ESTUDO DE CASO

Um estudo de caso técnico sobre um scanner de diagnóstico automotivo, com mais de 200,000 unidades enviadas por diversas linhas de produção de fabricantes de equipamentos originais (ODMs) — abordando decisões arquitetônicas reais, uma falha em campo que reescreveu nossas regras de PCB e os dados que realmente impulsionam as devoluções.

200k +Unidades enviadas

4.2% → 0.3%Taxa de falhas de comunicação

68%RMAs: Dados OEM ausentes

40-60%Cobertura real aprimorada

1. Visão geral do projeto

1.1 Histórico do Cliente

O cliente era uma marca de equipamentos para serviços automotivos com uma linha consolidada de ferramentas OBD de nível básico — como adaptadores baseados em ELM327 e leitores de código simples. Eles queriam subir na cadeia de valor e entrar no mercado de scanners multissistema profissionais. 

Mercado-alvo: oficinas de reparação independentes, operações de manutenção de frotas e boxes de serviço de concessionárias. Os mercados definidos desde o início foram a América do Norte e a Europa, com a Ásia como alvo em uma segunda fase.

A lacuna que eles estavam tentando preencher era real. As ferramentas básicas leem códigos genéricos do sistema de transmissão. As oficinas profissionais precisam de ABS, SRS, transmissão, TPMS, controles bidirecionais e dados da ECU em tempo real de dezenas de marcas. Essa mudança não se resume a uma atualização de firmware. Trata-se de um hardware e software completamente diferentes.

Leia também: Estudo de Caso de Tablet Robusto

1.2 Metas do Projeto

• Conformidade total com OBD-II como requisito mínimo, não como requisito máximo.

• Suporte a múltiplos protocolos, incluindo CAN, LIN e FlexRay

• Análise de dados da ECU em tempo real com baixa latência

• Conectividade sem fio para sincronização na nuvem e diagnóstico remoto

• Durabilidade de nível industrial para ambientes de oficina

• Projeto pronto para produção, aprovado para certificação global

• Caminho de atualização claro para diagnósticos de veículos elétricos sem a necessidade de uma reformulação completa do hardware.

2. Desafios da Indústria no Desenvolvimento de Ferramentas de Diagnóstico Automotivo

2.1 Compatibilidade multiprotocolo

A afirmação de "mais de 95% de compatibilidade com modelos de veículos" está em todas as caixas de scanners do mercado. Depois de enviarmos mais de 200,000 unidades, incluindo clones do ELM327 e tablets multiprotocolo completos, podemos dizer exatamente o que esse número esconde.

Abrange apenas a conformidade básica com a legislação OBD-II — modos 01 a 0A das normas SAE J1979 e ISO 15031 em cinco protocolos legados: ISO 9141-2, ISO 14230-4 KWP2000, SAE J1850 PWM e VPW, e ISO 15765-4 CAN a 250 e 500 kbps. Isso significa que o dispositivo lê PIDs genéricos do trem de força, status da MIL e dados de congelamento de quadro em qualquer veículo americano fabricado a partir de 1996 que atenda aos requisitos legais mínimos.

O que não abrange: PIDs definidos pelo fabricante, acesso aos módulos ABS/SRS/transmissão/TPMS, controles bidirecionais, adaptações ou chaves de acesso de segurança. Veículos fabricados após 2018 que utilizam UDS em CAN ou CAN FD ampliam ainda mais essa lacuna. Quando realizamos nossa própria validação com uma frota de 50 veículos, os scanners que alegavam 95% de compatibilidade básica apresentaram uma média de apenas 40 a 60% em dados avançados para veículos não fabricados nos EUA.

A métrica que os engenheiros de compras devem exigir é: uma matriz de cobertura detalhada e aprimorada pelo fabricante original (OEM) em Excel, discriminada por marca, modelo e ano — mostrando os códigos de falha (DTCs) aprimorados suportados por ECU, o status do CAN FD e DoIP, a capacidade de passagem J2534 e a frequência de atualização do banco de dados. Qualquer outra coisa é marketing.

