TCC - SISTEMA SUPERVISÓRIO

Prévia do material em texto

INSTITUTO SUPERIOR DE CIÊNCIAS APLICADAS 
ENGENHARIA DE PRODUÇÃO ELÉTRICA 
 
 
 
 
 
 
 
 
 
SISTEMA SUPERVISÓRIO: Estação de Tratamento de Água 
 
 
 
 
 
Alan Aparecido dos Santos 
 
 
 
 
 
 
 
 
 
Limeira – SP 
2012 
1 
 
ALAN APARECIDO DOS SANTOS 
 
 
 
 
 
 
 
SISTEMA SUPERVISÓRIO: Estação de Tratamento de Água 
 
 
 
 
Trabalho de conclusão de curso 
apresentado como exigência parcial para 
obtenção do título de bacharel em 
Engenharia de Produção Elétrica pelo 
Instituto Superior de Ciências Aplicadas, 
sob a orientação da Profa. Dra. Talía 
Simões dos Santos. 
 
 
 
 
 
 
 
Limeira – SP 
2012 
 
2 
 
 
 
 
 
 
 
 
 
 
 
Alan Aparecido dos Santos 
 
SISTEMA SUPERVISÓRIO: Estação de Tratamento de Água 
 
 
 
Banca Examinadora 
 
 
_________________________ 
Profa. Dra. Talía Simões dos Santos 
ISCA Faculdades 
 
 
_________________________ 
Prof. Marcelo Pinto Athayde 
ISCA Faculdades 
 
 
 
 
 
 
 
 
 
Limeira, ___ de ____________ de 2012 
 
3 
 
 
 
 
 
 
 
 
 
 
 
 
Dedico este trabalho aos meus amigos, 
professores e principalmente à minha família e 
minha noiva. 
 
 
 
 
 
 
 
 
 
 
 
 
 
4 
 
AGRADECIMENTOS 
 
Agradeço este trabalho aos meus familiares, minha mãe Izaura, meu pai 
Euclides e meus irmãos Alex e Valeria, pelo incentivo que me ajudaram a 
chegar nessa etapa da minha vida e por acreditarem em mim com este sonho que 
está se tornando realidade. 
À minha noiva Jaqueline pela pessoa e companheira maravilhosa que é, e 
de diversas formas que me ajudou a realizar este trabalho sempre me 
incentivando, pela compreensão nesses últimos meses e ausência em alguns 
momentos, mas que irão valer pelo resto de nossas vidas. 
À minha orientadora Talía Simões dos Santos pela paciência e auxílio na 
conclusão deste trabalho. 
À minha turma com quem compartilhei momentos alegres ao longo do 
curso. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
5 
 
RESUMO 
 
Este trabalho trata da aplicação de sistemas de supervisão e aquisição de 
dados, monitorando e supervisionando uma estação de tratamento e distribuição 
de água. Mostra-se que com a aplicação desta tecnologia pode-se diminuir os 
desperdícios de água sem afetar o abastecimento de água da cidade, fornecendo 
uma visão geral de todo o processo em tempo real. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
6 
 
 
ABSTRACT 
 
 This work discusses the application of systems monitoring and data acquisition, 
monitoring and supervising a treatment plant and water distribution. Shows that the 
application of this technology can reduce the waste of water without affecting the water 
supply of the city, providing an overview of the process in real time. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
7 
 
Sumário 
 
 
1 INTRODUÇÃO .............................................................................................. 11 
1.1 Objetivos..............................................................................................................................11 
1.2 Motivação ............................................................................................................................11 
1.3 Organização do Trabalho.....................................................................................................12 
2 SISTEMAS SCADA ....................................................................................... 13 
2.1 História ...............................................................................................................................14 
3 CLP ................................................................................................................. 16 
4 PAC ................................................................................................................. 19 
5 TIPOS DE COMUNICAÇÃO E PROTOCOLOS ........................................ 21 
5.1 Padrão Serial RS-232 ...........................................................................................................21 
5.2 Padrão RS-485 .....................................................................................................................23 
5.3 Padrão Ethernet ...................................................................................................................25 
5.4 Tipos de Cabos e Topologias ................................................................................................28 
5.5 Protocolos ...........................................................................................................................29 
6 OPC ................................................................................................................. 30 
6.1 Padrão OPC ........................................................................................................................31 
6.2 A arquitetura cliente-servidor do OPC .................................................................................32 
6.3 DCOM, OPC e Tunneling.....................................................................................................33 
6.4 Redundância e OPC .............................................................................................................36 
6.5 OPC e Sistemas Corporativos...............................................................................................38 
7 SOFTWARES SCADA ................................................................................... 40 
7.1 Vantagens dos sistemas SCADA ...........................................................................................40 
7.2 Desvantagens dos sistemas SCADA ......................................................................................41 
8 
 
8 ELIPSE SCADA ............................................................................................. 42 
8.1 Benefícios do Elipse SCADA ................................................................................................42 
8.2 Recursos e informações técnicas...........................................................................................43 
9 DESENVOLVIMENTO DO PROJETO SCADA ......................................... 44 
9.1 Características do projeto ....................................................................................................44 
9.2 Tela inicial ...........................................................................................................................45 
9.3 Tela Menu ............................................................................................................................48 
9.4 Histórico de Acesso ..............................................................................................................49 
9.5 Tela de Captação .................................................................................................................53 
9.6 Tela ETA ..............................................................................................................................54 
9.7 Telas de Distribuição ...........................................................................................................56 
9.8 Tela de Alarmes ...................................................................................................................57 
10 CONCLUSÃO................................................................................................. 59 
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................... 60 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
9 
 
LISTA DE FIGURAS 
 
Figura 1 - Estrutura SCADA [2]. .............................................................................. 13 
Figura 2 - Estrutura Básica do PLC [5]. ....................................................................16 
Figura 3 - Transmissão de um bit [7]. ....................................................................... 22 
Figura 4 - Padrões RS-232 (DB9 e DB25) [7]. .......................................................... 23 
Figura 5 - Taxa de transmissão [8]. ........................................................................... 24 
Figura 6 - Avanços tecnológicos ethernet [8]. ........................................................... 26 
Figura 7 - Diagrama dos modos de transmissão [9]. .................................................. 27 
Figura 8 - Topologia em estrela com cabo de par traçado [9]. ................................... 28 
Figura 9 - Topologia em barramento utilizando cabo coaxial grosso [9]. ................... 28 
Figura 10 - Topologia em barramento utilizando cabo coaxial fino [9]. ..................... 29 
Figura 11 - A falta de conectividade dos sistemas tradicionais [10]. .......................... 30 
Figura 12 - Arquitetura cliente-servidor OPC [10]. ................................................... 32 
Figura 13 - OPC e COM [10]. ................................................................................... 33 
Figura 14 - Funcionamento do OPC com DCOM [10]. ............................................. 34 
Figura 15 - Substituição DCOM por OPC Tunneler [10]. .......................................... 36 
Figura 16 - Redundância em OPC através do OPC Redundancy Broker [10]. ........... 37 
Figura 17 - Integração do OPC com SAP R/3 [10]. ................................................... 39 
Figura 18 - Tela inicial do sistema. ........................................................................... 45 
Figura 19 - Identificação do usuário. ......................................................................... 46 
Figura 20 - Configuração botão login. ....................................................................... 47 
Figura 21 - Configuração botão logout. ..................................................................... 48 
Figura 22 - Tela menu............................................................................................... 49 
Figura 23 - Histórico de acesso. ................................................................................ 50 
Figura 24 - Configuração do botão imprimir relatório. .............................................. 51 
Figura 25 - Configuração do botão preferencia da impressora. .................................. 52 
Figura 26 - Configuração botão apaga arquivo de acesso. ......................................... 53 
Figura 27 - Tela de captação. .................................................................................... 54 
Figura 28 - Tela ETA. ............................................................................................... 55 
Figura 29 - Tela Região Norte................................................................................... 56 
Figura 30 - Tela de alarmes....................................................................................... 57 
10 
 
LISTA DE ABREVIATURAS 
 
CLP – Controlador Lógico Programável 
CPU - Central Processing Unit (Unidade Central de Processamento) 
OPC - OLE for Process Control 
PAC – Programmable Automation Controller 
PC - Personal Computer 
PLC - Programmable Logic Controller 
SCADA – Supervisory Control and Data Acquisition 
VBA – Visual Basic for Applications 
VBS – Visual Basic Script 
COM - Component Objetc Model 
 DCOM - Distributed Component Object Model 
11 
 
 
 
 
 
1 INTRODUÇÃO 
 
 
 
Sistema de supervisão e aquisição de dados, mais conhecido como SCADA 
(Supervisory Control and Data Acquisition), é sistema que por meio de software e 
componentes conectados a uma rede de comunicação através de drivers, faz com que o 
usuário possa controlar, monitorar e receber dados em tempo real de um processo produtivo 
ou instalações físicas proporcionando interfaces em alto nível. Os sistemas SCADA coletam 
as informações, em seguida os dados são manipulados, analisados e apresentados ao usuário. 
 
1.1 Objetivos 
 
O objetivo deste trabalho é desenvolver um sistema de supervisão e aquisição de 
dados (SCADA) de uma estação de tratamento de água, sendo o usuário capaz de monitorar e 
controlar o processo de tratamento, desde a captação da água em dois mananciais até a 
distribuição para a população. Para isso será utilizado o software Elipse SCADA na criação 
deste sistema supervisório. 
 
1.2 Motivação 
 
Nos tempos de hoje o objetivo das organizações é diminuir o desperdício dos recursos 
humanos, que devido ao aumento da população no mundo, consequentemente aumenta o uso 
dos recursos naturais. Nos anos 90 o desperdício de água tratada era de 40%, com a 
implantação de novas tecnologias fez com que no processo de tratamento de água, tivesse 
uma redução em 2011 para 14% na cidade de Limeira e esta redução vem diminuindo a cada 
ano, um dos motivos desta redução é a implantação do sistema supervisório. 
 
