Sistemas de Supervisão e Aquisição de Dados

Visão geral do esquema SCADA

Sistemas de Supervisão e Aquisição de Dados, ou abreviadamente SCADA (proveniente do seu nome em inglês Supervisory Control and Data Acquisition) também chamado de sistema supervisório SCADA, são sistemas que utilizam software para monitorar e supervisionar as variáveis e os dispositivos de processos industriais, não industriais e equipamentos conectados através de servidores/drivers de comunicação específicos. É uma evolução dos antigos painéis sinópticos industriais. Estes sistemas podem assumir topologia mono-posto (standalone), cliente-servidor ou múltiplos servidores-clientes. Atualmente tendem a libertar-se de protocolos de comunicação proprietários. Permitem realizar operações de leitura e escrita na áreas de memória de dados e imagem (I/O) dos dispositivos PACs (Controladores Programáveis para Automação), módulos DAQ (aquisição de dados), controladores lógicos programáveis (CLPs), controladores singleloop/multloop, sistemas de fieldbus, dispositivos IoT, etc. Os diferentes hardwares utilizados possuem interfaces físicas de comunicação e protocolos proprietários ou abertos de comunicação. Portanto é necessário um servidor/driver de comunicação específico para cada caso. Este driver pode estar sendo executado no contexto do próprio software SCADA ou em um software independente. Nesse último caso tem-se a arquiteturas cliente-servidor de comunicação. Podem ser utilizados alguns protocolos de interface para estabelecer a relação cliente-servidor, que podem ser o OPC (OLE for Process Control), DDE (Dynamic Data Exchange), entre outros. Atualmente o Software SCADA tende a operar em diferentes sistemas operacionais com uso de diversos protocolos como por exemplo: OPC UA, MQTT, Mobus RTU, Modbus TCP e muitos outros.

Um exemplo de software SCADA com estas características é o Cloud Studio.

O que é na prática?

De forma genérica, um software de supervisão ou software SCADA (SSC) permite monitorar e operar partes ou todo um processo industrial ou não industrial como sistemas de transporte, sistema elétricos, domótica, etc. No caso dos processos industriais esses pode ser de manufatura de alumínio, fabricação de peças, fabricação em batelada, indústria alimentícia, entre outros. Pode ser utilizado até mesmo sistemas de serviços públicos, como de tratamento de água e esgoto, sistemas de distribuição de gás, etc. Também pode ser utilizado para implementar as interfaces de sistemas de Internet das Coisas (IdC/IoT).

Os SSC geralmente têm 2 módulos básicos: o desenvolvedor e o executável ("run-time"). (Os nomes e a metodologia de desenvolvimento variam um pouco de fabricante para fabricante, mas sempre são bem parecidos).

Atualmente, para desenvolver projetos de SSC não é necessário o conhecimento de nenhuma linguagem de programação em específico, pois os módulos de software já vem prontos comercialmente, cabendo ao técnico em automação industrial, cuidar da sua instalação e da combinação com as máquinas eletromecânicas e equipamentos do chão de fábrica. Em casos mais complexos e específicos, alguns SSC´s incorporam módulos de programação em linguagens de SCRIPT como: Java Script, VBA (Visual Basic For Applications), VBS (Visual Basic Script), "C", entre outras. Em alguns casos encontram-se linguagem próprias, mas sempre parecidas com linguagens comerciais que já são difundidas.

Por que a empresa precisa de um sistema de supervisão?

Qualidade, redução dos custos operacionais, maior desempenho de produção, base para outros sistemas, ou seja, vantagem competitiva.

Qualidade: Através do monitoramento das variáveis do processo produtivo, (pressão, temperatura, vazão, nível, etc.) é possível determinar valores ótimos de trabalho. Caso estes valores saiam da faixa aceitável o SSC pode gerar um alarme na tela, alertando o operador do processo para um eventual problema no processo produtivo. Desta forma, as intervenções no processo são feitas rapidamente, garantindo que o produto final sempre tenha as mesmas características.

