Hardware-in-the-Loop-Tests: Eine Einführung

Ari Mahpour
|  Created: May 27, 2020  |  Updated: November 17, 2020
Hardware-in-the-Loop-Tests: Eine Einführung

Wenn Sie nach "Hardware-in-the-Loop"-Tests suchen, werden Sie häufig Beispiele für komplexe Echtzeitsysteme finden. Dieser Artikel von National Instruments gibt zum Beispiel eine schöne Erklärung und Hintergrundinformationen darüber, was Hardware-in-the-Loop (HIL) ist, und liefert ein Beispiel für den Test von elektronischen Steuergeräten in einem Automobil. In diesem Artikel konzentrieren wir uns auf eine kleinere Version von HIL-Testkonzepten.

Was sind Hardware-in-the-Loop-Tests?

Für die Zwecke dieses Artikels werden wir Hardware-in-the-Loop-Tests etwas anders definieren, als üblich (z.B. innerhalb von Automobilanwendungen). Lassen Sie uns drei verschiedene Komplexitätsebenen betrachten, wenn es um das Testen eines Produkts geht.

Testformat 1: Grundlegende manuelle Tests

Bei diesem Testformat prüft ein Ingenieur das Gerät manuell. Dies kann durch die Abtastung von Testpunkten auf einer Platine mit einem Digitalmultimeter, das Beobachten von Wellenformen auf einem Oszilloskop oder das manuelle Parsen durch eine Telemetrie-Anzeige auf einem Computerbildschirm geschehen. Der Ingenieur prüft das Produkt durch manuelle Designverifizierungstests.

Depiction of manual testing
Abbildung 1. Darstellung manueller Tests

Testformat 2: Automatisierte Tests

Bei diesem Testformat erfolgen dieselben Messungen und Überprüfungen, die normalerweise von einem Ingenieur durchgeführt werden, jedoch werden sie von einem Computer automatisiert ausgeführt. Der Host-Computer spricht direkt mit den Instrumenten (z.B. Multimeter, Oszilloskop usw.), parst die Telemetrie vom Gerät und verifiziert dann den Testaufbau anhand der vom Ingenieur festgelegten Kriterien.

Depiction of automated testing
Abbildung 2. Darstellung automatisierter Tests

Testformat 3: Hardware-in-the-Loop-Tests

Hardware-in-the-Loop-Tests bringen automatisierte Tests auf eine neue Ebene, indem zusätzliche Stimuli hinzugefügt werden, um eine reale Anwendung zu simulieren. Zum Beispiel kann das zu testende Gerät (device under test, DUT) eine Reihe von Sensoren haben, die angeregt werden müssen. Die Testausrüstung würde in diesem Fall das andere Ende dieser Sensoren simulieren, um die Sensorseite des DUT anzuregen. Ein anderes Beispiel könnte etwas so Einfaches sein, wie RS-422-Verkehr in einen RS-422-Empfänger am DUT zu treiben. Die Idee ist, dass wir in der Lage sind, neue Impulse in das DUT zu treiben, die Telemetrie vom Host-Computer zurückzulesen und unsere Tests bei Bedarf entsprechend anzupassen (z.B. nach Bestehen eines ersten Tests schnelleren und größeren RS-422-Verkehr zu treiben).

Depiction of hardware-in-the-loop testing
Abbildung 3. Darstellung von Hardware-in-the-Loop-Tests 

Die Vorteile von dieser Tests

Basierend auf der Anwendung wird deutlich, warum man Hardware-in-the-Loop-Tests gegenüber automatisierten Tests (und sicherlich auch manuellen Tests) bevorzugen sollte. Wenn man versucht, ein komplexes System oder (Systeme von Systemen) mit vielen erforderlichen externen Anreizen zu integrieren, wird ein einfacher automatisierter Test nicht ausreichen. Stellen Sie sich ein einfaches Batterieladegerät vor. Während Sie eine Stromquelle, eine Last und eine Batterie simulieren könnten, um Ihre Steuerschaltung zu testen (entweder physisch oder durch Software), wäre es realistischer, eine tatsächliche Stromquelle, eine Batterie und eine Last zum Testen des Designs zu verwenden. Darüber hinaus können Ihre Ingenieure, wenn Sie diesen Prozess automatisieren, ihre Zeit mit tatsächlicher Entwicklung statt mit Tests verbringen.

Battery Charger Test Setup
Abbildung 4. Testaufbau des Batterieladegeräts

Kostenanalyse: Lohnt sich das?

