Errata exists for this version of the document.

This section describes behaviour that is expected from an OPC UA Server that is implementing the A&C Information Model. In particular this section describes specific behaviours that apply to various aspect of the A&C Information Model.

In some implementation of an OPC UA A&C Server, the Alarms and Condition are provided by an underlying system. The expected behaviour of an A&C Server when it is encountering communication problems with the underlying system is:

• If communication fails to the underlying system,
• For any Event field related information that is exposed in the address space, the Value/StatusCode obtained when reading the Event fields that are associated with the communication failure shall have a value of NULL and a StatusCode of Bad_CommunicationError.
• For Subscriptions that contain Conditions for which the failure applies, the effected Conditions generate an Event, if the Retain field is set to True. These Events shall have their Event fields that are associated with the communication failure contain a StatusCode of Bad_CommunicationError for the value.
• A Condition of the SystemOffNormalAlarmType shall be used to report the communication failure to Alarm Clients. The NormalState field shall contain the NodeId of the Variable that indicates the status of the underlying system.
• For start-up of an A&C Server that is obtaining A&C information from an already running underlying system:
• If a value is unavailable for an Event field that is being reported do to a start-up of the UA Server (i.e. the information is just not available for the Event) the Event field shall contain a StatusCode set to Bad_WaitingForInitialData for the value.
• If the Time field is normally provided by the underlying system and is unavailable, the Time will be reported as a StatusCode with a value of Bad_WaitingForInitialData.

In an OPC UA Server that is implementing the A&C Information Model and that is configured to be a redundant OPC UA Server the following behaviour is expected:

• The EventId is used to uniquely identify an Event. For an Event that is in each of the redundant Servers, it shall be identical. This applies to all standard Events, Alarms and Conditions. This may be accomplished by sharing of information between redundant Server (such as actual Events) or it may be accomplished by providing a strict EventId generating algorithm that will generate an identical EventId for each Event
• It is expected that for cold or warm failovers of redundant Servers, Subscription for Events shall require a Refresh operation. The Client shall initiate this Refresh operation.
• It is expected that for hot failovers of redundant Servers, Subscriptions for Events may require a Refresh operation. The Server shall issue a RefreshRequiredEventType Event if it is required.
• For transparent redundancy, a Server shall not require any action be performed by a Client.