For a long time, vehicle safety meant transitioning to a safe state in the event of a failure. With autonomous driving, this understanding is fundamentally shifting—because coming to a stop is no longer automatically safe.
In traditional vehicle architectures, safety was closely linked to the concept of coming to a stop. Systems were designed to shut down or transition to a passive state in the event of a fault. The driver served as the higher authority capable of intervening. With increasing automation, this fallback level is no longer available.
An autonomous vehicle operates independently, often in dynamic environments and under real-world operating conditions. In this context, coming to a standstill can create new risks—for example, in moving traffic, in logistics processes, or in safety-critical applications. This shifts the central question: no longer how a system shuts down safely—but how it remains controllable under constraints.
Fail-operational as an operational requirement
Fail-operational is not an additional technical feature, but an operational prerequisite for autonomous systems. A vehicle that comes to a stop in the event of a fault may comply with traditional safety logic, but it is not economically viable in autonomous operation. Autonomous systems must be able to complete tasks in a controlled manner, reach defined states, or safely navigate out of complex situations. This means that the system must not only detect faults but also actively manage them.
It must be able to assess
Why fail-operational cannot be retrofitted
A common misconception is to view fail-operational as an extension of existing safety concepts. In practice, this is not possible.
Fail-operational requires an architecture in which redundancy, monitoring, decision logic, and actuators are coordinated from the outset. It is not merely a matter of having multiple components available, but rather how the system handles degraded states. A system that merely detects that a function has failed is not fail-operational. Only when it can continue to operate in a targeted manner under these conditions does it meet this requirement.
Normative standards such as ISO 26262 on functional safety address safety requirements at the system level but do not automatically define fail-operational behavior during operation.
The difference becomes apparent during operation
In early development phases, it is often difficult to distinguish between fail-safe and fail-operational. Both approaches can be plausibly specified and documented in accordance with standards.
The difference only becomes apparent during actual operation. It is then that it becomes clear
Why fail-operational is often underestimated
In many autonomous driving programs, the focus is on perception systems and decision-making algorithms. Vehicle control is often viewed as an infrastructural prerequisite, not as a limiting factor. It is only during the transition from test operations to real-world applications that it becomes clear that without fail-operational control, many functions are theoretically possible but cannot be operated in practice.
Fail-operational design determines whether a system merely functions—or can actually be operated. At this point, fundamental architectural decisions can no longer be corrected.
Vehicle control as a prerequisite for autonomy
For autonomous vehicle architectures, this represents a fundamental shift in perspective. Safety no longer arises from shutdown, but from the controlled continuation of motion. The ability to remain capable of action even under restricted conditions becomes a prerequisite for operation, scaling, and acceptance.
Platform approaches such as NX NextMotion from Arnold NextG address precisely this requirement by integrating steering, braking, and propulsion into a shared, multi-redundant, and fail-operational drive-by-wire architecture. This means that vehicle control is no longer understood as a reaction to errors, but as a continuously secured system function.
A new benchmark for vehicle control
For developers, integrators, and operators of autonomous systems, this shifts the key evaluation criterion. The question is no longer: Is a system safe in the event of a failure? But rather: Can it continue to operate safely in the event of a failure? This capability defines the transition from assisted to autonomous systems—and places new demands on the underlying vehicle architecture.
Outlook
In the next article in this series, we will examine why platform independence and retrofitability are not peripheral issues, but rather central prerequisites for the real-world introduction of autonomous systems.
WE CONTROL WHAT MOVES
Further information: www.arnoldnextg.com/blog
In traditional vehicle architectures, safety was closely linked to the concept of coming to a stop. Systems were designed to shut down or transition to a passive state in the event of a fault. The driver served as the higher authority capable of intervening. With increasing automation, this fallback level is no longer available.
An autonomous vehicle operates independently, often in dynamic environments and under real-world operating conditions. In this context, coming to a standstill can create new risks—for example, in moving traffic, in logistics processes, or in safety-critical applications. This shifts the central question: no longer how a system shuts down safely—but how it remains controllable under constraints.
Fail-operational as an operational requirement
Fail-operational is not an additional technical feature, but an operational prerequisite for autonomous systems. A vehicle that comes to a stop in the event of a fault may comply with traditional safety logic, but it is not economically viable in autonomous operation. Autonomous systems must be able to complete tasks in a controlled manner, reach defined states, or safely navigate out of complex situations. This means that the system must not only detect faults but also actively manage them.
It must be able to assess
- which functions are still available
- at what level of performance they are operating
- what priorities apply
- what options for action exist
Why fail-operational cannot be retrofitted
A common misconception is to view fail-operational as an extension of existing safety concepts. In practice, this is not possible.
Fail-operational requires an architecture in which redundancy, monitoring, decision logic, and actuators are coordinated from the outset. It is not merely a matter of having multiple components available, but rather how the system handles degraded states. A system that merely detects that a function has failed is not fail-operational. Only when it can continue to operate in a targeted manner under these conditions does it meet this requirement.
Normative standards such as ISO 26262 on functional safety address safety requirements at the system level but do not automatically define fail-operational behavior during operation.
The difference becomes apparent during operation
In early development phases, it is often difficult to distinguish between fail-safe and fail-operational. Both approaches can be plausibly specified and documented in accordance with standards.
The difference only becomes apparent during actual operation. It is then that it becomes clear
- whether systems can stably manage transitions between states
- whether degraded operating modes can be maintained in a controlled manner
- whether the vehicle reacts predictably even under restricted conditions
Why fail-operational is often underestimated
In many autonomous driving programs, the focus is on perception systems and decision-making algorithms. Vehicle control is often viewed as an infrastructural prerequisite, not as a limiting factor. It is only during the transition from test operations to real-world applications that it becomes clear that without fail-operational control, many functions are theoretically possible but cannot be operated in practice.
Fail-operational design determines whether a system merely functions—or can actually be operated. At this point, fundamental architectural decisions can no longer be corrected.
Vehicle control as a prerequisite for autonomy
For autonomous vehicle architectures, this represents a fundamental shift in perspective. Safety no longer arises from shutdown, but from the controlled continuation of motion. The ability to remain capable of action even under restricted conditions becomes a prerequisite for operation, scaling, and acceptance.
Platform approaches such as NX NextMotion from Arnold NextG address precisely this requirement by integrating steering, braking, and propulsion into a shared, multi-redundant, and fail-operational drive-by-wire architecture. This means that vehicle control is no longer understood as a reaction to errors, but as a continuously secured system function.
A new benchmark for vehicle control
For developers, integrators, and operators of autonomous systems, this shifts the key evaluation criterion. The question is no longer: Is a system safe in the event of a failure? But rather: Can it continue to operate safely in the event of a failure? This capability defines the transition from assisted to autonomous systems—and places new demands on the underlying vehicle architecture.
Outlook
In the next article in this series, we will examine why platform independence and retrofitability are not peripheral issues, but rather central prerequisites for the real-world introduction of autonomous systems.
WE CONTROL WHAT MOVES
Further information: www.arnoldnextg.com/blog