Redução dos custos operacionais: Com o SSC é possível centralizar toda a leitura dos instrumentos de campo, gerar gráficos de tendência e gráficos históricos das variáveis do processo. Dessa forma, são necessários poucos funcionários especializados e com poucos “cliques” de mouse é possível realizar a operação do processo com o uso dos instrumentos virtuais implementados na interface do software SCADA.

Maior desempenho de produção: Através da rapidez da leitura dos instrumentos de campo, as intervenções necessárias podem ser feitas mais rapidamente. Problemas de parada de máquina por defeitos podem ser diagnosticados mais pontualmente e os setup´s de máquina também são agilizados.

Base para outros sistemas: Os SSC podem coletar os dados do processo produtivo e armazená-los em banco de dados. Estes dados podem ser utilizados para gerar informações importantes, sendo integrados com sistemas MES, ERP, SAP e etc. Podem também fornecer dados em tempo real, para sistemas que realizam cálculos de SPC, OEE, sistemas SFC, sistemas de PCP ou similares e ERP.

• SPC - Statistic Process Control
• OEE - Overall Equipment Effectiveness
• PCP – Planejamento e controle de produção
• MES - Manufacturing Execution Systems
• SFC - Shop floor control
• ERP - Enterprise Resource Planning

Painéis Sinóticos

No passado, os processos industriais eram monitorados através de grandes painéis sinóticos, com diagramas de luzes e alarmes, bem como alavancas, ponteiros e relógios analógicos, que representavam uma sinopse do processo, as etapas do mesmo e a supervisão de cada máquina do chão de fábrica. Atualmente, esses painéis foram substituídos por sistemas de software, que representam toda a operação da indústria, de modo muito mais preciso, e em tempo real. Estes sistemas são planejados, projetados e implementadas em um módulo desenvolvedor e depois executados para a correta operação do chão de fábrica.

Alarmes

Os SSC podem ser configurados para gerar alarmes, ou seja, avisar ao usuário do sistema quando uma variável ou condição do processo de produção está fora dos valores previstos.

Os alarmes são mostrados na tela em formato de planilhas e/ou animações na tela.

O gerenciamento de alarmes em SSC é um vasto tema de estudos.

A principal questão está no fato de que a grande maioria dos sistemas SCADA não possui ferramentas adequadas para o tratamento de grande quantidade de alarmes. Dessa forma, os operadores de sistemas, como seres humanos, possuem um limite de processamento de mensagens a cada intervalo de tempo. Em situações de estresse contínuo ou mesmo de “avalanches”, o excesso de mensagens geradas pode fazer com que os operadores passem a desprezá-las.

Nesse contexto, os sistemas de supervisão deveriam fornecer mais ferramentas que pudessem auxiliar os operadores nesses momentos, como por exemplo, distinguindo quais as ações são mais importantes e devem ter uma resposta mais imediata, e quais têm prioridade mais baixa, por ser apenas consequência de outros eventos.

Relatórios

Atualmente, os SSC do mercado possuem ferramentas para a geração de relatórios na própria estação de trabalho. Os relatórios mais comuns que são utilizados são:

• Relatório de alarmes: Lista um histórico com os alarmes ocorridos durante uma faixa de tempo escolhida pelo operador do sistema.
• Relatório de Acesso: Lista quais foram os usuários que acessaram o SSC ou modificaram algum parâmetro do processo.
• Relatório de variáveis: Lista a alteração de variáveis ao decorrer do tempo/lote/período.

Os relatórios dependem dos requisitos da aplicação e dos recursos existentes no software SCADA. Geralmente não são executados relatórios “pesados” (com muitos cálculos e relacionamentos) dentro do SSC, pois podem afetar drasticamente o desempenho do sistema (que geralmente é vital para o processo industrial). Relatórios complexos devem ser processados por outros sistemas de informação.

Gráficos Históricos

Uma das mais interessantes funcionalidades dos SSC é a possibilidade de geração de gráficos históricos.

Gráficos históricos ajudam a avaliar valores de variáveis ao longo do tempo de forma rápida.

Tipos de comunicação e protocolos

Meio físico

Os SSC necessitam de um meio físico para que seja possível a aquisição de dados no controlador de campo ( CLP ou outro).

O meio físico normalmente segue padrões elétricos como RS-232, RS-485, RS-422, Ethernet ou USB.

