You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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:
As a rule of thumb:
Does the group agree with this strategy?
The text was updated successfully, but these errors were encountered: