Генерация событий и сообщений

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

Для оповещения персонала используются различные элементы визуального оформления на терминале диспетчерской станции, локальные сигнальные лампы, светофоры и сигнальные панели, установленные в производственных помещениях, устройства звукового оповещения – зуммеры, громкоговорители и т.д., а также средства оповещения по электронной почте, через мессенджеры, СМС и т.п.

Оповещение персонала представляет собой многоступенчатый процесс, как правило, состоящий из следующих этапов:

1. Генерация события
2. Генерация сообщения
3. Вывод оповещения
4. Квитирование (опознание) сообщения
5. Инактивация (сброс) события (где применимо)

Генерация события

Событие в электронной системе можно определить, как идентификацию наступления определенных обстоятельств или выполнения определенных условий. Существуют различные программные механизмы реализации событий, от системных / аппаратных прерываний (System / Hardware Interrupts) на самом низком уровне, до генерации событий (Event) с их дальнейшим «отлавливанием» (Catch) и обработкой специальными обработчиками событий (Event Handler) в объектно-ориентированных языках программирования высокого уровня. Также распространены системы, где концепция событий реализуется с помощью обработки различных флагов статуса.

Жизненный цикл события в электронной системе можно описать следующим образом:

• Некий аппаратный и/или программный компонент электронной системы осуществляет регулярную проверку выполнения некоего условия / набора условий.
• В случае, если условие / набор условий выполнены, компонент электронной системы вносит изменения в определенные записи в системе, отражающие некий статус (в т.ч. абстрактный), которые доступны другим компонентам электронной системы – т.е. генерирует событие. В таких записях может также содержаться сопутствующая событию информация (например, код нажатой клавиши на клавиатуре в случае события «нажатие клавиши»).
• Другие компоненты электронной системы регулярно проверяют эти записи.
• Если они обнаруживают наличие определенного статуса в записях (т.е. «отлавливают» событие), они запускают некую процедуру / подпрограмму / макрос и т.п. (т.е. обработчик события), которые обрабатывают это событие, при необходимости используя сопутствующую информацию о событии из записей. В ходе обработки события они могут в свою очередь генерировать новые события, которые будут отлавливаться и обрабатываться другими компонентами системы.
• Также обработчик события может изменять записи, связанные с исходным событием, в том числе сбросить установленный при генерации события статус, чтобы оно больше не отлавливалось и не обрабатывалось компонентами системы, т.е. отметить событие, как обработанное.

Все события в системе GMP мониторинга можно подразделить на 2 класса: события процесса и события системы.

События процесса включают в себя различные обстоятельства, связанные с изменением наблюдаемых системой параметров и штатной эксплуатацией системы мониторинга, например:

• Выход наблюдаемых параметров за границы установленных пределов
• Изменение оператором настроек системы / пределов предупреждений / тревог для наблюдаемых параметров
• Квитирование (опознание) оператором предупреждений / тревог
• Истечение срока действия пароля учетной записи оператора

События системы включают в себя обстоятельства, связанные с различными сбоями и отклонениями в работе самой системы мониторинга, например:

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

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

Генерация сообщения

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

Алгоритм генерации сообщений анализирует события и формирует соответствующие сообщения, добавляя к ним необходимую сопутствующую информацию и текстовые комментарии для оператора, а также указания системе о категории сообщения, используемых аудиовизуальных сигналах и т.п.

Сформированное таким образом сообщение отправляется на исполнение (вывод оповещения).

Как правило, сообщения можно разделить на следующие три категории:

1. Тревога (авария)
2. Предупреждение
3. Информационное сообщение

Вывод оповещения

Система пользовательского интерфейса, или HMI (Human-Machine Interface) считывает сообщения из соответствующей очереди или массива записей системы, и осуществляет вывод соответствующих оповещений для оператора: на терминале диспетчерской станции, локальных терминалах, сигнальных лампах, светофорах и панелях, зуммерах / громкоговорителях, или путем отправки сообщений по электронной почте, в мессенджерах или на мобильные телефоны через СМС.

Квитирование (опознание) сообщения и инактивация события

Функция квитирования (опознания) сообщения необходима по целому ряду причин:

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

При квитировании сообщения система GMP мониторинга должна регистрировать: имя/учетную запись пользователя, осуществляющего квитирование, время квитирования, и, если применимо, комментарий пользователя / причину квитирования.

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

Система GMP мониторинга Tarqvara

В системе GMP мониторинга Tarqvara сопоставление значений параметров каналов с установленными пределами и контроль различных функций системы на предмет наличия ошибок осуществляется 1 раз в секунду. При выполнении определенных условий генерируются соответствующие сообщения (тревоги/предупреждения).

Каждое сообщение может иметь следующий статус:

1. Сообщение неактивно
2. Сообщение активно
3. Сообщение квитировано

Жизненный цикл сообщения, связанного с параметром, выглядит следующим образом:

• Сообщение неактивно
• Значение параметра выходит за допустимые пределы.
• Начинается отсчет времени задержки генерации сообщения.
• По истечении времени задержки сообщение генерируется.
• Сообщение активно
• Срабатывает сигнал предупреждения/тревоги. К элементу интерфейса, отображающему канал, применяется соответствующая предупреждению/тревоге цветовая маркировка.
• Если значение параметра возвращается в норму, статус сообщения всё равно остается активным.
• Пользователь с достаточными полномочиями «квитирует» (опознаёт) сообщение, используя соответствующую функцию интерфейса. При квитировании пользователь может добавить текстовой комментарий, который сохранится в истории сообщений. Также возможно групповое квитирование сообщений с добавлением общего текстового комментария.
• Сообщение квитировано
• Сигнал предупреждения/тревоги выключается. К элементу интерфейса, отображающему канал, применяется соответствующая квитированию цветовая маркировка.
• Сообщение остается в статусе «квитировано» до тех пор, пока значение параметра находится вне допустимых пределов.
• После того, как значение параметра возвращается в норму, сообщение инактивируется (сбрасывается).
• Сообщение неактивно

Сообщения, связанные с системными событиями, не имеют времени задержки и генерируются мгновенно.

В случае аварийного отключения программных модулей или системы, или при сбое связи между сервером и датчиками, также генерируется аварийное сообщение (сразу после восстановления работы).

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

Некоторые события, генерируемые в системе GMP мониторинга Tarqvara, не вызывают генерации сообщений, но при этом записываются в Контрольный след или Журнал аудита (Audit Trail).

см. также:
Системы GMP мониторинга
Система мониторинга Tarqvara
Контрольный след (Audit Trail)
Руководство по эксплуатации типовой системы Tarqvara
IT-решения / GAMP / Целостность данных
Валидация компьютеризированных систем (CSV)