Udjin
Forum Member / Участник форума
Участник № / Member № 8428
отправлено / posted
Добрый день. Планирую создать ГЭ "События" к которым привяжу все возможные аварии по связанным со СКАДА установкам. При возникновении аварии будет включаться звуковой сигнал, который будет гоняться в цикле на протяжении 4-х дней (потом умолкнет),если ранее его никто не квитирует или событие не исчезнет. Как включать/выключать звук, а так же задавать длительность зацикленного сигнала я разобрался. Но накопил ряд вопросов о которых не нашел пояснения ни в справочнике, ни в литературе, ни на форуме: 1) Зачем необходимы короткие и длинные события? 2) Зачем необходимы события второго типа при стандартной работе алгоритма канала СОБЫТИЕ (чем они могут отличаться от первого типа)? 3)Как изменять длительность коротких событий и таймаут квитирования событий? Делал так: в слое "системные" создавал @RTM_Parameter с параметром 10 (или 11) и типом OUTPUT, привязывал к нему канал типа F в котором устанавливал тип OUTPUT, период - "однократно", ставил галку "отработать", на старте - 30. В итоге данный канал определял недостоверность (атрибут 004 - F), а значение параметра @RTM_Parameter остается неизменным...
Сообщения / Posts 31 | Из / From: Российская Федерация
| IP / IP: IP адрес / IP address |
Udjin
Forum Member / Участник форума
Участник № / Member № 8428
отправлено / posted
Уважаемая Техподдержка, не хотелось бы Вас торопить, но я все еще очень жду ответа на 1 и 3 вопросы)))))
Сообщения / Posts 31 | Из / From: Российская Федерация
| IP / IP: IP адрес / IP address |
отправлено / posted
Извините за задержку с ответом.
1. "короткие" и "длинные" события - это условное разделение событий по длительности. Если событие возникло и исчезло за время меньшее чем время на квитирование события (Tисчезновения - Tвозникновения < Ack_after_of), то оно короткое. Принципиальное отличие между ними по возможности квитирования. Длинное не успел квитировать - не сможешь квитировать, короткое не квитировал - есть время согласно RTM_Parameter Параметр=11.
2. События второго типа необходимы в случаях когда возможно возникновение большего числа событий, чем "событие пришло" и "событие ушло".
3. При описанной постановке задачи рекомендуем использовать не канал Событие, а Отчет Тревог узла для фиксирования события, Sound_file для звуковой индикации и дополнительно цветовую индикацию на экране.
Звуковая индикация применяется для привлечения внимания Оператора. Зацикливать ее на 4 дня сомнительное решение. Стоит рассмотреть дополнительные варианты.
Сообщения / Posts 17345 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Udjin
Forum Member / Участник форума
Участник № / Member № 8428
отправлено / posted
3. Хорошо, но где-то на форуме я читал, что отчет тревог имеет ограничения по отключению звука при квитировании.
Цель: Создание СКАДА-системы мониторинга работы узлов жизниобеспечивания здания: (вент.установок,ВРУ,АВР,освещение,тепловые завесы и т.д.) одного из корпусов "кампуса". По т.з. техник (оператор) может заходить в диспетчерскую раз в 2-3 дня, если нет заявки. Для этого и была осуществлено зацикливание на 4 дня (потом звуковая тревога на динамиках замолкает). Так вот, возвращаясь к 3-му пункту: решил вести общий отчет тревог на отдельном экране, а на главном экране находится ГЭ "Событие" на котором могут высвечиваться все аварийные ситуации. "Запилена" программа, которая анализирует статусы Событий и если хоть одно событие ==1, тогда звук есть, в противном случае звук "Тревога" выключен, т.о. оператор не сможет пропустить ни одной тревоги, не квитировав её (а если он квитировал тревогу, значит для себя зафиксировал и принял меры по устранению)...Так вот, опираясь на вышеуказанное хотелось бы увеличить таймаут квитирования события...
Сообщения / Posts 31 | Из / From: Российская Федерация
| IP / IP: IP адрес / IP address |
quote:Отправитель / Originally posted by Udjin: По т.з. техник (оператор) может заходить в диспетчерскую раз в 2-3 дня, если нет заявки.
При указанной постановке задачи невозможно произвести оперативное реагирование Оператором на возникшее событие. Следовательно нет необходимости проигрывать звуковой файл столько времени. Звуковая сигнализация необходима именно для оперативного реагирования, а не для пост-анализа.
Для решения описанной задачи проще использовать Отчет Тревог для отображения на экране. Для вывода звукового оповещения Системная переменная Sound_File с Параметр=3.
Для увеличения длительности проигрывания зацикленных сообщений Sound_File с Параметр=4 в разумных пределах для обеспечения оперативного оповещения Оператора.
Рекомендую изучить вопрос о дополнительном информировании Оператора через e-mail (Call.Email) или SMS.
Сообщения / Posts 17345 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Printer-friendly view of this topic
