Genau diese Ebenen verbindet der Safety Case zu einer durchgängigen Argumentations- und Nachweiskette. Von jedem Sicherheitsziel muss der Weg über Requirements und Architektur bis zum Testergebnis nachvollziehbar sein – und zurück.

Für NX NextMotion als Drive-by-Wire-basierte Control Layer für autonome und teleoperierte Fahrzeuge ist diese Rückverfolgbarkeit ein wesentlicher Bestandteil der Systementwicklung. Denn wenn Lenken, Bremsen und Antrieb vollständig elektronisch kontrolliert werden, muss nicht nur die Sicherheitsarchitektur belastbar sein. Auch der Nachweis ihrer Wirksamkeit muss es sein.

Der Safety Case ist kein Papierstapel

Ein Safety Case entsteht nicht dadurch, dass am Projektende möglichst viele Nachweisdokumente zusammengetragen werden. Entscheidend ist die Rückverfolgbarkeit. Von jedem Sicherheitsziel muss sich der Weg über Requirements und Architektur bis zu Analysen und Testergebnissen verfolgen lassen – und von jedem Testergebnis zurück zu der Frage, welche Sicherheitsanforderung damit nachgewiesen wird. Bei Safety-by-Wire^® beginnt diese Beweiskette deshalb bereits in den frühen Entwicklungsphasen und begleitet NX NextMotion über den gesamten Lebenszyklus.

Requirements-in-the-Loop: prüfen, bevor implementiert wird

Eine der teuersten Fehlerquellen in der Systementwicklung liegt nicht zwangsläufig im Code. Bereits unvollständige, widersprüchliche oder nicht erfüllbare Anforderungen können sich durch Architektur, Implementierung und Test fortsetzen. Arnold NextG setzt deshalb bereits bei den Requirements an.

Mit Requirements-in-the-Loop werden Anforderungen und Szenarien in den frühen Systemphasen simulativ überprüft – bevor die erste Zeile Seriencode entsteht. Ziel ist es, Widersprüche, Lücken oder nicht erfüllbare Kombinationen zu erkennen, solange ihre Korrektur noch auf Requirement-Ebene erfolgen kann. Der Ansatz ist in die Anforderungserhebung und -analyse eingebunden – in der Automotive-SPICE-Systematik in SYS.1 und SYS.2. Damit beginnt der Sicherheitsnachweis nicht erst auf der Verifikationsseite des Entwicklungsmodells, sondern bereits während der Spezifikation.

FMEDA und FTA: Architektur quantitativ bewerten

Parallel zur Entwicklung der Systemarchitektur kommen quantitative Sicherheitsanalysen zum Einsatz.

Die FMEDA – Failure Modes, Effects and Diagnostics Analysis – betrachtet mögliche Ausfallarten von Hardwarekomponenten, deren Auswirkungen und die Wirksamkeit der Diagnose. Sie liefert damit eine Grundlage für die Bewertung, ob gefährliche Einzelfehler erkannt und latente Fehler ausreichend beherrscht werden.

Die Fault Tree Analysis (FTA) nimmt die entgegengesetzte Perspektive ein. Ausgehend von einem unerwünschten Top-Ereignis – beispielsweise dem Verlust der Lenkfunktion – untersucht sie, welche Einzelereignisse oder Kombinationen dazu führen können.

Für eine multi-redundante, Fully Fail-Operational Drive-by-Wire-Architektur ist gerade dieses Zusammenspiel entscheidend. Es muss nicht nur plausibel sein, dass Redundanz vorhanden ist. Der Safety Case muss nachvollziehbar belegen, dass die Architektur die zugrunde liegenden Sicherheitsziele erfüllt.

Von der Simulation ins reale Fahrzeug

Mit zunehmender Systemreife verlagert sich der Nachweis schrittweise von der virtuellen in die reale Welt. Software-in-the-Loop (SiL) prüft Funktionslogik in einer simulierten Umgebung. Hardware-in-the-Loop (HiL) integriert reale Steuerungshardware und ermöglicht gezielte Fehlerinjektionen unter reproduzierbaren Bedingungen. Vehicle-in-the-Loop (ViL) verbindet schließlich das reale Fahrzeug mit einer simulierten Umgebung.

Gerade für sicherheitskritische Drive-by-Wire-Funktionen ist diese Kette wesentlich. Fehler in Kommunikation, Energieversorgung oder Steuerung sowie definierte Mehrfachfehler und Übergänge zwischen Betriebszuständen lassen sich gezielt untersuchen, ohne entsprechende Situationen erst im Straßen- oder Maschinenbetrieb erzeugen zu müssen. Der reale Fahrzeugbetrieb bleibt dennoch unverzichtbar. Er ergänzt die Simulation um Bedingungen und Wechselwirkungen, die sich nicht vollständig vorwegnehmen lassen.

Der Nachweis endet nicht mit SOP

Mit dem Produktionsstart ist ein Safety Case nicht abgeschlossen. Software-Updates verändern Systeme über ihre Lebensdauer. Felddaten liefern neue Erkenntnisse über reale Betriebsbedingungen. Monitoring kann Abweichungen sichtbar machen, die während der Entwicklung nicht aufgetreten sind.

Für eine Plattform wie NX NextMotion muss die Nachweisstruktur deshalb fortschreibbar sein. Erkenntnisse aus dem Betrieb müssen in die Sicherheitsargumentation zurückgeführt und Änderungen kontrolliert bewertet werden können. Safety-by-Wire® versteht den Safety Case damit als lebende Nachweisstruktur über den gesamten Lebenszyklus – von den ersten Anforderungen über Entwicklung und Validierung bis zu Betrieb und Updates.

Unabhängige Begutachtung als Teil des Prozesses

Ein weiterer Faktor ist der Zeitpunkt der unabhängigen Begutachtung. Findet ein Assessment erst am Ende eines Projekts statt, können Schwächen zwar erkannt werden – ihre Behebung ist dann jedoch häufig mit erheblichem Aufwand verbunden. Bei Safety-by-Wire® begleitet die unabhängige Begutachtung deshalb die Nachweisführung über die Entwicklungsphasen hinweg. Ziel ist, Architektur- und Nachweisentscheidungen zu einem Zeitpunkt kritisch zu prüfen, an dem sie noch effizient angepasst werden können.

Für Kundenprojekte entsteht damit eine vorentwickelte Nachweisbasis. Sie ersetzt weder den Safety Case des Gesamtfahrzeugs noch die Verantwortung des Herstellers für Typgenehmigung und Anwendung – schafft aber ein Fundament, auf dem die projektspezifische Sicherheitsargumentation aufsetzen kann.

