Test & Debug In-The-Loop Testansätze für Mikrocontroller

Anbieter zum Thema

MicroConsult Academy GmbH

ISH Ingenieursozietät GmbH

IBR Leiterplatten GmbH & Co. KG

Bei Tests von Embedded-Systemen fallen oft die Begriffe Software-in-the-Loop (SiL), Processor-in-the-Loop (PiL) oder Hardware-in-the-Loop (HiL). Leider ist Entwicklern oft unklar, wann welcher dieser Testansätze einzusetzen ist. Dieser Beitrag verschafft einen Überblick.

Die Begriffe Software-in-the-Loop (SiL), Processor-in-the-Loop (PiL) und Hardware-in-the-Loop (HiL) sind als Testansätze seit vielen Jahren fester Bestandteil im Sprachgebrauch. Im Kontext klassischer Embedded-Projekte ohne Regelungsfokus bleibt jedoch oft unklar, wie diese Testansätze sinnvoll anzuwenden sind. Eine Recherche führt oft zu branchenspezifischen Interpretationen, häufig aus dem Automotive-Bereich. Der Fokus liegt dabei typisch auf der Implementierung eines Reglers. Beim Lesen dieser Interpretationen bleibt für Tester und Entwickler von Embedded-Projekten ohne Regler-Fokus unklar, welchen Mehrwert die Ansätze für Ihre Projekte haben, und wie sie dort definiert wären.

Dieser Artikel arbeitet zunächst die Merkmale und Ziele der In-The-Loop Testansätze heraus. Aus dieser Analyse wird sich bereits zeigen, warum man mit den Begrifflichkeiten leicht durcheinanderkommt – und wie man das mit einer eindeutigen Klassifizierung („wo läuft der zu testende Code“) vermeiden kann. Anschließend wird ein Projekt vorgestellt, um die Testansätze praxisnah auf eine Mikrocontroller-Umgebung ohne Regler-Fokus zu übertragen.

Ursprung der In-The-Loop Testansätze

SiL, PiL und HiL wurden ursprünglich für den Test von Reglern eingesetzt. Dieser Ursprung ist entscheidend für das Verständnis der heutigen Verwendung. Unser Beispiel wird keinen Regler enthalten und dennoch sinnvolle Anwendungen für alle In-The-Loop Testansätze haben.

Ein Regler misst kontinuierlich einen Prozess und versucht, die Abweichung zwischen gemessenem Ist-Wert und gewünschtem Soll-Wert durch Stelleingriffe zu minimieren. Die entstehende Rückkopplung der Umgebung auf den Regler wird im Englischen mit Feedback-Loop bezeichnet.

Ein einfaches Beispiel ist ein Zweipunkt-Temperaturregler. Über einen Fühler wird die Ist-Temperatur gemessen. Ein Algorithmus vergleicht Soll und Ist-Temperatur und schaltet als Stelleingriff ein Heizelement ein oder aus.

Bild 2 zeigt die praktische Umsetzung des Reglers aus Bild 1 mit einem Mikrocontroller. „Hardware“ bezeichnet hier das gesamte Steuergerät, also typischerweise eine oder mehrere Platinen.

Der SiL-Test verifiziert den isolierten Algorithmus. Dieser Test ist komplett hardware-unabhängig und kann auf dem PC ausgeführt werden. Die SiL-Umgebung muss dabei kontinuierlich auf Basis der Stelleingriffe für die korrekte Simulation der Ist-Werte sorgen (Feedback-Loop).

Der PiL-Test verifiziert den Algorithmus auf dem Mikrocontroller. Die Rolle der PiL-Umgebung wird in der Praxis jedoch sehr unterschiedlich interpretiert. Im häufigsten Fall wird der Algorithmus weiterhin isoliert auf dem richtigen Mikrocontroller ausgeführt und die Umgebung sorgt lediglich für die richtigen logischen Ein- und Ausgänge. Die Zeitbasis ist simuliert und die Umgebungssimulation läuft teilweise für diese Testzwecke auf dem Mikrocontroller. Technisch konsequent ist eine andere Interpretation: Die PiL-Umgebung simuliert hier kontinuierlich auf Basis der Ausgangs-Pins die Eingangs-Pins. Diese Interpretation eröffnet auch abseits von klassischen Reglern viele interessante Anwendungsfälle für Mikrocontroller und wird im Weiteren verwendet.

Der HiL-Test verifiziert den Algorithmus auf der gesamten Hardware. Die HiL-Umgebung muss dabei kontinuierlich auf Basis der Hardware-Ausgänge für die korrekte Simulation der Hardware-Eingänge sorgen.

