K.I.-basiertes Testing und Robot Process Automation

Bisher blieben K.I.-basierte Ansätze bei der Durchführung komplexer Manöver oder beim Testen im Reich von Science Fiction und weitab jeder Umsetzung für das Engineering. Dabei sind die Herausforderungen durch die wachsende Komplexität der Systeme in diesem Bereich gerade in den letzten Jahren um ein Vielfaches gestiegen. ESG Mobility beschreibt eine zweigeteilte Toollandschaft für den Einsatz im Testprozess.

Bild von Daniel Isemann

Daniel Isemann

Data Science Professional

10.03.20

Ca. 10 min

Sharing is caring!

Komplexe Interaktionen automatisieren

Je komplexer das System, je mehr Entscheidungen vom Fahrzeug allein getroffen werden und je mehr Interaktionen zwischen den verschiedenen Steuergeräten notwendig sind, um Fahrmanöver durchzuführen, desto größer ist die Herausforderung, diese komplexen, vernetzten Systeme vorab zu testen. Dieser intuitive Dreisatz bedarf keiner Erklärung. Sehr wohl bedarf es aber einer Erklärung, wie das Testing für diese Systeme in der Zukunft und im praktischen Alltag aussehen soll. Kostenseitig kann dies nicht im gleichem Maßstab mitwachsen wie die Anforderungen an das System. Es bedarf neuer, smarter Lösungen für das Komplexitätsproblem. Eine solche Lösung stellt das K.I.-basierte Testing dar. Um diese Herausforderung im praktischen Testingalltag zu lösen, haben die Machine-Learning- und Testing-Domänen-Experten der ESG Mobility zusammen mit den IoT- und Robotics-Fachleuten von BotCraft eine zweigeteilte Toollandschaft entwickelt, die zukünftig das sogenannte End-to-End-Testing realisieren soll: Ein vollautonomer Testablauf eines beliebigen Produkts vom Testauftrag über die Testdurchführung bis hin zur Fehleranalyse (BILD 1). In einem ersten Schritt setzt diese neue Testing-Toollandschaft auf einen Ansatz, der als Robot Process Automation (RPA) bekannt ist. Es gilt, die komplexen Interaktionen zwischen vorhandenen Planungssystemen, Testsystemen, Hardware und Produktkonfigurationen über Bots und Microservices zu automatisieren. Der nachfolgende Schritt konzentriert sich auf die Unterstützung bei der Analyse der gefundenen Fehlerbilder durch eine leistungsstarke künstliche Intelligenz.

EFFIZIENZ ERHÖHEN

Der Blick auf den Nutzen des neuartigen Ansatzes lässt sich am besten be werten, wenn man den Status Quo der heutigen Produktund Systemabsicherung analysiert. Um ein System vollständig zu testen gilt es – vereinfacht dargestellt – zunächst, die relevanten Testfälle für einen definierten Testauftrag aufzubauen. Als nächstes wird der sogenannte Hardware-in-the-Loop(HIL)-Prüfstand abhängig vom Prüfauftrag konfiguriert. Dieser simuliert die ge wünschte Fahrzeugumgebung, angepasst auf die exakte Produktvariante. Nun muss die zu prüfende Software auf die Steuergeräte portiert und der Test zur Ausführung angemeldet werden. Ein Schedulingsystem sorgt dafür, dass der Testlauf zu einem optimalen Zeitpunkt durchgeführt wird. Was in der Theorie noch recht übersichtlich erscheint, hat bei den hochkomplexen Systemen im Fahrzeug schwere Auswirkungen: Der HIL muss über unzählige Ländereinstellungen verfügen, denn die Hardware ist nach Regionen vollkommen unterschiedlich aufgebaut. Dazu kommen Abhängigkeiten durch unterschiedliche Modellvarianten. Die Steuergerätesoftware ist ebenso in un zähligen Varianten und Versionen verfügbar. Zu guter Letzt sind auch die Umgebungszustände des Tests an sich veränderbar. Die Abhängigkeiten unter den Systemen sind so hoch, dass kleinste Fehler im Setup den jeweiligen Test un brauchbar machen. Zudem müssen bei jedem Testsetup heute noch manuell Grundeinstellungen nachkonfiguriert werden, was zu einer geringen Auslastung der Prüfstände von unter 70% führt. Ein Wert, der vor den erwähnten Herausforderungen kaum tragbar ist und ein RPA im Automotive Testing interessant macht.

