Skip to main content
Version: v3.6 (Not Supported)

Application Supervision

Alert manages a list of tags to supervise, each entry of this list containing all necessary information for acquisition of the current state of the associated tag a nd for the treatments to perform when the tag goes into a specific state. Tags declared in this list can be DDE or OPC items, in that case Alert takes in charge the polling of their current state. Either, they can be considered as simple reference; in tha t case they should be updated by explicit commands of an external application or through the suitable mediator module.

A tag can be handled as:

  • A simple variable : the acquisition of its current value will be the only treatment in order to supply associated alarm with contextual information.
  • An event, that will be recorded in the event log when the tag goes into a state declared as an event state and will optionally trigger a message transmission to the concerned operators.
  • An alarm considered as a particular event that requires a human intervention. An alarm is recorded in the alarm table and must be acknowledged. It is signaled by a red indicator ALARM on the alarm status bar. An alarm can trigger the call of concerned operators, with procedure of resumption and relief in case of failure.
  • An acknowledgment, to transmit an acknowledgment request either from the supervised application or from an external system.

Every variable has the following attributes:

  • An identifier This identifier can be a simple name or the reference of the DDE or OPC link with the tag of the supervised application. A DDE reference always contains the name of the server application (service name), the name of the rubric (topic name) which contains the tag and the designation of the tag (item name). The DDE link is therefore defined by a triplet "service-topic-item". An OPC reference contains the name of the OPC server application and the reference of the tag within the server, under the form: "server\variable". The name of the DDE s erver or DDE topic can be replaced by an alias. This feature allows different tags to be referenced by using the same name (redundant configurations) or the link with a tag to be modified without having to change the Alert database.
  • A Station The station attribute defines a subset of the application of on -call management corresponding to a specific entity, geographical (site) or organizational (company, trade

...). The definition of stations allows subsets of tags and operators to be treated separately, with all associated information (on-call schedules, alarm table, alarm history, event log). According to the architecture of the application, one can choose one of the two following modes of management:  Alert stations : the definite stations are attached to r eal remote stations, equipped with the Alert software and dealing autonomously with their data and alarm management, in synchronization with the main station.  Virtual stations: the definite stations are virtually attached to specific entities (sites, companies...) but all the treatments (data acquisition, calls) are performed on the same computer.

  • Functional groups The tags can be organized following a hierarchical structure of groups (e.g. countries, cities, buildings, machines, functions, applications, et c.); each group can itself contain a sub-tree structure of groups(buildings in cities in countries for example). This organization allows the synoptic visualization of subsets of the application as well as treatments by group in the working screens (acknow ledgment of all alarms of a group, statistics by groups, etc.). A tag can belong to several groups. For each tag, one can select a basic group, who allows specific treatments: vocal message of identification of the group in alarms, grouping of message, etc.

  • A polling mode (DDE or OPC variables only) DDE or OPC variables can be supervised either through a permanent connection, or a periodic reading. DDE variables can be punctually read on detection of an alarm in the group. The periodic reading of a varia ble allows an active surveillance of the application and the detection of any problem at the level of the connection or of the application itself. A tag defined as event or alarm has in addition the following attributes:

  • An event condition The tag is declared as event when its associated event condition is TRUE. This condition can be the change into a determined state, the threshold overtake (high or low) or a mask on a logical state of the tag (event bit). An event can be defined as transitory (pulsed e vent). In that case the return to normal state is implicit and not handled. A weekly schedule allows the definition of periods for event invalidation, alarm masking or call inhibition.

  • A multi-format message An event can be associated to a numerical, alphanumeric and vocal message. The numerical message is only used for alarms in order to identify the alarm when calling operators provided with a numeric pager. The alphanumeric message is used to identify the event in the event log. It is also used for variables declared as alarms, to identify them in the alarm table and to inform the operator provided with an alphanumeric pager, a fax, a printer or a remote terminal. This alphanumeric message can be formatted in order to include some complementary static information (group, priority of alarm,) or dynamic data (value of associated tags). The vocal message is used to identify the event locally on the PC (on option), and for tags defined as alarms to identify them by telephone. This message can be recorded, by microphone or by telephone, or synthesized automatically from the formatted alphanumeric message if the "vocal synthesis from the text" option is available.

  • An action list The activation of an event, its reset to normal state or the acknowledgment of a n alarm, can trig the execution of a predefined list of actions: call of one or several on-call groups, call of designated operators, execution of a command sequence, execution of a script of the message processor, activation of an application, vocal message on the local station. For an alarm the call of an on -call group results in the trigger of a call cycle to the operators who belong to the group and who are currently on duty according to the group schedule. By default, this call will require a call ackn owledgment (in order to suspend the call cycle). If the call does not succeed for certain operators, it can be resumed to relief operators. The call can be delayed in order to filter an event that will be treated as an alarm only if it persists a minimum t ime (a prolonged power failure for example). A tag defined as alarm furthermore has the following attributes:

  • A priority level The priority level characterizes the alarm importance. It can be set between 0 (the lowest priority by default) and 9999. The priority order can be reversed. The priority level is used to transmit alarm messages by order of decreasing importance (what allows the most important alarm to be transmitted when only one message can be transmitted by call). It also allows the calls concer ning the most important alarms to be handled first when several alarms are simultaneously detected. It finally allows alarms to be discriminated in 2 categories: the important alarms requiring to be handled quickly, whatever the time, and the less importan t alarms that will not require an immediate call during periods defined as reduce duty (the night for example); according to an option, the no important alarms can be preserved in order to be treated at the end of the period of reduce duty.

  • An option to mask alarm by another alarm An alarm can be masked by another one, in order to avoid an avalanche of alarms in certain circumstances (power failure for example). A masked alarm will be treated like a simple event, without triggering of call.

  • An associated text file (option) This text file can contain instructions for the alarm treatment or contextual information acquired automatically at the alarm time. It can be consulted either locally in the alarm table or at a distance from a remote terminal. It can also be transmitted by fax.

  • An acknowledgment condition (option) An acknowledgment condition (indicating that the alarm has been acknowledged) can be defined like an alarm condition. This acknowledgment condition can be relative to the content of the tag itsel f or to the content of an associated tag. This functionality allows Alert to be informed by the supervised application that the alarm has been acknowledged, and the consequent treatments to be performed (recording in event log, abort of the call cycle,). In addition, an option allows the acknowledgment condition to be reciprocally transmitted to the supervised application when the alarm is acknowledged from Alert (locally, by telephone or from a remote terminal).

  • An masking condition (option) On the same way, a masking condition (indicating that the alarm has been masked) can be defined. This masking condition can be relative to the content of the tag itself or to