Was, wenn Sie als Embedded-Entwickler und Systemarchitekt in einem Steuergeräteverbund schon genau erfahren könnten, wie lange die Software zur Ausführung brauchen wird?
Wobei die Software erst noch zu entwickeln ist, und auch die Hardwareplattorm sowie das Betriebssystem und die Middleware noch nicht existiert? Wie wäre es, eine Simulation zu haben, die mir genau sagt, ob das alles so funktioniert, wie ich mir das ausgedacht habe?
»Architektursimulation von verteilten Steuergerätesystemen ist eine Methode zur Simulation des Zusammenwirkens von Funktionen, die verschiedenen Ausführungseinheiten eines Steuergeräteverbundes zugewiesen sind. Die Architektursimulation berücksichtigt dabei die Einflüsse der zugrundeliegenden Hardware- und Systemplattform.
Mit Funktionen sind in diesem Zusammenhang Anwendungen wie beispielsweise die Grundbremsfunktion eines Bremssystems benannt, die durch die sogenannte Funktionsnetzarchitektur in verschiedene Komponenten zusammengefaßt werden. Die Funktionen liegen dabei entweder als textuelle Beschreibung oder als ausführbare Modelle vor.
Die Hardware- und Systemplattform, kurz Plattform, bezeichnet die Hardware bestehend aus Busleitungen, Prozessoren, Speichern, Sensoren und Aktoren, sowie systembezogene Elemente wie Busprotokolle, Betriebssysteme, und Middleware wie z.B. Netzmanagement.«
Ein Jahrzehnt
Dieser Abstract ist alt, zehn Jahre, um genau zu sein.
Es ist der Abstract meiner Dissertation. Warum lesen Sie das als Eröffnung eines Blogposts? Ist eine zehn Jahre alte Doktorarbeit nicht schrecklich veraltet, vor allem in der Informatik?
Das kommt auf das Thema an, und auf die Betrachtung. Die konkrete Umsetzung mag veraltet sein. Die Theorie altert nicht. Und vor allem nicht der Nachweis, warum etwas nicht funktionieren kann. Also nicht im Sinne »wir haben es nicht hingebracht« sondern im Sinne von »es ist nicht möglich«.
Die Frage und die Abstraktion entscheidet
In den vergangenen zehn Jahren bin ich im Rahmen meiner Arbeit immer wieder auf Ingenieure und Entwickler gestoßen, die eine Simulation aufbauen wollten, die den Prozessor mit simuliert und viele andere Teile der Steuergeräte-Hardware.
Nur wenige konnten mir sagen, was sie sich tatsächlich von der Simulation erhofften.
Eine Simulation kann aber nur höchstens so gut sein wie die Frage, die ich stelle, manchmal auch weniger.
Das hat nichts mit der Software zu tun, die ich für die Simulation einsetze. Es ist eine Frage der Abstraktion. Wähle ich die Abstraktion falsch, oder passen die Abstraktionsebenen verschiedener Modelle nicht zusammen, wird die Simulation keine verlässlichen Aussagen liefern.
Das ist keine Frage der Implementierung. Es geht einfach nicht, und das kann man sogar beweisen. Andererseits können Sie sich auch vorab Gedanken machen, welche Abstraktion Sie benötigen, oder andersherum, wieviel Details das Modell enthalten muss, um die Simulation zu einem Erfolg führen zu können.
Die Methode ist ebenfalls in der Dissertation enthalten.
Denn wir fanden schließlich heraus: Das, was wir versuchten, konnte nicht gehen.
Die Dissertation ist somit leider ein wenig depremierend, weil sie eben nachweist, warum ein bestimmter Ansatz nicht funktionierte.
Darum jetzt als Open Access
Anders, als ich es vor zehn Jahren vermutet hatte, ist das Bewusstsein um die vernünftige Wahl der Abstraktionsebene noch nicht allgemeiner Konsens.
Die Simulationstools – allen voran Simulink und Stateflow – leisten Großartiges, können dem Ingenieur jedoch nicht die wichtigste Designentscheidung abnehmen: Wie detailliert, wie abstrakt sollte das Modell sein? Welche Fragen wird die Simulation auf Basis der zur Verfügung stehenden Informationen beantworten können? Passt das zum Wunsch und Bedürfnis?
Ich hoffe inständig, dass Sie sich alle mindestens das dritte Kapitel der Dissertation zu Gemüte führen, und in Zukunft weniger Zeit mit vermeintlich detaillierten Modellen verbraten, die ihre Stärken mangels detaillierter Informationslage anderer Modelle gar nicht ausspielen können.
Wir brauchen Simulaton. Sie brauchen Simulation. Aber bitte Simulation intelligent gedacht und intelligent gemacht.
Das Buch zur Architektursimulation kostenlos herunterladen
Sie können die komplette Dissertation hier frei als PDF herunterladen. Alle 379 Seiten mit 1,5 MB. Weil ich mit Ihnen gerne über das Thema weiter diskutieren möchte, bitte ich Sie im Gegenzug um Ihre E-Mail-Adresse und Namen. Sollte das Buch auch als EPUB-Fassung für den Kindle etc. verfügbar werden, gebe ich Ihnen nochmal Bescheid.
Nachdem Sie Ihre Adresse angegeben haben, bekommen Sie zunächst eine Anfrage zur Bestätigung. Klicken Sie auf den Link in der E-Mail, mit der Sie auch automatisch mein E-Book über E-Mail-Effizienz erhalten.
Das Grundprinzip der passenden Abstraktionsebenen aus dem Buch können Sie in den Vortragsunterlagen meines Rigorosums ersehen:
Um die vollen Erklärungen zu bekommen, tragen Sie sich bitte ein kleines Stück weiter oben ein.
Architektursimulation und der Unterschied zur funktionalen Simulation
»Rein funktionale Simulation betrachtet das Verhalten von Funktionskomponenten unter Vernachlässigung von Laufzeiten und Verzögerungszeiten.
Die Dissertation klärt, unter welchen Umständen die Architektursimulation einen Zusatznutzen zu bekannten Evaluierungsmethoden wie rein funktionaler Simulation, Rapid Prototyping oder Hardware-in-the-Loop bieten kann.
Zusatznutzen könnte zum einen erbracht werden, indem Tests in der Architektursimulation früher im Entwicklungsprozeß durchgeführt werden können, und der zeitliche Aufwand für den Testaufbau geringer ist. Dies eröffnete sowohl die Möglichkeit kürzerer Iterationszyklen, als auch einer größeren Testabdeckung. Zum anderen ist Zusatznutzen darin zu erkennen, dass insgesamt eine größere Testtiefe erreicht wird, also durch Modellevaluierung andere Eigenschaften des Systems geprüft werden können als mit rein hardwarebasierten Methoden. Diese Eigenschaften können entweder in der Hardware nur schwer oder gar nicht prüfbar, oder deren Zustände nicht reproduzierbar sein.
Mit Hilfe von Architektursimulation könnten Plattformentscheidungen fundierter getroffen werden und Probleme, die bei der Integration von Plattformbausteinen und Funktionskomponenten auftreten, früher erkannt und behoben werden.
Die dabei untersuchten Modellarten umfassen Modelle von Funktionsstruktur, Funktionsverhalten, Hardware inklusive Bus und Busprotokoll, Plattform und Verteilung. Das Verteilungsmodell beinhaltet die Information, welche Funktionskomponente auf welche Plattformkomponente abgebildet wird. Darin eingeschlossen ist im Falle von Betriebssystemen die Konfiguration von Tasks und Prozessen, die entweder separat vorliegt oder aus detaillierten Funktionsverhaltensmodellen generiert wird.«
Die wichtigste Frage vor der Modellierung
Alle Vorteile von Simulation an sich bleiben bestehen. Ich bin ja deshalb schon so lange bei MathWorks, dem Hersteller von MATLAB & Simulink, weil Simulation die Entwicklung von Systemen besser macht. Nur in der Simulation kann ich Eigenschaften des Systems prüfen, die sich am realen Aufbau nicht oder nur sehr schwer beobachten lassen.
Aber versuchen Sie nicht, genaue Laufzeiten zu erhalten, die von Betriebsystemaufrufen und der genauen Implementierung der Software abhängen, wenn Sie beides zum Zeitpunkt der Simulation noch nicht einmal zur Hälfte haben. Die Voraussagekraft der Simulation wäre in diesem Falle nicht größer als das Bauchgefühl des erfahrenen Entwicklers.
Wenn Sie detaillierte Aussagen wollen, brauchen Sie detaillierte Modelle.
Haben Sie den Plan, eine Simulation aufzubauen, dann fragen Sie sich zuallererst: Welche Frage genau soll mir die Simulation beantworten können?
Gute Fragen stellen
Welche Frage versuchen Sie mit Ihrer Simulation zu beantworten? Und welche Gedanken haben Sie sich um Abstraktionsebenen gemacht?
Lassen Sie die anderen Leser ebenso wie mich bitte teilhaben an Ihren Gedanken und kommentieren Sie!
Photo: Dirk Vorderstraße on Flickr, License Creative Commons Attribution
Schreiben Sie einen Kommentar