12 
 
1.3 Organização do Trabalho 
 
O próximo capítulo trata dos sistemas SCADA, suas funções principais, sua história e 
desenvolvimento destes softwares. 
O capítulo 3 aborda sobre CLP (Controlador Lógico Programável), como é 
constituído, seu desenvolvimento histórico e tipos de programação para sua implementação. 
O capítulo 4 aborda sobre PAC (Programmable Automation Controller), ano que 
surgiu para o mercado, a diferença entre o CLP e o PAC, e uma breve explicação de suas 
diferenças. 
O capítulo 5 trata dos tipos de comunicação utilizados nos sistemas SCADA, os 
padrões utilizados e suas capacidades de alcance, tipos de cabos que utilizam os sistemas. 
O capítulo 6 aborda sobre OPC (OLE for Process Control), padrão de comunicação 
que pode integrar todos os dados de uma empresa, e também suas arquiteturas e seu 
surgimento nos sistemas SCADA. 
O capítulo 7 analisa as vantagens e desvantagens dos softwares SCADA. 
O capítulo 8 apresenta uma breve descrição sobre o software Elipse SCADA da 
empresa de desenvolvimento Elipse Software, suas características que faz com que seu 
software seja utilizado em várias empresas de grande porte. 
O capítulo 9 detalha toda construção de um sistema de supervisão de uma estação de 
tratamento de água. 
O capítulo 10 apresenta os resultados e detalhes do sistema da estação de tratamento 
de água desenvolvido. 
 
 
 
 
 
 
 
 
 
13 
 
2 SISTEMAS SCADA 
 
Os sistemas SCADA podem assumir várias arquiteturas, podendo ser mono-posto, 
cliente-servidor, servidor-cliente, múltiplos servidor-cliente, podendo liberar comunicação 
como os dispositivos PAC (Controladores Programáveis para Automação), CLP (Controlador 
Lógico Programável), módulos de entradas e saídas remotas, registradores [1]. 
Para desenvolver projetos de sistemas SCADA não é necessário ter o conhecimento de 
nenhuma linguagem de programação em específico. A maioria da programação é 
automatizada, suprindo a maior parte das necessidades de um projeto. Em casos mais 
complexos e específicos, onde os passos não estão automatizados, alguns sistemas SCADA 
incorporam módulos de programação em VBA (Visual Basic for Applications) ou VBS 
(Visual Basic Script). Em alguns casos encontram-se linguagem próprias, mas sempre 
parecidas com linguagens comerciais que já são conhecidas no mercado [1]. A figura 1 
representa a estrutura de um sistema SCADA com os equipamentos de comunicação e 
controle.. 
 
 
Figura 1 - Estrutura SCADA [2]. 
 
Os sistemas supervisórios basicamente são utilizados em duas funções, função de 
supervisão e função de operação. 
14 
 
 Funções de supervisão: Esse tipo de supervisão é utilizado para monitorar o 
processo, gerando gráficos de tendências, CEP (Controle Estatistico do Processo), 
verificação de alarmes, tempos de parada, etc. 
 Funções de operação: Esse outro tipo de função de supervisão é utilizado para 
controlar equipamentos, conseguindo ligar e desligar,mudar modo de operação e 
processo de operação. 
 
2.1 História 
 
Os primeiros sistemas supervisórios tiveram início no começo de 1980, mas devido à 
baixa capacidade dos computadores não era comum a utilização dos softwares SCADA, 
apenas nos projetos sofisticados. 
Com o passar dos anos os computadores foram evoluindo e com isso a redução dos 
custos em função do aumento do volume de produção dos componentes, começaram a ser 
lançados os primeiros softwares SCADA. Com esta evolução motivou o surgimento de 
diversas empresas de desenvolvimento de softwares SCADA, sendo que em 1992 mais de 120 
diferentes fornecedores disputavam um mercado ainda em crescimento. Dentro desta mesma 
tendência, diferentes sistemas operacionais surgiram com propósitos e características 
distintas, e até o advento do Windows NT não houve uma convergência de desenvolvedores 
para uma plataforma única de sistemas operacionais. DOS, OS/2, Unix, QNX, Windows, 
VMS eram alguns dos sistemas operacionais encontrados, e a disputa entre supervisórios 
concorrentes também incluía a escolha do Sistema Operacional. Algumas empresas pioneiras 
marcaram época na década de 80, como a Heuristics e seu software Onspec, talvez o primeiro 
produto para computadores com projeção de mercado. A década de 80 teve também uma forte 
influência, no Brasil, da reserva de mercado e da SEI – Secretaria Especial de Informática, 
que limitava a importação de hardwares e softwares com o objetivo de estimular a geração de 
tecnologia nacional. Tal reserva trouxe um considerável atraso tecnológico às empresas 
brasileiras, mas gerou o surgimento dos primeiros sistemas de supervisão e controle de 
processos, motivados principalmente por empresas como a Cia. Vale do Rio Doce, na época 
estatal. Os produtos Pautom (da Paulo Abib Engenharia) e o Autovale (versão modificada 
para a CVRD), desenvolvidos em uma plataforma nacionalizada do sistema operacional 
QNX, foram possivelmente os embriões da produção nacional de softwares de supervisão. 
15 
 
Empresas internacionais lançaram, em meados dos anos 80, suas primeiras versões de 
softwares SCADA, além da Heuristics, empresas como Intellution (The Fix), PC Soft 
(Wizcon), Iconics (Genesis), US Data (Factory Link) e CI Technologies (Citect) tiveram 
destaque nesse período, sendo que a US Data buscou desenvolver uma versão de seu software 
como multi-plataforma para DOS, VMS e OS/2; a PC Soft tinha suas versões de Wizcon para 
OS/2 e DOS; a Intellution para DOS e em um momento chegou a lançar uma versão também 
em OS/2; e a Iconics, sempre em DOS. Existia no mercado, mas com participação reduzidas 
empresas RealFlex (QNX) ou Paragon. 
Com o passar dos anos, a grande maioria das empresas desenvolvedoras de softwares 
supervisórios migrou para a plataforma Windows e para padrões Microsoft. Ao mesmo 
tempo, os clientes foram requerendo funções similares nos produtos, resultando em uma 
convergência nos padrões e módulos. A consolidação da indústria de softwares supervisórios 
passa a ser inevitável, e dos 120 fornecedores mencionados anteriormente, passam a restar 
não mais que 15 empresas globais no mercado, em um período de apenas 10 anos. A empresa 
Wonderware (In Touch), sendo a pioneira em supervisórios em plataforma Windows, se 
beneficiou desse momento e conseguiu uma importante participação no mercado. No final dos 
anos 80 e inicio dos anos 90, duas empresas nacionais desenvolvedoras de supervisórios 
também surgiram, e merecendo destaque, a Elipse e a Indusoft. 
As empresas de desenvolvimentos supervisórios não pararam de evoluir e aprimorar 
seus softwares junto com os equipamentos que são conectados [3]. 
 
 
 
 
 
 
 
 
 
 
 
 
 
16 
 
3 CLP 
 
O controlador lógico programável, mais conhecido como PLC (Programmable Logic 
Controller) no termo Inglês, mas no mercado nacional normalmente usa-se o termo CLP, são 
definidos como um computador industrial, capaz de armazenar funções de controle, realizar 
operações lógicas e aritméticas, manipulação de dados de comunicação em rede [4]. 
Os PLCs são constituídos por blocos, os principais blocos são a CPU, 
Circuitos/Módulos de I/O, Fonte de Alimentação e Base. 
 CPU (Central Processing Unit – Unidade Central de Processamento): Basicamente é 
constituído pelo microprocessador, microcontrolador, sistema de memória (ROM e 
RAM) e os circuitos auxiliares. 
 Circuitos/Módulos de I/O (Input/Output – Entrada/Saída): podem ser discretos (sinais 
digitais: 12VDC, 110VCA, contatos normalmente abertos, contatos normalmente 
fechados) ou analógicos (sinais analógicos: 4-20mA, 0-10VDC, termopar). 
 Fonte de Alimentação: É responsável pela alimentação da CPU e aos 
Circuitos/Módulos de I/O. 
 Base ou Rack: Proporciona conexão mecânica e elétrica entre a CPU, os Módulos de 
I/O e a Fonte de Alimentação, contem também barramento de comunicação entre eles, 
no qual os sinais de dados, endereço, controle e tensão de alimentação estão presentes. 
A figura 2 mostra como é a estrutura básica de um PLC. 
 
 
Figura 2 - Estrutura Básica do PLC [5]. 
 
17 
 
A linguagem e as ferramentas para sua programação podem variar dependendo do 
fabricante, mas a linguagem de programação Ladder por meio de software para PC pode ser 
considerado padrão para a grande maioria dos PLCs encontrados no mercado. 
A programação Ladder foi a primeira linguagem criada para os PLCs. O fato de ser 
uma linguagem gráfica baseada em símbolos semelhantes aos encontrados nos esquemas 
elétricos foi determinante para aceitação por técnicos e engenheiros acostumados com os 
sistemas de controle a relés. 
Foi criada uma norma para definir cinco linguagens de programação utilizar, esta 
norma inicialmente era a 1131, mas a partir de agosto de 1992 se tornou a Norma IEC 61131-
3, sendo assim as linguagens são: 
 Lista de instruções (IL – Instruction List) – É uma linguagem de baixo nível, similar 
ao Assembly, nessa linguagem é permitida apenas uma operação por linha, como o 
armazenamento de um valor em uma determinada variável. 
 Texto Estruturado (ST – Structured Text) – É uma linguagem de alto nível, 