Was OEMs und Integratoren prüfen sollten

Für die Bewertung einer sicherheitskritischen Drive-by-Wire-Plattform reicht deshalb die Frage nach ASIL D oder einer fail-operational Architektur allein nicht aus. Relevant ist ebenso, wann die Nachweisführung beginnt, ob Sicherheitsziele durchgängig bis zu Testergebnissen rückverfolgbar sind und welche quantitativen Analysen der Architektur zugrunde liegen. Ebenso sollte geklärt werden, welche Fehlerfälle tatsächlich in SiL, HiL oder ViL injiziert wurden, wie unabhängig die Begutachtung erfolgt und wie der Safety Case nach dem Produktionsstart fortgeschrieben wird.

Denn die Qualität einer Sicherheitsarchitektur zeigt sich nicht nur darin, was sie technisch kann, sondern auch darin, wie belastbar sich diese Fähigkeit nachweisen lässt.

Fazit: Sicherheit ist eine nachweisbare Eigenschaft

Mit dem Safety Case schließt sich die Functional-Safety-Kette von Safety-by-Wire®. Die Normen definieren den Rahmen. Die Gefährdungsanalyse führt zu Sicherheitszielen. Das Prinzip der strengsten Anforderung konsolidiert sie für unterschiedliche Fahrzeugdomänen. Die Fully Fail-Operational Architektur setzt diese Ziele technisch um. Und der Safety Case verbindet Requirements, Architektur, Analysen und Tests zu einer nachvollziehbaren Beweiskette.

Für NX NextMotion beginnt diese Kette vor der ersten Zeile Seriencode und reicht über den Produktionsstart hinaus in den laufenden Betrieb. Denn sichere Kontrolle über Lenken, Bremsen und Antrieb muss nicht nur technisch gewährleistet sein. Sie muss auch nachweisbar bleiben.

WE CONTROL WHAT MOVES

For autonomous and teleoperated vehicles, this changes a fundamental assumption of the safety architecture: the safe state can no longer simply mean “off.” Control over the vehicle’s movement must be maintained even after a fault occurs—at least until a safe state can be achieved. For the drive-by-wire-based control layer, this means that steering, braking, and propulsion must remain controllable even in the event of a fault. This is precisely where the architecture behind Safety-by-Wire® comes into play.

From Safety Objectives to Technical Architecture

Functional safety initially focuses on safety objectives. These describe which hazardous conditions must be prevented—for example, unintended steering movements, loss of braking function, or unintended propulsion.

To turn this into a real system, two translation steps are necessary. The functional safety concept defines which functions and safety mechanisms are required. The technical safety concept then translates these into concrete hardware and software architectures: sensors, computing paths, communication, power supply, diagnostics, and actuators.

This turns the safety objective into a central architectural question: What must be redundant to ensure that a single failure does not lead to a loss of vehicle control?

Redundancy must be consistent throughout

Two control units alone do not make a system fail-operational. If, for example, both share the same power supply, a critical communication path, or other common resources, a common failure path remains.

NX NextMotion therefore relies on a consistent, multi-redundant architecture. Physical separation encompasses two channels across the entire chain of operation—from computing and communication paths to power control and actuators. Both sides are designed to meet ASIL D requirements. In addition, the system features redundant sensor systems, continuous diagnostics, and redundant power paths. The goal is not merely to detect a fault. The system must be able to manage the fault and continue to perform safety-critical functions within defined performance limits and response times.

Degradation Instead of Shutdown

In this context, “fail-operational” does not mean that a vehicle continues to operate indefinitely and unchanged after every fault. A defined degradation concept is crucial. Depending on the fault condition, the architecture can switch from full performance to a limited operating state or initiate a maneuver that minimizes risk. Every transition must be specified and completed within the designated fault tolerance time.

The key difference from the traditional shutdown principle is that control over the vehicle’s movement is maintained. This is particularly crucial for autonomous and teleoperated vehicles. An abrupt shutdown of a safety-critical movement function can itself pose a hazard.

Fully Fail-Operational: Redundancy on Four Axes

However, even the term “fail-operational” leaves room for interpretation. Which function remains available after which failure, for how long, and with what level of performance? Arnold NextG therefore uses the term “Fully Fail-Operational” for NX NextMotion as a deliberately narrower working definition. This is not a new normative category, but rather a technically verifiable description of the architectural requirement.

Fully Fail-Operational considers redundancy along four axes of completeness:

• Function: The primary safety-critical motion functions—steering, braking, and propulsion—are designed to be fail-operational.
• Channel: Two physically separate ASIL-D channels map the safety-critical chain of action. The loss of one side must not result in the loss of function.
• Control source: Autonomous driving systems, teleoperation, and human intervention can be accommodated within the same architecture. A deterministic arbitration mechanism determines which control path is valid.
• Power: The power supply is also designed to be redundant and supplemented with a buffer source for defined degradation windows.

It is only the interplay of these four levels that defines the standard Arnold NextG associates with “Fully Fail-Operational.”

Why This Is Relevant for OEMs and Integrators

For OEMs and system integrators, it is therefore worthwhile to take a closer look at what the term “fail-operational” actually entails. Is only a single function redundant—or is the entire motion control system redundant? Are two channels truly independent, or do they share critical components? What happens if a power supply fails? Which control source takes over in the event of a fault? And what functionality is actually still available during a degradation state?

These questions determine whether redundancy exists merely at the component level or supports the entire safety-critical chain of operations. For a drive-by-wire platform designed to support autonomous, teleoperated, and manual vehicle control, this end-to-end redundancy becomes a critical architectural feature.

Conclusion: The safe state is control

With the elimination of the driver as a permanent fallback, the safety architecture undergoes a fundamental change. A safety-critical system must not simply cease to function after a failure if doing so would result in the loss of control over the vehicle.

Drive-by-wire must therefore do more than simply execute electronic commands for steering, braking, and propulsion. The control layer must be designed to keep these functions controllable even in the event of a failure.

At Arnold NextG, “Fully Fail-Operational” describes this requirement: Redundancy is not considered on a case-by-case basis, but rather across functions, channels, control sources, and power supplies. NX NextMotion thus translates the safety goals of Safety-by-Wire® into a concrete, multi-redundant, fail-operational system architecture. Because for autonomous and teleoperated mobility, safety does not simply mean coming to a standstill.

Safety means maintaining control.

WE CONTROL WHAT MOVES

