When you buy an automobile. You rely on the manufacture to give you the most reliable vehicle available. 100 years ago this may not be the case, but today, we expect it. If there is anything that causes us to have less than a perfect experience, it will cause recourse. I am surprised that Toyota is seeing this, but it is normal to see companies rise and fall.
In reading this article, I felt sympathy for the people who died and their families. Toyota could have made it simplier on them and admitted the problem had to do with software. They had to recall the vehicles anyways.
@Susan: I have been following this article and threads and thought has come to me that this is not a new situation in the transport industry. It goes a long way back before software, I was looking up the worst all time cars and googled Ralph Nader who wrote a book called "Unsafe At Any Speed,". I also know of buses that had power surges for no reason at all and railway safety has only been driven forward to safer practices by disasters.
One of the big problems is that corporations have a very short memory regarding how they came to a disaster, this is because the people who were there at the time of a disater / design flaw move on or retire and the cycle starts again.
Is it possible to build in a management process to a company that learns from previous problems or wants to?
Yes, given that this has been happening for a number of years, even if infrequently, one wonders why the people involved in the design of this software didn't have second thoughts about their architecture. You know, while commuting to and from work, for instance. Even if the heavies didn't know, seems hard to believe that no one had on of those "oh sh**" moments, going back over the code. No?
@Crusty: Yes, there's nothing new under the sun. This story is an old one, as you say, especially for the automotive industry. Short memory syndrome and complacency---it is human nature after all.
It's precisely because of Ralph Nader's book and the way the American car manufacturers treated customers that generations of the American car-buying public had so much faith in basic quality and value of Japanese cars. Too bad Toyota squandered that good faith. Consumers had the impression that Japanese car makers had a built-in process that produced good cars -- cars you wouldn't have to take to the shop constantly -- and that wouldn't kill or injure you (you were still capable of getting yourself in trouble, in the wrong spot at the wrong time---but that's just the nature of driving a car).
That reputation for quality followed by good ratings was why Americans bought Toyota. This case definitely damages that reputation more than it would have if they fessed up in the beginning. Consumers often have longer, irrational memory: some people won't buy American because they remember that bad days of the industry, even though times may have changed.
As software becomes more complex and does more in cars, I hope software teams follow good processes for testing their code.
And there is just a plain mix up? I believe I read that Ariane 5 had Ariane 4 software loaded for it's first time off? Even here it's not a mistake or an accident but a failure in process control.
As a past assurance engineer for a very large fire protection agency, the ability for the wrong operating parameters to be loaded into fire alarms, caused me to order a change in the upgrading and loading software for the fire alarms we used.
I just hate to think what the casual chip hacker can do to the operating parameters of a modern car EMU.
Am I paranoid or could I also worry about some software being sabotaged for state or commercial imperative?
I will put excerpts here, in Betsy Benjaminson's own words.
First and most shocking were the reports horrified drivers wrote about their runaway cars. Second were startling emails Toyota's engineers had sent each other. They were searching for UA's root causes, but they could not seem to find them.
They sometimes admitted it was the electronic parts, the engine computer, the software, or interference by radio waves. Meanwhile, efforts were made to find floor mats that would trap gas pedals and conveniently explain UA. The R&D chief admitted that incompletely developed cars had gone into production and that quality control of parts was poor or non-existent.
Third, I read many descriptions by executives and managers of how they had hoodwinked regulators, courts, and even Congress, by withholding, omitting, or misstating facts.
Last, and most damning, I found Toyota's press releases to be bland reassurances obviously meant to help maintain public belief in the safety of Toyota's cars—despite providing no evidence to support those reassurances. I saw a huge gap between the hard facts known by engineers and executives and the make-believe produced for public consumption by Toyota's PR department.
Stuxnet is now open source and configurable and could potentially be used by anyone.
"I just hate to think what the casual chip hacker can do to the operating parameters of a modern car EMU."
The mind boggles at the possibility of a chip hacker mixing a bit of scrambled egg with what was described in the Bookout case as "spaghetti" software. What would happen if they tried to reorganize the "kitchen sink" tasks as part of the tuning process?
"As a past assurance engineer for a very large fire protection agency, the ability for the wrong operating parameters to be loaded into fire alarms, caused me to order a change in the upgrading and loading software for the fire alarms we used".
You raise a very important issue. In any manufacturing organization design variation has to be controlled very carefully. I expect that Toyota will have the assembly process under pretty good control with the correct parts delivered to assembly points for the particular batch build. However, with software change control may be more difficult.
I wonder how Toyota control the issue of upgrade software to their dealers and do they inform owners when a software upgrade has been done?
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.