Interactions

Interactions describe the sequence of calls of operations by a client application to achieve a defined goal in a use case. In the following, exemplary interaction sequences are depicted.

Currently, only the key use case “Access a submodel in a distributed system” with focus on a completely decentralized Industry 4.0 system or dataspace is described.

Some constraints and assumptions are made according to the configuration and qualities of the system.

Constraints and assumptions for calling an AAS and a submodel operation by a client application:

  • The calling application has to be aware that endpoints may change at any time. If the application has cached an endpoint that is no longer vivid, the application needs to start the interaction to resolve the appropriate endpoint again from the beginning.

  • Endpoints for infrastructure interfaces like AAS registries are known at design time of the client application or configured manually before start-up.

  • The asset IDs (either the global asset ID or some specific asset IDs) are known to the calling application.

  • Access to any API is allowed only if the caller is authenticated.

  • Response to any API call takes access rules as defined for the services into account, e.g. access rules for the AASs, the Submodels, or SubmodelElements within a Submodel.

An interaction typically starts with a client application using the discovery service to get the IDs of the AAS representing the asset under consideration. In the second step the AAS Registry is called to get the relevant endpoints for the AASs found. The AAS Registry provides the AAS Descriptor object belonging to this AAS ID (and thus the asset ID used for discovery) and containing the Submodel Descriptors of the Submodels, which are part of the related AAS.

As explained in Clause Descriptor, there are two ways of using the AssetAdministrationShellDescriptor when registering an Asset Administration Shell:

  1. Either add the endpoint of the Asset Administration Shell (usage by client see Figure 2)

  2. Or add the endpoints of its Submodels (usage by client see Figure 1)

There is also a third way to combine both. In this case the endpoint of the Asset Administration Shell and the information that can be retrieved at this endpoint is the master and a separate Submodel Registry would provide the Submodel endpoints as single source of truth.

Note: It is not recommended to combine the two approaches in one and the same AAS Registry. An AAS Registry either should always contain the AAS Endpoint or the AAS Endpoint should always be omitted and Submodel endpoints shall be added.

In the second case, the lookup of the Submodel IDs and the Submodel endpoints can be skipped (compare Figure 1 and Figure 2 ). No separate AAS Service or Submodel Registry Service needs to be offered to the Client. From the point of view of a data provider the Submodel Registry interfaces are still needed to add new SubmodelDescriptors to an existing AssetAdministrationShellDescriptor.

Interaction for Client Application using Submodel Endpoints
Figure 1. Interaction for Client Application using Submodel Endpoints

For accessing Submodels there are two different ways to do so:

  1. Access a Submodel via an AAS or Submodel Server

  2. Access a Submodel via a standardized Repository, either AAS or Submodel Repository

In the sequence shown in Figure 1, the first submodel is get via an AAS or Submodel interface whereas the second submodel is get via an AAS or Submodel Repository Service.

Note: The client application just uses the endpoint as provided in the Registry. Thus, for the client there is no difference in the interaction with a pure submodel server or a submodel repository server.

Figure 2 shows a sequence with a Registry providing AAS endpoints. In this case the client needs to look up the corresponding submodel IDs in an AAS or AAS Repository Service first. After looking up the relevant submodel IDs the client calls the Submodel Registry to get the Submodel Descriptors containing the endpoints of the submodels.

Note: If the AAS or AAS Repository Service is used to get the submodel IDs it is recommended that the data provider adds a "referredSemanticId" to the references of the submodels. Otherwise, it is not possible for the client to decide which of the submodels is relevant. This is typically done via the semanticId of the submodel.

Interaction for Client Application using AAS Endpoints and Repositories
Figure 2. Interaction for Client Application using AAS Endpoints and Repositories

The difference between Interface and API Operations is outlined in Figure 3. This sequence translates the interaction on the interface level of Figure 1, which is protocol-independent and therefore can be implemented in several different manners, to the specific HTTP API Operations. The generic operations are replaced with HTTP requests, e.g. “GetSubmodelById” can be realized by either “GET /shells/<aas-id>/submodels/<submodel-id>” within an AAS Repository or “GET /submodels/<submodel-id>” within a Submodel Repository. The returned objects are shortened for better readability.

Interaction for Client Application using Submodel Endpoints (for HTTP API Operations)
Figure 3. Interaction for Client Application using Submodel Endpoints (for HTTP API Operations)