Systematic Identification of Functional Deficiencies by means of Component Fault Trees

Abstract

A central component of semi-automated and highly automated driving functions is always the vehicle’s perception of its surroundings. Depending on the specific requirements of the automation function, this perception can often be realized in very different ways using a great variety of different sensor combinations. This requires taking into account that every sensor has inherent strengths and weaknesses in terms of realizing a particular aspect of how it perceives the surroundings. A camera, for instance, is very limited in its ability to detect something when it is dark. These inherent weaknesses result in limits to the perception and thus to the usage area of the (automated) driving function. Beyond this usage area, use of the function is generally unsafe. Creating a safe specification thus requires identification of the safe usage context. For the usage context of automated driving functions, the term Operational Design Domain (ODD) has become the term of choice.
The SOTIF standard ISO/PAS 21448 contributes to the identification and shaping of the ODD as it addresses the identification and treatment of functional insufficiencies. It focuses strongly on simulations and testing, but in Table 4 in Section 9.2, it also mentions “Analysis of functional dependencies” to derive a V&V strategy. Testing and simulations are essential, but they cannot replace systematic analyses at the level of the functional architecture, which also enable focused testing and simulations with regard to identified weaknesses. However, this standard does not describe any concrete approaches for how to perform such an analysis at the functional level.
In our presentation, we will introduce an approach for investigating a functional architecture in order to derive the Operational Design Domain. Correspondingly, the prerequisite is a functional architecture representing the processing of information and the data dependencies in a component composition diagram (UML), an internal block diagram (SysML), or another actor-oriented model. Then an analysis is performed along the functional dependencies using component fault trees to determine why a particular kind of required perception might fail.

Full text

© Fraunhofer IESE
Systematic Identification of Functional Deficiencies by
means of Component Fault Trees
Dr. Rasmus Adler
https://www.iese.fraunhofer.de/de/customers_industries/automotive/
referenzprojekt_robertbosch_Clouddienst.html

© Fraunhofer IESE
Outline
Introduce component fault trees (CFTs)
Identifying deficiencies using CFTs
Function
Automated Driving System Feature
Handling deficiencies
Operational Design Domain
Runtime Assurance Cases

© Fraunhofer IESE
Outline
Introduce component fault trees (CFTs)
Identifying deficiencies using CFTs
Function
Automated Driving System Feature
Handling deficiencies
Operational Design Domain
Runtime Assurance Cases

© Fraunhofer IESE
Fault Trees
BE2BE1
Out1
Top event
Basic event
Boolean gates (intermediate events)
Support deductive reasoning

© Fraunhofer IESE
Fault Trees
Become easily very large
→Paging
Page 1
Page 1.1
Page 1.2
Page 1.2.1

© Fraunhofer IESE
Fault Trees
Page 1
Page 1.1
Page 1.2
“Deep copies” instead of “instances” complicate maintenance

© Fraunhofer IESE
Component Fault Trees introduce instantiation
«CFTComponentInstance»
Component 1
Out1
«CFTComponentInstance»
Component 2
IN1
OUT1 OUT2
«CFTComponentInstance»
Component 3
IN1
OUT1
IN2
Top Event
Basic event 1
IN1
OUT1
IN2
«CFTComponentInstance»
Component 2_1
In1
Out1
«CFTComponentInstance»
Component 2_2
IN1
OUT1 OUT2
IN1
OUT2OUT1
BE2BE1
Out1
Out1
In1
BE1
BE1
OUT2OUT1
BE2
IN1

© Fraunhofer IESE
Component Fault Trees introduce formal traceability
formaler Link
CFT’s are linked with
components / blocks / functions

© Fraunhofer IESE
Tool support: safeTbox
9
https://safetbox.de/

© Fraunhofer IESE
Outline
Introduce component fault trees (CFTs)
Identifying deficiencies using CFTs
Function
Automated Driving System Feature
Handling deficiencies
Operational Design Domain
Runtime Assurance Cases

© Fraunhofer IESE
CFTs for “functions” that provide information
Wheel speed Ego vehicle speed
OR
Too high speedToo high wheel speed Internal fault
•Application Software
•Operating system software
•Execution platform failure
(Hardware)
Example: Function that provides the vehicle speed

© Fraunhofer IESE
Semantic of deviations like „too high“
Wheel speed Ego vehicle speed
OR
Too high speed
Too high speed
for the functions that use the information?
→ context dependent “failure” → in conflict with reuse
compared to that what the functional specification states?
→ specification deviation → no input failures as cause
compared to the “perfect” output!
→ proposed semantic / includes specification deficiencies

© Fraunhofer IESE
Types of specification deficiencies
Fundamental
assumptions
Performance limits

