Designpraxis Funktionale Sicherheit in der Praxis – Teil 2

Reale Projektplanung in funktionaler Sicherheit
Reale Projektplanung in funktionaler Sicherheit

Im ersten Teil dieses Projektes (Elektronik Heft 1/2013) wurden die Anforderungen der Standards an Embedded-Systeme, die Auswirkungen auf den Entwicklungsprozess und die Möglichkeiten, Fehler zu reduzieren, dargestellt. Hieraus folgend sollen nun die Aspekte der Planung eines realen Projektes bezüglich Funktionaler Sicherheit erläutert und die Vor- und Nachteile verschiedener Lösungen abgewogen werden.

Bisher war es üblich, zweikanalige Systeme zu verwenden, d.h. die sicherheitsrelevanten Teile eines Systems wurden doppelt ausgelegt, und ein Vergleich der Funktionen beider Kanäle konnte die Fehlfunktion eines der beiden erkennen. Wird daraufhin das System schnell genug in einen sicheren Zustand geführt, so gilt das System als sicher. Dies wird mit der Kennung 1oo2 (one out of two) bezeichnet; der Ausfall eines der beiden Kanäle führt zum Erkennen des Fehlers und zum sicheren Abschalten. Wird beim Ausfall eines Systems das sichere Weiterfunktionieren erwartet, wird das mit 2oo2 bezeichnet, dies wird aber in diesem Artikel nicht betrachtet.

Ist der Mikrocontroller Bestandteil der sicherheitsrelevanten Funktion, so ist in diesem Fall auch dieser zu verdoppeln. Wird der gleiche Mikrocontroller mit der gleichen Firmware genutzt, so hilft dies statistische Fehler zu erkennen; systematische (Design- oder Spezifizierungsfehler in Hardware und Software) werden dadurch nicht erkannt. Nimmt man zwei verschiedene Mikrocontroller mit zwei verschiedenen Programmen, so werden auch solche systematischen Fehler erkannt; man hat allerdings den Aufwand von zwei Entwicklungen, zwei Entwicklungsumgebungen sowie die Bauteilekosten und die Leistungsaufnahme von zwei Mikrocontrollern. Allerdings sind die Anforderungen an den Entwicklungsprozess deutlich geringer.

Dies gilt es abzuwägen. Da eine Entwicklung nach den Sicherheitsstandards um den Faktor 2 bis 4 aufwendiger ist als eine herkömmliche Entwicklung, scheint das zweikanalige System aus Sicht der Entwicklung günstiger zu sein, da nur die Bauteilekosten und der Energieverbrauch höher sind.

Existieren fertige Software-Pakete, die mit den integrierten Sicherheitsfunktionen in Hardware die fehlerfreie Funktionsweise des Mikrocontrollers beweisen, so wird die Entscheidung eher zu den einkanaligen Systemen tendieren. Sind diese Software-Pakete nach den Standards entwickelt und praxisbewährt, so können diese den erhöhten Entwicklungsaufwand bei dem Projekt reduzieren und man spart die doppelte Hardware und Software.

Die Qual der Wahl des Mikrocontrollers

Zu den schon sehr umfangreichen Auswahlkriterien wie Peripherie, Speicher, Rechenleistung, Leistungsaufnahme, Preis, Skalierbarkeit und Verfügbarkeit kommen aus Sicht der Funktionalen Sicherheit noch weitere hinzu.

Unabdinglich für den Einsatz eines Mikrocontrollers für ein sicherheitskritisches System nach den Standards sind die Entwicklung des Mikrocontrollers entsprechend den vorgeschriebenen Entwicklungsprozessen mit der entsprechenden Dokumentation und die Fehleranalyse (FMEDA). Ist dies nicht vorhanden, so wird ein Einsatz sehr fraglich. Selbstredend sind diese Dokumente nur von den Chipherstellern selbst erstellbar.

