Underlying systems are often large and Clients often have an interest in only a specific subset of the data. They do not need, or want, to be burdened with viewing Nodes in the AddressSpace for which they have no interest.
To address this problem, this standard defines the concept of a View. Each View defines a subset of the Nodes in the AddressSpace. The entire AddressSpace is the default View. Each Node in a View may contain only a subset of its References, as defined by the creator of the View. The View Node acts as the root for the Nodes in the View. Views are defined using the View NodeClass, which is specified in Table 10.
All Nodes contained in a View shall be accessible starting from the View Node when browsing in the context of the View. It is not expected that all containing Nodes can be browsed directly from the View Node but rather browsed from other Nodes contained in the View.
A View Node may not only be used as additional entry point into the AddressSpace but as a construct to organize the AddressSpace and thus as the only entry point into a subset of the AddressSpace. Therefore Clients shall not ignore View Nodes when exposing the AddressSpace. Simple Clients that do not deal with Views for filtering purposes can, for example, handle a View Node like an Object of type FolderType (see 5.5.3).
Table 10 – View NodeClass
|Base NodeClass Attributes||M||--||Inherited from the Base NodeClass. See 5.2.|
|ContainsNoLoops||M||Boolean||If set to “true” this Attribute indicates that by following the References in the context of the View there are no loops, i.e. starting from a Node “A” contained in the View and following the forward References in the context of the View Node “A” will not be reached again. It does not specify that there is only one path starting from the View Node to reach a Node contained in the View.
If set to “false” this Attribute indicates that following References in the context of the View may lead to loops.
|EventNotifier||M||Byte||The EventNotifier Attribute is used to indicate if the Node can be used to subscribe to Events or to read / write historic Events.
The EventNotifier is an 8-bit unsigned integer with the structure defined in the following table.
Field Bit Description
SubscribeTo Events 0 Indicates if it can be used to subscribe to Events (0 means cannot be used to subscribe to Events, 1 means can be used to subscribe to Events)
Reserved 1 Reserved for future use. Shall always be zero.
HistoryRead 2 Indicates if the history of the Events is readable (0 means not readable, 1 means readable)
HistoryWrite 3 Indicates if the history of the Events is writable (0 means not writable, 1 means writable)
Reserved 4:7 Reserved for future use. Shall always be zero
The second two bits also indicate if the history of the Events is available via the OPC UA Server.
|HierarchicalReferences||0..*||Top level Nodes in a View are referenced by hierarchical References (see 7.3).|
|HasProperty||0..*||HasProperty References identify the Properties of the View.|
|NodeVersion||O||String||The NodeVersion Property is used to indicate the version of a Node.
The NodeVersion Property is updated each time a Reference is added or deleted to the Node the Property belongs to. Attribute value changes do not cause the NodeVersion to change. Clients may read the NodeVersion Property or subscribe to it to determine when the structure of a Node has changed.
|ViewVersion||O||UInt32||The version number for the View. When Nodes are added to or removed from a View, the value of the ViewVersion Property is updated. Clients may detect changes to the composition of a View using this Property. The value of the ViewVersion shall always be greater than 0.|
The View NodeClass inherits the base Attributes from the Base NodeClass defined in 5.2. It also defines two additional Attributes.
The mandatory ContainsNoLoops Attribute is set to false if the Server is not able to identify if the View contains loops or not.
The mandatory EventNotifier Attribute identifies if the View can be used to subscribe to Events that either occur in the content of the View or as ModelChangeEvents (see 9.32) of the content of the View or to read / write the history of the Events. A View that supports Events shall provide all Events that occur in any Object used as EventNotifier that is part of the content of the View. In addition, it shall provide all ModelChangeEvents that occur in the context of the View.
To avoid recursion, i.e. getting all Events of the Server, the Server Object defined in OPC 10000-5 shall never be part of any View since it provides all Events of the Server.
Views are defined by the Server. The browsing and querying Services defined in OPC 10000-4 expect the NodeId of a View Node to provide these Services in the context of the View.
HasProperty References are used to identify the Properties of a View. The Property NodeVersion is used to indicate the version of the View Node. The ViewVersion Property indicates the version of the content of the View. In contrast to the NodeVersion, the ViewVersion Property is updated even if Nodes not directly referenced by the View Node are added to or deleted from the View. This Property is optional because it might not be possible for Servers to detect changes in the View contents. Servers may also generate a ModelChangeEvent, described in 9.32, if Nodes are added to or deleted from the View. There are no additional Properties defined for Views in this document. Additional parts of this series of standards may define additional Properties for Views.
Views can be the SourceNode of any hierarchical Reference. They shall not be the SourceNode of any non-hierarchical Reference.