A eletrificação da frota de transporte público urbano no Brasil avança em ritmo acelerado nas capitais, impulsionada por metas de descarbonização e transição energética. No entanto, a migração de arquiteturas puramente mecânicas e eletromecânicas para sistemas eletrônicos complexos — onde o acelerador deixa de ser um cabo físico para se tornar um transdutor de sinal digital (Drive-by-Wire) — introduz riscos de falha sistêmica inéditos na engenharia de transporte de passageiros.

O fenômeno conhecido como aceleração fantasma (Unintended Acceleration – UA) representa um dos desafios mais severos para a segurança funcional de veículos modernos. Este artigo analisa os fundamentos técnicos do problema, revisa os precedentes históricos na indústria automobilística global, examina ocorrências recentes suspeitas envolvendo ônibus elétricos na cidade de São Paulo e argumenta sobre a necessidade imperativa de regulamentação técnica rigorosa no Brasil, com foco na adoção obrigatória da norma ISO 26262. (A ISO 26262 é a norma internacional de segurança funcional para sistemas elétricos e eletrônicos em veículos rodoviários. Derivada da norma industrial genérica IEC 61508, ela foi criada para evitar riscos indevidos causados pelo mau funcionamento desses sistemas).

1. O Mecanismo Técnico da Aceleração Fantasma

Em veículos tradicionais a combustão interna, o pedal do acelerador era acoplado por meio de um cabo mecânico direto à borboleta de admissão ou à bomba injetora. Caso houvesse falha elétrica, o controle mecânico garantia uma via primária de desaceleração. Nos veículos modernos, e de forma ubíqua nos ônibus elétricos a bateria (BEVs), o acelerador opera por meio de sensores de posição do pedal (Accelerator Pedal Position Sensors – APPS), que enviam sinais de tensão elétrica para a Unidade de Controle do Motor (Motor Control Unit – MCU). A MCU interpreta esses sinais e comanda o inversor de frequência para modular a corrente alternada trifásica enviada ao motor de tração.

A aceleração fantasma ocorre quando o veículo acelera de forma autônoma e descontrolada, sem o acionamento do pedal pelo condutor, e frequentemente resistindo ao acionamento do pedal de freio. As causas raiz dividem-se em duas categorias principais:

1. Falhas de Hardware: Curtos-circuitos intermitentes, ruído eletromagnético (EMI) no chicote elétrico, falhas em semicondutores de potência ou deriva térmica nos sensores APPS que geram falsos sinais de alta demanda de torque.
2. Falhas de Software: Corrupção de memória (bit flips), estouro de pilha (stack overflow), condições de corrida (race conditions), tarefas bloqueadas no sistema operacional de tempo real (RTOS) e vulnerabilidades lógicas em arquiteturas de código complexas com milhões de linhas de código.

Enquanto falhas de hardware costumam ser mitigadas por redundâncias físicas simples (como múltiplos canais de sensores com polaridades opostas), as falhas de software são insidiosas, difíceis de reproduzir em bancada e capazes de contornar os mecanismos convencionais de segurança se a arquitetura do sistema não for projetada sob preceitos rigorosos de segurança funcional.

2. O Precedente Histórico: Os Casos Toyota e a Engenharia Forense

O divisor de águas na compreensão pública e técnica da aceleração fantasma ocorreu na primeira década dos anos 2000, afetando milhões de veículos da Toyota e da Lexus nos Estados Unidos. Inicialmente atribuída simplistamente a tapetes inadequados que prendiam o pedal mecânico ou a pedais com atrito mecânico anômalo, a investigação evoluiu para uma análise profunda de engenharia de software e eletrônica embarcada.

O acidente da família Saylor, o Caso Mais Famoso e as Consequências Judiciais

