Digital twin and the asset administration shell

The understanding of digital twins differs widely in literature (cf. 112 definitions of digital twins²). As of the main purposes of a definition is to decide whether something is in the set of defined things or outside of it, most of these definitions fail at supporting to make this decision precisely. Instead, the lowest common denominator seems to be that a digital twin represents something (e.g., a system, a process, or a workpiece), which is of little use for detailed discussions about their functions, engineering, and operations. Moreover, often these definitions areAmbiguous definitions would require a definition of their fuzzy base terms (e.g., "virtual representation") to enable deciding whether something is a digital twin or not, while very narrow definitions (e.g., requiring the use of AR technology) prevent understanding digital twins more generally, and utopian definitions would either logically or economically prevent building such digital twin (e.g., modeling the behavior of the atoms of the windshield wiper fluid of a car usually is not considered required for a vehicle digital twin, yet that would be necessary for the digital twin to contain all physical information of the car).

Among the plethora of definitions, characterizations, and reference models [38] of digital twins, few have been widely accepted to be useful: either by being cited by vast numbers of researchers in the field of digital twins [53, 88], by being formalized into ISO standards [47], or by being accepted as common ground by large industrial associations about digital twins [31, 32]. Section 4 discusses these in detail.

In the context of Industry 4.0 (I4.0) every element owned by an organization having a value for the execution of the process is defined as an asset [22]. Assets can be physical, such as production resources, workpieces, and even the factory itself, but also non-physical, such as models used for describing machine behavior, software, or licenses [40].

The IDTA is developing the AAS [10, 96] to provide a technology for realizing digital twins [71]. This initiative started within Platform Industry 4.0, an initiative of the German Federal Ministry for Economic Affairs and Climate Protection and the Federal Ministry of Education and Research together with German industry, academia, associations, and unions. This technology is now also being taken up in Europe, as calls for EU Horizon start mentioning that proposals should take any relevant international standards (such as the AAS) into account.³ Alongside its political relevance, the AAS has also achieved industrial relevance. There are currently 118 partners⁴ organized in the IDTA (as of July 2024), including German (e.g., SAP, Siemens, and Volkswagen), as well as international enterprises (e.g., HUAWEI, Phoenix Contact, and Mitsubishi Electric).

The AAS is defined as the digital representation of the asset containing all its relevant information throughout its entire lifecycle [72] and is presented as the basis of interoperability: on the one hand, it holds information of various types and on the other hand, it functions as the interface for communication within the I4.0 network through which information can be exchanged between assets [79]. Since the AAS holds relevant information throughout the lifecycle of the asset, it must be capable of representing different sorts of information, such as properties, modeled functionalities, parameters, a summary of included components, as well as data that accrues during manufacturing or simulation and also descriptions, such as their usage instructions and technical specifications. This presupposes the ability to store or refer to heterogeneous data and models [22].

The structure of an AAS is specified in the form of a conceptual metamodel using UML class diagram syntax [79]. Figure 1 shows an excerpt of this metamodel focusing on the AAS submodels and their relations. Essentially, the AAS is organizing submodels hierarchically and is working on standardizing submodels and their templates. Each individual submodel of an AAS is intended to represent one content-related or functional aspect of the represented asset. Submodels can be created individually applying the previously introduced metamodel. To ensure consistency and interoperability, the IDTA provides so-called submodel templates. Submodel templates are also standardized and publicly available in their content-hub,⁵ which currently features 89 submodel templates. Each parameter in a submodel template is specified with an identifier, its semantic meaning as well as a given example. The semantic meaning is indicated in line with established dictionaries, such as the ECLASS reference data standard for the unambiguous description of products and services.⁶ and the IEC Common Data Dictionary [45]. The scope of the perhaps best-known IDTA submodel, "Digital Nameplate", for example, is to provide information about the manufacturer and serial number of an asset. The other submodel templates cover use cases at a similar level of abstraction.

Bild vergrößern

The main concept is the Asset Administration Shell, which represents the entire AAS of the asset. It can consist of several submodels represented by the class Submodel, which consists of abstract Submodel Elements that either are of a specified subtype, such as File or Property, or a composite of SubmodelElements themselves.

The abstract class DataElement inherits from the class SubModelElement from which further classes inherit. The classes Property, Range, File, and ReferenceElement represent attributes of the asset. In the class Property an information pair consisting of one value and the value data type are defined. A Range consists of two values and the data type of the values. A File represents the type and location of a file, whereas ReferenceElement defines a logical reference either to another element of the AAS it is included in, or to an element of another AAS.

