6 Ein Echtzeitparallelrechner zur Rezentralisierung von Steuergeräten im Automobil

Transkript

1 6 Ein Echtzeitparallelrechner zur Rezentralisierung von Steuergeräten im Automobil Stefan Aust, Harald Richter 1 Entwicklungen in der Automobilelektronik Wohl kaum eine Erfindung des 20. Jahrhunderts hat unsere Welt so verändert wie die Erfindung des Automobils. So dynamisch wie sich das Auto für uns als Möglichkeit der individuellen Fortbewegung darstellt, so dynamisch ist auch dessen Entwicklung. Trotz seiner mehr als 100-jährigen Geschichte ist das Automobil auch in der heutigen Form noch weit davon entfernt, als technisch vollendete Lösung zu gelten. Die derzeit vielfach geführten Diskussionen um alternative Antriebsmethoden und fahrerunterstützende Systeme verdeutlichen weiteren Entwicklungsbedarf in der Automobilelektronik. 1.1 Historische Entwicklung Mit der Entwicklung der Automobilelektronik eröffneten sich in der Vergangenheit sukzessiv immer mehr Möglichkeiten bei der Fahrzeuggestaltung. Zunächst wurden einfache elektronische Steuergeräte für bisher mechanisch gesteuerte Funktionen konstruiert. Ein Beispiel hierfür ist der Einsatz einer elektronischen Zündung statt mechanischer Unterbrecherkontakte, mit deren Hilfe der Zündzeitpunkt und damit die Verbrennung im Motor gesteuert werden kann. Später wurde die Funktionalität solcher einfachen elektronischen Steuergeräte permanent erweitert. So entstand im Laufe der Jahre aus der elektronischen Zündung ein komplettes Motormanagement mit einer Vielzahl an Sensoren und Aktoren (z.b. zur Lambdaregelung). 1.2 Aktuelle Trends Es ist zu beobachten, dass sich die Eigenschaften moderner Fahrzeuge zunehmend durch die Funktion der eingebauten Steuergeräte und deren Software definieren. Es gibt kaum eine Funktion, die nicht elektronisch gesteuert werden könnte, sei es der elektrisch verstellbare Außenspiegel, die Sitzverstellung mit Memory-Funktion oder der automatisch gesteuerte Scheibenwischer. Neben dem Komfort spielt die aktive Sicherheit des Fahrzeugs eine immer wichtigere Rolle. Während bei den heute weitgehend gereiften passiven Sicherheitssystemen kaum noch grundlegende Innovationen zu erwarten sind, bieten die aktiven Sicherheitssysteme noch ausreichend Entwicklungspotenzial. Einige aktive Sicherheitssysteme sind bereits Standard in allen Fahrzeugklassen wie etwa das Antiblockiersystem (ABS) oder das elektronische Stabilitätsprogramm (ESP). Weitere aktive Sicherheitssysteme erobern gerade den Markt, wie etwa der Spurhalte- bzw. Spurwechselassistent, der Licht- oder auch der Bremsassistent. Weitere neue Assistenzsysteme befinden sich derzeit noch in der Entwicklungsphase, wie etwa der Rotlicht- oder der Kreuzungsassistent. 70

2 1.3 Herausforderungen für die Zukunft Die aktuellen Entwicklungen in der Automobilelektronik bergen leider auch neue Probleme. Eines der drängendsten Probleme ist der hohe Vernetzungsgrad zwischen den Steuergeräten. Dabei sind gerade die neuen aktiven Sicherheitssysteme mit ihren ausgeklügelten und hochkomplexen Funktionen nur durch den kooperativen Betrieb verschiedener Steuergeräte im Fahrzeug realisierbar. Die große Anzahl an Steuergeräten, die als kleine Computer überall im Auto verteilt sind, und deren hoher Vernetzungsgrad führen bereits während der Konstruktionsphase zu erheblichen Problemen. Für die Entwicklung und Erprobung einzelner Steuergeräte muss das spätere umgebende System im Fahrzeug aufwändig simuliert werden. Weitere Hürden zeigen sich bei der Konstruktion und Montage des Kabelbaums mit einer Gesamtlänge von mehreren Kilometern und mehreren hundert Steckverbindern. Nicht zu vergessen bleiben der steigende Aufwand bei der Qualitätssicherung und der Fehlerdiagnose vor allem bei sicherheitsrelevanten Systemen sowie der erhöhte Kraftstoffverbrauch aufgrund des höheren Gewichts der vielen verzweigten Kupferleitungen. 1.4 Pro Rezentralisierung Die Rezentralisierung der Steuergeräte durch einen Parallelrechner könnte eine Vielzahl der aktuellen und zukünftigen Probleme lösen. Die wachsende Kommunikation zwischen den Steuergeräten über Feldbusse wie CAN und FlexRay würde durch eine Rezentralisierung auf eine Interprozessor-Kommunikation verlagert. Diese ist leichter zu entwerfen, zu testen und zu kontrollieren als die Kommunikation über verschiedene Bussysteme, denn der Test und die Überwachung der Interprozessor- Kommunikation erfolgt über dieselben Werkzeuge, wie sie auch für die Programmierung des Parallelrechners benötigt werden. Die Skalierbarkeit innerhalb der Fahrzeugpalette eines Herstellers würde verbessert, da der fahrende Parallelrechner entsprechend der Ausstattung des Fahrzeugs konfiguriert werden kann. Probleme, die durch Heterogenität entstehen, werden minimiert. Zudem werden Größe und Komplexität des Kabelbaums aufgrund der reduzierten Zahl der Steuergeräte gesenkt. Die Montage und der Test werden vereinfacht und so die Qualität verbessert. Zugleich sinken Herstellungskosten und Gewicht des Fahrzeugs, da sich die Kabellängen und die Zahl der Stecker erheblich reduzieren. 2 AUTOSAR Ein viel diskutiertes Thema in der Automobilbranche ist die Einführung von AUTO- SAR 1. Hierbei handelt sich um eine herstellerübergreifende Spezifikation von Softwarestandards im Automobilbereich [1]. Die Ziele von AUTOSAR sind im wörtlichen Sinne vielschichtig. So beschreibt AUTOSAR neben der Softwarearchitektur auch die dazu notwendigen Softwareschichten. Die entscheidende Neuerung bei AUTOSAR gegenüber der Software klassischer Steuergeräte ist die Abstraktion der Hardware von der Anwendungssoftware durch 1 AUTomotive Open System ARchitecture 71

