Autonomes Fahren & fortgeschrittene Fahrerassistenzsysteme

Fahrerassistenz (ADAS) ist in neuen europäischen Pkw inzwischen Standard, während fahrerlose Dienste (Stufe 4) Stadt für Stadt wachsen, vor allem in den USA und China sowie in ersten europäischen Pilotprojekten. Derselbe KI-Aufbau, also Sensorfusion, gelernte Wahrnehmung, Vorhersage und Planung, bedient beides. Für die meisten Unternehmen besteht die realistische Rolle darin, zertifizierte Komponenten zu integrieren und zu validieren oder Shuttles und Flotten zu betreiben, nicht darin, einen Fahrstack von Grund auf zu entwickeln.

Problem & Nutzen

• Heute: Menschliches Versagen ist ein wesentlicher Faktor bei Verkehrsunfällen; im Berufsverkehr fehlen Fahrerinnen und Fahrer; städtische Shuttles und Logistik-Hubs kämpfen mit Personalmangel und Nachtbetrieb.
• KI-Nutzen: gleichbleibende Aufmerksamkeit (Spurhalten, Notbremsen, adaptiver Tempomat), Potenzial für fahrerlosen Betrieb in abgegrenzten Bereichen (Autobahn, Betriebshof, georeferenziertes Stadtgebiet) und niedrigere Betriebskosten pro Kilometer, sobald keine Sicherheitsfahrer mehr nötig sind.
• Vorteile: Die EU-Verordnung über die allgemeine Fahrzeugsicherheit (2019/2144) macht Notbremsassistent, Spurhalteassistent und Müdigkeitswarnung für neue Fahrzeugtypen verpflichtend, gestützt auf die Schätzung der Kommission, dass diese Systeme Leben retten können; den konkreten Sicherheitsgewinn je System sollten Sie Typgenehmigungs- und Versichererstudien entnehmen, nicht Herstellerversprechen [1].

Varianten

• ADAS der Stufe 2 / 2+ (Fahrer überwacht): Spurführung, adaptiver Tempomat, freihändiger Autobahnassistent, Einparkhilfe. In der EU durch UN R171 (DCAS) geregelt [2].
• Stufe 3 (bedingte Automatisierung): Das System fährt, der Fahrer muss auf Aufforderung übernehmen; UN R157 ALKS, in Deutschland zusätzlich das Gesetz zum autonomen Fahren (StVG, seit 2021 in Kraft) [2][3].
• Robotaxis und Shuttles der Stufe 4: fahrerloser Dienst in einem georeferenzierten Gebiet; in Deutschland der StVG-Rahmen für Stufe 4 mit Technischer Aufsicht und Genehmigung des Betriebsbereichs durch KBA und Landesbehörden; die EU-Verordnung 2022/1426 regelt die Typgenehmigung vollautomatisierter Fahrzeuge in kleinen Serien [3][4].
• Autonomer Lkw-Verkehr und Hof-/Hub-Logistik: Autobahn von Hub zu Hub und Betrieb auf geschlossenem Gelände; zu Bergwerken und geschlossenen Geländen siehe ROBO-022.
• Hier nicht behandelt: Fahrer- und Innenraumüberwachung (VIS-028), Züge (ROBO-019), Gehwegroboter (ROBO-020).

So funktioniert es

1. Sensoren (Kamera, Radar, Lidar, GNSS/IMU)
2. Wahrnehmung (Erkennung, Segmentierung, Fahrspuren, Freiraum, Tracking, Belegung)
3. Lokalisierung & Karte (HD-Karte oder kartenarm)
4. Prädiktion (Absicht und Trajektorien anderer Verkehrsteilnehmer)
5. Planung (Verhalten + Bewegung, gelernt oder regelbasiert, mit Sicherheitshülle)
6. Regelung (Lenken, Bremsen, Beschleunigen)
7. Sicherheitsmonitor / Rückfallebene (Manöver zur Risikominimierung, Fahrerübernahme oder Fernunterstützung)
8. Flotten-Datenschleife (Logging
9. Triage
10. Labeling
11. Nachtraining
12. Simulation
13. Freigabe)

