Zustandsautomaten-Origami

Zustandsmaschinen können genutzt werden, um das Verhalten von Komponenten grafisch zu beschreiben und effizienten Code in C oder C++ zu generieren. Die Interaktion von Statecharts mit ihrer Umgebung wird mithilfe von Konzepten wie Ereignissen und formalen Interfaces beschrieben.

Erstmals auf Deutsch erschienen auf embedded software engineering am 09. August 2017 | Autor / Redaktion: Dr. Klaus Birken und Axel Terfloth / Christine Kremser

Franca ermöglicht die Modellierung solcher Interfaces, insbesondere ihrer Semantik, d.h. erlaubter Ereignissequenzen. In den meisten Projekten wird diese Information nur informell dokumentiert – mit Franca sind die erlaubten Abläufe maschinenlesbar und können daher automatisch geprüft werden. Werkzeuge zur Erstellung von Zustandsmaschinen können diese semantischen Informationen nutzen und den Entwickler interaktiv unterstützen, z.B. durch Hinweise auf erwartete oder zu sendende Ereignisse sowie unerreichbare Zustände. Damit wird die Einhaltung aller Interface-Verträge sichergestellt und letztlich die Qualität des Codes verbessert.

Interfaces und ihre Dynamik mit Franca beschreiben

In der Embedded-Entwicklung sollten Interfaces zwischen Komponenten oder Subsystemen nicht direkt als C-Header-Dateien, sondern auf einer höheren Abstraktionsebene, unabhängig von der Programmiersprache, entworfen und dargestellt werden. Dies wird durch eine Beschreibungssprache für Interfaces ermöglicht, kurz IDL (Interface Definition Language) [1]. Die Syntax wird dabei auf genau das Vokabular reduziert, das für die Definition von Interfaces benötigt wird. Die Abbildung auf eine Programmiersprache erfolgt typischerweise durch Codegenerierung.

Eine IDL ermöglicht die formale Beschreibung von Interfaces unabhängig von der Zielplattform und -sprache. Dadurch können dieselben Interfaces für die Integration über Subsysteme, Programmiersprachen, Controller und ECUs hinweg genutzt werden. Interfaces werden so zu einem umfassenden Werkzeug für Architekten und Entwickler.

Franca [2] bietet eine solche IDL sowie verschiedene Werkzeuge zur Erstellung, Bearbeitung und Codegenerierung aus Interfaces. Franca wurde zunächst im Rahmen des GENIVI-Konsortiums [3] entwickelt und ist auf dem Weg, ein offizielles Projekt unter dem Dach der Eclipse Foundation zu werden. Die verschiedenen Aspekte von Franca wurden auf vergangenen ESE-Konferenzen vorgestellt, z.B. [1][4][6].

Das typische Sprachspektrum einer IDL umfasst die statischen Teile von Interfaces, d.h. Datentypen, Attribute und Funktionsaufrufe. Dies ist zunächst ausreichend für die Dokumentation der Interfaces und auch für die Codegenerierung, da in Programmiersprachen nur statische Teile von Interfaces beschrieben werden (C-Header oder C++-Klassen enthalten keine Definitionen von z.B. Aufrufsequenzen).

Heute werden die dynamischen Teile von Interfaces üblicherweise erst während der Implementierung berücksichtigt. Dazu gehören erlaubte Aufrufsequenzen und ihre Parameterwerte. Nichtfunktionale Eigenschaften, wie Zeiteinschränkungen, zählen ebenfalls zu den dynamischen Teilen.

Gerade für komplexere Systeme ist es sinnvoll, die dynamischen Komponenten als Teil der Interface-Definition festzulegen, da der Interface-Designer die genauste Vorstellung davon hat, wie sein Interface zu verwenden ist [4]. Durch die formale Definition der Dynamik kann der Interface-Designer dies den nachfolgenden Implementierern mitteilen. Das steigert die Qualität des entstehenden Softwaresystems.

Franca unterstützt genau diese Beschreibung des dynamischen Verhaltens von Interfaces. Dazu bietet das Franca-IDL die Möglichkeit, Verträge von Interfaces in Form von Protocol State Machines zu spezifizieren. Das sind Zustandsmaschinen, die an der Verbindung zwischen den zwei kommunizierenden Softwareteilen, z.B. Komponenten, sitzen und auf Kommunikationsereignisse in beide Richtungen reagieren.

Zum Beispiel findet ein Zustandsübergang statt, wenn die Client-Seite eine Remote-Methode aufruft. Ein weiterer Zustandsübergang wird ausgelöst, wenn die Server-Seite die Antwortnachricht auf diese Methode sendet. In jedem Zustand der Protokollmaschine sind nur die Ereignisse erlaubt, die durch ausgehende Transitionen beschrieben werden. Alle anderen Ereignisse wären Protokollfehler und damit Verstöße gegen den Vertrag.

