Errata exists for this version of the document.

Clause 5 defines the NodeClasses used to define Nodes in the OPC UA AddressSpace. NodeClasses are derived from a common Base NodeClass. This NodeClass is defined first, followed by those used to organise the AddressSpace and then by the NodeClasses used to represent Objects.

The NodeClasses defined to represent Objects fall into three categories: those used to define instances, those used to define types for those instances and those used to define data types. Subclause 6.3 describes the rules for subtyping and 6.4 the rules for instantiation of the type definitions.

The OPC UA Address Space Model defines a Base NodeClass from which all other NodeClasses are derived. The derived NodeClasses represent the various components of the OPC UA Object Model (see 4.2). The Attributes of the Base NodeClass are specified in Table 7. There are no References specified for the Base NodeClass.

Table 7 – Base NodeClass

Name	Use	Data Type	Description
Attributes
NodeId	M	NodeId	See 5.2.2
NodeClass	M	NodeClass	See 5.2.3
BrowseName	M	QualifiedName	See 5.2.4
DisplayName	M	LocalizedText	See 5.2.5
Description	O	LocalizedText	See 5.2.6
WriteMask	O	AttributeWriteMask	See 5.2.7
UserWriteMask	O	AttributeWriteMask	See 5.2.8
RolePermissions	O	RolePermissionType[]	See 5.2.9
UserRolePermissions	O	RolePermissionType[]	See 5.2.10
AccessRestrictions	O	AccessRestrictionsType	See 5.2.11
References			No References specified for this NodeClass

Nodes are unambiguously identified using a constructed identifier called the NodeId. Some Servers may accept alternative NodeIds in addition to the canonical NodeId represented in this Attribute. A Server shall persist the NodeId of a Node, that is, it shall not generate new NodeIds when rebooting. The structure of the NodeId is defined in 8.2.

The NodeClass Attribute identifies the NodeClass of a Node. Its data type is defined in 8.30.

Nodes have a BrowseName Attribute that is used as a non-localised human-readable name when browsing the AddressSpace to create paths out of BrowseNames. The TranslateBrowsePathsToNodeIds Service defined in OPC 10000-4 can be used to follow a path constructed of BrowseNames.

A BrowseName should never be used to display the name of a Node. The DisplayName should be used instead for this purpose.

Unlike NodeIds, the BrowseName cannot be used to unambiguously identify a Node. Different Nodes may have the same BrowseName.

Subclause 8.3 defines the structure of the BrowseName. It contains a namespace and a string. The namespace is provided to make the BrowseName unique in some cases in the context of a Node (e.g. Properties of a Node) although not unique in the context of the Server. If different organizations define BrowseNames for Properties, the namespace of the BrowseName provided by the organization makes the BrowseName unique, although different organizations may use the same string having a slightly different meaning.

Servers may often choose to use the same namespace for the NodeId and the BrowseName. However, if they want to provide a standard Property, its BrowseName shall have the namespace of the standards body although the namespace of the NodeId reflects something else, for example the local Server.

It is recommended that standard bodies defining standard type definitions use their namespace for the NodeId of the TypeDefinitionNode as well as for the BrowseName of the TypeDefinitionNode.

The string-part of the BrowseName is case sensitive. That is, Clients shall consider them case sensitive. Servers are allowed to handle BrowseNames passed in Service requests as case insensitive. Examples are the TranslateBrowsePathsToNodeIds Service or Event filter.

The DisplayName Attribute contains the localised name of the Node. Clients should use this Attribute if they want to display the name of the Node to the user. They should not use the BrowseName for this purpose. The Server may maintain one or more localised representations for each DisplayName. Clients negotiate the locale to be returned when they open a session with the Server. Refer to OPC 10000-4 for a description of session establishment and locales. Subclause 8.5 defines the structure of the DisplayName. The string part of the DisplayName is restricted to 512 characters.

The optional Description Attribute shall explain the meaning of the Node in a localised text using the same mechanisms for localisation as described for the DisplayName in 5.2.5.

The optional WriteMask Attribute exposes the possibilities of a client to write the Attributes of the Node. The WriteMask Attribute does not take any user access rights into account, that is, although an Attribute is writable this may be restricted to a certain user/user group.

If the OPC UA Server does not have the ability to get the WriteMask information for a specific Attribute from the underlying system, it should state that it is writable. If a write operation is called on the Attribute, the Server should transfer this request and return the corresponding StatusCode if such a request is rejected. StatusCodes are defined in OPC 10000-4.

The AttributeWriteMask DataType is defined in 0.

The optional UserWriteMask Attribute exposes the possibilities of a client to write the Attributes of the Node taking user access rights into account. It uses the AttributeWriteMask DataType which is defined in 0.

The UserWriteMask Attribute can only further restrict the WriteMask Attribute, when it is set to not writable in the general case that applies for every user.

Clients cannot assume an Attribute can be written based on the UserWriteMask Attribute.It is possible that the Server may return an access denied error due to some server specific change which was not reflected in the state of this Attribute at the time the Client accessed it.

The optional RolePermissions Attribute specifies the Permissions that apply to a Node for all Roles which have access to the Node. The value of the Attribute is an array of RolePermissionType Structures (see Table 8).

Table 8 – RolePermissionType

Name	Type	Description
RolePermissionType	Structure	Specifies the Permissions for a Role
roleId	NodeId	The NodeId of the Role Object.
permissions	PermissionType	A mask specifying which Permissions are available to the Role.

Servers may allow administrators to write to the RolePermissions Attribute.

If not specified, the value of DefaultRolePermissions Property from the NamespaceMetadata Object associated with the Node shall be used instead. If the NamespaceMetadata Object does not define the Property or does not exist, then the Server should not publish any information about how it manages Permissions.

If a Server supports Permissions for a particular Namespace it shall add the DefaultRolePermissions Property to the NamespaceMetadata Object for that Namespace (see Figure 8). If a particular Node in the Namespace needs to override the default values, the Server adds the RolePermissions Attribute to the Node. The DefaultRolePermissions Property and RolePermissions Attribute shall only be readable by administrators. If a Server allows the Permissions to be changed these values shall be writeable. If the Server allows the Permissions to be overridden for a particular Node but does not currently have any Node Permissions configured, then the value of the Attribute shall be an empty array. If the administrator wishes to remove overridden Permissions, an empty array shall be written to this Attribute. Servers shall prevent Permissions from being changed in such a way as to render the Server inoperable.

If a Server publishes information about the Roles for a Namespace assigned to the current Session, it shall add the DefaultUserRolePermissions Property to the NamespaceMetadata Object for that Namespace. The value of this Property shall be a readonly list of Permissions for each Role assigned to the current Session. If a particular Node in the Namespace overrides the default RolePermissions the Server shall also override the DefaultUserRolePermissions by adding the UserRolePermissions Attribute to the Node. If the Server allows the Permissions to be overridden for a particular Node but does not currently have any Node Permissions configured, then the Server shall return the value of the DefaultUserRolePermissions Property for the Node Namespace.

If a Server implements a vendor specific Role Permission model for a Namespace, it shall not add the DefaultRolePermissions or DefaultUserRolePermissions Properties to the NamespaceMetadata Object.

Figure 8 – Permissions in the Address Space

The optional UserRolePermissions Attribute specifies the Permissions that apply to a Node for all Roles granted to current Session. The value of the Attribute is an array of RolePermissionType Structures (see Table 8).

