Für Entwickler, OEMs, Tier-1-Zulieferer und Systemintegratoren wird Teleoperation damit zu einer Frage der Fahrzeug- und Steuerungsarchitektur. Eine Kommunikationsverbindung kann Steueranforderungen übertragen. Sie garantiert jedoch weder deren kontrollierte Umsetzung in Lenkung, Bremse und Antrieb noch eine belastbare Rückmeldung darüber, wie die reale Plattform tatsächlich reagiert.

Teleoperation ist mehr als eine Kommunikationsstrecke

Eine teleoperierte Plattform benötigt einen durchgängigen Steuerungspfad vom externen Bedienplatz bis zu den Bewegungsfunktionen des Fahrzeugs – und einen Rückkanal zurück zum Operator. Damit entsteht ein geschlossener Regelkreis:

Steueranforderung → elektronische Verarbeitung → Aktuatorik → Fahrzeugbewegung → Rückmeldung an den Operator.

Wie relevant diese Gesamtsystembetrachtung ist, zeigt auch der zivile regulatorische Rahmen. Die deutsche Straßenverkehr-Fernlenk-Verordnung betrachtet Fahrzeug und technische Fernlenkausrüstung ausdrücklich als Gesamtsystem und verlangt, Übertragungslatenzen im Sicherheitskonzept zu berücksichtigen. Für bestimmte Signale, die den Operator unmittelbar bei der dynamischen Fahraufgabe unterstützen, sieht die Verordnung eine maximale Signallatenz von 0,2 Sekunden vor. Das ist keine Defence-Vorgabe, verdeutlicht aber die enge technische Kopplung zwischen Kommunikation, Verarbeitung und Fahrzeugreaktion.

Für Defence-Anwendungen bleibt die konkrete Auslegung vom jeweiligen Einsatz- und Systemkontext abhängig. Die grundlegende Engineering-Frage ist jedoch dieselbe: Wie wird aus einer extern übertragenen Anforderung eine kontrollierte Fahrzeugbewegung?

Drive-by-Wire schließt die Lücke zwischen Leitstand und Fahrzeugbewegung

Genau hier setzt Drive-by-Wire an. Lenkung, Bremse und Antrieb werden elektronisch ansprechbar und können in eine übergeordnete digitale Steuerungsarchitektur eingebunden werden. Mit NX NextMotion bildet Arnold NextG dafür eine sicherheitsgerichtete Control Layer. Externe Steueranforderungen werden verarbeitet, auf Plausibilität geprüft und über die jeweilige Aktuatorik in reale Fahrzeugbewegung umgesetzt. Gleichzeitig überwacht die Architektur die beteiligten Funktionen und kann auf erkannte Fehler mit definierten Reaktionen antworten.

Teleoperation ist damit keine separate Fernsteuerung, die neben der eigentlichen Fahrzeugsteuerung arbeitet. Sie wird zu einer Steuerquelle innerhalb der Bewegungsarchitektur. Der technische Aufbau von NX NextMotion und die Integration unterschiedlicher Steuerquellen sind auch im ATZheavy-duty-Fachbeitrag zur Drive-by-Wire-Plattform dokumentiert.

Der Rückkanal entscheidet mit über die Qualität der Teleoperation

Je weiter der Operator vom Fahrzeug entfernt ist, desto wichtiger wird die Frage, welche Informationen aus der realen Plattform zurückgeführt werden. Kamerabilder bilden einen Teil dieser Rückmeldung ab. Hinzu kommen je nach Systemauslegung Zustandsdaten sowie Informationen zu Fahrzeugreaktion, Lenkkräften, Schlupf oder Untergrund. Diese können über visuelle, digitale oder haptische Rückkanäle bereitgestellt werden. Besonders deutlich wird die Bedeutung der Rückkopplung beim Force Feedback.

Bei NX NextMotion ist die haptische Rückmeldung Bestandteil des sicherheitsrelevanten Lenkpfads. Im zugrunde liegenden Sicherheitskonzept wird sie auf Basis der Fehlerbaumanalyse entsprechend sicherheitskritisch behandelt. Das Feedback wird dabei nicht ausschließlich künstlich im Bediengerät erzeugt, sondern aus plausibilisierten physikalischen und fahrdynamischen Größen abgeleitet. Damit wird Force Feedback vom reinen Bedienmerkmal zu einem Bestandteil des geschlossenen Bewegungsregelkreises.