3 die Einführung eines standardisierten Schichtenmodells, wie in Abbildung 1 dargestellt. Durch die Einführung einer Laufzeitumgebung (RTE 2 ) mit standardisierten Schnittstellen wird die anwendungsorientierte Software (SW-C 3 ) vollständig von der Basissoftware und damit von der zugrundeliegenden Hardware entkoppelt [2,3]. Dieser Schritt ermöglicht zum einen die Portierbarkeit von Software-Anwendungen auf unterschiedliche Steuergeräte-Hardware. Zum anderen können durch die so entstandene Modularisierung einzelne Teile der einmal entwickelten und getesteten Software auf Steuergeräten anderer Plattformen wiederverwendet werden. Für die angestrebte Rezentralisierung der Steuergeräte ist das Schichtenmodell von AUTO- SAR ein überaus wichtiger Schritt, weil dadurch Software-Anwendungen der Steuergeräte auf jedes AUTOSAR-konforme System portiert werden können. Abbildung 1: Schichtenmodell in AUTOSAR Für die Kommunikation zwischen zwei Software-Anwendungen innerhalb eines Steuergerätes oder zwischen zwei Steuergeräten stellt die Laufzeitumgebung RTE dieselben Funktionsaufrufe bereit. Deswegen ist es für die Software-Anwendung unerheblich, ob die Kommunikation innerhalb desselben Steuergerätes oder zwischen zwei verschiedenen Steuergeräten erfolgen soll. Die Aufbauphase, die für die Kommunikation notwendig ist, erfolgt durch die Laufzeitumgebung, und ggf. auch in Kooperation mit der Basis-Software, die passende Treibersoftware für die Kommunikationshardware (z.b. CAN) zur Verfügung stellt. 3 Echtzeit-Datenverarbeitung 3.1 Echtzeitanforderungen Bei der Datenverarbeitung in einem Echtzeitsystem ist neben der logischen Korrektheit der Rechenergebnisse auch deren zeitliche Korrektheit (=Rechtzeitigkeit) von entscheidender Bedeutung [4]. Ein Rechenergebnis behält seine Gültigkeit nur innerhalb festgelegter Zeitschranken (Deadlines). Außerhalb dieser Zeitschranken verliert das Rechenergebnis seinen Nutzwert. Man spricht von einem Echtzeitverhalten, wenn die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. Die besondere Situation der Echtzeitdatenverarbeitung ist dadurch ge- 2 Runtime Environment 3 Software Component 72

4 kennzeichnet, dass das Rechensystem seine Eingabedaten unmittelbar aus seiner Umgebung bezieht und die Rechenergebnisse auf das umgebende System ebenso unmittelbar zurückwirken [5]. Dabei muss das Rechensystem die Daten mit der gleichen Geschwindigkeit bearbeiten, wie sie auch anfallen. Das bedeutet, dass das Zeitverhalten des Systems innerhalb zulässiger Abweichungen vorherbestimmbar sein muss. Man spricht in diesem Zusammenhang von einem zeitlichen Determinismus [5]. Echtzeitdatenverarbeitung bedeutet nicht notwendigerweise die Forderung nach hoher Verarbeitungsgeschwindigkeit. Entscheidend ist, dass alle zeitgebundenen Aufgaben rechtzeitig ausgeführt werden. Ein Beispiel: Die Zündung im Motor darf nicht zu spät (obere Zeitschranke), aber auch nicht zu früh (untere Zeitschranke) erfolgen. Eine Reaktion außerhalb dieses Zeitfensters gilt als Fehlzündung und kann zu einer irreversiblen Schädigung des Motors führen. In diesem Beispiel liegt sogar eine harte Echtzeitanforderung vor, da eine Fehlfunktion auf keinen Fall zu tolerieren ist. Abbildung 2: Echtzeitsystem 3.2 Echtzeit-Betriebssysteme Echtzeit-Betriebssysteme erfüllen primär dieselben Aufgaben wie ein normales Betriebssystem. Als zusätzliche Besonderheit müssen Echtzeit-Betriebssysteme zeitlich deterministisch sein. Das heißt, sobald Aufgaben des Betriebssystems (Tasks) zeitlichen Anforderungen unterliegen, müssen die vorgegebenen Zeitschranken vom Betriebssystem garantiert eingehalten werden. Die Forderung nach Einhaltung möglicher Zeitschranken besteht vor allem im Multitaskingbetrieb, wo mehrere Prozesse unter Echtzeitbedingungen nebenläufig ausgeführt werden müssen. Die Abbildung 3 zeigt eine typische Konstellation in Steuerprogrammen mit einer zeitgesteuerten (periodischen) und einer ereignisgesteuerten (aperiodischen) Task unterschiedlicher Priorität. 73