Clients may determine their effective Permissions by logically ORing the Permissions for each Role in the array.

The value of this Attribute is derived from the rules used by the Server to map Sessions to Roles. This mapping may be vendor specific or it may use the standard Role model defined in 4.8.

This Attribute shall not be writeable.

If not specified, the value of DefaultUserRolePermissions Property from the Namespace Metadata Object associated with the Node is used instead. If the NamespaceMetadata Object does not define the Property or does not exist, then the Server does not publish any information about Roles mapped to the current Session.

The optional AccessRestrictions Attribute specifies the AccessRestrictions that apply to a Node. Its data type is defined in 8.56. If a Server supports AccessRestrictions for a particular Namespace it adds the DefaultAccessRestrictions Property to the NamespaceMetadata Object for that Namespace (see Figure 8). If a particular Node in the Namespace needs to override the default value the Server adds the AccessRestrictions Attribute to the Node.

If a Server implements a vendor specific access restriction model for a Namespace, it does not add the DefaultAccessRestrictions Property to the NamespaceMetadata Object.

References are defined as instances of ReferenceType Nodes. ReferenceType Nodes are visible in the AddressSpace and are defined using the ReferenceType NodeClass as specified in Table 9. In contrast, a Reference is an inherent part of a Node and no NodeClass is used to represent References.

This standard defines a set of ReferenceTypes provided as an inherent part of the OPC UA Address Space Model. These ReferenceTypes are defined in Clause 7 and their representation in the AddressSpace is defined in OPC 10000-5. Servers may also define ReferenceTypes. In addition, OPC 10000-4 defines NodeManagement Services that allow Clients to add ReferenceTypes to the AddressSpace.

Table 9 – ReferenceType NodeClass

Name	Use	Data Type	Description
Attributes
Base NodeClass Attributes	M	--	Inherited from the Base NodeClass. See 5.2.
IsAbstract	M	Boolean	A boolean Attribute with the following values: TRUEit is an abstract ReferenceType, i.e. no Reference of this type shall exist, only of its subtypes. FALSEit is not an abstract ReferenceType, i.e. References of this type can exist.
Symmetric	M	Boolean	A boolean Attribute with the following values: TRUEthe meaning of the ReferenceType is the same as seen from both the SourceNode and the TargetNode. FALSEthe meaning of the ReferenceType as seen from the TargetNode is the inverse of that as seen from the SourceNode.
InverseName	O	LocalizedText	The inverse name of the Reference, which is the meaning of the ReferenceType as seen from the TargetNode.
References
HasProperty	0..*		Used to identify the Properties (see 5.3.3.2).
HasSubtype	0..*		Used to identify subtypes (see 5.3.3.3).
Standard Properties
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.

The ReferenceType NodeClass inherits the base Attributes from the Base NodeClass defined in 5.2. The inherited BrowseName Attribute is used to specify the meaning of the ReferenceType as seen from the SourceNode. For example, the ReferenceType with the BrowseName “Contains” is used in References that specify that the SourceNode contains the TargetNode. The inherited DisplayName Attribute contains a translation of the BrowseName.

The BrowseName of a ReferenceType shall be unique in a Server. It is not allowed that two different ReferenceTypes have the same BrowseName.

The IsAbstract Attribute indicates if the ReferenceType is abstract. Abstract ReferenceTypes cannot be instantiated and are used only for organizational reasons, for example to specify some general semantics or constraints that its subtypes inherit.

The Symmetric Attribute is used to indicate whether or not the meaning of the ReferenceType is the same for both the SourceNode and TargetNode.

If a ReferenceType is symmetric, the InverseName Attribute shall be omitted. Examples of symmetric ReferenceTypes are “Connects To” and “Communicates With”. Both imply the same semantic coming from the SourceNode or the TargetNode. Therefore both directions are considered to be forward References.

If the ReferenceType is non-symmetric and not abstract, the InverseName Attribute shall be set. The InverseName Attribute specifies the meaning of the ReferenceType as seen from the TargetNode. Examples of non-symmetric ReferenceTypes include “Contains” and “Contained In”, and “Receives From” and “Sends To”.

References that use the InverseName, such as “Contained In” References, are referred to as inverse References.

Figure 9 provides examples of symmetric and non-symmetric References and the use of the BrowseName and the InverseName.

Figure 9 – Symmetric and Non-Symmetric References

It might not always be possible for Servers to instantiate both forward and inverse References for non-symmetric ReferenceTypes as shown in Figure 9. When they do, the References are referred to as bidirectional. Although not required, it is recommended that all hierarchical References be instantiated as bidirectional to ensure browse connectivity. A bidirectional Reference is modelled as two separate References.

As an example of a unidirectional Reference, it is often the case that a signal sink knows its signal source, but this signal source does not know its signal sink. The signal sink would have a “Sourced By” Reference to the signal source, without the signal source having the corresponding “Sourced To” inverse References to its signal sinks.

The DisplayName and the InverseName are the only standardised places to indicate the semantic of a ReferenceType. There may be more complex semantics associated with a ReferenceType than can be expressed in those Attributes (e.g. the semantic of HasSubtype). This standard does not specify how this semantic should be exposed. However, the Description Attribute can be used for this purpose. This standard provides a semantic for the ReferenceTypes specified in Clause 7.

A ReferenceType can have constraints restricting its use. For example, it can specify that starting from Node A and only following References of this ReferenceType or one of its subtypes, it shall never be able to return to A, that is, a “No Loop” constraint.

This standard does not specify how those constraints could or should be made available in the AddressSpace. Nevertheless, for the standard ReferenceTypes, some constraints are specified in Clause 7. This standard does not restrict the kind of constraints valid for a ReferenceType. It can, for example, also affect an ObjectType. The restriction that a ReferenceType can only be used by relating Nodes of some NodeClasses with a defined cardinality is a special constraint of a ReferenceType.

HasSubtype References and HasProperty References are the only ReferenceTypes that may be used with ReferenceType Nodes as SourceNode. ReferenceType Nodes shall not be the SourceNode of other types of References.

HasProperty References are used to identify the Properties of a ReferenceType and shall only refer to Nodes of the Variable NodeClass.

The Property NodeVersion is used to indicate the version of the ReferenceType.

There are no additional Properties defined for ReferenceTypes in this standard. Additional parts this series of standards may define additional Properties for ReferenceTypes.

HasSubtype References are used to define subtypes of ReferenceTypes. It is not required to provide the HasSubtype Reference for the supertype, but it is required that the subtype provides the inverse Reference to its supertype. The following rules for subtyping apply.

1. The semantic of a ReferenceType (e.g. “spans a hierarchy”) is inherited to its subtypes and can be refined there (e.g. “spans a special hierarchy”). The DisplayName, and also the InverseName for non-symmetric ReferenceTypes, reflect the specialization.
2. If a ReferenceType specifies some constraints (e.g. “allow no loops”) this is inherited and can only be refined (e.g. inheriting “no loops” could be refined as “shall be a tree – only one parent”) but not lowered (e.g. “allow loops”).
3. The constraints concerning which NodeClasses can be referenced are also inherited and can only be further restricted. That is, if a ReferenceType “A” is not allowed to relate an Object with an ObjectType, this is also true for its subtypes.
4. A ReferenceType shall have exactly one supertype, except for the References ReferenceType defined in 7.2 as the root type of the ReferenceType hierarchy. The ReferenceType hierarchy does not support multiple inheritances.

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

