Documents/How to/Violations, alarms and notifications

Violations and work with them in OpenSCADA are implemented in two ways, which is related to the structure of OpenSCADA, ways of its use, as well as the very nature of violations.

The first aspect of the violations with which OpenSCADA works from the start and which is most demanded is the notification in various ways. Since the notification is part of the user interface, it is implemented in the visualization engine UI.VCAEngine and the visualizers UI.Vision, UI.WebVision. Currently, the notification mechanism about the violates implements following functions, that have not yet been partially implemented in UI.WebVision:

• Notification:
  • Visual — blinking in an alarm color for the object, the signaling group and the general status.
  • Beep — issuing a continuous signal, usually on the system "buzzer", and regardless of the violation.
  • Sound — playing a sound file or the speech synthesis from a text, associated with the violation.
  • By expanded special ways and through special notification mechanisms.
• Quietance of the violation notification:
  • Fully — by clicking on the colored flashing circle status of violations (the event "ws_alarmLev"), to the right bottom.
  • By the notification way — separately visual (the event "ws_alarmNtf0"), beep (the event "ws_alarmNtf1"), audio (the event "ws_alarmNtf2") and expanded (the event "ws_alarmNtf{N}"); by pressing the button with the corresponding image to the right of the bottom or under the view types buttons.
  • By the violation object — the visual presentation shape can be appended for the quietance command of the notification, directly by itself;
  • In turn, with listening — is characterized for the sound notifications, because each object of the violation can provide its own sound message or synthesis of speech.

In the visualization environment, in the implementation of notifications, there is no established rule for obtaining and forming a violation flag, since there is no unambiguousness in different situations. For now, in the side of the typed data source templates, a method is used to create the error attribute "err" with the codes and the text of the violation, and their processing and notification generation is already in the visual shape data object.

Subsequently, there was a need for logging, as well as the accounting of current violations. If for logging it is enough to form messages of the program with the specified category and message format, but for accounting of the current violations some buffer is needed. Such buffer has been added as an add-in over the subsystem of messages, and the addressing to it is carried out by the inversion of the message level. So, writing a message with the level "-2" and the category "TEST" will put the message in the violation buffer and duplicate it in the message archive. When requesting messages with a negative level, messages will be taken from the buffer of violations. Deletion-removal of the violation is made by writing a message with the same category "TEST" and non-negative level.

Such concept of accounting the actual violations allows you to use the standard mechanisms of the messages processing:

• Alarm-violation registration: SYS.message("alCategory", -3, "Parameter: alarm");
• The alarm-violation removing: SYS.message("alCategory", 1, "Parameter: normal");
• Creating a list of the actual (active) alarms by means of the primitives "Protocol" or "Document", with the negative level for all — "-1".

The registration of violations is best done on the side of the typed data source templates, through the special function SYS.DAQ["Module"]["Controller"].alarmSet(string mess, int lev = -5, string prm = "", bool force = false) or its parameter-space variant SYS.DAQ["Modul"]["Controller"]["Parameter"].alarmSet(string mess, int lev = -5, bool force = false), which unifies the category. To call this functions from the context of the template you need to add the IO "this" of the type "Object", and then the setting of the violation will have a look this.alarmSet("Parameter: Violation", -5);. The specified function is currently used in many data source modules to account for global violations of the controller objects. The function provides control for the toggling of the messages passing to the message buffer, so you may safely re-generate and clean up violations with this functions, without flooding the archive messages and what may be useful for the periodic actualization of the violation state.

The function generates a violation with the category al{ModId}:{CntrId}[.{PrmId}] and the text {CntrNm} > {PrmNm}: {MessText}, where:

• ModId — identifier of the module;
• CntrId — identifier of the controller object;
• PrmId — identifier of the parameter from the prm argument in the form {PrmId}\n{PrmNm};
• CntrNm — name of the controller object;
• PrmNm — parameter name, from the argument prm in the form {PrmId}\n{PrmNm};
• MessText — message text.

The format of the message text is not regulated by these functions, but there is a practice of forming the text of the violation, defined by the cadres of the formation of accounting documents such as "Protocol of violations", where the format is: {PrmId}: {PrmName}: {Alarm} and where additionally defined:

• PrmName — name of the parameter;
• Alarm — text of the violation or "NORM" for the violation withdrawing.

In general, it should be noted that violations notification and accounting are different mechanisms that can be used separately — for simple projects, or together — for large-complex projects.