Funktionale Sicherheit in der Praxis · 2018-05-24 · Beispiel: SIL 4 Wahrscheinlichkeit eines...

Stand: 13-02-05 20:12

Funktionale Sicherheit

in der Praxis

Referent: Thomas Haller

www.newtec.deSeite 2

Das entspricht ca. 167.000.000 fit



Was alles passieren kann wenn …


Wenn die Technik versagt

Apollo 13 Ariane 5 Challenger

Tschernobyl AirFrance Flug AF 447


Ursprung der funktionalen Sicherheit

• Chemieunfall in Seveso, Italien 1976: Hochgiftiges Dioxin trat aus, mit

katastrophalen Folgen für Menschen, Tierwelt und Natur

• Unkontrollierte Reaktion führte zur Überhitzung

• Automatische Kühlsysteme und Warnanlagen waren nicht vorhanden

• Als Folge dieses Unfalls wurde die Verschärfung der Gesetze und Verordnung

zum Schutz von Menschen, Lebewesen und Umwelt beschlossen

• IEC 61508 (allgemein) – 1998/2000



Einführung


Definition

Funktionale Sicherheit ist die Fähigkeit eines elektrischen, elektronischen bzw.

programmierbar elektronischen Systems (E/E/PE-System)

… bei Auftreten zufälliger und/oder systematischer Ausfälle mit gefahrbringender Wirkung im sicheren Zustand zu bleiben bzw. einen sicheren Zustand einzunehmen…

Spannungsfeld

Sicheres System �� Entwicklungsaufwand


„Ausführen“„Reagieren“„Erkennen“

Was ist ein System?

Sensor Steuergerät (HW/SW) Aktor

Messen Regeln Steuern



Begriffsdefinitionen


Definition „funktionale Sicherheit“

Funktionale Sicherheit bezeichnet den Teil der Sicherheit eines Systems, der von der korrekten Funktion der sicherheitsbezogenen (Sub-)Systeme und externer Einrichtungen zur Risikominderung abhängt. Nicht zur funktionalen Sicherheit gehören u. a. elektrische Sicherheit, Brandschutz, Strahlenschutz. Da Sicherheit auch erreicht werden kann, indem notfalls die bestimmungsgemäße Funktion eingestellt und ein sicherer Zustand eingenommen wird, spricht man auch von der Sicherheitsintegrität des Systems.

Mit der Komplexität elektronischer, insbesondere programmierbarer Systeme steigt auch die Vielfalt der Fehlermöglichkeiten. Entsprechend fordert die Normenreihe IEC 61508 Funktionale

Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbar elektronischer

Systeme die Anwendung diverser Methoden zur Vermeidung systematischer Fehler (das sind Fehler bei der Spezifikation, Implementierung etc. des Systems) und zur sicheren Beherrschung von Ausfällen und Störungen (oft durch physikalische Phänomene oder Bedienungsfehler). Eine Anpassung dieser Normenreihe für Kraftfahrzeuge ist die ISO-Norm 26262

Sicherheit ist die Abwesenheit von Gefahr


Abgrenzung „funktionale Sicherheit“

Wird ein Navigationsgerät bei einem Unfall durch den Fahrgastraum geschleudert, ist dies ein Sicherheitsproblem.

Löst ein Navigationssystem zusammen mit einem Fahrassistenz-system durch eine Fehlfunktion jedoch eine kritische Situation aus, ist dies ein Problem der funktionalen Sicherheit.



Produkthaftungsgesetz


Definition „Produkthaftung“

Die Produkthaftung bezeichnet die Haftung auf Schadensersatz gegen den Hersteller für Schäden, die beim Endabnehmer infolge eines fehlerhaften Produkts entstanden sind. Sie ist in den §§ 1 bis 19 des Produkthaftungsgesetzes (ProdHaftG) geregelt und von der verschuldensabhängigen „Produzentenhaftung“ nach § 823 BGB zu unterscheiden.

Die Produkthaftung setzt weder einen Vertrag zwischen dem Hersteller und dem Endverbraucher voraus, noch ist ein Verschulden für die Haftung des Herstellers erforderlich. Vielmehr soll der Endabnehmer vor bestimmten von einem fehlerhaften Produkt ausgehenden Gefahren unabhängig von einem Verschulden des Herstellers geschützt werden, auch wenn sich erst nach Inverkehrbringen des Produkts gezeigt haben. Es handelt sich also um eine reine Gefährdungshaftung. Mangels Vertrags oder Kontakt zwischen Hersteller und Endabnehmer, der das Produkt in der Regel bei einem Zwischenhändler erworben hat, scheiden Ansprüche aus Gewährleistung, Positiver Vertragsverletzung (pVV) und der culpa in

contrahendo („cic“, Verschulden vor Vertragsabschluss) aus. Auch ein Vertrag zugunsten Dritter kommt regelmäßig nicht in Betracht, da der Endabnehmer dem Hersteller und den Zwischenhändlern noch nicht bekannt ist und daher in dem zwischen ihnen geschlossenen Vertrag nicht einbezogen ist.


Geltungsbereich funktionale

Sicherheit

NormenDIN ENISO, IEC

Anwendungsbereichsicherheitsbezogene elektronische

Systeme

Motivation• Produkthaftungsgesetz• Imageschaden vorbeugen• Nachfrage nach sicheren Produkten

ZielsetzungGefahren für Mensch und Umwelt

abwenden

Wann?Produktlebenszyklus

(Produktidee bis Außerbetriebnahme)

Methodik• Gefahren- u. Risikoanalyse• Fehleranalyse (FMEA)• sichere Produktentwicklung und Herstellung nach anerkannten Praktiken

StrategieFehlervermeidung und Fehlerbeherrschung

VoraussetzungQM-System

Safety ManagementMehrkosten durch Prozesse (~ 50%)


Normen und deren Nichtbeachtung

Die Normen zur funktionalen Sicherheit gelten ab deren offiziellen Release. Sie gelten für alle, ab ihrer Veröffentlichung verkauften, Produkte.

Die Anwendung der Normen zur funktionalen Sicherheit ist stets freiwillig.

Tritt ein Fehler oder gar ein Unfall auf, wird jedoch die Einhaltung der Normen bei der Entwicklung des Systems geprüft, da es sich um den „aktuellen Stand der Technik“ handelt.

Wurden die Normen verletzt oder nicht beachtet, drohen empfindliche zivil- und strafrechtliche Folgen. Es kann als grob fahrlässige Handlung oder Vorsatz gewertet werden. Daraus ergeben sich erhöhte Schadensersatzansprüche, persönliche Haftung sowie höhere Versicherungs-prämien zur Risiko Absicherung. Managerhaftpflichtversicherungen schützen nicht!

Eine Zertifizierung nach Normen der funktionalen Sicherheit dagegen befreit nicht von der Produkthaftung, sie mindert jedoch die einstehenden Ansprüche im Falle des Versagens des Systems.

Die Zertifizierungsstellen übernehmen keinerlei Haftung.



Welche Normen (Organisationen) gibt es und wo sind sie relevant


Welche Normen gibt es wofür


Kritikalitätslevels:

SIL LevelDAL LevelASIL Level

SILCL Level


Sicherheits-Integritätslevel SIL

IEC 61508

Sehr bedeutende Folge für die Gemeinschaft

Geringe Folge für die Gemeinschaft

Fehlerkategorie SIL Wahrscheinlichkeit eines gefährlichen

Ausfalls pro Stunde

„catastrophic“ 4 10-9 ≤ P < 10-8

„hazardous /severe-major“ 3 10-8 ≤ P < 10-7

„major“ 2 10-7 ≤ P < 10-6

„minor“ 1 10-6 ≤ P < 10-5

Beispiel: SIL 4

Wahrscheinlichkeit eines gefahrbringenden Ausfalls pro Stunde < 10-8

oder 1 gefahrbringender Ausfall in > 10 8 Stunden

1 : 100.000.000

Höh

ere

Sich

erhe

it


Kritikalitätslevel DAL

DO 178B



Höh

ere

Sich

erhe

it

Fehlerkategorie DAL Safety Objective Requirement

(Ausfallrate (P) pro Flugstunde)

„catastrophic“ A P < 10-9

„hazardous /severe-major“ B P < 10-7

„major“ C P < 10-5

„minor“ D Not relevant

„no safety effect“ E Not relevant


Kritikalitätslevel ASIL

ISO/FDIS 26262

Zur Risikoanalyse in der ISO 26262 wird eine festgelegte qualitative Methodik angewendet.

Dazu muss für jede identifizierte Gefährdung einzeln:

• die Schwere der Auswirkung (severity - S)

• die Häufigkeit der Fahrsituation (exposure - E)

• die Beherrschbarkeit der Fehlfunktion in der jeweiligen Fahrsituation z. B. durch den Fahrer (controllability - C)

abgeschätzt werden. Aus einer vorgegebenen Tabelle lässt sich dann für jede Gefährdung die Einstufung QM oder ASIL A bis D ablesen.

Kritikalitätslevel – ISO/FDIS 26262



ISO/FDIS 26262

KlasseS0 S1 S2 S3

No injuries Light and moderate injuries

Severe and life-threatining injuries (survival probable)

Life-threatening injuries (survival uncertain), fatal

injuries

Schwere der Auswirkung

KlasseE0 E1 E2 E3 E4

Incredible Very low probability

Low probability Medium probability

High probability

Häufigkeit der Fahrsituation

KlasseC0 C1 C2 C3

Controllable in general

Simply controllable

Normally controllable

Difficult to control or uncontrollable

Beherrschbarkeit der Fehlersituation



ISO/FDIS 26262

Schwere HäufigkeitBeherrschbarkeit

C1 C2 C3

S1

E1 QM QM QM

E2 QM QM QM

E3 QM QM A

E4 QM A B

S2

E1 QM QM QM

E2 QM QM A

E3 QM QM B

E4 A B C

S3

E1 QM QM A

E2 QM A B

E3 A B C

E4 B C D


SILCL Sicherheits-Integritätslevel

IEC/EN 62061

Sicherheits-Integritätslevel (SILCL) gemäß IEC/EN 62061



Fehlerkategorie SILCL Wahrscheinlichkeit eines

gefahrbringenden Ausfalls pro Stunde

(PFHd)

„hazardous /severe-major“ 3 ≥10-8 bis < 10-7

„major“ 2 ≥10-7 bis < 10-6

„minor“ 1 ≥10-6 bis < 10-5

Höh

ere

Sich

erhe

it


Klassifikation Risikoparameter

Klasse

S1 S2 S3 S4

Reversibel: erste Hilfe erforderlich

Reversibel: Behandlung durch Mediziner erforderlich

Irreversibel: gebrochene Gliedmaßen, Verlust eines Fingers

Irreversibel: Tod, Verlust eines Auges oder Arms

Schwere der Auswirkung

Klasse

F2 F3 F4 F5 F5

> 1 Jahr > 2 Wochen bis ≤ 1 Jahr > 1 Tag bis ≤ 2 Wochen > 1 Stunde bis ≤ 1 Tag ≤ 1 Stunde

Häufigkeit und Dauer der Exposition

Klasse

P1 P3 P5

wahrscheinlich selten unmöglich

Möglichkeit der Vermeidung

Klasse

W1 W2 W3 W4 W5

vernachlässigbar selten möglich wahrscheinlichsehr hoch

Wahrscheinlichkeit des Auftretens


Die Addition dieser Zahlen ergibt die Klasse der Wahrscheinlichkeit des Schadens K

Klasse der Wahrscheinlichkeit des Schadens (K)

Schwere (S) 3 bis 4 5 bis 7 8 bis 10 11 bis 13 14 bis 15

4 SIL 2 SIL 2 SIL 2 SIL 3 SIL 3

3 (AM) SIL 1 SIL 2 SIL 3

2 (AM) SIL 1 SIL 2

1 (AM) SIL 1

(AM): Empfehlung der Anwendung einer anderen Maßnahme

SILCL Sicherheits-Integritätslevel

IEC/EN 62061


Beispiele Gefährdungseinstufung

Lenkunterstützung ASIL-D = SIL 3Autopilot Tiefflug A400M DAL-A = SIL 4

Türsteuerung SIL 2 Infusionspumpe SIL 2

Airbag ASIL B (SIL 2)



Begriffsdefinition

Zuverlässigkeit (reliability) und Verfügbarkeit (availability) MTBF, MTTF, Ausfallrate und Fehlerrate


Zuverlässig verfügbar

Zuverlässigkeit

Die Wahrscheinlichkeit, daß ein System unter definierten Bedingungen eine gewisse Zeit fehlerfrei arbeitet

Die Zuverlässigkeit wird gemessen durch • MTBF: Meantime between failures – bei reparablen Systemen (z.B. PC – reboot)• MTTR: Meantime to restoration – Zeit zur Erkennung und Behebung• MTTF: Meantime to failures – bei nicht reparablen Systemen (z.B. Glühbirne)

Verfügbarkeit

Die Wahrscheinlichkeit, daß ein System unter definierten Bedingungen zu einem bestimmten Zeitpunkt fehlerfrei arbeitet


Die Fehlerrate, Ausfallrate und FIT

Ausfallrate, Fehlerrate λ

Berechnung für ein System mit konstanter Ausfallrate, Fehlerrate:

λ = oder λ =

1 FIT (failures in time) = 1 Fehler in 10 9 Betriebsstunden= 1 Fehler in 114.155 Jahren

Beispiel für 1 FIT:Bei 114.155 baugleichen Maschinen im dauernden Betrieb kommt es bei einer Maschine pro Jahr zu einem Zwischenfall mit „katastrophalen“ Folgen

1MTBF

Anzahl FehlerBetriebsstunden


Ausfallrate Berechnung, Beispiel

Wie wird die Ausfallrate bei Systemen von Objekten berechnet?

Bei einem System von Objekten wird die Ausfallrate des Systems berechnet als die Summe der Ausfallrate der einzelnen Elemente. Dabei wird davon ausgegangen, daß der Verlust irgendeines Elements zum Ausfall des Systems führt, was nicht der Fall ist, wenn das System Redundanz ausweist.

Zum Beispiel besteht eine Blinklampe aus20 Widerstände = 20 x 0.1 fit +3 Transistoren = 3 * 1 fit +2 Kondensatoren = 2 * 0.5 fit und1 Batterie = 200 fit.

Die totale Ausfallrate ist 206 fit, die mittlere Lebensdauer ist 550 Jahre. Diese Zahl gilt aber nur unter der Voraussetzung, daß die Batterie regelmäßig ausgewechselt wird: Die Batterie hat zu Anfang eine kleine Ausfallrate, die aber mit zunehmender Entladung stark ansteigt.


Ausfallrate Beispiel

Ausfallratemessungen an Glühbirnenoben: Kurve der funktionierenden Glühbirnen über der Zeitunten: Ausfallsrate, es ergibt sich hier ein auch für viele andere Produkte typisches Badewannenprofil der Ausfallswahrscheinlichkeit

Zum Beispiel werden 10 000 Glühbirnen gemessen (Bild). Am 19. Tag blieben noch 9 600 Birnen übrig und an diesem Tag fielen 5 Glühbirnen aus. Die Ausfallrate am 19. Tag war also 5/9600/24 = 21.7 pro Million Stunden = 21.700 fit.



Begriffsdefinition

Ausfallsicherheit und Lebensdauerverteilung


Ausfallsicherheit

In der Technik wird eine Ausfallsicherheit durch organisatorische Maßnahmen und technische Redundanzen erzielt – steigend geordnet:

Bereitstellung einer Ersatzkomponente, die bei einem Ausfall zum Einsatz kommt; wie ein Notstromgenerator bei einem Stromausfall.

Verwendung parallel arbeitender Komponenten, die die zusätzliche Belastung im Fehlerfall übernehmen. Beispiel: mehrstrahliges Flugzeug.

Redundanz der Funktion durch verschiedene Prinzipien. Beispiel: die gleichzeitige Verwendung eines elektronischen und eines mechanischen Meßgeräts.

In der Computertechnik, zusätzlich zu einfachen technische Redundanzen werden Computercluster eingesetzt.


Es gibt 2 Typen von Fehlern

Zufällige Fehler:

• Der Fehler tritt durch zufälliges Zusammentreffen von unterschiedlichen Ereignissen auf• Kann nicht vermieden werden und muss in der Applikation berücksichtigt werden• Ein Eintreten kann durch Gefährdungsbeurteilung und Risikoanalyse verringert werden

Systematische Fehler:

• Häufig das Resultat von Fehlern im Design oder der Produktion• Durch striktes Qualitätsmanagement reduzierbar• Häufig ein Ergebnis von nicht angewandten „best practices“


Sichere Entwicklung

Risikomanagement in der EntwicklungIdentifikation der möglichen Bedrohungen


Betrachtung aller System-Einflüsse

Generelle Einflüsse auf das System, die Risiken darstellen

• Temperatureinflüsse (Vereisung, Überhitzung)• Mechanische Einflüsse (Erschütterungen, Kompression, Beschleunigung)• EMV Einflüsse (äußere Felder, systemisch erzeugte Felder, Blitzschlag)• Wettereinflüsse (Wasser, Salzwasser, UV Bestrahlung)• Oxidation von Kontakten, Lötstellen, …• Stromversorgung (immer gewährleistet?)



Sensor defekt – das System wird „blind“

• Alterung der Hardware incl. Kunstoffgehäuse• Mechanischer Einfluss (Stoß, Steinschlag, Veränderung der Position)• Äußere Abschirmung und damit Reduktion der Sensorleistung• Veränderung der zu messenden Richtung (z.B. durch Erschütterungen)



Kabel/Stecker defekt – das System kann nicht „kommunizieren“

• Alterung der Hardware• Fehlende Sicherung der Steckverbindungen• Falsche Auslegung von Kabelstärken• Busfehler durch äußere Störungen (z.B. EMV)



Steuergerät defekt – das System kann nicht „denken“

• Hard- oder Softwarefehler• Falsche Reaktion auf Busfehler• Falsche Auslegung der Komponenten• Keine Berücksichtigung von Fehlerzuständen der Sensoren und Aktoren• Überlastung durch Daten-“boost“• Zu hohe Reaktionszeiten



Aktor defekt – das System wird „lahm“

• Mechanische Defekte (defekter Motor, Verklemmungen)• Keine autonome Notaus Funktionalität• Ungewollte Lage- oder Positionsänderung• Ausfall oder Reduktion der Stromversorgung• Kurzschluß• Hochvolt Probleme (schadhafte Isolatoren o.ä.)


Sichere Entwicklung

Anforderungen der funktionalen Sicherheit


Entstehung aus Safety Goals

Anforderungen der funktionalen Sicherheit folgen aus den Safety Goals:

• Aus der Risiko- / Bedrohungsanalyse werden die Safety Goals abgeleitet.• Aus den Safety Goals ergeben sich die Anforderungen zur funktionalen Sicherheit• Alle Anforderungen der funktionalen Sicherheit müssen vollständig umgesetzt sein• Alle Anforderungen der funktionalen Sicherheit müssen lückenlos verfolgbar sein


Risikoanalyse: Verfolgbarkeit

durch Verlinkung sicherstellen

SicherheitszieleSicherheits-

anforderungen

Gefahren und Risiken


Risikoanalyse ist übergeordnet

SystemrequirementsKundenrequirements

Planung des Projekts

Top-Level System-Design

DetaillierteRequirements

DetailliertesSystem-Design

ImplementierungEntwicklung

Kundenabnahme

SystemtestSicherheitsabnahme

IntegrationsTest

DetaillierteVerifikation

Modul Test

Gefährdungs- und RisikoanalyseSafety goals

Zertifizierung

Safety requirements


Sichere Entwicklung

Erforderliche Organisationsstrukturen gemäß der angestrebten Sicherheitslevels


Erforderliche Organisationsstruktur

Zwingend erforderlich für höhere Levels der funktionalen Sicherheit:

Eine unabhängige Qualitätssicherung!• Organisatorisch nicht in das Projekt integriert – fachlich schon• Berichtslinie direkt an die oberste Leitung des Unternehmens

Sinnvoll für höhere Levels der funktionalen Sicherheit:

Einen Manager für funktionale Sicherheit• Muss unabhängig von Projekten sein• Kümmert sich um die Einhaltung von Sicherheitsnormen über alle Ebenen• Sensibilisiert alle Beteiligten im Unternehmen für Anforderungen der funktionalen

Sicherheit


Die Umsetzung

Ausfallsicherheit durch robustes Design


Redundanzen erhöhen

Ausfallsicherheit

Ausfallsicherheit kann erhöht werden durch:

• Redundante Sensorik• Redundante Steuergeräte Hardware (vgl. Hardware Architekturen)• Redundante Aktorik• Diagnose Kanäle• Mischung von unterschiedlichen Technologien auf verschiedenen Kanälen (z.B.

Bremsfunktion ABS und Handbremse, mechanische und digitale Sensoren)• Intelligente Überwachungsfunktionen (z.B. Notaus durch aktiven Türsensor)• Autonome Notausfunktionen (z.B. Blockade einer Presse im Notaus-Fall)


Die Umsetzung

Architektonische Hardware Maßnahmen zur Erhöhung der Zuverlässigkeit und Sicherheit


Hardware: 1oo1 Architektur

1oo1 bezeichnet 1 out of 1

Dies ist die einfachste und meist kostengünstigste Form eines Systems. Hier gibt es keine Überwachung der sicheren Funktionsfähigkeit.

• Einfache Überwachungen sind durch Software realisierbar• Keine funktionale Sicherheit gewährleistet

Softw

are

Har

dwar

e

Zuverlässigkeit ▼

Verfügbarkeit ▼


Hardware: 1oo1D Architektur

1oo1 bezeichnet 1 out of 1 Diagnostic

Hier überwacht eine Diagnose Einheit die Funktionsfähigkeit der Hardware. Es kann im Fehlerfall (Hardware) reagiert werden. Softwarefehler oder Fehler außerhalb der Diagnose Überwachung werden nicht erkannt.

• Hardware Überwachung gewährleistet, Software nicht überwacht• Einfache funktionale Sicherheit realisierbar

Softw

are

Har

dwar

e

Diagnose

Zuverlässigkeit ►

Verfügbarkeit ▼



1oo2 bezeichnet 1 out of 2 („oder“ Verknüpfung – Redundanz der Steuergeräte),

meist als Multi-Core System realisiert

2 unabhängige Hardware-Kanäle, die beide eine Reaktion ausführen können. Bei Ausfall einer Einheit ist das System noch funktionsfähig. Sinnvoll in Verbindung mit einer Diagnose.

• Höhere Verfügbarkeit der Hardware durch 2 unabhängige Kanäle• Eingeschränkte funktionale Sicherheit realisierbar (z.B. für Airbag)• Softwareüberwachung durch 2. Kanal möglich

Zuverlässigkeit ►

Verfügbarkeit ▲



2oo2 bezeichnet 2 out of 2 („und“ Verknüpfung),

kann als „Lockstep“ der Steuergeräte eingesetzt werden

2 unabhängige Hardware-Kanäle, die ein konsistentes Ergebnis zeigen müssen, um eine Reaktion auszuführen. Bei Ausfall einer Einheit ist das System nicht mehr funktionsfähig. Sinnvoll in Verbindung mit einer Diagnose.

• Höhere Sicherheit der Funktion durch 2 unabhängige Kanäle• Eingeschränkte funktionale Sicherheit realisierbar• Ausfallsicherheit analog zu einem 1oo1 System• Softwareüberwachung durch 2. Kanal möglich

Zuverlässigkeit ▲

Verfügbarkeit ▼



2oo3 bezeichnet 2 out of 3 (3 Steuergeräte und Entscheidungslogik),

3 unabhängige Hardware-Kanäle, von denen 2 ein konsistentes Ergebnis liefern müssen, um eine Reaktion auszuführen. Bei Ausfall einer Einheit ist das System noch funktionsfähig. Entscheidungslogik überwacht die Steuergeräte (Diagnose).

• Höhere Verfügbarkeit der Hardware durch 3 unabhängige Kanäle• Hohe funktionale Sicherheit realisierbar (z.B. für Autopilot)• Softwareüberwachung möglich und erforderlich

Zuverlässigkeit ▲

Verfügbarkeit ▲

EntscheidungslogikMultiplexer


Die Umsetzung

Code/Design Review versus Test


Reviews effizienter als Tests

Reviews:

• Architektur Reviews

• Design Reviews

• Code Reviews

Jeweils in sehr frühen Phasen (sobald erste Ergebnisse zum Review zur Verfügung stehen)

Design und Code Reviews im Vergleich zu Tests

Tests:

• Komponententests (HiL)

• Systemtests (Black- / Whitebox)

• Umwelteinflüsse (EMV, Temperatur)

Erst nach Verfügbarkeit eines testbaren Systems möglich

Umwelteinflüsse sind nur durch Tests abzusichern

• Reviews sind deutlich effizienter als Tests

• Nahezu alle systematischen Fehler werden im Review gefunden

• Deutlich geringerer Aufwand durch Reviews


Die Umsetzung

Praxisbeispiel DO178B



Funktionalität:

• Konstante Regelung der Flughöhe

• Konstante Regelung der Flugrichtung

• Automatische Landung

• Keine Funktion beim Start

DAL-A: Autopilot



Notwendige Software Entwicklungsaktivitäten

DAL-A: Autopilot

© Quelle: HEICON Global EngineeringMartin Heininger Dipl.-Ing.(FH)



Funktionalität:

• Sicherheitsinformationen

• Bereitstellung von Passagierinfos

• Bordunterhaltungssystem

DAL D: Kabineninformations- und Displaysystem



Notwendige Software Entwicklungsaktivitäten

DAL D: Kabineninformations- und Displaysystem

© Quelle: HEICON Global EngineeringMartin Heininger Dipl.-Ing.(FH)


Die Umsetzung

Praxisbeispiel ISO 13849-1


Praxisbeispiel ISO 13849-1

Funktionalität:

• Sicheres Abschalten bei Detektion im Gefährdungsbereich

(z.B. bei manueller Bestückung)

• Überwachung der sicherheitsrelevanten Parameter

• Überwachung von Schutzsystemen

• Steuerung der Antriebe und ggf. Abschaltung

Schutzschaltung für den Antrieb eines Industrieroboters


Risikoanalyse Schutzschaltung

Antrieb Industrieroboter

Input OutputSensoren

Gefahrenbereich

Drehzahl-erfassung

Temperatur-sensor

Notaus

Abschaltung (STO)(safe torque off)

Logik / Steuerung

Fehler am Sensor:Schluss zur Versorgungsspannung

MasseschlußOszillierendes, offenes Signal

Kabelbruch

Kabelbruch

Verklebte Kontakte

Fehler im Steuergerät:Software- oder Hardwarefehler

Speicherfehler durch EMVFehler am internen Bussystem (Adress-/Datenbus), I/O Fehler

Über-/ Unterspannung


Beispiele für Sicherheitsziele,

Risiken und Anforderungen

SicherheitszieleSicherheits-

anforderungen

Gefahren und Risiken

Die Anforderung NOTAUS mußsicher zum Abschalten des

Roboterantriebs führen

Ein Kabelbruch in der Notausverkabelung führt dazu, daß die Notausanforderung nicht erkannt wird

Die Verkabelung des Notauskreises muss überwacht werden und bei einer Störung zur Sicherheitsabschaltung

führen

Eine Störung in der Verkabelung des Notauskreises muß spätestens nach

10 msec erkannt werden


Gewählte Architektur

Schutzschaltung Industrieroboter

Sensoren Gefahren-bereich (Lasergatter)

Drehzahlerfassung (Schleifring)

Temperatursensor(analog)

Notaus (Schließer)

Abschaltung STO (safe torque off)

Logik / SteuerungTyp 2

Sensoren Gefahren-bereich (öffner)

Drehzahlerfassung(Hall Sensor Typ 1)

Temperatursensor (digital)

Notaus (Öffner)

Abschaltung STO (safe torque off)

Logik / SteuerungTyp 1

Zwangsgeführte Hilfskontakte

(Rückmeldepfad)

Zwangsgeführte Hilfskontakte

(Rückmeldepfad)

Kreuzvergleich durch gegenseitige Überwachung

PWM mit 500 Hz


Die Umsetzung

Praxisbeispiel ISO 26262



Funktionalität:

• Im Falle eines Unfalls wird der Airbag ausgelöst

• Entfaltung erfolgt mittels pyrotechnischen Zünders

• Der Airbag muss zuverlässig auslösen

• Der Airbag darf nicht unbegründet auslösen

ASIL B oder SIL 2: Airbag


Die Auslösung erfolgt durch die Zündung eines pyrotechnischen Treibsatzes. Die hierbei entstehenden Abbrandgase füllen den Airbag. Die Abbrandgeschwindigkeit beträgt bei Natriumazid ca. 4700 m/s und es entsteht eine Gastemperatur von ca. 400°C bis 500°C.

Ein Fahrerairbag besitzt ein Aufblasvolumen von ca. 67 l und ist 30 ms nach dem Zünden entfaltet. Die Ausdehnungsgeschwindigkeit beträgt ca. 550 km/h. Der Beifahrerairbag besitzt ein Volumen von ca. 140 l und ist nach etwa 35 ms gefüllt. Das Gasgemisch besteht zu rund 99 % aus Stickstoff, Wasserdampf und Kohlendioxid

Ein Airbag kann mit einfacher pyrotechnischer Zündung nur einmal auslösen. Bei Mehrfachaufprall des Fahrzeugs wird die Schutzfunktion dadurch eingeschränkt.

Die Zündkapsel hat eine eigene, autonome Spannungsquelle, um im Falle einer durch den Unfall bereits zerstörten Energieversorgung trotzdem zu zünden.



Anforderung an die Funktionsfähigkeit des Airbags im Anforderungsfall:

„Trau‘ keiner Statistik…“


C1 C2 C3

S1

E1 QM QM QM

E2 QM QM QM

E3 QM QM A

E4 QM A B

S2

E1 QM QM QM

E2 QM QM A

E3 QM QM B

E4 A B C

S3

E1 QM QM A

E2 QM A B

E3 A B C

E4 B C D

Schwere der Auswirkung:S2: Severe and life-threatining injuries (survival probable)

Häufigkeit:E1: Very low probability

Level QM: Keine besonderen Maßnahmen erforderlich!!!

Beherrschbarkeit:C3: Difficult to control or uncontrollable


Anforderung an den Ruhezustand des Airbags:

„Trau‘ keiner Statistik…“


C1 C2 C3

S1

E1 QM QM QM

E2 QM QM QM

E3 QM QM A

E4 QM A B

S2

E1 QM QM QM

E2 QM QM A

E3 QM QM B

E4 A B C

S3

E1 QM QM A

E2 QM A B

E3 A B C

E4 B C D

Schwere der Auswirkung:S1: Light and moderate injuries

Häufigkeit:E4: High probability

ASIL Level B: Redundanz bei der Auslöse-Erkennung

Beherrschbarkeit:C3: Difficult to control or uncontrollable


Konsequenzen für die Entwicklung eines Airbag-Systems

Zur Erfassung der Airbag-Auslöse-Anforderung sind die Sensoren redundant ausgeführt. Zudem werden 2 verschiedene Methoden zur Erfassung verwendet:

• Erfassung der Beschleunigung mittels piezoelektrischem Effekt mit 2 unterschiedlichen Methoden

• (Erfassung mittels Verformungssensorik)

Das zugehörige Steuergerät wird 2 kanalig redundant ausgeführt (auf einem MC).

Die Aktorik (Zündeinheit) ist mit einer separaten Stromversorgung versehen.



Zertifizierung / Zulassung

Was kann zertifiziert/zugelassen werden


Unterscheidung Zulassung und

Zertifizierung

Typ-Zulassung:

• Eine Typ-Zulassung erfolgt durch eine staatliche Stelle (Luftfahrtbundesamt, Kraftfahrtbundesamt, EASA, …)

• Die Typ-Zulassung qualifiziert baugleiche Flug- / Fahrzeuge oder Geräte für einen sicheren Betrieb

• Eine Typ-Zulassung ist zwingend erforderlich, um z.B. ein Flug- / Fahrzeug oder Gerät in den Verkehr zu bringen

• Die Typ-Zulassung erfordert auch einen Nachweis der Sicherheit von Hard- und Software

Zertifizierung:

• Eine Zertifizierung ist nicht gesetzlich vorgeschrieben• Zertifizierungen können nur von akkreditierten Institutionen vorgenommen werden (z.B.

akkreditiert durch DAkkS – Deutsche Akkreditierungsstelle)• Zertifizierungen vereinfachen die Typ-Zulassung, garantieren sie jedoch nicht


Zertifizierungen

Zertifizierung von „Funktionen“ (safety items)

• Zertifiziert werden kann eine Funktion (z.B. ESP, Airbag, Lenkung) unter Einbeziehung von Sensorik, Steuergerät(en) und Aktorik

• Die Funktion muss eine sinnvolle funktionale Einheit darstellen

Zertifizierung von Elementen ohne Kontext (safety element out of context)

• Zertifiziert werden kann ein Grundelement (z.B. Betriebssystem, Compiler, Prozessor) ohne Bezug zu einer spezifischen Funktion

• Eine solche Zertifizierung reicht nicht aus, eine zertifizierte Funktion darzustellen• Diese Art der Zertifizierung erlaubt eine Vorqualifizierung geeigneter Komponenten für

sicherheitskritische Funktionen oder Systeme• Die Integration von zertifizierten Elementen in Funktionen oder Gesamtsysteme erfordert

eine erneute Zertifizierung der Anwendung


Die Zertifizierung

Die groben Schritte und Maßnahmen einer Zertifizierung


Ablauf einer Zertifizierung

- frühe Phase, Schritt 1

Risikobetrachtung mit MaßnahmenlisteErstellung der Anforderungen an die funktionale SicherheitTop Level Systemdesign (Software und Hardware)Festlegung eines Sicherheitslevels für den entwickelt wird

Review aller Dokumente durch die zertifizierende StelleBewertung, ob die Prozesse, die Maßnahmen sowie das Design geeignet sind, funktionale Sicherheit gemäß dem gewählten Level herzustellen �

�

Freigabe zur Entwicklung


Ablauf einer Zertifizierung

- Abschluß, Schritt 2

Entwicklung abgeschlossenSystemtests und Reviews abgeschlossenAlle erforderlichen Dokumente sind verfügbar

Review aller Dokumente durch die zertifizierende StelleBewertung, ob die vorgegebenen Prozesse eingehalten wurden, die Maßnahmen durchgeführt und alle erforderlichen Reviews und Tests abgeschlossen sind �

�

Zertifizierung des Systems


Die Dienstleister

Wer kann zertifizieren/zulassen


Wer kann zulassen/ zertifizieren

Typ-Zulassungen:

Luftfahrtbundesamt

Kraftfahrtbundesamt

EASA

US: JAA Joint Aviation Authorities

Zertifizierungen:

TÜV Nord Gruppe

TÜV Süd Gruppe

TÜV Rheinland

SGS TÜV Saar

VDE

Exida


Agil und sicher?

Kurzer Abstecher zur funktionalen Sicherheit und agilen Methoden


Wenn viele Anforderungen konstant

sind, lohnt sich agil nicht

Anforderungen anpassbar / flexibel

Konstante Anforderungen über den gesamten Entwicklungszeitraum

agil V-Modell

Projekt / Kundeflexibel

Projekt / Kundeunflexibel

Projekt / Kunde ohne funktionaler Sicherheit

Projekt / Kunde mit funktionaler Sicherheit


Trotzdem lohnt es sich die Regeln der

agilen Methoden anzuwenden

Agile Ansätze z.B. aus Scrum helfen jedem Software Entwicklungsprojekt

• Motivation des Teams durch viel Kommunikation analog „daily scrum“• Team als Gruppe von projekt-fremden Zugriffen abschotten• Starker und qualifizierter Produktmanager analog „product owner“• Review-Phasen während des Projekts analog „sprint retrospective“• Metriken, um Projektfortschritt zu messen analog „release/sprint burndown“• Priorisierung aller Anforderungen analog „product backlog“• Iterative Entwicklung für die Messung des Projektfortschritts und der Motivation• Daily (nightly) build der kompletten Software, „continuous integration“ um:

• Täglich eine lauffähige Version zu generieren• Kontrolle über „header“ und build Mechanismen zu behalten• Schnelle Reviews am „lebenden Objekt“ durchführen zu können

• Aktive Interaktion mit dem Kunden durch frühe „Prototypen“


Ihre Ansprechpartner der

NewTec

NewTec GmbH

System-Entwicklung und BeratungBuchenweg 389284 Pfaffenhofen a. d. Roth

Matthias Wolbert

Marktverantwortlicher Automotive / Transportation

Tel.: +49 (0)621 / 7899808-17E-Mail: [email protected]

Dieter Metternich

Marktverantwortlicher Verteidigungstechnik


Martin Allgaier

Marktverantwortlicher Medizintechnik


Thomas Mack

Marktverantwortlicher Avionik


Svenja Notz

Marketing & Training


Funktionale Sicherheit in der Praxis · 2018-05-24 · Beispiel: SIL 4 Wahrscheinlichkeit eines...

Documents

Transcript of Funktionale Sicherheit in der Praxis · 2018-05-24 · Beispiel: SIL 4 Wahrscheinlichkeit eines...