- Автор: Роман Савоченко
Нарушения и работа с ними в OpenSCADA реализуется двояко, что связано со структурой OpenSCADA, способами её использования, а также самой природой нарушений.
Первой стороной нарушений, с которой OpenSCADA работает изначально и которая наиболее востребована, является уведомление различными способами. Поскольку уведомление это часть интерфейса пользователя то и реализованы они в движке визуализации UI.VCAEngine и визуализаторах UI.Vision, UI.WebVision. На данный момент, механизм уведомлений о нарушениях реализует функции, часть из которых ещё не реализована в UI.WebVision:
- Уведомление:
- Визуально — мигание цветом нарушения для объекта, группы сигнализации и общего статуса.
- Гудком — выдача непрерывного сигнала, обычно на системный "бузер" и независимо от нарушения.
- Звуком — проигрывание звукового файла или синтез речи из текста, связанного с нарушением.
- Расширенными особыми способами и через специальные механизмы уведомления.
- Квитирование (утихомиривание) уведомления о нарушении:
- Полностью — по нажатию на цветной мигающий кружок статуса нарушений (событие "ws_alarmLev"), внизу справа.
- По способу уведомления — отдельно визуальную (событие "ws_alarmNtf0"), гудок (событие "ws_alarmNtf1"), звуковую (событие "ws_alarmNtf2") и расширенный (сообщение "ws_alarmNtf{N}"); по нажатию кнопки с соответствующим изображением снизу справа или под кнопками видов отображения.
- По объекту нарушения — к образу визуального представления может добавляться команда квитации уведомления непосредственно по нему.
- Поочерёдно, c выслушиванием — характерно для уведомлений звуком, поскольку каждый объект нарушения может предоставлять своё звуковое уведомление или синтез речи.
В среде визуализации, при реализации уведомлений, нет установленного правила получения и формирования признака нарушения, поскольку нет однозначности в разных ситуациях. На данный момент, на стороне типизированных шаблонов источника данных, практикуется способ формирования атрибута ошибки "err" с кодами и текстом нарушения, а их обработка и формирование уведомления осуществляется уже в самом визуальном образе объекта данных. Иногда обработка границ уставок также осуществляется непосредственно в визуальном образе объекта данных.
Впоследствии возникла необходимость протоколирования, а также учёта актуальных на текущий момент нарушений. Если для протоколирования достаточно формирования сообщений программы с оговоренной категорией и форматом сообщения, то для контроля за текущими нарушениями необходим некий буфер. Такой буфер был добавлен, в виде надстройки над подсистемой сообщений, а адресация к нему осуществляется инверсией уровня сообщения. Так, запись сообщения с уровнем "-2" и категорией "TEST" поместит сообщение в буфер нарушений и продублирует его в архиве сообщений. При запросе сообщений с отрицательным уровнем, сообщения будут браться из буфера нарушений. Удаление-снятие нарушения осуществляется записью сообщения с той же категорией "TEST" и неотрицательным уровнем.
Такая концепция учёта активных нарушений позволяет использовать стандартные механизмы работы с сообщениями:
- Регистрация нарушения: SYS.message("alCategory", -3, "Параметр: нарушение");
- Снятие нарушения: SYS.message("alCategory", 1, "Параметр: норма");
- Формирование списка активных нарушений: посредством примитива "Протокол" или "Документ", с отрицательным уровнем, для всех — "-1".
Регистрацию нарушений лучше всего осуществлять на стороне типизированных шаблонов источника данных, посредством специальной функции SYS.DAQ["Modul"]["Controller"].alarmSet(string mess, int lev = -5, string prm = "", bool force = false) или её варіанта пространства параметра SYS.DAQ["Modul"]["Controller"]["Parameter"].alarmSet(string mess, int lev = -5, bool force = false), которая унифицирует категорию. Для вызова этих функций из контекста шаблона нужно добавить ВВ "this" типа "Объект", после чего установка нарушения будет иметь вид this.alarmSet("Параметр: нарушение", -5);. Указанная функция сейчас используется во многих модулях источников данных, для учёта глобальных нарушений объектов контроллеров. Функция предоставляет контроль переключения пропуска сообщений к буферу сообщений, то есть вы можете спокойно осуществлять повторную генерацию и очистку нарушений этой функцией без переполнения архива сообщений и что может быть полезным для периодической актуализации состояний нарушения.
Функция формирует нарушение с категорией al{ModId}:{CntrId}[.{PrmId}] и текстом {CntrNm} > {PrmNm}: {MessText}, где:
- ModId — идентификатор модуля;
- CntrId — идентификатор объекта контроллера;
- PrmId — идентификатор параметра, из аргумента prm в форме {PrmId}\n{PrmNm};
- CntrNm — название объекта контроллера;
- PrmNm — название параметра, из аргумента prm в форме {PrmId}\n{PrmNm};
- MessText — текст сообщения.
Формат текста этой функцией не регламентируется, но есть практика формирования текста нарушения, определённая кадрами формирования отчётной документации вроде "Протокол нарушений", где применяется формат: {PrmId}: {PrmName}: {Alarm} и где дополнительно определено:
- PrmName — имя параметра;
- Alarm — текст нарушения или "НОРМА" для снятия нарушения.
В целом нужно отметить, что уведомления и учёт нарушений это разные механизмы, которые могут использоваться отдельно — для простых проектов или вместе — для больших-комплексных проектов.