Mit Franca werden die Zustandsmaschinen textuell als Teil des IDL modelliert. In einem früheren Artikel wurde im Detail gezeigt, wie solche Verhaltensdefinitionen genutzt werden können, um Trace-Daten eines realen Embedded Systems im Betrieb zu validieren [4]. Dieser Artikel beschreibt nun, wie solche dynamischen Definitionen bereits während der Implementierung eines Embedded Systems an der Schnittstelle genutzt werden können, wenn diese Implementierung mit einem Statechart-Modellierungswerkzeug erfolgt.

Embedded-Software mit Statecharts erstellen

Zustandsmaschinen sind ein verständlicher Formalismus, der sich ideal für die Spezifikation und Implementierung des reaktiven Verhaltens von Systemen bewährt hat. Es gibt verschiedene Ansätze, Zustandsmaschinen effizient in Programmiersprachen wie C und C++ zu implementieren.

itemis CREATE [5] bietet eine Werkzeugumgebung für die Modellierung, Simulation und Codegenerierung von Statecharts.

Statecharts mit Franca-Interfaces – Integration von Werkzeugen und Modellen

Softwarekomponenten, die mit Statecharts implementiert werden, interagieren üblicherweise mit anderen Softwarekomponenten. Dies erfordert wohldefinierte Interfaces, was nahelegt, die Interfaces der Softwarekomponenten mit einer IDL zu beschreiben.

Eine solche Integration besteht zwischen Franca und itemis CREATE. Die Statecharts bieten die Möglichkeit, Ports für die Verbindung passender Softwarekomponenten zu definieren. Für jeden Port kann angegeben werden, ob ein in Franca definiertes Interface bereitgestellt oder verwendet werden soll.

Die im Interface definierten Ereignisse, Methoden und Datenelemente können dann direkt im Statechart genutzt werden. Je nachdem, ob das Statechart als Nutzer oder als Anbieter eines Interfaces agiert, stehen entsprechende Elemente zur Verfügung.

Softwarekomponenten haben oft mehr als ein Interface und müssen auch bezüglich ihres dynamischen Verhaltens interface-konform sein. Ohne weitere Hilfsmittel kann sich die Komplexität der Interfaces in der Implementierung der Komponenten jedoch potentiell multiplizieren, sodass der Validierungs- und Testaufwand sehr groß werden kann.

Das folgende Beispiel zeigt, wie die Implementierungs-Zustandsmaschinen mithilfe von Protocol State Machines für die Interfaces automatisch validiert werden können.

Beispielprojekt: Roboterarm-Steuerung

Als Beispiel für die beschriebene Integration der Open-Source-Werkzeuge itemis CREATE und Franca dient eine Steuerungssoftware für einen Roboterarm. Die Roboterhardware ist ein Lynxmotion AL5D Kit mit einem SSC32-Steuerungsboard. Das Titelbild dieses Artikels zeigt den Roboterarm, der aus fünf Achsen und einer Greifereinheit besteht.

Für unser Beispiel modellieren wir das Verhalten am Anwendungs-Interface des Roboter-Controllers; damit lassen sich folgende Funktionen steuern:

• Der Greifer kann Objekte halten und loslassen (Operationen grab und release).
• Der Arm kann den Greifer zu einer bestimmten kartesischen Position bewegen (Operation move).

Dementsprechend sind die statischen Elemente des Interfaces die Methoden move, grab und release. Jede Ausführung einer dieser Methoden besteht aus zwei Ereignissen: Zunächst ruft die Client-Seite des Interfaces die Methode auf; dann sendet die Server-Seite eine positive oder negative Antwort. Neben diesen elementaren Protokolldefinitionen gibt es technische Einschränkungen der erlaubten Abläufe.

Eine release-Operation ohne vorherige grab-Operation ergibt beispielsweise keinen Sinn. Insgesamt lassen sich alle erlaubten Sequenzen durch die Protocol State Machine aus Abbildung 1 definieren.

Abbildung 1: Die Protocol State Machine wird als Teil der Interface-Definition formuliert.

Eine Protocol State Machine wie in Abbildung 1 wird als Teil der Interface-Definition unter Verwendung von Franca-IDL formuliert. Wichtig ist, dass dies nur die Semantik des Interfaces beschreibt und nicht die eigentliche Implementierung der Steuerungskomponente. Letztere wird durch eine andere, viel detailliertere Zustandsmaschine mit itemis CREATE erstellt.

Interaktives Feedback bei der Statechart-Modellierung

Ein früherer ESE-Beitrag zeigte, wie aufgezeichnete Trace-Daten automatisch gegen eine oder mehrere Protocol State Machines validiert werden können [4]. Dies steigert die Qualität des entstehenden Produkts, indem Fehler in der Implementierung beim Testen erkannt und korrigiert werden.

