Graphical System Design im Embedded-Bereich: Plattformübergreifend entwickeln − vom PXI über Singleboard Computer und FPGA zum Mikrocontroller

Gallery

Bild 1: Embedded-Systeme sind äußerst restriktiv in Bezug auf Skalierbarkeit, Verfügbarkeit, Deterministik, Stromverbrauch, Zuverlässigkeit und Wirtschaftlichkeit in der Herstellung.

Author(s):
Marco Schmid - Schmid Engineering AG
Stephan Ahrends - National Instruments germany GmbH

Eingesetzte Produkte: Grafische Entwicklungsumgebung NI LabVIEW, Embedded-Hardwareplattformen NI PXI, NI CompactRIO, NI Single-Board RIO, FPGA-Technologie von NI

Alle eingesetzten Produkte und Spezifikationen finden Sie weiter unten im Referenzsystem.

Die Welt der Embedded-Systeme ist "anders"

Embedded-Systeme unterscheiden sich fundamental von PC-Applikationen, denn sie sind äusserst restriktiv in Bezug auf Verfügbarkeit, Zuverlässigkeit, Deterministik, Stromverbrauch und Wirtschaftlichkeit in der Herstellung (Bild 1). Dabei ist der Formfaktor der Hard- und Softwarekombination nicht ausschlaggebend, sondern es ist die Autonomie, welche ein Embedded-System einzigartig macht. Wird die Anwendung gestartet, ist die Software nach einem kurzen Bootprozess sofort verfügbar und funktioniert unter allen Umständen fehlerfrei und deterministisch. 

Weil ein Embedded-System autark funktionieren muss, kommt selbstständiger Fehlererkennung und -behebung eine zentrale Bedeutung zu. Schlanke Echtzeitbetriebssysteme (RTOS) sorgen für sofortige Reaktion auf Ereignisse, minimalen Stromverbrauch, skalierbare CPU-Leistung und vor allem speicherschonenden Betrieb. Wie positioniert sich LabVIEW, üblicherweise als Sprache für Test und Automatisierungstechnik wahrgenommen, in diesem Gebiet ?

Bild 1: Embedded-Systeme sind äußerst restriktiv in Bezug auf Skalierbarkeit, Verfügbarkeit, Deterministik, Stromverbrauch, Zuverlässigkeit und Wirtschaftlichkeit in der Herstellung.

Warum grafische Embedded-Systemprogrammierung?

Drei Argumente regen bei dieser Frage zum ernsthaften Nachdenken an. Der Wunsch nach mehr Funktionalität und Komfort nimmt auch bei Embedded-Systemen generell zu. Damit steigt exponentiell mit den Anforderungen die technische Komplexität der Software. Die für die Entwicklung dringend benötigten Ressourcen wie Geld oder Personal sind meist begrenzt, der Match-entscheidende Trumpf im Entwicklungsgeschäft ist aber der Zeitgewinn. Damit punkten domänenspezifische Viertgenerationsprachen wie LabVIEW, da sich mit ihnen im Vergleich zu traditionellen Ansätzen sogar komplexe Probleme im Bruchteil der üblichen Zeit lösen lassen. 

Deshalb dringen sie vom klassischen PC-Bereich zunehmend in die Welt der Embedded-Systeme. Erfolgreiche Unternehmen haben diesen Trend erkannt und nutzen die Schlagkraft dieser modernen Entwicklungsmethode, um ihren Kunden gezielt und vor allem schneller einen Mehrwert bieten zu können.

Warum „LabVIEW Embedded"?

Jeder hat seine Gründe, warum er sich seinerzeit für oder gegen LabVIEW entschieden hat. Folgende Eigenschaften prädestinieren LabVIEW, objektiv betrachtet, zum Einsatz in Embedded-Systemen, die bislang vom Platzhirsch „C/C++" dominiert worden sind. 

