Designpraxis Funktionale Sicherheit in der Praxis - Teil 2

Projekt Funktionale Sicherheit
Projekt Funktionale Sicherheit

Nachdem die Anforderungen der Standards, ihre Auswirkungen und die Fehlerreduktion dargestellt wurden, folgen nun die Aspekte der Planung eines realen Projektes bezüglich Funktionaler Sicherheit. Dabei werden die Vor- und Nachteile verschiedener Lösungen abgewogen.

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 -Mi-krocontrollern. 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 -Mikro-controllers

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 Re-dundancy 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 I2C ü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.