Journal Pre-proof

Andromeda: A model-connected framework for safety assessment and

assurance

Athanasios Retouniotis, Yiannis Papadopoulos, Ioannis Sorokos

PII: S0164-1212(24)00300-5
DOI: https://doi.org/10.1016/j.jss.2024.112256
Reference: JSS 112256
To appear in: The Journal of Systems & Software
Received date : 15 February 2024
Revised date : 4 October 2024
Accepted date : 8 October 2024

Please cite this article as: A. Retouniotis, Y. Papadopoulos and I. Sorokos, Andromeda: A
model-connected framework for safety assessment and assurance. The Journal of Systems &
Software (2024), doi: https://doi.org/10.1016/j.jss.2024.112256.

This is a PDF file of an article that has undergone enhancements after acceptance, such as the
addition of a cover page and metadata, and formatting for readability, but it is not yet the definitive
version of record. This version will undergo additional copyediting, typesetting and review before it
is published in its final form, but we are providing this version to give early visibility of the article.
Please note that, during the production process, errors may be discovered which could affect the
content, and all legal disclaimers that apply to the journal pertain.

© 2024 Published by Elsevier Inc.

 Journal Pre-proof

Click here to view linked References

of
Andromeda: A Model-Connected Framework for Safety
Assessment and Assurance

pro
Athanasios Retouniotisa , Yiannis Papadopoulosa , Ioannis Sorokosb
a
Dependable Intelligent Systems Group, School of Computer Science, Cottingham
Rd, Hull, HU67RX, East Riding of Yorkshire, UK
b
Safety Engineering Department, Fraunhofer IESE, Fraunhofer-Platz
1, Kaiserslautern, 67663, Rheinland-Pfalz, Germany

Abstract re-
Safety is a key factor in the development of critical systems, encompassing
both conventional types, such as aircraft, and modern technologies, such as
autonomous vehicles. Failures during their operation can be potentially far-
reaching and impact people and the environment. To certify these systems
and enable their employment, regulatory bodies require, among others, a
lP
safety case. However, the growing complexity of modern systems and itera-
tive nature of development pose significant challenges to the traditional ap-
proaches for creating safety cases that are still used in practice. Furthermore,
safety cases are often generated in an ad-hoc manner and remain disconnected
from system models and related artifacts. Without these connections it is
difficult to construct the proper infrastructure for producing and maintaining
rna

safety cases in a structured manner throughout the system lifecycle. This

paper presents our innovative method, Andromeda, and its underpinning
metamodel, which establish connections between safety cases, system mod-
els, safety assessment activities aligned with international safety standards,
and argument patterns. Automation is applied across various stages of the
production of argument structures that support safety assurance and certi-
fication activities. Andromeda is complemented by tool-support designed to
facilitate its application, and we demonstrate our work through a case study
Jou

from the aviation industry.

Keywords: Safety cases, Model-Based Assurance, Automation, Argument
Patterns

Preprint submitted to Journal of Systems & Software October 4, 2024

 Journal Pre-proof

of
1. Introduction
Technological systems are integral to the function of modern societies,
shaping humanity through its ongoing evolution. Whether in the domain of

pro
energy production, where machines oversee the generation and dissemination
of power, or in the transportation industries, such as the railway, aviation and
automotive, with sensors and mechanisms that help control the behaviour of
the vehicle, our reliance on this infrastructure is clear.
This dependence has not gone unrecognized by governments and regula-
tory bodies, which maintain regulations and standards to guide the devel-
opment and use of safety-critical systems in order to avert potential societal
hazards, acknowledging that failure of these systems could lead to catas-
re-
trophic consequences. Safety standards do not have just an advisory role but
they effectively constitute the basis of certification, which in turn ensures
that a system meets the appropriate compliance levels and is acceptably safe
to operate under a given context.
In the past, standards have been more prescriptive and assurance was
governed by a rules-based approach [1]. However, this rendered the intro-
lP
duction of novel technologies and software engineering techniques difficult
since the respective authorities were not able to formulate universally appli-
cable rules for these innovations and their fast-paced changes. In addition,
due to the check-list mentality, system developers would invest considerable
effort into meeting the specific requirements set by the standards and often
overlook valuable contextual information, potentially diminishing the quality
of the assurance artifacts submitted to the authorities [2].
rna

Consequently, the mentality shifted to a goal-based approach, where reg-

ulatory bodies set the certification goals and developers must provide explicit
safety claims, a clear and comprehensive argument along with the supporting
evidence that collectively help to meet these goals. This process, along with
work products from other tasks such as requirement specification, architec-
tural designs, testing and simulations results, are encapsulated in a series of
documents known as the safety case.
The concept of the safety case has been widely adopted in the safety-
Jou

critical sector, with industries such as the aviation, automotive and nuclear
leveraging their potential for over two decades. There are variations of the
definition of safety cases but the most prevalent is found in [3][p. 22], which
describes it as a means to “communicate a clear, comprehensive and defen-
sible argument that a system is acceptably safe to operate in a particular

2
 Journal Pre-proof

of
context”.
This argument of safety can be presented in a variety of ways but practi-
tioners tend to use graphical notations, such as the Goal Structuring Notation

pro
(GSN) [4], to compact the information and aid in the construction and re-
view processes. These notations typically include a variety of elements that
represent all the essential entities necessary for an argument structure. For
example, GSN uses rectangular shapes to depict goals (i.e. claims) or ellip-
soids for assumptions and offers a set of different arrows to connect shapes
and highlight their relationship. The practitioners are able to use these el-
ements and produce an argument structure, in the form of a tree diagram,
that explains how a goal is broken down into sub-goals and ultimately pro-

re-
vide a reference of the supporting evidence. Note that notations typically
provide rules to prevent illogical structures.
Moreover, to further facilitate the creation of argument structures, in-
spired by the concept of software design patterns, safety engineers have also
incorporated the use of patterns. Specifically, they abstract the details from
previous successful arguments and re-employ their structure in appropriate
scenarios, with the intent to facilitate the production of safety cases and
lP
improve argument consistency and robustness.
Regulatory authorities advise towards a proactive approach, in which
safety activities are initiated at the earliest stages of the development lifecy-
cle, and heavily emphasize the continuous improvement of the related pro-
cesses. This helps identify and resolve any safety issues and establish a good
safety culture [5, p. 10] [6, p. 58]. To maintain these principles, safety cases
rna

must follow the evolutionary nature of system development, requiring con-

tinuous updates that align with ongoing system changes.
Considering that the majority of evidence artifacts are generated through
safety analysis techniques and testing, coupled with the repetitive develop-
ment process, it becomes evident that this is an arduous task, particularly
when a substantial portion of the activities relies on manual processes. Even
in the instances where safety assessment is handled by supporting-tools semi-
automatically, there is considerable manual work towards the assurance and
Jou

evaluation of the safety case [7]. For example, the safety argument needs
to be adjusted as changes occur, re-evaluated to ensure that its reasoning
remains consistent, re-assessed to validate and verify its supporting safety
artifacts, as well as analysed for valuable feedback from the rest of the devel-
opment teams [8]. In addition, the volume of a safety case scales accordingly
as systems become more complex and their architecture increases in size.

3
 Journal Pre-proof

of
Thus, the construction and maintenance of safety cases is far from triv-
ial, and to avoid costs and effort, safety can sometimes be neglected during
certain stages of development [9]. However, this is inappropriate not only

pro
because safety standards recommend that safety assurance should remain
up-to-date at all times, but also because as the system model evolves, our con-
siderations and understanding of its behaviour can potentially change. For
example, with each design iteration, our understanding of undesired events,
their causes, and relevance could change drastically. This suggests that par-
ticular evidence artifacts might not be relevant anymore, invalidating the
safety claims they support. After all, part of the safety case depends on
assumptions, initial requirements and predictions, necessitating the recon-

re-
struction of the safety argument if any such changes occur.
With the emergence of contemporary intelligent systems or autonomous
vehicles the maintenance of safety cases requires even more attention, not
only during the production stages, but also during operation [10]. These
systems often employ advanced software and machine learning techniques
that allow them to evolve either to improve their performance or to respond
to changes happening in their environment. As a result, if the safety case
lP
remains static it is more likely that there will be a mismatch between the
initial assumptions and the evolving behaviour of the system. That would
effectively undermine the initial safety argument constructed during the de-
velopment lifecycle.
As already mentioned earlier, certification is governed by international
standards. For instance, ISO26262 is the major guideline for achieving func-
rna

tional safety in the automotive domain. It provides a general framework

involving a series of tasks developers should follow including the definition of
safety goals, specification and allocation of requirements, verification and val-
idation processes, and specific safety analysis techniques, such as Fault-Tree
Analysis (FTA), they could employ to assess their system.
Analysis techniques play a significant role across different stages of the
safety lifecycle. In the concept phase, engineers employ Hazard Analysis
and Risk Assessment (HARA) to identify and assess possible hazards at the
Jou

earliest opportunity. In the phase of product development at system level,

techniques like FTA and Failure Mode and Effects Analysis (FMEA) help
evaluate the effects of system-level failures. Furthermore, the ISO 26262 re-
quires the creation of a safety case that gradually captures any outcomes
generated during the safety lifecycle [6, p. 51]. Given that safety analysis
and assurance activities unfold iteratively throughout the different stages,

4
 Journal Pre-proof

of
implementing systematic processes and automation becomes essential for en-
suring that safety tasks keep pace with the development process, effectively
addressing the aforementioned challenges, and improving the safety frame-

pro
work.
The introduction of the Model-Based Safety Analysis (MBSA) paradigm
empowered engineers to link system architectures with assessment-related
activities and their outcomes [11]. Typically, methods embracing the MBSA
create an unambiguous model enriched with elements from the system ar-
chitecture, failure information and formalized properties. This is achieved
with advanced metamodeling that captures relationships between the nom-
inal and other models. Furthermore, MBSA, by harnessing the power of

re-
software-tools and combining it with (semi-)formal models, facilitated the
adoption of automation. Thus, alleviating inconsistencies between generated
safety products, induced by traditional or other manual analysis methods,
whilst staying in sync with the fast pace of modern development. Due to
these benefits, various approaches, including Andromeda, have utilised and
further expanded the concept of MBSA towards safety assessment and assur-
ance. In Sec. 5: Related Work, we will explore notable examples of MBSA
lP
applications and highlight how Andromeda relates to them highlighting areas
where it advances the state-of-the-art.
As systems become increasingly complex to improve functionality, ad-
dressing the associated challenges stemming from this complexity remains a
persistent issue. This paper elaborates on our approach to support the as-
sessment and assurance process, with the goal of integrating safety as a foun-
rna

dational element that drives system design. Andromeda tackles the afore-
mentioned challenges by identifying common elements in safety standards
and utilising them to guide safety assurance, while incorporating automa-
tion into multiple stages of the safety framework. Key contributions of the
method entail:

1. Assurance Patterns: We elicited patterns that reflect commonalities

between emerging standards and use them for the construction of safety
arguments.
Jou

2. Automated Synthesis: We automated the synthesis of safety ar-

guments from system models, safety analysis artifacts and assurance
patterns via algorithms.
3. Metamodel: We designed and implemented an abstract structure that
links system models with safety assessment and assurance processes.

