The notation is divided into two parts. The simple notation only provides a simplified view on the data hiding some details like Attributes. The extended notation allows exposing all structure information of OPC UA, including Attributevalues. The simple and the extended notation can be combined to expose OPC UA data in one figure.

Common to both notations is that neither any colour nor the thickness or style of lines is relevant for the notation. Those effects can be used to highlight certain aspects of a figure.

Depending on their NodeClass Nodesare represented by different graphical forms as defined in Table C.1.

Table C.1– Notation of Nodes depending on the NodeClass

NodeClass

Graphical Representation

Comment

Object

image048.png

Rectangle including text representing the string-part of the DisplayNameof the Object. The font shall not be set to italic.

ObjectType

image049.png

Shadowedrectangle including text representing the string-part of the DisplayName of the ObjectType. The font shall be set in italic.

Variable

image050.png

Rectangle with rounded corners including text representing the string-part of the DisplayNameof the Variable. The font shall not be set in italic.

VariableType

image051.png

Shadowed rectangle with rounded corners including text representing the string-part of the DisplayNameof the VariableType. The font shall be set in italic.

DataType

image052.png

Shadowed hexagon including text representing the string-part of the DisplayNameof the DataType.

ReferenceType

image053.png

Shadowed six-sided polygon including text representing the string-part of the DisplayNameof the ReferenceType.

Method

image054.png

Oval including text representing the string-part of the DisplayNameof the Method.

View

image055.png

Trapezium including text representing the string-part of the DisplayNameof the View.

Referencesare represented as lines between Nodesas exemplified in Figure C.1. Those lines can vary in their form. They do not have to connect the Nodeswith a straight line; they can have angles, arches, etc.

image056.png

Figure C.1 – Example of a Reference connecting two Nodes

Table C.2defines how symmetric and asymmetric Referencesare represented in general, and also defines shortcuts for some ReferenceTypes. Although it is recommended to use those shortcuts, it is not required. Thus, instead of using the shortcut, the generic solution can also be used.

Table C.2– Simple Notation of Nodes depending on the NodeClass

ReferenceType

Graphical Representation

Comment

Any symmetric ReferenceType

image057.png

Symmetric ReferenceTypesare represented as lines between Nodeswith closed and filled arrows on both sides pointing to the connected Nodes. Near the line has to be a text containing the string-part of the BrowseNameof the ReferenceType.

Any asymmetric ReferenceType

image058.png

Asymmetric ReferenceTypesare represented as lines between Nodeswith a closed and filled arrow on the side pointing to the TargetNode. Near the line has to be a text containing the string-part of the BrowseNameof the ReferenceType.

Any hierarchical ReferenceType

image059.png

Asymmetric ReferenceTypesthat are subtypes of HierarchicalReferencesshould be exposed the same way as asymmetric ReferenceTypesexcept that an open arrow is used.

HasComponent

image060.png

The notation provides a shortcut for HasComponent Referencesshown on the left. The single hashed line has to be near the TargetNode.

HasProperty

image061.png

The notation provides a shortcut for HasProperty Referencesshown on the left. The double hashed lines have to be near the TargetNode.

HasTypeDefinition

image062.png

The notation provides a shortcut for HasTypeDefinition Referencesshown on the left. The double closed and filled arrows have to point to the TargetNode.

HasSubtype

image063.png

The notation provides a shortcut for HasSubtype Referencesshown on the left. The double closed arrows have to point to the SourceNode.

HasEventSource

image064.png

The notation provides a shortcut for HasEventSource Referencesshown on the left. The closed arrow has to point to the TargetNode.

In the extended notation some additional concepts are introduced. It is allowed only to use some of those concepts on elements of a figure.

The following rules define some special handling of structures.

  • In general, values of all DataTypesshould be represented by an appropriate string representation. Whenever a NamespaceIndexor LocaleIdis used in those structures they can be omitted.
  • The DisplayNamecontains a LocaleIdand a String. Such a structure can be exposed as [<LocaleId>:]<String> where the LocaleIdis optional. For example, a DisplayNamecan be “en:MyName”. Instead of that, “MyName” can also be used. This rule applies whenever a DisplayNameis shown, including the text used in the graphical representation of a Node.
  • The BrowseNamecontains the NamespaceIndexand a String. Such a structure can be exposed as [<NamespaceIndex>:]<String> where the NamespaceIndexis optional. For example, a BrowseNamecan be “1:MyName”. Instead of that, “MyName” can also be used. This rule applies whenever a BrowseNameis shown, including the text used in the graphical representation of a Node.

Instead of using the HasTypeDefinitionreference to point from an Objector Variableto its ObjectTypeor VariableTypethe name of the TypeDefinitioncan be added to the text used in the Node. The TypeDefinitionshall either be prefixed with “::” or it is put in italic as the top line. Figure C.2gives an example, where “Node1” uses a Referenceand “Node2” the shortcut in both notation variants. A figure can contain HasTypeDefinition Referencesfor some Nodesand the shortcut for other Nodes. It is not allowed that a Nodeuses the shortcut and additionally is the SourceNodeof a HasTypeDefinition.

image065.png

Figure C.2– Example of using a TypeDefinition inside a Node

To display Attributesof a Nodeadditional text can be put inside the form representing the Nodeunder the text representing the DisplayName. The DisplayNameand the text describing the Attributeshave to be separated using a horizontal line. Each Attributehas to be set into a new text line. Each text line shall contain the Attributename followed by an “=” and the value of the Attribute. On top of the first text line containing an Attributeshall be a text line containing the underlined text “Attribute”. It is not required to expose all Attributesof a Node. It is allowed to show only a subset of Attributes. If an optional Attributeis not provided, the Attributecan be marked by a strike-through line, for example “Description”. Examples of exposing Attributesare shown in Figure C.3.

image066.png

Figure C.3– Example of exposing Attributes

To avoid too many Nodesin a figure it is allowed to expose Propertiesinside a Node, similar to Attributes. Therefore, the text field used for exposing Attributesis extended. Under the last text line containing an Attributea new text line containing the underlined text “Property” has to be added. If no Attributeis provided, the text has to start with this text line. After this text line, each new text line shall contain a Property, starting with the BrowseNameof the Propertyfollowed by “=” and the value of the Value Attributeof the Property. Figure C.4shows some examples exposing Propertiesinline. It is allowed to expose some Propertiesof a Nodeinline, and other Propertiesas Nodes. It is not allowed to show a Propertyinline as well as an additional Node.

image067.png

Figure C.4– Example of exposing Properties inline

It is allowed to add additional information to a figure using the graphical representation, for example callouts.

______________