Grafisches Systemdesign Entwicklungszeiten von Echtzeit- und Embedded-Systemen verkürzen

Die Programmcode-Zeilen steigen mit zunehmender Komplexität und somit Entwicklungsaufwand und -kosten. Eine praktikable Lösung bieten grafische Entwicklungswerkzeuge. Dieser Artikel behandelt gängige fachspezifische Entwicklungsmethoden und Möglichkeiten, die Implementierung von Embedded-Systemen zu vereinfachen.

Anbieter zum Thema

MicroConsult Academy GmbH

Syslogic GmbH

Keysight Technologies Deutschland GmbH

National Instruments Germany GmbH

C ist zwar nach wie vor die meistgewählte Programmiersprache für Embedded-Systeme. Seit ihrer Einführung ist die Komplexität von Embedded-Systemen jedoch kontinuierlich angestiegen. Mit steigender Komplexität von Systemen werden daher Plattformen für das Design auf Systemebene immer wichtiger (Bild 1). Nur damit lassen sich in der Zukunft umfangreiche Anwendungen in einem realistischen Zeitrahmen bewältigen. Im Folgenden werden mehrere Methoden des Systemdesigns mit verschiedenen Arten der grafischen Programmierung und ihren jeweiligen Stärken und Schwächen erläutert.

Den Datenfluss grafisch programmieren

Das Datenflussprinzip ist eine Softwarearchitektur, die auf dem Konzept basiert, dass die Änderung eines Variablenwerts auch zu Abweichungen bei anderen, davon abhängigen Variablen führen sollte. Das bekannteste Beispiel dafür sind etwa abellenkalkulationsprogramme, in denen die Änderung eines Wertes in einer einzigen Zelle den Wert in einer anderen, damit zusammenhängenden Zelle beeinflussen kann, der dann wiederum eine andere Zelle ändert usw. Die grafische Darstellung des Datenflusses wird aus Architekturdiagrammen wie etwa Fluss- oder Prozessdiagrammen ersichtlich.

Für Embedded-Systeme wurden verschiedene Computerprogrammiersprachen zur Darstellung des Datenflussparadigmas entwickelt. Der größte Vorteil dieses Modells besteht darin, dass es parallele Vorgänge deutlich und ohne die Komplexität des Threading zeigt. Textbasierte Datenflusssprachen wie VHDL und Verilog wurden vor allem dazu verwendet, die Implementierung von FPGAs und ASICs zu beschreiben, wo parallele Operationen an der Tagesordnung sind.

Grafische Programmiersprachen wie Ptolemy oder NI LabVIEW ermöglichen es Programmierern, ihr Datenflussprogramm mit Blöcken und Drähten bzw. Pfeilen darzustellen, mit denen die Zusammenhänge zwischen einzelnen Komponenten ausgedrückt werden. Bei der in LabVIEW genutzten Programmiersprache, auch bekannt als G, wird die Ausführung von der Struktur eines grafischen Blockdiagramms (Bild 2) festgelegt, auf dem der Programmierer die verschiedenen Funktionsknoten durch das Ziehen von Drähten verbindet. Diese leiten Variablen weiter und dieser Fluss wird dadurch gesteuert, dass jeder Knoten erst dann ausgeführt wird, wenn alle seine Eingangsdaten vorliegen.

Komplexe Abläufe mit einem State-Diagramm beschreiben

Ein State Diagram (Zustandsdiagramm) ist eine Darstellung des Verhaltens eines Systems, das eine endliche Anzahl von Zuständen umfasst. Es gibt verschiedene Arten von State Diagrams, die sich etwas voneinander unterscheiden und eine unterschiedliche Semantik aufweisen. Statecharts wurden von David Harel am Weizmann Institute of Science erfunden, um „konventionelle State-Transition Diagrams (Zustandsübergangsdiagramme) um … die Konzepte der Hierarchie, Parallelität und Kommunikation zu erweitern“. In den 1990ern wurden die Statecharts in die Spezifikation der Unified Modeling Language übernommen. Dort sind sie als Behavior Diagram (Verhaltensdiagramm) bekannt.

Um Statecharts zu verstehen, sieht man sich am besten zuerst ein klassisches State-Diagramm an und ergänzt dann Hierarchie, Parallelität und Ereignisse. Das klassische State-Diagramm besteht hauptsächlich aus zwei Konstrukten: Zuständen und Übergängen. Das nachfolgende State-Diagramm (Bild 3) illustriert beispielsweise die Funktionsweise eines einfachen Getränkeautomaten mit fünf Zuständen und sieben Übergängen. Die Maschine beginnt im Zustand „Leerlauf“ und geht in den Zustand „Münzen zählen“ über, wenn diese eingeworfen werden. Das Diagramm zeigt weitere Zustände und Übergänge, beispielsweise wenn die Maschine auf die Getränkeauswahl wartet, ein Getränk oder Wechselgeld ausgibt.

