Werkzeuge und Notationen Entwicklungsbeschleuniger - Zeit als neue Währung (Teil 1)

Autor / Redakteur: Marco Schmid * / Franz Graser

Ausführbare Rechenmodelle in einem heterogenen Aktor-Framework unterstützen unsere Denkweise und beschleunigen die Entwicklung von Timing in Embedded-Software.

Firma zum Thema

Bild 1: Verschiedene Rechenmodelle passen sich flexibel der Aufgabenstellung an und lassen sich in ein heterogenes Framework einbetten, verbinden und auf Embedded-Hardware ausführen. Dank dieses Entwicklungsbeschleunigers schaffen auch kleine Teams in kurzer Zeit große Ergebnisse.
Bild 1: Verschiedene Rechenmodelle passen sich flexibel der Aufgabenstellung an und lassen sich in ein heterogenes Framework einbetten, verbinden und auf Embedded-Hardware ausführen. Dank dieses Entwicklungsbeschleunigers schaffen auch kleine Teams in kurzer Zeit große Ergebnisse.
(Bild: Schmid Elektronik)

In der physikalischen Welt passiert vieles auf einmal. Echtzeit, schnelle Reaktionszeiten, 24/7-Betrieb und Kommunikation sind gefragt. Embedded-Systeme treffen als zeitdiskrete, künstliche Recheneinheiten auf zeitkontinuierliche, natürliche Prozesse und sind damit Hybride.

Sie sind darüber hinaus heterogene Gebilde aus Mikroprozessoren mit analogen und digitalen Sensoren und Aktoren. Das macht sie von Natur aus komplex und ihre Entwicklung fehleranfällig.

Smarte Embedded-Systems [7] oder Cyber-Physical-Systems [1] gehen in drei Aspekten entscheidend weiter und lassen die virtuelle mit der physikalischen Welt verschmelzen. Erstens sind Parallelität und Timing das Maß für formale Korrektheit der Software. Zweitens sind dezentrale Regeltechnik und Synchronisierung stark ausgeprägt. Drittens kommunizieren die Systeme in Echtzeit über ein Netzwerk. Dieses Verständnis der gemeinsamen Dynamik ist es, was die neue Disziplin vom traditionellen Ansatz fundamental unterscheidet.

Beispiel 1: Zeit und Parallelität sind die wichtigsten Merkmale künftiger smarter Embedded-Systeme [2,3,4,5]. Beides waren die Hauptanforderungen an ein dezentrales Regelnetzwerk im Hochgeschwindigkeitszug eines chinesischen Bahnbetreibers. Ein zentraler CAN-Master steuert bis zu 256 lokale PID-Controller-Knoten in Echtzeit.

Im 50-Hz-Takt sendet der Master die Regelkoeffizienten an die individuellen Controller-Knoten und erhält im selben Zeitraster deren Regelgrößen zurück. Vorgabe für die Entwicklung: in einem Monat ein funktionsfähiger Prototyp, drei Monate später das Serienprodukt.

Beispiel 2: Die Schweizer Firma Dsolar Ltd. entwickelt zusammen mit Schmid Elektronik die Hauptsteuerung für ihre energieeffiziente, autonome Solaranlage in Form einer Satellitenschüssel. Darin sind 36 gekrümmte Spiegel montiert, die die Sonnenstrahlen im Brennpunkt auf das 2000-fache ihrer Energie bündeln. In diesem Hotspot werden elektrische und thermische Energie mit einem Wirkungsgrad von 80 Prozent (!) gewonnen.

Die Komplexität in Schach halten – von Anfang an

Die Schüssel dreht sich über zwei Achsen immer direkt der Sonne zu. Daher rührt auch der Kosename „Sunflower“ (Sonnenblume). Das zentrale Embedded-System von Schmid Elektronik ist mit Dutzenden von Sensoren verbunden, vom Temperatur-, Druck- und Feuchtesensor bis zur Meteostation und Sonnensensor.

Die Aktoren bestehen unter anderem aus zwei bürstenlosen 400-W-DC-Motoren. Ist das System im Feld installiert, kann via VPN von extern live drauf zugegriffen werden. Die hohe Komplexität wird neben den funktionalen vor allem durch die nicht-funktionalen Anforderungen bestimmt. Fehlererkennung und -behebung sind genauso wichtig für sicheren Betrieb wie Notfallszenarien, zum Beispiel beim Ausfall kritischer Komponenten bei Sturm und Gewitter.

Schließlich ist ein sportlicher Herstellungspreis einzuhalten, damit das System auch in ärmere Länder verkauft werden kann. Wegen der enormen Systemkomplexität soll die Embedded-Anwendung auf hoher Abstraktionsebene mit formalen Modellen beschrieben und daraus der Low-Level-Code generiert werden. Davon verspricht sich Dsolar Ltd. ein durchdachtes und korrektes Softwaredesign, das sich auch bei Änderungen und Weiterentwicklungen stabil verhält.

