X
BLOG

Defectos de ingeniería de software automotriz en aumento

Defectos de ingeniería de software automotriz en aumento Tiempo de leer: 3 minutos

"Se necesitan docenas de microprocesadores que ejecuten 100 millones de líneas de código para sacar un automóvil premium del camino de entrada, y este software solo se volverá más complejo". - Robert N. Charette, Espectro IEEE: Este coche funciona con código

La cita anterior fue tomada de un artículo escrito hace siete años, antes de que el Model S de Tesla saliera de la línea de ensamblaje, antes de que Google comenzara a probar autos autónomos y antes de que los sistemas de información y entretenimiento integrados se convirtieran en estándar incluso en modelos de gama baja. La ingeniería de software automotriz para los automóviles de hoy es considerablemente más compleja. Muchos modelos tienen más de 100 unidades de control electrónico (ECU), que son responsables de todo, desde monitorear un sensor hasta controlar un actuador. Con tanta complejidad incorporada en el software automotriz, no es de extrañar que los defectos relacionados con el software estén en aumento.

¿Qué es una ECU?

Una ECU generalmente consta de un conjunto de caja negra con un microprocesador integrado, memoria, firmware, conexión de red y circuitos para llevar a cabo su función. Los automóviles modernos consisten en un número cada vez mayor de ECU conectadas por un bus de comunicaciones de red sofisticado que utiliza cada vez más Ethernet.

El software integrado de la ECU puede ser diseñado y codificado por el fabricante del automóvil o suministrado por un tercero en la vasta cadena de suministro automotriz. Cuando las ECU se ensamblan en un vehículo terminado, se debe probar todo el sistema para garantizar que todos los componentes, no solo los componentes básicos y críticos para la seguridad, funcionen correctamente. De hecho, el motor, los frenos, las bolsas de aire y otras características y funciones ni siquiera funcionarán sin el software. Por eso, como escribió Charette en 2009, el automóvil funciona con código tanto como con combustible.

Garantizar la calidad del software automotriz

El fabricante de automóviles tiene la responsabilidad legal y ética completa de garantizar que el vehículo sea seguro de poseer y operar, lo que incluye realizar el control de calidad en muchos niveles. Por ejemplo:

  • Asegurarse de que los frenos actúen al pisar el pedal (seguridad funcional)
  • Prevención de pérdidas de memoria que degradan el rendimiento de los sensores de oxígeno del motor con el tiempo (seguridad no funcional)
  • Evitar que un pirata informático aproveche el sistema de control de la presión de los neumáticos o acceda a la telemetría cargada a través de enlaces móviles (ciberseguridad)

Cuando se encuentra un defecto, el fabricante puede responder de varias formas. Si el defecto es muy leve y no representa una amenaza para el rendimiento o la seguridad del vehículo, el fabricante puede simplemente optar por ignorarlo. Si el defecto representa un costo potencial, pero no es crítico para la seguridad, el firmware puede actualizarse la próxima vez que se realice el mantenimiento del automóvil. Alternativamente, una versión más reciente de un subconjunto reemplazable podría incluir firmware actualizado. Algunos fabricantes de automóviles han cambiado a actualizaciones inalámbricas (OTA) para modelos y ECU compatibles. En muchos casos, es posible que no se exija al fabricante que revele la solución de software al cliente oa una agencia reguladora.

El verdadero costo de la calidad incluye el costo de las retiradas

Si se detecta un defecto grave con implicaciones críticas para la seguridad, es posible que el fabricante tenga que emitir un retiro. Los retiros del mercado se llevan a cabo de forma voluntaria o por "instancias" de una agencia reguladora. El retiro del mercado incluiría software, que podría tener que ser probado y aprobado antes de ser lanzado.

Es difícil saber con certeza el costo del software defectuoso en los automóviles, pero debido a que los retiros del mercado se divulgan públicamente, tenemos algunas ideas sobre los costos y las tendencias. De 2005 a 2012, hubo 32 retiradas de automóviles que incluyeron correcciones de software que afectaron a 3.6 millones de vehículos. En los siguientes 3.5 años, desde 2012 hasta junio de 2015, hubo 63 retiradas del mercado asociadas con un componente de software que afectó a 6.4 millones de automóviles. En la mitad del tiempo, el impacto de los defectos del software casi se duplicó.

Además, solo alrededor del 5% de las retiradas de automóviles tenían un componente relacionado con el software en 2011. En 2015, ese número aumentó a casi el 15%.

Esos retiros relacionados con el software afectan a todas las partes del vehículo. Desde 2006 hasta 2015, hubo retiradas relacionadas con software para sistemas de llantas (por ejemplo, sistemas de monitoreo de presión de llantas), la estructura del vehículo, pestillos y cerraduras, sistema de combustible, tren de fuerza, control de velocidad del vehículo (es decir, control de crucero regular o adaptativo), Visibilidad e iluminación exterior, frenos de estacionamiento, propulsión híbrida, motor y refrigeración del motor, dirección, airbags y eléctricos. Para obtener más información sobre retiros relacionados con software, consulte nuestra publicación anterior, "Cuantificación del riesgo de fallas del software automotriz: Informe de garantía y retiro del mercado de SRR."

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

Prueba Parasoft