OPC UA Servers and the underlying systems that they expose can be conveniently configured using AutomationML (AML) through the use of standardized AML libraries built to mirror the OPC UA modelling concepts defined in OPC 10000-3 and OPC 10000-5. Table A.1 shows the OPC UA modelling concept and the AML modelling concept used to realize the OPC UA counterpart in the AML libraries.

Table A.1 – Mapping OPC UA modelling concepts to AML

UA Modelling Concept	AML Modelling Concept
DataType	AttributeType
ObjectType	SystemUnitClass
VariableType	SystemUnitClass
Method	SystemUnitClass
InterfaceType	RoleClass plus SystemUnitClass
ReferenceType	InterfaceClass(es)

These mappings are general rules and are not always explicitly followed due to mismatches in the capabilities of OPC UA vs. AML. For instance, ReferenceTypes in OPC UA can be used to connect any two nodes in the UA AddressSpace, but AML InterfaceClasses can only be used within nodes of the InstanceHierarchy or between nodes in a single SystemUnitClass. These mismatches lead to occasional exceptions to these rules and shall be explicitly denoted whenever they occur.

OPC UA Objects, Variables and Methods used in instance declarations are mapped to AML InternalElements in the respective SystemUnitClass.

To provide a clean mapping between AML and OPC model concepts, it is convenient to introduce OpcAmlMetaModel AML libraries to imply semantics that do not correspond to a Node in some UA Namespace and hence do not belong in the other generated AML libraries that are each based on a single UA Namespace.

The AML best practice is for all SystemUnitClasses to implement at least one Role. The RCL_OpcAmlMetaModel library contains one RoleClass UaBaseRole that all OPC UA-derived SUCs shall implement. The UaBaseRole derives from the standard AutomationMLBaseRoleClassLib/AutomationMLBaseRole.

The ATL_OpcAmlMetaModel library contains attributes that represent enumerations that come from the OPC UA metamodel and hence have no corresponding Node in the UA Namespace. The following enumeration-based attributes are provided:

• AttributeId,
• BuiltInType,
• ModellingRuleType.

Additionally, the ATL_OpcAmlMetaModel library contains the following AttributeTypes used to compose the specialized mapping of NodeId described in A.3.7:

NamespaceUri – An AttributeType with a data type of xs:anyURI to hold a NamespaceUri of a NodeId.

ExplicitNodeId – The primitive form of an absolute NodeId with the attributes shown in Figure A.1.

Figure A.1 – ExplicitNodeId AttributeType definition

When an instance of ExplicitNodeId is used, only one of the four “Id” fields shall have a value, and the remaining three shall be deleted.

Alias – Represents an OPC UA Alias with the attributes shown in Figure A.2.

Figure A.2 – Alias AttributeType definition

The ReferenceTypeFilter attribute is optional, and when omitted, the ReferenceType “AliasFor” shall be assumed. See the FindAlias Method in OPC 10000-17.

Methods in OPC UA do not have a base class that they all derive from; they just all conform to the Method NodeClass. In AML, it is desirable to have a base SUC UaMethodNodeClass that represents the AML base SUC from which all UA Methods are instantiated. Since there is no Node that represents the Method NodeClass in a UA Namespace (because it is built-in to the UA meta-model), the SUC UaMethodNodeClass is defined in this metamodel library.

For every OPC UA Namespace, an AML Attribute Type Library exists that defines a corresponding AML AttributeType for each OPC UA DataType. The name of the AML AttributeType Library is composed of the string “ATL_” followed by the OPC UA Namespace name. The name of each AML AttributeType shall match the string portion of OPC UA DataType BrowseName.

Table A.2 shows the mapping of the simple built-in DataTypes in OPC UA that correspond to simple XML schema types used in AML. Each of the built-in UA DataTypes is defined as an AML AttributeType in the AttributeType Library for the base OPC UA Namespace.

Table A.2 – Mapping simple built-in Datatypes

UA DataType	XML Schema type used in AML
Boolean	xs:boolean
SByte	xs:byte
Byte	xs:unsignedByte
Int16	xs:short
UInt16	xs:unsignedShort
Int32	xs:int
UInt32	xs:unsignedInt
Int64	xs:long
UInt64	xs:unsignedLong
Float	xs:float
Double	xs:double
String	xs:string
DateTime	xs:dateTime
ByteString	xs:base64Binary

OPC UA Structures are defined as AML AttributeTypes. Structures in OPC UA can be derived from other Structures and be composed of any other OPC UA DataTypes. Similarly, AML AttributeTypes can be derived from other AML AttributeTypes and be composed of any other AttributeTypes. This allows all OPC UA DataTypes (including Structures) to appear as AML AttributeTypes with the same derivation and composition structure as seen in OPC UA.

