Um computador veicular com barramento CAN faz mais do que simplesmente expor um par de terminais CAN. Ele precisa receber as mensagens corretas no momento certo, transmitir dados selecionados para um aplicativo, coexistir com dispositivos seriais e conexões sem fio, e permanecer confiável em todas as condições elétricas e ambientais do veículo.
Para os fabricantes de equipamentos originais (OEMs), a parte difícil começa após a seleção do tamanho da tela. As equipes de integração devem chegar a um consenso sobre a arquitetura do barramento, as definições de mensagens, a interface com o sistema operacional, o comportamento do serviço e os testes de aceitação. Este guia fornece um checklist prático para transformar um terminal CAN Bus em um subsistema de produção repetível.
Ilustração da integração do PDS. A fiação, os protocolos e o comportamento do software devem ser validados no veículo alvo.
Defina a arquitetura do computador do veículo no barramento CAN antes de escolher o hardware.
Uma rede CAN é um barramento diferencial compartilhado. Múltiplas unidades de controle eletrônico trocam quadros, e cada nó receptor decide se um quadro é relevante. A camada física, a taxa de bits, a terminação, a política de conectores e o protocolo de mensagens devem ser compatíveis com o projeto do veículo. A CSS Electronics oferece uma introdução útil ao barramento CAN para equipes que precisam de um vocabulário comum.
A primeira decisão do fabricante original (OEM) é definir as atribuições do computador do veículo via barramento CAN. Ele pode apenas monitorar dados, solicitar um conjunto limitado de ações, atuar como um gateway ou participar de uma rede privada. Essa função deve ser descrita no documento de controle da interface. Um terminal de monitoramento e um controlador com capacidade de comando exigem testes e atenção em cibersegurança distintos.
Identifique também todos os barramentos conectados ao terminal. Veículos comerciais geralmente separam as redes de transmissão, carroceria, implementos, diagnóstico e redes CAN privadas. Misturá-las sem uma estratégia de isolamento ou gateway pode gerar tráfego indesejado, comportamentos inesperados ou propagação de falhas.
| Camada de integração | Decisão de projeto | É necessário apresentar provas. |
|---|---|---|
| Físico | Taxa de bits, topologia, terminação, cabo, conector e isolamento | Desenho do chicote de fios, captura de dados com osciloscópio ou analisador e plano de EMC. |
| Protocolo | Formatos brutos CAN, J1939, CANopen, ISO-TP, UDS ou proprietários | Banco de dados de mensagens, identificadores, diagramas de tempo e de estado. |
| Sistema operacional | Driver, API, permissões, prioridade do processo e recuperação | Documentação do SDK, código de exemplo e resultados de injeção de falhas |
| Aplicativo | Decodificação, filtragem, registro, exibição e lógica de negócios | Testes de ponta a ponta com dados de veículos gravados |
| Vida útil | Controle de versão, atualizações, diagnósticos e serviço de campo. | Configuração básica, processo de lançamento e procedimento de recuperação |
Complete a lista de verificação do computador do veículo CAN Bus RS232 RS485.
Os projetos OEM frequentemente combinam CAN com equipamentos seriais legados. Uma lista de verificação para computadores veiculares com barramento CAN RS232 RS485 deve documentar cada interface separadamente e, em seguida, testar todo o caminho de dados.
Barramento CAN
Confirme o número de canais independentes, suporte a CAN FD, taxas de bits, método de terminação, isolamento, comportamento de ativação e pinagem do conector. Verifique se o terminal deve receber apenas quadros específicos ou também transmitir mensagens. Registre a carga do barramento e a latência no pior caso com o chicote completo do veículo.
RS232 e RS485
Para um computador veicular com RS232, especifique os níveis de tensão, a taxa de transmissão (baud rate), o controle de fluxo, o conector, o comprimento do cabo e o protocolo. O RS232 geralmente é ponto a ponto. O RS485 pode usar operação half-duplex ou full-duplex com múltiplos nós, portanto, os requisitos de terminação e polarização devem ser definidos. Não assuma que configurações de baud idênticas garantam a compatibilidade de protocolo.
Solicite um teste de loopback ou em nível de dispositivo antes da instalação no veículo. Em seguida, teste o tráfego simultâneo através da CAN, de ambos os canais seriais, da USB e da conexão sem fio. A carga compartilhada do processador e o tratamento de interrupções podem revelar problemas que não aparecem em demonstrações com uma única interface.
Ilustração de integração OEM do PDS. O comportamento da interface deve ser confirmado com a configuração do produto cotada.
Controle o banco de dados de mensagens e o modelo de dados.
O aplicativo não deve decodificar quadros hexadecimais brutos em todo o código-fonte. Defina um banco de dados de mensagens (DBC), mapeie valores e unidades físicas e gere uma camada de decodificação testada. Inclua taxas de atualização, comportamento de tempo limite, tratamento de valores inválidos, ordem de bytes, escalonamento e intervalos de sinal.
Versionarize o banco de dados com o software do veículo, não apenas com o aplicativo do terminal. Se uma ECU adicionar uma mensagem ou alterar um sinal, a equipe de integração precisa saber quais terminais, modelos de nuvem e casos de teste serão afetados. Armazene logs CAN representativos para que as alterações decodificadas possam ser reproduzidas sem um veículo.
Se o projeto usar SAE J1939 , documente os endereços de origem, os grupos de parâmetros, o comportamento das requisições e o tratamento de diagnóstico. Para CANopen ou um protocolo proprietário, forneça máquinas de estado e definições de erro equivalentes.
Selecione o sistema operacional e a API CAN.
Um computador veicular com barramento CAN executando Linux pode expor suas interfaces através do subsistema SocketCAN do kernel. A equipe de software pode usar operações de socket padrão, filtros e ferramentas de rede. Confirme a versão do kernel, o driver CAN, a configuração do buffer de recebimento e as permissões na imagem de distribuição, e não apenas em uma placa de desenvolvimento.
No Android, o fornecedor pode disponibilizar uma API em Java, Kotlin, nativa ou JNI. Pergunte como os aplicativos recebem frames, como o acesso de transmissão é controlado e o que acontece quando o serviço é reiniciado. O plano de integração deve incluir um mecanismo de monitoramento ou verificação de integridade que possa se recuperar de um processo interrompido, uma interface desconectada ou um estado de barramento passivo em caso de erro.
Os projetos OpenHarmony devem receber uma definição de interface igualmente específica. Evite aceitar uma afirmação genérica de que o CAN é suportado. O fabricante original (OEM) precisa da superfície real da API, de um projeto de exemplo, das permissões, do comportamento do ciclo de vida e da capacidade de depuração.
Adicione GNSS e 4G LTE sem comprometer a interface do veículo.
Um terminal GNSS veicular com barramento CAN pode combinar dados de posição, movimento e estado do veículo. Defina a precisão, a taxa de atualização, o formato de coordenadas, a fonte de tempo e o serviço de correção necessários. Teste o posicionamento da antena considerando o teto, a cabine, a carga e os equipamentos de rádio próximos. Mantenha a perda de sinal GNSS e o tempo limite do CAN como estados independentes, para que a indisponibilidade de uma fonte não invalide a outra.
Um computador veicular 4G LTE estende esses fluxos de dados para uma frota, mas o uplink não deve ser considerado sempre disponível. Especifique as bandas suportadas, os perfis de operadora, o comportamento em roaming, o isolamento da antena, os limites de dados e o tempo de reconexão. Utilize o armazenamento em buffer local para registros importantes e defina quais campos são enviados imediatamente, periodicamente ou somente após um evento.
Defina os limites de propriedade e acesso aos dados. Os proprietários de veículos podem precisar controlar a localização, os diagnósticos, os dados do condutor e os dados operacionais. O terminal e a plataforma em nuvem precisam de políticas claras de autenticação, autorização, retenção e comando remoto.
Proteja a energia, os sinais e o limite do software.
A alimentação do veículo inclui picos de tensão durante a partida, descarga de carga, partidas auxiliares e acionamento de acessórios. O computador do veículo com barramento CAN deve ser especificado com uma faixa de entrada, padrão de transientes, fusível, aterramento e comportamento de ignição para a classe de veículo em questão. As portas CAN e seriais também podem exigir isolamento ou proteção galvânica quando conectadas a equipamentos externos.
Considere a interface CAN como confiável somente após o fabricante do equipamento original (OEM) definir a confiança necessária. Restrinja os identificadores de transmissão, valide os comprimentos e intervalos recebidos, limite a taxa de comandos e impeça que um aplicativo acesse canais de barramento não relacionados. Registre as alterações de configuração relevantes para a segurança e ofereça suporte a atualizações de software assinadas ou verificadas.
O chicote de cabos deve permitir manutenção. Identifique os conectores, documente a pinagem, proteja as portas não utilizadas e especifique o torque quando necessário. Um terminal que passa no teste de bancada ainda pode falhar se um chicote pesado puxar um conector ou criar uma saliência que interfira no barramento.
Utilize uma matriz de aceitação para a versão de produção.
| Área de teste | Exemplo de critério de aceitação |
|---|---|
| Saúde do ônibus | Sem quadros de erro não intencionais durante as sequências normais de inicialização, ativação e desligamento. |
| Precisão dos dados | Os sinais decodificados correspondem às medições de referência em toda a faixa de operação. |
| Latência | Os dados críticos chegam ao aplicativo dentro do prazo estipulado pelo projeto. |
| Recuperação | Os serviços CAN, seriais, GNSS e celulares são recuperados após falhas em cabos, energia e rede. |
| Ciclos de energia | A configuração e os dados armazenados em buffer sobrevivem aos cenários de ignição e bateria exigidos. |
| Atualizar e reverter | Uma atualização com falha pode restaurar a unidade para uma versão funcional conhecida. |
Antes da produção, um computador veicular com barramento CAN deve passar por uma matriz aprovada de testes de barramento, latência, recuperação e atualização. A PDS oferece suporte à integração OEM/ODM para terminais veiculares robustos e pode alinhar as interfaces com o plano de software do projeto. O fabricante original (OEM) ainda deve ser o responsável pela especificação da interface em nível veicular e aprovar o plano de validação final.
Ilustração da validação do PDS. Os critérios de aceitação e os equipamentos de teste devem ser acordados antes da liberação para produção.
Perguntas frequentes
O que um computador veicular com barramento CAN precisa para receber dados do veículo?
É necessário um terminal com uma interface CAN física compatível, taxa de bits e terminação corretas, acesso ao barramento relevante, um banco de dados de mensagens e um software que decodifique os sinais necessários. O terminal também deve lidar com timeouts, valores inválidos e falhas no barramento.
Um computador de veículo pode usar CAN, RS232 e RS485 simultaneamente?
Muitos computadores veiculares robustos podem suportar essas interfaces simultaneamente, mas a quantidade exata de canais e o isolamento dependem do modelo. Teste todo o tráfego necessário ao mesmo tempo e confirme se o sistema operacional expõe cada interface de forma confiável.
J1939 é o mesmo que CAN Bus?
J1939 é um protocolo de camada superior usado em redes CAN, principalmente em veículos pesados. Um terminal pode suportar CAN fisicamente sem suportar as mensagens J1939 específicas ou o comportamento de diagnóstico exigido pelo projeto.
Os dados CAN devem ser processados no terminal ou na nuvem?
Use o terminal para filtragem, exibição, alertas e armazenamento em buffer sensíveis ao tempo. Envie registros resumidos ou orientados a eventos para a nuvem quando a disponibilidade da rede e a política de dados permitirem. A divisão deve seguir os requisitos de latência, privacidade, custo e disponibilidade offline.
Contate-nos
📧E-mail:[email protected]
📞Tel.: +86 13421822024
🌐Site: www.szpds.com
Isenção de responsabilidade
As informações contidas neste artigo são apenas para referência. A PDS Technology Co., Ltd. não se responsabiliza por erros, omissões ou inadequação do conteúdo para aplicações específicas. As especificações do produto estão sujeitas a alterações sem aviso prévio. Os compradores devem verificar todos os detalhes técnicos com nossa equipe antes do uso.
Sobre a PDS Technology
A PDS Technology é uma fabricante líder de OEM/ODM de terminais GNSS RTK de alta precisão e computadores veiculares, atendendo aos setores de agricultura, construção, mineração, táxi e logística desde 2011.
Com mais de 15 anos de experiência em P&D para o setor automotivo, oferecemos dispositivos robustos e multi-SO (Android/Linux/OpenHarmony) com posicionamento RTK de precisão centimétrica, proteção IP66 e desempenho preparado para IA. Nossas fábricas com certificação IATF16949 produziram mais de 100.000 unidades, distribuídas globalmente, e detêm mais de 30% do mercado chinês de terminais de direção autônoma para o setor agrícola. Exportamos para o Japão, EUA, Reino Unido, Turquia, Rússia e outros países.