estruturado em blocos, semelhante ao Pascal. Essa linguagem pode ser usada para 
expressar declarações complexas envolvendo variáveis que representem uma ampla 
faixa de dados de diferentes tipos, incluindo valores analógicos e digitais. 
 Linguagem Ladder (LD – Ladder Diagram) – O nome Ladder deve-se à 
representação da linguagem se parecer com uma escala, na qual duas barras verticais 
paralelas são interligadas pela lógica de controle (rung), formando os degraus da 
escada. Além de simples contatos e bobinas, dispõem de contatos para detecção de 
borda de subida/descida (one shot – ‘Disparo’), contatos de comparação, 
temporizadores, contadores, blocos de processamento, controle total de fluxo de 
execução do programa, interrupções e blocos para manipulação de mensagens. 
 Diagrama de Blocos de Função (FDB – Function Block Diagram) – É uma 
linguagem gráfica que permite aos elementos do programa, representados por blocos, 
serem conectados entre si de forma semelhante a um diagrama de circuito elétrico. 
Essa linguagem é apropriada para aplicações que envolvam fluxo de informação ou 
entre os componentes de controle. 
 Diagrama Funcional Sequencial (SFC – Sequencial Function Chart) – É uma 
linguagem gráfica utilizada para estruturar a organização interna de um programa, 
além de auxiliar a decomposição do problema de controle, em partes menores. Cada 
18 
 
elemento do SFC pode ser programado em qualquer uma das linguagens definidas na 
própria norma (IEC 61131-3). 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
19 
 
4 PAC 
 
O PAC (Programmable Automation Controller) foi desenvolvido pela ARC Advisory 
Group, entidade norte-americana de estudos e pesquisas sobre manufaturas, logística e 
cadeias de fornecimentos.Foi criado no ano de 2001 como auxílio ao usuário, de modo que o 
mesmo tivesse a possibilidade de definir com clareza o hardware de automação necessário e 
ao mesmo tempo, permitir ao fabricante do equipamento fornecer de maneira exata o produto 
e sua capacidade. Atualmente alguns fabricantes têm classificado seus produtos mais novos 
como PACs, enquanto outros alegam intercambialidade com os conhecidos PLCs. Apesar 
disso, PACs possuem características próprias e bem definidas, embora a sua similaridade com 
os PLCs sejam numerosas, há também suas diferenças. A seguir, algumas propriedades 
principais de um PAC são descritas: 
 Multifunção: os PACs são multifuncionais, possibilitando o processamento de sinais 
digitais, analógicos, pulsos, seriais, etc, presentes na maioria das aplicações 
industriais. Porém, eles vão muito além, por exemplo, um PAC pode implementar 
algoritmos de controle sofisticados e complexos como a combinação de funções PID 
(Proporcional-Integral-Derivativo) com ganhos agendados e lógicos Fuzzy. Essa 
combinação de controles pode ser efetuada de maneira simultânea e rápida. 
 Multidomínio: os PACs operam em domínio multiplo. Como o padrão de linguagem 
do software é poderoso, as funções avançadas, aquisição, armazenamento e 
compartilhamento de dados, controle de processos, controle de motores, lógica de 
intertravamento e segurança, etc, todos utilizam o mesmo hardware e software. 
 Comunicações abertas standart: para ter a maxima integração e minimizando os 
custos, os PACs utilizam um sistema de protocolos de comunicação abertos e standart, 
a nível de hardware e software. Protocolos como Fieldbus, Profibus, HART, seriais 
como RS 232C/485 e Ethernet ou mesmo protocolos standart da Internet, como 
TCP/IP, UDP, FTP e SMTP podem ser facilmente utilizados. O estabelecimento de 
comunicações com displays locais não necessita de um PC ou mesmo de uma IHM 
para estabelecer a conexão. 
 Multitarefas: um controle tipo PAC possui a capacidade de processar 
simultaneamente diversas tarefas. Simultaneamente ao controle de processos, o PAC 
pode processar aquisição de dados de diversas variáveis e dispositivos, como no caso 
20 
 
de sistemas com Processamento distribuído e ainda se comunicar com diversos 
clientes utilizando uma grande variedade de protocolos de comunicação. 
 Arquitetura Modular: a modularidade de PAC é altamente flexivel, um PAC é 
expandido somente no tipo de controle que solicita a expansão. Por exemplo: num 
sistema de controles que utiliza Processamento Distribuído, um PAC pode ser 
expandido de modo que as funções de controle de contagem e malhas PID operem 
independentes das unidades I/O. Com isso, o controlador principal fica livre para 
exercer suas funções principais: processar o software de controle, efetuar comunicação 
com unidades distribuidas I/O quando necessário e se trocar dados (enviar+receber) 
para um sistema de servidor com aplicações de IHM ou cliente OPC. Devido ao 
design flexivel da modularidade, é facilmente possível adicionar ou mesmo substituir 
as unidades de acordo com as necessidades de controle da planta. 
 Os PACs combinam a fiabilidade e robustez de um CLP com o desempenho, 
flexibilidade e facilidade de operação de um PC. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
21 
 
5 TIPOS DE COMUNICAÇÃO E PROTOCOLOS 
 
Para a utilização dos Sistemas Supervisórios necessita-se de um meio físico para que 
seja possível a aquisição de dados no controlador de campo (PLC). Este meio físico 
geralmente utiliza o padrão elétrico RS232, RS485 ou ethernet. 
O padrão RS232 pode ser utilizado até uma distância máxima de 12 metros. Já o 
padrão RS485 pode chegar a uma distância de até 1200 metros sem repetidores. 
Atualmente, utiliza-se em maior parte, o padrão ethernet. Chega à distância de até 100 
metros entre seguimentos com cabeamento do 10BaseT. 
 
5.1 Padrão Serial RS-232 
 
O padrão RS-232 é um padrão bastante antigo, mas que continua sendo bem utilizado 
pela sua simplicidade e confiabilidade podendo ser encontrado com os nomes EIA RS-232C 
ou V.24. 
Como qualquer dispositivo de transmissão serial, os bits são enviados um a um, 
sequencialmente, e normalmente com o bit menos significativo primeiro (LSB). Por ser um 
protocolo assíncrono, isto é, sem uma linha de relógio (clock), é responsabilidade do 
transmissor e do receptor efetuar controles de tempo para saber quando cada bit inicia e 
finaliza. 
Na sua forma padrão o RS-232 utiliza dois sinais de controle, o RTS (ready to send) e 
o CTS (clear to send) para efetuar o controle de fluxo via hardware. Basicamente, quando o 
transmissor deseja começar um envio ele sinaliza através do pino RTS. O receptor, ao 
perceber que o transmissor deseja enviar algum dado, prepara-se para recebê-lo e seta o pino 
CTS. Apenas depois de receber o sinal CTS o transmissor pode começar a transmissão. 
Para cada byte existem bits de start e stop; o mais comum é utilizar 1 bit de início 
(start bit) e 1 bit de parada (stop bit), mas é possível encontrar aplicações que utilizam 1,5 ou 
2 bits de início/parada. 
A figura 3 mostra como é a transmissão de um bit no RS-232. 
22 
 
 
Figura 3 - Transmissão de um bit [7]. 
 
Como já citado anteriormente, esta transmissão é assíncrona, tendo a velocidade de 
comunicação ajustada nos dois dispositivos inicialmente, cada um deles sabe quanto tempo 
um bit demora a ser transmitido, e é com base nisto que a identificação dos bits é possível. 
No transmissor o envio basicamente resume-se a enviar um bit de início, aguardar um 
tempo, e enviar os próximos 8 bits + bit de parada, com o mesmo intervalo de tempo entre 
eles. 
No receptor, após a primeira borda de descida (nível lógico de "1" para "0") (start bit) 
o receptor sabe que uma sequência de mais 8 bits de dados + bit de parada chegará. Ele 
também conhece a velocidade de transmissão, então tudo que ele precisa fazer é aguardar o 
tempo de transmissão entre cada bit e efetuar a leitura. Após receber o bit de parada, a 
recepção encerra-se e ele volta a aguardar o próximo start bit. 
Nos microcontroladores modernos todo este trabalho normalmente é efetuado por uma 
UART (Universal Asynchronous Receiver Transmitter). Este periférico encarrega-se de 
efetuar todo o controle e apenas gerar interrupções quando um byte é recebido. No entanto, 
algumas vezes o microcontrolador utilizado não possui uma UART, ou mesmo ela está sendo 
utilizada. Nestes casos é possível programar uma interface serial através de software, tratando 
a sequência de transmissão e recepção descrita anteriormente. 
Na interface RS232 o nível lógico "1" corresponde a uma tensão entre -3V e -12V e o 
nível lógico "0" a uma tensão entre 3V e 12V. Valores de tensão entre -3V e +3V são 
indefinidos e precisam ser evitados. O estado idle da linha é 1 lógico (-V). Porém, a grande 
maioria dos periféricos que trabalham com portas seriais não utiliza o padrão RS232 para 
níveis elétricos diretamente. Portanto é sempre necessário um circuito de conversão de níveis 
TTL/RS232. O circuito integrado mais comum para efetuar esta conversão, de baixo custo, é 
o MAX232 que possui alimentação TTL. 
23 
 
Através da Figura 4 podem-se visualizar os dois conectores mais utilizados no padrão 
RS-232, o DB9 e o DB25, com seus respectivos pinos. 
 
 
Figura 4 - Padrões RS-232 (DB9 e DB25) [7]. 
 
5.2 Padrão RS-485 
 
