Digital Dependability Identities and the Open ...

Digital Dependability Identities and the Open Dependability

Exchange Meta-Model D3.1

This deliverable provides the specification of the Open Dependability Exchange meta-model and

documentation of the fundamental concept of Digital Dependability Identities, to be updated and

extended by deliverables D3.2 and D3.3.

www.deis-project.eu

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant

agreement No 732242 (DEIS).

http://www.deis-project.eu/

Digital Dependability Identities and the Open Dependability Exchange Meta-Model

Page 1 of 65

Table of Contents

1 Publishable executive summary ............................................................................................................ 6

2 Introduction .......................................................................................................................................... 7

3 The ODE – Conceptual overview ........................................................................................................... 9

3.1 The general concept and structure of the ODE ........................................................................... 10

3.2 Refining the content of the ODE based on engineering stories .................................................. 13

3.3 The SACM as a backbone for the ODE ......................................................................................... 15

3.3.1 SACM overview.................................................................................................................... 15

3.3.2 SACM meta-model .............................................................................................................. 16

3.3.3 Usage of the SACM in the DEIS context ............................................................................... 20

3.3.4 System assurance case integration example ....................................................................... 21

3.4 ODE dependability packages ....................................................................................................... 24

3.4.1 ODE meta-model overview.................................................................................................. 24

3.4.2 Architectural modelling package ......................................................................................... 27

3.4.3 Hazard and risk analysis (HARA) package ............................................................................ 29

3.4.4 Failure logic modelling package ........................................................................................... 30

3.4.5 Dependability requirements package .................................................................................. 33

3.4.6 Crosscutting concerns ......................................................................................................... 34

4 Related work ....................................................................................................................................... 35

4.1.1 Safety argumentation .......................................................................................................... 35

4.1.2 Architectural modelling ....................................................................................................... 36

4.1.3 Failure logic modelling ......................................................................................................... 38

4.1.4 Hazard and risk assessment................................................................................................. 41

4.1.5 Safety requirements modelling ........................................................................................... 43

5 DEIS engineering stories ...................................................................................................................... 44

5.1 ES1: Multi-tool interoperability for dependability artefact exchange ......................................... 44

5.2 ES2: Protection of intellectual property in distributed development scenarios .......................... 45

5.3 ES3: Integration of safety case fragments into a system safety case .......................................... 46

5.4 ES4: Failure interface compatibility matching during design time system integration ................ 47

5.5 ES5: Trade-off support for RAMS property optimisation at design time ..................................... 47


Page 2 of 65

5.6 ES6: Synthesis of dependability runtime models for safe system of systems integration at runtime

47

5.7 ES7: Modelling of security aspects and safety analysis with respect to malicious reasons ......... 50

6 Utilisation of DDIs in an OEM-TIER integration scenario in the context of the ETCS ........................... 51

6.1 Use case overview ....................................................................................................................... 51

6.2 ES1: Multi-tool dependability artefact exchange in ETCS ............................................................ 52

6.3 ES3: Integration of safety case fragments into a system safety case .......................................... 53

7 Synthesis of runtime DDIs and utilisation in a system-of-systems scenario in the context of a traffic

light assistant ............................................................................................................................................... 55

7.1 Use case overview ....................................................................................................................... 55

7.2 ES6: Synthesis of dependability runtime models for safe system-of-systems integration at runtime

56

8 Summary and outlook ......................................................................................................................... 61

9 References ........................................................................................................................................... 62


Page 3 of 65

List of Figures

FIGURE 1 - DEIS OBJECTIVES REGARDING THE DDI (TAKEN FROM THE DEIS PROPOSAL) ....................................................................... 9

FIGURE 2 - TYPES OF DDI .......................................................................................................................................................... 10

FIGURE 3 - SACM-BASED SAFETY ARGUMENTATION AS THE BACKBONE OF A DDI .............................................................................. 11

FIGURE 4 - INTEGRATION SCENARIO WHERE THE ASSURANCE CASE MODELS ARE THE BACKBONE OF THE DDI.......................................... 12

FIGURE 5 - HIGH-LEVEL STRUCTURE OF THE ODE .......................................................................................................................... 13

FIGURE 6 - DEIS APPROACH W.R.T. REFINING THE CONCEPT OF DDI AND THE ODE ........................................................................... 14

FIGURE 7 - INFLUENCING FACTORS OF THE ODE META-MODEL WITHIN DEIS .................................................................................... 15

FIGURE 8 - SACM ASSURANCECASE PACKAGE ............................................................................................................................. 16

FIGURE 9 - SACM BASE PACKAGE .............................................................................................................................................. 17

FIGURE 10 - SACM ARGUMENTATION PACKAGE .......................................................................................................................... 18

FIGURE 11 - SACM ARTIFACT PACKAGE...................................................................................................................................... 19

FIGURE 12 - SACM TERMINOLOGY PACKAGE .............................................................................................................................. 20

FIGURE 13 - STRONG LINK FROM TERM TO MODEL ELEMENTS ....................................................................................................... 21

FIGURE 14 - EXAMPLE OF ODE USAGE IN THE SACM ................................................................................................................... 24

FIGURE 15 - ODE META-MODEL BIG PICTURE .............................................................................................................................. 25

FIGURE 16 - ODE META-MODEL VERSION 1 ............................................................................................................................... 26

FIGURE 17 - ODE::ARCHITECTURE PACKAGE ............................................................................................................................... 28

FIGURE 18 - ODE::DEPENDABILITY::HARA PACKAGE ................................................................................................................... 29

FIGURE 19 - ODE::FAILURELOGIC PACKAGE ................................................................................................................................ 31

FIGURE 20 - ODE::FAILURELOGIC::FTA PACKAGE........................................................................................................................ 32

FIGURE 21 - ODE::FAILURELOGIC::FMEA PACKAGE .................................................................................................................... 32

FIGURE 22 - ODE::FAILURELOGIC::MARKOV PACKAGE ................................................................................................................. 33

FIGURE 23 - ODE::DEPENDABILITY REQUIREMENT PACKAGE ......................................................................................................... 34

FIGURE 24 - ODE::BASE PACKAGE ............................................................................................................................................. 35

FIGURE 25 - THE SPES MODELLING FRAMEWORK (POHL, HÖNNINGER, ACHATZ, & BROY, 2012) ...................................................... 37

FIGURE 26 - MULTI-TOOL INTEROPERABILITY WITH THE HELP OF THE ODE AS EXCHANGE FORMAT ....................................................... 45

FIGURE 27 - DIFFERENT LEVELS OF DETAILS EXCHANGED IN DIFFERENT SCENARIOS ............................................................................. 45

FIGURE 28 - SAFETY CASE INTEGRATION WITH THE HELP OF DDIS .................................................................................................... 46

FIGURE 29 - OVERVIEW OF PROCESS STEPS FOR SYNTHESIS OF DESIGN TIME DDI AND RUNTIME DDI .................................................... 49

FIGURE 30 - ERTMS/ETCS REFERENCE ARCHITECTURE ................................................................................................................ 51

FIGURE 31 - INSTANTIATION OF ENGINEERING STORY ES1 FOR THE ETCS USE CASE ......................................................................... 52

FIGURE 32 – EXAMPLE SAFETY CASE FRAGMENT INTEGRATION (ES3) FOR THE ETCS USE CASE ............................................................ 54

FIGURE 33 - OVERVIEW OF VEHICLE SPEED CONTROL WITH FOCUS ON THE TRAFFIC LIGHT ASSISTANT .................................................... 55

FIGURE 34 – SERVICE-ORIENTED ARCHITECTURE FOR TRAFFIC LIGHT ASSISTANT SYSTEM ...................................................................... 57

FIGURE 35 - EFFECT ANALYSIS OF SERVICE DEVIATION AT TLA INPUT INTERFACE ................................................................................ 57

FIGURE 36 - SAFETY ANALYSIS OF THE TLA FUNCTION REGARDING SAFETY GOAL VIOLATION ................................................................ 58

FIGURE 37 - INSTANTIATION OVERVIEW OF ES6 FOR THE TRAFFIC LIGHT ASSISTANT SYSTEM ................................................................ 60


Page 4 of 65

Abbreviations

Abbreviation Long Version

AADL Architecture Analysis and Design Language

ACME Assurance Case Modelling Environment

ACP Assurance Case Package

CBD Component-based design

CCF Common Cause Failure

CFT Component Fault Tree

C²FT Component-integrated Fault Tree

ConSert Conditional Safety Certificate

CPS Cyber-Physical System

DDI Digital Dependability Identity

ETCS European Train Control System

ES Short for engineering story

FHA Functional Hazard Analysis

FMEA Failure mode and effects analysis

FMEDA Failure mode effects and diagnostic analysis

FTA Fault tree analysis

GSN Goal Structuring Notation

HARA Hazard and Risk Analysis

HiP-HOPS Hierarchically Performed Hazard Origin and Propagation Studies – Dependability technique developed at the University of Hull

HSE Health, Safety and Environment

IP Intellectual property

MDT Mean Down Time

OCL Object Constraint Language standardized by OMG

ODE Open Dependability Exchange Meta-Model

OEM Original Equipment Manufacturer

OSM Open Safety Meta-Model developed at Fraunhofer IESE

RAMS Reliability, Availability, Maintainability, Safety


Page 5 of 65

SACM Structured Assurance Case Meta-Model

SoS System of systems

TLA Traffic Light Assistant

V2I Vehicle To Infrastructure communication

Authors

Name, Partner E-mail

Jan Reich, Fraunhofer IESE

Daniel Schneider, Fraunhofer IESE

Rasmus Adler, Fraunhofer IESE

[email protected]

[email protected]

[email protected]

Ran Wei, University of York

Tim Kelly, University of York

[email protected]

[email protected]

Ioannis Sorokos, University of Hull [email protected]

Marc Zeller, Siemens

Joe Guo, Siemens

Christof Kaukewitsch, Siemens

[email protected]

[email protected]

[email protected]

Georg Macher, AVL

Eric Armengaud, AVL

[email protected]

[email protected]

mailto:[email protected]












Page 6 of 65

1 Publishable executive summary Cyber-Physical Systems (CPS) provide enormous potential for new types of applications, services and

business models in any embedded systems domain, such as automotive, rail, healthcare or home

automation. Overall, we anticipate a future of heavily interconnected, distributed, heterogeneous and

intelligent systems, which are bound to have a significant economical and societal impact in the years to

come.

However, several challenges need to be tackled before the full potential of CPS can be unlocked. One core

challenge is to ensure the trustworthiness and dependability of single and composite systems, as

established approaches and standards were designed with closed standalone systems in mind, thus

building on a complete understanding and analysability of a system and its relevant environment. As this is

no longer a given, we urgently require new types of approaches that do not (solely) rely on this basic

assumption (now rendered void).

A general solution concept involves shifting parts of the assurance activities into runtime, where unknowns

and uncertainties can be resolved dynamically. To this end, it is necessary to equip the constituent systems

with dedicated and adequate modularised and formalised dependability information. The key innovation

that is the aim of DEIS is the corresponding concept of a Digital Dependability Identity (DDI). A DDI contains

all the information that uniquely describes the dependability characteristics of a CPS or CPS component.

DDIs are synthesised at development time and are the basis for the (semi-)automated integration of

components into systems during development, as well as for the fully automated dynamic integration of

systems into systems of systems in the field.

In this deliverable, we present our initial version of the meta-model for the DDI – the ODE (Open

Dependability Exchange meta-model). We first describe the core concepts at an abstract level and sketch

how we utilised the project’s industrial use cases to engineer the ODE. We then delve deeper into the

details and describe the Structured Assurance Case Meta-Model (SACM) and its extension mechanisms,

which constitute the backbone of the ODE. We further describe some initial auxiliary modular ODE

packages, which provide coverage for architectural modelling, hazard and risk analysis, failure logic

modelling and dependability requirements, respectively. Based on this modular-package-based structure,

we plan to add further ODE packages covering additional concerns in the later stages of the project. The

design (and validation) of all of these meta-models is driven by engineering stories that are based on the

DEIS industrial use cases. For the time being, we have focused on specific engineering stories and use cases,

i.e., those that were suited best for the initial ODE packages listed above. Later in the project, when we

design further ODE packages (e.g., for security concerns), the focus will correspondingly be shifted to

different engineering stories and use cases.

This deliverable is closely related to D4.1, which describes the current state of the tool implementations.

DEIS aims at providing comprehensive tool support for DDI, covering the supported/semi-automated

synthesis of DDI as well as the (semi-)automated integration at development time. Moreover, it is our aim

to support multi-tool scenarios, where DDI are exchanged and evolved among different development

teams and tools.


Page 7 of 65

2 Introduction Cyber-Physical Systems (CPS) provide enormous potential for new types of applications, services and

business models in any embedded systems domain, such as automotive, rail, healthcare or home

automation. Overall, we anticipate a future of heavily interconnected, distributed, heterogeneous and

intelligent systems, which are bound to have a significant economical and societal impact in the years to

come.

However, several challenges need to be tackled before the full potential of CPS can be unlocked. One core

challenge is to ensure the trustworthiness and dependability of single and composite systems, as

established approaches and standards were designed with closed standalone systems in mind, thus

building on a complete understanding and analysability of a system and its relevant environment. As this is

no longer a given, we urgently require new types of approaches that do not (solely) rely on this basic

assumption (now rendered void).

A general solution concept involves shifting parts of the assurance activities into runtime, where unknowns

and uncertainties can be resolved dynamically. To this end, it is necessary to equip the constituent systems

with dedicated and adequate modularised and formalised dependability information. The key innovation

that is the aim of DEIS is the corresponding concept of a Digital Dependability Identity (DDI). A DDI contains

all the information that uniquely describes the dependability characteristics of a CPS or CPS component.

DDIs are synthesised at development time and are the basis for the (semi-)automated integration of

components into systems during development, as well as for the fully automated dynamic integration of

systems into systems of systems in the field.

In this deliverable, we present our initial version of the meta-model for the DDI – the ODE (Open

Dependability Exchange meta-model). In section 3, we will first describe the core concepts at an abstract

level and sketch how we utilised the project’s industrial use cases to engineer the ODE. We will then delve

deeper into the details and describe the Structured Assurance Case Meta-Model (SACM) and its extension

mechanisms, which constitute the backbone of the ODE. We will further describe some initial auxiliary

modular ODE packages, which provide coverage for architectural modelling, hazard and risk analysis, failure

logic modelling and dependability requirements, respectively. Based on this modular-package-based

structure, we plan to add further ODE packages covering additional concerns in the later stages of the

project. The design (and validation) of all of these meta-models is driven by engineering stories that are

based on the DEIS industrial use cases. For the time being, we have focused on specific engineering stories

