Zeit als neue Währung

Embedded-Programmiersprachen (Teil 2)

Zeit als neue Währung

Die im ersten Teil vorgestellten Rechenmodelle nutzen gezielt die Stärken heutiger Programmiersprachen und unterstützen damit unsere Denkweise beim Lösen von Problemen. Erfahren Sie in diesem zweiten Teil, wie sich diese Modelle im heterogenen Aktorframework LabVIEW kombinieren und auf plattformbasierter Hardware in Echtzeit ausführen lassen.

MoC’s (Models of Computation) sind Rechenmodelle, die verschiedene Zeitverhalten komfortabel abtrahieren. Als Daumenregel wähle man das schlankeste MoC, welches natürlich ein spezifisches Problem löst 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 Differenzialgleichungen, die eher mit Simulation (Model-Based-Design) entworfen werden, ins Framework eingefügt werden wie Statecharts, welche zustandsorientierte Applikationslogik vereinfacht. Die textbasierte C-Notation hingegen ermöglicht das Einbinden bestehender Algorithmen oder direkten Zugriff auf Betriebssystem oder Hardware.

Modelle ins heterogene Aktor-Framework einbetten

Gefragt ist nun ein heterogenes ‚Gefäss‘, in das sich die verschiedenen MoCs einbetten, verbinden und parallel ausführen lassen. Dafür eignet sich durch inhärente 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. Die grafische Systemdesign-Umgebung LabView von National Instruments eignet sich derzeit als das passendste Aktor-Framework für heterogene MoCs. LabView geht weit über das klassische Verbinden unterschiedlicher Tools hinaus. 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 .

Software mit Hardware zusammenführen

Diese Aktororientierung mit den eingebetteten MoCs ist ein mächtiges Instrument, durch das sich der Entwickler in der Embedded-Software auf verschiedenen Abstraktionsniveaus bewegen kann und trotzdem immer die globale Systemsicht vor Augen hat. Nun wird aufgezeigt, wie diese Software mit Embedded-Hardware zusammengeführt wird. Ob intelligenter Sensor am IoT, Embedded-Webserver, Messnetzwerk, Cloud-Lösung oder Regler mit Tablet. Der Anwendungsentwickler erzielte durch das Aktor-Framework LabView mit den flexiblen Rechenmodellen schnell Ergebnisse und hat die Machbarkeit seiner Idee im Labor geprüft. Nun soll das Serienprodukt geplant werden. Mit Hardware, die individuell auf die Bedürfnisse des Endanwenders zugeschnitten ist. In der Praxis bedeutet dies meist eine Neuentwicklung von Hard- und Software auf der Basis von ‚C‘ mit RTOS auf einem Mikrocontroller. Es geht auch anders: Der hier vorgestellte Plattformansatz ermöglicht nicht nur ein Wiederverwenden der bisherigen Software-Investitionen, sondern gibt dem Entwickler zusätzlich die Freiheit, Hardwareentscheidungen hinauszuzögern. Genau dies war beim Messnetzwerk im Zug, beim Solarkraftwerk und aktiver Schallbekämpfung aus Teil 1 die wichtigste Voraussetzung. Dieser zweite Teil führt jetzt durch die Möglichkeiten von LabView auf Embedded Hardware und diskutiert, wie dieser Leitfaden bei zwei Praxisbeispielen angewendet wurde.

Die Software macht den Unterschied

