Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03607.jsonl.gz/2819

Wie andere fortschrittliche Fahrerassistenzsysteme (ADAS) verwendet ein AEBS Sensoren, um die Umgebung abzutasten. Sobald eine Kollision bevorsteht, warnt das System den Fahrer mit einem akustischen Signal. Wenn dieser nicht reagiert, löst das System eine Warnbremsung aus. Falls der Fahrer danach noch immer nicht reagiert, aktiviert das System die volle Bremsleistung, um die Kollision zu vermeiden. Das Notbremssystem AEBS verfügt zudem über einen «Bremsassistenten»: Wenn der Fahrer bremst, aber nicht mit ausreichender 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 ausschliesslich Radar verwendet, wäre es schwierig, ein am Fahrbahnrand geparktes Auto von einem auf der Fahrbahn zu unterscheiden. Kameras können dagegen die Grösse 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).
Scania entwickelte ein System zur Sensorfusion, 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 muss.
Die Scania-Entwickler benutzten zuerst eine modellbasierte Entwicklung, um ein adaptives System zur Geschwindigkeitsregelung mit Radartechnologie zu entwickeln. Ein Sensorfusionssystem hatten sie zuvor noch nie entwickelt. Da es sich um ein neues Design handelte, brauchte man eine lesbare, verständliche Architektur, um den Signalfluss abzubilden. Da zahlreiche Iterationen bei der Entwicklung anstanden, suchten die Ingenieure einen einfachen Weg, um Ergebnisse anzuzeigen und Fehler im Design zu beheben.
Zusätzlich wollte man durch die Codegenerierung Zeit sparen, wobei aber der Code effizient sein musste, da die CPU-Auslastung der elektronischen Steuereinheit (Electronic Control Unit, ECU) bereits bei 60% lag, als mit dem Sensorfusionsprojekt begonnen wurde. Zuletzt musste das Design eingehend geprüft werden. Geplant waren Simulationen der Sensordaten auf der Grundlage von über 1,5 Mio. km. Die modellbasierte Entwicklung erfüllte alle diese Anforderungen.
Zunächst wurde das Systemdesign in funktionelle Einheiten aufgeteilt, wie Objektzuordnung und Positionierung des projizierten Pfads, danach wurde für jede Einheit ein separater Simulink-Block generiert. Das Ergebnis war eine klare Softwarearchitektur mit gut definierten Schnittstellen. Die Fachleute erstellten einen 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 das Simulink-Modell ein. Diese Algorithmenblöcke machten es dem Team einfach, ihre Algorithmen zusammenzuführen und sie in das Steuersystem zu integrieren. Um das anfängliche Design zu debuggen und zu verfeinern, führten die Scania-Techniker Simulationen mit aufgezeichneten Radarsensordaten, den zugehörigen Kamerabildern sowie weiteren Fahrzeugsensordaten durch. Mit einem Visualisierungstool in MATLAB, das Sensorfusionsdaten synchronisiert, liess sich mit einer Webkameraansicht der umgebende Verkehr anzeigen. Das Tool macht sich die objektorientierte Programmierung mit MATLAB zunutze und verwendet eine MATLAB-Klasse, um jedes von einem Sensor erkannte Objekt und das vom Sensorfusionssystem wahrgenommene Objekt zu repräsentieren. Diese MATLAB-Objekte erlaubten es, schnell im zeitlichen Ablauf vor- und zurückzuspringen, während Daten visualisiert wurden. Dieses Tool kam auch während der Strassenversuche zum Einsatz, um Livedaten aus dem Fahrzeugnetzwerk anzuzeigen.
Um das Sensorfusionssystem in der ECU einzusetzen, erstellten die Entwickler C-Code aus dem Simulink-Modell mit Embedded Coder. Dank der Codegenerierung war eine schnelle Implementierung möglich und es liessen sich Codierungsfehler vermeiden. Der Grossteil der Ressourcen des ECU-Prozessors wurden Wartungsfunktionen zugeordnet – Überwachung von Armaturenbrettanzeigen, physikalische Schätzungen, Daten-Gateway, adaptive Geschwindigkeitsregelung, usw. Das hatte zur Konsequenz, dass das anfängliche Design optimiert werden musste, um dessen Effizienz zu steigern.
Um die Verarbeitungslast weiter zu reduzieren, teilte man 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, wurden diese in abwechselnden Zyklen durchgeführt. Um das Stocken des Prozessors bei trigonometrischen Funktionen zu mindern, schrieben die Scania-Ingenieure trigonometrische Näherungsfunktionen in C und riefen diese 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.
Anhand aller auf der ECU vorhandenen Flottentestdaten führte Scania Simulationen durch, um interessante Fahrszenarien zu identifizieren – Szenarien, in denen das AEBS eingriff, um den Fahrer zu warnen oder die Bremse zu betätigen, und Szenarien, 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 Szenarien analysierten die Experten die Leistung des AEBS, um Optimierungen durchzuführen.
Jede Aktualisierung der AEBS-Software verlangte nach neuen Simulationen. Bei mehr als 80 TByte realer Verkehrsdaten aus über 1,5 Mio. km Fahrt dauerte es jedoch mehrere Tage, eine einzelne Simulation durchzuführen.
Aus diesem Grund bauten die Ingenieure einen Emulator unter Verwendung von mit Embedded Coder generiertem Code aus den Simulink-Modellen. Der Emulator liest und schreibt die gleichen MAT-Dateien wie das Simulink-Modell, führt aber Simulationen 150-mal schneller durch. Spezielle MATLAB-Skripte liessen die bis zu 300 Simulationen parallel auf speziellen Multiprozessor-Servern sowie auf mehreren Computern laufen. Mit diesen Optimierungen liess sich die Simulationszeit auf 12 Stunden reduzieren. Die Identifizierung und Klassifikation von potenziell interessanten Szenarien innerhalb von TByte von Daten war eine langwierige und zeitaufwendige Aufgabe. Ein MATLAB-basiertes Situationsklassifizierungs-Hilfsmodul (Situation Classification Assistant Module) automatisierte einen Teil der immer wiederkehrenden Simulationen. Das Tool generierte eine Eventliste aus den Simulationen, wie Kollisionswarnungen, Warnbremsvorgänge und Vollbremsungen, die vom System durchgeführt sowie scharfe Bremsungen und Richtungsänderungen, die vom Fahrer vorgenommen worden waren. Danach liessen sich diese Listen für jeweils zwei Softwareversionen 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 erlaubte es auch, Änderungen schneller vorzunehmen.
Die meisten Scania-LKW und -Busse sind jetzt mit AEBS ausgestattet, die Produktionscode verwenden, der von Simulink-Modellen generiert und durch Simulationen geprüft wurde. Es befinden sich bereits über 100 000 Einheiten auf der Strasse im Einsatz.
Sektion 32: Engineering in der Automation
Sektion 42: Robotics & Systeme
Sektion 19: Embedded Computing