Für viele Embedded-Projekte ist der ausschließliche Fokus auf ein Regelproblem nicht ausreichend. Im nächsten Abschnitt wird gezeigt, dass das Denken in den Umgebungen für Tests dennoch hilfreich ist.

Ein Embedded-Beispiel ohne Regler

„RedAlert“ soll ein sicherheitskritisches System zur Aufnahme und Übertragung von Temperaturwerten sein. Das Beispielsystem soll

• die Temperatur über einen PT1000-Sensor erfassen,

• jede Sekunde den aktuellen Temperaturwert über CAN übertragen, und

• einen defekten Messvorgang erkennen und im Fehlerfall eine rote Fail-Safe LED einschalten.

Die Regelung oder Steuerung eines externen Systems ist nicht Teil der Anforderungen. Wie übertragen sich hier die In-The-Loop Testansätze? Dazu ist es hilfreich, sich zunächst an der Softwarestruktur zu orientieren.

SiL: Die Logik nutzt den HAL, um eine bestimmte Funktionalität zu implementieren. Der SafetySensor ermittelt beispielsweise aus den ADC-Rohwerten die aktuelle Temperatur. Eine calc_temperature_from_adc Funktion rechnet eine gemessene Spannung am PT1000 Sensor in die Temperatur um. Diese Umrechnung kann isoliert in einer SiL-Umgebung ausgeführt werden. Im Gegensatz zum oben geschilderten Regel-Algorithmus handelt es sich hier um eine sogenannte pure Funktion, die unabhängig von vorherigen Aufrufen ist. Der simulierende Teil der SiL-Umgebung ist nicht nötig.

PiL: Der Hardware Abstraction Layer (HAL) macht über einen minimalen Satz an Funktionen die Hardwarefunktionalitäten zugänglich. Die ADC-Komponente im HAL wird eine Funktion zum Auslesen der Analogpins anbieten. Diese Funktion nutzt die Special-Function-Register des Mikrocontroller, um einen Analogwert über die ADC-Peripherie des RP2040 zu sampeln. Eine PiL-Umgebung kann am Pin eine beliebige Analogspannung einstellen und danach die HAL-Funktion auswerten. Je nach Auslegung des Tests und der Implementierung kann dies fortlaufend oder einmalig geschehen. Der simulierende Teil der PiL-Umgebung ist nicht nötig.

HiL: Die Applikation verbindet die einzelnen Logikteile miteinander. Das kann eine Endlosschleife oder ein Echtzeitbetriebssystem sein. Die Applikation nimmt sekündlich eine Temperaturmessung vor und sendet den Messwert per CAN. Eine HiL-Umgebung bildet den extern angeschlossenen PT1000 Sensor nach und ermöglicht so das Einstellen einer zu testenden Temperatur. Über einen CAN-Adapter analysiert die HiL-Umgebung die gesendeten Frames. Ein Test kann so beispielsweise überprüfen, dass die Frames in einem zeitlichen Abstand 1s +/- 10% erfolgen und eine gewünschte Genauigkeit bei der Temperaturangabe erreichen. Auch hier wird der simulierende Teil der HiL-Umgebung nicht benötigt.

Warum PiL mehr kann als oft angenommen

Bei einem genaueren Blick zeigt sich, dass eine PiL-Umgebung sehr viel mehr Testfälle sinnvoll abdecken kann, als die vorigen Beispiele vermuten lassen.

Interne Mikrocontroller-Peripherie: Bei ressourcenintensiven Berechnungen wird in der Praxis versucht, möglichst viel Rechenarbeit durch vorhandene Mikrocontroller-Peripherie zu erledigen. Beispielsweise können CRC oder Crypto-Berechnungen durch Peripherie deutlich beschleunigt werden. So kann in reiner „Logik“-Software eine Abhängigkeit zum Mikrocontroller entstehen. Eine gute PiL-Umgebung verfügt als Subset auch über alle Möglichkeiten einer SiL-Umgebung. Software, die interne Mikrocontroller-Peripherie verwendet, kann leicht in einer PiL-Umgebung geprüft werden.

Firmware-Tests ohne Hardware: Im vorigen Abschnitt wurde ein typischer HiL-Test für die Firmware vorgestellt. Aber braucht es für einen solchen Test wirklich eine HiL-Umgebung?

Das hängt stark vom Blickwinkel ab. Soll das Produkt bei Projektende getestet und freigegeben werden? Oder benötigt das Software-Team entwicklungsbegleitend eine Aussage darüber, ob die Firmware funktioniert?

