Keywords

1 Introduction

Digital twins (DTs) [1,2,3] have become more prevalent recently. They are used to support the design, operations, and analysis of complex systems in many domains, such as automotive [4], construction [5], medicine [6], or robotics [7], and comprise much information about the systems and processes of the twinned original system. They promise not only a better understanding of cyber-physical production systems (CPPSs) during their design time [5], but also more efficient operations of these systems [8]. For this purpose, (i) operational knowledge must be obtained from operational data, which serves to optimize the system under consideration and to develop subsequent system versions more efficiently and (ii) expert knowledge must be made machine-processable for the operation of digital twins. Operational knowledge and expert knowledge [9] can be represented by models and, thus, automatically processed at runtime by the digital twin and the system. The operation of such digital twins therefore requires the use of software and system models at runtime, which demands that appropriate models can be formulated, analyzed, and used for interpretation or synthesis. For this purpose, the modeling languages in which these models are formulated must be explicit, machine-processable, and meaningfully integrated. Yet, most digital twins are designed and engineered ad-hoc, in a piecemeal fashion, which is costly, binds valuable engineering resources and hampers research as well as industrial application of digital twins.

Leveraging the abstraction and automation of model-driven development yields more efficient and sustainable engineering methods for digital twins. Based on interdisciplinary research conducted at the German “Internet of Production”Footnote 1 excellence cluster, we combine model-driven methods for the engineering of information systems, software architectures, and software language engineering to systematically and sustainably engineer digital twins. Within this chapter, we discuss challenges on the road to a systematic engineering of digital twins, present our model-driven approach for their engineering as well as possible implementations for different purposes. Our insights may guide researchers and practitioners to sustainable, planned, and efficient engineering and operations.

In the following, Sect. 2 introduces foundations before Sect. 3 discusses challenges in engineering digital twins. Section 4 introduces sustainability with and for digital twins, and Sect. 5 presents model-based approaches to consider sustainability with and for digital twins. Section 6 debates the related work before the last section concludes.

2 Background

2.1 Digital Twins in Production

A pillar of “Industry 4.0” [10, 11] is the digitization of participating CPPSs, processes, and stakeholders to facilitate design-space exploration, integration, verification and validation, monitoring, and the optimization of system behavior. Under the umbrella term “digital twin” [2, 3], research and industry in production have produced various approaches to modeling the digital representations of CPPSs for specific purposes. These approaches define digital twins as “digital equivalent to a physical product” [12], an “always current digital image of the production system” [13], “a mimic of a real-world asset displaying up to date information of what is currently happening” [14], “an integrated virtual model of a real-world system containing all of its physical information and functional units” [15], or “a virtual representation of an asset used from early design through building and operation” [16]. While there are many more approaches to define digital twins, most of these assume the same main functionality inherent in the definitions above: to digitally represent a system, process, or person during their operation [17].

In the following, we understand digital twins as software systems comprising data, models, and services to interact with a CPPS for a specific purpose. Therefore, each digital twin is connected (twinned) with an original system (the CPPS), which it represents and interacts with. We also assume the distinction that a digital twin has automated data flows from and to the twinned original system [2] to (i) obtain data from it to represent its behavior and (ii) to send data to it to change its behavior. These purposes can include obtaining a better understanding of the system under development or operation [1], predicting its behavior [18, 19], such as its need for maintenance, or prescribing its behavior to optimize it [8, 20].

2.2 Model-Driven Engineering

The number of software systems is continuously increasing. Additionally, they are becoming more important and more complex [21, 22]. The increasing complexity of the software of such CPPSs demands better concepts, methods, and tools that enable overcompensating this growth in complexity and harnessing their potential. An important reason for the complexity of CPPS’ software is the conceptual gap between the problem domain challenges and the solution domain peculiarities. Overcoming this gap with handcrafted solutions demands enormous efforts and gives rise to accidental complexities [21], which are addional challenges in the solution domain that the problem domains abstract away from. For instance, to make a robot pick an object (a problem domain task), one needs to program it taking care of memory management, persisting data, or network access (solution domain peculiarities). These accidental complexities increase software engineering risks, and it is paramount to reduce these.

