Was macht BASELABS eigentlich?

Ich werde oft gefragt, was genau BASELABS eigentlich entwickelt und welche Technologien dafür verwendet werden. Hier ein kleiner Einblick.

BASELABS erstellt Softwareentwicklungswerkzeuge und -bibliotheken, die es Softwareentwicklern und -ingenieuren bei unseren Kunden wie z.B. Continental ermöglichen, effizient sichere Algorithmen für das automatisierte Fahren zu entwickeln. Wir haben uns dabei auf die sogenannte Sensordatenfusion spezialisiert, die Daten unterschiedlicher Sensoren wie Kamera, Radar und LiDAR kombiniert und daraus ein einheitliches und fehlerbereinigtes Abbild der Fahrzeugumgebung ermittelt.

Sensorfusion als Produkt

Wir haben unser gesamtes Wissen über Sensorfusion in unsere Software BASELABS Create Embedded und BASELABS Dynamic Grid gepackt, damit dieses Wissen allen Entwicklern zur Verfügung steht, um eigene Systeme möglichst effizient zu entwickeln. Die Software besteht aus unterschiedlichen Teilen, die beim Kunden zusammenspielen. Der Kern ist eine nach Sicherheitsnormen zertifizierte Bibliothek bzw. ein SDK, die/das verschiedene mathematische und statistische Verfahren wie den Kalman Filter beinhaltet. Für die Entwicklung der Bibliotheken verwenden wir eine stark an Rust angelehnte und selbst entwickelte Programmiersprache, die wir Trait-C nennen, aber auch C++ kommt stark zum Einsatz.

Ein weiterer Teil sind grafische Benutzeroberflächen, die die teilweise komplexen technischen Lösungen einfach(er) benutz- und erlebbar machen. Wir haben es zum Beispiel geschafft, dass unsere Kunden Sensorfusionsalgorithmen über eine Oberfläche vollständig konfigurieren und daraus C-Quellcode generieren können, der sich direkt für eingebettete Systeme kompilieren und darauf ausführen lässt:

Benutzeroberfläche unserer Software BASELABS Create Embedded. Modelle und Parameter aller im System verwendeten Sensoren werden vom Nutzer konfiguriert. Daraus erzeugt die Software C-Quellcode, der für die jeweilige Zielplattform kompiliert wird. Im Fahrzeug werden dann die Daten aller Sensoren eingesammelt und dem erzeugten Algorithmus bzw. der Sensorfusion übergeben. Diese berechnet ein einheitliches Abbild der Fahrzeugumgebung, woraus die Fahrbefehle wie Bremsen oder Lenken abgeleitet werden. — Übrigens: Die Automobilwelt setzt stark auf die Sprachen C und C++, um den hohen Sicherheits- und Performanceanforderungen gerecht zu werden. Speziell für diese Sprachen gibt es bereits eine Vielzahl von zertifizierten Tools und Workflows, die in der Regel beibehalten werden sollen.

Neben Software und Algorithmen für aktuell verfügbare Fahrerassistenzsysteme wie dem automatischen Notbremsen arbeiten wir bereits auch an den nächsten Algorithmengenerationen wie zum Beispiel Dynamic Grid und Extended Object Fusion. Dabei liegt eine große Herausforderung darin, diese Verfahren für typische automotive CPUs zu optimieren.

Freie Bereiche (schwarz) vs. statische Hindernisse (grau) vs. dynamische Objekte (bunt) — Mit hochauflösenden Sensoren und dem neuartigen Verfahren “Dynamic Grid” können vielfältige Objektarten inkl. Freiraum genau erfasst werden.

Softwareprodukt vs. Auftragsentwicklung

Natürlich entwickeln wir auch hin und wieder Software nach genauen Vorgaben eines Kunden, unser Fokus liegt jedoch in der Entwicklung von Softwareprodukten. Wo liegen die Unterschiede zwischen beiden Entwicklungsarten? Softwarequalität eignet sich hier nicht als Unterscheidungsmerkmal; diese hängt vor allem von der Entwicklungsphase wie z.B. Vor- oder Serienentwicklung ab.

Softwareprodukte zeichnen sich vor allem darin aus, dass sie von möglichst vielen Anwendern ohne Anpassung verwendet werden können. Dies erfordert ein sehr gutes Verständnis der Anwendungsfälle des Produktes im Vorfeld der Entwicklung, die wir durch regelmäßigen Austausch mit unseren Kunden und der Entwicklergemeinschaft erheben, oft allerdings erst durch viele (wirklich viele) Diskussionen mit unseren Experten „entdecken“, vor allem dann, wenn es am Markt (noch) nichts Vergleichbares gibt.

