newsonline24

Mit den neuen UN-Regelwerken R185 und GTR No. 26 entsteht ein internationaler Rahmen für Automated Driving Systems. Parallel arbeitet die UNECE-ADS-Arbeitsgruppe an Guidance and Interpretation Documents (GID), die die praktische Anwendung der Regelwerke unterstützen sollen. Unabhängig von der konkreten Ausgestaltung wird deutlich: Zukünftige Fahrzeugplattformen müssen so ausgelegt sein, dass automatisierte Fahrfunktionen sicher entwickelt, validiert und betrieben werden können.

Im ersten Teil dieser Reihe haben wir erläutert, warum zwischen Fahrentscheidung und Fahrzeugbewegung eine eigenständige sicherheitskritische Ebene entsteht – die Control Layer. Im zweiten Teil betrachten wir die technischen Anforderungen an diese Ebene und zeigen, weshalb Drive-by-Wire zum zentralen Enabler zukünftiger softwaredefinierter Fahrzeugarchitekturen wird.

Worauf es bei einer Control Layer technisch ankommt

• Deterministische Befehlsverarbeitung: Eine Control Layer muss Fahrbefehle jederzeit reproduzierbar verarbeiten. Prioritäten, Zeitverhalten und Grenzwerte dürfen nicht vom aktuellen Systemzustand oder der Ausführungsreihenfolge abhängen. Identische Eingangssituationen müssen zu identischen Fahrzeugreaktionen führen.
• Durchgängige Überwachung der Wirkungskette: Sicherheit endet nicht beim Fahrbefehl. Die gesamte Kette – von der Eingabe über Kommunikation und Aktuatorik bis zur tatsächlichen Fahrzeugbewegung – muss kontinuierlich überwacht und plausibilisiert werden.
• Redundanz und Fehlerbeherrschung: Kritische Funktionen benötigen unabhängige Signal-, Rechen- und Kommunikationspfade. Fehler müssen erkannt, lokalisiert und beherrscht werden, ohne die gesamte Steuerfunktion zu beeinträchtigen.
• Fail-operational statt Fail-silent: Eine Control Layer darf bei Fehlern nicht einfach abschalten. Entscheidend ist, dass die notwendige Kontrollfähigkeit erhalten bleibt, um ein definiertes Minimal-Risk-Verhalten oder einen sicheren Systemübergang auszuführen.
• Diagnose und Nachvollziehbarkeit: Sicherheitsrelevante Zustände, Fehler und Systemreaktionen müssen nachvollziehbar dokumentiert werden. Diese Daten bilden die Grundlage für Safety Case, Genehmigung, In-Service Monitoring und kontinuierliche Weiterentwicklung.
• Offene und definierte Schnittstellen: Eine Control Layer muss unterschiedliche Steuerquellen – etwa AD-Stack, Teleoperation oder Fahrerinteraktion – über klar definierte Schnittstellen integrieren können. Das erleichtert Wiederverwendung, Plattformintegration und Homologation.

Warum Drive-by-Wire zum zentralen Enabler wird

Klassische Fahrzeugarchitekturen wurden für eine Welt entwickelt, in der ein Mensch permanent Teil des Regelkreises war. Mechanische oder hydraulische Verbindungen konnten zugleich Bedienpfad und Rückfallebene sein. In fahrerlosen Anwendungen entfällt diese Annahme: Das Fahrzeug muss Lenkung, Bremsen und Antrieb elektronisch ansteuern, überwachen und bei Fehlern in einen kontrollierten Zustand überführen können.

Drive-by-Wire ersetzt oder ergänzt mechanische Bedienpfade durch elektronische Signal- und Steuerpfade. Sein strategischer Wert liegt jedoch nicht allein im Wegfall einer Lenksäule oder in neuen Packaging-Freiheiten. Entscheidend ist, dass Fahrzeugbewegung softwareseitig adressierbar, messbar und auf einer definierten Sicherheitsarchitektur beherrschbar wird.

Die Regulierung schreibt Drive-by-Wire nicht vor. In der praktischen Umsetzung macht sie aber Eigenschaften relevant, die ohne eine hochverfügbare elektronische Bewegungssteuerung nur schwer skalierbar erreichbar sind: kontrollierte Reaktion auf Fehler, eindeutige Systemzustände, nachvollziehbare Diagnostik, wiederholbare Validierung und die Integration unterschiedlicher Steuerquellen.

Safety-by-Wire® und NX NextMotion: der Ansatz von Arnold NextG

Arnold NextG versteht Safety-by-Wire® nicht als einzelne Funktion, sondern als durchgängiges Architekturprinzip. Hardware, Embedded Software, Kommunikation, Aktuatorik, Energieversorgung, Diagnose und Sicherheitsmechanismen werden als zusammenhängende Wirkungskette betrachtet.

NX NextMotion bildet innerhalb dieses Ansatzes die zentrale Control Layer. Die Plattform ist modular, fahrzeugunabhängig integrierbar und verfügt nach Unternehmensangaben über eine vierfach-redundante Hard- und Softwarearchitektur. Sie steuert Primärfunktionen wie Lenkung, Bremsen und Antrieb sowie ausgewählte sicherheitsrelevante Sekundärfunktionen und kann Fahrbefehle aus unterschiedlichen Quellen auf einer gemeinsamen Sicherheitsarchitektur verarbeiten.