Arrays are most naturally represented as lists in XML, so in AML, array DataTypes are represented as XML lists. The AML AttributeType Library of an OPC UA Namespace defines a number of lists for arrays of UA DataTypes, of which a subset is shown in Figure A.3. The same pattern shall be used to construct arrays of any derived DataTypes.

Figure A.3 – Some of the “ListOf” AttributeTypes representing UA array DataTypes

The “ListOf” attributes are all derived from the OrderedListType attributes in the standard AutomationMLBaseAttributeTypeLib.

Enumerations in OPC UA shall be represented as xs:string types in AML with a constraint to limit the values to those defined by the Enumeration. Figure A.4 shows the enumeration for the OPC UA DataType “ApplicationType” in AML.

Figure A.4 – Example OPC Enumeration mapping

OptionSets and bit masks in OPC UA are integer types where each bit is an independent named field that has a Boolean value. In AutomationML, this is mapped to an AttributeType with a set of contained attributes of type xs:Boolean, where the name of each contained attribute matches the field name in the bit mask or option set. Figure A.5 shows an example of OptionSets mapping.

Figure A.5 – Example of OptionSets mapping

The following complex DataTypes have special mappings that are non-intuitive.

QualifiedName – The integer NamespaceIndex used in OPC UA is replaced by a NamespaceURI (xs:anyURI) in AutomationML. In AutomationML, the full URI is always used, never an index.

LocalizedText – An xs:string AttributeType with contained attributes that derive from AutomationMLBaseAttributeTypeLib/LocalizedAttribute and follows the standard AutomationML rules.

NodeId – NodeIds in running OPC UA Servers are represented as an ID and a NamespaceIndex. In order to make reference to Nodes in the offline AutomationML file, a more flexible way to reference a Node is needed, both directly and indirectly, possibly long before the real Node is present in a running Server. The NodeId AML AttributeType is defined with four top-level attributes, as shown in Figure A.6

Figure A.6 – NodeId AttributeType definition

ServerInstanceUri – an optional attribute used to indicate the ServerInstanceUri of the Server containing the NodeId. If empty or missing, the context should be assumed to be the “local” Server. The type is xs:anyURI.

Alias – An indirect reference to a NodeId to be resolved by an alias Server at runtime. The Alias attribute type is defined in A.2.3.

RootNodeId – An ExplicitNodeId from which to traverse the BrowsePath. The ExplicitNodeId attribute type is defined in A.2.3.

BrowsePath – An optional RelativePath to follow from either the RootNodeId or the NodeId resolved from the Alias. See the definition of the RelativePath structure in OPC 10000-4.

Only the Alias attribute or the RootNodeId attribute should be present. If both are present, the Alias attribute shall be ignored.

ExpandedNodeId – ExpandedNodeId has the same definition as NodeId since NodeId can already express an ExpandedNodeId as well.

RelativePathElement – This attribute type is created using the standard mapping rules, except the ReferenceTypeId attribute is of type ExpicitNodeId defined in A.2.3, rather than NodeId. Table A.3 indicates the default value to use if the indicated attribute is missing.

Table A.3 – Default Values for RelativePathElement

attribute	Default value used if attribute is missing
ReferenceTypeId	nsu=http://opcfoundation.org/UA/;i=22 (i.e. HierarchicalReferences)
IsInverse	FALSE
IncludeSubtypes	TRUE

Guid – An xs:string AttributeType where the string shall be formatted in the standard notation for UUIDs per ISO/IEC 9834-8.

Byte – Where the UA DataType Byte is used in builtInType fields, the AML AttributeType is changed to derive from ATL_OpcAmlMetaModel/BuiltInType with constraints to match the enumeration as shown in Figure A.7.

Figure A.7 – BuiltInType enumeration

IntegerId – Where the UA DataType IntegerId is used in fields named “AttributeId”, the AML AttributeType is changed to derive from ATL_OpcAmlMetaModel/AttributeId with constraints to match the enumeration as shown in Figure A.8.

Figure A.8 – AttributeId enumeration

The OPC UA metamodel uses the concept of NodeClasses to define sets of primitive attributes that are present on different types of nodes in the UA address space. This NodeClass concept is not mapped directly in AutomationML. Instead, the relevant attributes are introduced in the SystemUnitClass, where they would first appear on an ObjectType or VariableType.

