Autoren: Prof. Dr.-Ing. Peter Fromm, Thomas Barth, Hochschule Darmstadt, Mario Cupelli, HighTec EDV Systeme GmbH<\/p>\n
Multi-Core Controller bieten neben einem Performancegewinn auch die M\u00f6glichkeit, redundante Applikationen auf einem einzelnen Chip zu realisieren. Da die physikalische Kopplung zwischen den einzelnen Cores jedoch deutlich\u00a0„enger“ ist als bei diskreten Mehrcontrollerl\u00f6sungen, werden besondere Anforderungen an die Softwarearchitektur, das Speicherlayout, das Betriebssystem und an die Treiberschicht gestellt.<\/strong><\/p>\n Dieser Aufsatz zeigt die Herausforderungen und die Herangehensweise bei der Entwicklung einer Safety-Architektur f\u00fcr 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\u00fcr die Applikationsentwicklung dargestellt.<\/p>\n 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\u00e4ufigkeit der Cores kann zu Datenkonsistenzproblemen f\u00fchren, Ressourcen wie Speicher und Peripherie m\u00fcssen 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\u00e4ndiger. Warum also den Schritt auf den Multicore wagen?<\/p>\n Ein Haupt-Argument ist der Performancegewinn einer Mehrkernarchitektur gegen\u00fcber einem Singlecore. Die CPU-Frequenz l\u00e4sst sich aufgrund der parallel steigenden Leistungsaufnahme und elektromagnetischen St\u00f6rung nicht beliebig erh\u00f6hen. Einen Ausweg bieten hier Multicore-Controller, die die parallele Ausf\u00fchrung voneinander unabh\u00e4ngiger Programmteile erlauben.<\/p>\n Ein weiterer interessanter Anwendungsfall von Multicore-Architekturen ist der Ersatz von redundanten Mehrcontrollerl\u00f6sungen durch einen einzelnen Multicore-Chip. Solche Architekturen finden sich h\u00e4ufig in Applikationen, die hohen Sicherheitsanforderungen unterliegen, z.B. Maschinensteuerungen, Motorsteuerger\u00e4te oder Flugzeugtechnologie, um nur einige Beispiele zu nennen. Bei solchen Architekturen werden die Signalpfade in der Regel mehrkanalig ausgef\u00fchrt, um eventuelle Fehlfunktionen zu erkennen und das System in einen sicheren Zustand zu \u00fcberf\u00fchren. Eine solche vereinfachte mehrkanalige Architektur mit redundanter \u00dcberwachungsfunktion ist in Abbildung 1 (siehe\u00a0PDF<\/a>) dargestellt. Das Eingangssignal wird \u00fcber einen zweikanaligen Sensor erfasst und einem Regelkreis zugef\u00fchrt, der ein Ausgangssignal, z.B. die gew\u00fcnschte Drehzahl f\u00fcr eine Maschine, berechnet und erzeugt. Gleichzeitig werden die Eingangssignale, die korrekte Berechnung des Ausgangssignals sowie das physikalische Ausgangssignal von zwei unabh\u00e4ngigen \u00dcberwachungseinheiten erfasst und gepr\u00fcft. Dabei werden aus Sicherheitsgr\u00fcnden h\u00e4ufig unterschiedliche Technologien zur Signalerfassung (z.B. VADC und Sigma-Delta ADC) und unterschiedliche Algorithmen genutzt. Sobald eine Pr\u00fcfung fehlschl\u00e4gt, kann das System \u00fcber eine geeignete Eskalationsstrategie unabh\u00e4ngig von beiden Kan\u00e4len in einen sicheren Zustand, z.B. Stillstand, \u00fcberf\u00fchrt werden.<\/p>\n Um Produktionskosten zu sparen und die Manipulationssicherheit des Systems zu erh\u00f6hen (Wegfall externer Verbindungen zwischen den Controllern), soll eine solche Architektur alternativ mit einem Multicore-Controller wie in Abbildung 2 (siehe\u00a0PDF<\/a>) beispielhaft skizziert aufgebaut werden.<\/p>\n Bei der Konzeptionierung einer solchen L\u00f6sung ergibt sich eine Reihe von Fragen, die im Folgenden diskutiert werden sollen:<\/p>\n Im Rahmen einer Machbarkeitsstudie wurde in Zusammenarbeit mit den Firmen HighTec, Infineon und einem namhaften Maschinenhersteller ein prototypisches Steuerger\u00e4t f\u00fcr zuk\u00fcnftige Gabelstaplersteuerungen unter Nutzung des 3-Kern-Controllers Aurix TC275 der Firma Infineon entwickelt.<\/p>\n 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.<\/p>\n Bei der Entwicklung der Steuerung wird nach [3] ein Entwicklungsprozess empfohlen, der die folgenden Schritte enth\u00e4lt:<\/p>\n Aufgrund der m\u00f6glichen Gef\u00e4hrdungen f\u00fcr die Nutzer eines Gabelstaplers soll die Steuerung f\u00fcr Fahr- und Hebeaktionen dem Performance Level d gen\u00fcgen. Gem\u00e4\u00df der folgenden Abbildung 3 (siehe\u00a0PDF<\/a>) l\u00e4sst sich erkennen, dass sich der gew\u00fcnschte Performance Level d mit einer Architektur der Kategorie 2 oder 3 erreichen l\u00e4sst. Bei einer Kategorie 2 Architektur gelten allerdings h\u00f6here Anforderungen an den Diagnosedeckungsgrad.<\/p>\n Bez\u00fcglich der Hardwarearchitektur unterscheidet sich die Norm in die folgenden Kategorien:<\/p>\n B \/ 1<\/td>\n \n<\/td>\n 2<\/td>\n \n<\/td>\n 3 \/ 4<\/td>\n \n<\/td>\n Betrachtet man die unterschiedlichen Kategorien aus Tabelle 1, so l\u00e4sst sich die Struktur eines Multicore-Controllers nicht direkt in diese Kategorien \u00fcbersetzen. Zwar verf\u00fcgt ein Multicore-Controller \u00fcber unabh\u00e4ngige Rechenkerne, doch der Speicher und auch die Peripheriebausteine k\u00f6nnen von allen Kernen angesprochen werden. Zus\u00e4tzliche Technologien wie Memory Protection Units versprechen hier zwar bei korrekter Konfiguration eine gewisse Separierung, die den Anforderungen der Norm in Bezug auf Ma\u00dfnahmen gegen Common Cause Fehler aber sehr wahrscheinlich nicht gen\u00fcgen, vor allem die Aspekte Trennung\/Abtrennung der Signalpfade, Diversit\u00e4t der Bauteile und Auswirkung von Umweltst\u00f6rungen erscheinen hier problematisch.<\/p>\n Unabh\u00e4ngig von dieser in Zukunft sicherlich noch zu beantwortenden Frage muss f\u00fcr die Softwarearchitektur gelten, dass ein m\u00f6glichst hoher Grad an R\u00fcckwirkungsfreiheit (Freedom of Interference) zwischen den einzelnen Applikationen und hier insbesondere zwischen den Logikfunktionen und den Sicherheitsfunktionen zu gew\u00e4hrleisten ist, der sich wie folgt begr\u00fcndet:<\/p>\n Der Aurix-Mikrocontroller unterst\u00fctzt die Anforderung nach „Freedom from Interference“ sowohl zwischen Software-Komponenten untereinander als auch zwischen Software-Komponenten und Peripherieregistern. Hierbei werden die Datendom\u00e4ne, die Zeitdom\u00e4ne und die Ressourcendom\u00e4ne unterschieden.<\/p>\n F\u00fcr den Schutz der Datendom\u00e4ne (Speicher) wird prim\u00e4r die Memory Protection Unit (MPU) des Aurix verwendet. Zus\u00e4tzlich steht mit der Bus Memory Protection Unit (BUS-MPU) ein weiteres Instrument zur Verf\u00fcgung. W\u00e4hrend 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\u00fcrfen nur bestimmte Bus-Teilnehmer, z.B. Tasks, von einem bestimmten Core zugreifen) und realisiert eher statische Einschr\u00e4nkungen.<\/p>\n Die Zeitdom\u00e4ne wird prim\u00e4r durch die nebenl\u00e4ufige Ausf\u00fchrung des Codes auf den einzelnen Kernen realisiert. Sobald ein Kern gestartet ist, l\u00e4uft er unabh\u00e4ngig von den anderen Kernen, solange zumindest keine Spinlocks oder andere blockierende Konstrukte genutzt werden. Zur Absicherung des Laufzeitverhaltens stehen au\u00dferdem die \u00fcblichen Watchdogs f\u00fcr lokale und ein Safety Watchdog f\u00fcr globale Operationen zur Verf\u00fcgung.<\/p>\n Der Schutz der Peripherieregister erfolgt \u00e4hnlich wie der Speicherschutz \u00fcber die Memory Protection Unit bzw. die Register Access Protection (RAP, funktional vergleichbar der BUS-MPU). Da die MPU 8 byte aligned ist, k\u00f6nnen damit nur komplette Module gesichert werden, f\u00fcr einzelne Pins reicht die Granularit\u00e4t h\u00e4ufig nicht. Die RAP bezieht sich immer auf komplette Peripheriemodule und erlaubt keine weitere Unterteilung. Diese Einschr\u00e4nkungen sind beim Hardwarelayout zu ber\u00fccksichtigen. Dar\u00fcber hinaus stehen neben dem Supervisor Mode zwei User Modes zur Verf\u00fcgung, die den Zugriff auf die Peripherie beschr\u00e4nken.<\/p>\n Nach dem Booten des Aurix sind alle Sicherheitsmechanismen deaktiviert. D.h. die Applikation muss den Zugriff bewusst einschr\u00e4nken, um bestimmte Ressourcen zu sch\u00fctzen. Da diese Konfiguration aus naheliegenden Gr\u00fcnden nicht \u00fcber die Applikation erfolgen soll, wurde das Betriebssystem PxROS der Firma HighTec ausgew\u00e4hlt. Bei PxROS handelt es sich um ein zertifiziertes Multicore-Betriebssystem, das die Hardwarefeatures des Aurix optimal unterst\u00fctzt:<\/p>\n Abbildung 4 (siehe\u00a0PDF<\/a>) zeigt schematisch die Partitionierung der Gabelstaplersteuerung. Alle Sicherheitsfunktionen sowie die von den Sicherheitsfunktionen ben\u00f6tigten Peripherietreiber werden auf Core 0 ausgef\u00fchrt, 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\u00f6renden Treiber.<\/p>\n Die blauen Boxen repr\u00e4sentieren jeweils eine Applikation, die einem Task mit definierten Ressourcen zugewiesen wird. Die Kommunikation zwischen den Tasks erfolgt in der Regel \u00fcber Betriebssystemdienste. Bei wenigen besonders schnellen Zugriffen kann ein Datenaustausch alternativ \u00fcber shared memory realisiert werden.<\/p>\n Die Applikationen werden dar\u00fcber hinaus als eigenst\u00e4ndige Hexfiles geflashed, so dass z.B. eine zuk\u00fcnftige Komfortfunktion erg\u00e4nzt werden kann, ohne dass eine neue Qualifikation der Sicherheitssoftware oder der Fahren-\/Hebefunktionen n\u00f6tig ist.<\/p>\n Eine weitere Forderung war es, dass der Applikationsentwickler seinen Code unabh\u00e4ngig von der letztendlichen Partitionierung des Systems erstellen kann. D.h. eine Applikation muss nur wissen, welche Daten sie ben\u00f6tigt und welche Daten sie bereitstellt. Der eigentliche Signalfluss soll \u00fcber eine Laufzeitumgebung realisiert werden, die zentral konfiguriert und qualifiziert wird.<\/p>\n Bei der Konzeptionierung der Laufzeitumgebung wurde die AUTOSAR RTE als Ausgangspunkt genommen und auf der Basis eine eigene Laufzeitumgebung entwickelt:<\/p>\nMotivation f\u00fcr den Einsatz von Multi-Core-Controllern<\/h2>\n
\n
Anforderungen an Sicherheitsarchitekturen aus der Normenwelt<\/h2>\n
\n
\n\n
\n Kategorie<\/strong><\/td>\n Aufbau<\/strong>[1]<\/td>\n Beschreibung<\/strong><\/td>\n<\/tr>\n \n <\/p>\n \n <\/p>\n \n
\n <\/p>\n \n <\/p>\n \n
\n <\/p>\n \n <\/p>\n \n
\u00dcbertragung der Architekurkategorien auf einen Multicore-Controller<\/h2>\n
\n
Basissoftware \/ Betriebssystem PxROS<\/h2>\n
\n
Architekturkonzept<\/h2>\n
Multi-Core-Laufzeitumgebung<\/h2>\n
\n