Discover how the Asset Administration Shell (AAS) and metaphactory transform industrial data exchange. This post explores how knowledge graphs and AI enhance AAS for interoperable digital twins and compliance with regulations like the Digital Product Passport (DPP).
AI, Knowledge Graphs and Asset Administration Shell for Industry 4.0
Image: Enabling interoperability through standard-based approaches, free from vendor lock-in*.
In today’s industrial landscape, managing and exchanging data efficiently is a major challenge. While many proprietary solutions exist that can address specific problems, organisations, systems and devices often use different and incompatible formats. This lack of standardization often creates barriers to collaboration and data exchange that make it challenging to make critical business decisions, especially on a global scale. To foster a resilient supply chain or have smooth asset handover, along with many other use cases, an interoperable and common approach is necessary.
Additionally, regulations like the European Sustainability Reporting Standards (ESPR), Right to Repair, and measures such as the Battery Passport and Digital Product Passport (DPP) require standardized and interoperable data exchange.
The DPP is designed to digitally capture and communicate key product information—including details related to sustainability, circularity, and compliance—across the entire value chain. Over time, DPPs will be introduced for different product categories sold in the EU, in accordance with ESPR and related legislation. For example, starting 18 February 2027, a DPP will be mandatory for certain types of batteries.
In this blog post, we explore the Asset Administration Shell (AAS) as a key enabler for DPPs and interoperable digital twins and discuss the role of metaphacts and our product, metaphactory. We’ll highlight how knowledge graphs and semantic technologies can enhance your AAS-based solution, making it more powerful and ready for LLMs and GenAI.
Table of contents
What is the Asset Administration Shell and Why Do You Need it?
In an increasingly connected world, businesses must exchange data efficiently to streamline operations, improve compliance and enhance decision-making. However, data formats and systems differ widely across industries, making seamless data exchange a major challenge.
This is where the Asset Administration Shell (AAS) comes in—a standardized digital representation of physical and virtual assets that serves as a crucial enabler of interoperability.
One of the most pressing issues in data exchange arises from the prevalence of proprietary formats. Many companies maintain well-structured, searchable product catalogs, but each often uses its own unique format. This diversity complicates the integration of information across systems. If businesses could converge on a common format or at least provide exports in a standardized format such as AAS, it would significantly simplify the process of delivering integrated solutions. The ability to seamlessly consolidate data from multiple sources can unlock greater efficiency, improve data quality and enhance the speed of decision-making.
The problem is further magnified when dealing with a large network of suppliers. Each supplier may provide asset information in its own format, making it nearly impossible to exchange, aggregate or process data efficiently, resulting in a challenge which is particularly evident in complex industries like automotive manufacturing, where supply chains involve numerous stakeholders. Recognizing the need for interoperability, Catena-X was developed to promote standardized data exchange. It uses the Asset Administration Shell (AAS) as a digital representation of assets to enable consistent, machine-readable communication. Catena-X is an open, collaborative data ecosystem for the automotive industry, supporting secure and interoperable data sharing across the entire value chain.
AAS, as an IEC 63278 standard, allows a uniform way to represent assets, via a so-called metamodel. But besides that, from a technological perspective, standardized interfaces like REST API would allow us to manipulate and exchange information in an interoperable way. In addition, there are various serialization formats in XML, JSON and also RDF (Turtle or JSON-LD) ensuring wide coverage of use cases for data exchange. You can think of AAS as the USB-C of digital twins—a universal standard for seamless data exchange and interoperability.
Concepts in a Nutshell
Before we jump into examples of AAS use cases, below are definitions for some key terms you’ll need to know:
“Asset”: An asset is the entity that we want to digitally represent - It’s the “thing” the digital twin is all about.It can be physical (e.g., a machine, a sensor, a manufacturing component) or non-physical (e.g., software, a service, a process).
“AssetAdministrationShell”: The Asset Administration Shell is the digital representation of an asset. It acts like a digital identity card or envelope, containing all the important data and functions related to that one asset. Each AAS is linked to exactly one asset, and it provides a structured, machine-readable way to access its information.
“Submodel”: A submodel organizes information. Each submodel is self-contained and focuses on a specific aspect of the asset—such as maintenance, technical information or documentation. Submodels contain Submodel Elements.
“SubmodelElement”: Submodel Elements are the building blocks of a submodel. They store the actual data and can take many forms: values, documents, multilingual texts, binary data, or even lists and structured groups. These elements help capture complex information in a structured and consistent way.
“ConceptDescription”: A Concept Description defines the meaning behind the data. It provides semantic context—like units, definitions or reference terms—so that everyone (and every system) interprets the information in the same way.
Example of Asset Administration Shell in practice
Let’s walk through a simple example to make these concepts more concrete. We’ll use the example of wanting to create a digital twin for an electric motor in a factory.
1. Identify the asset
First, we’ll need a way to uniquely identify the physical motor. The asset requires a unique identifier which can be based on IEC 61406, GS1 Digital Link, ISO/IEC 15459, RFIDs, and so on. Let’s say there's a QR code sticker on the motor that contains a globally unique ID. In AAS terms, this ID is referred to as the globalAssetId—it allows any system to know exactly which physical asset the digital twin refers to.
So for our example we assume our asset can be uniquely identified with the following identifier:
R88M-1M40030H-S2
Image: A physical asset, uniquely identified using a QR code*
2. Create the Asset Administration Shell (AAS)
Next, we’ll have to create an Asset Administration Shell for the motor. As such, the AAS will need its own unique identifier, separate from the asset itself. Then, we link this AAS to the electric motor using the globalAssetId. Since we are describing a real, physical motor (not just a product type or template), we set the assetKind to Instance. However, AssetAdministrationShell does not contain the actual data of the asset itself. Instead, runtime data is stored within Submodels, and AssetAdministrationShell only holds a link to those Submodels.
For now we assume in our example that:
AAS (ID: AAS_ElectricMotor_001)
Asset Information:
- globalAssetId: R88M-1M40030H-S2
- assetKind: Instance
Submodels:
- Submodel (ID: SM_Nameplate_001) (We only have a link to the Submodel)
3. Add submodels
Now we need a submodel to keep the properties and various attributes about our asset.
We have various kinds of SubmodelElements to use, but we keep our example simple:
Submodel: Digital Nameplate (ID: SM_Nameplate_001)
- ManufacturerName: "ACME Motors Ltd."
Semantic ID (we will explain this later): 0173-1#02-AAO225#004
- MaxRotationSpeed: 3000
Semantic ID: 0173-1#02-BAA120#010
(Unit: RPM → defined in Concept Description)
- MaxPowerConsumption: 1.5
Semantic ID: 0173-1#02-AAI767#005
(Unit: kW → defined in Concept Description)
4. Define concept description
Each SubmodelElement needs to have a clear semantics and description. When we talk about semantics, we really mean to have a proper way to ensure two parties are talking about the same thing. If two properties mean the same thing but have different names, we can refer to a ConceptDescription via an attribute called "semantic Id", to ensure that they refer to the same concept. Here as an example, we can have a Property that is called “ManufacturerName”, but the semanticId points to a ConceptDescription that contains the meaning of this Property.
This is where the role of common vocabularies comes into play. For example, IEC 61360 is a standard that defines how such a dictionary should be constructed, and IEC Common Data Dictionary (CDD) and ECLASS are among the examples. The image below shows an example property definition in IEC CDD. The description of our AAS element, “ManufacturerName”, corresponds to the IEC CDD entry with the preferred name “name of manufacturer.”
Image: “name of manufacturer” defined in IEC CDD (source)
These dictionaries classify products, their attributes and assign unique identifiers to them so that everyone can refer to them using a consistent, standardized definition. You can also use semanticId to refer to external links, pages, vocabularies or other artifacts. In this direction, elements within AAS can carry the meaning by referring to these external dictionaries and controlled vocabularies. While this may not be as sophisticated as semantic modeling with OWL, which includes complex logical constraints and ontological realism, this straightforward approach is still powerful enough to ensure a shared understanding across different systems.
At the end, we would end up with a very simple AAS for our asset which is visualized as a graph in the image below.
Image: Our simple example visualized as a graph
Common questions about AAS
Can I reuse submodels?
Yes, that's the idea of Submodel Templates. Each Submodel is typically designed for a specific use case. A panel of experts typically creates a Submodel by assembling modeling elements defined in the AAS Metamodel—for example, SubmodelElements such as File, MultiLanguageProperty, RelationshipElement, and others. In order to not re-invent these Submodels for common use cases, we have Submodel Templates. You can think of it as pre-built blueprints and without any specific value. When they are filled with value, they are called Submodel Instances, such a modular workflow is depicted in the image below.
Image: Building a digital twin with the building blocks of AAS
Why is the ID of AAS different from the ID of Asset?
Decoupling AAS identifier from asset identifier technically enables multiple AAS for a single asset in specific use cases, allowing each stakeholder to maintain, manage and host their own separate AAS for the asset. An asset can go through various lifecycle stages with different stakeholders involved, as depicted in the image below. Decoupling the Asset from the AAS allows creating new AAS instances with relevant data, reflecting different perspectives over time. This approach ensures adaptability even if the original manufacturer is no longer responsible or no longer exists.
Image: An asset goes through various phases, AAS provides a common ground to exchange information*
Open Ecosystem
Ultimately, using the elements of the AAS metamodel, we can model products, assets and entities while enabling seamless data exchange and interaction. However, without proper tooling and software components, it would be quite hard to adopt.
Open-source tools like Eclipse Package Explorer can support AAS modeling. If you need offline data exchange you can also use the AASX format, but if you want to use the REST API you can host your AAS. With other tools like Eclipse BaSyx or Eclipse FA³ST you can host your digital twin. For example, if we need integration with OPC UA/MQTT data sources to fetch live data from the asset, we need a hosting solution. If you need to write a program and interact with AAS in an programmatic way, you can use aas-core-works SDKs that are provided in various programming languages. The image below outlines the available open-source tools within each category. Each tool offers its own unique features, so using a combination of them is often possible—and even beneficial.
Image: AAS Tooling Ecosystem
A strong open-source ecosystem is essential for promoting interoperability and widespread adoption of AAS, but naturally there are also enterprise solutions available like metaphactory, which offers a wide range of features for modeling and managing AAS, including powerful visualization capabilities and a Web-based editor with input validation. It also provides additional functionalities, which will be described in the next section.
The whole ecosystem relies on open-source toolings and transparent development. Often you need a mix and match between different tools and they all work together seamlessly because they rely on the same structures. One of the advantages of AAS is that the whole standard is not just a PDF file behind a paywall, it is completely open, in Antora AsciiDoc-based format (https://github.com/admin-shell-io/aas-specifications) and all issues and discussions are available on GitHub.
Where do AAS and metaphactory meet?
Interoperability is one of metaphacts’ core principles as a company. Our product metaphactory relies on RDF and other W3C standards. metaphactory is an enterprise knowledge graph platform that transforms data into consumable, contextual and actionable knowledge. It simplifies capturing and organizing domain expertise in explicit semantic models, extracting insights from your data and sharing knowledge across the enterprise.
AAS also comes with a semantic rendition. The RDF representation of AAS is more than yet another serialization format. AAS is inherently a graph model—think about the Bill Of Materials: With the help of “RelationshipElement”, “AnnotatedRelationshipElement” and “Reference”, we have the capability to have a link between entities. Such a linked structure is much more cumbersome to handle in other formats and other data storage solutions, especially if you need queries to navigate through such complex and connected structures. The RDF representation of AAS brings together all the advantages of the W3C semantic technology stack such as SPARQL query language to query the Asset Administration Shell in an interoperable way. Also, SHACL can be used for data validation.
With metapactory’s visualization components, you can discover and leverage the knowledge within your data and visually explore AAS. Submodels can be viewed as a graph as we can see in the image below. With metaphactory’s configurable components you can easily create your own custom visualizations on-demand.
Image: Content of AAS visualized as a graph
Moreover, metaphactory comes with a visual and intuitive ontology and vocabulary authoring and management system, successfully supporting Semantic Knowledge Modeling across a number of customer use cases. If you want to define your own concepts or create domain models, our product provides powerful features to support you. Additionally, since ECLASS includes an RDF representation, metaphactory fully supports it as well. This allows you to leverage both AAS and ECLASS simultaneously to build your digital twin, as depicted in the below image.
Image: ECLASS entities—such as Aspects, Blocks and Properties—can be visualized as a graph and used to define the semantics of elements within an Asset Administration Shell (AAS). In this example, the concept of “Electromagnetic Compatibility” is represented, encompassing various aspects like “Valve Connector,” which includes related properties such as “External Cable Diameter”.
In addition, you might already have an existing OWL-based ontology for your domain, as well as instance data. However, your industry partner might require AAS for compatibility reasons. In this scenario, you can export your existing models and transform the instance data in AASX format. As shown in the image below, we have an ontology featuring two entities—"Product" and "Manufacturer"—along with their relationship. In this simple example, an AASX package file can be exported using a configurable process to guide the transformation. The configuration can be handled through different approaches, depending on the specific requirements.
Image: A simple ontology for Product and Manufacturer with the ability to transform instance data to AASX Package format
Since metaphactory is compliant with the AAS standard, you can easily convert your RDF representation to the JSON or XML representation of AAS and use it in other external tools like Eclipse BaSyx, Eclipse Mnestix or AASX Package Explorer (see image below).
Image: Exported AASX Package visualized in AASX Package Explorer
Our contribution to the AAS Ecosystem
metaphacts participates in the IDTA Ontology Workgroup to bring our decades of experience with semantic technologies in this workgroup. There are a number of issues and challenges within the current RDF representation. Issues are identified, but iterating through all possible options, evaluating the pros and cons of each of them, and discussing the implications and side effects of those decisions requires some time. In future, we are also considering bringing our knowledge graph and AAS expertise to other open-source solutions such as AAS4j to help foster the adoption of AAS RDF.
Interoperability with Other Standards
One might naturally ask “Why should we be forced to use AAS? Why does it matter? Many other initiatives have spent millions on solutions—how can they possibly adopt AAS?”
This is a fair question. You don’t need AAS—until you try to participate in a broader ecosystem, exchange data across company boundaries, or work toward shared goals within a value chain. In reality, silos exist—not just in data, but also in standards, ontologies, and interpretations. While industries have invested heavily in different frameworks, we still need a common language to collaborate.
The idea of a one-size-fits-all solution is unlikely to work, as each industry and sector has its own unique requirements. For example, in healthcare, HL7 FHIR serves as a standardized framework for representing patient data. In the Oil & Gas and process industries, standards like DEXPI and CFIHOS play a similar role in ensuring interoperability. These standards are deeply embedded and not going away.
In standards-based solutions, everyone must pack data into the exact same fields and structure. This rigidity ensures consistency and predictability, but it can be inflexible when needs change. Beyond standards-based interoperability, ontology-based methods offer not just an alternative but also a compelling complementary approach. Ontology-based approaches offer a more agile way to create a shared understanding on a specific domain. In this context, Basic Formal Ontology (BFO) (ISO/IEC 21838-2:2021) serves as a general upper-level ontology, while the Industrial Data Ontology (IDO) (ISO/CD 23726-3) acts as an industrial upper-level ontology.
However, neither approach is a silver bullet. Even if you use OWL, you still need to align the terms you use. If two companies have different ontologies for “pump pressure” or “motor speed,” the systems won’t interoperate until someone maps those terms. In other words, there’s no “magic” layer that makes arbitrary ontologies automatically merge–mutual agreement or mapping is mandatory.
AAS is not here to replace what exists—it is here to bridge the gap. The future is not about one standard ruling all, but about standards that work together. The question should not be ‘Why adopt AAS?’, but rather how can we create an ecosystem where different solutions talk to each other seamlessly? The image below illustrates how a knowledge graph (based on RDF) serves as the integration layer that connects a wide range of standards, ontologies and domain-specific models. The metaphactory platform sits on top, providing tools for interacting with and managing this unified knowledge space.
.jpg)
Image: Standards and Ontologies Converging in a Knowledge Graph: metaphactory enables flexible integration across heterogeneous models—standards-based and ontology-driven—by using RDF as a unifying layer
At metaphacts, our goal is to incorporate these diverse standards and methodologies into a flexible, commercial-grade solution that delivers an intuitive user experience—without any vendor lock-in.
Try it for yourself
We are here to guide you through your journey. AAS can be utilized in various contexts, especially Digital Product Passport. If you are implementing AAS or working with semantic models of products, we can unlock even greater value based on our knowledge-centric approach. Our experts are ready to discuss your specific needs and demonstrate how metaphactory can support your organization.
When working with AAS, metaphactory delivers key benefits that allow you to make the most of AAS’s inherent graph structure :
-
Built-in semantic search to explore information
-
Ability to create the semantics for AAS (via ontologies and controlled vocabularies)
-
Integration with ECLASS RDF
-
Ability to create tailored graph-based visualizations with our model-driven approach
-
Instance authoring with SHACL data validation
Want to see AAS and Knowledge Graphs in action? Schedule a demo to see how metaphactory can transform your data management.
*These images were generated using AI.