Was ist Hardware-in-the-Loop (HIL)?

Die bedeutenden Auswirkungen der Markteinführungszeit wurden in den 1980er Jahren durch bahnbrechende Arbeiten des ehemaligen McKinsey-Beraters Donald G. Reinertsen deutlich, die darauf hindeuten, dass „eine sechsmonatige Verzögerung 33 Prozent des Lebenszyklusgewinns wert sein kann“, der durch die Produktentwicklung verursacht wird. Darüber hinaus lehrte der Start und die Zerstörung der Ariane-5-Rakete am 4. Juni 1996 – bekannt als einer der berüchtigtsten Softwarefehler in der Geschichte – die Ingenieurwelt, wie wichtig Embedded-Softwarequalität und die Notwendigkeit ordnungsgemäßer Tests sind. Das Ergebnis war ein Verlust von mehr als 370 Millionen US-Dollar.ii Diese Zahlen sind ein klarer Beweis für die Folgen von Verzögerungen und der Notwendigkeit einer kürzeren Markteinführungszeit sowie einer Kostenreduzierung durch Erkennen von Fehlern und Fehlern durch ordnungsgemäße Tests zu einem früheren Zeitpunkt im Produktdesign und im Entwicklungszyklus.

Es ist wichtig, Technologie zu verwenden, die Fehler vor Produktionsbeginn auffängt. Es wird immer wichtiger, Tests zu einem integralen und strategischen Asset zu machen – als Teil des gesamten Produktdesign- und Entwicklungszyklus und nicht nur als Nachdenken oder gar Showstopper am Ende des Prozesses. Dieses Verständnis hat zur Entwicklung und Implementierung von Methoden und Strategien geführt, die als Frontload-Test, Linksverschiebung, modellbasiertes Design und XIL-Tests bezeichnet werden. In diesem Whitepaper wird der HIL-Test als eine der wichtigsten Testmethoden bei der Validierung eingebetteter Software hervorgehoben.

Bevor Sie direkt in den HIL-Test einsteigen, ist es wichtig, sich das tatsächlich zu entwickelnde Produkt anzusehen: das zu testende Gerät oder System (DUT/SUT). Die Produkte von heute und morgen sind deutlich softwarezentrierter und komplexer geworden. Beispiele wie WLAN-Router, Geschirrspüler, Küchenmaschinen usw. basieren jetzt auf Embedded-Software oder Firmware. Autos, Flugzeuge und Smartphones sind Paradebeispiele dafür, dass sie nicht nur hochgradig softwaredefiniert, sondern auch hochkomplex sind, da sie ein System aus softwarebasierten Systemen sind. Letztendlich haben sie alle gemeinsam, dass Software das bestimmende Element ihres aktuellen Funktionsumfangs und künftiger Verbesserungen ist. Aktualisierbare Apps auf einem Smartphone, die es in ein Multitool aus Tausenden von Funktionen und Funktionen verwandeln, sind die klare Verkörperung dieses Trends, der sich zur unbestreitbaren Erwartung der heutigen Kunden an fast jedes zweite Produkt entwickelt hat.

Apps, Firmware und Software im Allgemeinen können nicht alleine stehen, da sie Hardware benötigen. In der Regel handelt es sich bei der Hardware um einen Computer oder Prozessor – oder einfach nur um einen Controller. Das bedeutet, dass ein Produkt oder System (einschließlich Systemen aus Systemen) die Kombination und Integration von Hardware (Controller) und Software erfordert, die dann zum Prüfling wird. Darüber hinaus erfordert der Controller auch eine Interaktion mit seiner Umgebung. Zum Beispiel muss die Steuerung einer Waschmaschine prüfen, ob genügend Wasser vorhanden ist, die Temperatur des Wassers messen, die Drehzahl der Waschtrommel steuern usw. Daher benötigt der Controller die Verbindung zu Sensoren (Temperatur, UpM) und Aktoren (Heizung, Elektromotor), die Daten oder Rückmeldungen als Eingänge bereitstellen und Befehle oder Sollwerte als Ausgänge senden. Dies sind nur die grundlegenden Komponenten der Regelkreisdesigntheorie (siehe Abbildung 1). Die Umgebung um die Steuerung wird dabei typischerweise als Anlage bezeichnet.

