We know that sensors send signals into the ECU (engine computer), and that the ECU sends control signals out; but, what goes on inside? How are those signals handled inside “that pretty little head”? Just general signal processing and response explanations would be great from our beloved Car Makers.
I haven’t found any publication (by Ford, etc.), along these lines. I did find this, dated collection, on Ford EEC-IV, and a bit of EEC-V: http://www…ford_eec_v
Actually it’s pretty simple.
It keeps in memory a table of all the possible inputs and associated outputs. There really aren’t that many sensors to keep track of, so the table is fairly small…probably well less then couple megabytes. Most people think it’s doing this heavy calculation. It’s not…all it’s doing is a table lookup. The calculations have already been determined through extensive testing and calculations before the car went to production. So the ECU just looks up the readings it receives and responds according to what the readings say. If one of the sensors is not within the range specified then a error occurs.
The hot chips you buy are not any faster computer…It just has a different values in the table to give a difference performance…notice I didn’t say BETTER performance.
Yes, there’s lots of information on the nature of the inputs, and the outputs; but, I would like to know, in greater detail, about “what’s going on in there”, how the signal is routed and shuffled, and how the response is selected, before the response goes out. I, sometimes, find it as important to know HOW a decision is made, as much as what the decision is.
I would love to find a schematic of an Engine Control Module. But, so far I have come up empty. Even in an electronic engine control class I was unable to find any literature or instructor provided information on the ECM. I did find a book in the library by a ECM modification technician that went into depth on the inputs and outputs of the ECM, the sensors, and actuators. That book did not do anything with internal electronics or schematics.
On the general plane, analog signels are multiplexed to an A/D converter. The resultant values are placed in RAM. Pulse signels like VSS, Crank Position Sensor, Cam Position sensor, knock sensor, etc. are handled as interupts in the program. I gather that they start and stop internal timers that develop count numbers that are transferred to RAM. In addition to the overhead of reading input sensors and handling timing interupts, the CPU is calculating the required injection pulse width. As stated previously certain values are stored in the table look up using axis of engine RPM and air mass indices. These values are modified by variou multipliers to derive the correct value. The value is the dropped into the declination counter, injector output port toggled ‘on’, the count down continued, and the injector output toggled ‘off’ when the count gets to zero. The same sort of calculation is being done for ignition timing. The CPU is calculating how many degrees ahead of TDC to send out the ignitor pulse and to which ignitor the pulse is going. The CPU operates so fast that it treats each cylinder firing as a solo event. It can tell if the event actually happened by the change in CPS frequency change, if there was a knock if that firing, etc. Most of the CPU time is spent waiting for an interupt to happen.
The problem with trying to find out the software mechanics of the processing is that the software is propriatary, in machine language, undocumented, and burned into PROM. The object code can be read out but then that has to be reverse translated into a useable high language. Since the manufacturers have to recover the cost of software engineering and cannot permit meddling in the instruction set because of emissions warranty, they do not let the source code and documentation out to outside vendors. So we as users cannot see much that goes on inside the brain.
I have seen technical manuals which begin with a “Theory of Operation” section. This doesn’t divulge any company secrets. It explains, in simplified terms, what happens inside the processor…be it mechanical, electronic, or whatever.Technicians need this type of information.
A “fer instance”: “Signal R goes into the A/D converter. It gets compared to stored value yy, and signals MM from their (named) sources. The resultant signal is outputted because…”
If the car makers aren’t supplying their franchise mechanics with this type of information, they are increasing their warranty load because of improperly troubleshot systems and parts.
It depends at what level you are working at,the auto tech just needs to know what’s going in and whats comming out,now the component level electronics repair tech needs to know whats going on with these signals in the component.
Pretty much any process control computer, from the humble box in your car to the ones controlling production lines in factories (or your washing machine or whatever) do a couple of things: They run one main loop which looks for sensor inputs (like crank, cam sensors), makes calculations based on the main sensor inputs (like crank, cam sensors), maybe referring to a ‘lookup’ table, but mostly using an algorithm to determine what outputs should be. The computer then outputs pulses to the ignition system, fuel injectors, etc. All the while, subroutines that the computer branches off to are looking for changes in sensor inputs like coolant, MAP, MAF, TPS, O2 etc., and these inject values into the ‘main loop’ to determine how to modify the outputs. Then there’s other inputs like from the other vehicle’s computers like the transmission computer, the body controller module, airbag sensors, etc. There may be timers the system is waiting for which cause the program to go into a ‘wait’ cycle, such as --hmm, the ignition was turned on, but the engine hasn’t been cranked within 5 seconds, so turn off the fuel pump, ignition system, and wait till the crank sensor shows some rotation is happening. Ok, cranking is detected, turn on the fuel pump, ignition system, and wait for feedback on the MAP sensor to determine the engine has started. Or OK, the engine has been running for 5 minutes and O2 sensors should be heated up, try to go for ‘closed loop’ and start including inputs from the O2 sensors, temp sensors, etc. in the engine management instead of using fixed values for some of these to deal with everything. Oh crap! the BCM says the airbag has gone off—shut off fuel, ignition, other systems, turn on headlights, dome lights, tail lights, unlock doors, send signal to “OnStar” etc. (the BCM would do most of these)
If you’ve ever done any programming, it’s somewhat obvious how some of these decisions are handled, but mostly it’s one big loop with many sub-loops, just waiting for something to happen, and taking care of business in the meantime. There are lookup tables like someone else has mentioned—some are ‘static’, like the ones that govern the engine before everything is up to temp (or substitute values for sensor inputs for “limp home” mode if a major sensor has failed), and some are dynamic, based on how the system has ‘learned’ the eccentricities of your particular engine. Eg. if you have a weak fuel pump, the system will look at the O2 sensor, running lean, and open the injectors for a longer time than normal to compensate for the problem. The computer certainly isn’t all that bright, and doesn’t know that the fuel pump is going bad, but when the “fuel trim” exceeds a certain value, it may set the MIL and indicate a code of “engine always lean” If you have a seriously clogged air filter for example, the reverse may be true, and the code may be “engine always rich” The ignition system has feedback too, and based on this you may get “misfire on cyl 3” or whatever. A failed spark plug or sticking injector may confuse the hell out of an older system–the sensors will say “too rich”, but cutting back the fuel will make it run too lean–lather,rinse,repeat. It’s kind of complex, but a fraction of the complexity of the OS on your home computer, and a much more primitive processor. Modern mechanics have to be diagnosticians more than anything instead of simple ‘parts changers’—at least if they’re any good.
Hope this helps.
I’m surprised no one has mentioned MegaSquirt!
MegaSquirt is a DIY ECM module, you build it, you program it, you adapt it to whatever internal combustion system that you want to use it with. Study up on that site, lots of documentation and a few schematics, should help you get more of a grasp on what exactly is going on.
http://bgsoflex.com/megasquirt.html
Also, if you don’t mind a Ford-only style approach, check out the Ford Fuel Injection site.
Oblivion:
I was thinking of making a reply like this but you worded it far better than I could have. Great reply!
Joe
If the car makers aren’t supplying their franchise mechanics with this type of information, they are increasing their warranty load because of improperly troubleshot systems and parts.
NO one trouble shoots down to that level anymore. Trouble shooting is only done to the component level. If the component is failing then it’s replaced. There is no need to determine what is wrong with the component…just that it’s failing.
What you’re looking seems to be the table values. Not sure that information is easily available.
Hi A good manual on the subject is “How to Tune & Modify Engine Management Systems” by Jeff Hartman, published by Motorbooks. The author goes into depth on ECM, sensor, and actuator design points. Although he does not go into the sofeware specifics, he does outline what has to be done to adapt or reprogram OEM computers to run modified engines and how to program after market ECMs to handle heavily modified engines, (think multple hours of chassis dyno time, lap top PROM emulation, possibly burning down an expensive modified engine, and a computer tech who knows software and engines.) The modifications include supercharging, cam replacements, turbocharging, nitrous, alternate fuels, fuel pump pressure boost, injector swaps, two injectors per cylinder, etc.
Hope this helps you in your research.