The communication capability of AASs is differentiated into passive, active, and I4.0-compliant communication capability–a distinction originally started by the Association of German Engineers (VDI) [91]. Passive AASs are also referred to as Type 1 AAS. Exchanged on a file basis, these Type 1 AAS contain static master data for an asset. Master data could for example be a serial number, as in the "Digital Nameplate" introduced previously, but also physical dimensions, material properties, or electrical power consumption. The Type 1 AAS, hence, consists of serialized files representing the asset and can be exchanged manually among engineers. Its data model is defined by the AAS metamodels. Those metamodels are specified in different templates which the IDTA provides to construct the AAS for different purposes.⁷ These templates describe the structural composition of the submodels and the relationships between AASs. This enables domain experts to provide their knowledge in an ordered manner enabling expandability and modularization. As a passive entity, the Type 1 AAS does not have any automated data flow from or to its asset. Thus, the information in the Type 1 AAS describes asset types and instances as-designed without any real-time updates.

In addition to the serialized files of the Type 1 AAS, for Type 2 AASs an API is provided for the interaction with other components. Through this API, the Type 2 AAS can become service-oriented and reactive, i.e., it may consider any information provided by the asset or any third-party software, e.g., runtime information such as containing static and dynamic information about the asset. This establishes a mainly unidirectional data flow, in which live data is added to the models of the Type 1 AAS and where external methods, services, or tools can represent and relate this data.

Bild vergrößern