• Multi-redundante Rechen-, Kommunikations- und Versorgungspfade zur Vermeidung kritischer Single Points of Failure.
• Kontinuierliches Monitoring und TÜV-geprüftes Error Management auf Hard- und Softwareebene.
• Funktionale Sicherheit nach ISO 26262 bis ASIL D sowie IEC 61508 SIL 3 gemäß ausgewiesener Entwicklungs- und Nachweislage.
• TÜV-Nachweise für Lenk- und Bremssysteme nach UN ECE R79 und R13 sowie ausgewiesene Straßenzulassung.
• Plattformunabhängige Integration vom Prototyp bis zur homologationsfähigen Fahrzeuglösung.

Damit positioniert sich Arnold NextG bewusst nicht als weiterer Anbieter des AD-Stacks. Die strategische Rolle liegt darunter: NX NextMotion soll sicherstellen, dass eine digitale Fahrentscheidung – unabhängig davon, ob sie von Autonomie, Teleoperation oder Mensch stammt – in eine definierte und kontrollierte Fahrzeugbewegung übersetzt wird.

„Wir entwickeln nicht den nächsten Fahralgorithmus. Wir entwickeln die sichere Ebene, auf der unterschiedliche Fahrentscheidungen überhaupt erst zuverlässig zu Bewegung werden. Genau darin liegt die strategische Bedeutung der Control Layer.“ Kevin Arnold, CEO der Arnold NextG GmbH

Was OEMs, ADS-Entwickler und Systempartner jetzt klären sollten

Der neue regulatorische Rahmen erhöht nicht nur den Dokumentationsaufwand. Er verändert Architekturentscheidungen und Verantwortungsgrenzen. Für Projekte mit hoch- oder vollautomatisierten Fahrfunktionen sollten deshalb frühzeitig fünf Fragen beantwortet werden:

• Wo endet die Verantwortung des AD-Stacks – und wo beginnt die Verantwortung für die tatsächliche Fahrzeugbewegung?
• Welche Fehler müssen durch die Control Layer unabhängig vom Fahralgorithmus erkannt und beherrscht werden?
• Wie werden Softwareupdates, neue Fahrfunktionen und Fahrzeugvarianten in einen bestehenden Safety Case integriert?
• Welche Daten und Diagnosen werden für Genehmigung, Ereignisanalyse und In-Service Monitoring benötigt?
• Welche Teile der Bewegungssteuerung sind projektspezifisch – und welche können als wiederverwendbare, vorentwickelte Systembasis genutzt werden?

Eine klar abgegrenzte Control Layer kann hier Komplexität reduzieren. Sie ersetzt nicht die Systemverantwortung des Fahrzeugherstellers. Sie schafft aber eine wiederverwendbare Sicherheits- und Integrationsbasis, auf der unterschiedliche AD-Stacks, Plattformen und Anwendungen aufsetzen können.

Regulatorik ist kein Schlusskapitel

Die neuen ADS-Regelwerke verschieben die Perspektive von der einmaligen Freigabe hin zu einem fortlaufenden Sicherheitsmodell. Safety Management, Softwareänderungen, Felddaten, Ereignisberichte und Systemgrenzen müssen über den Betrieb hinweg konsistent bleiben. Für Unternehmen bedeutet das: Regulatorik darf nicht am Ende eines Entwicklungsprojekts „angefügt“ werden. Sie muss Teil von Architektur, Entwicklungsprozess, Lieferkette und Betriebsmodell sein.

Für Arnold NextG bestätigt diese Entwicklung die eigene Architekturstrategie: Entscheidend ist nicht allein, ob ein System die richtige Fahrentscheidung trifft, sondern ob diese jederzeit kontrolliert, nachvollziehbar und fehlertolerant umgesetzt werden kann.Fazit: Autonomie beginnt mit kontrollierbarer Bewegung

UN R185 und UN GTR 26 schaffen einen wichtigen internationalen Referenzrahmen. Sie definieren keine bestimmte technische Lösung und sie erklären Drive-by-Wire nicht zur Pflicht. Sie machen jedoch unmissverständlich deutlich, dass Sicherheit über die gesamte Wirkungskette eines Automated Driving Systems nachgewiesen werden muss.

Damit rückt die Ebene zwischen Algorithmus und Aktuatorik in den Mittelpunkt. Die Control Layer wird zur strategischen Infrastruktur des softwaredefinierten Fahrzeugs: Sie verbindet unterschiedliche Steuerquellen, beherrscht Fehler, schafft Evidenz und übersetzt digitale Entscheidungen in reale Bewegung. Autonome Mobilität beginnt nicht mit der Entscheidung eines Algorithmus. Sie beginnt mit der Fähigkeit, jede Bewegung kontrolliert auszuführen.

WE CONTROL WHAT MOVES.

Quellen und regulatorischer Hinweis

Diese Einordnung berücksichtigt den Stand der veröffentlichten Ergebnisse der 21. ADS-Sitzung der UNECE vom 14.–17. Juli 2026. Sie stellt eine fachliche und strategische Einordnung von Arnold NextG dar und ersetzt keine Rechts- oder Homologationsberatung.

• UNECE: Mitteilung zu den neuen globalen ADS-Regelwerken
• UNECE ADS IWG: 21. Sitzung, Brüssel, 14.–17. Juli 2026
• Arnold NextG: NX NextMotion
• Arnold NextG: Sicherheitskonzept
• Arnold NextG: Zertifikate
• Arnold NextG: Unternehmen und Mission