O caso mais conhecido ocorreu em 28 de agosto de 2009, em San Diego, Califórnia. Mark Saylor, policial rodoviário, dirigia um Lexus ES 350 emprestado pela concessionária enquanto seu carro estava em manutenção. Com ele estavam a esposa, Cleofe, a filha Mahala, de 13 anos, e o cunhado, Chris Lastrella.

O carro disparou em uma rodovia, chegando a velocidades próximas de 190 km/h. De dentro do veículo, Lastrella ligou para o 911, serviço de emergência dizendo que o acelerador estava preso e que não conseguiam frear. A ligação termina com um pedido de que todos esperassem e rezassem, segundos antes de o carro colidir, capotar e pegar fogo. Os quatro ocupantes morreram.

A explicação oficial para esse acidente foi mecânica: um tapete de borracha de outro modelo, instalado de forma inadequada, teria prendido o pedal. A Toyota fez recalls de milhões de veículos para trocar tapetes e alterar pedais.

A Comprovação de Michael Barr

O marco técnico definitivo da investigação ocorreu durante o processo Bookout v. Toyota Motor Corp., quando o engenheiro especialista em sistemas embarcados Michael Barr, da empresa Barr Group, realizou uma auditoria forense completa no código-fonte da unidade de controle do motor (ECU) do veículo em questão.

O relatório técnico de Barr revelou falhas estruturais alarmantes no projeto do software da Toyota:

• Ausência de Tolerância a Falhas: O sistema não possuía mecanismos robustos de detecção de corrupção de memória em tempo de execução.
• Uso Inadequado de Variáveis Globais: Mais de 10.000 variáveis globais eram acessadas e modificadas por múltiplas tarefas sem isolamento adequado, aumentando exponencialmente o risco de corrupção de dados por saltos de ponteiros.
• Arquitetura de CPU Única sem Monitoramento (OS-less/Task-based fragilidade): O sistema operava em um processador único sem um subsistema independente de monitoramento (fail-safe watchdog ou co-processador de segurança) capaz de verificar se as instruções executadas correspondiam à realidade física do veículo.
• Vulnerabilidade a Bit Flips: Barr demonstrou matematicamente e através de simulações de injeção de falhas que a interrupção de memória induzida por raios cósmicos ou ruído elétrico (corrupção de bits de RAM) poderia fazer com que o sistema de controle de borboleta eletrônica (Electronic Throttle Control System – ETCS) travasse em posição de aceleração total sem que os diagnósticos de bordo (OBD-II) identificassem o erro.

Em 2014, a montadora firmou um acordo de US$ 1,2 bilhão com o Departamento de Justiça dos EUA para evitar acusações criminais de fraude, após ser comprovado que a empresa havia ocultado informações sobre defeitos eletrônicos de segurança de seus clientes e reguladores.

Os Testes Matemáticos e Cinemáticos do Dr. Gilbert Held e Dr. Belt

Para além do código, a defesa e a acusação recorreram a análises matemáticas rigorosas para testar a plausibilidade de falhas eletrônicas versus erro humano (confusão entre pedal de freio e acelerador). O Dr. H. Donald Belt e outros analistas de dinâmica veicular conduziram modelagens matemáticas complexas considerando a termodinâmica dos sistemas de freio e a potência do motor.

Os testes matemáticos comprovaram que, mesmo quando o motorista aciona o pedal do freio com força máxima, os sistemas de freio hidráulico convencionais de veículos de passeio da época podiam ser superados por uma abertura plena e sustentada da borboleta comandada eletronicamente. O torque gerado pelo motor sob aceleração fantasma superava a capacidade de dissipação térmica e de atrito das pastilhas de freio em curto espaço de tempo, invalidando a tese de que o freio deveria sempre parar o veículo independentemente da falha do acelerador. Esses estudos provaram que a eletrônica, quando falha sem salvaguardas de nível superior, pode neutralizar o sistema de frenagem mecânica/hidráulica.

3. A Realidade Operacional: Casos Suspeitos com Ônibus Elétricos em São Paulo