Name	Use	Data Type	Description
Attributes
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.
References
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.
Standard Properties
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.

Objects are used to represent systems, system components, real-world objects and software objects. Objects are defined using the Object NodeClass, specified in Table 11.

Table 11 – Object NodeClass

Name	Use	Data Type	Description
Attributes
Base NodeClass Attributes	M	--	Inherited from the Base NodeClass. See 5.2.
EventNotifier	M	EventNotifierType	The EventNotifier Attribute is used to indicate if the Node can be used to subscribe to Events or the read / write historic Events. The EventNotifierType is defined in 0.
References
HasComponent	0..*		HasComponent References identify the DataVariables, the Methods and Objects contained in the Object.
HasProperty	0..*		HasProperty References identify the Properties of the Object.
HasModellingRule	0..1		Objects can point to at most one ModellingRule Object using a HasModellingRule Reference (see 6.4.4 for details on ModellingRules).
HasTypeDefinition	1		The HasTypeDefinition Reference points to the type definition of the Object. Each Object shall have exactly one type definition and therefore be the SourceNode of exactly one HasTypeDefinition Reference pointing to an ObjectType. See 4.5 for a description of type definitions.
HasEventSource	0..*		The HasEventSource Reference points to event sources of the Object. References of this type can only be used for Objects having their “SubscribeToEvents” bit set in the EventNotifier Attribute. See 7.17 for details.
HasNotifier	0..*		The HasNotifier Reference points to notifiers of the Object. References of this type can only be used for Objects having their “SubscribeToEvents” bit set in the EventNotifier Attribute. See 7.18 for details.
Organizes	0..*		This Reference should be used only for Objects of the ObjectType FolderType (see 5.5.3).
<other References>	0..*		Objects may contain other References.
Standard Properties
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.
Icon	O	Image	The Icon Property provides an image that can be used by Clients when displaying the Node. It is expected that the Icon Property contains a relatively small image.
NamingRule	O	NamingRuleType	The NamingRule Property defines the NamingRule of a ModellingRule (see 6.4.4.2.1 for details). This Property shall only be used for Objects of the type ModellingRuleType defined in 6.4.4.

The Object NodeClass inherits the base Attributes from the Base NodeClass defined in 5.2.

The mandatory EventNotifier Attribute identifies whether the Object can be used to subscribe to Events or to read and write the history of the Events.

The Object NodeClass uses the HasComponent Reference to define the DataVariables, Objects and Methods of an Object.

It uses the HasProperty Reference to define the Properties of an Object. The Property NodeVersion is used to indicate the version of the Object. The Property Icon provides an icon of the Object. The Property NamingRule defines the NamingRule of a ModellingRule and shall only be applied to Objects of type ModellingRuleType. There are no additional Properties defined for Objects in this document. Additional parts of this series of standards may define additional Properties for Objects.

To specify its ModellingRule, an Object can use at most one HasModellingRule Reference pointing to a ModellingRule Object. ModellingRules are defined in 6.4.4.

HasNotifier and HasEventSource References are used to provide information about eventing and can only be applied to Objects used as event notifiers. Details are defined in 7.16 and 7.18.

The HasTypeDefinition Reference points to the ObjectType used as type definition of the Object.

Objects may use any additional References to define relationships to other Nodes. No restrictions are placed on the types of References used or on the NodeClasses of the Nodes that may be referenced. However, restrictions may be defined by the ReferenceType excluding its use for Objects. Standard ReferenceTypes are described in Clause 7.

If the Object is used as an InstanceDeclaration (see 4.5) then all Nodes referenced with forward hierarchical References direction shall have unique BrowseNames in the context of this Object.

If the Object is created based on an InstanceDeclaration then it shall have the same BrowseName as its InstanceDeclaration.

ObjectTypes provide definitions for Objects. ObjectTypes are defined using the ObjectType NodeClass, which is specified in Table 12.

Table 12 – ObjectType NodeClass

Name	Use	Data Type	Description
Attributes
Base NodeClass Attributes	M	--	Inherited from the Base NodeClass. See 5.2.
IsAbstract	M	Boolean	A boolean Attribute with the following values: TRUEit is an abstract ObjectType, i.e. no Objects of this type shall exist, only Objects of its subtypes. FALSEit is not an abstract ObjectType, i.e. Objects of this type can exist.
References
HasComponent	0..*		HasComponent References identify the DataVariables, the Methods, and Objects contained in the ObjectType. If and how the referenced Nodes are instantiated when an Object of this type is instantiated, is specified in 6.4.
HasProperty	0..*		HasProperty References identify the Properties of the ObjectType. If and how the Properties are instantiated when an Object of this type is instantiated, is specified in 6.4.
HasSubtype	0..*		HasSubtype References identify ObjectTypes that are subtypes of this type. The inverse SubtypeOf Reference identifies the parent type of this type.
GeneratesEvent	0..*		GeneratesEvent References identify the type of Events instances of this type may generate.
<other References>	0..*		ObjectTypes may contain other References that can be instantiated by Objects defined by this ObjectType.
Standard Properties
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.
Icon	O	Image	The Icon Property provides an image that can be used by Clients when displaying the Node. It is expected that the Icon Property contains a relatively small image.

The ObjectType NodeClass inherits the base Attributes from the Base NodeClass defined in 5.2. The additional IsAbstract Attribute indicates if the ObjectType is abstract or not.

The ObjectType NodeClass uses the HasComponent References to define the DataVariables, Objects, and Methods for it.

The HasProperty Reference is used to identify the Properties. The Property NodeVersion is used to indicate the version of the ObjectType. The Property Icon provides an icon of the ObjectType. There are no additional Properties defined for ObjectTypes in this document. Additional parts of this series of standards may define additional Properties for ObjectTypes.

HasSubtype References are used to subtype ObjectTypes. ObjectType subtypes inherit the general semantics from the parent type. The general rules for subtyping apply as defined in Clause 6. It is not required to provide the HasSubtype Reference for the supertype, but it is required that the subtype provides the inverse Reference to its supertype.

GeneratesEvent References identify the type of Events that instances of the ObjectType may generate. These Objects may be the source of an Event of the specified type or one of its subtypes. Servers should make GeneratesEvent References bidirectional References. However, it is allowed to be unidirectional when the Server is not able to expose the inverse direction pointing from the EventType to each ObjectType supporting the EventType. Note that the EventNotifier Attribute of an Object and the GeneratesEvent References of its ObjectType are completely unrelated. Objects that can generate Events might not be used as Objects to which Clients subscribe to get the corresponding Event notifications.

GeneratesEvent References are optional, i.e. Objects may generate Events of an EventType that is not exposed by its ObjectType.

ObjectTypes may use any additional References to define relationships to other Nodes. No restrictions are placed on the types of References used or on the NodeClasses of the Nodes that may be referenced. However, restrictions may be defined by the ReferenceType excluding its use for ObjectTypes. Standard ReferenceTypes are described in Clause 7.

All Nodes referenced with forward hierarchical References shall have unique BrowseNames in the context of an ObjectType (see 4.5).

