Интеллектуальные системы оповещения

[vlasovdl]

Речь идет о сообщениях формируемой системой (Alarm) и выдаваемой оператору.

На всех ситемах автоматизации, что мне довелось видеть построено примерно следующим образом: алармы формируются как результат события изменения состояния дискретного сигнала или перехода определенной границы (HH, H, L, LL) аналоговым сигналом. Существуют различные дополнения к данному подходу (контроль скорости изменения аналогового сигнала, введение гистерезиса, задержки и пр.) повышающие возможность отфильтровать несущественные события без формирования соответствующего сообщения. Для сообщений возможна установка приоритетов, возможна установка направлений выдачи сообщений (на определенную станцию оператора, принтер, звуковой оповещатель). Однако всегда производится привязка к состоянию контретного сигнала. К сожалению , привязка к единому сигналу не дает возможности учесть технологическую ситуацию в которой изменение этого сигнала происходит.
Поясню на примере. Существует насос, нормальное технологическое состояние которого - работать. Останов данного насоса - в большинстве случаев является опасным для технологического процесса. Разумеется данная систуация обрабатывается алгоритмом ПАЗ и оператору должно выводится сообщение с высоким приоритетом. Типовое решение разработчика - сконфигурировать аларм по изменению состояния дискретного сигнала НасосВключен (ON OFF). Теперь при каждом останове этого насоса оператор будет соответствующим образом оповещен.

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

Хотелось бы узнать, уважаемое Сообщество, насколько такая проблема актуальна? Какие варианты борьбы с ней можно предложить?

[VADR]

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

[andrmur]

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

Какая система у Вас применяется?

[Jackson]

Мне кажется, тот подвох кроется в том, какая подсистема генерирует аларм. Если у насоса есть своя локальная САУ (подсистема) и она и генерирует все алармы по этому насосу, то проблема легко решается алгоритмом этой локальной САУ.

Вот пример из моей отрасли. Имеем электростанцию из 4 агрегатов, на каждом агрегате стоит своя локальная САУ на базе специализированного генераторного контроллера. Имеем аларм "низкая частота генератора". Понятно, что когда генератор стоит, этот аларм бессмысленный, как и другие алармы (низкое давление масла, низкое напряжение генератора, низкая частота вращения и т.п.). Поэтому в контроллере генератора локально реализован алгоритм подавления алармов (Inhibits), который грубо включает или отключает генерацию аларма по каждому контролируемому параметру по определенным условиям. В примере, если от генератора не получено сигнала "работа" (этот сигнал формируется по ряду признаков), то те алармы что я перечислил для примера не генерируются. Верхний уровень сам алармы не генерирует (точнее генерирует только 1 аларм для каждого агрегата - потеря связи с САУ генератора), а лишь обрабатывает алармы, прилетевшие "снизу" - в этом случае при штатных пусках/остановах "лишних" алармов оператор не видит.

Если же ПАЗ независимо от прочих систем и подсистем - как ей и положено - сама генерирует все алармы, то вносить алгоритмические блокировки алармов в ПАЗ мне лично кажется небезопасным делом.

Т.е. моя мысль в том, что необходимо продумывать алгоритмы подавления алармов в локальных САУ, и уже на основе их должны работать все остальные системы, включая ПАЗ. Однако, поскольку ПАЗ по определению д.б. независима от других систем, этот вопрос надо тщательно продумать. Т.е. всё решаемо, но аккуратно.

[vlasovdl]

В нашем зоопарке несколько систем: Simatic/WinCC, ABB Modcell/Citect, но основное технологическое оборудование управляется под Foxboro I/A Series (РСУ) в связке с Tricon (СПАЗ).

Практически все управление реализовано в СПАЗ. РСУ обеспечивает человеко-машинный интерфейс и ПИД-регулирование и управление клапанами. Логика управления технологическим оборудованием реализована в СПАЗ но получает команды от оператора из РСУ. Т.о. если оператор дает комаду на открытие задвижки или включение насоса, то не факт, что это произойдет. СПАЗ может не позволить это сделать. Такое построение позволило реализовать принцип независимости функционирования СПАЗ от работоспособности РСУ (и частично от адекватности действий оператора).
Обе системы автоматизации общепромышленного применения. Т.е. они ничего "не знают" про насосы, теплообменники, колонны, печи и пр. Есть дискретные и аналоговые сигналы ввода/вывода и типовые блоки логического и непрерывного управления (логические функции, триггеры, ПИД-регуляторы и пр.). Т.е. обычный конструктор.

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

