Errata exists for this version of the document.
This EventType is defined in OPC 10000-3. Its representation in the AddressSpace is formally defined in Table 23.
Table 23 – BaseEventType Definition
|
Attribute |
Value |
|||||
|
BrowseName |
BaseEventType |
|||||
|
IsAbstract |
True |
|||||
|
References |
NodeClass |
BrowseName |
DataType |
TypeDefinition |
ModellingRule |
|
|
Subtype of the BaseObjectType defined in 6.2 |
||||||
|
HasSubtype |
ObjectType |
AuditEventType |
Defined in 6.4.3 |
|||
|
HasSubtype |
ObjectType |
SystemEventType |
Defined in 6.4.28 |
|||
|
HasSubtype |
ObjectType |
BaseModelChangeEventType |
Defined in 6.4.31 |
|||
|
HasSubtype |
ObjectType |
SemanticChangeEventType |
Defined in 6.4.33 |
|||
|
HasSubtype |
ObjectType |
EventQueueOverflowEventType |
Defined in 6.4.34 |
|||
|
HasSubtype |
ObjectType |
ProgressEventType |
Defined in 6.4.35 |
|||
|
HasProperty |
Variable |
EventId |
ByteString |
PropertyType |
Mandatory |
|
|
HasProperty |
Variable |
EventType |
NodeId |
PropertyType |
Mandatory |
|
|
HasProperty |
Variable |
SourceNode |
NodeId |
PropertyType |
Mandatory |
|
|
HasProperty |
Variable |
SourceName |
String |
PropertyType |
Mandatory |
|
|
HasProperty |
Variable |
Time |
UtcTime |
PropertyType |
Mandatory |
|
|
HasProperty |
Variable |
ReceiveTime |
UtcTime |
PropertyType |
Mandatory |
|
|
HasProperty |
Variable |
LocalTime |
TimeZoneDataType |
PropertyType |
Optional |
|
|
HasProperty |
Variable |
Message |
LocalizedText |
PropertyType |
Mandatory |
|
|
HasProperty |
Variable |
Severity |
UInt16 |
PropertyType |
Mandatory |
|
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. It may do this, for example, by putting GUIDs into the ByteString. Clients can use the EventId to assist in minimizing or eliminating gaps and overlaps that may occur during a redundancy failover. The EventId shall always be returned as value and the Server is not allowed to return a StatusCode for the EventId indicating an error.
EventType describes the specific type of Event. The EventType shall always be returned as value and the Server is not allowed to return a StatusCode for the EventType indicating an error.
The SourceNode Property identifies the Node that the Event originated from. If the Event is not specific to a Node the NodeId is set to null. Some subtypes of this BaseEventType may define additional rules for the SourceNode Property.
SourceName provides a description of the source of the Event. This could be the string-part of the DisplayName of the Event source using the default locale of the server, if the Event is specific to a Node, or some server-specific notation.
Time 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 UA Servers shall not alter the value.
ReceiveTime provides the time the OPC UA Server received the Event from the underlying device of another Server. ReceiveTime is analogous to ServerTimestamp defined in OPC 10000-4, i.e. in the case where the OPC UA Server gets an Event from another OPC UA 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 ReceiveTime shall always be returned as value and the Server is not allowed to return a StatusCode for the ReceiveTime indicating an error.
LocalTime is a structure containing the Offset and the DaylightSavingInOffset flag. The Offset specifies the time difference (in minutes) between the Time Property and the time at the location in which the event was issued. If DaylightSavingInOffset is TRUE, then Standard/Daylight savings time (DST) at the originating location is in effect and Offset includes the DST correction. If FALSE then the Offset does not include DST correction and DST may or may not have been in effect.
Message 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 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 1 000, with 1 being the lowest severity and 1 000 being the highest. Typically, a severity of 1 would indicate an Event which is informational in nature, while a value of 1 000 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 1 000 distinct severity levels. Therefore, Server developers are responsible for distributing their severity levels across the 1 to 1 000 range in such a manner that clients can assume a linear distribution. For example, a client wishing to present five severity levels to a user should be able to do the following mapping:
|
Client Severity |
OPC Severity |
|
HIGH |
801 – 1 000 |
|
MEDIUM HIGH |
601 – 800 |
|
MEDIUM |
401 – 600 |
|
MEDIUM LOW |
201 – 400 |
|
LOW |
1 – 200 |
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 to 1 000 OPC Severity range in some other fashion. In particular, it is recommended that Server developers map Events of high urgency into the OPC severity range of 667 to 1 000, Events of medium urgency into the OPC severity range of 334 to 666 and Events of low urgency into OPC severities of 1 to 333.
For example, if a source supports 16 severity levels that are clustered such that severities 0 to 2 are considered to be LOW, 3 to 7 are MEDIUM and 8 to 15 are HIGH, then an appropriate mapping might be as follows:
|
OPC Range |
Source Severity |
OPC Severity |
|
HIGH (667 – 1 000) |
15 |
1 000 |
|
|
14 |
955 |
|
|
13 |
910 |
|
|
12 |
865 |
|
|
11 |
820 |
|
|
10 |
775 |
|
|
9 |
730 |
|
|
8 |
685 |
|
MEDIUM (334 – 666) |
7 |
650 |
|
|
6 |
575 |
|
|
5 |
500 |
|
|
4 |
425 |
|
|
3 |
350 |
|
LOW (1 – 333) |
2 |
300 |
|
|
1 |
150 |
|
|
0 |
1 |
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 to 1 000 range (for example, 1 to 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 to 1 000 range (for example, 334 to 1 000).
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 OPC 10000-9.