2.2 Estabilidade da comunicação da ECU

Os ambientes elétricos dos veículos são hostis. Injetores diesel common-rail, ruídos de comutação do alternador e picos de tensão durante a partida do motor geram transientes que testes em bancada jamais detectarão. A tensão na porta OBD varia de 9V a 36V, dependendo do veículo, do estado de carga e de outros componentes conectados ao barramento. A proteção contra inversão de polaridade não é opcional — é um item coberto pela garantia.

Aprendemos isso da maneira mais difícil. Um projeto ODM de 2023, utilizando um SoC GD32F103 com transceptor CAN TJA1050, passou em 100% dos testes de bancada — diagramas de olho limpos, sem perda de pacotes a 500 kbps. A primeira falha em campo ocorreu em uma oficina europeia, em uma Mercedes Sprinter diesel de 2019. A unidade desconectava-se do barramento intermitentemente, apresentava códigos de falha U0100 (perda de comunicação) e erros de limpeza de DTC (códigos de falha de diagnóstico) corrompidos. Causa raiz: diodos TVS subdimensionados e ausência de indutores de modo comum nas conexões CANH e CANL. Transientes de tensão, conforme os pulsos 3a e 3b da norma ISO 7637-2 — até +/-150V durante a partida do motor — eram transmitidos diretamente pelo conector OBD. O transceptor resistiu aos testes de bancada, mas apresentou falha em campo após aproximadamente 200 horas de uso acumuladas.

2.3 Complexidade do Banco de Dados de Software

Nossos dados de RMA de 120,000 unidades ao longo de 18 meses mostram que 68% das devoluções são registradas como "não funciona no meu XYZ 2024" — mesmo quando o hardware suporta os protocolos corretos. A entrada específica do fabricante no banco de dados estava faltando ou a negociação da chave de segurança falhou silenciosamente. Unidades com atualizações de banco de dados OTA pouco frequentes apresentam taxas de devolução de 18% a 22% quando um novo modelo é lançado. Isso é um problema de negócios, não de hardware.

2.4 Ambiente de Oficina Robusto

Mecânicos não tratam tablets de diagnóstico com delicadeza. Eles deixam os scanners conectados durante testes de alternador, ciclos de ignição e partidas auxiliares. As ferramentas caem das soleiras das portas dos veículos, ficam cobertas de óleo e são deixadas em vans frias durante a noite. A faixa de operação de -10 a 55 graus Celsius não é um número da ficha técnica — é a faixa real que um scanner vê entre uma manhã de janeiro em um estacionamento em Minnesota e um compartimento do motor em um verão no Texas.

3. Projeto de Arquitetura do Sistema

3.1 Plataforma de Processamento Central

O processador principal da aplicação é um ARM Cortex-A executando Android ou Linux embarcado. O Android se destaca pela velocidade de desenvolvimento da interface do usuário e pela maturidade do ecossistema de atualizações OTA. O Linux é mais eficiente para caminhos de diagnóstico sensíveis à latência. Um microcontrolador dedicado gerencia a camada de controle de comunicação separadamente — manter o processador da aplicação fora do barramento do veículo reduz a latência, melhora o isolamento de erros e impede que uma falha de software interrompa as sessões ativas da ECU. O tempo de inicialização alvo era inferior a 10 segundos, desde a inicialização a frio até o estado pronto para diagnóstico.

3.2 Interface de comunicação do veículo

O conector OBD-II de 16 pinos é o ponto de entrada, mas a camada física subjacente é onde a maioria dos projetos falha. A arquitetura utiliza transceptores CAN de alta e baixa velocidade, um circuito integrado de driver de linha K e linha L adequado — não transistores discretos —, um transceptor LIN e DoIP opcional via Ethernet para plataformas de 2020 em diante.