5 Abbildung 3: Multitaskingbetrieb Das Grundproblem bei der Ausführung von mehreren nebenläufigen Prozessen in einem klassischen Rechensystem besteht darin, dass deutlich mehr Prozesse als Prozessoren existieren. Dadurch entsteht eine Konkurrenzsituation zwischen den Prozessen bezüglich deren Ausführung. Die Vergabe der Rechenleistung des oder der Prozessor(en) an die jeweiligen Prozesse erfolgt durch den Scheduler des Betriebssystems, und zwar gemäß einer Prozessorzuteilungsstrategie. Für solche Scheduling-Strategien wurden in der Vergangenheit eine ganze Reihe unterschiedlicher Algorithmen und Methoden für Echtzeit-Betriebssysteme entwickelt [6,7,8]. Allerdings bietet keine Scheduling-Strategie die perfekte Lösung, weshalb oft Kombinationen verschiedener Strategien eingesetzt werden, um möglichst alle auftretenden Situationen abzudecken. Mit der Komplexität der Software steigt auch die Schwierigkeit, den Nachweis für die Echtzeitfähigkeit des Rechensystems zu erbringen. Hierzu muss die sog. Worst Execution Cycle Time (WECT) ermittelt werden. Die WECT ist die maximale Zeit, die ein Prozess zur vollständigen Bearbeitung einer gegebenen Task benötigt. In einem zeitgesteuerten System kann die WECT noch relativ genau bestimmt werden. Oftmals werden aber auch ereignisgesteuerte Prozesse höherer Priorität in die Prozessorzuteilungsstrategie mit eingebunden, deren Zeitpunkte der Aufrufe unter Umständen nur schwer vorhersagbar sind. Damit gerät das zeitliche Verhalten des Gesamtsystems in den Bereich der Wahrscheinlichkeit und ist so nicht mehr deterministisch, d.h. nicht echtzeitfähig. 4 Rechnerarchitektur Da die klassischen Echtzeitrechner zumeist Einkernprozessoren (Single Core) beinhalten, müssen ausreichend schnelle Prozessoren vorhanden sein, um die Einhaltung der durch das reale System vorgegebenen Zeitbedingungen mittels maximaler Rechenleistung zu gewährleisten. Das Betriebssystem bzw. dessen Task-Scheduler ist dafür verantwortlich, dass die einzelnen Prozesse gemäß einer geeigneten Prozessorzuteilungsstrategie vom Prozessor bearbeitet werden und somit die Echtzeitfähigkeit des Systems garantiert ist. In der Prozessortechnik ist allerdings seit dem Jahr 2006 eine Stagnation im bisher fast jährlichen Wachstum der Taktfrequenzen zu verzeichnen. Bei Frequenzen bis max. 4 GHz ist die physikalische Leistungsgrenze erreicht. Weitere Steigerungen der Rechenleistung werden seither durch den Einsatz von Mehrkernprozessoren (Multi Core) realisiert, bei denen Programme von mehre- 74

6 ren Prozessoren parallel bearbeitet werden sollen. Der Trend zur Parallelisierung durch Mehrkernprozessoren weist in die Richtung der massiv parallelen Rechensysteme, bei denen allerdings die Netto-Rechenleistung und nicht die Echtzeitfähigkeit des Systems das Ziel bei der Entwicklung einer geeigneten Rechnerarchitektur markiert. Doch gerade für eingebettete Echtzeitsysteme lohnt sich ein Blick auf die Architektur der parallel verarbeitenden Supercomputer, wie die nachfolgenden Ausführungen zeigen werden. 4.1 Multiprozessorsystem Wie im Abschnitt 3.2 beschrieben, entsteht die Konkurrenz zwischen lauffähigen Prozessen durch das zahlenmäßige Ungleichgewicht von Prozessoren und Prozessen. Diese Situation kann dadurch gelöst werden, dass die Zahl der Prozessoren P = {P 1,P 2,..,P n } der Zahl der Prozesse T = {T 1,T 2,..,T n } entspricht. Anstelle einer zeitlichen Aufteilung der Rechenleistung eines einzelnen Prozessors auf mehrere Prozesse, dem Time Sharing, wird durch Space Sharing eine räumliche Aufteilung des Computerchips, auf dem sich viele Prozessoren befinden, auf die Prozesse vorgenommen (Abbildung 4). Durch die so entstandene bijektive Abbildung der beiden Mengen P und T wird jedem Prozess T x ein Prozessor P x fest zugeordnet. Abbildung 4: Time Sharing vs. Space Sharing D. h. durch Space Sharing wird jedem Prozess ein eigener Prozessor exklusiv zugeordnet. Auf diese Weise kann sichergestellt werden, dass sowohl zeit- als auch ereignisgesteuerte Prozesse zu jeder Zeit und gleichzeitig bearbeitet werden können, ohne dass die Gefahr von Unterbrechungen durch andere Prozesse mit höherer Priorität besteht. Das aufwändige Verfahren der Zuteilung der Prozessorrechenleistung an Prozesse entfällt, das Betriebssystem wird vereinfacht und gibt zusätzliche Rechenzeit aufgrund der nicht mehr notwendigen Prozessumschaltung frei. Die Einhaltung der Zeitschranken und die damit verbundene Echtzeitfähigkeit des Rechensystems braucht nicht mehr durch das Betriebssystem bzw. dessen Task-Scheduler sichergestellt werden. 75

