CAN, RS485 e CANopen: De que comunicação uma bateria de robô precisa?

UM bateria de robô precisa de uma interface e protocolo de comunicação que correspondam ao controlador do robô, ao carregador, aos requisitos de dados do BMS e à arquitetura de rede. CAN funciona bem para comunicação baseada em prioridade em vários nós. RS485 fornece uma interface serial diferencial robusta e geralmente é combinada com um protocolo de aplicação como Modbus RTU. CANopen adiciona uma estrutura de comunicação padronizada de camada superior ao CAN.

Não existe um método de comunicação único que todo AGV ou AMR deva usar. Para confiável bateria de robô comunicação, a compatibilidade deve se estender além do conector. A interface elétrica, a taxa de bits ou baud, a estrutura da mensagem, o mapeamento de dados, o endereçamento, o tempo, o comportamento da falha e a lógica de carregamento devem corresponder ao sistema host.

O que uma bateria de robô precisa para se comunicar?

UM bateria de robô se comunica porque o robô precisa de mais do que energia elétrica. Seu sistema de gerenciamento de bateria deve disponibilizar condições selecionadas de bateria e limites operacionais para equipamentos como controlador de veículo, carregador, base de carregamento, computador de diagnóstico ou gateway de gerenciamento de frota.

Dados da bateria que o robô precisa

Um BMS de bateria AMR mede ou calcula diversas categorias de informações. O controlador pode não precisar continuamente de todos os valores internos da célula, mas deve receber os dados necessários para operação, carregamento, diagnóstico e manutenção.

Categoria de dados	Informações típicas	Como o robô usa it
Estado elétrico	Tensão do pacote, corrente, capacidade restante	Monitora a condição atual da bateria
Status térmico e celular	Tensão da célula, temperatura da embalagem, temperatura da célula	Suporta proteção e decisões operacionais
Estimativas de bateria	SOC, SOH	Suporta tempo de execução e planejamento de manutenção
Limites operacionais	Corrente de carga, corrente de descarga, tensão de carga	Ajuda a manter a operação dentro dos limites do BMS
Dados de falha e aviso	Sobretensão, subtensão, sobretemperatura, sobrecorrente	Suporta resposta controlada a falhas
Estado do sistema	Carregando, descarregando, espera, estado de proteção	Coordena o comportamento do robô
Identificação	Endereço do dispositivo, versão do protocolo, identidade da bateria	Suporta reconhecimento e serviço

Isso também é consistente com o design moderno de BMS de robótica móvel. As plataformas de referência BMS orientadas para robótica da NXP combinam medição de tensão de células e conjuntos, detecção de corrente, detecção de temperatura e conectividade CAN dentro da mesma arquitetura de gerenciamento de bateria.

A especificação de comunicação para uma bateria de robô deve, portanto, começar com os dados que o robô precisa, e não com um conector ou nome de barramento preferencial.

SOC, SOH e relatórios de falhas

O SOC fornece ao robô uma estimativa da carga restante, enquanto o SOH representa a condição da bateria a longo prazo. Ambos são valiosos, mas nenhum deles deve ser tratado como um requisito completo de comunicação.

UM bateria de robô também pode relatar temperaturas, corrente, estados de alerta, condições de proteção e limites permitidos de carga ou descarga. Quando as condições de operação mudam, esses valores fornecem ao controlador do veículo informações que ele pode usar antes que o BMS atinja um estado de proteção total.

Isso torna a comunicação da bateria do robô útil tanto para operação quanto para manutenção imediata. O software de frota pode usar informações consistentes de status e falhas para distinguir uma condição de baixa energia de um evento térmico, evento de proteção ou falha de comunicação.

Apertos de mão do controlador e do carregador

O controlador e o carregador do veículo não requerem necessariamente dados idênticos da bateria. Durante o movimento, o controlador pode priorizar SOC, tensão, corrente, temperatura, avisos e limites de descarga. Durante o carregamento, o sistema também pode precisar de permissão de carregamento, limites de corrente de carga, limites de tensão, status de temperatura e informações sobre o estado de carga.

