When drivers, remote operators, and automated systems all control the same vehicle functions, control arbitration becomes an architectural challenge. NX NextMotion coordinates control rights and defined transitions between operating modes.
Control Arbitration in Defense: How Drive-by-Wire Coordinates Multiple Control Sources on a Single Vehicle Platform
Pfronstetten-Aichelau, 27.10.2026 (PresseBox) - For many OEMs, Tier 1 suppliers, and development service providers, the electronic integration of steering, braking, and propulsion has long been part of modern vehicle architectures. The system architecture becomes more complex as soon as multiple control sources can access the same motion functions. In defense engineering in particular, different operating modes can coexist on a single platform: manual driving, remote operations?including teleoperation?automated driving functions, or unmanned operation. In such cases, it is no longer sufficient to simply transmit control commands electronically to actuators. The vehicle architecture must clearly define which control source is permitted to control which vehicle function under which system state. Control arbitration thus becomes a central architectural task.
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.
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.
Suchen