Asset Administration Shell Submodels in Practice (2026 Guide)

Last Updated: October 2026

If you want a vendor-neutral digital twin, the shell is not where the work happens. The Asset Administration Shell (AAS) itself carries little more than identity and a list of pointers. Every fact a consumer actually wants, such as the rated voltage, the manual, the carbon footprint, lives in a submodel. This guide is about asset administration shell submodels 2026 style: what the Industrial Digital Twin Association (IDTA) has standardized, what the current specification line looks like, and where real exchanges between two vendors still fail.

The timing matters. The AAS specification family moved to Release 26-01 in July 2026, with the metamodel at v3.2 and the API at v3.2. At the same time the EU Digital Product Passport (DPP) is turning submodel templates from a nice-to-have into a compliance input, with battery passports mandatory from February 2027. You will leave with a working mental model of the submodel layer, a way to choose between published templates and custom ones, and a checklist of the mistakes that make a “standard” twin unreadable by anyone else.

What this covers: the metamodel mechanics of a submodel, the templates that matter and how they are structured, AASX packaging and the REST API, deployment patterns, the failure modes, and a practical adoption checklist.

Context and Background

The AAS is the standardized digital representation of an asset, specified by the IDTA as a multi-part document series and standardized internationally as the IEC 63278 family (the IEC number is cited here from general knowledge and was not re-verified for this article). The IDTA’s specification hub lists six parts in Release 26-01: Part 1 Metamodel (IDTA-01001, v3.2.0), Part 2 Application Programming Interfaces (IDTA-01002, v3.2.0), Part 3a IEC 61360 data specification (IDTA-01003-a, v3.1.1), Part 3b measurement units (IDTA-01003-b, v3.0), Part 4 Security (IDTA-01004, v3.1.0), and Part 5 AASX package file format (IDTA-01005, v3.2). Drafts of v3.3 for Parts 1, 2 and 5 are visible as work in progress.

That version picture matters because many articles, including an earlier edition of this one, still quote metamodel v3.1.1. The metamodel GitHub repository shows v3.1.0 in May 2025, v3.1.1 in August 2025 and v3.1.2 in October 2025, and the v3.2 line carries a July 2026 notice. For the migration detail on what changed between those lines, read our AAS metamodel 3.2 migration guide. This article stays one layer up, at the submodel level.

Why does the submodel layer decide interoperability? Because the metamodel is deliberately small and generic. It gives you a closed vocabulary of element types, a referencing scheme and a serialization. It cannot tell you what a “rated voltage” is or how a maintenance manual should be classified. Templates do that. The IDTA publishes templates through a review process, assigns each an IDTA number, and hosts them in the public submodel-templates repository, licensed CC-BY-4.0. Published templates live in a published folder, and older versions move to deprecated six months after a successor appears, according to the repository README.

If you are weighing the AAS against other information modeling approaches, our AAS vs DTDL vs OPC UA comparison covers the trade-offs. If you need the system-level picture first, start with the AAS reference architecture. For a hands-on server, the Eclipse BaSyx tutorial shows how to host these submodels.

The Anatomy of a Submodel: Reference Architecture

Short answer: an AAS submodel is a self-describing container of typed submodel elements, such as properties, lists, collections and files, that covers one aspect of an asset. A submodel template fixes the structure, cardinalities and semantic IDs so the same data means the same thing across vendors, tools and repositories.

Figure 1: The shell holds identity and references to submodels. Each submodel is a tree of submodel elements, and each element points through its semanticId into a shared dictionary such as IEC CDD or ECLASS.

Figure 1 is the containment model you integrate against. The shell has an identifier, an asset reference and a list of submodel references. The submodels hold everything else. Because the shell does not embed submodels, different parties can host them in different places: the manufacturer might host the nameplate while the operator hosts the live operating data, and the shell simply references both.

Submodel element types

