So wird das autonome Auto schneller marktreif

Aufgrund eines Posts von Stefan Bratzel, Prof. Dr. zum Thema "Die n?chste Stufe des automatisierten Fahrens erm?glichen" einer Studie, die das Fraunhofer IAO und des Center of Automotive Management (CAM) Anfang 2024 ver?ffentlicht hatten, hatte ich mir in meinem Post zum Thema Skalierbarkeit des automatisierten und vernetzten Fahrens meine Gedanken dazu gemacht, wie wir mit unserer Arbeit im Forschungsprojekt SofDCar dazu beitragen k?nnen.

Bei der Entwicklung eines neuen, disruptiven Produktes wie das autonom fahrende Fahrzeug müssen etliche weitere Technologieinnovationen hinzukommen, um schliesslich die Marktreife und den Durchbruch zu erreichen. Beim Thema autonomous driving ist die Sicherheit (safety) das oberste Entwicklungsziel, und diese muss sowohl für alle Passagiere im Fahrzeug als auch für alle anderen Verkehrsteilnehmer zu jeder Zeit und unter jeder m?glichen Randbedingung gew?hrleistet werden k?nnen. Dieses Ziel scheint so ambitioniert und unerreichbar, dass alle bislang unternommenen Schritt hin zu diesem Olymp des autonomen Fahrens nicht ausreichend waren, um diesen Anforderungen zu genügen.

Wenn man etwas tiefer in das Thema einsteigt, so kommt man unweigerlich auf eine Methode die sich Operational Design Domain (ODD) nennt. Dabei geht es darum, nach standardisierten Kategorien externe Randbedingungen festzulegen, die gelten müssen, damit das Fahrzeug im autonomen Betriebszustand operieren kann.

Für die Entwicklung dieser Taxonomie gibt es bei der ISO eine Arbeitsgruppe, die an diesem Standard "ISO/AWI 34503 – Road vehicles – Taxonomy for Operational Design Domain for Automated Driving Systems" arbeitet. Ein Experte für dieses Thema ist z.B. Dr Siddartha Khastgir Head of Verification & Validation, Intelligent Vehicles WMG, University of Warwick, UK. Er ist der Experte aus dem vereinigten K?nigreich (UK) in den ISO Arbeitsgruppen ISO TC204/WG14 und ISO TC22/SC33/WG9.

Methodischer Ansatz "Klasse und Objekt"

Unser methodischer Ansatz, den Klaus Anwender im Rahmen des Forschungsprojektes SofDCar entwickelt haben, ist folgender:

Das aus der objektorientierten Programmierung bekannte Konzept von Klasse und Objekt bzw. Instanziierung der Klasse wenden wir auf alle Elemente unseres Datenmodells im Data-Driven Systems Engineering (DDSE) an, wo es Sinn macht. Wir nennen diesen Ansatz Typebased Product Line Engineering (TPLE).

Wir sprechen dabei im Solution Space = L?sungsraum (dort werden unsere Entwicklungsergebnisse dokumentiert) von Types = Klassen und von Type Configurations = Objekte. Man kann sich das so vorstellen wie eine Art Schablone, welche den Varianzraum der m?glichen konkret davon abgeleiteten Objekte definiert. Auf der Ebene der Objekte sind alle Varianzpunkte ausdefiniert und konkret mit einem Wert belegt.

Featuremodell im Data-Driven Systems Engineering

Das Konzept "Klasse und Objekt" haben wir nun zur Beschreibung von Produktfeatures logisch konsequent auch im Problem Space = Problemraum oder Anforderungsraum angewendet und im Datenmodell (siehe Darstellung oben) abgebildet.

Beispielhaft haben wir in unserem TPLE Manager die Schablonen für die einzelnen aus der ISO 34503 definierten Attribute der ODD als Features modelliert. In der Darstellung oben sieht man das Attribut "Scenery.Temporary road structures" mit seinen beiden Parametern "Exclude Temporary road structures" und "Temporary road structures".

Nun wird es konkret: eine in sich sinnvolle Konstellation von Features mit konkret belegten Parameterwerten k?nnen als Feature Configuration in TPLE beschrieben werden. In Detail sieht das beim Attribut "Scenery.Temporary road structures" so aus:

Man sieht in der Darstellung oben, dass in dieser konkreten ODD für Deutschland einzig Baustellen in der Kategorie "tempor?re Strassenstrukturen" ausgeschlossen sind.

Zusammenfassung

Mit diesem Beispiel der Abbildung von Randbedingungen für autonom fahrende Fahrzeuge durch das Featuremodell aus TPLE konnten wir zeigen, dass die standardisierte und automatisiert weiterverarbeitbare Beschreibung von ODDs m?glich ist.

Die Vorteile dieses Ansatzes sind:

• Gleiche Mechanismen ("Klasse und Objekt") werden zur Beschreibung unterschiedlicher Aspekte im Systems Engineering angewendet. Somit ist nach kurzer Einarbeitung eine hohe Produktivit?t bei der Modellierung erreichbar
• Durch die konsequente und durchg?ngige Versionierung alle Elemente im Datenmodell ist ein kontinuierliche Weiterentwicklung dieses Data-Driven Systems Engineering Ansatzes ohne weiteres m?glich
• Die zugrundeliegenden Technologien wie UML-Datenmodelle, Graphendatenbanken und GraphQL als Abfragesprache sind Industriestandards und in vielen F?llen gibt es Open Source Implementierungen davon. Dadurch ist eine geringe Einstiegshürde, z.B. auch für studentische Projekte, gegeben
• Bei einem weit verbreitetem Einsatz dieses Dokumentationslogik besteht die Chance, einen Industriestandard zu etablieren, der wiederum Skaleneffekte nach dem Netzwerkprinzip erm?glicht. Siehe dazu Introducing data-driven systems engineering: TPLE

Ausblick

Wir m?chten mit TPLE unseren Beitrag zur softwaredefinierten Zukunft de Autoindustrie beitragen. Dieses Datenmodell wollen und werden wir Open Source stellen - die Form und der Weg dahin ist noch nicht klar und wird nach Abschluss des Forschungsprojektes SofDCar von mir aktiv vorangetrieben. Bis dahin hoffe ich auf ein reges Interesse in der Automotive und Systems Engineering Community und freue mich auf den Gedankenaustausch mit Euch.