• Architekturen: klassische modulare Stacks (getrennte Wahrnehmung, Vorhersage und Planung) im Vergleich zu durchgängig gelernten Fahrmodellen (End-to-End), die Sensoreingaben direkt auf Trajektorien abbilden; die meisten Serienprodukte sind 2026 Hybride mit einem gelernten Kern und einer regelbasierten Sicherheitsschicht.
• Wahrnehmung: Multi-Kamera-Transformer in Vogelperspektive, Radar-/Lidar-Fusion, Belegungsnetze (Occupancy Networks).
• Mensch-in-der-Schleife (Human-in-the-Loop): der Fahrer bei Stufe 2/3, ein technischer Aufseher oder Fernbediener bei Stufe 4 und Ingenieurinnen und Ingenieure, die jede Software-Freigabe über den Sicherheitsnachweis abnehmen.

Datenaufbereitung

Die Daten sind hier aufgezeichnete Flottenfahrten (Kamera, Radar, Lidar, CAN-Bus), HD-Karten und simulierte Szenarien. Sie liegen typischerweise in Fahrzeug-Loggern, im Objektspeicher und auf Engineering-Dateiablagen, selten im ERP oder DMS. Typische Lücken sind fehlende Zeitsynchronisation zwischen den Sensoren, nicht gelabelte Fahrten, doppelte oder fast identische Clips, schlechte Abdeckung seltener Situationen (Nacht, Regen, Radfahrer) und personenbezogene Daten im Material (Gesichter, Kennzeichen).

Schritte der Aufbereitung: Quellen und Formate erfassen (siehe PREP-001 und GUIDE-003), Daten aus Loggern und Altsystemen herausholen (PREP-005), vor dem Labeln ein Kategorienschema festlegen (PREP-019), gemeinsam mit Fachleuten einen szenariobasierten Test- und Auswertungsdatensatz aufbauen (PREP-018) und Gesichter und Kennzeichen vor der weiteren Verwendung anonymisieren (PREP-022). Werkzeuge: ROS-2-Bag-Werkzeuge, automatisches Labeln mit Foundation-Modellen plus menschliche Prüfung, Szenariokataloge in ASAM OpenSCENARIO. Datenaufbereitung, Labeln und Szenario-Kuratierung machen typischerweise weit mehr als die Hälfte des Gesamtaufwands aus; für Käufer zertifizierter Komponenten schrumpft sie auf die ODD-Dokumentation und Validierungsdaten.

Umsetzungswege

Welcher Weg für wen

• Enterprise (Fahrzeughersteller, Tier-1-Zulieferer, Flottenbetreiber): Weg B, weil der Fahrstack strategisch ist und die eigentliche Arbeit im Cloud-Datenkreislauf (Speicher, Labeln, Training, Simulation) rund um zertifizierte Komponenten im Fahrzeug liegt.
• Entwickler: Weg C, weil Autoware, CARLA und offene Datensätze eigene Forschungs- und Integrationsarbeit ohne Anbieterbindung ermöglichen.
• Öffentlicher Sektor (Verkehrsbehörden, kommunale Shuttle-Betreiber): Weg A, weil typgenehmigte Shuttles und Betreiberdienste mit klarem Sicherheitsnachweis und Support die einzige beschaffbare Option sind.

Weg A — Kaufen (Standardsoftware)