An erster Stelle steht die enorme Produktivität, mit der sich Ideen in Rekordzeit umsetzen lassen. Zweitens führt das Datenflussparadigma zu paralleler Ausführung von Programmcode und damit zu Multitasking. Drittens ist LabVIEW eine vollumfängliche Programmiersprache mit einem erstaunlichen Funktionsumfang vom elementaren logischen Inverter bis zum integrierten Errorhandling und konfigurierbaren Task. Viertens ermöglicht die durchgängige Entwicklungsumgebung das Arbeiten im Team, Debuggen, Monitoring und Deployen. Fünftens steht eine breite Palette fertiger IP in Form von Bibliotheken zur Lösung verschiedener Signalverarbeitungsprobleme zur Verfügung. Sechstens lassen sich „trockene" Algorithmen schnell per Drag & Drop mit Live-I/O verknüpfen. Und siebtens ist LabVIEW ein Crosscompiler, der verschiedene Programmiermodelle unterstützt und diesen Sprachmix auf verschiedene Hardware verteilen kann.

Folgende drei in traditionellen Embedded-Systemen üblichen Softwaretechniken sind bei LabVIEW direkt von unterlegter Embedded-Hardware abhängig: modulare und skalierbare Architekturen, effizienter Umgang mit CPU- und Speicherressourcen und unmittelbare Reaktionen auf Ereignisse. Die Wahl der Hardware ist also ein wichtiger Meilenstein, denn die damit verbundene Leistungsreserve hat einen direkten Einfluss, ob sich die Projektanforderungen wie gewünscht umsetzen lassen, ohne diese Entscheidung später revidieren zu müssen. 

Die folgenden fünf Abschnitte sollen dem Anwendungsentwickler ein Gefühl geben, was ihn auf den drei NI-Plattformen PXI, CompactRIO/Single-Board RIO und FPGA, den zwei Drittanbieter-Mikrocontroller-Targets ARM und Blackfin erwartet, damit er die passende Plattform nach bestem Wissen und Gewissen auswählen kann.

Bild 2: Bei standardisierten National-Instruments-Plattformen wie PXI (links), CompactRIO (Mitte) oder Single-Board RIO (Rechts) ist der Komfort hoch, der Code einfach portierbar und die Hardware bietet Leistungsreserven.

Der PXI als Industrierechner der oberen Leistungsklasse

Data-, Sound- und Videostreaming, kontinuierliche High-Speed-Datenerfassung und -verarbeitung im MHz-Bereich, das Einbinden mehrerer tausend Messkanäle, komplexe Kommunikationsanwendungen und komfortable grafische Bedienoberflächen (GUI) passen in die Welt der High-End-PXI-Mess- und -Regelsysteme (Bild 2, links). 

Für den Anwendungsprogrammierer interessant ist die nahezu beliebige Skalierung von Rechenleistung und Prozess-I/O. Angefangen beim Stand-Alone-Embedded-Controller mit robustem Echtzeitbetriebssystem über den Hybrid „Windows + LabVIEW Real-Time" bis zur Möglichkeit, einen FPGA für sehr hartes Timing einzubinden passt sich das System nahtlos an die Projektanforderungen an. Zusammen mit flexibler Stromversorgung von 10-30 VDC bis 230 VAC, einem für industrielle Umgebungen konzipierten Lüftersystem und zertifizierten Grund- und Funktionsmodulen lässt diese „Spielwiese" bezüglich Funktionalität, Leistung und Qualität wenige Wünsche offen. 

