Desenvolvimento de aplicações com Modbus

Visão geral

O protocolo industrial Modbus foi desenvolvido em 1979, para possibilitar a comunicação entre dispositivos de automação. Originalmente implementado como um protocolo de nível de aplicação, destinado a transferir dados por uma camada serial, o Modbus foi ampliado para incluir implementações em comunicações seriais, TCP/IP e UDP (user datagram protocol). O Modbus é formado por duas partes: a camada de aplicação e o networking base. A camada de aplicação é o núcleo do protocolo. Essa camada determina muitas das restrições do projeto. Esse documento enfoca o uso da camada de aplicação do Modbus.

Conteúdo

Por que o Modbus?

O Modbus é aberto, disseminado e relativamente de fácil uso, além disso, tem poucas restrições quanto à sua aplicação; entretanto, tem suas limitações. Em muitos casos, o usuário não tem escolha além de utilizá-lo, devido a restrições de hardware como o uso de sensores ou outros dispositivos que precisam conversar pelo Modbus. Utilizando o Modbus ou tendo outras opções, você precisa compreender os benefícios e restrições inerentes a esse protocolo.

Se o Modbus for a melhor escolha para o trabalho, é importante saber como utilizá-lo. Quais são as opções para a sua implementação? Como você projeta sua aplicação para aproveitar as vantagens desse protocolo?

Considerações para a seleção e projeto do protocolo

A camada de aplicação do Modbus é implementada como um projeto mestre-escravo baseado em requisição-resposta que transmite dados entre dois pontos através de diversas camadas de networking. Esse projeto fundamental funciona bem, mas tem seus pontos fracos em algumas aplicações.

Padrões de mensagens do Modbus

O Modbus é um protocolo de requisição-resposta para interação entre sistemas SCADA (Supervisory Control and Data Acquisition) e dispositivos de automação. O dispositivo alvo deve responder a todas as requisições enviadas. Há uma resposta para cada requisição. Além disso, as requisições frequentemente são originadas de uma única fonte e visam um único dispositivo. Esses sistemas podem ser caracterizados por conter um dispositivo cliente, que gera uma requisição e aguarda a resposta, e um dispositivo servidor, que interpreta as requisições do cliente, trata essas requisições e então envia uma resposta (veja a figura 1). A terminologia do Modbus muitas vezes se refere ao cliente como mestre, pois normalmente ele é o host SCADA, e se refere ao servidor como escravo. Esse escravo muitas vezes é um sensor ou controlador de automação.

Figura 1. Modelo requisição-resposta com cliente-servidor

 

Confiabilidade das interações do Modbus

O padrão de mensagens do Modbus é similar àquele definido pelo HTTP. Uma vantagem desse padrão é que ele não requer uma camada de rede extremamente confiável. Se o cliente (ou mestre) enviar uma requisição e não receber uma resposta, ele saberá que algo deu errado e poderá enviar novamente a requisição. Em uma analogia com o HTTP, essa situação seria equivalente a clicar no botão "Atualizar" de um navegador web. Se você enviar várias requisições e não receber uma resposta do servidor, pensará que o servidor está fora do ar e vai parar de tentar acessá-lo por algum tempo. Esse comportamento é similar ao exibido por alguns servidores OPC, como o KEPServerEX e NI OPC Servers, quando a comunicação com o Modbus é perdida. Embora esse comportamento não seja uma proteção contra a perda de controle, ele garante que o mestre saberá quando tiver perdido o controle e poderá tomar medidas apropriadas, como acionar um dispositivo de segurança ou usar um dispositivo redundante para manter o controle. Isso não ocorre com o escravo, ou servidor.

Devido ao requisito de que todas as requisições têm de vir de um dispositivo mestre, um escravo inteligente não tem uma indicação confiável de que a comunicação foi perdida. Se o escravo não receber requisições, isso pode significar que a rede está fora do ar, o mestre está fora do ar, ou que o mestre decidiu parar de enviar requisições. Essa falta de informação confiável de status pode ser resolvida de muitas maneiras diferentes, mas o desenvolvedor do sistema deve entender essa necessidade.

