The remainder of Clause 4 defines the concepts of the AddressSpace. Clause 5 defines the NodeClasses of the AddressSpace representing the AddressSpace concepts. Clause 6 defines details on the type model for ObjectTypes and VariableTypes. Standard ReferenceTypes, DataTypes and EventTypes are defined in Clauses 7 to 8.61.

The informative Annex A describes general considerations on how to use the Address Space Model and the informative Annex B provides a UML Model of the Address Space Model. The normative Annex C defines a graphical notation for OPC UA data.

URIs provide a syntax for constructing unique identifiers for resources that are used in several different contexts with this specification. Three use cases where implementors may need to construct their own URIs are:

• NamespaceUris used to identify an information model. NamespaceUris appear in UANodeSets (see OPC 10000-6) and in the NamespaceArray in a Server AddressSpace (see OPC 10000-5);
• ApplicationUris identify an OPC UA Application running on a particular Device and are assigned by the OwnerOperator or automatically created by the application software. An ApplicationInstance Certificate has the ApplicationUri in the subjectAltName (see OPC 10000-6);
• ProductInstanceUris identify a Device and are assigned by the Device Manufacturer (see OPC 10000-21). A DeviceIdentity Certificate has the ProductInstanceUri in the subjectAltName.

These URIs conform to RFC 3986, however, this specification is very open ended. This clause provides recommendations for constructing these URIs.

The recommendations help ensure that URIs are unique by providing a scope controlled by a single authority (e.g. the domain name) and are human readable. Programs shall always treat URIs as opaque strings that can only be tested for equality with a case sensitive string comparison.

URIs should be tag URIs (RFC 4151) or HTTP URLs (RFC 3986). URLs should only be used if they link to actual webpages.

The scheme and domain name portions of the URI are in lower case. URIs may include query subcomponents and/or fragments.

Below are recommended URI formats for different use cases.

1) NamespaceUri assigned by the creator of a InformationModel:

tag:<authority-domain-name>,<yyyy-MM>:UA:<model-short-name>

http://<authority-domain-name>/UA/<model-short-name>

Where the <authority-domain-name> is a domain name owned by the authority creating the information model. In many cases this will be ‘opcfoundation.org’. <yyyy-MM> is the year and month that the URI was created. The <model-short-name> is a short identifier for the InformationModel.

2) ApplicationUri assigned by the OwnerOperator

tag:<device-domain-name>,<yyyy-MM>:<product>

http://<device-domain-name>/<product>

Where the <device-domain-name> is a domain name or IP address for the Device that is unique within the OwnerOperator system. <yyyy-MM> is the year and month that the URI was created. The <product> is an identifier for the product which could contain many path segments.

3) ApplicationUri automatically generated by product software:

tag:<vendor-domain-name>,<yyyy-MM>:<product>:<guid>

http://<vendor-domain-name>/<product>/<guid>

Where <vendor-domain-name> is a domain name owned by the product vendor. <yyyy-MM> is the year and month that the URI was created. The <product> is an identifier for the product which could contain many path segments and <guid> is unique identifier generated when the product is first initialized on a particular Device.

4) ProductInstanceUri assigned by a Device Manufacturer:

tag:<manufacturer-domain-name>,<yyyy-MM>:<product>:<serial-number>

http://<manufacturer-domain-name>/<product>/<serial-number>

Where <manufacturer-domain-name> is a domain name owned by the Manufacturer. <yyyy-MM> is the year and month that the URI was created. The <product> is an identifier for the product which could contain many path segments and <serial-number> is unique identifier for the Device assigned by the Manufacturer.

The primary objective of the OPC UA AddressSpace is to provide a standard way for Servers to represent Objects to Clients. The OPC UA Object Model has been designed to meet this objective. It defines Objects in terms of Variables and Methods. It also allows relationships to other Objects to be expressed. Figure 2 illustrates the model.

Figure 2 – OPC UA Object Model

The elements of this model are represented in the AddressSpace as Nodes. Each Node is assigned to a NodeClass and each NodeClass represents a different element of the Object Model. Clause 4.10 defines the NodeClasses used to represent this model.

The set of Objects and related information that the OPC UA Server makes available to Clients is referred to as its AddressSpace. The model for Objects is defined by the OPC UA Object Model (see 4.2).

