Entwickeln fortschrittlicher Notbremssysteme bei Scania

Heckkollisionen stellen die häufigste Unfallart bei Lastkraftwagen und anderen Schwerfahrzeugen dar. Seit 2015 sind EU-weit für alle Neufahrzeuge fortschrittliche Notbremssysteme (AEBS) vorgeschrieben, um das Risiko von Heckkollisionen zu verringern.

Wie andere fortschrittliche Fahrerassistenzsysteme (ADAS) verwendet ein AEBS Sensoren, um die Umgebung abzutasten. Sobald eine Kollision unmittelbar bevorsteht, warnt das System den Fahrer mit einem akustischen Signal. Wenn der Fahrer nicht reagiert, wird vom System eine Warnbremsung ausgelöst. Falls der Fahrer danach noch immer nicht reagiert, aktiviert das System die volle Bremsleistung, um die Kollision zu vermeiden (Abbildung 1). Das Notbremssystem AEBS verfügt zudem über einen „Bremsassistenten“: Wenn der Fahrer bremst, aber mit unzureichender Kraft um eine Kollision zu vermeiden, berechnet das System die zusätzlich notwendige Bremskraft und setzt sie ein.

AEBS verwendet sowohl Radar- als auch Kamerasensoren, die an der Fahrzeugfront montiert sind, um den Bereich vor dem Fahrzeug auf Objekte zu scannen. Das System setzt die besonderen Stärken jedes Sensors wirksam ein, um ein genaueres Umweltmodell zu erstellen. Radarsensoren können insbesondere die Reichweite eines Objekts, seine relative Geschwindigkeit und Festigkeit feststellen, sind aber weniger in der Lage, dessen Form oder laterale Position zu bestimmen. Für ein System, das ausschließlich Radar verwendet, wäre es schwierig, ein am Fahrbahnrand geparktes Auto von einem auf der Fahrbahn zu unterscheiden. Kameras können dagegen die Größe eines Objekts sowie seine laterale Position feststellen, erkennen aber Reichweiten nicht gut und sind nicht fähig, Dichten zu bestimmen (eine dichte Wolke kann als solides Objekt wahrgenommen werden).

Meine Mitarbeiter und ich haben ein System zur Sensorfusionentwickelt, das Daten aus beiden Sensoren zu einem einzelnen Objekt kombiniert. Das System verwendet vier gewichtete Eigenschaften – Längsgeschwindigkeit und -position sowie Quergeschwindigkeit und laterale Position –, um die Wahrscheinlichkeit zu berechnen, dass beide Sensoren das gleiche Objekt erkannt haben. Sobald das Sensorfusionssystem ein Objekt auf der Fahrbahn des Trägerfahrzeugs identifiziert hat, gibt es die Objektposition und den projizierten Fahrweg des Fahrzeugs an das AEBS weiter. Dieses bestimmt dann, wann der Fahrer gewarnt oder die Bremse betätigt werden müssen.

Unsere Gruppe hatte zuvor modellbasierte Entwicklung verwendet, um ein adaptives System zur Geschwindigkeitsregelung mit Radartechnologie zu entwickeln. Ein Sensorfusionssystem hatten wir zuvor allerdings noch nie entwickelt. Da es sich um eine neues Design handelte, wussten wir, dass wir eine lesbare, verständliche Architektur benötigten, um den Signalfluss abbzubilden. Wir rechneten auch mit zahlreichen Iterationen bei der Entwicklung und suchten aus diesem Grund einen einfachen Weg, um Ergebnisse anzuzeigen und Fehler in unseren Design zu beheben. Zusätzlich wollten wir durch die Codegenerierung Zeit sparen, wobei aber der Code effizient sein musste, da die CPU-Auslastung unserer elektronischen Steuereinheit (Electronic Control Unit, ECU) bereits bei 60% lag, als wir mit dem Sensorfusionsprojekt begannen. Zuletzt mussten wir unser Design eingehend prüfen. Unser Plan war es, Simulationen auf der Grundlage von mehr als 1,5 Millionen Kilometern an Sensordaten durchzuführen. Die modellbasierte Entwicklung erfüllte all diese Anforderungen.