Model-driven engineering [21, 23] captures software development methodologies that employ models to increase abstraction and reduce the conceptual gap. Therefore, from a model-centered perspective [24], researchers and practitioners utilize models as primary communication and development artifacts for various engineering activities, ranging from design, to documentation, requirements modeling, implementation, or deployment. To be machine-processable, these models conform to modeling languages [25], which can use more abstract terminology and concepts than programming languages. Using modeling languages tailored to a specific domain, so-called domain-specific languages (DSLs), enables problem domain experts to contribute to the development of complex systems directly and without needing to become solution domain experts. Models of such languages then can be automatically translated into software artifacts leveraging code generators that embody domain expertise (e.g., how to take memory management into account properly).

2.3 Digital Shadows for Production

Digital Shadows (DSs) [26, 27] capture the idea of collecting, aggregating, and abstracting manufacturing data for specific purposes sufficiently fast, such that decisions made on this data can impact processes and CPPSs having produced the data in a timely fashion. In contrast to digital twins, digital shadows, therefore, comprise only a reduced or abstracted subset of the available data (and possibly models) to represent a system with respect to a specific purpose. For this purpose, digital shadows need to comprise various kinds of data (such as measurement data, simulation data, and models) from different sources. We abstract and aggregate the data in domain-specific and application-specific ways and augment it with necessary metadata to fulfill the DSs’ purpose. Through their specific abstraction and aggregation, digital shadows can be optimal data structures to ensure timely decision-making in CPPSs.

A result of the interdisciplinary research in the German “Internet of Production” cluster of excellence is a reference model that captures the main concepts of the digital shadow. It acts as a common foundation to standardize the architecture of the relevant data held in a digital shadow. The reference model is shown in Fig. 1 as a UML class diagram and shows the reference structure, consisting among others of the main container DigitalShadow, the asset it stands for, the purpose the shadow fulfills and it’s contained DataTraces. As the authors of [26] propose a purpose-driven approach for the DS, the purpose specifies what the DS is supposed to do. An asset “is an item, thing, or entity that has potential or actual value to an organization” [28, 29] and can be of physical or virtual nature. Assets are, e.g., manufacturing machines, human workers or a software component. For more complex assets, the structure can be composed into subcomponents. Sources (which also can be an asset) produce data of interest for our system and are, e.g., measurements or sensor data. This data is captured as DataPoints gathered in DataTraces where data points are single data entries, e.g., a table column as a snapshot at a point in time. A data trace always originates from a source (e.g., machine) and can be enriched with MetaData holding additional information like the experimental machine setup relevant for this data. In addition, Models supply a deeper understanding of the system structure and behavior or provide calculation specifications on how to aggregate and abstract the gathered data. Using this reference model, we can formalize the contextualized data aggregation in a common manner that sets the foundation to model-driven generation of digital shadows.

Fig. 1
figure 1

Conceptual model describing digital shadow structures [26]

Full size image

3 Challenges of Digital Twins

The idea of a digital shadow is subject to ongoing research [30, 31] and in the past has rarely been properly distinguished from the idea of a digital twin. Following a popular definition of digital twins based on the data flows between the original and its digital representation [2], the distinction is clear: a digital shadow follows the original system under a specific illumination (view), whereas the digital twin follows the original system as well but also may change the behavior of that system. To this end, a digital twin must be a complex software system that interacts with the original system: neither a simulation model nor some cloud-based data storage and analytics (e.g., with AWS or Microsoft Azure) alone can fulfill the requirements imposed by this definition.

This confusion about definitions is a prime reason for why research on the reuse of digital twin (parts) is not advancing at a fast pace. Despite knowing that reuse (e.g., in the form of inheritance, frameworks, libraries, or containers) is one of the prime drivers of efficient software engineering (essentially, digital twins are software), there currently is little research on reusing digital twin parts to systematically and efficiently engineer more complex digital twins from less complex ones. For instance, when composing a car chassis with a motor, the corresponding digital twins should be composed as well, or when integrating a sensor in a production system and the system into a factory, their twins should be integrated as well. Instead, digital twins are created in an ad-hoc manner.