Uma solução bastante utilizada para esse problema é que os dispositivos tenham um temporizador watchdog. Se nenhuma requisição for recebida em um determinado intervalo de tempo, o dispositivo escravo assumirá que houve alguma falha e entrará em um estado seguro. Dependendo do dispositivo e da aplicação em questão, isso pode ser benéfico ou prejudicial ao controle global do sistema.

A solução simples com o watchdog tem suas limitações; especificamente, ela apenas confirma que as requisições estão sendo recebidas. Você pode usar esquemas de complexidade crescente, mas uma abordagem simples e efetiva, muito usada, é implementar um heartbeat no nível do registrador. Se o dispositivo puder utilizar esse recurso ou se você estiver desenvolvendo um dispositivo a partir do zero, essa abordagem garante a comunicação constante entre um mestre e um escravo no nível da aplicação. Isso significa que se o código de controle no mestre for responsável por alterar o valor do heartbeat e o código de controle no escravo for responsável por sua leitura, o valor do heartbeat representará um teste simples para a confirmação de que o sistema está funcionando normalmente. A funcionalidade do sistema, do código de controle do mestre às camadas de networking e todo o caminho até a malha de controle do escravo serão verificados por esse teste de heartbeat no nível do registrador. Outro registrador, modificado no escravo e lido no mestre, pode também ser usado para indicar a comunicação na outra direção.

Figura 2. Implementação de um heartbeat simples

Comunicação não solicitada

A natureza dessa arquitetura mestre escravo também implica que os escravos Modbus não podem fornecer dados não solicitados a um mestre. Apesar de o mestre poder implementar uma arquitetura baseada em eventos para enviar dados a um escravo, ele deve consultar os escravos continuamente, enviando comandos de polling a uma determinada taxa para obter novos dados. Isso significa um consumo significativo de recursos, tanto em termos de largura de banda de rede e utilização da CPU do mestre.

Em aplicações com atualizações frequentes de informações (fornecidas, por exemplo, por um sensor de temperatura), esse projeto funciona bem. Como esses dados variam constantemente, faz sentido utilizar polling em uma taxa definida pela aplicação. Por outro lado, um elemento de dados atualizado a intervalos longos, como um bit de alarme ou chave física, seria monitorado de maneira mais eficaz se o mestre somente fosse atualizado quando houvesse uma mudança de valor. O Modbus, de qualquer maneira, requer que cada valor seja verificado periodicamente.

Controle de rede e determinismo

Essa incapacidade do escravo de enviar dados não solicitados a um mestre significa que o Modbus oferece um nível de controle sobre a rede exigido por algumas aplicações. Em uma rede frágil, um protocolo de requisição-resposta pode garantir que o mestre será o único dispositivo que pode determinar quando a comunicação ocorrerá na rede. Se tudo for configurado corretamente, o mestre pode eliminar colisões entre pacotes na rede e garantir um maior nível de determinismo.

Essa configuração pode também oferecer benefícios mais gerais a um sistema de controle, pois a comunicação da rede sempre estará estável. Se informações baseadas em evento pudessem ser transmitidas pela rede por qualquer um dos escravos, isso introduziria jitter no sistema. Apesar de isso ser aceitável para algumas aplicações, o uso de um mecanismo estrito de polling para a transferência de dados reduz o risco.

Comunicação e organização de dados por tags

Os dados do Modbus são orientados pelo conceito de tags, ou variáveis. Esses elementos de dados — registradores de holding, registradores de entrada, coils e entradas discretas — são chamados por diferentes nomes dentro do protocolo, mas a ideia é a mesma. Esses tags são elementos de dados que podem ser lidos ou escritos a qualquer momento, mas fornecem apenas seu valor no momento. Isso faz sentido para algumas aplicações, mas a implementação de conceitos como eventos, mensagens ou buffers de memória FIFO (first-in-first-out) pode ser difícil.

