With 32-bit MCUs becoming ever cheaper, upgrading from 8-bit designs is becoming well worth the effort. But this increased capability has the potential to become a drawback if not applied carefully. It is too easy to add "intelligence" to systems in a way that simply frustrates and confounds users.
Earlier this week my car would not start. There was plenty of fuel, the starter would crank vigorously, and no warning lights came on. But it would never "catch." I was away from home at the time, so I was stuck for several hours and had to call upon friends, auto clubs, and a local mechanic to get me home and the car looked at and repaired. Some $500 later the failure proved to be the fault of an anti-theft mechanism built into the car. The battery voltage had briefly gone low, which reset the MCU that controlled the anti-theft function, so it forgot its pairing with my keys.
Basically, the intelligence built into the car to help foil potential thieves had turned out to not be very smart. Rather than tolerating a not-uncommon circumstance, the system took a problem and made it worse.
It's easy to add new features without considering all the possible exceptions.
A hand rolling windows is fool proof because it is completely mechanical. A powered windows can be broken due to failure of motor. Automatic door lock brings convenience. What if the battery is totally drained. Capacitive touch is a cool feature on smartphone. Would it be so cool in a car for temperature control? No doubt automotive goes electronic, the product managers shall think thoroughly to do a proper trade between features and reliability.
Sounds like my Volvo, after several such events I put some Dow4 on the connector which solved the problem. But what nonsense.
Here is another one: My new TDI VW has a pushbutton ignition that is so fast the glowplugs indicate a fault and the engine trouble light goes on.
We have to remember that some of this is simply because the programmer is asked to acomplish a task with too little information. This happens because companies don't want to take the time and money to do the testing that is needed. Result, programmer has to estimate the parameters or fails to account for certain classes of events.
Anti-theft and anti tamper devices are a common cause of failure because they are designed to lock out in any failure - otherwise they would be easier to defeat. What would be an alternative to an EEPROM memory error? Allow the user, er, thief, to reset the code manually?
You are right Battar, and by the way, all ECUs in a car are designed to stand all sort of power failures (short, very short or long ones) without loosing their configuration. This is always tested before implemetation, so there must have been another kind of failure to lead to the loss of configuration.
There was car system that had basic safety laws programmed in. If you broke your headlight, the engine would refuse to start, because it was illegal to drive with with faulty headlights. So even if it was daytime, you had to get your car towed to the garage to get a replacement headlight.
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.