Asset Administration Shell: A Standard Digital Twin Container

The Asset Administration Shell gives each physical asset a standard digital container of submodels, so engineering, operations, and enterprise systems can exchange the same asset facts.

Information about one asset is usually scattered. The nameplate sits in an engineering database, the datasheet in a document folder, the maintenance history in a maintenance system, and live values in a controller or historian. The Asset Administration Shell (AAS) is a standard way to bundle the descriptive information about an asset into one digital representation that other systems can read.

This article explains the AAS structure, the specification parts published by the Industrial Digital Twin Association (IDTA), serialization and interface options, how the AAS relates to OPC UA and enterprise data, and a rollout that starts with a small set of submodels. It is written for engineers and information managers who must decide what to build first. Read the current IDTA specification parts before you implement anything.

Core concepts: asset, shell, and submodels

An asset is the item being described, such as a pump, a motor, a control valve, or a production line. The Asset Administration Shell is the digital representation of that asset. It holds the asset identity and a set of submodels. Each submodel groups related information, such as technical data, documentation, or inspection records.

Elements inside a submodel can carry a semantic identifier that points to a definition of what the value means. This is what allows a system that did not produce a value, such as a rated power, to read it correctly. Without semantic references, an AAS is only a container of labelled values. The IDTA data specification part ties data definitions to IEC 61360, a dictionary-based method for defining data elements, so the meaning can be looked up rather than guessed.

The IDTA specification set

The IDTA, a German registered association, publishes the AAS specifications on its content hub. The specification is split into parts with separate numbers. Know which part answers your question before you read the rest of the set.

Submodel templates make content comparable

A submodel template defines the elements a submodel must or may contain for one kind of information. Templates matter because two vendors that fill the same template produce comparable content. The IDTA lists its submodel templates on a dedicated page. Each template entry shows an IDTA number, a version, and a status such as published or in development. Check the status of every template before a project depends on it, and prefer a published template version over an in-progress one.

Two templates are a useful starting point for most plants. A nameplate-type submodel carries identifying data that normally appears on the physical nameplate, such as manufacturer and serial number. A documentation submodel references the documents that describe the asset, such as manuals and certificates.

Serialization, packages, and interfaces

An AAS can be stored and exchanged in several forms. Part 5 defines the AASX package file format, which bundles AAS content and attached documents into one file. Part 2 defines the programming interfaces for applications that need to read or write AAS content. Plain JSON and XML serializations are used for exchange as well. The exact serialization rules are defined in the specification parts, so confirm them in Parts 1 and 2 of the edition you adopt, rather than in this summary.

• AASX package: one file for handover or archive, including attached documents. It captures a snapshot, not live values.
• Programming interface: suits a service that reads one asset on request. Access decisions belong in the security design, not only in the interface.
• JSON or XML files: useful for tests, reviews, and import tools. Validate each file against the chosen part before loading it into a repository.

How the AAS relates to OPC UA, ERP, and PLM

The AAS and OPC UA solve different problems, and they meet at the same asset. OPC UA is the framework for exchanging process data and methods between controllers, SCADA, and supervisory systems, as described in the OPC Foundation online reference. The AAS is a container for descriptive and document information, and it can reference data that lives elsewhere, including an OPC UA node. The practical pattern is to keep live values in OPC UA, keep the asset description in the AAS, and link them by identifier. Check the current IDTA material for any published mapping between AAS content and OPC UA before you design a bridge, because the mapping rules are where projects fail.

ERP and PLM systems hold master and transactional records, such as purchase data, bills of material, and change history. The AAS does not replace them. It can carry a view of selected facts or point to the system of record. Give every submodel element one named owner, as described in manufacturing data governance, so that a copy in the AAS never becomes an unofficial master record.

A rollout that starts with nameplate and documentation

Start with one asset class that has clear value and a manageable number of units. Motors and control valves are common choices. Keep the pilot small enough that a reviewer can check each record by hand. The steps below apply the template and semantics discipline described above, and they fit the wider plan in digital twin implementation strategies.

1. Select the asset class and scope. Choose one class and a pilot set small enough to review line by line.
2. Map fields to published templates. Match each required field to a published submodel template version. Record any gap as a change request, not as a private field name.
3. Bind definitions and units. Agree the definition and unit of each element using the data specifications the project adopts. Keep the agreed list under version control.
4. Fill from the system of record. Export values from engineering and document management. Compare a sample of the exported values with the source documents.
5. Validate and release. Run schema validation on the AASX or serialized output, obtain owner sign-off, and store the file with the asset record.

What the AAS does not solve

• Real-time control. An AAS is not a control protocol. Timing-critical exchange stays on the control network, with the protocols built for it.
• Bad source data. A standard container makes wrong values travel faster. Data quality checks belong at the source, as described in industrial tag naming and data contracts.
• Governance. Meaning, ownership, and change control are organizational decisions. The specification does not supply them.
• Security. Part 4 addresses security for AAS content, but network segmentation, access control, and patching remain separate engineering work.
• Automatic interoperability. Two AAS files match only when both authors used the same template version and definitions correctly.

Continue the engineering work

• Digital Thread and Digital Twin: Building the Product Lifecycle Data Spine
• Digital Twin Implementation Strategies for Industrial Assets
• OPC UA Companion Specifications — Industry-Specific Information Models
• Industrial Tag Naming and Data Contracts for PLC, SCADA, and MES
• Manufacturing Data Governance: Ownership, Quality and Lineage

Browse the related technical library or follow an ASP project guide to plan the implementation sequence.

Primary references and further reading

Use the original specifications and product documentation for implementation details. Examples in this guide are illustrative engineering scenarios, not published project results.

• Industrial Digital Twin Association — AAS specifications
• Industrial Digital Twin Association — AAS submodel templates
• OPC Foundation — OPC Unified Architecture online reference