"It seems to me that some cars have the gas pedal where other cars would have placed the brake pedal (everything is shifted a little to the left). This could be a contributing factor - especially if the drivers in the accidents often drove other cars with the pedals in a different relative geometry to the driver's seat."
It was many years ago now, mid 1980s, that the car company on the hot seat, for this same unintended acceleration problem, was Audi. That was one conclusion reached, back then. Pedal placement. The driver can swear up and down that he had his foot planted on the brake, when in fact he had the accelerator floored.
Here's a more general discussion of the Audi and other examples of this phenomenon, unrelated to electronic controls.
"Most of the major OS's such as VxWORKS, PSOS, Green Hills, etc should support something like this or better (possibly with an option) "
This is really the crux of what I was asking about. Trying to see if there are any RTOS vendors who advertise fault-tolerant countermeasures such as mirroring critical RTOS variables & data structures. I've haven't found one yet. If I remember Michael Barr's testimony, some of the scheduler's task lists or whatever were right next to the stack, and some of the important application variables weren't mirrored.
Will be interesting to see if this type of functionality starts showing up in some of the more heavyweight RTOSes. IMO it would be a reaction to this fiasco right here.
If one thinks about the software a bit both the OS and the OEM's code need to detect bit flips.
One way this can be done is via a checksum or a CRC. A routine or object to wrie or read each data type in the OS+OEM code needs to be created that adds this element to the type as an element in a structure or similar. If there is a checksum/crc error one must reboot or in some other manor re-test the entire memory to rule out a hard fault.
Another way might be to keep dupicate RAM entries and re-boot / retest on the mis-compare of the duplicates.
One also needs to do one of these on code both in RAM and FLASH.
Most of the major OS's such as VxWORKS, PSOS, Green Hills, etc should support something like this or better (possibly with an option)
The FAA has several good papers on reviews of safery critical systems
Do a google search for SEU SOFTWARE FAA
Also look up Byzantine Generals Algorythm for Softtware.
See my profile for contact information for further advise
Thank you, DrQuine. The testimony of this court transcript has been truly educational and enlightening to me. But even better is some of he comments I read in this forum. I learn something new every day here. Seriously.
The testimony cited here is quite remarkable. It is one think to speculate about the possibility that a corrupted bit might have serious consequences ... it is quite another to demonstrate in an operating car such a bit error does indeed have significant effects. Kudos to Junko for tracking down and publishing this very interesting evidence.
I do a lot of business travel and experience many car model in my car rentals every three weeks. I've noticed that the pedal placement varies from model to model. Has anyone investigated the positioning of the brake and gas pedals with respect to the centerline of the driver's seat? It seems to me that some cars have the gas pedal where other cars would have placed the brake pedal (everything is shifted a little to the left). This could be a contributing factor - especially if the drivers in the accidents often drove other cars with the pedals in a different relative geometry to the driver's seat.
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.