5
 Journal Pre-proof

of
4. Cost-Optimal Requirement Allocation: We showcased how the
concept of abstract requirements, known within the standards as Safety
Integrity Levels (SILs), can be utilised as a means to form argument

pro
structures. We also provide a way to cost-optimally allocate them to
subsystems and components using metaheuristics.

Andromeda adheres to established safety standards, such as ARP4754-A

for the aviation and ISO 26262 for the automotive industries. It employs
automated processes to generate safety artifacts, which are then used for the
automatic generation of argument structures via argument pattern instan-
tiation. This effectively incorporates safety considerations into the system
development process and produce essential outputs required for system cer-
re-
tification. The metamodel developed to underpin our approach ensures that
analysis results, requirements and system architecture are interconnected.

1.1. Structure of the paper

Following this introduction, the rest of this paper unfolds as follows. In
Sec. 2, we present a brief summary of the essential elements related to
lP
the guidelines used for our case study. In Sec. 3 we outline an overview
of Andromeda, its underpinning metamodel, and the necessary inputs and
generated outputs. These sections help the reader familiarise themselves
with our method and grasp the basic aspects before delving into the case
study in Sec. 4. In Sec. 5, we provide information on related work and
explain how our approach sets itself apart. Finally, in Sec. 6 we conclude
rna

and discuss Andromeda’s limitations, evaluations, and potential avenues for

future work.

2. Background
Andromeda is versatile and requires only moderate adjustments to adapt
to various safety-critical domains. However, the case study presented later
originates from the civil aviation industry. This section briefly introduces the
safety framework recommended by ARP4754-A, a standard widely adopted
Jou

in the sector.
Certification in civil aviation focuses on the safety of aircraft and their
embedded systems, primarily overseen by the International Aviation Organ-
isation (ICAO), the Federal Aviation Administration (FAA) in the United
States, and the European Aviation Safety Agency (EASA) in Europe. The

6
 Journal Pre-proof

of
differences between FAA and EASA standards are minor, making the method
applicable to either. The ARP comprises mainly two documents, the ARP4754-
A, which forms the basis for the development of aircraft systems and their

pro
functions, and the ARP4761, which serves as a process handbook explaining
how these advised processes can be performed. Additionally, there are other
supporting documents, such as the Document Objects (DO), with the most
notable being the DO-178C and DO-254 for the development of software and
hardware components, respectively. In this section, we discuss only the key
elements from the safety framework found in ARP; however, similar concepts
are integrated into guidelines in other industries.
The systems development lifecycle, in many safety-critical sectors, typi-

re-
cally follows the V-model approach to help navigate development milestones.
As shown on the left side of Fig. 1, the lifecycle has three main phases: a)
system design, b) implementation and c) integration and testing, before the
system proceeds to production and deployment. Development initiates with
defining the concept, functionality, and specifying requirements. These re-
quirements are gradually decomposed into lower levels before an informal
architecture is designed. Following numerous iterations of requirement re-
lP
finement and decomposition, the process advances to implementation, com-
ponent integration, and testing, before the system finally reaches the pro-
duction and deployment stages. As previously mentioned, it is crucial for
the safety process to align with development from the early stages. There-
fore, the guidelines provide a framework to integrate safety activities within
each phase of development. On the right side of Fig. 1, the distribution of
rna

safety-related tasks across each phase is presented, in accordance with the

ARP guidelines.
The validation processes determine whether all the identified require-
ments are appropriate and suitable against the higher-level requirements,
ensuring that the system fulfils its intended purpose. In contrast, verification
tasks assist in understanding whether the system implementation conforms
to the specified requirements, confirming that the system is built according to
the design and specifications. These tasks help build the confidence required
Jou

that the system is reliable and safe before moving into production.
The first key element from standards is the safety lifecycle, outlining the
sequence in which safety activities are performed for different stages, often
represented graphically using the V-model.
The second key point involves the concept of Safety Integrity Levels
(SILs), an abstract requirement that dictates the level of rigour required for

7
 Journal Pre-proof

of
pro
re-
Figure 1: The development lifecycle under the V-Model [12]

assessment activities. While these requirements share a similar foundation

as a concept, differences exist among standards regarding the criteria that
influence the decision-making of the allocation process. For instance, in the
lP
civil aviation, SILs allocation is based on the severity of the identified haz-
ard and its probability of occurrence. In the automotive sector, allocation is
also influenced by exposure and controllability traits. The former reflects the
frequency of the vehicle’s exposure to the hazard, whereas the latter focuses
on system-user’s ability to gain control of the hazardous situation.
Since our case study is drawn from the aviation industry, it is important
rna

to note that the concept of SILs is known as Development Assurance Levels

(DALs). Even though SILs is the generic form of abstract requirements
which we still mention later, when appropriate, we will refer to the concept
of abstract requirements as DALs. The standard defines five classes of DALs,
ranging from E to A, with E representing the least stringent requirements
and A the most stringent. For each identified hazard, the appropriate DAL
should be appointed based on the severity classification and the description
of the effects, as shown in Table 1 below:
Jou

8
 Journal Pre-proof

of
DAL Severity Description of Effects
A Catastrophic Airplane Loss / High-Mortality Accident
B Hazardous Serious Injuries / Low-Mortality

pro
Serious function/safety margins restriction
C Major Major physical discomfort
Significant function/safety margins restriction
D Minor Minor physical discomfort
Slight function/safety margins restriction
E No Safety Effect No Effects
Table 1: DAL allocation based on severity classification [13, p. 13]

re-
The process of DAL allocation begins once the high-level functional model
has been constructed and analysed with Functional Hazard Analysis (FHA).
The results of this analysis include all hazards, also referred to as the Failure
Conditions (FCs) within the ARP, associated with each function defined on
that specific design cycle, and then the appropriate DAL is assigned on each
of the corresponding hazards for every defined function.
lP
Once the system architecture starts forming, developers can allocate DALs
to lower parts of the architecture in a top-down manner. For this purpose,
the standard utilises the Functional Failure Sets (FFSs), more commonly
known as minimal cut sets. These represent the minimal combination of
basic events that result in the occurrence of the top event, in this case, the
hazard. The guidelines suggest to use FTA or Markov Analysis to examine
rna

the system and identify all the FFSs that can cause the top-level hazards.
To assist with the allocation of SILs, the guidelines provide a set of rules,
which also differ across industries. For instance, under the ARP4754-A,
if an FFS contains only a single member, then the DAL assigned to that
element is identical to the DAL allocated for the hazard. In cases where the
FFS contains two or more members, then the developer can follow the rules
prescribed by the guidelines [12, p. 44].

• One of the members of the FFS that contribute to the top-level hazard
Jou

is assigned the same DAL with the parent system, whereas the rest of
the members are assigned a DAL equal or up to two levels lower than
the parent-system.

• Two of the members of the FFS are assigned a DAL one level lower

9
 Journal Pre-proof

of
than the parent system, whereas the remaining members are assigned
a DAL equal or up to two levels lower than the parent system.

pro
Both of these options plausible, and the decision is up to the develop-
ers and specific implementation details. However, a challenge arises as the
system size increases, leading to numerous possible combinations that often
result in combinatorial explosion. Additionally, the repetitiveness of this pro-
cess renders any manual approaches impractical. Consequently, substantial
research, such as in [14] [15] [16], has been focused on automating the SILs
allocation process at the system architecture level, whereas in [17], the au-
thors automated the SILs decomposition and utilised it to modify the system
architecture, adjusting the redundancy of elements during system implemen-
tation. re-
As already mentioned, SILs represent the level of rigour assigned to safety
assessment activities, leading to increased effort and developmental costs.
Therefore, engineers must examine the different configurations of allocated
SILs and, based on the cost of a system-wide allocation, choose the most
cost-efficient option.
lP
Achieving this involves defining a basic cost value and assigning each DAL
a unique multiplier to calculate the overall cost. For example, DAL A can
have a multiplier of 10, DAL B a multiplier of 9, and DAL C a multiplier of 5.
This scaling helps understand that the effort required between the different
activities does not progress linearly across different DAL classifications and
that is reflected on the final cost once the multiplier is applied.
rna

Thus, considering the vast variety of configurations and the size of the ar-
chitecture, it becomes an intractable problem for manual approaches. There-
fore, developers turned to optimisation methods where the SILs’ allocation
is viewed as a constrained optimisation problem. The objective is to min-
imise the costs, the constraints are the decomposition rules and the decision
variables are the SIL values throughout the architecture. Due to the strict
timeframe of development, engineers often opt for approximate methods like
metaheuristics, known for delivering relatively good results within a reason-
Jou

able timeframe.
Overall, optimisation techniques provide an additional layer of automa-
tion that benefits system development.

10
 Journal Pre-proof

of
3. The approach
3.1. Overview of Andromeda
This section presents Andromeda, our method for the safety assessment

pro
and assurance of safety-critical systems. In formulating our method, it was
imperative to incorporate processes outlined by industry guidelines. This
not only demonstrates compliance but also instils confidence, as guidelines
comprise best practices that have evolved over the years and are crucial for
certification.
Additionally, recognizing the significance of leveraging automation was a
key factor to alleviate the overall process and address some of the challenges
associated with traditional techniques and the iterative development. Our
re-
investigation into functional standards, such as the ARP4754-A, and vari-
ous approaches that enable automation, including the MBSA paradigm and
argument patterns, guided the development of Andromeda.
Fig. 2 below provides in an illustrative way how Andromeda as a method
was conceptualised and eventually implemented from safety standards. The
rectangles are abstract representations of information. The coloured rect-
lP
angles, represent the information encapsulated in different guidelines (e.g.
ISO).
Functional safety standards typically specify individual safety frameworks;
however, they share common elements and processes, which if abstracted
from specific details it can contribute to a generic framework for safety.
The grey rectangle, represents the framework that Andromeda proposes for
rna

safety assessment and assurance which was elicited from the common ele-
ments among these standards.
Expanding upon this concept, we enhanced it by incorporating features
from MBSA, argument structure notations (i.e. GSN) and argument pat-
terns. The rest of the shapes represent the transition from that framework
to a metamodel (high-level design), which captures the links between the
assessment activities (of the framework), analyses techniques (suggested by
standards), argument pattern (that can be created by the practitioner in
Jou

Andromeda), system architecture, allocated requirements, and the concrete

argument itself.
The “Software Design“ shape represents the implementation of the meta-
model in a software tool, describing the software architecture and its cor-
responding data structures that capture system model and safety-related
artifacts. Note that, the software design block has three coloured blocks

11
 Journal Pre-proof

of
attached that match the respective standards. This is to signify that im-
plementation details vary to account for standard differences such as the
requirement decomposition rules or the different criteria during the initial

pro
SIL allocation.
Finally, the “System architecture” rectangle, is the potential system ar-
chitecture and the annotated information the user can create in the soft-
ware tool such as failure data, contextual information and evidence artifacts.
Lastly, there is an additional lower-level abstraction layer, not shown here,
that represents potential raw data from manual analyses, tests or stakeholder
requirements. These can also be incorporated within the system model and
presented, upon demand, in the argument structure.

re-
lP
rna

Figure 2: Transition from standards to the metamodel and tool