7 Abbildung 5: Multiprozessorsystem Da bei Time Sharing viele Prozesse vom selben Prozessor bearbeitet werden, ist die stets notwendige Interprozessor-Kommunikation relativ leicht zu bewerkstelligen, im Gegensatz zum Space Sharing, wo räumlich isolierte Prozesse Daten austauschen müssen. Die Aufgabe besteht nun darin, ein Multiprozessorsystem zu konstruieren, welches genügend Prozessoren zur Verfügung stellt, die ausreichend schnell miteinander kommunizieren können. Die Abbildung 5 zeigt ein Beispiel für ein solches Rechensystem. Jeder Prozessor besitzt hierbei einen eigenen Lokalspeicher, in dem die jeweilige Software-Anwendung abgelegt ist. Durch die lokalen Speicher wird der Adressraum automatisch vor unberechtigten Zugriffen von außen geschützt. Die Interprozess-Kommunikation erfolgt durch den Austausch von Nachrichten (Message Passing) oder optional durch Variablen in einem oder mehreren gemeinsamen Speicher(n) (Shared Memory). In beiden Fällen ist für die Kommunikation ein geeignetes Verbindungsnetzwerk nötig. 4.2 Softprozessoren Frei programmierbare Logikbausteine, sog. FPGAs 4, bieten die Möglichkeit, Softprozessoren zu implementieren. Die Architektur dieser Prozessoren wird mit Hilfe einer Hardwarebeschreibungssprache (z.b. VHDL 5 ) beschrieben, vom Compiler übersetzt ( synthetisiert ) und auf dem FPGA in Hardware implementiert. Auf diese Weise kann ein Multiprozessorsystem, wie es in Abbildung 5 gezeigt ist, als On-Chip Lösung (MPSoC 6 ) in einem FPGA implementiert werden. Softprozessoren bieten darüber hinaus den großen Vorteil, dass die Architektur des ganzen Systems oder einzelner Prozessoren an die jeweilige Applikation dynamisch angepasst werden kann. Darüberhinaus werden hinsichtlich der Ausführungszeit nichtdeterministische Komponenten wie Caches oder Sprungvorhersageeinheiten eliminiert, da aufgrund der Vielzahl 4 Field Programmable Gate Array 5 Very High Speed Integrated Circuit Hardware Description Language 6 Multi-Processor System on-chip 76

8 der auf demselben FPGA-Chip zur Verfügung stehenden Softprozessoren nicht mehr die Maximierung der Rechenleistung eines einzelnen Prozessors im Vordergrund steht. Dadurch wird ferner die benötigte Fläche eines einzelnen Prozessors auf dem Chip stark verkleinert und dessen Zahl im Sinne massiv paralleler Multiprozessorsysteme vervielfacht. Die maximale Anzahl der auf dem Chip implementierbaren Softprozessoren hängt von der Anzahl der Logikzellen des verwendeten FPGAs ab. Die Abbildung 6 zeigt die fortschreitende Zahl der verfügbaren Logikzellen bei verschiedenen Generationen von FPGAs aus der Virtex-Familie von Xilinx. Mit der für Anfang 2011 angekündigten Generation der Virtex-7 FPGAs lassen sich bereits Multiprozessor-Systeme mit einigen hundert Softprozessoren auf einem einzigen Chip implementieren. Abbildung 6: Verfügbare Zahl der Logikzellen verschiedener FPGAs 4.3 Interprozessor-Kommunikation Nachdem die gleichzeitige Bearbeitung aller Prozesse durch die Aufteilung der Prozesse auf genauso viele Prozessoren durch technologische Fortschritte der FPGAs möglich geworden ist, soll im Weiteren der Aspekt der Interprozessor-Kommunikation betrachtet werden. Damit das gesamte Rechensystem echtzeitfähig bleibt, muss auch die Interprozessor-Kommunikation, also das Verbindungnetzwerk zwischen den Prozessoren, echtzeitfähig sein. Diese beruht hardwaremäßig auf einem Verbindungsnetzwerk zwischen den Prozessoren. Da das Multiprozessorsystem auf einem einzigen Chip implementiert ist, muss auch das Verbindungsnetzwerk als On-Chip Lösung (NoC 7 ) auf demselben Chip implementiert werden. NoCs gelten aktuell als entscheidendes Paradigma bei der Kommunikation in Einzel-Chip Systemen. Sie lösen mehr und mehr konventionelle Bussysteme ab, die aufgrund ihrer geringen Skalierbarkeit und Bandbreite nicht länger effizient einsetzbar sind [10,11]. Mittlerweile wurden diverse Studien an NoCs vorgenommen [12,13,14,15]. Diese beschränken sich bisher aber auf die Implementierung statischer Netzwerktopologien ohne die Berücksichtigung von Echtzeiteigenschaften. 7 Network on-chip 77

9 4.3.1 Dynamische Verbindungsnetzwerke Dynamische Verbindungsnetzwerke werden auch als indirekte oder mehrstufige Netzwerke bezeichnet. Die Architektur dieser Netzwerke besteht im Wesentlichen aus in Stufen organisierten Schaltern, die wahlweise auf parallelen oder gekreuzten Durchgang gesetzt werden können, weshalb sie auch als Kreuzschalter bezeichnet werden (siehe dazu Abbildung 7). Bei Kreuzschaltern gibt es zusätzlich die Erweiterung durch obere und untere Broadcast-Funktionen, die in der Tasksynchronisation bei Parallelrechnern eine Rolle spielen. Kreuzschalter haben normalerweise zwei Eingänge und zwei Ausgänge. Sie können aber auch so erweitert werden, dass sie Daten simultan in beiden Richtungen übertragen. Im Falle bidirektionaler Datenübertragung ist es sogar möglich, Kreuzschalter so zu konfigurieren, dass sie einlaufende Datenströme auf dieselbe Seite zurückspiegeln, von der sie gekommen sind, freilich zu anderen Anschlussklemmen hin, um eine neue Funktionalität zu erreichen. Abbildung 7: Kreuzschalterstellung: a) gerade, b) gekreuzt Des Weiteren können Kreuzschalter zu Verbindungsnetzwerken verkoppelt werden. Die einzelnen Schalterstufen sind durch Permutationsfunktionen, den Verdrahtungsstufen, miteinander verbunden. Eine Gesamtpermutation entsteht aus der Verkettung aller Stufen, wobei die Kreuzschalter für eine Vielzahl potentieller Permutationen sorgen. Die Abbildung 8 zeigt ein mehrstufiges Netzwerk der Größe 8x8, das die Bezeichnung Omega-Netz trägt, bei dem die Kreuzschalter durch sog. Shuffle- Permutationen verdrahtet sind [16]. Abbildung 8: Omega-Netz der Größe 8x8 Erstmals wurden dynamische Netzwerke für die Leitungsvermittlung in Telefonnetzen eingesetzt. Im Zeitalter der Supercomputer finden solche Netzwerke in großen Parallelrechnern Verwendung und dienen der auf dem Austausch von Paketen basierten Interprozessor-Kommunikation zwischen hunderten bis zehntausenden Prozessoren. 78