Se uma aplicação consiste de vários dispositivos em lugares diferentes, ou se um 
sistema é composto de diversas unidades, cada uma com determinada função, certamente um 
meio de comunicação entre eles se faz necessário. Apesar do RS-232 ser a interface mais 
comumente utilizada para comunicação serial, ele tem suas limitações. 
O padrão RS-485, criado em 1983, é capaz de prover uma forma bastante robusta de 
comunicação multiponto que vem sendo muito utilizada na indústria em controle de sistemas 
e em transferênciade dados para pequenas quantidades e taxas de até 10 Mbps. 
O padrão RS-485 é administrado pela Telecommunication Industry Association (TIA) 
que é responsável pelo setor de comunicação da Electronic Industries Alliance (EIA), e este 
último é credenciado pelo American National Standards Institute (ANSI). 
No RS-232, os sinais são representados por níveis de tensão referentes ao terra. Há um 
fio para transmissão, outro para recepção e o fio terra para referência dos níveis de tensão. 
24 
 
Este tipo de interface é útil em comunicações ponto-a-ponto a baixas velocidades de 
transmissão. Visto a necessidade de um terra comum entre os dispositivos, há limitações do 
comprimento do cabo a apenas algumas dezenas de metros. Os principais problemas são a 
interferência e a resistência do cabo. Já o padrão RS-485 utiliza um princípio diferente, no 
qual apenas dois fios são utilizados, que serão chamados de A e B de agora em diante. Nesse 
caso tem-se nível lógico 1 quando, por exemplo, se “A” for positivo e “B” negativo, 
consequentemente tem-se nível lógico 0 quando B for positivo e A negativo. Verifica-se que o 
nível lógico é determinado pela diferença de tensão entre os fios, daí o nome de modo de 
operação diferencial. 
Umas das vantagens da transmissão balanceada é sua robustez a ruídos e 
interferências. Se um ruído é introduzido na linha, ele é induzido nos dois fios de modo que a 
diferença entre A e D dessa interferência tende a ser quase nulo, com isso o alcance pode 
chegar a 4000 pés, aproximadamente 1200 metros. Pode-se citar que o padrão RS-232 em sua 
taxa máxima de comunicação alcança em torno de 50 pés, aproximadamente 12 metros. 
Conforme visto anteriormente, o alcance do padrão RS-485 pode chegar a 4000 pés, 
porém quanto maior a distância a ser percorrida pelos dados, menor será a taxa de 
transmissão. Tem-se como base que para distância de até 40 pés a taxa pode chegar a 10Mbps 
e para uma distância de 4000 pés a taxa varia em torno de 100Kbps. O gráfico da Figura 5 
abaixo demonstra de forma clara a relação entre transmissão e taxa de comunicação. 
 
 
Figura 5 - Taxa de transmissão [8]. 
 
25 
 
Como o padrão RS-485 foi desenvolvido para atender a necessidade de comunicação 
multiponto o seu formato permite conectar até 32 dispositivos, sendo 1 transmissor e 1 
receptor por dispositivo. 
Outra grande vantagem do padrão RS-485 é a facilidade de conversão do padrão RS-
232 ao RS-485, simplesmente utilizando um CI, com isso tem-se que a compatibilidade com 
dispositivos já existentes no mercado é mantida, visto que a maioria dos computadores possui 
saída RS-232. 
 
5.3 Padrão Ethernet 
 
A necessidade de diminuir custos, aumentar a confiabilidade, disponibilizar o 
compartilhamento de recursos físicos (HD, impressoras) e informações (banco de dados, 
programas) fez surgir às redes de computadores. Estas características fazem com que estas 
redes não parem de evoluir. 
O padrão ethernet surgiu em 1972 nos laboratórios da Xerox com Robert Metcalfe, 
com uma rede onde todas as estações compartilhavam do mesmo meio de transmissão, um 
cabo coaxial; a configuração utilizada para esta conexão foi a de barramento, utilizava uma 
taxa de transmissão de 2,94 Mbps. 
No início este padrão era chamado de “Network Alto Aloha”, depois foi modificado 
para “ethernet” para deixar claro que este padrão pode suportar qualquer computador e para 
mostrar que pode ser desenvolvido fora de seus laboratórios. Metcalfe optou pela palavra 
“ether” de maneira a descrever uma característica imprescindível do sistema: o meio físico 
transporta os bits para todas as estações, como se acreditava que acontecia com o éter, o meio 
que preenchia o universo e o espaço entre os corpos celestes que propagava as ondas 
eletromagnéticas pelo espaço. 
A falta de padronização dificultava o processo e a venda de equipamentos, com o 
intuito de resolver este problema foi homologada ao IEEE (Institute of Electrical and 
Electronic Engineers), em 1980 a responsabilidade de criar e administrar a padronização da 
ethernet. Desde a sua regulamentação pelo IEEE suas especificações foram totalmente 
disponibilizadas. Esta abertura combinada com a facilidade na utilização e com sua robustez 
resultou no largo emprego desta tecnologia. 
O surgimento de avanços tecnológicos, sua padronização e o aumento da quantidade 
de redes que utilizavam este padrão no decorrer do tempo estão descritos na Figura 6. 
26 
 
 
 
Figura 6 - Avanços tecnológicos ethernet [8]. 
 
A tecnologia ethernet, basicamente, consiste de três elementos: o meio físico, as regras 
de controle de acesso ao meio e o quadro ethernet. 
O modo de transmissão é uma característica importante da ethernet, podendo ser: 
 Simplex: durante todo o tempo apenas uma estação transmite, a transmissão é feita 
unilateralmente. 
 Half-duplex: cada estação transmite ou recebe informações, não acontecendo 
transmissão simultânea. 
 Full-duplex: cada estação transmite e/ou recebe, podendo ocorrer transmissões 
simultâneas. 
A figura 7 mostra os as três principais características do modo de transmissão. 
 
27 
 
 
Figura 7 - Diagrama dos modos de transmissão [9]. 
 
A Ethernet é um padrão de camada física e camada de enlace, opera a 10 Mbps, com 
quadros que possuem tamanho entre 64 e 1518 bytes. O endereçamento é feito através de uma 
numeração que é única para cada host com 6 bytes sendo os primeiros 3 bytes para a 
identificação do fabricante e os 3 bytes seguintes para o número sequencial da placa. Este 
numeração é conhecida como endereço MAC (Media Access Control). 
A subcamada MAC, pertence a camada dois da pilha de protocolos OSI, controla a 
transmissão, a recepção e atue diretamente com o meio físico, consequentemente cada tipo de 
meio físico requer características da camada MAC. 
As características da camada de MAC são: 
 Modo de transmissão half-duplex, evoluindo para full-duplex. 
 Encapsulamento dos dados das camadas superiores. 
 Desencapsulamento dos dados para as camadas superiores. 
 Transmissão dos quadros. 
 Recepção dos quadros. 
 
O modo de transmissão em half-duplex requer que apenas uma estação transmita 
enquanto que todas as outras aguardam em “silêncio” esta é uma característica básica de um 
meio físico compartilhado. O controle deste processo fica a cargo do método de acesso 
Carrier Sense Multiple Access with Collision Detection - CSMA/CD qualquer estação pode 
transmitir quando “percebe” o meio livre. Pode ocorrer que duas ou mais estações tentem 
transmitir simultaneamente; nesse caso, ocorre uma colisão e os pacotes são corrompidos. 
Quando a colisão é detectada, a estação tenta retransmitir o pacote após um intervalo de 
28 
 
tempo aleatório. Isto implica que o CSMA/CD pode estar em três estados transmitindo, 
disputando ou inativo. 
 
5.4 Tipos de Cabos e Topologias 
 
Os principais cabos utilizados são: 
 Coaxial fino. 
 Coaxial grosso. 
 Par trançado sem blindagem. 
 
As topologias suportadas são: 
 Barramento: utilizando cabo coaxial fino ou grosso. 
 Estrela: utilizando cabos de par trançado sem blindagem. 
 Árvore: combinação das anteriores. 
 
A figura 8 mostra os quadros Ethernet. Já as figuras 9 e 10 mostra os padrões Ethernet 
em barramento, podendo ser com cabo grosso ou fino. 
 
 
Figura 8 - Topologia em estrela com cabo de par traçado [9]. 
 
 
Figura 9 - Topologia em barramento utilizando cabo coaxial grosso [9]. 
 
29 
 
 
Figura 10 - Topologia em barramento utilizando cabo coaxial fino [9]. 
 
O quadro ethernet é dividido em campos. Os principais campos podem ser descritos 
das seguintes maneiras: 
 Destination Address: Contém o endereço MAC do destinatário. 
 Sorce Address: Contém o endereço MAC do remetente. 
 Type/Length: Indica o tamanho em bytes do campo de dados. 
 Data: Contém os dados que deverão ser passado a próxima camada, deve ter tamanho 
mínimo de 46bytes e máximo de 1500 bytes. 
 FCS (Frame Check Sequence): Contém o Cyclic Redundancy Check (CRC). 
 
5.5 Protocolos 
 
Para que haja comunicação entre o controlador de campo e o sistema supervisório não 
basta apenas o meio físico. Os dois sistemas devem utilizar o mesmo protocolo de 
comunicação. Cada fabricante de PLC tem os seus protocolos de comunicação proprietária. 
Logo, os sistemas supervisório possuem vários “drivers” de comunicação, para que possam 
atender a maior parte dos fabricantes. 
 
 
 
 
 
 
 
 
30 
 
6 OPC 
 
Existem inúmeros sistemas nas áreas de produção, incluindo sistemas SCADA, 
SDCD’s, LIMS (Laboratory Information Management Systems), MES (Manufacturing 
Execution System), além dos sistemas de manutenção e historiadores. Muitos destes sistemas 
tendem a ser aplicação isolada umas das outras, ou em alguns casos possuem algum tipo de 
interface, mas no geral existe uma pequena integração entre eles. Décadas de protocolos de 
comunicação proprietários resultaram em sistemas desconexos dentro do próprio chão de 
fábrica. Tradicionalmente o usuário toma o caminho mais fácil e acaba agregando ferramentas 
do mesmo fornecedor inicial, mesmo que outro fornecedor possua soluções mais interessantes 
para sua necessidade. 
A figura 11 mostra como era falta de conectividade dos sistemas tradicionais. 
 
 
Figura 11 - A falta de conectividade dos sistemas tradicionais [10]. 
 
