Source-linked AI summary
Towards an Asset Administration Shell Maturity Model
Carsten Ellwein, David Dietrich, Rozana Cvitkovic, Andreas Wortmann
TL;DR
The paper addresses the lack of a widely accepted framework or maturity model for comparing AAS instances. It proposes a literature-derived maturity model based on digital-twin criteria, demonstrates it through exemplification, and reports structured evaluation of development over time while identifying important validation and scope limits.
Problem
Comparing AAS instances lacks a widely accepted methodological framework or maturity model for systematic analysis.
Method
The paper derives an AAS maturity model from established digital-twin definitions and evaluates five dimensions using quantitative sub-maturity scores.
Results
The exemplification shows increasing maturity over time and identifies necessary developments for growing digital twins.
Takeaways & Limitations
The model provides a formalized, quantifiable framework for estimating how closely an AAS functions as a digital twin and supporting development assessment.
Takeaways & Limitations
The model has not yet undergone systematic validation and has limited validity outside AAS use cases intended to implement digital twins.
Abstract
from arXiv · showhide
The Asset Administration Shell (AAS) is increasingly recognized as a fundamental model for the realization of and data exchange between digital twins in manufacturing. An AAS defines a hierarchical data structure to represent any type of asset throughout its entire lifecycle. In the context of AAS-based systems, comparing different AAS instances constitutes a practical challenge, as neither a widely accepted methodological framework nor a maturity model are available to systematically support such analyses. To address this gap, we propose a novel concept of AAS maturity that characterizes the extent to which established digital twin criteria are met and thus enabling comparability of AAS instances. The concepts are derived from the literature and applied through exemplification. These emerging results enable practitioners and researchers to systematically compare AAS instances and support the identification and assessment of further development steps in the digital twin engineering process.
1 Introduction
Digital twins support understanding, design, operation, and management of cyber-physical systems, while manufacturing uses AAS as a key technology for representing them. The paper addresses how to assess AAS maturity and compare implementations.
- The Asset Administration Shell is a key technology for representing and implementing manufacturing digital twins across an asset’s lifecycle.
- The paper is organized around digital-twin and AAS background, maturity modeling, exemplification, limitations, related work, future plans, and conclusions.
2 Background
Digital twins are software representations of cyber-physical production systems that provide services and maintain connections for data exchange. The AAS supplies a lifecycle-oriented, hierarchical representation of assets and supports heterogeneous content through standardized structures and templates.
- 2.1 Digital Twin: Digital-twin definitions emphasize either automated data flow, the five-dimensional structure of physical objects, data, models, services, and connections, or capability categories.
- 2.1 Digital Twin: A manufacturing digital twin is a software system representing a cyber-physical production system, complemented by services and connected for bidirectional data exchange.
- 2.2 Asset Administration Shell: The AAS is an emerging potential standard and ISO 23247 representation layer for manufacturing digital twins, modeling products, processes, and resources.
- 2.2 Asset Administration Shell: An AAS is intended as the single-source digital representation of an asset throughout its lifecycle and must store or reference heterogeneous information.
- 2.2 Asset Administration Shell: The AAS metamodel organizes an AssetAdministrationShell into submodels whose SubmodelElements represent attributes such as properties, ranges, files, and references.
- 2.2 Asset Administration Shell: IDTA submodel templates promote consistency and interoperability by specifying identifiers, semantics, examples, and links to established dictionaries.
3 AAS Maturity
The maturity framework evaluates an AAS as a digital-twin implementation using five dimensions derived from established digital-twin definitions. It computes sub-maturity scores and averages them into an overall estimate, while acknowledging use-case and evaluation boundaries.
- AAS maturity is assessed across connections, data, services, physical entities, and virtual models, with percentage scores combined into an overall academic maturity level.
- Connection maturity scores each connectable submodel element as 0 for no communication, 0.5 for partial InOut communication, or 1 for indicated communication.
- Physical-entity maturity distinguishes absent, conceptual, and present standalone assets, while model maturity weights required and optional elements and balances existing against expected submodels.
- Data maturity emphasizes whether information can be updated, using the ratio of connectable submodel elements to all submodel elements.
- Service maturity averages six DTC CPT categories, with category-specific scoring that includes binary fulfillment for Data Services and Integration and weighted scoring for Intelligence.
- The overall maturity M is calculated as the average of the five sub-maturity levels.
- The resulting spider-chart maturity level estimates how close an AAS is to the most developed AAS under digital-twin requirements, without implying that it suits every use case.
4 Exemplification
The exemplification applies the maturity model to a five-axis milling machine AAS across engineering phases, showing increasing maturity and the developments needed for digital-twin growth.
- Early engineering phase: The early AAS uses estimated, partly unvalidated technical values and manually updated connection elements, while many available elements lack connections.The connection-relevant elements include feed rates, spindle speed, and dimensions.
- Early engineering phase: Approximately 16% overall maturity is obtained for the early standalone AAS, with model maturity near 10% and physical-entity maturity at 50%.The early AAS contains two submodels, while eight are expected; required elements receive 75% weighting.
- Detailed design phase: The detailed-design phase adds validated engineering artifacts and increases model maturity to approximately 70% and data maturity to approximately 57.5%.Added submodels cover handover documentation, simulation models, 3D models, capability descriptions, and control component instances.
- Operational integration: Despite structural and simulation submodels, operational integration still requires bidirectional connectivity with the manufacturing execution system and automated asset-management synchronization.The customer can use the completed evaluation to order and plan shop-floor integration, while optional values are integrated into software systems later.
- The milling-machine case demonstrates increasing AAS maturity over time and identifies necessary developments across the engineering process.The scenario follows a five-axis machine controlled by Beckhoff TwinCAT before investment and operational deployment.
5 Discussion
The discussion emphasizes that the maturity model is intentionally simplified and remains only partially validated, limiting its resolution and applicability claims.
- Simplifying assumptions and discrete scoring may limit measurement resolution in practical applications.The paper states that sufficient differentiation of AAS maturity remains to be determined.
- The model assumes that an AAS is intended to implement a digital twin, so validity may be limited or misleading for other AAS use cases.Dependencies between maturity dimensions can produce incorrect assumptions outside that intended context.
- Statements about an AAS’s applicability to a specific use case can currently be made only to a very limited extent.
- Although experts were interviewed during development and the model was exemplified, systematic validation has not yet been performed.
6 Related Work
Related work covers AAS types, digital-twin readiness assessment, and broader capability or maturity models, while highlighting gaps in differentiation and practical evaluation.
- The AAS specification defines file-based, API-based, and peer-to-peer types but provides no additional differentiation criteria, leading stakeholders to interpret them differently.
- Technology Readiness Levels describe a digital-twin system’s development stage and industrial applicability but do not evaluate the AAS’s actual alignment.The paper therefore considers TRL alone insufficient for overall AAS maturity.
- The DTC CPT and another 27-criterion quantitative model are characterized as broad, over-specified, and complex for practical applications.
- A related maturity model extends digital-twin definitions with Cognitive DT and Federated DT levels, addressing a different maturity framing.
7 Future Plans
Future work targets formal evaluation, less subjective weighting and tooling, systematic AAS-instance comparison, and reference-based suitability assessment.
- Empirical Evaluation: The model will be evaluated across application scenarios through expert interviews and benchmarking against established models.The methodology is described as emerging research without formal validation.
- Weighting and Tool Support: Design guidelines and software tooling are planned to support weighting, balancing, parameter selection, and maturity computation.The weighting of required elements and balance level currently affect the calculated maturity.
- AAS Compatibility: Future compatibility work will compare AAS instances by applying the hierarchical metamodel and examining proportional distributions at each layer.The unresolved issue is deciding the level at which complex AAS instances should be compared.
- AAS Suitability: A future suitability assessment will compare an AAS with a reference or template defining an application’s minimum requirements.The planned dimensions are structural conformity, semantic consistency, cardinality, and conformity to specification.
8 Conclusion
The paper introduces a formalized, quantifiable method for assessing AAS maturity in runtime environments. Illustrative examples demonstrate its applicability and support structural comparison of AAS implementation status.
- The proposed maturity model formally and quantitatively assesses how extensively an AAS functions as a digital twin in its runtime environment.
- Illustrative examples substantiate the method’s applicability and demonstrate the necessity of the model compared with related work.
- The model provides a first step toward structurally comparing AAS implementation status and identifying further development steps.