10 Dynamische Verbindungsnetzwerke sind sehr kostengünstig, da sie mit O(nlogn) skalieren. Die Eigenschaften dynamischer Verbindungsnetzwerke sind weitgehend erforscht, so dass heute eine Reihe gut funktionierender Netze zur Verfügung stehen. Abbildung 9: 4-dimensionaler Hypercube Im Vergleich zu den bei bisherigen On-Chip-Systemen eingesetzten statischen Netzwerken, wie Gitter oder Hypercube, bieten dynamische Netzwerke eine ganze Reihe von Vorteilen. Bei einem statischen Netz vom Typ Hypercube zum Beispiel besitzt jeder Knoten log 2 N Nachbarknoten. Das heißt, dass bei einem 4-dimensionalen Hypercube (Abbildung 9) mit insgesamt nur 16 Knoten durch die räumliche Anordnung jeder Knoten bereits 4 Netzwerkschnittstellen aufweisen muss. Dazu kommt, dass jeder Rechenknoten gleichzeitig auch Routerknoten sein muss. Bei einem mehrstufigen Netzwerk, wie in der Abbildung 8 dargestellt, benötigt jeder Knoten unabhängig von der Netzgröße nur eine einzige Schnittstelle zum Netzwerk. Eine Routingaufgabe müssen die Knoten nicht übernehmen. Einen wichtigen Vorteil bietet die Leitungsvermittlung in dynamischen Netzwerken. Hierdurch kann der Sender die Nachricht über einen exklusiv zur Verfügung stehenden Kommunikationspfad an den Empfänger übermitteln. Dadurch entfällt im Vergleich zu statischen Verbindungsnetzwerken die Zeit für den Transfer über Zwischenknoten, die auf dem Weg vom Sender zum Empfänger passiert werden müssen. Auch die Entstehung sog. Hotspots, den Staustellen an besonders datenverkehrsbelasteten Routerknoten im Netz, kann vermieden werden, was die Echtzeitfähigkeit deutlich verbessert. Eine weitere Option der leitungsvermittelnden dynamischen Netze bietet das zentral organisierte Routing. Dadurch kann das Echtzeitverhalten des Netzes durch eine zentrale Instanz, den Netzwerk-Controller, einfacher sichergestellt werden. Nachteilig ist bei einer zentralen Wegewahlinstanz allerdings die höhere Komplexität bei der Leitungsvermittlung und der Totalausfall des Gesamtsystems bei Ausfall des Netzwerk-Controllers Nicht-blockierungsfreie Netze Mehrstufige Netze bieten die Möglichkeit, sehr große Netzwerke mit vergleichsweise geringen Hardwarekosten zu realisieren. Zu den mehrstufigen Netzen gehört insbesonders die technisch wichtige Kategorie der logn-netze [16]. Deren Name ergibt 79

11 sich aus der Eigenschaft, dass sie aus Nlog 2 N Kreuzschaltern aufgebaut sind, wobei N die Anzahl der Ein- und Ausgänge im Netzwerk bezeichnet. Diese Netze benötigen die kleinste Anzahl von Stufen, die überhaupt möglich ist, um jeden Eingang mit jedem Ausgang zu verbinden. Allerdings gilt die Einschränkung, dass nicht alle möglichen Gesamtpermutationen realisiert werden können. Das heißt, es kann bei bestimmten Permutationen vorkommen, dass nicht jeder Eingang mit dem dafür vorgesehenen Ausgang verbunden werden kann. Aus diesem Grund werden die logn- Netze als nicht-blockierungsfreie Netze bezeichnet. Positiv zu werten ist, dass logn- Netze die Eigenschaft der Pfadeindeutigkeit bieten. D.h. es gibt für jede Permutation genau einen Pfad von jedem Eingang zu jedem Ausgang, sofern dieser Pfad überhaupt existiert. Diese Eigenschaft erlaubt einen einfachen Routingalgorithmus. Die Abbildung 10 zeigt als Beispiel das Routing für eine Variante des Omega-Netzes, dem Baseline-Netz, das besonders übersichtlich ist. Die notwendigen Schalterstellungen in den einzelnen Stufen ergeben sich aus den Bits der binären Zieladresse, die von links nach rechts ausgewertet werden, angefangen mit dem höchstwertigen Bit. Im Falle einer 0 wird der obere Ausgang des Kreuzschalters und bei einer 1 der untere Ausgang genommen. Abbildung 10: Routing im Baseline-Netz Um die Echtzeitfähigkeit von log-netzen trotz ihrer Nichtblockierungsfreiheit zu gewährleisten, muss das Vermitteln von Leitungen durch das Netz kontrolliert erfolgen. Dies geschieht mit Hilfe eines Schedulings der zu vermittlenden Verbindungen, das in einzelnen Schritten abläuft. Das Scheduling kann entweder statisch während der Konfigurationsphase oder dynamisch zur Laufzeit erfolgen. Der zu beschreitende Pfad und die Dauer der Verbindung kann im statischen Fall in einer Schedulingtabel- 80

