Designpraxis Funktionale Sicherheit in der Praxis - Teil 3

Projekt Funktionale Sicherheit
Projekt Funktionale Sicherheit

Im letzten Teil dieses Projektes wird die SafeTcore-Bibliothek für XC2300- und TriCore-Mikrocontroller im Detail beschrieben und anhand von zwei Applikationsbeispielen die Realisierung erläutert. Auch hier wird mehr Wert auf Verständlichkeit als auf detailgetreue Exaktheit gelegt.

Wie bereits im letzten Teil erwähnt, besteht der Sinn des Sicherheitskonzeptes und der Selbsttestbibliothek darin, dem Anwender Bausteine zur Verfügung zu stellen, welche die sichere Funktion des Mikrocontrollers in Verbindung mit dem externen Watchdog CIC61508 nach Anforderungen der Standards testet und beweist. Wenn diese Bibliothek entsprechend dem Safety Manual richtig eingesetzt wird, so ist es auch möglich, die Zertifizierung zu erreichen. Wie die Beispiele zeigen, gibt es sehr unterschiedliche Sicherheitsanforderungen. Um diesen genügen zu können, ist die Bibliothek ein konfigurierbares Framework, das von der Applikation gezielt kontrolliert wird. Auf die richtige Inte-gration, d.h. die Anpassung der Parameter an das Safety-Konzept der Applikation, kommt es an.

Die Beispielapplikationen

Stellvertretend sollen hier zwei unterschiedliche Applikationen beschrieben werden, die die Konfiguration an die Anforderungen exemplarisch zeigen. Die erste ist eine typische Drive-Applikation. Markant ist dabei die hohe Interrupt-Last mit den extrem niedrigen Latenzzeiten und die kurze Zykluszeit, d.h. die Zeit, innerhalb derer eventuelle statistische Fehler erkannt werden müssen, um das System in einen sicheren Zustand zu bringen. Sie kann unter Umständen im Bereich von nur 12 ms liegen, d.h. innerhalb dieser Zeit müssen alle zur Laufzeit vorgeschriebenen Tests vollständig und erfolgreich durchgeführt worden sein und im Fehlerfall das System in den sicheren Zustand gebracht worden sein. Hier ist der TriCore der passende Controller, der die Anforderungen bezüglich der Rechenleistung erfüllen kann und der typischerweise auch ein oft genutzter Controller für solche Systeme ist. Die Anforderungen werden von der ISO 26262 als ASIL D definiert.

Die zweite Applikation ist eine Sensorapplikation für gefährliche Gase. Aufgrund der Tatsache, dass sich Gaskonzentrationen nur langsam verändern, ist auch die geforderte Zykluszeit wesentlich geringer. Anwendungsbedingt kann die sichere Erkennung statistischer Fehler innerhalb von 100 ms nötig sein. Die Anforderungen an die Rechenleistung, an die Speichergröße und auch an die Art der Peripherie - es werden hier nur GPIOs, A/D-Wandler und Kommunikations-Peripherie benötigt - lassen einen günstigen XC2300-Mikrocontroller zu. Die Anforderungen kommen von dem Standard IEC 61508 mit der Stufe SIL2.

Die SafeTcore-Elemente

Das Sicherheitskonzept beinhaltet alles Nötige für eine erfolgreiche Zertifizierung eines Mikrocontrollersystems bezogen auf den Mikrocontroller. Dies beinhaltet die Dokumentation der Mikrocontroller und des externen Watchdog CIC61508 inklusive FMEDA, die Dokumentation des Sicherheitskonzeptes selbst (Safety Manual) und die Sicherheitsbibliothek im Quellcode mit den Anforderungen, wie diese in die Applikation einzubinden ist.

Wie die Aufgabenverteilung und die Challenge-Response-Kommunikation des Mikrocontrollers und des externen Watchdog die Sicherheitsstandards erfüllen, wurde bereits beschrieben; hier soll im Wesentlichen auf die Einbindung der Sicherheitsbibliothek sowie die Konfiguration des externen Watchdog eingegangen werden. Bild 1 zeigt schematisch den Aufbau eines sicherheitskritischen Systems.

Die Sicherheitsbibliothek hat die Aufgabe, die richtige Funktionsweise der wichtigen Blöcke des Mikrocontrollers zu beweisen, und wird sowohl beim Start als auch während der laufenden Applikation ausgeführt. Wie in den Beispielapplikationen gezeigt, bestimmen die Sicherheitsanforderungen der Anwendungen die Zeit- und Abdeckungsparameter wie z.B. die Zykluszeit (auch Diagnostic Interval Time DIT genannt). Bild 2 zeigt ein Realisierungsbeispiel zur Laufzeit (Built-in Self Test BIST).

