aas-core-meta V3.0 🔗

Provide an implementation of the Asset Administration Shell (AAS) V3.0.

The presented version of the Metamodel is related to the work of aas-core-works, which can be found here: https://github.com/aas-core-works.

The presented content is neither related to the IDTA nor Plattform Industrie 4.0 and does not represent an official publication.

We diverge from the book in the following points.

We did not implement the following constraints as they are too general and can not be formalized as part of the core library, but affects external components such as AAS registry or AAS server:

We did not implement the following constraints since they depend on registry and de-referencing of Reference objects:

Some constraints are not enforceable as they depend on the wider context such as language understanding, so we could not formalize them:

  • AASd-012: This constraint requires that the texts inside Multi_language_property shall have the same meanings in the separate languages. This cannot be tested.

  • AASd-116: In the book, AASd-116 imposes a case-insensitive equality against globalAssetId. This is culturally-dependent, and depends on the system settings. For example, the case-folding for the letters "i" and "I" is different in Turkish from English.

    We implement the constraint as case-sensitive instead to allow for interoperability across different culture settings.

Furthermore, we diverge from the book in the following points regarding the enumerations. We have to implement subsets of enumerations as sets as common programming languages do not support inheritance of enumerations. The relationship between the properties and the sets is defined through invariants. This causes the following divergences:

  • We decided therefore to remove the enumeration DataTypeDefRDF and keep only DataTypeDefXsd as enumeration. Otherwise, we would have to write redundant invariants all over the meta-model because DataTypeDefRDF is actually never used in any type definition.

  • The enumeration AasSubmodelElements is used in two different contexts. One context is the definition of key types in a reference. Another context is the definition of element types in a SubmodelElementList.

    To avoid confusion, we introduce two separate enumerations for the separate contexts. Firstly, a set of KeyTypes, AasSubmodelElementsAsKeys to represent the first context (key type in a reference). Secondly, the enumeration AasSubmodelElements is kept as designator for SubmodelElementList.typeValueListElement.

  • The specification introduces several types of Lang_string_set. These types differ between the allowed length of their text inside the singular Lang_string objects. Since the native representation of Lang_string_set as List of Lang_string is required by specification, it is impossible to introduce separate Lang_string_set types. Therefore, the distinction is drawn here between the Lang_string types.

    DefinitionTypeIEC61360 is represented as a List of LangStringDefinitionTypeIec61360

    MultiLanguageNameType is represented as a List of LangStringNameType

    PreferredNameTypeIEC61360 is represented as a List of LangStringPreferredNameTypeIec61360

    ShortNameTypeIEC61360 is represented as a List of LangStringShortNameTypeIec61360

    MultiLanguageTextType is represented as a List of LangStringTextType

    Furthermore, since Lang_string is not used anywhere, we rename it to AbstractLangString.

Concerning the data specifications, we embed them within HasDataSpecification instead of referencing them via an external reference. The working group decided to change the rules for serialization after the book was published. The data specifications are critical in applications, but there is no possibility to access them through a data channel as they are not part of an environment.