RPA IM AUTOMOTIVE TESTING

RPA im Automotive Testing ist nicht gänzlich unbekannt, wird stellenweise in vereinfachter Form als Makro eingesetzt und hat sich in anderen Branchen bereits durchgesetzt. So sind heute Bots, und nichts anderes ist RPA, zum Beispiel dafür verantwortlich, dass E-Mails automatisiert nach Schlüsselwörtern untersucht werden, in der richtigen Abteilung landen, in der Buchhaltung automatisch Überweisungen auslösen und abschließend Bestätigungen verschicken. Nur so lässt sich mancher Prozess noch wirtschaftlich darstellen. Im Automotive Testing gibt es intelligente Bots noch nicht, denn die interagierenden Systeme sind weitaus komplexer und die Schnittstellen weniger standardisiert. Wo beispielsweise in der Versicherungsindustrie lediglich die Bürosoftware Outlook mit Excel, einem ERP-System und einer Datenbank kommunizieren muss, ist es im Testing ein beliebiger Mix aus unterschiedlich konfigurierter Hardware, Prüfständen und vielen Testsystemen – jede Komponente mit ihrer eigenen Connectivityphilosophie.

AUTOMATISIERUNG KANN ERHEBLICH KOSTEN SPAREN

Welches Potenzial allein die Automatisierung des Testing mit sich bringt, kann man am zukünftigen Prozess gut ablesen: Der Bot erkennt automatisch, dass eine neue Software für ein Steuergerät verfügbar ist. Er stellt anschließend alle notwendigen Parameter zusammen, wählt die hierfür notwendigen Testfälle aus, lädt weitere Dateien, synchronisiert sich mit der verfügbaren Testsoftware, aktiviert über eine Art Multiplexer die richtige Konfiguration des HIL und stößt den Test über einen Scheduler an. Die entscheidende Zutat, um einen Bot zum Leben zu erwecken, ist die nahtlose Connectivity über alle Bausteine hinweg. Hierfür war es nicht nur erforderlich, unzählige Schnittstellen zwischen den einzelnen Systemen, Tools, Datenbanken und der Hardware zu entwickeln, was bei den hochtechnischen und komplexen Abläufen und dem dafür notwendigen Ingenieurs-Know-how und Fahrzeugwissen allein schon eine Herkulesaufgabe war. Auch war es nötig, eine übergeordnete Funktionssprache zu entwickeln, mit der sich alle Bausteine zusammenschalten können. Das Ergebnis ist ein anpassungsfähiger Software stack, dessen Business Logic aus einer Library aufgebaut ist und lediglich eine kundenspezifische Konfiguration benötigt. So lassen sich alle Testingpipelines individuell auf die Bedürfnisse der Hersteller anpassen. Die extreme Parametrisierbarkeit der Systeme ermöglicht es nun, die hohe Produktvarianz zur Laufzeit vollständig abzutesten. Mit Hilfe der Bots lassen sich beispielsweise sowohl alte als auch parallel die neuen Stände der Gerätesoftware testen, die Ländereinstellungen hinzunehmen und alle verfügbaren Modelle in automatisierten Testläufen abprüfen. Dies geschieht rund um die Uhr, denn das Erkennen eines gescheiterten Testlaufs, die Analyse der Netzwerkprobleme oder des abgestürzten Prüfstands übernimmt der Bot, der die notwendigen Resets selbstständig einleitet. Nicht der menschliche Tester entscheidet über die Testplanung, sondern ein intelligenter Scheduler übernimmt die Steuerung und sorgt für eine optimale Auslastung der Prüfhardware. Die Overall Equipment Effectiveness lässt sich somit von den heute üblichen 70% auf über 90% steigern. Zudem sinkt der Personalaufwand im Testing um etwa 30% bei steigender Testabdeckung, Testtiefe und Qualität. In Zeiten schwindender Produktmargen und erstarkendem, internationalem Wettbewerb ist das ein relevanter Kostenhebel für Hersteller.

GANZHEITLICHES TESTEN

