"........in electrically noisy environments with connectors subjected to adverse conditions and wires flexing, the possibility that a bit might get flipped doesn't seem surprising......."
You are right to draw attention to the potential problems caused by poor electrical contacts particularly in connectors. These problems are exacerbated by the use of the vehicle body as a ground return for electrical circuits.
There is a multitude of electrical connectors in the modern automobile, each with a pair of vulnerable electrical contacts. For example an engine ECU may have upwards of 50 connectors. Designers in the automobile industry carry out exhaustive Failure Modes and Effects Analysis (FMEA) on components, sub-systems and systems and use this as a basis for the design of fault detection software. Some manufacturers carry out a 'PIN FMEA' for each electronic control unit and its associated wiring harness that lists the potential failure modes of the circuit connected to each pin and the possible resultant effects in terms of system performance. In the case of sensors, the 'PIN FMEA' covers the failure modes of the entire sensor loop. This useful approach to identifying potential problems is deficient in two respects:
1 The failure modes are identified and treated "one at a time", whereas in practice, as far as multi-pin connectors are concerned, common mode failures affecting several pins may occur more or less simultaneously. For example, although the likelihood of two sensors failing simultaneously may appear to be very small, should a multi-pin ECU connector come loose, the likelihood that several sensor circuits may be simultaneously become intermittent is quite high.
2 The FMEA method as presently implemented does not sufficiently recognise and deal with short duration dynamic intermittent faults. Faults are considered as if they will be open or short circuits and the intermediate situation where there are short duration intermittencies are not taken sufficiently into account. Intermittent contact faults in low-current sensor circuits excited by mechanical vibration will make a circuit noisy but, since the average circuit parameters may still remain within the bounds of what is deemed "normal", Electronic Control Unit (ECU) software designed to detect hard faults will not necessarily trigger diagnostic trouble codes (DTCs).
Electrical intermittencies may take many different forms, some of which might be very difficult to locate and confirm in a normal automobile servicing environment. Road-induced shocks and mechanical vibrations induced by the engine and transmission will stress potential points of electrical intermittency simultaneously.
Electrical contacts subject to vibration may become microphonic, as in the carbon microphone. Battery and ground terminals can become loose giving the potential for the generation of large transient voltages on the the DC power bus. Sensor connectors can become intermittent resulting in false speed signals and false accelerometer readings.
I use my left foot for the brake when I drive an automatic shift car. Nothing wrong with it at all, and you can gain a fraction of a second in braking response time. And no, I don't ride the brake normally, I am not an idiot.
"My father used his right foot for the accelerator and his left for the brake. It was fairly common in his day."
Might be common, but it's a really bad idea. The worst example of this is people who actually keep their left foot on the brake pedal, while driving. This risks dragging the brakes while you're driving, which will overheat the brake fluid, aside from wasting energy, brake linings, overheating and probably warping rotors, and keeping the brakes lights on so drivers behind you can't figure out what you're doing (added as the last bad effet, because it is the least destructive).
I think that treating the simultaneous application of brakes and throttle as an error condition is a great idea, myself, and it is consistent with the way cruise control works as well. Plus, it would cure drivers of that bad habit in a hurry!
As the resident test & measurement editor, I must ask, how do we know what caused the flipped bit? Was it caused by a glitch resulting from noise? Was it purely software initated? Is the condition repeatable enough to determine the root cause?
"No-one (sensible) will need to use acellerator and brake at the same time during highway driving, and it's normally expected that the same foot is used for both, and by design they are not suppoed to be used together."
My father used his right foot for the accelerator and his left for the brake. It was fairly common in his day.
Unless you design a totally benign product you should expect your code to be examined by an expert witness as a matter of certainty -- Ford and Chevy do not get to see all the code usually -- Just the expert witnesses for the prosicution and defense -- This was how $80 per share Honeywell stock of mine became $16 per share after a 757 related verdict came out that the design should not have required manual flipping of the Nav database data from one bank of memory to another by the pilot when crossing a certain line on the globe ----- In the case it was shown that other compiler vendors had the technology to automatically do this bank switching automaticaly --
@Antony Anderson: Thanks for sharing the link! I am from the industrial automation domain and I have been seeing a direct influence of the customers asking for complaince to IEC 61508 more than the regulatory authorities, which eventually has made the regulatory authorities in US, EU to make it mandatory for industrial safety critical systems. Unfortunately, in the automotive space, technology is advancing in a fast pace (electronics being used more and more) in comparison to the pace at which standards are upgraded, regulatory bodies bringing the necessary requirements/norms in, making it mandatory for the automobile industry to get their systems certified by the independent assesors such as TUV / Exida.
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. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.