Events Management

EventId is generated by the server to uniquely identify a particular event notification. The server is responsible to ensure that each event has its unique EventId vlaue. It may do this, for example, by assigning GUIDs to the Value attribute of this Property node. Clients can use the EventId to assist in minimizing or eliminating gaps and overlaps that may occur during a redundancy failover.

EventType Property describes the specific type of event.

SourceNode Property identifies the Node that the event originated from. If the event is not specific to a node the value attribute of the NodeId is set to null. Some subtypes of this BaseEventType may define additional rules for SourceNode.

SourceName Property provides a description of the source of the event. This could be the DisplayName attribute of the event source – if the event is specific to a node – or some server-specific notation.

The Time Property provides the time the event occurred. This value is set as close to the event generator as possible. It often comes from the underlying system or device. Once set, intermediate OPC Unified Architecture servers shall not alter the value.

ReceiveTime Property provides the time the OPC Unified Architecture server received the event from the underlying device of another server. ReceiveTime is analogous to ServerTimestamp defined in topic Services, i.e. in the case where the OPC Unified Architecture server gets an event from another OPC Unified Architecture server, each server applies its own ReceiveTime. That implies that a client may get the same event – having the same EventId – from different servers having different values of the ReceiveTime.

The Property TimeZone specifies the time difference (in minutes) between the TimeProperty and the standard time at the location in which the event was issued. TimeZone shall not be dependent on Standard/Daylight savings time at the originating location, because this would add ambiguities.

The DaylightSavingTime Property indicates whether the daylight saving time was applied at the location in which the event was issued.

Note
TRUE indicates that it was applied and therefore 60 min. shall be added to TimeZone in order to get the correct time with regard to daylight saving time. FALSE indicates that daylight saving time was not applied and TimeZone represents the correct value with respect to daylight saving time.

The Message Property provides a human-readable and localizable text description of the event. The server may return any appropriate text to describe the event. A null string is not a valid value; if the server does not have a description, it shall return the string part of the BrowseName attribute of the node associated with the event.

Severity is an indication of the urgency of the event. This is also commonly called “priority”. Values will range from 1 to 1000, with 1 being the lowest severity and 1000 being the highest. Typically, a severity of 1 would indicate an event which is informational in nature, while a value of 1000 would indicate an event of catastrophic nature, which could potentially result in severe financial loss or loss of life.

It is expected that very few server implementations will support 1000 distinct severity levels. Therefore, server developers are responsible for distributing their severity levels across the 1 – 1000 range in such a manner that clients can assume a linear distribution.

In many cases a strict linear mapping of underlying source severities to the OPC Severity range is not appropriate. The server developer will instead intelligently map the underlying source severities to the 1 – 1000 OPC Severity range in some other fashion. In particular, it is recommended that server developers map events of high urgency into the severity range of 667 – 1000, Events of medium urgency into the severity range of 334 – 666 and events of low urgency into severities of 1 – 333.

Some servers might not support any Events which are catastrophic in nature, so they may choose to map all of their severities into a subset of the 1 – 1000 range (for example, 1 – 666). Other servers might not support any Events which are merely informational, so they may choose to map all of their severities into a different subset of the 1 – 1000 range (for example, 334 – 1000).

The purpose of this approach is to allow clients to use severity values from multiple servers from different vendors in a consistent manner. Additional discussions of severity can be found in the topic Alarms and Conditions.