Jou

3.2. The Pattern

Safety standards consider safety as a system property that should be con-
trolled as early as possible and maintained throughout development. Once
the initial FHA is conducted, and the preliminary system design is formu-

12
 Journal Pre-proof

of
lated, integrity requirements (i.e. DALs) suitable to fulfil the higher-level
requirements can be determined.
To further assist on that front, the guidelines have provided a scheme for

pro
allocating requirements. In this context, by scheme, we mean a systematic
plan for allocating requirements. For example, guidelines suggest a top-down
approach for the allocation and they provide a set of rules for the decom-
position of those requirements from high-level to lower-levels. Specifically,
high-level DALs can then be decomposed and allocated accordingly based on
architectural dependencies and failure propagation as shown on the left side
of Fig. 3 below.
As the design matures, the whole process of analysis and requirement al-

re-
location are revisited. The cycle concludes upon completion of development,
with the establishment of an acceptably safe system substantiated by suffi-
cient evidence, confirming the systematic mitigation of all identified hazards
via the appropriate allocation of subsystem and component safety integrity
requirements.
Andromeda utilises this scheme as a mechanism for providing structure
to the safety argument following the logic mentioned in the right side of the
lP
figure. Note that this process is applicable for both validation and verifi-
cation activities, aligning with the V-model, as recommended by the safety
guidelines for the development of systems [12, p. 24].
rna
Jou

Figure 3: DALs Allocation on a simple architecture that forms the basis for the argument
structure

13
 Journal Pre-proof

of
3.3. Method Integration
Andromeda is an integrated approach which incorporates methods that
our research group has been developing over the years. One of the important

pro
facets of this integration is the automation capabilities, which can be used to
significantly facilitate the construction and maintenance of safety arguments.
While the early phases still require manual effort and input, such as functional
design and high-level requirements specification, the safety analysis of the
architecture can be automated using the embedded analysis techniques and
algorithms. Andromeda further extended on the assessment capabilities by
adopting the different activities, typically conducted in the aviation sector,
such as the Preliminary Aircraft Safety Assessment (PASA). The latter is

re-
useful for establishing a list of failure conditions on the aircraft-level functions
and the appropriate requirements for addressing them.
Following the scheme explained earlier, we used that logic behind the ar-
gument structure as a basis and combined it with the concept of argument
patterns. On this front, collaborative groups such as the Assurance Case
Working Group (ACWG) have extended graphical notations to support ar-
gument patterns with concepts like element and structural abstractions.
lP
For example, GSN’s structural abstraction is achieved via the multiplic-
ity and optionality extensions. The former generalises n-ary relationships
between argument elements by iterating similar arguments over them. The
optionality extension captures alternative relationships between argument
elements, effectively allowing conditional connections and the creation of dif-
ferent paths based on varying circumstances.
rna

Andromeda primarily employs GSN as the main graphical notation to

both build the pattern and present the concrete argument. GSN was our
first choice due to its extensions of modularity and structural abstraction
fitting the purpose, as well as its widespread acceptance in the domain.
It is worth noting, however, that comparable results could be attained
using alternative notations such as the Claims Arguments Evidence (CAE)
notation or the Structured Assurance Case Metamodel (SACM) [18] [19].
However, since GSN’s model-based support is limited, Andromeda ad-
Jou

justed these entities in the metamodel with the necessary structures to cap-
ture relationships between the system model, evidence artefacts and argu-
ment patterns. This link between the pattern and the model information
along with our implemented instantiation algorithm, allowed us to automat-
ically generate concrete argument structures.

14
 Journal Pre-proof

of
3.4. The Metamodel
Since Andromeda involves various steps, progressing from functional de-
sign to safety argument structures, it is more suitable to witness it in practice

pro
in the following section instead of explaining all the steps here. However, be-
fore delving into practical applications, it is useful to explore the metamodel,
which makes all this possible.
The HiP-HOPS approach already comes with an extensive metamodel
that connects elements from system architectures, such as subsystems or com-
ponents, ports acting as interfaces for information propagation, and safety ev-
idence artefacts such as minimal cut sets and integrity requirements. Hence,
we utilised it as a foundation for storing system-related information in order

re-
to exploit the HiP-HOPS capabilities.
As mentioned earlier, the metamodel is also enriched with elements from
the GSN standard as a means to incorporate argument and pattern elements,
structure rules and semantics. Moreover, the addition of an extensive data
structure, referred to as Model Connecting Storage Unit (MCSU), helps store
relevant information and interconnect all these components. Fig. 4 depicts
a high-level view of what the metamodel entails.
lP
Since standards provide the basic scheme for the argument structure, the
requirement decomposition rules, and a guide for the appropriate safety anal-
ysis activities, they are also connected with both the MCSU structure and
the system architecture. The connection with the architecture is important
to notify the analysis and decomposition engine about specific details based
on the corresponding system. For example, if the system is from the automo-
rna

tive industry, the decomposition rules will differ compared to a system from
the aviation industry. In addition, the connection with the MCSU is impor-
tant because, in some industries, the outcomes of certain processes might
be directly usable as evidence artifacts in the final argument. For instance,
under aviation guidelines, an FHA table could be used as evidence to sup-
port a claim arguing the correctness of DALs allocated to specific high-level
functions. The implemented instantiation algorithm draws all the necessary
information from the MCSU, and based on that and the pattern, it generates
Jou

the concrete structure.

Below, Fig. 5 and Fig. 6 present a more detailed view of the metamodel
in Unified Modeling Language (UML) format. The first figure depicts how
details of the pattern, model and argument elements entities are intercon-
nected. The nodes are high-level nodes. For example, the “MCSU Element”
node would be the equivalent of the SACM’s “ArtifactElement”. This is the

15
 Journal Pre-proof

of
pro
re-
lP
Figure 4: Overview of the Metamodel

base class for elements in our metamodel. Essentially, all elements which ex-
tend the MCSUElement, are MCSU entities. It is also a recursive container,
rna

meaning it can contain one or more sub-containers.

The second figure showcases the adapted version of the HiP-HOPS meta-
model, which we utilise to store information about the system during the
modelling phase. This adapted metamodel serves as input to the integrated
HiP-HOPS algorithms, facilitating the initiation of the analysis and require-
ment allocation phases. Together, these figures offer a deeper understanding
of the structural foundations of our approach and the interconnections be-
tween Andromeda’s embedded elements.
Jou

16
 Journal Pre-proof

of
pro
re-
lP

Figure 5: Model, Argument and Pattern Elements under the MCSU structure

The “Coordinator” entity serves as a manager class that oversees a sig-

rna

nificant portion of the tool’s functionalities and is tasked with creating and
maintaining the MCSU structure during a project. The MCSU encapsulates
essential information about the argument, pattern and model structures,
which inherit basic attributes and access to visitor classes from the “MC-
SUElement” entity.
Note, that the “MCSUElement” is developed using an adaptation of the
composite pattern found in [20][p. 183], allowing elements to contain other
elements; thus, forming a hierarchical structure where each element provides
Jou

access to the nodes one level lower in the architecture.

The “Visitor” class represents our basic implementation of the software
engineering pattern visitor, and supports each of the element types with vari-
ous capabilities without them including any additional methods or members.
Any required changes to the functionality can be achieved through an update

17
 Journal Pre-proof

of
to the visitor class.
While the argument and pattern elements share similarities, they also
differ in the types of elements. For example, pattern elements have special

pro
types such as “IfThen” or “ForEach” as well as expressions and parameters
to help follow the system architecture based on an abstract structure.
The “ModelElement” class holds all the information about the system ar-
chitecture, the failure information and SIL requirements for each component
through the “SystemContextData” attribute. This data is indispensable for
the instantiation algorithm in order to properly build the argument structure.
Note that all the elements discussed so far (and the ones that follow) are
represented within the tool as either object-oriented classes/objects or C-

re-
style structures. The related information for these elements, such as lists of
comprising subsystems, properties, and descriptions, as well as mechanisms
to retrieve data, are included as member variables, functions and properties.
Base elements typically provide general characteristics that are inherited by
their derived classes. For example, the MCSUElement in Fig. 5 is the base
class for ModelElements and PatternElements. It establishes a foundational
set of information, including anelement name, description, and the accept
lP
method, which is commonly included in the base class.
During the modelling phase, we store the model element information in a
separate structure through a model mapping process.This structure serves as
input for gaining direct access to the HiP-HOPS engine, allowing us to gen-
erate minimal cut sets, FMEA tables and SILs. The “MappingClass” entity
is responsible for this mapping process, facilitating the transfer of system in-
rna

formation between the MCSU and the HiP-HOPS metamodel. Furthermore,

we have implemented a reverse mapping (i.e. from MCSU to HiP-HOPS)
for potential future work that could allow engineers to adjust the model
information by manually applying changes to the argument structure.
Jou

18
 Journal Pre-proof

of
pro
re-
lP
rna

Figure 6: The integration of the HiP-HOPS metamodel

In Fig. 6, the “HiPModel” class serves as the top-level node of the sys-
Jou

tem, functioning as a container for the architecture. The “Perspective” helps

distinguish the software from hardware aspects of the architecture as well as
between different implementations. The “HiPSystem” are higher-level sys-
tem entities that have components and lines to guide the connections between
the various elements. These components have ports that help them connect

19
 Journal Pre-proof

of
through lines with other elements and enable behaviour propagation (both
nominal and failure). In addition, the components can have potentially more
than one implementation to account for components from different manufac-

pro
turers. Finally, the “FailureData” class stores all safety related information
such as basic events, output deviations and common cause failures for each
of the components. As previously mentioned, this aspect of the metamodel
is mainly utilised for the direct communication with the HiP-HOPS engine
and cannot be accessed by the instantiation algorithm.

3.5. Inputs and Outputs of Andromeda

In this subsection, the inputs and outputs of Andromeda are outlined
below:
re-
The process can initiate during the functional design, effectively just be-
fore the FHA stage in the V-model as shown in Fig. 1 earlier. The method
requires substantial input before it proceeds with the analysis of the system.
Fig. 7 shows an annotation window dialog from the Andromeda tool, which
is used for both inputting relevant data, including component failure rates
and output deviations, as well as accessing additional dialog windows. The
lP
output deviations are the failures that can propagate throughout the archi-
tecture, such as Omission, annotated as O in the dialogue parameter. As
mentioned earlier, all this input and output are stored within Andromeda in
their respective data structures.
1. Selection of industry (Tool-based parameter for the software to be ad-
justed accordingly)
rna

2. Function Identification and System Definition (Essentially the func-

tional model and system architecture)
3. Failure Behaviour Information (Hazards, risk, high-level DALs)
Jou

20
 Journal Pre-proof

of
pro
re-
Figure 7: Example of Failure Annotation Dialogue in the tool
lP
The automated analysis process generates the following outputs:
1. fault trees
2. fmea tables
3. minimal cut sets
rna

Based on this information and the initial high-level requirements converted

into DALs, the tool can allocate the remaining requirements hierarchically
and cost-optimally. At this point, the user can create the appropriate argu-
ment pattern for the industry in question within the tool. Then, by utilising
the interconnected models, the pattern, and the instantiation algorithm, An-
dromeda generates the concrete argument structure. Fig. 8 below illustrates
how an arbitrary argument structure appears in the tool.
Jou

