This section describes behaviour that is expected from an OPC UA Serverthat 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 Alarmsand Conditionare provided by an underlying system. The expected behaviour of an A&C Serverwhen it is encountering communication problems with the underlying system is:

• If communication fails to the underlying system,
• For any Eventfield related information that is exposed in the address space, the Value/StatusCodeobtained when reading the Eventfields that are associated with the communication failure shall have a value of NULL and a StatusCodeof Bad_CommunicationError.
• For Subscriptions that contain Conditionsfor which the failure applies, the effected Conditionsgenerate an Event,if the Retainfield is set to True. These Eventsshall have their Eventfields that are associated with the communication failure contain a StatusCodeof Bad_CommunicationError for the value.
• A Conditionof the SystemOffNormalAlarmType shall be used to report the communication failure to Alarm Clients. The NormalState field shall contain the NodeIdof the Variablethat indicates the status of the underlying system.
• For start-up of an A&C Serverthat is obtaining A&C information from an already running underlying system:
• If a value is unavailable for an Eventfield 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 Eventfield shall contain a StatusCodeset 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 StatusCodewith a value of Bad_WaitingForInitialData.

In an OPC UA Serverthat is implementing the A&C Information Modeland that is configured to be a redundant OPC UA Serverthe following behaviour is expected:

• The EventId is used to uniquely identify an Event. For an Eventthat is in each of the redundant Servers, it shall be identical. This applies to all standard Events, Alarmsand 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 EventIdgenerating algorithm that will generate an identical EventIdfor each Event
• It is expected that for cold or warm failovers of redundant Servers, Subscriptionfor Eventsshall require a Refresh operation. The Clientshall initiate this Refreshoperation.
• It is expected that for hot failovers of redundant Servers, Subscriptionsfor Eventsmay require a Refreshoperation. The Servershall issue a RefreshRequiredEventType Eventif it is required.
• For transparent redundancy, a Servershall not require any action be performed by a Client.