 |
Аварийные
сигнализации и архивирование в распределенных системах управления.
Возможность архивирования технологических параметров – неотъемлемое требование,
предъявляемое ко всем современным системам управления. В действительности
развитая система архивирования – это та характерная черта, которая отличает
полнофункциональные РСУ от многочисленных, так сказать, "аналогов”.
Для чего же нужно архивирование технологических параметров? По трем довольно
простым причинам:
1. Архив значений технологических параметров (на техническом
жаргоне “история”, history) позволяет оценить качество и эффективность
осуществляемого системой управления. Это делается путем ретроспективного анализа
ключевых технологических параметров, что позволяет судить о том, в какой мере достигнута
поставленная цель управления.
2. Архивирование позволяет специалистам оценить динамику
изменения технологических параметров за длительный период времени, что
чрезвычайно полезно для понимания поведения процесса в различных (в том числе
аварийных) ситуациях, а, следовательно, и пополнения знаний о конкретной
технологии.
3. Архив может содержать информацию, помогающую установить причины возникновения
различных аварийных и нештатных ситуаций. Так,
тщательно изучив журнал действий оператора, специалист может определить, какая
именно операция диспетчера привела к отклонению от регламента или, не дай Бог,
аварии (можно предположить, что операторы не всегда в восторге от того, что
каждое их действие протоколируется системой).
Какая же информация архивируется (пишется в историю)? Грубо говоря, все
данные, которые записываются в архив, можно разделить на три группы:
1. Процессные переменные (process values);
2.
Аварийные сигнализации (alarms);
3.
Действия операторов-технологов (operator actions).
Процессные переменные.
Под словосочетанием “процессные переменные” понимаются численные параметры,
определяющие текущее состояние технологического процесса. К процессным
переменным можно отнести сигналы ввода/вывода, параметры функциональных блоков,
локальные и глобальные флаги (переменные), тэги SCADA и т.д.
Процессные переменные делятся на дискретные и аналоговые. Дискретная переменная
может принимать конечное число значений из довольно узкого диапазона. На
практике под дискретной переменной чаще всего подразумевают величину булевского
типа (двоичную), указывающую на одно их двух возможных состояний объекта (или
управляющего сигнала), хотя, формально говоря, это не совсем корректно. В общем
же случае дискретная переменная аналогична типу enumeration языка C.
Аналоговая переменная может принимать любую величину из ограниченного
непрерывного диапазона значений. По типу представления аналоговая переменная
больше соответствует вещественному числу.
Как записываются процессные переменные в архив? Существуют две техники
регистрации значений процессных переменных в архиве:
1. Циклическая запись (cyclic archiving) подразумевает периодическую запись
текущего значения процессной переменной через заданные пользователем интервалы
времени вне зависимости от величины и скорости изменения данной переменной (см.
рис. 1). Хотя эта техника не очень экономична, она довольно часто используется
для архивации аналоговых переменных. Период циклической записи для каждой
переменной настраивается индивидуально и, как правило, лежит в диапазоне от 0.5
с до 10 мин. Как для дискретных переменных, так и быстро изменяющихся аналоговых
переменных, подобный подход записи в архив явно не оптимален.
Рис. 1. Циклическая
запись процессной переменной в архив.
2. Архивация по изменению переменной (дельта-архивированиe,
delta-archiving). Этот подход предполагает запись переменной
в архив только тогда, когда изменение ее значения по
сравнению с предыдущим записанным значением (абсолютная
разность) достигает определенной величины (дельты, см. рис. 2). Дельта настраивается пользователем и может
быть выражена как в абсолютных единицах измерения, так и в
процентах от шкалы. Безусловно, это техника более
экономична, чем циклическая запись, так как она адаптируется
к скорости изменения архивируемой величины. Для дискретных
величин – этот подход незаменим. Допустим, у нас есть
дискретная переменная, которая изменяется, скажем, раз в
час. Зачем же ее архивировать каждую секунду или минуту?
Ведь гораздо логичнее записывать значение переменной в архив
только в те моменты, когда это значение переходит
из 1 в 0 или наоборот.
Рис. 2.
Дельта-архивирование процессной переменной.
Куда записывается архив процессных переменных? Чаще всего
используется один из трех вариантов:
1.
Архив записывается в обычный текстовый файл в формате CSV (comma
separated values). Этот файл может храниться как на
локальном, так и на сетевом диске. На самом деле
архив состоит из множества последовательно создаваемых
файлов: система генерирует новый файл архива каждую рабочую
смену или сутки. У такого формата представления архива есть
неоспоримое преимущество – его можно просмотреть любым
текстовым редактором. Его также можно экспортировать в MS
Excel и посмотреть в виде таблицы, применив необходимые
сортировки и фильтры. Существенный недостаток – это
неэкономичность хранения; накопленный таким образом архив
занимает неприлично много места на жестком диске. Для
уменьшения объема архива можно применить компрессию по
алгоритму ZIP или RAR – благо, что текстовые файлы очень
хорошо сжимаются.
2.
Архив представляет собой двоичный файл, формат которого
зависит от используемого ПО визуализации тех. процесса
(SCADA). Очевидно, что это более экономичное представление
архива, но для работы с ним обычным экселем уже не
обойдешься. При этом формат архива у разных производителей
SCADA может сильно различаться. Как и в предыдущем случае,
архив состоит из последовательно создаваемых файлов. Вообще,
хранить архив в одном большом файле – это не очень хорошо с
точки зрения скорости доступа к данным.
3.
Самый прогрессивный способ. Хранение архива в виде
реляционной базы данных с поддержкой СУБД SQL. Этот способ
позволяет достичь достаточно большой скорости работы с
архивом (добавление записей, чтение и обработка данных), при
этом сервер SQL может обеспечить оптимальный доступ к
истории сразу нескольким десяткам удаленных клиентов.
Поскольку доступ к архиву осуществляется по открытому
интерфейсу SQL, разработчики имеют возможность создавать
клиентские приложения под свои нужды. Но главное
преимущество заключается в том, что архив на базе SQL – это
отличная возможность для интеграции АСУ ТП с информационными
системами более высокого уровня (например, уровня MES). Как
правило, для ведения архива SQL и обслуживания клиентов
используется достаточно мощная серверная платформа.
Во всех описанных случаях система архивирования процессных
переменных – это неотъемлемая часть ПО визуализации
технологического процесса. Разница заключается в формате
представления архива и технологии доступа.
Какие средства служат для отображения архива? Архив можно
отобразить несколькими способами. Самый простой – это
представить его в табличной форме и экспортировать,
например, в Excel, в котором можно строить графики, диаграммы и делать отчеты. Однако это
довольно утомительно и требует много ручного труда.
Более удобный способ – это отображение истории в виде
специального динамического
(обновляемого автоматически) графика, называемого трендом (trend).
Тренд помещается на мнемосхемы операторского интерфейса в тех
места, где это необходимо и удобно оператору. Пример тренда изображен на
рисунке ниже.
Рис. 3. Пример
исторического тренда, отображающего две процессные переменные.
На тренд можно выводить до 16 переменных одновременно, как
дискретных, так и аналоговых. При этом тренд можно строить
за произвольный промежуток времени (time span). Также
поддерживается масштабирование (scaling). Передвигая
ползунок (slider) вдоль шкалы времени можно просматривать
точные значения переменных в различные моменты времени в
прошлом. Отрезки времени, в течение которых наблюдались
аварийные значения переменных, выделяются на тренде
контрастным цветом. В общем, тренды – это мощный и очень
удобный инструмент, наглядно показывающий поведение
переменных в динамике.
Аварийные сигнализации.
Аварийная сигнализация (alarm) – это оповещение
оператора о наступлении определенного события, связанного с
нарушением или угрозой нарушения регламентного течения
технологического процесса.
Аварийные сигнализации настраиваются путем задания
предельных значений (границ, thresholds) индивидуально для
каждой процессной переменной. Система автоматически
отслеживает изменение процессной переменной и сопоставляет
ее значение с заранее настроенными границами. В случае
выхода переменной за нормальные границы система генерирует
оповещение и фиксирует его в журнале аварийных сигнализаций.
Рассмотрим наиболее часто используемые аварийные
сигнализации для аналоговых величин:
Lo – нижняя предупредительная граница. В случае если
процессная переменная становится меньше Lo, генерируется
предупредительное оповещение.
LoLo – нижняя аварийная граница. В случае если процессная
переменная становится меньше LoLo, генерируется аварийная
сигнализация.
Hi - верхняя предупредительная граница. В случае если
процессная переменная становится больше Hi, генерируется
предупредительное оповещение.
HiHi – верхняя аварийная граница. В случае если процессная
переменная становится больше HiHi, генерируется аварийная
сигнализация.
DEV_HI (DEVIATION_HI) – верхняя граница отклонения
(рассогласования). Если разность (абсолютное значение) между
двумя переменными становится больше DEV_HI, то генерируется
аварийная сигнализация. Например, такую сигнализацию можно
настроить у блока PID; в этом случае система будет
сигнализировать об отклонении регулируемой величины от
уставки, превышающем границу DEV_HI. По аналогии можно
настроить сигнализацию DEV_LO.
ROC_HI (RATE_OF_CHANGE_HI) – верхняя граница скорости
изменения. Система отслеживает скорость изменения процессной
переменной (первую производную). Если скорость возрастания
переменной выше границы ROC_HI, то генерируется аварийная
сигнализация.
Для дискретных переменных сигнализаций гораздо меньше. По
сути их всего две – аварийное состояние, соответствующее
значению 1, или авария в случае значения 0.
На рис. 4 показана схема появления аварийных сигнализаций на
примере быстро изменяющейся процессной переменной. Стоит
отменить, что на рисунке изображены отнюдь не все
генерируемые оповещения. Например, при возврате переменной
обратно в нормальный диапазон значений, кроме изображенных
на рисунке, генерируется оповещение RETURN_TO_NORMAL.
Рис. 4. Пример генерации
аварийных сигнализаций и оповещений.
Важность (или критичность) аварийной сигнализации
определяется приоритетом (целое число). Как правило, чем
выше приоритет у аварийной сигнализации, тем критичнее она
для производства, и тем быстрее на нее надо обратить
внимание.
При появлении аварийной сигнализации у оператора есть два
варианта действий:
1.
Игнорировать ее. Не всегда хорошее решение, мягко говоря.
При этом если процессная переменная вернется обратно в
нормальные границы, то появиться новое оповещение
UNACK_RETURN_TO_NORMAL, говорящее о том, что оператор
проспал аварийное событие, но, к счастью, все
нормализовалось.
2.
Подтвердить, что сигнализация замечена оператором (acknowledge).
Дело в том, что сразу после появления аварийной сигнализации
ей автоматически присваивается статус UNACK (не
подтверждена). Как только сигнализацию подтверждают (иногда
говорят “квитируют”), ее статус становится ACK
(подтверждена). В этом случае возврат переменной в
нормальные границы ведет к появлению оповещения
ACK_RETURN_TO_NORMAL, свидетельствующее о том, что оператор
“держит ухо востро”.
Аварийные сигнализации можно произвольно группировать. На
практике группировка проводится путем распределения
процессных переменных, а следовательно, и соответствующих им
аварийных сигнализаций по различным технологическим участкам
(plant areas) и установкам (plant units).
Как же архивируются аварийные сигнализации? Все описанные
выше аварийные сигнализации и оповещения регистрируются в
специальном архиве сразу после их появления. Этот архив
называется журналом аварийных сигнализаций (alarm journal,
alarm list).
Журнал аварийных сигнализаций представляет
собой базу данных SQL, которую разворачивают либо на
операторских станциях, либо на сервере, если таковой
предусмотрен в системе управления. Подробнее об этом речь
пойдет чуть ниже.
Как же отображаются аварийные сигнализации? Самое понятное отображение – это в
показ в виде отсортированной по времени и автоматически
обновляемой таблицы на подобие той, что изображена на
рисунке ниже.
Рис. 5. Пример журнала аварийных сигнализаций из пакета
визуализации Wonderware Intouch.
Поддерживается фильтрация и сортировка аварийных
сигнализации, а также их квитирование. Возможны операции как
с отдельными записями таблицы, так и с пользовательскими
группами. Все это стандартные инструменты, предлагаемые
современными РСУ для работы с журналом сигнализаций.
Рис. 6. Еще один пример журнала аварийных сигнализаций.
Пакет Simatic WinCC.
Действия операторов-технологов.
Тут много говорить не стоит. В специальном архиве (журнале)
регистрируются следующие действия оператора, выполняемые на рабочей станции:
1.
Вход/выход из системы (system logon/logout);
2.
Квитирование аварийных сигнализаций (alarm acknowledgment);
3.
Изменение процессных переменных (variable changes);
4.
Изменение настроек системы, если это допускается (tuning);
Этот журнал также записывается в базу данных SQL и может
храниться как на локальном компьютере (операторской
станции), так и централизованно на сервере (например, на том
же, где хранится архив аварийных сигнализаций). Журнал
оператора отображается в табличной форме и по виду весьма
похож на журнал аварийных сигнализаций. В нем, как минимум,
показывается:
1.
Имя оператора;
2.
Права или уровень доступа оператора;
3.
Дата и время совершения действия;
4.
Тип совершенного действия (например, изменение уставки PID1.SP с
34.5 єC на 34.2 єC);
5.
Комментарий оператора, если требуется.
В некоторых системах журнал действий оператора и журнал
аварийных сигнализаций хранятся в одной базе данных и
отображаются в единой форме. Это связано с тем, что в обоих
случаях в основе регистрации лежит событийных подход.
Архитектура системы архивирования.
Рассмотрим подробнее, как именно может быть развернуто
архивирование в реальной системе управления? Тут многое,
конечно, зависит от самой системы – у разных производителей
несколько отличающиеся подходы к организации архива. Ниже
рассмотрим наиболее часто применяемые схемы:
1.
Каждая операторская станция накапливает на своем жестком
диске собственный архив (или определенную часть архива)
независимо от работы других станций. При этом станция
имеет доступ как к своему архиву, так и к
архиву, хранящемуся на соседской станции. Как правило, на
каждой операторской станции устанавливается СУБД SQL
(например, бесплатный вариант Microsoft SQL Desktop Engine)
для ведения журнала аварийных сигнализаций и журнала
действий оператора. Во многих системах архив процессных
переменных также записывается в локальную базу данных и
обслуживается движком на базе SQL. Стоит учесть, что при
такой схеме архивы, хранящиеся на разных станциях, не
синхронизируются и поэтому могут значительно отличаться друг
от друга.
Описанная выше организация архивирования больше характерна
для систем с одиночными операторскими станциями (см. рис.
7).
Рис. 7. Система архивирования при одиночных операторских
станциях.
2.
При клиент-серверной архитектуре операторского уровня (см.
рис. 8) история накапливается и хранится на общем сервере. В
случае использования резервированной пары серверов система
обеспечивает идентичность хранящихся на них экземпляров
архива, проводя их периодическую синхронизацию. Операторские станции получают
по запросу архивные
данные именно от общего сервера (или серверов), что полностью соответствует общей
клиент-серверной концепции построения верхнего уровня АСУ
ТП. Работа с архивами, как и в предыдущем случае,
организуется с помощью СУБД на базе SQL.
Рис. 8. Система архивирования при клиент-серверной
архитектуре.
3.
Для долговременного хранения истории часто выделяют
отдельный центральный сервер архива (central archive server,
CAS). Как правило, это мощная серверная платформа с дисками
большой емкости или даже RAID-массивом. Главное
предназначение CAS – это сбор и хранение технологической
истории в течение нескольких лет. CAS берет исторические
данные с общего сервера, обеспечивает их хранения и
поставляет их операторским станциям (как, впрочем, и любому
другому обратившемуся к ним клиенту). Такая схема
архивирования позволяет освободить общий сервер и
операторские станции от такой ресурсоемкой задачи как сбор
истории. Описываемая архитектура изображена на рисунке 9. В
некоторых системах сервер CAS резервируется. Многие
производители АСУ ТП называют центральное хранилище архивных
данных модным термином "HISTORIAN",
но суть от этого не меняется.
Рис. 9. Система архивирования на базе сервера
CAS.
Для работы с базами данных истории в большинстве
современных систем используется СУБД MS SQL Server, реже
Oracle.
Каким требованиям должна отвечать система архивирования?
1.
Большая глубина (продолжительность) архива. Выражается в
способности непрерывного архивирования технологических
параметров в течение нескольких лет. Но даже после того, как
архив достигает своего максимального размера (например, в
случае заполнения жесткого диска), система не должна
останавливать архивирование. Это реализуется следующим
образом. Архив накапливается в виде последовательно
создаваемых частей (партиций, partitions) определенного
размера. Когда суммарный размер всех патриций достигает
угрожающего размера, система автоматически пересылает самые
старые патриции на Backup-сервер или осуществляет их запись
на съемный накопитель, тем самым высвобождая драгоценное
место под новые части.
2.
Производительность (скорость архивирования) и максимальное
количество архивируемых параметров. Это достигает путем
модификации стандартной СУБД (например, надстройки над
SQL-сервером), что позволяет добиться более высокой скорости
работы с базой данных, чем в обычных офисных приложениях.
Например, продукт Wonderware Industrial SQL Server версии
9.0 позволяет записывать до 2000 аналоговых переменных в
секунду и поддерживает в сумме до 60000 параметров
(процессных переменных). Примерно
такой же скоростью архивирования обладает система SIMATIC
PCS7 Central Archive Server, но при этом по заверению
производителя поддерживает до 120000 параметров.
3.
Поддержка открытых коммуникационных протоколов. Доступ к
архиву со стороны клиентов должен быть возможен с
использованием стандартных, всем известных протоколов,
например OPC. Или с использованием SQL – запросов. Это
требование связано с тем, что архивом пользуются не только
операторские станции, входящие непосредственно в состав АСУ
ТП, но и сторонние пользователи такие как: серверы
приложений MES, удаленные клиенты, рабочая станция
начальника цеха и т.д.
|
|
