Cumplimiento de estándares de codificación y análisis estático para software de conducción autónoma

Escribir código para funciones complejas como la conducción autónoma requiere grandes equipos de personas talentosas, que a menudo tienen sus propias opiniones sobre cómo garantizar un código de alta calidad. Pero no es tan fácil construir un proceso de desarrollo de software eficiente que incluya iniciativas de calidad como análisis estático y cumplimiento de estándares de codificación, que permitan la certificación exitosa del automóvil autónomo.

La conducción autónoma es un espacio muy competitivo y la velocidad del desarrollador es un mantra. Quien primero pueda llevar un producto certificado al mercado tendrá una ventaja significativa sobre la competencia, por lo que es fácil para los desarrolladores ver el análisis estático y otras iniciativas de calidad como un obstáculo. Especialmente porque el campo de la conducción autónoma está hambriento de talento, las organizaciones están contratando desarrolladores inteligentes, incluso si no tienen experiencia en seguridad. Pero los desarrolladores que provienen de un entorno sin una cultura de seguridad funcional no conocen todos los procesos de calidad que se requieren para el desarrollo de software crítico para la seguridad. Esto puede hacer que la aceptación cultural sea un desafío.

Conseguir aceptación interna

A veces se siente que construir un consenso interno para las prácticas orientadas a la calidad requiere una maestría en Psicología, o las habilidades de un negociador capacitado ... En proyectos anteriores, fui responsable de introducir el análisis estático y el cumplimiento de los estándares de codificación AUTOSAR C ++ 14 como un método sostenible. proceso. El software de conducción autónoma es muy innovador y los componentes de software que se utilizan para ello se desarrollan utilizando C ++ moderno. Con eso en mente, el estándar de codificación AUTOSAR C ++ 14 es el estándar más apropiado para el software de conducción autónoma porque es compatible con C ++ moderno y fue creado para un desarrollo orientado a la seguridad.

Para convencer a los no convencidos, he realizado múltiples presentaciones en las que se discutieron múltiples aspectos diferentes. Pero aún así, incluso con todas estas discusiones y acuerdos, algunos desarrolladores se resisten a analizar todo el código que crean. Estos son algunos de los puntos principales en los que me enfoco para implementar los procesos correctos:

• Certificación - El software de automóvil autónomo debe estar aprobado y certificado antes de entrar en producción en masa. Este proceso se ve diferente en diferentes regiones del mundo, pero todas las organizaciones automotrices reconocen ISO 26262 como el principal estándar de seguridad funcional que simplifica la aprobación y certificación. La norma ISO 26262 exige el análisis estático y el cumplimiento de los estándares de codificación, y la falta de cumplimiento de los estándares de codificación para el código fuente será un gran obstáculo en el proceso de aprobación. Ninguna organización empresarial seria permitirá ese riesgo.
• Mejor calidad a bajo costo - Cuando crea código compatible de alta calidad desde el principio, probando lo antes posible, es más fácil (es decir, más rápido) solucionar problemas y evitará los errores comunes porque los desarrolladores empezarán a adoptar las mejores prácticas desde el principio. Los desarrolladores (incluso aquellos que son nuevos en la cultura de seguridad crítica) aprenderán y habrá menos violaciones de análisis estático. Es esencial probar mientras se escribe el código para crear software complejo a un ritmo rápido. El análisis estático es uno de los métodos que encaja muy bien en esta imagen, estableciendo una base esencial para la seguridad al eliminar clases de problemas que pueden conducir a un comportamiento impredecible. Dar a los desarrolladores una herramienta que producirá los resultados en un ciclo de retroalimentación corto, con una cantidad baja de falsos positivos, aumenta la aceptación de esta tecnología de prueba. Y con el tiempo, los desarrolladores comienzan a verlo como una red de seguridad, es decir, algo que les ayuda a crear código confiable. Sin mencionar que esto es fundamental para Agile / DevOps porque si espera para realizar el escaneo justo antes del lanzamiento, pasará meses arreglando el código.
• Cuestiones legales - El cumplimiento de los estándares de codificación es un escudo para posibles problemas legales. Con millones de automóviles en las carreteras, van a ocurrir accidentes. Algunos de ellos se atribuirán a errores de software, que son inevitables. Las organizaciones deben poder presentar que han hecho todo lo posible para prevenir riesgos de seguridad. No tener un proceso de cumplimiento de estándares de codificación documentado será sin duda un problema en caso de un defecto de software que contribuyó a una tragedia. Entonces, al discutir este aspecto con los desarrolladores, para fortalecer el efecto, me gusta incluir algunos accidentes reales que fueron causados ​​por defectos del software, como la infame aceleración involuntaria de Toyota.

