3 ms·
The list of issues seems pretty independent of any bias of the presenter: > Copyright 2014, Philip Koopman. CC Attribution 4.0 International license. • Poor i
by 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 agoThey 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.