Beispiel 3: In einer Machbarkeitsstudie zu aktiver Schallbekämpfung wurde der Kernalgorithmus in Matlab realisiert und mit Hilfe von Testdaten verifiziert. Danach übersetzte ihn ein Praktikant nach C, portierte ihn auf einen Fixed-Point-DSP und testete ihn in realer Umgebung unter Echtzeitbedingungen.

Jetzt soll das Funktionsmuster zuerst in einen industriellen Prototypen und anschließend in die Serie überführt werden. Da kommen typische Embedded-Funktionen wie etwa Sensorik (Mikrofone), Aktorik (Lautsprecher) und Kommunikation (Webserver, Netzwerk) dazu. Serienfertigung ist gleichbedeutend mit höheren Stückzahlen und folglich tiefst möglichen Herstellkosten.

Da spricht vorerst vieles für den traditionellem Ansatz mit Mikroprozessor, RTOS und der Programmiersprache C. Letztere will der verantwortliche Systemingenieur aber aus drei Gründen vermeiden: Erstens müsste die Applikationsentwicklung ausgelagert werden, weil der C-Programmierer im Haus fehlt. Zweitens soll der Algorithmus auch zukünftig in der vertrauten Matlab-Notation laufend angepasst werden.

Drittens wird häufiges Rapid-Prototyping erwartet, sowohl beim Algorithmus als auch beim I/O. Also muss eine skalierbare Hardware her, vom leistungsfähigen PXI-System über eine modulare, robuste, SPS-Ähnliche Steuerung bis zur kundenspezifischen Hardware.

Die drei Projektbeispiele haben eines gemeinsam: Es handelt sich hier um eine neue Liga von Embedded-Systemen. Deshalb muss eine Methode her, die unsere Denkweise besser unterstützt. So lässt sich die Komplexität beherrschen und das Projekt bleibt auf Kurs. Das System soll von Beginn an richtig entworfen werden, schon lange vor der Aufteilung in Hardware und Software [3].

Auch Co-Design wird nie dieselbe Beschleunigung erreichen wie ein System, das von Beginn an das tut, was es soll und dies unabhängig von seiner Implementierung, nämlich korrektes Verhalten bezogen auf Funktion, Kommunikation und Zeit.

Der Schlüssel dazu sind flexible Rechenmodelle, die uns ein Verständnis für physikalische zeitliche Zusammenhänge geben. Sie werden in ein heterogenes Framework eingebettet und auf verschiedenen Zielplattformen in Echtzeit ausgeführt:

  • Diese formalen Modelle beschreiben das Systemverhalten auf hohem Abstraktionsgrad, weitgehend unabhängig von Programmiersprache und unterlegter Hardware. Es handelt sich um Rechenmodelle (Models of Computation), auch MoC's genannt [2,3,4] (Bild 2,3,4). Sie abstrahieren Syntax und Semantik und lenken unseren Fokus auf Parallelität, Zeit, Kommunikation und Synchronisierung. Je abstrakter das Modell, desto größer der Lösungsraum.
  • MoC's können beliebig kombiniert werden (Bild 2,3,4). Voraussetzung dazu ist ein heterogenes Entwicklungs-Framework, worin sich die MoC's einbetten und ausführen lassen [5].
  • Dank plattformbasiertem, hardwarunabhängigem Design erhält der Ingenieur die Freiheit, Entscheidungen zu Hardware und Implementierungsdetails hinauszuzögern. Er weiß, dass sich das Framework mit den MoC's auf mehreren Zielsystemen unterschiedlicher Funktions- und Leistungsklassen ausführen lässt und sich zeitlich und funktionell immer korrekt verhält [4].

Natur und Eigenschaften von Notationen

Ein MoC sorgt dafür, dass sich der Entwickler nicht in künstlicher Komplexität verirrt. Er kann mit ihm präzise ausdrücken, was die Spezifikationen fordern, sei es Funktion, Kommunikation oder Zeitverhalten. Damit sind MoC's mit einer DSL (Domain Specific Language) vergleichbar.

Eine Analogie zur Literatur: ein MoC entspräche einem Rezept oder einem Gedicht. Damit beschreibt der kreative „Entwickler“ das, was der Kunde (lesen) will, was ihm wichtig ist. Die Notation oder Umsetzung wäre dann Deutsch, Französisch oder Englisch. MoC's lassen sich grob in textbasierte, datenflussorientierte, regeltechnische, simulations-, zustands- und taskorientierte Modelle einteilen.

