1 pontos por GN⁺ 2025-10-14 | 1 comentários | Compartilhar no WhatsApp
  • Alguns proprietários do Jeep Wrangler 4xe híbrido relataram que seus veículos travaram após uma atualização de software OTA realizada no fim de semana
  • A atualização era da telemática do sistema de infotainment Uconnect e foi distribuída sem estar pronta
  • O problema não aparecia imediatamente após a atualização, mas causava uma situação grave em que o veículo parava por erro no trem de força durante a condução
  • A Jeep interrompeu a distribuição da atualização após os relatos do problema, mas ela já havia sido baixada em vários veículos
  • Depois, a Jeep lançou um patch corretivo e recomendou aos proprietários que ainda não tinham instalado a atualização que a ignorassem

Problema com atualização de software OTA em veículos híbridos Jeep 4xe

Visão geral do problema

  • Alguns proprietários do Jeep Wrangler 4xe híbrido passaram por situações em que o veículo parava repentinamente durante a condução após instalar uma atualização OTA de software no fim de semana
  • O problema ocorreu porque uma atualização de telemática do sistema de infotainment Uconnect foi distribuída antes de estar devidamente pronta

Como o problema ocorreu

  • O defeito não aparecia de imediato: após a atualização, ele levava à perda de potência durante a condução e à parada do veículo
  • Alguns proprietários relataram isso em áreas residenciais ou em baixa velocidade, mas também houve casos registrados de falha no trem de força durante a condução em rodovia

Resposta e medidas adotadas

  • A Jeep suspendeu a distribuição da atualização após os relatos do problema, mas muitos veículos já haviam feito o download
  • A equipe social da Stellantis orientou, por meio de um fórum da Jeep, que os proprietários que ainda não tinham instalado a atualização ignorassem o pop-up de atualização

Recomendação temporária

  • Aos proprietários que já haviam instalado a atualização, mas ainda não tinham enfrentado falhas, foi recomendado evitar o uso do modo híbrido ou do modo elétrico
  • Depois disso, a Jeep distribuiu com urgência um patch corretivo (atualização de correção)

Contexto e lições

  • Assim como no caso da Crowdstrike no ano passado, o episódio reforça que atualizações de software na tarde de sexta-feira podem se transformar em um problema de grande escala
  • Com este incidente, a Stellantis também passa a aprender a importância do timing das atualizações e dos testes prévios
  • No momento, não há resposta oficial da Stellantis; novas informações serão adicionadas quando houver atualização