The ObjectType FolderType is formally defined in OPC 10000-5. Its purpose is to provide Objects that have no other semantic than organizing of the AddressSpace. A special ReferenceType is introduced for those Folder Objects, the Organizes ReferenceType. The SourceNode of such a Reference should always be a View or an Object of the ObjectType FolderType; the TargetNode can be of any NodeClass. Organizes References can be used in any combination with HasChild References (HasComponent, HasProperty, etc.; see 7.5) and do not prevent loops. Thus, they can be used to span multiple hierarchies.

Objects are always based on an ObjectType, i.e. they have a HasTypeDefinition Reference pointing to its ObjectType.

Clients can create Objects using the AddNodes Service defined in OPC 10000-4. The Service requires specifying the TypeDefinitionNode of the Object. An Object created by the AddNodes Service contains all components defined by its ObjectType dependent on the ModellingRules specified for the components. However, the Server may add additional components and References to the Object and its components that are not defined by the ObjectType. This behaviour is Server dependent. The ObjectType only specifies the minimum set of components that shall exist for each Object of an ObjectType.

In addition to the AddNodes Service ObjectTypes may have a special Method with the BrowseName “Create”. This Method is used to create an Object of this ObjectType. This Method may be useful for the creation of Objects where the semantic of the creation should differ from the default behaviour expected in the context of the AddNodes Service. For example, the values should directly differ from the default values or additional Objects should be added, etc. The input and output arguments of this Method depend on the ObjectType; the only commonality is the BrowseName identifying that this Method will create an Object based on the ObjectType. Servers should not provide a Method on an ObjectType with the BrowseName “Create” for any other purpose than creating Objects of the ObjectType.

Two types of Variables are defined, Properties and DataVariables. Although they differ in the way they are used as described in 4.4 and have different constraints described in the remainder of 5.6 they use the same NodeClass described in 5.6.2. The constraints of Properties based on this NodeClass are defined in 5.6.3, the constraints of DataVariables in 5.6.4.

Variables are used to represent values which may be simple or complex. Variables are defined by VariableTypes, as specified in 5.6.5.

Variables are always defined as Properties or DataVariables of other Nodes in the AddressSpace. They are never defined by themselves. A Variable is always part of at least one other Node, but may be related to any number of other Nodes. Variables are defined using the Variable NodeClass, specified in Table 13.

Table 13 – Variable NodeClass

Name	Use	Data Type	Description
Attributes
Base NodeClass Attributes	M	--	Inherited from the Base NodeClass. See 5.2.
Value	M	Defined by the DataType Attribute	The most recent value of the Variable that the Server has. Its data type is defined by the DataType Attribute. It is the only Attribute that does not have a data type associated with it. This allows all Variables to have a value defined by the same Value Attribute.
DataType	M	NodeId	NodeId of the DataType definition for the Value Attribute. Standard DataTypes are defined in Clause 8.
ValueRank	M	Int32	This Attribute indicates whether the Value Attribute of the Variable is an array and how many dimensions the array has. It may have the following values: n  > 1: the Value is an array with the specified number of dimensions. OneDimension (1): The value is an array with one dimension. OneOrMoreDimensions (0): The value is an array with one or more dimensions. Scalar (−1): The value is not an array. Any (−2): The value can be a scalar or an array with any number of dimensions. ScalarOrOneDimension (−3): The value can be a scalar or a one dimensional array. All DataTypes are considered to be scalar, even if they have array-like semantics like ByteString and String.
ArrayDimensions	O	UInt32[]	This Attribute specifies the maximum supported length of each dimension. If the maximum is unknown the value shall be 0. The number of elements shall be equal to the value of the ValueRank Attribute. This Attribute shall be null if ValueRank ≤ 0. For example, if a Variable is defined by the following C array: Int32 myArray[346]; then this Variable’s DataType would point to an Int32 and the Variable’s ValueRank has the value 1 and the ArrayDimensions is an array with one entry having the value 346. The maximum number of elements of an array transferred on the wire is 2147483647 (max Int32).
AccessLevel	M	AccessLevelType	The AccessLevel Attribute is used to indicate how the Value of a Variable can be accessed (read/write) and if it contains current and/or historic data. The AccessLevel does not take any user access rights into account, i.e. although the Variable is writable this may be restricted to a certain user / user group. The AccessLevelType is defined in 8.57.
UserAccessLevel	M	AccessLevelType	The UserAccessLevel Attribute is used to indicate how the Value of a Variable can be accessed (read/write) and if it contains current or historic data taking user access rights into account. The AccessLevelType is defined in 8.57.
MinimumSamplingInterval	O	Duration	The MinimumSamplingInterval Attribute indicates how “current” the Value of the Variable will be kept. It specifies (in milliseconds) how fast the Server can reasonably sample the value for changes (see OPC 10000-4 for a detailed description of sampling interval). A MinimumSamplingInterval of 0 indicates that the Server is to monitor the item continuously. A MinimumSamplingInterval of -1 means indeterminate.
Historizing	M	Boolean	The Historizing Attribute indicates whether the Server is actively collecting data for the history of the Variable. This differs from the AccessLevel Attribute which identifies if the Variable has any historical data. A value of TRUE indicates that the Server is actively collecting data. A value of FALSE indicates the Server is not actively collecting data. Default value is FALSE.
AccessLevelEx	O	AccessLevelExType	The AccessLevelEx Attribute is used to indicate how the Value of a Variable can be accessed (read/write), if it contains current and/or historic data and its atomicity. The AccessLevelEx does not take any user access rights into account, i.e. although the Variable is writable this may be restricted to a certain user / user group. The AccessLevelEx is an extended version of the AccessLevel attribute and as such contains the 8 bits of the AccessLevel attribute as the first 8 bits. The AccessLevelEx is a 32-bit unsigned integer with the structure defined in the 8.58. If this Attribute is not provided the information provided by these additional Fields is unknown.
References
HasModellingRule	0..1		Variables can point to at most one ModellingRule Object using a HasModellingRule Reference (see 6.4.4 for details on ModellingRules).
HasProperty	0..*		HasProperty References are used to identify the Properties of a DataVariable. Properties are not allowed to be the SourceNode of HasProperty References.
HasComponent	0..*		HasComponent References are used by complex DataVariables to identify their composed DataVariables. Properties are not allowed to use this Reference.
HasTypeDefinition	1		The HasTypeDefinition Reference points to the type definition of the Variable. Each Variable shall have exactly one type definition and therefore be the SourceNode of exactly one HasTypeDefinition Reference pointing to a VariableType. See 4.5 for a description of type definitions.
<other References>	0..*		Data Variables may be the SourceNode of any other References. Properties may only be the SourceNode of any non-hierarchical Reference.
Standard Properties
NodeVersion	O	String	The NodeVersion Property is used to indicate the version of a DataVariable. It does not apply to Properties. The NodeVersion Property is updated each time a Reference is added or deleted to the Node the Property belongs to. Attribute value changes except for the DataType Attribute 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. Although the relationship of a Variable to its DataType is not modelled using References, changes to the DataType Attribute of a Variable lead to an update of the NodeVersion Property.
LocalTime	O	TimeZoneDataType	The LocalTime Property is only used for DataVariables. It does not apply to Properties. This Property is a structure containing the Offset and the DaylightSavingInOffset flag. The Offset specifies the time difference (in minutes) between the SourceTimestamp (UTC) associated with the value and the time at the location in which the value was obtained. The SourceTimestamp is defined in OPC 10000-4. 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.
AllowNulls	O	Boolean	The AllowNulls Property is only used for DataVariables. It does not apply to Properties. This Property specifies if a null value is allowed for the Value Attribute of the DataVariable. If it is set to true, the Server may return null values and accept writing of null values. If it is set to false, the Server shall never return a null value and shall reject any request writing a null value. If this Property is not provided, it is Server-specific if null values are allowed or not.
ValueAsText	O	LocalizedText	It is used for DataVariables with a finite set of LocalizedTexts associated with its value. For example any DataVariables having an Enumeration DataType. This optional Property provides the localized text representation of the value. It can be used by Clients only interested in displaying the text to subscribe to the Property instead of the value attribute.
MaxStringLength	O	UInt32	Only used for DataVariables having a String DataType. This optional Property indicates the maximum number of bytes supported by the DataVariable.
MaxCharacters	O	UInt32	Only used for DataVariables having a String DataType. This optional Property indicates the maximum number of Unicode characters supported by the DataVariable.
MaxByteStringLength	O	UInt32	Only used for DataVariables having a ByteString DataType. This optional Property indicates the maximum number of bytes supported by the DataVariable.
MaxArrayLength	O	UInt32	Only used for DataVariables having its ValueRank Attribute not set to scalar. This optional Property indicates the maximum length of an array supported by the DataVariable. In a multidimensional array it indicates the overall length. For example, a three-dimensional array of 2 x 3 x 10 has the array length of 60. NOTE In order to expose the length of an array of bytes do not use the DataType ByteString but an array of the DataType Byte. In that case the MaxArrayLength applies.
EngineeringUnits	O	EUInformation	Only used for DataVariables having a Number DataType. This optional Property indicates the engineering units for the value of the DataVariable (e.g. hertz or seconds). Details about the Property and what engineering units should be used are defined in OPC 10000-8. The DataType EUInformation is also defined in OPC 10000-8.

