quarta-feira, 23 de março de 2011

Modelos de Comunicação - Tags, Drivers e Meios Físicos

Vamos falar mais um pouco sobre modelos de comunicação, abordando os temas Tags, Drivers e Meio Físico. Essas definições são importantes pois impactam a maneira como os supervisórios realizam a comunicação com os equipamentos de campo. 

Meio Físico: meio físico é o tipo de ligação entre um equipamento e o computador onde o software supervisório é executado. Entre os meios físicos mais comuns estão:


  • Portas RS-232: porta de comunicação mais comum em computadores desktop, raramente são vistas nos notebooks atuais. Esse meio de comunicaçaõ serve para ligar um mestre a um escravo, ou seja, um equipamento ou software a outro equipamento ou software. Normalmente, quando se usa uma porta RS-232 o supervisório é o mestre na comunicação, ou seja, é dele que partem os questionamentos que chegam ao PLC. Redes que utilizam esse tipo de porta têm alcance limitado (a alguns metros, dependendo do ambiente); 
  • Portas RS-485: permitem a ligação entre dois ou mais equipamentos, através de um varal de dois fios. Essa rede pode ser usada também para aumentar o alcance de uma rede RS-232, utilizando-se nas terminações um ou dois conversores RS-232/RS-485. Cabeamento simples e longo alcance, mas os computadores não têm portas RS-485 (é necessário utilizar conversores);
  • Rede Ethernet: os modelos mais recentes de PLCs costumam trazer portas de comunicação Ethernet, o mesmo padrão físico utilizado em redes de computadores. Isso é interessante, visto que todos os computados vendidos atualmente dispõem de uma porta desse tipo. Mas para sistemas mais antigos, essa opção é inexistente;
  • Meios físicos dedicados: alguns protocolos e equipamentos exigem meios físicos dedicados. Por exemplo, os equipamentos da Siemens exigem placas especiais que criam meios físicos próprios para os protocolos criados pela empresa. Outro fabricante que costuma usar essa abordagem é a Allen-Bradley/Rockwell.  


 Tags: é a menor unidade de comunicação de um sistema supervisório e reflete, normalmente, um equipamento ou um conjunto deles (quando associados). Um tag, reflete, por exemplo, uma bomba (ligada ou desligada), a velocidade dessa bomba, as suas condições de alarmes. A forma como um tag é construído e acessado difere entre os supervisórios. O importante é poder diferenciar que existem dois tipos de tags que influenciam na especificação de um supervisório: tags de comunicação e tags internos. 


  • Tags de Comunicação: São aqueles usados para resgatar ou parametrizar informações em um equipamento externo (PLC, controladores de temperatura, etc). 
  • Tags Internos: são aqueles que são usados exclusivamente no supervisório, para contagens, cálculos diversos, entre outras funções. 

A maneira de construir esses dois tipos de tags será analisada posteriormente, quando cada supervisório for comentado em separado. 

Drivers de Comunicação: como já comentado anteriormente, são os responsáveis por implementar a comunicação entre um supervisório e um equipamento, implementando um protocolo de comunicação comum aos dois lados. Esses drivers normalmente trazem limitações que devem ser observadas. Por exemplo, em uma rede Ethernet, quantos equipamentos conseguirei acessar se cada um deles tiver um IP diferente. Ou então, qual a máxima porta RS-232 do micro que consigo acessar usando esse driver.

Essas questões relacionadas aos drivers, implicam na especificação da licença do seu supervisório, e conseqüentemente, o custo final da licença de runtime.


Links interessantes


terça-feira, 15 de março de 2011

Modelos de Comunicação

A principal função de um sistema supervisório é exibir ao operador de um processo os valores atuais de variáveis importantes da planta a ser operada e ao mesmo tempo, permitir interação com esse processo através de comandos e setpoints. Todo os recursos restantes são consequência de como a comunicação é executada. 

Colocando dessa maneira, existe uma questão que se deve analisar ao pensar em sistemas supervisórios: como eles são capazes de se comunicar com sistemas em campo? Como é possível se conectar a diferentes equipamentos e medidas e manter uma interface única com o operador? Como um sistema pré-formatado consegue acessar novos equipamentos instalados na rede industrial, sem que sejam necessários grandes períodos e volumes de dinheiro investido nessa atualização?