Ist ein Anwendungsfall einmal verstanden, geht es an die Umsetzung bzw. Implementierung, die sich oft von einer Entwicklung für einen einzelnen Kunden bzw. der Auftragsentwicklung unterscheidet. Einerseits möchte man mit einer maximal generischen Umsetzung so viele Anwendungsfälle wie möglich adressieren, andererseits soll jeder Anwendungsfall so spezifisch wie möglich gelöst werden. Diesen scheinbaren Widerspruch aufzulösen, stellt für mich eine der spannendsten Aufgaben der Softwareproduktentwicklung dar.

Zusätzlich gelten bei der Produktentwicklung in der Regel deutlich höhere Anforderungen an die Erweiter- und Wartbarkeit der Software. Ist zum Beispiel die Schnittstelle einer Bibliothek einmal veröffentlicht, können spätere Schnittstellenänderungen bei der Nutzung durch lediglich einen (Projekt-)Kunden verhältnismäßig einfach nachgezogen werden. Wird die Schnittstelle jedoch von vielen Kunden in vielleicht sogar unterschiedlichen Anwendungsfällen verwendet, stellen nachträgliche Änderungen oft eine mittlere Katastrophe dar, die wir durch sorgfältiges Schnittstellendesign oft vermeiden können.

Big Data für die Entwicklung von Sensorfusionssystemen

Sensorfusionsalgorithmen enthalten eine Vielzahl von statistischen Modellen, die durch den Anwender für sein spezifisches System und Sensorkombination gefunden, parametriert und angewendet werden müssen. Wir entwickeln daher gerade eine neue Software, die es ermöglicht, genau diese Modelle automatisiert zu finden und zu parametrieren.

Dafür zeichnen unsere Kunden große Datenmengen in Testfahrten auf, die dann für das Anlernen der Modelle und die Validierung in unserer Software verwendet werden — oft werden bis zu einer Million Kilometer an Daten eingefahren.

Auszug aus einem Vortrag, den wir auf der diesjährigen Tech.AD Konferenz in Berlin gezeigt haben.

Auch hier soll eine grafische Benutzeroberfläche die oft große Komplexität beim Auswerten der Daten reduzieren und dem Kunden schnelle Ergebnisse liefern. Die GUI richtet sich vor allem an Entwickler und Ingenieure und soll technische und statistische Größen sowie Zusammenhänge konfigurier- und darstellbar machen.

Moderne Radarsensoren liefern viele sogenannte Reflektionen oder Detektionen, je nachdem, von welcher Seite ein Fahrzeug vom Sensor gesehen wird. Um solche Modelle zu entwickeln, werden große Datenmengen benötigt.

Dafür werden die aufgezeichneten Daten im Backend aufbereitet; hier kommen Technologien wie Apache Spark und Docker zum Einsatz. Für die Entwicklung der GUI haben wir uns für die Technologie Avalonia entschieden, da sie eine XAML und MVVM basierte Entwicklung ähnlich zu WPF mit .Net (Core) ermöglicht und gleichzeitig Plattformunabhängigkeit bietet. Dadurch wird die Oberfläche neben Windows auch auf Linux nativ lauffähig, was für viele unserer Kunden ein Must-have ist.

Womit und wie wir Software entwickeln

Als Entwicklungsumgebung verwenden viele Kollegen Visual Studio (Code), die Programmiersprachen reichen von C über C++ (zwischen ´98 und ´20 ist alles vertreten) zu C#, Python, CUDA und unserer eigenen Sprache Trait-C. Die Verwendung von git, Jira, Code Review und Unit Testing Tools ist für uns selbstverständlich und natürlich werden alle Produkte und Projekte im Rahmen von Continuous Integration entwickelt — dafür verwenden wir TeamCity von JetBrains.

Continuous Integration (hier am Beispiel mit TeamCity) ermöglicht schnelle Integration und permanentes automatisiertes Testen von neuen Codebestandteilen. Fehler werden so frühzeitig erkannt und Entwickler gehen sicher, dass ihre Änderungen wie beabsichtigt funktionieren.

Für Entwickler bei BASELABS gibt es einen festen täglichen Termin, das sogenannte Daily Stand-Up, welches bei den meisten Teams kurz vor der Mittagspause zwischen 11:45 und 12 Uhr stattfindet und in dem sich die Team Mitglieder kurz über den aktuellen Stand austauschen. Größere Planungen finden im Mittel aller zwei Wochen statt.