For OEMs, Tier 1 suppliers, and system integrators, functional safety has been part of everyday development for years. However, with teleoperated, automated, and unmanned vehicle platforms, the challenge is changing. A fault must still be reliably detected and controlled. At the same time, a second factor is gaining importance: the technical availability of the remaining vehicle functions.
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:
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.
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?
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.