Für jedes MoC eignet sich eine bestimmte Programmiernotation, sei es C, G, M-Script, Model-Based-Design oder UML. Die heterogene Natur smarter Embedded-Systems oder sogar Cyber-Physical-Systems verlangen nach unterschiedlichen Zeitdarstellungen [2,3]. Diese lassen sich in zwei Gruppen einteilen. Die erste Gruppe steht für die Natur und Eigenschaften eines MoC respektive einer Notation:

  • Zeitkontinuierlich, Zeitdiskret: Physikalische Prozesse sind naturgemäß zeitkontinuierlich, werden etwa mit Differentialgleichungen und Rückkopplung beschrieben und mit Integrationssolvern gelöst. Die Modelle beziehen sich dabei auf eine reelle Zeit und entwickeln sich mit ihr. In der digitalen Computerwelt hingegen wandeln sich die Differentialgleichungen zu Differenzengleichungen mit diskreter Integrationszeit.
  • Sequentiell, Parallel: Bei ersterem wird zeitlich nacheinander Schritt für Schritt abgearbeitet. Beispiele dazu sind Kommunikationsprotokolle oder Hardwaretreiber. Die zeitlich parallele Verarbeitung kommt eher bei mehreren Prozessen mit unterschiedlichen Timings wie Regler mit Benutzerschnittstelle vor.

Die Notation C zum Beispiel eignet sich für ein textbasiertes MoC und wurde ursprünglich für zeitdiskrete, sequentielle Prozesse konzipiert.

Stärken und Schwächen von Notationen

Die zweite Gruppe von Zeitdarstellungen drückt die Stärken und Schwächen der jeweiligen Programmiernotation aus, bzw wie sich letztere kompensieren lassen:

  • Synchron, Asynchron: Zwei zeitlich unterschiedliche Betrachtungsweisen. Beim Ersten handelt es sich um eine starre, aber gleichzeitig komfortable Abstraktion von Zeit und alle Signale im System beziehen sich auf dieselbe Zeitachse, dem „Clock“. Das Zweite ist reaktiv, entspricht wohl eher der Praxis, ist aber technisch aufwändiger umzusetzen (Interrupts, Events).
  • Kooperativ, Preemptiv, echt parallel: Definiert das Zeitverhalten paralleler Prozesse. Dafür wird für die beiden erstgenannten Multitasking oder Multithreading genutzt, unterstützt durch den Scheduler eines RTOS. Echte Parallelität verlangt nach spezieller Hardware wie etwa Multicore-Mikrocontroller oder FPGAs.

Bild 2: Das textbasierte Rechenmodell (C-Algorithmus) ist optimiert für diskrete, sequentielle Zeitdarstellung und ist hier verknüpft mit dem parallel funktionierenden Datenflussmodell (LabVIEW).
Bild 2: Das textbasierte Rechenmodell (C-Algorithmus) ist optimiert für diskrete, sequentielle Zeitdarstellung und ist hier verknüpft mit dem parallel funktionierenden Datenflussmodell (LabVIEW).
(Grafik: Schmid Elektronik)

Jedes MoC hat Stärken und Schwächen. Deshalb soll es passend zum Problem gewählt werden, ähnlich wie die Werkzeuge eines Schweizer Armeetaschenmessers. Als Daumenregel wähle man das schlankeste MoC, das natürlich ein spezifisches Problem löst [3] und füge dann MoC um MoC ins Framework ein.

Eine Regeltechnik-Idee lässt sich etwa sehr aussagekräftig in Matlab-Notation umsetzen und ausführen. Sie kann ebenso wie Differentialgleichungen, die eher mit Simulation (Model-Based-Design) entworfen werden (Bild 3), ins Framework eingefügt werden wie Statecharts, die die zustandsorientierte Applikationslogik vereinfachen. Die textbasierte C-Notation hingegen ermöglicht das Einbinden bestehender Algorithmen oder direkten Zugriff auf Betriebssystem oder Hardware (Bild 2).

Bild 3: Eine Kombination von drei unterschiedlichen Rechenmodellen mit Regeltechnik (Matlab-Notation), Simulation (Model-Based-Design) und Datenfluss (LabVIEW) für einen PID-Regler.
Bild 3: Eine Kombination von drei unterschiedlichen Rechenmodellen mit Regeltechnik (Matlab-Notation), Simulation (Model-Based-Design) und Datenfluss (LabVIEW) für einen PID-Regler.
(Grafik: Schmid Elektronik)

Gefragt ist nun ein heterogenes Gefäß, in das sich die verschiedenen MoC's einbetten, verbinden und parallel ausführen lassen. Nach [4] und [5] eignet sich dank inhärenter Parallelität speziell das Aktor-Framework. Dessen Konzept setzt sich aus datenorientierten, funktionalen Komponenten (Aktoren) und deren Interaktion (Scheduling) zusammen. Aktoren warten auf Input, „feuern“ und produzieren Output. Sie skalieren von einfachen Operatoren wie Multiplikation und logischer Verknüpfung über inverse FFT und Matrizenrechnung bis zum Statechart, werden parallel ausgeführt und kommunizieren über Ports.

