Modbus TCP x Ethernet/IP

Quando se fala em rede industriais e comunicação, um termo vem à mente: Protocolo de comunicação. Existem diversos protocolos de comunicação utilizados na indústria, cada um com suas particularidades. Dois dos mais utilizados são o Modbus TCP e o Ethernet/IP. Ambos resolvem necessidades em comum: adquirir dados / controlar / parametrizar dispositivos. Porém, o caminho para fazer isto é completamente diferente. Vamos entender mais sobre estas diferenças neste post.

Uma breve história

O protocolo Modbus RTU (Sem o TCP) foi inicialmente desenvolvido em 1979 pela Modicon para possibilitar a comunicação entre dispositivos de automação e é um dos mais antigos protocolos de comunicação. O Modbus TCP é uma evolução do seu predecessor e é simplesmente o Modbus RTU encapsulado em um pacote Ethernet, ou seja, o Modbus TCP usa o TCP/IP e Ethernet para transportar mensagens Modbus. É um protocolo mantido pela Modbus e é muito utilizado na indústria. A Schneider Electric, embora atualmente esteja “abraçando” o Ethernet/IP, é pioneira na comunicação via Modbus TCP e possui este protocolo nativo em diversos dispositivos em sua cadeia de fornecimento.

O Ethernet/IP (IP de Industrial Protocol e não de Internet Protocol), é um padrão ethernet destinado a aplicações industriais. Isto quer dizer que este padrão foi desenvolvido pensando em sua aplicação na indústria. Ele começou a ser desenvolvido por volta do ano de 1990 pela Controlnet International e atualmente é mantido pela ODVA (Open Devicenet Vendor Association) e seus membros. No núcleo do Ethernet/IP está o CIP (Common Industrial Protocol) ou Protocolo Industrial Comum, que define a organização da estrutura orientado a objetos dos dados e o formato das mensagens, de forma a criar um padrão de comunicação industrial robusto e consistente, independente de fabricante. A Rockwell, por exemplo, é totalmente aderida ao CIP e Ethernet/IP. Outra empresas, como a Schneider Electric já possuem em suas novas famílias de PLCs o Modbus TCP e O Ethernet/IP já nativos, como é o caso do controlador M580.

Não será dado mais detalhes históricos sobre os protocolos, pois a intenção é focar nas diferenças entre ambos. Então vamos lá!

Características dos protocolos

Tanto o protocolo Modbus TCP e o Ethernet/IP são protocolos regulamentados por organizações industriais. Modbus TCP é regulamentado pela Modbus e o Ethernet/IP pela ODVA.

Ambos os protocolos rodam na camada física Ethernet, logo há diversos elementos da infraestrutura de uma rede ethernet que podem ser utilizados para ambos, como como cabeamento, conectores, switches etc. Inclusive, ambos podem coexistir em uma mesma rede de forma transparente um para o outro.

As diferenças entre um protocolo e outro aparecem com relação aos seguintes itens:

• Modelo de comunicação
• Arquitetura
• Serviços

Modelo de comunicação

Vamos começar pela nomenclatura de cada dispositivo dentro da rede. Para um mesmo tipo de dispositivo, teremos diferentes nomenclaturas, dependendo se ele está operando em Modbus TCP ou Ethernet/IP.

Em um processo de comunicação entre dois dispositivos, há dois lados: O de quem solicita a informação e o de quem entrega a informação solicitada. É a mesma relação de um cliente em um restaurante, que solicita um determinado prato (informação) e o garçom, que a entrega.

Quando falamos de Modbus TCP, o dispositivo que inicia a mensagem é chamado de Cliente e os dispositivos que respondem à mensagem do cliente são chamados de Servidores. É comum também de ver o termo Mestre (ou Master), para referenciar o cliente e o termo Escravo (ou Slave) para referenciar ao servidor.

