ARM erweitert MCU-Core für sicherheitskritische Anwendungen
Fehlertoleranter Cortex-M3
Fortsetzung des Artikels von Teil 2
Fehlertoleranter Cortex-M3
Die Ariane-5-Rakete hatte einen redundanten Navigations-Controller, leider führte dieser jedoch dieselbe fehlerhafte Software aus wie der Master. Yogitechs fRCPU kann diverse Software- Fehler erkennen, primär wurde das System jedoch für die Hardware- Fehler-Erkennung designt.
Der Cortex-M3 wird im Jahr 2009 seinen Siegeszug im MCU-Markt antreten. NXP, STMicroelectronics und Luminary Micro haben ihn bereits lizenziert und werden zahlreiche Derivate auf den Markt bringen. Durch die Yogitech-faultRobust-Technologie dürften seine Zielmärkte auch in die Bereiche Automotive, Medizin und Militär ausgedehnt werden. Überraschenderweise hat ARM bis heute keine Ankündigung gemacht, die Yogitech- Technologie auch in den Cortex- R4F zu übernehmen, den ARM im Jahr 2006 ja gerade wegen seiner höheren Rechenleistung für die Automobilindustrie eingeführt hat. Es wäre aber wenig überraschend, wenn dies in naher Zukunft passieren würde.
Jobangebote+ passend zum Thema
Literatur
[1] Website von Yogitech:
www.yogitech.com
[2] Informationen über den Cortex-M3 Release 2:
html>www.arm.com/products/CPUs/ARM_Cortex-M3.html
Dipl.-Ing. Frank Riemenschneider
ist verantwortlicher Redakteur der Elektronik für Mikroprozessoren, Mikroelektronik und Leistungselektronik.
friemenschneider@elektronik.de
Verbesserungen bei Release 2 des Cortex-M3
Der Cortex-M3 wurde designt, um den weitverbreiteten aber veralteten ARM7TDMICore zu ersetzen; er wurde bisher von mehr als 20 Firmen lizenziert. Vor zwei Jahren bot Luminary Micro die erste 32-bit-MCU für unter einen US-Dollar an. Nach wie vor ist es der einzige ARM-Core, der im Hinblick auf eine maximale Codedichte ausschließlich den ARMv7-M-Befehlssatz (16-bit-Thumb- und Thumb-2-Anweisungen) unterstützt. Die maximale Taktfrequenz wurde bei Release 2 von 190 MHz auf 250 MHz angehoben (bei Nutzung eines 90-nm-CMOS-Prozesses). Bislang konnte sich der Entwickler nur entscheiden, die Dubug-Logik komplett oder, wenn sie die gewünschte Chipgröße überstieg, gar nicht zu nutzen. Mit Release 2 wurden Flexibilität und Konfigurierbarkeit erheblich erweitert: Der Designer kann nun eine bis vier Ebenen von Daten-Watchpoints und zwei bis acht Ebenen von Hardware- Breakpoints auswählen.
Ein ebenfalls neuer Wake-Up-Interrupt-Controller (WIC) ermöglicht einen Extrem-Energiesparmodus, in dem alle Taktsignale des Prozessors abgeschaltet werden. Der WIC ist mit dem bereits existierenden NVIC (Nested Vectored Interrupt Controller) verbunden und unterstützt eine konfigurierbare Anzahl von Interrupts, die pro Interrupt nur 50 Gatter kosten. Der WIC kann zwischen kritischen Interrupts, bei denen der Prozessor geweckt werden muss, und unkritischen unterscheiden. Da der Prozessor selbst die Interrupts nicht überwachen muss, werden durch den WIC sowohl die dynamische Leistungsaufnahme als auch die Leckströme reduziert. Da der Prozessor im Schlaf alle Zustände bewahrt, kann er innerhalb von zwölf Taktzyklen aufwachen und mit der Verarbeitung der Interrupt-Service-Routine beginnen.
Beispielhaft wird dies für einen ABS-Controller betrachtet. Dabei wird angenommen, dass ein CPU-Register einen falschen Wert enthält. Dies kann durch einen Hardware-Defekt auf Transistor-Ebene oder sogar durch einen Soft-Error, der z.B. durch kosmische Strahlung verursacht wird, hervorgerufen werden.
In diesem Fall könnte ein Rad abgebremst werden, wenn es nicht gebremst werden soll oder umgekehrt: In jedem Fall würde eine gefährliche Situation heraufbeschworen. Yogitechs frCPU würde in diesem Fall einen fehlerspezifischen Alarm auslösen, der dazu führt, dass das System den Bremsen-Aktor in einen sicheren Zustand überführt und den Prozessor entweder zurücksetzt (Reset) oder einen Interrupt generiert.
Selbst wenn der fehlerhafte Zustand bestehen bleibt, könnte das ABS-System in einem sicheren (abgeschalteten) Zustand verbleiben. Bild 6 zeigt beispielhaft einen Aufbau eines solchen Systems.
Gegenüber einer redundanten Lösung mit zwei Cortex-M3 bietet das System einen weiteren Vorteil: Der zweite Cortex-M3 in einem solchen System könnte Fehler des Master- Core erst durch fehlerhafte Daten auf dem konventionellen I/O-Bus erkennen. frCPU überwacht die Signale durch den Cortex-M3-internen Überwachungsport und kann damit Fehler unmittelbar schon dann erkennen, bevor sie auf dem I/O-Bus Auswirkungen haben.
Für die meisten automobilen Anforderungen reicht HFT = 0 aus, es gibt jedoch auch sicherheitskritischere Anforderungen wie eine Drive-by-Wire- Steuerung, bei denen der Ausfall einer kritischen Funktion nicht toleriert werden kann. Um HFT > 0 zu erreichen, müssen mehrere Cores oder Chips redundant völlig unabhängig voneinander arbeiten können (mehrere so genannte „Kanäle“). Logischerweise sind derartige Konfigurationen teurer und benötigen auch mehr Energie. Des weiteren setzt IEC 61508 auch voraus, dass jeder Kanal eine eigene Diagnostik aufweist; es reicht also nicht aus, wenn ein Kanal den anderen überwacht. Yogitechs faultRobust-Technologie kann auch diese Anforderungen erfüllen, indem zwei Cortex- M3-Prozessor-Cores mit zwei fRCPU-Supervisorn gekoppelt werden (Bild 7). Diese Konfiguration kann unterschiedlichste Fehlerszenarien abdecken und von einem Kanal auf den anderen wechseln, Tasks zwischen den einzelnen Kanälen allokieren und dabei die Systemverfügbarkeit aufrechterhalten.
Allerdings ist nicht einmal jedes Zwei-Kanal-System perfekt, wie das Desaster beim Start einer Ariane-5-Rakete im Jahr 1996 zeigte. Eine Minute nach dem Start versuchte der Navigationscomputer, einen 64-bit-Wert in einen 16-bit- Wert zu konvertieren, leider verbockte die Software die Umwandlung. Der Computer missinterpretierte die Fehlermeldung als Navigationsdaten- Eingabe und versuchte über die Ansteuerung der Triebwerke eine unmögliche Kurskorrektur auszuführen. Das Ergebnis: Eine zerstörte Rakete und ein Verlust von vier Satelliten im Gesamtwert von 370 Mio. Dollar.
Der Großteil der Diagnosen beim frCPU-Modul erfolgt hardware-mäßig: Alarme werden unabhängig von der Applikation generiert und es gibt keine Rückwirkungen auf die Rechenleistung der CPU. Implementiert werden nur die für das Erreichen von SIL3 relevanten Leistungsmerkmale, was ein Minimum an Hardware (und damit an Verlustleistung), Verbindungsaufwand und Komplexität ergibt.
- Fehlertoleranter Cortex-M3
- Fehlertoleranter Cortex-M3
- Fehlertoleranter Cortex-M3
- Fehlertoleranter Cortex-M3
- Fehlertoleranter Cortex-M3