Der Preis ist ein für den Embedded-Bereich physikalisch grosser Formfaktor, Bootzeiten zwischen 30 s (Echtzeitbetrieb) und 90 s (Windows-Betrieb) und eine mit 40 W bis 500 W relativ hohe Verlustleistung. Im Hybridmodus kombiniert das PXI die Vorteile des Windows-Standards mit den Vorteilen eines robusten Echtzeitbetriebssystems. Ersteres bietet Möglichkeiten wie komfortable GUIs, Datenbankanbindungen oder Zugriff auf die Cloud. Letzteres erlaubt robusten 24/7-Dauerbetrieb sowie harte (LabVIEW Real-Time) als auch sehr harte Echtzeit (FPGA). Die zwei unterschiedlichen „Welten" werden auf einer Multicore-CPU in je einem Core abgearbeitet, unterstützt durch einen Hypervisor-Midlayer. Der Datenaustausch zwischen Windows und Realtime erfolgt in gewohnter Weise über Shared-Memory oder TCP/IP. Ein für Datastreaming oder -recording zentraler Punkt ist die Option, Solid-State-Disks im oberen Gigabyte- oder Festplatten im Terrabyte-Bereich anzubinden.

Die modularen Messrechner NI CompactRIO und NI Single-Board RIO

Kompakte Stand-Alone-Systeme für Datenerfassung, Steuerung und Regelung mit hohen Ansprüchen an zuverlässigen Dauerbetrieb und einem breiten Spektrum an Prozesssignalen lassen sich am besten mit den Plattformen CompactRIO (Bild 2, Mitte) und Single-Board RIO (Bild 2, rechts) realisieren. 

Das CompactRIO steht für ein robustes Gehäuse mit Echtzeitcontroller, FPGA-Backplane für rekonfigurierbaren I/O und für verschiedene Hotplug-I/O-Module. Das Single-Board RIO ist die Singleboard-Variante derselben Hard- und Softwarearchitektur und konzipiert für den Serieneinsatz. Die im Vergleich zum PXI deutlich niedrigere Verlustleistung zwischen 10-20 W, eine 10-30 V DC-Speisung, der kompakte Formfaktor und zahlreiche industrietaugliche I/O-Module prädestinieren die Plattform für den typischen harten SPS-ähnlichen Industrieeinsatz.

Das Deployment funktioniert auf Knopfdruck innerhalb weniger Sekunden. Die Verfügbarkeit des Real-Time-Codes (Booten) in einer Grössenordnung von 20 s und ein Software-Timing auf dem Echtzeit-Controller im Millisekundenbereich sind für viele industrielle Anwendungen ausreichend. Hardwareseitig kombinieren die Plattformen einen schnellen (typischerweise bis zu 800 MHz getakteten) Embedded-Floating-Point-Applikationsprozessor mit einem parallel arbeitetenden FPGA. Dieser ist der "Backbone" der CompactRIO- und Single-Board-RIO-Plattformen. Er verarbeitet I/O und logische Operationen parallel und deterministisch im Nanosekundenbereich und ermöglicht damit parallele I/O-Verarbeitung und äusserst schwierige Timings auch unter harten Echtzeitbedingungen. Damit lässt sich Jitter, welcher aufgrund der Architektur des Echtzeitbetriebssystems üblicherweise vorhanden und abhängig von parallelen Threads ist, kompensieren.

Grafische Programmierung von FPGAs

Ein FPGA ist eine im Kern Software-rekonfigurierbare, parallel arbeitende Hardware. An ihn werden zeitkritische Aufgaben und I/O delegiert, um die CPU des Hauptcontrollers zu entlasten. Dabei gibt es zwei entscheidende Eckdaten: die realisierbare Funktionalität und deren Timing. Bislang war FPGA-Programmierung Spezialisten vorbehalten. 

