Some very competent people have reported that the brakes failed to respond when they tried to stop the car from an unintended acceleration incident. Most people investigating this passed it off as "driver error". I understand this is a "panic" situation and people can get confused. But these people swear they were stepping on the brake and not the accelerator.
If the drive computer went into some strange runnaway mode where it caused the engine to accelerate, it also could cause the anti-lock braking system to release the brakes. The anti-lock brake system takes precidence over the brake pedal in a skid condition, as it should do under normal conditions. But in these cases there would be no way to stop the car.
This is all speculation and guess-work of course, but it seems to follow closely to the reports of the actual drivers who experienced it. Very intriguing report. And it gets more interesting all the time.
>Toyota should be forced to publish the complete source code of the faulty ECU
Good idea, along with flow charts and schematics. Not just Toyota, but all manufacturers whose code is so crucial to public safety. There was a time when a backyard mechanic could see exactly what was happening in the workings, not any more when so much is hidden in silicon.
And, yes, there should be a legal requirement for a big panic button kill switch that shuts down all software functions and returns complete mechanical control of the vehicle to the driver. This is the only effective "fail-safe", assuming of course that the driver is not drunk, or texting, or both.
Redeveloping or just patching buggy code is not as simple as it sounds. I remember a New Yorker cartoon from the '40s showing a customer at an auto repair shop asking whether the mechanics put new carbon in when they took the old carbon out (this was from the time when engines normally developed heavy carbon deposits and required tear downs of the top end to remove them).
In the same way, I always told my development teams that fixing known bugs necessitated inserting new bugs - a good Monday-morning joke but not really that funny. However, bugs are inevitable and, as many commenters here have pointed out, there are many, many methods of detecting and remidating them - but they only work if the development team is willing to accept their own fallibility and has the support of managemnet to rework something that is supposed to be finished.
All repairs are fraught with risk - will the repair be done corectly? will further damage be done to the unit during the process?
I would be very leery of taking on a 'new and improved' version of the engine conrol code in a Camry covered by Mr. Barr's analysis. As many other comments have pointed out, the system at present has no independent throttle system fail safe and relies on a single CPU running multiple threads to manage a plethora of processes, some of which are trivial and others of which may be life threatening. I would rather see a full redesign of the control system, reviewed by an independent group and compliant with existing real time standards rather than a redux of the existing code labeled with a 'trust us, we are engineers' sticker.
I don't see this happening - the models in question are ageing and Toyota is in business to make money, not to make people happy or safe. IMHO they will try to sweep this under the floor mats and spend more on advertising and lawyers to cover their problems rather than investing money in strengthening their engineering teams and compensating those injured by their incompentence. That may happen (strengthening their engineering teams) but it will be a reactive response. After all, they are making lots of money selling hybrids [subsidized by US taxpayers, by the way] and other technological wonders that maze the minds of those who should know better.
I don't know what the long term solution is, but I, for one, would stand up for criminal penalties for faulty products - kill someone with a known faulty product, you got to prison. That's the case with drivers who injure construciton workers - why not for manufacturers who make products that injure and/or kill people? These are not exactly equivalent cases, but the past is littered with catastrophes that resulted from the hubris of designers.
Recently Boeing was forced to ground an entire generation of new aircraft due to a battery control problem. Why doesn't the NHTSA have the authority to take faulty cars off the road? First, the problem is not as severe - a failure at 35,000 feet is much more likely to be catastrophic than one on a public highway. Still, as control systems take over more and more of the functions that a driver assumes are 'theirs' there is a creeping loss of control. Perhaps we did not realize this or were unwilling to face up to it, either as a community of responsible engineers or as a nation that relies on a governement agency as the last defense against disaster (regardless of the attempts to blame government for our own failures whether intentional or accidental).
Think of the Titanic 101 yeara ago - advertised as unsinkable with 'watertight compartments' - except the compartments did not extend the full height of the ship so that when one filled it overflowed into the next - a progressive system failure that killed more that 1,500 people. We have many more recent examples - Maverick bumper bolts that ruptured fuel tanks, Explorer tire failures that resulted in rollovers (I don't mean to single out Ford but those came to mind easily).
Back when I was making things that went out into the field I often woke at night wondering if something I had done or compromised on would result in a disaster. Fortunately there were no personal injuries connected with anything I designed or built (perhaps I should qualify that with 'as far as I know') but there was a certain amount of luck there as well as engineering horse sense.
As we move further into the age of autonomous vehicles it is time to think about what role software plays in things we are familar with - cars seem innocous and common, but the technology inside them is changing rapidly and the things we assume about the cars we drive are often no longer true - the gas pedal does not connect to the carburetor (there is no carburetor [what's a carburetor, Daddy?]) nor does the brake pedal necessarily connect directly to the hydraulic system - these are just inputs into a processor that is built w/o standards or any oversight.
Enough - this has to stop somewhere before we have 1,500 people killed at the same time by one software bug.
Welcome to the twentyfirst century. And act like grown ups, because that's what we are, no matter what images we hide behind.
After a close reading of the testimony I was wondering if the sections marked [REDACTED] were not marked in this way due to trade secret but rather due to the extreme embarassment of the software developers who developed this code base. [REDACTED] may perhaps be read as a fig leaf concealing worst practices(*) from the community rather than a protection of the rightful IP of a set of hard working engineers.
Perhaps all of us who own these vehicles should join togehter in a new Engineering Society, the Community of the [REDACTED] and label our vehicles, and, perhaps, other efforts, with the proud term [REDACTED].
What say you?
(*) I have always wondered why, in a community that celebrates 'Best Practices' there is not a contrary group that celebrates 'Worst Practices.'
IMHO Toyota should be forced to publish the complete source code of the faulty ECU, as an object lesson to the industry. Clearly it's not suitable for commerce. I can't see how confidentiality can apply when people die. Besides, the threat of having your code exposed might be a better incentive to do better than the risk of dead customers. ... only half joking.
Good questions, sixscrews. From the transcripts, if I understand them correctly, if the car goes into sudden uncommanded (by you) acceleration, you can brake, release the brake for a few tenths of a second, then brake again. But like you say, ramming the shift into reverse should also do the trick, an/or shutting off the engine.
As for Toyota, assuming what we all think we understand is factual, I'm not sure why they can't send out update kits to install. Some of this would be just new firmware that splits out apps better. And they would also want to reapportion tasks to different processing units, to split up this infamous Task X to different hardware (split out the monitoring and fail-safe functions). I'm not sure why this can't be done as a recall. Without any inside knowledge, it seems to me that once the new software architecture has been figured out, replicating it in cars out there now should be doable. We do this type of firmware update, remotely, one our systems, very frequently.
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.