The OPC UA Meta Model (the OPC UA Address Space Model) is represented by UML classes and UML objects marked with the stereotype <<TypeExtension>>. Those stereotyped UML objects represent DataTypes or ReferenceTypes. The domain model can contain user-defined ReferenceTypes and DataTypes, also marked as <<TypeExtension>>. In addition, the domain model contains ObjectTypes, VariableTypes etc. represented as UML objects (see Figure B.1).

The OPC Foundation specifies not only the OPC UA Meta Model, but also defines some Nodes to organise the AddressSpace and to provide information about the Server as specified in OPC 10000-5.

Figure B.1 – Background of OPC UA Meta Model

An example of a UML class representing the OPC UA concept Base is given in the UML class diagram in Figure B.2. OPC Attributes inherit from the abstract class Attribute and have a value identifying their data type. They are composed of a Node which is either optional (0..1) or required (1), such as BrowseName to Base in Figure B.2.

Figure B.2 – Notation (I)

UML object diagrams are used to display <<TypeExtension>> objects (e.g. HasComponent in Figure B.3). In object diagrams, OPC Attributes are represented as UML attributes without data types and marked with the stereotype <<Attribute>>, like InverseName in the UML object HasComponent. They have values, like InverseName =ComponentOf for HasComponent. To keep the object diagrams simple, not all Attributes are shown (e.g. the NodeId of HasComponent).

Figure B.3 – Notation (II)

OPC References are represented as UML associations marked with the stereotype <<Reference>>. If a particular ReferenceType is used, its name is used as the role name, identifying the direction of the Reference (e.g. Aggregates has the subtype HasComponent). For simplicity, the inverse role name is not shown (in the example SubtypeOf). When no role name is provided, it means that any ReferenceType can be used (only valid for class diagrams).

There are some special Attributes in OPC UA containing a NodeId and thereby referencing another Node. Those Attributes are represented as associations marked with the stereotype <<Attribute>>. The name of the Attribute is displayed as the role name of the TargetNode.

The value of the OPC Attribute BrowseName is represented by the UML object name, for example the BrowseName of the UML object HasComponent in Figure B.3 is “HasComponent”.

To highlight the classes explained in a class diagram, they are marked in grey (e.g. Base in Figure B.2). Only those classes have all of their relationships to other classes and attributes shown in the diagram. For the other classes, we provide only those attributes and relationships needed to understand the main classes of the diagram.

NOTE: Other parts of this series of standards can extend the OPC UA Meta Model by adding Attributes and defining new ReferenceTypes.

Base is shown in Figure B.4.

Figure B.4 – Base

ReferenceType is shown in Figure B.5 and predefined ReferenceTypes in Figure B.6.

Figure B.5 – Reference and ReferenceType

If Symmetric is “false” an InverseName shall be provided.

Figure B.6 – Predefined ReferenceTypes

Attributes are shown in Figure B.7.

Figure B.7 – Attributes

There may be more Attributes defined in other parts of this series of standards.

Attributes used for references, which have a NodeId as DataType, are not shown in this diagram but are shown as stereotyped associations in the other diagrams.

Objects and ObjectTypes are shown in Figure B.8.

Figure B.8 – Object and ObjectType

EventNotifier are shown in Figure B.9.

Figure B.9 – EventNotifier

Variable and VariableType are shown in Figure B.10.

Figure B.10 – Variable and VariableType

The DataType of a Variable shall be the same as or a subtype of the DataType of its VariableType (referred with HasTypeDefinition).

If a HasProperty points to a Variable from a Base “A” then the following constraints apply:

• The Variable shall not be the SourceNode of a HasProperty or any other HierarchicalReferences Reference.
• All Variables having “A” as the SourceNode of a HasProperty Reference shall have a unique BrowseName in the context of “A”.

Method is shown in Figure B.11

Figure B.11 – Method

DataType is shown in Figure B.12.

Figure B.12 – DataType

View is shown in Figure B.13.

Figure B.13 – View