Für autonome und teleoperierte Fahrzeuge verändert sich damit eine grundlegende Annahme der Sicherheitsarchitektur: Der sichere Zustand kann nicht mehr grundsätzlich „aus“ bedeuten. Die Kontrolle über die Fahrzeugbewegung muss auch nach einem Fehler erhalten bleiben – mindestens so lange, bis ein sicherer Zustand erreicht werden kann. Für die Drive-by-Wire-basierte Control Layer bedeutet das: Lenken, Bremsen und Antrieb müssen auch im Störfall kontrollierbar bleiben. Genau hier beginnt die Architektur hinter Safety-by-Wire®.

Vom Sicherheitsziel zur technischen Architektur

Im Mittelpunkt funktionaler Sicherheit stehen zunächst Sicherheitsziele. Sie beschreiben, welche gefährlichen Zustände verhindert werden müssen – beispielsweise unbeabsichtigte Lenkbewegungen, den Verlust der Bremsfunktion oder ungewollten Vortrieb.

Damit daraus ein reales System entsteht, sind zwei Übersetzungsschritte notwendig. Das funktionale Sicherheitskonzept definiert, welche Funktionen und Sicherheitsmechanismen erforderlich sind. Das technische Sicherheitskonzept überführt diese anschließend in konkrete Hardware- und Softwarearchitekturen: Sensorik, Rechenpfade, Kommunikation, Energieversorgung, Diagnose und Aktuatorik.

Damit wird aus dem Sicherheitsziel eine zentrale Architekturfrage: Was muss redundant vorhanden sein, damit ein einzelner Fehler nicht zum Verlust der Fahrzeugkontrolle führt?

Redundanz muss durchgängig sein

Zwei Steuergeräte allein machen ein System noch nicht fail-operational. Teilen beide beispielsweise dieselbe Energieversorgung, einen kritischen Kommunikationspfad oder andere gemeinsame Ressourcen, bleibt ein gemeinsamer Ausfallpfad bestehen.

NX NextMotion setzt deshalb auf eine durchgängige, multi-redundante Architektur. Die physische Trennung umfasst zwei Kanäle über die gesamte Wirkungskette – von Rechen- und Kommunikationspfaden bis zur Leistungsansteuerung und Aktuatorik. Beide Seiten sind auf ASIL D ausgelegt. Hinzu kommen mehrfach ausgelegte Sensorik, kontinuierliche Diagnose sowie redundante Energiepfade. Das Ziel ist nicht lediglich, einen Fehler zu erkennen. Das System muss ihn beherrschen und die sicherheitsrelevanten Funktionen innerhalb definierter Leistungsgrenzen und Reaktionszeiten weiterführen können.

Degradation statt Abschaltung

Fail-operational bedeutet dabei nicht, dass ein Fahrzeug nach jedem Fehler unbegrenzt und unverändert weiterfährt. Entscheidend ist ein definiertes Degradationskonzept. Je nach Fehlerzustand kann die Architektur von voller Performance in einen eingeschränkten Betriebszustand wechseln oder ein risikominimales Manöver einleiten. Jeder Übergang muss spezifiziert und innerhalb der vorgesehenen Fehlertoleranzzeit abgeschlossen sein.

Der wesentliche Unterschied zum klassischen Abschaltprinzip: Die Kontrolle über die Fahrzeugbewegung bleibt erhalten. Gerade bei autonomen und teleoperierten Fahrzeugen ist das entscheidend. Ein abruptes Abschalten einer sicherheitskritischen Bewegungsfunktion kann selbst eine Gefährdung erzeugen.

Fully Fail-Operational: Redundanz auf vier Achsen

Doch auch der Begriff „fail-operational“ lässt Spielraum. Welche Funktion bleibt nach welchem Fehler wie lange und mit welcher Leistungsfähigkeit verfügbar? Arnold NextG verwendet deshalb für NX NextMotion den Begriff Fully Fail-Operational als bewusst engere Arbeitsdefinition. Dabei handelt es sich nicht um eine neue normative Kategorie, sondern um eine technisch prüfbare Beschreibung des Architekturanspruchs.

Fully Fail-Operational betrachtet Redundanz entlang von vier Vollständigkeitsachsen:

• Funktion: Die primären sicherheitsrelevanten Bewegungsfunktionen Lenken, Bremsen und Antrieb werden fail-operational ausgelegt.
• Kanal: Zwei physisch getrennte ASIL-D-Kanäle bilden die sicherheitsrelevante Wirkungskette ab. Der Verlust einer Seite darf nicht zum Verlust der Funktion führen.
• Steuerquelle: Autonomes Fahrsystem, Teleoperation und menschlicher Eingriff können innerhalb derselben Architektur berücksichtigt werden. Eine deterministische Arbitrierung entscheidet, welcher Steuerpfad gültig ist.
• Energie: Auch die Energieversorgung wird redundant betrachtet und um eine Pufferquelle für definierte Degradationsfenster ergänzt.

Erst das Zusammenspiel dieser vier Ebenen beschreibt den Anspruch, den Arnold NextG mit Fully Fail-Operational verbindet.

Warum das für OEMs und Integratoren relevant ist

Für OEMs und Systemintegratoren lohnt deshalb ein genauer Blick hinter den Begriff „fail-operational“. Ist nur eine einzelne Funktion redundant – oder die vollständige Bewegungssteuerung? Sind zwei Kanäle tatsächlich unabhängig oder teilen sie kritische Komponenten? Was passiert beim Ausfall einer Energieversorgung? Welche Steuerquelle übernimmt bei einem Fehler? Und welche Funktionalität steht während des Degradationszustands tatsächlich noch zur Verfügung?

Diese Fragen entscheiden darüber, ob Redundanz lediglich auf Komponentenebene vorhanden ist oder die gesamte sicherheitskritische Wirkungskette trägt. Für eine Drive-by-Wire-Plattform, die autonome, teleoperierte und manuelle Fahrzeugführung unterstützen soll, wird diese Durchgängigkeit zum entscheidenden Architekturmerkmal.

Fazit: Der sichere Zustand ist Kontrolle

Mit dem Wegfall des Fahrers als permanenter Rückfallebene verändert sich die Sicherheitsarchitektur grundlegend. Ein sicherheitskritisches System darf nach einem Fehler nicht einfach aufhören zu funktionieren, wenn genau dadurch die Kontrolle über das Fahrzeug verloren geht.