The metamodel defines a closed set of submodel element types. From the v3 line of the metamodel (listed here from general knowledge and not re-verified against v3.2), they are Property, MultiLanguageProperty, Range, File, Blob, ReferenceElement, RelationshipElement, AnnotatedRelationshipElement, Entity, Operation, Capability, BasicEventElement, SubmodelElementCollection (SMC) and SubmodelElementList (SML). The v3.2 specification’s table of contents lists “Submodel Element Types” as its own normative section, which is where to confirm the exact list for your target version.

The closed set is a design choice with a real payoff. A generic tool can render, validate, diff and transform any conformant submodel without knowing what it describes. The cost is expressiveness: you cannot invent a new element type for your domain, you have to compose one from collections, lists and properties.

Two of these types deserve special attention. SubmodelElementCollection groups named children whose order is irrelevant, similar to an object in JSON. SubmodelElementList holds an ordered sequence of elements that must all be of the same type, and it is what IDTA templates use whenever a repeating structure exists, such as the Markings in the Digital Nameplate or the Documents in Handover Documentation. In the Nameplate v3.0 change log, “Markings changed from a collection type to a list type” is precisely this refinement at work.

Semantic IDs: where meaning lives

Every element can carry a semanticId, a reference into a dictionary that defines what the element means regardless of its idShort. The IDTA templates rely primarily on IEC Common Data Dictionary (CDD) identifiers, with ECLASS identifiers as supplemental semantic IDs. The Digital Nameplate specification states exactly this: “IEC CDD semantic IDs as the primary reference, with ECLASS references as supplemental.”

This is where interoperability is won or lost. Two vendors may name a property RatedVoltage and Vrated, but if both carry the same dictionary reference, a consumer knows they are the same quantity. The inverse failure is worse: two vendors both use RatedVoltage with different or missing semantic IDs, and a naive consumer assumes they match. The Technical Data template even reserves a ConceptDescription named “SemanticIdNotAvailable” for elements that have no dictionary entry, which is an honest admission that coverage is incomplete.

Template versus instance

A template is the published schema: the elements, semantic IDs, cardinalities and data types. An instance is a populated submodel on one asset that conforms to the template. The metamodel distinguishes them through the modelling kind attribute (Template or Instance). In practice, IDTA ships each template as a specification PDF plus an AASX file containing the template itself, and your tooling should validate your instance against it.

Two properties of this relationship are easy to miss. First, cardinality is the contract: an element marked 1 must be present and an element marked 0..1 is optional, and consumers should be written to tolerate absence of the optional ones. Second, the template is versioned, and a new major version is normally not backward compatible, so the version is part of the semantic ID. The Nameplate’s identifying semantic ID, https://admin-shell.io/idta/nameplate/3/0/Nameplate, carries the 3/0 explicitly.

Table 1 summarizes the vocabulary used throughout the rest of this guide.

Concept	What it is	Where it appears in a template
Submodel	Container for one aspect of an asset	Top level, one per template
SubmodelElementCollection (SMC)	Unordered named group of elements	Address information, individual marking entries
SubmodelElementList (SML)	Ordered list of same-typed elements	Markings, Documents, ProductClassifications
Property / MultiLanguageProperty	Typed value or localized text	ManufacturerName, product designation
File	Reference to a document stored in the package or elsewhere	Manuals, certificates, images
semanticId	Reference to a dictionary definition	Every meaningful element
Cardinality	1, 0..1, 0.., 1..	Declared per element in the spec

The Templates That Matter in 2026

The IDTA content hub lists dozens of published templates. Most teams need five or six of them, plus a domain-specific one. This section walks through the ones that appear in real projects, using the specification texts themselves rather than secondary summaries.

Digital Nameplate (IDTA 02006, v3.0.1)

The Digital Nameplate is the entry point for almost every AAS project. The current published version on the IDTA hub is 3.0.1, and the specification describes it as providing nameplate information for equipment in the process industry and factory automation. Its idShort is Nameplate.