In the literature, there are different life cycle stages of digital twins w.r.t. to the twinned system. A DT might represent the original system “as-designed”, “as-manufactured”, or “as-operated” [32]. While digital twins “as-designed” tend to be in place at design time of their corresponding original system [33], the latter two kinds of representations often aim at representing the runtime of the original system. There is little research on integrating these perspectives, which can entail that there are DTs of a system “as-designed” and “as-operated” that are developed independent from another and with little synergies between both. One important reason behind this is that this terminology hides a fundamental distinction: a digital twin of a system “as-designed” aims to represent the idealized type of that system, that is, its developers aspire to it as being a valid representation for all instances of that system, whereas a digital twin “as-manufactured” or “as-operated” needs to incorporate manufacturing tolerances and effects, as well as the wear and tear of the individual system instance. This gap demands further investigation.

In line with these challenges, there is also little research on systematically engineering digital twins together with the original system (greenfield) or after the original system has been deployed (brownfield). Both enable different functions in the corresponding digital twins. In a greenfield approach, the data required for the digital twin to perform its intended functions can be considered in the interface of the original system. However, in a brownfield approach, this might not be possible and hence, brownfield engineering of digital twins will be subject to restrictions regarding what can be observed from the original system.

4 Sustainability and Digital Twins

Sustainability is of increasing importance. It comprises social, economic, and environmental aspects [34]. Social sustainability is often related to respect for individuals, equal opportunities, diversity, and human rights. Economic sustainability is related to economic growth. Environmental sustainability has the aim to improve human welfare through the protection of natural capital. They can be seen either as distinct perspectives [35] or as a system influencing one another [36]. The further definitions of these aspects differ in the literature, but what seems to unite them is the critique of the economic status quo from different ecological and social perspectives [34]. The United Nations General Assembly has further detailed these areas and suggest 17 sustainable development goals (SDGs) with 169 associated targets [37] that should be achieved by the member states. This results in passing on the targets to companies, local authorities, and nudging of individuals.

Recent literature about sustainability and digital twins has a special focus on sustainability assessment or evaluation, e.g., for educational buildings [38], railway station buildings [5], or smart campuses [39]. Other work focuses on the improvement of sustainability performances of whole value chains due to the simulation and optimization services digital twins are able to provide, e.g., in production [40], the future development and assessment of intelligent manufacturing along a set of indicators [41] and life cycle sustainability assessment in the clothing industry [42].

To sum up these approaches, we can develop digital twins

  • to support the assessment of sustainability targets due to their ability to monitor, calculate, and visualize key sustainability indicators defined by humans,

  • for the simulation and forecasting of sustainability indicators if they use historic information together with forecasting algorithms, and

  • which integrate digital twin services that

    • assist with responsible consumption and use in relation to created products,

    • enable simulation of different variants of digital twins before building the physical one to improve resource efficiency,

    • facilitate optimizing production processes toward waste reduction and energy saving allowing a responsible production, and

    • provide self-adaptability to improve resource efficiency.

Talking about the sustainable development of certain objects, none of these approaches consider that the digital twins themselves could be the objects that are sustainably developed. Model-driven engineering [43] is a promising approach to support the sustainable development of digital twins in different regards, especially when using DSLs. It leads to (1) an increased development speed and reduced development time; (2) better software quality, e.g., less bugs, because of well-defined domain-specific modeling languages, automated model checking, transformation, as well as test and test case generation, leading to reduced development time in the long run of a software system; (3) improved maintainability as cross cutting implementation aspects can be changed in one place which again reduces the development time; and (4) empowered domain experts by developing low-code platforms for the development of digital twins.

Considering human resources, these aspects are supporting sustainable development goals in the areas of resource efficiency in consumption and production and allow to reduce technological inequalities. Less development time leads to reduced energy needs for the engineering process of digital twins.

In the following section, we show some of these approaches and their impact for companies, products, and humans.

5 Approaches for Sustainably Developed Digital Twins

We have conceived, analyzed, discussed, and realized different model-driven implementations of digital twins and the process to derive large parts of their implementation from these models to reduce the effort and resources required in engineering digital twins and ultimately improve the economic sustainability of their development.

5.1 Model-Driven Engineering of Self-adaptive Digital Twins