Herstellung des Sensorfusionssystems

Wir teilten zunächst das Systemdesign in funktionelle Einheiten auf, wie Objektzuordnung und Positionierung des projizierten Pfads, und erstellten einen separaten Simulink^®-Block für jede Einheit. Das Ergebnis war eine klare Softwarearchitektur mit gut definierten Schnittstellen (Abbildung 2). Wir erstellten MATLAB^®-Code für die Spurenzuordnung, zur Berechnung von Abweichungen, zur Ermittlung gewichteter Wahrscheinlichkeiten und Durchführung anderer Aufgaben, die mit einem Skript einfacher als mit Blöcken umzusetzen sind, und fügten diesen Code mit MATLAB-Funktionsblöcken in unser Simulink-Modell ein. Diese Algorithmenblöcke machten es den Teammitgliedern einfach, ihre Algorithmen zusammenzuführen und sie in das Steuersystem zu integrieren.

Um unser anfängliches Design zu debuggen und zu verfeinern, führten wir Simulationen mit aufgezeichneten Radarsensordaten, den zugehörigen Kamerabildern sowie weiteren Fahrzeugsensordaten durch. Während der Fehlerbehebung fanden wir es nützlich, die Sensordaten neben einer Kameraansicht von der Fahrzeugfront aus anzuzeigen. Wir erstellten ein Visualisierungstool in MATLAB, das Sensorfusionsdaten synchronisiert mit einer Webkameraansicht des umgebenden Verkehrs anzeigt (Abbildung 3). Das Tool macht sich die objektorientierte Programmierung mit MATLAB zunutze und verwendet eine MATLAB-Klasse, um jedes von einem Sensor erkannte Objekt sowie das vom Sensorfusionssystem wahrgenommene Objekt zu repräsentieren. Diese MATLAB-Objekte ermöglichten es uns, schnell im zeitlichen Ablauf vor- und zurückzuspringen, während wir die Daten visualisierten.

Wir verwendeten das gleiche Tool während der Straßenversuche, um Live-daten aus dem Fahrzeugnetzwerk anzuzeigen (Abbildung 4).

Umsetzung des Systems und Leistungsoptimierung

Um das Sensorfusionssystem in der ECU einzusetzen, erstellten wir C-Code aus unserem Simulink-Modell mit Embedded Coder^®. Dank der Codegenerierung war eine schnelle Implementierung möglich und wir konnten Codierungsfehler vermeiden. Der Großteil der Ressourcen des ECU-Prozessors wurde Wartungsfunktionen zugeordnet – Überwachung von Armaturenbrett-Anzeigen, physikalische Schätzungen, Daten-Gateway, adaptive Geschwindigkeitsregelung, usw. Das hatte zur Konsequenz, dass wir unser anfängliches Design optimieren mussten, um dessen Effizienz zu steigern.

Wir arbeiteten mit dem MathWorks-Team von Pilot-Ingenieuren, um die Leistung des generierten Codes zu optimieren. Um die Verarbeitungslast weiter zu reduzieren, teilten wir das Modell in verschiedene Teile auf, die in abwechselnden Zyklen ausgeführt wurden. Statt Berechnungen für stationäre und sich bewegende Objekte in jedem Zyklus durchzuführen, führten wir diese beispielsweise in abwechselnden Zyklen durch. Wir bemerkten, dass der Prozessor durch die trigonometrischen Funktionen, die unser System aufrief, ins Stocken geriet. Um dieses Problem zu mindern, schrieben wir trigonometrische Näherungsfunktionen in C und riefen sie von einem MATLAB-Funktionsblock aus auf. Diese Änderungen steigerten nicht nur die Effizienz des Sensorfusionscodes, sondern verkürzten auch die Reaktionszeit der AEBS-Software, was entscheidend ist, wenn Fahrzeuge in Autobahngeschwindigkeit unterwegs sind und jede Millisekunde zählt.

Prüfen und Verfeinern des Designs