21
 Journal Pre-proof

of
pro
re-
lP
Figure 8: Example of an argument structure within tool

4. Case Study
4.1. System Details
rna

This section explores the practical application of Andromeda through a

case study drawn from the aviation industry, focusing on a brake system
designed according to the principles employed in the Boeing 787 Dreamliner.
The choice of this example is deliberate, given its contemporary technology
and the widespread adoption of similar mechanisms across various aircraft.
In particular, the brake system exemplifies a shift from traditional hy-
draulic components to electronic counterparts and other characteristics. For
example, it uses a carbon disk sensor unit that can assess the wear of the
Jou

disks in real-time and also features its own data transmission unit to the cock-
pit. More importantly, this shift significantly reduces random failures which
typically occur due to material degradation and require statistical techniques
to predict. Instead, the most common faults of electric brakes are system-
atic, from either hardware or software components, which can be addressed

22
 Journal Pre-proof

of
with process or design measures via requirements (DALs) according to the
guidelines[12].
Before applying the method, it is useful to highlight details related to

pro
the system and its architecture. The brake unit is responsible for decelerat-
ing the aircraft and preventing any motion during extended periods on the
ground. In some instances, it also contributes to steering through differential
braking. Despite its seemingly straightforward function, commercial aircraft
incorporate additional mechanisms such as spoilers, reverse thrust and other
brake technologies like antiskid to enhance braking efficiency. Normally, en-
gineers would assess these components both individually and collectively to
ensure the safety of the braking function. However, for the sake of simplicity

re-
in this example, our focus is narrowed down to the wheel-brake system and
relevant actuators and controllers.
The Boeing 787 Dreamliner was released in the early 2000s and comes in
different models which vary in size and capabilities [21]. Despite following
a similar architecture, the components and safety requirements might differ.
For example, the difference in weight between the models suggests many vari-
ations in the architecture including potentially an alternative brake setup.
lP
In general, the aircraft includes 8 separate braking assemblies, one per main
wheel, and they are a contemporary version of the multi-disc brake, known as
the rotor-disc brake. Each assembly has a stack of 5 rotors and stators. The
rotors are similar to discs, but they have small openings to allow water and
heat to escape whereas stators are immobile flat plates covered in isolated
blocks that have brake linings attached. When the brakes are activated, the
rna

pistons in the assembly exert pressure through a major plate which corre-
spondingly imposes tension to the stack of rotors and stators and creates the
friction needed for heavy-duty braking.
With the transition from hydraulic into electromechanical brakes, 787
Dreamliner also introduced a modern actuation mechanism that uses elec-
tricity to power the braking mechanism instead of fluids. Manufacturers can
choose system components from different vendors, which changes the system
drastically. Each configuration needs to be carefully evaluated, as it can alter
Jou

safety requirements substantially.

4.2. Andromeda Core Phases

4.2.1. Functional Modelling
Development typically commences with the function modelling stage,
where a set of high-level functions is defined. As development advances,

23
 Journal Pre-proof

of
this process is reiterated to define functions that support the high-level func-
tions and build a hierarchical functional model. This activity is integral for
both system development and safety assessment.

pro
On one hand, the work products of this stage are utilised by the engineers
to design the initial system architecture. On the other hand, knowledge
of the system functionality enables the identification of potential hazards
and through the FHA it is possible to evaluate the risk involved and assign
integrity requirements.
For these reasons, Andromeda initiates with the functional modelling
stage. Naturally, the functional model would include several low-level func-
tions, but to avoid an unnecessary and extensive diagram we only highlight

re-
an overview for demonstrative purposes in Fig. 9.
lP
rna

Figure 9: Overview of High-level Functions

The first layer of this functional model includes only some of the major
high-level functions typically found in commercial aircraft. In particular, the
“ground deceleration” function involves all sub-functions and systems related
to the deceleration capabilities for this aircraft.
The spoiler control and reverse thrust are linked with the ground decel-
Jou

eration function since they are mechanisms that assist that function; how-
ever, in practice they are mostly used during the landing phase. Thus, even
though they are implied as sub-functions in this example to highlight this
connection, their implementation is part of the navigation and engine systems
respectively.

24
 Journal Pre-proof

of
Normally, they would still be assessed for safety concerns when examining
the ground deceleration, but they are excluded from this example as the focus
is solely on the wheel brake system.

pro
At this point, guided by a more mature functional model and accumulated
experience, an initial system architecture can be established. The model for
our example is shown in Fig. 10 below, followed by a brief explanation.

re-
lP
rna

Figure 10: Example Architecture based on Boeing 787 Dreamliner [22]

As we see in the figure, each pilot has access to two brake pedals, left
and right, that send signals to the corresponding Brake System Control Unit
(BSCU). This aircraft uses two separate processing units (BSCUs), one for
each group of wheels, for the left and right sides respectively. Their responsi-
bilities are to process input from pedals, send the commands to the Electric
Brake Actuator Controllers (EBACs) and receive feedback from the brake
assembly sensors in order to notify the cockpit or other automatic systems
Jou

(e.g. autobrake).
The feedback is instrumental for the proper operation of brakes and cor-
rect control since it provides information such lining wear, wheel rotation
rate and temperature. The EBACs main role is to interpret the signals from
BSCUs, control the brake rate and send essential data for health monitoring.

25
 Journal Pre-proof

of
Each one of them comes with its unique power supply, shown in the image
above as Electric Brake Power Supply Unit (EBPSU).
On each wheel there is a brake assembly that has four Electric Brake Actu-

pro
ators (EBAs), which are engaged through the actuator controllers (EBACs),
and apply pressure on the stack of rotors and stators to decelerate the wheel.
The software parts of the processing units are validated and verified di-
rectly from the suppliers (e.g. Safran) as well as third-party companies. The
methodologies used for the validation and verification activities were not
specified, however it was clear that software development was in line with
functional specifications through tests that evaluated the outcome based on
specific inputs (black-box testing) [23].

re-
For the purposes of this example, we consider the software and hardware
parts as one unit and assess their interactions as a system. Finally, Boeing
has to extensively test all vital parts of the system under both normal and
irregular conditions. For example, part of the testing phase examines the
aircraft’s braking capabilities with overused brake linings or with several
brake assemblies disabled to ensure performance is always within the required
threshold.
lP
Redundancy and autonomy are incorporated in many parts of the system
architecture and with the existence of auxiliary systems for deceleration, such
as the engine reverse thrust, supported separately from other sub-systems
decreases the likelihood of common errors which indicates that functional
independence is supported to an extent.
rna

4.2.2. Risk Assessment

The subsequent phase entails identifying hazards for each function, esti-
mating risk, assigning a classification, and a DAL requirement. The results
of the FHA activity for two specific functional failures are outlined in Tables
2 and 3 below.
In Table 2, we examine the effects of losing control over the ability of
braking as a whole which could lead to a high-speed overrun with potentially
high number of casualties. As a result, the hazard is classified as catastrophic,
Jou

the acceptable likelihood of occurrence is set to a very low probability and

the DAL assigned is A, which is the most stringent. Table 2 explores the pos-
sibility of losing the autobrake function. In this case, the pilots are expected
to take over and operate the braking manually. Even assuming slow reaction
time, the estimated outcome of such an incident is only minor injuries and
for this reason the hazard is assigned only a DAL C.

26
 Journal Pre-proof

of
pro
FHA Function FHA Boeing Aircraft Landing & Rejected
Name Dreamliner 787 Phase Take-off
Function Ground Hazard Catastrophic
Name Deceleration Classification
Hazard Loss of Deceleration DAL A
Name Capability
Hazard Unanticipated loss of System Likelihood occurrence
Description deceleration capability Reqs less than 1E-9
per flight hour
Hazard
Effect
re-
Pilots unable to stop
the aircraft
Verification
Method
Aircraft
Fault Tree

Table 2: Example Hazard Analysis and Risk Assessment Summary for Loss of Autobrake
lP

FHA Function FHA Boeing Aircraft Landing & Rejected

rna

Name Dreamliner 787 Phase Take-off

Function Ground Hazard Major
Name Deceleration Classification
Hazard Loss of Autobrake DAL C
Name
Hazard Unanticipated loss of System -
Description automatic brake Reqs
Hazard Automatic system fails to operate, Verification Software & Hardware
Effect and pilots switch to manual mode. Method Testing
Slow reaction time might lead to
Jou

overrun and minor injuries

Table 3: Example Hazard Analysis and Risk Assessment Summary for Loss of Autobrake

27
 Journal Pre-proof

of
4.2.3. Failure Behaviour Annotation
The next phase in Andromeda is to determine the failure behaviour and
annotate the system architecture. This process involves the modelling of

pro
the architecture within our software tool and providing the failure logic on
each of the sub-systems and components. Hence in this part, we convey that
behaviour with the use of a fault tree for clarity as depicted in Fig. 11. Note
that in reality the system-level fault tree would demonstrate the behaviour
of the system as a whole. For example, the top node could be the “Loss of
Aircraft” which would be connected with all the potential lower-level hazards
that could lead to that.
Furthermore, each function could potentially have multiple hazards and

re-
each of these hazards could have different facets. In our example below,
we examine the hazard “Loss of Deceleration Capability” from Table 3, but
only for the failure condition “unanticipated loss of deceleration capability”.
That same hazard could also manifest as “inadvertent deceleration after an
attempt for landing” with the same outcome of which is the loss of deceler-
ation.
After careful evaluation, it is calculated that the “loss of wheel braking
lP
failure” can occur from any of the following conditions:
• Loss of brake pedals
– Only possible if both pilots’ pedals fail
• Loss of EBACs
rna

– Loss of both EBACs due to loss of power or internal hardware or

software failure
• Loss of BSCUs
– Failure of BSCU due to internal failure
– Both BSCU power supplies fail
• Loss of Wheel-Brake Assemblies
Jou

– Any combination of 3, or more, wheel assemblies fail or suffer

damage
The conditions in this case are slightly simplified to facilitate the demon-
stration of the process, but we now have enough information to annotate the
system and initiate the automated activities.

28
 Journal Pre-proof

of
pro
re-
lP
rna

Figure 11: Fault Tree for the Unanticipated loss of the wheel brake system
Jou

4.2.4. System Safety Analysis

With all this information inside our tool, we can commence the auto-
matic analysis phase, which after a series of processes such as the synthesis
of the system-level tree from individual failure fault trees, it produces valu-
able safety artifacts such as the system-level fault tree, FMEA tables, and
Common Cause Analysis (CCA) results. After further qualitative analysis

29
 Journal Pre-proof

of
on the fault trees, we generate the minimal cut sets.

4.2.5. DALs Decomposition and Allocation

pro
During this next phase, the algorithms provide the list of minimal cut
sets as input to the optimisation algorithm in order to cost-optimally decom-
pose and allocate the DALs throughout the architecture. The basic idea is
that integrity requirements allocation to lower-level systems is influenced by
the contribution of sub-systems and components to the system failure. The
guidelines suggest FTA or Markov analysis as suitable candidate techniques
for determining that contribution and the minimal cut sets is the key artifact
exploited for this task. As already discussed, the other significant part of the
allocation process is the set of rules provided by the standards when two
re-
or more sub-system failures contribute to a higher-level failure. These key
elements for the optimal requirement allocation are also graphically depicted
in Fig. 12 with the use of a triangle.
lP
rna
Jou

