Modellgetriebene Entwicklung verteilter embedded Systeme

Transkript

1 Modellgetriebene Entwicklung verteilter embedded Systeme oder Warum eigentlich noch programmieren? Embedded Systems ESE-Kongress Das Problem: Embedded Systeme werden noch überwiegend manuell codiert, teilweise sogar in Assembler. Auch wenn der Einsatz von C++ oder sogar Java für embedded Systeme diskutiert wird, bleibt es manuell! Kommerzielle Tools, die aus Modellen Code generieren, sind schwer an die eigenen Bedürfnisse anpassbar und erzeugen oft unverständlichen Code. Und wie beeinflusst das Betriebssystem das Verhalten? Und wenn Modelle ohnehin nichts zum Produkt beitragen warum soll man dann Mühe investieren? joerg.robra@t-online.de Embedded Systems ESE-Kongress

2 stm Tuere1 Geschlossen ist_zu Schliessen entry / Motor.rueck exit / Mo tor.stopp auf zu auf zu Oeffnen entry / Motor.vor exit / Motor.stopp Offen ist_auf Das Ziel: Embedded Systeme sollen überwiegend automatisch codiert werden. Dabei sollen innerbetriebliche Richtlinien, projektspezifische Sonderanforderungen sowie Wünsche an die Zielsprache berücksichtigt werden können. Das Betriebssystem darf das dynamische Verhalten nicht beeinflussen. Damit verlagert sich die Entwicklerarbeit in die sorgfältige Erstellung der notwendigen UML-Modelle. joerg.robra@t-online.de Embedded Systems ESE-Kongress Dafür gibt es doch die MDA! MDA (Model Driven Architecture) ist der Standard der OMG für Codegenerierung aus UML-Modellen in zwei Schritten: Aus einem plattformunabhängigen Modell (PIM) wird durch Transformation ein plattformspezifisches Modell (PSM) erzeugt und aus diesem durch weitere Transformation Code. joerg.robra@t-online.de Embedded Systems ESE-Kongress

3 Allerdings kann schon der erste Schritt schwierig werden: Embedded Systems ESE-Kongress Zum Glück gibt es eine Alternative: Kapitel "Automatic Transformation": Es kann sein, dass in besonderen Fällen überhaupt kein PSM, sondern aus dem PIM direkt Code generiert wird. Diese besonderen Fälle sind solche, in denen eine ausgereifte Plattform alle erforderlichen Dienste zur Verfügung stellt, und in denen die notwendigen Architekturentscheidungen einmal für eine größere Anzahl von Projekten getroffen wurden, die alle ähnliche Systeme betreffen, so dass diese Entscheidungen direkt in Tools, Templates, Entwicklungsrichtlinien und Codegeneratoren eingearbeitet werden konnten. In diese Kategorie gehören embedded Systeme, wenn man es richtig macht! joerg.robra@t-online.de Embedded Systems ESE-Kongress

4 Die Idee: Nur aus Zustandsautomaten kann man ablauffähigen Code generieren. Also bauen wir doch unser ganzes System nur aus kommunizierenden Zustandsautomaten auf! Zustandsautomaten der UML2 haben eine Semantik, die nur eine einfache Laufzeitumgebung benötigt. Also schreiben wir selber eine Plattform mit Laufzeitumgebung, die zu unseren Systemen passt! Jetzt brauchen wir nur noch den passenden Codegenerator. Also schreiben wir einen, der den richtigen Code erzeugt! Embedded Systems ESE-Kongress Schreiben, schreiben Wo bleibt der Vorteil? Plattform und Codegenerator werden für alle oder zumindest für eine große Zahl ähnlicher Systeme nur einmal benötigt. Wahrscheinlich sind nur für einen anderen Prozessortyp oder für besondere Sicherheitsanforderungen Anpassungen erforderlich. Dafür sind neue Systeme schnell graphisch erstellt, Tests besonders einfach, Änderungen leicht realisiert. Und das Beste: Alles lässt sich perfekt an innerbetriebliche Standards anpassen anstatt umgekehrt! joerg.robra@t-online.de Embedded Systems ESE-Kongress

5 Was muss die ausgereifte Plattform bieten? Kommunikation zwischen den Zustandsautomaten durch "Message Passing" Automat_a Scheduler... Automat_y Automat_z Message handler Embedded Systems ESE-Kongress Was muss die ausgereifte Plattform bieten? einen Timer zur Realisierung von TimeEvents Taktgeber Automat_a Scheduler... Automat_y Automat_z Timer Message handler joerg.robra@t-online.de Embedded Systems ESE-Kongress

