Skip to content

Commit

Permalink
minor changes for JOSS publication (#12)
Browse files Browse the repository at this point in the history
  • Loading branch information
@danielskatz
danielskatz authored Oct 14, 2024
1 parent 846f5af commit 05bd450
Show file tree
Hide file tree
Showing 2 changed files with 20 additions and 20 deletions.
26 changes: 13 additions & 13 deletions paper/paper.bib
View file
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
@article{barbie:2024,
title = {{From Digital Twins to Digital Twin Prototypes: Concepts, Formalization, and Applications}},
title = {From Digital Twins to Digital Twin Prototypes: Concepts, Formalization, and Applications},
volume = {12},
ISSN = {2169-3536},
DOI = {10.1109/access.2024.3406510},
Expand All @@ -11,7 +11,7 @@ @article{barbie:2024
}

@article{silagecontrol:2024,
title = {{Digital Twin Prototypes for Supporting Automated Integration Testing of Smart Farming Applications}},
title = {Digital Twin Prototypes for Supporting Automated Integration Testing of Smart Farming Applications},
volume = {16},
ISSN = {2073-8994},
DOI = {10.3390/sym16020221},
Expand All @@ -29,14 +29,14 @@ @article{demomission:2020
year = {2021},
publisher = {Institute of Electrical and Electronics Engineers ({IEEE})},
author = {Alexander Barbie and Niklas Pech and Wilhelm Hasselbring and Sascha Flogel and Frank Wenzhofer and Michael Walter and Elena Shchekinova and Marc Busse and Matthias Turk and Michael Hofbauer and Stefan Sommer},
title = {{Developing an Underwater Network of Ocean Observation Systems with Digital Twin Prototypes - A Field Report from the Baltic Sea}},
title = {Developing an Underwater Network of Ocean Observation Systems with Digital Twin Prototypes - A Field Report from the {B}altic {S}ea},
journal = {{IEEE} Internet Computing}
}

@misc{ADTF:2022,
doi = {10.3289/sw_arches_core_1.0.0},
year = {2022},
publisher = {{{GEOMAR} Helmholtz Centre for Ocean Research Kiel}},
publisher = {{GEOMAR} {H}elmholtz {C}entre for {O}cean {R}esearch {K}iel},
author = {Alexander Barbie and Niklas Pech},
title = {{ARCHES Digital Twin Framework}},
note = {[Software]}
Expand All @@ -45,7 +45,7 @@ @misc{ADTF:2022
@ARTICLE{studyembeddedtesting:2018,
author={Garousi, Vahid and Felderer, Michael and Karap{\i}{\c{c}}ak, {\c{C}}a{\u{g}}r{\i} Murat and Y{\i}lmaz, U{\u{g}}ur},
journal={IEEE Software},
title={{What We Know about Testing Embedded Software}},
title={What We Know about Testing Embedded Software},
year={2018},
volume={35},
number={4},
Expand All @@ -54,7 +54,7 @@ @ARTICLE{studyembeddedtesting:2018

@MISC{empiricalstandardsgithub,
author = {Ralph, Paul and Baltes, Sebastian and Bianculli, Domenico and Dittrich, Yvonne and Felderer, Michael and Feldt, Robert and Filieri, Antonio and Furia, Carlo and Graziotin, Daniel and He, Pinjia and Hoda, Rashina and Juristo, Natalia and Kitchenham, Barbara and Robbes, Romain and Méndez Fernández, Daniel and Molleri, Jefferson and Spinellis, Diomidis and Staron, Miroslaw and Stol, Klaas-Jan and Vegas, Sira},
title = {{ACM SIGSOFT Empirical Standards on GitHub}},
title = {ACM SIGSOFT Empirical Standards on {GitHub}},
url = {https://github.com/acmsigsoft/EmpiricalStandards}
}

Expand All @@ -67,15 +67,15 @@ @article{Veneri:2020
number = {6},
pages = {907--927},
author = {M. Veneri and M. Massaro},
title = {{The effect of Ackermann steering on the performance of race cars}},
title = {The effect of {A}ckermann steering on the performance of race cars},
journal = {Vehicle System Dynamics}
}

@inproceedings{barbiepicarx:2024,
doi = {10.48550/ARXIV.2408.13866},
author = {Barbie, Alexander and Hasselbring, Wilhelm},
keywords = {Software Engineering (cs.SE), FOS: Computer and information sciences, FOS: Computer and information sciences},
title = {{Toward Reproducibility of Digital Twin Research: Exemplified with the PiCar-X}},
title = {Toward Reproducibility of Digital Twin Research: Exemplified with the {PiCar-X}},
publisher = {arXiv},
year = {2024}
}
Expand All @@ -97,12 +97,12 @@ @article{kritzinger:2018
number = {11},
pages = {1016--1022},
author = {Werner Kritzinger and Matthias Karner and Georg Traar and Jan Henjes and Wilfried Sihn},
title = {{Digital Twin in manufacturing: A categorical literature review and classification}},
title = {Digital Twin in manufacturing: A categorical literature review and classification},
journal = {{IFAC}-{PapersOnLine}}
}

@inproceedings{Eckhart:2018,
title = {{A Specification-based State Replication Approach for Digital Twins}},
title = {A Specification-based State Replication Approach for Digital Twins},
DOI = {10.1145/3264888.3264892},
booktitle = {Proceedings of the 2018 Workshop on Cyber-Physical Systems Security and PrivaCy},
publisher = {ACM},
Expand All @@ -112,7 +112,7 @@ @inproceedings{Eckhart:2018
}

@article{Russo:2023,
title = {{LiDiTE: A Full-Fledged and Featherweight Digital Twin Framework}},
title = {{LiDiTE}: A Full-Fledged and Featherweight Digital Twin Framework},
volume = {20},
ISSN = {2160-9209},
DOI = {10.1109/tdsc.2023.3236798},
Expand All @@ -126,12 +126,12 @@ @article{Russo:2023
}

@article{Fogli:2023,
title = {{Chaos Engineering for Resilience Assessment of Digital Twins}},
title = {Chaos Engineering for Resilience Assessment of Digital Twins},
ISSN = {1941-0050},
DOI = {10.1109/tii.2023.3264101},
journal = {IEEE Transactions on Industrial Informatics},
publisher = {IEEE},
author = {Fogli, Mattia and Giannelli, Carlo and Poltronieri, Filippo and Stefanelli, Cesare and Tortonesi, Mauro},
year = {2023},
pages = {1–9}
}
}
14 changes: 7 additions & 7 deletions paper/paper.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -28,20 +28,20 @@ This paper presents a digital twin prototype of the [PiCar-X by Sunfounder](http
# Statement of need
Digital twins are becoming increasingly relevant in the Industrial Internet of Things and Industry 4.0 [@kritzinger:2018], as they enhance existing capabilities for monitoring and controlling cyber-physical systems. This is achieved by integrating a digital representation of the real system in the form of a digital model. However, the concept of digital twins lacks a consensual definition and faces validation challenges, partly due to the scarcity of reproducible modules or source codes in existing studies. While many applications are described in case studies, they often lack detailed, re-usable specifications for researchers and engineers. This can lead to confusions, since modern simulations or enhanced climate models are also often praised as digital twins [@barbie:2024].

In [@barbie:2024], we formally specified a digital twin concept including its sub-concepts physical twin, digital model, digital template, digital thread, digital shadow, digital twin, and digital twin prototype using the Object-Z notation and they are the basis for this paper and the PiCar-X example. These concepts were developed for a network of ocean observation systems and the results were evaluated in a real-world mission in the Baltic sea in October 2020 [@demomission:2020]. One of the results of the successful proof-of-concept was the ARCHES Digital Twin Framework [@ADTF:2022], a software package providing the functionality to implement the digital thread between physical twins and digital twins for data and command exchange.
Ocean observation systems use quite specific and expensive hardware, hence, we see the need of a cheap lab experiment to enable independent evaluation and exploration of the different concepts. The PiCar-X example [@archespicarx:2024] is implemented based on ROS and the ARCHES Digital Twin Framework and demonstrates how the framework was used for ocean observation system. Docker Compose files facilitate the launching of the physical twin, digital model, digital shadow, digital twin, and digital twin prototype, which not only differ in the complexity of the compose files but also source code. The digital twin prototype can also be used to connect to the digital shadow or digital twin without the physical PiCar-X, enabling exploration of the communication between them and how the binary messages exchange works. Moreover, our example includes an integration test pipeline that is similar to the approach in ARCHES. In [@barbiepicarx:2024], we elaborate in more detail how the PiCar-X can be used to evaluate all these concepts and how they differ from each other in possible code implementations.
In @barbie:2024, we formally specified a digital twin concept including its sub-concepts physical twin, digital model, digital template, digital thread, digital shadow, digital twin, and digital twin prototype using the Object-Z notation; they are the basis for this paper and the PiCar-X example. These concepts were developed for a network of ocean observation systems and the results were evaluated in a real-world mission in the Baltic sea in October 2020 [@demomission:2020]. One of the results of the successful proof-of-concept was the ARCHES Digital Twin Framework [@ADTF:2022], a software package providing the functionality to implement the digital thread between physical twins and digital twins for data and command exchange.
Ocean observation systems use quite specific and expensive hardware, hence, we see the need of a cheap lab experiment to enable independent evaluation and exploration of the different concepts. The PiCar-X example [@archespicarx:2024] is implemented based on ROS and the ARCHES Digital Twin Framework and demonstrates how the framework was used for ocean observation system. Docker Compose files facilitate the launching of the physical twin, digital model, digital shadow, digital twin, and digital twin prototype, which not only differ in the complexity of the compose files but also source code. The digital twin prototype can also be used to connect to the digital shadow or digital twin without the physical PiCar-X, enabling exploration of the communication between them and how the binary messages exchange works. Moreover, our example includes an integration test pipeline that is similar to the approach in ARCHES. In @barbiepicarx:2024, we elaborate in more detail how the PiCar-X can be used to evaluate all these concepts and how they differ from each other in possible code implementations.

# Related Work
Examples of digital twin implementations based on sensor recordings or simulation data already exist, with some even providing a Docker setup [@Eckhart:2018; @Russo:2023]. @Fogli:2023 offer an abstract example involving chaos testing, which includes integration tests. However, none of these publications present an implementation of a digital twin that could be easily connected with the proposed physical twin. At the time the ARCHES PiCar-X was published, and to the best of our knowledge, no similar software packages were available that demonstrated the fundamental implementation of the various concepts from physical twin to digital twin (prototype), including automated CI/CD pipelines with actual integration tests.
Examples of digital twin implementations based on sensor recordings or simulation data already exist, with some even providing a Docker setup [@Eckhart:2018; @Russo:2023]. @Fogli:2023 offer an abstract example involving chaos testing, which includes integration tests. However, none of these publications present an implementation of a digital twin that could be easily connected with the proposed physical twin. At the time the ARCHES PiCar-X was published, to the best of our knowledge, no similar software packages were available that demonstrated the fundamental implementation of the various concepts from physical twin to digital twin (prototype), including automated CI/CD pipelines with actual integration tests.

# The PiCar-X and its Digital Twin
Lacking a consensual definition of a digital twin, the range of interpretations spans from a complex simulation to a completely mirrored status of the physical device in real-time. In our definition [@barbie:2024], the digital twin is connected to the physical twin over the entire life cycle for automated bidirectional data exchange, i.e. changes made to the digital twin lead to adapted behavior of the physical twin and vice-versa. The implementation of this capabilties can vary, with model driven approaches are being very popular [@barbie:2024]. To reduce implementation complexity and possible sources of errors, our approach for the implementation of digital twins differs from others by reusing as many software components from the physical twin as possible [@barbiepicarx:2024].
Lacking a consensual definition of a digital twin, the range of interpretations spans from a complex simulation to a completely mirrored status of the physical device in real-time. In our definition [@barbie:2024], the digital twin is connected to the physical twin over the entire life cycle for automated bidirectional data exchange, i.e., changes made to the digital twin lead to adapted behavior of the physical twin and vice-versa. The implementation of this capabilties can vary, with model driven approaches are being very popular [@barbie:2024]. To reduce implementation complexity and possible sources of errors, our approach for the implementation of digital twins differs from others by reusing as many software components from the physical twin as possible [@barbiepicarx:2024].

The PiCar-X is a toy car, see \autoref{fig:picarx-pt}, with all sensors and actuators connected to a RaspberryPi. Two direct current motors (DC motors) are used to move the car. A servo motor at the front is used to steer the car. The steering is a typical Ackermann steering [@Veneri:2020] known from common cars. The PiCar-X also includes grey-scale sensors for line following, infrared sensors for collision avoidance, and a camera. However, in the current example only the DC motors and the servo motor for steering are included, so far. All software components are implemented using the middleware ROS and are containerized using Docker. The ARCHES Digital Twin Framework establishes the digital thread between the physical twin and the digital shadow/twin [@barbiepicarx:2024].
The PiCar-X is a toy car, see \autoref{fig:picarx-pt}, with all sensors and actuators connected to a RaspberryPi. Two direct current motors (DC motors) are used to move the car. A servo motor at the front is used to steer the car. The steering is a typical Ackermann steering [@Veneri:2020] known from common cars. The PiCar-X also includes grey-scale sensors for line following, infrared sensors for collision avoidance, and a camera. However, in the current example, so far only the DC motors and the servo motor for steering are included. All software components are implemented using the middleware ROS and are containerized using Docker. The ARCHES Digital Twin Framework establishes the digital thread between the physical twin and the digital shadow/twin [@barbiepicarx:2024].

![The Picar-X by SunFounder.\label{fig:picarx-pt}](./img/picarx-pt.jpg){ width=70% }

Lacking official CAD files for the PiCar-X, we utilized a simplified CAD model of an [older SunFounder PiCar version](https://github.com/Theosakamg/PiCar_Hardware), see \autoref{fig:picarx-dm}, available under Apache 2.0 license on GitHub. This model, consisting of just the frame and wheels, closely mirrors the original PiCar-X's key dimensions like wheelbase and track, crucial for an accurate Ackermann steering simulation. However, the original PiCar-X's steering mechanism, operated by a steering bar to achieve Ackermann angles, could not be replicated in [GAZEBO](https://gazebosim.org/). Instead, we approximate the Ackermann steering angles for both front wheels based on established methodologies [@Veneri:2020].
Lacking official CAD files for the PiCar-X, we utilized a simplified CAD model of an [older SunFounder PiCar version](https://github.com/Theosakamg/PiCar_Hardware), see \autoref{fig:picarx-dm}, available under the Apache 2.0 license on GitHub. This model, consisting of just the frame and wheels, closely mirrors the original PiCar-X's key dimensions like wheelbase and track, crucial for an accurate Ackermann steering simulation. However, the original PiCar-X's steering mechanism, operated by a steering bar to achieve Ackermann angles, could not be replicated in [GAZEBO](https://gazebosim.org/). Instead, we approximate the Ackermann steering angles for both front wheels based on established methodologies [@Veneri:2020].

![The CAD model used for the PiCar-X digital model in a GAZEBO simulation.\label{fig:picarx-dm}](./img/picarx-dm.jpg){ width=70% }

Expand All @@ -51,7 +51,7 @@ We provide Docker compose files that can be used to run the software with either
Developing a physical twin typically requires connecting the hardware to a development environment. However, in such a setup, only one person can use the hardware at a time. For a team of engineers, this means either everyone needs their own PiCar-X or they must take turns, which can become costly, especially in real-world applications like full-scale vehicles.
A digital twin prototype can reduce the need for additional hardware for each team member by serving as the software counterpart of a physical twin, with identical configurations [@barbie:2024]. However, instead of physical sensors and actuators, emulators are used to mimic their functions.

The core of the digital twin prototype approach involves replacing all physical sensors and actuators with emulations or simulations, effectively virtualizing the hardware interfaces. As a result, the device driver cannot - and does not need to - distinguish between a real sensor/actuator and its emulated equivalent. The ARCHES PiCar-X uses emulators connected to a [GAZEBO](https://gazebosim.org/) simulation. The simulation provides the virtual context for the emulators, instead of using recordings from previous runs.
The core of the digital twin prototype approach involves replacing all physical sensors and actuators with emulations or simulations, effectively virtualizing the hardware interfaces. As a result, the device driver cannot, and does not need to, distinguish between a real sensor/actuator and its emulated equivalent. The ARCHES PiCar-X uses emulators connected to a [GAZEBO](https://gazebosim.org/) simulation. The simulation provides the virtual context for the emulators, instead of using recordings from previous runs.

For the PiCar-X, the primary interfaces, GPIO and I2C, are emulated using Linux kernel tools. The virtual GPIO interaction module (gpio-mockup) and the I2C chip (I2C-stub) are integrated into the container for these emulation purposes. This example also works on computers running on Windows with the Linux subsystem (WSL2). This setup provides a flexible and adaptable environment for emulating the PiCar's hardware interactions. The configuration of the digital twin prototype is illustrated in \autoref{fig:picarx-dtp}. The digital twin prototype can also be started using the provided Docker compose files.

Expand Down

0 comments on commit 05bd450

Please sign in to comment.