O Modbus define quatro bancos de dados — os quatro tipos mencionados acima — que armazenam a vasta maioria das informações transportadas pelo protocolo. Cada requisição de um mestre pode executar uma única operação em um determinado banco de dados. Isso significa que uma requisição pode fazer uma leitura nos bancos de coils ou escrever nesses bancos, mas não ambas. Há exceções, entretanto. Por exemplo, o código de função 23 permite que um mestre escreva em registradores holding e leia registradores holding em um único ciclo de requisição-resposta. Entretanto, esse não é um código de função muito implementado. A documentação dos dispositivos mestre e escravo deve ser consultada para verificar se esse código de função está disponível.

É crítico também entender que os dados de um determinado banco somente podem acessados de maneira sequencial e até o limite de tamanho de pacote do protocolo Modbus. Esse limite é tipicamente de cerca de 240 a 250 bytes de dados de payload, mas isso depende da função utilizada. Isso torna extremamente importante projetar cuidadosamente os bancos de registradores.

Por exemplo, uma determinada aplicação pode exigir a transferência de quantidades significativas de dados a altas taxas. Nesse caso, é desejável minimizar a quantidade de requisições exigidas. Como os dados devem ser acessados sequencialmente, faz sentido que essa aplicação concentre o máximo de dados possível em um único banco de registradores e empacote dados juntos com a mínima quantidade de elementos de dados não utilizados.

Outra aplicação pode ter um escravo mais complexo, que permita algum grau de controle local. Nessa situação, pode haver dados lidos a uma taxa alta e outros dados monitorados periodicamente. Nesse caso, os dados devem ser agrupados por taxa de transferência. A atualização de dados rápida deve ser concentrada em um local e os dados atualizados com menor frequência devem ser organizados em diferentes blocos, para tornar mais fácil que uma determinada requisição faça a leitura ou atualização de um determinado conjunto de dados.

Como exemplo, considere um conjunto de cinco valores de dados (F1-F5) atualizados rapidamente e cinco valores de dados atualizados lentamente (S1-S5). Além disso, S1, S2 e S3 corresponderão a um módulo de código; S4 e S5, a outro — ou seja, eles podem ser atualizados em tempos diferentes. Na figura 3, a organização ideal para esse caso proporciona ao mestre a capacidade de ler os dados atualizados rapidamente em uma única requisição e então, conforme necessário, ler os outros dados de atualização lenta.

Figura 3. Dados bem organizados

Caso não tomemos cuidado, um conjunto de dados pode facilmente ser organizado como mostrado na figura 4. Nesse caso, passamos de um pouco mais de 20 requisições por segundo a mais de 80 requisições por segundo. É, na verdade, mais eficiente que um conjunto de dados pequeno seja lido todo em um único bloco. Entretanto, essas abordagens rapidamente se tornam insustentáveis em um sistema complexo.

 

FigurA 4. Má organização dos dados

Numeração de tags

Internamente, os dados de cada banco do Modbus são acessados por um valor de endereço de 0 a 65.535, mas é mais comum que a documentação se refira aos elementos de dados conforme um esquema de endereçamento comum. Nesse esquema, o endereço do elemento de dados tem um prefixo, que é um número que define o banco a ser acessado. Esses prefixos são mostrados no quadro 1

Bloco de dados Prefixo
Coils 0
Entradas discretas 1
Registradores de entrada 3
Registradores holding 4

Quadro 1. Prefixos de acesso aos dados

 

Dependendo da documentação que esteja sendo referenciada, o endereçamento começa em zero ou 1 e utiliza um comprimento fixo de quatro a seis valores. Isso significa que documentos diferentes podem se referir a um mesmo registrador de holding de valores inteiros como 4005, 40004 e 400005. A documentação deve definir o esquema de endereçamento utilizado, e qualquer novo desenvolvimento de sistema deve publicar essa informação.

