Safety für Auto, Industrie und Medizin ARM Cortex-R52 für funktionale Sicherheit

Bereits 2013 stellte ARM seine Architektur ARMv8-R vor, die speziell für sicherheitsrelevante Anwendungen entwickelt wurde. Drei Jahre später erblickt mit dem Cortex-R52 die erste ARMv8-R-CPU das Licht der Welt, bei der vor allen Dingen die deutlich verbesserte Interrupt-Verarbeitung hervorsticht.

Nicht nur die Automobilindustrie braucht immer mehr Rechenleistung für ADAS (Advanced Driver Assistence System) und Benutzerschnittstellen für Infotainment und Navigation – für letztere will man auch noch Software-Bibliotheken aus der Applikations-Welt wiederverwerten können –, auch in der Industrie erlebt man dank smarter Roboter, die mit Menschen zusammenarbeiten, höhere Anforderungen bezüglich funktionaler Sicherheit in Kombination mit CPU-Performance. Auch in der Medizintechnik fordern Operations-Roboter und intelligente Medikamenten-Verteilungssysteme Mensch und Technik. ARM hat mit ARMv8-R eine Mikroarchitektur enwickelt, die Hardware-Virtualisierung, die man aus der Applikations- und Server-Welt schon lange kennt, mit Echtzeitfähigkeit und Sicherheit zusammenführt.

Anders als bei der ARMv8-Architekur, die »nur« zwei Privileg-Modi für Betriebssystem und Anwendungsprogramme kennt, wurde ARMv8-R um eine Privileg-Ebene für einen echtzeitfähigen VMM (Virtual Maschine Monitor) oder Hypervisor erweitert (Bild 1), welcher die Verwaltung parallel z.  B. eines High-Level-Betriebssystems und eines RTOS übernimmt.

Da ARMv8-R im Wesentlichen auf den auf der Applikations-Welt bekannten Architekturen ARMv7/ARMv8-A aufsetzt, ist der Schritt von der Kosumer- in die Embedded-Welt überschaubar – man kann alle Betriebssysteme, die dem 32-bit-A-Profil genügen, laufen lassen – theoretisch sogar Apples iOS und das neben einem RTOS.

Virtualisierung + Echtzeit

Der Ansatz der Virtualisierung ist ja nicht neu. Primäres Ziel ist, eine Abstraktionsschicht zwischen Anwender (etwa einem Betriebssystem) und Ressource (etwa die Hardware, über die ein Betriebssystem üblicherweise exklusive Kontrolle hat) bereitzustellen. Diese erlaubt, andere physische Gegebenheiten vorzugeben als tatsächlich vorhanden: Etwa kann einem Betriebssys¬tem die Alleinnutzung einer Hardware (CPU, Peripherie, Speicher und I/O) vorgegaukelt werden, wobei es tatsächlich innerhalb eines anderen Betriebssystems als reguläres Anwendungsprogramm läuft auf Hardware, die durch die Abstraktionsschicht emuliertert wird. ARM hat bereits 2011 in einem White Paper seine Ideen zur Virtualisierung präsentiert und die sogenannten »Virtualization Extensions« für die ARMv7-Architektur vorgestellt.

Das Problem war bislang, dass die Virtualisierung mit einer Speicherübersetzung von virtuellen in physikalische Adressen verbunden ist, welche z. B. über TLBs (Übersetzungspuffer, Translation Lookaside Buffer) und Page-Tabellen im RAM vorgenommen werden. Dieser Mechanismus ist deswegen nicht echtzeitfähig, weil man beispielsweise nicht vorhersagen kann, ob ein TLB-Miss auftritt.

ARM implementierte daher in seiner neuen Architektur eine MPU-basierte zweistufige Umsetzung: Statt Page-Tabellen im RAM handelt es sich um eine registerbasierte Übersetzung, die natürlich zeitinvariant funktioniert und Determinismus sicherstellt. Die systemweit agierende MPU isoliert auch den Hypervisor und die Gast-Betriebssysteme voneinander (Bild 2, oben). Auf die erste Stufe, die als MMU wirkt und die virtuellen Adressen in sogenannte physikalische Zwischenadressen (IPA) umsetzt, haben noch jedes Gast-Betriebssystem und dessen Anwendungen Zugriff, auf Stufe 2 nur noch der Hypervisor und Gast-Betriebssysteme, denen die Stufe 1 den Durchgriff erlaubt hat (Bild 2, unten). Diese zweite Stufe setzt dann die IPAs in physikalische Adressen um. Somit ist ein physikalischer Speicherzugriff ohne »Absegnung« des Hypervisors unmöglich.