OPC UA Servers and the underlying systems that they expose can be conveniently configured using AutomationML (AML) through the use of standardised 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, and
• 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 from which they all derive; 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.

Each AML AttributeType has a NodeId Attribute, which matches the NodeId of the OPC UA DataType. The NodeId Attribute does not appear on data type instances and contains an “OPC:TypeOnly” entry in the Additional Information collection of the Attribute Header.

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 composed of any other OPC UA DataTypes. Similarly, AML AttributeTypes can be derived from other AML AttributeTypes and 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 with 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 OptionSet’s 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 in AutomationML. In AutomationML, the full URI is always used, and there is never an index. Wherever NamespaceUri is used, the AutomationML datatype is always xs:anyURI.

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 in case the BrowsePath is not empty. The ExplicitNodeId attribute type is defined in A.2.3. If the BrowsePath is empty or not present, the node is identified by the RootNodeId or the NodeId resolved from the alias.

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.

If a BrowsePath is present and not empty in a NodeId, then the RootNodeId should be a well-known NodeId like the NodeId of the Root Object (NS=UA, i=84) or the NodeId of the FxRoot Object (NS=UAFX, i=71).

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

A typical use case for the BrowsePath in a Descriptor is to reference the corresponding variable in the AddressSpace from the PublishedData of a PublishedDataSet if the variable does not contain a real NodeId. The RootNodeId attribute of the NodeId AttributeType refers to the starting point of the BrowsePath, and the Elements of the BrowsePath direct to the target. Figure A.7 shows an example.

Figure A.7 – Example for the use of the BrowsePath

The formal definition of the BrowsePath is given in Table A.3.

Table A.3 – Formal definition of the BrowsePath

0	ReferenceTypeId	NamespaceUri	http://opcfoundation.org/UA/
		NumericId	35
	IncludeSubTypes		False
	IsInverse		False
	TargetName	NamespaceUri	https://www.acme.com/BottleMachineProject/
		Name	ME_BottleMachineProject
1	ReferenceTypeId	NamespaceUri	http://opcfoundation.org/UA/
		NumericId	47
	IncludeSubTypes		False
	IsInverse		False
	TargetName	NamespaceUri	http://opcfoundation.org/UA/FX/AC/
		Name	FunctionalEntities
2	ReferenceTypeId	NamespaceUri	http://opcfoundation.org/UA/
		NumericId	35
	IncludeSubTypes		False
	IsInverse		False
	TargetName	NamespaceUri	https://www.acme.com/BottleMachineProject/
		Name	BottleMachineFE
3	ReferenceTypeId	NamespaceUri	http://opcfoundation.org/UA/
		NumericId	47
	IncludeSubTypes		False
	IsInverse		False
	TargetName	NamespaceUri	http://opcfoundation.org/UA/FX/AC/
		Name	OutputData
4	ReferenceTypeId	NamespaceUri	http://opcfoundation.org/UA/
		NumericId	35
	IncludeSubTypes		False
	IsInverse		False
	TargetName	NamespaceUri	https://www.acme.com/BottleMachineProject/
		Name	BottleIdOut

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

PortableNodeId – The identifier field of PortableNodeId has the same definition as NodeId. The NamespaceUri information of the PortableNodeId is already present in the identifier and, therefore, redundant.

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

Table A.4 – 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.8.

Figure A.8 – 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.9.

Figure A.9 – 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 first introduced in the SystemUnitClass, where they would appear on an ObjectType or VariableType or an object or variable after instantiation.

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 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.5.

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

OPC UA Attribute name	Included in SystemUnitClasses or Instances	Notes
NodeId	X	If the NamespaceUri portion of the NodeId or the entire NodeId is not present, then the AML object 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 AML library containing the AML object or the default OPC UA Server Namespace (depending on the context of the Node). If the NodeId is not present on an AML object, it can be derived by constructing a BrowsePath from a well-known RootNodeId as described in A.3.7. See the example in A.3.7.1.
NodeClass		NodeClass is never present in the AML SUC. The appropriate UA NodeClass is inferred by the SUC, and the OPC UA Namespace is referenced by the SUC library containing the SUC. .
BrowseName	X	If the Name sub-attribute of the BrowseName AML attribute is not present (i.e. missing or empty) in the AML, then the Name portion of the BrowseName is inferred by the AML object Name. If the NamespaceUri sub-attribute of the BrowseName AML attribute is not present and the AML Object is contained in an AML library, the NamespaceUri portion of the BrowseName is the OPC UA Namespace referenced in the AML library definition. If the NamespaceUri sub-attribute of the BrowseName AML attribute is not present and the AML Object is in an AML InstanceHierarchy, then the NamespaceUri portion of the BrowseName is the default OPC UA server Namespace (Namespace index equals one).
DisplayName	X	If not present in the AML, the OPC UA DisplayName is inferred by the AML object Name. If the OPC UA DisplayName is present and has multiple localizations, the localizations are mapped to additional localized sub-attributes of the DisplayName AML attribute. All DisplayNames that are present in the Server shall be present in the AML file. The DisplayName that exists in the AML file may not be present in the Server due to memory reasons.
Description	X	If not present in the AML, the OPC UA Description is inferred by the Description XML attribute in the Header of the AML object. If the OPC UA Description is present and has multiple localizations, the localizations are mapped to additional localized sub-attributes of the Description AML attribute. All Descriptions that are present in the Server shall be included in the AML file. The Description that exists in the AML file may not be present in the Server due to memory reasons.
WriteMask	X	If the WriteMask is present in the AML, it shall also be present in the Server. If sub-attributes of the WriteMask Attribute are part of the AML, their values shall match the corresponding bits in the Server. If a sub-attribute of the WriteMask is not present in the AML, then the value of the field is unknown.
UserWriteMask		UserWriteMask is never present in the AML SUC.
RolePermissions	X	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	X	If the AccessRestrictions is present in the AML, it shall also be present in the Server. If sub-attributes of the AccessRestrictions Attribute are part of the AML, their values shall match the corresponding bits in the Server. If a sub-attribute of the AccessRestrictions is not present in the AML, then the value of the field is unknown.
Executable		Executable is never present in the AML SUC.
UserExecutable		UserExecutable is never present in the AML SUC.
NOTE The “X” marks 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.10.