Já no ambiente corporativo existem vários outros softwares que preenchem 
necessidades específicas como planejamento de produção, gerenciamento de custos, 
contabilidade, entre outros. Estes softwares podem ser fornecidos por um único fabricante ou 
então adquiridos separadamente. No entanto, de um modo geral, estes softwares tendem a 
possuir uma maior integração do que a existente nas áreas de produção. 
Devido aos aspectos culturais e de negócios da organização, as pessoas e sistemas 
envolvidos nestas áreas frequentemente têm pouca interação, criando uma lacuna de 
comunicação. Como resultado desta lacuna as informações se tornam indisponíveis através da 
organização. Porém, em um ambiente competitivo como o encontrado atualmente, as 
31 
 
informações tornaram-se essenciais, uma espécie de vantagem estratégica. As tecnologias do 
padrão OPC permitem a integração dos dados de toda a empresa, sejam provenientes do chão 
de fábrica ou dos setores corporativos. Sendo um padrão aberto, o OPC separa os sistemas das 
dificuldades de comunicação, criando uma camada única e padronizada que permite a fácil 
integração de diversos sistemas, desde um simples instrumento de campo até os sistemas de 
ERP (Enterprise Resource Planning) e de Gestão Corporativa. 
 
6.1 Padrão OPC 
 
O OPC é um padrão de comunicação aberto, que tem por principal objetivo permitir a 
interoperabilidade vertical entre sistemas dentro de uma organização. A primeira versão 
funcional do OPC foi desenvolvida por volta de 1996, resultado do trabalho conjunto entre 
fornecedores de sistemas para automação industrial. Deste esforço conjunto surgiu a OPC 
Foundation, organização que define os padrões do OPC e que busca constantemente sua 
melhoria e evolução. Desde o seu surgimento, há mais de 10 anos, novas especificações são 
elaboradas com o objetivo de agregar mais funcionalidades ao padrão OPC. 
Baseado nas tecnologias Microsoft OLE COM (Component Objetc Model) e DCOM 
(Distributed Component Object Model), o OPC é um conjunto comum de interfaces, métodos 
e propriedades de comunicação, agregados dentro de uma especificação padronizada e aberta 
para acesso público. Teoricamente qualquer pessoa com conhecimentos de programação pode 
desenvolver seus aplicativos OPC, basta acessar as especificações contidas na web site da 
OPC Foundation e desenvolver uma interface compatível. 
Para ficar mais claro o que é o OPC pode-se fazer uma analogia com um driver 
comum de impressora. Na época do MS-DOS, o desenvolvedor de um software como um 
editor de textos precisava desenvolver um driver de comunicação para cada uma das 
impressoras existentes no mercado: um para a Epson-FX, um para a HP LaserJet, entre outras 
impressoras. Em um software de supervisão, será visto que ele tem seus próprios drivers para 
cada um dos CLPs existentes no mercado. No entanto estes drivers não podem ser utilizados 
em outro software de supervisão. O Windows resolveu o problema dos drivers de impressoras 
ao incluir o suporte para impressão no próprio sistema operacional. A partir de então a 
impressora deveria possuir somente um driver para Windows, e não mais para cada um dos 
aplicativos utilizados. Este fato possibilitou uma redução de custos considerável para as 
32 
 
empresas de software. Ao basear o OPC na tecnologia OLE, nativa do Windows, este mesmo 
benefício chegou à área industrial. 
Com o surgimento do OPC os desenvolvedores de sistemas de automação podem 
escrever servidores OPC para seus equipamentos, e os demais softwares (como os 
supervisórios) passam a ser clientes OPC. Desaparece a necessidade de se desenvolver 
inúmeros drivers de comunicação. Enquanto o OPC permitiu aos fornecedores de automação 
reduzir seus custos de conectividade e assim manter o foco nas funcionalidades de sua 
solução, para os clientes o benefício foi a flexibilidade. Agora o usuário pode escolher seus 
softwares com base nas funcionalidades. 
 
6.2 A arquitetura cliente-servidor do OPC 
 
O funcionamento do OPC é baseado na tradicional arquitetura cliente-servidor, 
conforme mostra a Figura 12. 
 
 
Figura 12 - Arquitetura cliente-servidor OPC [10]. 
 
O funcionamento desta solução é simples, um ou mais servidores fornecem dados para 
uma ou mais aplicações cliente. 
O interessante do OPC é que uma aplicação cliente pode solicitar os dados a um ou 
mais servidores OPC, e o inverso também é verdadeiro, um servidor OPC pode transferir 
dados a um ou mais clientes OPC. Portanto, o OPC possibilita uma variedade enorme de 
comunicações, basta que os aplicativos sejam compatíveis com OPC. 
33 
 
É importante ressaltar que o OPC não elimina o protocolo proprietário nativo do CLP 
ou equipamento de campo. O que acontece é que o servidor OPC “traduz” este protocolo 
proprietário para o padrão OPC. 
Portanto é necessário o desenvolvimento de um servidor OPC específico para cada um 
dos diferentes protocolos de comunicação existentes. 
Inicialmente o OPC foi desenvolvido com o objetivo de solucionar o problema dos 
drivers de comunicação proprietários, trazendo um padrão para onde antes só existiam 
soluções customizadas. A primeira especificação OPC posteriormente veio a se chamar Data 
Access e, como o nome sugere, permitia somente a troca de dados em tempo real. O OPC 
Data Access é largamente utilizado em todo mundo, é o mais comum de ser encontrado. 
Porém logo surgiram outras necessidades, como o acesso a dados e o acesso a alarmes e 
eventos gerados no sistema. Novas especificações surgiram para suprir estas e outras 
demandas. 
 
6.3 DCOM, OPC e Tunneling 
 
Como visto anteriormente, o OPC é baseado nas tecnologias Microsoft OLE COM 
(Component Object Model) e DCOM (Distributed COM). Quando o servidor e o cliente OPC 
estão instalados no mesmo computador, o OPC utiliza o COM para estabelecer a 
comunicação entre ambos conforme mostra a figura 13. Geralmente não há problemas nesta 
configuração, o COM é de fácil configuração, envia e recebem dados a altas velocidades e 
raramente apresenta problemas. 
 
Figura 13 - OPC e COM [10]. 
34 
 
 
Porém, quando o servidor e cliente OPC estão instalados em computadores diferentes 
dentro de uma rede, o OPC passa a utilizar o DCOM. Surgido em 1996, com foco no 
ambiente de TI, o DCOM é uma extensão do COM, com foco na comunicação entre objetos 
em sistemas distribuídos. O DCOM atendia bem aos requisitos daquela época, basicamente o 
funcionamento dentro de LANs (Local Area Networks). A figura 14 mostrao seu 
funcionamento. 
 
 
Figura 14 - Funcionamento do OPC com DCOM [10]. 
 
Com o surgimento e popularização da Internet na década de 90, as demais tecnologias 
acabaram por evoluir rapidamente a fim de atender uma infinidade de novas demandas. A 
própria Microsoft acabou desenvolvendo uma nova plataforma de desenvolvimento, em 
resposta ao Java da Sun Micro systems e também como forma de combater a onda de vírus e 
invasões remotas que acompanharam a evolução da Internet. 
O DCOM deixava a desejar frente às novas demandas da tecnologia, e ainda por cima 
não estava acessível aos programadores para que os mesmos pudessem melhorar superar tais 
deficiências. 
Dentre as limitações do DCOM pode-se mencionar: 
35 
 
 Dificuldade de se trabalhar em WANs (Wide Area Network): redes com diferentes 
usuários, senhas e domínios são um problema para o DCOM, que exige configurações 
detalhadas a fim de funcionar corretamente. 
 Timeout demasiadamente longo: em caso de simples oscilações na rede, o DCOM 
pode levar vários minutos até restabelecer a conexão. 
 Dificuldade de se trabalhar com firewalls: O DCOM inicia a comunicação através de 
uma porta TCP/IP e em caso de encontrar algum impedimento, utiliza outras portas 
aleatoriamente até conseguir estabelecer a conexão. Em uma época em que o próprio 
Windows já vem com firewall instalado para aumentar a segurança, a utilização do 
DCOM acaba obrigando o usuário a manter diversas portas TCP/IP abertas, ou até 
mesmo a desativar o firewall por completo, prejudicando criticamente a segurança do 
sistema. 
 
Tais limitações são um grande empecilho em aplicações industriais onde, por 
exemplo, alguns sistemas obrigatoriamente devem ser instalados em domínios diferentes, a 
velocidade de comunicação é fator essencial e a segurança contra hackers e invasões aumenta 
a cada dia. 
Algumas vezes os problemas do DCOM podem ser solucionados com muitas horas de 
trabalho e políticas corporativas que respeitem o ambiente industrial. Outra abordagem para 
eliminar estes problemas por inteiro é utilizar a tecnologia de Tunneling. Neste caso, um 
software chamado OPC Tunneler é colocado em cada uma das pontas da comunicação OPC, 
por exemplo, um no computador do servidor e outro na estação cliente OPC. Os dois objetos 
Tunneler se comunicam com seus OPC locais através do COM, confiável e rápido. Após isto 
os dois OPC Tunneler estão livres para trocar dados entre si através de outras tecnologias 
mais apropriadas para as necessidades da aplicação, como o TCP/IP, HTTP, HTTPS, XML, 
etc. Problemas com usuários, senhas e domínios diferentes são automaticamente anulados. O 
desempenho da rede já não tem tanta interferência sobre o OPC, uma vez que o timeout é 
configurável no OPC Tunneler. E o problema mais comum encontrado atualmente que é o de 
se trabalhar com OPC e firewalls ao mesmo tempo passa a ser resolvido, uma vez que o OPC 
Tunneler utiliza sempre a mesma porta de comunicação TCP/IP. Esta porta é configurável 
pelo usuário, portanto basta escolher a mais adequada e liberá-la no firewall. Conforme dito 
acima a figura 15 mostra os motivos para a substituição. 
 