Objects and their components are represented in the AddressSpace as a set of Nodes described by Attributes and interconnected by References. Figure 3 illustrates the model of a Node and the remainder of 4.3 discusses the details of the Node Model.

Figure 3 – AddressSpace Node Model

NodeClasses are defined in terms of the Attributes and References that shall be instantiated (given values) when a Node is defined in the AddressSpace. Attributes are discussed in 4.4.3 and References in 4.4.4.

Clause 5 defines the NodeClasses for the OPC UA AddressSpace. These NodeClasses are referred to collectively as the metadata for the AddressSpace. Each Node in the AddressSpace is an instance of one of these NodeClasses. No other NodeClasses shall be used to define Nodes, and as a result, Clients and Servers are not allowed to define NodeClasses or extend the definitions of these NodeClasses.

Attributes are data elements that describe Nodes. Clients can access Attribute values using Read, Write, Query, and Subscription/MonitoredItem Services. These Services are defined in OPC 10000-4.

Attributes are elementary components of NodeClasses. Attribute definitions are included as part of the NodeClass definitions in Clause 4.10 and, therefore, are not included in the AddressSpace.

Each Attribute definition consists of an attribute id (for attribute ids of Attributes, see OPC 10000-6), a name, a description, a data type and a mandatory/optional indicator. The set of Attributes defined for each NodeClass shall not be extended by Clients or Servers.

When a Node is instantiated in the AddressSpace, the values of the NodeClass Attributes are provided. The mandatory/optional indicator for the Attribute indicates whether the Attribute has to be instantiated.

References are used to relate Nodes to each other. They can be accessed using the browsing and querying Services defined in OPC 10000-4.

Like Attributes, they are defined as fundamental components of Nodes. Unlike Attributes, References are defined as instances of ReferenceType Nodes. ReferenceType Nodes are visible in the AddressSpace and are defined using the ReferenceType NodeClass (see 5.3).

The Node that contains the Reference is referred to as the SourceNode and the Node that is referenced is referred to as the TargetNode. The combination of the SourceNode, the ReferenceType and the TargetNode are used in OPC UA Services to uniquely identify References. Thus, each Node can reference another Node with the same ReferenceType only once. Any subtypes of concrete ReferenceTypes are considered to be equal to the base concrete ReferenceTypes when identifying References (see 5.3 for subtypes of ReferenceTypes). Figure 4 illustrates this model of a Reference.

Figure 4 – Reference Model

The TargetNode of a Reference may be in the same AddressSpace or in the AddressSpace of another OPC UA Server. TargetNodes located in other Servers are identified in OPC UA Services using a combination of the remote Server name and the identifier assigned to the Node by the remote Server.

OPC UA does not require that the TargetNode exists, thus References may point to a Node that does not exist.

Variables are used to represent values. Two types of Variables are defined, Properties and DataVariables. They differ in the kind of data that they represent and whether they can contain other Variables.

Properties are Server-defined characteristics of Objects, DataVariables and other Nodes. Properties differ from Attributes in that they characterise what the Node represents, such as a device or a purchase order. Attributes define additional metadata that is instantiated for all Nodes from a NodeClass. Attributes are common to all Nodes of a NodeClass and only defined by this specification whereas Properties can be Server-defined.

For example, an Attribute defines the DataType of Variables whereas a Property can be used to specify the engineering unit of some Variables.

To prevent recursion, Properties are not allowed to have Properties defined for them. To easily identify Properties, the BrowseName of a Property shall be unique in the context of the Node containing the Properties (see 5.6.3 for details).

A Node and its Properties shall always reside in the same Server.

DataVariables represent the content of an Object. For example, a file Object may be defined that contains a stream of bytes. The stream of bytes may be defined as a DataVariable that is an array of bytes. Properties may be used to expose the creation time and owner of the file Object.

For example, if a DataVariable is defined by a data structure that contains two fields, “startTime” and “endTime” then it might have a Property specific to that data structure, such as “earliestStartTime”.

As another example, function blocks in control systems might be represented as Objects. The parameters of the function block, such as its setpoints, may be represented as DataVariables. The function block Object might also have Properties that describe its execution time and its type.

DataVariables may have additional DataVariables, but only if they are complex. In this case, their DataVariables shall always be elements of their complex definitions. Following the example introduced by the description of Properties in 4.5.2, the Server could expose “startTime” and “endTime” as separate components of the data structure.