• ADAS- und Automated-Driving-Stacks für Fahrzeughersteller und Tier-1-Zulieferer: Mobileye (EyeQ-Chips, SuperVision, Chauffeur, Drive), NVIDIA DRIVE (Plattform Hyperion, DriveOS, zertifiziertes Sicherheits-Betriebssystem), Qualcomm Snapdragon Ride, Bosch und ZF (EU), Continental und Aumovio (EU), Valeo (EU), Wayve (UK, Fahrsoftware mit verkörperter KI), Momenta, Applied Intuition (Werkzeuge und Fahrzeug-Betriebssystem).
• Fahrerlose Dienste und Shuttles: Waymo, Baidu Apollo Go, Pony.ai, WeRide (Betreiber der Stufe 4); in Europa MOIA/VW (ID. Buzz AD), Holon, Karsan, Oxa, Verne und Shuttles aus der EasyMile/Navya-Linie; Betreiber wie KIRA (DB, Deutschland) führen Pilotprojekte durch.
• Wählen Sie A, wenn: Sie Flotten-, Kommunal- oder Verkehrsbetreiber sind oder ein Fahrzeughersteller, der zertifizierte Rechenplattformen und Software integriert. Prüfen Sie Typgenehmigungsstatus, ODD (Operational Design Domain, Betriebsbereich), Sicherheitsnachweis und Update-Support.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Die Cloud dient dem Datenkreislauf, nicht dem Fahren: Objektspeicher und Labeln, Training auf verwalteten GPU-Clustern und Simulation in großem Maßstab (NVIDIA Omniverse/Cosmos, AWS, Azure, EU-Clouds wie STACKIT, OVHcloud). Bild-Sprach-Modelle helfen beim automatischen Labeln, bei der Suche in Flottendaten („Regen bei Nacht mit Radfahrern finden“) und beim Erzeugen von Szenarien.
• Echtzeit-Fahrentscheidungen hängen nie von einer Cloud-API ab; die Verbindung dient nur der Teleoperation, Karten und OTA-Updates.

Weg C — Selbst betreiben (Open Source)

• Stacks: Autoware (Open Source, ROS 2, in Shuttles und Forschung eingesetzt), Apollo (Baidu), openpilot (comma.ai, Stufe 2 für unterstützte Fahrzeuge, für Forschung und Hobby, rechtlichen Status je Land prüfen).
• Modelle und Daten: Forschungsmodelle im Stil von BEVFormer/UniAD, offene Datensätze (nuScenes, Waymo Open Dataset, Argoverse 2, KITTI), meist unter nicht-kommerziellen Lizenzen; prüfen Sie die Bedingungen vor kommerzieller Nutzung.
• Simulation: CARLA, ASAM OpenSCENARIO/OpenDRIVE für Szenarien.
• Hardware: HW4 für Training und Simulation; die Rechenplattform im Fahrzeug sind Automotive-SoCs (Klasse NVIDIA Orin/Thor), außerhalb der HW-Stufen.

Weg D — Eigenes Training

Nur für Fahrzeughersteller, Tier-1-Zulieferer und gut finanzierte Start-ups. Erfordert Fahrdaten im Flottenmaßstab über Wetter, Länder und Grenzfälle hinweg, eine Pipeline zum automatischen Labeln, große GPU-Cluster und eine Organisation für funktionale Sicherheit (ISO 26262, SOTIF ISO 21448). Die typische Beteiligung von KMU beschränkt sich auf Nischenbereiche wie Shuttles auf Privatgelände, Hoftraktoren oder spezialisierte Wahrnehmungsmodule.

Stand der Technik (2026)

• End-to-End- und Foundation-Modell-Fahren: Transformer-Modelle, trainiert auf großen Flottendaten, wobei Ideen aus Bild-Sprach-Handlungs-Modellen (ROBO-004) in die Fahrforschung einfließen, Szenen deuten und Erklärungen liefern.
• Fahrerlose Dienste im großen Maßstab: Waymo und chinesische Betreiber bieten kommerzielle Robotaxi-Dienste der Stufe 4 in mehreren Städten an; europäische Angebote bleiben Pilotprojekte und kleine Einsätze, wobei Großbritannien und Deutschland die aktivsten Märkte sind. Aktuelle Städtelisten finden Sie auf den Seiten der Betreiber.
• Freihändige Systeme der Stufe 2 werden breit verkauft; beaufsichtigte Produkte im Stil von „Full Self-Driving“ durchlaufen in Europa die Zulassung nach UN R171, die einschränkt, was ein System der Stufe 2 tun darf.
• Simulation und synthetische Daten: generative Weltmodelle und neuronale Rekonstruktion ermöglichen geschlossene Tests seltener Szenarien (ROBO-010).
• Grenzen: seltene Ereignisse (ungewöhnliche Objekte, Baustellen, schlechtes Wetter, Sensorverschlechterung), unzuverlässiges Verhalten außerhalb der ODD, schwierige statistische Sicherheitsnachweise, Übervertrauen des Fahrers bei Stufe 2 und die schiere Kostenlast der Validierung.

