Software-Projektmanagement
Multicore-Software mit APP4MC entwickeln
Fortsetzung des Artikels von Teil 1
Optimierung bei Aufgabenverteilung
Die Integration von Software-Teilen auf einem Multi-Core-Steuergerät ist eine herausfordernde Aufgabe: Zum Integrationszeitpunkt müssen viele verschiedene Entscheidungen getroffen werden, die die Ausführung des Systems maßgeblich betreffen. Zum Beispiel
- die Verteilung der ausführbaren Runnables auf die verschiedenen periodisch aufgerufenen oder durch ein Ereignis geweckten Tasks,
- die Verteilung der Tasks auf die verfügbaren Rechenkerne,
- die Verteilung der Variablen und Puffer auf die zur Verfügung stehenden Speicher-Einheiten.
Man ist gut beraten, die Entscheidungen so zu treffen, dass das System »optimal« ist. Nur ist das eine multifaktorielle Aufgabe. Die zu berücksichtigenden Faktoren sind unter anderen
- gleichmäßige Verteilung der Rechenlast auf die verfügbaren Kerne (Core Balancing),
- Minimierung der der Signallaufzeiten entlang gegebener Signalpfade/Wirkketten,
- Reduktion des Kommunikations-Overheads zwischen verschiedenen Tasks.
Viele Entscheidungen dieser Art beeinflussen sich gegenseitig – z. B. Core Balancing und der Kommunikations-Overhead: Werden zwei Tasks auf denselben Kern gelegt, so wird die Kommunikation minimiert, aber die Lastverteilung in vielen Fällen verschlechtert. Amalthea unterstützt bei einer solchen Optimierungsaufgabe.
Jobangebote+ passend zum Thema
Zu diesem Zweck werden Wirkketten in Amalthea analog zu Autosar als Sequenz von Events dargestellt. Meistens als LabelEvents (Schreib- und Lesezugriffe auf Variablen) oder als RunnableEvents (Start oder Ende eines Runnables). Zusätzlich zum Signalfluss gibt es vom System her Anforderungen an das zeitliche Verhalten einer Wirkkette. In der Regel ist dies eine Anforderung an die maximale Latenz. In Amalthea wird diese als ReactionConstraint abgelegt, das eine maximale (auch minimale) Dauer spezifiziert, die ein Durchlauf einer Wirkkette vom ersten bis zu letzten Event dauern darf.
Werkzeuge, die auf Basis des Amalthea-Modells eine Lösung für das Verteilungsproblem suchen, verwenden u.a. Integer Linear Programming (ILP). Bei großen Aufgaben – wir sprechen von ~103 Runnables und ~104 Variablen [6] – kann so eine optimale Lösung nur mit sehr großem Aufwand und nach längerer Zeit gefunden werden. Deswegen kommen in Boschs firmeninternen Werkzeug zum Beispiel Näherungslösungen mit polynomiellen Laufzeiten wie genetische Algorithmen oder Heuristiken zum Einsatz. Die Bilder 3 und 4 zeigen, wie man in einem großen Steuergeräteprojekt mit Hilfe so einer Verteilungsoptimierung die Kommunikationslast verringert hat.
Unterstützung bei »Object-Code-Sharing«
In aktuellen Generationen von Steuergeräten im Automobil sind neben der Software des Lieferanten auch Software-Anteile von Kunden und weiterer Entwicklungspartner zu integrieren. Da die zugelieferte Software überwiegend in Form von Objekt-Code, quasi als »Black Box«, geliefert wird, erfolgt die Integration in Projekten ohne Amalthea auf Basis von mitgelieferten Dokumentationen über Schnittstellen und Anforderungen an das Scheduling.
Viel zuverlässiger funktioniert so eine Integration aber, wenn diese Dokumentation in Amalthea maschinenlesbar hinterlegt ist und daher im Rahmen der Integration automatisiert nachweisbar ist. Das betrifft z. B. Anforderungen an die Integration wie
- Software-Anteil A muss auf einem Kern mit Feature X (z. B. Lockstep) ausgeführt werden;
- ISR B darf nur eine maximale Response Time von x ms aufweisen;
- Software-Anteil C muss nach Anteil D ausgeführt werden.
Die von Bosch an die Kunden der Steuergeräte-Projekte angebotenen Amalthea-Modelle lassen sich auf einfache Weise mit Amalthea-Modellen der Entwicklungspartner kombinieren und stellen somit ein detailliertes Modell des Gesamtsystems zur Verfügung. Auf Basis dieses Gesamtmodells können die Projektteilnehmer durch die erwähnten Simulationen/Analysen Verifikationsschritte durchführen, die für gewöhnlich den Quellcode benötigen. Hier kann APP4MC/Amalthea als freies Format seine Stärken voll entfalten: Dies ist nun möglich, ohne den Quellcode auszutauschen. Eine Vision, die vielleicht bald Realität wird, hat den Projektnamen Cloud-Based-Solution. Alles dreht sich um ein Amalthea-Modell im Netz (Bild 5). Damit ist eine Modellerstellung als Dienstleistung noch eine Spur eleganter, ebenso die Durchführung von Verifikationsschritten als Dienstleistung. Zugriffsrechte auf das Modell oder Teile davon können maßgeschneidert werden.
Was APP4MC/Amalthea nicht kann
APP4MC bietet kein geeignetes Format zur projektunabhängigen Spezifikation von Automotive-Software-Komponenten und stellt deshalb keine Alternative zu Standards wie Autosar dar. Der Grund dafür ist die bewusste Entscheidung, Varianz nur begrenzt zu unterstützen.
Das domänenspezifische Modell zeigt seine Stärken bei Embedded-Multi-Core-Systemen, welche statisch konfiguriert werden, und bietet daher nur minimalen Support für dynamisch erzeugte Software-Artefakte, wie das Erzeugen von Tasks zur Laufzeit, Verwendung von Timern, Callbacks und komplexeren Datenstrukturen. Die Unterstützung zur Optimierung bei Amalthea findet in der Entwicklungsumgebung statt und nicht zur Laufzeit.
APP4MC bietet keine Sammlung an Algorithmen für Embedded-Systeme oder eine Simulationsumgebung. Es stellt vielmehr ein flexibles und freies Austauschformat für Tools unterschiedlicher Hersteller und Dienstleister zur Verfügung – mit dem Fokus auf Interoperabilität und Usability.
Auf Multi- und Manycore-Systeme ausgerichtet
APP4MC bietet ein offenes Ökosystem für systembezogene Werkzeuge und Dienstleistungen für die Entwicklung von Steuergeräten. Der Fokus liegt dabei klar auf Lösungen für Multi- und Manycore-Systeme.
In Projekten mit mehreren Entwicklungspartnern bietet Amalthea ein architekturunabhängiges Austauschformat, um das dynamische Verhalten des Systems mit allen enthaltenen Software-Komponenten zu beschreiben. Dies ermöglicht die Integrationstests im Rahmen von Gemeinschafts-Projekten, bei denen der Austausch von Quellcode nicht möglich ist. Amalthea hat das Potenzial, sich hier als Standard-Austauschformat zu etablieren und wird bereits von mehreren Tool-, Steuergeräte- und Fahrzeugherstellern verwendet. Durch den Austausch von relevanten Systembeschreibungen auf Basis dieses offenen, maschinenlesbaren Formats werden Diskussionen um Einsicht in Entwicklungsunterlagen und Source-Code pragmatisch vermieden. Für alle in diesem Artikel beschriebenen typischen Anwendungsfälle stehen bereits kommerzielle oder frei verfügbare Werkzeuge zur Verfügung.
Literatur
[1] Grünfelder, S.: Software-Test für Embedded Systems. dPunkt-Verlag, Heidelberg, 2. Auflage 2017.
[2] González Harbour, M.; Grünfelder, S.: Echtzeitanalyse für nebenläufige Systeme. Elektronik 2015, H. 8, S. 56 bis 61.
[3] Bericht auf NTV am 25.11.2012: Neue ICEs bremsen zu langsam. https://www.n-tv.de/wirtschaft/Neue-ICEs-bremsen-zu-langsam-article9599211.html.
[4] Clarke,S. und McDermid, J.: Software fault trees and weakest preconditions: a comparison and analysis. Software Engineering Journal. 8(4): 225-236, 1993.
[5] Grünfelder, S.: Race Conditions; Algorithmen und Werkzeuge zum Erkennen von laufzeitabhängigen Software-Fehlern. Elektronik 2008, H. 17, S. 36 bis 42.
[6] Kramer, S.; Ziegenbein,D.; Hamann, A.: Real world automotive benchmarks for free. Proceedings of the 6th International Workshop on Analysis Tools and Methodologies for Embedded Systems. An mehreren Stellen im Web zu finden.
Die Autoren
- Multicore-Software mit APP4MC entwickeln
- Optimierung bei Aufgabenverteilung
