Прецедентный подход к управлению инцидентами в автоматизированных системах управления технологическими процессами

Концепция системы прецедентного управления

Когда речь идет о проектировании и синтезе автоматизированных систем управления, обычно не упоминается о необходимости управления техническими средствами, которые входят в состав систем управления. Однако, техническая инфраструктура также является объектом, которым необходимо управлять ^[1,2], чему уделяется недостаточно внимания в специализированной литературе по АСУТП. Таким образом, проектирование автоматизированных систем управления (АСУТП) должно включать в себя как минимум два связанных друг с другом уровня управления:

1) Управление технологическим объектом.

2) Управление программно-технической инфраструктурой, которая входит в состав АСУТП.

Недооценка подобной необходимости может привести в итоге к тяжелым последствиям, ведь известно, что затраты на сопровождение программно-технических средств по оценкам независимых аналитических агентств, может составлять от 40 до 60% от общей стоимости проекта. Простои систем, затраты на инфраструктуру в конечном итоге будут только возрастать.

Существуют известные содержательные и формализованные подходы к управлению технической инфраструктурой, при предоставлении ИТ-услуг ^[3,4,5] и разработке ИТ-решений, из которых можно выделить ITILv3, MOF v.4, COBIT, здесь не ставится цель их подробного описания и анализа. Общая идея заключается в том, что некоторые типовые процессы (допустим, управление инцидентами), прекрасно подходят для автоматизированных систем управления различного назначения.

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

Построение современных систем АСУТП связано с использованием технических средств последнего поколения (датчики, аналоговые и дискретные модули связи, промышленные контроллеры), можно выделить решения от компаний ОВЕН, Siemens, Omron, Schneider electric, Rockwell automation, Allen bradley. Рассматривая управление сложными системами, следует выделить объективные тенденции, связанные в первую очередь с насыщением современных систем большим количеством программно-технических средств. Если рассматривать техническую инфраструктуру как часть объекта управления (которой она и является), закономерно возникает задача управления инфраструктурой, поскольку возникает потребность снижения издержек на всех этапах жизненного цикла таких систем.

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

Рисунок 1 – Структура системы управления инцидентами

На рисунке приведены следующие обозначения: – вектор действительных неконтролируемых возмущений, – вектор действительных контролируемых возмущений; - управляющие воздействия; – консолидирующий вектор, – соответствующие множества поступающих в систему управления инцидентов и хранящихся в библиотеке прецедентов.

Поясним работу прецедентной системы управления на конкретном примере. Допустим, при возникновении нового инцидента получена определенная окружающая обстановка , когда измененному положению дел соответствуют текущие измеренные значения многопараметрического вектора . Также, с инцидентом связан технический элемент (идентификатор) узла {ID} и признак неисправности . По сути, каждый новый инцидент – это отдельный факт, когда для известной (измеренной) обстановки зафиксирован отказ оборудования или выход за пределы допустимых значений некоторого технологического параметра. Таким образом, поступающий в систему инцидент описывается набором параметров и, возможно, дополнительной информацией. Задача прецедентного управления заключается в данном случае в том, чтобы найти в библиотеке конкретный прецедент, который аналогичен текущей ситуации и может быть использован для выбора решения. Следовательно, при возникновении нового инцидента необходимо сопоставить вновь наступившие и ранее известные факты, что позволит использовать выбрать уже известный прецедент из библиотеки. Для выбора допустимого прецедента из библиотеки может использоваться некоторая функция подобия , которая позволяет оценить, насколько близка реальность, при которой возник инцидент ранее зафиксированным случаям.

Для более простых случаев, можно использовать подход при выборе прецедента из библиотеки в соответствии с выражением (1):

(1)

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

Хранимый в библиотеке прецедент состоит из:

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

Принятие управленческих решений с использованием прецедентного подхода включает в себя четыре основных этапа, которые образуют CBR-цикл ^[1] (рассуждения на основе прецедентов), из них выделим следующие:

• Извлечения множества подобных прецедентов из базы данных;
• Выбор прецедента для решения проблемы по принципу «наиболее близкого совпадения».
• Повторное использование прецедента (решение) для обработки вновь поступившего инцидента.
• Анализ, адаптация и пересмотр решения и проверка его на допустимость.
• Сохранение измененного решения как части нового прецедента.

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

Реализация системы прецедентного управления на примере ТЭЦ

Необходимость управлять инцидентами и происшествиями для сложного технологического объекта (такого как ТЭЦ) очевидна. Важнейшая задача управления инцидентами заключается в оперативном восстановлении работоспособности программно-технических средств автоматизации (УСО, PLC, SCADA), которые в свою очередь обеспечивают работу технологического оборудования (котельных агрегатов, турбогенераторов, редукционно-охладительных установок и т.д.).

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

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

Рассматривается разработка и внедрение системы управления инцидентами в существующей системе АСУТП (Западно-Сибирская ТЭЦ - филиал ОАО «ЕВРАЗ ЗСМК»), архитектура предлагаемого технического решения представлена на рисунке 2.

Рисунок 2 – Изменения в действующей структуре АСУТП ТЭЦ

1 – контрольно - измерительные приборы и автоматика; 2 – программируемый логический контроллер; 3 – SCADA-система; 4 – модуль генерации сообщений в базу данных (БД) Service Desk; 5 – модуль генерации сообщений в базу данных центра обработки данных; 6 – БД Service Desk; 7 – БД центра обработки данных; 8 – рабочие станции инженеров по обслуживанию АСУТП с программным модулем SD client; 9 – средство корпоративной мобильной связи инженеров по обслуживанию АСУТП (GSM-телефон); 10 – пользователи доменной сети (мастера, главные специалисты, начальники цехов, главный инженер, директор).

В представленной на рисунке 2 схеме добавлен уровень управления технологической инфраструктурой. Процесс устранения инцидента включает в себя следующие шаги:

• Получение значений технологических параметров от источников данных;
• Анализ значений параметров на наличие инцидента;
• Регистрация инцидента;
• Категоризация (классификация) инцидента;
• Определение приоритета инцидента;
• Отправка сообщения об инциденте;
• Закрытие инцидента.

Внедрение автоматизированной системы управления инцидентами на базе программных продуктов STI_Server, STI_Viewer, тесно интегрированных с комплексной системой сервисного обслуживания HP Open View Service Desc 4.5 позволило сократить время обслуживания инцидентов в среднем на 10-15%, что привело к повышению эффективности работы ТЭЦ.

Заключение

Итоги внедрения системы управления инцидентами применительно к Западно-Сибирской ТЭЦ - филиалу ОАО «ЕВРАЗ ЗСМК»:

− увеличилась оперативность реакции персонала цехов на инцидент;

− статистический анализ по типам инцидентов способствует разрабатывать корректирующие мероприятия;

− снизилась вероятность хищения технических средств автоматизации, в том числе коммутационных материалов;

− появилась возможность разработки и дальнейшего расширения базы знаний по идентификации инцидентов, сигнатурам девиации поведения параметров для заблаговременного предупреждения об инциденте, способам его устранения.