Este programa foi marcado como "Limpo" pelo anfitrião.
01 Introdução
Este é o sexto episódio de uma série de oito partes.
02
No episódio anterior, analisamos módulos de entrada e saída (I/O), o que eles são, como funcionam e a função que desempenham no sistema.
Também discutimos sistemas de segurança de máquinas e também as alegações feitas por certas pessoas sobre segurança cibernética e segurança industrial.
Neste episódio, vamos explorar a rede PLC, juntamente com uma análise detalhada de um protocolo de rede, o Modbus.
03 Tipos de Redes
Redes PLC são divididas em três categorias amplas, com base no propósito da rede.
Estas categorias são
• PLC para IO
• PLC para PLC
• e PLC para PC ou Computador Pessoal.
Há uma grande sobreposição entre elas, então não espere que elas caiam em gavetas discretas.
04 Uma Multidão de Protocolos
Lógica, você pensaria que as vantagens da interoperabilidade seriam tão grandes que haveria apenas alguns protocolos de rede e todos os usariam.
A realidade é o oposto.
Existem tantos protocolos que eu não vou tentar listar todos eles.
A automação industrial é um mercado que está firmemente sob o controle dos fornecedores, não dos clientes, e os fornecedores valorizam o bloqueio do cliente em detrimento dos benefícios do usuário.
05
Em vez disso, vou me concentrar no desenvolvimento tecnológico ao longo do tempo para que você possa entender como terminamos onde estamos hoje.
Vou ilustrar isso com alguns protocolos de alguns fornecedores antes de entrar em detalhes sobre uma família específica de redes.
06 Conexão Serial Ponto a Ponto Básica
As primeiras e mais básicas redes eram simples links serial ponto a ponto.
Você pode argumentar que uma conexão ponto a ponto não é uma rede, mas, neste caso, é o início da rede com PLC, e um dos protocolos de rede industrial mais importantes de hoje é um descendente direto de um dos primeiros protocolos ponto a ponto.
07
Esses links ponto a ponto inicialmente abordaram duas questões principais.
Uma vez que os computadores eram usados para executar o software necessário para programar PLCs, era necessário um meio de baixar o programa para o PLC e depurar o programa do PLC, e isso acontecia através de uma ligação serial ponto a ponto.
08
O outro era que havia vários instrumentos e dispositivos movidos por microprocessador onde era desejável permitir que o PLC se comunicasse com eles para obter leituras, ajustar pontos de ajuste e, de outra forma, trocar dados.
Uma ligação serial era o meio óbvio de implementar isso.
Os meios físicos e elétricos eram geralmente RS-232, RS-422 ou loop de corrente serial.
09 RS-232
O RS-232 deve ser familiar à maioria dos ouvintes.
A característica notável do RS-232 é que os sinais de dados e controle eram referenciados ao terra, ou "single ended", como também é conhecido.
Embora fosse simples, isso impunha limitações ao comprimento do cabo e era um pouco problemático quando o PLC e o outro dispositivo estavam conectados a fontes de energia diferentes e não tinham um terra comum.
10 RS-422
O RS-422 difere do RS-232 no aspecto de que os sinais são diferenciais, em vez de referenciados a um terra comum.
As linhas de sinal vêm em pares, e é a diferença de tensão dentro do par, em vez de comparada ao terra, que define os zeros e uns.
Isso permite taxas de dados mais altas, até 10 Mbps a distâncias muito curtas, e cabos muito mais longos, até 1.200 metros, ao custo de taxas de dados mais baixas.
11
O RS-422 também permitiu que múltiplos receptores fossem conectados aos mesmos fios, embora apenas um driver fosse permitido.
Isso permitiu que múltiplos dispositivos "ouvissem" o mesmo conjunto de fios, embora apenas um nó pudesse "falar".
12 Loop de Corrente Serial ou TTY
Alguns PLCs, particularmente os da Siemens, usavam um loop de corrente serial em vez de RS-232 ou RS-422.
Isso é conhecido como interface TTY, pois surgiu com os teletipos.
Você pode estar familiarizado com o termo TTY sendo usado para descrever janelas de terminal em sistemas operacionais semelhantes ao Unix.
13
Isso é devido aos computadores iniciais adotarem equipamentos de teletipo prontos para uso para fornecer terminais de operador.
Ele usava diferenças de corrente em vez de diferenças de tensão para transmitir sinais.
Quando 20 mA estão fluindo, isso indica um "1".
Quando 0 mA estão fluindo, isso indica um "0".
Loops de corrente serial podem operar de forma confiável em distâncias maiores do que o RS-232, até um quilômetro em taxas de dados mais baixas.
14 Protocolos Tipicos
Uma norma elétrica como RS-232 permite transmitir zeros e uns através de um fio.
No entanto, ela não define o que significam esses zeros e uns.
Isso requer um protocolo de dados.
15
Cada fabricante tendia a criar seu próprio protocolo.
A Modicon desenvolveu o Modbus.
A Allen Bradley criou o DF1.
A Siemens criou o 3964R e o RK512.
Outros fabricantes geralmente tinham os seus próprios, cada um.
Discutirei o Modbus em detalhes mais tarde, mas, além disso, não entrarei em detalhes sobre esses protocolos aqui.
Serial Multi-drop 16
Serial ponto a ponto, até mesmo o RS-422, que permitia múltiplos receptores, funcionava, mas sofria de várias limitações.
A mais óbvia é que, se você quisesse comunicação de duas vias, precisava de um cabo separado entre cada ponto e um porta de comunicação dedicada ou um multiplexador de portas.
À medida que o sistema se torna maior e mais complexo, isso se torna desconfortável.
17 RS-485
O ideal seria uma maneira de permitir que vários dispositivos serial compartilhassem um link de comunicação serial.
A solução para isso é o RS-485.
Assim como o RS-422, utiliza sinalização diferencial.
Também permite múltiplos receptores nos mesmos fios.
Diferente do RS-422, o RS-485 permite múltiplos transmissores.
Até 32 nós podem ser conectados ao mesmo cabo RS-485.
Este limite é determinado pelas características elétricas do cabo e dos chips transmissor e receptor.
18 Novos Protocolos
Fabricantes de PLC adaptaram seus protocolos existentes ou criaram novos.
A Allen Bradley adaptou seu protocolo serial DF1 em Data Highway, Data Highway Plus e Data Highway 485.
A Siemens desenvolveu o L1, Profibus e Profibus-DP.
19 Mestre Escravo vs. Multi-Mestre
Muitos desses redes eram sistemas estritamente mestre-escravo.
Um nó seria designado como o mestre da rede, e ele consultaria cada um dos outros nós, os escravos.
Esse tipo de configuração se adequava a muitas aplicações onde, geralmente, se queria permitir que um PLC atuasse como o mestre da rede e consultasse vários outros dispositivos localizados a uma certa distância.
20
Uma aplicação inicial disso foi permitir que racks de entrada/saída fossem localizados a uma certa distância do CPU do PLC.
Isso, por sua vez, permitiu que os racks de entrada/saída em máquinas muito grandes ficassem mais próximos dos dispositivos aos quais estão conectados, como interruptores, válvulas ou relés, reduzindo assim a quantidade de cabos e fios necessários.
21
O desenvolvimento posterior disso produziu entrada/saída na forma de blocos que poderiam ser montados diretamente na máquina sem exigir um invólucro elétrico separado.
Esses poderiam ser integrados diretamente em bancos de válvulas, que são coleções de válvulas compartilhando um plenum comum.
22
No entanto, isso tinha limitações quando o objetivo era conectar múltiplos PLCs para coordenar entre si.
Com um sistema mestre-escravo estrito, um dos PLCs teria que ser designado como mestre e o programa do PLC teria que lidar com a encaminhamento de mensagens entre os outros PLCs.
23
A solução para isso foi uma rede multi-mestre.
O cabeamento físico ainda seria tipicamente RS-485 ou alguma variação proprietária disso.
O protocolo, no entanto, teria que ser adaptado para permitir múltiplos mestres.
Isso geralmente era algum tipo de protocolo de passagem de token, onde o "token", que era uma peça de dados designando o mestre, seria passado de nó para nó para que cada nó tivesse sua vez de ser mestre temporariamente.
24 Redes de Nível de Dispositivo
A redução nos cabos e fios e as economias de custo resultantes em termos de mão de obra de instalação significaram que havia um incentivo adicional para estender as redes até dispositivos individuais, como switches ou válvulas únicas.
Não vou entrar em muitos detalhes sobre esses, mas em vez disso, apenas menciono alguns exemplos comuns.
Houve alguns sistemas puramente proprietários, como o Siemens ASI.
25
Também havia vários sistemas baseados no CAN, que significa Rede de Área de Controlador.
O CAN vem da indústria automotiva, e foi projetado para conectar várias partes do seu carro.
Provavelmente você tem uma rede CAN no seu carro, sem perceber.
26
A indústria de automação industrial adotou os padrões CAN e chipsets prontos para uso e adicionou seus próprios protocolos em cima para criar redes de nível de dispositivo.
Alguns exemplos típicos disso são o Canbus e o Allen Bradley Devicenet.
O Surgimento do Ethernet
A rede apareceu no chão da fábrica muito antes de se tornar comum nos escritórios da fábrica.
Isso, combinado com a natureza altamente fragmentada da indústria de automação industrial, significou que era difícil alcançar economias de escala na fabricação de hardware de rede.
Isso também significou que cada empresa teve que dedicar esforços de P&D para desenvolver coisas que duplicavam funcionalidades já existentes em outros lugares.
28
Enquanto isso, a tecnologia de rede se espalhou nos ambientes de escritório, e gradualmente se consolidou em torno do Ethernet e TCP/IP.
A enorme escala desse mercado e os padrões bem desenvolvidos significaram que os custos caíram significativamente devido às economias de escala e à competição entre os fornecedores.
29
Vendo esse desenvolvimento na indústria de TI, as empresas de automação decidiram adotar os padrões de rede de TI em sua totalidade, pelo menos no que diz respeito ao cabeamento físico e aos protocolos de baixo nível.
Elas ainda podiam usar seus protocolos de nível de aplicação, mantendo o bloqueio de fornecedor.
30
Alguns exemplos típicos desses protocolos são Siemens Profinet, Allen Bradley Ethernet/IP e Modbus/TCP, todos os quais foram adaptações de protocolos existentes para operar em Ethernet.
31 Resumo até o momento
Até agora, neste episódio, abordamos as origens da rede na automação industrial, começando com
ligações série ponto a ponto,
redes série mestre multidrop,
redes série multi-mestre multidrop,
até a adoção do Ethernet.
Neste ponto, você deve ter uma ideia do contexto em que a rede opera na indústria e para que é usada.
Em seguida, discutiremos em detalhes um protocolo específico, o Modbus.
32 Modbus
Contexto
O Modbus foi criado pela Modicon em 1979.
Se lembrarem dos episódios anteriores, a Modicon, agora parte da Schneider Electric, foi uma das primeiras empresas a desenvolver um PLC.
33
A Modicon publicou a especificação para permitir que terceiros a implementassem, tornando-a um dos poucos padrões de automação industrial verdadeiramente abertos e sem royalties.
Digo "verdadeiramente aberto", porque a indústria de automação adora colocar a palavra "aberto" em suas marcas, embora para eles "aberto" signifique solicitar uma licença, ser aceito por eles, pagar royalties ou taxas de associação, e pagar pela certificação como fornecedor aceito.
34
Qualquer pessoa, no entanto, pode baixar a especificação Modbus, implementá-la e fazer o que quiser com ela.
Existem várias implementações gratuitas de bibliotecas Modbus.
35 Versões ou Variantes do Modbus
Existem várias variantes do Modbus, diferenciadas pela mídia física ou aplicação.
Estes são
• Modbus RTU
• Modbus ASCII
• Modbus Plus
• e Modbus TCP
36 Modbus RTU
Esta é a versão original do Modbus, que é um protocolo de comunicação serial ponto a ponto.
A parte RTU do nome significa "Unidade Terminal Remota", que é o nome de um dispositivo industrial que possui alguma interface serial ou de rede e atua como interface para instrumentos de campo.
Um exemplo típico pode ser um medidor de fluxo em uma tubulação.
Este protocolo foi amplamente implementado por terceiros.
37
O formato de dados serial é:
• 8 bits binários
• 1 bit de início
Oito bits de dados, o bit menos significativo primeiro.
Um bit de paridade.
Um bit de parada.
Um campo de verificação de redundância cíclica de 16 bits é incluído na mensagem.
38 Modbus ASCII.
O Modbus RTU é projetado como um protocolo serial e possui especificações de tempo por bit muito precisas.
No entanto, isso significou que ele não funcionaria de forma confiável em links de rádio que atendem a sistemas de água, campos de petróleo e outras aplicações distribuídas.
Além disso, o Modbus RTU é um protocolo binário, e isso significou que alguns valores podem ser interpretados como códigos de controle pelo hardware transmissor ou receptor.
39
A solução para isso foi o Modbus ASCII.
Este enviava dados em formato ASCII, com cada byte convertido em dois bytes hexadecimais.
As restrições de temporização serial foram relaxadas para efetivamente o que o hardware toleraria.
40
O formato serial é:
• Hexadecimais, caracteres ASCII 0-9 e A-F
• 1 bit de início
• 7 bits de dados, o bit menos significativo enviado primeiro
• 1 bit de paridade
Um bit de parada.
41
Um ponto e vírgula é usado para sinalizar o início de uma nova mensagem, e uma combinação de retorno de carro e quebra de linha marca o fim de uma mensagem.
Uma verificação de redundância longitudinal foi incluída como dados codificados em ASCII e posicionada logo antes dos caracteres de término.
42
Como as mensagens Modbus ASCII ocupavam o dobro de bytes em comparação com o Modbus RTU, elas podiam transmitir dados apenas à metade da velocidade. Isso limitava o uso do Modbus ASCII apenas às aplicações para as quais foi projetado, ou seja, links de comunicação por rádio.
43 Modbus Plus
Modbus Plus é uma adaptação do Modbus para funcionar em uma rede serial multidrop RS-485.
No entanto, nunca fez parte da especificação Modbus e era propriedade da Modicon.
Não vou me dar ao trabalho de descrever mais nada sobre isso.
44 Modbus TCP
O Modbus TCP é uma versão ligeiramente modificada do Modbus RTU, projetada para ser tunelada sobre TCP/IP, especialmente em Ethernet.
Isso foi amplamente adotado, e até mesmo alguns dos grandes fornecedores que tinham seus próprios protocolos ofereciam isso como uma alternativa para permitir a comunicação com dispositivos aos quais, de outra forma, não conseguiriam se comunicar.
45
O Modbus TCP utiliza a porta 502.
Esta é uma porta oficialmente atribuída, e se você consultar a lista oficial de portas TCP, encontrará o Modbus listado como 502, assim como o HTTP é a porta 80 e o e-mail SMTP é a porta 25.
46
O comitê de normas do Modbus tomou a decisão consciente de adotar as normas e convenções da indústria de TI na medida do possível e simplesmente se referir a elas, em vez de manter um conjunto único de normas e convenções da indústria de automação.
Isso foi por várias razões práticas.
47
Uma delas era que havia muito poucas pessoas envolvidas no trabalho de normas e elas estavam procurando maneiras de reduzir a quantidade de trabalho que precisavam fazer.
Outras pessoas que trabalham na indústria acharam a duplicação do vocabulário muito confusa e difícil de manter em ordem, para entender o que, em termos de TI, se traduz em que na linguagem da automação industrial.
48
Uma das consequências disso foi que os termos de comunicação serial mestre-escravo foram substituídos pelos termos de rede de TI cliente-servidor.
Como resultado, vou usar os termos Modbus TCP no restante deste episódio, pois é a forma de Modbus que você provavelmente encontrará hoje em dia.
49 Modbus UDP
Esta era uma versão não oficial do Modbus TCP que simplesmente enviava os dados sobre UDP em vez de TCP.
Não houve alteração no formato de dados Modbus enviado.
Foi feito principalmente para mostrar que isso poderia ser feito.
A suposta vantagem era a menor sobrecarga e latência do UDP em comparação com o TCP, mas não foi o suficiente para gerar muito interesse.
50 Extensões Proprietárias Modbus
Várias empresas criaram suas próprias extensões Modbus, especialmente para estender o Modbus RTU.
Essas foram usadas apenas em algumas aplicações de nicho.
Uma das mais comuns foi o Modbus Enron, criado pela empresa Enron nos EUA.
Isso adicionou uma extensão de dados de 32 bits ao protocolo.
51 Modelo de Dados Modbus
O modelo de dados Modbus é centrado em uma tabela de dados estilo PLC.
É um array de memória e um conjunto de comandos para ler e escrever nessa memória.
52
Existem quatro tipos de memória.
• Entradas Discretas
• Espiras
• Registradores de Entrada
• Registradores de Armazenamento
53
Podem existir até 65.536 endereços de memória de cada um dos quatro tipos.
Cada tipo de memória pode ter de zero ao número máximo de elementos, a implementação decide quantos endereços ter.
Os endereços de memória começam em 1, de modo que o número "1" se refere ao primeiro endereço.
Endereços enviados de fato pelo cabo começam em "0".
54
Entradas discretas e registros de entrada são memória somente de leitura.
Enquanto bobinas e registros de retenção são memória de leitura e escrita.
Entradas discretas e bobinas são bits únicos.
Ou seja, cada endereço representa um bit de memória.
55
Registros de entrada e de retenção são palavras de 16 bits.
Ao serem transmitidos pela rede, as palavras são no formato "big endian".
Ou seja, o byte superior de uma palavra é enviado primeiro e o byte inferior é enviado em segundo lugar.
56
É permitido sobrepor diferentes tipos de memória.
Por exemplo, a memória de bobinas pode ser sobreposta na memória de registro de retenção, de modo que, por exemplo, as primeiras 16 bobinas também sejam o primeiro registro de retenção, etc.
57 Funções Modbus
Modbus TCP é um protocolo cliente-servidor.
O cliente envia um comando solicitando ler ou escrever memória, e o servidor responde com um reconhecimento ou com outra mensagem contendo os dados solicitados ou um código de erro.
Cada comando é conhecido como uma "função".
Cada função é referenciada por um número.
58
Não listarei todas as funções, apenas as mais comumente usadas.
Uma instância Modbus não precisa implementar todas as funções possíveis, apenas as que ela utiliza.
59
• A função 1 é "ler bobinas".
• A função 2 é "ler entradas discretas".
• A função 3 é "ler registradores de retenção".
• A função 4 é "ler registradores de entrada".
• A função 5 é "escrever bobina única".
• A função 6 é "escrever registrador único".
• A função 15 é "escrever múltiplas bobinas".
16 permite múltiplos registros.
60
Os limites na quantidade de elementos de dados que podem ser utilizados em uma única transação para cada comando são os seguintes.
Função 1 é de 1 a 2000.
2 - de 1 a 2000.
3 - de 1 a 125.
4 - de 1 a 125.
5 - Não aplicável (NA).
6 - Não aplicável (NA).
De 15 a 1 até 1968
De 16 a 1 até 123
Formato de Mensagem Modbus
A mensagem Modbus completa é chamada de ADU, ou Unidade de Dados de Aplicação.
Dentro do ADU está a Unidade de Dados do Protocolo, ou PDU.
O PDU contém o comando Modbus e os dados associados.
O ADU contém informações adicionais, que podem variar dependendo do tipo de Modbus.
Aqui, vou me limitar a falar sobre Modbus TCP.
Cabeçalho MBAP de 62 MB
No Modbus TCP, o PDU é precedido pelo Cabeçalho MBAP, que é o Cabeçalho do Protocolo de Aplicação Modbus.
Ele tem o seguinte formato.
• Os primeiros 2 bytes são o Identificador de Transação.
• Os próximos 2 bytes são o Identificador de Protocolo.
• Os 2 bytes seguintes são o Comprimento.
• O próximo byte é o Identificador de Unidade.
63
O Identificador de Transação é simplesmente um inteiro que será copiado da solicitação do cliente para a resposta do servidor.
O cliente pode examinar isso para combinar respostas com solicitações.
Isso é realmente útil apenas se houver uma chance de que as respostas possam ficar fora de ordem.
64
O Identificador de Protocolo é sempre zero e indica que o protocolo é Modbus.
O comprimento é o número de bytes seguintes, incluindo o identificador de unidade e os campos de dados.
65
O Identificador de Unidade é usado para permitir que mensagens passem entre Modbus TCP e Modbus serial, como Modbus RTU.
Por exemplo, um gateway na rede Modbus TCP pode ter vários dispositivos Modbus RTU conectados a ele.
O Identificador de Unidade, nesse caso, corresponderia ao endereço da linha serial ou ao número da porta serial da unidade Modbus RTU para a qual a solicitação é direcionada.
66
O campo de comprimento é definido pelo cliente no caso de uma solicitação, ou pelo servidor no caso de uma resposta.
Todos os outros campos são simplesmente copiados da solicitação para a resposta pelo servidor.
67 Exemplo - Função 1
Aqui está um exemplo de uma mensagem PDU Modbus para a função 1, leitura de relés.
68
A solicitação tem o seguinte formato.
• O primeiro byte é o código de função, neste caso é "1".
• Os próximos dois bytes contêm o endereço inicial na faixa de 0 a 65535.
• Os próximos dois bytes contêm a quantidade de relés, que pode estar na faixa de 1 a 2000.
69
A resposta está no seguinte formato.
O primeiro byte é o código de função, neste caso, é "1".
O segundo byte é o número de bytes de dados seguintes.
Em seguida, uma série de bytes contendo os dados, com 8 enrolamentos empacotados em cada byte, pelo número de bytes necessários.
Qualquer bit não utilizado no último byte é preenchido com zeros.
70
Se houver um erro, a resposta estará no seguinte formato.
O primeiro byte seria o código de função com 128, ou 80 em hexadecimal, adicionado a ele. Isso define efetivamente o bit mais alto no byte.
O segundo byte conterá um código de erro indicando o que foi o erro. Isso será 1, 2, 3 ou 4.
Códigos de Exceção 71
Em caso de erro na solicitação, o código de função é retornado com 128 adicionado, definindo o bit mais alto.
Códigos de função válidos são todos abaixo de 128, então qualquer resposta que comece com 128 ou mais indica um erro.
Após o código de erro virá o código de exceção.
1 - Código de função não suportado.
2 - Endereço fora do alcance.
3 - Quantidade fora do alcance, ou valor inválido (no caso das funções 5 e 6).
4 - Outro erro.
Todos os valores de palavras possíveis são válidos no caso da função 6 (que é escrever registro único), então tecnicamente a exceção 3 não pode ocorrer, mas está especificada de qualquer maneira.
72
Como você pode ver, o Modbus TCP é um protocolo de aplicação muito simples e bem definido, adequado para controle industrial.
Estes comandos básicos farão quase tudo o que é necessário na maioria das aplicações.
Como este protocolo está disponível gratuitamente e é fácil de implementar, tem ampla suporte, especialmente entre fornecedores menores ou especializados.
73 Conclusão
Neste episódio, fizemos uma breve análise da rede PLC, juntamente com uma análise detalhada de um protocolo de rede, o Modbus.
No próximo episódio, analisaremos:
• Computadores pessoais na indústria, incluindo hardware especializado,
• Sistemas SCADA,
Sistemas HMI,
Sistemas de teste e medição,
74
Este foi o sexto episódio de uma série de oito partes.