36 
 
 
Figura 15 - Substituição DCOM por OPC Tunneler [10]. 
 
Em resumo o OPC Tunneler tem duas funções básicas: transferir data da maneira mais 
fácil, segura e confiável possível para o outro componente OPC Tunneler, e traduzir todos os 
dados para o padrão OPC novamente, tornando a comunicação mais consistente. Todas as 
dores de cabeça geralmente associadas ao DCOM são aliviadas. Basta especificar um 
endereço IP e uma porta de comunicação e assim estabelecer a comunicação em rede 
utilizando OPC. 
 
6.4 Redundância e OPC 
 
Em muitos processos a segurança e confiabilidade são fundamentais. Os motivos para 
tanto podem ser diversos, tais como: 
 Prevenção contra acidentes e fatalidades em sistemas críticos. Ex.: indústrias químicas 
e petroquímicas. 
 Minimizar paradas de produção e/ou quebras de equipamentos caros e que demandam 
muito tempo para reparo. Ex.: indústrias siderúrgicas e de mineração. 
 Impossibilite de se interromper a prestação de serviços sob a penalidade de sofrer 
multas e prejuízos na imagem. Ex.: empresas de geração, transmissão e distribuição de 
energia elétrica. 
 Necessidade de se manter um histórico de dados confiável para facilitar a 
rastreabilidade e identificação de falhas. Ex.: indústria automobilística. 
 
37 
 
Uma solução bastante utilizada na indústria para o aumento da confiabilidade e 
segurança é a redundância, que basicamente consiste na utilização de dois ou mais sistemas 
iguais. Desta maneira, caso um dos sistemas apresente problemas, o outro estará pronto para 
entrar em operação e assumir suas funções. A redundância pode ser utilizada em diversos 
níveis dentro de um sistema de automação industrial, ou seja, pode-se encontrar CLPs com 
CPUs redundantes, softwares de supervisão em redundância, redes redundantes, etc. No 
entanto, apesar da grande importância da redundância para aumento da segurança e 
confiabilidade dos sistemas, a especificação OPC não aborda este tema de maneira 
satisfatório, abrindo uma grande lacuna na utilização do OPC. Para um sistema ser redundante 
não basta instalar dois softwares e/ou equipamentos iguais, é necessário um gerenciamento 
entre os mesmos com o objetivo de não aumentar o fluxo de dados na rede e ao mesmo tempo 
manter uma base de dados completa e confiável, sem duplicações que podem levar à dúvida. 
Muitas vezes tenta-se instalar dois servidores OPC em paralelo como objetivo de aumentar a 
segurança. No entanto o resultado é que ambos passam a funcionar em paralelo, aumentando 
o fluxo de dados na rede e deixando dúvidas sobre qual deles tem o dado de melhor 
qualidade. 
Soluções de terceiros foram desenvolvidas para preencher a lacuna da redundância no 
OPC. Também conhecido com OPC Redundancy Broker, este gerenciador de redundância 
sempre escolhe somente um OPC Server para realizar a comunicação, mantendo o outro em 
estado de espera. O OPC Server backup somente entra em cena em caso de falha no OPC 
Server primário, assumindo suas funções e garantindo a continuidade e confiabilidade da 
comunicação OPC, conforme mostra na figura 16 a seguir. 
 
 
Figura 16 - Redundância em OPC através do OPC Redundancy Broker [10]. 
 
38 
 
6.5 OPC e Sistemas Corporativos 
 
Inicialmente o OPC foi desenvolvido para o ambiente de chão de fábrica. Porém a 
evolução trouxe novas necessidades, como a troca de informações com sistemas de gestão. 
Através disso é possível, por exemplo, que uma ordem de produção gerada em um sistema de 
planejamento de produção seja levada diretamente aos sistemas de automação, permitindo 
uma agilidade muito maior nas operações. Conforme o andamento da produção, os sistemas 
de automação devolvem os dados de processo aos softwares de gestão, dando aos gestores 
informações em tempo real. Assim uma equipe de vendas pode saber, em tempo real, se pode 
aceitar determinado pedido ou não, dependendo do andamento da produção. A contabilidade 
pode calcular os custos de produção em tempo real. O departamento de compras pode saber 
qual fornecedor tem a melhor relação custo/benefício, em função do rendimento da matéria-
prima no processo. 
Apesar de ainda não abordado em detalhes na especificação OPC DA – o que deve 
ocorrer na nova especificação OPC UA, existem soluções customizadas para a integração do 
OPC com sistemas corporativos. 
Um exemplo é o OPC Generic Data Access da empresa Matrikon OPC, que permite a 
troca de dados bidirecional com bancos de dados relacionais. Um sistema de automação de 
chão de fábrica pode enviar dados diretamente para um ERP baseado em um banco de dados 
como Oracle ou SQL Server, e este sistema podem devolver dados aos sistemas de produção. 
Já o Nlink OPC to SAP da Junot Systems é uma interface direta entre o OPC e o ERP 
mais famoso mundialmente,o R/3 da SAP. É uma solução pronta e que minimiza a criação de 
códigos em linguagens de programação. 
A Figura 17 mostra a integração dos sistemas. 
 
39 
 
 
Figura 17 - Integração do OPC com SAP R/3 [10]. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
40 
 
7 SOFTWARES SCADA 
 
Conforme visto anteriormente existem no mercado várias empresas de 
desenvolvimento de software SCADA, abaixo uma lista dos melhores softwares: 
 
DELTA V FIX DMACS INTOUTH LOOKOUT 
TCD-3000 IFIX ABB MICROSCADA PLANTSPAPE 
TPS GENESIS CIMPLICITY LINTOUCH 
SCAN3000 WIZCON RSVIEW ELIPSE 
 
Basicamente todos os softwares SCADA são parecidos, mudando apenas a linguagem 
de programação e modos de configuração. 
Será visto na continuação deste projeto uma breve explicação do Elipse SCADA, 
software que foi utilizado para o desenvolvimento de uma estação de tratamento de água. 
 
7.1 Vantagens dos sistemas SCADA 
 
Ao utilizar o sistema SCADA pode-se obter diversas vantagens em comparação com 
os processos antigos, como redução de custo operacional, maior qualidade, maior 
desempenho no processo, conforme pode-se comprovar abaixo: 
Redução dos custos operacionais: Com um sistema SCADA é 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, controles estatistico do processo. São necessários poucos funcionários 
especializados e com comandos simples é possível realizar a leitura dos instrumentos de um 
processo industrial inteiro, reduzindo assim a necessidade de vários operadores em alguns 
procssos operacionais. 
Qualidade: Através do monitoramento das variáveis do processo produtivo é possível 
determinar níveis previstos no processo normal. Caso estes níveis não estejam na faixa 
aceitável o sistema SCADA 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 assim que não gere gastos, perdas no processo ou que o 
produto final não esteja dentro das características desejáveis. 
41 
 
Maior desempenho no processo: Através da rapidez da leitura dos instrumentos de 
campo, as intervenções necessárias podem ser feitas assim que ocorre o evento ou atraves dos 
alarmes gerados. Problemas de parada de máquina por defeitos podem ser diagnosticados 
mais pontualmente ou realizando com antecedência as manutenções preventivas e os setups 
de máquina também mais ageis, fazendo com que o processo seja mais produtivo. 
Base para outros sistemas: Coletar os dados do processo produtivo e armazenar 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 OEE, sistemas SFC, sistemas de PCP ou 
similares, ferramentas que são utilizados para a gestão da produção. 
 
7.2 Desvantagens dos sistemas SCADA 
 
A desvantagem encontrada neste sistema é a necessidade de mão-de-obra 
especializada e dependendo do tipo de controle ou monitoramento é necessario investimento 
muito alto. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
42 
 
8 ELIPSE SCADA 
 
O software Elipse SCADA foi desenvolvido pela Elipse Software, esta empresa está a 
mais de 20 anos no mercado de automação, sempre inovando o desenvolvimento de soluções 
de gerenciamento de processos, este software não está vinculado a nenhum hardware 
específico, garantindo alto desempenho de comunicação e conectividade. 
A Elipse é uma empresa nacional, mas tem presença no mercado mundial, tendo sua 
sede em Porto Alegre e filiais em São Paulo, Curitiba, Belo Horizonte, Estados Unidos e 
Taiwan, e tem participação significativa em outros países como Alemanha, Índia, Rússia, 
Suécia, Coréia do Sul, Argentina, Colômbia, Chile, dentre outros. 
O software Elipse SCADA foi testado e implantado em grandes empresas e diversos 
segmentos produtivos no Brasil, empresas como a Alstom, Aracruz, Areva, Banco Itaú, 
Batavo, Braskem, Brasil Telecom, CENPES, Ceval, Cia. Vale do Rio Doce, Copel, CSN, 
Dana Albarus, DMAE, Elektro, Gerdau, Marcopolo, Nestlé, Perdigão, PETROBRAS, 
Randon, Rede Globo de Televisão, RGE, Sabesp, Sadia, Siemens, Stemac, Stihl, SuperVia, 
Tractebel, Usiminas e WEG são algumas empresas que utilizam o software. No mercado 
internacional conta com representantes que divulga este software de alta qualidade [12]. 
O software Elipse SCADA na ausência de um dispositivo de proteção (hardkey) pode 
ser executado na versão demonstrativo, mas trabalho com no máximo 20 Tags (variáveis de 
campo), permitindo a comunicação com equipamento de aquisição de dados por até 10 
minutos, podendo assim verificar e avaliar o software. 
 
