Digital Twin Submodel Details Inconsistencies related to "interface"

[eckardg]

When we compared the KITs for Digital Twin, Industry Core and PCF Exchange we detected a difference in the Submodel description for a Digital Twin, related to the attribute "interface". In the Digital Twin KIT the interface "SUBMODEL-3.0" is used, whereas in the PCF Exchange KIT another interface, "PCF-1.0.0" is used.

As the Digital Twin KIT describes a standard, or at least a recommendation, it is confusing to find a deviation in the PCF Exchange KIT that is also referring to the Digital Twin KIT.

It seems there are reasons why different "interface" types have been chosen.

In my opinion, It would be helpful to get an explanation in the Digital Twin KIT what the field "interface" means and if alternatives to "SUBMODEL-3.0" are expected and how they should be handled.

In addition, the PCF Exchange KIT should then explain why a different "interface" has been chosen and what it actually means.

What do you think?

[arnoweiss]

I think the answer is that the PCF use-case only uses a subsection of Digital Twin Kit. The difference in submodelDescriptors[i]/endpoints[j]/interface actually makes sense here. An example from the DT-Kit:

        {
          "interface": "SUBMODEL-3.0",
          "protocolInformation": {
            "href": "https://edc.data.plane/mypath/submodel",
            "endpointProtocol": "HTTP",
            "endpointProtocolVersion": [
              "1.1"
            ],
            "subprotocol": "DSP",
            "subprotocolBody": "id=123;dspEndpoint=http://edc.control.plane/api/v1/dsp",
            "subprotocolBodyEncoding": "plain",
            "securityAttributes": [
              {
                "type": "NONE",
                "key": "NONE",
                "value": "NONE"
              }
            ]
          }
        }

Here, the interface signifies that the data can be accessed via the API SUBMODEL-3.0 leveraging the fields in the protocolInformation object. This API is defined by the SubmodelServiceSpecification, yielding for example the plain-key-value-json representation when appending the $value. That's how the API works.

However, the PCF use-case works differently. They use the data in the protocolInformation to access data thats behind their own API. The descriptor merely provides the link to the specificAssetIds from the Industry Core.

[arnoweiss]

The AAS-spec obviously is opinionated on how a Submodel should be retrieved - via the Submodel API. It does provide a safe path to use other APIs as well but will not recommend them. That's the duty of the standards "borrowing" the concept of the Digital Twin Registry without the Submodel-API, like CX - 0136 does in this case.

[matgnt]

Question remains: what is the benefit of having an entry for this in the registry?
Seems the API behaves different and also searching seems to be done via the Catalog (not registry) before, right?

[arnoweiss]

True, the only information in a shell-descriptor that's currently not represented in the dcat:Catalog is the link to the globalAssetId or specificAssetIds. One could perhaps standardize properties on dcat:Dataset objects that take care of this but I'm not entirely sure.

[matgnt]

I don't know the use case in detail, but when I look into the KIT and the API spec there, it looks to me like it is a generic API and thus, what I would use in the registry to search, I also use as query params with the generic API endpoint:
https://eclipse-tractusx.github.io/docs-kits/next/kits/PCF%20Exchange%20Kit/Software%20Development%20View/pcf-exchange-api/get-pcf
Namely, the so called productId and the BPN

Do we have a real example of how the href of such a submodel would look like and how it is called?

[matgnt]

Here is a good overview in the KIT
https://eclipse-tractusx.github.io/assets/images/EDCDiscoveryanddDTRAccess-8595824d52ff5f5589ac9b4da5ea8b32.png

So yes, it might make sense, IF there are other submodels registered for the same AAS (Twin) I guess AND you start searching from the AAS view. If not, I think the sense of this indirection is questionable. Probably it is like that, because it 'has to be' like that.

I'll put this aside now from my perspective. I'm not part of the use case.