Utilização da rede

Os protocolos de requisição-resposta não necessariamente fazem o melhor uso da largura de banda da rede. Embora uma requisição de um mestre para ler um determinado valor de dados certamente precisa de uma resposta, esta não é necessária para uma requisição para escrever dados. Entretanto, o protocolo de aplicação do Modbus requer que uma resposta seja enviada para cada requisição. Isso significa que é necessário que um pacote Modbus completo seja formado, incluindo dados de protocolo, dados de aplicação e quaisquer dados de rede necessários. Isso também significa que um processo de requisição de dados e recepção destes em uma resposta pode levar um tempo significativamente maior que a exigida pela simples difusão dos dados, devido à latência da rede, tempo de processamento do escravo e quaisquer eventuais colisões ou interferências.

Isso é ainda mais ampliado pelas considerações de organização de dados descritas acima. Se os dados estiverem mal organizados no espaço de memória do Modbus, a quantidade de ciclos de requisição-resposta necessários pode aumentar drasticamente. Por motivos relacionados à latência, há uma taxa finita na qual os ciclos de requisição-resposta podem ocorrer, mesmo sem a interferência da rede. Como resultado, a redução da quantidade de requisições necessárias para a interação entre um mestre e um escravo é uma das melhores formas de aumentar o desempenho do sistema.

Considerações de segurança 

O protocolo Modbus oferece pouca ou nenhuma segurança. No passado, a natureza confinada das redes industriais significava que era necessário haver uma violação física na segurança para uma infiltração na rede. À medida que as redes se tornaram mais interconectadas, a segurança passa a ser uma preocupação mais séria. Nos últimos anos, vários esquemas foram formulados para a segurança da comunicação por protocolos Modbus. Entretanto, esses esquemas geralmente acabam com a compatibilidade entre as redes e dispositivos Modbus existentes.

Considerações para a implementação

A utilidade global de um determinado sistema também varia, dependendo da implementação de driver específica escolhida. Tipicamente, os mestres Modbus são integrados em uma aplicação, seja por uma biblioteca ou uma ferramenta autônoma, como um servidor OPC. Por outro lado, um escravo Modbus é normalmente integrado a um dispositivo que utiliza algum tipo de biblioteca ou desenvolvido como parte do firmware de um dispositivo. De qualquer forma, é importante compreender a variedade de implementações disponíveis, para fazer a escolha mais apropriada para uma determinada aplicação.

Aplicação ou biblioteca

Tipicamente, uma aplicação como KEPServerEX ou NI OPC Servers tem recursos mais completos que uma biblioteca, mas oferece menos recursos de controle. Por exemplo, essas duas aplicações de servidores OPC podem ser configuradas para fornecer elementos de dados específicos a uma taxa específica, e ambas podem converter os dados brutos do Modbus em um tipo de dados definido. Elas são limitadas, entretanto, por não permitirem a geração e envio diretos de uma requisição de Modbus — todas as requisições devem passar pela aplicação e as opções de configuração são limitadas. Uma biblioteca, por outro lado, tipicamente fornece dados brutos e requer que você inicie todas as requisições. Isso oferece flexibilidade e dá a você um rígido controle sobre todo o tráfego.

Agendamento de requisições

Seja qual for a implementação, aplicação ou biblioteca, alguma parte do sistema será a responsável pelo agendamento de requisições e determinação do formato dessas requisições. De forma geral, as implementações são feitas de uma das duas formas. A primeira possibilidade seria exigir que todas as requisições e respostas ocorressem em sequência. Essa abordagem de projeto síncrono é uma opção comum, pois o código é simples e não dependente de rede; entretanto, ele pode subutilizar significativamente uma rede TCP/IP. Em um projeto síncrono, o mestre deve executar as seguintes operações: gerar uma requisição, enviar essa requisição pela rede, aguardar que o servidor tenha tempo de processar a requisição e gerar uma resposta, aguardar que a resposta atravesse a rede, e finalmente processe essa resposta — tudo isso antes de gerar outra requisição. Para um dispositivo escravo ou camada de rede suficientemente lentos, esse tempo de ida-volta pode ser significativo.