Modelle ins heterogene Aktor-Framework einbetten

Bild 4: Welches Rechenmodell sich zur Lösungen einer quadratischen Gleichung besser eignet, bleibt dem Leser überlassen. Oben die Lösung mit dem Datenflussmodell (LabVIEW), unten mit dem Regeltechnikmodell (Matlab-Notation). Beide Modelle liefern dasselbe Ergebnis.
Bild 4: Welches Rechenmodell sich zur Lösungen einer quadratischen Gleichung besser eignet, bleibt dem Leser überlassen. Oben die Lösung mit dem Datenflussmodell (LabVIEW), unten mit dem Regeltechnikmodell (Matlab-Notation). Beide Modelle liefern dasselbe Ergebnis.
(Grafik: Schmid Elektronik)

Die grafische Systemdesign-Umgebung LabVIEW [6] von National Instruments eignet sich als das derzeit passendste kommerziell verfügbare Aktor-Framework für heterogene MoC's. LabVIEW geht weit über das Verbinden unterschiedlicher Tools oder eine „eierlegende MoC-Wollmilchsau“ [2] hinaus.

Auch wird nicht zwischen theoretischer Spezifikationsphase und architekturbetonter Implementierungsphase unterschieden. Das LabVIEW- Aktor-Framework kann direkt diskrete Dynamik digitaler Rechner mit kontinuierlicher Dynamik physikalischer Prozesse verbinden. Ein unterlegter Scheduler steuert Ausführung und Kommunikation vom Aktornetzwerk nach strukturiertem Datenfluss [5].

LabVIEW ermöglicht außerdem die „richtige“ Abstraktion zur „richtigen“ Zeit und eignet sich bestens als Wirt für die verschiedenen MoC's:

  • Plattformbasierter Ansatz ermöglicht gleichzeitig formale Verifikation und Validation auf Modellebene.
  • Support von heterogenen MoC's
  • Hybrid aus diskretem und kontinuierlichem Zeitmodell
  • Parallelität und Kommunikation sind natürlicher Bestandteil der Sprache
  • Dank Hierarchie und Modularität lassen sich verschiedene MoC's auf beliebigem Level als Submodelle integrieren.
  • Abstrakt und trotzdem hardwarenah und damit ausführbar auf verschiedenen Hardwarearchitekturen.
  • Kommerziell verfügbar, weltweite Akzeptanz und ein weit verbreitetes Ökosystem

Diese Aktor-Orientierung mit den eingebetteten MoC's ist ein mächtiges Instrument, mit dem sich der Entwickler in der Embedded-Software auf diversen Abstraktionsniveaus bewegen kann und trotzdem immer die globale Systemsicht vor Augen hat. Der zweite Teil des Berichts zeigt auf, wie diese Software mit Embedded-Hardware zusammengeführt wird. //FG

Referenzen:

[1] Cyber-Physical-Systems ganz konkret, Marco Schmid, Schmid Elektronik, ELEKTRONIKPRAXIS Nr. 7, April 2014.

[2] Models of Computation for Embedded System Design, Luciano Lavagno, Politecnico di Torino, Alberto Sangiovanni Vincentelli, EECS Departement of UK Berkeley, September 1998.

[3] Models of computation and languages for embedded system design, A.Jantsch und I.Sander, Departement for Microelectronics & Information Technology, Royal Institute of Technology, Kista, Sweden, IEEE Proc.-Comput. Digit. Tech., Vol. 152, Nr. 2, März 2005

[4] Addressing Modeling Challenges in Cyber-Physical-System, Patricia Derler, Edward A.Lee, Alberto Sangiovanni Vincentelli, EECS Departement of UK Berkeley, March 2011

[5] Actor-Oriented Control System Design: A Responsible Framework Perspective, Jie Liu et. al. IEEE-Mitglied, IEEE Transactions on Control Systems Technology, Vol.12, Nr. 2, März 2004

[6] Kreativität entfesseln, Marco Schmid, Schmid Elektronik, iX Developer 2/2014 – Embedded Software, Heise Zeitschriften Verlag, Februar 2014

[7] Kompakt verbunden, Marco Schmid, Schmid Elektronik, Embedded-Design, Ausgabe November 2014

* Marco Schmid ist Diplom-Ingenieur (FH) für Systemtechnik. Er ist Inhaber des Lösungsanbieters Schmid Elektronik in Münchwilen/Schweiz.

(ID:43140829)