ADAS benötigt ein intelligentes Backend

Da Verfügbarkeit und Quality-of-Service der Konnektivität der Fahrzeuge nicht für jede Umgebung sichergestellt werden können, muss das Fahrzeug Situationen selbstständig einschätzen und Entscheidungen treffen, um Gefährdungen angemessen aufzulösen. Der einfachste Weg wäre, sich auf die Notfall-Maßnahmen der On-Board-Assistenz-Systeme zu verlassen. Diese Lösung kann aber nur als „Manöver des letzten Augenblicks“ eingesetzt werden, da der nachfolgende Verkehr gefährdet werden kann und ein negatives und verstörendes Fahrerlebnis für die Insassen entsteht.

Deshalb müssen intelligente Verfahren und KI durch Off-Board-IT im Backend zur laufenden Unterstützung der Flotte verfügbar sein – entweder durch aktuelle, verifizierte Informationen von externen Anbietern oder aus Erkenntnissen der eigenen Flotte. Diese Informationen sind insbesondere als Unterstützung der On-Board-IT der ADAS-Funktionen wichtig, während Informationen zu definierten oder besonderen Situationen im tatsächlichen Fahrbetrieb für das Training der KI im Fahrzeug in der Entwicklung der ADAS-Features essenziell sind.

Schließlich können spezielle Informationen erforderlich werden, die nur implizit in verfügbaren Quellen vorhanden sind, zum Beispiel in sehr seltenen oder dynamischen Konstellationen. Solche Informationen sind Voraussetzung beispielsweise für Testfälle und die Planung von Testfahrten oder auch für Trainingsdaten zur Situations- oder Objekterkennung für die On-Board-KI. 

Eine für alle ADAS-Fahrfunktionen elementare Information ist eine belastbare Karte der relevanten Umgebung zur Navigation. Jedoch veralten Kartendaten schnell, wenn Baustellen oder kurzfristige Straßensperrungen entstehen.

Die Kartendienstleister sind selbstverständlich bemüht, diese Veränderungen so schnell wie möglich nachzuziehen. Dazu werden meist in getakteten Abständen aktuelle Releases bereitgestellt. Doch Änderungen in der realen Welt erfolgen in Echtzeit, unabhängig von den Release-Takten der verschiedenen Kartendienstleister. Dort werden Änderungen auch erst übernommen, wenn das Wissen darüber hinreichend gesichert ist – also zum Beispiel erst, nachdem eine neue 3D-Vermessung stattgefunden hat.

Die zusätzlichen – insbesondere aktuellen – Informationen können nur durch Fahrten auf den entsprechenden Straßensegmenten gesichert erfasst werden.

Dafür können Daten aus Flottenfahrten oder dedizierten Einzelfahrten genutzt werden, aber auch Dienste von Informationsanbietern, die sich auf entsprechende Fahrdaten stützen. Das Dilemma daran: Eigene dedizierte Flotten sind ebenso teuer wie externe Dienstanbieter, z. B. Google Street View. Andererseits können dedizierte Fahrten nur in Ausnahmen sinnvoll sein, zum Beispiel für Voruntersuchungen oder Proof-of-Concepts (PoC), und die Ziele oder Strecken für diese Fahrten müssen bekannt sein.

Die Automotive-OEM haben mit ihrer jeweiligen Kundenfahrzeug-Flotte zwar eine starke Alternative, die jedoch weitere Herausforderungen mit sich bringt:

• Die Qualität der Sensorik in den Serienfahrzeugen ist durch den Verkaufspreis und für den ursprünglichen Zweck getrieben, was sie zum Teil nicht direkt verwendbar für Off-Board-Datenprodukte macht. Als Beispiel dient die Standortbestimmung in Geo-Koordinaten, die in den Fahrzeugdaten einen Positionsfehler zwischen wenigen Zentimetern bis zu mehreren Metern haben können, zusätzlich verstärkt durch Umgebungsbedingungen (Tunnel, Abschattungen).
• Die Anzahl der Durchfahrten an den Straßensegmenten variiert sehr stark – zeitlich und regional – und kann für bestimmte Sachverhalte oder Strecken zu gering sein, insbesondere wenn gesicherte Messwerte mit hoher Konfidenz notwendig sind, wie zum Beispiel für Maßnahmen, die aus einer FMEA resultieren.
• Die Erhaltung der Marken-Integrität sowie die gesetzlichen Vorgaben erfordern die strikte Einhaltung und Beachtung zur Einwilligung des jeweiligen Kunden und insbesondere der Einhaltung der #DSGVO für die Begründung der Verwendung und Verarbeitung jedes einzelnen Use-Cases.
• Verfahren zur Ableitung von Erkenntnissen oder Erkennungen aus den Serien-Flottendaten benötigen eine Überprüfung oder Validierung über die sogenannte „Ground Truth“. Diese belastbaren Informationen sind meist nicht vorhanden oder in der Breite sehr schwer zu beschaffen. Dazu müssen oft Video-Sequenzen, die mit Geo-Koordinaten annotiert sind, manuell gesichtet und gelabelt werden. Dies ist eine zeitaufwändige, fehleranfällige und teure Prozedur.
• Aktuelle Informationen, die zur Unterstützung der ADAS-Funktionen in der Kundenfahrzeugflotte genutzt werden, erfordern eine Unterstützung im Backend mit Prozessen, Pipelines, Verarbeitungsschritten etc., die gesichert rund um die Uhr verfügbar sind und kosteneffizient betrieben werden können.

Die msg ist ein etablierter IT-Dienstleister für unsere Kunden im Bereich Automotive – auch für ADAS-Funktionen.

Ein Beispiel dafür ist ein langlaufendes Projekt für eine Fahrzeugflotte: msg hat die technische Architektur und Konzeption für das #Cloud Backend erstellt und schließlich so umgesetzt, dass derzeit monatlich Messages im zweistelligen Milliardenbereich mit einem Datenvolumen von deutlich zweistelligen TByte auf der Plattform verarbeitet werden.

Im Laufe der Zusammenarbeit sind durch das msg-Team eine große Anzahl von Ingest-Komponenten und Datenprodukten mit sehr hoher Verfügbarkeit technisch umgesetzt worden. So konnten wir mit unserer technischen Kompetenz die laufenden Betriebskosten um eine Größenordnung reduzieren. Zusätzlich haben wir durch Erfahrungen in den verwendeten Technologien und Analysen von potenziellen Fehlerquellen die Systeme so optimiert, dass sie sowohl auf interne als auch auf externe Fehler robust und ohne manuelle Eingriffe reagieren. Wegen der implementierten Resilienz-Mechanismen ist eine „On-call Duty“ außerhalb der Büroarbeitszeiten nicht mehr erforderlich.

Darüber hinaus wurden insbesondere auch die Datenprodukte durch das msg-Team inhaltlich mitgestaltet – und einige sogar gemeinsam initial entworfen. Die Kompetenz durch unsere End-to-end-Erfahrung in allen Belangen des Cloud Backends hat zum Beispiel zu einem Datenprodukt für eine sehr gute, weltweite Erkennung von potenziellen Gefahrenstellen geführt, die eine Verfügbarkeit eines ADAS-Dienstes wesentlich unterstützt. Für ein anderes Datenprodukt betreiben wir die komplette KI-Strecke im hochautomatisierten MLOps-Modus.

Insbesondere hat die Art der Zusammenarbeit – ein offenes, vertrauensvolles Co-Working mit einer End-to-end-Verantwortung in einem Dev-Ops-Modell – zu kürzesten Umsetzungszeiten von der Idee bis zum Betrieb mit voller Automatisierung, Compliance, Resilienz und Wartbarkeit geführt.