Defense platforms highlight a development challenge that is also familiar to OEMs, Tier 1 suppliers, and system integrators from other vehicle segments: Different vehicles must draw on a common technological foundation without disregarding their individual architectures, actuator concepts, or safety requirements. This challenge becomes particularly evident in drive-by-wire systems. Steering, braking, and propulsion are directly related to the vehicle’s controllability. A scalable architecture therefore cannot be based on transferring the same integration unchanged to different platforms.
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:
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:
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
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.
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?
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
