Sensordatenfusion: der Schlüssel für die gute Nutzung von KI

Robin Schubert: Die aktuellen weltpolitischen Krisen machen uns Sorgen, aber anderseits spüren wir in diesem Jahr eine starke Nachfrage. Wir rechnen damit, den Umsatz im Vergleich zum Vorjahr fast verdoppeln zu können. Zudem haben wir gerade eine Niederlassung in den USA eröffnet, um den nordamerikanischen Markt besser bedienen zu können.

Was sind die Kernaktivitäten von Baselabs?

Robin Schubert: Baselabs entwickelt Softwareprodukte für das sichere automatisierte Fahren, speziell für den Bereich der Sensordatenfusion. Weil die Sensoren, die man für das automatische Fahren braucht, immer physikalischen Beschränkungen unterliegen und damit nie perfekte Informationen geben, trägt unsere Software dazu bei, aus diesen Sensordaten zuverlässige Fahrentscheidungen zu treffen.

Wie kamen Sie auf die Idee, in diesen Bereich einzusteigen?

Robin Schubert: Wir sind eine Ausgründung aus der Technischen Universität Chemnitz. Vor der Gründung waren zwei meiner Mitgründer und ich fünf Jahre als wissenschaftliche Mitarbeiter an der TU beschäftigt und haben uns dort forschungsseitig mit dem Thema Sensordatenfusion beschäftigt. Damals ging es noch um Fahrerassistenz, da hat noch niemand von hochautomatisiertem Fahren gesprochen, aber die Themen Umfeldmodell, Sensoren und Sensordatenfusion waren auch damals schon ein zentraler Baustein.

Was ist einzigartig an den Lösungen von Baselabs?

Robin Schubert: Wir haben unsere Marktlücke in der skalierbaren, sensorunabhängigen Architektur für die Sensordatenfusion entdeckt. Vom Gründungstag an verfolgen wir die Idee, eine konfigurierbare Sensordatenfusion anzubieten, die sich unabhängig vom Sensor-Set ISO26262-konform in Serie nutzen lässt.

Unsere Software ist für die Kunden sofort verfügbar, so dass sie damit schneller sind als wenn sie diese selbst entwickeln. Der zweite Bestandteil des Produktgeschäftsmodells ist, dass wir die Entwicklungskosten auf die verschiedenen Kunden verteilen. Das senkt die Kosten für jeden einzelnen Kunden drastisch im Vergleich zur Eigenentwicklung.

Robin Schubert: OEMs und Tier-1s könnten die Sensordatenfusion im Prinzip auch selbst entwickeln, aber das erhöht nicht nur die Kosten, sondern bindet auch wertvolle Ressourcen und kostet viel Zeit. Software-Entwickler sind jedoch in der Industrie kaum zu bekommen. Gleichzeitig steigt die Komplexität der Software, die auch weiter gepflegt werden muss. Ich bin davon überzeugt, dass der Entwicklermangel zu einem der zentralen Engpässe der Branchen in den nächsten Jahren werden wird – und zwar noch drastischer als das schon heute der Fall ist.

Wir nutzen eine der zentralen Eigenschaften von Software, nämlich die Möglichkeit, sie zu vervielfältigen. Es klingt total banal, aber ich sehe, dass viele diese Eigenschaft noch nicht nutzen, sondern jeder seine eigene Software macht. Wir entwickeln die Funktionalität, die man für Sensordatenfusion benötigt, eben einmal und stellen sie dann mehreren Kunden zur Verfügung. Somit ist diese sofort verfügbar, und die Kunden können ihre Softwareentwickler für die Themen einsetzen, die vielleicht wirklich nur in ihrem Fahrzeug benötigt werden und wo nur sie die entsprechende Software erstellen können.

Bei der Sensordatenfusion gibt es eine große Überlappung, weil die mathematischen Ansätze hierfür meist gleich oder zumindest ähnlich sind. Daher ist es aus meiner Sicht ökonomisch absolut sinnvoll, Sensordatenfusion als Softwareprodukt zu nutzen.

