Hardware-in-the-Loop: Tutorial zur Konfiguration

Ari Mahpour
|  Erstellt: Mai 9, 2021  |  Aktualisiert am: Oktober 30, 2021
Richten Sie sich Ihr eigenes Hardware-in-the-Loop-Setup ein

In "Hardware-in-the-Loop"-Testing: Als Einführung haben wir untersucht, was Hardware-in-the-Loop (HIL)-Testing ist, wie ein mögliches Setup aussieht und welche Vorteile es bietet, diese Methode in unser Projektdesign zu integrieren. In diesem Hardware-in-the-Loop-Tutorial betrachten wir nun ein Beispielprojekt, in dem eine in Altium Designer entworfene Leiterplatte einen DevOps-Flow durchläuft, bei dem Hardware-in-the-Loop gegen ihre Firmware getestet wird.

Hardware in the Loop: Erklärung der Konfiguration anhand eines Beispiels

Bevor wir eine Hardware-in-the-Loop-Konfiguration einrichten, benötigen wir eine Beispiel-Leiterplatte, mit der wir arbeiten können. Eine gute Möglichkeit, vor der Erfassung von Schaltplänen und dem Layout mit einem Design zu beginnen, ist das Prototyping mit Evaluierungsleiterplatten. Für diesen Artikel verwenden wir das SAM4E XPlained Pro von Microchip (ehemals Atmel) als Evaluierungsleiterplatte. Um loszulegen, benötigen Sie diese Evaluierungsleiterplatte und müssen Microchip Studio installiert haben. Sobald Ihre Hardware und Software einsatzbereit sind, können Sie das Hardware-in-the-Loop-Beispiel-Projekt von Gitlab klonen. Dieses Projekt enthält eine minimale Menge an Code - gerade genug, um die Fähigkeiten des Hardware-in-the-Loop-Tests zu demonstrieren. Dieses Projekt nutzt auch einige Bibliotheken aus dem Microchip Advanced Software Framework. Das ASF bietet Treiber, die die serielle USB-Kommunikation ermöglichen, Verzögerungsroutinen und andere Bibliotheken, die viele Low-Level-Hardware-Implementierungen abstrahieren, die normalerweise für andere Mikroprozessoren geschrieben werden. Sobald Sie das Repository heruntergeladen und die Firmware kompiliert und geladen haben, sind Sie bereit, Hardware-in-the-Loop-Tests einzurichten und durchzuführen.

Konfiguration

Für die Versionskontrolle und kontinuierliche Integration/kontinuierliches Deployment (CI/CD) wurde Gitlab als Host gewählt. Versionskontrolle und CI/CD wurde in Gitlab als ein gemeinsames Tool integriert. Dieses Projekt besteht aus mehreren CI/CD-Stufen (in Gitlab auch als "Pipelines" bezeichnet):

Screenshot der Gitlab-Benutzeroberfläche: drei verschiedene Pipelines - “Build”, “Power_on” und “Program”
Figure 1: Project Pipeline

In der ersten Stufe werden die Binaries erstellt, die benötigt werden, um die Programmierdateien auf den Mikroprozessor zu laden. Danach wird das nachgeschaltete Gerät (d. h. die Evaluierungsleiterplatte) eingeschaltet. Anschließend wird das Gerät programmiert, und die Einheit ist dann testbereit.

Test

Der Hardware-in-the-Loop-Test kann je nach Bedarf einfach oder komplex gestaltet werden. Während viele komplexe HIL-Systeme externe Geräte benötigen, um reale Umgebungen zu emulieren, verwendet dieses Beispiel als grundlegenden Mechanismus die serielle Kommunikation, um einen externen Stimulus zu emulieren. Die Schnittstelle USB Device CDC von Atmel erzeugt einen virtuellen COM-Port, um eine Kommunikation über USB zu ermöglichen, die mit UART über RS-232 vergleichbar ist. In dieser Test-Suite:

  1. Stellen wir ein Register ein, indem wir einen Befehl senden
  2. Lesen wir das Register (um unseren Befehl zu validieren)
  3. Löschen wir das Register
  4. Lesen wir das Register erneut

