Figure 10 illustrates the principal structure of submodels in the AAS standard and
the method of developing an AAS submodel for any model. The left panel displays a
simplified proprietary, that is, a nonstandard data model (named MODEL) of a
machine’s DT. Its instantiation is shown below, describing a concrete machine
m1. Only one attribute is displayed here to focus on the mechanisms of translating
this model to an AAS submodel.
The middle panel of Fig. 10 shows the simplified generic AAS model. The right
panel shows that this model is instantiated to build the given proprietary model. Each
submodel has an Internationalized Resource Identifier (IRI) [60], an idShort (often
being the last part of the IRI), descriptions (several pairs of language tags and strings
in that language are allowed), and a kind (being Type or Instance). A submodel is
composed of SubmodelElements. Different subclasses exist, such as Property, File,
and Collection (the latter are not shown).
For all attributes of the given model, an AAS Property can be added to the AAS
Submodel. A Property is a name–value pair with additional metadata. Here the
semantic annotation using its attribute semanticId is crucial for automatic interpretation. In this example, an International Registration Data Identifier to an attribute
defined by the eCl@ss [61] standard is used. The eCl@ss dictionary contains
properties for product descriptions and service descriptions based on standardized
data formats conform to IEC 61360 [62]. Alternatively, an IRI referencing a standard
property of well-known ontologies is usable (e.g., https://schema.org/identifier). A
third alternative is to use own IEC61360 conformant so-called ConceptDescriptions,
stored within an AAS.
The last attributes are valueType and value. A value can only be set if
kind ¼ Instance. This context indicates that types and their instances appear
Fig. 10 Simple AAS submodel construction sample
The Challenge of Implementing Digital Twins in Operating Value Chains
147
the method of developing an AAS submodel for any model. The left panel displays a
simplified proprietary, that is, a nonstandard data model (named MODEL) of a
machine’s DT. Its instantiation is shown below, describing a concrete machine
m1. Only one attribute is displayed here to focus on the mechanisms of translating
this model to an AAS submodel.
The middle panel of Fig. 10 shows the simplified generic AAS model. The right
panel shows that this model is instantiated to build the given proprietary model. Each
submodel has an Internationalized Resource Identifier (IRI) [60], an idShort (often
being the last part of the IRI), descriptions (several pairs of language tags and strings
in that language are allowed), and a kind (being Type or Instance). A submodel is
composed of SubmodelElements. Different subclasses exist, such as Property, File,
and Collection (the latter are not shown).
For all attributes of the given model, an AAS Property can be added to the AAS
Submodel. A Property is a name–value pair with additional metadata. Here the
semantic annotation using its attribute semanticId is crucial for automatic interpretation. In this example, an International Registration Data Identifier to an attribute
defined by the eCl@ss [61] standard is used. The eCl@ss dictionary contains
properties for product descriptions and service descriptions based on standardized
data formats conform to IEC 61360 [62]. Alternatively, an IRI referencing a standard
property of well-known ontologies is usable (e.g., https://schema.org/identifier). A
third alternative is to use own IEC61360 conformant so-called ConceptDescriptions,
stored within an AAS.
The last attributes are valueType and value. A value can only be set if
kind ¼ Instance. This context indicates that types and their instances appear
Fig. 10 Simple AAS submodel construction sample
The Challenge of Implementing Digital Twins in Operating Value Chains
147