WGMwgm QEqe EPep PMSpms BECbec DEde

[mode = title]Towards consensus on the identity of model-based safety
assessment: A systematic analysis

[type=, auid=000,bioid=1, prefix=, role=, orcid=0000-0002-9220-1576]

[1]

url]

[style=]

[style=]

[style=]

[cor1]Corresponding author

# Characterizing the Identity of Model-based Safety Assessment: A Systematic
Analysis

Minghui Sun<EMAIL_ADDRESS>Iowa State University, Ames, 50011, Iowa,
USA  Smitha Gautham<EMAIL_ADDRESS>Carl Elks<EMAIL_ADDRESS>Virginia
Commonwealth University, Richmond, 23284, Virginia, USA  Cody Fleming
<EMAIL_ADDRESS>
###### Abstract

Model-based safety assessment has been one of the leading research thrusts of
the System Safety Engineering community for over two decades. However, there
is still a lack of consensus on what MBSA is. The ambiguity in the identity of
MBSA impedes the advancement of MBSA as an active research area. For this
reason, this paper aims to investigate the identity of MBSA to help achieve a
consensus across the community. Towards this end, we first reason about the
core activities that an MBSA approach must conduct. Second, we characterize
the core patterns in which the core activities must be conducted for an
approach to be considered MBSA. Finally, a recently published MBSA paper is
reviewed to test the effectiveness of our characterization of MBSA.

###### keywords:

MBSAfault modeling modeling language safety analysis architecture consistency

Research highlights item 1

Research highlights item 2

Research highlights item 3

##  1 Introduction

Model-based safety assessment111Sometimes also known as model-based safety
analysis. (MBSA) has been around for over two decades. The benefits of MBSA
have been well-documented in the literature, such as tackling complexity,
introducing formal methods to eliminate the ambiguity in the traditional
safety analysis, using automation to replace the error-prone manual safety
modeling process and ensuring the consistency between the design model and the
safety model [124]. We have seen a flourish of research development over the
years. Prominent modeling languages from the academic realm, such as AADL-EMV2
[95, 123, 52], AltaRica [105, 17, 109, 140], and HipHops [87, 40] are
generally considered MBSA [25]. In addition, there are a growing number of
commercial tools aimed at applying general model-based approaches to safety
analysis, such as SCADE [7], CAMET [3], MADe [139], and Medini [6]. However,
MBSA approaches are significantly dissimilar in the literature [136]. A
significant question remains: what exactly is MBSA?

There is a lack of consensus on the identity of MBSA. For example, is Formal
Methods applying to safety analysis MBSA (e.g., [48])? Are MBSA approaches
different from the general model-driven approaches applied to safety-critical
systems (e.g., [116, 5]), and if so, how? It is usually claimed that MBSA
contributes to the current literature by, for example, handling the increasing
complexity of safety-critical system, integrating different views, finding
design flaws early, reusing previously developed artifacts, introducing
automation to reduce time and cost, and structuring unstructured information.
However, these contributions can also be found in the general Model-based
Design community [132, 4, 100, 117, 34, 12, 77]. Obviously, MBSA is closely
related to all the communities above, but a question such as what makes an
approach MBSA is still left unanswered.

This ambiguity has significant implications. First, it jeopardizes the
identity of MBSA as a main research thrust of the system safety engineering
community. Without a clear definition, MBSA can quickly become a buzzword that
any discipline can claim as long as the work uses computer models and has
safety implications. Such an identity crisis impedes MBSA researchers
communicating to a broader audience (even to some safety practitioners),
promoting the significance of MBSA, and forging new breakthroughs and
synergies with the rest of the scientific communities.

Furthermore, because of the lack of consensus on the identity of MBSA, some
people equate MBSA with those high-profile modeling languages such as AADL-
EMV2 and AltaRica, or the development of new modeling languages and tools
similar to them. It is true that those modeling languages are crucial for the
success of MBSA, but one should not forget MBSA ultimately serves the overall
goal of safety assurance. Obviously, MBSA alone is insufficient to achieve
this goal. Narrowly focusing on developing new modeling languages or applying
the current modeling languages to new domains may miss other equally
significant issues and research opportunities to push MBSA forward. For MBSA
to be used effectively for safety assurance, it is imperative to address key
gaps and challenges that the safety community must address. However, before
identifying these challenges, we must first define MBSA.

Therefore, to help the safety community to eventually reach a consensus on the
identity of MBSA, this paper reasons and characterizes MBSA by answering the
following two questions:

  * •

Question 1: What is the minimal set of activities that must be conducted for
an approach to be considered MBSA? We call them the “core activities” of MBSA.

  * •

Question 2: What is the minimal set of patterns in which the core activities
must be conducted for an approach to be considered MBSA? We call them the
“core patterns” of MBSA.

##### Research method.

A common approach to investigating the identity of a research subject is
literature review. In a conventional review, papers are systematically
searched and then screened based on a set of pre-defined criteria with respect
to the scope of the subject matter. However, we do not have the privilege,
because MBSA is ill-defined. The results of such a review will be inevitably
biased towards the criteria selected. Then, to achieve a consensus, one will
have to compare one set of criteria against another, which will eventually
require an understanding of the reasoning behind the different sets of
criteria. Compared with the specific criteria selected to characterize MBSA, a
more fundamental question is how to reason about MBSA.

Therefore, our approach provides a way to reason about MBSA. We start from a
broader and better-established scope than MBSA to reason about the “general
activities” that may be conducted by an MBSA approach. After that, we refine
this scope into a minimal set of well-understood activities that an MBSA
approach must absolutely conduct (called the “core activities”). Then, we
characterize the “general patterns” in which the core activities are conducted
in the literature. Finally, we summarize a minimal set of common
characteristics of the general patterns (called the “core patterns”) that an
approach must exhibit to be considered MBSA.

Note that we do not have a “Literature Review” section in this paper because
this entire paper is presented based on reviewing and analyzing the MBSA
literature. Furthermore, although almost all MBSA literature mention their
interpretations of MBSA, these interpretations usually take an implicit stance
that characterizes MBSA only to emphasize the technical features of the
particular paper. To the best of our knowledge, there is no comprehensive
study that is specifically dedicated to the investigation of the identity of
MBSA.

##  2 The activities of MBSA

In this section, we first identify a set of general activities of MBSA. Then,
we reason about a minimal set of core activities that an MBSA approach must
conduct.

###  2.1 Model-based Design (MBD)

We start by putting MBSA in a broad scope:

_Assertion 1: MBSA is Model-based Design applied to system safety assessment._

Although it is difficult to find direct evidence to support this assertion
because there is no consensus on an exact definition of MBSA, this assertion
is consistent with [82, 1] that claim MBSA is an extension of safety analysis
to Model Based Design. More importantly, our confidence in starting from this
assertion is in its broadness, meaning we will not miss important
characteristics of MBSA by starting off with a too narrow view.

We are aware that MBD is an overloaded term. Numerous papers tried to
differentiate it from “model-driven engineering”, “model-driven design,” and
“model-driven architecture” [145, 132]. It is not our intention to define
these terms. However, we need a clear understanding of MBD to start the
reasoning of MBSA. Hence, we adopt the process proposed by [79] as the “ground
truth” of our discussion. The left of the Fig.1 is the proposed MBD process
which can be mapped to the detailed 10 steps of [79] at the right. We explain
all the involved steps in this section.

Figure 1: The MBD process. The arrows of the left can be mapped to the steps
to the right (adopted from [79]).

##### The inner loop (Step A-G).

An MBD process starts with a problem statement (Step A) which details the goal
of the design activities. The problem statement then informs the definition of
requirements such as functional requirements and safety requirements. Second,
models are derived to solve the stated problem, which corresponds to Step B, C
and D in [79]. The resulting models are a representation of the engineering
specifications that will be used to realize the actual system, hence are
called the “model of engineering specification”. Third, a modeling language is
selected to further represent the aspects under study of the model of
engineering specification such as functional, physical, safety and environment
[61], leading to an executable model (called “model of computation”, Step E)
that can be automatically computed and verified against the requirements.
Fourth, Step G closes the inner loop by automatically verifying the model of
computation against the requirements. If the verification is passed, the MBD
process proceeds to the outer loop; otherwise the model of engineering
specification must be updated until the model of computation satisfies the
requirements.

##### The outer loop (Step F-J).

Given the model of computation, specifications are derived (Step F); hardware
is constructed in accordance with the specification (Step H); software is
developed or automatically generated from the model and synthesized with the
hardware (Step I). Finally, Step J closes the outer loop. The prototype or the
actual system is built to verify against the requirements, and eventually the
resulting system is validated against the problem statement made at the
beginning of the MBD process.

As stated in Assertion 1, MBSA is MBD applied to safety assessment. Safety
assessment can happen during both the inner loop and the outer loop of MBD.
However, safety assessment often emphasizes capturing design problems early
before the software and the hardware are built, at which time correcting a
design error can be costly or even impossible [56]. We acknowledge that model-
based approach can still be useful at a later stage (e.g.,[76]), but MBSA is
nevertheless still most effective at the early stages of design. Therefore, we
refine the scope of MBSA from Assertion 1 to Assertion 2.

_Assertion 2: MBSA is the inner loop of MBD applied to safety assessment._

###  2.2 The general activities of MBSA

Next, we take a holistic view of safety assessment by applying the inner loop
of MBD to the safety assessment process (Fig.2). First, the “requirements” are
the intended function to achieve and the associated functional hazard to
avoid. Second, the “model of engineering specification” is the nominal
behavior to achieve the intended function, and the component fault or human
error that may lead to the functional hazard. Third, the “model of
computation” is the design model and the safety model to be analyzed to ensure
the safety risk associated with the functional hazard is acceptable.

Figure 2: A holistic view of safety assessment in the context of the inner
loop of MBD. Note that the generation of the intended function, the nominal
behavior, and the design model are not the tasks of the safety assessment
process, but they support the safety assessment process.

We explain in detail each activity of the safety assessment process (i.e., the
six arrows in Fig.2).

##### Functional hazard identification (Arrow 1).

Given the intended functions, Arrow 1 identifies the functional hazards.
Traditional approaches for hazard identification include, for example, Hazard
and Operability Analysis [42] and Functional Hazard Assessment [146]. More
recently, the model-based approaches are also applied to (partially) automate
the hazard identification process [73, 15, 36, 72, 81, 91, 106, 80, 74, 131].

