Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

СПКД123 / СПДК / Задачи АСУТП / Диспетчерский пункт АСУТП. Система тревог

.doc
Скачиваний:
87
Добавлен:
04.03.2016
Размер:
284.16 Кб
Скачать

Диспетчерский пункт АСУТП. Система тревог

Содержание лекции:

  • Понятие «тревоги». Типизация ситуаций

  • Передача тревог между процессами ДП АСУТП

  • Определение тревоги в БД. Процессор тревог как конечный автомат

  • Пример составления таблицы переходов состояний

  1. Понятие «тревоги». Типизация ситуаций

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

  • Логическая. Отслеживается изменение состояния логического сигнала «включен/выключен».

  • N-состояний. В возможном диапазоне изменения значений вводится N поддиапазонов, классифицирующих состояние измеряемой величины.

  • Изменение величины. Любое изменение некоторого дискретного значения (например, приращение счетчика) приводит к генерации тревоги. 

Для иллюстрации рассмотрим изменение аналогового сигнала (см. рис. 7.1) с диапазоном измерения датчика от 0 до MAX. Однако оптимальный режим технологического процесса требует, чтобы значение измеряемого параметра находилось в диапазоне от 0,4 до 0,75 МАХ, при значениях от 0,2 до 0,9 МАХ технологический процесс протекает неоптимально, при выходе и за этот диапазон возможно разрушение оборудования. Исходя из этого, мы можем определить четыре значения, которые определяют границы диапазонов состояний аналогового сигнала. Эти границы часто называют уставками, вводят наименования: верхняя аварийная уставка (ВАУ), верхняя предупредительная уставка (ВПУ), нижняя предупредительная уставка (НПУ), нижняя аварийная уставка (НАУ).  Рис. 7.1. Границы диапазонов состояний аналогового измерения.

  1. Передача тревог между процессами ДП АСУТП

Возникновение тревоги приводит к формированию сообщения, включающего метку времени, указание источника возникновения тревоги (последовательно: эксплуатационного участка, производственного объекта, его части, датчика) и его передаче всем заинтересованным получателям (см. рис. 7.2): подсистемам отображения, записи тревоги (сохранение в архиве, вывод на печать), планировщику задач; прочим пользовательским приложениям, использующим API программного комплекса для установления связи с сервером тревог. Отметим, что связь подсистемы отображения и сервера тревог – двунаправленная: оператор, увидев новое аварийное сообщение на дисплее, подтверждает его прочтение, что протоколируется сервером тревог и также фиксируется в архиве и на внешних носителях. Подтверждение также называется квитированием (англ.: acknowledgment) тревоги. Рис. 7.2. Передача тревог между процессами ДП АСУТП.

  1. Определение тревоги в БД. Процессор тревог как конечный автомат

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

  • state table – граф перехода состояний;

  • message – формат и правила динамического формирования сообщений;

  • send msg action – выполняемая передача сообщений;

  • exec cmd action – выполняемый запуск процессов;

  • write value action – выполняемые действия по записи значений в объекты БД.

  1. Пример составления таблицы переходов состояний

Рассмотрим обработку тревоги в случае для логического сигнала. Сигнал может принимать два значения: 0 или 1. При этом считаем, что 0 – нормальное состояние, 1 – аварийное. Также требуется различать состояния, требующие подтверждения и уже квитированные оператором. Тогда мы можем построить граф с пятью узлами (рис. 7.3). Четыре из них – возможные состояния сигнала, пятое – ошибочное (сервер тревог также должен генерировать сообщения при поступлении ошибочных, выходящих за допустимый диапазон входных данных). Возможно и объединение некоторых состояний в одной вершине графа.  Правила перехода между состояниями, выполняемые при этом действия, формируемые сообщения и пр. мы можем определить в табличной форме. Каждое состояние описывается одной строкой в таблице, номер текущего состояния – индекс строки. Столбцы соответствуют возможным действиям (изменениям состояний сигнала) – дугам графа; так, &VALUE=1 – изменение значения контролируемого атрибута, присваивание ему нового значения, равного 1, &ACK – подтверждение изменения состояния и т.п. Рис. 7.3. Граф перехода состояний логического сигнала. Тогда в ячейках таблицы определяем номера состояний конечного автомата, в которые он должен перейти из текущего при наступлении определенного события. Второй тип столбцов – выходные значения функции перехода, такие как необходимость подтверждения нового состояния, тип сообщения (информационное, предупредительное, аварийное) и проч. Для приведенного на рис. 7.3. графа таблица переходов состояний будет выглядеть следующим образом (см. Табл. 7.1). Увеличение количества вершин (например, для определения состояния аналогового сигнала) приведет к увеличению как числа строк таблицы, так и в росту количества возможных переходов. Для нашего примера, если текущее значение сигнала было 0, а поступило значение 1, алгоритм действий процессора тревог будет следующим: Табл. 7.1. Таблица перехода состояний логического сигнала.

№ состояния

ACK

VALUE=0

VALUE=1

VALUE<0

VALUE>1

ack req’d

seve-rity

0

0

4

2

0

0

0

0

1

1

1

2

0

0

0

5

2

3

4

2

0

0

1

1

3

3

1

3

0

0

0

4

4

1

4

2

0

0

1

1

  • Выполнить инициализацию процессора тревог. Перейти из состояния 1 в состояние 2.

  • Сформировать текстовое сообщение по шаблону, подставляя текущие время, значения атрибутов объектов БД (источник тревоги, сигнал, значение, достоверность).

  • Записать в объект БД значение 1 атрибута ack required – потребовать подтверждения.

  • Передать внутрисистемное сообщение модулю отображения, архивирования и проч.

1   2   3   4   5   6   7   8   9   10   ...   14

хорошо

   1