A escolha do driver da linha K é mais importante do que parece. Implementações discretas baratas não possuem a tolerância a 12V, o controle da taxa de variação e o desligamento por sobretemperatura de um CI dedicado como o L9637. Em ECUs asiáticas e europeias mais antigas que levam a linha a 12V durante a inicialização, a diferença se manifesta como comunicações intermitentes quase impossíveis de depurar em campo. O suporte a DoIP requer um PHY Ethernet, componentes magnéticos e uma pilha TCP/IP no MCU — um aumento de US$ 8 a US$ 12 na lista de materiais antes mesmo de considerar a complexidade do firmware. Não se trata de uma simples opção de software.

3.3 conectividade sem fio

• Wi-Fi 5 e 6 para sincronização de banco de dados em alta velocidade e registro de sessões na nuvem

• Bluetooth 5.0 para emparelhamento com o PC da oficina e visualização remota.

• Módulo 4G LTE opcional para diagnóstico em nuvem a partir de veículos em campo

• O módulo LTE também oferece suporte à assistência técnica remota com compartilhamento de fluxo de dados em tempo real.

3.4 Armazenamento e Segurança

O armazenamento eMMC varia de 32 a 128 GB, dependendo da versão do produto. Somente o banco de dados de veículos, com cobertura completa de fabricantes de equipamentos originais (OEMs) para marcas americanas, europeias e asiáticas, ocupa mais de 20 GB, sem contar os registros de logs e de sessão. A arquitetura de atualização de firmware segura utiliza pacotes de atualização assinados, cadeia de inicialização verificada e canais OTA criptografados. Autenticação de usuário e canais de comunicação criptografados são requisitos básicos para qualquer ferramenta de nível profissional vendida para frotas ou concessionárias.

4. Engenharia de PCB e Hardware

4.1 Projeto de PCB Multicamadas

A falha da Mercedes Sprinter em 2023 reescreveu nossas regras para placas de circuito impresso. A análise pós-projeto revelou oscilações nas linhas CAN superiores a 2Vpp — uma violação direta da norma ISO 11898-2 — causadas por filtragem de modo comum inadequada e má separação do plano de aterramento. Adotamos uma arquitetura de 6 a 8 camadas com um plano de aterramento analógico dedicado sob a seção do transceptor. Nenhuma trilha digital cruza a área do barramento CAN. Vias são interconectadas a cada 5 mm ao redor da seção analógica. O layout de EMI é uma restrição inicial, não um item de auditoria pós-projeto.

Componentes de nível automotivo em toda a sua extensão: classificações de temperatura estendidas, qualificação AEC-Q100 quando aplicável, seleção de CIs de longo ciclo de vida com estratégia de substituição documentada antes da fabricação do chip. A seção da camada física utiliza um front-end ASIC de protocolo dedicado com terminação programável e lógica de supressão de pulsos.

4.2 Projeto de Gerenciamento de Energia

A proteção contra sobretensão na entrada abrange toda a faixa de tensão do veículo, de 9V a 36V. A proteção contra descarga de carga lida com a sobretensão transitória que ocorre quando a bateria é desconectada de um alternador em funcionamento — esse evento gera picos acima de 60V que danificam circuitos desprotegidos. Os diodos TVS agora são arranjos bidirecionais com classificação ISO 7637-3, e não as peças P6KE6.8A que falharam no projeto Sprinter. As variantes portáteis incluem um sistema de gerenciamento de bateria para operação sem fio durante inspeções ao redor do veículo.

4.3 Proteção contra ESD e transientes

Cada pino OBD possui proteção TVS bidirecional com classificação ESD IEC 61000-4-2, ferrites em série e filtragem de modo comum de 100nF mais 100pF. A conformidade com a norma ISO 7637 é documentada. A especificação de proteção que utilizamos no projeto é ainda mais rigorosa — as condições reais de oficina excedem o que os modelos padrão exigem.

5. Software e funcionalidade de diagnóstico

5.1 Recursos de diagnóstico principais

• Leia e apague códigos de falha (DTCs) em todas as ECUs compatíveis — não apenas no trem de força.

• Monitoramento de fluxo de dados em tempo real com seleção de PID configurável e geração de gráficos.

• Captura de dados em estado de congelamento durante condições de falha

• Status do monitor de prontidão para testes de emissões