Unternehmen wie Nvidia bieten praktisch einen kompletten Software-Stack für eine bestimmte automatische Fahrfunktion an, dafür dann aber oft nur für bestimmte vorgegebene Sensoren. Wir hingegen bieten unseren Kunden die Möglichkeit, genau die Sensoren auszuwählen, die für deren individuelle Anwendung in puncto Performance und Kosten am besten geeignet sind. Dafür stellen wir dann die passende Sensordatenfusion bereit – und das hebt uns von unseren Wettbewerbern ab. Diese Strategie ist weltweit einzigartig.

Robin Schubert: Das ist ein ganz zentraler Punkt bei uns. Wir stellen die Betriebs- und funktionale Sicherheit mit dem Dreiklang von Prozessen, Technologien und Menschen sicher. Aus Prozesssicht haben wir sehr viel interne Expertise zu ASPICE und ISO 26262 aufgebaut und die entsprechenden Softwareentwicklungsprozesse etabliert. Wir lassen diese Prozesse von externen Experten unabhängig auditieren, um immer wieder zu überprüfen, ob wir richtig vorgehen. Bei der Technologie nutzen wir stark automatisierte Tests, Continuous Integration und Codeanalysen. Zudem nutzen wir reale und simulierte Sensordaten für eine szenarienbasierte Validierung.

Sicherheit hängt aber immer auch von den Menschen ab, die an der Software arbeiten. Die ISO spricht dort von der Safety Culture. Das kommt meiner Meinung nach oft zu kurz, aber wir legen darauf großen Wert. Wir leben eine offene und aufrichtige Kommunikation und schreiben das regelmäßige Hinterfragen unseres Tuns sehr groß. Die Auszeichnung als „Great Place to Work“, die wir jetzt zum dritten Mal in Folge bekommen haben, bestätigt das. Ich glaube, dass nicht viele den Zusammenhang zwischen Unternehmenskultur und Safety sehen, aber dieser Aspekt ist für mich ganz zentral. Ich bin überzeugt, dass nur engagierte und motivierte Mitarbeiterinnen und Mitarbeiter am Ende gute und damit auch sichere Arbeitsergebnisse generieren.

Wenn mehrere Unternehmen die gleiche Codebasis der Software einsetzen, ist sie natürlich auch von mehr Leuten getestet als eine selbst entwickelte Einzellösung. Auch das trägt zur Sicherheit bei. Die ISO spricht dort von einer „Proven-in-Use“ Safety-Argumentation und das kommt praktisch als Bonus zur Argumentation hinzu.

Robin Schubert: Die zentrale Herausforderung von Sensordatenfusion besteht darin, Widersprüche zwischen den Sensordaten aufzulösen, über Statistiken herauszufinden, welchem Sensor ich in der spezifischen Situation mehr vertrauen kann, und das dann an die nachfolgenden Fahrfunktionen auszugeben. Typische Ausgänge sind dann zum Beispiel Objektlisten oder Freiraumpolygone. Die andere Ebene ist die sogenannte Low-Level-Fusion, also die Rohdatenfusion. Dabei bekommt das System z. B. vom Lidar die Punktwolke, also die einzelnen Reflexionspunkte der Laserstrahlen, oder von dem Radar die Rohziele, die es dann verarbeitet.

Wie nutzt Baselabs V2X und GNSS als Sensor-Input?

Robin Schubert: Wenn wir von Sensoren reden, dann meinen wir meist die im Fahrzeug verbauten Komponenten, aber unsere Software ist auch in der Lage, virtuelle Sensoren mit einzubeziehen. Das kann zum Beispiel eine Cloud-Anbindung oder V2X sein. Schon 2015 haben wir die Fusion von Onboard-Sensorik mit V2X in einem Projekt unter anderem mit Scania erfolgreich umgesetzt. Wichtig ist dabei, dass die Zeitbasis zwischen den einzelnen Teilnehmern der Kommunikation synchronisiert ist, aber auch die präzise Lokalisierung spielt eine große Rolle.

