In defense engineering in particular, it cannot be assumed in every operating condition that a driver will be immediately available as a fallback. For system development, it is therefore not sufficient to merely define a safe state. Already at the architectural level, it must be determined which functions will remain available under various failure scenarios, how long this state can be maintained, and what target state should subsequently be achieved. This makes operational availability an engineering task.

Availability Must Be Defined as a System Requirement

In traditional safety analyses, the primary focus is on ensuring that a failure does not lead to an uncontrolled vehicle state. For automated, teleoperated, or unmanned platforms, another question arises: What must continue to function after a failure?

There is no one-size-fits-all answer to this question. It depends on the function under consideration, the failure scenario, the remaining system integrity, and the intended operating state.

For developers, this results in three key factors:

• Scope of functions: Which safety-critical vehicle functions must remain available?
• Time: For how long must this state be maintained within the specified limits?
• Target state: Which defined system state should subsequently be achieved in a controlled manner?

Only the combination of these factors provides a technical description of what availability actually means after a failure.

Failover Does Not Automatically Mean Degradation

An important architectural consideration here is the distinction between failover and functional degradation. The loss of a redundant path does not necessarily mean that a safety-critical vehicle function is also lost. NX NextMotion is designed to be fully fail-operational for this purpose. Arnold NextG uses the term as a deliberately narrower working definition and not as a standalone normative safety class.

After any single failure under consideration, all safety-critical control functions remain fully available—within the specified failure rates, performance limits, and response times. The architecture detects and isolates the affected path and continues to execute the function using the remaining fault-free resources. Thus, the engineering question following a single failure is not automatically: “Which function do we need to shut down?”

Rather, the first step is to clarify: Which redundant resources remain available, and can the specified scope of functionality be fully maintained? Defined degradation strategies become relevant only in the event of more extensive failure scenarios.

Fault detection alone is not enough

Operational availability requires that a fault be reliably detected, evaluated, and assigned to a defined system state. In the underlying system concept, NX NextMotion detects critical faults in less than two milliseconds. Through plausibility checks and safety logic, the affected path is identified and, if necessary, deactivated. The switchover occurs deterministically and without any perceptible interruption in control.

For system development, however, the pure fault detection time is only one parameter. The subsequent reaction logic is decisive: Which function is continued via which path? What performance limits apply? When must a different system state be activated? And how long may or must this state remain available? This transforms fault detection into a defined availability strategy.

Different failure scenarios require different responses

A robust vehicle architecture should not treat fault conditions with a single, blanket response. The civilian system concept from NX NextMotion demonstrates how such strategies can be designed with nuance. In the event of a complete side failure while the path remains otherwise intact, the safety-critical control functions remain fully available within a defined limp-home window.

For the underlying civilian demonstrator context, this time window was set at 37 minutes. The design is based on a worst-case scenario in which the available buffer capacity must be sufficient to safely and controlledly traverse a section of road without a safe stopping point. In the event of combined multiple failures, however, a significantly tighter “limp-aside” concept takes effect. In the civil demonstrator, a two-minute time window was considered for this purpose. Steering and braking functions remain available via the intact path while the platform is guided in a controlled manner toward a stop.

The values of 37 and two minutes, respectively, are explicitly not defense specifications. They illustrate an engineering principle: Availability can be quantitatively described for defined failure scenarios in terms of functional scope, time window, and target state, rather than simply being asserted as a general system property. For a defense platform, corresponding objectives would need to be derived from the respective vehicle architecture, the operational model, and the application context.

Redundancy Is a Means to an End

This distinction is particularly relevant for companies that transfer expertise from the automotive, commercial vehicle, or off-highway sectors to defense applications. Redundancy alone does not define operational availability. A duplicate processing unit or a redundant communication path does not answer the question of which vehicle function will remain available—and with what level of performance—following a specific failure.

Operational availability arises only from the interaction of the entire safety-critical control path: processing, communication, sensors, actuators, and power supply must be considered together. Redundancy is therefore not an end in itself. It provides the resources upon which a defined fault tolerance and availability strategy can be built.

What OEMs and Tier 1 Suppliers Should Define Early On

For development programs, this means that availability should not be considered only during the validation phase. As early as the system architecture stage, failure scenarios, required residual functions, and permissible operating states must be linked together. This is particularly relevant for platforms whose level of automation is intended to change over the course of their lifecycle. A vehicle that was originally manned can later be equipped with teleoperation, supplemented with automated functions, or further developed for unmanned operating modes.

With each of these operating modes, the question of the fallback level also changes. An architecture that fundamentally relies on immediate handover to a driver cannot be readily transferred to an unmanned operating state. For OEMs and system integrators, it must therefore be clear early on which functions must remain available regardless of driver presence and what technical resources are required to ensure this.

Operational Availability as an Architectural Decision

NX NextMotion combines fault detection, fault tolerance, and defined response strategies within a common drive-by-wire control layer. The platform evaluates control requests and executes them via steering, braking, propulsion, and relevant secondary functions. Even under defined fault conditions, it thus remains clear which control functions are available and what the intended system state is. Operational Availability explicitly does not mean that a platform continues to operate indefinitely despite any faults. It means that for defined fault scenarios, it can be technically described and verified: What remains available? For how long? And with what target state?

This is a central architectural issue, particularly for defense engineering, because automated, teleoperated, and unmanned modes of operation are increasingly undermining the traditional assumption of a driver being available at all times as a fallback.

The Next System Boundary

A defined availability strategy makes it possible to determine which vehicle functions can continue to be executed after failures. However, another question must be addressed first: Is a requested movement even executable in this form under the current conditions of the real-world platform? This shifts the focus from the availability of the vehicle control system to the evaluation of the movement request itself.

WE CONTROL WHAT MOVES

more information: www.arnoldnextg.com/blog

Sources and Technical Classification

