Errata exists for this version of the document.

The remainder of 9 defines EventTypes. Their representation in the AddressSpace is specified in OPC 10000-5. Other parts of this series of standards may specify additional EventTypes. Figure 29 informally describes the hierarchy of these EventTypes.

Figure 29 – Standard EventType Hierarchy

The BaseEventType defines all general characteristics of an Event. All other EventTypes derive from it. There is no other semantic associated with this type.

SystemEvents are Events of SystemEventType that are generated as a result of some Event that occurs within the Server or by a system that the Server is representing.

ProgressEvents are Events of ProgressEventType that are generated to identify the progress of an operation. An operation can be a service call or something application specific like a program execution.

AuditEvents are Events of AuditEventType that are generated as a result of an action taken on the Server by a Client of the Server. For example, in response to a Client issuing a write to a Variable, the Server would generate an AuditEvent describing the Variable as the source and the user and Client session as the initiators of the Event.

Figure 30 illustrates the defined behaviour of an OPC UA Server in response to an auditable action request. If the action is accepted, then an action AuditEvent is generated and processed by the Server. If the action is not accepted due to security reasons, a security AuditEvent is generated and processed by the Server. The Server may involve the underlying device or system in the process but it is the Server’s responsibility to provide the Event to any interested Clients. Clients are free to subscribe to Events from the Server and will receive the AuditEvents in response to normal Publish requests.

All action requests include a human readable AuditEntryId. The AuditEntryId is included in the AuditEvent to allow human readers to correlate an Event with the initiating action. The AuditEntryId typically contains who initiated the action and from where it was initiated.

The Server may elect to optionally persist the AuditEvents in addition to the mandatory Event Subscription delivery to Clients.

Figure 30 – Audit Behaviour of a Server

Figure 31 illustrates the expected behaviour of an aggregating Server in response to an auditable action request. This use case involves the aggregating Server passing on the action to one of its aggregated Servers. The general behaviour described above is extended by this behaviour and not replaced. That is, the request could fail and generate a security AuditEvent within the aggregating Server. The normal process is to pass the action down to an aggregated Server for processing. The aggregated Server will, in turn, follow this behaviour or the general behaviour and generate the appropriate AuditEvents. The aggregating Server periodically issues publish requests to the aggregated Servers. These collected Events are merged with self-generated Events and made available to subscribing Clients. If the aggregating Server supports the optional persisting of AuditEvent, then the collected Events are persisted along with locally-generated Events.

The aggregating Server may map the authenticated user account making the request to one of its own accounts when passing on the request to an aggregated Server. It shall, however, preserve the AuditEntryId by passing it on as received. The aggregating Server may also generate its own AuditEvent for the request prior to passing it on to the aggregated Server, in particular, if the aggregating Server needs to break a request into multiple requests that are each directed to separate aggregated Servers or if part of a request is denied due to security on the aggregating Server.

Figure 31 – Audit Behaviour of an Aggregating Server

This is a subtype of AuditEventType and is used only for categorization of security-related Events. This type follows all behaviour of its parent type.

This is a subtype of AuditSecurityEventType and is used for categorization of security-related Events from the SecureChannel Service Set defined in OPC 10000-4.

This is a subtype of AuditChannelEventType and is used for Events generated from calling the OpenSecureChannel Service defined in OPC 10000-4.

This is a subtype of AuditSecurityEventType and is used for categorization of security-related Events from the Session Service Set defined in OPC 10000-4.

This is a subtype of AuditSessionEventType and is used for Events generated from calling the CreateSession Service defined in OPC 10000-4.

This is a subtype of AuditCreateSessionEventType and is used for Events generated from calling the CreateSession Service defined in OPC 10000-4 if the EndpointUrl used in the service call does not match the Server’s HostNames (see OPC 10000-4 for details).

This is a subtype of AuditSessionEventType and is used for Events generated from calling the ActivateSession Service defined in OPC 10000-4.