Mutual understanding seems to be that the Type 3 AAS is an extension of Type 2 AAS that enables the AASs to perform I4.0-compliant communication according to the “Industrie 4.0 Language” [92] and therefore allows vertical integration into other AAS instances, this is referred to as Type 3 AAS. Moreover, the Type 3 AASs can feature algorithms to control the represented asset (to some extent), as well as to analyze the data and manipulate its models. Type 3 AASs thus extend across all RAMI4.0 [44] layers (i.e., from the asset over communication to the business layer and, therefore, are able to implement business processes on their own. Unlike Type 1 AASs and Type 2 AASs, the Type 3 AAS has not yet been fully specified but is subject to ongoing research [48, 84].

The admin-shell-io package⁸ by the IDTA can be considered as a reference implementation for managing administration shells. The package consists of the AASX⁹ package explorer, with which administration shells can be created, edited, and visualized, but also includes the AASX server as infrastructure for deployment. If the AAS is to be integrated into a software project, the Eclipse BaSyx¹⁰ project provides an open-source I4.0 middleware. BaSyx is available under the MIT license and offers an SDK for implementing AASs in Java, Python, and RUST.

Bild vergrößern

The most prominent qualitative definition of digital twins distinguishes these from digital models and digital shadows [19] based on the automated data flows between the (cyber-)physical and digital object (cf. Fig. 5) [53]. Here, a digital object is considered to be:Also, the authors hide much of the complexity of digital twins in the data flows: for instance, this definition already demands that the digital object can receive data from its actual (cyber-physical) system and send data back to it, i.e., it needs to be a sufficiently complex software system that takes care of communication, synchronization, and digital representation. This also demands an interface to the actual system (e.g., through OPC UA [34] or MQTT [56]), means to analyze the data, and user interfaces to control the behavior of the digital twin. Moreover, the model does not make explicit how frequently the data between the actual system and its digital twin must be exchanged (which means the digital twin might be asynchronous with the actual system for a long time). Also, how human decision-making can be incorporated, which often is necessary in manufacturing and other domains operating complex systems in reality, such as automotive or avionics, is not explained.

The 5D digital twin model extends the model of based on data flows [53] with the additional dimensions data, models, and services [88]. Here, a digital twin is a system that comprises elements of 5 dimensions: (1) Tthe AS itself, (2) Data from and about the AS, (3) Models of the AS as well as models of the digital twin, (4) Services about the AS (e.g., predictive maintenance, reporting), and (5) Connections between the elements of these dimensions (cf. Figure 6).

Bild vergrößern

This model assumes that all connections between all constituents are bidirectional, i.e., services can directly read data from the actual system and send commands to it as well. This allows making changes to the actual system without informing the digital twin. Moreover, both the services and the actual system can interact with data and models of the digital twin independently, which allows for introducing inconsistencies between the real-world system and its representation. Moreover, this model does not prescribe any minimally required models, data, or services.

The Digital Twin Consortium (DTC) devised a list of potential capabilities of digital twins ¹¹ according to six different categories (cf. Fig. 7). According to this digital twin periodic table, digital twins can provide (1) Data services, (2) Integration, (3) Intelligence, (4) User interaction, (5) Management functions, and (6) Trustworthiness capabilities. Data services (1) Contain data management processes, such as acquisition and ingestion, data interpretation with ontologies, data management with a model repository, data management methods such as pub/sub, batch processing, and data aggregation. Integration (2) Contains integration methodologies, such as platforms, APIs, and enterprise systems for both directions of abstraction more coarse, as well as more detailed systems. Intelligence (3) Describes components and services that encompass reasoning, planning, machine learning, simulation, recommendation systems, and any other capabilities being considered intelligent. User interaction (4) Contains all features the system provides for the monitoring, consisting of visualization of data, models, relationships and interaction, consisting of gamification, BPM, workflow and business intelligence methods without influencing the machine. Management functions (5) Are mostly directed to the manipulation of the system. Here for the device, the logging of the system and the data methods are advised to be used for interpretation and configuration of machines. Trustworthiness capabilities (6) Contain all features important for the trustworthiness of the system.

Bild vergrößern

Based on these observations, the DTC proposes an architectural framework of building blocks for creating digital twins for different applications as depicted in Fig. 8  [32]. Its main components are a virtual representation on top of an IT/OT platform and the service interfaces of this representation. The virtual representation consists of data (“stored representations”), models, and functions for their integration. Taken this to the illustrative example from Sect. 3: the models of the milling machine can consist of multiple different models. These models could be designed by providing SysML in addition to 3D models in a 3D environment for simulation purposes. It provides interfaces (1) To synchronize with the real world, (2) With external data sources, and (3) To deploy services leveraging the virtual representation. The IT/OT platform includes orchestration middleware, networking infrastructure, APIs that provide access to services, and integration representation/functions for data storage and data transformation. This middleware could be manufacturing-specific management systems or even systems composed of data management services such as a database, a network interface such as OPCUA, or local platform-specific APIs from cloud platforms such as Azure.

Another main part of the architectural framework are services for privacy, physical and cyber-security, safety, resilience, and reliability. For example, the milling machine could provide safety measurements for its condition. In milling processes, it is often not safe for a worker to open the cabin in which a mill is located. Other metrics such as resilience and reliability can be measured based on KPIs. Finally, security and privacy are often addressed at a higher level of abstraction. The network within a factory must be secure from outside attacks to prevent malicious use of machines within the factory.

The Digital Twin Framework for Manufacturing as depicted in Fig. 9 (ISO 23247) [47] defines a conceptual digital twin framework for manufacturing. The framework consists of three layers of components that provide functionality on top of observable manufacturing elements (OMEs), which are items providing observable properties (e.g., staff, a manufacturing plant, a robot) defined through existing standards from the manufacturing domain. The device communication entity’s bottom layer comprises functional elements (FEs) to collect and process data from OMEs, as well as to actuate and control the OMEs. An example of such FEs could be a system that uses cameras and distance sensors for monitoring. Such a system could accurately determine the position and condition of a workpiece under the mill. The digital twin entity middle layer uses device communication to represent, manage, operate, simulate, and maintain the devices observed and controlled through the OMEs. For example, the distance and camera inputs are collected, processed, and forwarded to the digital twin entity. This entity contains models and analysis methods based on simulation models of the mill to predict a failure or malfunction. It could also provide an interface for updating the models, such as the path the mill needs to move along or the drilling speed and settings of the environment.

Through the user interface entity top layer, users and additional services can leverage the digital twin. For example, the interpreted data and model of the machine could be visualized at run time for maintenance without stopping the machine during milling. In this way, downtime for maintenance can be reduced and the behavior of the mill can be optimized under the supervision of a machine expert.

Bild vergrößern

Bild vergrößern

We have analyzed the conceptual frameworks for digital twins introduced above and identified capabilities that are required by (1) At least one of the frameworks, (2) At least two of the frameworks, and (3) All of the frameworks. Table 1 summarizes our findings, where each row represents an identified capability. To this, the first column assigns an identifier to the capability, the second column briefly describes the capability, the third column describes which framework it was derived from, and the last column details its context.

From this analysis, it also follows that the commonalities of the all investigated models, i.e., the essence of a digital twin based on its potential capabilities, consist of (1) Retrieving data from its counterpart (R01), (2) Sending data to its counterpart (R02), and (3) Digitally representing its counterpart (R04). Additional commonalities between some of the investigated models arise from considering requirements that at least two of them have in common: This, for instance, includes having a user interface (R03) and, according to [47, 53], the synchronization of properties between AS and the digital twin (R05) and its manifestation (cf. [70]). Other commonalities (see [31, 47]) include different ways of communication, including the need for reporting information to selected recipients (R06), communication with other digital twins (R07), and interaction possibilities with third-party systems (R08). Even though R07 and R08 are both requirements related to providing communication functionality, we made this differentiation on purpose: It makes a difference if we communicate with an application where we know the structure of the software system and might influence it (white-boy system), i.e., a digital twin created with a similar technology or using AAS, or an application, where we can only rely on the provided APIs of a third-party system (black-boy system), i.e., Manufacturing Execution Systems, or Enterprise-Resource-Planning Systems. More requirements are related to the functionalities that digital twins provide: this includes the need for different kinds of services [31, 47, 88] (R09) to act on data and models (some of them including detailed examples), as well as to explicitly describe the need for reasoning and analytics on data [31, 47] (R10). Clearly, R09 could be broken down into more specific categories of services, e.g., monitoring, optimization, prediction, visualization (cf. the purposes of DTs in the systematic mapping study on software engineering for DTs [26] or the DT capabilities in Fig. 7), however, what services a specific digital twin needs is strongly dependent on the purpose one wants to create a digital twin for. Considering this requirement from a software architecture perspective, all services require data and/or models as input, process this information to gain new knowledge, and produce an output. Therefore, we summarize them into one higher level requirement.

The need for Type 1 AAS is grounded in its file transfer as defined by IDTA [80]. As such, Type 1 AASs exist as serialized files, such as XML or JSON formats cf. Fig. 10). Here we see the set of AASs beginning (ll. 2 ff) and the definition of the milling machine (ll. 3-9), which contains the attributes from the illustrative example of Sect. 3 (ll. 4-7).