Convencer a los desarrolladores más resistentes ...

La tecnología de conducción autónoma se encuentra en una fase muy temprana. Gran parte del código fuente creado es solo un prototipo para probar nuevas ideas. Algunos desarrolladores no quieren “perder” el tiempo haciéndolo compatible con el estándar de codificación, solo quieren escribir algo rápidamente y probarlo. Una historia típica que he escuchado es: "Solo quiero probar este nuevo algoritmo, si funciona, reescribiré el código para hacerlo limpio". Esto suena bastante inocente, pero la realidad es que solo se trata de una deuda técnica creciente.

Cuando pasamos de un prototipo a otro, normalmente llevamos mucho código, estadísticamente puede ser hasta el 80% del código. Así que no podemos darnos el lujo de crear un prototipo de algo con un código incorrecto y luego arreglarlo más tarde, porque desde el principio, sabemos que no tendremos tiempo para eso. Entonces, incluso si algo es un prototipo, el código debe ser compatible porque el producto final contendrá una cantidad significativa de código que se creó inicialmente como un prototipo.

Si en lugar de concentrarse en hacerlo ahora en lugar de hacerlo más tarde, puede concentrarse en hacerlo ahora para evitar pasar una cantidad de tiempo desconocida al final, los desarrolladores empiezan a verlo como una mejora del proceso en lugar de introducir una ralentización. Si puede adaptar el proceso de manera eficiente al flujo de trabajo del desarrollador sin disminuir la velocidad o la creatividad, será mucho más fácil trabajar con él. Es mucho más fácil mantener algo ordenado y limpio sobre la marcha, que limpiar un gran desorden al final. La construcción de prácticas consistentes y sostenibles para escribir código compatible lo ayudará a encontrar menos desorden en el futuro.

Ese maldito código heredado ...

Pero incluso si puede introducir con éxito un proceso de cumplimiento de estándares de codificación desde el principio, inevitablemente ya habrá una cantidad (significativa) de código que ya fue creado por el equipo, y algo que fue heredado. Y mientras selecciona la herramienta de análisis estático (prueba Parasoft C / C ++) y elige el estándar (AUTOSAR), mientras tanto, el equipo está creando una gran cantidad de código sin ninguna política de cumplimiento. Por lo tanto, es importante crear también una política para el código heredado. Dos grandes políticas son:

• "Cero nuevas infracciones": en el que no puede terminar de crear un nuevo código hasta que cumpla
• "Limpiar sobre la marcha": en el que, si toca el archivo, debe limpiarlo

Con estas estrategias, puede abordar el código heredado, introducir código nuevo y continuar manteniendo el lugar ordenado.

Resumen

Para tener éxito en la adopción de procesos de cumplimiento de estándares de codificación y análisis estático en toda la organización de desarrollo, se beneficiará de hacer lo siguiente:

1. Asegúrese de que todos comprendan por qué lo está haciendo (sin dedicar tiempo a ello, no puede obtener la certificación y no podrá tener éxito en el mercado automotriz)
2. Aborde el costo de los lanzamientos retrasados ​​si no aborda la calidad como un esfuerzo continuo y muéstrele al equipo lo que sucede cuando lo deja para el final
3. Haga que la adopción sea lo más relevante y sin fricciones posible. Sea intencional al implementar su herramienta de análisis estático, asegurándose de seleccionar las reglas y verificadores correctos y tener un flujo de trabajo que se integre en el flujo de trabajo existente de los desarrolladores.