Real-Time-Blackbox-Systemtest für Steuersystem und Hardware-Aufbau

In Zeiten von IoT, Automation und Vernetzung kommen viele Firmen zum ersten Mal an den Punkt, an dem saubere Systemtests kritisch für die Überlebensfähigkeit sind. Ein Gesamtsystem, das aus verschiedenen Steuerkomponenten, Sensoren, Aktuatoren und mechanischen Bauteilen besteht, ist zwar komplexer zu testen als ein einzelnes Steuergerät. Doch gerade in diesem Fall sind automatisierbare und reproduzierbare Systemtests eine große Erleichterung. Mit dem kompakten und wirtschaftlichen Fahrstuhl-Demonstrator stellt Razorcat einen Weg vor, um bestehende Testlücken zu schließen und dadurch die Qualität, Zuverlässigkeit und langfristige Rentabilität eines Produkts sicherzustellen.

Der Fahrstuhl-Demonstrator setzt sich aus den drei Komponenten Miniatur-Fahrstuhl, Steuergerät und Testsystem zusammen. Der Fahrstuhlaufbau ist rund einen Meter hoch und besitzt drei Etagen mit jeweils einem Etagentaster und einem Sensor zur Positionserfassung der Kabine. Die Kabine selbst hat bewegliche Türen und eine Beleuchtung. Der Gleichstrom-Getriebemotor des Aufzugs verfügt über einen Temperatursensor und einen Drehsensor. Alle Sensorwerte und Steuersignale für diesen Aufbau werden den anderen Komponenten über einen Stecker zur Verfügung gestellt.

Bild 1: Der Aufbau des Fahrstuhl-Demonstrators für manuelle funktionale Systemtests. Razorcat

Das Steuergerät des Fahrstuhls basiert auf einem Arduino Due. Es besitzt ebenfalls einen Stecker, über den es mit dem Fahrstuhl verbunden werden kann. Auf dem Steuergerät läuft die Steuersoftware für den Fahrstuhl, die in C geschrieben wurde. Die Software steuert die Fahrstuhlkabine entsprechend der gedrückten Taster in die jeweilige Etage und öffnet und schließt dort die Türen. Mit dem bis hierher beschriebenen Aufbau sind bereits manuelle funktionale Systemtests möglich: Ein Tester kann die Etagentaster drücken und die Reaktion des Systems betrachten und bewerten (Bild 1).

Testsystem zwischen Steuergerät und Fahrstuhl

Bild 2: Das Testsystem des Fahrstuhl-Demonstrators besteht aus Standardkomponenten. Razorcat

Für voll automatisierte Tests wurde ein Testsystem aus „emBrick“-Standardkomponenten erstellt (Bild 2), das seinen Platz zwischen dem Fahrstuhl und dem Steuergerät hat und beide Systeme über zwei Stecker verbindet (Bild 3). Diese Position im Aufbau ermöglicht es dem Testsystem, alle Signale, die zwischen Steuergerät und Fahrstuhl laufen, aufzuzeichnen und auch zu manipulieren. In seiner Grundkonfiguration ist das Testsystem in der Lage, die Signale für die Etagentasterbeleuchtung, die Motorsteuersignale, den Drehsensor und den Temperatursensor zu ermitteln. Das Testsystem kann zusätzlich alle Etagentaster drücken und einen fehlerhaften Wert für den Temperatursensor simulieren. Über Relais ist es zusätzlich möglich, die Positionssensoren für die drei Etagen schalten zu lassen.

Bild 3: Grundsätzlicher Aufbau des HiL-Testsystems. Razorcat