Figure 12: Integrity requirement allocation model

In practice, the software tool uses a Tabu search optimisation technique,

which is an extension of HiP-HOPS as described in [16][24], and an abstract
cost catalogue. Each candidate solution represents a specific set of allocated

30
 Journal Pre-proof

of
DALs and the best candidate is considered the one with the lowest cost.
First, the algorithm creates a candidate solution at random which is used
in the next cycle to produce a new generation of candidates. After every

pro
iteration, the available solutions are compared and the less costly is selected.
In addition, the algorithm also checks the short-term memory (Tabu Tenure)
for any recent occurrences of the current solution and if an identical exists
within the tenure, it gets discarded. However, due to an “aspiration criterion”
if the candidate in the tenure has the overall lowest cost in memory, then
the algorithm selects that candidate regardless being in the tenure. The
algorithm is provided as pseudocode in Fig. 13 below.

re-
lP
rna

Figure 13: Optimisation Algorithm

For this particular example, we used the following cost values shown in
Table 4.
Jou

DAL A B C D E
Cost 100 80 40 20 0
Table 4: DAL cost values

The generated DALs for the function “Deceleration Capability” have been

31
 Journal Pre-proof

of
decomposed and allocated automatically as illustrated in a more detailed
system architecture in Fig. 14. Note that the initial DAL assigned is A due
to the fact that the hazard in Table 2 requires a more stringent requirement

pro
compared to the hazard in Table 3 and as the guidelines propose, the most
stringent requirement per element overrules lower values. As can be seen, in
the case of the power supply units (BSCU) there is redundancy and therefore
the decomposition rules are applicable. In addition, the DALs assigned on
the wheel assemblies are to cover for the electronic parts and actuators rather
than mechanical parts since these require different methods for determining
requirements. Finally, there have been alternative allocations with similar
costs but here we present only one of the available options.

re-
lP
rna

Figure 14: Cost-Optimal allocation of DALs on the wheel brake

4.2.6. Pattern Creation and Instantiation

Jou

Once safety assessment is completed for this development cycle, effort

must be invested towards system safety assurance by creating an argument
structure. For this task, we employ the concept of arguments patterns that
mandate the argument structure, system model information and an instan-
tiation algorithm to produce the concrete argument.

32
 Journal Pre-proof

of
The general pattern we use for the aviation industry follows closely the
safety lifecycle from the ARP4754-A. Despite the pattern being substantially
smaller in size than the concrete argument, here we present only certain parts

pro
of the pattern due to space limitations. Fig. 15 showcases an overview of the
pattern at high-level.
The argument comprises of various subgraphs and their encapsulated
modules. The top-level module argues that the system in question (i.e. the
aircraft) is safe since the development followed all safety guidelines and ad-
dressed all the functional failures identified during the design stage. The
following nodes argue that this has been achieved by validation and verifica-
tion activities as described with the use of the V-model. This is important

re-
to ensure that all functional requirements specified during the design stage
are appropriate and correct and the implemented architecture is correct ac-
cording to those requirements. The process is iterative and goes through
the entire architecture starting from functions and followed by systems that
implement these functions and their sub-systems.
The subgraph in Fig. 16 illustrates the claim that functional requirements
address all the underlying hazards identified during the most recent FHA.
lP
The justification of assurance is based on the guidelines that suggest Prelim-
inary Aircraft Safety Assessment (PASA), which indicates that the process
must continue until all hazards for all aircraft functions have been addressed
via the requirements. To notify the algorithm to iterate over all hazards of
every function in the system, the pattern uses the GSN’s multiplicity ex-
tension. On the other hand, we also use the optionality extension to create
rna

options based on the current requirement. For example, if the requirement

is a DAL, then the claim is supported by the “DAL VAL module” whereas
in any other case it is supported with the “RValGoal” node, which is left
undeveloped in this case.
Jou

33
 Journal Pre-proof

of
pro
re-
lP
rna
Jou

Figure 15: Overview of the pattern

34
 Journal Pre-proof

of
pro
re-
lP
rna
Jou

Figure 16: Function Validation Pattern

35
 Journal Pre-proof

of
Finally, the “DAL Val Module” is expanded in Fig. 17 below. The top-
level node claims that the DAL allocated is suitable for addressing a specific
hazard (i.e. parameter “H”) of the current function or system element. The

pro
strategy utilises the Preliminary System Safety Assessment (PSSA) to exam-
ine causes of failure that might lead to the hazard occurring. This is further
supported by nodes which claim that the DALs allocated throughout the
function’s supporting elements (i.e. systems or components) are appropriate
and optimal. The appropriateness is specified through the “SupportingDal-
Goal” node that uses the multiplicity extension to go over all the elements
within the architecture that implement the “F” function. The optimality
is argued via the “DALOptModule” within the “DALGoal” node and sup-

re-
ported via evidence generated through the Tabu search.
lP
rna
Jou

36
 Journal Pre-proof

of
pro
re-
lP
rna

Figure 17: DAL Validation Pattern

Similar to this validation subgraph, there is a part of the pattern that

handles arguments related to verification activities (ASA and SSA).

4.2.7. Pattern Instantiation

Jou

Once the pattern is built within the tool, the engineer can employ the
instantiation action, prompting the algorithm to produce the corresponding
concrete argument. In this process, the pattern serves as a guiding structure,
allowing the algorithm to traverse the system architecture as needed. It
replaces all parameters within the nodes with actual information derived

37
 Journal Pre-proof

of
directly from the system model.
The algorithm responsible for the instantiation is implemented as three
parts within our tool. The initial functions, “Instantiate”, initiates the pro-

pro
cess, checks for the provision of essential user inputs -comprising system
model information and structure, assessment artifacts, and the argument
pattern- and performs basic model-checking to ensure adherence to specific
rules for both the system model and pattern. For instance, it does not ac-
cept a pattern where a strategy node is connected directly with an evidence
element, as this is invalid based on the GSN standard.
Assuming all the information is suitable, the program creates the top-level
element and calls the second function, “ParseandCreate”. This function is

re-
the core of our algorithm, utilising three inputs: the top-nodes from the sys-
tem model, the pattern and the concrete argument to gather the information
and structure and recursively construct the argument. Specifically, through
the parameterised expressions within the pattern nodes, the algorithm man-
dates the type of information needed from the system.
Our third function, ”ParseForEach”, is an auxiliary mechanism used when
the process meets special pattern elements such as ”ForEach”and ”IfThen”.
lP
The latter enables the system to traverse through the model information ac-
cording to user-defined expressions found in these special nodes. The system
model is utilised for both its encapsulated information and structure, allow-
ing the algorithm to identify which parts of the pattern need to be repeated,
and ensuring the argument extents throughout the underlying architecture.
Finally, the algorithm returns to the “Instantiate” function, which passes
rna

through the generated argument structure and calls the tool’s editor to cre-
ate the graphical representation. The “ParseandCreate” function depicted
in Fig. 18 as pseudocode with all the language-related details omitted.
Jou

38
 Journal Pre-proof

of
pro
re-
lP
rna
Jou

Figure 18: Instantiation Algorithm

The automatically generated structure is depicted in Fig. 19 and 20.

Given the considerable size difference between the argument and the pattern,

39
 Journal Pre-proof

of
only two segments are presented here. The first part constitutes the concrete
representation of the pattern structure shown earlier in Fig. 15.

pro
re-
lP
rna
Jou

Figure 19: Top-level Concrete Argument - Aircraft safety via compliance with guidelines

40
 Journal Pre-proof

of
Showing compliance with the EASA’s guidelines is mandatory since the
aircraft operates within the European boundaries and this should be reflected
in the argument; however, due to similarities with the FAA, it set as unde-

pro
veloped in this example.
The second part of the concrete argument, Fig.20, corresponds to the ar-
gument derived from the pattern snippet in Fig. 17. It asserts that the DALs
allocated to the left-side BSCU and its underlying systems are adequate to
address the hazard examined in this example- namely, the “Unanticipated
Loss of Deceleration Capability”.

re-
lP
rna
Jou

41
 Journal Pre-proof

of
pro
re-
lP
rna
Jou

Figure 20: Argument over Left-side BSCU and supporting systems

4.2.8. Handling Changes

Last but not least, it is essential to discuss how Andromeda accommo-
dates changes to adapt to the continuous evolution of modern development.
42
 Journal Pre-proof

of
Arguably, the most common type of change involves alterations to the sys-
tem model. During development, engineers may determine that certain com-
ponents are unsuitable for the intended purpose, or issues may arise with

pro
suppliers, leading to the adoption of alternative products with distinct archi-
tectural differences.
Additionally, authorities may request hardware or software modifications
through directives to ensure compliance with the regulations. For instance, in
2019, the FAA issued an Airworthiness Directive (AD) suggesting all Boeing
787-8 and 787-9 aircraft to install a hydraulic tubing and replace their flight
control software [25]. These design alterations are easily managed by re-
annotating the system model with new failure information, and the remaining

re-
tasks are handled automatically by the algorithms. Other types of changes,
such as new guidelines or alterations to existing ones, can be accommodated
by adjusting the argument pattern to align with the new regime. Finally,
changes may also involve the replacement of analysis techniques with different
approaches. These can be seamlessly integrated into the tool, either through
ad-hoc solutions and minor adjustments to the metamodel and tool or by
direct implementation within software’s analysis engine.
lP
4.3. Evaluation
Summarising our findings, we begin with a reflective evaluation, which
revealed that the integration of all the aforementioned processes enabled a
seamless generation of major work products such as integrity requirements
and argument structures. In combination with the significant automation
rna

introduced in our method, this provides a strong foundation for a scalable

safety assurance solution, which is crucial for modern development.
It is important to note that we applied this evaluative case study with
an aim to address the paper’s research questions and evaluate the tool at
its prototypical stage. In addition to our own experience using the tool, we
distributed it to industrial partners from EU projects and others with HiP-
HOPS licences (the proprietary part of Andromeda). The group of users
averaged 5-7 years of experience in reliability engineering. Each user received
Jou

the files necessary to install the tool on their own machines and used it to run
various examples. Once the testing period concluded, we conducted informal
interviews remotely through collaborative apps (Microsoft Teams).
From our own experience as the authors, we found that the method han-
dles changes - whether architectural or knowledge-based - reasonably well

43
 Journal Pre-proof

of
due to the adjustability of the argument pattern and the automation, as dis-
cussed in Section 4. This capability enhances user confidence and facilitates
the maintainability of safety arguments. The case study has provided insight

pro
into the following key evaluation dimensions:

1. Scalability
2. Validation of Requirements and Traceability
3. Compliance with Industrial Practice
4. Usability

