Limp Home and Engine Protection

It's all about the code!
Post Reply
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Limp Home and Engine Protection

Post by mck1117 »

Hello all, I've been working on implementing some limp home and protection features in the firmware.

It's based on a simple set of rules in the form "if X fails/happens, then disable/change Y, Z, A, and B"

Currently in the works (note: some of these features already exist, but are getting restructured):
  • If RPM is above hard limit, cut ignition and injection
  • If MAP is above boost cut limit, cut injection
  • If the electronic throttle has a problem (TBD how to compute that), set a rev limit of ~1500-2500 rpm (TBD) and disable throttle control for all throttles
  • If a fatal error occurs, disable injection, ignition, electronic throttle, and trigger input (kill the engine).
Possible things to add in the future:
  • In case of a sensor failure, change fueling mode to a fallback that doesn't use that sensor
  • In case of engine overheat, lower rev limit, do rolling cylinder cut, possibly cut engine?
  • In case of low oil pressure, limit engine speed/throttle position?
Anybody have ideas of what they'd like to see for engine protection features?
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Limp Home and Engine Protection

Post by kb1gtt »

-- If rpm rate of change is bad 5krpm to 0rpm in one rotation then cut fuel pump.
-- if over temp then limit hp or do something to protect the engine
-- if speed density sensor failure, then switch to alpha-n or average two fuel algos or something like that.
-- if unreasonably air temp then ???
-- if any sensor fail then ???
-- if onstar then self destruct

Also there should be an enable / disable bit for these. Aka if I don't care to save engine and I want to cross the finish line spraying water, a bit to disable the feature.
Welcome to the friendlier side of internet crazy :)
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Limp Home and Engine Protection

Post by mck1117 »

kb1gtt wrote:
Sat Dec 26, 2020 10:35 pm
-- If rpm rate of change is bad 5krpm to 0rpm in one rotation then cut fuel pump.
we sort of already do this, the pump is on when there was a trigger event in the last XX period of time. Maybe that period should be shorter than the 1 second that it currently is.
kb1gtt wrote:
Sat Dec 26, 2020 10:35 pm
Also there should be an enable / disable bit for these. Aka if I don't care to save engine and I want to cross the finish line spraying water, a bit to disable the feature.
Yes, most of them should get a bit, but a few won't. For example, I'm not interested in letting you disable the ETB protections.
blundar
contributor
contributor
Posts: 141
Joined: Tue Jan 07, 2014 4:38 am
Location: Cincinnati, Ohio
Github Username: blundar
Slack: Dave B.
Contact:

Re: Limp Home and Engine Protection

Post by blundar »

I think my asks are going to be more of a 2.0 than a 1.0 but...

Error handling is soooo critical.

I think that this splits into two pieces:

1. Define conditions that cause an error count
2. Define how to respond to a given error

The nice thing about this is that some existing functions (like a rev limiter) could be implemented by the same kind of logic. i.e. (if RPM > low limit) ign -= 20deg and if (RPM > hi limit) ign source = none or fuel source = none

On many race cars, doing everything to keep the engine running can be a design choice. i.e. mechanically self destruct before giving up
On most street cars, gracefully shutting things down before serious damage occurs typically is far more desirable.
Point: different use cases are going to need drastically different fault handling

On a manual transmission car, losing a clutch switch or clutch position sensor might be worth trapping.
Onn an automatic transmission car, losing a gear shift selector input might be worth trapping.
Neither makes sense on the other car.

What I'm proposing basically is an analog to FSIO (with perhaps many of the same "inputs" ?) that outputs error states. FSERR? Almost the same code could be used, except instead of changing the state of IO, simply an internal "errorstate" could be changed.

What I'm proposing is that the behavior of the rest of the system have the error states available as inputs, just as the value of a sensor would be.
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: Limp Home and Engine Protection

Post by mk e »

mck1117 wrote:
kb1gtt wrote:
Sat Dec 26, 2020 10:35 pm
Also there should be an enable / disable bit for these. Aka if I don't care to save engine and I want to cross the finish line spraying water, a bit to disable the feature.
Yes, most of them should get a bit, but a few won't. For example, I'm not interested in letting you disable the ETB protections.
The way I handle that in my set up is the feature is always on, but simply set the "act if" point to a value that effectively disables it. The only thing I currently act on is low oil pressure and limit engine rpm and max throttle position (engine load is probably better) but to disable I just set the min oil pressure to 0