Das Testsystem besteht aus einem „BeagleBone“- und drei „emBrick“-Bausteinen der Firma Imacs, die Digital-Inputs, Analog-Inputs und Relais zur Verfügung stellen. Auf dem BeagleBone läuft die Gamma-V-Middleware der Firma RST, auf der die CCDL-Systemtestsprache (Check Case Definition Language) von Razorcat aufsetzt. Ein Laptop mit einer CCDL-Entwicklungsumgebung kann sich per LAN mit dem BeagleBone verbinden und darauf Tests durchführen. Die Hardware für das Testsystem ohne Fahrstuhl und Controller ist komplett bei einem großen deutschen Elektronikversand erhältlich und kostet rund 300 Euro. Die Software auf dem Testsystem – bestehend aus der Gamma-V-Laufzeitumgebung und einem CCDL-Compiler – ist für weniger als 5000 Euro zu haben. In diesem Paket ist auch eine CCDL-Entwicklungsumgebung mit Editor enthalten, die es ermöglicht, die Prozeduren am Arbeitsrechner zu entwickeln und per Netzwerk zum Testsystem zu senden. Für klassische HiL-Systeme liegt allein der Preis für die Hardware oft bereits im fünfstelligen Bereich.

Die CCDL-Sprache wurde mit dem Ziel entwickelt, Realtime-Blackbox-Systemtests so einfach wie möglich zu beschreiben. Innerhalb der Prozedur kann auf Prozessvariablen zugegriffen werden, die die Eingangs- und Ausgangssignale der Testhardware abbilden. Die CCDL-Prozeduren werden von einem Compiler in C-Code übersetzt und auf dem Zielsystem zur Ausführung gebracht. Dadurch sind selbst mit einfacher Hardware Zykluszeiten von unter 10 ms möglich. Die CCDL-Sprache ist ohne Vorwissen lesbar und auch für Nicht-Programmierer innerhalb weniger Stunden erlernbar.

Im sicherheitsrelevanten Kontext ist es oftmals auch notwendig zu testen, ob die real eingesetzte Hardware eine Sicherheitsfunktion tatsächlich in einer bestimmten Zeit umsetzen kann. Lässt sich ein Motor mit Schwungmasse innerhalb einer gewissen Zeit stoppen? Verhalten sich bestimmte Komponenten auch beim Ausfall des Steuergeräts korrekt? In einer HiL-Umgebung, die ausschließlich das Steuergerät kapselt, wird die reale Hardware simuliert und daher sind diese Fälle dort nicht testbar. Der Fahrstuhl-Demonstrator zeigt, wie es möglich ist, auch die reale Hardware mit in einen Systemtest einzubinden und diese ebenfalls mit zu testen. Das Testsystem spannt zwei Hardware-Loops auf, einmal für das Steuergerät und einmal für die reale Hardware. Der Aufbau lässt im Normalfall alle Signale unverändert zwischen Fahrstuhl und Steuergerät hin und her laufen. Durch die CCDL kann aber, wenn gewünscht, hier eingegriffen werden. Der modulare und erweiterbare Aufbau der emBrick-Module ermöglicht es, auch größere Aufbauten mit mehreren IoT-Geräten abzubilden und dort viele Geräte jeweils in einem eigenen Testloop zu kapseln.

Lesen Sie auf der nächsten Seite: Funktionale Tests automatisch und in Echtzeit.

Funktionale Tests automatisch und in Echtzeit

Mit einem Aufbau wie im Fahrstuhl-Demonstrator können vollautomatische Blackbox-Systemtests in Echtzeit durchgeführt werden. Funktionale Tests an diesem Aufbau werden durch das Testskript gesteuert und bestehen beispielsweise aus einer Abfolge von Betätigungen der Etagentaster und darauffolgender Überprüfung der angefahrenen Etagen. Variationen von unterschiedlichen realen Verhaltenssituationen für das zu testende System machen den Hauptteil solcher funktionalen Tests aus. Wenn funktionale Tests automatisiert für jede Produktversion durchgeführt werden können, lässt sich damit für jede Produktversion sicherstellen, dass das Produkt dem Kunden das gewünschte Verhalten zeigt.

