3 ms·
I followed the accelerator-gate thing fairly closely, and I came out pretty convinced it was a computer failure. If it wasn't Toyota's floor mats were many tim
by rstuart4133 5y ago
I followed the accelerator-gate thing fairly closely, and I came out pretty convinced it was a computer failure. If it wasn't Toyota's floor mats were many times more likely to jam the accelerator than any other make or model.
There was a plausible root cause - a bit flip in the CPU. It was proved such flipping the right bit would cause uncontrolled acceleration that characterised each event.
I don't agree Toyota was guilty of shoddy work, or cost cutting. At worst, there were guilty of working some fairly shitty, hard to support code. (Someone below mentions 10,000 global variables.) If anything that shitty code just proves how dedicated Toyota was to testing something until until all the safety related bugs are gone, because despite some horrid kludges like replying on watch dogs resetting the thing when it got stuck and a reset so fast most people wouldn't notice it, despite the intense scrutiny of the code no one every found a safety issue with it. Toyota was well aware of a electrically noisy area like a engine bay could cause bit lips, and defended against it. Every variable was stored in two places in RAM, and on use they were always read and compared, and if they differed it was reset.
Sadly for Toyota they used a proprietary ECU and OS provided by NEC. NEC didn't let their customers look at their proprietary stuff. NEC didn't defend against bit flips. And it turned out a bit flop in a task ready bit could cause that task to never be scheduled again. If that task was supposed to turn off the cruise control acceleration, then bingo.
I have no idea what changes Toyota made in response to this mess, but if I was to hazard a guess it would be when it comes to software, they demand their supplies open their source to them.