Während die Firmware für den Mikroprozessor in C geschrieben ist, ist die Testsoftware (die die Befehle steuert und die Telemetrie ausliest) in Python unter Verwendung des Pytest-Frameworks geschrieben. Da die Software in Python geschrieben wurde, können wir die Vorteile von High-Level-Skripten und Bibliotheken nutzen, deren Entwicklung in einer kompilierten Sprache wie C++ normalerweise viel mehr Zeit und Aufwand erfordern würde. Darüber hinaus können wir diese Tests auf jeder Art von Maschine durchführen, unabhängig von deren Betriebssystem oder sogar Chip-Architektur. Die gleichen Tests, die auf einem Windows-PC (Windows, x86) laufen, können auch auf einem Raspberry Pi (Linux, ARM) durchgeführt werden. Das Abstrahieren von Entwicklung, Kompilieren und Testen von Ihrem Rechner aus ist ein wichtiges Prinzip im DevOps-Workflow. Dabei liegt der Vorteil darin, dass Sie im Handumdrehen eine neue Umgebung reproduzieren können. Außerdem wollen wir die mühsame, stundenlange Erstellung einer Entwicklungsumgebung vermeiden, bei der man seitenweise Leitfäden oder Anleitungen lesen muss. Wenn man diesen Prozess (einschließlich der Tests) skriptet, wie es mit der Pipeline-Definitionsdatei umgesetzt wurde, erhält man eine reproduzierbare Umgebung ohne großen Aufwand. Wenn Sie dieselben Tests manuell über die Befehlszeile ausführen möchten, finden Sie die notwendigen Informationen dazu in der Pipeline-Datei.

Nach Abschluss des Tests werden die Ergebnisse in eine JUnit-XML-Datei geschrieben, die dann von Gitlab geparst und in der Weboberfläche angezeigt wird.

Screenshot der Gitlab-Benutzeroberfläche: Junit-XML-Datei wurde von Gitlab verarbeitet
Figure 2: Unit Test Result

Wir haben nun eine vollständige End-to-End-Lösung für die Hardware-in-the-Loop-Konfiguration mit Gitlab demonstriert. Sie können sich gerne das Projekt genauer ansehen, um sich mit dem Setup und dem Format vertraut zu machen.

Zusammenfassung

In diesem Artikel haben wir anhand eines Beispiels erklärt, wie man ein Projekt für Hardware-in-the-Loop-Tests konfiguriert. Unter anderem haben wir uns ein auf Gitlab gehostetes Beispielprojekt angesehen, das Benutzer klonen und mithilfe der Pipeline-Konfigurationsdatei (d. h. der Datei .gitlab-ci.yml) konfigurieren können. Wir haben auch die Ausführung der Tests in Python unter Verwendung des Pytest-Frameworks behandelt und besprochen, wie sie in der Weboberfläche angezeigt werden. Der Benutzer kann nun mithilfe dieser Anleitung und des auf Gitlab gehosteten Beispielprojekts sein eigenes Hardware-in-the-Loop-Setup erstellen.

Würden Sie gerne mehr darüber erfahren, wie Altium Sie bei Ihrem nächsten PCB-Design unterstützen kann? Sprechen Sie mit einem Experten von Altium und erfahren Sie mehr darüber, wie Sie Designentscheidungen einfach und sicher treffen können.

Über den Autor / über die Autorin

Über den Autor / über die Autorin

Ari ist ein PCB-Designer mit umfassender Erfahrung in der Entwicklung, Herstellung, Prüfung und Integration verschiedener Softwaresysteme. Dabei bringt er leidenschaftlich gern Entwickler aus den Bereichen Design, Prüfung und Abnahme zusammen, um gemeinsam an Projekten zu arbeiten und diese voranzutreiben.

Ähnliche Resourcen

Verwandte technische Dokumentation

Zur Startseite
Thank you, you are now subscribed to updates.