As another example, a complex DataVariable may define an aggregate of temperature values generated by three separate temperature transmitters that are also visible in the AddressSpace. In this case, this complex DataVariable could define HasComponent References from it to the individual temperature values that it is composed of.

OPC UA Servers shall provide type definitions for Objects and Variables. The HasTypeDefinition Reference shall be used to link an instance with its type definition represented by a TypeDefinitionNode. Type definitions are required; however, OPC 10000-5 defines a BaseObjectType, a PropertyType, and a BaseDataVariableType so a Server can use such a base type if no more specialised type information is available. Objects and Variables inherit the Attributes specified by their TypeDefinitionNode (see 6.4 for details).

In some cases, the NodeId used by the HasTypeDefinition Reference will be well-known to Clients and Servers. Organizations may define TypeDefinitionNodes that are well-known in the industry. Well-known NodeIds of TypeDefinitionNodes provide for commonality across OPC UA Servers and allow Clients to interpret the TypeDefinitionNode without having to read it from the Server. Therefore, Servers may use well-known NodeIds without representing the corresponding TypeDefinitionNodes in their AddressSpace. However, the TypeDefinitionNodes shall be provided for generic Clients. These TypeDefinitionNodes may exist in another Server.

The following example, illustrated in Figure 5, describes the use of the HasTypeDefinition Reference. In this example, a setpoint parameter “SP” is represented as a DataVariable in the AddressSpace. This DataVariable is part of an Object not shown in the figure.

To provide for a common setpoint definition that can be used by other Objects, a specialised VariableType is used. Each setpoint DataVariable that uses this common definition will have a HasTypeDefinition Reference that identifies the common “SetPoint” VariableType.

Figure 5 – Example of a Variable defined by a VariableType

TypeDefinitionNodes can be complex. A complex TypeDefinitionNode also defines References to other Nodes as part of the type definition. The ModellingRules defined in 6.4.4 specify how those Nodes are handled when creating an instance of the type definition.

A TypeDefinitionNode references instances instead of other TypeDefinitionNodes to allow unique names for several instances of the same type, to define default values and to add References for those instances that are specific to this complex TypeDefinitionNode and not to the TypeDefinitionNode of the instance. For example, in Figure 6 the ObjectType “AI_BLK_TYPE”, representing a function block, has a HasComponent Reference to a Variable “SP” of the VariableType “SetPoint”. “AI_BLK_TYPE” could have an additional setpoint Variable of the same type using a different name. It could add a Property to the Variable that was not defined by its TypeDefinitionNode “SetPoint”. And it could define a default value for “SP”, that is, each instance of “AI_BLK_TYPE” would have a Variable “SP” initially set to this value.

Figure 6 – Example of a Complex TypeDefinition

This approach is commonly used in object-oriented programming languages in which the variables of a class are defined as instances of other classes. When the class is instantiated, each variable is also instantiated, but with the default values (constructor values) defined for the containing class. That is, typically, the constructor for the component class runs first, followed by the constructor for the containing class. The constructor for the containing class may override component values set by the component class.

To distinguish instances used for the type definitions from instances that represent real data, those instances are called InstanceDeclarations. However, this term is used to simplify this specification, if an instance is an InstanceDeclaration or not is only visible in the AddressSpace by following its References. Some instances may be shared and therefore referenced by TypeDefinitionNodes, InstanceDeclarations and instances. This is similar to class variables in object-oriented programming languages.

This standard allows subtyping of type definitions. The subtyping rules are defined in Clause 6. Subtyping of ObjectTypes and VariableTypes allows:

• Clients that only know the supertype to handle an instance of the subtype as if it were an instance of the supertype;
• instances of the supertype to be replaced by instances of the subtype;
• specialised types that inherit common characteristics of the base type.

In other words, subtypes reflect the structure defined by their supertype but may add additional characteristics. For example, a vendor may wish to extend a general “TemperatureSensor” VariableType by adding a Property providing the next maintenance interval. The vendor would do this by creating a new VariableType which is a TargetNode for a HasSubtype reference from the original VariableType and adding the new Property to it.

