Multicore Sicherheit auf allen Kernen

Autor / Redakteur: Prof. Dr.-Ing. Peter Fromm, Thomas Barth, Mario Cupelli* / Martina Hafner

Da bei Multicore-Controllern die physikalische Kopplung zwischen den einzelnen Kernen deutlich enger ist als bei diskreten Mehrcontrollerlösungen, werden besondere Anforderungen an die Softwarearchitektur, das Speicherlayout, das Betriebssystem und an die Treiberschicht gestellt.

Firma zum Thema

(Bild: ClipDealer)

Dieser Aufsatz zeigt die Herausforderungen und die Herangehensweise bei der Entwicklung einer Safety Architektur für Gabelstaplersteuerungen mit dem Infineon AURIX Multi-Core Baustein TC27x von Infineon unter Verwendung des Betriebssystems PxROS der Firma HighTec. Insbesondere werden die Entwicklung einer sicheren und erweiterbaren Basisarchitektur, das Design einer Multi-Core Laufzeitumgebung und die Anwendung geeigneter Designpattern für die Applikationsentwicklung dargestellt.

Bildergalerie
Bildergalerie mit 6 Bildern

Motivation für den Einsatz von Multi-Core Controllern

Die Entwicklung von Multicore Applikationen ist alles andere als trivial. Die Umstellung von existierendem Code in eine Multicore Architektur setzt in der Regel ein komplettes Redesign der Software Architektur voraus. Die echte Nebenläufigkeit der Core’s kann zu Datenkonsistenzproblemen führen.

Ressourcen wie Speicher und Peripherie müssen konfliktfrei zwischen den einzelnen Core’s geteilt werden. Die Qualifikation von Software und das Debugging von Fehlern werden im Vergleich zu Single-Core Applikationen deutlich aufwändiger. Warum also den Schritt auf den Multicore wagen?

Ein Haupt-Argument ist der Performancegewinn einer Mehrkernarchitektur gegenüber einem Singlecore. Die CPU-Frequenz lässt sich aufgrund der parallel steigenden Leistungsaufnahme und elektromagnetischen Störung nicht beliebig erhöhen. Einen Ausweg bieten hier Multicore Controller, die die parallele Ausführung voneinander unabhängiger Programmteile erlauben.

Ein weiterer interessanter Anwendungsfall von Multicore Architekturen ist der Ersatz von redundanten Mehrcontrollerlösungen durch einen einzelnen Multicore Chip. Solche Architekturen finden sich häufig in Applikationen, die hohen Sicherheitsanforderungen unterliegen, z.B. Maschinensteuerungen, Motorsteuergeräte, Flugzeugtechnologie, um nur einige Beispiele zu nennen.

Bei solchen Architekturen werden die Signalpfade in der Regel mehrkanalig ausgeführt, um eventuelle Fehlfunktionen zu erkennen und das System in einen sicheren Zustand zu überführen. Eine solche vereinfachte mehrkanalige Architektur mit redundanter Überwachungsfunktion ist in Bild 1 der Bildergalerie dargestellt.

Das Eingangssignal wird über einen zweikanaligen Sensor erfasst und einem Regelkreis zugeführt, der ein Ausgangssignal z.B. die gewünschte Drehzahl für eine Maschine berechnet und erzeugt. Gleichzeitig werden die Eingangssignale, die korrekte Berechnung des Ausgangssignals sowie das physikalische Ausgangssignal von zwei unabhängigen Überwachungseinheiten erfasst und geprüft.

Dabei werden aus Sicherheitsgründen häufig unterschiedliche Technologien zur Signalerfassung (z.B. VADC und Sigma-Delta ADC) und unterschiedliche Algorithmen genutzt. Sobald eine Prüfung fehlschlägt, kann das System über eine geeignete Eskalationsstrategie unabhängig von beiden Kanälen in einen sicheren Zustand, z.B. Stillstand, überführt werden.

Um Produktionskosten zu sparen und um die Manipulationssicherheit des Systems zu erhöhen (Wegfall externer Verbindungen zwischen den Controllern), soll eine solche Architektur alternativ mit einem Multicore Controller wie in Bild 2 der Bildergalerie beispielhaft skizziert aufgebaut werden.

Bei der Konzeptionierung einer solchen Lösung ergibt sich eine Reihe von Fragen, die im Folgenden diskutiert werden sollen:

  • Wie ist eine Multicore Architektur aus Sicht der einschlägigen Sicherheitsnormen mit einer diskreten Mehrcontrollerlösung zu vergleichen?
  • Wie kann die zentrale Forderung nach Freedom of Interferance auf einem Multicore Controller sichergestellt werden?
  • Wie sieht eine geeignete Safety Software Architektur auf einem Multicore Controller aus?