Figure A.10 – 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.6 shows the additional attributes introduced by the BaseObjectType SUC.

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

Attribute name	Included in SUC or Instances	Notes
IsAbstract	X	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	X	If not present in the AML Object, the value of all fields is unknown. OPC UA Servers may override some or all of the configured values

All the rules in A.5 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.11.

Figure A.11 – Attributes of BaseVariableType

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

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

Attribute name	Included in SUC or Instances	Notes
IsAbstract	X	If not present in the AML SUC type, the value shall be FALSE. In some instances, this attribute has no meaning and should be deleted or ignored.
Value	X	If not present in the AML Object, the attribute value is NULL in OPC UA.
DataType		Never present in the AML Object. The UA DataType is inferred by the DataType of the AML Value attribute.
ValueRank	X	If not present in the AML Object, the value in OPC UA shall be Scalar (1).
ArrayDimensions	X	If not present in the AML Object, the attribute is also omitted in OPC UA.
AccessLevel	X	If not present in the AML Object, the value of all fields is unknown. OPC UA Servers may override some or all of the configured values
UserAccessLevel		Never present in the AML Object.
MinimumSamplingInterval	X	If not present in the AML Object, the attribute is also omitted in OPC UA.
Historizing		Never present in the AML Object.
AccessLevelEx	X	The bit fields of AccessLevelEx that are also contained in AccessLevel are not mapped to AML. If not present in the AML Object, the value of all fields is unknown. OPC UA Servers may override some or all of the configured values.

BaseDataType is the root abstract DataType from which all other OPC UA DataTypes derive. 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.12, Figure A.13, and Figure A.14 show some examples of derived VariableTypes with more restrictive DataTypes.

Figure A.12 – A VariableType with abstract Number DataType

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

Figure A.14 – 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.15. In Figure A.15, 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/OrganizedBy.

Figure A.15 – ReferencesTypes Hierarchy

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

Table A.8 – Attributes of References InterfaceClass

Attribute name	Type	Notes
NodeId	NodeId	In instances, this attribute has no meaning and should be deleted or ignored.This Attribute only appears on InterfaceClasses that represent the forward or symmetric Reference( i.e not on inverse references). This Attribute only appears on the InterfaceClass type and is marked with the Modelling Rule “OPC:TypeOnly” (see A.11.2.2).
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. This Attribute only appears on the InterfaceClass type and is marked with the Modelling Rule “OPC:TypeOnly” (see A.11.2.2).
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. This Attribute only appears on the InterfaceClass type and is marked with the Modelling Rule “OPC:TypeOnly” (see A.11.2.2).
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. This Attribute only appears on the InterfaceClass type and is marked with the Modelling Rule “OPC:TypeOnly” (see A.11.2.2).
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. This Attribute only appears on the InterfaceClass type and is marked with the Modelling Rule “OPC:TypeOnly” (see A.11.2.2).
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. This Attribute only appears on the InterfaceClass type and is marked with the Modelling Rule “OPC:TypeOnly” (see A.11.2.2).

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.16 Shows that the ModellingRule for the NodeVersion Property is explicitly set to “Mandatory”.

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

Figure A.16 – SUC with connected InterfaceClasses

Figure A.17 – 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.18 shows an example of an SUC (UA ObjectType) that implements several Roles that correspond to UA InterfaceTypes.

Figure A.18 – SUC that implements multiple Roles

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

Figure A.19 – OPC UA InstanceHierarchy

Note that the example hierarchy shown in Figure A.19 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, optional or no modelling rule, 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.

In OPC UA models, there are also attributes that only appear on data types and reference types that do not get propagated to instances, but in AML, the corresponding AML attribute types and AML interface classes, when instantiated propagate all the attributes associated with the type. In cases where the value of an attribute only has meaning on a type, the attribute shall contain an entry in the Additional Information collection of the Header “OPC:TypeOnly” to indicate that the attribute only has meaning on the type and can ideally be deleted or at least ignored on instances as shown in Figure A.20. Engineering tools should delete attributes marked “OPC:TypeOnly” when creating instances on export. Engineering tools shall ignore attributes marked “OPC:TypeOnly” on import in cases where the exporting tool fails to delete them when creating the instance.

Figure A.20 – “OPC:TypeOnly” additional Information in Header

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 the original InternalElement to be kept 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).