I am not from Indian decent, and recent the comment that Runko posted. Before you expeculate that the origin of Toyota's firmware I wouold be more careful on the making such trivial assesment. In this case there is more than simple firmware in question.
I would like NASA team to do a good exploration of all possible causes, including hard to duplicate gamma radiation, or alike.
Please lets keep negative racial slurs out of here!
I have a Toyota Avensis with Cruise Control and as you would have expect application of the brake or clutch results in it disengagment.Now this seems to suggest that the necessary sensor inputs are available to detect this state so it seems unbelievable that Toyota Software Designers would not have put a line of code in that said :
if (brake applied)
Presumably they will make their source code available to NASA.
It aint Rocket Science!
My wildest guess (yes, it's a guess, what would you expect ?) : this is EITHER
- a threading issue (a tough one, though; less likely), OR
- some FPGA that's not temperature-proof (more likely).
If turning the software inside-out by a complete testing battery reveils no mistake, then firmware is likely to be the guilty one.
When you think you store A, but in reality B is written by the firmware, you may have that well defined software requirements tested by any that-well-thought testing battery, the guilty component will never be found by your tests if you stick to tests not using the real hardware (and most don't).
I had such a case while developing a MIL-STD-1553B ACE chip driver, and needed all my capabilities to persuade the hardware engineer that his design acted erroneously. Only after really having gathered and having shown him my findings, testing during over a week in different and varying temperature conditions made his VHDL design flaw reappear. Helped by the logic analyser (and only it).
I can imagine that such testing conditions aren't available everywhere. This, eventually combined with a strong "time-to-market" pressure ...
Maybe I'm wrong, but if I'm not, you may pay me the beer ;-)
I think this whole Toyota debate has gotten ridiculous. Cars have always been dangerous. Car manufacturers withdraw cars from the market ALL THE TIME, for similar life-threatening faults. I can count to nearly ten such withdrawal occations, and then I'm not even interested in cars. Cars rolling over when you turn the wheel too quickly, or cars suddenly catching fire randomly for mysterious reasons, cars that turn into death traps upon collision, airbags that kill babies etc etc.
This debate really stinks of car industry patriotism, where some broke car manufacturers in the west desperately need to direct media attention elsewhere. I can't see any other reason why this case is singled out from numerous of similar cases.
But if it is about the Prius cars : the Prius is a hibrid car . Its "throtlle" is not controled at all by the accelerator pedal. This pedal controls the electric motors (indirectly , of course). The gasoline engine is controled only by the main computer when it is needed . Am i wrong ?
A power button looks like a bad idea to me because it relies on the firmware running correctly to work.
How many people have had a PC lock up and holding the power button does not cause a shutdown, so they have to switch off at the mains?
So the only immediate short term fix is to remove the fuse box cover, add a cord to the engine management fuse with a note saying in the event of an emergency pull cord.
This looks to me like an improvement in the failure modes and effects analysis is required at the design stage.
"Turning off the ignition will NOT work because the Prius does not have an ignition switch. It uses a "Power" button (computer controlled, obviously) which is disabled while driving. "
This is incorrect! And unfortunately copied by journalists all over without verification or any simple research...
All Toyotas equipped with a power button instead of a conventional ignition key, will switch off (or to be more precise: power down to standby mode) when the power button is pressed for more than three seconds.
Such models with a 'car key' (or 'fob') that must be inserted will *not* enter into steering lock mode when the power down is activated, unless that key is removed.
Models with a so-called 'smart key system' are not equipped with a steering lock mechanism at all.
Braking and steering is still available when the car has been powered down, but obviously power steering and brake assist are no longer available.
The older drivers will certainly remember how that feels: when they were young those 'luxuries' were unheard of in the average car... ;)
In both "power button"-models the car can only be restarted when the brake pedal is firmly pressed and the car has stopped completely.
Hope this clarifies that issue...
it is hard or impossible to solve intermittent unknown states that cannot be duplicated.
Is the design fail safe per mil std requirements?
Is their a return to zero throttle default in the code for each cycle execution?
If all conditions are not met then RTZ is defaulted to.
Is there a safety over-ride condition that must be met to allow a non zero throttle setting each cycle?
Like a braking action, a large rapid braking action, multiple breaking actions, any of the above should force RTZ or it is not fail safe.
was the response time to excessive for the cheap 8 bit? micro that was forced on engineering by the MBA's when these type of features were included in prototypes?
same story different company...
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.