There was a court case later that investigated the firmware of the drive by wire...

vilhelm_s · on April 28, 2015

The court case showed that the throttle control programming was shoddy in various ways, but I don't think they demonstrated any observably buggy behavior, let alone any proof that software faults were behind any particular accident.

I think it's also quite possible that there never were any abnormal unintended accelerations, but the media debacle caused people to carefully investigate the cars, at which point they discovered that the programming was bad.

pnathan · on April 28, 2015

They actually demonstrated buggy behaviour, as well as the number of paths that could lead to that behaviour (very large).

ArkyBeagle · on April 27, 2015

It's hard to say whether it should or not. Something like that, sure. Perhaps not exactly the same thing.

kijin · on April 28, 2015

> similar to what is required for FDA medical devices

Given how often we hear about gaping security holes in all sorts of medical devices, that doesn't seem like a particularly high standard.

Does anyone know whether Boeing and Airbus have higher standards for software quality?

EpicEng · on April 28, 2015

Well, I've spent the last decade designing FDA cleared systems (class I and class III), and I can tell you that it is. That doesn't mean that mistakes aren't made, and it doesn't mean that you can't outright lie in documentation. There's no way the FDA could catch that short of replicating all of your V&V.

However, most of us aren't trying to cheat, and I can tell you that the amount of engineering rigor that goes into a medical device is leagues beyond what most software devs have ever been a part of. At my company we don't hire "developers"; we hire engineers who have programming in their toolbox.

Medical software screwups are high profile. You don't hear about every bug that the next "disruptive startup" lets into the wild.