Sistemas Supervisórios de Processos

Neste post serão abordados conceitos básicos sobre sistemas supervisórios de processos e sua utilidade no âmbito da automação industrial.

Introdução

Um Sistema Supervisório é um software que funciona geralmente na plataforma Windows, destinado a construir telas com um desenho esquemático do processo que está sendo controlado por um PLC ou outro sistema de controle, permitindo a um operador verificar
de forma gráfica, os valores das variáveis do processo, observar tendências de variação, verificar os estados de equipamentos, etc., possibilitando também o envio de comandos e parâmetros para o processo, inerentes à sua operação.

As telas construídas em um sistema supervisório são chamadas geralmente de telas sinóticas, nome este herdado dos sinóticos elétricos utilizados durante muitos anos na indústria (e por incrível que pareça, ainda presente em algumas indústrias), onde se tinha um grande desenho do sistema controlado, com informações visuais através de sinaleiros luminosos, instrumentos de medição analógicos ou digitais, sinaleiros sonoros, registradores gráficos em papel, bem como botões, potenciômetros, chaves do tipo thumbwheel e outros métodos de ação sobre o processo controlado. Um exemplo de um sinótico elétrico é mostrado na Figura 1.

Figura 1 – Antigo sinótico elétrico (Imagem disponível neste link)

A Figura 2 apresenta uma tela sinótica de um sistema supervisório.

Figura 2 – Tela sinótica de um sistema supervisório (Fonte: Elipse Software)

Os sistemas supervisórios, em conjunto com os PLCs formam o chamado sistema SCADA – Supervisory Control and Data Acquisition, ou Sistemas Controle e Aquisição de Dados.

Princípio de operação

O princípio de operação de um sistema supervisório é relativamente simples. Este software faz a aquisição de dados no campo (valores instantâneos das variáveis de processo, tais como temperatura, vazão, velocidade, estado de um equipamento, etc.), associa cada dado a uma variável, denominada TAG e possibilita uma série de operações com essas TAGs, tais como:

  • Associar uma TAG discreta (0 ou 1) a objetos para indicação do estado de um equipamento, sendo que este objeto muda sua cor de acordo com o estado real do equipamento em campo.
  • Assiociar uma TAG contínua (variável analógica) a um campo que simplesmente exibe o valor dessa variável.
  • Associar TAGs discretas a botões de comando, possibilitando o acionamento de equipamentos no campo quando o operador pressiona o botão.
  • Associar TAGs contínuas a campos editáveis, de modo que o operador poderá enviar valores pré-definidos (presets ou setpoints) para os equipamentos em campo.
  • Construir animações e associá-las a TAGs discretas ou contínuas, de maneira a representar mais fielmente movimentos ou vários estados possíveis de um equipamento.
  • Gerar gráficos de tendência a partir de TAGs contínuas.
  • Armazenar um histórico de variáveis em um banco de dados.
Dessa maneira, os dados de campo são transformados em informações valiosas para a operação de um determinado processo industrial.
Base de dados
Para possibilitar a leitura e escrita de valores em dispositivos de campo, é necessário que:
  • Haja um meio físico que faça a interligação entre o dispositivo e o computador/servidor onde está o sistema supervisório. (Ex: Cabo serial RS-232, Rede RS-485 com conversor para RS-232, rede Ethernet TCP/IP, etc.)
  • Estejam agregados ao sistema supervisório, drivers ou servidores OPC que possibilitem a comunicação com os dispositivos de campo, através de um protocolo de comunicação aberto ou proprietário, possibilitando a alimentação da base de dados do sistema.
  • Sejam criadas TAGs associadas a endereços específicos em cada dispositivo de campo, de modo que seja possível associar cada valor em campo a objetos na tela do sistema.
Device drivers
Os device drivers ou drivers de dispositivos, são geralmente bibliotecas (arquivos .dll ou similares) que podem ser integrados a um sistema supervisório de maneira que seja possível a comunicação (leitura e escrita de valores) com dispositivos em campo, utilizando um dos meios físicos disponíveis.
Geralmente, os device drivers são desenvolvidos para um fabricante de sistema de supervisão específico, de maneira que cada fabricante de software para desenvolvimento de sistemas supervisórios precisaria desenvolver o seu arquivo de driver para cada protocolo ou dispositivo de campo.
A Figura 3 mostra o princípio de operação de um sistema supervisório utilizando device drivers para acesso aos dispositivos de campo. Note que os device drivers integram o sistema supervisório, logo, o fabricante deste supervisório deve desenvolver o driver para isso. 