4.3.1. Scalability
Models and automation naturally simplify labour intensive and error-
re-
prone processes. However, it is important to consider the scalability of our
algorithms and tool. First, we note that all the key processes that are com-
putationally expensive, such as the analysis and design optimisation, are
handled within the Andromeda using the HiP-HOPS engine, a commercial
tool used in industrial context, which has been proven to be scalable [26]
[27] [28] [29]. Regarding the overall application of the method, although
lP
the paper presents proof of concept, our case study has been designed on
a realistic system architecture, having consulted engineers and a number of
published resources. This included not only the “Wheel Brake” system but
also other supporting systems of the “Ground Deceleration” function, such as
the “Spoiler Control” and “Thrust Reverser Control”. Our system is there-
fore of substantial complexity and size for the purposes of demonstration,
rna

comprising over 152 system elements and resulting in thousands of argument

nodes. Manually creating such an argument structure would require several
person days of modelling, whereas with the automated instantiation in our
tool, it took only a few seconds.
The user group reported that, based on extrapolation, the examples they
worked with would scale to the typical model sizes they encounter in their
applications.

4.3.2. Validation of Requirements and Traceability

Jou

As a model-based method, Andromeda enables traceability from a safety

case to various engineering artifacts due to the interconnections between the
heterogenous models established by its underpinning metamodel. For indus-
tries like the aviation, traceability is essential for the validation of require-
ments of sub-systems and items [12, p. 62]. Specifically, each requirement

44
 Journal Pre-proof

of
should be traceable to a parent requirement or to the specific design decision
that led to its identification. The MCSU structure holds all the information
at any time between argument elements and model elements, which can help

pro
to algorithmically, using the requirement decomposition rules as a base, ex-
amine whether a low-level requirement satisfies the higher-level requirement.
In terms of other validation processes, we have implemented analysis meth-
ods that are acceptable by the regulatory authorities as means to assist in
the validation of safety-related requirements, such as FHA and PSSA. Other
validation activities include the demonstration of results from special tests
and simulations. To this end, we do not currently offer direct support for
such specialised processes, but we have designed generic structures in the

re-
pattern to store test results along with the mechanisms necessary to add
them externally from other sources.
Regarding this aspect, the users confirmed that the traces relevant to
their typical application usage were included.

4.3.3. Compliance with Industrial Practice

Despite the fact that this method is novel, we have put significant effort
lP
into ensuring it is compliant with standards. Andromeda closely follows what
ISO26262 and ARP4754-A suggest as suitable processes at each development
stage and provides the appropriate safety artifacts as outcomes. For example,
hazard identification and mitigation measures, requirements allocated across
system architecture, and the generated argument of safety.
Similarly to our own findings, user feedback reassured us that our method
rna

adheres to the standard processes. However, we intend to follow up on this

qualitative evaluation with more detailed quantitative studies assessing spe-
cific standard requirements coverage.

4.3.4. Usability
The selected user group provided substantial unstructured feedback on us-
ability improvements, and overall, reactions were positive for a non-commercial
tool. For example, users suggested implementing version control to allow for
concurrent development and the ability to revert changes in case of errors.
Jou

Another recommendation was to transition from a standalone implementa-

tion to a web application to enable collaborative work among multiple users.
This preliminary feedback has been prioritised, and some changes were
incorporated in the latest version of the tool. After addressing the remaining
recommendations, we plan to investigate means of releasing a public version

45
 Journal Pre-proof

of
of the tool and distributing it to more industry experts for further review
and structured evaluation as part of our future work.

pro
5. Related work
Several methods have built upon and refine the concept of MBSA to ei-
ther address obstacles associated with the manual nature of classical analysis
techniques or to improve the design process through automation and deliv-
erables such as optimised architectural designs.
One approach found in [30] introduced the idea of Component Fault Trees
(CFTs), a concept that extends the classical fault trees by incorporating
modularisation and elements from the system architecture. Each compo-
re-
nent represents a system element with its own modular fault tree and many
components are connected through input/output ports forming a network
structured as directed acyclic graphs, effectively creating a high-level system
architecture. The failure propagation applies through the output ports and
is computed based on the input received from the connected components
and any internal (within that component) events. The modular structure of
lP
CFTs enhances scalability and traceability, ensuring that all safety-critical
aspects can be linked directly to system requirements, which is a significant
benefit over classical fault trees.
A novel method that further extends on MBSA and promotes automa-
tion for the safety assessment presented in [31] and referred to as the Semi-
Automatic Safety Analysis and Optimisation (SASAO). This is a semi-automatic
rna

safety analysis approach that uses a system model capable of encapsulating

the cost of architectural elements and error propagation information, rep-
resented as CFTs. The outcome of this method includes both a functional
and technical architecture that remain consistent with other generated arti-
facts, such as fault trees for each safety goal and the FMEA results. SASAO
also utilises optimisation techniques to aid in system design by selecting the
cost-optimal architecture whilst adhering to the safety requirements (i.e., the
probability of top events stays within the required threshold).
Jou

Another recent approach that incorporates automation for safety analy-

sis of systems is presented in [32], known as Designing Critical Systems with
automated IteratiVe safety analysis (DECISIVE). This methodology facili-
tates the strategic planning and design of a safety-centric system through
a systematic five-step process that is applicable with or without the model-
based paradigm. In brief, the engineers define the system and functional

46
 Journal Pre-proof

of
requirements and perform hazard analysis and risk assessment. Then, the
safety requirements are defined and utilised for designing the architecture
and, based on component reliability data, they form the reliability model.

pro
After completing these stages, a safety analysis model is created using auto-
mated FMEA and identification of safety-related components implemented
within the software tool-support. Following a refinement phase, the accept-
ably safe architectural design is produced. Any safety-related artifacts gen-
erated during this recurring process can later serve as supporting evidence
for the system’s assurance case.
As per DECISIVE, Andromeda also leverages the MBSA paradigm to
facilitate semi-automatic safety analysis of systems, producing fault trees,

re-
FMEA tables, and minimal cut sets, which are essential evidence artifacts for
safety assurance. Additionally, like SASAO, Andromeda features capabilities
for architectural optimisation. Through the use of multi-objective genetic
algorithms [33], it is capable of exploring a large design space with the goal
of finding cost-efficient and reliable system architectures. However, the key
distinction of Andromeda is that it extends beyond the safety assessment.
Instead, it utilises these work products to synthesize argument structures
lP
that are directly applicable for certification purposes.
There are some approaches for producing assurance artifacts towards a
safety-driven architectural design that do not only focus on automation.
For instance, methods such as in [34] utilise bow-tie diagrams to com-
pose a safety architecture. Broadly, with the use of bow-tie diagrams it is
possible to link identified hazards with their causes (using FTA) on one side
rna

and the consequences (using Event Tree Analysis) on the other, which also
capture the corresponding probabilistic information. The authors strate-
gically adopted this approach to address practical considerations in safety
case development of small unmanned aircraft systems (sUAS). This includes
maintaining consistency across diverse safety artifacts and ensuring that any
changes to the architecture are well-justified allowing them to streamline the
decision-making process. This approach is novel, and based on the authors,
the safety case produced from the artifacts generated through their method
Jou

was approved by the corresponding regulatory authority. Andromeda dif-

fers in a couple of ways. First, our framework uses abstract requirements,
making it more generic and adaptable to various industries with only a few
changes whereas their method focuses on the sUAS. Secondly, the argument
generated with our approach, which is one of the key parts of a safety case,
is generated semi-automatically, whereas in [34] there is no indication for au-

47
 Journal Pre-proof

of
tomation capabilities on that front and no instantiated argument is shown.
This means that a more complex system than a sUAS might pose significant
challenges during the assurance stage.

pro
Below, we explore various approaches that utilise model-driven develop-
ment or MBSA to deliver substantial benefits to both the assessment and
assurance parts of the safety framework.
In [35], the authors presented their work in argument pattern composi-
tion. Specifically, they provided a formal foundation for producing complex
argument patterns by combining a number of simpler patterns or by ab-
stracting established arguments. Additionally, they implemented a pattern
instantiation mechanism in their tool, AdvoCATE, which allowed them to

re-
create argument structures and effectively automate a significant part of the
safety case synthesis. This method innovatively creates complex argument
patterns that can be easily adapted for any industry and utilises tool-support
with the appropriate algorithms to instantiate these patterns and generate
argument structures. Consequently, the pattern can drastically change de-
pending on the expertise of the safety engineers. In contrast, Andromeda
elicited a pattern from commonalities found in known safety standards and
lP
uses that as a basis to form argument structures. In addition, our method
employs abstract requirements, generated from system models and analysis,
to provide the rationale for how sub-goals support higher-level goals, rather
than using concrete requirements. As a result, this allows for a high-level
framework that can be adapted to various contexts more easily, enabling
broader application. Furthermore, Andromeda also features manual creation
rna

of argument patterns, allowing developers to adapt the patterns and gain

flexibility.
The work proposed in [8], known as the weaving model, helps to estab-
lish interconnections between different information models and GSN patterns
via appropriate semantics. Adhering to the model-based paradigm, this ap-
proach is equipped with automation that facilitates safety case construction
and is supported by a software tool developed within the Eclipse framework.
This method offers a robust foundation for interconnecting models with GSN
Jou

pattern structures and instantiating argument structures given the concrete

information available. However, while model weaving allows for the auto-
matic extraction of data from design and analysis models, it does not directly
generate the appropriate evidence artifacts from the system. Additionally, it
lacks specific reasoning for constructing arguments and does not utilise SILs,
which are essential in multiple industries. Nevertheless, the weaving model

48
 Journal Pre-proof

of
is sufficiently generic to allow for adaptations, and these features could be
implemented in principle.
Another notable methodology, the Assurance Case Centric Engineering

pro
Safety-critical System (ACCESS), is presented in [36], along with its tool-
support, the Assurance Case Management Environment (ACME), for the
development of systems and their assurance cases. The authors explain the
importance of assurance cases for certification, discuss the diverse engineering
artifacts they comprise, and emphasize the impact of their evaluation on the
overall assurance case. They highlight challenges such as the lack of model-
based support in traditional graphical notations. Additionally, they stress
that with the emergence of robotics and autonomous systems, assurance

re-
cases must adapt not only during system development but also during the
operational stage. To address the first challenge, ACCESS employs the Struc-
tured Assurance Case Metamodel (SACM), which offers substantial benefits
over the graphical notations and robust model-based support for creating
and managing assurance case models. They have also implemented formal
verification capabilities that enhance assurance case evaluation by avoiding
argumentation fallacies and increasing confidence. ACCESS comprises five
lP
basic steps, starting with system function specification and concluding with
system designs, an assurance case, and system verification and validation
reports. Additionally, there are two optional steps that support the con-
struction and evaluation of runtime assurance cases, with results recorded
for continuous system improvement.
ACCESS is undoubtably a novel method offering significant benefits, such
rna

as the integration of formal methods and the creation of runtime assurance

cases. Despite both ACCESS and Andromeda providing frameworks for
safety assurance, there are substantial differences. For instance, Andromeda
is a fully integrated method that internally provides all the elements needed
for the semi-automatic generation of safety arguments, including safety anal-
ysis artifacts. In contrast, ACCESS focuses mainly on the automated evalua-
tion of the generated assurance structure through the validation and verifica-
tion of external engineering artifacts. Moreover, Andromeda uses the concept
Jou

of SILs and analysis techniques, as advised by safety standards, to construct

