So I’ve known for a while that modern cars, at least ones sold in the US, come with engine control computers that perform a “tune up” several times a minute. Effectively, the system is set up as a feedback loop where various sensors in the car submit inputs to the computer, the computer processes those inputs according to a defined algorithm/business rules, and the computer outputs changes to car settings such as ignition timing and amount of fuel injection to attempt to bring the next cycle of inputs closer to what is desired. If an unacceptably out of range sensor value persists after a sufficient number of cycles, the computer throws an exception and pops up the infamous “check engine” light.
I can find information online about OBD-II engine trouble codes and the fact that there is a standardized interface to connect your own computer to download the trouble codes. What I’m not finding is information about the architecture of engine control computers themselves.
Are the internal computer architectures of engine control computers standardized? For example, do Toyota engine control computers run a proprietary Toyota operating system and control software on Z80 processors, BMW’s made between 1990 and 2003 run Seaside Software’s Engine Pro on Macintosh System 6 on a Motorola 68k processor, and BMW’s made 2004 and later run Microsoft Engine 2003 software on Windows XP on a Pentium 3? Do car computers even have operating systems as we know them or do they normally run embedded single purpose software?
Are there differences in the engine IO system (sensor input and engine tuning output). Can you e.g. take the computer out of a 2003 Volkswagen Passat and hook up the inputs and outputs to the engine of a 2002 Ford Focus and expect it to just work, or are there differences in the interface with the engine that would cause problems?
Why do you never hear about car engine control computers crashing? E.g. “I was driving to work the other day when my engine started to backfire. I took it to a mechanic and he said that the engine control computer had crashed. He rebooted it and it’s working fine now.”
Can you upgrade your car computer to improve mileage, performance, or longevity? E.g. “I got an extra 10MB of RAM and a math coprocessor chip for my 2010 Toyota Corolla. The computer detects this extra RAM and uses it to run more sophisticated simulations that allow it to more finely tune settings to reduce wear and tear.”
The answers to 3 and 4 is that yes, they do occasionally fail, and expensively so, and yes, you can “reflash” the computer, changing the parameters for better performance at the expense of voiding the warranty.
The rest? The computers are different, though in what way I don’t know precisely, and no, they are not interchangeable.
The software on automobile computers isn’t anything nearly as high-level as consumer computer operating systems (Windows, Mac etc.) They’re more on the order of industrial control systems. Consequently they’re very hardy & robust, both software and hardware wise, because they’re only as complicated as they need to be, and they’re designed from the ground up to interface with very specific, never-changing hardware. And they are rigorously tested. Car computers do fail, but it is very rare. Nothing even close to personal computers crashing or failing.
Computers that are used for engine control are called “Embedded” (they don’t have a User Interface, and are expected to run forever without intervention). Embedded processors that need real-time responsiveness often have no “operating system” at all (they use a simple event loop to do everything), or they may have a Real Time Operating System (RTOS) that guarantees some maximum response time. There are a lot of players in this game. Green Hillsis one. Here’s some information about an effort in Japan to standardize on an RTOS.
No way. The firmware in each controller is tailored to the specific characteristics of each engine - timing, sensor inputs, fuel consumption, mass flow, etc.
Currently, most cars have a dedicated engine controller. This is a well-tested device, and the firmware is straightforward enough that it’s unlikely to crash. However, there have been some moves towards making a fully multi-tasking computer which controls all aspects of the car, and this will be complicated enough that crashing will be a real issue.
People have messed around with the firmware in fuel-injected cars for ages. Usually it’s for better performance, though.
no. they have “operating systems” in the sense that they have blobs of code which dictate how they work, but they don’t have operating systems in the sense of a user-interactive system.
no, you can’t do this.
two reasons- 1) by the time the car goes on sale, the powertrain management code is validated, and 2) the powertrain control firmware is relatively simple compared to desktop OSes or software. The firmware in a powertrain control module has a very specific job to do; the software on your PC, tablet, or smartphone is much more general purpose.
you can move stuff around, but any gains in a particular situation are going to be at the expense of other situations. see, with your PC, adding RAM or a faster CPU lets your software get shit done faster. With an automotive PCM, it’s still controlling a mechanical system. “chipping” a PCM can do things like increasing peak HP but there will be trade-offs like requiring premium gas or a loss of low-end power.
You never hear about them crashing (and being able to be rebooted), because even though we call them “computers” they are not anywhere near akin to the computers we use at home and at work. They are microprocessers. They don’t “crash” and they don’t “reboot.” They can fail, but that’s a different thing.
Just out of curiosity, don’t some ‘chip’ reprogramming changes also require mechanical upgrades like say a higher compression ratio, more radical cam profile or something like that? Thanks.
Pretty much each car company uses proprietary software. The hardware is tailored to the individual car company’s needs. This applies to both board/processor speed/design/physical package and software. The one exception to this is some European companies use Bosch Motronic systems which may be similar, but not identical across car brands.
Well first off, you can’t plug the VW computer into the Ford, the connectors are different. Secondly the input and outputs are different. One car might have a hot film MAF, the other a hot wire MAF, one might have a 5V reference voltage, the other 10V.
Now could you take all the sensors off one car put them on another car, rewire the whole mess, hook it to the new ECU and get it to run? Probably, but I’m guessing it would run for shit, as it is not optimized for the new engine.
Well first off they are very robust. No video, no sound, so there is tons less code than your PC, so crashing is has a much lower chance of happening. They will sometimes back themselves into a corner, where they won’t do quite what they are supposed to do. Disconnecting power for 5 minutes to a couple of hours will usually get them back to responding. A cold boot if you will.
Contrary to what the guys selling chips will tell you, the factory engineers actually do something between coffee breaks. The engine is an air pump, unless you get more air in, you are not going to effect power much if at all with a chip. Now if you have a turbo with electronic boost control, you can get a lot more power out, at the expense of reliability.
The engine management computers are a lot more powerful than a simple Z80. They are often proprietary CPU designs that are pretty heavily customised to purpose. The IO capabilities are quite complex, as they need to talk to a lot of systems in the car (although absolute data rates are quite low.) The typical communication is over CAN or FlexRay. The designs may have specialised hardware to control synchronisation of code elements with IO operations - addressing both performance and concurrency.
As noted above, the software is embedded, and real time. The software writers take extraordinary care over the code. The sort of stupid race conditions and other concurrency issues that beset ordinary computers are rooted out with great effort. Hard real time systems require certain limitations on design as well. Caches can cause uncontrolled variations in execution speed, and must be either avoided, or used with great care. Such common features as demand paged virtual memory are unheard of.
The ECU is usually part of the stability and ABS system, and will respond to commands to override the throttle from the stability control system. This gives a sense of how safety critical these systems are. Some cars will poll the various control computers each time the car is started, and they exchange IDs - and the car won’t start if the IDs don’t match - making cars built up from stolen components very hard to create. All these intercommunications between systems are proprietary, and specific to a manufacturer.
Although you can’t transplant ECUs from one brand to another, it is common to discover that the same ECU can be used in many cars from the same manufacturer, sometimes with as little as a set of switches, or an external programming selection made over CAN bus control, that selects the right model. This also allows coverage of the various options and configurations and markets that the car can be built for.
The provenance of the CPUs is via the ECU manufactures. German cars tend to use Bosch, Japanese use Denso. But the actual CPU can be from companies like Reneasis, Freescale, and the like.
The opposite is more like it. If you put in a “performance” cam or bodge on an aftermarket turbo, you’ll need to let the ECU know that the new components exist to get best advantage of them. This isn’t like installing a device driver for a new sound card, though. It’s more of an adjustment to parameters like setting a new upper limit on how much fuel the injectors are allowed to pass or changing shift points for the transmission.
People doing custom cars and motorcycles needed a engine control computer (or at least injection) that they could customize to their needs. So some enterprising fellows made one:
MegaSquirt That link is work safe. I do not recommend googling megasquirt from your work computer.
There are a lot of details there.
On operating systems: The overhead is huge for a typical operating system. Back in the 1990s I was doing embedded control systems that could have easily run an engine with a 12 MHz clock, 256 bytes (Note lack of prefix on bytes) of RAM, and 64KB of code space. Yes, it all needs to be in assembly code, and it is a witch to debug sometimes, but you can really make these things hum when you ditch the bloatware. The stuff now is serious overkill, but it allows for easier to maintain code and teams to collaborate on the code. When you need to wring the last drop of performance out of the hardware, it pretty much has to come from one mind, and finding the right mind may be difficult.
If you do have a real time operating system, they all have one key trait: Everything runs out of RAM. Typical general purpose operating systems use virtual memory systems, that keep swapping chunks of RAM on and of disk. This causes large and variable time delays, and there is no way to get acceptable real time performance.
Engine control systems typically use a microcontroller rather than a general purpose microprocessor. Microcontrollers have a lot of peripheral functions built-in, and this saves a lot of development time getting various chips working together. It also saves board space and can improve reliability. In many cases, microcontrollers have enough memory built-in that no external memory chips are needed, as just one example.
Interesting answers. What about the other direction? I know someone who might be junking a 15-ish year old car soon. The car is rusting in several places, has mechanical trouble too often, and doesn’t get very good mileage but I assume the ECU is fine. If we yank it out before sending the car to the hereafter, are we likely to have an interesting microcontroller that we can reprogram as the control system for an automatic plant watering system or pet feeder or are the specs so proprietary or ill-documented that a decent programmer and electrical engineer would say it’s too hard, chuck this thing and buy a microcontroller from a hobbyist shop?
QFT. I had the main control computer chip go toes-up in two different cars (both of them Chryslers). Both times, it was several years into the car’s life, and the chip just simply died. Not a cheap fix, and, in one of the cases, the car was no longer under warranty.
In the first case (an '87 LeBaron), the new chip which the dealer installed then proceeded to do the same damned thing 20 miles after installation.
a PCM is not really a general-purpose microcontroller. You’d have to hope that it has the output signals you need, you’d have to hope it’s an off-the-shelf MCU inside there (and even if it is, it might be re-marked to obscure its origin,) you’d have to hope to figure out how to “talk” to it; many are flash-programmable but you still need to know how to communicate to it and figure out its memory map, and so on.
For simple automation tasks like you mention, better to just drop $30 on an Arduino kit and go to town.
I always had the impression that they weren’t really a set of complex algorithms run on a CPU so much as a system of somewhat complex lookup tables that used sets of particular inputs to find values.
So for example, if there’s X amount of air entering the engine, the engine is at Y RPM, the intake air temp is Z, and the timing is AA degrees advanced, then those values are looked up in the injector pulse width table as X,Y,Z,AA, and a value for the pulse width is obtained and used.
Even where look-up tables are used, they are usually not all that big, so the controller interpolates between entries. Rather than having a table index for temperature and another for pressure, the controller would instead calculate density, and use that as a single index. Other engines sense air mass flow directly (hot wire anemometer is popular).
There is also usually some attention to learning optimization. An oxygen sensor in the exhaust is used to build a table that tweaks the default mixture values over time, for example. If you disconnect the battery in a car, it may run a little funky for a while, while it re-learns.
Most modern cars have closed loop idle control, where the ECU looks at engine RPM and adjusts the air intake to maintain a consistent idle.
Also the ECU looks at what the driver is doing and may move between different performance mappings, perhaps optimizing for performance or economy, depending on how often the accelerator is pushed all the way to the floor, for example. It may even interpolate between two different maps if the driver is being middling aggressive, and if the throttle position is constant for a while, it will drop back to economy-cruise mappings.
Then there is the matter of detecting problems like failed sensors and trying to keep the engine running in spite of that, often called “limp mode”. Usually this takes the form of taking what you DO still know and trying to approximate data from a dead sensor. This often works well enough that the only way the driver knows there is a problem is the idiot light on the dash. Many modern ECUs will detect misfiring cylinders based either on spark plug voltage profiles or acoustic sensors on the engine block…20 years ago the processors were too slow for that.
Finally there might be some shady stuff. About 10 years ago a couple of car makers got in trouble because the ECUs were detecting the EPA test protocol and switching to a low-emission/high economy mode just to post good numbers over the test run.
As with almost everything now, there is a smartphone app that you can plug into the OBD II data port under your dash and monitor your engine output, clear trouble codes, etc.
There are several other, relatively cheap tools you can buy at your local auto parts store to access this info too. Your OBD II data port is usually under the dash board, on the driver’s side. Looks like a printer port for a pre-USB computer.
You can also purchase programs for your laptop that will access the PCM and allow you to change shift point, fuel mixtures, etc.
Whenever a major engine modification is done you need to reset some of these parameters to avoid getting a trouble light. Such as the installation of headers, modified exhaust, larger injectors, air induction, etc.
Not only can you not do this, but you generally can’t swap engines from the same manufacturer without changing the wiring harness and computer. For instance, if you were trying to swap a V-6 for a V-8, there wouldn’t be wires for the extra two fuel injectors, the computer wouldn’t know to send output to them, it wouldn’t understand the cam sensor output, etc. If the engines are similar, like going from a Ford 4.6 to a 5.4, then you’re likely to be able to keep the same computer but you would probably need to reflash it. This is assuming the engines have the same sensors and controls (ie not going from a distributor engine to a distributorless ignition engine), though in some of those cases, there are still ways of doing it without even having to reflash the computer.