Was ist Hardware in the Loop Testing?
Hardware-in-the-Loop (HIL)-Testing wird, unter anderem in der Medizintechnik, dazu verwendet, die Interaktionen zwischen einem realen physikalischen (Sub-)System und einer simulierten Umgebung zu überprüfen. Diese Testmethode ist besonders häufig in der Entwicklung und Verifizierung von Embedded Software, aber auch anderweitiger Baugruppen, zum Beispiel rein elektronischer Komponenten, zu finden.
Der Prüfling wird in eine künstliche Umgebung eingebettet. Diese bildet, so akkurat wie nötig, das Verhalten der Schnittstellen zu der zu testenden Einheit nach, mit dem Ziel, entweder die „reale Welt“ oder etwa Grenzbereiche zu simulieren. Dabei kann diese virtuelle Umgebung, je nach Bedarf, reale Hardware (Aktoren und Sensoren) oder lediglich eine Software-Repräsentation dieser enthalten.
Mithilfe von automatisch ablaufenden Testskripten lassen sich sowohl die Eingaben und Parameter der simulierten Testumgebung beliebig variieren als auch Zustände bzw. Antworten des Systems unter Test prüfen. Entsprechende Testläufe können geplant ausgeführt oder aber manuell, ggf. auch durch z. B. die Bereitstellung eines neuen Softwarestandes, ausgelöst werden. Testergebnisse und Logs entstehen dabei ebenso, werden gesammelt und entsprechend an Entscheider verteilt.
Warum ist HIL-Testing relevant?
Alle automatischen Testverfahren (auch klassische Unittests) zeichnen sich durch eine hohe Reproduzierbarkeit aus. Im Bereich der Testausführung lässt sich der „menschliche Faktor“ weitestgehend ausschließen – somit haben unterschiedliche Tester, verschiedene Tagesformen und ähnliche Einflüsse keine Relevanz mehr.
Bei den Kosten kann die Methodik doppelt punkten. Lokale HIL-Test-Setups ersetzen teure und möglicherweise gefährliche physische Prototypen. Menschliche Tester werden für die Ausführung nicht benötigt. Zwar entsteht initial Aufwand für das Aufsetzen des Testprojektes und die Erstellung der Testfälle – dieser Punkt kann sich allerdings schon durch wenige Wiederholungen der Testläufe innerhalb eines Projektes recht schnell relativieren. Wenn man den exponentiellen Anstieg von Kosten in Bezug auf den Zeitpunkt des Findens von Fehlern zugrunde legt (NIST, „The Economic Impacts of Inadequate Infrastructure for Software Testing“, 05/2002) wird schnell klar, dass die Möglichkeit, Tests einfach und häufig ausführen zu können die gravierendsten Auswirkungen auf Kosten und Qualität haben dürften. In der Praxis bieten sich also regelmäßige HIL-Tests schon während der Entwicklung, parallel zu ggf. bereits vorhandenen Unittests, zum Beispiel in der Nacht, an, um Probleme frühzeitig aufdecken und korrigieren zu können.
Was ist regulatorisch beim HIL-Einsatz zu beachten?
Die Nutzung von HIL-Testing erscheint technisch also sehr vorteilhaft. Um das Verfahren für die Entwicklung von Medizinprodukten einsetzen zu können, ist die Qualifikation der gesamten Test-Umgebung notwendig.
In Kapitel 7.6 der deutschen Fassung der EN ISO 13485:2016 + AC:2018 + A11:2021 heißt es dazu: „Die Organisation muss Verfahren für die Validierung der Anwendung von Computersoftware dokumentieren, die für die Überwachung und Messung von Anforderungen eingesetzt wird. Derartige Softwareanwendungen müssen vor der ersten Verwendung validiert werden und, soweit angemessen, nach Änderungen an dieser Software oder deren Anwendung. Der spezifische Ansatz und Tätigkeiten im Zusammenhang mit der Softwarevalidierung und -revalidierung müssen dem mit der Anwendung der Software verbundenen Risiko entsprechen, einschließlich der Wirkung auf die Fähigkeit des Produkts, Spezifikationen zu erfüllen. Es müssen Aufzeichnungen der Ergebnisse und Schlussfolgerungen der Validierung und notwendige Maßnahmen aus der Validierung aufrechterhalten werden […].“
Ähnliche Anforderungen finden sich auch bei der FDA, u. a. in 21 CFR part 820.70 (i): „When computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol. All software changes shall be validated before approval and issuance. These validation activities and results shall be documented.“
In der Praxis bedeutet dies, dass der entsprechende HIL-Aufbau vor der Implementation im Prozess und damit vor Einsatz in Projekten im Rahmen einer Computer System Validierung (CSV) erfasst, bewertet, spezifiziert und geprüft werden muss. Betroffen davon ist sowohl die HIL-Software als auch -Hardware, ggf. auch Teile der angebundenen Infrastruktur. In besonderem Fokus sollten dabei sowohl die zu erwartenden Risiken bei Einsatz des Tools in Bezug auf die betroffenen Teilprozesse als auch die präzise Festlegung und Verifikation der Anforderungen an das Test-Equipment stehen.
Das typische HIL-Setup, was sollte es können?
Gängige HIL-Produkte bieten durch die Bank mehrere Standard-Schnittstellen wie digitale Ein- und Ausgänge (GPIO, PWM), analoge Ein- und Ausgänge (ADC und DAC) und Busse (I2C, SPI, CAN). Meist wird das Setup per USB mit einem PC verbunden. Die Anzahl bzw. Aufteilung der jeweiligen Schnittstellen variiert stark und sollte entsprechend der zu erwartenden Prüfaufgaben ausgewählt werden. Das gilt ebenso für die qualitativen Eigenschaften der Schnittstellen (Geschwindigkeiten, Auflösungen, Toleranzen etc.). Spezielle Kauflösungen für bestimmte Anwendungsbereiche oder Geschäftsfelder existieren, dies schließt Anpassungen oder Erweiterungen für den Einsatz allerdings nicht aus.
Ein nicht zu vernachlässigender Punkt sollte die Benutzbarkeit sein. Dieser Punkt wird maßgeblich durch die Software bestimmt. Sollen Tests grafisch oder mittels klassischer Programmierung erstellt werden, welche Programmiersprache kommt also in Frage? Wie leicht lässt sich das System aufsetzen, in Betrieb nehmen und integrieren?
Wie also starten?
Am Anfang steht sicher die Frage: „Make or buy?“ Auch wenn der Markt viele fertige Produkte bietet, kann es sinnvoll sein, eine eigene, bereits auf den Einsatzzweck oder das Umfeld ausgelegte Lösung zu entwickeln. Ein brauchbares Setup, das ein USB-IO-Adapter-Board und Peripherie enthält, ist bereits für wenige hundert Euro pro Stück (Materialkosten) verfügbar. Meist ergibt die Kopplung mit einer CI/CD-Umgebung (Continuous Integration/Continuous Delivery) Sinn – HIL-Tests sind dann Teil jedes Software-Erstellprozesses. In jedem Fall sollte der Aufbau und die Konfiguration gründlich dokumentiert werden.
Ist das HIL-System unter Versionskontrolle gestellt und der entsprechende Stand „eingefroren“, wird mit dem CSV-Prozess fortgefahren. Das Werkzeug ist danach, ein positives Resultat vorausgesetzt, grundsätzlich für den produktiven Einsatz bereit. Änderungen und spezielle Anpassungen für ein Projekt ab diesem Zeitpunkt sollte der CSV-Prozess ebenso absichern.
Final thoughts…
HIL-Testing ist ein mächtiges Werkzeug in der Entwicklung und Verifikation komplexer Systeme. Es ermöglicht Ingenieuren, reale Szenarien, aber auch Grenzbereiche, in einer kontrollierten Umgebung zu simulieren und die Reaktion eines Systems zu überprüfen, lange bevor das Medizinprodukt auf den Markt kommt. Ist erst einmal die Einstiegsschwelle überwunden, lassen sich die Effizienz und Sicherheit der Testprozesse, damit ebenso die Produktqualität, erheblich steigern.
Bitte beachten Sie, dass alle Angaben und Auflistungen nicht den Anspruch der Vollständigkeit haben, ohne Gewähr sind und der reinen Information dienen.
