Hausgeräte sicherer machen

Der Elektronik-Abschnitt nimmt Bezug auf eine weitere Norm, nämlich die für automatische elektronische Regelungen in einem breiten Anwendungsfeld geltende IEC 60730. Wichtig für die Entwickler von Embedded-Systemen ist hier speziell der Anhang H, der sich schwerpunktmäßig mit programmierbaren Bauelementen befasst. Mikrocontroller (MCUs) werden in weißer Ware häufig eingesetzt, und nicht selten finden sich sogar mehrere dieser Bauelemente in einem Gerät: während einer für die Benutzeroberfläche zuständig ist, steuern andere die Ventile und Motoren.

Die Norm unterscheidet abhängig von der Gefahr, die mit einem Ausfall verbunden ist, zwischen den drei Softwareklasse A, B und C. Hängt die Sicherheit des Geräts nicht von der Software ab, fällt diese in die Klasse A. Raumthermostate oder Beleuchtungssteuerungen sind Beispiele für diese Kategorie. Wenn am anderen Ende des Spektrums die Software zur Abwendung besonderer Gefahren (zum Beispiel zur Vermeidung von Explosionen in elektronisch gezündeten Gasbrennern) vorgesehen ist, wird sie in die Klasse C eingestuft. Der vorliegende Artikel befasst sich nicht mit der Klasse C, denn die meisten Hausgeräte, deren elektronische Steuerungen einen unsicheren Betrieb verhindern müssen, gehören zur Klasse B. Dies gilt beispielsweise für Waschmaschinen, bei denen die potenziellen Probleme mit den elektronisch gesteuerten Türverriegelungen oder dem Überhitzungsschutz der Motoren zusammenhängen.

Tabelle H.11.12.7 in Anhang H der Norm IEC 60730 listet auf, welche Mikrocontroller-Komponenten geprüft und welche Fehler erkannt werden müssen und welche akzeptablen Maßnahmen es für Software der Klassen B und C gibt. Abgedeckt sind die CPU (Register und Programmzähler), die Interrupts (Behandlung und Exceptions), die Überwachung der Taktfrequenz, Prüfungen an variablem Speicher (RAM) und invariablem Speicher (Flash, EEPROM), externe Kommunikationsfunktionen und die Peripheriefunktionen.

Diese Prüfungen erfolgen erstmals beim Booten des Mikrocontrollers, noch bevor der Start-up-Code des Systems verarbeitet wird. Der Hauptgrund hierfür ist, dass der RAM-Test „destruktiv“ ist, sodass etwaige bereits initialisierte Variablen verfälscht würden.

Was ein RAM-Test abdecken muss

Was muss ein RAM-Test abdecken? Für die Klasse B verlangt die Norm, dass periodisch nach Einzelbit-DC-Fehlern (zum Beispiel Stuck-at- oder Kopplungsfehler) gesucht wird. Da die meisten MCUs der unteren Preisklasse für ihren SRAM-Speicher keine Paritätsunterstützung bieten, muss dieser Test softwaremäßig implementiert werden. March-Algorithmen erkennen diese Fehler mit einer überschaubaren Anzahl an Durchläufen. March C passt ideal und benötigt 10×n Operationen (wobei n für die Zahl der geprüften Speicherstellen steht), jedoch akzeptieren die Prüfinstitute in bestimmten Fällen auch March X (mit 6×n Operationen). Ist der Test abgeschlossen, wird das RAM gelöscht (daher die Bezeichnung destruktiver Test).

Die Durchführung eines March-Tests nach einem Reset wirft keine besonderen Schwierigkeiten auf, und bis auf die Tatsache, dass der Startvorgang geringfügig verlangsamt wird, ergeben sich keine weiteren Nachteile. Angesichts der geringen Größe des RAM ist die Verzögerung meist nicht einmal spürbar.