We have realized our architecture for DTs using the component and connector architecture description language MontiArc [44]. In MontiArc, software systems are described using hierarchical components that are connected via typed directed ports. Ports describe incoming and outgoing messages of components. Components can either be decomposed, consisting of one or more subcomponents, or atomic, providing a behavior implementation on themselves.

Our digital twin architecture [1, 8] facilitates self-adaptive manufacturing by recognizing the behavior of the twinned system that diverges from the intended behavior over time. It then takes measurements to fix or mitigate this divergent behavior. We employ different modeling techniques to leverage domain expertise to improve the capabilities of digital twins for adapting to such situations.

The architecture for self-adaptive digital twins consists of four components each realizing a step in the self-adaptive loop (see Fig. 2):

Fig. 2
figure 2

Reference architecture for self-adaptive digital twins (based on [1])

Full size image
  1. 1.

    Data Processor: It is connected to and collects relevant data from the Data Lake. The Data Lake encapsulates multiple databases storing data about the physical system and its environment.

  2. 2.

    Evaluator: It supervises the data collected by the data processor and triggers the reasoner if unintended or divergent behavior is recognized.

  3. 3.

    Reasoner: If triggered, based on data describing the intended behavior, it plans a solution to rectify the diverging behavior.

  4. 4.

    Executor: It is connected to the physical system, converts the solution of the reasoner into machine-executable commands, sends them to the physical system, and observes their execution.

To instruct and transfer domain knowledge into the digital twin architecture in a model-driven fashion, we leverage different domain-specific languages:

  • UML/P class diagrams [45] describe elements of the domain, and their relations with each other.

  • Object-constraint languageFootnote 2 formulate constraints on the classes of the domain model.

  • Event condition action [1] models enable domain experts to define events based on conditions over instances of the classes of the domain model. Actions define the digital twin’s reaction to an occurring event. This action triggers the reasoner of the digital twin to plan a solution for the detected event. Event models are interpreted during runtime.

  • Case-based reasoning [8] is used for problem-solving. It reuses existing solutions from already encountered situations and computes solutions to occurring problematic situations on their basis. A case contains a condition based on the domain model, its solution, and the intended situation after applying the solution. Case similarity models define similarity metrics for cases. With that, the case-based reasoner knows based on which parameters, cases are more or less similar. Both, the case description models and the similarity models are interpreted during runtime. With more cases solved, the case base grows over time.

  • Communication specifications enable the definition of data types that are accessible via a specific endpoint with a defined protocol. Currently, the architecture supports OPC-UA [46] and MQTTFootnote 3as communication protocols in our communication specification models.

  • Query definitions are specifiable via an expression language. It comprises the expressions such as maximum, minimum, or simple mathematical expressions. The query language is employed for collecting and aggregating data in digital shadows from sources such as the Data Lake.

For deriving models of the mentioned modeling languages, existing engineering models of the CPPS can be reused. To this end, CAD, kinematics, material flow, control models, and others can be employed to derive events and parts of the domain model. This lowers the initial effort in developing the digital twin. The automatically derived models can be enriched by domain experts with further details.

Regarding sustainability, our digital twin enables humans to define sustainability via the modeling of events and case-based reasoning goals, and the respective architecture components responsible for monitoring and calculating indicators based on these models enable the assessment of sustainability targets. Furthermore, our digital twin is self-adaptive to improve efficiency and save resources by optimizing the production process.

Sustainable development is achieved through increased development speed by employing modeling languages and models for different aspects of the digital twin. These modeling languages are domain-specific, and, thus, empower domain experts to configure the digital twin to their needs through the reuse and semantic reification of common concepts of the model-driven development of digital twins.

5.2 Generating Digital Twin Cockpits

Digital twins require an interface for inspection and control. We define a digital twin cockpit as follows:

“A digital twin cockpit is the user interaction part (UI/GUI) of a digital twin.

It provides the graphical user interface for

  1. 1.

    visualizations of its data organized in digital shadows and models, and

  2. 2.

    the interaction with services of the digital twin, and thus

  3. 3.

    enabling humans to access, adapt, and add information and

  4. 4.

    monitor and partially control the physical system [47].”