Wir testeten das Design in einem Fahrzeug auf geschlossener Strecke, aber wir mussten ebenfalls wissen, wie das System in realistischen Fahrszenarios reagieren würde, zum Beispiel unter verschiedenen Witterungsbedingungen, bei unterschiedlichen Verkehrsmustern und bei wechselndem Fahrerverhalten. Es wäre sowohl unpraktisch als auch gefährlich, das AEBS direkt unter diesen Bedingungen zu testen. Wir verwendeten stattdessen einen simulationsbasierten Workflow. Zuerst sammelten wir Daten von einer Lkw-Flotte. Wir entschieden uns für die Sammlung aller auf der ECU vorhandenen Daten – nicht nur Daten vom Radar und der Kamera, die für die Sensorfusion genutzt wurden – sowie der Bilder von einer separaten Referenzkamera.

Anhand dieser Flottentestdaten führten wir Simulationen durch, um interessante Fahrszenarios zu identifizieren – Szenarios, in denen das AEBS eingriff, um den Fahrer zu warnen oder die Bremse zu betätigen, und Szenarios, in denen das System hätte eingreifen können, es aber nicht tat – zum Beispiel, wenn der Fahrer hupte und gleichzeitig bremste, auswich oder scharf bremste. Auf Basis dieser Szenarios analysierten wir die Leistung des AEBS, um Bereiche zu identifizieren, in denen wir das Design verbessern könnten.

Wir mussten jedes Mal neu simulieren, wenn wir die AEBS-Software aktualisierten. Bei mehr als 80 Terabyte realer Verkehrsdaten aus mehr als 1,5 Millionen Kilometern Fahrt dauerte es jedoch mehrere Tage, eine einzelne Simulation durchzuführen.

Um die Simulationen zu beschleunigen, bauten wir einen Emulator unter Verwendung von mit Embedded Coder generiertem Code aus unseren Simulink-Modellen. Der Emulator liest und schreibt die gleichen MAT-Dateien wie unser Simulink-Modell, führt aber Simulationen 150-mal schneller durch. Zur weiteren Beschleunigung schrieben wir MATLAB-Skripte, die bis zu 300 Simulationen parallel auf speziellen Multiprozessor-Servern sowie auf mehreren Computern in unserer Abteilung laufen ließen. Mit dieser Einstellung verkürzten wir die benötigte Zeit für die Simulation aller 1,5 Millionen Kilometer auf nur 12 Stunden. Immer wenn wir ein neues interessantes Szenario im Emulator identifiziert hatten, führten wir die Simulation in Simulink erneut durch, um sie eingehend zu analysieren.

Die Identifizierung und Klassifikation von potenziell interessanten Szenarios innerhalb von Terabytes von Daten war eine langwierige und zeitaufwendige Aufgabe. Daher entwickelten wir das Situationsklassifizierungs-Hilfsmodul (Situation Classification Assistant Module), ein MATLAB-basiertes Tool, das diesen Teil des Vorgangs automatisiert (Abbildung 5). Das Tool generierte eine Event-Liste aus den Simulationen, wie Kollisionswarnungen, Warnbremsvorgänge und Vollbremsungen, die vom System durchgeführt worden waren, sowie scharfe Bremsungen und Richtungsänderungen, die vom Fahrer vorgenommen worden waren. Danach konnten wir diese Listen für jeweils zwei Versionen unserer Software vergleichen.

Die Fähigkeit, umfangreiche Simulationen durchzuführen, verstärkte die Robustheit und Sicherheit der AEBS-Funktions- und Produktionscode-Umsetzung für das ECU. Sie ermöglichte es uns auch, Änderungen schneller vorzunehmen. Wir vertrauten diesen Änderungen, da wir alle verfügbaren Daten in unseren Simulationen verwendeten, um Tausende von Szenarien zu testen.

Einsatz des generierten Codes in der Herstellung von fortschrittlichen Fahrerassistenzsystemen (ADAS)

Die meisten Scania-Lkws und -Busse sind jetzt mit AEBS ausgestattet, die Produktionscode verwenden, der von Simulink-Modellen generiert und durch ausgedehnte Simulationen geprüft wurde. Wir haben das Design unseres Sensorfusionssystems in Scanias adaptivem Geschwindigkeitsregelungssystem wiederverwendet. Derzeit befinden sich mehr als 100.000 Einheiten auf der Straße im Einsatz.