Es ist jedoch besser, Fehler bereits während der Implementierung zu vermeiden. Dies wird durch die Integration von itemis CREATE und Franca ermöglicht: Während der Entwicklung werden die Implementierungs-Statecharts ständig gegen die Protocol State Machines der beteiligten Franca-Interfaces geprüft. Der Entwickler wird durch interaktives Feedback geleitet.

Abbildung 2 des RobotArm-Beispiels zeigt, welche Informationen aus den Interface-Definitionen abgeleitet werden und wie sie dem Nutzer präsentiert werden. Der Entwickler hat gerade begonnen, die Zustandsmaschine für die RobotArm-Steuerungskomponente zu erstellen. Diese Komponente implementiert das RobotArm-Interface mit dem in Abbildung 1 dargestellten Verhalten.

Abbildung 2: Interaktives Feedback im Statechart-Editor.

Die folgenden Informationen werden aus der Interface-Definition abgeleitet:

• Im Zustand idle wird der Aufruf der move-Operation behandelt (siehe Transition IdleMoving), aber die Behandlung der grab-Operation fehlt. Dies wird durch eine Warnung angezeigt. Der Entwickler wird angewiesen, eine weitere Transition (und einen weiteren Zustand) hinzuzufügen, um den grab-Aufruf zu behandeln.
• Der Zustand Moving wird durch einen move-Aufruf erreicht. Die Antwort auf die move-Operation steht jedoch noch aus, was durch eine Benachrichtigung (“Proposed send…”) dargestellt wird. Dies weist den Entwickler an, die move-Antwort zu implementieren.

Die weitere Arbeit an der Zustandsmaschine wird interaktiv weitere Warnungen und Informationen erzeugen, die dann durch weitere Entwickleraktionen verarbeitet werden. Am Ende entsteht eine Zustandsmaschine, die keine Warnungen mehr verursacht.

Dies zeigt, dass die Spezifikationen der Protocol State Machine berücksichtigt werden. Bei komplexen Komponenten mit mehr als einem Interface verstärkt sich der positive Effekt, da der Entwickler durch mehr Informationen noch besser geführt werden kann.

Im nächsten Schritt werden für jede der Warnungen oder Informationen des Werkzeugs zusätzliche Vorschläge angeboten, sodass der Entwickler das Problem direkt per Mausklick beheben oder implementieren kann (sogenannte Quick Fixes). Auf diese Weise kann der Entwickler vollständige Teile der Zustandsmaschine automatisch generieren lassen und gleichzeitig bestehende Warnungen beheben.

Vorteile für die Embedded-Praxis

Werkzeuge zur Modellierung von Zustandsmaschinen und zur Codegenerierung werden überall in Embedded-Projekten eingesetzt. In diesem Artikel wurde gezeigt, wie die innovative Berücksichtigung von Interface-Semantik Entwickler anleiten kann, um sicherzustellen, dass das Verhalten der erstellten Softwarekomponenten den vorgegebenen Interfaces entspricht.

Der Entwickler wird automatisch so früh wie möglich auf potenzielle Fehler hingewiesen und damit entlastet. Implementierungsfehler werden frühzeitig erkannt und behoben, was die Qualität der Software steigert und den Entwicklungsprozess beschleunigt. Die aufwändige Beseitigung von Integrationsfehlern und Fehlern im Allgemeinen entfällt.

Die modellbasierte Definition von Interfaces ist notwendig und nützlich, insbesondere für verteilte Anwendungen. Mit Franca-IDL können Interfaces formal definiert werden und als maschinenlesbarer „Vertrag" für die beteiligten Parteien und Systeme dienen.

Die Integration des Franca-IDL und itemis CREATE bringt für Entwickler und Architekten zusätzlichen Nutzen.

Literatur

[1] K. Birken: Interfaces vollständig im Griff – modellbasierte Ansätze mit dem Open-Source-Werkzeug Franca. In: Tagungsband – Embedded Software Engineering Kongress 2012, Sindelfingen, 2012.

[2] http://code.google.com/a/eclipselabs.org/p/franca/

[3] http://www.genivi.org

[4] K. Birken: Interfaces dynamisch beschreiben mit Franca. In: Tagungsband – Embedded Software Engineering Kongress 2013, Sindelfingen, 2013.

[5] itemis CREATE

[6] T. Szabo, K. Birken: Modellbasiert im Internet of Things. In: Tagungsband – Embedded Software Engineering Kongress 2014, Sindelfingen, 2014.

Custom Tool Development bei itemis — Domänenspezifische Werkzeuge und Sprachworkbenches für die Embedded- und Automotive-Entwicklung: Custom Tool Development →