safety cases, while ACCESS primarily utilises formal methods, which are
essential in various applications like software development for safety-critical
systems. To conclude, these two methods are quite distinct, each with its own
benefits and limitations, but could benefit from incorporating features from
each other. For example, Andromeda could be adapted to use formal meth-

49
 Journal Pre-proof

of
ods for software component verification, whereas ACCESS could implement
ASILs to align with guidelines such as the ISO26262.
Finally, in [37], the author investigates numerous open source and com-

pro
mercial tools for assurance cases and highlights his concerns. The main
criteria of this review were ease of use and cybersecurity. In terms of cyber-
security, most of the tools that are developed or heavily utilise the Eclipse
Framework found to introduce security risks due to the conflicts between
Eclipse IDE’s networking protocols and national cybersecurity protocols (per
USA standards). Other tools were either web-based, which means they are
not suitable for classified projects or found to use platforms that were com-
promised in the past. The review indicates that the most robust tools found

re-
to be these without any dependencies from specific platforms. Based on the
second criterion, most tools, with the exception of commercial tools, were
either unavailable, had outdated documentation and required quite the ex-
pertise to be installed or were outdated. There was a third criterion, about
the appropriate use of Model-Based System Engineering in assurance cases,
but the author was mostly reviewing tools that are good candidates for USA
Department of Defence (DoD) use; therefore, it is not appropriate to focus
lP
on it here.
Andromeda’s supporting tool was developed as a standalone application
using C++ under the Qt framework, making it compatible with a variety
of operating systems. Qt offers a wide range of libraries for rendering, user
interface design, and peripheral management, and does not involve any on-
line usage once the application is compiled [38]. This design minimises se-
rna

curity risks since the application is usable offline without dependencies on

third-party platforms. Regarding ease of use, Andromeda’s tool requires no
installation and includes straightforward documentation.
Lastly, the idea behind Andromeda was first conceived and proposed in a
short conceptual paper in [39]. In that paper, we introduced the concept of
building argument structures with a rationale centred on SILs and a struc-
ture that follows the system architecture. The reasoning was twofold. First,
SILS are flexible abstract requirements extensively used by functional safety
Jou

standards, making the approach applicable across various industries and rel-
evant to certification authorities. Secondly, the model-based paradigm was
ideal as it allows for automation, helping to keep up with the pace and com-
plexity of modern systems development, and providing a top-down approach
that enhances traceability, as stressed by regulations.
However, much progress has been achieved since. Our research group

50
 Journal Pre-proof

of
has been developing MBSA tools which have become commercial and pro-
duce evidence artifacts that meet the requirements of standards. Andromeda
introduces a metamodeling infrastructure that enables integration of such so-

pro
phisticated tools. To connect them with assurance structures, we extended
our analysis tool metamodel by adding GSN pattern and argument elements.
This allowed us to extract information from system architectural models into
GSN pattern elements and instantiate the latter to generate an argument
structure. As an integrated method, Andromeda absorbed some of these
features, but both the method and the tool have matured substantially since
then.
Specifically, the initial pattern of safety was generic and trivial. For ex-

re-
ample, practitioners would manually set the top-goal and all the sub-goals
for the argument structure without any considerations of the specific indus-
try. The instantiated argument lacked validation or verification activities’
outcomes because there was no underlying framework to guide the structure.
Andromeda, on the other hand, implements a pattern elicited from common-
alities among standards and provides a solid foundation that covers these
activities, helping to build major parts of the safety case.
lP
Moreover, Andromeda’s metamodel has significantly evolved from earlier
work. Initially, the metamodel was externally connecting the GSN argu-
ment and pattern elements with the HiP-HOPS elements. It now effectively
links all these under a single framework and implements them in the same
tool, eliminating the need for artifacts in the form of Extensible Markup
Language (XML) files from different tools and linking them in an ad-hoc
rna

manner. The primary benefits are that any changes to the system archi-
tecture are now reflected in the argument instantly during design iterations,
increasing efficiency and traceability. Additionally, we expanded our meta-
model by incorporating the different scheme and requirement decomposition
rules recommended by the ISO26262. Consequently, our method now directly
supports safety assurance activities for both the aviation and automotive in-
dustries and can be further adapted for other domains.
Jou

6. Conclusions and Future Work

In this paper, we described our work towards a largely automated safety
assessment and assurance framework for safety-critical systems. Our ap-
proach, Andromeda, is applicable from the early stages of development and
follows the assessment activities in compliance with safety standards to pro-

51
 Journal Pre-proof

of
duce and maintain safety argument structures. It integrates elements from
various areas. Specifically, it facilitates functional design and analysis, safety
activities, requirement allocation and assurance through automation and pro-

pro
vides a solid foundation for constructing safety cases that are essential for the
certification of modern systems. To achieve this, we designed an innovative
metamodel that links together model-based safety analysis, automated and
cost-optimal requirement decomposition and allocation via a sophisticated
optimisation algorithm, key common elements across various safety standards
and the concept of argument patterns accompanied by an instantiation algo-
rithm responsible for automatically constructing the concrete argument. We
developed a safety assessment and assurance method that is adaptable, and

re-
supported by a software engineering tool, which can be employed directly
for practical use in safety assessment and assurance. Furthermore, both the
metamodel and the tool are easily customizable and therefore usable as a
foundation for future methods that follow the model-based paradigm.

6.1. Limitations
Despite the strengths of Andromeda, it comes with certain limitations.
lP
First and foremost, the approach is subject to the “garbage in, garbage out”
(GIGO) principle. This means the quality of the work products generated
by the method is dependent on the quality of the inputs. For example, if the
failure annotation by the safety engineer is not appropriate, then the minimal
cut sets and the abstract requirements will not be correct either. As a result,
the produced argument will not reflect the true safety state of the system
rna

since its evidence is compromised. However, the arguments constructed in

Andromeda are explicit and subject to scrutiny. Typically, arguments un-
dergo evaluation, which is possible due to the traceability, and enhancements
before being delivered to regulatory bodies. As for the validity of the alloca-
tion of requirements, these can be checked during development. The failure
model can be examined by experienced practitioners before submission, and
the fault trees generated in Andromeda, which form a significant part of
the evidence, can be assessed using mathematical models within the tool.
Jou

Requirement optimisation results can also be manually tested for validity.

Overall, it is much harder to scrutinise an argument when it is written on
paper rather than in a software tool where most of the results are linked to
system models and can be traced back.
Currently, Andromeda focuses mostly on product-based arguments, which
address safety issues with functions, systems, and components. However,

52
 Journal Pre-proof

of
modern standards also examine other factors that indirectly affect system
safety, such as organisational processes or practitioner competency. These
are known as process-based arguments, and their implementation could bene-

pro
fit Andromeda by bolstering confidence in evidence artefacts and claims. For
instance, an experienced safety engineer is unlikely to introduce many errors
when annotating the system model with failure behaviour data compared
to an inexperienced one. Our tool allows the user to introduce such infor-
mation. The argument pattern can easily be extended manually, and there
are appropriate structures in place to capture this information. However, we
have not utilised it yet on any substantial examples or case studies.
Another limitation is that Andromeda does not incorporate formal meth-

re-
ods and therefore lacks the ability to support mathematically rigorous veri-
fication and validation techniques, which are useful for various applications,
including the development of software for safety-critical systems. Finally, al-
though Andromeda is generic, it still requires modification to be usable in a
new industry such as by adjusting the analysis methods used or by modifying
the structure of the safety pattern.
Finally, we would like to discuss a practical limitation regarding the ar-
lP
gument structure itself. Currently, we provide justifications and assumptions
that are fixed within the pattern. While the pattern allows these elements
to scale along with the system, thus maintaining consistency between high-
level and lower-level arguments elements of the same node type, it lacks
dynamic behaviour. For instance, an assumption stating, “Hazards have
been addressed during X process” applies uniformly to all similar nodes in
rna

the hierarchy. This may be acceptable in some cases, but it could also be
unwanted behaviour depending on the scenario. Furthermore, if there is an
element lower in the architecture requiring a justification that is not neces-
sary at higher-levels, the practitioner must manually extend the pattern to
that level to create the abstract element and supply the needed justifications
or evidence, such as simulation results or other specialised tests.
As part of our ongoing work, we have explored this issue in detail and
developed a solution. Each system element can be extended with a list of jus-
Jou

tification and assumption expressions, allowing the safety engineer to provide

relevant context in the form of templates. This feature enables the dynamic
addition of assumptions and justifications as text integrated with parame-
terised expressions at any time. During the instantiation stage, if a system
element has any assumptions or justifications, these will be automatically in-
cluded in the argument, even if they are not present in the argument pattern.

53
 Journal Pre-proof

of
With the help of parameterised expressions, we can dynamically extract rele-
vant information from the models and provide appropriate context and data.
This solution minimizes the need to extend the pattern unnecessarily, and it

pro
is currently in the implementation phase.
We do not claim that Andromeda produces a complete safety case, mean-
ing the argument is not directly usable for certification purposes. It needs to
be scrutinised and undergo enhancement and potentially modification before
handled to the authorities. In addition, there are artifacts from simulations
and specialised tests that might be necessary for a safety case that are not
produced by the tool. There are proper entities in our framework to capture
these in the argument, but the artifacts have to be generated by external

re-
sources and imported later in Andromeda. Despite these, the work products
created are still valuable and would be challenging to produce manually for
large scale systems.

6.2. Future Work

Currently, our focus has been on the generation of artifacts and argument
structures for safety cases. Despite our best efforts to make our approach
lP
applicable across various industries, many assumptions remain regarding the
structure of the input for the case generator. In that regard, we see great
potential to further evolve Andromeda by introducing a standardized and ho-
mogenous language for specifying inputs across more domains. Therefore, we
plan to integrate other methods for systematizing the nominal development
process, allowing our approach to leverage the yielded relationships between
rna

requirements, architecture, V&V planning, testing results, and other argu-

ment evidence. This will enable the programmatic construction of the rele-
vant assurance cases. Further benefits include enhanced capability for main-
taining and updating the assurance case as the nominal development model
is modified, building on the already established benefits of semi-automation,
such as effort reduction, consistency, and scalability.
In addition to the previous avenues for future work, we plan to seek
external validation from industry experts on the applicability of Andromeda
Jou

and receive user-experience feedback on the tool.

7. Acknowledgements
This work was funded by the EU H2020 SESAME project (grant agree-
ment 101017258).

54
 Journal Pre-proof

of
References
[1] N. G. Leveson, Engineering a safer world: systems thinking applied to
safety (engineering systems), MIT Press Cambridge (2011).

pro
[2] C. H.-C. QC, The nimrod review, An Independent Review into the
Broader Issues Surrounding the Loss of the RAF Nimrod MR2 Aircraft
XV230 in Afghanistan in 2006 (2009).
[3] T. P. Kelly, et al., Arguing safety: a systematic approach to managing
safety cases, Ph.D. thesis, Citeseer, 1999.
[4] A. C. W. Group, Goal Structuring Notation Community Standard Ver-
re-
sion 3, Technical Report, Safety-Critical Systems Club, 2021. Online at:
https://scsc.uk/r141C:1?t=1. Last accessed on: 15/07/24.
[5] Ministry of Defence, 00-56 safety management requirements for defence
systems, 1996. MoD (1996a), UK.
[6] International Organization for Standardization, Iso 26262: Road vehi-
lP
cles – functional safety, 2018. Parts 1-12.
[7] S. Nair, J. L. de la Vara, M. Sabetzadeh, D. Falessi, Evidence manage-
ment for compliance of critical systems with safety standards: A survey
on the state of practice, Information and Software Technology 60 (2015)
1–15.
rna