The instantiation of complex TypeDefinitionNodes depends on the ModellingRules defined in 6.4.4. However, the intention is that instances of a type definition will reflect the structure defined by the TypeDefinitionNode. Figure 7 shows an instance of the TypeDefinitionNode “AI_BLK_TYPE”, where the ModellingRule Mandatory, defined in 6.4.4.4.1, was applied for its containing Variable. Thus, an instance of “AI_BLK_TYPE”, called AI_BLK_1”, has a HasTypeDefinition Reference to “AI_BLK_TYPE”. It also contains a Variable “SP” having the same BrowseName as the Variable “SP” used by the TypeDefinitionNode and thereby reflects the structure defined by the TypeDefinitionNode.

Figure 7 – Object and its Components defined by an ObjectType

A client knowing the ObjectType “AI_BLK_TYPE” can use this knowledge to directly browse to the containing Nodes for each instance of this type. This allows programming against the TypeDefinitionNode. For example, a graphical element may be programmed in the client that handles all instances of “AI_BLK_TYPE” in the same way by showing the value of “SP”.

There are several constraints related to programming against the TypeDefinitionNode. A TypeDefinitionNode or an InstanceDeclaration shall never reference two Nodes having the same BrowseName using forward hierarchical References. Instances based on InstanceDeclarations shall always keep the same BrowseName as the InstanceDeclaration they are derived from. A special Service defined in OPC 10000-4 called TranslateBrowsePathsToNodeIds may be used to identify the instances based on the InstanceDeclarations. Using the simple Browse Service might not be sufficient since the uniqueness of the BrowseName is only required for TypeDefinitionNodes and InstanceDeclarations, not for other instances. Thus, “AI_BLK_1” may have another Variable with the BrowseName “SP”, although this one would not be derived from an InstanceDeclaration of the TypeDefinitionNode.

Instances derived from an InstanceDeclaration shall be of the same TypeDefinitionNode or a subtype of this TypeDefinitionNode.

A TypeDefinitionNode and its InstanceDeclarations shall always reside in the same Server. However, instances may point with their HasTypeDefinition Reference to a TypeDefinitionNode in a different Server.

The Event Model defines a general purpose eventing system that can be used in many diverse vertical markets.

Events represent specific transient occurrences. System configuration changes and system errors are examples of Events. Event Notifications report the occurrence of an Event. Events defined in this document are not directly visible in the OPC UA AddressSpace. Objects and Views can be used to subscribe to Events. The EventNotifier Attribute of those Nodes identifies if the Node allows subscribing to Events. Clients subscribe to such Nodes to receive Notifications of Event occurrences.

Event Subscriptions use the Monitoring and Subscription Services defined in OPC 10000-4 to subscribe to the Event Notifications of a Node.

Any OPC UA Server that supports eventing shall expose at least one Node as EventNotifier. The Server Object defined in OPC 10000-5 is used for this purpose. Events generated by the Server are available via this Server Object. A Server is not expected to produce Events if the connection to the event source is down for some reason (i.e. the system is offline).

Events may also be exposed through other Nodes anywhere in the AddressSpace. These Nodes (identified via the EventNotifier Attribute) provide some subset of the Events generated by the Server. The position in the AddressSpace dictates what this subset will be. For example, a process area Object representing a functional area of the process would provide Events originating from that area of the process only. It should be noted that this is only an example and it is fully up to the Server to determine what Events should be provided by which Node.

Each Event is of a specific EventType. A Server may support many types. This part defines the BaseEventType that all other EventTypes derive from. It is expected that other companion specifications will define additional EventTypes deriving from the base types defined in this part.

The EventTypes supported by a Server are exposed in the AddressSpace of a Server. EventTypes are represented as ObjectTypes in the AddressSpace and do not have a special NodeClass associated to them. OPC 10000-5 defines how a Server exposes the EventTypes in detail.

EventTypes defined in this document are specified as abstract and therefore never instantiated in the AddressSpace. Event occurrences of those EventTypes are only exposed via a Subscription. Components of an EventType defined with ModellingRules other than Mandatory or Optional cannot be returned in an Event Subscription. EventTypes exist in the AddressSpace to allow Clients to discover the EventType. This information is used by a client when establishing and working with Event Subscriptions. EventTypes defined by other parts of this series of standards or companion specifications as well as Server specific EventTypes may be defined as not abstract and therefore instances of those EventTypes may be visible in the AddressSpace although Events of those EventTypes are also accessible via the Event Notification mechanisms.

