Reverse engineering the VW electronic control unit

http://lwn.net/SubscriberLink/670488/4350e3873e2fa15c/

by oska • 11 years ago

123 24 11 years ago

jzwinck2• 11 years 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• 11 years 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• 11 years 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.

jacquesm5• 11 years 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...).

kaftoy3• 11 years 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.

_pmf_• 11 years 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

kaftoy3• 11 years 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.

revelation• 11 years 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...)

snyderize2• 11 years ago

This seems to be about engines that use diesel exhaust fluid (lots of references to AdBlue), not the 2.0 L TDIs that are part of the emissions scandal

ygra2• 11 years ago

The ECU he looked at was from his own car, which does use DEF, but also was affected by the recall that reprogrammed it, so it had the affected engine. While many of the affected cars didn't use DEF, some did. And since he could tinker and test with his own car, that's what he looked at.

snyderize2• 11 years ago

OK, I thought his was something new. Seems like the fix for these is easy -- just use the normal dosing regime for the AdBlue and everything should be fine. I'm more interested in what happens with the cars like mine that don't use the fluid, and what the performance and mileage trade offs were to get under emissions targets.

kinofcain• 11 years ago

There was a separate issue with the 3.0L TDIs (which do use AdBlue) that VW had not informed the regulators of certain modes that the engine could enter due to temperature. This looks like that issue.

"Audi also shed light on the Auxiliary Emission Control Devices (AECDs) which the EPA had earlier labeled "defeat devices," confirming that the tech was part of a "warmup strategy" for the catalyst in the 3-liter emissions control system, and was thus completely different from the emissions-cheating software found in the 2.0-liter VW engines."

http://autoweek.com/article/vw-diesel-scandal/audi-develops-...

rurban• 11 years ago

It was a Bosch ECU, not a VW ECU. VW (via Audi) just provides the a2l parametrization for the ECU.

Reverse engineering the VW electronic control unit

Related Stories