Update cookies preferences
Promotic

Alarm and Event system

Alarms and events in the PROMOTIC system represents terms for catching and controlling technological actions.
- Alarm is a caught action (e.g. breakdown of valve) that arises, expires, and there is need to take notice of it by the user, by so-called acknowledgment.
- Event is a simplier type of action (e.g. actions of the user) that only arises and there is need just to record it.

Both terms are very similar and also have some common methods. The PmaAlarmGroup object is designed for one group oof alarms and the PmaEventGroup object for a group of events. Such objects can be in the application more than once. (e.g. if you want to separate communication and technological alarms or events from a boiler-room and a drying-room, etc.)

Creating of the concrete alarm/event:
Specific alarm/event can be created (i.e. define it for later activation/deactivation/acknowledgment, etc.) by various ways:
- Data extension: To use Data extension is the most standard and easy way for alarm/event creating. This is defined in data item of the PmaData object. System controls limit exceeding and by this it activates/deactivates alarm. Data extension of the type AlarmAnalog, AlarmBinary, ExtEvent can be used.
- Static alarms/events: Alarms (or events) can be defined directly in PmaAlarmGroup (or PmaEventGroup) object on the "Items" tab. These alarms/events must be activated in the script by the Activate method.
- Dynamic alarms/events: To avoid alarms/events to have to be defined in advance, then it is possible to define so-called template on the "Items" tab (see the "Template for dynamically created items" configurator) and then such alarms/events can be created dynamically in the script by methods PmaAlarmGroup.RegisterNew or PmaAlarmGroup.ActivateNew.


Creating a group by more objects:
If you want to have only one group of alarms/events (so that you could, for example, view all these alarms together) but you want to create it by more PmaAlarmGroup objects (e.g. you want to have one PmaAlarmGroup object for each boiler), then it can be done by as follows:
Create one PmaAlarmGroup object which will serve as the base (root) for all further objects. You parametrize it accordingly but you don't need to create even single alarm/event in this object. Then you create next PmaAlarmGroup objects on other relevat suitable places where you check the "Parent enabled" configurator and you set the path to the base object. Then you create required alarms/events in these objects.
Thus you'll maintain these alarms/events with these objects but internaly they are "pointed" to the base object. All alarms/events can be viewed together, they can be stored in one file, etc.

Local group (server) and remote group (client):
- Local group (server) - the most common case when the alarm/event group represents a place in the application where alarm items really arise and they are stored on the disk. The "Text file (*.al)" or "Database dBase backups" type of storage is used - see the "Storage type" configurator.
- Remote group (client) - the case when the application displays alarms/events that arise and they are stored in another application (server) that can run on another computer. The "Remote connection via the Web" type of storage is used - see the "Storage type" configurator.


Viewing alarms/events:
The objects PmgAlarmStateViewer, PmgAlarmHistoryViewer or PmgEventViewer are designed for viewing alarms/events. The object is usually located in the panel together with other utility objects (buttons, texts) and works as alarm state viewer, alarm history viewer, or event history viewer. The viewer is usually registered in the PmaAlarmGroup object or in the PmaEventGroup object. Registering the viewer into the alarm/event group allows it to intermediate the viewing of its alarms/events. Opening the registered viewer (created by panel) of intermediated alarm/event group is much easier thank opening the viewer directly, because the group provides the viewer with all important parameters that have to be provided for opening. Registration the viewer into the group therefore makes it easier to open the viewer for such alarm/event group.
Creating a viewer panel is not a trivial matter. Therefore, the PROMOTIC system contains preconfigurations of all three basic viewers (alarm states, alarm history and event history). When you resize the viewer in runtime, it adapts its content (zooming, moving graphic objects), and also works on the Web. When creating a new alarm/event group, it is possible to choose to create the appropriate viewers. The viewer can be created separately at any time later. This is a preconfigured panel that can be freely modified by the designer.
The registered viewers are opened via PmaAlarmGroup or PmaEventGroup by additional suffix /#state or /#history. The basic parameters are added (only if not provided previously) into the parameters sParams of the Pm.CreateView method and then passed to the viewer (PmaPanel object). Basic panel parameters of registered viewer:
- filter: Filtering string specifies which alarms/events will be displayed. This parameter is provided in the Pm.CreateView method. If not provided (is empty) then all alarms/events are displayed.
- grouppath: Path to alarm/event group. Provided automatically (if not defined) when opening the registered viewer.
- statepath: Path for opening the alarm state viewer. It is used only in the alarm history viewer - for implementation of switching into the alarm states viewer. Provided automatically (if not defined) when opening the registered viewer.
- historypath: Path for opening alarm history viewer. It is used only in the alarm state viewer - for implementation of switching into the alarm history viewer. Provided automatically (if not defined) when opening the registered viewer.
 