Já no protocolo Ethernet/IP, o dispositivo que inicia a mensagem é chamado de Scanner (Originator) e os dispositivos que respondem à mensagem do cliente são chamados de adapters (Target). É comum também de ver o termo Consumidor (ou Consumer), para referenciar o scanner e o termo Produtor (ou Producer) para referenciar ao adapter.

Nomenclaturas utilizadas nos protocolos Ethernet/IP e Modbus TCP

Para cada protocolo, há dois diferentes métodos de comunicação entre os dispositivos:

Comunicação explícita: A comunicação explícita é um tipo de comunicação “programada” pelo usuário. Programada pelo fato de que o usuário deve utilizar blocos de funções na aplicação (lógica) para definir os parâmetros de comunicação e o próprio gerenciamento dela (detecção e tratativas na ocorrência de falhas). O intervalo de tempo entre requisições em uma comunicação explícita não é necessariamente cíclico. Ele pode ser disparado por um evento da lógica e não tem necessariamente um período definido. É utilizado em operações que demandam comunicação com menor frequência.

Bloco MSG do RSLogix 5000, de comunicação explícita

Comunicação implícita: A comunicação implícita é uma comunicação que é gerenciada pelo hardware de PLC. Ao contrário da comunicação explícita, ela não é programada pelo usuário. O usuário configura seus parâmetros geralmente em uma tela de configuração do hardware e o hardware gerencia todo o processo da comunicação, sem a necessidade de programar blocos ou lógicas para isto.

Uma das grandes diferenças do Ethernet IP e o Modbus TCP se tratando do de modelo de comunicação é a sequência de comunicação. Vamos discutir sobre as diferenças na comunicação implícita para estes dois protocolos.

Comunicação implícita Ethernet/IP

O protocolo Ethernet utiliza mensagens UDP para comunicação implícita. O protocolo UDP não é um protocolo orientado a conexão, o que quer dizer que não há confiabilidade na entrega das mensagens, pois não há um processo de reconhecimento de entrega de mensagens entre o scanner e o adapter. Em contrapartida, o fato das mensagens não serem “validadas ponta a ponta” fazem com que o fluxo de dados via UDP seja mais rápido do que no TCP (orientado à conexão).

Vamos utilizar da imagem a seguir para descrever o processo de troca de dados no protocolo Ethernet/IP:

Processo de troca de dados em comunicação implícita no protocolo Ethernet/IP

Primeira etapa: O scanner envia na rede uma mensagem inicial, para iniciar a comunicação com um adapter. Esta mensagem inicial contém um comando Ethernet/IP chamado de Foward Open e nele é especificada a informação que o scanner “solicita” e a taxa de RPI. RPI vem de Request Packet Interval, ou Intervalo de requisição de Pacotes, que é o intervalo de tempo entre uma solicitação e outra durante o processo de comunicação. Se o RPI for de 100ms, de 100 em 100ms a informação solicitada pelo scanner será enviada pelo adapter. Esta mensagem é como se o scanner falasse assim:

“- Estou precisando do adapter A a informação X, e quero que esta informação seja enviada a cada RPI de 100ms.”

Embora a troca de dados via comunicação implícita no ethernet IP seja via UDP, o comando Foward Open é enviado através de uma mensagem Unicast TCP, o que quer dizer que é uma mensagem para um único target da rede (por isto Unicast) e é orientada a confiabilidade de conexão (por isto TCP).

Segunda etapa: Esta mensagem chegará ao adapter de destino e depois que este adapter reconhece a mensagem, irá publicar na rede a informação solicitada pelo scanner em um intervalo de tempo ditado pelo RPI que o scanner definiu.

A cada RPI, este dado produzido pelo adapter é enviado através de mensagens UDP Multicast, o que quer dizer que ele produz a informação não apenas para o scanner que solicitou, mas esta informação fica disponível também para outros “consumidores” da rede e pode, como consequência consumir mais largura da banda da rede. Para que isto não ocorra, é possível configurar esta mensagem para Unicast (ponto a ponto), via interface do software de programação.