Dank LabVIEW erhalten nun Ingenieure aus allen Sparten Zugang zur mächtigen Technologie rekonfigurierbarer Logik. Genauer betrachtet, kommt die echte Parallelität dem LabVIEW-Datenflussparadigma tatsächlich am nächsten. Über intuitive Funktionsblöcke lässt sich ein breites Spektrum analoger, digitaler und serieller Prozesssignale einbinden, verknüpfen und parallel vorverarbeiten, bevor sie in die CPU weitergeleitet werden. Die Funktionalität der abzubildenden Anwendung auf einem FPGA ist direkt begrenzt durch die zur Verfügung stehenden Gatter. Bekannte Kennwerte, welche Operation (Addition, Filter, FFT) wieviele Gatter benötigt, liefern deshalb wertvolle Entscheidungsgrundlagen bei der Auswahl der FPGA-Leistungsklasse. Beim Timing "denkt" der Anwendungsprogrammierer in "Ticks", dem kleinsten Zeitinkrement in der Grössenordnung von Nanosekunden auf dem FPGA. 

Dabei ist definiert, wieviel Zeit von bestimmten logischen und mathematischen Operationen und I/O-Zugriffen benötigt wird. Dies gibt Richtwerte für das System-Timing. Beim Softwaredesign gilt es, die Embedded Anwendung sorgfältig auf CPU und FPGA aufzuteilen. Der Hauptcontroller ist verantwortlich für die High-Level-Hauptfunktionen. Low-Level Details wie zeitkritischer Code, digitale Filter, kombinatorische und sequentielle Logik, Skalierungen, Fixed-Point- und Integer-Arithmetik werden auf den FPGA ausgelagert. Das LabVIEW-FPGA-Diagramm wird schlussendlich in VHDL-Code synthetisiert, mit den FPGA-Tools in eine Firmware kompiliert und in den FPGA geladen. 

Der gesamte Workflow wird dank den LabVIEW-Tools komplett abstrahiert und erfolgt auf Knopfdruck. Der „Build" mit Synthetisieren, Kompilieren und Flashen kann je nach Komplexität der FPGA-Anwendung mehrere Stunden dauern, was beim FPGA- und Hardwaredesign jedoch üblich ist. In diesem Moment wird Hardware produziert, weshalb dieser Vorgang direkt mit ähnlich zeitintensiven Routing-/Autorouting-Prozessen vergleichbar ist. Im kreativen und hektischen Rapid Prototyping wären solche Totzeiten natürlich „No-Gos". In diesen Phasen wird deshalb die Möglichkeit genutzt, über Funktionsblöcke direkt auf den I/O zuzugreifen. So lassen sich neue Funktionen nach dem Anschliessen der I/O-Module sofort in die Applikation integrieren und testen.

LabVIEW für ARM-Mikrocontroller

Verlangt die Anwendung nach kundenspezifischen und kleinsten Formfaktoren im Briefmarken- und Scheckkartenformat, Stromsparbetrieb bis Milliwatt und Boardpreisen im zweistelligen Eurobereich, bewegen wir uns in die Richtung von „Deeply-Embedded-Hardware" (Bild 3). Hier beginnt die Welt der Mikrocontroller mit ARM-Cortex-M3 und Mixed-Signal-Schaltungen, auf einer individuellen Hardwareplattform wirtschaftlich kombiniert. 

Die Programmierung solcher Architekturen war bislang Spezialisten mit Erfahrung im Umgang mit Interrupts, CPU-Register und der weitverbreiteten, textbasierten Sprache C und C++ vorbehalten. Das "LabVIEW Embedded Module for ARM" schliesst nun die Brücke zwischen den zwei unterschiedlichen Welten mit einem unterlegten Autocode-Generator, welcher das LabVIEW-Blockschaltbild in C-Code übersetzt. 

Die in der Embedded-Industrie etablierte KEIL-Toolchain mit integriertem Compiler und Linker kombiniert diesen C-Code mit der Source des standardisierten RTX-Realtime-Kernels und erzeugt daraus eine Anwendungsfirmware. Diese wird über einen Standard-JTAG-Link ins On-Chip-Flash geladen und lässt sich dort mit den üblichen LabVIEW-Instrumenten debuggen. Hier erfährt der LabVIEW-User im Vergleich zum LabVIEW-Real-Time-Standard einen ersten deutlichen Unterschied im Komfort. Jede Änderung im grafischen Code muss von den Tools  erneut in ein Executable übersetzt, ins Zielsystem geladen und dort gestartet werden. Dieser Deployment-Vorgang ist also nicht wie bei LabVIEW Real-Time in wenigen Sekunden erledigt, sondern kann je nach Anwendungskomplexität zwischen 20 Sekunden und ein paar Minuten dauern. 

