[RFC] Standardizing Interfaces for Redundant System Switching (ECU/VCU Redundancy)

[TetsuKawa]

Background and Objectives

To date, Autoware has not officially supported operation in a redundant configuration. Consequently, OSS users requiring redundancy have had to develop and integrate their own custom implementations. Currently, TIER IV is developing a redundant architecture utilizing Main/Sub ECUs and Main/Sub VCUs, achieving a degree of success in operations where control shifts to the Sub system upon a Main system failure.

At present, this switching control relies on the /system/election/status topic, with the existing command_mode_switcher node acting as the input interface. However, this approach assumes specific hardware configurations and connectivity, leading to a lack of versatility.

The goal for Autoware as an OSS project is to define a standard interface that allows for the flexible handover of autonomous driving control, independent of the number of ECUs/VCUs or their physical network topology. This discussion aims to define the interface and functional allocation required for such a system. While this proposal does not provide the "switching Function" itself, the design of this interface will directly impact future functional constraints; therefore, we must establish a direction that ensures long-term scalability.

Current Configuration and Challenges

The current configuration being piloted by TIER IV assumes an "ECU Switching Function" (hereafter referred to as the Vague component) provided by the vehicle integrator.

In this setup, the Vague component monitors the status of the vehicle and each ECU, then sends a switching request via /system/election/status. The command_mode_switcher receives this, identifies the current ECU switching state, and shares this information with the command_mode_decider via /system/command_mode/status. The final determination of system behavior is performed by the command_mode_decider, which subscribes to information from both the Main and Sub ECUs.

For example, if a system failure occurs while driving on the Main ECU, the command_mode_decider determines that a Minimum Risk Maneuver (MRM) should be executed by the Sub ECU. This decision is then processed back through the Vague component, triggering the physical failover to the Sub ECU.

Proposal 1: Distributed Decision-Making

This proposal assumes a model where each Autoware ECU autonomously determines its own behavior, while an external "ECU Switching Function" arbitrates between them.

In this configuration, the vehicle side (the interface consumer) must provide the ECU Switching Function in some form. This can be implemented either as a single piece of high-reliability hardware or as a virtual function distributed across multiple devices.

Operational Mechanism

Each ECU determines the specific behavior it should output and shares the Priority of that behavior with the Switching Function. It is assumed that Priorities are pre-assigned by system designers to ensure consistency across all ECUs.

The Switching Function collects these Priorities from all functional ECUs, identifies the ECU ID with the highest priority behavior, and feeds this result back to all ECUs. Additionally, this Switching Function is responsible for the physical command path switching to ensure that the control commands from the selected ECU are transmitted as the actual vehicle inputs.

This interface is defined as the "minimum viable configuration" for operating a redundant system. Future considerations include adding interfaces that allow ECUs to retrieve debugging information from the Switching Function or send system-wide reset requests to it.

Pros and Cons

• Pros: By limiting the role of the Switching Function to simple "Priority comparison and path switching," the design remains hardware-agnostic and adaptable to diverse vehicle architectures.
• Cons: Because each ECU must independently determine its behavior and maintain redundant API functions—and because inter-ECU synchronization is required to prevent state divergence—the implementation cost within Autoware and the complexity of coordination between ECUs will increase.

Proposal 2: Centralized Supervisor

As a comparative alternative, we also considered a design that centralizes high-level decision-making logic within the Switching Function itself.

In this model, each ECU reports only its own "Availability" (its readiness and capability to execute a specific behavior), and the Switching Function acts as a comprehensive System Supervisor. The Switching Function determines the optimal behavior and identifies which ECU should execute it based on all collected information, then issues commands back to each ECU.

Pros and Cons

• Pros: By consolidating the API logic within the Switching Function, individual ECUs no longer need to handle API-level switching. This significantly simplifies the functional allocation across the ECUs.
• Cons: Because the Switching Function bears the responsibility for complex decision-making, it becomes more difficult to provide hardware-level safety justifications (safety certifications) for the function itself. Furthermore, since the user (vehicle integrator) must implement this sophisticated logic, the barrier to adoption becomes considerably higher.

Comparison of Proposals

Item	Proposal 1 (Distributed)	Proposal 2 (Centralized)
Role of Switching Function	ECU selection based on Priority; physical switching of command output.	Aggregation of all data; determination of optimal behavior; ECU selection; provision of APIs.
Prerequisites for Autoware (ECU)	Each ECU independently determines its optimal behavior. Each ECU maintains API functionality.	Each ECU only calculates its "Availability." No API functionality required on the ECU side.
Pros	High versatility; independent of hardware configuration or constraints.	Clear functional allocation; minimizes complex coordination between ECUs.
Cons	High implementation burden on Autoware (inter-ECU coordination, redundant API management, etc.).	Extremely high implementation cost for the user; risk of being unfeasible due to hardware constraints.

Conclusion

As an Autoware OSS policy, we plan to proceed with the interface implementation based on Proposal 1 (Distributed), as it provides a redundancy framework accessible to a broader range of users without depending on specific hardware configurations.

We would appreciate feedback from the community regarding this direction. In particular, we welcome discussions on the requirements for the Switching Function, as well as any better alternatives or concerns regarding the challenges of inter-ECU coordination in Proposal 1.

[TetsuKawa]

We plan to proceed with a "Proposal 1: Distributed Decision-Making" approach. While the diagram above suggests an infinitely scalable number of ECUs, we intend to implement a simple redundant configuration consisting of a Main ECU and a Sub ECU.