Drive-by-Wire and Control Layer
Why Controlled Vehicle Movement Is Becoming a Key Technology for Autonomous Vehicles
The new UN regulations R185 and GTR No. 26 establish an international framework for automated driving systems. At the same time, the UNECE ADS Working Group is developing Guidance and Interpretation Documents (GID) intended to support the practical application of these regulations. Regardless of the specific details, one thing is clear: Future vehicle platforms must be designed in such a way that automated driving functions can be safely developed, validated, and operated.
In the first part of this series, we explained why a distinct, safety-critical layer—the control layer—emerges between the driving decision and the vehicle’s movement. In the second part, we examine the technical requirements for this layer and show why drive-by-wire is becoming the key enabler of future software-defined vehicle architectures.
What Matters Technically in a Control Layer
Deterministic command processing: A Control Layer must process driving commands in a reproducible manner at all times. Priorities, timing behavior, and threshold values must not depend on the current system state or the order of execution. Identical input situations must result in identical vehicle responses.
End-to-end monitoring of the chain of action: Safety does not end with the driving command. The entire chain—from input through communication and actuators to the actual vehicle movement—must be continuously monitored and validated.
Redundancy and fault containment: Critical functions require independent signal, computing, and communication paths. Faults must be detected, localized, and contained without compromising the entire control function.
Fail-operational rather than fail-silent: A control layer must not simply shut down in the event of errors. It is crucial that the necessary control capability is maintained to execute a defined minimum-risk behavior or a safe system transition.
Diagnostics and Traceability: Safety-relevant states, faults, and system responses must be documented in a traceable manner. This data forms the basis for the safety case, certification, in-service monitoring, and continuous development.
Open and defined interfaces: A control layer must be able to integrate different control sources—such as the AD stack, teleoperation, or driver interaction—via clearly defined interfaces. This facilitates reuse, platform integration, and homologation.
Why Drive-by-Wire Is Becoming a Key Enabler
Traditional vehicle architectures were developed for a world in which a human was a permanent part of the control loop. Mechanical or hydraulic connections could serve as both the control path and the fallback mechanism. In driverless applications, this assumption no longer applies: The vehicle must be able to electronically control and monitor steering, braking, and propulsion, and transition to a controlled state in the event of faults.
Drive-by-wire replaces or supplements mechanical control paths with electronic signal and control paths. However, its strategic value lies not solely in the elimination of a steering column or in new packaging freedoms. What is crucial is that vehicle movement becomes addressable, measurable, and controllable via software within a defined safety architecture.
Regulations do not mandate drive-by-wire. In practical implementation, however, they highlight characteristics that are difficult to achieve at scale without highly available electronic motion control: controlled response to faults, unambiguous system states, traceable diagnostics, repeatable validation, and the integration of different control sources.
Safety-by-Wire® and NX NextMotion: Arnold NextG’s Approach
Arnold NextG views Safety-by-Wire® not as a single function, but as an overarching architectural principle. Hardware, embedded software, communication, actuators, power supply, diagnostics, and safety mechanisms are considered as an interconnected chain of effects.
Within this approach, NX NextMotion forms the central control layer. The platform is modular, can be integrated independently of the vehicle, and, according to the company, features a quadruply redundant hardware and software architecture. It controls primary functions such as steering, braking, and propulsion, as well as selected safety-critical secondary functions, and can process driving commands from various sources within a common safety architecture.
- Multi-redundant computing, communication, and power supply paths to avoid critical single points of failure.
- Continuous monitoring and TÜV-certified error management at the hardware and software levels.
- Functional safety in accordance with ISO 26262 up to ASIL D and IEC 61508 SIL 3, as demonstrated by the development and validation documentation.
- TÜV certifications for steering and braking systems in accordance with UN ECE R79 and R13, as well as proven road approval.
- Platform-independent integration from prototype to a vehicle solution ready for homologation.
Arnold NextG is thus deliberately positioning itself not as just another provider of the AD stack. Its strategic role lies below that: NX NextMotion is designed to ensure that a digital driving decision—regardless of whether it originates from autonomy, teleoperation, or a human—is translated into a defined and controlled vehicle movement.
“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.” Kevin Arnold, CEO of Arnold NextG GmbH
What OEMs, ADS developers, and system partners should clarify now
The new regulatory framework does more than just increase the documentation burden. It changes architectural decisions and the boundaries of responsibility. For projects involving highly or fully automated driving functions, five questions should therefore be answered early on:
- Where does the responsibility of the AD stack end—and where does the responsibility for the actual vehicle motion begin?
- Which faults must be detected and controlled by the control layer, regardless of the driving algorithm?
- How are software updates, new driving functions, and vehicle variants integrated into an existing safety case?
- What data and diagnostics are required for approval, event analysis, and in-service monitoring?
- Which parts of the motion control are project-specific—and which can be used as a reusable, pre-developed system foundation?
A clearly defined control layer can reduce complexity here. It does not replace the vehicle manufacturer’s system responsibility. However, it creates a reusable safety and integration foundation upon which different AD stacks, platforms, and applications can be built.
Regulatory requirements are not the final chapter
The new ADS regulations shift the focus from a one-time approval to an ongoing safety model. Safety management, software changes, field data, incident reports, and system limits must remain consistent throughout operation. For companies, this means that regulatory compliance cannot simply be “tacked on” at the end of a development project. It must be an integral part of the architecture, development process, supply chain, and operating model.
For Arnold NextG, this development confirms its own architectural strategy: What matters is not merely whether a system makes the right driving decision, but whether that decision can be implemented in a way that is controlled, traceable, and fault-tolerant at all times.
UN R185 and UN GTR 26 establish an important international framework. They do not define a specific technical solution, nor do they mandate drive-by-wire. However, they make it unmistakably clear that safety must be demonstrated across the entire chain of effects of an automated driving system.
This brings the layer between the algorithm and the actuators into focus. The control layer becomes the strategic infrastructure of the software-defined vehicle: It connects different control sources, manages errors, generates evidence, and translates digital decisions into real-world motion. Autonomous mobility does not begin with an algorithm’s decision. It begins with the ability to execute every movement in a controlled manner.
Sources and Regulatory Note
This classification takes into account the status of the published results from the 21st ADS session of the UNECE held July 14–17, 2026. It represents a technical and strategic assessment by Arnold NextG and does not constitute legal or homologation advice.
- UNECE: Announcement on the new global ADS regulations
- UNECE ADS IWG: 21st Session, Brussels, July 14–17, 2026
- Arnold NextG: NX NextMotion
- Arnold NextG: Safety Concept
- Arnold NextG: Certificates
- Arnold NextG: Company and Mission