##### Causal factors identification (Arrow 2).

After the nominal behavior is defined by the design team, Arrow 2 identifies
the casual factors that may lead to the hazard. There are two types of casual
factors: design errors of the nominal behaviors, and the component fault and
the human error that may lead to the off-nominal behaviors. Such an activity
is usually called deductive safety analysis [142], sometimes also known as
top-down [66, 37] or effect-to-cause [55] safety analysis. For example, two
well-known deductive safety techniques are Fault Tree Analysis [128] and
Systems Theoretic Process Analysis [99]. Note that the identified design
errors have to be corrected before the design can proceed to the next step.
Therefore, only the component fault and the human errors flow to the next
step.

##### Component fault and human error characterization (Arrow 3).

Arrow 3 characterizes the component faults and human errors identified by
Arrow 2. This activity requires scientific understanding about how a component
fails and/or how a person makes mistakes. Studies are available in the system
safety literature on how components fail such as [84, 147, 148, 68, 115, 123].
Similar efforts can also be found in the human factors literature on human
reliability analysis such as [110, 60].

##### Modeling language selection (Arrow 4).

Arrow 4 selects the modeling language for the safety model. We are aware that
there is a tight coupling between the modeling languages for the design model
and the safety model. But we mainly focus on the modeling language for the
safety model in this paper.

##### Safety model construction (Arrow 5).

Arrow 5 builds the safety model based on the design model. Although the
individual component faults are already characterized by Arrow 3, they still
need to be weaved together so that the resulting safety model can describe the
off-nominal behavior of the system precisely.

##### Safety analysis (Arrow 6).

Arrow 6 conducts the desired safety analysis. It verifies the design model to
ensure the nominal behavior will not lead to the functional hazard, and
analyzes the safety model to demonstrate that the safety risk associated with
the functional hazard is acceptable.

###  2.3 The core activities of MBSA

We further narrow down the scope of MBSA by identifying the core activities
that an MBSA approach must conduct.

First, the main goal of the functional hazard identification of Arrow 1 and
the casual factors identification of Arrow 2 is _to identify_ , which is
exploratory in nature, and highly relies on the subject matter experts’
knowledge. The model-based approach can provide a structured way to represent
the identified hazards and causal factors, and systematically analyze the
traceability between levels of abstraction, but not _identify_ them in the
first place. In fact, many MBSA approaches start with given hazards and/or
causal factors. Therefore, we do not consider Arrow 1 and 2 as the core
activities of MBSA.

Second, the characterization of human error of Arrow 3 has been traditionally
addressed by the human factors community. Although system safety and human
factors are closely related and there is a strong push to integrate human
error modeling into safety assessment, at least at this point, the study of
how humans make mistakes and how to model human error is still a separate
topic from safety assessment. For example, in commercial aircraft
certification, human factor (i.e., 25.1302) and system safety (i.e., 25.1309)
still mostly work in parallel. Therefore, we do not consider characterizing
human error as a core activity of MBSA.

Finally, the rest of the activities are the core activities of MBSA because no
convincing case can be made for a safety analysis without explaining all the
remaining activities no matter how narrow a view is taken for the safety
analysis. In summary, the core activities of MBSA are the component fault
characterization (Arrow 3), the modeling language selection (Arrow 4), the
safety model construction (Arrow 5), and the safety analysis (Arrow 6).

Note that we are aware that some literature disagrees with this way of
narrowing down the scope of MBSA. For example, [149] puts the functional
hazard identification under the umbrella of MBSA. However, one way to
interpret our reasoning is to flip the logic. If one activity is an core MBSA
activity, then any approach that does not conduct such activity is not MBSA.
For example, many high-profile MBSA approaches do not specify how to model
human error. If characterizing human error is a core activity, then all those
well-known MBSA approaches will be disqualified as MBSA. For this reason,
characterizing human error cannot be a core MBSA activity. The same reasoning
process can be applied to other activities. As a caveat, although certain
activities are not classified as the core activities of MBSA, that does not
mean efforts should not be made to integrate them into MBSA. Excluding them
from the core activities of MBSA is just to identify a _minimal_ scope of MBSA
to reach a broad consensus across the community.

##  3 The patterns of MBSA

In this section, we first classify the general patterns in which the core
activities are conducted in the literature. After that, we summarize a minimal
set of common characteristics of the general patterns (called the “core
patterns”) that an MBSA approach must exhibit.

###  3.1 Component fault characterization (Arrow 3 of Figure 2)

####  3.1.1 Reasoning about component faults

Avizienis’s model [10] on faults is a highly influential model in the
dependable systems literature. It depicts how a fault activates and develops.
According to Avizienis’s model, fault activation is the application of the
activation pattern to a component that causes a dormant fault to become
active. Errors are produced by an active fault. Errors propagate to the system
interface and cause the service delivered by the system to deviate from the
correct service. There are two processes in Avizienis’s model: an activation
process that leads to an active fault, and an error propagation process that
leads to the effects of the fault (i.e., the top of Fig. 3).

Another important work is Ericson’s hazard model [51] (i.e., the bottom of
Fig. 3). Ericson decomposes hazard into three elements: Hazardous Element,
Initiating Mechanism and Target/Threat, where Hazardous Element is the basic
hazardous resource creating the impetus for the hazard; Initiating Mechanism
is the trigger or initiator event(s) causing the hazard to occur through the
actualization or transformation of the hazard from a dormant state to an
active mishap state; Target/Threat is the mishap outcome and the expected
consequential damage and loss.

Figure 3: The proposed general framework of component faults, with Avizienis’s
model [10] at the top and Ericson’s model [51] at the bottom for comparison.

Inspired by both Avizienis’s model and Ericson’s model, we propose a general
framework to model component faults (i.e., the middle of Fig. 3).
Specifically, each fault is correlated with a set of casual factors, all of
which have to be present for a fault to happen or become active. Furthermore,
a fault does not necessarily lead to a failure [9] — the notion of dormancy,
which implies two mechanisms in play: one leading to the fault and the other
leading to the effect of the fault. The two mechanisms are similar to the
“occurrence pattern” and “direct effect” in [111]. We denote them as the
activation mechanism and the impact mechanism in this paper. Finally, effects
are the outcomes of the fault, and there can be multiple ways to represent the
effects of a fault. The relationship between the proposed framework and
Avizienis’s model and Ericson’s model is depicted in Fig. 3.

####  3.1.2 The general patterns of component fault characterization

We examine each element in the framework proposed in Fig. 3 and classify the
general patterns of component fault characterization in the literature.
According to [10], faults can be originated from the operational phase and
developmental phase. However, faults modeled in MBSA literature are mostly
faults at the operational phase.

##### Causal factors.

While the specific context of causal factors vary from application to
application, two perspectives are often presented in the literature about the
causal factors: (1) the location of the causes with respect to the component
boundary, and (2) the likelihood of the causes (i.e. the occurrence).

With respect to the location, there are internal causes and the external
causes [137, 24, 47, 119]. The difference between the two is self-explanatory.

Moreover, the external causes can be further classified into intended and
unintended. The intended external causes refer to the scenarios where the
intended input becomes erroneous and leads to the fault. For example, a
voltage (i.e. the input) too high can break a capacitor in the circuit.
Examples abound in the literature [21, 144]. The unintended external causes
are relatively less studied by the model-based literature. They are caused by
the effect of a fault stemming from an external component that is not supposed
to have interaction with the current component in nominal conditions. They are
called “unconnected” in [84], and “unintended interaction faults” in [10] . In
fact, many causal factors addressed in Zonal Safety Analysis and Particular
Risk Analysis [130] belong to this type, such as engine burst and
electromagnetic interference.

The occurrence of component fault can either be probabilistic or Boolean. For
the internal causal factors, the occurrence usually follows a probability
distribution. Industry has reliability dataset that records the probability
distributions of the failures of commonly used components. For the external
causal factors, probability can also be applied to describe the uncertainty
that some external causes may or may not lead the component fault. When the
causal factors are characterized with probability, both quantitative and
qualitative safety analysis can be conducted [69].

In addition, the occurrence of the component faults can also be depicted with
Boolean variables. Safety analysis based on Boolean causal factors usually
assumes the worst-case scenario and reaches conservative conclusions. Boolean
causal factors are mainly used for qualitative safety analysis.

##### Activation mechanism.

The causal factors being present is a necessary but not sufficient condition
for the fault to be present. The activation mechanism is the additional
condition (also known as “fault activation conditions” in [8]) that the causal
factors must satisfy to activate the fault. We examined the literature and
identified the following list of patterns for the activation mechanism.

  * •

Guard: The component may be vulnerable to the causal factor(s) only when it is
in certain states. For example, overcurrent can cause an electric device to
fail only when the device is on.

  * •

Sequence: The causal factors may have to happen in a certain sequence for the
fault to be activated. This is one of the main advancements of Dynamic Fault
Tree [11, 86] over the traditional FTA. In [78], the fault activation
conditions specify the input/state sequences that cause the activation of the
fault and the propagation within the system.

  * •

Delay: It may take time for a fault to happen even after the causal factors
are all present. For example, a pump overheats after no water flows in for a
certain period of time. This time period can be a deterministic one or a
probabilistic one [125]. If the fault is activated immediately after the
causal factor(s) is present, such a causal factor can usually be modelled as a
trigger event of the fault [88].

  * •

Duration: A duration may be defined to model the phenomenon that a fault can
be deactivated. A fault can disappear a certain period of time after the
activation because of its transient nature [113] or after being repaired [38].
A infinite long duration means the fault is permanent. The characterization of
the time can be deterministic, probabilistic [114] or non-deterministic as
suggested by [70].

##### Impact mechanism.

The fault being activated is a necessary but not sufficient condition for the
fault to show effects on the component. The impact mechanism is the additional
condition that needs to be satisfied for a given fault to cause the defined
effects. We examined the literature and identified the following list of
patterns for the impact mechanism.

  * •

Guard: The fault may lead to the defined effects only when the system is in
certain state. For example, loss of hydraulic supply will only affect the
ground deceleration function when the aircraft is landing. Guard condition is
widely modeled in the literature such as in state/event fault tree [88] and
AltaRica Data-flow [133].

  * •

