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.