Standard EventTypes are described in Clause 8.61. Their representation in the AddressSpace is specified in OPC 10000-5.

Events can be categorised by creating new EventTypes which are subtypes of existing EventTypes but do not extend an existing type. They are used only to identify an event as being of the new EventType. For example, the EventType DeviceFailureEventType could be subtyped into TransmitterFailureEventType and ComputerFailureEventType. These new subtypes would not add new Properties or change the semantic inherited from the DeviceFailureEventType other than purely for categorization of the Events.

Event sources can also be organised into groups by using the Event ReferenceTypes described in 7.16 and 7.18. For example, a Server may define Objects in the AddressSpace representing Events related to physical devices, or Event areas of a plant or functionality contained in the Server. Event References would be used to indicate which Event sources represent physical devices and which ones represent some Server-based functionality. In addition, References can be used to group the physical devices or Server-based functionality into hierarchical Event areas. In some cases, an Event source may be categorised as being both a device and a Server function. In this case, two relationships would be established. Refer to the description of the Event ReferenceTypes for additional examples.

Clients can select a category or categories of Events by defining content filters that include terms specifying the EventType of the Event or a grouping of Event sources. The two mechanisms allow for a single Event to be categorised in multiple manners. A client could obtain all Events related to a physical device or all failures of a particular device.

Methods are “lightweight” functions, whose scope is bounded by an owning (see Note) Object, similar to the methods of a class in object-oriented programming or an owning ObjectType, similar to static methods of a class. Methods are invoked by a client, proceed to completion on the Server and return the result to the client. The lifetime of the Method’s invocation instance begins when the client calls the Method and ends when the result is returned.

NOTE The owning Object or ObjectType is specified in the service call when invoking the Method.

While Methods may affect the state of the owning Object, they have no explicit state of their own. In this sense, they are stateless. Methods can have a varying number of input arguments and return resultant arguments. Each Method is described by a Node of the Method NodeClass. This Node contains the metadata that identifies the Method’s arguments and describes its behaviour.

Methods are invoked by using the Call Service defined in OPC 10000-4.

Clients discover the Methods supported by a Server by browsing for the owning Objects References that identify their supported Methods.

A Role is a function assumed by a Client when it accesses a Server. Roles are used to separate authentication (determining who a Client is) from authorization (determining what the Client is allowed to do). By separating these tasks Servers can allow centralized services to manage user identities and credentials while the Server only manages the Permissions on its Nodes assigned to Roles.

The set of Roles supported by a Server are published as components of the RoleSet Object defined in OPC 10000-18. Servers should define a base set of Roles and allow configuration Clients to add system specific Roles. Adding, deleting, and modifying Roles is restricted to callers with appropriate permissions.

When a Session is created, or a Session-less Service is called, the Server must determine what Roles are granted to that Session or Session-less Service invocation. This specification defines standard mapping rules which Servers may support. Servers may also use vendor specific mapping rules in addition to or instead of the standard rules.

The Anonymous Role is the default Role which is always assigned to all Sessions.

The AuthenticatedUser Role is always assigned when a Session has been authenticated with a UserIdentityToken other than the AnonymousIdentityToken (see OPC 10000-4).

The TrustedApplication Role is always assigned when a Session has been authenticated with a trusted ApplicationInstance Certificate (see OPC 10000-4) and uses at least a signed communication channel.

The standard mapping rules allow Roles to be granted based on:

• User identity;
• Application identity;
• Endpoint;

User identity mappings can be based on user names, user certificates or user groups.

Application identity mappings are based on the ApplicationUri specified in the Client Certificate. Application identity can only be enforced if the Client proves possession of a trusted Certificate by using it to create a Secure Channel or by providing a signature in ActivateSession (see OPC 10000-4).

Endpoint identity mappings are based on the URL used to connect to the Server. Endpoint identity can be used to restrict access to Clients running on particular networks. Endpoint identity mappings should not be used as the only criteria unless access to the endpoint is restricted by the network infrastructure. For example, an endpoint on a loopback address is only accessible from the same machine.

OPC 10000-5 defines the Objects, Methods and DataTypes used to represent and manage these mapping rules in the Address Space.

The NodeIds for the well-known Roles are defined in OPC 10000-6. All Servers should support the well-known Roles which are defined in Table 2.

Table 2 – Well-Known Roles