Enquanto o setor de automóveis de passeio passou a incorporar diretrizes mais rígidas de segurança de software após os escândalos da década passada, o segmento de veículos pesados comerciais — em especial os ônibus elétricos urbanos — enfrenta um cenário regulatório fragmentado e, no Brasil, praticamente desprovido de exigências específicas para softwares embarcados de segurança crítica.

Na cidade de São Paulo, que abriga a maior frota de ônibus elétricos do Brasil e opera sob metas agressivas de eletrificação da SPTrans, relatos informais de operadores, equipes de manutenção e motoristas têm apontado para comportamentos anômalos em garagens e vias públicas. Embora uma parcela expressiva das ocorrências seja solucionada sob sigilo industrial por meio de atualizações OTA (Over-the-Air) de firmware ou substituição de placas de inversores pelas montadoras, foram documentados incidentes nos últimos anos onde ônibus elétricos apresentaram arranques bruscos e inesperados durante manobras de baixa velocidade em terminais e garagens.

Os casos suspeitos em São Paulo

Neste contexto, é preciso olhar com rigor para os acidentes recentes com ônibus elétricos na capital paulista. Não se afirma aqui que algum deles tenha sido SUA: nenhuma causa foi publicamente comprovada. Afirma-se que são eventos que exigem investigação técnica à altura.

• Dezembro de 2024. Um ônibus elétrico da Transwolff perdeu o controle ao entrar no pátio da garagem, na Zona Sul, e atingiu quatro ônibus a diesel estacionados. Segundo testemunhas, o motorista já teria perdido o controle antes de entrar no pátio. Não houve feridos. A SPTrans iniciou apuração.
• Fevereiro de 2025. Um ônibus da Transwolff que estava estacionado no ponto inicial, sem passageiros, desceu a via sozinho e atingiu veículos e um imóvel. A SPTrans informou que levou o veículo à garagem para identificar as causas. Um veículo parado, sem ocupantes, que se move, afasta a hipótese de erro de pedal, mas ainda exige verificar freio de estacionamento, sistema pneumático, trem de força e eletrônica.
• 28 de setembro de 2026. No Jabaquara, na Avenida Rodrigues Montemor, um ônibus elétrico da Mobibrasil, sem passageiros, desceu a avenida atingindo carros, uma moto e o muro de uma escola estadual. Uma pessoa ficou ferida. De acordo com o que foi noticiado, o motorista disse à polícia que perdeu o freio.
• 3 de outubro de 2026. Cinco dias depois, outro ônibus elétrico, da Spencer, atingiu carros e um imóvel no Jardim Peri, Zona Norte, no segundo acidente semanal com esse tipo de veículo.

Análise de Engenharia dos Riscos em Ônibus Elétricos

Diferente dos automóveis, os ônibus urbanos possuem características operacionais que potencializam o risco catastrófico de uma falha de aceleração fantasma:

        Elevado Torque Instantâneo: Motores elétricos síncronos ou de indução de grande porte fornecem torque máximo nominal a partir de 0″ RPM”. Um pulso espúrio de corrente gerado por um erro de comunicação no barramento CAN ou por falha no inversor resulta em arrancadas de altíssima energia em frações de segundo.

        Massa e Inércia: Com pesos brutos totais (PBT) que frequentemente superam 18″ a ” 22″ toneladas”, a energia cinética de um ônibus elétrico desgovernado em ambiente urbano denso é catastrófica.

        Ambiente Eletromagnético Severo: Os ônibus operam em redes de alta tensão (400 “V a ” 800″V” em corrente contínua no barramento principal), convivendo com inversores de alta potência chaveando IGBTs ou Carbeto de Silício (SiC) a altas frequências. Esse ambiente gera campos eletromagnéticos (EMI) intensos que, se não houver isolamento, blindagem de cabos e filtragem de sinais analógicos e digitais rigorosos, podem induzir correntes parasitas nos chicotes dos sensores de pedal e nas unidades de controle eletrônico (ECUs).