A alternativa é um projeto assíncrono, no qual um processo no mestre é responsável pela geração de requisições, enquanto outro processo é responsável por receber respostas e rotear essas respostas internamente ao código que necessita dos dados. Esse projeto é muito mais eficiente porque várias requisições podem estar em processamento na rede de uma só vez, mas isso requer que o escravo tenha um buffer de tamanho suficiente na memória para lidar com as requisições de entrada e que o desenvolvedor da implementação do mestre invista significativamente mais recursos no problema. A figura 5 demonstra a diferença entre esses dois esquemas de envio de mensagens. Cada seta à direita indica uma requisição e cada seta à esquerda indica uma resposta.

Figura 5. Comparação entre transmissões síncronas e assíncronas das mensagens

Algumas aplicações, como KEPServerEX e NI OPC Servers, aproximam as diferenças e implementam um esquema de threading que oferece alguns dos benefícios das duas implementações. Isso significa que tags e dispositivos podem ser organizados de forma que todas as requisições ocorram sincronamente, em um único thread, ou possam ser organizadas em diferentes threads. Nesse caso, todos os tags em um determinado thread são solicitados sincronamente, mas vários dispositivos podem ser acessados em paralelo. Isso mantém um controle razoavelmente rígido sobre a rede e melhora o desempenho global do sistema.

Disponibilidade de tipo de dados

Em parte, o Modbus é flexível porque quase não impõe restrições aos dados do sistema. Os dados do sistema são formados por até quatro blocos de registradores, ou elementos booleanos, de até 65.635 palavras. Os dados podem ser armazenados em elementos dos tipos U16 ou booleanos, ou podem ser armazenados como valores de sub-registradores, ou como dados que cruzam as fronteiras de diversos registradores.

Infelizmente, essa flexibilidade não implica em usabilidade. Assim como com o TCP e serial, onde os dados são transferidos como feixes de bytes, o código da aplicação que utiliza Modbus precisa formatar os dados de maneira que faça sentido para o resto do sistema. Por exemplo, a conversão de dados dos 32 bits que transformam o primeiro e segundo registradores em um valor de ponto flutuante de precisão simples é feita inteiramente pelo código da aplicação. Para tornar as coisas mais confusas, o ordenamento desses dados não é definido pelo protocolo. O protocolo define que os registradores sejam transferidos pela rede na ordem da rede (big-endian), mas diversos dispositivos lidam com as fronteiras entre registradores de maneira diferente.

Essa situação é importante para ser considerada em todas as implementações, pois pode haver variações entre dispositivos diferentes. Uma biblioteca tipicamente fornece dados brutos na forma de registradores, o que significa que você precisa reformular os dados conforme necessário para a sua aplicação. Se uma biblioteca fornecer um tipo de dados específico, a documentação deverá ser consultada para conhecermos o formato esperado. Por outro lado, uma aplicação tipicamente permite algum grau de variabilidade. Por exemplo, KEPServerEX e NI OPC Servers dão a você a capacidade de trocar a convenção endian de interpretação dos dados para cada dispositivo. Se essa opção não estiver disponível, você precisará implementá-la por você mesmo e tratar os registradores como dados brutos.

Endereçamento

Como discutido anteriormente, o endereçamento no Modbus é complicado, devido à variedade de esquemas utilizados. Embora a especificação defina um esquema de endereçamento obrigatório (isso é, o registrador de holding número cinco é lido pelo endereço da requisição 0x04 com código de função 0x03), os dispositivos tipicamente convertem essa informação em um único número. A documentação de diferentes fontes pode usar um mesmo número para se referir a valores diferentes. É crítico que isso seja considerado quando uma biblioteca padrão ou aplicação sejam utilizadas.

