View
1
Download
0
Category
Preview:
Citation preview
2012 TÜV NORD Systems GmbH & Co. KG 1 Gerhard M. Rieger
Produktentwicklung Hardware Teil 5 der ISO 26262
+49.821.450954-4280
+49.821.450954-4269
http://www.tuev-nord.de
grieger@tuev-nord.de
Gerhard Rieger
Branch Manager
______________________________
TÜV NORD Systems GmbH & Co. KG
Functional Safety
Halderstr. 27
D-86150 Augsburg
2012 TÜV NORD Systems GmbH & Co. KG 2 Gerhard M. Rieger
5-5 Initialisierung der
Produktentwicklung auf HW-Ebene [1]
2012 TÜV NORD Systems GmbH & Co. KG 3 Gerhard M. Rieger
Zielsetzung
Das Ziel ist es die Tätigkeiten zur Einhaltung der
funktionalen Sicherheit während der Phasen der HW
Entwicklung. Dies beinhaltet auch die Hilfsprozesse
entsprechend ISO 26262-8.
Die Planung der HW-spezifischen Tätigkeiten ist im
Safety Plan enthalten.
Work-Products
• Gesamtprojektplan
• Safety Plan
5-5 Initialisierung der
Produktentwicklung auf HW-Ebene [2]
2012 TÜV NORD Systems GmbH & Co. KG 4 Gerhard M. Rieger
Integration (HW und SW)
programmierbarer
Elektronik
Software
Sicherheits-
anforderungen
Software
Design und
Entwicklung
Sicherheits-
anforderungs-
spezifikation
Hardware
programmier- barer
Elektronik
Nicht
programmierbare
Hardware
Hardware Sicherheitsanforderungen
Design und
Entwicklung von
programmier- barer
Elektronik
System
Architektur
System
Integration
Design und
Entwicklung von
nicht-
programmierbarer
Hardware
Die Integration der folgenden
Tätigkeiten ist erforderlich für
die Produkt-entwicklung auf
HW-Ebene:
• Hardware Umsetzung des technischen Sicherheits-
konzepts
• Analyse von potentiellen Fehlern und deren
Auswirkung und
• Koordination mit der Software Entwicklung
5-5 Initialisierung der
Produktentwicklung auf HW-Ebene [3]
2012 TÜV NORD Systems GmbH & Co. KG 5 Gerhard M. Rieger
5-6 Spezifikation der HW
Sicherheitsanforderungen [1]
Zielsetzung
Das erste Ziel ist es eine konsistente und vollständige HW
Spezifikation zu erstellen, die auf die HW des betrachteten
Items oder Elements angewandt wird. Die Anforderungen dieser
Spezifikation sind HW Sicherheitsanforderungen.
Das zweite Ziel ist es zu verifizieren, dass die HW Sicherheits-
anforderungen mit dem technischen Konzept übereinstimmen.
Ein weiteres Ziel ist es die HW-SW Schnittstellenanforderungen
zu detaillieren, die in ISO 26262-4 Absatz 7 initialisiert wurden.
Work-Products
• HW Sicherheitsanforderungsspezifikation
• Anforderungen an die HW Architektur Metrik
• Anforderungen an die zufälligen Fehler
• HW-SW-Schnittstellenspezifikation (überarbeitet)
• Verifizierungsbericht der HW Sicherheitsanforderungen
2012 TÜV NORD Systems GmbH & Co. KG 6 Gerhard M. Rieger
Die HW Sicherheitsanforderung soll jede HW Anforderung enthalten, die die Sicherheit betrifft, inklusive:
a) Die HW Sicherheitsanforderungen an Sicherheits-
mechanismen zur Überwachung interner Fehler der HW des
Elements mit den relevanten Eigenschaften.
b) Die HW Sicherheitsanforderungen an Sicherheits-
mechanismen, die das betrachtete Element vor externen
Einflüssen/Fehlern sichern soll mit den relevanten
Eigenschaften
c) Die HW Sicherheitsanforderungen an Sicherheits-
mechanismen, die im Einklang mit den Sicherheits-
anforderungen anderer Elemente (z.B. Sensoren) zu
bringen sind.
d) Die HW Sicherheitsanforderungen an Sicherheits-
mechanismen zur Entdeckung und Signalisierung von
internen und externen Fehlern.
5-6 Spezifikation der HW
Sicherheitsanforderungen [2]
2012 TÜV NORD Systems GmbH & Co. KG 7 Gerhard M. Rieger
5-7 HW Design [1]
Zielsetzung
Das erste Ziel ist es die HW auf Basis der Systemdesign-
spezifikation und der HW Sicherheitsanforderungen zu
entwerfen.
Das zweite Ziel ist es das HW Design gegen die
Systemdesignspezifikation und die HW
Sicherheitsanforderungen zu verifizieren.
Work-Products
• HW Designspezifikation
• Bericht zur Analyse der HW-Sicherheit
• Verifizierungsbericht des HW Design
• Anforderungen an Produktion und Betrieb
2012 TÜV NORD Systems GmbH & Co. KG 8 Gerhard M. Rieger
Eingangs-
schaltung
Ausgangs-
schaltung CPU
Zentraler
Schaltungsteil
Sensor
Aktuator
Eingangs-
schaltung
Ausgangs-
schaltung
CPU
Zentraler
Schaltungsteil
Sensor
Eingangs-
schaltung
Ausgangs-
schaltung CPU
Zentraler
Schaltungsteil Aktuato
r
Eingangs-
schaltung
Ausgangs-
schaltung CPU
Zentraler
Schaltungsteil
Sensor
Aktuator
Diagnose-Schaltung
Einkanalige Systeme
Mehrkanalige Systeme
Systeme mit
Diagnoseeinheit
5-7 HW Design [2]
2012 TÜV NORD Systems GmbH & Co. KG 9 Gerhard M. Rieger
Um ein angemessenes Level an Granularität zu erreichen und um Fehler
aufgrund von hoher Komplexität zu vermeiden, sollten folgende modulare
Designeigenschaften betrachtet werden:
1) Hierarchisches Design;
2) Genau definierte Schnittstellen von sicherheitsrelevanten HW Komponenten;
3) Vermeidung von unnötiger Komplexität der Schnittstellen;
4) Vermeidung von unnötiger Komplexität der HW Komponenten;
5) Wartbarkeit (Service);
6) Testbarkeit.
5-7 HW Design [3]
2012 TÜV NORD Systems GmbH & Co. KG 10 Gerhard M. Rieger
Sicherheitsanalyse:
Sicherheitsanalysen der HW Architektur und des detaillierten
Design zur Entdeckung von Auswirkungen und Ursachen von
Fehlern sollen entsprechend folgender Tabelle angewandt werden.
ISO 26262-5 Tabelle 2 — Hardware Design Sicherheitsanalyse:
Methoden ASIL
A B C D
1 Deduktive Analysea o + ++ ++
2 Induktive Analyseb ++ ++ ++ ++
++ stark empfohlen für den jeweiligen ASIL
+ empfohlen für den jeweiligen ASIL
a. Deduktive Analyse (FTA, reliability block diagrams)
b. Induktive Analyse (FMEA, ETA, Markov Modele)
5-7 HW Design [4]
2012 TÜV NORD Systems GmbH & Co. KG 11 Gerhard M. Rieger
Bestimmen der Restfehlerwahrscheinlichkeit in Bezug auf zufällige
Hardwarefehler „Probabilistic Metric for random Hardware Failures”
(PMHF). Ein geeignete Methode um den PMHF zu ermitteln ist z.B. die
FTA. Folgende Parameter müssen bei der Analyse beachtet werden:
• alle gefährlichen Einzelfehler (single-point fault or a residual fault)
• Der Diagnoseaufdeckungsgrad für Hardwarefehler
• alle Fehler die nur in Kombination mit anderen gefährlich werden und
unentdeckt im System verbleiben (dual-point fault)
• Die Zeit die Fehler latent im System verbeiben können ohne entdeckt
zu werden.
Die zweite Methode ist die „cut-set analysis“. Bei dieser Methode wird
jeder Hardwarefehler für sich betrachtet und darf eine bestimmte
Ausfallrate (Failure rate class) nicht überschreiten.
Um zu bestimmen ob das Sicherheitsziel durch zufällige Hardwarefehler
gefährdet ist gibt der Standard zwei alternative Methoden vor:
5-8 HW Metriken [1]
2012 TÜV NORD Systems GmbH & Co. KG 12 Gerhard M. Rieger
Ermittlung jeder verbleibenden Ursache der Verletzung eines Sicherheitsziels:
Die Ermittlung ob ein Sicherheitsziel aufgrund von zufälligen HW Fehlern verletzt wurde ist in folgendem
Flussdiagramm dargestellt. Jeder Single Point Fehler wird untersucht nach Kriterien des Auftretens. Jeder Residual
Fehler wird untersucht nach Kriterien des Auftretens und der Effizienz des Sicherheitsmechanismus.
5-8 HW Metriken [2]
2012 TÜV NORD Systems GmbH & Co. KG 13 Gerhard M. Rieger
Tabelle 7: Max. erlaubte Fehlerraten bei Verletzung des Sicherheitsziels aufgrund unerkannter Einfachfehler
Failure class 1: 0,1FIT
Failure class 2: 1 FIT
Failure class 3: 10 FIT
Failure class 4: 100 FIT
Failure class 5: 1000 FIT
•HW-Anforderungen: Absatz 9.4.2.4
•Sample Test
•Burn-In Test
•Überdimensionierung
•Implementierung von sicherheitsrelevanten
Charakteristiken
5-8 HW Metriken [3]
2012 TÜV NORD Systems GmbH & Co. KG 14 Gerhard M. Rieger
Tabelle 8: Max. erlaubte Fehlerraten bei Verletzung des Sicherheitsziels aufgrund residual faults
Failure class 1: 0,1FIT
Failure class 2: 1 FIT
Failure class 3: 10 FIT
Failure class 4: 100 FIT
Failure class 5: 1000 FIT
5-8 HW Metriken [4]
2012 TÜV NORD Systems GmbH & Co. KG 15 Gerhard M. Rieger
Jeder Dual Point Fehler wird
zuerst auf Plausibilität
überprüft. Dieser ist nicht
plausibel, wenn beide Fehler in
einer angemessenen Zeit und
mit einer entsprechenden
Aufdeckung entdeckt oder
erkannt werden
Wenn der Dual Point Fehler
plausibel ist müssen die
Anforderungen entsprechend
ISO 26262-5, Tabelle 6 erfüllt
sein.
5-8 HW Metriken [5]
2012 TÜV NORD Systems GmbH & Co. KG 16 Gerhard M. Rieger
Tabelle 9: Max. erlaubte Fehlerraten bei Verletzung des Sicherheitsziels aufgrund dual-point faults
Failure class 1: 0,1FIT
Failure class 2: 1 FIT
Failure class 3: 10 FIT
Failure class 4: 100 FIT
Failure class 5: 1000 FIT
5-8 HW Metriken [6]
2012 TÜV NORD Systems GmbH & Co. KG 17 Gerhard M. Rieger
Definiere für jedes Sicherheitsziel numerische Zielwerte für Single Point Fehler
Metrik (SPFM) und Latent Fehler Metrik (LFM)
Single Point Fehler Metrik und Latent Fehler Metrik Zielwerte
Failure Mode Effect Diagnostic Analysis (FMEDA)
Bestimmung der SPFM und LFM
ASIL B ASIL C ASIL D
Single Point
Fehler Metrik
>90 % >97% >99%
Latent Fehler
Metrik
>60% >80% >90%
5-8 HW Metriken [7]
2012 TÜV NORD Systems GmbH & Co. KG 18 Gerhard M. Rieger
Fehlerarten eines HW Element
Sicherheitsrelevantes
HW Element
Nicht-
Sicherheitsrelevantes
HW Element
Sicherer
Fehler Sicherer
Fehler
Entdeckter
Multiple
Point Fehler
Erkannter
Multiple
Point
Fehler
Latenter
Multiple
Point
Fehler
Single Point
Fehler/
Residual
Fehler
5-8 HW Metriken [8]
2012 TÜV NORD Systems GmbH & Co. KG 19 Gerhard M. Rieger
Aufteilung der Fehlerraten
nein
ja
5-8 HW Metriken [9]
2012 TÜV NORD Systems GmbH & Co. KG 20 Gerhard M. Rieger
Bestimmung des Wertes der Single Point Faults Metric - SPFM
Prozentualer Anteil der gefahrbringenden Einfachfehler (SPF) und Restfehlern
(RF), die nicht von den implementierten Sicherheitsmechanismen erkannt
werden.
oder
das Komplement des Prozentualer Anteil der erkannten und unerkannten
sicheren und gefahrbringenden Mehrfachfehler
5-8 HW Metriken [10]
2012 TÜV NORD Systems GmbH & Co. KG 21 Gerhard M. Rieger
Bestimmung des Wertes der Latent Faults Metric
Prozentualer Anteil von sicheren erkannten Mehrfachfehlern die durch
Sicherheitsmechanismen oder durch den Fahrer erkannt werden.
oder
Das Komplement des prozentualen Anteils von schlafenden
Mehrfachfehlern, die nicht durch die implementierten
Sicherheitsmaßnahmen entdeckt werden.
Nur die sicherheitsrelevanten HW-Komponenten werden betrachtet
5-8 HW Metriken [11]
2012 TÜV NORD Systems GmbH & Co. KG 22 Gerhard M. Rieger
Grenzwerte der Metriken in Bezug auf den zu erreichenden ASIL
ASIL B ASIL C ASIL D
Single point
faults metric
>90 % >97% >99%
Latent faults
metric
>60% >80% >90%
5-9 Ermittlung ob ein Sicherheitsziel aufgrund von zufälligen
HW Fehlern verletzt wurde [1]
2012 TÜV NORD Systems GmbH & Co. KG 23 Gerhard M. Rieger
Grenzwerte (PMHF) der zulässigen Ausfallraten der
Sicherheitsfunktion in Bezug auf den zu erreichenden ASIL
ASIL Zulässiger Grenzwert der HW-Ausfallrate
D < 10-8/h (Gefordert)
C < 10-7/h (Gefordert)
B < 10-7/h (Empfohlen)
A - keine Anforderungen -
5-9 Ermittlung ob ein Sicherheitsziel aufgrund von zufälligen
HW Fehlern verletzt wurde [2]
2012 TÜV NORD Systems GmbH & Co. KG 24 Gerhard M. Rieger
Single Point Fault Metric
(SPFM)
Permanent fault
Transient fault
-
nur CPU und
Speicher!
Latent Failure Metric (LFM)
Probabilistic Metric for random Hardware Failures
(PMHF)
Betrachtung der
Hardware- Architecktur
Alle single-point faults ,
residual faults and
latent multiple
faults
Die Erkennungs-zeit latenter
Fehler
Welche Werte müssen nach 26262 bestimmt werden?
22/03/201
2
TÜV NORD Systems - FMEDA Workshop
24
5-9 Ermittlung ob ein Sicherheitsziel aufgrund von zufälligen
HW Fehlern verletzt wurde [3]
2012 TÜV NORD Systems GmbH & Co. KG 25 Gerhard M. Rieger
Schaltungsbeispiel [1]
RAM ROM
CPU Core
System Register + SP
Instruction Queue
ALU + Multiplier
Interrupt-‚Vectoren
Program Counter
Timer
I/O PortsBUS
Interface
ADC
CPU 2
Logic SolverInput Circuit Output Circuit
Optokoppler
1
Sensor 7
Busanbindung
11
Watch
dog
6Abschaltpfad
Relais 4
Relais 5
Treiber 3
LED 8
R7
R9
Recommended