Systemsicherheit von ADAS und hochautomatisiertem Fahren

Transcription

SYSTEMSICHERHEIT VON ADAS UND
HOCHAUTOMATISIERTEM FAHREN
Dr.-Ing. Bernhard Kaiser
Leiter Competence Center Safety & Systems Engineering
Technikforum Funktionale Sicherheit 2014, Braunschweig
10.02.2014 / BK
1
VERTRAULICH
SYSTEMSICHERHEIT VON ADAS UND HOCHAUTOMATISIERTEM FAHREN • 10.02.2014
GLIEDERUNG
• Herausforderungen bei ADAS /
Hochautomatisiertem Fahren
• Sicherheit – mehr als Erfüllung der ISO 26262
• Systems Engineering als gesamtheitlicher
Lösungsansatz
• Adäquate Ansätze für Verifikation und Test von
ADAS
2
Herausforderungen bei ADAS und
hochautomatisiertem Fahren
SYSTEMSICHERHEIT VON ADAS UND
HOCHAUTOMATISIERTEM FAHREN • 10.02.2014
3
VERTRAULICH
INTRODUCTION TO ADAS
Advanced Driver Assistance Systems (ADAS)
Increasing road safety and driver comfort
•
Even in presence of driver failures
Typical Examples:
•
Adaptive Cruise Control (ACC)
•
Automatic Park Assist
•
Lane-keeping Assist
•
Traffic Jam Assist
•
Autonomous Emergency Braking
Characteristics
• Multiple Heterogeneous Sensor Technologies
• Intelligent Fusion Algorithms and Complex Decision Processes
• Complex Human-Machine-Interaction and Operation Scenarios
• Influence on various safety-relevant actuators (steering, braking, powertrain)
… and ADAS are further evolving towards automated driving!
4
VERTRAULICH
INTRODUCTION TO ADAS
Why are ADAS safety critical?
•
ADAS influence steering, braking and acceleration control to
accomplish their function
 Erroneous intervention can be safety critical
•
ADAS react in safety critical situations
 Failure to do so results in loss of safety advantage