Was LabView für smarte Embedded-Systeme so interessant macht, sind erstens seine mächtigen Bibliotheken für Mathematik und Signalverarbeitung und zweitens die komfortable Abstraktion von Timing, Betriebssystem, Multitask-ing, Multicore und Zugriff auf unterlegte Hardware. Die Anwendung lässt sich damit ohne Detailkenntnisse zum Unterbau per Knopfdruck auf die eigene Embedded Hardware laden und dort in Echtzeit im 24/7-Betrieb ausführen. Welche Hardware eignet sich nun am besten für die individuellen Bedürfnisse? Das Gemeinsame aller aufgeführten Hardwareplattformen ist die grafische Programmierbarkeit mit LabView. Relevante Unterschiede zeigen sich im Formfaktor, der Leistungsfähigkeit der CPU und der Unterstützung durch die Bibliotheken. Grundsätzlich unterscheiden sich die beiden Klassen Singleboard-Computer und Einsteckmodule. Die Wahl zwischen den beiden hängt z.B. davon ab, ob im Projekt überhaupt Hardware-Entwicklung eingeplant ist. Wenn nicht, bleibt der Single-Board-Computer übrig. Ansonsten bietet sich vom Zweiplatinenansatz mit Einsteckmodul im Baseboard bis zur Kompletthardware die volle Hardwarebandbreite an. Ausschlaggebend sind jedoch die eigenen Anforderungen an die geplante Anwendungssoftware und deren Bedarf an Funktionalität, Rechenleistung und Speicher. Es gibt zwei unterschiedliche Wege von LabView zur Embedded Hardware. Der erste führt über Echtzeit-Linux auf die Dual-Core-ARM9-Architektur mit FPGA. Das SOM-Einsteckmodul (Bild 3) und die Single-Board-RIO-Familie von National Instruments (NI) funktionieren nach diesem Schema. Die anderen Module und die Kompletthardware folgen dem Weg über den universellen NI ANSI-C-Code-Generator mit µ-Kernel. Damit ließe sich LabView auf irgendeinen 32-Bit-Prozessor portieren. Die Softwarefunktionalität und Leistung sind eingeschränkt, dafür punktet dieser Ansatz bei anderen Aspekten, wie Low-Power, Low-Cost und Bootzeiten unter 1 Sekunde.

Einfach nutzbare SBCs

Der Vorteil von Single-Board-Computern (SBCs) mit an Klemmen abgreifbarem I/O liegt auf der Hand: sie sind sofort betriebsbereit. Das heißt: Sensoren, Aktoren und Kommunikationskabel anschließen, mit dem PC verbinden, die Entwicklungsumgebung LabView starten und die Embedded-Applikationsentwicklung kann ohne weitere Vorarbeit am ersten Tag beginnen. Das macht SBCs interessant für Machbarkeitsstudien, Rapid Prototyping und Kleinserien. Die CPU-Leistungsklassen skalieren derzeit vom 500MHz Fixed-Point-DSP bis zum 667MHz-Floating-Point-Dual-Core-ARM9 auf Formfaktoren vom Hutschienen- über das PC-104- bis zum Europaformat (Bild 1, rechts). Die Hardware-Funktionalität bietet alles, was smarte Embedded Systems heute verlangen: vom Analog- und Digital-I/O über Standard-Kommunikationskanäle und Embedded-Filesystemen bis zum Multi-Touch-TFT. In der LabView-Umgebung steht für jede dieser Hardwarefunktionen ein Virtuelles Instrument (VI = Funktionsblock /Treiber) zur Verfügung.

Briefmarken- oder Scheckkartenrechner

