Conference PaperPDF Available

Automated Evidence Analysis of Safety Arguments using Digital Dependability Identities

Authors:

Abstract and Figures

Creating a sound argumentation of why a system is sufficiently safe is a major part of the assurance process. Today, compiling a safety case and maintaining its validity after changes are time-consuming manual work performed by safety experts based on their experience and knowledge. This work is further complicated when supplier components need to be integrated where important details might not be known. By using the concept provided by Digital Dependability Identities (DDI), we present an approach to automatically check evidence validity for safety requirements through leveraging from formal traceability between safety argument and evidence models being both parts of the DDI. This approach reduces the effort for creating and maintaining the system-level safety argument by (a) performing automated evidence analysis for safety requirements, (b) supporting a model-based multi-tier safety engineering process and (c) eliminating the human error source by relying on DDI scripts to encode safety engineering activities. We illustrate our approach using a case study from the railway domain, which focuses on the safety assurance of a train control system (ETCS).
Content may be subject to copyright.
© Fraunhofer IESE
1
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
Jan Reich (Fraunhofer IESE), Marc Zeller (Siemens AG), Daniel Schneider (Fraunhofer IESE)
@ SAFECOMP, 12th September 2019, Turku, Finland
AUTOMATED EVIDENCE ANALYSIS OF SAFETY ARGUMENTS
USING DIGITAL DEPENDABILITY IDENTITIES
DDI
Design
Time Runtime
© Fraunhofer IESE
2
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
PRESENTATION OUTLINE
Safety Argumentation 101
Arguments and Evidence models today
Integrated Safety Case Models with Digital Dependability Identities (DDI)
Automation with DDIs
Extension concept of DDIs
© Fraunhofer IESE
3
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
DEIS Project Overview
Dependability Engineering Innovation
for Cyber-Physical Systems“
H2020 ICT-01-2016 Grant No. 732242
01/2017 12/2019
Core Concept: Digital Dependability
Identities for design time and runtime
assurance
www.deis-project.eu
© Fraunhofer IESE
4
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
Safety Cases Explicit assurance arguments backed up by evidence
System X is sufficiently safe in its
operating environment
ASafety Case should communicate aclear, comprehensible and defensible
argument that asystem is acceptably safe to operate in aparticular context.
© Fraunhofer IESE
5
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
The top opportunities for using safety cases in practice
Efficient safety change
management and
impact analysis
Understanding and
planning required
assurance activities for
complex systems
(AI, autonomy, CPS)
Establish basis for
transparent safety
assessment and
certification
© Fraunhofer IESE
6
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
The anatomy of a safety assurance claim
Claim
Failure Rate of Trackside Functions
(„trusted part“) <= 0,67e-09/h has
been demonstrated.
„Trackside
functions“?
What is a compliant
demonstration?
Techniques? Processes?
„Trusted
part“?
Which failures in
which operating
conditions?
Required
confidence?
European Train Control System (ETCS)
(Integrator)
Trackside
System
(Supplier 2)
Onboard
System
(Supplier 1)
demands
guarantees
LEU =
Lineside Electronic Unit
© Fraunhofer IESE
7
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
The natural interrelation of safety argument and safety engineering artifacts
Goal
Failure Rate of Trackside Functions
(„trusted part“) <= 0,67e-09/h
has been demonstrated.
Solution
FTA Result
of FT for
H1
Strategy
Argument over sum of occurence
probabilities of hazards of
trackside functions <= 0,67e-09/h
Context
Hazard List of
Trackside Functions
(„trusted part“)
Solution
FTA Result
of FT for
H2
Goal
Failure Rate of H1 <= 0,2e-09/h
has been demonstrated.
Goal
Failure Rate of H2 <= 0,3e-09/h
has been demonstrated.
Goal
Failure Rate of H3 <= 0,37e-
09/h has been demonstrated.
Solution
FTA
Result of
FT for H3
Context
UNISIG ERTMS/ETCS
specification Subset-091
Context
CENELEC EN 50128
Safety Standard
7
The safety engineering artifact heap...
Functional
models
Structural
models
System
Hazards
Safety
analyses Test
results
Process &
Standard
descriptions
Requirements
© Fraunhofer IESE
8
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
The research problems
How to provide semantic
traceability between typical
evidence used in safety arguments?
8
Functional
models
Structural
models
System
Hazards
Safety
analyses Test
results
Process &
Standard
descriptions
Requirements
How to formally trace safety
arguments to their evidence?
Goal
Failure Rate of Trackside Functions
(„trusted part“) <= 0,67e-09/h has
been demonstrated.
Solution
FTA Result
of FT for H1
Solution
FTA Result
of FT for H2
How to do
something useful
with the
integrated model?
© Fraunhofer IESE
9
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
Digital Dependability Identities (DDI) as model-connected safety cases
DDI@DesignTime
Assurance
Case
System
Structure
Failure
Logic
Hazards
& Risks
Dependability
capabilities
System
Behavior
Dependability
Goals
Assurance
Strategies
Validation &
Verification
strategies
V&V
Evidence
HARA models
© Fraunhofer IESE
10
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
Hazardous Event
+ RiskAssessment: SIL 3
MCS1: MinimalCutSet
Example DDI for ETCS
Claim
Failure Rate of Trackside Functions
(„trusted part“) <= 0,67e-09/h
has been demonstrated.
Artifact
Quantitative Analysis
of FT for H1
Strategy
Argument over sum of
occurence probabilities
of hazards of trackside
functions <= 0,67e-09/h
Claim
Failure Rate of H1 <= 0,2e-09/h
has been demonstrated.
Train Localization: Function
Trackside System : System
<Wrong> Train Localization
: Malfunction
Other train on same track with opposite
driving directions: Situation
H1: Train Erroneously Localized Before
Commanded Braking Point: Hazard
Trackside Failure Propagation
Model : Fault Tree
Erroneous Eurobalise
Telegram interpreted as
correct : Failure Cause
Euro-Balise:
System
Euroloop:
System
LEU:
System
Wrong Train Localization :
Output Failure Mode
Erroneous Euroloop
Detection as active:
Failure Cause
+ FailureRate = 0,18e-09/h
Eurobalise Euroloop
Output Plausibilization:
Safety Function
HARA
Design
Measure
Failure Logic
ETCS specification
Subset-091: Safety
Standard
Domain CENELEC EN 50128:
Safety Standard
+ TargetFailureRate Failure Rate
Demonstration: Activity
© Fraunhofer IESE
11
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
Process & Product Reference Models provide explicit semantics for argument
Hazard
FT
TopEvent
+ FailureRate: double
Function
Product Evidence
Reference Model
Activity
Technique
Artifact(s)
QualityCriteria
Process Evidence
Reference Model
produces/
consumes/queries
Argument
definition
semantics
Artifact
relation
semantics
Argument
Artifact Artifact
Failure Rate of H1
Artifact
FaultTree model for H1
Terminology
Term
Failure Rate
Demonstration
Term
Trackside Functions
(„trusted part“)
Claim
Failure Rate of Trackside Functions
(„trusted part“) <= 0,67e-09/h
has been demonstrated.
ArtifactReference
FTA Result of FT
for H1
operates on
+ resourceRefQuery
+ resourceRefQuery
+ resourceRefQuery
Safety Argument
Model (SACM*)
* SACM = Structured Assurance Case Metamodel
© Fraunhofer IESE
12
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
Open Safety
Meta-Model
Common Assurance
and Certification
Metamodel (CACM)
© Fraunhofer IESE
13
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
ODE v2 Details
13
TARA
Failure
Logic Markov
FMEA FTA
System Design
Base
Terminology
Artifact
Argumentation
Assurance
Case
HARA
Domain
Requirements
Measure
CACM
© Fraunhofer IESE
14
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
Model Built Now what to do with it?
Safety Argument Validity Analysis
Did I cover all analyzed hazards in „Argue over all hazards...“?
Executed processes fit standard‘s demands? (e.g. Do FT + FMEA models exist for ASIL C/D safety
goals with certain quality criteria?)
Change Impact Analysis
Signal X changed -which safety requirements or test cases affected?
Argument Fragment Instiatiation
Automatic instantiation of argument decomposition strategy („argue over X“)
Custom parameterization of argument elements and enforcement of completeness
Drive and control safety engineering activities
How many hazards don‘t have safety analysis models yet?
<Replace with your favorite analysis >
© Fraunhofer IESE
15
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
Executing DDI scripts to automatically check the failure rate
Activity
Demonstrate FailureRate for Hazard
Params: {Hazard}, {TargetRate}
1. Get all system functions contributing to {Hazard}
2. Perform quantitative fault tree analysis on all fault trees related to
functions.
3. Compare the sum of computed top event failure rates with {TargetRate}
Input
DDI
Output
Boolean Result :=
Claim Validity
Formal Activity
Get system functions leading to hazard H
DDI Query
Get all {Function} of {System}:„Trackside System“,
where #({Hazard}) > 0 && {Hazard}.includes(H)
Term
Failure Rate
Demonstration
Formal Activity
Perform quantitative fault tree analysis
DDI Query
Get all {FaultTree} of {Functions}.ForAll(
ft => quantitativeAnalysis({TopEvent}.isAssociatedToHazard(H)).FailureRate)
[Functions]
Formal Activity
Compare failure rate sum with
Target Rate
+<= {TargetRate}
[FailureRates]
© Fraunhofer IESE
16
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
DDI Model File DDI Script
The DDI Automation Framework
Activity
Demonstrate
FailureRate for Hazard
eclipse.org/epsilon/
Modeling Tools
ACME
ComposR
Download/try/challenge our framework at:
https://github.com/DEIS-Project-EU/ODEv2
© Fraunhofer IESE
17
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
Conclusion
~20 years of project-proven design time safety assurance practice put together in overarching
conceptual framework
To date, it is the only framework that systematically provides semantics for both argument & evidence
Freely available meta-model, scripting engine and reference modeling tools enable adoption by
industry
Apart from railway, DDIs have been successfully evaluated in automotive and medical use cases
We‘re not done yet!
Current: Coverage of left side of V-model for safety & security
Future:
Verification & Validation packages
Dynamic safety assurance packages
Environment modeling for SOTIF and Autonomy assurance (UL 4600, AAIP BoK, RSS, ...)
© Fraunhofer IESE
18
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
Ongoing and future work
18
© Fraunhofer IESE
19
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
Functional /
Technical
Assumptions
What‘s next: Assuring Autonomy with DDIs (cf. WAISE Keynote Tuesday)
Operational
Design Domain
Technical
Context
Fault
Models
Activity
Guidephrase-Based
Safety Analysis
Claim
Backlight in a driving situation does not violate the assumption
sufficient contrast leading to an omission failure of the object
detection with sufficient confidence.
ODE v3?v4?
© Fraunhofer IESE
20
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
Analyze Risk
Dependability
Knowledge
Environment System
Monitor Events
Plan
Adaptation
Execute
Adaptation
Dependability
Control
Dependability
Sensing
Dependability
Reasoning
Engineer
DDI@DesignTime
Assurance
Case
System
Structure
Failure
Logic
Hazards
& Risks
Dependability
capabilities
System
Behavior
Dependability
Goals
Assurance
Strategies
Validation &
Verification
strategies
Conditional
Certificates
Dependability
Intelligence
Deployment
Experience Feedback
from Operation
DDI
@RunTime
Engineering &
Assurance Methods
© Fraunhofer IESE
21
Follow the DEIS Project on LinkedIn
linkedin.com/company/deis-project/
Thank you for your interest! Questions or remarks?
Integrated and model-
based design time DDI
engineering with our tool M.Sc. Jan Reich
Project Manager
Systematic Safety Assurance
@ Fraunhofer IESE, Germany
jan.reich@iese.fraunhofer.de
www.iese.fraunhofer.de
Get in touch with me for further
details on our approaches for...
Dynamic risk management to
assure complex/AI-based
behavior at runtime with the
www.safeTbox.de
... Accompanying engineering methods and tools have been developed to enable distributed dependability engineering in multi-tier integrator-supplier scenarios [3]. In [4], we showed, for an industrial railway use case, how to use design-time DDIs to automatically verify safety requirements with component fault trees and model-based evidence lifecycle documentation. ...
... Consequently, runtime DDIs need to be developed with appropriate model contents and runtime mechanisms to enable dependable integration and cooperation at runtime. The upcoming sections take the approach outlined in [4] to engineer design-time DDIs as a basis and add on top the aspect of how to address openess and adaptivity challenges. Therefore, the specific content additions of runtime DDIs are explained, exemplified for a cooperative platooning application and a process for their systematic derivation is proposed. ...
Chapter
Full-text available
Cyber-Physical Systems (CPS) harbor the enormous potential for societal improvement in terms of safety, comfort and economic efficiency. However, these benefits will only be unlocked if the safety of these systems can be assured with a sufficient level of confidence. Traditional safety engineering and assurance approaches alone cannot address the CPS-inherent uncertainties and unknowns induced by openness and adaptivity. Runtime safety assurance approaches such as Conditional Safety Certificates (ConSerts) represent novel means to cope with CPS assurance challenges by introducing modular and formalized safety arguments with variant support, thereby shifting the final safety certification step to runtime. However, the systematic engineering of ConSerts at design-time is a complex task which, up to now, has not been sufficiently addressed. Without systematic safety assurance at both design-time and runtime, CPS will hardly be assurable with acceptable confidence given the uncertainties and unknowns. In this paper, we present an engineering method for synthesizing ConSerts based on Digital Dependability Identities (DDI). The approach is demonstrated for a cooperative vehicle platooning function (CACC) from an industrial case study.
... Accompanying engineering methods and tools have been developed to enable distributed dependability engineering in multi-tier integrator-supplier scenarios [3]. In [4], we showed, for an industrial railway use case, how to use design-time DDIs to automatically verify safety requirements with component fault trees and model-based evidence lifecycle documentation. ...
... Consequently, runtime DDIs need to be developed with appropriate model contents and runtime mechanisms to enable dependable integration and cooperation at runtime. The upcoming sections take the approach outlined in [4] to engineer design-time DDIs as a basis and add on top the aspect of how to address openess and adaptivity challenges. Therefore, the specific content additions of runtime DDIs are explained, exemplified for a cooperative platooning application and a process for their systematic derivation is proposed. ...
Preprint
Full-text available
Cyber-Physical Systems (CPS) harbor the enormous potential for societal improvement in terms of safety, comfort and economic efficiency. However, these benefits will only be unlocked if the safety of these systems can be assured with a sufficient level of confidence. Traditional safety engineering and assurance approaches alone cannot address the CPS-inherent uncertainties and unknowns induced by openness and adaptivity. Runtime safety assurance approaches such as Conditional Safety Certificates (ConSerts) represent novel means to cope with CPS assurance challenges by introducing modular and formalized safety arguments with variant support, thereby shifting the final safety certification step to runtime. However, the systematic engineering of ConSerts at design-time is a complex task which, up to now, has not been sufficiently addressed. Without systematic safety assurance at both design-time and runtime, CPS will hardly be assurable with acceptable confidence given the uncertainties and unknowns. In this paper, we present an engineering method for synthesizing ConSerts based on Digital Dependability Identities (DDI). The approach is demonstrated for a cooperative vehicle platooning function (CACC) from an industrial case study.
... DDIs [12,13] enable seamless integration of cyber-physical systems throughout their life-cycle i.e. both during development, as well as during deployment and operation. DDIs encapsulate dependability properties (i.e. ...
Chapter
The production sector is experiencing significant transformations driven by comprehensive digitalization, interconnection, and further automation advances. One sub-sector that can benefit significantly from these trends is the production of Advanced Therapy Medicinal Products (ATMPs). ATMPs show promise for treating different serious conditions, but they are very expensive—being patient tailored products whose production is a highly manual, minimally automated process. In a recent research project with an ATMP producer, we investigated how the degree of automation can be increased. It became apparent that in parallel to increasing automation across the actual production steps, quality assurance needs to be addressed in a similar way. This paper introduces a framework for automating (parts of) the quality assurance of ATMPs using two concepts: (a) digital shadows or twins and (b) assurance cases. We demonstrate its conceptual implementation along a case study for Car-T cell products used to treat certain forms of cancer.
... Moreover, the evidences to prove that the claims are fulfilled are crated automatically in the pipeline (in the safety analysis and test & verification steps). According to [18] the relationships between the claims in the safety argumentation and evidences provided by the artifacts represented in an ODE model can created automatically. The resulting safety case can then be checked w.r.t. ...
Preprint
Traditionally, promoted by the internet companies, continuous delivery is more and more appealing to industries which develop systems with safety-critical functions. Since safety-critical systems must meet regulatory requirements and require specific safety assessment processes in addition to the normal development steps, enabling continuous delivery of software in safety-critical systems requires the automation of the safety assessment process in the delivery pipeline. In this paper, we outline a continuous delivery pipeline for realizing continuous safety assessment in software-intensive safety-critical systems based on model-based safety assessment methods.
Article
Full-text available
Context: Many critical systems must comply with safety standards as a way of providing assurance that they do not pose undue risks to people, property, or the environment. Safety compliance is a very demanding activity, as the standards can consist of hundreds of pages and practitioners typically have to show the fulfilment of thousands of safety-related criteria. Furthermore, the text of the standards can be ambiguous, inconsistent, and hard to understand, making it difficult to determine how to effectively structure and manage safety compliance information. These issues become even more challenging when a system is intended to be reused in another application domain with different applicable standards.
Conference Paper
Full-text available
A crucial aspect of safety case management is the ongoing maintenance of the safety argument through life. Throughout the operational life of any system, the corresponding safety case can be challenged by changing regulatory requirements, additional safety evidence and a changing design. In order to maintain an accurate account of the safety of the system, all such challenges must be assessed for their impact on the original safety argument. This is increasingly being recognised by many safety standards. However, many safety engineers are experiencing difficulties with safety case maintenance at present, the prime reason being that they do not have a systematic and methodical approach by which to examine the impact of change on safety argument. This paper presents an approach that begins to address these difficulties by defining a process, based upon the principles of goal structuring, for the systematic impact assessment of safety case challenges.
Conference Paper
Full-text available
This paper introduces a new method for safety analysis called HiP- HOPS (Hierarchically Performed Hazard Origin and Propagation Studies). HiP-HOPS originates from a number of classical techniques such as Functional Failure Analysis, Failure Mode and Effects Analysis and Fault Tree Analysis. However, it extends, automates and integrates these techniques in order to address some of the problems currently encountered in complex safety assessments. The method enables integrated assessment of a complex system from the functional level through to the low level of component failure modes. It mechanises and simplifies a large part of the analysis, the development of fault trees, and can guarantee the consistency of results. HiP-HOPS is currently supported by a tool called the Safety Argument Manager (SAM). In this paper we introduce the method and we show how it has helped us analyse and improve the safety of a distributed brake-by-wire system for cars.
Conference Paper
Full-text available
The decomposition of complex systems into manageable parts is an essential principle when dealing with complex technical systems. However, many safety and reliability modelling techniques do not support hierarchical decomposition in the desired way. Fault Tree Analysis (FTA) offers decomposition into modules, a breakdown with regard to the hierarchy of failure influences rather than to the system architecture. In this paper we propose a compositional extension of the FTA technique. Each technical component is represented by an extended Fault Tree. Besides the internal basic events and gates, each component can have input and output ports. By connecting these ports, components can be integrated into a higher-level system model. All components can be developed independently and stored in separate files or component libraries. Mathematically, each Component Fault Tree represents a logical function from its input ports and internal events to its output ports. As in traditional FTA, both qualitative and quantitative analyses are possible. Known algorithms e.g. based on Binary Decision Diagrams (BDDs) can still be applied. The Windows based safety analysis tool UWG3 has been developed to prove this concept in practice. It allows creating component libraries in an exchangeable XML format. We have carried out some case studies in order to show that the new concept improves clearness and intuitive modelling while maintaining the same results as traditional FTA.
The goal structuring notation -a safety argument notation
  • T Kelly
  • R Weaver
Kelly, T., Weaver, R.: The goal structuring notation -a safety argument notation. In: Proc. of the dependable systems and networks workshop (2004)