Computer ermöglichen die Trennung von Soft- und Hardware, mehr noch, sie basieren geradezu auf dieser Möglichkeit. Diese leistet auch bei der Soft- und Hardwareentwicklung gute Dienste. Dieser Beitrag hat seinen Fokus im embedded Bereich. Zur Vereinfachung werden drei „Spieler“ betrachtet:
- die Umwelt
- die Hardware, auf welcher die Software ausgeführt wird
- die Software selbst
Jeder dieser drei Spieler lässt sich virtualisieren. Und genau diese Möglichkeit kann die Entwicklungsarbeit immens vereinfachen. Dazu ein paar Beispiele:
Es wird der numerische Kern eines Vermessungsgerätes geschrieben. Dieser berechnet aus Sensordaten wie den Winkelgebern des Messkopfes und Laserdaten Punktpositionen. Zum Test dieser Software werden beim Integrationstest Umwelt und Messgerät virtualisiert. Aus Punktpositionen der virtuellen Umwelt werden die Sensorwerte des virtuellen Gerätes berechnet und dem Kern übergeben. Er berechnet die Punktpositionen und diese werden mit den ursprünglichen Punktpositionen verglichen. Auf diese Weise lassen sich selbst Extremwerte mit z.B. absoluten Sensorwerten gleich Null testen, welche real so genau gar nicht anfahrbar wären. Später bei der Hardwareumsetzung können immer wieder reale Sensorwerte der Hardware mit dem Simulator verglichen und so Fehler schneller gefunden werden. Zuletzt unterstützt die Simulation die Fehlersuche nach dem roll out bei Problemen beim Kunden, die gleiche Software läuft im Simulator wie auch auf dem Gerät.
Es wird eine embedded Videostreaming Lösung für ein kamerabasiertes Vermessungsgerät entwickelt. Dazu werden Testaufnahmen relevanter Einsatzszenarien im Rohdatenformat mit Zeitstempeln gemacht. Diese werden anschließend in alle möglichen Ausgabeformate des Bildsensors umgerechnet und dem SoC anhand der Zeitstempel wie vom Bildsensor kommend übergeben. Auf diese Weise kann nun die optimale Entwicklung der Streamingsoftware „im Labor“ erfolgen, mit direktem Vergleich der Ergebnisse bezüglich Qualität des Ausgabestroms, Leistungsaufnahme des SoCs, Bandbreite etc. Verschiedene Elemente wie Codecs können automatisiert durchgetestet werden.
Es wird die automatische Anfahrt von Messpunkten durch einen Messkopf entwickelt. Zur Vereinfachung der Entwicklung werden die Sensorwerte des Messkopfes per Netzwerk an einen Entwicklungsrechner übertragen, auf welchem die Software entwickelt wird. Diese steuert per Netzwerk wieder die Schrittmotoren des Messkopfes an. Schrittweise wird dann die Software vom Entwicklungsrechner in den Messkopf übertragen und läuft auf diesem direkt.
Die Arbeit mit einer virtuellen Umgebung hat verschiedene Vorteile. Die Umgebungsbedingungen können beliebig oft exakt gleich nachgestellt und vervielfältigt werden. Es können jederzeit bestimmte Umgebungsbedingungen geschaffen werden. Die Zeit kann „eingefroren“, zeitkritische Algorithmen auf diese Weise debuggt werden.
Bei diesen Methodiken sind bestimmte Dinge selbstverständlich. Möchte man z.B. die Hardware austauschen, so werden die Sensoren nicht direkt an einem Board verlöten, sondern stattdessen Steckverbinder benutzen, um so schnell wechseln oder ein Messgerät zwischenschalten zu können. Bei prototypischen Boards sieht man bewusst Abgreifpunkte vor, die allein dem Anschluss von Messgeräten dienen, um Signale abzugreifen und damit kontrollieren zu können. Genau diese Vorgehensweise sollte auch bei der Software angewendet werden. Darauf wird später in einem weiteren Beitrag eingegangen. Auf diese Weise kann diese unverändert virtuell oder auf der realen Hardware ablaufen.
Bei der Entwicklung von Software haben sich bestimmte Arbeitsweisen etabliert. Bei einer virtuellen Umgebung sind dies:
| Model in the Loop | MIL | Umwelt und Steuergerät sind simuliert, die Algorithmen bzw. Regelkreise der späteren Software werden zunächst mithilfe spezieller Software simuliert |
| Software in the Loop | SIL | Umwelt und Steuergerät sind simuliert, die Software, bereits als source code vorliegend, läuft kompiliert in einer virtuellen Umgebung |
| Processor in the Loop | PIL | Die Umwelt ist simuliert, die Software läuft cross kompiliert auf dem „echten“ Zielprozessor |
| Hardware in the Loop | HIL | Die Umwelt ist simuliert, das Steuergerät und die Software sind „echt“ |
Diese Arbeitsweisen werden in der Industrie von etablierter Software unterstützt, wie etwa MATLAB und Simulink, oder den Alternativen Scilab und Xcos aus dem open source Lager.