Content uploaded by Rasmus Adler
Author content
All content in this area was uploaded by Rasmus Adler on May 20, 2020
Content may be subject to copyright.
© 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
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
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