AlarmScreenNg  0.9.5
Using the Alarm Screen

The core component of the NG AS is a dedicated EWO (External Widget Object), which can be placed in WinCC OA panels (like any other EWO), and with some (optional) CTRL code will result in a fully functional Alarm Screen panel.

The main components of the NG AS EWO are illustrated in the following picture:

The main components of the NG AS EWO
  1. The filter view area, similar to the existing Alarm Groups functionality: every widget in this area displays statistics of alarms in a selected filter. See Filter Views (~Alarm Groups)
  2. The source control area, used for switching between live and history types of source, and for selecting parameters used for archive query.
  3. The filter editor area contains a number of widgets, allowing to specify criteria that alarms need to fulfill in order to be visible in the Alarm Table. See Filter editor.
  4. Alarm Table displays alarms according to the applied filter, grouping and sorting settings. See table description.
  5. The Footer informs the user about the number of alarms and potential problems affecting their display, such as broken distributed connection. This area also contains a toolbar for performing some common actions (both common and application-specific).

All the AS parts are optional (except for the Alarm Table) - they can be shown or hidden by changing the configuration. In addition, the AS EWO includes two splitters, allowing the source control + filter editor and footer areas to be resized or hidden by dragging the boundary between areas:

Resize the filter editor area by dragging the splitter

The Alarm Table

The core of the AS EWO is a table that displays selected properties of alarms, according to the applied filtering, grouping and ordering settings. The set of available columns is configured by the project administrator (see columns); the set of currently visible columns, as well as their order, can also be configured by the end user (see user settings editor).

Other elements of the EWO (see picture) are mainly used to configure what is displayed in the table and how exactly the information on alarms is displayed.

Types of alarm sources: live and history modes

There are two major sources of alarms to be shown in the table:

  • Live data coming from the running system(s). When this type of source is selected, a connection to DPEs is performed (using dpQueryConnectSingle()) and the contents of the table reflect the current state of system. The table is immediately updated when any alarm-related events occur in the system.
  • Alarms history with data queried from the archive. With this type of source, the table is filled once, on explicit user's request, and then remains constant until next user request.

The type of the source is selected by combo box, located on the left of the source control area. The combo box is only enabled if ORACLE credentials have been entered by the admin; see ORACLE archive connection for details.

Source type selection

When History source type is selected - more controls, specific to history source mode, appear next to combo box:

Extra controls for history source

These extra controls are buttons, displaying current selection of:

  1. Time interval for query of archived data.
  2. Number of systems for which data shall be quesried from archive.

When clicking either of these buttons, popup window appears where the value can be edited. The editor of time interval looks as following:

Editor of time interval for query

The meaning of types of time interval, which can be selected in combo box, shall be clear from thir names. Some types require extra number to clarify - for example 'last N hours' require the value N to be specified - this value is edited by spinboxa located next to combo box. Two time editor fields (labeled From and to) are used to display the resulting time interval for selected type of interval. They can also be used for direct editing of time interval when Arbitrary interval type is selected.

The editor of systems to select is described in other section.