Управление алармами осуществляется в РСУ. В случае с насосом СПАЗ просто перенаправляет дискретный сигнал о включении насоса в РСУ. А та, в свою очередь, устанавливает аларм по событию изменения сигнала с 1 на 0. В I/A Series так же как в приличных системах существует возможность отключать выдачу алармов. И даже можно это делать динамически, но нет возможности скорректировать текст аларма, либо изменить приоритет.

Пост Евгения Брониславовича натолкнул меня на одну мысль. Действительно аларм, или то что его инициирует должно формироваться в системе, владеющей максимальной информацией об объекте. В его случае это локальная САУ генератора. А в моем случае это СПАЗ. Поскольку СПАЗ знает почему и зачем он отключает насос то пусть передает в РСУ не один сигнал об отключении насоса, а несколько: Неожиданное_отключение, Отключение_Оператором, Отключение_Алгоритмом, Отключение_Не_произошло. Для всех сигналов должны быть установлены свои алармы со своими приоритетами. При чем первое и последнее должно иметь высший приоритет, а второе и третье должно подаваться как информационное сообщение.

Фильтрация сообщений должна основываться на понятии "состояние объекта". В случае Е.Б. это сигнал "работа".

[VADR]

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

Зачем типовой техпроцесс? Ведь почти в любом техпроцессе есть такой элемент, как двигатель. Есть его характеристики: тип запуска (тип запуска - с удержанием или импульсный), наличие/отсутствие измерения тока (и его предельные значения), допустимое время запуска (в течение которого ток асинхронника должен упасть с пускового режима на рабочий), ну и много еще чего. Аналогичная ситуация - клапаны типа МЭО (правда, в последнее время их не так часто ставят), задвижки электроприводные многооборотные и т.д. и т.п. Для каждого из таких стандартных агрегатов может быть определен (у нас определен) набор стандартных элементов системы управления. Один - собственно модуль системы управления, реализующий функции включения/выключения/блокировок и т.п., другой - модуль операторского интерфейса, третий - модуль обработки событий и алармов... И никакой типовой техпроцесс тут не нужен - у нас такие системы работают и в энергетике, и на варке целлюлозы, и на бумагоделательных машинах.
Такое построение позволяет не заниматься решением уже решенных задач, но и не лишено недостатков. В частности (то, что мне не нравится) - отсутствие возможности расширять функционал таких модулей. К примеру - стандартный модуль управления двигателем есть, а модуля управления двигателем с частотно-регулируемым приводом - нет. Приходится немного колдовать. Также нет и встроенной предпусковой подготовки - к примеру, сигнальчик дать на пуск наездника (который тоже по сути обычный двигатель).

Логика управления технологическим оборудованием реализована в СПАЗ но получает команды от оператора из РСУ. Т.о. если оператор дает комаду на открытие задвижки или включение насоса, то не факт, что это произойдет. СПАЗ может не позволить это сделать. Такое построение позволило реализовать принцип независимости функционирования СПАЗ от работоспособности РСУ (и частично от адекватности действий оператора).

А в обратную сторону СПАЗ доложит о том, почему пускать нельзя? Технологи среди ночи не начнут консилиум собирать из АСУшников, электриков и иже с ними (и с нами :) )?

[Jackson]

Логика управления технологическим оборудованием реализована в СПАЗ но получает команды от оператора из РСУ. Т.о. если оператор дает комаду на открытие задвижки или включение насоса, то не факт, что это произойдет. СПАЗ может не позволить это сделать. Такое построение позволило реализовать принцип независимости функционирования СПАЗ от работоспособности РСУ (и частично от адекватности действий оператора).

А в обратную сторону СПАЗ доложит о том, почему пускать нельзя? Технологи среди ночи не начнут консилиум собирать из АСУшников, электриков и иже с ними (и с нами :) )?

Вопрос хороший. :) Если параметров, по значениям коорых СПАЗ выдает или не выдает разрешение на запуск того или иного механизма, то оператор должен точно знать, почему именно СПАЗ не разрешила пуск. В нашей сфере тоже есть такой алгоритм: запрос на включение мощных электропотребителей. Оператор посылает в АСУ электростанции запрос на включение потребителя, АСУ смотрит есть ли резерв мощности в электростанции, если его нет то пытается запускать резервные генераторы и в итоге, если резерв мощности таки найден - АСУ сама включает потребитель, а если резерв не найден (резервных генераторов нет либо их запуск не удался) - сообщает о том, что включение невозможно. Но тут всё просто, потому что параметр всего один - резерв мощности. А в случае серьезного технологического алгоритма, где алгоритм проверки наличия достаточных условий будет разветвленым - это весьма непростая задача выделить именно те условия, по которым оператор правильно поймет, что поисходит в системе, что ему нужно сделать чтобы осуществить желаемое, а чего делать нельзя, и при этом информация должна быть компактной. И к тому же желательно при этом чтобы информация была полной, чтобы оператор получил сразу перечень всех блокирующих условий, а не последовательно одно за другим. Система оповещения получается действительно интеллектуальной.

