The Asset Administration Shell (AAS) is the Industry 4.0 standard for giving every industrial asset a structured, machine-readable digital twin. In this article you will learn how an asset administration shell is built from submodels and semantic IDs, how the three AAS types differ, and how to keep live submodel values up to date from MQTT data streaming through a broker.
For a broader introduction to twins, see our digital twin technology guide.
What Is an Asset Administration Shell?
An asset administration shell is a standardised digital representation of an asset: a motor, a drive, a robot, a whole production cell, even a piece of software. It was defined within Plattform Industrie 4.0 in Germany and is now maintained by the Industrial Digital Twin Association (IDTA), with its metamodel standardised internationally as IEC 63278.
The core idea is interoperability. A drive from one supplier and a pump from another should describe their nameplate, technical data, documentation and operating data in the same way, so a plant engineer, an MES or a maintenance tool can read them without custom integration for each vendor. The AAS gives every asset the same "wrapper", and the content inside it is organised into submodels.
The Structure of an AAS
An AAS has a small number of building blocks:
| Element | Purpose |
|---|---|
| Asset Administration Shell | The twin itself, with its own ID, referencing exactly one asset |
| Asset information | Global asset ID and kind (type or instance) |
| Submodel | A self-contained aspect of the asset, such as nameplate or operational data |
| Submodel element | The actual content: properties, ranges, files, collections, operations |
| Semantic ID | A reference to a dictionary definition that says what an element means |
| Concept description | The definition of a semantic ID, units and data type |
Submodels
Submodels are the heart of the asset administration shell. Each one covers one aspect of the asset and can be maintained by a different party. The manufacturer supplies the digital nameplate and technical data; the operator adds maintenance records and live operational data.
The IDTA publishes submodel templates so that common aspects look the same everywhere. Widely used templates include the Digital Nameplate, Technical Data, Contact Information, Handover Documentation and Time Series Data. Using a template rather than inventing your own structure is what makes AAS interoperable.
Submodel Elements
Inside a submodel, content is expressed as typed elements. The ones you will meet most often:
- Property: a single value with a data type, for example
MaxRotationSpeedas a double. - MultiLanguageProperty: text in several languages.
- Range: a minimum and maximum.
- File and Blob: documents, images, CAD files.
- SubmodelElementCollection and SubmodelElementList: grouping and repetition.
- ReferenceElement and RelationshipElement: links between elements or assets.
- Operation: a callable function with input and output variables.
Semantic IDs
Every element can carry a semantic ID that points to a definition in a dictionary such as ECLASS or the IEC Common Data Dictionary. This is what lets software know that a property called NenndrehzahlMax in one AAS and MaxSpeed in another mean the same thing. Without semantic IDs, an AAS is just another JSON format.
The Three Types of Asset Administration Shell
| AAS type | Form | Typical use |
|---|---|---|
| Type 1 | A file, usually an AASX package | Manufacturer delivers twin data with the product |
| Type 2 | A server exposing the AAS through an API | Plant systems read and update twins at runtime |
| Type 3 | Proactive shells that interact with each other | Autonomous negotiation between assets, still emerging |
Most industrial projects today work with Type 1 for engineering and handover data and Type 2 for runtime twins. Open-source implementations such as Eclipse BaSyx provide AAS servers and registries, and the AASX Package Explorer is commonly used to create and inspect AASX files.
Where MQTT Fits: Live Data for an Asset Administration Shell
The AAS standard defines the information model and APIs, but it does not prescribe how live shop-floor values arrive. In practice, operational data such as temperatures, speeds and states already flows over MQTT from PLCs and edge gateways. The practical pattern is to keep MQTT as the real-time transport and let an adapter update the relevant AAS submodel.
PLC / sensor -> edge gateway -> MQTT broker -> AAS adapter -> AAS server (Type 2)
|
+-> dashboards, 3D twins, historians
This keeps fast consumers (dashboards, alarms, real-time 3D twins) on MQTT, while the AAS server holds the standardised, semantically annotated view that MES, ERP and engineering tools read.
Topic Design that Maps Cleanly to Submodels
Choose topics that make the mapping to the AAS obvious. An ISA-95 path identifies the asset, and the last levels identify the submodel:
acme/plant1/assembly/line3/drive07/operational live values, retained
acme/plant1/assembly/line3/drive07/status online/offline, retained
The adapter keeps a mapping table from MQTT asset paths to AAS IDs and from JSON fields to submodel element idShorts. Sparkplug B payloads work too: ConnectMQ decodes Sparkplug B and can republish it into ISA-95 topics, which gives the adapter a simple JSON stream to consume.
A Minimal MQTT-to-AAS Adapter
This Python adapter subscribes to operational data and patches property values on an AAS server. The REST path follows the AAS Part 2 API style used by servers such as Eclipse BaSyx, where identifiers are base64url-encoded; check your server's documentation for the exact endpoint and version.
import base64
import json
import paho.mqtt.client as mqtt
import requests
AAS_SERVER = "http://localhost:8081"
SUBMODEL_IDS = {
"acme/plant1/assembly/line3/drive07": "https://acme.example/ids/sm/drive07-operational",
}
FIELD_TO_IDSHORT = {"speed_rpm": "RotationSpeed", "temp_c": "MotorTemperature", "state": "OperatingState"}
def b64url(value: str) -> str:
return base64.urlsafe_b64encode(value.encode()).decode().rstrip("=")
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe("acme/plant1/+/+/+/operational", qos=1)
def on_message(client, userdata, msg):
asset_path = msg.topic.rsplit("/", 1)[0]
submodel_id = SUBMODEL_IDS.get(asset_path)
if not submodel_id:
return
data = json.loads(msg.payload)
for field, id_short in FIELD_TO_IDSHORT.items():
if field in data:
url = f"{AAS_SERVER}/submodels/{b64url(submodel_id)}/submodel-elements/{id_short}/$value"
requests.patch(url, json=data[field], timeout=5)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_connect = on_connect
client.on_message = on_message
client.connect("YOUR_BROKER_HOST", 8883)
client.loop_forever()
Two design notes. First, do not push every high-rate sample into the AAS server; update it at a sensible rate, for example once per second or on change, and keep full-rate data in a historian. Second, keep the mapping tables in configuration, ideally generated from the AAS itself, so adding an asset does not require code changes.
You can test the MQTT side right now with the public MQTT test broker, using a unique prefix such as connectmq/demo/c58d/... in place of acme/..., and adjust the subscription accordingly.
Asset Administration Shell Implementation Checklist
- Define the assets in scope and assign stable global asset IDs.
- Start from IDTA submodel templates before creating custom submodels.
- Attach semantic IDs from ECLASS or IEC CDD to every property you expose.
- Decide which data lives in Type 1 files and which in a Type 2 server.
- Design MQTT topics so asset paths map one-to-one to AAS IDs.
- Write or deploy an adapter that updates live submodel values at a controlled rate.
- Secure the MQTT path with TLS and per-gateway credentials.
- Version submodels and keep the mapping configuration under source control.
AAS Compared with Other Twin Models
AAS is strongest for industrial assets that change hands between manufacturers, integrators and operators, because its submodel templates and semantic IDs travel with the asset. DTDL is lighter and developer-oriented, focused on telemetry, properties and commands. Eclipse Ditto models twins as things with attributes and features and connects natively to MQTT; see Eclipse Ditto with MQTT. Many plants combine them: AAS for the standardised asset description, MQTT and a Unified Namespace for live data, and a lightweight twin layer for visualization. Our Sparkplug B and Unified Namespace guide covers the live data side.
Feed Your Asset Administration Shell with ConnectMQ
ConnectMQ provides the real-time layer: a cloud MQTT broker with MQTT 3.1.1 and 5.0, TLS on 8883, ISA-95 topic detection, a devices view organised by ISA-95 levels and Sparkplug B decoding. Your AAS server and adapter run alongside it as normal MQTT clients. Sign up at app.connectmq.com, start on the free Serverless plan without a credit card, and stream your first asset's operational data into its shell.
Frequently Asked Questions
Is the asset administration shell a software product?
No. It is a standardised information model and API specification. Products and open-source projects such as Eclipse BaSyx implement it.
What is a submodel in the AAS?
A submodel is a self-contained aspect of an asset, such as its nameplate, technical data or operational data, built from typed elements with semantic IDs.
Does the AAS replace MQTT or OPC UA?
No. AAS describes assets and exposes them through APIs; MQTT and OPC UA move live data. A common pattern is MQTT for real-time streams with an adapter updating the AAS.
What is an AASX file?
An AASX file is a package format for Type 1 shells that bundles the AAS, its submodels and supplementary files such as manuals into one file for exchange.