In OPC UA, the attributes that appear on a type are different from the attributes that appear on an instance of that type (although there is a large overlap). In AutomationML, the SystemUnitClasses contain the union of the relevant attributes for both the type and instance. This simplification leads to the possibility of attributes appearing in AML that make no sense. In this case, they should ideally be deleted, and if not deleted, they should be ignored. For example, in OPC UA, the ObjectType and VariableType NodeClasses contain an attribute IsAbstract that indicates if direct instances of that type are allowed. In AutomationML, the IsAbstract attribute could appear on both types and instances, but if it appears on an instance, it has no meaning and thus should be deleted (ideally by the engineering tool without user interaction) or at least ignored.

The attributes defined on the SystemUnitClasses are almost always optional and can be deleted in cases where there is no desire to configure a specific value. When such attributes are not present in the SystemUnitClass or an AML instance, but the attributes are required in OPC UA, then the rules stated in this document will be used to set appropriate values as noted.

The OPC UA Base NodeClass contains a set of attributes that appear on all OPC UA Nodes. In AML, their equivalent may appear in the SystemUnitClasses UaMethodNodeClass, BaseObjectType and BaseVariableType according to the mapping defined in Table A.4.

Table A.4 – Mapping UA Base NodeClass attributes to SUC UaMethodNodeClass, BaseObjectType and BaseVariableType attributes

Attribute name	May be included in SystemUnitClass and/or instances	Notes
NodeId		The NodeId attribute may be present in the AML SUC or instance if it is known when the AML is produced; however, it may be omitted if unknown. If the NamespaceURI portion of the NodeId or the entire NodeId is not present, then the SUC contains an AML attribute UaNodeNamespaceUri that represents the OPC UA Namespace of the corresponding OPC UA Node. If the NodeId and UaNodeNamespaceUri are empty or not present, then the presumed value is either the OPC UA Namespace referenced by the SUC library containing the SUC or the default OPC UA Server Namespace (depending on the context of the Node).
NodeClass		NodeClass is never present in the AML SUC. The appropriate UA NodeClass is inferred by the SUC, and the OPC UA Namespace referenced by the SUC library containing the SUC.
BrowseName	ü	If not present in the AML SUC, the OPC UA BrowseName is inferred by the AML object Name, and the NamepaceURI is either the OPC UA Namespace referenced by the SUC library containing the SUC or the default OPC UA Server Namespace (depending on the context of the Node).
DisplayName	ü	If not present in the AML SUC, the OPC UA DisplayName is inferred by the AML object Name.
Description	ü	If not present in the AML SUC, the OPC UA Description is inferred by the AML object’s Description Attribute in the Header.
WriteMask	ü	If not present in the AML SUC, the attribute is also omitted in OPC UA.
UserWriteMask		UserWriteMask is never present in the AML SUC.
RolePermissions	ü	If not present in the AML SUC, the attribute is also omitted in OPC UA.
UserRolePermissions		UserRolePermissions is never present in the AML SUC.
AccessRestrictions	ü	If not present in the AML SUC, the attribute is also omitted in OPC UA.
Executable		Executable is never present in the AML SUC.
UserExecutable		UserExecutable is never present in the AML SUC.

NOTE The checkmarks in Table A.4 indicate all of the OPC attributes allowed in the AML mapping, however the SUCs in the AML Libraries described in Annex B through Annex E may only contain a chosen subset. Engineering tools are free to delete any unused attributes or add any allowed attributes as needed.

The OPC UA BaseObjectType is modelled in AML as a SystemUnitClass with the same name. The BaseObjectType SUC contains attributes that mimic the attributes of the OPC UA Object and ObjectType NodeClasses, as shown in Figure A.9.

Figure A.9 – BaseObjectType Attributes

In OPC UA, the set of attributes appears on the type as well as the instances and the values on the types are often used to convey a default value on the instance. In AML, only one set of attributes is used since both a Value and DefaultValue can be specified for every attribute in AML.

Table A.5 shows the additional attributes introduced by the BaseObjectType SUC.

Table A.5 – Mapping UA Object/ObjectType NodeClass attributes to BaseObjectType SUC attributes

Attribute name	Included in SUC	Notes
IsAbstract	ü	If not present in the AML SUC type, the value is assumed to be FALSE. In instances, this attribute has no meaning and should be deleted or ignored.
EventNotifier	ü	If not present in the AML SUC, the attribute is also omitted in OPC UA.

All the rules in 0 for ObjectTypes also apply to VariableTypes with these notable differences:

The base AML SUC for OPC UA VariableTypes is BaseVariableType;

VariableTypes have a “Value” attribute and other attributes related to Value.

In BaseVariableType, the Value attribute has the DataType BaseDataType, as shown in Figure A.10.

Figure A.10 – Attributes of BaseVariableType

Table A.6 shows the additional attributes introduced by the BaseVariableType SUC.