ATZheavy duty 02/2026, Technical Article
„Drive-by-Wire Platform for Integrating Different Control Sources “
(Insert link to the ATZ article https://www.arnoldnextg.com/storage/assets/Content-Main_Navigation/Unternehmen/Presse/Presse_ATZ/Sonderdruck_Arnold_NextG_ATZhd_englisch_KORR2.pdf)

In this context, the term “fully fail-operational” refers to a working definition by Arnold NextG and not to a standalone normative safety class. The mentioned time windows of 37 and two minutes originate from the civilian development and demonstration context of NX NextMotion and do not constitute a defense specification.

Gerade im Defence Engineering kann nicht in jedem Betriebszustand vorausgesetzt werden, dass ein Fahrer unmittelbar als Rückfallebene zur Verfügung steht. Für die Systementwicklung reicht es deshalb nicht, lediglich einen sicheren Zustand zu definieren. Bereits auf Architekturebene muss festgelegt werden, welche Funktionen nach unterschiedlichen Fehlerbildern weiterhin zur Verfügung stehen, wie lange dieser Zustand aufrechterhalten werden kann und welcher Zielzustand anschließend erreicht werden soll. Damit wird Operational Availability zur Engineering-Aufgabe.

Verfügbarkeit muss als Systemanforderung definiert werden

Bei klassischen Safety-Betrachtungen steht zunächst im Vordergrund, dass ein Fehler nicht zu einem unkontrollierten Fahrzeugzustand führt. Für automatisierte, teleoperierte oder unbemannte Plattformen kommt eine weitere Frage hinzu: Was muss nach einem Fehler weiterhin funktionieren?

Diese Frage lässt sich nicht pauschal beantworten. Sie hängt von der betrachteten Funktion, dem Fehlerbild, der verbleibenden Systemintegrität und dem vorgesehenen Betriebszustand ab.

Für Entwickler ergeben sich daraus drei zentrale Größen:

• Funktionsumfang: Welche sicherheitsrelevanten Fahrzeugfunktionen müssen weiterhin verfügbar sein?
• Zeit: Für welchen Zeitraum muss dieser Zustand innerhalb der spezifizierten Grenzen aufrechterhalten werden?
• Zielzustand: Welcher definierte Systemzustand soll anschließend kontrolliert erreicht werden?

Erst die Kombination dieser Größen beschreibt technisch, was Verfügbarkeit nach einem Fehler tatsächlich bedeutet.

Failover ist nicht automatisch Degradation

Ein wichtiger Architekturpunkt ist dabei die Trennung zwischen Failover und Funktionsdegradation. Der Verlust eines redundanten Pfads bedeutet nicht zwangsläufig, dass auch eine sicherheitsrelevante Fahrzeugfunktion verloren geht. NX NextMotion ist dafür fully fail-operational ausgelegt. Arnold NextG verwendet den Begriff als bewusst engere Arbeitsdefinition und nicht als eigenständige normative Sicherheitsklasse.

Nach jedem zu betrachtenden Einzelfehler bleiben alle sicherheitsrelevanten Steuerfunktionen uneingeschränkt verfügbar – innerhalb der spezifizierten Ausfallraten, Leistungsgrenzen und Reaktionszeiten. Die Architektur erkennt und isoliert den betroffenen Pfad und führt die Funktion über verbleibende fehlerfreie Ressourcen weiter. Damit lautet die Engineering-Frage nach einem Einzelfehler nicht automatisch: Welche Funktion müssen wir abschalten?

Zunächst muss vielmehr geklärt werden: Welche redundanten Ressourcen stehen weiterhin zur Verfügung und kann der spezifizierte Funktionsumfang vollständig erhalten bleiben? Erst bei weitergehenden Fehlerbildern werden definierte Degradationsstrategien relevant.

Fehlererkennung allein reicht nicht

Operational Availability setzt voraus, dass ein Fehler zuverlässig erkannt, bewertet und einem definierten Systemzustand zugeordnet wird. Im zugrunde liegenden Systemkonzept erkennt NX NextMotion kritische Fehler in weniger als zwei Millisekunden. Über Plausibilitätsprüfungen und Safety-Logik wird der betroffene Pfad identifiziert und gegebenenfalls deaktiviert. Die Umschaltung erfolgt deterministisch und ohne wahrnehmbare Unterbrechung der Kontrolle.

Für die Systementwicklung ist die reine Fehlererkennungszeit jedoch nur ein Parameter. Entscheidend ist die daran anschließende Reaktionslogik: Welche Funktion wird über welchen Pfad weitergeführt? Welche Leistungsgrenzen gelten? Wann muss ein anderer Systemzustand aktiviert werden? Und wie lange darf beziehungsweise muss dieser Zustand verfügbar bleiben? Damit wird aus Fehlererkennung eine definierte Verfügbarkeitsstrategie.

Unterschiedliche Fehlerbilder benötigen unterschiedliche Reaktionen

Eine robuste Fahrzeugarchitektur sollte Fehlerzustände nicht mit einer einzigen pauschalen Reaktion behandeln. Wie differenziert solche Strategien ausgelegt werden können, zeigt das zivile Systemkonzept von NX NextMotion. Bei Ausfall einer kompletten Seite bei ansonsten intaktem Pfad bleiben die sicherheitsrelevanten Steuerfunktionen innerhalb eines definierten Limp-Home-Fensters vollständig verfügbar.

Für den zugrunde liegenden zivilen Demonstratorkontext wurde dieses Zeitfenster auf 37 Minuten ausgelegt. Die Auslegung basiert auf einem Worst-Case-Szenario, in dem die vorhandene Pufferkapazität ausreichen muss, um einen Streckenabschnitt ohne sichere Haltemöglichkeit kontrolliert zu passieren. Bei kombinierten Mehrfachfehlern greift dagegen ein deutlich engeres Limp-Aside-Konzept. Im zivilen Demonstrator wurde hierfür ein Zeitfenster von zwei Minuten betrachtet. Lenk- und Bremsfunktion bleiben über den intakten Pfad verfügbar, während die Plattform kontrolliert in Richtung Stillstand geführt wird.

Die Werte von 37 beziehungsweise zwei Minuten sind ausdrücklich keine Defence-Spezifikation. Sie veranschaulichen ein Engineering-Prinzip: Verfügbarkeit lässt sich für definierte Fehlerbilder über Funktionsumfang, Zeitfenster und Zielzustand quantitativ beschreiben, anstatt sie lediglich als allgemeine Systemeigenschaft zu behaupten. Für eine Defence-Plattform müssten entsprechende Ziele aus der jeweiligen Fahrzeugarchitektur, dem Betriebsmodell und dem Anwendungskontext abgeleitet werden.

Redundanz ist Mittel zum Zweck

Gerade für Unternehmen, die Kompetenzen aus Automotive, Commercial Vehicle oder Off-Highway in Defence-Anwendungen übertragen, ist diese Unterscheidung relevant. Redundanz allein beschreibt noch keine Operational Availability. Eine doppelte Recheneinheit oder ein redundanter Kommunikationspfad beantwortet noch nicht, welche Fahrzeugfunktion nach einem konkreten Fehler weiterhin mit welcher Leistungsfähigkeit zur Verfügung steht.

Operational Availability entsteht erst aus dem Zusammenspiel des gesamten sicherheitsrelevanten Steuerungspfads: Verarbeitung, Kommunikation, Sensorik, Aktuatorik und Energieversorgung müssen gemeinsam betrachtet werden. Redundanz ist damit kein Selbstzweck. Sie stellt die Ressourcen bereit, auf denen eine definierte Fehlertoleranz- und Verfügbarkeitsstrategie aufbauen kann.

Was OEMs und Tier 1 früh festlegen sollten

Für Entwicklungsprogramme bedeutet das, Verfügbarkeit nicht erst in der Validierungsphase zu betrachten. Bereits bei der Systemarchitektur müssen Fehlerbilder, benötigte Restfunktionen und zulässige Betriebszustände miteinander verknüpft werden. Besonders relevant ist dies bei Plattformen, deren Automatisierungsgrad über den Lebenszyklus verändert werden soll. Ein ursprünglich bemanntes Fahrzeug kann später Teleoperation erhalten, um automatisierte Funktionen ergänzt oder für unbemannte Betriebsarten weiterentwickelt werden.

Mit jeder dieser Betriebsarten verändert sich auch die Frage nach der Rückfallebene. Eine Architektur, die grundsätzlich auf die unmittelbare Übergabe an einen Fahrer angewiesen ist, lässt sich nicht ohne Weiteres auf einen unbemannten Betriebszustand übertragen. Für OEMs und Systemintegratoren muss daher früh nachvollziehbar sein, welche Funktionen unabhängig von Fahrerpräsenz erhalten bleiben müssen und welche technischen Ressourcen dafür erforderlich sind.

Operational Availability als Architekturentscheidung

NX NextMotion verbindet Fehlererkennung, Fehlertoleranz und definierte Reaktionsstrategien innerhalb einer gemeinsamen Drive-by-Wire Control Layer. Die Plattform prüft Steueranforderungen und übernimmt deren Ausführung über Lenkung, Bremse, Antrieb und relevante Sekundärfunktionen. Auch unter definierten Fehlerzuständen bleibt damit nachvollziehbar, welche Steuerfunktionen verfügbar sind und welcher Systemzustand vorgesehen ist. Operational Availability bedeutet dabei ausdrücklich nicht, dass eine Plattform trotz beliebiger Fehler unbegrenzt weiterarbeitet. Sie bedeutet, dass für definierte Fehlerbilder technisch beschrieben und nachgewiesen werden kann: Was bleibt verfügbar? Für wie lange? Und mit welchem Zielzustand?

Gerade für Defence Engineering ist das eine zentrale Architekturfrage, weil automatisierte, teleoperierte und unbemannte Betriebsarten die klassische Annahme eines jederzeit verfügbaren Fahrers als Rückfallebene zunehmend auflösen.

Die nächste Systemgrenze

Mit einer definierten Verfügbarkeitsstrategie lässt sich festlegen, welche Fahrzeugfunktionen nach Fehlern weiterhin ausgeführt werden können. Eine andere Frage liegt jedoch noch davor: Ist eine angeforderte Bewegung unter den aktuellen Bedingungen der realen Plattform überhaupt in dieser Form ausführbar? Damit verschiebt sich der Blick von der Verfügbarkeit der Fahrzeugsteuerung auf die Bewertung der Bewegungsanforderung selbst.

WE CONTROL WHAT MOVES

 weitere Informationen: www.arnoldnextg.de/blog

Quellen und technische Einordnung

ATZheavy duty 02/2026, Fachartikel
„Drive-by-Wire-Plattform zur Integration verschiedener Steuerquellen“
https://www.arnoldnextg.de/storage/assets/Content-Main_Navigation/Unternehmen/Presse/Presse_ATZ/Sonderdruck_Arnold_NextG_ATZhd_deutsch_KORR2.pdf   einfügen)

Der Begriff fully fail-operational bezeichnet in diesem Kontext eine Arbeitsdefinition von Arnold NextG und keine eigenständige normative Sicherheitsklasse. Die genannten Zeitfenster von 37 und zwei Minuten stammen aus dem zivilen Entwicklungs- und Demonstratorkontext von NX NextMotion und stellen keine Defence-Spezifikation dar.

Control rights become part of the E/E architecture

In traditional vehicle architectures, the assignment is often unambiguous: the driver operates the steering wheel and pedals, and the vehicle functions respond accordingly. With increasing automation and external control sources, this assignment becomes dynamic. For example, an automated driving system may request steering, braking, and propulsion. At the same time, a remote operator may need access to the same functions. Furthermore, the driver inside the vehicle may still remain part of the architecture.

For developers, this creates an additional system level: control authority must be technically implemented. The NX NextMotion drive-by-wire platform developed by Arnold NextG includes an arbitration layer for this purpose between the various control sources and the vehicle’s actual motion functions. It continuously checks requests for plausibility and consistency and correlates them with system state, availability, and temporal behavior. The system thus makes decisions not merely based on a static priority list, but within a defined state model.

A mode change is a change in the control path

From an engineering perspective, the transition between control sources is particularly relevant. A switch from automated operation to teleoperation, or from the remote operator back to the driver, is not merely a change of operating mode within a user interface. It alters the active control path for safety-critical vehicle functions.

In this context, at least three questions must be clearly answered:

• Which source relinquishes control authority?
• Which source assumes control?
• How are control requests handled during the transition?

In the NX-NextMotion system concept, such transitions are therefore treated as defined system states. Non-deterministic state transitions are excluded. For the transitions described, the underlying system concept achieves error response times of less than five milliseconds. Each transition is itself considered a safety-critical function.

For OEMs and integrators, this is an important distinction: The safe integration of multiple control sources is not merely a matter of interfaces. The handover logic itself is also part of the safety concept.

Control authority does not have to change simultaneously for the entire vehicle

Another challenge arises from the fact that vehicle states are not always clearly “manual” or “automated.” Mixed operating states can be an explicit part of a vehicle architecture. For example, the ATZ technical article on NX NextMotion describes a state in which the driver intervenes in steering while the automated driving system continues to control the braking function. Technically, this creates so-called virtual target channels within the arbitration architecture.  This highlights a crucial engineering requirement:

Control authority must be considered on a function-by-function basis.

Steering, braking, and propulsion do not necessarily have to be controlled simultaneously by the same control source. For the architecture, this means that control rights must be clearly defined not only per operating mode but also depending on function and system state. This capability is particularly relevant for manned-unmanned teaming, assisted operating modes, or progressively automated platforms. As a result, a vehicle can switch between different levels of automation without requiring completely separate control architectures.

Why Static Priorities Alone Are Not Sufficient

A simple hierarchy based on the principle “driver takes priority over teleoperation, teleoperation over autonomy” only partially reflects this reality. This is because the permissibility of a control request does not depend exclusively on its source. Among other factors, the following are relevant:

·       System state: Is the relevant operating mode currently permitted?

·       Availability: Is the associated control path functional?

·       Plausibility: Is the requested function consistent with the current state?

·       Timing: Does the request—and, if applicable, the transition—occur within the specified time frame?

NX NextMotion integrates this information within the arbitration process. As a result, control rights and transitions are handled deterministically. This unambiguity is crucial for safety-oriented development: At any given moment, it must be possible to trace which source is affecting which function.

What OEMs and Tier 1 Suppliers Should Define Early On for Defense Platforms

For companies that are applying their existing automotive or commercial vehicle expertise to defense applications, this creates an additional layer of system development. The question is not merely which interface an AD stack or remote control system requires.

Rather, the following must be clarified early on:

·        Which control sources should the platform support throughout its lifecycle?

·         Which vehicle functions may be requested by which source?

·         What priorities and handover conditions apply to each function?

·         What mixed states are permitted?

·         How are conflicts between requirements detected?

·         Which states and transitions must be considered in the safety case?

·         How is it ensured that additions of new control sources do not alter the existing architecture in an uncontrolled manner?

This shifts the focus of integration from mere signal transmission to the definition and control of control authority.

A common control layer instead of parallel control systems

For manufacturers and system integrators, this represents a significant architectural advantage. Manned, teleoperated, and automated operating modes do not necessarily have to be implemented as separate vehicle control systems. They can be based on a common drive-by-wire control layer that coordinates their requirements. This is particularly relevant for platforms whose functional scope is intended to be further developed over their lifecycle.

A platform that was originally manned can later be equipped with teleoperation. Automated functions can be added incrementally. Unmanned operation can be incorporated for specific applications. If control arbitration is already an integral part of the underlying vehicle architecture, the fundamental logic of motion control does not have to be rebuilt with every new operating mode.

Defense as a Particularly Challenging Integration Case

In defense engineering, many of these requirements converge. Platforms can be operated over long periods and modernized multiple times. Different levels of automation can exist in parallel. Depending on the mission concept, drivers, remote operators, and automated systems may all be relevant within the same vehicle architecture. This makes the separation between the control source and the vehicle function particularly important.

The question is not: Who controls the vehicle?
But rather: Which source is authorized to control which function in this state?

NX NextMotion maps this assignment within a common control layer. For companies diversifying into defense applications from traditional automotive and commercial vehicle segments, this represents a significant shift in perspective: Existing expertise in E/E architecture, functional safety, actuator technology, and system integration remains relevant—but it must be expanded to include the controlled integration of multiple control sources.

The Limits of Arbitration

Control arbitration answers a clearly defined architectural question: Who has control authority for a specific function? It does not automatically answer whether every formally valid and unambiguously assigned motion request can actually be executed in a controlled manner under the real physical and technical conditions of a platform. A requested motion always encounters a real vehicle—with a specific vehicle state and specific boundary conditions.

At this system boundary, another development task begins. For the arbitration architecture, it is first and foremost crucial that a clear prerequisite has been established beforehand: It must be defined at all times which source is permitted to control which motion function.

From Access to Vehicle Functions to Controlled Control Authority

Drive-by-wire makes vehicle functions electronically accessible. However, only a defined arbitration architecture makes this access technically manageable when multiple control sources are involved. For modern defense platforms, this means: It is not the number of possible control sources that determines a platform’s integration capability.

What matters is whether its architecture can assign control rights on a function-by-function basis, handle conflicts deterministically, and execute transitions in a controlled manner. NX NextMotion forms the drive-by-wire control layer of Arnold NextG for this purpose.

WE CONTROL WHAT MOVES

 more information: www.arnoldnextg.com

Sources and Technical Classification

ATZheavy duty 02/2026 – “Three Control Sources, One Architecture – A Fail-Operational Drive-by-Wire Platform for Integrated Control of Autonomy, Teleoperation, and Driver Intervention.” Technical foundation for control source integration, arbitration, transitions, virtual setpoint channels, and failover behavior.

ISO 26262 – Functional Safety of Electrical and Electronic Systems in Road Vehicles; relevant as the development framework for NX NextMotion. The specific assessment of a defense application depends on the function, target platform, and application context.

Steuerrechte werden Teil der E/E-Architektur

In klassischen Fahrzeugarchitekturen ist die Zuordnung häufig eindeutig: Der Fahrer betätigt Lenkrad und Pedale, die Fahrzeugfunktionen reagieren entsprechend. Mit zunehmender Automatisierung und externen Steuerquellen wird diese Zuordnung dynamisch. Ein automatisiertes Fahrsystem kann beispielsweise Lenkung, Bremse und Antrieb anfordern. Gleichzeitig kann ein Remote Operator Zugriff auf dieselben Funktionen benötigen. Darüber hinaus kann der Fahrer im Fahrzeug weiterhin Teil der Architektur bleiben.

Für Entwickler entsteht daraus eine zusätzliche Systemebene: Control Authority muss technisch abgebildet werden. Die von Arnold NextG entwickelte Drive-by-Wire-Plattform NX NextMotion enthält dafür eine Arbitrierungsschicht zwischen den verschiedenen Steuerquellen und den realen Bewegungsfunktionen des Fahrzeugs. Sie prüft Anforderungen kontinuierlich hinsichtlich Plausibilität und Konsistenz und setzt sie in Beziehung zu Systemzustand, Verfügbarkeit und Zeitverhalten. Das System entscheidet damit nicht lediglich nach einer statischen Prioritätenliste, sondern innerhalb eines definierten Zustandsmodells.

Ein Moduswechsel ist ein Wechsel des Steuerungspfads

Aus Engineering-Sicht ist insbesondere der Übergang zwischen Steuerquellen relevant. Ein Wechsel von automatisiertem Betrieb zu Teleoperation oder vom Remote Operator zurück zum Fahrer ist nicht lediglich ein Wechsel eines Betriebsmodus in einer Benutzeroberfläche. Er verändert den aktiven Steuerungspfad für sicherheitsrelevante Fahrzeugfunktionen.

Dabei müssen mindestens drei Fragen eindeutig beantwortet sein:

• Welche Quelle gibt das Steuerrecht ab?
• Welche Quelle übernimmt es?
• Wie werden Steueranforderungen während des Übergangs behandelt?

Im NX-NextMotion-Systemkonzept werden solche Wechsel deshalb als definierte Systemzustände behandelt. Nichtdeterministische Zustandswechsel werden ausgeschlossen. Für die beschriebenen Übergänge weist das zugrunde liegende Systemkonzept Fehlerreaktionszeiten von unter fünf Millisekunden aus. Jeder Übergang wird dabei selbst als sicherheitsrelevante Funktion betrachtet.

Für OEMs und Integratoren ist das ein wichtiger Unterschied: Die sichere Integration mehrerer Steuerquellen ist nicht allein eine Schnittstellenfrage. Auch die Übergabelogik selbst gehört zum Safety-Konzept.

Steuerrechte müssen nicht für das gesamte Fahrzeug gleichzeitig wechseln

Eine weitere Herausforderung entsteht dadurch, dass Fahrzeugzustände nicht immer eindeutig „manuell“ oder „automatisiert“ sind. Gemischte Betriebszustände können ausdrücklich Teil einer Fahrzeugarchitektur sein. Der ATZ-Fachbeitrag zu NX NextMotion beschreibt beispielsweise einen Zustand, in dem der Fahrer in die Lenkung eingreift, während das automatisierte Fahrsystem weiterhin die Bremsfunktion regelt. Technisch entstehen dadurch sogenannte virtuelle Sollkanäle innerhalb der Arbitrierungsarchitektur.  Damit wird eine entscheidende Engineering-Anforderung sichtbar:

Control Authority muss funktionsbezogen betrachtet werden.

Lenkung, Bremse und Antrieb müssen nicht zwangsläufig gleichzeitig von derselben Steuerquelle geführt werden. Für die Architektur bedeutet das, dass Steuerrechte nicht nur pro Betriebsmodus, sondern abhängig von Funktion und Systemzustand eindeutig beschrieben werden müssen. Gerade für Manned-Unmanned Teaming, assistierte Betriebsarten oder schrittweise automatisierte Plattformen ist diese Fähigkeit relevant. Ein Fahrzeug kann dadurch zwischen unterschiedlichen Automatisierungsgraden wechseln, ohne dass dafür vollständig getrennte Steuerungsarchitekturen notwendig werden.

Warum statische Prioritäten allein nicht ausreichen

Eine einfache Hierarchie nach dem Prinzip „Fahrer hat Priorität vor Teleoperation, Teleoperation vor Autonomie“ bildet diese Realität nur unvollständig ab. Denn die Zulässigkeit einer Steueranforderung hängt nicht ausschließlich von ihrer Quelle ab. Relevant sind unter anderem:

·       Systemzustand: Ist die betreffende Betriebsart aktuell zulässig?

·       Verfügbarkeit: Ist der zugehörige Steuerungspfad funktionsfähig?

·       Plausibilität: Ist die angeforderte Funktion mit dem aktuellen Zustand konsistent?

·       Zeitverhalten: Erfolgt die Anforderung und gegebenenfalls der Übergang innerhalb des spezifizierten Zeitrahmens?

NX NextMotion verknüpft diese Informationen innerhalb der Arbitrierung. Dadurch werden Steuerrechte und Übergänge deterministisch behandelt. Für eine Safety-orientierte Entwicklung ist diese Eindeutigkeit entscheidend: Zu jedem Zeitpunkt muss nachvollziehbar sein, welche Quelle auf welche Funktion wirkt.

Was OEMs und Tier 1 bei Defence-Plattformen früh definieren sollten

Für Unternehmen, die bestehende Automotive- oder Nutzfahrzeugkompetenz auf Defence-Anwendungen übertragen, entsteht damit eine zusätzliche Ebene der Systementwicklung. Die Frage lautet nicht nur, welche Schnittstelle ein AD-Stack oder Remote-Control-System benötigt.

Frühzeitig geklärt werden muss vielmehr:

·        Welche Steuerquellen soll die Plattform während ihres Lebenszyklus unterstützen?

·         Welche Fahrzeugfunktionen dürfen von welcher Quelle angefordert werden?

·         Welche Prioritäten und Übergabebedingungen gelten pro Funktion?

·         Welche gemischten Zustände sind zulässig?

·         Wie werden Konflikte zwischen Anforderungen erkannt?

·         Welche Zustände und Übergänge müssen im Safety Case betrachtet werden?

·         Wie wird sichergestellt, dass Erweiterungen um neue Steuerquellen die bestehende Architektur nicht unkontrolliert verändern?

Damit verschiebt sich die Integrationsfrage von der reinen Signalübertragung zur Definition und Beherrschung von Control Authority.

Eine gemeinsame Control Layer statt paralleler Steuerungssysteme

Für Hersteller und Systemintegratoren liegt darin ein wesentlicher Architekturvorteil. Bemannte, teleoperierte und automatisierte Betriebsarten müssen nicht zwangsläufig als voneinander getrennte Fahrzeugsteuerungen realisiert werden. Sie können auf einer gemeinsamen Drive-by-Wire Control Layer aufsetzen, die ihre Anforderungen koordiniert. Das ist insbesondere für Plattformen relevant, deren Funktionsumfang während ihres Lebenszyklus weiterentwickelt werden soll.

Eine ursprünglich bemannte Plattform kann später Teleoperation erhalten. Automatisierte Funktionen können schrittweise ergänzt werden. Für einzelne Anwendungen kann unbemannter Betrieb hinzukommen. Wenn Control Arbitration bereits Bestandteil der darunterliegenden Fahrzeugarchitektur ist, muss nicht mit jeder neuen Betriebsart auch die grundlegende Logik der Bewegungssteuerung neu aufgebaut werden.

Defence als besonders anspruchsvoller Integrationsfall

Im Defence Engineering verdichten sich viele dieser Anforderungen. Plattformen können über lange Zeiträume betrieben und mehrfach modernisiert werden. Unterschiedliche Automatisierungsgrade können parallel existieren. Je nach Einsatzkonzept können Fahrer, Remote Operator und automatisierte Systeme innerhalb derselben Fahrzeugarchitektur relevant sein. Damit wird die Trennung zwischen Steuerquelle und Fahrzeugfunktion besonders wichtig.

Die Frage lautet nicht: Wer steuert das Fahrzeug?
Sondern: Welche Quelle darf in diesem Zustand welche Funktion führen?

NX NextMotion bildet diese Zuordnung innerhalb einer gemeinsamen Control Layer ab. Für Unternehmen, die sich aus klassischen Automotive- und Nutzfahrzeugsegmenten in Defence-Anwendungen diversifizieren, ist das ein wesentlicher Perspektivwechsel: Bestehende Kompetenz in E/E-Architektur, Functional Safety, Aktuatorik und Systemintegration bleibt relevant – sie muss jedoch um die kontrollierte Integration mehrerer Steuerquellen erweitert werden.

Die Grenze der Arbitrierung

Control Arbitration beantwortet dabei eine klar umrissene Architekturfrage: Wer besitzt für eine bestimmte Funktion das Steuerrecht? Sie beantwortet nicht automatisch, ob jede formal gültige und eindeutig zugeordnete Bewegungsanforderung unter den realen physikalischen und technischen Bedingungen einer Plattform tatsächlich kontrolliert ausführbar ist. Eine angeforderte Bewegung trifft immer auf ein reales Fahrzeug – mit konkretem Fahrzeugzustand und konkreten Randbedingungen.

An dieser Systemgrenze beginnt eine weitere Entwicklungsaufgabe. Für die Arbitrierungsarchitektur ist zunächst entscheidend, dass davor eine eindeutige Voraussetzung geschaffen wurde: Es muss jederzeit definiert sein, welche Quelle welche Bewegungsfunktion führen darf.

Vom Zugang zur Fahrzeugfunktion zur kontrollierten Control Authority

Drive-by-Wire macht Fahrzeugfunktionen elektronisch zugänglich. Erst eine definierte Arbitrierungsarchitektur macht diesen Zugang jedoch bei mehreren Steuerquellen technisch beherrschbar. Für moderne Defence-Plattformen bedeutet das: Nicht die Anzahl möglicher Steuerquellen bestimmt die Integrationsfähigkeit einer Plattform.

Entscheidend ist, ob ihre Architektur Steuerrechte funktionsbezogen vergeben, Konflikte deterministisch behandeln und Übergänge kontrolliert ausführen kann. NX NextMotion bildet dafür die Drive-by-Wire Control Layer von Arnold NextG.

WE CONTROL WHAT MOVES

Mehr Informationen: www.arnoldnextg.de

Quellen und technische Einordnung

ATZheavy duty 02/2026 – „Drei Steuerquellen, eine Architektur – Eine fail-operational Drive-by-Wire-Plattform zur integrierten Steuerung für Autonomie, Teleoperation und Fahrereingriff“. Technische Grundlage zu Steuerquellenintegration, Arbitrierung, Übergängen, virtuellen Sollkanälen und Failover-Verhalten.

ISO 26262 – funktionale Sicherheit elektrischer und elektronischer Systeme in Straßenfahrzeugen; relevant als Entwicklungsrahmen von NX NextMotion. Die konkrete Bewertung einer Defence-Anwendung bleibt abhängig von Funktion, Zielplattform und Anwendungskontext.

The crucial question is rather: Which parts of a safety-critical control architecture can be reused—and which must be specifically designed and validated for each target platform?

Scaling Begins at the Right System Boundary

A wheeled vehicle, a tracked platform, a heavy-duty commercial vehicle, or an electrified specialty platform differ not only in dimensions and drive concepts. The vehicle electrical system, vehicle communication, actuators, installation conditions, and dynamic characteristics can be fundamentally different. Therefore, equating scalability with plug-and-play is an oversimplification. Platform scaling only makes technical sense when reusable system functions and vehicle-specific integration are clearly separated from one another.

With NX NextMotion, Arnold NextG is pursuing precisely this approach. The drive-by-wire platform forms a control layer between the requesting systems and the vehicle’s actual motion functions. On one side are control requests—for example, from the driver, teleoperation, or automated driving systems. On the other side, steering, braking, and propulsion are connected to the specific target platform. This creates a clear architectural boundary: the fundamental control and safety logic can be designed to be reusable; its physical and communication interfaces remain platform-specific.

What Remains Reusable Across Platform Boundaries

For OEMs and integrators, the relevant scaling effect does not lie in installing the same hardware configuration unchanged in different vehicles.

Rather, what is reusable are core architectural principles and functions such as:

• deterministic real-time processing,
• plausibility checking of control requests,
• diagnostics and fault detection,
• defined error responses,
• safety-critical control logic.

NX NextMotion provides a common architectural foundation for this. As a result, core mechanisms of electronic vehicle control do not have to be completely redeveloped for each new target platform. This separation is essential for development organizations: it shifts the focus from the repetitive development of fundamental safety and control mechanisms to the targeted integration of the specific platform.

What Must Remain Platform-Specific

The reusability of the control core does not eliminate vehicle-specific development work. Different platforms require different interfaces to actuators, communication, and power supply. Actuator characteristics, vehicle parameters, installation configurations, and specific parameter settings also differ.

The integration can utilize existing vehicle networks and communication interfaces. Which technologies are used and how individual functions are integrated depends on the respective target platform, its E/E architecture, and the specific function, and must be designed and validated accordingly. A scalable architecture must be able to accommodate differences without requiring the entire safety-critical control core to be redeveloped for every vehicle.

Fully Fail-Operational as an Architectural Principle

This separation becomes particularly relevant when vehicle control must remain not only scalable but also controllable in the event of faults. For this expanded fault-tolerance approach, Arnold NextG uses the term fully fail-operational for NX NextMotion. It describes the technical design of the architecture and does not constitute a standalone normative safety class.

The approach considers four completeness axes simultaneously: function, channel, control source, and energy path. After any single fault under consideration, the platform continues to perform all safety-critical control functions without restriction—within the specified failure rates, performance limits, and response times. For teleoperation and autonomous driving functions, the control source axis is particularly relevant: the architecture does not rely on the driver as a fallback.

Thus, fault tolerance is not reduced to the redundancy of a single control unit. It becomes a property of the entire chain of control requests, processing, communication, actuators, and power supply.

Domain neutrality does not mean blanket certification

For OEMs and development service providers, another point is crucial: A reusable architecture can be relevant for different application domains without necessarily being certified for every domain. NX NextMotion was developed in accordance with ISO 26262 for applications in public road traffic. Furthermore, the “fully fail-operational” property was analyzed against functional safety requirements of adjacent domains – including ISO 25119 for agricultural and forestry machinery, ISO 13849-1 for machinery, and IEC 61508 as a generic framework for safety-related E/E/PE systems.

ISO 26262 addresses the functional safety of safety-critical E/E systems in mass-produced road vehicles. ISO 13849-1 describes requirements and methods for safety-related parts of machine control systems; ISO 25119 addresses corresponding control systems in agricultural and forestry machinery.

For a specific defense, automotive, or off-highway application, the evaluation therefore always depends on the target platform, function, scope of integration, and operational context. Domain neutrality does not, therefore, mean standardizing normative requirements. It means that fundamental architectural and safety principles are designed in such a way that they can be reused across different applications and evaluated against the relevant requirements in each case.

What OEMs, Tier 1 suppliers, and integrators should clarify early on

This raises five key questions for the development of a scalable drive-by-wire architecture:

• Control Core: Which control, diagnostic, and fault response functions should remain unchanged across multiple platforms?
• Interfaces: Which vehicle-specific communication and actuator paths must be developed for each target platform?
• Parameterization: Which characteristics and system parameters depend directly on the specific vehicle?
• Safety Case: What safety requirements apply to the function, platform, and application domain—and what evidence must be documented on a project-specific basis?
• Validation: Which parts of an existing architecture can be carried over, and which must be re-verified and validated on the respective target platform?

These questions are not limited to the defense sector. Traditional OEM programs, commercial vehicles, off-highway machinery, and new software-defined vehicle concepts also face the same fundamental decision: How can technological reuse be increased without losing necessary vehicle-specific features?

Defense intensifies the demands on platform scalability

This challenge is particularly evident in the defense sector. Different platform generations, wheeled and tracked vehicles, various propulsion systems, and different operational concepts can coexist within a single fleet. At the same time, new requirements are emerging due to teleoperation, automated driving functions, and unmanned applications.

The architecture must therefore reconcile two seemingly contradictory requirements: standardization where it makes technical sense—and specialization where it remains necessary for the specific platform. For OEMs and integrators, this results in a different perspective on drive-by-wire. What matters is not only whether steering, braking, and propulsion can be controlled electronically. What matters is whether the underlying control layer can be consistently further developed across different vehicle programs.

From Individual Projects to a Reusable Integration Architecture

A scalable drive-by-wire platform does not replace platform-specific development. However, it changes where that development begins. Instead of rebuilding fundamental control, diagnostic, and safety mechanisms from scratch for each platform, development work can build upon an existing architectural foundation and focus on the specific vehicle integration, parameterization, and validation.

NX NextMotion thus pursues a platform approach in which it is not the vehicle that is standardized, but rather the control layer for vehicle motion. The key difference is this:

Scalability does not result from treating every platform the same. It results from clearly defining what can remain the same—and what must remain specific.

WE CONTROL WHAT MOVES

more information: www.arnoldnextg.com

Sources and Technical Context

• ATZheavy duty 02/2026 – “Drive-by-Wire Platform for Integrating Various Control Sources” – technical background on NX NextMotion, the integration of different control sources, and the fully fail-operational architectural approach.
• ISO 26262 – Road vehicles – Functional safety
• ISO 25119 – Tractors and machinery for agriculture and forestry – Safety-related parts of control systems
• ISO 13849-1 – Safety of machinery – Safety-related parts of control systems
• IEC 61508-1:2010 – Functional Safety of Electrical, Electronic, and Programmable Electronic Safety-Related Systems – Part 1: General Requirements

Die entscheidende Frage lautet vielmehr: Welche Teile einer sicherheitsgerichteten Steuerungsarchitektur können wiederverwendet werden – und welche müssen für jede Zielplattform spezifisch ausgelegt und validiert werden?

Skalierung beginnt an der richtigen Systemgrenze

Ein Radfahrzeug, eine Kettenplattform, ein schweres Nutzfahrzeug oder eine elektrifizierte Sonderplattform unterscheiden sich nicht nur in Abmessungen und Antriebskonzept. Bordnetz, Fahrzeugkommunikation, Aktuatorik, Einbauverhältnisse und dynamische Eigenschaften können grundlegend verschieden sein. Wer Skalierbarkeit deshalb mit Plug-and-play gleichsetzt, greift zu kurz. Technisch sinnvoll wird Plattformskalierung erst, wenn wiederverwendbare Systemfunktionen und fahrzeugspezifische Integration sauber voneinander getrennt werden.

Mit NX NextMotion verfolgt Arnold NextG genau diesen Ansatz. Die Drive-by-Wire-Plattform bildet eine Control Layer zwischen den anfordernden Systemen und den realen Bewegungsfunktionen des Fahrzeugs. Auf der einen Seite stehen Steueranforderungen – beispielsweise von Fahrer, Teleoperation oder automatisierten Fahrsystemen. Auf der anderen Seite werden Lenkung, Bremse und Antrieb an die konkrete Zielplattform angebunden. Damit entsteht eine klare Architekturgrenze: Die grundlegende Steuerungs- und Sicherheitslogik kann wiederverwendbar ausgelegt werden; ihre physische und kommunikative Anbindung bleibt plattformspezifisch.

Was über Plattformgrenzen hinweg wiederverwendbar bleibt

Für OEMs und Integratoren liegt der relevante Skalierungseffekt nicht darin, dieselbe Hardwarekonfiguration unverändert in verschiedene Fahrzeuge einzubauen.

Wiederverwendbar sind vielmehr zentrale Architekturprinzipien und Funktionen wie:

• deterministische Echtzeitverarbeitung,
• Plausibilisierung von Steueranforderungen,
• Diagnose und Fehlererkennung,
• definierte Fehlerreaktionen,
• sicherheitsgerichtete Steuerungslogik.

NX NextMotion schafft hierfür eine gemeinsame Architekturgrundlage. Dadurch müssen zentrale Mechanismen der elektronischen Fahrzeugsteuerung nicht für jede neue Zielplattform vollständig neu konzipiert werden. Für Entwicklungsorganisationen ist diese Trennung wesentlich: Sie verschiebt den Fokus von der wiederholten Entwicklung grundlegender Safety- und Control-Mechanismen hin zur gezielten Integration der konkreten Plattform.

Was plattformspezifisch bleiben muss

Die Wiederverwendbarkeit des Steuerungskerns hebt die fahrzeugspezifische Entwicklungsarbeit nicht auf. Unterschiedliche Plattformen erfordern unterschiedliche Schnittstellen zur Aktuatorik, Kommunikation und Energieversorgung. Auch Aktuatorkennwerte, Fahrzeugparameter, Einbaukonfigurationen und die konkrete Parametrierung unterscheiden sich.

Die Anbindung kann bestehende Fahrzeugnetzwerke und Kommunikationsschnittstellen nutzen. Welche Technologien zum Einsatz kommen und wie einzelne Funktionen angebunden werden, hängt von der jeweiligen Zielplattform, ihrer E/E-Architektur und der konkreten Funktion ab und muss entsprechend ausgelegt und validiert werden. Eine skalierbare Architektur muss Unterschiede aufnehmen können, ohne dass für jedes Fahrzeug der gesamte sicherheitsgerichtete Steuerungskern neu entwickelt werden muss.

Fully fail-operational als Architekturprinzip

Besonders relevant wird diese Trennung, wenn Fahrzeugsteuerung nicht nur skalierbar, sondern auch bei Fehlern kontrollierbar bleiben soll. Für diesen erweiterten Fehlertoleranzansatz verwendet Arnold NextG bei NX NextMotion den Begriff fully fail-operational. Er beschreibt die technische Auslegung der Architektur und keine eigenständige normative Sicherheitsklasse.

Der Ansatz betrachtet vier Vollständigkeitsachsen gleichzeitig: Funktion, Kanal, Steuerquelle und Energiepfad. Nach jedem zu betrachtenden Einzelfehler führt die Plattform alle sicherheitsrelevanten Steuerfunktionen uneingeschränkt weiter – innerhalb der spezifizierten Ausfallraten, Leistungsgrenzen und Reaktionszeiten. Für Teleoperation und autonome Fahrfunktionen ist insbesondere die Steuerquellenachse relevant: Die Architektur setzt den Fahrer nicht grundsätzlich als Rückfallebene voraus.

Damit wird Fehlertoleranz nicht auf die Redundanz eines einzelnen Steuergeräts reduziert. Sie wird zur Eigenschaft der gesamten Wirkungskette von Steueranforderung, Verarbeitung, Kommunikation, Aktuatorik und Energieversorgung.

Domänenneutralität heißt nicht pauschale Zertifizierung

Für OEMs und Entwicklungsdienstleister ist ein weiterer Punkt entscheidend: Eine wiederverwendbare Architektur kann für unterschiedliche Anwendungsdomänen relevant sein, ohne deshalb automatisch für jede Domäne zertifiziert zu sein. NX NextMotion wurde nach ISO 26262 für Anwendungen im öffentlichen Straßenverkehr entwickelt. Die fully fail-operational Eigenschaft wurde darüber hinaus gegenüber funktionalen Sicherheitsanforderungen angrenzender Domänen analysiert – darunter ISO 25119 für Land- und Forstmaschinen, ISO 13849-1 für Maschinen sowie IEC 61508 als generischer Rahmen für sicherheitsbezogene E/E/PE-Systeme.

ISO 26262 adressiert funktionale Sicherheit sicherheitsrelevanter E/E-Systeme in Serien-Straßenfahrzeugen. ISO 13849-1 beschreibt Anforderungen und Methoden für sicherheitsbezogene Teile von Maschinensteuerungen; ISO 25119 adressiert entsprechende Steuerungssysteme in Land- und Forstmaschinen.

Für eine konkrete Defence-, Automotive- oder Off-Highway-Anwendung bleibt die Bewertung deshalb immer abhängig von Zielplattform, Funktion, Integrationsumfang und Einsatzkontext. Domänenneutralität bedeutet also nicht, normative Anforderungen zu vereinheitlichen. Sie bedeutet, dass grundlegende Architektur- und Safety-Prinzipien so angelegt sind, dass sie über unterschiedliche Anwendungen hinweg weiterverwendet und gegen die jeweils relevanten Anforderungen bewertet werden können.

Was OEMs, Tier 1 und Integratoren früh klären sollten

Für die Entwicklung einer skalierbaren Drive-by-Wire-Architektur ergeben sich damit fünf zentrale Fragen:

• Control Core: Welche Steuerungs-, Diagnose- und Fehlerreaktionsfunktionen sollen über mehrere Plattformen hinweg unverändert bleiben?
• Schnittstellen: Welche fahrzeugspezifischen Kommunikations- und Aktuatorpfade müssen pro Zielplattform entwickelt werden?
• Parametrierung: Welche Kennwerte und Systemparameter hängen unmittelbar vom konkreten Fahrzeug ab?
• Safety Case: Welche Sicherheitsanforderungen gelten für Funktion, Plattform und Einsatzdomäne – und welche Nachweise müssen projektspezifisch geführt werden?
• Validierung: Welche Teile einer bestehenden Architektur können übernommen werden und welche müssen auf der jeweiligen Zielplattform neu verifiziert und validiert werden?

Diese Fragen sind nicht auf Defence beschränkt. Auch klassische OEM-Programme, Nutzfahrzeuge, Off-Highway-Maschinen oder neue softwaredefinierte Fahrzeugkonzepte stehen vor derselben Grundentscheidung: Wie lässt sich technologische Wiederverwendung erhöhen, ohne notwendige Fahrzeugspezifik zu verlieren?

Defence verdichtet die Anforderungen an Plattformskalierung

Im Defence-Umfeld tritt diese Herausforderung besonders deutlich hervor. Unterschiedliche Plattformgenerationen, Rad- und Kettenfahrzeuge, verschiedene Antriebssysteme und unterschiedliche Nutzungskonzepte können innerhalb einer Flotte parallel bestehen. Gleichzeitig entstehen neue Anforderungen durch Teleoperation, automatisierte Fahrfunktionen und unbemannte Anwendungen.

Die Architektur muss deshalb zwei scheinbar gegensätzliche Anforderungen zusammenführen: Standardisierung dort, wo sie technisch sinnvoll ist – Spezialisierung dort, wo sie für die konkrete Plattform notwendig bleibt. Für OEMs und Integratoren entsteht daraus ein anderer Blick auf Drive-by-Wire. Entscheidend ist nicht nur, ob Lenkung, Bremse und Antrieb elektronisch steuerbar sind. Entscheidend ist, ob die zugrunde liegende Control Layer über verschiedene Fahrzeugprogramme hinweg konsistent weiterentwickelt werden kann.

Vom Einzelprojekt zur wiederholbaren Integrationsarchitektur

Eine skalierbare Drive-by-Wire-Plattform ersetzt keine plattformspezifische Entwicklung. Sie verändert jedoch, wo diese Entwicklung beginnt. Statt grundlegende Steuerungs-, Diagnose- und Safety-Mechanismen mit jeder Plattform erneut aufzubauen, kann die Entwicklungsarbeit auf einer bestehenden Architekturgrundlage aufsetzen und sich auf die konkrete Fahrzeuganbindung, Parametrierung und Validierung konzentrieren.

NX NextMotion verfolgt damit einen Plattformansatz, bei dem nicht das Fahrzeug vereinheitlicht wird, sondern die Control Layer für Fahrzeugbewegung. Der entscheidende Unterschied lautet:

Skalierbarkeit entsteht nicht dadurch, dass jede Plattform gleich behandelt wird. Sie entsteht dadurch, dass klar definiert ist, was gleich bleiben kann – und was spezifisch bleiben muss.

WE CONTROL WHAT MOVES 

Weitere Informationen: www.arnoldnextg.de

Quellen und technische Einordnung

• ATZheavy duty 02/2026 – „Drive-by-Wire-Plattform zur Integration verschiedener Steuerquellen“ – technischer Hintergrund zu NX NextMotion, zur Integration unterschiedlicher Steuerquellen sowie zum fully fail-operational Architekturansatz.
• ISO 26262 – Road vehicles – Functional safety
• ISO 25119 – Tractors and machinery for agriculture and forestry – Safety-related parts of control systems
• ISO 13849-1 – Safety of machinery – Safety-related parts of control systems
• IEC 61508-1:2010 – Functional safety of electrical/electronic/programmable electronic safety-related systems – Part 1: General requirements

This challenge becomes particularly evident with autonomous convoys or unmanned logistics platforms: An identical trajectory can present different levels of difficulty for two vehicles depending on their load, the terrain, or available braking and propulsion reserves. This creates a critical system limitation—the “control gap”—between what a higher-level autonomy or mission system demands and what the actual vehicle platform can execute in a controlled manner under its current conditions.

Arnold NextG addresses the Control Gap with a new product to be unveiled in early November. At the heart of this development is Vehicle Motion Assurance—an additional vehicle-side function that bridges the gap between digital motion commands and drive-by-wire execution.

This development builds on Arnold NextG’s more than 25 years of product development expertise in digital vehicle control and system integration. This know-how forms the technological foundation for the next stage of vehicle architecture development.

A New Layer Between Motion Request and Execution

With NX NextMotion, Arnold NextG has already created the drive-by-wire control layer for in-vehicle execution. Steering, braking, propulsion, and relevant secondary functions are digitally controlled via this layer. The system architecture is now being expanded to include an upstream layer. Its task is Vehicle Motion Assurance: it verifies whether and how a requested motion can be executed in a controlled manner under the platform’s current conditions.

To this end, motion requests are placed in the context of the real-world platform, evaluated, constrained, and monitored during execution. This creates a clear motion chain: an autonomy, mission, or remote system defines the desired motion. The new product layer handles Vehicle Motion Assurance. NX NextMotion implements the approved motion as the drive-by-wire control layer on the vehicle.

“Autonomous systems today can see, analyze, and make decisions. The crucial question is whether their motion requirements can also be implemented in a controlled manner under real-world operational conditions,” says Kevin Arnold, CEO of Arnold NextG. “It is precisely at this interface that we are further developing our vehicle architecture.”

The new solution is aimed in particular at manufacturers, system integrators, and operators of automated, teleoperated, and unmanned defense platforms. It extends the existing Arnold NextG architecture precisely at the point where the “control gap” arises: between the digital motion requirement and the actual vehicle execution.

In the coming weeks, Arnold NextG will provide further technical details on this additional layer. A full product launch will follow in early November—featuring the specific system architecture, the product name, and the technical solution to the “control gap”: Command to Controlled Motion.

WE CONTROL WHAT MOVES.

More Information: www.arnoldnextg.com