The Variable NodeClass inherits the base Attributes from the Base NodeClass defined in 5.2.

The Variable NodeClass also defines a set of Attributes that describe the Variable’s Runtime value. The Value Attribute represents the Variable value. The DataType, ValueRank and ArrayDimensions Attributes provide the capability to describe simple and complex values.

The AccessLevel Attribute indicates the accessibility of the Value of a Variable not taking user access rights into account. If the OPC UA Server does not have the ability to get the AccessLevel information from the underlying system then it should state that it is readable and writable. If a read or write operation is called on the Variable then the Server should transfer this request and return the corresponding StatusCode even if such a request is rejected. StatusCodes are defined in OPC 10000-4.

The SemanticChange flag of the AccessLevel Attribute is used for Properties that may change and define semantic aspects of the parent Node. For example, the EngineeringUnit Property describes the semantic of a DataVariable, whereas the Icon Property does not. In this example, if the EngineeringUnit Property may change while the Server is running, the SemanticChange flag shall be set for it.

Servers that support Event subscriptions shall generate a SemanticChangeEvent whenever a Property with SemanticChange flag set changes.

If a Variable having a Property with SemanticChange flag set is used in a Subscription and the Property value changes, then the SemanticsChanged bit of the StatusCode shall be set as defined in OPC 10000-4. Clients subscribing to a Variable should look at the StatusCode to identify if the semantic has changed and retrieve the relevant Properties before processing the value returned from the Subscription.

The UserAccessLevel Attribute indicates the accessibility of the Value of a Variable taking user access rights into account. If the OPC UA Server does not have the ability to get any user access rights related information from the underlying system then it should use the same bit mask as used in the AccessLevel Attribute. The UserAccessLevel Attribute can restrict the accessibility indicated by the AccessLevel Attribute, but not exceed it. Clients should not assume access rights based on the UserAccessLevel Attribute. For example it is possible that the Server returns an error due to some server specific change which was not reflected in the state of this Attribute at the time the Client accessed the Variable.

The MinimumSamplingInterval Attribute specifies how fast the Server can reasonably sample the value for changes. The accuracy of this value (the ability of the Server to attain “best case” performance) can be greatly affected by system load and other factors.

The Historizing Attribute indicates whether the Server is actively collecting data for the history of the Variable. See OPC 10000-11 for details on historizing Variables.

Clients may read or write Variable values, or monitor them for value changes, as specified in OPC 10000-4. OPC 10000-8 defines additional rules when using the Services for automation data.

To specify its ModellingRule, a Variable can use at most one HasModellingRule Reference pointing to a ModellingRule Object. ModellingRules are defined in 6.4.4.

If the Variable is created based on an InstanceDeclaration (see 4.5) it shall have the same BrowseName as its InstanceDeclaration.

The other References are described separately for Properties and DataVariables in the remainder of 5.6

Properties are used to define the characteristics of Nodes. Properties are defined using the Variable NodeClass, specified in Table 13. However, they restrict their use.

Properties are the leaf of any hierarchy; therefore they shall not be the SourceNode of any hierarchical References. This includes the HasComponent or HasProperty Reference, that is, Properties do not contain Properties and cannot expose their complex structure. However, they may be the SourceNode of any non-hierarchical References.

The HasTypeDefinition Reference points to the VariableType of the Property. Since Properties are uniquely identified by their BrowseName, all Properties shall point to the PropertyType defined in OPC 10000-5.

Properties shall always be defined in the context of another Node and shall be the TargetNode of at least one HasProperty Reference. To distinguish them from DataVariables, they shall not be the TargetNode of any HasComponent Reference. Thus, a HasProperty Reference pointing to a Variable Node defines this Node as a Property.

The BrowseName of a Property is always unique in the context of a Node. It is not permitted for a Node to refer to two Variables using HasProperty References having the same BrowseName.

DataVariables represent the content of an Object. DataVariables are defined using the Variable NodeClass, specified in Table 13.

DataVariables identify their Properties using HasProperty References. Complex DataVariables use HasComponent References to expose their component DataVariables.

The Property NodeVersion indicates the version of the DataVariable.

The Property LocalTime indicates the difference between the SourceTimestamp of the value and the standard time at the location in which the value was obtained.

The Property AllowNulls indicates if null values are allowed for the Value Attribute.

The Property ValueAsText provides a localized text representation for enumeration values.

The Property MaxStringLength indicates the maximum number of bytes of a String value. If a Server does not impose a maximum number of bytes or is not able to determine the maximum number of bytes this Property shall not be provided. If this Property is provided then the MaxCharacters Property shall not be provided.

The Property MaxCharacters indicates the maximum number of Unicode characters of a string value. If a Server does not impose a maximum number of Unicode characters or is not able to determine the maximum number of Unicode characters this Property shall not be provided. If this Property is provided then the MaxStringLength Property shall not be provided.

The Property MaxByteStringLength indicates the maximum number of bytes of a ByteString value. If a Server does not impose a maximum number of bytes or is not able to determine the maximum number of bytes this Property shall not be provided.

The Property MaxArrayLength indicates the maximum allowed array length of the value.

The Property EngineeringUnits indicates the engineering units of the value. There are no additional Properties defined for DataVariables in this part of this document. Additional parts of this series of standards may define additional Properties for DataVariables. OPC 10000-8 defines a set of Properties that can be used for DataVariables.

