Sie können Operatoren mit Ihrer Suchanfrage kombinieren, um diese noch präziser einzugrenzen. Klicken Sie auf den Suchoperator, um eine Erklärung seiner Funktionsweise anzuzeigen.
Findet Dokumente, in denen beide Begriffe in beliebiger Reihenfolge innerhalb von maximal n Worten zueinander stehen. Empfehlung: Wählen Sie zwischen 15 und 30 als maximale Wortanzahl (z.B. NEAR(hybrid, antrieb, 20)).
Findet Dokumente, in denen der Begriff in Wortvarianten vorkommt, wobei diese VOR, HINTER oder VOR und HINTER dem Suchbegriff anschließen können (z.B., leichtbau*, *leichtbau, *leichtbau*).
Der Artikel diskutiert die Einführung digitaler Zwillinge (DTs) in die Systemtechnik und führt in die DarTwin-Notation ein, um über die Evolution von Zwillingssystemen, ihre Zwecke und Eigenschaften nachzudenken. Es konzentriert sich auf die drei wichtigsten Arten von Modifikationen in DTs: Änderungen des tatsächlichen Zwillings (AT), Verbesserungen in der Präzision und Änderungen im Zweck und in den Zielen. Der Autor schlägt einen systematischen Ansatz vor, um die schrittweise Entwicklung von DTs unter Verwendung modularer und skalierbarer Architekturen zu unterstützen. Der Artikel veranschaulicht diesen Ansatz anhand einer Fallstudie zu Smart-Home-Heizsystemen und bewertet ihn mit einem Portalkran im Labormaßstab DT. Die Beiträge umfassen die Entwicklung der DarTwin-Notation und die Identifizierung architektonischer Transformationen durch Fallstudien. Der Artikel diskutiert auch die Beschränkungen der Studie und verwandter Arbeiten in der Softwareentwicklung und der DT-Zusammensetzung.
KI-Generiert
Diese Zusammenfassung des Fachinhalts wurde mit Hilfe von KI generiert.
Abstract
Despite best efforts, various challenges remain in the creation and maintenance processes of digital twins (DTs). One of those primary challenges is the constant, continuous and omnipresent evolution of systems, their user’s needs and their environment, demanding the adaptation of the developed DT systems. DTs are developed for a specific purpose, which generally entails the monitoring, analysis, simulation or optimisation of a specific aspect of an actual system, referred to as the actual twin (AT). As such, when the twin system changes, that is either the AT itself changes, or the scope/purpose of a DT is modified, the DTs usually evolve in close synchronicity with the AT. As DTs are software systems, the best practices or methodologies for software evolution can be leveraged. This paper tackles the challenge of maintaining a (set of) DT(s) throughout the evolution of the user’s requirements and priorities and tries to understand how this evolution takes place. In doing so, we provide two contributions: (i) we develop DarTwin , a visual notation form that enables reasoning on a twin system, its purposes, properties and implementation, and (ii) we introduce a set of architectural transformations that describe the evolution of DT systems. The development of these transformations is driven and illustrated by the evolution and transformations of a family home’s DT, whose purpose is expanded, changed and re-prioritised throughout its ongoing lifecycle. Additionally, we evaluate the transformations on a laboratory-scale gantry crane’s DT.
Communicated by T. Clark, S. Zschaler, V. Kulkarni, and D. E. Khelladi.
Publisher's Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
1 Introduction
The last two decades saw the adoption of digital twins (DTs) in systems engineering in a wide range of application domains [12, 13, 21, 36].
Many definitions of DT can be found in the literature [5, 12, 21]. In essence, a DT is a digital representation of an actual system, referred to as the actual twin (AT)1, that is dynamically updated with AT data2 [15, 41] and that can interact with and influence the AT. A DT is developed for a well-defined purpose, e.g. improve the energy efficiency of a building, and aims at achieving a set of goals related to its purpose. From an execution perspective, a DT uses different types of models [7] to extract information and compute metrics from the collected data (current and historical) to provide a set of services [7, 36] related to its purpose and goals. Examples of DT services include the monitoring of specific properties, detection of system issues, data analytics to identify correlations between different system properties, simulation, and analysis of what-if scenarios.
Anzeige
Like any software artefact, DTs are dynamic entities that evolve during their lifecycle to satisfy constantly evolving needs and requirements. The evolution of a DT can be associated with three main types of modifications:
(i)
Modifications made to the AT or its environment that need to be reflected in the DT. For example, a DT may need to be modified after a new sensor has been added to the AT or a new external source of data has become available. A DT may also need to be modified to reflect a structural modification made to the AT.
(ii)
Modifications made to the DT to improve its precision with respect to one of its existing goals. For example, a DT can be modified to take advantage of a new source of data (as a result of (i)) or the introduction of a new type of model that can be used to improve its current thermal comfort.
(iii)
Modifications made to the purpose and/or goals of the DT. For example, the scope of a DT that was initially developed to improve thermal comfort in a building can be modified to include a new purpose or goal like the reduction of energy consumption and the improvement of air quality. This type of modification results in the creation of new DT services.
This last type of change (iii) is related to the fact that ATs are in general complex entities that have several aspects and that any DT only addresses a specific subset of these aspects. While essentially all definitions of DT refer to a digital representation/replica of an AT, it would be more accurate to say that a DT is a digital representation/replica of an AT that only includes a subset of its aspects, for example, in the context of a smart building a DT can be developed to improve thermal comfort while another DTs can be developed to reduce energy consumption. In this article, we follow the view that a system can include several/many DTs that each have a different purpose associated with specific aspects. We point out that our research is nonetheless compatible with alternative definitions, e.g. where only one DT exists, but it is decomposed into a set of components. In this context, during its lifecycle, the scope and purpose of a DT may need to be progressively increased to include an increasing set of aspects of the AT [1, 19].
Typically, when the evolution of a DT is considered in the existing literature, it is concerned with the mirroring of the evolution of the AT or its data [4, 23], i.e. case (i). However, doing so loses sight of the evolution of the purpose and scope of a DT as it is given new, altered or improved purposes and goals, i.e. case (iii). For this case, we believe that DTs must be architected and incrementally developed using a modular and scalable approach, just as it is done for systems that evolve over time. Hence, except for trivial cases, DTs should be designed as encapsulated entities that can be composed, transformed, exchanged, and adapted to enable the incremental development of advanced functionality and sophisticated services.
While we appreciate the evolution of DTs with respect to the three types of modifications, this paper focuses on the evolution of DTs related to the modification made to their purpose and goals, i.e. (iii). To support this type of evolution, we propose a systematic approach that is based on transforming the system architecture and synthesising a set of transformation templates. The approach aims at supporting the incremental development of a DT (that addresses multiple aspects of a system) by composing DTs that have been independently developed to address different purposes. Since the resulting set of DTs is related to the same system, their integration needs to be carefully and systematically architected to avoid conflict and ensure optimal solutions.
Anzeige
As the goal of our study is to explore the evolution(s) of DTs, case study research constitutes an appropriate research method to answer the proposed research questions [40]. In this paper, we illustrate our approach using a smart home’s heating system over the course of several requirements changes (e.g. switch from thermal comfort prioritisation to considering energy consumption), and evaluate it with the help of a laboratory-scale gantry crane’s DT.
Specifically, our contributions are twofold:
1.
Firstly, we develop the DarTwin notation that enables reasoning on a twin system, its purposes, properties and implementation.
2.
Secondly, we introduce a set of architectural transformations that we identified through analysis of our case study system
The remainder of this paper is structured as follows: in Sect. 2 we discuss our underlying understanding of DTs and introduce our views on the compositionality of DTs. Next, in Sect. 3 we describe our notation for reasoning on the system’s evolution, and the application on a smart home system through which we found the architectural transformations. Afterwards, in Sect. 4, we check if the architectural transformations are also suited for other systems, by applying them to a case study of a laboratory-scale gantry crane. Then, Sect. 5 positions our research and discusses some limitations. Following that, we discuss related work in Sect. 6 and ongoing and future work in Sect. 7, before concluding in Sect. 8.
2 Modular aspects of DTs
We have observed that most discussions seem to treat DTs as relatively static artefacts. Despite continuous (self-) adaptation using the AT’s data [23], once created, the DT’s architecture typically remains conceptually unchanged. As ATs are usually part of a larger, continuously evolving system, it is evident that the corresponding DTs should evolve too, e.g. when new system parts are added, removed or restructured. Besides, continuous development and the addition of new features also requires the evolution of DTs themselves. Finally, we also note that the execution environment itself may change. We would call this process of managing the DT evolution the DT lifecycle management. Following this philosophy, we treat evolution as a continuous norm, where changes to any of the above aspects are omnipresent, occur on various granularity aspects and demand frequent adaptations. Hence, our goal should be to enhance current DT practices and integrate a modern mindset that allows quick reaction and adjustment to such an evolution.
2.1 DT development and evolution
We may think of DT evolution in two ways. The first way deals with the evolution of an individual DT, e.g. based on updated data from the AT (e.g. Lehner et al. [23]), and the second way views the twin system more globally, in which we discuss the creation and interaction of DTs and ATs, or the interaction between DTs (see Sect. 3).
Although this article focuses on the second way, we nonetheless briefly outline our understanding of an AT-DT system (a.k.a. twin system) and its typical creation/design flow.
Figure 1 illustrates a typical twin system consisting of an AT and a DT, which interact in synergy, such that the DT is updated with new data produced by the AT
. The feedback/control flow
on the other hand is used to update the AT, based on the implemented DT services and the newly gained knowledge.
Next to the autonomous operation, twin systems typically enable user interaction
. Note that the figure indicates an interaction with the twin system as a unit, but in practice users may modify all parts of the system (e.g. directly configure the DT or alter the AT’s settings).
The DT services may be clustered in a single DT, or spread out over multiple DTs. Each DT only works with the subset of data and control flows it needs to provide its services
; they may also rely on the services of another DT to provide their own services
.
Finally, we point out the hierarchical view that allows a twin system to be the AT within another twin system. In the above figure, Twin System 2 (dashed) contains DT2 which serves as a DT for Twin System 1, rather than the (inner) AT or DT.
shows the communication from DT2 and Twin System 1 as an AT. This conceptual distinction is important for avoiding conflicts of different DT’s purposes, as we will see further on in Sect. 3.
2.2 Introduction to the notation
In order to better reason about the evolution of twin systems, including the above-mentioned purposes and properties of interest (PoIs), we developed a notation called DarTwin, and the evolutionary scenarios are shown in framed diagrams with keyword dartwin. Our notation aims to relate the why, what and how of a certain evolution. Specifically:
Why? What are the goals of the twin system, and how are they evolving?
What? What properties of interest (PoIs) of the twin system are we working on?
How? What is the architecture of the twin system, and how does it relate to the goals and properties of interest?
Fig. 2
Legend containing the building blocks used in the DarTwin notation
The legend containing the elements of our notation is shown in Fig. 2. The two main elements are the trapezoidal-shaped goal and the roundtangle-shaped DT. The diagram is split in two sections by a horizontal line, as shown in the legend as well. Above that horizontal separator, the trapezoids will form the whole of the goals of the twin system, while below, the roundtangles will form a communication diagram of the twin system architecture.
The goal trapezoid contains three elements: a name/title describing the goal, the properties of interest (PoIs) related to that goal, and the constraints to which must be adhered to fulfil the goal.
The PoIs are characteristics of the AT or its environment that designers consider to evaluate whether a specific goal is reached or not. For example, in the context of building improvement, we could be interested in the room temperature, level of pollution in the air or the energy consumption. The PoIs allow us to abstract aspects of the AT and reason about them in the goals. The PoI is typically retrieved as payloads of the messages that pass through the ports of the DT roundtangles. This represents the four-variable model introduced by Parnas and Madey [32].
The constraints describe how the PoI must behave for the goal to be fulfilled.
During an evolution, goals appear in three different flavours:
(i)
Orthogonal, where the new goal has no connection to the current goals of the twin system;
(ii)
Extending, such that the new goal extends the current goal(s) of the system, depicted using the “generalisation relation” arrow;
(iii)
Positive relation or opposing/conflicting relation, the new goal positively affects or opposes/conflicts with one or more of the current goals of the system, shown using either a “goal relation” or “conflict arrow” between the goals.
This then leads us to the roundtangle-shaped DT. It contains a name of the DT it represents, as well as a set of communication ports. Arrows indicate the flow of data between the ports. All linked together, they form a communication diagram of the twin system architecture, similar to composite structures in UML [29]. Dashed relations connect DTs of the architecture with their corresponding goals of the conceptual upper part. These dashed arrows are the only element that crosses the horizontal separator.
2.3 Architectural transformations
We will use our running example in the next section to explain our approach and to depict the evolutions. We apply an orange colour (visually impaired-friendly) to depict the changes/additions. For each evolution, we try to summarise our motivation by an architectural transformation that generalises the evolution. The transformation applies the same notation as the example itself, in a simpler and more generic diagram.
In general, our approach is that of separation of concerns. The concerns are first defined by the goals, and then the implementation will typically see whether the new concern can be represented by a separate DT. Alternatively, we do changes to the architecture, and modifications of existing DTs.
3 Twin systems and their structured evolution
In the following sections, we introduce our running example and describe its evolution over the course of several purpose switches using the graphical notation.
3.1 Running example: a smart home system
Fig. 3
The case study system is a room in a Norwegian home, equipped with multisensor, Raspberry Pi controller and an oil-filled heater
We introduce our approach using a running example that is based on an actually existing, single-family home in Norway. Despite focusing on one individual room to explain our concepts and the evolution of the system, in fact, several rooms in the house are controlled by the developed solution. The house itself was originally built in 1965 and maintained with several independent climate-controlling systems such as an invertible heat pump and mechanical ventilation. As these installations were made over the course of several decades, unfortunately, these systems are independent, that is, without a common control. The focus of our running example is on one room, that is equipped with one electric oil-filled heater (see Fig. 3). A multisensor capable of sensing temperature, luminance, humidity and motion is installed to provide sensory input to a Raspberry Pi that serves as an independent control unit of the room by actuating a power switch of the heater.
3.1.1 The basic system: thermal comfort
Due to traditionally low energy prices in Norway, the original and main purpose of controlling the thermal comfort was (and mostly remains) to keep the room temperature pleasant for occupants. Furthermore, given the climatic circumstances (long and fairly cold winters) the main functionality requires controlling the room heating (without active cooling). Thus, the first logic for controlling the room was a simple thermostat where we defined the comfort temperature and the allowed deviation from that comfort temperature.
Figure 4a shows the Thermal Comfort DarTwin with the Warm Comfort purpose with the temperature PoI, above the horizontal separation bar. Here the goal is to provide Warm Comfort for occupants and the way we operationalise it is to control the Room Temperature as indicated in the goal with a simple constraint giving a range for the room temperature.
When it comes to the actual implementation, we may view the room altogether as a system with temperature control. However, another view can designate the Raspberry Pi program with inputs from the multisensor and outputs to the Heater’s switch actuator, as a virtual representation (or a DT) of the physical room with its heater. We therefore denote the whole room, including the controller, as Thermostat twin system, consisting of one physical system (the Room AT) and one virtual system (the Thermostat Logic DT).
The implementation of this initial room is depicted in Fig. 4a, which shows the AT being the Room AT with Temperature Sensor for observing temperature and an oil-filled electric Heater to be controlled by the Thermostat Logic DT’s simple on or off actions. A user can set the desired comfort temperature through the User Comfort Temperature input. The dashed arrow crossing the bar shows the dependency between the goal specification and its DT implementation. We depicted the Room AT as a rectangle, but realise that it is normally not necessary to indicate the AT with more than its communication ports. Indeed, the AT can be collapsed as shown in Fig. 4b. In Fig. 4a we have the Room Temperature sensor and the Heater actuator, and we decide to place those ports on the bottom edge of the Thermal Comfort twin system. In the remainder of the paper, we default to the collapsed view unless otherwise stated.
3.1.2 The initial transformation template
The most basic template is given in Fig. 5. It merely shows a typical starting design with one specific goal implemented through one DT. Typically, there is communication with the AT through ports representing sensors and actuators. The sensor ports carry monitoring data while the actuator ports carry control data. Most systems will have input from the users and may be also output to the user (not shown here).
After the initial configuration of the heating’s digital operation, over the years the system underwent several significant modifications. Step by step, new system purposes were introduced, thereby requiring iterative adaptation and extension of the existing DT and system.
3.2.1 Evolution 1a: green comfort with hierarchical transformation
Despite the comparatively low-cost energy, even in Norway, a wave of energy-awareness led to the ambition to decrease the energy use in homes to contribute in general to a better environment. Thus, a new goal was introduced into the system, namely that the room should be more energy-efficient. By considering the existing Thermostat twin system as the AT, the aim was to manipulate the parameters of the thermostat to lower energy consumption without sacrificing the occupants’ thermal comfort. Hence, it was decided to lower the comfort temperature when the room was not used (i.e. nobody is in the room), or when the room was used for sleeping.
We have depicted our desire and energy-saving reasoning, which we call the Green Comfort evolution, in Fig. 6 by showing the incremental changes in orange colour. We specialise the Lower Energy goal into two separate disjunct cases, namely when people are absent (or sleeping at night) and when they are present. When people are absent, we may lower the energy usage without affecting the thermal comfort. When there are people present, we keep the previous notion of thermal comfort.
Fig. 6
Green Comfort DarTwin introduces the additional goal Lower Energy which is satisfied by the Energy Saving DT
Therefore, we designed a controlling process that adjusted the user’s comfort temperature based on predictions of the room’s use. A luminosity sensor (from the multisensor) is used to indicate occupancy. When the room is lit, we assume there are people present or intend to become present and therefore the thermal comfort level should be normal. On the other hand, when there is no light, the thermostat’s temperature is lowered. Furthermore, a distinction between day and night keeps the temperature slightly higher during the day, so the time to heat to the user’s comfort temperature is shortened once the light is turned on.
We now have two different perspectives on the Green Comfort evolution. Either we see the Thermostat twin system as a finished system that we will see as the AT, or we see the original Thermostat twin system as a system that we augment by one more DT. We show both alternatives of this new Energy Saving Thermostat twin system.
There may be reasons to consider the simple thermostat system as a fixed system. It may have been deployed in a way that we have only very limited ways to manipulate it. We assume our only communication with the original Thermostat is through giving the user comfort temperature. Thus, our process serves as a DT relative to our Thermostat twin system, effectively establishing a hierarchical, nested twin system as depicted in Fig. 6. We introduce a presence sensor, which abstracts over the combination of luminance and time of day. We see that the new Energy Saving DT is connected to the existing Thermostat twin system. This addition corresponds to what we call a hierarchical transformation pattern, as shown generalised in Fig. 7.
The hierarchical pattern represents an evolution where the original twin system is treated as a black box. Treating a twin system as a black box means that, from the new twin system’s vantage point, we consider it as the AT. This means that the user inputs and outputs of the original twin system now become the controlling and monitoring data of the new twin system.
Since there are no modifications to the original Thermostat twin system in this evolution, we do not need to show it in full detail. We can just represent it by one port for User Comfort Temperature as depicted in Fig. 8. This may help focus on the elements we now design and evolve.
Fig. 7
Hierarchical transformation describing a nested twin system
3.2.2 Evolution 1b: green comfort with augmented transformation
The hierarchical Energy Saving Thermostat nested twin system, could have been deployed with the two DTs on different physical hardware, and in principle, the Thermostat twin system could have been available to the programmer of the Energy Saving DT only through a limited interface. In our real twin system, however, the border of the inner Thermostat twin system is defined by software running on the Raspberry Pi. Therefore, for a systems engineer it is natural to consider whether the new DT should just augment the twin system as a parallel DT, as depicted in Fig. 9.
The connection between the Energy Saving and the Thermostat Logic DTs is now internal to the Energy Saving Thermostat twin system and can be adjusted at will without affecting the interface to the Room AT. We have called this transformation Augmented as depicted in Fig. 10. The augmented transformation may rely on plain communication between the constituent DTs. This means that the inputs and outputs of the constituents may interconnect, while the monitoring and controlling data of the DTs will be kept separate for each DT.
The Flat Green Comfort evolution applying the augmented transformation shown in Fig. 9 corresponds with our real chosen implementation and we shall continue from that variant in the next evolution.
Fig. 9
Flat Green Comfort DarTwin applying the augmented transformation
3.2.3 Evolution 2a: freeze protection with orthogonal transformation
Nowadays, winters are often warmer than before, but Norway is still cold sometimes. A risk analysis of our programmed temperature control system revealed the need to cope with extreme cases. Every year water pipes in Norway freeze and subsequently break with very unpleasant consequences for the owners. In particular this often happens in remote or vacation cabins where the people are not always present to realise the catastrophe. This is why we decided to introduce an independent Freeze Protection DT process. Often also called “watchdogs”, such independently functioning monitoring processes should be as independent of the core system as possible.
Initially, we deployed the Freeze Protection DT as an orthogonal DT within the twin system, but still deployed on the same Raspberry Pi and applying the same sensors and actuator. This is depicted in Fig. 11.
Watchdogs are commonly used in many cyber-physical systems (CPSs) such as elevators, assembly lines and trains. In critical systems, there may even be several watchdogs serving the same purpose. The orthogonal transformation summarises such a setup in Fig. 12. The essence of a watchdog is that it is orthogonal and independent of the main functionality, taking care of the exceptional cases with unfortunate consequences.
However, with this orthogonal architecture, we realise that both the Thermostat Logic DT and the Freeze Protection DT may try and instruct the heat actuator at the same time, and thus, in principle, they may be in conflict. One could imagine a hacker being able to set the comfort temperature to minus 5 degrees Celsius which would obviously counter the purpose of the Freeze Protection DT. Safety precautions are important, but it is necessary to consider the situations where there are competing actuations. Obviously, one could prevent such conflicts by limiting the legal domain of comfort temperatures to what is above the No Freezing goal boundaries, but that would make the existing DT behaviour dependent upon the introduced watchdog. We present two alternative architectures for avoiding the potential actuation conflict.
3.2.4 Evolution 2b: freeze protection with new output transformation
The problem with the purely orthogonal architecture is that the single heater may be independently instructed and these instructions may be conflicting. One solution would be to have two heaters, one instructed by the Thermostat Logic DT and one controlled by the Freeze Protection DT. The freeze protect heater (Heater 2 in Fig. 13) must be strong enough to make the room not freeze, but it does not necessarily need to be strong enough to maintain the comfort temperature. This is a good solution (Fig. 13) that copes with situations where the original heater is not functioning, or the thermostat logic is erroneous.
In general, the transformation template given in Fig. 14 shows how the watchdog could be defined by making the control data separate to two distinct actuators, while receiving monitoring data in both DTs is normally not provoking a conflict.
3.2.5 Evolution 2c: freeze protection with chained transformation
Our real system has only one heater, and therefore we look for an alternative solution. We would rather let the architecture reflect the desired priority, namely that the watchdog should have priority since it will be guarding the situation with the most serious consequences. We can achieve that by modifying the DT architecture to obtain a pipelined structure. We would like to transform the architecture such that one DT (Freeze Protection) is given priority over another DT (Thermostat Logic) relative to the actuator (Heater). This is depicted in Fig. 15 where we see that actuation from the Thermostat Logic will pass through Freeze Protection and one may say that Freeze Protection assesses and filters the control data from the Thermostat Logic against the freeze conditions (temperature \(t > 8\,^{\circ }\)C).
Fig. 13
Additional Heater Freeze Protection DarTwin removes the actuator conflict by introducing an additional heater output
Our aim was to achieve priority of the watchdog, and this was provided by piping the actuation. We refer to this transformation pattern as “chaining” and in this case priority is achieved by “post-chaining” the DT. We may say that the Energy Saving DT is “pre-chaining” the Thermostat Logic for its purpose of creating the two sub-cases of Warm Comfort. The Chaining transformation is indicated in Fig. 16.
The chained DT architecture avoids actuation conflict by applying priorities, but fails to prevent consequences of a failing heater. This watchdog merely covers thermostat logic errors.
Our real implemented system also has one more watchdog that monitors the opposite situation: when the heater is on for so long that it may cause fire. We have pipelined the Fire Protection watchdog following Freeze Protection giving fire a higher priority than freezing since a fire has even more consequences than frozen pipes. Note that, since there are no new considerations regarding the pipelined Fire Protection watchdog, we omitted its description in this paper. The principle behind Fire Protection is to make sure that the heater cools off after a given maximum operating period. This duration is of course a parameter.
3.2.6 Evolution 3: saving money with arbitration transformation
In 2022 the electricity prices in Norway changed drastically. The price of electrical energy soared to 200–500% and became unpredictably volatile. The reasons were the combinations of a steep increase in foreign demand due to the Ukrainian war, and some new large cables to bring the energy to Europe. Suddenly, the price of energy in Norway was dependent on the energy prices in Germany. Thus, next to energy saving, which also impacts the amount of money, the hourly price variations became an even more important factor than the amount of energy used.
With this background, we first redesigned our DT on energy. We replaced the Energy Saving DT that was based on lower temperature when absent, with a process that focused on energy cost. The applied approach was simplistic: We assume that the inhabitants would accept lower temperatures when the energy prices were high. Therefore, we devised a function (implemented by a lookup table) that reads the hourly varying price as input and provided a delta temperature value of how much the inhabitant was willing to lower the comfort temperature (and instead rather put on a jumper or a woollen blanket). Thus, the replaced DT on energy cost saving had fundamentally the same interface towards the thermostat, namely to change the comfort temperature setting and there would be no further architectural changes.
However, the original idea of changing the comfort temperature when there is nobody present, still seems a good idea even when we have introduced the new cost-centric approach. Could we apply both strategies together? If so, how should they be combined? We have now two DTs concerned with energy that both try to manipulate the comfort temperature. Therefore, there is a potential conflict between the goals to save money and to lower energy. This is indicated by a double arrow as seen in Fig. 17. We have defined a conflict arrow between Warm Comfort and Saving Money as well since our approach is to sacrifice some comfort for money.
What we have now are two DTs that each suggests a new comfort temperature. What is needed is some explicit arbitration facility for the combination of the two suggestions from the DTs involved with energy. One arbitration rule could be to choose the lowest of the two suggestions at all times. This arbitration architecture is depicted in Fig. 17. It shows that our additional goal now is to save money, and our operationalisation is to take advantage of knowing the hourly changing energy prices. In our implementation, the hourly cost is given as a table which gets its values from a public website depicted in our illustration as a port connected to an external API giving input to the Cost Saving DT.
The arbiter architecture as depicted in Fig. 18 is well-known from, for example, safety-critical systems such as train monitoring systems where there are two totally independent watchdogs with the same requirement, but with fundamentally different implementations with disjunct development teams, disjunct hardware and disjunct software. The arbiter’s role is to initiate an emergency exception if the two watchdogs do not agree. In our situation, the arbiter’s role is also to harmonise and combine the results from the two energy DTs. Our first implementation of this harmonisation is very simple, but it represents the process of compromise, and it may be enhanced to any kind of complexity.
Fig. 17
Compromise Saving DarTwin introduces the Saving Money goal, which is fulfilled by the Cost Saving DT in combination with the Arbiter
So far, we explained the transformations with the help of the smart home system. Now, we want to evaluate whether or not the transformations are also applicable to systems in other domains. To this end, we apply them (retroactively) to another twin system at the University of Antwerp’s Cosys-Lab: a laboratory-scale Gantry Crane twin system, shown in Fig. 19. The goal of a real gantry crane is to move containers from/onto ships that are docked in the harbour. To achieve a high throughput, the swinging motion at the end of a container movement should be minimised and preferably even zero. This way, the container can be lowered onto the quay or ship immediately and safely. Our laboratory-scale crane is a scaled down (approximately 1:10) version of such a real gantry crane, moving a container of 5 cm \(\times \) 2 cm \(\times \) 2 cm (about 1:10 of a 20’ standard container) over a height and width of about 50 \(\times \) 70 cm. Suffice to say, our laboratory-scale crane does not move the containers onto real ships, but it does move a container payload from one position to another, mimicking such a real crane. We discuss four stages in the development of the crane twin system, each one incrementally adds to the previous stage:
The initial Gantry Crane twin system (Sect. 4.1): the container is moved over an optimally calculated trajectory. This stage shows the use of the Basic DarTwin from Fig. 5.
Evolution 1 - Dynamic Positioning Constraints (Sect. 4.2): we add dynamic positioning constraints to the Gantry Crane twin system. These constraints form dynamic keep-out zones that influence the calculated trajectory. This stage shows the Augmented transformation with multiple DTs from Fig. 10.
Evolution 2 - Continuous Validation (Sect. 4.3): after each executed trajectory, a validation is performed, checking that the trajectory was executed flawlessly (or not). This stage shows a slightly modified New Output transformation from Fig. 14.
Evolution 3 - Container Constraints (Sect. 4.4): dynamic kinetic constraints based on the container’s contents are added to influence the calculated trajectory. This stage shows an alternative way to add dynamic constraints based on the Arbiter transformation from Fig. 18.
Figure 20 shows the initial Optimal Control twin system. It showcases the Basic DarTwin from Fig. 5. The goal of the crane is to achieve a high throughput of containers. This is achieved by following an optimal trajectory, generated by a trajectory generation service provided by the Trajectory DT. Every time the crane should move from one point to another, one such trajectory must be calculated. The Trajectory DT contains an optimal constraint problem solver, which tries to find an optimal trajectory that the crane can execute to move the container. The goals of this DT are threefold: (i) there should be no swinging motion at the end of the trajectory, (ii) the duration of the trajectory should be as short as possible, and (iii) none of the system constraints may be violated. For the goal that minimises the trajectory duration, the PoI is the time duration in seconds of the trajectory. This duration should be minimised. For the goal of having no swinging motion, the PoI are swinging angle and angular velocity in rad and rad/s, both should be equal to zero at the end of the trajectory (the latter is not shown in the figure for conciseness). Lastly, for the adherence to the system constraints goal, we have both a set of geometric constraints and kinetic constraints to which the Trajectory DT should adhere. For the geometric constraints, the PoI are the minimum and maximum positions of the cart and the container. For the kinetics, the PoI are the maximum accelerations and velocities of the cart and container. These properties stem from the geometry of the crane, as well as the properties of the motors driving the crane, and should be strictly adhered to. To generate the trajectory, the Trajectory DT uses the current motor position and swing angle as initial conditions/inputs, and yields an optimal trajectory that can be executed by the motor controllers as output. Once generated, the motor controllers accept this trajectory and enact it in real life. Implementation-wise, this means the motor controllers set the end position of the trajectory as target; then, as the cart is moving along the trajectory, they update the cart’s velocity over time, as specified by the samples in the trajectory.
Fig. 20
Optimal Control DarTwin showing the initial Gantry Crane twin system
A harbour terminal is a dynamic environment, with straddle carriers moving containers in and out, deckhands securing containers on the ship and so on. In an attempt to increase the safety of the Gantry Crane twin system, we are looking to add dynamic keep-out zones, zones in which the container should not pass in its trajectory for safety reasons. The new goal is thus to respect the dynamic position constraints of those keep-out zones. Because these keep-out zones change over time, before a trajectory is calculated, the latest zones must be taken into account. The PoI is the container’s position trace, which at no point should violate the keep-out zones. Implementation-wise, these position constraints are additional geometric constraints that the Trajectory DT must adhere to. We show this by drawing a relation between the Respect Dynamic Position Constraints and Respect System Constraints goals. Implementation-wise, the Trajectory DT must adhere to the union of these goals. To achieve this goal, we must undertake two steps. Firstly, the Trajectory DT must be mutated, such that it gains an input port on which it can accept these dynamic position constrains, and it must apply the union of all geometric constraints when solving for the optimal trajectory. Secondly, we need an Objects in Area DT, a DT which captures the position of objects in real time, and extracts the position constraints from that information. It should do so based on information coming from cameras spread around the gantry crane. This is visually shown in Fig. 21. Machine learning techniques with image segmentation can be applied in the implementation to extract the keep-out zones. To add this new DT to the system, we apply the Augmented twin transformation with multiple DTs as previously shown in Fig. 10. The new DT is coupled in front of the existing DT, as was done previously in Sect. 3.2.2.
4.3 Evolution 2: Continuous Validation
The second evolution is the addition of a continuous validation scheme. Here, we wish to continuously validate that the digital model of the gantry crane is still a good model of the physical gantry crane. This is important since the model is used in the Trajectory DT to generate optimal trajectories, and set the system constraints. When this model starts deviating from the crane’s actual behaviour, the generated trajectories are no longer optimal. The goal, thus, is to validate the crane model after each completed trajectory enactment. We do so by comparing every executed trajectory of the gantry crane with simulations that execute the same trajectory. This comparison produces validation metrics that should remain below a warning/failure thresholds. The properties of interest are thus the validation metrics, generated by the trace comparison, the goal is that they conform to their thresholds. When they do not, an operator needs to be informed to take appropriate action before performing new movements of the crane. From this description, it becomes clear that this is a type of watchdog, as was previously discussed. We see that there is no actuation conflict, since the output of the validation is merely used to inform an operator. We are therefore dealing with a New Output transformation, as shown previously in Fig. 14. The only difference is that the new output does not go to the AT, but rather to the operator. Implementation-wise, the Validation DT takes as inputs the measured motor state and swing state, as well as the trajectory being currently executed, and compares those measurements with simulations using the model of the gantry crane. When thresholds are breached, the Validation DT informs the operator of this fact, allowing them to take appropriate action. This is shown in Fig. 22.
Fig. 22
DarTwin Continuous Validation adds the Continuous Validation goal, which is fulfilled by the Validation DT
This last evolution is that of handling dynamic container constraints. Perhaps not every container can be moved at the same speed and with the same acceleration due to the contents of that container. The new goal is thus to have dynamic kinetics constraints dependent on the container that’s being moved. The PoI are the kinetics constraints of the container, the goal is to adhere to these constraints. Similarly to Sect. 4.2, there is a link to the goal of the Trajectory DT that needs to ensure all system constraints are met. In contrast to the geometric constraints, which become the union of both, the kinetic constraints the Trajectory DT must apply is the strictest combination of both the container and the system constraints. At first glance, we could apply the Augmented transformation again, as we did previously in Sect. 4.2. However, we can also apply an Arbiter such as in Fig. 18. Indeed, instead of having the Trajectory DT deciding on which constraints to apply, an Arbiter can do it in its place. To apply the arbiter, the Trajectory DT must provide the Arbiter with its constraints, and a new Container Specification DT must provide the Arbiter with the container constraints. The Arbiter then provides the Trajectory DT with the applicable constraints. Therefore, to attain this new goal, we introduce a new Container Specification DT. It connects to a container camera to identify the container being moved, and looks in a container database to find the constraints of the container. It forwards the constraints to the Arbiter, which provides the Trajectory DT with the strictest set of constraints to apply. The Trajectory DT must be mutated such that it can provide the Arbiter with its own constraints, and such that it can accept the kinetic constraints. This is all shown in Fig. 23, where for presentation purposes we chose to take the Dynamic Positioning Constraints DarTwin as basis rather than the Continuous Validation DarTwin.
Fig. 23
DarTwin Container Constraints adds the Respect Container Kinetic Constraints goal, which is fulfilled by the Container Specification DT with the help of the Arbiter
It is worth noting which of the previously discussed elements are actually implemented. The Optimal Control twin system in combination with the Continuous Validation DT are actually up and running. The crane can perform these optimal moves, and each trajectory is compared to simulation to validate that the crane is operating normally. Providing the dynamic constraints to the Trajectory DT is also possible. What is not implemented are the Objects in Area DT and the Container Specification DT in combination with its Arbiter. For now, constraints imposed by those DT’s have to be defined manually. Implementing those two DT’s would not be unreasonably hard, the container specifications would simply have to be stored and retrieved in/from a database. Somewhat harder are the dynamic keep-out zone classification and segmentation of the Objects in Area DT, for which deep learning techniques are appropriate.
5 Discussion
In our study, we inferred the different architectural choices without analysing the trade-offs between alternatives. In some situations, several options were applicable. Our preferred choice intended to separate the concerns of the twins as much as possible, as suggested by [31]. Conversely, we could have always tried to evolve a single twin to encompass all the different concerns. Nonetheless, other competing choices might still have been available. To help break the tie in these situations, several antipatterns might be available to help make better decisions [25]. Another strategy could have been to calculate a set of architectural metrics to help make the decision [27]. Furthermore, developers under release pressure could also calculate technical debt metrics to help make decisions to allow for some technical debt in favour of release time [28].
The presented set of transformations was yielded by our running case study. Typically, every evolution was triggered by some emerging new purpose. Our focus on separation of concerns led to a strategy to investigate whether a simple architectural transformation would be sufficient such that the new goal could be satisfied with as little dependence between the old and the new DT’s. The hierarchical transformation considered the basic Thermostat as is, and just added a new DT that manipulated the input parameters of the existing DT. Then we showed that we could flatten a hierarchical twin system and return with a flattened twin system rather than a hierarchical twin system. Semantically, these architectures are equivalent, but one can easily imagine that extra-functional properties such as the physical possibility to control input parameters may have favoured one of those architectures.
The orthogonal transformation is even more focused on separation of concerns. However, this transformation comes with a requirement, namely that the orthogonal DTs must not send competing actuations. In our watchdog evolution, the Heater may get conflicting instructions, and we had to abolish the pure orthogonal architecture. Instead, we wanted an architecture which would imply prioritisation between DTs and thus between their associated goals. In our Freeze Protected Thermostat, we wanted that the Freeze Protection DT has the priority, and this was achieved by the chained transformation by post-chaining the Freeze Protection DT. The actuation of the Thermostat Logic DT is monitored and potentially modified by the Freeze Protection DT which then forwards the final actuation to the Heater. A post-chained DT would have priority, while a pre-chained DT would provide input parameters to the sequel DT.
The Arbitration transformation was introduced to respond to the fact that sometimes neither full orthogonality nor priorities are sufficient. There are conflicts between the DTs that must be harmonised. Logically this means that their corresponding goals must be harmonised and compromised. We have shown two evolutions that apply this transformation. Our example was the Compromise Saving DarTwin, combining both the general Lower Energy goal with the Saving Money goal.
In the Gantry Crane twin system case, we saw the recurrence of four of the different transformations, additionally it also showed how the goals can have relations that are dealt with in different ways. Furthermore, it showed that the notation also works for a system from a different domain and with a different implementation.
In this article, we refer to evolutionary transformations. However, for most software engineers, these transformations are generally referred to as patterns: a reusable solution, capturing best practices, to a commonly occurring problem within a given context. This collection would be referred to as a pattern catalogue, best known from the group-of-four [10]. We, on purpose, do not use the pattern terminology as the evolution of DTs is yet in its infancy and no clear best practices have emerged so far.
5.1 Limitations
Our study is based on a real-world use case that has been actively used in everyday life, thereby fulfilling “the two aspects most clearly distinguishing a case study from other types of research studies are ‘contemporary phenomenon’ and ‘real-life context’ ” [40]. Despite this, however, our work does not claim to be exhaustive or complete, but we instead describe a systematic and careful exploration that hopefully can prove fruitful for future research on DT evolution. Though an evaluation was performed on a gantry crane case study, a use case from another domain, no new transformations were discovered. Thus, some of our future work involves the discovery and application of evolutionary transformations in/for other case studies and in other domains.
Another dimension that requires further analysis is the extension of our work to (potentially orders of magnitude) larger systems. Remaining in the domain of smart buildings, we are planning to expand our private home study to, for example, office buildings. In this context, we note that our expectation is that the transformations remain similar; however, the types and rate of evolution are expectedly higher.
6 Related work
The objective of our research is to provide support for the systematic and iterative development and evolution of DTs. Our proposed approach focuses on the structural dimension of DTs and aims at building complex multi-aspects DTs by composing and evolving simpler ones. In this context, related work includes generic approaches to software evolution, approaches that look at the evolution of DTs and the composition of DTs.
Software Evolution
Evolution is a natural part of any system’s lifecycle. Lehman postulated eight laws of software systems evolution between 1969 and 1996 [22], with one stating that “An E-type program must be continually adapted, else it becomes progressively less satisfactory” [22]. This law applies not only to pure software systems but also to software-intensive and cyber-physical systems, for example, in automated production systems [39]. Standards also include the topic of evolution, e.g. the ISO25000 [16] standard on software quality defines four types of important maintenance: (i) corrective maintenance, focusing on resolving issues and errors in the system; (ii) adaptive maintenance to respond to changes in the environment or requirements of the system; (iii) perfective maintenance to improve the system (e.g. optimise, re-engineer); and (iv) preventive maintenance, focusing on preventing issues before they occur.
In this article, we mainly concern ourselves with adaptive and perfective maintenance.
Software evolution is an active research field with various research directions. One such direction is the visualisation of evolutions to understand the system, e.g. [33, 38]. However, these visualisations are used to understand the evolution of the software over time and how a change might impact the current twin system. Our approach uses a continuous model that is kept up-to-date and used during the evolution of the twin system.
Continuous design decision support also has this vision and is close to the work presented here. [14] presents a documentation model to capture architectural design knowledge during the design and evolution of software systems. This prevents this knowledge and its related assumptions from eroding over time. The model combines elements from both the requirements and architecture. Our notation is similar as it also captures aspects from both the requirements and the architecture side but also contains the properties of interest, which could be conflicting as there is a shared AT. However, our notation is not purely aimed at documentation; it is aimed towards active use during the evolution and also acts as a documentation of the system’s current state.
Design patterns are commonly advocated as a solution for the design and evolution of systems. Durdik created the AM3D (architectural modelling with design decision documentation) pattern catalogue that contains solution-specific questions that can be used to evaluate if a pattern is applicable in a particular case and for documentation [6]. The approach also has a workflow that can be adopted. Similarly, we use a pattern-based approach to guide the evolution of our system, where they are reusable solutions to common problems in the evolution of DT-based systems.
Digital Twin Evolution
Many systematic literature reviews (SLRs) have been published on different aspects of DTs over the last years [8, 18, 21, 26], but none of them identify papers that directly address the systematic and incremental evolution of DTs using a transformation approach.
Regarding DTs evolution, Michael Stych [1] highlights the successful development of DTs requires embracing a continuous improvement approach and adopting an iterative approach to identifying and exploring use cases. The development of a DT for a system of the dimension of a building is unlikely to succeed if it is addressed as a whole all at once. To succeed, the overall building DT needs to be incrementally and systematically developed, starting from smaller and simpler building components that are individually evolved and assembled. While the paper describes the overall approach, it does not discuss the technical aspects of the incremental development.
In the context of cyber-physical systems (CPSs) where a large amount of data is collected from various sources, [23] proposes the use of a dedicated framework to support the evolution of a DT in synchrony with the evolution of the system data and data sources it uses as changes are made on the physical system. The approach aims at reducing the manual effort that is required to synchronise a DT with the modifications made to a CPS systems (more precisely to the data and data sources that the DT is using), ensuring the compatibility of the data schema, and eliminating the unintended loss of data that may occur if synchronisation is not performed correctly. This approach focuses on the data aspect of DTs, while we focus on the broader perspective of the DTs and the AT.
In the context of smart buildings, [4] proposes a reference architecture for the development of DTs that aims at integrating heterogeneous data from different sensor types in a single data repository to enable the development of different applications (which can be viewed as DT services). They emphasise the fact that the databases containing building data/information (in this case, the IoT ontology and the sensor database) need to be constantly updated/evolved as sensors and actuators are added/removed/modified in the building to keep the databases in synchrony with the actual building. In this approach, the evolution of DTs is related to the evolution of the building, the AT, and is focused on the data aspect. The concept of DT evolution is related to the need to maintain the different databases in synchrony with each other in the context of building evolution. The paper discusses the fact that the integration of all the data in a single repository (that was previously developed in silos) enables the development of different applications to address different aspects of the system, but it does not directly address the question of how the system DT can be incrementally developed (evolved) to integrate different aspects of a system.
Composition of DTs We consider system evolution an iterative and incremental process. The purpose of the existing DTs may change over time, while new DTs for other purposes might be added in other situations. As such, different DTs have to be combined to focus on specific aspects of improving the system. The idea of composition and interoperability of DTs aligns with several contributions in literature, although their focus lies on compositional aspects, not evolution. Especially in the case of systems of systems we find references describing how the compositionality of twins is a challenge given conflicting purposes and constraints [24, 30].
Traore describes the conceptual framework on interoperability between disparate urban DTs [37]. Several levels of interoperability are described: data interoperability, model interoperability, service interoperability, data/model reuse, data/service reuse and model/service reuse. These types of composition are at the technical level and define the space of possible solutions for combining DTs together.
Ashtari Talkhestani et al. describe a hierarchical DT architecture composed of an intelligent layer on top of a set of DTs [2]. The intelligent DT layer is responsible for process optimisation by coordinating the DTs below. Similarly, Reiche et al. propose a networked structure of DTs based on the system hierarchy [34]. They introduce a digital twin of a System (DTS) that is superordinate to other DTs. The DTS thus manages the other DTs as an administrator. A DTS2DT-interface component is introduced to provide the communication. The authors focus on the technical aspects of the composition: how to communicate and which information is to be exchanged. Both architectures use the hierarchical transformation to compose the intelligent DT with the (orthogonal) regular DT.
Gil et al. [11] describe a DT-based approach to architect cooperative systems. In their approach DTs have semantic relationships and can be composed in a composition DT that inherits operations, attributes and behaviours of the composing DTs. They state this composition of small DTs may reduce implementation effort in complex systems. They demonstrate their approach by composing the DT of a cooperative robot cell through the composition of 4 DTs, on each of the of two heterogeneous robotic arms and the two effectors.
Kamel Boulos and Zhang [19] explores the adoption of DTs in the health sector and discusses their potential use for personalised medicine. The paper highlights the fact that different types of DTs can be developed to address different needs. For example, a DT can be developed for the whole human body, or only a part of a function of it (e.g. digestive system), or body organ (e.g. liver). It can also be developed for specific diseases or disorders. The paper introduces the concept of composite digital twins that allows building more complex DTs by composing/integrating two or more (simpler) DTs. It also introduces the concept of digital twin levels, which refers to the level of sophistication of the DT, and digital twin aggregates, which are aggregates of DT instances belonging to different individuals, e.g. sets covering one family, population group or the whole population. Similar ideas are found in the work of Jia et al., where they propose to create complex DTs by composing simple ones [17]. An ontology and knowledge graph combines the different aspect DTs. Finally, Robles et al. present an open framework for DT composition [35]. They aim to technically link individual DT entities to create a higher degree DT, allowing knowledge sharing. These types of frameworks can be used as the basis for the technical composition during the evolution proposed in this paper.
7 Ongoing and future work
We are in the process of refining the described approach with more analysis techniques while working on applying the proposed approach to additional case studies and on the integration of DevOps principles [20] to support continual improvements of DTs.
In this paper, we illustrate the proposed approach using a smart home system. This case study has allowed establishing the basis of our approach. As part of ongoing work, we are starting to work on several smart building projects. One focuses on the development of a DT to monitor and control different aspects of climatic rooms at École de technologie supérieure (ÉTS) in Montréal that will be used to support different research projects in construction engineering. The industrial environment provided by these rooms will allow us to validate and evolve different aspects of our approach. We are also working on the development of a DT to manage different aspects of a research laboratory at ÉTS, including thermal comfort, air quality, and acoustic comfort.
In both of these projects, we extend our work to the integration of the DevOps principles of feedback, and continual learning and experimentation to support the evolution and continual improvement of DTs. Concretely, we are developing the mechanisms to monitor the impact of modifications made on a DT. This will allow evaluation of whether the modifications are meeting the targeted improvement objectives.
We can also support the twin system engineers in analysing the notation we proposed. For this, we can draw inspiration from the large body of work that has been done in the systems dynamics community. For example, the causal loop diagram proposed by Forrester [3, 9] is a notation from systems dynamics. In causal loop diagrams, the connections show causal influence between these different PoIs. These influences can be positive or negative. By using the analysis techniques of system dynamics (given sufficient constraints), positive and negative feedback loops can be identified. As such, they can be used to model the meta-laws or physical laws of the system in an understandable manner. Furthermore, techniques are available to create and validate such causal loop diagrams. This might help designers better understand the dependencies between PoIs and goals.
One such direction that draws inspiration from this continual feedback from the real world is to go one step further with Forrester System Dynamics, using “stock and flow diagrams”. Stock and flow diagrams consist of stocks (or levels) and flows (rates) between them. A stock is a quantity that could have accumulated in the past. In our example, the temperature is a stock, as it is a reflection of the energy that accumulated. But also the total amount of energy used would be expressed as a stock. Flows represent the rate at which the stock is changing at any given instant. Flows either go into a stock (increasing the stock) or flow out of a stock (decreasing the stock). Stocks can connect from and to (infinite) sources, or between stocks. The rate of a flow can be influenced by converters. The semantic domain of the model is a set of differential equations. As such, stock and flow diagrams can be simulated and thus be used to evaluate the impact of a set of choices
8 Conclusion
In recent years, the MBSE community started exploring the impact of system, data and purpose evolution on DTs. We recognise that DTs by their nature have a very close relationship to a dynamic reality (the AT) and therefore need systematic, timely and reliable evolution. In contrast to evaluating DTs as individual units, our research specifically tackles the compositional aspects of DTs and their interplay during continuous and omnipresent system evolution.
In this paper, we investigate the evolution of a set of DTs using a case study of a real-world smart home system. Starting from a DT controlling the thermal comfort of a room, different orthogonal and non-orthogonal goals are added to the system. We also showed that the system’s properties of interest can interact with each other, resulting in unpredictable effects on the system’s functionality and performance if not adequately considered. To reason over the impact of these added goals and properties of interest, we provide a notation that helps connect the evolution’s why, what and how; connecting the goals, properties of interest and architecture. This notation allows us to reason on valuable transformations at the level of the twin system’s architecture. In the course of our study, we identify several architectural transformations, which we describe alongside the system descriptions. Specifically, we identified the following transformations: Basic, Hierarchical, Augmented, Orthogonal, New output, Chained, Arbitration. Furthermore, we discussed how the notation is valuable in evolving the different aspects of a twin system. We expect to enhance the notation and progress the research on reasoning about the continuous evolution of DT-enabled systems based on this paper
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.
Publisher's Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Joost Mertens
is a PhD student at the University of Antwerp, Faculty of Applied Engineering in Electronics and ICT. His research interest is the continuous evolution of Cyber-Physical Systems. Particularly, he is interested in the synchronization of digital twins and their actual system, through validation processes. He is also interested in the usage of the Digital Twin throughout the software release management process. His email address is joost.mertens@uantwerpen.be.
Stefan Klikovits
is a university assistant at the Johannes Kepler University Linz, Austria. His current research interests include model-driven systems engineering, autonomous driving system verification, and quantum computation. Stefan received his Ph.D. degree in Computer Science from the University of Geneva, Switzerland. He is involved in the international community and served as local chair of SE 2024 and MODELS 2024. Contact him at stefan.klikovits@jku.at.
Francis Bordeleau
is professor at Ecole de technologie superieure (ETS) in Montreal where he leads the Kaloom-TELUS ETS Industrial Research Chair in DevOps. His research interests include software/system engineering, software process improvement, Model-Based Engineering (MBE), DevOps and Digital Twins. He has over 25 years of experience researching, working, consulting, and collaborating with companies worldwide. Prior to joining ETS, he was Product Manager of Software Development at Ericsson (2013-2017), founder and CEO of Zeligsoft (2003-2013), and assistant professor at Carleton University (1997-2006). He received his Ph.D. in electrical engineering from Carleton University, Ottawa, Canada.
Joachim Denil
is an associate professor at the University of Antwerp, Faculty of Applied Engineering in Electronics and ICT. His research interests are enabling methods, techniques and tools to design, verify and evolve Cyber-Physical Systems. Specifically, he is interested in the performance modelling and simulation, model-based systems engineering, and verification and validation of models and systems. He serves as an associate editor of the Transaction of the SCS: Simulation. His email address is joachim.denil@uantwerpen.be.
Øystein Haugen
leads the research group for Cyber-physical System at the Faculty of Computer Science and Communication at Østfold University College. Ø. Haugen is focused on making better systems. In particular, he has worked in the domain of real-time systems and telecommunications. He has mainly concerned himself with modeling languages and methodology for applying them. He has taken part in the standardization of modeling languages SDL and MSC within ITU (International Telecom Union), and UML within OMG (Object Management Group), and he was General Chair of the conference MODELS 2010 in Oslo, Norway.
While definitions of DT traditionally refer to Physical Twin, we prefer to use the term Actual Twin because DTs can be associated with different types of systems that are not exclusively physical, including processes, Cyber-Physical Systems (CPS) and socio-technical systems.
The frequency of data update of the DT depends on its purpose and goals.
1.
Arup Digital twin: Towards a meaningful framework. Tech. rep., Arup: London, UK (2019)
2.
Ashtari Talkhestani, B., Jung, T., Lindemann, B., et al.: An architecture of an intelligent digital twin in a cyber-physical production system. Automatisierungstechnik 67(9), 762–782 (2019)CrossRef
Chevallier, Z., Finance, B., Boulakia, B.C.: A reference architecture for smart building digital twin. In: SeDiT @ ESWC, pp. 1–12 (2020)
5.
Dalibor, M., Jansen, N., Rumpe, B., et al.: A cross-domain systematic mapping study on software engineering for digital twins. J. Syst. Softw. 193, 111361 (2022)CrossRef
6.
Durdik, Z.: Architectural Design Decision Documentation through Reuse of Design Patterns, vol. 14. KIT Scientific Publishing, Karlsruhe (2016)
7.
Eramo, R., Bordeleau, F., Combemale, B., et al.: Conceptualizing digital twins. IEEE Softw. 39(2), 39–46 (2021)CrossRef
8.
Fang, X., Wang, H., Liu, G., et al.: Industry application of digital twin: from concept to implementation. Int. J. Adv. Manuf. Technol. 121(7–8), 4289–4312 (2022)CrossRef
9.
Forrester, J.W.: Industrial Dynamics. MIT Press, Cambridge (1961)
10.
Gamma, E., Helm, R., Johnson, R., et al.: Design patterns: elements of reusable object-oriented software. Pearson Deutschland GmbH, Munich (1995)
11.
Gil, S., Mikkelsen, P.H., Tola, D., et al.: A modeling approach for composed digital twins in cooperative systems. In: 2023 IEEE 28th International Conference on Emerging Technologies and Factory Automation (ETFA), pp 1–8, (2023)https://doi.org/10.1109/ETFA54631.2023.10275601
12.
Glaessgen, E., Stargel, D.: The Digital Twin Paradigm for Future NASA and U.S. Air Force Vehicles. https://doi.org/10.2514/6.2012-1818 (2012)
13.
Grieves, M., Vickers, J.: Digital Twin: Mitigating Unpredictable, Undesirable Emergent Behavior in Complex Systems, pp. 85–113. Springer International Publishing, Cham (2017). https://doi.org/10.1007/978-3-319-38756-7_4
14.
Hesse, T.M., Paech, B.: Supporting the collaborative development of requirements and architecture documentation. In: 2013 3rd International Workshop on the Twin Peaks of Requirements and Architecture (TwinPeaks), pp 22–26https://doi.org/10.1109/TwinPeaks-2.2013.6617355 (2013)
15.
International Council on Systems Engineering (INCOSE): Incose systems engineering vision 2035. Tech. rep, International Council on Systems Engineering (INCOSE) (2021)
16.
International Organization for Standardization: Iso/iec 25000. Standard, International Organization for Standardization, Geneva, CH (2014)
17.
Jia, W., Wang, W., Zhang, Z.: From simple digital twin to complex digital twin part i: a novel modeling method for multi-scale and multi-scenario digital twin. Adv. Eng. Inform. 53, 101706 (2022)CrossRef
18.
Jones, D., Snider, C., Nassehi, A., et al.: Characterising the digital twin: a systematic literature review. CIRP J. Manuf. Sci. Technol. 29, 36–52 (2020)CrossRef
19.
Kamel Boulos, M.N., Zhang, P.: Digital twins: from personalised medicine to precision public health. J. Personal. Med. 11(8), 745 (2021)CrossRef
20.
Kim, G., Humble, J., Debois, P., et al.: The DevOps handbook: How to create world-class agility, reliability, & security in technology organizations. IT Revolution (2021)
21.
Kritzinger, W., Karner, M., Traar, G., et al.: Digital Twin in manufacturing: a categorical literature review and classification. Ifac-PapersOnline 51(11), 1016–1022 (2018)CrossRef
22.
Lehman, M.M.: Laws of software evolution revisited. European workshop on software process technology, pp. 108–124. Springer, Berlin (1996)
23.
Lehner, D., Garmendia, A., Wimmer, M.: Towards flexible evolution of digital twins with fluent apis. In: 2021 26th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), IEEE, pp. 1–4 (2021)
24.
Michael, J., Pfeiffer, J., Rumpe, B., et al.: Integration challenges for digital twin systems-of-systems. In: Proceedings of the 10th IEEE/ACM International Workshop on Software Engineering for Systems-of-Systems and Software Ecosystems. Association for Computing Machinery, New York, NY, USA, SESoS ’22, pp. 9–12, https://doi.org/10.1145/3528229.3529384, (2022)
25.
Mo, R., Cai, Y., Kazman, R., et al.: Architecture anti-patterns: automatically detectable violations of design principles. IEEE Trans. Softw. Eng. 47(5), 1008–1028 (2021). https://doi.org/10.1109/TSE.2019.2910856CrossRef
26.
Mohsen, A., Gokhan, C.: Digital twin: benefits use cases challenges and opportunities. Decis. Anal. J. 6(1), 111–123 (2023)
27.
Nakamura, T., Basili, V.R.: Metrics of software architecture changes based on structural distance. In: 11th IEEE International Software Metrics Symposium (METRICS’05), pp 24, https://doi.org/10.1109/METRICS.2005.35 (2005)
28.
Nord, R.L., Ozkaya, I., Kruchten, P., et al.: In search of a metric for managing architectural technical debt. In: 2012 Joint Working IEEE/IFIP Conference on Software Architecture and European Conference on Software Architecture, IEEE, pp. 91–100 (2012)
Olsson, T., Axelsson, J.: Systems-of-systems and digital twins: A survey and analysis of the current knowledge. In: 2023 18th Annual System of Systems Engineering Conference (SoSe), pp 1–6, https://doi.org/10.1109/SoSE59841.2023.10178527 (2023)
31.
Parnas, D.L.: On the criteria to be used in decomposing systems into modules. Commun. ACM 15(12), 1053–1058 (1972). https://doi.org/10.1145/361598.361623
Pfahler, F., Minelli, R., Nagy, C., et al.: Visualizing evolving software cities. In: 2020 Working Conference on Software Visualization (VISSOFT), IEEE, pp 22–26 (2020)
34.
Reiche, L., Gundlach, C., Mewes, G., et al.: The digital twin of a system: a structure for networks of digital twins. In: 26th Int. Conf. on Emerging Technologies and Factory Automation (ETFA), IEEE (2021)
35.
Robles, J., Martín, C., Díaz, M.: Opentwins: an open-source framework for the development of next-gen compositional digital twins. Computers in Industry (2023)
36.
Tao, F., Xiao, B., Qi, Q., et al.: Digital twin modeling. J. Manuf. Syst. 64, 372–389 (2022)CrossRef
37.
Traoré, M.K.: A conceptual framework to analyze urban digital twins interoperability (2024)
38.
Van Rysselberghe, F., Demeyer, S.: Studying software evolution information by visualizing the change history. In: 20th IEEE International Conference on Software Maintenance, 2004. Proceedings., IEEE, pp .328–337 (2004)
39.
Vogel-Heuser, B., Fay, A., Schaefer, I., et al.: Evolution of software in automated production systems: challenges and research directions. J. Syst. Softw. 110, 54–84 (2015). https://doi.org/10.1016/j.jss.2015.08.026CrossRef
40.
Wohlin, C.: Case study research in software engineering-it is a case, and it is a study, but is it a case study? Inform. Softw. Technol. 133, 106514 (2021). https://doi.org/10.1016/j.infsof.2021.106514CrossRef
. The feedback/control flow
on the other hand is used to update the AT, based on the implemented DT services and the newly gained knowledge.
. Note that the figure indicates an interaction with the twin system as a unit, but in practice users may modify all parts of the system (e.g. directly configure the DT or alter the AT’s settings).
; they may also rely on the services of another DT to provide their own services
.
shows the communication from DT2 and Twin System 1 as an AT. This conceptual distinction is important for avoiding conflicts of different DT’s purposes, as we will see further on in Sect. 3.
