|
http://www.circellar.com/archives/priorityinterrupt/237.html Priority IntErrupt Issue #237 April 2010 If you drive a late-model car these days, it is probably “drive-by-wire." What this means is that there is no cable linkage between the accelerator pedal and the carburetor or fuel injection system, no unassisted fluid mechanics connecting the brake pedal directly to the master cylinder, and no mechanical linkage between the shift lever and the automatic transmission. Instead, there are sensors under the pedals and switches under the shift lever that transmit force and position information to an on-board computer that coordinates all this to physically control the real brakes, real motor, and real vehicle. Step on the brake or shift into drive and pray that the guy who wrote the software was an MIT grad. As I'm writing this, all the insanity about floor mats under the accelerator, adding shims or whatever to sticky pedals, and about a hundred other car problems is still going on. For Toyota, it has become the problem of the day and then the fix of the week. While nothing has been entirely solved as of yet, I was glad someone in the press finally asked whether all the electronics in cars could be causing some of these problems. That question made me smile, perhaps because I'm an electrical engineer and I know that "secure electronic control" is an oxymoron. Engineers only design perfect circuits and write perfect code, of course, so it has to be the floor mats and stupid drivers. ;-) I started thinking about all the rest of the electronics I depend on like my router, webcams, home control system, etc.—and my experience with them. Anyone who thinks that electronic stuff works right all the time is nuts! When I spend a few months at the cottage, I depend on all the electronics at home to keep running smoothly. My experience is that if the device can be even remotely described as "electronic," it will hang up, screw up, or bite the dust at some point in that few months. It might be EMI from a lightning strike, transient spikes on the power line, or incongruous inputs causing just plain gotchas in my control software, but it does happen. The typical failures I experience with commercial electronics aren't just dead failures. More often than not, they just stall or get stuck in some aberrant operating pattern. It seems stupid that modern commercial hardware doesn't seem to know it isn't working properly and reset itself, but it doesn't. Rather than wait three months to clear a stuck router or video server, I chose to rely on tried and true brute force. I use a bunch of electromechanical timers on the power lines to turn the devices on/off/on once every 24 hours. It doesn't keep a web camera from hanging after the thunderstorm today, but it usually fixes it for tomorrow. I speak from experience on this subject. One poignant example was many years ago when Circuit Cellar columnist Jeff Bachiochi and I designed an electromagnetic bug-repelling device for a customer (who subsequently sold a million of them on The Home Shopping Network). To make a long story short, it used a single-chip microprocessor to pulse an electromagnetic coil. As you might expect, when manufacturing a high-volume device, cost goals determine the trade-off between satisfactory operation and bullet-proof safety. For example, we could use thinner wire and cheaper plastic bobbins because the coil only experienced 5% duty cycle and rarely got hot. Fortunately, just as we were about to send the design out for production, we experienced a transient on the test bench that locked the processor into a 100% duty cycle on the 120-VAC coil. I can't remember which of us got to the fire extinguisher first, but it was quick. The reality was that we had designed a device that satisfied the customer's specification, but we hadn't thought far enough to make sure what happens (or doesn't happen) when it only meets those specs. Fortunately for us, the microprocessor we used had a watchdog timer on it so a quick code change eliminated the chances of 100% duty cycle for more than a few tens of milliseconds. Cars with dozens of networked processors are a bit more complicated and I'm glad I'm not the one responsible for making this mess work correctly. Given all the sensor, switch, and electromagnetic device coordination, I can't help but feel that somewhere in a million lines of control code the likelihood that someone missed a biggie or two is better than even money. Hence, 100% gas pedal duty cycle! The irony of all this is that car electronics is extremely sophisticated and drive-by-wire cars that are computer-controlled to go should just as easily be computer-controlled to stop. Just like my cheap plastic bobbin that depended on having less than 20% duty cycle to stay safe, many American and Japanese car manufacturers simply depend upon having brakes that can out-power the motor and stop a runaway car rather than using more sophisticated (costly?) options. German cars, like BMW, simply have a couple more sensors and software that inhibits conflicting control inputs, albeit a rusty gas pedal or a misplaced floor mat. If you step on the gas and brake at the same time, German cars say verboten and give priority to the brake. In my opinion, successful embedded control design isn't always just about making something work correctly. Good designers take the effort to make sure it can't work any other way! Perhaps Toyota concluded that a $2 sensor on the brake or gas pedal was too much to add to millions of cars, but it sure seems that some simple code that said, "press the gas pedal or press the brake but not both (at greater than 30 mph)," might have solved some of these problems a long time ago. In the meantime, while they continue to figure it all out, I'll just go enjoy my BMW. Of course, such satisfaction only goes so far, since it is parked next to my Toyota. ;-) |
