Mit dem Remote Testlab lösen sich Automobilbauer von den bisherigen Beschränkungen physischer Hardware-Tests. Ortsunabhängige Testreihen werden möglich, Prototypen werden besser ausgelastet, Entwicklungszyklen werden beschleunigt.
Autos werden immer intelligenter, Connected Cars sind die Zukunft. Beispielsweise unterstützen sie ihre Fahrer mit wohlmeinenden Ratschlägen zur Verkehrssicherheit („Achtung! Hier gelten 50 Stundenkilometer Höchstgeschwindigkeit“) oder auch hinsichtlich des Service: „Ölwechsel und Inspektion sind in 3100 Kilometern fällig“. Human Machine Interfaces (HMI) sind die modernen Berührungspunkte zwischen Hersteller und Kunde und tragen damit wesentlich nicht nur zur Usability des Autos, sondern zum gesamten Markenerlebnis bei. Das wird aber getrübt, wenn das Display in einem Elektroauto zum Ölwechsel auffordert.
Möglicherweise geht solches als eine neue Form des „Infotainment“ durch – eine Head Unit oder ein Kombiinstrument im Fahrzeug, das Spaß versteht. Was in diesem Beispiel eher kurios daherkommt, kann in anderen Ausprägungen durchaus gefährlich werden – oder rechtliche Probleme erzeugen (zum Beispiel, wenn eine Betriebsanleitung nicht den gesetzlichen Anforderungen entspricht). Soft- und Hardware im Auto müssen einwandfrei funktionieren. Dabei geht es nicht nur um das beste Erlebnis für die Kunden. In der Tat ist eine einwandfreie Funktionalität – insbesondere, wenn Autos immer stärker „software-definiert“ werden – eine Voraussetzung für eine Zulassung eines Fahrzeugs.
Nicht umsonst stecken Automobilbauer große Energie in Tests ihrer Hardware und Software. Dafür etabliert sich immer mehr ein Shift-Left-Ansatz. Je früher Fehler erkannt werden, desto früher können sie behoben werden und desto weniger Aufwände (und Kosten) entstehen. Ein früh entdeckter Fehler ist ein guter Fehler. Ein spät entdeckter Fehler … lässt Entwicklungsingenieure tief seufzen – und das meistens sehr lautstark. Die Auswirkungen auf die Reputation und das Image sind meist noch viel größer als der eigentliche Fehler in der Maschine selbst.
In frühen Testphasen lässt sich das Zusammenspiel zwischen Hardware und Software noch virtualisieren, aber wenn das Fahrzeug-Entwicklungsprojekt vorangeschritten ist, kommt irgendwann der Zeitpunkt, an dem echte Hardware in Verbindung mit der Software getestet werden muss. Und spätestens da zeigt sich meist, dass die reale Hardware sich nicht immer entsprechend des Entwicklerwunschs verhält. Theorie trifft Praxis. Die Tests an und mit der realen Hardware sind damit ein essenzieller Beitrag zur Qualitätssicherung innerhalb der Fahrzeugentwicklung.
Klassisch werden die Hardware-Komponenten mit speziellen Tools in Testlabors physisch auf Herz und Nieren geprüft. Dabei ist eine manuelle Abarbeitung von Testfällen und damit einhergehend eine vor-Ort-Präsenz unabdingbar. Reisen oder das Errichten eines entwicklungsnahen Teststandorts erzeugen erhebliche Kosten.
Doch während Ingenieure die Software beliebig oft multiplizieren können (solange sie die lizenzrechtlichen Vorgaben beachten), steht komplexe Infotainment-Hardware wie eine Head Unit, Rear Seat Entertainment oder Tablets im Font in der Testphase nicht in beliebiger Anzahl zur Verfügung. Tatsächlich gibt es in der Regel pro Entwicklungsreihe höchstens eine Handvoll Prototypen, eine rare Ressource also. Das führt zu einem Ungleichgewicht – denn dieser begrenzten Zahl von Prototypen beim Hersteller steht eine Fülle notwendiger Tests gegenüber.
Im traditionellen Testlab müssen die Ingenieure dann ihre Ellenbogen ausfahren, um „ihre“ Testzeit mit den Prototypen zu bekommen. Das erinnert ein wenig an das traditionelle „bitte ziehen Sie eine Nummer und warten Sie, bis sie aufgerufen werden“. Es ist leicht nachvollziehbar, dass derartige Testreihen gut organisiert werden müssen – und dass keine Fehler auftreten dürfen. Denn das würde die Entwicklungszeit verlängern.
In einer Ära, in der allerorten von Digitalisierung gesprochen wird, Autos digitale Services erhalten und sogar der Autokauf digital wird, warum sollten da Hardware-Tests eine der letzten Bastionen der rein physischen Welt bleiben?
Wenn die Corona-Pandemie uns eines gelehrt hat, dann das, dass viele Arbeiten auch remote wahrgenommen werden können. Und tatsächlich böte ein „Remote Testlab“ neben einem nachhaltigen Infektionsschutz eine Fülle weiterer Vorteile, um physische Limits vielleicht nicht zu umgehen, aber doch zu erweitern. Das Remote Testlab würde die untersuchte Hardware oder den Zugriff darauf nicht nur simulieren, sondern das Arbeiten mit der echten Hardware ermöglichen. Auch Remote-Usability-Tests wären möglich. In unserem Beispiel müsste die Head Unit für das Connected Car über die typischen Kanäle bedienbar sein: Audio und Touch – und zwar aus der Ferne. Dazu ist selbstverständlich auch ein Videostream essenziell.
Also ab mit dem Testlab ins Web. Gemäß Datenschutz und -sicherheit versteht sich. Im Prinzip besteht eine solche Lösung aus vier Komponenten.
1. Auf der Seite des Users muss ein Remote Client zur Verfügung stehen, über den der Ingenieur Zugriff auf die Head Unit hat.
2. Auf der anderen Seite ist das Head Unit Testlab mit der echten Head Unit Hardware. Sie ist über ein CAN Bus Interface und einen Framegrabber mit dem Head Unit Computer verbunden. Über einen Steuerroboter können echte Touch- und Wischgesten erzeugt und authentische Usability-Tests simuliert werden.
3. Zwischen dem Testlab und dem Remote Client braucht es eine Orchestrierungsschicht. Sie enthält eine Datenbank, einen Applikationsserver und sorgt für das Web Signaling.
4. Eine Over-the-Air-Versorgung ermöglicht den Ingenieuren, dass sie Updates der Software auf der Head Unit einspielen können.
Damit steht die Head Unit nach wie vor in ihrem Testlab, aber die Ingenieure des Unternehmens müssen nicht mehr vor Ort sein, um sie zu testen. Der Applikationsserver in der Orchestrierungsschicht kann nun als eine Art Testkoordinator fungieren, der die Testzeiten zentral verwaltet.
Durch das Remote Testlab bleiben Berg und Prophet da, wo sie sind – und kommen trotzdem zueinander. D.h. der Zugriff auf die Head Unit bzw. die Hardware wird ortsunabhängig. Testingenieure können den 24/7-Ansatz optimal ausnutzen und Zeit sparen, indem sie Testperioden verkürzen. Während Kollegen in Indien Feierabend machen, können unmittelbar im Anschluss Europäer die Tools zum Testen nutzen, gefolgt von den US-Teams. Eine Hardware kann so effizienter genutzt werden. Oder anders gesagt: Mit einer Hardware-Einheit kann in kürzerer Zeit häufiger getestet werden. Das beschleunigt die Entwicklung des Fahrzeugs. Oder es werden einfach weniger Prototypen gebraucht.
Zugleich bedient dieser Ansatz aber auch die Lokalisierung bzw. Internationalisierung von Fahrzeug und Software. Unternehmen können das Produkt einfacher an den jeweiligen Markt anpassen, obwohl Komponenten eines Tier-1-Partners nicht immer auch im selben Markt produziert werden.
Ein Thema, das man eigentlich gar nicht mehr zu erwähnen braucht: Auf der Habenseite steht ein bisweilen erheblicher Beitrag zu Nachhaltigkeitszielen von Unternehmen. Reisezeiten und die damit verbundenen Kosten entfallen. Wegen des zentralen Betriebs muss weniger Hardware in der Entwicklung produziert und versandt werden. Unser Testlab bei T-Systems läuft darüber hinaus sogar mit 100 Prozent grünem Strom auf der Open Telekom Cloud .
Solange Hardware sich nicht beliebig klonen lässt oder Digital Twins noch nicht den entsprechenden Reifegrad erreicht haben, bietet das Remote Testlab das Remote Testlab ein wertvolles Tool und bietet eine starke Alternative zu „Testen vor Ort“. Sie befreit Testteams von der Notwendigkeit, sich mit der Hardware „persönlich zu treffen“. Damit werden Prozesse in Zukunft deutlich flexibler und schneller und Hersteller von Fahrzeugen können effizienter arbeiten.
