Asset Administration Shell: Industry 4.0 Submodels Guide

What Is the Asset Administration Shell?

The Asset Administration Shell (AAS) is a standardized digital representation of industrial assets that implements IEC 63278, enabling seamless interoperability between manufacturing equipment, enterprise systems, and cloud platforms. AAS encapsulates an asset’s metadata, capabilities, and operational state as semantic submodels (IEC 63365), making physical devices self-describing and machine-discoverable within the Industry 4.0 ecosystem.

Architecture at a glance

Why Asset Administration Shell Matters for Industry 4.0 in 2026

The manufacturing landscape in 2026 faces a critical interoperability crisis. Legacy PLC networks speak Modbus and Profibus; modern ERP systems demand REST APIs and cloud integration; digital twin platforms require semantic context about asset capabilities. Without a universal lingua franca, data transformation becomes a custom integration nightmare—expensive, brittle, and impossible to scale across supply chain partners.

The Asset Administration Shell solves this by providing a standardized container for machine-readable asset metadata. Unlike point-to-point adapter solutions, AAS creates a federated knowledge graph where any OEM, integrator, or cloud provider can publish asset shells once and have them understood by every downstream system.

Industry Adoption Drivers

OEM-to-OEM Transparency: Manufacturers no longer ship equipment with printed datasheets and CAD files. Instead, they publish an AASX package (zipped AAS + XML + embedded assets) that ERP systems and MES platforms can ingest directly. Siemens, Bosch, ABB, and KUKA have all published reference AAS implementations for their flagship product lines.

Supply Chain Visibility: Automotive Tier-1 suppliers use AAS to expose sub-assembly capabilities, geometric tolerances, and lead times to automotive OEMs via secure REST endpoints. A vehicle platform’s digital twin can now auto-discover which stamping presses can produce which body panels.

ERP Integration Without Middleware: SAP and Oracle have published AAS consumption connectors. A manufacturing facility’s AAS server becomes the single source of truth for asset master data—no manual parts list uploads, no data entry errors.

Regulatory Compliance: Carbon footprint tracking, traceability (FSMA, IMDS), and circular economy mandates require immutable audit trails of asset configuration. AAS + AASX packages provide tamper-proof provenance.

Asset Administration Shell Reference Architecture: Type 1, 2, and 3

The IDTA (Industrial Digital Twin Association) and Plattform Industrie 4.0 define three implementation types for AAS, each suited to different maturity levels and use cases.

AAS Type 1: Read-Only Registry

Purpose: Publish static asset metadata (nameplate, technical data, documentation).

Architecture: A passive HTTP registry or file server that serves AASX packages. No bidirectional communication, no operational state feedback.

Use Case: OEM datasheet replacement. A pump manufacturer publishes an AASX containing ISO 9001 certification, performance curves, spare parts catalog, and 3D CAD. A system integrator downloads the AASX once and extracts configuration parameters.

Pros: Minimal integration effort, zero vendor lock-in.
Cons: No real-time diagnostics, no closed-loop feedback to the asset.

AAS Type 2: Bidirectional OPC UA Server

Purpose: Expose asset operational state (measurements, diagnostics, actuation) via standardized OPC UA Companion Specifications.

Architecture: An edge gateway (or embedded microcontroller) runs an OPC UA server that publishes AAS submodels. Each submodel maps to OPC UA nodes; property reads and writes translate directly to device commands.

Use Case: Manufacturing cell integration. A CNC machine’s AAS server exposes:
– NamePlate submodel: Machine serial number, manufacturer, model, firmware version.
– Technical Data submodel: Spindle RPM limits, tool changer capacity, axis travel.
– Operational State submodel: Real-time spindle speed, tool offset, alarm codes.
– Capabilities submodel: Functions (drill, tap, bore); constraints (±0.01mm tolerance only with HQ spindle oil).

An MES client subscribes to the Operational State submodel and triggers a job cancel if vibration exceeds thresholds.

Pros: Real-time feedback, bidirectional control, standardized OPC UA tooling.
Cons: Requires embedded OPC UA stack (memory, CPU overhead); network dependency.

AAS Type 3: Cloud-Native Microservices

Purpose: Decouple digital twin logic from physical assets; enable autonomous asset behavior and multi-tenant management.