DataVariables may use additional References to define relationships to other Nodes. No restrictions are placed on the types of References used or on the NodeClasses of the Nodes that may be referenced. However, restrictions may be defined by the ReferenceType excluding its use for DataVariables. Standard ReferenceTypes are described in Clause 7.

A DataVariable is intended to be defined in the context of an Object. However, complex DataVariables may expose other DataVariables, and ObjectTypes and complex VariableTypes may also contain DataVariables. Therefore each DataVariable shall be the TargetNode of at least one HasComponent Reference coming from an Object, an ObjectType, a DataVariable or a VariableType. DataVariables shall not be the TargetNode of any HasProperty References. Therefore, a HasComponent Reference pointing to a Variable Node identifies it as a DataVariable.

The HasTypeDefinition Reference points to the VariableType used as type definition of the DataVariable.

If the DataVariable is used as InstanceDeclaration (see 4.5) all Nodes referenced with forward hierarchical References shall have unique BrowseNames in the context of this DataVariable.

VariableTypes are used to provide type definitions for Variables. VariableTypes are defined using the VariableType NodeClass, as specified in Table 14.

Table 14 – VariableType NodeClass

Name	Use	Data Type	Description
Attributes
Base NodeClass Attributes	M	--	Inherited from the Base NodeClass. See 5.2
Value	O	Defined by the DataType attribute	The default Value for instances of this type.
DataType	M	NodeId	NodeId of the data type definition for instances of this type.
ValueRank	M	Int32	This Attribute indicates whether the Value Attribute of the VariableType is an array and how many dimensions the array has. It may have the following values: n > 1: the Value is an array with the specified number of dimensions. OneDimension (1): The value is an array with one dimension. OneOrMoreDimensions (0): The value is an array with one or more dimensions. Scalar (−1): The value is not an array. Any (−2): The value can be a scalar or an array with any number of dimensions. ScalarOrOneDimension (−3): The value can be a scalar or a one dimensional array. NOTE All DataTypes are considered to be scalar, even if they have array-like semantics like ByteString and String.
ArrayDimensions	O	UInt32[]	This Attribute specifies the length of each dimension for an array value. The Attribute specifies the maximum supported length of each dimension. If the maximum is unknown the value is 0. The number of elements shall be equal to the value of the ValueRank Attribute. This Attribute shall be null if ValueRank ≤ 0. For example, if a VariableType is defined by the following C array: Int32 myArray[346]; then this VariableType’s DataType would point to an Int32, the VariableType’s ValueRank has the value 1 and the ArrayDimensions is an array with one entry having the value 346.
IsAbstract	M	Boolean	A boolean Attribute with the following values: TRUEit is an abstract VariableType, i.e. no Variable of this type shall exist, only of its subtypes. FALSEit is not an abstract VariableType, i.e. Variables of this type can exist.
References
HasProperty	0..*		HasProperty References are used to identify the Properties of the VariableType. The referenced Nodes may be instantiated by the instances of this type, depending on the ModellingRules defined in 6.4.4.
HasComponent	0..*		HasComponent References are used for complex VariableTypes to identify their containing DataVariables. Complex VariableTypes can only be used for DataVariables. The referenced Nodes may be instantiated by the instances of this type, depending on the ModellingRules defined in 6.4.4.
HasSubtype	0..*		HasSubtype References identify VariableTypes that are subtypes of this type. The inverse subtype of Reference identifies the parent type of this type.
GeneratesEvent	0..*		GeneratesEvent References identify the type of Events instances of this type may generate.
<other References>	0..*		VariableTypes may contain other References that can be instantiated by Variables defined by this VariableType. ModellingRules are defined in 6.4.4.
Standard Properties
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 except for the DataType Attribute 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. Although the relationship of a VariableType to its DataType is not modelled using References, changes to the DataType Attribute of a VariableType lead to an update of the NodeVersion Property.

The VariableType NodeClass inherits the base Attributes from the Base NodeClass defined in 5.2. The VariableType NodeClass also defines a set of Attributes that describe the default or initial value of its instance Variables. The Value Attribute represents the default value. The DataType, ValueRank and ArrayDimensions Attributes provide the capability to describe simple and complex values. The IsAbstract Attribute defines if the type can be directly instantiated.

The VariableType NodeClass uses HasProperty References to define the Properties and HasComponent References to define DataVariables. Whether they are instantiated depends on the ModellingRules defined in 6.4.4.

The Property NodeVersion indicates the version of the VariableType. There are no additional Properties defined for VariableTypes in this document. Additional parts of this series of standards may define additional Properties for VariableTypes. OPC 10000-8 defines a set of Properties that can be used for VariableTypes.

HasSubtype References are used to subtype VariableTypes. VariableType subtypes inherit the general semantics from the parent type. The general rules for subtyping are defined in Clause 6. It is not required to provide the HasSubtype Reference for the supertype, but it is required that the subtype provides the inverse Reference to its supertype.

GeneratesEvent References identify that Variables of the VariableType may be the source of an Event of the specified EventType or one of its subtypes. Servers should make GeneratesEvent References bidirectional References. However, it is allowed to be unidirectional when the Server is not able to expose the inverse direction pointing from the EventType to each VariableType supporting the EventType.

GeneratesEvent References are optional, i.e. Variables may generate Events of an EventType that is not exposed by its VariableType.

VariableTypes may use any additional References to define relationships to other Nodes. No restrictions are placed on the types of References used or on the NodeClasses of the Nodes that may be referenced. However, restrictions may be defined by the ReferenceType excluding its use for VariableTypes. Standard ReferenceTypes are described in Clause 7.

All Nodes referenced with forward hierarchical References shall have unique BrowseNames in the context of the VariableType (see 4.5).

Variables are always based on a VariableType, i.e. they have a HasTypeDefinition Reference pointing to its VariableType.

Clients can create Variables using the AddNodes Service defined in OPC 10000-4. The Service requires specifying the TypeDefinitionNode of the Variable. A Variable created by the AddNodes Service contains all components defined by its VariableType dependent on the ModellingRules specified for the components. However, the Server may add additional components and References to the Variable and its components that are not defined by the VariableType. This behaviour is Server dependent. The VariableType only specifies the minimum set of components that shall exist for each Variable of a VariableType.

Methods define callable functions. Methods are invoked using the Call Service defined in OPC 10000-4. Method invocations are not represented in the AddressSpace. Method invocations always run to completion and always return responses when complete. Methods are defined using the Method NodeClass, specified in Table 15.

Table 15 – Method NodeClass

Name	Use	Data Type	Description
Attributes
Base NodeClass Attributes	M	--	Inherited from the Base NodeClass. See 5.2.
Executable	M	Boolean	The Executable Attribute indicates if the Method is currently executable (“False” means not executable, “True” means executable). The Executable Attribute does not take any user access rights into account, i.e. although the Method is executable this may be restricted to a certain user / user group.
UserExecutable	M	Boolean	The UserExecutable Attribute indicates if the Method is currently executable taking user access rights into account (“False” means not executable, “True” means executable).
References
HasProperty	0..*		HasProperty References identify the Properties for the Method.
HasModellingRule	0..1		Methods can point to at most one ModellingRule Object using a HasModellingRule Reference (see 6.4.4 for details on ModellingRules).
GeneratesEvent	0..*		GeneratesEvent References identify the type of Events that will be generated whenever the Method is called.
AlwaysGeneratesEvent	0..*		AlwaysGeneratesEvent References identify the type of Events that shall be generated whenever the Method is called.
<other References>	0..*		Methods may contain other References.
Standard Properties
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.
InputArguments	O	Argument[]	The InputArguments Property is used to specify the arguments that shall be used by a client when calling the Method.
OutputArguments	O	Argument[]	The OutputArguments Property specifies the result returned from the Method call.