Jeder OEM bzw. Tier-1 hat eine andere Hardware-Umgebung. Wie erfolgt die Anpassung an die Hardware-Umgebung, und wie ist eine Wiederverwendung der Auswerte-Algorithmen bei einem Wechsel der Hardware möglich?

Robin Schubert: Die in unserer Software enthaltenen Algorithmen sind sehr stark mathematischer Natur, so dass sie nur in geringem Maße von der Hardware abhängig sind. Wir geben Objektlisten aus, aber wir erledigen nicht die Kommunikation zum Sensor über CAN oder Ethernet. Deshalb hat unsere Software erst mal intrinsisch keine direkten Hardwareabhängigkeiten.

Viele der Verfahren, die wir aktuell anbieten, gab es vor einem Jahr nur zur Abarbeitung auf einer GPU, und das schränkt natürlich die Hardware-Wiederverwendbarkeit ein. Wir haben es geschafft, diese Verfahren CPU-tauglich zu machen, so dass sie zum Beispiel auf mehrkernigen Arm-Prozessoren laufen. Das ist ein entscheidender Faktor in puncto Wiederverwendbarkeit, weil wir so mit den Standardsprachen C und C++ arbeiten können und damit alle relevanten Hardwareplattformen adressieren.

Robin Schubert: Da gibt es zwei Perspektiven. Natürlich nutzen wir in der Sensordatenfusion die Ergebnisse von KIs. Wenn eine Kamera in einem Bild Fußgänger oder Fahrzeuge erkennt, dann stecken da KI-Algorithmen dahinter, die anschließend die Rechtecke im Fahrzeug als Eingang an unsere Sensordatenfusion liefern. Insofern sind wir schon seit vielen Jahren eine Art Konsument von KI-Ergebnissen.

Interessant ist auch die andere Richtung: Durch den höheren Automatisierungslevel steigt die Komplexität, so dass auch komplexere KI-Verfahren zum Einsatz kommen. Dort sehen wir den Trend, dass Sensordatenfusion als Vorverarbeitung vor der KI eingesetzt wird und damit die Datenqualität steigert. Datenqualität ist auch für die KIs der zentrale Faktor. Wenn man jetzt vorher verschiedene Sensordaten zusammenführt, vielleicht auch über die Zeit sammelt, Koordinatensysteme transformiert etc., dann lässt sich die Qualität der Daten deutlich erhöhen, die als Input in das neuronale Netz fließen – und das steigert wiederum die Performance der KI.

Ein Beispiel ist das Dynamic Grid, bei dem die Umgebung des Fahrzeugs in Zellen zerlegt wird, etwa wie die Pixel eines Bildes. Für jede Zelle wird bestimmt, ob diese Zelle frei oder belegt ist. Ist sie belegt, stellt sich die Frage, ob es dort eine Bewegung gibt. Falls ja, wird eine Geschwindigkeit, eine Richtung bestimmt, so dass am Ende ein mehrkanaliges Bild vorliegt, wie eine Art Vogelperspektivbild. Mit derartigen Bildern – 2D oder auch 3D – als Input können CNNs, also Convolutional Neural Networks, die für Bilder geschaffen wurden, sehr gut umgehen. Weil wir zum Beispiel auch noch die Geschwindigkeiten von Objekten schätzen können, haben wir mehr Informationen zur Verfügung, als wenn man die Sensoren direkt an die KI anschließen würde. Die Sensordatenfusion ist in Zukunft der Schlüssel für eine gute Nutzung von KI.