Im Rahmen einer Machbarkeitsstudie wurde in Zusammenarbeit mit den Firmen HighTec, Infineon und einem namhaften Maschinenhersteller ein prototypisches Steuergerät für zukünftige Gabelstaplersteuerungen unter Nutzung des 3-Kern Controllers Aurix TC275 der Firma Infineon entwickelt.

Anforderungen an Sicherheitsarchitekturen aus der Normenwelt

Die Entwicklung sicherheitskritischer Systeme unterliegt sehr stark den gesetzlichen Normen. Prominente Vertreter solcher Normen sind z.B. die ISO26262 [1] in der Automobilwelt oder die ISO13849 [2] in der Maschinewelt, auf die sich im Folgenden bezogen wird.

Bei der Entwicklung der Steuerung wird nach [3] ein Entwicklungsprozess empfohlen, der die folgenden Schritte enthält:

  • Risikoanalyse und -beurteilung
  • Identifikation der notwendigen Sicherheitsfunktionen zur Reduzierung des Risikos und Ermittlung des erforderlichen Performance Levels
  • Festlegung der Steuerungsarchitektur
  • Bewertung der Auswirkung von Fehlern und Diagnosemöglichkeiten, Fehlervermeidung
  • Umsetzung fehlervermeidender Maßnahmen im Softwarelebenszyklus
  • Verifikation und Validierung des Gesamtsystems

Aufgrund der möglichen Gefährdungen für die Nutzer eines Gabelstaplers soll die Steuerung für Fahr- und Hebeaktionen dem Performance Level d genügen. Gemäß des Bild 3 in der Bildergalerie lässt sich erkennen, dass sich der gewünschte Performance Level d mit einer Architektur der Kategorie 2 oder 3 erreichen lässt. Bei einer Kategorie 2 Architektur gelten allerdings höhere Anforderungen an den Diagnosedeckungsgrad.

Bezüglich der Hardwarearchitektur unterscheidet die Norm folgende Kategorien: siehe Tabelle 1 der Bildergalerie.

Übertragung der Architekturkategorien auf einen Multicore Controller

Betrachtet man die unterschiedlichen Kategorien aus Tabelle 1, so lässt sich die Struktur eines Multicore Controllers nicht direkt in diese Kategorien übersetzen. Zwar verfügt ein Multicore Controller über unabhängige Rechenkerne, doch der Speicher und auch die Peripheriebausteine können von allen Kernen angesprochen werden.

Zusätzliche Technologien wie Memory Protection Units versprechen hier zwar bei korrekter Konfiguration eine gewisse Separierung, die den Anforderungen der Norm in Bezug auf Maßnahmen gegen Common Cause Fehler aber sehr wahrscheinlich nicht genügen, vor allem die Aspekte Trennung/Abtrennung der Signalpfade, Diversität der Bauteile und Auswirkung von Umweltstörungen erscheinen hier problematisch.

Unabhängig von dieser in Zukunft sicherlich noch zu beantwortenden Frage muss für die Softwarearchitektur gelten, dass ein möglichst hoher Grad an Rückwirkungsfreiheit (Freedom of Interferance) zwischen den einzelnen Applikationen und hier insbesondere zwischen den Logikfunktionen und den Sicherheitsfunktionen zu gewährleisten ist, der sich wie folgt begründet:

  • Die Qualifikation kleinerer Softwareeinheiten mit klaren Schnittstellen ist einfacher und sicherer, als die Qualifikation großer Software-Monolithen. Gerade regelungstechnische Applikationen realisieren den Datenaustausch häufig gerne mithilfe globaler Variablen, deren Datenfluss in der Praxis nur schwer oder gar nicht zu verifizieren ist.
  • Die Auswirkung möglicher (Software)-Fehler wird lokal begrenzt.
  • Sicherheitsfunktionen und normale Funktionen müssen unterschiedlich qualifiziert werden. Eine klare und sichere Trennung ermöglicht es, die Sicherheitsfunktionen und den Applikationsteil einmal nach den jeweiligen Prozessanforderungen zu qualifizieren. Insbesondere bei Änderungen im applikativen Teil der Software kann dieser mit weniger Aufwand requalifiziert werden.