12 le festgeschrieben werden. So kann bereits vor der Ausführung einer Software- Anwendung geprüft werden, ob alle Verbindungswünsche fristgerecht erfüllt oder ob Zeitschranken (Deadlines) verletzt werden. Beim dynamischen Scheduling muss ähnlich wie beim Prozess-Scheduling ein zeiteffizienter Scheduling-Algorithmus existieren. Eine Vorhersage über das tatsächliche Zeitverhalten ist hier nur durch Vorabsimulation der Interprozessor-Kommunikation möglich Blockierungsfreie Netze Schaltet man zwei nicht-blockierungsfreie logn-netze hintereinander, so erhält man ein Netz, das durch Umordnen interner Pfade stets blockierungsfrei ist. Die Abbildung 11 zeigt als Beispiel das Benes-Netz [17]. Das Benes-Netz entsteht durch die Verkettung des Baseline- mit einem inversen Baseline-Netz, wobei die letzte Stufe des ersten Netzes und die erste Stufe des zweiten Netzes miteinander verschmelzen. Durch die auf 2log 2 N-1 vergrößerte Stufenanzahl besitzen blockierungsfreie Netze die Eigenschaft, jeden Eingang zu allen Zeitpunkten mit jedem freien Ausgang verbinden zu können. Es kann jede Permutation von Eingängen auf Ausgängen realisiert werden. Diese Fähigkeit basiert auf der Existenz alternativer Pfade durch das fast doppelt so große Netz. Die Anzahl alternativer Pfade von jedem Eingang zu jedem Ausgang steigt proportional mit der Anzahl der Ein- und Ausgänge. Abbildung 11: Benes-Netz Aufgrund der fehlenden Pfadeindeutigkeit müssen die Pfade so durch das Netz gelegt werden, dass alle gewünschten Verbindungen vermittelt werden können. Da dieser Vorgang bei sequentieller Ausführung eine nichtlineare Zeitkomplexität hat, entstehen hier im Vergleich zu den nicht-blockierungsfreien logn-netzen neben den zusätzlichen Stufen weitere Kosten durch das aufwändige Routingverfahren. Dafür bieten diese Netze eine garantiert echtzeitfähige Kommunikationsstruktur ohne Verwendung eines Schedulings. 81

13 5 Implementierung im FPGA Der hier beschriebene Echtzeit-Parallelrechner wird als Multiprozessorsystem (MPSoC) in einem einzigen FPGA implementiert. Der FPGA enthält sowohl die Prozessoren als auch das mehrstufige Verbindungsnetzwerk. Für einen Prototypen des Parallelrechners wurde ein FPGA vom Typ Virtex-4 FX100 der Fa. Xilinx verwendet. Mit diesem Chip lässt sich ein MPSoC mit bis zu 16 Softprozessoren realisieren. Wie bereits in der Abbildung 6 dargestellt, bieten nachfolgende Generationen dieser Familie deutlich mehr Kapazitäten. Vor allem die jüngste Generation der Virtex-7 FPGAs zeigt einen Sprung in der Evolution. Weitere Steigerungen sind auch zukünftig zu erwarten. Als Prozessoren kommen proprietäre Softprozessoren der Fa. Xilinx vom Typ Micro Blaze zum Einsatz [18]. MicroBlazes sind 32-Bit RISC Prozessoren, die in unterschiedlichen Ausbaustufen (z.b. Cache, Pipelining, Gleitkommaeinheit) konfiguriert werden können. Eigene spezifische Co-Prozessoren können ebenfalls implementiert werden. Je nach verwendetem FPGA sind maximale Prozessortaktfrequenzen von 50 MHz bis 200 MHz möglich. Da Softprozessoren in VHDL oder Verilog beschrieben werden, können selbstdefinierte, anwendungsspezifische Softprozessoren entwickelt werden. Auf diese Weise lassen sich auch spezielle Assemblerbefehle, z.b. für besonders schnelle Steuer- oder Regelalgorithmen, implementieren. Für den MicroBlaze Softprozessor stehen mehrere verschiedene Betriebssysteme zur Verfügung. Neben den proprietären Versionen von Xilinx (Standalone, Xilkernel) existieren noch diverse Linux-Derivate und Echtzeitbetriebssysteme wie FreeRTOS. Abbildung 12: MicroBlaze: Befehlspipeline mit FSL-Interface 82

14 Beim vorgeschlagenen Multiprozessor erfolgt die Anbindung an das Verbindungsnetzwerk durch den ebenfalls proprietären FSL-Bus 8, Dieser Bus besitzt eine 32-Bit Datenleitung und wurde ursprünglich für die Anbindung kundenspezifischer Co- Prozessoren an den MicroBlaze von Xilinx entwickelt [19]. Der Vorteil dieses Interfaces liegt zum einen in der Integration der Kommunikation in den Prozessorkern, zum anderen in der asynchronen Betriebsweise von FSL, die aufgrund eines FSLinternen FIFO-Speichers von der Befehlsausführung des Prozessors entkoppelt ist (Abbildung 12). Für die Kommunikation steht ein eigener Befehlssatz im Prozessor zur Verfügung, sodass Schreib- und Lesebefehle schnell ausgeführt werden. Diese atomaren Befehle erlauben z.b. die Implementierung von Tasksynchronisationen mit Hilfe von Semaphoren. Abbildung 13: Implementierung des Multiprozessorsystems im Xilinx FPGA Das Verbindungsnetzwerk für die Interprozessor-Kommunikation wird als mehrstufiges On-Chip- Netzwerk (MINoC 9 ) ebenfalls auf dem FPGA implementiert und dient der Leitungsvermittlung zwischen Sender und Empfänger. Aus Geschwindigkeitsgründen wird der Algorithmus zur Leitungsvermittlung nicht als Software auf einem Softprozessor sondern in VHDL programmiert und in Hardware vom FPGA ausgeführt. Nach außen wird das Netzwerk über mehrere FSL-Busverbindungen an die Prozessoren gekoppelt. Da der FSL-Bus je eine unidirektionale Verbindung zwischen einem Sender und einem Empfänger aufbaut, steht jedem Prozessor ein exklusiver Netzwerkzugang zur Verfügung. Für jeden Prozessor müssen je zwei FSL- Busverbindungen implementiert werden. Die Abbildung 13 zeigt den Aufbau des Multiprozessorsystems, wie es im Xilinx FPGA implementiert wurde. Jedem MicroBlaze Softprozessor ist ein sog. Block RAM als Lokalspeicher zugeordnet. Die Interprozessorkommunikation erfolgt über das mehrstufige Verbindungsnetzwerk, welches die FSL-Busverbindungen zwischen den Prozessoren vermittelt. 8 Fast Simplex Link 9 Multistage Interconnection Network on-chip 83

