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:
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:
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:
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:
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.
Documents/How_to/Violations,_alarms_and_notifications/en - GFDL | December 2024 | OpenSCADA 1+r3000 |