Der Aurix-Microcontroller unterstützt die Anforderung nach „Freedom from Interferance“ sowohl zwischen Software Komponenten untereinander als auch zwischen Software Komponenten und Peripherieregistern. Hierbei werden die Datendomäne, die Zeitdomäne und die Ressourcendomäne unterschieden.

Für den Schutz der Datendomäne (Speicher) wird primär die Memory Protection Unit (MPU) des Aurix verwendet. Zusätzlich steht mit der Bus Memory Protection Unit (BUS-MPU) ein weiteres Instrument zur Verfügung. Während die MPU vom jeweils zugreifenden Prozess angesteuert wird (Task xyz soll auf den Speicherbereich abc zugreifen) und eher dynamisch verwendet werden kann, wird die BUS-MPU aus Sicht der zugegriffenen Ressource konfiguriert (auf den Speicherbereich abc dürfen nur bestimmte Bus-Teilnehmer, z.B. Tasks von einem bestimmten Core zugreifen) und realisiert eher statische Einschränkungen.

Die Zeitdomäne wird primär durch die nebenläufige Ausführung des Codes auf den einzelnen Kernen realisiert. Sobald ein Kern gestartet ist, läuft er unabhängig von den anderen Kernen, solange zumindest keine Spinlocks oder andere blockierende Konstrukte genutzt werden. Zur Absicherung des Laufzeitverhaltens stehen außerdem die üblichen Watchdogs für lokale und ein Safety Watchdog für globale Operationen zur Verfügung.

Der Schutz der Peripherieregister erfolgt ähnlich wie der Speicherschutz über die Memory Protection Unit bzw. die Register Access Protection (RAP, funktional vergleichbar der BUS-MPU). Da die MPU 8 byte aligned ist, können damit nur komplette Module gesichert werden, für einzelne Pins reicht die Granularität häufig nicht. Die RAP bezieht sich immer auf komplette Peripheriemodule und erlaubt keine weitere Unterteilung. Diese Einschränkungen sind beim Hardwarelayout zu berücksichtigen. Darüber hinaus stehen neben dem Supervisor Mode zwei Usermodes zur Verfügung, die den Zugriff auf die Peripherie beschränken.

Basissoftware / Betriebssystem PxROS

Nach dem Booten des Aurix sind alle Sicherheitsmechanismen deaktiviert. D.h. die Applikation muss den Zugriff bewusst einschränken, um bestimmte Ressourcen zu schützen. Da diese Konfiguration aus naheliegenden Gründen nicht über die Applikation erfolgen soll, wurde das Betriebssystem PxROS der Firma HighTec ausgewählt. Bei PxROS handelt es sich um ein zertifiziertes Multicore Betriebssystem, das die Hardwarefeatures des Aurix optimal unterstützt:

  • Einzelne Tasks können dynamisch verschiedenen Cores zugewiesen werden.
  • Die Taskkonfiguration enthält sämtliche Zugriffsrechte auf Speicher und Peripherie, die damit automatisch für die Applikationssoftware gelten, die im Kontext dieses Tasks ausgeführt wird.
  • Der Datenaustausch zwischen den Tasks erfolgt über non-blocking Events und Messages. Dieses erfolgt unabhängig vom Core, auf dem der Task physikalisch läuft. D.h. die Zuordnung der Tasks auf die Hardware kann rekonfiguriert werden, ohne dass der Applikationscode geändert werden muss.

Architekturkonzept

Bild 4 in der Bildergalerie zeigt schematisch die Partitionierung der Gabelstaplersteuerung. Alle Sicherheitsfunktionen sowie die von den Sicherheitsfunktionen benötigten Peripherietreiber werden auf Core 0 ausgeführt, der nach einem Reset per Hardware gestartet wird. Sobald alle Sicherheitsfunktionen laufen, startet Core 0 die Reglerapplikationen auf Core 1 und die Komfortfunktionen auf Core 2 sowie die dazugehörenden Treiber.

Die blauen Boxen repräsentieren jeweils eine Applikation, die einem Task mit definierten Ressourcen zugewiesen wird. Die Kommunikation zwischen den Tasks erfolgt in der Regel über Betriebssystemdienste. Bei wenigen besonders schnellen Zugriffen kann ein Datenaustausch alternativ über shared memory realisiert werden.

Die Applikationen werden darüber hinaus als eigenständige Hexfiles geflashed, so dass z.B. eine zukünftige Komfortfunktion ergänzt werden kann, ohne dass eine neue Qualifikation der Sicherheitssoftware oder der Fahren/Hebefunktionen nötig ist.

