The purpose of this document

This document contains information on operation and configuration of the NextGen Alarm Screen (NG AS). The NG AS is replacing the existing AES of WinCC OA. Like the AES in WinCC OA, the NG AS acts as a common foundation for different framework- and application-specific alarm screens.

Main features of the Alarm Screen

The main purpose of the Alarm Screen is to provide a means for experts to observe the current state of alarms in the system, as well as investigate development of alarm states in the past. Alarms are displayed as rows in a table, with every column displaying different alarm properties. The set of columns is configured according to the requirements of the framework/system. There are two major modes of AS operation:

Live mode that displays the alarms that are currently active in the controlled system.
History mode that displays the alarms that appeared in the past and were stored in the archive.

In both modes, the user has the possibility to filter the set of displayed alarms based on the values of alarm properties; the set of available properties for filtering is configurable. Whenever possible, filter widgets use completers, providing the user with meaningful completion for strings as they are edited. Filter settings can be persisted for future use. Furthermore, it is possible to view the number of active alarms, matching any saved filter, in a very compact form, without seeing all the details of matching alarms - just their number. The overview of the controlled system can be built by combining several of such prepared filters.

The end user has a wide range of features for configuring the AS according to their particular needs, including the set of columns displayed in the table, the order of rows in the table, the default filter, etc. In addition, a hierarchical tree view (with alarms grouped by different properties at different levels of the tree) can be used instead of a flat table if such approach better suits the requirements. The prepared set of user settings can be persisted Several sets of user settings can be stored, and one of them can be nominated to be the default which is used when the AS is started.

Originally, the AS comes with all configuration features available to all users. However, the admin can configure the access rights such that certain features are available only to a selected group of users.

Improvements as compared to the previous solution

The previous solutions used at CERN are based on the built-in AES of WinCC OA. The major improvements brought by the new solution are the following:

The basic implementation uses C++, which is expected to result in better performance, especially on tables with many alarms.
More flexible and user-friendly configuration: 'almost human-readable' JSON format is used for all types of configurations. The whole configuration is stored in just one DPE, so the set of DPEs doesn't need to be extended when new functionality is added.
Unified approach to customization of running alarm screen, including admin and user settings. It is expected that a single set of configuration tools shall fulfill the needs of all project types.
The possibility of very precise configuration of the alarm screen's appearance, including disabling or hiding certain elements based on the access rights of the current user.
Relatively easy extension of the set of columns displayed in the alarm table: the basic implementation includes the most important properties of alarms; more can be added by plugins(s) written in C++. The basic implementation includes plugins for JCOP and UNICOS; their code can be used as the base for creating other plugins.
Similar plugin mechanism is used for building queries to retrieve alarms from ORACLE archives; more plugins can be added if some specific data needs to be retrieved from archive.

Terms

The basic terms used throughout the documentation are introduced in this section.

Alarm

The interpretation of 'an alarm' by WinCC OA may not meet intuitive expectations. Let's consider a simple example: a door that must normally be closed. There is a big red lamp which turns on when the door is opened. The alarm condition for this case is: 'the door is open'.

Door alarm example

The plot above displays the state of the door as a function of time: the green line corresponds to the closed door (normal state), the red line corresponds to the opened door (alarm state).

One could consider the red state on the plot above to be 'an alarm'. However, for WinCC OA 'an alarm' is not a state, but rather an event: a transition between a good and a bad state (or vice versa). Thus, from the WinCC OA point of view, there are two alarms on the plot above, corresponding to two transitions at moments t1 and t2 (the blue lines on plot):

CAME alarm at time t1, and
WENT alarm at time t2

These two alarms are physically and logically linked to each other: they represent the transitions between good and bad state for the same physical object (the door). Furthermore, the WENT alarm at time t2 is the end of the life cycle for the 'bad state', started by the CAME alarm at time t1. Such linked CAME and WENT alarms form an alarm pair. Internally, every alarm object of a pair has a reference to its partner: a WENT alarm has a reference to its CAME alarm, and the CAME alarm has a reference to the WENT alarm (if any).

More detailed information on alarms in WinCC OA, their logic, configuration and attributes can be found in the WinCC OA Online Help.

Alarm properties

The Alarm Screen displays alarms as rows in a table, with the columns displaying different alarm properties. The set of available properties includes:

Limited subset of attributes of the _alert_hdl config. This includes: DPE name, alarm time, alarm text, alarm priority, alarm color, etc.
The values, calculated from the attributes of _alert_hdl config. For example, the _comment attribute is used to calculate the total number of comments attached to the alarm, to be shown in the table.
The values which are not taken from the attributes of the _alert_hdl config, but rather from other sources. Some examples: DP/DPE alias, description, device type etc.

All alarm properties, displayed by the Alarm Screen in a particular project, are composed of two parts:

Basic properties, which are a part of the basic implementation. They are available in all projects where the NG AS is used, and they cannot be removed
In addition, every project can add its own properties. This is a relatively easy task, but it requires C++ coding (at least in the current version of the NG AS)

Alarm property source

Taking into account that alarms are naturally joined in pairs (see Alarm), it is a common practice to display just one row in the table for a pair of alarms. In such cases, it can be desirable to mix the values of properties of both CAME and WENT alarms in a table row.

In order to handle such use cases, the source of value has been introduced. Thus, when deciding what values shall be shown in table, one can select not only what property is to be shown in a particular column, but also from which alarm of a pair that property shall be read. Four types of sources have been introduced:

this: the value of a property for the 'main' alarm is shown in the table column
partner: the value of a property for the partner of the 'main' alarm is shown in the table column
came: the value of a property for the CAME alarm is shown in the table column, independently on what is the 'main' alarm for the table row
went: the value of a property for the WENT alarm is shown in the table column, independently on what is the 'main' alarm for the table row