Delay: As pointed of by [101], “the effect of a failure may not immediately
cause an output failure mode and may remain dormant”. The time between the
fault being present and the appearance of the fault effect is defined as
“Fault Tolerant Time Interval” by [63]. This delay is considered as “safety-
relevant properties” in SafeDeML [64].

  * •

Indeterminism: The exact effects of a fault may be uncertain due to either
epistemic uncertainty or aleatoric uncertainty. [31] coins it as
“probabilistic transition conditions”. A feature called “branching transition”
is provided by [53] where multiple target states can be transitioned to from
one source state following a probability distribution.

Note that guard and delay are defined in both the activation mechanism and the
impact mechanism. Sometimes, they can even be modeled with the same modeling
construct. However, they are inherently different in terms of their roles in a
component fault. It is crucial to identify them correctly when characterizing
the component faults and then model them accordingly with whatever modeling
language selected.

##### Effects on the component.

Fault effects are characterized differently in the literature. Two dimensions
are identified from the literature: the abstraction and the semantics (Table
1).

The abstraction dimension determines how many details are included in the
effect model. At the _component_ level, how the fault affects the internal
behaviors of a component is presented. At the _architecture_ level, the fault
effects are only captured at the input/output ports of a component at the
interface. In [43, 54], the former is called white box error model and the
latter is called black box error model. For the _function_ level, the
component is abstracted as a Boolean logic node; the fault sets the node to be
false, affecting all the functional flows that pass through the node. In fact,
AADL-EMV2 supports modeling at exactly all the three levels of abstraction
with a slightly different naming system [94, 46]. Modeling at different levels
of abstraction follows the safety analysis carried out (by techniques such as
FMEA and HAZOP) at various stages of the system development life cycle. At the
concept phase, the safety analysis is congruent to the level of abstraction of
the functional model. At the system level and detailed design stage, safety
analysis is congruent to the abstraction at the architecture and component
level respectively.

The semantics dimension classifies different ways to interpret the effect of a
fault. First, local effect of the fault can be interpreted as a deviation to
the intended performance of the nominal behavior. In this way, the semantics
of the _nominal_ behavior can be reused, and the global effects of the fault
can be evaluated using the same interaction paths of the nominal behavior.
Second, the local effect of a fault can also be interpreted as new off-nominal
behaviors (such as omission, commission, early and late) beyond the semantics
of the nominal behavior. Depending on how the off-nominal behaviors of
components downstream are triggered, there are two different ways to evaluate
the global effects. On one hand, the downstream off-nominal behavior can be
triggered directly by the upstream off-nominal behavior. In this case, the
safety model only includes the _off-nominal_ behavior. On the other hand, the
downstream off-nominal behavior can be modeled as a result of the interactions
between the upstream off-nominal behavior and the downstream nominal behavior.
In this case, both nominal behaviors and off-nominal behaviors are present in
the safety model (thus _integrated_).

In fact, the semantics dimension is consistent with the classification of FEM
and FLM in [102]. We classify the effect patterns of a sample pool of
literature in Table 1.

Table 1: Patterns that a sample pool of literature model the fault effects on a component. Note that some papers appear in more than one cell because the fault effects are defined at multiple levels of abstraction. Abstraction Semantics |  Nominal |  Off-nominal |  Integrated
---|---|---|---
Function |  NA |  [89, 75] |  [47, 88, 21]
Architecture |  [19, 50, 83] |  [37, 89, 54, 63, 118, 143, 151, 62, 26] |  [124, 47, 88, 21, 24, 133, 96, 152, 104]
Component |  [28, 84, 137, 33, 121] |  [63] |  [124, 47, 88, 24, 133, 96, 152]

##### Summary.

As a result, the general patterns of the component fault characterization can
be summarized in Fig.4. Note that when one identifies the fault of a component
as the external casual factor of another component, the fault propagation
between the two components will be automatically defined after the fault
effect of the upstream component and the activation mechanism of the
downstream component are defined. For this reason, we do not define a
dedicated fault propagation mechanism to avoid repetition.

Figure 4: The general patterns of component fault characterization.

###  3.2 Modeling languages selection (Arrow 4 of Figure 2)

####  3.2.1 Reasoning about how the modeling language is selected

A model in the context of MBD (Fig.1) is intended to (1) represent the
engineering solution, and (2) facilitate the desired analysis by a computer
program. As shown in Fig.5, the engineering solution specifies what _needs_ to
be represented, and the desired analysis specifies what analysis _needs_ to be
conducted. However, a specific modeling language has a limited capability of
what _can_ be represented, and what analysis _can_ be conducted. Therefore,
the modeling language must support both the modeling efforts (i.e., be fully
equipped to represent the engineering solution) and the computing efforts
(i.e., be computable by a computer program for the desired analysis), which in
fact are the two challenges observed in [58]: “the abstraction challenge” and
“the formality challenge”.

Figure 5: The modeling language must be able to fully represent the
engineering solution, and must be analyzable by a computer program for the
desired analysis.

Furthermore, the modeling efforts assign engineering meanings to the syntax of
the language, and the computing efforts map the engineering meanings (through
the syntax) into the formal semantics for compatible programs to compute.
Therefore, _engineering meaning_ and _formal semantics_ (Fig.5) are the two
inherent aspects of modeling languages in MBD. For example, a Simulink block
has a pre-defined engineering interpretation at the front end to represent
engineering components (e.g., a high-pass filter) and a formal semantics at
the back end to support the mathematical analysis. In addition, “$\int$” in an
engineering solution can be the relationship between the acceleration and the
velocity; it can also be the mathematical operation of “integral” in a
computer program. Therefore, modeling languages in MBD always have the two
aspects. Similar concepts can be found as in “pragmatic vs. formal” of [13],
and “interpretation vs. theory” of [134].

####  3.2.2 The general patterns of the modeling languages

We have identified the two aspects of a modeling language: engineering meaning
and formal semantics. Different modeling languages have different emphases.
Some focus on supporting the modeling efforts, some are designed mainly to
compute properties, and some address both. Therefore, based on how the
engineering meaning and the formal semantics are specified in a modeling
language, we classify the safety modeling languages from the literature into
the following three classes.

  * •

Modeling-oriented: Modeling languages in this class are developed mainly to
represent the system (off-nominal) behavior. Usually, no dedicated formal
semantics is specified for the language. To use these languages for safety
assessment, safety engineers have to make the computing efforts either by
designing tools from scratch, or by transforming the language to existing and
well-supported formalism (or languages), in order to conduct the desired
safety analysis, such as UML in [96], Sysml in [150, 45], HipHops in [52] and
AADL in [127, 108].

  * •

Computing-oriented: Modeling languages in this class are very close to
mathematical formalisms. The engineering concepts under study are usually
represented ad-hoc, as the mathematical objects can always be assigned with
different engineering meanings [126]. Safety engineers define the off-nominal
behavior directly using the mathematical construct such as the Interface
Automaton in [152] and Hybrid Automaton [104]. Usually, this type of modeling
languages is well-supported by existing tools for the desired safety analysis.

  * •

Comprehensive: Modeling languages in this class usually have syntax that is
associated with certain engineering meanings (e.g., error propagation), and a
formal semantics, for example, SMV [29] and Statemate [33, 121] with finite
state machine, SLIM with Event Data Automation [24], AltaRica with General
Transition System [14] and Arcade with Input/output interactive Markov chains
[21].

Five criteria are developed in [20] to qualitatively compare the effectiveness
of a modeling language in terms of the modeling efforts and the computing
efforts. In our case, the modeling-oriented languages have the best support
for the modelling efforts, but require considerable efforts to accomplish an
automatic computerized safety analysis. The computing-oriented languages have
the best support in conducting automatic safety analysis, but can be
challenging when modeling a complex system. The comprehensive languages
provide support in both modeling and computing.

###  3.3 Safety model construction (Arrow 5 of Figure 2)

####  3.3.1 Reasoning about how safety model is constructed

This activity constructs the safety model from the design model. Making sure
the safety model is consistent with the design model has always been a
challenge in the system safety community.

The design model represents the nominal behavior of a system. While how a
fault develops within a component has no logical consistency with the nominal
behavior of the component, how the fault may propagate across the system does
bear (at least partially) resemblance with the interaction path of the nominal
behavior. Such resemblance is indeed the basis for the consistency between the
design model and the safety model. Because the fault propagation path and the
nominal interaction path are usually considered as the architectures of the
safety model and the design model respectively, the consistency between the
two models can be represented as the consistency between the architectures,
which we call architecture consistency in this paper.

In other words, regardless of how the models are constructed, the architecture
consistency between the design model and the safety model must be maintained,
which is, in fact, one of the most recognized features of MBSA [85, 122, 59].
Compared to the traditional safety approaches, such as FTA, that are not
formally related to the technical architecture of the system [90], the MBSA
models represent systems with a point of view closer to their architecture
[141]. Some literature even addresses the MBSA approaches as “architecture-
based safety evaluation methodologies” [67].

####  3.3.2 The general patterns of architecture consistency

Three different ways of achieving Architecture Consistency is found in the
literature (Fig.6). This classification is an extension of the model
provenance in [102] and the ESACS project in [30, 22].

Figure 6: Different patterns that the architecture consistency is achieved in
the literature.

The first class injects faults into the design model. The off-nominal behavior
of the individual component is described by reusing the semantics of the
nominal behavior, and then is “injected” into the design model. No information
of the fault propagation paths is defined. Instead, the fault propagation
paths are generated automatically by reusing the interaction paths of the
nominal behavior, which leads to the architecture consistency of the design
model and the safety model by construction. Therefore, the architecture
consistency in this class is achieved by reusing the _nominal semantics_. A
typical example is the FSAP/NuSMV-SA language [29].

The second class extends the design model into to the safety model by reusing
the _architectural constructs_ of the design model when defining the off-
nominal behaviors of each component. Tools are usually available to ensure the
architecture consistency between the design model and the safety model through
the shared architectural constructs. Typical example is AADL- EMV2 [47] and
HiP-HOPS for EAST-ADL [40].

For the third class, the safety engineers refer the _compositional structure_
of the design model to manually create the safety model. The safety model is
organized and constructed in a compositional way [120] so that the
architecture consistency can be examined by comparing the compositional
structure of the design model and the safety model. Typical examples include
AltaRica [124], Component Fault Tree [89], Failure Propagation and
Transformation Notation [107], Fault Propagation and Transformation Calculus
[54] and State Event Fault Trees [88].

##### Observation.