Multi-Core-Laufzeitumgebung

Eine weitere Forderung war es, dass der Applikationsentwickler seinen Code unabhängig von der letztendlichen Partitionierung des Systems erstellen kann. D.h. eine Applikation muss nur wissen, welche Daten sie benötigt und welche Daten sie bereitstellt. Der eigentliche Signalfluss soll über eine Laufzeitumgebung realisiert werden, die zentral konfiguriert und qualifiziert wird.

Bei der Konzeptionierung der Laufzeitumgebung wurde die AUTOSAR RTE als Ausgangspunkt genommen und auf der Basis eine eigene Laufzeitumgebung entwickelt:

  • Zuordnung der Runnables auf Tasks und Tasks auf Cores
  • Erweiterung der Nachrichtendienste über Coregrenzen hinweg
  • Unterstützung unterschiedlicher Speicherbereiche (read only, read/write, write once,…)
  • Direkte Ankopplung der Treiber an die Signale der Laufzeitumgebung
  • Skalierung der Rohdaten in Applikationsdaten im Signallayer

Bild 5 in der Bildergalerie zeigt exemplarisch die Umsetzung einer Sicherheitsfunktion sowie die Fahrenapplikation und eine Komfortfunktion.

Erfahrungen, Fazit, Ausblick

Das Projekt hat gezeigt, dass Multicore Architekturen auch für Sicherheitsapplikationen eine interessante Lösung bieten. Allerdings ist die Entwicklung von Multicore Applikationen deutlich komplexer als die Entwicklung traditioneller Singlecore Programme. Ein Betriebssystem, das optimal auf die Hardware abgestimmt ist und diese vernünftig abstrahiert ist eine wichtige Voraussetzung für den Projekterfolg.

Die Kombination Infineon Aurix und PxROS HR von der Firma HighTec haben sich dabei als gut abgestimmtes Paar erwiesen. Auf dieser Basis konnte mit überschaubarem Aufwand eine leistungsstarke Multicore Laufzeitumgebung entwickelt werden, die bereits in ersten Projekten eingesetzt wird.

Nichtsdestotrotz bleibt die Entwicklung von Multicore Applikationen eine große Herausforderung, da die Systemkomplexität schnell sehr groß wird und Fehler nur schwer zu lokalisieren sind. Im Beispiel des Aurix müssen vielfältige Konfigurationen des Speichers, der Hardware-Safety Funktionen und des Betriebssystems auch nach Änderungen synchron gehalten werden. Hier müssen noch geeignete Werkzeuge entwickelt werden, um dieses wirtschaftlich und sicher zu unterstützen.

Eine weitere spannende Frage für die Zukunft ist die Weiterentwicklung der hier vorgestellten Fail-Safe Architektur in eine Fail-Operational Lösung, bei der Tasks im Fehlerfalle z.B. von einem Core auf einen anderen Core transferiert werden können.

Abkürzungsverzeichnis

  • I : Input – Eingabeeinheit, z.B. Sensor mit ADC Signal;
  • L: Logic – Datenverarbeitungseinheit, z.B. Controller;
  • O: Output – Ausgabeeinheit, z.B. Aktor, der über PWM angesteuert wird;
  • TE: Testeinheit

Literaturverzeichnis

  • [1] ISO26262; Functional Safety – Road Vehicles; ISO / FDIS; 2011
  • [2] Deutsches Institut für Normung e.V.; DIN EN ISO 13849-1/2; Beuth Verlag; Berlin; 2008
  • [3] Barg, Eisenhut-Fuchsberger, Orth, Ost, Springhorn; 10 Schritte zum Performance Level; Bosch-Rexroth; o.A.
  • [4] Infineon; Aurix Safety Manual AP32224 V1.2; Infineon Munich; 2015

* Prof. Fromm vertritt an der Hochschule Darmstadt im Fachbereich Elektrotechnik und Informationstechnik das Gebiet Mikrocontroller und Informationstechnik. Daneben berät und unterstützt er mehrere Firmen im Bereich Embedded Software und System Engineering.

* Thomas Barth ist Lehrkraft für besondere Aufgaben an der Hochschule Darmstadt und forscht an funktionaler Sicherheit auf Mehrkern-Mikrocontrollern.

* Mario Cupelli ist seit 2009 CTO bei HighTec. Die Firma ist spezialisiert auf die professionelle Pflege des GNU Compilers und Entwicklung sicherer Betriebssysteme sowie die Entwicklung innovativer Lösungen für Antriebssysteme.

(ID:44288508)