1 Scope

The companion specification presented in this document is an extension of the overall OPC Unified Architecture standards and defines an information model that conforms to the Industrie 4.0 Asset Administration Shell (AAS) metamodel defined in the Plattform Industrie 4.0 document “Details of the Asset Administration Shell” (see Section 2).

The aim of the AAS metamodel is to enable partners in a value creation network to exchange meaningful information by conforming to a specified set of standardized information elements.

This companion specification describes the mapping of the AAS metamodel specified in “Details of the Asset Administration Shell - Part 1” (see Section 2) to the OPC UA information model in order to represent AAS and their submodels in the address space of OPC UA servers.

2 Normative references

The following referenced documents are indispensable for the application of this companion specification. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

Details of the Asset Administration Shell - Part 1 - The exchange of information between partners in the value chain of Industrie 4.0 (Version 2.0.1).

https://www.plattform-i40.de/PI40/Redaktion/EN/Downloads/Publikation/Details_of_the_Asset_Administration_Shell_Part1_V2.html

OPC 10000-1 - OPC UA Specification: Part 1 – Concepts

3 Terms, definitions and conventions

3.1 Overview

It is assumed that basic concepts of OPC UA information modelling and metamodel of the AAS are understood in this companion specification. This companion specification will use these concepts to describe the AAS Information Model. For the purposes of this document, the terms and definitions given in OPC 10000-1, OPC 10000-3, OPC 10000-4, OPC 10000-5, OPC 10000-7 and “Details of the Asset Administration Shell – Part 1” V2.0 (see section 2) as well as the following apply.

Note that OPC UA terms and terms defined in this companion specification are italicized in the specification.

3.2 OPC UA for Asset Administration Shell terms

The terms defined in “Details of the Asset Administration Shell - Part 1” (see section 2) are valid for this companion specification.

3.3 Abbreviations and symbols

3.4 Conventions used in this document

3.4.1 Conventions for Node descriptions

Node definitions are specified using tables (see Table 2).

Attributes are defined by providing the Attribute name and a value, or a description of the value.

References are defined by providing the ReferenceType name, the BrowseName of the TargetNode and its NodeClass.

• If the TargetNode is a component of the Node being defined in the table the Attributes of the composed Node are defined in the same row of the table.

