Overview Metamodel of the Asset Administration Shell

This clause gives an overview of the main classes of the Asset Administration Shell (AAS) metamodel.

Figure 1 shows the main classes to describe a single Asset Administration Shell.

An Asset Administration Shell represents exactly one asset (AssetAdministrationShell/assetInformation). Type assets and instance assets are distinguished by the attribute AssetInformation/assetKind. See Clause Core Classes for details.

In case of an Asset Administration Shell of an instance asset, a reference to the Asset Administration Shell representing the corresponding type asset or another instance asset it was derived from may be added (AssetAdministrationShell/derivedFrom). The same holds true for the Asset Administration Shell of a type asset. Types can also be derived from other types.

An asset may typically be represented by several different identification properties like the serial number, the manufacturer part ID or the different customer part IDs, its RFID code, etc. Such external identifiers are defined as specific asset IDs (AssetInformation/specificAssetId), each characterized by a user-defined name, a value, and the user domain (tenant, subject in Attribute Based Access Control). See Clause Asset Information Attributes for details. Additionally, a global asset identifier should be assigned to the asset (AssetInformation/globalAssetId) in the production and operation phase.

Asset Administration Shells, submodels and concept descriptions need to be globally uniquely identifiable (Identifiable). Other elements like properties only need to be referable within the model and thus only require a local identifier (idShort from Referable). For details on identification, see Clause Identification of Elements.

Submodels consist of a set of submodel elements. Submodel elements may be qualified by a so-called Qualifier. There might be more than one qualifier per Qualifiable.

There are different subtypes of submodel elements like properties, operations, lists, etc. See Clause Overview of Submodel Element Types for details. A typical submodel element is shown in the overview figure: a property is a data element that has a value of simple type like string, date, etc. Every data element is a submodel element (not visible in the figure but implicitly the case, since DataElement is inheriting from SubmodelElement). For details on properties, see Clause Property Attributes.

Every submodel element needs a semantic definition (semanticId in HasSemantics) to have a well-defined meaning. The submodel element might either refer directly to a corresponding semantic definition provided by an external reference (e.g. to an ECLASS or IEC CDD property definition), or it may indirectly reference a concept description (Concept Description Attributes). See Clause Matching Strategies for matching strategies.

A concept description may be derived from another property definition of an external standard or another concept description (ConceptDescription/isCaseOf). isCaseOf is a more formal definition of sourceOfDefinition, which is just text.

If a concept description is not just a copy or refinement of an external standard, the provider of the Asset Administration Shell using this concept description shall be aware that an interoperability with other Asset Administration Shells cannot be ensured.

Data specification templates (DataSpecification) can be used to define a named set of additional attributes (besides those predefined by the metamodel) for an element. The data specification template following IEC 61360 is typically used for the concept description of properties, providing e.g. an attribute "preferredName". The <<template>> dependency is used to denote recommended data specification templates. See Clause Data Specification Templates (normative) for details.

Data specification templates like the template for IEC 61360 property definitions (Part 3a) are explicitly predefined and recommended to be used by Plattform Industrie 4.0. See Clause Data Specification Templates (normative) for details. If proprietary templates are used, interoperability with other Asset Administration Shells cannot be ensured.

Besides submodel elements including properties and concept descriptions, other identifiable elements may also use additional templates (HasDataSpecification). Data specification templates are selected at design time.

Figure 2 gives a complete overview of all elements defined in the metamodel and specified in Clause Specification (normative). The UML packages reflect the structure of Clause Metamodel Specification Details: Designators. The elements of package "Core" are specified as first class citizens in Clause Core Classes, except for their imported packages: the elements of package "SubmodelElements" are specified in Clause Overview of Submodel Element Types. Elements of package "Common" are specified in Clause Common Attributes. The elements of package "Reference" are specified in Clause Referencing in Asset Administration Shells. Elements from package "Types" are specified in Clause Primitive and Simple Data Types. The only package that is not listed is "Data Specifications (Templates)" because data specifications are handled differently. Data specification templates are explained in Clause ref:data-specifications.adoc[].

Figure 3 shows the so-called environment. The environment’s purpose is to list all Asset Administration Shells, all submodels, and all concept descriptions – in other word, all identifiables within an ecosystem.