and use cases, i.e., those that were suited best for the initial ODE packages listed above. Later in the project,

when we design further ODE packages (e.g., for security concerns), the focus will correspondingly be shifted

to different engineering stories and use cases.

After providing an overview of the DEIS engineering stories in Section 5, we will focus on some specific

engineering stories in the context of the European Train Control System (ETCS) and Traffic Light Assistance

(TLA) use cases. These are examples extracted from industrial use cases to showcase the developed DEIS

technologies. Note that we do not claim full correctness and completeness regarding the actual use cases

(developed in DEIS work package 5) in sections 6 and 7, as those use cases were modified and simplified in


Page 8 of 65

order to illustrate the DEIS technology in a more realistic setting. In the case of ETCS, we will focus on multi-

tool dependability artefact exchange and on the integration of safety case fragments into a system safety

case. In the case of TLA, we will focus on the synthesis of dependability runtime models for safe system-of-

systems integration at runtime.

This deliverable is closely related to D4.1, which describes the current state of the tool implementations,

captures the DDI concept by means of a corresponding meta-model profile and elaborates the current state

of the tool implementations. DEIS aims at providing comprehensive tool support for DDIs, covering the

supported/semi-automated synthesis of DDIs as well as the (semi-)automated integration at development

time. Moreover, it is our aim to support multi-tool scenarios where DDIs are exchanged and evolved among

different development teams and tools. Moreover, both this deliverable and D4.1 are related to D2.2, which

describes the refined project requirements for semi-automation, i.e., the corresponding tool requirements

that are derived from the envisioned synthesis, utilisation and composition of DDIs in the context of the

engineering stories described in Sections 6 and 7.


Page 9 of 65

3 The ODE – Conceptual overview

The ODE (Open Dependability Exchange meta-model) is the meta-model for the DEIS core concept – the DDI

(Digital Dependability Identity) – and thus a central artefact of the project. It needs to be fit for the DEIS

core challenges and objectives as described in the proposal and refined in deliverables D2.1, D5.1 and D6.1.

Figure 1 summarises the main objectives of DEIS with respect to DDIs, i.e.:

• Support their engineering and modelling;

• Enable semi-automated generation (i.e., support the engineers in their creation) and integration

as well as IP protection (i.e., support the engineers in integrating a supplier component into an

OEM product, for example);

• Automated integration of DDIs in the field (i.e., in the fully automated integration of systems in a

system-of-systems context, the DDIs are utilised to assess and manage the relevant dependability

properties of the integration).

Figure 1 - DEIS objectives regarding the DDI (taken from the DEIS proposal)

In order to be fit for these different objectives throughout the system lifecycle, a DDI may assume different

forms, which differ regarding their level of abstraction and the amount of information they contain. We

found that the three corresponding levels illustrated in Figure 2 are a reasonable categorisation in this

regard. The white-box type DDI gives full details regarding all relevant dependability engineering artefacts

such as argumentation or failure logic models. The grey-box type DDI can have the same comprehensive

range of information but, for instance for the sake of IP protection, abstracts certain aspects. An example


Page 10 of 65

would be that the details of the failure logic models are not included and only the corresponding interfaces

are specified (maybe with a mapping function in between to give some variability). The black-box type DDI

is an abstraction meant to be adequate for fully automated runtime evaluation in a system-of-systems

context. An example are ConSerts (Schneider D., 2013), which specify a set of demands, runtime evidences

and guarantees as well as mapping functions in between.

Figure 2 - Types of DDI

The actual development approach we took with respect to the ODE is twofold.

On the one hand, we used a top-down approach and discussed how a DDI and thus the ODE should be

designed, based on our comprehensive previous work, experience and expertise in the consortium. This

activity is briefly described in Section 3.1 and resulted in the definition of an initial general (high-level)

concept and structure for the DDI and the ODE.

On the other hand, we used a bottom-up approach starting from the DDI challenges and requirements

from the DEIS use cases. This allowed us to fill in the required details and thus augment and refine the initial

high-level structure and validate it. This activity will be described in Section 3.2.

3.1 The general concept and structure of the ODE

The general concept of the ODE meta-model and the DDI was designed on the basis of the diverse previous

work of the DEIS consortium and the DEIS objectives and vision. A fundamental outcome of the conceptual

discussion was the decision to use SACM 2.0, the Structured Assurance Case Meta-Model of the Object

Management Group, as a core ingredient for the ODE meta-model. Using the SACM entails several

advantages: It is already standardised and relatively mature, which might help us get the DDI concept / ODE

meta-model accepted and adopted eventually. SACM is an exchange format for structured assurance cases

and provides corresponding means for modularisation. These properties render SACM a good candidate

for being utilised as a backbone for the ODE meta-model.


Page 11 of 65

To illustrate the utilisation of the SACM in the context of the ODE, consider the example depicted in Figure

3. It shows how an argumentation structure can be the front and centre artefact within a DDI. All other

relevant artefacts – functional design, hazard and risk analyses or failure logic models – are directly linked

to elements of the argumentation.

Figure 3 - SACM-based safety argumentation as the backbone of a DDI

The integration of different systems, each equipped with a DDI, is then also done by linking the modularised

assurance case fragments of the systems (cf. Figure 4). This means that in an integration scenario, there is

no direct linkage between any other safety engineering artefacts (e.g., failure logic models) beyond the

argumentation (at least not initially). Everything is interlinked and interrelated via the argumentation

structure of the assurance case, which thus constitutes the backbone of all DDIs (regardless of whether the

DDI is a constituent system DDI or an integrated system-of-systems DDI). On this basis, it is also relatively

easy to integrate systems where different failure logic modelling techniques such as HiP-HOPS and CFTs

have been used.

In order to enable semi-automated (or even fully automated) integration of DDIs, it is necessary to formalise

the interfaces of the assurance case fragments sufficiently. Moreover, it is important to enable a certain

extent of flexibility because the assured properties given by a constituent system DDI might not fit exactly

with what is demanded by the superordinate assurance case of the integrating system. Here ConSerts

provide a good starting point, even though the flexibility enabled by ConSerts is still not as good as we

would expect for the development time “white-box” DDI integration scenario. Here we would like to


Page 12 of 65

achieve deeper integration between the different safety engineering artefacts so that, for instance, a

change in the architecture at one point of a constituent system would propagate through different channels

(e.g., failure logic models) and the integrator would see the impact for the overall integrated system on the

level of its safety guarantees. Alternatively, in the grey-box case, the DDI of a constituent system may

provide a bundle of variants that can be switched by the integrator. Even though the details are masked

due to IP protection, the different variants exhibit different properties at the assurance case interface.

Based thereon, optimisation could be performed to find an overall system configuration for the integrating

system (i.e., resolving the variants in the supplier systems) that is optimal with respect to dependability,

cost and performance.

Figure 4 - Integration scenario where the assurance case models are the backbone of the DDI

The examples and elaborations above reveal that an assurance case argumentation is well suited as a

central artefact of a DDI, but that other aspects obviously need to be covered as well. Thus, the ODE cannot

just be a slightly adapted version of the SACM, but rather needs to be a set of interlinked meta-models

covering all relevant dependability concerns. Still, we would like to use the SACM as the DDI interface

language for the reasons mentioned above (standard, acceptance, adoption due to potential widespread

tool support). In addition, there is a mechanism within the SACM that could be utilised to this end: The so-

called terminology package allows arbitrary information to be referenced in an assurance case (in the form

of SACM Expressions/Terms/Categories). In this sense, the SACM is able to link to models (which may

contain system information, FME(D)A, FTA, dependability requirement models etc.). One may choose to

use either a weak link or a strong link. For weak links, the SACM can simply point to the referred model with

text. For strong links, with the help of the facilities provided by the SACM, such information can be retrieved

automatically from the referenced models (by using a model querying language such as the Object

Constraint Language or the Epsilon Object Language). Thus, the SACM can link (either via weak links using

text or via strong links using queries) models which conform to heterogeneous meta-models in order to

extract relevant information.


Page 13 of 65

Figure 5 depicts the corresponding high-level structure of the ODE meta-model. The different relevant

models are integrated into an assurance case via the SACM terminology package. The correspondingly

augmented SACM then constitutes the DDI interface language. Other models might be added or changed

later on, but as long as both the SACM and the DDI terminology part remain untouched, tool

interoperability is assured.

It should be noted that the ODE as shown here focuses on development time integration scenarios and the

corresponding DEIS objectives. For runtime integration scenarios, we expect additional sub-meta-models

to be added. A runtime DDI should be generated out of a development time DDI (as depicted here); once

generated, it might only conform to a dedicated runtime meta-model. Thus, the runtime DDI is not

necessarily based on the SACM but on conditional assurance contract meta-models such as the ConSert

meta-model. The development of the runtime DDI concept is still subject to research and will be fixed (as

planned) in the later stages of DEIS.

Figure 5 - High-level structure of the ODE

3.2 Refining the content of the ODE based on engineering stories

In order to refine the high-level structure determined in Section 3.1, we use the DEIS use cases and the

corresponding engineering stories created and maintained in WP3. The approach we took in the project is

illustrated in Figure 6:

1. In DEIS, there are different industrial use cases with different foci and flavours.

2. In the context of each use case, we defined one or several DDI engineering stories. These

engineering stories focus on specific DDI challenges (corresponding to the core challenges and

objectives described in the proposal). They describe explicitly how DDIs support the engineering

activities with respect to a certain challenge.


Page 14 of 65

3. Based on the more detailed requirements emerging from the engineering stories, we were able to

refine the DDI concept and, correspondingly, the high-level ODE as introduced in section 3.1.

Figure 6 - DEIS approach w.r.t. refining the concept of DDI and the ODE

To describe the different factors influencing the ODE meta-model creation process in more detail, Figure 7

shows an overview that correlates the ODE, the engineering stories and the previous work. The initial draft

of the ODE was mainly informed by the integration of dependability meta-models which had been

developed and evolved during past industry and research projects carried out by the research partners of

the consortium. These meta-models contain condensed information about well-established dependability

modelling and analysis techniques, which are additionally already supported by the partners’ tools. This

means that a solid dependability engineering baseline already existed, which is currently being revised and

extended in order to successfully support engineering stories focusing on specific challenges that have

emerged within the DEIS use cases.

For example, consider the sample engineering story of replacing a failure model from supplier company A

with one from integrator company B, taking into account IP protection issues: This engineering story can

be understood as a set of additional requirements for the ODE meta-model. The mission in DEIS is to extract

engineering stories from the use cases that focus on interesting engineering challenges emerging in the

development of systems of systems. Afterwards the ODE shall be extended, on the one hand, with specific

missing elements and information to support the engineering challenges; on the other hand, changes and

extensions of the ODE meta-model will be fed back to the corresponding tool support.

The ODE must be fit to address all the challenging aspects of the engineering stories, but the reverse is not

true, of course: i.e., that the ODE meta-model is an extensive solution supporting all conceivable challenges.

Similar to the way a sequence chart only addresses one specific scenario, the engineering stories and the

derived “DDI content models” focus on specific aspects. To account for the observation of ODE non-

extensiveness, the ODE is structured into modular packages, meaning it has been explicitly designed to be

incrementally extended in future to support additional engineering challenges when such challenges are


Page 15 of 65

identified. As elaborated in this section, the sum of all formulated engineering stories combined with our

previous work and expertise will lead to the final DDI concept and ODE meta-model at the end of the DEIS

project, but future extensions to it are already being anticipated now.

Figure 7 - Influencing factors of the ODE meta-model within DEIS

3.3 The SACM as a backbone for the ODE

3.3.1 SACM overview

As already described in the introduction and adopted in the definition of ODE, we will use the SACM as the

underlying supporting meta-model for ODE.

The Structured Assurance Case Meta-Model (SACM) is a modelling language specialised for the creation of

structured system assurance cases. An assurance case is a set of auditable claims, arguments and evidence

created to support the claim that a defined system/service will satisfy typical requirements such as safety

and/or security. An assurance case in this context is a machine-readable model that facilitates the exchange

of information between various systems stakeholders such as suppliers and integrators, and between the

operator and regulator, with the knowledge related to the safety and security of the system being

communicated in a clear and defendable way. Each assurance case should communicate the scope of the

system, the operational context and the safety and/or security arguments, along with the corresponding

evidence.


Page 16 of 65

3.3.2 SACM meta-model

3.3.2.1 SACM Assurance Case Component

In general, the SACM enables the user to create assurance cases by combining structured argument(s) into

ArgumentPackage(s) with their corresponding evidence defined in ArtifactPackage(s), as well as the

information of the system/service for which the assurance case provides assurance for, in

TerminologyPackage(s).

Figure 8 - SACM AssuranceCase Package

Considering the possibility of exchanging assurance cases (or simply exchanging system information), the

SACM provides the notion of Interface. The creator of an assurance case can decide to reveal part of its

information by using the AssuranceCasePackageInterface. In this sense, systems with SACM-based

assurance case models can be exchanged at runtime for higher-level engineering requirements.

The design of the SACM also takes into consideration scenarios where systems form a system of systems;

in such cases, systems with SACM-based assurance case models can determine whether they are

compatible (by using the AssuranceCasePackageInterface, as previously discussed). When the systems are

compatible, a binding/contract (which contains the argumentation, if necessary, regarding why the systems

are compatible and why they satisfy their safety/security requirements) can be created to bind/link

assurance cases together to form a compound assurance case. For this purpose, the SACM provides the

notion of binding, which is used to bind two or more interfaces at any given level (a binding also provides

possible structured argumentations showing the logic underlying the integration).

3.3.2.2 SACM Machine-Readable Design

The SACM takes into consideration that machine-readable assurance cases can be created. The Base

component (shown in Figure 9) of the SACM provides the necessary means such that not only

names/descriptions can be described in natural language, they can also be described in computer

languages (e.g., formal notations) to enable automated argument reasoning in future.


Page 17 of 65

At the same time, the SACM provides various facilities (subclasses of UtitlityElement in Figure 9) allowing

the user to define necessary constraints, notes, additional attributes etc.

Figure 9 - SACM Base package

3.3.2.3 SACM Argumentation Component

As previously discussed, an assurance case created using the SACM contains a number of argument

packages which contain structured argumentations. The SACM Argumentation component provides the

facilities for creating structured argumentations, as shown in Figure 10. The user of the SACM can make a

number of different types of claims which provide means of assertion, context, assumption and

justification. The user can also make use of the Artifact component to refer to corresponding evidence

(internal/external to the SACM model) to support the claims. There are various types of

AssertionRelationships to link claims to sub-claims, contexts, assumptions, justifications etc.

As previously discussed, the SACM provides the possibility for two systems to exchange information with

regard to their structured argumentations about system assurance, via the ArgumentPackageInterface. In