Wenn die Prüfung jedoch während des Betriebs wiederholt werden muss, kann sie zu einer echten Herausforderung werden. Erstens muss sie transparent gemacht werden. Die Anwendung muss das RAM also ohne ein besonderes Protokoll nutzen können, als wäre kein Test implementiert. In der Praxis bedeutet dies Folgendes:

• Der Test muss als Interrupt Service Routine (ISR) implementiert werden, die mit höchster Priorität behandelt wird. Dies stellt sicher, dass während des Tests kein Zugriff der Applikation auf die Daten erfolgt.
• Es muss ein Pufferspeicher bereitgestellt werden, damit der Inhalt des geprüften RAM-Bereichs zunächst gesichert und nach dem Test wiederhergestellt werden kann, bevor die Applikation ihre Arbeit wieder aufnimmt. Selbstverständlich muss auch dieser Pufferspeicher regelmäßig geprüft werden.

Zweitens darf die Prüfung die Applikation nicht übermäßig lange anhalten. Hierzu wird die Prüfung normalerweise in mehrere Teiltests aufgeteilt, um die Zeit, die auf dieser höchsten Prioritätsebene verbracht wird, zu begrenzen. Dennoch dürfen pro Abschnitt nicht weniger als drei aufeinanderfolgende Speicherstellen getestet werden. Dies ist zwingend notwendig, damit auch Kopplungsfehler abgedeckt werden. Bei einem March-C-Algorithmus bedeutet dies nicht weniger als 30 aufeinanderfolgende Lese- und Schreibzugriffe. Diese Lösung hat sich als effektiv erwiesen und ist in der Industrie heutzutage gängige Praxis. Dennoch hat sie einige Nachteile.

Dies soll jetzt zunächst aus dem Blickwinkel der Downloadentwicklung betrachtet werden. Ohne hier genauer auf die Vorteile der strukturierten Programmierung einzugehen, sei auf die folgenden Einschränkungen dieser Implementierung verwiesen:

• Kapselungsprobleme: Die C-Module müssen einen Teil ihrer internen Variablen global machen, sodass sie nicht mehr von den Sanity Checks erfasst werden, die die Compiler als Mittel gegen modulübergreifende Zugriffe nutzen.
• Schwache Task-Isolation und mangelhafte Modularisierung: Die Teststruktur setzt einen Testzugriff auf jedes sicherheitskritische Softwaremodul voraus und macht das Hinzufügen neuer Features dadurch komplexer.

Höhere Risiken für ein Verfälschen von Daten lassen sich ebenfalls ausmachen, wenn die Wahrscheinlichkeit mit der Zahl der Lese- und Schreibzugriffe verknüpft wird. Abmildern lässt sich dies durch die inverse redundante Speicherung sicherheitskritischer Variablen, jedoch wächst hierdurch die Größe des gemäß Klasse B zu testenden Bereichs.

Was die MCU-Ressourcen betrifft, verbraucht die Implementierung des Tests sowohl ROM als auch RAM und CPU-Bandbreite. Sollte der Prozessorkern den Verarbeitungsaufwand für den Test zusätzlich zu seinem normalen Arbeitsaufkommen zeitweilig nicht bewältigen können, muss der Prüfvorgang während einer rechenintensiven Betriebsphase des Geräts möglicherweise unterbrochen werden.

Erfassung von Koppplungsfehlern

Bild 1: In diesem Schaubild ist dargestellt ist, wie die Software die partiellen RAM-Tests zur Laufzeit handhabt. STMicroelectronics

Schließlich wirkt sich ein zur Laufzeit durchgeführter RAM-Test auf die Echtzeit-Eigenschaften des Systems aus, da andere ISRs möglicherweise verzögert oder unterbrochen werden. Außerdem können Konflikte mit Low-Latency- oder Notfall-Tasks entstehen. Die Länge der Prüfroutine lässt sich nicht beliebig reduzieren, denn zur Erfassung von Kopplungsfehlern muss eine bestimmte Mindestanzahl aufeinanderfolgender Speicherstellen geprüft werden. Die Komplexität nimmt außerdem zu, wenn die Software das Adress-Descrambling koordinieren muss, um der physischen Anordnung des Speichers gerecht zu werden. Bild 1 zeigt, wie die Software die partiellen RAM-Tests zur Laufzeit handhabt.