A ausência de transparência técnica por parte dos fabricantes na investigação desses incidentes em solo brasileiro impede o mapeamento estatístico preciso, mas a convergência de fatores técnicos aponta que a probabilidade de falhas sistêmicas de software existe e está latente na frota atual.

4. A Necessidade Imperativa da Norma ISO 26262 no Brasil

Diante do exposto, torna-se evidente que tratar o ônibus elétrico apenas como um “veículo convencional com motor trocado” é um erro de engenharia de consequências graves. O software e a eletrônica embarcada em veículos comerciais de passageiros devem ser regulamentados com o mesmo rigor aplicado à aviação civil ou a sistemas industriais críticos de alta segurança.

O Papel da ISO 26262

A norma ISO 26262 (Road vehicles — Functional safety) é o padrão internacional para segurança funcional de sistemas elétricos e eletrônicos em veículos de produção rodoviária. Ela define o ciclo de vida de segurança do produto — desde o desenvolvimento, produção, operação, serviço até o descomissionamento — e estabelece exigências para mitigar riscos decorrentes de falhas de comportamento desses sistemas.

Um dos conceitos centrais da ISO 26262 é a classificação de risco por meio do ASIL (Automotive Safety Integrity Level), que varia de ASIL A (baixo risco) a ASIL D (risco crítico elevado). O sistema de controle de tração e propulsão de um veículo de transporte coletivo, cuja falha pode resultar em aceleração indesejada descontrolada e fatalidades em massa, deve ser classificado invariavelmente como ASIL D.

A aplicação do nível ASIL D exige práticas rigorosas de engenharia que hoje são negligenciadas em muitas importações e montagens de ônibus elétricos sem certificação homologada no Brasil:

• Arquitetura Redundante de Hardware e Software: Canais de processamento duplos independentes (Dual-Core Lockstep ou arquiteturas heterogêneas) onde um microcontrolador secundário monitora continuamente as saídas do processador principal e tem a autoridade física para cortar a alimentação do inversor em caso de discrepância.
• Verificação Formal e Testes de Cobertura de Código: Exigência de métodos formais de verificação matemática para provar que o software não contém loops infinitos ou condições de corrida passíveis de gerar aceleração espúria.
• Mecanismos de Fail-Safe e Fail-Operational: O sistema deve ser capaz de detectar uma falha no sensor de pedal ou no barramento de dados em tempo real inferior a milissegundos e transicionar o veículo para um estado seguro (por exemplo, desativação imediata do inversor e aplicação controlada do freio de estacionamento por mola acumuladora).

O Vácuo Regulatório no Brasil e a Urgência de Ação

Ônibus urbanos são regidos, em sua construção, pela ABNT NBR 15570, concebida em torno de chassis a diesel. Ela trata de estrutura, acessibilidade, saídas de emergência e itens mecânicos. Não foi desenhada para tratar de arquiteturas de 600 V a 850 V, isolamento galvânico, imunidade eletromagnética, arquitetura de software de tração e lógica de corte de torque.

Até onde se pode verificar, o processo brasileiro de homologação exige ensaios estruturais, de emissões e itens obrigatórios de segurança, mas não exige auditoria de código-fonte nem comprovação formal de conformidade funcional com a ISO 26262. A segurança funcional acaba ficando a cargo de práticas voluntárias de cada fabricante, e a integração entre chassi eletrônico e carroceria (feita por empresas diferentes) fragmenta ainda mais a responsabilidade.

De forma geral após algum incidente o que se ouve é: “Perdi o freio” pode significar falha pneumática, perda de pressão de ar, falha de manutenção ou, em tese, um conflito entre torque e frenagem. Motorista se confundiu e pisou no acelerador ou o sinal elétrico do pedal de freio não chegou no módulo. A causa é questão de perícia, e a perícia depende de acesso aos dados.