Ein Mix aus einem Standardmodul, welches in ein kundenspezifisches Baseboard eingesteckt wird, kombiniert die Vorteile vom Single-Board-Computer mit Komplett-Hardware. Die Komplexität der Baseboards ist geringer als bei Mikroprozessor-Komplett-Hardware, denn die kritischen Schaltungsteile um CPU und Memory sind schon auf dem Einsteckmodul realisiert. Außerdem werden abgekündigte Bauteile im Prozessorbereich durch den Hersteller nach Form-Fit-Function ersetzt. Von der Funktionalität her bietet der Zweiplatinenansatz ähnliches wie bei Single-Board-Computern, lässt sich im Vergleich aber beliebig erweitern. Der Vorteil dabei ist ein nahtloses Anpassen von Hardware in Form und Funktion an jede beliebige Aufgabenstellung. Außerdem müssen zu Beginn der Entwicklung, beispielsweise beim Rapid Prototyping, noch nicht alle Anforderungen wie in Stein gemeißelt sein, denn Baseboards lassen sich schnell ändern. Diese Flexibilität hat jedoch auch ihren Preis: im Vergleich zum Single-Board-Computer muss beim Zweiplatinenansatz immer zuerst Hardware in Form eines Baseboards entwickelt werden. Je nach Anforderung an Platzbedarf, Funktionalität, Leistungsverbrauch und Bootzeit wählt der Designer ein Briefmarken-Coremodul, ein Scheckkarten-COM oder ein SOM. Sind nach dem Prototyping mittels Briefmarken- oder Scheckkartenrechner mit C-Generator/ µ-Kernel-Support alle Anforderungen bekannt, lassen sich die Einsteckmodule mit dem Baseboard ‚verheiraten‘. Das Ergebnis ist ein kundenspezifisches, komplett integriertes Mikroprozessorboard, welches in mittleren und großen Stückzahlen zu üblichen Bestückpreisen hergestellt werden kann. Seine spezifische LabView-Hardware kann der Kunde bei Schmid Elektronik entwickeln, produzieren und testen lassen oder dies in Lizenz selber tun.

Mit C-Code-Generator auf eigene Hardware

In der Embedded-Welt der Mikrocontroller und DSPs ist die Sprache ‚C‘ heute der Quasi-Standard. Genau hier setzt National Instruments‘ ANSI-C-Code-Generator an. Er übersetzt ein grafisches LabView-Diagramm/-Blockschaltbild inklusive Mathematik- und Signalverarbeitungs-VIs in neutralen ANSI-C-Code für 32-Bit-Mikrocontroller. Schmid Elektronik kombiniert diese Technologie mit der Funktionalität der Single-Board-Computer im Hutschienen- und PC104-Format sowie Briefmarken-Coremodulen und Scheckkarten-COMs (Bild1, links). Der so erzeugte Embedded-Applikations-C-Code wird mit dem Quellcode eines schlanken µ-Kernels verlinkt, mit den gängigen Tools (Compiler, Linker, Loader) in eine echtzeitfähige Standalone-Firmware gebaut und als Loaderfile ins Flashmemory der Zielhardware geladen. Von dort bootet die Anwendung direkt in weniger als einer Sekunde, geht in einen zuverlässigen 24/7-Echtzeit-Betrieb über und ist gegen Einflüsse von außen weitgehend unempfindlich.

Flexibel und netzwerkfähig durch Echtzeit-Linux