Table A.6 – Mapping UA Variable/VariableType NodeClass attributes to BaseVariableType SUC attributes

Attribute name	Included in SUC	Notes
IsAbstract	ü	If not present in the AML SUC type, the value is assumed to be FALSE. In instances, this attribute has no meaning and should be deleted or ignored.
Value	ü	If not present in the AML SUC, the attribute value is NULL in OPC UA.
DataType		Never present in the AML SUC. The UA DataType is inferred by the DataType of the AML Value attribute.
ValueRank	ü	If not present in the AML SUC, the value in UA is assumed to be Any (2)
ArrayDimensions	ü	If not present in the AML SUC, the attribute is also omitted in OPC UA.
AccessLevel	ü	If not present in the AML SUC, the value of all fields is presumed to be FALSE. Only the fields of AccessLevelType that make sense for configuration are included in the AML attribute type. OPC UA Servers may override some or all of the configured values
UserAccessLevel		Never present in the AML SUC.
MinimumSamplingInterval	ü	If not present in the AML SUC, the attribute is also omitted in OPC UA.
Historizing		Never present in the AML SUC.
AccessLevelEx		Never present in the AML SUC.

BaseDataType is the root abstract DataType that all other OPC UA DataTypes derive from. The semantic implied by this is that the Value of an instance can be any valid DataType. Typically, VariableTypes that derive from BaseVariable type will alter the DataType of Value to be more restrictive. This could be other abstract DataTypes like the Number AttributeType or a concrete AttributeType from an OPC UA-based AML AttributeTypeLibrary, or an allowed built-in DataType from Table A.2. Figure A.11, Figure A.12 and Figure A.13 show some examples of derived VariableTypes with more restrictive DataTypes.

Figure A.11 – A VariableType with abstract Number DataType

Figure A.12 – A VariableType with a concrete Structure DataType

Figure A.13 – A Variable type with a built-in DataType

OPC UA ReferenceTypes are modelled in AML as InterfaceClasses. All AML InterfaceClasses that represent OPC UA ReferenceTypes shall derive directly or indirectly from the Reference’s InterfaceClass in the ICL_http://opcfoundation.org/UA/ InterfaceClassLibrary. OPC UA ReferenceTypes that are symmetric or have the same forward and inverse name shall be represented by a single AML InterfaceClass with the same name. All other ReferenceTypes shall be represented by a pair of AML InterfaceClasses where one element of the pair represents the source endpoint, and the other represents the destination endpoint corresponding to the forward and inverse names. This pair of AML InterfaceClasses are organized in a hierarchy, see Figure A.14. In Figure A.14, the OPC UA ReferenceTypes References and HierarchicalReferences are represented by a single AML InterfaceClass, but the ReferenceType Organizes is represented by a pair of AML Organizes/OrganizeBy.

Figure A.14 – ReferencesTypes Hierarchy

The base References InterfaceClass contains the Attributes shown in Table A.7.

Table A.7 – Attributes of References InterfaceClass

Attribute name	Type	Notes
InverseName	LocalizedText	For non-symmetric References, this is the name of the other interface class in the pair. It has no meaning for symmetric References.
IsAbstract	Boolean	Indicates if the Reference is abstract according to the UA model. The default value for this attribute is FALSE. If the attribute is missing, then the default value is assumed.
IsSource	xs:boolean	For non-symmetric References, TRUE shall indicate that this interface represents the source endpoint of the Reference, and FALSE shall indicate that this interface represents the destination endpoint of the Reference. It has no meaning for symmetric References. The default value for this attribute is FALSE. If the attribute is missing, then the default value is assumed.
ModellingRule	ModellingRuleType	Present on the destination interface to indicate the UA ModellingRule of the destination. If missing, the ModellingRule “Optional” shall be assumed.
RefClassConnectsToPath	xs:string	Indicates the AML path to the only other InterfaceClass that this interface shall be allowed to connect to. For symmetric References, this is a path to its own InterfaceClass. For non-symmetric References, this is the path to the other InterfaceClass in the pair.
Symmetric	Boolean	Indicates if the Reference is symmetric according to the UA model. The default value for this attribute is FALSE. If the attribute is missing, then the default value is assumed.

The InterfaceClasses are used in two ways:

Within an SUC to represent the UA relationships between the InternalElements of a Type within the SUC;

Within the InstanceHierarchy to show UA relationships between InternalElements.

When used within an SUC, the destination InterfaceClass contains a ModellingRule attribute that can be used to specify the UA ModellingRule used during instantiation. Figure A.15 Shows that the ModellingRule for the NodeVersion Property is explicitly set to “Mandatory”.

