MISRA C es un conjunto de pautas de desarrollo de software para el lenguaje de programación C desarrollado por el Consorcio MISRA . Sus objetivos son facilitar la seguridad , la portabilidad y la confiabilidad del código en el contexto de los sistemas integrados , específicamente aquellos sistemas programados en ISO C /C90/ C99 . [1 ]
También hay un conjunto de pautas para MISRA C++ que no se tratan en este artículo.
En las dos primeras ediciones de MISRA-C (1998 y 2004), todas las Directrices se consideraban reglas. Con la publicación de MISRA C:2012 se introdujo una nueva categoría de Directrices: las Directivas cuyo cumplimiento está más abierto a la interpretación o se relaciona con cuestiones procesales o de procedimiento.
Aunque originalmente estaba destinado específicamente a la industria automotriz, MISRA C ha evolucionado hasta convertirse en un modelo ampliamente aceptado de mejores prácticas por los principales desarrolladores de sectores como el automotriz, aeroespacial, telecomunicaciones, dispositivos médicos, defensa, ferrocarriles y otros. Por ejemplo:
Cuando se inicia un nuevo proyecto de software, se debe utilizar el estándar MISRA más reciente. Los estándares anteriores aún están disponibles para su uso en proyectos de software antiguos que necesitan hacer referencia a él. [9]
Cada directriz se clasifica [10] como obligatoria (novedad en MISRA C:2012), obligatoria o consultiva . Además, el documento de cumplimiento de MISRA permite que las directrices consultivas no se apliquen .
Las reglas se pueden dividir lógicamente en varias categorías:
inttipo de C puede variar pero int16_t(estandarizado en C99) siempre es de 16 bits.mallocpuede fallar.La norma MISRA C:2012 clasifica por separado cada directriz como Unidad de Traducción Única o Sistema . [10]
MISRA C:2012 clasifica las reglas (pero no las directivas ) como decidibles o indecidibles .
MISRA publicó documentos para brindar orientación adicional para comprender y lograr el cumplimiento de MISRA.
Para que un software pueda considerarse conforme a las Directrices MISRA C, se deben cumplir todas las normas obligatorias y todas las normas y directivas obligatorias o deben estar sujetas a una desviación formal. Las normas recomendadas pueden dejar de aplicarse sin una desviación formal, pero esto debe quedar registrado en la documentación del proyecto.
Nota: Para efectos de cumplimiento, no existe distinción entre reglas y directivas .
Muchas reglas de MISRA C pueden caracterizarse como pautas porque, en determinadas condiciones, los ingenieros de software pueden desviarse de las reglas y, aun así, considerarse que cumplen con el estándar. Las desviaciones deben documentarse en el código o en un archivo. Además, se debe proporcionar una prueba de que el ingeniero de software ha considerado la seguridad del sistema y que desviarse de la regla no tendrá un impacto negativo; los requisitos para las desviaciones también incluyen:
La primera edición de MISRA C, "Directrices para el uso del lenguaje C en software basado en vehículos", que se publicó en 1998 y se conoce oficialmente como MISRA-C:1998 . [14]
MISRA-C:1998 tiene 127 reglas, de las cuales 93 son obligatorias y 34 son consultivas; las reglas están numeradas en secuencia del 1 al 127.
En 2004, se produjo una segunda edición, "Directrices para el uso del lenguaje C en sistemas críticos ", o MISRA-C:2004 , con muchos cambios sustanciales en las directrices, incluida una renumeración completa de las reglas.
MISRA-C:2004 contiene 142 reglas, de las cuales 122 son "obligatorias" y 20 son "recomendadas"; están divididas en 21 categorías temáticas, desde "Entorno" hasta "Errores en tiempo de ejecución".
En 2013 se publicó la tercera edición, MISRA C:2012, que amplía el soporte a la versión C99 del lenguaje C (manteniendo las directrices para C90), además de incluir una serie de mejoras que pueden reducir el coste y la complejidad del cumplimiento, al tiempo que favorecen un uso coherente y seguro de C en sistemas críticos. [15]
MISRA-C:2012 contiene 143 reglas y 16 "directivas" (es decir, reglas cuyo cumplimiento está más abierto a la interpretación o se relaciona con cuestiones procesales o de procedimiento); cada una de las cuales se clasifica como obligatoria , requerida o consultiva . Se clasifican por separado como Unidad Única de Traducción o Sistema . Además, las reglas se clasifican como Decidibles o Indecidibles .
En abril de 2016, MISRA publicó (como descarga gratuita) MISRA C:2012 - Enmienda 1: Pautas de seguridad adicionales [16] que agregó catorce nuevas pautas de seguridad .
En febrero de 2020, MISRA publicó (como descarga gratuita) MISRA C:2012 - Enmienda 2: Actualizaciones para la funcionalidad principal de ISO/IEC 9899:2011/18 [17] que agrega mapeo para los comportamientos no definidos, no especificados y definidos por la implementación dentro de C11/C18.
MISRA ha publicado las siguientes adendas para apoyar MISRA C:2012:
En mayo de 2023, MISRA publicó MISRA C:2023 (MISRA C Tercera edición, Segunda revisión) que incorpora las Enmiendas 2 a 4 (AMD2, AMD3, AMD4) y la Corrigendum Técnica 2 (TC2) e incorpora soporte para las características lingüísticas C11 y C17 . [21]
Hay disponible un conjunto de ejemplos (para MISRA-C:2004 y MISRA C:2012) en el repositorio GitLab de MISRA [22] (se requiere iniciar sesión). Esto permite a los usuarios de las herramientas evaluar y comparar el soporte de verificación que ofrecen las distintas herramientas de MISRA; además, ofrece a los implementadores de herramientas cierta orientación sobre la intención de las Directrices de MISRA.
Si bien existen muchas herramientas de software que afirman verificar el código para determinar su “conformidad con MISRA”, no existe un proceso de certificación MISRA. [23]
La mayoría de las pautas se pueden comprobar mediante herramientas que realizan análisis de código estático . Las pautas restantes requieren el uso de análisis de código dinámico .
Las herramientas que verifican el código para verificar su conformidad con MISRA incluyen:
Los compiladores C/C++ que admiten la conformidad con MISRA incluyen:
Algunos resultados de investigaciones cuestionan la eficacia de MISRA C 2004.
En un artículo que compara trabajos anteriores sobre MISRA C:1998 con MISRA C:2004, Les Hatton llega a la conclusión de que: [30]
En vista de la aparente ampliación de la influencia de la norma MISRA C, este artículo intenta evaluar si se han abordado satisfactoriamente importantes deficiencias de la norma original. Lamentablemente, no ha sido así y la importante relación entre resultados positivos reales y falsos positivos no es mucho mejor en la MISRA C 2004 que en la MISRA C 1998 y es inaceptablemente baja en ambas.
Continúa afirmando: [30]
En su forma actual, los únicos que se beneficiarían con la actualización de MISRA C 2004 aparentemente serían los proveedores de herramientas y es de esperar que se tomen medidas para simplificar la redacción y reducir la tasa de falsos positivos en futuras revisiones, prestando un poco más de atención a los datos experimentales publicados y estando menos tentados a inventar reglas sobre la base de que parecen una buena idea.
Un estudio de la TU Delft , realizado por Cathal Boogerd y Leon Moonen, evalúa empíricamente el valor de MISRA C:2004 y llega a resultados similares: [31]
A partir de los datos obtenidos, podemos hacer las siguientes observaciones clave. En primer lugar, hay 9 de las 72 reglas para las que se observaron violaciones que funcionan significativamente mejor (α = 0,05) que un predictor aleatorio en la localización de líneas relacionadas con fallas. Las tasas de verdaderos positivos para estas reglas varían entre el 24 y el 100 %. En segundo lugar, observamos una correlación negativa entre las violaciones de las reglas MISRA y las fallas observadas. Además, 29 de las 72 reglas tuvieron una tasa de verdaderos positivos de cero. Tomado en conjunto con la observación de Adams de que todas las modificaciones tienen una probabilidad distinta de cero de introducir una falla, esto hace posible que la adherencia al estándar MISRA en su conjunto hubiera hecho que el software fuera menos confiable.