The mandatory elements at submodel level are small in number: the product URI (URIOfTheProduct), ManufacturerName, ManufacturerProductDesignation, OrderCodeOfManufacturer, and an AddressInformation collection in which Street, Zipcode, CityTown and NationalCode are mandatory. Notably, serial number and year of construction are optional (cardinality 0..1), a point that surprises people who assume a nameplate always carries them. Markings is a list that must contain at least one entry when used, each entry holding a marking name and optional certificate designation, issue and expiry dates, and a marking file.

The Nameplate also shows how templates handle extensibility. An AssetSpecificProperties collection lets a manufacturer add freely defined properties, and a nested GuidelineSpecificProperties list holds information required by a specific guideline. The specification states that it covers the minimum nameplate requirements in EU regulations and directives and cites Regulation (EU) 2023/1230 and the Blue Guide. The v2.0 to v3.0 change log lists the breaking changes you must handle when migrating: Markings became a list, the ExplosionSafeties collection was removed in favour of supplementary templates such as IDTA 02057, ContactInformation was renamed AddressInformation, and OrderCodeOfManufacturer became mandatory while YearOfConstruction became optional.

Generic Frame for Technical Data (IDTA 02003, v2.0)

Technical Data is the template with the most variance in practice, because it is a frame rather than a fixed schema. Version 2.0 was released on 26 March 2025, and its identifying semantic ID is 0173-1#01-AHX837#002. The structure has five top-level areas: GeneralInformation (mandatory), ProductClassifications (a list), TechnicalPropertyAreas (a list), FurtherInformation (optional) and SpecificDescriptions (a list). The text of the specification describes four areas, but its root table also includes SpecificDescriptions, so rely on the table.

GeneralInformation requires ManufacturerName, ManufacturerProductDesignation, ManufacturerArticleNumber and ManufacturerOrderCode. ProductClassifications entries require the classification system, the product class ID and the coded class name, which lets one product be classified in ECLASS, ETIM or another system simultaneously.

The key idea is that the frame does not define the technical properties. Those come from dictionaries such as ECLASS or IEC CDD (the specification references IEC 61987 and IEC 62683), identified by the prefix of each property’s semanticId. Sections exist for human readability and carry no machine meaning. If a dictionary requires blocks, for example ECLASS aspects, you model them as collections carrying the block’s semanticId. The specification also states a naming rule: any submodel whose title includes “Technical Data” must follow this template.

Version 2.0 is not backward compatible with 1.2. ProductImages and ProductClassifications became lists, TechnicalProperties was renamed TechnicalPropertyAreas, and SpecificDescriptions is new. One gotcha flagged in the document itself: it cites ECLASS 14.0 in one section and ECLASS 15.0 in an annex, so confirm which ECLASS release your property IRDIs come from before you publish.

Handover Documentation (IDTA 02004, v2.0)

Handover Documentation carries the documents that travel with a machine: manuals, certificates, drawings. Version 2.0 was released on 11 June 2025, replacing 1.2 from March 2023. It is based on the German guideline VDI 2770 Sheet 1 and the IEC 82045-2 information model, and it also references IEC 61355-1 document classes.

The structure is a Documents list holding Document collections, each of which requires at least one DocumentId, one DocumentClassification and one DocumentVersion. A version carries language, title, description, a status value (either InReview or Released), organization names, and at least one digital file. The specification requires PDF/A for the digital file, and notes that each language version of a document is modeled as a separate Document.

For practitioners the interesting part is the version history. The 2.0 change log lists ECLASS IRDIs updated to ECLASS 15, the AASX migrated to V3.01, DocumentVersionId renamed to Version, Summary renamed to Description and ValueID renamed to DocumentIdentifier, all flagged non-backward-compatible. If your document management system exports 1.2-shaped data, expect a mapping step.

Carbon Footprint (IDTA 02023, v1.0)

The Carbon Footprint template reached version 1.0 on 25 March 2025, after a draft dated 17 September 2024. Its root is a CarbonFootprint submodel with a mandatory ProductCarbonFootprints list and an optional ProductOrSectorSpecificCarbonFootprints list. The transport carbon footprint present in earlier drafts was removed from v1.0.