Тут, полагаю, надо плясать от конкретного объекта, т.к. "контрольные" параметры в каждом процессе свои.

[VADR]

Логика управления технологическим оборудованием реализована в СПАЗ но получает команды от оператора из РСУ. Т.о. если оператор дает комаду на открытие задвижки или включение насоса, то не факт, что это произойдет. СПАЗ может не позволить это сделать. Такое построение позволило реализовать принцип независимости функционирования СПАЗ от работоспособности РСУ (и частично от адекватности действий оператора).

А в обратную сторону СПАЗ доложит о том, почему пускать нельзя? Технологи среди ночи не начнут консилиум собирать из АСУшников, электриков и иже с ними (и с нами :) )?

Вопрос хороший. :) Если параметров, по значениям коорых СПАЗ выдает или не выдает разрешение на запуск того или иного механизма, то оператор должен точно знать, почему именно СПАЗ не разрешила пуск. В нашей сфере тоже есть такой алгоритм: запрос на включение мощных электропотребителей. Оператор посылает в АСУ электростанции запрос на включение потребителя, АСУ смотрит есть ли резерв мощности в электростанции, если его нет то пытается запускать резервные генераторы и в итоге, если резерв мощности таки найден - АСУ сама включает потребитель, а если резерв не найден (резервных генераторов нет либо их запуск не удался) - сообщает о том, что включение невозможно. Но тут всё просто, потому что параметр всего один - резерв мощности.

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

[Jackson]

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

Все правильно. Только применительно к электростанции конкретная причина отказа генератора вторична и мало кого волнует, первичен сам отказ (или просто невозможность запуска) и первой реакцией будет запуск и ввод резерва. А с причинами будут разбираться механики уже потом.
Вы представтье, если оператор в данном примере - судоводитель, у него отказ электростанции. Уж поверьте, ему ровно поровну перегрелся приводной двигатель, закончилось топливо в расходном танке или произошел аварийный останов. Ему нужно электропитание и срочно - 45 секунд обесточивания судна в узкости легко приводит к катастрофе, что не раз, к сожалению, случалось. В этот момент штурману получить полную расшифровку неисправности с точным указанием в каком месте какая срезалась шпонка - бред. :) Ему электричество нужно для управления, а не объяснение почему его нет. Объяснение он потом посмотрит.

Я о том и говорил, что в каждой сфере своя специфика, тут общего решения видимо нет.

[VADR]

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

Все правильно. Только применительно к электростанции конкретная причина отказа генератора вторична и мало кого волнует, первичен сам отказ (или просто невозможность запуска) и первой реакцией будет запуск и ввод резерва. А с причинами будут разбираться механики уже потом.
Вы представтье, если оператор в данном примере - судоводитель, у него отказ электростанции. Уж поверьте, ему ровно поровну перегрелся приводной двигатель, закончилось топливо в расходном танке или произошел аварийный останов. Ему нужно электропитание и срочно - 45 секунд обесточивания судна в узкости легко приводит к катастрофе, что не раз, к сожалению, случалось. В этот момент штурману получить полную расшифровку неисправности с точным указанием в каком месте какая срезалась шпонка - бред. :) Ему электричество нужно для управления, а не объяснение почему его нет. Объяснение он потом посмотрит.

Тут в принципе можно было бы разделить операторские функции - судоводителю (кто там? штурман?) - информация об отказе и готовности, а мотористам (или как там БЧ-5 на гражданских судах называется?) - подробрую расшифровку по агрегату. Хотя я в данной специфике не копенгаген, может, и ерунду говорю.

Я о том и говорил, что в каждой сфере своя специфика, тут общего решения видимо нет.

Естественно.

[Вован]

Все так тщательно запутано... Но мысль прослеживается. И очень приятно было услышать в конце "в каждой сфере своя специфика, тут общего решения видимо нет". Именно и только так. И даже в типовых проектах типовых объектов ктрл-ц ктрл-в лучше не допускать. Типовые АСУ ТП это как близнецы-братья: похожи - не различить. А сердце - у каждого свое...