É por isso que especificar uma bateria CAN BMS ou uma bateria RS485 BMS é apenas o primeiro passo. Dois dispositivos podem compartilhar a mesma interface elétrica, mas usar identificadores, registros, fatores de escala, intervalos de atualização ou lógica de controle diferentes.

O carregamento automático torna a distinção particularmente importante. Quando um AGV ou AMR atraca sem intervenção do operador, a bateria, o carregador e o controlador do robô precisam de um comportamento definido para autorização de carregamento, limites operacionais, tratamento de falhas, conclusão de carga e retorno ao serviço.

Por que a comunicação afeta o tempo de atividade

A comunicação útil da bateria permite que o robô responda às condições da bateria antes que um desligamento forçado se torne a única resposta disponível. Um SOC baixo pode iniciar uma tarefa de carregamento, uma condição de temperatura pode afetar o comportamento de carregamento e uma falha relatada pode colocar o veículo em um estado de serviço definido.

Para frotas, dados consistentes da bateria do robô também melhoram a solução de problemas. As equipes de manutenção podem revisar os estados operacionais e alarmes em vez de tratar cada perda de propulsão ou interrupção de carga como o mesmo problema.

O benefício não é simplesmente mais telemetria. O valor real vem de tornar a bateria uma parte integrada e interpretável da arquitetura de controle do robô.

CAN vs. RS485: Como eles diferem em sistemas robóticos

CAN e RS485 são comuns em sistemas industriais, mas resolvem diferentes partes do problema de comunicação. CAN fornece mecanismos de enquadramento de mensagens, arbitragem, confirmação e gerenciamento de erros para um barramento compartilhado. RS485 define principalmente a sinalização elétrica usada para comunicação serial.

Essa distinção é importante quando os engenheiros selecionam uma arquitetura de comunicação para uma bateria de robô.

CAN como uma rede

CAN foi projetado para vários dispositivos se comunicando em um barramento compartilhado. As mensagens são identificadas por identificadores CAN e as tentativas de transmissão simultânea são resolvidas através de arbitragem baseada em prioridade.

Para a comunicação da bateria do robô, esta arquitetura pode suportar mensagens regulares de status, limites operacionais, informações de aviso e relatórios de falhas orientados por eventos. O atual projeto de referência BMS de robótica móvel MR-BMS771 da NXP inclui dois barramentos CAN, fornecendo um exemplo prático de CAN sendo integrado diretamente em uma plataforma robótica de gerenciamento de bateria.

Uma porta CAN por si só, entretanto, não define o significado dos dados. Um BMS de bateria CAN e um controlador de robô ainda precisam de taxas de bits, identificadores, definições de carga útil, escala, tempo de transmissão e lógica de aplicação compatíveis.

RS485 como interface física

RS485 é uma interface serial diferencial amplamente utilizada em comunicação multiponto industrial. É particularmente útil onde o equipamento já utiliza redes seriais ou onde um controlador se comunica com vários dispositivos endereçados.

Para uma bateria de robô, o ponto crítico é que o RS485 sozinho não informa ao controlador o que significa qualquer byte. Um BMS de bateria RS485 ainda precisa de um protocolo de aplicação definido ou de uma estrutura de dados proprietária.

Esta distinção explica porque RS485 e Modbus RTU frequentemente aparecem juntos sem serem sinônimos. A Organização Modbus documenta implementações de linha serial Modbus usando EIA/TIA-485, enquanto o próprio Modbus define o comportamento de mensagens de nível superior.

Uma especificação de compra deve, portanto, dizer mais do que “RS485 necessário”. Deve identificar o protocolo real e o mapa de dados esperado pelo robô.

Arbitragem CAN e tratamento de erros

CAN permite que os nós transmitam sem esperar que um controlador central atribua todas as oportunidades de transmissão. Se dois nós começarem a transmitir ao mesmo tempo, a arbitragem baseada nos identificadores de mensagens determinará qual quadro continuará.

CAN também inclui mecanismos para detectar erros de transmissão e gerenciar nós que geram erros repetidamente. Estas características tornam-no adequado para redes onde o bateria de robô deve trocar dados operacionais frequentes com outros controladores.

A decisão de engenharia não deve ser reduzida a uma afirmação genérica de que o CAN é simplesmente “mais rápido”. O que importa é se as mensagens de bateria necessárias podem ser entregues com a prioridade necessária e atualizar o tempo sob a carga esperada do barramento.