Gemeinsame Bausteine & Kombinationen

• Gemeinsamer Stack: Objekterkennung, Tracking, 3D-Sehen und Edge-Inferenz teilt dieser Anwendungsfall mit ROBO-016 (Maschinensicherheit), ROBO-019 (Schiene), ROBO-020 (Gehwegroboter), ROBO-022 (Transport) und ROBO-015.
• Simulation und digitale Zwillinge: ROBO-010; Grundlagen für Handlungsstrategien: ROBO-004.
• Angrenzend: VIS-028 (Fahrerüberwachung, in neuen EU-Fahrzeugen verpflichtend), PRED-030 (Telematik-Bewertung), OPT-001 (Routenplanung für Robotaxi- und Shuttle-Flotten).

Aufwand, Kosten & Kennzahlen

• Weg A: Monate für Pilotprojekte mit Shuttles oder Fahrzeugintegration; die Hauptkosten sind Fahrzeuge, Sicherheits- personal, Versicherung und Genehmigungen.
• Weg C: ein Forschungsprototyp in Monaten; eine serienreife Freigabe braucht Jahre und eine Sicherheitsorganisation.
• Weg D: mehrjähriges Programm mit Hunderten Ingenieurinnen und Ingenieuren auf Herstellerebene.
• Kennzahlen: Systemabschaltungen oder Eingriffe pro 1.000 km, Kollisions- und Beinaheunfallrate im Vergleich zu einer menschlichen Referenz, ODD-Abdeckung, mittlere Strecke zwischen sicherheitsrelevanten Ereignissen, Verfügbarkeit, Szenarioabdeckung in der Simulation, Fernunterstützungsanfragen pro Stunde.

Menschen & Veränderung

Die Geschäftsführung entscheidet über die Rolle (integrieren, validieren oder betreiben) und finanziert die Sicherheitsorganisation. Die Fachabteilungsleitung und die Endnutzer (Testfahrer, Sicherheitsfahrer, Fernbediener) sind von Anfang an dabei, weil Übernahmekonzepte und Regeln zur Fahrerüberwachung von ihnen abhängen. IT-Sicherheit und Recht/Compliance werden früh für Typgenehmigung, Produkthaftung und OTA-Updates gebraucht; die Datenschutzbeauftragte bzw. der Datenschutzbeauftragte für Kameraaufnahmen und Fahrerüberwachung (GUIDE-005), wo eine DSFA wahrscheinlich ist.

Betriebsrat: kommt darauf an. Fahrerüberwachung, Flottentelemetrie und Innenraumkameras eignen sich technisch zur Verhaltensüberwachung, daher gilt in der Praxis § 87 Abs. 1 Nr. 6 BetrVG, wo immer Beschäftigte fahren oder überwachen; § 90 Abs. 1 Nr. 3 verlangt rechtzeitige Information über KI-geplante Arbeitsabläufe. Öffentliche Betreiber beteiligen den Personalrat. Siehe GUIDE-004.

KI-Kompetenz: Fördern Sie die Kompetenz der Beschäftigten mit Schulungen für Bediener und Sicherheitsfahrer (GUIDE-006). Typische Sorgen sind Arbeitsplatzverlust und Haftung nach Unfällen; begegnen Sie ihnen mit einer klaren Rollenbeschreibung, transparentem Umgang mit Vorfällen und einem Start mit einer kleinen Pilotgruppe auf einer Strecke oder in einer ODD (GUIDE-008). Der Mensch behält die Kontrolle durch Sicherheitsfahrer, Teleoperation und definierte Manöver zur Risikominimierung.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): KI-Sicherheitskomponenten in Fahrzeugen werden über das Typgenehmigungsrecht behandelt (Anhang I Abschnitt B); die Hochrisiko-Anforderungen der KI-Verordnung gelten nicht unmittelbar, müssen aber beim Erlass delegierter Rechtsakte zu den Fahrzeugverordnungen berücksichtigt werden (Art. 2 Abs. 2, Art. 102 ff.) [5]. Anwendungen außerhalb der Typgenehmigung, etwa Fahrzeuge auf Privatgelände, können Maschinen oder Hochrisiko-Sicherheitskomponenten sein. Art. 5: Die biometrische Ableitung von Emotionen aus Fahrergesichtern ist im Arbeitskontext (Flottenfahrer) verboten; die Fahrerüberwachung muss auf Müdigkeit und Ablenkung beschränkt bleiben.
• Fahrzeugrecht: UN R157 (ALKS), UN R171 (DCAS), EU 2022/1426 (ADS), Verordnung über die allgemeine Fahrzeugsicherheit 2019/2144, UN R155 (Cybersicherheit) und R156 (Software-Updates); Deutschland: StVG-Rahmen für Stufe 4 und AFGBV [2][3][4].
• DSGVO: Kamera- und Sensordaten erfassen Gesichter, Kennzeichen und Aufenthaltsorte Unbeteiligter; Flotten- und Fahrerdaten sind personenbezogene Daten. Nötig sind eine Rechtsgrundlage, Datenminimierung, Anonymisierung (Unkenntlichmachung) im Fahrzeug vor dem Hochladen, Speicherfristen und eine DSFA; die EDPB-Leitlinien 01/2020 zu vernetzten Fahrzeugen gelten [6].
• Haftung: Die Produkthaftungsrichtlinie (EU) 2024/2853 erfasst Software; Stufe 3/4 verschiebt die Haftung hin zu Halter und Hersteller.
• Gegenmaßnahmen: definierte ODD, Sicherheitsnachweis nach ISO 26262/SOTIF/UL 4600, Redundanz, Fahrerüberwachung, gestufte Einführung, Meldung von Vorfällen, Cybersicherheits-Managementsystem.

Erste Schritte

1. Anwendungsfall und ODD festlegen: Assistenz oder fahrerlos, öffentliche Straße oder Privatgelände, Geschwindigkeit, Wetter.
2. Rechtlichen Weg prüfen: Typgenehmigung, StVG-Genehmigung des Betriebsbereichs oder Maschinenrecht für geschlossene Gelände.
3. Bei Shuttles: vor jeder Entscheidung zum Eigenbau ein Pilotprojekt mit einem etablierten Betreiber durchführen.
4. Für Entwickler: Autoware oder CARLA mit einem offenen Datensatz ausführen, um Stack und Szenario-Werkzeuge kennenzulernen.
5. Vor der Datenerhebung einen DSGVO-konformen Datenkreislauf einrichten (Anonymisierung im Fahrzeug, Speicherfristen, DSFA).

Quellen

1. Regulation (EU) 2019/2144 General Safety Regulation: https://eur-lex.europa.eu/eli/reg/2019/2144/oj
2. UNECE, vehicle regulations (UN R157 ALKS, UN R171 DCAS, R155, R156): https://unece.org/transport/vehicle-regulations
3. German Autonomous Driving Act (StVG, Level 4 framework), Federal Motor Transport Authority (KBA): https://www.kba.de/EN/Home/home_node.html
4. Implementing Regulation (EU) 2022/1426 on ADS type-approval: https://eur-lex.europa.eu/eli/reg_impl/2022/1426/oj
5. Regulation (EU) 2024/1689 (AI Act): https://eur-lex.europa.eu/eli/reg/2024/1689/oj
6. EDPB Guidelines 01/2020 on connected vehicles: https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-012020-processing-personal-data-context_en
7. Autoware Foundation: https://autoware.org
8. NVIDIA DRIVE: https://developer.nvidia.com/drive
9. Mobileye: https://www.mobileye.com
10. Waymo Open Dataset: https://waymo.com/open/