Se requerido, o scanner também não só solicita dados do adapter, mas também escreverá dados nele na taxa definida pelo RPI.

Durante um processo de falha na comunicação entre o scanner e o adapter, se uma mensagem for perdida, ela não é reenviada (pois como foi dito, a comunicação é via UDP). Ambos scanner e adapter irão utilizar a próxima mensagem bem-sucedida. Para indicar que há uma falha de comunicação entre ambos, é verificado se o scanner não recebe resposta do adapter por um período que é igual ao produto do RPI com uma constante denominada RPI Multiplier (ou Network Multiplier).

No exemplo da imagem anterior, onde o RPI estava configurado para 100ms, se o RPI Multiplier ajustado for igual a 3, após scanner não receber uma resposta do adapter, irá aguardar um tempo de 3 RPI’s, que totaliza 300ms (100ms x 3) para somente após este tempo sem mensagem recebida indicar uma falha de comunicação entre ambos.

Linha do tempo de uma falha de comunicação em Ethernet/IP (implícita)

Linha do tempo de uma falha de comunicação em Ethernet/IP (implícita)

Dependendo do hardware e do firmware, o RPI é ajustado automaticamente ou pelo usuário e possui um valor mínimo permitido.

Comunicação implícita Modbus TCP

O protocolo Modbus TCP utiliza comunicação Ponto a ponto (Unicast) e mensagens TCP, que são mensagens orientadas a conexão. Isto quer dizer que há todo um processo de validação de entrega e integridade das mensagens (handshake), tanto do lado do cliente (quem solicita) quanto do servidor (quem fornece). A imagem abaixo ilustra como é o processo de troca de dados em uma comunicação implícita em Modbus TCP, de uma forma simplificada:

Processo de troca de dados em comunicação implícita no protocolo Modbus TCP

Primeira etapa: O cliente envia uma requisição ao servidor (que pode ser de leitura ou escrita) em uma taxa de tempo denominada Repetitive Rate. O Repetitive rate no Modbus TCP é o equivalente ao RPI no Ethernet/IP, ou seja, é o intervalo de tempo entre uma solicitação e outra durante o processo de comunicação. Se o Repetitive rate for de 100ms, de 100 em 100ms o cliente irá solicitar a informação do servidor.

Segunda etapa: O dispositivo escravo (servidor) irá processar a requisição enviada pelo mestre (cliente) e irá responder ao servidor com a informação solicitada. Uma das principais diferenças é que no Ethernet/IP, após o scanner enviar o Foward Open, é o adapter é quem ficará enviando as mensagens para o scanner repetitivamente e o scanner não precisa mais ficar solicitando a informação a cada ciclo. É como se o adapter falasse: “- Scanner, você já me falou o que tenho de enviar e o intervalo de tempo com o qual devo repetir o envio. A partir de agora fica calado e deixa comigo, porque eu já sei o que fazer”.

No Modbus TCP a cada ciclo sempre haverá sempre a requisição do cliente e a resposta do servidor. Ao contrário do “diálogo” entre o scanner e o adapter, o mestre sempre tem de informar para o cliente o que ele quer a cada intervalo de tempo.

Estas etapas descrevem o processo de comunicação entre cliente/servidor de uma forma simplificada. Isto porque como a comunicação implícita em Modbus TCP se dá por mensagens TCP, há todo um processo de confirmação de entrega da mensagem (Three-Way Handshake).

