RCP Demonstrator

Introduction

Software-defined vehicles are changing the way we think about vehicle electrical and electronic architectures. Instead of giving every feature its own dedicated electronic control unit, centralized architectures move more of the computing and decision-making into a small number of high-performance modules. This can reduce hardware, wiring, and overall system complexity, but it also creates new challenges for connecting the vehicle’s sensors, actuators, and power distribution systems.

I have been working on a demonstrator that brings these ideas together in a way that is easy to see and understand. The demonstrator shows the communications side of a centralized E/E architecture, the powernet side, and, most importantly, how Remote Control Protocol (RCP) can make a door module much simpler.

We will be showcasing this work at Bosch’s Mobility Experience Days (MED) at the end of September of this year. The goal is to show not only what a centralized architecture looks like (that is pretty standard from a high level point of view), but also why RCP can be an important part of making these architectures practical.

The Centralized Architecture

At the center of the demonstrator is a High Compute Module (HCM). The HCM is responsible for handling the vehicle functions that would traditionally be distributed across several different electronic control units. It communicates with two zone modules over 10GBase-T1 Ethernet.

Each zone module is also connected to a camera using the same 10GBase-T1 connection. This represents the communications, or COM, side of the E/E architecture. The zone modules provide a local connection point for devices in their area of the vehicle, while the HCM provides the centralized computing capability needed to coordinate the vehicle’s functions.

This arrangement gives a clear picture of the direction many vehicle architectures are taking: high-bandwidth communication between centralized compute and zones, with the zones located closer to the sensors and actuators they support.

Showing the Powernet Side

Communication is only one part of the architecture. The modules also need a power distribution system that can support different voltage domains and the electrical loads connected to them.

For this demonstrator, a Bosch Powernet Guardian (PNG) supplies power to the modules at both 12V and 48V. The HCM is supplied with 12V, while the zone modules receive both 12V and 48V. This allows the demonstrator to show how the communications architecture and the powernet architecture work together in a centralized vehicle system.

The 48V side is especially important as vehicle electrical loads continue to grow. Higher-voltage power distribution can help support these loads more efficiently, while centralized architectures can reduce the number of separate control units needed throughout the vehicle. The PNG provides the power-management foundation for demonstrating these different voltage domains in one system.

The RCP Door

The most important part of the demonstrator is the door. One of the zone modules is connected to the door over 10BASE-T1S Ethernet. Inside the door is an RCP bridge that translates the Ethernet frames into the low-level interfaces needed by the door hardware, including I2C, SPI, ADC inputs, and general-purpose I/O.

The HCM can therefore control the door by sending Ethernet frames through the zone module and across the 10BASE-T1S connection. From the HCM’s perspective, the door is another part of the centralized vehicle architecture. It can send commands to control functions and receive information from the switches, motors, lights, and other devices in the door.

The key idea is that the door does not need its own microcontroller containing the functionality for those features. The RCP bridge provides the connection to the low-level hardware, while the HCM handles the logic and processing. In other words, the door has the interfaces it needs, but the intelligence can remain centralized.

Why This Matters

Traditional door architectures can require a local microcontroller and a large amount of wiring running between a door module and the different switches, motors, lights, and sensors in the door. As the number of vehicle functions increases, this can make the door harness and the overall electrical architecture more complicated.

RCP provides another option. By using Ethernet to communicate with a simple bridge in the door, the vehicle can reduce or remove the need for a dedicated microcontroller in the door module. It can also reduce the amount of point-to-point wiring that would otherwise need to run between a centralized module and each individual door device.

This is the main selling point of the demonstrator: RCP can help move functionality into the HCM without requiring every end node to have its own intelligence. The result is a simpler edge node, less wiring, and a more scalable approach to centralized E/E architectures.

From Concept to Demonstration

The demonstrator combines several important elements of a software-defined vehicle in one setup:

• A High Compute Module for centralized vehicle functionality.
• Two zone modules connected to the HCM over high-bandwidth 10GBase-T1 Ethernet.
• Cameras connected to the zones using the same 10GBase-T1 technology.
• A Bosch Powernet Guardian supplying both 12V and 48V power domains.
• An RCP-enabled door connected over 10BASE-T1S.
• An RCP bridge translating Ethernet frames into I2C, SPI, ADC, and I/O signals.

Each part demonstrates something important on its own, but the real value comes from seeing the pieces operate together. The COM side provides the high-bandwidth backbone, the powernet side supplies the different electrical domains, and RCP connects the centralized compute platform to simple, low-level vehicle devices.

Mobility Experience Days

We will be presenting this demonstrator at Bosch’s Mobility Experience Days at the end of September. I am excited to show how these technologies fit together and to explain the practical benefits of RCP in a centralized architecture.

For me, the door is what makes the concept especially compelling. It is easy to talk about moving functionality into a centralized computer, but the demonstrator makes the idea tangible: the HCM can control the door, while the door itself does not need to contain the application intelligence. That is a concrete example of how RCP can help reduce vehicle complexity at the edge while supporting the broader goals of software-defined vehicles.

Looking Ahead

Centralized E/E architectures will continue to evolve as vehicles add more software, sensors, and electrical loads. High-compute modules, zone-based communications, and flexible power distribution are all important parts of that evolution.

RCP adds another piece to the picture by providing a practical way to connect simple edge devices to centralized compute. By reducing the need for local intelligence and extensive wiring, it can help make centralized architectures more cost-effective, easier to scale, and easier to integrate.

That is what this demonstrator is intended to show: a vehicle architecture where communication, power, and functionality are designed together, with RCP providing a simple connection between the centralized vehicle brain and the devices at the edge.