Problem / Motivation
When generating AASX packages programmatically, it is unclear what a "standard" minimal-yet-complete AASX package should look like when it contains multiple submodels (e.g., Digital Nameplate + Technical Data + additional submodels).
I can create individual submodels, but I’m missing a canonical reference for:
- how the AAS should reference/link to multiple submodels in the AAS Environment (XML),
- how ConceptDescriptions and semantic references should be handled (embedded vs external references),
- what the recommended minimal AASX package layout should include besides the AAS environment file,
- what the minimal “complete” closing structure is for the environment/package.
Request
Could IDTA provide (or reference) a normative or at least officially recommended example AASX package that includes:
- 1 AAS
- 2–3 submodels (e.g., Digital Nameplate + Technical Data + one more optional)
- (optional) ConceptDescriptions (at least one example embedded in-package)
- (optional) an external file (PDF/datasheet) referenced from a submodel element
Preferably:
- Provided as a downloadable
.aasx (not only screenshots)
- Paired with the corresponding AAS Environment XML (
.xml) and a short explanation of:
- how the AAS references submodels (submodel references)
- how semanticId is represented for each submodel
- how package relationships are expected to be set up
Expected Outcome
A canonical sample would make it much easier to implement reliable AASX generation pipelines and to validate interoperability across tools (AASX Package Explorer, BaSyx, etc.).
Problem / Motivation
When generating AASX packages programmatically, it is unclear what a "standard" minimal-yet-complete AASX package should look like when it contains multiple submodels (e.g., Digital Nameplate + Technical Data + additional submodels).
I can create individual submodels, but I’m missing a canonical reference for:
Request
Could IDTA provide (or reference) a normative or at least officially recommended example AASX package that includes:
Preferably:
.aasx(not only screenshots).xml) and a short explanation of:Expected Outcome
A canonical sample would make it much easier to implement reliable AASX generation pipelines and to validate interoperability across tools (AASX Package Explorer, BaSyx, etc.).