Wie viele Umgebungssensoren werden benötigt?
In den nächsten Jahren werden Unternehmen in der Automobil-, Landwirtschafts-, Bergbau- und anderen Industrien im Bereich des automatisierten Fahrens ihre Aktivitäten zur Erreichung der Autonomielevel 3 und 4 beschleunigen. Um diese Autonomielevel zu erreichen, muss die Anzahl der Perzeptionssensoren deutlich erhöht werden. Grundsätzlich ist es an der Zeit, dass Stakeholder die Frage beantworten, wie viele Umgebungssensoren für die Autonomielevel 3 und 4 benötigt werden und welche neuen Herausforderungen sich daraus ergeben. "
Unterschätzen Sie nicht die Herausforderung der Entwicklung von Multisensoranwendungen.
Die Hersteller (OEMs) statten ihre Fahrzeuge bereits mit der notwendigen Hardware aus, die für eine hohe Automatisierung in der Zukunft erforderlich ist. Sie schätzen, dass 20-30 Sensoren erforderlich sind, um dieses Ziel zu erreichen. Dies bedeutet, dass Fahrzeuge zunehmend mit zahlreichen Kameras, Radar-, Lidar-, Audio-, Ultraschall-, GPS/GNSS- und anderen Umgebungssensoren ausgestattet sein werden. Diese Sensoren haben unterschiedliche Abtastraten, Datenschnittstellen und Datenformate. Darüber hinaus sind verschiedene Abteilungen, Teams, Partner und Spezialisten an der Entwicklung komplexer Software (SW)-Funktionalitäten beteiligt. Daher sollte die Herausforderung der Entwicklung von Multisensoranwendungen für den Einsatz in Fahrzeugen nicht unterschätzt werden.
Anforderungen an die Entwicklung von ADAS/AD-Anwendungen
Schnittstellen für Sensoren und I/O-Geräte
ADAS/AD-Entwickler müssen Schnittstellen für Sensoren und Busse entwickeln, um auf Daten aus diesen Quellen in einem Format zuzugreifen, das von nachgelagerten Komponenten übernommen werden kann. Ingenieure und Entwickler müssen effiziente und vielseitige Werkzeuge für die Erfassung von Rohdaten und Daten mit hoher Bandbreite, die Datenverarbeitung, die Datensynchronisierung und die Datenfusion entwickeln.
Rapid Prototyping und Serienimplementierung
Wozu sind auwendige Prototypen gut, wenn sie nicht in Serienumgebungen eingesetzt werden können? Diese Situation ist vielen ADAS/AD-Software-Entwicklungsteams ein Dorn im Auge. Viele Ingenieure verwenden Open-Source-Software (OSS) wie das Robot Operating System (ROS). Diesen Werkzeugen fehlt die Unterstützung für funktionale Sicherheitsnormen wie ISO 26262 für Kraftfahrzeuge, ISO 25119 für die Landwirtschaft, ISO 219014-1 für Erdbewegungsmaschinen und andere. Darüber hinaus gibt es keine solide Unterstützung für Standards wie CAN, CAN-FD, Ethernet etc.
Kollaboration
Die Zusammenarbeit zwischen Teams und mit Partnern ist ein wichtiges Element bei der Entwicklung moderner Anwendungen. Diese Anforderung ist besonders wichtig für multinationale Unternehmen, in denen sich die Projektteams an verschiedenen geografischen Standorten befinden können. Die Zusammenarbeit zwischen verschiedenen Partnern, Teams und Spezialisten erfordert einen benutzerfreundlichen Rahmen für alle, die an der Software-Entwicklung beteiligt sind. Dieser Rahmen sollte idealerweise einen Schutz des geistigen Eigentums (IP) bieten, der die gemeinsame Entwicklung mit Partnern ohne Risiken ermöglicht. Darüber hinaus sollte die Plattform auch verschiedene Programmiersprachen wie Python und Simulink unterstützen.
Wiederverwendung von Codes/Algorithmen
Die Entwicklung von Algorithmen für ADAS/AD ist ein ressourcenintensives Unterfangen. Im Wesentlichen ist es wichtig, dass der entwickelte Code bzw. die entwickelten Algorithmen in anderen Projekten und in der Zukunft wiederverwendet werden können. Darüber hinaus erfordern zuverlässige Anwendungen einheitliche Code-Schablonen und Kodierungsrichtlinien für eine hohe Wartbarkeit der SW-Funktionen. Das Erreichen dieses Ziels kann sich als schwierig erweisen, wenn OSS von verschiedenen Entwicklern verwendet wird. Die komponentenbasierte Programmierung ermöglicht die stabile Wiederverwendung von Komponenten, was nicht nur die Wiederverwendung von Code, sondern auch die gemeinsame Nutzung erleichtert.
Einfaches Debugging von Anwendungen
ADAS/AD-Projekte sind komplex und erfordern mehrere Anwendungen für eine erfolgreiche Umsetzung. Dennoch ist Schnelligkeit von entscheidender Bedeutung und die rasche Markteinführung von Anwendungen entscheidend. Die Fähigkeit, Anwendungen schnell zu debuggen, ist essentiell wichtig. Dies verkürzt die Zeit, die für die Entwicklung, den Test und die Bereitstellung von Anwendungen benötigt wird.
RTMaps als ADAS/AD-Software-Entwicklungsplattform
Real Time Multi-Sensor Applications (RTMaps) ist eine Software-Entwicklungsplattform, die vom frühen Prototyping bis zur Serie reicht. Mit folgenden RTMaps-Funktionen können Entwicklungsteams die Software-Entwicklung beschleunigen.
Vom Prototyping zur Serie
Der Prozess der Entwicklung funktionaler ADAS/AD-Anwendungen wird durch die Herausforderung der Bereitstellung von Anwendungen in der Produktion verlangsamt. Viele der bestehenden Lösungen wie ROS sind nicht serienreif. Hohe Latenzzeiten, nicht-deterministisches Verhalten und fehlende Unterstützung der funktionalen Sicherheit sind einige der größten Stolpersteine beim Einsatz von OSS. RTMaps ist serienreif und ermöglicht es Anwendern, ihre Anwendungen auf Linux oder Windows zu entwickeln und diese Anwendungen auf RTOS wie QNX einzusetzen. Auch ist die Hardware-Abstraktion mit RTMaps möglich, wenn die Software auf X86- und ARM-basierten Geräten ausgeführt wird.
Weniger Komplexität in der Software-Entwicklung
Obwohl Skripte in RTMaps erstellt werden können, ist die Möglichkeit der komponentenbasierten Entwicklung von entscheidender Bedeutung, um die Komplexität der Software-Entwicklung zu reduzieren. Die komponentenbasierte Entwicklung vereinfacht das Debuggen und Testen von Anwendungen sowie die Zusammenarbeit in Teams. Außerdem wird die Komplexität des Testens verringert, da die Anforderungen einfacher definiert werden können und das Verhalten einer Anwendung getestet werden kann, indem sie verschiedenen Eingaben ausgesetzt wird.
ISO-26262-Zertifizierung
Für sicherheitskritische Anwendungen, z. B. in der Automobilindustrie, ist eine Homologation erforderlich. Für die Automobilindustrie ist ISO26262 die Norm, die erfüllt werden muss. Während das gesamte Framework eines automatisierten Fahrzeugs zertifiziert werden muss, ist es wichtig, dass die Middleware bereits zertifiziert ist, um die für die Zertifizierung erforderlichen Ressourcen und Aufwände zu reduzieren. Mit der bevorstehenden Zertifizierung von RTMaps nach ISO26262 ASIL-B können Anwender Multicore-Funktionen sicher in verschiedenen RTOS wie QNX und Embedded Linux ausführen, Daten kopierfrei verarbeiten, RTMaps-Komponenten aus dem dSPACE Seriencode-Generator TargetLink generieren und Latenzen verschiedener Komponenten überwachen.
600+ Sensor- und I/O-Komponenten
Eine Plattform mit vielen Komponenten, die den Anschluss von Sensoren wie Lidar, Radar und Kamera auf der Grundlage von Bussen wie CAN, CAN-FD und Ethernet ermöglichen, ist von unschätzbarem Wert. In vielen Fällen verfügen OSS wie ROS über Knoten oder Schnittstellen, die von der Community entwickelt wurden. Speziell für das Software-Prototyping bietet RTMaps eine fertige Schnittstelle zu ROS, so dass beide Anwendungen einfach miteinander verbunden werden können. Die Verwendung von OSS für die Serienentwicklung erfordert jedoch normalerweise erhebliche Investitionen in die Validierung und Wartung dieser Komponenten. RTMaps verfügt über mehr als 600 Komponenten, die professionell entwickelt und gewartet wurden. Darüber hinaus bietet der RTMaps AI Store Zugang zu hochmodernen von Partnern entwickelten AI-Modellen.
Im Wesentlichen ist RTMaps die ideale Plattform für die Beschleunigung der Entwicklung von ADAS/AD-Anwendungen, die eine schnellere Markteinführung bei geringeren Gesamtkosten ermöglicht.
