Funktionale Sicherheit Safety-Rundumpaket

Embedded Systeme werden immer öfter auch in Bereichen eingesetzt, die bei Fehlfunktionen Schäden verursachen könnten. Hierbei handelt es sich nicht nur um Luft- und Raumfahrt, Fahrassistenzsysteme oder Medizintechnik, nein auch bei Geräten in unserem alltäglichen Umfeld können - wenn auch kleinere - Schäden entstehen, die zu vermeiden sind. Hersteller solcher Systeme stehen vor der Herausforderung, Maßnahmen für eben diese Schadensvermeidung zu treffen oder gar eine Zertifizierung ihres Geräts entsprechend den Anforderungen der Normen zu erhalten. Wie gut, wenn man ein Rundum-Sicherheitspaket aus Konzept, Software und Dienstleistungen zur Verfügung hat.

Absolut sichere Systeme gibt es nicht, das ist klar. Doch unter dieser Prämisse versuchen verschiedene Normen zu definieren, was »funktionale Sicherheit« (Safety) bedeutet. Als Grundnorm dafür gilt die IEC 61508, aus der dann branchenspezifische Normen abgeleitet wurden, wie die ISO 26262 für den Automobilbereich. Weitere spezifische Normen gibt es auch für Flugzeuge, Kernkraftwerke, Bahnanwendungen, Medizintechnik sowie Feuerungen bis hin zu Hausgeräten. Auch wenn diese Normen sehr unterschiedlich sind, ist das Prinzip doch ähnlich, und vieles wird aus der Grundnorm abgeleitet, auf die im Folgenden hauptsächlich referenziert werden soll.

Grundsätzlich bewerten die Normen das Risiko eines Systems, also das Produkt aus der Eintrittshäufigkeit eines Fehlers und der Schwere der Auswirkungen. Zudem verlangen die Normen, das Restrisiko durch geeignete Maßnahmen unter das »tolerable« Risiko zu drücken. Wie stark diese Maßnahmen sein müssen, definieren die »Safety Integrity Level« (SIL 1 bis SIL 4 bzw. im Automobilbereich ASIL A bis ASIL D; Tabelle 1). Hierbei wird unterschieden, ob das System permanent (High Demand Rate) oder nur auf Anforderung (Low Demand Rate) aktiv ist.

Die Maßnahmen zur Gefahrenreduktion verteilen sich auf das Vermeiden von systematischen Fehlern und das Beherrschen von statistischen Fehlern. Ersteres bezieht sich meistens auf Software und bestimmt den ganzen Entwicklungsprozess vom Design über Implementierung, den verschiedenen zugeordneten, nachvollziehbaren Tests bis hin zur Dokumentation nach dem V-Modell. Letzteres bezieht sich meistens auf die Hardware. Dort müssen Fehler besonders des Mikrocontrollers erkannt und damit unschädlich gemacht werden.

Die Norm sagt dazu, der Anteil ungefährlicher Ausfälle (Safe Failure Fraction, SFF) muss steigen. Einen guten Einstieg in die recht umfangreichen, schwer verständlichen und auch oft interpretierbaren Normen gibt das Werkzeug »RiskCAT« von Hitex, bei dem aus den Systemeigenschaften die SIL-Stufen sowie sämtliche empfohlenen und notwendigen Maßnahmen ersichtlich sind. Zudem lassen sie sich auch auf die betreffenden Stellen in der Norm referenzieren, was die Planung eines Sicherheitsprojektes deutlich leichter und klarer machen soll.

Zwei Bausteine machen sicher

Für Nutzer der Mikrocontroller »TriCore« und »XC2000« haben deren Hersteller Infineon und der Tool-Anbieter Hitex nun ein Sicherheitskonzept entwickelt und bieten hierfür ein Paket von Komponenten an, um die Integration funktionaler Sicherheit leicht zu machen. Die 16-Bit-Mikrocontrollerfamilie »XC2300« ist dediziert für Safety-Applikationen im Automobil- und auch im industriellen Bereich ausgelegt. Die Derivate decken sowohl kostensensitive als auch komplexe, leistungshungrige Anforderungen ab.

Mit einem flexiblen Satz an Peripherieeinheiten ist die Familie besonders für Sicherheits-anwendungen geeignet. Die 32-Bit-Familie TriCore mit dem vereinigten RISC-MCU/DSP-Prozessor ist für höhere Anforderungen im Automobil- und Industriebereich gedacht. Mit ihrem integrierten Peripheral-Control-Processor (PCP) ist sogar eine Aufgabenteilung bei der Fehlererkennung möglich, weshalb in diesem Beitrag hauptsächlich auf die TriCore-Variante mit dem integrierten Sicherheitskonzept eingegangen werden soll. Dies soll allerdings nicht den Eindruck erwecken, dass die XC-Variante weniger leistungsfähig wäre.

Mit dem Label »PRO-SIL« hat Infineon alle Komponenten gekennzeichnet, die zu dem Sicherheitskonzept passen. Das Konzept für die Erkennung von statistischen Fehlern (Hardware) basiert auf einen Zweichip-System mit einem Mikrocontroller vom Typ TriCore beziehungsweise vom Typ XC2300 und dem externen Watchdog »CIC61508« (Safety Monitor).