Durante um processo de falha na comunicação entre o cliente e o servidor, o cliente (mestre) irá detectar esta falha ao perceber que não recebeu resposta por parte do servidor (escravo) dentro de um período denominado de Timeout. Quando este tempo de timeout for atingido, o cliente ainda tentará enviar a solicitação por uma determinada quantidade de vezes. Esta tentativa de reenvio de mensagens é denominada de Retry. Se um cliente está configurado como um timeout de 1 segundo e Retry = 3, após 1 segundo de “branco” na comunicação entre ele e o cliente, ele irá considerar que a primeira tentativa foi sem sucesso e irá fazer mais 2 tentativas de comunicação, onde o intervalo de tempo entre cada tentativa também é igual ao tempo de timeout. Após executadas todas as tentativas de comunicação sem resposta, o cliente irá resetar a comunicação com o servidor e indicar falha na comunicação com ele.

Linha do tempo de uma falha de comunicação em Modbus TCP (implícita)

Algumas configurações de comunicação em Modbus TCP podem não haver o parâmetro Retry; apenas o Timeout.

Arquitetura da memória

Para obtermos qualquer tipo de informação de um dispositivo, precisamos acessar dados que estão gravados na memória interna dele. Estes dados podem ser a leitura da posição de um encoder, por exemplo. E para acessar estes dados, precisamos entender a estrutura da memória onde eles estão armazenados. Imagina você querer chegar a um determinado local (que você sabe o nome) mas não sabe o endereço…

E é aí onde surge outra grande (GRANDE mesmo) diferença entre os protocolos Modbus TCP e o Ethernet IP: A arquitetura de memória.

Arquitetura de memória em Modbus TCP

A arquitetura de memória é mais simples, baseada em registros (conhecida como memória plana ou do inglês flat memory). Cada dispositivo possui uma área de memória com uma determinada quantidade de registros disponíveis para leitura ou escrita, onde cada registro possui um endereço numérico único, e o usuário define quais registros (endereços) ele precisa ler ou escrever baseado na informação que ele precisa.

Esta arquitetura baseada em registros (flat memory) funciona como um gaveteiro, onde cada gaveta é um registro contendo uma informação que o usuário pode ler (ou dependendo do caso escrever). Geralmente esta área de memória é dividida entre área de memória de escrita e área de memória de leitura. Fazendo a analogia do gaveteiro, vamos exemplificar uma estrutura de memória fictícia (e bem simplificada) de um inversor de frequência:

Estrutura de memória plana (flat memory) em Modbus TCP

Para acessar os dados em um dispositivo Modbus TCP, basicamente são necessárias 3 informações:

• O endereço IP do dispositivo
• O endereço inicial de leitura
• A quantidade de registros consecutivos a ser lido a partir do endereço inicial de leitura

Arquitetura de memória em Ethernet/IP

A arquitetura de memória em Ethernet/IP é mais abstrata e orientada a objeto. Isto faz com que ela seja mais sofisticada, porém mais complexa de entender do que a de Modbus TCP:

Estrutura de memória orientada a objeto em Ethernet/IP

Para acessar os dados em um dispositivo Ethernet/IP, basicamente é necessário passar as seguintes informações:

• O endereço IP do dispositivo
• ID da classe do objeto
• ID da instância
• ID do atributo
• Código de serviço
• Em alguns casos, o tamanho do pacote enviado

A ODVA padroniza estes parâmetros na tentativa de fazer com que as configurações de memória sejam idênticas para dispositivos de mesma classe, mesmo sendo de diferentes fabricantes. Isto faz com que o padrão Ethernet/IP seja completo e consistente, mas fabricantes podem definir seus próprios objetos, quando necessário.

A classe é o código que representa o tipo de componente. Por exemplo, um objeto de classe 35 (decimal) representa sensores de posicionamento, como encoders e um objeto de classe 42 (decimal) representa inversores. Vários objetos de mesma classe podem ser utilizados, gerando várias instâncias. Estas instâncias possuem diferentes atributos, que são objetos particulares. Simplificando, são os “dados” que o dispositivo dispõe, como posição, temperatura, versão de firmware. Por fim, nestes dados executamos determinado tipo de serviço, como por exemplo leitura ou escrita.