1 comentários

 
GN⁺ 2025-10-14
Opiniões no Hacker News
  • Meu veículo 4xe parou na frente de casa depois da atualização de software de sábado, e quero explicar, como proprietário de um 4xe, o quão péssima foi a resposta da Jeep/Stellantis
    • Até 8h da manhã de segunda-feira, não houve nenhuma comunicação nem reconhecimento oficial por parte de contas oficiais da Jeep ou da empresa
    • Só descobri o problema porque fui procurar em grupos da Jeep no Facebook se havia outras pessoas com o mesmo sintoma
    • Até a informação mais “oficial” era apenas uma postagem em um fórum off-road feita pela conta ‘JeepCares’, operada pela Jeep, e até as orientações dessa conta eram contraditórias. Primeiro disseram que a atualização do Uconnect e a atualização de telemática eram coisas separadas, depois passaram a aconselhar adiar a atualização do Uconnect, como se as duas estivessem ligadas
    • Pela falta de informação da Jeep, as pessoas passaram a depender de todo tipo de rumor, do tipo “se reiniciar o Uconnect em tal modo, a luz de check engine apaga”. Na prática, a reclamação sumia, mas o problema de fundo não era resolvido
    • Não há como saber se você recebeu a atualização defeituosa
    • Também não dá para saber se você recebeu o patch
    • Os concessionários também não sabem absolutamente nada do que está acontecendo
    • E, enquanto escrevo isto agora, continuo exposto ao risco de o carro perder potência de repente no meio da rodovia e parar
    • É realmente assustador que o sistema de potência do carro, isto é, o motor, possa desligar enquanto o veículo está em movimento na rodovia. Segundo a matéria, isso realmente aconteceu; em alguns casos foi em baixa velocidade perto de casa, mas algumas pessoas afirmam que o conjunto motriz falhou enquanto dirigiam na rodovia. É um problema realmente chocante
    • É insano que isso esteja acontecendo no mundo real. Há alguns anos, durante uma due diligence de investimentos no setor automotivo, eu apontava que, antes de qualquer atualização, era preciso obrigatoriamente verificar se o veículo estava parado e com o motor desligado. Lembro que acharam curioso eu insistir que uma situação dessas poderia levar a um problema sério
    • Isso soa como o caso clássico de uma equipe que não conseguiu cumprir o prazo original, foi empurrando tudo sucessivamente e, no fim, lançou o código às pressas porque ninguém tinha margem para assumir responsabilidade por causa dos planos de férias. Sob pressão de tempo e dominados por viés de confirmação, empurraram código apesar dos sinais de problema, e agora os principais responsáveis provavelmente estão num avião, incomunicáveis ou de férias sem notebook para reagir
    • Fico curioso sobre como validaram que uma atualização de software pudesse ser executada com o carro em movimento e levar à perda de potência. Quando trabalhei numa fornecedora automotiva, havia várias proteções para evitar corrupção em atualizações, e a mais básica era que a própria entrada na sessão de programação UDS já levava em conta velocidade do veículo ou modo de condução
  • Trabalho atualmente numa grande empresa de iluminação residencial e tenho experiência desenvolvendo o SO do roteador responsável pela conectividade das lâmpadas com a internet e o usuário. Nossa arquitetura OTAU usa atualização de sistema A/B com dois boot slots (link de referência). Com isso, se a atualização falhar, há rollback automático para a versão anterior, então nunca tivemos um dispositivo brickado. E isso em um eletrodoméstico que custa menos de US$ 100. Aí fica difícil não suspeitar que a ausência desse tipo de proteção num SUV de US$ 50 mil–60 mil seja corte de custo. Mesmo dobrando a capacidade de NAND num veículo desse nível, isso não representaria nem 0,5% do custo total. Se for realmente corrupção do boot slot, eu até entendo, mas decepciona ver como montadoras parecem se importar tão pouco com o código que distribuem
    • Tenho experiência tanto com luzes IoT quanto com carros, então consigo comparar os dois setores. Não é uma tentativa de defender ninguém. Grandes montadoras também são extremamente sensíveis a otimização de custos, e acho que esse problema não é de boot slot. Na maioria dos casos, software automotivo é projetado para impedir atualizações enquanto o veículo está em movimento. Isso aqui parece ter sido um bug grave no novo firmware. Também existe a crítica de que a indústria automotiva como um todo está no fundo do poço, mas a Stellantis em particular não é exatamente uma empresa conhecida por pagar salários de topo
    • Dispositivos Android (inclusive muitos carros que adotaram isso) também usam partições A/B para reduzir o risco de brick. Mas essa abordagem não elimina totalmente o risco. Se houver lógica complexa e vários dispositivos filhos precisarem ser atualizados ao mesmo tempo, então 2*N partições precisam se encaixar, e cada checkpoint pode falhar. Em geral, se o checkpoint de “está tudo bem” for marcado cedo demais, o sistema pode entrar num estado sem recuperação mesmo quando um serviço essencial falha
    • Em um dispositivo de US$ 50 mil–60 mil como um carro, 0,5% de custo também pesa muito. Por exemplo, a margem operacional da Ford é de 2%; um aumento de 0,5% no custo por veículo come 25% dessa margem. Carros têm volume anual relativamente menor e exigências de chip mais rígidas, então o custo dos componentes tende a ser mais alto. Atualização A/B também não é solução completa e, se mal configurada, pode até prender o sistema em loop infinito
    • Já ouvi dizer que, na indústria automotiva, até menos de US$ 5 por unidade pode gerar extrema sensibilidade. O próprio esquema A/B pode ter sido deixado fora da especificação, ou o tamanho do OTA pode ter batido no limite de armazenamento. Para ser ainda mais seguro, às vezes se usa A/B/A (em que B é um SO enxuto), mas na prática isso costuma ser inviável por falta de tempo de desenvolvimento
    • Tem lugar usando A/B até em dispositivo de US$ 100, então é provável que isso não seja corte de custo, mas sim problema de prioridade e capacidade. Talvez a especificação já tenha saído sem mecanismos de segurança de atualização, e a repetição de pressão de cronograma com fuga de responsabilidade tenha levado a um acidente como esse. Na prática, este caso não foi brick, mas sim a ocorrência de um bug crítico durante a condução
  • Aluguei um Jeep Wagoneer, e os eletrônicos eram tão ruins que um incidente desses nem surpreende. No segundo dia, a tampa traseira não fechava e apareceu uma mensagem de erro no painel; o travamento eletrônico simplesmente não funcionava. Pesquisei e vi muita gente com o mesmo problema dizendo que era preciso fazer atualização de software, sem nem existir método manual de destravamento. Como a loja da locadora era perto, troquei o carro, mas mesmo depois disso passei por vários outros problemas
    • Ao carregar pelo carregador do Steam Deck no banco traseiro, o painel inteiro, incluindo o sistema de infotainment, desligava e religava repetidamente
    • O banco do motorista descia para facilitar a saída, mas não voltava automaticamente à posição original, então eu ia ficando cada vez mais para trás
    • Surgia um alerta de erro do latch do banco traseiro que não dava para desligar, embora o latch estivesse normal
    • A luz do TPMS acendia e apagava o tempo todo (sinal ruim)
    • Erros relacionados ao controle de cruzeiro apareciam aleatoriamente
    • O freio de estacionamento eletrônico acionava automaticamente em paradas rápidas dentro do estacionamento
    • O ar-condicionado funcionava de forma estranha, deixando a cabine quente ou simplesmente sem resfriar
    • Há muita gente online relatando problemas parecidos ou até mais graves. É difícil acreditar que um veículo novo de US$ 80 mil tenha esse tipo de problema
    • Numa viagem recente em família, chegamos a trocar de Grand Wagoneer quatro vezes, e cada veículo tinha um problema crítico
    • Jeep e Stellantis/Dodge têm um controle de qualidade e um projeto eletrônico seriamente lamentáveis. Há muita comunidade de fãs, mas ela tende a romantizar defeitos frequentes. Comprar um veículo desses é se prejudicar por conta própria
  • Atualizar via OTA componentes críticos como ECU é um risco realmente inaceitável. Se for absolutamente inevitável, isso deveria ser feito obrigatoriamente na concessionária, por um profissional, com rollback preparado. As fabricantes começaram a automatizar tudo para buscar receita com serviços por assinatura, e isso está passando por cima da segurança do consumidor; por esse tipo de razão, entusiastas como eu preferem carros mais antigos
  • Esse incidente estourou menos de duas semanas depois de a Stellantis ter forçado recentemente um workflow de engenharia com 'vibe coding' (notícia relacionada)
    • Mas, para poder ser enviado via OTA para uma frota de veículos reais, esse código no mínimo já devia ter sido escrito mais de duas semanas antes
  • Estou dirigindo um Jeep há alguns meses, e a comunidade é toda focada em modificação, mas reclama do fato de o SO ser fechado e desenvolvido pela SiriusXM. O Jeep Wrangler, de todos os veículos, parece o candidato ideal para ser otimizado para open source
    • Isso não quer dizer que não exista atividade de hacking de software nas modificações do Wrangler. Com base no que foi apresentado neste fórum, houve até caso que virou produto comercial. Só nunca vi o firmware da head unit ser realmente aberto de forma adequada
    • Não é a Jeep a empresa que colocou um sistema de anúncios no infotainment mostrando pop-ups no sinal vermelho? Não faz sentido imaginar que a fabricante queira um SO open source que permita burlar esse tipo de anúncio
  • Não consigo entender por que uma atualização OTA pode deixar o veículo inteiro brickado. O sistema de infotainment e o sistema de condução não deveriam ser completamente separados?
    • Essa conclusão parte da suposição de que se trata apenas de um OTA do infotainment. Na verdade, isto é um OTA do veículo inteiro. Pode mexer em infotainment, ECU, ECM, TCM e BCM, e até recalls importantes são resolvidos por OTA, então também é impossível impedir atualização dos sistemas críticos. Em 2025, a maioria das fabricantes já tem esse tipo de capacidade OTA
    • A causa fundamental de problemas assim é corte de custo. Painel de instrumentos e infotainment são substituídos por monitores no lugar de componentes analógicos porque isso sai mais barato. O software também acaba sendo remendado sob a lógica de “nada de reescrever, só reutilizar”, então o teste de integração inevitavelmente fica fraco. Na era dos veículos elétricos, cada controlador de motor tem seu próprio software, e o OTA pode sobrescrever até isso. A única que parece sofrer menos com isso é a Toyota, por ter mais tempo de experiência acumulada
    • Como informações cotidianas — por exemplo, silenciar música enquanto o sensor de estacionamento atua, ou mostrar combustível/bateria restante — exigem interação entre o sistema de condução e o infotainment, separação completa é impossível
    • No passado, já tive o infotainment de um Tahoe brickado por uma atualização OTA. Depois disso, a câmera de ré também parou totalmente de funcionar, e até o som da seta desapareceu, o que me gerou quase US$ 2.000 em transporte e reparo, sem cobertura de garantia. Desde então, decidi desativar todas as atualizações no futuro
    • A Tesla criou o precedente desse OTA integrado, e depois a maior parte das fabricantes seguiu pelo mesmo caminho. A Volvo também vem enfrentando problemas parecidos
  • Não consigo entender por que sistemas de infotainment, em particular, dão tanto problema até para tantos engenheiros. No caso do Mazda 3 (2018), isso chegou a gerar ação coletiva. Depois de anos funcionando normalmente, o menu começava do nada a reagir aleatoriamente, botões eram acionados sozinhos, o problema sumia por dias ou meses e depois reaparecia. No fim, tive que desconectar todos os dispositivos e dirigir ouvindo só rádio
    • Isso nasce de uma base sem integração vertical, com mais de 20 mil ECUs separadas por função, e de contratos espremidos até o limite com fornecedores, reduzindo ao extremo o custo de cada peça. E também do fato de fabricantes “tradicionais” e fornecedores tier 1 quase não se importarem em adotar inovação em software
    • Recentemente conectei um celular Android a um Mercedes por Bluetooth e, apesar de ser uma marca “de luxo”, encontrei logo de cara cinco bugs de GUI só no processo de configuração. No geral, o carro tinha acabamento aceitável, mas a qualidade do software claramente é questão de vontade. (Aliás, interfaces de set-top box também são lentas demais para o hardware que têm)
    • Esses problemas são simplesmente resultado de terceirização e corte de custos. Sem integração vertical, tudo vai para o fornecedor mais barato
    • Trabalhei no passado numa empresa de software de infotainment, e aqueles sistemas mostravam o extremo da economia de custos. RAM mínima, CPU mínima, telas ruins — até em carros de categoria alta era assim. Rádio automotivo sempre foi um símbolo clássico de corte de custo
    • Diferentemente do mercado de celulares, em que sai produto novo todo ano, um único dispositivo no carro precisa continuar funcionando por mais de dez anos, com equipe mínima e comportamento consistente
  • Nunca ouvi um grande caso de atualização OTA da Tesla ter deixado o carro inteiro brickado — isto é, um brick de verdade, sem se mover. Pelo que sei, a Tesla projetou isso com uma estrutura de dual BIOS, como a dual BIOS de placa-mãe
    • Acompanho comunidades de Tesla há mais de dez anos e nunca vi caso de brick por OTA. Na maioria das vezes, o máximo que acontece é a pessoa ficar irritada porque a atualização entrou bem na hora em que precisava sair correndo
    • A Tesla faz muito teste HIL, e a abordagem geral de testes é mais a de uma empresa de software do que a de uma montadora
    • Na prática, se você pesquisar no Google, existem sim alguns casos de brick por OTA na Tesla. Exemplo relacionado
  • Link para a discussão do fim de semana