Konfigurationen möglichst früh evaluieren
Multicore auf dem Weg in den Embedded Markt

Mit Multicore Prozessoren, die mehrere Prozessorkerne (Cores) auf einem Halbleiterchip vereinen, wurde eine
neue Ära in der Prozessortechnologie eingeleitet. Durch Multicore-Technologie kann man die Leistungsfähigkeit bei unverändertem Energieverbrauch steigern oder den Energieverbrauch ohne Leistungseinbußen senken. Das gelingt jedoch nur, wenn die Applikationen so ausgelegt sind, dass die Vorteile tatsächlich nutzbar gemacht werden. Bei PCs, Desktop-Rechnern und Servern dominieren bereits heute Multicoreprozessor-Systeme den Markt.
Wenn man sich die aktuellen Neuigkeiten bei Herstellern von Halbleitern und Echtzeitbetriebssystemen anschaut, so scheint dieser Trend nun auch bei Embedded Systemen Fuß zu fassen. So hat mittlerweile jeder Halbleiterhersteller einen Multicore-Prozessor auf seiner Roadmap und es vergeht kein Tag, ohne dass ein Tool- oder Betriebsystemhersteller neue oder verbesserte Unterstützung für den Einsatz von Multicore-Prozessoren in Embedded Systemen anbietet.

Parallele Verarbeitung bei Embedded Systemen

Embedded Systeme müssen auf Ereignisse der Umwelt schnell reagieren und gleichzeitig komplexe Aufgaben erfüllen. Dies lässt sich mit paralleler Verarbeitung leichter bewältigen. Daher gehören Multiprozess- und Multiprozessor-Applikationen bereits seit vielen Jahren zur Standardausstattung in diesem Bereich. So besteht z.B. ein Computertomograph aus einer Vielzahl von Subsystemen wie Strahlungssteuerung, Bildbearbeitungseinheit, Verwaltungs-, Kommunikations- und Tischsteuerungseinheiten. Jedes dieser Subsysteme wird in der Regel durch einen eigenen Prozessor gesteuert.

Embedded Systeme mit Multicore-Technologie

Multicore Prozessoren sind bereits seit Jahren auf dem Embedded Markt. Einer der bekannteren Vertreter ist der TriCore, den man im Automotivebereich sehr häufig vorfindet. Solche sogenannten heterogenen Multicoreprozessoren haben meist eine gemeinsame CPU für die eigentliche Applikation, einen DSP für schnelle algorithmische Aufgaben wie z.B. Regelungsaufgaben, sowie einen Peripheriecontroller für die Ansteuerung des im KFZ verwendetetn Bussystems. Ihre Aufgabengebiete sind spezifische Bereiche, in denen parallele und schnelle Verarbeitung besonders wichtig ist. Bis vor wenigen Jahren konnten Leistungssteigerungen der Prozessoren primär durch immer höhere Taktfrequenzen erreicht werden. Der aus der höheren Frequenz normalerweise resultierende höhere Energieverbrauch konnte durch den Trend zu immer kleineren Dimensionen weitgehend kompensiert werden. Der Grad der Kompensation hat jedoch die Grenzen des derzeit Machbaren erreicht. Eine weitere Steigerung der Taktgeschwindigkeit ist wegen der damit verbundenen überproportionalen Erhöhung des Energiebedarfs bei der derzeitigen Halbleitertechnologie wirtschaftlich und ökologisch nicht mehr vertretbar. Halbiert man die Maximalfrequenz eines Chips, so sinkt die von ihm aufgenommene elektrische Leistung auf etwa ein Viertel. Daraus folgt, dass zwei Prozessoren mit der halben Frequenz f/2 lediglich die Hälfte der Energie eines mit f getakteten Prozessors benötigen. Theoretisch könnte man also bei gleicher Rechenleistung den Energiebedarf halbieren, oder bei gleichbleibendem Energieverbrauch die Performance zu verdoppeln.

Neuer Spielraum für portable Embedded Systeme

Dieser Effekt eröffnet ganz neuen Spielraum beim Einsatz dieser Technologie in portablen Embedded Systemen, wie Handhelds, Mobiltelefonen, MP3-Playern und Spielekonsolen, die nach immer mehr Leistung bei längerer Batterielaufleistung verlangen. Aber auch für Embedded Multiprozessorsysteme, wie unser eingangs beschriebener Computertomograph, ist die Multicoretechnologie interessant. Im Zuge einer Migration von einer Multiboard- zu einem Multicoreumgebung ließe sich allein durch die Konsolidierung der Hardware ein signifikanter Anteil der Kosten sparen.

Herausforderungen beim Einsatz der Multicore-Technologie

Da Multiprozessorsysteme konzeptionell auf parallele Verarbeitung ausgelegt sind, sollte eine Migration auf Multicore relativ einfach durchzuführen sein. Multicore bedeutet jedoch nicht einfach eine Kombination mehrerer eigenständiger Prozessoren auf einem Chip, sondern dass die Cores in direkter Abhängigkeit zueinander stehen und sich gemeinsame Ressourcen, wie Speicher, Peripheriegeräte und Interrupt Controller teilen. Das konfliktfreie Management der gemeinsamen Ressourcen ist also bereits die erste Herausforderung, speziell wenn verschiedene Betriebsysteme auf den Cores laufen sollen.

Konfliktfreies Management

Grundsätzlich gibt es zwei unterschiedliche Modi, wie man ein Multicore System betreiben kann. Beim Symmetrischen Multiprocessing (SMP) kontrolliert ein Betriebsystem alle Cores, und beim Asymmetrischen Multiprocessing (AMP) läuft auf jedem Core eine eigene Betriebsysteminstanz. Der AMP Modus bietet sich an, wenn die Applikation bereits (wie bei einem Multiprozessorsystem) partitioniert ist oder leicht partitioniert werden kann und nur wenig oder zumindest wohl definierter Datenaustausch zwischen diesen Partitionen stattfindet. Allerdings benötigt ein System im AMP Betrieb generell mehr Speicher und das Aufsetzen der Kommunikation zwischen den Cores ist schwieriger, besonders wenn unterschiedliche Betriebsysteme auf den verschiedenen Cores zum Einsatz kommen. Im SMP Modus ist der Zugriff auf gemeinsame Ressourcen wie Bus und Speicher vereinheitlicht. Aus Sicht des Entwicklers setzt die Applikation nur auf einem Betriebsystem auf, welche die Aufgaben gleichmäßig auf die Cores Verteilt (Dynamic LoadBalancing). Daten können relativ einfach und schnell zwischen den Cores ausgetauscht werden, allerdings muss das Betriebsystem die Cores verwalten und synchronisieren, was wiederum Auswirkungen auf die Verarbeitungsgeschwindigkeit des Betriebsystems hat.

Einfacher und schneller Datenaustausch

Der Einsatz von Multicore-Technologie oder die Migration dorthin birgt eine Reihe von Fragen und Herausforderungen für die Entwickler. Grundsätzlich bringt es noch keinen Vorteil, eine Anwendung, die für sequentielle Ausführung implementiert worden ist, in einer Multicore-Umgebung laufen zu lassen. Erst wenn man beim Design der Applikation die Möglichkeiten der parallelen Ausführung in mehreren „Ausführungspfaden“ berücksichtigt, wird man in einer Multicore-Umgebung bessere Ergebnisse erzielen als in einem herkömmlichen System. Interessanterweise ist gerade der objektorientierte Entwicklungsansatz, welcher vielfach in der modernen Softwarepraxis angewendet wird, vom Konzept her bereits nebenläufig also parallel angelegt.

Objektorientierter Ansatz

Die vollständige Abstraktion des objektorientierten Ansatzes spiegelt sich in der standardisierten Modellierungssprache Unified Modeling Language (UML) wider. Sie ermöglicht es, in jeder Phase der Softwareentwicklung das zu realisierende Softwaresystem über verschiedene Diagrammformen grafisch zu beschreiben. Bemerkenswert dabei ist, dass viele UML Diagrammtypen von Haus aus Nebenläufigkeiten und Parallelitäten unterstützen und eine entsprechende Syntax zur Verfügung stellen. Die UML ist inzwischen weltweit akzeptierten und wird in der Entwicklung von Software und Systemen vielfach eingesetzt. Man sollte also meinen, dass Softwareapplikationen, die mit Hilfe der UML entworfen wurden, ein gewisses Maß an Parallelität unterstützen und somit prädestiniert sind für die echte parallele Verarbeitung in einer Multicore-Umgebung. Das ist allerdings nicht der Fall. Oftmals gibt es eine Diskrepanz wischen dem eigentlichen objektorientierten Entwurf des Systems und seiner Umsetzung, was einen nicht unerheblichen Programmieraufwand für den Programmierer bedeutet. Dieser zusätzliche Aufwand, aber auch die Natur der textuellen Programmiersprachen, verleiten Programmierer dazu, ursprünglich objektorientierte Systementwürfe letztendlich sequentiell umzusetzen. Die Intention des Entwurfes und die tatsächliche Implementierung laufen auseinander.

