Контроль НС по отрицательной температуре срабатывает, даже если, судя по параметрам, нет потребления тепла. Пример на скриншоте ниже. Это объект, где в течение отопительного сезона контур вентиляции работает не постоянно. И когда он работает, необходимо контролировать отрицательную разность температур.
Предложение: доработать это правило и, при необходимости, включать контроль только по достижении температурой Т1 установленного уровня и при наличии расхода, превышающего указанный. Значение расхода нужно брать, приведенное к часу. Также необходимо позволить пользователю выбирать, какие данные использовать при анализе.
По умолчанию поведение этой НС должно быть таким же, как до этого изменения.
Кроме того, похоже, эта НС в списке НС указывается с неправильным типом
Не думаю, что нужно переделывать этот тип диагностики, так как он используется в системах теплоснабжения, где dQ отсутствует только в межотопительный период.
Моё предложение направлено на то, чтобы в ЛЭРС Учете появилось больше аналитической диагностики, которую можно было бы просто и гибко настраивать. Одно такое универсальное правило позволяет избежать дублирования диагностических условий и минимизирует риск пропустить важную ситуацию.
Например, после внедрения контроля работы расходомеров большинство правил, связанных с диапазонами, я перестал использовать на практике.
Я описал диагностику, не привязанную к конкретному региону - её можно применять по всей стране, особенно актуально это для южных регионов, где отопительный сезон может прерываться: это происходит как из-за действий ЭСО, так и по инициативе самих потребителей.
Контроль на отрицательные температуры - это не про стабильную работу отопления, для этого есть рабочий или метрологический диапазон измерения разности температур. На практике контроль отрицательных температур чаще всего отключён или дублирует другие правила. Мой подход позволяет использовать этот контроль более эффективно.
Пользовательская диагностика действительно решает проблему - это универсальный и гибкий инструмент для настройки контроля и аналитики в системе.
Этой теме уже три года. Я хотел понять реальные задачи пользователя, чтобы запроектировать правильный механизм. Были и другие темы, где этот вопрос поднимался и я задвала такие же вопросы. И в результате обсуждения мы сделали для формул и ссылки на точки учёта в объекте и ссылки на текущую точку и групповые операции по настройке формул диагностики.
А ситуация похожая. Объектов тоже много - около 160.