Para um robô móvel, um pequeno conjunto de mensagens de bateria corretamente priorizadas e documentadas costuma ser mais valioso do que uma taxa de dados teoricamente alta com comportamento de aplicativo mal definido.

Modbus RTU sobre RS485

O Modbus RTU fornece uma estrutura de mensagens em nível de aplicativo que pode operar em um link serial RS485. O protocolo define como os dispositivos endereçados trocam solicitações e respostas, enquanto o mapa de registro específico do equipamento identifica onde os valores individuais são armazenados.

Para uma bateria de robô, um mapa Modbus RTU pode conter registros de tensão do pacote, corrente, SOC, temperatura, alarmes ou limites operacionais. A interpretação correta exige que o controlador conheça o endereço do registro, o formato dos dados, o fator de escala, a ordem dos bytes, o endereço do dispositivo, a taxa de transmissão, a paridade e o comportamento do tempo limite.

Várias distinções são importantes durante a integração: RS485 não significa automaticamente Modbus RTU; dois dispositivos Modbus não usam automaticamente o mesmo mapa de registro; um conector RJ45 não estabelece compatibilidade com Ethernet, CAN ou RS485; e uma conexão eletricamente válida não garante compatibilidade em nível de aplicação.

Estas verificações evitam uma falha de integração comum: ambos os lados parecem suportar a mesma tecnologia de comunicação, mas a bateria e o controlador do robô não conseguem compreender os dados um do outro.

Onde o CANopen se encaixa em um sistema de bateria de robô

CANopen fica acima do CAN na pilha de comunicação. Não substitui o barramento CAN. Em vez disso, o CANopen define mecanismos padronizados para organizar dados de dispositivos, transmitir informações de processos, acessar parâmetros de configuração, controlar estados de rede e monitorar participantes da rede.

Uma implementação de bateria CANopen requer, portanto, mais do que um transceptor CAN ou conector CAN. O BMS deve implementar as funções CANopen exigidas pelo controlador host.

CAN não é CANopen

CAN fornece o mecanismo de comunicação de rede subjacente. CANopen adiciona a estrutura de camada superior que determina como os dispositivos baseados em CAN organizam e trocam dados de aplicação.

CAN in Automation, ou CiA, descreve um dispositivo CANopen como tendo uma pilha de protocolos CANopen, software de aplicação e um dicionário de objetos que conecta o sistema de comunicação com parâmetros de aplicação.

Isto torna uma regra de aquisição especialmente importante:

Suporte CAN não significa automaticamente suporte CANopen.

Se um controlador AMR exigir uma bateria CANopen, a especificação deverá identificar a funcionalidade CANopen e os mapeamentos de dados esperados pelo controlador. Simplesmente solicitar uma porta CAN não é suficiente.

O Dicionário de Objetos CANopen

O dicionário de objetos é o modelo de dados estruturados utilizado pelos dispositivos CANopen. CiA especifica que os parâmetros de comunicação e aplicação são organizados através de entradas indexadas de dicionário de objetos, com valores de índice e subíndice fornecendo endereços definidos para dados.

Em uma integração de bateria CANopen, esta estrutura pode fornecer uma maneira consistente de expor o status da bateria, parâmetros de configuração e informações de diagnóstico. Os objetos reais da bateria ainda precisam atender aos requisitos do controlador e a qualquer perfil aplicável ou especificação de projeto.

A vantagem prática é a clareza. Os engenheiros não precisam tratar cada quadro CAN como uma mensagem proprietária isolada quando uma implementação CANopen definida é usada. Eles podem trabalhar com objetos documentados e serviços de comunicação.

PDOs, SDOs e Diagnósticos

CANopen separa diferentes tarefas de comunicação através de serviços definidos. Process Data Objects, ou PDOs, são adequados para processar informações trocadas durante a operação. Objetos de dados de serviço, ou SDOs, fornecem acesso a entradas no dicionário de objetos para configuração e funções de serviço.

CANopen também fornece mecanismos para relatório de erros e supervisão de nós. A documentação da CiA identifica funções PDO, SDO, emergência, pulsação e gerenciamento de rede como partes da arquitetura de comunicação CANopen.

Para uma bateria CANopen, os valores operacionais frequentemente necessários podem ser mapeados na comunicação PDO, enquanto o acesso SDO pode suportar comissionamento ou diagnóstico. O mapeamento exacto deve ser acordado antes da integração e não assumido.

É também por isso que uma bateria de robô que se comunica com sucesso através de CAN proprietário não pode ser automaticamente tratada como compatível com CANopen.

Gerenciamento de rede e pulsações

O CANopen Network Management, ou NMT, define os estados de comunicação para um dispositivo. CiA identifica estados de inicialização, pré-operacional, operacional e parado dentro da máquina de estado CANopen NMT. A comunicação PDO fica disponível no estado operacional, enquanto a comunicação SDO pode ser utilizada no estado pré-operacional.

Para a comunicação da bateria do robô, esses estados ajudam a definir o comportamento durante a inicialização, comissionamento, operação normal, desligamento e recuperação.

Os mecanismos de pulsação fornecem outra função útil, permitindo que o controlador determine se um nó esperado permanece presente na rede. Uma especificação de bateria CANopen deve, portanto, abranger mais do que campos de dados da bateria. O estado de inicialização, o tempo de pulsação, a resposta de tempo limite e o comportamento de recuperação também podem ser importantes para o robô.

Escolhendo a interface certa para AGVs e AMRs

O método de comunicação correto é aquele que corresponde à arquitetura de controle existente do robô e fornece as informações da bateria exigidas por esse sistema.

A seleção do protocolo deve, portanto, começar com o controlador host e a arquitetura de carregamento, em vez de uma preferência genérica por CAN ou RS485.

Combine a rede de robôs existente

O primeiro passo é determinar exatamente o que o controlador do robô espera. Um controlador pode usar quadros CAN proprietários, CANopen, RS485 com Modbus RTU ou outro protocolo documentado.

Arquitetura existente	Requisito apropriado de bateria do robô
Controlador CAN proprietário	Bateria CAN BMS com taxa de bits e mapa de mensagens correspondentes
Controlador CANopen	BMS implementando os objetos CANopen necessários e comportamento de rede
PLC ou controlador usando Modbus RTU	Bateria RS485 BMS com configurações seriais correspondentes e mapa de registro
Redes separadas de controle e diagnóstico	Defina qual conexão carrega o controle da bateria e qual carrega os dados de serviço

A bateria do robô deve corresponder a esse requisito de rede. Escolher um pacote porque seu conector ou etiqueta de porta parece familiar reverte o processo de engenharia correto.

Defina os dados necessários da bateria

Antes de solicitar um pacote personalizado, os engenheiros devem criar uma matriz de comunicação que separe os dados necessários para a operação das informações destinadas principalmente ao diagnóstico ou manutenção.

Para muitos projetos AGV e AMR, o necessário bateria de robô os dados incluem:

• Tensão e corrente do pacote
• SOC e SOH
• Temperatura da bateria
• Limites de carga e descarga
• Estados de aviso e proteção
• Status de carregamento e estado do BMS
• Identidade do dispositivo ou endereço de rede
• Status do contator ou MOSFET quando exigido pelo sistema

O projeto também deve definir a direção dos dados. Algumas informações são transmitidas do BMS da bateria AMR para o host, enquanto outras arquiteturas podem exigir comandos de controle, confirmações ou mensagens de configuração do controlador.

Esta etapa determina o que a interface realmente deve realizar.

Verifique o tempo e a resposta a falhas

Uma especificação de comunicação completa precisa de requisitos de temporização além de definições de dados.

Os engenheiros devem determinar com que frequência as informações críticas da bateria do robô devem ser atualizadas, quanto tempo o controlador espera antes de declarar o BMS offline e qual resposta segue um tempo limite de comunicação. As prioridades das mensagens CAN ou os intervalos de pesquisa RS485 devem refletir a importância dos dados que estão sendo transferidos.

A recuperação de falhas também precisa de um comportamento definido. O sistema deve estabelecer se a comunicação é retomada automaticamente após um evento transitório, se o BMS requer uma reinicialização e se o robô pode retomar a operação imediatamente ou deve primeiro verificar o status da bateria.