© Fraunhofer IESE
Outline
Introduce component fault trees (CFTs)
Identifying deficiencies using CFTs
Function
Automated Driving System Feature
Handling deficiencies
Operational Design Domain
Runtime Assurance Cases

© Fraunhofer IESE
Relation between features and functions
Sensor /
Actuator
Mapping
Controller Control physical state variables
to implement features
Derive required information
from measurements
Measurement Measurement
Derive required actions for
fulfilling control commands
Action Action

© Fraunhofer IESE
Relation between features and functions
Sensor Actuator
MappingFeatureMapping
accelerate

© Fraunhofer IESE
Modeling CFTs for features
Traditional approach Feature-oriented approach [1]
[1] Adler, Rasmus & Schneider, Daniel & Höfig, Kai. (2017). Evolution of fault trees from
hardware safety analysis to integrated analysis of software-intensive control systems.
522-522. 10.1201/9781315210469-447.
Mapping
between
feature
failures to
actuator
failures?

© Fraunhofer IESE
Start at the function that realizes the feature
feature:
acceleration
≥ 1
Incorrect input Incorrect
processing of output
Specification
incorrectly
implemented
Specification
deficiencies

© Fraunhofer IESE
Why is the command not correctly implemented?
Specification
incorrectly
implemented
≥ 1
Specification
deficiencies
Incorrect
processing of
outputs

© Fraunhofer IESE
Big picture: Causes for deviations from intention
Sensor /
Actuator
Mapping
Controller OR
OR OR
OR OR OR OR
Causes include deficiencies (assumptions and performance limits)
Insufficiency: unacceptable deficiency
Feature “failure”

© Fraunhofer IESE
Outline
Introduce component fault trees (CFTs)
Identifying deficiencies using CFTs
Function
Automated Driving System Feature
Handling deficiencies
Operational Design Domain
Runtime Assurance Cases

© Fraunhofer IESE
Operational Design Domain
Operational Design Domain: “The specific conditions under which a given
driving automation system or feature thereof is designed to function,
including, but not limited to, driving modes” SAE J3016 2016-09
4.2.30 Operational Design Domain (ODD): “The set of environments and
situations the item is intended to operate within. This includes not
only direct environmental conditions and geographic restrictions, but also
a characterization of the set of objects, events, and other conditions that
will occur within that environment.” UL 4600
→What drives this design and this intention?
The business case and the technical feasibility (costs)

© Fraunhofer IESE
Operational Design Domain
ODD is driven by
the business case
and the needs of
the user
ODD is driven by
the capabilities
of the driving
automation
system
User needs
System capability
“Perfect capability” “Functional deficiencies
with respect to perfect
capability”
Feature
→ Deficiencies “shape” the ODD

© Fraunhofer IESE
Operational Design Domain
[1] Simon Burton’s keynote at SafeComp 2019 (and keynote at Issre 2019)
ODD
[1]

© Fraunhofer IESE
Function F1
algorithm 1
algorithm 2
algorithm n
.
.
.
data quality
signal
parameter 1 … parameter n
quality
quality
quality
quality
quality
quality
qualityquality
data
data
Managing deficiencies by runtime adaptation
quality formalizes
deficiencies
(assumptions and
performance limits)
“Engineering and Hardening of Functional Fail-Operational Architectures for
Highly Automated Driving” ISSRE 2019

© Fraunhofer IESE
Managing deficiencies by runtime adaptation
Monitor Plan Actuate
…
…
…
…
Function
Function
Function
Function

© Fraunhofer IESE
Runtime assurance cases / Digital Dependability Identity
http://www.deis-project.eu
Capture deficiencies in a machine-readable
assurance case
Handle deficiencies at runtime
Example: “Road condition service”
Assumption: No foliage on the highway
→Check this assumption at runtime

© Fraunhofer IESE
Summary and conclusion
Identifying functional deficiencies is mandatory for assuring safety
ODD definition is mandatory and deficiencies shape the ODD
Analytic reasoning is an efficient and powerful means for identifying
deficiencies
Important input for testing / simulation: “unknown performance limits”
Generalize cases from testing / simulation
Presented CFT approach supports analytic reasoning
Focus on single algorithms/functions and relate their deficiencies to
deficiencies of features

© Fraunhofer IESE
Contact:
Dr. -Ing. Rasmus Adler
Fraunhofer IESE
Program Manager “Autonomous Systems”
Fraunhofer-Platz 1 | 67663 Kaiserslautern | Germany
Phone: +49 631 / 6800-2172
Email: Rasmus.Adler@iese.fraunhofer.de
Thank you for your interest