Публикация пресс-релизов Поиск по компании
Решения, технологии, стандарты Рынок, отрасль, люди Основы
Отменить подписку Подписка
Производители Системные интеграторы Дистрибьюторы
Продукты месяца Поиск по категории Добавить продукт
Добавить мероприятие
Добавить вакансию Специалисты по АСУ ТП, КИП Специалисты по электротехнике, энергетике Главные инженеры, технологи, электрики Менеджеры по продажам, консультанты, другое
Технические требования Публикация статей Публикация пресс-релизов Media Kit 2014
 


 

Решения, технологии, стандарты - статьи Ua.Automation.com

Диагностируем систему тревожного оповещения

Диагностируем систему тревожного оповещения

Дональд Данн и Николас Сэндс для InTech

Если вы работаете на предприятии нефтегазовой, химической, фармацевтической, энергетической, водной или пищевой промышленности, у вас, скорее всего, не все ладно с системой тревожного оповещения. Причем проблемы с ней, вполне вероятно, самые типичные. И это не очень хорошая новость, так как типичные сложности с системами аварийного оповещения делают весьма весомый вклад в аварии, выпуск некачественной продукции и простои предприятия.
 
Хорошей новостью является то, что для типичных проблем есть типичные решения. Как правило, они требуют существенных усилий, но зато они работают. Во всех отраслях есть много предприятий, которые уделяют внимание управлению системами безопасности для минимизации типичных проблем и их негативных последствий. И на таких предприятиях системы тревожного оповещения становятся надежным подспорьем для оператора, указывая правильное время для правильных действий, предотвращающих нежелательные последствия.
 
Давайте рассмотрим семь типичных проблем, их потенциальные последствия и возможные решения.
 
1. Слишком много тревог
 
Самая типичная проблема с системами тревожного оповещения – лавина тревог. Они могут в переносном смысле «затопить» оператора. И это может привести к нежелательным последствиям, если эти тревоги действительно сигнализируют о нештатных ситуациях, требующих реагирования. Если же нет, то это вызовет у оператора своего рода нечувствительность, апатию к тревогам, что тоже не сулит ничего хорошего, когда тревога будет настоящей. И это не «страшилка». Так действительно происходит.
 
Главным параметром, сигнализирующим об этой проблеме, является среднее количество тревог за единицу времени или количество тревог, передаваемых на одну панель оператора за единицу времени, деленное на длительность отчетного периода. Часто используется показатель среднего количества тревог в час на оператора в течение месяца. Метрика включает оператора или операторскую консоль, поскольку психофизические ограничения оператора, с более-менее постоянным уровнем на протяжении смены, являются основой для определения приемлемых значений. Иными словами, «операторская консоль» – это объем операторской зоны контроля, или зона его ответственности.
 

Рис. 1. Жизненный цикл управления тревогами

Меньше 6 тревог в час, скорее всего, вполне приемлемый уровень, в то время как больше 12 тревог в час – максимальный уровень, поддающийся управлению. Больше 30 тревог в час, скорее всего, – слишком тяжело. Не все согласятся с этими цифрами, а типы процессов и сложность требуемой реакции оператора тоже очень сильно влияют на них. С другой стороны, бывают случаи с более чем 1000 тревог в час, и все согласятся, что это совершенно неприемлемо.
 
Есть и другие метрики, отражающие проблему «лавины» тревог, как, например, количество активных тревог и доля времени «потопа тревог» в общей длительности периода работы оператора.
 
Существует множество потенциальных причин проблемы лавины тревог. Среди них: повторяющиеся тревоги (см. № 2) или тревоги, не требующие реакции (см. № 3). Задачей является измерение средней частоты тревог, чтобы понять, когда они сигнализируют о проблеме. Задача – измерить средний уровень тревог для того, чтобы понимать, когда он означает проблему. Не надо добавлять тревог для более высокого уровня. Эта метрика более полезна на протяжении какого-то периода времени, а не как «моментальный» снимок ситуации.
 