8.1 Benefícios do Elipse SCADA 
 
Este software contém vários benefícios fáceis de notar, como sua fácil configuração 
por meio de sua ferramenta Organizer (Árvore do aplicativo), mantendo o seu projeto 
organizado e visualização geral do aplicativo. 
Contém uma interface clara e objetiva, fazendo com que o usuário realize sua 
operação com mais rapidez e clareza, com vários recursos visuais como, botões, displays, 
gráficos, animações e os TAGs (Variáveis de campo), podendo importar imagens de vários 
formatos (Bitmap, JPG), podendo a sua operação do sistema supervisório ser controlado por 
mouse, teclado ou touthscreen. 
43 
 
Conectividade com qualquer equipamento como PLCs, DACs (Cartões de Aquisição 
de Dados), RTUs (Unidades Remotas). 
 
8.2 Recursos e informações técnicas 
 
Aplicações Remotas - supervisão e controle de estações à distância por meio de 
conexão Intranet (via protocolos TCP/IP ou IPX/SPX), Internet (Elipse WEB), linha discada 
ou linha privada, satélites, links de rádio ou serial. 
Drivers de comunicação - a maneira mais simples e eficiente de trocar informações 
com equipamentos, com mais de 400 drivers compatíveis com os equipamentos mais 
utilizados no mercado e suportando diferentes tipos de conexões como serial, Ethernet, linha 
discada, rádio modem ou outras redes específicas. 
Cross-Reference (Referência cruzada) - rápida visualização das ligações entre os 
objetos, permitindo que, em qualquer momento da configuração, se visualize todos os pontos 
onde um determinado Tag ou objeto está sendo referenciado. 
Históricos - registros de dados. 
Alarmes - até 999 níveis de prioridade e quatro intervalos de atuação para cada um. O 
usuário pode, em tempo de execução, alterar limites, habilitar/desabilitar e/ou modificar 
mensagens de alarmes. 
Bancos de Dados - A integração com qualquer base de dados é muito simples através 
de recursos ODBC (Open Data Base Connectivity) e DAO (Data Access Objects), Wizards 
auxiliam no processo de conexão ou criação de uma base de dados qualquer, dentre elas SQL 
Server®, Access®, Oracle® e DBase®. Ainda é possível a integração com sistemas 
corporativos (ERP) como o SAP. 
Relatórios - dispensa a utilização de módulos externos para a geração de relatórios. 
Scripts - maior flexibilidade e poder para realizar tarefas complexas, com linguagem 
de programação própria semelhante à linguagem Visual Basic. 
Ferramentas de depuração - status dos componentes e processos do sistema, facilita 
o processo de aplicativo utilizando ferramentas como WatchWindow e ScriptWindow, 
informando o estado do processo ou do componente do sistema. 
 
44 
 
9 DESENVOLVIMENTO DO PROJETO SCADA 
 
Nos capítulos anteriores foram apresentados conceitos de PLCs, protocolos de 
comunicação e de sistema supervisório, os quais seus conhecimentos são fundamentais para a 
elaboração de um sistema supervisório. O foco principal deste projeto é desenvolver um 
sistema supervisório de uma estação e distribuição de água em um município, mostrando que 
essa tecnologia pode diminuir o desperdício de água, a falta de abastecimentoe ter controle 
em tempo real. 
 
9.1 Características do projeto 
 
O projeto desenvolvido possui todas as características de um sistema de supervisão, 
pois monitora os eventos em tempo real, armazena dados, produz relatórios, gera simulação 
de alarmes, entre outras características. 
O processo utilizado para este projeto é realizado da seguinte forma: 
 Na primeira etapa é necessária a identificação do usuário para entrar no sistema. 
 A água é captada em dois mananciais, sendo que não é possível a utilização dos dois 
ao mesmo tempo. 
 A captação é realizada por duas bombas, sendo uma em utilização contínua e outra 
como reserva, não sendo possível ligar as duas ao mesmo tempo. 
 A água passa por um reservatório intermediário antes de chegar a ETA (Estação de 
Tratamento de Água), com duas bombas na saída deste reservatório com o mesmo 
critério das bombas na captação. 
 Na ETA a água passa pelos processos convencionais do pré-tratamento, coagulação, 
floculação, decantação e a filtração. Logo após este processo é feita a dosagem de 
fluoretação, desinfectação e dosagem de cal, que neste processo não é automatizado e 
a água é enviada para o reservatório de distribuição. Na saída deste reservatório foi 
colocada uma bomba que realiza a distribuição de água. 
 A distribuição é feita para quatro regiões, norte, sul, leste e oeste, cada região existe 
um reservatório. Na entrada deste reservatório foi colocada uma válvula que impede o 
abastecimento, e na saída a distribuição é feita por meio de bombas para os bairros. 
 
45 
 
9.2 Tela inicial 
 
A tela inicial do projeto foi realizada com o intuito de fazer um controle de acesso do 
usuário, podendo ser verificadas e impressas as informações de acesso, como data e hora do 
acesso ou quando foi desconectado do sistema. Nesta tela foram colocados quatro botões, 
sendo, login, logout, manutenção de senha e de acesso no sistema, conforme Figura 18 
abaixo. 
 
 
Figura 18 - Tela inicial do sistema. 
 
Também foram adicionados dois displays que mostram o nome do usuário conectado 
ao sistema e o nível de acesso do usuário. Este nível de acesso informa quais são as telas e 
funções o usuário terá acesso, podendo variar de 0 a 100. Se o nível de acesso for 0, o usuário 
poderá entrar em qualquer tela sem restrições de funções, se for 1 este usuário poderá 
modificar, adicionar, remover os atributos de todos os usuários. No projeto em questão foram 
criados apenas quatro usuários, o Administrador com nível de acesso 1, e os demais com nível 
de acesso 2. Apenas a tela inicial e o menu estão com o nível de acesso 0, as outras que serão 
vistas adiante foram configuradas para nível 2. 
Alem disso, foi criado um tag RAM com o nome User para que as informações sejam 
armazenadas no sistema. 
46 
 
O botão login, quando acionado, solicitará ao usuário para digitar a sua identificação e 
senha. Caso a identificação ou senha estiver incorreta aparecerá uma mensagem “Login ou 
senha inválida” e o usuário não terá acesso para entrar no sistema, caso tente entrar no sistema 
também aparecerá uma mensagem de acesso negado. 
Para a construção deste botão foi colocado um botão com funcionalidade momentânea 
e associando duas imagens, que quando pressionado seu formato irá modificar e sua 
identificação será solicitada conforme a Figura 19. 
 
Figura 19 - Identificação do usuário. 
 
Para que ocorram os processos acima, foi realizada uma configuração na aba Scripts 
conforme Figura 20. É executada uma linguagem que no momento que o botão login é solto é 
feita a identificação do usuário. Caso não seja correto, aparecerá a mensagem dita 
anteriormente, se estiver correto, automaticamente os dados do usuário são enviados e salvos 
no histórico e gerado um relatório que pode ser impresso. A tela de histórico de acesso será 
dita no decorrer no trabalho. 
47 
 
 
Figura 20 - Configuração botão login. 
 
Ao contrário do botão login, que faz com que o usuário seja conectado no sistema, o 
botão logout faz com que o usuário desconecte do sistema. 
Na aba Scripts do botão logout, também foi realizada uma configuração que irá ler a 
função, fazendo com que as informações de data e hora que o usuário foi desconectado serão 
salvas no histórico de acesso conforme Figura 21, assim como o botão login. 
 
48 
 
 
Figura 21 - Configuração botão logout. 
 
Nesta tela foi adicionado o botão trocar a senha para que os usuários possam trocar a 
sua senha, porém, apenas o administrador tem liberdade de adicionar e excluir dados 
conforme dito anteriormente. 
 
9.3 Tela Menu 
 
A tela menu foi construída para que o usuário tenha acesso a todas as outras telas e 
históricos do sistema com facilidade (Figura 22). 
 
49 
 
 
Figura 22 - Tela menu. 
 
Como se pode ver na figura acima foram criados sete botões que quando pressionados, 
automaticamente é feita a troca da tela a qual foi desejada. A configuração foi inserida nas 
propriedades do botão. 
Caso o usuário não tenha acesso à tela que foi pressionada, o usuário não irá conseguir 
ir para a tela desejada, mas no projeto em questão todos os usuários têm acesso a todas as 
telas, conforme mencionado anteriormente. 
Os botões do “Menu Principal” levam o usuário para a tela início, retornando assim 
para a tela vista anteriormente e suas funções. Pode-se também ir para ela histórico de acesso 
ou na tela de alarmes, que será visto ao longo do trabalho. 
Os botões do painel “Distribuição” levam os usuários às telas onde são verificados os 
reservatórios de água e bombas de captação e distribuição de água. 
 
 
9.4 Histórico de Acesso 
 
Através da tela histórico de acesso pode-se verificar qual usuário estava conectado em 
uma determinada hora ou data, esta informação pode ser verificada devido à configuração dos 
50 
 
botões login e logout visto anteriormente neste projeto. Pode-se também imprimir este 
relatório, configurar a impressora e apagar os dados (Figura 23). 
 
 
Figura 23 - Histórico de acesso. 
 
Para a construção desta tela foi criado no comando “Organizer” um arquivo histórico e 
inserido os tags user.name e o User. Foi dado o nome de Histórico de Acesso para este 
arquivo, e também foi criado um arquivo de histórico com o nome “histoperador.dat”. 
Na tela de histórico de acesso foi criado um Browser e associado o arquivo de 
histórico criado, nos quis são criadas automaticamente as colunas das informações dos tags 
inseridos no arquivo histórico de acesso. 
51 
 
