Atualização de software da Rivian “bricka” sistema de infoentretenimento, correção não é óbvia
Uma atualização de software over-the-air recente da Rivian está causando soft-brick nos sistemas de infoentretenimento e exibição em alguns veículos, deixando os carros dirigíveis, mas sem telas, controles de climatização ou, em alguns casos, velocímetros visíveis. Comentadores usam o incidente para criticar o pipeline de atualização da Rivian e destacar práticas consolidadas para software embarcado e automotivo, como rollouts em etapas, partições A/B, watchdogs e caminhos robustos de rollback que deveriam tornar falhas assim recuperáveis. Em um plano mais amplo, o episódio alimenta um debate maior sobre se carros constantemente atualizados e altamente conectados valem a complexidade e o risco adicionais em comparação com veículos “burros” com sistemas mais simples e menos conectados.
Causa raiz e modos de falha técnicos
- Comentadores dizem que a Rivian testou a atualização em frotas internas; a falha provavelmente ocorreu na promoção/implantação (por exemplo, release “fat-fingered”, build errado ou chave errada).
- Muitos especulam que o pacote OTA foi assinado corretamente, mas um componente (o binário de infoentretenimento) foi assinado com uma chave de teste/não produção, que o bootloader de produção rejeitou.
- Outros sugerem incompatibilidades entre o que a camada OTA valida e o que subsistemas individuais validam na inicialização, levando a um soft-brick da pilha de exibição.
Arquitetura OTA e proteções
- Há forte consenso de que uma OTA robusta deve incluir:
- Partições de boot A/B (ou até triplas) com rollback automático em caso de boot falho/parcial.
- Watchdogs ligados ao progresso real do sistema, e não apenas a um daemon que “tique-taqueia” periodicamente.
- Imagens “golden” de recuperação e caminhos de restauração testados.
- Rollouts em etapas, randomizados, com bloqueio baseado em telemetria.
- Vários engenheiros observam que esses padrões existem há décadas em sistemas embarcados/automotivos; a falha aqui é vista como problema de processo/prioridade, não como tecnologia sem solução.
Escopo do impacto e segurança
- Relatos dizem que funções críticas de condução (motores, freios, luzes, limpadores, câmeras) ainda funcionam; a principal perda é o infoentretenimento e, para alguns, o painel/display de velocidade e os controles de HVAC.
- Alguns argumentam que isso ainda é um problema de segurança (sem velocímetro, sem desembaçador, sem controle fácil de clima em clima extremo).
- Há debate sobre se um incidente assim poderia ou deveria gerar recalls ou complicações com seguros.
Debate mais amplo: atualizações OTA em carros
- Um lado: carros deveriam ser o mais “prontos” e offline possível; OTA é um risco desnecessário, especialmente quando pode desativar funções-chave durante a noite.
- Outro lado: OTA é valiosa para correções de bugs, atualizações de segurança e novos recursos (por exemplo, curvas de carregamento melhores, novos modos de condução, ajustes de UX), especialmente quando os centros de serviço são escassos.
- Muitos criticam a mentalidade de “move fast and break things” e CI/CD quando aplicada a sistemas próximos de segurança.
Comparações e contexto do setor
- São feitas comparações com Tesla, Polestar, BMW, Volvo, Ford etc.; várias também têm problemas com OTA, mas geralmente com menos “bricks” em toda a frota.
- Há forte sentimento de que montadoras complicam demais o infoentretenimento, deveriam favorecer CarPlay/Android Auto ou interfaces “burra” mais simples, e respeitar a propriedade do usuário, a privacidade e o direito de reparar.