Designpraxis Funktionale Sicherheit in der Praxis - Teil 1

Funktionale Sicherheit
Funktionale Sicherheit

Für Entwickler, die erstmals mit dem Thema Funktionale Sicherheit konfrontiert werden, erscheint dieses sehr unübersichtlich, teuer und riskant. Dieses mehrteilige Elektronik-Projekt zeigt beispielhaft die Anforderungen der Standards, die Planung eines Projekts und dessen Durchführung auf.

Nicht nur durch rechtliche Anforderungen sind immer mehr embedded-Projekte von dem Thema Funktionale Sicherheit betroffen, auch aus Wettbewerbsgründen und aus Gründen der Systemzuverlässigkeit werden die Regeln der Funktionalen Sicherheit in der Entwicklung angewandt. Mit der Steuerung eines Elektromotors und einem Gaswarngerät werden zwei Applikationen mit sehr unterschiedlichen, aber typischen Anforderungen genannt und aufgezeigt, wie diese mit Mikrocontrollern von Infineon und den Services von Hitex zertifizierbar realisiert werden.

Die Tendenz, dass immer mehr die Software für Embedded-Systeme funktionsentscheidend ist und dass diese immer komplexer wird, ist seit langem bekannt. Die Erwartungen an die Systeme kann in diverse Kategorien eingeteilt werden: Zuverlässigkeit, Verfügbarkeit und Sicherheit, wobei das System nur richtig nutzbar ist, wenn alle Kategorien erfüllt sind. So ist ein System, das zur Wartung in der Werkstatt steht, zwar sicher im Sinne der Funktionalen Sicherheit (es kann kein Schaden in seiner üblichen Nutzung von ihm ausgehen), aber es ist eben nicht verfügbar.

Die Sicherheit wird nochmals in zwei verschiedene Kategorien unterteilt, die englischen Begriffe „Security“ und „Safety“ sind hier klarer. Einmal geht es um die Sicherheit vor externen Manipulationen (z.B. Hacker-Angriffen), das andere bedeutet die Funktionale Sicherheit, das Schwerpunktthema dieses Projektes. Was bedeutet nun diese Funktionale Sicherheit? Dass es kein absolut sicheres System gibt, ist wohl inzwischen unumstritten. Von jedem System gehen Gefahren aus. Um die Sicherheit eines Systems zu bewerten, gibt es zwei Ansätze.

Der erste Ansatz betrachtet die Vorgehensweise und vergleicht mit dem Stand der Technik. Hier betrachtet der Zertifizierende, ob alle üblichen und technisch zumutbaren Maßnahmen ergriffen wurden, um das System sicher zu machen. Da der Stand der Technik sich laufend weiterentwickelt, steigen damit auch die Anforderungen.

Der zweite Ansatz ist die Abwägung der Gefahren im Vergleich zu anderen alltäglichen Gefahren. Tragen die Gefahren eines Systems nicht wesentlich zur Erhöhung der allgemeinen Risiken bei, so wird das dadurch entstehende Risiko als tolerabel bezeichnet. Bei dieser Betrachtung gehen die Fehlerwahrscheinlichkeit, die Häufigkeit der Nutzung, der mögliche Schaden sowie die Einflussmöglichkeiten bei einem Fehler in die Betrachtung ein und die Anforderungen auf dieses Ergebnis ergeben die tolerable Fehlerrate, wie sie in den Sicherheitsstandards definiert ist. Auch hier sind Veränderungen zu sehen; so wurde z.B. nach den folgenschweren hitzebedingten Ausfällen der Klimaanlagen in den ICE-Zügen die Bewertung des Risikos der Klimaanlagen wesentlich erhöht.

Infineon und Hitex haben aufgrund dieser Betrachtungen ein Konzept mit den erforderlichen Komponenten Mikrocontroller, Dokumentation, Software und Consulting entwickelt, mit dem inzwischen erfolgreich die Zertifizierung erreicht wurde. In der Praxis wird dieses Konzept seit Jahren in der Automobilindustrie bei Motor- und Getriebesteuerungen eingesetzt, ist aber inzwischen auch sehr erfolgreich bei klassischen Industrieapplikationen etabliert. Im Folgenden soll gezeigt werden, wie mit diesen Komponenten der Aufwand für die Funktionale Sicherheit minimiert werden kann.

Die Anforderungen der Standards

Hier beginnt die erste Fragestellung bei Beginn eines Projektes: Welche Standards müssen beachtet werden und was davon ist auf mein Projekt anzuwenden? Als branchenübergreifende Norm ist die IEC 61508 zu sehen. Sie wurde bereits 2001 als DIN-Norm zur „Funktionalen Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme“ übernommen. Aus ihr wurden verschiedene bereichsbezogene Normen abgeleitet; die neueste ist die ISO 26262, gültig für den Automobilbereich. Weitere Standards sind IEC 62061 (Maschinen), IEC 61511 (Prozess-industrie), IEC 60335 (Hausgeräte) und diverse IEC 501xx (Bahn). Die DO-178B (Flugzeuge) und IEC 60601 (Medizingeräte) sind teilweise abgeleitet, haben aber auch andere Ansätze. Gilt für das zu entwickelnde System keine spezielle abgeleitete Norm, so ist die IEC 61508 anzuwenden, auf die im Weiteren auch tiefer eingegangen werden soll.

Die zweite Fragestellung ist die Einstufung des Sicherheits-Integritäts-Levels (SIL bzw. ASIL bei ISO 26262) für das System. Es wird von SIL 1 (niedrige Stufe) bis SIL 4 (höchste Stufe) unterschieden. Als Ausgangspunkte werden die Fehlerhäufigkeit, der mögliche auftretende Schaden, die Häufigkeit der Nutzung und die Möglichkeit des Eingreifens, einen Schaden zu verhindern, betrachtet. Bild 1 zeigt die sich ergebenden SIL-Level.

Aus der SIL-Einstufung kann dann die erlaubte Fehlerrate abgeleitet werden. Hierbei wird unterschieden, ob das System permanent genutzt wird und auch permanent sicher sein muss (z.B. eine Motorsteuerung, kontinuierliche Betriebsart) oder nur gelegentlich genutzt wird (Anforderungsmodus). Im ersten Fall wird eine maximale Ausfallrate pro Stunde definiert, im letzteren eine maximale Ausfallrate pro Nutzung (Tabelle).

Damit ist definiert, wie groß das Ausfallrisiko des Systems sein darf, also das tolerable Risiko. Nun muss das tatsächliche Risiko des Systems analysiert werden, und da dies üblicherweise höher als das tolerable Risiko ist, muss es auf das erlaubte Maß reduziert werden (Bild 2).

Safety Integrity Level
 Kontinuierlicher Modus (Ausfälle
pro Stunde)
 Anforderungsmodus (Ausfälle
pro Nutzung)
SIL 4≥10–9 bis 10–8≥10–5 bis 10–4
SIL 3
≥10–8 bis 10–7≥10–4 bis 10–3
SIL 2≥10–7 bis 10–6≥10–3 bis 10–2
SIL 1≥10–6 bis 10–5≥10–2 bis 10–1
Maximale Ausfallraten bei den verschiedenen Safety Integrity Levels.