6 Was muss die ausgereifte Plattform bieten? e Ein- und Ausgangsschnittstellen zur Hardware Taktgeber Scheduler Automat_a... Automat_y Automat_z Input- macht aus HW- Signalen Nachrichten Timer Message handler Output- joerg.robra@t-online.de Embedded Systems ESE-Kongress Was muss die ausgereifte Plattform bieten? eine Schnittstelle zur Kommunikation mit anderen Plattformen (verteilte Systeme!) Damit ist eine beliebige Systemverteilung möglich! Taktgeber Scheduler Automat_a... Automat_y Automat_z Input- Timer Message handler Output- Bus-Controler Registry Wo ist welches Objekt? joerg.robra@t-online.de Embedded Systems ESE-Kongress

7 Taktgeber Scheduler Taktgeber Scheduler Objekt_a... Objekt_e Objekt_f Objekt_v... Objekt_y Objekt_z an_g Timer Message handler Sensor- Überwachungen Aktor- Treiber Timer Message handler port_7 Sensor- Überwachungen Aktor- Treiber (CAN)- Controler Registry Wo ist welches Objekt? (CAN)- Controler Registry Wo ist welches Objekt? Taktgeber Scheduler Taktgeber Scheduler Objekt_g Timer an_u... Message handler Objekt_m Objekt_n Sensor- Überwachungen Aktor- Treiber Objekt_o Timer... Objekt_t Message handler Objekt_u out_7 Sensor- Überwachungen Aktor- Treiber (CAN)- Controler Registry Wo ist welches Objekt? (CAN)- Controler Registry Wo ist welches Objekt? Embedded Systems ESE-Kongress Gesamt-Komponentendiagramm der Plattform: Embedded Systems ESE-Kongress

8 Jetzt müssen die Entwickler nur noch lernen, in Zustandsautomaten zu denken! Es ist eigentlich gar nicht kompliziert: Ein in UML modelliertes System ist ereignisgesteuert. Zustandsautomaten sind ereignisgesteuert. Die wichtigste Umstellung ist also, kein System zu modellieren, das Daten verarbeitet, sondern eines, das Ereignisse verarbeitet. Der Rest ergibt sich fast von alleine. Embedded Systems ESE-Kongress Es ist eigentlich gar nicht kompliziert: Am Anfang steht ein ganz normales Klassendiagramm (PIM). Einzige Besonderheiten: Sensoren senden von sich aus Änderungsevents, und es gibt keine Funktionsergebnisse: class Wagen Wagen + geschlosse n() : void + hindernis() : void + Wagen(tuere_1, tuere_2) 2 - versuche Tuere + auf() : void + zu() : void + ist_auf() : void + ist_zu() : void + hindernis() : void + Tuere(wagen, motor) 3 Sensor Motor + vor() : void + rueck() : void + stopp() : void joerg.robra@t-online.de Embedded Systems ESE-Kongress

9 Es ist eigentlich gar nicht kompliziert: Dann erinnern wir uns daran, dass Sensor- und Motorschnittstellen von der Plattform angeboten werden: class Wagen Tuere «platform» Sensor Wagen - versuche 3 + geschlossen() : voidd + hindernis() Wagen(tuere_1, : voidtuere_2) + Wagen(tuere_1, tuere_2) 2 + auf() : void + zu() : void + ist_auf() : void + ist_zu() : void + hindernis() : void + Tuere(wagen, motor) «platform» Motor + vor() : void + rueck() : void + stopp() : void joerg.robra@t-online.de Embedded Systems ESE-Kongress Es ist eigentlich gar nicht kompliziert: Dann wird das Verhalten jedes Objekts als Zustandsautomat spezifiziert; dabei sind das, was vorher die Methoden waren, die Signal Events des Automaten. Beispiel Türe: stm Tuere Initial Geschlossen entry / Wagen.geschlossen Schliessen entry / Motor.rueck exit / Motor.stopp hindernis [versuche!= 0] ist_zu Stoe rung entry / Motor.vor exit / Motor.stopp exit / versuche-- ist_auf auf hindernis [versuche == 0] /Wagen.hindernis zu Oeffnen entry / Motor.vor exit / Mo tor.stopp Offen ist_auf entry / versuche = 3 joerg.robra@t-online.de Embedded Systems ESE-Kongress