15 6 Neue Entwurfsmethodik zur Erstellung von Software für ein Steuergerät 6.1 AUTOSAR Methodik Die Abbildung 14 zeigt eine Übersicht der AUTOSAR-Methodik bei der Erstellung von Software für ein Steuergerät (ECU 10 ) [20]. Als Ausgangspunkt für die Software- Erstellung dient die Beschreibung der Hardware des Systems und des einzelnen Steuergerätes auf Basis von XML. Aus dieser Beschreibung werden z.b. die wesentlichen Kenndaten der Konfiguration des jeweiligen Steuergerätes wie etwa der Prozessortyp oder externe Anbindungen anderer Steuergeräte automatisch extrahiert. In einer weiteren Beschreibung sind Kenndaten der Software-Komponenten enthalten, die in die Laufzeitumgebung RTE einzupassen sind. Anhand dieser Beschreibungen werden Teile der Basis-Software, des Betriebssystems und der Laufzeitumgebung für jedes Steuergerät erzeugt. Im letzten Schritt wird aus allen Objekten eine auf dem Steuergerät ausführbare Datei generiert. Abbildung 14: Übersicht der AUTOSAR Methodik Die in der Abbildung 14 dargestellte Vorgehensweise basiert darauf, dass die Steuergerätesoftware entsprechend den Rahmenbedingungen einer statisch vordefinierten Hardware (z.b. Prozessortyp oder Speichergröße) generiert wird. Die Hardwareentwicklung erfolgt weitgehend unabhängig von Art und Umfang der späteren Softwarelösung. Die Softwareentwicklung erfolgt dagegen unter strenger Berücksichtigung sowohl der Hardware im Steuergerät als auch der späteren Systemintegration im Fahrzeug. Diese Methodik erfordert zudem eine umfangreiche Laufzeitanalyse der Software bezüglich des Echtzeitverhaltens des Systems. 10 Electronic Control Unit 84

16 6.2 Software-orientierte Methodik Bei der Verwendung frei programmierbarer Hardware auf FPGA-Basis lässt sich ein Rechensystem entwerfen, welches die Rechenhardware des Steuergerätes an die Anforderungen der Software anpasst. Diese Methode wird dadurch begünstigt, dass bei automobilen Steuergeräten Art und Umfang der Software frühzeitig bekannt sind. Sobald die Softwarearchitektur grob definiert ist, kann parallel die dazu passende Rechnerarchitektur in VHDL spezifiziert werden. Dadurch kann das Prinzip des Space Sharing, d.h. die räumliche Aufteilung der Chipfläche des FPGAs, auf die zur Bearbeitung benötigten Prozessoren angewendet werden (siehe Abschnitt 4.1). Die Rechenhardware im FPGA wird auf diese Weise fester Bestandteil in der Entwicklungsumgebung der Steuergerätesoftware. Eine ähnliche Konstellation existiert bereits im Entwicklungstool EDK der Firma Xilinx, bei dem Hardware und Software in derselben Umgebung entwickelt werden können. Allerdings steht hier das Design der Hardware im Vordergrund. Die Abbildung 15 zeigt die Vorgehensweise bei der software-orientierten Entwicklungsmethode. Die für die Rechenhardware benötigten Informationen werden automatisch aus der Beschreibung der Softwarekomponenten aus dem Softwareprojekt extrahiert. Aus diesen Informationen und den zusätzlichen Hardwarebeschreibungen des Steuergerätes (z.b. für externe Schnittstellen) wird in der Entwicklungsumgebung ein Hardwareprojekt mit der benötigten FPGA-Hardware in VHDL generiert. Das Synthesetool übersetzt das VHDL-Projekt in den zur Verfügung stehenden FPGA. Der Softwarecompiler generiert aus der Anwendungssoftware und den darunterliegenden Schichten ausführbare Dateien. Im finalen Schritt werden die generierte Hardware und programmierte Software der Softprozessoren als gemeinsamer Bitstream in den FPGA des Steuergerätes geladen und ausgeführt. Durch die Aufteilung der Software auf viele Prozessoren wird die spätere Laufzeitanalyse der einzelnen Programmteile entsprechend dem Teile-und-Herrsche-Prinzip stark vereinfacht. Abbildung 15: Software-orientierte Methodik 85

