Simulation? Wozu, hab doch ‘ne Hardware

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/… .

if-def-Hell

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!

Kontaktieren Sie uns!

Autor

  • Jürgen Welzenbach

    Seit Juli 2021 bin ich Teil des MEDtech Ingenieur-Teams – also ganz frisch aber (derzeit noch?) ältester Mitarbeiter. Ein Physiologieseminar gegen Ende des Elektrotechnik-Studiums in Erlangen weckte bei mir das Interesse an der Medizintechnik. Infolgedessen habe ich die Studien- und Diplomarbeit in Kooperation mit einer Firma (Hersteller von Geräten für die Ophthalmologie) bzw. der Universitätsaugenklinik durchgeführt, wo ich später auch ein paar Jahre eine Analyse-Software entwickelte. Zur Embedded-Software-Entwicklung kam ich schließlich bei zwei weiteren Erlanger Unternehmen (ab 1999). Bei letzterem war ich lange Jahre für die Entwicklung von HMIs für z.B. Baumaschinen und Laboranalysegeräte zuständig.

Wie hilfreich war dieser Beitrag?

Durch das Anklicken der Sterne wird ein Cookie in diesem Browser gespeichert, um das mehrfache Abgeben von Bewertungen zu verhindern. Durch das Anklicken der Sterne erlauben Sie medtech-ingenieur.de das Cookie zu speichern.

Es gibt bereits 1 Bewertung(en) mit einer Durschnittsbewertung von 5.

Bisher keine Bewertungen! Seien Sie der Erste, der diesen Beitrag bewertet.

Es tut uns leid, dass der Beitrag für Sie nicht hilfreich war!

Helfen Sie uns, diesen Beitrag zu verbessern!

Wie können wir diesen Beitrag verbessern?

Auch interessant:

Systemarchitektur und Risikomanagement – zwei wie Pech und Schwefel

Wer Medizinprodukte entwickelt, hat zwangsweise auch mit Risikomanagement zu tun. Sehr viele Unternehmen tun sich jedoch schwer mit dem Thema Risikomanagement. Und auch Systemarchitektur steckt bei vielen Unternehmen noch in den Kinderschuhen. Doch gerade diese beiden Disziplinen sind füreinander essenziell und mit der richtigen Methodik können sich Systemarchitektur und Risikomanagement…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.