Abbildung 1: Grundlagen des Regelkreisdesigns

Beim Betrachten des Produktdesigns und des Entwicklungszyklus wird deutlich, dass nicht alle Komponenten der Regelschleife zu Beginn eines Projekts verfügbar sein werden. Darüber hinaus ist es unrealistisch, alle notwendigen Hard- und Softwarekomponenten in den frühen Entwicklungsphasen bereit und verfügbar zu haben. Hier füllen Simulation und modellbasiertes Design die Lücken.

Abbildung 2 zeigt den Produktentwicklungszyklus in typischer V-Diagramm-Darstellung mit seinen verschiedenen Phasen vom Entwurf über Prototyping, Software- und Controller-Tests bis hin zu physischen Tests. Außerdem werden die Testmethoden von Model in the Loop (MIL), Software in the Loop (SIL) und Hardware in the Loop (HIL) veranschaulicht.

Abbildung 2: Das V-Diagramm: Von Anything in the Loop (XIL) zu physischem Test

Digitale Simulation und modellbasierter Entwurf sind der Schlüssel für den gesamten Entwurfsprozess, weil sie:

• Entwicklung und Tests ermöglichen, bevor die erforderlichen physikalischen Komponenten verfügbar sind
• Erhöhen der Testabdeckung und Erstellen schnellerer Entwurfsiterationen
• Erhöhung der Geschwindigkeit durch Minimierung der Anzahl redundanter (physikalischer) Tests
• Sie beschleunigen Produktqualitätstests für Eckfälle und alle erdenklichen Szenarien.

Simulation und modellbasiertes Design ermöglichen den Testbeginn viel früher (als Frontloading-Test bezeichnet) durch Testmethoden wie MIL, SIL und HIL. Wie in Abbildung 2 unten dargestellt, werden die Komponenten der Regelschleife schrittweise ersetzt, wenn sie sich im V-Diagramm von rechts nach links bewegen (auch als Linksverschiebung bezeichnet). Während sie sich entsprechend dem tatsächlichen Produktdesign und Entwicklungslebenszyklus nach rechts bewegen, werden die Komponenten durch die tatsächlich verfügbare Hard- und Software ersetzt.

Darüber hinaus maximieren virtuelle Tests die Testabdeckung und reduzieren die Anzahl teurer und zeitaufwändiger physikalischer Tests. Eine ungefähre Schätzung der Anzahl von Fehlern, die in Embedded-Software gefunden werden, liegt in der Größenordnung zwischen 10 und 20 pro 1.000 Codezeilen. Diese Zahl mag nicht sehr hoch erscheinen, aber wenn man bedenkt, wie viele Codezeilen heute in ganz gewöhnlichen Systemen enthalten sind, kann die geschätzte Anzahl der Fehler unglaublich hoch sein. Bei medizinischen Geräten wie Herzschrittmachern mit 80.000 Zeilen Softwarecode oder einem Kernspintomographen mit 7.000.000 Zeilen wird jedoch deutlich, wie groß die Systemkomplexität ist – und wie viel schwerwiegender die Auswirkungen sein können.

Die Komplexität dieser Systeme ist so überwältigend, dass sie auf herkömmliche Weise nicht mehr eingehend getestet werden können. Es ist unmöglich, alle Szenarien physikalisch zu testen, da dies unverhältnismäßig viel Zeit und Geld in Anspruch nehmen würde. Zudem muss man sich darauf verlassen können, dass die Testfälle alle möglichen realen Bedingungen abdecken. Große Ausfälle, Katastrophen und Geräterückrufe sind sehr teuer, wie im Beispiel Ariane 5 in der Einleitung dieses Whitepapers erwähnt. Aber noch mehr sind die negativen Auswirkungen dieser Folgen auf Markenimage und Unternehmensruf einfach unbezahlbar. Dieses Risiko kann durch Modellierung und Simulation verringert werden. Wir können Produkte praktisch in allen möglichen, wiederholbaren Szenarien testen und darauf vertrauen, dass der abschließende physikalische Test nur eine letzte Kontrolle ist und nicht zu einem teuren, schwerwiegenden Ereignis führt.

