Um fornecedor de baterias não consegue conceber uma interface CAN fiável com base apenas numa fotografia do conector e em alguns quadros capturados. Este guia explica o pacote técnico exato que um fabricante de equipamento original (OEM) deve disponibilizar antes de se iniciar a integração do BMS numa bateria para empilhadores.
Isto falha logo no início.
Quando um fabricante de empilhadores (OEM) envia a um fornecedor de baterias apenas a tensão nominal, a capacidade, fotografias dos conectores e um pedido vago para “fazer com que o CAN funcione”, o projeto já passou de uma fase de engenharia controlada para uma fase dispendiosa de engenharia inversa, em que cada pressuposto em falta se traduz num novo atraso no protótipo, numa revisão do firmware ou numa avaria em campo.
Por que razão as empresas de equipamentos de ponta continuam a considerar os dados de comunicação como algo opcional?
A integração do CAN bus na bateria de uma empilhadeira não é uma simples questão de ligação elétrica. Trata-se de um acordo de interface entre o sistema de gestão da bateria, a unidade de controlo do veículo, o carregador, o painel de instrumentos, o inversor de tração, a unidade telemática e, por vezes, uma ECU de gateway.
O fornecedor precisa de mais do que o CAN-H e o CAN-L.
Tem de saber o que cada mensagem significa, quando deve ser apresentada, a quem pertence, o que acontece quando desaparece e qual o dispositivo com autoridade para interromper a carga ou desativar a tração.
A minha opinião direta é simples: Um fabricante de equipamento original (OEM) que não divulgue a definição da interface não pode, de forma razoável, responsabilizar o fornecedor da bateria pelo desempenho da integração.
O Norma ISO 11898-1 relativa à rede CAN define a camada de ligação de dados CAN e as regras de codificação física. Não define o significado do byte 3 numa empilhadora específica, nem se o estado de carga utiliza uma escala de 0,5%, nem se a mensagem 0x351 tem de chegar a cada 100 milissegundos.
Essa diferença é importante.
Um fornecedor pode ligar um analisador CAN e ver o tráfego imediatamente. Os quadros aparecem. Os contadores aumentam. Os dados alteram-se quando se carrega no acelerador ou quando o carregador é ligado.
Mas o tráfego não é o que importa.
Considere este quadro:
ID CAN: 0x351
DLC: 8
Dados: 64 0A 5E 10 00 03 7B 92
Ciclo: 100 ms
Sem uma definição de sinal aprovada, o fornecedor não sabe se:
As suposições podem resultar num painel de controlo funcional em laboratório. No entanto, não resultam numa bateria segura para produção.
A diferença entre uma demonstração CAN e um produto integrado reside na documentação.
O fornecedor precisa de um pacote técnico organizado. Não de dez cadeias de e-mails. Não de capturas de ecrã de uma ferramenta de assistência antiga. E, certamente, não de um ficheiro DBC em que metade dos sinais estão identificados como Reservado.
Eis o pacote mínimo de transferência que exigiria antes de aprovar a integração do BMS da bateria da empilhadeira.
| Entrega OEM | Conteúdo obrigatório | Por que razão o fornecedor precisa disso | Falha comum quando falta |
|---|---|---|---|
| Arquitetura de rede | Todas as ECUs ligadas, gateways, pontos terminais, segmentos de barramento, portas de diagnóstico e propriedade da rede | Mostra onde se encontra a bateria e quais os controladores que dependem dos seus dados | A bateria funciona numa bancada, mas deixa de funcionar atrás do portão do veículo |
| Especificação da camada física | CAN Classic ou CAN FD, identificadores de 11 ou 29 bits, 250/500 kbps ou outra taxa de transmissão, ponto de amostragem, terminação e circuitos de ativação | Permite uma comunicação elétrica estável | Eventos de desligamento do barramento, reflexões, falhas intermitentes no arranque |
| DBC, EDS ou base de dados equivalente | ID de mensagens, sinais, posições de bits, escala, deslocamentos, unidades, ordem dos bytes, valores válidos e velocidades de transmissão | Fornece o mapeamento das mensagens CAN da bateria da empilhadeira | SOC incorreto, corrente invertida, falsos alarmes de temperatura |
| Matriz de responsabilidade pelas mensagens | ECU transmissora, ECU recetora, tempo de ciclo previsto, tempo de espera e atraso de arranque para cada mensagem | Evita a duplicação de IDs e conflitos de temporização | Dois dispositivos transmitem o mesmo identificador ou os watchdogs expiram |
| Máquina de estados operacionais | Transições entre os modos de sono, ativo, espera, pré-carregamento, funcionamento, carregamento, avaria, manutenção e desligamento | Define o comportamento legal, em vez de sinais isolados | Os contactores abrem durante o percurso ou permanecem fechados durante uma avaria |
| Interface de carregamento | Identificadores dos carregadores, pedidos de tensão/corrente, lógica de ativação dos carregadores, redução da potência nominal, interrupção do carregamento e comportamento em caso de tempo limite | Coordena o BMS, o carregador e o camião | O carregador não arranca ou ignora o limite de corrente da bateria |
| Matriz de reação a falhas | Gravidade da falha, nível de aviso, resposta de binário, resposta do contactor, condições de recuperação e regras de bloqueio | Alinha o comportamento do camião com a proteção do BMS | Os avisos menores desativam a tração ou as falhas graves são ignoradas |
| Desenho da interface elétrica | Disposição dos pinos, modelo do conector, entrada de ignição, circuito de interbloqueio, alimentação auxiliar, blindagem e ligação à terra | Previne danos nas comunicações e no hardware | Linha de esteira invertida, desvio em relação ao solo, falha no bloqueio |
| Especificação de diagnóstico | Identificadores de diagnóstico, UDS ou serviços proprietários, formato DTC, direitos de acesso e método de atualização do firmware | Apoia os testes de produção e a assistência no terreno | Os revendedores não conseguem identificar avarias nem atualizar as baterias de substituição |
| Consultar registos CAN | Arranque a frio, condução normal, baixo nível de carga (SOC), carregamento, carga completa, falhas e registos de desligamento | Fornece ao fornecedor provas comportamentais comprovadas | Os erros na documentação permanecem ocultos até aos testes com camiões |
| Matriz de testes de aceitação | Condições de aprovação/reprovação, modelos abrangidos, limites ambientais e versões de software | Define quando a integração está concluída | Revisões intermináveis porque o termo “funcionar” nunca foi definido |
O DBC é importante.
No entanto, uma base de dados DBC descreve normalmente mensagens e sinais; raramente inclui a máquina de estados completa da bateria, a sequência dos contactores, o modelo de cibersegurança, as permissões de diagnóstico ou a resposta do veículo à perda de comunicação, pelo que o fabricante de equipamento original (OEM) deve também emitir um documento de controlo de interface e um plano de aceitação.
A equipa do CoreSpark Capacidades de engenharia de baterias OEM/ODM já abrangem a configuração personalizada do BMS, as opções de comunicação, a conceção dos conectores, a compatibilidade dos carregadores, o desenvolvimento de amostras e o apoio aos testes. Esse fluxo de trabalho só se torna eficiente quando o fabricante fornece dados de interface controlados desde o início, em vez de o fazer após a falha do primeiro protótipo.
Um ficheiro DBC do barramento CAN utilizável para os fornecedores de baterias deve definir todos os sinais que a bateria transmite ou recebe.
No mínimo, cada entrada de sinal necessita de:
A descrição da soma de verificação merece uma atenção especial. Não basta escrever “CRC-8”.
O fornecedor necessita do polinómio, do valor inicial, do valor XOR final, das regras de reflexão, do intervalo de bytes protegidos, das regras de inclusão de identificadores, da posição do contador de atividade e de um exemplo verificado de entrada-saída. O CRC-8/SAE-J1850 e o CRC-8/AUTOSAR são ambos cálculos de oito bits, mas não são intercambiáveis.
Um parâmetro em falta pode fazer perder dias.
E não, um registo CAN não é um substituto. Um registo pode confirmar o comportamento, mas raramente revela todos os valores reservados, condições de falha, tempos de espera, regras de escalonamento, sementes de soma de verificação ou variantes específicas do modelo.
O fabricante de equipamento original (OEM) deve identificar o protocolo de camada superior efetivo.
Um sistema CAN proprietário necessita normalmente de um ficheiro DBC e de um documento de controlo de interface. Uma implementação CANopen pode exigir um ficheiro EDS ou DCF, um dicionário de objetos, um mapeamento de PDO, um comportamento SDO, estados NMT, intervalos de heartbeat, regras de identificação de nós e definições de mensagens de emergência.
O Perfil do dispositivo CiA 418 foi criado especificamente para apoiar a interoperabilidade entre módulos de bateria CANopen e carregadores, incluindo carregadores implementados de acordo com a norma CiA 419. Trata-se de uma orientação útil, mas a menção “compatível com CANopen” continua a não indicar a um fornecedor quais os objetos opcionais, mapeamentos, IDs de nó ou regras de temporização que a empilhadeira utiliza efetivamente.
Um camião baseado na norma J1939 necessita do seu próprio conjunto de parâmetros: PGNs, SPNs, endereços de origem, comportamento de reivindicação de endereços, PGNs proprietários, taxas de repetição, requisitos do protocolo de transporte e regras de gestão da rede.
“Utiliza CAN” não nos diz praticamente nada.
A maioria dos problemas de integração não ocorre enquanto o camião circula normalmente. Ocorrem durante as transições.
Ativação. Pré-carregamento. Ligação do carregador. Atraso após desligar a chave. Paragem de emergência. Desligamento por baixa tensão. Recuperação da comunicação.
O fabricante de equipamento original (OEM) deve documentar cada transição como uma sequência, e não como uma lista dispersa de sinais.
Uma sequência de arranque simplificada poderia ser a seguinte:
Agora, faz as perguntas incómodas.
E se o pedido do veículo chegar antes de o BMS ter concluído o autoteste? Quanto tempo pode durar a pré-carga? O BMS tem de receber três quadros válidos antes de fechar os contactores? Que percentagem do circuito de ligação CC é considerada como pré-carga concluída: 85%, 90% ou 95%? O que acontece se o sinal de vida do veículo desaparecer durante 500 milissegundos enquanto o camião estiver em movimento?
As respostas não podem provir da imaginação do fornecedor de baterias.
Para cada estado de funcionamento, o fabricante original deve definir:
A mesma disciplina aplica-se ao sono.
Alguns camiões cortam imediatamente a alimentação da ignição. Outros esperam que a bateria permaneça ativa durante 10, 30 ou 120 segundos, para que o veículo possa registar dados de funcionamento, transmitir mensagens finais ou concluir o envio de dados telemáticos.
Uma bateria que entra em modo de suspensão demasiado cedo pode parecer defeituosa, mesmo que o seu sistema de proteção funcione na perfeição.
Muitas equipas debatem a questão do camião e da bateria, considerando o carregador como um acessório.
Isso é um erro.
Num sistema integrado de empilhadores a lítio, o carregador poderá ter de receber:
A bateria também pode necessitar de informações sobre a tensão de saída do carregador, a corrente disponível, o estado do carregador, os códigos de avaria e o estado do conector.
Nessa altura, o camião pode ficar estacionado sobre ambos os dispositivos e decidir se o carregamento é permitido com base no estado do travão de estacionamento, na posição da chave, no estado do sistema de bloqueio, na presença do operador, na deteção do conector ou nas regras de funcionamento do armazém.
Quem é o responsável?
O fabricante original deve responder a essa questão por escrito.
A equipa do CoreSpark soluções de baterias para empilhadores abrangem a conceção da área de carregamento, o carregamento de oportunidade, o dimensionamento com base nos turnos, a segurança e o planeamento da conversão. Estes temas estão diretamente ligados à integração CAN, uma vez que um protocolo correto para baterias de lítio de empilhadores deve suportar a estratégia de carregamento efetiva, e não se limitar a indicar o SOC num ecrã.
Um empilhador comercializado como “empilhador de 48 V” pode utilizar uma bateria de lítio com uma arquitetura LFP de tensão nominal de 51,2 V. Uma configuração típica de LiFePO₄ em série de 16 células utiliza células com uma tensão nominal de aproximadamente 3,2 V, mas o controlador do empilhador tem em conta toda a janela de funcionamento, e não a indicação na etiqueta de venda.
O fabricante de equipamento original (OEM) deve fornecer:
O fornecedor cruza, em seguida, esses limites com a composição química das células, o número de séries, os limiares de proteção do BMS e as definições do carregador.
Corresponder à expressão “48 V” não é engenharia.
Uma matriz de falhas deve associar cada condição da bateria a uma resposta explícita do veículo.
Por exemplo:
| Incidente com a bateria | Funcionamento da bateria | Previsão de tráfego de camiões | Regra de recuperação |
|---|---|---|---|
| Aviso do SOC | Transmitir o estado de aviso | Mostrar aviso; manter a tração | Ultrapassa o limiar SOC do fabricante de equipamento original |
| Limite baixo de SOC | Reduzir o limite da corrente de descarga | Reduzir o binário gradualmente | Desaparece após o carregamento |
| Sobretemperatura celular | Corrente de redução | Limitar a tração e a regeneração | Desativa-se após serem atingidos os limites de temperatura e de histerese |
| Sobretemperatura grave | Desligue os contactores quando for seguro fazê-lo | Introduzir paragem controlada | É necessária uma manutenção ou uma reinicialização definida |
| Tempo limite da rede CAN enquanto o veículo está estacionado | Manter ou abrir os contactores de acordo com a lógica de estado | Exibir falha de comunicação | Recuperação após uma sequência de quadros válidos |
| Tempo limite da CAN durante o deslocamento | Aplicar o período de funcionamento em caso de falha acordado | Reduzir o binário ou parar em segurança | Procedimento de reinício definido pelo fabricante (OEM) |
| Falha de isolamento | Bloquear a unidade ou a cobrança | Mostrar códigos DTC de gravidade elevada | É necessária uma inspeção realizada por pessoal qualificado |
| Detecção de contactores soldados | Impedir o reinício normal | Desativar falha do camião e do registo | Apenas reinicialização do serviço |
“Enviar um bit de falha” não é uma estratégia de gestão de falhas.
O fabricante do equipamento original (OEM) deve definir o que o veículo faz após o receber. O fornecedor deve definir o que o BMS faz caso o veículo o ignore.
Esse segundo caso é frequentemente evitado nas reuniões, porque levanta questões sobre a autoridade. No entanto, continua a ser necessário dar-lhe resposta.
O relatório da OSHA sobre lesões graves de 2024 registou 5 186 lesões graves envolvendo empilhadores entre 2015 e 2024, ou aproximadamente nove ferimentos graves por semana entre os empregadores abrangidos pelo conjunto de dados federal. O relatório alerta ainda que o conjunto de dados abrange apenas uma parte da força de trabalho dos EUA, pelo que não deve ser considerado como um recenseamento nacional completo. Leia o Relatório sobre Lesões Graves de 2024 da OSHA.
Nem todos esses acidentes estiveram relacionados com baterias ou falhas de comunicação. Mas não é essa a questão.
A questão é que as empilhadoras operam na proximidade de peões, estantes, docas de carga, cargas suspensas e corredores estreitos. Uma interrupção inexplicável da tração, um cálculo incorreto do nível de carga (SOC), um limite de recuperação desativado ou a abertura de um contactor não constituem apenas uma má experiência para o utilizador.
Pode comprometer a segurança da operação.
A formulação regulamentar é também direta. Nos termos de OSHA 29 CFR 1910.178(a)(4), as modificações que afetem a capacidade ou o funcionamento seguro de um veículo industrial motorizado requerem aprovação prévia por escrito do fabricante, bem como as atualizações correspondentes nas placas, etiquetas ou autocolantes.
É por isso que qualquer programa de conversão de lítio deve começar com o lista de controlo da conversão de empilhadores de chumbo-ácido em empilhadores de lítio e o processo de aprovação por escrito do fabricante de equipamento original (OEM). A integração do CAN não dispensa a análise de questões mecânicas relacionadas com o peso da bateria, a sua fixação, as dimensões do compartimento, o lastro, os conectores e a capacidade nominal.
O regras relativas ao peso e ao contrapeso das baterias de empilhadores são especialmente relevantes neste contexto. Uma interface CAN tecnicamente perfeita não consegue corrigir um conjunto de baterias de substituição que viole o intervalo de peso de bateria aprovado para o camião.
As baterias ligadas são unidades de controlo eletrónico (ECU) controladas por software.
Trata-os assim.
A bateria pode disponibilizar funções de diagnóstico CAN, Bluetooth, RS485, USB, software de manutenção, dados telemáticos ou atualização de firmware. Cada interface altera o modelo de risco.
O Orientações da NHTSA sobre cibersegurança dos veículos recomenda comunicar normas claras de cibersegurança aos fornecedores, manter registos dos componentes e versões do software, testar os produtos, documentar as decisões de conceção, proteger o acesso para fins de diagnóstico, autenticar as mensagens relacionadas com a segurança sempre que possível e utilizar a segmentação ou filtragem da rede. Embora o documento se destine a veículos rodoviários, a lógica de engenharia aplica-se diretamente a equipamentos industriais ligados à rede CAN.
Existe um precedente concreto para levarmos isto a sério.
Em julho de 2015, a Fiat Chrysler procedeu a uma recolha de aproximadamente 1,4 milhões de veículos norte-americanos depois de os investigadores terem demonstrado que era possível aceder remotamente aos controlos dos veículos ligados em rede através do sistema Uconnect. A Reuters noticiou que os investigadores conseguiam emitir comandos que afetavam o motor, a direção e os travões.
Uma bateria de empilhador não é um Jeep Cherokee. Mas as redes CAN partilham uma característica preocupante: assim que uma interface não fiável acede a um barramento de controlo mal segmentado, um pequeno elemento de comunicação pode tornar-se uma via de acesso a funções relacionadas com a segurança.
Por conseguinte, o fabricante de equipamento original (OEM) tem de definir:
A segurança baseada na obscuridade dos conectores não é segurança.
Existem casos legítimos em que um fabricante de equipamento original (OEM) mais antigo não consegue fornecer documentação completa. O fornecedor original do controlador pode já não existir. O DBC pode estar incompleto. A plataforma do camião pode ter acumulado quinze anos de alterações de firmware não documentadas.
A engenharia inversa pode ajudar.
No entanto, deve ser tratado como um projeto de engenharia controlado, com as suas limitações, e não como uma alternativa barata à cooperação com os fabricantes de equipamento original.
Um programa de engenharia inversa adequado pode exigir:
Mesmo assim, algumas condições podem nunca surgir nos dados recolhidos. Uma falha grave no isolamento, um evento de contactor soldado, uma avaria no sensor de temperatura das células, uma recuperação do bootloader ou um erro raro do carregador podem não ocorrer durante a observação normal.
O silêncio não é prova.
A melhor abordagem consiste em utilizar registos CAN para verificar a especificação escrita. Quando o registo e o documento apresentam discrepâncias, o fabricante original (OEM) deve resolver a discrepância e emitir uma definição revista, sujeita a controlo de versões.
Um programa sério de integração de baterias OEM requer uma matriz de aceitação assinada.
Os testes devem abranger mais do que “a arranque e a condução do camião”.”
Verificar:
Teste:
Desligar ou simular:
Em seguida, verifique se a bateria, o camião, o carregador e o ecrã respondem todos de acordo com a mesma matriz de avarias.
Não se deve pedir a um fornecedor que descubra o critério de aceitação durante o ensaio final do veículo. Isso é uma aquisição por surpresa.
A equipa do CoreSpark Estudos de caso e processo de validação do projeto da bateria LiFePO₄ Salientar a importância da revisão de amostras antes da produção em série, incluindo tensão, capacidade, dimensões do conjunto de baterias, configuração do BMS, método de carregamento e requisitos dos conectores. No caso de projetos de empilhadores com integração CAN, essa mesma fase deve incluir a verificação da conformidade com o protocolo e testes de falhas ao nível do veículo antes de o firmware de produção ser finalizado.
Os fabricantes de equipamento original (OEM) resistem frequentemente à divulgação de uma base de dados CAN completa, uma vez que esta contém sinais proprietários não relacionados com a bateria.
Essa preocupação é razoável. A resposta habitual, porém, não o é.
O fabricante de equipamento original (OEM) não tem de disponibilizar todos os sinais de direção, hidráulicos, de tração ou telemáticos. Deve disponibilizar informação suficiente para que o fornecedor da bateria possa implementar e verificar a interface que lhe foi atribuída de forma segura.
Existem três modelos viáveis:
O fabricante original fornece uma base de dados filtrada que contém as mensagens relativas à bateria, ao carregador, ao gateway e às mensagens de diagnóstico necessárias. Os sinais não relacionados são removidos ou renomeados.
O fabricante original (OEM) fornece um documento controlado que define apenas os sinais, as sequências, os tempos, as avarias e os serviços de diagnóstico exigidos pela bateria.
O fabricante de equipamento original (OEM) mantém o protocolo do veículo privado atrás de um gateway e fornece ao fornecedor da bateria uma interface estável e documentada. Isto permite, muitas vezes, a separação mais clara a longo prazo, desde que o tempo de espera e o comportamento em caso de falha do gateway estejam totalmente especificados.
Um acordo de confidencialidade (NDA) pode proteger informações confidenciais.
Não pode substituir a informação técnica.
Suspenderia o trabalho de engenharia sempre que um fabricante de equipamento original (OEM) dissesse alguma das seguintes coisas:
Esta última afirmação é especialmente perigosa. Pode significar que o fornecedor anterior recebeu melhor documentação, incorporou uma solução alternativa não documentada ou assumiu um risco de integração que nunca foi formalmente avaliado.
O silêncio no passado não é prova de que a interface seja adequada.
A integração do CAN bus na bateria de empilhadores consiste no processo de engenharia que permite que o sistema de gestão da bateria, o controlador do empilhador, o carregador, o ecrã e as ferramentas de diagnóstico troquem mensagens definidas, sigam o mesmo estado de funcionamento e reajam de forma segura a limites, falhas, comandos de ativação, pedidos de carregamento e perda de comunicação.
O trabalho inclui a configuração da camada física, o mapeamento de sinais, a sincronização das mensagens, a lógica dos contactores, o controlo de carregamento, os diagnósticos, a gestão de software e a validação ao nível do veículo. Só se considera concluído quando tanto o funcionamento normal como o comportamento em caso de falha cumprirem os critérios de aceitação estabelecidos por escrito.
Um ficheiro DBC do barramento CAN é uma base de dados legível por computador que define todos os quadros e sinais CAN que o fornecedor deve implementar, incluindo identificadores de mensagens, posições de bytes, comprimentos de bits, ordem dos bytes, escala, deslocamentos, unidades, velocidades de transmissão, regras de multiplexação, intervalos válidos e, por vezes, tabelas de valores ou campos de soma de verificação.
O DBC é apenas uma parte da interface. Deverá existir uma especificação separada que defina as transições de estado, a coordenação do carregador, as reações a falhas, o comportamento em caso de tempo limite, os diagnósticos, os controlos de cibersegurança e os testes de aceitação.
O fabricante de equipamento original (OEM) deve fornecer ao fornecedor da bateria o contrato de interface completo: disposição dos pinos elétricos, configurações da camada física, DBC ou mapa de sinais equivalente, propriedade da rede, temporização das mensagens, transições de estado, protocolo de carregamento, reações a falhas, acesso a diagnóstico, regras relativas à versão do software, sequências de teste e critérios de aceitação por escrito para o modelo de empilhador em questão.
O fabricante de equipamento original (OEM) deve também identificar todos os modelos abrangidos, a versão do controlador, a versão do carregador e a variante regional. Um protocolo validado num camião de 48 V não deve ser automaticamente aplicado a toda a família de produtos.
Uma bateria de empilhador só pode funcionar sem comunicação CAN quando o empilhador e o carregador foram concebidos para aceitar uma bateria autónoma cujo BMS controla os contactores e as proteções de forma independente; em muitos empilhadores modernos, a ausência de mensagens CAN desencadeia bloqueios, o modo de emergência, a recusa de carregamento, códigos de aviso ou a perda total de tração.
Mesmo uma bateria autónoma tem de estar em conformidade com a gama de tensão do veículo, a procura de corrente, o conector, os requisitos relativos ao peso da bateria, o sistema de carregamento e os controlos de segurança. “Não requer CAN” não significa “compatível sem adaptações”.”
A melhor prática de integração CAN para baterias de empilhadores consiste em definir uma especificação de interface sujeita a controlo de versões, validá-la com registos CAN reais e num sistema «hardware-in-the-loop» ou num banco de ensaio de empilhadores, simular falhas de tempo de espera e de sensores, confirmar o comportamento do carregador e assinar uma matriz de aceitação antes de o fornecedor lançar o firmware de produção.
O fabricante de equipamento original (OEM) e o fornecedor devem também garantir a rastreabilidade da versão do protocolo, analisar todas as alterações ao firmware, controlar o acesso aos diagnósticos e conservar os registos dos testes relativos a cada combinação aprovada de empilhador, bateria e carregador.
A documentação UN 38.3 não constitui um requisito do protocolo CAN; trata-se de uma prova de conformidade para efeitos de transporte, que demonstra que o projeto de uma célula ou bateria de lítio foi aprovado nos ensaios aplicáveis previstos na Parte III, Subsecção 38.3 do Manual de Ensaios e Critérios da ONU, antes de ser apresentado para transporte.
O Administração de Segurança de Oleodutos e Materiais Perigosos dos EUA estabelece que os fabricantes e os distribuidores subsequentes devem disponibilizar resumos dos ensaios das baterias de lítio, em conformidade com as regras aplicáveis. A validação do protocolo e a documentação de transporte devem ser incluídas no pacote de lançamento do projeto, mas têm finalidades diferentes.
Não inicie um projeto de integração do CAN bus numa bateria de empilhador baseando-se apenas na tensão, nos ampères-hora e numa fotografia do conector.
Prepare a arquitetura de rede, o ficheiro DBC ou EDS, a matriz de propriedade das mensagens, a máquina de estados operacionais, o protocolo de comunicação para carregamento, a tabela de respostas a falhas, a disposição dos pinos, os traçados CAN de referência, a lista de versões de software e os critérios de aceitação. Identifique os modelos exatos de camiões e carregadores envolvidos.
Em seguida, envie o pacote para análise técnica.
Um fornecedor de baterias qualificado pode proteger ficheiros confidenciais ao abrigo de um acordo de confidencialidade (NDA), assinalar informações em falta, propor um sistema de gestão da bateria (BMS) e uma arquitetura de comunicação, construir um protótipo controlado e validar o resultado em relação ao veículo real.
Mas o fornecedor não pode criar informações que o fabricante de equipamento original nunca tenha divulgado.
Partilhe com a CoreSpark Battery o modelo da sua empilhadeira, a tensão e a capacidade da bateria, o protocolo CAN, os detalhes do carregador, o esquema do conector e a quantidade pretendida, para dar início a uma análise documentada da integração OEM — e não a mais uma aposta arriscada de engenharia reversa.