Bei der Entscheidung über die Einführung von dieser Tests sollte man die folgenden Faktoren berücksichtigen:

  1. Testzeit: Wie viel Zeit werden Sie für den Test des Geräts aufwenden? Wird es ein einfacher Checkout sein, und dann sind Sie fertig, oder sind monatelange Tests erforderlich?
  2. Testwiederholung: Wie oft werden Sie den gleichen Test durchführen? Kann dieser Testaufbau (d.h. Geräte- und Automatisierungsskripte) bei zukünftigen Entwürfen verwendet werden?
  3. Testausrüstung: Wie kostspielig ist es, die notwendige Ausrüstung für automatisierte Tests im Vergleich zu manuellen Tests zu beschaffen?

Wenn Sie diese und andere Faktoren in Betracht gezogen haben, können Sie entscheiden, ob Sie beim manuellen Testen bleiben oder in automatisierte/Hardware-in-the-Loop-Tests investieren wollen.

Erste Schritte

Ich habe festgestellt, dass der einfachste Einstieg in Hardware-in-the-Loop-Tests die Verwendung eines allumfassenden Testrahmens ist, wie er von National Instruments (NI) zur Verfügung gestellt wird. NI verfügt über eine allumfassende Hardware/Software-Plattform, die Plug-and-Play ist. Hier sind einige Vor- und Nachteile, die bei der Erwägung eines allumfassenden Rahmens zu berücksichtigen sind:

Vorteile

Nachteile

Einfache Einrichtung. Treiber arbeiten nahtlos mit ihrer Softwareanwendung (z.B. LabVIEW und NI-Hardware).

Kosten. Die Ausrüstung kann im Vergleich zu kommerziellen Äquivalenten, die nicht nativ mit Framework arbeiten (z.B. native Integration mit LabVIEW), ziemlich teuer sein.

Die meisten Gerätehersteller bieten inzwischen LabVIEW-"Treiber" an, die den Bedarf an benutzerdefinierten SCPI-Bibliotheken beseitigen.

Nicht viel Unterstützung für Linux und kundenspezifisches Hardware-Design.

LabVIEW-spezifisch: Die Software-Sprache ist visuell und wird Ingenieursstudenten in vielen Disziplinen gelehrt (z.B. Maschinenbau vs. nur Computerwissenschaften).

LabVIEW-spezifisch: Programmierdateien liegen im Binärformat vor, was bedeutet, dass das Zusammenführen schwierig sein kann. Automatisierte Builds und Befehlszeilenunterstützung sind ebenfalls begrenzt und kompliziert.

Als ich an komplexen Systemen gearbeitet habe, war LabVIEW meine erste Wahl für automatisierte Tests – einschließlich des Aufbaus einer vollständigen Pipeline für kontinuierliche Integration und kontinuierlichen Einsatz für LabVIEW-Projekte und VIs. Beim Übergang zu kleineren Systemen, die eine einfachere Hardware-in-the-Loop-Unterstützung erforderten, habe ich angefangen, benutzerdefinierte oder kommerzielle Standard-Hardware (COTS) und Python-Skripte (unter Verwendung des Pytest-Frameworks) zu nutzen. Auch hier hängt alles von der Anwendung ab und wie bereits erwähnt, sind die Testzeit, die Testwiederholung und die Testausrüstung die Hauptfaktoren, die diese Entscheidung bestimmen.

Fazit

In diesem Artikel haben wir über das Konzept von Hardware-in-the-Loop-Tests gesprochen, und wie sie sich sowohl von manuellen als auch von automatisierten Tests unterscheiden. Wir haben uns auch die Vorteile von der Tests angeschaut und gesehen, wie man beurteilen kann, ob diese Tests wirklich den Bedürfnissen des Benutzers entsprechen. Schließlich erörterten wir einige Möglichkeiten für den Einstieg. Auch wenn Hardware-in-the-Loop-Tests vielleicht nicht für jeden geeignet sind, so ist doch klar, dass sich die Investition bei der richtigen Anwendung sehr schnell auszahlen wird.

Möchten Sie mehr darüber erfahren, wie Altium Sie bei Ihrem nächsten PCB-Design unterstützen kann? Sprechen Sie mit einem Experten von Altium oder erfahren Sie mehr über die vielen Features des neuen Altium Designer in Kombination mit Altium 365

About Author

About Author

Ari is an engineer with broad experience in designing, manufacturing, testing, and integrating electrical, mechanical, and software systems. He is passionate about bringing design, verification, and test engineers together to work as a cohesive unit.

most recent articles

Back to Home