In dem folgenden Beispiel wird durch das Testsystem der Etagentaster für das Erdgeschoss gedrückt und anschließend überprüft, ob die Kontrollleuchte auf dem Taster aufleuchtet.

test step 1:

{

// Press button

set CTRL_DO_FLOOR_LEVEL_0_BUTTON to ON

after 500 [ms]:

set CTRL_DO_FLOOR_LEVEL_0_BUTTON to OFF

// Check button lights

within 0 [ms] .. 100 [ms]:

expect CTRL_DI_FLOOR_LEVEL_0_LIGHT => ON

wait 2 [s]

}

Im zweiten Beispiel wird durch das Testsystem der Etagentaster für das zweite Obergeschoss betätigt. Anschließend prüft das System, ob das korrekte Steuersignal für den Motor gegeben wird. Nach weiteren 12 bis 14 Sekunden wird erwartet, dass die Kabine die zweite Etage erreicht und dort stoppt.

ccd

initial conditions:

{

// Drive elevator to level 0, close doors

// …

}

test step 1:

{

// Press button

set CTRL_DO_FLOOR_LEVEL_2_BUTTON to ON

after 500 [ms]:

set CTRL_DO_FLOOR_LEVEL_2_BUTTON to OFF

// Check motor movement

within 0 [ms] .. 100 [ms]:

expect CTRL_AI_MOTOR_DIRECTION => UP

within 0 [s] .. 1 [s]:

expect CTRL_AI_MOTOR_SPEED > HIGH_SPEED

// …

within 12 [s] .. 14 [s]:

expect CTRL_DI_LEVEL_2_SENSOR => REACHED

expect CTRL_AI_MOTOR_SPEED => OFF

}

end of ccd

Wenn bei der Testausführung nicht alle Bedingungen an den „expect“-Ausdrücken eintreffen, schlägt ein Test fehl. Die zeitlichen Vorbedingungen für diese Erwartungen sollten entsprechend den Anforderungen für das zu testende System formuliert sein. Wurde ein Fehler gefunden und behoben, kann der Test wiederholt werden, um zu überprüfen, ob nun das gewünschte Verhalten eintritt. Ohne die Einbindung der realen Hardware in den Testaufbau hätte an dieser Stelle nicht überprüft werden können, ob der Motor in der Lage ist, den Fahrstuhl innerhalb der gewünschten 14 Sekunden in die zweite Etage zu befördern.

Dies sind nur zwei von vielen Testbeispielen, um zu verdeutlichen, wie einfach funktionale Systemtests sein könnten. Die Laufzeit eines Tests ist dabei fast ausschließlich durch die zeitlichen Abläufe der realen Hardware definiert. Die CCDL-Sprache bietet noch viele weitere sprachliche Konstrukte, um auch deutlich komplexere Szenarien zu testen. Gleichzeitig bleiben die Lesbarkeit und Wartbarkeit der Skripte erhalten. Der Aufwand für die einmalige Definition dieser Tests ist überschaubar und über die Gesamtlaufzeit eines Projekts ergibt sich ein enormer Kosten- und Zeitvorteil gegenüber manuellen Tests.

Sicherheitskritische Tests mit Failure Injections

Neben den funktionalen Tests gilt es für zahlreiche Anwendungen auch Prüfungen durchzuführen, die sich auf sicherheitstechnisch relevantes Systemverhalten konzentrieren. In sicherheitskritischen Tests werden dazu Fehlersituationen für das Steuergerät durch das Testsystem hergestellt – sogenannte Failure Injections. Ein Test lässt zum Beispiel mehrere Etagensensoren ausfallen und beobachtet die Reaktion des Steuergeräts. Grundsätzlich ist diese Art von Tests aufwändig in manuellen Testsituationen zu erzeugen. Möchte man tatsächlich an einem realen Aufbau die Verbindung zu den Sensoren trennen? Für ein HiL-System ist das einfach. Es kontrolliert alle Signale, die zwischen Testaufbau und Steuergerät hin und her wandern, und kann daher auch Signale unterdrücken oder manipulieren. Beispielsweise lässt sich der reale Wert eines Temperatursensors mit einem Offset manipulieren, um einen Fehler zu injizieren. Es lässt sich ein starkes Rauschen für einen Sensorwert einspielen oder das Klemmen eines mechanischen Schalters simulieren.

