Errata exists for this version of the document.

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.