Cómo aprovechar los estándares de desarrollo de software automotriz para mitigar el riesgo

Algunas organizaciones ven el cumplimiento de ISO 26262, MISRA y otras normas como una carga que aumenta los gastos generales, pero la verdad es que el costo de las fallas asociadas con los defectos del software es mucho, mucho mayor que el costo de garantizar la calidad.

Cuando los consumidores promedio que no son ingenieros piensan en los sistemas electrónicos de los automóviles, es probable que piensen en GPS integrados, sistemas de información y entretenimiento y probablemente en una vaga noción de que hay una computadora en algún lugar del automóvil que controla algunas de las características de seguridad. Por supuesto, la realidad es que los automóviles modernos son significativamente más complejos y el software desempeña un papel cada vez más importante en todas las facetas de la funcionalidad, incluidas muchas funciones críticas para la seguridad.

De hecho, los automóviles han aprovechado los sistemas electrónicos para la funcionalidad crítica durante décadas, y los cambios del mercado, como el impulso hacia un "Internet de las cosas", han empujado a los fabricantes de automóviles a incorporar una mayor cantidad de sistemas informáticos complejos que abarcan toda la gama de aspectos críticos.

Las estructuras comerciales y las cadenas de suministro asociadas con el desarrollo de sistemas aumentan aún más la complejidad. Es raro, si es que sucede, que un fabricante diseñe y construya todos los componentes y subsistemas de sus automóviles desde cero, lo que lleva a posibles problemas de integración. De este modelo se toma una transmisión, de aquél un buen sistema de frenado. Si bien es posible que hayan funcionado bien en su entorno anterior, en un sistema complejo totalmente nuevo pueden tener resultados inesperados y no deseados. Como resultado, el software automotriz es a menudo una mezcla compleja de sistemas que pueden o no haber sido suficientemente probados. Implementar componentes de manera ad-hoc sin las pruebas adecuadas, especialmente en aplicaciones críticas para la seguridad, puede resultar extremadamente costoso.

Sin embargo, la ventaja es que existen prácticas conocidas para ayudar a los fabricantes de automóviles a mitigar el riesgo de fallas al incorporar la calidad del software en sus procesos de desarrollo. En este artículo, discutiremos algunos de los problemas que contribuyen a la complejidad del software automotriz, así como los riesgos asociados con el desarrollo de software automotriz. También discutiremos cómo la implementación de las mejores prácticas de desarrollo conocidas, como ISO 26262, ayudan a las organizaciones a mitigar esos riesgos.

¿Más código inyecta más riesgo?

Según algunas estimaciones, un automóvil estándar de gama media puede tener más de cien unidades de control electrónico (ECU) que procesan millones de líneas de código, y este número está aumentando. No es raro que un fabricante tenga varios modelos de automóviles con más de cien millones de líneas de código.

Existe la percepción de que cuanto más caro es el automóvil, más software está integrado, y que la mayor parte del software está dedicado a componentes de información y entretenimiento de alta gama. Si bien es cierto que estos sistemas se vuelven cada vez más complejos a medida que avanza en la línea de modelos, incluso las líneas iniciales de automóviles usan software para controlar la dirección, los sistemas de frenos, la distribución de energía eléctrica, etc. E incluso cambios aparentemente menores en funciones, como Bluetooth, control de clima, control de crucero, etc., conducen a un crecimiento exponencial del código.

Podemos suponer que más código se traduce en más complejidad y, por lo tanto, riesgo, pero el impacto puede no ser necesariamente significativo. Un factor que contribuye en mayor medida al riesgo empresarial asociado con el software automotriz es la integración de código desarrollado a partir de una variedad de fuentes en múltiples niveles. La mayoría de los componentes, incluidos los componentes basados ​​en ECU, se subcontratan a proveedores de segundo nivel que subcontratan a proveedores de tercer nivel, etc. Cada nivel anterior tiene requisitos específicos asociados con el componente que están desarrollando. Las organizaciones a menudo (pero no siempre) tienen prácticas para analizar el código entrante para garantizar que los componentes funcionen como se espera.

Pero esto supone que cada componente a lo largo de la cadena de suministro es un desarrollo nuevo. En realidad, los niveles posteriores se derivan del código escrito para una marca, modelo y año específicos. La mutación y reutilización del código tiene lugar a lo largo de la cadena de suministro, lo que genera un problema de prueba. ¿Cómo implementa el fabricante las pruebas de extremo a extremo en un ecosistema tan caótico de desarrollo de software? Cuando la ECU en el volante se desarrolló originalmente para un vehículo y la ECU en el tablero se desarrolló para otro vehículo, y ninguna de las ECU se diseñó para el vehículo en el que están integradas actualmente, ¿cuál es el impacto? ¿Cómo puede asegurarse de que el sistema completo funcione como se espera? Es completamente posible que ambos sistemas pasen las pruebas como funcionales pero no puedan comunicarse correctamente en todas las situaciones. ¿Cuál es el riesgo asociado con esta brecha?

