Asset Administration Shell (AAS)

The AAS structures asset data into discrete, domain-specific submodels rather than a monolithic data block. Each submodel represents a distinct facet of the asset—such as its technical documentation, operational parameters, or carbon footprint. This separation of concerns allows different stakeholders to access and update only the information relevant to their role without interfering with other domains. Submodels are identified by unique semantic identifiers, enabling automated discovery and matching across heterogeneous systems. A motor's AAS, for example, might contain a nameplate submodel with static properties and a condition monitoring submodel streaming real-time vibration data.

Every property and submodel within an AAS is annotated with a globally unique semantic identifier referencing a formal dictionary like ECLASS or IEC CDD. This ensures that a 'temperature' value from a Siemens PLC and a 'temperature' value from a Rockwell drive are semantically identical and machine-interpretable. The AAS does not enforce a single data model but instead provides a common meta-model that maps proprietary data points to standardized concepts. This semantic layer is the critical enabler for plug-and-produce interoperability, allowing assets from different vendors to communicate without custom integration code.

The AAS exposes a standardized RESTful HTTP API defined by the Industrial Digital Twin Association (IDTA). This API provides a uniform set of CRUD operations for reading and writing submodel data, browsing the asset's structure, and invoking asset services. The specification defines endpoints for:

• Serialization formats: JSON, XML, and AutomationML
• Protocol bindings: HTTP/REST and OPC UA
• Security: OAuth 2.0 and role-based access control This API-first design decouples the digital representation from the underlying physical asset, enabling cloud-based analytics platforms to interact with factory-floor equipment through a single, consistent interface.

An AAS is not a static document but a living digital companion that evolves with the physical asset from engineering through operation to decommissioning. The specification includes robust versioning mechanisms for both the shell itself and its submodels, tracking changes over time with clear revision histories. This enables auditability and traceability—critical for regulated industries like pharmaceuticals and aerospace. When a component is replaced or firmware updated, the corresponding submodel is versioned, creating an immutable record of the asset's configuration state at any point in its lifecycle.

Beyond passive data storage, the AAS can expose active services that represent the asset's functional capabilities. These services are invoked through the standardized API and can trigger physical actions, execute algorithms, or initiate complex workflows. Examples include:

• A calibration service on a sensor's AAS that triggers a self-calibration routine
• A simulation service on a digital twin that runs what-if scenarios
• A negotiation service on a production module for agent-based manufacturing This transforms the AAS from a static information model into an executable interface for Industry 4.0 automation.

The AAS specification incorporates a comprehensive role-based access control (RBAC) model to govern who can read, write, or invoke services on specific submodels. Access policies can be defined at the granularity of individual properties, ensuring that sensitive data—such as proprietary process parameters—is only exposed to authorized consumers. The security framework supports OAuth 2.0 and X.509 certificate-based authentication, enabling integration with enterprise identity providers. This is essential for cross-company data sharing in Catena-X and other data space initiatives where supply chain partners require selective, auditable access to each other's asset information.