Ein weiterer wichtiger Punkt ist die Verfügbarkeit der Fehleranalysen in Hardware oder Software oder einer Kombination davon. Hier haben die Chiphersteller teilweise verschiedene Ansätze; manche bevorzugen mehr Hardware, andere mehr Software. Der Nutzen der Zeitersparnis für den Anwender ist aber nur dann vorhanden, wenn beides zusammenspielt und vollständig vorhanden ist. Manche Mikrocontroller werden mit ihren aufwendigen Hardware-Sicherheitsfunktionen beworben, was schon ein wichtiger Schritt in Richtung Funktionaler Sicherheit ist; wenn allerdings dazu die Software fehlt, die nun beim Startup, beim Herunterfahren und während der Laufzeit auf eventuell erkannte Hardware-Fehler richtig reagiert, so erhöht dies wieder den Entwicklungsaufwand und das Risiko, eine Zertifizierung nicht zu bestehen.

Hat man einen passenden Mikrocontroller mit diesen Safety-Umrandungen ausgewählt, so ist es sehr hilfreich, wenn man für ein anderes Projekt mit unterschiedlichen Applikationsanforderungen ein anderes Derivat findet, für das die Sicherheitsentwicklung leicht angepasst werden kann. Gerade die Skalierbarkeit kann also sehr wichtig werden.

Das Wiederverwenden von bestehenden Systemen

Für viele Entwickler, die vor der Herausforderung stehen, Funktionale Sicherheit nach einem Standard wie der IEC-Norm in ihren Projekten zu verwirklichen, stellt sich nun die Frage, eine neue Mikrocontroller-Architektur zu verwenden oder zu untersuchen, ob doch auf bestehende Systeme aufgesetzt werden kann. Oft wurde viel Aufwand investiert, um Software und Hardware auf die Anwendung abzustimmen. Eine Neuentwicklung des gesamten Systems, um erweiterte Anforderung an die Funktionale Sicherheit zu erfüllen, sprengt zuweilen die finanziellen Möglichkeiten. Um bestehende Hard- und Software weiter zu verwenden, gibt es zum einen die Möglichkeit einer „Proven in use“-Argumentation. Dabei wird durch Auswertung von Fehlern und Rückläufer-daten eine Beweisführung angetreten, um die Eignung für Funktionale Sicherheit nachzuweisen.

Sollte diese nicht möglich sein, bieten Mikrocontroller-Architekturen wie die XC2000-Familie von Infineon die Möglichkeit, bestehende und neue Systeme auf Funktionale Sicherheit abzustimmen.

Systemlösung

Hierfür wird ein Safety-Paket aus Hardware, Software und Dokumentation benötigt. Weiterhin benötigen im Allgemeinen alle Safety-Systeme einen weiteren Baustein, einen Watchdog, der den sicherheitskritischen Pfad kontrolliert.

Bei der Hardware im 16-bit-Mikrocontroller-Bereich bietet die XC2000-Familie vier untereinander kompatible Ausprägungen: Die XC2200-Familie für Automotive-Body-Applikationen, die XC2700-Bausteine für Powertrain-Anwendungen, die XE166-Familie mit den Funktionen für Indus-trieanwendungen und zu guter Letzt die XC2300-Familie mit ihrem speziellen Safety-Fokus. Für Systeme, die in Zukunft der IEC 61508 oder der ISO 26262 genügen müssen, ist die XC2300-Familie also die richtige Wahl (Bild 1).

Bei der Hardware wird auf den mittlerweile mit mehr als 600 Millionen Stück verkauften C166V2-Cores mit 5-stufiger Pipeline und Speicherschutzeinheit (MPU) gesetzt, der ständig weiterentwickelt wurde und der sich seit vielen Jahren im Einsatz für verschiedenste System befindet.

