Safety-Features in Hardware MCU macht sicher

Sowohl der Gesetzgeber als auch Normungsgremien legen bei medizinelektronischen Geräten zu Recht hohe Maßstäbe an die funktionale Sicherheit (Safety). Um diese Standards zu erreichen, genügt es nicht nur, gute Software zu schreiben. Auch die Hardware muss entsprechende Features aufweisen, damit Fehlfunktionen nicht fatal enden.

Schon heute gibt es sowohl in Europa als auch weltweit unzählige Normen und gesetzliche Vorschriften, die sich mit der Entwicklung medizinischer Geräte befassen. Dazu zählt die IEC 60601, welche die allgemeinen Anforderungen für die Grundlagen der Sicherheit und Leistungsfähigkeit für medizinische Geräte sowie die dazugehörigen Normen definiert, welche die Anforderungen für spezielle Anwendungen festlegen. Die Softwareentwicklung für medizinische Geräte wird von IEC 62304 abgedeckt, wobei der Hersteller eines medizinischen Gerätes sein Gerät in Bezug auf das Gefährdungspotenzial für den Benutzer klassifizieren muss.

Die IEC 62304 teilt Software in drei einfache Klassen ein:

  • Klasse A: Verletzungen oder Gesundheitsschäden sind nicht möglich.
  • Klasse B: leichte Verletzungen sind möglich.
  • Klasse C: tödliche oder ernsthafte Verletzungen sind möglich.

Die Durchsetzung von Standards verbessert die Sicherheit der Geräte, stellt jedoch erhebliche zusätzliche Anforderungen sowohl an den Entwickler als auch an die Bausteine, die in den medizintechnischen Produkten zum Einsatz kommen.

Entwickler von medizinischen Geräten müssen eine zusätzliche Analyse möglicher Fehler und Fehlerzustände erstellen und zudem den erheblich gestiegenen Anforderungen einer detaillierten Dokumentation bei jeder Produktentwicklung nachkommen.

Aufgrund dieser Anforderungen entwickeln Mikrocontrollerhersteller Bausteine mit neuen Funktionen, um Entwickler bei der Erfüllung dieser Anforderungen zu unterstützen.

Ein Beispiel dafür ist der »RX210«, eine Familie von 32-Bit-CISC-Mikrocontrollern (Bild 1) von Renesas.

 

Mit Fehlern richtig umgehen

Wenn es um Sicherheit und Zuverlässigkeit in einem Mikrocontroller-gestützten Design geht, muss man bei der Entwicklung eine Reihe von Punkten berücksichtigen. Dabei sollten die Auswirkungen von Fehlern außerhalb des Mikrocontrollers sowie in seinem Inneren beachtet werden. Solche Fehler können vom Ausfall externer Sensoren und Schnittstellen bis zum extrem seltenen Fall von Defekten im Inneren des Bausteins, wie etwa Ausfälle des CPU-Kerns oder Fehler im integrierten Speicher oder an den I/O-Kanälen, reichen.

Die Tabelle führt einige der jetzt im RX210 enthaltenen Sicherheitsfunktionen auf. Für jeden dieser Fehlertypen muss der Designer eine Strategie entwickeln. Dabei geht es nicht nur um die Erkennung des Fehlers, sondern auch um eine genau festgelegte Methode zum sicheren Umgang mit dem Ausfall, damit ausgeschlossen werden kann,  dass dieser den Benutzer schädigen kann. Entscheidend ist dabei, den CPU-Kern zu berücksichtigen; hier gibt es zahlreiche Methoden, um die Zuverlässigkeit der CPU und des von ihr ausgeführten Codes zu verbessern. Mit einem Interrupt für undefinierte Befehle lässt sich die Ausführung von illegalem Code erkennen.

Über einen solchen Interrupt kann man auch Befehlszugriffe auf unerwartete Speicherbereiche ermitteln, indem leere Speicheradressen mit nicht definierten Befehlen beschrieben werden. Durch Implementieren mehrerer Watchdog-Timer (WDT) über unterschiedliche Clock-Ressourcen lassen sich mehrere Taktsignale am Baustein nutzen - was oft bei Low-Power-Anwendungen wichtig ist -, ohne die Gefahr, dass sich die Taktquelle für den Watchdog-Timer ändert. Damit entfallen auch mögliche Risiken, die bei solchen Veränderungen auftreten können.

