Wie aus einem Testproblem ein Roboter für die automatisierte HMI- und Touchpanel-Prüfung auf realer Industriehardware wurde.
Eine berechtigte Frage: Warum entwickelt ein Unternehmen für Mobile- und Softwarelösungen plötzlich Roboter?
Die ehrliche Antwort: Das war so nie geplant. Wir sind lediglich einem konkreten Testproblem Schritt für Schritt nachgegangen – bis am Ende ein mechanischer Arm daraus wurde.
Viele unserer Kunden und Partner kommen aus der Industrie. Für sie entwickeln wir Anwendungen, die mit Hardware kommunizieren. Sehr häufig gehört dazu auch eine direkte Interaktion an der Maschine – typischerweise über ein Touchpanel. Gleichzeitig arbeiten wir eng mit Partnern zusammen, die Firmware für Steuerungen und Human-Machine Interfaces (HMIs) entwickeln, und unterstützen sie auch beim Testen dieser Lösungen.
Für das Testen solcher Systeme sind Simulatoren oder modifizierte Maschinen nach wie vor der Standard. Genau das hat mich schon immer gestört.
Von einem echten End-to-End-Test kann kaum die Rede sein, wenn ein wesentlicher Bestandteil des Systems durch etwas ersetzt wird, das die reale Komponente nur nachbildet. In solchen Fällen testet man nicht das tatsächliche Produkt, sondern dessen Simulation.
Wer schon einmal erlebt hat, dass ein Gerät im Simulator alle Tests problemlos besteht und sich auf der echten Maschine plötzlich anders verhält, weiß genau, was ich meine.
Für einen wirklich durchgängigen End-to-End-Test braucht es also einen echten Finger, der einen echten Bildschirm auf einem echten Gerät bedient. Und das bedeutet: manuelles Testen.
Genau hier stößt man allerdings schnell an Grenzen. Menschen werden müde und übersehen nach vier Stunden Dinge, die ihnen zu Beginn noch aufgefallen wären. Und ich habe bisher noch keinen Kollegen getroffen, der bereit war, dieselbe Abfolge von Taps 72 Stunden lang zu wiederholen.
Ich habe gefragt. Niemand hat sich freiwillig gemeldet.
Dabei sind die Risiken auf dieser Ebene erheblich – das wissen Hersteller und Entwickler in der Industrie nur zu gut. Ein UI- oder Firmware-Fehler, der es bis ins Feld schafft, gehört zu den teuersten Fehlern, die einem Gerätehersteller passieren können.
Die Folgen reichen von Serviceeinsätzen und Updates auf bereits installierten Maschinen bis hin zu Rückrufen oder – in besonders kritischen Fällen – einer erneuten Zertifizierung.
Einen solchen Fehler im Labor zu entdecken, kostet vielleicht nur wenige Stunden. Wird er jedoch erst im Feld erkannt, entstehen Kosten in einer völlig anderen Größenordnung – verbunden mit einem erheblichen Vertrauensverlust.
Ich bin ein großer Fan von Automatisierung. Deshalb stellte sich für mich irgendwann ganz zwangsläufig die Frage:
Wie können wir Tests automatisieren und dabei die echte Maschine in den Test einbeziehen?
Bei Touchscreens braucht es im Grunde nichts Kompliziertes. Man braucht jemanden, der auf den richtigen Bereich des Bildschirms drückt und anschließend liest, was auf dem Display angezeigt wird. Das ist eigentlich schon die gesamte Aufgabenbeschreibung.
In der Welt der Automatisierung bedeutet „jemand“: ein Roboter.
Ich skizzierte die Idee und begann zu recherchieren, was es bereits gab. Es existieren Open-Source-Robotikprojekte, die genau dafür entwickelt wurden: auf Bildschirme zu tippen. Der pragmatische erste Schritt lag daher auf der Hand: Wir bauen eines dieser Systeme nach und lernen daraus.
Gesagt, getan. Und wir lernten vor allem, was es nicht konnte.
Wir starteten mit einem Design, das ursprünglich für Tests auf Smartphones gedacht war. Schon bald wurde jedoch klar, dass wir eine deutlich größere Variante benötigten – und dass wir das System grundlegend an die Anforderungen industrieller Touchpanels anpassen mussten.
Der erste Prototyp konnte zwar tippen, den Bildschirm jedoch nicht lesen. Dadurch war er nicht in der Lage festzustellen, ob die Anwendung tatsächlich das Richtige getan hatte.
Ein Roboter, der blind auf Tasten drückt, ist eine beeindruckende Demo – aber noch kein Testsystem.
Er konnte die reale Welt berühren, aber er konnte sie nicht überprüfen. Und genau diese Überprüfung war schließlich der eigentliche Zweck des Projekts.
Trotzdem war dieser erste Aufbau keineswegs umsonst. Im Gegenteil: Er hat uns sehr genau gezeigt, was wir tatsächlich brauchen – und was fertige Lösungen von der Stange nicht leisten können.
Also haben wir unseren eigenen Roboter gebaut – und uns ganz bewusst dafür entschieden, die Delta-Kinematik beizubehalten. Ein Delta-Roboter ist schnell, hat sich in der Praxis bewährt und macht die Konstruktion nicht unnötig komplex wie manch andere Roboterarchitektur.
Gerade beim Testen ist das entscheidend: Das Testwerkzeug selbst muss zuverlässig sein. Andernfalls verbringt man seine Zeit damit, den Tester zu debuggen, statt den eigentlichen Fehler im Gerät zu finden.
Die zweite Herausforderung war das Auslesen des Displays. Die Idee dahinter ist einfach – die Umsetzung allerdings keineswegs: Wir haben eine Kamera am Roboter montiert und eine visuelle Erkennung mit OCR integriert.
Damit kann der Roboter den Bildschirm so „sehen“ wie ein menschlicher Tester: Er führt eine Aktion aus, liest anschließend das Ergebnis vom Display ab und vergleicht es mit dem erwarteten Wert.
Eine Designentscheidung möchte ich dabei besonders hervorheben, weil sie dem aktuellen Trend bewusst entgegensteht: Sabotap verwendet keine selbstheilende Testautomatisierung.
Wenn sich beispielsweise ein Button von seiner erwarteten Position verschiebt, versucht das System nicht, ihn clever wiederzufinden und den Test einfach fortzusetzen. Stattdessen meldet Sabotap einen Fehler.
Denn bei einem Regressionstest eines industriellen Geräts ist ein Button, der plötzlich an einer anderen Stelle auftaucht, selbst der Fehler. Wir wollen solche Abweichungen erkennen – nicht geschickt umgehen.
Das dritte Puzzleteil schließt den Regelkreis: die Simulation von Sensorsignalen.
Viele Geräte, die wir testen, reagieren nicht nur auf Eingaben über die Benutzeroberfläche, sondern auch auf physikalische Größen wie Temperaturen oder digitale Signale. Dafür haben wir eine eigene Lösung entwickelt: Sabotap kann simulierte Sensordaten über standardisierte industrielle Protokolle an das zu testende Gerät übertragen – während der Roboter gleichzeitig die Benutzeroberfläche bedient.
Ein einfaches Beispiel: Der Roboter drückt „Heizung starten“, anschließend wird die simulierte Temperatur schrittweise erhöht und überprüft, ob sich die Anzeige des Geräts entsprechend verändert.
Damit entsteht ein vollständig automatisierter Systemtest, der laufen kann, während alle anderen längst schlafen.
Erstmals deckt der Test damit die komplette Realität des Geräts ab: die Benutzeroberfläche, die interne Logik und die physikalischen Eingangssignale, mit denen das Gerät in der realen Welt arbeitet.
Premiere auf der SPS 2025
Im November 2025 haben wir dieses Setup auf der SPS-Messe in Nürnberg vorgestellt.
Der Roboter hat sich dabei gut geschlagen – und damit gezeigt, dass unser Ansatz funktioniert: Ein automatisierter Tester, der nicht nur Software prüft, sondern ein industrielles Gerät so bedient und bewertet, wie es auch ein menschlicher Tester tun würde.
Die Gespräche auf der Messe waren letztlich wertvoller als die Demo selbst. Die wichtigste Erkenntnis daraus war: Damit Sabotap über ein einzelnes Projekt hinaus sinnvoll einsetzbar ist, muss sich die Software problemlos von einem Gerät auf das nächste übertragen lassen. Genau aus diesem Grund haben wir unseren Software-Stack überarbeitet.
Neues Projekt, neues Panel, neue Testfälle – dieselbe Plattform. Unser Ziel ist unverändert: Wir testen weiterhin das reale Gerät. Der Unterschied ist, dass wir nicht mehr bei jedem neuen Projekt von vorne beginnen müssen.
Sabotap ist heute einsatzbereit und lässt sich an die Anforderungen einzelner Kunden anpassen. Genauso sollte Hardware funktionieren, die für den Einsatz in der realen Welt entwickelt wird.
Natürlich sind weiterhin projektspezifische Anpassungen erforderlich, insbesondere bei der Sensorsimulation. Jedes Projekt bringt eigene Anforderungen mit sich. Ich halte es jedoch für sinnvoller, gezielt dort anzupassen, wo es notwendig ist, anstatt eine übermäßig komplexe Lösung zu entwickeln, die jede denkbare Variante abdecken soll. Andernfalls würden wir vermutlich noch jahrelang daran arbeiten, ohne etwas anderes zu tun.
Inzwischen haben wir Sabotap außerdem mit SaTI verbunden, unserem KI-Tool zur Prüfung und Erstellung von Anforderungen und Testfällen. Die Kombination haben wir bereits mit Sabotap-Szenarien getestet – mit guten Ergebnissen.
Der Ablauf ist einfach: Anforderungen werden vorgegeben, daraus entstehen geprüfte Testfälle, der Roboter führt sie aus, und ein Mensch überwacht den gesamten Prozess.
SaTI hat jedoch seine eigene Geschichte. Darüber werde ich in einem zukünftigen Beitrag berichten.
Während der Entwicklung von Sabotap stieß ich auf eine weitere Herausforderung: Manche Touchpanels lassen sich nicht vom Gerät abnehmen, um sie in den Roboter einzubauen. Sie müssen direkt an der Maschine getestet werden – in ihrer realen Umgebung.
Da wir anspruchsvolle Probleme gerne lösen, arbeiten wir bereits an einem neuen Sabotap-Prototyp: einem Roboter, der das Display ausliest und mit der Maschine interagiert, während das Panel montiert bleibt. Die Grundidee bleibt dieselbe, wird jedoch konsequent weitergedacht: Wenn das Panel nicht ins Labor kommen kann, kommt der Test zum Panel.
Und wenn ein Roboter eine Maschine vor Ort bedienen kann, kann er mehr tun, als sie nur zu testen. Er kann die Maschine auch automatisieren und Aufgaben in meinem Auftrag ausführen – was, seien wir ehrlich, ebenfalls sehr reizvoll klingt.
Sabotap entstand aus einem einfachen Problem: Die für den Nutzer sichtbarste Ebene unserer Produkte war zugleich die am wenigsten automatisierte. Die übliche Lösung bestand darin, eine Nachbildung der Realität, statt der Realität selbst zu testen.
Heute haben wir einen Roboter, der rund um die Uhr tippt, sieht, simuliert und Berichte erstellt – ohne müde zu werden oder den Ablauf zu verändern. Jeder Fehler, den er im Labor entdeckt, ist ein Fehler, der nie den Weg in die Praxis findet.
Wenn Sie Geräte mit Touchscreens entwickeln und Ihnen diese Herausforderung bekannt vorkommt, senden Sie uns Ihr Testszenario. Wir sagen Ihnen offen, ob Sabotap dafür geeignet ist.
Und keine Sorge: Der Roboter wird nicht auf Sie tippen.