A resposta é comum a todos os supervisórios do mercado: existem módulos responsáveis por essa comunicação que podem ser integrados ao sistema supervisório, sejam eles desenvolvidos pela própria fabricante do supervisório ou por fabricantes que adotam padrões abertos de comunicação. 

Sendo assim, para compreendermos o que chamei de "Modelo de Comunicação" vou pontuar alguns termos relacionados ao processo de troca de dados entre um supervisório e equipamentos de campo. 

Modelo de Comunicação: processo de configuração de um sistema supervisório para extrair dados de um equipamento de campo (seja ele um CLP, uma UTR, um controlador de temperatura, uma rede de dispositivos, etc). Esse modelo varia de supervisório para supervisório e é um dos pontos mais importantes no aprendizado de qualquer ferramenta desse tipo; 

Protocolo de Comunicação: conjunto de regras a serem seguidas para que a comunicação entre dois pontos aconteça. Na área industrial os protocolos mais comumente utilizados são Modbus, Profibus, MPI, DeviceNet, entre outros. Esses protocolos podem ser de domínio público (ou protocolos abertos) ou de domínio privado (protocolo fechado). Nesse último caso, é necessário pagar royalties para os donos da tecnologia de forma a ter acesso às suas definições de protocolo;

Definições de protocolos: normalmente englobam: tipos de meio físico, tipos de variáveis existentes, quantidades de mestres na rede, valores válidos para perguntas, sinalização de erros de comunicação ou perdas de mensagens, tipos de pontos de verificação existentes na mensagem, etc;

Driver de Comunicação: em todos os supervisórios existem os drivers de comunicação, que são módulos desenvolvidos com a função de permitir a comunicação com um equipamento de campo em um protocolo específico. Algumas características dos drivers de comunicação:
- São dependentes do supervisório: isso significa que não conseguem trabalhar sozinhos, pois devem ser parametrizados pelo supervisório;
- Não são intercambiáveis entre supervisórios de diferentes fabricantes: o modelo de desenvolvimento de um driver de comunicação varia de um supervisório para outro. Dessa forma, é virtualmente impossível que um driver criado por um fabricante seja compatível com o de outro fabricante. 
- São compatíveis entre versões diferentes de supervisórios de um mesmo fabricante: normalmente, ao substituir uma versão antiga por uma mais atual, é possível migrar os aplicativos para a nova ferramenta. E isso é repetido com os drivers, que costumam manter compatibilidade com drivers antigos nas novas ferramentas;
- São softwares especializados: normalmente um driver de comunicação implementa um único protocolo de comunicação. Mais que isso, quanto mais específico for o driver, mais fácil será sua configuração. Mas será mais difícil de manter esse driver atualizado caso ocorram alterações no protocolo ou equipamento sendo lido;

Kit de desenvolvimento de drivers: alguns fabricantes permitem que se utilizem esses kits para a implementação de novos protocolos, mas a responsabilidade por essa criação é inteiramente do cliente;

Protocolo OPC: é um padrão de comunicação que substitui a necessidade de um driver de comunicação, pois um software (servidor OPC) faz a tarefa de comunicar com os equipamentos de campo e traduzir essa comunicação para o padrão OPC. Esse protocolo será discutido em um post ainda a ser escrito;

Em resumo, a idéia aqui não é discutir a fundo o funcionamento das redes industriais existentes, mas apresentar nos posts subsequentes o modo de se configurar a comunicação em diferentes supervisórios. Pelo menos 3 famílias serão abordadas (e se possível, mais delas serão acrescentadas com o tempo): Elipse E3, Afcon Pulse e Indusoft. São três famílias de software existentes há mais de 10 anos, uma brasileira e duas estrangeiras, com uma grande abrangência no mercado brasileiro. 

Links interessantes
Protocolo Modbus: www.modbus.org
Protocolo Profibus: www.profibus.org
Protocolo OPC: www.opcfoundation.org

sexta-feira, 11 de março de 2011

Novos posts

Em breve, novos posts deverão sair da lista de intenções.

Assuntos variados, como programação em PLCs Dakol, modelos de comunicação de diferentes supervisórios, truques para alarmes dinâmicos no Indusoft, truques e dicas sobre Pulse e P-CIM, módulos e PLCs ADAM, entre outras questões que podem ajudar a quem lida com automação.

Coming soon!