The Method NodeClass inherits the base Attributes from the Base NodeClass defined in 5.2. The Method NodeClass defines no additional Attributes.

The Executable Attribute indicates whether the Method is executable, not taking user access rights into account. If the OPC UA Server cannot get the Executable information from the underlying system, it should state that it is executable. If a Method is called then the Server should transfer this request and return the corresponding StatusCode even if such a request is rejected. StatusCodes are defined in OPC 10000-4.

The UserExecutable Attribute indicates whether the Method is executable, taking user access rights into account. If the OPC UA Server cannot get any user rights related information from the underlying system, it should use the same value as used in the Executable Attribute. The UserExecutable Attribute can be set to “False”, even if the Executable Attribute is set to “True”, but it shall be set to “False” if the Executable Attribute is set to “False”. Clients cannot assume a Method can be executed based on the UserExecutable Attribute. It is possible that the Server may return an access denied error due to some Server specific change which was not reflected in the state of this Attribute at the time the Client accessed it.

Properties may be defined for Methods using HasProperty References. The Properties InputArguments and OutputArguments specify the input arguments and output arguments of the Method. Both contain an array of the DataType Argument as specified in 8.6. An empty array or a Property that is not provided indicates that there are no input arguments or output arguments for the Method.

The Property NodeVersion indicates the version of the Method. There are no additional Properties defined for Methods in this document. Additional parts of this series of standards may define additional Properties for Methods.

To specify its ModellingRule, a Method can use at most one HasModellingRule Reference pointing to a ModellingRule Object. ModellingRules are defined in 6.4.4.

GeneratesEvent References identify that Methods may generate an Event of the specified EventType or one of its subtypes for every call of the Method. A Server may generate one Event for each referenced EventType when a Method is successfully called.

AlwaysGeneratesEvent References identify that Methods will generate an Event of the specified EventType or one of its subtypes for every call of the Method. A Server shall always generate one Event for each referenced EventType when a Method is successfully called.

Servers should make GeneratesEvent References bidirectional References. However, it is allowed to be unidirectional when the Server is not able to expose the inverse direction pointing from the EventType to each Method generating the EventType.

GeneratesEvent References are optional, i.e. the call of a Method may produce Events of an EventType that is not referenced with a GeneratesEvent Reference by the Method.

Methods may use additional References to define relationships to other Nodes. No restrictions are placed on the types of References used or on the NodeClasses of the Nodes that may be referenced. However, restrictions may be defined by the ReferenceType excluding its use for Methods. Standard ReferenceTypes are described in Clause 7.

A Method shall always be the TargetNode of at least one HasComponent Reference. The SourceNode of these HasComponent References shall be an Object or an ObjectType. If a Method is called then the NodeId of one of those Nodes shall be put into the Call Service defined in OPC 10000-4 as parameter to detect the context of the Method operation.

If the Method is used as InstanceDeclaration (see 4.5) all Nodes referenced with forward hierarchical References shall have unique BrowseNames in the context of this Method.

The DataType Model is used to define simple and structured data types. Data types are used to describe the structure of the Value Attribute of Variables and their VariableTypes. Therefore each Variable and VariableType is pointing with its DataType Attribute to a Node of the DataType NodeClass as shown in Figure 10.

Figure 10 – Variables, VariableTypes and their DataTypes

In many cases, the NodeId of the DataType Node – the DataTypeId – will be well-known to Clients and Servers. Clause 8 defines DataTypes and OPC 10000-6 defines their DataTypeIds. In addition, other organizations may define DataTypes that are well-known in the industry. Well-known DataTypeIds provide for commonality across OPC UA Servers and allow Clients to interpret values without having to read the type description from the Server. Therefore, Servers may use well-known DataTypeIds without representing the corresponding DataType Nodes in their AddressSpaces.

In other cases, DataTypes and their corresponding DataTypeIds may be vendor-defined. Servers should attempt to expose the DataType Nodes and the information about the structure of those DataTypes for Clients to read, although this information might not always be available to the Server.

Figure 11 illustrates the Nodes used in the AddressSpace to describe the structure of a DataType. The DataType points to an Object of type DataTypeEncodingType. Each DataType can have several DataTypeEncoding, for example “Default”, “UA Binary” and “XML” encoding. Services in OPC 10000-4 allow Clients to request an encoding or choosing the “Default” encoding. Each DataTypeEncoding is used by exactly one DataType, that is, it is not permitted for two DataTypes to point to the same DataTypeEncoding.

Figure 11 – DataType Model

Since the NodeId of the DataTypeEncoding will be used in some Mappings to identify the DataType and it’s encoding as defined in OPC 10000-6, those NodeIds may also be well-known for well-known DataTypeIds.

Different kinds of DataTypes are handled differently regarding their encoding and according to whether this encoding is represented in the AddressSpace.

Built-in DataTypes are a fixed set of DataTypes (see OPC 10000-6 for a complete list of Built-in DataTypes). They have no encodings visible in the AddressSpace since the encoding should be known to all OPC UA products. Examples of Built-in DataTypes are Int32 (see 8.26) and Double (see 8.12).

Simple DataTypes are subtypes of the Built-in DataTypes. They are handled on the wire like the Built-in DataType, i.e. they cannot be distinguished on the wire from their Built-in supertypes. Since they are handled like Built-in DataTypes regarding the encoding they cannot have encodings defined in the AddressSpace. Clients can read the DataType Attribute of a Variable or VariableType to identify the Simple DataType of the Value Attribute. An example of a Simple DataType is Duration. It is handled on the wire as a Double but the Client can read the DataType Attribute and thus interpret the value as defined by Duration (see 8.13).

Structured DataTypes are DataTypes that represent structured data and are not defined as Built-in DataTypes. Structured DataTypes inherit directly or indirectly from the DataType Structure defined in 8.33. Structured DataTypes may have several encodings and the encodings are exposed in the AddressSpace. How the encoding of Structured DataTypes is handled on the wire is defined in OPC 10000-6. The encoding of the Structured DataType is transmitted with each value, thus Clients are aware of the DataType without reading the DataType Attribute. The encoding has to be transmitted so the Client is able to interpret the data. An example of a Structured DataType is Argument (see 8.6).

Enumeration DataTypes are DataTypes that represent discrete sets of named values. Enumerations are always encoded as Int32 on the wire as defined in OPC 10000-6. Enumeration DataTypes inherit directly or indirectly from the DataType Enumeration defined in 8.14. Enumerations have no encodings exposed in the AddressSpace. To expose the human-readable representation of an enumerated value the DataType Node may have the EnumStrings Property that contains an array of LocalizedText. The Integer representation of the enumeration value points to a position within that array. EnumValues Property can be used instead of the EnumStrings to support integer representation of enumerations that are not zero-based or have gaps. It contains an array of a Structured DataType containing the integer representation as well as the human-readable representation. An example of an enumeration DataType containing a sparse list of Integers is NodeClass which is defined in 8.30.