Стандарт ANSI/ISA-18.2-2009 (Управление системами тревожного оповещения в процессных отраслях) требует, чтобы мониторинг таких систем осуществлялся таким образом, который позволял бы проводить оценку: хорошо или плохо работает система. Разумеется, то, как происходит процесс, играет огромную роль в эффективности системы оповещения. В идеале система оповещения сообщает только о ненормальных условиях протекания процесса таким образом, чтобы оператор мог отреагировать. Система со слишком большим количеством тревог может не оказаться надежной поддержкой для оператора в предотвращении нежелательных последствий.
 
2. Самовозбуждающиеся тревоги
 
Основной вклад в возникновение проблемы № 1 делают так называемые самовозбуждающиеся (англ. chattering) тревоги. Они действительно делают оператора нечувствительным к тревожным сигналам. Если вы хоть раз видели, как оператор реагирует на тревогу, поворачиваясь спиной к консоли, то, скорее всего, это была самовозбуждающаяся тревога.
 
Эта проблема измеряется отношением, показывающим, во сколько раз временной промежуток между двумя тревогами, показываемыми оператору, меньше эталонного промежутка, часто равного 60 с. Тревога проходит через повторяющийся цикл: тревога – возврат к норме – тревога. Кластером называется группа сигналов тревог, подаваемых перед прекращением цикла повторов. Размер кластера – количество тревог в кластере. Порой можно встретить сообщения о более чем 100 000 тревожных сообщений в день, которые на определенном этапе становятся одним кластером.
 
Если предположить, что тревожный сигнал является необходимым (см. № 3) и точка активации тревоги установлена верно, то окажется, что самовозбуждающиеся тревоги часто вызываются ошибками настройки тревоги, как, впрочем, и неправильным обслуживанием измерительных устройств. Частью настройки тревог является выбор таких параметров, которые предотвращают ненужные повторы: диапазон нечувствительности, задержка подачи сигнала тревоги, задержка отмены сигнала тревоги. Выбор этих параметров часто включается в рационализацию тревожных сигналов.
 
Добавление диапазона нечувствительности в размере 1%, а также задержки отмены подачи сигнала тревоги длиной в 5 с радикально сокращают объем повторяющихся тревог. Задержка отмены подачи сигнала тревоги длиной 60 с превращает целый кластер самовозбуждающихся тревог в одну тревогу.
 
3. Тревоги, не требующие реакции
 
Как ни странно, одной из проблем является то, что, по мнению многих, функцией тревог является «информировать» оператора о состоянии оборудования и процессов. Эта ошибка основана на предположении, что функцией тревог является коммуникация между системой автоматизации и оператором.
 
Результатом этой ошибки является дальнейшее понижение чувствительности оператора к тревогам. Использование тревог для информирования хотя и является обычной практикой, на деле не соответствует определению тревог. Тревога – это слуховое или/и визуальное средство информирования оператора о том, что оборудование неисправно, или процесс отклонился от нормального протекания, или возникли нештатные условия, требующие реагирования.
 
Это сложная для измерения проблема. Лучший параметр, после завершения очень трудоемкой процедуры рационализации, это количество тревог, которые не потребовали реакции и были отменены. Нередко убирается до 50% тревог во время рационализации. Мы не говорим, что целью рационализации является устранение тревог. Целью рационализации является убедиться в том, что тревоги настроены правильно, точки их активации заданы верно, с правильным приоритетом, а документация составлена корректно и подходит для обучения операторов.
 
Рационализация может привести к тому, что ряд сигналов будет назначен как уведомления, а не как тревоги. Уведомления показываются в другом списке, по сравнению с тревогами, отделяя «важное» от «важного и срочного». Уведомление – это слышимое и/или видимое средство указания оператору на факт об оборудовании или состоянии технологического процесса, о котором он должен знать, но который не соответствует критериям тревоги.
 
Другой обычной причиной этой проблемы являются тревоги, которые остаются активными в течение долгих промежутков времени  (см. № 4).
 
4. «Зависшие» тревоги
 