Key aspects for a digital twin cockpit, such as the data structures and user interfaces, can be described with models. Using the MontiGem generator framework [48], developers produce a web application that can serve as a cockpit for a digital twin. It can be connected to the reference architecture for self-adapting digital twins [49]. The target application is a server-client architecture connected to a relational database (see Fig. 3). To realize the digital twin cockpit, a data structure and a UI generator are used. The first one generates the infrastructure that connects both the database and the client to the server. Based on the input domain model, it provides a multitude of interfaces to perform CRUD operations in the database as well as process client input in a systematic, authorized, and authenticated manner. The components created by the UI generator are fitted to the provided interfaces from the data-structure generator and thus provide implementation for detailed views on the current data available to the back end.

Fig. 3
figure 3

Artifacts of the MontiGem generator framework used to generate a digital twin cockpit with multiple interfaces according to each role of the end user

Full size image

This approach supports reusability of components and models, due to its model-driven design, enabling sustainable methodologies for software development. With this approach, the developer can rapidly implement digital twin cockpits that are easily adapted with custom logic and extended with further complex data structures.

5.3 Process Prediction as a Digital Twin Service

Using process mining techniques, we are able to analyze event data from physical systems and extract information related to processes, e.g., discover process models [50]. To systematically improve the operation of digital twins, we can use these techniques: Process discovery from runtime data of the physical object, conformance checking if the processes of the physical object are running as planned, and simulations or process prediction using process models where changes in processes in the long run can be foreseen [18].

We need to additionally provide functionality to handle explicated processes of the physical object and its context in the digital twin cockpit, which leads us to the concept of process-aware digital twin cockpits. A process-aware digital twin cockpit “is a digital twin cockpit that additionally provides functionality to handle explicated processes of the physical object and its’ context” [47]. To integrate process prediction and conformance checking services allows us to analyze the processes of the CPPS based on real-time data during runtime of a self-adaptive DT.

We envision a model-driven DT architecture that uses models at runtime and incorporates process mining techniques (see Fig. 4) covering the following six steps:

Fig. 4
figure 4

Process discovery services as well as conformance checking services as parts of a digital twin visualized in process-aware digital twin cockpits

Full size image
  1. 1.

    Generation of the DT: Using domain knowledge of experts and from engineering models, e.g., AutomationML, CAD, Modelica, SysML, we can create a set of application-specific models such as class diagrams for the structure, or process models representing the machine processes or processes of related humans. Together with application-independent models, e.g., the DT architecture or the basic digital shadow or process model structure to handle models during runtime, these models are used as input for code generators to generate a DT (see Fig. 4).

  2. 2.

    Configuration of the generated DT application: We have to add relevant runtime models and specify digital shadow types. We need to know for which purpose the DS is needed, which data accessed by a fully qualified address with respective data points and metadata, should be chosen and how it should be aggregated.

  3. 3.

    Initialization of DSs: Using the DS types, the DT computes relevant DSs from the latest data and stores them for further processing.

  4. 4.

    Process discovery: By applying process discovery algorithms on data transformed into event logs, we can discover how processes run in the real environment. They can be stored and visualized in the DT cockpit.

  5. 5.

    Runtime analysis: In a next step, discovered processes can be compared to processes-to-be in conformance checkers which allows to identify problems and reconfiguration needs of the physical object. Moreover, they can be used for process prediction.

  6. 6.

    User interaction: At runtime of the DT, human users can view data and processes about and interact with the physical object and the provided services of the DT.

These functionalities allow us to create DTs supporting sustainability, e.g., to compare as-is-processes with to-be processes regarding their use of materials and production of waste.

5.4 Low-Code Platforms for Model-Driven Digital Twins

Digital twins are highly complex software systems that require a high amount of development resources over a long time period. A high number of the components of a digital twin are either systematic or can be categorized as “boilerplate code”, thus enabling a good application of generative approaches. Low-code development platforms (LCDP) aim to operate on similar principles as generators, by providing a large amount of implementation based on simple configurations and models.