Tipicamente, uma biblioteca não fornece abstrações para a conversão de um esquema comum de endereçamento, como "400005," em uma requisição pelo dado armazenado no registrador de holding número cinco. Algumas bibliotecas, especialmente aquelas que fornecem suporte a tipo de dados, podem fazer isso.

Em contraste, servidores OPC e outras aplicações têm maior probabilidade de usar um esquema de endereçamento mais geral. Aplicações como NI OPC Servers e KEPServerEX fornecem até mesmo opções para cobrir muitas das permutações em esquemas de endereçamento (indexação iniciada em zero ou um, por exemplo). Entretanto, essas aplicações ainda podem ter requisitos incomuns — especialmente quando se trata de interpretar registradores como tipos de dados diferentes — e a documentação de aplicação deve sempre ser referenciada, para garantir que os dados sejam transferidos e interpretados corretamente.

Seleção de implementação e arquitetura do Modbus

Se o Modbus for escolhido como o protocolo a ser usado em uma aplicação, três ferramentas básicas da NI podem ser usadas para a comunicação do Modbus. No nível mais baixo, há uma ampla variedade de bibliotecas de API diferentes disponíveis. Essas bibliotecas normalmente fornecem suporte a mestre e escravo. Os módulos NI LabVIEW Datalogging and Supervisory Control (DSC) e LabVIEW Real-Time fornecem uma ferramenta chamada Modbus I/O server, que oferece algum grau de flexibilidade e facilidade de uso de uma biblioteca de baixo nível. Os servidores de E/S também oferecem suporte a mestre e escravo. Finalmente, o NI OPC Servers é um servidor OPC totalmente funcional, que pode incluir suporte a drivers para mestres Modbus.

Modbus com NI OPC Servers

O NI OPC Servers é uma aplicação autônoma completa de servidor OPC, que pode ser o backbone de um sistema SCADA. Como todos os servidores OPC anteriores ao lançamento do OPC UA, o NI OPC Servers é um programa somente para Windows. Dessa forma, é mais adequado para ser usado como sistema supervisório do que um sistema para o controle de dispositivos escravo em alta velocidade. O NI OPC Servers fornece um amplo conjunto de drivers para permitir a comunicação não somente com dispositivos Modbus, mas também com dispositivos que utilizam diversos protocolos de fornecedores específicos ou protocolos padrão, como o OPC UA. Um sistema típico seria parecido como o mostrado na figura 6.

Figura 6. Essa aplicação SCADA típica usa um conjunto de dispositivos TCP/IP Modbus e um host NI OPC Servers.

Assim como muitos servidores OPC o NI OPC Servers tem recursos para lidar com tipos de dados grandes, ajustes de interpretação de endian para cada dispositivo, recursos de agendamento de requisições e muitos outros recursos que abstraem alguns dos detalhes de baixo nível do Modbus. Após os dados estarem na aplicação, eles podem ser transferidos usando OPC ou OPC UA a data loggers, interfaces homem-máquina (IHM) ou outras aplicações do Windows.

Figura 7. Essa visão estendida de uma aplicação SCADA típica inclui a interação entre bases de dados históricos baseadas em Windows e IHMs.

Modbus com servidores de E/S

Os servidores de E/S do Modbus incluídos no LabVIEW oferecem um meio termo entre a facilidade de uso dos servidores OPC e as poderosas bibliotecas de baixo nível que fornecem controle total sobre o protocolo. Como servidor OPC, servidores de E/S oferecem uma interface simples baseada em configuração para a comunicação com um dispositivo Modbus. Como um servidor OPC, servidores de E/S têm seu próprio sistema de agendamento de requisições e tratam de muitos dos problemas de baixo nível do Modbus, como a configuração endian dos dados. Entretanto, servidores de E/S oferecem uma interface simples no LabVIEW e dão aos programas a capacidade de acessar dados processados (o valor de ponto flutuante de precisão simples nos registradores 45 e 46) ou dados brutos (o inteiro de 16 bits não sinalizado no registrador 45) com rapidez e facilidade. Como um servidor de OPC, servidores de E/S são tipicamente utilizados em aplicações nas quais o controle supervisório é importante, enquanto que os microcontroladores distribuídos são responsáveis pelo controle em alta velocidade do sistema.

