Composing References to AAS/Submodels/SubmodelElements the right way

[alexgordtop]

There are Submodels that are obviously bound to an AssetAdministrationShell like DigitalNameplate. Additionally there are AAS specific instances of Submodels, that may be used multiple times within an AAS.

Think about the TimeSeries Submodel: An AAS (A1) may have one instance of TimeSeries for electrical power consumption, one for vibrations and another one for weather.

When another AAS (A2) tries to model an overview of vibrations in different parts of a bigger Asset, then it would be very helpful, to have the opportunity, to drill down to the originally monitored Asset (A1) to check other monitoring data. So a "vibration sources / overview" Submodel would explicitly reference the TimeSeries of other AASs.

My proposal would be to start references on Submodels of other AAS with the referenced AAS as first key:

{
    "keys": [
        {
            "type": "AssetAdministrationShell",
            "local": false,
            "value": "op.basyx.generic_sensor/AccelerationSensor_4711:1",
            "idType": "Custom"
        },
        {
            "type": "Submodel",
            "local": false,
            "value": "op.basyx.generic_sensor/AccelerationSensor_4711/Conf_20230320T0000:1",
            "idType": "Custom"
        }
    ]
}

As a rule of thumb:

• (RoT1) References to Submodel-Templates should start Submodel ID as first key - they have no associated AAS.
• (RoT2) References to Submodel-Instances should start AAS ID as first key - so it's clear, in which context the Submodel is referred to.
• (RoT3) References from ReferenceElements to Submodels/SubmodelElements, should include the AAS as first key.

Does the group agree with this strategy?

[alexgordtop]

Discussion in Best-Practice-Group on 2023-12-18:

• Currently this is not possible according to AASd-125.
• A new issue in aas-specs should be opened with the goal to discuss removal of AASd-125 with the specification group.

[arnoweiss]

Firstly, I don't think the json above is valid. A Key only has a type and a value field.

For your use-case, I don't understand why you're suggesting to treat Submodel-Templates and -Instances differently (in RoT1, RoT2). Submodels are globally, uniquely identifiable so a Reference to them doesn't need any context. If it's an offline use-case, the Submodel can be fetched from the submodels section of an Environment. For online use-cases, the Submodel can be fetched via the logical GetSubmodel operation (assuming endpoints are known or at least discoverable).

As correctly identified, AASd-125 is the relevant constraint here. I think it's important to have and even think it should apply to GlobalReferences too. Currently, it would be possible to chain multiple keys of type ExternalReference and I don't see the point in that.

[StenGruener]

@alexgordtop Hi Alex, did you create an issues in the https://github.com/admin-shell-io/aas-specs in the meantime which can be cross-refernced here?