• The DataType is only specified for Variables; “[<number>]” indicates a single-dimensional array, for multi-dimensional arrays the expression is repeated for each dimension (e.g. [2][3] for a two-dimensional array). For all arrays the ArrayDimensions is set as identified by <number> values. If no <number> is set, the corresponding dimension is set to 0, indicating an unknown size. If no number is provided at all the ArrayDimensions can be omitted. If no brackets are provided, it identifies a scalar DataType and the ValueRank is set to the corresponding value (see OPC 10000-3). In addition, ArrayDimensions is set to null or is omitted. If it can be Any or ScalarOrOneDimension, the value is put into “{<value>}”, so either “{Any}” or “{ScalarOrOneDimension}” and the ValueRank is set to the corresponding value (see OPC 10000-3 and the ArrayDimensions is set to null or is omitted. Examples are given in Table 1.

• The TypeDefinition is specified for Objects and Variables.

• The TypeDefinition column specifies a symbolic name for a NodeId, i.e. the specified Node points with a HasTypeDefinition Reference to the corresponding Node.

• The ModellingRule of the referenced component is provided by specifying the symbolic name of the rule in the ModellingRule column. In the AddressSpace, the Node shall use a HasModellingRule Reference to point to the corresponding ModellingRule Object.

If the NodeId of a DataType is provided, the symbolic name of the Node representing the DataType shall be used.

Nodes of all other NodeClasses cannot be defined in the same table; therefore, only the used ReferenceType, their NodeClass and their BrowseName are specified. A reference to another part of this document points to their definition.

Table 2 illustrates the Type Definition Table. If no components are provided, the DataType, TypeDefinition and ModellingRule columns may be omitted and only a Comment column is introduced to point to the Node definition.

Components of Nodes can be complex and contain components by themselves. The TypeDefinition, NodeClass, DataType and ModellingRule can be derived from the type definitions, and the symbolic name can be created as defined in 3.4. Therefore, those contained components are not explicitly specified; they are implicitly specified by the type definitions.

3.4.2 NodeIds and BrowseNames

3.4.2.1 NodeIds

The NodeIds of all Nodes described in this standard are only symbolic names. Annex A defines the actual NodeIds.

The symbolic name of each Node defined in this companion specification is its BrowseName, or, when it is part of another Node, the combination of the BrowseName of the other Node, a “.” and the BrowseName of itself. In this case “part of” means that the whole has a 0:HasProperty or 0:HasComponent Reference to its part. Since all Nodes not being part of another Node have a unique name in this companion specification, the symbolic name is unique.

The NamespaceUri for all NodeIds defined in this companion specification is defined in Annex A. The NamespaceIndex for this NamespaceUri is vendor-specific and depends on the position of the NamespaceUri in the server namespace table.

Note that this companion specification not only defines concrete Nodes, but also requires that some Nodes shall be generated, for example one for each Session running on the Server. The NodeIds of those Nodes are Server-specific, including the namespace. But the NamespaceIndex of those Nodes cannot be the NamespaceIndex used for the Nodes defined in this companion specification, because they are not defined by this companion specification but generated by the Server.

3.4.2.2 BrowseNames

The text part of the BrowseNames for all Nodes defined in this companion specification is specified in the tables defining the Nodes. The NamespaceUri for all BrowseNames defined in this companion specification is defined in Annex A.

If the BrowseName is not defined by this companion specification, a namespace index prefix like ‘0:EngineeringUnits’ or ‘2:DeviceRevision’ is added to the BrowseName. This is typically necessary if a Property of another specification is overwritten or used in the OPC UA types defined in this companion specification. Table 88 provides a list of namespaces and their indexes as used in this companion specification.

3.4.3 Common Attributes

3.4.3.1 General

The Attributes of Nodes, their DataTypes and descriptions are defined in OPC 10000-3. Attributes not marked as optional are mandatory and shall be provided by a Server. The following tables define if the Attribute value is defined by this companion specification or if it is server-specific.

For all Nodes specified in this companion specification, the Attributes named in Table 3 shall be set as specified in the table.

3.4.3.2 Objects

For all Objects specified in this companion specification, the Attributes named in Table 4 shall be set as specified in the Table 4. The definitions for the Attributes can be found in OPC 10000-3.

3.4.3.3 Variables

For all Variables specified in this companion specification, the Attributes named in Table 5 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.4.3.4 VariableTypes

For all VariableTypes specified in this companion specification, the Attributes named in Table 6 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.4.3.5 Methods

For all Methods specified in this companion specification, the Attributes named in Table 7 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

4 General information on the Asset Administration Shell and OPC UA

4.1 Introduction to the Asset Administration Shell

4.1.1 Motivation

The Asset Administration Shell (AAS) is the standardized digital representation of an asset, the corner stone for the interoperability of Industrie 4.0 components organized in Industrie 4.0 systems. The Industrie 4.0 component is the combination of the asset and its digital representation, the AAS, as illustrated in Figure 1. The AAS may be the logical representation of a simple component, a machine or a plant at any level of the equipment hierarchy. The manufacturer provides the standardized digital representation to his customers, creating both an AAS for the asset type and for each asset instance. The system designers, the asset users, the applications, the processes and the asset itself update the information of the AAS during the lifetime of the asset until its disposal. From the manufacturer’s point of view the asset is a product. The manufacturer manages different asset types that have a history with different versions. In parallel, he produces instances of these different types and versions.

4.1.2 AAS metamodel overview

The AAS metamodel stipulates structural principles of the AAS in a formal manner (UML) in order to enable an exchange of information between AASs. The main parts of AAS model elements describe the represented asset as well as its submodels (see Figure 2). Optionally, dictionaries and views may be part of an AAS. A dictionary contains so-called concept descriptions. Views define a set of elements selected for a specific stakeholder, e.g. for a machine operator. An AAS represents exactly one asset.

4.2 Introduction to OPC Unified Architecture

4.2.1 What is OPC UA?

OPC UA is an open and royalty free set of standards designed as an interoperability framework. While there are numerous communication solutions available, OPC UA has key advantages:

A state-of-the-art security model (see OPC 10000-2).

Multiple fault-tolerant communication protocols.

An information modelling framework that allows application developers to represent their data in an object-oriented way.

OPC UA has a broad scope which offers economies of scale for application developers. This means that a larger number of high-quality applications at a reasonable cost is available. When combined with semantic models such as Asset Administration Shell, OPC UA makes it easier for end users to access data via generic commercial applications.

The OPC UA model is scalable from small devices to ERP systems. OPC UA Servers process information locally and then provide that data in a consistent format to any application requesting data -- ERP, MES, PMS, Maintenance Systems, HMI, Smartphone or a standard Browser, for example. For a more complete overview see OPC 10000-1.

4.2.2 Basics of OPC UA

As an open standard, OPC UA is based on standard internet technologies, like TCP/IP, HTTP, Web Sockets.

As an extensible standard, OPC UA provides a set of Services (see OPC 10000-4) and a basic information model framework. This framework provides an easy method for creating and exposing vendor defined information in a standard way. Moreover, OPC UA Clients are able to discover and use vendor-defined information. This means OPC UA users can benefit from the economies of scale that come with generic visualization and historian applications. This companion specification is an example of an OPC UA Information Model designed to meet the needs of a specific group of developers and users.

OPC UA Clients can be any consumer of data from another device on the network to browser based thin clients and ERP systems. The full scope of OPC UA applications is shown in Figure 3.

OPC UA provides a robust and reliable communication infrastructure having mechanisms for handling lost messages, failover, heartbeat, etc. With its binary encoded data, it offers a high-performing, secure data exchange solution.

4.2.3 Information modelling in OPC UA

4.2.3.1 Concepts

OPC UA provides a framework that can be used to represent complex information as Objects in an AddressSpace which can be accessed with standard services. These Objects consist of Nodes connected by References. Different classes of Nodes convey different semantics. For example, a Variable Node represents a value that can be read or written. The Variable Node has an associated DataType that can define the type of the actual value, such as a string, float, structure etc. It can also describe the Variable value as a variant. A Method Node represents a function that can be called. Every Node has a number of Attributes including a unique identifier called NodeId and a non-localized name called BrowseName. An Object representing a ‘Reservation’ is shown in Figure 4.

Object and Variable Nodes represent instances and they always reference a TypeDefinition (ObjectType or VariableType) Node which describes their semantics and structure. Figure 5 illustrates the relationship between an instance and its TypeDefinition.

The type Nodes are templates that define all of the children that can be present in an instance of the type. In the example in Figure 5 the PersonType ObjectType defines two children: First Name and Last Name. All instances of PersonType are expected to have the same children with the same BrowseNames. Within a type the BrowseNames uniquely identify the children. This means Client applications can be designed to search for children based on the BrowseNames from the type instead of NodeIds. This eliminates the need for manual reconfiguration of systems if a Client uses types that multiple Servers implement.

OPC UA also supports the concept of subtyping. This allows a modeller to take an existing type and extend it. There are rules regarding subtyping defined in OPC 10000-3, but in general they allow the extension of a given type or the restriction of a DataType. For example, the modeller may decide that the existing ObjectType in some cases needs an additional Variable. The modeller can create a subtype of the ObjectType and add the Variable. A Client that is expecting the parent type can treat the new type as if it was of the parent type. Regarding DataTypes, subtypes can only restrict. If a Variable is defined to have a numeric value, a sub type could restrict it to a float.

References allow Nodes to be connected in ways that describe their relationships. All References have a ReferenceType that specifies the semantics of the relationship. References can be hierarchical or non-hierarchical. Hierarchical references are used to create the structure of Objects and Variables. Non-hierarchical are used to create arbitrary associations. Applications can define their own ReferenceType by creating subtypes of an existing ReferenceType. Subtypes inherit the semantics of the parent but may add additional restrictions. Figure 6 depicts several References, connecting different Objects.

The figures above use a notation that was developed for the OPC UA specification. The notation is summarized in Figure 7. UML representations can also be used; however, the OPC UA notation is less ambiguous because there is a direct mapping from the elements in the figures to Nodes in the AddressSpace of an OPC UA Server.

A complete description of the different types of Nodes and References can be found in OPC 10000-3 and the base structure is described in OPC 10000-5.

OPC UA specification defines a very wide range of functionality in its basic information model. It is not expected that all Clients or Servers support all functionality in the OPC UA specifications. OPC UA includes the concept of Profiles, which segment the functionality into testable certifiable units. This allows the definition of functional subsets (that are expected to be implemented) within a companion specification. The Profiles do not restrict functionality, but generate requirements for a minimum set of functionalities (see OPC 10000-7).

4.2.3.2 Namespaces

OPC UA allows information from many different sources to be combined into a single coherent AddressSpace. Namespaces are used to make this possible by eliminating naming and ID conflicts between information from different sources. Namespaces in OPC UA have a globally unique string called a NamespaceUri and a locally unique integer called a NamespaceIndex. The NamespaceIndex is only unique within the context of a Session between an OPC UA Client and an OPC UA Server. The Services defined for OPC UA use the NamespaceIndex to specify the Namespace for qualified values.

There are two types of values in OPC UA that are qualified with Namespaces: NodeIds and QualifiedNames. NodeIds are globally unique identifiers for Nodes. This means the same Node with the same NodeId can appear in many Servers. This, in turn, means Clients can have built-in knowledge of some Nodes. OPC UA Information Models generally define globally unique NodeIds for the TypeDefinitions defined by the Information Model.

QualifiedNames are non-localized names qualified with a Namespace. They are used for the BrowseNames of Nodes and allow the same names to be used by different information models without conflict. TypeDefinitions are not allowed to have children with duplicate BrowseNames; however, instances do not have that restriction.

4.2.3.3 Companion Specifications

An OPC UA companion specification for an industry specific vertical market describes an Information Model by defining ObjectTypes, VariableTypes, DataTypes and ReferenceTypes that represent the concepts used in the vertical market, and potentially also well-defined Objects as entry points into the AddressSpace.

5 AAS metamodel representation in the OPC UA information model

5.1 General rules for the mapping of the AAS metamodel to the OPC UA information model

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:

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

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.

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

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.

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.

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:

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.

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.

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.

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.

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:

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.

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.

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.

The parent attribute of Referables is not explicitly modelled because OPC UA supports native navigation.

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:

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:

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

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.

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

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:

Concrete data specifications are inheriting from the AAS ObjectType “AASDataSpecificationType”.

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.

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.

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.

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

The 0:HasDictionaryEntry 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.

5.2 Overview of AAS in the OPC UA information model

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

5.3 Overview of AAS types which are directly inherited from OPC UA types

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

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

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

-

5.4 Handling of Dictionary Entries

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.

6 OPC UA ObjectTypes

6.1 General remark

The AAS metamodel contains model elements representing security aspects. These are not part of this version of the companion specification and a matter of the next revision.

6.2 AAS root ObjectTypes

Table 11 defines the root class AASAssetAdministrationShellType of the OPC UA Asset Administration Shell.

Note: For a single submodel either a <Submodel> component or a <SubmodelReference> component is created. Submodel references are used in case that the submodel is deployed on a different OPC UA Server, i.e. it is not located in the address space. Otherwise the submodel can be directly added.

The components of the AASAssetAdministrationShellType have additional references which are defined in Table 12.

6.3 AASReferenceType

For AAS references as used in ReferenceElement of RelationshipElement a new non-hierarchial ReferenceType “AASReference” is introduced (Figure 9). The OPC UA ReferenceType 0:HasComponent is not directly used to reference an element because OPC UA references can only reference elements in the same address space. For more details please see rule 24 in section 5.1.

The details of the AASReferenceType are defined in Table 13.

The components of the AASReferenceType have additional references which are defined inTable 14.

Objects of the AASReferenceType can reference another referable node instance. Instances of the following ObjectTypes can be referenced:

AASAccessPermissionRuleType

AASAnnotatedRelationshipElementType

AASAssetAdministrationShellType

AASAssetType

0:BaseEventType

AASBlobType

AASCapabilityType

AASConceptDictionaryType

AASCustomConceptDescriptionType

AASFileType

AASEntityType

AASEventType

AASIrdiConceptDescriptionType

AASIriConceptDescriptionType

AASMultiLanguagePropertyType

AASOperationType

AASPropertyType

AASRangeType

AASReferenceElementType

AASRelationshipElementType

AASSubmodelType

AASSubmodelElementType

AASSubmodelElementCollectionType

AASViewType

6.4 Referable and Identifiable

The identification concept serves to clearly identify all AAS elements. In principle, a distinction can be made between the following partial identification concepts, which differ in their validity area (Figure 10).

• Globally unique identification, e.g. IRDI or URI - this is called "Identifiable"

• Locally unique identification (instance-related ID valid only in the inner context of an AAS) - this is called "Referable"

• semantic referencing (reference to a conceptual library (dictionary / repository))

In Figure 10 these are shown. The light blue backed rectangles are each AASs. The attributes of the AAS named in the upper section (AAS - Asset Administration Shell, Asset and Submodel) have a globally valid identifier. In addition to the identifier itself, the identifier is also given its type, which can be URI, IRDI or Custom (manufacturer-specific). The identifiers of these AAS elements are thus unique. This is necessary because it is the entry point into the AAS. If this is compared with an OPC UA Server URI, then the same applies since the validity in the namespace of the OPC UA server must also be unique.

The middle section of Figure 10 shows AAS elements that have locally unique identifiers. This allows for e.g. the same properties can be present several times and also submodels can be used again and again. The validity of this identification concept is only in its context (namespace), i.e. along the composition from the globally unique identifiers until the individual instances. An example of idShort is "MaxTemp" and for the composition in the identification: "urn: PROFIBUS: PROFIBUS-PA: V3-02: Parameter: 1: 1: MaxTemp # 0002".

With these two concepts, the identification of an AAS, i.e. the addressing is clearly possible. However, as with the example of the PROFIBUS PA profile, the name MaxTemp is unique only in this profile. In the planning documents of the plants there are also specifications for the maximum temperature, as well as in the manual of the transmitter. All three parameters correspond to the same understanding, but they are not automatically interconvertible by machine. This is where the third identification concept of AAS comes in. The lower part of Figure 10 shows the semantic references that refer to dictionaries, which are feature catalogs that store the understanding of the properties and important attributes (data type, unit of measurement, ...). From selected AAS elements e.g. submodel and property can be checked if the same thing is meant despite different naming. It is possible to specify only the semantic reference and it is expected that the user can interpret this. However, it is also possible to embed the corresponding dictionary in the AAS.

For these three identification principles, there are corresponding model elements in the AAS metamodel. It is also possible that an element e.g. a submodel has both a local identifier and a semantic reference. The reserved word "keys" encapsulates each of the attributes of the identifier. The attribute "local" allows elements to be located outside the AAS where it is identifiable. Local = "TRUE" means the identifier value "Value" refers to the same AAS, Local = "FALSE" means the identifier value "Value" refers to an external location. The “Local” variable is defined in AASKeyDataType (Table 70).

Figure 11 shows an overview about the IAASReferableType ObjectType.

For the identification concept, a mapping to the OPC UA information model is shown in (Figure 11). It can be seen that "Identifiable" is a specialization of "Referable". The identifiable identification contains not only the identifier but also the type and optionally a version and revision. The Category for the Referable Identifier are inherited. What is striking is that in OPC UA modelling at this level, the formal idShort designation is not visible. idShort is always mapped to the browsing name of an OPC UA node by the generally valid rule (see). In this way, the locally valid identification customary in OPC UA can be used.

Overall, this AAS identification concept is an extension of the OPC UA BrowseName Identification (valid in the namespace of the OPC UA Server).

6.4.1 IAASReferableType

Table 15 defines the AASReferable ObjectType.

The OPC UA node attribute “description” is used for the IAASReferableType instances.

The components of the IAASReferableType have additional references which are defined in Table 16.

6.4.2 IAASIdentifiableType

Table 17 defines the IAASIdentifiable ObjectType.

The components of the IAASReferableType have additional references which are defined in Table 18.

6.4.3 AASAdministrativeInformationType

The AdministrativeInformationType is a subtype of the BaseObjectType. Table 19 defines the AASAdministrationInformation ObjectType.

The components of the AASAdministrativeInformationType have additional references which are defined in Table 20.

6.5 AASIdentifierType

Table 21 defines the AASIdentifier ObjectType. It is used to uniquely identify an entity.

The components of the AASIdentifierType have additional references which are defined in Table 22.

6.6 AASAssetType

Figure 12 shows an overview about the AASAsset ObjectType.

The Asset Type describes meta data of an asset that is represented by an AAS. The asset has a globally unique identifier (I4AASIdentifiableType) plus – if needed – additional domain specific (proprietary) identifiers (Table 23). Optionally it can refer to a list of submodels.

The components of the AASAssetType have additional references which are defined in Table 24.

6.7 AASSubmodelType

Figure 13 shows an overview about the AASSubmodel ObjectType.

A Submodel defines a specific aspect of the asset represented by the AAS and is defined in Table 25.

A submodel is used to structure the information model of an AAS representing the technical functionality of the underlying asset into distinguishable parts. Each submodel refers to a well-defined domain or subject matter. Submodels can become standardized and thus become submodel templates. Submodels can have different life-cycles.

Note: The concept of template and instance applies to properties.

The default value of the variable “ModelingKind” is “Instance”.

For each AASSubmodelType instance the semanticId is mapped to the OPC UA HasDictionaryEntry reference. This is why the semanticId refers to the instance of the submodel element. This is equivalent to the DictionaryEntry which refers to the concept dictionary element which describes the individual instance not the submodel type.

The components of the AASSubmodelType have additional references which are defined in Table 26.

6.8 SubmodelElementType specialization

To meet the range of aspects of the assets which have to be described in the AAS a set of submodel element types are defined. Each submodel element type represents one of these aspects. Figure 14 provides a general overview.

6.8.1 AASSubmodelElementType common attributes

Figure 15 shows an overview about the AASSubmodelElement ObjectType.

A data element is a submodel element that is not further composed of other submodel elements (Table 27). A data element is a submodel element that has a value. The type of value may differ for different data elements.

The default value of the variable “ModelingKind” is “Instance”.

For each AASSubmodelElementType instance the semanticId is mapped to the OPC UA HasDictionaryEntry. This is at instance level because the DictionaryEntry refers to the concept dictionary element, which describes the individual instance and not the submodel element type.

The components of the AASSubmodelElementType have additional references which are defined in Table 28.

6.8.2 AASSubmodelElementCollectionType

Figure 16 shows an overview about the AASSubmodelElementCollection ObjectType.

A submodel element collection is a set or list of submodel elements. The AASSubmodelElementCollectionType is defined in Table 29

The components of the AASSubmodelElementCollectionType have additional references which are defined in Table 30.

The value elements in this collection are not ordered (i.e. http://Admin-shell.io/aas/2/0/ SubmodelElementCollection/ordered == False).

6.8.3 AASOrderedSubmodelElementCollectionType

Figure 17 shows an overview about the AASOrderedSubmodelElementCollection ObjectType.

Table 31 defines the AASOrderedSubmodelElementCollection ObjectType.

The components of the AASOrderedSubmodelElementCollectionType have additional references which are defined in Table 32.

The value elements in this collection are ordered (i.e. http://Admin-shell.io/aas/2/0/ SubmodelElementCollection/ordered == True).

6.8.4 AASMultiLanguagePropertyType

Figure 18 shows an overview about the AASMultiLanguageProperty ObjectType

This submodel element type is used for properties with a value that can be provided in multiple languages (see Table 33).

The components of the AASMultiLanguagePropertyType have additional references which are defined in Table 34.

6.8.5 AASPropertyType

Figure 19 shows an overview about the AASProperty ObjectType.

The valueId attribute references a DictionaryEntry. Table 35 defines the AASProperty ObjectType.

The components of the AASPropertyType have additional references which are defined in Table 36.

6.8.6 AASCapabilityType

Table 37 defines the AASCapability ObjectType.

6.8.7 AASOperationType

Figure 20 shows an overview about the AASOperation ObjectType.

AASOperationType is defined in Table 38. It encapsulates the standard OPC UA Method “Operation”. All rules for the OPC UA Method NodeClass declaration apply. “Operation” is defined without Arguments but with the OptionalPlaceholder ModellingRule. As defined in OPC 10000-3, this rule allows the inclusion of Arguments to this Method on sub-types or on instances.

An example of a method definition is:

Signature

Method_xy_name (

)

Each individual element of the InputArgument and OutputArgument has to be referenced by a 0:HasDictionaryEntry to its semantic definition.

6.8.8 AASBlobType

Figure 21 shows an overview about the AASBlob ObjectType.

Table 39 defines the AASBlob ObjectType.

The components of the AASBlobType have additional references which are defined in Table 40.

6.8.9 AASFileType

Figure 22 shows an overview about the AASFile ObjectType.

Table 41 defines the AASFile ObjectType.

The components of the AASFileType have additional references which are defined in Table 42.

The additional reference to the real file of type 0:FileType is optional and not specified as such in the asset administration shell metamodel.

6.8.10 AASRelationshipElementType

Figure 23 shows an overview about the AASRelationElement ObjectType.

A relationship element is used to define a relationship between two referable elements (Table 43).

Objects which have the AASReferenceType shall reference another type. According to Table 43 these are the following references:

the “First” node shall reference the Referable Type instance having the role of the subject

the “Second” node shall reference the Referable Type instance having the role of the object

The components of the AASRelationshipType have additional references defined in Table 44.

Table 45 defines the AASAnnotatedRelationshipElement ObjectType.

The components of the AASAnnotatedRelationshipElementType have additional references which are defined in Table 46.

The following SubmodelElement objects are allowed for AASAnnotatedRelationshipElementType:

AASProperty

AASMultiLanguageProperty

AASRangeType

AASReferenceElementType

AASFileType

AASBlobType

6.8.11 AASReferenceElementType

Figure 24 shows an overview about the AASReferenceElement ObjectType.

An AASReferenceElement has a Reference as value (Table 47). This reference has an aggregation of keys (see Table 47) which represents a key chain. The resolved key chain points to an element.

The Object which has the AASReferenceType shall reference another type. According to Table 47 the “Value” can contain the allowed subtypes of AASSubmodelElementTypes as defined in chapter 6.3.

The components of the AASReferenceElementType have additional references which are defined in Table 48.

6.8.12 AASEventType

Figure 25 shows an overview about the AASEvent ObjectType.

Table 49 defines the AASEvent ObjectType.

6.8.13 AASEntityType

Figure 26 shows an overview about the AASEntity ObjectType.

Table 50 defines the AASEntity ObjectType.

The components of the AASEntityType have additional references which are defined in Table 51.

6.8.14 AASRangeType

If Min missing then negative open range infinitely, if max missing the open range infinitely.

Only simple data type of the OPC UA specification are allowed.

The components of the AASRangeType have additional references which are defined in Table 53.

6.9 Concept description

The AAS can define its own dictionary that contains semantic definitions of its submodel elements. These semantic definitions are called concept descriptions (ConceptDescription). It is optional whether an AAS defines its own concept dictionary (ConceptDescription) or not.

A concept description is inheriting from the predefined OPC UA IrdiDictionaryEntry or UriDictionaryEntry (Figure 27). This is why there are both ObjectTypes: “AASIrdiConceptDescriptionType” or “AASIriConceptDescriptionType” and not only one like for the other AAS classes. Additionally, for user specific dictionaries the “AASCustomConceptDescriptionType” is derived from the general OPC UA DictionaryEntryType. The semanticId is modelled by using the predefined OPC UA ReferenceType HasDictionaryEntry and is either referencing an object of type “AASIrdiConceptDescriptionType” and of type “AASUriConceptDescriptionType” or “AASCustomConceptDescriptionType”. Additionally, a concept description has at least one Add-In to allow the usage of the IEC61360 data specification template (see rules for data specifications in section 5.1 and section 6.10).

The ConceptDescription types are located under the standard OPC UA folder Dictionaries.

6.9.1 AASIrdiConceptDescriptionType

Table 54 defines the AASIrdiConceptDescription ObjectType.

The components of the AASIrdiConceptDescriptionType have additional references which are defined in Table 55.

6.9.2 AASIriConceptDescriptionType

Table 56 defines the AASIriConceptDescription ObjectType.

The components of the AASIriConceptDescriptionType have additional references which are defined in Table 57.

6.9.3 AASCustomConceptDescriptionType

Table 58 defines the AASCustomConceptDescription ObjectType.

The components of the AASCustomConceptDescriptionType have additional references which are defined in Table 59.

6.10 AAS Data Specification Templates

6.10.1 AASDataSpecificationType

Concrete data specifications are inheriting from the AAS ObjectType “AASDataSpecificationType”. The AAS attributes of DataSpecification are modelled as properties 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 (Table 60).

The concept of embedded data specifications is used. The element that is using the data specification uses the OPC ReferenceType “HasComponent”. This Add-In uses pairs of elements: one property being the global external reference to a data specification, the other one the data specification.

6.10.2 AASDataSpecificationIEC61360Type

Figure 28 shows an overview about the AASDataSpecificationIEC61360 ObjectType.

Table 61 defines the AASDataSpecificationIEC61360 ObjectType.

6.10.3 AASDataSpecificationType

The components of the AASDataSpecificationType have additional references which are defined in Table 62.

6.11 AAS Qualifiers

6.11.1 AASQualifierType

Figure 29 shows an overview about the AASQualifier ObjectType.

Table 63 defines the AASQualifier ObjectType.

The components of the AASQualifierType have additional references which are defined in Table 64.

6.11.2 AASQualifier usage

The HasDictionaryEntity of Table 63 is denoted by the complete qualifier. The ValueId of Table 63 is referencing the individual value instantiated in the Value of the AASQualifier instance. There are multiple qualifier value depending on the application domain and the application case. While the semanticId of the qualifier is fixed the semanticId of the ValueId is instance dependent. A JSON example is shown below. The “semanticId” references the AASQualifier instance itself. The "DinSpec29000QualifierType" ValueId Keys value references the “required” value semantic coming from the DIN-SEC 29000.

Note: the IRI for defining the unique semantic ids of the qualifier and its values are only examples.

"qualifiers": [

{

"semanticId": {

"keys": [

{

"type": "GlobalReference",

"local": false,

"value": "http://DINSPEC/29000/PropertyValueStatement/ExpressionSemantic",

"index": 0,

"idType": "IRI"

}

]

},

"type": "ExpressionSemantic",

"value": "REQUIREMENT_0",

"valueId": {

"keys": [

{

"type": "GlobalReference",

"local": false,

"value": " http://DINSPEC/29000/PropertyValueStatement/ExpressionSemantic/Requirement",

"index": 0,

"idType": "IRI"

}

]

},

6.12 AASViewType

Table 65 defines the AASView ObjectType.

For each AASViewType instance the semanticId is mapped to the OPC UA DictionaryEntryType. This is at instance level because the DictionaryEntry refers to the concept dictionary element which describes the individual instance not the AASView type.

The components of the AASViewType have additional references which are defined in Table 66.

7 OPC UA DataTypes

Figure 30 shows the AAS data types which are directly derived from OPC UA data types enumeration and string. The details are defined in the following sub-sections of this chapter.

7.1 AASIdentifierTypeDataType enum value definition

Table 67 defines the AASIdentifierType data type.

7.2 AASModelingKindDataType

Table 68 defines the AASModelingKindDataType data type.

7.3 AASAssetKindDataType

Table 69 defines the AASAssetKindDataType data type.

7.4 AASKey data types

The AAS metamodel knows different ways of referencing which have to be specified in the “Keys” variable used in the AASReferenceType (6.3). The “Keys” Variable is of the data type AASKeyDataType which is a structure defined in Table 70. It indicates to which type of AAS element it is referring to (AASKeyElementDataType - Table 71), if the reference refers to a local or remote element (Local), the type of the identifier of the referred element and the identifier value. The IdType is of data type AASKeyTypeDataType (Table 72).

7.4.1 AASKeyDataType

The AASKeyDataType is defined in Table 70.

7.4.2 AASKeyElementsDataType

The AASKeyElementsDataType is defined in Table 71.

7.5 AASKeyTypeDataType

The AASKeyTypeDataType is defined in Table 72.

7.6 AASCategoryDataType

The CategoryDataType is defined in Table 73.

7.7 AASValueTypeDataType

The AASValueTypeDataType is defined in Table 74.

7.8 AASPathDataType

The AASPath data type is a sub type of string and defined in Table 75.

7.9 AASMimeDataType

The enumeration of the AASMime is defined in Table 76.

7.10 AASEntityTypeDataType

The AASEntityTypeDataType is defined in Table 77.

The enumeration of the AASEntityType is defined in Table 78.

7.11 AASDataTypeIEC61360DataType

The AASDataTypeIEC61360DataType is defined in Table 79.

The enumeration of the AASDataTypeIEC61360 is defined in Table 80.

7.12 AASLevelTypeDataType

The AASLevelTypeDataType is defined in Table 81.

The enumeration of the AASLevelType is defined in Table 82.

8 Profiles and ConformanceUnits

8.1 Conformance Units

This chapter defines the corresponding Conformance Units for the OPC UA Information Model for I4AAS.

8.2 Profiles

8.2.1 Profile list

Table 84 lists all Profiles defined in this document and defines their URIs.

8.2.2 Server Facets

8.2.2.1 Overview

The following sections specify the Facets available for Servers that implement the I4AAS companion specification. Each section defines and describes a Facet or Profile.

8.2.2.2 I4AAS BaseFunction Server Server Facet

Table 85 defines a Facet that describes the basic Server functionality necessary for the I4AAS companion specification.

An AAS is a standardized digital representation of the asset, corner stone of the interoperability between the applications managing the manufacturing systems. It identifies the Administration Shell and the assets represented by it, holds digital models of various aspects (submodels) and describes technical functionality exposed by the Administration Shell or respective assets.