6 ms·

The "data driven" nature of the ECU is not surprising. Ever since the first ECUs were made they have used lookup tables (LUTs) as opposed to mathematical models

by jzwinck 11y ago

The "data driven" nature of the ECU is not surprising. Ever since the first ECUs were made they have used lookup tables (LUTs) as opposed to mathematical models. I don't know exactly how ubiquitous LUTs are today but certainly they are traditionally used in this application. Computer enthusiasts may enjoy knowing that the controller in many LCD monitors is similarly LUT based rather than containing curves as formulas. As an aside, I imagine "A2L" is short for addr2line.

_0ffh 11y ago
I think "data driven" is meant in how all software modules are running in a kind of quasi-parallel mode: They read a bunch of "current" values, work on them, output a bunch of "next" values. Rinse and repeat. Modern ECU software has lots of physical models in there. (I worked on a few.) Just using a few LUTs hasn't been cutting it for quite some time.
- Washuu 11y ago
  Back in the 1990s using almost exclusively LUTs made sense due to less processing power. The Chrysler JTEC PCM has three Motorola 68HC microcontrollers working in tandem. One for fuel, one for ignition, and one that ties it all back together with other sensors.
  - jacquesm 11y ago
    The other reason is to make the device work in a deterministic manner.
    - TeMPOraL 11y ago
      And in general, not recomputing things that should not be recomputed sounds like very good engineering to me. In the wider software world, we're way too eager to waste computational resources on pointless things.
jacquesm 11y ago
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...).
- kaftoy 11y ago
  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.
  - jacquesm 11y ago
    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?
