search

admin-shell-io / aas-specs-api

Repository of the Asset Administration Shell Specification DTA-01002 API
https://admin-shell-io.github.io/aas-specs-antora/index/home/index.html
Creative Commons Attribution 4.0 International
12 stars 5 forks source link

Asset Administration Shell Registry Service Specification - Submodel Descriptors #182

Open mjacoby opened 1 year ago

mjacoby commented 1 year ago

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 commented 1 year ago

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

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 ...

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 commented 1 year ago

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

arnoweiss commented 1 year ago

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

FrankSchnicke commented 1 year ago

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