Drive-by-Wire muss deshalb mehr leisten als elektronische Befehle für Lenken, Bremsen und Antrieb umzusetzen. Die Control Layer muss darauf ausgelegt sein, diese Funktionen auch im Störfall kontrollierbar zu halten.

Fully Fail-Operational beschreibt bei Arnold NextG diesen Anspruch: Redundanz wird nicht punktuell, sondern über Funktion, Kanal, Steuerquelle und Energie gedacht. NX NextMotion überführt damit die Sicherheitsziele von Safety-by-Wire® in eine konkrete multi-redundante, fail-operational Systemarchitektur. Denn für autonome und teleoperierte Mobilität bedeutet Sicherheit nicht einfach Stillstand.

Sicherheit bedeutet, die Kontrolle zu behalten.

WE CONTROL WHAT MOVES

For NX NextMotion, Arnold NextG follows a clear principle: If different standards assess the same safety objective with varying levels of stringency, the most stringent requirement sets the benchmark. This is a central component of Safety-by-Wire®.

It all starts with the hazard

Before discussing ASIL D, SIL, or other safety levels, it must first be clarified what risk a malfunction actually poses. In the automotive world, this is done through hazard analysis and risk assessment—HARA for short. This process combines specific operating situations with potential malfunctions.

For example, what does an unintended steering input at high speed mean? What are the consequences of losing braking function on a downhill slope? What happens in the event of unintended forward motion during a maneuver? The assessment evaluates the potential severity of harm, exposure, and—depending on the applicable standards—the possibility of still controlling the situation. Safety objectives are ultimately derived from the risk assessment. This step is particularly relevant for drive-by-wire systems. This is because steering, braking, and propulsion are the primary functions through which vehicle movement is directly controlled.

The Same Fundamental Risk—Different Languages

The fundamental logic of functional safety applies across various vehicle and machinery domains. However, the respective risk models differ. ISO 26262 uses Automotive Safety Integrity Levels (ASIL) for road vehicles. IEC 61508 uses Safety Integrity Levels (SIL). In agriculture and forestry, ISO 25119 specifies Agricultural Performance Levels (AgPL); for earth-moving machinery, Machine Performance Levels (MPL) according to ISO 19014 are used; and in machine safety, Performance Levels (PL) according to ISO 13849 apply. These classifications cannot simply be equated.

An ASIL D is not automatically a SIL 4, nor are PL e and AgPL e identical despite sharing the same letters. Each scale incorporates assumptions specific to its respective application domain—for example, regarding speed, environment, exposure, or operator role. For a platform intended for use across domain boundaries, this presents a key development challenge: the requirements must be made comparable without losing their respective normative significance.

From Five Assessments to a Single Set of Objectives

This is precisely where Arnold NextG’s Safety-by-Wire® strategy comes into play. The safety objectives derived from the relevant analyses are consolidated across standards. Where the respective standards provide for corresponding mappings, different risk metrics are mapped to a common assessment basis. For NX NextMotion, ISO 26262 serves as the guiding standard for development.

If the same safety objective appears in multiple application domains, its assessment may vary. In this case, the principle of the most stringent requirement applies. No average value, no selection based on application: the highest relevant requirement becomes the benchmark for the platform. For the primary motion functions, this approach leads to the highest classification of the leading standard: ASIL D.

At the system level, this results in safety objectives such as preventing unintended steering movements, loss of braking function, or unintended propulsion. Added to these are safety objectives for supporting functions, such as ensuring the vehicle comes to a complete stop or providing signaling. The result is not a collection of disparate safety catalogs, but a common foundation for further system development.

Safety objectives must determine the architecture—not the other way around

For OEMs, Tier 1 suppliers, and system integrators, timing is of the essence. A safety objective catalog does not realize its full value if it is compiled after an architecture has already been developed. It must precede key architectural decisions. This is because technical requirements for hardware and software are derived from the safety objectives: Which functions must be redundant? Which faults must be diagnosed? What response times apply? How must the system behave after a fault?

At NX NextMotion, the consolidated catalog of safety objectives was therefore established at the very beginning of platform development. Decisions regarding redundancy, diagnostics, and degradation behavior can thus be traced back to defined safety objectives. This traceability is particularly crucial for a drive-by-wire-based control layer: It links the initial hazard analysis to the technical implementation and, ultimately, to the safety case.

What OEMs and Integrators Should Check

An ASIL or SIL claim alone therefore says little about whether a system is suitable for a specific application. Among other things, it is crucial to determine which operating situations and assumptions the underlying hazard analysis is based on. Do these scenarios cover the vehicle’s actual use? What assumptions were made regarding controllability? Do these assumptions still apply when there is no driver in the vehicle?

Equally relevant is the question of whether the safety objectives were formulated exclusively for a single vehicle domain or whether they already take other areas of application into account. For a scalable drive-by-wire platform, functional safety is thus not merely a question of the safety level achieved. The safety rationale behind it is what matters most.

Conclusion: A Single Set of Objectives Instead of Five Parallel Worlds

Different vehicle domains speak different languages of functional safety. For a drive-by-wire platform that addresses several of these domains, however, this must result in clear technical requirements. Safety-by-Wire® therefore consolidates the relevant safety objectives into a common catalog of safety objectives. Where different assessments conflict, the most stringent requirement sets the standard.

This creates the foundation for a multi-redundant, fail-operational drive-by-wire architecture whose safety requirements are not defined only for the next vehicle project, but are already embedded in the platform. After all, safe vehicle movement does not begin with the actuator. It begins with the question of which hazard must be controlled—and what architecture is necessary to do so.

WE CONTROL WHAT MOVES

Für NX NextMotion folgt Arnold NextG dabei einem klaren Prinzip: Bewerten unterschiedliche Normen dasselbe Sicherheitsziel unterschiedlich streng, setzt die strengste Anforderung den Maßstab. Das ist ein zentraler Baustein von Safety-by-Wire®.

Am Anfang steht die Gefährdung

Bevor über ASIL D, SIL oder andere Sicherheitslevel gesprochen werden kann, muss zunächst geklärt werden, welches Risiko eine Fehlfunktion überhaupt verursacht. In der Automotive-Welt erfolgt dies über die Gefährdungsanalyse und Risikobewertung – die Hazard Analysis and Risk Assessment, kurz HARA. Dabei werden konkrete Betriebssituationen mit möglichen Fehlfunktionen kombiniert.