17 Zusammenfassung Die heutige Entwicklung der Automobilelektronik hin zu mehr Komfort und aktiver Fahrsicherheit durch fahrerunterstützende Systeme führt zu einem dramatischen Wachstum hinsichtlich Umfang und Komplexitität automobiler Software. Dadurch stellt sich zum einen die Forderung nach immer mehr Rechenleistung im Fahrzeug. Zum anderen verursacht das gewachsene heterogene System aus vielen verteilten Steuergeräten große Schwierigkeiten bei der Realisierung komplexer und steuergeräteübergreifender Funktionen bezüglich Fragen der Kommunikation, Skalierbarkeit, Systemintegration, Portierbarkeit und Qualitätssicherung. Unser Konzept zur Rezentralisierung der im Fahrzeug verteilten Steuergeräte in wenige zentrale Rechenknoten bietet hier geeignete Lösungen. Hierfür wurde die Architektur eines Echtzeit- Parallelrechners entworfen, der nicht nur frei skalierbare Rechenleistung zur Verfügung stellt, sondern auch Echtzeitverhalten garantiert. Durch den Einsatz programmierbarer FPGAs kann die Rechnerhardware nach dem Prinzip des Space Sharing an die Anforderungen der Software angepasst werden, wodurch die Echtzeitfähigkeit des Rechensystems in einfacher Weise gesichert werden kann. Die Rechnerhardware wird dadurch Teil der Entwicklungsumgebung der Steuergerätesoftware. Die benötigte Rechenleistung kann je nach Ausstattung des Fahrzeugs frei gewählt werden. Dafür stehen FPGAs in unterschiedlichen Größen und Leistungsklassen zur Verfügung. Aufgrund des verwendeten Space Sharing sind Umfang und Komplexität der Anwendungssoftware nicht mehr die wesentlichen Kriterien für das Echtzeitverhalten. Zudem wird durch die Aufteilung der Software in lokale Speicher der Speicherschutz sicherheitskritischer Anwendungen automatisch gewährleistet. Durch die Einführung eines Schichtenmodells in der Steuergerätesoftware im Sinne von AUTOSAR wird die Anwendungssoftware von der Hardware entkoppelt und Schnittstellen zu darunterliegenden Schichten definiert. Aufgrund der durch standardisierte Schnittstellen entstandenen Portierbarkeit kann die Software bereits bestehender Steuergeräte einfach in den Parallelrechner übernommen werden. Ein späteres Upgrade der Rechenleistung zur Erweiterung um zusätzliche Funktionen oder der Austausch defekter Geräte durch Hardware nachfolgender Generationen wird dadurch ebenfalls möglich. Die Interprozess-Kommunikation zwischen zwei oder mehreren Anwendungsprogrammen erfolgt über ein sehr schnelles und echtzeitfähiges On-Chip-Verbindungsnetzwerk an Stelle der heute üblichen Steuergerätekommunikation über Feldbussysteme. Die Anzahl der Steuergeräte wird minimiert, der Kabelbaum vereinfacht und der Anteil an Kupferkabeln und damit das Gewicht reduziert. Die Verwendung bestehender AUTOSAR-konformer Software in einem Parallelrechner führt in Verbindung mit einem geeigneten Kommunikationsnetzwerk für Sensoren und Aktoren zu einem homogenen und gut skalierbaren System im Fahrzeug, damit die zukünftigen komplexen Aufgaben der Automobilelektronik realisiert werden können. 86

18 Literaturverzeichnis [1] AUTOSAR Development Partnership, [2] Kindel, O. und Friedrich, M., 2009, Softwareentwicklung mit AUTOSAR. Grundlagen, Engineering, Management in der Praxis. 1. Auflage, Heidelberg, dpunkt.verlag [3] Zimmermann, W. und Schmidgall, R., 2008, Bussysteme in der Fahrzeugtechnik. 3. Auflage, Wiesbaden, Vieweg+Teubner Verlag [4] Buttazzo, G. C., 1997, Hard Real-Time Computing Systems. Predictable Scheduling, Algorithms and Applications. Boston; Dordrecht; London, Kluwer Academic Publishers [5] Rzehak, H., 1994, Echtzeitsysteme und Fuzzy Control. Konzepte, Werkzeuge, Anwendungen. Braunschweig; Wiesbaden, Vieweg & Sohn Verlagsgesellschaft mbh [6] Ziegler, B., 1979, Prozessorzuteilung unter strengen Zeitbedingungen. aus Computing, Volume 23, Wien, Springer Verlag, Seiten [7] Henn, R., 1978, Antwortzeitgesteuerte Prozessorzuteilung unter strengen Zeitbedingungen. aus Computing, Volume 19, Wien, Springer Verlag, Seiten [8] Scholz, P., 2005, Softwareentwicklung eingebetteter Systeme. Grundlagen, Modellierung, Qualitätssicherung. Berlin; Heidelberg; New York, Springer Verlag [9] Aust, S. und Richter, H., 2010, Space Division of Processing Power For Feed Forward and Feed Back Control in Complex Production and Packaging Machinery, WAC 2010, Kobe, Japan [10] Benini, L. und De Micheli, G., 2002, Networks on chips: a new SoC paradigm, IEEE Computer Magazine, Vol. 35, Nr. 1, Seiten [11] Lee, H.G., Chang, N., Ogras, U. Y., und Marculescu, R., 2007, On-chip communication architecture exploration: A quantitative evaluation of point-to-point, bus, and network-on-chip approaches, ACM Transactions on Design Automation of Electronic Systems, Vol. 12, Nr. 3, Artikel 23 [12] Kumar, S., Jantsch, A., Soininen, J.-P., Forsell, M., Millberg, M., Öberg, J., Tiensyrjä, K., und Hemani, A., 2002, A Network on Chip Architecture and Design Methodology. Proceedings of the IEEE Computer Society Annual Symposium on VLSI (ISVLSI), Seiten [13] Bjerregaard, T. und Mahadevan, S., 2003, A Survey of Research and Practices of Network-on-Chip. Integrated Circuits and Systems Design (SBCCI), Seiten [14] Zeferino, C. A. und Susin, A. A., 2006, SoCIN: A Parametric and Scalable Network-on-Chip. ACM Computing Surveys (CSUR), Vol. 38, Ausgabe 1 [15] Benini, L. und De Micheli, G., 2006, Networks on Chips: Technology and Tools, San Francisco, Morgan Kaufmann [16] Richter, H., 1997, Verbindungsnetzwerke für parallele und verteilte Systeme, Heidelberg, Spektrum 87

19 [17] Grammatikakis, M. D., Hsu, D. F., und Kraetzl, M., 2000, Parallel System Interconnections and Communications, Boca Raton; London; New York; Washington, CRC Press Inc. [18] Xilinx Inc., 2008, MicroBlaze Processor Reference Guide, Product Specification: UG081, v9.0 [19] Rosinger, H.P., 2004, Connecting Customized IP to the MicroBlaze Soft Processor Using the Fast Simplex Link (FSL) Channel, Xilinx Application Note: XAPP529, Version 1.3 [20] AUTOSAR Methodology Version 1.2.2, AUTOSAR Release 3.1, 88