Software-Projektmanagement Multicore-Software mit APP4MC entwickeln

Multicore-Software für Steuergeräte muss viele Bedingungen einhalten: Ressourcen-Zuweisung, Timing-Verhalten, Ablaufreihenfolge. Die offene Plattform APP4MC sorgt dafür, dass Teams alles im Blick behalten, selbst ohne den Quellcode der anderen zu kennen.

APP4MC ist eine Open-Source-Plattform für die Beschreibung von eingebetteten Multi- und Manycore-Software-Systemen, die die Planung, Optimierung und Analyse solcher Systeme gestattet. Die Entwicklung der APP4MC (Application Platform Project for Multi Core) begann 2011 im Rahmen zweier öffentlich geförderter ITEA3-Projekte. 2016 wurde APP4MC als offizielles Projekt von der Eclipse Foundation aufgenommen und wird seither in diesem Rahmen weiterentwickelt. Zahlreiche Partner aus Industrie und Forschung beteiligen sich nach wie vor daran oder bieten Lösungen und Dienstleistungen auf Basis dieser Plattform an.

Die größte Verbreitung hat APP4MC momentan in der europäischen Automobilindustrie. In dieser Branche wird es immer üblicher, dass der Fahrzeughersteller Code-Teile in Form von Object Code für ein zugekauftes Steuergerät beisteuert. Dem Zulieferer obliegt dann die Durchführung von Integrationstests. Insbesondere bei sicherheitskritischen Steuergeräten sind auch Timing-Analysen durchzuführen [1]. Die Rahmenbedingungen dafür sind in diesem Projekt­umfeld denkbar komplex. Amalthea erlaubt die Durchführung von diesen Tests und Analysen in einem Umfang, der bislang nicht möglich war: Selbst wenn ein Zulieferer den Quellcode nicht preisgibt, kann mit einem Modell seines Codes zuverlässig gearbeitet werden. Um zu verstehen, wie das funktioniert, müssen wir uns zunächst ansehen, welche Information in Amalthea hinterlegt ist und wie ein solches Modell erzeugt wird.

Die Gegenüberstellung in Tabelle 1 verdeutlicht die Unterschiede zwischen einer Desktop-Software auf einer Multi-Core-CPU und einem Steuergerät mit Multi-Core-CPU – und damit auch die Herausforderungen an Amalthea/APP4MC:

Modelle aus Teilmodellen

Amalthea gliedert sich in unterschiedliche Teilmodelle, siehe vereinfachte Darstellung in Bild 1. Basis des Modells ist die Eclipse-EMF-Technologie sowie eine XML-Spezifikation. Tabelle 2 beschreibt die wichtigsten Teilmodelle eines Amalthea-Modells.

Da nicht für jeden Anwendungsfall alle Teilmodelle benötigt werden, lassen sich mit APP4MC Teilmodelle beliebig hinzufügen, entfernen oder austauschen und auf Konsistenz prüfen. Somit lässt sich z. B. durch den Austausch des Hardware-Modells eine neue Prozessor-Generation abbilden und evaluieren; durch den Austausch des Mapping-Modells lässt sich die Auswirkung einer alternativen Verteilung von Rechenaufgaben auf die Rechnerkerne evaluieren. Im Rahmen einer Simulation oder Analyse lässt sich zudem schnell feststellen, ob solch eine Änderung eine Verletzung der im Constraints-Modell hinterlegten Anforderungen bewirkt. Eine detaillierte Beschreibung der einzelnen Modellelemente sowie Beispiele finden sich in der umfangreichen Online-Dokumentation von APP4MC.

Ein Amalthea-Modell kann dabei die gesamte Produktentwicklung begleiten: in frühen Projektphasen werden im Modell Schätzungen/Erfahrungswerte hinterlegt; damit unterstützt das Modell bei der Planung und bei ersten Simulationen. Solche Schätzungen können z. B. Ausführungszeiten sein. In späteren Projektphasen werden die geschätzten Werte durch Messwerte ersetzt. Im Beispiel könnten sodann am Modell Analysen zur Verifikation von Echtzeiteigenschaften durchgeführt werden – eine Schedulability-Analyse zum Beispiel, wie in [1] und [2] beschrieben.

Erstellung von Amalthea-Modellen

Vor der Erstellung eines Amalthea-Modells ist es ratsam, den Anwendungszweck (Use Case) klar zu definieren. Je nach Anwendungszweck ist es weder nötig noch sinnvoll, sämtliche Teilmodelle zu befüllen. Es gilt, die richtige Menge an Informationen für den konkreten Anwendungsfall bereitzustellen. Dazu zwei Beispiele:

Use Case 1: Laufzeitsimulation

Für eine einfache Laufzeitsimulation ist es vollkommen ausreichend, z. B. nur die Tasks und ISRs sowie deren Laufzeiten im Software-Modell, den Prozessor im Hardware-Modell sowie eine Softwareverteilung im Mapping-Modell und einen Arbeitspunkt im Stimuli-Modell zu berücksichtigen.

Use Case 2: Verifikation von Echtzeit­anforderungen an Ursache-Wirkungsbeziehungen

Jede Berechnung benötigt Zeit, und oft ist für das Vorliegen des Ergebnisses einer Berechnung eine Zeitschranke vorgegeben. Eingabe für eine Berechnung, die z. B. zyklisch stattfindet, können wieder andere Berechnungen sein, die in einem anderen zyklischen Zeitraster berechnet werden. Es entsteht eine »Wirkkette« von Berechnungen (Bild 2). Bis das Endergebnis einer Berechnung vorliegt, müssen potenziell viele Faktoren/Abhängigkeiten berücksichtigt werden.

Ein prominentes Beispiel, bei dem dies nicht erschöpfend berücksichtigt wurde, ist in [3] beschrieben: eine Notbremsung wurde zeitverzögert eingeleitet. Amalthea erlaubt solche Wirkketten zu analysieren. Dazu müssen die konkreten Zugriffe auf Ergebnisse von Runnables im Software-Modell und die Definitionen der Wirkketten im Con­straints-Modell erstellt werden. Ein Runnable ist eine atomare Software-Einheit/Funktion, die (bis auf die Notwendigkeit des Austausches von Eingabe-Daten) unabhängig von anderen Software-Einheiten laufen kann. Ein periodischer Task kann z. B. mehrere Runnables beherbergen und ein Runnable kann gegebenenfalls in einen periodischen Task mit geringerer Periodendauer verschoben werden, um die Reaktionszeit des Systems zu verbessern.

Der zweite Use Case macht klar, dass das Software-Modell umfangreich sein muss, um entsprechende Nachweise zu gestatten. Das möchte und kann man nicht per Hand machen. Die APP4MC-Plattform stellt daher einen auf LLVM/CLANG basierten Source-Code-Explorer SCA2Amalthea zur Verfügung, der in der Lage ist, detaillierte Modelle auf Source-Code-Basis automatisch zu erzeugen. Diesen Komfort hat man beim Constraint-Modell nicht. Hier benötigt es Handarbeit und Erfahrung. Weiter stehen in APP4MC Visualisierungsfunktionen, Editoren, Beispielmodelle sowie Diff- und Merge-Funktionalität zur Verfügung, die bei der Modellerstellung und -nutzung unterstützen.

In den meisten Fällen werden die Modelle aber automatisch oder zumindest mit Werkzeugunterstützung erzeugt. Der Geschäftsbereich Powertrain Solutions der Robert Bosch GmbH bietet seinen Kunden Amalthea-Modelle auf Basis von

  • Spezifikation (z.B. Autosar/ASAM-MDX),
  • Source-Code (z.B. C- und H-Dateien) oder
  • binären Artefakten (z. B. Hex-, Elf-, Objekt-Dateien)

für nahezu alle Steuergeräteprojekte an. Der Kunde kann diese Modelle mit eigenen Modellen kombinieren und nach Belieben in Simulationen und Analysewerkzeugen verwenden. Vo­raussetzung dafür ist eine Amalthea-Schnittstelle bei den verwendeten Werkzeugen. Welche Verifikationsschritte man in Simulatoren auf Basis von Amalthea machen kann, werden die folgenden Abschnitte erläutern.

Unterstützung in Projektphasen

Für sicherheitskritische Echtzeitsysteme ist Absicherung von zentraler Bedeutung. Je früher potenzielle Fehler und Probleme vermieden bzw. erkannt und behoben werden, desto geringer und besser planbar ist das Risiko für ein Entwicklungsprojekt. Da unterstützt Amalthea mit dem Konzept, ein Modell für alle Entwicklungsphasen bereitzustellen. Auf Basis dieses einen Modells kann in frühen Projektphasen zum Beispiel mit Hilfe von Simulation die Verteilung von Tasks auf Rechnerkerne mit Hilfe von Speicherverwendungs- und Laufzeitabschätzungen erfolgen und eben diese Verteilung optimiert werden. Zu einem späteren Zeitpunkt kann man die Schätzung mit Messungen vergleichen und ersetzen. Das funktioniert auch reibungsfrei, wenn die Schätzung und die Messung in anderen Werkzeugen erfolgen. Letztendlich kann ein weiteres Werkzeug auf Basis des Modells eine Schedulability-Analyse durchführen.