Was bedeutet beispielsweise ein unbeabsichtigter Lenkeingriff bei hoher Geschwindigkeit? Welche Folgen hat der Verlust der Bremsfunktion im Gefälle? Was passiert bei ungewolltem Vortrieb während eines Rangiervorgangs? Bewertet werden mögliche Schadensschwere, Exposition und – je nach Normenwelt – die Möglichkeit, die Situation noch zu kontrollieren. Aus der Risikobewertung werden schließlich Sicherheitsziele abgeleitet. Für Drive-by-Wire ist dieser Schritt besonders relevant. Denn Lenken, Bremsen und Antrieb bilden die primären Funktionen, über die Fahrzeugbewegung unmittelbar kontrolliert wird.

Dasselbe Grundrisiko – unterschiedliche Sprachen

Die grundlegende Logik funktionaler Sicherheit findet sich über verschiedene Fahrzeug- und Maschinendomänen hinweg. Die jeweiligen Risikomodelle unterscheiden sich jedoch. Die ISO 26262 verwendet für Straßenfahrzeuge Automotive Safety Integrity Levels (ASIL). Die IEC 61508 arbeitet mit Safety Integrity Levels (SIL). In der Land- und Forstwirtschaft kommen über die ISO 25119 Agricultural Performance Levels (AgPL) zum Einsatz, für Erdbaumaschinen Machine Performance Levels (MPL) nach ISO 19014 und in der Maschinensicherheit Performance Levels (PL) nach ISO 13849. Diese Einstufungen lassen sich nicht einfach gleichsetzen.

Ein ASIL D ist nicht automatisch ein SIL 4, ebenso wenig sind PL e und AgPL e trotz gleicher Buchstaben identisch. Jede Skala enthält Annahmen aus ihrer jeweiligen Anwendungswelt – beispielsweise zu Geschwindigkeit, Umgebung, Exposition oder Bedienerrolle. Für eine Plattform, die über Domänengrenzen hinweg eingesetzt werden soll, entsteht daraus eine zentrale Entwicklungsaufgabe: Die Anforderungen müssen vergleichbar gemacht werden, ohne ihre jeweilige normative Bedeutung zu verlieren.

Von fünf Bewertungen zu einem Zielkatalog

Genau hier setzt die Safety-by-Wire®-Strategie von Arnold NextG an. Die Sicherheitsziele aus den relevanten Analysen werden normübergreifend konsolidiert. Wo die jeweiligen Normen entsprechende Zuordnungen vorsehen, werden unterschiedliche Risikometriken auf eine gemeinsame Bewertungsbasis abgebildet. Für NX NextMotion bildet die ISO 26262 dabei die Leitnorm der Entwicklung.

Taucht dasselbe Sicherheitsziel in mehreren Einsatzdomänen auf, kann seine Bewertung unterschiedlich ausfallen. Für diesen Fall gilt das Prinzip der strengsten Anforderung. Kein Mittelwert, keine Auswahl nach Anwendung: Die höchste relevante Anforderung wird zum Maßstab für die Plattform. Für die primären Bewegungsfunktionen führt dieser Ansatz bis zur höchsten Einstufung der Leitnorm: ASIL D.

Auf Systemebene entstehen daraus Sicherheitsziele wie die Vermeidung unbeabsichtigter Lenkbewegungen, des Verlusts der Bremsfunktion oder ungewollten Vortriebs. Hinzu kommen Sicherheitsziele für flankierende Funktionen, beispielsweise für die Absicherung des Fahrzeugstillstands oder die Signalisierung. Das Ergebnis ist kein Nebeneinander verschiedener Safety-Kataloge, sondern eine gemeinsame Basis für die weitere Systementwicklung.

Safety-Ziele müssen Architektur bestimmen – nicht umgekehrt

Für OEMs, Tier-1-Zulieferer und Systemintegratoren ist dabei vor allem der Zeitpunkt entscheidend. Ein Sicherheitszielkatalog entfaltet seinen Wert nicht, wenn er nach einer bereits entwickelten Architektur zusammengestellt wird. Er muss vor wesentlichen Architekturentscheidungen stehen. Denn aus den Sicherheitszielen werden technische Anforderungen an Hardware und Software abgeleitet: Welche Funktionen müssen redundant vorhanden sein? Welche Fehler müssen diagnostiziert werden? Welche Reaktionszeiten gelten? Wie muss sich das System nach einem Fehler verhalten?

Bei NX NextMotion stand der konsolidierte Sicherheitszielkatalog deshalb am Anfang der Plattformentwicklung. Entscheidungen zu Redundanz, Diagnose und Degradationsverhalten lassen sich damit auf definierte Sicherheitsziele zurückführen. Gerade für eine Drive-by-Wire-basierte Control Layer ist diese Rückverfolgbarkeit entscheidend: Sie verbindet die ursprüngliche Gefährdungsanalyse mit der technischen Umsetzung und schließlich mit dem Safety Case.

Was OEMs und Integratoren prüfen sollten

Ein ASIL- oder SIL-Claim allein sagt deshalb noch wenig darüber aus, ob ein System zur konkreten Anwendung passt. Entscheidend ist unter anderem, auf welchen Betriebssituationen und Annahmen die zugrunde liegende Gefährdungsanalyse basiert. Decken diese Szenarien den tatsächlichen Einsatz des Fahrzeugs ab? Welche Annahmen wurden zur Kontrollierbarkeit getroffen? Gelten diese auch noch, wenn kein Fahrer im Fahrzeug sitzt?

Ebenso relevant ist die Frage, ob die Sicherheitsziele ausschließlich für eine Fahrzeugdomäne formuliert wurden oder bereits weitere Einsatzfelder berücksichtigen. Für eine skalierbare Drive-by-Wire-Plattform wird Functional Safety damit nicht nur zur Frage des erreichten Sicherheitslevels. Entscheidend ist die Sicherheitsargumentation dahinter.

Fazit: Ein Zielkatalog statt fünf Parallelwelten

Unterschiedliche Fahrzeugdomänen sprechen unterschiedliche Sprachen der funktionalen Sicherheit. Für eine Drive-by-Wire-Plattform, die mehrere dieser Domänen adressiert, müssen daraus jedoch eindeutige technische Anforderungen entstehen. Safety-by-Wire® führt die relevanten Sicherheitsziele deshalb in einer gemeinsamen Sicherheitszielkatalog zusammen. Wo unterschiedliche Bewertungen aufeinandertreffen, setzt die strengste Anforderung den Maßstab.

Damit entsteht die Grundlage für eine multi-redundante, fail-operational Drive-by-Wire-Architektur, deren Sicherheitsanforderungen nicht erst für das nächste Fahrzeugprojekt definiert werden, sondern bereits in der Plattform verankert sind. Denn sichere Fahrzeugbewegung beginnt nicht beim Aktuator. Sie beginnt bei der Frage, welche Gefahr beherrscht werden muss – und welche Architektur dafür notwendig ist.

