I think this is one of the most interesting software stories in recent years, up there with Stuxnet.
The software development process seems so staggeringly, jaw-droppingly incompetent and negligent, and it now seems clear that software flaws really did kill people despite the heavy layer of spin that it was driver error, floor mats, etc.
I almost certainly couldn't buy a Toyota ever again knowing this. But it also really makes me wonder: how bad is the QA and testing for the software components of other carmakers' vehicles?
That's what I mean; I don't necessarily think it is (which is scary).
Maybe we only got to know how horribly flawed the software situation is at Toyota because they had finally had enough people killed that they just couldn't keep it hidden any longer, and Audi and Honda are just as bad and just haven't yet had this kind of exposure event.
I would prefer to doubt that, but it does all kind of make me want to buy a restored 1978 Datsun with carburetors and mechanical everything.
This makes me want a Tesla. That company actually seems to hire qualified engineers given the failure modes it's had in the exceedingly rare cases of accidents that have thus far made the news.
Idk... there was an article on here a while ago about how after the Ford/Firestone tires = death incidents a decade and a half ago actually resulted in Ford making much better quality cars.
It doesn't seem at all clear to me that it was "spin" when there were cases of floor mats getting caught under the pedal, incidents of driver error, and physical problems.
It also is striking that the analysis could not provide an example of a single error condition that would cause the crash scenario. It's only a high level analysis.
It probably wasn't just spin -- Toyota probably didn't initially believe that they had a multiple-fatality software bug. When I first read some of the news stories about this, years ago, I also thought it sounded far-fetched that a bug that caused your car to accelerate to 100+ mph and crash could have made it all the way to production.
But it is important to note that the post we are all commenting on here isn't "the" analysis. This is just an academic case study of this now-infamous and interesting case, based on public information.
The closest thing that we have to "the" analysis on this (since we will never see Toyota's internal analyses) is, as tokenrove linked to elsewhere in this thread, the one Michael Barr did that was the main analysis[1][2][3] used in the court case against Toyota.
But there have been a lot of other interesting articles and posts on this case, other than just this one.
How hard would it be to get an old prius from a junk yard, extract the ECU, extract the software from there and reverse assemble and annotate the whole thing?
The hardest part I figure would be getting around the inevitable read protection but there are some folks that have done very interesting things in this arena (for instance, reading out pic chips that had their read fuses blown).
Your comments about the software development process reminds me of the arguments from a few years ago, against open source software, like linux. One of the arguments for professionally made, closed source, proprietary software (like Microsoft windows), was that; programmers getting paid by a corporation would obviously develop better software than a bunch of unpaid, unprofessional, part-time hackers. Funny how much that argument has changed today.
The software development process seems so staggeringly, jaw-droppingly incompetent and negligent, and it now seems clear that software flaws really did kill people despite the heavy layer of spin that it was driver error, floor mats, etc.
I almost certainly couldn't buy a Toyota ever again knowing this. But it also really makes me wonder: how bad is the QA and testing for the software components of other carmakers' vehicles?