Network representation of Alarm & Condition|OPC UA Standard|Forum|OPC Foundation

Hi,

  I think this might need some more explanation.  OPC UA has a Client/ Server communication model and a PubSub communication model.  Both can report data from a common information model. Client/Server typically reports event data via a subscription, while in PubSub a publisher might publish an event and the subscriber could listen for it.  The structure of the event returned in a subscription (client/server) is determined by the client, since the client provides a select clause and a where clause as part of a filter for a subscription to the server.  The select clause specifies what fields the server should send and the where clause specifies a filter to restrict which events are to be sent. For PubSub, the publisher sets what fields are to be sent out for the Event message, the subscriber has no choice on what it will get.

Part 9 describes the A&C information model and the structure of all of the alarms.

Alarms and Conditions (A&C) is an information model.  If a server has implemented the information model then any client that understands the model can manage the A&C model exposed by the server.  This management includes acknowledging alarms, suppressing alarms, silencing alarms etc.  The A&C information model is an extension of the BaseEventModel in OPC UA, which means that changes of state in an alarm or condition instance trigger an event.  If a client has a subscription to the server and the subscription include a monitored item for events - then the client will receive any events that pass the filter specified in the subscription.  Once a client receives an event the client can call methods associated with the event to perform actions on the event (i.e. acknowledge it). 

For pubsub, if a subscriber receives and event, the subscriber must resort to Client/Server communication if it wishes to change the state of the Alarm.