Ein Statechart (Bild 4), welches das Verhalten derselben Maschine beschreibt, besitzt weniger Zustände und Übergänge. Die Zustände „Münzen zählen“ und „Ausgeben“ können in einem übergeordneten Zustand zusammengefasst werden. So muss von diesen beiden Zuständen nur ein Übergang (T3) zum Zustand „Wechselgeld ausgeben“ definiert werden. Der Übergang T3 kann so konfiguriert werden, dass er auf drei Ereignisse reagiert: Getränk ausgegeben, Wechselgeld angefordert oder Münzen abgelehnt. Darüber hinaus kann der Zustand „Getränk auswählen“ im klassischen State Diagram wegfallen, wenn Übergang T2 mit einer Bedingung belegt wird. Diese muss erfüllt werden, damit der Übergang stattfindet. Wird die Bedingung nicht erfüllt, wird das Ereignis ignoriert und der Übergang findet nicht statt.

Da die meisten Embedded-Systeme als eine Art der Zustandsmaschine implementiert werden, bieten Statecharts eine bequeme Methode, um die High-Level-Architektur eines Systems darzustellen. Jedoch reichen Statecharts alleine meist nicht für die vollständige Implementierung eines Embedded-Systems aus, da jeder Zustand und jeder Übergang in einer anderen Form (Datenfluss, Imperativ) implementiert werden muss.

Dynamische Systeme simulieren

Ein dynamisches Systemmodell ist eine mathematische Darstellung der Dynamik zwischen Eingängen und Ausgängen eines dynamischen Systems. Die meisten Modelle dynamischer Systeme werden mit Differenzialgleichungen sichtbar gemacht, die aus physikalischen Gesetzen oder experimentellen Daten abgeleitet werden.

Viele Embedded-Systeme kommen in Regelschleifenanwendungen zum Einsatz, in denen die Ausgänge eines Systems von einer Reihe von Eingängen abhängen, darunter ein Referenz- oder Sollwert sowie ein Istzustand. Ein einfaches Beispiel für ein solches Regelsystem ist ein Heizungsthermostat. Der Sollwert liegt beispielsweise bei 21 °C. Liegt die aktuelle Zimmertemperatur bei 18 °C, sendet das Thermostat ein Signal an die Heizung, die sich dann einschaltet und den Raum heizt. Erreicht die Temperatur 21 °C, geht ein weiteres Signal vom Thermostat an die Heizung, die sich dann wieder ausschaltet.

Werkzeuge zur Simulation dynamischer Systeme werden von verschiedenen Herstellern angeboten. Die meisten Tools sind in der Lage, Programmcode zu erzeugen, der auf Embedded-Systemen ausgeführt werden kann. Diese Werkzeuge eignen sich besonders für Anwendungen, die komplexe Steuer- und Regelalgorithmen erfordern, sind aber bei der Implementierung universeller Programmieraufgaben recht schwerfällig.

Ideale Systemdesignplattform integriert verschiedene Modelle

Jedes dieser grafischen Designmodelle hat andere Stärken und/oder Schwächen, abhängig vom jeweiligen Anwendungsbereich. Eine ideale Systemdesignplattform ermöglicht Anwendern, sich frei zwischen den verschiedenen Modellen zu bewegen und sie sogar in eine einzige Darstellung zu integrieren.

Darüber hinaus sollte eine brauchbare Systemdesignplattform nicht nur grafische Programmiermethoden, sondern auch textbasierte Programmiermodelle zulassen. So könnte ein Programmierer einen Signalverarbeitungsalgorithmus als Datenfluss, eine Transfergleichung als Text, einen Motorsteuerungsalgorithmus als Simulation und den gesamten Systemablauf als Statechart darstellen (Bild 6).

Steigende Komplexität erfordert wachsende Abstraktion bei der Softwareentwicklung von Embedded-Systemen. Dabei unterstützen Systemdesignplattformen wie LabVIEW den Embedded-Entwickler durch die Integration vielfältiger Abstraktionstechniken ohne den Zugriff auf maschinennahe Funktionen einzuschränken. Erst dieser heterogene Ansatz ermöglicht effiziente Applikationen bei höchstmöglicher Abstraktion. Die Beschreibung von Parallelität, Threading und Timing werden angesichts des aktuellen Trends zu heterogenen Multicore-Prozessoren in Embedded-Systemen immer wichtigere Themen, die einen Einfluss auf Qualität und Leistung von Embedded-Software ausüben. So können die grafischen Datenflussprogrammiersprachen helfen, die Brücke von traditionellen Programmierkonzepten hin zu den neuen Rechenplattformen für die nächsten zehn Jahre und darüber hinaus zu schlagen.

Weiterführende Literatur:

Luciano Lavagno, Alberto Sangiovanni-vincentelli, Models of Computation for Embedded System Design (1998).

http://www-cad.eecs.berkeley.edu/Respep/Research/asves/paper1998/Luciano_asi98.ps

David Harel, Statecharts: A Visual Formalism for Complex Systems, Department of Applied Mathematics, The Weizmann Institute of Science, 1986.

Barr, Michael. „Introduction to Closed Loop Control,“ Embedded Systems Design, August 2002.

Entwicklung von Embedded Systemen, http://www.ni.com/embedded/d/

(ID:280617)