To summarize, the most important differences between the Live and History modes are as follows:

  • Using the Live source results in displaying the 'current state' (snapshot) of all active alarms in the table, while the History mode displays the sequence of alarms in the selected time range. The differences between them are subtle but very important.
  • As a consequence of the previous statement, the following observation can be made:
    • If both alarms of a pair are active, then for the Live source the user will see both alarms in the table. The table can also be configured to display both alarms in one row.
    • However, for the History source it is possible that only one alarm of the pair is displayed - for example, if the time of the second alarm in the pair is outside of the selected time range.
  • The approach for displaying alarms in the Live mode is simple: display all active alarms matching the filters. In the History mode, the approach is completely different: only a limited number of alarms can be shown, as configured by the admin. The reason for the difference, is an assumption that it is unlikely that a live will contain hundreds of thousands of alarms simultaneously. However, the archives can contain tens of millions of alarms, especially when long time intervals are selected. It was therefore decided that displaying a limited number of alarms is a much better strategy than risking allocating too much memory, especially on shared machines.
  • No extra configuration is needed for the Live source: the AS can display alarms from any connected distributed system. However, the History source needs information on how to connect to the ORACLE DB containing the archives. Therefore, before switching to the History mode is possible, the admin must enter the appropriate configuration settings.
  • The Live source results in a 'live' display: the contents of the table change to reflect the changes in the running system. In contrast, the table is 'frozen' when the History source is used: it displays the result of the last query (with a given time range, systems selection and filter); the contents of the table can only be changed by an explicit user request.
    Note
    The visible contents of the table in the History mode can still be filtered thanks to the quick filter feature.
  • The filter view area only works in the Live mode; the area is hidden when the History source is used.
  • The History mode may display alarms for DPEs which do not exist in the live system anymore.

Selection of systems

One of the primary settings for the AS is selecting the list of systems from which alarms shall be displayed. The selection of systems is performed differently depending on whether the Live or History mode is used (see Types of alarm sources: live and history modes).

Live alarm source

For the Live source, the control of the system connections is located on the right-hand side of the footer. The widget consists of two parts:

  • The label displaying the number of systems to which the AS is connected now
  • The button next to the label allows to connect/disconnect select systems; clicking on the button opens a popup menu with names of available (known) systems
System selection in the Live mode

Such widget may be convenient if the system is connected to a few peers. If the list of systems gets very long, another appearance/functionality can be configured:

  • The 'system map' widget can be displayed in addition to the label with the number of connected systems
  • The button will now open a dedicated dialog where all systems are shown in a table

The system map is a simple rectangular widget, displaying all known systems in a grid, with the color of every cell corresponding to the state of one system:

  • green: the AS is connected to the system
  • yellow: the AS is not connected to the system, but the distributed connection has been established
  • red: connection to system is not available, for example due to the remote system being stopped

An example connection map is presented in the following picture, for a use case with four systems:

Connection map widget

Tooltips for individual cells in the grid display the names of the systems.

The dialog for controlling connections to individual systems is shown in the following picture:

System connections dialog

In this example, the distributed system consists of four individual systems, so the dialog does not have evident advantages compared to the simple popup menu. However, the situation changes dramatically in large distributed systems.

Both the popup menu and the dialog have indicators showing which systems can not be connected to (for example, system as_test_3 in the pictures above).

Automatic connection to available systems depending on their name is an important feature of the live mode. If a system becomes available when the AS is running in live mode, the AS can connect to it automatically, provided that its name matches one of the patterns defined in the configuration.

History alarm source

Selection of systems for the History alarm source works differently compared to the Live source. It is performed in a dedicated popup table that appears when the button with the system count is activated (see picture). All known systems are shown in the table, with additional functionality for selecting multiple systems:

Selecting systems for history mode queries

Individual systems in the table can still be selected/unselected using checkboxes in the cells. In addition, 'group selection' is possible using the following scenario:

  • the filter on systems names is entered in the text field
  • all systems, whose name matches this filter, are highlighted in the table (cyan background)
  • then the two buttons next to the filter can be used to either select or unselect all the highlighted cells This group selection can be repeated as many times as needed, with different filter texts, until the user is happy with the resulting list of selected systems.

Interacting with alarms in the table

Once alarms are displayed in the table, the user can perform some actions just by clicking in the cells. Like in other applications, there are two major variants of user actions, initiated by pressing left or right mouse button.

The processing of mouse button clicks is not done by the AS EWO itself, but by Control functions. What exactly is done is defined by a Control function, which is configurable. The basic implementation of the AS just calls that function, passing enough information about the clicked alarm and pressed mouse button.

As a consequence, this document describes two implementations - for JCOP and UNICOS frameworks - which follow closely the functionality available in the 'old' AS.