this sense, the creator of the structured argumentation can decide what information can be accessed

externally (e.g., a safety requirement that is asserted to have been fulfilled), so that external users can make

use of such information. Obviously, the notion of interface leads to the question of trust; the SACM also

provides facilities for structurally arguing the level of trust embedded in the information provided in the

interfaces (in the same manner as structured argumentation, via metaClaims).

With the interface present, systems can integrate and form a compound structured argumentation, by

using ArgumentPackageBinding. The ArgumentPackageBinding used to integrate systems contains the


Page 18 of 65

underlying logic (in the form of structured argumentation) of the binding. This provides the possibility for

systems to integrate at the level of argumentation.

Figure 10 - SACM Argumentation Package

3.3.2.4 SACM Artifact Component

The SACM provides the means for maintaining the evidence associated with the structured

argumentations. The SACM Artifact component provides the facilities to maintain evidence such as

Resource, Artifact as well as Activities, Event, Participant and Technique, as illustrated in Figure 11. The

SACM enables the user to point to external files/URLs of the related artifacts via the use of Property. In this

sense, the SACM provides the necessary abstraction, as it does not demand the use of models for

argumentation evidence. This abstraction provides a significant degree of openness regarding its adoption

in open systems (i.e., Cyber-Physical Systems). However, the SACM does provide the necessary means for

the Artifacts to be linked to model elements in the sense that constraints (described in model querying

languages such as the Object Constraint Language) can be embedded into each one of the Artifacts, which,

in turn, would be executed at runtime and retrieve the value of the referenced model elements.

With respect to assurance case integration, there is also a need to exchange information at the level of

evidence. The SACM provides the ArtifactPackageInterface to enable the exchange of Artifacts among

assurance cases. The user can choose what evidence (inside an ArtifactPackage) can be accessed externally

in an ArtifactPackageInterface associated with the ArtifactPackage. With the ArtifactPackageInterface, it is

possible to bind ArtifactPackages by using ArtifactPackageBinding, so that system integration can be

performed at the level of ArtifactPackage.


Page 19 of 65

Figure 11 - SACM Artifact Package

3.3.2.5 SACM Terminology Component

Without context, structured argumentation is meaningless. In the SACM, the Terminology component

provides the necessary means for linking system information to the structured argumentation in the

ArgumentPackages. Concerning system information, the user can define Terms, Expressions and

Categories, which are the terminologies in the system for which the assurance case provides assurance. At

this point the SACM also provides the necessary abstraction so that external system information (such as

system models, failure logic models, FMEA models, FTA models etc.) can be referenced. Note that the

SACM does not demand the use of models to provide openness regarding its adoption in open systems

(i.e., Cyber-Physical Systems).

The creator of a TerminologyPackage can also decide to expose system information by using the

TerminologyPackageInterface for system integration so that system information (e.g., system properties)

can be accessed externally.

With TerminologyPackageInterface present, system integration is performed by using

TerminologyPackageBinding, so systems are integrated at the Terminology level.

With standardised TerminologyPackages, a typical task to perform is to extend a standardised

TerminologyPackage to create new standard/non-standard TerminologyPackages. We can, once again,

make use of the +abstractform of the SACMElement on both the level of the TerminologyPackage and the

level of the elements contained inside TerminologyPackages. In this sense, a TerminologyPackage can be

extended. Standardised TerminologyPackages can be stored in publicly accessible repositories for

reference, which is in line with the DEIS vision of the application of DDIs.


Page 20 of 65

Figure 12 - SACM Terminology Package

3.3.3 Usage of the SACM in the DEIS context

As discussed above, the SACM provides the necessary abstraction to provide flexibility and enable a great

degree of openness when referencing external information. In this respect, the SACM does not necessarily

assume that the external information is organised in models, but rather expects a piece of information to

be organised in arbitrary form defined in an arbitrary technology. However, the SACM does consider the

scenario where external information is represented by models (but not necessarily homogenous models)

and provides the necessary means to refer to them. In summary, the SACM provides two types of extension

points for the user to use when they create references to external information. We refer to these two

types as weak links and strong links.

Weak links are links to external information where the reference is plain text. Such links can be observed

in the Term element of the Terminology component, where +externalReference (of the type String) is used

to point to an external piece of information. Obviously, this weak link only points to a location of the

information; it is hard to tell to which specific part of the external information the Term points.

Strong links, in contrast, provide the users with the ability to describe the referenced piece of information

at a finer degree of granularity. Strong links are often used (or are suggested to be used) when the

referenced pieces of information are structured (e.g., organised into models which conform to their


Page 21 of 65

corresponding meta-models). In order to do this, the users can define queries (in model querying languages

such as the Object Constraint Language) in +externalReference, which can then be executed to extract the

values of the referenced model elements. By doing this, for example, the Terms in the TerminologyPackage

can refer to a specific model element rather than simply pointing to the location of the model (as opposed

to using weak links).

Via weak links and strong links, the SACM provides the necessary extension points where elements in the

Artifact and Terminology components can refer to external information with the degree of granularity

selected by the users of the SACM.

The usage of strong link is illustrated in Figure 13. At the top left of the figure is a Claim of the SACM, which

contains a Description (which states that “Failure Mode Z will lead to Hazard Y”), with the Description

containing the Terms “Failure Model” and “Z”. The Claim is supported by an ArtifactReference (bottom left

of Figure 13) which contains a Description stating “FMEA for X”. With strong links, we establish that the

Term “Failure Mode” refers to the meta-element named “Failure Mode” in the FMEA meta-model (top

right of Figure 13). We then establish that the Term “Z” refers to the model element named “Z” in the FMEA

model for X (bottom center in Figure 13). We also establish a weak link in the ArtifactReference, as it refers

to the FMEA model for X (no further granularity needed).

Figure 13 - Strong link from Term to Model Elements

It is also worth mentioning that the contents in a TerminologyPackage can also be structured: they can be

either organised into Category(-ies) or into explicit conform-to relationships. The latter is achieved by using

the +abstractForm of the SACMElement in Figure 9. The purpose of +abstractForm is for the users to declare

that a SACMElement conforms to another SACMElement in a type-of relationship (such as inheritance). By

doing this, we can declare that a Term has an +abstractForm of another SACMElement.

3.3.4 System assurance case integration example

As previously discussed, system integration and, in particular, system assurance case integration can be

facilitated by the SACM at three lower levels of integrations and one higher-level integration. In lower-level


Page 22 of 65

integration, system information integration is performed at the Terminology level; structured

argumentation integration is performed at the Argumentation level; and evidence integration is performed

at the Artifact level. With Terminology, Argumentation and Artifact integrations, system assurance cases

are integrated at the System Assurance Case level.

To illustrate how assurance case integration is performed in the SACM, we provide an example taken from

an engineering story in the European Train Control System (ETCS). In this example, we consider a scenario

where the assurance cases of on-board and trackside components of ETCS are integrated to form an overall

assurance case.

The example SACM model for the ETCS case study is shown in Figure 13. For the sake of simplicity, we only

show the top-level Claims of the assurance cases. A more detailed description can be found in Section 6. In

Figure 13, there are three AssuranceCasePackages. On-Board ACP (at the top of the figure) is the assurance

case for the on-board component of the ETCS; Track-Side ACP (at the bottom of the figure) is the assurance

case for the trackside component of the ETCS; and Integration ACP (in the middle of the figure) is the

integration assurance case, which integrates the two component assurance cases.

For On-Board ACP, ArgumentPackage AP1 contains the argument regarding the safety of the on-board

component. As discussed in previous sections, system engineers may wish to disclose only the top-level

Claim externally, hence ArgumentPackageInterface AP1 is used, which contains a citation of G2 that will be

referenced externally. The same principle is applied to Track-Side ACP, where the top-level Claim G3 is cited

in the ArgumentPackageInterface API2. It is to be noted that both On-Board ACP and Track-Side ACP contain

ArtifactPackages and TerminologyPackages, which are not shown due to the complexity of the model

structure.

To integrate On-Board ACP and Track-Side ACP, an AssuranceCasePackage named Integration ACP is

created. Integration ACP contains AssuranceCasePackageBinding (Integration ACPB) specifically for binding

On-Board ACP to Track-Side ACP. Within Integration ACPB, ArgumentPackageBinding (APB1) is used to bind

API1 and API2 via the +participantPackage feature. In APB1, the top-level Claim G1 argues the safety of

ETCS and two supporting Claims G2 and G3 are in place. Note that G2 and G3 are citation Claims which cite

G2 in API1 (which in turn cites G2 in AP1) and G3 in API2 (which in turn cites G3 in AP2). Also note that

within AssuranceCasePackageBinding (Integration ACPB), there are also ArtifactPackageBindings and

TerminologyPackageBindings, which bind the artefacts and expressions used in the on-board component

and the trackside component.

The integration of assurance cases in the SACM is achieved via various package bindings. It is also possible

to include additional arguments in the binding AssuranceCasePackage if deemed necessary. Users of the

SACM may also argue the trustworthiness of the cited Claims in other packages to ensure confidence in

citing argument elements.


Page 23 of 65

Figure 13 - SACM Illustrative ETCS example


Page 24 of 65

The terms used in the assurance cases are captured by their respective TerminologyPackages as discussed;

their details are not shown due to space limitations. Figure 14 provides an example of how Terms work in

the SACM. In G2, the Claim specifies that the on-board functions are acceptably safe, where “On-Board

functions” is a Term in the SACM. It is captured and put into the TerminologyPackage of the On-Board

AssuranceCasePackage; the Term itself provides an “externalReference” which points to the On-Board

system design model captured using ODE. In this case, the assurance case is able to refer to external

materials (not only to models).

Figure 14 - Example of ODE usage in the SACM

3.4 ODE dependability packages

In this section, a conceptual overview of the first version of the ODE meta-model will be presented.

On the one hand, it has been created based on past engineering experience by the participating industrial

partners and on dependability meta-models capturing the safety engineering knowledge of the involved

research partners evolved through numerous research and industry projects in the dependability area. On

the other hand, the creation of the ODE was guided by a subset of the identified engineering stories in

order to make sure that the engineering challenges identified in the context of DEIS can be solved to a

certain degree with the help of DDIs conforming to the ODE meta-model.

The first version of the ODE contains packages including the following important aspects required for

modelling and analysing dependability: system architecture modelling, failure logic modelling, hazard and

risk modelling as well as means for dependability requirement modelling. The different aspects of the meta-

model were separated into modular packages, which is reflected in the structure of the subsections. This

refinement should help to simplify management and review of the ODE elements while also highlighting

each element’s role in its package.

After an abstract overview of the ODE packages and their main interrelations with each other, the next

subsections will describe the single package contents in detail.

3.4.1 ODE meta-model overview

This section provides an overview of the overall structure of the ODE meta-model (see Figure 15 for the

overview and Figure 16 for the full version of the meta-model). The focus of the description is on the


Page 25 of 65

package notions as well as their interrelations. Therefore, the actual contents of the ODE packages have

been abstracted in Figure 15 and only the principal elements are shown.

Figure 15 - ODE meta-model big picture

As dependability always has to be demonstrated in the context of a particular system or system of systems,

fundamental inputs to dependability activities are models describing the structural and behavioural aspects

of the system architecture. These aspects are depicted in the ODE::Architecture package (section 3.4.2),

where System represents a logical or physical representation of the system structure and Function

represents the behavioural aspect of the System.

The dependability activities start with a hazard and risk analysis, where Malfunctions of the intended

system behaviour (Functions) are identified and the risk is of the resulting Hazards is rated. Modelling

elements regarding this activity are found in the ODE::Dependability::HARA package (section 3.4.3).

Based on the top-level dependability requirements derived from the dependability-critical hazards

identified in the HARA, safety analyses are carried out to find potential failure causes in the System or

Function leading to the hazards to be mitigated. There exist various techniques, such as Fault Tree Analysis

(FTA), Failure Mode and Effect Analysis (FMEA) or Markov chains, for the identification and documentation

of the resulting failure logic models. As faults typically manifest themselves as failures on the System’s

interface if no safeguards are provided, the notion of interface failure modes plays an important role in

relating potential failures to the System interface. The respective modelling elements for failure logic

modelling regarding the techniques mentioned above can be found in the ODE::FailureLogic package and

its sub-packages (section 3.4.4).


Page 26 of 65

Figure 16 - ODE Meta-Model Version 1


Page 27 of 65

The faults identified during the safety analysis are principal input for the derivation of additional

Dependability Requirements, which have to be satisfied by the system through the implementation of

additional dependability Measures. Thus, modelling elements for dependability requirement

decomposition and documentation as well as measures intended to satisfy the requirements are located

in the ODE::Dependability package and its sub-packages (sections 3.4.3 and 3.4.5).

As explained in the preceding paragraphs, the current set of ODE packages is structured according to

different phases and aspects of the dependability engineering lifecycle of a system. As the artefacts from

different phases are conceptually interrelated through input-output and refinement relations, it is clear

that these inter-package relations have to be formally expressed in the ODE as well in order to enable

integrated and automated synthesis and processing of DDIs. Note that these inter-package relations will

thus not be described further in the following subsections for reasons of presentation clarity.

3.4.2 Architectural modelling package

The ODE::Architecture package contains elements that are necessary for describing architectural aspects

of the system under development. These aspects model both the structure and behaviour of the

architecture, including functional, performance and design attributes. Note that ODE::Architecture is not

intended to provide modelling elements that are required for engineering a system architecture

completely, but rather only those required as input for the dependability lifecycle. The package contents

are depicted in Figure 17. The System is the central root element of the architecture package.

In this view, a System can comprise subsystems and ports. Ports represent the explicitly defined interface

through which the System communicates with external systems or sub-systems via signals. A Signal can be

described as a connection between ports through which information (e.g., data flows) is passed between

different Systems. Depending on the direction of the signal (incoming, outgoing, both), a Port has an

assigned PortDirection.

In different phases of the system engineering lifecycle, the focus is on different aspects of the System under

development which require different attributes of the system to be examined and thus modelled. To

account for this, the engineer of the System can focus on the logical, physical or safety-related aspect

depicted as LogicalComponent, PhysicalComponent or SafetyRelatedSystem, respectively. In each case,

different attributes will be important for modelling and subsequent analyses. Independent of the specific

modelling aspect, a System as a hierarchical representation of the architectural structure will always have

a set of Functions representing the behaviour the System should realize. Attached to a function to be

realized are the required PerfChars (=performance characteristics) emerging from the functional

requirements of the System. In addition, the (typically embedded) System will always operate within a

certain Context, which might contain relevant information about the System’s operation, usage or

environment.


Page 28 of 65

Figure 17 - ODE::Architecture Package

As explained in section 3.4.1, the relations of ODE::Architecture to other ODE packages have been omitted

