How does ArchestrA handle alarms?

• The Platform as an Alarm Provider
  • A Platform can act as a single Alarm Provider that provides alarms to the InTouch Distributed Alarm subsystem. A boolean checkbox is provided in the Platform AutomationObject indicating whether it subscribed to Areas or not for alarm and event reporting.
  • The platform is responsible for routing all alarms and events for all Areas subscribed to by that Platform to InTouch’s distributed alarming infrastructure.
  • An alarm generated by App Server contains fields that are generated by the alarm functions inside the AutomationObject. Those fields are mapped to fields in InTouch as follows:

 Alarms:

• 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 Acknowledgement from Distributed Alarming

  • The InTouch Alarm Client can acknowledge unacknowledged alarms that are reported by the Platform. The Platform receives the acknowledge request and forwards it to the target AutomationObject’s acknowledge attribute for the alarm.
  • Security is used as part of this set (it is a UserSetAttribute). An optional comment can be entered when the acknowledge is requested.

• Alarm Enable/Disable

  • The InTouch Alarm Client can enable/disable alarming on any AutomationObject. The platform receives the enable request and forwards it to the target AutomationObject’s AlarmMode attribute. Security is used as part of this set (it is a UserSetAttribute).

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 following tables define how the fields in those events are mapped to fields in the Distributed Alarm subsystem.

System Events:

Security Audit (includes User Data Change) Events:

Application Data Change Events:

• 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:

Note: Only one wildcard character is allowed per alarm query.

• 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