WE CONTROL WHAT MOVES

This makes drive-by-wire a safety-critical control layer between the driving command and vehicle motion. Whether the command comes from an autonomous driving system, a teleoperator, or a driver: it is not only crucial that it is reliably executed. The safety of the entire chain of action must be systematically verifiable. This is precisely where functional safety comes into play.

From “works” to “verifiably safe”

Testing and validation are indispensable. However, they alone do not answer the crucial question of functional safety: What happens if something fails? What faults can occur? What are their consequences? How are they detected, and how does the system architecture ensure that vehicle movement remains controllable despite the failure?

Standards provide the methodological framework for this—from hazard and risk analysis through safety objectives and technical requirements to verification and validation. For road vehicles, ISO 26262 serves as the central reference framework. However, a drive-by-wire platform—which is used not only in passenger cars or commercial vehicles but also, for example, in agricultural machinery, construction equipment, or intralogistics—encounters multiple sets of standards.

One parent standard, many variants

IEC 61508 is considered the generic base standard for functional safety of electrical, electronic, and programmable electronic systems. Domain-specific standards have emerged from it or are based on it—each tailored to the risk profiles of its specific application area. This is because an autonomous shuttle in urban traffic, a tractor in a field, a wheel loader on a construction site, and a forklift in a warehouse differ fundamentally: in terms of speed and environment, as well as in terms of exposure and a person’s ability to still control a malfunction.

That is why different risk metrics exist:

• ISO 26262 for road vehicles with Automotive Safety Integrity Levels (ASIL A through D)
• IEC 61508 as a generic basis with Safety Integrity Levels (SIL 1 through 4)
• ISO 25119 for agricultural and forestry machinery with Agricultural Performance Levels (AgPL)
• ISO 19014 for earth-moving machinery with Machine Performance Levels (MPL)

• DIN EN 1175 / ISO 13849 for industrial trucks and machine controls with Performance Levels (PL)

Different scales and operating conditions—but essentially the same task: systematically assessing and managing dangerous failures. For NX NextMotion, ISO 26262 is the guiding standard for development. For the primary functions of steering, braking, and propulsion, ASIL D represents the highest relevant safety level. At the same time, a cross-domain platform must take other standards into account already during its development.

Functional Safety Becomes an Architectural Decision

This is precisely where a challenge lies for OEMs, Tier 1 suppliers, and system integrators: functional safety cannot be “added on” at the end of the development process. Hazard analyses, safety requirements, architectural decisions, verification, and documentation are established throughout the development process. If a system is initially developed exclusively for one domain and later transferred to another, significant portions of this verification may need to be repeated. Anyone developing a drive-by-wire platform for multiple vehicle domains must therefore embed the standards strategy into the system architecture at an early stage.

Safety-by-Wire®: A Common Requirements Base

Arnold NextG has therefore decided against separate safety concepts for individual markets in NX NextMotion. The requirements of the relevant standards are consolidated into a common set of requirements. Different risk metrics are systematically mapped to one another—in cases of doubt, the most stringent requirement sets the standard. Arnold NextG refers to this strategy as Safety-by-Wire®.

This is explicitly not about equating different standards. Their scopes of application and conformity requirements remain in place. The difference lies in the development approach: requirements from various vehicle domains are taken into account as early as the platform development phase, rather than retroactively adapting the safety architecture for each new application.

Safety does not end with functional safety

For autonomous and teleoperated vehicles, however, functional safety alone is not sufficient. A comprehensive safety case must take additional levels into account. ISO 21448 (SOTIF) addresses hazards that can arise without technical faults, such as those caused by functional limitations. ISO/SAE 21434 addresses cybersecurity. Added to this are homologation requirements—such as UNECE regulations for steering, braking, and EMC, as well as the new international ADS framework with UN R185 and UN GTR No. 26. For a drive-by-wire-based control layer, functional safety, SOTIF, cybersecurity, and homologation must therefore be considered together from the very beginning.

What does this mean for OEMs and integrators?

One key question should be clarified right at the start of the project: What safety certifications does a platform already provide—and which ones still need to be obtained for the specific vehicle project? This applies not only to the relevant standards landscape. Equally relevant is whether, for example, an ASIL or SIL rating applies only to a single component or to an entire safety-critical function, and how the interfaces between functional safety, SOTIF, and cybersecurity are defined.

At NX NextMotion, this consideration was at the forefront of platform development from the very beginning. The consolidated set of requirements thus creates a pre-developed foundation for various applications. The vehicle manufacturer’s responsibility for the safety case of the entire vehicle remains unaffected.

Conclusion: Safety Requires a Strategy

Standards are not bureaucracy. They are the language through which safety is verifiable—to developers, auditors, regulatory agencies, operators, and ultimately the people who trust autonomous and remotely controlled systems. Anyone developing a drive-by-wire-based control layer for different vehicle domains therefore needs not just a standard, but a standards strategy.

NX NextMotion combines these requirements into a unified, multi-redundant, fail-operational architecture. The goal: to make vehicle movement fully electronically controllable—and to maintain control even if a component in the system fails.

WE CONTROL WHAT MOVES

Damit wird Drive-by-Wire zur sicherheitskritischen Control Layer zwischen Fahrbefehl und Fahrzeugbewegung. Ob der Befehl von einem autonomen Fahrsystem, einem Teleoperator oder einem Fahrer kommt: Entscheidend ist nicht nur, dass er zuverlässig umgesetzt wird. Die Sicherheit der gesamten Wirkungskette muss systematisch nachweisbar sein. Genau hier setzt Functional Safety an.

Von „funktioniert“ zu „nachweisbar sicher“

Testkilometer und Erprobung sind unverzichtbar. Sie allein beantworten jedoch nicht die entscheidende Frage der funktionalen Sicherheit: Was passiert, wenn etwas ausfällt? Welche Fehler können auftreten? Welche Auswirkungen haben sie? Wie werden sie erkannt und wie stellt die Systemarchitektur sicher, dass die Fahrzeugbewegung trotzdem kontrollierbar bleibt?

