Available online at www.sciencedirect.com
Procedia CIRP 00 (2026) 000–000
www.elsevier.com/locate/procedia
CIRP Global Web Conference 2026 (CIRPe 2026)
A Set-Theoretic Evaluation Framework for Assessing Asset Administration Shell Instances: Towards Comparability and Suitability Carsten Ellweina,∗, David Dietricha , Rozana Cvitkovicb , Bastian Langb , Hansjoerg Tutschb , Andreas Wortmanna
arXiv:2609.17062v1 [cs.SE] 15 Sep 2026
a Institute for Control Engineering of Machine Tools and Manufacturing Units (ISW), University of Stuttgart, Seidenstraße 36, 70174 Stuttgart, Germany b Blue Yonder GmbH,Industriestraße 6, 70565 Stuttgart, Germany
* Corresponding author. Tel.: +49 711 685-82424 E-mail address: [email protected]
Abstract Asset Administration Shells (AAS) provide a standardized means of representing assets and their information in manufacturing and increasingly serve as a basis for software services. However, different AAS instances vary in structure, content, and degree of completion, making it difficult to determine whether a given AAS is suitable for a specific application. This paper presents two complementary methods to support the comparison and application-oriented assessment of AAS. First, set-theoretic operations are employed to compare AAS models, enabling the identification of common, missing, and differing submodels and parameters. Second, an AAS suitability model assesses the conformity of an AAS to the requirements of a specific use case. The assessment considers structural conformity, semantic consistency, cardinality, and specification conformity and can be performed either against a reference AAS or a set of required SemanticIDs. A suitability value is derived from the identified deviations and is complemented by a detailed report of missing or non-conforming information. The proposed approach support practitioners and researchers in the comparison of evolving AAS and provide application-specific information on their suitability for manufacturing software services. © 2026 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/) Peer-review under responsibility of the scientific committee of the CIRP Global Web Conference 2026 (CIRPe 2026). Keywords: AAS; Digital Twin; AAS Comparability; AAS Suitability; Set Theory
1. Introduction Digital twins are increasingly becoming the technological backbone to improve the understanding, design, operation, and management of cyber-physical systems (CPS) [1]. Although the software engineering community is primarily responsible for developing the key technologies that underpin DTs [2], manufacturing continues to be one of the primary application areas in which their capabilities are explored [3]. Within manufacturing, a digital twin is typically defined as a virtual representation of a cyber-physical production system (CPPS) [4], instantiated and executed within a software environment [5]. Individual digital twins are tailored to specific objectives with respect to their corresponding physical systems [4], e.g., analysis [6], control [7], or behavior forecast [8]. The Asset Administration Shell (AAS) is becoming a central technology for representing and implementing digital twins [9] in manufacturing and has already been employed to describe
products [3], processes [10], and resources [11]. The AAS is designed to serve as the authoritative and instantiated digital representation of any asset throughout its life cycle [12]. Consequently, the AAS is therefore utilized and further continuously advanced by various stakeholders – partly simultaneously, partly in a collaborative manner. This, along with the use of multiple submodels, increases the risk of ambiguity within the AAS. Set theory has previously been used to formally compare data models, e.g. by defining relative information capacity between database schemata via set-based mappings between their instances [13], including more recent set-theoretic treatments of the AAS itself [14]. However, existing approaches to AAS comparability rely on informal or purely syntactic matching rather than a formal set-theoretic basis capable of guaranteeing precise notions such as equivalence and subsumption. The first part of the paper therefore establishes the methodological foundations necessary for a systematic and coherent analysis of AAS instances.
2212-8271 © 2026 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/) Peer-review under responsibility of the scientific committee of the CIRP Global Web Conference 2026 (CIRPe 2026).
C. Ellwein et al. / Procedia CIRP 00 (2026) 000–000
The AAS is increasingly employed not merely as a representational construct but as a foundational framework for the provision of software-based services [15, 16]. This raises the challenge of comparing different AAS to identify the appropriate data source for the software component to be implemented and to ensure that the required information is available in the expected format. An option is to develop and apply a dedicated maturity model [17]. However, maturity does not necessarily indicate suitability for a specific use case. The approach discussed in the second part of the paper therefore is a reference-based suitability assessment, in which the application developer provides a reference or template AAS that specifies the minimum requirement profile. In the following, section 2 presents the state of the art on AAS. Subsequently, section 3 introduces a concept of mutual comparability for AAS models grounded in set theory, before section 4 develops the AAS suitability model. Next, section 5 demonstrates how the proposed methods can be applied by means of an example. Building on these results, section 6 highlights limitations, before section 7 offers concluding remarks.
2. Background Within the framework of Industry 4.0, any entity owned by an organization that adds value to the execution of processes is termed an asset [18]. Assets can be physical, such as production machinery, workpieces, or even the entire manufacturing plant, but they can also be non-physical, including models used to represent machine behavior, software, or licenses [19]. The AAS [20] is increasingly being recognized as a potential standard for modeling and implementing digital twins [9], and has been proposed as the definition and representation layer in ISO 23247.Its evolution is being advanced by the International Digital Twin Association (IDTA) [14], an industry-focused organization affiliated with the Association of German Mechanical Engineering Companies (VDMA). Because the AAS holds relevant information covering the entire life cycle of an asset, it must be capable of depicting a wide range of content, including properties, modeled functions, parameters, summaries of integrated components, data generated during manufacturing or simulation, and descriptive details such as usage guidelines and technical specifications. Consequently, it needs the ability to store or reference heterogeneous data types [18]. The structure of the AAS is defined by a metamodel (cf. [12]). At the top level, the AssetAdministrationShell class represents the complete AAS of a given asset. It may contain multiple submodels, represented by the Submodel class, each capturing particular characteristics of the asset. The individual attributes that constitute a submodel — such as properties and files — are represented by the abstract class SubmodelElement. From this, the abstract class DataElement is derived and serves as a base class for further concrete specializations. The classes Property, Range, File, and ReferenceElement describe different categories of asset attributes. Property encapsulates a pair of information consisting of a single value and its data type, whereas
2
Model Layer M3: Metametamodel
Format of AAS (e.g., XML, JSON)
Model Layer M2: Metamodel
AAS-Metamodel
Model Layer M1: Model
AAS for Product Type
Model Layer M0: Reality
Instance, Physical Asset
Fig. 1. The four layers of an AAS, based on the hierarchical metamodel layout [21]
Range defines two values that share a common data type. File specifies the type and location of a file, while ReferenceElement establishes a logical reference either to another element within the same AAS or to an element in a different AAS. To ensure consistency and interoperability, the IDTA provides so-called submodel templates. These templates are standardized as well and are publicly available through the Content Hub1 . Each parameter in a submodel template is specified by an identifier, its semantic definition, and a representative example. The semantic definition is harmonized with established dictionaries, such as the ECLASS2 reference data standard for the unequivocal description of products and services, and the IEC Common Data Dictionary, and is referred to as SemanticID. 3. AAS Comparability This chapter describes the comparability of AAS instances. The focus of this analysis is the AAS model. Since AASs are complex constructs, it is necessary to define the level at which the comparison is to be made. The four-layer hierarchical metamodel layout [21], which is also used by the Object Management Group (OMG) and the Electronic Industries Alliance / Computer-Assisted software engineering (CASE) Data Interchange Format (EIA/CDIF), is applied to the AAS. In this hierarchical layout, the upper level specifies the lower level. This means that the lower level can be regarded as an instance of the upper level. The four levels are formally defined as M3 Metametamodel, M2 - Metamodel, M1 - User Model, and M0 - User Object [22]. Thus, M0 describes the current system and the objects that currently exist. M1 represents these objects as models or classes with defined attributes. M1 is the classification of M0 and, conversely, the objects are instances of M1. M2 describes the modeling language, i.e., the process used to create models. M2 thus categorizes the models from M1. M3, as a metametamodel, describes the concepts used to create modeling languages in M2 [23]. The layers applied to AAS can be seen in Figure 1. M3 describes the top level and thus the meta-metamodel of an AAS. This includes general visualization and representation, 1 IDTA Content Hub: https://industrialdigitaltwin.org/en/ content-hub/submodels 2 ECLASS: https://eclass.eu/en/eclass-standard
C. Ellwein et al. / Procedia CIRP 00 (2026) 000–000
as well as structuring languages such as JSON. M2 contains the metamodel of an AAS, which includes general specifications and minimum requirements for an AAS. M1 shows the AAS model for a product type, such as an AAS for a milling machine with the corresponding submodels. M0 describes a specific instance of a physical asset, that is, real values for the parameters within the AAS submodels. The question now arises as to which level AASs should be compared. M3 and M2 are standardized for AASs in order to precisely define which construct is already an AAS and which is not. This causes these levels to be identical when two AASs are compared to each other. Therefore, a comparison is only truly informative at the M1 and M0 levels. The purpose of comparing two AASs is to identify similarities and differences between two physical assets. To do this, individual values within models would have to be compared. The same model must be present in both AASs in order to be able to compare individual data points within the models in the subsequent step. As a result, the comparison of AASs must first be carried out at the M1 level in order to do a meaningful comparison at the M0 level. In order to compare AASs, the principles of set theory are used. The AAS constitutes a set, the submodels representing elements of this set. For demonstration purposes, three AASs containing several submodels are defined and compared in pairs. A = {1, 2}, B = {1, 2, 3}, C = {1, 3, 4}
(1)
These AASs consist of submodels that can be identical or different. For illustrative purposes, the submodels are represented numerically. The numbers thus represent an identification number for a submodel. The cardinality of an AAS is described by the number of its submodels. In the example used here, this corresponds to: ∥A∥ = 2, ∥B∥ = ∥C∥ = 3
(2)
An AAS without submodels can be noted by an empty set. D = {} = ∅
(3)
An AAS consists of submodels, which in turn consist of empty and filled parameters with real values. Submodels within an AAS are only valid if all mandatory parameters are filled in. The optional parameters may differ in terms of the percentage degree of fulfillment, that is, how many optional parameters are filled in within a submodel. Differences in the selection of the respective optional parameters are also possible. An AAS can be a subset of another AAS. This can occur, for example, when an AAS acquires additional submodels over time compared to its previous AAS version. Another use case would be the inheritance of models. If an AAS as the parent generation passes on some of its submodels to the child generation of AASs, or if the parent AAS transfers all of its submodels and the children also hold additional submodels, then this can be represented with subsets. In the example introduced, A would be a subset of B but not of C. A ⊆ B, A ⊈ C
(4)
3
Backward compatibility corresponds to A ⊆ B, and its absence to a non-trivial intersection with both difference sets non-empty. The intersection between two AASs describes the common submodels. This makes it easy to determine the similarities between the AASs at the M1 model level. If two AASs do not have any models in common, then they are disjunctive with respect to each other. The intersection is then described with an empty set. In the example described here, the intersections would look as follows. A ∩ B = {1, 2}, A ∩ C = {1}, C ∩ B = {1, 3}
(5)
The union set describes an OR relationship between two AASs. The model must appear in either A or B or in both to be part of the set. This construct can be useful for obtaining an overview of which models are in use system-wide. This set can be used, for example, during system setup to obtain an overview of which models need to be implemented. A∪B = {1, 2, 3}, A∪C = {1, 2, 3, 4}, C∪B = {1, 2, 3, 4}(6) Another way to compare AASs is using the difference set. For two AASs, A and B, the difference set describes all submodels that occur exclusively in A but not in B. This makes it possible, for example, to identify the differences of evolving AASs compared to the previous version. A typical use case would be the description of the version differences for the release documentation if submodels were added or removed. Applied to the example set, the difference sets are as follows. The comparison of AASs B and C is skipped here. A\B = ∅, B\A = {3}, A\C = {2}, C\A = {3, 4}
(7)
Once a syntactic identity has been determined, i.e., a submodel exists in both AASs, a semantic comparison can be performed at the M0 level. In principle, the same set theory methods used for M1 can be applied to M0 as well. To obtain a semantic statement, the real values assigned to the parameters of a submodel must be compared. With the help of the set theory, differences and similarities between the values can be determined and conclusions can be drawn about the two AASs being compared. The submodel represents a set, and the values of the parameters represent the elements. A submodel is termed empty if no parameters are filled with values. Set-theoretic relations provide a formal basis for structured comparison. A submodel can be characterized as a subset of another submodel when the latter introduces additional parameters, while modifications of parameter values lead to non-trivial intersections rather than strict subset relations. In the context of evolving metamodels, intersections may also arise when backward compatibility is not preserved. In this case, intersections represent the set of shared parameters for which the corresponding values are identical, whereas disjoint submodels have no parameters with matching values in common. The union operation aggregates all parameters and their associated values from both submodels, while the symmetric difference isolates those parameters that are either unique to one submodel or shared but assigned differing values, thus enabling explicit identification of discrepancies. Difference sets emphasize the features that are unique to a given submodel when compared to one or more reference submodels.
C. Ellwein et al. / Procedia CIRP 00 (2026) 000–000
Complement operations support two distinct modes of comparative analysis. Structurally, they expose uninstantiated or missing parameters by referencing a designated complete parameter set. Semantically, they identify parameter values that are absent from, or deviate from, those in a broader contextual reference (e.g., a system-wide or fleet-wide baseline). In summary, set theory can simplify the comparison of AASs by identifying both the differences and similarities between them using the various sets. Comparisons are carried out within levels M1 and M0 to examine syntactic and semantic identity.
4. AAS Suitability Model In addition to structural and organizational maturity aspects, the concrete applicability of an AAS is evaluated in specific application scenarios. Although conformity checks against specifications ensure syntactic and semantic correctness, they do not answer the central question from an application perspective: Is a specific AAS immediately suitable for use in a particular application? This chapter describes a methodical approach to testing the suitability of AAS. The aim is to produce a formalized assessment that provides immediate information on whether an AAS: (i) is fully usable, (ii) is usable with restrictions, or (iii) is not suitable due to missing information. The suitability of an AAS for use is defined as: The degree of structural, semantic, and specification-compliant conformity between a given AAS and the requirements of a specific application. Formally, the test can be described as a comparison between two models: The AAS and a requirement model, given as list of defined semantic content or reference AAS – the copy of a submodel template in which no values are specified, but entries are marked as required. The suitability check is carried out along four central dimensions that address different aspects of the conformity between a given AAS and the requirements of a specific application. The first dimension concerns structural conformity. If a reference administration shell is available, a structural model matching between the administration shell to be tested and this reference is performed. The comparison is performed at both the submodel level and the submodel elements contained therein. Methodologically, the comparison is similar to a structural diff of two JSON documents: It is analyzed whether all required submodels are present, whether the required elements exist, whether they are correctly embedded in the intended hierarchical structure, and whether the defined cardinality is adhered to. Missing mandatory submodels are considered critical deviations, as they usually prevent immediate usability of the administration shell for a specific use case. In contrast, missing optional elements are given less weight, as they restrict the application but do not necessarily exclude it. The second dimension is semantic consistency. As an alternative or supplement to structural comparison, suitability testing can be performed using SemanticIDs. In this case, the system checks whether there is a corresponding element in the AAS for each required SemanticID, whether the assignment is unique, and whether the associated data structure is consistent.
4
The identity of SemanticID is considered a sufficient criterion for content consistency. There is no further examination of semantic hierarchies or ontological relationships, as the focus is on the availability of the specifically required information. In addition to structural and semantic analysis, cardinality and specification conformity are also checked as third and fourth dimensions. For each relevant submodel and the elements it contains, the declared cardinality – for example, in the sense of 1..1 or 0..n – is compared with the actual number of instances and checked for conformity with the normative specifications of the IDTA. This involves checking whether mandatory elements are present, data types are used correctly, and — especially in the case of physical quantities — the specified units are in accordance with the specifications. This validation is implemented by a project-specific validator that converts the IDTA specifications into formalized test rules, enabling automated evaluation. In the following, two comparison strategies are introduced. The reference-based suitability assessment quantifies the conformance of an AAS to a requirement profile derived from the specific needs of the target use case. This requirement profile is defined by the application developer in the form of a reference AAS, which specifies the minimum set of submodels and submodelelements required for the intended application. Formally, we express this conformance using set difference operations. Let Mreq denote the set of required elements specified by the reference AAS (e.g., required submodels, submodel elements, and their expected cardinality, type, and unit), with ∥Mreq ∥ its cardinality. Suitability is then determined by: S =1−
∥Dcrit ∥ + w∥Dncrit ∥ ∥Mreq ∥
(8)
where Dcrit ⊆ Mreq denotes the subset of critical deviations, i.e., required elements entirely missing from the evaluated AAS (e.g., a missing required submodel or mandatory element), and Dncrit ⊆ Mreq denotes the subset of non-critical deviations, i.e., required elements that are present but do not fully conform to the reference (e.g., cardinality or unit discrepancies), with Dcrit ∩ Dncrit = ∅. The weighting factor w ∈ [0, 1] scales the non-critical deviations relative to critical ones. Critical and noncritical deviations are specified in the reference AAS, whilst the weighting factor is defined by the user. This method is particularly suitable for applications that are highly dependent on structure, such as production schedulers. In the requirement-based suitability assessment, a list of required elements is defined using SemanticIDs. This strategy is more robust against structural variations. The suitability S =
∥E f ound ∥ ∥Ereq ∥
(9)
is thus calculated using found elements E f ound and required elements Ereq . The result of the check provides various information, such as: (i) List of missing submodels, (ii) list of missing or incorrect elements, (iii) cardinality violations, (iv) type and unit discrepancies, and (v) general suitability value. This provides concrete transformation instructions to achieve the target suitability. The
C. Ellwein et al. / Procedia CIRP 00 (2026) 000–000
Fig. 2. Five-axis milling machine (left) and its simulation model (right)
suitability value S is to be interpreted by the user in the context of their specific use case, as requirements on completeness and correctness vary depending on the intended application of the AAS. Depending on the application of the AAS, requirements on completeness and correctness can vary, so the same suitability value may be regarded as sufficient in one scenario and insufficient in another. The detailed breakdown of missing submodels, elements, cardinality violations, and discrepancies allows users to assess which deviations underlie the reported value and prioritize the transformation steps for their use case. Critical deviations, such as missing required submodels, are additionally reported explicitly in the detailed breakdown, ensuring they remain visible to the user even when the aggregated suitability value alone might suggest high usability. 5. Exemplification To exemplify the proposed Suitability Model, we consider the engineering life cycle of a five-axis milling machine controlled by Beckhoff TwinCAT (cf. Figure 2). The scenario illustrates how suitability evolve across development phases and stakeholder perspectives and how temporarily divergent digital representations can be reconciled prior to investment and operational deployment. During the early engineering phase, the manufacturer creates a standalone AAS containing the standardized submodels “Digital Nameplate” and “Technical Data”. The technical data 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. An early customer requested the AAS machine for the planning of a future production line. The customer assesses its suitability for capacity alignment and layout planning based on its reference AAS. Further properties in the reference AAS are the simulation model, axes limits, and dynamics, which would enable tool path planning and validation using a material removal simulation, likewise qualified as optional. In contrast values of the feed rates, spindle speed, and dimensions are required in the reference. In total, this yields twenty parameters that are specified as mandatory by the submodel, nine of which are critical for capacity alignment and layout planning. Based on Equation 8, with nine critical values and deviations in all eleven noncritical values weighted at w = 0.2 due to the early stage, suit-
5
ability results in S = 1 − (0 + 0.2 ∗ 11)/20 = 0, 89. Based on the results, the customer expects a limited suitability, as required values are present but optional ones are not. The available parameters allow approximate cycle time calculations, yet the absence of finalized dynamic properties and simulation models restricts advanced planning tasks such as tool path validation or material removal simulation. During planning, the customer extends the AAS with derived production metrics, enriches the technical data, and extends its “Process Parameters Type”. In parallel, the manufacturer completes the detailed design of the drives, leading to slightly modified parameters in the Technical Data submodel. Furthermore, validated engineering artifacts are integrated in “Handover Documentation”, “Provision of Simulation Models”, the “Provision of 3D Models”, the “Capability Description” and the “Control Component Instance”, resulting in an AAS ready to deliver with the resource. At this point, two partially divergent representations exist: a customer-enhanced version and a manufacturer updated engineering version. Before making an investment decision, the customer compares both variants. The difference at the level of the submodels visualizing the equations defined in section 3 is shown in Figure 3. The customer decides that minor deviations in the overlapping parameters remain within acceptable tolerances. As no reevaluation of his first assessment is needed, he merges his calculations from the early development stage in the updated AAS of the manufacturer. However, the inclusion of validated simulation models substantially increases suitability for detailed path planning, collision checks, and material removal simulation, as all deviations of non-critical parameters from the first stage are solved, the AAS is directly usable with the full suitability S = 1. With this exemplification, the methodologies introduced are demonstrated. In addition to being used as a basis for suitability assessments, the comparison helps to merge divergent developments. Based on the model, the use of the AAS in software applications is evaluated at different development stages. 6. Limitations The basis for compatibility in section 3 is the simplification of the AAS structure. Dependencies between submodels and cross-references are not taken into account here, nor are duplicates or the order of submodels. In particular, with regard to the
Fig. 3. Comparison of the two AAS for the milling machine using set theory.
C. Ellwein et al. / Procedia CIRP 00 (2026) 000–000
order, the applicability of set theory in large AAS containing nested elements must be verified. The semantic meaning of the values is ignored for the comparison based on set theory. For parameters with the same values but different units this could lead to misinterpretation (e.g., temperature °C or K). The suitability in section 4 closes the gap between the pure conformity of the specification and practical usability. While classic validation tools check syntactic correctness, the suitability test described here addresses the application-oriented perspective. This results in the absence of systematic data quality assessment—limited exclusively to structural aspects—and the omission of any analysis or resolution of semantic ambiguities. 7. Conclusion This paper presents methods for (i) comparing AAS models, and (ii) evaluating its suitability for a specific use case. Their applicability is substantiated through illustrative examples. The proposed suitability model determines the optimum for a respective use case, is thus less theoretical and more practical, and supports, in particular, the ongoing development of an AAS over time. If the methodology is further refined by means of the following steps and its limitations are systematically mitigated, it may provide an additional basis for the comparative analysis of AAS and thereby augment the set-theoretic comparison methodology previously presented. Such an extension would enable the parallelized and collaborative development of assets within the context of AAS. In particular, it would support the realization of a Git-like branching and merging mechanism, which would constitute a highly valuable instrument for engineering activities as well as for life cycle management. Acknowledgments Partly funded by the German Federal Ministry of Research, Technology and Space (BMFTR) within the “Research Campus – Public-Private Partnership for Innovation” funding initiative (grant no. 02P23Q820) and managed by the Project Management Agency Karlsruhe (PTKA). Partly funded by the Federal Ministry for Economic Affairs and Energy (BMWE) through the projects growING (grant no. 13IPC036G). References [1] M. Dalibor, N. Jansen, B. Rumpe, D. Schmalzing, L. Wachtmeister, M. Wimmer, A. Wortmann, A cross-domain systematic mapping study on software engineering for Digital Twins, Journal of Systems and Software (2022) 111361doi:https://doi.org/10.1016/j.jss. 2022.111361. [2] S. Fur, M. Heithoff, J. Michael, L. Netz, J. Pfeiffer, B. Rumpe, A. Wortmann, Sustainable digital twin engineering for the internet of production, in: Digital Twin Driven Intelligent Systems and Emerging Metaverse, Springer, 2023, pp. 101–121. [3] S. Chen, C. Ellwein, L. Klingel, R. Neumann, J. Zhang, O. Riedel, A. Verl, A. Wortmann, Digital twins for machine tools: a systematic mapping study, Digital Twin 0 (0) (2025) 2538727. doi:10.1080/27525783.2025. 2538727.
6
[4] R. Eramo, F. Bordeleau, B. Combemale, M. van Den Brand, M. Wimmer, A. Wortmann, Conceptualizing digital twins, IEEE Software (2021). [5] P. Muñoz Ariza, J. Troya-Castilla, A. J. Vallecillo-Moreno, et al., A conceptual architecture for building digital twins, in: STAF Workshops, 2023. [6] H. Pargmann, D. Euhausen, R. Faber, 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), IEEE, 2018, pp. 233–237. [7] I. Verner, D. Cuperman, A. Fang, M. Reitman, T. Romm, G. Balikin, 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, 2018, pp. 307–314. [8] A.-K. Splettstößer, C. Ellwein, A. Wortmann, Self-adaptive digital twin reference architecture to improve process quality, Procedia CIRP 119 (2023) 867–872. [9] M. Neubauer, L. Steinle, C. Reiff, S. Ajdinovic, L. Klingel, A. Lechler, A. Verl, Architecture for manufacturing-x: Bringing asset administration shell, eclipse dataspace connector and opc ua together, Manufacturing Letters 37 (2023) 1–6. doi:10.1016/j.mfglet.2023.05.002. [10] D. Dietrich, M. Neubauer, A. Lechler, A. Verl, Automated manufacturing toolchain using skill-based digital twins, Procedia CIRP 128 (2024) 923– 928. doi:10.1016/j.procir.2024.06.045. [11] F. Frick, C. Ellwein, A. Lechler, M. Neubauer, A. Verl, Software-defined manufacturing: Reference architecture, in: 2024 International Symposium on Power Electronics, Electrical Drives, Automation and Motion (SPEEDAM), IEEE, 2024, pp. 1289–1295. [12] S. Bader, E. Barnstedt, H. Bedenbender, B. Berres, M. Billmann, M. Ristin, 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), Tech. rep., Federal Ministry for Economic Affairs and Climate Action (BMWK) (2022). [13] R. Hull, Relative information capacity of simple relational database schemata, SIAM Journal on Computing 15 (3) (1986) 856–886. doi: 10.1137/0215061. [14] S. R. Bader, M. Maleshkova, The semantic asset administration shell, in: Semantic Systems. The Power of AI and Knowledge Graphs: 15th International Conference, SEMANTiCS 2019, Springer, 2019, pp. 159–174. [15] C. Ellwein, J. Zhang, A. Wortmann, A. A. A. Meckhael, A containerbased approach for proactive asset administration shell digital twins, in: 2025 ACM/IEEE 28th International Conference on Model Driven Engineering Languages and Systems (MODELS), IEEE, 2025, pp. 232–238. [16] C. Ellwein, D. Dietrich, J. Roth, R. Cvitkovic, A. Wortmann, Softwareheavy asset administration shells: Classification and use cases, arXiv preprint arXiv:2602.16499 (2026). [17] C. Ellwein, D. Dietrich, R. Cvitkovic, A. Wortmann, Towards an asset administration shell maturity model, in: 2026 ACM/IEEE 29th International Conference on Model Driven Engineering Languages and Systems (MODELS), ACM, 2026. doi:10.1145/3822455.38387652. [18] S. Cavalieri, M. G. Salafia, Asset administration shell for plc representation based on iec 61131–3, IEEE Access 8 (2020) 142606–142621. [19] J. Frysak, C. Kaar, C. Stary, Benefits and pitfalls applying RAMI4.0, in: 2018 IEEE Industrial Cyber-Physical Systems (ICPS), 2018, pp. 32–37. doi:https://doi.org/10.1109/ICPHYS.2018.8387633. [20] K. Wei, J. Sun, R. Liu, A review of asset administration shell, in: 2019 IEEE International Conference on Industrial Engineering and Engineering Management (IEEM), IEEE, 2019, pp. 1460–1465. [21] R. G. Flatscher, Metamodeling in eia/cdif—meta-metamodel and metamodels, ACM Trans. Model. Comput. Simul. 12 (4) (2002) 322–342. doi:10.1145/643120.643124. [22] J. Álvarez, A. Evans, P. Sammut, Mapping between levels in the metamodel architecture, UML 2001 2185 (2001) 34–46. doi:10.1007/ 3-540-45441-1_4. [23] L. Fuentes-Fernández, A. Vallecillo-Moreno, An introduction to uml profiles, UML and Model Engineering 5 (2) (2004) 6–13.