X
BLOG

La fusión de MISRA C ++ y AUTOSAR C ++: una mesa redonda

La fusión de MISRA C ++ y AUTOSAR C ++: una mesa redonda Tiempo de leer: 11 minutos
La Asociación de Confiabilidad de Software de la Industria del Motor (MISRA) anunció la futura fusión de MISRA C ++ y AUTOSAR C ++, los dos principales estándares de codificación C ++ críticos para la seguridad. ¿Qué significa eso para los usuarios del estándar y cómo afectará eso a las organizaciones que logren el cumplimiento?

Reunimos a un grupo de expertos de la industria aquí en Parasoft para una discusión de estilo de mesa redonda sobre lo que depara el futuro para MISRA C ++ y cuál será el impacto y los beneficios esperados de este nuevo estándar combinado.

Los participantes son:

  • Andrey Madan, Arquitecto líder de soluciones en Parasoft
  • Piotr Pepek, Gerente de desarrollo de software para la prueba Parasoft C / C ++
  • Michal Rozenau, Project Lead Software Engineer en Parasoft y miembro del WG de MISRA C y C ++
  • Miroslaw Zielinski, Product Manager para la prueba Parasoft C / C ++

Mesa Redonda de Discusión

¿Cómo se utilizan actualmente los estándares MISRA C ++ y AUTOSAR C ++ y cuáles son algunos de los problemas generales que está viendo en la industria automotriz?

Mirek: Aunque ambos estándares tienen un origen automotriz, es muy común que veamos que se utilizan en el proceso de cumplimiento no solo con ISO 26262 para automóviles, sino también con IEC 61508, el estándar de automatización industrial, y con dispositivos médicos e IEC. 62304. Entonces, cuando hablamos de MISRA y AUTOSAR, no es solo para la industria automotriz.

En términos de problemas, según mi experiencia trabajando con diferentes clientes en varias industrias, diría que las partes más difíciles del cumplimiento de un estándar de codificación son:

  • Establecer el estándar dentro de las herramientas de análisis estático del equipo
  • La fase inicial después del primer análisis.
  • Hacer frente a una gran cantidad de infracciones

El éxito definitivamente depende de la forma en que se introduce el estándar en la organización, y construir el proceso para el cumplimiento es fundamental para el éxito de la adopción de cualquier estándar de seguridad funcional, estos dos incluidos.

Uso de las pautas de codificación AUTOSAR C ++ para optimizar el cumplimiento de ISO 26262

Andrey: Definitivamente estoy de acuerdo. Un problema común que vemos con el uso de análisis estático para las reglas de MISRA C ++ y AUTOSAR C ++ es el número de violaciones informadas. Si activa todas las reglas, tendrá muchas infracciones, y me refiero a muchas, especialmente para una base de código heredada.

Entonces, en este momento, creo que el enfoque que están adoptando la mayoría de los clientes es tratar de encontrar un término medio. No todos de las reglas son obligatorias o requeridas. Entonces necesitan desarrollar un buen proceso. Por ejemplo, ejecutan algunas verificaciones y analizan el código y descubren cuál sería el subconjunto de reglas que se aplicaría a su desarrollo y documentar ese subconjunto. Entienden que no necesitan cumplir con todas las reglas, solo necesitan tener una justificación de por qué no se usó la regla, documentarla y eso está perfectamente bien.

Una vez que entienden el proceso, ejecutan un análisis e incluso con una acumulación de miles de advertencias, estos clientes pueden trazar una línea en la arena y seguir adelante con una acumulación de problemas, con la intención de volver a ellos y solucionarlos en algún punto.

Michael: Sí, creo que una razón adicional para la lucha aquí es que, para las empresas que están tratando de lograr finalmente el cumplimiento de un estándar de codificación como MISRA, a pesar de que comienzan a desarrollar un nuevo código, están buscando el cumplimiento hacia el final del ciclo de vida de desarrollo, en lugar de intentar comenzar desde el principio. Comenzar tarde es una de las principales razones por las que, en primer lugar, pueden encontrar una gran cantidad de infracciones.

¿Qué impide a las organizaciones hacer cumplir estos estándares de codificación en la práctica?

