For a few years now, “digital thread” has been the phrase manufacturers reach for when they want to sound serious about connecting design data to production data to service data without actually specifying how. It’s a good concept and a bad file format. The Asset Administration Shell, or AAS, is the Industry 4.0 community’s attempt to fix the second half of that problem — to define what actually goes inside the thread, not just wave at the idea of it. After several years of being mostly a conference-slide standard, AAS is starting to show up in shipping tooling and real RFP language. That’s worth your attention, but it doesn’t mean you should be ripping out your current integration layer this quarter.
What an AAS submodel actually is, concretely
Strip away the Industry 4.0 branding and an Asset Administration Shell is a standardized digital wrapper around a physical or logical asset — a pump, a robot cell, a whole production line, even a single sensor. The shell itself is mostly metadata: an identifier, references to a manufacturer and asset type, and a collection of submodels that hold the actual technical content.
Submodels are where the substance lives. IDTA (the Industrial Digital Twin Association, the body that stewards the specification alongside groups like Plattform Industrie 4.0) publishes submodel templates for specific concerns: nameplate data, technical data sheets, handover documentation, contact information, carbon footprint, and increasingly things closer to production — capability descriptions, process parameters, condition monitoring data. Each submodel template defines a semantic structure using standardized identifiers (often ECLASS or IEC CDD classifications) so that “temperature setpoint” means the same thing whether Siemens equipment or Festo equipment is emitting it.
Technically, an AAS instance can be serialized as JSON or XML and transported over a REST API defined in AAS Part 2, or increasingly exposed via OPC UA using the companion specification that maps AAS structures onto OPC UA information models. That OPC UA binding matters more than it might seem: it means AAS doesn’t have to compete with your existing OPC UA infrastructure, it can ride on top of it. For plant IT teams, that’s the detail that turns AAS from “yet another integration standard” into something that might actually reduce integration work over time.
Who’s shipping real tooling versus who’s shipping roadmap
The honest answer is: it’s mixed, and the split roughly follows who has skin in the game on the equipment side versus the software side.
Siemens has been one of the more visible companies actually shipping AAS-related capability rather than just talking about it, particularly around integrating AAS concepts into its industrial edge and TIA ecosystem and supporting asset data exchange in ways that align with IDTA templates. Festo and Bosch, both long-time contributors to the IDTA working groups, have real deployment experience feeding AAS-structured data from their own equipment and have published or contributed submodel templates rather than just consuming them — that’s a meaningfully different level of commitment than a vendor bolting on an export button. SAP’s involvement leans toward the enterprise side of the thread: positioning AAS as a way to standardize how asset and product data flows into business systems, which is a sensible lane for an ERP vendor but tells you less about shop-floor readiness.
What you should watch for in any vendor conversation is the difference between “we support the AAS Part 2 API” and “we ship pre-built submodel templates you can populate from your existing equipment data without a custom mapping project.” The first is table stakes and increasingly common. The second is where the real engineering effort — and the real value — sits, and it’s still uneven across vendors and asset classes.
What’s genuinely ready, and what isn’t
Ready now: AAS as a standardized way to package equipment nameplate, technical documentation, and handover data — the stuff that traditionally arrived as PDFs in an email and got manually keyed into your CMMS or MES asset master. This is the least glamorous use case and also the most mature one. If your plant’s biggest digital-thread pain point is OEM documentation and spare-parts data scattered across formats, AAS tooling can address that today without heroics.
Not ready, or ready only with significant integration work: using AAS as a live, high-frequency data channel for production execution — feeding an MES’s work order or quality modules directly from AAS submodels in real time. The submodel templates for process and capability data exist, but the semantic modeling for dynamic production state is still being worked out across industries, and most MES platforms don’t yet have native AAS ingestion — you’re building a translation layer, not flipping a switch. Treat any vendor claim of “plug-and-play AAS-to-MES” with real skepticism until you’ve seen it work against your actual equipment mix.
The buy/build/wait framework
Buy if you’re doing greenfield equipment procurement now and can specify AAS-compliant data delivery in your RFP — getting structured asset data from the OEM at commissioning is worth far less integration pain than reverse-engineering it later, and it costs you nothing extra to ask for it.
Build a pilot if you have a specific, bounded pain point — multi-vendor asset documentation, or onboarding data for a new line — and can scope a submodel implementation narrowly rather than trying to model your whole plant at once. This is where most legitimate 2026 AAS projects should live: contained, well-defined, honestly evaluated.
Wait on treating AAS as your primary MES integration backbone. OPC UA, MQTT Sparkplug B, and ISA-95-aligned interfaces aren’t going away, and they still cover most of what a production MES actually needs day to day. AAS is shaping up to be the layer that standardizes the asset context around those data flows, not a wholesale replacement for them.
What to actually do about it
Don’t launch an “AAS initiative.” Launch a specific integration project — asset onboarding, documentation handover, whatever your actual pain is — and require AAS compliance from vendors where it’s a natural fit for that use case. Ask equipment vendors directly whether they contribute to IDTA submodel templates or just consume them; the answer tells you how much you can trust their roadmap claims. And keep your MES admin and plant IT team looking at this the way they’d look at any standard still consolidating: useful to know, worth specifying in procurement, not yet something to bet a production integration on without a fallback plan.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
