This Companion Specification maps AAS information model elements from “Details of the Asset Administration Shell – Part 1” (see section 2) expressed in UML class diagrams, to OPC UA information model elements. This mapping has to be used in order to implement Industrie 4.0 conformant digital twins based on OPC UA as implementation technology.

General rules for mapping the AAS information model to OPC UA are given in the following section. In subsequent sections examples for these rules are given.

General Rules:

1. For all class elements of the metamodel, an ObjectType with the same name + suffix “Type” + prefix “AAS” is added. Example: AASAssetType for Asset, AASSubmodelElementType for SubmodelElement and AASQualifierType for Qualifier. These Types are derived from OPC UA’s BaseObjectType. Exception: ConceptDescriptions and Referables (see below).
2. For all types in an AAS that cannot directly be mapped to OPC UA primitive types, a data type is created with the same name + suffix “DataType” + prefix “AAS”. Example: AASKeyElementDataType for KeyElement. Exception: LangStringSet is mapped to the predefined OPC UA type 0:LocalizedText.
3. Attributes of classes in an AAS that have a simple data type are mapped to 0:HasProperty references within the ObjectType. The BrowseName corresponds to the name in the AAS UML model but is starting with a capital letter. Example: AASAdministrativeInformationType contains a property with BrowseName Version and data type String. Exception: The name of the attribute “Kind” was extended with the prefixes “Modelling” and “Asset”.
4. The cardinality of an association or aggregation is specified via OPC UA modelling rules. The OPC UA modelling rule “Optional” is used, if the cardinality is 0 or 1. The OPC UA modelling rule “Mandatory” is used, if the cardinality is 1. The OPC UA modelling rule “OptionalPlaceholder” is used, if the cardinality is 0, one or more than one element. The OPC UA modelling rule “MandatoryPlaceholder” is used, if the cardinality is 1 or more than 1 element.
5. Aggregation and composition attributes of classes in AAS are mapped to 0:HasComponent References within the ObjectType. In case of cardinality 0 .. 1 or 1 the BrowseName corresponds to the name in the AAS UML model but is starting with capital letter. Example: Objects of type “AASAssetType” have a component with browse name “AssetIdentificationModel”. In case of cardinality > 1 the BrowseName corresponds to the idShort in the AAS UML model. Example: AASSubmodelType has OPC UA components with OPC UA TypeDefinition AASSubmodelElementType. A submodel element may have the idShort “MaxRotationSpeed”. Then the BrowseName of the component is “MaxRotationSpeed” as well.
6. Since OPC UA does not support multiple inheritance abstract classes, e.g. needed for the AAS classes “Qualifiable” or “Identifiable”, these are not modelled via subtype reference in OPC UA. The corresponding attributes, aggregations and compositions are modelled as part of the inheriting class. For details see rules below.

Rules for SubmodelElements:

1. Specific for the Blob SubmodelElement type (AASBlobType) the predefined OPC UA type definition FileType is used for the value. References of type FileType are components of the ObjectType. The BrowseName is not “value”, but “File”. The mime type is part of the OPC UA FileType and therefore not added. In contrast to the OPC UA FileType, the mime type is mandatory for the AAS information model.
2. Specific for the File SubmodelElement type (AASFileType) the value attribute is mapped to an OPC UA property with BrowseName “FileReference”. Additionally, an object of type “FileType” with browse name “File” can be added similar as for the Blob. Since this is optional, the mime type is modelled as OPC UA property. In case both are present, then the mime types need to be the same.
3. SubmodelElementCollection can be either ordered or not ordered. In case of an ordered collection “SubmodelElementCollection” is realized as AASOrderedSubmodelElementCollectionType and the relationship between collection and submodel elements is realized via the predefined OPC UA “HasOrderedComponent” reference type. Otherwise a AASSubmodelElementCollectionType is used.
4. For Operations first an AASOperationType is defined but then the OPC UA Method is used for describing the operation. The name of the method is “Operation”. Hint: The OPC UA Specification “Amendment 2: Method Metadata” allows to add meta information to individual arguments (HasArgumentDescription). This is used to realize a semanticId by using the OPC UA reference type 0:HasDictionaryEntry. For AAS references as used in ReferenceElement of RelationshipElement see rule for referencing.
5. For AAS submodel elements of type “Event”, the ObjectType “AASEventType” references an OPC UA event via the reference type “GenerateEvent”.

Rules for Referables and Identifiables:

1. For Referable and Identifiable separate OPC UA ObjectTypes are defined that are referenced from the corresponding ObjectTypes representing the concrete referables and identifiables via the OPC UA 0:HasInterface reference type. The naming convention for this is as follows: “IAAS<AAS UML class name>”. Example: IAASIdentifiableType.
2. In case of referenced referables with modelling rule “OptionalPlaceholder” or “MandatoryPlaceholder” the attribute idShort of AAS Referables is represented by the browse name of an element. Since there are cases like for AssetAdministrationShell/asset where the browse name is “Asset” but the asset has an idShort as well, idShort is modelled additionally. In cases with no predefined BrowseName The BrowseName and the idShort shall be identical.
3. DisplayName has prefix "Asset:", "AAS:", "Submodel:" and "View:" for Instances of AASAssetType, AASAssetAdministrationShellType, AASSubmodelType and AASViewType. Although DisplayName is of type LocalizedText, the prefix will not be translated.
4. The parent attribute of Referables is not explicitly modelled because OPC UA supports native navigation.
5. In case of referenced referables with modelling rule “Optional” or “Mandatory” the browse name is identical to the AAS attribute name and the display name shall be identical to the idShort.

Rules for Qualifiables:

1. Qualifiers of an element are modelled via the 0:HasComponent reference. Since qualifiers are not referable, they do not have a BrowseName that corresponds to an AAS attribute. Instead the name should be generated as follows: qualifier:<value of AAS:Qualifier/qualiferType>=<value of Qualifier/qualifierValue>.

Rules for semanticId and Concept Descriptions:

1. A concept description is inheriting from the predefined OPC UA IrdiDictionaryEntry or UriDictionaryEntry. This is why there are both ObjectTypes: “AASIrdiConceptDescriptionType” or “AASUriConceptDescriptionType” and not only one like for the other AAS classes. Additionally for “idType = Custom” a new Type “AASCustomConceptDescriptionType” is created inheriting directly from “DictionaryEntryType”.
2. Concept descriptions are added to a folder on the server side. The “Dictionaries” folder defined in OPC 10000-19 shall be the top-level folder. Below additional subfolders can be created.
3. semanticId is modelled by using the predefined OPC UA reference type HasDictionaryEntry and is either referencing an object of type “AASIrdiConceptDescriptionType” or of type “AASUriConceptDescriptionType” or of type “AASCustomConceptDescriptionType”.
4. A concept description has at least one Add-In to allow the usage of the IEC61360 data specification template (see rules for data specifications).

Rules for Data Specifications:

1. Concrete data specifications are inheriting from the AAS ObjectType “AASDataSpecificationType”.
2. There is no need in OPC UA to distinguish between the data specification properties and the data specification content defining the properties that shall be added to the ObjectType that uses the data specification. The AAS attributes of DataSpecification are modelled as OPC UA properties or components (rules as above) of the AASDataSpecificationType but are not instantiated. This is always the case in OPC UA if there are no modelling rules attached to a property or component.
3. The concept of embedded data specifications is used. The element that is using the data specification uses the OPC UA reference type 0:HasComponent. This Add-In uses pairs of elements: one property being the global external reference to a data specification, the other one being the data specification content.
4. For AAS references as used in ReferenceElement of RelationshipElement a new non-hierarchial Reference Type “AASReference” is introduced. For AAS, however, also global external references are possible – to elements in other AAS on other OPC UA Servers or to entities completely outside the scope of the AAS. The object with type “AASReferenceType” is holding the unique key chain to the referenced elements and optionally can reference the “real” element via “AASReference” reference. There is no special rule for the BrowseName in this case. The display name should be the same as the idShort of the referenced element.
5. The Keys of a reference are implemented in form of an array. Every single Key is serialized as described in Section 5.2.1. of “Details of the Asset Administration Shell – Part 1” V2.0.

Rules for Semantics of Metamodel Elements

1. The 0:HasDictionaryEntr y reference type of OPC UA is not only used to describe the semantics of objects but also of ObjectTypes. For doing so, the rules for creating identifiers as defined in Section 5.2.2 of “Details of the Asset Administration Shell – Part 1” V2.0 are used.

Figure 8 gives a general overview about the AAS root (left upper structure), the asset type description (left lower structure), the submodel type (right upper structure) and the submodel element types (right lower structure). The detailed specification is part of the following sections.

Legend: green – defined in OPC UA, red – type/instance relation, brown – Identification elements, black – main AAS model definitions

Figure 8 – Overview of the AAS OPC UA core information model

Table 8 collects all AAS ObjectTypes that are directly derived from OPC UA types.

Table 8 – Basic ObjectTypes of the asset administration shell

AASiD Element	Parent OPC UA type
AASAssetAdministrationShellType	BaseObjectType
AASAssetType	BaseObjectType
AASSubmodelType	BaseObjectType
AASSubmodelElementType	BaseObjectType
AASAdministrativeInformationType	BaseObjectType
AASReferenceType	BaseObjectType
AASIriConceptDescriptionType	UriDictionaryEntryType
AASIrdiConceptDescriptionType	IrdiDictionaryEntryType
AASCostumConceptDescriptionType	DictionaryEntryType
AASViewType	BaseObjectType
AASQualifierType	BaseObjectType

Table 9 collects all Asset Administration Shell ReferenceTypes which are OPC UA types.

Table 9 – Basic ReferenceTypes of the asset administration shell

AASiD Element	Parent OPC UA type
IAASReferableType	BaseInterfaceType
AASReference	NonHierarchicalReference

Table 10 collects all AAS data types that are directly derived from OPC UA data types.

Table 10 – Basic data types of the asset administration shell

AASiD Element	Parent OPC UA type
AASAssetKindDataType	Enumeration
AASModelingKindDataType	Enumeration
AASIdentifierTypeDataType	Enumeration
AASEntityTypeDataType	Enumeration
AASCategoryDataType	Enumeration
AASDataTypeIEC61360DataType	Enumeration
AASLevelTypeDataType	Enumeration
AASKeyElementsDataType	Enumeration
AASKeyTypeDataType	Enumeration
AASValueTypeDataType	Enumeration
AASMimeDataType	String
AASPathDataType	String
AASPropertyValueDataType	String
AASQualifierDataType	String
AASKeyDataType	Structure

-

The ObjectTypes in this specification define dictionary entries (using the HasDictionaryEntry References) in various places either directly on the ObjectType or the InstanceDeclarations. By the nature of this non-hierarchical Reference this only defines the dictionary entry for the corresponding Node. It does not require, from the OPC UA modelling concepts, that instances of the ObjectType or instances based on InstanceDeclarations have to have the same dictionary entries. However, this is the intention in this specification. Therefore, all Objects that are instance of an ObjectType defined in this specification shall have the same HasDictionaryEntry References to the same dictionary entries as the ObjectType. The same is true for the InstanceDeclarations. Instances based on InstanceDeclarations shall have References to the same dictionary entries as their InstanceDeclarations. In both cases it is allowed, that instances have additional References to other DictionaryEntries.