My prediction three days ago appears to fit the facts! I just saw a news report in which the GM key in the ignition had a long slot across the head which enabled the other keys hanging on one side of the key to create the torque to turn the key from the "ON" [horizontal] position to the "ACC" position in which the key head is vertical.
The light torque required to turn off the GM ignitions and the drivers' heavy keychains have been widely discussed in the GM car crashes. What has not been discussed is the angle of the key in the ignition and the shape of the keyring holes in the keys. These two factors should also be considered to prevent accidents.
[A] IF the key has a long keyring slot across the head of the key, then if the key chain slides to the edge it may have additional leverage on the keyhead and increase the potential torque on the key to turn off the engine. [B] IF the keyhead is vertically oriented when the car is driving, the keychain may help hold the key in the "ON" position whereas if the key head is horizontal when the car is driving, the weight of the keychain may tend to pull the key into the "OFF" position.
These factors should be considered in future ignition configurations to avoid designs which are at risk of failure.
There is little or no evidence to suggest that Toyota engineers knew of any such failure mechanism and failed to address it.
We can certainly agree on that. This is not to say that the problem may not exist, however. If the problem is bogus, then Toyota is free to counter-sue, after showing why the description by Barr was bogus. We have no reason to believe that Barr was spreading falsehoods, as of now.
However, an expert witness paid to go through the tens of thousands of lines of code with a fine-tooth comb to find a problem - lo and behold - found a "problem" and managed to convince a (presumably) non-technical jury that Toyota was at fault in one case.
Correct. And since unintented acceleration reports for Toyotas were statistically larger than from other auto companies, it is certainly not beyond belief that this problem is real. I wouldn't be a bit surprised if Toyota has taken this input seriously, to determine whether the problem is verifiable. That's what I would do, for sure. It's very possible, with thousands of lines of code, that something was missed back when. Previous attempts at bombarding these cars did not look in depth at the code itself, just the effects. A fault in the logic that only rears its ugly head rarely can certainly have been missed.
Again, it is beyond me why we are even going on and on about this. When safety critical mechanisms are being questioned, it's inconceivable to me that anyone would gladly ignore the problem. You have to show that the logic is correct as is, or you develop a fix. It cannot be so difficult to show that task X death cannot possibly create a false throttle command.
"A "hypothetical failure mechanism" that is known to exist must be addressed."
There is little or no evidence to suggest that Toyota engineers knew of any such failure mechanism and failed to address it. A team of NASA engineers tasked with finding such a problem found no such failure mechanism. An objective look at the statistical data - adjusted to correct for the floor mat problem and the "publicity effect" - does not show Toyota having a significant problem in this area relative to that of other auto manufacturers. However, an expert witness paid to go through the tens of thousands of lines of code with a fine-tooth comb to find a problem - lo and behold - found a "problem" and managed to convince a (presumably) non-technical jury that Toyota was at fault in one case. Certainly if this is a theoretically possible issue that can be addressed, I would expect Toyota would update their software accordingly. But given the weight of the evidence so far, it does not seem that Toyota deserves the excoriation it has received here in articles and threads on this topic.
"If you can show that the "hypothetical" actually CANNOT occur, that would be a different matter."
Of course. But the burden of proof is on those making the claim. Proving a negative is likely to be far more difficult - if not impossible - than actually proving the initial claim.
In the Toyota case we are not talking about a "known mechanism of failure" but a hypothetical failure mechanism that has yet to be demonstrated to have occurred in reality
I'm not sure I even understand why insist on this.
This same sort of thing happened to me. I wrote a control system algorithm that was supposed to work in a particular way, to be able to withstand two simultaneous failures. During testing, I noticed that it wasn't implemented the way it was meant to be.
Were there any known failures in the field? No, not yet anyway. Did I just forget about it? Of course not. How ridiculous would that have been? I wrote up the problem, its potential effects, what it would take to fix it, and passed that up the chain.
It's entirely possible that the floor mat problem masked other problems. Pedal positioning was not mentioned as a possible issue in this case, so it makes no sense to invent an extra mechanism of failure. A "hypothetical failure mechanism" that is known to exist must be addressed. If you can show that the "hypotehtical" actually CANNOT occur, that would be a different matter.
"When designing anything that is supposed to be safety critical, you cannot allow known mechanisms of failure to go unaddressed."
In the Toyota case we are not talking about a "known mechanism of failure" but a hypothetical failure mechanism that has yet to be demonstrated to have occurred in reality or even assigned any probability of its occurrence.
"Statistically, it was shown that the Toyota unintended acceleration problem was far worse than occurrences from other companies."
Some of this can be attributed to the floor mat issue or pedal positioning, as you point out. And, no surprise, Toyota UA-related complaints shot up after the massive publicity about the issue a few years ago. So the statistical data does not appear to be nearly so cut and dried:
If a WDT is triggered yes restart. But no restarting if some protections are lost could result in all protections being lost or even unpredictable conditions to occur. In a single channel system such as the Toyota car's restarting at the first sign of an OS fault or other problem that doesn't stop all protections is better than rebooting into an unknown condition and maybe fixing the problem. There is no secondary/revisionary channel to take up the task if a CPU would run into an error and sometimes ignoring errors is normal. In medical industry errors and internal faults are not to cause a device to reset unless it catastrophically fails to operate if there is some remaining functions then it should be upto the user to reset the device or continue using it in a degraded state. Think about a heart lung machine rebooting while it is running and it shuts off everything during a reboot cycle and loses all the parameters and starts up blank. Better try to deal with the fault as best as possible and keep as many fail safes that may still be working than kill them all and risk having nothing after. It is better to limp to the side of the road than to potentially stall the engine or cause other unpredictable effects should the restart not succeed.
The problem with your suggestion is some "expert" who I don't really think carries all that much weight with a group named after himself with him being the expert witness and some questionable programming advice sprinkled everwhere online. His books also are topical at best and as some reviews state just wrong in general or not applicable with dev kits highly overpriced or not even manufactured anymore. (One of the best review quotes for the embedded systems dictionary is that it is suitable for managers..., not that google can't do that for you) A self respecting engineer would look at this and say there is no evidence of a problem with the ECU and if it really is so hard to maintain why fix something that ain't broken (They might end up causing more bugs and actually break something). Sure maybe it doesn't fit his coding standards but juding by what he posts online he doesn't fit the coding standards of others as well. He views optimization tricks and workarounds that are useful in various situations and horrible advice and never should be used similar to saying Goto is blanket evil when what is assembly have a lot of.
Toyota hasn't recalled the ECUs and there isn't any statistics I know of that actually prove that there is a problem the media inflated self reported incidents are not a hard statistic. (The EDR reviews are)
GM did replace the part years ago they tried to hid it replacing it would involve a recall. They didn't do this till now and using a dealership alert isn't what I call replacing a part it is called covering up a big management and engineering fail on a scale so large it makes an FADEC tearing a helicopter apart look like peanuts when they couldn't get a simple dedent to work as they intended. (There isn't even a single piece of electronics in the dedent mechanism itself and you can't have BUGs in a mechanical part. They knew it was out of spec, they knew it caused deaths, and they knew it needed to be recalled.)(Toyota would be commiting many countless crimes if they covered up the ECU fault and juding by how their internal emails are floating around I'm sure they were not aware of any catastrophic bugs if they existed or not)
Show me actual EDR statistics pointing the finger not at the driver because the self reported numbers if you know anything about statistics are affected by more than just it being unreliable (The media factors hugely into those self reports, hard statistics needs all the variables controlled for and an EDR report is consistant, quantitative, and objective) The self reporting system is an indication not proof.
You should accept the possiblity that an expert witness hired by the platiff sueing Toyota for millions in damages may be slightly baised to say the least. The DoT and NASA have no interest in Toyota's sucess arugably as a forign company they would like GM (also partly government owned) to suceed and maybe thats why the national highway regulators didn't make more of a fuss about some really strange EDR reports with no air bag deployements and complaints about stalling cars going from on to accessory or even off.
Also it is clear that your ignoring the differences that I directly relate to this article and countinue to ride on how similar GM's mechanical defect is to Toyota's supposed software defect I have no choice conclude that you have placed your crediblity and worth in the hands of another unknown expert based on unpublished reports and unverified testing.
I neither believe that Toyota, GM, Boeing, Airbus, any programmer can write bug free code and that they all hopefully tried as hard as they code to write safe code within the best of their ablities and that in Toyota's situation real world statistics appear to favour their opinion that it is drivers at fault while in GM's case it is clear that it is not the driver's at fault as keeping keys on a keychain isn't something the manual says not to do. (The GM situation has nothing to do with electronics and everything to do with managment/engineer/supply chain failure)
Attempting to refer to Toyota's supposed overly complex ECU bugs isn't remotely similar to GM's known non-supposed simple glaringly obvious mechanical defect in a simple part that went unrecalled for 10 years and had many deaths/injuries directly attributed to the fault to date in real world statistics and EDR records.
Answer this, GM has EDR reports that point the finger directly at the cause and Toyota doesn't, why are they both on the same level of coverup?
Assuming your right and the ECU buggy mess it doesn't cause errors then Toyota/Regulators wouldn't have known and the difference in the article is that GM knew it was clear as day for 10 years. (Silently fixing something and not fixing every affected car can't be considered "problem solved")
Real hard statistical reliablity in real world testing will always trump theoricial reliablity (Saying it might be unreliable when it isn't really isn't a factual statement). If you say a part can only last for 10 hours in use due to advanced FEA modeling showing a clear defect in the design but 100% of your customers used it for 10+ years ignoring your unproven model and no failures or even indications of failure occurring which one is correct. Debuggers inducing a percieved bug doesn't prove a bug exists as already mentioned without access to the technical details of their test and other groups not reproducing the same results it can only be concluded that your theory is wrong.
Vaccum assist works even at full thorttle it just won't recharge. If a user claims they pressed full down on the break then the car will stop with minimal effort and a forceful stop can occur. Even if they don't read the manual or understand basic car tech a depleted vac assist doesn't stop the user from slowing the car down safely and a runaway condition only occurs if they don't do anything or are actually pressing on the accelerator. It has already been proven that the pedal sensor for the brakes show that it wasn't depressed in the EDR reports so nothing was even trying to stop the car and the braking system is not even electrical (the ECU has nothing to do with it and is another layer of protection on top of a number of other simple defenses against a rouge ECU that hasn't even been proven publicly) The EDR records brake pedal position and almost all cases had them slamming hard on the accelerator (pedal misapplication).
The most basic point remains in that the unpublished, not-repeated, unverified "expert" theory on what happened did not happen in real world situations. Drivers have a responisblity to know how to turn off their car, use the neutral, and press (not pump) the brakes when needed, and of utmost importance in not mixing up the pedals (Pilots of planes are expected to know what to do if the autopilot disconnects and that doesn't involve entering a unrecoverable stall by pitching up maxiumally when the clear thing all pilots should know is to pitch slightly down to exit a stall regardless of lost or confusing sensor readings gravity/aerodynamics basics don't change).
Experienced drivers can use both pedals at once and brake override is a "noob" feature which doesn't even help if the driver doesn't mash both pedals which as shown in actual EDRs is almost always just them slamming the accelerator to the floor and a pedal override wouldn't help. (it is just to platacte people).
Your bias regardless of what you claim is so apparent it is surpising you need to state that as the poster your replying to never implyed any of that, who here ever claimed your biased to GM or Toyota other than yourself now. I don't care about Toyota and I don't own stock or even own one of their cars I just find it appaling that according to your profile pic a Principal Engineer at Boeing Defense Systems thinks a supposed ECU bug is somehow similar to a switch detent being off spec. (linked in is a bit creepy I must say but its in public space so fair game)
Care to chip into to how you think Toyota's ECU is similar/different to the Beoing Chinook disaster. http://www.ccsr.cse.dmu.ac.uk/resources/general/ethicol/Ecv12no2.pdf
Because I think that case the first thing I searched up on FADECs (jet engine eq, ECUs) was that and I was surprised that boeing would ignore their own internal testing resulting in some catastrophic damage to the test helicopter's due to obvious control system bugs (no monitor CPU on the sensor lines to idle the throttle control so it instead went to 100% and would have and did later self destruct the entire drive train and frame in flight). I dunno but when the CPU arch is switched entirely and obviously a total rewrite occured it is pretty clear which case had bugs and which didn't. (Toyota never swaped the ECUs out and no recall and no further cases and there were likely none to start with in regards to an ECU bug).
Get me the actual report and then I will consider it but making random points without backing it up with any information isn't proving anything. Induce the bug in an actual car without a debugger and prove it publicly on tape with EDR. Compared to the miles driven the probablity of this supposed bug is slim to none and we don't even know what it is that they are changing in the debugger or what the task is called. It definitely isn't an app I can tell you that much it probably is the entire ECU program and in C.
Interesting comments from him when he suggests using a division operator when the mfg specifications specifically states not to do it and the resulting compiler madess to accomodate something like a divide on a platform without a division or multipler results in horribly unoptimized code. Using maximum sized variables is a waste of space especially on highly RAM constrained systems, sure on a x86 or ARM processor don't even bother doing hand optimization but on a tiny 8 bit memory/flash/cpu starved micro not doing hand optimization and assembly tricks and just letting the compiler deal with it is not going to work. He ignores 95% of the embedded systems out there by suggesting readiablity above all else as many products can't even afford to add extra resources just to keep readable code around (C++ on an 8bit?, C# on an 8bit???, python?, .......) In all those it makes sense not to attempt hand tweaking (not that intel IPPs don't do that in spades).
Barr's wikipeida article reads like an ad and the cross editing is a tad suspecious and I sure hope all those editors are revealing their potential conflicts of interest before modifying a public encylopedia add paragraphs in every UA article about how the ECU is buggy. Strange that they haven't pounced on FADECs.
Rebooting a ECU while the engine is on is dangerous and it isn't just a PC computer running an engine.
I strongly disagree. A safety critical ECU that crashes should definitely be rebooted. That's why one uses watchdog timers in such circumstances. Of course, the reboot time has to be specified appropriately, and it typically is.
If any self-respecting engineer discovers a problem such as this one, even if the event had never been known to happen in the real world, the right thing to do is to patch the software sooner rather than later. This is actually standard practice in control systems.
My bet is that Toyota either has or soon will do so. Toyota won't want to advertize that it has fixed the problem, because that would be tantamount to admitting a problem was there at all, but they could include the patch among other updates to the ECU software.
GM doesn't have a control system fault they have a mechanical switch design fail that they knew about and didn't correct for 10 years
As the article explained, GM had replaced the part years ago, and thought the problem was solved. But once again, I cannot understand bending over backwards to make excuses for one company and not the other. In both cases, issues had been occurring for 10 or more years. In both cases, the absolute number of problems was tiny, compared with their entire fleets of cars. Statistically, it was shown that the Toyota unintended acceleration problem was far worse than occurrences from other companies. So I'll accept that perhaps Toyota was concentrating too much on the carpeting explanation, and not looking more closely into software problems.
Showing that something is possible is not the same as proving that it actually happened.
While that statement might be true, it's beside the point. When designing anything that is supposed to be safety critical, you cannot allow known mechanisms of failure to go unaddressed. That's what "fail safe" means, after all. This holds true for GM and for Toyota. Most of the time, you have to demonstrate that it takes at least n simultaneous failures before the unsafe state can exist. Very standard engineering practice.
The drivers in all of these cases claim to have been fully alert and pressing fully down on the brake pedal.
True. And sometimes, due to the positioning of the pedals, it was determined that they actually had their foot planted firmly on the throttle and not the brakes (this applies to Audi back in the 1980s). Other times, such as in the Toyota case, it was instead quite likely that the brakes were not working, or that the vacuum assist was not (due to the full throttle command), and that therefore the driver needed to apply a whole lot more brake pedal pressure than they normally would. Such an event could easily be construed as "the brakes were not working."
The basic point remains, though. Faced with an extraordinary set of circumstances, many, if not most, human drivers do not react properly. So while it might be true that the driver "should have" done this or that, the reality is that many or most drivers don't.
I feel no compulsion to take sides with or against Toyota or GM, in these cases.
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.