c - Estándar Misra para software integrado
code-analysis embedded (6)
Tengo un requisito para hacer una gran cantidad de código compatible con MISRA.
Primera pregunta: ¿Alguien puede dar una estimación para pasar un código bien escrito para un sistema integrado basado en la experiencia? Entiendo que "bien escrito" está mal definido y vago, así que pido una estimación bruta.
Segunda pregunta: cualquier recomendación de herramienta que pueda personalizarse (es decir, permitir la supresión de advertencias específicas) y utilizarse en un entorno de compilación automático (es decir, interfaz de línea de comandos)
Cualquier otra sugerencia útil que pueda ayudar con esta tarea.
Gracias Ilya.
Hacer que el código Misra sea compatible no es demasiado tarea, si sigues prácticas de programación bastante buenas. Es posible que encuentre algunas de las reglas del puntero ligeramente engañosas, si el código que está tratando de cumplir tiene alguna aritmética de puntero extraño y maravilloso.
Apoyaría la recomendación de Greg para PC Lint, pero el Splint de código abierto también vale la pena mirarlo, aunque entre ellos (y el sistema de advertencia del compilador), estimo que solo podrás cubrir el 80% de las reglas de Misra - el resto probablemente necesite ser revisado por código a mano.
He usado una herramienta comercial llamada QAC . La herramienta es capaz de hacer cumplir MISRA
Tiene una interfaz de línea de comandos, por lo que puede configurarlo para que se ejecute desde un entorno de compilación automatizado. Las reglas que se aplicarán son configurables, pero esperamos que alguien dedique algún tiempo a configurarlo. La aplicación MISRA es bastante simple y funcionó lo suficientemente bien. Me dijeron (y esto es solo de tercera mano) que esta es una de las herramientas que algunas agencias (como la FDA) usan para evaluar el código. Como la mayoría de las herramientas de análisis estático, hay ruido (falsos positivos) con los que lidiar. La última vez que lo usé, no tenía un buen medio para marcar / detener la ocurrencia de un falso positivo nuevamente (sin cambiar el código del que se quejaba).
Sospecho que un ingeniero junior tomará hasta una semana (4-5 días) para configurarlo (suponiendo que estén decididos a hacerlo funcionar como lo desee).
En una nota lateral, otras herramientas comerciales de análisis estático probablemente también tengan aplicación MISRA. Según se informa (por su representante de ventas), Klocwork sí lo hace.
Uso PC Lint para el análisis estático del código C y C ++. Se puede configurar para mostrar qué reglas MISRA se han violado y tiene una interfaz de línea de comando.
También recomiendo PC-Lint. Si está compilando su código con Visual Studio, recomiendo un complemento ''Visual Lint'' de Riverblade. Si no puede compilar el código en Visual Studio, aún puede ejecutar PC-Lint desde la línea de comando con buenos resultados.
Algunos compiladores de sistemas integrados proporcionan pruebas de cumplimiento MISRA como advertencias del compilador. Uso el compilador IAR para el desarrollo Arm7 / Arm9. Proporciona una lista de verificación de conformidad MISRA fácil de configurar en la configuración del compilador.
Es difícil encontrar una regla empírica para estimar el tiempo que le llevaría hacer un código bien escrito que cumpla con MISRA. Mucho depende de los hábitos de codificación existentes de los programadores y de cuán cerca siguen las reglas MISRA en primer lugar.
Estimaciones aproximadas:
2 - 3 días para convertirse en un experto en el uso de PC-Lint.
Paso inicial para hacer que el código existente cumpla con MISRA: del 10 al 25 por ciento del tiempo dedicado a escribir el código en primer lugar.
Mantener el código compatible con MISRA: 5 a 10 por ciento agregado al desarrollo del código. La mitad de este costo está cambiando los hábitos de sus codificadores para seguir la ''manera MISRA'' de hacer las cosas. La otra mitad es el costo adicional de la prueba e inspección del código para garantizar el cumplimiento de MISRA.
Tuvimos un problema similar de adaptación de las reglas de Misra. Tuvimos algunos problemas de calidad del código en un proyecto grande y decidimos usar MISRA para mejorar la calidad del código.
Usamos el compilador Green Hills que tiene soporte para las reglas C de MISRA. También hay damas independientes disponibles. Dependiendo de lo que quieras hacer, puede ser un poco excesivo matar todas las reglas. Cambiamos una regla a la vez para dar tiempo a las personas a solucionar un número limitado de problemas similares, de lo contrario, la cantidad de errores los abruma.
Dado que nuestras advertencias fueron generadas por el compilador y no por una herramienta independiente, usted ve los errores a medida que se desarrolla y no solo cuando ejecuta el comprobador. A medida que continuamos desarrollando, obtuvimos nuestro código conforme y no en una gran explosión. Esto también evita que los viejos hábitos arruinen el nuevo código, haciendo que tenga que volver a trabajar el código nuevamente más tarde.
Algunas veces es difícil cumplir con el código anterior, ya que nadie sabe exactamente cómo funciona el código. Espero que tengas pruebas unitarias.
Aprecio que esta es una vieja pregunta, pero para el beneficio de cualquier otro arqueólogo (o buscador), es importante recordar que MISRA proporciona pautas que no siempre deben seguirse a ciegas.
Recomiendo escribir un nuevo código con MISRA en mente; por lo tanto, será mucho más fácil cumplir con los requisitos.
Sin embargo, esto no siempre es posible, y en particular, cuando se intenta utilizar el código de ingeniería inversa para cumplir con las pautas. En este caso, sugiero que se concentre en las reglas requeridas y que trate los avisos como un bono ... ¡el costo y el beneficio se aplican también aquí!
Además, tenga en cuenta que hay un proceso de desviación: es mejor mantener el código limpio y mantenible con una desviación, que idear algunos espaguetis dóciles pero ilegibles.