3 ms·

> I testified as a Plaintiff expert witness This slide is written by someone that has a bias. I have not seen any independent confirmation that the Toyota pro

> I testified as a Plaintiff expert witness This slide is written by someone that has a bias. I have not seen any independent confirmation that the Toyota problem was caused by a software issue (and indeed the slides mention that NASA looked at it and did not find such an issue).

matthewdgreen 5y ago
NASA looked at it well before the analysis mentioned in the slide deck, and it was a much shorter analysis and simply did not find this flaw. Toyota had their own technical experts and plenty of opportunity to publish technical reports rebutting it. I am not aware of any place where they did so, and they certainly had the opportunity (nobody is muzzling them.) I believe that maybe Toyota did argue that there was no evidence that this flaw caused the actual events in the field, which is true but also not a rebuttal exactly.
photochemsyn 5y ago
The list of issues seems pretty independent of any bias of the presenter: > Copyright 2014, Philip Koopman. CC Attribution 4.0 International license. • Poor isolation of task functions • “Kitchen Sink” “Task X” both computes throttle angle AND is responsible for many of the failsafes (same CPU, same task). Brake Override function in 2010 MY Camry is in this same task. [Bookout 2013-10-14 AM 80:5-82:16] • OSEK RTOS not certified; 80% CPU load (> 70% RMA limit) [Bookout 2013-10-14PM 42:6-25] [NASA App. A p. 119] • Many large functions – 200 functions exceeded 75 lines of non-comment code [NASA App. A p. 23] • Reviews informal and only on some modules [Bookout 2013-10-11 PM 29:24-30:5; 2013-10-14 49:17-21] • No formal specifications [Bookout 2013-10-11 PM 29:24-30:5] • No bug tracking system [Bookout 2013-10-14 PM 49:3-50:23] • No configuration management [Bookout 2013-10-11 PM 30:7-10] That doesn't look good. No bug tracking system? Large functions with no comments? Certainly not best practices as I've ever seen them described.
- elfchief 5y ago
  They also followed almost none of the guidelines in the MISRA C standard, which is a standard developed by the automotive industry specifically for helping to ensure that code running on car computers is up to at least some standard.
- Stratoscope 5y ago
  > > • Many large functions – 200 functions exceeded 75 lines of non-comment code [NASA App. A p. 23] > Large functions with no comments? I don't think that's what the citation says. It says the functions had more than 75 lines of code not counting any comments. It doesn't say there were no comments in these functions. Nitpick aside, I'm sure we can all agree that a large number of such lengthy functions is not good practice.
