Jump to content

The Power of 10: Rules for Developing Safety-Critical Code

From Wikipedia, the free encyclopedia

The Power of 10 Rules were created in 2006 by Gerard J. Holzmann of the NASA/JPL Laboratory for Reliable Software.[1] The rules are intended to eliminate certain C coding practices that make code difficult to review or statically analyze. These rules are a complement to the MISRA C guidelines and have been incorporated into the greater set of JPL coding standards.[2]

Rules

[edit]

The ten rules are:[1]

  1. Restrict all code to very simple control flow constructs—do not use goto statements, setjmp or longjmp constructs, or direct or indirect recursion.
  2. Give all loops a fixed upper bound. It must be trivially possible for a checking tool to prove statically that the loop cannot exceed a preset upper bound on the number of iterations. If a tool cannot prove the loop bound statically, the rule is considered violated.
  3. Do not use dynamic memory allocation after initialization.
  4. No function should be longer than what can be printed on a single sheet of paper in a standard format with one line per statement and one line per declaration. Typically, this means no more than about 60 lines of code per function.
  5. The code's assertions density should average to minimally two assertions per function. Assertions must be used to check for anomalous conditions that should never happen in real-life executions. Assertions must be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken such as returning an error condition to the caller of the function that executes the failing assertion. Any assertion for which a static checking tool can prove that it can never fail or never hold violates this rule.
  6. Declare all data objects at the smallest possible level of scope.
  7. Each calling function must check the return value of nonvoid functions, and each called function must check the validity of all parameters provided by the caller.
  8. The use of the preprocessor must be limited to the inclusion of header files and simple macros definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed. All macros must expand into complete syntactic units. The use of conditional compilation directives must be kept to a minimum.
  9. The use of pointers must be restricted. Specifically, no more than one level of dereference should be used. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. function pointers are not permitted.
  10. All code must be compiled, from the first day of development, with all compiler warnings enabled at the most pedantic setting available. All code must compile without warnings. All code must also be checked daily with at least one, but preferably more than one, strong static source code analyzer and should pass all analyses with zero warnings.

Uses

[edit]

The NASA study of the Toyota electronic throttle control firmware found at least 243 violations of these rules.[3][4]

See also

[edit]

Further reading

[edit]
  • G.J. Holzmann (2006-06-19). "The Power of 10: Rules for Developing Safety-Critical Code". IEEE Computer. 39 (6): 95–99. doi:10.1109/MC.2006.212.

References

[edit]
  1. ^ a b The Power of 10: Rules for Developing Safety-Critical Code
  2. ^ JPL C Coding Standard - JPL Laboratory for Reliable Software
  3. ^ Barr, Michael (2011-03-01). "Unintended Acceleration And Other Embedded Software Bugs". Embedded Gurus. Archived from the original on 2024-02-26. Retrieved 2025-03-03.
  4. ^ "NASA Engineering and Safety Center Technical Assessment Report, National Highway Traffic Safety Administration Toyota Unintended Acceleration Investigation, Appendix A" (PDF). 2011-01-18. Archived from the original (PDF) on 2022-06-25. Retrieved 2025-03-03.
[edit]
Retrieved from "https://en.wikipedia.org/w/index.php?title=The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code&oldid=1321971739"