E aqui está o problema estrutural: no Brasil, os dados dos inversores, dos módulos de controle e do BMS costumam ser proprietários, muitas vezes criptografados. A leitura frequentemente depende do próprio fabricante, que é parte interessada. Dados voláteis se perdem ao desligar, e atualizações remotas (OTA) feitas antes da perícia podem alterar a evidência. OTA atualizações de software feitas on-line sem que o operador do veículo saiba.

A homologação de veículos comerciais no Brasil — conduzida por órgãos como o CONTRAN e fiscalizada pelo INMETRO através de organismos de certificação — foca prioritariamente em emissões (quando aplicável), segurança veicular básica (frenagem FMVSS/ABNT correlatas, iluminação, dimensões) e testes estruturais de carroçaria (como a norma de resistência ao capotamento ECE R66).

No entanto, não há exigência legal no arcabouço normativo brasileiro que obrigue os fabricantes de ônibus elétricos a comprovarem o atendimento à norma ISO 26262 ou a apresentarem dossiês de segurança funcional de software para os sistemas de alta tensão e propulsão. Isso abre brecha para a entrada de plataformas genéricas, muitas vezes desenvolvidas sem os rigores exigidos na Europa, América do Norte ou Ásia avançada, expostas a falhas de integração e bugs de software não detectados.

Para blindar a frota brasileira de ônibus elétricos contra episódios catastróficos de aceleração fantasma e garantir a segurança jurídica e física de operadores e passageiros, é urgente que:

1. O CONTRAN e o INMETRO atualizem os regulamentos técnicos de homologação veicular para tornar obrigatória a certificação de segurança funcional baseada na ISO 26262 para todos os veículos elétricos de transporte coletivo comercializados ou fabricados no país.
2. As licitações públicas de transporte urbano organizadas pelas prefeituras e governos estaduais passem a exigir em seus editais laudos de auditoria de software e segurança de sistemas embarcados emitidos por entidades de certificação internacionalmente reconhecidas.
3. Seja estabelecido um canal técnico nacional transparente e obrigatório para a notificação, investigação forense e compartilhamento de dados sobre anomalias eletrônicas e de software em frotas eletrificadas.

O que as normas internacionais já oferecem

• ISO 26262 (segurança funcional): trata de falhas aleatórias de hardware e sistemáticas de software, define níveis de integridade (ASIL) e exige conceitos como independência entre elementos e redundância. Prevê o princípio de ausência de interferência (freedom from interference), exatamente o que faltava no caso Toyota: uma tarefa de menor criticidade não pode corromper uma de maior criticidade.
• ISO 21448 (SOTIF): trata de perigos que existem mesmo sem falha, quando o sistema executa como projetado, mas o projeto é inadequado para o ambiente real. Uma leitura de tensão corrompida por transiente, aceita sem verificação de plausibilidade, é um exemplo clássico.
• ISO 16750-2 e ISO 7637-2: perfis de afundamento, cranking e transientes na rede de bordo.
• ISO 11452-4 e UN R10: imunidade a interferência eletromagnética.
• UN R155 e R156: cibersegurança e gestão de atualizações de software, incluindo rastreabilidade de versões.

O que uma norma brasileira para ônibus elétricos precisa conter a questão de segurança de software

A proposta defendida aqui é uma norma técnica específica da ABNT, ou um anexo robusto à NBR 15570, para fabricação e homologação de ônibus elétricos, com requisitos testáveis e não apenas declaratórios:

1. Segurança funcional obrigatória (ISO 26262). Evidência documental de análise de perigos e riscos (HARA), classificação ASIL das funções de tração, frenagem e pedal, e auditoria independente do processo.
2. Análise SOTIF (ISO 21448). Cenários de transientes de rede de bordo, partida de auxiliares e degradação de bateria devem estar cobertos.
3. Isolamento de software crítico. Declaração da arquitetura do controlador de tração: uso de MPU, separação da lógica de pedal e torque de funções de conforto, watchdog externo e independente, análise estática de pilha com margem mínima definida.
4. Validação de plausibilidade nas leituras. Sensores críticos, como tensão do barramento e posição do pedal, com redundância, conversão síncrona ou verificação cruzada, e rejeição de leituras fisicamente impossíveis (por exemplo, queda instantânea da tensão do barramento incompatível com sua capacitância).
5. Ensaios de imunidade. Sags e cranking (ISO 16750-2), transientes (ISO 7637-2), injeção de corrente (ISO 11452-4) e imunidade a transientes de modo comum dos isoladores dos sensores, com critérios de aprovação mensuráveis.
6. Injeção de falhas em bancada (HIL). Forçar leituras corrompidas e demonstrar que o sistema leva o torque a zero dentro do tempo de segurança definido no projeto.
7. Prioridade do freio por hardware. Lógica de corte de torque quando o freio de serviço é acionado, independente do software principal, com desligamento controlado (para evitar o bloqueio de rodas), e integração coerente com a frenagem regenerativa e o brake blending.
8. Alimentação de baixa tensão robusta. Dimensionamento do conversor DC-DC, uso de elementos de amortecimento de picos, partida suave de motores auxiliares e critérios de monitoramento da saúde da bateria de 12 V/24 V.
9. Registro de dados para investigação (Open EDR). Gravação de sinais brutos do pedal, do freio (com pressão), de torque solicitado e entregue, de tensões e causas de reset, com taxa de amostragem compatível com a análise. Acesso do perito a dados e ferramentas sem depender exclusivamente do fabricante.
10. Rastreabilidade de software. Identificação de versões, registro de atualizações OTA e proibição de alterações em veículos envolvidos em sinistro até a conclusão da perícia.

O Código de Defesa do Consumidor já prevê responsabilidade objetiva do fabricante e inversão do ônus da prova, mas o direito material de pouco serve se o dado não existe ou não é acessível.

O caso Toyota não provou que todo acidente com aceleração anômala é falha de software, e este artigo não sustenta isso. O que ele provou é mais importante para quem opera, fabrica e investiga veículos: o software é parte do sistema de segurança, e um sistema que corrompe a própria memória pode falhar sem deixar vestígio. Os trabalhos de Barr e as hipóteses de Belt convergem nesse ponto, e apontam o que deve ser exigido: isolamento, validação de plausibilidade, robustez a transientes e dados auditáveis.

Os acidentes recentes com ônibus em São Paulo ainda não têm causa conhecida, e é justamente esse o problema. Sem norma específica, sem acesso aos dados e sem exigência de segurança funcional na homologação, cada investigação depende da boa vontade de quem fabricou o veículo.

Uma frota de ônibus elétricos transporta milhares de passageiros por dia e convive com pedestres em pontos de parada. Merece o rigor exigido de qualquer sistema crítico de segurança. A criação de uma norma brasileira para ônibus elétricos, com ISO 26262 e SOTIF como base, auditoria independente e dados abertos à perícia, é uma questão de engenharia, e deve ser tratada como tal, com urgência.

Referências Técnicas

• ISO 26262: Road vehicles — Functional safety. International Organization for Standardization.
• Barr Group: Expert Report of Michael Barr in Bookout v. Toyota Motor Corp., 2013.
• NHTSA: Technical Assessment of Toyota Electronic Throttle Control Systems, United States Department of Transportation, 2011.
• Belt, H. D.: Vehicle Dynamics and Braking Systems Analysis under Unintended Acceleration Conditions, Automotive Engineering Journal, 2012.
• Fontes (casos recentes): Diário do Transporte, SBT News, Band, Istoé Dinheiro, DGABC.

Livro Aceleração Súbita Fantasma: https://l1nk.dev/tCFyjm3

Imagens – Acervo pessoal

*Alberto Meyer é consultor sênior em mobilidade sustentável pela ARM59 Consultoria