• Testes do sensor de O2 e teste de vazamento do sistema EVAP conforme o modo OBD-II 08

Essas são as funcionalidades obrigatórias por lei. Todos os scanners disponíveis no mercado as possuem. A questão é a confiabilidade com que funcionam em toda a gama de veículos cobertos — e não se elas existem.

5.2 Funções Avançadas

Codificação e programação de ECU para plataformas compatíveis — com uma ressalva importante. O bypass completo do gateway de segurança não está disponível em todas as plataformas de veículos de luxo e elétricos de 2024 em diante. Alguns módulos específicos da Mercedes, BMW e Tesla usam segurança baseada em código variável ou certificado, que não conseguimos quebrar. Isso é intencional. Recomendamos aos clientes que usem o scanner como uma ferramenta de triagem e serviço, e não como substituto de um dispositivo PASSTHRU da concessionária quando a programação da ECU for realmente necessária.

Para 95% do trabalho diário em oficinas mecânicas, o scanner é suficiente. Para os 5% restantes, o fluxo de trabalho ideal é nossa ferramenta de diagnóstico, além da integração J2534 com o software do fabricante. Essa transparência aumentou os pedidos recorrentes dos distribuidores, pois eles pararam de receber ligações de clientes insatisfeitos com alegações de "acesso total" que não se confirmam na prática.

• Reinicialização do TPMS e programação do sensor

• Diagnóstico de ABS e SRS com dados de sensores em tempo real

• Reinicializações de serviço: vida útil do óleo, desgaste das pastilhas de freio, registro da bateria

• Programação de chaves onde a segurança do fabricante do equipamento original (OEM) o permite

5.3 Integração em Nuvem

O diagnóstico remoto por meio de sessões registradas na nuvem permite que um técnico sênior revise dados em tempo real e o histórico de falhas de qualquer local. Geração de relatórios de veículos em formato PDF para documentação de serviço. Um banco de dados de suporte técnico online vinculado à identificação do veículo reduz o tempo de diagnóstico em plataformas desconhecidas. A integração com o painel de gerenciamento de frota está disponível para operadores com 10 ou mais veículos.

“Ao longo de 18 meses, 68% das nossas solicitações de RMA foram registradas como 'não funciona no meu veículo de 2024' — e não como falha de hardware. O registro no banco de dados estava ausente ou a negociação da chave de segurança falhou silenciosamente.”

6. Projeto Mecânico e Industrial

6.1 Projeto da Caixa

Classificação IP54 como especificação básica, IP65 para a versão premium. Revestimento emborrachado nos quatro cantos e na superfície traseira — não apenas estético, mas funcional. Quedas de soleiras de portas de veículos e bordas de bancadas são as causas mais comuns de falhas físicas em devoluções de campo. Uma estrutura interna de absorção de impacto desacopla a placa de circuito impresso dos impactos da carcaça. O conector OBD é reforçado separadamente, pois a tensão no conector devido ao peso do cabo é uma causa de falha a longo prazo que se manifesta após mais de 6,000 ciclos de conexão.

6.2 Design da interface do usuário

Tela sensível ao toque capacitiva de 7 a 10 polegadas, dependendo do modelo. Ajuste de sensibilidade ao toque compatível com luvas — essa é uma configuração de software que a maioria dos fabricantes de equipamentos originais (OEMs) ignora, e que se reflete imediatamente no feedback da oficina. Os mecânicos usam luvas de nitrilo constantemente. Um scanner que exige entrada com os dedos desprotegidos é descartado em uma semana. Botões físicos de atalho para as quatro funções mais comuns reduzem a dependência da tela sensível ao toque para operação com uma só mão.

6.3 Gerenciamento Térmico

Gabinetes selados não podem usar refrigeração ativa. O projeto térmico se baseia em um dissipador de calor interno de alumínio fixado ao processador e acoplado ao painel traseiro do gabinete, que atua como um radiador passivo. A estabilidade de operação contínua durante um turno de 8 horas era o objetivo do projeto. A meta: desempenho máximo mantido a 55 graus Celsius de temperatura ambiente, abrangendo o uso próximo ao compartimento do motor.

