Дополнительный триггер формирования нештатной ситуации

Хотелось бы увидеть триггер с “двойным условием”, а именно если T1(температура по подаче) и T2(соответственно по обратке) > 29 градусов по Цельсию, а M1 и M2 (расход по подаче и обратке) ~=0 (десятые и сотые доли числа считать равными нулю во избежании наводок и “шума”) формировать нештатку, типа - “Отсутствует расход в несущей” или в “отводящей”.

Непонятно, почему " M1 и M2 (расход по подаче и обратке) ~=0", а формировать нештатку, типа - “Отсутствует расход в несущей” или в “отводящей”. Из-за этого непонятно, для каких систем нужна такая диагностика.

Объясню, на примере. Предположим производился монтаж “на сухую”, т.е. система не была запущена, возмем пример с эноргозависимыми расходомерами, работают они от сети 12В, в монтажном комплекте стоят блоки питания преобразователи 220-12В, в межотопительный сезон их выключают. К моменту запуска, многие не помнят, что расходомеры не работают, но термодатчики, как правило, энергонезависимые и поэтому с них данные идут постоянно, в следствии мы имеем T1-2>30, M1-2 = 0, но ЛЭРС не генерирует нештатку, потому что расход был 0 и сейчас 0, все нормально, но мы то видим что темпер в трубах, например, 60 градусов, а расход 0, что есть нонсенс, вы согласны?
Да, можно триггер выставить на M текущий меньше, например, 0.001 но данный триггер не всегда будет отражать действительность, да и в таком случае будет нештатная ситуация, а хотелось бы критическую ошибку видеть или что-то подобное. Поэтому и хочу увидеть триггер с условием.

Вот пример
0 по М1 и М2.png

а вот пример наводок или так называемого “шума”
соответственно, инженер, который это видит, сразу скажет, что это прибор “глючит”, и цифры эти никакого отношения к действительности, к отоплению летом, не имеют.
Это я к “Непонятно, почему " M1 и M2 (расход по подаче и обратке) ~=0”, а формировать нештатку, типа - “Отсутствует расход в несущей” или в “отводящей”
шум в приборе.png

Так все таки, если взять ваш последний пример, какую нештатку должна сформировать система: “Отсутствует расход в несущей” или “Отсутствует расход в отводящей”?

Последний пример с “шумом” не подходит под условие из вашего первого сообщения: “а именно если T1(температура по подаче) и T2(соответственно по обратке) > 29”, т.к. Т1 в примере < 29 градусов.

Если взять пример где T>30 M=0 то соответственно она должна сформировать ошибки, предположим из условия T1>30, M1 = 0 - “отсутствует потребление в несущей”, T2>30, M2=0 - “отсутствует потребление в отводящей”…

Все верно, последний пример не подходит под условие, я поэтому его и выложил. Но если бы T1-2 было бы >30, а, к примеру, шум составлял порядка 0,09 - 0,1 то этот вариант бы отработал без ошибки, хотя фактически она бы была.

Вы меня в конец запутали. Давайте с самого начала.

Исходное условие из первого сообщение звучит следующим образом:

а именно если T1(температура по подаче) и T2(соответственно по обратке) > 29 градусов по Цельсию, а M1 и M2 (расход по подаче и обратке) ~=0"

В этой формулировке условие противоречит вашей последней фразе

предположим из условия T1>30, M1 = 0 - “отсутствует потребление в несущей”, T2>30, M2=0 - “отсутствует потребление в отводящей”

Может исходную формулировку стоит заменить на “T1 > 29 и M1~=0” или “T2 > 29 и M2~=0”?

Да именно это я и имел ввиду, извините за неясность.

Тогда двигаемся дальше. Насколько я понимаю, цель предлагаемой вами диагностики заключается в том, чтобы просигналить об объекте, на котором в зимнем режиме отсутствует расход. Поправьте, если я ошибаюсь.

В обновлении 3.08 мы планируем вернуть в систему понятие сезона для систем теплоснабжения и ГВС. В зависимости от сезона (отопительный/межотопительный) будут использоваться различные параметры диагностики. Туда же можно добавить и диагностику отсутствия теплоносителя после даты начала отопительного сезона.

Система должна создавать запись в журнале нештатных ситуаций, чтобы мог отработать блок рассылки уведомлений. Уровень нештатной ситуации может быть “критическая”.

Да, вы правы, я хочу видеть что отсутствует расход в зимнее время (!!если имеется Температура в теплоносителе свыше 29 грЦ!!) на конкретном объекте учета или точке.

я бы предложил пойти дальше, и позволить каждому пользователю самостоятельно определять параметры формирования нештатных ситуаций (например в виде конструктора диагностических параметров). так как бывают случаи, когда заданных в текущем ПО наборов параметров недостаточно. возможно, на один параметр необходимо поставить несколько триггеров с различной степенью критичности НС. свобода конфигурирования системы диспетчеризации это один из важнейших критериев выбора между программными продуктами.

Это было бы вообще здорово.
И еще иметь возможность работать с триггерами в групповых операциях.