Mandatory elements of a product carbon footprint entry include the calculation methods list, the CO2-equivalent total (PcfCO2eq), the reference impact unit and quantity for the calculation, the life cycle phases list, a goods handover address and a publication date. The specification references the GHG Protocol and ISO 14067 in its calculation-method value list, and it cites Catena-X semantic models CX-0029 and CX-0136. For automotive use it recommends using the Catena-X semantic model independently, with this submodel as a supplement. The document is slightly inconsistent about whether multiple footprint entries are modeled as repeated collections inside the list, so check your target tooling before relying on multiple methods per product.

Digital Product Passport metadata and the battery series

Two newer families matter for compliance work. The Digital Battery Passport is a seven-part series under IDTA 02035: Digital Nameplate (02035-1), Handover Documentation (02035-2), Product Carbon Footprint (02035-3), Technical Data (02035-4), Product Condition (02035-5), Material Composition (02035-6) and Circularity (02035-7), all at version 1.0 on the hub. According to IDTA’s May 2026 two-pager, these seven specifications cover all EU Battery Regulation data points, were co-developed with Catena-X, and are based on DIN DKE SPEC 99100; the implementation guideline cites the draft prEN 18223:2025 for alignment.

The second family is Digital Product Passport Part 1: Metadata (IDTA 02099-1). Version 1.0 was published in May 2026 and 1.0.1, a bugfix, in July 2026. Its DppMetadata submodel requires a passport ID, a unique product identifier, a granularity (Model, Item or Batch), a schema version reference, a status, a last-update timestamp and an economic operator ID, with optional facility ID and a list of content specification IDs pointing at the templates that make up the passport. The specification positions itself against EN 18223:2026 and cites ESPR, Regulation (EU) 2024/1781, for the granularity definitions. Our digital product passport data model analysis and the broader DPP architecture reference go deeper on how these pieces connect to GS1 identifiers and registries.

A practical observation: the contentSpecificationIds design means the DPP is a composition. The metadata submodel tells a consumer which other submodels (nameplate, carbon footprint, material composition) to fetch and interpret. That is exactly the same pattern as a plain AAS, which is why the IDTA argues the AAS is a natural DPP carrier.

Other templates worth knowing

The hub lists many more published templates, and a few are broadly applicable rather than niche. Asset Interfaces Description (IDTA 02017, v1.1 and v1.2) describes how to talk to an asset’s own interfaces, and Asset Interfaces Mapping Configuration (IDTA 02027, v2.0) maps them into submodel elements. Control Component Type and Instance (02015 and 02016, v2.0) cover control software. Hierarchical Structures enabling Bills of Material (02011-1, v1.0, an IEC 81346 extension) express product structure. Provision of Company Data (02068), Production Calendar (02067) and Data Retention Policies (02056) are examples of cross-cutting business templates. All of these were visible on the IDTA hub listing at the time of writing; the hub page was truncated in places, so treat the list as indicative rather than complete.

From Template to Running System: Packaging, APIs, and Workflow

Knowing the templates is half the job. The other half is getting populated submodels from an engineering tool to a consumer in a form that survives the trip. That involves three things: the template-to-instance workflow, the AASX file used for offline exchange, and the Part 2 REST API used for live access.

Figure 2: A template is instantiated, validated against its schema, packaged as AASX for exchange, and served through a Submodel Repository to consumers such as MES, PLM or DPP applications.

Figure 2 draws a loop that real projects underestimate. Validation failures send you back to fix elements and semantic IDs, and that loop should run in your build pipeline, not once before a customer demo. The IDTA ships the AASX of each template precisely so tooling can compare your instance structure to the reference.

The AASX package

AASX is the file format for exchanging shells and submodels offline. According to IDTA-01005 v3.2, it is built on the Open Packaging Conventions (ISO/IEC 29500-2:2012), uses the .aasx extension and the MIME type application/aas+zip. In other words, it is a zip archive with a defined internal relationship structure, much like an Office document.