Andrey: Muchas organizaciones ya están utilizando su propio estándar de codificación interno para C y C ++ que se ha desarrollado internamente y se ha utilizado durante años. Estas empresas tienen un documento interno y políticas que siguen, y necesitan modernizarse a un estándar como MISRA, pero el impulso corporativo es tan grande que lleva mucho tiempo cambiar.

La estrategia para esas organizaciones es pasar por infracciones, observar su propio estándar de codificación y luego mapear los verificadores de análisis estático de Parasoft a su propio estándar de codificación, al mismo tiempo que se examina dónde se debe actualizar su propio estándar de codificación con respecto a MISRA y actualizaciones de la Lenguaje C.

Con C ++, la situación es peor actualmente debido a los estándares de codificación más antiguos. No admiten nuevas construcciones de lenguaje, como punteros automáticos y otras cosas que el nuevo C ++ moderno trae a la mesa, por lo que el proceso lleva más tiempo.

Mirek: Mencioné que vemos que AUTOSAR C ++ y MISRA C ++ se utilizan con frecuencia como parte del proceso de cumplimiento de estándares de seguridad funcional como ISO 26262 e IEC 61508. El cumplimiento de estos estándares de seguridad funcional requiere un proceso de desarrollo disciplinado, que incluye la preparación de la documentación. Los clientes necesitan una forma de demostrar formalmente que cumplen con los estándares de seguridad funcional, y también con un estándar de codificación, que es parte del proceso de cumplimiento para la seguridad funcional.

Con MISRA C ++ y AUTOSAR C ++, las herramientas de Parasoft brindan soporte dedicado para este lado formal del proceso de cumplimiento. Nuestro marco de informes genera documentación especial que se ajusta a los requisitos definidos en el Cumplimiento de MISRA: 2016 "Lograr el cumplimiento de las pautas de codificación de MISRA"documento. Esto acaba siendo muy importante. Los clientes que intentan lograr el cumplimiento del estándar tienen esta parte del proceso de cumplimiento automatizado mediante el uso de herramientas de Parasoft.

estándares, es que los estándares en sí mismos también proporcionan algunos mecanismos de categorización para sus reglas, lo que ayuda enormemente a la organización a incorporar el estándar. Para MISRA C ++, por ejemplo, existen diferentes categorías para las pautas (obligatorias, requeridas y de asesoramiento). Lo mismo ocurre con el conjunto AUTOSAR C ++, y también hay un marco adicional para las categorizaciones. Este mecanismo también se puede utilizar para facilitar todo el proceso de implementación y, básicamente, ayudar a las personas a hacerlo en fases, comenzando desde la categoría más crítica y limpiando el código, y luego yendo más allá.

¿Las organizaciones que comienzan con estos estándares comprenden la importancia de la categorización y la priorización?

Andrey: Las organizaciones no necesariamente lo han pensado. La solicitud más grande que recibo como arquitecto de soluciones es algo como: “Está bien, Parasoft, vemos que tiene miles de reglas y tenemos esta gran base de código. Ayúdanos a seleccionar las reglas que nos ayuden a encontrar errores reales, a encontrar algo interesante, algo de valor, algo que valga la pena corregir ".

En ese momento, damos un paso atrás para averiguar cuáles son sus objetivos específicos. Pero a menudo vemos que los clientes comienzan de manera más general, porque a pesar de la necesidad de cumplir con un estándar de codificación, no tienen tiempo para revisar todas las reglas y analizarlas. Ahí es donde entra la categorización y la priorización general.

También podemos preguntarle a la gerencia del equipo si requieren o no un enfoque estricto para el cumplimiento, por ejemplo, siguiendo todas las reglas requeridas y obligatorias. La mayoría de las veces, la gerencia no trazará esa línea y, en cambio, dejará la decisión a sus ingenieros, quienes son "lo suficientemente inteligentes" para determinar qué reglas se necesitan para cumplir. La expectativa es que el equipo de desarrollo documente su justificación de por qué se activaron o desactivaron las reglas.

Entonces, desde esa perspectiva, no he visto a la gente realmente "hacer cumplir". Es más un enfoque educativo. Por ejemplo, cuando explico que hay reglas obligatorias y obligatorias, y que puede desviarse de las reglas (pero debe documentar según lo especificado por el documento de cumplimiento de MISRA 2016), esto puede ser bastante revelador para muchos personas. Desde mi experiencia, definitivamente hay una curva de aprendizaje y una necesidad de consultoría en este espacio.

Mirek: Estoy de acuerdo: vemos una necesidad significativa aquí, no solo en la industria automotriz, sino también en otras organizaciones críticas para la seguridad, de obtener servicios de consultoría para hacer cumplir de manera más práctica el estándar y priorizar las acciones para lograrlo. Tenemos varios socios que ayudan a brindar servicios a nuestros clientes en este espacio, pero es evidente que existe la necesidad de obtener más educación y aplicación.

¿Cuál cree que fue la fuerza impulsora para la integración de las pautas de AUTOSAR C ++ y MISRA C ++? ¿Faltan piezas importantes de una norma u otra?

Piotr: La razón principal para fusionar los estándares fue simplemente tener un estándar único para C ++. Históricamente, MISRA C ++ 2008 se basó en C ++ 2003, y MISRA C ++ tiene casi 10 años. AUTOSAR C ++ se basó fuertemente en MISRA C ++ 2008 al principio, pero luego agregó muchas reglas nuevas que son más relevantes para C ++ moderno, incluidas características de C ++ 11 y C ++ 14. Entonces, la principal fuerza impulsora para la integración de ambos estándares fue tomar lo que ha hecho el grupo AUTOSAR C ++ y transformarlo en el próximo estándar MISRA C ++.

¿El estándar de codificación AUTOSAR C ++ está siendo reemplazado como estándar por MISRA C ++?

Michael: Sí, este es el plan. Las anotaciones en la versión actual de AUTOSAR C ++ hacen referencia a futuros deltas a las pautas de codificación que serán impulsadas por MISRA. Entonces podemos pensar en AUTOSAR C ++, como dijo Piotr, como una versión actualizada del estándar MISRA C ++, basada en MISRA C ++, con una serie de reglas literalmente tomadas de MISRA. Algunas de estas reglas se actualizaron y se agregaron reglas. Entonces, el plan es tomar estas reglas actualizadas y traerlas de vuelta a MISRA C ++.

¿De qué manera ayudará a los usuarios este nuevo estándar integrado?

Mirek: Creo que es muy valioso tener un estándar en el mercado. Hemos hablado con muchas organizaciones que se mostraron reacias a adoptar un estándar de cumplimiento porque no estaban seguras de si habría una actualización proveniente de MISRA y estaban pensando en adoptar AUTOSAR C ++ en su lugar. Así que pospusieron esta decisión. Entonces, la fusión aclara la situación y el beneficio obvio es que solo hay un estándar en el mercado y, básicamente, no hay duda sobre qué camino tomar: el nuevo estándar MISRA C ++ se convierte en la opción principal para el cumplimiento.

¿La integración de MISRA C ++ y AUTOSAR C ++ afectará a los usuarios existentes?

Mirek: Definitivamente habrá un impacto. Por ejemplo, si una organización que se basa en MISRA C ++ 2008 quiere pasar a AUTOSAR C ++, tiene que lidiar con aproximadamente 200 reglas nuevas (porque en la versión actual de AUTOSAR C ++ 18.10, aproximadamente el 45% de las reglas se heredaron directamente de MISRA C ++ 2008 ).

Entonces, si una organización confía en MISRA C ++ 2008, migrar a AUTOSAR C ++ es un esfuerzo significativo para ellos. Pero, también hay un gran valor en hacerlo, porque el delta entre MISRA C ++ 2008 y AUTOSAR C ++ aborda los cambios en el lenguaje C ++ desde 2003. Así que todas las novedades en C ++ 11 y C ++ 14 están incluidas en AUTOSAR C ++. Entonces, sí, hay un impacto, pero también hay mucho valor en la actualización al nuevo estándar.

Andrey: Si un cliente cambia de MISRA C ++ y ya se estaba ajustando a su estándar de codificación establecido, y cambia los estándares para decir, AUTOSAR C ++, el impacto a veces también puede ser más logístico.

