Echtzeit-Systemdesign mit Hilfe der AUTOSAR-Methodik
Echtzeitfähigkeit ist alles
Fortsetzung des Artikels von Teil 3
Bewältigung der Herausforderungen
Würde das Modell dagegen die Möglichkeit bieten, einer Task abhängig von einer äußeren Bedingung unterschiedliche Verarbeitungszeiten zuzuweisen, müssten unterschiedliche Fälle validiert werden. Pessimistische Festlegungen in einem Modell zu treffen, hat allerdings den Nachteil, dass der Generator möglicherweise kein taugliches Systemdesign findet, obwohl es unter Praxisbedingungen eigentlich eines gäbe. Speziell auf dem Automotive-Sektor stellt die Kostenminimierung eine wichtige Restriktion für das Systemdesign dar, weshalb die vorhandenen Ressourcen so weit ausgeschöpft werden müssen, wie es die Sicherheits-Anforderungen eben zulassen. Das Zugrundelegen pessimistischer Festlegungen hat aber zur Folge, dass Ressourcen ungenutzt bleiben und sich die Kosten des Systems dadurch erhöhen. Um ein besseres, dem Optimum näher kommendes Systemdesign zu erhalten, werden mehr detaillierte Informationen benötigt.
Wegen der zwei erklärten Zielsetzungen, nämlich die Komplexität transparent zu machen und die Ressourcen maximal auszuschöpfen, ist es sehr wichtig, die Granularität der Modell-Abstraktion sorgfältig festzulegen. Ein zu hoher Abstraktionsgrad liefert Ergebnisse, die zu viele Ressourcen vergeuden, wodurch das System zu teuer und für den Praxiseinsatz möglicherweise untauglich wird. Ein zu detailliertes Modell dagegen kann zur Folge haben, dass das Ermitteln eines geeigneten Systemdesigns für heutige Computersysteme zu komplex ist.
Die wichtigsten Probleme, die im vorigen Abschnitt herausgearbeitet wurden, sind die Komplexität der betrachteten algorithmischen Probleme, der Abstraktionsgrad des Modells und die Vollständigkeit der verwendeten Informationen.
Algorithmische Probleme wie das Berechnen eines optimalen ECU-Schedules, das Bestimmen eines optimalen Bus-Schedules und das Herausfinden der optimalen Verteilung der Software-Komponenten auf das Bordnetz sind sehr komplex. Die meisten dieser Aufgaben sind „NP-vollständige“ Probleme. Unter NP-vollständigen Problemen versteht man eine Klasse von Problemen, die allesamt so hart sind wie das einfachste Problem in der betreffenden Klasse. Zurzeit erfordern sämtliche bekannten Algorithmen, die eine exakte Lösung für ein NP-vollständiges Problem berechnen, eine exponentiell zunehmende Zeitspanne.
Zur Berechnung eines optimalen statischen ECU-Schedules für eine bestimmte Anzahl von Tasks gilt, dass die Rechenzeit exponentiell mit der Anzahl der Tasks wächst, denn das Herausfinden einer Lösung erfordert generell das Ausprobieren aller möglichen Kombinationen für die Verteilung der Tasks entlang der Zeitachse.
Positiv ist zu vermerken, dass das Herausfinden des optimalen ECU-Schedules nicht unter allen Umständen erforderlich ist. Heutzutage wird das Ermitteln eines ECU-Schedules mit einer mentalen Methode gelöst, nämlich mit dem Systemintegrator der ECU, und dieser liefert keine Aussage darüber, ob dieser Schedule optimal ist. Es reicht aus, einen ECU-Schedule zu finden, der korrekt ist (d.h. keine Task-Überlappungen aufweist) und der die Timing-Anforderungen erfüllt. Man hofft also darauf, dass es Algorithmen gibt, die mit vertretbarem Zeitaufwand einen funktionierenden ECU-Schedule finden können.
Diese Lösung muss keineswegs das absolute Optimum sein. Sie muss lediglich ihre Aufgabe erfüllen in dem Sinn, dass sämtliche Anforderungen einschließlich der Timing-Vorgaben eingehalten werden.
In diesem Kontext werden einige vielversprechende Näherungen, heuristische Algorithmen wie genetische oder Greedy-Algorithmen sowie stochastische Verfahren untersucht und man prüft derzeit, ob diese geeignet sind, mit akzeptablem Zeitaufwand Lösungen zu finden. Heuristische Algorithmen bieten zwar keine Garantie, dass sie eine Lösung finden, doch in einer durchschnittlichen Situation kommen sie wesentlich schneller zu einem Ergebnis. Wird keine Lösung gefunden, bedeutet dies jedoch nicht, dass es keine gibt.
Der zweite Aspekt ist die Wahl des passenden Abstraktionsgrads. Im Kern geht es darum, den richtigen, weder zu allgemeinen noch zu detaillierten Mittelweg zu finden. Bei zu starker Detaillierung sind Zweifel angebracht, ob tatsächlich alle modellierbaren Informationen vom Anwender modelliert werden. Es ist vorstellbar, dass man bei einer zu sehr ins Detail gehenden Modellierung eines Softwaresystems schließlich kein Modell mehr hat, sondern nur mehr eine weitere Implementierungsart. Die mit der Methodik angesprochene Zielgruppe wird aber ihr Interesse verlieren, wenn es darauf hinausläuft, die Software zweimal zu implementieren.
Bei zu starker Abstraktion dagegen wird die Berechnung einer Lösung möglicherweise zu pessimistisch ausfallen. Unter Umständen findet ein Algorithmus keine funktionierende Lösung mehr, obwohl ein Systemarchitekt eine ermitteln könnte.
Zwischen Systemarchitekt und Algorithmus gibt es den Unterschied, dass ersterer auf gewisses implizites Wissen über das System zurückgreifen kann, das im Modell nicht enthalten ist. Diese Kenntnisse ermöglichen ihm das Erstellen eines funktionsfähigen Schedules, den ein ausschließlich auf das in dieser Hinsicht unvollständige Modell angewiesener Algorithmus niemals finden könnte.
Jobangebote+ passend zum Thema
- Echtzeitfähigkeit ist alles
- Literatur:
- Tasks und Runnables
- Bewältigung der Herausforderungen
- Es bleiben Fragen offen
- Timing-Chains
- Der AUTOSAR-RTE-Generator
