Nr. 16/2015 vom 07.10.2015

Für den Entwickler bedeutet dies, dass er die embedded Hard- und -Software mithilfe von C auf einem Mikrocontroller neu entwickeln muss. Wie man aus diesem Raster ausbrechen und mit LabVIEW als Embedded-Programmiersprache den direkten Weg wählen kann, zeigt dieser Zweiteiler.
In der physikalischen Welt passiert vieles auf einmal. Embedded-Systeme mit ihren Sensoren und Aktoren treffen als digitale, künstliche Recheneinheiten auf analoge, natürliche Prozesse. Das macht sie von Natur aus komplex und fehleranfällig. Deshalb muss eine Methode her, die unsere Denkweise optimal unterstützt. Das System soll von Beginn an «richtig» entworfen werden, schon lange vor der Aufteilung in Hard- und Software. Es soll das tun, was es soll, nämlich korrektes Verhalten, bezogen auf Funktion, Kommunikation und Zeit. Der Schlüssel dazu sind flexible Rechenmodelle, welche unterschiedliche Zeitaspekte abstrahieren. Diese werden in das Framework LabVIEW eingefügt und auf einer passenden Hardwareplattform in Echtzeit ausgeführt.
Viele Ingenieure schätzen den Charme und kennen die Vorteile des Entwicklungsbeschleunigers LabVIEW, sind aber skeptisch, ihn gerade im sensiblen Embedded-Umfeld einzusetzen. Was aber, wenn sich die «softe» grafische Programmierung mit «harten» Embedded-Funktionen wie Echtzeit, Interrupts, DMA, Low-Level-Treiber, ausfallsichere Speicher, Watchdog, Fehlererkennung und -behebung für robusten 24/7-Betrieb sowie skalierbarer Strombedarf kombinieren liesse?
Der Nutzen ist dreifach: erstens mächtige LabVIEW-Funktionen und Bibliotheken für Mathematik und Signalverarbeitung, zweitens eine komfortable Abstraktion von unterlegter Hardware und Timing und drittens verschiedene Rechenmodelle, die das Entwicklerleben erleichtern.
Bei Embedded-Systemen sind dezentrale Mess- und Regeltechnik und Synchronisierung stark ausgeprägt und Parallelität, sowie Timing das Mass für formale Korrektheit der Software. Genau hier bieten flexible Rechenmodelle Unterstützung. Sie geben uns ein Verständnis für physikalische und zeitliche Zusammenhänge und beschreiben das Systemverhalten auf hohem Abstraktionsgrad, weitgehend unabhängig von Programmiersprache und unterlegter Hardware. Eine Analogie zur Literatur: Ein Rechenmodell entspräche einem Rezept oder einem Gedicht. Damit beschreibt der kreative «Entwickler» das, was der Kunde (lesen) will, was ihm wichtig ist. Die «Programmiersprache» hingegen wäre dann Deutsch, Französisch oder Englisch.
Rechenmodelle lassen sich grob in text-, datenfluss-, simulations-, zustands- und taskorientierte Modelle unterteilen. Eine Regeltechnik-Idee lässt sich etwa sehr aussagekräftig in der textorientierten Matlab-Notation umsetzen (Bild 3 oben). Sie kann ebenso wie Differentialgleichungen nach dem Simulationsmodell (Bild 3 Mitte) im LabVIEW-Framework eingefügt werden wie Statecharts, welche die zustandsorientierte Applikationslogik vereinfachen (Bild 4). Die textbasierte C-Notation hingegen erlaubt z.B. das Einbinden bestehender Algorithmen oder direkten Zugriff auf Hardware. Multitasking wiederum abstrahiert Funktionen des Betriebssystems (Bild 5).
Derzeit bieten sich drei Klassen von Embedded-Boardlevel-Hardware an, die LabVIEW mit seinen Rechenmodellen unterstützen:
Diese drei Hardwareklassen sind als Plattform ausgelegt. Hardware wird so abstrahiert, dass sich eine LabVIEW-Applikation mit wenig Aufwand portieren lässt. Damit erhält man die Freiheit, Entscheidungen zu Hardware und Implementierungsdetails hinauszuzögern und je nach Funktions-, Leistungs- oder Kosten- bedarf die nächst höhere oder tiefere Stufe zu wählen. Die Methode mit den eingebetteten Rechenmodellen im LabVIEW-Framework ist ein mächtiges Tool, um etwas entspannter an komplexe Aufgaben heranzugehen.
Die Möglichkeit, eigene LabVIEW-Hardware für ein Serienprodukt zu entwickeln, ist der Traum vieler Entwickler und Entscheidungsträger. Mit Schmid Elektroniks Entwicklungs-, Produktions- und Testdienstleistungen wird dieser Traum Wirklichkeit. Vom individuellen Baseboard mit anwendungsspezifischer, industrieller Elektronik über Kompletthardware bis zum eigenen cRIO-Modul. Softwareseitig gehören Anpassungen des Linux-Kernels ebenso dazu, wie das Entwickeln individueller Gerätetreiber mit C/C++ in Eclipse und deren Einbinden in die LabVIEW-Umgebung. Schmid gehört von den über 900 weltweiten National Instruments (NI) Allianzpartnern zu den 13 ausgesuchten «Electronic-Design-Specialties» mit Fokus auf kundenspezifischer Embedded-Hardware. Seit über 10 Jahren arbeitet Schmid Elektronik mit NI R&D im amerikanischen Austin zusammen und entwickelte über die Jahre ein zum NI-Produktkatalog komplementäres Produktportfolio, um LabVIEW für Serienprodukte nutzen zu können. Der Entwickler erhält auf diese Weise eigene Hardware mit einem Programmierkomfort, den er von NI-Produkten gewohnt ist und kann sich damit voll und ganz auf seine Hauptaufgabe konzentrieren.
Im zweiten Teil des Berichts geht es um den Einsatz in der Praxis anhand reeller Projektbeispiele:
Der Einsatz in sensiblen Bereichen wie Luftfahrt, Verteidigung, Automotive und Bahntechnik wird ebenfalls kurz angesprochen.
Schmid Elektronik AG
Mezikonerstrasse 13, 9542 Münchwilen
Tel. 071 969 35 80, Fax 071 969 35 99
info@schmid-elektronik.ch
www.schmid-elektronik.ch
Bild 1: Skalierbare LabVIEW-Einsteckmodule, von der Briefmarke bis zur Scheckkarte (links) und Singleboard-Computer im PC-104 und Hutschienenformat (rechts)
Bild 2: Grafisch programmierbare Kompletthardware mit Mikrocontroller und I/Os für spezifische Formfaktoren und sensible Preisvorgaben in der Serie
Bild 3: Eine Kombination von drei unterschiedlichen Rechenmodellen mit Regeltechnik (Matlab-Notation, oben) und Simulation (mitte), eingebettet im Datenflussmodell LabVIEW für einen PID-Regler
Bild 4: Das zustandsorientierte Rechenmodell mit hierarchischem Statechart (links), seinem Aufruf in LabVIEW (rechts oben) und dem Zustand «Datenerfassung» (rechts unten)
Bild 5: Das Taskmodell abstrahiert diskrete, parallele Zeitdarstellung und unterstützt synchrone und asynchrone Prozesse. Task 1 (grün, 500-ms-Takt) und Task 2 (rot, 50-ms-Takt) arbeiten kooperativ auf dem ersten Rechenkern, Task 3 (Blau, 50-ms-Takt) hingegen läuft präemptiv auf dem zweiten Rechenkern
Sektion 16: Electronic Manufacturing
Sektion 19: Embedded Computing