buescher 5y ago
Toyota lost the lawsuit on their development processes and firmware design. As far as I know, no specific bug that would cause unintended acceleration was ever found.
- elfchief 5y ago
  IIRC, they did identify a bit that if it were flipped in a certain way at a certain time, would lead to the struck throttle condition, and were able to successfully replicate the stuck throttle condition by 'manually' flipping that bit. So they never reproduced the problem in the field, but they could force a condition that would cause it -- and for a one-in-a-million thing like a cosmic ray bit flip, that seems like a reasonable methodology. (and was only a problem because they didn't handle critical variables correctly, by having mirrors of the values that could be compared to protect against various types of corruption)
  - buescher 5y ago
    Koopman is the real deal. Big fan of the RTX-2000 here, and his embedded software book is excellent. But my recollection is that he and Barr found no such particular bit - the argument was, if one task failed, which could be due to any number of potential bugs, perhaps just one bit getting flipped, the unintended acceleration could happen. The material from Barr is worth reading too (google it), and if you want some amusement: https://www.embedded.com/why-every-embedded-software-developer-should-care-about-the-toyota-verdict/ https://www.embedded.com/why-every-embedded-software-develop... https://www.embedded.com/a-rebuttal-to-why-every-embedded-software-developer-should-care-about-the-toyota-verdict/ https://www.embedded.com/a-rebuttal-to-why-every-embedded-so...
- bsder 5y ago
  > Toyota lost the lawsuit on their development processes and firmware design. As far as I know, no specific bug that would cause unintended acceleration was ever found. I truly believe that it was human factors and not a computer failure. I've been in similar situations and had a acquaintance drive through a wall because of human factors. In our case, the parking lot was relatively flat but had a drainage channel at the front. So, you could put your car into reverse, release the brake, and your car would roll forward. Quite unnerving if you are driving a stick, but your brain processes it because you are used to rolling in the wrong direction. If you are driving an automatic, you smack the accelerator, jump across way too small gap between you and a building, and bury your car trunk in an office wall. Nevertheless, I'm also quite happy that Toyota got smacked as their development process was TERRIBLE. They 100% deserved what they got even if it wasn't a computer bug.

matthewdgreen 5y ago

NASA looked at it well before the analysis mentioned in the slide deck, and it was a much shorter analysis and simply did not find this flaw. Toyota had their own technical experts and plenty of opportunity to publish technical reports rebutting it. I am not aware of any place where they did so, and they certainly had the opportunity (nobody is muzzling them.) I believe that maybe Toyota did argue that there was no evidence that this flaw caused the actual events in the field, which is true but also not a rebuttal exactly.

photochemsyn 5y ago

The list of issues seems pretty independent of any bias of the presenter: > Copyright 2014, Philip Koopman. CC Attribution 4.0 International license. • Poor isolation of task functions • “Kitchen Sink” “Task X” both computes throttle angle AND is responsible for many of the failsafes (same CPU, same task). Brake Override function in 2010 MY Camry is in this same task. [Bookout 2013-10-14 AM 80:5-82:16] • OSEK RTOS not certified; 80% CPU load (> 70% RMA limit) [Bookout 2013-10-14PM 42:6-25] [NASA App. A p. 119] • Many large functions – 200 functions exceeded 75 lines of non-comment code [NASA App. A p. 23] • Reviews informal and only on some modules [Bookout 2013-10-11 PM 29:24-30:5; 2013-10-14 49:17-21] • No formal specifications [Bookout 2013-10-11 PM 29:24-30:5] • No bug tracking system [Bookout 2013-10-14 PM 49:3-50:23] • No configuration management [Bookout 2013-10-11 PM 30:7-10] That doesn't look good. No bug tracking system? Large functions with no comments? Certainly not best practices as I've ever seen them described.

elfchief 5y ago
They also followed almost none of the guidelines in the MISRA C standard, which is a standard developed by the automotive industry specifically for helping to ensure that code running on car computers is up to at least some standard.
Stratoscope 5y ago
> > • Many large functions – 200 functions exceeded 75 lines of non-comment code [NASA App. A p. 23] > Large functions with no comments? I don't think that's what the citation says. It says the functions had more than 75 lines of code not counting any comments. It doesn't say there were no comments in these functions. Nitpick aside, I'm sure we can all agree that a large number of such lengthy functions is not good practice.

buescher 5y ago

Toyota lost the lawsuit on their development processes and firmware design. As far as I know, no specific bug that would cause unintended acceleration was ever found.

elfchief 5y ago
IIRC, they did identify a bit that if it were flipped in a certain way at a certain time, would lead to the struck throttle condition, and were able to successfully replicate the stuck throttle condition by 'manually' flipping that bit. So they never reproduced the problem in the field, but they could force a condition that would cause it -- and for a one-in-a-million thing like a cosmic ray bit flip, that seems like a reasonable methodology. (and was only a problem because they didn't handle critical variables correctly, by having mirrors of the values that could be compared to protect against various types of corruption)
- buescher 5y ago
  Koopman is the real deal. Big fan of the RTX-2000 here, and his embedded software book is excellent. But my recollection is that he and Barr found no such particular bit - the argument was, if one task failed, which could be due to any number of potential bugs, perhaps just one bit getting flipped, the unintended acceleration could happen. The material from Barr is worth reading too (google it), and if you want some amusement: https://www.embedded.com/why-every-embedded-software-developer-should-care-about-the-toyota-verdict/ https://www.embedded.com/why-every-embedded-software-develop... https://www.embedded.com/a-rebuttal-to-why-every-embedded-software-developer-should-care-about-the-toyota-verdict/ https://www.embedded.com/a-rebuttal-to-why-every-embedded-so...
bsder 5y ago
> Toyota lost the lawsuit on their development processes and firmware design. As far as I know, no specific bug that would cause unintended acceleration was ever found. I truly believe that it was human factors and not a computer failure. I've been in similar situations and had a acquaintance drive through a wall because of human factors. In our case, the parking lot was relatively flat but had a drainage channel at the front. So, you could put your car into reverse, release the brake, and your car would roll forward. Quite unnerving if you are driving a stick, but your brain processes it because you are used to rolling in the wrong direction. If you are driving an automatic, you smack the accelerator, jump across way too small gap between you and a building, and bury your car trunk in an office wall. Nevertheless, I'm also quite happy that Toyota got smacked as their development process was TERRIBLE. They 100% deserved what they got even if it wasn't a computer bug.