Bei der Amalthea-Entwicklung wurde darauf geachtet, dass für Multitasking- und Echtzeitsysteme typische Software-Fehler in allen Projektphasen adressiert werden. Diese sind [4]:

  • Verletzung von Anforderungen an die notwendige Reihenfolge von Berechnungen
  • Race Conditions, insbesondere Data Races
  • Deadlocks, LivelocksSeiteneffekte durch nicht wiedereintrittsfähigen Code
  • Bereitstellung von (sonst korrekten) Ergebnissen zum falschen Zeitpunkt
  • Jitter

Analyse und Simulation

Die Liste der typischen Software-Fehler eines Echtzeitsystems aus [4] zeigt, dass Zeit sehr häufig eine Rolle spielt. Das Einhalten von Anforderungen an das Zeitverhalten kann in funktionalen Systemtests eines dynamisch geplanten, nebenläufigen Systems im Allgemeinen nicht getestet werden, weil man nicht davon ausgehen kann, den Worst Case getestet zu haben. So ist man auf Analysemethoden angewiesen. Das Amalthea-Modell bietet daher umfangreiche Möglichkeiten, das Zeitverhalten eines Systems zu modellieren. Je nach Bedürfnis können diese Modelle skaliert werden. Während APP4MC selbst keine Umgebung zur Echtzeitverifikation zur Verfügung stellt, gibt es jedoch kommerzielle Anbieter (Timing-Architects und mit Einschränkungen Symtavision), die einen Import und/oder Export nach Amalthea unterstützen.

Mit Hilfe so eines Werkzeugs kann eine zuvor schon erwähnte Schedulability-Analyse durchgeführt werden, die den Worst Case errechnet. Diese Berechnung ist besonders bei Multi-Core-Systemen nicht trivial. Mit dem Worst Case lassen sich auch maximale Reak­tionszeiten oder die maximale CPU-Last ermitteln. Auf Basis dieser Daten ist die Verifikation der Einhaltung der zuvor erwähnten Wirkketten möglich. Ähnlich wie das Zeitverhalten in der Schedulability-Analyse verifiziert wird, lässt sich auch das Einhalten von anderen Anforderungstypen mit Hilfe von Simula­tionswerkzeugen untersuchen. Dazu gehören in Amalthea die »Execution Order Constraints« und sogenannte »Data Age Constraints«.

Simulation und Analyse können nicht nur zur Bestimmung der Kennwerte eines einzelnen Steuergeräts, sondern auch eines ganzen verteilten Systems verwendet werden. Ähnlich wie Tasks auf einer CPU durch Synchronisationsmechanismen voneinander abhängen, können mehrere Steuergeräte miteinander Kommunikationsabhängigkeiten über ein Bussystem (wie CAN oder Flexray) aufweisen. Auch hier kann man mit einer Schedulability-Analyse für das Bussystem den Worst Case von Wirkketten berechnen, die gegebenenfalls über mehrere Steuergeräte reicht [2]. Amalthea ist für solche Anwendungen entsprechend vorbereitet und gestattet die Definition der nötigen Inputs für solche umfangreichen Analysen.

Last but not least stellt Amalthea alle Daten für eine automatische Data-Race-Analyse bereit. Werkzeuge für Windows und Unix dafür gibt es seit mehr als zehn Jahren am Markt und die dahinterliegenden Techniken wurden vor vielen Jahren bereits in der Elektronik vorgestellt [5]. Was bei der Verwendung eines Amalthea-Modells aber revolutionär ist, ist die Tatsache, dass zur Analyse kein Quellcode vorliegen muss. Damit können mehrere Firmen Software für ein Steuergerät zur Verfügung stellen, den Quellcode vor den anderen Firmen geheim halten, und dennoch mit einer solchen Analyse zuverlässig Data Races erkennen: Jede Firma erstellt ihr eigenes Amalthea-Modell automatisch aus dem Quellcode, die Modelle werden mit Hilfe von APP4MC verknüpft, auf dem Gesamtmodell läuft dann die Data-Race-Analyse. Hand in Hand mit einer Data-Race-Analyse geht in der Regel das automatische Auffinden von Deadlocks [5].