Реестр тревог может быть заполнен «зависшими» тревогами, или тревогами, которые остаются активными более 24 часов. Это могут быть тревоги, которые не требуют реакции (см. № 3) или однажды требовали, но больше реакция не нужна. Эти тревоги заполняют собой списки тревог и приводят к нечувствительности оператора. Некоторые могут не согласиться, но «зависшие» тревоги по определению являются ложными.
 
Измерить «зависшие» тревоги очень просто: количество тревог, прозвучавших в течение 24 часов. Сложно поверить, но встречались тревоги длительностью 13 лет. Как вы сами понимаете, скорее всего, тревога была ложной.
 
Две обычные причины зависших тревог – специфические практики настройки систем управления и неправильные процедуры управления изменениями. Одно исследование «зависших» тревог показало, что 30% из них были связаны с оборудованием, не работавшим в тот момент, поскольку оно не было необходимым. К примеру, базовые практики настройки сгенерировали тревогу, сигнализировавшую о том, что насос не работает – хотя он был отключен намеренно. Правильная настройка предотвращает множество ненужных тревог.
 
Второй причиной «зависших» тревог является плохое управление изменениями. Когда оборудование убирается из цеха, соответствующая тревога должна быть убрана из системы управления или, как минимум, деактивирована. Будем откровенны, в списке тревог частенько находятся тревоги, относящиеся к оборудованию, которого на заводе нет уже несколько лет.
 
5. Неверный приоритет тревог
 
Многим тревогам присваивается неправильный приоритет, что делает эту характеристику менее полезной для оператора, а потенциально вообще бесполезной. Это может привести к неправильной реакции, когда активны сразу несколько тревог. Необходимо отметить, что в случае серийного производства (ISA-TR18.2.6-2012) приоритет тревог необходимо изменять при переходе от одной стадии процесса к другой. Так что если во время рационализации тревоге присваивается один приоритет, скорее всего, он будет верным для одних этапов производства и неверным для других.
 
Измерение проблемы также происходит после рационализации. Разумная приоритезация, основанная на масштабе последствий и времени, отводимом на реакцию, может кардинально изменить приоритеты тревог. В некоторых случаях изменяется до 80% приоритетов – в основном, на более низкие.
 
Приоритет должен быть основан на том, насколько срочно оператор должен предпринять какие-то действия. Часто в этом нет необходимости. Проблема состоит в том, что на многих предприятиях не использовалось никакой, не то что стройной, системы для присвоения приоритетов. В большинстве случаев это оставлялось на усмотрение инженера АСУ ТП. Также существовал достаточно распространенный подход, заключавшийся в том, что приоритеты (порой жестко задаваемые в АСУ ТП) тревог присваивались следующим образом: чем дальше переменная отходит от нормального показателя, тем более высокий приоритет присваивается тревоге. Это неправильно. Приоритет тревоге должен присваиваться на основе последствий, которые может предотвратить оператор, а также разнице в последствиях при реализации различных сценариев, когда оператор реагирует или не реагирует.
 
Обычной ошибкой является оценка последствий, которые может предотвратить оператор, с помощью тех же методов, что и при анализе рисков процесса (англ. process hazards analysis или PHA). Есть три разницы между оценкой последствий при рационализации по сравнению с РНА:
 
1. Есть предохранительные механизмы или нет: PHA исследует последствия рисков без учета предохранительных механизмов или уровней защиты. В рационализации учитываются все уровни защиты либо присутствуют специфические тревоги, сигнализирующие об их отказе. К примеру, рационализация всегда предполагает, что аварийный замок сработает. В противном случае, последствия, для предотвращения которых он был разработан, обозначаются как последствия, предотвращаемые оператором.
 
2. Ближайшие последствия или конечные: PHA фокусируется на конечных последствиях, следующих после цепи событий. В рационализации последствия отсутствия реакции только ведут к следующему событию в цепи, а не к конечному результату. К примеру, высокоуровневая тревога может дать оператору шанс отреагировать и предотвратить активацию аварийного замка. Последствиями отсутствия действия будет срабатывание замка, а не переполнение резервуара из-за того, что замок отказал. 
 
