Closed-loop fuel control (both short term and long term)

[AndreyB]

At the moment rusEfi ECU depends on external WBO controller and external proprietary long-term fuel auto-tune logic (LTFT). I would like rusEfi to figure out fuel control by itself.

Random first link to read: https://deepblue.lib.umich.edu/handle/2027.42/84501
Wonder if https://deepblue.lib.umich.edu/ has anything else cool. Wonder how to leverage the fact that I am two miles away from the campus pretty often.

[Dial0]

I think relying on an external WBO controller is fine. It allows the users the most flexibility.

How are you planning to do the closed loop control?

I know OEM ecus now use trim tables, which are load against rpm, and a -/+ % of trim for the fuel injectors. They normally have a long term trim table that is limited to something like 15% swing.

The method that I most correlate with closed loop control would be at idle or cruise.
Where the ecu detects that there has been no significant change in throttle for so many seconds, then starts adjusting the fuel trim %.

Being able to auto-tune the entire VE table from scratch or a few starting parameters (engine size,peak torque/rpm, injector dead time, injector size), seems like it should be possible, but I don't know of any ECU that does it well.

[AndreyB]

How are you planning to do the closed loop control?

No idea so far. At this point I just want to implement something similar to TS auto-tune, as the first phase I am implementing in Java within rusEfi console, once it works in Java I will move it inside the ECU. There is some not-yet-really-functional code @ https://svn.code.sf.net/p/rusefi/code/trunk/java_console/models/src/com/rusefi/autotune/

[kb1gtt]

Good description of fuel trim found here, it's 50 minutes long.

[video][/video]

[AndreyB]

Progress - that's just a short-term PID correction, just one PID regulator which uses current target AFR as the targer. @ recommends just adding/subscribing injector milliseconds, bone simple basic implementation.

[video][/video]

[AndreyB]

One day this would be properly documented @ http://rusefi.com/wiki/index.php?title=Manual:Software:Fuel_Control#Closed_loop_correction

[stefanst]

That looks like it's working rather well already- awesome!

[kb1gtt]

I believe OEM closed loop is typically something like this.

-- Every fuel calculation checks AFR and calculates what % the fuel is wrong. This % is then added to a Fuel Error Variable (FEV). Over time you would have some %'s that are high and some that are low. So if you are operating perfectly, this variable would hang out very close to 0%.
-- Once a second, if the variable is above something like 1% or 2%, then the Short Term Fuel Trim (STFT) variable is increased by 1%. Or if negative, then decreased by 1%. The goal of STFT is to keep this FEV at 0%.
-- Once a minute, the STFT is checked and if STFT is 1% perhaps 2% then Long Term Fuel Trim (LTFT) variable is increased by 1%. Or if negative, then decreased by 1%. The goal of LTFT is to keep the STFT at 0%.
-- When cold and operating in open-loop, you calculate fuel as you currently do, then add LTFT. Keep in mind LTFT is not updated until you are in closed-loop mode.
-- When in closed-loop you calculate fuel as you currently do, then add both STFT and LTFT.
-- Normal operation of STFT and LTFT is less then 2% and could be 5% with normal engine wear and tear.
-- If STFT or LTFT get up to 10% that would potentially trigger an error code.
-- STFT and LTFT are both limited to no more than 15%. AKA a massive air leak can not dump more than 30% more fuel.
-- Closed loop is entered when you coolant is warm, etc for at least 1 minute. This includes letting the engine run for at least one minute, such that we know coolant temperature are good.

I'm pretty sure that OEM's do not use a PID loop.

I think a key of this approach is how AFR turns into fuel error %. Also I think a key issue is that OEM's keep a specific AFR, commonly 14.7. So the above algorithm works well. However track day folks are commonly changing the AFR to get more power when they want more power. So calculating the FEV can potentially get kind of complicated.

Any how, that my comments from the peanut gallery.

[Rhinoman]

I think the OEM ECUs use the equivalent of a PID loop, at least the Suzuki ECUs appear to although there may well not be a D term - its a relatively slow system. PID is a continuous time algorithm, micros run in discrete time so the algorithm and values must be translated into discrete time, this is something that seems to be widely ignored by the vast majority of demos and tutorials on the web. A more informed tutorial is here: http://controlsystemslab.com/discrete-time-pid-controller-implementation/
I haven't studied the fuel trim algorithm used on the Suzukis in any great depth. They have three fuel trims, long term, short term and total fuel trim, total fuel trim = (ltft+stft)/2. The 'constants' used in the algorithm appear to vary depending on the engine operating conditions. You'd need to modify the PID or PI algorithm to include the TFT.

[Rhinoman]

Closed loop is entered when the output from the O2 sensor has risen above a defined threshold - that indicates that it is sufficiently heated. There may be a couple of other requirements, I will check.

[kb1gtt]

The firmware currently has a PID block which can be used in multiple places and in multiple ways. What @russian would need for closed loop control is to have a good idea of how the other pieces around the PID block would work and be connected. For example what numbers go in the PID terms, as well as what range of numbers are expected from the error. Remember we are reading ADC values, so would these need to be converted to float, integer, other? As well would they need to be scaled to some human readable range, etc.

I have only see videos explaining how automotive STFT and LTFT operate from a mechanics stand point. Do we know of any more detailed or lower level descriptions of how closed loop operation exist?

[sleepingAwake]

I believe OEM closed loop is typically something like this.