Das NI System-On-Module und die NI Single-Board-Computers werden durch Echtzeit-Linux betrieben. Durch dessen Beliebtheit und weltweiter Verbreitung sowie dazugehörigem Ökosystem eröffnen sich speziell für vernetzte, smarte Embedded Systems neue Möglichkeiten. Installiert ist die für den Embedded-Bereich verbesserte ? ngström-Distribution mit einem Repository auf den Servern von NI. Das LabView-Diagramm wird nach dem ‚POSIX‘-Standard 1:1 auf das Linux-Betriebssystem abgebildet. Dort lässt sich mit dem Package-Manager ‚opkg‘ die ‚Spielwiese‘ des Linux-Ökosystems nutzen, ob SQL-Datenbank, Apache-Webserver oder QT-GUI. Als Bootloader dient (Das) ‚U-boot‘. Weitere Merkmale von Echtzeit-Linux sind: Mit der ‚Busybox‘ steht ein Tool für typische Embedded-Aufgaben zur Verfügung, von Filesystemzugriffen, Abholen der Systemzeit und kleinem DHCP-Client bis zum Sleepmodus und Systemreboot. LabView erhält direkten Zugriff auf die Linux ‚command-line‘, womit sich direkt Systembefehle ausführen und so Filesystem- und User-Berechtigungen live steuern lassen. Mit Technologien wie ‚Python‘ stehen mächtige Scriptsprachen zur Verfügung. LabView kann mit TCP/IP über ‚localhost‘ die Dienste weiterer Linux-Prozesse (Deamons) anzapfen. Über das native ‚C-API‘ von LabView kann auf Bibliotheken des Linux-Betriebssystems zugegriffen werden. Der versierte Linux-User kann den Linux-Kernel jederzeit individuell konfigurieren und neu kompilieren. Bei smarten und vernetzten Embedded Systems ist Timing die Herausforderung Nr.1. Hier unterstützt Linux als LabView-Betriebssystem mit sechs nützlichen Schemas. Mit ‚cron‘ lassen sich bis [min]-Auflösung repetitive Tasks wie das Löschen von Logfiles ausführen. Der ‚CFS‘ (Completely Fair Scheduler) dient vor allem zum Implementieren nicht-zeitkritischer, aber trotzdem effizienter ‚Work-Tasks‘. Werden Antwortzeiten in [ms] benötigt, wird der Kernel ‚preemtive‘ konfiguriert. Dank Multicore-Support von LabView lassen sich grafische ‚Tasks‘ direkt einem Prozessorkern zuordnen. Bei zeitkritischen Tasks mit gefordertem Jitter zwischen 10…100µs kommt der ‚PREEMPT_RT‘-Patch ins Spiel. Harte Echtzeit im einstelligen [µs]- oder sogar [ns]-Bereich wird durch den FPGA garantiert.

Messnetzwerk im Hochgeschwindigkeitszug

Bei der flächendeckenden Messintelligenz im Hochgeschwindigkeitszug aus Teil 1 dieses Beitrags wurde nach dem Prototyping mit einem Single-Board RIO das System-On-Module sbRIO-9651 von National Instruments als CAN-Master gewählt. Ein zentraler Grund neben der geforderten, hohen Rechenleistung war vor allem die flexible und sichere Netzwerkfähigkeit zum Leitrechner dank Linux. Über einfache CAN-Befehle steuert der Master zukünftig bis zu 256 Knoten. Diese sind je nach Typ und Aufgabe entweder als Briefmarkenrechner auf Baseboard oder Kompletthardware ausgeführt. Ein Netzwerk mit 32 Knoten wurde bereits erfolgreich im Feld getestet.

System-On-Module in der ‚Sonnenblume‘

Beim zweiten Beispiel aus diesem Beitrag handelte es sich um ein kompaktes Solarkraftwerk, welches die Sonnenenergie dank Solarkonzentration effizienter nutzen kann als bisherige Anlagen. Das sogenannte High-Concentration- Photovoltaic-Thermal(HCPVT)-System ist auch als ‚Sonnenblume‘ bekannt. Das Herzstück der zehn Meter hohen Struktur ist eine 40qm große Parabolschüssel, die mit einem Track-ingsystem kontinuierlich zur Sonne ausgerichtet wird. Basis dazu sind ein Sonnensensor und zwei bürstenlose DC-Motoren, welche als dezentrale Intelligenz über CAN mit dem Embedded-System verbunden sind. Dessen ‚Hirn‘ ist das NI sbRIO-9651-System-On-Module. Es ist über das Baseboard und dezentrale Knoten mit Dutzenden von Sensoren verbunden, vom Temperatur-, Druck- und Feuchtesensor bis zur Meteo-station. Höchste Zuverlässigkeit spielt sowohl in Hard- wie auch der Software eine zentrale Rolle. So soll sich die Schüssel beim Ausfall kritischer Komponenten oder bei Extremsituationen wie Sturm immer in eine Sicherheitsposition drehen und einen konstanten Innendruck aufrechterhalten.

Schmid Elektronik AG
www.schmid-elektronik.ch

Das könnte Sie auch Interessieren