Normen geben dafür den methodischen Rahmen vor – von der Gefährdungs- und Risikoanalyse über Sicherheitsziele und technische Anforderungen bis zu Verifikation und Validierung. Für Straßenfahrzeuge ist die ISO 26262 dabei der zentrale Referenzrahmen. Doch eine Drive-by-Wire-Plattform, die nicht nur im Pkw oder Nutzfahrzeug, sondern beispielsweise auch in Landmaschinen, Baumaschinen oder der Intralogistik eingesetzt wird, trifft auf mehrere Normenwelten.

Eine Mutternorm, viele Dialekte

Die IEC 61508 gilt als generische Basisnorm der funktionalen Sicherheit für elektrische, elektronische und programmierbare elektronische Systeme. Aus ihr sind domänenspezifische Normen hervorgegangen oder an sie angelehnt worden – jeweils zugeschnitten auf die Risikoprofile ihrer Anwendungswelt. Denn ein autonomes Shuttle im Stadtverkehr, ein Traktor auf dem Feld, ein Radlader auf der Baustelle und ein Stapler im Lager unterscheiden sich fundamental: bei Geschwindigkeit und Umgebung ebenso wie bei Exposition und der Möglichkeit eines Menschen, eine Fehlfunktion noch zu beherrschen.

Deshalb existieren unterschiedliche Risikometriken:

• ISO 26262 für Straßenfahrzeuge mit Automotive Safety Integrity Levels (ASIL A bis D)
• IEC 61508 als generische Basis mit Safety Integrity Levels (SIL 1 bis 4)
• ISO 25119 für Land- und Forstmaschinen mit Agricultural Performance Levels (AgPL)
• ISO 19014 für Erdbaumaschinen mit Machine Performance Levels (MPL)

• DIN EN 1175 / ISO 13849 für Flurförderzeuge und Maschinensteuerungen mit Performance Levels (PL)

Unterschiedliche Skalen und Einsatzbedingungen – aber im Kern dieselbe Aufgabe: gefährliche Ausfälle systematisch bewerten und beherrschen. Für NX NextMotion ist ISO 26262 die Leitnorm der Entwicklung. Für die primären Funktionen Lenken, Bremsen und Antrieb bildet ASIL D die höchste relevante Sicherheitsstufe. Gleichzeitig muss eine domänenübergreifende Plattform weitere Normenwelten bereits in ihrer Entwicklung berücksichtigen.

Functional Safety wird zur Architekturentscheidung

Genau hier liegt eine Herausforderung für OEMs, Tier-1-Zulieferer und Systemintegratoren: Funktionale Sicherheit lässt sich nicht am Ende einer Entwicklung „ergänzen“. Gefährdungsanalysen, Sicherheitsanforderungen, Architekturentscheidungen, Verifikation und Dokumentation entstehen entlang des Entwicklungsprozesses. Wird ein System zunächst ausschließlich für eine Domäne entwickelt und später auf eine weitere übertragen, können wesentliche Teile dieser Nachweise erneut erforderlich werden. Wer eine Drive-by-Wire-Plattform für mehrere Fahrzeugwelten entwickelt, muss die Normenstrategie deshalb frühzeitig in der Systemarchitektur verankern.

Safety-by-Wire®: eine gemeinsame Anforderungsbasis

Arnold NextG hat sich bei NX NextMotion deshalb gegen separate Safety-Konzepte für einzelne Märkte entschieden. Die Anforderungen der relevanten Normenwelten werden in einer gemeinsamen Anforderungsbasis konsolidiert. Unterschiedliche Risikometriken werden systematisch aufeinander abgebildet – im Zweifel setzt die strengste Anforderung den Maßstab. Diese Strategie bezeichnet Arnold NextG als Safety-by-Wire®.

Dabei geht es ausdrücklich nicht darum, unterschiedliche Normen gleichzusetzen. Ihre Anwendungsbereiche und Konformitätsanforderungen bleiben bestehen. Der Unterschied liegt im Entwicklungsansatz: Anforderungen verschiedener Fahrzeugdomänen werden bereits bei der Plattformentwicklung berücksichtigt, statt die Sicherheitsarchitektur für jede neue Anwendung nachträglich anzupassen.

Sicherheit endet nicht bei Functional Safety

Für autonome und teleoperierte Fahrzeuge reicht Functional Safety allein allerdings nicht aus. Ein vollständiger Safety Case muss weitere Ebenen berücksichtigen. ISO 21448 (SOTIF) betrachtet Gefährdungen, die ohne technischen Fehler entstehen können, beispielsweise durch funktionale Grenzen. ISO/SAE 21434 adressiert Cybersecurity. Hinzu kommen die Anforderungen der Homologation – beispielsweise UNECE-Regelungen für Lenkung, Bremse und EMV sowie der neue internationale ADS-Rahmen mit UN R185 und UN GTR No. 26. Für eine Drive-by-Wire-basierte Control Layer müssen Functional Safety, SOTIF, Cybersecurity und Homologation deshalb von Anfang an zusammengedacht werden.

Was bedeutet das für OEMs und Integratoren?

Eine zentrale Frage sollte bereits zu Projektbeginn geklärt sein: Welche Sicherheitsnachweise bringt eine Plattform mit – und welche müssen im konkreten Fahrzeugprojekt noch erbracht werden? Das betrifft nicht nur die jeweilige Normenwelt. Ebenso relevant ist, ob beispielsweise eine ASIL- oder SIL-Aussage lediglich für eine Komponente gilt oder für eine vollständige sicherheitsrelevante Funktion und wie die Schnittstellen zwischen Functional Safety, SOTIF und Cybersecurity definiert sind.

Bei NX NextMotion stand diese Betrachtung am Anfang der Plattformentwicklung. Die konsolidierte Anforderungsbasis schafft damit ein vorentwickeltes Fundament für unterschiedliche Anwendungen. Die Verantwortung des Fahrzeugherstellers für den Safety Case des Gesamtfahrzeugs bleibt davon unberührt.

Fazit: Sicherheit braucht eine Strategie

Normen sind keine Bürokratie. Sie sind die Sprache, in der Sicherheit nachweisbar wird – gegenüber Entwicklern, Auditoren, Zulassungsstellen, Betreibern und letztlich den Menschen, die autonomen und ferngesteuerten Systemen vertrauen. Wer eine Drive-by-Wire-basierte Control Layer für unterschiedliche Fahrzeugdomänen entwickelt, braucht deshalb nicht nur eine Norm, sondern eine Normenstrategie.

NX NextMotion verbindet diese Anforderungen in einer gemeinsamen, multi-redundanten, fail-operational Architektur. Das Ziel: Fahrzeugbewegung vollständig elektronisch steuerbar zu machen – und die Kontrolle auch dann zu erhalten, wenn im System etwas ausfällt.