From left to right in Fig.6, there is less and less support in maintaining
architecture consistency between the design model and the safety model. This
is the same argument as “model provenance” in [102] and we will not provide
further explanation here.

However, the flexibility to model complex off-nominal behaviors goes in the
opposite direction. For the “injected” class, faults are depicted as the
deviation from the nominal behavior. But it is possible that certain off-
nominal behaviors caused by the faults cannot be expressed as deviation of the
original design model. Therefore, the “injected” way to achieve architecture
consistency has limited ability to express complex off-nominal behaviors. By
contrast, both the “extended” class and the “referred” class have dedicated
semantics to represent the off-nominal behaviors, and that provides more
flexibility in describing the complex off-nominal behaviors because the safety
engineers do not have to be restricted by the nominal semantics of the design
model.

Furthermore, the off-nominal behaviors of a component usually evolve from the
nominal behaviors of the same component. The ability to depict this evolution
process will make the safety model more accurate in representing the complex
off-nominal behaviors. In this regard, the “referred” class works on a “clean
slate”, and hence has the freedom to make abstractions of the nominal behavior
when describing the evolution process aforementioned, while the “extended”
class is (at least partially) constrained by the existing design model for the
same endeavor. For this reason, the “referred” class has more flexibility than
the “extended” class in describing the complex off-nominal behaviors.
Therefore, as shown in Fig.6, from left to right, it becomes more and more
flexible to describe complex off-nominal behaviors.

In fact, architecture consistency is a type of architectural constraint on the
safety model. The weaker constraints on the architecture of the safety model,
the more flexible the safety model is able to describe complex off-nominal
behaviors, which explains the opposite directions of the “consistency” and the
“flexibility” in Fig.6.

###  3.4 Safety analysis (Arrow 6 of Figure 2)

####  3.4.1 Reasoning about how safety is analyzed

In general, safety analysis demonstrates that system behaviors satisfy
requirements. The system behaviors can be nominal or off-nominal, and the
requirements can be the functional requirements or the safety requirements. In
this way, we can derive four general types of safety analysis in Fig. 7.

Figure 7: Four types of safety analysis.

  * •

Type 1 analysis demonstrates the “goodness” of the design. The nominal
behaviors have to satisfy the functional requirements, which is the foundation
of all safety analysis.

  * •

Type 2 analysis demonstrates that the nominal behavior will satisfy the safety
requirements. For example, a series of safety assessment is conducted in [5]
to prove that all the possible trajectories of the autonomous cars are not in
conflicts by using reachability analysis.

  * •

Type 3 analysis demonstrates the “fail-operational” [135] property, i.e. the
functional requirements can still be satisfied even in the presence of
component failure. This is a subject of robustness analysis [93], a
dependability property that is closely related to safety.

  * •

Type 4 analysis demonstrates the fail-safe property, i.e., the system is still
safe even in the presence of component failure.

####  3.4.2 The general patterns of safety analysis

In this section, we provide a list of the different types of safety analysis
found in the literature. Note that only the commonly conducted safety analysis
is listed here. The less common analysis, such as the safety optimization in
[118], is not included here.

  * (1)

Fault tree analysis: This class of analysis includes the automatic generation
of fault tree, the derivation of the minimal cut sets and the calculation of
the failure rate [65]. Note that not all approaches conducts all the three
tasks. For example, [89] only mentions the generation of the fault tree; [151]
only derives the minimal cut set; [62] only addresses the failure rate
calculation for the hazard. However, because all the three activities are part
of a conventional FTA, they are all classified in the class of fault tree
analysis.

  * (2)

Failure modes and effects analysis (FMEA): This class of analysis is the
automatic generation of FMEA [2, 19].

  * (3)

Reliability Block Diagram (RBD): This class of analysis is similar with FMEA
and can be automatically accomplished, for example in [47] and [75].

  * (4)

Probabilistic indicators: This class of analysis is a broad class of analysis
for dependability, such as Reliability and Availability. We direct readers to
[10] for a detailed explanation. Example approaches that cover analysis of
probabilistic indicators include [24] and [50].

  * (5)

Property verification for nominal behavior: This class of analysis is the
formal verification of nominal behavior (e.g. [137, 83]) against the function
and/or the safety properties. It checks the “goodness” of a design, which is
the precondition for any safety analysis.

  * (6)

Property verification for off-nominal behavior: This class of analysis is the
formal verification of off-nominal behavior (e.g. [23] and [104]) against
safety properties. It rigorously checks whether certain safety constraints can
be broken under certain off-nominal conditions.

  * (7)

Critical sequence: A critical sequence is a sequence of events leading from
the initial state to a critical state. In the case of dynamic models, the
order of occurrences of events is important and thus a simple minimal cut set
is insufficient: minimal or most probable sequences or sequences of a given
length (also called order) can be extracted by simulation of the model.
Example works include [124, 96, 97, 16].

  * (8)

Trace simulation: This class of analysis is to display the traces of the
individual failure scenarios for the safety engineering to debug the model and
understand the propagation of the fault effect. It can be a step-wise
interactive simulation [133] or the trace of a given number of steps is output
at the end of the simulation [29].

  * (9)

Common cause analysis: This class of analysis is required in [130] and aims at
investigating possible dependencies between the faults and evaluates the
consequences in terms of system safety/reliability [92]. Example works include
[18, 121].

###  3.5 The core patterns of MBSA

We summarize the general patterns in which the core activities are conducted
in Table. 2. Among the general patterns, we identify in this section a minimal
set of common characteristics as the core patterns that an MBSA approach must
exhibit.

Table 2: The general patterns of MBSA. Arrow NO. | Activity | The general patterns
---|---|---
3 | Component fault characterization | Causal factor | Location | Internal, Intended, Unintended
Occurrence | Probabilistic, Boolean
Activation Mechanism | Guard, Sequence, Delay, Duration
Impact Mechanism | Guard, Delay, Indeterminism
Effect | Abstraction | Function, Architecture, Component
Semantics | Nominal, Off-nominal, Integrated
4 | Modeling languages selection | Modeling-oriented, Computing-oriented, Comprehensive
5 | Safety model construction | Architecture Consistency | Injected, Extended,Referred
6 | Safety analysis | The nine types of safety analysis

##### Component fault characterization (Arrow 3).

Almost all the literature characterizes component faults and the fault
propagation between components. Compared to the traditional approaches like
FTA and FMEA where faults are only abstracted as Boolean variables, the model-
based approaches are able to capture more sophisticated dependencies between
the components and obtain more precise analysis results [71].

##### Modeling languages selection (Arrow 4).

The commonalities between the modeling languages used in different literature
are that they all can (1) represent the component faults and (2) support
automatic safety analysis.

##### Safety model construction (Arrow 5).

Not all literature emphasizes architecture consistency between the safety
model and the design model. However, almost all the prominent approaches
implement architecture consistency as one of the key missions of MBSA.
Architecture consistency is indeed an important constraint for any safety
analysis. Therefore, we consider architecture consistency as a common practice
among the literature.

##### Safety analysis (Arrow 6)

Among the four types analysis in Fig.7, almost all the literature conduct at
least Type 4 analysis. The focus of classical safety analysis techniques lies
on supporting the reasoning of possible failures and the causal relationships
in failure events [44]. Therefore, demonstrating the system is safe in the
presence of component failure is a minimal commonality of the literature.

Therefore, the core patterns of MBSA are,

  * •

It must model component fault and fault propagation.

  * •

It must support automatic safety analysis.

  * •

It must maintain architecture consistency between the design model and the
safety model.

  * •

It must evaluate whether the system is safe in presence of component failure.

##  4 A case study

In this section, we review a recent MBSA paper [136] (addressed as the AADL
Paper ) to test the effectiveness of the characterization of MBSA in this
paper. Note that we intentionally excluded the AADL Paper when we
characterized the MBSA activities and patterns so that the results would not
be biased toward the specific practices of the AADL Paper .

##### Component fault characterization (Arrow 3).

The AADL Paper explains in its Section 3.6 how to model the individual faults
and the fault propagation between the components, which apparently satisfies
the core pattern for this activity. Specifically,

  * •

Causal factor: The AADL Paper addresses two types of causal factors. First,
they described an internal causal factor leading to “inverted_fail” with
probability $5.0\times 10^{-6}$. Second, they mentioned “a failure in one
hardware component may trigger failure in other hardware components located
nearby”, which is in fact an “unintended” external causal factor. Of note,
they also mentioned the faulty behavior of one component may lead to a
violation of the contracts of other components in the downstream components.
But it is not clear whether such a violation will cause a fault of the
downstream component. If yes, that would be an ‘intended” external causal
factor.

  * •

Activation mechanism: Not much was defined in the AADL Paper for the
activation mechanism except the “duration” of the fault.

  * •

Impact mechanism: The AADL Paper discussed different destination components
may observe different effects of the same component fault (i.e., the
asymmetric fault). This phenomenon can be easily modeled by defining
respective impact mechanisms for different destination components.
Furthermore, non-deterministic communication nodes are used to model this
phenomenon, which is also aligned with the “indeterminism” of our impact
mechanism.

  * •

Effect model: First, once a fault is activated, it “modifies the output of the
component”. Hence, the AADL Paper models the fault effects at the output port
of a component, i.e., the “architecture” at the abstraction dimension. Second,
because “the faulty behavior propagates through the nominal behavior contracts
in the system model just as in the real system”, it belongs to the “nominal”
class at the semantics dimension.

##### Modeling language selection (Arrow 4).

The AADL Paper explains in its Section 3.7 how the safety model is analyzed
formally by the model checker JKind. Apparently, the automatic safety analysis
is supported, which satisfies the core pattern of this activity.

Specifically, the AADL/AGREE language is modeling-oriented, because the
compositional nature of the modeling language makes it straightforward to
model a complex system hierarchically. In addition, to facilitate the
automatic safety analysis, the AGREE tool translates the language into Lustre,
and then to the model checker JKind. Such a series of translation steps is an
important feature of the modeling-oriented language, as explained in Section
3.2.2.

##### Safety model construction (Arrow 5).

One of the key objectives of the AADL Paper is to “support a shared model”
between the design side and the safety side. An considerable amount of efforts
were made to emphasize that faults in the AADL Paper were injected (or the
“implicit error propagation”) into the the design model. Clearly, the AADL
Paper satisfies the core pattern for this activity and achieves architecture
consistency in the “injected” way.