Bild vergrößern

These serialized shells encapsulate static information and can be shared among partners of different companies. This file distribution follows a template,¹² which outlines the structural relations between the contained submodels.

Considering the illustrative example from Sect. 3, the CAD model, the simulation models, and models of the milling machine are represented as submodels in the AAS as depicted in Fig. 4. Submodels can be identified by using BaSyx [50] to iterate over the relations established between the elements of the AAS and the linked submodels. However, BaSyx does not support parsing these submodels. For instance, a CAD model can be identified through the bill of materials, in which the relations and the instances are referenced in our example in Fig. 4. Further, the bill of materials also links the submodels of the spindle, the milling machine, the frame, and the simulation models. Another aspect is the connection to further AAS. These are also denoted in submodels which contain the relation as an ID, a description, and a value that contains the concrete address of the server. Comparing this with the digital twin requirements of the previous section, we notice that an explicit service component is missing and that the physical entities are depicted as an asset without concrete reference to the connection between the AAS and its asset depicted in blue in Fig. 11. In general, the Type 1 AAS can be used as a knowledge base, in which a dedicated submodel may contain relations between submodels. Such relations can also be noted in descriptive files. When implementing a connection between a digital twin and Type 1 AAS, the necessary interface includes an implementation, e.g., BaSyx, to identify the submodels. Reasoning on top of the submodels becomes a feature that the digital twin provides. Now we look at Table 2 and compare Type 1 AAS with the digital twin requirements from Table 1. First and foremost, the Type 1 AAS are serialized files without an active part. This leads to R01, R02, and R03 being answered with a clear no. The Type 1 AAS cannot receive data from its twinned counterpart without an interface (R01) e.g., BaSyx. This also means that it cannot send data back to its twinned counterpart (R02). There is also no explicit user interface provided off-the-shelf (R03). The Type 1 AAS represents its counterpart digitally (R04), e.g., the serialized files, the relations, and documentation describe static properties of the asset. It cannot synchronize properties with its counterpart, as the data have to be managed manually (R05). This also means that it cannot actively report information (R06), not actively interact with other AAS (R08), provides no services to act on data and models (R09), and cannot reason about data (R10). The Type 1 AAS can be integrated with other AAS by adding information on the relation with further shells in submodels. However an active behavior as communicating with other AAS is not possible (R07). In conclusion, we observe that Type 1 AAS can be used as a knowledge base, while the digital twin has to provide means to analyze and reason on the knowledge.

Type 2 AAS addresses a prevalent challenge in the current Industry 4.0 landscape: inconsistency in communication protocols between tools provided by various providers [37]. Thus, in contrast to pure file sharing, as with the Type 1 AAS, Type 2 AASs [9] are realized as an executable software system e.g., on a server. To read and write AAS files (and submodels), APIs are provided. Such Type 2 AASs can be realized with e.g., Eclipse BaSyx or AASX as mentioned in Sect. 2.

Bild vergrößern

In our example, this implies utilizing the submodels defined for a Type 1 AAS as the foundation for the Type 2 AAS’s repository as illustrated in Fig. 11. The repository can for example be equipped with a REST API [37], enabling access to a database. This database could facilitate the retrieval of information by providing shells on top of assets. In a centralized database, it is crucial to manage access in an industrial setting to safeguard the confidentiality and consistency of data and models across multiple submodels and AASs. Thus leading to increased importance of data and model consistency methods. However, another possible way to implement this could be an interface that provides access to Type 1 AAS. Typically, operations performed using these shells include a name (the name is used as an unique identifier for accessing the operation), a semantic reference (a link to the metamodel of the operation - in general a link to a submodel), an explanation (general information of the operation, e.g., a textual description of the functionality of the operation), input and output parameters. In the illustrative example, the application of a change to the PT, specifically the spindle of the milling machine, will affect the submodels of the spindle as well as all submodels which it is referenced in. To further illustrate, consider the type of the spindle, which changes from a high precision spindle to a low precision, high power spindle. Given the fact that the AAS is unable to detect changes on its own, the change of a spindle of unknown origin and type implies the need for a manual configuration of the submodel. Regarding the requirements on digital twins, similar issues are observed as in the Type 1 AAS, with the exception of improved connectivity due to its reactive nature.