in Figure 17 for reasons of presentation clarity. Below, they are explained in textual form:

• A DesignArtifact inherits the basic attributes Id, Name and Description from a BaseElement

(ODE::Base)

• A DesignArtifact can have an assigned AssuranceLevel (ODE::Dependability::Domain)

• DesignArtifacts can have several assigned DependabilityRequirements

(ODE::Dependability::Requirements)

• A PhysicalComponent can have several MaintenanceProcedures (ODE::Dependability)

• A System can have several Standards (ODE::Dependability::Domain) that must be complied with

during development

• Systems and Functions can have FailureModels (ODE::FailureLogic) capturing their failure logic

• A Function can have several Malfunctions (ODE::Malfunction) depicting safety-critical deviations

from the intended behaviour

• In a similar as Systems and Functions can have FailureModels, their interface in the form of Ports

can have related InterfaceFailureModes (ODE::FailureLogic) describing the failure propagation

interface of a System or Function


Page 29 of 65

3.4.3 Hazard and risk analysis (HARA) package

In the ODE::Dependability::HARA package, the essential root data elements used in hazard and risk analyses

and their relationships are modelled. Such data elements of the hazard and risk meta-model are also

handled by the Open Safety Meta-Model (OSM) representing the safety meta-model which was developed

and evolved at Fraunhofer IESE in several research and industry projects. The establishment of a hazard

and risk meta-model in this context is, however, not directly related to the OSM. The modelling is

performed based on the best practice of the hazard analysis/assessment of the research group

Dependability Analysis and Management (DAM) at Corporate Technology of Siemens AG. The current

version of the hazard and risk package is rather abstract and coarse. The data attributes of the modelled

data elements (classes) require further refinement. Nevertheless, this package includes the most essential

data elements and their relationship used in the hazard and risk analysis for the use of such data inside the

package and data exchange across the packages.

Figure 18 - ODE::Dependability::HARA Package

Figure 18 illustrates this hazard and risk package. The root of this meta-model is the element HaraArtifact,

which enables composing and linking the data elements Function and Hazard. Malfunction is modelled as

a separate data element which references the identified function. Together with Function, it is further

referenced by the Hazard element, where the hazard analysis takes place based on the corresponding

malfunction. The identified hazard is then referenced by:

• A Function, due to the data exchange between Hazard and Function;

• A FaultToleranceMeasure, for the identification of this measure with respect to the Hazard;

• A SafetyRequirement, for the derivation of the safety goal and safety requirement;

• A SafetyFunction, for the derivation of the safety function;


Page 30 of 65

• A RiskAssessment, for conducting quantitative risk analysis of the corresponding hazard.

SafetyRelatedSystem has also been included as a data element because the SafetyFunction is implemented

by it, and the SafetyRequirement is performed by it. The relationships among these three elements are

modelled via references. Furthermore, there are also references among SafetyRelatedSystem,

RiskAssessment and FaultToleranceMeasure. This is because the SafeState, which shall be ensured by the

SafetyRelatedSystem, is derived from the FaultToleranceMeasure (also from the linked Hazard) and the

RiskAssessment. A SafetyRequirement as a requirement of the SafetyFunction references the

FaultToleranceMeasure and the RiskAssessment to derive the safety requirement. The

FaultToleranceMeasure is modelled as a single element compared to other fault handling measures, such

as fault avoidance measures and fault removal measures, because this measure is identified during the

functional hazard analysis and then used to derive the safety goal / safety requirement and the safety

function. The other measures are handled together in the element of the overall type of measure. For

further information about fault tolerance measures and the rationale for this modelling style, please refer

to (Avizienis et al. 2004). As the top-level SafetyRequirement, the Safety_Goal is modelled as a data

attribute of the SafetyRequirement. The SafetyFunction fulfills the SafetyGoal and references it via the

SafetyRequirement.

The attributes of the current data elements are rather incomplete; the refinement of the attributes could

be performed in accordance with the overall project requirements of the ODE.

3.4.4 Failure logic modelling package

The ODE::FailureLogic package contains the meta-model elements which describe the potential causes of

failure of the system. These causes are derived from the failure analysis (Markov modelling, Failure Modes

and Effects Analysis or Fault Tree Analysis) captured under a specific FailureLogicPackage. The

FailureLogicPackage can be seen in Figure 19. To maintain presentational clarity, some details have been

omitted.

The FailureLogicPackage contains most of the other elements of the package, providing access to various

types of Failures to be shared through it. FailureLogicPackages are also composable, which provides

support for modular and hierarchical analysis techniques such as CFT and HiP-HOPS. The Failure element

aims to abstract common characteristics of the various failures that can be identified within functions,

systems or components. Failures attributable to a specific architectural element can be categorised into

InterfaceFailures, which can be InputFailures or OutputFailures, or InternalFailures. This distinction is based

on the viewpoint of the analysis of the failure. For example, if the analysis of a system identifies failures

originating from within its boundary, those are InternalFailures. Furthermore, the abstraction is useful for

composing heterogeneous failure analysis results of hierarchical models. Other types of Failure that can be

modelled are so-called Common Cause Failures (CCFs), which can trigger other failures and are captured

via the CCF element. To provide default support for the exchange of failure logic information, the

FailurePropagation element enables capturing one-to-one relationships between InterfaceFailures,

whereas the MinimalCutSet element describes the combinations of Failures that can lead to OutputFailures.


Page 31 of 65

The relationship between the FailureLogic package and other packages is summarised as follows:

• The FailureAnalysisArtifact element inherits from the ODE::Base::BaseElement and is inherited by

all other elements in the ODE::FailureLogic package.

Figure 19 - ODE::FailureLogic Package

The analysis-specific sub-packages ODE::FailureLogic::FTA (Fault Tree Analysis), ODE::FailureLogic::Markov

(Markov Chain Analysis) and ODE::FailureLogic::FMEA (Failure Modes and Effect Analysis) within the

ODE::FailureLogic package capture information regarding the corresponding analysis techniques. In Figure

20, the FTA sub-package is shown.

The ODE::FailureLogic::FTA sub-package captures the information produced during an FTA. The

FTAPackage element extends the FailureLogicPackage element from the ODE::FailureLogic package,

enabling references to relevant elements, such as InternalFailures. The Gate element captures the logical

relationship that associates the various types of events represented within a fault tree. Such events

correspond to input, output and internal failures captured in the FailureLogic package. Thus, Gates can

compose such events as well as other Gates, forming the tree hierarchy featured in a fault tree. The

composition is supported via the FTAPropagation element, which associates pairs of FailureAnalysisArtifact

elements (such as Gates and various events).


Page 32 of 65

Figure 20 - ODE::FailureLogic::FTA Package

The ODE::FailureLogic::FMEA sub-package can be seen in Figure 21. The abstract element FMEAPackage

provides a common interface for describing standard FMEAs and Failure Modes, Effects and Diagnostic

Analyses (FMEDAs). As before, the FMEAPackage element inherits from the FailureLogicPackage element,

providing access to refer to relevant elements from the FailureLogic package such as InternalFailure. FMEA

entries relate a failure originating from a constituent element of the system under analysis to an output

failure. Each FMEAPropagation element captures one such entry and they are composed under an

FMEAPackage element. An FMEDA entry is represented by a DiagnosableFailurePropagation, which

extends the FMEAPropagation by associating a rate of diagnosing the subject failure with the causal

relationship.

Figure 21 - ODE::FailureLogic::FMEA Package

To provide future support for the analysis of system behaviour including dynamic or temporal elements,

the Markov analysis technique is supported in the ODE, as seen in the Markov sub-package in Figure 22.


Page 33 of 65

Figure 22 - ODE::FailureLogic::Markov package

The MarkovChainPackage element also inherits from the FailureLogicPackage element of the FailureLogic

package, enabling association of fail states with OutputFailures. A MarkovChainPackage element composes

MarkovArtifacts, which can represent states of normal behavior (State) and failed behavior (FailState)

respectively, as well as the probabilistic Transitions between them.

3.4.5 Dependability requirements package

Dependability requirements are crucial for describing artefacts of dependability. Almost all the artefacts of

a dependable system are derived from dependability requirements. The associated safety, reliability,

availability, maintenance and security requirements therefore form the basis of all the activities of the

dependability system. The source of the dependability requirements are not only the project-specific goals

and requirements but also the product and process requirements from the relevant standard and the

domain-specific regulations . This situation is represented in Figure 23.

The focus with respect to dependability-requirement modelling rests on safety requirement modelling in

the current ODE meta-model version. As depicted in Figure 18, a safety requirement is derived from a

FaultToleranceMeasure and the corresponding RiskAssessment. It refers to what the SafetyRelatedSystem

shall do as well as to what it shall not do, in order to ensure the SafeState of the designated system and its

environment, and the quantitative or semi-quantitative quality and integrity requirements that the

designated system shall fulfil. Except for the security requirements, all the other dependability

requirements are derived from hazard and failure analysis techniques. Functional hazard analyses,

FME(C/D)A, FTA and Markov chains all lead to the fault tolerance measure and the risk assessment. The

respective dependability requirements could be derived as follows:

• Safety requirement based on the identified measure and its associated integrity level, which are

the results of the hazard analysis and risk assessment;


Page 34 of 65

• Reliability requirement based on the probability and failure rate (as a time function) calculated by

means of a quantitative hazard/failure analysis, such as fault tree analysis;

• Availability requirement based on the availability calculated by means of quantitative fault tree

analysis;

• Maintenance requirement based on Mean Down Time (MDT), also calculated by means of

quantitative fault tree analysis.

Figure 23 - ODE::Dependability Requirement Package

This means that if identification of the artefacts of the hazard and failure analysis is adequate, the

dependability requirements can be derived in an adequate manner as well. Therefore, the modelling of the

hazard and failure analysis with a focus on the aforementioned system behaviour and its quality attributes

is important for establishing the ODE meta-model. According to (Avizienis, Laprie, Randell, & Landwehr,

2004), a requirement is also understood as the requirement for a system to deal with avoiding service

failures that are more frequent and more severe than is acceptable.

Currently such failure elements and the associated attributes are handled by the ODE::Dependability::HARA

and the ODE::FailureLogic packages. The DependabilityRequirement references a Failure in

ODE::FailureLogic and Measure in the ODE::Dependability::HARA. In the current meta-model, the

dependability requirement is still modelled as one entire element beside the safety requirement. Both the

dependability requirement and the associated requirements need to be associated and further refined.

3.4.6 Crosscutting concerns

The ODE::Base package can be seen in Figure 24. It provides common attributes and a generic extension

mechanism for all meta-model elements. To address potential extensions to the ODE that are specific in

certain project environments, the mechanism enables users to provide custom annotations for each of the

meta-model elements in the packages outside the ODE. The BaseElement is the generic element from


Page 35 of 65

which the vast majority of the other meta-model elements inherit. The BaseElement allows each element

to be assigned a unique identification number, a name and description, as well as a set of KeyValueMaps.

Each KeyValueMap can be used to associate a particular element with user-defined properties (the keys),

whose values are retrievable through Value elements. For properties that are composed of sets of Values,

tags can be used to further specify which Value is required. Thus, the KeyValueMap allows extending the

ODE meta-model on an application-specific level. This means that if the DDI producer and the consumer

agree on an application-specific protocol describing information not yet formalized in the ODE, they can

enrich the DDI with that information without waiting for a new ODE version.

Figure 24 - ODE::Base Package

The BaseElement is inherited by central elements in other packages to distribute its properties; in the

ODE::Architecture package by the DesignArtefact element, in the ODE::Dependability package by the

DependabilityArtifact element, which in turn is inherited by the RequirementArtifact in the

ODE::Dependabilty::Requirements sub-package and the HARAArtifact in the ODE::Dependability::HARA sub-

package. In each case, the remaining elements of each package and sub-package inherit the properties

mentioned from the corresponding elements mentioned above.

In each of the major sub-packages of the ODE, a design pattern consisting of meta-model elements named

-Package, -Binding and -Interface are included. The pattern is widely used in SACM, as described briefly in

Section 3.3.2.1. The role of -Package elements is to compose most of the remaining elements from the

immediately surrounding sub-package. For example, as shown before in Figure 20, the FTAPackage

element composes FTAArtifact elements, from which most of the elements in the FTA sub-package inherit.

This provides a convenient container for storing and retrieving relevant FTA elements. -Interface elements

allow the user control over which meta-model elements are visible to external parties. -Binding elements

are used to associate separate -Interface elements. Following the above example, FTAPackageBinding

allows the user to associate two FTAPackageInterface elements. This association effectively composes the

two interfaces.

4 Related work

4.1.1 Safety argumentation

For many industries, the development, review and acceptance of a safety case forms a key element of

regulatory processes. This includes the nuclear HSE, defence, civil aviation and railway industries. Safety


Page 36 of 65

cases are defined as follows: A safety case should communicate a clear, comprehensible and defensible

argument that a system is acceptably safe to operate in a particular context.

Historically, safety arguments were most typically communicated in safety cases through free text.

However, problems are experienced when text is the only medium available for expressing complex

arguments. One problem with using free text is that the language used in the text may be unclear and

poorly structured; there is no guarantee that system engineers would produce safety cases using clear and

well-structured language. In addition, the capability of expressing cross-references as free text is very

limited; multiple cross-references can also disrupt the flow of the main argument. Most importantly, the

biggest problem with using free text lies in ensuring that all stakeholders involved share the same

understanding of the argument to develop, agree and maintain the safety arguments within the safety case.

To overcome the problems of expressing safety arguments in free text, graphical argumentation notations

have been developed. Graphical argumentation notations are capable of explicitly representing the

elements that form a safety argument (i.e., requirements, claims, evidence and context) and the

relationships between these elements (i.e., how individual requirements are supported by specific claims;

how claims are supported by evidence and the assumed context that is defined for the argument).

Amongst the graphical notations, the Goal Structuring Notation (GSN) has been widely accepted and

adopted.

The key benefit experienced by companies/organisations adopting the GSN is that it improves the

comprehension of the safety argument amongst all of the key project stakeholders (e.g., system

developers, safety engineers, independent assessors and certification authorities), therefore improving the

quality of the debate and discussion amongst the stakeholders and reducing the time it takes to reach

agreement on the argument approaches being adopted. Tools that implement the GSN include ISCADE

(Integrated Safety Case Development Environment), CertWare, Astah GSN Editor and GSN add-on for Visio

from the University of York. The Assurance and Safety Case Environment from Adelard typically uses the

CAE notation. The graphical safety argumentation tools mentioned above are not model-based; therefore,

the artefacts they produce are only comprehensible to humans.

4.1.2 Architectural modelling

SysML is an architectural specification language conforming to the UML 2 standard (OMG, 2017). While