Im nachfolgenden Beispiel wird dem Steuergerät durch das Testsystem vorgespielt, dass sich die Kabine gleichzeitig in Etage 0 und 2 befinden müsste. Ein Szenario, das beispielsweise aufgrund eines Kabelbruchs zustande kommen kann – das Steuergerät soll diesen Fehler erkennen und sich abschalten.

test step 1:

{

// Simulate the cabin is in two different levels

set CTRL_DO_FLOOR_LEVEL_0_SENSOR to ON

after 500 [ms]:

set CTRL_DO_FLOOR_LEVEL_2_SENSOR to ON

// Check if error handling catches this

within 0 [ms] .. 100 [ms]:

expect CTRL_DI_ERROR_LIGHT => ON

wait 2 [s]

}

In einem weiteren Beispiel wird durch das Testsystem der Wert des Temperatursensors am Motor manipuliert. Nach 4 Sekunden wird ein kleiner Offset auf das Signal gegeben. Das Steuergerät soll darauf reagieren und den Motor nun mit weniger Leistung laufen lassen. Nach 8 Sekunden wird ein großer Offset auf das Signal gegeben. Darauf soll der Motor stoppen und es soll ein Fehler signalisiert werden.

ccd

initial conditions:

{

// Drive elevator to level 0, close doors

//…

}

test step 1:

{

// Press button

set CTRL_DO_FLOOR_LEVEL_2_BUTTON to ON

after 500 [ms]:

set CTRL_DO_FLOOR_LEVEL_2_BUTTON to OFF

// Inject small motor over temperature

after 4 [s]:

set CTRL_AI_MOTOR_TEMPERATUR to OFFSET 20

within 0 [s] .. 1 [s]:

expect CTRL_AI_MOTOR_SPEED = SLOW

// Inject high motor over temperature

after 8 [s]:

set CTRL_AI_MOTOR_TEMPERATUR to OFFSET 60

within 0 [s] .. 1 [s]:

expect CTRL_AI_MOTOR_SPEED => OFF

expect CTRL_DI_ERROR_LIGHT => ON

}

Auch in diesem Test wird das erwartete Verhalten über die „expect“-Anweisungen abgefragt. Er schlägt fehl, sobald ein expect nicht erreicht wird. Der Unterschied im Vergleich zum funktionalen Test ist, dass das Setzen der Stimuli an einem Sensor geschieht, der bei einem aufgebauten realen Prüfling von außen schwer erreichbar ist. Der Wert dieser sicherheitskritischen automatischen Systemtests lässt sich für ein Produkt nicht hoch genug bewerten. Die Arbeitszeit eines Testers sollte aber nicht ausschließlich für die Durchführung von Tests verschwendet werden, sondern er sollte seine Expertise dazu einsetzen, eine gute Balance zwischen großer Testabdeckung und Vermeidung überflüssiger Tests zu finden.

Zum Fahrstuhl-Demonstrator von Razorcat gibt es auf Github ein Repository. Dort finden sich Teilelisten, Baupläne, Verdrahtungspläne, Detailfotos, Konfigurationsdaten, CCDL-Prozeduren und der Code des Steuergeräts. Die Inhalte dort werden bei Bedarf aktualisiert. Alle Interessierten sind dazu eingeladen, ihre Beiträge hier einfließen zu lassen. Das Gesamtsystem bietet sich etwa für Hochschulen als Plattform für Systemtests und Anlagensteuerung an.

(ku)