Comparing the Type 2 AAS, as defined by IDTA in the specifications [46], with the requirements for DTs from Table 1, we observe the following (cf. Table 3). There is a discrepancy between the specified properties a Type 2 AAS has and the actual implemented properties. In the table, the fully filled circles represent the specified properties, the partly filled circles represent properties which are not specified but suggested by context, and the empty circle denote undefined requirements. Section 5.4 investigates the implementations and their properties in greater detail. The core of the Type 2 AAS according to the specifications provides an API with create, read, update and delete operations for managing submodels, so it can passively receive data from the asset (R01), but it cannot actively send data back to the asset. This means for R01, that it is fulfilled. It is possible to propagate values to submodels to influence the system’s behavior, but actively sending data is not possible (R02). In general, the specification enables a user interface (R03), but it is not specified nor suggested by IDTA. As the Type 1 AAS is part of Type 2 AAS, the actual system is represented digitally (R04).

The requirements (R05–R10) depend on the functionality of the actual implementation of the specified API to realize the reactive nature of the Type 2 AAS. We briefly discuss these requirements and provide further insight in Sect. 5.4. A Type 2 AAS, by its very nature, is unable to synchronize data between AASs. However, the IDTA specification suggests a solution in which a timer can be defined for data update intervals (R05). While the specification does not explicitly address the communication and interaction between digital twins, an integration with another Type 2 AAS is possible and suggested, by referencing the submodels and APIs of the AAS (R06). A reference could enable a communication between DTs and the interaction with other systems (R07 and R08) by using the references a way of data access from a shared repository, as shown in Fig. 11. Since these features have to be active communication, where data is sent back and forth between DTs, the R07 and R08 are not fulfilled. In regard to the provided services, when deploying the API as a REST-service it is possible to provide functionalities. As specification for Type 2 AAS ends with the requirement of an API. A service to access the API’s functionalities is suggested by IDTA, but also (R09)dependent on the actual implementation. Finally, the requirement for active reasoning is suggested in the specification, where references between submodels alongside regular expressions could be used for drawing conclusions on data (R10).

As the Type 3 AAS is not yet fully specified and still under ongoing research, we base our analysis on the research concepts. The Type 3 Asset Administration Shell extends the Type 2 AAS with additional features. It has an active behavior in addition to the ability to communicate and negotiate on its own [48, 80, 84]. This means it contains data-transforming functions, can obtain and transform/abstract data autonomously (e.g., for analyzing purposes), and is also able to act upon the AS on its own. For this bidirectional communication with the asset, the Type 3 AAS uses a well-defined I4.0-Language [8].

Others discuss the reactive components of a Type 3 AAS and describe a possible architecture of such a system [43]. This architecture comprises a passive and an active part of the AAS. The passive part is already discussed for the Type 1 and Type 2 AAS. The active part contains algorithms managed by a component manager and scheduled by an interaction manager. All these can interact with the environment via a messenger component that communicates using the I4.0 language. In this section, we call the single algorithms together with the interaction and component manager services. This concept is then again refined by Mediavilla et al. in [60]. They describe a conceptual architecture for engineering change management with a Type 3 AAS. Here, the AAS contains an API and again active services.

Ultimately, a Type 3 AAS contains a passive part, already present in a Type 1 AAS and a Type 2 AAS as well as an active part (cf. Table 4), illustrated in Fig 12. This active part contains reactive and proactive services that implement the autonomous behavior required by the IDTA.

Bild vergrößern