WE CONTROL WHAT MOVES

In the first part of this series, we explained why a distinct, safety-critical layer—the control layer—emerges between the driving decision and the vehicle’s movement. In the second part, we examine the technical requirements for this layer and show why drive-by-wire is becoming the key enabler of future software-defined vehicle architectures.

What Matters Technically in a Control Layer

• Deterministic command processing: A Control Layer must process driving commands in a reproducible manner at all times. Priorities, timing behavior, and threshold values must not depend on the current system state or the order of execution. Identical input situations must result in identical vehicle responses.
• End-to-end monitoring of the chain of action: Safety does not end with the driving command. The entire chain—from input through communication and actuators to the actual vehicle movement—must be continuously monitored and validated.
• Redundancy and fault containment: Critical functions require independent signal, computing, and communication paths. Faults must be detected, localized, and contained without compromising the entire control function.
• Fail-operational rather than fail-silent: A control layer must not simply shut down in the event of errors. It is crucial that the necessary control capability is maintained to execute a defined minimum-risk behavior or a safe system transition.
• Diagnostics and Traceability: Safety-relevant states, faults, and system responses must be documented in a traceable manner. This data forms the basis for the safety case, certification, in-service monitoring, and continuous development.
• Open and defined interfaces: A control layer must be able to integrate different control sources—such as the AD stack, teleoperation, or driver interaction—via clearly defined interfaces. This facilitates reuse, platform integration, and homologation.

Why Drive-by-Wire Is Becoming a Key Enabler

Traditional vehicle architectures were developed for a world in which a human was a permanent part of the control loop. Mechanical or hydraulic connections could serve as both the control path and the fallback mechanism. In driverless applications, this assumption no longer applies: The vehicle must be able to electronically control and monitor steering, braking, and propulsion, and transition to a controlled state in the event of faults.

Drive-by-wire replaces or supplements mechanical control paths with electronic signal and control paths. However, its strategic value lies not solely in the elimination of a steering column or in new packaging freedoms. What is crucial is that vehicle movement becomes addressable, measurable, and controllable via software within a defined safety architecture.

Regulations do not mandate drive-by-wire. In practical implementation, however, they highlight characteristics that are difficult to achieve at scale without highly available electronic motion control: controlled response to faults, unambiguous system states, traceable diagnostics, repeatable validation, and the integration of different control sources.

Safety-by-Wire® and NX NextMotion: Arnold NextG’s Approach

Arnold NextG views Safety-by-Wire® not as a single function, but as an overarching architectural principle. Hardware, embedded software, communication, actuators, power supply, diagnostics, and safety mechanisms are considered as an interconnected chain of effects.

Within this approach, NX NextMotion forms the central control layer. The platform is modular, can be integrated independently of the vehicle, and, according to the company, features a quadruply redundant hardware and software architecture. It controls primary functions such as steering, braking, and propulsion, as well as selected safety-critical secondary functions, and can process driving commands from various sources within a common safety architecture.

• Multi-redundant computing, communication, and power supply paths to avoid critical single points of failure.
• Continuous monitoring and TÜV-certified error management at the hardware and software levels.
• Functional safety in accordance with ISO 26262 up to ASIL D and IEC 61508 SIL 3, as demonstrated by the development and validation documentation.
• TÜV certifications for steering and braking systems in accordance with UN ECE R79 and R13, as well as proven road approval.
• Platform-independent integration from prototype to a vehicle solution ready for homologation.

Arnold NextG is thus deliberately positioning itself not as just another provider of the AD stack. Its strategic role lies below that: NX NextMotion is designed to ensure that a digital driving decision—regardless of whether it originates from autonomy, teleoperation, or a human—is translated into a defined and controlled vehicle movement.

“We’re not developing the next driving algorithm. We’re developing the secure layer on which different driving decisions are reliably translated into movement in the first place. That is precisely where the strategic importance of the Control Layer lies," says Kevin Arnold, CEO of Arnold NextG GmbH.

What OEMs, ADS developers, and system partners should clarify now

The new regulatory framework does more than just increase the documentation burden. It changes architectural decisions and the boundaries of responsibility. For projects involving highly or fully automated driving functions, five questions should therefore be answered early on:

• Where does the responsibility of the AD stack end—and where does the responsibility for the actual vehicle motion begin?
• Which faults must be detected and controlled by the control layer, regardless of the driving algorithm?
• How are software updates, new driving functions, and vehicle variants integrated into an existing safety case?
• What data and diagnostics are required for approval, event analysis, and in-service monitoring?
• Which parts of the motion control are project-specific—and which can be used as a reusable, pre-developed system foundation?

A clearly defined control layer can reduce complexity here. It does not replace the vehicle manufacturer’s system responsibility. However, it creates a reusable safety and integration foundation upon which different AD stacks, platforms, and applications can be built.

Regulatory requirements are not the final chapter

The new ADS regulations shift the focus from a one-time approval to an ongoing safety model. Safety management, software changes, field data, incident reports, and system limits must remain consistent throughout operation. For companies, this means that regulatory compliance cannot simply be “tacked on” at the end of a development project. It must be an integral part of the architecture, development process, supply chain, and operating model.

For Arnold NextG, this development confirms its own architectural strategy: What matters is not merely whether a system makes the right driving decision, but whether that decision can be implemented in a way that is controlled, traceable, and fault-tolerant at all times.Conclusion: Autonomy begins with controllable movement

UN R185 and UN GTR 26 establish an important international framework. They do not define a specific technical solution, nor do they mandate drive-by-wire. However, they make it unmistakably clear that safety must be demonstrated across the entire chain of effects of an automated driving system.

This brings the layer between the algorithm and the actuators into focus. The control layer becomes the strategic infrastructure of the software-defined vehicle: It connects different control sources, manages errors, generates evidence, and translates digital decisions into real-world motion. Autonomous mobility does not begin with an algorithm’s decision. It begins with the ability to execute every movement in a controlled manner.

WE CONTROL WHAT MOVES.

Sources and Regulatory Note

This classification takes into account the status of the published results from the 21st ADS session of the UNECE held July 14–17, 2026. It represents a technical and strategic assessment by Arnold NextG and does not constitute legal or homologation advice.

• UNECE: Communication on the new global ADS regulations
• UNECE ADS IWG: 21st Session, Brussels, July 14–17, 2026
• Arnold NextG: NX NextMotion
• Arnold NextG: Safety Concept
• Arnold NextG: Certificates
• Arnold NextG: Company and Mission

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