I have a malfunction light that has oil pres, engine temp, fuel pres at the moment but will likely add more like lamba error nd a few others.

A couple examples of how others do it:

I was looking through the motec M1 software some years ago when I had one and was planning to use it, they have an error condition for every sensor I think as part of the setup that you can set or not set.

Enginelab that ended up installing is library function driven, with a GUI for each available function. All items have the ability to clamp the output, but the analog input function provides an error message if the clamp is enabled and exceeded and there is a predefined channel (every thing in the "program" is a channel, user set channels first then all the built in stuff like these error channels that can't be user edited). Any channel can read any other channel, so adding a sensor error to the MIL light is just "on if AN_xx Error not 0".

So in both ECUs this is baked into every at least sensor whether the user chooses to use it or not. As all aftermarket ECUs are sold in the US for "off-road use" its more about racing where a warning and tracking are desired over any kind of limp-home assuming the driver knows how to limp it home once notified if that is the correct action. Oil pressure can cause serious damaged pretty quickly so that is the one place I have the ECU take action on its own...light on at pressure x, engine limited at lower pressure y o if it drops too quick for the driver to notice and react the engine may be saved.
error output.JPG
error output.JPG (67.92 KiB) Viewed 26258 times
AN_error channels.JPG
AN_error channels.JPG (123.73 KiB) Viewed 26258 times
I know there is a way to save the error to flash and I want to figure that out at some point. There may also be a way to add an error output for any item exceeding the clam limit but those things are not spoken of in the user manual so I need to ask when I get to that point.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Limp Home and Engine Protection

Post by kb1gtt »

Hmmmm if etb claims 0% yet MAF = WOT then limit fuel to 10% or ignore high sensor and only use lower power sensor or do something like that.
Welcome to the friendlier side of internet crazy :)
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: Limp Home and Engine Protection

Post by puff »

what's the usual way of checking engine temperature? from the coolant temperature sensor? what if there's a crack in the rad, and all the coolant has run away? will the sensor still provide valid values? i mean to say, for the peace of mind coolant level sensor is a must.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Limp Home and Engine Protection

Post by mck1117 »

puff wrote:
Mon Dec 28, 2020 9:50 am
what's the usual way of checking engine temperature? from the coolant temperature sensor? what if there's a crack in the rad, and all the coolant has run away? will the sensor still provide valid values? i mean to say, for the peace of mind coolant level sensor is a must.
I think if the sensor tip gets uncovered, the sensor start reading cylinder head temperature, but much slower than coolant since the heat has to travel down the sensor body to the tip. That usually means the temperature will climb when uncovered.

The solution to this is a coolant pressure sensor, since that lets you know both if you're blowing the head gasket, or if the radiator has released coolant. You define an allowed region of temperature vs. pressure: for example at 0C allow 0 to 0.5 bar, but at 100C allow 0.5 to 1.5 bar. Below that you have a leak, and above that the head gasket has let go.
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: Limp Home and Engine Protection

Post by puff »

That's an awesome trick! Haven't heard of using such sensors in mass production vehicles. I'd like to see the implementation of such a solution - I mean, the sensor part number, its proper location, etc.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Limp Home and Engine Protection

Post by mck1117 »

I don't think it exists in consumer vehicles (except maybe at the very top - porsche/mercedes/McLaren sort of thing), but I have seen it in racing, especially drag racing where people are running stupid boost pressures that explode the head gasket in short order.
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Limp Home and Engine Protection

Post by mck1117 »

And coolant isn't very exciting sensor wise, any off the shelf stainless pressure sensor would work
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: Limp Home and Engine Protection

Post by puff »

but wait! shouldn't there be a reliefe valve in the cap of the expansion tank?
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: Limp Home and Engine Protection

Post by mk e »

The few times I've had coolant leaks the temp has read pretty low so with a slow leak I would know to add when I saw the low temp or in winter the heater stopped working.