Open the specific registered viewer via the alarm/event group will be demonstrated (including examples) in the following paragraphs.

In the next the description of alarms/events differs and therefore we'll describe them separatelly:

Alarms

An alarm means signaling the state that wouldn't happen at normal conditions (e.g. a technological limit excess of the certain variable, communication error, etc.).

Open the registered state/history viewer in the form of the panel containing the PmgAlarmStateViewer/PmgAlarmHistoryViewer object by means of the PmaAlarmGroup object.
Example:
JavaScriptSelect and copy to clipboard

Pm.CreateView(null, "/Alarms/#state", "pars:{filter:{source:boiler1;}}", "target:main;").Open();
// or
Pm.CreateView(null, "/Alarms/#history", "pars:{filter:{source:boiler1;}}", "target:main;").Open();


Basic terms:
Alarm activation: Is an action when the alarm becomes active. For example a pump breaks down. The alarm can be activated by the following ways:
1. In the script by calling the PmaAlarmGroup.Activate or PmAlarmItem.Activate methods - useful for existing alarm items.
2. In the script by setting the PmAlarmItem.Active property - useful for simple activation/inactivation.
3. In the script by calling the PmaAlarmGroup.ActivateNew method - useful for creating new alarm item from template.

By the PmAlarmItem.Active property we can find out if the alarm is active.
Alarm inactivation: Is an action when the alarm stops to be active. For example the pump leaves the perturbance. The alarm can be inactivated by the following ways:
1. In the script by calling the methods PmaAlarmGroup.Inactivate or PmAlarmItem.Inactivate.
2. In the script by setting the PmAlarmItem.Active property - useful for simple activation/inactivation.
Alarm acknowledgment: Is an action when the user acknowledges the alarm in the application. For example he acknowledges that he takes into account that the pump is (or was) broken down. The alarm can be acknowledged by the following ways:
1. By alarm acknowledgment in the window with an outline of the alarm states for the specified group.
2. In the script by calling the methods PmaAlarmGroup.Acknowledge or PmAlarmItem.Acknowledge.

Caution: The user must have the "Acknowledge" permission. By means of the alarm you can find out if the alarm is acknowledged.


Each alarm can find itself in one of the following states:
Alarm state: Description:
active unacknowledged [red] An alarm that has been activated and no inactivation occurred nor the user acknowledged it.
active acknowledged [yellow] An alarm that has been activated, no inactivation occurred and the user acknowledged it. It doesn't happens at alarms where the "Acknowledgment type" configurator is set to "2 = acknowledgment and automatic inactivation".
inactive unacknowledged [blue] An alarm that has been inactivated but the user hasn't acknowledged it. It doesn't happens at alarms where the "Inactivate type" configurator is set to "2 = inactivation and automatic acknowledgment".
inactive acknowledged [green] An alarm that has been inactivated and if needed, the user has even acknowledged it.

The PmaAlarmGroup.onStateChange event is triggered for each change in state of each alarm in the PmaAlarmGroup object where the alarm is defined.

Suspicious alarms (delayed activation and deactivation):
It is set in configurators Activate delay [sec] and Inactivate delay [sec] that allow not to activate/deactivate the alarm right immediately but instead of this to set it into the suspicious state for activation or deactivation. The suspicion changes into the real alarm activation/deactivation or the suspicion expires after the specified time.
By this method it is possible to prevent unnecessary activation/inactivation of alarms caused by some swings of values of the watched variable, for example, by the interference or failure of the communication. By this method it is also possible to implement alarms for the actions with the 'timeout', when the alarm is activated with delayed activation before such action and after detection of the successful termination of the action, the alarm is deactivated.
If the action is not successfully terminated in the set time, then the alarm in the suspicion is activated automatically in the set time.

In the alarm state viewer each alarm is stated only once usually. For each alarm there is always the most current state of it.
If the alarm has checked Delete inactive acknowledged (green) in configuration, then the alarm from the list of active alarms disappears if it becomes inactive acknowledged [green].
If the value of the "Number of inactive, unacknowledged older copies of the (blue) alarm" configurator of the PmaAlarmGroup object is greater than 1, then alarms that wait for the acknowledgment, remain in the list even after activation of new alarm with the same name. In this only case a situation when there are more the same alarms in the alarm state viewer, can occur.

