Cómo un enfoque de ingeniería para la calidad del software automotriz pone freno a los defectos

Por Alan Zeichick

22 de septiembre de 2016

3  min leer

By alan zeichick (Analista principal en Asociados de Camden) y Arturo Hicken, Evangelista jefe en Parasoft

Los automóviles son más complejos que nunca y eso significa un potencial exponencial de defectos de software. Como comentamos en "Defectos de ingeniería de software automotriz en aumento, ”Los automóviles modernos están repletos de software que unen funciones críticas para la seguridad, características de entretenimiento y comunicaciones avanzadas en una vasta cadena de suministro. En estas condiciones, un solo error o un fragmento de código mal concebido puede tener consecuencias importantes. Y aunque ninguna herramienta o práctica es una solución milagrosa, existen principios importantes para reducir el riesgo asociado con el desarrollo de software automotriz.

Aproveche los conceptos de ingeniería para prevenir defectos de software

La mejor manera de eliminar los defectos del software es crear un entorno en el que no se puedan introducir, así como un proceso para identificar y remediar fácilmente los defectos introducidos por un proveedor anterior. Esto se logra mediante la adopción de principios de desarrollo de hardware bien establecidos, como la repetibilidad, la aplicación de las mejores prácticas conocidas y la confianza en los estándares.

Como explicamos en "Cómo aprovechar los estándares de desarrollo de software automotriz para mitigar el riesgo, ”Lograr la seguridad funcional en el software integrado requiere seguir estos principios de ingeniería al diseñar y codificar:

  • La seguridad funcional debe ser proactiva
  • Los procesos deben ser controlados, medidos y repetibles
  • Los defectos deben evitarse mediante la implementación de estándares.

Implementar estándares de desarrollo con políticas

Ya sea que se construya una autopista de dos carriles o se codifique un sistema de despliegue de bolsas de aire, los estándares son herramientas críticas de ingeniería. En el espacio automotriz integrado, los estándares incluyen ISO-26262 6: 2011, que cubre la seguridad funcional para software automotriz, y Misra, una familia de estándares de desarrollo C y C ++ para sistemas electrónicos relacionados con la seguridad en automóviles.

La implementación de estándares comienza con encapsular el cumplimiento de estándares dentro de su política de desarrollo. Como se explica en "Aprovechamiento de los estándares de desarrollo automotriz para mitigar el riesgo, parte 2, ”Las políticas son declaraciones exigibles que prescriben en un lenguaje sencillo cómo se debe desarrollar el software y por qué se debe desarrollar de esta manera. Por ejemplo, una política puede indicar:

  • El software debe ser desarrollado según lo definido por ISO 26262
  • No se aceptará el código de los subcontratistas posteriores que no proporcionen una trazabilidad adecuada que demuestre el cumplimiento de la norma.

Automatizar la aplicación de la política de desarrollo

Convertir las políticas en lenguaje sencillo en declaraciones exigibles requiere herramientas que puedan aplicar continuamente técnicas de calidad de software basadas en los estándares de la industria y las mejores prácticas en todo el SDLC. También es necesario un mecanismo que recopile, correlacione y priorice los hallazgos para la visibilidad de los procesos que potencialmente inyectan riesgos en la aplicación.

Si tiene una política que requiere que todas las variables se inicialicen y toda la memoria se asigne explícitamente, entonces necesita una herramienta que simplemente no permita que se registre el código con variables no inicializadas o referencias a memoria no asignada. Si dicho código se desliza en el base de código, una política debe garantizar que las fallas sean descubiertas mediante análisis estático o detección de errores en tiempo de ejecución.

Además, si hay un equipo o programador que continuamente comete ese tipo de errores, el análisis de métricas y metadatos ayudará a la gerencia a comprender cómo ocurren esos errores, asegurarse de que se corrijan y ofrecer orientación sobre cómo mejorar la capacitación para que esos errores sean menos probables. .

Imagine que ese escenario se desarrolla en cientos y miles de reglas que cubren las mejores prácticas para el desarrollo de software integrado. Si se compromete a adherirse a esos estándares, las herramientas pueden garantizar que el trabajo se realice correctamente.

Prueba para validar, no para depurar

Las pruebas deben ser efectivas, deterministas y deben realizarse para problemas de memoria complejos. Las pruebas también deben realizarse en todo el SDLC para que las pruebas de aceptación validen que la aplicación (o todos los sistemas integrados, como un automóvil complejo) cumple con sus requisitos funcionales y de calidad y está lista para su lanzamiento.

Desafortunadamente, muchas organizaciones confían en las pruebas de aceptación en las últimas etapas como un medio para depurar sus aplicaciones, lo que aumenta el costo y el riesgo del software. El objetivo de las pruebas es verificar que el código cumpla con los estándares internos, regulatorios y de la industria, no identificar errores. Las pruebas deben aprobarse y los resultados deben documentarse para referencia futura (y para satisfacer los requisitos de certificación y reguladores).

No podemos ser complacientes y creemos que la mejor manera de mejorar la calidad del software automotriz integrado es ejecutar más pruebas en un producto final o casi final. Tenemos que diseñar y codificar el software de la manera correcta, la primera vez, utilizando un enfoque de ingeniería con políticas para aprovechar y hacer cumplir los estándares y las mejores prácticas de la industria. Así es como abordamos el desafío de la calidad del software automotriz.

“MISRA”, “MISRA C” y el logotipo del triángulo son marcas comerciales registradas de The MISRA Consortium Limited. © The MISRA Consortium Limited, 2021. Todos los derechos reservados.

Por Alan Zeichick

Alan Zeichick es analista principal de Camden Associates; anteriormente, Alan fue editor en jefe de SD Times de BZ Media. Síguelo @zeichick.

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