Autonome Fahrzeuge verändern weit mehr als das eigentliche Fahren. Sie stellen auch grundlegend infrage, wie Fahrzeuge künftig getestet und validiert werden müssen.
Mit dem Wandel vom klassischen Fahrzeug hin zum softwaredefinierten, autonomen System verändert sich zugleich die Bedeutung des Testens. Nach Produktionsstart, Typfreigabe oder Markteinführung ist ein Fahrzeug nicht mehr einfach „fertig“. Softwarestände entwickeln sich weiter, Funktionen kommen hinzu, Einsatzgebiete werden erweitert und regulatorische Anforderungen verändern sich.
Jede einzelne dieser Anpassungen kann Sicherheit, Fahrzeugverhalten und Freigabestatus beeinflussen.
Für Testing-Organisationen entsteht dadurch eine neue Realität:
Bei autonomen Fahrzeugen endet Testing nicht länger mit SOP, Typfreigabe oder Markteinführung. Es wird zu einem festen Bestandteil des laufenden Flottenbetriebs.
Vom Entwicklungsprojekt zum kontinuierlichen Validierungsprozess
Im klassischen Fahrzeugentwicklungsprozess gibt es einen vergleichsweise klar definierten Endpunkt.
Ein Fahrzeug wird entwickelt, erprobt, validiert und schließlich freigegeben. Selbstverständlich folgen später noch Änderungen und Modellpflegen. Trotzdem orientiert sich der Testing-Prozess stark an festen Entwicklungsphasen und definierten Meilensteinen.
Bei autonomen Fahrzeugen greift dieses Modell zunehmend weniger.
Der Grund: Das Verhalten des Fahrzeugs wird maßgeblich von Software geprägt. Und diese Software entwickelt sich kontinuierlich weiter. Sensorik und Algorithmen erhalten Updates. Neue Funktionen werden ergänzt. Fehler werden behoben. Auch die Operational Design Domain – also der Bereich, innerhalb dessen das autonome System betrieben werden darf – kann wachsen.
Mit jeder wesentlichen Veränderung stellt sich dieselbe Frage von Neuem:
Ist das System auch unter den veränderten Bedingungen weiterhin sicher und spezifikationskonform?
Testing entwickelt sich dadurch von einer einzelnen Phase im Entwicklungsprozess zu einer wiederkehrenden Aufgabe über den gesamten Lebenszyklus hinweg.
Eine Flotte ist nicht einfach derselbe Test in größerem Maßstab
Wenn autonome Fahrzeuge skalieren, steigt nicht nur ihre Anzahl.
Vor allem wächst die Menge der Kombinatione naus Softwarestand, Fahrzeugkonfiguration, Einsatzgebiet, Umgebungsbedingungen und regulatorischem Kontext, die kontrolliert werden müssen.
Eine autonome Flotte bewegt sich schließlich nicht in einem einheitlichen Testumfeld.
Innenstadtverkehr bringt andere Anforderungen mit sich als Autobahnabschnitte oder Vororte. Baustellen verändern bereits bekannte Situationen. Wetter, Straßenzustand und Verkehrsverhalten schwanken. Regionale Vorgaben können voneinander abweichen. Gleichzeitig kommen neue Einsatzgebiete hinzu.
Skalierung wird dadurch schnell zu einem Komplexitätsthema.
Exakt hier verändert sich die Aufgabe des Testmanagements.
Die zentrale Frage lautet nicht länger nur:
Kann dieses Fahrzeug freigegeben werden?
Stattdessen rückt zunehmend diese Frage in den Mittelpunkt:
Welche Version wurde für welches Einsatzgebiet ,in welcher Konfiguration, unter welchen Bedingungen und mit welchem Ergebnis validiert?
Jedes Update kann einen neuen Validierungszyklus anstoßen
Software-defined Vehicles machen es möglich, Funktionen auch nach dem Produktionsstart weiterzuentwickeln. Darin liegt einer ihrer größten Vorteile.
Für Testing-Organisationen bringt genau das jedoch zusätzliche Dynamik mit sich.
Ein neues Software-Release kann das Fahrverhalten verändern. Ein aktualisiertes Wahrnehmungsmodell kann weitere Szenarien erkennen. Geänderte Entscheidungslogik kann bekannte Situationen anders bewerten. Wird ein Betriebsgebiet erweitert, kommen wiederum neue Verkehrssituationen hinzu.
Nicht jede Änderung macht automatisch eine vollständige Wiederholung sämtlicher Tests notwendig.
Für jede relevante Änderung braucht es jedoch eine belastbare Antwort darauf, welche Tests erneut durchgeführt werden müssen und aus welchem Grund.
Deshalb entwickelt sich Testing immer stärker zu einem kontinuierlichen Regelkreis:
Änderung → Risikobewertung → Testplanung →Durchführung → Auswertung → Freigabe → Betrieb → neue Erkenntnisse → nächsteÄnderung.
An die Stelle eines einmaligen Freigabeprozesses tritt damit ein fortlaufender Validierungsprozess.
Auch Anforderungen bleiben nicht unverändert
Nicht allein die Fahrzeuge entwickeln sich nach dem Produktionsstart weiter.
Auch technische Vorgaben, Sicherheitsanforderungen, Nachweispflichten und regulatorische Rahmenbedingungen können sich im Laufe der Zeit verändern.
Für Testing-Organisationen kommt damit eine weitere Ebene der Komplexität hinzu. Ein Test kann technisch weiterhin korrekt durchgeführt worden sein, während gleichzeitig geprüft werden muss, ob die zugrunde liegenden Anforderungen noch dem aktuellen Stand entsprechen.
Das betrifft zum Beispiel:
- neue oder geänderte Sicherheitsanforderungen,
- angepasste Freigabekriterien,
- zusätzliche Nachweispflichten,
- neue Einsatzgebiete,
- veränderte Fahrzeugkonfigurationen,
- aktualisierte Softwarestände.
Auch die Nachweisführung wird dadurch zu einer kontinuierlichen Aufgabe.
Es genügt nicht mehr, belegen zu können, dass ein Test stattgefunden hat. Genauso relevant ist, auf welcher Anforderungsbasis er durchgeführt wurde, für welche Konfiguration er galt und unter welche nBedingungen seine Ergebnisse gültig waren.
Die eigentliche Herausforderung liegt in den Zusammenhängen
Bei autonomen Flotten entsteht deshalb eingewaltiges Informationsproblem.
Testfälle befinden sich in einem System. Fahrzeugkonfigurationen werden an anderer Stelle geführt. Softwarestände liegen in separaten Systemen. Findings landen im Ticketing. Messdaten werden auf weiteren Plattformen gespeichert. Freigaben werden dokumentiert. Anforderungen verändern sich fortlaufend.
Trotzdem müssen Teams jederzeit nachvollziehen können, welche Tests zu welchem Zeitpunkt für welche Konfiguration relevant waren.
Solange Testing überwiegend in einzelnen Entwicklungsprojekten stattfindet, lässt sich ein Teil dieser Fragmentierung organisatorisch noch auffangen.
Bei dauerhaft wiederkehrenden Validierungszyklen stößt dieser Ansatz jedoch zunehmend an seine Grenzen.
Tritt eine Änderung auf, muss schließlich sofort erkennbar sein:
Welche Fahrzeuge betrifft sie? Welche Softwarestände sind relevant? Welche Tests hängen damit zusammen? Welche Ergebnisse liegen bereits vor? Welche Issues sind noch offen? Welche Anforderungen wurden geändert? Und welche Nachweise müssen deshalb aktualisiert werden?
Entscheidend ist daher nicht allein, immer mehr Testdaten zu erzeugen. Entscheidend ist, die Beziehungen zwischen diesen Informationen dauerhaft transparent und beherrschbar zu halten.
Hier wandelt sich die Rolle einer Testing-Plattform
Für uns bei Softwarehelden ist genau diese Entwicklung besonders relevant.
Mit Cluu Assisted Testing führen wir Testplanung, Ressourcenmanagement, Durchführung, Dokumentation, Analyse und Issue Tracking in einem durchgängigen Testing-Workflow zusammen.
Für eine kontinuierliche Validierung wird diese Vernetzung zum entscheidenden Faktor.
Ein Test sollte nicht bloß als abgeschlossenes Dokument abgelegt werden. Er muss mit Anforderungen, Fahrzeugen, Konfigurationen, Softwareständen, Ergebnissen, Findings und Freigaben verknüpft sein.
Verändert sich ein Bestandteil dieses Netzwerks, muss klar erkennbar bleiben, welche weiteren Elemente davon berührt werden.
Dadurch entwickelt sich auch das Testmanagement weiter:
vom Management einzelner Testkampagnen hin zurSteuerung eines dauerhaften Validierungsprozesses.
Damit steigen zugleich die Anforderungen an Testing-Software. Es reicht nicht mehr, Tests lediglich zu planen und Ergebnisse festzuhalten. Zunehmend zählt die Fähigkeit, Veränderungen transparent abzubilden und ihre Auswirkungen über Systeme, Konfigurationen und Teststände hinweg nachvollziehbar bewerten zu können.
Testing wird Bestandteil des Flottenbetriebs
Die industrielle Einführung autonomer Fahrzeuge stellt daher nicht nur neue Anforderungen an Sensorik, KI oder Fahrzeugarchitekturen.
Auch die Organisation hinter dem Fahrzeug verändert sich grundlegend.
Wer autonome Fahrzeuge im realen Betrieb einsetzt, braucht eine Infrastruktur, mit der kontinuierliche Änderungen kontrolliert getestet, sauber dokumentiert und zuverlässig freigegeben werden können.
SOP markiert dann nicht länger das Ende des Testbetriebs.
Auch die Typfreigabe bildet nicht mehr den letzten großen Validierungsmeilenstein.
Stattdessen markieren beide den Übergang in eine neue Phase: einen laufenden Betrieb, in dem Software, Einsatzgebiete, reale Erfahrungen und regulatorische Anforderungen immer wieder neue Validierungszyklen anstoßen.
Das autonome Fahrzeug wird zu einem System, das sich dauerhaft weiterentwickelt. Damit wird auch Testing zu einem kontinuierlichen Prozess.
Für Testing-Organisationen ist das eine erhebliche Herausforderung – zugleich eröffnet es die Möglichkeit, Testprozesse ebenso vernetzt und softwaredefiniert aufzubauen wie die Fahrzeuge, deren Sicherheit sie gewährleisten sollen.