In addition to the DataTypes described above, abstract DataTypes are also supported, which do not have any encodings and cannot be exchanged on the wire. Variables and VariableTypes use abstract DataTypes to indicate that their Value may be any one of the subtypes of the abstract DataType. An example of an abstract DataType is Integer which is defined in 8.24.

The DataType NodeClass describes the syntax of a Variable Value. DataTypes are defined using the DataType NodeClass, as specified in Table 16.

Table 16 – DataType NodeClass

Name	Use	Data Type	Description
Attributes
Base NodeClass Attributes	M	--	Inherited from the Base NodeClass. See 5.2.
IsAbstract	M	Boolean	A boolean Attribute with the following values: TRUEit is an abstract DataType. FALSEit is not an abstract DataType.
DataTypeDefinition	O	DataTypeDefinition	The DataTypeDefinition Attribute is used to provide the meta data and encoding information for custom DataTypes. The abstract DataTypeDefinition DataType is defined in 8.48. Structure and Union DataTypes The Attribute is mandatory for DataTypes derived from Structure and Union. For such DataTypes, the Attribute contains a structure of the DataType StructureDefinition. The StructureDefinition DataType is defined in 8.49. It is a subtype of DataTypeDefinition. Enumeration and OptionSet DataTypes The Attribute is mandatory for DataTypes derived from Enumeration, OptionSet and subtypes of UInteger representing an OptionSet. For such DataTypes, the Attribute contains a structure of the DataType EnumDefinition. The EnumDefinition DataType is defined in 8.50. It is a subtype of DataTypeDefinition.
References
HasProperty	0..*		HasProperty References identify the Properties for the DataType.
HasSubtype	0..*		HasSubtype References may be used to span a data type hierarchy.
HasEncoding	0..*		HasEncoding References identify the encodings of the DataType represented as Objects of type DataTypeEncodingType. Only concrete Structured DataTypes may use HasEncoding References. Abstract, Built-in, Enumeration, and Simple DataTypes are not allowed to be the SourceNode of a HasEncoding Reference. Each concrete Structured DataType shall point to at least one DataTypeEncoding Object with the BrowseName “Default Binary” or “Default XML” having the NamespaceIndex 0. The BrowseName of the DataTypeEncoding Objects shall be unique in the context of a DataType, i.e. a DataType shall not point to two DataTypeEncodings having the same BrowseName.
Standard Properties
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. Clients shall not use the content for programmatic purposes except for equality comparisions.
EnumStrings	O	LocalizedText[]	The EnumStrings Property only applies for Enumeration DataTypes. It shall not be applied for other DataTypes. If the EnumValues Property is provided, the EnumStrings Property shall not be provided. Each entry of the array of LocalizedText in this Property represents the human-readable representation of an enumerated value. The Integer representation of the enumeration value points to a position of the array.
EnumValues	O	EnumValueType[]	The EnumValues Property only applies for Enumeration DataTypes. It shall not be applied for other DataTypes. If the EnumStrings Property is provided, the EnumValues Property shall not be provided. Using the EnumValues Property it is possible to represent Enumerations with integers that are not zero-based or have gaps (e.g. 1, 2, 4, 8, and 16). Each entry of the array of EnumValueType in this Property represents one enumeration value with its integer notation, human-readable representation and help information.
OptionSetValues	O	LocalizedText[]	The OptionSetValues Property only applies for OptionSet DataTypes and UInteger DataTypes. An OptionSet DataType is used to represent a bit mask and the OptionSetValues Property contains the human-readable representation for each bit of the bit mask. The OptionSetValues Property provides an array of LocalizedText containing the human-readable representation for each bit.

The DataType NodeClass inherits the base Attributes from the Base NodeClass defined in 5.2. The IsAbstract Attribute specifies if the DataType is abstract or not. Abstract DataTypes can be used in the AddressSpace, i.e. Variables and VariableTypes can point with their DataType Attribute to an abstract DataType. However, concrete values can never be of an abstract DataType and shall always be of a concrete subtype of the abstract DataType.

HasProperty References are used to identify the Properties of a DataType. The Property NodeVersion is used to indicate the version of the DataType. The Property EnumStrings contains human-readable representations of enumeration values and is only applied to Enumeration DataTypes. Instead of the EnumStrings Property an Enumeration DataType can also use the EnumValues Property to represent Enumerations with integer values that are not zero-based or containing gaps. There are no additional Properties defined for DataTypes in this standard. Additional parts of this series of standards may define additional Properties for DataTypes.

HasSubtype References may be used to expose a data type hierarchy in the AddressSpace. The semantic of subtyping is only defined to the point, that a Server may provide instances of the subtype instead of the DataType. Clients should not make any assumptions about any other semantic with that information. For example, it might not be possible to cast a value of one data type to its base data type. Servers need not provide HasSubtype References, even if their DataTypes span a type hierarchy. Some restrictions apply for subtyping enumeration DataTypes as defined in 8.14.

HasEncoding References point from the DataType to its DataTypeEncodings. Each concrete Structured DataType can point to many DataTypeEncodings, but each DataTypeEncoding shall belong to one DataType, that is, it is not permitted for two DataType Nodes to point to the same DataTypeEncoding Object using HasEncoding References.

An abstract DataType is not the SourceNode of a HasEncoding Reference. The DataTypeEncoding of an abstract DataType is provided by its concrete subtypes.

DataType Nodes shall not be the SourceNode of other types of References. However, they may be the TargetNode of other References.

If a DataType Node is exposed in the AddressSpace, it shall provide its DataTypeEncodings using HasEncoding References. These References shall be bi-directional. Figure 12 provides an example how DataTypes are modelled in the AddressSpace.

Figure 12 – Example of DataType Modelling

The information on how to encode the DataType is provided in the Attribute DataTypeDefinition of the DataType Node. The content of this Attribute shall not be changed once it had been provided to Clients since Clients might persistently cache this information. If the encoding of a DataType needs to be changed conceptually a new DataType needs to be provided, meaning that a new NodeId shall be used for the DataType. Since Clients identify the DataType via the DataTypeEncodings, also the NodeIds for the DataTypeEncodings of the DataType shall be changed, when the encoding changes.

Table 17 summarises all Attributes defined in this document and points out which NodeClasses use them either in an optional (O) or mandatory (M) way.

Table 17 – Overview of Attributes

Attribute	Variable	Variable Type	Object	Object Type	Reference Type	DataType	Method	View
AccessLevel	M
AccessLevelEx	O
ArrayDimensions	O	O
AccessRestrictions	O	O	O	O	O	O	O	O
BrowseName	M	M	M	M	M	M	M	M
ContainsNoLoops								M
DataType	M	M
DataTypeDefinition						O
Description	O	O	O	O	O	O	O	O
DisplayName	M	M	M	M	M	M	M	M
EventNotifier			M					M
Executable							M
Historizing	M
InverseName					O
IsAbstract		M		M	M	M
MinimumSamplingInterval	O
NodeClass	M	M	M	M	M	M	M	M
NodeId	M	M	M	M	M	M	M	M
RolePermissions	O	O	O	O	O	O	O	O
Symmetric					M
UserAccessLevel	M
UserExecutable							M
UserRolePermissions	O	O	O	O	O	O	O	O
UserWriteMask	O	O	O	O	O	O	O	O
Value	M	O
ValueRank	M	M
WriteMask	O	O	O	O	O	O	O	O