Content uploaded by Philipp Grimmeisen
Author content
All content in this area was uploaded by Philipp Grimmeisen on Jan 22, 2024
Content may be subject to copyright.
Automated and Continuous Risk Assessment for ROS-Based
Software-Defined Robotic Systems
Philipp Grimmeisen1, Rucha Golwalkar1, Yuliang Ma1, and Andrey Morozov1
Abstract— In modern and complex production systems, the
focus is shifted toward the software part. Software-Defined
Manufacturing (SDM) and Cyber-Physical Production Systems
(CPPS) characterize this trend. SDM and CPPS enable the
concept of adaptive, flexible, and self-configuring production
systems. These software-intensive robotic systems are safety-
critical because they usually are applied in the same environ-
ments as human workers. Therefore they require a continuous
risk assessment. The uploading of a new software to the system
can change its behavior drastically and therefore, the risk
assessment needs to be redone. Key enabling technologies are
digital twins, advanced and hybrid risk models, and Model-to-
Model (M2M) transformation methods.
In this paper, we introduce a new approach to the automated
and continuous risk assessment based on Robot Operating
System (ROS) code of a software-defined robotic system. The
approach pipelines four key elements: (i) a logger that logs the
data of the digital twin, (ii) an adder algorithm that creates
risk annotated code based on the given ROS code, the output
of the logger, and the hardware description including risk data
of robot parts, (iii) an M2M transformation algorithm that
automatically generates hybrid risk models from risk-annotated
code, and (iv) OpenPRA solvers for numerical evaluation of the
generated hybrid risk models.
Keywords: Risk Assessment, Risk-Annotated Code, Hybrid
Risk Models, M2M Transformation, ROS, Software-Defined
Robotic Systems
I. INTRODUCTION
The focus of modern, dynamic, and complex production
systems is shifting toward the software part. The develop-
ment of flexible, adaptive, and self-configuring production
systems is emphasized by the concepts of Software-Defined
Anything (SDx), Software-Defined Manufacturing (SDM),
Cyber-Physical Systems (CPS), and Cyber-Physical Produc-
tion Systems (CPPS). Thus, production systems become
more efficient, cost-effective, and sustainable [1], [2], [3].
In SDx the software is solely decisive for the configuration
of system functionality. SDM is a concept derived from SDx.
SDM enables a separation of the manufacturing ecosystem
into software definition layers and physical manufacturing
layers, which allows full flexibility of production through
definition via software [4], [5]. Digital twins and model-
based systems engineering are indispensable technologies for
SDM-systems. The digital twin is a virtual representation
of a physical asset that is available at all times during the
operation and engineering process [6], [1]. The introduced
software-intensive production systems, including robotic sys-
tems, can be safety-critical because they are often deployed
1The Authors are with the Institute of Industrial Automation and
Software Engineering, University of Stuttgart, 70550 Stuttgart, Germany
first.last@ias.uni-stuttgart.de
in the same environment as human workers. Moreover, they
collaborate with human workers. They may contain moving
parts that can hurt human workers or carry substances that
are dangerous to humans, such as chemical mixtures. Thus,
they require a continuous risk assessment.
Hybrid risk assessment methods that combine event trees,
fault trees, Markov chains, and Bayesian networks can de-
scribe sophisticated failure scenarios of modern production
systems, but they need to be adjusted to update the soft-
ware. Thus, the risk assessment must be performed before
uploading any software. Advanced hybrid and highly flexible
risk models are essential. These hybrid risk models must be
automatically generated and synchronized with the current
software, digital twins, or system models. Therefore, Model-
to-Model (M2M) transformation algorithms are needed.
Contribution: This paper presents a new approach that
enables the automated and continuous risk assessment of
software-defined robotic systems using risk annotated Robot
Operating System (ROS) code. The case study on a robotic
manipulator demonstrates the applicability of the proposed
approach. The proposed pipeline is shown in Figure 1.
•Logger that analyzes the execution of ROS code and
outputs the sequence of relevant code functions and
physical robotic components that are active during the
execution of relevant functions.
•Adder that automatically extends the original ROS code
with the risk annotations based on the output of the
logger and the robotic hardware description extended
with available risk data.
•An M2M transformation algorithm from risk-annotated
code to a hybrid risk model.
•OpenPRA solvers that numerically evaluate the gener-
ated hybrid risk model.
II. STATE OF THE ART
Relevant methods from the literature are categorized into
the following sections. First, the available risk profiles and
Annexes for modeling languages are discussed. Second,
relevant model-to-model transformation methods are investi-
gated.
A. Risk Profiles and Annexes
Risk profiles enable the modeling and analysis of the
risk and reliability from different source models. In [7], the
Modeling and Analysis of Real-Time Embedded Systems
(MARTE) profile was introduced. It extends the Unified
Modeling Language (UML) with concepts for the quan-
titative analysis and modeling of embedded and real-time
systems. In [8], [9], MARTE was extended by a profile for
Dependability Analysis and Modeling (DAM). The DAM
profile can add dependability annotations to UML and derive
a stochastic Petri net model for dependability analysis. The
Architecture Analysis & Design Language (AADL) [10]
has been extended with an Error Model Annex and Hazard
Model Annex. This allows the extending of AADL models
with error models and hazard models for safety and hazard
analysis [11], [12], [13]. SysML v1 resilience profiles for
reliability analysis were introduced in [14] and [15]. In our
previous work [16], [17], [18] we used and extended the
SysML v2 RiskMetadata package [19]. The RiskMetadata
package allows the integration of reliability-related data, such
as the failure probability of parts into SysML v2 models. We
extended the RiskMetadata package with the ability to mark
redundancy.
B. Model-to-Model Transformation Methods
To adequately describe and analyze flexible software-
defined systems, M2M transformation methods that automat-
ically generate risk models are indispensable. In our previous
papers [18], [16], [17] we introduced a new method that
includes a transformation method from SysML v2 to hybrid
risk models. This enables the automated and continuous
reliability assessment based on the SysML v2 [19] models
of the digital twin.
Many research works have investigated M2M transforma-
tion methods to fault trees [20], [21], [22], [23], [24]. The
automated generation Markov chains has been the subject
of different research works [25], [26], [27], [28]. The main
difference between these works is the type of the source
model. We generate the fault trees and Markov chains from
ROS code whereas other methods use SysML v1 [29],
SysML v2, AADL, and MATLAB & Simulink. In [30] a
generation of fault trees from code was introduced. The
approach is generic and only for fault tree generation.
To the best of our knowledge, there is no risk annotation
available that allows the enhancement of ROS code with
risk-related data. None of the discussed methods support the
automated generation of hybrid risk models from ROS code.
Our approach can generate hybrid risk models from ROS
code extended with risk-annotations.
III. APPROACH
A. Overview
The new approach to automated and continuous risk
assessment of a ROS-based software-defined robotic system
is shown in Figure 1. The main contributions are highlighted
in blue. First, the logger logs data during the execution
of ROS code. The output is a log data file that lists the
components that are active during the execution of relevant
functions. This file also contains the call sequence of relevant
functions. Second, the Adder parses the log data and the
robotic hardware description including the available risk
data. The risk data includes failure probabilities of robotic
hardware components (joints, grippers, sensors, etc.) and
redundancy information (e.g. we might use redundant power
sources). The output of the Adder is a risk-annotated code,
where each identified function is annotated with a special risk
annotation block. Next, the M2M transformation algorithm
automatically generates a hybrid risk model from the risk-
annotated code. Last, the hybrid risk models are analyzed
with OpenPRA solvers. The Logger part, highlighted in
a dashed red line is ROS specific and must be adapted
for use in other programming languages. The other parts
can be easily adapted to other programming languages and
frameworks.
B. Logger
The Logger extracts relevant software functions as well
as the information about robotic components being active
during the execution of those functions. The Logger input,
could be e.g. a ROS code that controls a robotic manipulator
to pick and place a test tube as described in the case study.
The Logger outputs the log data as a text file. Listing 1 shows
the log data of the pick and place software.
1Function:init()
2ActiveComponents:gripper,electric_motor
3Function:pick_position()
4ActiveComponents:electric_motor
5Function:pick()
6ActiveComponents:gripper,electric_motor
7Function:place_position()
8ActiveComponents:electric_motor
9Function:place()
10 ActiveComponents:gripper
12 CallSequence:init(),pick_position(),pick(),
place_position(),place()
Listing 1. Generated log data of the pick-and-place software.
The Logger is written in C++. The execution of the ROS
code can be visualized on simulation tools RViz [31] and
Gazebo [32]. As soon as a new function in the ROS code
begins execution, a ROS message containing the name of
the function is published on a ROS topic. Along with the
function name, the components used during the execution of
a particular function are also published. For example, the data
related to the joints of a robotic manipulator is published to
the topic joint states. A ROS node subscribed to the relevant
topic receives the required data. This data is stored in a text
file for further analysis. The log data contains the names of
relevant executed software functions as a sequence and the
robotic components that are active during the functions.
However, the log data is not the complete data about the
system. The Logger can only identify components that are
available in the simulation and in ROS topics. In Gazebo
simulation we can extract information about the position,
velocity, and effort of the joints and gripper of a robotic
manipulator. Among others, the control system and power
supply are missing, because they are not part of the sim-
ulation and there are no ROS topics for these components
to subscribe. However, this components are required for the
risk assessment.
The Logger can be adapted to any programming language
such as Python or C and can work with ROS version 1 as
well as can be adapted to ROS2. The Logger is not hardware-
specific, we can log the data of any ROS controlled robotic
system.
Fig. 1. The proposed approach to the automated and continuous risk assessment of ROS-based software-defined robotic systems.
C. Adder
The Adder automatically generates risk-annotated code
from the log data, robotic hardware description with available
risk data, and the original code.
Hardware description with risk data: The hardware
description should contain the information about the hier-
archical architecture of the robotic system, such as parts or
components, extended with risk-related data, such as failure
probability and redundancy. It could be stored e.g., as a
SysML or text file. The robotic manipulator that we use in
our case study (see Figure 3) has the following hierarchical
architecture: The risk data such as failure probabilities and
redundancy needs to be added by experts, as shown in Figure
2.
Fig. 2. Robotic manipulator executing the pick-and-place of a test tube.
Risk-annotated code: The risk-annotation is a comment
block that can be added to any function of the software.
The syntax and structure of the risk-annotated code for
the place() function are shown in Listing 2. There are
two types of sections in this block. @Function describes
the function itself. @Component describes all components
which are active during the execution of this function. Inside
the function block (lines 6 - 9) the name of the function
and the callSequence are stored. The callSequence gives us
information at which position in the code the function is
executed. The component block defines the risk data related
to each component. There will be one component block for
each component that is active inside the function. Component
blocks (lines 10 - 27) contain the name, probability of
failure (probability [0;1]), quantity, and redundancy {true,
false}of the corresponding component. In this paper, we
consider only classical redundancy (a spare component that
takes over if the primary is failed), such as the redundant
control system (lines 16 - 21). However, in a similar way,
we can add other risk-related features such as N-modular
redundancy, error detection, hot and cold spares, and other
fault tolerance techniques [33]. The risk-annotation can be
adapted to other programming languages, such as Python,
Java, or C. It is editable, which allows engineers to make
changes or additions like new components, updating the
probability of failure, etc.
The Adder algorithm has the following steps:
1) Parsing the log data and robotic hardware description.
2) Storing retrieved information; risk-related data, func-
tions call sequence, and active components during each
function.
3) Searching for the functions from call sequence list in
the original code.
4) Creating and adding of the risk-annotations.
5) Repeat steps 3 - 4 until the end of the code.
6) Output the risk-annotated code.
D. M2M Transformation Method
The M2M transformation method parses the risk-annotated
code and searches for the risk-annotations. The transfor-
mation algorithm reads and stores all provided information
about the functions, components, and respective risk-related
data. Then, the M2M transformation algorithm creates a fault
tree for each identified function. The fault tree contains all
the components as basic events, which are used in the func-
tion. The top event is the failure of the function modeled as
an OR-gate. If the algorithm detects a redundant component,
it creates an AND-gate and adds the corresponding quan-
tity of the components as basic events. The transformation
method from risk-annotated code to fault trees is described
with pseudo code in Algorithm 1.
The M2M transformation algorithm stores the information
about the call sequence from the function block. Within
that, the algorithm creates a Markov chain, see Figure 4.
It creates a transient state (e.g. pick) for each function and a
corresponding absorbing failure state (e.g. pick failure). An
absorbing ”done” state is created, which serves as a success
state. The transition probability to jump from a state to the
corresponding failure state is defined by interconnected fault
trees. The probability to jump from a state (e.g. pick) to
the corresponding failure state (e.g. pick failure) is provided
by the top event probability of fault tree ft pick failure. The
transition probability to jump from a transient state (e.g. pick)
to the next transient state (e.g. place position) is calculated
as 1 - P(ft pick failure). The transformation method from
risk-annotated code to Markov chains is described with
pseudo code in Algorithm 2. The output of the transformation
algorithm is a hybrid risk model in the OpenPRA model
exchange format.
Algorithm 1 Fault tree transformation algorithm
//Step (0): Parse risk-annotated code
risk data = parse(’file’)
//Step (1): Create empty sets of events (FT.E), gates (FT.G), and relations
(FT.C)
F T.E :=∅
F T.G :=∅
F T.C :=∅
//Step(2): For each function create one FT
for function in risk data do
top event = str(function + ’ failure’)
FT.G.add(’OR’)
FT.C.add(’OR’, top event)
//Step(3): Transform components to basic events
for component in risk data do
FT.E.add(component)
//Step(4): Add redundancy
if redundancy == TRUE then
FT.G.add(’AND’)
for num components do
FT.C.add(’AND’, FT.E[component])
end for
end if
if redundancy == FALSE then
if num components >1then
FT.G.add(’OR’)
for num components do
FT.C.add(’OR’, FT.E[component])
end for
else
FT.C.add(top event, FT.E[component])
end if
end if
//Step(5): Add probabilities
for prob in components do
if prob == TRUE then
FT.E[component].add(prob)
end if
end for
end for
//Step(6): Write FT to file
write(FT)
end for
E. Risk Assessment with OpenPRA
We use the OpenPRA framework [34] for numerical
risk assessment. OpenPRA is an open-source framework,
which integrates multiple risk methods into an easy-to-use
environment. The OpenPRA integrated analysis module can
analyze hybrid risk models, such as Markov chains with
interconnected fault trees. It first solves the fault trees by
calling the fault tree analysis solver. The computed results
are added to the transitions of the Markov chain. The
Markov chain solver solves afterwards the final Markov
chain. Currently, the risk assessment method considers only
component failures. But the method will be extended with
Algorithm 2 Markov chain transformation algorithm
//Step (0): Parse risk-annotated code
risk data = parse(’file’)
//Step (1): Create empty sets of states (MC.S) and edges (MC.E)
M C.S :=∅
M C.E :=∅
for state in sequence do
//Step (2): Create state and failure state for each function
MC.S.add(state)
MC.S.add(failure state)
//Step (3): Set the edges between states and links to fault trees
MC.E.[old state].add(state)
MC.E[old state].add(link)
end for
//Step (4): Write MC to file
write MC
failure modes (e.g. loose of the picked object) and can be
used for a detailed risk assessment.
IV. CASE STUDY
A. System architecture and software
We evaluated the applicability of the introduced approach
on a real robotic manipulator. The set-up of the case study
including the robotic manipulator and a laptop that executes
ROS code is shown in Figure 3. In our experiments RViz
and Gazebo plays the role of the digital twin of the system.
The method could be extended to other digital twin imple-
mentations.
Fig. 3. Robotic manipulator executing the pick-and-place of a test tube.
The real robotic manipulator consists of a control system,
seven non-redundant electric motors, seven non-redundant
torque sensors, one power system, and a two-finger gripper.
We manually added redundancy to the control system and
power system of the robotic manipulator, to show that
our method can handle redundant components. The system
architecture is modeled by the SysML v2 formalism, see
Figure 2. We used the RiskMetadata package to extend
the system architecture with risk-related data (probability of
failure and redundancy).
The task of the robotic manipulator is to pick and place
an object. The corresponding software is implemented in
ROS. It firsts, initialises the robotic manipulator. Then, it
moves, based on predefined coordinates, to the pick position
and picks the object. Afterwards, it moves to the desired
place position and place the object there. Then, the robotic
manipulator goes in nine out of ten cases back to the initial
position and picks another object. Otherwise, the task is
finished. This operation sequence is visible in the Markov
chain in Figure 4.
B. Logger analysis
We use Linux Ubuntu 20.4 operating system that is
installed with ROS Noetic Ninjemys. The required libraries
for the digital twin of the robotic manipulator and framework
MoveIt [35] are installed so that complex motion sequences
can be implemented. We use visualization tools and simula-
tion tools such as RViz and Gazebo to visualize the actions
performed by the robotic manipulator. The ROS code to
implement the pick and place actions is executed. Intending
to extract the executed functions of the ROS code and the
components used during the execution of each function, we
added a logger to the ROS code. The final result of the
Logger is the log data containing the call sequence and a
list of used components for each function. The log data is
shown in Listing 1.
C. Risk-annotated code
The developed Adder algorithm automatically creates the
risk-annotated code from the ROS code that controls the
robotic manipulator, the Logger outputted log data, and the
robotic hardware description including risk data. Listing
2 shows the generated risk-annotated code of the place()
function. The place() function is called on the fifth position
(line 8). During the place() the control system,power system,
and gripper are used. Within the @Component block, the
probability,quantity, and redundancy are defined. The failure
probability of the power system is 6.674e−08 (line 12). The
redundancy and quantity of the power system are defined
in lines 13 - 14. We updated the failure probability of the
electric motors during the place position() function with a
higher failure probability, due to the additional weight.
1void place(moveit::planning_interface::
MoveGroupInterface& move_group)
2{
3/*******************************
4*RiskAnnotation
5*
6*@Function {
7*name = place
8*callSequence = 5
9*}
10 *@Component {
11 *name = power_system
12 *probability = 6.674e-08
13 *quantity = 2
14 *redundancy = true
15 *}
16 *@Component {
17 *name = control_system
18 *probability = 2.167e-10
19 *quantity = 2
20 *redundancy = true
21 *}
22 *@Component {
23 *name = gripper
24 *probability = 7.344e-08
25 *quantity = 1
26 *redundancy = false
27 *}
28 *******************************/
Listing 2. Except of the risk-annotated code to control the
robotic manipulator
D. Hybrid risk model
We automatically transform the risk-annotated code into
a hybrid risk model. It consists of a top-level Markov chain
with interconnected fault trees. The Markov chain is shown
in Figure 4. It contains the transient states: init,pick position,
pick,place position, and place. It also contains an absorbing
failure state for each function, e.g. pick failure, and the
absorbing done state. The transition probabilities to jump
from a transient state to the corresponding failure state
is given by the interconnected fault trees. We generate a
fault tree for each function of the code. The fault trees
include all components that are used throughout the func-
tion. The probability of failure for the associated compo-
nents is derived from the FIDES 2009 [36] and NPRD-95
[37] database. We defined the failure probabilities for one
minute of operation. In particular, we generated the fault
trees: ft init failure,ft pick position failure,ft pick failure,
ft place position failure, and ft place failure.
E. Results
We conduct the risk assessment of the hybrid risk model
with our OpenPRA framework.
TABLE I
PROBABILITY OF ABSORPTION OF THE MARKOV CH AIN.
Failure state Probability of absorption
init failure 7.38e-06
pick position failure 6.65e-06
pick failure 7.38e-06
place position failure 9.14e-06
place failure 7.34e-07
TABLE II
FAIL URE PR OBABI LITI ES OF T HE FAULT TRE ES.
Fault tree Failure probability top event
ft init failure 7.38e-07
ft pick position failure 6.65e-07
ft pick failure 7.38e-07
ft place position failure 9.15e-07
ft place failure 7.34e-08
Table I shows the probability of absorption in one of the
failure states. Starting state is the init state. The most likely
failure state to get absorbed is the place position state. Table
II presents the top event failure probabilities of the fault trees.
V. CONCLUSION
In this paper, we introduce a new method, that enables
the automated and continuous risk assessment of software-
defined robotic systems based on the software. We demon-
strate the applicability of the proposed approach using a
robotic manipulator case study.
Fig. 4. Hybrid risk model containing a Markov chain with interconnected
fault trees. The Markov chain contains one absorbing failure state for each
function and the absorbing done state. The probabilities 0.9 and 0.1 represent
the operational profile of the system. We assume that the robotic manipulator
goes in nine out of ten cases back to the initial position and picks another
object.
The novel method includes (i) a Logger that extracts log
data such as the sequence of relevant functions and compo-
nents that are active during the function from executed ROS
code, (ii) an Adder, that extends code with risk annotations
in an automated way to generate risk-annotated code. The
risk annotation is based on the output of the Logger, the
robotic hardware description including available risk data,
and the original code, (iii) An M2M transformation algorithm
from risk-annotated code to a hybrid risk model, and (iv) the
analysis with OpenPRA. The proposed method can assess the
risk of a software-defined robotic system.
The extension of the risk-annotation with more risk-related
data that include failure modes, dependencies, or error prop-
agation is possible. This will require further development
of suitable hybrid risk models, transformation algorithms,
and new solvers for OpenPRA. This will help us to describe
possible failures scenarios of modern, flexible and dynamic
production systems more precisely and therefore enable a
more meaningful risk assessment. This will be subject of
our future work.
ACKNOWLEDGMENT
This work has been partly funded by the German Federal
Ministry of Economic Affairs and Climate Action (Bun-
desministerium f¨
ur Wirtschaft und Klimaschutz, BMWK)
under the project ”Software-defined Manufacturing f¨
ur die
Fahrzeug- und Zulieferindustrie” (SDM4FZI, funding code
13IK001ZE).
REFERENCES
[1] D. Dittler, D. Braun, T. M¨
uller, V. Stegmaier, N. Jazdi, and
M. Weyrich, “A procedure for the derivation of project-specific intel-
ligent digital twin implementations in industrial automation,” Entwurf
komplexer Automatisierungssysteme (EKA): Beschreibung, Methoden,
Werkzeuge und Anwendungen, Magdeburg, 2022.
[2] K. D. Bettenhausen and S. Kowalewski, “Cyber-physical systems:
Chancen und nutzen aus sicht der automation,” VDI/VDE-Gesellschaft
Mess-und Automatisierungstechnik, pp. 9–10, 2013.
[3] J. J¨
ager, O. Sch¨
ollhammer, M. Lickefett, and T. Bauernhansl, “Ad-
vanced complexity management strategic recommendations of han-
dling the “industrie 4.0” complexity for small and medium enter-
prises,” Procedia Cirp, vol. 57, pp. 116–121, 2016.
[4] A. Lechler, O. Riedel, and D. Coupek, “Virtual representation of
physical objects for software defined manufacturing,” International
Conference on Production Research, 2017.
[5] L. Xu, L. Chen, Z. Gao, H. Moya, and W. Shi, “Reshaping the
landscape of the future: Software-defined manufacturing,” Computer,
vol. 54, no. 7, pp. 27–36, 2021.
[6] W. Kritzinger, M. Karner, G. Traar, J. Henjes, and W. Sihn, “Digital
twin in manufacturing: A categorical literature review and classifica-
tion,” IFAC-PapersOnLine, vol. 51, no. 11, pp. 1016–1022, 2018.
[7] Object Management Group (OMG), A UML profile for Modeling
and Analysis of Real Time Embedded Systems, 2007, see also URL
https://www.omg.org/spec/MARTE/.
[8] S. Bernardi, J. Merseguer, and D. C. Petriu, “A dependability profile
within marte,” Software & Systems Modeling, vol. 10, pp. 313–336,
2011.
[9] S. Bernardi, “Adding dependability analysis capabilities to the marte
profile,” pp. 736–750, 2008.
[10] P. H. Feiler, D. P. Gluch, and J. J. Hudak, “The architecture analysis
& design language (aadl): An introduction,” Carnegie-Mellon Univ
Pittsburgh PA Software Engineering Inst, Tech. Rep., 2006.
[11] X. Wei, Y. Dong, M. Yang, N. Hu, and H. Ye, “Hazard analysis for aadl
model,” in 2014 IEEE 20th International Conference on Embedded
and Real-Time Computing Systems and Applications. IEEE, 2014,
pp. 1–10.
[12] J. Delange and P. Feiler, “Architecture fault modeling with the aadl
error-model annex,” in 2014 40th EUROMICRO Conference on Soft-
ware Engineering and Advanced Applications. IEEE, 2014, pp. 361–
368.
[13] B. Larson, J. Hatcliff, K. Fowler, and J. Delange, “Illustrating the
aadl error modeling annex (v. 2) using a simple safety-critical medical
device,” ACM SIGAda Ada Letters, vol. 33, no. 3, pp. 65–84, 2013.
[14] M. Steurer, A. Morozov, K. Janschek, and K.-P. Neitzke, “Sysml-
based profile for dependable uav design,” IFAC-PapersOnLine, vol. 51,
no. 24, pp. 1067–1074, 2018.
[15] M. A. Diaconeasa, A. Mosleh, A. Morozov, and A. T. Tai, “Model-
based resilience assessment framework for autonomous systems,” in
ASME International Mechanical Engineering Congress and Exposi-
tion, vol. 83501. American Society of Mechanical Engineers, 2019,
p. V013T13A027.
[16] P. Grimmeisen, A. Morozov, T. Fabarisov, A. Wortmann, and C. H.
Koo, “Automated model-based reliability assessment of software-
defined manufacturing,” in 2022 IEEE 27th International Conference
on Emerging Technologies and Factory Automation (ETFA). IEEE,
2022, pp. 1–4.
[17] P. Grimmeisen, A. Wortmann, and A. Morozov, “Case study on
automated and continuous reliability assessment of software-defined
manufacturing based on digital twins,” in Proceedings of the 25th
International Conference on Model Driven Engineering Languages
and Systems: Companion Proceedings, 2022, pp. 511–518.
[18] P. Grimmeisen, Y. Ma, M. A. Diaconeasa, and A. Morozov, “Auto-
mated generation of hybrid probabilistic risk models from sysml v2
models of software-defined manufacturing systems,” in ASME Interna-
tional Mechanical Engineering Congress and Exposition, vol. 86717.
American Society of Mechanical Engineers, 2022, p. V009T14A031.
[19] Object Management Group (OMG), OMG Systems Modeling
Language (SysML) Version 2.0, 2021, see also URL
https://github.com/Systems-Modeling/SysML-v2-Release.
[20] F. Mhenni, N. Nguyen, and J.-Y. Choley, “Automatic fault tree gener-
ation from sysml system models,” in 2014 IEEE/ASME International
Conference on Advanced Intelligent Mechatronics. IEEE, 2014, pp.
715–720.
[21] N. Yakymets, H. Jaber, and A. Lanusse, “Model-based system en-
gineering for fault tree generation and analysis,” in International
Conference on Model-Driven Engineering and Software Development,
vol. 2. SCITEPRESS, 2013, pp. 210–214.
[22] A. Joshi, S. Vestal, and P. Binns, “Automatic generation of static fault
trees from aadl models,” 2007.
[23] Z. Zhao, “Uml model to fault tree model transformation for depend-
ability analysis,” Ph.D. dissertation, Carleton University, 2014.
[24] Y. Papadopoulos and M. Maruhn, “Model-based synthesis of fault trees
from matlab-simulink models,” in 2001 International Conference on
Dependable Systems and Networks. IEEE, 2001, pp. 77–82.
[25] A. Baouya, D. Bennouar, O. A. Mohamed, and S. Ouchani, “A
probabilistic and timed verification approach of sysml state machine
diagram,” in 2015 12th International Symposium on Programming and
Systems (ISPS). IEEE, 2015, pp. 1–9.
[26] S. Ouchani, O. A. Mohamed, and M. Debbabi, “A formal verification
framework for sysml activity diagrams,” Expert Systems with Appli-
cations, vol. 41, no. 6, pp. 2713–2728, 2014.
[27] T. Zhang, Y. Jiang, J. Ye, C. Jing, and H. Qu, “An aadl model-based
safety analysis method for flight control software,” in 2014 Interna-
tional Conference on Computational Intelligence and Communication
Networks. IEEE, 2014, pp. 1148–1152.
[28] A. Joshi and M. P. Heimdahl, “Model-based safety analysis of simulink
models using scade design verifier,” in International conference on
computer safety, reliability, and security. Springer, 2005, pp. 122–
135.
[29] M. Hause et al., “The sysml modelling language,” in Fifteenth Euro-
pean Systems Engineering Conference, vol. 9, 2006, pp. 1–12.
[30] J. M. Voas and K. W. Miller, “An automated code-based fault-
tree mitigation technique,” in Safe Comp 95: The 14th International
Conference on Computer Safety, Reliability and Security, Belgirate,
Italy 11–13 October 1995. Springer, 1995, pp. 59–72.
[31] R. Wiki, “RViz: 3d visualization tool for ROS,” http://wiki.ros.org/rviz,
accessed: March 1, 2023.
[32] Open Robotics, “Gazebo simulator,” https://gazebosim.org/home, ac-
cessed 2023.
[33] K. Ding, A. Morozov, and K. Janschek, “Classification of hierar-
chical fault-tolerant design patterns,” in 2017 IEEE 15th Intl Conf
on Dependable, Autonomic and Secure Computing, 15th Intl Conf
on Pervasive Intelligence and Computing, 3rd Intl Conf on Big
Data Intelligence and Computing and Cyber Science and Technology
Congress (DASC/PiCom/DataCom/CyberSciTech). IEEE, 2017, pp.
612–619.
[34] P. Grimmeisen, A. Karimov, M. A. Diaconeasa, and A. Morozov,
“Demonstration of a limited scope probabilistic risk assessment for
autonomous warehouse robots with openpra,” in ASME International
Mechanical Engineering Congress and Exposition, vol. 85697. Amer-
ican Society of Mechanical Engineers, 2021, p. V013T14A030.
[35] Open Source Robotics Foundation, “Moveit!” https://moveit.ros.org/,
2021, accessed: March 1, 2023.
[36] F. Group, FIDES guide 2009, Reliability Methodology for Electronic
Systems, 2010.
[37] W. Denson, G. Chandler, W. Crowell, A. Clark, and P. Jaworski,
“Nonelectronic parts reliability data 1995,” RELIABILITY ANAL-
YSIS CENTER GRIFFISS AFB NY, Tech. Rep., 1994.