SysML is applicable to a large variety of scenarios in the context of dependable systems, we will focus here

on its use within the COMPASS project (Coleman, et al., 2012) and as a basis for a development approach

that merges safety and security analysis (Oates, Thom, & Herries, 2013). SysML was initially standardised

in 2005 by the OMG, as an extension to a subset of the UML. SysML was developed as a variant focused on

systems engineering; it uses fewer of UML’s software-oriented diagrams and introduces the requirement

and parametric diagrams. These are particularly useful in tool-supported system validation & verification.

The EAST Architecture Description Language (EAST-ADL) and its updated version, EAST-ADL2, are employed

to develop domain-specific models for embedded automotive systems (EAST-ADL, 2016). It follows a multi-

view approach to development, abstracting architecture elements into four high-level layers, namely:


Page 37 of 65

• the Vehicle layer, which describes external, high-level vehicle functionality;

• the Analysis layer, which describes system input/output and control functionality;

• the Design layer, which describes the software/hardware architecture;

• the Implementation layer, which links to an AUTOSAR specification

AUTOSAR (AUTOSAR, 2018) is a collection of automotive systems specification standards focusing on lower-

level architecture; it has its own partitioning of the architecture into basic software, runtime environment

and application layer. For communication between low-level elements, the SOME/IP protocol is used.

Following SOME/IP, control units independently register services, share data and request operations

through the vehicle’s network, which is usually implemented via a central bus aka Controller Area Network.