I think most/all? OEMs are now using a coolant level sensor. They are pretty cheap and were easy to add once they all switched to remote reservoir setups.


Without the level sensor you'd kind of need to map the warmup time and flag an issue when the temp is below normal for the time or similar.

A pressure sensor will see big holes, but with a slow leak a pressure sensor probably would be misled because system pressure is driven by water vapor pressure and at any given temp the water will turn to steam until the until the pressure is at equilibrium, a value you can lookup in a steam table.
https://www.steamtablesonline.com/steam97web.aspx

The steam will fill.....1000x? more space than water so it could be pretty empty and still maintain pressure, I guess at least until the water level drops below the leak point and low density/viscosity steam can rush out if the hole is big enough to allow it.
mk e
Posts: 486
Joined: Tue Dec 06, 2016 7:32 pm

Re: Limp Home and Engine Protection

Post by mk e »

puff wrote:
Mon Dec 28, 2020 1:18 pm
but wait! shouldn't there be a reliefe valve in the cap of the expansion tank?
Only if you don't want the system to explode ;)

Fun fact, the very first US engineering standard was published by SME in 1904 and required pressure systems (steam at the time) to be pressure tested to 1.5 times the rated working pressure and include a relief valve. At the time about 4000 people year year in the the US were dying in boiler explosions.

Most cars are designed to operate at about 195F and have about a 15psi relief valve. The system will hit the relief pressure at about 240F but are normally closer to 10psi....because yeah, that 1904 standard still applies in one form or another and anything that heats water is considered a boiler and must comply :)

Edit: I lied a little. System pressure is due to steam is 0psig below 212F but is 15psig at 250F, at sea level anyway....different answer in Denver. At 195 any pressure you see is from expansion of any trapped air/vapor the water pump. The water pump can put 30psi or more pressure in the block. The relief valve/cap is normally in a place near the pump inlet so its protecting the radiator not the block directly, the block is protected because the pump will deadhead at some pressure and reverse flow above that, which would then trip the relief valve. Anyway a pressure sensor in the block will normally see a higher pressure than the system relief pressure and will vary with RPM and coolant temp (viscosity changes, so pressure drop due to flow changes). After I got done welding on my cylinder heads and realized they leaked, the consensus was they should be pressure tested to 60psi before they went back on the engine to account for pump pressure + overheat water pressure + safety factor.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Limp Home and Engine Protection

Post by kb1gtt »

I guess error check the temperature profile and trigger an error. Aka if engine is not warm after 10 minutes then limit power. Frozen block, loss of coolant, broken sensor can cause bad temp readings. Limit power to limit the damage.

I guess the same for a stuck thermostat. Wrong profile could cause an error event and things could happen.
Welcome to the friendlier side of internet crazy :)
Simon@FutureProof
contributor
contributor
Posts: 413
Joined: Tue Jul 24, 2018 8:55 pm
Github Username: Orchardperformance
Slack: Orchardperformance

Re: Limp Home and Engine Protection

Post by Simon@FutureProof »

