The Power of 10: Rules for Developing Safety-Critical Code
Extracto
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]
Resumen
Resumen Principal
Las Reglas del Poder de 10 fueron formuladas en 2006 por Gerard J. Holzmann del Laboratorio de Software Fiable de NASA/JPL, constituyendo un conjunto de directrices críticas para la programación en lenguaje C. Su propósito fundamental es erradicar prácticas de codificación que dificultan la revisión y el análisis estático del código, promoviendo así la robustez y predictibilidad en sistemas de seguridad crítica. Estas reglas no solo complementan las directrices MISRA C, sino que también han sido integradas en los estándares de codificación de JPL, subrayando su importancia en entornos donde la fiabilidad del software es absolutamente esencial. Abordan aspectos clave desde la estructura del flujo de control y la gestión de memoria hasta la disciplina en el uso del preprocesador y los punteros, culminando en la necesidad de abordar todas las advertencias del compilador. La relevancia de estas directrices se evidenció en un estudio de NASA sobre el firmware de control de aceleración electrónica de Toyota, donde se identificaron al menos 243 infracciones de estas reglas, destacando el impacto directo en la calidad del software y la seguridad del sistema.
Elementos Clave
- Restricciones de Flujo y Gestión de Recursos: Las reglas prohíben constructos de flujo complejos como
gotoy la recursión, y exigen que todos los bucles tengan límites fijos para evitar código incontrolable. Además, se restringe la asignación de memoria heap después de la inicialización, lo que reduce la variabilidad en tiempo de ejecución y simplifica la verificación de recursos. - Modularidad y Disciplina Funcional: Se enfatiza la limitación del tamaño de las funciones a una sola página impresa, lo que promueve la modularidad y facilita la comprensión. Asimismo, se requiere un mínimo de dos aserciones en tiempo de ejecución por función, asegurando que las suposiciones clave del código sean validadas constantemente.
- Control de Datos y Punteros: Las directrices dictan la restricción del alcance de los datos al mínimo posible para limitar efectos secundarios no deseados. En cuanto al uso de punteros, se limita estrictamente a una única desreferenciación y se prohíbe el uso de punteros a funciones, mitigando algunas de las complejidades y riesgos más comunes del lenguaje C.
- Verificación Exhaustiva y Calidad de Compilación: Se exige que se verifique el valor de retorno de todas las funciones no
void(o se cast avoidsi es intencionalmente ignorado), previniendo errores de lógica silenciados. Además, se subraya la importancia de compilar el código con todas las advertencias activas y resolverlas antes del lanzamiento, asegurando un código robusto y sin ambigüedades.
Análisis e Implicaciones
La adopción de las Reglas del Poder de 10 tiene implicaciones profundas para la fiabilidad del software y la seguridad en sistemas críticos para la vida. Al imponer una disciplina rigurosa en la codificación, estas reglas promueven una base de código predecible, auditable y menos
Contenido
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]
The ten rules are:[1]
- Avoid complex flow constructs, such as goto and recursion.
- All loops must have fixed bounds. This prevents runaway code.
- Avoid heap memory allocation after initialization.
- Restrict functions to a single printed page.
- Use a minimum of two runtime assertions per function.
- Restrict the scope of data to the smallest possible.
- Check the return value of all non-void functions, or cast to void to indicate the return value is useless.
- Use the preprocessor only for header files and simple macros.
- Limit pointer use to a single dereference, and do not use function pointers.
- Compile with all possible warnings active; all warnings should then be addressed before release of the software.
The NASA study of the Toyota electronic throttle control firmware found at least 243 violations of these rules.[3][4]
- 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.
- NASA Technical Standards System Software Assurance and Software Safety Standard
- Open Source Satellite: How do you make software that is reliable enough for space missions?
Fuente: Wikimedia Foundation, Inc.