O padrão RS232 pode ser utilizado até uma distância máxima de 12 metros. Já os padrões RS485 e RS422 podem chegar a uma distância de até 1200 metros sem repetidores.

Atualmente, o padrão Ethernet é bem difundido para redes locais. Chega à distância de até 100 metros entre segmentos com cabeamento do 10BaseT.

Para distância elevadas pode-se utilizar fibra óptica.

Protocolos

Para que haja comunicação entre o controlador de campo e o SSC não basta apenas o meio físico. Os dois sistemas devem utilizar o mesmo protocolo de comunicação. Cada fabricante de CLP tem o seu protocolo de comunicação que pode ser proprietário ou aberto. Logo, os SSC podem possuir vários “drivers” de comunicação, para que possam atender a maior parte dos fabricantes. Em muitos casos os SSC possuem interfaces que permitem a comunicação com protocolos como por exemplo o OPC. Nesse caso existe a relação cliente(SSC) e servidor (driver).

Existem protocolos de comunicação abertos, como por exemplo, o Modbus versões RTU e TCP. A maioria dos fabricantes de CLP já implementa este protocolo de forma nativa.

OPC (OLE for process control)

OPC (OLE for Process Control) é um padrão industrial publicado para interconectividade de sistema. As especificações deste padrão são mantidas pela Fundação de OPC. A Fundação OPC é uma organização dedicada ao desenvolvimento de tecnologias aplicadas a interoperabilidade na automação a fim de criar e gerenciar especificações que padronizam a comunicação das arquiteturas de acesso a dados on line, alarmes, registros de eventos, comandos e bancos de dados de diferentes equipamentos, de vários fabricantes que comunicam em diferentes protocolos. Seu funcionamento é baseado no OLE (Object Linking and Embedding) de componentes orientados a objeto, por meio das tecnologias COM e DCOM da Microsoft que permitem que aplicações troquem dados que podem ser acessados por um ou mais computadores que usam uma arquitetura cliente/servidor, mesmo que essas aplicações trabalhem sobre sistemas que utilizem protocolos diferentes.

O OPC funciona utilizando os serviços das tecnologias OLE COM de Microsoft (modelo objeto/componente) e DCOM (modelo objeto/componente distribuído), a especificação define o formato padrão de objetos, interfaces e métodos para uso em sistemas de automação e controle que facilitam a interoperabilidade. As tecnologias de COM/DCOM proveram o procedimento padrão para criação de softwares que objetivam a integração de equipamentos. Com base nessa tecnologia foram criadas centenas de OPC de acesso a dados tanto em servidores quanto em clientes. O OPC propõe a interface amigável entre sistemas que trabalham usando protocolos diferentes. Assim diversas aplicações recebem dados no mesmo formato da sua base de dados, embora a fonte desses dados possa trabalhar com um padrão diferente de formatação e comunicação de dados. O OPC unifica o padrão de comunicação de dados de controle de processo e a permite que diferentes produtos sejam interfaceados com uma única tecnologia, promovendo interações dos sistemas de operação e integração de vários processos em um só sistema, isso com custo e tempo de implementação reduzidos (IWANITZ F. E LANGE, 2006).

O OPC permite a “integração vertical” entre os diferentes sistemas dentro de uma organização.

Consiste em um programa servidor, geralmente disponibilizado pelo próprio fabricante do PLC, que se comunica com o PLC através do protocolo proprietário e disponibiliza os dados no padrão OPC.

O cliente, ao invés de precisar ter um driver do protocolo proprietário, necessita ter apenas o driver OPC client instalado.

O servidor OPC pode estar instalado na mesma maquina que o OPC client.

Quando o servidor e o cliente estão instalados no mesmo computados, o OPC utiliza o COM para estabelecer a comunicação. O COM é de fácil configuração e relativamente rápido.

Em aplicações distribuídas, o servidor e o cliente OPC serão instalados em computadores diferentes.

Neste caso, o OPC passa a utilizar o DCOM. O DCOM é de configuração complicada, difícil de trabalhar em WAN´s, tem timeout elevado e exige configurações avançadas no firewall.