BrowseName	Suggested Permissions
Anonymous	The Role is allowed to browse and read non-security related Nodes only in the Server Object and all type Nodes.
AuthenticatedUser	The Role is allowed to browse and read non-security related Nodes.
TrustedApplication	The Role is allowed to browse and read non-security related Nodes.
Observer	The Role is allowed to browse, read live data, read historical data/events or subscribe to data/events.
Operator	The Role is allowed to browse, read live data, read historical data/events or subscribe to data/events. In addition, the Session is allowed to write some live data and call some Methods.
Engineer	The Role is allowed to browse, read/write configuration data, read historical data/events, call Methods or subscribe to data/events.
Supervisor	The Role is allowed to browse, read live data, read historical data/events, call Methods or subscribe to data/events.
ConfigureAdmin	The Role is allowed to change the non-security related configuration settings.
SecurityAdmin	The Role is allowed to change security related settings.

When a Client attempts to access a Node, the Server goes through the list of Roles granted to the Session and logically ORs the Permissions for the Role on the Node. If there are no Node specific Permissions then the default Permissions for the Role in the DefaultRolePermissions Property of the NamespaceMetadata for the namespace the Node belongs to are used (see OPC 10000-5). The resulting mask is the effective Permissions. If the bits corresponding to current operation are set, then the operation can proceed. If they are not set the Server returns Bad_UserAccessDenied.

Roles appear under the Roles Object in the Server Address Space. Each Role has mapping rules defined which appear as Properties of the Role Object (see OPC 10000-5). The examples shown in Table 3 illustrate how the standard mapping rules can be used to determine which Roles a Session has access to and, consequently, the Permissions that are granted to the Session.

Table 3 – Example Roles

Role	Mapping Rules	Description
Anonymous	Identities = Anonymous Applications = Endpoints =	An identity mapping rule that specifies the Role applies to anonymous users.
AuthenticatedUser	Identities = AuthenticatedUser Applications = Endpoints =	An identity mapping rule that specifies the Role applies to authenticated users.
Operator1	Identities = User with name ‘Joe’ Applications = urn:OperatorStation1 Endpoints =	An identity mapping rule that specifies specific users that have access to the Role with a application rule that restricts access to a single Client application.
Operator2	Identities = Users with name ‘Joe’ or ‘Ann’ Applications = urn:OperatorStation2 Endpoints =	An identity mapping rule that specifies specific users that have access to the Role with a application rule that restricts access to a single Client application.
Supervisor	Identities = User with name ‘Root’ Applications = Endpoints =	An identity mapping rule that specifies specific users that have access to the Role
Administrator	Identities = User with name ‘Root’ Applications = Endpoints = opc.tcp://127.0.0.1:48000	An identity mapping rule that specifies specific users that have access to the Role when they connect via a specific Endpoint.

The examples also make use of the Nodes defined in Table 4. The table specifies the value of the RolePermissions Attribute for each Node.

Table 4 – Example Nodes

Node	Role Permissions
Unit1.Measurement	AuthenticatedUser = Browse Operator1 = Browse, Read
Unit2.Measurement	AuthenticatedUser = Browse Operator2 = Browse, Read
SetPoint	AuthenticatedUser = Browse Operator1 and Operator2 = Browse, Read, Write Supervisor = Browse, Read
DisableDevice	AuthenticatedUser = Browse Operator1 and Operator2 = Browse, Read Administrator = Browse, Read, Write

When a Client creates a Session the Roles assigned to the Session depend on the rules defined for each Role. Table 5 lists the assigned Roles for different Sessions created with different Users, Client applications and Endpoints.

Table 5 – Example Role Assignment

User Provided by Client	Roles Assigned to Session
Anonymous	Anonymous
Sam	AuthenticatedUser
Joe using OperatorStation1 application.	AuthenticatedUser, Operator1
Joe using OperatorStation2 application.	AuthenticatedUser, Operator2
Joe using generic application.	AuthenticatedUser
Root using OperatorStation1 application.	AuthenticatedUser, Supervisor
Root using generic application and 127.0.0.1 endpoint.	AuthenticatedUser, Supervisor, Administrator
Root using generic application and another endpoint.	AuthenticatedUser, Supervisor

When a Client application accesses a Node the RolePermissions for the Node are compared to the Roles assigned to the Session. Any Permissions available to at least one Role is granted to the Client. Table 6 provides a number of scenarios and examples and the resulting decision on access.

