ESE Fachwissen
Sicherheit auf allen Kernen
Autoren: Prof. Dr.-Ing. Peter Fromm, Thomas Barth, Hochschule Darmstadt, Mario Cupelli, HighTec EDV Systeme GmbH
Beitrag - Embedded Software Engineering Kongress 2015
Multi-Core Controller bieten neben einem Performancegewinn auch die Möglichkeit, redundante Applikationen auf einem einzelnen Chip zu realisieren. Da die physikalische Kopplung zwischen den einzelnen Cores jedoch deutlich "enger" ist als bei diskreten Mehrcontrollerlösungen, werden besondere Anforderungen an die Softwarearchitektur, das Speicherlayout, das Betriebssystem und an die Treiberschicht gestellt.
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 unter Verwendung des Betriebssystems PxROS der Firma HighTec. Insebsondere werden die Entwicklung einer sicheren und erweiterbaren Basisarchitektur, das Design einer Multi-Core-Laufzeitumgebung und die Anwendung geeigneter Designpattern für die Applikationsentwicklung dargestellt.
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 Cores kann zu Datenkonsistenzproblemen führen, Ressourcen wie Speicher und Peripherie müssen konfliktfrei zwischen den einzelnen Cores 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 oder 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 Abbildung 1 (siehe PDF) 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 die Manipulationssicherheit des Systems zu erhöhen (Wegfall externer Verbindungen zwischen den Controllern), soll eine solche Architektur alternativ mit einem Multicore-Controller wie in Abbildung 2 (siehe PDF) 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 Interference 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 Maschinenwelt, 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äß der folgenden Abbildung 3 (siehe PDF) 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 sich die Norm in die folgenden Kategorien:
|
Kategorie |
Aufbau[1] |
Beschreibung |
|
B / 1 |
|
|
|
2 |
|
|
|
3 / 4 |
|
|
Übertragung der Architekurkategorien 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 Interference) 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-Mikrocontroller unterstützt die Anforderung nach "Freedom from Interference" 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 User Modes 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
Abbildung 4 (siehe PDF) 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
Abbildung 5 (siehe PDF) zeigt exemplarisch die Umsetzung einer Sicherheitsfunktion sowie die Fahren-Applikation 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 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 |
Multicore - unsere Trainings & Coachings
Wollen Sie sich auf den aktuellen Stand der Technik bringen?
Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Multicore /Mikrocontroller.
Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.
Multicore - Fachwissen
Wertvolles Fachwissen zum Thema Multicore /Mikrocontroller steht hier für Sie zum kostenfreien Download bereit.
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.