Moderne UML-Werkzeuge

Hier sind Entwickler im Vorteil, die moderne UML-Werkzeuge einsetzen, die aus den grafischen UML-Modellen Code generieren und die Kommunikationsmechanismen frei Haus und transparent implementieren. IBM Rational Rhapsody gehört zu dieser Kategorie von Tools. Ein Service Layer, der auf dem Betriebsystem aufsetzt, stellt die oben genannten Mechanismen zur Verfügung. Der Entwickler kann sich damit auf den eigentlichen Entwurf, das Verhalten der Objekte und die Kommunikation zwischen den Objekten konzentrieren. Routinearbeiten und Implementierung der Basisdienste werden vom Tool übernommen. Zur Besonderheit gehört, dass das Laufzeitverhalten der Applikation grafisch auf UML Ebene nachverfolgt und gesteuert werden kann. Hierbei handelt es sich nicht etwa um eine Simulation, sondern um den tatsächlichen, sozusagen auf UML Ebene visualisierten Code der Applikation. Das besondere: Dieses „grafische Debuggen“ der Applikation ist auch auf einer Target Plattform möglich. Verhalten der Zustandsautomaten, Aktivitätendiagramme, Objektinteraktion anhand von Sequenzdiagrammen, Lebenszyklus der Objekte, Variablenbelegung, all diese Aspekte sind in Rhapsody einsehbar während die Applikation ausgeführt wird. Das Systemverhalten kann auf der grafischen Modellebene validiert werden und im Weiteren auch getestet werden.

Einsehbar während die Applikation läuft

Ein weiterer Vorteil dieser Herangehensweise ist die Möglichkeit, bereits zu einem frühen Zeitpunkt Prototypen zu erzeugen. Dank eines Operating System Abstrac­tion Layers (OSAL), der das darunterliegende Betriebssystem abstrahiert, kann die Applikation quasi per Knopfdruck für verschiedene Betriebsysteme übersetzt werden. Die nötigen OSAL Adapter für die gängigsten Embedded Betriebsysteme auf dem Markt sind Bestandteil des Lieferumfangs von Rhapsody. Gerade in der Multicoreentwicklung wird dieses Rapid Prototyping eine bedeutende Schlüsselfunktion einnehmen, da dies eine elegante Möglichkeit bietet die Konfigurationsfragen frühzeitig zu beantworten. Frühes Prototyping versetzt die Entwickler in die Lage, das System bereits in einer möglichst frühen Entwurfsphase zu evaluieren, die richtige Konfiguration zu identifizieren und zu optimieren. Aber auch für den eigentlichen Entwicklungsprozess ist Rapid Prototyping hilfreich, um Systemanforderungen auch noch während der Entwicklung ändern zu können.

Systemanforderungen während der Entwicklung ändern

Im nächsten Schritt wird dann das System entsprechend seiner Architektureigenschaften auf die einzelnen Cores aufgeteilt (einzelne Target Prototypen). Im konkreten Fall bedeutet dies, dass das FlightInformationSystem nicht mehr mit dem FlightController verbunden ist. An die Stelle des FlightControllers tritt ein Stellvertreter (sogenanntes Proxy). Dieser Proxy bedient die gleichen Schnittstellen wie ursprüngliche FlightController, realisiert aber über definierte Intercore Kommunikationsmechanismen die Verbindung zum eigentlichen FlightController auf dem anderen Core. Das FlightInformationSystem selbst ändert sich nicht, für dieses Modul ist die Kommunikation völlig transparent. Dieses Vorgehen verbunden mit den Möglichkeiten der Modelbasierten Entwicklung hat entscheidende Vorteile. So sind etwa Host- und Target Prototyp nicht redundant. Eine neue Funktionalität die in den Host Prototype einfließt und getestet wurde, ist automatisch Bestandteil des Target Prototyps. (Es gibt nur ein FlightInformationSystem). Weiterhin kann der Target Prototype auf beliebige Betriebsysteme portiert werden und sogar die Kommunikation zwischen den Subsystemen ist dank des Proxies von der physikalischen Implementierung unabhängig. Alles in allem, ideale Voraussetzungen, diverse Konfigurationen in einer möglichst frühen Entwurfsphase zu evaluieren. Autoren: Frank Braun, Rhapsody Program Manager, IBM Rational;