10 Es ist eigentlich gar nicht kompliziert: Auf Wunsch kann mit Hilfe der State-Event-Matrix die Vollständigkeit überprüft stm Tuere Event auf ist_auf zu ist_zu hindernis hindernis <None> State Geschlossen Oeffnen Oeffnen Offen Offen Schliessen Schliessen Geschlossen [versuche == 0] Oeffnen [versuche!= 0] Stoerung Initial Geschlossen Stoerung Schliessen Embedded Systems ESE-Kongress Es ist eigentlich gar nicht kompliziert: und gegebenenfalls ergänzt werden. Was danach noch leer bleibt sind Fehlerfälle: stm Tuere Event auf ist_auf zu ist_zu hindernis hindernis <None> State Geschl ossen Oeffnen Geschlossen Oeffnen Offen Offen Schliessen Schliessen Oeffnen Geschl ossen [versuche == 0] Oeffnen [versuche!= 0] Stoerung Initial Geschl ossen Stoerung Schliessen Embedded Systems ESE-Kongress

11 Es ist eigentlich gar nicht kompliziert: Den Rest erledigen Tools, Plattform und Richtlinien. Dass es hinterher gar keine Methoden und keine Methodenaufrufe mehr gibt, sondern Nachrichten, die von Message und Scheduler des Systems übermittelt werden, braucht niemand zu wissen. Wen interessiert schon dieses PSM?? class Wagen_PSM Wagen + start() : void + Wagen(tuere_1, tuere_2) System + send(message) : void - versuche Tuere + start() : void + Tuere(wagen, motor) AbstractObject # state + start() : void joerg.robra@t-online.de Embedded Systems ESE-Kongress Wie kommt man vom UML-Diagramm zum Code? Die OMG hat eine Sprache auf XML-Basis zum Austausch von UML-Diagrammen spezifiziert: Die XMI "Anständige" UML-Tools können ihre Diagramme in XMI exportieren joerg.robra@t-online.de Embedded Systems ESE-Kongress

12 Wie kommt man vom UML-Diagramm zum Code? Das Ergebnis sieht dann so aus (Seite 1 von 27): joerg.robra@t-online.de Embedded Systems ESE-Kongress Wie kommt man vom UML-Diagramm zum Code? Daraus werden die coderelevanten Informationen extrahiert: State Geschlossen entry transition Wagen.geschlossen trigger joerg.robra@t-online.de Embedded Systems ESE-Kongress

13 In welcher Sprache soll der Code erzeugt werden? Objektorientierte Programmiersprachen wie C++ oder Java machen es dem Programmierer leichter, ein objektorientiertes Modell zu implementieren. Wenn der Code aber automatisch generiert wird, spielt das keine Rolle. Also nehmen wir eine Sprache, die auch der kleinste Microcontroller versteht, ohne dass die Effizienz leidet: ANSI-C oder eine domänenspezifische wie ST oder eine Interpretersprache (hat Vorteile!) Embedded Systems ESE-Kongress Wie werden Objekte und Nachrichten identifiziert? Die Verwendung eines Message bietet viele Vorteile: Alle Objekte kennen sich gegenseitig nur über symbolische Namen; nur der Scheduler benötigt ihre Speicherreferenzen. Also werden auch alle Assoziationen durch Zahlen repräsentiert. Dies erleichtert die Systemgenerierung erheblich (z.b. bei bidirektionalen Assoziationen). Auch alle Nachrichtensignale sind als Zahlen codiert (enum). Daraus ergeben sich sehr kompakte Datenstrukturen. typedef struct Byte state; Word lnkwagen; Word lnkmotor; Byte versuche; } Tuere_Daten; typedef struct Word empfaenger, absender, signal; Byte priority, parindex; } Message; joerg.robra@t-online.de Embedded Systems ESE-Kongress

14 Wie findet eine Nachricht die richtige Transition? Es gibt mehrere Möglichkeiten, einen Zustandsautomaten zu implementieren: switch(state) "geradeaus": Implementierung der State-Event-Matrix: Vorteil: Die Leerfelder können mit einer automatischen Fehlerbehandlung vorbelegt werden! case Geschlossen: switch(event) case auf: static Pfunc trans [STATES][EVENTS] = tr0000, error, error, error, tr0004, error, error, tr0102, error, error, error, error, error, error, tr0204, tr0300, tr0301, error, tr0303, error, error, error, tr0402, error, error, }; joerg.robra@t-online.de Embedded Systems ESE-Kongress Generierter Code Diese Version ist besonders leicht lesbar und verständlich: static void Stoerung_entry(void) send(this->lnkmotor, vor, NULL); } static void Stoerung_exit(void) send(this->lnkmotor, stopp, NULL); this->versuche--; } keine Parameter static Word eventlist[] = auf, hindernis, ist_auf, ist_zu, zu}; static void tr0102(void) /* state = Oeffnen, event = ist_auf */ Oeffnen_exit(); Offen_entry(); this->state = Offen; } joerg.robra@t-online.de Embedded Systems ESE-Kongress