The generator framework MontiGem [48] can be used to create a LCDP that enables the developer to configure and finally generate a digital twin [51, 52] (see Fig. 5). MontiGem is extended with LCDP language plugins and a model library covering multiple use cases. This enables the generation of a LCDP that provides the developer with user interfaces to configure the multiple models that ultimately define the digital twin. Once configured, the same framework can be used again to generate further digital twins for the same use case.

Fig. 5
figure 5

Process in which MontiGem is used to generate an LCDP, which in turn is used to configure and control digital twins

Full size image

This approach combines the benefits of generators and LCDPs to rapidly produce multiple digital twins that can be used with similar configurations, e.g., on multiple machines on the same factory floor. This approach reduces development resources and, thus, supports the sustainable development of DTs.

5.5 Ontologies and Digital Twins

Ontologies [53] provide the terminology to express domain knowledge and make this locally gathered knowledge and its semantic concepts globally available. Ontologies, similar to UML class diagrams, describe structural parts of (production) data as well as their semantic interconnection. Reasoning and inference rules are used to derive new knowledge on a given data set. One of the driving purposes of ontologies is the ability to reuse domain knowledge: A detailed ontology, published by a group of researchers, can easily be repurposed by others allowing for combining ontologies to larger vocabularies tailored to a specific domain.

In our digital twin architecture, we can use ontologies to enrich the domain’s structural part described by annotating additional information to classes and attributes in the class diagram. Commonly used concepts in production, such as sensors or material properties, are already defined in ontologies [54] and provide the development process of DTs with a formally defined vocabulary. This way, we can connect locally specified structure elements to globally valid concepts in a model-driven manner, reuse pre-existing components, and provide an easier comparison to other use cases.

5.6 Assistive Services Within Digital Twins

Digital twins could provide intelligent assistive services supporting human operators, e.g., they could assist operators in production processes in making the best possible decisions using human-behavior goals [55]. This is important, as operators have to handle an increasing amount of detailed information. Within not fully automated production steps, we can use assistive services within DTs to analyze a current task, identify next tasks, and suggest their (semi-automated) execution [56]. These intelligent assistive services [57] (1) provide support for human behavior tailored to specific situations, e.g., in case of adding resources in the production process or making repairments. (2) The support is based on stored and real-time monitored structural context and behavior data. Within DTs, especially ones which explicitly handle process information, large parts of the data are already available, e.g., process models for describing the physical object or relevant data and parameters. Missing aspects which have to be additionally modeled for realizing assistive services are support processes including user interaction. (3) The support is provided at the time the person needs it, e.g., when a human user has to operate with the CPPS, or when the person requests it, e.g., via interaction components of the digital twin. To realize such assistive services within the system architecture of DTs requires additional interaction components for user communication and assistive visualization and the internal handling of process models during runtime. Process models can be defined manually or one can use methods for the semantic annotation of user manuals [58] of production machines to automate the setup of assistive information.

To incorporate assistive services within digital twins support two different aspects of sustainability: Within the production process, assistive services can be used to provide users step-by-step support to improve key sustainability indicators. If products are delivered to customers together with a digital twin of the product, assistive services can be used to support customers with improving key sustainability indicators related to the use of the product.

5.7 Calibration and Adjustment of Simulation Models of Digital Twins

The simulation models used in virtual commissioning are suitable as a basis for digital twins of production systems, as they represent the behavior of these systems and are often already available from the development phase. These “as-designed” simulation models represent the respective production system in a generalized way [59, 60]. However, a digital twin requires simulation models that represent the real system; an “as-operated” model. If the “as-designed” models are used without any adaptations to the real system, there would be considerable discrepancies between the behavior of the general simulation models and that of the concrete production system. For this reason, they cannot be used directly within the digital twin. Therefore, efforts are being made to synchronize the behavior of the simulation model and the real production system so that the model can become part of a real “twin” of the concrete production system instance.

So far, simulation models for virtual commissioning are only used in the development phase of production systems to test the control code [61]. With regard to the digital twin, there are some publications in which discrepancies between the simulation model and the real system are investigated and compensated for specific aspects of the digital twin [62,63,64,65]. For this, the simulation models must be adapted to the reality of the concrete CPPS instances, whose behavior increasingly diverges from the idealized assumptions of these simulation models due to tolerances in the structure, environmental influences or wear—“as-operated”. However, the issue of how to convert the “as-designed” models into “as-operated” models is not addressed. The initial “as-designed” simulation models, thus, increasingly deviate from the reality of the actual system behavior, whereby they lose their predictive capabilities and analyses of this leading to erroneous conclusions. During commissioning, the general simulation models of the system must therefore be transformed into instance models of a concrete, physically constructed system in order to continue enabling useful analyses. Currently, however, changes through adaptation or wear and tear to the (often long-lived) CPPS are not represented in the digital twins or in updates to their simulation models, so that control and simulation of the CPPS assumes outdated assumptions encoded in the models and information relevant to the development of future versions of the represented CPPS is lost [66]. This is essentially a modeling challenge [66, 67].

To solve this modeling challenge, a sustainable methodology needs to be developed to (partially) automatically transform the general simulation models of CPPS into precise instance models during commissioning. For this purpose, it is investigated how different modeling concepts, methods, and tools of model-driven software development, such as software language engineering [56, 68, 69], model transformations [70] and self-adaptive digital twins [9, 8, 44], can be suitably adapted and combined in a domain-specific way.

6 Related Work

In the development process of production plants, it has become common for domain experts to design digital twins as simulation models with the purpose to develop and test the control code of the plant at an early stage. The real control hardware and communication medium (field bus system) are used for this as a hardware-in-the-loop simulation. It is advantageous if the simulation models are calculated in the real-time cycle of the communication periphery in order to be able to carry out the most meaningful tests possible. This process is commonly referred to as virtual commissioning. In most cases, it is sufficient to model simple kinematics and material flow to positively influence control code development. However, this does not apply to the use of simulation models in an operational simulation. In some cases, highly accurate simulation models are required that cannot be calculated in real time. Co-simulation has established itself for these cases [71]. There are also other potentials of these simulation models that go beyond pure virtual commissioning, such as control optimization by means of macroscopic material flow models [72] or the support of control development by means of AI [73,74,75]. These aspects make these simulation models interesting as a possible component of digital twins.

Recently, various digital twin platforms have emerged [76]. They aim at supporting developers in creating digital twins and digital shadows and provide tooling support for different aspects of a DT. Numerous DT platforms already exist from various vendors, e.g., by IBM,Footnote 4 Oracle,Footnote 5 Siemens,Footnote 6 Amazon Web ServicesFootnote 7 [77], Microsoft AzureFootnote 8 [78], and Eclipse.Footnote 9 We already compared the latter three platforms in terms of functionality [79]. All three of the investigated DT platforms provide comprehensive infrastructure for defining data structures for the data exchanged between physical and digital twins. For this purpose, they even provide modeling languages. However, models of these languages are not interoperable and restricted to their platform. Also, they miss standardized interfaces to enable composition of digital twins, or command models that enable interaction with other value-adding services, such as simulations or prediction. Because the platforms only provide modeling techniques for structural modeling, compared to our solution behavior, i.e., the communication, evaluation, and reasoning, of the DT cannot be defined in a model-based way and requires hand-written code to be deployed to the used cloud platform. This requires skilled software engineers, whereas our approach does not require programming skills from domain experts. Microsoft’s and Amazon’s DT platforms are part of their cloud ecosystems providing the advantage that their DTs can use machine learning capabilities, data processing algorithms, and CI/CD functionalities provided by their ecosystem. However, our approach to digital twins can be easily deployed to these platforms, enabling users to experience the advantages of these platforms. Our approach could be extended with interfaces to integrate features of the platforms.

7 Conclusion

In this chapter, we have presented a collection of methods for the sustainable model-driven development of digital twins. These methods are based on our understanding of digital twins as software systems that comprise data, models, and services enabling interaction with a CPPS for specific purposes. Leveraging models as primary development artifacts supports (a) the sustainable engineering of digital twins as well as (b) the engineering of sustainable digital twins, i.e., to leverage monitoring, controlling, and optimizing the behavior of CPPSs through their digital twins. The methods can be applied to digital twins in a variety of application domains and shall guide researchers and practitioners in the conception, engineering, and operations of digital twins.