Home » Eclipse Projects » Eclipse Semantic Modeling Framework (ESMF) » What is the relationship between ESMF and AAS?
What is the relationship between ESMF and AAS? [message #1860966] |
Tue, 12 September 2023 12:22 ![Go to next message Go to next message](https://www.eclipse.org/forums/theme/Solstice/images/down.png) |
Andreas Textor![Friend of Eclipse Friend](https://www.eclipse.org/donate/web-api/friends_decorator.php?email=Andreas.Textor%40de.bosch.com) Messages: 2 Registered: January 2023 |
Junior Member |
|
|
What are ESMF, IDTA, AAS, SAMM?
- ESMF: The Eclipse Semantic Modeling Framework (ESMF) is a sub-project of the Eclipse Digital Twin project which is driven by the Industrial Digital Twin Association (IDTA). In the ESMF, the Semantic Aspect Meta Model (SAMM) and corresponding tooling is developed. See the ESMF project page for a more detailed explanation.
- IDTA: The IDTA develops, maintains and publishes [1] specifications that describe the Asset Administration Shell (AAS) ecosystem, such as its meta model, exchange formats and APIs.
- AAS: Quoting from the AAS Reading Guide:
Quote:TThe Asset Administration Shell (AAS) is the digital representation of an asset. The AAS consists of a number of submodels in which all the information and functionalities of a given asset including its features, characteristics, properties, statuses, parameters, measurement data and
capabilities can be described.
- SAMM: The Semantic Aspect Meta Model (SAMM) specifies how Aspect Models can be created, which are formal (machine readable) semantic descriptions of the aspects of a digital twin (which can represent an asset, or an abstract concept such as a service).
What is the relationship between AAS and ESMF?
Both AAS and and ESMF define a meta model (the AAS Meta Model [2] and SAMM [3], respectively).
Although they have overlapping goals, they differ in scope, expressiveness and technical implementation. On a high level, the AAS meta model can be used to describe digital twins for assets, with properties of the asset/twin itself, and separate submodels or submodel templates. SAMM Aspect Models conceptually correspond to AAS submodel templates: They do not describe an asset or twin itself, but "only" a certain slice of information adjacent to the twin (hence the name Aspect Model). Also, Aspect Models explictly model data but don't contain data. This data - which therefore corresponds to "value only" payloads in AAS terminology - is semantically described by an Aspect Model. In terms of expressiveness, SAMM is a cross between ontology modeling languages such as OWL and UML-based modeling formalisms such as the AAS metamodel. It aims for deep expliclit semantic modeling by imposing the concept of Characteristics for making the meaning of properties explicit, reusable and referrable. Context and meaning of values is made explicit using various value constraints and context information such as physical units and quantity kinds.
In short, AAS can be used to create models that provide a comprehensive view on an asset and its submodels, while SAMM Aspect Models describe one part (Aspect) of a digital twin semantically. Depending on the requirements, either can be used on its own. However, to get the best of both worlds, the AAS meta model concept of data specifications can be used to link AAS submodel elements with a SAMM identifier that further describes this element's semantics in detail. This way, you retain the interoperability and comprehensive model of the asset and its submodels and additionally the rich semantic description using SAMM. This works today.
The details for using SAMM Aspect Models (or fragments of Aspect Models) as embedded data specifications in AAS, i.e., to have a self-contained AAS model that already comes with the semantic description, are being worked out by the respective IDTA working groups. This effort includes both defining how the Aspect Model (fragments) are to be included in an AAS model (including referencing of identifiers), and enhancing the SAMM meta model and Characteristic catalog to be able to express the concepts from AAS in a way that enables bi-directionality. For the latter parts, work-in-progress is captured in the SAMM wiki [4].
[1] https://industrialdigitaltwin.org/en/content-hub/downloads
[2] https://industrialdigitaltwin.org/en/wp-content/uploads/sites/2/2023/04/IDTA-01001-3-0_SpecificationAssetAdministrationShell_Part1_Metamodel.pdf
[3] https://eclipse-esmf.github.io/samm-specification/2.1.0/index.html
[4] https://github.com/eclipse-esmf/esmf-semantic-aspect-meta-model/wiki/AAS-SAMM-features
[Updated on: Thu, 14 September 2023 09:14] Report message to a moderator
|
|
|
Re: What is the relationship between ESMF and AAS? [message #1861072 is a reply to message #1860966] |
Mon, 18 September 2023 11:59 ![Go to previous message Go to previous message](https://www.eclipse.org/forums/theme/Solstice/images/up.png) ![Go to next message Go to next message](https://www.eclipse.org/forums/theme/Solstice/images/down.png) |
Hossein Rimaz![Friend of Eclipse Friend](https://www.eclipse.org/donate/web-api/friends_decorator.php?email=mhrimaz%40yahoo.com) Messages: 2 Registered: September 2023 |
Junior Member |
|
|
However, the added value remains unclear. When you talk about "semantically describing the digital twin", what you mean exactly? Would you have any use cases that we cannot solve with the AAS metamodel and its submodels?
AAS already provides RDF representation and the serialization between xml-json-rdf is already in the scope. So you have the freedom to use that RDF representation. The ontology and relationship between elements of metamodel already exists (aas-ontology-rdf [7]), and you can also validate it against metamodel SHACL rules which is also provided (aas-shacl-schema [8]). So you can use that representation and connect it to external ontology such as QUDT ontology [2] for unit of measurements. Or you can simply query it with SPARQL. For submodel templates you can create your own SHACL schema to validate it and check the constraints. If you have an external ontology, you can map the elements of your submodel and create ABox instances with a custom parser or RML mappers. And you can leverage Rule-based and Ontology-based reasoners at the end [1].
Therefore, in my view, under the same project name (Eclipse Digital Twin), two parallel activities are ongoing, which is confusing for me. When I look at projects like Catena-X [5], everything is described using Aspect models. AAS (aasx) is a side artifact generated via SAMM-CLI, which cannot be opened in the AASX Package Explorer V3 2023-09-12 [6] because it is invalid. Therefore, I feel that Bosch wants to push his own toolset, and SAMM is going to replace and rule the AAS.
In my view many things seems duplicate/equivalent:
Aspect Model Editor (create aspect model) -> AASX Package Explorer (create submodel template)
Aspect Model -> Submodel Template
SAMM units [3], and unit catalog [4] -> ConceptDescription & QUDT [2]
SAMM constraints [5] -> SHACL
Regards,
Hossein
[1] Y. Huang, S. Dhouib, L. P. Medinacelli and J. Malenfant, "Semantic Interoperability of Digital Twins: Ontology-based Capability Checking in AAS Modeling Framework," 2023 IEEE 6th International Conference on Industrial Cyber-Physical Systems (ICPS), Wuhan, China, 2023, pp. 1-8, doi: 10.1109/ICPS58381.2023.10128003.
[2] QUDT Ontology https://doi.org/10.25504/FAIRsharing.d3pqw7
[3] https://eclipse-esmf.github.io/samm-specification/snapshot/units.html
[4] https://eclipse-esmf.github.io/samm-specification/snapshot/appendix/unitcatalog.html
[5] https://github.com/eclipse-tractusx/sldt-semantic-models/tree/main/io.catenax.battery.battery_pass/3.0.1
[6] https://github.com/admin-shell-io/aasx-package-explorer/releases/tag/v2023-09-12.alpha
[Updated on: Thu, 21 September 2023 13:11] Report message to a moderator
|
|
|
Re: What is the relationship between ESMF and AAS? [message #1861099 is a reply to message #1861072] |
Wed, 20 September 2023 13:38 ![Go to previous message Go to previous message](https://www.eclipse.org/forums/theme/Solstice/images/up.png) ![Go to next message Go to next message](https://www.eclipse.org/forums/theme/Solstice/images/down.png) |
Andreas Textor![Friend of Eclipse Friend](https://www.eclipse.org/donate/web-api/friends_decorator.php?email=Andreas.Textor%40de.bosch.com) Messages: 2 Registered: January 2023 |
Junior Member |
|
|
Hi Hossein,
this is a well-reasoned post and you are correct in many regards! Allow me to try to address the single points:
Quote:
However, the added value remains unclear. When you talk about "semantically describing the digital twin", what you mean exactly? Would you have any use cases that we cannot solve with the AAS metamodel and its submodels?
Comparison: How are semantics expressed in AAS, SAMM Aspect Models and OWL? Where are the differences?
- In SAMM Aspect Models, domain semantics are expressed by explicitly named and referenceable Characteristics.
- In OWL, domain semantics are expressed by class restrictions, subclass relationships and subproperty relationships.
- In AAS, domain semantics are expressed by data specificiations and concept descriptions, i.e., references to externally defined vocabularies, taxonomies or standards.
To give a feeling what this exactly means, let us consider a simple example which is based on a subset of a real-world use case. The "Battery Pass" use case in Catena-X contains an eponymous SAMM Aspect Model which models, among other things, a battery and three of its properties: minVoltage, maxVoltage and nominalVoltage. There are two parts to the domain semantics here: There are the properties themselves and what they mean in the context, and there is the fact that the properties talk about the concept of voltage, which implies a numeric datatype. Furthermore, the unit their values are given in needs to be made explicit - is it volt, millivolt or something different altogether? In the Aspect Model, the concept of voltage - the thing the properties talk about - is explicitly named. It can have human readable name and descriptions in multiple languages and most importantly, it has an identifier and can be referenced. This allows modelers in the scope of the same domain - or even across domains, in case of generally applicable Characteristics - to reuse this concept, to refer to this exact concept. Aspect Models require every property to explicitly refer to a Characteristic, so modelers are not only encouraged, but forced, to make a property's semantics explicit. The following image shows the corresponding part of the BatteryPass Aspect Model as shown in the Aspect Model Editor.
![index.php/fa/43522/0/](https://www.eclipse.org/forums/index.php/fa/43522/0/)
The Characteristic is the embodiment of the domain semantics that goes beyond the datatype and the property or properties that use it. Being a measurement, the VoltCharacteristic also contains the reference to the physical unit. Note that all additional information on the unit, such as its symbol and common code, are not modeled in the Aspect Model, but are provided by SAMM's unit catalog. The Aspect Model Editor conventiently displays such information inline. For another example on Characteristics, think about a model of a device that has two properties called serialNumber and consistsOfParts (pointing to a list of other serialNumbers). You'd model the SerialNumber Characteristic once - because that is the concept both properties talk about - and use it in the defintions of both properties. It's not the same thing as a data type - the data type is just string.
How could we express this part of the Battery Pass model in OWL? Firstly, we'd create OWL Datatype Properties for minVoltage, maxVoltage and nominalVoltage. To express the fact that they all talk about the concept of voltage, you'd be inclined to create a superproperty called voltage that they inherit from:
:voltage a owl:DatatypeProperty .
:minVoltage a owl:DatatypeProperty ;
rdfs:subPropertyOf :voltage .
:maxVoltage a owl:DatatypeProperty ;
rdfs:subPropertyOf :voltage .
:nominalVoltage a owl:DatatypeProperty ;
rdfs:subPropertyOf :voltage .
However, one should be aware of what OWL semantics actually imply here; if you'd have an instance of the battery with our three properties asserted, an OWL reasoner supporting the SubDataPropertyOf axiom would infer multiple "voltage" assertions, which is technically correct but is not at all helpful in applications:
:battery01 :minVoltage "5.0"^^xsd:float ;
:maxVoltage "12.0"^^xsd:float ;
:nominalVoltage "6.0"^^xds:float .
# the above also implies the following:
:battery01 :voltage "5.0"^^xsd:float,
"12.0"^^xsd:float,
"6.0"^^xsd:float .
There are not many alternative ways to this to express the concept of voltage here. One alternative would be the creation of a voltage individual and relating it using an OWL Annotation Property:
:voltage a owl:NamedIndividual .
:characteristic a owl:AnnotationProperty .
:minVoltage a owl:DatatypeProperty ;
:characteristic :voltage .
# .. and so on
Unfortunately, this mixes up model and data levels and such a use of an annotation property is a statement outside of actual OWL semantics, it makes this statement invisible to a reasoner. This means additional modeling rules _on top of_ OWL semantics would be required to sufficiently enforce rigorous modeling. Expression of and relating properties with units has a very similar problem.
Now, how could the example look like using "pure" AAS? You'd first create a submodel or submodel template that contains the three property submodel elements minVoltage, maxVoltage and nominalVoltage. We'd want to use ConceptDescriptions to have the properties point to a given suitable description of the concept voltage. Let's assume there is a suitable referenceable element representing this concept, for example via an IRI in a well-known ontology or RDF vocabulary or via an IRDI in ECLASS, so we refer to its identifier as ConceptDescription.
This leads to two problems: Firstly, it could be difficult for other AAS authors to find the concept for reusing it in other AAS models, since it's identified by its external ID, not by a semantic ID. Unless you already exactly know the concept and its ID, you wouldn't know it, even if you indexed and searched through IDs of elements of published admin shells. Secondly, how are tool authors going to make use of the concept description in a portable way? They need to know and support (i.e., load, parse, evaluate) the formalism the referenced concept description is defined in. This is were SAMM can step in: If it's a first class citizen in the AAS tool landscape, evaluation of concept descriptions needs not longer be a random encounter.
Quote:
AAS already provides RDF representation and the serialization between xml-json-rdf is already in the scope. So you have the freedom to use that RDF representation. The ontology and relationship between elements of metamodel already exists (aas-ontology-rdf [7]), and you can also validate it against metamodel SHACL rules which is also provided (aas-shacl-schema [8]). So you can use that representation and connect it to external ontology such as QUDT ontology [2] for unit of measurements.
External references via concept descriptions are a powerful tool, but neither tool developers nor users can and should rely on semantic descriptions in "arbitrary" context that are linked to from your admin shell. Let's assume I follow your advice and add links to units defined in QUDT. But my colleague in another department happens to prefer the QUDV ontology instead. Then a customer comes along and claims "I'd like to refer to units in the GNU Units catalog". And so on. Every such link is perfectly valid on its own, but with a hodgepodge of definitions and such a large degree of freedom, it's impossible to build interoperable tooling that can reasonably well make use of the units (other than just displaying it, that is). By recommending/using SAMM Aspect Models for the semantic description linked from AAS elements (as a first choice), this problem could be reduced. The huge difference to, let's say, ISO or the UNECE Rec 20 itself, is that ESMF being a sister project in the Eclipse Digital Twin Project, will actively work towards a good solution and will make adjustments and developments as necessary. Note that works regardless of which format or serialization is used for the AAS (although RDF-based format makes things nice on a technical level :))
Quote:
Therefore, in my view, under the same project name (Eclipse Digital Twin), two parallel activities are ongoing, which is confusing for me.
You are correct in that they are parallel activities, but they don't mean to compete, but rather complement each other. I hope the posts in this thread help here.
Quote:When I look at projects like Catena-X [5], everything is described using Aspect models. AAS (aasx) is a side artifact generated via SAMM-CLI, which cannot be opened in the AASX Package Explorer V3 2023-09-12 [6] because it is invalid.
Yes, SAMM-CLI can create AASX packages in the form of a general outline (they will not be 100% semantically identically due to the differences in AAS meta model and SAMM). However, if the package can not be opened in the AASX Package Explorer, this is actually due to differences in the implementations and reading of the AAS spec in AASXE and AAS4J, which is yet another Eclipse Digital Twin subproject and which is used inside SAMM-CLI to create AASX (but which is not used in the AASXE). We encountered this also recently (while reading models created with AASXE using AAS4J), please refer to the issue. This is unfortunate, but should be considered purely a technical problem, not in any way intentional.
Quote: Therefore, I feel that Bosch wants to push his own toolset, and SAMM is going to replace and rule the AAS.
Although the initial contribution of SAMM (formerly known as BAMM, BAMM Aspect Meta Model) was done by Bosch more than two years ago (at the time in the Open Manufacturing Platform), neither the meta model nor its tooling belongs to Bosch. We went to great lengths to contribute specifications and SDKs in multiple programming languages in the scope of proper open source projects under the aegis of the Eclipse Foundation. SAMM is not going to replace or rule AAS since they have a very different scope, as explained in my last post. All of the ESMF projects are open for contributions: This includes bug reports, discussions, feature requests and of course also code contributions.
[Updated on: Wed, 20 September 2023 13:50] Report message to a moderator
|
|
|
Re: What is the relationship between ESMF and AAS? [message #1861118 is a reply to message #1861099] |
Thu, 21 September 2023 13:49 ![Go to previous message Go to previous message](https://www.eclipse.org/forums/theme/Solstice/images/up.png) |
Hossein Rimaz![Friend of Eclipse Friend](https://www.eclipse.org/donate/web-api/friends_decorator.php?email=mhrimaz%40yahoo.com) Messages: 2 Registered: September 2023 |
Junior Member |
|
|
Thanks for your elaborate explanation. Some things still not clear for me, but I think this would be helpful for others too.
Hopefully, with more documentation, examples, youtube videos, etc, it would get more clear. I would suggest to setup a community meeting, similar to IDTA open hours, or BaSyx open hours. There can be presentations, Q/A, discussion, ... which would be really helpful.
Quote:Let's assume I follow your advice and add links to units defined in QUDT. But my colleague in another department happens to prefer the QUDV ontology instead. Then a customer comes along and claims "I'd like to refer to units in the GNU Units catalog".
I guess we cannot force everyone to use SAMM and its unit catalog either, right? If we can, then there is no interoperability issue to be solved. Either manually, like QUDT, for example, we provide an external link to other ontologies that define the same concept, or automatically, via ontology matching, repair, etc.. For example, in the automotive industry and the Catena-X network, people agreed to use SAMM, but for other sectors, we cannot force any choice. Therefore, if we really want to solve interoperability issues, we should focus on aligning the terms in different ontologies such as QUDT, QUDV, and SAMM Units. This is the end goal and the ultimate interoperability. Right?
Quote:This is were SAMM can step in: If it's a first class citizen in the AAS tool landscape, evaluation of concept descriptions needs not longer be a random encounter.
And when SAMM is a first class, what would be the future workflow?
1: We model the digital twin using Aspect Model Editor, then use SAMM-CLI to generate AAS (AASX), which contains all the information of digital twin in AAS + links to SAMM aspect models as a complement
2: We model the digital twin using Package Explorer and semantically enhance it with Aspect Model Editor (with least duplicate work), and then we can link our submodel to its SAMM aspect.
Regards,
Hossein
|
|
|
Goto Forum:
Current Time: Sat Nov 11 05:59:03 GMT 2023
Powered by FUDForum. Page generated in 0.01975 seconds
|