Nesta tela foram criados três botões, o primeiro, quando pressionado com o botão 
esquerdo do mouse, irá imprimir o relatório. Para isso foi realizada uma configuração na aba 
Scripts, conforme Figura 24 abaixo. 
 
 
Figura 24 - Configuração do botão imprimir relatório. 
 
Para poder imprimir este relatório, foi criado um relatório de texto no comando 
“Organizer”, “Relatórios”, do software Elipse SCADA e dado o nome de relatório 1. 
No segundo botão, pode-se configurar a impressora e suas preferências, também foi 
realizada uma configuração na aba Scripts, conforme Figura 25. 
52 
 
 
Figura 25 - Configuração do botão preferencia da impressora. 
 
E por ultimo o botão apaga arquivo que apaga o arquivo de histórico por completo. 
Neste botão foi realizada uma configuração na aba Scripts, que quando o botão for solto, 
aparecerá uma mensagem de alerta para que o usuário confirme se quer que o histórico de 
acesso seja apagado, conforme Figura 26. 
53 
 
 
Figura 26 - Configuração botão apaga arquivo de acesso. 
 
9.5 Tela de Captação 
 
A captação neste projeto é realizada por dois mananciais, que são chamados de Rio 
Jaguari e Ribeirão Pinhal. As comportas dos mananciais não são acionadas juntas neste 
projeto. Quando o botão manancial for pressionado, irá trocar de manancial automaticamente. 
Para poder controlar os mananciais foi criado um tag RAM com o nome comporta, 
que foi associado aobotão manancial e aos textos que representam se a comporta está aberta 
ou fechada. 
 A captação da água é feita por duas bombas, uma bomba em utilização contínua e 
outra que sempre fica como reserva, mas pode-se controlar ao utilizar. Foram criados dois 
tags Demo com os nomes B1 e B2, com limites de o a 6 com período de 70 e com incremento 
2. 
Para a representação da movimentação das bombas, foram criados animações que 
foram dados os nomes de Bomba B1 e B2 e associadas aos tags B1 e B2 comentados acima, 
para o acionamento das bombas B1 e B2 foram criados dois botões que irão ligar e desligar e 
conforme o controle dos mananciais as bombas não serão acionadas juntas, devido à 
configuração na aba Scripts dos botões. 
54 
 
Após a passagem da água nas bombas de captação B1 e B2, ela passará por um 
reservatório chamado de Reservatório Intermediário, que foi associado ao tag intermediário, 
configurado para que seu limite seja de 17000 a 20000 e período de 150. Para a 
movimentação do nível de água, a aba alarme foi configurada para que assim que o nível 
chegar ao máximo registre um alarme. 
Foram colocadas duas bombas na saída do reservatório chamadas de B3 e B4, e seu 
funcionamento é o mesmo das bombas B1 e B2 comentadas acima. 
A Figura 27 abaixo mostra como é o processo da tela de captação. 
 
 
Figura 27 - Tela de captação. 
 
 
Também foi criado um tag Demo, com o nome água captada, com seus limites entre 0 
a 250 e período de 1000. Este tag foi associado ao display que representa a quantidade de 
água captada por hora. 
O botão Menu foi colocado para que quando acionado o sistema volte para a tela menu 
do sistema. 
 
9.6 Tela ETA 
 
Na tela ETA foram representados os processos convencionais do pré-tratamento de 
água, coagulação, floculação, decantação, filtração. Em seguida passa-se pela dosagem de 
55 
 
fluoretação, desinfectação e dosagem de cal, que não é automatizado neste projeto, conforme 
pode ser visto na Figura 28. 
A água é enviada para o reservatório de distribuição, e na saída deste reservatório foi 
colocada uma bomba que realiza a distribuição de água para as regiões. 
 
 
Figura 28 - Tela ETA. 
 
Para a construção da tela ETA foram criados quatro tags Demo, dois botões e as 
imagens para a representação dos processos. 
O primeiro tag Demo está representado com o nome “ETA” e serve para representação 
da movimentação da água no processo de pré-tratamento. Este tag foi configurado para que os 
limites fiquem entre 0 a 3, com o período de 250, e foi associado na animação do processo. 
O segundo tag foi dado o nome de “Água Distribuída” que mostra a quantidade de 
água distribuída. Este tag foi configurado para que os limites fiquem entre 0 a 240 e com 
período de 1000. Para representar este valor foi criado um display e associado a este tag. 
O terceiro tag foi dado o nome de “BD” que liga a bomba de distribuição, a sua 
configuração é a mesma das bombas de captação, com os limites de 0 a 6 e período de 70. 
Para realizar o processo de liga/desliga, foi também associado na animação da bomba. 
O último tag tem o nome “Res. ETA”, que representa o nível do reservatório na tela 
ETA. Este tag foi configurado para que os limites fiquem entre 17000 e 20000. Assim que o 
valor chegue em 20000 será disparado o alarme, conforme os outros reservatórios deste 
projeto. 
56 
 
Foi também adicionado um botão que faz com que o usuário volte para a tela menu 
conforme as outras telas. 
 
9.7 Telas de Distribuição 
 
As telas de distribuição representam as regiões Norte, Sul, Leste e Oeste. As 
configurações e funcionalidade destas quatro telas são basicamente as mesmas, pois todas irão 
distribuir a água tratada para os bairros (Figura 29). 
 
 
Figura 29 - Tela Região Norte. 
 
Para a construção das telas de distribuição (Norte, Sul, Leste e Oeste) foram criados 
dois tags Demo e dois botões, para cada tela de distribuição. 
O primeiro tag Demo realiza a animação da bomba, e foram dados os nomes B5, B6, 
B7 e B8, respectivamente, conforme a sequência das telas especificadas acima. A sua 
configuração foi feita com limites de 0 a 6, e período de 75 com incremento 2. 
O segundo tag Demo realiza o fechamento e abertura da válvula de entrada de água no 
reservatório, e os nomes dos tags são Norte, Sul, Leste e Oeste. Estes tags também 
representam o nível de água em cada reservatório, cuja configuração foi realizada para que os 
limites fiquem entre 17000 a 20000, com período entre 130 a 170 para que não fiquem iguais. 
57 
 
Os botões adicionados no sistema irão ligar e desligar a bomba e a válvula, então 
foram associados os tags especificados acima um para cada botão. Foi colocado também o 
botão Menu que levará o usuário a tela menu do sistema, conforme as outras telas anteriores. 
 
9.8 Tela de Alarmes 
 
A tela de alarme foi adicionada no sistema com o intuito de que o usuário possa 
verificar onde ocorreu o alarme, o usuário conectado no momento do alarme, a hora que 
ocorreu e o valor encontrado, como pode ser verificado através da Figura 30. 
 
 
Figura 30 - Tela de alarmes. 
 
A tela de alarmes foi criada para que quando o nível 0 passa de 19900, o alarme é 
acionado e realizado um som de aviso e aparecera a mensagem de nível alto e o local que 
ocorreu o alarme, assim que o nível volte ao normal aparecerá uma nova mensagem que o 
nível esta normal e o local. 
58 
 
Para a realização da tela alarme foi realizado a configuração nas abas alarmes dos tags 
dos reservatórios (Norte, Sul, Leste, Oeste, ETA e Intermediário) onde foi selecionado os 
comandos Low e High (Baixo e Alto), no comando Low foi colocado o valor 0 e no 
comentário “Nível Baixo – Local’ e para comando alto o valor foi 19900 e comentário “Nível 
Alto – Local”, no grupo de alarme foi selecionado o alarme “Nível”, criado no comando 
organizer, na aba alarmes do software Elipse. 
Para criar a tela que irá mostrar os alarmes, no Elipse SCADA existe um menu com o 
nome alarmes, e automaticamente todos os alarmes gerados irão ser mostrados nesta tela, 
conforme visto na Figura 30. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
59 
 
10 CONCLUSÃO 
 
Conforme visto, o sistema foi realizado no Elipse SCADA versão DEMO, por esse 
motivo os números de tags são limitados, mas se utilizar a versão completa o sistema pode ser 
melhorado em vários aspectos, principalmente no tratamento de água, podendo ser 
completamente automatizado. 
A maior dificuldade encontrada na realização do projeto no software foi o número 
limitado de tags e encontrar as imagens bitmap para inserir no projeto para que realize os 
movimentos das bombas, 
O sistema mostrou uma grande vantagem, pois antes o desperdício de água era de 40% 
e o município sofria muito com a falta de água, pois os reservatórios eram controlados a sua 
quantidade de água por bóias. Com a utilização do sistema haverá apenas a necessidade de ter 
um operador capacitado para controlar, supervisionar e monitorar o processo de captação ate a 
distribuição de água, mas o usuário terá todo o controle em tempo real e reduzindo 
drasticamente os dados acima. 
Com toda a experiência adquirida neste período de desenvolvimento, é possível 
concluir que os softwares de supervisão são de grande valia para qualquer indústria e ramos 
diferentes que tenha qualquer tipo de automação, pois com essa tecnologia pode-se diminuir o 
desperdício de qualquer processo. 
A tendência é que estes sistemas cresçam cada vez mais, uma vez que a tecnologia de 
automação está tomando conta de todos os setores industriais e até mesmo predial e 
residencial. 
 
 
 
 
 
 
 
 
60 
 
REFERÊNCIAS BIBLIOGRÁFICAS 
 
[1] – Sistemas de Supervisão e Aquisição de Dados - SCADA Disponível em: 
http://pt.wikipedia.org/wiki/Sistemas_de_Supervis%C3%A3o_e_Aquisi%C3%A7%C3%A3o
_de_Dados, acessado em 02 de fevereiro de 2012. 
 
[2] – Estrutura