Estos clientes ya han justificado, documentado y suprimido internamente las advertencias, y potencialmente incluso han pasado por auditorías. Por ejemplo, digamos que se violó la regla 11.5 de MISRA C ++ pero la desviación se registró y documentó. Ese es un ejemplo de supresión, o en este caso una desviación, y requiere informes y papeleo. Ahora, si me muevo a AUTOSAR C ++, esta regla de MISRA C ++ puede ser la misma regla bajo el capó, pero el proveedor de la herramienta informa esto como la regla 17.6 de AUTOSAR C ++. Es un nombre diferente, pero esa es la única diferencia, solo la etiqueta. Sin embargo, la herramienta de análisis estático vuelve a marcar esto como un error y no tiene en cuenta la supresión. La supresión fue etiquetada con un número de regla diferente y ahora tienen una gran cantidad de violaciones.

¿Y la seguridad? ¿AUTOSAR C ++ y presumiblemente el nuevo MISRA C ++ cubren la seguridad?

Mirek: Bueno, principalmente es un estándar de seguridad funcional, pero la seguridad y la protección están relacionadas. Ambos tratan de crear software libre de construcciones que conduzcan a un comportamiento impredecible, lo que significa que las organizaciones que siguen AUTOSAR C ++ o MISRA C ++ para la seguridad funcional suelen estar bastante bien cubiertas por la seguridad. La seguridad consiste en eliminar la imprevisibilidad del programa y, por supuesto, eso también promueve la seguridad.

Pero las pautas de seguridad como CERT son más completas e incluyen más pautas específicamente relacionadas con la seguridad. Actualmente, lo que vemos en muchas organizaciones, especialmente en las automotrices maduras, es que eligen su estándar de seguridad funcional como su fuente principal y luego mejoran su conjunto de reglas al incluir pautas seleccionadas adicionales de un estándar de seguridad como CERT C ++.

¿Existe alguna fuerza impulsora para conseguir más seguridad en estos estándares críticos de seguridad, como fusionar un estándar de seguridad como CERT C ++? ¿O cree que las empresas continuarán fusionando conjuntos de reglas?

Mirek: Personalmente, no predeciría que CERT se integre o se fusione con MISRA o AUTOSAR en el corto plazo. Debido a que la seguridad tiene un alcance más amplio y menos estricto, en términos de subconjunto de idiomas, siempre habrá una necesidad de estándares orientados a la seguridad, separados de los estándares de seguridad.

Entonces, por ejemplo, en MISRA C ++ 2008 tiene una regla que le impide usar la asignación de memoria dinámica. No puede usarlo si desea cumplir con MISRA C ++ 2008. Sin embargo, para CERT C ++ esto está perfectamente bien. Puede utilizar la asignación de memoria dinámica y existen reglas sobre cómo hacerlo de forma segura.

Piotr: Sí, y en el sitio web de MISRA, puede encontrar documentos oficiales que brindan información sobre el mapeo entre MISRA C 2012 y CERT C, por ejemplo, y estos mapeos le muestran claramente la diferencia de lo que falta. Por lo tanto, los desarrolladores tienen información sobre qué pautas incluir de CERT C / C ++ para incluir en su selección de reglas. Y también hay un mapeo de trazabilidad entre AUTOSAR C ++ y CERT C ++. Creo que alrededor del 50% de todas las pautas de CERT C ++ tienen una regla similar en AUTOSAR C ++.

Mirek: Además, creo que hay un aspecto regional en la adopción de estos estándares. Como vimos con la adopción de MISRA a lo largo del tiempo, ahora estamos viendo un patrón similar con CERT C y C ++. Por ejemplo, nuestros clientes en Japón adoptan rápidamente los últimos estándares y parecen estar por delante del resto del mundo. Nuestros clientes japoneses fueron los primeros en solicitar el soporte de MISRA C 2012 al menos un año antes que en otras regiones, y ahora mismo vemos un patrón similar con CERT C y C ++, con más solicitudes del mercado automotriz japonés que quieren soporte de CERT C / C ++. .

AUTOSAR C ++ es un estándar muy dinámico, con dos lanzamientos por año. ¿Cuál es el impacto de las actualizaciones frecuentes en las organizaciones que intentan lograr el cumplimiento? ¿Prevé que el nuevo estándar MISRA C ++ mantenga este calendario?

Piotr: Es importante recordar que las pautas de AUTOSAR C ++ son parte de la Plataforma adaptable AUTOSAR, por lo que estos dos lanzamientos por año son el ciclo de lanzamiento de toda la plataforma. Si quieren mantener las pautas de C ++ sincronizadas con la plataforma, entonces sí, esto debe administrarse de alguna manera a largo plazo. Pero no es necesariamente el caso de que muchas cosas hayan cambiado con cada lanzamiento.