This is a subtype of AuditSessionEventType and is used for Events generated from calling the Cancel Service defined in OPC 10000-4.

This is a subtype of AuditSecurityEventType and is used only for categorization of Certificate related Events. This type follows all behaviours of its parent type. These AuditEvents will be generated for Certificate errors in addition to other AuditEvents related to service calls.

This is a subtype of AuditCertificateEventType and is used only for categorization of Certificate related Events. This type follows all behaviours of its parent type. This AuditEvent is generated if the HostName in the URL used to connect to the Server is not the same as one of the HostNames specified in the Certificate or if the Application and Software Certificates contain an application or product URI that does not match the URI specified in the ApplicationDescription provided with the Certificate. For more details on Certificates see OPC 10000-4.

This is a subtype of AuditCertificateEventType and is used only for categorization of Certificate related Events. This type follows all behaviours of its parent type. This AuditEvent is generated if the current time is outside the validity period’s start date and end date.

This is a subtype of AuditCertificateEventType and is used only for categorization of Certificate related Events. This type follows all behaviours of its parent type. This AuditEvent is generated if the certificate structure is invalid or if the Certificate has an invalid signature.

This is a subtype of AuditCertificateEventType and is used only for categorization of Certificate related Events. This type follows all behaviours of its parent type. This AuditEvent is generated if the Certificate is not trusted, that is, if the Issuer Certificate is unknown.

This is a subtype of AuditCertificateEventType and is used only for categorization of Certificate related Events. This type follows all behaviours of its parent type. This AuditEvent is generated if a Certificate has been revoked or if the revocation list is not available (i.e. a network interruption prevents the Application from accessing the list).

This is a subtype of AuditCertificateEventType and is used only for categorization of Certificate related Events. This type follows all behaviours of its parent type. This AuditEvent is generated if a Certificate set of uses does not match the requested use for the Certificate (i.e. Application, Software or Certificate Authority).

This is a subtype of AuditEventType and is used for categorization of node management related Events. This type follows all behaviours of its parent type.

This is a subtype of AuditNodeManagementEventType and is used for Events generated from calling the AddNodes Service defined in OPC 10000-4.

This is a subtype of AuditNodeManagementEventType and is used for Events generated from calling the DeleteNodes Service defined in OPC 10000-4.

This is a subtype of AuditNodeManagementEventType and is used for Events generated from calling the AddReferences Service defined in OPC 10000-4.

This is a subtype of AuditNodeManagementEventType and is used for Events generated from calling the DeleteReferences Service defined in OPC 10000-4.

This is a subtype of AuditEventType and is used for categorization of update related Events. This type follows all behaviours of its parent type.

This is a subtype of AuditUpdateEventType and is used for categorization of write update related Events. This type follows all behaviours of its parent type.

This is a subtype of AuditUpdateEventType and is used for categorization of history update related Events. This type follows all behaviours of its parent type.

This is a subtype of AuditEventType and is used for categorization of Method related Events. This type follows all behaviours of its parent type.

A DeviceFailureEvent is an Event of DeviceFailureEventType that indicates a failure in a device of the underlying system.

A SystemStatusChangeEvent is an Event of SystemStatusChangeEventType that indicates a status change in a system. For example, if the status indicates an underlying system is not running, then a Client cannot expect any Events from the underlying system. A Server can identify its own status changes using this EventType.

ModelChangeEvents are generated to indicate a change of the AddressSpace structure. The change may consist of adding or deleting a Node or Reference. Although the relationship of a Variable or VariableType to its DataType is not modelled using References, changes to the DataType Attribute of a Variable or VariableType are also considered as model changes and therefore a ModelChangeEvent is generated if the DataType Attribute changes.

There is a correlation between ModelChangeEvents and the NodeVersion Property of Nodes. Every time a ModelChangeEvent is issued for a Node, its NodeVersion shall be changed, and every time the NodeVersion is changed, a ModelChangeEvent shall be generated. A Server shall support both the ModelChangeEvent and the NodeVersion Property or neither, but never only one of the two mechanisms.

