Introduce a new Asset Administration Shell Registry Basic Profile

[sebbader-sap]

What is missing?

There are currently only three service profiles to describe an Asset Administration Shell Registry:

1. Full
2. Read
3. Bulk
4. Query
5. Minimal Read

#1 and #2 contain the Submodel Registry via the superpath concept, while #3 is intended for mass operations, #4 requires full-fledged query functionality, and #5 has no creation or update operations. It is not possible to describe an Asset Administration Shell Registry that has Asset Administration Shell Descriptors only but allows creation, read, update, and delete operation.

As therefore the Submodel Registry is implicitly contained, a client does not out-of-the-box know whether the way to a Submodel endpoint goes via Asset Administration Shell Descriptor -> endpoint -> read AAS submodel references -> Submodel Registry: Submodel Descriptor -> endpoint, or the shortcut Asset Administration Shell Descriptor -> submodelDescriptors -> endpoint .

How should it be fixed?

Add a new "Asset Administration Shell Registry - Basic Profile" (final name can be different), with these operations only:

• AAS Registry API:

  • GetAllAssetAdministrationShellDescriptors
  • GetAllAssetAdministrationShellDescriptorsByAssetType
  • PostAssetAdministrationShellDescriptor
  • GetAssetAdministrationShellDescriptorById
  • PutAssetAdministrationShellDescriptorById
  • DeleteAssetAdministrationShellDescriptorById

• Description API:

  • GetDescription

• I have signed the required Developer Certificate of Origin (DCO) already.

[mjacoby]

I can understand the problem, however, this seems to be a conscious design decision that was made in the past.
This does not mean that we cannot or should not change this, but that is related to other aspects, e.g., a very similar problem exists for AAS Registry and Submodel Registry if I'm not mistaken.

Second, shouldn't the reference type of the link AAS -> Submodel be used to determine if a submodel is available on the same server meaning if the reference is a ModelReference than I would assume that I can access the submodel within the same server as oppsed to ExternalReference which tells me it is not hosted on the server.

I am generally in favor of revising the interface definitions but I am not sure in which direction we should go as both, having only separate interfaces and no combined ones as well as having only combined ones and no separate interfaces, have valid pros and cons.