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.

Testsystem

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

Testsystem

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.

Testsystem

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.

Seite 1 von 212