Best Practice for Nesting Administration Shells

[MichaelHoerning]

Is there a best practice for creating a system of shells?
I want to have a shell for each of my devices and these should be aggregated under a parent shell of my system, where the devices are built into. These structure should be searchable like registry.

The submodel "VDMA VWS für Roboter" in the document "VWS in der Praxis" shows a topology submodel which uses ReferenceElement to refer to the sub-shells. Has this been tested?

[BirgitBoss]

In V2.0 special submodel elements were introduced to be able to model so-called "bill of materials" (attribute from Asset in V2.0 or AssetInformation in V3.0RC01): Entity that can be either co-managed or self-managed (if it has its own AAS). Relationships between the entities are modelled via RelationshipElements.

The aasx package explorer provides some aasx examples for modeling bill of materials together with plugins for graphical representation.
These examples can be used as basis for answering the question in the Q&A.

[BirgitBoss]

see also answer in admin-shell/aasx-package-explorer#35

[StenGruener]

revisit 14.06. :
When do I need BOM, vs using references to external AASs and Submodels (which relationship types).
- BOM way: dedicated submodel with self- or co-managed assets
-- Self-managed assets have own asset ID which can be queried for AAS
-- Scope of BOM: relations between assets and not AASs, BOM submodel defies "isPartOf" or "isIdentical" as relation types
-- Advantage: BOM-AAS is self-contained
-- Disadvantage: "resolution-infrastructure" is needed
- Direct references to external AASs and Submodels
-- Not recommended at the moment (contact us in case you have a generalizable use-case for this mechanism)