Endlich – das neue Projekt soll demnächst starten. Die Hardware ist soweit fertig, wenn auch erst mal nur auf dem Papier. Naja, dafür gibt’s ja die Referenzboards. Es kann also gleich mit der Entwicklung auf der Zielplattform losgehen. Soweit – so gut.
Die Realität sieht meist anders aus: Entwicklerboards sind möglicherweise nicht lieferbar oder nicht in ausreichender Menge verfügbar. Schlussendlich heißt das, das Team kann sich die erste Zeit um die wenigen Exemplare kloppen. Aber was können die Software-Entwickler tun, damit sie trotz wideriger Umstände loslegen können? Die Lösung lautet: Simulieren. (nicht zu verwechseln mit „Blau machen“). Aber selbst wenn die Hardwareverfügbarkeit kein Problem darstellt, gibt es noch viele weitere Gründe, die für eine Simulation sprechen.
Warum Simulieren?
Zu den schon erwähnten Gründen gibt es noch eine ganze Reihe weiterer Vorteile:
- Bei häufigen Wechseln zwischen Arbeiten im Büro und Heimarbeit möchte man nicht jedes Mal das ganze Equipment mit umziehen. Irgendwas vergisst man ja immer.
- Eine Hardwareabstraktion ist prinzipiell erstrebenswert, denn sie erleichtert die Portierung auf Hardwarevarianten oder komplett neue Hardware-OS-Kombinationen. Wechselt man später die Hardware, kann es sein, dass man auf ein anderes Betriebssystem oder SDK umsteigen muss. Mit einem Osal bleibem die Änderungen überschaubar.
- In vielen meiner bisherigen Projekte hatten die Geräte z.B. eine oder mehrere CAN-Verbindungen zu den Controllern des Gesamtsystems. Baut man an der „richtigen“ Stelle eine Weiche ein, kann man die Applikation z.B. mittels USB2CAN-Interface (mit den SDKs von z.B. IXXAT oder Vector ist das relativ schnell erledigt) am PC testen. Kunden konnten auf diese Art mit dem Laptop in der „echten“ Umgebung erste Tests durchführen – lange bevor die erste Hardware überhaupt verfügbar war.
Es gab auch Fälle, wo wir Fehlern in der Controller-Software mit dem Debugger sehr schnell auf die Schliche gekommen sind. Mit der Applikation auf dem Target wäre das ein schwierigeres Unterfangen. - Wie woanders auch, ist Diversität ein Gewinn für alle. In diesem speziellen Fall meine ich, dass unterschiedliche Compiler zum Einsatz kommen können (Zielplattform: gcc, clang – Entwicklerplattform: z.B. VisualStudio). Compiler sind wie wir auch: Mimosen – und jeder meckert über ‚was anderes. In diesem Fall bringen also unterschiedliche Compiler einen Zugewinn an Sicherheit – natürlich vorausgesetzt, alle Compiler-Warnungen sind eingeschaltet (alles andere ist eh ein no-go!).
- In jedem Fall ist allein schon das um ein Vielfaches einfachere Debugging eine Simulation Wert. Anstatt der üblichen Turn-around-Zyklen (Compile/Link – Download – Debugging starten; manchmal auch über den Zwischenschritt einer SD-Karte/USB-Stick – besonders schön!) genügt ein F5 und los geht’s (ok – ich habe mich als VS-User geoutet).
- Obendrein kann man noch von zusätzlichen Sicherheitsnetzen der Laufzeit-Umgebung profitieren. So lassen sich z.B. bei VS oder Clang Checks für Buffer-Overruns, Memory-Leaks, Uninitialized-Memory-Access, Stack-Overflows etc. einschalten. Das erspart den Einsatz von extra Tools oder zeitaufwändige Fehlersuche/Debuggen auf dem Target. Denn spätestens wenn so ein Fehler im Feld auftritt, kann’s verdammt teuer oder sogar gefährlich werden!
Wie?
Zunächst trennt man die Applikation in einen Hardware-bzw. OS-unabhängigen Teil und erstellt eine OSAL-Schicht (OSAL=Operating System Abstraction Layer). Natürlich könnte man den Applikationscode auch mit #ifdefs versehen, um den Target-spezifischen Code nur im Target-Build einzuschalten. Viele von uns hatten mit solchem Code bestimmt schon mal zu tun. Schön ist das nicht wirklich. Und das ist nicht der einzige Nachteil. Es leiden Lesbarkeit, Wartbarkeit, Testbarkeit, Portierung auf andere Hardware/OS/… .
Das hat wohl jeder so oder noch schlimmer mal gesehen
Für das Betriebssystem, auf dem die Entwickler arbeiten (meist Windows, Linux nicht ganz so häufig) implementiert man eine Version das OSAL. Natürlich werden OSAL und Applikation für die Entwicklungsumgebung ein etwas anderes Laufzeitverhalten haben als das der Zielplattform. Das ist zunächst aber nicht so wichtig. Hauptsache, die Applikationsentwicklung wird nicht unnötig blockiert.
In Fällen, wo die Applikation zum Beispiel auf Flash– oder EEPROM-Speicher zugreifen muss, kann man diese meist recht einfach z.B. über Dateizugriffe simulieren. Damit eröffnen sich obendrein noch zusätzliche Möglichkeiten, Hardwarefehler (wie z.B. Lesefehler) automatisiert zu testen.
Etwas schwieriger kann die Simulation in Fällen von z.B. seriell angebundener Hardware sein. Aber auch hier kann man sich behelfen. Die Daten vom externen Gerät kann man Aufzeichnen und in die Simulation (per Datei oder Pipe) einspielen.
Letztendlich ist es nur eine Frage, auf welcher Ebene man die Weiche einbaut und mit welchem Mechanismus man die Funktionalität abbildet.
Ein ganz anderer Ansatz könnte auch sein, von Vornherein auf abstraktere Schnittstellen zu setzen, wie z.B. Kommunikation über Sockets. Damit wäre sogar die Kommunikation über Rechnergrenzen zu bewerkstelligen.
Wie so oft sind der Kreativität – mit Maß und Ziel – keine Grenzen gesetzt. In jedem Fall ist es lohnenswert, sich zu Projektbeginn mit diesem Aspekt zu befassen.
Zögern Sie nicht, mit Anmerkungen, Anregungen oder Fragen auf uns zuzugehen – sei es über die Kommentarfunktion oder direkt via E-Mail (info@medtech-ingenieur.de) oder Telefon (09131/691240). Und wenn Sie auf der Suche nach einem Job als Software-Entwickler sind, dann freuen wir uns über Verstärkung!
