¿Qué herramientas o estándares se pueden usar para mejorar la confiabilidad del código C incorporado?

La validación de código incrustado es complicada, especialmente cuando se trata de partes de recursos limitados como los PIC. Con frecuencia, no puede permitirse el lujo de codificar en casos de prueba debido a las restricciones de memoria de la pieza y la programación a menudo "en tiempo real" realizada en este tipo de dispositivos.

Estas son algunas de mis pautas:

1. Escriba una especificación si no hay una: Si no está codificando contra una especificación, documente lo que se supone que debe hacer su código, cuáles son las entradas válidas, cuáles son las salidas esperadas , cuánto tiempo debe durar cada rutina, qué se puede y qué no se puede eliminar, etc. - una teoría de operación, diagramas de flujo, cualquier cosa es mejor que nada.

2. Comente su código: El hecho de que algo sea obvio para usted no significa que sea obvio (o correcto) para otra persona. Los comentarios en lenguaje sencillo son necesarios tanto para la revisión como para la capacidad de mantenimiento del código.

3. Código a la defensiva: No solo incluya el código para las entradas normales. Maneje las entradas faltantes, las entradas que están fuera de rango, los desbordamientos matemáticos, etc. - cuantas más esquinas cubra con su diseño de código, menos grados de libertad tendrá el código cuando se implementa.

4. Use herramientas de análisis estático: puede ser humillante la cantidad de errores que las herramientas como PC-lint pueden encontrar en su código. Considere un análisis estático limpio como un buen punto de partida para pruebas serias.

5. Las revisiones por pares son esenciales: Su código debe estar limpio y bien documentado, de manera que una parte independiente pueda revisarlo de manera eficiente. Revise su ego en la puerta y considere seriamente cualquier crítica o sugerencia hecha.

6. Las pruebas son esenciales: debe hacer su propia validación, así como tener una validación independiente del código. Otros pueden romper tu código de maneras que posiblemente no puedas imaginar. Pruebe todas las condiciones válidas y todas las condiciones no válidas que pueda imaginar. Use PRNGs y alimente datos de basura. Haga lo que pueda para romper cosas, luego repare e intente nuevamente. Si tiene suerte, podrá ejecutar su código en modo de depuración y echar un vistazo a los registros y las variables. Si no, tendrá que ser astuto y alternar los LED / señales digitales para tener una idea del estado de su dispositivo. Haga lo que sea necesario para obtener los comentarios que necesita.

7. Mire debajo del capó: No tenga miedo de mirar el código de máquina generado por su compilador de C. Puede (¿va a?) Encontrar lugares donde su hermoso código C se haya inflado en decenas, si no en cientos de operaciones, donde algo que debería ser seguro (ya que es solo una línea de código, ¿no?) Lleva tanto tiempo ejecutar esas múltiples interrupciones Han despedido e invalidado las condiciones. Si algo se vuelve horriblemente ineficiente, refácelo e inténtelo de nuevo.

La mayoría de las mismas técnicas para crear software confiable en una PC también son aplicables al desarrollo integrado. Es útil separar sus algoritmos del código específico del hardware y probarlos por separado con pruebas unitarias, simulaciones, análisis estático y herramientas como Valgrind. De esa manera, hay mucho menos código que solo se prueba en el hardware.

No abandonaría a C. Si bien los idiomas como Ada pueden ofrecer algunas garantías menores, es fácil caer en la trampa de pensar que el lenguaje promete más de lo que realmente hace.

MISRA-C es de hecho muy útil para mejorar la calidad del código general y minimizar errores. Solo asegúrate de leer y entender todas las reglas, la mayoría de ellas son buenas, pero algunas de ellas no tienen ningún sentido.

Una advertencia aquí. El documento MISRA asume que el lector es alguien con un amplio conocimiento del lenguaje C. Si no tiene un veterano de C más sólido en su equipo, pero decide obtener un analizador estático y luego sigue ciegamente todas las advertencias, es probable que se obtenga un código de calidad inferior , ya que podría estar reduciendo la legibilidad. e introducir errores por accidente. He visto que esto sucede muchas veces, la conversión de código a conformidad con MISRA no es una tarea trivial.

Hay dos versiones del documento MISRA-C que pueden aplicarse. O bien MISRA-C: 2004, que sigue siendo el estándar de facto de la industria integrada actual. O el nuevo MISRA-C: 2012 que es compatible con el estándar C99. Si nunca ha usado MISRA-C antes, le recomendaría que implementara esta última.

Sin embargo, tenga en cuenta que los proveedores de herramientas generalmente se refieren a MISRA-C: 2004 cuando dicen que tienen una comprobación de MISRA (a veces incluso se refieren a la versión obsoleta de MISRA-C: 1998). Por lo que sé, el soporte de la herramienta para MISRA-C: 2012 todavía es limitado. Creo que solo algunos analizadores estáticos lo han implementado hasta ahora: Klocwork, LDRA, PRQA y Polyspace. Podría ser más, pero definitivamente necesitas verificar qué versión de MISRA es compatible.

Antes de decidir, por supuesto, puede comenzar por leer el documento MISRA y ver qué implica. Se puede comprar por £ 10 en misra.org , bastante asequible en comparación con los precios para las normas ISO.

Mathworks (la gente de MATLAB) tiene una herramienta de análisis de código estático llamada Polyspace .

Además del análisis de código estático, la pelusa y similares, sugeriría una cuidadosa definición y diseño de interfaces (con un proceso de revisión formal) y un análisis de cobertura de código.

Es posible que también desee consultar las pautas para el diseño de códigos críticos para la seguridad, incluidos MISRA, pero también las normas UL1998 e IEC 61508.

Para obtener una respuesta completa a esta pregunta, suprimiría la idea de "confiabilidad del código" y, en cambio, pensaría sobre "confiabilidad del diseño", porque el código es solo la expresión final del diseño.

Entonces, comience con los requisitos y escriba e inspeccione esos. Si no tiene un documento de requisitos, señale una línea de código aleatoria y pregúntese "¿por qué se necesita esa línea?" La necesidad de cualquier línea de código eventualmente debería ser rastreable a un requerimiento, incluso si es tan simple / obvio como "la fuente de alimentación debe generar 5VDC si la entrada está entre 12-36VDC". Una forma de pensar acerca de esto es que si esa línea de código no se puede rastrear a un requisito, ¿cómo sabes que es el código correcto o que es necesario?

A continuación, verifica tu diseño. Está bien si está completamente en el código (por ejemplo, en los comentarios), pero eso hace que sea más difícil saber si el código está haciendo lo que realmente significa. Por ejemplo, el código puede tener una línea que lee output = 3 * setpoint / (4 - (current * 5)); ¿Es current == 4/5 una entrada válida que podría causar un bloqueo? ¿Qué se debe hacer en este caso para evitar la división por cero? ¿Evita la operación por completo o degrada la salida? Tener una nota general en su documento de diseño sobre cómo manejar estos casos de borde hace que sea mucho más fácil verificar el diseño a un nivel superior. Por lo tanto, ahora la inspección del código es más fácil porque es una cuestión de verificar si el código implementa correctamente ese diseño.

Junto con eso, la inspección del código debe verificar si hay errores comunes que su IDE no detecta (está utilizando un IDE, ¿verdad?) como '=' cuando quiso decir '==', faltas que cambian el significado de declaraciones 'if', puntos y coma donde no deberían estar, etc.

Mientras escribo esto, se me ocurre que es realmente difícil resumir los años de capacitación / experiencia en calidad de software en una sola publicación. Escribo código para dispositivos médicos y lo anterior es un resumen extremadamente simplificado de cómo lo abordamos.