Für diese Verarbeitung gelten Echtzeit-, Redundanz- und Fehlerreaktionsanforderungen wie für die übrige Steer-by-Wire-Funktion. Der Steuerungs- und Diagnosezyklus von NX NextMotion liegt bei zwei Millisekunden. Der zugrunde liegende technische Ansatz ist im ATZheavy-duty-Fachbeitrag dokumentiert.

Ohne Fahrer verändert sich die Sicherheitsarchitektur

Bei einer bemannten Plattform kann ein Fahrer unter bestimmten Bedingungen als Rückfallebene zur Verfügung stehen. Bei einem unbemannten oder vollständig teleoperierten Fahrzeug entfällt diese Annahme. Kommunikation, Sensorik, Aktuatorik, Steuerung und Energieversorgung müssen deshalb als zusammenhängender sicherheitsgerichteter Steuerungspfad betrachtet werden. Ein Kommunikationsabbruch oder der Verlust eines Signalpfads darf nicht zu einer unkontrollierten Fahrzeugbewegung führen.

Für Drive-by-Wire bedeutet das: Die Architektur muss Fehler erkennen, den verbleibenden Funktionsumfang bewerten und eine definierte Reaktion ermöglichen. NX NextMotion ist dafür multi-redundant und fail-operational ausgelegt. Entscheidend ist dabei nicht allein die Redundanz eines Steuergeräts, sondern die Betrachtung der gesamten sicherheitsrelevanten Wirkungskette. Arnold NextG beschreibt diesen Architekturansatz auch im Zusammenhang mit der kontrollierten Fahrzeugbewegung ohne Fahrer als permanente Rückfallebene. Hintergrund: fail-operational Drive-by-Wire bei NX NextMotion (https://www.pressebox.de/…)

Teleoperation wird zur integrierten Fahrzeugfunktion

Für Defence-Plattformen liegt die technische Herausforderung nicht allein in der Übertragung von Steueranforderungen. Entscheidend ist, wie externe Bedienung, Fahrzeugsteuerung und Aktuatorik zu einer durchgängigen Architektur verbunden werden. Der Remote Operator, die Kommunikationsstrecke und die Drive-by-Wire Control Layer übernehmen dabei unterschiedliche Aufgaben. Während der Bedienplatz Steueranforderungen erzeugt und Fahrzeuginformationen visualisiert, verbindet NX NextMotion diese Anforderungen mit den realen Bewegungsfunktionen des Fahrzeugs.

Damit bleiben die Systemebenen klar voneinander getrennt: Teleoperation stellt die Steuerquelle bereit, Drive-by-Wire übernimmt die kontrollierte Umsetzung in Lenkung, Bremse und Antrieb.

Für OEMs, Tier-1-Zulieferer und Systemintegratoren ist diese Trennung besonders relevant. Neue Bedien- oder Automatisierungsfunktionen können über definierte Schnittstellen in die Fahrzeugarchitektur integriert werden, während die Anbindung an Aktuatorik, Bordnetz und Kommunikationssysteme plattformspezifisch bleibt.

Was OEMs und Integratoren bei Defence Teleoperation betrachten müssen

Für die technische Bewertung einer teleoperierten Plattform sind deshalb nicht nur Reichweite oder Bandbreite der Kommunikationsverbindung relevant. Entscheidend sind insbesondere:

• Steuerungspfad: Wie gelangen externe Steueranforderungen sicherheitsgerichtet bis zu Lenkung, Bremse und Antrieb?
• Rückkopplung: Welche Informationen über die reale Fahrzeugreaktion stehen dem Operator zur Verfügung?
• Zeitverhalten: Wie werden Latenzen, Übertragungsunterbrechungen und Reaktionszeiten erkannt und behandelt?
• Fehlerverhalten: Welche Fahrzeugfunktionen bleiben kontrollierbar, wenn kein Fahrer im Fahrzeug als unmittelbare Rückfallebene zur Verfügung steht?

Damit verschiebt sich die zentrale Entwicklungsfrage von „Wie übertragen wir einen Fahrbefehl?“ zu „Wie erhalten wir einen geschlossenen und kontrollierbaren Fahrzeugregelkreis?“

Teleoperation wird zur Systemeigenschaft der Plattform

Gerade im Defence-Umfeld kann Teleoperation unterschiedliche Plattformtypen und Nutzungskonzepte betreffen – von neu entwickelten unbemannten Fahrzeugen bis zu digitalisierten Bestandsplattformen. Für eine skalierbare Integration ist deshalb entscheidend, Teleoperation nicht als isolierte Zusatzfunktion zu behandeln. Die externe Bedienung muss Bestandteil einer Fahrzeugarchitektur werden, die elektronische Steuerung, Rückmeldung, Diagnose und Fehlerreaktion gemeinsam betrachtet.

NX NextMotion bildet dafür die Drive-by-Wire Control Layer zwischen externer Steueranforderung und realer Fahrzeugbewegung. Der technologische Kern ist damit einfach formuliert: Teleoperation überträgt nicht nur Kontrolle über Distanz. Sie muss die Kontrolle über Bewegung auch über diese Distanz erhalten.

WE CONTROL WHAT MOVES

weitere Information: www.arnoldnextg.de

Quellen und technische Einordnung

Straßenverkehr-Fernlenk-Verordnung (StVFernLV), Anlage 1 – Technische Anforderungen
Regulatorischer Referenzrahmen für Fernlenkung im zivilen Straßenverkehr; im Beitrag ausschließlich zur technischen Einordnung der Signallatenz verwendet, nicht als Defence-Vorgabe.
https://www.gesetze-im-internet.de/stvfernlv/anlage_1.html

ATZheavy duty 02/2026 – „Drive-by-Wire-Plattform zur Integration verschiedener Steuerquellen“
Technische Grundlage unter anderem für NX NextMotion, Teleoperation, Force Feedback sowie den Steuerungs- und Diagnosezyklus.
https://link.springer.com/article/10.1007/s35746-026-1416-1

For OEMs, Tier 1 suppliers, system integrators, and operators, retrofitting is therefore increasingly becoming an architectural challenge. It is no longer sufficient to simply integrate additional sensors, communication systems, or electronic components into an existing platform. As soon as new forms of vehicle control are added, the steering, brakes, and powertrain must also be electronically controllable in a safe and reliable manner.

This is precisely where drive-by-wire expands the possibilities for modernization. The technology establishes the electronic connection between digital driving functions and the vehicle’s actual motion functions. This allows existing platforms to be adapted for new capabilities without necessarily having to develop an entirely new generation of vehicles. As a result, drive-by-wire is evolving from an individual retrofit project into the technological foundation for the gradual digitization of heterogeneous defense fleets.

Existing platforms have different requirements than new developments

In a newly developed vehicle, the electrical system, communication systems, control units, sensors, and actuators can be designed together from the outset. Digital controllability is an integral part of the vehicle architecture. With an existing platform, the starting point is fundamentally different.

Integration must account for existing electrical systems, existing bus systems, and mechanical or hydraulic actuators for steering, braking, and propulsion. Depending on the vehicle, actuators, sensors, electronic signal paths, and communication interfaces must therefore be integrated into an existing architecture.

For developers and integrators, this results in a complex system challenge: The new electronic control system must work together with the existing vehicle technology while also ensuring defined behavior even in the event of faults. Retrofit is therefore far more than the retroactive installation of individual components. It is the integration of a safety-critical control architecture under the real-world constraints of the respective platform.

Scalable Architecture Instead of a One-Off Solution

Defense fleets, in particular, are technically heterogeneous. Wheeled and tracked vehicles, different weight classes, various platform generations, as well as diesel, “ ” hybrid, and electric powertrains must be operated and further developed in parallel. An economically scalable modernization can therefore hardly be based on developing a completely new drive-by-wire solution for each vehicle type.

Arnold NextG’s technical approach consists of separating a reusable, safety-critical control core from platform-specific integration. NX NextMotion is designed as an open, manufacturer-independent drive-by-wire platform. The architecture can be integrated into various wheeled and tracked vehicles as well as different drive concepts. Steering, braking, and propulsion are integrated into a digital control architecture via electronic interfaces.

This creates the foundation for various forms of vehicle control—ranging from manual driving to teleoperation and autonomous functions, all the way to coupled applications such as platooning. The key distinction here is that reusability does not mean plug-and-play. Each target platform requires its own technical interface, parameterization, and evaluation. Vehicle communication, actuators, the electrical system, and mechanical requirements differ from platform to platform. Integration can, for example, utilize existing communication structures such as CAN, but must always be tailored to the specific vehicle.

Safety must be considered across the entire control path

With the electronic control of steering, braking, and propulsion, functions that are directly relevant to the vehicle’s controllability are being digitized. Accordingly, it is not sufficient to simply design a control unit with redundancy. Signal transmission, actuators, sensors, communication, and power supply must be considered as an integrated system.

The goal is to ensure that a single fault does not lead to an uncontrolled loss of vehicle control. To this end, NX NextMotion incorporates an architectural foundation into the integration process that was developed in accordance with relevant functional safety and cybersecurity requirements. For OEMs and integrators, this represents a key difference from a project-specific, standalone solution: fundamental mechanisms for safe electronic vehicle control do not have to be completely redeveloped from scratch for every new platform.

Nevertheless, the specific overall vehicle assessment always depends on the target platform, the scope of integration, and the intended use. Retrofittability is thus a characteristic of the architecture—not a universally transferable vehicle approval.

From Digital Connectivity to New Vehicle Capabilities

The actual added value of such a retrofit architecture therefore lies not solely in the digitization of a single vehicle. If the same safety-oriented control approach is applied across multiple platforms, it creates a technical foundation for the gradual modernization of heterogeneous fleets. This also changes the perspective on future capabilities.

Teleoperation, autonomous driving functions, or platooning do not necessarily have to be tied to a new generation of vehicles. They can be integrated wherever the necessary technical prerequisites are met—including on existing platforms. For operators, this means being able to further develop the functionality of existing vehicles throughout their remaining service life . For OEMs and Tier 1 suppliers, this creates an architectural foundation upon which new digital functions can be built. System integrators can focus their customization efforts more on the specific vehicle connectivity rather than having to redevelop the basic control architecture for each platform.

Retrofit thus becomes a strategic architectural decision

The global market for upgrades and retrofits of armored vehicles was valued at approximately $6.46 billion in 2025. Growth of about 4.5 percent was expected for 2026. Behind this trend lies a long-term goal: to extend the service life of existing fleets while equipping them with new digital capabilities. For the technical implementation, therefore, it will not be decisive solely which new function can be demonstrated on a vehicle. What matters is whether the underlying architecture is scalable.

A retrofittable drive-by-wire platform bridges the gap between existing vehicle technology and new forms of digital vehicle control. This transforms a single retrofit project into a foundation for the modernization of entire vehicle families and fleets.

NX NextMotion creates the conditions for making existing platforms digitally controllable—with a reusable, safety-critical control core and platform-specific integration.

WE CONTROL WHAT MOVES

Source for market classification:
Armored Vehicle Upgrade and Retrofit Market Report 2026, Research and Markets.

Für OEMs, Tier-1-Zulieferer, Systemintegratoren und Betreiber wird Retrofit deshalb zunehmend zu einer Architekturaufgabe. Es reicht nicht mehr aus, zusätzliche Sensoren, Kommunikationssysteme oder elektronische Komponenten in eine bestehende Plattform zu integrieren. Sobald neue Formen der Fahrzeugführung hinzukommen, müssen auch Lenkung, Bremse und Antrieb elektronisch, sicherheitsgerichtet und zuverlässig ansprechbar sein.

Genau hier erweitert Drive-by-Wire die Möglichkeiten der Modernisierung. Die Technologie schafft die elektronische Verbindung zwischen digitalen Fahrfunktionen und den realen Bewegungsfunktionen des Fahrzeugs. So können auch bestehende Plattformen für neue Fähigkeiten geöffnet werden, ohne dass dafür zwingend eine vollständig neue Fahrzeuggeneration entwickelt werden muss. Damit wird Drive-by-Wire vom einzelnen Retrofit-Projekt zur technologischen Grundlage für die schrittweise Digitalisierung heterogener Defence-Flotten.

Bestandsplattformen stellen andere Anforderungen als Neuentwicklungen

Bei einem neu entwickelten Fahrzeug können Bordnetz, Kommunikationssysteme, Steuergeräte, Sensorik und Aktuatorik von Beginn an gemeinsam ausgelegt werden. Die digitale Steuerbarkeit ist Teil der Fahrzeugarchitektur. Bei einer Bestandsplattform ist die Ausgangslage grundlegend anders.

Die Integration trifft auf vorhandene elektrische Systeme, bestehende Bussysteme sowie mechanische oder hydraulische Betätigungen für Lenkung, Bremse und Antrieb. Abhängig vom Fahrzeug müssen deshalb Aktuatoren, Sensoren, elektronische Signalpfade und Kommunikationsschnittstellen in eine bereits existierende Architektur eingebunden werden.

Für Entwickler und Integratoren entsteht daraus eine komplexe Systemaufgabe: Die neue elektronische Steuerung muss mit der vorhandenen Fahrzeugtechnik zusammenarbeiten und gleichzeitig ein definiertes Verhalten auch bei Fehlern ermöglichen. Retrofit ist deshalb weit mehr als die nachträgliche Installation einzelner Komponenten. Es ist die Integration einer sicherheitsgerichteten Steuerungsarchitektur unter den realen Randbedingungen der jeweiligen Plattform.

Skalierbare Architektur statt Einzellösung

Gerade Defence-Flotten sind technisch heterogen. Rad- und Kettenfahrzeuge, unterschiedliche Gewichtsklassen, verschiedene Plattformgenerationen sowie Diesel-, Hybrid- und Elektroantriebe müssen parallel betrieben und weiterentwickelt werden. Eine wirtschaftlich skalierbare Modernisierung kann deshalb kaum darauf basieren, für jeden Fahrzeugtyp eine vollständig neue Drive-by-Wire-Lösung zu entwickeln.

Der technische Ansatz von Arnold NextG besteht darin, einen wiederverwendbaren sicherheitsgerichteten Steuerungskern von der plattformspezifischen Integration zu trennen. NX NextMotion ist als offene, herstellerunabhängige Drive-by-Wire-Plattform ausgelegt. Die Architektur kann in unterschiedliche Rad- und Kettenfahrzeuge sowie verschiedene Antriebskonzepte integriert werden. Über elektronische Schnittstellen werden Lenkung, Bremse und Antrieb in eine digitale Steuerungsarchitektur eingebunden.

Damit entsteht die Grundlage für unterschiedliche Formen der Fahrzeugführung – vom Fahrer über Teleoperation und autonome Funktionen bis hin zu gekoppelten Anwendungen wie Platooning. Entscheidend ist dabei die Abgrenzung: Wiederverwendbarkeit bedeutet nicht Plug-and-play. Jede Zielplattform benötigt eine eigene technische Anbindung, Parametrierung und Bewertung. Fahrzeugkommunikation, Aktuatorik, Bordnetz und mechanische Voraussetzungen unterscheiden sich von Plattform zu Plattform. Die Integration kann beispielsweise bestehende Kommunikationsstrukturen wie CAN nutzen, muss aber immer auf das konkrete Fahrzeug abgestimmt werden.

Safety muss über den gesamten Steuerungspfad betrachtet werden

Mit der elektronischen Kontrolle von Lenkung, Bremse und Antrieb werden Funktionen digitalisiert, die unmittelbar für die Beherrschbarkeit des Fahrzeugs relevant sind. Entsprechend reicht es nicht aus, lediglich ein Steuergerät redundant auszulegen. Signalübertragung, Aktuatorik, Sensorik, Kommunikation und Energieversorgung müssen als zusammenhängendes System betrachtet werden.

Ziel ist, dass ein einzelner Fehler nicht zu einem unkontrollierten Verlust der Fahrzeugführung führt. NX NextMotion bringt dafür eine Architekturgrundlage in die Integration ein, die unter Berücksichtigung einschlägiger Anforderungen an funktionale Sicherheit und Cybersecurity entwickelt wurde. Für OEMs und Integratoren liegt darin ein wesentlicher Unterschied zu einer projektspezifischen Einzellösung: Grundlegende Mechanismen für sichere elektronische Fahrzeugsteuerung müssen nicht für jede neue Plattform vollständig neu entwickelt werden.

Die konkrete Gesamtfahrzeugbewertung bleibt dennoch immer abhängig von Zielplattform, Integrationsumfang und vorgesehenem Einsatz. Nachrüstbarkeit ist damit eine Eigenschaft der Architektur – keine pauschal übertragbare Fahrzeugzulassung.

Von der digitalen Anbindung zur neuen Fahrzeugfähigkeit

Der eigentliche Mehrwert einer solchen Retrofit-Architektur liegt deshalb nicht allein in der Digitalisierung eines einzelnen Fahrzeugs. Wird derselbe sicherheitsgerichtete Steuerungsansatz über mehrere Plattformen hinweg eingesetzt, entsteht eine technische Grundlage für die schrittweise Modernisierung heterogener Flotten. Das verändert auch die Perspektive auf zukünftige Fähigkeiten.

Teleoperation, autonome Fahrfunktionen oder Platooning müssen dann nicht zwangsläufig an eine neue Fahrzeuggeneration gekoppelt sein. Sie können dort integriert werden, wo die erforderlichen technischen Voraussetzungen geschaffen werden – auch auf bereits vorhandenen Plattformen. Für Betreiber bedeutet das, bestehende Fahrzeuge über ihre verbleibende Nutzungsdauer funktional weiterentwickeln zu können. Für OEMs und Tier-1-Zulieferer entsteht eine Architekturgrundlage, auf der sich neue digitale Funktionen aufbauen lassen. Systemintegratoren können die Anpassung stärker auf die konkrete Fahrzeuganbindung konzentrieren, statt bei jeder Plattform die grundlegende Steuerungsarchitektur neu zu entwickeln.

Retrofit wird damit zur strategischen Architekturentscheidung

Der weltweite Markt für Upgrades und Retrofit gepanzerter Fahrzeuge lag 2025 bei rund 6,46 Milliarden US-Dollar. Für 2026 wurde ein Wachstum von etwa 4,5 Prozent erwartet. Hinter dieser Entwicklung steht eine langfristige Aufgabe: Bestehende Flotten sollen länger genutzt werden und gleichzeitig neue digitale Fähigkeiten erhalten. Für die technische Umsetzung wird deshalb nicht allein entscheidend sein, welche neue Funktion auf einem Fahrzeug demonstriert werden kann. Entscheidend ist, ob die zugrunde liegende Architektur skalierbar ist.

Eine nachrüstbare Drive-by-Wire-Plattform schafft dafür die Verbindung zwischen bestehender Fahrzeugtechnik und neuen Formen digitaler Fahrzeugführung. Damit wird aus einem einzelnen Retrofit-Projekt perspektivisch eine Grundlage für die Modernisierung ganzer Fahrzeugfamilien und Flotten.

NX NextMotion schafft die Voraussetzung, bestehende Plattformen digital steuerbar zu machen – mit einem wiederverwendbaren sicherheitsgerichteten Steuerungskern und einer plattformspezifischen Integration.

WE CONTROL WHAT MOVES

Quelle zur Markteinordnung:
Armored Vehicle Upgrade and Retrofit Market Report 2026, Research and Markets.

The safety case links precisely these levels into a consistent chain of reasoning and evidence. The path from each safety goal—through requirements and architecture—to the test result must be traceable—and vice versa.

For NX NextMotion, a drive-by-wire-based control layer for autonomous and teleoperated vehicles, this traceability is an essential component of system development. After all, when steering, braking, and propulsion are controlled entirely electronically, it is not only the safety architecture that must be robust—the evidence of its effectiveness must be as well.

The Safety Case Is Not Just a Pile of Paper

A safety case is not created simply by compiling as many supporting documents as possible at the end of the project. Traceability is crucial. For every safety objective, it must be possible to trace the path from requirements and architecture through to analyses and test results—and from every test result back to the safety requirement it verifies. With Safety-by-Wire^(®),this chain of evidence therefore begins in the early development phases and accompanies NX NextMotion throughout its entire lifecycle.

Requirements-in-the-Loop: Verify Before Implementation

One of the most costly sources of errors in system development does not necessarily lie in the code. Even incomplete, contradictory, or unfulfillable requirements can carry over into the architecture, implementation, and testing phases. Arnold NextG therefore starts right at the requirements stage.

With Requirements-in-the-Loop, requirements and scenarios are verified through simulation in the early system phases—before the first line of production code is written. The goal is to identify contradictions, gaps, or unfulfillable combinations while they can still be corrected at the requirements level. This approach is integrated into requirements gathering and analysis—specifically, in the Automotive SPICE framework at SYS.1 and SYS.2. As a result, safety verification does not begin only on the verification side of the development model, but already during the specification phase.

FMEDA and FTA: Quantitatively Evaluating Architecture

Quantitative safety analyses are conducted in parallel with the development of the system architecture.

FMEDA—Failure Modes, Effects, and Diagnostics Analysis—examines possible failure modes of hardware components, their effects, and the effectiveness of diagnostics. It thus provides a basis for assessing whether dangerous single-event failures are detected and latent faults are sufficiently controlled.

Fault Tree Analysis (FTA) takes the opposite perspective. Starting from an undesirable top-level event—such as the loss of steering function—it examines which individual events or combinations of events could lead to it.

For a multi-redundant, fully fail-operational drive-by-wire architecture, this interplay is particularly crucial. It is not enough for redundancy to simply be plausible; the safety case must provide verifiable evidence that the architecture meets the underlying safety objectives.

From Simulation to the Real Vehicle

As the system matures, the validation process gradually shifts from the virtual to the real world. Software-in-the-Loop (SiL) tests functional logic in a simulated environment. Hardware-in-the-Loop (HiL) integrates real control hardware and enables targeted fault injections under reproducible conditions. Finally, Vehicle-in-the-Loop (ViL) connects the real vehicle to a simulated environment.

This chain is particularly essential for safety-critical drive-by-wire functions. Errors in communication, power supply, or control—as well as defined multiple faults and transitions between operating states—can be specifically investigated without first having to generate such situations during road or machine operation. Real-world vehicle operation remains indispensable, however, as it supplements the simulation with conditions and interactions that cannot be fully anticipated.

Validation Does Not End with SOP

A safety case is not complete once production begins. Software updates alter systems over their lifetime. Field data provides new insights into real-world operating conditions. Monitoring can reveal deviations that did not occur during development.

For a platform like NX NextMotion, the verification structure must therefore be updatable. Findings from operation must be fed back into the safety case, and changes must be evaluated in a controlled manner. Safety-by-Wire® thus views the safety case as a living verification structure spanning the entire lifecycle—from initial requirements through development and validation to operation and updates.

Independent Review as Part of the Process

Another factor is the timing of the independent assessment. If an assessment takes place only at the end of a project, weaknesses can indeed be identified—but correcting them often involves considerable effort. With Safety-by-Wire®, therefore, the independent assessment accompanies the verification process throughout the development phases. The goal is to critically review architectural and verification decisions at a stage when they can still be efficiently adjusted.

This provides a pre-developed basis for verification in customer projects. It does not replace the safety case for the entire vehicle or the manufacturer’s responsibility for type approval and application—but it does create a foundation upon which project-specific safety arguments can be built.

What OEMs and Integrators Should Consider

When evaluating a safety-critical drive-by-wire platform, therefore, simply asking whether it meets ASIL D or features a fail-operational architecture is not sufficient. It is equally important to determine when the verification process begins, whether safety objectives are consistently traceable all the way to test results, and what quantitative analyses underpin the architecture. It should also be clarified which fault scenarios were actually injected into SiL, HiL, or ViL, how independent the assessment is, and how the safety case is updated after production begins.

After all, the quality of a safety architecture is demonstrated not only by what it can do technically, but also by how robustly this capability can be verified.

Conclusion: Safety is a verifiable property

The Safety Case completes the Safety-by-Wire® functional safety chain. The standards define the framework. The hazard analysis leads to safety objectives. The principle of the most stringent requirement consolidates these objectives across different vehicle domains. The Fully Fail-Operational architecture implements these objectives technically. And the Safety Case links requirements, architecture, analyses, and tests into a traceable chain of evidence.

For NX NextMotion, this chain begins before the first line of production code is written and extends beyond the start of production into ongoing operations. After all, safe control over steering, braking, and propulsion must not only be technically guaranteed—it must also remain verifiable.

WE CONTROL WHAT MOVES

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