AlarmScreenNg 0.9.6
|
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.
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:
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.
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 terms used throughout the documentation are introduced in this section.
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'.
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):
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.
The Alarm Screen displays alarms as rows in a table, with the columns displaying different alarm properties. The set of available properties includes:
All alarm properties, displayed by the Alarm Screen in a particular project, are composed of two parts:
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: