arXiv:2609.17084v1 [cs.SE] 15 Sep 2026
Towards an Asset Administration Shell Maturity Model Carsten Ellwein∗†
David Dietrich∗
[email protected] ISW, University of Stuttgart Stuttgart, Germany
[email protected] ISW, University of Stuttgart Stuttgart, Germany
Rozana Cvitkovic∗
Andreas Wortmann∗
[email protected] Blue Yonder GmbH Stuttgart, Germany
[email protected] ISW, University of Stuttgart Stuttgart, Germany
Abstract
1
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.
Digital twins [24, 42] are increasingly serving as the foundation for improved understanding, design, operation, and management of cyber-physical systems (CPS) [9]. Although the software engineering community is largely responsible for developing the technologies that enable DTs [36], manufacturing remains one of the main fields exploring their application [9]. In manufacturing, a DT is a virtual counterpart of a real cyber-physical production system (CPPS) [13], implemented and operated within a software environment [33]. Different DTs perform distinct roles, such as supporting analysis [35], enabling control [44], or predicting behavior [41]. To create DTs, various kinds of models have been proposed [26, 31], ranging from UML [32] and derivatives, over SysML [14] and AutomationML [25], to the Asset Administration Shell (AAS) [45]. The AAS is a key modeling technology to represent and implement DTs [34] in manufacturing and has been successfully applied to, e.g., predictive maintenance [37], model management [7], and process control [10]. It is conceived as the authoritative digitally instantiated representation of any type of asset throughout its entire lifecycle. Therefore, an AAS is specified as a hierarchical structure of data models, termed submodels, each of which formalizes distinct components, properties, or functional aspects of the asset under consideration. When AASs are developed collaboratively–such as through the integration of supplier-provided submodels into a comprehensive overall model or through the concurrent work of multiple engineering disciplines on a shared single source of truth–challenges emerge with respect to their mutual comparability, their maturity, and their applicability in terms of the intended use. A maturity model offers a systematic and effective framework for such comparisons [47]. However, no maturity frameworks for AAS are known [6]. We aim to close this research gap. Next, Sec. 2 illustrates the state-of-the-art on DTs and AASs, before Sec. 3 showcases the maturity of AASs, when perceived as DT in their runtime environment. Afterward, Sec. 4 illustrates the application of the maturity model. Based on this, Sec. 5 outlines limitations, Sec. 6 discusses related work, and Sec. 7 presents future plans. Sec. 8 concludes.
CCS Concepts • Theory of computation → Theory and algorithms for application domains; • Information systems → Enterprise information systems; Data management systems; • Software and its engineering → Software organization and properties.
Keywords Digital Twin, AAS, TRL, Compatibility, Capability ACM Reference Format: Carsten Ellwein, David Dietrich, Rozana Cvitkovic, and Andreas Wortmann. 2026. Towards an Asset Administration Shell Maturity Model. In ACM/IEEE 29th International Conference on Model Driven Engineering Languages and Systems (MODELS 2026), October 04–09, 2026, Málaga, Spain. ACM, New York, NY, USA, 7 pages. https://doi.org/10.1145/3822455.3838765 ∗ All authors contributed equally to this research. † Corresponding author.
This work is licensed under a Creative Commons Attribution-NonCommercialNoDerivatives 4.0 International License. MODELS 2026, Málaga, Spain © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2809-9/2026/10 https://doi.org/10.1145/3822455.3838765
Introduction
2 Background 2.1 Digital Twin A common definition within academia distinguishes DTs from models and digital shadows based on their automated data flow [24].
MODELS 2026, October 04–09, 2026, Málaga, Spain
Although models are not connected to their physical counterparts, there is an automated connection between the physical object and its digital shadow or digital twin, for data exchange. For digital shadows, this exchange is unidirectional - the digital shadow automatically receives data from the physical object. In contrast, the digital twin closes the control loop and is capable of sending instructions back to its physical counterpart. Another academic definition focuses more on the structure of the DT than on the data flow between the digital object and its physical counterparts [42]. According to this definition, referred to as the 5D model, a DT consists of: (i) the physical object itself, (ii) data from and about the physical object, (iii) models of the physical counterpart as well as models of the DT itself, (iv) services related to the physical object, and, as in the previous definition (c.f. [24]), the (v) connections between all elements of these dimensions. In this 5D model, every component is linked by bidirectional connections. Therefore, services can directly access real-time data from the physical system and issue commands to it. In addition, the services and the physical system can read, write, update, and delete the data and models provided by the DT. A popular industrial definition of the DT is the Capabilities Periodic Table1 (CPT), published by the Digital Twin Consortium (DTC), part of the Object Management Group (OMG) and an association community within the US American non-profit trade association Enterprise Data Management (EDM). The CPT is characterized as a requirements definition framework that is independent of any specific architecture or technology. According to the CPT, DTs can implement the following categories of capabilities: (i) Data Services, (ii) Integration, (iii) Intelligence, (iv) user interaction (UX ), (v) Management, and (vi) Trustworthiness. Data services (i) include data management processes such as acquisition and ingestion, interpretation of data using ontologies, management of data through a model repository, and various data handling methods such as pub/sub, batch processing, and data aggregation. Integration (ii) refers to integration approaches that employ platforms, APIs, and enterprise systems to connect both higher-level, more abstract systems and lower-level, more detailed systems. Intelligence (iii) includes components and services for reasoning, planning, machine learning, simulation, and other capabilities that can be considered intelligent. UX (iv) includes all system features that support monitoring, such as visualization of data, models, and their relationships, as well as interaction mechanisms including gamification and business intelligence methods, without directly affecting the machine. Management (v) functions are mainly concerned with the control and manipulation of the system. In this context, logging and data-related methods are advised for interpreting and configuring devices and machines. The trustworthiness (vi) capabilities comprise all features that contribute to the overall trustworthiness and reliability of the system. Another, industrial driven definition is ISO 23247 [43], an international standard that establishes a framework for DTs in manufacturing. The standard identifies five elements of a DT framework: (i) Data Services, (ii) System Components, (iii) Interfaces, (iv) Instances, and (v) Observable Manufacturing Elements. In contrast to the 5D model (cf. [42]), according to ISO 23247, the digital representation 1 https://www.digitaltwinconsortium.org/initiatives/capabilities-periodic-table/
C. Ellwein et al.
Figure 1: AAS metamodel [49] of the object (i.e., the DT) provides the interface for services to communicate with the physical counterpart. In summary, a DT in manufacturing can be described as a software system [33] that represents a CPPS [24], complements it with software services [42] and is connected, allowing bidirectional data exchange [24, 42].
2.2
Asset Administration Shell
In Industry 4.0 (I4.0), any element owned by an organization that contributes value to process execution is referred to as an asset [7]. Assets may be tangible, such as production equipment, workpieces, or even an entire factory, but can also be intangible, including models to describe machine behavior, software, or licenses [17]. The AAS [46] is emerging as a potential standard for representing and implementing DTs [34], proposed as the definition and representation layer within ISO 23247 [43]. The development of AAS is driven by the Industrial Digital Twin Association (IDTA) [5], an industry-oriented association related to the Association of German Mechanical Engineering Companies (VDMA). The AAS is used to model products [16], processes [10], and resources [8] and is intended to be the single source of truth digital representation of an asset throughout its entire life cycle [4]. As the AAS contains relevant information throughout the lifecycle of an asset, it must be able to represent many types of content, including properties, modeled functions, parameters, an overview of integrated components, data generated during manufacturing or simulation, and descriptive information such as usage instructions and technical specifications. This requires the capability to store or reference heterogeneous data types [7]. The structure of the AAS is specified by a metamodel (cf. [4]). The main subset of the class hierarchy related to the submodel structure of the AAS is illustrated in Fig. 1. At the highest level, the AssetAdministrationShell class represents the entire AAS of an asset. It can include multiple submodels, represented by the Submodel class, each of which describes specific attributes of the asset. The individual attributes that make up a submodel — such as properties and files — are modeled by the abstract class SubmodelElement. The abstract class DataElement is derived from SubmodelElement and serves as a base for additional concrete classes. The classes Property, Range, File, and ReferenceElement model different kinds of asset attributes. The Property encapsulates an information pair consisting of a single value and its data type, while Range specifies two values together with their shared data type. File denotes the
Towards an Asset Administration Shell Maturity Model
type and location of a file, while ReferenceElement defines a logical reference to either another element within the same or a different AAS, as well as external references. To promote consistency and interoperability, the IDTA offers so-called submodel templates. These submodel templates are also standardized and made publicly accessible via their Content Hub2 . Every parameter within a submodel template is defined by an identifier, its semantics, and an illustrative example. The semantics are aligned with established dictionaries, such as the ECLASS3 reference data standard for the unambiguous specification of products and services and the IEC Common Data Dictionary (CDD), referred to as SemanticID.
3
AAS Maturity
In order to determine the maturity and thus the completeness of an AAS as a DT implementation, it is advisable to use the previously established definitions as criteria. For this reason, the framework presented here is based on the well-known DT definitions data flow, 5D model, and the DTC CPT. The five components of the 5D model (cf. [42]), connections, data, services, physical entities, and virtual models serve as independent dimensions of maturity. A percentage value is calculated for each of these, representing the respective maturity. All dimensions taken together then determine the overall academic maturity level of the AAS. The maturity level M𝐶 for connections is based on data flows [24], which describes a categorization of the connections to CP(P)S. To derive connectable submodel elements, they are indicated by a custom concept qualifier of type “Connection” and the possible values “Input”, “Output”, or “InOut”. The connection of each element 𝑖 containing this qualifier type is then determined as 0 𝑐𝑖 = 0.5 1
if no communication, if partial communication of InOut connections, and if the indicated communication (1) is present. The presence of such a connection can be derived from asset management systems or the submodel “Asset Interfaces Mapping Configuration” [22] (IDTA 02027). The dimension of connectivity M𝐶 for an AAS with 𝑚 connectable submodelelements 𝑐𝑖 is then calculated as the average. For physical entities, the maturity level M𝐸 is distinguished between standalone assets and composed assets that contain subcomponents. For standalone assets the maturity is divided into three ordinal stages and converted using the following linear scale: 0% M𝐸𝑠𝑖𝑛𝑔𝑙𝑒 = 50% 100%
if no physical asset exists at all, if a concept for the physical asset exists, if the physical asset is present.
(2) For composed assets including a bill of material (BOM), the maturity level M𝐸𝑐𝑜𝑚𝑝𝑜𝑠𝑒𝑑 is calculated as the average based on its 𝑛 direct subcomponents 𝑖 indicated as 𝐸𝑖 . For multi stage BOMs this results in a recursive calculation. 2 https://industrialdigitaltwin.org/en/content-hub/submodels 3 https://eclass.eu/en/eclass-standard
MODELS 2026, October 04–09, 2026, Málaga, Spain
The maturity level M𝑀 of the virtual models depends on how fully these models are completed. To do so, the cardinality of the templates indicating required and optional values are used. In the IDTA specification they are indicated by the qualifier “SMT / Cardinality” with its possible values “ZeroToOne”, “One”, “ZeroToMany” and “OneToMany”. Let 𝑅 be the set of required elements and 𝑂 the set of optional elements in submodels in an AAS. Let 𝑟𝑖 ∈ {0, 1} indicate whether the required element 𝑖 is present and 𝑜 𝑗 ∈ {0, 1} whether the optional element 𝑗 is present. For an existing AAS (or also submodels or submodel element collections), the maturity ! 1 ∑︁ 1 ∑︁ 𝑟𝑖 + (1 − 𝑤𝑟𝑒𝑞 ) · 𝑜𝑗 (3) M𝑀 = 𝐵𝑀 𝑤𝑟𝑒𝑞 · |𝑅| 𝑖 ∈𝑅 |𝑂 | 𝑗 ∈𝑂 is calculated based on the weighting 𝑤𝑟𝑒𝑞 ∈ [0, 1] of required elements, as well as a further balance level 𝐵𝑀 . The weighting as well as the balance level need to be defined by users of the maturity framework based on the desired evaluation, e.g. the weighting of optional values may be lower in early lifecycle phases. As further submodels may be expected, but not yet added in the AAS, the balance 𝐵𝑀 = 𝑓 (𝑀𝑆𝑀,𝑒𝑥𝑝 , 𝑀𝑆𝑀 ), which compares existing and expected submodels as a percentage, is required to calculate the maturity level of the AAS. The data within the models is examined to determine the maturity level M𝐷 for the Data component. The main focus here is on the actuality of the information, that is, whether the data can be updated. Thus, the maturity M𝐷 =
𝑀𝑠𝑚𝑒,𝑐𝑜𝑛 𝑀𝑠𝑚𝑒
(4)
is calculated as a quotient of the number of all available submodel elements requiring a connection 𝑀𝑠𝑚𝑒,𝑐𝑜𝑛 , as in the introduced qualifier of connectable elements, over the number of all available submodel elements 𝑀𝑠𝑚𝑒 in the AAS. Services are diverse in nature, as they can, for example, provide data from the AAS, perform important functions for the runtime environment, or prepare information for end users. This diversity creates challenges in determining the maturity level of services M𝑆 . The DTC CPT shows the diversity of services and categorizes them into six different areas. The category Data Services (DS) includes services that deal with data processing and data management. Examples include data streaming, batch processing, and real-time processing. The data services have different approaches to data processing and are therefore mutually exclusive within a system, meaning that only one or a few services of this type would be present in the system at any given time, rather than all of them. This leads to the assumption that the full maturity M𝑆𝐷𝑆 =
max
𝑠𝐷𝑆,𝑖 ∈𝑆 𝐷𝑆
𝑠𝐷𝑆,𝑖
(5)
is reached as soon as one service 𝑠𝐷𝑆,𝑖 ∈ {0, 1} exists without gradation in the set of Data Services 𝑆 𝐷𝑆 of DTC CPT. The same applies to the next category, Integration (IR). This category lists various services related to the integration of systems or platforms, such as API services, digital twin integration, and enterprise system integration. Since services are also used for different use cases here, fulfilling one criterion 𝑠𝐼𝑅,𝑖 in the set of integration
MODELS 2026, October 04–09, 2026, Málaga, Spain
C. Ellwein et al.
services 𝑆𝐼𝑅 is sufficient to achieve a maturity of 100%, simular to the data services. For the category Intelligence (IC), the fulfillment of the first criterion plays a central role, whilst additional criteria may add further value. To reflect this, the maturity 1 𝑘𝐼𝐶 (6) 2 is described as a weighted score based on the number of fulfilled criteria 𝑘𝐼𝐶 in the category. Intelligence deals with data analysis and analytics, such as simulation, prediction, and reporting. The same applies to the category UX, which considers the presentation of information and topics that affect the end user, such as basic visualization, gamification, and dashboards. For the category Trustworthiness (TW), all criteria must be met for 100% maturity. A gradation is also possible if not all criteria are met. The maturity 𝑀𝑇𝑊 M𝑆𝑇𝑊 = (7) 𝑁𝑇𝑊 thus, is calculated based on the criteria fulfilled 𝑀𝑇𝑊 out of the possible criteria 𝑁𝑇𝑊 in the respective category. Trustworthiness includes eight criteria related to system security, such as data encryption, security, safety, and privacy. This applies equally to the category Management (MG), which deals with system monitoring. The category includes four services to achieve this in the best possible way, such as event logging and device management. Now, it has been explained how the individual maturity levels for the corresponding categories can be measured. To determine the overall maturity level of the services, the average of the six categories 1 ∑︁ M𝑆𝑖 for 𝑖 ∈ {𝐷𝑆, 𝐼𝑅, 𝐼𝐶, 𝑈 𝑋, 𝑀𝐺,𝑇𝑊 } M𝑆 = (8) 6 𝑖 M SIC = 1 −
is calculated. The maturity level for each of the components of the 5D model has now been assessed. To obtain the overall maturity level 1 ∑︁ M= M 𝑗 for 𝑗 ∈ {𝐶, 𝐷, 𝐸, 𝑀, 𝑆 } (9) 5 𝑗 of the AAS, the average of the five sub-maturity levels must be calculated. When displayed as a spider chart, the resulting maturity level is illustrated in Fig. 3. In summary, the maturity level can provide an initial estimate of how close the AAS is to the most developed AAS in terms of DT requirements. This refers to an academic concept, recognizing that the most advanced AAS is not necessarily the most suitable choice for every particular use case.
4
Exemplification
To exemplify the proposed Maturity Model, we consider the engineering lifecycle of a five-axis milling machine controlled by Beckhoff TwinCAT (cf. Fig. 2). The scenario illustrates how maturity evolves across development phases and stakeholder perspectives prior to investment and operational deployment. During the early engineering phase, the manufacturer creates an initial standalone AAS. It contains the standardized submodels “Digital Nameplate”, containing 4 required and 54 optional elements,
Figure 2: Five-axis milling machine at ISW (left) and its simulation model (right)
and “Technical Data”, containing 4 required and 21 optional elements at this development stage. In order to address the defined application scenario of the AAS, 8 submodels are expected. The “Technical Data” submodel documents planned feed rates and spindle speeds, as well as key construction parameters derived from preliminary calculations. Although structurally compliant with the standardized submodel templates, the values are partly estimated and have not yet been validated against finalized drive configurations. At that time, the submodel elements indicated as connections are the drive feed rates, spindle speed, and dimensions (9 optional elements), even if manually updated. In contrast, 25 available elements (of which 8 are required) of the two templates do not contain a connection. The maturity of the AAS at that time is shown in the inner red polygon in Fig. 3: As neither connection to the CPPS nor services exist, their corresponding maturity M𝐶 = M𝑆 = 0 equals zero. In contrast, the data flow equals M𝐷 = 9/34 ≈ 26.4% due to the share of updated information. Regarding the maturity of the models, the weighting 𝑤𝑟𝑒𝑞 = 75% is assumed to prioritize the required elements. For the balance 1
𝐵𝑀 = 1+𝑒
𝑀𝑆𝑀,𝑒𝑥𝑝 −𝑀𝑆𝑀 2
(10)
a sigmoid function is used including the expected number of the submodels 𝑀𝑆𝑀,𝑒𝑥𝑝 and the current number of submodels 𝑀𝑆𝑀 . The sigmoid function is chosen to represent estimated maturity instead of a completion rate, where early progress is weighted less with an accelerating growth in the middle, when a significant number of submodels is present. The maturity of models thus results in 1 1 17+9 (75% ∗ 4+4 M𝑀 = 1+𝑒 0.5·8−2 ∗ 8 + 25% ∗ 54+21 ) = 0.119 ∗ 84% ≈ 10%. A high maturity can be determined, since all required data of the 2 submodels are present. As the physical entity for the standalone AAS is planned, it results in maturity M𝐸 = 50%. The result is the overall maturity M = 0+0+26.4+3.8+50 % ≈ 16%. 5 In the following engineering phase, the manufacturer completes the detailed design of the drives, leading to slightly modified technical parameters in the Technical Data submodel. Furthermore, validated engineering artifacts are integrated in “Handover Documentation” (IDTA 02004), “Provision of Simulation Models” (IDTA 02005), the “Provision of 3D Models” (IDTA 02026), the “Capability Description” (IDTA 02020) and the “Control Component Instance” (IDTA 02016), resulting in an AAS ready to be delivered together with the resource instance. The increased maturity of the AAS at
Towards an Asset Administration Shell Maturity Model
MODELS 2026, October 04–09, 2026, Málaga, Spain
practical applications, be differentiated with sufficient granularity. Furthermore, the maturity model is based on the assumption that the AAS is intended to implement a DT. In other, theoretically possible use cases of the AAS, the validity of the maturity model is therefore very limited and may be misleading. In particular, dependencies between dimensions can lead to incorrect assumptions in this context. Based on the maturity model presented, statements regarding the applicability of AAS to a specific use case can only be made to a very limited extent. Although the maturity model was applied in the exemplification (cf. Sec. 4) and several expert interviews were conducted during development, a systematic validation of the model has not yet been performed. An initial theoretical differentiation from existing models is presented in the following subsection. Figure 3: Maturity of the milling machine AAS throughout the engineering process
this point is visible in the green polygon in Fig. 3: As no physical asset exists, and thus automated data flow cannot exist, maturities in terms of connection and physical entity remain in mid-range. In terms of services, an intelligent machine control (IR.IO, IC.CC) exists, the data have a basic visualization (UX.BV), and a system monitoring (MG.SM) is available for the manufactured physical = 37.5%. asset, resulting in service maturity M𝑆 = 0+1+0.5+0.5+0.25+0 6 The data and model maturity are calculated similarly to the early AAS, resulting in M𝐷 ≈ 57.5% and M𝑀 ≈ 70% A customer requests the AAS of the milling machine for its integration in a production line. Based on the evaluation, which has already been completed successfully, the customer can order the machine and plan its integration into the shop floor directly using the AAS maturity assessment. Although structural- and simulation related submodels are present, operational integration requires bidirectional connectivity to its manufacturing execution system and an automated data synchronization of the AAS in its asset management system. As the machine is delivered, the customer has already implemented these steps, resulting in the blue-shaded maturity shown in Fig. 3 calculated analogously to the previous examples with a production line ready to use. To reach full maturity in terms of services, the customer already plans a further data processing service and operation-accompanying digital twin for quality evaluation as well as improvements in terms of management and trustworthiness. To achieve that, optional values will finally be integrated into its software systems leveraging the maturity of models and connections. With this exemplification, the previously introduced maturity model is demonstrated. The maturity model shows the increasing maturity over time as well as the necessary developments. In combination, a structured evaluation for growing digital twins is shown.
5
Discussion
The introduced maturity model is based on simplifications in order to remain applicable in practice. Simplifying assumptions and the use of discrete scoring schemes may result in limited measurement resolution. It remains to be determined whether the AAS can, in
6
Related Work
Beyond its metamodel, the AAS specification [4] introduces three different types of AAS: (Type 1) serialized as a file, (Type 2) information retrieval through an API, and (Type 3) peer-to-peer data exchange between AAS using interaction protocols specified in [30]. However, the specification does not provide additional details or criteria to differentiate between these types and their functionalities, which has led to different interpretations by different stakeholders [12]. Whereas AAS type 1 is consistently characterized as a static or passive representation of asset-related information [39], type 2 is described in various ways as an AAS that offers a common interface or a standardized API for data access [21], as capable of reacting to external events [3], as an AAS with decision-making capabilities [18], or as an AAS that incorporates capabilities and skills [2]. Type 3, in turn, is depicted as an AAS that interacts with other type 3 AAS [40], enables communication using the I4.0 language [48], includes service-oriented communication mechanisms [1], or provides decision-making skills [39] with the ability to build multi-agent systems [38]. In summary, types 2 and 3 exchange data with the physical object, thus extending the core functionality and coming close to the definition of a DT according to data flows [24], 5D model [42], or ISO 23247 [43]. However, due to their poor differentiation, the two terms type 2 and type 3 can be used almost synonymously. AAS types therefore do not indicate anything about the maturity of the AAS. The AAS portfolio analysis [12] is based on the AAS types. Although the resulting scheme yields an unambiguous categorization in contrast to the original AAS types, its applicability remains restricted to the specific mode of communication under consideration. The application of the portfolio classification enables a preliminary assessment of maturity along the dimensions of "connection" and "data"; however, when considered in its entirety, it provides substantially less informative value than the model proposed in the present work. The DTC recommends [11] applying Technology Readiness Levels (TRL) [19] to DTs and DT systems as a measure of maturity. The TRL provides information on the condition of the DT system (e.g., the AAS), its stage of development, and industrial applicability. The suggestion to apply TRL is therefore certainly valid from the perspective of an industry association. However, TRL does not provide any information on the actual alignment of the AAS, and statements about stages of conceptual development cannot be inferred.
MODELS 2026, October 04–09, 2026, Málaga, Spain
The TRL alone is therefore not sufficient to evaluate the overall maturity of the AAS. Further models in the literature are the DTC CPT, as a capability model (cf. Sec. 2.1) or the quantitative model [20], which focuses on value, functions, and reliability, and evaluates performance based on 27 criteria. These models are broad, over-specified, and complex for practical applications. The maturity model proposed in [27] builds on the definition of DTs introduced in [24] and extends it by introducing two additional levels: (i) Cognitive DT and (ii) Federated DT. The (i) cognitive DT leverages algorithms, methods, and domain knowledge based on artificial intelligence (AI) to autonomously generate and deliver feedback to the corresponding physical asset. The (ii) federated DT enables shared access to distributed data sources and connectivity interfaces, thus supporting the integration of advanced cross-domain DT applications. Other DT maturity models follow similar approaches and conceptualize adaptive and intelligent [28], autonomous and federated [23], predictive, optimized and autonomous [29], or self-adaptive DTs [41] as subsequent stages in the overall evolution of the DT paradigm. The models, more suited to academic than practical applications, assume that the subject to be evaluated is indeed a DT. This assertion does not universally apply to all AAS; in certain instances, the AAS functions solely as a model [38].
7
Future Plans
The subsequent section presents an overview of the roadmap for future research. This includes the (i) evaluation of the maturity model, (ii) weighting and tooling, as well as future work on the (iii) comparability and (iv) suitability of AAS instances. 1. Empirical Evaluation: As noted in the discussion of limitations (cf. Sec. 5), this methodology is emerging research and has not yet been subjected to formal validation. Future work will involve deploying the model across a range of application scenarios. To perform an evaluation, predictions are systematically assessed through expert interviews. Furthermore, the predictions will be benchmarked against established models (cf. Sec. 6). 2. Weighting and Tool Support: The proposed maturity is calculated based on the weighting 𝑤𝑟𝑒𝑞 of required elements, as well as a further balance level 𝐵𝑀 (cf. Sec. 3). To enhance the comparability of the maturity levels achieved and reduce subjectivity, future research will focus on developing systematic design guidelines for weighting and balancing. Furthermore, we intend to develop and integrate software-based tooling to systematically support parameter selection and the computation of maturity levels.
C. Ellwein et al.
3. AAS Compatibility: An issue that remains unresolved within the maturity model is the methodological comparison of two AAS instances with regard to the parameters they cover. Since AASs are complex constructs, it is necessary to define the level at which the comparison is to be made. Therefore, in future work, the hierarchical metamodel layout [15] will be applied to the AAS. On the basis of the findings, mathematical sum theory will be employed to systematically compare different AAS instances with respect to the proportional distributions observed at each metamodel layer. 4. AAS Suitability: Another aspect, beyond the focus of the maturity model, is the concrete applicability or suitability of an AAS instance to serve as a data basis for a dedicated application. The suitability check will be targeted in future work. The approach will be a reference-based suitability assessment, where the application developer must provide a reference or template AAS that represents the minimum requirement profile. The assessment will be carried out along four central dimensions that address different aspects of the conformity between a given AAS and the requirements of a specific application: (i) structural conformity, (ii) semantic consistency, (iii) cardinality, and (iv) conformity to specification.
8
Conclusion
This paper presents a method for assessing the maturity of the AAS in its runtime environment. The applicability of the method is substantiated through illustrative examples. The necessity of the model introduced is demonstrated in comparison with the related work. The proposed maturity model provides a formalized and quantifiable framework. It provides a general overview of the extent to which the AAS actually functions as a DT. This will impact the further acceptance and interchangeability of AAS technology, as it can provide insights for further development and is the first step towards a structural comparison of the implementation status of two AASs. Furthermore, the future plans present a roadmap for continued research, encompassing both AAS comparability and AAS suitability.
Acknowledgments Partly funded by the Federal Ministry for Economic Affairs and Energy (BMWE) through the projects growING (grant no. 13IPC036G). Partly funded by the German Federal Ministry of Research, Technology and Space (BMFTR) within the “Research Campus – PublicPrivate Partnership for Innovation” funding initiative (02P23Q820) and managed by the Project Management Agency Karlsruhe (PTKA).
References [1] Alejandro López, Oskar Casquero, Elisabet Estévez, Aintzane Armentia, Darío Orive, and Marga Marcos. 2023. An industrial agent-based customizable platform for I4.0 manufacturing systems. Computers in Industry 146 (2023), 103859. [2] Lucía Alonso, Lara Barja, Baltasar Lodeiro, Evangelos Xanthakis, and Raimund Broechler. 2024. Asset Administration Shell Modelling and Implementation Enabling Plug and Produce Capabilities for Modular Production. Flexible Automation and Intelligent Manufacturing (2024). doi:10.1007/978-3-031-38165-2_24 [3] Evi Elisa Ambarita, Anniken Karlsen, Francesco Scibilia, and Agus Hasan. 2024. Industrial digital twins in offshore wind farms. Energy Informatics 7, 1 (2024), 5. [4] Sebastian Bader, Erich Barnstedt, Heinz Bedenbender, Bernd Berres, Meik Billmann, and Marko Ristin. 2022. Details of the asset administration shell-part 1: the exchange of information between partners in the value chain of industrie 4.0 (version 3.0 rc02). Technical Report. Federal Ministry for Economic Affairs and Climate Action (BMWK).
Towards an Asset Administration Shell Maturity Model
[5] Sebastian R Bader and Maria Maleshkova. 2019. The semantic asset administration shell. In Semantic Systems. The Power of AI and Knowledge Graphs: 15th International Conference, SEMANTiCS 2019. Springer, 159–174. [6] Daniel Büttner, Dirk Schöttke, Stephan Schäfer, Sönke Knoch, Daniel Porta, Tim Schwartz, Claudette Ocando Röhricht, Aaron Zielstorff, and Andreas Bayha. 2025. Bridging the Qualification Gap for the Asset Administration Shell: A Modular and Role-Based Learning Framework. (2025), 1–8. [7] Salvatore Cavalieri and Marco Giuseppe Salafia. 2020. Asset administration shell for PLC representation based on IEC 61131–3. IEEE Access 8 (2020), 142606– 142621. [8] Shengjian Chen, Carsten Ellwein, Lars Klingel, Rebekka Neumann, Jingxi Zhang, Oliver Riedel, Alexander Verl, and Andreas Wortmann. 2025. Digital twins for machine tools: a systematic mapping study. Digital Twin 0, 0 (2025), 2538727. [9] Manuela Dalibor, Nico Jansen, Bernhard Rumpe, David Schmalzing, Louis Wachtmeister, Manuel Wimmer, and Andreas Wortmann. 2022. A cross-domain systematic mapping study on software engineering for Digital Twins. Journal of Systems and Software (2022), 111361. doi:10.1016/j.jss.2022.111361 [10] David Dietrich, Michael Neubauer, Armin Lechler, and Alexander Verl. 2024. Automated Manufacturing Toolchain using Skill-based Digital Twins. Procedia CIRP 128 (2024), 923–928. doi:10.1016/j.procir.2024.06.045 [11] Digital Twin Consortium. 2023. Platform Stack Architectural Framework: An Introductory Guide. Last accessed: 2024-03-01. [12] Carsten Ellwein, David Dietrich, Nicolai Maisch, Rebekka Neumann, Samed Ajdinović, Armin Lechler, and Andreas Wortmann. 2026. Rethinking Asset Administration Shell Communication Types: A Systematic Mapping Study and Portfolio-Based Classification. Production Engineering 20, 1 (2026), 23. [13] Romina Eramo, Francis Bordeleau, Benoit Combemale, Mark van Den Brand, Manuel Wimmer, and Andreas Wortmann. 2021. Conceptualizing digital twins. IEEE Software (2021). [14] Enxhi Ferko, Luca Berardinelli, Alessio Bucaioni, Moris Behnam, and Manuel Wimmer. 2024. Towards interoperable digital twins: Integrating sysml into aas with higher-order transformations. In 2024 IEEE 21st International Conference on Software Architecture Companion (ICSA-C). IEEE, 342–349. [15] Rony G. Flatscher. 2002. Metamodeling in EIA/CDIF—meta-metamodel and metamodels. ACM Trans. Model. Comput. Simul. 12, 4 (Oct. 2002), 322–342. [16] Florian Frick, Carsten Ellwein, Armin Lechler, Michael Neubauer, and Alexander Verl. 2024. Software-defined manufacturing: Reference architecture. In 2024 International Symposium on Power Electronics, Electrical Drives, Automation and Motion (SPEEDAM). IEEE, 1289–1295. [17] J. Frysak, C. Kaar, and C. Stary. 2018. Benefits and pitfalls applying RAMI4.0. In 2018 IEEE Industrial Cyber-Physical Systems (ICPS). 32–37. [18] Gustavo P. Cainelli, Lisa Underberg, Lutz Rauchhaupt, and Carlos E. Pereira. 2022. Asset administration shell submodel for wireless communication system. IFAC-PapersOnLine (2022), 120–125. doi:10.1016/j.ifacol.2022.04.180 [19] Mihály Héder. 2017. From NASA to EU: the evolution of the TRL scale in Public Sector Innovation. The Innovation Journal 22, 2 (2017), 1–23. [20] Weifei Hu, Jianhao Fang, Tongzhou Zhang, Zhenyu Liu, and Jianrong Tan. 2023. A new quantitative digital twin maturity model for high-end equipment. Journal of Manufacturing Systems 66 (2023), 248–259. doi:10.1016/j.jmsy.2022.12.012 [21] Hsuan-Chao Huang, Chun-Hsien Tsai, and Hsiung-Cheng Lin. 2023. Development of 5G Cyber-Physical Production System. International Journal of Networked and Distributed Computing 11, 1 (2023), 9–19. doi:10.1007/s44227-022-00003-4 [22] Industrial Digital Twin Association (IDTA). 2026. IDTA 02027: Asset Interfaces Mapping Configuration (AIMC) – Submodel Template. [23] Yong-Woon Kim. 2020. Digital Twin maturity model. Proceedings of the WEB D 3 (2020), 2020. [24] Werner Kritzinger, Matthias Karner, Georg Traar, Jan Henjes, and Wilfried Sihn. 2018. Digital Twin in manufacturing: A categorical literature review and classification. IFAC-PapersOnLine 51, 11 (2018), 1016–1022. [25] Daniel Lehner, Sabine Sint, Michael Vierhauser, Wolfgang Narzt, and Manuel Wimmer. 2021. AML4DT: A model-driven framework for developing and maintaining digital twins with automationml. In 2021 26th IEEE international conference on emerging technologies and factory automation (ETFA). IEEE, 1–8. [26] Daniel Lehner, Jingxi Zhang, Jérôme Pfeiffer, Sabine Sint, Ann-Kathrin Splettstößer, Manuel Wimmer, and Andreas Wortmann. 2025. Model-driven engineering for digital twins: a systematic mapping study: D. Lehner et al. Software and Systems Modeling 24, 5 (2025), 1339–1377. [27] Yang Liu, Jun Feng, Jiamin Lu, and Siyuan Zhou. 2024. A review of digital twin capabilities, technologies, and applications based on the maturity model. Advanced Engineering Informatics 62 (2024), 102592. doi:10.1016/j.aei.2024.102592 [28] Azad M. Madni, Carla C. Madni, and Scott D. Lucero. 2019. Leveraging Digital Twin Technology in Model-Based Systems Engineering. Systems 7, 1 (2019). [29] Homa Masoumi, Sara Shirowzhan, Paria Eskandarpour, and Christopher James Pettit. 2023. City Digital Twins: their maturity level and differentiation from 3D city models. Big Earth Data 7, 1 (2023), 1–36. doi:10.1080/20964471.2022.2160156 [30] Measurement and Automation Technology Society (GMA). 2020. VDI/VDE 2193: Language for I4.0 components: Part 1: Structure of messages. Standard VDI/VDE
MODELS 2026, October 04–09, 2026, Málaga, Spain
2193-1. Association of German Engineers (VDI) / Association of German Electrical Engineering, Electronics and Information Technology(VDE), Düsseldorf, DE. [31] Judith Michael, Loek Cleophas, Steffen Zschaler, Tony Clark, Benoit Combemale, Thomas Godfrey, Djamel Eddine Khelladi, Vinay Kulkarni, Daniel Lehner, Bernhard Rumpe, et al. 2025. Model-driven engineering for digital twins: opportunities and challenges. Systems Engineering 28, 5 (2025), 659–670. [32] Paula Muñoz, Javier Troya, and Antonio Vallecillo. 2021. Using UML and OCL models to realize high-level digital twins. In 2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C). IEEE, 212–220. [33] Paula Muñoz Ariza, Javier Troya-Castilla, Antonio Jesús Vallecillo-Moreno, et al. 2023. A Conceptual Architecture for Building Digital Twins. In STAF Workshops. [34] Michael Neubauer, Lukas Steinle, Colin Reiff, Samed Ajdinovic, Lars Klingel, Armin Lechler, and Alexander Verl. 2023. Architecture for Manufacturing-X: Bringing Asset Administration Shell, Eclipse Dataspace Connector and OPC UA together. Manufacturing Letters 37 (June 2023), 1–6. [35] Hergen Pargmann, Dörthe Euhausen, and Robin Faber. 2018. Intelligent big data processing for wind farm monitoring and analysis based on cloud-technologies and digital twins: A quantitative approach. In 2018 IEEE 3rd International Conference on Cloud Computing and Big Data Analysis (ICCCBDA). [36] Jérôme Pfeiffer, Daniel Lehner, Andreas Wortmann, and Manuel Wimmer. 2022. Modeling Capabilities of Digital Twin Platforms - Old Wine in New Bottles? Journal of Object Technology 21, 3 (July 2022), 3:1–14. doi:10.5381/jot.2022.21.3.a10 The 18th European Conference on Modelling Foundations and Applications (ECMFA 2022). [37] Jhonny Rodriguez Rahal, Alexander Schwarz, Benjamín Sahelices, Ronny Weis, and Simon Duque Antón. 2023. The asset administration shell as enabler for predictive maintenance: a review. Journal of Intelligent Manufacturing (2023), 1–15. [38] Lucas Sakurada, Fernando de La Prieta, and Paulo Leitao. 2023. A Methodology for Integrating Asset Administration Shells and Multi-agent Systems. In 2023 IEEE 32nd International Symposium on Industrial Electronics (ISIE). 1–6. doi:10. 1109/ISIE51358.2023.10227964 [39] Henrique Silva, Tomás Moreno, António Almeida, António Lucas Soares, and Américo Azevedo. 2023. A Digital Twin Platform-Based Approach to Product Lifecycle Management: Towards a Transformer 4.0. Innovations in Industrial Engineering II (2023), 14–25. doi:10.1007/978-3-031-09360-9_2 [40] Simon Kosse, Vincent Betker, Philipp Hagedorn, Markus König, and Thorsten Schmidt. 2024. A Semantic Digital Twin for the Dynamic Scheduling of Industry 4.0-based Production of Precast Concrete Elements. Advanced Engineering Informatics (2024). doi:10.1016/j.aei.2024.102677 [41] Ann-Kathrin Splettstößer, Carsten Ellwein, and Andreas Wortmann. 2023. Selfadaptive digital twin reference architecture to improve process quality. Procedia CIRP 119 (2023), 867–872. [42] Fei Tao, Weiran Liu, Meng Zhang, Tian-liang Hu, Qinglin Qi, He Zhang, Fangyuan Sui, Tian Wang, Hui Xu, Zuguang Huang, et al. 2019. Five-dimension digital twin model and its ten applications. Computer integrated manufacturing systems 25, 1 (2019), 1–18. [43] Technical Committee ISO/TC 184, Automation systems and integration, Subcommittee SC 4, Industrial data. 2021. ISO 23247-1:2021 – Automation Systems and Integration – Digital Twin Framework for Manufacturing – Part 1: Overview and General Principles. Technical Report ISO 23247-1:2021. International Organization for Standardization, Geneva, Switzerland. International Standard. [44] Igor Verner, Dan Cuperman, Amy Fang, Michael Reitman, Tal Romm, and Gali Balikin. 2018. Robot Online Learning Through Digital Twin Experiments: A Weightlifting Project. In Online Engineering & Internet of Things: Proceedings of the 14th International Conference on Remote Engineering and Virtual Instrumentation REV 2017, held 15-17 March 2017, Columbia University, New York, USA. Springer, 307–314. [45] Constantin Wagner, Julian Grothoff, Ulrich Epple, Rainer Drath, Somayeh Malakuti, Sten Grüner, Michael Hoffmeister, and Patrick Zimermann. 2017. The role of the Industry 4.0 asset administration shell and the digital twin during the life cycle of a plant. In 2017 22nd IEEE international conference on emerging technologies and factory automation (ETFA). IEEE, 1–8. [46] Kang Wei, JZ Sun, and RJ Liu. 2019. A review of asset administration shell. In 2019 IEEE International Conference on Industrial Engineering and Engineering Management (IEEM). IEEE, 1460–1465. [47] Roy Wendler. 2012. The maturity of maturity model research: A systematic mapping study. Information and software technology 54, 12 (2012), 1317–1339. [48] William Motsch, Aleksandr Sidorenko, Alexander David, Pascal Rübel, Achim Wagner, and Martin Ruskowski. 2021. Electrical Energy Consumption Interface in Modular Skill-Based Production Systems with the Asset Administration Shell. Procedia Manufacturing 55 (2021), 535–542. doi:10.1016/j.promfg.2021.10.073 [49] Jingxi Zhang, Carsten Ellwein, Malte Heithoff, Judith Michael, and Andreas Wortmann. 2025. Digital twin and the asset administration shell. Software and Systems Modeling (2025). doi:10.1007/s10270-024-01255-0