A especificação OPC UA liberta o protocolo permitindo trabalhar em outros sistemas operacionais não Windows (R).

Tipos de OPC

• OPC DA – 'Qual o valor da variável “x” AGORA?'
• OPC HDA – 'Qual o valor da variável “x” ONTEM?'
• OPC A&E – 'A variável “x” está com valor Alto' - Trata de alarmes e eventos
• OPC UA: - Independe de Plataforma.

Sistema cliente/servidor

Existem aplicação onde é necessário ter acesso remoto as interfaces de operação do SSC, até mesmo a partir da Internet. Os SSC permitem arquiteturas servidor SCADA WEB. Geralmente, o processamento dos dados do processo fica centralizado no servidor SCADA, garantindo que não haverá incertezas e diminuindo o trafego de rede.

O servidor SCADA, neste caso, pode ou não ter uma interface gráfica. Um exemplo de software SCADA com estas características é o Myscada [1]

Sistema Web Server

De forma análoga ao sistema cliente/servidor o Web Server visa disponibilizar os dados do processo através da rede. Porém os clientes ao invés de acessarem os dados através de um software instalado na máquina, eles acessam via browser de Internet.

Estes sistemas têm como vantagem a não necessidade de instalação de softwares adicionais no micro cliente e pode-se acessar o SSC através da Internet de forma fácil e segura. Permite o fácil acesso através de palms e celulares mais avançados.

A principal desvantagem é a relativa perda de robustez do sistema.

A tendência é a substituição dos clientes normais por sistemas WEB. Os custos são menores, há menor investimento em infra-estrutura e gera ótimos resultados.

Redundância e confiabilidade

Existem processos industriais que não podem parar. A parada destes processos pode causar prejuízos financeiros imensos ou até mesmo riscos à vida.

Desta forma alguns dos sistemas SCADA podem ser configurados de forma redundante. Existem inúmeros métodos de arquitetura de redundância de dados, variando de fabricante a fabricante de SSC. O mais utilizado é comumente chamado de hot standby. Neste caso, usam-se dois servidores, um chamado primário e outro secundário ou backup. Os dois sistemas possuem base de dados idênticas, que resumem as planilhas de comunicação com o PLC.

Quando o servidor primário está em funcionamento, os clients requisitam dos dados deste servidor. O próprio servidor secundário também requisita os dados do servidor primário e deixa a sua base de dados inativa.

Quando o servidor primário não está mais ativo, os clients automaticamente começam a requisitar dados do servidor secundário, o que é chamado failover automático. O servidor secundário, por sua vez, ativa a sua base de dados local e inicia a leitura das variáveis dos CLP.

Quando o servidor primário volta à ativa, o sistema chaveia-se automaticamente, ou seja, volta à condição inicial.

Banco de Dados

Os SSC têm plena capacidade de armazenamento em banco de dados relacionais (DB). Podem ser armazenados:

• Dados históricos.
• Alarmes e eventos.
• Informações Logísticas.
• Dados de logon/logoff.
• Entre outros.

Os dados podem ser utilizados para gerar relatórios, gráficos, entre outras informações analíticas.

Os sistemas de gerenciamento de bancos de dados (SGBD) mais utilizados no mercado são SQL Server, Oracle e mySQL. Em alguns casos que exijam menor complexidade pode-se utilizar o MS Access. Geralmente instalam-se os SSC e os SGBD em máquinas separadas, por razões de desempenho e maior tolerância a falhas.

PIMS

Basicamente, PIMS (do inglês Process Information Management System) é um software que contém um repositório, onde são concentradas todas as informações relevantes das células de produção, diretamente ligadas aos sistemas de supervisão e controle. O PIMS coleta informações dos sistemas de supervisão, CLP, SDCD e sistemas legados e os armazena em uma base de dados real time.

Tal base tem características não encontradas nos bancos de dados convencionais, como grande capacidade de compactação (tipicamente de 10:1) e alta velocidade de resposta a consultas em sua base histórica. Devido a isto, é capaz de armazenar um grande volume de dados com recursos mínimos, se comparada às soluções convencionais.

Estes dados são normalmente utilizados para controle de produção, consumo, eficiência etc.