-- Every fuel calculation checks AFR and calculates what % the fuel is wrong. This % is then added to a Fuel Error Variable (FEV). Over time you would have some %'s that are high and some that are low. So if you are operating perfectly, this variable would hang out very close to 0%.
-- Once a second, if the variable is above something like 1% or 2%, then the Short Term Fuel Trim (STFT) variable is increased by 1%. Or if negative, then decreased by 1%. The goal of STFT is to keep this FEV at 0%.
-- Once a minute, the STFT is checked and if STFT is 1% perhaps 2% then Long Term Fuel Trim (LTFT) variable is increased by 1%. Or if negative, then decreased by 1%. The goal of LTFT is to keep the STFT at 0%.
-- When cold and operating in open-loop, you calculate fuel as you currently do, then add LTFT. Keep in mind LTFT is not updated until you are in closed-loop mode.
-- When in closed-loop you calculate fuel as you currently do, then add both STFT and LTFT.
-- Normal operation of STFT and LTFT is less then 2% and could be 5% with normal engine wear and tear.
-- If STFT or LTFT get up to 10% that would potentially trigger an error code.
-- STFT and LTFT are both limited to no more than 15%. AKA a massive air leak can not dump more than 30% more fuel.
-- Closed loop is entered when you coolant is warm, etc for at least 1 minute. This includes letting the engine run for at least one minute, such that we know coolant temperature are good.

I'm pretty sure that OEM's do not use a PID loop.

I think a key of this approach is how AFR turns into fuel error %. Also I think a key issue is that OEM's keep a specific AFR, commonly 14.7. So the above algorithm works well. However track day folks are commonly changing the AFR to get more power when they want more power. So calculating the FEV can potentially get kind of complicated.

Any how, that my comments from the peanut gallery.

Subaru uses this method for fuel trims. They have 4 fuel trim ranges divided up by air flow.
Ive included a screenshot of a program called learning view that takes a snapshot of the current learned fuel trims.
Its a pretty decent system.

[sleepingAwake]

Do we know of any more detailed or lower level descriptions of how closed loop operation exist?

I could look into it more later but there is a subaru enthusist website http://www.romraider.com/forum/
Theyre always working on reverse engieerning subaru ecu logic and having in depth discussions regarding control schemes like this.

[Rhinoman]

I used to have some DSM code, I'll try and find it may have the fuel trim stuff commented, I haven't gone into the Suzuki code in any depth, its full of nested loops to implement delays. Even if I did extract the algorithm then it may well be different to others, there are several methods for transforming from continuous time to discrete time, I'm working away from home for at least three months so I can't get the logic analyser on the ECU in the car to do any code tracing. I'll have a look for patents.

[Rhinoman]

Subaru uses this method for fuel trims. They have 4 fuel trim ranges divided up by air flow.

That probably depends on the year, earlier Suzukis use just one STFT, LTFT and TFT, from something like 2003 they moved to three ranges beyond that I don't have any experience.

[Rhinoman]

The Vitara FSM states that closed loop is used unless:
At engine start and during post-start enrichment
When coolant temperature is low
When highly loaded and enrichment is applied
At fuel cut
When O2 sensor is cold.

Its also disabled if there are any current fault codes.

[sleepingAwake]

Subaru uses this method for fuel trims. They have 4 fuel trim ranges divided up by air flow.

That probably depends on the year, earlier Suzukis use just one STFT, LTFT and TFT, from something like 2003 they moved to three ranges beyond that I don't have any experience.

I believe Subaru started using 4 airflow ranges in 1999 and continued until this day.
My experience is mostly with Subarus from 2002-2015 and reflashing/tuning the stock ecu using opensource software.

[Horsty]

so we actually need two new trim tables in the ecu?

one short term trim table and one long term trim table?!

-- Once a second, if the variable is above something like 1% or 2%, then the Short Term Fuel Trim (STFT) variable is increased by 1%. Or if negative, then decreased by 1%. The goal of STFT is to keep this FEV at 0%.
-- Once a minute, the STFT is checked and if STFT is 1% perhaps 2% then Long Term Fuel Trim (LTFT) variable is increased by 1%. Or if negative, then decreased by 1%. The goal of LTFT is to keep the STFT at 0%.

we should figure out which time for adapting the values really make sense i guess.

and the STFT should be deleted every time the engine stops while the LTFT should be first deleted if you delete it via Tunerstudio or disconnect the ecu from the car.

[kb1gtt]

There are many approaches for many reasons. I don't think STFT and LTFT would be table tune-able. These are self learned, and I would expect they would be just a variable which is added to the fuel pulse equation.

I still haven't found any really good low level explanations about how OEM's do it, and I don't know a good algorithm for after markets folks who vary the AFR, instead of keeping a constant AFR.

[Horsty]

There are many approaches for many reasons. I don't think STFT and LTFT would be table tune-able. These are self learned, and I would expect they would be just a variable which is added to the fuel pulse equation.

a basic only readable LTFT would be nice which the stm does by itself.
such as this: (but not so crappy )

LTFT beispiel.JPG (74.24 KiB) Viewed 17023 times

[AndreyB]

We have a PID stft implementation. What is the end goal exactly? Do we have a test of the existing PID implementation which we are not happy with?

https://en.wikipedia.org/wiki/KISS_principle also being lazy.

[Horsty]

After setting up the ecu, tuning it to the max with autotune, dyno, whatsoever, everything is just fine and good to go.

now you are driving your car, lets say for about two weeks, around.
in this time there is stuff which could affect some values, causing the tables to get slightly off.

pid-implementation fixes this during driving based on the o2-sensor.

a display for this case would be nice to have. -> just in case somebody programming gets bored during their holidays.

[AndreyB]

A display for this case would be nice to have. -> just in case somebody programming gets bored during their holidays.

Great suggestion! https://sourceforge.net/p/rusefi/tickets/342/