Asset Administration Shell Registry Service Specification - Submodel Descriptors

[mjacoby]

The specification defines the Asset Administration Shell Registry Service Specification as combination of the APIs Asset Administration Shell Registry API and Submodel Registry API where the first provides CRUD functionality on AssetAdministrationShellDescriptors while the latter provides CRUD functionality on SubmodelDescriptors.

From a purely technical perspective, I would expect the combined APIs to work similar to when the APIs are used as stand-alone.
However, as the classes AssetAdministrationShellDescriptor and SubmodelDescriptor are interrelated, i.e. an AssetAdministrationShellDescriptor containing a number of SubmodelDescriptors, a user would probably expect a different behavior.

Consider the following example:

A user has an Asset Administration Shell A with Submodel X and Submodel Y. He now creates an AssetAdministrationShellDescriptor for AAS A containing two SubmodelDescriptors for X and Y and posts this to a combined API using the PostAssetAdministrationShellDescriptor operation.
After that, the user executes the GetAllSubmodelDescriptors from the Submodel Registry API. Obviously, the user would expect to get back the SubmodelDescriptors for X and Y which has just been posted in the previous call. However, if the implementation follows the purely technical idea that the combined API behaves just as the two separate APIs, the result would be empty.

Therefore, my question is what is the expected behavior of Asset Administration Shell Registry Service Specification? Should both contained APIs share the same data or be completely independent? If it is the latter, then what benefit does having a combined API/service provide? If it is the former, this would raise even more questions on expected behavior e.g. when deleting submodels (cascading deletes).

[sebbader-sap]

A) strictly separated AAS-Registry and SubmodelRegistry

1. Client posts AAS-Descriptor incl. at least one SubmodelDescriptor
2. AAS-Registry contains now one AAS-Descriptor and one SubmodelDescriptor
3. SubmodelRegistry is still empty
4. Client deletes AAS-Descriptor
5. Both Registries are now empty

• Pro: Exactly same pattern can be used even if the AAS Registry and SubmodelRegistry are separate services

B) Conveniently combined Registries

1. Client posts AAS-Descriptor incl. at least one SubmodelDescriptor
2. AAS-Registry contains now one AAS-Descriptor and one SubmodelDescriptor
3. SubmodelRegistry contains one SubmodelDescriptor
4. Client deletes AAS-Descriptor
   5.a AAS-Registry is empty, SubmodelRegistry contains one SubmodelDescriptor , or
   5.b Both Registries are now empty if no other AAS Descriptor uses this SubmodelDescriptor, or
   5.c ...

• Pro: Less interactions for the client.
• Con: Unclear behaviour of the Registry

B') Conveniently combined Registries (but SubmodelDescriptor exists already)

1. Client posts AAS-Descriptor incl. at least one SubmodelDescriptor
2. old SubmodelDescriptor has same id but at least one different attribute
3. What happens???

[sebbader-sap]

Proposal 1:
AAS Descriptors can only reference SubmodelDescriptors, not contain.
(READ can also give the complete data back / resolve references before response)

[arnoweiss]

Proposal 1: AAS Descriptors can only reference SubmodelDescriptors, not contain. (READ can also give the complete data back / resolve references before response)

This would require Data Providers to deploy both and introduces an additional hop in the AAS-Discovery Sequence.

Proposal 2:

Deprecate

• SubmodelRegistryServiceSpecification,
• SubmodelServiceSpecification,
• AssetAdministrationShellServiceSpecification,
• AssetAdministrationShellRepositoryServiceSpecification

[FrankSchnicke]

I would like to point out two issues where I raised the same questions to ensure that the discussion there is not lost:

• Redundant information about Submodels in AAS Registry, Submodel Registry and AAS #114
• Unclear expected resolution behavior of superpaths for AAS Registry Interface #115