Die Norm IEC 60730 schlägt eine alternative Lösung auf der Basis eines hardwaremäßigen Paritätsbits vor. Während dies für DRAM-Speicher ein routinemäßiges Verfahren darstellt, ist es für Universal-Mikrocontroller doch recht ungewöhnlich. Allerdings haben höher entwickelte Halbleiter-Prozessknoten dafür gesorgt, dass sich solche Features kosteneffektiver implementieren lassen.

Pro Speicherstelle ein Paritätsbit

Die Lösung besteht darin, pro Speicherstelle ein Paritätsbit vorzusehen. Die Parität wird berechnet, wenn die Speicherstelle beschrieben und zusammen mit den Daten abgespeichert wird. Beim Lesen der Daten wird die Parität erneut berechnet und mit dem Referenzwert verglichen (siehe Bild 2). Im Fall einer Differenz, sei es durch einen Fehler in den Daten oder durch eine unkorrekte Paritätsinformation, wird ein Interrupt- oder Exception-Signal gesetzt. Der Core behandelt den Fehler daraufhin in einer speziellen Sicherheits-ISR und fährt das Gerät geordnet herunter. In einem zweiten Schritt kann der Core die Applikation entweder erneut hochfahren (Warmstart) oder das Gerät mit der Ausgabe eines Wartungs-Codes endgültig deaktivieren.

Bild 2: Die Parität wird berechnet, wenn die Speicherstelle beschrieben und zusammen mit den Daten abgespeichert wird. Beim Lesen der Daten wird die Parität erneut berechnet und mit dem Referenzwert verglichen.STMicroelectronics

Die Vorteile dieser Implementierung liegen auf der Hand. Der Klasse-B-gemäße RAM-Check erfolgt vollkommen transparent.

• Es sind keine Abstriche an den Software-Praktiken erforderlich.
• Es muss keine auf den MCU-Anbieter zugeschnittene Prüfroutine entwickelt werden. Stattdessen reicht eine globale Fehlerbehandlungs-Funktion, die ohnehin vorhanden sein muss.
• Es wird weder eine spezielle RAM-Aufteilung noch ein Linker-Skript benötigt.
• Die CPU-Bandbreite steht in vollem Umfang der Applikation zur Verfügung (die Lese-Latenz des Speichers nimmt durch die Paritätsberechnung nicht zu).
• Es wird ein optimales Echtzeitverhalten erzielt.

Als weiterer Vorteil kommt hinzu, dass beim Hochfahren keine vollständige RAM-Prüfung erforderlich ist. Das Booten geht außerdem schneller, da die Paritätsprüfung unmittelbar nach dem Power-On-Reset aktiv ist.

Schnelleres Booten

In Hausgeräten werden häufig bürstenlose Motoren eingesetzt, was sich aus ihrem hohen Wirkungsgrad, ihrer Laufruhe und ihrer Robustheit erklärt, auch wenn komplexe Regelungen und spezielle PWM-Peripheriefunktionen benötigt werden. Spezielles Augenmerk muss auf den Fehlerschutz und das sichere Abschalten gerichtet werden. Die RAM-Paritätsprüfung sorgt in diesem Fall für mehr Zuverlässigkeit und eine höhere Reaktionsgeschwindigkeit. Anstatt die Sicherheitsabschaltung per Software zu koordinieren, wird das Paritätsfehlersignal direkt an die PWM-Peripherie geleitet. Auf diese Weise lässt sich automatisch eine Notabschaltung auslösen, ohne dass es zu Verzögerungen durch den Systemtakt und die Software kommt. Eine praktische Umsetzung dieses Konzepts ist in Bild 3 zu sehen.

