This is a good thing. Having the computations done once and the results stored in a LUT saves compute power and it makes the device much easier to test exhaustively. A LUT doesn't have any edge cases, it only has values, whereas computing the same results in real time might lead to result values that cause problems. A LUT simply can not return a value that isn't in it (provided you index it right...).
We (at another supplier) work with 2 types of LUT's: index and interpolation. The "index" ones will return, indeed, only values calibrated by the car maker or the subsystem supplier and nothing else.
Interpolation lookup tables can compute values "in between" the calibrated values, based on not so complicated formula and the input values.
Having this type of computation saves lots of CPU cycles and there's nothing wrong using them. Believe me, there are a lot of models computed in real time, so saving some cycles on maps is quite allright. CPU load is high, as nobody ever will pay for an overkill CPU for a specific application with lower requirements. Modern single core TriCores from Infineon run at 120-150-180 MHz. Maximum CPU load (reached in regeneration or other calculation intensive activities) can go up to 85-87%. You can't go higher MHz with single cores as the heat is not manageable. So future cars (2016+) are setup to use new TriCores with multicore architecture. More complicated to program (to really run on multiple cores, not just use one), and still this new power we get will not be wasted by removing LUT's.
Since LUTs are also calibratable, you can have same model on very similar engines, but with different calibration maps (slightly adjusted to match the engine) => high reusability of code.
You're right, there are also interpolating LUTs, for those the output values tend to be circumscribed by the values listed in the edge columns (and rows in case of 2D tables).
Since you seem to have a lot of insight into this material, what is the reason that the cycle budget is spent to that degree? With my limited insight into the world of embedded systems like these I'd imagine a main loop cycling several thousand times per second and none of the inputs generating more pulses than a few KHz you'd imagine that 120 MHz would be ample, what am I missing? Are these chips programmed in some high level language with significant overhead?
(Coding is done in C, following MISRA rules and some internal additional standards. This includes the generated code - this one may not be highly optimized every time. The rest of the SW I could say is pretty much OK optimization wise. Assambler may be also used in some limited scenarios, especially for low level device drivers)
I think what you are missing is the complexity of the models working with the inputs to produce the outputs. The models are much more than a few LUT's here and there. It is just so much to do and you have to do in real time (we actually use real time operating systems, like RTA-OSEK and RTA-OS). Stuff is executed time based (1ms to 1s, with most at 10ms and 100ms) or event based (generated by SW or by interrupts). Events can come faster than 1ms (crank wheels teeth counting at high rpm for example).
More detail on the "it depends". The guarantees are of the form "if the utilization is less than X%, then an arbitrary collection of periodic tasks can be scheduled without missing deadlines". The key term there is "arbitrary". For example, rate monotonic scheduling provides this guarantee up to ~70% utilization. However, manually scheduled tasks can walk up into the 90's. A UPS application I worked on scheduled all of its periodic tasks manually by ensuring that each slower rate task had a rate that was always an integer divisor of (and lower preemptable priority than) the next higher rate task. This proceeded all the way until you get down to much slower rate periodic "housekeeping" tasks that weren't even realtime.
That depends. As long as you don't miss any interrupts and as long as you manage to fulfill your latency promises it can work, but the higher the load the closer to the abyss you'll be walking.
Not an automotive developer but I've done quite a bit of embedded stuff that was placed in/on various items including cars. Yes, it is that tight. You're in a sealed container under the hood of a car, the ambient temperatures can be quite high and you're not going to be able to dump any of the heat you generate outside of the box you're in other than through conduction. Those boxes are typically made of ABS so conduction will be terrible.
Of course you could re-design the enclosures, have a heatsink mount point on the outside (some expensive trickery required to do that without breaking the sealed environment), or even an air duct that would allow you to use a fan (but fans tend to fail).
So I can totally see why the constraint on power consumption for such an embedded system would be so drastic.
