Slashdot Mirror
If The Problem Persists, Reboot The Car
prostoalex writes "Ever-increasing presence of high-tech devices in modern cars is a double-edged sword, the New York Times discovers. Software from different suppliers brings up to some peculiar bugs, such as a heater turning itself on during a hot summer day. In December last year ABI Research estimated that roughly 30% of all warranty issues with new cars were microprocessor- and software-related. The NYT article also quotes an interesting prediction from IBM, saying that by 2010 almost all cars will have the same mechanical systems (hardware), and the differences will be primarily on software level." (That prediction seems as accurate as the IBM prediction that there was a worldwide market for 10 or so computers.)
Actually, on my last flight, we were delayed for a couple hours on the tarmac becasue they had to "replace a part". When they put the new part in, they had to turn off and back on the plane, and they waited about 2 minutes between turning off and back on.
It was eerie sitting there for those two minutes thinking, "They're cold booting the plane that is about to take me into the air."
Pulp Audio Weekly - Geek News and Reviews
Personally, I like the way old cars worked. There is no need for a computer in a car. Old cars are easier to fix. They also cost less to fix. They are also immune to electromagnetic pulse should a nuclear bomb go off. Granted, old cars do not have all the fancy navigational equipment and automated devices.
which was supposedly "repaired" by the dealership. 2 days after I picked up my jeep, the check engine light came back on.
Rather than take it in for a $90 diagnostic fee, I found a trick: put in key, turn "on", "off", "on", "off", and finally, "on", and the diagnostic code(s) display in the digital odometer.
Take that code to google, and I found that the jeep had the same problem which was supposedly "repaired".
I took it back in, and mentioned the codes it was showing, and put up a fight with the service manager saying, "No, you will not charge me for the 'diagnostic' check, I already know what it is. It's code ABC and XYZ. Now, fix."
I concur with another reply to this comment. I find it interesting we've come to a level of quality in our technology that consumers actually expect and assume things will need to be rebooted. As for the OP of this reply, if one would be expecting and not minding a reboot as normal activity, how would one at the same time expect reliability such as "a lot of redundancy" to co-exist? If something is ill-behaved enough to likely require reboots, it IMO is equally likely to not have reliable redundancy.
In the IT industry, I've encountered people who found something to work reliably 999 times out of 1000 to be good reliability (I used to work at microsoft -- many of them considered that good). But when you start talking about my car, I really think reliability needs to be essentially perfect. God help us if we start seeing this attitude in jet and airplane technology. (If we had .999 reliability in takeoffs and landings, guess how many crashes (literally) there would be every day!)
I worked at a dealership back in 1998, right out of High School. I was amazed, on a daily basis, how far computers in cars had come since my 1979 Volvo had been made.
In a lot of cases, we could tell the telemetry on the car in the last week. Also cars adjusting themselves to the driver. (Pretty annoying when you loan your car to your lead foot mate of teenager).
Cars have, without a doubt, come just as far again since then.
I also have to agree that the mechanics of cars won't be seeing too may improvements in the next decade or longer. The real advances will come in fine tuned computer controlling of all the support systems. Fual, air, spark, all adjusted based on temp, humidity, how hard the driver is pushing the car, and many other factors.
I don't see any reason why a straight gas car can't do over 100 MPG, given the right fuel.
Pretty Pictures!
I was on a 7 pm flight this week. We say on the runway for over 2 hours while a computer on the plane was rebooting repeatedly. Finally they rebooting the entire plane, shutting everything off and then bringing the systems back up. That didn't work either. Finally they gave up, said that this had happened early in the day (!) and put us on another plane going to a different city. To make a long story short, I got in at 2 am instead of 8 pm and I could have driven there faster.
Lasers Controlled Games!
Since it's diesel, there's no ignition system. It did have an alternator, but really it was just there to charge the battery so the starter motor could run, but it came with a handcrank so that if need be, you could handstart it. I did that once. Painful, but possible.
No engine computer. No electricity needed whatsoever. Everything was mechanical.
The timing was done by a cogged system, so there was no timing belt to break. In fact, the only belt in the entire engine was for the alternator. The water pump was also cogged.
The manual had a succinct sentence in the debugging section: "If the engine is getting clean fuel and air, it must run". This was actually a bit pessimistic; one fellow I knew ran out of fuel a few miles away from home once in a flat calm and ended up pouring a mixture of turpentine and paint thinner into his fuel tank. The diesel fired up and run just fine, albeit a bit smokier than usual.
Having formerly worked for an auto supplier designing microprocessor-based control modules for the Big Three, I have first-hand experience with microprocessor- and software-related warranty returns. I would not be the least bit surprised if this 30% figure is significantly on the high side. There was one vehicle model in particular that we got an enormous number of warranty returns on. We checked each and every one of them against the mechanic's report and found that less than 2% of the returned modules were actually defective, and the vast majority of those were unrelated to software or the microprocessor. My question, of course, is whether the ABI study would include ALL of those warranty returns, or just the ones that were actually defective.
The real problem was twofold: The module in question stored all of the fault codes for the entire vehicle, and it was located in a place where the mechanic could replace it in less than 10 minutes. As a result, the mechanic would see a fault code, match it up with an easy-to-replace module, and simply replace the module storing the fault code (never mind that the code was generated by, say, the engine controller). We would get the module back as a warranty return, and the mechanic would go on looking for the true source of the problem. I understand that certain expensive components are purposely made horribly difficult to replace so they won't be returned unless there truly is a problem with them.
This is not to say our software was perfect. We once discovered a bug that would reset the odometer if you took the right combination of actions. It was a very unusual combination of actions, but the bug was highly reproducible.