The Power of Ten – Rules for Developing Safety Critical Code
1–10 of 155 posts
Re: The Power of Ten – Rules for Developing Safety Critical Code
#2The original paper describing and justifying these rules in more detail is at http://spinroot.com/gerard/pdf/P10.pdf, and the official document is at http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
Re: The Power of Ten – Rules for Developing Safety Critical Code
#3Found the rule
`There shall be no use of dynamic memory allocation after task
initialization.`
They must use pre-allocated string buffers for some of the task's. Though I figured if you're doing a flight controller for a jet fighter or sate-light you don't need a lot of string parsing.
Re: The Power of Ten – Rules for Developing Safety Critical Code
#4Found the rule `There shall be no use of dynamic memory allocation after task initialization.` They must use pre-allocated string buffers for some of the task's. Though I figured if you're doing a flight controller for a jet fighter or sate-light you don't need a lot of string parsing.
Almost all of the programs that I have ever read parse strings far too often. Almost all scientific and engineering software can eliminate it except at the UI and database.
Re: The Power of Ten – Rules for Developing Safety Critical Code
#5These are basically a subset of rules that MISRA defines for C programming.
Re: The Power of Ten – Rules for Developing Safety Critical Code
#6Found the rule `There shall be no use of dynamic memory allocation after task initialization.` They must use pre-allocated string buffers for some of the task's. Though I figured if you're doing a flight controller for a jet fighter or sate-light you don't need a lot of string parsing.
I have written software for mobile network base stations where there were hardly any strings. I think it was only process names and log messages, both of which were string constants.
I imagine unmanned space software is similar; there is little need for a text UI on the spacecraft itself.
Re: The Power of Ten – Rules for Developing Safety Critical Code
#7> Do not use [..] direct or indirect recursion.
Ok.. I get it that they don't want their C programmers to do that, but do they also mean that this is to "complex" for normal developers to implement in a fault-free manner?
Re: The Power of Ten – Rules for Developing Safety Critical Code
#8All of these make perfect sense, but I would have allowed tail recursion (and only that). Its properties are well-defined and boundedness can be easily proven (also it is easy to distinguish tail and non-tail recursive calls).
Re: The Power of Ten – Rules for Developing Safety Critical Code
#9Found the rule `There shall be no use of dynamic memory allocation after task initialization.` They must use pre-allocated string buffers for some of the task's. Though I figured if you're doing a flight controller for a jet fighter or sate-light you don't need a lot of string parsing.
dynamic memory allocation is very much frowned upon in embedded systems, not just for strings.
Everything should be static and deterministic at all times. This is the easiest/only way to ensure you have no resource issues.
You should always (statically) allocate for maximum/worst case.. because you have analysed your worst-case, haven't you?
Re: The Power of Ten – Rules for Developing Safety Critical Code
#10Found the rule `There shall be no use of dynamic memory allocation after task initialization.` They must use pre-allocated string buffers for some of the task's. Though I figured if you're doing a flight controller for a jet fighter or sate-light you don't need a lot of string parsing.
What counts as a task?