Снижение количества ложных тревог с помощью ISA 18.2 в Honeywell Experion и Emerson Ovation
Слишком большое количество ложных тревог мешает оператору заметить действительно важное предупреждение. ISA-18.2 предоставляет жизненный цикл для определения того, какие тревоги должны отображаться на консоли, как они должны работать и как следует оценивать их эффективность.
Почему количество тревог выходит из-под контроля?
Когда для каждого аналогового тега задаётся несколько стандартных пределов, обычные колебания процесса могут вызывать повторяющиеся уведомления. Тревога должна указывать на ненормальное состояние, требующее определённой реакции оператора, а не просто сообщать об изменении значения. Начните с философии управления тревогами, проведите их рационализацию в соответствии с ней, управляйте изменениями и оценивайте эффективность на основе реальной истории событий.
Как задавать приоритет, мёртвую зону и задержку?
Назначайте приоритет с учётом последствий бездействия и доступного времени на реакцию, используя утверждённую на объекте матрицу. Устанавливайте мёртвую зону или гистерезис, чтобы предотвратить дребезг около порогового значения, и используйте задержку включения только в тех случаях, когда это допускается технологической опасностью. Не существует универсального процентного значения или количества секунд для контуров расхода, уровня или давления. Убедитесь, что задержка не может скрыть быстро развивающееся опасное состояние.
В Honeywell Experion и Emerson Ovation перед изменением атрибутов проверьте установленную версию и настроенный объект тревоги. Связанные продукты, такие как модуль Honeywell Experion Series 8 IOTA и модуль аналогового ввода Emerson Ovation, работают в системах, где поведение тревог необходимо проверять в фактической конфигурации. Не предполагайте, что обе платформы используют одинаковые настройки или блоки.
Что должно входить в основную базу данных тревог?
Для каждой тревоги записывайте её тег, назначение, ненормальное состояние, последствия, необходимые действия оператора, время реакции, приоритет, уставку, мёртвую зону, задержку, правила квитирования с временным снятием или подавления и историю проверок. Отклоняйте или перерабатывайте уведомления, для которых не предусмотрено полезное действие оператора. Выбирайте целевые показатели эффективности на основе философии управления тревогами и истории эксплуатации объекта, а не копируйте фиксированные целевые значения для активных тревог или потоков тревог с другого объекта.
Когда уместно временное снятие тревоги?
Временное снятие тревоги удаляет её из активного представления оператора на ограниченный срок в рамках контролируемой процедуры. Определите, кто может временно снять тревогу, по какой причине, на какой срок, как это будет отображаться и когда тревога должна автоматически вернуться. Не рассматривайте фиксированный таймер временного снятия при запуске как замену корректному управлению тревогами на основе состояния. Тревоги, критичные для безопасности, требуют особого внимания в соответствии с политикой объекта.
Как следует передавать тревоги через OPC UA?
Если сервер поддерживает OPC UA Alarms & Conditions, подпишитесь на соответствующие события и проверьте тип события, источник, временную отметку, активное состояние, квитирование и переходы к нормальному состоянию. Подписки на события могут лучше сохранять переходы, чем периодический опрос, однако доставка и буферизация по-прежнему зависят от конфигурации сервера и клиента. Не ограничивайте события, передаваемые на нижестоящие системы, только уровнями High и Emergency, если только принимающий сценарий использования и политика хранения явно не допускают исключение событий с более низким приоритетом. Задавайте параметры публикации и очереди на основе проверенной пропускной способности, а не фиксированных общих значений.
Как оператору справиться с потоком тревог?
Анализируйте последовательности тревог, чтобы найти первопричину, затем проводите рационализацию зависимых тревог и применяйте утверждённое проектное подавление, если состояние процесса делает их неактуальными. Сохраняйте видимость опасностей, требующих действий. Тестируйте изменения в реалистичных сценариях нарушений режима и отслеживайте частые тревоги, тревоги с дребезгом, потоки тревог и реакцию операторов по сменам. Любое принудительное тестирование должно выполняться по утверждённой процедуре, обеспечивающей защиту объекта и персонала.
Каков первый практический шаг?
Возьмите репрезентативную историю тревог из установленной системы Honeywell Experion или Emerson Ovation. Определите наиболее проблемные повторяющиеся тревоги, подтвердите необходимые действия оператора и рационализируйте приоритет, пределы, мёртвую зону и задержку, прежде чем изменять сразу большое количество тегов. Обеспечивайте синхронизацию основной базы данных тревог с рабочей конфигурацией посредством управления изменениями.
Автор: Чжао Минъюань - инженер по промышленной автоматизации с более чем 10-летним опытом работы с PLC, DCS и системами управления.
