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	AccessRestrictionType	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 identifierType and identifier NodeId elements of a Node as well as the Namespace Uri which the namespaceIndex NodeId element references. A Server may change the namespaceIndex NodeId element of a Node with future Sessions and therefore a Client shall not assume the namespaceIndex will not change. 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.29.

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.

Standards bodies defining standard type definitions shall use their namespace(s) for the NodeId of the TypeDefinitionNode as well as for the BrowseName of the TypeDefinitionNode. BrowseNames of TypeDefinitionNodes, ReferenceTypes, and DataTypes shall be unique. A ny well-known instances used as entry points shall also be unique. For example, the Root Node defined in OPC 10000-5.

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. If a Server accepts a case insensitive BrowseName it needs to ensure that the uniqueness of the BrowseName does not depend on case.

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 writeable 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 writeable. 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 8.60.

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 8.60.

The UserWriteMask Attribute can only further restrict the WriteMask Attribute, when it is set to not writeable 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. See 8.55

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 14). 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 allows writes to the RolePermissions it shall preserve all bits written by the Client even if they are not valid for the Node. When a Client reads the RolePermissions or UserRolePermissions it shall ignore bits that are not valid for the Node.

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 14 – 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 performing a logical OR of 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.9.

This Attribute shall not be writeable. When a Client reads the UserRolePermissions it shall ignore bits that are not valid for the Node.

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 14). 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.