Servidor de E/S do mestre Modbus

Servidores de E/S podem ser pensados como um servidor OPC básico executado dentro de sua aplicação. Em seu uso típico, o servidor de E/S do mestre Modbus é implementado como parte de uma aplicação que é diretamente responsável por enviar dados a uma IHM ou base de dados. Em alguns casos, esse nível de envolvimento do desenvolvedor reduz a usabilidade do sistema final — um servidor OPC completo oferece mais escalabilidade. Entretanto, para sistemas menores faz todo sentido eliminar o OPC intermediário e criar uma única aplicação simples para lidar com todo o processo.

Figura 8. Exemplo de aplicação de controle que utiliza um servidor de E/S do mestre Modbus

Servidor de E/S do escravo Modbus

Assim como o mestre do servidor de E/S, os servidores escravo devem apenas ser usados para controle supervisório. Como o servidor de E/S é um processo de segundo plano, o código do usuário não tem como saber quando uma requisição foi recebida. Isso torna os servidores de E/S os mais adequados para aplicações nas quais um equipamento de hardware mais poderoso, como um CPA, é usado para tratar prioritariamente do controle, com atualizações de baixa prioridade de um hub central. Em uma aplicação como essa, os dados de Modbus no servidor de E/S seriam escaneados em cada iteração de um loop de controle e usados para tomar decisões, mas esses dados não seriam usados para comunicações críticas (como E-stop).

Figura 9. Exemplo de aplicação de servidor de E/S de um escravo Modbus

Modbus com APIs de baixo nível

Muitos drivers Modbus de baixo nível estão disponíveis em diversas linguagens. Os módulos LabVIEW 2014 DSC e LabVIEW 2014 Real-Time e posteriores oferecem uma API Modbus de baixo nível para complementar os recursos do NI OPC Servers e servidores de E/S do Modbus

Com esses drivers, você pode definir explicitamente o que acontece quando uma requisição do Modbus é enviada ou recebida. Eles também oferecem normalmente um maior desempenho máximo que os drivers de nível mais alto. Em troca, você tipicamente precisa escrever uma grande quantidade de código de processamento de dados, o que permite que sua aplicação interaja de maneira efetiva com outros dispositivos do sistema. A funcionalidade e o comportamento desse código variam, dependendo de o dispositivo ser mestre ou escravo.

A figura 10 mostra como um mestre de baixo nível, o LabVIEW Modbus API, oferece um controle rígido sobre requisições específicas enviadas e a temporização dessas requisições.

Figura 10. Um mestre de baixo nível controla a temporização e o conteúdo de uma requisição de leitura.

Mestre de baixo nível

Quando usado como mestre, um CPA de alto desempenho que utiliza um driver Modbus de baixo nível pode ser usado para controlar com eficácia um sistema que exija alta velocidade e confiabilidade. Como as requisições são geradas diretamente pelo código da aplicação, eventuais falhas são também informadas e reconhecidas de imediato, permitindo que o sistema entre em um estado seguro ou execute alguma ação corretiva.

Além disso, a aplicação tem controle rígido sobre exatamente quando os dados são transmitidos, o que permite que o código da aplicação utilize a largura de banda da rede de maneira eficaz. Em vez de varrer tudo na mesma taxa, é possível utilizar taxas diferentes para dispositivos escravo diferentes. Se necessário, a aplicação poderia até mesmo utilizar percursos de rede totalmente diferentes (duas conexões TCP, diferentes linhas seriais) para atender os requisitos de desempenho da aplicação.