With the Type 3 AAS extending the capabilities of the Type 2 AAS with additional I4.0-compliant communication and active behavior, we take R01 (Asset Receiving) and R04 (Representing) as been fulfilled by each Type 3 AAS. Therefore, we concentrate on the requirements which were for the Type 2 AAS not fulfilled and for digital twins required, namely requirements R02, R03, R07, and R08 and the already implemented digital twin requirements R05, R06, R09, R10. We refer to the reference architecture from [43], to discuss which digital twin requirements must be fulfilled by the Type 3 AAS and which are possible or likely to be implemented. With the ability to autonomously send data to its associated asset, an implementation of the Type 3 AAS fulfills R02 (Asset Sending). This data comes in the format, the asset is capable of processing. In most cases, this might be control commands to an actual system. The AAS uses the I4.0 language to communicate with the asset. R03 (GUI) describes that a twin needs to have a user interface. According to [89], a user interface is an “interface that enables information to be passed between a human user and hardware or software components of a computer system”. The Type 3 AAS offers an HTTP interface which can act as a remote interface when logging in via a remote console. To this point, the AAS does not require to have a graphical user interface by itself but can produce data that can be interpreted as graphical elements. Although, referring to the definition given in [89], the HTTP interface together with a remote machine, interpreting the communication, might act as an interface, the Type 3 AAS does not come with a GUI out-of-the-box. Therefore, we state that R03 is possible but not defined by the IDTA. R05 (Synchronizing) asks for the capability to synchronize (selected) properties with its counterpart. Those properties therefore must be present in the asset and in the AAS. Synchronization goes bidirectional. With its ability to receive data from the asset, the AAS is already capable of mirroring properties and property changes in the AAS, either by being notified or by pulling the required information. The Type 3 AAS is capable of bidirectional communication with its asset. Therefore the AAS can send control commands to the asset which alter the asset’s properties. A synchronization service could detect all changes in the AAS properties to be synchronized and send according to control commands to its asset. However, the synchronization must be triggered, either by some AAS functionality or by a user. Manual user synchronization can be triggered via the user interface and autonomous synchronization of asset properties can be done by a monitoring service. With this, the Type 3 AAS does not fulfill R05 out-of-the-box, but the implementation of it is possible and very much likely to utilize its abilities. R06 (Reporting) describes the ability to report information. We already described how a service could autonomously synchronize data with its associated asset. In the same manner, the Type 3 AAS can synchronize reporting information with another party, either bidirectional or only from the AAS to the reporting recipients. So, the Type 3 AAS again is not out-of-the box capable of reporting information, but has all components to implement such a behavior. A Type 3 AAS is capable of an I4.0 language and at least some HTTP interfaces. Assuming the I4.0 language is processable by other DTs, a Type 3 AAS can communicate with other digital twins, fulfilling R07 (Twin Communication), the ability to communicate with other digital twins. This communication is processed in the AAS active services for specific submodel purposes. Other 3rd party systems can communicate with the AAS via the HTTP interface or the I4.0 language, respectively, fulfilling R08 System Interaction, the ability to interact with other systems. R09 (Added Value Services) requires services to act on data and models, while R10 (Reasoning) also requires services to reason about data from other systems. The architecture for a Type 3 AAS defines an active behavior and requires autonomous services. These act on asset data and potentially models that are not limited to asset data and models, but can also act and reason on data from other systems. The IDTA does not specify in which manner the active behavior interacts with the asset data or models, but it is very likely that the Type 3 AAS does act on asset data and reason about it, as the main use case in industrial environments.

In summary, our understanding is that a Type 3 AAS is capable of implementing all of the previously derived requirements for a digital twin. With its active autonomous behavior, it overcomes the shortcomings of the Type 2 AAS regarding our derived digital twin requirements.

Now we look at some implementations of AAS from industry and from research to provide a broad overview of possible functionalities in-between the specified AAS types in Table 5. A file transfer protocol, as i.e., supported by FileZilla server ,¹⁴ may be employed for the manipulation of Type 1 AAS. In its most basic form, the Type 1 AAS is a file stored on a local drive (R04). This approach is compliant with the Type 1 AAS as defined in the specification. However, as the file is unable to manage data in its submodels, it is not capable of receiving data, thus not fulfilling the requirement of being a Type 2 AAS.

The IDTA provides sample projects¹⁵ and a server¹⁶ hosting them. These projects fulfill the requirement for the asset to be represented digitally (R04) and are in accordance with the Type 1 AAS. However, as the file server is also unable to manage data in its submodels, the files are not capable of receiving data on their own, thus not fulfilling the requirement of being a Type 2 AAS. Only in combination with the server the minimal requirement of being a Type 2 AAS would be fulfilled. In conclusion, both the file transfer protocol and the sample projects, provide no further features and thus do not fulfill any other requirements.

