A Model-based System Engineering Plugin for Safety Architecture

Pattern Synthesis

Yuri Gil Dantas

1

, Tiziano Munaro

1

, Carmen Carlan

1

, Vivek Nigam

Alexander Pretschner

1, 3

, Ulrich Sch

¨

opp

1

and Sergey Tverdyshev

2

1

fortiss GmbH, Munich, Germany

fi

Keywords:

Model-based System Engineering, Safety Architecture Patterns, Automation, Tooling.

Abstract:

Safety architecture patterns are abstract representations to address faults in the system architecture. In the

current state of practice, the decision of which safety architecture pattern to deploy and where in the system

architecture is carried out manually by a safety expert. This decision may be time consuming or even lead

to human errors. This paper presents Safety Pattern Synthesis, a tool for automating the recommendation of

safety architecture patterns during the design of safety-critical systems: 1) Safety Pattern Synthesis recom-

mends patterns to address faults in the system architecture (possibly resulting in more than one architectural

taken from the automotive domain.

1 INTRODUCTION

Safety architecture patterns, such as the Homoge-

neous Duplex or the Triple Modular Redundancy pat-

terns, are deployed to avoid harm due to faults trig-

gering failures, such as erroneous function or loss

of function (Avizienis et al., 2004). An advan-

tage of making use of such patterns in practice is

that their goal and development are well understood,

and even recommended by standards (ISO26262,

by carrying out a manual safety analysis. As the

complexity of systems grows, it becomes challenging

for experts to make these decisions due to, e.g., time

consuming and human error issues. Moreover, since

these decisions are normally made in early stages of

design, potential errors or sub-optimal designs may

result in high development delays and costs.

Current safety-critical systems are character-

ized by an ever-increasing number of highly inter-

dependant requirements, functions and subsystems.

The safe integration of critical and non-critical com-

adds additional complexity to determine an architec-

ture configuration that satisfies all constraints (in par-

ticular in terms of safety and performance).

The inherent abstraction introduced by Model-

Based System Engineering (MBSE) has the poten-

tial to meet these challenges, as it has been shown

in e.g., an model based engineering approach for

mixed-criticality systems (Barner et al., 2017), the

model-based architecture exploration approach intro-

duced by Eder et al. (Eder et al., 2018b)(Eder et al.,

2018a)(Eder et al., 2020), or in the approaches by

itation of the existing approaches for safety archi-

tecture patterns is that it does not provide the type

of automation successfully applied in other develop-

ment phases, such as in optimizing deployment strate-

gies (Eder et al., 2018b).

ture patterns in an automated fashion. To this end,

we have developed a plugin within the MBSE tool

AutoFOCUS3 (Aravantinos et al., 2015) to enable the

during a safety analysis, in particular by assisting with

the selection of patterns to ensure the required func-

tional safety of the system architecture. To the best

of our knowledge, Safety Pattern Synthesis is the first

MBSE tool that enables the automated recommenda-

tion of safety architecture patterns.

The development of Safety Pattern Synthesis has

been motivated by concrete use-cases provided by

our industry partner. In this paper, we illustrate how

tion to help the reader to understand the results pre-

sented in the paper. Section 3 describes Safety Pattern

tion details. Safety Pattern Synthesis is validated in

Section 4 using an industry use-case. Finally, we con-

clude the paper by pointing out to related and future

work in Sections 5 and 6.

2 BACKGROUND

AutoFOCUS3 (AF3) is a model-based open source

tool and research platform for safety-critical embed-

ded systems (fortiss GmbH, 2020). AF3 builds on

the Eclipse platform and supports the design, devel-

software integration.

of models. The task and partition architectures

represent the hardware-independent interaction of

software tasks and their aggregation into partitions,

and the platform architecture describes the system’s

hardware including its properties and topology.

Finally, the distinct models are linked by means of

allocations, defining, e.g., the deployment of tasks to

hardware units.

We briefly review some basic safety concepts to set

of a function. An error is a deviation of the expected

system behavior. A fault is the hypothesized cause

of an error. A failure triggered by a fault may lead

to a hazard. Normally, failures are associated with a

set of predefined Guidewords that characterize intu-

itively the semantics of such failures. Examples of

Guidewords are loss and erroneous that denote, re-

spectively, a failure due to the loss of a function, i.e.,

a function not operating whatsoever, and a failure due

to an erroneous function behavior, e.g., a function not

A safety architecture pattern (safety pattern for

short) is an architectural solution for tolerating faults

in the system architecture. A fault detection pattern

deactivates the system in the presence of a failure

(triggered by a fault) by either transitioning the sys-

tem to a safe state (e.g., informing the driver to take

over the vehicle control) or shutting down the system.

A fault tolerant pattern ensures that the system will

given the redundant component. A fault tolerant pat-

tern may also transition the system to a safe state or

shutdown the system in the presence of a failure in the

redundant component.

Examples of safety patterns are Homogeneous

which patterns and where in the system architecture

they shall be deployed. These reasoning principles

are automated by the DLV engine.

SAFPAT currently supports the following safety pat-

terns: Acceptance Voting, Homogeneous Duplex, Het-

erogeneous Duplex, Monitor-Actuator, Simplex Ar-

chitecture, and Triple Modular Redundancy.

hardware faults;

• homogeneousDuplex is suitable for avoiding FL’s

type of failure (i.e., erroneous or loss);

• homogeneousDuplex is suitable for addressing

the ASIL of HZ. Since the Homogeneous Duplex

pattern is suitable for ASIL D, it is also suitable

for lower levels, i.e., ASIL A, B and C.

• the safety mechanism type (i.e., fault tolerant or

detection) of heterogeneousDuplex matches the

type of the safety mechanism chosen by the user.

SAFPAT may provide multiple architectural solu-

tions as output, with different safety patterns for each

solution. For example, possible patterns for tolerat-

ing a software fault include the use of either the Ac-

ceptance Voting pattern or the Heterogeneous Duplex

pattern. The user may select the most suitable system

architecture with patterns based on some criteria such

rules check whether the ASIL of SW1 is higher than

the ASIL of HW1. If this condition is true, SAFPAT

provides a requirement to allocate SW1 to a hardware

component with the same ASIL of SW1.

We refer the interested reader to (Dantas et al.,

2020) for the detailed description about SAFPAT, in-

cluding its reasoning principles rules.

3 SAFETY PATTERN SYNTHESIS

based system engineering tool AutoFOCUS (AF3)

for recommending safety patterns. Figure 1 depicts

the artifacts that are used by Safety Pattern Synthesis

(system architecture and safety elements) and which

artifacts are produced (system architecture with pat-

ponents (tasks or hardware units) may be assigned

to the ASIL that such components shall be imple-

mented. We assume that the system architecture

is designed following an model-based engineer-

ing approach, e.g., developed in AF3.

• Safety Elements: This artifact consists of the

results from a safety analysis

carried out by a

safety engineer on the designed system architec-

ture. This consists of hazards, faults and fail-

recommends safety architecture patterns based on

the system architecture and safety elements. The

reasoning on which pattern to select and where

to place the selected pattern in the architecture is

1

In our example described in Section 4, the safety anal-

ysis was carried out using the STPA method

performed with the help of SAFPAT (described in

Section 2.3). Safety Pattern Synthesis generates

the use of either the Homogeneous Duplex pat-

tern or the Triplex Modular Redundancy pat-

tern. The user of Safety Pattern Synthesis shall

then select the most suitable architecture for the

system. Section 3.1 provides some criteria to

assist the user in selecting the architecture.

– Requirements: Safety Pattern Synthesis pro-

vides requirements that shall be implemented

during system development. In particular,

with the ASIL assigned to tasks.

The following section describes the high-level ar-

chitecture of Safety Pattern Synthesis, including im-

plementation details and how an user interacts with

The architecture of Safety Pattern Synthesis is illus-

trated by Figure 2. Safety Pattern Synthesis has been

developed, as part of the AF3 framework, in Java

(frontend) and DLV (backend), and currently works

• Safety Elements Wizard: This component pro-

vides a wizard to enable users to define the safety

elements obtained from a safety analysis. The

component requires an interface to the designed

ments. Firstly, the user defines a hazard consist-

ing of the hazard’s description and its ASIL. Sec-

ondly, the user selects the (possibly) faulty com-

ponents (either tasks for software faults or ECUs

for hardware faults). Thirdly, for each selected

fault, the user defines the type of failure (either

erroneous or loss) triggered by the fault.

Finally,

the user defines which type of safety mechanism

(either fault detection of fault tolerant) shall toler-

plemented in Java) to SAFPAT (which is imple-

mented in DLV). We transform AF3 system archi-

tecture models and safety element models (speci-

fied in the wizard) to SAFPAT models. Figure 3 il-

lustrates a model-to-model transformation from a

task architecture modeled in AF3 to SAFPAT. The

translation is implemented with the help of the

EmbASP framework (EmbASP, 2018). EmbASP

enables the Java representation of predicates that

are specified in a DLV program. We represent in

of the system architecture. Explained in Sec-

tion 2.3, this component is the backend of Safety

2

Currently, Safety Pattern Synthesis supports two

Guidewords, erroneous and loss, which are most commonly

used in methodologies such as HAZOP. We plan in the fu-

ture to incorporate other Guidewords such as early and late.

Figure 2: Architecture of Safety Pattern Synthesis. Gray boxes are artifacts either received as input or generated for output.

Safety Pattern Synthesis generates requirements for each System architecture with patterns (output artifact).

Figure 3: Illustration of a model-to-model transformation

from a task architecture modeled in AF3 (left side) to SAF-

PAT (right side) with the help of EmbASP (illustrated by the

visualizing the solutions obtained from SAFPAT,

including a number of criteria to assist the user

mended and additional requirements. For exam-

ple, the highlighted solution in Figure 5 deploys

an architecture by clicking on the “Select” and

“Export” buttons, respectively.

1. Req 1: not cause the ego vehicle to exceed its

maximum velocity,

As the HWP takes over the complete Dynamic

Driving Task (DDT) as well as Object and Event

Response (OEDR), the system is classified as a

highly safety-critical, ASIL-D rated, level 3 Auto-

mated Driving System (ADS) according to the SAE

J3016 standard (SAEJ3061, 2012)(ISO26262, 2018).

HWP has been designed in AutoFOCUS3 (AF3)

as part of the fortissimo

demonstrator platform. The

HWP architecture consisting of both task and plat-

provide longitudinal and lateral control, respectively

– each according to the HWP’s nominal function. The

Emergency Brake (EB) provides longitudinal control

in case a collision with an obstacle in front of the ve-

hicle is deemed unavoidable. Here, the goal is not

collision avoidance, but mitigation. The system is al-

ways active as such situations can arise both during

manual driving as well as due to a fault of the HWP.

The Motion Control coordinates the desired vehicle

states given by the driving functions and controls the

Table 2 describes the allocation of task to hard-

ware units, as well as the ASIL requirements for each

component (i.e., the ASIL that each component shall

be implemented).

Safety Elements. For the sake of our evaluation,

we consider the following safety elements that can be

identified from a safety analysis. The identified safety

elements are not meant to be comprehensive.

Table 3 describes the identified hazards HZ1 and

3

https://www.fortiss.org/en/research/living-lab/detail/

fortissimo

allocation does not comply with the safety integrity level

required (i.e., ASIL D task allocated to ASIL B hardware

unit). The intended outcome is to show that Safety Pattern

Synthesis can provide requirements to ensure the safety in-

tegrity w.r.t. allocations.

Task Hardware Unit

Sensor Data Fusion

[ASIL B]

Host SoC (GPU)

[ASIL B]

ACC

[ASIL D]

MCU

[ASIL D]

Table 3: Identified hazard for the HWP system.

Hazard Description ASIL

HZ1 The vehicle violates the safety

distance to other road users or

objects on the road.

D

HZ2 Unintended emergency brake. B

• FT1: A software fault occurs in the algorithm im-

plemented by the task implementing ACC causes

the provided target deceleration value not be high

enough to reach the safety distance between vehi-

gered by fault FT4 may lead to hazard HZ2.

Consider the system architecture and the safety ele-

ments described in Section 4.1. We run Safety Pat-

the identified faults and address the identified hazards.

lutions for tolerating the identified faults. The recom-

mended safety patterns are described in Table 4. Con-

sidering that both the system architecture has been

Monitor Actuator pattern is applied to EB. Both ACC

(V2) and Fault Detector tasks are created to toler-

ate the software faults that may be present in ACC

(V1). That is, if one fault is detected in ACC (V1),

the function ACC will continue operating using the

outputs from ACC (V2). This solution contains addi-

tional requirements to be implemented to ensure that

the pattern works as intended such as ACC (V1) and

ACC (V2) tasks shall be developed using different de-

sign, and for safety integrity such as ACC (V2) and

the Monitor Actuator task shall implement a timeout

algorithm to detect failures of type loss triggered by

a fault in Vector Cores. This requirement is provided

by Safety Pattern Synthesis to be realized during the

system development.

ensure safety integrity w.r.t. allocations. Consider the

Figure 5: Screenshot of the wizard for visualizing architectural solutions with patterns. It includes the recommended patterns,

the additional requirements to be implemented during the system development, and some criteria to assist the user in selecting

the most suitable architecture for the system.

allocation of the Motion Control [ASIL D] to AI SoC

[ASIL B] in Table 2. This allocation does not comply

of this work, but that are important for Safety Pattern

Handling Potential Design Option Explosion.

high number of solutions to be selected by the user,

as shown in Table 4. Currently, Safety Pattern Syn-

the user with this decision. We are investigating fur-

ther criteria used, for example, by AutoFOCUS3 for

design space exploration (Eder et al., 2020), such as,

Towards Incremental Development. In this work,

we consider only one development loop. That is, once

loops are involved. For example, consider an architec-

ture with safety patterns, possibly recommended by

Currently Safety Pattern Synthesis would recommend

new safety patterns without modifying the existing

ones. This may not lead to optimal solutions as it does

not exploit synergies between patterns, e.g., a safety

pattern that provide more fault tolerance can subsume

other weaker patterns. It seems possible to use Safety

cialized engines, such as SMT-solvers, have been

used in industry projects (Eder et al., 2020) for other