Документи/Як/Сформувати порушення, сигналізацію та сповіщення

Порушення та робота з ними у OpenSCADA реалізуються двояко, що пов'язано зі структурою OpenSCADA, способами її використання, а також самою природою порушень.

Першою стороною порушень, з якою OpenSCADA працює від початку та яка найбільш затребувана, є сповіщення різними способами. Оскільки сповіщення це частина інтерфейсу користувача то й реалізовано їх у рушії візуалізації UI.VCAEngine та візуалізаторах UI.Vision, UI.WebVision. На цей час механізм сповіщення про порушення реалізує функції, частина з яких ще не реалізована у UI.WebVision:

• Сповіщення:
  • Візуально — миготіння кольором порушення для об'єкту, групи сигналізації та загального статусу.
  • Гудком — видача неперервного сигналу, зазвичай на системний "бузер" та незалежно від порушення.
  • Звуком — програвання звукового файлу або синтез мови з тексту, пов'язаного з порушенням.
  • Розширеними особливими способами та через спеціальні механізми сповіщення.
• Квітація (стишення-втихомирення) сповіщення про порушення:
  • Цілковито — за натиском на кольорове миготливе коло статусу порушень (подія "ws_alarmLev"), праворуч знизу.
  • За способом сповіщення — окремо візуальну (подія "ws_alarmNtf0"), гудок (подія "ws_alarmNtf1"), звукову (подія "ws_alarmNtf2") та розширене (подія "ws_alarmNtf{N}"); за натиском кнопки з відповідним зображенням праворуч знизу або під кнопками видів відображення.
  • За об'єктом порушення — до образу візуального представлення може додаватися команда квітації сповіщення безпосередньо за ним.
  • Почергово, з вислуховуванням — характерно для сповіщень звуком, оскільки кожний об'єкт порушення може надавати власне звукове сповіщення або синтез мови.

У середовищі візуалізації, при реалізації сповіщень, немає встановленого правила отримання та формування ознаки порушення, оскільки немає однозначності у різних ситуаціях. На цей момент, на стороні типізованих шаблонів джерела даних, практикується спосіб формування атрибуту помилки "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 — текст порушення або "НОРМА" для зняття порушення.

Загалом треба відзначити, що сповіщення та облік порушень це різні механізми, які можуть використовуватися окремо — для простих проектів або разом — для великих-комплексних проектів.