JCOP

Left mouse button clicks

The action depends on the column where the mouse click occurred:

Table columns in the default JCOP config
  1. Ack. column (the 'summary' state of alarm acknowledgement): the alarm in the current row will be acknowledged (if possible). Available only in the Live mode.
  2. Com column (the number of comments for this alarm): opens the standard WinCC OA panel for editing alarm comments. Available only in the Live mode.
  3. > column (column with the name of the default panel): opens a custom panel, related to the alarm, provided that its _panel attribute is not empty.
  4. ... column: opens the standard WinCC OA panel for viewing alarm details. Available only in the Live mode.

Right mouse button

Pressing right mouse button opens the popup menu configured by the admin. The default menu configuration (when AS component was just installed) contains the following items:

The default popup menu for the JCOP configuration
  • FSM Panel: opens the FSM panel for the device for which alarm occurred. The item is disabled if the DPE of alarm does not exist (possible in the History mode).
  • Details: opens the standard WinCC OA panel for viewing alarm details. The item is disabled if the table displays alarms for the History source type.
  • Trend: opens the trend of the value of the DPE which produced the alarm. The item is disabled for summary alarms, as well as if table displays alarms for the History source type.
    Note
    The last limitation is caused by the fact that archived alarms do not contain the _sum attribute.
  • Alarm Help: opens the help page for the alarm (see Help File Types). The item is disabled if the DPE of the alarm does not exist (possible in the History mode).
  • Comment Panel: opens the standard WinCC OA panel for editing alarm comments. The item is disabled if the table displays alarms for the History source type.
  • Mask Alarm: mask alarm so that it is not shown in table; if the alarm is already masked then the menu item is called Unmask Alarm and its action changes appropriately. Masking is performed by setting the _force_filtered attribute of the alert config. The item is disabled if the table displays alarms for the History source type. In addition, this menu item is hidden if the basic configuration disables alarms masking.

In addition to the logic described above, the admin can set up visibility/availability of individual items in the menu depending on the access rights of the current user.

UNICOS

Left mouse button

The action depends on the column where the mouse click occurred:

  • Ack. column (the 'summary' state of alarm acknowledgement): all alarms for the device will be acknowledged. This only works if the table displays alarms for the Live source type.
  • S column (faceplate existence): opens the faceplate panel for the device. This only works if the table displays alarms for the Live source type.

Right mouse button

Pressing the right mouse button opens a popup menu, but the contents of the menu are very different depending on whether the DPE for which the alarm is displayed still exists in the system (alarms for DPEs removed from the system can be displayed in the table when the History source type is used).

When the DPE of the alarm exists, the default popup menu for the UNICOS device is displayed, with some AS-specific additions:

The popup menu for a UNICOS device in the AS; DPE exists
  1. Copy the whole line to the clipboard.
  2. Open the standard WinCC OA panel for viewing alarm details. The item is disabled if the table displays alarms for the History source type.
  3. Open the standard WinCC OA panel for editing alarm comments. The item is disabled if the table displays alarms for the History source type.
  4. Open a submenu allowing to display/hide the columns in table.


However, if the DPE of the alarm does not exist anymore, the popup menu is very reduced compared to the menu on picture above:

The popup menu for a UNICOS device in the AS; DPE does not exists

Acknowledging multiple alarms in one go

Acknowledging is one of very common tasks when working with alarms. It is used to mark the fact that the user (operator) has seen the alarm and is (probably) taking care of it. The 'acknowledgement state' is a property of every alarm.

Alarms can be acknowledged one by one, or per device (see table actions). In addition, the AS provides the possibility to acknowledge multiple alarms in one go. The AS footer contains a button labelled Acknowledge multiple...; clicking this button allows to select one of the multiple acknowledgement modes.

Variants of multiple acknowledgement