_pmf_ 11y ago
> As an aside, I imagine "A2L" is short for addr2line. A2L is for "ASAM MCD-2 MC Language" [0] (but it does contain addresses for internal variables and associated information related to the interpretation of the variable's meta data, so your guess makes sense). Mostly, A2L files are generated by using the concrete addresses from an ELF file to fill a template A2L file. This file can be used with something called "application tool", which is mostly either Vector CANape or ETAS Inca, to either manipulate or read out the variable values from the live ECU via the XCP/CCP protocol. XCP also contains mechanisms for so called bypass operation, where stimuli that are generally received via sensors are fed from the host PC (used mainly in stand-alone test scenarios for the ECU). [0] https://wiki.asam.net/display/STANDARDS/ASAM+MCD-2+MC https://wiki.asam.net/display/STANDARDS/ASAM+MCD-2+MC
- kaftoy 11y ago
  Yeah, so much for the "reverse engineering" operation. The guy didn't even take the time to research what the A2L is, but he was quick to throw accusations around [1]. There's nothing like some quick internet exposure. [1] "Domke said that it is clear that lots of different kinds of cheating is going on in the ECU" ... because "12KB block of code that is used to ensure the tachometer always shows 780 RPM when the car is idling. Even though the engine is not that steady [...]". What does he expect? The RPM niddle to have 1-2-10 rpm resolution on the analog board? Or for the value to switch super fast on the digital screen to annoy the driver? All this stuff is filtered to have a smooth display info on the dashboard, same way input values from sensor in all sensor based applications are filtered at some point, for example. [edit] And btw, the SW is not set to display anything. The engine ECU does not display shit. It send data to the BCM or some other module over the CAN (usually) network. The value of 780 rpm in this case is a setpoint value. The ECU is programmed to KEEP a minimum idle engine speed value when not torque is requested. Else the engine would stall. This is done in a closed loop, one of the inputs being the engine speed which is calculated in different ways, from system to system (usually crank wheel sensor counting the teeth). This balance you may imagine will not be able to keep perfectly fixed 780 rpm idle speed, while the BCM will filter the dashboard value for driver's comfort.
  - 11y ago
revelation 11y ago
Notice that the reason the code is data driven to this extent is simply because it has been automatically generated from Matlab Simulink models. Massively popular in the car industry and it will produce code exactly like this as there is very little control flow in Simulink. (There is of course control flow, but really only in the basic elements of blocks you are composing, like a switch or a minmax block. Here is a good example of a Simulink model: http://de.mathworks.com/help/simulink/examples/engine-timing-model-with-closed-loop-control.html http://de.mathworks.com/help/simulink/examples/engine-timing...)

by jzwinck 11y ago

_0ffh 11y ago

I think "data driven" is meant in how all software modules are running in a kind of quasi-parallel mode: They read a bunch of "current" values, work on them, output a bunch of "next" values. Rinse and repeat. Modern ECU software has lots of physical models in there. (I worked on a few.) Just using a few LUTs hasn't been cutting it for quite some time.

Washuu 11y ago
Back in the 1990s using almost exclusively LUTs made sense due to less processing power. The Chrysler JTEC PCM has three Motorola 68HC microcontrollers working in tandem. One for fuel, one for ignition, and one that ties it all back together with other sensors.
- jacquesm 11y ago
  The other reason is to make the device work in a deterministic manner.
  - TeMPOraL 11y ago
    And in general, not recomputing things that should not be recomputed sounds like very good engineering to me. In the wider software world, we're way too eager to waste computational resources on pointless things.

jacquesm 11y ago

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...).

kaftoy 11y ago
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.
- jacquesm 11y ago
  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?

_pmf_ 11y ago

> As an aside, I imagine "A2L" is short for addr2line. A2L is for "ASAM MCD-2 MC Language" [0] (but it does contain addresses for internal variables and associated information related to the interpretation of the variable's meta data, so your guess makes sense). Mostly, A2L files are generated by using the concrete addresses from an ELF file to fill a template A2L file. This file can be used with something called "application tool", which is mostly either Vector CANape or ETAS Inca, to either manipulate or read out the variable values from the live ECU via the XCP/CCP protocol. XCP also contains mechanisms for so called bypass operation, where stimuli that are generally received via sensors are fed from the host PC (used mainly in stand-alone test scenarios for the ECU). [0] https://wiki.asam.net/display/STANDARDS/ASAM+MCD-2+MC https://wiki.asam.net/display/STANDARDS/ASAM+MCD-2+MC

kaftoy 11y ago
Yeah, so much for the "reverse engineering" operation. The guy didn't even take the time to research what the A2L is, but he was quick to throw accusations around [1]. There's nothing like some quick internet exposure. [1] "Domke said that it is clear that lots of different kinds of cheating is going on in the ECU" ... because "12KB block of code that is used to ensure the tachometer always shows 780 RPM when the car is idling. Even though the engine is not that steady [...]". What does he expect? The RPM niddle to have 1-2-10 rpm resolution on the analog board? Or for the value to switch super fast on the digital screen to annoy the driver? All this stuff is filtered to have a smooth display info on the dashboard, same way input values from sensor in all sensor based applications are filtered at some point, for example. [edit] And btw, the SW is not set to display anything. The engine ECU does not display shit. It send data to the BCM or some other module over the CAN (usually) network. The value of 780 rpm in this case is a setpoint value. The ECU is programmed to KEEP a minimum idle engine speed value when not torque is requested. Else the engine would stall. This is done in a closed loop, one of the inputs being the engine speed which is calculated in different ways, from system to system (usually crank wheel sensor counting the teeth). This balance you may imagine will not be able to keep perfectly fixed 780 rpm idle speed, while the BCM will filter the dashboard value for driver's comfort.
- 11y ago

revelation 11y ago

Notice that the reason the code is data driven to this extent is simply because it has been automatically generated from Matlab Simulink models. Massively popular in the car industry and it will produce code exactly like this as there is very little control flow in Simulink. (There is of course control flow, but really only in the basic elements of blocks you are composing, like a switch or a minmax block. Here is a good example of a Simulink model: http://de.mathworks.com/help/simulink/examples/engine-timing-model-with-closed-loop-control.html http://de.mathworks.com/help/simulink/examples/engine-timing...)