The Incubator Case Study for Digital Twin Engineering
Hao Feng, Cláudio Gomes, Casper Thule, Kenneth Lausdahl, Michael Sandberg, Peter Gorm Larsen
TThe Incubator Case Study for Digital TwinEngineering
Hao Feng † , Cl´audio Gomes † , Casper Thule † , Kenneth Lausdahl † ,Michael Sandberg † , and Peter Gorm Larsen †† DIGIT, Department of Electrical and Computer Engineering, AarhusUniversity, DenmarkFebruary 23, 2021
Abstract
To demystify the Digital Twin concept, we built a simple yet representativethermal incubator system. The incubator is an insulated box fitted with a heatbed,and complete with a software system for communication, a controller, and sim-ulation models. We developed two simulation models to predict the temperatureinside the incubator, one with two free parameters and one with four free param-eters. Our experiments showed that the latter model was better at predicting thethermal inertia of the heatbed itself, which makes it more appropriate for furtherdevelopment of the digital twin. The hardware and software used in this case studyare available open source, providing an accessible platform for those who want todevelop and verify their own techniques for digital twins.
Cyber-Physical Systems (CPSs) are integrations of computation with physical pro-cesses. Embedded computers act through a network, monitor and control the physicalprocesses [1].The cyber part refers to the computation part and communications, while the phys-ical part refers to the part of the system interacting with the physical world. The envi-ronment is the part that may significantly affect the properties of the CPS but cannotdirectly be controlled.An example of a CPS is a car. The physical part in the car contains a body, fourwheels, seats, an engine, and so on, which interact with the environment (e.g., wind,road surface). The cyber part of the car is different control systems implemented inElectronic Control Units (ECUs) that communicate among themselves through a Con-troller Area Network.Since systems are getting increasingly complex, models are needed to better com-prehend their behaviour. A model is an abstract representation of a system, built with1 a r X i v : . [ ee ss . S Y ] F e b he goal of understanding one aspect of the system [2]. For example, a Computer-AidedDesign (CAD) model of a car may store information about the sizes of the wheels,shapes of the chassis, styles of the car, and so on, but it does not contain informationabout how the forces acting on the car affect its movement. An engineer who desiresto analyse the dynamics of the car may build a dynamic model described by the differ-ential equations introduced in, e.g., [3, Section 5].Beyond better understanding, models can assist with optimising the overall system,discovering causes and effects, measuring consequences of changes, and communicat-ing among engineers. Once the system is deployed, the models used to build it shouldnot be discarded. Instead, they should be integrated into a Digital Twin (DT).DT is often defined as a framework that integrates modelling, simulation, moni-toring, and optimisation technologies, with the intent of adding value to the use of thePhysical Twin (PT) [4,5]. For instance, a DT provides the ability to run simulations thatreproduce and predict the behaviour of the PT under its current operating conditions.The following important parts are highlighted [6]: Data – collected from the PT through sensors over time;
Models – knowledge about different aspects of both the cyber and the physics of thePT and its environment ; and Algorithms – techniques that use data and models, manipulating those to generatemore data and knowledge (e.g., fault detectors, supervisory controllers, state es-timators, optimisers).An example common structure of a DT is represented in fig. 1. In fig. 1, the DTemploys calibration algorithms to update the models of the CPS and environment withthe best estimate of the parameters. The resulting data is then used to inform monitorsthat check whether the system is performing safely and optimally. When violations aredetected, humans (or other algorithms) may decide to make changes to the physicaltwin.DTs increase the value of their physical counterparts by potentially enabling ad-vanced visualisations, reconfigurability (and therefore robustness with respect to chang-ing environment), safety, predictability, and reduced maintenance.The often vague definitions and claims about DTs makes the concept hard to distin-guish from: self-adaptive systems [7, 8], autonomic computing [9], Industry 4.0 [10],models@runtime [11, 12], and supervisory controllers [13].We introduce the Incubator case study as an attempt to clearly identify the tech-niques used in digital twinning. This system is a simple, yet representative, CPS andPT. Detailing how the DT is built is out of the scope of this manuscript, but we sketchhow such implementation can be done, and which technologies can be used. Thismakes it easier for the reader to see the similarities of DT to the aforementioned re-lated research areas.The publicly available repository contains the up-to-date hardware and softwarespecifications of the case study.The rest of the report is organized as follows: section 2 introduces the incubator It is worth noting that models can be described at different levels of abstraction, and typically there is atendency that accurate models also are very slow to analyse for example by means of simulation. https://github.com/INTO-CPS-Association/example-incubator The main goal of the incubator is to reach a certain temperature within a box andregulate it regardless of the content inside. The physical components in the incubatorform a plant that is controlled by a Raspberry Pi. The overall systematic diagram ofthe Incubator is shown in fig. 2.
We start with a brief description of the hardware components, back-of-the-envelopecalculations, and refer the reader to the online repository for more details.The plant of the Incubator consists of (see fig. 3):• A styrofoam box in order to have an insulated container.• A heatbed to heat up the content inside the styrofoam box.• A fan to distribute the heating inside the box.• Two temperature sensors to monitor the temperature inside the box.• One temperature sensor to monitor the temperature outside the box. https://github.com/INTO-CPS-Association/example-incubator emperature Sensors Heatbed Content
Fan Temperature Sensor
InsulatedContainerController
Figure 2: Schematic overview of the Incubator.• A controller to communicate with the DT, actuate the heatbed, the fan, and readthe temperature sensors.• A Printed Circuit Board (PCB) connecting all electrical components.• A power supply.
The aim of the insulated container (see fig. 3(a)) is to preserve the energy generated bythe heatbed inside the box as much as possible, so as to minimise the potential impactof the environment around the CPS. We chose the styrofoam box (see fig. 3(a)) madeof polystyrene for its good insulation properties.The air volume inside the box is about . m . This value will be used for estima-tion of energy and air flow requirements. The heated content in the incubator is the air inside the box. The heatbed was used (seefig. 3(b)) as the surface heat source instead of a bar-like or point-like heat source. Thisis because we want to make the heat energy distributed as uniformly as possible.Assuming that• there is no heat transfer into the box walls,• the mass of the air inside the box is . ,• the air heat capacity is − K − and it does not change due to the temper-atures, pressure and so on,the heatbed can warm up the air inside the box from ( ° C ) to (about . ° C ), by producing . ∗ (300K − ∗ − K − = 200J a) The styrofoam Box is used as aninsulated container. (b) The heatbed is approximately ∗ ∗ mm to fit the styrofoambox.(c) The Fan, used to circu-late the air in the styrofoambox. It can be run on 12Vor 24V. (d) Raspberry Pi 4 ModelB (e) Temperature Sensor Figure 3: Components used in the incubatorof energy.Assuming it delivers at least − of power, be provided inunder 2 seconds. As we will show later, this is more than enough power. We installed a fan (see fig. 3(c)) inside the box to circulate the air inside the box formaking the temperature as uniformly distributed as possible. The fan airflow is about . s − .With a box volume of . , the fan should take 2 seconds to move all the airwithin the box. A Raspberry Pi 4 Model B (see fig. 3(d)) was selected to implement the controller. TheGeneral Purpose Input/Output (GPIO) connectors on the Raspberry Pi can be used toconnect many accessories such as temperature sensors, fan, and the heatbed. Further-more it supports wireless internet out of the box, with built-in Wi-Fi and Bluetooth,5hich simplifies deployment of the controller.
It is necessary to get feedback from the temperature sensors for feedback control. To dothis, a DS18S20 High-Precision 1-Wire Digital Thermometer (see fig. 3(e)) was usedfor measuring the temperature. This temperature sensor can measure temperaturesfrom -55 ° C to +125 ° C with an accuracy of 0.5 ° C from -10 to +85 ° C , which issuitable for the physical incubator. And each DS18S20 has a unique 64-bit serial code,which allows multiple DS18S20s to function on the same 1-Wire bus. Such 1-wire bussupport to connect multiple sensors with only one GPIO. In the incubator system, threesensors were deployed for detecting the temperature. Controlling the heatbed requires approximately current which is not supported bythe Raspberry Pi. Instead, MOSFETs are used to separate the control signals from theRaspberry Pi and the driving currents. In order to decouple the control signals from theRaspberry Pi to the MOSFETs, we use optocouplers. The PCB schematic is shown infig. 4. TIL111TIL111TIL111TIL111 IRLZ44NIRLZ44NIRLZ44NIRLZ44N k k k k k k k k W S upp l y . v
12 645
OK1
12 645
OK2
12 645
OK3
12 645
OK4 Q1Q2Q3Q4 R R R R R R R R R9R10R11R12 X2-1X2-2X2-3X3-1X3-2X3-3X4-1X4-2X4-3X5-1X5-2X5-3R13
JP1
JP2
JP3
JP4
JP5 X2-4X3-4X4-4X5-4 J P JP7 J P JP9
JP10 GND2GND1GND3GND4GND V CC . VCC3.3VCC3.3 P W M PWM1 P W M PWM0 - W I R E S U PP L Y P W M O U T S U PP L Y P W M O U T SUPPLY3OUT3SUPPLY4 O U T G P I O GPIO17 G P I O GPIO27 1WIRE_VCC VCC5VVCC5V
Figure 4: PCB schematics.6 .1.7 The Connections
The configuration details are shown in fig. 5. (a) Styrofoam box configuration.
TemperatureSensor 1TemperatureSensor 2TemperatureSensor 3 Fan To 18VPowerSupply Heatbed Topowersupply (b) PCB board connection.
Figure 5: Connections of components.
The software setup includes a controller, a low-level driver, and a communicationserver for delivering data. Fig. 6 shows the schematic of the software system.
Communication Server – We used a Rabbit MQ server, running on the raspberry piitself.
Low-level driver – Abstracts the low level communication with the sensors and actu-ators.
Controller – Implements the control logic required to regulate the temperature insidethe incubator. It receives the measured data and sends commands through thecommunication server.
For the case study, the RabbitMQ server was deployed for synchronisation and com-munication. With tens of thousands of users, RabbitMQ is one of the most popularopen source message brokers. RabbitMQ is a mature, lightweight, and easy to deployon premises and in the cloud. abbit MQ serverRaspberry Pi GPIO low_level_driver(Python Application)Controller(Python Application)Temperature sensors, fan, heater Physical Twin
Figure 6: Schematic of the software deployment of the components.The controller on the Raspberry Pi is listening from the RabbitMQ server for com-mands of controlling the fan and the heatbed and at the same time sharing the controlstates to the RabbitMQ server.We choose RabbitMQ because it greatly facilitates the digital twinning process, asthe DT can be implemented by components that listen to the messages being passedbetween the controller and the load level driver, as illustrated in fig. 7.
The low-level driver is used to interact with the PT and to issue the states of the PTto the RabbitMQ server. In order keep the device in a safe state, a safe protocol isincorporated into the low-level driver.The low level driver periodically reads the temperature data, and checks if there arecommands from the controller, through the communication server. The temperaturedata is uploaded to the communication server.
The controller used in the case study is a comparable to a bang-bang controller, whicha small difference described below. The control strategy is executed after receiving thetemperature measurements.The principle of bang-bang control is that when a reference temperature is givento the controller, the controller issues a heating signal turning on the heatbed until themeasured temperature from sensors reaches the reference temperature. Because of thedelayed effect of the temperature, the controller needs to wait after each actuation, tomake sure the temperature does not rise too much. Figure 8 shows the state chart of thecontroller. The controller parameters are: 8 abbitMQ
Low_Level_Driver
Fan Heated Bed
Temperature Sensors
Digital TwinController
Issue Commands Receive MessagesIssue Commands Issue CommandsCommunicate Data
Physical Twin Digital Twin
Figure 7: Overview of communication in the Incubator. The arrows represent the in-formation flow. LL – Lower limit for temperature; UL – Upper limit for temperature; H – Heating duration; C – Waiting duration. If T < LL, turn heater on.coolingdown after H sheating after C s, if T > UL after C s, if T< UL waitingheater off
Figure 8: Controller Statechart.
The dynamics model we created mainly focuses on predicting the temperature insidethe styrofoam box. To simplify the model, a few assumptions were made.9 ssumption 1
The temperature inside the box is distributed uniformly. This was ac-complished by deploying a fan inside the box ensuring distribution of the air inside thebox. We test this assumption in section 4.
Assumption 2
The box walls do not accumulate heat, or such heat accumulation haslittle effect on the air temperature inside the box.
Assumption 3
The specific heat capacity of the air inside the box is assumed constant,even when pressure and humidity may change.
Assumption 4
The majority of electrical power is transferred to heat energy, whichmeans the heatbed inside the box does not absorb the heat energy and the heat energygenerated by the fan was ignored as well.
Two different models were built:
Model A: relies on all assumptions.
Model B: relies on all assumptions except Assumption 4.To obtain the dynamic models of the temperature, the model was developed byconsidering the way the energy flows. If the amount of the energy used for heating theair is acquired, then this energy can be converted into the temperature inside the boxby calculating a basic heat equation: Q = cm ∆ T, (1)where Q represents the energy transferred, m equals the mass of the heated object, c isthe specific heat capacity which is dependent on many factors such as temperature andpressure, in this project to simplify the dynamic model, c is considered to be constant,and not dependent of temperature and pressure following Assumption 3. ∆ T is thetemperature change either in Kelvin or in °C. All the units are SI-units. Based on thisequation, the energy can be converted into temperature, which is the basis of the twotime-dependent models.We now explain the derivation of Model A, and Model B is described in section 3.2. In model A, only the transformation of the energy between the air inside the box andoutside of the box is considered. This means all the energy from the power supplyis transferred to the air inside the box (recall Assumption 4 above). The total energybrought in by the power supply is: E power in = V I ∆ t, (2)where V and I are the voltage and current provided by the power supply and ∆ t is thetime interval.Since the temperature of the air inside the box differs from that of the box, part ofthe energy flows from the air inside the box to the box. A parameter G box (unit: J K − )10as used to link the difference between the room temperature and the air temperatureinside the box with the energy flowing to the box, which is: E power out = G box ( T bair − T room ) , (3)where T bair represents the temperature of the air inside the box and T room is the roomtemperature.By subtract eq. (3) from eq. (2), we can get the difference of the energy. Substitutethe difference of the energy to the Q in eq. (1), a new equation is obtained: dT bair dt = 1 c bair m bair [ V I ∆ t − G box ( T bair − T room )] . (4)Since c bair , the capacity of the air inside the box, is assumed to be constant but un-known and m bair , the mass of the air inside the box, is a constant, a new parameter C air (unit: J K − ) is used to replace c bair ∗ m bair . A more compact equation withmodel A is: dT bair dt = 1 C air [ V I ∆ t − G box ( T bair − T room )] . (5) The main difference between Model B and Model A is that Model B relaxes Assump-tion 4. In other words, it considers the heatbed to also accumulate heat.Similar to G box , G heater (unit: J K − ) is used to describe the energy transferredfrom the heatbed to the air. The heat bed has its own specific heat capacity and mass.The energy transferred from the heatbed to the air is: E heater air = G heater ( T heater − T bair ) . (6)And the energy retained in the heatbed is: E heater = V I ∆ t − E heater air . (7)This energy makes the temperature of the heatbed increase.The process of energy flowing from the air to the box is the same as model A. Theenergy used for heating the air can be calculated by: E air = G heater ( T heater − T bair ) − G box ( T bair − T room ) . (8)Both the energy E heater and E air are used for heating the heatbed and the air. Accord-ing to eq. (1), the changes in the temperature of the heatbed and the air are: dT heater dt = 1 C heater ( V I ∆ t − G heater ( T heater − T bair )) dT bair dt = 1 C air [ G heater ( T heater − T bair ) − G box ( T bair − T room )] . (9)The model (eq. (9)) considered more detailed than Model A, has four parameters C heater , C air (unit: J K − ), G heater , and G box (unit: J K − ).11 .3 Calibration Although the dynamics models have been built, they contain free parameters. In orderto utilise the models, the models need to be calibrated for the incubator. The results ofthe calibration are detailed in section 4.2, and here we detail the procedure.A non-linear least squares solver was used to calibrate the parameters of the modelsderived above. Then the models are evaluated using the estimated parameters. After-wards the resulting behaviour is compared with a data trajectory that is obtained byrunning an experiment of the incubator. Finally using an optimisation function insidethe python Scipy package [14] to obtain the values of the parameters. Such a functionfinds the parameters that minimizes the residual error. When the residual error is smallenough, the optimised parameters can be obtained.The principle of the package is based on least-square, it assumes that: y = f ( x, θ ) + (cid:15) (10)where f ( x, θ ) is the model needed to be calibrated, θ are the parameters represented ina vector in the model, and y is the label or the measured data.A cost function or an objective function can be provided as: J = (cid:88) ( y i − f ( x i , θ )) (11)The objective is to acquire a minimal value of J , and at the same time, the correspond-ing θ are the value needed. In order to minimise the cost function, the most commonlyused one is gradient descent. After multiple iterations, the value of the cost functiongoes to a sufficient small value and the θ are obtained simultaneously. Two kinds of experiments have been conducted. One is for testing Assumption 1.Another has been conducted to calibrate the parameters of the models. The sourcecode used for the experiments is available online . The temperature inside the box is assumed to be distributed uniformly, thanks to thefan. An experiment was conducted to test the uniformity of the temperature. In thiscase, it is not necessary to know the temperature of the room, so the sensor measuringthe room temperature was used to test the air temperature inside the box. The setupwith the sensors can be seen in fig. 9.During the experiment, the fan is always turned on in order to circulate the air insidethe box and the fan blows the wind from the bottom to the top in fig. 9. The heatbedwas turned on during two periods. The experimental results are shown in fig. 10. https://github.com/INTO-CPS-Association/example-incubator Figure 9: Three sensors are placed in different places.
Box opened Box openedHighestdisagreementHighestdisagreement
Figure 10: Experimental results of a uniform temperature inside the box. The first sub-figure shows the temperatures measured from the three sensors change over time. Thetemperature measured from the sensor T2 is overlapped by the average temperature,which is hard to read. The other subfigures show different information regarding theexperiment such as the status of the heatbed, the power introduced in the system, etc.From the first subfigure in fig. 10, it seems that the temperature correlates with thedistance to the heatbed and the average temperature matches the temperature measured13rom T2 in fig. 9.Since only three temperature sensors are included in the box and one is necessaryfor measuring the room temperature, sensor T2 in fig. 9 was rearranged to the newplace in fig. 11 and sensor T1 in fig. 9 was taken to be outside of the box measuring theroom temperature. The new setup of the sensors is shown in fig. 11. One was placedin the hottest position which is T2 position in fig. 11 and another one was placed in thecoldest position, T3 position in fig. 11. Taking the average of those two, the averagetemperature of the air inside the box is acquired.Figure 11: Optimized setup for sensors. The position of T2 and T3 are the same withfig. 9In order to determine whether a stronger wind flow contributes a more uniformtemperature, one additional experiment was conducted based on the setup in fig. 9. Allthe conditions were the same except the voltage of the fan which is 18 V while in theprevious experiment it was 12 V . The result is shown in fig. 12.The previous setup in fig. 10 showed a discrepancy of a maximum of 7 °C betweenthe three temperature measurements while the maximum discrepancy in a new setupwith 18 voltage on the fan is 6 °C. 14igure 12: The experimental result with 18 voltage on the fan. Based on the optimised setup for sensors (fig. 11), a calibration experiment was con-ducted and the calibration method has been described in section 3.3. The experimentwas used for generating a data trajectory. The calibrated parameters for the model Aare C air ( unit : J K − ) = 616 . and G box ( unit : J K − ) = 0 . . And the cali-brated parameters for the model B are C air ( unit : J K − ) = 486 . , G box ( unit :J K − ) = 0 . , C heater ( unit : J K − ) = 33 . , and G heater ( unit : J K − ) = 0 . .The calibration result can be seen from fig. 13. Model A is sufficient to get a rough Orange is Model BBlue is Model A Purple line is theaverage roomtemperature. Red is theheatbed signal
Figure 13: The calibration result.approximation of the system magnitude and time scale, whereas the model B is betterat predicting the inertia of the heatbed itself.15
Digital Twinning Goals
In this section, we sketch the goals of the digital twinning process for the incubatorcase study. This constitutes our future work.Our goal is to implement a DT framework that enables
Real-time visualization of the incubator status – achieved by listening to the con-troller and low level driver messages, and relaying that data into a time seriesdatabase, and plot the data into a dashboard.
On demand calibration – achieved by automatically running the calibration processdescribed in section 3.3. This is similar to the tracking simulator implementedin [15].
Anomaly detection and Heatbed state estimation – This is achieved by running aKalman filter [16] that uses Model B developed in section 3 and correlates themeasure data to the (non-measured) heatbed temperature.
What-if simulations – This is implemented by running co-simulations that relay thehistorical or real-time data from the PT (e.g., similar to what is done in [17]). Itcan be used to, e.g., optimize the controller parameters introduced in fig. 8.
Self-adaptation loop – This is the functionality that truly closes the loop of the DT.We envision that, whenever a new object (imagine a bucket of cold water) isplaced in the incubator, the DT will:1. detect that the plant behavior has changed (given by the anomalies detectedby the Kalman filter);2. schedule an experiment to gather relevant data (e.g., let the plant cool downto a safe temperature, then ramp up heating for some time).3. configure the controller for the new experiment;4. gather the experiment data;5. run the calibration of Model B for new experiment;6. re-configure Kalman filter with new parameters;7. run what-if simulations to optimize the controller behavior; and8. finally re-configure the controller.
We described the implementation and modelling of the incubator case study. Hardware,software, and datasets are available online . Using this example to set the terminology,we proceeded to demystify the DT concept and its goals. https://github.com/INTO-CPS-Association/example-incubator eferences [1] Edward A. Lee. Cyber Physical Systems: Design Challenges. In , pages 363–369, 2008.[2] Thomas K¨uhne. What is a Model? In Language Engineering for Model-Driven Software Development , volume 04101. Internationales Begegnungs- undForschungszentrum f¨ur Informatik (IBFI), 2005.[3] Dieter Schramm, Manfred Hiller, and Roberto Bardini.
Vehicle Dynamics .Springer, 2014.[4] Fei Tao, He Zhang, Ang Liu, and A. Y. C. Nee. Digital Twin in Industry: State-of-the-Art.
IEEE Transactions on Industrial Informatics , 15(4):2405–2415, April2019.[5] Aidan Fuller, Zhong Fan, Charles Day, and Chris Barlow. Digital Twin: EnablingTechnologies, Challenges and Open Research.
IEEE Access , 8:108952–108971,2020.[6] Louise Wright and Stuart Davidson. How to tell the difference between a modeland a digital twin.
Advanced Modeling and Simulation in Engineering Sciences ,7(1):13, December 2020.[7] Danny Weyns, M. Usman Iftikhar, Didac Gil de la Iglesia, and Tanvir Ahmad. Asurvey of formal methods in self-adaptive systems. In
Proceedings of the FifthInternational C* Conference on Computer Science and Software Engineering -C3S2E ’12 , pages 67–79, Montreal, Quebec, Canada, 2012. ACM Press.[8] Tao Chen, Rami Bahsoon, and Xin Yao. A Survey and Taxonomy of Self-Aware and Self-Adaptive Cloud Autoscaling Systems.
ACM Computing Surveys ,51(3):1–40, June 2018.[9] J.O. Kephart and D.M. Chess. The vision of autonomic computing.
Computer ,36(1):41–50, January 2003.[10] Heiner Lasi, Peter Fettke, Hans-Georg Kemper, Thomas Feld, and Michael Hoff-mann. Industry 4.0.
Business & information systems engineering , 6(4):239–242,2014.[11] Nelly Bencomo, Robert France, Betty H. C. Cheng, and Uwe Aßmann, editors.
[email protected] , volume 8378 of
Lecture Notes in Computer Science . SpringerInternational Publishing, Cham, 2014.[12] Nelly Bencomo, Sebastian G¨otz, and Hui Song. [email protected]: A guidedtour of the state of the art and research challenges.
Software & Systems Modeling ,18(5):3049–3082, October 2019. 1713] Mohammad Karimadini, Ali Karimoddini, and Abdollah Homaifar. A Survey onFault-Tolerant Supervisory Control. In , pages 733–738, Windsor, ON,Canada, August 2018. IEEE.[14] SciPy 1.0 Contributors, Pauli Virtanen, Ralf Gommers, Travis E. Oliphant, MattHaberland, Tyler Reddy, David Cournapeau, Evgeni Burovski, Pearu Peterson,Warren Weckesser, Jonathan Bright, St´efan J. van der Walt, Matthew Brett,Joshua Wilson, K. Jarrod Millman, Nikolay Mayorov, Andrew R. J. Nelson, EricJones, Robert Kern, Eric Larson, C J Carey, ˙Ilhan Polat, Yu Feng, Eric W. Moore,Jake VanderPlas, Denis Laxalde, Josef Perktold, Robert Cimrman, Ian Henrik-sen, E. A. Quintero, Charles R. Harris, Anne M. Archibald, Antˆonio H. Ribeiro,Fabian Pedregosa, and Paul van Mulbregt. SciPy 1.0: Fundamental algorithmsfor scientific computing in Python.
Nature Methods , 17(3):261–272, March 2020.[15] Christian Møldrup Legaard, Cl´audio Gomes, Peter Gorm Larsen, and Frederik F.Foldager. Rapid Prototyping of Self-Adaptive-Systems using Python FunctionalMockup Units. In , SummerSim ’20, pageto appear, Virtual event, 2020. ACM New York, NY, USA.[16] Rudolph Emil Kalman. A New Approach to Linear Filtering and Prediction Prob-lems.
Journal of Basic Engineering , 82(1):35, March 1960.[17] Casper Thule, Cl´audio Gomes, and Kenneth Lausdahl. Formally Verified FMIEnabled Data Broker: RabbitMQ FMU. In2020 Summer Simulation Conference