Автор: В.Ю. Усачев (АО «ИПН»).
Опубликовано в журнале Химическая техника №9/2018
Современные нефтехимические производства становятся все более сложными, растет уровень автоматизации технологических процессов, развитие технологий в области микроэлектроники и вычислительной техники позволяет легко получать все больше информации от датчиков, исполнительных механизмов, локальных САУ и т.д. и обрабатывать ее. Заказчики, эксплуатирующие технологические установки, хотят контролировать все параметры и состояния, какие только возможно, соответственно растет количество сигналов АСУТП и самой его ответственной части – системы ПАЗ. Безусловно, все это хорошо. Но, с другой стороны, оператор часто не в состоянии справляться с поступающим потоком информации. Для безопасной эксплуатации опасных производственных объектов сегодня уже недостаточно просто наличия системы ПАЗ. Необходимы программные решения, позволяющие ранжировать по уровням приоритетности все системные аварийные сообщения.
Типы сообщений в АСУ ТП. Основные понятия
В учебной и справочной литературе по АСУТП рассмотрены классические, несколько упрощенные, сис-темы типов (уровней) сигнализаций/сообщений, которые формирует Система для информирования и/или оповещения операторов технологического процесса, диспетчеров или иного оперативно-технического персонала, например, в главе 13.16 «Уровни сигнализаций. Определения» [1]. Цель данной статьи: дать более подробную информацию по данному вопросу и попытаться построить систему ранжирования сообщений подситемы АСУТП – Противоаварийной защиты (ПАЗ), или, по крайней мере, дать свое видение, как решать проблему распределения тревожных сообщений ПАЗ на этапе разработки прикладного ПО под конкретный технологический процесс сложного и опасного производства.
В АСУТП сложных и опасных производственных объектов (ОПО) принято функциональное разделение входных сигналов на следующие:
- данные для управления и автоматического регулирования технологическим процессом;
- информационные/мониторинговые данные;
- события (могут быть как входные, так и внутрисистемные генерируемые сигналы);
- тревожные сообщения.
Два последних типа входных сигналов, как правило, относятся к системам ПАЗ. Рассмотрим их подробнее.
События (Events) представляют собой обычные статусные сообщения системы и не требуют немедленной реакции оператора. Обычно событие генерируется при возникновении в системе определенных условий, например, вход в систему, или регистрация оператора в системе, или включение дренажного насоса. События отображаются на экранах визуализации и регистрируются в журнале событий в системе и могут впоследствии обрабатываться текстовым редактором.
Тревожные сообщение – это некое сообщение, предупреждающее оператора о возникновении ситуации, которая может привести к нежелательным, нестандартным, а иногда и к очень серьезным последствиям, и потому требующее его внимания, а зачастую и вмешательст-ва. В АСУТП и в системах ПАЗ особенно различают подтвержденные и неподтвержденные тревожные сообщения. Сообщение считается подтвержденным после того, как оператор отреагировал на него, как минимум, квитировал. До этого сообщение считается неподтвержденным.
Тревожные сообщения в современных SCADA-сис-темах различных производителей/разработчиков, как правило, делятся на два типа:
- ворнинги (от англ. Warning – предупреждение);
- алармы (от англ. Alarm – тревога).
Алармы
В большинстве современных средах программирования прикладного ПО, средах разработки SCADA-систем, наряду с другими подсистемами имеется подсистема алармов. Что это такое? Зачем она нужна? От эффективности подсистемы алармов зависит скорость идентификации неисправности, возникшей в системе, или технологического параметра, вышедшего за установленные регламентом граничные уставки. Быстродействие и надежность этой подсистемы помогают существенно повысить безаварийность и непрерывность технологического процесса и сократить время простоя технологического, энергетического оборудования. Подсистема алармов – это обязательный компонент любой современной SCADA-системы. Различают аналоговые и дискретные алармы в SCADA-системах.
Аналоговые алармы базируются на анализе выхода значений переменной за заданные/сконфигурированные верхние и нижние пределы. Аналоговые алармы задаются в нескольких комбинациях:
- аварийный верхний (HH – High High);
- аварийный нижний (LL – Low Low);
- Deviation (отклонение от нормы);
- RoC – Rate of Change (скорость изменения парамет-ра).
В отличие от алармов типа HH, когда выдаются аварийные сообщения при достижении уставки (Setpoint) только при возрастании значения переменной, и алармов типа LL, когда выдаются аварийные сообщения при достижении уставки только при понижении значения переменной, для алармов типа Deviation формируются аварийные сообщения как при повышении переменной выше заданного значения (Setpoint), так и при понижении ниже Setpoint. При этом заданное значение в ходе технологического процесса может изменяться либо оператором, либо программно (автоматически).
Алармы RoC срабатывают, когда скорость изменения параметра становится больше предельно допустимой, например, при резком повышении давления при вскипании среды, тогда как этот параметр должен плавно повышаться или изменяться по заданному алгоритму. Понятие «зона нечувствительности» (Deadband) к алармам этого типа не применяется.
Дискретные алармы срабатывают при изменении состояния дискретной переменной. При этом для срабатывания аларма можно использовать любое из двух состояний: 1 (TRUE или ON) или 0 (FALSE или OFF). По умолчанию или в зависимости от конфигурации входного канала АСУ аварийное сообщение может выдаваться на ON или OFF, так же это можно сконфигурировать в конкретной SCADA-системе.
При программировании прикладного ПО и/или при конфигурации системы задаются зоны нечувствительности (Deadband), задержки времени выдачи алармов (Delay), гистерезис, т.е зона возвращения контролируемого параметра к нормальному состоянию (только для аналоговых алармов).
Подсистема алармов поддерживает два типа алармов: аппаратные и конфигурируемые. Аппаратные алармы призваны информировать оператора о неисправностях, возникающих в микропроцессорных устройствах АСУТП (Hardware): контроллерах, серверах, модулях ввода/вывода, АРМах, панели HMI, сетевом оборудовании и т.д. Аппаратные алармы выдаются в результате самодиагностики как собственного состояния системы управления АСУ, так и всего перефирийного оборудования, независимо от оператора. Эта функция самодиагностики является встроенной по умолчанию и не нуждается в конфигурировании. А все алармы, вызываемые выходом значений технологических параметров за допустимые границы, неисправностью оборудования, срабатыванием оборудования ПАЗ и т.д. и которые необходимо предварительно конфигурировать, относятся соответственно к конфигурируемым алармам [2].
Описание проблемы
В последней трети прошлого века, начале 2000-х годов нашего века, когда у нас в стране использовались щитовые системы управления с аналоговыми приборами, регуляторами и регистраторами, имелась некая проблема человеческого фактора. В помещении операторных/диспетчерских были целые стены с панелями, щитами, плотно заполненными различными приборами (показывающими, сигнализирующими и регистрирующими), лампами, табло, блинкерами и т.д. У оператора, что называется, «глаза разбегались», очень сложно было уследить за всеми показаниями и сигнализациями и тем более оперативно определить и отреагировать на первопричину при цепных, взаимосвязанных блокировках и отключениях.
С развитием автоматизированных систем управления производством на базе цифровой микропроцессорной техники, с внедрением визуализации технологичес-ких процессов на АРМах операторов (компьютерные мониторы и даже видеостены), с внедрением SCADA-систем на объектах ОПО поначалу указанная проблема, связанная с человеческим фактором, исчезла – электроника и ПО пришли на помощь человеку. Упростилось восприятие, улучшилась эргономика, все основные необходимые параметры и данные о процессе теперь перед глазами в одном месте. Но, как говорится, все хорошо в меру. С бурным развитием систем АСУТП, с развитием их быстродействия и вычислительной мощности и одновременно со снижением относительной стоимости одного условного входного канала АСУТП, у заказчиков (пользователей Системы) появилось вполне объяснимое желание видеть и контролировать как можно больше параметров, иметь информацию обо всем, что только можно измерить и зафиксировать на объекте управления, даже самые незначительные и некритические, чисто информационные сигналы. Сейчас количество точек контроля (тэгов) зависит только от финансовых возможностей заказчика системы. А количество сигнализаций SCADA-системы на особо сложных производствах сейчас может достигать 3500…4000 на человека-оператора [3].
Технически теперь все это легко реализовать: не нужны физические лампочки, табло, блинкеры и щитовые приборы, не нужны физические кнопки и переключатели. Достаточно изменить цвет определенной зоны, добавить анимации и мигания с различной частотой на мониторе АРМа оператора. Однако возможности восприятия человека не безграничны, и с ростом числа сигнализаций и тревожных сообщений вновь появляется проблема человеческого фактора – «невозможность оперативно и адекватно воспринимать, контролировать большое количество сигнализаций, сообщений, алармов и соответствующим образом реагировать на каждый из них». Особенно это актуально, когда на мониторах АРМов кроме главной экранной схемы много других экранных форм/вкладок, таблиц и журналов сообщений. А в случае остановки технологического процесса полностью или частично начинается лавинообразный обвал параметров, цепные отключения и вал алармов и сигнализаций. Человек не в состоянии сориентироваться в ситуации, когда на экраны мониторов за несколько минут выводятся 200…300 и более сообщений. Тем более, не в состоянии сразу определить первопричину сбоя и предпринять соответствующие оперативные действия. Потом, конечно, по журналам событий из архивного сервера можно восстановить первопричину аварийной ситуации, но останов уже произошел, а в связи с нештатной ситуацией и аварийном останове большое количество исходной, промежуточной или конечной продукции сбросили на свечу или в дренаж, простаивало дорогостоящее оборудование, вновь производились сложные и энергозатратные процедуры запуска установки (продувка, прогрев и т.д.), недоотпуск продукции и т.д. и т.п. И все это в лучшем случае, а может такая ситуация на ОПО привести и к аварии с человеческими жертвами и к экологической катастрофе.
И все это может произойти, когда в потоке одинаковых сигнализаций и сообщений, некритичных и чисто информационных, затеряется тот действительно критически важный аларм противоаварийной защиты, оперативное и своевременное реагирование на которое оператором предотвратит дальнейшее опасное или нежелательное развитие ситуации.
Приоритеты алармов
В современных средах программирования прикладного ПО, средах разработки SCADA-систем подсистема алармов позволяет устанавливать приоритеты алармов, а также конфигурировать группы алармов. Каждая переменная связывается с какой-либо группой алармов, группы определяются разработчиком или пользователем и могут быть объединены в иерархическую структуру. Это позволяет сгруппировать алармы в зависимости от их организации, принадлежности к технологическим блокам, территориального размещения оборудования и любых других признаков.
Каждому аварийному сообщению в подсистеме алармов можно присвоить некоторое значение, называемое приоритетом аларма. Этот приоритет характеризует важность данного аларма, опасность события, вызвавшего срабатывания этого внутрисистемного сообщения. В среде разработке SCADA-системы InTouch (компания Wonderware, США) приоритет аларма может принимать значение от 1 до 999. По умолчанию сконфигурировано четыре диапазона приоритетов [4]:
- критические алармы – диапазон приоритетов от 0 до 249;
- существенные алармы – диапазон приоритетов от 250 до 499;
- несущественные алармы – диапазон приоритетов от 500 до 749;
- информационные алармы – диапазон приоритетов от 750 до 999.
В средах разработки WinCC, WinCC-Flexible (компания Siemens AG, Германия) можно сконфигурировать до 16 уровней (диапазонов) приоритетов алармов.
У некоторых современных производителей аппаратных и программных компонентов АСУТП применительно к опасным и взрывоопасным объектам разработаны и сертифицированы в РФ специальные программные пакеты, приложения к SCADA-системам этих произ-водителей, позволяющие управлять и ранжировать сообщения и алармы от системы ПАЗ. Например, Инструментальное приложение управления сообщениями Triconex Safety View от компании Schneider Electric [3] или Пакет анализа тревожных сообщений Explog от компании Yokogawa Electric. Но эти приложения – только программный инструмент, облегчающий программисту-разработчику прикладного ПО и инженеру АСУТП, эксплуатирующему Систему, управлять и распределять по приоритетам сообщения ПАЗ с уже разработанными алгоритмами и визуализацией. Это только удобный инструмент, эти приложения не распределяют автоматически сообщения и алармы (да и не смогут это сделать даже теоретически, хотя бы только потому, что каждый технологический процесс уникален, и невозможно создать какой-то универсальный алгоритм ранжирования на все случаи жизни) и соответственно именно человеку надо конфигурировать эти программные пакеты, присваивая каждому сообщению свой уровень приоритетности.
И тут мы подходим к главному вопросу: А кто определяет эти приоритеты? Исходя из какого принципа и каких соображений то или иное сообщение, выдаваемое SCADA-системой оператору, необходимо распределить по уровням критичности и опасности для конкретного технологического процесса? Автор за годы работы в сфере автоматизации не встречал каких-либо методик, рекомендаций, руководящих документов и т.д. по этому вопросу, устанавливающих или рекомендующих некий алгоритм, систему, правила присвоения приоритетности не только для нефтегазоперерабатывающих, химических производств и энергетики, но и для других менее опасных и менее критических производств. Решение этих важных вопросов для каждого конкретного проекта отдано на откуп субъективным личным мнениям инженеров – программиста и технолога – проектировщика установки. В лучшем случае согласуется с заказчиками (будущими эксплуатационщиками технологической установки и АСУТП). Но обычно на стадии создания АСУТП со SCADA разработчики предпочитают «не заморачиваться» и просто игнорируют эту проблему, что может в будущем привести к последствиям, описанными выше.
Далее автор берет на себя смелость составить алгоритм присвоения приоритетности алармов системы ПАЗ, выдаваемых оператору/диспетчеру посредством SCADA-системы. Алармы сгруппированы в пять уровней приоритетности, которым при разработке ПО визуализации (если это не готовое приложение) можно придать различные свойства человеко-машинного интерфейса: различные яркости свечения и частоту мигания (цвет, как правило, остается один – красный), различные тональности звукового сигнала, индикация цифры, соответствующей уровню приоритета и т.д. Автор не претендует на «абсолютную истину» своей системы ранжирования, у каждого проектировщика или эксплуатирующего, обслуживающего технического персонала может быть свое, отличное от автора, мнение по принципу распределения алармов, исходя из их опыта и знаний. К тому же, повторюсь, в современных сложных производствах нет совершенно одинаковых технологических процессов, каждая конкретная технология уникальна, применяется различное оборудование даже на типовых лицензированных технологиях или типовые технологии работают в разных условиях, различных климатических зонах, различная конфигурация межблочных связей и т.д.
Итак, примерный перечень алармов системы ПАЗ с разделением по уровням приоритета:
1-й приоритет (высший)
1.1. Сигнал «ПОЖАР» от системы АПС (кроме указанных в п.2.1);
1.2. Сигнал «Shutdown/Аварийный СТОП» от агрегатов/динамического, вращающегося оборудования (компрессоры, детандеры, насосные агрегаты, ГТУ, дымососы и т.д.) мощностью более 250 кВт и/или стоимостью более $1 млн;
1.3. Сигнал «Загазованность/превышение ДВК» в зонах 0 и 1 по МЭК 60079-0–2011 (зоны ВI, ВII по ПУЭ);
1.4. Предельное превышение какого-либо параметра или иное событие, способное вызвать цепную реакцию отключений и блокировок всей технологической установки или ее части;
1.5. Превышение предельно допустимых давлений в емкостях, колоннах или иных сосудах, работающих под давлением 16 МПа и выше;
1.6. Превышение предельно допустимых температур в реакторах, печах, криогенном оборудовании.
2-й приоритет
2.1. Сигнал «ПОЖАР» в отдельно стоящих блок-боксах/модульных зданиях:
- компрессорных воздуха КИП и азота;
- насосных (водяных, канализационных, щелочных и других не взрывопожароопасных сред);
- модульных отопительных или водогрейных котельных;
- вспомогательных помещений и складов негорючих материалов;
- трансформаторных, электрораспределительных устройствах, находящихся вне взрывоопасных зон.
2.2. Сигнал «Shutdown/Аварийный СТОП» от агрегатов/динамического, вращающегося оборудования (компрессоры, детандеры, насосные агрегаты, АВО, дымососы, воздуходувки и т.д.) мощностью от 75 до 250 кВт;
2.3. Сигнал «Загазованность/превышение ДВК» в зоне 2 по МЭК 60079-0–2011 (зоны ВI-а ВI-б ВI-г, BII-a по ПУЭ );
2.4. Сигнал «Загазованность/превышение НКПР» (вредных, отравляющих веществ);
2.5. Сигнал «Авария/неисправность» системы пожарной сигнализации (АПС) контролирующей: контроллерные, серверные, аппаратные, технологические установки и резервуарные парки с взрывоопасными средами;
2.6. Сигнал «Авария/неисправность» систем пожаротушения (АПТ) защищающих контроллерные, серверные, аппаратные, технологические установки и резервуарные парки с взрывоопасными средами;
2.7. Превышение предельно допустимых давлений в емкостях, колоннах или иных сосудах, работающих под давлением от 10 до 16 МПа.
3-й приоритет
3.1. Сигнал «Авария общая/неисправность» системы факельного хозяйства;
3.2. Сигнал «Авария общая/неисправность» отдельных технологических блоков/агрегатов/установок, например:
- осушки газа (УОГ);
- установки регенерации паров (УРП);
- газового компрессора или детандера;
- насоса перекачки нефти;
- ЭЛОУ нефти;
- установки налива нефтепродуктов, СУГ;
и т.п.;
3.3. Сигнал «Shutdown/Аварийный СТОП» от агрегатов/динамического, вращающегося оборудования (насосные агрегаты, АВО, дымососы, воздуходувки и т.д.) мощностью от 15 до 75 кВт;
3.4. Сигнал «Загазованность/превышение НКПР» (азот, СО2);
3.5. Падение давления в системе воздуха КИП;
3.6. Превышение предельно допустимых давлений в емкостях, колоннах или иных сосудах, работающих под давлением от 1,6 до 10 МПа или вакуумных.
4-й приоритет
4.1. Авария электроснабжения, силового электропитания;
4.2. Авария ИБП систем АСУТП, локальных САУ;
4.3. Авария общая/неисправность систем громкоговорящей связи, оповещения;
4.4. Авария общая/неисправность систем электрообогрева (трубопроводов, технологического оборудования, оборудования КИП);
4.5. Превышение предельно допустимых уровней в колоннах, емкостях, сепараторах и т.д.;
4.6. Превышение давлений в емкостях, колоннах или иных сосудах, работающих под давлением менее 1,6 МПа;
4.7. Превышение предельно допустимых других параметров (температура, расход, уровень, качественный состав и т.д.), из-за которых возможно возникновение опасной или нештатной ситуации или частичная остановка технологического процесса.
5-й приоритет (низший)
5.1. Авария/неисправность частотных преобразователей насосов, АВО, воздуходувок и т.д., которые управляют оборудованием системы ПАЗ;
5.2. Авария насосов мощностью до 15 кВт, электрозадвижек, исполнительных механизмов (сухой ход, перегрев, заклинивание и т.д.), которые относятся к оборудованию системы ПАЗ;
5.3. Сигнал «Аварийный СТОП» насосов мощностью до 15 кВт, электрозадвижек, исполнительных механизмов, которые относятся к оборудованию системы ПАЗ;
5.4. Авария системы наружного электроосвещения;
5.5. Авария систем вентиляции, кондиционирования, отопления;
5.6. Авария систем электроснабжения, ИБП слаботочных систем (кроме АПС и АПТ), например, телефония, видеонаблюдение, СКС и т.д.
Заключение
На сложных ОПО с большим количеством точек контроля и сигнализаций, с многоэкранной и сложной SCADA необходимо внедрять ранжирование тревожных и аварийных сообщений/сигнализаций, что обеспечит точную и быструю ориентировку и поможет принять правильное и своевременное решение в сложной нештатной ситуации. Это минимизирует аварийные ситуации, аварийные остановки оборудования, сброс продукции на свечу или в дренаж, простои технологического оборудования, пуски оборудования и т.д. В конечном итоге это положительно отражается на финансовой деятельности и бизнес-процессах всего предприятия. Необходимо также исправлять ситуацию с отсутствием каких-либо нормативных документов, методик, правил или инструкций по принципам и алгоритмам ранжирования по степени опасности аварийных и тревожных сигнализаций.
Список литературы
- Федоров Ю.Н. Основы построения АСУТП взрывоопасных производств. Т. 2. Проектирование. Глава 13.16 Уровни сигнализации. Определения; Глава 16.22. Методы снижения числа оповещений. М.: Изд-во СИНТЕГ, 2006.
- Андреев Е.Б., Кунцевич Н.А., Синенко О.В. SCADA-системы: взгляд изнутри. М.: Изд-во «РТ-Софт», 2004.
- Огорельцев Е.В. ПАЗ на базе Triconex Safety View: новый взгляд на эксплуатацию опасных производственных объектов//Автоматизация и IT в нефтегазовой области. 2017. №1 (27). С. 48–51.