The labels are meant to be self-explanatory, though some comments could be useful.

  • The admin can configure the access control such that multiple acknowledgement is available/visible only to a restricted set of users.
  • Only the alarms contained in the table can be affected by the acknowledgement. For example, if the system contains 1000 alarms, but table only displays 100 of them because of the current filter, then only the 100 alarms in table can be acknowledged.
  • 'Selected' means 'selected alarm', not 'selected row'. The difference can be important if the table displays alarms in a tree due to applied grouping: in such case selecting a group node in the tree does not mean selecting all of its child nodes.
  • Not all alarms, displayed in table, can be acknowledged. The alarms which are already acknowledged are out of scope for these actions. For other alarms, the decision is usually taken based on _ackable, _oldest_ack and _ack_oblig attributes; see the WinCC OA documentation for more details.
  • The actual operation is not performed by the AS EWO itself, but by Control code; see the corresponding configuration settings. Two implementations have been developed so far, for JCOP and UNICOS frameworks.

Filter editor

The filter editor is used to enter filters that specify the criteria that alarms need to fulfill in order to be visible in the alarm table.

There are two types of filters in the filter editor area of the AS EWO:

Two types of filters
  1. Structured filter contains a number of widgets, with each widget used to specify criteria for a single table column (or, to be more precise, for a single alarm property, and that property does not have to appear as column in the table). Very complex filters can be built if needed by combining criteria for individual properties.
  2. Quick filter is used to find occurrences of a given string, wildcard pattern or regular expression in any column of the table

These two types of filters are described in more details in the following sections.

Structured filters (entered using widgets)

The structured filter area in the AS is divided horizontally into three distinct parts:

Structured filter area
  1. Editor of structured filters
  2. Buttons in the structured filter area

Editor of structured filters

The structured filter editor allows to build complex filters by combining criteria for individual alarm properties, and then by combining resulting sets of individual filters.

A complete structured filter may be built of several filter sets. In the filter editor, every filter set is shown as a separate tab:

Filter sets of a structured filter

The tab labeled '+' is used for adding new tabs (filter sets) to the filter.

Filters for individual alarm properties in a single tab are joined by logical AND, i.e. an alarm shall match all non-empty filters given in one tab in order to pass the filter. Sets of individual filters defined by tabs can be either used to include alarms matching the criteria to the table, or for excluding them. This is changed using the Filter type radio box. For example, one can create two tabs:

  • Filter type = include, Alarm text = 'error'
  • Filter type = exclude, Alarm text = 'no error'

Combining these two filters will result in displaying all alarms which contain the 'error' string in their alarm text, except for the ones that contain the string 'no error'.

The set of widgets for editing criteria for individual alarm properties on one tab, as well as the rules for working with these widgets, are configurable (see FilterWidget). Two filtering widgets have been developed so far, for JCOP (fwAlarmScreenNg) and UNICOS (unAlarmScreenNg). There are some common considerations, applicable to all of them.

All available (implemented) filter types can be subdivided into two main categories with respect to the user's ability to edit them:

  • Editable filters: the user can specify any (allowed/valid) criteria for comparing with the value of alarm property. For example, 'alarm priorities in range 1 to 20', or 'alarm text like error'
  • Fixed filters: the criteria are hard-coded; the user can only choose to switch such filter ON or OFF. The JCOP filter on alarms severity (Warning/Error/Fault) is an example of this behaviour. There is a range of alarm priority values behind each of the buttons (W/E/F), but the users can not edit the range; they can only switch each of the filters ON or OFF.