7. Conformidade e Certificação

7.1 Normas Automotivas

A conformidade com a norma ISO 7637 abrange a proteção contra transientes nas linhas de alimentação e na interface OBD. No entanto, a norma representa um patamar mínimo, não um teto. A falha na Mercedes Sprinter foi causada por transientes de pulso 3a e 3b, definidos pela ISO 7637-2 — e que nosso projeto original subestimou em um ambiente veicular real com alta interferência eletromagnética (EMI). A norma ISO 16750 abrange as cargas ambientais e elétricas dos componentes do veículo. Nossas especificações de projeto internas superam essas normas, principalmente em relação às classificações de proteção TVS e à filtragem de modo comum.

• ISO 7637 — imunidade a transientes e pulsos, proteção da linha de alimentação

• ISO 16750 — Requisitos ambientais e elétricos para componentes de veículos

• SAE J2534-1 e J2534-2 — conformidade direta para integração de software OEM

7.2 Certificações Globais

• Marcação CE — compatibilidade eletromagnética e segurança elétrica para o mercado europeu

• Autorização da FCC — Operação sem fio na América do Norte

• Conformidade com a RoHS — restrições de substâncias perigosas para os mercados da UE e da Ásia

• Avaliação REACH — por conteúdo químico específico, quando necessário.

Todas as certificações são tratadas como parte do programa ODM. O cliente recebe um produto totalmente certificado e pronto para ser comercializado.

8. Teste e Validação

8.1 Teste Funcional

A validação de veículos multimarcas é realizada em nossa frota de 50 veículos, atualizada trimestralmente para incluir novos anos-modelo. A frota abrange marcas americanas, europeias e asiáticas de 1996 até os dias atuais. Os testes de estabilidade da comunicação da ECU vão além da verificação do protocolo de comunicação — realizamos testes sob ruído elétrico ativo, durante a partida do motor e com outras cargas de alta corrente funcionando simultaneamente.

Os testes com veículo em circuito fechado (Vinyl-in-the-Loop) em um motor diesel em funcionamento, com um banco de carga de 30 kW e um injetor de ruído de centelhador, agora são obrigatórios antes da aprovação final de cada lote de produção. Nenhuma norma ISO exige isso. Nossos dados de retorno de campo nos levaram a adicioná-lo.

8.2 Teste Ambiental

• Teste de queda de 1.2 a 1.5 metros sobre concreto — altura realista de um peitoril de porta ou bancada de trabalho

• Ciclos de alta e baixa temperatura: -10 a 55 graus Celsius com verificação funcional em ambos os extremos

• Testes de vibração em uma mesa de seis eixos simulando o piso da oficina e o transporte de veículos

• Verificação da integridade do sinal do barramento CAN após vibração, com análise por osciloscópio — oscilações após estresse mecânico são uma falha que testes funcionais isolados não detectam.

8.3 Testes de Produção

O teste em circuito de cada placa verifica a presença dos componentes e a integridade das juntas de solda. O teste funcional do circuito verifica cada protocolo de comunicação, cada caminho de E/S e a regulação da fonte de alimentação em diferentes temperaturas. A calibração da interface OBD com um simulador de ECU de referência confirma o sincronismo do protocolo e os níveis de sinal antes da montagem final. Nenhuma unidade é enviada sem passar por todas as três etapas. Isso explica, em parte, por que nossa taxa de devolução em campo por falhas de comunicação é de apenas 0.3%.

9. Fabricação e Produção em Massa

9.1 Otimização DFM

O projeto para manufatura começa na revisão do esquema, não após o layout. Para cada circuito integrado crítico no projeto — transceptor, microcontrolador, gerenciamento de energia — documentamos um substituto qualificado antes da fabricação do produto. Problemas de disponibilidade de componentes inviabilizaram dois programas de ODM em 2021 e 2022 que não possuíam estratégias de substituição. A seleção de circuitos integrados com longo ciclo de vida evita a situação em que um produto entra em produção e o componente principal chega ao fim de sua vida útil em 18 meses.