Figura 3 – Princípio de operação de um supervisório com device drivers

Para equipamentos específicos ou muito antigos, com protocolos de comunicação de dados proprietários,  provavelmente nenhum software de mercado suportará e será necessário desenvolver um device driver para aquele equipamento. Geralmente os fabricantes de softwares de supervisão possuem esse serviço mas ele é muito caro, pois exigirá um grande esforço de engenharia e talvez até testes de campo para concluir este desenvolvimento. Em uma certa ocasião, um cliente mencionou que havia feito uma cotação para o desenvolvimento de um driver que ele precisaria e o fabricante cobraria cerca de US$ 5.000,00 (cinco mil dólares) para o desenvolvimento, se não houvesse a necessidade de realizar testes de campo, o que encareceria mais o processo.

Assim, este tipo de solução de comunicação utilizando device drivers se torna muito complexa e o usuário final fica preso ao fabricante do software, pois a migração para outro fabricante dependerá da existência de drivers para o novo supervisório que sejam compatíveis com os dispositivos de campo. 
Padrão OPC
Durante algum tempo, esta problemática de device drivers influenciava até a aquisição de novos equipamentos, pois, como adquirir um equipamento de campo que não poderia se comunicar com o supervisório existente?
Para evitar o incoveniente dos device drivers, um conjunto de fabricantes de softwares de supervisão e dispositivos de campo desenvolveu em 1996 um padrão denominado OPC (do inglês OLE for Process Control – OLE para Controle de Processos) e, mais tarde, foi criada a OPC Foundation, para manter e gerenciar o desenvolvimento do padrão.
OLE (do inglês Object Linking and Embedding, ou Incorporação e Vinculação de Objetos) é, basicamente, um protocolo criado pela Microsoft para possibilitar o intercâmbio de dados entre aplicativos dentro do ambiente Windows. Um exemplo clássico disso é o famoso Ctrl+C e Ctrl+V, utilizado para copiar e colar dados (no mesmo aplicativo ou em aplicativos diferentes). Assim, esta tecnologia é utilizada para fins de monitoramento e comandos em sistemas de controle.
Assim, cada fabricante de dispositivos disponibiliza um software, chamado de OPC Server, que tem incorporado os protocolos específicos de comunicação com os dispositivos, mas disponibiliza, via OLE, os dados que podem ser lidos e/ou escritos.
O sistema supervisório, por sua vez, será um OPC Client, ou seja, ele será configurado para requisitar informações do OPC Server, disponibilizando-as na base de dados do sistema. Deste modo, o sistema supervisório pode solicitar um dado ou enviar um novo valor para um dado, através da OLE, de/para um determinado OPC server.
A Figura 4 ilustra a operação de um supervisório com a comunicação de dados via OPC Server com os dispositivos de campo.

Figura 4 – Operação de um Sistema Supervisório com OPC

Outro detalhe importante de ser reforçado é que como o OPC Server é um aplicativo independente do sistema supervisório (ver Layout da Figura 4) vários OPC Clients podem acessar um mesmo OPC Server, de maneira que os dados do processo podem ser disponibilizados para diversos aplicativos ou sistemas, de acordo com a necessidade. Sendo assim, o OPC server pode estar instalado na mesma máquina onde está o supervisório, ou pode também estar em outra máquina, que pode ser acessada via rede. 

Conclusão
Os sistemas supervisórios são, atualmente, uma ferramenta indispensável na construção de sistemas de controle e aquisição de dados, que compõem os sistemas de automação industrial da atualidade. Dentro deste contexto, o advento do padrão de comunicação OPC libertou os fabricantes dos softwares supervisórios do desenvolmento árduo de drivers de comunicação para dispositivos de campo, embora muitos deles tenham os seus próprios drivers para protocolos de comunicação abertos, tal como o Mobdus RTU/TCP.
Referências
Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s