A figura 11 mostra um exemplo de aplicação, no qual o desenvolvedor escolheu utilizar um loop supervisório baseado em eventos de baixa velocidade, similar ao que você teria em um sistema SCADA baseado em Windows. Em um processo paralelo, uma malha de controle determinístico é usada para a comunicação com a bomba em alta velocidade.

Figura 11. Esse exemplo de aplicação de CPA com o NI CompactRIO utiliza um driver de mestre Modbus de baixo nível.

Além disso, devido à alta flexibilidade desses drivers de baixo nível, você pode usá-los para recriar alguns dos recursos de uma interface de alto nível, como um servidor de E/S, ainda mantendo o controle sobre as prioridades que são tão críticas para o comportamento do sistema. Nesse exemplo de aplicação, uma malha de comunicações foi desenvolvida para tratar do agendamento de todas as requisições e respostas de forma que atenda as necessidades específicas da aplicação. Uma malha de controle determinístico poderia então ser definida, com o conhecimento de quando dados novos estarão disponíveis no loop de comunicações, o que oferece muitos dos benefícios do primeiro sistema sem as desvantagens potenciais das falhas de comunicação.

Figura 12. Essa aplicação de controle customizado coloca as comunicações para um loop secundário para reduzir o impacto de falhas de comunicações e manter os requisitos de desempenho do sistema.

Escravo de baixo nível

Devido às dificuldades de se lidar com o lado do servidor de um protocolo de requisição-resposta diretamente no código de aplicação, muitas implementações de escravo Modbus oferecem um processo de segundo plano que cuida das respostas às requisições do mestre. Esse processo tem princípio similar ao comportamento dos escravos de servidor de E/S.

 

Entretanto, em um driver de baixo nível, é típico e esperado que o código da aplicação possa ajustar o comportamento desse processo para atender as necessidades do sistema. Em alguns casos, escravos de baixo nível fornecem um evento que pode ser tratado por um código de aplicação. Isso proporciona a você a capacidade de fornecer resposta imediata aos dados vindos do mestre, sem precisar verificar se ocorreram mudanças na memória do dispositivo.

Figura 13. Esse driver de escravo de baixo nível usa eventos para indicar alterações nos dados em um modelo de dados compartilhado.

Em casos mais avançados, o driver de baixo nível pode ser escrito de maneira tal que o código da aplicação possa ser introduzido diretamente no modelo de dados da API do escravo. Dessa forma, em vez de simplesmente fazer uma leitura de uma posição de memória, o escravo pode ser capaz de responder às requisições do mestre de maneira específica para a aplicação. Isso proporciona muitos dos benefícios fornecidos pelo mestre de baixo nível, sem exigir a criação de um servidor no código da aplicação.

Figura 14. Essa aplicação escravo de baixo nível usa um modelo de dados customizado para interagir diretamente com o código de controle determinístico de maneira específica para o sistema.

Benefícios e desvantagens do Modbus

Benefícios

  • Bastante utilizado, com muitas implementações disponíveis
  • Flexível
  • Especificação disponível livremente
  • Sua arquitetura de requisição-resposta fornece acknowledgement no nível da aplicação

Desvantagens

  • O paradigma de requisição-resposta subutiliza a rede ou complica o código da aplicação
  • Alto consumo de recursos da rede
  • O tamanho limitado dos pacotes aumenta o consumo de recursos da rede e reduz a taxa máxima de polling
  • O streaming de dados é difícil ou impossível
  • Não há suporte nativo a tipos de dados além de bits e inteiros de 16 bits não sinalizados
  • Não incorpora recursos de segurança
  • Requer arquitetura de polling

O Modbus é e continuará a ser um protocolo bastante usado, apesar das muitas tecnologias novas introduzidas nos últimos anos. Embora tenha limitações que você deve conhecer, sua natureza simples e flexível o torna uma excelente escolha para alguns projetos.

Referências relacionadas

Especificação do protocolo de aplicações Modbus

Por que o OPC UA é importante

Biblioteca Modbus para Java

Recursos técnicos para Modbus