• What is an Alarm/Event ?

• Alarms and events are things that occur in the runtime system. Events and alarms are different and the system distinguishes between the two. An event is simply an occurrence of a condition at a certain point in time. The system can detect events, store them historically and report them to various clients. Alarms, on the other hand, represent the occurrence of a condition that is considered abnormal (generally bad) in nature and requiring immediate attention from a user. Alarms are a special type of event that indicate something abnormal has happened. The system handles the real-time reporting of alarms in a special manner and provides special clients for their viewing.

• Examples of alarms include:

• A process measurement has exceeded a predefined limit, such as a high temperature alarm.
• The system hardware is not operating within desired limits, for example the CPU utilization on a Platform exceeds a certain percentage for an extended time.
• A process device is not in the desired state, such as a pump that should be running has stopped.

• Examples of events include:

• A plant process has started; for example, a new batch or campaign starts.
• The operator has changed a plant operator parameter; for example, a setpoint on a temperature controller.
• The system engineer has changed the runtime system configuration; for example, deployment of a new AutomationObject.
• The system engineer has started or stopped a system component; for example, stopping an engine.
• A platform has come back online after it had a failure or shutdown.
• A user has logged into the system.
• Detection of a severe software problem; such as a failed Application Object component.

• The following items are not considered alarms or events:

• Configuration actions within the Galaxy Repository; for example import or check-out.
• Installation of Bootstrap on a PC.
• A message sent to the system logger (SMC Logger). Note, sometimes certain software events may log a message in addition to generating an event, but this is ancillary. Logger messages are not events.
• Viewing a window in the View Engine.

• How does ArchestrA handle alarms?

• The Platform as an Alarm Provider
• The platform is responsible for routing all alarms and events for all Areas subscribed to by that Platform to InTouch’s distributed alarming infrastructure. The Platform acts as a router between all Alarm/Event Notification Distributors that are running in the subscribed Areas throughout the Galaxy (inside every Area, Platform, Engine, DI Device, etc.) and the distributed alarming infrastructure. The Platform also routes alarm acknowledgements, enables and disables received from distributed alarming back to the appropriate AutomationObject. Alarm acknowledgements, enables, and disables carry along the User information for security purposes. An alarm generated by Application Server contains fields that are generated by the alarm functions inside the AutomationObject.
• InTouch as an Alarm Consumer
• The InTouch Alarm Client can be configured to subscribe to alarms and events generated by Alarm Providers. The Alarm Provider is specified by providing the node name and provider name of the provider. For ArchestrA, only one provider exists per Platform (node). In addition, the InTouch Alarm client can be configured to subscribe to only selected Alarm Areas for the provider based on its query filters. Alarm Group names in InTouch map to Areas names and pseudo-Area names (Platforms, Engines, etc.) in ArchestrA.

• How does ArchestrA handle Events?

• A Platform is an Event Provider that provides events to the InTouch Distributed Alarm subsystem. This provider routes all events that are generated by AutomationObjects hosted by that Platform to Application Server. The provider does not need to deal with subscriptions to Areas. The provider acts as a router between the NotificationDistributor (inside every Area, Platform, Engine, etc) and the InTouch Distributed Alarm subsystem.
• Several types of events can be generated by AutomationObjects The following tables define how the fields in those events are mapped to fields in the Distributed Alarm subsystem.
• System Events-SYS
  
• Security Audit (includes User Data Change) Events-OPR
  
• Application Data Change Events -LGC

• Alarm Queries

• Alarm queries are used within alarm clients to retrieve real-time alarm information and event reports from the Galaxy.
• The fully-qualified syntax of an alarm query to retrieve a single alarm within an object as reported by a specific WinPlatform object is:
• \\nodename\Galaxy!area!object.attribute
• If the WinPlatform object that serves as an alarm provider is located in the local computer, the following syntax of the alarm query is allowed:
• \Galaxy!area!object.attribute
• The following table lists different variants of the alarm query and their return data:

• Use of Wildcard

• The asterisk (*) is a wildcard character that may be used to substitute any character or characters in the object.attribute part of the alarm query.
• The following table lists different examples on the use of the wildcard character on alarm queries and their return data:

• Using Multiple Queries

• Multiple queries can be submitted by an alarm client. For example, if Area1 an Area2 are two mutually exclusive areas, the following two queries can be submitted at once:
• \Galaxy!Area1 \Galaxy!Area2
• By using multiple queries it is possible to retrieve alarms from different nodes (WinPlatform objects) at the same time, for example:
• \\NodeNameA\Galaxy!Area1 \\NodeNameB\Galaxy!Area2