One Control Architecture, Many Platforms: How Safety-Critical Control Scales Across Platforms

How can a drive-by-wire architecture be scaled across different defense platforms? NX NextMotion separates reusable control functions from platform-specific interfaces, parameterization, and validation.

TECHNOLOGICAL CORE

NX NextMotion combines a reusable control core—designed to be fully fail-operational—with platform-specific integration. Functions for real-time processing, plausibility checking, diagnostics, and error response are built on a common architectural foundation; interfaces, parameterization, and validation remain vehicle-specific.

Defense fleets are technically heterogeneous: wheeled and tracked vehicles, different weight classes, platform generations, and propulsion concepts must be operated and further developed in parallel. For drive-by-wire systems, this raises a key engineering question: Which parts of a safety-critical control architecture can be reused across platform boundaries—and which must be adapted and validated for each vehicle?

The architecture of NX NextMotion addresses precisely this boundary between the reusable control layer and platform-specific integration.

One control core, different platforms

NX NextMotion forms the control layer between requesting systems and the vehicle’s actual motion functions. Drivers, remote operators, or automated driving systems can issue control requests; on the vehicle side, steering, braking, and propulsion are connected via platform-specific interfaces.

This separation is the key to scalability. Vehicle communication, actuators, and specific interfaces vary from platform to platform. Functions such as real-time processing, plausibility checks, diagnostics, and defined error responses, on the other hand, can be built on a common architectural foundation. This standardizes not the integration itself, but its safety-critical core. As a result, fundamental control and safety mechanisms do not need to be completely redeveloped from scratch for each target platform.

Domain-neutral rather than vehicle-specific

Arnold NextG uses the term “fully fail-operational” to describe its advanced fault-tolerance approach—a deliberately narrower working definition: 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, and across four completeness axes simultaneously: every safety-critical function, every channel, every control source, and every energy path. This specifically implies that teleoperation and autonomy do not rely on a driver as a fallback. Degradation is only permitted in the defined limp modes and within the specified time windows. The term does not denote a normative safety class; the property is quantitatively verifiable within the safety concept.

NX NextMotion was developed in accordance with ISO 26262 for public-road applications. Since the fully fail-operational property is domain-neutral, the architecture has also been analyzed against functional-safety requirements from 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.

Consequently, there is no blanket certification across all domain boundaries. The domain-neutral design and analysis of the architecture are substantiated based on various normative requirements. The specific evaluation remains tied to the target platform, function, and deployment context. This distinction is crucial: NX NextMotion does not mean that every platform can be operated with the same configuration without adaptation. Rather, it is the fundamental functional safety and control principles of the architecture that are reusable.

Platform-specific where necessary

Different vehicles use different electrical systems, communication structures, and actuator concepts. The connection can, for example, utilize existing CAN-based vehicle communication; however, the specific interface architecture always depends on the target platform. This adaptation does not contradict platform independence; rather, it is a prerequisite for it. An open architecture must be able to accommodate differences at defined interfaces without making the entire control layer vehicle-specific as a result.

Vehicle parameters, actuator characteristics, communication behavior, and installation configurations also vary from platform to platform. They must be taken into account, parameterized, and validated during the specific integration process. It is the safety-oriented control approach that is reusable—not every interface or parameter setting.

What Reusability Means in Development

For manufacturers and integrators, a reusable control layer means that fundamental mechanisms for control, diagnostics, and fault response do not have to be completely redeveloped for every target platform. Development work can thus focus more strongly on the specific vehicle integration: interfaces, actuators, communication, parameterization, and validation.

This creates a consistent technical framework across different platforms without abstracting or ignoring their specific characteristics. NX NextMotion thus combines technological reuse with the necessary platform-specific adaptation. It is precisely this balance that enables scaling across platform boundaries.

Outlook

A control layer can be deployed across multiple platform types. In turn, different control sources can be connected to each of these platforms: the driver, a remote operator, or an automated driving system. But what happens when multiple sources need access to the same motion functions?

The next article will show how NX NextMotion arbitrates control rights and enables controlled transitions between operating modes.

ARNOLD NEXTG – WE CONTROL WHAT MOVES

Sources and Context

ATZheavy duty 02/2026, technical article “Three Control Sources, One Architecture—A Fail-Operational Drive-by-Wire Platform for Integrated Control of Autonomy, Teleoperation, and Driver Intervention.”

ISO 26262; ISO 25119; ISO 13849-1; IEC 61508 – as references for analysis, not as blanket cross-platform certification.