So I took a bit of time to get around to looking at this but went through all posts and made a few notes, apologies for the long post.
If RPM is above hard limit, cut ignition and injection
If MAP is above boost cut limit, cut injection
# Can this also be supplemented by setting a max position for the wastegate control and in the case of ETB closing the throttle by say 20% over a second? This would have an effect of reducing the energy to the turbine and lowering the MAP pressure (vs the TIP pressure).
If the electronic throttle has a problem (TBD how to compute that), set a rev limit of ~1500-2500 rpm (TBD) and disable throttle control for all throttles
# As discussed and suggested before, throttle operation can be limited in case of deviation problems to a configurable threshold (sey 30%) or in event of signal loss a fixed position or pulse width equivalent to fast idle can be set.
If a fatal error occurs, disable injection, ignition, electronic throttle, and trigger input (kill the engine).
# This is a tricky one, in some cases this could be worse than the fatal error, for this to work out then we need to be sure that in all cases of fatal error shutting the engine down is safer than allowing the driver to damage the engine. I am put in mind of the F3 incident where power failure on a car lead to a serious collision with a faster car on a corner exit.
Possible things to add in the future:
In case of a sensor failure, change fueling mode to a fallback that doesn't use that sensor
# Assuming this is the discussed TPS - VE transfer table. Difficulty comes with detecting the issue with the sensor, out of range is easy but deviation is harder. Producing the VE table is also tricky, maybe this is something where a script could auto gen it from a log?
In case of engine overheat, lower rev limit, do rolling cylinder cut, possibly cut engine?
# Rolling skip fire could be a good strategy for thermal limiting, proven to work well by cadillac.
In case of low oil pressure, limit engine speed/throttle position?
# Limit throttle as it lower pressure on the bearings, rpm may be needed in a case of a weak pump to keep the oil pressure up. However there is not much we can do about that one, your pretty SOL if its anything more than a bad pressure sender.
-- If rpm rate of change is bad 5krpm to 0rpm in one rotation then cut fuel pump.
we sort of already do this, the pump is on when there was a trigger event in the last XX period of time. Maybe that period should be shorter than the 1 second that it currently is.
# Given there is some time to loose pressure from the rail does this not present the possibility of a noisy trigger signal causing a lean out and engine destruction? Thinking if the pump ended up pulsing on and off.
There is also the issue of determining what is the threshold for "bad" we either go so broad with the default that its in effective or have the user set a limit which could be a source of calibration issues.
What could be very useful is simply logging the events and turning a warning light on as it helps show an aging sensor or a bracket that is just a little too far from the trigger wheel.

-- if unreasonably air temp then ???
# If high air temp then retard ignition and enrich target AFR.
-- if onstar then self destruct
# Agreed.
Yes, most of them should get a bit, but a few won't. For example, I'm not interested in letting you disable the ETB protections.
# Agreed, IMO we should be more aggressive with the requirement for dual signal.
The way I handle that in my set up is the feature is always on, but simply set the "act if" point to a value that effectively disables it. The only thing I currently act on is low oil pressure and limit engine rpm and max throttle position (engine load is probably better) but to disable I just set the min oil pressure to 0
# That is more or less how the older systems are configured when hacking OEM ecus, you just set them to a range where they no longer cause an intervention.
I have a malfunction light that has oil pres, engine temp, fuel pres at the moment but will likely add more like lamba error nd a few others.
# May I suggest a further intervention for hitting the duty cycle limit, and that is to lower the boost target by 50%. Also perhaps allow a minimum AFR while the boost target is above X, to prevent lean outs, if that occurs take the same steps as with duty cycle.
Now keeping MRE in stock in the UK - https://www.FutureProofPerformance.com
Simon@FutureProof
contributor
contributor
Posts: 413
Joined: Tue Jul 24, 2018 8:55 pm
Github Username: Orchardperformance
Slack: Orchardperformance

Re: Limp Home and Engine Protection

Post by Simon@FutureProof »

Adding a further suggestion to the pot here, in some cases a custom bit of protection may be wanted, some additional actions that the ECU would need to take over and above the basic intervention.

Suggestion is that we expose the flags for each fault condition to the GPIO so it is possible to have the condition as a trigger for custom things in GPIO.
Now keeping MRE in stock in the UK - https://www.FutureProofPerformance.com
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Limp Home and Engine Protection

Post by AndreyB »

Would FSIO be relevant here? Maybe too much to expect users to FSIO but at least for us?

Open question what are all "conditions" so that we can confirm that FSIO exposes all relevant data points?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Simon@FutureProof
contributor
contributor
Posts: 413
Joined: Tue Jul 24, 2018 8:55 pm
Github Username: Orchardperformance
Slack: Orchardperformance

Re: Limp Home and Engine Protection

Post by Simon@FutureProof »

FSIO would be 100% relevant here, being able to use FSIO for a lot of this would be the quick and dirty way forward until we put them into the code as integrated features.
It would also allow the custom bits in the same way as the GPIO.

I don't think it would be too bad to ask users to paste in ready made formulas for certain tasks at this stage. Only writing the formulas is tricky when you first come to RE.

I will try to close that open question over the weekend. I want to sit down and produce a "what happens and how do with mitigate within current rusEFI" document. Will try to put down as much logic flow as possible and what kind of triggers/counters we will need.
Now keeping MRE in stock in the UK - https://www.FutureProofPerformance.com
Post Reply