Examples of Safety Critical Scenarios:
5
VERTRAULICH
•
Erroneous Emergency Braking intervention of Traffic Jam Assist or
Adaptive Cruise Control (ACC) at full speed
•
Steering Intervention by Park Assist which is erroneously active
•
Omission of braking intervention of Automatic Park Assist despite
pedestrians crossing the street in the proximity of the car
HERAUSFORDERUNGEN BEI ADAS / HOCHAUTOMATISIERTEM FAHREN
Evolution of ADAS Increases Safety Criticality
Lane Departure Warning:
• Yesterday: Information only
• Today: Influence on Steering
Park Assist Systems:
• 1st Generation: Driver Information / Warning
• 2nd Generation: Steering aid (driver controls accelerator and brake)
• 3rd Generation: Assisted Parking (driver supervises)
• 4th Generation: Autonomous Parking (driver not even inside the car)
6
VERTRAULICH
Networked Functions, Complexity, Division of Labor
•
Functions are distributed among many ECUs
•
ECUs host many different functions
•
Functions share same sensors and control same actuators
•
Functions evolve from pre-existing functions  Re-Use!
•
Functions are deployed in variants for different vehicles
•
Complexity of vehicle functions ever increases
•
7
VERTRAULICH
•
No single person can understand all aspects
•
Problems resulting from interaction, unforeseen combinations of situations,
human-machine-interaction etc.
High degree of division of labor (many enterprises involved)
Gefährdungsentstehung: Fokus auf Zusammenwirken
• Hazards entstehen nicht nur durch Fehler in einzelnen Komponenten
• Auf Funktionsebene (OEM) müssen gesamtheitliche Fehler betrachtet werden:
• Auch: Fehler im Zusammenwirken an sich korrekter Komponenten
Hazard
Fehler in
Komponente A
8
VERTRAULICH
Fehler in
Komponente B
Fehler im
Zusammenwirken
CHALLENGES OF ADAS DEVELOPMENT
Fehler im Zusammenwirken: Feature Interaction
Func 1
„Brake“
Feature
Interaction
Func 2
9
ESC
Brake
„Release“
SICHERHEIT – MEHR ALS ERFÜLLUNG DER ISO 26262
Fehler im Zusammenwirken: Synchronsiation
EPS
passive
active
fail
ADAS ECU
passive
active
fail
ESC
passive
active
fail
10
Brake
Sicherheit – mehr als Erfüllung der ISO 26262
SYSTEMSICHERHEIT VON ADAS UND HOCHAUTOMATISIERTEM
FAHREN • 10.02.2014
11
VERTRAULICH
Aspekte der Sicherheit – mehr als ISO 26262
• Produkthaftungsgesetz (ProdHaftG): §3 Fehler
• Ein Produkt hat einen Fehler, wenn es nicht die Sicherheit bietet,
die unter Berücksichtigung aller Umstände, insbesondere
- seiner Darbietung
- des Gebrauchs, mit dem billigerweise gerechnet werden kann,
- des Zeitpunktes, in dem es in den Verkehr gebracht wurde,
berechtigterweise erwartet werden kann.
Die Gesetzgebung bzgl. Sicherheit geht von der Gefährdung
des Menschen aus, nicht Geltungsbereich irgendeiner Norm!
• ISO 26262 „Scope“ (vgl. Einleitungskapitel aller Bände)
26262
• ISO 26262 addresses possible hazards caused by malfunctioning
behaviour of E/E safety-related systems, including interaction of these
systems.
• ISO 26262 does not address the nominal performance of E/E systems
NB: ISO 26262 adressiert jedoch Anforderungs- / Design- /
Validierungs-Fehler („nicht zu Ende gedachte Funktion“)
12
VERTRAULICH
COMPETENCE CENTER SAFETY & SYSTEMS ENGINEERING • DATUM
„Safety Beyond ISO 26262“
Safety according to
ProdHaftG
Functional Safety
(cross-divisional view)
Functional Safety
(according to
ISO 26262 Scope)
26262
13
VERTRAULICH
Adäquanz der ISO 26262 für ADAS
• Mit den derzeitigen Mitteln der ISO 26262 schwierige
Bewertung / Entscheidungsfindung bei
• entgangenem Sicherheitszugewinn
• z.B. System hat nicht gebremst bei Auffahren auf Stau
• Minderung der Unfallschwere durch Assistenzfunktion („Delta Severity“)
• Verbesserung der Beherrschbarkeit („Delta Controllability“)
• abgestuften Rückfallebenen (statt dem sicheren Zustand)
• Relevant bei Fail Operational Systemen (z.B. teil-autonomes Fahren bei
höheren Geschwindigkeiten)
• Trade-Offs zwischen Sicherheitszielen
• „Pest oder Cholera?“
• Fehlern / Missverständnis des Fahrers in der Interaktion mit dem System
• Im Bahnbereich hat Lokführer „SIL2“ ?!?
14
VERTRAULICH
COMPETENCE CENTER SAFETY & SYSTEMS ENGINEERING • DATUM
Quantifizierung der Sicherheitsvorgaben
• Quantitative Abschätzung des Rest-Risikos gefordert bei höherem ASIL
• Probabilistische Vorgaben macht die ISO 26262 nur für HW-Ausfälle
• Bei HW: Tolerable Wahrscheinlichkeit der Sicherheitszielverletzung
• 10 -7 / h bei ASIL (B)/C bzw.10 -8 / h bei ASIL D
• Manche Sensoren / Sensorfusionsalgorithmen entscheiden (im
fehlerfreien Fall!) nur richtig mit Wahrscheinlichkeiten um:
• 95% bei kamerabasierten Systemen (aktueller Fusionsalgorithmus)
• tw. deutlich darunter (situationsabhängig)
• Die Erkennungsgüte hängt u. a. von Wetter, Sensor-Verschmutzung und Oberfläche des
zu erkennenden Objekts ab
HW-Fehler und Unzulänglichkeit der Sensorik können die selbe Gefährdung
verursachen! Woher kommen die Vorgaben an Entwicklung und Test?
15
VERTRAULICH
Funktionsorientierter Entwicklungsprozess für ADAS
ISO 26262 steht
Funktionsorientierter
Entwicklung nicht entgegen
– aber Interpretationsbedarf!
Idee
Fkt. 1
Fkt. 2
Req
Fkt. 3
Req
Req
P
x
x
P
Vehicle Test
P
x
x
P
Function 1 Function 2 Function 3
Test
Test
Test
(u.a. Teilung der Verantwortung,
Sicherheitsnachweis, Re-Use
bestehender Komponenten)
System Architecture
P
x
x
P
P
x
x
P
B
A
D
C
System Integration
A
Components
C
B
D
P
x
x
P
Test
Comp.
A
OEM
P
x
x
P
P
x
x
P
P
x
x
P
OEM
Lieferant
Test
Test
Test
Comp. Comp. Comp.
B
C
D
Lieferant
Supplier Process: Design and Implementation
16
VERTRAULICH
Arbeitsteilung und Verantwortung bei ADAS
Bsp. Verantwortlichkeits- und Nachweisproblematik
• Lieferant X verantwortet Ultraschallsensoren
• Lieferant Y verantwortet Kamera und Fusionsalgorithmus
• OEM verantwortet Fahrzeugsicherheit
• Lieferant X analysiert Fehlermodes seines Sensors...
Fehler
Maßnahme
Zuständig
Leitungsabriss
Range Check
Lieferant X
De-Justage
Math. Modell im
Fusionsalgorithmus
Lieferant Y
Wie weist OEM nach, dass alles abgedeckt ist? „Safety Case“ der ISO 26262
zu wenig formalisiert für Gewissheit im Haftungsfall!
17
VERTRAULICH
Systems Engineering als gesamtheitlicher
Lösungsansatz
FAHREN • 10.02.2014
18
VERTRAULICH
SYSTEMS ENGINEERING ALS GESAMTHEITLICHER LÖSUNGSANSATZ
Was ist Systems Engineering?
• Methodisches ingenieursmäßiges Vorgehen bei der Entwicklung
hochkomplexer Systeme
• Ursprünge: Telefon-Netze, Raumfahrtprogramme, Avionik
• Top-Down-Ansatz (definierte Einbeziehung bewährter Lösungen)
• Fokus auf interdisziplinärer Zusammenarbeit im Team
• Ziel: gesamtheitliches Systemverständnis
• insbes. bzgl. der „systemischen“ Eigenschaften wie Sicherheit,
Zuverlässigkeit, Bedienbarkeit, Performanz, Kosten…
• Starker Einsatz von Modellen zu
• Verständnisbildung und Spezifikation
• Simulation und Analyse relevanter System-Eigenschaften
• Validierung der Eignung des Systems für seinen Einsatzzweck
19
VERTRAULICH
SYSTEMS ENGINEERING ALS GESAMTHEITLICHER LÖSUNGSANSATZ
Was trägt Systems Engineering zur Lösung bei?
• Strukturierte Prozesse mit Integration aller Beteiligten und Disziplinen
• Durch Baukasten mit definierten Schnittstellen herstellerübergreifende Zusammenarbeit
• Ganzheitliche Sicht  Safety integraler Prozessbestandteil
• Schrittweise Ableitung von Anforderungen und Eigenschaften
• Transformation von Eigenschaften (Safety des Systems  Performanz eines Subsystems)
• Ableitung quantitativer Vorgaben durch Modelle und Berechnungen
• Begründete Designentscheidungen mit Dokumentation der Annahmen
• Designentscheidung für sichere Lösung unter Randbedingungen (Kosten, Verfügbarkeit,…)
• Bei Re-Use und Variantenbildung leichterer Nachweis der Sicherheit
• Frühe modellbasierte Validation mit Blick auf das Gesamtsystemverhalten
• „Das ganze ist mehr als die Summe seiner Teile“  Fokus auf Modellierung von
Wechselwirkungen zwischen Systemteilen beim Gesamtsystemverhalten
20
VERTRAULICH
SYSTEMS ENGINEERING: PROZESSINTEGRATION
Integration Safety vs Funktionsorientierte Entwicklung
Idee
P
x
x
P
Vehicle Test
Fkt. 1
Item Definitions
Fkt. 2
Fkt. 3
P
x
x
P
P
x
x
P
HARA
Req
Req
D
C
B
D
A
Components
C
B
P
x
x
P
P
x
x
P
B
A
P
x
x
P
Validation
per Function
System Integration
A
P
x
x
P
Function 1 Function 2 Function 3
Test Safety
Test
Test
Req
System Architecture
Functional
Safety Concepts
F1 F2 F3
P
x
x
P
D
P
x
x
P
C
System
System Safety
Safety
O
Concep
t EM
Concept
Test
Comp.
A
P
x
x
P
P
x
x
P
P
x
x
P
Int. & Testing
acOcE. M
ISO 26262
Lieferant
Test
Test
Test
Comp. Comp. Comp.
B
C
D
Lief eran t
Technical Safety
Concepts
A B C D
21
VERTRAULICH
Supplier Process: Design on Implementation
SYSTEMS ENGINEERING: PROZESSINTEGRATION
Integration Systems Engineering / Functional Safety
• D1: Function Modelling
Idea of Function
• D2: Functional Requirements Definition
• S1: Hazard Analysis
D1
H xx ASIL
H xx ASIL
H xx ASIL
H xx ASIL
Hazard Analysis
• S2: Functional Safety Concept
• S3: Integration of Functional Safety
Requirements
S1
Function Block Model / Use Cases
D2
S2
S2
Functional
Requirements
• D3: Definition of Technical Solution
S3
Functional Safety Concept
• S4: Analysis of Failure Possibilities of
Technical Solution (e.g.. FTA, FMEA)
D3
FTA / FMEA
• S5: Technical Safety Concept
System
Architecture
S5
S5
• D4: Definition of Requirements to Parts
D4
S4
• S6: Integration of Technical Requirements
Legend:
D = Development Activities
S = Safety Activities
22
VERTRAULICH
OEM
S6
Technical Safety Concept
Supplier
Part A
Req
Part B
Req
Part C
Req
SYSTEMS ENGINEERING: SYSTEMATISCHE ABLEITUNG
Strukturiertes Modell – Ableitung von Anforderungen
ISP, Preprocessing
Element
Level
Steering
Controller
Data Reduction,
Signal Processing
Steering
Sensor Evaluation Level
Sensor Type 1
(camera)
Sensor Fusion,
Interpretation
Sensor Type 2
(ultrasonic)
Braking
Controller
Brake
ADC, Signal
Conditioning
Data Reduction,
Signal Processing
Sensor Fusion Level
23
Evaluation, Decision
VERTRAULICH
Engine
Controller
Core Function Level
Engine
Vehicle Level
Element
Level
ISP, Preprocessing
Steering
Controller
Data Reduction,
Signal Processing
Steering
Sensor Type 1
(camera)
Sensor Fusion,
Interpretation
Sensor Type 2
(ultrasonic)
Evaluation, Decision
Braking
Controller
Brake
ADC, Signal
Conditioning
Data Reduction,
Signal Processing
Sensor Fusion Level
Engine
Controller
Core Function Level
System Architecture Hierarchy
Engine
Vehicle Level
Vehicle Level
Core Function Level
...
Sensor Fusion Level
...
Scopes of Requirements and
Safety Statements
24
VERTRAULICH
Element Level
Func Req
Safety Req
Vehicle Level
ASIL x
Safety Requirement:
Prevent pedestrian collision
Func Req
Perf Req
Safety Req
Func Req
Perf Req
Safety Req
Core Function Level
ASIL y *)
Functional Requirement:
Func Req
Perf Req
Safety Req
Func Req
Perf Req
Safety Req
Func Req
Perf Req
Safety Req
...
Reliable pedestrian detection
Sensor Fusion Level
ASIL z *)
...
Func Req
Perf Req
Safety Req
Func Req
Perf Req
Safety Req
Func Req
Perf Req
Safety Req
Func Req
Perf Req
Safety Req
Performance Requirements:
• Accuracy
Sensor Evaluation
Level
•
of detection
Surface of material
Safety Requirement:
Func Req
Perf Req
Func Req
Perf Req
Func Req
Perf Req
Func Req
Perf Req
Func Req
Perf Req
•
Diagnostic Check of HW
Element Level
25
*) = applies to process quality to be assured
25
VERTRAULICH
SYSTEMS ENGINEERING: DOKUMENTIERTE ENTWURFSENTSCHEIDUNGEN
Design Decisions: Topology of an ADAS System
•
Camera
Steering ECU
Steering
ADAS ECU
Radar
Lidar
Ultrasonic
Transversal
control
Sensor
Fusion
Decision
maker
Engine ECU
Engine
Braking ECU
Brake
Longitudinal
control
Ego-velocity
26
VERTRAULICH
Variant 1: Centralized Implementation of Safety Features
Camera
Steering ECU
Steering
ADAS ECU
Lidar
Transversal
control
Sensor
Fusion
Decision
maker
Longitudinal
control
Ultrasonic
Safety
Decision
Ego-velocity
27
VERTRAULICH
Actuator Guardian
ASIL
Radar
Engine ECU
Engine
Braking ECU
Brake
Priority
ASIL
Variant 2: Redundancy of critical functions
•
Camera
Steering ECU
Steering
ADAS ECU
Radar
Lidar
Transversal
control
Sensor
Fusion
Decision
maker
Longitudinal
control
Ultrasonic
Safety
Fusion
Safety
Decision
Actuator Guardian
Processor Core 1
Engine ECU
Engine
Braking ECU
Brake
Priority
Ego-velocity
Processor Core 2
28
VERTRAULICH
Variant 3: Decentralized Guards for Safety Conditions
Camera
Steering ECU
ADAS ECU
Safety
Guardian
Radar
Lidar
Ultrasonic
Steering
Transversal
control
Sensor
Fusion
Engine ECU
Decision
maker
Engine
Safety
Guardian
Longitudinal
control
Braking ECU
Brake
Safety
Guardian
Ego-velocity
29
VERTRAULICH
Variant 4: Partially Fail Operational
Prediction
Camera
Steering ECU
ADAS ECU
Emergency
operation
Radar
Lidar
Ultrasonic
Steering
Transversal
control
Sensor
Fusion
Engine ECU
Decision
maker
Engine
Emergency
Cut-Off
Longitudinal
control
Braking ECU
Brake
Emergency
Decelerati
on
Ego-velocity
30
VERTRAULICH
SYSTEMS ENGINEERING: FRÜHE VALIDIERUNG DURCH MODELLEINSATZ
Frühere (Safety-)Validierung durch Modelleinsatz
Safety Validation acc.
ISO 262626-4
31
VERTRAULICH
Dynamisches Verhalten und Zusammenwirken
ibd [SysML Internal Block] Position Ctrl [1]
ECU
Position Reference
CAN
sd [Sequence] Position
[1]
IgnitionCtrl
Status
Phase Current U
Actuator
Range Check
Phase Current V
CAN
Position Sensor
Position Sensor
ECU-SW
Phase Current W
(Position Control)
PWM Driver
min Voltage
max Voltage
Motor Position
[error detected]
get Position Reference()
Offset Compensation
12 V Logic Power
Power Supply
Voltage Offset
12V High Power
get Motor Position()
Plausibility Check
redundant
Voltage Value
Motor Speed Calculation()
Flt qualified
FLT_DIAG
Motor Speed Control()
[error detected]
set PWM U()
Motor Speed Calculation
set PWM V()
Motor
PositionValue
Motor Speed
100ms
500ms
32
VERTRAULICH
Motor
Speed
Max allowed
Last Motor
Speed for Fnct
Position Value
set PWM W()
Create Error Entry
Hazard
Threshold
Standstill Limit
33
VERTRAULICH
Verfeinerung zum Simulationsmodell  Validierung
ECU
Position Reference
CAN
Ignition Status
Phase Current U
Actuator
Phase Current V
Phase Current W
Position Sensor
Motor Position
12 V Logic Power
Power Supply
12V High Power
34
VERTRAULICH
35
VERTRAULICH
Adäquate Ansätze für Verifikation und Test von ADAS
FAHREN • 10.02.2014
36
VERTRAULICH
ADÄQUATE ANSÄTZE FÜR VERIFIKATION UND TEST VON ADAS
Ableiten und Verifizieren Quantitativer Anforderungen
• Sensorik/Sensorfusion in Verbindung mit variablen UmgebungsSzenarien nicht deterministisch, sondern probabilistisch
1. Teilproblem: Zielwerte auf Gesamt-Funktionsebene
• Mögliche Quellen: Unfallstatistiken, Stand der Technik
• GAMAB-Prinzip: mit neuer Technik nicht mehr Unfälle als mit vorheeriger
(Juristisch keine Garantie für Haftungsfreiheit im Falle eines Unfalls!)
2. Teilproblem: Herunterbrechen von Test-Kriterien auf
Fahrzeugebene zu Zielwerten auf Subsystem-Ebene
• Z.B. Sensor, Auswertung & Plausibilisierung, Fusion, Entscheidung
3. Teilproblem: Verifikation durch Tests / Simulation
• Statistische Konfidenz: Wieviele km muss man fahren, ohne dass etwas
passiert?  Formeln grundsätzlich bekannt!
• Machbarkeit: Bei sehr niedrigen Fehlerwahrscheinlichkeiten kann man
nicht genug testen / alle praxisrelevanten Situationen erreicht man nicht 
Simulation mit statistischer Variantenbildung, Evolutionärer Test
37
VERTRAULICH
ENGINEERING SOLUTIONS
AND PRODUCTS FOR AUTOMOTIVE
ELECTRONICS & SOFTWARE & MECHANICS
38
VERTRAULICH

Systemsicherheit von ADAS und hochautomatisiertem Fahren

Transcription

Similar documents

Effektivität und Effizienz der CT- Koloskopie im Vergleich zur

Umweltbrief Dezember 2008

Full List of Publications - Institut für Leichtbau und Struktur

Promotionsprojekte an der HCU

UR_05_Aldisert1985_Grenzlinien - Pressestelle der Universität

Sensorfusion zur Navigation eines Fahrzeugs mit low

Paper - bei FZD