Your objection is well taken. As I pointed out earlier, the fail-safe approach to safety-critical product design is to assume the Totalitarian Law of Physics, which says that whatever isn't forbidden by natural law is mandatory: it must occur. If SEU is physically possible, then the product must be designed in such as way that it can be irrefutably proven that it will not cause a fatal accident when, not if, it occurs.
For products where no safe shutdown is possible, it must be irrefutably proven that the product will meet minimum functional requirements after SEU, component failure, external electromagnetic interference, or any other unfavorable circumstance: it must be fault-tolerant.
Probability is irrelevant in safety-critical product design.
Having shown that an SEU can kill a task does not prove it is actually the cause. But having no alternative explanation, we have a tendency to assume it must be cause. We couldn't be more incorrect. We would be 100% subjective. We are still in the state of not knowing for sure. There is no less than a Nobel Prize here for the person that can figure out how to analyze an intractable problem.
After 15 years in flight controls software, having written code for 787, 747-8, Hawker Premier, Hawker Horizon, Bombardier Challenger, I have never ever seen a test for SEU. Not ever. How does one do it? Expose the processor card to nuclear reactor and sit around waiting for it to happen? So not being able to deterministically test SEU, how can we ever now what will happen under SEU? We can't. So we fall back on probability. Toyota's software is an unfortunate example of this state of affairs.
NASA's efforts were sabotaged by certain known individuals within NHTSA from the start. After weeks of delay, the NASA scientists were given banker's boxes of random, unlabeled parts from Camrys that had not experienced any UA events. They were given '2 or 3' documents out of the tens of thousands Toyota produced for the govt. No engineering drawings. Then, just as they were getting started with their analysis and started finding questionable software design practices and tin whiskers, the guys from NHTSA seized the materials and told NASA the investigation was over.
There were witnesses to these events. Will they come forward publicly?
This is an issue that should be investigated by the U.S. Dept. of Transportation's Inspector General.
Fly by wire is done on aircraft -- and if you have flown on a 757,767,747-400,787,777, or any Airbus Airliner, you have depended on this technology from take-off to landing -- The best of these systems are Quadruple Redundant (typically three redundant actuators and dual sticks, plus redundant trim switch controls -- plus a disimilar backup system -- in these systems the power systems are triple redundant or quadruple redundant as well.
Exactly. And that's affordable on a $300 million commercial airliner. On a car, maybe a Lamborghini owner could pay for a fully fault-tolerant steer-by-wire system. Nothing less should be allowed on a public road.
Fly by wire is done on aircraft -- and if you have flown on a 757,767,747-400,787,777, or any Airbus Airliner, you have depended on this technology from take-off to landing -- The best of these systems are Quadruple Redundant (typically three redundant actuators and dual sticks, plus redundant trim switch controls -- plus a disimilar backup system -- in these systems the power systems are triple redundant or quadruple redundant as well -- (MULTIPLE apu'S AND ENGINE mount Variable Frequency Generators -- with multiple batteries and ram air turbines for backup -- 767's have even glided in for a landing sucuessfully with no fuel on board(due to metric/english conversion error by crew) ---- Automakers have no trackrecord with redundant systems and safetys for doing electronics -- it will be a long steep curve if they wish to climb it)
No need to kill everything, just the engine....leave the brakes and all safety systems intact. --
Well. This gets us into another problem. It should be unlawful to market a vehicle that has not been rigorously proven to be physically incapable of malfunctioning in such as way as to defeat the driver's control of steering, braking and power. Preventing loss of control of steering and braking is relatively easy: forbid steering or braking by wire.
Engine control is a different proposition, with engines that rely on complex control systems to minimize fuel consumption. It must be recognized that simply shutting down in the event of a component failure is not necessarily a safe failure, because being stranded in some locations can be fatal to the vehicle occupants. Thus, fail-safe principles can't be applied to engine controls; fault-tolerant design is required instead. It should be legally mandatory that before a vehicle can be marketed, there must be peer-reviewed irrefutable proof than no design fault or hardware failure can defeat the driver's control of the engine, as long as the mechanical core itself is capable of operation.
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.