UN R157 begrenzte ALKS ursprünglich auf 60 km/h für Personenkraftwagen; die 01-Serie hob die Grenze auf 130 km/h mit Spurwechselfähigkeit und erweiterte die Regelung auf schwere Fahrzeuge. R157 ist ein bewegtes Ziel.
Cybersicherheit für autonomes Fahren laesst sich nicht darauf reduzieren, einen ECU vor Fernkompromittierung zu schuetzen. Ein Automated Driving System (ADS) trifft Entscheidungen aus Sensoren, Karten, Lokalisierung, Machine-Learning-Modellen, Fahrzeugsteuerung, Cloud-Diensten, Remote-Assistance-Workflows und Flotten-Feedback. Das Sicherheitsziel ist nicht nur, unautorisierten Zugriff zu verhindern. Es geht darum, sicheres, vorhersehbares Verhalten innerhalb der Operational Design Domain zu bewahren und nachzuweisen, was geschehen ist, wenn die Realität von der Erwartung abweicht.
Dieser Nachweis wird immer wichtiger. Die Standing General Order der NHTSA verpflichtet identifizierte Hersteller und Betreiber, qualifizierende Unfälle mit ADS- oder Level-2-Systemen zu melden und liefert der Behoerde so reale Informationen für Untersuchung und Durchsetzung. UN Regulation No. 157 für Automated Lane Keeping Systems verbindet die Zulassung automatisierten Fahrens mit Cybersicherheits- und Software-Update-Anforderungen. Betriebs-Beweismittel, Softwarekonfiguration, Vorfall-Daten und Änderungskontrolle sind heute zentrale Assurance-Assets.
Dieser Leitfaden erklärt, wie Cybersicherheit in das operative Assurance-Modell für ADS und Robotaxi-Flotten eingebaut wird. Er fokussiert auf das besondere Zusammenspiel von Cyber-Risiko, Safety-Verhalten, Remote-Betrieb, Machine Learning und Feld-Beweismitteln, statt ein generisches Sicherheitsprogramm für vernetzte Fahrzeuge zu wiederholen.
Das System über das Fahrzeug hinaus definieren
Ein ADS ist ein soziotechnisches System. Die Assurance-Grenze kann umfassen:
- Sensoren, Compute-Plattformen, Netzwerke, Aktuatoren und Energiesysteme im Fahrzeug.
- Perzeptions-, Praediktions-, Planungs-, Lokalisierungs- und Regelungssoftware.
- Machine-Learning-Modelle sowie Trainings- oder Validierungsdaten.
- Hochauflösende Karten, Lokalisierungs-Korrekturen, Wetter-, Verkehrs- und Baustellendaten.
- Flottenmanagement, Disposition, Telemetrie, Logging und Update-Dienste.
- Remote-Assistance- oder Remote-Operations-Zentren.
- Cloud-Simulations- und Validierungs-Pipelines.
- Mobile Apps und Kunden-Identität.
- Depot-, Lade-, Wartungs- und Kalibrierungssysteme.
- Dritte Dienste und Kommunikationsnetze.
- Menschliche Operatoren, Sicherheitsfahrer, Support-Mitarbeiter und Field-Techniker.
Eine Bedrohung, die in einem nicht-fahrenden Dienst beginnt, kann das Fahrverhalten dennoch beeinflussen. Ein kompromittierter Karten-Feed kann die Lokalisierung verzerren. Ein Remote-Assistance-Account kann betriebliche Entscheidungen exponieren. Ein Depot-Werkzeug kann die Sensor-Kalibrierung verändern. Eine fehlerhafte Flottenkonfiguration kann Software ausserhalb ihrer freigegebenen Bedingungen aktivieren.
Die Architektur muss Daten und Autoritaet zeigen, nicht nur Komponenten. Fragen Sie, welche Quelle eine Entscheidung beeinflussen kann, welches System das Fahrzeug kommandieren kann und welcher Mensch eine Aktion übersteuern, beraten oder freigeben kann.
Sicherheit an die Operational Design Domain binden
Die Operational Design Domain (ODD) definiert die Bedingungen, unter denen das ADS betrieben werden darf. Sie kann Strassentyp, Geografie, Geschwindigkeit, Wetter, Beleuchtung, Verkehr, Baustellen, Konnektivitaet und andere Einschraenkungen umfassen.
Cybersicherheit kann die ODD-Durchsetzung auf mehrere Arten untergraben:
- Manipulation von Orts- oder Kartendaten, sodass das Fahrzeug glaubt, sich im erlaubten Bereich zu befinden.
- Veränderung von Wetter-, Strassenzustands- oder Infrastruktur-Eingaben.
- Änderung von Konfigurationsschwellen, die die Aktivierung steuern.
- Unterdrückung von Health- oder Degradationssignalen.
- Kompromittierung der Flottenautorisierung für eine Route oder ein Servicegebiet.
- Wiedereinspielen eines früheren gueltigen Zustands.
- Änderung von Software- oder Modellversionen, ohne den freigegebenen ODD-Case zu aktualisieren.
Behandeln Sie ODD-Bedingungen als sicherheitsrelevante Assets. Definieren Sie vertrauenswuerdige Quellen, Validierungslogik, Cross-Checks, Aktualitaetsanforderungen und sicheres Verhalten bei widerspruechlichen Eingaben.
Eine nützliche Assurance-Frage lautet: "Welche Beweismittel zeigen für diese Fahrt, dass das Fahrzeug zu jeder relevanten Zeit autorisiert, korrekt konfiguriert und innerhalb seiner freigegebenen ODD betrieben wurde?"
Die Kette von Sensor zu Entscheidung schuetzen
ADS-Sicherheit braucht Traceability vom physischen Input bis zur Fahrzeugaktion.
Sensoren und Schnittstellen
Kameras, Radar, Lidar, GNSS, inertiale Systeme, Ultraschallsensoren und Fahrzeugzustandseingaben können gespooft, geblendet, verdeckt, fehlkalibriert, wiedereingespielt oder getrennt werden. Physische und Cyber-Angriffe überlappen sich oft.
Kontrollen umfassen Eingangs-Plausibilitaet, Sensor-Diversitaet, ggf. authentifizierte interne Kommunikation, Kalibrierungs-Integritaet, Health-Monitoring, Tamper-Erkennung und kontrollierte Degradation.
Perzeption und Fusion
Fehlgeformte Daten können Parser ausnutzen oder adversariale Bedingungen für Machine-Learning-Modelle erzeugen. Fusionslogik sollte inkonsistente Quellen erkennen, statt eine kompromittierte Eingabe zu verstaerken.
Lokalisierung und Karten
Kartendaten, Korrekturen und Geofencing brauchen Quellauthentizitaet, Versionskontrolle, Update-Integritaet und Aktualitaet. Das Fahrzeug sollte Kartenerwartungen gegen Live-Beobachtungen validieren und Cloud-Verfügbarkeit nicht ohne Fallback als Safety-Anforderung behandeln.
Planung und Regelung
Schuetzen Sie Schnittstellen, die Trajektorien, Constraints und Aktuator-Kommandos übertragen. Erzwingen Sie Grenzen und unabhängige Safety-Monitore, damit eine kompromittierte Software-Komponente keine unbeschraenkte Regelung ausgeben kann.
Logging
Erfassen Sie genug Zustand, um die Entscheidung zu rekonstruieren, ohne Logs zu einer neuen Datenschutz- oder Sicherheits-Schwachstelle zu machen. Zeitsynchronisation und Konfigurationsidentitaet sind kritisch.
Sicherheitskontrollen sollten auf jeder Schicht und über den gesamten Pfad getestet werden. Ein sicherer Sensortreiber belegt nicht, dass die End-to-End-Entscheidung resilient ist.
Machine-Learning-Assets und Pipelines schuetzen
Das ML-Modell ist ein Teil einer größeren Lieferkette. Wichtige Assets umfassen Trainingsdaten, Labels, Feature-Pipelines, Modellgewichte, Evaluationsdatensaetze, Simulationsszenarien, Build-Umgebungen, Registries, Deployment-Manifeste und Monitoring-Schwellen.
Bedrohungen umfassen:
- Vergiftete oder qualitativ minderwertige Trainingsdaten.
- Unautorisierte Änderungen an Labels oder Szenarien.
- Modell-Diebstahl oder -Ersatz.
- Kompromittierte Dependencies und Build-Tools.
- Evaluations-Leakage oder Benchmark-Gaming.
- Adversariale Eingaben.
- Ignorierte oder verborgene Drift.
- Auslieferung des falschen Modells an eine Fahrzeugvariante.
- Unzureichende Trennung zwischen Forschungs- und Produktionsumgebungen.
Kontrollen sollten etablieren:
- Datensatz-Provenienz und Zugriffskontrolle.
- Versionierte Modell- und Daten-Linage.
- Signierte Artefakte und kontrollierte Registries.
- Reproduzierbares Training und Evaluation.
- Unabhängige Validierungsdatensaetze.
- Freigabe-Gates für Deployment.
- Varianten- und Hardware-Kompatibilitaet.
- Monitoring auf Drift und anomales Verhalten.
- Rollback und Quarantaene.
- Traceability von Modelländerung zu betroffenen Szenarien und Fahrzeugen.
Behaupten Sie nicht, ein Modell sei sicher, weil es einen fixen adversarialen Testset bestanden hat. Bedrohungen entwickeln sich, und Betriebsbedingungen können von Laborannahmen abweichen.
Remote Assistance ist eine privilegierte Schnittstelle
Robotaxi- und ADS-Flotten können Remote-Assistance nutzen, wenn das Fahrzeug auf eine ungewoehnliche Situation trifft. Der Mensch kann Kontext liefern, aus Optionen wählen, ein Manoever genehmigen oder in manchen Designs direkter eingreifen.
Diese Schnittstelle verdient dieselbe Strenge wie ein sicherheitskritisches Steuerungssystem.
Definieren Sie:
- Die exakte Autoritaet des Remote-Operators.
- Ob der Operator beraet, autorisiert oder direkt steuert.
- Bedingungen, unter denen Assistance erlaubt ist.
- Fahrzeug- und Sitzungs-Authentifizierung.
- Operator-Identität, Qualifikation und Standort.
- Starke Authentifizierung und Privileged-Access-Management.
- Integritaet und Aktualitaet von Kommandos oder Ratschlaegen.
- Latenz, Konnektivitaet und Verhalten bei Verbindungsverlust.
- Aufzeichnung, Review und Datenschutz.
- Funktionstrennung und Supervisor-Eskalation.
- Begrenzung der Anzahl Fahrzeuge je Operator.
- Notfall- und Kompromittierungsverfahren.
Ein kompromittierter Remote-Assistance-Account kann skalierbaren Schaden anrichten. Nutzen Sie Least Privilege, Geraete-Posture, Netzsegmentierung, Sitzungsaufzeichnung, Verhaltensüberwachung und schnelle Revokation.
Das Fahrzeug muss die Verantwortung für Safety-Constraints behalten. Eine Remote-Anweisung darf unabhängige Grenzen nicht nur deshalb umgehen, weil sie von einem authentifizierten Operator stammt.
Flotten- und Dispositions-Sicherheit
Flottensysteme entscheiden, wo Fahrzeuge fahren, welche Software und Konfiguration sie nutzen, wie sie geroutet werden und wann sie in Betrieb gehen. Diese Systeme können ebenso folgenreich sein wie Fahrzeugcode.
Schuetzen Sie:
- Fahrzeug-Enrollment und -Identität.
- Disposition und Routenvergabe.
- Geofence- und Servicegebiets-Konfiguration.
- Wartungs- und Release-Status.
- Funktionen zum Remote-Disable oder zur Wiederherstellung.
- Lade- und Depot-Betrieb.
- Kundenabholung und Identitätsabgleich.
- Flottenweite Feature-Flags.
- Massenaktionen und Kampagnen-Management.
Eine administrative Massenaktion sollte staerkere Freigaben verlangen als eine Einzelfahrzeug-Aktion. Nutzen Sie gestaffelten Rollout, Gruppenlimits, Änderungsfenster, Peer-Review und automatische Rollback-Kriterien.
Mandanten- und Regionsisolation sind wichtig für Betreiber, die mehrere Programme oder Partner führen. Ein Support-Nutzer einer Stadt darf nicht durch Ändern eines Objekt-Identifiers Zugriff auf eine andere Flotte erhalten.
Software- und Konfigurations-Änderungssteuerung
ADS-Verhalten kann sich durch Code, Modelle, Karten, Schwellen, Policies, Sensor-Kalibrierung, Infrastruktur oder Backend-Logik ändern. Der Assurance-Prozess muss all dies als Konfiguration anerkennen.
Bestimmen Sie für jede Änderung:
- Welche Funktionen und Safety- oder Cybersecurity-Claims sind betroffen?
- Welche ODD-Bedingungen oder Szenarien benoetigen eine Neubewertung?
- Welche Fahrzeuge und Hardware-Varianten sind kompatibel?
- Welche Tests müssen wiederholt werden?
- Verändert die Änderung Remote-Assistance- oder Flottenverhalten?
- Welche Monitoring- und Rollback-Kriterien gelten?
- Welche regulatorischen oder Meldedatensaetze müssen aktualisiert werden?
Verwenden Sie unveraenderliche Release-Baselines, die die vollstaendige ausgelieferte Konfiguration identifizieren, nicht nur den Hauptsoftware-Build. Karten-, Modell-, Kalibrierungs-, Policy- und Cloud-Service-Versionen können noetig sein, um ein Ereignis zu rekonstruieren.
Rollen Sie Änderungen gestaffelt aus. Canary-Fahrzeuge und Shadow-Mode-Evaluation können Risiken senken, brauchen aber explizite Erfolgs- und Abbruchkriterien. Das Ausbleiben beobachteter Vorfälle ist kein ausreichender Beleg, wenn Telemetrie oder Szenarienabdeckung unvollstaendig sind.
Betriebs-Beweismittel als Sicherheitskontrolle
Pre-Deployment-Tests können nicht jede reale Interaktion abdecken. Betriebs-Beweismittel helfen festzustellen, ob Kontrollen wirksam bleiben und ob neue Risiken entstehen.
Nützliche Beweismittel umfassen:
- ODD-Eintritts- und Austrittsereignisse.
- Sensor- und Subsystem-Gesundheit.
- Disengagements und Minimal-Risk-Manoever.
- Remote-Assistance-Anfragen und Ergebnisse.
- Eingriffe von Safety-Monitoren.
- Sicherheits-Alarme und Authentifizierungsereignisse.
- Software-, Modell-, Karten- und Konfigurationsidentitaet.
- Unfall- und Near-Miss-Kontext.
- Ungewoehnliche Routen- oder Verhaltenscluster.
- Update- und Rollback-Historie.
- Operator- und Wartungsaktionen.
Das Ziel ist nicht, alles zu sammeln. Definieren Sie, welche Entscheidungen die Beweismittel stützen müssen, und sammeln Sie die minimal notwendigen, vertrauenswuerdigen Daten.
Bewahren Sie Provenienz, Zeitsynchronisation, Zugriffskontrolle und Aufbewahrung. Ein Log ohne bekannte Konfiguration oder Uhrenintegritaet kann für eine Untersuchung unbrauchbar sein.
Das Unfall-Meldeframework der NHTSA zeigt den regulatorischen Wert konsistenter realer Daten. Auch wenn ein konkretes Ereignis nicht meldepflichtig ist, verbessert dieselbe Disziplin das interne Lernen und die Defekterkennung.
Cyber-Safety-Vorfall-Triage
Ein ADS-Ereignis kann Software-, Cybersecurity-, Safety-, Betriebs-, Menschen- oder Umweltursachen haben. Die Triage sollte es nicht zu früh in eine Kategorie zwingen.
Schaffen Sie einen gemeinsamen Prozess mit Cybersecurity, Safety, ADS-Engineering, Flottenbetrieb, Recht, Qualität und Kommunikation. Erste Fragen umfassen:
- War das ADS oder die relevante Assistance aktiv?
- War das Fahrzeug innerhalb der vorgesehenen ODD?
- Welche Software und Konfiguration waren ausgeliefert?
- Gab es Authentifizierungs-, Integritaets- oder Sicherheitsanomalien?
- Widersprachen sich Sensoren, Karten oder Cloud-Eingaben?
- War Remote-Assistance involviert?
- Gab es kürzliche Änderungen, die bei aehnlichen Ereignissen gemeinsam auftreten?
- Koennte ein boeswilliger Akteur das Verhalten reproduzieren oder skalieren?
- Welche Fahrzeuge teilen die betroffene Komponente oder Konfiguration?
- Welche Eindaemmung ist sicher?
Überschreiben Sie keine Beweismittel bei der Wiederherstellung. Bewahren Sie Logs, fluechtigen Zustand soweit möglich, Cloud-Traces, Operator-Aufzeichnungen, Update-Historie und relevante externe Daten.
Eindaemmungsoptionen können Routeneinschraenkungen, ODD-Reduktion, Feature-Abschaltung, Credential-Revokation, Konfigurations-Rollback, verstaerktes Monitoring, Depot-Rückruf oder Flotten-Pause umfassen. Die sicherste Reaktion hängt vom Kontext ab.
Bedrohungs-Szenarien speziell für ADS-Betrieb
Manipulation der ODD-Grenze
Ein Fahrzeug wird durch verfaelschte Standort-, Karten-, Wetter- oder Flotten-Autorisierungsdaten zum Betrieb dort verleitet, wo das ADS nicht zugelassen ist.
Kompromittierung der Remote-Assistance
Ein Angreifer gibt sich als Operator aus, verändert Ratschlaege, spielt eine Sitzung wieder ein oder gewinnt übermaessige Kontrolle über mehrere Fahrzeuge.
Modell- oder Konfigurations-Mismatch
Ein gueltiges, aber inkompatibles Modell, eine Karte, Kalibrierung oder Policy wird in die falsche Hardware oder das falsche Servicegebiet ausgeliefert.
Missbrauch flottenweiter Features
Ein privilegierter Backend-Account ändert Verhalten, Geofences oder Safety-Einstellungen über viele Fahrzeuge hinweg.
Verschleierung der Sensor-Degradation
Health-Indikatoren werden unterdrückt oder manipuliert, sodass das Fahrzeug trotz beeintraechtigter Erfassung im autonomen Dienst bleibt.
Datenvergiftung durch Betriebs-Feedback
Boeswillige oder beschaedigte Flottendaten gelangen in Trainings-, Simulations- oder Validierungs-Pipelines und beeinflussen kuenftige Releases.
Adversariale Interaktion mit Infrastruktur
Kompromittierte Strassen-, Baustellen-, Karten- oder Kommunikationsinformationen erzeugen unerwartetes Planungsverhalten.
Manipulation von Beweismitteln
Logs, Ereigniszeiten, Konfigurationsdatensaetze oder Operator-Aktionen werden verändert, sodass eine akkurate Untersuchung und Meldung verhindert wird.
Jedes Szenario sollte mit Kontrollen, Tests, Monitoring und einer sicheren Reaktion verknuepft sein.
Validierungsstrategie
ADS-Cybersicherheits-Validierung sollte mehrere Methoden kombinieren.
Architektur- und Angriffspfad-Analyse
Verfolgen Sie Pfade von externen Diensten, Operatoren, Sensoren, Depot-Systemen und Cloud-Accounts zu Fahrentscheidungen und Aktuatoren.
Komponenten-Test
Fuzzen Sie Parser, testen Sie Authentifizierung, bewerten Sie Secure Boot, prüfen Sie Schlüsselspeicherung und validieren Sie Fehlerbehandlung.
Simulation
Spielen Sie cyber-beeinflusste Szenarien in grosser Zahl durch: gespoofte Lokalisierung, inkonsistente Sensoren, boeswillige Karten-Updates, verzoegerte Remote-Assistance und abnormale Flotten-Kommandos.
SIL- und HIL-Test
Verifizieren Sie Software- und Hardware-Verhalten bei fehlgeformten Eingaben, Timing-Fehlern, Netzwerk-Manipulation, degradierten Sensoren und Regelungs-Grenzbedingungen.
Test auf abgeschlossener Strecke
Validieren Sie physische Konsequenzen und sichere Rückfallpfade unter kontrollierten adversarialen Bedingungen.
Operatives Shadowing
Bewerten Sie neue Modelle oder Policies gegen Live-Bedingungen, ohne das Fahrzeug zu steuern, unter Beachtung von Datenschutz- und Safety-Kontrollen.
Red Teaming
Testen Sie die gesamte Organisation einschliesslich Cloud, Operatoren, Support, Lieferanten, Depots und Incident Response.
Jedes Testergebnis sollte Konfiguration, Szenario, erwartetes Verhalten, beobachtetes Ergebnis und den verknuepften Assurance-Claim ausweisen.
Lieferanten- und Partner-Assurance
ADS hängt von Sensoren, Compute, Karten, Konnektivitaet, Simulation, Remote-Operations, Cloud-Plattformen und vielen Software-Lieferanten ab. Definieren Sie Cybersecurity-Schnittstellenvereinbarungen zu:
- Asset- und Verantwortungsgrenzen.
- Software- und Modell-Provenienz.
- Schwachstellen-Notifikation.
- Änderungs- und Release-Mitteilung.
- Vorfall-Beweismittel und Unterstützung.
- Zugriff und Remote-Administration.
- Sicherheits-Test-Beweismittel.
- Betriebs-Monitoring.
- Datenaufbewahrung und -teilung.
- End-of-Support und Übergang.
Die Komponenten-Beweismittel eines Lieferanten sollten wiederverwendbar sein, der ADS-Integrator bleibt aber für Fahrzeug- und Betriebskontext verantwortlich. Ein sicherer Sensor belegt nicht, dass das Perzeptionssystem ein koordiniertes Spoofing-Szenario bewaeltigt.
Governance-Kennzahlen
Verfolgen Sie Indikatoren wie:
- Anteil der ausgelieferten Fahrzeuge mit vollstaendiger Konfigurationsidentitaet.
- Anteil privilegierter Remote-Assistance-Sitzungen mit vollstaendigem Audit-Beleg.
- Zeit zur Identifikation von Fahrzeugen, die ein betroffenes Modell, eine Karte oder Software-Version teilen.
- Anteil der ADS-Änderungen mit Szenario- und ODD-Impact-Bewertung.
- Alter von Cybersicherheits-Testbeweisen für kritische Kontrollen.
- Anzahl Fahrzeuge, die mit ungeloesten Sensor-Gesundheits-Anomalien betrieben werden.
- Zeit vom Feld-Ereignis bis zur flottenweiten Mustererkennung.
- Anteil der Massen-Flottenaktionen mit Doppelfreigabe.
- Abdeckung cyber-beeinflusster Szenarien in Simulation, SIL, HIL und Streckentest.
- Zeit bis zur Revokation eines Operator-, Fahrzeug- oder Service-Credentials.
- Anzahl Betriebs-Ereignisse, die aus aufbewahrten Beweismitteln nicht rekonstruiert werden können.
Kennzahlen sollten an die zugrunde liegende Fahrzeugpopulation und Beweismittel ankoppeln, statt isolierte Dashboard-Prozente zu bleiben.
Wie ThreatZ operative Assurance unterstützt
ADS-Assurance erfordert ein verbundenes Modell aus Architektur, Software, Modellen, Bedrohungen, Kontrollen, Tests, Releases, Betriebsereignissen, Vorfällen, Lieferanten und Flottenkonfigurationen. ThreatZ kann die Cybersicherheits-Traceability-Schicht liefern, die designseitige Analyse mit Feld-Beweismitteln und Änderungsentscheidungen verbindet.
Ein praktischer Pilot kann auf einen Remote-Assistance-Workflow oder eine ODD-Durchsetzungskette fokussieren. Karten Sie Autoritaet und Datenpfad, verknuepfen Sie Kontrollen mit Validierung und Betriebs-Beweismitteln und weisen Sie nach, dass ein verdaechtiges Ereignis bis zur betroffenen Software, den Fahrzeugen und Assurance-Claims zurückverfolgt werden kann.
Häufig gestellte Fragen
Geht es bei Cybersicherheit für autonome Fahrzeuge hauptsaechlich um die Abwehr von Remote-Hacking?
Nein. Sie umfasst auch Integritaet von Sensoren, Karten, Modellen, Konfiguration, Flottendiensten, Remote-Operations, Software-Änderungen und Betriebs-Beweismitteln, die sicheres Verhalten stützen.
Welche Rolle spielt die ODD in der Cybersicherheit?
Die ODD definiert, wo und unter welchen Bedingungen das ADS betrieben werden darf. Sicherheitskontrollen müssen die Daten, Konfiguration und Autorisierung schuetzen, mit denen geprüft wird, ob diese Bedingungen erfuellt sind.
Sollten Remote-Operatoren Safety-Grenzen des Fahrzeugs umgehen können?
Das sicherste Design haelt unabhängige Fahrzeug-Constraints autoritativ. Remote-Assistance sollte eng definiert, authentifiziert, geloggt und unfähig sein, unbeschraenkte Steuerung zu erzeugen.
Wie kann ein Betreiber einen ADS-Cyber-Vorfall eingrenzen?
Halten Sie vollstaendige Deployment- und Konfigurations-Traceability. Der Betreiber sollte jedes Fahrzeug identifizieren können, das die betroffene Software, das Modell, die Karte, Hardware, Policy oder den Service nutzt.
Welche Testumgebung ist am wichtigsten?
Keine einzelne Umgebung reicht. Simulation liefert Skalierung, SIL und HIL kontrollierte technische Evidenz, Strecken-Tests validieren physisches Verhalten, und Betriebs-Monitoring zeigt reale Grenzfälle.
Autoritative Referenzen
- NHTSA Standing General Order on Crash Reporting
- NHTSA Automated Vehicle Safety
- UNECE UN Regulation No. 157 - Automated Lane Keeping Systems
- UNECE-Überblick zur Regulierung automatisierter Fahrzeuge