Software-defined vehicle (SDV) architecture refers to the electrical and electronic (E/E) systems that enable vehicle functions to be controlled and updated through software. Automakers are increasingly shifting from domain-based systems to zonal automotive architecture, where central computers work with zonal controllers organized by physical location. Long-distance peripherals take this approach further, allowing zonal controllers to operate lights, sensors, and actuators over 10BASE-T1S Ethernet without requiring a dedicated local microcontroller (MCU) for each device.
Depending on the vehicle, automotive hardware architecture can involve 30 to 150 electronic control units (ECUs), according to Bosch. These distributed mini computers support critical functions ranging from braking and battery management to casual exterior lighting and infotainment. Even relatively basic devices can depend on a nearby microcontroller (MCU) for command processing, diagnostics, hardware control, and status reporting. As the number of local controllers increases, automakers face growing pressure to simplify their electrical and electronic (E/E) architectures.
The Neue Klasse platform from BMW illustrates the broader move toward consolidated computing and zonal architecture. Beginning with the BMW iX3, the platform brings major processing workloads into four high-performance computers, described by BMW as “superbrains.” One of these combines more than 100 vehicle functions previously handled by separate systems. BMW reports a 20-fold increase in in-vehicle computing capability compared with earlier automotive architectures. The platform also introduces a zonal architecture divided into four areas: front, center, rear, and roof. This design reduces wiring by approximately 600 meters and makes the wiring harness 30% lighter than in the previous generation. Additionally, smart electronic fuses (eFuses) replace up to 150 conventional fuses, enabling more intelligent power distribution across vehicle systems.
From distributed ECUs to zonal SDV architecture
A practical approach to SDV modernization is domain consolidation, which brings related functions under more powerful controllers responsible for body electronics, chassis, powertrain, infotainment, or advanced driver assistance. This helps reduce the number of individual MCUs while maintaining vehicle functionality.
With zonal automotive architecture, control of vehicle components is organized according to their physical location rather than their functions. A controller serving the front-left area, for instance, can connect local lighting, sensors, speakers, and body control modules even when those components belong to different functional domains. Central compute platforms manage vehicle-wide coordination, while zonal controllers handle communication and control closer to the devices.
This arrangement can cut validated ECU counts, gateways, and cabling. Yet a local MCU may still sit beside each lamp, sensor, speaker, or actuator to interpret commands, execute device software, provide diagnostics, and drive the hardware. As a result, some of the complexity survives at the edge despite consolidation elsewhere. The next design question is how zonal controllers can interact with those devices without duplicating programmable control hardware at every endpoint.
Long-distance peripherals address that question by relocating application-level control logic away from the individual device. The term describes the separation between a peripheral and the controller running its logic, not a fixed physical distance. Software can reside on a zonal controller or central computing platform, while remote hardware performs the requested operation and returns data through the vehicle network.
Moving control logic upstream is only part of the solution, however. The distributed devices and their controllers also need a common mechanism for configuration, communication, and monitoring.
Domain vs. Zonal architecture: What’s the difference?
The key difference between domain and zonal architecture is how an E/E architecture organizes vehicle control: domain architecture groups functions by type, while zonal architecture connects devices according to their physical location in the vehicle.
The table below compares how automotive E/E architecture evolves from distributed ECUs to centralized control with long-distance peripherals.
| Architecture | How control is organised | ECUs / MCUs | Wiring | Where software lives |
|---|---|---|---|---|
| Distributed | One ECU per function | 30–150 ECUs | Point-to-point per function | Every ECU |
| Domain | Domain controllers (body, chassis, ADAS…) | Fewer ECUs, MCUs remain at devices | Still function-based | Domain controllers + edge MCUs |
| Zonal | Central compute + zonal controllers by location | Fewer gateways and ECUs | Shorter, location-based | Central/zonal + edge MCUs |
| Zonal + long-distance peripherals | Zonal controller drives edge hardware directly | No application MCU at suitable endpoints | Shared single-pair Ethernet + optional PoDL | Central/zonal only |
Connecting, controlling, and powering devices at the vehicle edge
Remote Control Protocol (RCP), specified through OPEN Alliance TC18, provides one way to support this model. Available across automotive Ethernet offerings from multiple semiconductor suppliers, RCP enables a host controller to set up, control, supervise, and diagnose remote peripherals. For suitable functions, dedicated endpoints can translate network messages into local signals for LED drivers, audio components, sensors, or actuators, removing the need for a separate application-level MCU and device-specific application firmware.
Analog Devices’ Ethernet-to-the-Edge Bus (E²B) family takes a related approach to edge connectivity, although it is separate from the RCP specification developed by OPEN Alliance TC18. E²B is based on 10BASE-T1S, a 10 Mbps Single-Pair Ethernet technology suited to shorter edge connections. Through multidrop networking, as many as eight nodes can use one shared twisted pair instead of each requiring its own switch connection and cable. Microchip cites support for 10BASE-T1S multidrop runs of up to 15 meters and point-to-point links of up to 25 meters.
Where Power over Data Line (PoDL) is part of the system design, the cable can deliver electrical power as well as network traffic. Compatible low-power peripherals can receive instructions, transmit diagnostic or status information, and draw power over one connection. This reduces the need for separate power cables and can help limit connector quantities, long harness runs, and overall harness weight. Power capacity remains a constraint: 10BASE-T1S PoDL supports up to 10 W for Class 10 and 13 W for Class 11. Higher-demand components, including motors and high-current actuators, may still need an independent power supply.
Using Ethernet at the edge can also reduce the protocol translation and gateway hardware traditionally needed between local buses and a vehicle Ethernet backbone. Physical Layer Collision Avoidance (PLCA) coordinates transmission opportunities among nodes on the shared medium, helping provide predictable communication latency for time-sensitive functions.
New architectural possibilities lead to new engineering requirements
For automakers, consolidating similar functions is one of the most immediate opportunities. Lighting provides a useful example: modules positioned around a car frequently receive comparable commands and share similar status information. Instead of maintaining an MCU and its software in every module, manufacturers can manage common application logic centrally or within a zone and use RCP-capable endpoints to operate the LEDs. This model can support additional lighting features for ambient experience, personalization, entertainment, driver guidance, and vehicle-state indication without multiplying local control software.
Other potential applications include selected body-control devices, environmental sensors, audio components, and actuators. Eliminating application MCUs at the edge, though, does not eliminate the engineering involved. It redistributes that work to the host controllers, network SDV architecture, and supporting software platform.
Controllers must acquire endpoint status, detect and localize faults, and provide the data needed for maintenance and service. Time-sensitive functions require careful handling of traffic loads, response-time budgets, and recovery behavior. Functional-safety engineering must also specify how failures are recognized, contained, and brought to a defined safe state.
Security likewise changes rather than disappears. Although RCP-enabled components can contain embedded firmware for low-level operation, they generally do not need a dedicated application MCU or separately maintained node-specific application software. That can reduce the number of software components and update targets across the vehicle. At the same time, concentrating control logic makes trusted configuration, authentication, segmentation, and protection of the zonal and central computers especially important. A simpler edge therefore depends on software upstream being designed to assume those responsibilities reliably.
From architectural concept to available components
The technology is moving beyond laboratory proposals. Semiconductor manufacturers offer automotive-oriented endpoints, development kits, drivers, and supporting design resources that engineers can use for prototyping and integration.
Microchip’s LAN866x portfolio provides 10BASE-T1S connectivity for designs involving control, lighting, and audio functions, allowing network traffic to interface with local hardware rather than relying on a separately programmed application at every node. Analog Devices also supplies E²B components for hardware-based edge devices, including capabilities associated with diagnostics, synchronization, and power delivery on the data connection.
These products should be treated as enabling components, not a complete vehicle solution ready for installation. OEMs and Tier 1 suppliers still have to determine which functions fit the approach, engineer the power distribution, implement and integrate endpoint control, and demonstrate the required functional-safety behavior.
Current progress of long-distance peripheral adoption
Long-distance peripherals are advancing from evaluation into concrete automotive development plans. BMW Group intends to use Analog Devices’ E²B technology in ambient-lighting architectures for future vehicles. In February 2026, Hyundai Motor Group and Microchip also announced plans to collaborate on evaluating 10BASE-T1S Single-Pair Ethernet for future vehicle connectivity.
These developments do not mean MCU-less peripheral networks have become the standard across production vehicles. Early opportunities are concentrated in areas with moderate bandwidth needs, large numbers of edge devices, and substantial duplication of local electronics. Lighting, certain control networks, audio, and selected sensors and actuators are candidates. Cameras, radar, and other high-throughput systems, by contrast, continue to depend on faster communication links and different processing approaches.
How software engineering partners support long-distance peripheral integration
Adopting long-distance peripherals involves more than exchanging one electronic component for another. Control software moves to a different part of the software-defined vehicle architecture, and the communication model changes with it. Engineering partners can support OEMs and Tier 1 suppliers by selecting viable use cases, developing the network and software architecture, building proofs of concept, integrating drivers, and validating performance under representative operating conditions.
Intellias works with global automotive OEMs on research, development, and proof-of-concept activities involving RCP-enabled solutions. This includes connecting real hardware endpoints, implementing communication protocols, evaluating timing and diagnostics, and establishing where MCU-less designs can provide measurable benefits before broader deployment.
Not every ECU should disappear from a software-defined vehicle. The more useful goal is to remove repeated control functions where they can be managed collectively. By simplifying electronics at the vehicle edge while preserving the functions drivers and passengers expect, long-distance peripherals can contribute to SDV platforms that are easier to maintain, adapt, and scale.