[8] R. Hawkins, I. Habli, D. Kolovos, R. Paige, T. Kelly, Weaving an assur-

ance case from design: a model-based approach, in: 2015 IEEE 16th In-
ternational Symposium on High Assurance Systems Engineering, IEEE,
2015, pp. 110–117.
[9] N. G. Leveson, The use of safety cases in certification and regulation,
Engineering Systems Division (ESD) Working Paper Series (2011).
[10] E. Denney, G. Pai, I. Habli, Dynamic safety cases for through-life safety
Jou

assurance, in: 2015 IEEE/ACM 37th IEEE International Conference on

Software Engineering, volume 2, IEEE, 2015, pp. 587–590.
[11] A. Joshi, M. P. Heimdahl, S. P. Miller, M. W. Whalen, Model-based
safety analysis, Technical Report, NASA, 2006. Online at: https://ntrs.
nasa.gov/citations/20060006673. Last accessed on: 15/07/24.

55
 Journal Pre-proof

of
[12] SAE International, ARP4754-A: Guidelines for Development of Civil
Aircraft and Systems, revision a ed., SAE International, Warrendale,
PA, 2010.

pro
[13] Radio Technical Commission for Aeronautics, Do-178c: Software con-
siderations in airborne systems and equipment certification, 2011.

[14] P. Bieber, R. Delmas, C. Seguin, Dalculus–theory and tool for de-

velopment assurance level allocation, in: Computer Safety, Reliability,
and Security: 30th International Conference, SAFECOMP 2011, Naples,
Italy, September 19-22, 2011. Proceedings 30, Springer, 2011, pp. 43–56.

re-
[15] L. S. Azevedo, D. Parker, M. Walker, Y. Papadopoulos, R. E. Araujo,
Automatic decomposition of safety integrity levels: Optimization by
tabu search, in: SAFECOMP 2013-Workshop CARS (2nd Workshop
on Critical Automotive applications: Robustness & Safety) of the 32nd
International Conference on Computer Safety, Reliability and Security,
2013, p. NA.
lP
[16] I. Sorokos, Y. Papadopoulos, L. Azevedo, D. Parker, M. Walker, Au-
tomating allocation of development assurance levels: an extension to
hip-hops, IFAC-PapersOnLine 48 (2015) 9–14.

[17] A. Frigerio, B. Vermeulen, K. Goossens, Component-level asil decom-

position for automotive architectures, in: 2019 49th Annual IEEE/IFIP
International Conference on Dependable Systems and Networks Work-
rna

shops (DSN-W), IEEE, 2019, pp. 62–69.

[18] C. Framework, CAE Concepts. Claims Arguments Ev-

idence., Technical Report, CAE Framework, 2020. On-
line at: https://claimsargumentsevidence.org/notations/
claims-arguments-evidence-cae/. Last accessed on: 15/07/24.

[19] O. M. Group, Structured Assurance Case Metamodel (SACM), Tech-

Jou

nical Report, Object Management Group, 2018. Online at: https:

//www.omg.org/spec/SACM/2.0. Last accessed on: 15/07/24.

[20] G. Erich, H. Richard, J. Ralph, V. J. M. D. Patterns, Elements of

reusable object-oriented software, 1994.

56
 Journal Pre-proof

of
[21] Boeing, 787 Airplane Characteristics for Airport Planning, Technical
Report, Boeing, 2023. Online at: https://www.boeing.com/content/
dam/boeing/boeingdotcom/commercial/airports/acaps/787.pdf. Last

pro
accessed on: 15/07/24.

[22] J.-C. Mare, Aerospace Actuators 2 - Signal by Wire and Power by Wire,
Wiley-ISTE, 2017. doi:10.1002/9781119332442.

[23] S. Nidhra, J. Dondeti, Black box and white box testing techniques-
a literature review, International Journal of Embedded Systems and
Applications (IJESA) 2 (2012) 29–50.

re-
[24] I. Sorokos, Y. Papadopoulos, M. Walker, L. Azevedo, D. Parker, Driving
design refinement: How to optimize allocation of software development
assurance or integrity requirements, in: Software Quality Assurance,
Elsevier, 2016, pp. 237–250.

[25] F. A. Administration, 14 cfr part 39. airworthiness directives; the boeing

company airplanes, 2019. Online at: https://www.federalregister.gov/
lP
d/2019-22390. Last accessed on: 15/07/2024.

[26] J. I. Aizpurua, Y. Papadopoulos, G. Merle, Explicit modelling and

treatment of repair in prediction of dependability, IEEE Transactions
on Dependable and Secure Computing 17 (2018) 1147–1162.

[27] J. Lampe, E. Rüde, Y. Papadopoulos, S. Kabir, Model-based assessment

rna

of energy-efficiency, dependability, and cost-effectiveness of waste heat

recovery systems onboard ship, Ocean Engineering 157 (2018) 234–250.

[28] L. da Silva Azevedo, D. Parker, M. Walker, Y. Papadopoulos, R. E.

Araújo, Assisted assignment of automotive safety requirements, IEEE
software 31 (2013) 62–68.

[29] Z. Mian, L. Bottaci, Y. Papadopoulos, N. Mahmud, Model transfor-

mation for analyzing dependability of aadl model by using hip-hops,
Jou

Journal of Systems and Software 151 (2019). doi:10.1016/j.jss.2019.

02.019.

[30] B. Kaiser, P. Liggesmeyer, O. Mäckel, A new component concept for

fault trees, in: Proceedings of the 8th Australian workshop on Safety
critical systems and software-Volume 33, 2003, pp. 37–46.

57
 Journal Pre-proof

of
[31] P. Munk, A. Abele, E. Thaden, A. Nordmann, R. Amarnath,
M. Schweizer, S. Burton, Semi-automatic safety analysis and optimiza-
tion, in: Proceedings of the 55th Annual Design Automation Conference,

pro
2018, pp. 1–6.

[32] R. Wei, Z. Jiang, X. Guo, H. Mei, A. Zolotas, T. Kelly, Designing critical

systems with iterative automated safety analysis, in: Proceedings of the
59th ACM/IEEE Design Automation Conference, 2022, pp. 181–186.

[33] D. J. Parker, Multi-objective optimisation of safety-critical hierarchical

systems, 2010. PhD thesis, The University of Hull.

re-
[34] E. Denney, G. Pai, I. Whiteside, Model-driven development of safety
architectures, in: 2017 ACM/IEEE 20th International Conference on
Model Driven Engineering Languages and Systems (MODELS), IEEE,
2017, pp. 156–166.

[35] E. Denney, G. Pai, Composition of safety argument patterns, in: Com-

puter Safety, Reliability, and Security: 35th International Conference,
lP
SAFECOMP 2016, Trondheim, Norway, September 21-23, 2016, Pro-
ceedings 35, Springer, 2016, pp. 51–63.

[36] R. Wei, S. Foster, H. Mei, F. Yan, R. Yang, I. Habli, C. O’Halloran,

N. Tudor, T. Kelly, Y. Nemouchi, Access: Assurance case centric engi-
neering of safety–critical systems, Journal of Systems and Software 213
(2024) 112034. doi:https://doi.org/10.1016/j.jss.2024.112034.
rna

[37] K. P. Roback, Review of Potential Assurance Case Tool Options for

DoD, Technical Report, Institute for Defense Analyses, 2023. On-
line at: https://apps.dtic.mil/sti/citations/trecms/AD1211550. Last ac-
cessed on: 15/07/2024.

[38] Qt Group, Quick start with qt for python, 2024. URL: https://doc.qt.
io/qtforpython-6/quickstart.html#quick-start, accessed: 2024-08-01.
Jou

[39] A. Retouniotis, Y. Papadopoulos, I. Sorokos, D. Parker, N. Matragkas,

S. Sharvia, Model-connected safety cases, in: Model-Based Safety and
Assessment: 5th International Symposium, IMBSA 2017, Trento, Italy,
September 11–13, 2017, Proceedings 5, Springer, 2017, pp. 50–63.

58
 Journal Pre-proof

Highlights: A Model-Connected Framework for Assessment and Assurance

 Synthesis of safety arguments for a system can be achieved from electronic systems models,
safety analyses, assurance patterns via algorithms. This process is underpinned by a
metamodel that links modelling, analysis and assurance artefacts.

 Patterns that reflect commonalities between emerging safety standards can be elicited, and

of
used for construction of specific safety arguments for systems.

 The cost optimal allocation of safety requirements in the form of SILs to subsystems and
components of a system can be automated using metaheuristics. Provably valid allocations
together with evidence of components meeting their SILs can form a core part of a safety

pro
argument for a system.

re-
lP
rna
Jou
 Journal Pre-proof

of
pro
re-
Yiannis Papadopoulos
lP
Summary

Professor Papadopoulos has pioneered work on model-based dependability assessment and

evolutionary optimisation of complex engineering systems known as Hierarchically Performed Hazard
Origin and Propagation Studies (HiP-HOPS). He co-authored EAST-ADL, an emerging automotive
architecture description language.
rna

These technologies have gained wide academic recognition and have been successfully transferred to
the automotive, shipping and other industries, where they have been commercialised and
successfully deployed in design and engineering processes. He is currently developing technologies
for self-certification of cyberphysical and autonomous systems.

More information about his academic and industrial projects can be found on his personal website
@ https://yipapadopoulos.wixsite.com/yiap
Jou
 Journal Pre-proof

of
pro
re-
lP
Ioannis Sorokos

Summary

Ioannis Sorokos is a senior researcher and project manager at the Fraunhofer Institute for
Experimental Software Engineering (IESE) in the department of Safety Engineering. He received his
PhD from the University of Hull in a topic related to model-based safety assurance. He has
rna

participated in and managed several industry and international research projects, including the
Horizon Europe projects DEIS, BIECO and SESAME. He's a member of the WAISE workshop program
committee and an editor in the Frontiers in Robotics and AI journal for AI Safety in safety-critical
systems. His research interests include model-based safety assurance, safety-security co-
engineering, ML uncertainty and self-adaptive systems.
Jou
 Journal Pre-proof

of
pro
re-
Athanasios Retouniotis

Summary
lP
Athanasios Retouniotis is a software developer with a strong academic background and research
experience in model-based safety assurance. He completed a PhD in Model-Based Systems at the
University of Hull, where he also held a contract position as a Research Assistant within the
Dependable Intelligent Systems Group. During that time, he participated in the Horizon Europe
project DEIS and worked on tool support for the group. In addition to his doctoral studies, he holds a
Master’s degree in Computer Graphics and has keen interests in game development, web
rna

technologies and computer vision.

Jou
 Journal Pre-proof

Declaration of interests

of
☒ The authors declare that they have no known competing financial interests or personal relationships
that could have appeared to influence the work reported in this paper.

☐ The authors declare the following financial interests/personal relationships which may be considered
as potential competing interests:

pro
re-
lP
rna
Jou