##### Safety analysis (Arrow 6).

It was explicitly mentioned in the AADL Paper that the safety analysis “verify
safety properties in the presence of faults”, which satisfies the core pattern
for this activity. Furthermore, the AADL Paper checked the design model
against the safety properties, generated the minimal cut set and calculated
the probability of combinations of faults, which corresponds to (1) and (5) of
the safety analysis.

##### Summary.

The AADL Paper conducts all the core activities of MBSA and exhibits all the
core patterns of MBSA. None of the non-core activities (i.e., functional
hazard identification, causal factor identification and human error
characterization) are conducted in the AADL Paper . The specific patterns in
which the AADL Paper conducts the core activities are also captured in the
general patterns characterized by our paper. The results indicate that our
characterization of MBSA is effective to reason about MBSA.

##  5 Conclusion

###  5.1 Summary

There is no consensus on the identity of MBSA, which impedes the advancement
of MBSA. We investigated the identity of MBSA in this paper. First, we
reasoned about the core activities that an MBSA approach must conduct. Second,
we characterized a set of general patterns in which the core activities are
conducted in the literature. After that, we summarized a minimal set of common
characteristics of the general patterns (i.e., the core patterns) that an
approach must exhibit to be considered MBSA. Finally, we successfully tested
the effectiveness of the proposed characterization of MBSA on a recent MBSA
paper.

We welcome other and potentially different characterizations of MBSA, as MBSA
is just a way to conduct safety analysis, and there should be no standard
approach to it. We hope this analysis of MBSA will eventually lead to a
general consensus on the identity of MBSA, promoting the advancement of MBSA
as a leading research topic in the system safety engineering community.

###  5.2 Suggestions

Over a decade ago, Lisagor observed that most of the MBSA innovation focuses
on model specification notations and/or algorithms for possible manipulations
of the models [103]. Braun [32] pointed out that the major open issue is how
to reason about the choice of models. Most recently, Sadeghi [129] made a
similar observation that “establishing the validity of the models (of MBSA) is
still a major challenge”. Our investigation concurs with all these findings
and identifies three reasons (and thus research opportunities) why there is a
lack of attention to model validity in MBSA.

##### Identifying faults.

The safety model is invalid if some of the faults that may contribute to the
hazards are missing.

Finding a complete set of fault modes for a given component is not an easy
task [112]. The combinatorial diversity of each plausible (fault) event
interacting with other set of events within and without the system makes
bottom-up analysis intractable, so experts’ knowledge of the system behavior
needs to be employed to narrow the search space of critical scenarios [147].
Traditional FTA relies on experts’ knowledge to identify the causal factors of
the failure event deductively. However, the automatic FTA [49, 41, 27] in most
MBSA approaches automates away the deductive process of the traditional FTA
without proposing a replacement. Although many MBSA approaches are supported
by formal methods, which are known for the ability of exhaustive exploration,
“if a failure mode is not even part of the formal model, then it is impossible
to reason about it” [112].

This general lack of deductive analysis in the MBSA literature is perhaps
caused by the faster advancement of formal methods than safety engineering (to
which the deductive safety analysis is almost exclusively belong). Moving
forward, it is crucial for the safety engineering community to develop new or
modify existing deductive analysis techniques to integrate with the current
MBSA approaches, so that the faults that may contribute to the hazards can be
thoroughly identified in a more systematic, tractable and efficient way.

##### Fault behavior modeling.

The safety model is invalid if some of the faults are characterized
incorrectly in the model.

Unlike other scientific communities such as aerodynamics and heat transfer
where the fundamental attributes of the subject phenomenon are well studied,
the safety community only has limited studies on the general mechanisms of how
a component fails. As a result, safety engineers decide the necessary
information to characterize a component fault in an ad-hoc way, which makes it
challenging to assure the adequacy of the fault models, especially for the
newly designed components.

Therefore, more efforts need to be made to study component faults as a
scientific phenomenon, to help safety engineers better understand the fault
behaviors under study and therefore better characterize them in the safety
model. The fault patterns characterized in Fig. 4 are our first attempt
towards this goal. They constitute a generic model of component faults, and
should be continuously improved as more literature is reviewed.

##### Hazard without failure.

The safety model is invalid if the non-failure causal factors are not
eliminated from the design model in the first place.

It has been well established that hazards can be caused by non-failure factors
[57]. However, the current MBSA practices are overwhelmingly failure-oriented.
Although EAST-ADL framework mentioned systematic faults such as design errors
[39], it is unclear from the literature how the design errors are actually
identified in the first place. Furthermore, it is also well established that
(formal) verification alone is insufficient to validate safety [35, 98]. Even
if the design model is formally verified, there is still no guarantee that the
design is free from the non-failure causal factors if certain safety-critical
scenarios are missing from the design model.

Therefore, more research is needed on how to eliminate the non-failure causal
factors from the design model. STAMP-STPA [99] is known for its ability to
address the non-failure causal factors. Based on STPA, a new approach called
STPA+ is proposed in [138] to complement MBSA specifically for the non-failure
causal factors. However, studies on this front are still rare in the safety
communities. Without demonstrating that the non-failure causal factors are
sufficiently addressed, the results of an MBSA approach still cannot be fully
trusted for safety assurance.