9.2 SMT e Montagem

Linhas SMT automatizadas para toda a montagem de componentes de superfície — sem posicionamento manual nas placas de produção. Soldagem por onda para conectores de furo passante, quando necessário. A gravação final do firmware e a instalação do software fazem parte do fluxo da linha de produção, e não de uma etapa pós-montagem. Cada unidade recebe o firmware de produção, o banco de dados do veículo e os parâmetros de calibração como uma operação controlada e registrada. A capacidade de atualização OTA é verificada em cada unidade antes de sair da linha de produção.

9.3 Garantia de Qualidade

Inspeção funcional completa em cada unidade — sem amostragem. O teste de envelhecimento acelerado (burn-in) submete cada unidade a temperaturas elevadas por um período definido para detectar falhas prematuras antes do envio. A validação final da comunicação com o veículo conecta cada unidade a um simulador de ECU em funcionamento e verifica a leitura, a eliminação e os dados em tempo real dos códigos de falha (DTCs) em todos os protocolos suportados.

Nossa produção de 120,000 unidades, ao longo de 18 meses e em três linhas de fabricação ODM, manteve uma taxa de retorno por falha de comunicação de 0.3%. Esse número é o resultado desse processo.

10. Resultados do Projeto

10.1 Conquistas Técnicas

Comunicação estável com a ECU em mais de 95% dos modelos de veículos testados com diagnósticos avançados — não apenas com OBD-II genérico. Tempo de inicialização inferior a 10 segundos, desde a partida a frio até estar pronto para diagnóstico. Leitura confiável de dados CAN em alta velocidade a 500 kbps e 1 Mbps, sem perda de quadros, em conformidade com a especificação de imunidade a ruído ISO 11898.

A taxa de falhas de comunicação em devoluções em campo caiu de 4.2% para 0.3% após as alterações no layout da placa de circuito impresso, atualizações na proteção contra transientes e medidas de segurança de firmware introduzidas após a falha do Sprinter de 2023. Em 120,000 unidades, isso representa uma diferença entre 5,040 devoluções em garantia e 360.

10.2 Resultados de mercado

O scanner foi lançado na América do Norte e na Europa, posicionado como uma ferramenta de diagnóstico profissional de gama média a alta. A taxa de recompra dos distribuidores melhorou depois que o cliente adotou uma comunicação transparente sobre a cobertura — publicando a matriz de cobertura aprimorada pelo fabricante original em vez de uma declaração percentual genérica. A escalabilidade para expansão do diagnóstico de veículos elétricos está integrada à arquitetura de hardware, com footprints CAN FD e DoIP na placa de circuito impresso para a próxima revisão do produto.

11. Veículos Elétricos e Capacidade de Expansão Futura

11.1 Diagnóstico de Veículos Elétricos

"Preparado para veículos elétricos" é a expressão mais usada em diagnósticos automotivos atualmente. Mas o que isso realmente exige em termos de hardware?

O monitoramento de BMS em baterias com tensões entre 400 e 800 V exige conversores analógico-digitais (ADCs) de alta resolução e caminhos de medição isolados que um scanner padrão para motores de combustão interna não possui. O diagnóstico de sistemas de alta tensão — falhas de isolamento de alta tensão, detecção de soldagem de contatores, sinais de fuga térmica — utiliza PIDs, esquemas de acesso de segurança e modos de falha diferentes de qualquer procedimento padrão de diagnóstico para motores de combustão interna. As ECUs de veículos elétricos usam os mesmos comandos UDS que os motores de combustão interna, mas com estruturas de PID completamente diferentes. Sem o hardware da camada física compatível, o scanner não consegue estabelecer a conexão em muitas plataformas. Isso não é um problema de banco de dados, mas sim um problema de hardware.

• Monitoramento de tensão, temperatura e equilíbrio de células do BMS

• Detecção de falhas de isolamento de alta tensão e análise do estado do contator

• Diagnóstico do sistema de carregamento, incluindo o protocolo de comunicação EVSE