Das Testen von Embedded-Software dient als Methodik zur Problemerkennung und bringt Entwurfs- und Testteams durch einen kompatiblen Arbeitsablauf zusammen.

Abbildung 3: MIL-, SIL-, HIL- und physische Tests in der Regelkreisdarstellung

Die erste Stufe, MIL (Quadrant 1 in Abbildung 3), simuliert alles, einschließlich des Reglers und der gesamten Anlage (Umgebung) um den Regler herum.

In der zweiten Stufe, SIL (Quadrant 2 in Abbildung 3), erzeugen Software-Ingenieure zielbereiten Code nur aus dem Steuerungsmodell, ersetzen den Block und erstellen einen Softwareprototyp, während die Anlage noch simuliert wird. Diese ersten beiden Stufen ermöglichen die Testausführung mit Hilfe der Simulation und Modelle erfordern kaum reale, physische Hardwarekomponenten.

Die dritte Stufe, HIL (Quadrant 3 in Abbildung 3), ist entscheidend für diese Methode. Der Programmcode wird auf einer physischen, hardwarebasierten Steuereinheit (einer Rapid-Control-Prototyping-Plattform oder einem produzierten Controller) bereitgestellt und ausgeführt, so dass alle möglichen realen Szenarien mit Hilfe der simulierten Anlage getestet werden können.

Daher kann HIL als das Äquivalent zur Ehe zwischen dem Chassis und dem Antriebsstrang eines Fahrzeugs angesehen werden, dessen Karosserie sich auf einer Produktionslinie befindet. Es ist wichtig, den entwickelten Softwarecode auf der eigentlichen Controller-Hardware auszuführen, um sicherzustellen, dass alle Timing-, Synchronisations- und Ausführungsfehler identifiziert werden können, die typischerweise nicht vorhanden sind, wenn der Embedded-Code beispielsweise in einer SIL-Umgebung ausgeführt wird.

Es gibt große Erwartungen und erhebliche Weiterentwicklungen, um die Betonung und Nutzung von MIL und SIL weiter zu erhöhen. Aber HIL wird und muss immer der Beweis dafür sein, dass Embedded-Software auf der realen Controller-Plattform ausgeführt wird – um sichere und softwareorientierte Produkte mit Vertrauen auf den Markt zu bringen. Zusammenfassend bietet HIL-Test folgende Vorteile:

• Sichere Tests—Vermeidet das Risiko, teure oder gefährliche Geräte zu beschädigen
• Kosteneffizienz – Verringert den Bedarf an vollständigen Prototypen
• Schnelle Entwicklung—Ermöglicht frühzeitiges Testen vor dem Erstellen des Gesamtsystems
• Wiederholbare Szenarien – Simuliert gängige Cases und Fehler zuverlässig

Abbildung 4: Die Fischanalogie: Ein HIL-System entspricht einem Aquarium.

HIL ist eine Testmethode, die eine virtuelle Umgebung oder virtuelle Realität (digitaler Zwilling) um den physischen Prüfling (eingebettete Software, die auf einem Controller ausgeführt wird) herum bereitstellt, um zu „glauben“, dass sie tatsächlich mit der realen Umgebung (physikalischer Zwilling) verbunden ist. Eine sehr einfache Analogie dazu ist ein Fisch in einem Aquarium oder Fischbecken, wie in Abbildung 4 dargestellt. Das Aquarium ahmt die reale Umgebung des Ozeans perfekt nach, indem es eine kontrollierte simulierte Umgebung bietet, um sicherzustellen, dass die Fische alles haben, was sie zum Überleben benötigen (Futter, Wasser, Temperatur, Salzgehalt usw.).