Architecture: Each asset is represented by a stateless REST microservice (cloud-deployed) that maintains an authoritative copy of the asset’s AAS. A companion edge agent (lightweight, on-premises) syncs operational state bidirectionally with the cloud via MQTT or REST webhooks.

Use Case: Distributed supply chain. A contract manufacturer’s facility exposes AAS shells for 200 production lines, each as a cloud microservice. Customers’ MES platforms query the cloud AAS for available capacity, schedule work, and receive real-time progress updates. The local edge agent handles failover if cloud connectivity drops.

Pros: Scalable, multi-tenant capable, enables AI/analytics on pooled asset data.
Cons: Data sovereignty and latency concerns; requires cloud infrastructure.

Submodels Deep Dive: IDTA-Published Standard Submodels

Submodels are the semantic building blocks of an AAS. Each submodel is a standardized template defining a specific aspect of an asset—nameplate, technical data, capabilities, or operational state. The IDTA maintains a registry of published submodels, each identified by a unique IRI (Internationalized Resource Identifier).

NamePlate Submodel (IRI: https://l2-automation.com/spec/submodel/nameplate/1/0)

Purpose: Machine-readable asset identity and manufacturer metadata.

Required Properties:
– Manufacturer: Organization name, ISO 9001 certification link.
– ManufacturerProductDesignation: Model number, SKU.
– SerialNumber: Unique instance identifier.
– ModelNumber, ProductCode: Cross-reference to ERP/CAD system.
– YearOfConstruction: Warranty and lifecycle tracking.
– VendorModelNumber: Supplier’s internal part number.

Example JSON (Type 2 OPC UA JSON serialization):

{
  "modelType": "Submodel",
  "idShort": "NamePlate",
  "identification": "https://l2-automation.com/spec/submodel/nameplate/1/0",
  "submodelElements": [
    {
      "idShort": "Manufacturer",
      "modelType": "Property",
      "valueType": "xs:string",
      "value": "Siemens AG"
    },
    {
      "idShort": "ManufacturerProductDesignation",
      "modelType": "Property",
      "valueType": "xs:string",
      "value": "SINAMICS G120XE"
    },
    {
      "idShort": "SerialNumber",
      "modelType": "Property",
      "valueType": "xs:string",
      "value": "SN-2024-0042851"
    }
  ]
}

Technical Data Submodel (IRI: https://l2-automation.com/spec/submodel/technicaldata/1/0)

Purpose: Specifications, performance curves, compatibility matrices.

Typical Contents:
– Datasheets (PDF/CAD binary embedded in File submodel elements).
– Performance curves: efficiency vs. load, power consumption vs. speed.
– Environmental tolerances: operating temperature, humidity, vibration class.
– Compliance certifications: CE marking, machinery directive, RoHS.
– 3D CAD model (STEP, STL), piping & instrumentation diagrams.
– Bill of materials (BOM) for spare parts.

Use Case: An automated test system pulls the Technical Data submodel and extracts environmental constraints before scheduling a product burn-in cycle.

Documentation Submodel

Purpose: User manuals, commissioning guides, safety data sheets, field-service procedures.

Use Case: Service technician’s mobile app queries the Documentation submodel and displays the correct manual for the installed asset version, with highlighted procedures for the observed fault code.

Capabilities Submodel (IRI: https://l2-automation.com/spec/submodel/capabilities/1/0)

Purpose: Advertise what the asset can do—functions, constraints, performance characteristics.

Structure:
– Capabilities (array of JSON objects describing available functions)
– Function: “Drill”, “Tap”, “Bore”
– Constraint: “±0.01mm tolerance only with spindle calibration”
– Tool: “Standard T-slot tool changer”
– CycleTime: “5 sec per hole” (reference or formula)
– Cost: “$0.42 per operation” (for ERP costing)

Use Case: An MES job scheduler queries all AAS in the facility for their capabilities, filters to those that can bore to ±0.005mm with a 4-flute carbide endmill, and assigns the job to the machine with the shortest queue.

Operational State Submodel (Custom, facility-specific)

Purpose: Real-time machine state—spindle speed, tool offset, active alarms.

Typical Properties:
– SpindleRPM, FeedRate, CuttingPower (real-time measurements).
– ActiveTool, ToolOffset (current configuration).
– CycleState: “READY”, “CUTTING”, “TOOL_CHANGE”, “ALARM”.
– MaintenanceHours: Hours since last scheduled maintenance.
– EnergyConsumption: kWh counters (for carbon tracking).

Transport: OPC UA subscriptions, MQTT, or periodic REST pull.

AAS Metamodel: IEC 63278 Class Hierarchy

The IEC 63278 standard defines the formal metamodel—a class hierarchy describing how to structure submodel elements, relationships, and references.

Core IEC 63278 Concepts

Asset Shell (AssetAdministrationShell)
– Top-level container for all metadata and submodels.
– Attributes: identification (unique IRI), idShort (human-readable name), assetInformation (type: Asset).
– Contains: SubmodelReferences, SubmodelCollections, ConceptDescriptions (semantic mapping).

Submodel (Submodel)
– A domain-specific collection of properties, relationships, and operations.
– Identified by IRI per IEC 63365 registry.
– Can be instantiated multiple times (e.g., Asset contains NamePlate + TechnicalData + OperationalState submodels).

SubmodelElement (SubmodelElement)
– Atomic unit of information: Property, MultiLanguageProperty, File, Relationship, Operation.
– Property: Key-value pair with type annotation (xs:string, xs:integer, xs:double).
– MultiLanguageProperty: Localizable strings ({“en”: “Drill”, “de”: “Bohren”}).
– File: Binary or text asset (CAD, image, PDF) with MIME type and path.
– Relationship: Semantic link to another submodel element (e.g., “Spindle ⟶ bearings installed”).
– Operation: Callable function signature (inputs, outputs) + binding to device command.

ConceptDescription (ConceptDescription)
– Semantic annotation linking a submodel element to external ontology (ISO 80000, IEC CDD, etc.).
– Example: The “Power” property points to ISO 80000-6 (Power and Energy) for unit harmonization.

Reference Semantics: IRI vs. idShort

• IRI (Internationalized Resource Identifier): Permanent, globally unique identifier. Example: https://l2-automation.com/spec/submodel/nameplate/1/0.
• idShort: Local, human-readable name within the asset shell. Example: NamePlate.

An AAS server resolves both: GET /shells/{shellId}/submodels/NamePlate returns the NamePlate submodel; GET /shells/{shellId}/submodels/https%3A%2F%2Fl2-automation.com%2Fspec%2Fsubmodel%2Fnameplate%2F1%2F0 (IRI-URL-encoded) returns the same.

Serialization Formats: AASX, JSON, XML, RDF—When to Use Which

AASX (AAS eXtended)

Format: ZIP container with embedded XML (AAS metamodel), PNG/SVG thumbnails, and binaries (CAD, PDFs, 3D models).

Use Case: OEM publishes a complete, standalone asset package. Download once, unzip, extract metadata and documentation offline.

Pros: Self-contained, no external dependencies, standard format for data interchange.
Cons: Not real-time friendly; versioning requires re-zipping.

Example Tools: AASX Package Explorer (2024.04 version), BaSyx AASX Service, OpenUI5-based viewers.

JSON

Format: RESTful API responses (AAS, submodels, properties as JSON objects).

Use Case: Real-time bidirectional communication. MES platform queries GET /shells/{id}/submodels/OperationalState and receives JSON submodel; updates via PATCH /shells/{id}/submodels/OperationalState/properties/SpindleRPM/value (JSON body).

Pros: Lightweight, human-readable, standard web APIs.
Cons: Loses embedded binaries; requires separate File API for CAD downloads.

Serialization: AAS JSON Schema (v3.0) published by IDTA, compatible with OpenAPI 3.1 tooling.

XML

Format: Verbose hierarchical encoding; default serialization inside AASX packages.

Use Case: Legacy SOAP integration, enterprise data warehouses (SAP Analytics Cloud, Informatica).

Pros: Schema validation (XSD), namespacing, traditional SOAP stack compatibility.
Cons: Verbose, poor performance at scale, less suitable for IoT edge devices.

RDF/OWL Linked Data

Format: Semantic Web representation (Turtle, N-Triples, JSON-LD).

Use Case: Graph databases, supply-chain provenance queries. “Find all assets manufactured by Company X in 2025 with ISO 9001 certification.”

Pros: Cross-organizational semantic queries, standardized ontologies (QUDT, Dublin Core).
Cons: Steep learning curve, limited tooling in traditional PLCs/MES platforms.

Choosing the Right Format

Use Case	Format	Rationale
OEM publishes datasheet replacement	AASX	Self-contained, embeds CAD + PDFs
MES real-time polling of asset state	JSON	Lightweight, REST-native
ERP batch data import (nightly)	XML	Schema validation, data warehouse ingestion
Graph database queries (supply chain)	RDF/JSON-LD	Semantic interoperability

AAS Interoperability: OPC UA, Companion Specs, and MTConnect

The true power of AAS emerges when it bridges three critical industrial protocols: OPC UA (deterministic automation), MTConnect (statistical machine monitoring), and proprietary REST APIs.

OPC UA Companion Specifications

OPC UA Companion Specs (Machinery, AutomationML, Packml, Weighing) define standardized node sets for specific verticals. An AAS Type 2 gateway translates between OPC UA nodes and AAS submodels.

Mapping Example:

OPC UA Node	AAS Property	Semantics
Objects/Motors/MainSpindle/ActualRPM	OperationalState/SpindleRPM	Real-time spindle speed (numeric)
Objects/Motors/MainSpindle/ActualRPM/EURange	OperationalState/SpindleRPM/@valueType	Unit annotation (xs:integer, min=0, max=24000)
Objects/Safety/EStop	OperationalState/CycleState enum value	E-stop activated → “HALTED”

Bidirectional binding: A cloud MES service issues an AAS operation call PATCH /spindle/actuation/setRPM {value: 8000} → OPC UA method call on the gateway → modbus command to drive → spindle accelerates.

MTConnect Integration

MTConnect is the NIST standard for streaming machine tool data (ISO 23835). An AAS can bridge MTConnect agents to OPC UA consumers.

Pattern:
1. Machine Tool (Haas CNC, Makino) exposes MTConnect Agent on port 5000, publishing cutting power, tool changer position, spindle load.
2. AAS Adapter (runs on edge gateway) polls the MTConnect agent every 500ms, parses XML, and updates AAS OperationalState submodel.
3. OPC UA Server (on same gateway) exposes AAS submodels as OPC UA nodes, subscribed by MES clients.

Benefit: MTConnect data becomes discoverable via OPC UA Companion Specs, eliminating the need for separate MTConnect clients.

Production Integration Pattern: PLC → AAS Server → Digital Twin → ERP

A real-world manufacturing cell demonstrates the full stack:

Step-by-Step Data Flow

1. PLC/Edge Gateway (Deterministic Layer)
– Siemens S7-1500 PLC runs machine control, logs events to internal SD card.
– At 100ms intervals, writes spindle RPM, tool number, cycle count to Modbus registers.
– Local AAS edge agent (BaSyx embedded on a Raspberry Pi) polls Modbus and synchronizes to AAS OperationalState submodel.

2. AAS Server (Semantic Aggregation Layer)
– BaSyx Registry (Docker, on edge or local cloud) hosts the AAS for this machine.
– Exposes two endpoints:
– REST API: GET /shells/machine-01/submodels/OperationalState → JSON property values.
– OPC UA Server: Synchronizes OPC UA nodes ↔ AAS properties bidirectionally.
– Submodels: NamePlate (static), TechnicalData (specs), OperationalState (real-time), Capabilities (what this machine can do).

3. Digital Twin Service (Analytics Layer)
– Cloud microservice (AWS Lambda, Azure Functions, or Kubernetes pod) subscribes to machine-01 AAS operational state via MQTT or webhook.
– Aggregates data from 50 machines in the facility.
– Detects anomalies: “Spindle vibration exceeded ±2mm for >5 seconds” → triggers predictive maintenance workflow.
– Publishes digital twin state (machine utilization, energy draw, quality metrics) to a time-series database (Prometheus, InfluxDB).

4. ERP/MES (Business Logic Layer)
– SAP ERP queries the digital twin service API for capacity and scheduling constraints.
– MES (e.g., Siemens Opcenter) subscribes to OperationalState submodel and receives work orders, tool offsets, and quality checkpoints.
– When a job finishes, MES updates the Capabilities submodel to reflect the tool that was just inserted, enabling auto-scheduling of the next compatible job.
– Material movements (part in → work-in-process → inspection → finished goods) are logged in ERP with AAS-derived asset context.

Integration Benefits

• No custom adapters: OPC UA standard bindings + AAS semantics replace vendor-specific data transformations.
• Federated data: Digital twin aggregates across facilities without copying; MES remains the authority.
• Auditability: Every submodel update is timestamped and optionally cryptographically signed (AASX + blockchain).
• Extensibility: Adding a new asset type (paint booth, AGV, quality test rig) requires only publishing a new AAS (no MES code changes).

Open-Source Tooling: BaSyx, NovaAS, AASX Package Explorer

BaSyx Eclipse (2.0 LTS, GA April 2024)

Purpose: Reference implementation of AAS, OPC UA server binding, and REST API gateway.

Components:
– AAS Server: Stateful microservice for managing AAS instances. Docker image ~150MB, memory footprint ~200MB at 100k properties.
– OPC UA Server Module: Exposes AAS submodels as OPC UA nodes.
– Registry: Discovers shells across distributed environments (federated).
– AASX Service: Publishes and consumes AASX packages via REST.

Deployment:

docker run -p 8080:8080 \
  -e BASYX_AASSERVER_REGISTRY_PATH=/data/registry.json \
  eclipsebasyx/aas-server:2.0.0

Use: Embedded in MES, data lake, or IoT platform as a sidecar. Lightweight enough for edge (industrial PC), scalable to cloud deployments.

NovaAS by Fraunhofer

Purpose: Lightweight Java-based AAS server, optimized for embedded and edge devices.

Pros: Minimal dependencies, ~50MB JAR, sub-100ms response times.
Integration: REST API + OPC UA server option.
Use Case: Deployed on small industrial gateways (Siemens IoT Gateway, HMS Ewon).

AASX Package Explorer (2024.04, open-source)

Purpose: Desktop GUI for authoring, validating, and publishing AASX packages.

Features:
– Visual submodel editor (drag-and-drop property definition).
– AASX package bundler (zips XML + binaries).
– Semantic validation against IEC 63278 and IDTA submodel templates.
– CAD model preview (STEP, STL).

Workflow: OEM engineer builds asset metadata → AASX Package Explorer validates → publishes AASX to web server → integrators download and ingest.

Integration with Existing MES/ERP

Tool	AAS Binding	Status
SAP MES	REST API Consumer	Production (2024)
Siemens Opcenter	OPC UA Server Binding	Production (MES 21+)
Dassault Systèmes 3DExperience	AASX Importer	Public Preview
AWS IoT Core + Lambda	MQTT ↔ AAS Translator	Custom integration (blueprints available)
Grafana	OPC UA Data Source	Community-supported

Trade-offs and Common Pitfalls

Pitfall 1: Over-Specification at Design Time

Error: OEMs publish static Technical Data submodels that do not anticipate customer modifications. A drilling machine is sold with a specific tool changer, but a customer retrofits it with a different one. The published AAS becomes incorrect.

Solution: Separate design-time submodels (immutable) from instance-time submodels (mutable). The NamePlate is static (signed in AASX); the Capabilities submodel is configurable via a secured REST PATCH endpoint, synchronized bidirectionally with the facility MES.

Pitfall 2: Namespace Collisions

Error: Two suppliers each define a “Power” property with different units. Asset 1’s Power is in watts; Asset 2’s Power is in kilowatts. An aggregation query breaks.

Solution: Use ConceptDescriptions (semantic annotations) to bind each property to an ISO 80000 unit. An AAS consumer always resolves the unit via the ConceptDescription before aggregating.

Pitfall 3: Security Model Ambiguity

Error: AAS servers published without TLS, API keys, or signature validation. A supply-chain attacker publishes a rogue AAS claiming to be a critical pump, causing ERP to over-order spares.

Solution:
– At rest: AASX packages signed with OEM certificate + SHA-256 hash.
– In transit: AAS REST APIs served over TLS 1.3, API client authentication via mTLS or OAuth2.
– Access control: Role-based AAS server (read NamePlate publicly; write OperationalState only from authenticated edge agent).

Pitfall 4: Performance at Scale

Error: A facility with 5,000 assets each publishing OperationalState at 1 Hz → 5,000 REST requests/sec to the AAS server. Single-instance BaSyx saturates at ~500 req/sec.

Solution:
– Scaling strategy: Deploy multiple BaSyx instances behind a load balancer; use time-series DB (Prometheus) for operational metrics, AAS for configuration.
– Decoupling: Operational state (fast, frequent) → MQTT publish-subscribe; Configuration (slow, rare) → AAS REST with caching.

Pitfall 5: IRI Versioning and Drift

Error: IDTA publishes v1.1 of NamePlate submodel with a new required property “YearOfManufacture”. Existing AAS instances still declare v1.0 IRIs and fail validation.

Solution: Semantic versioning in IRI paths: https://l2-automation.com/spec/submodel/nameplate/1/1. Legacy v1.0 instances continue to work; new instances adopt v1/1. A compatibility layer or migration script assists upgrades.

FAQ: Five Practical Questions

Q1: How Does AAS Relate to Digital Twin?

A: Digital Twin is the broader concept (a virtual representation of a physical asset across its lifecycle). AAS is the semantics layer—it standardizes how the digital twin is described and serialized. An AAS + submodels is one valid representation of a digital twin; you could also have a CAD model or a graph database as alternative representations. AAS excels at machine-to-machine interoperability; digital twin excels at human visualization and simulation.

Q2: Can I Retrofit an Existing Brownfield Machine with AAS?

A: Yes. An AAS edge adapter (software running on a Siemens IoT Gateway, HMS Ewon, or Raspberry Pi) bridges the gap. The adapter polls Modbus/EtherCAT from the PLC, maps to AAS submodels, and exposes a REST API. The physical machine is unchanged; you’ve added a digital “skin.” The retrofit AAS is published (Type 2) or cloud-synced (Type 3).

Q3: What Happens If My AAS Server Goes Down?

A: Depends on deployment type:
– Type 1 (read-only AASX): No problem; clients cache the AASX locally.
– Type 2 (OPC UA server): MES clients should cache the last-known submodel state and fall back to local rules (e.g., “assume spindle is idle” if OPC UA subscription drops).
– Type 3 (cloud AAS): The edge agent buffers operational state locally (SQLite, local files) and batches sync once cloud is restored.

Recommended: Implement a heartbeat check on the AAS Registry endpoint; if the asset is unreachable for >30 seconds, ERP marks the asset as offline and re-routes work.

Q4: How Do I Authenticate OPC UA Clients to the AAS Server?

A: OPC UA defines user/password or certificate-based authentication at the server level. BaSyx 2.0 supports OpenSecureChannel (OPC UA native security). For REST API:
– OAuth2 (recommended): BaSyx integrated with Keycloak; MES client obtains JWT token.
– mTLS: AAS server and client exchange X.509 certificates.
– API key: Simple, not recommended for sensitive production data.

Q5: Can I Use AAS for Real-Time Control (Sub-100ms Latency)?

A: Not recommended. AAS + REST is designed for deterministic operations (sub-second latency acceptable). For real-time control:
– Use OPC UA with subscriptions (100ms delivery guaranteed).
– Or use Modbus/Profibus directly (native machine control), then layer AAS on top for metadata/configuration.
– Reserve AAS for supervisory logic: scheduling, diagnostics, capacity planning.

Further Reading and Internal Links

• Digital Twin Fundamentals: Architecture Patterns for Industrial Assets
• Industry 4.0 Framework: Pillar 1 – Connectedness and Interoperability
• OPC UA Companion Specifications: Industrial Interoperability Standard
• IDTA Specification Library
• IEC 63278:2023 Asset Administration Shell – Metamodel
• IEC 63365:2024 Generic Submodels and Specifications

---

Conclusion

The Asset Administration Shell transforms manufacturing interoperability from a fragmented, integration-heavy problem into a standardized, scalable ecosystem. By publishing machine capabilities, configurations, and state as semantic submodels conforming to IEC 63278 and IEC 63365, OEMs enable their equipment to become self-describing, discoverable, and autonomously orchestrated across ERP, MES, and digital twin platforms.

In 2026, AAS adoption distinguishes best-in-class manufacturers—those with seamless data pipelines, zero-downtime supply chain visibility, and AI-driven predictive maintenance—from those still wrestling with custom adapters and manual data entry. The tools (BaSyx, NovaAS, AASX Package Explorer) are mature and open-source; the standards (IEC 63278, IEC 63365) are finalized. The remaining challenge is organizational: aligning OEM, integrator, and customer incentives to co-publish reference AAS implementations for shared supply chains.

Next steps: Download the AASX Package Explorer reference implementation, author a test AAS for one of your critical assets, and integrate it with your MES via a Type 2 OPC UA server gateway. The initial integration is a two-week effort; the long-term ROI (reduced engineering time, faster troubleshooting, supply-chain agility) is measured in months.