Letzterer muss bis zu vier konfigurierbare Spannungsdomänen überwachen und ist über einen SPI-Kanal an den Mikrocontroller angeschlossen (Bild 1). Er kommuniziert mit dem TriCore in definierten Zeitfenstern in einem Frage-Antwort-Ablauf und kann damit sowohl die von den Normen geforderte korrekte Funktionsweise des Clocks als auch der Spannungen der MCU prüfen. Fehlerzähler summieren auftretende Fehler, und ab einer konfigurierbaren Schwelle signalisiert er dies mit bis zu drei Ausgabepins (Safe State Control). Dies kann man zum sicheren Abschalten des Systems nutzen.

Der TriCore-Mikrocontroller wiederum überwacht die Spannungsversorgung des CIC61508, und durch die Frage-Antwort-Kommunikation erkennt er auch dessen Ausfall. Ansonsten teilt er sich seine Fehler-erkennungsaufgaben zwischen Haupt-CPU und Peripheral-Control-Processor (PCP) auf. Es wird hierbei nicht nur auf Hardwarefehler getestet, sondern auch auf fehlerhafte Abweichungen des Programmablaufes (Task Monitoring). Jeder Test hat einen Fehlerzähler mit zwei konfigurierbaren Schwellen.

Die erste Schwelle kann einen Interrupt auslösen, um noch per Software auf den Fehler reagieren zu können, die zweite Schwelle führt nach einem Interrupt zwangsweise zum sicheren Abschalten des Systems. Der aufwändigste Test ist der Opcode-Test. Hierbei wird nicht nur jede Instruktion geprüft, sondern der Test wird so durchgeführt, dass eine ausreichende Abdeckung des Siliziums gewährleistet ist. Die Liste der Core-Checks enthält Registertests, Speichertests (RAM, FLASH, Cache), Bus-Diagnostic-Tests, Algorithm-Result-Comparison und MPU-Tests.

Auch Peripherie-Einheiten werden geprüft: CAN, FlexRay (falls vorhanden), Memory-Check-Unit, DAM-Unit, Interrupt-Struktur, Bus-Control-Unit und Error-Correction-Unit. Das »intelligente« Konzept verteilt dabei die Aufgaben auf TriCore und PCP, um eine maximale Abdeckung bei möglichst kleinem Ressourcenbedarf zu erreichen. Durch die Aufteilung ist auch eine Unabhängigkeit von ausführender und überwachender Instanz gegeben. So wird jeweils die Instanz, welche die Tests ausführt, von der jeweils anderen Instanz bezüglich der Testergebnisse überwacht.

Baukastensystem für zertifizierbare Qualität

Die kompletten oben genannten Selbsttestroutinen wurden für verschiedene TriCore-Derivate entwickelt und stehen in Kürze auch für die XC2300-Familie zur Verfügung. Bei der Entwicklung wurde streng normengerecht vorgegangen (V-Modell, Traceability). Von der Anforderungsspezifikation bis zu den durchgeführten Tests ist die Entwicklungsdokumentation vollständig vorhanden und ein Audit hat die Korrektheit bestätigt.

Diese Bibliothek mit dem Namen »SafeTcore« ist mit Beispielapplikationen und Benutzerhandbuch erwerbbar. Verschiede Lizenzmodelle treffen die Anforderungen von Vorentwicklungen über Kleinserien bis hin zu Mengenprodukten. Zur preisgünstigen frühen Evaluierung ist ein »SafeTkit« von Hitex verfügbar, ausgestattet mit einer auf das beigelegte Board limitierten SafeTcore-Bibliothek, einer Beispielapplikation und den nötigen Entwicklungswerkzeugen (einschließlich einem Compiler von Tasking als Evaluierungsversion und dem Debugger »HiTOP« von Hitex mit ausreichender Codegröße). Dadurch lässt sich die Beispielapplikation modifizieren und sogar die SafeTcore-Bibliothek in die eigene Applikation einbinden.

Damit soll eine Plausibilitätsprüfung schnell und preiswert möglich sein. Eine andere Möglichkeit des Einstieges in das Sicherheitskonzept und in die Prüfung der Realisierungs-möglichkeit im Kundenprojekt ist durch einen Trainings- beziehungsweise Consulting-Tag eines Experten von Hitex vor Ort gegeben. Das Ergebnis hieraus kann außer der Machbarkeit des Projektes auch eine Aufwandsabschätzung für das Projekt sein. Für Modifikationen und die Einbindung in die Applikation des endgültigen Systems werden Entwicklungsdienstleistungen von erfahrenen SafeTcore-Entwicklern angeboten.

Eine sinnvolle Aufgabenverteilung zwischen Eigenentwicklung und Beauftragung an Hitex lässt sich durch den vorausgehenden Consulting-Tag realistisch definieren.Für die endgültige Zertifizierung können die notwendigen Dokumente wie Fehleranalyse (FMEDA), Safety-Konzept, Common-Cause-Analyse, Failure-Tree-Analyse und der Beweis der Diagnose-Coverage in einem Audit diskutiert werden.

Über den Autor:

Dr. Kurt Böhringer beschäftigt sich als Head of Technology & Innovation bei Hitex Development Tools unter anderem  mit den zukünftigen Herausforderungen in der Embedded-Entwicklung.

Safety Integrity Level
High Demand Rate (gefährliche Fehler pro Stunde)
Low Demand Rate (Wahrscheinlichkeit eines Fehlers pro Anforderung)
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
Tabelle 1: Anforderungen an die Fehlerwahrscheinlichkeit für die verschiedenen SIL-Level