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.
Discover the world's research
20+ million members 135+ million publications 700k+ research projects Join for free
© Fraunhofer IESE
Systema tic Identificat ion of Functional Deficiencies by
means of Compone nt Fault T rees
Dr. Rasmus Adler
https:// www.iese.fraunhofer.de/de/customers_i ndustries/ automotive/
referenzprojekt_ro bertbosch _Cloudd ienst.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
T op 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 Tr ees introduce instantia tion
«CFTComponentInstance»
Component 1
Out1
«CFTComponentInstance»
Component 2
IN1
OUT1 OUT2
«CFTComponentInstance»
Component 3
IN1
OUT1
IN2
Top Event
«CFTComponentInstance»
Component 2_1
In1
Out1
«CFTComponentInstance»
Component 2_2
IN1
OUT1 OUT2
IN1
OUT2 OUT1
© Fraunhofer IESE
Component Fa ult Trees intr oduce forma l traceabilit y
formaler Link
CFT’ s are linked with
components / blocks / functions
© Fraunhofer IESE
Tool support: safeTbox
9
https://safetb ox.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 “f unctions” that pr ovide informa tion
Wheel sp eed Ego vehicle speed
OR
T oo high speed T oo high wheel speed Internal fault
•Applicati on Software
•Operating sy stem software
•Execution platform failu re
(Hardware)
Example: Function that provides the vehicle speed
© Fraunhofer IESE
Semantic of deviations like „too high“
Wheel sp eed Ego vehicle speed
OR
T oo 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 specif ication def iciencies
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 betw een feat ures and functions
Sensor /
Actuator
Mapping
Controller Con trol physica l state varia bles
to impleme nt feature s
Derive required inf ormation
from me asureme nts
Measurement Measur ement
Derive req uired actio ns for
fulfill ing control commands
Action Action
© Fraunhofer IESE
Relation betw een feat ures and functions
Sensor Actuator
Mapping Feature Mapping
accelerate
© Fraunhofer IESE
Modeling CFTs for feature s
T raditional approach Feature-oriented approach [1]
[1] Adler, Rasmus & Schneider, Danie l & Höfig, Ka i. (201 7). Evoluti on of faul t trees fro m
hardwa re safety an alysis to in tegrated analysis o f software- intensi ve contro l systems.
522- 522. 10.1201/9781315 210469- 447.
Mapping
between
feature
failures to
actuator
failures?
© Fraunhofer IESE
Start at the func tion that realizes the feature
feature:
acceleration
≥ 1
Incorrect input Incorrect
processing of output
Specificatio n
incorrectly
implemented
Specificatio n
deficiencie s
© Fraunhofer IESE
Why is the com mand not corre ctly implem ented?
Specificatio n
incorrectly
implemented
≥ 1
Specificatio n
deficiencie s
Incorrect
processing of
outputs
© Fraunhofer IESE
Big picture: Caus es for devia tions 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 D esign Doma in
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 mode s” 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 D esign Doma in
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 capabi lity
“Perfect capability” “Functional deficiencies
with respect to perfect
capability”
Feature
→ Deficiencies “shape” the ODD
© Fraunhofer IESE
Operational D esign Doma in
[1] Simon B urton’s keynote at SafeComp 2019 (and keyno te at Issre 2019)
ODD
[1]
© Fraunhofer IESE
Function F1
algorithm 1
algorithm 2
algorithm n
.
.
.
data quality
signal
parameter 1 … p arameter n
quality
quality
quality
quality
quality
quality
quality quality
data
data
Managing defic iencies by runtim e adaptat ion
quality formalizes
deficiencies
(assumptions and
performance limits)
“Engineering and Hardening of Functional Fail- Opera tional Architectures for
Highly Automat ed Driving ” ISSRE 2019
© Fraunhofer IESE
Managing defic iencies by runtim e adaptat ion
Monitor Plan Actuate
…
…
…
…
Function
Function
Function
Function
© Fraunhofer IESE
Runtime assura nce cases / Digital Depe ndability Identit y
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:
D r. -Ing. Rasmus Adler
Fraunhofer IESE
Program Manager “Autonomous Systems”
Fraunhofer-Platz 1 | 67663 Kaisersl auter n | Germany
Phone: +49 631 / 6800- 2172
Email: Rasmus.Adler@iese.fraunho fer.de
Thank y ou for your interest
ResearchGate has not been able to resolve any citations for this publication.
ResearchGate has not been able to resolve any references for this publication.
Artificial Intelligence (AI) methods such as Machine Learning (ML) and especially Deep Learning (DL) are widely used in non-critical applications such as language assistants. In safety-critical env
ironments, there are also many use cases with huge economic potential, but this potential cannot be fully exploited yet at present. One prominent example is the use of ML-based object recognition for automated driving. There are many approaches aimed at making ML-based components more dependable, and due to intensive research, more and more new approaches are emerging. Manufacturers are supposed to keep up with the state of the art and the state of the practice, but how can they do this if research keeps publishing new results almost daily, and if these results may even represent different viewpoints? Safety standards are intended to describe the assured state of the practice, but traditional standards such as the basic safety standard IEC 61508 do not take AI developments into account. They assume that safety functions are realized without AI and that AI components are assured through these traditional safety functions. Although there are many standards that deal with AI, they are not sufficient with regard to safety or refer to traditional safety standards, such as the technical report ISO/IEC TR 24028 “Overview of trustworthiness in artificial intelligence”. The technical report ISO/IEC AWI TR 5469 “Functional safety of AI-based systems” currently under development may be able to answer the question of what is generally accepted when it comes to the use of AI in safety-critical contexts. However, it will not be able to provide custom-tailored safety concepts. To do this, safety and AI experts must work together and mutually understand each other’s mindset and terminology.
The use of ML, in particular, signifies a change of the development paradigm: In the development of a classical system, the system is typically specified, refined, implemented, and tested by engineers, who consider safety requirements. If, on the other hand, ML is used for specific, usually complex, tasks, a set of example data serves as a detailed specification; on this basis, a learning algorithm generates a model that is used in the final system (after being checked on more example data) to implement a specific function. However, it is known that the way in which these models are developed is (often) not deterministic. In addition, the quality of such models depends, among other things, on the data used, the process, the learning algorithms used (product), and the expertise of the developers (humans). The fact that many established verification and validation methods are only applicable partially due to the lack of a real specification and the non-interpretability of ML-based solutions further complicates the situation. ... [more] View project January 2018
Two state-of-the-art languages being used in the field of integrated modeling and management of systems are OMG Systems Modeling Language (SysML) and Object-Process Methodology (OPM). SysML is based on UML 2, a de-facto standard in software engineering. OPM is chartered as ISO/PAS 19450 for system and process modeling. Aspects of these two diverse modeling methodologies have been comparatively
... [Show full abstract] analyzed and examined. This paper points to yet another approach that takes a methodology oriented to flow of things to provide an underlying conceptual model on which to construct a fundamental representation of the information or physical system. Adopting a similar analysis technique of comparing SysML and OPM, we examine features of a flow of things orientation based on a concrete sample problem. To demonstrate the feasibility of this methodology in a real environment, we present a study case of an actual IT department of a government ministry, and the results point to the viability of the approach as a foundation for modeling and management of systems. Read more February 2012
Modelowanie systemów informatycznych w oparciu o język UML znalazło wiele zastosowań i jest obecnie przedmiotem nauczania na kierunkach informatycznych wielu światowych uczelni. UML stał się również inspiracją do opracowania licznych standardów branżowych, przyjmujących postać profili tego języka. Dla analityków, projektantów oraz inżynierów systemów informatycznych najważniejszy jest bez
... [Show full abstract] wątpienia SysML, ułatwiający projektowanie aplikacji technicznych w oparciu o architekturę języka UML.
Choć UML zyskał w ostatnich latach status standardu i stał się narzędziem wykorzystywanym przy tworzeniu wielu projektów informatycznych, jego architektura może stanowić poważne wyzwanie dla użytkowników, a zastosowanie jego profili w projektowaniu aplikacji i systemów może prowadzić do dalszych komplikacji. Nauki języka nie ułatwia również fakt, że podlega on stałej ewolucji, przejawiającej się w licznych udoskonaleniach i rozszerzeniach kolejnych wersji standardu UML. Osoby zainteresowane rozszerzeniem swojej wiedzy na temat UML-a oraz poznaniem bardziej zaawansowanych zagadnień związanych z jego używaniem powinny sięgnąć po książkę "UML 2.x. Ćwiczenia zaawansowane". Znajdą w niej dużo innowacyjnych przykładów zastosowania języka i praktycznych zadań utrwalających wiadomości oraz ułatwiających wdrażanie ich w codzienną praktykę projektowania czy analizowania systemów informatycznych.
Autorzy nie ograniczyli się do najbardziej typowych aplikacji, lecz zaprezentowali sposoby wykorzystania UML-a w bardzo różnych dziedzinach gospodarki elektronicznej, przedstawiając między innymi zagadnienia związane z planowaniem akcji marketingowej, sterowaniem ruchem pojazdów oraz tworzeniem rozmaitych systemów rezerwacyjnych czy serwisów rozliczeniowo-handlowych. Książka jest logiczną kontynuacją cyklu publikacji na temat UML-a i doskonale uzupełnia poprzednie pozycje, umożliwiając poszerzenie wiedzy o wiadomości związane z najnowszymi wersjami języka oraz nowymi obszarami jego używania.
Struktura języków UML i SysML
Zmiany, uaktualnienia oraz profile UML-a
Rodzaje diagramów i ich zastosowania
Praktyczne przykłady wykorzystania diagramów
Zadania do samodzielnego wykonania
Wdrażanie modelowanych systemów i aplikacji View full-text June 2005 · Electronic Systems and Software
Read more Last Updated: 05 Jul 2022
Discover the world's research
Join ResearchGate to find the people and research you need to help your work.