Every editable filter may be presented in different forms (== different widgets). The basic implementation includes three different types of widgets for the filter editor:

  1. String pattern editor is used for filtering strings using patterns with wildcard support. UNIX-style wildcards are supported: the asterisk * character matches zero or more characters; the question mark ? matches any single character.

    Note
    Other characters can be used as wildcards instead of the standard * and ? (e.g. % and _), see wildcards. This option can be very useful if the standard wildcard characters are expected to often appear in filtered strings.

    In addition, sets of characters in square brackets can be used, but this is not recommended when the History source is used, see Notes on filtering in the History mode.

    A single editor widget may contain several patterns separated by the semicolon ; character; the value of the alarm property will match the filter if it matches any of the patterns. For example, for the 'abc*;def*' pattern, any string starting with 'abc' or 'def' will match.

    Whenever possible, string pattern editors supports completers: when the user starts typing a word, the editor will suggest possible ways of completing the word, based on the word list it was configured with.

    A completer in action
  2. Single value selector is used when only one of possible values should be used for filtering at a time; this is the well-known combo box widget.
  3. Numbers editor is a text editor where one can specify complex criteria for numeric values of alarm properties.

    The filter string may contain several individual rules separated by the comma , character; a numeric value matches the filter if it matches any of the rules. The following rule types are supported:

    • Comparison with a single value. For example:
      • 123 the value must be equal to 123
      • <123 the value must be less than 123
      • >123 the value must be greater than 123
    • Comparison with a range of values. For example: 123-456 the value must be in the range from 123 to 456

    Both conditions can be prefixed with an exclamation mark (!) to negate the condition, for example:

    !123 the value must not be equal to 123

Buttons in the structured filter area

The set of buttons related to filters is located on the right side of the filter area.

Buttons in the filter area
  1. Toggle button for switching between case-sensitive and case-insensitive string comparison; this single setting applies to all string patterns in the filter editor.
    Note
    Be careful when using case-insensitive comparison in the History mode, as this can significantly slow down query execution (see Notes on filtering in the History mode).
  2. Save the current structured filter for future use; this opens the following panel:

    Saving the current structured filter

    The functionality of the panel is similar to the standard 'Save file' dialog, available in many editors. The check box 'My Filters' is used to only display the filters saved by the current WinCC OA user.

    The filter is saved in a dedicated DP as string in the JSON format.

    Note
    Even though the source type selection control appears to be a part of the filter, its value is not saved with the filter.
  3. Load and apply a previously saved filter.
  4. This label appears when the current contents of the structured filter editor widget differs from the filter applied to the table. This serves as a reminder: don't forget to click the 'Apply' button in order for the new filter to be used.
  5. Clear the contents of the filter editor. In principle, there are two possible interpretations of the term 'clear' in this context:

    • Set all filter fields to empty, such that the resulting filter includes all alarms.
    • Display the 'default' filter in the editor. The default filter is a part of previously saved user settings.

    If the two options are available at the moment the button was clicked, a small popup menu is presented to the user in order to choose one of the options.

    In either case, clearing the filter means just modifying the contents of the filter editor widget - the new filter is not applied to table automatically.

  6. Apply the filter displayed in the filter editor to the table. Applying the filter works differently for different source types:
    • For the Live source, the filter is just applied to the set of known alarms stored in memory; this is typically a very fast operation, unless many thousands of alarms are active in the systems the AS is connected to.
    • For the History source, applying the filter means executing a query on the archives and replacing the current contents of the table with its result.

Notes on filtering in the History mode