## References

  * Abdellatif and Holzapfel [2020] Abdellatif, A.A., Holzapfel, F., 2020\.  Model based safety analysis (mbsa) tool for avionics systems evaluation, in: 2020 AIAA/IEEE 39th Digital Avionics Systems Conference (DASC), IEEE. pp. 1–5.
  * Adedjouma and Yakymets [2019] Adedjouma, M., Yakymets, N., 2019\.  A framework for model-based dependability analysis of cyber-physical systems, in: 2019 IEEE 19th International Symposium on High Assurance Systems Engineering (HASE), IEEE.
  * AdventiumLabs [2022] AdventiumLabs, 2022.  Camet tools.  https://www.adventiumlabs.com/camet-tools#RMF.  Accessed: 2022-12-10.
  * Akdur et al. [2018] Akdur, D., Garousi, V., Demirörs, O., 2018.  A survey on modeling and model-driven engineering practices in the embedded software industry.  Journal of Systems Architecture 91, 62–82.
  * Althoff [2010] Althoff, M., 2010.  Reachability analysis and its application to the safety assessment of autonomous cars.  Diss. Technische Universität München.
  * Ansys [2022a] Ansys, 2022a.  Medini analyze: Safety & security for electronic systems.  https://www.ansys.com/products/safety-analysis/ansys-medini-analyze#tab1-3.  Accessed: 2022-12-10.
  * Ansys [2022b] Ansys, 2022b.  Scade suite: Model-based development environment for critical embedded software.  https://www.ansys.com/products/embedded-software/ansys-scade-suite.  Accessed: 2022-12-10.
  * Arlat et al. [1991] Arlat, J., Crouzet, Y., Laprie, J.C., 1991.  Fault injection for the experimental validation of fault tolerance, in: Proc. Esprit Conference’91, pp. 791–805.
  * ARP4754a [2010] ARP4754a, S.A.E., 2010.  Guidelines for development of civil aircraft and systems. 2010 .
  * Avizienis et al. [2004] Avizienis, A., Laprie, J.C., Randell, B., Landwehr, C., 2004\.  Basic concepts and taxonomy of dependable and secure computing.  IEEE transactions on dependable and secure computing 1, 11–33.
  * Bäckström et al. [2016] Bäckström, O., Butkova, Y., Hermanns, H., Krčál, J., Krčál, P., 2016.  Effective static and dynamic fault tree analysis, in: International Conference on Computer Safety, Reliability, and Security, Springer. pp. 266–280.
  * Barbieri et al. [2014] Barbieri, G., Fantuzzi, C., Borsari, R., 2014.  A model-based design methodology for the development of mechatronic systems.  Mechatronics 24, 833–843.
  * Batteux et al. [2019a] Batteux, M., Prosvirnova, T., Rauzy, A., 2019a.  Model synchronization: a formal framework for the management of heterogeneous models, in: International Symposium on Model-Based Safety and Assessment. , Cham.
  * Batteux et al. [2019b] Batteux, M., Prosvirnova, T., Rauzy, A., 2019b.  Modeling patterns for the assessment of maintenance policies with altarica 3.0, in: International Symposium on Model-Based Safety and Assessment. , Cham.
  * Beckers et al. [2013] Beckers, K., Heisel, M., Frese, T., Hatebur, D., 2013\.  A structured and model-based hazard analysis and risk assessment method for automotive systems, in: 2013 IEEE 24th International Symposium on Software Reliability Engineering (ISSRE), IEEE. pp. 238–247.
  * Beer et al. [2012] Beer, A., Kühne, U., Leitner-Fischer, F., Leue, S., Prem, R., 2012.  Analysis of an airport surveillance radar using the quantum approach .
  * Bieber et al. [2004] Bieber, P., Bougnol, C., Castel, C., Christophe Kehren, J.P.H., Metge, S., Seguin, C., 2004\.  Safety assessment with altarica, in: Building the Information Society. Springer, pp. 505–510.
  * Bittner et al. [2016] Bittner, B., Bozzano, M., Cavada, R., Cimatti, A., Gario, M., Griggio, A., Mattarei, C., Micheli, A., Zampedri, G., 2016.  The xsap safety analysis platform, in: International Conference on Tools and Algorithms for the Construction and Analysis of Systems, Springer. pp. 533–539.
  * Bonfiglio et al. [2015] Bonfiglio, V., Montecchi, L., Irrera, I., Rossi, F., Lollini, P., Bondavalli, A., 2015\.  Software faults emulation at model-level: Towards automated software fmea, in: 2015 IEEE International Conference on Dependable Systems and Networks Workshops, IEEE. pp. 133–140.
  * Boudali et al. [2008a] Boudali, H., Crouzen, P., Haverkort, B.R., Kuntz, M., Stoelinga, M., 2008a.  Arcade-a formal, extensible, model-based dependability evaluation framework, in: 13th IEEE International Conference on Engineering of Complex Computer Systems (iceccs 2008), IEEE. pp. 243–248.
  * Boudali et al. [2008b] Boudali, H., Crouzen, P., Haverkort, B.R., Kuntz, M., Stoelinga, M.I.A., 2008b.  Architectural dependability evaluation with arcade, in: 2008 IEEE International Conference on Dependable Systems and Networks With FTCS and DCC (DSN), pp. 512–521.
  * Bozzano et al. [2003a] Bozzano, M., Cavallo, A., Cifaldi, M., Valacca, L., Villafiorita, A., 2003a.  Improving safety assessment of complex systems: An industrial case study, in: International Symposium of Formal Methods Europe, Springer. pp. 208–222.
  * Bozzano et al. [2015a] Bozzano, M., Cimatti, A., Fernandes Pires, A., Jones, D., Kimberly, G., Petri, T., Robinson, R., Tonetta, S., 2015a.  Formal design and safety analysis of air6110 wheel brake system, in: International Conference on Computer Aided Verification, Springer. pp. 518–535.
  * Bozzano et al. [2011] Bozzano, M., Cimatti, A., Katoen, J.P., Nguyen, V.Y., Noll, T., Roveri, M., 2011\.  Safety, dependability and performance analysis of extended aadl models.  The Computer Journal 54, 754–775.
  * Bozzano et al. [2015b] Bozzano, M., Cimatti, A., Lisagor, O., Mattarei, C., Mover, S., Roveri, M., Tonetta, S., 2015b.  Safety assessment of altarica models via symbolic model checking.  Science of Computer Programming 98, 464–483.
  * Bozzano et al. [2014] Bozzano, M., Cimatti, A., Mattarei, C., Tonetta, S., 2014\.  Formal safety assessment via contract-based design, in: International Symposium on Automated Technology for Verification and Analysis, Springer. pp. 81–97.
  * Bozzano et al. [2007] Bozzano, M., Cimatti, A., Tapparo, F., 2007.  Symbolic fault tree analysis for reactive systems, in: International Symposium on Automated Technology for Verification and Analysis. , , Heidelberg, Springer, Berlin.
  * Bozzano and Villafiorita [2003] Bozzano, M., Villafiorita, A., 2003\.  Improving system reliability via model checking: The fsap/nusmv-sa safety analysis platform, in: International Conference on Computer Safety, Reliability, and Security. , , Heidelberg, Springer, Berlin.
  * Bozzano and Villafiorita [2007] Bozzano, M., Villafiorita, A., 2007\.  The fsap/nusmv-sa safety analysis platform.  International Journal on Software Tools for Technology Transfer 9, 1.
  * Bozzano et al. [2003b] Bozzano, M., Villafiorita, A., Åkerlund, O., Bieber, P., Bougnol, C., Böde, E., Bretschneider, M., Cavallo, A., Castel, C., Cifaldi, M., 2003b.  Esacs: an integrated methodology for design and safety analysis of complex systems, in: Proc. ESREL, Balkema publisher.
  * Braman and Murray [2009] Braman, J.M.B., Murray, R.M., 2009\.  Probabilistic safety analysis of sensor-driven hybrid automata.  Computation and Control, Hybrid Systems.
  * Braun et al. [2009] Braun, P., Philipps, J., Schätz, B., Wagner, S., 2009\.  Model-based safety-cases for software-intensive systems.  Electronic Notes in Theoretical Computer Science 238, 71–77.
  * Bretschneider et al. [2004] Bretschneider, M., Holberg, H.J., Böde, E., Brückner, I., Peikenkamp, T., Spenke, H., 2004\.  Model-based safety analysis of a flap control system, in: INCOSE International Symposium, Wiley Online Library. pp. 246–256.
  * Broy et al. [2012] Broy, M., Kirstan, S., Krcmar, H., Schätz, B., 2012\.  What is the benefit of a model-based design of embedded software systems in the car industry?, in: Emerging technologies for the evolution and maintenance of software models. IGI global, pp. 343–369.
  * Butka et al. [2015] Butka, B., Mandalapu, S., Kilgore, C., 2015.  Advanced verification methods for safety-critical airborne electronic hardware.  Federal Aviation Admlinistrtion William J. Hughes Technical Center.
  * Cancila et al. [2009] Cancila, D., Terrier, F., Belmonte, F., Dubois, H., Espinoza, H., Gérard, S., Cuccuru, A., 2009.  Sophia: a modeling language for model-based safety engineering., in: ACES-MB@ MoDELS, Citeseer.
  * Chaari et al. [2016] Chaari, M., Ecker, W., Kruse, T., Novello, C., Tabacaru, B.A., 2016.  Transformation of failure propagation models into fault trees for safety evaluation purposes, in: 2016 46th Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshop (DSN-W), IEEE. pp. 226–229.
  * Chaux et al. [2011] Chaux, P.Y., Roussel, J.M., Lesage, J.J., Deleuze, G., Bouissou, M., 2011.  Qualitative analysis of a bdmp by finite automaton.  Advances in Safety Reliability and risk management , 2055–2057.
  * Chen et al. [2011] Chen, D., Johansson, R., Lönn, H., Blom, H., Walker, M., Papadopoulos, Y., Torchiaro, S., Tagliabo, F., Sandberg, A., 2011.  Integrated safety and architecture modeling for automotive embedded systems.  e & i Elektrotechnik und Informationstechnik 128, 196–202.
  * Chen et al. [2013] Chen, D., Mahmud, N., Walker, M., Feng, L., Lönn, H., Papadopoulos, Y., 2013\.  Systems modeling with east-adl for fault tree analysis through hip-hops.  IFAC Proceedings Volumes 46, 91–96.
  * Clegg et al. [2019] Clegg, K., Li, M., Stamp, D., Grigg, A., McDermid, J., 2019\.  Integrating existing safety analyses into sysml, in: International Symposium on Model-Based Safety and Assessment, Springer. pp. 63–77.
  * Crawley and Tyler [2015] Crawley, F., Tyler, B., 2015\.  HAZOP: Guide to best practice.  Elsevier.
  * Cuenot et al. [2014] Cuenot, P., Ainhauser, C., Adler, N., Otten, S., Meurville, F., 2014.  Applying model based techniques for early safety evaluation of an automotive architecture in compliance with the iso 26262 standard, in: Embedded Real Time Software and Systems (ERTS2014).
  * Cuenot et al. [2007] Cuenot, P., Chen, D., Gérard, S., Lönn, H., Reiser, M.O., Servat, D., Kolagari, R.T., Törngren, M., Weber, M., 2007.  Towards improving dependability of automotive systems by using the east-adl architecture description language, in: Architecting dependable systems IV. Springer, pp. 39–65.
  * David et al. [2010] David, P., Idasiak, V., Kratz, F., 2010.  Reliability study of complex physical systems using sysml.  Reliability Engineering & System Safety 95, 431–450.
  * Delange and Feiler [2014] Delange, J., Feiler, P., 2014\.  Architecture fault modeling with the aadl error-model annex, in: 2014 40th EUROMICRO Conference on Software Engineering and Advanced Applications, IEEE.
  * Delange et al. [2014] Delange, J., Feiler, P., Gluch, D.P., Hudak, J., 2014\.  AADL fault modeling and analysis within an ARP4761 safety assessment.  Technical Report. CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING INST.
  * Desgeorges et al. [2021] Desgeorges, L., Piriou, P.Y., Lemattre, T., Chraibi, H., 2021\.  Formalism and semantics of pycatshoo: A simulator of distributed stochastic hybrid automata.  Reliability Engineering & System Safety 208, 107384.
  * Dickerson et al. [2018] Dickerson, C.E., Roslan, R., Ji., S., 2018.  A formal transformation method for automated fault tree generation from a uml activity model.  IEEE Transactions on Reliability 67, 1219–1236.
  * Dong et al. [2019] Dong, L., Lu, Z., Li, M., Zhou, J., 2019.  Model-based system reliability analysis by using monte carlo methods, in: 2019 Prognostics and System Health Management Conference (PHM-Qingdao), IEEE. pp. 1–6.
  * Ericson [2015] Ericson, C.A., 2015.  Hazard analysis techniques for system safety.  Wiley, John & Sons.
  * Feiler and Delange [2017] Feiler, P., Delange, J., 2017\.  Automated fault tree analysis from aadl models.  ACM SIGAda Ada Letters 36, 39–46.
  * Feiler et al. [2016] Feiler, P., Hudak, J., Delange, J., Gluch, D.P., 2016\.  Architecture Fault Modeling and Analysis with the Error Model Annex, Version 2.  Technical Report. CARNEGIE-MELLON UNIV PITTSBURGH PA PITTSBURGH United States.
  * Fenelon and McDermid [1992] Fenelon, P., McDermid, J.A., 1992\.  New directions in software safety: Causal modelling as an aid to integration, in: Workshop on Safety Case Construction, York (March 1994), Citeseer.
  * Fenelon et al. [1994] Fenelon, P., McDermid, J.A., Nicolson, M., Pumfrey, D.J., 1994\.  Towards integrated safety analysis and design.  ACM SIGAPP Applied Computing Review 2, 21–32.
  * Fleming and Leveson [2015] Fleming, C.H., Leveson, N., 2015\.  Integrating systems safety into systems engineering during concept development, in: INCOSE International Symposium, Wiley Online Library. pp. 989–1003.
  * Fleming et al. [2013] Fleming, C.H., Spencer, M., Thomas, J., Leveson, N., Wilkinson, C., 2013.  Safety assurance in nextgen and complex transportation systems.  Safety science 55, 173–187.
  * France and Rumpe [2007] France, R., Rumpe, B., 2007\.  Model-driven development of complex software: A research roadmap.  Future of Software Engineering (FOSE’0 7\.
  * Frazza et al. [2022] Frazza, C., Darfeuil, P., Gauthier, J., 2022.  Mbsa in aeronautics: A way to support safety activities, in: International Symposium on Model-Based Safety and Assessment, Springer. pp. 31–42.
  * French et al. [2011] French, S., Bedford, T., Pollard, S.J., Soane, E., 2011\.  Human reliability analysis: A critique and review for managers.  Safety science 49, 753–763.
  * Gautham et al. [2022] Gautham, S., Jayakumar, A.V., Hite, R., Deloglos, C.S., Tantawy, A., Gibson, M., Rajagopala, A.D., Elks, C., 2022\.  Model-based design assurance and verification in the context of iec-61508 sil-4 standard.  Nuclear Science and Engineering .
  * Gomes et al. [2012] Gomes, A., Mota, A., Sampaio, A., Ferri, F., Watanabe, E., 2012.  Constructive model-based analysis for safety assessment.  International Journal on Software Tools for Technology Transfer 14, 673–702.
  * Gonschorek et al. [2019a] Gonschorek, T., Bergt, P., Filax, M., Ortmeier, F., 2019a.  Integrating safety design artifacts into system development models using safedeml, in: International Symposium on Model-Based Safety and Assessment, Springer. pp. 93–106.
  * Gonschorek et al. [2019b] Gonschorek, T., Bergt, P., Filax, M., Ortmeier, F., Hoyningen-Hüne, J.v., Piper, T., 2019b.  Safedeml: On integrating the safety design into the system model, in: International Conference on Computer Safety, Reliability, and Security, Springer. pp. 271–285.
  * Gradel et al. [2022] Gradel, S., Aigner, B., Stumpf, E., 2022.  Model-based safety assessment for conceptual aircraft systems design.  CEAS Aeronautical Journal 13, 281–294.
  * Grigoleit et al. [2016] Grigoleit, F., Holei, S., Pleuß, A., Reiser, R., Rhein, J., Struss, P., Wedel, J.v., 2016.  The qsafe project–developing a model-based tool for current practice in functional safety analysis .
  * Grunske and Han [2008] Grunske, L., Han, J., 2008.  A comparative study into architecture-based safety evaluation methodologies using aadl’s error annex and failure propagation models 2008, 11.
  * Guangyan et al. [2010] Guangyan, Z., Rui, K., Yufeng, S., Gang, Z., 2010\.  System fault behavior model considering the effects of structural factors and method of its description, in: 2010 Third International Conference on Dependability, IEEE. pp. 118–124.
  * Gudemann and Ortmeier [2010] Gudemann, M., Ortmeier, F., 2010\.  A framework for qualitative and quantitative formal model-based safety analysis, in: 2010 IEEE 12th International Symposium on High Assurance Systems Engineering, IEEE.
  * Güdemann and Ortmeier [2010a] Güdemann, M., Ortmeier, F., 2010a.  Probabilistic model-based safety analysis.  arXiv preprint arXiv:1006.5101 .
  * Güdemann and Ortmeier [2010b] Güdemann, M., Ortmeier, F., 2010b.  Quantitative model-based safety analysis: A case study.  Sicherheit 2010. Sicherheit, Schutz und Zuverlässigkeit .
  * Guiochet [2016] Guiochet, J., 2016.  Hazard analysis of human–robot interactions with hazop–uml.  Safety science 84, 225–237.
  * Habli et al. [2009] Habli, I., Kelly, T., Paige, R., 2009.  Functional hazard assessment in product-lines–a model-based approach, in: MDPLE’2009 1st International Workshop on Model-Driven Product Line Engineering CTIT PROCEEDINGS, p. 26.
  * Haider [2020] Haider, S., 2020.  Applying model based safety assessment for aircraft landing gear system certification, in: 2020 Annual Reliability and Maintainability Symposium (RAMS), pp. 1–7.
  * Helle [2012] Helle, P., 2012.  Automatic sysml-based safety analysis, in: Proceedings of the 5th International Workshop on Model Based Architecting and Construction of Embedded Systems.
  * Henderson et al. [2016] Henderson, R., Hussain, G., Stecki, J., 2016.  Model based approach to zonal safety analysis, in: PHM Society European Conference.
  * Jayakumar [2020] Jayakumar, A.V., 2020.  Systematic model-based design assurance and property-based fault injection for safety critical digital systems.  Master’s thesis. Virginia Commonwealth University.
  * Jayakumar and Elks [2020] Jayakumar, A.V., Elks, C., 2020\.  Property-based fault injection: A novel approach to model-based fault injection for safety critical systems, in: International Symposium on Model-Based Safety and Assessment, Springer. pp. 115–129.
  * Jensen et al. [2011] Jensen, J.C., Chang, D.H., Lee, E.A., 2011.  A model-based design methodology for cyber-physical systems 2011, 7th International Wireless Communications and Mobile Computing Conference. IEEE.
  * Jiang et al. [2020] Jiang, Y., Bai, N., Yang, H., Zhang, H., Wang, Z., Liu, X., 2020.  Mbse-based functional hazard assessment of civil aircraft braking system, in: 2020 5th International Conference on Mechanical, Control and Computer Engineering (ICMCCE), IEEE. pp. 460–464.
  * Johannessen et al. [2001] Johannessen, P., Grante, C., Alminger, A., Eklund, U., Torin, J., 2001.  Hazard analysis in object oriented design of dependable systems, in: 2001 International Conference on Dependable Systems and Networks, IEEE. pp. 507–512.
  * Joshi et al. [2006] Joshi, A., Heimdahl, M.P., Miller, S.P., Whalen, M.W., 2006\.  Model-based safety analysis.  Technical Report.
  * Joshi and Heimdahl [2005] Joshi, A., Heimdahl, M.P.E., 2005\.  Model-based safety analysis of simulink models using scade design verifier, in: International Conference on Computer Safety, Reliability, and Security, Springer, Berlin.
  * Joshi and Heimdahl [2007] Joshi, A., Heimdahl, M.P.E., 2007\.  Behavioral fault modeling for model-based safety analysis 10th IEEE High Assurance Systems Engineering Symposium (HASE’07). IEEE.
  * Joshi et al. [2005] Joshi, A., Miller, S.P., Whalen, M., Heimdahl, M.P., 2005\.  A proposal for model-based safety analysis, in: 24th Digital Avionics Systems Conference, IEEE. pp. 13–pp.
  * Junges et al. [2016] Junges, S., Guck, D., Katoen, J.P., Stoelinga, M., 2016\.  Uncovering dynamic fault trees, in: 2016 46th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), IEEE. pp. 299–310.
  * Kabir et al. [2019] Kabir, S., Aslansefat, K., Sorokos, I., Papadopoulos, Y., Gheraibia, Y., 2019.  A conceptual framework to incorporate complex basic events in hip-hops, in: International Symposium on Model-Based Safety and Assessment, Springer. pp. 109–124.
  * Kaiser et al. [2007] Kaiser, B., Gramlich, C., F”orster, M., 2007.  State/event fault trees—a safety analysis model for software-controlled systems.  Reliability Engineering & System Safety 92, 1521–1537.
  * Kaiser et al. [2003] Kaiser, B., Liggesmeyer, P., M”ackel, O., 2003.  A new component concept for fault trees, in: Proceedings of the 8th Australian workshop on Safety critical systems and software-Volume 33.
  * Kaiser et al. [2018] Kaiser, B., Schneider, D., Adler, R., Domis, D., Möhrle, F., Berres, A., Zeller, M., Höfig, K., Rothfelder, M., 2018.  Advances in component fault trees, in: Safety and Reliability–Safe Societies in a Changing World. CRC Press, pp. 815–823.
  * Kaleeswaran et al. [2019] Kaleeswaran, A.P., Munk, P., Sarkic, S., Vogel, T., Nordmann, A., 2019.  A domain specific language to support hazop studies of sysml models, in: International Symposium on Model-Based Safety and Assessment, Springer. pp. 47–62.
  * Kessler [2019] Kessler, F.B., 2019.  “xSAP User Manual”.
  * Krach [2017] Krach, S.D., 2017.  Model-based architecture robustness analysis for software-intensive autonomous systems, in: 2017 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW), IEEE.
  * Kushal et al. [2017] Kushal, K.S., Nanda, M., Jayanthi, J., 2017.  Architecture level safety analyses for safety-critical systems.  International Journal of Aerospace Engineering 2017\.
  * Larson et al. [2013] Larson, B., Hatcliff, J., Fowler, K., Delange, J., 2013\.  Illustrating the aadl error modeling annex (v. 2) using a simple safety-critical medical device.  ACM SIGAda Ada Letters 33, 65–84.
  * Leitner-Fischer and Leue [2011a] Leitner-Fischer, F., Leue, S., 2011a.  Quantitative analysis of uml models, in: Dagstuhl, G.. (Ed.), Proceedings of Modellbasierte Entwicklung eingebetteter Systeme (MBEES 2011).
  * Leitner-Fischer and Leue [2011b] Leitner-Fischer, F., Leue, S., 2011b.  QuantUM: Quantitative safety analysis of UML models.  preprint. arXiv.  arXiv:1107.1198.
  * Leveson [2020] Leveson, N., 2020.  Are you sure your software will not kill anyone?  Communications of the ACM 63, 25--28.
  * Leveson [2016] Leveson, N.G., 2016.  Engineering a safer world: Systems thinking applied to safety.  The MIT Press.
  * Liebel et al. [2014] Liebel, G., Marko, N., Tichy, M., Leitner, A., Hansson, J., 2014.  Assessing the state-of-practice of model-based engineering in the embedded systems domain, in: International conference on model driven engineering languages and systems, Springer. pp. 166--182.
  * Lisagor [2010] Lisagor, O., 2010.  Failure logic modelling: a pragmatic approach.  Diss. University of York.
  * Lisagor et al. [2011] Lisagor, O., Kelly, T., Niu, R., 2011.  Model-based safety assessment: Review of the discipline and its challenges, in: The Proceedings of 2011 9th International Conference on Reliability, Maintainability and Safety. IEEE.
  * Lisagor et al. [2010] Lisagor, O., Sun, L., Kelly, T., 2010.  The illusion of method: Challenges of model-based safety assessment 28th international system safety conference (ISSC). System Safety Society.
  * Liu et al. [2012] Liu, J., Tang, T., Zhao, L., Xu, T., Zheng, W., 2012\.  Functional safety analysis method for ctcs level 3 based on hybrid automata, in: 2012 IEEE 15th International Symposium on Object/Component/Service-Oriented Real-Time Distributed Computing Workshops, IEEE. pp. 7--12.
  * Machin et al. [2019] Machin, M., Saez, E., Virelizier, P., Bossoreille, X.d., 2019\.  Modeling functional allocation in altarica to support mbse/mbsa consistency, in: International Symposium on Model-Based Safety and Assessment, Springer. pp. 3--17.
  * Maitrehenry et al. [2011] Maitrehenry, S., Metge, S., Bieber, P., Ait-Ameur, Y., 2011\.  Toward model-based functional hazard assessment at aircraft level.  Advances in Safety, Reliability and Risk Management: ESREL 2011 , 390.
  * McDermid et al. [1995] McDermid, J.A., Nicholson, M., Pumfrey, D.J., Fenelon, P., 1995\.  Experience with the application of hazop to computer-based systems, in: COMPASS’95 Proceedings of the Tenth Annual Conference on Computer Assurance Systems Integrity, Software Safety and Process Security’, IEEE. pp. 37--48.
  * Mokos et al. [2010] Mokos, K., Meditskos, G., Katsaros, P., Bassiliades, N., Vasiliades, V., 2010.  Ontology-based model driven engineering for safety verification, in: 2010 36th EUROMICRO Conference on Software Engineering and Advanced Applications, IEEE. pp. 47--54.
  * Mortada et al. [2014] Mortada, H., Prosvirnova, T., Rauzy, A., 2014.  Safety assessment of an electrical system with altarica 3.0, in: International Symposium on Model-Based Safety and Assessmemt. , Cham.
  * Mosleh and Chang [2004] Mosleh, A., Chang, Y., 2004\.  Model-based human reliability analysis: prospects and requirements.  Reliability Engineering & System Safety 83, 241--253.
  * Ortmeier et al. [2007] Ortmeier, F., G"udemann, M., Reif, W., 2007.  Formal failure models.  IFAC Proceedings 40, 145--150.
  * Ortmeier and Reif [2004] Ortmeier, F., Reif, W., 2004\.  Failure-sensitive specification: A formal method for finding failure modes .
  * Ortmeier et al. [2005a] Ortmeier, F., Reif, W., Schellhorn, G., 2005a.  Deductive cause-consequence analysis (dcca).  IFAC Proceedings 38, 62--67.
  * Ortmeier et al. [2005b] Ortmeier, F., Reif, W., Schellhorn, G., 2005b.  Formal safety analysis of a radio-based railroad crossing using deductive cause-consequence analysis (dcca), in: European Dependable Computing Conference, Springer. pp. 210--224.
  * O’Halloran et al. [2014] O’Halloran, B.M., Haley, B., Jensen, D.C., Arlitt, R., Tumer, I.Y., Stone, R.B., 2014\.  The early implementation of failure modes into existing component model libraries.  Research in Engineering Design 25, 203--221.
  * Pajic et al. [2012] Pajic, M., Mangharam, R., Sokolsky, O., Arney, D., Goldman, J., Lee, I., 2012\.  Model-driven safety analysis of closed-loop medical systems.  IEEE Transactions on Industrial Informatics 10, 3--16.
  * Panesar-Walawege et al. [2013] Panesar-Walawege, R.K., Sabetzadeh, M., Briand, L., 2013.  Supporting the verification of compliance to safety standards via model-driven engineering: Approach, tool-support and empirical validation.  Information and Software Technology 55, 836--864.
  * Papadopoulos [2013] Papadopoulos, Y., 2013.  Hip-hops automated fault tree, fmea and optimisation tool-user manual.
  * Papadopoulos and McDermid [1999] Papadopoulos, Y., McDermid, J.A., 1999\.  Hierarchically performed hazard origin and propagation studies, in: International Conference on Computer Safety, Reliability, and Security. , , Heidelberg, Springer, Berlin.
  * Parker et al. [2013] Parker, D., Walker, M., Papadopoulos, Y., 2013.  Model-based functional safety analysis and architecture optimisation.  Embedded Computing Systems: Applications, Optimization, and Advanced Design , 79--92.
  * Peikenkamp et al. [2006] Peikenkamp, T., Cavallo, A., Valacca, L., Böde, E., Pretzer, M., Hahn, E.M., 2006\.  Towards a unified model-based safety assessment, in: International Conference on Computer Safety, Reliability, and Security, Springer. pp. 275--288.
  * Piriou et al. [2014] Piriou, P.Y., Faure, J.M., Lesage, J.J., 2014.  Control-in-the-loop model based safety analysis, in: Proc. 24th European Safety & Reliability Conference (ESREL’14), Wroclaw (Poland), pp. 655--662.
  * Procter and Feiler [2020] Procter, S., Feiler, P., 2020\.  The aadl error library: An operationalized taxonomy of system errors.  ACM SIGAda Ada Letters 39, 63--70.
  * Prosvirnova [2014] Prosvirnova, T., 2014.  AltaRica 3.0: a model-based approach for safety analyses.  Diss.
  * Prosvirnova et al. [2013] Prosvirnova, T., Batteux, M., Brameret, P.A., Cherfi, A., Friedlhuber, T., Roussel, J.M., Rauzy, A., 2013.  The altarica 3.0 project for model-based safety assessment.  IFAC Proceedings Volumes 46, 127--132.
  * Rauzy and Haskins [2019] Rauzy, A.B., Haskins, C., 2019\.  Foundations for model-based systems engineering and model-based safety assessment.  Systems Engineering 22, 146--155.
  * Rugina et al. [2007] Rugina, A.E., Kanoun, K., Kaâniche, M., 2007.  A system dependability modeling framework using aadl and gspns, in: Architecting Dependable Systems IV. , , Heidelberg. Springer, Berlin, pp. 14--38.
  * Ruijters and Stoelinga [2015] Ruijters, E., Stoelinga, M., 2015\.  Fault tree analysis: A survey of the state-of-the-art in modeling, analysis and tools.  Computer science review 15, 29--62.
  * Sadeghi and Goerlandt [2021] Sadeghi, R., Goerlandt, F., 2021\.  The state of the practice in validation of model-based safety analysis in socio-technical systems: An empirical study.  Safety 7, 72.
  * SAE [1996] SAE, 1996.  Guidelines and Methods for Conducting the Safety Assessment Process on Airborne Systems and Equipment.  The Engineering Society for Advancing Mobility Land Sea Air and Space, USA.
  * Savelev et al. [2021] Savelev, A.S., Bersutskaya, O.D., Silin, N.D., Neretin, E.S., 2021\.  Development of failure modes and effects analysis methodology using model-based safety assessment approach.  Journal of Physics: Conference Series 1958, 012033.  doi:10.1088/1742-6596/1958/1/012033.
  * Scippacercola [2016] Scippacercola, F., 2016.  “A Model-Driven Methodology for Critical Systems Engineering.”.
  * Seguin et al. [2004] Seguin, C., Bieber, P., Castel, C., Kehren, C., 2004\.  Formal assessment techniques for embedded safety critical system, in: 18th IFIP World Computer Congress, Topical Day on New Methods for Avionics Certification.
  * Seidewitz [2003] Seidewitz, E., 2003.  What models mean.  IEEE software 20, 26--32.
  * Sinha [2011] Sinha, P., 2011.  Architectural design and reliability analysis of a fail-operational brake-by-wire system from iso 26262 perspectives.  Reliability Engineering & System Safety 96, 1349--1359.
  * Stewart et al. [2021] Stewart, D., Liu, J.J., Cofer, D., Heimdahl, M., Whalen, M.W., Peterson, M., 2021\.  Aadl-based safety analysis using formal methods applied to aircraft digital systems.  Reliability Engineering & System Safety 213, 107649.
  * Stewart et al. [2017] Stewart, D., Whalen, M.W., Cofer, D., Heimdahl, M.P., 2017\.  Architectural modeling and analysis for safety engineering, in: International Symposium on Model-Based Safety and Assessment, Springer. pp. 97--111.
  * Sun and Fleming [2022] Sun, M., Fleming, C.H., 2022\.  A new safety-guided design methodology to complement model-based safety analysis for safety assurance.  arXiv preprint arXiv:2205.00152 .
  * Technology [2022] Technology, P., 2022.  Module overview – made safety and risk assessment.  https://www.phmtechnology.com/assets/downloads/default/MADe%20for%20SRA.pdf.  Accessed: 2022-12-10.
  * Tlig et al. [2018] Tlig, M., Machin, M., Kerneis, R., Arbaretier, E., Zhao, L., Meurville, F., Van Frank, J., 2018.  Autonomous driving system: Model based safety analysis, in: 2018 48th Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshops (DSN-W), IEEE. pp. 2--5.
  * Vidalie et al. [2022] Vidalie, J., Batteux, M., Mhenni, F., Choley, J.Y., 2022\.  Category theory framework for system engineering and safety assessment model synchronization methodologies.  Applied Sciences 12, 5880\.
  * Vilela et al. [2017] Vilela, J., Castro, J., Martins, L.E.G., Gorschek, T., 2017\.  Integration between requirements engineering and safety analysis: A systematic literature review.  Journal of Systems and Software 125, 68--92.
  * Wallace [2005] Wallace, M., 2005.  Modular architectural representation and analysis of fault propagation and transformation.  Electronic Notes in Theoretical Computer Science 141, 53--71.
  * Walter et al. [2008] Walter, M., Siegle, M., Bode, A., 2008.  Opensesame—the simple but extensive, structured availability modeling environment.  Reliability Engineering & System Safety 93, 857--873.
  * Whittle et al. [2013] Whittle, J., Hutchinson, J., Rouncefield, M., 2013.  The state of practice in model-driven engineering.  IEEE software 31, 79--85.
  * Wilkinson and Kelly [1998] Wilkinson, P., Kelly, T., 1998\.  Functional hazard analysis for highly integrated aerospace systems .
  * Wille [2019] Wille, A., 2019.  Contributions to Model-Based Safety Assessment.  Diss. Technische Universit"at M"unchen.
  * Wolforth et al. [2010] Wolforth, I., Walker, M., Papadopoulos, Y., Grunske, L., 2010\.  Capture and reuse of composable failure patterns.  International Journal of Critical Computer-Based Systems 1, 128--147.
  * Woodham et al. [2018] Woodham, K.P., Graydon, P., Borer, N.K., Papathakis, K.V., Stoia, T., Balan, C., 2018\.  Fueleap model-based system safety analysis, in: 2018 Aviation Technology, Integration, and Operations Conference, p. 3362.
  * Yakymets et al. [2015] Yakymets, N., Perin, M., Lanusse, A., 2015.  Model-driven multi-level safety analysis of critical systems 2015 Annual IEEE Systems Conference (SysCon) Proceedings. IEEE.
  * Yang and Rauzy [2019] Yang, L., Rauzy, A., 2019.  Fds-ml: A new modeling formalism for probabilistic risk and safety analyses, in: International Symposium on Model-Based Safety and Assessment. , Cham.
  * Zhao et al. [2016] Zhao, L., Thulasiraman, K., Ge, X., Niu, R., 2016.  Failure propagation modeling and analysis via system interfaces.  Mathematical Problems in Engineering 2016\.