15 Wie realisiert man ein Time-Event (after )? stm Tuere zu Geschlossen Oeffnen entry / Wagen.geschlossen auf entry / Motor.vor exit / Mo tor.stopp Initial ist_zu Schliessen auf hindernis [versuche == 0] /Wagen.hindernis Offen ist_auf hindernis [versuch e!= 0] entry / Motor.rueck exit / Mo tor.stopp ist_auf Stoerung entry / Motor.vor exit / Motor.stopp exit / versuche-- zu after(5000) entry / versuche = 3 static void Schliessen_entry(void) send(this->lnkmotor, rueck, NULL); timestart(5000); } Timer der Plattform static void Schliessen_exit(void) send(this->lnkmotor, stopp, NULL); timestop(); } joerg.robra@t-online.de Embedded Systems ESE-Kongress Zugegeben: Einige Zeilen muss man noch selber schreiben: /* eventuelle Instanznamen definieren */ enum tuere_vorn = Tuere, tuere_hinten}; typedef struct Byte state; /* restliche Daten eintragen */ können auch auch aus aus dem Word lnkwagen; Klassendiagramm Word lnkmotor; Byte versuche; generiert werden } Tuere_Daten; /* Initialisierungsfunktion vervollstaendigen! */ /* Dabei Kommentarzeichen nicht entfernen! */ /* void Tuere_init(Word objekt, Word wagen, Word motor) this = &(daten[objekt & 0xff]); this->lnkwagen = wagen; this->lnkmotor = motor; trinit(objekt); } */ joerg.robra@t-online.de Embedded Systems ESE-Kongress

16 Der "Erbauer" arbeitet ein Konfigurationsskript ab Embedded Systems ESE-Kongress oder wird danach automatisch oder manuell erstellt: prepare_classes(2); install_class(wagen_start); install_class(tuere_start); Tuere_init(tuere_vorn, Wagen, motor_0); Tuere_init(tuere_hinten, Wagen, motor_1); Wagen_init(Wagen, tuere_vorn, tuere_hinten); /* Tastatur anstatt Inports */ install_bport(nil, 'g', 0, tuere_vorn, 1, ist_zu); install_bport(nil, 'o', 0, tuere_vorn, 1, ist_auf); install_bport(nil, 'G', 0, tuere_hinten, 1, ist_zu); install_bport(nil, 'O', 0, tuere_hinten, 1, ist_auf); Embedded Systems ESE-Kongress

17 Wie funktioniert das Multitasking? Für Zustandsautomaten der UML gilt das RTC-Prinzip (Run To Completion): Eine laufende Transition kann nicht durch eine neue Anforderung an dasselbe Objekt unterbrochen werden, sondern nur durch eine höher priore Nachricht an ein anderes Objekt. Außerdem hat es sich für Echtzeitsysteme bewährt, dass das Scheduling durch Nachrichtenprioritäten gesteuert wird, und dass interne Nachrichten (von Objekt an Objekt) eine höhere Priorität haben als Nachrichten aus der Peripherie; Beides garantiert unsere Plattform. Daraus ergibt sich, dass kein preemptives Scheduling erforderlich ist; die Laufzeitumgebung wird extrem einfach. Embedded Systems ESE-Kongress Kann man solche Systeme auch testen? Ja, sogar besonders leicht: Der Nachrichtenfluss kann leicht beobachtet werden. Testautomaten können intern oder extern eingesetzt werden. Fehlende Hardware kann simuliert Taktgeber Scheduler Testautomat werden. Input- MessageTracer Bus-Controler Automat_a Timer... HW-Simulator Automat_y Message handler Registry Testautomat Automat_z Output- Embedded Systems ESE-Kongress

18 Fazit: Verteilte embedded Systeme können aus UML-Modellen leicht automatisch generiert werden. Codegenerator und erforderliche Plattform können mit vertretbarem Aufwand selber erstellt werden. Sie sind in hohem Maße wiederverwendbar. Dafür entstehen wesentliche Vorteile: Unabhängigkeit von Toolherstellern Verständliche Ergebnisse Anpassung an interne Richtlinien und projektspezifische Anforderungen Also: Es lohnt sich! Embedded Systems ESE-Kongress Danke für f Ihre Aufmerksamkeit! joerg.robra@t-online.de Embedded Systems ESE-Kongress