Im ersten Fall ist zwingend eine HiL-Umgebung nötig, da nur hier die Hardware ein Teil des Tests ist. Im zweiten Fall hingegen ist die Abhängigkeit zur Hardware vielfach sogar unerwünscht. Eine Hardware steht als Leiterplatte oft erst im Verlauf eines Projektes zur Verfügung und würde so den frühzeitigen Test blockieren.

Ein Blick in den Schaltplan hilft zur Einordnung, ob der Firmware Test auch in einer PiL-Umgebung stattfinden kann. Bild 5 zeigt die Anbindung des PT1000 Sensors (TH1). Analog0 ist mit einem Analogeingang des Mikrocontrollers verbunden. Über den Schaltplan und das Datenblatt des PT1000 Sensors kann zwischen Temperatur und Anlaog0 Spannung umgerechnet werden.

Die PiL-Umgebung kann ebenfalls den CAN TX Pins auswerten. Damit kann der oben skizzierte HiL-Test einer Firmware („werden CAN-Frames in der richtigen Zeit mit dem richtigen Temperatur-Inhalt gesendet“) problemlos auch in der PiL-Umgebung durchgeführt werden!

Wann sind Simulationen nötig?

Bisher war allen Beispielen gemeinsam, dass die Test-Umgebung keine „Loop“ erforderte. Alle Szenarien waren mit sogenannten „Open-Loop-Tests“ durchführbar, das heißt es musste keine Simulation der Umgebung stattfinden. Die In-The-Loop Umgebungen dienten der Auswahl der richtigen Test-Schnittstelle auf Software, Pin oder Hardware-Ebene.

Simulationen werden immer dann nötig, wenn die Ausgänge der Funktionen (SiL), der Pins (PiL) oder der System Ein- und Ausgänge (HiL) eine rückwirkende Auswirkung auf die Eingänge haben. Klassisch ist das Beispiel einer geregelten Motordrehzahl. Der Mikrocontroller steuert über PWM eine Leistungselektronik, die dann den Motor in Drehung versetzt. Ein Tachometer führt die Drehzahl auf einen Eingang des Mikrocontrollers zurück.

Ein Blick auf das RedAlert-Beispiel zeigt eine weitere Rückwirkung. Der TestPulse aus Bild 5 ist ein Sicherheitsfeature und soll einen Selbsttest der Hardware ermöglichen. Schaltet der Mikrocontroller diesen GPIO ein, so wird der parallel geschaltete Mosfet Q1 dafür sorgen, dass der Strom durch TH1 kleiner und die Spannung Analog0 ebenfalls kleiner wird.

Die Firmware kann für eine kurze Zeit den Testpulse einschalten und prüfen, ob der Analog0-Spannung in diesem Zeitraum um einen berechneten Wert abfällt.

Ist dieser Mechanismus in der Firmware implementiert, muss eine PiL-Umgebung das TestPulse-Signal überwachen und die Analog0-Spannung entsprechend abfallen lassen. Diese Simulation ist nötig, da ansonsten die Firmware einen Fehlerzustand detektieren und einen Fail-Safe Zustand einnehmen würde.

Für einen HiL-Test ist eine solche Simulation nicht nötig, da die Schaltung aus Bild 5 zur „internen Elektronik“ aus Bild 2 gehört. Gleichzeitig heißt das aber auch, dass ein Test dieser Überwachungslogik auf einer PiL-Umgebung leichter zu realisieren ist, da der Test eine direkte Kontrolle über die Simulation von Analog0 hat.

Die Auswahl der passenden Umgebung ist immer eine Testdesign-Entscheidung.

In-the-Loop beschreibt nicht zwingend eine Simulation, sondern die Art der Kopplung zwischen Testumgebung und Testobjekt.

Das TestPulse-Beispiel hat gezeigt, dass Simulationen nicht nur für klassische Regelungen nötig sind. Nahezu jedes Embedded-System verfügt über Rückwirkungen. Die Tabelle zeigt in der Übersicht noch einmal die Eignung der verschiedenen In-The-Loop Umgebungen für typische Testfälle.

Fazit: Nicht jedes Projekt erfordert eine aufwendige HiL-Umgebung. Gerade für komplexe Mikrocontroller-Projekte kann eine PiL-Umgebung einen sinnvollen Mix zwischen Testmöglichkeiten und Testaufwand bieten.  (sg)

* Daniel Penning ist Geschäftsführer der embeff GmbH

(ID:50699552)