Table 6 – Examples of Evaluating Access

Use Case	Role Permissions
Anonymous user on localhost browses Unit1.Measurement Node.	Access denied because no rule defined for Anonymous users.
User ‘Sam’ using OperatorStation1 application browses Unit1.Measurement Node.	Allowed because AuthenticatedUser is granted Browse Permission.
User ‘Sam’ using OperatorStation2 application reads Value of Unit1.Measurement Node.	Access denied because AuthenticatedUser is not granted Read Permission.
User ‘Joe’ using OperatorStation1 application reads Value of Unit1.Measurement Node.	Allowed because Operator1 is granted Read Permission.
User ‘Joe’ using OperatorStation2 application reads Value of Unit1.Measurement Node.	Access denied because AuthenticatedUser and Operator2 are not granted Read Permission.
User ‘Joe’ using generic OPC UA application reads Value of Measurement Node.	Access denied because AuthenticatedUser is not granted Read Permission.
User ‘Joe’ using OperatorStation1 application write Value of SetPoint Node.	Allowed because Operator1 is granted Write Permission.
User ‘Root’ using OperatorStation1 application write the Value of SetPoint Node.	Denied because AuthenticatedUser and Supervisor are not granted Write Permission.
User ‘Joe’ using OperatorStation1 application write Value of DisableDevice Node.	Access denied because AuthenticatedUser and Operator1 are not granted Write Permission.
User ‘Root’ using OperatorStation1 application write the Value of DisableDevice Node.	Access denied because AuthenticatedUser and Supervisor are not granted Write Permission.
User ‘Root’ using endpoint 127.0.0.1 to write Value of DisableDevice Node.	Allowed because Administrator is granted Write Permission.

OPC UA defines a type model supporting one object-oriented type hierarchy for ObjectTypes. Although the specification does not restrict those hierarchies to be single inheritance (i.e. a type can only have one super-type) it only specifies the semantic (inheritance rules) for single inheritance.

In general, good object-oriented design is accomplished by using composition to aggregate an object which provides several functions instead of over-using inheritance [GH95], [FF04] .

Interfaces and AddIns complement the type model and can be used when subtyping is not suitable for the required extension. They:

• allow enhancing multiple types at arbitrary positions in the type hierarchy.
• also allow enhancing just instances.

Interfaces are ObjectTypes that represent a generic feature (functionality), assumed to be usable by different ObjectTypes or Objects. The Interface model specifies the rules and mechanisms to achieve this.

The “InterfaceTypes” Object (see OPC 10000-5) has been defined so that all Interfaces of the Server are either directly or indirectly accessible browsing HierarchicalReferences starting from this Node.

Rules for the definition of Interfaces:

• Interface ObjectTypes shall be abstract subtypes of the BaseInterfaceType ObjectType.
• InstanceDeclarations on an Interface shall only have ModellingRules Optional or Mandatory.
• Interfaces can be subtyped as specified in clause 6.3.
• Interfaces shall not be the source of HasInterface References.
• Recommended convention: The first letter of an Interface should be ‘I’. See examples below.

Rules for applying Interfaces:

• When an ObjectType references an Interface with a HasInterface Reference or a subtype, the following rules apply:
• Each mandatory InstanceDeclaration of the fully-inherited InstanceDeclarationHierarchy of the Interface shall have for each BrowsePath a similar Node (see 6.2.4) with the ModellingRule Mandatory using the same BrowsePath in the fully-inherited InstanceDeclarationHierarchy of the ObjectType. The rules for instantiating InstanceDeclarations defined in 6.2.6 shall be applied.
• Each optional InstanceDeclaration of the fully-inherited InstanceDeclarationHierarchy of the Interface should have for each BrowsePath a similar Node (see 6.2.4) with the ModellingRule Mandatory or Optional using the same BrowsePath in the fully-inherited InstanceDeclarationHierarchy of the ObjectType. The rules for instantiating InstanceDeclarations defined in 6.2.6 shall be applied. If no similar Node with the same BrowsePath exists, the ObjectType and its sub-types shall not use the same BrowsePath for a different Node (e.g. with a different NodeClass).

If the rules cannot be fulfilled (e.g. name collisions) the ObjectType cannot apply the Interface, i.e. it shall not reference the Interface with a HasInterface Reference of a subtype.

The rules apply for each referenced Interface. As a consequence, an ObjectType cannot reference two Interfaces using the same BrowsePath for Nodes that are not similar Nodes or have TypeDefinitionNodes that are not compatible (compatible means they have either the same TypeDefinitionNode or one TypeDefinitionNode is the subtype of the other TypeDefinitionNode).

• Subtypes should not have a HasInterface Reference to an Interface if it was already applied to a super-type.
• When an Object references an Interface with a HasInterface Reference or a subtype, the following rules apply:
• The Interface shall not be applied on the Object when the Interface cannot be applied on the TypeDefinitionNode of the Object.
• The same rules on the Object apply as if the Interface would have been applied on the TypeDefinitionNode of the Object (e.g. all Mandatory InstanceDeclarations need to be applied).
• The Nodes defined based on the Interface shall be handled as if they were defined by the TypeDefinitionNode. For example, the TranslateBrowsePathsToNodeIds Service shall return them first.
• If several Interfaces should be applied to the Object, they should be treated as if they were all applied to the ObjectType of the Object at the same time. If this is not possible, the Interfaces cannot be applied to the Object together.
• Instances should not have a HasInterface Reference to an Interface if it was already applied to the TypeDefinitionNode.
• A BaseInterfaceType or any subtype of BaseInterfaceType shall not be the TargetNode of a HasTypeDefinition Reference.

Figure 8 illustrates example Interfaces:

• ISerializeServiceType, an Interface to convert the Object and its components into a stream of bytes.
• ITransactionServiceType, an Interface to perform a sequence of changes to the Object as a single operation.
• ILocationType, an Interface to specify the installation location of the Object.

Figure 8 – Examples of Interfaces

The following examples illustrate the application of these Interfaces. In Figure 9 the example Interface ILocationType is applied to the XYZ-DeviceType ObjectType. It also illustrates the overriding of Property “Address” by changing the ModellingRule from Optional to Mandatory. Figure 10 in addition shows how to use the ISerializeService Interface on the instance only. Figure 11 shows an Interface hierarchy where InstanceDeclarations of the referenced Interface and its parent type(s) are applied (the fully-inherited InstanceDeclarationHierarchy).

Figure 9 – Example: Interface application to an ObjectType

Figure 10 – Example: One Interface applied to an ObjectType another one to the instance

Figure 11 – Example: Interface Hierarchy

Clients can detect the implementation of Interfaces by filtering for the HasInterface Reference into the Browse Service request.

On instances, the Browse Service will return elements derived from an Interface together with elements of the Node’s base type. Clients can also use the TranslateBrowsePathsToNodeId Service with BrowseNames of Interface members to get the NodeId of these members directly.

In the example in Figure 10 “Address” with the starting node MD002 can be used to request the NodeId of this Property.

On Object instances, some Nodes of an Interface may not be available if defined with ModellingRule Optional.

AddIns associate a feature or feature-set, represented by an ObjectType to the Node (an Object or ObjectType) they are applied to. The Interface model is different than the AddIn model in that it is based on composition. An AddIn is applied to a Node by adding a Reference to the AddIn instance.

There are no restrictions for AddIn ObjectTypes and there is no special supertype for AddIns. To identify instances as an AddIn, the HasAddIn Reference or a subtype shall be used.

The AddIn ObjectType shall include the definition of a default BrowseName using the DefaultInstanceBrowseName Property. Instances of such an AddIn should use this default BrowseName. If an AddIn is instantiated multiple times in the same parent, only one instance can have the default BrowseName.

The definition of an AddIn and its use with a default BrowseName is illustrated in Figure 12.

Figure 12 – Example of AddIn with default BrowseName

As already described, an AddIn can be applied on types and instances. The use on an instance is shown in Figure 13.

Figure 13 – Example of AddIn applied to an instance

Clients can detect the implementation of AddIns by passing the HasAddIn Reference as filter to the Browse Service request. If an AddIn has a default BrowseName, Clients can use the TranslateBrowsePathsToNodeId Service with the default BrowseName to get the NodeId of an AddIn.

In the example in Figure 12 the relative path “MyFeature/MyPropertyM” with the starting node MD002 can be used to request the NodeId of this Property and the relative path “MyFeature/MyMethodO” can be used for the respective Method.