Using structured filters in the History mode comes with several important caveats described in this section.

  • Applying a structured filter in the History mode is performed by executing a query on the archived data. Applying every new filter means executing a new query and the result of the previous query is completely removed. This behavior is different from the Live mode, where all active alarms are cached inside the AS (see AS architecture); applying a new filter in the Live mode just decides which of the cached alarms shall be displayed.
  • It is assumed that the Live alarm source can produce a rather limited number of alarms to be cached by the AS simultaneously, i.e. the number of active alarms is not expected to be extremely high (in the range of hundreds of thousands), at least not during normal operation. In contrast, the History source queries can return a huge number of alarms, especially when long time intervals are selected. In order to prevent the AS from allocating too much memory, the number of alarms retrieved from the archive is limited by the configuration.
  • When a filter is applied in the History mode, the AS tries to convert its every field to a corresponding filter predicate in the ORACLE query (typically - extra predicates in the WHERE clause). Ideally, all conditions are mapped in the ORACLE query, but this not always possible. For example, string patterns that contain a set of characters in square brackets [] cannot be expressed in the ORACLE query.

    For this reason, the filtering is performed in two steps in the History mode:

    • First filtering is performed by the predicates in the ORACLE query.
    • Then, the query results are additionally filtered by the C++ code, in the same way as in the Live mode.

    As a consequence, more complex (not fully-translatable) filters are processed differently than simpler (fully-translatable) ones:

    • For simple filters, the maximum number of alarms to be returned is specified in the query, allowing ORACLE to take the limit into account and (potentially) to execute the query faster.
    • For complex filters, the maximum number of alarms to be returned is not specified in the query; instead the limit is applied by the AS code during processing of the query results.

    clown car

  • Performance of queries in the history mode can be affected by several issues. Some of them are predictable, but there can be some queries that are unexpectedly slow if the ORACLE database chooses a 'wrong' execution plan. Some examples of predictable reasons for slower query execution:
    • Using case-insensitive string comparison is in general slower compared than case-sensitive.
    • Filtering by string patterns starting with a wildcard (* or ?) is in general slower than with wildcards inside (or at the end of) a string pattern.
    • Using criteria on alarm attributes of type langString (e.g. alarm text) is in general slower than criteria on alarm attributes of type string (e.g. alarm DPE) because of the way they are stored in ORACLE archive.
    The execution of queries for the History mode can sometimes take very long time. For this reason, the source control displays a button that allows to abort running the running query. Of course, this does not make query execution faster, but it gives the user a chance to refine the query if the current one is taking too long.

Quick Filter

The quick filter, located just above the table, can be used for searching for rows that contain a text or a pattern in any of the visible columns.

There is no special button for applying the quick filter - it is done immediately when the Enter key is pressed, or when focus leaves the quick filter editor. A quick filter that is not applied yet is indicated with a pale yellow text background.

Unlike rather complex and rich structured filter, the quick filter was designed to be very simple, and enable fast searching through the data already displayed in the table. Still, there are some quick filter options can be configured; the configuration popup can be opened by clicking the wrench icon at the beginning of the pattern editor:

Configuration of the quick filter

All configuration options should be self-explanatory, except for 'Match full column':

  • if the box is checked then the pattern App in the quick filter does not match the Application string in one of the table columns
  • if the box is not checked then the pattern App in the quick filter matches the Application string in one of table columns

In short - when the box is unchecked, the filter pattern only has to match a part of any of the columns.

Other essential differences between the quick filter and the structured filter:

  • the quick filter can not be saved for future loading
  • the quick filter is applied in the same way independently of the source type, i.e. applying a new quick filter does not result in a new query to the archive when the History mode is used.

Sorting the table

The order or rows in the table can be changed by clicking the header of a column whose content shall be used for sorting. This works in the Alarm Table, except for the first (grouping) column when alarms are grouped. The sort order in the grouping column is fixed and cannot be changed by clicking the column headers; it can only be changed by editing the user settings. This is done in order to keep the order of groups constant, while still allowing to change the order of alarms in the groups.

Simple 'sort by click' approach only allows to sort alarm by a single column. Sorting by more than one column can be requested in the the user settings editor.

Grouping alarms in the table

From the visual point of view, the table can operate in two modes:

  • Flat table mode, as illustrated in the picture
  • Tree mode, when alarms are grouped by the values of selected alarm properties. The set of alarm properties for grouping alarms is configurable, see the user settings editor. The following picture illustrates the appearance of the table when two levels of grouping are configured: system name and device type. If grouping is used, then one more column is added to the table as the very first column in row. This extra column displays group nodes; each group node displays the value of the alarm property selected for grouping and the total number of alarms in this group.