A reader recognizes an AASX by the relationship type http://admin-shell.io/aasx/relationships/aasx-origin in the root relationships file. From that origin, aas-spec relationships (at least one) point to the file holding the AAS, submodel or concept description structure, typically XML or JSON stored as aasx/data.xml or aasx/data.json. The same data may be stored in several formats in parallel. aas-suppl relationships point at supplementary files referenced from File elements, such as PDF manuals, usually in a suppl folder. An optional thumbnail (a picture of the device) and package core properties are linked through metadata relationships, and the OPC digital signature mechanism can sign the origin file, the structure file, supplementary files and their relationships.

Two practical consequences follow. A File element’s path is relative to the package, so a manual referenced from a Handover Documentation submodel travels inside the AASX and does not depend on a URL staying alive. And blobs are not stored as supplementary files, which means large binary content should be a File, not a Blob. For the architecture view of where AASX sits among the other exchange paths, see our AAS architecture overview.

The Part 2 API and the Submodel Repository

For live access, IDTA-01002 defines HTTP/REST services. The v3.1.3 service specification page lists the services and their profiles: AAS, Submodel, AASX File Server, AAS Registry, Submodel Registry, Discovery, AAS Repository, Submodel Repository and ConceptDescription Repository. Profiles are numbered subsets, for example SSP-001 Full, SSP-002 Read and, for the Submodel service, SSP-003 Value. Profile identifiers follow the pattern https://admin-shell.io/aas/API/<major>/<minor>/<service specification name>/SSP-<number>, and servers advertise what they support at a /description endpoint.

Profiles are the most underused feature of the API. A read-only edge gateway should implement the Read profile, not claim full conformance. A consumer should check /description before assuming it can write, bulk-load or query. This is how you avoid the common situation where two “AAS-compliant” servers turn out to support non-overlapping subsets.

The Submodel interface has the operations you would expect from a tree store. GetSubmodel and GetAllSubmodelElements read content, the latter with limit and cursor paging. GetSubmodelElementByPath reads one element by its idShort path. PostSubmodelElementByPath, PutSubmodelElementByPath and the Patch variants write. File content has its own GetFileByPath, PutFileByPath and DeleteFileByPath. Operations declared in the submodel are invoked through InvokeOperationSync or InvokeOperationAsync, the latter with GetOperationAsyncStatus and GetOperationAsyncResult to poll. When you add to a SubmodelElementList, new elements are appended, and direct children of a list need an index in the path.

Figure 3: A consumer resolves an asset ID through Discovery to an AAS identifier, finds submodel endpoints in the Registry, reads structure and semantic IDs from the Submodel Repository, then polls compact values.

Figure 3 shows the access pattern that makes semantic IDs useful at runtime. The consumer first learns what a submodel contains, then switches to the value-only serialization for cheap repeated reads. The spec offers a dedicated GetSubmodelElementValueByPath and PatchSubmodelElementValueByPath for this, and the Submodel service has a Value profile that, per the specification, supports a reduced set of operations to cut bandwidth and does not support pagination. For telemetry-style data this separation matters: structure rarely changes, values change constantly.

The service model also separates concerns that simple deployments merge. A Registry holds descriptors that say where an AAS and its submodels are hosted. Discovery maps asset identifiers to AAS identifiers. Repositories hold the data. A small plant can run all three in one process, but a multi-company data space needs them separate, because the party that knows an asset exists is not always the party that holds its data.

Instantiating a template: a worked example

Consider a centrifugal pump from a vendor you will call Vendor A. The goal is a Nameplate instance that a plant historian, a PLM system and a customer portal can all read. The steps are the same whichever tool you use.