Eines der wichtigsten Elemente ist der CPU-Selbsttest (SBST). Bei der Entwicklung wurde besonderen Wert darauf gelegt, mit möglichst wenig Rechenleistung eine hohe Diagnoseabdeckung zu erhalten. Diese Abdeckung wurde in der Simulation des Siliziums geprüft und ist in dem „Prove of Diagnostic Coverage“-Dokument niedergeschrieben. Eine Abdeckung von 95 % bedeutet also nicht nur, dass 95 % der Instruktionen getestet wurden, sondern dass tatsächlich 95 % des CPU-Siliziums mit dem SBST geprüft wird. Da bei diesen Tests teilweise Interrupts gesperrt werden müssen, wurde auch hier so optimiert, dass die von den Applikationen geforderten Interrupt-Latenzzeiten erreicht werden konnten.

Da dieser Test ein wichtiges Merkmal, nämlich die Integrität der CPU, beweisen muss, werden die Ergebnisse der Tests an den CIC61508 gemeldet und die erfolgreiche Testdurchführung von diesem überwacht.

Ein weiterer wichtiger Test ist der sogenannte „Program Sequence Monitor“. Mit diesem Monitor wird nicht nur die richtige Programmabarbeitung, sondern auch eventuelle Überlastungen des Prozessors überwacht. Hierbei sind Programmsequenzen bezüglich Reihenfolge und Zeitfenstern als Sollvorgabe definierbar. So spielt es keine Rolle, ob ein Echtzeitbetriebssystem vorhanden ist oder nicht. Auch hier ist aufgrund der Wichtigkeit die prüfende Instanz eine andere als die ausführende. Beim TriCore wird die Programmsequenz vom PCP und beim XC2300 vom CIC61508 geprüft.

Um höhere SIL- bzw. ASIL-Level mit vertretbarem Aufwand zu erreichen, ist es in einigen Fällen notwendig, den sicherheitskritischen Algorithmus diversitär zu implementieren. Ein Beispiel, wie so eine Implementierung mit einem XC2300-Mikrocontroller aussehen könnte, ist in Bild 3
zu sehen.

Der gleiche Algorithmus wird zum einen mit Hilfe der ALU, zum anderen mit Hilfe der MAC-Einheit realisiert. Die Ergebnisse werden anschließend durch eine unabhängige Instanz verglichen. Beim SafeTcore für XC2000 erfolgt der Vergleich durch den Watchdog CIC61508, beim SafeTcore für TriCore durch die SafeTcore-Applikation auf dem PCP-Core. Dabei müssen die Ergebnisse nicht zwingend gleich sein. Mit der in SafeTcore bereitgestellten Schnittstelle kann sowohl ein Vergleich auf Gleichheit als auch „größer als“ und „kleiner als“ durchgeführt werden. Es lässt sich auch leicht eine Bereichsprüfung realisieren, um zu prüfen, ob das errechnete Ergebnis in einem definierten Bereich liegt.

Zu den zyklischen Tests gehören auch die CSFR- und SFR-Tests. Bei diesen Tests wird überprüft, ob der Inhalt eines Core bzw. Peripheral-Special-Function-Registers dem erwarteten Wert entspricht. Diese Maßnahme ist sowohl gegen systemische Software-Fehler während der Entwicklung, die z.B. dazu führen, dass eine Peripherie fälschlicherweise umkonfiguriert wird, als auch gegen transiente Fehler, die Bit-Kipper in den Registern verursachen können, sinnvoll.
Weitere zyklische Tests sind RAM- und ROM-Tests und der Test der ECC-Logik. Da zur Laufzeit eines Systems nur geringe Ressourcen zur Verfügung stehen, ist der RAM-Test laufzeitoptimiert und kann dementsprechend nur „Stack at“-Fehler (Fehler, bei denen ein Signal einen festen logischen Zustand einnimmt und sich nicht verändern lässt) erkennen. Dadurch aber, dass sowohl beim TriCore als auch beim XC2000 die RAMs durch die ECC-Logik abgesichert sind, ist normalerweise eine zyklische Ausführung des RAM-Tests nicht notwendig. Das gleiche gilt auch für den ROM-Test.

Während der Startup-Tests werden zusätzlich zu den oben genannten zyklischen Tests die sicherheitsrelevanten Peripherien wie z.B. die DMA und die MCHK-Einheiten getestet. Damit sollen latente (schlafende) Fehler vermieden werden. Die MCHK (Memory Checker Unit) wird zum Beispiel sowohl für den ROM-Test als auch für den Instruktionstest (SBST) verwendet und ist damit sicherheitsrelevant.

Beim SafeTcore für XC2300 stehen u.a. folgende Startup-Tests zur Verfügung: RAM-Test, ROM-Test, Test der MultiCAN-Einheit, Überprüfung der ECC und Paritäts-Logik für RAMs und Flash-Speicher, Peripherie-Konfigurationsregister-Test, Test der Memory-Checker-Einheit, Überprüfung des internen Watchdog, Befehls-Cache-Test und SBST (Software Based Self Test).
SafeTcore für TriCore bietet die gleichen Tests wie SafeTcore für XC2300 an und deckt zusätzlich einige Peripherie-Elemente ab, die beim XC2300 nicht vorhanden sind.