• Monitoramento de sinais de alerta precoce de fuga térmica

11.2 DoIP e Expansão OTA

O suporte completo a DoIP — ISO 13400 — requer uma camada física Ethernet (PHY), componentes magnéticos e uma pilha TCP/IP no microcontrolador (MCU). Isso adiciona de US$ 8 a US$ 12 à lista de materiais (BOM) antes de considerar o desenvolvimento do firmware. O suporte a CAN FD para comunicação de dados de 5 Mbps adiciona outros US$ 2 a US$ 3 por unidade. O custo incremental total da lista de materiais para passar de um scanner sólido apenas para veículos a combustão interna (ICE) para um hardware genuinamente pronto para veículos elétricos (EV) varia de 25% a 40% — o que se traduz em US$ 15 a US$ 25 por dispositivo.

Quando os clientes pedem para "adicionar diagnóstico de veículos elétricos", a conversa é direta: não se trata de uma simples opção de software. São seis meses de trabalho em um banco de dados específico para cada veículo, além de alterações de hardware que aumentam o custo unitário em US$ 15 a US$ 25. Se você estiver adquirindo um scanner compatível com veículos elétricos, solicite a lista de verificação de hardware DoIP e CAN FD e um relatório de validação assinado para pelo menos três plataformas de veículos elétricos antes de assinar o pedido de compra.

“Exija a lista de verificação de hardware DoIP e CAN FD, além de um relatório de validação assinado para pelo menos três plataformas de veículos elétricos. Não é uma promessa de marketing. É um documento assinado.”

12. Por que nos escolher para o desenvolvimento de dispositivos de diagnóstico automotivo?

Não priorizamos a lista mais extensa de recursos. Priorizamos os dados.

Nossa capacidade de projeto de PCBs vai além do layout EMC padrão, abrangendo a imunidade a transientes específica para veículos — validada em veículos em funcionamento com bancos de carga e injetores de ruído, e não apenas por simulação. A falha da Mercedes Sprinter em 2023 gerou um conjunto de regras de projeto que nenhuma norma ISO exige e que reduziu nossa taxa de retorno de falhas de comunicação de 4.2% para 0.3%. Esse conhecimento está presente em todos os projetos que produzimos atualmente.

A engenharia de hardware de nível automotivo significa componentes AEC-Q100, conformidade com as normas ISO 7637 e 16750 como ponto de partida e estratégias documentadas para componentes substitutos antes da finalização do projeto. A diferença entre um scanner que passa pela certificação e um que sobrevive a 200,000 ciclos de conexão em oficinas reais não é visível em uma ficha técnica.

O desenvolvimento de software embarcado abrange toda a pilha: firmware de protocolo, gerenciamento de banco de dados da ECU, infraestrutura de atualização OTA e integração com a nuvem. Consideramos a frequência de atualização do banco de dados como um entregável com um SLA — no máximo 45 dias entre o lançamento de um novo modelo e a validação da atualização do banco de dados.

O serviço OEM e ODM completo significa que o cliente recebe um produto finalizado, certificado e pronto para o mercado. As certificações CE, FCC e RoHS são tratadas dentro do programa. Produção em massa com inspeção funcional de 100%. Validação completa da comunicação com o veículo em cada unidade antes do envio.

E informamos aos clientes o que nossa ferramenta não faz. Limitações de bypass do gateway de segurança em certas plataformas de 2024 em diante. O fluxo de trabalho híbrido necessário para a programação da ECU nesses veículos. O custo real da preparação para veículos elétricos em termos de hardware. Essa transparência não é uma fraqueza no processo de vendas. Nossos dados de pedidos recorrentes mostram o contrário.

50+Frota de Validação de Veículos

45 diasSLA de atualização do modelo máximo do ano

0.3%Taxa de falhas nas comunicações de campo

100%Inspeção funcional por unidade

Todos os dados foram extraídos de registros internos de produção, logs de RMA e dados de validação em campo de mais de 200,000 unidades enviadas. As identidades de clientes e marcas são anonimizadas de acordo com os contratos de ODM.