aas-core-meta V3.0RC02 🔗

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, so we can not formalize them with formalizing such external dependencies:

• AASd-006
• AASd-007

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

• AASd-012

AASd-116 is ill-defined. The type of the SpecificAssetId.value is a string, but the type of AssetInformation.globalAssetId is a Reference. The comparison between a string and a reference is not defined, so we can not implement this constraint.

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 enumerations DataTypeDef and DataTypeDefRDF and keep only DataTypeDefXsd as enumeration. Otherwise, we would have to write redundant invariants all over the meta-model because DataTypeDef and DataTypeDefRDF are 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. It is very counter-intuitive to see the type of SubmodelElementList.typeValueListElement as KeyTypes even though an invariant might specify that it is an element of AasSubmodelElements.

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

Concerning the data specifications, we embed them within HasDataSpecification instead of referencing them via a global 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.

Since the data specifications are now embedded, the following constraints became futile:

• AASd-050
• AASd-050b