Figure A.16 shows an example of InterfaceClasses connected in an InstanceHierarchy.

Figure A.15 – SUC with connected InterfaceClasses

Figure A.16 – InstanceHierarchy with connected InterfaceClasses

OPC UA Interfaces are used to add a defined group of elements to an Object in an alternate way than containment or inheritance, similar to the way interfaces do in an object-oriented programming (OOP) language. Interfaces in OOP and OPC UA help alleviate some of the limitations of a single inheritance model by allowing an Object to “implement” multiple interfaces.

AML Role Classes serve a similar purpose in that an instance or an SUC can fulfil one or more Roles. For this reason, OPC UA InterfaceTypes are represented as Role Classes in AML in addition to being represented in the SUC as they naturally occur (since all OPC UA InterfaceTypes derive from the supertype BaseObjectType).

The AML RoleClasses that correspond to the UA InterfaceTypes contain no additional attributes. They only serve the purpose of annotating the SUCs that implement the Interfaces. Figure A.17 shows an example of an SUC (UA ObjectType) that implements several Roles that correspond to UA InterfaceTypes.

Figure A.17 – SUC that implements multiple Roles

OPC UA Instance Nodes shall map to AutomationML InternalElements in an AutomationML InstanceHierarchy, as shown in Figure A.18.

Figure A.18 – OPC UA InstanceHierarchy

Note that the example hierarchy shown in Figure A.18 was created using the OPC2AML Conversion Tool that mimics the full OPC UA instance tree as specified in the NodeSet files, minus the standard OPC UA Types folder since the equivalent type objects are contained in the AutomationML Libraries. Engineering tools may organize instance elements in alternate hierarchies (utilizing AutomationML MirrorElements) in addition to the way they would appear in an OPC UA Server.

When SUCs are instantiated in the AutomationML InstanceHierarchy, care must be given to setting the URIs properly to reflect the correct NamespaceURI for both the BrowseName and the Node. In the InstanceHierarchy, an empty or missing NamespaceURI (of the BrowseName) or UaNodeNamespaceUri shall imply the default NamespaceURI of the OPC UA Server (i.e. Namespace index 1). In all other cases, the URI attributes shall contain valid URIs that reflect the correct Node and BrowseName URIs.

The following information in an OPC UA NodeSet is lost when converting to OPC UA FX AML:

• NamespaceIndexes: OPC UA FX AML does not use NamespaceIndexes. It always uses the NamespaceURI as a string;
• Bit order in OptionSets and Bitmasks: In OPC UA FX AML, OptionSet and bit masks are defined with an unordered list of boolean AML attributes;
• builtinType values are defined as string and not as integer;
• AttributeId values are defined as string and not as integer.

When creating a NodeSet from an OPC UA FX AML file, the missing information needs to be taken from the NodeSet files that define the types used in the OPC UA FX AML file.

An AutomationComponent is either modelled as AML InternalElement as part of an AML InstanceHierarchy or as AML SystemUnitClass (SUC).

If the AutomationComponent is modelled as InternalElement (IE), it shall be either a direct or indirect instance of the SUC AutomationComponentType. If modelled as an SUC, it shall be a subclass of the SUC AutomationComponentType.

AutomationML does not have modelling rules, like mandatory or optional, that guide the creation of instances. Instantiating an SUC usually results in the creation of all InternalElements that are modelled as instance declarations on the type. However, since the UA modelling rules are present on the SUC of the OPC UA FX Libraries, engineering tools could do automatic postprocessing and delete the optional IEs from the type or let the user decide which optional IEs should be removed.

When making changes to an already existing AML InternalElement, two strategies can be followed:

• Change the InternalElement directly. Here, every operation (add, change, delete) is possible as long as it does not violate a rule from the OPC UA standard. However, in these cases, the original instance is not kept.
• Convert the InternalElement to an SUC, make the SUC a subclass of the SUC from which the InternalElement was created, and make an instance from this new SUC for further editing. This allows keeping the original InternalElement as an SUC in the type system. If this is done repeatedly, an instantiation step is followed by an SUC-conversion step, and the work history is available in the derivation chain of the modelled SUCs.

If an ObjectType, VariableType, DataType, or ReferenceType is used in an OPC UA FX Information Model that is not defined in the libraries listed in Annex B, Annex C, Annex D, and Annex E, a definition of the object type, variable type, data type, or reference type shall exist in an OPC UA FX Library, and this library shall be included in the Descriptor. The OPC UA FX AML Core Libraries are those libraries defined in this document.

For modelling of safety information for a Descriptor, the OPC UA FX AML Safety library shall be used (see Annex E).