От управления к оптимизации тревог на производстве

Если в последнее время вы изучали вопрос управления тревогами, то в курсе, что сейчас большинство дискуссий разворачиваются вокруг того, как уменьшить количество тревог, с которыми должны иметь дело операторы в залах управления в обычное время и во время аварий. Этот тренд соответствует здравому смыслу, подсказывающему, что если активировано слишком много тревог, то только потому, что настройщику было легко это сделать в компьютеризированной системе управления процессами. Из-за этого же легко и ошибиться в настройке тревог, или сделать их активацию слишком «чувствительной».

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

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

Чем помогает ANSI/ISA-18.2

В 2003 ISA начала разработку стандарта, который помог бы в управлении тревогами. После нескольких лет работы был представлен стандарт Управление системами тревожного оповещения для процессных отраслей, ANSI/ISA-18.2-2009 (Management of Alarm Systems for the Process Industries). Недавно эта версия была обновлена. Стандарт несколько отошел от обычного подхода ISA, которая, как правило, концентрируется на азах. Вместо этого стандарт был разработан, скорее, с прицелом на широкое видение рабочих процессов, а не на механику. Стандарт учитывает, что управление тревогами существенно зависит от человеческого фактора – ведь, хотя в процесс вовлечены механизмы и системы, в основном он управляется человеком.

Основываясь на работе Консорциума по управлению чрезвычайными ситуациями (Abnormal Situation Management Consortium (ASM)), Ассоциации пользователей сырья и инженерного оборудования (Engineering Equipment and Materials Users Association (EEMUA)) и NAMUR, нефтехимическая отрасль использует этот стандарт уже примерно десятилетие. В последнее время он начал широко использоваться в других отраслях, и сегодня есть смысл изучать его для буквально всех профессионалов промышленной автоматизации. Стандарт фокусируется на тревогах, обычных для современных систем управления технологическими процессами, таких как РСУ, системы сбора данных, ПЛК и т.д.

Поскольку ANSI/ISA-18.2 является стандартом, а не руководством или предложением – он является «признанной и распространенной лучшей инженерной практикой». Т.е. его используют соответствующие надзорные и контролирующие организации при оценке уровня безопасности производств и расследовании инцидентов.

Жизненный цикл тревоги

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

Слишком много, слишком мало или ровно столько, сколько нужно

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

Концепция проста, но ее не так просто реализовать. Главная проблема с неконтролируемым количеством тревог состоит в том, что слишком много их может активироваться в одно и то же время, «перегрузив» операторов. Во время этого «потока» тревог практически невозможно отличить важные тревоги от дублированных или нерелевантных. В результате этого ситуационная осведомленность страдает, и операторы могут принимать неправильные решения и даже усугублять инциденты вместо их устранения.

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

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

Использование диагностических функций в течение некоторого времени было весьма противоречивым. Если преобразователь давления демонстрирует ухудшение состояния электроники, он может обнаружить проблему и послать предупреждение. Но кому? Операторам зала управления? Персоналу техподдержки? Правильный ответ, конечно же: «зависит от ситуации».

Одно из базовых требований к «правильной тревоге» то, что оператор должен быть в состоянии сделать что-либо для устранения или хотя бы реагирования на ситуацию. Так что, если датчик давления передает критические показания, то это сценарий для тревоги уровня зала управления, даже если операторы сами и не будут заниматься ремонтными работами. С другой стороны, они могут внедрить резервное решение или компенсировать потерю данных во время замены или ремонта устройства. А теперь умножьте этот сценарий на количество всех интеллектуальных инструментов и приводов на предприятии или в цеху.

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

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

Динамические тревоги

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

Вот еще один пример: компрессор подает сжатый воздух в различные устройства в цеху, такие как приводы клапанов. Каждое из устройств проверяет, адекватна ли подача воздуха, и сработает, если трубопровод засорится или кто-то ненароком закроет клапан. Теперь предположим, что привод компрессора отказывает. У него есть своя тревога для предупреждения операторов и техников о том, что подача воздуха прервана. Операторам может понадобиться открыть клапан для того, чтобы воспользоваться потоком воздуха из другой части производства, пока служба техподдержки ремонтирует компрессор. Теперь, когда с корневой причиной уже работают, нужны ли в зале управления десятки или даже более тревог от всех устройств, зависящих от подачи воздуха и сообщающих о том или ином отказе? Очевидно, нет. Как только исходная причина становится известной операторам, все связанные тревоги должны быть подавлены, чтобы не отвлекать операторов от реальной проблемы.

Типы подавления

ANSI/ISA-18.2 определяет три типа подавления тревог:

1. «Откладывание», когда оператор вручную заглушает тревогу на время.
2. «Запрограммированное подавление», когда система АСУ ТП заглушает тревогу при наступлении необходимых условий.

3. «Отключение», когда тревога заглушается потому, что часть оборудования отключена для ТО или по другой причине.

Запрограммированное подавление является самым интересным и сложным одновременно и, как правило, делится на две категории: статическое и динамическое подавление.

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

Динамическое подавление позволяет избежать «потопа» тревог во время отказа того или иного оборудования или при более сложных сценариях. Оно наделяет систему достаточной «разумностью» для определения самых важных тревог в данных условиях и обеспечивает привлечение внимания операторов к ним с одновременным подавлением ненужных или нерелевантных тревог.

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

Очень сложная задача

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

Компании могут или инвестировать в развитие собственного персонала, ответственного за управление тревогами, с помощью учебных программ, подобных той, что предлагает ISA, или использовать опытных консультантов и системных интеграторов. Они могут помочь с программами управления тревогами, в частности, с их внедрением. Развитие своего персонала – долгосрочная инвестиция, которую надо всесторонне обдумать.

Использование услуг интеграторов вполне может оказаться более разумным вариантом.

Источник: http://ua.automation.com/content/ot-upravlenija-k-optimizacii-trevog-na-proizvodstve