In the running application the list of alarm groups can be viewed by clicking the "Alarms" icon. The icon is in the toolbar that is created automatically on creation of the new application.
In the window with the alarm groups list there is an outline of all alarm groups. There is stated the number of alarms:
- unacknowledged - inactive unacknowledged [blue] and
- sounded alarms in each group.

By left mouse button double-clicking the name of any group to open the status overview of alarms in the given group. In this window, the alarms can be viewed and acknowledged. If is enabled, then it is also possible to set and save (buttons "Settings" and "Save") columns widths, color of alarm states, format of displayed time, etc.
But each line of the viewer informs only about the time of the last alarm activation/inactivation/acknowledgment. The whole history of all alarms can be displayed by clicking the "History" button. By this the window for all history overview of all alarms from the group is opened. In this window it is possible to view the history of all alarms in the specified group.

Events

Event is a notification about the execution of the operation (e.g. starting, ending or a success rate about the process, etc.). This notification is written to disk for later viewing. Something like a "chronicle" about running the technology is created.

Open the registered history viewer in the form of the panel containing the PmgEventViewer object by means of the PmaEventGroup object.
Example:
JavaScriptVBScriptSelect and copy to clipboard

var oCreator = Pm.CreateView(null, "/Events/#history", "pars:{filter:{source:boiler1;}}", "target:main;");
oCreator.Open();


Contrary to alarms, events are only activated. The terms "deactivation" and "acknowledgment" needn't be used here because you can imagine it so that events are deactivated and acknowledged already during its activation. The events activation is performed in the script by methods PmaEventGroup.ActivateNew, PmaEventGroup.Activate or PmEventItem.Activate.

In the running application it is possible to view the list of event groups by clicking the "Events" icon. The icon finds itself in the toolbar that is created automatically on creating of the new application.
There is an overview of all event groups in the window with the list of event groups. By left mouse button double-clicking the name of any event group a window with the history overview of the group is opened. In this window it is possible to view the history of all events in the group.

History:
Pm8.03.00:
- The history can now be saved also to Database MS SQL Server cyclic and Database Oracle cyclic (see the "Storage type" configurator).
- History viewer:
- The scrollbar has been replaced by buttons "up" and "down".
- Sorting by the time of origin is now functional, i.e. new alarms now can be displayed on up.
- The state and history viewer can now be opened multiple times, i.e. to have a small window permanently open and open large window sometimes.
Pm8.02.09:
- When switching from status viewer to history viewer the view settings and filtering did reset.
- The state browser on the Web was fixed in order to display larger number of alarms.
Pm8.02.05: If the "Storage type" configurator in the PmaAlarmGroup object was set to "Remote connection via the Web" value, then:
- sometimes the GetHistoryData method malfunctioned.
- the status viewer displayed the alarms in wrong colors shortly after opened. The patch has also been included into the version Pm8.1.11.
- the history viewer sometimes caused the system crash. The patch has also been included into the version Pm8.1.11.
- if the alarm is acknowledged by a remote user then more information is available concerning the user. The patch has also been included into the version Pm8.1.11.
- the status viewer did not display the AckerId and UserNote columns on the client side. The patch has also been included into the version Pm8.1.11.
Pm8.02.00:
- Now it is possible to save the history also into dBase DBF files, see the "Storage type" configurator and "Parameters for type: Database dBase backups".
- When saving the text files, the *.alc/*.evc type files are no longer created. The backup list is now created automatically.
Pm8.01.11: If the "Storage type" configurator in the PmaAlarmGroup object was set to "Remote connection via the Web" value, then:
- the status viewer displayed the alarms in wrong colors shortly when opening. The patch has also been included into the version Pm8.2.5.
- the history viewer sometimes caused the system crash. The patch has also been included into the version Pm8.2.5.
- after acknowledgment by a remote user then more information is available concerning the user. The patch has also been included into the version Pm8.2.5.
- the status viewer did not display the AckerId and UserNote columns on the client side. The patch has also been included into the version Pm8.2.5.
Pm8.00.11: In Windows OS XP, when opening the viewer some blank grey areas were drawn.
Pm8.00.10: for viewing the alarm history on the Web the scrollbar control has been improved.
PROMOTIC 9.0.31 SCADA system documentation MICROSYS, spol. s r.o.

Send page remarkContact responsible person
© MICROSYS, spol. s r.o.