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.
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.
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?
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.
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.
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.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.