From OpenSCADAWiki
Jump to: navigation, search
This page is a translated version of the page Documents/How to/Violations, alarms and notifications and the translation is 100% complete.

Other languages:
English • ‎российский • ‎українська

Автор: Роман Савоченко

Порушення та робота з ними у 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 = ""), яка уніфікує категорію. Для виклику цієї функції з контексту шаблону треба додати IO "this" типу "Об'єкт", після чого встановлення порушення матиме вигляд this.cntr().alarmSet("Параметр: порушення", -5, "prm");. Вказана функція наразі використовується у багатьох модулях джерел даних, для обліку глобальних порушень об'єктів контролерів.

Функція формує порушення з категорією: al{ModId}:{CntrId}[.{PrmId}], де:

  • ModId — ідентифікатор модуля;
  • CntrId — ідентифікатор об'єкту контролера;
  • PrmId — ідентифікатор параметру, з аргументу prm.

Формат тексту цією функцією не регламентуються, але є практика формування тексту порушення, визначена кадрами формування звітних документів на кшталт "Протокол порушень", де застосовується формат: {PrmId}: {PrmName}: {Alarm} та де додатково визначено:

  • PrmName — ім'я параметру;
  • Alarm — текст порушення або "НОРМА" для зняття порушення.

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