3. Вероятное или возможное: PHA фокусируется на маловероятных событиях, которые могут привести к катастрофическим последствиям – раз в тысячу лет или около того. Рационализация должна фокусироваться на вероятных причинах и вероятных последствиях. Список должен быть коротким и ясным, чтобы оператор мог практиковаться в реагировании на то, что реально происходит на предприятиях каждый день. Решение проблемы должно начинаться не с самой маловероятной причины, а с наиболее вероятной.
 
Если вы еще не в курсе, то сложно себе представить, насколько удобно и правильно, когда приоритет тревог расставлен правильно и основан на срочности действий оператора.
 
6. Неконтролируемая деактивация тревог
 
Зачастую неконтролируемая деактивация тревог обнаруживается после возникновения нежелательных последствий, к которым привело отсутствие тревоги, побуждающей оператора к действию. Есть более удобные способы нахождения этой проблемы. Исследование неконтролируемой деактивации тревог состоит из двух частей: оценки предположительно контролируемого архивирования тревог и оценки тревог, деактивированных без надлежащей авторизации. Есть три типа деактивации, упомянутые в ISA-18.2, и которые можно описать следующим образом:
 
  • Запрограммированная деактивация: соответствующим образом запрограммированная система управления регулирует деактивацию и активацию тревог.
  • Архивация: оператор отключает тревогу, а система архивации контролирует ее обратную активацию.
  • Вывод из эксплуатации: для активации и деактивации тревог используются административные средства.
 
Архивация и вывод из эксплуатации могут использоваться неправильно. Архивация не должна использоваться без системы мониторинга, оповещающей о наиболее часто архивируемых тревогах, которые необходимо проверять на предмет потенциальных изменений. Выведенные из эксплуатации тревоги могут оставаться деактивированными в течение долгих лет без решения реальной проблемы, как правило, связанной с КИПиА. Такие формы подавления тревог также необходимо отслеживать и проверять на предмет неправильного использования.
 
7. Оператор, не обученный реагировать на тревоги
 
Другой проблемой является то, что сложно измерить количество тревог, на которые оператор не обучен реагировать. В итоге это ведет к нежелательным последствиям, для предотвращения которых тревога как раз была создана. И все из-за отсутствия правильных действий.
 
Тревоги существуют только для того, чтобы предложить оператору предпринять корректирующие действия. Если бы не было оператора, не было бы и тревог. Для реализации функции тревоги необходимо предпринимать корректирующие действия. Действия должны быть известны заранее или легко находится в соответствующих руководствах. Тревоги, внедренные без рационализации или обучения оператора, часто приводят к проблемам. В таких случаях необходимо пересматривать программу обучения оператора.
 
Процесс рационализации включает основную информацию для обучения оператора:
 
  • Вероятную причину тревоги.
  • Корректирующие действия, которые позволят отреагировать на тревогу.
  • Последствия, возникающие в случае, если действия не будут предприняты.
Эту информацию иногда называют процедурой реагирования на тревоги.
 
Управление тревогами
 
Этот список проблем с системами тревожного оповещения не является исчерпывающим, но перечисленные семь являются наиболее общими. Анализ проблем показывает, как каждая из них может быть измерена и решена. Не случайно решениями являются действия в жизненном цикле управления тревогами ISA-18.2. Рационализация, внедрение, мониторинг и оценка, эксплуатация, включающие обучение и контроль за деактивацией тревог, а также управление изменениями, являются ключевыми активностями управления тревогами. Благодаря этим активностям и остальным этапам жизненного цикла, могут быть минимизированы типичные проблемы систем тревожного оповещения, а сами системы будут по-настоящему помогать операторам, как и требуется.
 
Следующие шаги
 
В рамках постоянного развития ISA-18.2 разрабатывается серия технических отчетов ISA18 (TR), которые помогут практикам в области управления тревогами реализовывать требования и рекомендации ISA-18. Если вы заинтересованы в том, чтобы сделать свой вклад в этот процесс или получить помощь и совет от своих коллег, можете связаться с руководителями ISA18: Николас Сэндс (Nicholas Sands) (Nicholas.P.Sands@USA.dupont.com) или Дональд Данн (Donald Dunn) (Donald.G.Dunn@p66.com).