Essas decisões são específicas da aplicação. Devem ser documentados durante a integração e não inferidos a partir da interface de comunicação.

Planejar a comunicação da estação de carregamento

Um AGV ou AMR carregado automaticamente precisa da base de carregamento considerada parte do bateria de robô arquitetura.

O sistema de carregamento pode precisar coordenar a permissão de carregamento, tensão da bateria, limites de corrente, estado de temperatura, status de carregamento, conclusão e condições de falha. Contatos físicos de carregamento ou um receptor de energia sem contato fornecem o caminho de energia, mas não definem o comportamento da comunicação.

O robô também precisa de uma sequência clara para detectar a doca, permitir o carregamento, responder aos limites do BMS, concluir o processo de carregamento e retornar à operação.

A orientação atual de integração AMR da bateria MANLY identifica comunicação CAN ou RS485, monitoramento de corrente e temperatura, design de conector e fiação específica da aplicação como fatores a serem coordenados ao integrar uma bateria AMR, BMS e base de carregamento.

Para frotas autónomas, a comunicação de carregamento deve, portanto, ser concebida ao mesmo tempo que a bateria do robô e o BMS, e não depois de o pacote já ter sido finalizado.

Considere as necessidades de diagnóstico da frota

Os dados de tráfego e manutenção de controle nem sempre precisam usar o mesmo caminho de comunicação. Alguns robôs colocam dados da bateria sensíveis ao tempo na rede CAN primária enquanto usam uma interface separada para comissionamento, serviço ou diagnósticos mais profundos.

O que importa é que a arquitetura diagnóstica seja deliberada.

Para grandes frotas, definições consistentes de dados de baterias de robôs podem simplificar a solução de problemas em muitos veículos. Códigos de falha, unidades, escala, versões de firmware, estados de comunicação e registros de manutenção devem ter significados repetíveis de um robô para outro.

Isto pode tornar-se particularmente valioso quando o software da frota é utilizado para distinguir eventos relacionados com a energia de falhas do BMS, falhas do carregador ou falhas de comunicação.

O que perguntar a um fabricante de baterias antes da integração

UM fabricante de baterias deve ser capaz de discutir a comunicação BMS com os mesmos detalhes de engenharia usados ​​para tensão do pacote, capacidade, corrente, dimensões e requisitos de conector.

“CAN disponível” ou “RS485 disponível” é útil para triagem inicial, mas uma bateria de robô de produção requer uma especificação de comunicação mais completa.

Protocolo e mapa de mensagens

Para integração CAN, solicite o protocolo de aplicação, identificadores CAN, definições de carga útil, escala, direção da mensagem, tempo de transmissão e comportamento de tempo limite.

Para uma bateria CANopen, defina as entradas necessárias do dicionário de objetos, mapeamentos PDO, acesso SDO, comportamento NMT, requisitos de pulsação e funções específicas do controlador.

Se o projeto usar comunicação CAN específica do fabricante, a definição da mensagem deverá estar disponível com antecedência suficiente para o desenvolvimento do controlador e testes de bancada. A equipe de software não deveria ter que fazer engenharia reversa do bateria de robô após a chegada do hardware do protótipo.

Taxa de transmissão e IDs de nó

Ambos os lados da conexão devem usar configurações de rede compatíveis.

Para CAN, confirme a taxa de bits CAN e o identificador relevante ou configuração do nó. Para CANopen, defina também os IDs dos nós e o comportamento de gerenciamento de rede necessário. Para um BMS de bateria RS485, confirme a taxa de transmissão, a paridade, os bits de parada, o endereçamento e o comportamento esperado de pesquisa ou resposta.

Esses parâmetros devem ser registrados na especificação de comunicação do projeto e controlados como qualquer outro requisito de interface no nível do sistema.

Registrar Mapa e Dimensionamento de Dados

Uma conexão RS485 usando Modbus RTU necessita de um mapa de registro completo. Cada valor necessário deve ter endereço, tipo de dados, fator de escala, unidade de engenharia e método de acesso definidos.

Por exemplo, um valor transmitido não pode ser interpretado corretamente até que o controlador saiba se ele representa volts, milivolts, décimos de volt, corrente com sinal ou outra codificação.

