ASCET-MD f Frank Schnicke schnicke11@cs.uni-kl.de 1 Einführung Heutzutage findet der Großteil der Innovation im Automobilsektor auf der Softwareseite statt. Da die meisten Anwendungen in diesem Sektor von außerordentlicher Sicherheitsrelevanz sind, wird nach Wegen gesucht, Fehlerquellen zu eliminieren. Ein weiteres Ziel ist es, effizient zu abstrahieren, da sich Zielsysteme sehr stark von der Implementierung und der Hardwareseite unterscheiden können und durch diese Abstraktion dann sowohl Entwicklungskosten und Zeit gespart werden können. Ein Lösungsansatz beider Probleme bietet die automatische Codegenerierung aus formalen Modellen. Im Folgenden soll zuerst die generelle Herangehensweise zur Generierung von formalen Modellen vorgestellt werden. Danach wird auf ein Werkzeug eingegangen, dass sich die oben genannten Punkte als Ziel gesetzt hat und sie durch modellgetriebene Softwareentwicklung löst. 2 Modellgetriebene Softwareentwicklung Ziel der modellgetriebenen Softwareentwicklung ist es, formalen Modelle für Probleme zu generieren, um aus ihnen automatisch lauffähigen Code zu erzeugen. Dabei soll eine Abstraktion von der Zielsprache und dem Zielsystem stattfinden, z.b. wird die eventuelle Einschränkung der Wortbreite vom Zielsystem erst zur Compile-Zeit beachtet. Es muss also nicht für jedes Zielsystem neu entwickelt werden, ein Wechsel dieser zieht nur eine Parameteranpassung nach sich. Oft werden zur Modellierung sogenannte domänespezifische Sprachen, kurz DSL für domain-specific language, entwickelt und genutzt. Diese sind, wie ihr Name vermuten lässt, für eine spezielle Domäne, also ein spezielles Problemfeld, entwickelt und bilden dieses komplett ab. Ein nicht zu vernachlässigender Nachteil ist aber der hohe Initialaufwand, der zur Entwicklung der DSL notwendig ist.
3 Überlick über ASCET Bei ASCET(Advanced Simulation and Control Engineering Tool) handelt es sich um eine von ETAS entwickelte Produktfamilie, die zur modellbasierten Entwicklung Eingebetteter Automobilsoftware genutzt wird. Das Tool existiert seit 1997 und wird hauptsächlich für die Entwicklung von Software für Brems-, Lenkund Motormanagementsystemen eingesetzt. Laut eigenen Angaben existieren weltweit über 68 Millionen Steuergeräte, deren Software mit ASCET erzeugt wurde ([5]). Neben den drei unten genannten stellt ASCET unter anderem Tools zum effizienten Arbeiten mit Versionsverwaltungen zur Verfügung. ASCET-SE (Software Engineering): ASCET-SE ist ein nach den Sicherheitsstandarts der IEC61508 und der ISO26262-Norm zertifiziertes Tool zur automatischen Codegenerierung, dass verschiedene Standards unterstützt. Als Ausgangsbasis nimmt es das formale Modell, welches in ASCET-MD generiert wurde. ASCET-MD (Modeling and Design): Auf ASCET-MD wird in diesem Vortrag gesondert im 4. Abschnitt eingegangen. ASCET-RP (Rapid Prototyping): ASCET-RP stellt Möglichkeiten zum Rapid Prototyping von Softwarefunktionalitäten sowohl im Vehikel als auch in der Testumgebung zur Verfügung. Dadurch kann bereits früh die Validation der Funktionen vorgenommen und eventuelle Probleme direkt erkannt werden. Diese unterschiedlichen Komponenten sollen eine möglichst schnelle, einfach zu überblickende und effiziente Entwicklung erlauben, die dabei die wachsenden Softwaregröße und die sicherheitsrelevanten Aspekten der Automobilbranche berücksichtigt. 4 Generelle Struktur von ASCET-MD Das Ziel von ASCET-MD ist, sowohl eine möglichst gute Abstraktion von sowohl Hardware als auch realisierungsnahen Details herzustellen, in dem Spezifikation und Design streng getrennt werden. Wie dies im Einzelnen vonstatten geht, wird in den folgenden Abschnitten beschrieben. 4.1 Projekt Das Projekt ist der übergeordnete Container. Es verwaltet sowohl eine Sammlung von Komponenten als auch das Betriebsystem, wobei eine Komponente verschiedene Prozesse beinhalten kann, die innerhalb des Betriebsystems einzelnen Tasks zugeordnet werden. Weiterhin wird im Projekt sowohl die Definition der Interprozesskommunikation vorgenommen, als auch der Task-Schedule für das Echtzeitbetriebsystem erstellt. Für eine schematische Übersicht siehe Abbildung 1 auf Seite. Zur Definition eines Moduls bzw. eines Prozesses und wie die Interprozesskommunikation vonstatten geht, siehe Abschnitt 4.2. 4.2 Komponente Die zentrale Idee der Komponenten ist die Kapselung, man kann sich eine Komponente ähnlich einer Klasse in z.b. C++ vorstellen. Jede Komponente besitzt eine eindeutig definierte Schnittstelle nach außen
Abbildung 1: Interne Struktur eines Projektes, Quelle: [1] hin, die beschreibt auf welche Art und wann auf die in ihr spezifizierten Algorithmen zugegriffen werden soll. Außerdem beinhaltet sie verschiedene Elemente, die von den Methoden oder Prozessen genutzt werden können. Weiterhin wird der Datenaustausch mit anderen Komponenten spezifiziert. Es wird zwischen zwei Komponententypen unterschieden: Module und Klassen. 4.2.1 Module Ein Modul beschreibt verschiedene Prozesse sowie Methoden, die es beinhaltet. Prozesse werden vom Betriebsystem aktiviert, wobei keine Parameter übergeben werden können. Stattdessen greifen die Prozesse auf sogenannte Messages, also globale Variablen, zu, wodurch eine effektive Kommunikation gewährleistet ist. Bei einer Methode handelt es sich um eine Funktion im klassischen Sinn, sie besitzt Argumente und einen einzigen Rückgabewert. Weiterhin kann ein Modul Ressourcen beinhalten, die nur von jeweils einem Prozess gleichzeitig genutzt werden können. Um dies widerzuspiegeln verfügt jede Ressource über Funktionen zum Belegen und Freigeben dieser. Es besteht die Möglichkeit, die in einem Modul beschriebene Funktionalität in mehrere Prozesse aufzuspalten, was den Vorteil hat, dass nur die empfindlichen Teile eines Algorithmus mit hoher Frequenz ausgeführt werden müssen. Außerdem können die verschiedenen Teile zu unterschiedlichen Zeiten abgearbeitet werden, was sich in einer schnelleren Gesamtausführungszeit im Vergleich zur Beschreibung in nur einem Prozess äußert. Der Vorteil ist, dass sich, trotz dieser Zerlegung, die komplette Algorithmusbeschreibung noch an einem Platz befindet, nämlich innerhalb des Moduls. Ein Nachteil von Modulen ist allerdings, dass nur eine Instanz gleichzeitig innerhalb eines Projektes bestehen darf.
4.2.2 Klassen Um die Einschränkung der Instanziierung betreffend von Modulen zu vermeiden, bietet sich die Verwendung von Klassen an. Jede Instanz einer Klasse besitzt ihre eigenen Parameter, wobei auch globale Variablen, die sich alle Instanzen der selben Klasse teilen, möglich sind. Allerdings haben Klassen den Nachteil, dass sie nicht die Echtzeit-Interprozesskommunikation über Messages unterstützen. Die Begründung ist, dass Prozesse statisch einem festen Task zugeordnet werden. Außerdem können Klassen mehrere Instanzen haben, was das Datenkonsistenzschema von ERCOSek (Embedded Real-time Control Operation System) aber nicht unterstützt. 4.3 Scheduling ASCET-MD unterstützt folgende drei Arten von Task-Scheduling: Kooperativ: Kooperative Tasks unterbrechen die Ausführung des aktuellen Prozesses nicht, wenn ein höherpriorisierter Task aktiviert wird, pausieren aber sobald dieser abgearbeitet ist. Präemptiv: Ein präemptiver Task kann jederzeit, auch mitten in einer Prozessausführung unterbrochen werden. Nicht-unterbrechbar: Nicht-unterbrechbare Tasks sind zu vermeiden, da ihre Funktionalität auch über präemptive oder kooperative Tasks realisiert werden kann, ihre Konfiguration aber um vieles komplizierter ist. Ihr Vorhandensein ist in der gewünschten OSEK-Konformität begründet. Prozesse werden zu Tasks zusammengefasst, wobei jeder Task einer dieser Scheduling-Gruppe und innerhalb dieser einer Priorität zugeordnet wird. Dem Benutzer ist es möglich, die Anzahl Prioritätsebenen pro Gruppe manuell zu konfigurieren um den Speicherbedarf der Scheduler-Tabelle zu optimieren. Um diese drei Scheduling-Arten gleichzeitig zu realisieren, werden den kooperativen Tasks die niedrigsten Prioritäten zugewiesen, den nicht-unterbrechbaren die höchsten. Zwischen diesen beiden Prioritätsebenen befindet sich dann die Prioritätsebene der präemptiven Tasks. 4.4 Interprozesskommunikation Wie bereits erwähnt, erfolgt die Interprozesskommunikation per Messages. Für jede Message kann eine Sichtbarkeit definiert werden, z.b. Messages, die nur für die Prozesse desselben Moduls sichtbar sind. Da es, außer bei nicht-unterbrechbaren Prozessen, jederzeit zu einer Ausführungsunterbrechung innerhalb eines Prozesses kommen kann, und Messages asynchron sind, muss die Datenkonsistenz innerhalb einer Prozessausführung gesichert werden. Dies geschieht über lokale Kopien von Messages, die automatisch direkt zum Beginn der Prozess-Abarbeitung angelegt werden. Nach erfolgreicher Ausführung werden dann diese Messages wieder zurück in die globalen Messages geschrieben. Eine Message kann also als geschütze, globale Variable verstanden werden. ASCET-MD bietet die Optimierungsmöglichkeit, nur Messages auf die mehrere Prozesse gleichzeitig Schreibzugriff haben, durch lokale Kopien gegen Inkonsistenzen abzusichern. Dadurch werden unnötige Kopien vermieden und Speicherplatz gespart. Messages können außerdem in eine der drei folgenden Klassen eingeteilt werden: Send: Send-Messages können von dem aktuellen Modul nur geschrieben, aber nicht gelesen werden. Receive: Receive-Messages verhalten sich umgekehrt zu Send-Messages. Send/Receive: Bei Send/Receive-Messages handelt es sich um eine Kombination der oben genannten, sie können also sowohl gelesen als auch geschrieben werden.
4.5 Beschreibungsvarianten ASCET-MD bietet verschiedene Möglichkeiten zur Beschreibung von Prozessen und Modulen, wobei jede ihre Vor- und Nachteile hat. Es obliegt also dem Nutzer, die jeweils für ihn am geeignetste Beschreibungsvariante zu wählen. 4.5.1 ESDL Bei der Embedded Systems Description Language, kurz ESDL, handelt es sich um keine Programmiersprache, sondern um eine reine Modellierungssprache. Bis auf gewisse Einschränkungen kann sie als eine hoch spezialisierte Variante von Java betrachtet werden, sie stellt also alle bekannten Konstrukte wie If, Switch, For, While zur Verfügung. Eine dieser Einschränkungen ist z.b., dass keinerlei String- Variablen zur Verfügung stehen, da es sich um eine rein für den Gebrauch in Eingebetteten Systemen, im speziellen Kraftfahrzeuge, entwickelte Sprache handelt, und dort diese keinen sinnvollen Zweck erfüllen. Weiterhin ist ESDL echtzeitfähig, wodurch aber Abstriche in der Objektorientiertheit in Kauf genommen werden müssen. Das heißt allerdings nicht, das diese gar nicht zur Verfügung steht. Der Schwerpunkt bei ESDL liegt auf der Kontrollstruktur, weswegen sie auch zur Modellierung von Final State Machines genutzt werden kann. Abbildung 2 zeigt beispielhaft, wie ESDL in ASCET-MD genutzt wird. Abbildung 2: Beschreibung eines Integrators in ESDL, Quelle: [1]
4.5.2 ANSI-C Jeder Prozess kann auch direkt über ANSI-C-Code spezifiziert werden. Dies hat allerdings den Nachteil, dass der Nutzer bei Messages selbst auf die Datenkonsistenz achten muss, da ASCET-MD z.b. bei der Nutzung von Makros nicht erkennt, dass auf Messages zugegriffen wird. Ohne diese Erkennung ist aber nicht gewährleistet, dass genutzte Messages wieder von der lokalen Kopie in die globale Message zurückgeschrieben wird. Es ist möglich, eigenen Quellcode in ASCET-MD einzubinden, Funktionsaufrufe funktionieren dann wie gewohnt. Um komfortabel auf ASCET-eigene Konstrukte wie Messages oder Ressourcen zugreifen zu können, wird eine große Auswahl von Zugriffsmakros zur Verfügung gestellt. Im folgenden der, zu der ESDL-Beschreibung äquivalente Integrator in ANSI-C. Hierbei ist memory eine globale Variable innerhalb des Integrationsmoduls, mx und mn sind Konstanten. 1 double i n t e g r a t e ( double dt, double K, double i n ) { 2 memory += K dt i n ; 3 i f ( memory > mx) 4 memory = mx ; 5 6 i f ( memory < mn) 7 memory = mn ; 8 9 return memory ; 10 } 4.5.3 Blockdiagramme Blockdiagramme sind fast äquivalent zu ESDL. Allerdings stehen unter anderem verschiedene Operationen und Konstrukte, wie auch z.b. For-Schleifen, nicht zur Verfügung. Bei Blockdiagrammen handelt es sich um die meistgenutzte Beschreibungsform. Der Fokus liegt hierbei auf dem Datenfluss, wie von anderen graphischen Programmiersprachen gewohnt. Für ein Beispiel eines Blockdiagramms siehe Bild 5. 4.5.4 Zeitkontinuierliche Beschreibung Alle vorher geschilderten Beschreibungsmethoden gehen von diskreten Systemen aus. Allerdings handelt es sich bei physikalischen Prozessen nicht um diskrete, sondern um zeitkontinuierliche Systeme, die über Differentialgleichungen beschrieben werden müssen. Um innerhalb ASCET-MD diese zeitkontinuierlichen Systeme beschreiben zu können, werden sogenannte CT-Basisblöcke bereit gestellt, wobei CT für Continuous Time steht. Diese Basisblöcke werden mithilfe von nichtlinearen, gewöhnlichen Differentialgleichungen erster Ordnung und nichtlinearen Ausgabegleichungen beschrieben. Jeder Basisblock repräsentiert eine kleine, unabhängige physikalische Komponente. Mehrere Basisblöcke können wieder hierarchisch zu größeren CT-Blöcken zusammnegefasst werden. Die Blöcke werden per ESDL oder C konfiguriert, wobei ASCET gesonderte Methoden zur Beschreibung von Differentialgleichungen zur Verfügung stellt. ASCET bietet verschiedene, echtzeitfähige Integrationsalgorithmen, wie das Eulerverfahren. Während bei normalen Blockdiagrammen die Ausführungsreihenfolge und die
Methodennamen frei festlegbar sind, schränken CT-Blöcke dies auf vorgegebene Definitionen ein. Das Scheduling der Methoden ist ebenfalls vorgegeben. 4.6 Variablentypen Da ASCET-MD von der Hardware-Ebene abstrahiert, stehen die bekannten Datentypen wie int oder float nicht zur Verfügung. Stattdessen gibt es abstrakte Datentypen: Logical: Ein Logical repräsentiert einen boolschen Wert, er speichert also logische Informationen. Discrete: Discrete liegt sowohl als Signed als auch als Unsigned vor. Der Discrete-Typ kann zur Modellierung von natürlichen Zahlen genutzt werden. Continuous: Dieser Typ kann zur Darstellung von stetigen, physikalischen Werten genutzt werden. Hierbei ist zu Beachten, dass der abstrakte Typ nicht zwingend auf den tatsächlichen Variablentyp schließen lässt. So kann eine Variable des Types Continuous über eine Intervallfestlegung und eine Quantisierung auf einen diskreten Variablentyp wie int übertragen werden. Bekannte Konstrukte wie Arrays und Matrizen stehen ebenfalls zur Verfügung, wobei jeder Array oder jede Matrix wieder aus Variablen des oben genannten Types besteht. Zur Modellierung nichtlinearer Zusammenhänge, die entweder nicht genau bekannt sind oder zu aufwendig zu berechnen währen, werden außerdem Kennlinien bzw -felder zur bereit gestellt. Sie bestehen aus einer Menge von Zweiertupeln, die Abtastpunkte darstellen. Zwischen diesen Abtastpunkten kann linear interpoliert werden, bei Zugriff auf Werte außerhalb des Punkteintervalls kann außerdem extrapoliert werden. 4.7 Implementationscasts Bei einme Implementationscast handelt es sich um eine Spezifikation des Wertebereichs, der zur Compile- Zeit genutzt werden kann um den Speicherbedarf zu optimieren. Ist z.b. bei der Addition von zwei 16 Bit Variablen bekannt, dass der addierte Wert nie 16 Bit überschreiten wird, so kann dies in einem Implementationscast spezifiziert werden und dementsprechend wird zur Repräsentation des Ergebnisses nur eine 16 Bit Variable genutzt. Durch Implementationscasts kann also Wissen aus dem zu modellierenden, physikalischen System für eine effizienter Implementierung genutzt werden. Für ein Beispiel, siehe Abbildung 3. Abbildung 3: Implementationscasts einer Multiplikation, Quelle: [2] 4.8 Sequenzaufrufe In klassischen graphischen Modellierungstools wie SimuLink oder Labview folgt die Ausführungsreihenfolge dem Datenfluss. Dies muss in ASCET-MD nicht immer zwingend so sein.
Stattdessen ist es möglich, in Blockdiagramme die Ausführungsreihenfolge über sogenannte Sequenzaufrufe festzulegen. Es ist deswegen notwendig, Sequenzaufrufe zu nutzen, da sonst mehrere Zuweisungen auf eine Variable zu nichtdeterministischen Verhalten führen würde. Durch einen Sequenzaufruf wird dann festgelegt, welche dieser Zuweisungen tatsächlich ausgeführt wird bzw. in welcher Reihenfolge. Dies kann entweder manuell oder automatisch geschehen. Abbildung 4: Blockschaltbild einer Verzweigung, Quelle: [1] Außerdem werden Verzweigungen über Sequenzaufrufe realisiert, wie in Abbildung 4 dargestellt. Ein Aufruf in ASCET-MD lässt sich wie folgend lesen: Beginnend mit dem Block, der mit dem Methodennamen assoziiert ist und die Sequenznummer 1 hat, wird die Anweisungen links von ihm samt sich selbst ausgewertet, von links nach rechts. Dabei ist zu beachten, dass die Ausführung an den Ausgängen der genutzten Variablen beginnt. Nach Beendigung dieser Ausführung fahre genauso fort mit Sequenznummer 2 usw. der Methode. Für eine Veranschaulichung des oben geschilderten Sachverhalts, siehe Bild 5. Abbildung 5: Blockschaltbild eines Integrators, Quelle: [2] /Nummer/Name entspricht dem Aufruf der Funktion Name, wobei Nummer die Ausführungsreihenfolge angibt. Wird reset aufgerufen, wird der Wert von initvalue in memory eingelesen. Wird out aufgerufen, wird der Wert von memory ausgegeben, aber nicht der Wert von reset eingelesen, was im ersten Moment dem Datenfluss zu widersprechen scheint. Der Aufruf von compute führt die Multiplikation von in, dt, und K durch, addiert das Ergebnis mit memory und schreibt das Endergebnis in memory. Es sind auch komplexere Sequenzaufrufe möglich, wie in Bild 6 dargestellt.
Abbildung 6: [1], Mehrfache Ausführung in unterschiedlichen Prozessen Hier wird die Addition der zwei Variablen a und b dreimal durchgeführt, dabei zweimal im Prozess M10ms. Zuerst wird in diesem Prozess c zugewiesen, danach d. Das Bild 7 demonstriert ein weiteres Beispiel für die Ausführungsreihenfolge, die durch den Sequenzaufruf festgelegt ist. Dabei wird, sofern i kleiner 1 ist, zuerst die Multiplikation von c mit b und danach die Zuweisung zu c durchgeführt, danach erst die Inkrementierung von i. Abbildung 7: While-Schleife mit sequentieller Ausführung zweier Zuweisungen, Quelle: [1] 5 Zusammenfassung Für die heutige Entwicklung von Software im Automobilbereich sind Produkte wie ASCET und im speziellen ASCET-MD mittlerweile nahezu unverzichtbar geworden. Durch die zur Verfügung gestellten Mittel ist eine deutlich effizientere und sicherere Softwareentwicklung möglich. Die modellgetriebene Softwareentwicklung hilft den explodierenden Softwareaufwand durch ihre starke Abstraktion zu beherrschen und stellt deswegen die bisher wahrscheinlich beste Lösung für die behandelten Probleme dar. Literatur [1] ETAS, ASCET V5.2 Referenz. [2] ETAS, ASCET V5.2 Handbuch. [3] ETAS, ASCET V5.2 Schnelleinstieg. [4] Schäuffele, Zurawka. Automotive Software Engineering, 5. Auflage. Wiesbaden: Springer Vieweg [5] http://www.etas.com/en/products/ascet software products.php, Zugriff am 28.06.14 um 15:26.