Grouping by system name and device type

If the table displays alarms in the tree mode, a special popup menu is available when pressing the right mouse button on tree nodes in the grouping (first) column:

Popup menu for group nodes in the tree

Selecting rows in the table

Selecting single or multiple rows in the table works like in other tables. However, the interpretation of the selection made by user depends on how this selection is used later, though the difference is only noticeable when the alarms are displayed in the tree mode:

  • If the selection is used for a 'neutral' purpose (for example: 'export selected to CSV' - see Exporting alarms), then selecting a grouping row also means selecting all of the children in this group. In other words, in such cases the selection is automatically propagated down in the tree hierarchy.
  • If the selection is done for a 'potentially dangerous' purpose (for example, to acknowledge all selected alarms), then the group selection is not propagated down in the tree hierarchy. In order for an alarm to be selected for acknowledgement, its table must be explictly selected - it is not enough to select its parent group.

Filter Views (~Alarm Groups)

In large systems with many alarms, it is convenient to have an overview of active alarms, providing a summary of the system's state. In such case, the alarm table in the tree mode can be used, but Filter views offer a more advanced alternative.

The basic idea is very simple:

  • The user creates and saves a number of filters, each filter corresponding to a unit of grouping (e.g. one filter per subdetector, or per building).
  • The filters can then be added to the filter view.
  • Finally, every filter is shown in filter view area, with the number of active alarms matching that filter.

Thus, the overview of a large and complex system can appear in a compact form. The filter view also allows to switch between the filters contained within it by clicking on their corresponding cells, acting as a kind of a clickable 'table of contents' for the system.

The following picture presents an example of a very simple filter view, containing only three items:

Example of a simple filter view

Every item in the view displays: the filter name, the total number of active alarms and the number of unacknowledged alarms (in brackets). The background color of every item corresponds to the color of 'the most severe' alarm (in terms of priority) matching this filter.

As mentioned before, clicking on an item in a filter view applies its filter to the table. This also works in the opposite direction: the item of the filter view whose filter matches the current structured filter applied to the table is highlighted (with a thin yellow border - see the item in left top corner on picture above).

The AS provides many options for configuring the contents and appearance for the filter view as a whole as well as for the individual items in the view.

Warning
Filter views can only be used in the Live mode - they are automatically hidden when the History mode is enabled.

Exporting alarms

It is possible to copy the contents of the table to another document, or to save them in some 'commonly understandable' format. The AS provides two features for such operations:

  • Select one or more rows in the table, then press Ctrl+C. The clipboard now contains the values of all columns in the selected rows, plus the headers. This text can be inserted wherever needed (in a text editor, for example) with the Ctrl+V key combination.
  • Dedicated button in the footer area of the AS:

    The button for exporting the table to a CSV file

    Clicking this button first presents a small dialog with export options:

    Options for exporting the table to a CSV file

    All options in this dialog are self-explanatory, except for the Include grouping check box. It is enabled if the table displays alarms in the tree mode. If the box is checked, then the contents of the grouping (first) column will also be written to the output file.

Internal messages

In addition to the elements of the footer area described in previous sections, there is one more element in that part of the AS GUI: the internal message counter.

While the AS operating, it can produce messages of different categories (from debug trace to critical errors). Normally, the messages in WinCC OA are sent to the log, and the AS is not an exception. The logs, however, are almost never checked during normal operation.

To make access to the messages easier, they can be written (depending on the configuration) to the WinCC OA log and/or to the internal buffer in the AS EWO. The label in the footer area of the alarm screen displays the current number of messages in the buffer:

Message counter

The background color of the counter corresponds to the color of the most severe message in the buffer:

  • Red for critical errors
  • Yellow for warnings
  • Neutral for all other messages (neutral here means default background color)

The user can click on this label, which will open the list of stored messages in new window.