Функции основных блоков SCADA - системы

• Графической среды разработки и запуска приложений,
• Архивов,
• Аварий,
• Доступа
• Встроенных языков программирования

Графическая среда разработки и запуска приложении (GraphWorX32)

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

Основные характеристики GraphWorX32

• Мощные инструменты для создания экранных форм и динамических элементов отображения
• Возможность встраивания элементов управления ActiveX и объектов OLE
• Встроенная среда редактирования сценарных процедур Microsoft Visual Basic. Алгоритмы вторичной обработки данных и процедуры управления экранными формами могут разрабатываться в данной среде
• Динамизация элементов отображения с малым временем обновления (<50 мс)
• Поддержка шаблонов экранных форм, содержащих наиболее часто используемые слои графических объектов
• Возможность встраивания в HTML-страницы и другие контейнеры OLE (MS Word, MS Excel, MS Access и др.)
• Возможность просмотра браузерами Интернет, такими как MS Internet Explorer
• Обширная библиотека элементов отображения, ориентированных на построение мнемосхем промышленных объектов
• Поддержка графических слоев: один файл может содержать множество экранных форм
• Поддержка градиентов цветовой палитры, обеспечивающая возможность реализации объемной графики
• Возможность динамической смены источников данных во время исполнения посредством технологии псевдонимов
• Защита экранных форм паролем от внесения несанкционированных изменений
• Возможность встраивания графиков, журналов событий и тревог.
• Средства импорта графических метафайлов (WMF) и растровых изображений (BMP)
• Встроенный редактор выражений для выполнения математических, функциональных, логических и других операций над данными.

Единые принципы организации экранных форм предоставляют следующие преимущества:

• наглядность изображения;
• высокую информативность;
• низкую утомляемость.

Структура типовой экранной формы АРМ:

• общий светло-серый фон (~25%);
• в верхней части экрана отображается панель управления, на ней расположены чаще всего используемые кнопки, общие для всех мнемосхем  («Смена пользователя», «Общая сводка тревог» и «Тренды»);
• ниже панели управления располагается панель переходов с пиктограммами выбора экранов и стрелками переходов между формами;
• в нижней части экрана отображается окно тревожных и аварийных событий;
• в правой части экрана под панелью переходов отображаются индикаторы наиболее важных аварийных параметров и режимов;
• в левой верхней части экрана, на панели управления, приводится изображение логотипа;
• в правой верхней части экрана, на панели управления, дата и время;
• вверху по центру, на панели переходов, наименование объекта автоматизации;
• в центре текущая мнемосхема объекта автоматизации.

 Отображение объектов и параметров на мнемосхемах

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

• авария – красный цвет;
• ремонт, блокировка – синий цвет;
• недостоверность, неопределенность – тёмно-серый.

Для аналоговых измерений зарезервированными состояниями считаются:

• выход за предельное значение – жёлтый цвет;
• выход за аварийное значение – красный цвет;
• ремонт, блокировка – синий цвет;
• недостоверность, неопределенность – тёмно-серый.

В состоянии недостоверности вместо текущего значения отображается символы “ХХХ”.

Отображение параметров контроля технологического процесса

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

Рисунок – Типовая ячейка отображения параметра

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

• LoLo – значение меньше “Ниже нижнего порога”, красный цвет
• Lo – значение меньше “Нижнего порога”, желтый цвет
• Hi – значение больше “Верхнего порога”, желтый цвет
• HiHi – значение больше “Выше верхнего порога”, красный цвет.

Рисунок – Типы порогов сигнализации

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

Пример окна контроля и управления задвижкой

Рисунок – Окно управления задвижкой

В данном окне информация представлена по степени важности:

• Сигнализация аварии
• Состояние: “В работе”/ “В ремонте”
• Режим:“Местный”/”Дистанционный”
• Статус: “Открыта”/ “Закрыта”
• Панель управления

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

• если задвижка находится в состоянии ”В ремонте”, то возможен только местный режим управления и панель ”Управление” недоступна;
• если задвижка находится в  состоянии ”В работе” и в режиме ”Дистанционный”, то оператор может управлять задвижкой с помощью панели ”Управление.

Режим “Mестный”/ “Дистанционный” выбирается аппаратно, переключением тумблера в шкафу автоматики.

Подсистема архивов (TrendWorX32)

Графическое представление значений технологических параметров во времени способствует лучшему пониманию динамики технологического процесса предприятия. Поэтому подсистема создания трендов и хранения информации о параметрах с целью ее дальнейшего анализа и использования для управления является неотъемлемой частью любой SCADA - системы.

Тренды реального времени (Real Time) отображают динамические изменения параметра в текущем времени. При появлении нового значения параметра в окне тренда происходит прокрутка графика справа налево. Таким образом текущее значение параметра выводится всегда в правой части окна.

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

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

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

Основные функциональные возможности подсистемы архивов:

• Представление значений контролируемых параметров, получаемых от серверов OPC, на графиках различных типов в реальном масштабе времени.
• Поддерживаются следующие виды графиков:
  - зависимость от времени;
  - логарифмическая зависимость от времени;
  - гистограмма;
  - круговая диаграмма;
  - зависимость одного параметра от другого.
• Возможность настройки параметров графика, добавления и удаления перьев во время исполнения
• Возможность построения графических зависимостей на основе данных пользователя путем использования сценариев VBA или внешних приложений
• Архивирование значений контролируемых параметров в базах данных MS Access, MS SQL Server, Oracle при помощи сервера доступа к историческим данным TrendWorX32 SQL Server
• Вычисление статистических характеристик выборок значений контролируемых параметров
• Извлечение значений контролируемых параметров из архивов и представление в виде графиков различных типов
• Возможность одновременного просмотра текущих и исторических данных в одной области построения
• Вывод графиков на печатающее устройство
• Разработка и исполнение сценарных процедур на встроенном Visual Basic for applications
• Возможность вставки элементов просмотра графиков в различные контейнеры ActiveX
• Встроенное средство генерации отчетов в базах данных и MS Excel

Подсистема аварий (AlarmWorX32)

Это подсистема обнаружения, идентификации, фильтрации и сортировки аварийных и других событий, связанных с контролируемым технологическим процессом и состоянием технических средств АСУ ТП. Является набором программных компонентов, предназначенных для обнаружения аварийных событий, оповещения оперативного персонала, приема подтверждений восприятия информации об аварийных событиях и регистрации информации об авариях в базе данных.
Основные функциональные возможности подсистемы аварий:

• Обнаружение аварийных событий по множеству признаков и критериев, настраиваемых пользователем
• Передача информации об обнаруженных авариях клиентским приложениям, расположенным на разных узлах локальной или глобальной сети
• Простое оповещение персонала об обнаруженных аварийных событиях путем прерывистого отображения информации об аварии и звукового сигнала
• Голосовое оповещение персонала об обнаруженных аварийных ситуациях
• Оповещение персонала путем автоматического дозвона по коммутируемым каналам связи с передачей сообщений об аварийных событиях и приемом подтверждений восприятия от ответственных лиц
• Персональное планирование оповещения для привлечения к мероприятиям по устранению аварийной ситуации только дежурного персонала
• Анализ аварийных событий и действий ответственного персонала
• Объединение всех аварийных событий и подтверждений восприятия системных сообщений ответственным персоналом в сводки аварийных событий
• Отображение вспомогательной информации для аварийных событий, позволяющей локализовать и устранить причины аварии
• Связь с аппаратными средствами системы через интерфейсы OPC
• Возможность запуска сервера обнаружения аварий в качестве службы Windows NT
• Возможность записи информации о событиях в журнал Windows NT
• Мощное средство конфигурирования признаков аварийных событий
• Управляющий элемент ActiveX просмотра текущих аварийных событий
• Управляющий элемент ActiveX просмотра архива событий
• Встроенная среда редактирования сценарных процедур Microsoft Visual Basic for Applications 5.0

Состояние тревоги, в дальнейшем аларм (Alarm) - это некоторое сообщение, предупреждающее оператора о возникновении определенной ситуации, которая может привести к серьезным последствиям, и потому требующее его внимания, а часто и вмешательства. А принял - ли оператор сообщение об аларме? Чтобы снять эти сомнения, в системах управления принято различать неподтвержденные и подтвержденные алармы. Аларм называется подтвержденным после того, как оператор отреагировал на сообщение об аларме. До этого аларм оставался в состоянии неподтвержденного. Наряду с алармами в SCADA - системах существует понятие событий. События представляют собой обычные статусные сообщения системы и не требуют реакции оператора. Обычно событие генерируется при возникновении в системе определенных условий (типа регистрации оператора в системе).

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

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

Подсистема алармов - это обязательный компонент любой SCADA - системы. Но возможности подсистем алармов различных SCADA - систем, вероятно, разные. С другой стороны, когда речь идет о типах алармов, то все SCADA - системы поддерживают такие типы алармов, как дискретные и аналоговые.

Дискретные алармы срабатывают при изменении состояния дискретной переменной. При этом для срабатывания аларма можно использовать любое из двух состояний: TRUE / ON (1) или FALSE / OFF (0). По умолчанию дискретный аларм может срабатывать на ON или OFF, в зависимости от конкретной SCADA - системы.

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

• High и High High (верхний и выше верхнего);
• Low и Low Low (нижний и ниже нижнего);
• Deviation (отклонение от нормы);
• Rate of Change - ROC (скорость изменения).
• изменения).

Алармы High и High High срабатывают при достижении переменной заданных для каждого аларма пределов (High Alarm, High High Alarm). Для выхода переменной из состояния аларма (High и High High) необходимо, чтобы ее значение стало меньше порогового на величину, называемую зоной нечувствительности (Deadband). Аналогично можно интерпретировать алармы типа Lo и LoLo.

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

Алармы типа ROC срабатывают, когда скорость изменения параметра становится больше предельно допустимой. Понятие "зона нечувствительности" (Deadband) к алармам этого типа не применяется.
Каждому аларму в SCADA соответствует некоторая величина, называемая приоритетом аларма. Этот приоритет характеризует важность данного аларма и принимает значения от 1 до 999 (наиболее серьезные алармы имеют приоритет 1). Организовав несколько диапазонов значений и связав алармы с каждым диапазоном, можно достаточно легко отфильтровать критические алармы от некритических. Выполнение анимационных функций, скриптов подтверждения, печать и просмотр информации также могут зависеть от приоритетов.
При определении  переменных и условий возникновения алармов каждый из них может связываться с определенным диапазоном при указании приоритета из этого диапазона. Определив уровни приоритетов, пользователь получает возможность просмотра и печати тех алармов, которые интересуют его в текущий момент

Для отображения информации об аварийных ситуациях или событиях в SCADA-системах предусмотрены два типа объектов (окон): Alarm Summary (текущие алармы) и Alarm History (архивная сводка алармов).

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

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

Основные понятия журнала тревог.

Состояние тревоги - это некоторое сообщение, предупреждающее оператора о возникновении определенной ситуации, которая может привести к серьезным последствиям, и потому требующее его внимания, а часто и вмешательства.
События представляют собой обычные статусные сообщения системы и не требуют реакции оператора. Обычно событие генерируется при возникновении в системе определенных условий (регистрация оператора в системе, задвижка открылась/закрылась).
В журнале тревог принято различать неподтвержденные (неквитированные) и подтвержденные (квитированные) тревоги. Тревога называется подтвержденной после того, как оператор отреагировал на сообщение о тревоге. До этого тревога оставалась в состоянии неподтвержденной.
Для отображения информации об аварийных ситуациях или событиях в АРМ разработано два типа журналов: Текущие тревоги и Общая сводка тревог. Для реализации этих журналов использовался один и тот же объект -  ”Alarm Summery” (”Сводка тревог”).

В АРМ реализовано два типа журнала для следующих  целей:

1. Журнал “Текущие тревоги” отображается на всех мнемосхемах, поэтому он должен занимать как можно меньше рабочего места, предусмотренного для отображения технологического процесса, и информировать только о текущих тревогах.
2. Для информирования оператора как о тревогах, так и текущих событиях служит журнал ”Общая сводка тревог”.
   Журнал “Текущие тревоги” служит для отображения текущих тревог в системе. Он всегда выводится на экране, так как в системе управления очень важно вовремя увидеть и отреагировать на тревогу.

Рисунок - Журнал “Текущие тревоги” Настройки журнала тревог в SCADA – системе iFix 2.6  позволяют выбрать 15 информационных колонок, но после изучения назначения каждой из них, были выбраны самые необходимые:

• “Ack” (“Квитирование”) – отображает состояние тревоги: подтверждена или не подтверждена. Тревога подтверждена, если напротив нее в колонке “Ack” стоит галочка. Подтвердить тревогу можно двойным щелчком на соответствующей строке. В случае возврата значения в нормальное состояние запись о тревоге исчезает из журнала.
• “Time In” (“Время появления”) – сообщает о времени возникновения тревоги.
• ”Time Last” (“Последнее время”) – сообщает  время возвращения значения параметра в нормальное состояние.
• “Tagname” (“Имя тега”) – содержит  имя тега, значение которого в данный момент достигла одного из порогов сигнализации.
• ”Status” (“Состояние”) – отображает  порог сигнализации (таблица 5.5), в котором на данный момент находится значение тега.

Таблица – Типы порогов сигнализации

Пороги сигнализации	Пределы
L	Минимальный
LL	Минимально– аварийный
H	Максимальный
HH	Максимально – аварийный

• ”Value” (“Значение”) – отображает текущее значение соответствующего тега.
• ”Description” (”Описание”) – содержит описание тревоги, кратко поясняющее что произошло.
• “Area” (“Зона тревоги”) – отображает имя группы тревог, к которой принадлежит сгенерированная тревога.

SCADA-cистема использует настраиваемую конфигурацию системы тревог, основанную на зонах тревог, представляющих собой технологические или функциональные участки производства. Для разрабатываемого АРМ созданы следующие зоны тревог, разбитые на две группы:

1. По технологическому принципу: AlarmSmith, AlarmMN, AlarmPN, AlarmRP – зоны тревог каждой частной мнемосхемы.
2. По функциональному принципу: AlarmН31, AlarmН32, AlarmН33, AlarmН21, AlarmН22, AlarmН23 – зоны тревог магистральных и подпорных насосов.

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

Рисунок – Цветовая политика, принятая в журнале тревог

Встроенные языки программирования в SCADA-системах

Большинство SCADA-систем имеют встроенные языки высокого уровня, Basic-подобные языки, позволяющие генерировать адекватную реакцию на события, связанные с изменением значения переменной, выполнением некоторого логического условия, использованием комбинации клавиш, а также реализацией некоторого фрагмента с заданной частотой относительно всего приложения или отдельного окна.

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

• Ориентация встроенных языков программирования на технологов. Функции в таких языках являются высокоуровневыми, не требующими профессиональных навыков программирования при их использовании. Количество таких функций в базовых поставках не исчисляется сотнями, хотя существуют свободно распространяемые библиотеки дополнительных функций.
• Ориентация на системного интегратора. В этом случае в качестве языков чаще всего используются VBasic - подобные языки.

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

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

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

Во всех языках функции разделяются на группы, часть из которых присутствует практически во всех языках: математические функции, функции работы со строками, обмен по SQL , DDE - обмен и т. д.

В разрабатываемом приложении создаются программные фрагменты, состоящие из операторов и функций языка, которые выполняют некоторую последовательность действий. Эти программные фрагменты связываются с разнообразными событиями в приложении, такими как нажатие кнопки, открытие окна, выполнение логического условия (a +b > c). Каждое из событий ассоциируется с графическим объектом, окном, таймером, открытием/ закрытием приложения. Когда приложение содержит сотни окон, тысячи различных графических объектов, а с каждым из них связано несколько событий, в приложении может "работать" огромное количество отдельных программных фрагментов. Велика вероятность их "одновременной" активизации.

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