Der Einsatz unabhängiger Oszillatoren für den Watchdog-Timer zusammen mit Window-Funktionen (Zeitfenster), die erkennen, ob das Refresh-Signal für den Watchdog-Timer zu früh oder zu spät auftritt, bietet zusätzliche Sicherheit. Um die CPU auf Integrität hin zu überprüfen, sind auf ihr viele weitere Testroutinen regelmäßig auszuführen. Zusätzliche Routinen ermöglichen eine individuelle Funktionsprüfung der wichtigsten Systemregister, wie etwa des General-Purpose-Registers, des Akkumulators (der für Multiply/Accumulate und andere DSP-Funktion verwendet wird), des Interrupt-Tabellenregisters, des User-Stack-Pointers, des Interrupt-Stack-Pointers, des Static-Base-Registers, des Program-Counter-Registers (PC) sowie des Status-Registers.

Besonders wichtig ist außerdem die Schnittstelle zur Außenwelt: Peripheriefunktionen für den Integritätstest der Verbindung zur Außenwelt sind ebenfalls entscheidend. Dabei geht es einerseits um die physikalische Integrität und andererseits um die Bewertung der Zuverlässigkeit der eigentlichen Messergebnisse. Der RX210 bietet Rücklesefunktionen an den digitalen I/O-Pins, mit denen der Anwender die Integrität der an den Pins ausgegebenen Daten überprüfen kann, wenn der Pin von außen angesteuert wird. Dadurch lassen sich Diskrepanzen ermitteln und vom Baustein mithilfe der CPU handhaben. Auch der A/D-Wandler (ADC) bietet eine Reihe unterschiedlicher Funktionen, um die Zuverlässigkeit zu verbessern.

Diese überprüfen den ADC-Betrieb und bestätigen die Zuverlässigkeit der gemessenen Ergebnisse. Der Datenwandler besitzt an jedem Pin automatisch selektierbare Vorlade- und Entlade-Schaltungen, mit denen sich am Pin Unterbrechungen erkennen lassen. Daneben enthält der ADC externe Spannungsreferenzen, die sich nicht nur messen lassen, sondern die auch zusammen mit jedem erfassten Abtastwert gemessen und abgespeichert werden können. So kann der Anwender zusammen mit jedem erfassten Abtastwert Test-daten sammeln, um die Messgenauigkeit laufend zu ermitteln.

Daten korrekt hin- und herschieben

Viele der Peripherieschaltungen im RX210 hat Renesas flexibel ausgelegt, wobei die meisten Funktionen nicht in Hardware verdrahtet wurden, sondern der Entwickler muss sie erst zusammenschalten, um das gewünschte Ergebnis zu erzielen. In einem solchen Fall müssen zunächst einmal einige der für diesen Zweck einsetzbaren Funktionen genauer betrachtet werden. Die wichtigste dieser Funktionen ist der Data-Transfer-Controller (DTC). Der DTC bietet im Wesentlichen die gleiche Funktion wie der bekanntere DMA-Controller (Direct Memory Access), weil er dafür konzipiert ist, eine durch ein Ereignis am Chip ausgelöste Übertragung eines oder mehrerer Bytes zwischen dem Speicher und einer Peripherieschaltung oder umgekehrt zu ermöglichen.

Ein DTC lässt sich jedoch wesentlich kostengünstiger implementieren und ist erheblich flexibler als ein DMA-Controller, weil er viel mehr Funktionen als dieser besitzt. Der Data-Transfer-Controller kann auch mit einem eigenen, dedizierten Bus und unabhängig von der CPU arbeiten. Der DTC ist weniger ein großer, spezialisierter Hardwareblock sondern vielmehr eine Hardwareeinheit auf der Basis einer programmierbaren Tabelle und enthält seine Konfigurationsinformationen in einem kleinen, integrierten SRAM-Block.

Damit eignet sich der Data-Transfer-Controller nicht nur dafür, ein oder zwei Datentransfer-Kanäle zu erstellen, sondern bei Bedarf auch für zehn oder zwanzig Kanäle. Außerdem lässt sich der DTC in einer Reihe von Betriebsarten nutzen. Er kann bis zu 256 Mal ein oder mehr als ein Byte zwischen einer Peripherieschaltung und dem Speicher oder umgekehrt übertragen (Bild 2).

Die Adresse im Speicher kann die gleiche Adresse sein, oder sie lässt sich hoch- oder herunterzählen, sodass dabei eine Pufferstruktur entsteht. Am Ende der Übertragung kann der Data-Transfer-Controller ein Interrupt erzeugen, um der CPU mitzuteilen, dass die Daten bereitstehen. Alternativ kann der Interrupt auch einen zweiten DTC-Transfer anstoßen. Diese Funktion lässt sich bei Bedarf für die Verkettung einer bestimmten Anzahl von Transfers verwenden.

