mk e wrote:
After pondering a bit I've come to this. It's interesting how you've arranged things.
Load (MAP/Baro or TPS or a mixture of the 2) is independent of RPM, but "Charge" is a function of Load & RPM. Load & RPM are sufficient to fully characterize engine state because because they are independent of RPM.
Charge is a function of RPM so Charge v RPM can not fully characterize the engine state, so you've had to add TPS, which is independent to gain the missing information. What you have is a fully functional system and it sounds like you've got it working quite well....and with a turbo setup you normally need both MAP and TPS involved because you also have boost to think about which adds another dimension to things and MAP alone can't separate out turbo effects from driver input on the throttle.....interesting how you've split it up.
It's always an interesting dance of what tables we need to and how easy they are to calibrate.
We based our design on an OEM system which we had access to. Since OEM systems run strict stoichiometric for emissions reasons, Charge and RPM alone are enough to fully characterize the engine. Whenever they enrich (which changes spark), they are at high load and hugging the knock limit with knock control so the exact values in the spark tables aren't as important. Charge also correlates really well to indicated torque (assuming MBT spark) which helps in torque modeling, and Charge can be used with other airflow models also based on the ideal gas law or nozzle flow equations.
Our first gen system was implemented exactly as the OEM system. We run very lean since fuel economy is prioritized more than emissions in our competition (sorta..) so we added a pair of fuel/air tables indexed by Charge and RPM, one for eco and one for performance. However, we had to manually copy cells between the tables in some regions and it was a PITA. The second gen system had a single charge-based lean limit table which defines the leanest the engine is allowed to run and a number of lower resolution driver demand tables. The idea is to make separate tables for engine characterization which are all charge-based and tables for driver intent which are all pedal-based. If we had functions which required it, we could insert software which produces a pedal-load from something other than a pedal, such as cruise control or traction control.
Once we split the software in half, it was much easier to go into the engine test cell and calibrate all of the engine surfaces with all 0's or 1's for the driver surfaces, then go into the vehicle and ride around and trim the driver surfaces without worrying about interactions to the engine or going out of the engine's operating range. There are some cases where we have overlapping tables but it all works very well in the end.