The OPC UA Address Space Model defines a Base NodeClassfrom which all other NodeClassesare derived. The derived NodeClassesrepresent the various components of the OPC UA Object Model (see 4.2). The Attributesof the Base NodeClassare specified in Table 7. There are no Referencesspecified 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 Referencesspecified for this NodeClass

Nodesare unambiguously identified using a constructed identifier called the NodeId. Some Serversmay accept alternative NodeIdsin addition to the canonical NodeIdrepresented in this Attribute. A Servershall persist the NodeId of a Node, that is, it shall not generate new NodeIdswhen rebooting. The structure of the NodeIdis defined in 8.2.

The NodeClass Attributeidentifies the NodeClassof a Node. Its data type is defined in 8.30.

Nodeshave a BrowseName Attributethat is used as a non-localised human-readable name when browsing the AddressSpaceto create paths out of BrowseNames. The TranslateBrowsePathsToNodeIds Servicedefined in OPC 10000-4can be used to follow a path constructed of BrowseNames.

A BrowseNameshould never be used to display the name of a Node. The DisplayNameshould be used instead for this purpose.

Unlike NodeIds, the BrowseNamecannot be used to unambiguously identify a Node. Different Nodesmay have the same BrowseName.

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

Serversmay often choose to use the same namespace for the NodeIdand the BrowseName. However, if they want to provide a standard Property, itsBrowseNameshall have the namespace of the standards body although the namespace of the NodeIdreflects something else, for example the local Server.

It is recommended that standard bodies defining standard type definitions use their namespace for the NodeIdof the TypeDefinitionNodeas well as for the BrowseNameof the TypeDefinitionNode.

The string-part of the BrowseNameis case sensitive. That is, Clientsshall consider them case sensitive. Serversare allowed to handle BrowseNamespassed in Servicerequests as case insensitive. Examples are the TranslateBrowsePathsToNodeIds Serviceor Eventfilter.

The DisplayName Attributecontains the localised name of the Node. Clientsshould use this Attributeif they want to display the name of the Nodeto the user. They should not use the BrowseNamefor this purpose. The Servermay maintain one or more localised representations for each DisplayName. Clientsnegotiate the locale to be returned when they open a session with the Server. Refer to OPC 10000-4for a description of session establishment and locales. Subclause 8.5defines the structure of the DisplayName. The string part of the DisplayNameis restricted to 512 characters.

The optional Description Attributeshall explain the meaning of the Nodein a localised text using the same mechanisms for localisation as described for the DisplayNamein 5.2.5.

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

If the OPC UA Serverdoes not have the ability to get the WriteMaskinformation for a specific Attributefrom the underlying system, it should state that it is writable. If a write operation is called on the Attribute, the Servershould transfer this request and return the corresponding StatusCodeif such a request is rejected. StatusCodesare defined in OPC 10000-4.

The AttributeWriteMask DataTypeis defined in 0.

The optional UserWriteMask Attributeexposes the possibilities of a client to write the Attributesof the Nodetaking user access rights into account. It uses the AttributeWriteMask DataTypewhich is defined in 0.

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

Clientscannot assume an Attributecan be written based on the UserWriteMask Attribute.It is possible that the Servermay return an access denied error due to some server specific change which was not reflected in the state of this Attributeat the time the Clientaccessed it.

The optional RolePermissions Attributespecifies the Permissionsthat apply to a Nodefor all Roleswhich have access to the Node. The value of the Attributeis an array of RolePermissionType Structures(see Table 8).

Table 8– RolePermissionType

Name

Type

Description

RolePermissionType

Structure

Specifies the Permissionsfor a Role

roleId

NodeId

The NodeIdof the Role Object.

permissions

PermissionType

A mask specifying which Permissionsare available to the Role.

Serversmay allow administrators to write to the RolePermissions Attribute.

If not specified, the value of DefaultRolePermissions Propertyfrom the NamespaceMetadata Objectassociated with the Nodeshall be used instead. If the NamespaceMetadata Objectdoes not define the Propertyor does not exist, then the Servershould not publish any information about how it manages Permissions.

If a Serversupports Permissionsfor a particular Namespaceit shall add the DefaultRolePermissions Propertyto the NamespaceMetadata Objectfor that Namespace(see Figure 8). If a particular Nodein the Namespaceneeds to override the default values, the Serveradds the RolePermissions Attribute to the Node. TheDefaultRolePermissions Propertyand RolePermissions Attribute shall only be readable by administrators. If a Serverallows the Permissionsto be changed these values shall be writeable. If the Serverallows the Permissionsto be overridden for a particular Nodebut does not currently have any Node Permissionsconfigured, then the value of the Attributeshall be an empty array. If the administrator wishes to remove overridden Permissions, an empty array shall be written to this Attribute. Serversshall prevent Permissionsfrom being changed in such a way as to render the Serverinoperable.

If a Serverpublishes information about the Rolesfor aNamespaceassigned to the current Session,it shall add the DefaultUserRolePermissions Property to the NamespaceMetadata Objectfor that Namespace. The value of this Propertyshall be a readonly list of Permissionsfor each Roleassigned to the current Session. If a particular Nodein the Namespaceoverrides the default RolePermissions the Servershall also override theDefaultUserRolePermissions by adding the UserRolePermissions Attribute to the Node. If the Serverallows the Permissionsto be overridden for a particular Nodebut does not currently have any Node Permissionsconfigured, then the Server shall return the value of the DefaultUserRolePermissions Propertyfor the Node Namespace.

If a Serverimplements a vendor specific Role Permissionmodel for a Namespace,it shall not add the DefaultRolePermissions orDefaultUserRolePermissions Properties to the NamespaceMetadata Object.

image011.png

Figure 8– Permissions in the Address Space

The optional UserRolePermissions Attributespecifies the Permissionsthat apply to a Nodefor all Rolesgranted to current Session. The value of the Attributeis an array of RolePermissionType Structures(see Table 8).

Clientsmay determine their effective Permissionsby logically ORing the Permissionsfor each Rolein the array.

The value of this Attributeis derived from the rules used by the Serverto map Sessionsto Roles. This mapping may be vendor specific or it may use the standard Rolemodel defined in 4.8.

This Attribute shall not be writeable.

If not specified, the value of DefaultUserRolePermissions Propertyfrom the Namespace Metadata Objectassociated with the Nodeis used instead. If the NamespaceMetadata Objectdoes not define the Propertyor does not exist, then the Serverdoes not publish any information about Rolesmapped to the current Session.

The optional AccessRestrictions Attributespecifies the AccessRestrictionsthat apply to a Node. Its data type is defined in 8.56. If a Serversupports AccessRestrictionsfor a particular Namespaceit adds the DefaultAccessRestrictions Propertyto the NamespaceMetadata Objectfor that Namespace(see Figure 8). If a particular Nodein the Namespaceneeds to override the default value the Serveradds the AccessRestrictions Attribute to the Node.

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