ModelChangeEventsare generated to indicate a change of the AddressSpacestructure. The change may consist of adding or deleting a Nodeor Reference.Although the relationship of a Variableor VariableTypeto its DataTypeis not modelled using References, changes to the DataType Attributeof a Variableor VariableTypeare also considered as model changes and therefore a ModelChangeEventis generated if the DataType Attributechanges.

There is a correlation between ModelChangeEventsand the NodeVersion Property of Nodes. Every time a ModelChangeEventis issued for a Node, its NodeVersionshall be changed, and every time the NodeVersionis changed, a ModelChangeEventshall be generated. A Servershall support both the ModelChangeEventand the NodeVersion Propertyor neither, but never only one of the two mechanisms.

This relation also implies that only those Nodesof the AddressSpacehaving a NodeVersionshall trigger a ModelChangeEvent. Other Nodesshall not trigger a ModelChangeEvent.

A ModelChangeEventis always generated in the context of a View,including the default Viewwhere the whole AddressSpaceis considered. Therefore the only Notifierswhich report the ModelChangeEventsare View Nodesand the Server Objectrepresenting the default View. Each action generating a ModelChangeEventmay lead to several Eventssince it may affect different Views. If, for example, a Nodewas deleted from the AddressSpace, and this Nodewas also contained in a View “A”, there would be one Eventhaving the AddressSpaceas context and another having the View “A” as context. If a Nodewould only be removed from View“A”, but still exists in the AddressSpace, it would generate only a ModelChangeEventfor View“A”.

If a Clientdoes not want to receive duplicates of changes then it shall use the filter mechanisms of the Event Subscriptionto filter only for the default Viewand suppress the ModelChangeEventshaving other Viewsas the context.

When a ModelChangeEventis issued on a Viewand the Viewsupports the ViewVersion Property, then the ViewVersionshall be updated.

An implementation is not required to issue an Eventfor every update as it occurs. An OPC UA Servermay 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 ModelChangeEventmay 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 NodeVersionand the ViewVersion may thus reflect a group of changes and not a single change.

BaseModelChangeEventsare Eventsof the BaseModelChangeEventType. The BaseModelChangeEventTypeis the base type for ModelChangeEventsand does not contain information about the changes but only indicates that changes occurred. Therefore the Clientshall assume that any or all of the Nodesmay have changed.

GeneralModelChangeEventsare Eventsof the GeneralModelChangeEventType. The GeneralModelChangeEventTypeis a subtype of the BaseModelChangeEventType. It contains information about the Nodethat was changed and the action that occurred to cause the ModelChangeEvent(e.g. add a Node, delete a Node, etc.). If the affected Nodeis a Variableor Object, then the TypeDefinitionNodeis also present.

To allow Eventcompression, a GeneralModelChangeEventcontains an array of changes.

Two types of ModelChangeEventsare defined: the BaseModelChangeEventthat does not contain any information about the changes and the GeneralModelChangeEventthat identifies the changed Nodesvia an array. The precision used depends on both the capability of the OPC UA Serverand the nature of the update. An OPC UA Servermay use either ModelChangeEventtype depending on circumstances. It may also define subtypes of these EventTypesadding additional information.

To ensure interoperability, the following guidelines for Eventsshould be observed.

  • If the array of theGeneralModelChangeEvent 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 Clientthat responds to ModelChangeEvents should respond to any Event of the BaseModelChangeEventTypeincluding its subtypes like the GeneralModelChangeEventType.

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