The BaSyx framework provides an API to interact with the Type 1 AAS through a component called registry. The BaSyx framework further provides a database interface to persist the state of the Type 1 AAS. The BaSyx framework is conform to a Type 2 AAS. It is able to receive data from the asset (R01) and represent the asset digitally (R04). Functionalities such as sending data to the twinned counterpart (R02), active reporting to a selected recipient (R06), communication and interaction with other DTs (R07 and R08), the provision of BaSyx as a service (R09) and the reasoning on data (R10) are open for future extensions. At this time, two features have been incorporated into BaSyx, which extend it from a Type 2 AAS. With the AAS Web UI provided by the BaSyx framework a user interface is added (R03). A DataBridge component enables a timed synchronization between the asset and the Type 1 AAS R05. Any further functionality can be built on top of this basis. This means that requirements for a Type 3 AAS are partly fulfilled, while mandatory ones such as R07 and R08 are not fulfilled. In research on the connection between Type 2 AAS and a database [37] the connection between the AAS and an API to automatically store data was researched (R05). With the involvement of multiple Type 1 AAS, connected to a single database backend a connection to selected recipients is shown (R06). Since the backend is independent from the Type 2 AAS an interaction between Type 2 AAS and a self-developed system is shown (R08). With the representation of the asset and the ability to receive data from the asset R01 and R04 are fulfilled. Since the focus does not cover the communication between DTs, any value services or reasoning on data the requirements R07, R09 and R10 are not fulfilled. Overall this research is a Type 2 AAS as per definition and adds features to it. In other research [7, 10, 22] the focus is shifted toward the modeling of submodels inside of the AAS with regard to the templates provided by the IDTA. While the modeling is also an important aspect, it remains unclear how a DT is supposed to interact with other DTs and systems. Consequently, it is not possible to find an answer whether our requirements are fulfilled. Eclipse Papyrus4Manufacturing¹⁷ is a graphical modeling tool for industry 4.0 and provides integration with BaSyx. Thus also fulfilling the requirement of being a Type 2 AAS. As this tooling is also reliant on the implementation and specification of the user, fulfillment of the requirements R05-R10 remain open.

Digital twins are complex software artifacts that combine data, models, and services to provide better insights and added value on top of the twinned system. Consequently, their engineering is challenging and costly. With one of the main reasons for the success of software being its reusability (e.g., classes and libraries in-the-small, apps and containers in-the-large), digital twins should benefit from efficient reuse mechanisms as well. Methods for the composition of language-independent software through superimposition [4] or the composition of event-specific context-dependent behavior through language constructs [5] are commonly practiced for software. For digital twins, this is not the case. Although recent studies claim to compose digital twins, they commonly limit themselves to a virtual representation [3, 28].

Wherever a digital twin of a larger system (e.g., a factory) logically consists of digital twins of smaller systems (e.g., production machinery), reusing the smaller digital twin as part of the larger one should be as easy as reusing existing classes in another software [65]. Moreover, digital twins of specific systems should be transferable to similar systems easily, e.g., allowing for systematic reuse (parts of) the digital twin of a sports car of one brand with the sports car of another brand. Through MDE methods a possibility opens of leveraging existing models of a digital twin for a transfer across the boundaries [17]. These methods focus on heterogeneous models, bidirectional synchronization, and the development throughout the system lifecycle. While also opening up new challenges such as the question for a modeling language, an architectural framework, inconsistency, model and data management. Currently, neither form of reuse is supported systematically, which is why creating digital twins still demands tremendous handcrafting of software artifacts, which hampers the adoption of digital twins.

Reuse for AAS is a built-in property through the use of AAS submodels. These define the underlying data structure and thus promise modularity and reusability. Therefore, for Type 1 and Type 2, different AASs of similar assets or even similar domains are built similarly. However, since Type 1 and Type 2 AASs have little or no software engineering, their development consists mainly of setting the right values. Type 3 AAS engineering consists of more sophisticated software engineering that defines their active behavior. This active behavior could be implemented, for example, by a service that works on data consistent with the data models of the submodels. This promises reuse of such services for different Type 3 AASs, since the input data looks the same. Composability of AASs from other smaller AASs may be possible due to well-defined interfaces, but the number of different submodels¹⁸ and possible combinations of them, as well as their quality, make it difficult to predict the actual engineering effort.

Digital twins will be largely operated and configured by experts in the respective application domains. These rarely have received formal software engineering training, which limits the expressiveness of technologies that should be applied to configuring digital twins. Using low-code development platforms or low-code development approaches [30] for digital twin engineering can enable domain experts to create, configure, and operate tailored digital twins for their specific domain of interest [25] using their domain expertise, concepts, and terminology.

In addition, the concrete application domain may also have different requirements for a low-code platform coming from possible users, e.g., which level of abstraction has to be provided for the intended users when describing configuration information. This covers the whole spectrum from (1) the type of representation, e.g., text-based approaches, graphical interfaces, or wizards, (2) different levels of knowledge, e.g., domain experts covering a broad spectrum of information about an asset to niche knowledge for a particular part of the asset, and (3) the depth of technology understanding, e.g., without software engineering skills up to software engineering experts. Thus, low-code development platforms have to be tailored for their intended AAS user groups.

Such low-code development platforms could either be developed as open-source, e.g., BESSER [2], or in-house if companies create digital twins for themselves regularly or sell them to customers. However, their core development will be easier if more AAS aspects are standardized, especially services to be used within Type 3 AASs and their communication interfaces within a digital twin implementation.