Mirek: Como ya hemos comentado, existen problemas con los estándares cambiantes. Con cambios frecuentes en el estándar, tiene todos los problemas que Andrey discutió relacionados con la logística. Cuando una directriz ha cambiado, los clientes deben actualizar su marco de cumplimiento porque tendrán todos los problemas de infracciones nuevamente reportadas que ahora de repente ya no se suprimen. Este es un desafío importante y cuesta mucho dinero. Si tiene 50, 70 o 100 desarrolladores y ya tiene un proceso de cumplimiento introducido en su proceso de desarrollo, pero tiene un requisito comercial de que su producto debe cumplir con la última edición del estándar, entonces tiene este desafío.

Si el estándar está evolucionando rápidamente con cambios significativos en el estándar, los clientes deben abordar esto de alguna manera. A menudo, esto significa horas extra extraídas del programa y el presupuesto. Es un problema, pero como dijo Piotr, creo que, a largo plazo, el estándar se estabilizará y los cambios entre cada lanzamiento no serán tan significativos, como hemos visto por ejemplo en la transición entre AUTOSARC ++ versión 17.32 y 18.10 , por ejemplo.

La evolución del lenguaje C ++ se aceleró en los dos últimos años. AUTOSAR C ++ se basa actualmente en C ++ 14. ¿Cuál es la expectativa de la evolución de MISRA C ++ en relación con el lenguaje C ++?

Michael: Actualmente, el plan para la próxima versión de MISRA C ++ es incorporar AUTOSAR C ++ 14 y también cubrir C ++ 17, la versión actual del lenguaje. Sin embargo, no puedo hablar de qué tan rápido evolucionará en el futuro o cómo se lanzarán estas nuevas versiones. Personalmente, esperaría que se creara una nueva versión del estándar para cada nueva versión del lenguaje, la idea básica es actualizar el estándar cuando esté lo suficientemente maduro. Esto debería evitar el caso que hemos tenido con AUTOSAR C ++, que está basado en C ++ 14, pero aún cambia dos veces al año.

¿Cuánto tiempo prevé el nuevo retraso entre la actualización del estándar MISRA C ++ y el lanzamiento del lenguaje del comité ISO C ++?

Michael: Es difícil de decir, porque en el caso de AUTOSAR C ++, la estandarización comenzó después del lanzamiento de C ++ 14. El lanzamiento de AUTSAR C ++ no estuvo relacionado con el lanzamiento de la versión del idioma o cuando apareció el idioma.

AUTOSAR C ++ se basó en C ++ 14 desde el principio. Cuando AUTOSAR lanzó Adaptive Platform, vieron que no había estándares de codificación que cubrieran C ++ 14, por lo que decidieron basar el estándar en MISRA C ++ 2008 y actualizar con nuevas reglas y soporte para C ++ 14.

¿Las actualizaciones de AUTOSAR C ++ se basan en el programa de lanzamiento de Adaptive Platform en lugar del idioma?

Piotr: Sí, yo diría que sí.

Mirek: Es importante señalar que el nuevo estándar combinado MISRA C ++ se actualizará más allá de AUTOSAR C ++. Se ha declarado que el nuevo estándar integrado se actualizará para incluir todas las innovaciones introducidas en las nuevas versiones del lenguaje C ++, incluidos C ++ 17 y C ++ 20. Para muchas organizaciones, esto era de suma importancia. Las características modernas de C ++ son importantes en sistemas que utilizan IA, por ejemplo, que se basan en arquitecturas modernas, plataformas modernas y una biblioteca moderna que se desarrollan con frecuencia en las últimas ediciones de C ++. Por tanto, la declaración de que el estándar seguirá la evolución del lenguaje es muy importante.

Supere los engorrosos estándares de cumplimiento de seguridad funcional con la prueba Parasoft C / C ++.
Solicita Una Demo
Escrito por

Parasoft

Las herramientas de prueba de software automatizadas líderes en la industria de Parasoft respaldan todo el proceso de desarrollo de software, desde que el desarrollador escribe la primera línea de código hasta las pruebas unitarias y funcionales, hasta las pruebas de rendimiento y seguridad, aprovechando los entornos de prueba simulados en el camino.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft