How Drive-by-Wire Is Reshaping Autonomous Machine Architecture

How Drive-by-Wire Is Reshaping Autonomous Machine Architecture

The international rulebook for fully automated vehicles acquired considerably more substance in June 2026 when the UNECE World Forum for Harmonization of Vehicle Regulations adopted the first global framework covering Automated Driving Systems capable of operating without continuous human control. UN Regulation No. 185 and UN Global Technical Regulation No. 26 now provide parallel regulatory routes for ADS, placing safety management, validation, the safety case and monitoring after deployment within a common international framework.

Much of the attention will naturally fall on the intelligence doing the driving: perception systems, decision-making software, operational design domains and the enormous validation problem involved in demonstrating that an automated vehicle can cope with the road. There is another engineering problem immediately beneath it. Once software has decided that a vehicle should steer, brake or accelerate, something has to turn that digital instruction into physical movement with sufficiently predictable behaviour that the entire chain can form part of a defensible safety case.

That is bringing renewed attention to the vehicle control layer between an automated driving system and the machinery it commands. Drive-by-wire specialist Arnold NextG argues that this layer should be treated as a distinct safety-critical architecture rather than an assortment of steering, braking and propulsion components. Its NX NextMotion platform is one attempt to provide that foundation, separating the source of a driving decision from the controlled execution of the movement itself.

The regulations do not prescribe drive-by-wire, nor do they mandate Arnold NextG’s interpretation of the architecture. They do, however, create an environment in which deterministic control, fault management, traceability and continuous monitoring become difficult to separate from the wider problem of approving and operating automated vehicles. The same engineering problem extends beyond passenger cars into autonomous trucks, shuttles, construction and mining equipment, agricultural machinery and specialised industrial vehicles, where removing the human from the control loop leaves the machine itself responsible for executing every movement safely.

Briefing

• UN Regulation No. 185 and UN GTR No. 26 establish harmonised international provisions for Automated Driving Systems following adoption by WP.29 in June 2026.
• UNECE is developing supporting guidance intended to encourage consistent practical application of the two instruments.
• Automated operation places greater emphasis on deterministic, fault-tolerant electronic control of steering, braking and propulsion.
• Arnold NextG’s NX NextMotion provides a control layer for primary vehicle functions using a multi-redundant architecture.
• A reusable motion-control foundation could allow different autonomous systems, vehicle platforms and applications to share established safety-critical infrastructure.

From Driving Decision to Vehicle Movement

UNECE’s new framework approaches automated driving as more than a function that passes a test before a vehicle enters service. Manufacturers are expected to operate a Safety Management System, assemble evidence demonstrating the capabilities of the ADS, validate it through complementary virtual, track and real-world methods, and continue monitoring safety performance once vehicles are operating.

Work on implementation is continuing. UNECE’s Working Party on Automated/Autonomous and Connected Vehicles, GRVA, and its ADS activities have been developing a Guidance and Interpretation Document covering the GTR and UN Regulation, including subjects ranging from safety cases and Safety Management Systems to data storage and remote interaction. The guidance is intended to help authorities and manufacturers interpret and apply the requirements consistently rather than impose a particular technical architecture.

The regulatory structure nevertheless reaches further down the vehicle than the automated driving algorithm. An ADS can determine a trajectory, request a steering angle or initiate braking, but the physical outcome depends upon communication networks, controllers, power supplies and actuators behaving correctly. The resulting vehicle response also has to be measured so that the system can establish whether the requested movement actually occurred.

For conventional vehicles, the human driver historically sat inside this chain. Mechanical and hydraulic connections could transmit control inputs and, depending upon the architecture, provide a physical relationship between the person operating the vehicle and its steering or braking systems. Fully automated operation removes that assumption. The vehicle may need to remain controllable when nobody is holding a steering wheel or pressing a brake pedal.

Building the Control Layer

Arnold NextG defines this intermediate architecture as the Control Layer. In its model, driving commands arriving from an ADS, teleoperator or human interface pass into a safety-critical system responsible for translating them into steering, braking and propulsion while supervising the resulting chain of action.

Command processing needs to be deterministic. Equivalent commands presented under equivalent conditions should produce predictable responses rather than behaviour dependent upon execution order or an unintended internal system state. Timing, priorities and thresholds become part of the safety architecture.

Monitoring has to extend beyond receipt of the command. A braking instruction being transmitted successfully is not the same thing as the requested deceleration occurring. Communication, control electronics, actuators and ultimately vehicle movement form a connected chain in which discrepancies and failures need to be identified.

Redundancy becomes particularly important when loss of the primary path cannot simply hand responsibility back to a driver. Independent computing, communication, signal and power paths can prevent individual faults from removing control capability, while fault containment is intended to stop a problem in one part of the system propagating through the rest.

Bringing a vehicle to a safe stop may itself require continued steering, braking and propulsion control. A driverless vehicle travelling at road speed cannot necessarily respond to an electronic failure by switching the affected system off. Safety-relevant states, failures and system responses also need to be recorded, both for development and validation and for approval evidence, incident investigation and monitoring during operation.

These requirements are not confined to passenger vehicles. An autonomous haul truck, site vehicle or industrial machine may operate in a very different environment from a road car, but removing the operator creates much the same underlying control problem. The intelligence commanding the machine can change considerably between applications while dependable execution of steering, braking and propulsion remains fundamental.

Drive-by-Wire as Platform Infrastructure

Drive-by-wire is hardly a new concept. Electronic throttle control has been commonplace for years, while steer-by-wire and brake-by-wire systems have steadily moved from specialist applications towards production vehicles and automated machinery.

Replacing a mechanical control path with an electronic one can provide packaging freedom and allow different cabin or vehicle configurations. For an automated platform, steering, braking and propulsion also become electronically addressable functions whose requested and actual states can be controlled and monitored within software.

A common electronic interface can accept commands from more than one source. An automated driving stack may control the vehicle during normal operation, a remote system may provide assistance under defined circumstances, and a human interface may remain where manual operation is required. UNECE’s continuing interpretation work includes consideration of remote interaction and intervention, reflecting the variety of control arrangements likely to emerge around automated vehicles.

The intelligence above the control layer can evolve while some of the safety-critical infrastructure underneath it remains comparatively stable.

Automated driving software is likely to change repeatedly during the life of a platform, with different vehicles using different autonomy providers, operating domains or control strategies. Construction, mining and industrial machinery may also require highly application-specific autonomous behaviour. Rebuilding the complete steering, braking, propulsion, fault-management and diagnostic architecture around every new driving system would make each deployment a substantial systems-engineering exercise.

A reusable motion-control layer cannot remove the need for integration or validation, but it can provide an established boundary between digital driving decisions and physical vehicle behaviour. That gives drive-by-wire a role closer to platform infrastructure than conventional component supply.

NX NextMotion

Arnold NextG’s answer is NX NextMotion, developed around what the German company calls its Safety-by-Wire® principle. Rather than treating individual by-wire components independently, the approach encompasses hardware, embedded software, communications, actuators, power, diagnostics and safety mechanisms as a connected control system.

NX NextMotion combines steer-by-wire, brake-by-wire and acceleration-by-wire within a central control architecture. Arnold NextG describes the platform as multi-redundant and platform-independent, allowing it to control primary vehicle functions alongside selected secondary functions. Company documentation also describes continuous system monitoring and mechanisms intended either to retain functionality or transfer the vehicle to a safe state following a fault.

According to Arnold NextG, the NX NextMotion system architecture is designed for functional safety up to ISO 26262 ASIL D and IEC 61508 SIL 3. The company also states that its steering and braking systems have TÜV certifications under UN ECE R79 and R13 respectively, alongside road approval.

The architecture is intended to remain independent of the intelligence generating the driving command. That potentially allows the same underlying control approach to support different ADS platforms, teleoperation systems and applications rather than binding vehicle motion to a single autonomy stack.

“We’re not developing the next driving algorithm. We’re developing the secure layer on which different driving decisions are reliably translated into movement in the first place. That is precisely where the strategic importance of the Control Layer lies,” says Kevin Arnold, CEO of Arnold NextG GmbH.

It is a deliberately different position from competing to build another complete automated-driving stack. Arnold NextG instead wants to provide part of the infrastructure underneath it.

Reusing Safety-Critical Engineering

An automated driving system has responsibility for perceiving its environment and determining the appropriate response within its defined operating conditions. Motion control then has to execute those decisions while dealing with failures that may occur independently of the intelligence above it. A steering actuator fault, interrupted communication path or power-supply problem cannot be resolved by improving a perception algorithm.

If different autonomous systems can communicate through a stable, defined control interface, some of the underlying motion-control architecture may remain reusable as software and vehicle applications change. A new ADS release or machine variant still has to be assessed as part of the complete system, but steering and braking do not necessarily have to become fresh engineering projects every time the intelligence changes.

This is particularly relevant outside conventional automotive production. Autonomous trucks, mining vehicles, construction equipment, agricultural machinery and industrial carriers are produced in smaller volumes and frequently operate within tightly defined applications. The economics of developing a complete safety-critical motion architecture independently for each programme can look very different from those of a global passenger-car platform.