In manufacturing, a lot of information that would be interesting for digital twin creation with AAS, is already created during, e.g., the engineering process of production machines, factory planning, and process planning (cf. “Representing Systems with Models” in the Systems Engineering Body of Knowledge [85]). With the SysML v2 release, it is also to be expected that more systems engineering models will be available in an interchangeable format within the next few years. Reusing this information would be helpful for engineering digital twins [21]. This requires extraction of the information from these engineering models into information needed in submodels. This transformation could be improved by reusing the information already provided and standardized in submodels, as they could parametrize this transformation.

Moreover, up to now, it is unclear how information during runtime of an asset could be brought back to the development process of the asset [24] using AAS technologies. This requires adding a methodology and tools on top which enable the analysis of information relevant to improving the development. As the realization of Type 3 AAS is planned, such mechanisms could be integrated in the active part as algorithms. However, reuse of these functionalities is not considered if they are to be realized newly for every AAS.

There exists a large MDE body of knowledge on models@runtime [12, 18] which is specifically of interest for AAS Type 2 and Type 3. Models@runtime approaches can support the bidirectional synchronization between digital twins and their counterparts [16]. While different types of runtime models [12], e.g., structure, behavior, quality, goal, requirements models, could be of interest for digital twins developed with AAS technologies, concrete examples, and their implementations are missing.

When it comes to connections between different digital twins, open challenges still remain [66], e.g., how digital twins on different levels of details can be integrated or can exchange information on different levels of granularity. It still requires manual effort to map and integrate information between different levels. This problem arises in particular with AAS, as they claim to represent an AS over its entire lifecycle, which consequently results in integration challenges when ownership of an AS is transferred from one party to another [39].

Semantic challenges, such as inconsistencies, could be solved by using standardized submodels [37]. However, this might not be possible in all cases, as this requires forcing a certain view of the world on each application domain. Thus, mechanisms for translating or linking information from different submodels might be a more sensible way to go.

The technical connection between the AASs for Type 2 AAS is, depending on the Type 2 interpretation, based on established technologies, primarily REST via HTTP(S) and Open Platform Communication Unified Architecture (OPC UA) or is implemented in proprietary interfaces OPC UA is used in particular to drive convergence between Information Technology (IT) and Operational Technology (OT) systems and to ensure interoperability in manufacturing [71]. Standardized, Industry 4.0-compliant communication is part of Type 3 AAS [80], a specification is pending.

One limitation of our analysis of requirements is that it is purely based on functional requirements. This is due to two reasons: The existing approaches rarely mention non-functional requirements (e.g., [32] mentions privacy, security, safety, resilience, and reliability), and such requirements are strongly connected to the application domain, i.e., safety-critical domains require different aspects in their digital twins than other domains. This also includes the question of how to handle inconsistency or similarity. When creating digital twins for complex cyber-physical systems, we have to cope with the inconsistent behavior of these assets. There exist approaches for the explicit representation and treatment of uncertainty [29], that require uncertainty-aware controlling components in the digital twin. Other approaches enable us to measure the similarity between an asset and its digital twin [68].

MDE tackles some of these non-functional requirements [17], e.g., uncertainty modeling integrated in the digital twin development to explicitly cover it in the design phase, or the ability to integrate evolved asset information in the form of models. With the various submodels ¹⁹ regarding different non-functional requirements like Functional Safety, Security Engineering, Reliability, Maintenance, or ecological Carbon Footprint, the AAS covers the means to support storing information needed for fulfilling some of the non-functional requirements stated. However, how this data is used and played back to the actual system in an, e.g., Type 3 AAS, remains to be defined and is up to the developer for now.

Engineering models, models@runtime and the asset we are creating a digital twin for could evolve. Thus, approaches for digital twin evolution need to be developed [27, 63] and adapted for digital twins we are creating with AASs. Currently, new submodel templates are developed which are a conservative extension of existing AAS submodels. Thus, for Type 1 AAS rather values in submodels are changing based on the changing reality. For Type 2 and Type 3, it could also affect the connection to the actual system and its control interfaces. If the Type 3 AAS autonomously computes data, e.g., for analysis purposes, depending on the requirements for this analysis the need for data might also change over time.

There exists a variety of MDE approaches to support system evolvement, e.g., for (meta-)model evolution, software migration, software reuse, and to check correctness and consistency during and after model evolution. However, approaches for the co-evolution of AAS across multiple meta-levels including its submodels, models, and data are to be researched. Here, collaborating with researchers from data and process modeling [62] would be helpful to integrate MDE methods with methods from data and process engineering. In addition, the evolution of AAS services with models, and their data is a challenging open research aspect.