TPMS de autocarro no CAN do veículo

Porque um projeto de autocarro é um projeto de integração

Um carroçador não quer outro ecrã na cabina. Já tem um controlador de carroçaria, um painel e uma porta de

diagnóstico. O que quer do TPMS é: **quatro ou seis números e um bit de alarme, no barramento existente,

legíveis pelo controlador existente.**

Assim, a unidade de entrega não é "um kit", mas:

Autocarros de 4 e 6 rodas são trabalhos diferentes

Num autocarro de 4 rodas (dois eixos, pneu simples) o mapa é trivial: 11 / 12 / 21 / 22. Um recetor,

quatro sensores, sem repetidor na maioria dos casos.

Num autocarro de 6 rodas há habitualmente um eixo de arrasto ou empurrador. Na prática aparecem duas

configurações:

• 6 pneus simples → seis posições, um sensor cada.
• Par geminado traseiro → seis posições, e o pneu interior precisa do seu próprio sensor, o detalhe

que surge tarde no projeto.

Assim é o emparelhamento num autocarro real — eixo dianteiro, traseiro e de arrasto, com uma ferramenta

de mão:

• Emparelhamento TPMS de autocarro — 4 rodas, uma ferramenta de mão
• Emparelhamento TPMS de autocarro de 6 rodas — eixos dianteiro, traseiro e de arrasto

Esses dois clips são a parte aborrecida que decide se o projeto termina a tempo: cada sensor é identificado

com uma posição e o registo coincide com o desenho.

O que acordar com o carroçador antes da primeira unidade

1. Que nó é mestre. O nosso recetor é escravo Modbus RTU em RS485, ou um nó CAN: em ambos os casos o

controlador do veículo interroga-nos. Não interrogamos o veículo.

2. O conjunto de mensagens. CAN 2.0B, 11 bits ou 29 bits estendidos. **Já implementámos conjuntos de

mensagens em formato J1939 em integrações de máquinas de construção com grandes OEMs**; num programa de

autocarro mapeamos para o DBC ou lista de parâmetros do carroçador. Não afirmamos certificação J1939.

3. O que significa o alarme. Limiar de baixa pressão, limiar de alta temperatura, tempo de espera de

sensor ausente: três números a acordar, não a deixar num menu de fábrica.

4. Onde vai fisicamente o recetor. Não atrás do painel por omissão. Baixo no chassi, desobstruído, perto

dos eixos: caso contrário as últimas rodas de um autocarro de 6 são as que sofrem.

5. De quem é o mapa de rodas. Deve ser um documento no processo do veículo, não uma foto no telemóvel de

alguém.

Realidade da interface: uma por recetor

Um recetor é fabricado com uma interface: CAN 2.0B, RS485 (escravo Modbus RTU), RS232/UART, PROFINET via

gateway, ou USB-UART. Se um projeto precisa de CAN e RS232 ao mesmo tempo, são dois recetores ou uma

construção específica: vale fechar isso na fase de RFQ e não descobrir na bancada de integração.

O que o carroçador ganha e um ecrã não dá

• Um nó e um conjunto de mensagens para validar, em vez de outro ecrã para montar e alimentar.
• Pressão, temperatura, ID de sensor e estado de cada roda, no mesmo barramento que a ferramenta de

diagnóstico já lê.

• Um registo que pode entregar ao operador quando um pneu é questionado.

Perguntas frequentes

O autocarro pode manter o painel atual? Sim. Os dados vão para o barramento; onde mostrá-los (ecrã

existente, página nova ou só diagnóstico) é decisão do carroçador.

Também fornecem o display? Podemos fornecer displays de 7", matriciais e de segmentos, mas um programa de

autocarro normalmente não precisa. A peça que importa é o recetor.

J1939 é suportado? Suportamos tramas estendidas de 29 bits e já implementámos conjuntos em formato J1939,

mapeados ao vosso DBC. Não afirmamos certificação de conformidade J1939.

Quantas rodas admite um recetor? Até 256 posições, muito acima de um autocarro: é essa a ideia, a mesma

referência serve um autocarro, uma frota de camiões e um transportador de vigas de 160 rodas.

Podemos testar antes de o veículo ser construído? Sim: integração em bancada com o vosso controlador e o

nosso recetor, com o conjunto de mensagens que enviaríamos. É o sítio mais barato para encontrar um erro de

mapeamento.

← Todos os artigos