El costo de la calidad del software

Cuando las organizaciones intentan medir el costo del desarrollo de software, tienden a mirar métricas generales: tiempo de desarrollo para los ingenieros; tiempo de prueba para QA; “Materiales de construcción” en forma de adquisición de licencias de herramientas, compiladores y otros componentes de infraestructura. Estas son métricas importantes, pero a menudo se pasan por alto los costos de fallar.

Si el software del sistema de frenos falla, ¿cuánto le costará a la empresa en términos de reelaboración, retiros, auditorías, litigios y pérdida del valor de las acciones? ¿Qué pasa si hay una pérdida de vidas? Argumentamos que el costo de la calidad es el costo de desarrollar y probar el software, incluidas todas las métricas normales que identificamos más los costos muy tangibles asociados con una falla en el campo.

Los defectos cuestan mucho dinero a los fabricantes de automóviles. La NHTSA estima que las retiradas y reparaciones en toda la industria cuestan a los fabricantes de automóviles $ 3 mil millones al año. Cuando se trata del costo de los problemas relacionados con el software, una estimación de 2005 de IEEE puso el costo para los fabricantes en $ 350 por automóvil. Cuando se consideran los bajos márgenes de beneficio en una línea de vehículos, es concebible que un defecto de software suficientemente grave pueda dañar gravemente el negocio.

El resultado final es importante, pero aún más importante es que las personas pueden sufrir lesiones graves o incluso morir como resultado de un defecto del software. Y no importa qué tan abajo en la cadena de suministro se pueda originar el defecto, los defectos y todas sus consecuencias asociadas se vuelven responsabilidad del fabricante de automóviles. Como tal, cualquier análisis de costos en torno al desarrollo de software debe tener en cuenta los costos potenciales de fallas.

El estado actual del desarrollo de software

Hemos argumentado que la complejidad de la cadena de suministro por niveles para el software automotriz contribuye al riesgo general asociado con los sistemas críticos para la seguridad. También reiteramos los costos potenciales para las empresas automotrices. Pero hay otra dimensión de este problema que reside en la diferencia cultural entre ingeniería y desarrollo de software.

El desarrollo de software casi nunca es ingeniería. Es decir, ciertos conceptos de principios de ingeniería, como la repetibilidad, las mejores prácticas bien ejercidas y la confianza en los estándares de construcción, aún no se han establecido firmemente en el desarrollo de software. Además, la capacitación de los desarrolladores de software puede ser inconsistente, incluso inexistente, y las organizaciones tendrían que esforzarse mucho para verificar que sus desarrolladores posean los conocimientos adecuados para construir software crítico para la seguridad.

Esto contrasta con la ingeniería en la que las actitudes, la mentalidad y la historia de la disciplina imponen un proceso que es menos propenso a defectos en comparación con el desarrollo de software. Eso no quiere decir que los ingenieros sepan lo que están haciendo y los desarrolladores de software no. Más bien, quiere decir que la ingeniería automotriz como campo es dos veces más madura que el desarrollo de software, y que la naturaleza temporal e intangible del software perpetúa una actitud arrogante en la que si funciona, entonces está hecho.

El énfasis en el desarrollo de software se centra en una entrega más rápida y requisitos funcionales: ¿con qué rapidez podemos tener esta funcionalidad? La dirección tiene pocos incentivos para implementar prácticas sólidas de ingeniería en el ciclo de vida del desarrollo de software. Lograr la seguridad funcional en el software requiere poner en práctica ciertos principios de ingeniería:

• 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.
• Las pruebas deben ser efectivas y deterministas
• Se deben realizar pruebas para problemas de memoria complejos

La buena noticia es que las actitudes en torno al desarrollo de software han ido evolucionando. ISO 26262, MISRA y otras normas buscan normalizar el desarrollo de software para aplicaciones automotrices proporcionando una base para implementar conceptos de ingeniería en los procesos de desarrollo de software. Algunas organizaciones ven el cumplimiento de ISO 26262 y otras normas como una carga que aumenta los gastos generales sin ningún valor directo, pero la verdad es que el costo de las fallas asociadas con los defectos del software es mucho, mucho mayor que el costo de garantizar la calidad. Al igual que en los estándares eléctricos que especifican un calibre específico de cable para transportar un voltaje conocido, los estándares de codificación pueden proporcionar las pautas que ayudan a evitar desastres.

ISO 26262, MISRA y otros estándares buscan normalizar el desarrollo de software para automotor aplicaciones proporcionando una base para implementar conceptos de ingeniería en los procesos de desarrollo de software. Algunas organizaciones ven el cumplimiento de la norma ISO 26262 y otras normas como una carga que aumenta los gastos generales, pero la verdad es que el costo de las fallas asociadas con los defectos del software es mucho, mucho mayor que el costo de garantizar la calidad.

“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 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.