Cyber-Physical Systems (CPS) are required to operate over a longer lifetime. As such, their requirements can change, requiring updates to the system to be be rolled out continuously (Continuous Deployment) throughout the system's lifetime. The DevOps methodology provides a structured, quality assuring way to do so, as it integrates Development and Operations of a system in a continuous cycle. DevOps is generally applied in software development, however in the design of CPS, which follows a ModelBased Systems Engineering (MBSE) approach, it is not. This is because many challenges remain in the application of DevOps in MBSE. Our focus is on creating the foundations for continuous deployment of safety-critical CPS using digital twins of the CPS.k.
harsh conditions, reasoning about the redesign of the system, synchronization between the system in operation and its models, the virtual deployment of system changes in model-based testing of these heterogeneous systems.
Inspired by these challenges, our aim is to create the foundations for continuous deployment of safety-critical CPS using a digital twin. We aim to do this by applying the DevOps cycle for the MBSE of CPS. In relation to DevOps, we specifically tackle the challenges in the release, deploy and monitor phases, visually represented in green/dots in Figure 1. Additionally, we only tackle the challenges at the technical side of the engineering process, while challenges in the human aspect of the process are disregarded. In summary, our focus is the development of new digital-twin enabled methods and techniques to allow the continuous deployment of CPS. With these techniques, we aim to solve the challenges in the monitoring, release management and deployment of CPS.
The remainder of this paper is structured as follows: in Section 2 we cover the state-of-the-art. Section 3 describes our objectives and approach, after which Section 4 lists past work and preliminary results. In Section 5, we look at the future, and lastly Section 6 concludes the paper.
We find relevant research in the areas of (1) digital twins, (2) run-time monitoring in real-time systems and (3) continuous integration in MBSE.
The digital twin is a popular concept in the industry 4.0 domain. In essence a digital twin is
a virtual version of a physical entity, with which it shares data in both directions. As such,
the application potential in the DevOps cycle is high, since it also exchanges information in
such a way. In [
Runtime monitoring in literature mainly covers the system monitoring itself but does not take
the critical part of data-transfer into account for the DevOps cycle of CPS systems. Medhat
et al. [
In [
The main goal is to define new methods that overcome current challenges concerning the
continuous deployment of CPS, and tools that facilitate the integration of the digital twins
in these methods. The underlying framework is the DevOps cycle for Model-Based Systems
Engineering. Our approach is to apply multi-paradigm modeling principles to create such
methods and techniques. Multi-paradigm modeling advocates the explicit modeling of all parts
of a system, at diferent abstraction levels using multiple formalisms [
(i) Definition of a method to optimize data capture from a system in operation for the calibration and initialization of digital twins. To use a digital twin, there must be a synchronization between the real and physical world. This can be achieved by monitoring the system in operation and using the monitored data to initialize the digital twin. The data logging is done in the Monitor phase of the DevOps cycle. The problem at hand is a co-design problem. On the one hand, the initialization of a digital twin is a state estimation of the system, which is more accurate when more data is used. On the other hand, the CPS being monitored is a heterogeneous real-time system with limited resources. The system instrumentation introduces penalties in memory, execution time and, latency. As such, there is a trade-of between the accuracy of the initialization and the real-time behavior of the system. Additionally, the data must get to the digital twin. If the digital twin is physically separated from the system, network transmission is required. A network introduces additional limits and uncertainties: bandwidth, latency, packet loss. (ii) Definition of a method to support release management and software deployment using the digital twin for viability checking. The goal is to create a method that can perform automated viability checking (testing) of a release on a product family and its undocumented variants. The challenge lies in the fact that within one product family, various system variants reside. These variants are either documented (variant by design, e.g. more expensive, faster) or undocumented (variant due to runtime changes, e.g. replaced parts, wear and tear, new environments that difer from the initial test conditions). In the testing phases of a piece of software, it can only be tested against the variants by design. Variants due to runtime changes should also be tested to ensure compatibility. The shared knowledge of the digital twin(s) of the system(s) implicitly contains the undocumented changes and can therefore exclude incompatible candidate systems through viability checking. (iii) Exploration of computational architectures to support continuous deployment. The goal is to explore diferent architectures that enable the continuous deployment of system updates, specifically with regards to the release viability checking of (ii). Not all system architectures are eficient in this viability checking, especially with regards to the location of the digital twin. Examples of architectures could be: (a) running centralized digital twins and performing individual tests. (b) Running centralized digital twins, but grouping systems in compatible groups, and testing the group. (c) Running decentralized digital twins on edge nodes and performing individual test. These examples show the variability in the testing architecture. Finally, complex event processing can lump specific events together in the monitoring hierarchy.
Our past and current work has mainly focused on sub-objective (i). As described in section 3.2,
this objective concerns the co-optimization of a system and its digital twin to find the optimal
trade-of between the instrumentation load on the system and the accuracy of the digital twin.
For this trade-of analysis it is essential to have: (a) a method of verifying the instrumentation
load on the system, and (b) a method to determine the sensitivity of parts of the model. Thus
far, we have tackled the problem of verifying the load on the system in [
In the work on (a), we made various assumptions regarding the expected output from (b), which is only logical given the co-optimization approach. The focus of our current work is thus to replace those assumptions with factual data from developing (b). Currently, we are researching diferent types of data-assimilating digital twins of systems, of which we aim to generate sensitivity analyses as input for our method from (a). Then, the goal is to combine (a) and (b) in a single method.
The objectives in section 3.2 are formulated in what we deem chronological order. After completing objective (i), we aim to first complete objective (ii), and then (iii), since objectives (ii) and (iii) are inherently linked. The goal for objective (ii) is to perform automated viability checking in the release and deploy stages of the DevOps cycle. This viability checking will be based on the current digital twin of the system, we envision an approach similar to virtual commissioning. In objective (iii) we then specifically aim to look at architectures supporting this release management. The reason being that we believe the needs for release management vary greatly between diferent CPS, e.g. the needs for an automated factory are diferent than those from a fleet of vehicles.
Lastly, we foresee that various assumptions will be made throughout this work, e.g. in our current partial solution to sub-objective (i), we still have assumptions with regards to the data-communication between the digital and physical world. After the first iteration through the objectives, we aim to perform a second development cycle, which will allow us to further elaborate on the assumptions made throughout the course.
In this paper we presented our views on using digital twins to enable continuous deployment in the field of model-based systems engineering for cyber-physical systems. We briefly introduced the challenges as covered in literature, and reviewed the related work most relevant to those challenges we tackle. We described our main objective and three sub-objectives as well as our past, present and future work on these topics.
The work plan shown in Figure 2 is divided in 4 work packages. Three of these are for the sub-objectives, whereas the fourth foresees time for writing papers and general communication. Each year is divided in 4 quarters, each quarter is further split to 3 months. The People’s months (PM) column gives an indication of the amount of hours each task receives. In the case of WP4, the timeline is colored light gray. This indicates that this is working time allotted throughout the entire 4 years. The work plan timeline cannot show the dependence of tasks on one-another, which is why the dependency relationship is provided by a design structure matrix.
The design structure matrix shown in Figure 3 shows only one dependence problem, which is that the definition of the use case depends on the method being developed in T2.2., T3.1. and T3.2.. Depending on the abilities of this method, the use case must be defined, yet these abilities are not known beforehand. In our case we tackle this dependence by making assumptions on those abilities. By then iterating a second time through the design, as can be seen in the timeline, we can alter the implemented use case where necessary.
A visual poster summarizing the challenges discussed in this paper can be seen in Figure 4. t y n
e n S rp e h
c
o y j , s C f te
r m . g t
s i o
j C r {
; r e il o e n
e f n i n c
a n D i
m g i h
A la , n . it em ito tsem iged tssy iza
m sy th e it
h p e t o ed iz n n tsn co i o ra rh e a ts c m
n ru is no sy ts s c o in ih a t T e l e w t w a -re t
a a t a o d m c n d n e rd n y is au ign ked l.rd ifen ah ian lo y }@ ru ra ow tdo teh ltw
il tp sh l ta p h n a : g i
e ca a e e in ig e P d :1 sa r v t d
e i c - . t e e D r m e in th ce sp th i
b s a e t d ts – , a
m th f e y B ir s [1 so l- f o u y o e o o n q d ls d d t i
e o
w m t
M e u y du so l rae em itn aw in le ita ) it n ) k ig .
S e co d d SE ca d ge PC lif t re ie B t a d
r uo tcu lpp (M e g l ( e s e c n th in .y t t du re iw tw fte ro iffe t l a
n ta s p d e i e
g r em id s
u o t h t n i ga e e t n w an Th to e
m . t m se y il e em en lo i s t m
m a sy y ep fa le s lo
e d r
t d c ts t e th it l rre epd li.y d d d g a i o n
e a w ro fam th a u e th ,s
t ft g e
m n n o n s n o a o ia
r e d a g fte in
n se v in o ts i g n e ab ted
f a d an re ir g en a a va to itn
m M ) : s u
S d e te co : P te v 2 C n it y d
e c it n e e il u gn .se cu b it ie
m j b s le li o a if l i o p t a d r
m n u m en h a u O co id C f ( rva ,ts ya : le s
e l t m v a n :3 em se it ch ia
t c r e s r e t a g sy tu j n v en f ce bo em fo ll o it e p a e h ru lp u
o h yp rc C t a O im rg sed tsc lga rsd op h g d la ttehh .n l-eadB sepgA -rrgeeV .)aTow rskohW rscaeeR iirgeenn rchana irscyehP i e o in n 7 n e b w re M re ir 1 aepn iree seR yC , g sa ien Sp (20 RU le d d g .H EC ro th n fo c n ra En om , Eu nd o t cy a Tow rea fr ew .g l“ sa ap en
e lu in a svepO libnu ..)(1902 .ftsSow itrveeed 68780 gaehnV irgeenn rsPpoo ftsySem oadRm eanagm eD red ,reM -tsyem .tnR l-a402 ,,.C& se ilcyPo tsseom reoanp ndaM iftttrsaeeehpnnoo lillssccaaeebppphoo frsceeeen li,,.]aeeboCB&mmmmWilf-rrsscvyySeopbhaPCO iltsveeeooonnuupCDm ilii..::ftttrr///ssaaehphnh illi,,,,..JrsySaaaeePndRD lil-tsssyaeeeedbdomm i,,.scee–2019424429dng l,...()SgEe012332nD ilf-rrscyyySaaeednbphoC .Irss"TEeodaaundw iiiitrveeEoonanngnnng .fttssssySeeomm R a R [1 eD fo ebw []2 ga roP ][3 gA en In yS