Vamos utilizar de um exemplo real, onde precisamos escrever um valor de preset em um encoder em Ethernet/IP, do fabricante Leine Linde através de mensagem explícita. Para fazer esta operação no RSLogix, o bloco MSG é utilizado. Perceba na imagem a seguir os parâmetros que falamos:

Escrevendo via comunicação explícita um preset em um encoder Ethernet/IP da Leine Linde através do bloco MSG (RSLogix). Fonte: https://www.leinelinde.com/support/downloads/#12071

Este exemplo foi um exemplo de comunicação explícita, onde o usuário define manualmente todos os parâmetros de comunicação (IP, classe, instância etc.). Para que consigamos acessar os dados de um dispositivo Ethernet/IP de forma implícita, precisamos também de um arquivo chamado EDS (Eletronic Data Sheet). Como o próprio nome já diz, este arquivo é como se fosse o “driver” do dispositivo, contendo as informações para estabelecimento de comunicação e acesso aos dados dele. O EDS facilita o acesso de dados do dispositivo, pois ao nos disponibiliza os dados que podemos ler e escrever no mesmo e nos poupa tempo de procurar no manual todo o caminho que precisamos de percorrer para acessá-la, como ocorre na comunicação explícita. O EDS é fornecido pelo fabricante do dispositivo, mas há casos em que não se tem o EDS do dispositivo e há a possibilidade de utilizar um Generic EDS, que nada mais é que um EDS genérico, que irá permitir a obtenção de dados genéricos.

Deu para perceber que ler um dado via protocolo Ethernet IP é mais complexo do que em Modbus TCP e irá demandar um treinamento maior e uma curva de aprendizado mais lenta por parte de quem irá utilizá-lo.

Serviços

Por fim, outro aspecto em que os dois protocolos se diferenciam é pelos serviços que são disponíveis para cada um.

Em Ethernet/IP, quando é necessário a substituição de um dispositivo defeituoso na uma rede por um novo, a recuperação da configuração do dispositivo antigo para o novo é realizada pelo scanner, pois no protocolo Ethernet/IP, a configuração do dispositivo fica armazenada nele. Quando um novo dispositivo é instalado no lugar do antigo, ele solicita ao scanner a configuração e o scanner então responde enviando a este dispositivo a configuração armazenada.

No Modbus TCP não há um serviço definido de recuperação de configuração definido. Para isto, há um serviço à parte, o FDR. A sigla FDR é apresentada com significados diferentes, dependendo da literatura:

• Fast Device Replacement (Reposição Rápida de Dispositivo)
• Faulty Device Recovery (Recuperação de Dispositivo defeituoso)
• Faulty Device Replacement (Reposição de Dispositivo defeituoso)

Embora haja diferentes atribuições para a sigla, a função é a mesma: Ajudar na substituição rápida de um dispositivo na rede. O serviço FDR armazena configurações de rede e parâmetros operacionais de um determinado dispositivo na rede. Se este dispositivo vier a ser substituído, o serviço, assim como no Ethernet/IP envia automaticamente as configurações armazenadas para o novo dispositivo.

Com relação à identificação do tipo de dispositivo, o protocolo Modbus TCP não define um padrão de identificação. Para haver a comunicação, é apenas configurado um IP e uma área de memória a ser lida ou escrita no dispositivo. Isto implica, por exemplo que se o usuário no campo colocou um inversor na rede com um mesmo IP de um encoder, desde que o encoder esteja “fora” e não haja conflito de IPs, o mestre irá efetuar a tentativa de leitura/escrita no inversor, achando que se trata de um encoder (pois ele só olha para IP e endereço e estas duas informações por si não diferenciam um dispositivo do outro). E pior: se coincidir que a faixa de leitura/escrita for uma faixa válida para o inversor, o mestre irá manipular esta faixa e nem fica sabendo que está tentando fazer leitura e/ou acionar um inversor.