First, take the published IDTA 02006 v3.0.1 AASX as the starting template. Second, create the instance and fill the five mandatory submodel-level elements: product URI, manufacturer name, manufacturer product designation, order code and address information with its four mandatory fields. Third, add at least one Markings entry if you want the Markings list at all, because an empty list is invalid when used. Fourth, put anything vendor-specific in AssetSpecificProperties, not in new top-level elements, so a generic consumer ignores it safely. Fifth, run validation and check that every semantic ID resolves to the template’s value, not to a locally invented one.

The instance in JSON form is a simple tree. The following is an illustrative fragment of the shape, not a complete valid payload:

{
  "idShort": "Nameplate",
  "modelType": "Submodel",
  "kind": "Instance",
  "semanticId": {
    "type": "ExternalReference",
    "keys": [{"type": "GlobalReference",
              "value": "https://admin-shell.io/idta/nameplate/3/0/Nameplate"}]
  },
  "submodelElements": [
    {"idShort": "ManufacturerName", "modelType": "MultiLanguageProperty",
     "value": [{"language": "en", "text": "Vendor A GmbH"}]}
  ]
}

The kind and semanticId lines are the two that consumers and validators check first. If you remember nothing else, remember to keep the template’s submodel semantic ID untouched on your instance. Changing it turns your instance into a custom submodel that merely resembles a standard one.

Reading the same element through the API uses a path rather than a query language. A request to the Submodel Repository for the element path ManufacturerName returns the element, and the value-only variant returns just the value. Identifiers in API paths are base64url-encoded; confirm the encoding rules in the IDTA-01002 text for your target version before writing a client by hand, since this is a frequent source of 404 errors.

Deployment Patterns and Where the Submodels Live

A submodel is a data structure, and who hosts it is an architectural decision. Three patterns recur.

Pattern 1: file-based exchange

The manufacturer ships an AASX with the machine, or makes it downloadable. The customer imports it into a PLM, CMMS or asset register. This is the lowest-friction pattern and a natural fit for static aspects: nameplate, technical data, handover documentation. Its weakness is staleness. The AASX is a snapshot, and nothing tells the customer when the manufacturer later issues a corrected manual. The Handover Documentation template mitigates this with a StatusValue of InReview or Released and a version, but the consumer still has to ask.

Pattern 2: manufacturer-hosted repository

The manufacturer runs a Submodel Repository and publishes its endpoints through a Registry. Customers fetch current data on demand. This fixes staleness for static aspects and is the shape most DPP implementations take, since the passport must be retrievable by a product identifier. It adds operational burden for the manufacturer: availability expectations for products that live for decades, access control through the Part 4 Security specification, and a decision about whether published data is public or restricted per consumer.

Pattern 3: federated, operator-side composition

The operator composes submodels from several parties: nameplate from the manufacturer, maintenance history from a service provider, live operating values from their own edge system. The shell references all of them. This is where the shell-versus-submodel separation proves its worth, and it is also where the Registry and Discovery services stop being optional. Data spaces such as Catena-X and Factory-X use this idea, and IDTA’s DPP two-pager positions the AAS as the data format for them. Our Catena-X reference architecture covers the data-space side.

Mapping live data into submodels

Static aspects are easy. Live data is where teams get stuck. The honest view is that the AAS is an information model and exchange layer, not a streaming platform. Time-varying signals typically come from an OPC UA server, an MQTT broker or a historian, and the submodel holds either the latest value, a reference to where the series lives, or a description of how to reach it. The Asset Interfaces Description template (IDTA 02017) exists to describe that last case: how to reach an asset’s own interfaces, while the Mapping Configuration (02027) maps them into elements. If your question is “how do I get 1 kHz vibration data into a twin”, the answer is that you generally should not put it in a Property, and our OPC UA historian ingestion architecture explains the pattern that works.

Units and value types

One detail that bites at integration time is units. A Property has a value type, such as a double or a string, but the unit of measure is a dictionary-level concept, carried through the semantic definition or data specification content rather than the value itself. Part 3a covers IEC 61360 data specifications and Part 3b covers measurement units. If two systems both send a double for “rated power” and one means kilowatts while the other means watts, the AAS offers no magic. Our units of measurement deep dive explains how the data specification content resolves this.