Neben einer sehr breiten Skalierbarkeit von 64 KB bis 1 MB integriertem Flash-Speicher, Taktfrequenzen von 40 bis 128 MHz und einer Vielzahl an Gehäusen (38-144 Pin VQFN und LQFP) bietet die Familie bereits viele Safety-Merkmale, die auch in Multicore-Produkten zu finden sind. Dazu gehört u.a. die Absicherung aller Speicher (RAM und Flash) mit Error Detection Code und Error Correction Code (EDC und ECC). Weiterhin verhindert die MPU unerlaubte Speicherzugriffe. Zusätzlich erlaubt eine CRC-Hardware (Cyclic Redundancy Check), auch größere Speicherbereiche auf Fehler hin zu überprüfen. Bei Schnittstellen und -Peripheriebestandteilen wurde auf redundante Auslegung Wert gelegt.

Bei den 10-/12-bit-A/D-Wandlern sind meist zwei parallele Instanzen vorhanden, die 3,3- und 5-V-Spannungen vertragen. Diese können parallel eingesetzt werden; damit prüft ein Wandler den anderen. Weiterhin können sie durch eine Broken Wire Detection prüfen, ob die Kontakte noch richtig angeschlossen sind.

Das USIC-Modul kann die Kommunikation über SPI, UART und I²C übernehmen und besitzt einen Datenpuffer. Durch die multiplen USIC-Instanzen kann beispielsweise ein gesendetes Signal durch ein paralleles Modul wieder rückgelesen werden, um eventuelle Fehler zu detektieren. Beim CAN wird auf die bewährte MultiCan-Technologie gesetzt und auch ein FlexRay-Modul ist verfügbar. Weiterhin kann unter einer Reihe von Timern gewählt werden. Hier ist zum Beispiel die PWM-Einheit CCU6 (Capture Compare Unit) mit GPT12 (General Purpose Timer) zu nennen, die speziell auf die sichere Ansteuerung von Elektromotoren ausgelegt sind.

Funktional (un-) abhängig

Bei der Software kann zuerst zwischen funktional unabhängiger sicherheitskritischer Software und funktional abhängiger sicherheitskritischer Software unterschieden werden. Der funktional unabhängige Teil ist für die Absicherung des Mikrocontroller an sich, unabhängig von der Anwendung, verantwortlich. Dies beinhaltet einen Software-basierenden Selbsttest und einen Treiber, der alle Hardware-Safety-Mechanismen verwaltet und eventuell auftretende Probleme der Applikation melden kann, die zyklischen Tests terminiert und weiterhin die notwendige Kommunikation mit dem externen Watchdog übernimmt. Diese Software ist für den XC2300 unter dem Namen PRO-SIL SafeTcore erhältlich. Der PRO-SIL SafeTcore übernimmt aber nicht nur die funktional unabhängige Sicherheit, sondern unterstützt auch den funktional abhängigen Teil, der aus der Anwendung selbst erfolgen muss.

Um die extrem geringe Anzahl unerkannter Fehler, wie sie die IEC 61508 verlangt, zu erreichen, ist in sicherheitskritischer Anwendungs-Software eine redundante Berechnung erforderlich. Durch Umwelteinflüsse wie zum Beispiel radioaktive Strahlung ist es möglich, dass sogenannte Bit-Kipper dazu führen, dass sich der Core verrechnet. Bei einem Einkanal-System wie dem XC2300 ist es daher notwendig, Berechnungen zu verifizieren. Hierzu gibt es zwei Möglichkeiten: Der Code wird zeitlich versetzt redundant ausgeführt und das Ergebnis danach verglichen oder man erstellt einen zweiten, weniger genauen und komplexen Code, der überprüft, ob das Ergebnis im richtigen Bereich liegt. Dafür wird auch ein Vergleichsmechanismus benötigt. Der SafeTcore bietet auch hierfür eine Schnittstelle, um die Ergebnisse zu vergleichen und auf falsche Berechnungen zu reagieren. Weiterhin existiert auch noch ein Task Scheduler, der verhindert, dass Applikationen zu viel Zeit benötigen, was auch auf einen Fehler hinweisen würde.