Right on, pbenjamins. NHTSA broadcasted the big lie that NASA had ruled out any electronic issues, knowing full well that NASA had done no such thing, that the space agency never said it had, and that NASA was hamstrung from the get go, complete with time limitations and incorrect information from Toyota. Embedded systems expert Michael Barr has set the record straight, and driving the point home, NASA physicist Henning Leidecker is now warning of increased risk of unintended acceleration in '02-'06 Camrys due to "tin whiskers" growing in the pedal sensors.
I was always suspicious of "NASA's" report on the Toyota acceleration study and the assumption that a NASA evaluation is irrefutable. Not all NASA scientists and engineers are of the same caliber. I doubt that the programmers that worked on the deep space probes where code has to be perfect, were the ones that reviewed the Toyota code. I also wonder if the black boxes now placed in automobiles have independent sensors for operation and black box logging. (I suspect they were looking at the same incorrect sensor input with the same resulting conclusions.) We routinely reboot our PC's, printers, cell phones, game boxes, and cable/satelite receiver boxes with little consequences. However when software controlls peripherals that can affect lives, extra care has to be taken and reviewed by programmers not involved in writing the code.
This situation is nothing new. Look up "10 historical software bugs with extreme consequences" and "A collection of well-known software failures". Not admitting that a serious mistake was made is the real tragedy.
There was 150 feet of skid marks from the plaintiff's tires. This was a MAJOR part of the trial, emphasized by Jere Beasley, founder of the plaintiffs' law firm, in a YouTube video accusing Toyota of a cover-up.
I commend EE Times for following the sudden unintended acceleration issue. Junko Yoshida summed things up quite well in her reply to one of the comments:
"...the fact that the experts' group was able to demonstrate at least one way for the software to cause unintended acceleration is a "breakthrough," at a time when the Toyota case -- up until last week -- was viewed by many as an issue of floor mat, sticky pedal or a driver's error."
The Oklahoma case is now being referred to as a "landmark," underscored by Toyota's shift to "settlement mode" after the verdict was in. Not only for the Oklahoma case, but for all of the remaining sudden unintended acceleration cases, and now there are reports that Toyota is also interested in "settling" (for about a billion bucks) the two-year-old federal criminal investigation as to how complaints of sudden unintended acceleration were handled (along with a few other niceties such as possible mail fraud, wire fraud, lying to Congress, and misleading stockholders).
Actions speak louder than words, and I won't belabor the notion of anyone being allowed to buy their way out of a criminal investigation.
But we are not trained or naturally do the correct thing when the mechanical controls that extend our senors and actuators beyond our bodies STOP WORKING AS EXPECTED the brain is running engramless, that is the brain has no textbook answer handy when the car wants to keep accelerating to the moon.
not just loss of accelerator but the worst possible kind of malfunction, full power.
I looked at these electronic foot pedal hardware and saftware packages for a school project for challenge X.
I was appalled no safety standards existed for the hardware or software for the industry, no oversight or help with safety design of these critical hardware components for the schools either.
Did not get involved further because of this fact alone...a disaster in the making.
Many solutions some or all should be used.
avionics level software and hardware certification for power control and user interface devices.
A simple big red pull pin or pushbutton override
Add drivers license training for stuck throttle driver response training.
1. A car's brakes in proper working order WILL stop the car under full throttle acceleration, whether you think it's a good idea or not.
2. There are only a handful of cars on the road that do zero to sixty in 6 seconds or less, let alone the 4 seconds you state.
3. Many attentive drivers will have reaction times less than 0.5 seconds.
4. Meanwhile inattentive/unskilled/intoxicated/elderly drivers may have reaction times in the seconds, and their reactions may also be so poor that their initial non reaction is more favorable than the results afterward.
Item 4 does not mean good drivers should not have manual mechanisms to enhance safety, although it is a strong argument for self driving cars and graduated licensing. Automated safety systems such as radar are already prevalent, and self driving cards are in test in mulptiple locations. Better get ready to face your fears.
The discussion on this story is remarkable in that apparently only a couple of commenters know that the brakes will stop the car regardless of what the engine is doing. When the plaintiff in this case claims that she was mashing the brakes to the floor but the car was still accelerating, but the brakes were then found to be fine after the incident, there is a greater than 99.9% probablity she was mistaken or simply lying.
Go back and review the claims and cases during the Audi 5000 "sudden acceleration" era. Such as the driving instructor who swore he was on the brakes, meanwhile witnesses behind the car saw no brake lights and no brake failure was found in the car afterward. Or the elderly man who was sure his foot was on the brake as he crashed through a concrete barrier in a parking garage. Sure until he looked down and saw his foot on the gas, that is. At least he was honest.
Then there was the Audi dealership owner John Morzenti, who challenged CBS/60 Minutes (Remember their show on the Audi where they failed to disclose how they tampered with the Audi's engine, and also did not apply the brake?) to a 1 million dollar bet. He said they could do anything they wanted with the engine, as long as he got to sit inside with his foot on the brake pedal. CBS did not take the bet.
"Sudden acceleration" was investigated hundreds of times in the past, and other than some minor sticky throttles (Which would not have caused the wild claims made by the drivers.) no major problems with the cars were found. That's why in this case the plaintiff's attorneys had to come up with a new strategy focused on software, and of course that strategy had to include that the black box could be incorrect. Given a typical jury of non technical people, a strategy such as this had a good chance of success. How is the average non technical person going to have any clue whether a "software expert" is right, wrong, clueless, honest, or dishonest?? Especially since people generally want to believe in other people telling a heart wrenching story, and even more especially when they are up against a large "evil" corporation.
Kudos to the people asking for the experts probablity calculations, and to Bert for pointing out how bad of an idea it is to brake with your left foot and push the gas pedal with your right. I've seen quite a few people driving this way, and I'm sure they were convinced they weren't riding the brake pedal, even though from behind I could see the brake lights remain on as they accelerated away from a stop. Of course not all 2 foot drivers will ride the brake, but being in the habit of using different feet for the brake and gas pedals will absolutely increase the likelihood of pedal errors. Stick drivers of course have to use their left foot for the clutch, but this is not a problem. If you "accidentally" mash the clutch to the floor in a panic it of course will not cause the vehicle to accelerate.
In my own experience I was driving a turbocharged Isuzu back in the late 80's. I confess that I frequently would floor the throttle to accelerate quickly. One day I did this and the throttle remained stuck after I let off the pedal. Instead of panicking, I tapped the pedal hard a couple of times trying to free what I thought was stuck throttle cable. When that didn't work I put my foot on the brake. While my stopping distance was of course a bit longer, the car did slow down to where I could easily pull off onto a side road and then easily come to a full stop. The turbo engine was wailing away, but no match for the brakes. I put the car in neutral, and then looked down to see that the very stiff floor mat was holding the gas pedal to the floor. Easy fix.
I suggest anyone who doubts the brakes find a stretch of open road, or a very large parking lot and try the test themselves. In this case do use both feet. From a stop, floor the brake with your left foot, and then try applying more and more throttle with your right. If your brakes are in proper working order the car will not be going anywhere even if you floor the gas pedal. Automatic transmissions only, of course.
One way to carry the passive concept a step further would be for the "dead man switch" to invoke braking rather than merely releasing the throttle. I believe that already exists in trains. The challenge in cars is that we have have two controls: the throttle and the brake rather than a single control that when released would return the car to a statioary condition. We also have to be careful about stopping too quickly if the surrounding traffic isn't following suit. As a minimum the "dead man switch" would do well to provide some external indication that the car is stopping. Currently releasing the accelerator does not cause the brake lights to illuminate.
One of the challenges in automotive software design is fail-safety. Ideally, you want the failure fallback to be at minimum passive, at best natural - that is, you want the path of least resistance upon failure to result in the safest outcome. That's not such a big problem with acceleration - if the driver has a heart attack, then (in most cases) his foot relaxes from the accelerator and the car at minimum won't go faster and will ultimately slow to at least idle speed. The natural course of events happens to be the best one for safety, and requires no additional effort to invokde (in other words, it is passive). Obviously, active subsystems could be applied to the situation to improve safety - invoking the brake, for example - but the natural behavior contributes to, rather than detracts from, safety.
Braking is an entirely different problem. First, because of legacy mechanical designs in cars, braking is not a passive behavior - you have to DO something. Consider that one of the scenarios in which braking would be invoked as a fail-safety measure would be in the event of system power failure. Where would power come from to depress the brake? Where would power come from to feed the electronics to compute the need to depress the brake? Complicating the issue is the fact that many power brake systems are vacuum-assisted - vacuum that goes away when the engine stops, markedly altering the amouint of pressure needed to activate the braking system. In hybrids, this is further complicated by hardware and electronics that attempt to tap the residual and excess energy being thrown off during braking.
Electric cars can be made significantly more fail-safe for braking, because the electric motors used are also generators when the stator is not being powered (and generators cause drag).
The best solution for the problem is simple, but requires a re-design of legacy technology. That solution proposes electronically-regulated electric clutching at the drive wheels, where unless all systems throughout the vehicle are optimum no forward power is allowed to pass through to the wheel, and when not expressly powered to go forward the braking systems are by default engaged.
I've been professionally writing software for thirty years, and there is no code I can imagine that could be deployed to solve the issue through electronics alone that wouldn't have bugs, and therefore fail under some condition.
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.