Trade-offs, Gotchas, and What Goes Wrong

The AAS submodel ecosystem is real and growing, but it has sharp edges that vendor brochures skip. Treat these as a pre-mortem.

Version drift between template and tooling. Templates target a metamodel version. The Nameplate v3.0 states it was updated to metamodel IDTA-01001-3-0-1. Handover Documentation 2.0 migrated its AASX to V3.01. With the metamodel now at 3.2 and v3.3 drafts visible, your editor, your repository server and your validator may each target a different minor version. Our earlier analysis of the 3.2 release found that SDK support lags the specification, so check what your toolchain actually reads, not what the vendor says it supports. Release 26-01 also carries the specification’s own warning that bugfix releases are not necessarily backward compatible, which breaks the usual semantic-versioning intuition.

Templates that are not backward compatible. Nameplate 2.0 to 3.0, Technical Data 1.2 to 2.0 and Handover Documentation 1.2 to 2.0 all changed shape. A consumer that hard-codes a path like Markings/Marking00 breaks silently when Markings becomes a list with differently named entries. The defense is to resolve by semantic ID, not by idShort, wherever you can.

Optional means absent. The Nameplate makes serial number and year of construction optional. Do not build a downstream process that requires them unless you have a contract saying the supplier must provide them. This also applies to the lists: Markings is optional, but when present it must have at least one entry.

Semantic coverage gaps. The “SemanticIdNotAvailable” placeholder exists because dictionaries do not cover everything. An element with no semantic ID is only as interoperable as the human who reads its idShort. Count how many of your elements fall back to it, and treat that number as technical debt.

Dictionary version confusion. The Technical Data specification cites ECLASS 14.0 in the body and ECLASS 15.0 in an annex, and Handover Documentation 2.0 updated to ECLASS 15. Properties from different ECLASS releases may carry different IRDI revisions, and mixing them within one submodel produces confusing lookups.

Custom submodels as lock-in. Nothing stops you from creating a custom submodel with your own namespace, and sometimes you must. But a custom submodel is legal and unreadable to everyone else. The Technical Data template even forbids using the words “Technical Data” in a submodel title unless you follow it, a small guard against exactly this problem.

Profile mismatch. Servers advertise profiles at /description. A client written against the Full profile will fail against a Read-only server, and the failure may look like an authentication error. Test against profiles, not just against the base URL.

Security is a separate concern. Part 4 (IDTA-01004, v3.1.0) addresses security, and the Part 2 text states that the API requires security measures and access control rules defined there. A repository that serves nameplate data publicly may be fine. One that also serves maintenance history or bill-of-material structure may not be. Decide per submodel, and plan for the DPP case where different actors are legally entitled to different views.

The DPP is moving. The DPP metadata template says EN 18223 defines no schema, so the dppSchemaVersion reference is only as precise as your own conventions. IDTA’s May 2026 material shows DPP annexes under member review and a security annex waiting on the CEN-CENELEC JTC 24 security standard. Build for change, and pin the exact template versions in your passport content specification IDs.

Practical Recommendations

Start from the published template whenever one exists, and resist the temptation to remodel it for local taste. The value of the template is the shared contract. If it does not fit, extend through the sanctioned hooks: AssetSpecificProperties in the Nameplate, SpecificDescriptions in Technical Data. Only when neither fits should you create a custom submodel, and then document its semantic IDs and consider proposing it to the IDTA.

Figure 4: Use a published template when it fits, extend it through its sanctioned hooks when it partly fits, and build a documented custom submodel only as a last resort. Validate in every branch.

Figure 4 puts the decision on one page. The branch teams most often get wrong is “partly”: they copy the template, add fields in place and republish it under the original semantic ID, which breaks the contract for every consumer.

