ЖУРНАЛ «СТА» 4/2016

107 СТА 4/2016 www.cta.ru В ЗАПИСНУЮ КНИЖК У ИНЖЕ Н Е РА 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 – специализирован- ную хранимую процедуру s pGetTodayAlarms , которая автома- тизирует выборку и подготовку данных для отчётов. Текст хра- нимой процедуры приведён в листинге 1. Процедура spGetTodayAlarms получает на вход следующие па- раметры: @SystemName – название системы, @ARMName – на- звание АРМ, на который выводится информация по системе, @SeverityVal – уровень значимости сигнала. На выходе проце- дуры таблица, содержащая следующие колонки: название объ- екта/сооружения, название системы, название аварийного сиг- нала, текст аварийного сообщения, время возникновения ава- рии, время квитирования, время снятия аварии. Внутри процедуры spGetTodayAlarms автоматически опреде- ляется временной диапазон от начала до конца текущего дня, и на его основе формируется временная таблица #TempAlarmLog , содержащая данные из БД AlarmWorX64 Logger только за текущий день. А уже из временной таблицы выполняется выборка, увязывающая цепочку событий: по- явление аварийного сигнала, квитирование и снятие аварий- ного сигнала. Здесь следует отметить важность колонки ChangeMask в БД AlarmWorX64 Logger, которая содержит битовую маску, одно- значно определяющую, какие изменения произошли с ава- рийным сигналом (в том числе квитирование). На основании сочетания (листинг 1) значения этой колонки, колонки ConditionActive (сработало условие фиксации аварийного сиг- нала) и Acked (квитирование аварийного сигнала) опреде- ляется момент возникновения аварийного сигнала, его кви- тирования и снятия аварийного сигнала. Более подробную информацию по этим колонкам можно найти в документа- ции на GENESIS64. Название объекта/сооружения и название конкретной си- стемы формируются путём разбора данных колонки Area и на- полнения указанных колонок только нужной информацией. Это необходимо, поскольку из-за сложной иерархии Area в AlarmWorX64 Server в БД AlarmWorX64 Logger записываются Рис. 3. Фрагмент базы данных AlarmWorX64 Logger