Startseite > Halbleiter > Funktionale Sicherheit in der Praxis - Teil 1

Designpraxis

Funktionale Sicherheit in der Praxis - Teil 1

4. Juli 2013, 10:07 Uhr | Kurt Böhringer und Markus Kroh

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Risikoanalyse und Risikoreduzierung

Es gibt verschiedene Ursachen, aus denen Fehlfunktionen entstehen können, u.a.

falsche oder unvollständige Spezifikation des Systems
statistische Hardware-Fehler
systematische Hardware-Fehler
Software-Fehler
Umwelteinflüsse
Störungen in der Versorgungsspannung

Diese gilt es zu erkennen und zu reduzieren. Die Norm IEC61508 unterscheidet hier auch zwischen Hardware und Software und widmet jedem Teil ein Kapitel (Kap. 2 und 3). Da systematische Fehler im Entwicklungsprozess vermieden und erkannt werden können, werden für dessen Reduktion Anforderungen an den Entwicklungsprozess gestellt. Hierauf soll später eingegangen werden.

Jobangebote+ passend zum Thema

Auszubildende zum Kaufmann für Groß- und Außenhandelsmanagement (m/w/d) FR Großhandel mit dem Schwerpunkt Vertrieb

GLYN GmbH & Co. KG, Idstein

Vertriebsinnendienst / Account Manager (m/w/d) für das Vertriebsbüro bei Wien

GLYN GmbH & Co. KG, Brunn am Gebirge

Quereinsteiger im Vertriebsinnendienst (m/w/d) für das Vertriebsbüro bei Wien

GLYN GmbH & Co. KG, Brunn am Gebirge

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Statistische Fehler sind in der Software nicht vorstellbar und treten in der Hardware auf. Hier sind Maßnahmen beim Betrieb zu ergreifen, um diese Fehler zu erkennen und zu minimieren. Dabei können verschiedene Maßnahmen ergriffen werden, z.B. durch redundante Hardware, d.h. für wichtige Hardware-Komponenten wird eine Kontrollinstanz eingebaut, die ein Fehlverhalten erkennt, oder es wird per Software ein Testmechanismus eingebaut, der das Fehlverhalten erkennt. Dabei ist vorgeschrieben, dass die Erkennungszeit und die Reaktionszeit darauf, um einen Schaden durch einen Fehler zu vermeiden, kleiner als die Zeit sein muss, in welcher der Fehler einen Schaden verursachen kann (Prozesssicherheitszeit). Außerdem muss das System bei Erkennung eines Fehlers nach der Reaktionszeit die Fähigkeit haben, in einen sicheren Zustand überzugehen.

Für Mikrocontroller gibt es verschiedene Methoden der Risikominimierung. Bisher waren oft zweikanalige Systeme im Einsatz, wobei die beiden Mikrocontroller (ggf. verschiedene Typen mit unterschiedlicher Programmierung, um auch systematische Fehler zu minimieren) sich gegenseitig überwachten. Heute geht man eher zu einkanaligen Systemen über, wobei hier für die CPU auch zwei Ansätze gewählt werden können. Es gibt Mikrocontroller mit zwei CPUs, die das gleiche zeitlich versetzt abarbeiten und statistische Fehler einer der beiden CPUs so erkannt werden (sog. Lockstep-Funktionalität). Ein anderer Ansatz ist, die fehlerfreie Ausführung der CPU per Software zu testen, wobei hier auch sichergestellt werden muss, dass der Test die erforderliche Testabdeckung des CPU-Siliziums erfüllt. Im einkanaligen System ist also die Unterstützung des Mikrocontroller-Designers nötig.

Entsprechend den SIL-Anforderungen muss nun das Risiko der statistischen Fehler minimiert werden. Hierbei hilft die Unterscheidung der Fehler, ob sie zu einem wesentlichen Schaden führen können (gefährliche Fehler) oder zu keinem Schaden führen (ungefährliche Fehler). Im Sinne der Zuverlässigkeit und Bedienbarkeit eines Systems ist diese Unterscheidung nicht relevant; insofern macht es durchaus auch Sinn, über die Anforderungen der Funktionalen Sicherheit hinauszugehen und auch solche Fehler zu vermeiden.

