La actualización de software de Rivian inutiliza el sistema de infoentretenimiento, la solución no es obvia
Una actualización de software over-the-air reciente del fabricante de vehículos eléctricos Rivian ha estado dejando en soft-brick los sistemas de infoentretenimiento y pantalla en algunos vehículos, lo que los mantiene conducibles pero sin pantallas, controles de climatización o, en algunos casos, velocímetros visibles. Quienes comentan usan el incidente para criticar la canalización de actualizaciones de Rivian y destacar prácticas consolidadas para software embebido y automotriz, como despliegues por fases, particiones A/B, watchdogs y rutas de reversión robustas que deberían hacer recuperables fallos de este tipo. En términos más amplios, el evento alimenta un debate más amplio sobre si los coches constantemente actualizados y muy conectados merecen la complejidad y el riesgo añadidos frente a vehículos “tontos” con sistemas más simples y menos conectados.
Causa raíz y modos de fallo técnicos
- Quienes comentan dicen que Rivian sí probó la actualización en flotas internas; probablemente el fallo ocurrió en la promoción/despliegue (por ejemplo, una publicación hecha por error, una compilación o clave equivocadas).
- Muchos especulan que el paquete OTA estaba correctamente firmado, pero que un componente (el binario de infoentretenimiento) fue firmado con una clave de prueba/no de producción que el cargador de arranque de producción rechazó.
- Otros sugieren desajustes entre lo que valida la capa OTA y lo que validan los subsistemas individuales al arrancar, lo que provoca un soft-brick de la pila de pantalla.
Arquitectura OTA y salvaguardas
- Hay un consenso fuerte en que una OTA robusta debe incluir:
- Particiones de arranque A/B (o incluso triples) con reversión automática si el arranque falla o es parcial.
- Watchdogs vinculados al progreso real del sistema, no solo a un daemon que hace ticking periódicamente.
- Imágenes “golden” de recuperación y rutas de restauración probadas.
- Despliegues por fases, aleatorios, con control basado en telemetría.
- Varios ingenieros señalan que estos patrones tienen décadas en sistemas embebidos/automotrices; ven este fallo como un problema de proceso/prioridad, no como tecnología sin resolver.
Alcance del impacto y seguridad
- Los informes dicen que las funciones críticas de conducción (motores, frenos, luces, limpiaparabrisas, cámaras) siguen funcionando; la principal pérdida es el infoentretenimiento y, para algunos, la pantalla del cuadro/velocímetro y los controles de HVAC.
- Algunos sostienen que esto sigue siendo un problema de seguridad (sin velocímetro, sin desempañado, sin control fácil del clima en condiciones extremas).
- Hay debate sobre si un incidente así podría o debería desencadenar retiradas del mercado o complicaciones con el seguro.
Debate más amplio: actualizaciones OTA en coches
- Un bando: los coches deberían estar lo más “terminados” y fuera de línea posible; OTA es un riesgo innecesario, especialmente cuando puede desactivar funciones clave de la noche a la mañana.
- El otro bando: OTA es valiosa para corregir errores, actualizar seguridad/seguridad informática y añadir funciones nuevas (por ejemplo, curvas de carga mejoradas, nuevos modos de conducción, correcciones de UX), especialmente cuando los centros de servicio son escasos.
- Muchos critican la mentalidad de “move fast and break things” y el CI/CD cuando se aplica a sistemas adyacentes a la seguridad.
Comparaciones y contexto del sector
- Se trazan contrastes con Tesla, Polestar, BMW, Volvo, Ford, etc.; varios también tienen problemas con OTA, pero por lo general menos casos de vehículos inutilizados a escala de flota.
- Existe un sentimiento fuerte de que los fabricantes complican en exceso el infoentretenimiento, deberían favorecer CarPlay/Android Auto o interfaces “tontas” más simples, y respetar la propiedad del usuario, la privacidad y el derecho a reparar.