Одной из часто встречающихся задач на рынке автоматизации является внедрение системы отчётов о состоянии технологических процессов. В частности, наиболее интересна для заказчиков информация о произошедших за определённый временной период аварийных событиях. Такая информация позволяет прогнозировать ресурс работы оборудования и планировать планово-предупредительные и аварийные ремонтные работы.
С подобной задачей на одном из объектов столкнулась и инжиниринговая компания «Инсайт-НГ». Необходимо было разработать систему генерации периодических (суточных) отчётов о возникших аварийных событиях в технологических системах обслуживаемого объекта с последующей рассылкой отчётов по заданным адресам электронной почты.
Для решения задачи был выбран компонент ReportWorX из пакета BizViz компании ICONICS, выбор был определён тем, что на объекте уже стояла SCADA-система GENESIS64 разработки компании ICONICS. Хотя многие компоненты BizViz 32-битовые, они прекрасно работают с GENESIS64.
ReportWorX – это система документирования, обеспечивающая создание, исполнение и перенаправление отчётов. Система работает как с продуктами ICONICS, так и с другими источниками данных: различные SCADA-системы, данные MES и ERP-систем, корпоративные базы данных и т.д. Поддерживается доступ к отчётам из Интернета и корпоративной сети.
В качестве источника данных для формирования отчётов используется база данных AlarmWorX64 Logger. Она хранит всю информацию о произошедших аварийных событиях и наполняется автоматически.
Далее поэтапно описан процесс конфигурирования ReportWorX и разработки необходимых SQL-запросов к базе. Поскольку статья не ставит своей целью подменить руководство ICONICS, а также объяснить правила разработки SQL-запросов, ряд моментов был сознательно опущен.
Предварительные настройки
Разработка велась в следующей конфигурации системы:
- Windows 7 Professional x64;
- ICONICS GENESIS64 v.10.71, HotFixPack 1, ServicePack 1, ServicePack 2;
- BizViz 9.22, компонент ReportWorX;
- Microsoft Excel 2007.
В AlarmWorX64 Server были созданы аварийные сигналы, связанные с регистрами UDM, а также
Area – области для группировки аварийных сигналов, например, для разных объектов, типов систем, систем. Созданные
Area в дальнейшем использовались при формировании запросов в базу данных AlarmWorX64 Logger и были организованы по иерархическому принципу:
1)
Area с названием АРМ, куда выводится информация по системе (АРМ Э, АРМ ОВК и т.д.);
a. Area-названия объектов (внешняя территория, КТП, административный корпус и т.д.);
i. Area-названия конкретных технологических систем (СО – система освещения, СЭ – система электроснабжения, ОВ – система вентиляции и т.д.);
1. Area-названия конкретных систем/шкафов управления (ШРНН, ШУ ИТП и т.д.);
a. Название аварийного сигнала.
Пример: АРМ Э\ВНЕШНЯЯ ТЕРРИТОРИЯ\БКТП\СЭ\ШРНН_1\1QF1.
Извлечение данных из базы данных AlarmWorX64 Logger
В AlarmWorX64 Logger есть два основных типа аварийных сигналов – дискретные (Digital) и аналоговые (Limit). Сигналы могут быть в аварийном или нормальном состоянии. Аварийное состояние означает, что значение сигнала стало равно некоторой заданной величине, трактуемой как негативное, или сработало иное условие фиксации аварийного сигнала.
Дискретные сигналы имеют два состояния – норма и авария (рис. 1).
Аналоговые имеют пять состояний (рис. 2): норма,
LoLo (аварийно-низкий уровень),
Lo (предупредительный низкий уровень),
Hi (предупредительный высокий уровень),
HiHi (аварийно-высокий уровень). Точная трактовка аварийного состояния зависит от уровня Severity (уровня критичности сигнала), задаваемого для каждого аварийного состояния, например: 100 – рядовое событие; 500 – предупреждение о предаварийном состоянии типа загрязнённый фильтр; 700 – критичная авария типа потери питания/неисправности оборудования. Иногда для конкретной установки уровень Lo – это не предупредительный низкий, а аварийный сигнал о снижении какого-либо параметра, и его уровень значимости будет высоким. Уровень Severity удобно использовать для фильтрации сигналов, чтобы избежать попадания в отчётную документацию малозначащих сигналов. В разработанной системе требовалось заносить в отчёт все сигналы с уровнем Severity выше 500.
Каждый переход от нормального состояния к аварии (на рис. 1, 2 показаны стрелками) фиксируется в БД AlarmWorX64 Logger. В случае перехода от нормального состояния к аварии требуется квитирование такого перехода – подтверждение оператором фиксации данной информации. Факт квитирования заносится в БД AlarmWorX64 Logger и может использоваться для отчёта.
На рис. 3 приведён фрагмент данных из БД AlarmWorX64 Logger.
В БД попадают
Area, название аварийного сигнала, время изменения состояния, комментарий при квитировании, время квитирования, текст описания аварийного сигнала, признак активности/квитирования аварийного сигнала, битовая маска изменения состояния аварийного сигнала и множество другой, по большей части служебной информации.
Для извлечения данных из БД AlarmWorX64 Logger необходимо написание SQL-запросов. В ReportWorX имеется редактор запросов к БД и в большинстве случаев его вполне достаточно для построения простых запросов. Но при необходимости построения сложных запросов, как в случае поставленной задачи, с вложенными подзапросами и предварительной обработкой извлечённых данных, встроенного редактора уже недостаточно. Поэтому было принято решение создать запрос внутри БД AlarmWorX64 Logger – специализированную хранимую процедуру
spGetTodayAlarms, которая автоматизирует выборку и подготовку данных для отчётов. Текст хранимой процедуры приведён в листинге 1.
Процедура
spGetTodayAlarms получает на вход следующие параметры:
@SystemName – название системы,
@ARMName – название АРМ, на который выводится информация по системе,
@SeverityVal – уровень значимости сигнала. На выходе процедуры таблица, содержащая следующие колонки: название объекта/сооружения, название системы, название аварийного сигнала, текст аварийного сообщения, время возникновения аварии, время квитирования, время снятия аварии.
Внутри процедуры
spGetTodayAlarms автоматически определяется временной диапазон от начала до конца текущего дня, и на его основе формируется временная таблица
#TempAlarmLog, содержащая данные из БД AlarmWorX64 Logger только за текущий день. А уже из временной таблицы выполняется выборка, увязывающая цепочку событий: появление аварийного сигнала, квитирование и снятие аварийного сигнала.
Здесь следует отметить важность колонки
ChangeMask в БД AlarmWorX64 Logger, которая содержит битовую маску, однозначно определяющую, какие изменения произошли с аварийным сигналом (в том числе квитирование). На основании сочетания (листинг 1) значения этой колонки, колонки
ConditionActive (сработало условие фиксации аварийного сигнала) и Acked (квитирование аварийного сигнала) определяется момент возникновения аварийного сигнала, его квитирования и снятия аварийного сигнала. Более подробную информацию по этим колонкам можно найти в документации на GENESIS64.
Название объекта/сооружения и название конкретной системы формируются путём разбора данных колонки
Area и наполнения указанных колонок только нужной информацией. Это необходимо, поскольку из-за сложной иерархии
Area в AlarmWorX64 Server в БД AlarmWorX64 Logger записываются очень длинные пути в поле Area и без их разбора колонки отчёта будут слишком длинными и будут содержать ненужную информацию. Например:
Исходное значение
Area – АРМ Э\ВНЕШНЯЯ ТЕРРИТОРИЯ\БКТП\СЭ\ШРНН_1.
После разбора колонка с названием объекта будет содержать «ВНЕШНЯЯ ТЕРРИТОРИЯ\БКТП», а колонка с названием системы будет содержать «ШРНН_1».
Также в
spGetTodayAlarms происходит анализ собранной информации, и в соответствующих полях (с метками времени) выводится поясняющая информация. Например, если аварийный сигнал не квитирован на момент формирования отчёта, в поле «время квитирования» будет написано «Не квитировано». Если аварийный сигнал ещё не пропал или для аналогового сигнала произошло изменение одного аварийного уровня на другой, будет написано «Авария не снята/сменила уровень».
Создание отчёта для ReportWorX
Для создания отчёта необходимо в ReportWorX Configurator создать новую конфигурацию (рис. 4) или использовать имеющуюся.
Для конфигурации важно задать имя, и путь к папке для временных файлов отчётов. Далее создаётся сам отчёт (Report Object). Для него можно задать (рис. 5) имя, шаблон и действия по распространению отчёта: пересылка по почте, публикация в Интернете, сохранение копии отчёта на файловом ресурсе.
После создания Report Object можно перейти к созданию шаблона отчёта (Report Template), для этого необходимо нажать на кнопку “Create new template object” напротив надписи “Report Template” (рис. 5). Запущенный мастер предложит задать имя шаблона, папку для размещения шаблона, формат файла шаблона (Excel 2003/Excel 2007), а также предложит скопировать форматирование, ссылки на источники данных из других шаблонов. После этого будет запущена программа Excel с надстройкой ReportWorX.
На открывшемся листе Excel оформляется внешний вид отчёта, указывается заголовок, поля для автоматической вставки времени и даты и т.д. После этого выполняется привязка к шаблону источников данных, для чего на вкладке ReportWorX на ленте с инструментами необходимо нажать кнопку “Data Source Management”, откроется окно для настройки источников данных (рис. 6): это могут быть теги OPC DA, OPC HDA, базы данных (БД), гиперссылки и т.д. В данном проекте источником данных выступала база данных AlarmWorX64 Logger.
Для подключения к БД AlarmWorX64 Logger необходимо выбрать в списке “Local Data Source” пункт “Open Database” и через контекстное меню запустить мастер создания соединения с БД. Первый шаг мастера – подключение к серверу БД и выбор базы данных на сервере.
Следующий шаг – формирование запроса к БД (ссылки на данные), который извлечёт нужные для отчёта данные. Как было описано ранее, для извлечения данных из БД AlarmWorX64 Logger будет использоваться хранимая процедура spGetTodayAlarms, поэтому при нажатии на кнопку “Edit” выбираем из списка пункт “Stored Procedure Call” (рис. 7).
В открывшемся окне (рис. 8) при нажатии на кнопку “…” (справа вверху) выбирается нужная хранимая процедура.
После этого в таблице под названием процедуры отображается перечень параметров хранимой процедуры. Эти параметры необходимо сопоставить так называемым переменным отчёта. Для этого надо нажать кнопку “…” напротив каждой переменной. В открывшемся окне (рис. 9) отображается список переменных отчёта, при нажатии кнопки Add добавляется новая переменная.
Для каждой переменной (рис. 10) указывается имя, тип данных и значение по умолчанию.
После настройки переменной она выбирается в списке переменных отчёта и при нажатии кнопки “Ok” (рис. 9) сопоставляется с параметром хранимой процедуры. Теперь при генерации отчёта хранимая процедура будет получать на вход данные из указанных переменных. Их значение может задаваться в ReportWorX Configurator или в Web-интерфейсе ReportWorX. Если значения не заданы, то будут использованы значения по умолчанию.
Последнее оказалось очень удобно, поскольку необходимо на разных вкладках отчёта выводить информацию по разным системам, а хранимая процедура одна, и возник вопрос, как передать параметры, однозначно определяющие технологическую систему, в хранимую процедуру. Для каждой технологической системы были созданы индивидуальные запросы на базе spGetTodayAlarms и созданы соответствующие переменные отчёта, а им назначены значения по умолчанию, однозначно определяющие нужную систему. Тогда при генерации отчёта каждый раз формировались отдельные запросы с нужными параметрами, но при этом в БД AlarmWorX64 Logger использовалась только одна хранимая процедура.
После завершения настройки ссылок на данные в шаблоне выделяется область ячеек для вывода данных, полученных по запросу. Размер области зависит от количества полей, возвращаемых запросом. Используя условное форматирование (доступно в Excel 2007 и выше), зависящее от содержимого ячейки, можно сделать более наглядное оформление отчёта, например, подсветив строки с авариями, которые не квитированы или активны.
После завершения оформления шаблона отчёта при закрытии Excel возникнет диалоговое окно с предложением сохранить сделанные изменения. Сохранив изменения, можно перейти к следующему этапу – настройке периода генерации отчёта. Для этого необходимо выбрать отчёт и в области его настроек (рис. 5) нажать “Advanced Mode”, после этого выбрать вкладку Report Scheduling (рис. 11) и нажать кнопку “Add…”, выбрать Time Triggers и триггер с нужным периодом генерации отчётов. Поскольку нужного триггера в 24 часа по умолчанию нет, то он был создан вручную в приложении UDMCfg (Unified Data Manager).
После создания отчёта можно проверить его генерацию, нажав кнопку “Execute Report Now” (рис. 12).
На рис. 13 показан пример сгенерированного отчёта. В нём интересно отметить не характерное для дискретного аварийного сигнала повторение описания «Авария не снята/сменила уровень», поскольку он не может сменить уровень без перехода в нормальное состояние, которого в отчёте нет. Это связано с перезагрузкой сервера AlarmWorX64 Server, после которой все аварии обрабатываются как вновь появившиеся, что приводит к дублированию в отчёте аварийных сигналов.
Бороться с этим нежелательно, так как достоверно неизвестно, «новая» это авария или повторно зарегистрированная старая.
Если предварительно в ReportWorX Configurator открыть Monitor View (кнопка на панели в виде очков), то внизу откроется протокол работы ReportWorX, в котором можно увидеть статус генерации отчёта. Там же можно открыть файл отчёта, щёлкнув по значку файла левой кнопкой мыши.
После настройки отчёта не стоит забывать включить его – флажок “Enabled” на рис. 12.
Настройка рассылки отчётов
Отчёты используются не только оперативным персоналом, но и руководством, поэтому важно иметь возможность рассылки отчётов заинтересованным лицам. Для этого в ReportWorX предусмотрены так называемые Redirector Actions, действия для распространения отчётов. В описываемой задаче интересовал только один тип Redirector Actions – E-mail Actions, рассылка по электронной почте. Для настройки данного действия нужно выбрать отчёт и в области его настроек нажать кнопку “Create new RedirectorTask”, будет запущен мастер настройки пересылки отчёта. При выборе E-mail Report будет создано действие (Action) для пересылки по электронной почте, далее необходимо заполнить традиционные для любого электронного письма поля (рис. 14): адресат, тема письма, текст письма.
Для работы рассылки по электронной почте также надо задать SMTP-настройки системы (рис. 15).
Следует обратить внимание, что для отправки по умолчанию используется 25-й порт SMTP-сервера, если необходимо изменить порт для отправки, необходимо внести в файл C:\ProgramData\ICONICS\IcoSetup.ini, строки:
[ReportWorX.NET\ReportWorXRedirector]
SMTPPort=2525
Если требуется включить SSL при отправке почты, то в файл настроек в секцию [ReportWorX.NET\ReportWorXRedirector] надо внести строку:
EnableSSLForEmail=1
После изменения настроек необходимо перезапустить ReportWorX-сервис – кнопка в виде светофора в ReportWorX Configurator. Теперь в конце каждого дня при срабатывании триггера генерации отчёта будет происходить автоматическая рассылка.
Возможности расширения созданной системы
За счёт использования современных программных продуктов ICONICS созданная система периодических отчётов получилась расширяемой и масштабируемой. И компания «Инсайт-НГ» уже готова предложить заказчику возможное направление развития данной системы.
В июне 2015 года компания ICONICS представила новую версию надстройки ReportWorX Express, которая даёт возможность пользователям платформы Microsoft Office получать доступ к данным из приложений ICONICS (GENE-SIS64, Hyper Historian и AnalytiX и др.).
Обновлённый продукт ICONICS Report-WorX Express может работать как в классическом приложении Microsoft Excel 2013, так и в веб-приложении Excel Online для облачной службы Microsoft Office 365.
С помощью ReportWorX Express можно быстро и просто настраивать и просматривать отчёты по производственным процессам. Встроенная система безопасности реализует управление доступом пользователей к данным на основе ролей. Интуитивно понятный интерфейс позволяет легко выбирать необходимые данные и определять формат их отображения на листе Excel, а затем применять нужные фильтры.
Такое решение в перспективе может оказаться очень интересным, особенно для заказчиков с территориально распределёнными системами, например, общероссийского масштаба, поскольку позволяет снизить издержки на развёртывание системы и расходы на лицензирование. Также оно может быть полезным и для небольших заказчиков, так как за счёт поддержки Office 365 не требует установки программ из пакета Microsoft Office на рабочих местах. ●
E-mail: ssa-company@rambler.ru
автоматизация
автоматизация
автоматизация
автоматизация