Die gefährlichen Fehler gilt es nun durch die Minimierungsmaßnahmen zu erkennen. Hierbei spielt die sogenannte Diagnostic Coverage (DC), d.h. der Anteil der Hardware, der überwacht wird, eine Rolle. Hierbei gilt: DC = λ_dd/λ_{d, mit}λ_dd = Anzahl der erkennbaren gefährlichen Fehler und λd = Gesamtanzahl der gefährlichen Fehler. Mit SFF (Safe Failure Fraction) wird der Anteil der ungefährlichen und erkannten gefährlichen Fehler bezeichnet (siehe Formel).

Hierbei ist λs die Anzahl der ungefährlichen Fehler. In Summe ergeben daher λs und λd die Summe der Gesamtfehler (Bild 3).

Wie diese Erkennungsmaßnahmen durchgeführt werden, ist eine Aufwandsabwägung. Erfolgen sie durch Hardware, bedeutet das zusätzliche Kosten und evtl. auch Energieverbrauch; werden sie durch Software erledigt, dann spielen Performance-Betrachtungen und Interrupt-Latenzzeiten eine wichtige Rolle. Auf diese Punkte wird im nächsten Teil des Projektes näher eingegangen.
Die Vermeidung der oben genannten systematischen Fehler hat großen Einfluss auf den Entwicklungsprozess, wobei die Anforderungen bei zweikanaligen Systemen wesentlich kleiner sind als bei einkanaligen.

Auch hier ist es wieder so, dass der Beweis, dass der Mikrocontroller entsprechend den Standards entwickelt wurde, vom Chiphersteller zu erbringen ist. Der Anwender ist dann verpflichtet, die daraus folgenden Errata Sheets richtig zu beachten und so bekannte systematische Fehler eines Mikrocontrollers zu umgehen.

Für seine Applikations-Hardware und seine Software hat nun der Entwickler Prozesse zu entwickeln, die sichern, dass die Regeln der Standards eingehalten werden. Diese Regeln umfassen Vorgehensweisen, Rollen, Dokumentation und Vorgaben für die Implementierung und die Tests. Diese Regeln basieren auf Erfahrungen, wo oft Spezifikations-, Design-, Implementierungs- und auch Änderungsfehler geschehen können, und versuchen diese zu erkennen und zu vermeiden. Üblicherweise werden diese Regeln als V-Modell dargestellt (Bild 4).

Bekannterweise ist eine Entwicklung nach den Sicherheitsstandards mit der zugehörigen Dokumentation und Vorgehensweise wesentlich aufwendiger als eine bisher übliche Entwicklung (die Erfahrung zeigt einen Faktor 2 bis 4 mehr Zeitaufwand); deshalb ist hier auch abzuwägen, was sicherheitsrelevant ist und entsprechend entwickelt werden muss und was nicht. Auch der Prozess selbst ist optimierungswürdig; nicht alles, was gemacht werden kann, ist gefordert und ggf. auch nicht nötig.

Um diese Anforderungen zu erfüllen, gibt es verschiedene Möglichkeiten und es gibt von verschiedenen Mikrocontroller-Herstellern diverse Angebote. Die konkrete Planung eines Konzeptes wird im Teil 2 beschrieben.

Dipl.-Physiker Dr. Kurt Böhringer
ist seit über 20 Jahren in der Embedded-Welt bei Hitex tätig. Als Head of Technology & Innovation ist er unter anderem mit dem Schwerpunktthema Funktionale Sicherheit beschäftigt.
Kurt.Boehringer@hitex.de

Markus Kroh
ist seit 12 Jahren bei der Infineon Technologies AG tätig. Als Marketing Manager ist er u.a. für den Bereich „Business Development Functional Safety“ verantwortlich.
markus.kroh@infineon.com