Slashdot Mirror
Toyota Acceleration and Embedded System Bugs
An anonymous reader writes "David Cummings, a programmer who worked on the Mars Pathfinder project, has written an interesting editorial in the L.A. Times encouraging Toyota to drop claims of software infallibility in their recent acceleration problems. He argues that embedded systems developers must program more defensively, and that companies should stop relying on software for safety. Quoting: 'If Toyota has indeed tested its software as thoroughly as it says without finding any bugs, my response is simple: Keep trying. Find new ways to instrument the software, and come up with more creative tests. The odds are that there are still bugs in the code, which may or may not be related to unintended acceleration. Until these bugs are identified, how can you be certain they are not related to sudden acceleration?'"
Always going forward.
o hai
Most software is nearly -impossible- to test under flawless conditions. Especially embedded systems with small amounts of CPU power and memory.
Plus, all this hype around these Toyota acceleration problems is just that, hype.
Taxation is legalized theft, no more, no less.
Drive by wire is great and all, but I'd feel much better with a physical fail-safe than their "infallible" software. I am aware of the physical remedies for the issue, but I'd like to see the brake pedal override the accelerator.
Some more data here
Testing only confirms the absence of known bugs. Never forget that.
Driver error, much like the Audi "unexplained acceleration" problem.
When Audi came up with a new automatic transmission interlock that forced drivers to put their foot on the brake before they could shift out of park, the problem went away.
The US government and its friends in the not-so-big three are using this as an excuse to pick on Toyota. No other car recall has had anything close to this level of government intervention.
Of course, my car has a fail-safe mechanism to disconnect the engine from the wheels - it's called a clutch. You should get one on your next car.
I haven't heard much about this, but disgruntled employee(s) that work for some blood sucking temp agency writing this control code could have easily hidden an Easter Egg that activates on some obscure set of triggers like changing the temperature while the left turn signal is on, etc.
I am thinking this is actually the most likely scenario to why these problems are happening with Toyota.
Toyota: Treat your code monkeys better!
* Carthago Delenda Est *
David Cummings does seem to know what he's talking about, but as it is written, there is some strange logic in the article.
Testing cannot prove the absence of bugs, only their presence. There are two things that do not follow from this:
It sounds to me as if Toyota is saying the former, while Cummings says the latter. Neither is a correct conclusion.
Notice that they always emphasise that 'there is no evidence that embedded software contains flaws'. Actually, Cummings notes it as well.
Remember also the statement of president Toyoda, mentioning that focus has been on speed more than quality.
There is a theoretical possibility that software development has exceeded the bounds of where you can have total overview of the code at all times (as in military and life critical applications). For example, if you develop 50 different software components controlling each of 50 components in car 1, it is very attractive to reuse 45 of those in car 2 and only rewrite the software for the 5 components that have changed. There is no need to test a module that has worked in all your previous cars, right?
And when you plug these together at the shipping stage and discover that it works 100% of the time (rounded up to the nearest thousand tests), you are set to go.
If the problem WAS in software, Toyota would have to either 1) invest a lot very quickly in bug testing which may or may not be successful, 2) rebuild the software from the ground up, 3) scrap all the cars. In the meantime they would have to absorb the costs of A) providing full refunds for the purchase to all customers, or B) providing rental cars to every owner of a Toyota for the months it takes to do these things.
Both of those options are unimaginably costly.
Therefore, if you so much as start going down the path that the problems COULD lie in the embedded software, it's pretty much total game over for Toyota.
I'm in the market for a car and everyone is picking on Toyota now.
I don't believe in stupid media hype. I don't believe cars rewire themselves. And I know how to hit the breaks, shift into neutral, and/or turn off the key when I want the car to go slower (so far, hitting the breaks has always proven adequate).
Are there any really good deals on Toyotas available?
Well you can always assume that your real time code is buggy and write checks to ensure exact conditions before a critical assignment or operation. But given the limited amount of CPU there arent too many checks you can build into firmware.
My thought is that the car should have either:
1. A hand brake, and the handbrake have a physical cutout switch (relay) that shuts off the fuel pump and disconnects the motor controller from the motor if pulled, and the car is in any but 'park' or 'neutral.'
2. A force sensor on the brake pedal, and if pushed hard (panic stop), would also trip the breaker for fuel pump and motor controller.
The concept is not new, in terms of overrides. For example: Many cars require the clutch pedal be depressed to start the car, or foot on the brake pedal.
There may be better ways to do it, but seems like an 'intuitive' way for the driver, and reasonably easy for an automotive engineer to add into the design.
Uh, Linux geek since 1999.
It seems he wants more software. This time to check for both pedals being depressed at the same time. One more thing to break.
The less these embedded systems have to do, the better.
Toyota may also have witches on staff, which may cause the unintended acceleration. If Toyota has indeed searched its personnel as it says without finding any witches, my response is simple: Keep trying. Find new ways to find witches, and come up with more creative tests, possibly involving a duck and a scale. Until these witches are identified, how can you be certain they are not related to sudden acceleration?
pay for QA and don't over work coders that makes bugs. When people are working 80+ hours they make more bugs then people doing 40. Also pay for QA and don't cut back there. Look at the xbox 360 to see what that left them with.
All practically sized software has bugs, but that doesn't mean it has to be dangerous. Mechanical devices fail too and therefore the engineers add failsafe-mechanisms. If something breaks, something else must absorb the problem. Consistency checks and redundancy are indispensable even when the code is perfect, because hardware is never infallible.
Didn't we already "solve" this problem in the airline industry by breaking down larger more complex software into separate physical components that can be more easily verified? Can we do the same with cars?
Just split one computer into half a dozen much smaller, simpler, little units and set the valid IO conditions for them, then have the components around them sanity check their output.
Pardon my laziness for not investigating this myself, but doesn't the Prius have a mechanical (hydraulic) link to the brakes that engages when the pedal is pushed down far enough? I realize that the first portion of the braking is done electronically (for the regenerative braking system), but in an emergency wouldn't a full application of the brakes slow down the vehicle?
I've said time and time again, "Never replace hardware with software" because
something dedicated to the task will always work better, or be less failure
prone (more often than not).
Would Toyota be having these problems with an accelerator cable vs electronic?
99% sure the answer is "no"...heck the solution is add some grease, make sure
it isn't pinched/looped too tightly and/or add tension to the pedal side.
Or, replace the damn cable with a new one...a 20 to 30 minute task.
(less than 10min on a motorcycle)
Oh, well, what do I know? I'm just a CS major with real world experience, pay
no attention to the man behind the keyboard!!!
Have you read the moderator guidelines? Well, have you, PUNK? (and I want a Karma: Gnarly option)
I'm loving this conversation here because I've gotten crucified in slashdot before for making simmilar comments to the whole thread here. I grew up in a family of top managers of Boeing systems engineers. They hated computers. My dad never even learned how to turn one on. He hired other monkey to use the computers. As A child I was regailed with wonderful stories of every hard lesson in safety my dad had learned over his lifetime. He loved world war II because they got to use cutting edge designs for balls out performance yet at the same time learned how to make things reliable by disecting the accident. He would tell me about the accident that taught them that the engine pumps need to be at full speed but flow stalled on take off so that there's no lag when you hot swap after a pump fails. He told me of the accident where they learned not to route 100% of the control system wiring through any one junction box. etc...
Probably because of all these hard won lessons boeing for years insisted on fully mechanical or hydraulic flight surface controls. Whereas Airbus and other jumped on the fly-by-wire concept early. My dad would spit after hearing some youg person tout all the advantages of fly by wire. He knew them perfectly well. He was big on accepting new innovations to reduce fuel costs and increas performance. He was not a luddite. But he had a safety background that told him these electonic systems were hard as hell to validate and hard as hell to make truly independent from each other.
For example they often used triple redundant computers and if one of them disagreed the other two would vote it off the island and stop listening to it. From what I've read it's now suspected that the latest airbus crash in the pacific had one of it's root problem in the voting nexus where a superior computer over ruled a more primitive safety system.
While we all know that computer software validation is hard if not impossible. It's not something we readily admit here on slash dot. It's because for years people like my dad would throttle the innovations the computer engineeers wanted to implement. I think as a result there became this culture of computer engineers that presented the case that embedded computing could be made safer than it really could be to offset that.
So now we come full circle and have to admit there is this middle ground. Just because a computer can improve perfromance does not mean it's reliable and safe. The old guys had a point after all when it came to safety.
Next week I'll tell you about how the ancient shocking lesson of the British Commet aluminum aircraft wings falling off led to the unanticipated discovery of metal fatigue and probably was the reason Boeing was slow to move to composite materials in commercial aircraft (but not in military aircraft). In hind sight we have heard of many tales of the composite tails of plane falling off as the reason for the loss of control before a crash. Conversely, composite wings on UAVs allow them to absorb a lot of bullet holes with no loss of control and to operate under higher perfromance conditions.
The point is that safety and performance are trade offs when both are pushed to the limit. The old guys know a lot more about safety than you might expect. The young guys are all about performance.
Some drink at the fountain of knowledge. Others just gargle.
On a side note, our legal system forces us all to lie.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
you want just plain silly the computer models they use are different from the ones in use by the weather dept. The weather Dept is only good for about 3 days ahead. If our current setups are good for just days in advance why do they think that their models are accurate over thousands of years?
i thought once I was found, but it was only a dream.
Did Toyota forget to convert imperial to metric unit like those Mars Pathfinder?
Isn't this like proving God doesn't exist?
They can test and test and not get a result that said this is the bug, so they assume that it doesn't exist.
--- Relax, that mass muderer is just trying to reduce our carbon footprint, one fetus at a time...
So I work on a robotics team on all of the firmware which interfaces the main computer with the actuators and sensors it needs to move. It drove me crazy because I had a bug that I couldn't replicate outside the robot.
If you were driving the robot around under normal operating circumstances, suddenly, the motor driver board would stop working. I had a simple state machine on the motor board which would update the motors one by one, but I had a bug which I hadn't noticed because it seemed innocuous at the time:
I updated the state machine immediately *after* I initiated an action which would eventually start interrupt code. Now, what ended up happening was that message about new speeds coming from the main board were also interrupts, and so there was this very odd cascading failure, where the motor board would initiate the action, the message from the main board would come in, we would jump into the message receive interrupt, and then immediately we would jump into the motor control routine. Since the state machine hadn't been updated yet, we would then execute the wrong part of the state machine, which would cause an error. The motor control routine would initiate a "stop" command and then go into an error state. Because this was a time-critical operation, I didn't care if we had failed to send a single packet, so I ignored the error, and jumped to the next motor. Unfortunately, the "stop" command would finish right as I tried to reset the state machine, which would put it in a different error state. And then when I tried to communicate with the next motor, I would do the same thing, over, and over, and over.
The whole system would lock up, but by itself, all the code was completely reasonable. If you took that segment of code out of the system to verify that it worked, it would work 100% of the time. Put it into the system, and it generally took something like 10 to 20 minutes to suddenly die.
the acceleration was caused by some external EMI event? Why?. It is well known amongst ham radio operators that some cars do not have sufficient EMI protection so that an otherwise correctly installed transceiver will interfere with the car electronics when used. Pure speculation I know......
This is what I've seen in the news: Toyota says there is a mechanical fault in the accelerator pedal, that may cause it to get physically stuck down. This is extremely rare, but possible. To fix it, they add a little extra piece to the pedal. Sound like a duct-tape solution, but if it works, then okay.
Did Toyota lie to us, and actually added a patch to the software instead?
Is it just me or did everyone else miss the one where a guy introduced a fault into the Toyota system that caused sudden acceleration without producing an error code? I admit he had to introduce the fault artificially but if you can do that and have no fault come up on the computer how can you say that your system works 100% of the time?
Most throttle systems I've worked with employed two cables to control the throttle in a push-pull arrangement. If setup in a single-wire arrangement then only one wire is used to pull the throttle open and a spring is used to ensure it closes when the tension is removed. In some motorcycles where the operators have a literal grip on the throttle then, if the spring is not strong enough to close the throttle (or one of the cables jams), the operator can always physically force its return by turning the throttle back manually. Car operators using pedal-based accelerators, unless they are barefoot, cannot wrap their toes around the pedal to pull it back into position.
My solution blends the two strategies: retain the pedal position sensor that captures the operators intention while retaining use of a 'return' cable. The ECU can remain in control of advancing the throttle to retain their interest in fuel economy measures while removing its control over retarding it. Pushing the pedal down merely provides enough physical free play for the ECU to work with while retaining any veto control if it gets out of hand.
The final part would encourage the adoption of accelerator pedals that users slip their feet into rather than just on top of. This would provide the same ability to positively influence the pedal return rather than expect the spring to do so.
you want just plain silly the computer models they use are different from the ones in use by the weather dept. The weather Dept is only good for about 3 days ahead. If our current setups are good for just days in advance why do they think that their models are accurate over thousands of years?
Playing devil's advocate...
Apples and oranges. Predicting local weather 3 days in advance is like throwing a coin and predicting whether it's going to land heads up or tails up by calculating the air stress on the coin, factoring in the landing zone, and all other factors. That's difficult and inaccurate. Predicting weather a thousand years from now is like throwing a million coins and predicting how many heads, how many tails, (roughly 50/50) and what shape the pile is going to be (roughly a circular mound). That's easy and predictable.
Of course, climates are much more complex than a pile of coins, so even the thousand year model is undeterministically complex.
Sometimes it's best to just let stupid people be stupid.
My mother drives using both feet, as in one foot on the brake and the other on the gas. She has always driven this way. Does anyone know if this is common or unsafe?
If you look at the latest 2 incidents the accelerator pedal was stuck to the floor. The one man even said he felt something funny has he pressed the pedal down to pass a car and it was stuck to the floor. It did not return. He said he even tried to pull it back to its original position. So how in the world it this an electronic problem? How does electronics cause a mechanical pedal to be stuck to the floor? Someone? Anyone?
Think about this: even thousands of years ago primitive humans figured out that in certain places they had a winter and a summer every year.
Denier! How dare you question the truth.
And off topic, at that. You, sir, disgust me. Our lord Al Gore will consume your soul.
Everyone knows that the first thing to do, when creating acceleration software, is to test for race-conditions...
If everyone had access to all of the data on their own cars, this problem could be solved much faster (... I seem to remember something that someone once said that "with many eyes all bugs are shallow"...)
I don't read your sig. Why are you reading mine?
Based only on testing and design experience, this is not sound logic.
Agreed software commonly has bugs not exposed to testing, but the same is true of hardware manufacture, and firmware/ROM code too.
But also, there may also be an unanticipated interaction that would not be considered a software bug in and of itself, but a combination of two unanticipated inputs creates a serious problem.
The software does not exist in a vacuum, and might be susceptible from effects from hardware, especially as the unit ages -- such as corrupt memory area, multi-bit errors, memory flip errors due to gamma radiation, overheating, and all the same issues that plague desktop computers.
Could be a characteristic of the design of some portion of the software causes the system to handle an error condition ungracefully, that should be trapped, that safety hardware should be added to detect/deal with, or that software changes should occur (even if it's not strictly a software bug, sometimes you need to change the software to be more robust in the face of a hardware problem).
For example, some chip periodically has a minor (indetectable) manufacturing chip defect, or some minor variation.
Or it could be as simple as the code that gets burned to some chip isn't the same as it's supposed to be 100% of the time.
For instance, if there was a revision to one component, but the old code was still getting burnt to new units... things could still be being produced with an old fixed bug, maybe.
Or combination of components at different revision levels than what was tested.
Moreover, an unexpected input could have been found in the field to result in physical lockup of some microcontroller.
You can't test everything 100% it's arrogant and flat out wrong to claim you can.
Surely the fault couldn't be something as simple as the speed or acceleration sensor becoming saturated? This could throw off even a properly designed, stable feedback loop because the basic analysis doesn't consider nonlinearities. I'm assuming that it is in fact a proper digital feedback system done in hardware (in which case the only software involved is a digital filter responding to periodic interrupt requests), not some wishy-washy software routine that can't be analyzed for stability.
I worked on an embedded flight system there, and deeply respected people like your dad.
Boeing works under the eye of a certification authority who has to approve the safety of a design including, at least in the system I worked on, human factors. If there's anything comparable for cars, I haven't heard of it.
Boeing would not have made a pilot have to guess at how to turn an engine off (people with older cars, it's no longer a matter of turning a key).
Inputs were checked for consistency and validity. The specs would have anticipated what to do if the accelerator and brake were both full on at the same time.
There was a culture of worst-case planning and redundancy.
Also, if Boeing built a car, it would have a flight data recorder which investigators could examine and say for example "Looks like both(*) potentiometers on the accelerator went hard over at the same time, so we go look on the branches of the fault tree where there's a common-mode failure in the potentiometers or the pedal is down due to mechanical or pilot error".
(*) If I remember correctly from my obsessive pre-purchase research on Priuses, there are two separate sensors for accelerator position.
If the engine accelerates suddenly and doesn't respond, you turn the ignition key one click to the left, to the off/unlocked position. This is how you listen to the radio when parked, for instance. The key stays in the lock and the steering wheel is unlocked.
A Prius is a special case, with its electronics.
If you cannot point to a bug then, maybe, you should not say there is a bug. Maybe you can talk Toyota into releasing the code to open source peer review.
What does the Toyota source code look like?
Back in the 1960s, when the space capsules were being designed, 16k words was a lot. So programmers wrote tight code, optimized down to every instruction. It wasn't perfect but it was fairly easy to examine.
Nowadays memory is cheap. And we have programming techniques that take advantage of it. Object-oriented code, for instance. This speeds up some kinds of programming but it puts more effective distance between the source code and the executable. And the mere act of using an OS API, as noted in the original story, makes the application vulnerable to subtle bugs in the OS.
It's laughable that Toyota could have thoroughly debugged code that was written using modern, large-memory techniques.
Still, it's unfair to single out Toyota. There's too much drive-by-wire in a lot of cars.
But there are umpteen different models and implementations. I suppose they could all be wrong, but it would be more than a simple coding error if so.
The 737 Rudder Problem was hydraulic not electronic.
There is one efficient and reliable machine out there: The paper weight.
There is one bug-free software out there: int main( void ){ return 0;}
Where's the manual override for that accelerator?
can't find it, let others do, put 10k prize and you will get hundreds of leads!
... why does everyone assume it is a software bug? I agree that it very well could be an undiscovered software bug. But there are so many more sources of erroneous behavior in an embedded system that *even* *if* the software were flawless (ummm... just go with me a minute... :) an automotive environment can cause all manner of strange glitches. I work with robots, lots of DC motors causing commutation noise on the power supply, long (several inch) distances between units that must talk to each other and therefore may have a different opinion as to ground reference voltage... many things can get wacky. Even flawless code needs a watchdog timer to get you out of weird states that power glitches that put you into. Power supply spikes can cause the program counter to jump to very odd places, with odd, corrupted stuff in RAM. Ground level shifting can cause communication glitches. CAN bus is *extremely* robust, so bad data should not get through... but what does get through? Does the system as a whole get into a weird state if packets drop?
Despite the obvious problems with Toyota cars, one thing is shure. There is a lot of people in the US profiting and betting in the fall of the main concurrent for US disgraced auto makers. They (Toyota) are being targeted by a negative campaign.
I cannot believe that only Toyota has some sort of serious problem in their cars. Greediness and bugs are not a their exclusive. The main problem consists in being one of the most advanced producers.
As software complexity surges I'm afraid this problem will multiply elsewhere.
Math is beautiful... e^(pi*i)+1=0
One possible explanation: If reporters consciously or subconsciously expect old drivers to be crappy drivers, they may be more likely to report the ages of older drivers.
... because we can't find reverse.
Is there much of a chance that some evil idiot created a bug, perhaps transferred from a Toyota diagnostic device that inserts a bug causing the accelerators to act as if they are wide open?
My personal bet is that there are three or more ways that these cars run away. One might be the carpet thing. Another might be wear on that little metal part that we saw on TV and more might be in the software. The next question is whether the software glitch was sabotage or design related.
That stupid start button needs to be converted to a switch so that off becomes more absolute. Having to hold a button for three seconds to turn a car off is just wrong.
The Miami heat have a "Toyota" scoreboard. During the last game the scorekeeper messed up and they had to run the numbers real fast before they could reset it. I could not help but think of it as a run away Toyota score board.
This is off topic:
I'd rather not have comments on the article appearing in the RSS feed. I'd like to see the article summaries appear "several on one screen" rather than "one per screen".
Several years ago, I designed the software for a real-time automotive test system called HP ECUTEST (I think the official name was HP Design Span DS5470, but let's not waste time on HP's cold dead fish naming conventions). It simulated a car from an electric point of view. You connected an electronic control unit (ECU), and it had basically no way to tell it was not in a real car. Think of it as The Matrix for car electronics.
One of our first customers wanted us to test it with a reliable, proven, tested, tried and true ECU, something that was on the road in cars for several years already. So we did. And I noticed something odd. The ECU worked fine when we "drove" a car normally, but at idle, it would basically slow down, one RPM at a time, until it stopped. However, if I changed the value of the input corresponding to the accelerator pedal, it would reset the idle speed to the default, something like 800rpm.
Finally, after eliminating the possible bugs on our side, we tell the customer. Their first reaction was "no way". But after a week and a demo of the problem, they finally made a connection. They had this elusive bug of some car customers complaining that their car would sometimes stop when idle. It turns out that in a real car, chassis vibrations generally caused minute changes in the input value for the accelerator. So the ECU would correctly recompute its idle speed. However, if there was no change, like if the pedal was more rigid than usual, the bug would trigger.
The root cause was a routine that wanted to optimize idle speed to be as low as possible, but for some reason kept cached data if the accelerator had not changed, so it thought the engine was still running smoothly.
We found such bugs in practically all ECUs we tested for the first time. The most impressive one was in a V8 ECU that was basically a V8 until 1200rpm, then a V7, then a V6, and basically a V2 above 4000 rpm. The customer had hoped we'd find something, because they didn't get all the power they expected from the engine. Obviously. It was hard to find without our system, because the injectors that fired were differnt from cycle to cycle, so more simple instrumentation saw all cylinders running. The root cause here was that the software badly exceeded its real-time envelope... Ouch.
-- Did you try Tao3D? http://tao3d.sourceforge.net
Put the throttle cable back. Why fix something that was not broken to begin with. With a throttle cable if it broke then the car stopped. How many reports of cars accelerating themselves with a throttle cable have you heard of?
Sounds like to me a little bit of over engineering something.
Failure to embrace the latest tech does not mean one is a luddite, especially when we are talking life-and-death. SCUBA diving is a hobby of mine. When submersible dive computers came on the scene I noticed the early adopter were generally non-technical people: doctors, lawyers, business types, etc. The electrical engineers and computer programmers were usually sticking to mechanical analog depth and pressure gauges and plastic cards with depth/time limit tables. Over time the dive computers left the "1.0 stage" and proved themselves and tech types began to transition.
Fly-by-wire has a somewhat comparable history. Fly-by-wire was adopted, debugged and eventually proven in military aircraft. In this case it was a greater risk tolerance that allowed the military to be an early adopter. Today it is far more reasonable to use fly-by-wire in civilian aircraft.
Fly-by-wire software in aircraft or cars should never be considered 100% reliable. However older tech is not 100% reliable either and one also has to consider the increased safety offered by newer tech. For example the software in anti-lock brakes may save more lives in that vast majority of cases where it works properly than the number of lives that are lost in extremely rare situations where it fails. There is a point where an imperfect solutions can save lives. Should a manufacturer ship such an imperfect solution when it passes this point? That is a very complicated question.
--
Perpenso Calc for iPhone and iPod touch, scientific and bill/tip calculator, fractions, complex numbers, RPN
The fundamental flaw here, is that if the brake pedal and throttle pedal are both pressed at the same time the ECU isn't not ignoring the input from the throttle pedal. This I suspect would be expensive for Toyota to fix (otherwise they would have done so already and not tried to "fix" this flaw by carpet mats and throttle "shims".).
Ford fly-by-wire systems ignore the throttle input when the brake is depressed and Toyota is even changing their systems to match for 2012. Seems like to me they are dancing around the issue of back-fixing this in older models, most likely due to cost (though one would think it could be done in software but perhaps not and requires changing some part of the engine management system out).
I don't think anyone at Toyota realized just how bad their handling of the event recorder data looks. I'd be much more willing to give them the benefit of doubt if they were as open with the data as GM, but this comes off as incredible arrogance.
A Shadeless room is a brighter room.
The best computers in the world may be wrong about exactly what the weather will be like next week but even I can tell you when summer/winter will be. You can be much more accurate over a larger time frame.
putting the vehicle in neutral won't stop the vehicle.
I put our Prius in *full* acceleration for 5 seconds then put the car in neutral. Transmission does, in fact, shift into neutral. Meanwhile, with my foot on the accelerator, 'floored' the engine drops to idle. Brake assist works because the motor is providing vacuum.
So, it seems that the CV transmission is independent from throttle control.
I did this at a ridiculously early hour with no one in sight on the nice, straight, highway.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
You can't test enough. It buys you time. Test is more important than the development, especially in hard real-time systems.
Unfortunately, Toyota doesn't have time (time is money) as well as its priority was cash over safety, period.
It is funny that the armchair quarterbacking comes from the organization that consistently has bugs concerning english to metric unit conversions.
This is what I've been saying all along; it could have easily been caused by some lazy programmer who didn't check a return value, overlooked integer overflow, or made an inappropriate type cast.
On the other hand, I do agree that there is a large chance that it could be due to 'ground bounce' or other EM noise. However, the electrical & computer systems on automobiles should really be considered one in the same. They are the left and right hands of an entity and need to communicate effectively with each other. If there is electrical interference, then the signal processing system should take that into consideration and filter it out. If there is too much electrical interference, then the electronics should be re-designed!
The author wrote near the end of his piece "It is probably only a matter of time before a software error results in injury or death, if it has not happened already (there are some who say it has)."
I thought this wasn't even remotely in question. The Therac 25 radiation overdose killed some people for sure (see http://en.wikipedia.org/wiki/Therac-25)
Whether Toyota should be straightforward with customers about the level of uncertainty
or adopt a blustering strategy, kind of depends on how comfortable people (the customers
or potential customers) are with uncertainty existing in science and engineering.
Scientists and engineers are comfortable (some of us) with existing in a world where .83 probability of this, and a .012 probability of that, and we expect as a matter
there is a
of course that our theory might have to be revised as more observations come in.
But I had the experience of working for a non-techie executive, and when he asked how
things were going, or I proactively informed him about some issue in the development
project, he invariably had the same reaction, no matter whether I was reporting a minor
problem (one in a sequence of hundreds of obstacles the engineer has to discover and
work around as they go - i.e. a routine temporary unknown or a routine new problem at
the forefront of the innovation), or a potential show-stopper.
Regardless of which of these it was, and I was always careful to put these problem
reports/issue reports in perspective when reporting them, it was always:
"Oh MY GOD!!! We need to shut down this project / subproject /workpackage / feature
development RIGHT NOW! There is a PROBLEM! We can't afford PROBLEMS!! They
are too SCARY!! I don't know what's around the corner! We must backtrack and go another
route altogether!!!!
So eventually I stopped reporting problems/issues to my management, and just went
about with the other techies fixing/working around each one. And if asked how it was
going, I would resort to impenetrable but vaguely positive generalities. Why?
So we could get some work done. So that management by irrational fear and lack of
insight and perspective would not GUARANTEED ruin the project.
How dysfunctional is that.
I imagine Toyota, and its relationship with the general public, is kind of like that.
They may be damned for blustering, but they damn sure would be crucified
for telling the truth about the level of engineering uncertainties in any developed
complex system.
To get the downlow, you have to be equipped to handle it rationally.
Where are we going and why are we in a handbasket?
In my first internship, I worked with a QA team for a telephony hardware company. One of the tasks that we started, (and I stress started,) was a "Continuous Hours of Operation" test where we would run tests that were supposed to keep running for weeks or months in order to find bugs.
The first thing I did, to get comfortable with the APIs and testing hardware, was to write a simple program that picked up the phone, played some music, and then hung up. After about 5 minutes, my program kept crashing. Assuming that I was doing something wrong, (because I didn't know the API,) I asked for help.
It turns out my silly "pick up the phone and play music over and over again" test found a bug that had been eluding major engineers for a few years.
Perhaps all Toyota needs to do is take some of their simple unit tests and keep running them over and over without rebooting the firmware. Then they might reproduce the issue within a few days.
No, I will not work for your startup
I do industrial automation for a living, and machine guarding/safety is a major component of the job. There are now, in the last few years, software based safety products that are provably just as safe as a hardware only safety products. The key is that it's not just about rigorous testing, it's about correct design. If you want category 4 protection, you need to be sure that:
Software becomes another component. Therefore you need to have redundancy in your software. Government regulators that certify these safety systems as compliant want to see you prove that a single component (i.e. unit of software) can't malfunction and leave the system in an unsafe state. What a lot of companies do is they have two independent processors each monitoring the inputs to the system in parallel, and each generating the required outputs. The processors are typically sourced from different companies, and the circuit boards are designed by different teams. The software running on each processor is written by a different team. If both processors agree on the outputs, the system drives those outputs, and if not, all power is dropped to everything and the system can't be restarted (may need to be replaced, etc.).
Those of us in the industry were skeptical of software based safety at first, but given the above facts and a decent amount of regulatory oversight, I'm satisfied that it will live up to the design criteria. That doesn't mean an error can't happen, but it makes the probability low enough that we can live with it.
The latest thing is safety systems running their I/O across networks like DeviceNet and even Ethernet/IP (the IP stands for Industrial Protocol, not Internet Protocol). Again, I was at first skeptical, but they use a protocol layering on top of the network using timestamps and redundant processors on both ends with reasonable failure modes that the system is provably safe, within reasonable limits.
So you can make safe embedded systems, but without being able to inspect the design and see that it lives up to these guidelines, Toyota can't ever *prove* that the system is safe.
"I have never let my schooling interfere with my education." - Mark Twain
not to say things like the temperature is going up by 3 degrees over the last 50 years it isn't.
I can bet there isn't a climate model that would say that virginia would get more snow then New York. yet that is exactly what happened this year.
i thought once I was found, but it was only a dream.
Is it just me or could this be corrected with one line of code?
if brake_input > 0 then accelerator_output=0
I'm a former professional "software tester from hell" (currently unemployed) -- and I drive a 2007 Camry Hybrid.
Officially, my car does not have a problem -- other than the floor mats -- which are now in my trunk and were never a real problem anyways.
Months before all of this publicity, I complained to my dealer about what seemed like a "sticky throttle" during routine maintenance.
The engine continues to run fast for 3-5 seconds after letting up on the gas.
The dealer actually charged me for the extra inspection, but did not find a problem.
So obviously -- I have some concerns.
I doubt that it is a software bug. It didn't start happening until the car was 2 years old.
But who knows ?
Some of those embedded computers have probably been running since the day the Hybrid battery pack was connected in the factory.
Any software running that long could have become unstable.
But without source code, I am powerless to do anything about it.
I have to rely on the word of Toyota's software QA people -- even though I know the current state of the art of software testing is a JOKE !
If Toyota open sourced the code -- I'd have a lot more confidence -- that with a lot more eyes on it -- the software really was OK.
(and if they offered a reward for finding a problem -- I'd be even more confident)
Now for a quick rant as to WHY the current state of software testing is a joke, and why I have little confidence in ANY corporate software QA.
I write this as a former CSTE -- the QAI's "Certified Software Test (Engineer/Expert)".
I also should say that I love software testing because it is the one part of software development where creativity and intuition still play significant role.
And -- it is one area where techniques and standards are still being developed at a significant pace.
Most software development today is 98% boilerplate and copies of stuff somebody else did.
Engineers translate functional specifications into code based on established design patterns.
There are some basic calculations to ensure good response times and scalability.
Software testers typically create test plans from the same set of functional specs that the engineers use.
They simply validate that everything that is supposed to happen, happens.
Then they might run some performance tests -- but only if management budgeted for a test environment for suitable for performance testing.
Then they stop.
Inevitably -- bugs appear in areas that no one ever expected.
Those are fixed later -- and regression tests are added to the test plan.
But -- almost NO ONE EVER LOOKS FOR THOSE "UNEXPECTED" BUGS -- before software is put into production.
Why ?
Because engineers hate the unexpected and don't typically know how to deal with it.
Micro-managed companies following strict Six Sigma processes (like Toyota) don't know how to create a time and resource budget for a "hunt for the unexpected".
The QAI (Quality Assurance Institute) doesn't help either.
They are run by a bunch of engineers obsessed with a desire to precisely measure and quantify every aspect of software testing.
Their techniques are useful, and largely valid -- but if they don't know HOW to quantify something -- they IGNORE it.
Just ask any CSTE -- "How do you test for race conditions" ?
There is no established technique for this, so the QAI simply IGNORES the issue.
There is no mention of race conditions in the CSTE's CBOK (Certified Body of Knowledge).
I used to work for one the the world's top software QA "gurus" and I once asked him how we test for race conditions -- the answer was --
"we don't, because we don't know how to do it".
Despite this -- intermittent race condition bugs account for a huge portion of real-world bugs !
As programmers make more use of multi-core CPUs and GPUS -- race condition bugs are getting to be more and more common.
And yet -- testing for race conditions and testing for "the unexpected" IS actually possible -- it just
The Times also helpfully provides a list of all the people who have died in "sudden acceleration" accidents involving Toyotas:
Toyotas, deaths and sudden acceleration
If you look through the list at the ages mentioned, one begins to notice a rather odd pattern: 18, 21, 32, 34, 44, 45, 47, 56, 57, 58, 60, 61, 63, 66, 68, 72, 72, 77, 79, 83, 85, 89
This is a most peculiar bug indeed in that it seems occur primarily when the driver is elderly. Or perhaps, as with previous "sudden acceleration" scares, this will ultimately turn out to be the result of people slamming on the gas when they menat to slam on the brake and then trying to blame the car for their error.
People have died enmass in a fire right beside a fire exit because nobody before them had opened it. People, you and me, ain't smart when the shit hits the fan. The parachute was not invented by a guy while falling from an aircraft. It took someone sitting very quietly behind a desk drinking a cup of tea to come up with that one. People have burned rather then take risk a broken bones jumping from away from a fire.
In a way, it has to do with training. We are trained not to use the fire exit and not to jump down and not to put the car in neutral while driving. Why, I heard rumors that if you do that, the transmission explodes and you spin violently out of control (or was that going into reverse) (tested on myth busters) and so people lock down in a crisis. They really just stop thinking. We all do it. I can make you freeze just by asking you to say something in a microphone. 99% chance you freez or become a blittering idiot.
Why do you think there are slip-courses? So you know what to do and have a remote chance that training takes over from thinking.
It is very easy to say "I would do X" when you are sitting behind a desk.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
/dev/console read each line of code as it is getting executed and isolate the line that causes the sudden acceleration
It isn't a software or electrical problem. It is a mechanical problem.
There is a way to do it and it has with timing and expectations. Read How to Construct 100% Bug-Free Software if you're interested in solving the reliability crisis once and for all. Of course, one must use a synchronous and reactive software model like COSA.
Trying to code to handle all possible malfunctions can be exceedingly difficult. (Yes, I do have experience with embedded design and code that deals with H/W problems.)
First off, it can be difficult to determine which set of inputs are normal or acceptable and which ones represent a possible malfunction. Think about the myriad ways that a system can malfunction from bad sensors, noisy voltage, open or shorted connections, crosstalk on cables and so on. I had a system malfunction because a built in A/D converter malfunctioned and the interrupt it generated was lost, causing the system to suspend in time. If the brake and throttle are both pressed at the same time, is that a sensor problem? One foot on two pedals? Or maybe the driver is getting ready to pull a boat up a ramp. Disable the throttle and he'll roll back into the water. Might drown. But he probably won't have time to dial 911.
Figuring out all of the situations in which the system can malfunction will require an exceedingly fertile imagination. And most likely 90% of those malfunctions will never ever happen in the wild. But it is likely that something will malfunction several years down the road and the engineers will scratch their heads and say "gee, didn't see that coming."
Now add code to deal with all of those possibilities and you have a combinatorial explosion of situations the code has to handle. That makes it less and less likely that the code will gracefully handle all situations and makes more and more likely that unrelated bugs will be introduced.
I found the problem. Seems to be some bad code in the cruise control module: DateTime randomTime = Random(time); if (randomTime currentTime && carDriver == "ugly american") { speed = 160; while (true) { if (carDriver.presses(break)) { speed += 5; } } }
How about a project that explores millions of unlikely chains of events. It would record all the events, and if any event-sets were to result in unimagined but catastrophic failure, an analysis of the inputs would probably uncover some interesting facts. This could be run by a distributed computing project, like SETI, Folding etc. Toyota would probably not want to facilitate unauthorized analysis of the processors' code etc, but that could all be sealed in a Black Box so as not to be available except to the project client code, and the inputs & outputs would be encrypted and communicated from/to Toyota (or some appropriate authority).
Since when did two-lined spittlebugs become the bug-of-choice? I thought it was all about the blatellids.
"He argues that embedded systems developers must program more defensively, and that companies should stop relying on software for safety"
I've been doing embedded systems development since about 1981 at companies such as Intel, Etec, Tait, and contracted for many, many others. None of the companies I've worked for relied solely on software for safety; we all knew better. Whether opening a door, sending a distress signal, or having a robot move there has always been a physical "wall" behind the software to prevent mishaps that could led to bodily harm or mission critical failures. It is patently unfair to claim a generic problem with embedded system developers; especially true considering the extent embedded system are involved in our lives -- from thermostats to microwave ovens, from the bios in our PC to our TV, the list goes on and on. Besides, as to the Toyota problem, we have no idea as to the cause and the reams of data we have are not reliable.
The last thing I heard was that these Toyota problems happen in the US only, or at least have devastating consequences in the US only. There are reports of more than 50 deaths that are supposed to have been caused by these "uncontrollable acceleration" issues in the US, while the combined death toll of these problems in all other countries is zero. Now, I'm generally not a supporter of conspiracy theories or speculative explanations that suggest things like some mild mass psychosis (culturally induced, irrational fear of evil engines going berserk, maybe?), but if the above numbers are correct, they're far beyond the realm of mere statistical fluctuations.
Can't we just put a mechanical fuel-line kill switch somewhere in the car? Like a covered button in the dash panel or glove box? No fuel, no go, right?
But anyways, reading from the statistics, there's been some 50 out-of-control Toyotas for how many millions on the road? It sounds like the expense of installing them would not be worth of. But the PR effects or re-assuring the public might make it worth it.
Computers are useless. They can only give you answers.
-- Pablo Picasso
What evidence is there that it is a software bug? I mean, sure, a lot of us are computer programmers so we know how unreliable the software can be... but a lot can go wrong in mechanical systems as well. And so far, I haven't seen a bit of evidence which points to a software fault over a mechanical fault. (and some, like the pedal being physically stuck, which points the other way)
As for the addition bug found in the Pathfinder... I ran into a similar bug once. A simple addition was returning the wrong answer, in the middle of a decryption routine, which would then fail. It was, as was the Pathfinder bug, interrupt related. But, in this case, it was the CPU itself which would screw up the add (as confirmed by the manufacturer's errata sheet); hardware, not software. Sure, software's unreliable. But it's not the only thing which is.
as a driver of course i have all kinda of situations of something failing on my car being its a old car. the key to any bad situation is not to panic. these would be the same drivers that hit other cars if there brake failed rather then quickly applying the ebrake. the system there wanting to put in cars the smart peddle does the same thing shutting off the car yourself would do. trust me i was going down i-75 in my car and a brake line blew being my car is a single cylinder brake system i lost all braking power and had to pull the ebrake locking the rear tires did i crash no. of course my cars sensors all work and both my abs and brake light lit up right away telling me there was a major problem. i dunno abought other drivers sometimes even if you car all of a suddion whent to full power for no reasion thers always that off button stoping that chain of events dead. weather toyotas cars have a real issue or not driver skill still is the reasion people died. drivers tend to panic hen there put in a bad spot and bad things happon. im not blaming them but any good driver should knoe what to do in case of a runaway or failer of the brake system. but in the usa you dont not need to knoe these things to get a liance to drive.
It sucks, skippit. But gee, thanks, Mr. Gates, for a philosophy that proves those clowns at IBM had some of it right in the prehistoric Sixties. (I.e., racks of software printouts, and a multitiered CVS with flinty-eyed human engineers running the protocols, not some flimsy database system.) You had to SIGN your stuff in the old days.
``Tension, apprehension & dissension have begun!'' - Duffy Wyg&, in Alfred Bester's _The Demolished Man_
And that's good, because it's not so safe to stand in front of them.
/Not mine. Shamelessly stolen. Love my Camry. Don't sue me. Please?
Help stamp out iliturcy.
a race condition!
http://courses.cs.vt.edu/cs3604/lib/Therac_25/Therac_1.html
This is why you should put more effort in design and proving http://en.wikipedia.org/wiki/SPARK_(programming_language) and not use C as programming language.
So you know: most car manufactures use C for embedded programming. I consider that wrong - they should use Ada or better SPARK-Ada http://en.wikipedia.org/wiki/SPARK_(programming_language) instead.
Aisin-Warner is one of the largest AT manufacturers for cars in the world (and, by the way, a daughter company of Toyota). The shifter is directly connected to AT itself by mechanical wire -- albeit not to the valve box. This is not possible as you have five/six valves operating the AT and those five/six valves do not directly correspond to the individual gear settings.
At least the AT control system software as delivered here in Germany does NOT prevent spin up of the engine. Either there are different software versions or you mix up things: there are two control boxes, one for the AT itself and the other one being the engine control box. The engine control box does overspin control -- in my case it will cut gas supply immediately around 6500 U/min. The AT control box does not do any engine control: it just asks the engine control box to reduce torque when changing gears.
And before you ask -- yes, I checked that with my own car just some days ago: at 130km/h hit the lever into N and up goes the engine.
It is a question of system design. Maybe Toyota needs to learn a lesson?
Since most car manufactures use C it would be:
if (brake_input > 0)
{
accelerator_output=0;
}
Of course I think using C is wrong to begin with...
Let's all follow NASA's design methods. The 2011 model cars will be available sometime after the year 2050, that is if the project isn't scrapped around 2040.
So far all I've heard is probes into stuck gas pedals and software review. Of course, if the problem is not a stuck gas pedal then the assumption is the hardware is fine. If the software is tested thoroughly, then it too must be fine and the problem doesn't exist. Yet, something is happening.
Having been involved in the hardware and software investigation of very intermittent problems, it's not surprising to see these discussions. This happens when the vendor doesn't really want to find the problem, but rather put the blame elsewhere.
There are other sources of problems, and they can be difficult to replicate and even harder to fix. The two most common areas I've experienced have been timing and interference. Timing issues can be anything from handling of interrupts out of sync with clocks or other code. Interference can affect sensors or logic levels from external RF energy, electrostatic discharge, or noise from in-circuit inverters. Interference is the toughest because the source that happens in the field doesn't always exist in the lab.
The possibility of interference as a source of the problem is also a hard pill to swallow for some engineers because they tend to trust shielding that is either insufficient or not properly installed, thus making it more of an antenna and transformer of energy rather than protecting the equipment from that energy. Elimination of the source of the energy at the hardware is one method of solving the problem, but it doesn't hurt to have the proper software rules in place to insure that exception conditions are handled properly (for instance, you shouldn't need to press the brake and accelerator to force the vehicle to slow down. When the assumption is the accelerator is stuck and you only try to press the brake, nothing happens because the accelerator isn't actually stuck... duh).
Instead of testing such narrow parameters for the situation to appease Congress, Federal officials, and Toyota Management, a broader scope should be done. The quickest way would be by Toyota engineers who have knowledge and access tot he internals, but if they cannot be open minded about it then a third party with full access to the designs might be in order.
Hi ho silver
I've been contending for ages that car makers, now that they're essentially doing fly-by-wire, need to hire aviation engineers to make their systems triple-redundant. A car may not be "fall out of the sky if the computer fails", but slamming in to a bridge abutment at 90 MPH is just as deadly to the driver.
I had a 2000ish Isuzu Rodeo. It had drive-by-wire throttle. One day the Get Serviced Now light came on and the acceleration dropped to a pitiful number. It ran fine, still had good top speed, just no acceleration. Took it to the dealer and found out that the throttle sensor went bad, and if the computer did what it was told by the sensor, it would have trashed the tranny. So the computer locked the tranny in to 3rd gear and told me to hie me hence to a dealer. This is the sort of failure path that this sort of electronic control system needs.
When you sympathize with stupidity, you start thinking like an idiot.
Years ago, I had a Datsun B210. There probably wasn't even software in the car radio. I lived in the Seattle area at the time. It's fairly humid there and at certain time a little ice would form in the carburetor and cause the throttle to stick open. The first time it happened to me was a bit of a shock. I stepped on the clutch and the RPMs jumped. I then hit the brakes, and turned off the engine and costed to the side of the highway.
The next time it happened I discovered that kicking the accelerator pedal would break the ice and let things work normally. Not too long after that, "Oxygenated Fuel" was introduced and the problem disappeared.
un-ALTERED reproduction and dissimination of this IMPORTANT information is ENCOURAGED
I'll bet the touch-sensitive dashboard is the problem. Click and Clack said it could cost $800-$2000 to fix one messed up by a teacher putting a refrigerator magnet on it. What other sorts of random inputs will occur from dust, sweaty hands, or spit? I'll bet they haven't tested for that at all.
I see that Toyota apologists are in full cry, trying to prove that Toyota unintended acceleration is really due to a bunch of old people who don't know how to drive, young people driving badly, and almost anything other than a real defect in the throttle software. Steve Wozniac (Apple founder and designer) says he can replicate the problem at will, and he claims that Toyota is ignoring him. Wonder why.
Other things to consider:
- The same old and young drivers don't report unintended acceleration for other brands.
- The unintended acceleration in other cars was a real human design defect[1]
- The press (other than Slashdot) has ignored Wozniac as well, for the most part
[1] It seems that if pedals are put in a "stick shift" configuration, throttle on the right, brake in the middle, and (space for) clutch on the left, people don't hit an unintended pedal. Putting the brake and accelerator in the middle space, under the wheel, is more likely to result in error. Since the elderly and young men are somewhat more likely to have driven manual transmission, they are more likely to stomp in the middle of the floor looking for the brake under stress. Call that human error exacerbated by design factors. But those were not situations lasting for minutes.
Also, if Boeing built a car, it would have a flight data recorder which investigators could examine and say for example "Looks like both(*) potentiometers on the accelerator went hard over at the same time, so we go look on the branches of the fault tree where there's a common-mode failure in the potentiometers or the pedal is down due to mechanical or pilot error".
(*) If I remember correctly from my obsessive pre-purchase research on Priuses, there are two separate sensors for accelerator position.
There are black boxes, and several stories circulating about them. The first says there is only one laptop in the entire USA which can read the black box codes. And the other claims that the black boxes are now not recording brake and throttle settings, or so Toyota claims. Call me paranoid, but if that data showed something which proved the throttles didn't stick or the brakes weren't used, I bet Toyota would give the NTSB a hundred of the laptops. Of course I would promptly crash a Toyota with brake and throttle on and see what the readings were, "I am not a trusting person."
The link I gave to the Associated Press story notes both accusations, and a number of other steps Toyota has taken to hide the black box data. As Nixon found, the damage from being caught in a coverup is worse than the crime.
To me it suggests that older drivers are having more difficulty coping with the situation once it arises.
Forbes says that the guy who got himself plastered all over cable last week was 'afraid' to put the vehicle into neutral, or to turn off the engine:
http://www.forbes.com/2010/03/12/toyota-autos-hoax-media-opinions-contributors-michael-fumento.html?boxes=financechannelforbes
(They link the 911 recording:
http://www.thetruthaboutcars.com/the-jim-sikes-911-call-23-minutes-of-unintended-acceleration/
)
So apparently being an idiot is also a likely factor in the failing to cope with the incident before it becomes lethal.
But they key observation is that the higher number of fatalities among older drivers doesn't really point to the source of the problem being driver error (rather, the driver error is in failing to deal with the situation once it arises).
You certainly don't have to be an idiot to fail to handle a stuck throttle, most people will never have the experience, and if it becomes a problem starting at highway speeds, many drivers may feel the need for both hands on the wheel. I would want to know in advance that I could turn the engine off without engaging the steering wheel lock. And that it kills both the electric and gas power in a Prius. Shifting to neutral is likely to to be the last resort, but most effective.
There could well be an issue with the anti-lock brakes as well, if the braking power is being limited, they may well not have the stopping power needed to overcome the engine, the recent police assisted stop was made made after slowing with the emergency brake which probably is mechanical and will actually lock the wheels. That would explain the claims that the brakes were full on but the car didn't slow down, and the odd signs of only partial brake application noted in some cases. Apply full engine power and limit brake effectiveness, if that bug could be proved it would explain many things.
It would also probably exonerate the man who is in prison after unintended acceleration.
Plus, all this hype around these Toyota acceleration problems is just that, hype.
So... 52 people hyped to death. That might be some kind of record.
52 people allegedly hyped to death.
Few if any of these tragic incidents have yet been demonstrably linked to either defect-related unintended acceleration or media hysteria.
However, I would expect hype-related deaths to increase as drivers of Toyotas and other vehicles make unusual fear-based driving decisions concerning the perceived threat of runaway Toyotas (or try to cash in on the lawsuit).
Phooey on the whole acceleration bug...the people that are having problems are inept and I think part of a smear campaign.
I learned to drive using both feet! I learned to drive using the left foot for the left brake and the right foot for the right brake. I used my left hand for the clutch and used the right hand for the throttle! I could hit either or both brakes with the throttle fully engaged. Usually I had the throttle fully engaged.
When I had to turn a corner I would spin the steering wheel usually with my left hand and if the front wheels were not biting enough I'd hit a brake. I usually drove only with the left hand on the steering wheel and usually in the 6:00 position and never at 10:00 and 2:00! I usually drove looking in the opposite direction where I was going. I knew the route pretty well so I had a pretty good gut feel when a turn was coming up and I did look forward for the turns.
I took all the turns at full throttle and usually at full speed!
I also judged my position in the lane by looking at the ditch. This meant that while I was looking backwards really I had one eye on where I was and one eye on the ditch. I never hit the ditch once! I never got too far from the ditch either! I was always dead center in the sweet spot of the lane.
So that folks is how I learned to drive! I figure what they teach in Drivers Ed is for sissies!
Also I got my drivers license when I was 16. There was a box on the application form where I had to indicate how many years of driving experience I had. I put down "4". I learned to drive when I was 12. When I was 13 I was driving 8+ hours a day sometimes. I figured I'm not going to lie on this thing. If I have 4 years experience then I say I have 4 years experience! I got my driver's license on the first try. I had not taken any driver's training.
Where can I download a dump of the original and reflashed accelerator code that is available and driving around on countless cars today?
-- I was raised on the command line, bitch
I've looked far and wide for a quote from Toyota where they claimed that either their electronics or their software was "infallible", with no luck. What I did find were several passages similar to "Toyota's assertion that its electronics are infallible" with no citation of such an assertion.
Infallibility sound like something no sane manufacturer would claim. Can anyone cite where this alleged claim was made?
But, I wanted socialized health insurance!
Apparently shifting to Neutral on the transmission is the suggested way to go:
"...the first thing a driver should do is to put the transmission in Neutral. A driver can place the Prius in Neutral by moving the shift lever to the “N” position—to the left side of the shift gate, and hold it there for a second. This stops the torque to the wheels, and gives the driver instant speed control over the vehicle, and allows the driver time to assess what is happening. Shifting into Neutral at full throttle will not damage the engine. "
http://www.hybridcars.com/safety/top-5-myths-about-prius-runaway-acceleration-27507.html
Uh, Linux geek since 1999.
I agree with this article. I'm a software engineer - software without bugs is unheard of. Look at Windows - they've spent many years and millions (if not billions) of dollars making it better, but it still crashes, you still get the "blue screen of death" sometimes. It's not because they're incompetent - it's because complex software systems are really, really hard to make without bugs. Especially closed source.
Furthermore, unlike with spacecraft software, normal developers don't bother testing for very unexpected results. I'd be extremely surprised if Toyota did. So if there is some hardware problem, some spike/short circuit somewhere that manifests once in a blue moon, that could lead to incorrect results and for example signal that the brake is not pressed even though it is.
I don't trust software. No one should trust software. I'm buying my next car with manual transmission so that I have more control over it. Whether Toyota's problem is software related or not is irrelevant; sooner or later, there WILL be deaths caused by software bugs, I guarantee it.