rusefi.com

Hi All,

I was wondering if it would be possible to run two rusefi's in parallel allowing a simple manual failover between the ECU's controlling fuel and spark.

So with unit A active it would control air, fuel and spark
With unit B active it would control air, fuel and spark
A simple switch would allow toggling from one to another with the injectors and coils connected in parallel

Sensors like Hall effect sensors would be connected in parallel

While failure is unlikely, it's a low cost/weight option which could save the day.

How much hardware are you willing to duplicate ? Are you building a plane ?

No, but I do fly in a plane with redundant engines, batteries and centreline thrust where redundancy is the order of the day and single engine failure won't ruin your day. I understand that Rusefi is only endorsed for off-road use and for non-aviation purposes.

But the focus of the question was more general in nature, in situations where the weight and complexity costs are very low, can redundancy be configured. For instance the gruelling nature of Finke race has been known to kill ECUs.
https://www.carsales.com.au/editorial/details/motorsport-finke-desert-race-run-and-won-37037/

In terms of redundant hardware the focus would be on systems which cause total failure. For example failure of an injector will slow you down but not put you out of the running.
The rusefi ECU is lightweight and relatively cheap, individual coils, plugs and fuel injectors don't cause total system failure. Input sensors might benefit from redundancy I've had MAF sensors fail on a regular basis. Throttle bodies might just be a bridge too far.

The first step is understanding what's achievable and reasonable from an architectural point of view, if code is required it also helps if someone points in the right direction. The master slave demonstration of the microrusefi running in a master/slave arrangement made me curious about the possibilities and with manual failover there's no requirement for quorum, just a simple switch.

The first thing that comes to mind are the pull-up resistors for temp sensors. Having 2 ECUs connected to the same sensor will skew values for both. I am using a UAEFI in conjunction with my stock ECU, where the stock ECU still controls cruise control, AC, tachometer, and stuff like that. The UAEFI controls spark only (for now), but will later control injectors and IAC. I have connectors so I can switch between stock and rusEFI.

It depends on the sensors.
Having two ECU's connected to hall sensors or MAP sensors shouldn't cause an issue.
Sensors like EGT's will either have to be duplicated of ingested via CANbus through an intermediate.

My thoughts to this point.

Initially the scope would be control of the following.
4 fuel injectors
8 spark plugs using CoP
Using inputs from
2 Hall sensors and trigger wheel.
MAP
Air temp
Maybe wideband o2

Batch firing of injectors and wasted spark is simple and getting a cam input is harder.

Simple toggle between the ECU's
Position 1: ECU-A active, ECU-B standby
Position 2: ECU-B active, ECU-A standby

Active ECU: Calculates and outputs normal injection pulsewidths
Standby ECU: Forces all injection pulsewidths to zero (outputs disabled)
Diodes allow either ECU to control injectors and ignition. Probably a separate board to consolidate isolation rather than a lot of distributed components.

I think that changes to the following would be needed.
firmware/controllers/engine_controller.cpp - add state update loop
firmware/hw_layer/digital_input/digital_input.cpp - state input
firmware/controllers/algo/fuel/fuel_computer.cpp - Disable injection in standby
firmware/config/boards/proteus/efifeatures.h Enable redundant mode

I'm starting to think that this query might have been best asked in the software section not hardware.

I don't think that simulator can model a dual ECU's approach.