The Architecture Analysis & Design Language (AADL) is an SAE standard (SAE Int'l, 2017) that supports

system architecture modelling. Its application domain focuses on the aerospace industry. The language

supports the specification and analysis of software and hardware system architecture. The language follows

a component-based paradigm, viewing systems as collections of software components mapped onto a

(hardware) execution platform.

Figure 25 - The SPES modelling framework (Pohl, Hönninger, Achatz, & Broy, 2012)

In a series of German national projects under the label SPES (“Software Platform Embedded Systems”), the

so-called SPES Modeling Framework was developed, which includes an integrated modelling method for

software-intensive embedded systems (Pohl, Hönninger, Achatz, & Broy, 2012) (Pohl, Broy, Daembkes, &

Hönninger, 2016). In the SPES approach, abstraction layers and viewpoints form a two-dimensional

engineering space (see Figure 25). Based on well-understood software engineering approaches, the SPES


Page 38 of 65

modelling framework focuses on the following viewpoints to support views, from solution-neutral

requirements to concrete technical solutions: requirements, functional, logical and technical. Note that our

approach is not limited to these viewpoints in principle. For example, in other application scenarios, a

geometrical viewpoint is required. The requirements, functional and logical viewpoints are especially

pertinent to software engineering, also for systems with no technical background. The structure of the

solution space framework considers software-intensive embedded systems in which the software is

affected by the physical environment of the system and has to interact with (or react to) the surrounding

technical system.

4.1.3 Failure logic modelling

In this section, we will briefly describe the links established between the two failure logic modeling

techniques found within DEIS (HiP-HOPS and CFTs) and earlier dependability analysis meta-models. This

information should provide further context regarding the design of the ODE and its interaction with the

techniques and highlight significant differences and similarities with previous work.

4.1.3.1 EAST-ADL & EAST-ADL2

The Dependability package of EAST-ADL is designed to complement the development guidelines of the ISO

26262 automotive safety standard. Using this approach, a vehicle system’s safety analysis begins with a

hazard and risk analysis, where high-level hazards are identified and their risk is estimated as a combination

of severity, likelihood of occurrence and driver controllability. Based on these hazards, safety objectives are

defined to avoid or mitigate the hazards accordingly. The vehicle functions defined in the vehicle layer are

associated with each of the hazards and are assigned appropriate functional safety objectives. As functions

are implemented by systems and, in turn, by components, safety objectives are assigned accordingly based

on failure analysis targeting the appropriate architectural level.

Potential error behaviour identified by engineers can be captured through an EAST-ADL Error Model and

then used to perform tool-supported analysis. Each Error Model (Type) (EMT) identifies potential error

behaviour of a system and characterises it with properties such as anomaly types (e.g., internal fault,

input/output failure), propagation links to other EMTs and how the output failures of the

system/component function are related to its input ports or internal components. ISO 26262 Safety

Integrity Levels (ASILs) can also be incorporated into the EMT description. Different EMTs are composable

via Prototypes, which apply a given EMT to a specific context, such as linking to a nominal system design

(Chen, et al., 2013).

The EAST-ADL Behavior Description Annex also supports the definition of state machines. State machines

enable, among other uses, the incorporation of temporal/dynamic features into the system design and

analysis. State machines are particularly relevant to the HH methodology for its temporal fault tree analysis

extensions (Walker, 2009) and (Mahmud, 2012). These allow the definition and analysis of fault trees where

the likelihood of system failure depends, wholly or partially, on the sequence of two or more failure events.

Transforming EAST-ADL models into HH for FTA/FMEA (and further) analysis is performed via two steps,

referred to as model-to-model (M2M) and model-to-text (M2T) transformations in the literature. The first

involves a semantic mapping of the source meta-model (EAST-ADL) to the target (HH) meta-model. The


Page 39 of 65

second step produces an HH input file from the transformed model, in XML. The commercial version of HH

can then be invoked for analysis using the input file. For EAST-ADL models, the reader is referred to (Sharvia,

et al., 2014) for M2M transformation using a custom algorithm and for M2T from an XML-based EAST-ADL

exchange format to HH. The process is realised using a custom Java tool which carries out both the M2M

and M2T steps. For EAST-ADL2 models, the reader is referred to (Biehl, Chen, & Torngren, 2010), where

the M2M transformation is carried out using the ATLAS transformation language (ATL) (The Eclipse

Foundation, 2018) and the M2T transformation is performed using the Xpand language of the

OpenArchitectureWare framework (Efftinge, et al., 2007). The semantic mapping is encoded as an Ecore

meta-model for HH. Both transformation steps are integrated into the Eclipse development environment

via plugins.

4.1.3.2 AADL

The Architecture Analysis & Design Language (AADL) is an SAE standard (SAE Int'l, 2017) that supports

system architecture modelling. Its application domain focuses on the aerospace industry. The language

supports the specification and analysis of software and hardware system architecture. The language follows

a component-based paradigm, viewing systems as collections of software components mapped onto a

(hardware) execution platform.

AADL is extensible, allowing a more detailed or specialised description of system behaviour aspects to be

defined through such extensions. One key example is the AADL Error Model Annex (AADL EA), which allows

component error models and relevant properties to be captured in addition to the base system

architecture. This feature delivers many of the benefits of Model-Based Safety Analysis (Joshi, Heimdahl,

Miller, & Whalen, 2006); most notably, early, rapid and repeatable dependability analysis.

Under the AADL EA, error models and properties can be defined for each AADL component. Properties can

include fault/repair assumptions, fault propagation behaviour and fault tolerance policies. Error models

describe component behaviour in the presence of local (i.e., internal to the component) failure/repair

events and failure propagations as input deviations of the component. Input deviations can be propagated

from other components as output deviations from the latter. Error propagation is specified by rules along

system dataflow paths or explicitly by the designer.

AADL and its application in architecture modelling have been described in detail in (Feiler, Gluch, & Hudak,

2006), (Feiler & Rugina, 2007), (Joshi & Heimdahl, Behavioral Fault Modeling for Model-Based Safety

Analysis, 2007) and (Rugina, Kanoun, & Kaaniche, 2007). Further support has been added for deriving static

fault trees (Joshi, Vestal, & Binns, 2007), dynamic fault trees (Dehlinger & Dugan, 2008), generalised

stochastic petri nets (Rugina, Kanoun, & Kaaniche, 2008) and HiP-HOPS models (Mian, Bottaci,

Papadopoulos, & Biehl, 2012). Support for migration from SysML models is also planned, via translators for

the Enterprise Architect and Papyrus SysML-compatible modelling tools (See: https://osate.org/about-

osate.html).

Although not directly applicable to the use cases proposed so far for the DEIS project (as none are

associated with the aerospace domain), concepts from the AADL can still prove informative for our

purposes. For example, the Open Source AADL Tool Environment (OSATE) supports AADL modelling and

https://osate.org/about-osate.html

https://osate.org/about-osate.html


Page 40 of 65

validation/verification support. OSATE supports validation/verification through various analyses, including

weight, electric power, port connection consistency and computer resource (memory, bandwidth and

processing capacity) budget checking. These issues are also arguably relevant in the DEIS use cases,

especially in the ETCS case, whose focus is on the integration of CPS components. Other notable features

of ADDL include its explicit support of state machine definition, as in the case of EAST-ADL.

The approach used to transform AADL-EA models into HH closely follows the one for EAST-ADL2 mentioned

in the previous section. Once more, the ATL supports the M2M transformation that converts the initial

AADL-EA model into an intermediate HH model through a corresponding Ecore meta-model. M2T

transformation is performed via a plugin for the OSATE tool framework. HH can then be invoked to analyse

the converted AADL-EA model. The process is described in (Mian, Bottaci, Papadopoulos, & Biehl, 2012).

4.1.3.3 SysML Failure Logic Extension

In the COMPASS project, SysML was chosen for the development of systems-of-systems (SoS) models which

were later analysed using the project’s techniques and tools. In an outline of the vision for COMPASS

(Coleman, et al., 2012), SysML is employed alongside UML by the modelling tool Artisan Studio to model

and generate software. Afterwards, the remaining tools connect either directly or through file exchange,

the files being defined in the project’s shared modelling language, CML. The remaining tools provide static

& dynamic analysis (theorem proving and FTA, among others) as well as simulation of the generated

software. The use of contracts aimed to address confidentiality issues between collaborating users.

Contracts provide abstract behaviour definitions of the systems that compose the SoS in a formal way

(Andrews, Bryans, Payne, & Kristensen, 2014).

Fault modelling in COMPASS enables the generation of fault trees from annotated system models, which

can then be exported to external tools such as HiP-HOPS for analysis. A demonstration of this in video

format can be found online (COMPASS, 2011), where a SysML model in Artisan Studio is translated into an

XML file and analysed by HiP-HOPS. The Fault Modeling Architectural Framework (FMAF) aims to provide

support for structured fault modelling and is designed based on the taxonomy from (Avizienis, Laprie,

Randell, & Landwehr, 2004). The FMAF is defined as a SysML profile from which a tool generates the

corresponding HiP-HOPS XML input; see (Ingram, Andrews, Payne, & Plat, 2014) and (Andrews, Fitzgerald,

Payne, & Romanovsky, 2013). The FMAF can also be leveraged to model and analyse faults in SoS contracts

(Andrews, Bryans, Payne, & Kristensen, 2014). For a more in-depth description of how HiP-HOPS is

leveraged by this process, we refer the reader to (Andrews & Payne, 2014).

In (Oates, Foulkes, Herries, & Banham, 2013), a novel threat model profile for extending SysML with security

modelling capability is presented. The authors then discuss their profile in terms of its potential to address

security concerns, based on fundamental security concepts: confidentiality, integrity, availability, non-

repudiation and authenticity. In (Oates, Thom, & Herries, 2013), the authors propose a conceptual

approach that uses the previously described security threat model to generate security-based fault trees

aka attack trees. The authors reference HiP-HOPS as an example of a technique that could be used for fault

tree generation and/or for the analysis of these trees. They also discuss numerous differences between the


Page 41 of 65

security and safety contexts and highlight challenges that would be associated with their proposed

technique.

4.1.3.4 Component Fault Trees & Open Safety Meta-model (OSM)

CFTs (Kaiser, Liggesmeyer, & Mäckel, 2003) use fault trees as a starting point and extend them with the

possibility to decompose the structure of large systems in terms of components. The goal is to support

reusability and reduce modelling complexity. More recently, CFTs have been integrated with Markov chains

to incorporate a dynamic dependency analysis capability (Kaiser, Gramlich, & Förster, State/event fault

trees - safety analysis model for software-controlled systems, 2007). The inclusion of dynamic capabilities

enables support for modelling different modes of operation and dynamic reconfigurations in a system,

which is clearly useful in the context of DEIS. Other recent work on CFTs has been the development of the

"component-integrated CFT" or C2FT (Adler, et al., 2011). These integrate the modular fault tree notation

of CFTs with component-based modelling from established modelling languages like SysML and UML. A

formal description can be found in (Domis & Trapp, Integrating safety analysis and component-based

design, 2008). To provide better support for incremental development of hierarchical systems, C2FTs were

subsequently extended with a "safe component model" (Domis & Trapp, Component-Based Abstraction in

Fault Tree Analysis, 2009).

Recently, C²FTs have been extended methodologically with the notion of service orientation. Especially

within systems of systems, accidents do not necessarily occur only due to a failure that is propagated to an

actuator output, but also due to the interaction of different constituent systems performing some

collaborative function (or providing a service) together. Thus, instead of starting the deductive failure

analysis at the outputs of an actuator, it is necessary to start the safety analysis at the collaborative service.

To combine dataflow-oriented and service-oriented safety analyses in CFT models, C²FTs have been

extended to Service-Oriented Fault Trees (SCFT) in (Adler, Schneider, & Höfig, 2017).

As modularisation and hierarchisation are key demands in the context of DDI usage, component fault trees

and their integration with architectural models had a major impact on the design of the failure logic package

of the ODE meta-model.

CFTs were a major part of the Open Safety Meta-Model (OSM) that was developed as part of the SPES XT

project. One aspect of SPES XT was to create the idea of an open safety meta-model enabling modular,

cross-tool and cross-company safety certification, which provided a sound basis for defining an appropriate

format for Digital Dependability Identities.

4.1.4 Hazard and risk assessment

Hazard analysis and risk assessment is considered by the different safety standards in different domains as

one of the core activities in the development of safety-critical systems. In (ISO 26262, 2010), the

performance of hazard and risk analysis is required in the overall functional safety lifecycle. Without

performing this step, it is not possible to establish any concept for functional safety and conduct other

activities in the safety-critical system. Functional safety is understood in this standard as the “absence of

unreasonable risk due to hazards caused by malfunctioning behaviour of E/E systems”. The importance of

hazard analysis and risk assessment is also emphasised in other safety standards, such as the railway


Page 42 of 65

domain standard IEC62278 (EN50126 in English) (IEC 62278, 2002) and the general standard for safety-

critical systems IEC61508 (IEC 61508-2, 2010). There are plenty of hazard analysis techniques. Functional

Hazard Analysis (FHA) is one of the most fundamental techniques for identifying malfunctions, their hazards

and the corresponding safety goals and safety requirements. FHA is defined in (SAE ARP 47641, 1996) as:

“A Functional Hazard Assessment is defined as a systematic, comprehensive examination of functions to

identify and classify failure conditions of those functions according to their severity”. Typically, FHA consists

of the following steps (Cozon, Spuge, & DNV, 2007):

• Definition of system function;

• Identification of hazardous states or failure modes of the system functions;

• Analysis of the failure effects of hazardous states;

• Derivation of safety goals;

• Derivation of quantitative and safety functions / safety requirements (incl. SIL) of the hazardous

states.

This technique is used quite frequently in different industry domains for identifying safety requirements.

Similar to FHA, Hip-Hops uses an extended Functional Failure Analysis (FFA) to identify hazards or failures

based on a single function or a combination of functions (Papadopolous, 2000). This process includes the

following steps:

• Identification and analysis of system functions and their dependencies through use of functional

block diagrams;

• Identification of single functional failures;

• Assessment of single functional failures;

• Identification and assessment of possible failure combinations.

System models were used in this approach to determine the system-level failure effects of a local

component failure. The propagation of a failure is traced, e.g., by the architecture.

Another approach that aims at extending SysML with a viewpoint for modelling the artifacts of the safety

engineering lifecycle is the modelling language SafeML (Biggs, Sakamoto, & Kotoku, 2016). SafeML is a

SysML profile for integrating safety information with system design information, as an aid to information

consistency and communication between development teams and among members of a team. It can be

used for:

• Tracing from hazards through the safety measures used to the verification steps taken to test those

measures;

• Documenting the analysed hazards and their safety measures to certification authorities;

• Communicating from safety engineers to system engineers the hazards that must be considered

while designing to meet requirements, as identified through the hazard and safety analysis

processes;

• Communicating from system engineers to safety engineers the hazards that the system is designed

to manage, including the safety measures used.


Page 43 of 65

The goal of SafeML is to allow the intuitive documentation of hazard and safety analysis results and safety

measures in the system model. This can improve consistency among multiple analyses and aid in

communicating the results of analyses. SafeML focuses on making this information visible in the system

design. SafeML is designed to be used in conjunction with SysML. SysML provides the diagrams and element

types necessary for design modelling, while SafeML provides the element types used to add safety

information to the model.

4.1.5 Safety requirements modelling

Safety requirements are a subset of requirements, which could be understood as something that the

product must do or must not do or a quality it must have to ensure the system’s safety. Compared to the

functional requirements, safety requirements are derived from hazard and risk analysis. The relevant

standards and domain-specific regulations are normally essential sources of the safety requirements.

In (IEC 61508, 2010), safety requirements are defined as “requirements for the safety functions and their

associated safety integrity levels”. A safety function “is a function to be implemented by a safety-related

system, other technology safety-related systems or external risk reduction facilities, which is intended to

achieve or maintain a safe state for the EUC, in respect of a specific hazardous event”. And a safety-related

system is understood as “a system that is designated to implement the safety functions necessary to achieve

or maintain a safe state for the EUC; and intended to achieve, on its own or with other E/E/PE safety-related

systems and other risk reduction measures, the necessary safety integrity for the required safety functions.”

ISO 26262 introduces the idea of the "safety concept", which includes all the safety requirements and how

they are allocated to different elements of the system. This is used as part of a refinement process that

allows top-level safety goals, identified on the basis of early hazard analyses, to be traced throughout the

system development. Based on the analysis results, the subsequent validation & verification processes then

ensure that these original safety requirements are still being fulfilled by the developed system, and

therefore a safety case can be easily derived from this refinement of the safety concepts. The concept of

the "Safety Concept Tree" was introduced by Domis et al. (Domis, Forster, Kemmann, & Trapp, 2009) to

support this safety concept process. It makes use of a tree-like notation similar to fault trees as its basis.

However, whereas fault trees model combinations of failures leading to a hazard, safety concept trees

model the safety requirements that must be fulfilled in order to achieve the safety goals for the system.

The Safety Concept Tree approach has since been extended to provide a model-based, modular

methodology for representing safety concepts and safety cases using safety contracts (Adler, Kemmann,

Liggesmeyer, & Schwinn, 2012).


Page 44 of 65

5 DEIS engineering stories Having introduced the conceptual overview as well as the contents of the ODE meta-model V1 in section

3, this section lists and describes the engineering stories that were defined based on the DEIS use cases

(for more details on the use cases, refer to the activities in DEIS Work Package 5). Engineering stories are

supposed to represent concrete challenges that engineers face during the engineering lifecycle activities

of a dependability-critical system or system of systems.

These engineering stories were identified, on the one hand, on the basis of practical problems faced by

industry already today in developing these kinds of systems. On the other hand, some of them emerged

during prototypical application of existing dependability methods to the use cases in a more academic

setting. These were afterwards presented to the industry partners, who verified their importance.

The following subsections give an overview of the currently existing engineering stories that will be used to

further drive the development of the ODE meta-model. Although the ultimate goal of the project would be

to support all identified engineering stories fully with the help of DDIs and the ODE, this goal can be deemed

ambitious at this stage of the project. Instead, the project partners will prioritise the most important stories

as candidates to be supported directly by the ODE. All other engineering stories shall serve as a reference

to demonstrate that DDIs can be leveraged to support future engineering challenges not fully addressed in

the DEIS project. Therefore, the ODE meta-model has been defined in an extensible manner so that support

for future or not yet fully addressed engineering stories can be integrated incrementally.

5.1 ES1: Multi-tool interoperability for dependability artefact exchange

There exists a variety of tools to model and analyse the dependability aspect of systems or systems of

systems. Although the modelling and analysis techniques used are often similar to each other, it is currently

not possible to easily exchange dependability models between different tools. The consequence is effort-

intensive and potentially error-prone remodelling.

In order to solve this challenge, the ODE meta-model shall capture the essence of dependability-related

techniques to achieve a common interface for dependability model and information exchange between

different tools at design time. This idea is illustrated in Figure 26, where several techniques

(CBD=Component-Based Design, CFT=Component Fault Tree, GSN=Goal Structuring Notation,

FMEA=Failure Mode and Effect Analysis) are supported by different tools. The important point is that two

tools supporting the same technique (e.g., fault tree analysis in HipHops and safeTbox) still differ with

respect to methods and modelling. The goal of the ODE here is to capture the essence of the techniques

and abstract from tool-specific details.


Page 45 of 65

Figure 26 - Multi-tool interoperability with the help of the ODE as exchange format

5.2 ES2: Protection of intellectual property in distributed development scenarios

Both closed and open embedded systems, especially systems of systems, are developed in a distributed

fashion (see Figure 27). There are different kinds of distribution: distribution in a single company,

distribution among integrator and supplier companies or distribution “@runtime”, where running systems

exchange models and the manufacturer companies of these systems might not even be in contact with

each other. Depending on the distribution scenario, different levels of detail have to be exposed to the

recipients of the model in order to enable them to perform the intended task with the models they

received.

Figure 27 - Different levels of details exchanged in different scenarios

In an intra-company scenario, where intellectual property hiding is typically not an issue, the goal is to

exchange the full set of dependability-related information (white box) among different units mainly to

boost efficiency. In the supplier-integrator scenario, IP hiding is a major issue; therefore means are

necessary especially for suppliers to (semi-)automatically extract only that dependability information from

the models that is of relevance for the integration task of the integrator (grey box). In the runtime

integration scenario, the focus lies on achieving a sufficiently formalised representation of the exchanged


Page 46 of 65

models that computers can understand, because the development of the exchanging systems is already

finished. In this case, the goal of model exchange is to resolve variabilities which were not known at the

time the system was designed, so a black-box representation of the dependability guarantees and demands

(in the form of a certificate) has to be exchanged and checked for compatibility.

In this case, the DDI concept can help by providing ODE meta-model packages suitable for the different

scenarios on the one hand, and (semi-)automated algorithms that help in producing and consuming the

exchanged information in a goal-oriented manner on the other hand.

5.3 ES3: Integration of safety case fragments into a system safety case

When several subsystems are to be integrated into a system together, a system safety case providing a

sound argumentation of why the overall system is safe has to be created. Therefore, the modular safety

arguments (also called fragments here) of the subsystems have to be combined and additional

argumentation has to be added, taking into account the integration context of the overall system, which

was only assumed during the development of the subsystems. The consistency between the argumentation

in the safety case and the dependability artefacts being referenced from the argumentation is still checked

and maintained manually nowadays.

Figure 28 - Safety case integration with the help of DDIs

This challenge could be solved with the help of DDIs by (Figure 28):

• Providing means to model and exchange modular safety case fragments.

• Formalising relevant parts of the safety argumentation content (e.g., references to dependability

model artefacts as well as system model artefacts) and structure (e.g., argumentation patterns,

where the structure itself may have certain semantics). In this case, “relevant” means suitable for

the safety case integration task.


Page 47 of 65

• Providing (semi-)automated algorithms capable of helping the integration engineer to check the

consistency of the interface between the system safety argumentation and the subsystem safety

argumentation.

5.4 ES4: Failure interface compatibility matching during design time system

integration

A similar problem as in “ES3: Integration of safety case fragments into a system safety case”, where the

focus is on safety case integration, exists regarding the synthesis of system and failure logic models from a

set of subsystems. A core issue during the integration is checking for compatibility between the system and

the failure interface of integrating and integrated systems. In this case, compatibility is not only

characterised by the explicit matching of exchanged information (e.g., data flows or failure propagation),

but also by matching assumptions with expectations related to the interface. The compatibility check is

often still done manually nowadays because no sufficiently formalised representation exists in terms of

models. This is especially true for failure model interfaces, where failures and related assumptions are

described with imprecise natural text and are therefore hard to process by algorithms.

In addition, a common problem that occurs during the integration of several modular sub-systems is the

existence of common-cause failures, i.e.,. failures in separate sub-systems that are dependent on each

other because they have common causes. These failures can only be revealed during integration. To

properly identify and mitigate common-cause failures, it is not sufficient to just consider the interface

compatibility of the integrating system and the integrated system, but also specific information about

internal failures of sub-systems.

DDIs can assist in these tasks by providing capabilities (=model elements in the ODE meta-model) for

describing formalised system and failure interfaces as well as common-cause-related aspects of the sub-

systems specifically with the aim of (semi-)automatically checking failure interface compatibility and

adequately mitigating common-cause failures during system integration at design time.

5.5 ES5: Trade-off support for RAMS property optimisation at design time

This engineering story is embedded into the scenario that an integrator company has to integrate

components provided by different suppliers. The specific challenge targeted in this ES is that nowadays,

there is little support for performing trade-offs and optimisation among the RAMS (=Reliability, Availability,

Maintainability, Safety) properties when considering all properties at once. The idea for solving this issue is

to support the integration engineer in a (semi-)automated way by using DDIs so that qualitative and

quantitative trade-offs with respect to the RAMS properties are facilitated and the process is accelerated.

5.6 ES6: Synthesis of dependability runtime models for safe system of systems

integration at runtime

The newest generation of embedded systems is being developed with the goal that they shall be fit for

dynamic participation in different collaboration scenarios with other systems; i.e., systems of systems are

anticipated to be created in an ad-hoc manner at runtime, thereby providing an emergent benefit for the


Page 48 of 65

humans operating the systems. The manufacturers of the single systems do not have complete knowledge

about all the details of the future collaboration scenarios and collaboration partner systems at design time.

This is a challenge because assumptions have to be made not only concerning the behaviour and structure

of collaborating systems, but also about the environmental and integration context. In order to develop a

system that can successfully participate in many different collaboration scenarios at runtime, a set of

variants have to be built into the product. For instance, the accuracy or confidence of a certain piece of

information such as the position of a vehicle in an automotive collaboration scenario might vary depending

on the sensors deployed to the collaborating vehicle system. In this sense, the receiving vehicle has to be

fit to deal with multiple degrees of accuracy or confidence in a safe way. The knowledge of whether the

quality of a received signal or service from another system is good or bad can only be resolved at runtime,

and therefore the final integration of collaborative systems can only be carried out at runtime as well.

Regarding the engineering of systems that can ultimately participate in systems of systems, the

aforementioned assumptions and demands on other potentially collaborating systems and the

environment have to be explicitly modelled already at design time. As the runtime integration has to be

carried out in a fully automated manner, the models have to be formalised to a sufficient degree. Based on

the demands fulfilled and the environmental assumptions checked, valid guarantees can be formulated

which are associated with the possible operating modes of a system. For instance, if certain demands of a

system are fulfilled with worse quality, the overall operating mode of the system of systems could be

degraded regarding functional performance; e.g., the speed of a cooperative vehicle platoon could be

reduced to account for low quality guarantees.

Especially regarding the assurance of dependability for systems of systems, models have to be created to

capture certain behavioural and structural variants (also known as configurations) together with the

assumptions, demands and guarantees describing dependability-related properties of the system. We

believe DDIs can help to solve the engineering challenges mentioned above by providing (semi-) automated

capabilities to synthesise runtime models containing sufficient information to perform fully automated

integration leading to safe collaboration. A major benefit of including an ODE package intended to support

the synthesis of runtime dependability models would be that the models from other ODE packages

(architecture, failure logic, HARA, safety requirements) can be used directly as input for the synthesis

without any further ado.

Figure 29 depicts a possible process of how runtime DDIs could be synthesised based on design time DDI

models. The process is divided into the three sequential phases domain engineering, application

engineering and systems engineering, which account for the different levels of abstraction that have to be

considered in systems-of-systems development. These different phases will be briefly described in the

following paragraphs.

In domain engineering, the goal is to establish domain-wide standardisation of service types. Services

render high-level functionality. The standardisation of service types is intended to enable system

manufacturers to contribute to a bigger ecosystem by implementing a single service. The defined service

types need to be clearly understandable by the entire domain. Thus, this step is performed by domain

experts.


Page 49 of 65

Standardised collaboration scenarios describe the applications in the ecosystem that use a set of basic

services which concrete systems may implement or not. In application engineering, application experts are

expected to create and agree upon these collaboration scenarios. In the next step, the experts then

perform an initial hazard and risk analysis in the context of the considered collaboration scenario. Without

this context, it is not possible to conduct a hazard and risk analysis. Thus, this step cannot be performed as

part of domain engineering. The outcome of this initial HARA are first dependability properties assigned to

the defined service types.

Figure 29 - Overview of process steps for synthesis of design time DDI and runtime DDI

System experts will use the attached dependability properties in systems engineering. The properties serve

as requirements for the development of a system that shall provide a service needed in the collaboration

scenario. To document the fulfilment of the requirement, the system experts have to create an assurance

case. This assurance case is finally compiled into the runtime DDI depicting only the information which is

required to perform safe integration at runtime. It still needs to be defined which information from the

assurance case needs to be used to this end. The development time DDI can contain more information,

such as underlying assumptions or activities performed to achieve the claimed integrity level. Making this


Page 50 of 65

information part of the runtime version of the DDI allows checking this information when creating a

collaboration, thus moving more dependability intelligence to runtime.

5.7 ES7: Modelling of security aspects and safety analysis with respect to malicious

reasons

When open systems of systems are to be built that communicate with each other over Wi-Fi, the assurance

of security is of major importance to prevent dependability problems caused by malicious reasons (e.g.,

hacker attacks). Particularly the dependability attributes confidentiality, integrity and availability (CIA) can

be affected by malicious faults. However, malicious faults can also affect reliability or safety. In current

development processes for embedded systems, the modelling and analysis of security does not have a long

tradition yet and is therefore still tightly integrated with other disciplines, as in the case of safety. Therefore,

security-related activities are often carried out by expert security departments which do not have clear

standardised interfaces to architecture and safety teams. This causes a lot of overhead regarding the

coordination of teams and activities. In addition, this is not only true for the process, but also for the

product; i.e., there are no standardised interfaces between system design models, safety models and

security models.

In order to reduce the overhead times and make the interfaces between security models, safety models

and system design models explicit, DDIs can help by incorporating security-related models that are explicitly

related to the models created by other disciplines in order to enable integrated reasoning on security.

Another benefit of having a security-related package as part of the ODE meta-model would be that safety

teams could get much easier access to security models (i.e., through the DDI) to analyse safety-related

consequences of malicious causes.


Page 51 of 65

6 Utilisation of DDIs in an OEM-TIER integration scenario in the context of the

ETCS

6.1 Use case overview

The European Train Control System (ETCS) provides standardised train control in Europe and makes it easier

to travel by train across the borders of all countries in Europe.

Figure 30 - ERTMS/ETCS Reference Architecture


Page 52 of 65

ETCS itself is a system of systems, consisting of an on-board and a trackside sub-system (see Figure 30). In

the railway domain, the realisation of such a system typically involves different stakeholders in the value

chain (railway undertaking, OEMs, suppliers etc.). Often a railway company orders an ETCS system from

one vendor while another one provides the trackside equipment. Moreover, the on-board sub-system must

interact with the train, which is either built by another department in the same company or by another

OEM.

In order to satisfy the laws and regulations in each European country, it must be proven that the overall

ETCS system is sufficiently safe. Therefore, both sub-systems must fulfil the safety requirements as defined

in Subset-091 (Safety Requirements for the Technical Interoperability of ETCS in Levels 1 & 2) of the

ERTMS/ETCS specification (ETCS/ERTMS, 2016). This standard defines specific hazards and tolerable hazard

rates are apportioned to each sub-system. Moreover, inoperability between the trackside and the on-board

systems must be ensured.

6.2 ES1: Multi-tool dependability artefact exchange in ETCS

In this use case, we utilise DDIs to interchange safety-relevant information (including, e.g., safety

requirements, models and assessments) during the development lifecycle of the trackside and the on-

board ETCS units, thus evaluating how the DEIS approach eases the development process in achieving safe

and interoperable railway systems.

To realise such a scenario, different tools used for safety assessment of either the trackside or the on-board

system interchange dependability-relevant information using the DDI approach. As illustrated in Figure 31,

different tools (also implementing different methodologies) are used for the different ETCS sub-systems

and interchange the required information using DDIs. In this context, we assume that a different team than

the ETCS trackside system (all within the same company) is developing the ETCS on-board system. Since

the teams use different tools (or methodologies) for their safety assessments, information is exchanged

between the teams using DDIs.

Figure 31 - Instantiation of Engineering Story ES1 for the ETCS Use Case


Page 53 of 65

6.3 ES3: Integration of safety case fragments into a system safety case

According to the DDI use case UC_Uc_001 (Distributed Dependable Systems Development) defined in D2.1

(DEIS Consortium, 2017), the safety requirements for the ETCS system as specified in Subeset-091 which

must be taken into account by the suppliers of ETCS systems are provided in the form of DDIs. In addition,

the DDIs can also represent specific availability- or reliability-relevant requirements of the customer

(typically a railway operator).

Based on these requirements available in the form of DDIs, the suppliers of on-board or trackside systems

can build their systems taking into account the dependability information formalised by the respective DDI.

Moreover, during the system integration phase, the suppliers also provide safety case information about

the trackside or on-board ETCS sub-system in the form of DDIs, as described in the DDI use case UC_Uc_001

(Distributed Dependable Systems Development). Hence, an on-board or trackside system can be integrated

into an existing railway system and interact in a safe manner with the pre-existing systems within the

railway system. Moreover, the safety case documentation of an ETCS system (either trackside or on-board)

shall be generated based on the information provided by the sub-system / component DDIs.

Figure 31 shows an example integration scenario, where the ETCS on-board system is developed by

company A using a specific tool for performing the safety assessment (e.g., ComposR) while the ETCS

trackside system is developed by company B using a different tool (e.g., safeTbox). The dependability-

related information is interchanged with the customer (e.g., a railway company operating the newly

developed ETCS system) using DDIs. The customer then integrates the safety case fragments as part of the

DDI information provided by companies A and B to create an overall safety case for the ETCS system using

its own tooling (e.g., ACME in our example scenario).

An example safety case of an ETCS system implemented in SACM is illustrated in Figure 32. Since the ETCS

system consists of an on-board and a trackside sub-system, the safety case also integrates a safety case

fragment for the on-board system and one for the trackside system. The On-Board Assurance Case Package

(ACP) – at the top of the figure – represents the safety case for the on-board system. The Trackside ACP –

at the bottom of the figure –- represents the safety case for the trackside system. These two safety case

fragments are integrated using the so-called Integration ACP, which is an SACM argumentation itself and

which is used to interlink the two safety cases of the ETCS sub-systems.

With this engineering story, we demonstrate the improvement of interoperability in the area of safety

engineering across companies, railway operators as well as safety authorities when using DDIs.

Interchanging safety-relevant information formalised by the DDIs will make safety engineering easier so

that different stakeholders can interchange information easier and work together more efficiently. Hence,

time and effort needed for the certification of systems (or sub-systems) in the railway domain can be

reduced significantly.


Page 54 of 65

Figure 32 – Example safety case fragment integration (ES3) for the ETCS use case


Page 55 of 65

7 Synthesis of runtime DDIs and utilisation in a system-of-systems scenario in

the context of a traffic light assistant

7.1 Use case overview

The traffic light assistant use case is based on an approach for the optimal control of a fully electric vehicle

and its powertrain approaching a road segment with Multiple Traffic Lights (TL), which is presented in

(Ferreira-Parrilla, 2014). A system referred to as the Traffic Light Assistant (TLA) was developed in order to

take over longitudinal control of the vehicle, thereby optimising the velocity trajectory when approaching

multiple traffic lights in traffic. The main goals of the system are to reduce energy consumption and CO2

emission, reduce the number of vehicle stops and the waiting times, and introduce smoother speed

profiles. The presented TLA approach has since been developed further to work with other powertrain

topologies (Jones, 2016).

Figure 33 - Overview of vehicle speed control with focus on the traffic light assistant

The fundamental work focuses on controlling an “ego vehicle” equipped with TLA, assuming complete

knowledge about the road conditions and traffic light signal phasing. In reality, not all information may be

accessible at all times to every vehicle. For example, if the current state of a traffic light or a pedestrian at

the side of a crossing is observed by an on-board camera or local V2I communication, the information


Page 56 of 65

would only be available to a vehicle close by. Such a vehicle, if equipped with automated driving functions,

would adapt its velocity accordingly to stop in front of the traffic light, or to safely let the pedestrian pass.

However, a following vehicle might not directly see the traffic light or the pedestrian and therefore would

be unable to anticipate the behaviour of the preceding vehicle. In such a case, a reaction can only occur

based on observation of the behaviour of the preceding vehicle. It is possible to improve energy efficiency

if the state of the traffic light or the presence of the pedestrian are known in advance.

7.2 ES6: Synthesis of dependability runtime models for safe system-of-systems

integration at runtime

The Traffic Light Assistance (TLA) system is a highly dynamic cooperative cyber-physical system in which

collaborations of vehicles and infrastructure components are created and terminated during runtime.

From the engineering perspective, the traffic light assistant is a cooperative application that is deployed to

several systems, which are integrated into a system of systems only at runtime. The consequence of this

observation is that the functionality of the cooperative TLA application needs to be designed by application

engineers with a holistic view of the intended cooperative application.

As the functional application design still abstracts from the decision which concrete system within the SoS

actually realises which part of the overall application, the next step is to meaningfully deploy parts of the

functionality to existing systems. An important part of this step is to consider existing organisational

structures within the domain; e.g., within the automotive domain, there are OEMs developing vehicle

platforms and suppliers providing components to be integrated into the vehicles by the OEMs. In future,

there will additionally be road infrastructure and global data provider system companies (e.g., providers of

real-time high-resolution maps or traffic condition information). By deploying different parts of the TLA

application to different systems considering different deployment variants, interfaces between these

systems will become visible. As these systems (1) are developed by different companies, which might not

even be in contact during the development phase, and (2) will have to integrate at runtime in a fully

automated manner, special attention has to be paid to the system interfaces.

To capture the black-box system description focusing on the interfaces between systems, a service-based

architecture model has been created for the TLA SoS containing three sub-systems: vehicle platform, traffic

light assistant system and traffic light system (Figure 34). As the assurance of dependability and, in

particular, of safety is a first-class objective of the TLA SoS, hazard and risk analyses have to be performed

at the level of the TLA SoS to identify afterwards which cause-effect chains of the cooperating systems (in

particular failure-caused deviations at the interface between systems) can lead to the violation of SoS safety

goals. Both safety-related activities have been carried out for the example SoS hazard “Run a red traffic

light when the TLA system has vehicle control”, which might lead to a side collision accident involving traffic

crossing the intersection. Excerpts of the TLA hazard and risk analysis as well the safety analysis carried out

with component fault trees are depicted in Figure 35 and Figure 36, respectively.


Page 57 of 65

Figure 34 – Service-oriented architecture for traffic light assistant system

Figure 35 - Effect analysis of service deviation at TLA input interface

soaml TLA Service Architecture

Traffic Light Assistant

RequestVelocity

RequestAcceleration

Energy-optimized intersection crossing

Deliver time untilbegin of red phasesof next traffic light

Deliver duration ofred phases of next

traffic light

Deliver positionof next traffic

light

Deliver currentposition of ego

vehicle

Deliver roadgradient for

complete scenario

Deliver velocityof one other

vehicle

Deliver distanceof one other

vehicle

Interpretation & Translation for TLA

Deliver time untilbegin of red phasesof next traffic light

Deliver duration ofred phases of next

traffic light

Deliver positionof next traffic

light

Vehicle & Environment

RequestVelocity

RequestAcceleration

Deliver currentposition of ego

vehicle

Deliver roadgradient for

complete scenario

Deliver velocityof one other

vehicle

Deliver distanceof one other

vehicle


Page 58 of 65

Figure 36 - Safety analysis of the TLA function regarding safety goal violation

Based on the interface safety analysis results, safety demands and safety guarantees can be derived that

have to be expressed for the cooperating system interfaces (Figure 37). These demands and guarantees

are basically safety requirements being passed from the demanding system to the guaranteeing system

and are used as the basis for the runtime integration of systems. By anticipating and modelling a certain

set of variations for these safety guarantees and demands, different cooperation modes emerge that

enable a pre-defined degree of flexibility for the development of systems which are to collaborate in the

TLA SoS at runtime. Without these variants, there would only be one possible cooperation mode for the

TLA SoS, which is unlikely to be realistic as the companies developing the systems are not in contact with

each other at design time.

Regarding the TLA system, safety demand variants have been defined for quality variations with respect to

the guaranteed bounds of input signal accuracy. Considering several combinations of different safety

[cft] TLA Function [TLA Function.cft]

«block»TLA System::Ego Vehicle::TLA Function

Cameraimage

TL ShiftPlan

«CFT»TLA Function

TL CurrentShift Plan

wrong Value

Camera imagedoes not containTL state change

«CFT Instance»(Acceleration Coordinator)

Overrun a red traffic light, whenTLA system has vehicle control

Emergencydeceleration_Too

Low

Nominalaccel._Too

High

«CFT Instance»(Side Collision Avoidance)

Distance toTL Too_High

No TL StateChange

detected(Camera)

Emergencydeceleration

Too_Low


wrongValue

«CFT Instance»(Self-localization)


«CFT Instance»(Optimal Trajectory Computation)


wrong Value


Accelerationvector Too_High

«CFT Instance»(Longitudinal Control)

Accelerationvector

Too_High

Nominaldeceleration

Too_Low

«CFT Instance»(Camera-based TL State

Detection)

No TL Statechange detected

(Camera)

Camera imagedoes not containTL state change


Page 59 of 65

demands, different safety guarantees can be expressed with varying degrees of confidence; e.g., a red

traffic light crossing is avoided with a certain degree of confidence at different speeds. Every safety

guarantee of the TLA system is related to a certain degradation mode; i.e., if only degraded quality can be

guaranteed, the speed ego vehicle equipped with the TLA is limited to a certain maximum value in order to

still be able to guarantee safety.

One possible model kind for expressing the safety interface (i.e., demands and guarantees) of a black-box

system regarding a service interface and the mapping variants of the system’s safety guarantees to

demands is a ConSert (=Conditional Safety Certificate) (Schneider D., 2013). ConSerts is one of the first

approaches worldwide that deals explicitly with runtime safety certification. The approach has been

developed at Fraunhofer IESE and builds almost completely upon traditional safety engineering techniques.

Therefore, ConSerts have been chosen in DEIS to represent a starting point for synthesising and expressing

runtime DDIs that are suitable for system-of-systems integration at runtime.

Design time safety engineering activities are a required input for the synthesis of runtime DDIs possibly

modelled as ConSerts. Therefore, the DDI concept as well as the design time ODE V1 packages described in

section 3.4 represent a solid foundation for adding support for the synthesis and integration of runtime

DDIs in upcoming ODE versions. This is illustrated in Figure 37, where the necessary additions for modelling

ConSerts are planned be added in a separate ODE RuntimeSafety package in the future.

It has been elaborated in this section how the DDI concept at both design time and runtime can help to

systematically engineer applications like the traffic light assistant in a distributed manner. In addition, a

potential process has been laid out for the synthesis of runtime DDIs based on design time DDIs modelled

with the first version of the ODE meta-model. This shows how the approach for extending the ODE meta-

model is envisioned by the DEIS consortium and, more importantly, how DDIs can be utilised to enable

innovative system-of-systems applications relying on connectivity and collaboration between

independently developed systems.


Page 60 of 65

Service-based system architecture model

Hazard and risk analysis regarding collaboration and

system interfaces

Cause-effect safety analysis

based on collaboration safety goals

ODE V1

ODE::Architecture

ODE::FailureLogic

ODE::Dependability

ODE::RuntimeSafety

ODE V2

Design time representation of safety guarantee-demand mapping variants

Figure 37 - Instantiation overview of ES6 for the traffic light assistant system


Page 61 of 65

8 Summary and outlook This document presented our approach to deriving and designing the high-level structure of the ODE meta-

model as well as its initial building blocks. To this end, section 3 described the envisioned DDI concept

including the utilisation of the SACM as the backbone of the DDI and the present state regarding concrete

packages for the ODE. On the one hand, the focus regarding the initial set of packages relied on harmonising

dependability engineering techniques (failure logic modelling, hazard and risk analysis, dependability

requirements decomposition) developed by the involved research partners under the umbrella of the ODE.

On the other hand, the derivation of the ODE meta-model was guided by a set of engineering stories

extracted from industrial use cases being developed in the DEIS project. Related work regarding the

currently existing ODE package contents was described in section 4. The above-mentioned engineering

stories were described in detail in section 5 and are intended to be supported by the ODE meta-model at

the end of the DEIS project. Finally, sections 6 and 7 exemplified the instantiation of selected engineering

stories in the context of specific use cases to illustrate both design time and runtime DDIs in action.

With the finalisation of this deliverable, the overall DDI vision and its operationalisation through the ODE

meta-model have been defined and exemplified with the help of engineering stories. Based on this

framework, the approach for the remainder of the DEIS project will be to extend the ODE meta-model with

additional model elements and packages. To date, not all of the engineering stories described in section 5

are supported yet by the ODE. Therefore, the ODE additions will be driven by the aim to improve support

for the existing engineering stories and to add support for new stories that are not yet supported. To keep

the application of the DDI concept tangible, we will continue demonstrating supported engineering stories

based on the evolution of models from the DEIS use cases.

Regarding concrete additions to the ODE meta-model for the upcoming work period, we identified support

for the synthesis of design time DDIs to runtime DDIs (engineering story 6 in section 5) as a major topic.

Our starting points for this synthesis are ConSerts and the SACM assurance case package interface

mechanism. In order to achieve dependable system-of-systems integration at design time, safety interface

abstraction in terms of failure propagation, safety argumentation and environmental assumptions have to

be added to the design time DDIs (engineering stories 3 and 4). Going one step further, this integration

might also have to be the subject of optimisation activities (engineering story 5).

A further aspect that will be tackled is the extension of the DDI with respect to other dependability

properties beyond safety and reliability, in particular cyber-security and privacy. Cyber-security plays an

important role, as malicious hacker attacks are emerging as a potential source of safety-critical hazards and

should thus be integrated with safety and architectural activities to achieve dependable behaviour

(engineering story 7). Privacy will come into play through our use cases that handle sensitive data, such as

the automotive use case of monitoring physiological driver health or the medical oncology use case.

Finally, the implementation of tool support for exchanging DDIs with varying levels of detail among different

stakeholders will continue to be driven as part of engineering stories 1 and 2.


Page 62 of 65

9 References

Adler, R., Domis, D., Höfig, K., Kemmann, S., Kuhn, T., Schwinn, J., & Trapp M. (2011). Integration of

component fault trees into the UML, Models in Software Engineering. (pp. 312-327). Springer.

Adler, R., Kemmann, S., Liggesmeyer, P., & Schwinn, P. (2012). Model-based development of a Safety

Concept. Proceedings of the 11th International Probabilistic Safety Assessment and Management

Conference and the Annual Eureopean Safety and Reliability ocnference, PSAM/ESREL 2012.

Helsinki, Finland.

Adler, R., Schneider, D., & Höfig, K. (2017). Evolution of fault trees from hardware safety analysis to

integrated analysis of software-intensive control systems. In proceeding of ESREL 2017. Portoroz,

Slovenia.

Andrews, Z., & Payne, R. (2014, October 28). Modelling and Analysis of Faults in SysML With application to

Systems of Systems. Retrieved from IMBSA 2014:

https://cse.cs.ovgu.de/imbsa2014/files/tutorial8/files/Fault%20Modelling%20and%20Analysis%2

0Tutorial.pdf

Andrews, Z., Bryans, J., Payne, R., & Kristensen, K. (2014). Fault Modelling in System-of-Systems Contracts.

arXiv.

Andrews, Z., Fitzgerald, J., Payne, R., & Romanovsky, A. (2013). Fault modelling for systems of systems. 11th

International Symposium on Autonomous Decentralized Systems (ISADS) (pp. 1-8). IEEE.

AUTOSAR. (2018). Retrieved from AUTOSAR: www.autosar.org

Avizienis, A., Laprie, J., Randell, B., & Landwehr, C. (2004). Basic concepts and taxonomy of dependable and

secure computing. IEEE Transactions on Dependable and Secure Computing, 1(1), 11-33.

Biehl, M., Chen, D., & Torngren, M. (2010). Integrating Safety Analysis into the Model-based Development

Toolchain of Automotive Embedded Systems. LCTES '10 Proceedings of the ACM SIGPLAN/SIGBED

2010 conference on Languages, compilers, and tools for embedded systems (pp. 125-131).

Stockholm, Sweden: ACM.

Biggs, G., Sakamoto, T., & Kotoku, T. (2016). A profile and tool for modelling safety information with design

information in SysML. Software & Systems Modeling 15, 147-178.

Chen, D., Mahmud, N., Walker, M., Feng, L., Lonn, H., & Papadopoulos, Y. (2013). Systems Modeling with

EAST-ADL for Fault Tree Analysis through HiP-HOPS. 4th IFAC Workshop on Dependable Control of

Discrete Systems (pp. 91-96). York, UK: IFAC.

Coleman, J., Malmos, A., Larsen, P., Peleska, J., Hains, R., Andrews, Z., . . . Didier, A. (2012). COMPASS Tool

Vision for a System of Systems Collaborative Development Environment. 7th International

Conference on System of System Engineering. Genova, Italy: IEEE.


Page 63 of 65

COMPASS. (2011). COMPASS Tool Tutorials. Retrieved from COMPASS: http://www.compass-

research.eu/tool-videos.html#hide9

Cozon, G., Spuge, J., & DNV. (2007). OATA Safety Assessment: Functional Hazard Assessment (En-Route).

European Organisation for the safety of air navigation.

Dehlinger, J., & Dugan, J. (2008). Analyzing Dynamic Fault Trees Derived from Model-Based System

Architectures. Nuclear Engineering And Technology, 40(5), 365-374.

DEIS Consortium. (2017). D2.1: Project Requirements.

Domis, D., & Trapp, M. (2008). Integrating safety analysis and component-based design. Computer Safety,

Reliability and Security (pp. 58-71). Springer.

Domis, D., & Trapp, M. (2009). Component-Based Abstraction in Fault Tree Analysis. In Computer Safety,

Reliability and Security (pp. 297-310). Springer.

Domis, D., Forster, M., Kemmann, S., & Trapp, M. (2009). Safety Concept Trees. Reliability and

Maintainability Symposium (RAMS 2009). , (pp. 212-217).

EAST-ADL. (2016). About EAST-ADL. Retrieved from EAST-ADL: www.east-adl.info/Specification.html

Efftinge, S., Friese, P., Haase, A., Kadura, C., Kolb, B., Moroff, D., . . . Voelter, M. (2007).

openArchitectureWare User Guide. openArchitectureWare Community.

ETCS/ERTMS. (2016, 05 12). Safety Requirements for the Technical Interoperability of ETCS in Levels

(Subset-091, Issue: 3.6.0).

Feiler, P., & Rugina, A. (2007). Dependability Modeling with the Architecture Analysis & Design Language

(AADL). Report prepared for the SEI Administrative Agent.

Feiler, P., Gluch, D., & Hudak, J. (2006). The Architecture Analysis & Design Language (AADL): An

Introduction. Retrieved from Carnegie Mellon University, Software Engineering Institute:

https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=7879

Ferreira-Parrilla, A. e. (2014). Traffic Light Assistant System for Optimized Energy Consumption in an Electric

Vehicle. ICCVE.

IEC 61508-2. (2010). Functional safety of electrical/electronic/programmable electronic safety related

systems. International Electrotechnical Commission.

IEC 62278. (2002). Standard for railway applications - Specification and demonstration of reliability,

availability, maintainability and safety (RAMS). International Electrotechnical Commission.

Ingram, C., Andrews, Z., Payne, R., & Plat, N. (2014). SysML fault modelling in a traffic management system

of systems. 9th International Systems of Systems Engineering Conference (SoSE 2014). Adelade,

Australia: IEEE.

ISO 26262. (2010). Road Vehicles - Functional Safety. International Organization for Standardization.


Page 64 of 65

Jones, S. e. (2016). V2X Based Traffic Light Assistant for Increased Efficiency of Hybrid & Electric Vehicles.

VDI Wissensforum.

Joshi, A., & Heimdahl, M. (2007). Behavioral Fault Modeling for Model-Based Safety Analysis. Proceedings

of the 10th IEEE High Assurance Systems Engineering Symposium (HASE'07) (pp. 199-208). Dallas,

USA: IEEE.

Joshi, A., Vestal, S., & Binns, P. (2007). Automatic Generation of Static Fault Trees from AADL Models.

Workshop on Architecting Dependable Systems DSN07-WADS. Edinburgh, Scotland, UK.

Joshi, Heimdahl, Miller, & Whalen. (2006). Model-based safety analysis. Nasa Langley Research Center.

Kaiser, B., Gramlich, C., & Förster, M. (2007). State/event fault trees - safety analysis model for software-

controlled systems. Reliability engineering & system safety 92, (pp. 1521-1537).

Kaiser, B., Liggesmeyer, P., & Mäckel, O. (2003). A new component concept for fault trees. SCS '03:

Proceedings of the 8th Australian workshop on Safety critical systems and software, (pp. 37 - 46).

Kaiser, B., Liggesmeyer, P., & Mäckel, O. (2003). A new component concept for fault trees. 8th Australian

Workshop on Safety Critical Systems and Software. Canberra.

Mahmud, N. (2012). Dynamic model-based safety analysis: from state machines to temporal fault trees.

Hull, UK: University of Hull.

Mian, Z., Bottaci, L., Papadopoulos, Y., & Biehl, M. (2012). System Dependability Modelling and Analysis

Using AADL and HiP-HOPS. 14th IFAC Symposium on Information Control Problems in

Manufacturing, (pp. 1647-1652). Bucharest, Romania.

Oates, R., Foulkes, D., Herries, G., & Banham, D. (2013). Practical extensions of safety critical engineering

processes for securing industrial control systems. 8th IET International System Safety Conference

incorporating the Cyber Security Conference. Cardiff, UK: IET.

Oates, R., Thom, F., & Herries, G. (2013). Security-Aware, Model-Based Systems Engineering with SysML.

1st International Symposium on ICS & SCADA Cyber Security Research (ICS-CSR 2013) (pp. 78-87).

Leicester, UK: BCS.

OMG. (2017). OMG SysML Specifications. Retrieved from OMG:

http://www.omgsysml.org/specifications.htm

Papadopolous, Y. (2000). Safety-Directed System Monitoring Using Safety Cases. York, U.K: The University

of York.

Papadopoulos, Y., & McDermid, J. (1999). Hierarchically Performed Hazard Origin and Propagation Studies.

Proceedings of the 18th International Conference on Computer Safety, Reliability and Security (pp.

139-152). LNCS 1608.

Pohl, K., Broy, M., Daembkes, H., & Hönninger, H. (2016). Advanced Model-Based Engineering of Embedded

Systems. Retrieved from http://spes2020.informatik.tu-muenchen.de/spes_xt-home.html


Page 65 of 65

Pohl, K., Hönninger, H., Achatz, R., & Broy, M. (2012). Model-Based Engineering of Embedded Systems - The

SPES 2020 Methodology. Springer-Verlag Berlin Heidelberg.

Rugina, A., Kanoun, K., & Kaaniche, M. (2007). An Architecture-based Dependability Modelling Framework

Using AADL. 10th IASTED International Conference on Software Engineering and Applications (SEA

'06), (pp. 222-227). Dallas, USA.

Rugina, A., Kanoun, K., & Kaaniche, M. (2008). The ADAPT Tool: From AADL Architectural Models to

Stochastic Petri Nets through Model Transformation. 7th European Dependable Computing

Conference (EDCC), (pp. 85-90). Kaunas, Lithuania.

SAE ARP 47641. (1996). Aerospace Recommended Practice (ARP): Guidelines and Methods for Conducting

the Safety Assessment Process on Civil Airborne Systems and Equipment. The Engineering Society

for Advancing Mobility Land Sea, Air and Space (SAE.

SAE Int'l. (2017, 01 18). Architecture Analysis & Design Language (AADL) AS5506C. Retrieved from SAE:

https://www.sae.org/standards/content/as5506c/

Schneider D., T. M. (2013). Conditional Safety Certification of Open Adaptive Systems. ACM Trans. Auton.

Adapt. Syst. , 8, 2, Article 8, 20 pages.

Sharvia, S., Papadopoulos, Y., Chen, D., Walker, M., Yuan, W., & Lonn, H. (2014). Enhancing the EAST-ADL

Error Model with HiP-HOPS Semantics. Athens Jounral of Technology Engineering, 137-154.

The Eclipse Foundation. (2018). ATL - a model transformation technology. Retrieved from eclipse:

http://www.eclipse.org/atl/

Walker, M. (2009). Pandora: A Logic for the Qualitative Analysis of Temporal Fault Trees. Hull, UK: University

of Hull.

Peter Fenelon, John A. McDermid, (1993):An Integrated Toolset For Software Safety Analysis,Journal of

Systems and Software.

Pohl, K., Broy, M., Daembkes, H., Hönninger, H. (2016): Advanced Model-Based Engineering of Embedded

Systems - Extensions of the SPES 2020 Methodology, springer

EAST-ADL Association (2013): EAST Architecture Description Language (ADL), www.east-adl.info

Peter Feiler and Dave Gluch, (2012) : Model-Based Engineering with AADL, Addison-Wesley Professional.

Oleg Lisagor, (2010):Failure Logic Modelling: A Pragmatic Approach, PHD thesis, University of York

Jose Luis de la VaraRajwinder Kaur Panesar-Walawege (2013): SafetyMet: A Metamodel for Safety

Standards, MODELS 2013. Lecture Notes in Computer Science, vol 8107. Springer, Heidelberg

SafeML: Safety Modeling Language, https://astahblog.com/2016/01/28/safeml-intro/

http://www.east-adl.info/Specification

Digital Dependability Identities and the Open ...

Documents