Diese Verkettungsfunktion ist besonders nützlich, um komplexe Abläufe zu erstellen, die im Hintergrund ohne CPU-Beteiligung ablaufen. Ein March-X-Test zur Überprüfung des integrierten SRAMs ist ein gutes Beispiel dafür. Der Data-Transfer-Controller lässt sich auch in einen Repeat-Modus versetzen, in dem er eine Datenübertragung für eine bestimmte Zeit wiederholt.

Automatisch Speicher checken

Der DTC lässt sich auch zusammen mit dem auf dem Chip integrierten CRC-Modul (Cyclic Redundancy Check) verwenden. Damit lässt sich eine Funktion erstellen, die den On-Chip-Datenspeicher automatisch überprüft. Diese Funktion kann im Hintergrund ablaufen, während die CPU normal arbeitet, um die Integrität des Programmspeichers in regelmäßigen Zeitabständen zu kontrollieren.

Auch eine zweite Peripherieschaltung, der Data-Operation-Circuit (DOC), lässt sich zusammen mit dem DTC einsetzen, um eine Reihe von Testfunktionen speziell für die Integritätsüberprüfung des On-Chip-Daten-SRAM zu ermöglichen (Bild 3). In diesem Fall lässt sich der Ablauf nicht komplett im Hintergrund verwalten, da der SRAM-Inhalt durch den Test zerstört würde. Hier sind vor einem Speichertest die Daten sorgfältig zu überwachen und an einem anderen Ort zu speichern. Der DOC kann zwei Datensätze miteinander vergleichen und einen Interrupt ausgeben, wenn die Daten übereinstimmen oder aber nicht übereinstimmen.

Im March-X-Test wird der DTC dazu verwendet, einen bestimmten Wert - zum Beispiel HexAA - in den zu überprüfenden SRAM-Block zu kopieren. Diese Daten werden dann über den DTC wieder in den DOC zurückgelesen und automatisch mit den erwarteten Daten verglichen. Stimmen die Daten nicht überein, dann wurde ein Fehler gefunden, und ein Interrupt erzeugt. Darüber hinaus enthält die RX210-Produktfamilie viele weitere Standardfunktionen, um die Systemzuverlässigkeit zu verbessern, zum Beispiel Brownout-Schutzschaltungen oder Clock-Accuracy-Check-Module (CAC) (siehe Tabelle).

Über den Autor:

Craeme Clark ist Product Marketing Specialist in der Industrial Business Group bei Renesas Electronics Europe.

Hardwaremodule
Zweck
Vorteile für die funktionale Sicherheit der Software
unabhängiger Watchdog (Zeitfenster, Reset)
CPU-Test, Kontolle des Programmablaufs
erkennt jegliche Softwarefehler und Aufhänger; zuverlässiges und sehr schnelles Zeitschlitz-Monitoring
Schreibschutz für Register
vermeidet Softwarefehler
sichert eine zuverlässige MCU-Konfiguration
CAC (Clock frequency Accuracy measurement Circuit)
Clock-Test
erkennt falsche Taktfrequenzen; keine externen Komponenten nötig; erkennt Taktabweichungen; zuverlässiges Zeitschlitz-Monitoring
Oszillatortakt-Stopp-Erkennung
erkennt jegliche Taktstopp-Situation
bringt die CPU schnell in einen sicheren Status oder nutzt die interne Taktversorgung; generiert bei Bedarf einen »warmen« Reset
ELC (Event Link Controller)
kompletter MCU-Selbsttest
deterministischer Zustandsautomat und Scheduler testet schnell die CPU; bringt CPU mit deterministischen Verhalten in einen sicheren Zustand
Event Link Controller
Flash-Test
sehr schneller und zuverlässiger Flash-Test, der die CPU wenig belastet; garantiert eine zuverlässige Kommunikation; testet den gesamten Flash-Speicher im Hintergrund, ohne die CPU zu unterbrechen
DOC (Data Output Control)
RAM-Test
Hardware-Implementierung der March-X- und -C-Algorithmen; sehr geringe Prozessorlast; periodischer Test einfach durchzuführen
Temperatursensor auf dem Chip
MCU-Fehler
erkennt jegliche Hardwarefehler und unnormale Temperaturen des Chips und des Systems
LVD (Low Voltage Detector)
verhindert jegliche Fehler
Ausfallsicherung einfacher auszuführen; Vorhersage von Fehlfunktionen; Software-Reset verfügbar
Selbstdiagnose des A/D-Wandlers
Glaubwürdigkeitstest
kein externer Widerstand nötig; kürzere Stückliste
POE (Port Output Enable)
erkennt falsche PWM sowie Umrichterfehler
gewährleistet die funktionale Sicherheit von Umrichter, Brückenschaltung und Last; legt die PWM-Signale auf hohe Impedanz nach Hardware-Trigger; vermeidet Überhitzung von Motoren wegen blockiertem Rotor, etc.