Bei der Testinglandschaft geht es auch darum, die in der Testphase gefundenen Produktfehler zu analysieren, so dass diese zeitnah gelöst werden können. Auch hier lohnt zunächst der Blick auf den Status Quo, um besser verstehen zu können, welche Vorteile sich aus einer leistungsfähigen K.I. ergeben. Liefert ein Testfall ein negatives Ergebnis („Failed“), ist es Aufgabe des Testingenieurs, die Ursachen dafür zu finden. Dabei können die Ursachen der Fehler manchmal sogar abenteuerlich erscheinen. Ob beispielsweise ein Strom ausschlag im Energiebordnetz, ein falsches Signal von einem Steuergerät oder der Prüfstand selbst mit einer gerade um wenige Millisekunden gefallenen Latenz der Auslöser war, lässt sich auf den ersten Blick nicht erkennen und zieht oft eine mühevolle Detektivarbeit nach sich. Dabei untersuchen die Fahrzeugexperten die aufgezeichneten Datenströme aller Signale aus dem Bordnetz. Mit ihrem Fahrzeugwissen und der langjährigen Erfahrung können sie schließlich die Ursachen erahnen. In frühen Phasen der Produktentwicklung sind 50% gescheiterte Tests keine Seltenheit. In absoluten Zahlen bedeutet dies meist einige Tausend Testfälle, für die es mehrerer Experten bedarf, um in angemessener Zeit die Ursachen zu finden. Testfälle und deren zugrundeliegende Funktionen werden für die Analyse manuell nach Kategorien geschnitten und den Funktionsexperten zugeordnet. Die Fehlerbilder halten sich jedoch nicht an diese Kategoriegrenzen und so ist es wenig verwunderlich, dass ähnliche Fehler von unterschiedlichen Personen parallel bearbeitet werden, ohne voneinander zu wissen. Die begrenzten Möglichkeiten der menschlichen Kommunikation erlauben es nicht, diese Fehler zu einem frühen Zeitpunkt ganzheitlich, system- und testübergreifend zu betrachten und nach Mustern zu suchen.

MIT K.I. ZUR ZWEITEN PHASE

Anstelle der starren Kategoriegrenzen verwenden die Experten der ESG Mobility Machine Learning, um mit modernen Clusteranalyseverfahren nach gleichartigen Ereignissen zu suchen, die zu den entsprechenden Fehlern führten. Vereinfacht dargestellt werden die vorhandenen Testdaten und deren Ergebnisse auf der Basis ihrer vielfältigen Eigenschaften in einen hochdimensionalen Vektorraum zu transformiert (BILD 2).

In dieser Punktmenge werden Zentren gebildet und abgeschätzt, welche Punkte als benachbart gelten. Diese Nachbarschaft kann als eine Approximation eines Ähnlichkeitsmaßes gesehen werden. Hier ist zudem Fahrzeug-Domänenwissen gefragt, denn nicht jede Ähnlichkeit macht sofort Sinn. Den in einem unüberwachten Lernverfahren identifizierten Clustern können immer weitere neue Testergebnisse zugeordnet und gelabelt werden. Mit steigender Datenmenge nimmt auch die Treffsicherheit des Lernverfahrens zu und stabilisiert den Gesamtansatz zunehmend. Nachweislich lassen sich auf diese Weise Genauigkeiten von über 90% in der Klassifikation von Fehlerbildern erreichen. Aus Beispielen aus der angewandten Produkt- und Fahrzeugentwicklung lässt sich ableiten, dass auf diese Weise Ablösungen der manuellen Tätigkeiten in Höhe von oftmals über 20.000 Stunden pro Jahr keine Seltenheit sind.

VERSCHIEDENE TESTPIPELINES – GLEICHBLEIBENDE STRATEGIE

Auch wenn einige Teile der entwickelten Testingpipeline auf kundenspezifische Anforderungen angepasst werden müssen, ist schon jetzt ersichtlich, welches Potenzial im K.I.-basierten Testing steckt. Vor dem Hintergrund der Komplexitätsexplosion durch hochautonome Assistenten und stark vernetzte Kundenfunktionen wird klar, dass sich nur mit diesem Setup eine notwendige Testabdeckung mit vertretbarem Aufwand in den Griff bekommen lässt. 

Professional Daniel Isemann

Daniel Isemann

Data Science Professional

Dr. Daniel Isemann ist Head of Data Science and Artificial Intelligence, dessen kluge Lösungen er seit Jahren in den Dienst der Cognizant Mobility stellt.