A pre-developed control layer therefore offers something more useful than a collection of by-wire components. It can package part of the engineering required to make a machine electronically controllable, observable and fault tolerant, leaving vehicle manufacturers and autonomy developers to concentrate more of their effort on the characteristics that actually distinguish the application.

That separation does not remove the manufacturer’s responsibility for the complete machine, and it does not make homologation automatic. It can, however, alter where development effort is spent and where suppliers sit within the autonomous vehicle value chain.

The UNECE framework also extends the safety case beyond initial approval. Software changes, field performance, incident data and system limits have to remain consistent with the safety case as vehicles continue operating. Records of commanded states, actual responses, failures and safety interventions can therefore contribute to incident investigation, software-change management and assessment of whether assumptions made during validation continue to hold in service.

For a reusable control platform, those diagnostic capabilities form part of the engineering proposition. The control system is responsible not only for executing movement but for providing evidence of how it behaved when the vehicle was operating, something that becomes increasingly valuable as software changes while the underlying machine remains in service.

The Machinery Beneath Autonomy

UN Regulation No. 185 and GTR No. 26 have not chosen a vehicle architecture. They do not prescribe drive-by-wire, establish a standard Control Layer or remove the need for manufacturers to demonstrate the safety of the complete automated system.

They do make it increasingly difficult to regard dependable vehicle movement as something that can simply be assumed once an autonomous driving algorithm has made its decision.

For OEMs, that raises decisions about where responsibility for motion control sits, which elements should remain vehicle-specific, which can be standardised across platforms and how much safety-critical engineering should be developed repeatedly as autonomous software evolves.

For suppliers such as Arnold NextG, the opportunity sits below the more visible contest to build increasingly capable driving intelligence. If the autonomous stack becomes replaceable, upgradeable or application-specific while the control architecture beneath it remains comparatively stable, validated motion control becomes a potentially valuable piece of reusable technology.

The autonomous vehicle may attract attention for what it perceives and decides. Its ability to steer, brake and propel itself predictably when the driver disappears from the control loop is more prosaic, but no less fundamental. As automated-driving software becomes increasingly separable from the platforms on which it operates, the machinery between digital decision and physical movement is beginning to look less like a collection of components and more like infrastructure.

Key Industry Questions

1. What are UN Regulation No. 185 and UN GTR No. 26? They are UNECE instruments establishing internationally harmonised provisions for Automated Driving Systems. UN R185 operates through the 1958 Agreement framework, while GTR No. 26 provides globally harmonised technical provisions under the 1998 Agreement.
2. Do the new regulations require drive-by-wire? No. The framework is technology-neutral and does not mandate a particular steering, braking or propulsion architecture.
3. Why is drive-by-wire relevant to autonomous vehicles? It allows steering, braking and propulsion to be electronically commanded and monitored without depending upon continuous human control.
4. What is a control layer? It is the safety-critical architecture between the source of a driving decision and the vehicle’s physical actuators, responsible for processing commands, controlling movement, monitoring execution and managing faults.
5. What does fail-operational mean? A fail-operational system retains sufficient functionality following certain faults to continue controlling the vehicle while an appropriate safety response or transition is performed.
6. Can the same control layer work with different autonomous driving systems? Potentially. Defined interfaces can allow different ADS platforms, teleoperation systems or human controls to use a common underlying motion-control architecture, subject to appropriate integration and validation.
7. Why could this matter for construction and industrial machinery? Specialised machines are often produced in lower volumes and operate in defined environments. Reusing established safety-critical motion-control technology could reduce the amount of engineering that has to be repeated for individual autonomous applications.
8. What does NX NextMotion control? Arnold NextG says the platform controls primary functions including steering, braking and propulsion, together with selected secondary functions, through a common electronic architecture.

Strategic Takeaways

1. Automated driving is creating a clearer architectural boundary between deciding how a machine should move and safely executing that movement.
2. Drive-by-wire provides an electronic foundation through which steering, braking and propulsion can be controlled, monitored and diagnosed.
3. Reusable motion-control technology could become particularly valuable for lower-volume autonomous trucks, construction equipment, mining machines and specialised industrial vehicles.
4. Separating the autonomy stack from the underlying control architecture could allow driving software to evolve without repeatedly rebuilding every element of safety-critical vehicle control.
5. Suppliers positioned beneath the ADS stack may capture an important part of the software-defined vehicle value chain as autonomy spreads across different machine categories.