Já no Ethernet/IP, é informado primeiramente a classe (identidade) do objeto. Para o mesmo exemplo do encoder e o inversor, no Ethernet/IP o encoder possui sua identificação de classe igual a 35 (decimal) e o inversor 42 (decimal). Logo, mesmo se a situação anterior ocorrer, o Scanner irá identificar que o objeto que foi substituído no lugar do encoder não se trata de um encoder e não irá estabelecer a comunicação. Logo não há risco de acionar o inversor acidentalmente.

O protocolo Modbus TCP ainda é muito utilizado para comunicação com sistemas SCADA. Você irá deparar com muitos projetos de supervisório e IHM referenciando endereços de registros Modbus TCP na base de dados de variáveis, mas não encontrará um projeto com aquelas referências de endereço de dados em Ethernet IP (Classe, instância, atributos etc.).

O protocolo Ethernet IP permite que você faça o procedimento de Network Discovery, que nada mais é do que uma varredura na rede para identificar quais os dispositivos estão conectados à rede. Descoberto estes dispositivos, o software de configuração indica qual EDS mais aplicável a este dispositivo. Embora no protocolo Modbus TCP tenha esta função, há alguns dispositivos que não suportam “serem descobertos” na rede.

E quando utilizar um ou outro?

Não há uma resposta única para esta pergunta. Nem mesmo uma norma ou “técnica”. A resposta é: “depende”. A escolha de utilizar Modbus TCP ou Ethernet/IP irá variar de um sistema para outro.

Em um sistema existente onde há diversos dispositivos Modbus TCP, o mais plausível é continuar a utilizá-lo. Como os dois protocolos são baseados em ethernet, futuramente, caso seja necessário, é possível utilizar a mesma infraestrutura para fazer uma implementação de novos dispositivos em Ethernet/IP ou até mesmo a substituição completa dos existentes.

Para um novo sistema, fatores como os protocolos suportados pelos dispositivos que serão implementados na rede, suporte e necessidades técnicas devem ser considerados. O Ethernet/IP possui uma flexibilidade maior de diagnósticos e funcionalidades (como a reposição rápida) que alguns dispositivos em Modbus TCP não possuem. A complexibilidade do protocolo também deve ser considerada, pois demanda um conhecimento e tempo maior de aprendizado. Não é difícil na área de automação você escutar histórias de equipes que tiveram problemas na fase de configuração e/ou manutenção, para diagnosticar falhas em dispositivos Ethernet/IP, gerando um tempo de resposta maior e consequentemente perda de produção.

Dependendo do caso, a combinação dos dois protocolos também é o melhor caminho a se tomar. Há PLCs e módulos de comunicação de alguns fabricantes que até suportam comunicação com estes dois protocolos, facilitando ainda mais esta existência de ambos os protocolos na mesma infraestrutura de rede. É o caso do PLC M580 da Schneider Electric, tal como os módulos de comunicação BMENOC301, também da Schneider Electric. Esta capacidade de suportar os dois protocolos sem necessidade de gateways “no meio do caminho” facilita bastante na migração de um protocolo para outro ou até mesmo a convivências de ambos na mesma rede, dependendo da necessidade do sistema.

Finalizando

E você, tem algum caso para contar sobre alguma situação em que teve dificuldades de trabalhar e passou aperto com Modbus TCP ou Ethernet/IP? Gostaríamos bastante se pudesse comentar e compartilhar esta situação. E quem sabe pode ser tema de debate posteriormente, ajudando pessoas que poderão passar pela mesma situação.

Esperamos que este conteúdo tenha agregado valor e conhecimento para você. Se está achando nossos conteúdos úteis, agradeceríamos se considerasse e os compartilhasse, para que eles também possam alcançar mais pessoas e ser útil para elas também. Se tem alguma dúvida, sugestão ou algo não ficou claro, sinta-se à vontade em colocar nos comentários. Sintam-se à vontade também em sugerir algum tema que possa servir de assunto para um post dedicado.

Muito obrigado pela leitura, um grande abraço e até o próximo post!