This relation also implies that only those Nodes of the AddressSpace having a NodeVersion shall trigger a ModelChangeEvent. Other Nodes shall not trigger a ModelChangeEvent.

A ModelChangeEvent is always generated in the context of a View, including the default View where the whole AddressSpace is considered. Therefore the only Notifiers which report the ModelChangeEvents are View Nodes and the Server Object representing the default View. Each action generating a ModelChangeEvent may lead to several Events since it may affect different Views. If, for example, a Node was deleted from the AddressSpace, and this Node was also contained in a View “A”, there would be one Event having the AddressSpace as context and another having the View “A” as context. If a Node would only be removed from View “A”, but still exists in the AddressSpace, it would generate only a ModelChangeEvent for View “A”.

If a Client does not want to receive duplicates of changes then it shall use the filter mechanisms of the Event subscription to filter only for the default View and suppress the ModelChangeEvents having other Views as the context.

When a ModelChangeEvent is issued on a View and the View supports the ViewVersion Property, then the ViewVersion shall be updated.

An implementation is not required to issue an Event for every update as it occurs. An OPC UA Server may be capable of grouping a series of transactions or simple updates into a larger unit. This series may constitute a logical grouping or a temporal grouping of changes. A single ModelChangeEvent may be issued after the last change of the series, to cover all of the changes. This is referred to as Event compression. A change in the NodeVersion and the ViewVersion may thus reflect a group of changes and not a single change.

BaseModelChangeEvents are Events of the BaseModelChangeEventType. The BaseModelChangeEventType is the base type for ModelChangeEvents and does not contain information about the changes but only indicates that changes occurred. Therefore the Client shall assume that any or all of the Nodes may have changed.

GeneralModelChangeEvents are Events of the GeneralModelChangeEventType. The GeneralModelChangeEventType is a subtype of the BaseModelChangeEventType. It contains information about the Node that was changed and the action that occurred to cause the ModelChangeEvent (e.g. add a Node, delete a Node, etc.). If the affected Node is a Variable or Object, then the TypeDefinitionNode is also present.

To allow Event compression, a GeneralModelChangeEvent contains an array of changes.

Two types of ModelChangeEvents are defined: the BaseModelChangeEvent that does not contain any information about the changes and the GeneralModelChangeEvent that identifies the changed Nodes via an array. The precision used depends on both the capability of the OPC UA Server and the nature of the update. An OPC UA Server may use either ModelChangeEvent type depending on circumstances. It may also define subtypes of these EventTypes adding additional information.

To ensure interoperability, the following guidelines for Events should be observed.

• If the array of the GeneralModelChangeEvent is present, then it should identify every Node that has changed since the preceding ModelChangeEvent.
• The OPC UA Server should emit exactly one ModelChangeEvent for an update or series of updates. It should not issue multiple types of ModelChangeEvent for the same update.
• Any Client that responds to ModelChangeEvents should respond to any Event of the BaseModelChangeEventType including its subtypes like the GeneralModelChangeEventType.

If a Client is not capable of interpreting additional information of the subtypes of the BaseModelChangeEventType, it should treat Events of these types the same way as Events of the BaseModelChangeEventType.

SemanticChangeEvents are Events of SemanticChangeEventType that are generated to indicate a change of the AddressSpace semantics. The change consists of a change to the Value Attribute of a Property.

The SemanticChangeEvent contains information about the Node owning the Property that was changed. If this is a Variable or Object, the TypeDefinitionNode is also present.

The SemanticChange bit of the AccessLevel Attribute of a Property indicates whether changes of the Property value are considered for SemanticChangeEvents (see 5.6.2).

The ViewVersion and NodeVersion Properties do not change due to the publication of a SemanticChangeEvent.

SemanticChangeEvents are handled in the context of a View the same way as ModelChangeEvents. This is defined in 9.32.3.

SemanticChangeEvents can be compressed the same way as ModelChangeEvents. This is defined in 9.32.4.