HIL ist ein Embedded-Software-Testverfahren, bei dem reale Signale von einem Controller mit einem Testsystem (einer Anlage) verbunden werden. HIL simuliert mithilfe von Softwaremodellen und Simulation die Realität. Das HIL-Testsystem, das die reale Umgebung imitiert, entspricht dem Aquarium – und der Prüfling (Physical Controller Executing Embedded Software) entspricht dem Fisch. Dies lässt den Controller (oder Prüfling) glauben, dass er im zusammengesetzten Produkt wie einer Waschmaschine, einem Flugzeug oder einem Auto installiert ist.

Test- und Entwurfsiterationen finden statt, als wären sie mit dem realen System verbunden, jedoch durch eine simulierte Anlage. Durch die Verwendung wiederholbarer, virtualisierter Szenarien können Ingenieure den Controller über Tausende von Bedingungen hinweg trainieren, ohne dass alle realen Komponenten verfügbar sein müssen, Kosten, Komplexität oder Zeitplanbeschränkungen für hardwarebasierte physische Tests. Der reale Controller oder Prüfling empfängt seine Eingänge vom HIL-System und sendet seine Ausgangswerte zurück an das HIL-System. Das HIL-System besteht aus Ein- und Ausgängen einschließlich Busschnittstellen sowie einem Echtzeit-Rechenkern, der die HIL-Anwendungssoftware einschließlich der erforderlichen Anlagenmodelle ausführt. Um sicherzustellen, dass ein HIL-Testsystem alle Voraussetzungen erfüllt, um eine umfassende virtuelle Realität um den Prüfling bereitzustellen, muss es mindestens aus diesen Kernelementen bestehen (siehe Abbildung 5:

• DUT(eingebettete Software, die auf einem Controller ausgeführt wird)
• I/O- und Busschnittstellen zum Anschließen an den Prüfling
• Echtzeitberechnung zum deterministischen Lesen, Schreiben und Steuern der I/O- und Kommunikationsbusse sowie zur Ausführung von Anwendungssoftware
• Anwendungssoftware zum Konfigurieren des Testsystems, Integrieren und Verteilen von Simulationsmodellen, Ausführen eines Tests oder mehrerer Testfälle (manuell und automatisiert) sowie Analysieren und Beheben von Fehlern in Ergebnissen und Verhaltensweisen
• Simulationsmodell(e)

Abbildung 5. Steuerschleife in einem HIL-Testsystem

Wie bereits erwähnt, sind dies nur die Kernelemente eines HIL-Systems. Weitere Elemente können auch folgende Elemente enthalten:

• Fehlerinjektion
• FPGA-basierte I/O
• I/O-Umschaltung
• Signalaufbereitungskomponenten
• Verbindungen zu Lasten oder emulierten Lasten
• Restbussimulation (erforderliche Eingaben von anderen Controllern, z. B. in einem System aus Systemen)
• Testautomatisierung bis hin zur kontinuierlichen Integration und kontinuierlichen Verteilung (CI/CD)

Der auf der NI-Plattform basierende Ansatz für HIL-Tests bietet Entwicklern und Benutzern eine Toolbox mit offenen und flexiblen Bausteinen, die eine umfassende Anpassung von kommerziellen Regalprodukten (COTS-Produkten) und eine Skalierung von kleinen Tischplatten auf Komponenten und Systeme sowie vollständige Integration von HIL-Setups ermöglichen. Benutzer können entscheiden, was sie verwenden und wie sie für aktuelle und zukünftige Herausforderungen erweitern und erweitern. Sie behalten die volle Kontrolle über ihren Workflow sowie die Entwicklung und Wartung ihrer Test-Assets und minimieren gleichzeitig die Herstellerabhängigkeit.

Die HIL-Testsystemarchitektur von NI bietet eine umfassende Hard- und Softwareplattform, die die verschiedenen Elemente eines HIL-Systems adressiert. Seine offene, anpassbare Toolchain maximiert die Fähigkeit, ein HIL-Testsystem mit einer Mischung aus Hard- und Software von NI, NI Partner und Drittanbietern anzupassen, zu skalieren und zu erweitern.

PXI ist eine führende Hardwareplattform nach Industriestandard, die auf echter COTS-Technologie basiert. Es bietet erstklassige Timing- und Synchronisationsfunktionen und ist ein grundlegendes Element von HIL-Testsystemen. PXI unterstützt auch eine breite Palette von I/O- und Busschnittstellen – von DC bis RF – einschließlich FPGA-basierter Technologie, universeller Schnittstellen und branchenspezifischer Kommunikationsprotokolle.

Diese I/O- und Busangebote können durch die NI Switch Load and Signal Conditioning (SLSC)-Plattform erweitert werden. SLSC fügt dem Signalweg zwischen den eigentlichen I/O- und Busschnittstellen auf der Testsystemseite und dem Prüfling benutzerdefinierte Frontend-Module hinzu. Durch standardisierte COTS-Konnektivität und Formfaktoren entfällt der fehleranfällige Prozess der Punkt-zu-Punkt-Verdrahtung. Dies vereinfacht das Gesamtsystem und ermöglicht Signalumschaltung und -aufbereitung, Lastintegration, Fehlerbehebung und mehr.

NI VeriStand ist die Kernanwendungssoftware für HIL-Systeme und Embedded-Softwaretests von NI unter Echtzeitbedingungen. Es beschleunigt den Produktentwicklungszyklus durch konfigurationsbasiertes Einrichten und Steuern von HIL-Systemen (UI und API), Fehlersuche, Modellintegration, Echtzeit-Stimuluserzeugung, In-Produkt-Automatisierung sowie umfangreiche benutzerdefinierte API-Funktionen durch NI LabVIEW, C/C++, Python und mehr.

Weitere Informationen zur NI HIL Test System Architecture finden Sie hier.

Heutige Produkte sind softwarezentriert geworden, und die Basis für die Erwartungen der Kunden ist, dass sich ein Produkt in Zukunft weiterentwickeln und verbessern wird – und einen kontinuierlichen und sogar neuen Wert bietet. Virtuelle Validierungstests mit Simulation, modellbasiertem Design und HIL-Tests sind wichtige Methoden zur Erhöhung der Testabdeckung und Produktqualität. Diese Methoden verkürzen auch die Markteinführungszeit, indem sie Tests starten und in frühe Entwicklungszyklen integrieren und gleichzeitig die Notwendigkeit kostspieliger und zeitaufwändiger physischer Tests minimieren.

Dies macht das Wort „Test“, das oft als letzte Schritte definiert und verwendet wird, um einen Entwurf in die Produktion und schließlich auf den Markt zu bringen, zu einem strategischen Vorteil für die allgemeine Produktinnovation. Durch HIL wird das Testen zu mehr als nur einem Kontrollkästchen auf einem Projektplan. Es wird zu einem integralen Bestandteil der Innovation, die ein Design und ein Unternehmen erfolgreich macht (siehe „Sechsmonatige Verzögerung kann 33 Prozent des Lebenszyklusgewinns wert sein“).

Bei vorausschauend agierenden Unternehmen kommt HIL auch außerhalb der üblichen Tests bei der Markteinführung zum Einsatz. Obwohl das langfristige Ziel von HIL darin besteht, kostspielige Fehler (wie im Beispiel Ariane 5) in einem teuren und/oder massenproduzierten Endprodukt zu vermeiden, ist es auch ein Entwurfswerkzeug, mit dem Softwareentwickler ihre Softwaredesigns iterativ testen und optimieren können. Dies führt zu einem geprüften Produkt, bevor die formale Prüfung überhaupt beginnt. Außerdem können Softwareingenieure neue Ideen schnell konzipieren und testen. Durch das zeitgerechte Feedback können sie so die volle Innovationskraft entfalten.

• HIL-Testsystemarchitekturen erkunden
• Hier sehen Sie, wie Whirlpool HIL-Tests verwendet
• Erfahren Sie mehr über HIL Accelerated Archer Aviation
• Sehen Sie, wie ZF ADAS mit HIL validiert