Des Weiteren stehen den Vorteilen kurzer Bootzeiten in Sekunden und niedrigem Stromverbrauch bis Milliwatt die Nachteile limitierter CPU-Leistung von 50-70 MHz und reduziertem Speicher (64 kByte RAM, 256 kByte Flash) gegenüber. Auch wenn die Tools über Optimierungsschalter wie Codereduktion verfügen, so entsteht gegenüber manueller C-Programmierung wegen der hohen Abstraktion doch ein deutlicher Overhead in Speicherbedarf und Ausführungszeit. Damit stehen der Anwendung die im Prozessordatenblatt spezifizierten Ressourcen nicht vollumfänglich zur Verfügung und eine (zu) frühzeitige Wahl dieser Hardwareplattform könnte deshalb bei der Anwendungsprogrammierung schmerzhafte Konsequenzen haben. 

Dies ist der Fall, wenn die gegebenen Projektanforderungen die Möglichkeiten der LabVIEW-ARM-Plattform so übersteigen, dass nicht einmal Optimierungsmassnahmen zum Ziel führen. Kann der Programmierer jedoch eine Embedded-Applikation dieser Art linear Schritt für Schritt auf hohem Level entwickeln, lückenlos debuggen und stösst nirgends an unüberwindbare Leistungsgrenzen, so ist er bereit, den Preis der langen Deployment-Zeit zu bezahlen.

LabVIEW mit C-Code-Generator auf Blackfin-Mikroprozessor

Sind die Projekt-Randbedingungen ähnlich wie beim ARM-Mikrocontroller, der Anspruch an Rechenleistung und Speicher aber höher, so bietet der Blackfin-Prozessor eine Kompromisslösung (Bild 3). Dank seiner 500-MHz-Fixed-Point-CPU, 64 MB RAM und 32 MB Flash lassen sich Mess- und Steueranwendungen erstaunlicher Komplexität mit nahezu beliebiger Anzahl an Prozess-I/O realisieren. 

Anstelle des LabVIEW-Frontpanels bieten sich als GUI verschiedene Color-TFT mit Touch bis 5.7" an. An die Stelle traditioneller File-Systeme treten mobile Speichermedien (SD-Card, MicroSD-Card) oder Solid-State-Disks (NAND-Flash). Interessant ist der skalierbare Stromverbrauch bis in den zweistelligen Milliwattbereich. Damit lassen sich beispielsweise Langzeit-Datalogger oder batteriebetriebene, LabVIEW-programmierbare Mess-Handhelds realisieren. Die Bootzeiten sind mit < 1 Sekunde enorm kurz und damit ideal für schnell verfügbare Systeme. 

Kontinuierliche Datenerfassung funktioniert im zweistelligen kHz-Bereich und die Grenzen für blockorientiertes, simultanes Erfassen mehrkanaliger ADC-Signale liegen zwischen dreistelligem kHz- und einstelligem MHz-Bereich. Letzteres funktioniert nur, wenn die Daten anschliessend „offline" verarbeitet werden können, was je nach der Komplexität der Algorithmen die geforderte Zykluszeit einer Regelung übersteigen kann. Genau hier zeigen sich erste signifikante Unterschiede zur viel leistungsfähigeren CompactRIO-/Single-Board-RIO-Hardware, deren Controller gegenüber einem Blackfin auch hohe Datenmengen in Echtzeit verarbeiten können. 

Das für den LabVIEW-Kenner aber einschneidendste Erlebnis ist das Verlassen der "Komfortzone", indem er parallel in zwei Toolchains arbeitet. Ähnlich wie bei der ARM-Plattform wird das LabVIEW-Diagramm in ein Executable übersetzt, diesmal aber über den plattformunabhängigen LabVIEW-ANSI-C-Code-Generator und den Blackfin-spezifischen Compiler und Linker. Jetzt wechselt der Programmierer in das Blackfin-Entwicklungswerkzeug, lädt das Executable und später die Firmware in das Zielsystem und debugged es dort. Dabei stehen ihm die üblichen Hilfsmittel zur Verfügung, jedoch nicht in der gewohnten LabVIEW-Abstraktion. Er arbeitet quasi direkt auf dem Silizium und debugged den generierten Code mit Low-Level-Instrumenten. 


Die meisten Entwickler machen aus dieser Not eine Tugend und integrieren das Debuggen im Zusammenhang mit Fehlererkennung und -korrektur für 24/7-Dauerbetrieb schon in frühen Projektphasen in die Anwendung. Des Weiteren bieten Drittanbieter interessante Rapid-Prototyping-Lösungen, womit sich ein Teil des LabVIEW-Komforts zurückgewinnen lässt. Dann lässt sich ein LabVIEW-Blockschaltbild auf dem PC erstellen, der Mikroprozessor-I/O über einen seriellen Link nahtlos einbinden und die komplette Applikationslogik bis auf die Echtzeitfähigkeit testen. Ähnlich wie beim grafisch programmierbaren ARM nimmt der Anwendungsentwickler die Komforteinbusse in Kauf, solange er die Applikation zügig entwickeln und auftretende Probleme nachvollziehbar lösen kann.

Wie wähle ich Embedded-Hardware aus?

Mit den Projektanforderungen und dem Wissen über die Möglichkeiten und Grenzen der verschiedenen Plattformen geht es jetzt zielorientiert an die Wahl der Embedded Hardware. Sie bestimmt direkt die Leistungsreserven, den Freiheitsgrad in der Anwendung möglicher Softwarearchitekturen und in welchem Mass Software optimiert und auf Portabilität getrimmt werden muss. Die häufige Folge einer Fehlentscheidung besteht darin, dass Software aufgrund zwingend notwendiger Portierung auf eine andere Hardware massiv umcodiert werden muss, sodass sich der Projektaufwand nicht mehr rechnet. 

Die grösste Konsequenz hat die Entscheidung „PXI, CompactRIO, Single-Board RIO, FPGA" oder „ARM-Mikrocontroller/Blackfin-Mikroprozessor", denn hier spaltet sich das LabVIEW-Paradigma. Bei vielen Embedded-Anwendungen kann diese Wahl dank bekannter Entscheidungsgrundlagen und anhand der Killerkritieren sofort und eindeutig getroffen werden. Sind die Projektanforderungen inklusive Formfaktor, Leistungsaufnahme, Timing und Systemkosten mit PXI, CompactRIO oder Single-Board RIO realisierbar, sind diese Plattformen die richtige Wahl. Der Entwickler geniesst dann den Komfort einer durchgängigen Toolchain, die nahtlos auf die unterlegte Hardware abgestimmt ist. Zudem lässt sich die Entscheidung zur definitven Zielhardware in der Regel fast beliebig hinausschieben, ohne dass dies signifikante Auswirkungen auf die Embedded-Software hat. 

Dann gibt es „Grauzonen", bei denen vorerst vieles für den Einsatz individueller Mikrocontrollerhardware spricht, aber ein Off-The-Shelf Single-Board RIO unter Kompromissen ebenfalls eingesetzt werden könnte. In diesen Fällen ist das Single-Board RIO, objektiv betrachtet, vorzuziehen, weil die Embedded-Programmierung noch immer dem durchgängigen LabVIEW-Paradigma entspricht und beim Mikrocontroller diesbezüglich Abstriche gemacht werden müssten. Schliessen die Projektanforderungen an Formfaktor, Bootzeiten, Stromverbrauch oder Preis den Einsatz von PXI, CompactRIO und Single-Board RIO deutlich aus, stehen zurzeit mit dem Blackfin-Mikroprozessor und ARM-Cortex-M3-Mikrocontroller zwei Hardwarearchitekturen zur Verfügung. In beiden Fällen ist mit Einschränkungen zu rechnen, weshalb den Kriterien Portierbarkeit, Speicherbedarf und Ausführungsgeschwindigkeit die volle Aufmerksamkeit gilt.

Wie wird Software portierbar?

Je nach den gegebenen Projektanforderungen und der Wahl der Hardwareplattform kann sich der Anwendungsentwickler Freiheitsgrade schaffen, um die Embedded-LabVIEW-Software notfalls plattformübergreifend einsetzen zu können. Beschränkt sich die Auswahl entweder auf die PXI/CompactRIO/Single-Board RIO-Plattformen oder Mikrocontroller-Targets, dann gilt es, diese drei Richtlinien zu beachten:

• Anstelle von LabVIEW-OOP wird die Anwendung mittels "Funktionalen Globalen Variablen" hierarchisch in einzelne, überblickbare Funktionseinheiten, respektive Objekte heruntergebrochen.
  
  
• Über den limitierten Speicher verantwortungsvoll verfügen und den LabVIEW-Speichermanager weitgehend entlasten. Das bedeutet, bei Strings, Cluster und Arrays die Regeln für ressourcenschonendes Programmieren beachten.
  
  
• Der schwächeren CPU-Leistung Rechnung tragen und Integer- oder Fixed-Point-Arithmetik der Floating-Point-Alternative vorziehen. Mindestens anstelle des Double-Precision-Datentyps die Single-Precision-Variante einsetzen und auf CPU-belastende Operationen wie Floating-Point-Divisionen grundsätzlich verzichten, beziehungsweise entsprechende Optimierungen vornehmen.
  
  
  
  Werden zusätzlich diese vier Regeln konsequent eingehalten, lässt sich eine überblickbare Anwendung mit minimalen Anpassungen zwischen allen Plattformen portieren:

• Eine gute Portierbarkeit wird erreicht, wenn auf Spezial-VIs wie Eventstruktur, Express-VIs und den Timed-Loop grundsätzlich verzichtet wird und nur die Kernfunktionen von LabVIEW verwendet werden. Für maximale Portierbarkeit dient die von LabVIEW am schwächsten unterstützte Plattform Blackfin (ANSI-C-Code-Generator) als Basis für die im Diagramm erlaubten VIs.
  
  
• Nur Signalverarbeitungs- und Mathematik-Libraries einsetzen, die auch von allen zur Auswahl stehenden Plattformen unterstützt werden. Damit fällt z. B. die weitverbreitete Sound-&-Vibration-Toolbox aus dem Rennen.
  
  
• Jeder Zugriff auf Hardware wird zusätzlich mit einem VI abstrahiert und über targetspezifische Definition ausgewählt (Bild 4). Dasselbe gilt für hardwarenahe VIs wie z. B. Blackfin-optimierte Filteralgorithmen, lokale Code-Optimierungen mittels Inline-C-Node oder Massnahmen für 24/7-Betrieb wie Watchdogs.
  
  
• Die Vielzahl an möglichen Softwarearchitekturen wird auf den Single-Loop mit einfacher Statemachine und das Producer-Consumer-Konzept beschränkt. Bei letzterem soll die speicherhungrige Queue durch eine selbst gestrickte Queue mit speicherschonenden Datentypen ausgetauscht werden.

Sobald die fehlende CPU-Leistung und der limitierte Speicher nach tiefgreifendem Code-Optimieren verlangen, kommt irgendwann der „Point-Of-No-Return" und ein Plattformwechsel ist unmöglich oder nur mit sehr viel Aufwand verbunden.

Das Optimum finden

Hat der Programmierer seine Hausaufgaben gemacht und sich weitgehend an die Richtlinien zur Portierbarkeit gehalten, so wird er, wenn die Embedded-Hard- und -Software auf dem Prüfstand steht, selten Überraschungen erleben. Liefert die Software die erwarteten Ergebnisse auch im Dauerbetrieb deterministisch, ist die Embedded-Anwendung auf der Zielgeraden. 

Andernfalls gilt es, Grenzen auszuloten und Codes zu optimieren, um einen Plattformwechsel zu vermeiden. Unabhängig von der gewählten Hardware sind diese Techniken ähnlich wie im traditionellen Ansatz und unterscheiden sich primär im Komfort. Das Ergebnis sind Kennzahlen über Ausführungszeit, Deterministik und Speichernutzung als Ausgangslage für gezieltes Optimieren. Als Erstes gibt der Profiler ein Gefühl für das Systemtiming, Parallelität und die Reserven. Er misst, welche 20 % des Codes 80 % der CPU- und Speicherressourcen fressen oder Memoryleaks verursachen. 

Der zeitkritische Code wird anschliessend einem Benchmarking unterzogen und gezielt solange optimiert, bis die Eckdaten stimmen. Statische Analysetools unterstützen diesen Prozess, indem sie in der Anwendung Schwachstellen wie dynamische Speicherallokation oder implizites Casten lokalisieren. Meistens führen solche Optimierungszyklen zu 5 bis 500 schnelleren Laufzeiten und die gewählte Hardware bleibt damit im Rennen. Andernfalls bleibt nichts anderes übrig, als die Hardware neu auszuwählen.

Fazit

Als Anwendungsentwickler frage ich mich zuerst, ob sich die Embedded-Systemaufgabe mit LabVIEW überhaupt lösen lässt. Dabei steht weniger die Funktionalität, sondern vielmehr Qualitätsmerkmale wie Formfaktor, Stromverbrauch, Bootzyklen, Deterministik, Dauerbetrieb, Zertifizierbarkeit und „Total Cost of Ownership" im Vordergrund. 

Dann geht es an die Wahl der von LabVIEW unterstützten Hardware, welche direkt den Komfort und Aufwand in der Softwareentwicklung beeinflusst. Solange ich mich auf einer standardisierten NI-Plattform wie PXI, CompactRIO oder Single-Board RIO bewege, ist der Komfort hoch, der Code einfach portierbar und die Hardware bietet Leistungsreserven. Wenn immer möglich entscheide ich mich also für eine dieser drei Plattformen. Fällt die Wahl aufgrund zwingender Vorgaben wie Formfaktor oder Stromverbrauch auf ein kundenspezifisches ARM-/Blackfin-Mikrocontroller-Target, müssen Portierbarkeit, Speicherbedarf und Ausführungsgeschwindigkeit genau evaluiert werden. 

Speziell die Grauzone macht die Unterscheidung zwischen den zwei Familien schwierig. Hier gilt es, die Killerkriterien zu hinterfragen, Spezifikationen notfalls zu ändern, Projekt- und Produktkosten neu zu kalkulieren, Abgabetermine nochmals zu prüfen und Lösungsalternativen mit Machbarkeitsstudien und Rapid Prototyping abzusichern. Sind diese Hausaufgaben gemacht und die Projektanforderungen optimal mit der Zielhardware kombiniert, lässt sich die Embedded-Anwendung mit überblickbaren Risiken zügig entwickeln und termingerecht abschliessen.

Author Information:
Marco Schmid
Schmid Engineering AG
Mezikonerstr.9
Muenchwilen 9542
Switzerland
Tel: +41 (0)71 9693590
Fax: +41 719693598
marco@schmid-engineering.ch