Bild 3: Eine praktische Umsetzung einer RAM-Paritätsprüfung.STMicroelectronnics

Sorgfalt ist auch bei der Beachtung der übrigen kritischen Systemparameter geboten. Ein Stromversorgungs-Überwachungssystem kann beispielsweise so programmiert werden, dass es einen Interrupt auslöst, sobald V_d unter einen programmierten Grenzwert fällt. Ein Clock-Security-System verifiziert ferner, dass der Hauptsystemtakt einwandfrei arbeitet. Auch hier wird bei Abweichungen vom Normalbetrieb ein Interrupt generiert. Der Cortex-Core stellt ferner auf der Chip-Ebene ein Signal zur Verfügung, das gesetzt wird, wenn der Core in einen Lockup-Zustand gerät. Hierzu kann es kommen, wenn ein Fehler in den Hard Fault- oder NMI-Handlern auftritt, oder wenn es während des Bootvorgangs zu einem Busfehler kommt. Diese drei Ereignisse werden zusammen mit der Parität zu einem internen Notabschaltsignal verknüpft, das wiederum mit einer ODER-Funktion mit dem externen Break-Eingang kombiniert wird.

Ausfallsichere Taktschaltung

Die Norm verlangt darüber hinaus nach einer ausfallsicheren Taktschaltung. Diese wird teils mithilfe einer als Clock-Security-System (CSS) bezeichneten Peripheriefunktion realisiert, die den Haupttakt bei einem Ausfall des Quarzes auf einen internen schnellen Oszillator umschaltet. Zusätzlich wird eine Möglichkeit zur Überwachung des externen Takts benötigt. Hierzu wird die erwartete externe Frequenz mit einer internen Frequenz verglichen. Der Echtzeit-Takttimer kann vom internen LSI (Low Speed Internal) RC-Oszillator angesteuert werden, um den Hauptsystemtakt an Hand der Subharmonischen der Quarzfrequenz so genau zu messen, dass sich eine Abweichung um 50 % feststellen lässt. Auf der Systemebene lässt sich auf diese Weise der Aufwand für eine Schaltung einsparen, die die Nulldurchgänge der Netzspannung (50 beziehungsweise 60 Hz) detektiert.

Die Norm schlägt die Verwendung einer unabhängigen Zeitschlitz-Überwachung vor, damit ein Durchgehen der CPU bei einer Fehlfunktion des Programmzählers verhindert wird. Hierfür wird der Watchdog-Timer verwendet, der in den meisten MCUs enthalten ist. Da aber die vollständige Unabhängigkeit dieser Funktion verlangt wird, ist die Cortex-M-basierte STM32-Familie von STMicroelectronics mit zwei Watchdogs ausgestattet: Ein regulärer Window-Watchdog läuft am Haupt-Systemtakt, und ein zweiter Watchdog nutzt einen unabhängigen internen Oszillator und wird mit einem Option-Byte im Flash-Speicher gestartet. Damit ist sichergestellt, dass bei einem Ausfall des Quarzes und ungeachtet der Konfiguration der Taktschaltung mindestens ein Watchdog aktiv bleibt.

Ausgestattet mit zwei Watchdogs

Schließlich ist in den Mikrocontroller eine hardwaremäßige 32-Bit-CRC-Schaltung integriert. Diese beschleunigt die Integritätsprüfung des Flash-Inhalts entscheidend und senkt die damit einhergehende CPU-Belastung (zur Laufzeit) auf ein vernachlässigbar geringes Niveau ab. Diese Peripheriefunktion kann sogar durch den DMA-Controller angesteuert werden, sodass die Flash-Integrität zur Laufzeit als Hintergrundaufgabe geprüft werden kann.

(ah)