ESE Fachwissen
Das Erwachen der Macht - Automatische Softwareverteilung
Autoren: Uwe Pohlmann, Jörg Holtmann und Matthias Meyer, Fraunhofer IEM
Beitrag - Embedded Software Engineering Kongress 2016
Für die Ausführung der Software müssen die Softwarekomponenten auf ECUs verteilt werden. Dabei unterliegt die Verteilung sicherheitskritischen Constraints. Das Suchen der optimalen und gültigen Verteilung ist sehr komplex. Die Lösung kann effizient durch Verfahren des Operations Research ermittelt werden. Jedoch ist die manuelle Kodierung sehr aufwändig.
Dieser Beitrag stellt eine modellgetriebene Methode und Werkzeugunterstützung vor, welche die Beschreibung von Constraints und Optimierungen vereinfacht sowie die formale Kodierung und Lösungssuche automatisiert. Dies erlaubt die effiziente Nutzung der Macht von formalen Modellen ohne Kenntnis der formalen mathematischen Verfahren. Die Vorteile der Methode werden anhand eines Beispiels aus der Automobilindustrie beschrieben.
Software übernimmt immer mehr Funktionen in technischen Systemen wie dem Auto, wodurch die Komplexität der Entwicklung steigt. Für die Ausführung der Software müssen die verschiedenen Softwarekomponenten auf die ECUs verteilt werden. Dabei unterliegt die Verteilung verschiedensten sicherheitskritischen Constraints. Es müssen komplexe Abhängigkeiten (Topologie, Komponenten) und Ressourcenconstraints (Speicher, Scheduling, Netzwerk) beachtet und Architekturoptimierungen (Latenzzeiten) durchgeführt werden. Das Suchen der optimalen Verteilung im Entwurfsraum, welche alle Constraints einhält, ist sehr komplex. Die Suche kann automatisiert werden, indem das Verteilungsproblem mathematisches Problem des Operations Research beschrieben wird. Diese können dann durch Verfahren, wie ‚Constraint-/Lineare-Programmierung‘ oder Meta-Heuristiken automatisch gelöst werden.
Jede mögliche Verteilung, Beschränkung und Optimierung muss als Variable und als Gleichung formalisiert werden. Um z.B. auszudrücken, dass jede Komponente genau auf eine ECU allokiert werden muss, führen wir die Variablen Xc,e für das kartesische Produkt der Menge C E COMPONENT und der Menge e E ECU sowie die Gleichung ∑eEEcu Xc,e = 1 ein. Für weitere Constraints müssen neue Variablen und Gleichungen eingeführt werden und mit bestehenden Variablen verbunden werden, wodurch die manuelle Kodierung sehr fehleranfällig wird.
Dieser auf der Veröffentlichung [1] basierende Beitrag stellt den in Abbildung 1 (siehe PDF) als Prozess dargestellten, modellgetriebenen Ansatz vor. Dieser ermöglicht die Beschreibung von Constraints und Optimierungen auf Basis von EMF-Modellen und OCL Constraints. Eine Demo ist online frei verfügbar [3]. Auf Basis der Modelle und Constraints wird das Verteilungsproblem automatisch als ganzzahliges lineares Programm kodiert, automatisch gelöst und in ein Verteilungsmodell überführt.
Durch den Einsatz von Modellen und Modelltransformationen wird die effiziente Nutzung der Macht von formalen Modellen ermöglicht. Dies erfordert vom Entwickler kein Wissen über die mathematische Kodierung, wodurch die Nutzung dieser Macht für Entwickler signifikant vereinfacht wird. Die automatische Berechnung der Softwareverteilung verbessert den Systementwurf. Hierdurch werden Unzulänglichkeiten und teure Anpassungen vermieden, was die Beschleunigung des Entwicklungsprozesses ohne qualitative Verluste ermöglicht. Insbesondere kann die Wechselwirkung zwischen Soft- und Hardwareentwurf frühzeitig betrachtet werden.
Beispiel - Brake-by-Wire System
Wir nutzen ein Brake-by-Wire-System als Beispiel. Zur Modellierung nutzen wir die Sprache MechatronicUML [2]. MechatronicUML ist eine modellgetriebene und komponentenbasierte Sprache für den Entwurf von vernetzten intelligenten, technischen Systemen. Es bietet eine modellgetriebene Prozessunterstützung von den Anforderungen über verschiedene Entwurfsschritte (inkl. deren Analyse) bis zur verteilt ausführbaren Software. MechatronicUML unterstützt neben der Beschreibung von Softwarearchitekturen auch die Beschreibung von Hardwareplattformen.
Abbildung 2 (siehe PDF) zeigt im linken Teil die Softwarearchitektur. Diese besteht aus den strukturierten Komponenten Calliper, BrakePedal, Wheel und den atomaren Komponenten sc1-sc13. Abbildung 2 zeigt im rechten Teil die Hardwareplattform. Sie besteht aus den drei Teilplattformen Assistance, Brake und Human Interface, den Netzwerkbussen bus1-bus4, den ECUs hw1-hw8, den Sensoren 1, 2, 7, 9, 11, 12 und den Aktoren 3, 5. 13. Die Nummer des Sensors und Aktors entspricht immer derselben Nummer wie die dazu passende Komponente.
Komponenten benötigen zur Ausführung immer eine ECU, welche Informationen an den passenden Sensor oder Aktor senden kann. Zum Beispiel muss die Komponente sc1 auf eine ECU aus der Menge hw4-hw7 allokiert werden, um den Sensorwert von dem Temperatursensor 1 zu lesen und zu verarbeiten. Weiterhin müssen die Komponenten sc11 und sc12 auf derselben ECU allokiert werden. Alle Komponenten verbrauchen Speicher. Es muss immer gewährleistet werden, dass der Speicherverbrauch kleiner als der zur Verfügung stehende Speicher ist. Die Verteilung soll dahingehend optimiert werden, dass die Kommunikationslatenz minimal wird.
Aktionsspezifikationssprache (Allocation Specification Language, ASL)
Der Entwickler muss die Constraints und Optimierungen basierend auf dem Systemmodell beschreiben. Hierzu haben wir die ASL entwickelt, welche die OCL für die Spezifikation von Modellabfragen einbettet. Die ASL unterscheidet zwischen vier Beschränkungsarten und einer Optimierungsart, welche im Folgenden demonstriert werden.
Abbildung 3 (siehe PDF) zeigt zunächst das Laden von vorgefertigten OCL-Operationen aus der OCLContext.ocl Bibliothek und danach eine Beschränkung vom Typ ‚collocation‘. Der Constraint erfordert, dass das der durch den OCL-Ausdruck zurückgegebene Tupel zwei Komponenten an die OCL-Variablen ‚first:ComponentInstance‘ und ‚second: ComponentInstance‘ bindet und erzwingt dadurch, dass diese Komponenten zusammen auf eine ECU allokiert werden. Das Constraint collocateSC11AndSC12 erzeugt das Tupel (first=sc11, second=sc12), indem die Namen als Strings in entsprechende Objekte aus dem Modell umgewandelt werden. Falls ein Entwickler den Typ des Constraints von ‚collocation‘ auf ‚separateLocation‘ wechselt, dann dürften die beiden Komponenten nicht auf dieselbe ECU allokiert werden. Die spezifizierten Constraints dienen als Eingabe für die automatische Kodierung des Allokationsproblems.
Abbildung 5 (siehe PDF) zeigt eine Beschränkung vom Typ ‚requiredLocation‘. Es erfordert, dass das durch den OCL-Ausdruck zurückgegebene Tupel eine Komponente und eine ECU an die OCL-Variablen ‚first:ComponentInstance‘ und ‚second:ECU‘ bindet, indem die Namen als Strings in entsprechende Objekte aus dem Modell umgewandelt werden. Die an die Variable ‚first‘ gebundenen Komponenten müssen auf eine der ECUs, die an die Variable ‚second‘ gebunden sind, allokiert werden.
Abbildung 6 (siehe PDF) zeigt eine Beschränkung vom Typ ‚requiredResource‘. Es erfordert, dass der OCL-Ausdruck einen Tupel von dem Typ zurückgibt, der in Abbildung 7 (siehe PDF) dargestellt und durch die Keywords ‚lhs‘, ‚rhs‘ und den ‚descriptor‘ festgelegt wird.
Der Constraint erzwingt, dass der gesamte Speicherbedarf der Komponenten nicht die obere Speichergrenze einer ECU überschreitet.
Abbildung 8 (siehe PDF) zeigt eine Servicebeschreibung mit dem Namen ‚communication‘ und die Definition einer ‚qos‘ (Quality-of-Service) Eigenschaft in Form einer Latenz. Diese soll minimiert werden. Die ‚qos‘ erfordert, dass ihr OCL-Ausdruck einen Tupel von dem Typ zurückgibt, der in Abbildung 9 (siehe PDF) dargestellt wird und durch das Keyword ‚value‘ und den ‚descriptor‘ festgelegt wird.
Die dargestellten Constraints und Optimierungen werden in nachfolgenden Schritten automatisch in mathematische Gleichungen überführt, gelöst und zurück in ein Allokationsmodell überführt. Die berechnete Verteilung ist in Abbildung 10 (siehe PDF) als Tabelle dargestellt. Wenn in einer Zelle eine 1 steht, bedeutet dass, das die entsprechende Komponente (Zeile) auf die entsprechende ECU (Spalte) allokiert wurde. Details zur automatischen Kodierung und Lösung der Allokationsconstraints sind im Beitrag [1] beschrieben.
Zusammenfassung
Für die Ausführung der Software müssen die verschiedenen Softwarekomponenten auf die Steuergeräte verteilt werden. Aufgrund der hohen Anzahl an Softwarekomponenten, ECUs, Constraints und Optimierungen ist dies sehr komplex. Dieser Beitrag stellt eine modellgetriebene Methode und Werkzeugunterstützung vor, welche die Beschreibung von Verteilungsconstraints und Optimierungszielen auf Basis von Entwurfsmodellen vereinfacht sowie die formale Kodierung und Lösung automatisiert. Dies erlaubt die effiziente Nutzung der Macht von formalen Modellen ohne das tiefgehende Wissen der mathematischen Mechanismen dahinter. In Zukunft wollen wir die vorgestellte Methode so erweitern, dass sie für beliebige Allokationsprobleme anwendbar wird. Diese Erweiterungen ermöglichen ebenso die Beschreibung und Lösung anderer Allokationsprobleme mittels der ASL, wie z.B. die Zuweisung von Aufgaben an Personen.
Literaturverzeichnis
[1] U. Pohlmann and M. Hüwe, "Model-Driven Allocation Engineering", In Proceedings of the 30th IEEE/ACM International Conference on Automated Software Engineering, 2015, Lincoln, NE, USA, 2015, pp. 374-384.
[2] Steffen Becker, Stefan Dziwok, Christopher Gerking, Christian Heinzemann, Wilhelm Schäfer, Matthias Meyer, and Uwe Pohlmann. “The MechatronicUML method: model-driven software engineering of self-adaptive mechatronic systems”, In Companion Proceedings of the 36th International Conference on Software Engineering, 2014, ACM, New York, NY, USA, pp. 614-615.
[3] https://trac.cs.upb.de/mechatronicuml/wiki/PaperASE2015
https://www.mechatronicuml.de
Software Engineering Management - unsere Trainings & Coachings
Wollen Sie sich auf den aktuellen Stand der Technik bringen?
Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Software Engineering Management /Prozess-, Projekt- und Produktmanagement.
Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.
Software Engineering Management - Fachwissen
Wertvolles Fachwissen zum Thema Software Engineering Management /Prozess-, Projekt- und Produktmanagement steht hier für Sie zum kostenfreien Download bereit.
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.