Redundant information about Submodels in AAS Registry, Submodel Registry and AAS

[FrankSchnicke]

What?

An AAS contains references to its submodels. At the same time, an AAS descriptor contains submodel descriptors, thus implicitly providing information about the submodels associated with the AAS. In addition, a separate submodel registry may contain a descriptor for the same submodel. Consequently, (a) the "AAS -> Submodel" relationship information is redundant between the AAS and the AAS Registry, and (b) the "SubmodelId -> SubmodelDescriptor" information is redundant between the AAS Registry and the Submodel Registry.

This leads to the following problems:

• Inconsistent state of the "AAS -> Submodel" relationship if the submodel references of an AAS are changed but the AAS registry is not updated, and vice versa. This can happen not only due to oversight, but also due to simple timing issues, as it can't be guaranteed that the AAS & registry updates happen at the same time.
• Inconsistent state of "SubmodelId -> SubmodelDescriptor" information due to the AAS registry being updated (e.g. with a new submodel endpoint due to a deployment change) and the submodel registry not being updated and vice versa. Again, this can happen not only due to oversight, but also due to simple timing issues, as it can't be guaranteed that the AAS registry & submodel registry updates happen at the same time.

How?

Clarify where the ground truth is for "AAS -> Submodel" relationship information as well as "SubmodelId -> SubmodelDescriptor" information. From my point of view, it would be best to define a clear retrieval sequence (see figure below) and mark the use of SubmodelDescriptors in AASDescriptors as deprecated.

[alexgordtop]

Hello together,

here we have a slightly opposite opinion, that conforms more with the current specification.

Our view is, that the registry combines information from several repositories.

Keeping the stakeholders "provider", "integrator" and "operator" in mind, there will be different views on the same asset and its shells / submodels. So in the registry a user will have an aggregated view on a shell with submodels from different repositories.

So it will most possibly be more the default case, that a shell in the registry has [m] submodels, while the shell in repository A has [n] and the same shell in repository B has [o] submodels.

From implementation point of view, there will be redundant information, if a registry implementation stores the submodel descriptors inside the shell descriptor. But that I would consider a bad persistence strategy, not a specification issue.

[BirgitBoss]

Please have a look at the note in the Part 2 specification on the class AssetAdministrationShellDescriptor:

Note: the cardinality restriction for AssetAdministrationShellDescriptor/endpoint (optional: 0..*) allows a provider to skip the declaration of the location of an AssetAdministrationShell and directly point to the endpoints of the contained Submodels through the path AssetAdministrationShellDescriptor/submodelDescriptor-> SubmodelDescriptor/endpoint. A client, therefore, might decide to skip the lookup on the AssetAdministrationShell. Nevertheless, in case the information contained in the AssetAdministrationShellDescriptor deviates from the related AssetAdministrationShell, or attributes are missing, the AssetAdministrationShell is always the source of truth.

[BirgitBoss]

Our view is, that the registry combines information from several repositories.

This is also a very interesting perspective we should discuss, especially in dataspaces that allow or even request that different parties add data in form of submodels to an asset and thus its - now there is no name for it: since the asset is represented by several AAS - its AAS descriptor. In this case no single AAS Endpoint can be specified in the AAS registry (so the API specification is ok) and thus the AAS itself cannot be the source of truth... If we agree on this we need to change the note in Part 2.

Another position would be that in this case there also would be several AAS registries.

BTW: there are also cases in which no repositories are needed, just direct use an AAS endpoint or a submodel endpoint.

[BirgitBoss]

Your proposal in "How?" seems to be exactly the order that is recommended in Part 2. However, there are also "short-cuts" defined as you noted.

[FrankSchnicke]

Please have a look at the note in the Part 2 specification on the class AssetAdministrationShellDescriptor

Thanks for pointing out this remark, I somehow missed it. However, in my opinion, there's still the issue on how to ensure that the SubmodelDescriptors contained in the AASDescriptor are synchronized with the SubmodelDescriptors contained in the Submodel Registry for Submodels with the same Id. Or is it expected that the SubmodelDescriptors are only provided by the AAS Registry if it somehow ensures this internally?

[sebbader-sap]

Related to https://github.com/admin-shell-io/aas-specs-api/issues/147

[BirgitBoss]

Please have a look at the note in the Part 2 specification on the class AssetAdministrationShellDescriptor

Thanks for pointing out this remark, I somehow missed it. However, in my opinion, there's still the issue on how to ensure that the SubmodelDescriptors contained in the AASDescriptor are synchronized with the SubmodelDescriptors contained in the Submodel Registry for Submodels with the same Id. Or is it expected that the SubmodelDescriptors are only provided by the AAS Registry if it somehow ensures this internally?

Exactly, it is not expected that you provide both, an AAS Registry with submodel descriptors and a Submodel registry as stand-alone implementation providing submodel desriptors as well.