Heute erlebe ich oft, dass KI und Sensordatenfusion als Widerspruch gesehen werden, aber das ist meiner Meinung nach falsch; man braucht immer beides. Langfristig werden so-wohl KI in Form von neuronalen Netzen als auch klassische Verfahren wie Sensordatenfusion oder Regler zum Einsatz kommen, weil durch diese Zerlegung des Gesamtsystems in Teilkomponenten eine bessere Testbarkeit und damit eine zuverlässigere Zulassung auf der Straße gewährleistet wird. Auch die Hardware lässt sich besser ausnutzen. Es wird in Zukunft immer eine Mischung geben: Sensordatenfusion, Regler, andere Verfahren und natürlich neuronale Netze.

Robin Schubert: Die Cloud-Anbindung sehe ich vor allem relevant bei der Nutzung von Karteninformationen, weil es gerade für die Bewertung des Fahrzeugumfelds relevant ist, ob sich Objekte zum Beispiel auf einem Abbiegefahrstreifen befinden oder nicht. Das ist eine relevante Information, und die bekommt man typischerweise aus der Cloud. Bei Big Data sehe ich das große Potenzial darin, die Millionen Kilometer, die gerade überall eingefahren werden, und die so gewonnenen Daten für die Parametrierung der Sensordatenfusion zu nutzen. Denn je besser ich das Verhalten der Sensoren verstehe, gerade auch in seltenen Situationen, desto besser kann die Sensordatenfusion die Daten auch kombinieren, verarbeiten und interpretieren.

Dort sehe ich ein großes Potenzial, Big-Data-Analytics-Ansätze zu nutzen, um aus den vielen Messdaten das Sensorverhalten zu extrahieren. Wir sprechen bei Baselabs von Sensorcharakterisierung, bei der man statistische Eigenschaften der Sensoren extrahiert: wie oft treten bestimmte Effekte auf, wie oft werden bestimmte Fahrzeuge gesehen, wie viele Detektionen habe ich, etc.? Je besser ich diese Charakteristika verstehe, desto genauer kann ich die Daten interpretieren, die ich zur Fahrzeit des Fahrzeuges bekomme.

Robin Schubert: Ein großes Thema, mit dem wir uns gerade beschäftigen, ist die Standardisierung. Ich bin überzeugt, dass für das automatische Fahren eine stärkere Zusammenarbeit in der Industrie notwendig ist – gerade wenn es um die Sicherheit geht. Deswegen arbeitet Baselabs zum einen im Rahmen der ISO an der Standardisierung entsprechender Verfahren mit, aber auch als Platinum Member in der Initiative The Autonomous. The Autonomous hat es wirklich geschafft, hochkarätige Partner mit an Bord zu bringen.

Wir sind bei The Autonomous aktiv, weil es eine Zusammenarbeit, eine Einigung auf bestimmte Grundarchitekturen geben muss, um die Komplexität zu reduzieren und damit die Sicherheit zu gewährleisten. Je größer die Variantenvielfalt und Komplexität, desto höher die Risiken. Jeder Safety-Experte sagt, Komplexität muss reduziert werden, damit man die Software testen und absichern kann. Dort sind wir sehr stark involviert, und wir werden damit perspektivisch eines der ersten Unternehmen sein, das zukünftige Standards in seinen Softwareprodukten mit am Markt anbieten kann.

Robin Schubert: Chemnitz ist die Heimatstadt von uns Gründern, und wir wollten bewusst die Region stärken. Inzwischen hat sich Chemnitz zu einem Cluster für automatisiertes Fahren entwickelt. Es gibt hier inzwischen einige Unternehmen, die an dem Thema arbeiten, neben Baselabs unter anderem FDTech, Intenta, das Startup Naventik und FusionSystems. Baselabs ist ein Gründungsmitglied des Netzwerks CADA, Chemnitz Automated Driving Alliance, und wir sehen, dass uns das vor allem hier in der Region in eine starke Position versetzt, um Softwareentwickler zu finden, die gern im Bereich automatisiertes Fahren arbeiten, aber vielleicht nicht nach Süddeutschland ziehen wollen. Hier sind wir gemeinsam stark.