O mesmo princípio se aplica ao CAN. Receber um quadro CAN válido não prova que o bateria de robô os dados foram interpretados corretamente. A ordem dos bytes, as definições de bits, a escala, os valores assinados e os sinalizadores de status ainda precisam corresponder.

Terminação, pinagem e conectores

A documentação elétrica deve identificar todos os pinos de comunicação necessários, incluindo CAN-H, CAN-L, RS485-A, RS485-B, terra de sinal, linhas de ativação, blindagem ou outros condutores específicos do projeto.

A terminação também deve corresponder à topologia de rede selecionada. Os engenheiros devem verificar se a terminação está dentro da bateria do robô, instalada em outro lugar do robô, configurável ou omitida.

O formato do conector nunca deve ser usado como substituto desta documentação. Um conector estilo RJ45, por exemplo, não indica automaticamente Ethernet e não estabelece uma pinagem CAN ou RS485 padronizada.

O projeto do cabo e do conector, portanto, pertence à especificação de comunicação e não apenas ao desenho mecânico.

Requisitos de comunicação do carregador

A bateria e o carregador do robô devem ser projetados como um sistema coordenado quando o processo de carregamento exigir comunicação.

A especificação deve definir se o carregador utiliza configurações elétricas fixas ou recebe limites dinâmicos do BMS ou do controlador do veículo. Ele também deve documentar a lógica de habilitação de carga, limites de corrente e tensão, comportamento térmico, status de carga, conclusão de carga, resposta a falhas, handshake de dock e recuperação após interrupção de carga.

Para um AGV ou AMR que depende de carregamento autônomo, essas funções podem afetar diretamente a confiabilidade com que o robô retorna à operação após chegar à doca.

Opções de comunicação de bateria MANLY

Na MANLY Battery, projetos de robôs e baterias industriais podem ser desenvolvidos em torno dos requisitos de comunicação da aplicação, em vez de tratar a interface como um complemento isolado.

A bateria do robô MANLY 24V 50Ah é um pacote LiFePO4 avaliado em 24V nominal, com uma tensão real de bateria de 25,6V e 1.280Wh de energia nominal. Sua especificação atual fornece comunicação opcional RS485, RS232 ou CANBus. Dimensões, caixa, conector, caixa e fiação também podem ser configurados para requisitos OEM/ODM.

Para robôs industriais que exigem maior capacidade integrada, a bateria do robô MANLY 48V 100Ah fornece capacidade de 100Ah e 4.800Wh de energia nominal. Ele também suporta comunicação opcional RS485, RS232 ou CANBus, com dimensões, invólucros, conectores e fiação personalizáveis.

Bateria do robô MANLY	Comunicação	Foco na integração
Bateria do robô 24V 50Ah LiFePO4	RS485, RS232, CANBus opcionais	Projetos de robôs e AGV que exigem comunicação BMS, conectores e dimensões de pacote configuráveis
bateria de robô industrial 48V 100Ah	RS485, RS232, CANBus opcionais	Aplicações de robôs industriais de maior capacidade que exigem integração coordenada de BMS, controlador, carregador e pacote

Se um projeto exigir especificamente comunicação de bateria CANopen, esse requisito deverá ser definido durante a revisão de engenharia. A disponibilidade do CANBus por si só não deve ser tratada como uma confirmação da compatibilidade do CANopen.

A equipe do projeto deve fornecer o mapeamento de objetos CANopen, configuração de rede, comportamento do controlador e outros requisitos de protocolo necessários para que a implementação possa ser avaliada antes do bateria de robô o projeto está finalizado.

Para projetos CAN ou RS485, aplica-se o mesmo princípio. Fornecer a especificação do controlador, mapa de mensagens ou registros, velocidade de comunicação, pinagem, arquitetura do carregador, tensão, capacidade, requisitos de corrente e comportamento de falha esperado dá ao fabricante da bateria uma meta de integração muito mais clara.

A direita comunicação de bateria de robô portanto, o método não é determinado pela escolha de CAN, RS485 ou CANopen isoladamente. É determinado se o BMS, o controlador do robô, o carregador, a fiação, o protocolo e a lógica operacional foram projetados para funcionarem juntos como um sistema.

Saiba mais sobre bateria