Appropriate MRM behavior with ECU redundant system

[asana17]

We have mappings between MRM and ECU failure situations when we can use redundant ECUs.
I want to ask whether this mapping is appropriate or need to be fixed.

Background

We are currently implementing the ECU redundant system of the Minimal Risk Maneuver. The system extends MRM behavior: When one ECU fails, we can operate the MRM operation in another ECU.

Structure

The following figure shows the current ECU structure we are working on. (For ease, the figure omits some components and lacks topic name accuracy.)

Main, Sub, and Supervisor ECU exist in the architecture. The voter in the Supervisor ECU judges the appropriate MRM behavior from operation mode availability.
External monitors deal with ECU failure in the monitored ECU, such as CPU high load. External monitoring has two different characteristics from self-monitoring:

1. External monitoring results is used when two out of three ECUs indicate the same failure ECU. Ex. When Sub and Supervisor ECU says Main ECU is failing, the voter judges Main ECU has failed. If only Sub ECU said Main ECU is failing, this monitoring result will be ignored.
2. External monitors are given priority over Self-monitors.

Operation mode availability

The operation mode availability shows whether the component, such as autonomous, comfortable stop, or pull over, can be operated.
autowarefoundation/autoware.universe#3829
https://github.com/tier4/tier4_autoware_msgs/blob/tier4/universe/tier4_system_msgs/msg/OperationModeAvailability.msg

Stop operations

Currently, available stop operations are as follows:

1. Emergency Stop: The vehicle will stop quickly with a comfortable deceleration.
2. Comfortable Stop: The vehicle will stop immediately with as much deceleration as possible.
3. Pull Over: The vehicle will stop after moving to the side of the road.

Supervisor ECU does not have Autoware functionality, so the Supervisor can only operate Emergency stop by itself.

We need to combine the above operations to map with failure patterns.

Current MRM behavior mappings

Suppose we are using the Main ECU for vehicle control, and then failure occurs.

The following figure shows current mappings between failure situations and MRM behaviors:

failed ECU	available stop operation on failed ECU	MRM behavior in Cold Standby	MRM behavior in Hot Standby	additional info
Main	Emergency Stop	Emergency Stop by Main	Emergency Stop by Main	When a failure such as software failure occurs, Sub ECU Stop operations are also thought of as unavailable.
Main	Comfortable Stop	Comfortable Stop by Main	Comfortable Stop by Main
Main	Pull Over	Pull over by Main	Pull over by Main
Main	None	Emergency Stop by Supervisor, then Pull over by Sub	Pull over by Sub
Sub	Emergency Stop	Pull over by Main	Pull over by Main	We are planning to continue running to next goal, then Pull over by Main.
Sub	Comfortable Stop	Pull over by Main	Pull over by Main	We are planning to continue running to next goal, then Pull over by Main.
Sub	Pull Over	Pull over by Main	Pull over by Main	We are planning to continue running to next goal, then Pull over by Main.
Sub	None	Pull over by Main	Pull over by Main	We are planning to continue running to next goal, then Pull over by Main.
Supervisor	Emergency Stop	Stop CAN frame, and detect it by VCU	Stop CAN frame, and detect it by VCU	If the VCU is connected to Main ECU directly, we can use Main Can frame
Supervisor	None	Stop CAN frame, and detect it by VCU	Stop CAN frame, and detect it by VCU	If the VCU is connected to Main ECU directly, we can use Main Can frame
Multiple ECU	-	Stop CAN frame, and detect it by VCU	Stop CAN frame and detect it by VCU

We cannot switch the Main ECU to the Sub ECU directly if the system is Cold/Warm Standby. We need to implement time sync between Main/Sub ECU to switch directly.

The idea of new MRM behavior is also welcome.