Pick one metamodel version across your toolchain and write it down. If you are starting a new project in late 2026, target the v3.2 line and confirm each tool’s support. If you must stay on 3.0 or 3.1 for tooling reasons, plan the migration, using our metamodel 3.2 guide as the checklist.

Treat validation as a build step. Run schema and template checks in CI, fail on missing mandatory elements, and report the count of elements without semantic IDs. Treat the repository as a product: version it, document which profiles it supports, and monitor /description drift.

Use the checklist below before you call a twin “standard”.

• Every submodel declares the template’s exact semantic ID and version.
• Mandatory elements per the template’s cardinality table are present, and optional ones are handled as optional by consumers.
• Consumers resolve elements by semantic ID rather than idShort wherever possible.
• Dictionary references (IEC CDD, ECLASS) have a recorded release.
• Documents are PDF/A where the Handover Documentation template requires it.
• The AASX opens in at least two independent tools.
• The repository advertises its API profiles and security model.
• Unit semantics are verified, not assumed.
• For DPP scope, the content specification IDs list the exact template versions.

Frequently Asked Questions

What is an AAS submodel?

An AAS submodel is a structured container of submodel elements, such as properties, lists, collections and files, that describes one aspect of an asset, for example its nameplate or technical data. It is referenced from the asset administration shell rather than embedded in it. When it follows an IDTA template, its structure and semantic IDs are fixed so any conformant tool can read it.

What is the difference between a submodel and a submodel template?

A template is the reusable, published schema: elements, semantic IDs, cardinalities and data types. A submodel instance is a concrete, populated submodel on a specific asset that conforms to it. In the metamodel, the distinction is carried by the modelling kind attribute, Template or Instance. IDTA publishes each template as a specification and an AASX file you can validate against.

Which IDTA submodel templates should I start with?

Most projects start with the Digital Nameplate (IDTA 02006), Generic Frame for Technical Data (IDTA 02003) and Handover Documentation (IDTA 02004). Add Carbon Footprint (IDTA 02023) for sustainability reporting, and the Digital Product Passport Part 1 Metadata (IDTA 02099-1) or the battery series (IDTA 02035) if you are in DPP scope. Always check the IDTA hub for the current version before building.

What is an AASX file and when should I use it?

AASX is the package format defined in IDTA-01005, built on the Open Packaging Conventions (ISO/IEC 29500-2) with the MIME type application/aas+zip. It bundles the AAS structure in XML or JSON together with supplementary files like PDF manuals. Use it for offline exchange of static aspects. Use the Part 2 REST API when consumers need current data or fine-grained updates.

Can I create my own custom submodel?

Yes, the metamodel permits it, and sometimes the domain demands it. The cost is interoperability, since only systems that know your semantic IDs can interpret the result. Prefer extending a published template through its sanctioned extension points, document your custom semantic IDs, and consider proposing the template to IDTA. Avoid reusing a published template’s semantic ID for a modified structure.

How do submodels relate to the EU Digital Product Passport?

IDTA states that an application can assemble a DPP from submodels retrieved through AAS APIs. The DPP Part 1 Metadata template (IDTA 02099-1) defines the data points every passport needs, and the DPP content is composed from other templates it lists by ID. Batteries are the first product group, with the passport mandatory from February 2027, according to IDTA.

Further Reading

• AAS metamodel 3.2 migration guide: what changed in Release 26-01 at the metamodel and API level.
• AAS units of measurement: IDTA-01003-b vs IEC 61360: how units are carried by data specifications.
• AAS vs DTDL vs OPC UA information models: choosing a modeling approach.
• Asset Administration Shell architecture and the AAS reference architecture: where submodels sit in the system.
• Eclipse BaSyx AAS tutorial: hosting a Submodel Repository.
• Digital product passport data model with GS1 and AAS: DPP identifiers and data.
• Digital twin complete overview: the pillar page for the wider topic.
• External: IDTA AAS specifications (Release 26-01), IDTA submodel template catalogue, admin-shell-io submodel-templates repository, and IDTA 02099-1 DPP Metadata.

By Riju — about