almost all modern engine management systems work similarly, with certain aspects specific to the type of algorithms they are implementing.... they all however, aim to calculate the correct pulse width of the fuel injectors to supply the amount of fuel to reach the desired AFR/Lambda that's been programmed. Alpha-N systems look at TPS and RPM to do most of the figuring. Speed Density systems look at MAP and RPM, MAF systems look at air mass and RPM.
they *all* need to have an idea of how much air is going into the engine at any given time, engines are just air pumps and the ecu is controlling how much fuel to add to get the right mixture that it's been told to try and hit.
in a speed density system like what is on the Rocket III, (some people may argue it's Alpha-N because it uses TPSvRPM fuel map, but you can call it a hybrid system if it makes you feel better, it does use MAP to figure the L map, and internally probably uses MAP during the F calculation as well, we just don't have it available to us), the tables that describe mostly how much air is going in are the F tables which would be (at least what most people would call) Volumetric Efficiency tables. Basically, 'How much air volume gets into the cylinder at what TPSvRPM?' a VE normalized to 1 (100% full), would be the exact displacement of the individual cylinder/combustion chamber at BDC. at low throttle openings, the engine isn't very efficient and the VE is much below 100%. at higher RPMs and throttle openings, the engine is much more efficient and can often reach over 100% VE. this is very much influenced by the engine design and the camshaft profile, intake opening/closing points, exhaust overlap, etc. at higher RPMs and WOT, VE often falls off again because the engine can't fill the cylinders 100% in the short amount of time that the intake valves are open.
so, if the ECU knows the airflow modeling of the system, then the displacement times the VE times the density of the air as measured by the MAP sensor and the Inlet Air Temperature will tell the ECU how much oxygen is in the cylinder right now. the ECU will then look up the desired AFR for the current TPS/RPM, then based on the known flow rate or injector size (which is coded in the ECU someplace, and it may also monitor fuel pressure or battery voltage to know whether the injectors will be opening at the spec the code was designed for.... low battery voltage can mean low fuel pressure for example) it knows how long to keep the injectors open. at lower AFRs it holds them open longer. with larger injectors or higher fuel pressure it holds them open less, etc.
closed loop operation with narrowband O2 sensors only works in a small range of Lambda/AFR, typically 14.5-14.7 or so, anything outside of that range and the feedback is meaningless because the sensor can't accurately measure outside of that range. So, if your AFR table isn't 14.5 (what appears to be the 'closed loop' switch for this ECU), then the system only uses the parameters i spoke of above to calculate the fueling. in closed loop, it does the same calculation, but there's an additional 'offset' added or subtracted to the fuel timing based on the O2 sensor's feedback. this is most often used to fill out long-term and short-term fuel trim tables. the O2 sensor is giving the ECU a 'trend' to update these tables and they are used in the calculation of the fuel timing. what narrowband O2 sensors won't do (which is often the misconception) is adjust your tune for changes in airflow, displacement, camshafts, etc. if it's not *too* far off it can adjust somewhat, but it's not the intention. it's mostly there for fuel economy and to adjust to slight differences in fuel quality/blends over the course of the riding season/conditions, etc.
for the R3 and TuneECU, you have the 3 F maps which are TPS/RPM VE tables. higher numbers mean higher VE and therefore more fuel will result. the L maps are VE tables, just based on MAP feedback rather than TPS. if you set the F-L switch to 0, you're essentially turning it into an Alpha-N system (presuming the MAP reading doesn't contribute too terribly much to the F map-based calculations. if you set the F-L switch to 100 (if you were able to) you would essentially disable the F map and it would be a pure speed density system using MAP vs RPM VEs that are in the L table.
to tune the VE tables properly (at least, using the typical UEGO tools available), you need to be able to correlate the AFR readings with the engine data. Narrowbands are not the best choice for this, as the range they are effective in is small as stated above..... sometimes this can be fudges somewhat by changing the voltage bias offset to the narrowbands.... while they will still think that they are reading the 14.5-14.7 range, the bias is making them actually sense a higher or lower AFR range. however, this accuracy gets worse the farther away from the normal operating (0 bias) they are designed for. if this capability isn't present in the ECU or tuner software it doesn't matter. tuning with narrowbands basically means setting the entire AFR table to the closed loop region and recording the engine data and applying the offsets calculated to the VE tables. if you are too far away from an accurate VE table, the sensors won't be able to read the AFR accurately and your data is garbage. what typically is done when you have the tools (a dyno is nice for this!), is to use WBO2s to read a range of AFRs that can be as low as 10 to as high as 18 or so. the problem with WBO2s is that their response time is *much* slower than narrowbands. you need to collect a lot more data in steady state conditions with widebands to get a good quality of data. for road testing, setting the AFR table to a fixed, safe value across the board (say 13.x) is often done, to remove the need for the ECU to do a rolling calculation of the AFR as the engine moves to different cells in the VE table while riding (it's hard to keep steady-state operations during road testing). the ECU will typically apply an algorithm to determine the VEs at each point between the cells in the VE tables, it's not simply a 'step-function'. if the cell at 10TPS for a given RPM is 5000, and the 15TPS is 6000, the ECU is will use the surrounding values to figure out what the VE is for 12.5% TPS for example..... having smooth transitions between the values in the VE table is beneficial to the ECU because it minimizes the errors in the perfect calculation (which will never be perfect in the dynamic system). smooth transitions are achieved by having good accurate data.
there's tons of other things that go into the ECU's calculations as well, IVO/IVC, EGR (from cam overlap), the 'imperfectness' of injector flow at low and high duty cycles, the possible nonlinearity of the MAP sensor(s) at different RPMs, etc. One thing i find interesting in this ECU is that they didn't use MAP for timing instead of TPS. Does the Rocket 3 only have 1 MAP sensor or are there 3 indivdual sensors per intake?
timing is a whole other thing that i can give input on as well in a separate post if someone's interested in my thoughts on it.