UNIVERSIDADE FEDERAL DO PAR INSTITUTO DE TECNOLOGIA FACULDADE DE ENGENHARIA DA COMPUTAO

Daniella dos Santos Ferreira

DESENVOLVIMENTO E IMPLEMENTAO DE UM SISTEMA DE SUPERVISO MVEL EM AMBIENTES INDUSTRIAIS

Belm-Par, 02/07/2009

UNIVERSIDADE FEDERAL DO PAR INSTITUTO DE TECNOLOGIA FACULDADE DE ENGENHARIA DA COMPUTAO

Daniella dos Santos Ferreira

DESENVOLVIMENTO E IMPLEMENTAO DE UM SISTEMA DE SUPERVISO MVEL EM AMBIENTES INDUSTRIAIS

Trabalho de Concluso de Curso apresentado para obteno do grau de Engenheiro em Engenharia da Computao, do Instituto de Tecnologia, da Faculdade de Engenharia da Computao da Universidade Federal do Par.

Julho/2009

ii

DESENVOLVIMENTO E IMPLEMENTAO DE UM SISTEMA DE SUPERVISO MVEL EM AMBIENTES INDUSTRIAIS

Este trabalho foi julgado em 02/07/2009 adequado para obteno do Grau de Engenheiro da Computao, e aprovado na sua forma final pela banca examinadora que atribuiu o conceito _____________.

Profa. MSc. Rosana Soares (Orientadora) Faculdade de Engenharia Eltrica Universidade Federal do Par

Eng. Normando Queiroz (Co-Orientador) Alunorte Alumina do Norte do Brasil S.A

Prof. Dr. Walter Barra Jnior (Membro) Faculdade de Engenharia Eltrica Universidade Federal do Par

Prof. MSc. Rafael Chaves (Membro) Faculdade de Engenharia da Computao Universidade Federal do Par

Prof. Dr. Gervsio P. dos Santos Cavalcante Diretor da Faculdade de Engenharia da Computao da Universidade Federal do Par

Julho/2009

iii

DEDICATRIA Dedico este trabalho aos pais maravilhosos que Deus me deu. Alm de me amar e educar, eles fizeram tudo o que estava ao alcance para que eu realizasse este sonho e tivesse uma oportunidade que eles no tiveram: a de cursar o nvel superior.

iv

AGRADECIMENTOS Primeiramente eu no poderia deixar de agradecer ao meu Deus, pois sem Ele tenho certeza de que no conseguiria passar pelas tantas dificuldades encontradas na minha trajetria de Porto Trombetas at aqui. Aos meus pais que sempre me deram todo o apoio necessrio. Muito obrigada, papai! Muito obrigada, mame! Ao meu amado esposo, Shalon Guilherme, sempre muito paciente, compreensivo e orando por mim. Tambm minha mana Llian. A minha orientadora Rosana, sempre muito solcita, respondendo meus emails e sanando todas as minhas dvidas. Sua orientao e amizade foram muito preciosas e importantes e me ajudaram a passar por momentos de tanta ansiedade e expectativas. Aos colegas da turma 2005/1 Edinaldo, Bemerguy, Jos Thiago, Diego, Srgio, Fabrcio, Gilberto, Mrcio e tantos outros pelo companheirismo e amizade. A todos os funcionrios e professores da UFPA que repassaram seus conhecimentos durante o perodo de quatro anos e meio em que estudei nessa instituio. A Alunorte Alumina do Norte do Brasil S.A, onde executei este trabalho por ocasio de um estgio supervisionado, pela concesso de toda a infra-estrutura necessria e apoio financeiro sem os quais a realizao deste trabalho no seria possvel. Aos amigos da Diviso de Automao Industrial da Alunorte que me ajudaram muito, seja me dando material para estudar, tirando dvidas e at mesmo revisando meus textos. Destes tenho especialmente que agradecer ao meu tutor e coorientador, engenheiro Normando Queiroz, pela ateno que me dispensava mesmo quando estava ocupado e pelo muitos Calma Dani... quando as coisas comeavam a dar errado. Ao engenheiro Diego, pela ajuda e amizade. Ao Alexandre Lopes, da Lume Sistemas, famoso Carioca, pela grande ajuda com o supervisrio e por ter realmente vestido a camisa deste projeto, apertando sua agenda para poder me orientar. A todos que participaram de minha trajetria acadmica, desde os professores e amigos da Escola Professor Jonathas Pontes Athias Fundao Vale do Trombetas at hoje. Deus abenoe a todos vocs. Muito obrigada!

Senhor Deus, ensina-me a viver os meus dias de modo que meu corao alcance sabedoria. Salmo 90.12, Bblia Sagrada.

vi

RESUMO Este trabalho apresenta o estudo realizado para projetar, desenvolver e implementar um sistema de superviso mvel para uma planta industrial, especificamente uma refinaria de alumnio. O trabalho foi desenvolvido no ambiente fabril da Alunorte Alumina do Norte do Brasil S.A e testado em laboratrio. No desenvolvimento do sistema foram utilizadas tcnicas e ferramentas de reconhecida eficcia no meio industrial, tais como OPC (OLE for Process Control), comunicao por redes wireless e Ethernet, arquitetura cliente-servidor, UML, entre outras. O sistema se prope a ser uma ferramenta para auxiliar os profissionais em campo, de forma que o tempo e a dificuldade de acesso as informaes sobre o processo possam ser minimizados, servindo, portanto de apoio a tomada de decises e diminuindo os riscos planta, s pessoas e aos equipamentos, visto que possibilitar o monitoramento do processo em tempo real por um nmero maior de pessoas e de qualquer local da empresa, diminuindo a probabilidade de acidentes em qualquer dessas esferas. Palavras-Chave: Sistemas de Superviso Mvel. Wireless. OPC.

vii

ABSTRACT

This work presents the study to design, develop and implement a mobile supervision system for a industrial plant, specifically an aluminum refinery. The work was developed in the manufacturing environment of Alunorte - Alumina do Norte do Brasil S.A and tested in the laboratory. In development of the system were used techniques and tools of recognized effectiveness in business environment, such as OPC (OLE for Process Control), communication by wireless networks and Ethernet, client-server architecture, UML and others. The system aims to be a tool to help professionals in the field, so that the time and difficulty of access to information about the process can be minimized, serving therefore to support decision making and reducing the risks to plant, to people and equipment, as will be possible the monitoring of the process in real time by a larger number of people and any place of company, reducing the likelihood of accidents in any of these spheres. Keywords: Mobile Supervision Systems. Wireless. OPC.

viii

LISTA DE FIGURAS Figura 2.1: Viso geral do Processo Bayer................................................. 4 Figura 2.2: Fluxograma bsico da Alunorte................................................ 6 Figura 2.3: Filtrao de Licor Rico dentro do Processo Bayer.................. 9 Figura 2.4: Layout da rea 5....................................................................... 10 Figura 2.5: (a) Filtro de presso vertical visto de cima e (b) debaixo......... 11 Figura 2.6: Arquitetura do SDCD da Alunorte............................................ 13 Figura 2.7: Uma sala de controle da Alunorte............................................ 14 Figura 2.8: Exemplo de dificuldade de acesso........................................... 15 Figura 2.9: Exemplos de dispositivos mveis............................................ 17 Figura 2.10: Estrutura do sistema de superviso mvel proposto.............. 17 Figura 3.1: Diagrama representativo de um sistema automatizado........... 18 Figura 3.2: Controle tpico de um supervisrio .......................................... 22 Figura 3.3: Sistema Supervisrio Tpico..................................................... 23 Figura 3.4: Mtodo tradicional de desenvolvimento de softwares.............. 26 Figura 3.5: Plataforma iFIX......................................................................... 29 Figura 3.6: Tela do workspace do iFIX...................................................... 30 Figura 3.7: Exemplo de tela do GENESIS32, da Iconics........................... 31 Figura 3.8: Exemplo de case do Elipse SCADA........................................ 31 Figura 3.9 : Viso Geral e simplificada de um SDCD................................ 33 Figura 3.10: Evoluo dos sistemas de automao................................... 35 Figura 3.11: Nveis de redes industriais..................................................... 38 Figura 3.12: (a) Arquitetura sem Fielbdus Foundation, (b) Arquitetura FF..40 Figura 3.13: Ethernet 10BaseT....................................................................42 Figura 3.14: Encapsulamento dos protocolos TCP/IP.................................45 Figura 3.15: Camadas do Modelo OSI .......................................................46 Figura 3.16: Modo de operao ponto a ponto............................................47 Figura 3.17: Modo infra-estrutura com 1 AP................................................48 Figura 3.18: Interfaces dedicadas versus OPC...........................................56 Figura 3.19: Aplicaes rodando com vrios servidores OPC....................57 Figura 3.20: Especificaes do padro OPC...............................................58 Figura 4.1: Tela do SCU..............................................................................62 Figura 4.2: Base de dados, inserindo um novo bloco................................. 63 Figura 4.3: Ns do iFiX............................................................................... 64 Quadro 4.1: Tipos de ns do iFIX............................................................... 64 Figura 4.4: Estrutura simplificada do sistema, destacando-se os ns do iFIX.........................................................................................................65 Figura 4.5: Ligao no ponto de acesso......................................................68 Figura 4.6: Utilizao de um switch no sistema de superviso mvel.........69 Figura 4.7: Arquitetura do sistema de superviso mvel.............................70 Figura 4.8: Diagrama de Casos de Uso do Sistema................................... 72 Figura 4.9: Diagrama de seqncia geral do sistema................................. 77 Figura 4.10: Diagrama de atividades do sistema.........................................78

ix

Figura 4.11: Modelo da Tabela principal do Banco de Dados do iFIX.........78 Figura 4.12: Diagrama e foto da estrutura montada em laboratrio para o sistema de superviso mvel............................................................80 Figura 4.13: Endereamento IP da rede montada em laboratrio.............. 81 Figura 4.14:Resultados de pings originados no n SCADA aos demais componentes do sistema.............................................................................82 Quadro 4.2: Descrio dos principais itens configurados no grupo EC_05D_01.................................................................................................83 Figura 4.15: Detalhe mostrando o OPC da ABB, utilizado como OPC Server no sistema...................................................................................................84 Figura 4.16: OPC Power Tool com destaque em algumas estatsticas......84 Figura 4.17: Configuraes do grupo EC_05D_01.....................................85 Figura 4.18: Tabela do componente Database Manager............................85 Figura 4.19: Interfaces desenvolvidas para o sistema de superviso mvel...........................................................................................................86 Figura 4.20: Configurao de um datalink...................................................87 Figura 4.21: Esquema geral de clientes e servidores do sistema...............88 Quadro 4.3: Descrio dos softwares instalados e configuraes feitas....88 Figura 4.22: Usurio testando o Pocket PC, com destaque para o Pocket PC................................................................................................................89 Figura 5.1: Representao geral do sistema de superviso mvel.............90 Figura 5.2: Simulador da planta industrial utilizado no single node.............91 Figura 5.3: Programa OPC Server Configuration........................................91 Figura 5.4: iFIX rodando..............................................................................92 Figura 5.5: Interface do SDCD real (online).................................................93 Quadro 5.1: Valores utilizados nos testes....................................................93 Figura 5.6: Modificando manualmente o valor de um tag, de 0.00 para 86.3..............................................................................................................94 Figura 5.7: Resultados dos testes com os filtros (a) 1; (b) 2; (c) 3; (d) 4; (e) 5............................................................................................................94 Figura 5.8: Algoritmo desenvolvido para automatizar o valor do tag PT_05D_020, na linguagem do software e no pseudocdigo.....................96 Tabela 5.1: Resultados da primeira medio..............................................98 Figura 5.9: Grficos com os resultados da primeira medio.....................98 Tabela 5.2: Resultados da segunda medio.............................................99 Figura 5.10: Grficos com os resultados da segunda medio..................99 Tabela 5.3: Resultados da terceira medio...............................................100 Figura 5.11: Grficos com os resultados da terceira medio....................100 Tabela 5.4: Resumo dos dados levantados nas medies.........................101 Figura 5.12: Grfico com as mdias gerais obtidas nas trs medies......101 Figura 5.13: OPC Power Tool, com destaque para dados estatsticos importantes..................................................................................................102 Figura 5.14: Diferena na estatstica do tag PT_05D_01, detectada Durante os testes com o filtro 2...................................................................103

Figura 5.15: Interface do software Ping Tester Professional 9.23, com destaque para o resumo dos parmetros que ele capaz de avaliar.........104 Tabela 5.5: Resultados das anlises feitas pelo Ping Tester Professional.................................................................................................105 Figura 5.16: Grfico com dados de pacotes................................................105 Figura 5.17: Grfico da taxa de perda de pacotes......................................106 Figura 5.18: Grfico do tempo mdio (RTT)................................................106 Figura 5.19: Relatrio referente ao teste 1 do Ping Tester..........................107 Figura 5.20: Relatrio referente ao teste 2 do Ping Tester..........................107 Figura 5.21: Relatrio referente ao teste 3 do Ping Tester..........................108 Figura 5.22: Relatrio referente ao teste 4 do Ping Tester..........................108

xi

LISTA DE ABREVIATURAS ABB - Asea Brown Boveri AE - Alarms and Events AGC - Automatic Generation Control AI - Analog Input AMR - Automatic Meter Reading AP - Access Point AR - Analog Register ASE - High Speed Ethernet BI - Boolean Input BSC - Balanced Scorecard CD - Compact Disk CF - Compact Flash CLP - Controlador Lgico Programvel COM - Component Object Model CPU - Central Processing Unit CSMA/ CA - Carrier Sense Multiple Access/ Colidion Avoidance DA - Data Access DAR - Decantador de Alto Rendimento DCOM - Distributed Component Object Model DDE - Dynamic Data Exchange DI - Digital Input DIT- Drive Image Table DMACS - Distributed Manufacturing Automation and Control Software DMS - Distribution Management System DNS - Domain Name Server DO - Digital Output DR - Digital Register DSSS - Direct Sequence Spread Spectrum EMS - Energy Management System FF - Foundation Fielbus FHSS - Frequency Hopping Spread Spectrum

xii

FTP - File Transfer Protocol GE - General Electrics GEBAN - Gerncia da rea Branca GEPOR - Gerncia de Porto GETIL - Gerncia da rea de Utilidades GEVER - Gerncia da rea Vermelha HART - Highway Addressable Remote Transducer HDA - Historical Data Access HTTP - Hypertext Transfer Protocol I/O - In/ Out (Entrada/Sada) IBSS - Independent Basic Service Set IDE - Integrated Development Environment IDL - Interface Definition Language IDS - Intrusion Delection System IEEE - Institute of Electrical and Electronics Engineers IHM - Interface Homem-Mquina IrDA - Infrared Data Asociation LAN - Local Area Network LM - Load Management MTU - Master Terminal Unit OLE - Object Linking and Embedding ON/ OFF - Ligado/ Desligado OPC - OLE for Process Control OSI - Open System Interconnection PARC - Palo Alto Research Center PC - Personal Computer PCMCIA - Personal Computer Memory Card International Association PCP - Planejamento e Controle de Produo PDA - Personal Digital Assistant PDB - Process Database PI - Plant Information PID - Proporcional Integral e Derivativo PLC - Programable Logic Controller

xiii

PPA - Process Portal A RS232 - Recomended Standard 232 RS485 - Recomended Standard 485 RTT Round Trip Time RTU - Remote Terminal Unit SAC - Scan Alarm and Control SCADA - Supervisory Control and Data Acquisition SCU - System Configuration Unit SD - Secure Digital SDCD - Sistema Digital de Controle Distribudo SOAP - Simple Object Access Protocol SUPMOV1 - Superviso Mvel 1 SUPMOV2 - Superviso Mvel 2 TCP/IP - Transport Control Protocol/ Internet Protocol TI - Tecnologia da Informao TR Trend TS - Terminal Server UA - Unified Architecture UML - Unified Modeling Language VB - Visual Basic VBA - Visual Basic for Application VPN - Virtual Private Network WEP - Wired Equivalent Privacy WLAN - Wireless Local Area Network WMAN - Wireless Metropolitan Area Network WPAN - Wireless Personal Area Network WWAN - Wireless Wide Area Network XML - Extensible Markup Language

LISTA DE SMBOLOS - ohm(s)

xiv

SUMRIO

1 INTRODUO ........................................................................................................ 1 1.1. ESTRUTURA DO TRABALHO .......................................................................................3 2 CONTEXTUALIZAO DO PROBLEMA............................................................... 4 2.1. PROCESSO PRODUTIVO DA ALUNORTE [2] [3] [4] [5] .................................................4 2.2. REA-PILOTO ..................................................................................................................7 2.2.1. rea da Filtrao [2] [10] .................................................................................................9 2.3. SISTEMAS DE AUTOMAO......................................................................................12 2.4. SITUAO-PROBLEMA ...............................................................................................14 2.5. SOLUO PROPOSTA ................................................................................................16 3 FUNDAMENTAO TERICA ............................................................................ 18 3.1. A AUTOMAO DE PROCESSOS INDUSTRIAIS ..................................................18 3.2. SISTEMAS SUPERVISRIOS .....................................................................................20 3.2.1. Caractersticas e propriedades ................................................................................21 3.2.2. Estrutura ......................................................................................................................23 3.2.3. Sistemas SCADA .......................................................................................................24 3.2.4. Interfaces Usurio-Computador ...............................................................................25 3.2.5. Desenvolvimento de Interfaces Usurio-Computador..........................................26 3.2.6. Sistemas Supervisrios atuais .................................................................................29 3.3. O SDCD SISTEMA DIGITAL DE CONTROLE DISTRIBUDO ............................32 3.3.1. Semelhanas e diferenas entre SDCD e CLP [40] [41] ..........................................34 3.4. REDES DE COMUNICAO INDUSTRIAL ..............................................................38 3.4.1. Redes Foundation Fieldbus (FF) .............................................................................40 3.4.2. Redes Ethernet e protocolo TCP/IP [47] [48] .............................................................41 3.4.3. Redes sem fio (wireless) ...........................................................................................45 3.4.4. Segurana em redes de automao industrial [56] [24] ...........................................52 3.4.5. Terminal Services .......................................................................................................54 3.5. A TECNOLOGIA OPC (OLE FOR PROCESS CONTROL) .....................................55 4 DESENVOLVIMENTO DO SISTEMA ................................................................... 60 4.1. SISTEMA SUPERVISRIO [65] [33] ...............................................................................60 4.2. HARDWARE ....................................................................................................................67 4.2.1. Dispositivo mvel........................................................................................................67 4.2.2. Ponto de acesso (AP) ................................................................................................67 4.2.3. Switch ...........................................................................................................................69 4.3. MODELAGEM DO SISTEMA........................................................................................70 4.4. CONFIGURAO DO SISTEMA .................................................................................79

xv

4.4.1. Instalao ....................................................................................................................79 4.4.2. Configurao ...............................................................................................................82 5 APRESENTAO DOS RESULTADOS .............................................................. 90 5.1. SISTEMA FINAL .............................................................................................................90 5.2. TESTES ............................................................................................................................92 5.3. ANLISE ESTATSTICA DO OPC...............................................................................97 5.4. ANLISE ESTATSTICA DA REDE ...........................................................................103 6 CONCLUSES E CONSIDERAES FINAIS ................................................... 110 REFERNCIAS BIBLIOGRAFICAS ...................................................................... 112 ANEXO 1 ................................................................................................................ 118 ANEXO 2 ................................................................................................................ 120

1 INTRODUO

Diariamente a sociedade se depara, em diversos ramos do conhecimento humano, com o avano da tecnologia e seus desafios, que no so poucos. Com automao industrial isso no poderia ser diferente. O conceito e a aplicao de automao industrial vm sendo repensados nos ltimos anos, dado o grande desenvolvimento experimentado nessa rea, impulsionado pelos crescentes desafios. At antes do surgimento dos primeiros Personal Computers Computadores Pessoais (PCs) a automao industrial se caracterizava pelo imobilismo. Se uma empresa queria automatizar seu processo ela escolhia uma marca e a empresa responsvel desenvolvia toda a tecnologia de forma proprietria, estabelecendo entre elas uma relao de forte dependncia. Com o advento do PC os painis sinpticos deixaram de existir, bem como as mesas de controle. Assim todas as operaes relacionadas puderam ser centralizadas em um nico equipamento, o computador. Como conseqncia, surgiram e evoluram os sistemas de Controle Supervisrio e Aquisio de Dados (SCADA), trazendo novas funcionalidades ao processo. Com o passar do tempo e a evoluo natural do mercado, algumas grandes empresas se consolidaram, investindo cada vez mais em tecnologia. Paralelamente desenvolvia-se o protocolo HART de instrumentao e diversos tipos de redes industriais que se firmaram e at hoje so largamente utilizadas. O campo de atuao da automao foi se expandido, rompendo os limites do ambiente de cho de fbrica, na medida em que novos tipos de processos foram surgindo e hoje se nota aplicaes da automao em sistemas que envolvem desde gerncia de informao e negcios em tempo real at sistemas crticos no campo mdico, por exemplo. [1] Com este crescente avano da tecnologia, e a atual necessidade de informao em todos os campos, os sistemas de automao modernos deixaram de ser simples automaes de processos e equipamentos para envolver tambm a automao de negcios, lidando com grandes quantidades de informao relevante.

A partir desse momento surgia outro desafio, gerenciar e otimizar a grande quantidade de informaes geradas. A gerncia de informaes industriais surgiu na medida em que, com o amadurecimento das tecnologias dos equipamentos de campo inteligentes, uma grande quantidade de informaes possibilitadas por eles pode agora ser disponibilizada para outras aplicaes em outros nveis de tecnologias, sendo possvel organiz-las, por exemplo, em formato conveniente para anlise de processos industriais. [1] Diante dessa realidade, constatada na prtica na Alunorte Alumina do Norte do Brasil S.A, surgiu a motivao para o desenvolvimento deste trabalho. A quantidade de dados gerados pelo processo e coletados pelos sistemas de automao enorme e precisa ser distribuda a quem precisa dela. Pensando nisso, desenvolveu-se um sistema de superviso mvel, cujo principal objetivo disponibilizar, em tempo real, informaes do processo a quem precisa delas, dando suporte tomada decises e possibilitando aes rpidas. Inicialmente o sistema foi desenvolvido pensando-se em atingir os profissionais que atuam diretamente no campo, como forma de diminuir a dependncia deles em relao sala de controle, onde essas informaes encontram-se disponveis, mas centralizadas. No entanto, devido sua caracterstica de mobilidade o sistema pode facilmente ser utilizado por gerentes e outras pessoas que tambm necessitem, com freqncia, desse tipo de informao. Seus benefcios podero ser sentidos pelas pessoas que o utilizam, j que elas no precisaro consultar a sala de controle com freqncia e nem se deslocar at certos equipamentos, de difcil acesso, para obter determinados medidas de variveis como a temperatura de um tanque, por exemplo. Os equipamentos e a planta industrial tambm estaro sendo supervisionados por mais pessoas, o que diminui o risco de acidentes com pessoas e quebra de equipamentos, pois as falhas sero detectadas e aes sero tomadas com mais rapidez. Dessa forma, todos saem ganhando. O novo sistema est baseado em tecnologias como o OPC, para comunicao industrial; wireless, para garantir mobilidade; no uso de dispositivos mveis que trazem praticidade; na definio de arquitetura cliente-servidor; no uso de redes de computadores entre outros.

O produto final deste trabalho ser um sistema de superviso rodando em um dispositivo mvel e atualizando, em tempo real, as informaes de processo, obtidas a partir do supervisrio da empresa, que adquire e trata os dados.

1.1.

ESTRUTURA DO TRABALHO

Este trabalho encontra-se dividido em seis captulos, sendo que o primeiro a introduo; o segundo contextualiza o problema; o terceiro traz a fundamentao terica necessria ao entendimento dos demais captulos; o quarto mostra o desenvolvimento do sistema; o quinto enfatiza os resultados alcanados pelo sistema e o sexto so as concluses e consideraes finais. No segundo captulo, de contextualizao do problema, apresentado o processo produtivo da Alunorte, com destaque para a rea-piloto escolhida para o desenvolvimento do trabalho, bem como os critrios que levaram a essa escolha. Ainda so apresentadas consideraes sobre os sistemas de automao da empresa, bem como sobre a situao-problema que motivou esse trabalho e a soluo proposta nele. No terceiro captulo h toda uma fundamentao terica, necessria ao desenvolvimento do trabalho. Os principais tpicos abordados so: a automao de processos industriais, sistemas supervisrios, o Sistema Digital de Controle Distribudo (SDCD), redes de comunicao industrial e a tecnologia OLE for Process Control (OPC). O quarto captulo traz detalhes sobre o desenvolvimento do sistema tais como o software e o hardware utilizado, uma breve descrio da modelagem do sistema e detalhes da implementao do sistema (instalao e configurao). O sistema final, obtido, os testes feitos com ele e os resultados alcanados so apresentados no captulo cinco. Por fim, as concluses adquiridas durante o desenvolvimento do trabalho, as recomendaes de melhorias e trabalhos futuros so apresentadas no sexto e ltimo captulo.

2 CONTEXTUALIZAO DO PROBLEMA

Neste captulo deseja-se esclarecer a situao que motivou este trabalho e a proposta de melhoria que ele apresenta, dentro do contexto de um ambiente industrial, uma refinaria de alumina.

2.1.

PROCESSO PRODUTIVO DA ALUNORTE [2] [3] [4] [5]

A Alunorte Alumina do Norte do Brasil S.A, empresa na qual este projeto foi implementado, est localizada a 40 km, em linha reta, da capital do Estado do Par, Belm, no municpio de Barcarena. A empresa hoje a maior refinaria de alumnio do mundo, com capacidade para produzir 6,3 milhes de toneladas de alumina por ano. O processo Bayer, desenvolvido por Karl Josef Bayer em 1888, o principal processo industrial de produo de alumina (xido de alumnio Al2O3). Esse processo utilizado na Alunorte e est representado na figura 2.1.

Figura 2.1: Viso geral do Processo Bayer [2]

A matria-prima para a produo da alumina a bauxita, minrio encontrado em larga escala no Par. A bauxita utilizada na Alunorte vem em navios e atravs de um mineroduto, proveniente de Porto Trombetas e Paragominas, respectivamente. A primeira etapa do processo de produo da alumina a moagem. Moinhos combinados de barras e bolas processam a bauxita j em mistura com soluo de soda custica e leite de cal. A etapa seguinte digesto, na qual a bauxita atacada por uma soluo custica pr-aquecida, formando o aluminato de sdio. Na Alunorte, isto feito em baterias de digestores que operam segundo o processo Bayer de baixa temperatura cerca de 150C e asseguram a completa extrao da alumina e a eliminao da slica solvel. A descompresso da mistura que flui no ltimo digestor feita em tanques de expanso, que reduzem a temperatura da mistura e geram vapor, reutilizado no processo. O produto do ltimo tanque de expanso contm alumina em soluo e resduos de bauxita em suspenso, que precisam ser separados. Os resduos de granulao mais grossa so facilmente retirados, mas a maior parte, composta de grnulos finos s separada em espessadores e com o auxlio de agentes floculantes, para acelerar a decantao. Neste processo de separao, os resduos de bauxita que formam a chamada lama vermelha passam por um circuito de espessadores e filtros que asseguram uma eficincia de lavagem superior a 99%. Em seguida, so descartados no depsito de rejeitos, dentro de um rgido controle ambiental, de forma que esta rea possa ser reflorestada depois. Ainda necessrio passar pela etapa da filtrao. Nela so removidas as ltimas partculas em suspenso atravs de uma bateria de filtros verticais, garantindo assim a alta qualidade do produto. Depois de filtrada, a soluo de processo - tambm chamada de licor rico resfriada em tanques de expanso a vcuo, permitindo a recuperao de vapor que, como na digesto, reutilizado no processo. Esse procedimento minimiza o consumo de energia. O licor rico direcionado ento para os precipitadores. Nos precipitadores a soluo filtrada se decompe em uma reao qumica desencadeada pela adio de semente, que o hidrato em granulao fina obtido

no prprio ciclo de precipitao. Assim se obtm a alumina hidratada o hidrato e se recupera a soda custica, que reciclada para a digesto. Os cristais de hidrato formados na precipitao so classificados em duas partes (etapa de classificao): a frao grossa hidrato produto, que seguir para a etapa seguinte, a calcinao, e as partculas finas, as quais so recicladas como semente para a reao na precipitao. Na calcinao toda a gua livre ou combinada do hidrato eliminada, formando o xido de alumnio ou, simplesmente, alumina. Essa reao requer aquecimento em cmara de combusto com temperatura controlada em torno de 1000C, localizada dentro dos calcinadores estacionrios de leito fluidizado, equipamentos dentro dos quais acontece essa fase. A alumina obtida nos calcinadores transportada para os silos por correia transportadora. Dos silos, o produto transferido e embarcado aos clientes no porto de Vila do Conde ou ento segue para a Albrs, fbrica de alumnio situada prxima refinaria. A alumina pode ser utilizada tambm na fabricao de detergentes, produtos de limpeza, compostos para tratamento da gua, supressores de fumaa, materiais pticos e pastas de dente, alm de atender tambm indstria plstica, de mrmore, granito sinttico e isolante. Para atender as necessidades de aquecimento dos processos, a Alunorte instalou sistemas de caldeiras a leo, carvo e energia eltrica. Estes sistemas operam de forma alternada ou paralelamente, de acordo com a disponibilidade de energia secundria no sistema Eletronorte. Um fluxograma bsico do processo pode ser encontrado na figura abaixo:

Figura 2.2: Fluxograma bsico da Alunorte [3]

Na Alunorte, cada etapa do processo tem uma numerao e elas foram agrupadas em reas, por questes administrativas. As reas operacionais so: GEPOR rea do Porto, GEVER - rea Vermelha, GEBAN rea Branca e GETIL rea de Utilidades, sendo a GEVER e a GEBAN as duas maiores reas.

2.2.

REA-PILOTO

Na fase inicial de implantao do projeto escolheu-se uma rea-piloto para a realizao dos testes com o sistema e para coletar dados dos experimentos. Em se obtendo resultados satisfatrios ser analisada a viabilidade financeira para implantao em mais reas da fbrica. Os dados analisados para a escolha da rea originaram-se das seguintes fontes: BSC (Balance Scorecard): Sistema de gesto da estratgia de um negcio. O termo pode ser traduzido para Indicadores Balanceados de Desempenho ou Cenrio Balanceado. Atravs do BSC a estratgia da empresa pode ser traduzida em objetivos, metas e medidas especficas. [6] [7] Sistema PI (Plant Information): Desenvolvido pela OSI Software, o PI um conjunto de mdulos (softwares) projetados para monitoramento e anlise de plantas industriais. O principal mdulo do sistema o PI Data Archive (arquivo de dados), que armazena os dados do processo. [8] PCP (Setor de Planejamento e Controle de Produo): rea responsvel pelo gerenciamento de recursos. Este gerenciamento em nvel do cho de fbrica significa utilizar de maneira eficiente a mo-de-obra, a matria-prima, as mquinas, entre outros.[9] Especialistas: Profissionais aptos a esclarecer dvidas em questes especficas, como sade e segurana no trabalho, por exemplo. Uma vez definidas as fontes de pesquisa os dados estatsticos obtidos foram interpretados, de acordo com os seguintes critrios:

a) Performance operacional: Esse critrio avaliou as paradas e as perdas de produo no perodo de setembro de 2008 a fevereiro de 2009. Concluiu-se que a rea mais crtica foi a vermelha, mais especificamente a rea de filtrao de licor, pois foi a rea em que a perda calculada, em toneladas, foi maior no perodo considerado. b) Segurana no Trabalho: Para mensurar o nvel de segurana no trabalho normalmente so utilizados dados referentes taxa de acidentes srios ocorridos. A anlise dos dados apontou a GEBAN, seguida pela GEVER, como as reas em que mais ocorreram acidentes srios em 2008. Na rea vermelha os acidentes no causaram afastamento dos empregados envolvidos, enquanto na branca 50% dos empregados foram afastados de suas atividades operacionais. c) Importncia no processo: Esse critrio avaliou a rea mais crtica do processo produtivo da empresa. Nesse quesito destacou-se mais uma vez a rea vermelha, a qual determina a produtividade da planta. d) Risco Ambiental: Na Alunorte, o monitoramento ambiental feito principalmente em termos de efluentes industriais e qualidade do ar. Os efluentes so tratados na rea GETIL e as emisses mais significativas so provenientes dos calcinadores (GEBAN) e caldeiras (GETIL). Nesse sentido, a rea mais importante a GETIL. Como forma de levantar maiores informaes, principalmente no que se refere necessidade da ferramenta criou-se um critrio comportamental. Para avali-lo foi feita uma entrevista, apresentada no anexo 1, com diferentes profissionais das reas operacionais. A pesquisa foi respondida por 6 profissionais de cada rea, entre engenheiros e operadores de rea, exceto na GEBAN, em que apenas um operador respondeu ao questionrio. Vale destacar que a entrevista era annima, para que as pessoas se sentissem mais vontade para expressarem suas opinies. A anlise das entrevistas aponta as reas GEVER e GETIL, como sendo as reas em que a implantao do projeto seria mais importante, so as que mais precisam de informaes do SDCD, solicitadas sala de controle com muita freqncia e em ambas os operadores sentem dificuldade em obter algumas informaes, tais como medies de nvel, por exemplo. Os profissionais pesquisados nessa rea j tiveram contato com dispositivos mveis (80% dos

entrevistados), ou seja, j existe certa familiaridade com dispositivos mveis. A rea em que os entrevistados sentem maior presena de risco ambiental a GETIL. Ponderando-se todas essas consideraes concluiu-se que a rea Vermelha, GEVER, a mais indicada para a implantao do projeto, mais especificamente a Filtrao de Licor Rico (rea 5).

2.2.1. rea da Filtrao [2] [10]

Dentro do processo Bayer a etapa de Filtrao de Licor pode ser vista observando-se o destaque na figura abaixo:

Figura 2.3: Filtrao de Licor Rico dentro do Processo Bayer [2]

O objetivo desta rea remover os slidos residuais do transbordo dos decantadores/DARs (Decantadores de Alto Rendimento) da rea de decantao e Lavagem de Lama, resultando em um licor rico filtrado purificado que seguir para a rea de Resfriamento Vcuo. Para atingir esse objetivo existe um circuito de filtrao, composto de vrios filtros, cujo layout apresentado na figura 2.4. O processo da filtrao ser explicado a seguir.

10

Figura 2.4: Layout da rea 5 [10]

A rea de filtrao deve ser operada de forma que a vazo de alimentao dos filtros seja igual do transbordo dos decantadores. A filtrao um processo cclico descontnuo. As etapas deste processo esto resumidas no quadro 2.1.

Quadro 2.1: Ciclo de filtrao ETAPA 1 NOME DA ETAPA Enchimento do corpo do filtro Refiltrao Filtrao DESCRIO O filtro cheio decantadores (DAR). com transbordo dos

2 3

Filtrado desviado para Tanque de Refiltrao. Filtrado claro coletado no Tanque de Licor Rico Filtrado.

Lavagem do filtro Alimentao do filtro transferida do licor de transbordo dos decantadores para o licor de lavagem do primeiro estgio de lavagem de lama. O licor de lavagem dever ser filtrado para remover o licor rico na torta de lama aderida ao tecido do filtro e ser coletado no tanque no Tanque de licor rico Filtrado.

11

Drenagem

A torta de lama aderida ao tecido do filtro lavada atravs do jateamento com licor de lavagem proveniente do transbordo do 3 estgio de lavagem de lama. A torta de lama drenada para o tanque de transferncia de lama. Filtro fica em reserva, preparado para pronta operao. Fonte: [10]

Reserva

Nos filtros existem telas, revestidas por tecidos nos quais, ao longo do processo, vo se formando tortas de lama. O tecido da tela consiste de uma fibra sinttica resistente soluo custica, com propriedade de liberar e capacidade de reter a lama, com alta e suficiente permeabilidade, proporcionando uma taxa de filtrao excelente. Para no reduzir a eficincia da filtrao o tecido rejuvenescido pela lavagem regular com soda custica. Para facilitar o entendimento seguem-se algumas fotos reais do existe implantado na Alunorte.

(a)

(b)

Figura 2.5: (a) Filtro de presso vertical visto de cima e (b) debaixo [2]

12

2.3.

SISTEMAS DE AUTOMAO

Na Alunorte, o Sistema Supervisrio utilizado o PPA (Process Portal A) cujo fabricante a ABB e todo o processo produtivo controlado por um SDCD, o 800xA, tambm da ABB. Desde o incio da fbrica, em 1995, optou-se pelo SDCD por ser um sistema mais robusto, principalmente para grandes aplicaes, como o caso da refinaria. Na Alunorte o SDCD controla cerca de 5000 tags de equipamentos. A arquitetura distribuda consiste em colocar cartes de interface com o processo prximo a planta e a estao de operao na sala de controle. A parte que fica junto s reas de processo possui os cartes de I/O (entrada e sada analgica, entrada e sada digital) e os cartes dos controladores, ou seja, o hardware. Este hardware responsvel pela aquisio de dados junto ao processo e execuo dos algoritmos de controle e o comando para elementos finais de controle. Fisicamente, tais cartes ficam em racks dentro de painis. Esse sistema troca informao com a sala de controle atravs de uma rede de dados. As estaes de operao so as interfaces homem-mquina (IHM). Estas estaes so microcomputadores nos quais possvel visualizar telas com sinticos que representam o processo. Atravs destas estaes os tcnicos de sala de controle monitoram as vrias etapas do processo podendo alterar valores de variveis, reconhecer alarmes, ajustar parmetros de sintonia, assim como dar comandos de abrir e fechar vlvulas do sistema, por exemplo. As estaes de engenharia so mquinas onde os (as) engenheiros (as) podem visualizar tudo exatamente como os tcnicos da sala de controle visualizam, tendo a liberdade para modificar parmetros, bloquear sinais. Nessas estaes possvel tambm trabalhar no modo de desenvolvimento das interfaces, alterando inclusive a lgica, se necessrio. [4] A arquitetura do SDCD da Alunorte est representada na figura 2.6.

13

Figura 2.6: Arquitetura do SDCD da Alunorte [4]

Na figura, nota-se a presena de uma rede de planta e uma rede de controle, ambas Ethernet e com protocolo TCP/IP, mas com velocidades diferentes, devido a diferenas no volume de dados. A rede de campo, que interliga os instrumentos Foundation Fieldbus, usando uma rede de alta velcidade (HSE). A arquitetura do sistema do tipo multi node, ou seja, h vrios ns nas redes. No entanto, para realizao de testes, desenvolveu-se uma soluo single node. O single node, como tambm conhecido o equipamento, um notebook, no conectado na rede, no qual esto instalados os vrios equipamentos da rede, como servidores de aspecto, conectividade, estaes de engenharia e etc. Atravs desta mquina e possvel simular o comportamento de um controlador do sistema por vez, inserindo dados aleatoriamente ou usando como entrada dados reais, a partir de um backup do sistema real

14

2.4.

SITUAO-PROBLEMA

Atualmente, quando um operador de rea percebe uma anomalia capaz de causar danos planta ou a um componente desta, ele tem que comunicar-se rapidamente com o tcnico de sala de controle, via rdio, celular, pessoalmente ou de qualquer outra forma para obter informaes e poder realizar aes cabveis. Esse processo pode demorar alguns segundos e at minutos, tempo que muitas vezes decisivo para que ocorra um incidente. A comunicao via rdio, por sua vez, nem sempre eficaz visto que fatores como rudo e interferncia do ambiente afetam diretamente qualidade da comunicao. A situao inversa tambm acontece. Caso um tcnico na sala de controle detecte alguma situao de risco ou que precise de alguma manobra em campo, ele precisa se comunicar com a rea para tentar contornar o problema.

Figura 2.7: Uma sala de controle da Alunorte [2]

Atravs da figura pode-se perceber que o ambiente de uma sala de controle de extrema ateno e algumas vezes chega a ser tenso, devido a grande responsabilidade e o alto nvel de cobrana sobre esses profissionais, que normalmente so bastante experientes e conhecedores da rea que monitoram. Algumas manobras tambm precisam ser acompanhadas em tempo real pelos tcnicos de sala de controle como quando h a troca de instrumento ou de

15

equipamento, por exemplo, principalmente se ocorrer nas reas mais crticas do processo. Outra situao freqente em um ambiente fabril a dificuldade na obteno de algumas informaes no campo. Como os equipamentos em sua maioria so de grande porte, muitas vezes um operador necessita ler informaes no display dos equipamentos e isso pode se tornar uma tarefa rdua se este display estiver em posio de difcil acesso (muito alto ou em um espao apertado, por exemplo) ou se for noite, pois eles no possuem iluminao prpria. Um exemplo de nvel difcil de ler pode ser visto na figura 2.8. Na situao ilustrada, para ver se a vlvula est aberta ou fechada o operador precisa subir ao segundo andar do prdio e depois subir a escada vertical (amarela).

Figura 2.8: Exemplo de dificuldade de acesso

As chamadas aos tcnicos de sala so tambm realizadas por muitos engenheiros quando os mesmos precisam de informaes do SDCD para auxili-los na tomada de decises importantes. Essas e outras circunstncias fazem com que especialistas, operadores, engenheiros e demais profissionais em campo mantenham contato constantemente com a sala de controle, sobrecarregando os tcnicos e os meios de comunicao. Isso ocorre porque a informao est centralizada, em grande parte nas salas de controle.

16

2.5.

SOLUO PROPOSTA

Diante da situao exposta percebeu-se a necessidade de criar uma ferramenta que pudesse acompanhar os profissionais em seu trabalho no campo e que fornecesse essas informaes, facilitando o trabalho deles, dando-os mais autonomia para atuar. Atravs do sistema de superviso mvel proposto, essas informaes sero descentralizadas e os dados de processo coletados estaro disponveis em tempo real, de forma confivel e segura, para a superviso dos profissionais nas reas atravs de dispositivos mveis. Conseqentemente eles tero mais autonomia, o tempo de resposta ser maior, bem como seu poder de deciso e as chamadas aos tcnicos da sala de controle diminuiro. Dessa forma, mais pessoas estaro supervisionando o processo simultaneamente, garantindo assim maior agilidade na tomada de decises, maior velocidade na execuo das aes em campo (importante para proteger equipamentos) e aumentando a segurana das atividades. Outro aspecto que merece ser analisado o trabalho em conjunto. Mesmo que o sistema descentralize as informaes, conforme dito anteriormente, em alguns momentos os operadores de sala e de campo precisam trabalhar em sincronia, principalmente quando se trata de realizar alguma manobra em equipamentos ou etapas crticas do processo. Nessas situaes, em especial, muito importante que ambos os profissionais compreendam e acompanhem o status do processo para que possam realizar as operaes com segurana, analisar e encontrar erros e prever comportamentos. Tudo isso fica mais fcil se o especialista em campo dispuser de uma ferramenta mvel que lhe fornea as informaes necessrias, facilitando a comunicao e o entendimento entre ele e o tcnico na sala de controle. A estrutura de hardware bsica necessria para o sistema deve ser composta por: 1 dispositivo mvel, no mnimo; 1 ponto de acesso, no mnimo; 1 servidor, no mnimo. O servidor o responsvel pelo tratamento e manipulao dos dados recebidos do SDCD, antes de serem enviados para o dispositivo mvel.

17

Os dispositivos mveis mais comuns so mostrados na figura 2.8.

Figura 2.9: Exemplos de dispositivos mveis [11][12]

Os dados, provenientes do SDCD precisaro passar por um sistema de segurana antes de chegar ao servidor, e antes de sarem dele, por medida de segurana. Os pontos de acesso ou AP (do ingls, access point) permitem que seja estabelecida uma comunicao sem fio entre o sistema, localizado na sala da automao (prdio na rea 73 da Alunorte) e o campo, onde estar acontecendo o processo e onde o dispositivo mvel estar recebendo os dados. A figura 2.10 apresenta a estrutura descrita acima.

Figura 2.10: Estrutura do sistema de superviso mvel proposto

As linhas em azul na figura simbolizam a comunicao com fio, ethernet, com protocolo TCP/IP. usado tambm o padro OPC. Detalhes dessa implementao sero descritos no captulo 4. Neste captulo foi apresentada a situao que motivou este trabalho dentro do contexto de um ambiente fabril, tambm apresentado. Diante deste problema o ltimo sub-tpico do captulo trouxe a soluo proposta. No prximo captulo sero descritas as tecnologias e ferramentas necessrias ao desenvolvimento e implementao do sistema idealizado (figura 2.10).

18

3 FUNDAMENTAO TERICA

Neste captulo so apresentados os principais conceitos necessrios ao desenvolvimento desse trabalho, de forma a suprir as necessidades da proposta apresentada no captulo anterior. So eles: Automao de processos industriais, sistemas supervisrios, redes de comunicao industrial e OPC. Ao longo do captulo sero apresentadas algumas solues tecnolgicas disponveis no mercado atualmente.

3.1.

A AUTOMAO DE PROCESSOS INDUSTRIAIS

A automao industrial pode ser definida como uma tecnologia que visa operar e controlar processos industriais e para isso integra conhecimentos de trs grandes reas: a eletrnica, responsvel pelo hardware, a mecnica, na forma de atuadores e outros dispositivos, e a informtica responsvel pelo software que ir controlar todo o sistema. [13] Com a implantao de sistemas automatizados as indstrias ganham principalmente em competitividade, na melhoria das condies de trabalho e de segurana das pessoas e equipamentos. De uma forma geral, sistemas automatizados apresentam a seguinte configurao:

Figura 3.1: Diagrama representativo de um sistema automatizado [13]

O processo produtivo um conjunto de funes e/ou operaes usadas no tratamento de um material ou matria-prima [14], o objeto da automao, a partir

19

do qual sero colhidas as informaes necessrias para implementar o controle automtico. Os responsveis pela coleta de informaes do processo so os sensores: dispositivos conectados aos equipamentos em campo e que convertem parmetros fsicos tais como velocidade, nvel de gua e temperatura, para sinais analgicos ou digitais.[15]. Os sensores podem ser classificados, de acordo com a aplicao, em detectores ou medidores, conforme as caractersticas abaixo: Detectores: so capazes de capturar e sinalizar informaes representadoas somente nos estados ON/OFF. Os detectores de fim de curso, de proximidade e as clulas fotoeltricas podem funcionar como detectores. Medidores: so capazes de capturar e sinalizar informaes

representando-as em um nmero muito grande de estados representando valores medidos. Os sensores de posio, de temperatura, de presso e de peso so exemplos de instrumentos deste tipo. [16] Os atuadores so utilizados para atuar sobre o sistema de acordo com as tarefas ordenadas pelo controlador, como ligar e desligar determinados equipamentos, por exemplo. Incluem-se no grupo dos atuadores os rels auxiliares, os contatores e conversores eletrnicos e os variadores de velocidade/freqncia. [16] O controlador um elemento computacional responsvel pelo acionamento dos atuadores, levando em conta o estado das entradas (sensores) e as instrues do programa inserido em sua memria. Devido presena deste dispositivo pode-se dizer tambm que o sistema representado na figura 3.1 um sistema de controle em malha fechada. Diante de todas essas informaes faz-se necessrio uma forma de acompanhar e gerenciar as aes que devem ser tomadas para otimizar e controlar o processo como um todo e os sub-processos existentes em cada etapa, detalhadamente. nesse contexto que surgem os sistemas supervisrios.

20

3.2.

SISTEMAS SUPERVISRIOS

Com o aumento da complexidade dos sistemas produtivos atuais, a quantidade de informaes necessrias para um gerenciamento eficaz da produo se torna cada vez maior. Conseqentemente, apenas o conhecimento emprico do processo, proveniente dos profissionais mais experientes, no suficiente, sendo necessrio algum tipo de controle mais especfico, inteligente e automtico para monitorar tais informaes. Estas funes so desempenhadas pelos sistemas supervisrios. A seguir so apresentadas algumas definies destes sistemas, com suas respectivas fontes:

Sistema supervisrio um sistema em tempo real que coleta dados do processo, gera relatrios e grficos e processa esse conhecimento para otimizar a tomada de decises. [17]

Sistemas supervisrios so sistemas computacionais que permitem a monitorao de informaes de processos produtivos ou de dispositivos de automao e de plantas industriais.[18].

Sistemas Supervisrios englobam todos os equipamentos de indicao de controle e equipamentos telemtricos associados na estao principal, alm de todos os dispositivos complementares nas estaes remotas. [19] Diante dessas definies, pode-se dizer que, de uma forma geral, eles so responsveis pela monitorao das informaes de uma planta industrial, pelo processamento dessas informaes e pela tomada de deciso, seja ela atravs de uma ao de controle ou no. Resumidamente, pode-se descrever um sistema de superviso em um ambiente industrial automatizado como sendo composto por quatro elementos: Processo Fsico: o elemento principal do sistema e representa o objeto da superviso, conforme descrito anteriormente.

21

Hardware de Controle: utilizado na interface fsica com o processo e, geralmente, no controle deste; Software de Superviso: responsvel pela aquisio, tratamento e distribuio dos dados; Rede de Comunicao: responsvel pelo trfego das informaes, constituindo-se, geralmente, de duas sub-redes denominadas rede de campo e rede local de superviso ou rede de controle. A rede de campo responsvel pela aquisio dos dados do processo, enquanto a rede local de superviso responsvel por tornar disponveis e compartilhar os dados do processo em uma LAN (Local Area Network - Rede de rea Local). [16]

3.2.1. Caractersticas e propriedades

Em geral, os supervisrios operam em dois modos distintos: Modo de desenvolvimento: modo no qual so definidas as variveis de processo e controle a serem monitoradas/manipuladas, criadas as telas grficas, definidos os alarmes e realizadas as configuraes. Modo runtime: modo de apresentao de telas, animao de objetos criados no modo de desenvolvimento e operao integrada com Programmable Logic Controller (PLC) ou PC. [20] As variveis envolvidas em um determinado processo de superviso podem ser, por exemplo: temperatura, nvel e vazo, nas quais o sistema pode verificar as condies de alarmes, identificadas quando o valor da varivel ultrapassa uma faixa de condio pr-estabelecida, sendo possvel armazenar os registros em banco de dados, ativar som, enviar mensagens, alternar cores, etc. [18]. Um exemplo tpico de controle executado por um sistema supervisrio est na figura 3.2.

22

Figura 3.2: Controle tpico de um supervisrio. [21]

Fora do modo de desenvolvimento, as principais funes desempenhadas envolvem: [22] Aquisio de dados: Fornece medies telemtricas e informaes de status ao operador. Tagueamento: Os tags so todas as variveis numricas ou alfanumricas envolvidas na aplicao (variveis de processo), podendo executar funes computacionais (operaes matemticas, lgicas, com vetores ou strings, etc) ou representar pontos de entrada/sada de dados do processo que est sendo controlado [15]. A identificao atravs dos tags, operao conhecida como tagueamento, identifica o dispositivo para prevenir operaes no autorizadas, definindo operaes especficas. Tendo conhecimento das normas de tagueamento entende-se, por exemplo, que o tag LT-05A-100 indica um transmissor de nvel, localizado na rea 05A com nmero de srie 100. Alarmes: Informam ao operador sobre eventos no planejados e condies

de operao indesejadas. Os alarmes so ordenados por criticidade, rea de responsabilidade e cronologia. Quando esses alarmes disparam solicitado que se faa o reconhecimento (acknowledgment). Logging: Armazena, em arquivos de log, todas as entradas dos operadores, alarmes e outras informaes previamente configuradas. Trending: Plota grficos de medio em escalas de tempo selecionadas.

23

3.2.2. Estrutura

Uma descrio detalhada da estrutura bsica de um supervisrio pode ser encontrada a seguir:

Figura 3.3: Sistema Supervisrio Tpico. [23]

A interface com usurio ou interface homem-mquina (IHM) ou ainda interface usurio-computador, apresenta os dados para o operador e oferece entradas de controle em diferentes formatos incluindo grficos, janelas, menus, etc. [24] A estao de monitorao central (MTU, do ingls Master Terminal Unit) a unidade principal, responsvel por recolher a informao gerada pelas estaes remotas e agir em conformidade com os eventos detectados, podendo ser centralizada num nico computador ou distribudas por uma rede de computadores, de modo a permitir o compartilhamento das informaes coletadas [15]. As estaes remotas (RTU do ingls Remote Terminal Unit) enviam sinais de controle para os dispositivos sob controle, fazem aquisio de dados desses dispositivos e transmitem dados para a MTU. Uma RTU pode ser um CLP, por exemplo. A taxa de dados entre a RTU e os dispositivos relativamente alta e o mtodo de controle utilizado normalmente o de malha fechada [24]. Os dispositivos eletrnicos inteligentes incluem subestaes de controle, proteo e instrumentos, possuem microprocessadores programados para monitorar e/ou calcular os vrios parmetros do sistema necessrios para que eles tenham uma performance operacional satisfatria.Fazem parte do hardware de controle [25]. A rede de comunicao a plataforma por onde as informaes fluem dos RTUs para o sistema e, levando em considerao os requisitos do sistema e a

24

distncia a cobrir, pode ser implementada atravs de cabos Ethernet, fibras pticas, linhas dial-up, linhas dedicadas, rdio modems, etc.[15] Os modems, por sua vez, fazem parte dessa rede e so dispositivos moduladores/demoduladores que convertem sinais digitais (binrios) em sinais apropriados para o canal de comunicao. [19] Entradas e sadas digitais normalmente so incorporadas ao hardware de aquisio de dados para controlar rels, testar dispositivos digitais, etc. [26] Dados analgicos so usados para descrever caractersticas fsicas (como voltagem e corrente, por exemplo), que normalmente variam de maneira contnua. O contedo da informao de um sinal analgico expresso pelo valor ou magnitude de alguma caracterstica do sinal como amplitude, fase, freqncia, durao do pulso, etc. Um exemplo desse tipo de magnitude so os sinais de 4 a 20mA. Uma indicao de 20 mA em uma vlvula quer dizer, por exemplo, que ela est totalmente aberta, enquanto 4mA indica totalmente fechada.[27]

3.2.3. Sistemas SCADA

Na literatura alguns autores consideram sistemas supervisrios e sistemas SCADA como sinnimos. Diante dessa divergncia de conceitos entende-se que a definio mais aceitvel de sistemas SCADA a que se segue:

Sistemas SCADA podem ser definidos como uma tecnologia capaz de coletar dados de um ou mais instrumentos, fisicamente distantes, e/ou enviar instrues de controle para estes instrumentos. [24] Pode-se concluir, ento, que este tipo de sistema, apesar de apresentar todas as caractersticas de um supervisrio tradicional, conforme descrito na seo 3.2.2, envolve tambm funes de controle supervisrio, as quais permitem que os operadores controlem dispositivos remotamente, abrindo e fechando circuitos, por exemplo. Ou seja, um sistema SCADA pode ser mais abrangente do que um supervisrio tradicional, dependendo da aplicao.

25

As aplicaes mais comuns na indstria envolvem as etapas da gerao, transmisso e distribuio de energia, destacando-se os sistemas Automatic Generation Control (AGC), Energy Management System (EMS), Distribution Management System (DMS), Load Management (LM) e Automatic Meter Reading (AMR).[23]

3.2.4. Interfaces Usurio-Computador

Uma interface pode ser definida como o lugar onde ocorre contato entre duas entidades. algo discreto e tangvel em que se pode mapear, desenhar, projetar, implementar e acrescentar um pacote de funcionalidade existente. Quando as duas entidades envolvidas so um homem e uma mquina, temos a interface homemmquina. Se a mquina em questo for um computador esta pode tambm ser chamada de interface usurio-computador. Os softwares aplicativos para o desenvolvimento das interfaces tm apresentado grande evoluo nessa rea. [28] As interfaces grficas com o usurio proporcionam a virtualidade do processo, ou seja, a representao da realidade que pode ser manipulada. Entretanto, o simples fato de ferramentas computacionais serem desenvolvidas sob uma interface grfica com o usurio no assegura que elas representaro efetivamente o modelo mental que o usurio possui da tarefa a ser executada, podendo resultar em longos perodos de treinamento, elevadas taxas de erros, ansiedade, desinteresse e frustrao, causando baixa produtividade e at a no utilizao da ferramenta. [28] Dada esta situao entende-se a importncia de escolher o processo pelo qual a interface ser desenvolvida, conduzindo ento, um ciclo de desenvolvimento de software, descrito na prxima subseo.

26

3.2.5. Desenvolvimento de Interfaces Usurio-Computador

No desenvolvimento das interfaces deve ser considerado no apenas o hardware e o software disponveis, mas tambm o aspecto cognitivo e comportamental dos usurios envolvidos na operao. Cinco fatores se propem a isso: tempo de aprendizado do usurio, a rapidez na execuo das tarefas, a taxa de erros dos usurios, a reteno ao longo do tempo e a satisfao dos objetivos. Esses componentes so a base da chamada usabilidade do sistema, e a engenharia de usabilidade um conjunto de mtodos estabelecidos para alcan-la. [28] O ciclo de projeto das interfaces pode obedecer ao ciclo tradicional de desenvolvimento de softwares centrados em usurios, constitudo de trs etapas: definio, implementao e manuteno (figura 3.4). .

Figura 3.4: Mtodo tradicional de desenvolvimento de softwares. [28]

O mtodo descrito considera de uma forma geral as atividades de especificao, desenvolvimento, validao e evoluo, de forma a suprir as necessidades dos clientes. Essas atividades so representadas separadas no processo, como a especificao do sistema (requisitos), o projeto ou especificao do software, as etapas da implementao, testes e manuteno. [29] As fases acima so mais bem explicadas a seguir: a) Especificao do sistema: Os requisitos gerais, funes, restries e os objetivos do sistema so estabelecidos por meio de consulta aos usurios do sistema. Posteriormente so definidos em detalhes, gerando a especificao do sistema. [29] b) Especificao do software: Realiza a especificao de requisitos de software, a qual captura todos os requisitos de software para o sistema ou

27

para uma parte do sistema. Quando uma modelagem de casos de uso utilizada, este artefato consiste em um pacote contendo casos de uso do modelo de casos de uso e outras especificaes aplicveis. [30] c) Projeto Preliminar: Envolve o projeto de sistemas e de software. Normalmente nesta fase, realiza-se a descrio da arquitetura e de dados, ou seja, desenvolve-se uma estrutura modular, definem-se interfaces e estabelece-se a estrutura dos dados. Todo o trabalho desta etapa revisado de acordo com o documento de Especificao de Software e ento, gera-se uma Especificao de Projeto preliminar. [31] d) Projeto Detalhado: A Especificao de Projeto detalhada nesta etapa. Para tanto, os aspectos procedimentais de cada componente modular do projeto de software so considerados. Adiciona-se Especificao de Projeto cada descrio detalhada de um processo. [31] e) Codificao e Depurao: Nesta fase produzido o cdigo (programa) do produto. As fases anteriores podem at desenvolver cdigos em nvel de prottipos, testes, simulaes, etc. Contudo, esta fase exclusiva dos programadores ou desenvolvedores. Os mdulos desenvolvidos nesta fase so individualmente testados (debugados) procurando-se erros de software que previnam o programa de ser executado ou que produzam um resultado inesperado.[29] f) Testes e pr-operao: As unidades (mdulos) de programa ou programas individuais so integrados e testados como um sistema completo a fim de garantir que os requisitos de software foram atendidos. Depois destes testes o sistema entregue ao cliente.[29] g) Operao e Manuteno: Normalmente essa a fase mais longa do ciclo de vida. O sistema instalado e colocado em operao. A manuteno envolve corrigir os erros que no foram descobertos em estgios anteriores do ciclo de vida, melhorando a implementao das unidades do sistema e aumentando as funes desse sistema medida que novos requisitos so descobertos. [29] importante destacar que na prtica esses estgios se sobrepem e trocam informaes entre si. O processo de software no um modelo linear simples, mas envolve uma seqncia de iteraes das atividades de desenvolvimento. essencial

28

e de suma importncia que o usurio possa participar de todo o ciclo de vida de desenvolvimento do software. [29] Sendo assim, importante que seja feita uma constante avaliao da usabilidade do software, de forma a assegurar sua qualidade. Por usabilidade entende-se:

o esforo necessrio para utilizar o software e para o julgamento individual deste uso por determinado conjunto de usurios. Tambm pode ser entendida como a preocupao com a interao do usurio em um sistema por meio da interface. [32] Entender os usurios e encar-los como indivduos que possuem ponto de vista diferente do projetista um grande passo para um projeto bem sucedido, por isso a utilizao de entrevistas uma tcnica bastante usada. Essa atividade muito importante porque os softwares precisam ser desenvolvidos considerando as capacidades reais do usurio e tendo flexibilidade suficiente para se moldarem evoluo da experincia adquirida no decorrer do seu uso. [28] Durante o projeto algumas diretrizes devem ser seguidas, tais como: Consistncia: O propsito bsico da consistncia permitir ao usurio a generalizao do conhecimento sobre os aspectos de um sistema para outros sistemas; Realimentao: Para cada ao do operador, deve haver uma resposta do sistema; Minimizao de erros: a interface, dentro do possvel, deve evitar a ocorrncia de erros por parte dos usurios, fornecendo a estes apenas aes ou comandos vlidos naquele contexto, para no induzi-lo ao erro; Possibilidade de recuperao de erros: As aes dos usurios na interface devem ser facilmente corrigidas, permitindo que os usurios explorem novas caractersticas do sistema, pois sabem que suas aes no sero drsticas; Acomodao de mltiplos nveis de habilidade/conhecimento: a interface precisa se modelar s caractersticas do seu pblico-alvo, levando em considerao diferenas entre usurios novatos e experientes, por exemplo [28].

29

3.2.6. Sistemas Supervisrios atuais

Essa subseo tem por objetivo apresentar os principais supervisrios disponveis no mercado e que se adquam s necessidades de nossa aplicao.

iFIX: [33] um sistema SCADA/IHM baseado na plataforma Windows criado pela GE Fanuc. Faz parte da famlia de softwares de automao. O sistema foi desenvolvido para ser um supervisrio tpico e permite ainda uma fcil integrao e interoperabilidade entre o cho-de-fbrica e sistemas de gesto. O componente SCADA do iFIX traz ferramentas de monitoramento, controle supervisrio, alarme e outras funes de controle, alm de uma rede distribuda. O iFIX foi desenvolvido utilizando-se os principais padres tecnolgicos existentes como ActiveX, OPC, VBA e Component Object Model (COM) para facilitar a integrao com sistemas terceiros, inclusive pela Internet. A arquitetura bsica do sistema apresentada na figura 3.5.

Figura 3.5: Plataforma iFIX.[33]

Os quadros na parte superior da figura so softwares da linha GE Fanuc Proficy com os quais o iFIX capaz de interagir, bem como com aplicaes terceiras, de outros fabricantes. Um dos componentes mais importantes do iFIX o Workspace. Ele uma interface que organiza todos os componentes do sistema em um ambiente de

30

desenvolvimento integrado (IDE), atravs dele possvel navegar, acessar e manipular todos os outros componentes do sistema.

Figura 3.6: Tela do workspace do iFIX. [33]

Wizcon: [34] o supervisrio desenvolvido pela Elutions. Atravs dele possvel gerenciar e controlar o processo em tempo real nas estaes de trabalho ou remotamente via Internet, publicando-se as informaes em um servidor web. Ele combina interfaces com operador, controle supervisrio e tecnologia da Internet para transformar um sistema SCADA clssico em uma soluo moderna completa para automao.

GENESIS32: [11] A ltima verso do GENESIS32, fabricado pela Iconics representa a nova gerao dos sistemas de visualizao, IHM e SCADA que incorpora a primeira aplicao industrial de minerao de dados em IHM. O sistema integra informaes fabris e de negcios e oferece suporte a OPC.

31

Figura 3.7: Exemplo de tela do GENESIS32, da Iconics. [11]

Elipse SCADA: um software de superviso de processos que permite a monitorao de variveis e o acionamento de equipamentos. O Elipse SCADA contm funes de monitorao, controle, importao de imagens, alarmes, autenticao de usurios, servidor e cliente DDE. Ademais, oferece suporte para aplicaes que utilizam armazenamento de dados, tratamento de informaes e gerao de relatrios complexos, sendo disponibilizadas funes para histricos, relatrios, controle estatstico de processos e log de alarmes em disco. O Elipse SCADA possui ferramentas adicionais que trabalham em conjunto com o software e que permitem acrescentar funcionalidades como monitorao de sistemas por imagens e a superviso web de processos atravs de um navegador de Internet. [18]

Figura 3.8: Exemplo de case do Elipse SCADA. [35]

32

3.3.

O SDCD SISTEMA DIGITAL DE CONTROLE DISTRIBUDO

O Sistema Digital de Controle Distribudo ou SDCD um sistema para automao industrial que tem como funo primordial o controle e a superviso de processos de forma a permitir uma otimizao da produtividade industrial, estruturada na diminuio de custos de produo, melhoria na qualidade dos produtos, preciso das operaes, segurana operacional, entre outros. Para tanto, utilizam-se tcnicas de processamento digitais (discreto) em oposio ao analgico (contnuo). O sistema dotado de processadores e redes redundantes e permite uma descentralizao do processamento de dados e decises, atravs do uso de unidades remotas na planta. Alm disso, oferece uma poderosa interface homemmquina (IHM) que permite o interfaceamento com controladores lgicos programveis (CLP), controladores PID, equipamentos de comunicao digital e sistemas em rede [36]. Destaca-se tambm uso de controles Java, que permitem visualizao remota e ininterrupta do processo produtivo, bem como da tecnologia OPC (OLE para Controle de Processo), que viabiliza a troca de informaes com sistemas de Gerenciamento de Informaes de Planta e Laboratrio, ou com sistemas corporativos. Os principais protocolos de campo utilizados so o Foundation Fieldbus, Profibus, HART, alm de outras interfaces sobre RS232, RS485 e Ethernet, que garantem a conectividade entre o SDCD, a instrumentao inteligente e os demais equipamentos existentes na planta. [37] Uma vez coletados os dados em campo atravs das Unidades de Processamento (Controladores), distribudas nas reas, que os sinais obtidos so processados, de acordo com a estratgia programada. Estes sinais, transformados em informao de processo, so atualizados em tempo real nas telas de operao das Salas de Controle. [36] A figura 3.9 apresenta uma viso geral do que foi descrito anteriormente.

33

Figura 3.9: Viso Geral e simplificada de um SDCD. [38]

Um SDCD pode ser representado por uma sala central, gerenciadora de controle e superviso global, microprocessada em rede com vrios outros controladores de responsabilidade local, caracterizando-se pela transformao de processos automatizados em verdadeiros sistemas de automao supervisionados com a capacidade e rastreamento de todas as etapas do processo produtivo, bem como a flexibilizao e aumento da capacidade de integrao de seus componentes, prevendo, portanto, um aumento do processo e do nvel de automao de forma natural e continuada [39]. Vale destacar que sistemas distribudos, como os da figura 3.9, tem muitas vantagens sobre os sistemas centralizados. Como os dados processados so distribudos na rede, os vrios servidores precisam de menos processamento, dessa forma, os custos com computadores diminui. Tambm mais fcil fazer um upgrade ou adicionar mais servidores se for necessrio. Outra vantagem dos sistemas distribudos a de que uma falha em um servidor no afeta, necessariamente, todo o sistema. [27]

34

3.3.1. Semelhanas e diferenas entre SDCD e CLP [40] [41]

Existem muito mais publicaes sobre os CLPs do que sobre os SDCDs, apesar de eles desempenharem funes muito semelhantes na indstria atualmente. Para entender melhor as diferenas e semelhanas deve-se primeiro conhecer a evoluo do desenvolvimento dos dois sistemas. Na dcada de 70, quando os primeiros CLPs e SDCDs surgiram no mercado era fcil perceber que haviam sido concebidos para a execuo de tarefas diferentes. O CLP tinha como objetivo a simples substituio dos painis de rels (variveis digitais), e por este motivo em sua primeira verso operava de maneira cega, ou seja, sem interface para superviso. O SDCD tinha a funo de automatizar uma planta por completo, substituindo os painis dos controladores (variveis analgicas) assim como o de rels (variveis digitais). Ao longo dos anos os sistemas de controle evoluram muito, os CLPs integraram uma estao de operao/superviso ao seu hardware e tambm comearam a tratar as variveis analgicas. Os SDCDs, por outro lado, flexibilizaram o tamanho de seu hardware de forma a atender aplicaes de pequeno/mdio portes e tambm abriram o seu sistema viabilizando a comunicao com qualquer hardware/software de mercado. Por fim, o CLP e o SDCD convergiram para um mesmo ponto e nos dias de hoje executam funes similares e, principalmente, podem disputar mesma fatia de mercado. Um resumo dessa evoluo pode ser encontrado na figura a seguir:

35

Figura 3.10: Evoluo dos sistemas de automao. [41]

Conforme dito anteriormente o SDCD e o CLP desempenham hoje funes muito semelhantes. Entretanto, ainda existem diferenas entre estes sistemas, diferenas estas relacionadas funo para qual cada um deles foi concebido.[40] a. Velocidade/Desempenho O tempo de varredura o principal indicativo de velocidade e desempenho. Para os SDCDs esse tempo corresponde leitura das entradas de sinal, o processamento da lgica de controle e a atualizao/atuao nas sadas. Esse tempo pode variar de 50 milissegundos (para aplicaes crticas) a 1 segundo, suficiente para atender a maioria das aplicaes de controle regulatrio tpicas da indstria de processo. Para os CLPs, o tempo de varredura referente somente ao processamento da CPU. Normalmente varia de 1 a 10 milissegundos.

36

As diferenas de concepo em relao aos tempos de varredura tambm podem ser caracterizados atravs dos conceitos de determinismo e flexibilidade do tempo. Nos SDCDs, que utilizam o conceito de determinismo do tempo de varredura, o nmero de tarefas que podero ser executadas pr-definido. As tarefas so executadas em paralelo e o tempo de execuo (leitura da entrada, processamento da tarefa e atualizao da sada) de cada uma delas pode ser selecionada individualmente. Por exemplo, um PID com tempo de execuo de 50 milissegundos atualiza 20 (vinte) vezes a sada do sistema dentro do tempo de varredura de 1 segundo. Nos CLPs, que utilizam o conceito de flexibilidade da utilizao do tempo, ou ainda compartilhamento do processamento no tempo, as tarefas so executadas em srie e podem ter seus tempos de execuo selecionados individualmente. Por exemplo, um CLP com 10 tarefas concorrentes de 10 milissegundos cada ter um tempo de varredura de 100 milissegundos. Neste caso, a atualizao de todas as sadas ocorrer a cada 100 milissegundos. b. Abrangncia Os SDCDs normalmente trazem uma extensa biblioteca de blocos voltados para o controle de processo, sendo que muitos destes foram desenvolvidos a partir da experincia do fornecedor em aplicaes de controle regulatrio. Os CLPs, que por sua vez possuem uma biblioteca no to vasta para este propsito, possibilitam customizaes atravs de linguagem de baixo nvel. c. Robustez Os SDCDs foram concebidos de forma a permitir a escalabilidade do sistema e tambm a operao ininterrupta do processo, por este motivo possibilitam a incluso e a redundncia de cartes de I/O, bem como a configurao de novos tags sem parada da CPU do sistema e conseqentemente da planta. No caso da incluso de novos tags, realiza-se o download online, havendo ainda a equalizao automtica deste tag em todas as CPUs do sistema. Os CLPs, apesar de possurem tecnologia Plug and Play (reconhecimento automtico do carto), normalmente exigem a inicializao da CPU para o reconhecimento dos cartes, o que acarreta em uma parada no processo. Para a

37

incluso de um novo tag necessrio que seja feita uma reinicializao individual de todas as CPUs que estejam utilizando este tag em sua lgica. d. Adequao s implementaes Hoje possvel se encontrar no mercado SDCDs especialmente desenvolvidos para aplicaes de pequeno/mdio portes, assim como CLPs para grandes aplicaes. Em se tratando de aplicaes de grande porte ou mesmo crticas, onde devem ser atendidos requisitos como: sistema de controle totalmente redundante (CPU, fontes, I/O, rede de controle), escalabilidade, robustez, grande quantidade de recursos para controle regulatrio, dentre outros, a melhor opo ainda so os SDCDs por atenderem melhor estes requisitos. e. Integrao Inicialmente, se faz necessrio compreender que os SDCDs fornecem uma soluo completa composta por hardware e software de controle e software de superviso. Os CLPs em contrapartida so compostos somente por hardware e software de configurao, sendo, portanto necessrio a integrao de um software supervisrio ao mesmo. Nos SDCDs todas as variveis existentes na estao de controle so automaticamente disponibilizadas na estao de operao/superviso, onde frontais (faceplates) padres do sistema podem ser selecionados para representar estas variveis. Por outro lado, as variveis existentes nos CLPs precisam ser transcritas para a base de dados do sistema supervisrio, isto , as variveis acessadas pelo supervisrio devem ser declaradas no mesmo. f. Direcionamento dos sistemas de controle De uma forma geral, os sistemas atuais esto cada vez mais compactos, flexveis, com comunicao e interface simples, o que facilita a integrao com outros sistemas e a adequao deles s mais diversas aplicaes, sem deixar de atender a necessidade de padronizao na programao/configurao, de acordo com as normas IEC61131-3, o que permite a utilizao de blocos funcionais otimizados para cada situao.

38

3.4.

REDES DE COMUNICAO INDUSTRIAL

A instalao de manuteno de sistemas de controle antigamente tinha um custo muito alto e era muito difcil de fazer. Hoje, com a utilizao das redes industriais, os custos de instalao, manuteno e upgrades diminuram, enquanto a qualidade da informao melhorou consideravelmente. Escolhendo-se a rede mais adequada possvel estabelecer uma boa comunicao entre os componentes de um supervisrio, essencial para o seu bom funcionamento. Nesse caso, a troca de informaes deve ser feita em vrios sentidos, como indicam as setas direcionais da figura 3.3, da a importncia das redes de comunicao industriais, principalmente em aplicaes distribudas. Essa integrao pode reduzir os custos de fabricao e manuteno, aumentar a produtividade e acaba por estabelecer um novo conceito em automao industrial: a integrabilidade de seus componentes nos mais diferentes nveis.[16] A rede de comunicao a plataforma por onde as informaes fluem das estaes remotas para a estao de monitorao central. Levando em considerao os requisitos do sistema e a distncia a cobrir, pode ser implementada atravs de cabos de par tranado, fibras pticas, linhas dial-up, linhas dedicadas, radiofreqncia, etc. [15] Normalmente redes industriais so padronizadas sobre 3 nveis de hierarquias cada qual responsvel pela conexo de diferentes tipos de equipamentos com suas prprias caractersticas de informao, conforme representado na figura 3.11. [42]

Figura 3.11: Nveis de redes industriais. [42]

39

O nvel mais alto, nvel de planta, tambm conhecido como nvel de informao da rede ou nvel de gerenciamento, destinado a um computador central que processa o escalonamento da produo da planta e permite operaes de monitoramento estatstico da planta sendo implementado, geralmente, por softwares gerenciais. O padro Ethernet operando com o protocolo TCP/IP o mais comumente utilizado neste nvel. O nvel intermedirio, nvel de controle da rede, a rede central localizada na planta incorporando CLPs, SDCDs e computadores em geral. A informao deve trafegar neste nvel em tempo real para garantir a atualizao dos dados nos softwares que realizam a superviso da aplicao. Neste caso, os sistemas de superviso, geralmente utilizam arquiteturas do tipo cliente/servidor para acessar as informaes do processo disponveis na rede de campo. O nvel mais baixo, nvel de controle discreto ou nvel de campo se refere geralmente s ligaes fsicas da rede. Este nvel de rede conecta os equipamentos de baixo nvel entre as partes fsicas e de controle. Nele encontram-se os sensores discretos, contatores e blocos de entrada e sada [42]. Essas redes utilizam, em sua maioria, uma arquitetura mestre/escravo. Neste caso, os controladores que desempenham a funo das estaes escravas jamais iniciam a comunicao, respondendo somente s solicitaes feitas pelo controlador mestre. [16]. De uma forma geral, os sistemas de redes de campo adotam arquiteturas de trs camadas: a camada fsica, a camada de ligao de dados e a camada de aplicao do conhecido modelo de referncia OSI. [43] Para cada classe de redes industriais, existem vrias organizaes que padronizam, regulamentam, controlam e certificam equipamentos para aquele padro. No entanto, os padres mais conhecidos e utilizados so a Ethernet (TCP/IP), Modbus, Devicenet, Profibus, HART, Foundation Fieldbus, entre outros. A comunicao com outros sistemas, como os de ordem corporativa, ou simplesmente outros coletores ou fornecedores de dados, por exemplo, pode se dar atravs da implementao de mdulos especficos, via Bancos de Dados, ou outras tecnologias como o XML e o OPC. [15]

40

3.4.1. Redes Foundation Fieldbus (FF)

As redes Foundation Fieldbus tem tido grande destaque nesse contexto. A arquitetura Foundation prov um protocolo de comunicao para sistemas de controle e instrumentao no qual cada equipamento tem sua prpria inteligncia e se comunica atravs de um sistema de comunicao digital e bidirecional [44]. Suas principais caractersticas so: Cabo de par tranado com 2 fios e uma blindagem, trafegando sinal e alimentao no mesmo cabo; At 32 dispositivos sem alimentao e 12 com alimentao Velocidades de 31,25 Kbits / s Mxima distncia de 1900 m conforme nmero de dispositivos Permite vrias topologias [14]. Esta tecnologia apresenta muitas vantagens, tais como a diminuio do hardware, da quantidade de fios, facilidade na instalao e na manuteno, alm da quantidade e da qualidade dos dados que trafegam na rede. Conseqentemente a economia pode chegar a 40% nos custos de projeto, instalao, operao e manuteno de um processo industrial. [45] A figura 3.12 traz uma comparao entre uma rede sem FF e outra com FF.

(a)

(b)

Figura 3.12: (a) Arquitetura sem Fielbdus Foundation, (b) Arquitetura FF.[14] [46]

41

3.4.2. Redes Ethernet e protocolo TCP/IP [47] [48]

Em 1973, os pesquisadores Bob Metcalfe e David Boggs, do Xerox Corporation's Palo Alto Research Center (mais conhecido como PARC), criaram e testaram a primeira rede Ethernet. Metcalfe tentava conectar o computador "Alto" da Xerox a uma impressora e acabou desenvolvendo um mtodo fsico de cabeamento que conectava os dispositivos na Ethernet. Ele tambm criou os padres de comunicao em cabos. Desde ento, a Ethernet se tornou a tecnologia de redes mais popular do mundo. Com o amadurecimento das redes, o padro Ethernet cresceu para agregar novas tecnologias, mas sempre se baseando no sistema original de Metcalfe. O conceito original de Ethernet : comunicao compartilhada por um nico cabo para todos os dispositivos da rede. Uma vez que o dispositivo est conectado a esse cabo, ele tem a capacidade de se comunicar com qualquer outro dispositivo. Isso permite que a rede se expanda para acomodar novos dispositivos sem ter de modificar os dispositivos antigos. A Ethernet uma tecnologia de rede local (LAN). Essas redes normalmente operam num mesmo prdio e conectam dispositivos prximos. No incio podia haver no mximo algumas centenas de metros de cabos separando dispositivos numa Ethernet, tornando difcil conectar locais muito distantes geograficamente. Avanos recentes da tecnologia conseguiram aumentar essas distncias, e as redes Ethernet atuais podem cobrir dezenas de quilmetros. Os principais modelos fsicos so: [48] 10Base2: Tambm conhecido como Thin Ethernet. Todas as estaes ficam interconectadas por cabos coaxiais, com terminadores de 50 em cada ponta. 10BaseT: Todos os componentes da rede esto conectados, atravs de cabos de par tranado, a um hub que passa todos os pacotes a todas as estaes. Nesse caso, a topologia da rede do tipo estrela.

42

Figura 3.13: Ethernet 10BaseT. [48]

10Base5: Muitas vezes chamado de o cabo amarelo foi o padro Ethernet original e muito utilizado hoje. Alcana uma distncia de at 500m e sua velocidade de 10Mbps. Existem ainda os padres como o 100BaseT4 e o 100BaseTX, que apresentam taxas de dados mais altas. Independente do modelo fsico escolhido, a estrutura lgica dos pacotes de dados a mesma em qualquer topologia. Todas as estaes na LAN recebem todos os pacotes enviados, mas somente processam os que foram endereados a elas. O endereo Ethernet, tambm chamado de MAC ou nmero do n gravado no adaptador Ethernet pelo fabricante e no pode ser modificado. Trata-se de um nmero de 6 bits, normalmente expresso em hexadecimal. Os pacotes de dados ou frames, tambm se diferenciam de acordo com a aplicao, mas de uma forma geral existe um conjunto necessrio de trechos de informao que ele deve conter. Por exemplo, cada frame deve incluir um endereo de destino e um endereo de envio, que identificam respectivamente o destinatrio e o remetente da mensagem. O endereo identifica um n nico. Como um sinal no meio Ethernet alcana todos os ns conectados, o endereo de destino desempenha um papel fundamental para identificar o destinatrio do pacote. Contudo, somente a Ethernet no capaz de enderear tipos de redes diferentes. Existe tambm a desvantagem de que o remetente no recebe nenhuma confirmao do receptor de que o pacote realmente chegou. Precisa-se, ento, utilizar protocolos de ordem superior, tal como TCP/IP, e principalmente se a rede Ethernet estiver conectada a mltiplas redes.

43

Embora os nomes TCP e IP sejam utilizados juntos eles constituem dois protocolos complementares, que sero explicados a seguir. Protocolo IP [48] O Protocolo de Internet (do ingls, Internet Protocol) permite que sejam inseridos um nmero indefinido de redes em uma rede global, sem importar o tipo de transmisso e a estrutura fsica de cada rede. Abaixo do IP cada estao da rede tem um endereo de Internet nico, chamado de nmero IP. O IP um nmero de 32 bits, expresso em forma de 4 nmeros decimais de 8 bits cada, separados por .. Os ns da rede podem ser endereados de acordo com uma das seguintes classes: Classe A: O primeiro byte dedicado ao endereamento da rede e os outros 3 so para enderear a estao. Classe B: Os dois primeiros bytes so dedicados ao endereamento da rede e os outros 2 so para enderear a estao. Classe C: Os 3 primeiros bytes so dedicados ao endereamento da rede e o ltimo serve para enderear a estao. Os dados enviados pela rede so empacotados em um frame, que tambm tem seu formato especfico, incluindo campos que identificam o IP de origem e o IP de destino do pacote. A maior limitao do protocolo IP est no fato de ele no ser seguro. Protocolo TCP [48] [49] O protocolo de Controle de Transporte (em ingls Transport Control Protocol) est no nvel da camada 4 (transporte) do modelo OSI (figura 3.15), e estabelece a conexo entre duas estaes de rede durante a transmisso dos dados. Basicamente ele trabalha com o princpio do cliente e do servidor: a estao que toma a iniciativa para estabelecer a conexo chamada de cliente. O cliente faz uso de um servio oferecido pelo servidor, que a estao para a qual foi feita a ligao. O servidor apenas espera o contato do cliente.

44

As principais caractersticas deste protocolo so: Orientado conexo: A aplicao envia um pedido de conexo para o destino e usa a "conexo" para transferir dados. Ponto a ponto: Uma conexo TCP estabelecida entre dois pontos. Confiabilidade: O TCP usa vrias tcnicas para proporcionar uma entrega confivel dos pacotes de dados, permitindo a recuperao de pacotes perdidos, a eliminao de pacotes duplicados, a recuperao de dados corrompidos, e podendo ainda recuperar a ligao em caso de problemas no sistema e na rede. Full duplex: possvel a transferncia simultnea em ambas direes (cliente-servidor) durante toda a sesso. Handshake: Mecanismo de estabelecimento e finalizao de conexo a trs e quatro tempos, respectivamente, o que permite a autenticao e encerramento de uma sesso completa. O TCP garante que, no final da conexo, todos os pacotes foram bem recebidos. Entrega ordenada: A aplicao faz a entrega ao TCP de blocos de dados com um tamanho arbitrrio num fluxo (ou stream) de dados, tipicamente em octetos. O TCP parte estes dados em segmentos. Porm, a circulao dos pacotes ao longo da rede (utilizando um protocolo de encaminhamento, na camada inferior, como o IP) pode fazer com que os pacotes no cheguem ordenados. O TCP garante a reconstruo do stream no destinatrio mediante os nmeros de seqncia. Controle de fluxo: O TCP usa o campo janela ou window para controlar o fluxo. O receptor, medida que recebe os dados, envia mensagens ACK (acknowledgement), confirmando a recepo de um segmento; como funcionalidade extra, estas mensagens podem especificar o tamanho mximo do buffer no campo (janela) do segmento TCP, determinando a quantidade mxima de bytes aceita pelo receptor. O transmissor pode transmitir segmentos com um nmero de bytes que dever estar confinado ao tamanho da janela permitido: o menor valor entre sua capacidade de envio e a capacidade informada pelo receptor. De uma forma geral, pode-se dizer que o pacote de dados do TCP inserido dentro do pacote IP (figura 3.14)

45

Figura 3.14: Encapsulamento dos protocolos TCP/IP. [48]

3.4.3. Redes sem fio (wireless)

Uma rede sem fio, como o prprio nome diz, uma rede de dispositivos interligados, sem o uso de cabos ou fios entre eles, por meio de equipamentos que usam radiofreqncia (comunicao via ondas de rdio) ou comunicao via infravermelho. Sua classificao baseada na rea de abrangncia: redes pessoais ou curta distncia (WPAN), redes locais (WLAN), redes metropolitanas (WMAN) e redes geograficamente distribudas ou de longa distncia (WWAN). Existem muitas tecnologias para implementar uma rede sem fio, dentre as quais pode-se citar: ZigBee, Infrared Data Association (IrDA), Wi-Fi, WIMAX, Bluetooth, WirelessHart (industrial), Mesh, etc. Seu funcionamento baseado na utilizao de portadoras de rdio ou infravermelho. Atravs delas, as WLANs estabelecem a comunicao de dados entre os pontos da rede. Os dados so modulados na portadora de rdio e transmitidos atravs de ondas eletromagnticas. Mas o sistema s funciona porque mltiplas portadoras de rdio podem coexistir num mesmo meio, sem que uma interfira na outra. Para extrair os dados, o receptor sintoniza numa freqncia especfica e rejeita as outras portadoras de freqncias diferentes. Num ambiente tpico, o dispositivo transceptor (transmissor/receptor) ou ponto de acesso conectado a uma rede local Ethernet convencional (com fio). Os pontos de acesso no apenas fornecem a comunicao com a rede convencional, como

46

tambm intermedeiam o trfego com os pontos de acesso vizinhos, num esquema de micro clulas semelhante a um sistema de telefonia celular. Esse tipo de rede foi padronizado na especificao IEEE 802.11 que foi lanada em 1997 e define basicamente todas as necessidades de estruturais necessrias para a utilizao de redes sem fio, para isto foram definidos protocolos de controle de acesso ao meio CSMA/CA, tipos de modulao utilizados (FHSS e DSSS), criptografia (WEP) e principais componentes, placa de rede e ponto de acesso. A velocidade de transmisso desta especificao de no mximo 2Mbps. Dois anos aps o lanamento da primeira especificao, em 1999, surgiu uma nova especificao, a IEEE 802.11b, que atendia a uma necessidade crescente do mercado, uma maior velocidade de transmisso. Ocorrendo mudanas somente na camada fsica para que fosse possvel atingir maior velocidade, neste caso de at 11Mbps. Hoje j existem mais especificaes baseadas na IEEE 802.11. A especificao IEEE 802.11 foca nas duas camadas de mais baixo nvel do modelo OSI (figura 3.15), a camada fsica e de dados. A diferena entre a especificao 802.11 e 802.11b somente na camada fsica, para permitir taxas de transferncias mais altas. [50]

Figura 3.15: Camadas do Modelo OSI. [50]

47

Modos de Operao [50] As redes sem fio tm dois modos bsicos de operao: ponto a ponto e infraestrutura. O modo ponto a ponto tem seu alcance pequeno e no permite uma grande expanso da rede, j que a comunicao ocorre diretamente entre duas estaes na rede e a potncia da placa de rede sem fio muito inferior a de um ponto de acesso. O modo infra-estrutura exige um maior investimento, pois necessita de ao menos um ponto de acesso, tem um alcance muito maior, pois as estaes se comunicam com o ponto de acesso ao invs de transmitirem seu sinal diretamente a outra estao. Outra vantagem sua integrao com outros pontos de acesso e redes cabeadas convencionais atravs de um sistema de distribuio. a) Ponto a ponto No modo ponto a ponto as estaes sem fio comunicam-se diretamente umas com as outras formando assim uma rede, sem a necessidade de um ponto de acesso. Todas as estaes devem estar dentro da faixa de alcance das placas de rede umas as outras, para que se forme esta configurao de rede (figura 3.16). O modo ponto a ponto tambm definido como Ad Hoc ou IBSS (Independent Basic Service Set) devido rede ser independente (sem comunicao com outras redes) e formada apenas pelas estaes sem fio.

Figura 3.16: Modo de operao ponto a ponto. [50]

b) Infra-estrutura O modo infra-estrutura consiste de ao menos um ponto de acesso (AP) conectado rede com fios e um conjunto de uma ou mais estaes com acesso a rede sem fio. Nesta configurao todas as mquinas se comunicam com o AP

48

(figura 3.17), ao contrrio da configurao ponto a ponto onde cada mquina se comunica diretamente com o destino. Esta configurao proporciona economia de energia para as mquinas da rede, j que seu destino sempre o AP e uma maior abrangncia da rea de rede.

Figura 3.17: Modo infra-estrutura com 1 AP. [50]

Wireless na indstria Essa tecnologia, hoje bastante popular, carrega um estigma no muito satisfatrio, com muitas reclamaes dos usurios em termos de queda de linhas, falta e baixa intensidade de sinal, problemas de segurana, etc. Mesmo assim as redes wireless ganharam seu espao na indstria. Elas foram pensadas, inicialmente, para serem aplicados em pontos de difcil acesso para o ser humano, onde os custos com infra-estrutura e mo de obra eram inviveis, como aquelas que envolvem dados a grandes distncias, obstculos fsicos, interferncias eltricas e at mesmo para aumentar a segurana (evitando a ronda dos operadores pela planta), mas hoje o mercado j absorve solues de todos os portes, de redes de sensores sem fio a celulares, Bluetooth M2M, handhelds, cumprindo as mais diversas funes. Especialistas afirmam que os negcios envolvendo redes sem fio constituem o segmento de negcios em automao industrial com maiores perspectivas de

49

crescimento, com taxas superiores a 32% ao ano at 2010, quando devero atingir US$ 1,18 bilho. Em 2005, esses valores foram de apenas US$ 325 milhes. [51] Os principais entraves para esse progresso so ainda problemas de segurana e com disponibilidade de energia, mais comuns em aplicaes industriais, j que as baterias utilizadas hoje tm durao estimada de 5 a 10 anos, para uma taxa de transmisso de 1 minuto, mas a maioria dos usurios (industriais) demanda informaes a cada segundo, o que reduz muito a vida til da bateria alm de reduzir bastante a quantidade de dispositivos na rede. Em termos de classificao industrial o comit da ISA SP100, responsvel pela padronizao do wireless industrial [52], desenvolveu classificaes para o wireless e uma delas est assim dividida: Classe 5: Monitoramento sem conseqncias imediatas para a operao; Classe 4: Monitoramento com conseqncias de curto prazo para a operao; Classe 3: Controle de loop aberto; Classe 2: Loop fechado, controle supervisrio; Classe 1: Loop fechado, controle regulatrio; Classe 0: Ao de emergncia. O Comit tambm inclui a coexistncia e a qualidade do servio como caractersticas bsicas para uma rede wireless e isso se torna importante quando se imagina que vrias redes podem conviver num emaranhado de tubos e equipamentos de uma planta, gerando, ento uma latncia, uma defasagem de tempo para as mensagens.

Hardware necessrio para uma rede wireless [53] fcil perceber que uma rede wireless exige, de alguma maneira, um conjunto diferente de componentes de hardware de uma rede com fio tradicional. O principal componente que um dispositivo deve ter para que possa estar na rede um adaptador de rede. Um adaptador de rede uma interface entre um computador e uma rede. Ele contm um transmissor e um receptor de rdio. Cada adaptador wireless utiliza um utilitrio de configurao que controla o modo de operao, o

50

nmero do canal e todas as outras opes de configurao, as quais devem combinar com os outros ns da rede. Em redes de infra-estrutura h a necessidade de se instalar pontos de acesso, mencionados anteriormente. Eles esto disponveis como pontos de acesso simples em combinao com hubs, switches e roteadores para conexo com fio, computadores e outros dispositivos prximos. Muitos pontos de acesso e a maioria dos adaptadores de rede wireless acompanham antenas onidirecionais embutidas. Existem duas antenas no link entre uma estao base e um adaptador de rede wireless uma em cada extremidade.

3.4.3.1. Dispositivos Mveis

Uma vez definido o hardware mnimo necessrio para instalar uma rede wireless e planejada a distribuio e instalao dos pontos de acesso, se for o caso, necessrio instalar e configurar as interfaces de rede (adaptadores). Conforme apresentado na seo 2.5, a soluo proposta envolve o uso de dispositivos mveis e neles esto embutidos os adaptadores de rede. Os dispositivos mveis tambm conhecidos como handhelds, so equipamentos computacionais de tamanho reduzido, que normalmente tem uma tela touchscreen ou pequenos teclados [54]. Os handhelds mais utilizados so os Personal/enterprise digital Assistant (PDAs) ou Palmtops, Smartphones, Pocket PC. Para games, destacam-se os PlayStation Portable (PSPs) e o Nintendo DS. Dentre os dispositivos mencionados, os que mais se adaptam s necessidades de nossa aplicao so os Pocket PCs e os Palmtops, j que os Smartphones so utilizados tambm como celulares e os demais so focados para jogos e entretenimento. A seguir so apresentadas as principais diferenas entre Pocket PC e Palm. 1. O processador Comparando-se os mais modernos processadores de Pocket PCs e Palms possvel observar que o clock dos Pockets significativamente maior. importante notar que o sistema operacional de um Pocket PC foi desenvolvido para um

51

processador mais genrico e mais combinaes de hardware e usos mais substanciais de processamento. No entanto, sua bateria acaba mais rapidamente. 2. Memria O sistema operacional de um Pocket PC tambm foi desenhado para manipular alocaes de memria maiores do que no Palm. Isso implica dizer que o usurio pode trabalhar com arquivos maiores e programas mais sofisticados que requerem mais memria. As verses mais modernas dos Pocket PCs chegam a ter mais de 256MB de memria, contra 16MB dos melhores Palms. No entanto, o Palm faz um uso muito eficiente da memria, mesmo comparando com a capacidade maior do Pocket PC. Porm, quando se trata de dados simples, o uso de memria essencialmente o mesmo. 3. Multi-tarefas (multitasking) A habilidade do processador de trabalhar em mais de uma tarefa simultaneamente uma importante caracterstica do ambiente do Pocket PC, principalmente quando se trata de us-lo para atividades rotineiras. Toda vez que uma aplicao nova aberta, as outras continuam rodando em background. O sistema operacional do Palm no permite multitasking. Um exemplo: com multitasking possvel conectar-se Internet e carregar o e-mail ao mesmo tempo em que se navega na Web e copiam-se informaes para um arquivo do Pocket Word. Essa atividade complexa no possvel em um Palm. 4. Aplicativos Existem duas categorias de aplicativos a serem consideradas: os aplicativos que j vm instalados no dispositivo e aplicativos de terceiros. Normalmente tanto Pocket PCs quanto Palms vm com calendrio, lista de atividades, e-mail, entre outros aplicativos instalados. Os Pockets trazem tambm aplicativos como Pocket Word, Excel, Outlook e outras ferramentas da Microsoft. No entanto, ainda existem muito mais aplicativos de terceiros disponveis para Palms do que para Pocket PCs. Para os primeiros, existem cerca de 10.000 contra 1.500 aplicativos compatveis com Pocket PCs.

52

5. Expansibilidade O Pocket PC pode ser expandido de quatro formas, dependendo das opes de hardware. A tcnica mais comum de expanso por cartes CompactFlash (CF) Alguns Pocket PCs incluem portas de expanso. Tambm possvel expandir o Pocket PC via PCMCIA e cartes Secure Digita (SD), a ltima opo atravs de um padro Bluetooth. Nas verses mais recentes do Palm possvel expandi-lo usando cartes SD e CF. [55]

3.4.4. Segurana em redes de automao industrial [56] [24]

Redes de automao, principalmente as redes de comunicao existentes nos sistemas SCADA contm computadores e aplicaes que realizam funes chave no fornecimento de servios essenciais (eletricidade, matria-prima, gasolina, gua, transportes, etc.). Assim sendo, elas fazem parte de uma infra-estrutura crtica e requerem proteo contra uma enorme variedade de ameaas existentes no cyber-espao. As redes SCADA foram inicialmente projetadas para maximizar funcionalidades, com pouca ateno voltada para a segurana. Como resultado, performance, confiabilidade, flexibilidade dos sistemas SCADA so robustas, enquanto os controles de segurana so fracos, isto as torna potencialmente vulnerveis a problemas de segurana que podem resultar em problemas de segurana pblica ou em srias paradas de produo nas empresas, causando muitas perdas, financeiras ou no. Com o tempo e por questes de eficincia, manuteno e economia, as plataformas de controle e aquisio de dados deixaram de ser isoladas e proprietrias (hardware e software) para se tornarem baseadas em sistemas PC e utilizarem softwares padro, protocolos de rede e a Internet. A principal desvantagem dessa transio foi o fato de que os sistemas industriais ficaram expostos s mesmas vulnerabilidades que afetam o Windows e suas redes. Os ataques mais comuns a sistemas SCADA so listados a seguir: Acesso, divulgao, modificao e manipulao de dados crticos. Indisponibilidade de servios.

53

Excesso de informao disponvel: Websites fornecem dados teis aos invasores sobre a estrutura da empresa, nomes de empregados, emails e at mesmo nomes de sistemas; servidores de DNS permitem zonas de transferncia fornecendo endereos IP, nomes de servidores, e informaes de emails. Arquitetura de rede insegura: Configurao de servidores de FTP, web e email s vezes de maneira inadvertida ou sem necessidade fornecem acesso rede interna da empresa; conexes de rede com parceiros de negcios no protegidas por Firewalls, IDS ou VPN so portas de entrada para invases; modems permanentemente habilitados, sem mecanismos fortes de controle de acesso; firewalls e outros dispositivos de segurana de rede no implementados internamente, deixando pouca ou nenhuma separao entre as redes corporativa e de automao; redes sem fio configuradas sem segurana adequada; PLCs, pois no requerem autenticao para serem usados; softwares de IHM, pois possuem suas vulnerabilidades publicadas na Internet. Falta de monitoramento em tempo real: Arquivos de log de equipamentos de segurana no so analisados, impedindo o pessoal de segurana de redes de reconhecer ataques individuais; empresas no utilizam softwares especialistas para gesto de logs e incidentes. Cdigos maliciosos: Cdigos como vrus, trojans, worms e bombas lgicas (pedaos de cdigo intencionalmente inseridos em um sistema de software e que ir executar uma funo maliciosa quando condies especficas forem atingidas) podem causar grandes danos. A maior parte dos sistemas SCADA, principalmente CLPs e controladores operam em tempo real ou em ambientes em que os dados precisam ser atualizados com muita freqncia. Por esse motivo, muitas vezes eles no podem suportar os atrasos que podem ser ocasionados pelo software de segurana, j que isso impactaria negativamente no controle de decises crticas, na qualidade do produto, na segurana e nos custos operacionais. Tambm necessrio considerar que componentes de sistemas SCADA normalmente no tm uma grande capacidade de memria para que possam acomodar os programas de monitoramento de atividades de segurana, que so grandes e exigem muito processamento.

54

Em suma, pode-se dizer que os sistemas de TI so concebidos para prover conectividade interna e externa, produtividade e extensivos mecanismos de segurana para autenticao e autorizao, seguindo os trs maiores princpios da segurana da informao que so a confidencialidade, disponibilidade e integridade. Inversamente, os sistemas SCADA enfatizam a resposta em tempo real, tolerncia a situaes de emergncia, segurana das pessoas, qualidade do produto e segurana da planta. Exemplificando, pode-se relembrar o ataque ao sistema de controle de tratamento de resduos de Maroochy Shire, na Austrlia, no ano 2000. Naquele evento, a Planta passou por uma srie de problemas: bombas no acionavam quando comandadas, alarmes no estavam sendo reportados, e havia uma perda de comunicaes entre o centro de controle e as estaes de bombas. Estes problemas causaram o alagamento do terreno de um hotel prximo, um parque, e a contaminao de um rio com milhes de litros de resduos. A resposta a este ataque foi muito lenta e o atacante conseguiu lanar 46 ataques antes de ser pego. Em 1982, a ex Unio Sovitica foi vtima de uma bomba lgica que causou uma exploso na Sibria.

3.4.5. Terminal Services

Servios de Desktop Remotos (Remote Desktop Services), formalmente conhecidos como Terminal Services so um dos componentes do Microsoft Windows que permitem a execuo remota de aplicativos em um servidor com base em Windows, a partir de uma ampla variedade de dispositivos sobre virtualmente qualquer tipo de conexo de rede. Um servidor que executa os Terminal Services pode ser referido como um Terminal Server (TS). [57] Com Terminal Services, somente a interface com o usurio de uma aplicao apresentada ao cliente. Qualquer entrada redirecionada pela rede ao servidor, onde todas as aplicaes rodam. Esse tipo de arquitetura, cliente-servidor, diferente de aplicaes nas quais existe um servidor que centraliza e armazena os dados e os envia, sob demanda, mquina cliente, onde sero processados.

55

Esta tecnologia foi introduzida no Windows NT 4.0 e posteriormente melhorada no Windows 2000 e no Windows 2003 Server. Hoje, a verso cliente do software est disponvel em quase todas as verses do Windows com 32-bit, incluindo o Windows Mobile. H verses tambm o Apple e Mac OS X. [58]

3.5.

A TECNOLOGIA OPC (OLE FOR PROCESS CONTROL)

Tipicamente existem inmeros sistemas nas reas de produo, incluindo sistemas SCADA, IHMs, SDCDs, sistemas de manuteno, entre outros. Muitos destes sistemas tendem a ser aplicaes isoladas umas das outras, ou em outros casos possuem algum tipo de interface, mas no geral existe uma pequena integrao entre eles. Somando-se isso a dcadas de protocolos de comunicao proprietrios temos como resultado vrios sistemas desconexos dentro do prprio cho de fbrica. [59] Nesse contexto, surgiu, em 1996, a tecnologia OPC, como resultado da reunio de vrias empresas em torno de um objetivo comum: desenvolver um padro baseado na tecnologia OLE/DCOM para acesso a dados de tempo real dentro do sistema operacional Windows. Sendo assim necessrio compreend-las antes de apresentar um conceito final sobre o OPC. A tecnologia OLE (Object Linking and Embedding) foi desenvolvida pela Microsoft em meados de 1990, para suprir a necessidade de se integrar diferentes aplicaes dentro da plataforma Windows, de forma a solucionar os problemas de desempenho e confiabilidade do at ento utilizado padro Dynamic Data Exchange (DDE). [60] Como uma continuao da tecnologia OLE, o Distribuited Component Object Model (DCOM) surgiu junto com o sistema operacional Windows NT e foi logo aceito pela indstria. Basicamente, o DCOM um conjunto de definies usadas para permitir a implementao de aplicaes distribudas em uma arquitetura clienteservidor. Desta forma, um cliente pode acessar diferentes servidores ao mesmo tempo e um servidor pode disponibilizar suas funcionalidades para diferentes clientes simultaneamente. Atravs da definio de interfaces, o DCOM permite que objetos sejam instanciados de forma distribuda e seus servios e mtodos (funes)

56

sejam acessveis por diferentes programas. Para isso necessria a utilizao de uma linguagem especial, a Interface Definition Language (IDL). Atravs de um identificador nico (Global Unique Identifier, GUID), as interfaces so protegidas contra modificaes aps a sua publicao e a compatibilidade dos objetos DCOM ento garantida. [60] Como resultados do avano destas tecnologias tm-se o OPC, um conjunto comum de interfaces, mtodos e propriedades de comunicao, agregados dentro de uma especificao padronizada e aberta para acesso pblico. Teoricamente qualquer pessoa com conhecimentos de programao pode desenvolver seus aplicativos OPC, basta acessar as especificaes contidas no web site da OPC Foundation e desenvolver uma interface. [59] A figura abaixo apresenta um diagrama simplificado mostrando a diferena entre uma implementao na qual se faz uso do padro OPC e outra sem ele, mantendo interfaces dedicadas para cada comunicao.

Figura 3.18: Interfaces dedicadas versus OPC. [61]

Antes do OPC, cada software tinha que disponibilizar sua prpria forma de se conectar a aplicaes de terceiros. Ou seja, quando uma aplicao precisava de dados disponveis em outras fontes era necessrio desenvolver um driver especifico para estes pacotes. Isso gerava muitos problemas, tais como: muito trabalho desprendido em esforos para desenvolver vrios drivers para hardwares diferentes; dificuldades na compatibilidade entre os drivers e na alterao/atualizao dos mesmos, quando isso necessrio; conflitos de acesso, principalmente quando vrios sistemas desejam acessar o mesmo dispositivo, etc. Com a iniciativa do OPC, desenvolvedores da indstria de automao comearam a adotar a especificao de forma que as aplicaes fossem escritas com os mesmos padres OPC, assim elas poderiam se conectar rapidamente, com baixo custo e sem a necessidade de programao de cdigo. Para isso, o OPC

57

prov um mecanismo que fornece os dados de uma determinada fonte e comunicaos com qualquer aplicao cliente de forma padronizada, atravs de um servidor. Este servidor (servidor OPC) possui uma interface que possibilita o acesso a qualquer cliente OPC. A arquitetura e o design dessas interfaces so feitas de forma a suportar o desenvolvimento de servidores OPC em diversas linguagens, como C, C++, VB, etc.

Figura 3.19: Aplicaes rodando com vrios servidores OPC.[62]

O cliente OPC, por sua vez, uma aplicao de software que precisa dos dados dos sistemas de controle de processo e pode falar a linguagem definida pelas especificaes OPC para poder obter os dados de um servidor OPC. O servidor OPC, conforme dito anteriormente, o driver que fala com um hardware especfico, lendo e escrevendo dados e os disponibilizando para o cliente OPC. Como resultado do desenvolvimento dos trabalhos em torno dessa tecnologia, em setembro de 2006 estabeleceu-se a OPC Foundation, organizao sem fins lucrativos responsvel por coordenar todos os trabalhos em torno do marketing e das especificaes OPC. [63] Com o passar do tempo vrias especificaes OPC foram sendo lanadas, para atender as necessidades do mercado no campo da automao, so elas: Data Access Specification; Alarms and Events Specification; Historical Data Access Specification; Security Specification; Batch Specification; Data Exchange Specification;

58

XML-DA Specification, entre outras. Durante a elaborao da verso 2.0 da Data Access Specification e de outras especificaes surgiram elementos comuns, os quais foram reunidos em duas outras especificaes: o documento OPC Overview [62], que contm explicaes gerais e o OPC Common Definitions and Interfaces que traz definies normativas.[63] Um resumo destas publicaes encontra-se na figura 3.20.

Figura 3.20: Especificaes do padro OPC. [60]

Recentemente, houve o lanamento da especificao OPC Unified Architeture ou OPC UA. Esta nova especificao quer levar o OPC alm do ambiente industrial, tornando-se o padro para sistemas to distintos quanto um software de contabilidade e um controlador de campo. Confirmando seu nome, o OPC UA unificar todas as especificaes OPC, principalmente as OPC DA, HDA e AE. Ou seja, caso um equipamento ou sistema seja compatvel com OPC UA, ser possvel a troca de quaisquer tipos de dados, sejam eles dados em tempo real, histricos ou alarmes.

59

O OPC UA tambm vem de encontro constante evoluo da informtica e da Internet e alm de ser multi-plataforma, pois baseado em tecnologias orientadas para a web como TCP/IP, HTTP, SOAP e XML, deixando o COM em segundo plano assim como a prpria Microsoft j o fez. Isto significa que ser possvel utilizar o OPC no s em computadores com Windows, mas tambm em solues baseadas em outros sistemas operacionais como o Linux. [59] Os estudos atualmente encontram-se divididos em grupos especficos e as especificaes esto em constante evoluo. Todas essas informaes podem ser encontradas no site da OPC Foundation [64]. Nesse captulo foram abordados os principais conceitos das ferramentas e tecnologias que podero ser utilizadas no desenvolvimento do trabalho proposto no captulo anterior. No prximo captulo sero apresentadas as tcnicas utilizadas no desenvolvimento do trabalho bem como a justificativa e a aplicao do conhecimento adquirido durante o estudo deste captulo.

60

4 DESENVOLVIMENTO DO SISTEMA

Nas prximas sees so apresentadas as tcnicas e ferramentas utilizadas no trabalho, bem como as justificativas da escolha de tais ferramentas. Ao final, temse a modelagem e consideraes sobre a implantao do sistema.

4.1.

SISTEMA SUPERVISRIO [65] [33]

Diante dos vrios sistemas supervisrios disponveis no mercado e descritos na seo 3.2.5 a opo escolhida foi o supervisrio iFIX, da GE Fanuc, por ser um dos mais utilizados nas indstrias atualmente, pela sua tradio no mercado e pela confiabilidade e facilidade de utilizao das ferramentas de desenvolvimento. A seguir apresentado um breve histrico do sistema, sua arquitetura bsica e algumas outras caractersticas de funcionamento. Em 1984 foi lanada pela Intellution (Inteligent Solutions) a primeira verso do software de superviso e controle FIX, que na poca chamou-se THE FIX (uma adaptao visual/sonora para FICS - Fully Integrated Control System). Desde aquela, vrias outras verses foram lanadas, com destaque para o FIX DMACS (Distributed Manufacturing Automotion and Control Software - 1988), que foi o primeiro software do tipo SCADA (Supervisory Control and Data Acquisition) com arquitetura cliente/servidor a ser lanado para microcomputadores pessoais. Podem ser citadas ainda verses para VMS, OS2, Windows e Windows NT (Intel e Alpha). A verso atualmente comercializada o iFIX 5.0, sendo que a atual detentora dos direitos deste software a GE Fanuc. O iFIX tem dois modos de operao: run e configure. No modo run, as telas podem ser visualizadas da forma como sero vistas pelos operadores e no modo configure destaca-se o Workspace, onde, conforme descrito na seo 3.2.5, possvel desenvolver interfaces e acessar outros componentes do sistema. Os principais componentes/ferramentas so:

61

a) Aquisio de dados de Processo O iFIX usado em conjunto com a instrumentao do processo de uma planta. Os sensores e controladores enviam dados para serem registrados no hardware de processo, do qual o software iFIX adquire dados. b) Drivers I/O O iFIX se comunica com o controlador atravs de um driver I/O, o qual suporta hardwares especficos. Esses drivers exercem funes de leitura (e escrita) de dados do dispositivo, transfere dados de/para endereos na Tabela Imagem do Driver (DIT- Driver Image Table), que referenciada tambm como a Poll Table. Para monitorar e controlar esses drivers tem-se o I/O Control, ferramenta que faz parte do Mission Control, o indicador do status de funcionamento do drivers. c) Tabela Imagem do Driver (DIT) Trata-se de uma rea de memria do SCADA onde o driver I/O armazena os dados, que so atualizados pelos drivers, a uma determinada taxa, chamada de poll time ou update rate. d) Varredura, Alarme e Controle (SAC Scan, Alarm and Control) As funes do SAC incluem: Ler os dados da DIT Transferir dados para a base de dados do processo (PDB Process DataBase) O SAC pode ser monitorado atravs da ferramenta Mission Control e sua taxa de leitura chamada de scan time. e) Base de Dados do Processo (PDB) A representao do processo feita atravs de tags (tambm chamados de blocos). Um conjunto de tags pode ser conectado para formar cadeias para monitorar o processo. No iFIX, as funes do tag incluem comparar os valores do processo com os limites de alarmes, realizar clculos baseados em valores especficos do processo e escrever valores no hardware do processo

62

f) Tela de Operador Uma vez os valores estando na PDB, estes podem ser mostrados graficamente atravs de uma IHM. Nas telas grficas das IHM so usados objetos grficos para mostrar valores da base de dados, informaes sobre alarmes e informaes especficas de um tag. g) System Configuration (SCU) A configurao dos drivers de comunicao se d atravs do aplicativo denominado System Configuration Unit (SCU). tambm atravs deste aplicativo do iFIX que se configura, habilita ou desabilita, por exemplo, alarmes, segurana, comunicao em rede, etc.

Figura 4.1: Tela do SCU. [65]

h) Base de dados O cerne de toda funcionalidade do iFIX a tabela de dados do processo. Esta tabela opera a partir da captao dos dados na DIT, feita pelo SAC. Estes dados so ento manipulados pelos blocos e cadeias que compe esta tabela.

63

Figura 4.2: Base de dados, inserindo um novo bloco. [65]

A tabela de dados criada pelo programa Database Manager, e como foi dito, baseia-se em blocos e cadeias de blocos. O bloco, tambm chamado de tag, pode ser definido como um conjunto de instrues pr-definido que vai manipular os dados por ele recebidos. Cada bloco possui um conjunto de parmetros que devem ser informados para que o bloco opere os dados de modo adequado. Uma cadeia formada por um conjunto de blocos organizados de forma a permitir a execuo de um controle ou de uma monitorao. Pode-se supor, por exemplo, que deseja-se ler um valor do campo, us-lo em uma frmula pr-definida e em seguida envi-lo de volta ao campo (aumentando ou reduzindo a abertura de uma vlvula). Em termos de cadeia de blocos, isso ser obtido com um Bloco Analgico de Entrada, seguido de um Bloco de Clculo e, finalmente um Bloco Analgico de Sada. Os principais blocos utilizados nas bases de dados so: AI entrada analgica, AR registro analgico, DI entrada digital, DO sada digital, DR registro digital, BI bloco booleano, TR- bloco de trend.

i) Scripts Scripts so as lgicas desenvolvidas a partir da lista de comandos do iFIX. Com os comandos disponveis possvel desenvolver uma infinidade de lgicas com os mais variados objetivos. Os scripts fazem parte da lista de propriedades

64

dinmicas e so executados no ambiente View atravs do clique do mouse, em uma das seguintes opes: on up, on down, e while down.

Arquitetura bsica A arquitetura bsica do iFIX dividida em ns (figura 4.3). Um n um computador rodando o iFiX. Os principais tipos de ns so descritos detalhadamente no quadro 4.1.

Figura 4.3: Ns do iFiX. [33]

Tipo de n Local e remoto

N isolado (stand alone)

Quadro 4.1: Tipos de ns do iFIX Descrio Quando se trabalha com um sistema iFIX distribudo, o termo local refere-se a um n no qual se est trabalhando atualmente e remoto refere-se a um n que precisa de um link de comunicao para ser acessado. Quando se trabalha com um sistema SCADA iFIX centralizado, isolado refere-se ao n que realiza todas as funes. Ns isolados no esto em rede.

65

Um servidor SCADA (ou n SCADA) roda os componentes de aquisio de dados e gerenciamento do iFIX. Normalmente Servidor SCADA um n SCADA encontra-se no cho-de-fbrica e tem conexes diretas com o hardware de processo. O termo blind, do ingls quer dizer cego, j que esse tipo de Servidor SCADA n no usa display grfico. Essa configurao permite que os Blind recursos do computador sejam todos direcionados para a aquisio de dados e funes de gerenciamento de rede. Um n run-time no permite que sejam modificados os grficos ou a base de dados do processo. Arquivos prN run-time configurados so instalados nesse n de forma que s possvel monitorar o processo, mudar configuraes de processo e reconhecer alarmes. Um iClient (ou n View) tipo mais comum de n. Os ns View mostram os grficos em tempo real. O termo View iClient significa que o n roda o programa de display grfico, mas no pode rodar outras aplicaes. iClient somente Um iClient somente de leitura tem as mesmas funcionalidades do iClient, exceto pelo fato de no poder escrever na base de para leitura (iClient Read Only) dados do iFIX nem nos servidores OPC. Fonte: [33] Nesse trabalho utilizou-se um n SCADA e um n iClient, j que essa configurao se adequava s necessidades da aplicao que inicialmente pequena, desenvolvida pensando-se em poucos dispositivos mveis, o que no requer muito processamento. A estrutura simplificada mostrada na figura 4.4.

Figura 4.4: Estrutura simplificada do sistema, destacando-se os ns do iFIX.

No n SCADA foi instalado o iFIX verso 4.0, escolhendo-se a opo SCADA j na instalao. O nome dado a este n foi SUPMOV1 e sua funo era adquirir os dados do processo, isso foi feito via OPC. A verso do driver OPC instalada foi a 7.36, disponibilizada em um dos CDs que acompanha o iFIX. Como parte dos

66

requisitos de software do iFIX, instalou-se o Sistema Operacional Windows 2003 Server na mquina SCADA. Mais detalhes da configurao desse micro, podem ser vistos no anexo 2. importante ressaltar que o micro deveria ter apenas o sistema operacional, sem nenhum outro aplicativo instalado, pois o iFIX no funciona corretamente com aplicativos rodando em background, como antivrus e firewall, por exemplo. Para que a comunicao OPC pudesse funcionar o SCADA e os demais micros foram colocados no mesmo workgroup e as contas de usurio dele e do View tinham o mesmo nome de usurio e a mesma senha. Assim como no SCADA, no n View foi instalada a verso 4.0 do iFIX, escolhendo-se a opo View e o nome SUPMOV2, durante a instalao. Uma peculiaridade deste em relao ao SCADA a de que, alm do sistema operacional Windows 2003 Server, foi necessrio instalar e configurar o Terminal Services (TS), motivo pelo qual a partir de agora este n ser chamado de iClientTS. A funo deste n receber esses dados do SCADA e public-los atravs do Terminal Service, usando rede wireless, para o dispositivo mvel. Para que os dados pudessem chegar ao n iClientTS ele foi interligado em rede com o n SCADA. A rede utiliza protocolo proprietrio da Intellution, atravs de conexo Ethernet TCP/IP. Algumas taxas que so configuradas no iFIX merecem destaque, so elas; Scan time: Freqncia com que o SAC recupera os dados da DIT. No caso, o scan time utilizado foi de 1 segundo. Poll time ou update rate: Freqncia de tempo com que o I/O driver l as variveis no hardware de processo e atualiza seus valores para cada registro. A update rate utilizada foi de 1 milisegundo. Refresh rate: Freqncia com que cada objeto animado solicita o valor atual ao OPC Server. A refresh rate utilizada foi de 0.1 segundo. Poll rate: Freqncia com que o OPC Client captura dados do OPC Server para um grupo especfico de itens. Quando a comunicao assncrona, o OPC Client aguarda o servidor enviar os dados, exceto se estiver habilitada a opo Enable Asynchronous Watchdog. Dessa forma o cliente pode periodicamente solicitar dados ao servidor, garantindo assim que no haja perda de dados. A poll rate utilizada foi de 5 minutos.

67

4.2.

HARDWARE

Os hardwares utilizados nessa aplicao, citados na seo 2.5, sero mais bem detalhados nessa seo.

4.2.1. Dispositivo mvel

Analisando-se os dispositivos mveis descritos na seo 3.4.3.1 optou-se pelo Pocket PC, pois ele funciona com a plataforma Windows (Windows CE), o que facilita a comunicao com o iFIX, que funciona no Windows 2003 Server. Os Pocket PCs tambm so mais robustos e suportam mais processamento do que os demais handhelds. No mercado j existem algumas verses de supervisrios mveis proprietrios que funcionam com Pocket PC, o que comprova sua grande aplicabilidade nesse tipo de implementao. O Pocket PC utilizado foi o HP iPAQ 4100 series, que j encontrava-se disponvel na empresa, e cujas especificaes tcnicas podem ser encontradas no anexo 2. Sua principal caracterstica, necessria a essa implementao, a facilidade de acesso wireless segundo o padro 802.11b, atravs do iPAQ wireless menu. No sistema desenvolvido o Pocket PC deveria se comunicar com o n iClientTS do iFIX, via Terminal Services, para receber as informaes das interfaces j desenvolvidas e replic-las em seu display. Dessa forma, sua principal funo ser um desktop remoto, fornecendo acesso aos dados disponveis no iClientTS. Assim, o usurio pode navegar pelas opes clicando sobre elas com a caneta que acompanha o Pocket PC ou tocando sobre a tela touchscreen dele.

4.2.2. Ponto de acesso (AP)

Para implementar a rede sem fio foi escolhido o modo de operao infraestrutura, descrito em detalhes na seo 3.4.3, e por isso fez-se necessrio o uso de

68

um ou mais pontos de acesso para que fosse garantida uma das principais caractersticas do sistema, a mobilidade. Os pontos de acesso, semelhantemente a outros dispositivos de rede, tm a funo de retransmitir os pacotes de dados, de forma que todos os micros da rede os recebam, mas so dispositivos inteligentes, que podem ser configurados atravs de uma interface de administrao via web. O ponto de acesso utilizado foi o DWL 7100AP, da D-Link, uma das empresas mais reconhecidas no ramo de dispositivos de rede. As especificaes tcnicas podem ser encontradas no anexo 2. Uma questo muito importante a ser considerada a atenuao do sinal. sabido que a potncia do sinal decai conforme aumenta a distncia, enquanto a qualidade decai pela combinao do aumento da distncia e dos obstculos pelo caminho. por isso que num campo aberto o alcance ser muito maior do que dentro de um prdio, por exemplo. Sendo assim, algumas recomendaes de instalao so feitas pelo fabricante, tais como: posicionar os dispositivos de forma a ter o menor nmero possvel de obstculos entre ele e o AP e que o sinal possa atravessar os obstculos diretamente e no contorn-los; evitar obstculos como portas slidas de metal ou alumnio, podendo mant-los desde que estejam abertos, por exemplo; manter o AP de 1 a 2 metros de distncia de equipamentos eltricos que possam causar rudo de radiofreqncia. [66] No sistema de superviso mvel, o ponto de acesso deveria comunicar-se com o n iClient (figura 4.5), via rede Ethernet e transmitir os dados ao Pocket PC, no qual existem adaptadores de rede vindos de fbrica.

Figura 4.5: Ligao no ponto de acesso.

69

4.2.3. Switch

O switch um aparelho que possibilita a conexo de computadores em redes, cuja forma de trabalho muito simples: o switch recebe os dados vindos de um computador e os transmite ao computador de destino. Isso possvel porque os switchs criam uma espcie de canal de comunicao exclusiva entre a origem e o destino. Dessa forma, a rede no fica "presa" a um nico computador no envio de informaes, aumentando seu desempenho, j que a comunicao est sempre disponvel, exceto quando dois ou mais computadores tentam enviar dados simultaneamente mesma mquina. Essa caracterstica tambm diminui a ocorrncia de erros (colises de pacotes, por exemplo). Nesse tipo de equipamento a quantidade de portas varia de acordo com o modelo e fabricante do equipamento. [67] No sistema de superviso mvel foi utilizado um switch de quatro portas, nas quais se conectou o AP, os dois ns do iFIX e o um outro laptop, o single node, que ser explicado mais adiante (Figura 4.6). A utilizao deste equipamento foi adequada, pois se tratava de uma pequena rede local. Caso contrrio seria necessrio um roteador, por exemplo, equipamento semelhante, mais sofisticado e usado em redes de grande porte.

Figura 4.6: Utilizao de um switch no sistema de superviso mvel.

70

A figura 4.6 mostra a estrutura montada com um switch no sistema, no entanto, devido sua ao inerente ao sistema e para facilitar o entendimento, nas prximas figuras ao longo do trabalho ele pode no ser mostrado, estando subentendido que est conectando os 4 equipamentos.

4.3.

MODELAGEM DO SISTEMA

Os sistemas de automao industrial modernos atingiram tal nvel de complexidade que a intuio e experincia humana no so mais suficientes ou eficientes para construir rapidamente modelos bem definidos dos mesmos. Um ambiente de modelagem torna-se necessrio para a que se alcance este objetivo. Nestas circunstncias o planejamento da arquitetura do sistema um dos aspectos mais importantes. Por arquitetura entende-se a decomposio do sistema em seus componentes principais, bem como a especificao de seus relacionamentos. A arquitetura de sistemas , geralmente, retratada como um diagrama de blocos mostrando os subsistemas principais e suas interconexes.[29] O diagrama da arquitetura do sistema est indicado na figura 4.7.

Figura 4.7: Arquitetura do sistema de superviso mvel.

O modelo de objetos uma abordagem promissora para a especificao de arquiteturas de sistemas por duas razes principais:

71

Prev uma arquitetura: um sistema orientado a objetos pode ser descrito como uma rede de componentes interconectados. Recurso da herana: encoraja abstrao e generalizao cruciais para o desenvolvimento das arquiteturas. As vantagens do uso de orientao a objetos em sistemas de simulao so plenamente aceitas nos dias de hoje. O paradigma da orientao a objetos tem sido bastante utilizado no desenvolvimento de sistemas industriais tempo-real, uma vez que objetos permitem estruturar a informao de uma forma lgica, aumentando o trato de sistemas complexos. Alm disso, outros benefcios como a fcil manuteno, o melhor gerenciamento e a modularidade proporcionaram a utilizao de modelos orientados a objetos nestes sistemas. [68] Diante disso desenvolveu-se a modelagem do sistema utilizando o paradigma orientado a objetos, utilizando a Linguagem de Modelagem Unificada (UML) e levando em considerao o mtodo de desenvolvimento de software proposto na seo 3.2.4. I. Especificao do sistema

a) Requisitos funcionais: Os requisitos funcionais que o sistema deve obedecer so: Aquisio dos dados do SDCD; Possibilidade de o usurio consultar as dados dos filtros da rea 5 na tela do dispositivo mvel atravs de interfaces grficas; Gerao de alarmes; b) Requisitos no-funcionais: Os requisitos no-funcionais que o sistema deve obedecer so: Utilizao do padro OPC para comunicao; Utilizao do protocolo TCP/IP para comunicao; Uso de rede sem fio para garantir a mobilidade do sistema; Desenvolvimento de interfaces usurio-computador atravs de ferramentas de desenvolvimento grfico; Utilizao dos Terminal Services para comunicao;

72

Garantia da mobilidade do sistema; Atraso dos dados de, no mximo, 1 minuto. c) Limitaes do sistema: Tamanho da tela do dispositivo mvel; Impossibilidade de abrir vrias telas (interfaces) simultaneamente; No possvel exercer o controle sobre o processo, ou seja, no possvel enviar comandos ao processo. II. Especificao do software

A especificao em questo representada em forma de diagrama de casos de uso, diagrama de seqncia, diagrama de atividades, alm do Modelo do Banco de Dados utilizado.

a) Diagrama de Caso de Uso: Representao das funcionalidades externamente observveis (figura 4.8). [69]

Figura 4.8: Diagrama de Casos de Uso do Sistema

73

Descries dos casos de uso: As descries foram feitas no formato essencial, mas de acordo com o modelo proposto por Bezerra, em [69].

Visualizar dados dos filtros da rea 5 (CSU 01) Sumrio: O usurio visualiza os dados de processo dos filtros da rea 5 na tela do dispositivo mvel, em uma interface grfica. Ator primrio: Usurio com Pocket PC Pr-condies: Os dados estarem disponveis ao iClientTS e o usurio estar conectado rede sem fio. Fluxo Principal: 1. O usurio abre o programa Cliente de Terminal no Pocket PC para estabelecer uma conexo via Terminal Services; 2. O usurio insere o IP da mquina iClientTS e conecta-se a ela; 3. O usurio roda o iFIX; 4. Na tela inicial do sistema o usurio comea a navegar nas pginas do sistema, de acordo com o filtro que desejar. 5. O usurio visualiza os valores (tags) e acompanha suas variaes. Fluxo Alternativo: 1. O usurio no consegue utilizar o Pocket PC; 2. O usurio consulta o manual de instrues do sistema de superviso mvel e o caso de uso termina. Ps-condies: O usurio conseguiu exercer superviso sobre os filtros da rea 5.

Conectar-se rede sem fio (CSU 02) Sumrio: Usurio consegue detectar e conectar-se rede sem fio atravs do Pocket PC. Ator primrio: Usurio com Pocket PC Pr-condies: O usurio possuir um Pocket PC e saber utiliz-lo. Fluxo Principal: 1. O usurio liga o Pocket PC; 2. O usurio entra no menu Iniciar e clica em iPAQ Wireless; 3. Na nova janela clica em WLAN at que o cone fique verde;

74

4. Se a rede for detectada automaticamente o usurio somente clica em conectar quando o cone de rede sem fio surgir na tela.. 5. Caso a rede sem fio no seja detectada automaticamente o usurio deve configur-la manualmente seguindo as instrues do fabricante. Fluxo Alternativo: 1. O usurio no consegue conectar-se rede sem fio e o caso de uso termina. Ps-condies: O usurio fica conectado.

Rodar e atualizar interfaces (CSU 03) Sumrio: O n iClientTS roda as interfaces grficas e consulta a base de dados periodicamente para atualizar os pontos dinmicos (variveis). Ator primrio: iClientTS Pr-condies: O n iClientTS estar corretamente configurado para conectarse ao SCADA e os arquivos de interface grfica (com extenso .grf) estarem nele. Fluxo Principal: 1. O projetista do sistema liga o computador do iClientTS; 2. O projetista configura a refresh rate para cada objeto; 3. O iFIX inicializado e inicia-se a execuo em modo run; 4. A tela inicial exibida e mostra-se o menu inicial; 5. O supervisrio consulta periodicamente a base de dados do SCADA (CSU 06) para exibir os dados na tela. Fluxo Alternativo: 1. O iClientTS no consegue desempenhar suas funes satisfatoriamente e o caso de uso termina. Ps-condies: O Sistema est pronto para ser replicado no display do Pocket PC.

Armazenar dados em uma base de dados (CSU 04) Sumrio: O SCADA adquire os dados do single node e os armazena em uma tabela na base de dados. Ator primrio: SCADA

75

Pr-condies: O sistema SCADA ter comunicao com o single node, via OPC e ter o driver OPC Client instalado. Fluxo Principal: 1. O SAC, servio que roda no SCADA, l automaticamente os dados da DIT. 2. O projetista/desenvolvedor do sistema SCADA configura o scan time; 3. A cada perodo do scan time o SAC automaticamente armazena os dados da DIT na base de dados (PDB). Fluxo Alternativo: 1. O SAC no reconhece os dados da DIT e no prossegue com a leitura; 2. O projetista/desenvolvedor do sistema SCADA d um shutdown no iFIX e reinicia-o; 3. Se o SAC no funcionar o caso de uso termina. Ps-condies: O sistema est pronto para que o iClientTS receba os dados.

Adquirir dados do processo (CSU 05) Sumrio: O sistema SCADA do iFIX adquire os dados de processo do SDCD, nesse caso do single node. Ator primrio: SCADA Pr-condies: Os procedimentos para inicializao e simulao no single node j terem sido realizados. Fluxo Principal: 1. O projetista/desenvolvedor do sistema SCADA instala o driver OPC, com a mesma verso, no single node e no SCADA; 2. O projetista/desenvolvedor configura a update rate; 3. O SCADA automaticamente atualiza os dados de acordo com a update rate. 4. O projetista/desenvolvedor configura a deadband. 5. O OPC Server envia os dados a cada alterao para o OPC Client, no SCADA. 6. Os dados obtidos pelo driver OPC so automaticamente armazenados na DIT. Fluxo Alternativo:

76

1. No sendo possvel capturar os dados do single node, o projetista verifica se o OPC Server est funcionando corretamente nele. Ps-condies: O SCADA tem os dados do processo disponveis, em tempo real e de forma confivel para serem armazenados na base de dados

Consultar base de dados (CSU 06) Sumrio: O sistema iClientTS do iFIX consulta a base de dados do SCADA para atualizar os valores dos tags no display. Ator primrio: iClientTS Pr-condies: Os dados estarem disponveis na base de dados do iFIX. Fluxo Principal: 1. O iFIX instalado no iClientTS acessa os dados na base de dados do SCADA atravs da rede utilizando um protocolo proprietrio da Intellution. Fluxo Alternativo: 1. O iFIX instalado no iClientTS no consegue acessar a base de dados do SCADA e surgem erros de conexo na tela. 2. O caso de uso termina. Ps-condies: Os dados coletados so mostrados nas interfaces grficas, no display do View. b) Diagrama de Seqncia O enfoque deste diagrama est em como as mensagens so enviadas entre os objetos que esto relacionados. Os diagramas de seqncia e caso de uso esto intimamente relacionados, no entanto, o diagrama de seqncia exibido na figura 4.9 um diagrama geral do sistema, no relacionado a um caso de uso apenas. Os objetos que fazem parte do diagrama (figura 4.9) so: Terminal Services: Servio de desktop remoto do Windows; iFIX iClientTS: N do iFIX que roda as aplicaes grficas; iFIX SCADA: N do iFIX que faz o gerenciamento e aquisio de dados. Dentro dele roda o SAC, responsvel por ler os dados da DIT; DIT: Tabela onde so armazenados os dados lidos pelo driver de I/O.

77

OPC Client: Driver OPC que solicita informaes ao servidor; OPC Server: Driver OPC responsvel por adquirir os dados do processo; Processo: Processo produtivo da Alunorte para a produo de alumina. Nesse caso trata-se especificamente da rea 5 (filtrao).

Figura 4.9: Diagrama de seqncia geral do sistema.

c) Diagrama de atividades Os diagramas de atividades so orientados a fluxos de controle e representam os estados de uma atividade. Uma caracterstica importante a de possuir uma notao especfica para representar aes concorrentes (paralelas), juntamente com a sua sincronizao. [69]

78

Figura 4.10: Diagrama de atividades do sistema

d) Modelo Banco de Dados Na estrutura do iFIX s permitida a criao de uma base de dados, composta de uma nica tabela, portanto, o sistema precisou se adaptar a essa limitao. A modelagem desta tabela est representada na figura 4.9.

Figura 4.11: Modelo da Tabela principal do Banco de Dados do iFIX

. As etapas que levaram implementao do sistema sero descritas na seo 4.4, os testes sero descritos no captulo 5 e o estgio final do ciclo de vida do software, a fase de operao e manuteno, ainda no foi executada, visto que o sistema apenas foi testado em laboratrio e ainda no se encontra efetivamente em operao.

79

4.4.

IMPLEMENTAO DO SISTEMA

Uma vez escolhidas todas as tecnologias adequadas s necessidades do sistema de superviso mvel proposto ele foi implementado e testado em laboratrio, ou seja, no foram feitos testes em campo. A principal diferena entre a estrutura montada em laboratrio e a estrutura real est na fonte das informaes e na WLAN montada para simular o campo, isto porque os dados utilizados no foram reais e nem online, e a WLAN, montada em laboratrio no apresenta as mesmas diversidades para a propagao do sinal que apresentaria se estivesse em campo. Nessa seo sero detalhados os procedimentos para a instalao e configurao do sistema.

4.4.1. Instalao

Para realizar os primeiros testes do sistema utilizou-se um equipamento conhecido como single node, no qual possvel simular o sistema real, mas sem estar conectado a ele. O single node um notebook no qual so instalados todos os programas e projetos que rodam no supervisrio tradicional, alm de softwares de simulao. A vantagem de se utilizar esse tipo de ferramenta a de que no existe risco para a planta, pois o sistema do single node no est conectado rede real. Os dados so apenas carregados nele e possvel simular um controlador por vez. Para que ele pudesse funcionar para os fins a que se destinam esse trabalho foi o primeiro procedimento foi importar o projeto da rea 5 do sistema real e export-lo para o notebook. Em seguida, para que ele pudesse se comunicar com o SCADA foi preciso montar uma rede Ethernet simples, configurar o DCOM, liberando permisses de usurios para leitura e escrita de dados nas duas mquinas, criar uma conta de usurio no n SCADA com exatamente o mesmo nome e senha do usurio do single node, entre outras configuraes.

80

(a)
SCADA iClientTS

Single node

Ponto de Acesso

(b)
Figura 4.12: Diagrama (a) e foto (b) da estrutura montada em laboratrio para o sistema de superviso mvel.

No laboratrio, o AP foi posicionado de forma que o Pocket PC recebesse o sinal sem muitas atenuaes (figura 4.12). Na figura as setas direcionais no diagrama indicam o sentido do fluxo da informao. No entanto, importante salientar que no campo a situao bem diferente, pois existem inmeros obstculos, como tanques, pipe racks e prdios que dificultam a passagem do sinal. Como todos os equipamentos precisavam se comunicar, todos foram colocados na mesma rede, com mesma mscara de sub-rede. Destaca-se o fato de toda a rede ter sido baseada no IP da placa de rede do single node, por uma restrio do software de simulao e do sistema da ABB instalado no notebook. No sistema da ABB, os dados so divididos em projetos. No nosso caso, utilizamos o projeto da Filtrao como fonte de informaes. Em cada projeto existem um ou mais controladores, abaixo dos quais esto os tags dos instrumentos e demais equipamentos. Para que seja possvel acessar tais dados necessrio

81

que o controlador receba um IP e o IP que faz o sistema funcionar o IP da placa de rede do single node, j que o software de simulao est instalado nele. Sendo assim, o IP disponvel no single node era 172.16.120.75 e por isso toda a rede foi endereada desta forma (Figura 4.13).

Figura 4.13: Endereamento IP da rede montada em laboratrio

O Pocket PC recebeu o IP 172.16.120.7 automaticamente quando detectou o sinal da rede. importante destacar que se os IPs no fossem fixos o sistema no funcionaria, mas isso um fator que aumenta a vulnerabilidade do sistema. Na figura 4.14 possvel ver um ping da mquina SCADA (origem) nas mquinas iClientTS, Pocket PC e Single Node (destino), atravs desse comando do Windows possvel confirmar que os equipamentos esto todos na mesma rede, j que em todos os casos 100% dos pacotes foram recebidos, ou seja, houve 0% de perda (destaque em vermelho). O comando ip config mostra que a mquina de origem mesmo a SCADA, identificada pelo IP circulado em verde.

82

Figura 4.14: Resultados de pings originados no n SCADA aos demais componentes do sistema.

4.4.2. Configurao

Algumas caractersticas da configurao do sistema j foram descritas anteriormente, mas nessa seo elas sero explicadas de forma mais detalhada.

Configuraes n SCADA

A comunicao entre o single node e o n SCADA foi feita via OPC. Nesse caso o OPC Server era o single node e o OPC Client era o n SCADA. O OPC

83

Server j estava instalado na mquina, pois do mesmo fabricante do SDCD, a ABB. Para que essa comunicao entre OPC Client e Server remoto pudesse ocorrer foi necessrio coloc-los em um mesmo workgroup do Windows, criar contas de usurio e senhas iguais para ambos e realizar vrias configuraes no DCOM. Terminadas estas configuraes e estabelecida conexo, utilizou-se, no SCADA, o programa OPC Power Tool, que instalado automaticamente quando se instala o driver OPC, a partir do CD do iFIX. No software foram feitas as seguintes configuraes: 1. Adicionou-se o servidor de dados da ABB, instalado no Single node (figura 4.15); 2. Ao servidor, adicionou-se um grupo: o controlador EC_05D_01, no qual esto os dados do projeto da rea escolhida, a Filtrao. O grupo foi configurado de acordo com as necessidades da aplicao, conforme ser explicado posteriormente. 3. Ao grupo, adicionaram-se vrios itens, correspondentes aos sinais (tags) que foram escolhidos para serem exibidos. Formou-se ento, uma espcie de rvore de diretrios (figura 4.16). Nesta ferramenta possvel tambm ter acesso a vrias informaes estatsticas, bem como acompanhar o status da comunicao (Good ou Bad). importante destacar que os dados obtidos so armazenados na DIT e atualizados periodicamente. As configuraes do grupo EC_05D_01 so muito importantes para o funcionamento do sistema. As principais so mostradas na figura 4.17 e explicadas no quadro 4.2.

Quadro 4.2: Descrio dos principais itens configurados no grupo EC_05D_01 Item Descrio I/O Type Tipo de comunicao. Pode ser sncrona ou assncrona. Na sncrona o OPC Cliente requisita dados ao OPC Server de acordo com a poll rate. Na assncrona o OPC Server manda dados ao Cliente de acordo com as modificaes ocorridas. Freqncia com que o driver l as variveis no single node e atualiza seus valores para cada registro. Fonte de dados. No caso, a memria cache. Porcentagem mnima de variao de um dado.

Update Rate Data Source Deadband

84

Poll rate Enable Asynchronous Watchdog Async Timeout

Frequncia com que o OPC Client captura dados do OPC Server. Funo que permite que o OPC Client solicite dados ao servidor, mesmo estando no modo assncrono. Tempo que o OPC Client espera por uma atualizao do OPC Server. Disponvel apenas no modo assncrono. Fonte: [33]

Figura 4.15: Detalhe mostrando o OPC da ABB, utilizado como OPC Server no sistema.

Figura 4.16: OPC Power Tool com destaque em algumas estatsticas.

85

Figura 4.17: Configuraes do grupo EC_05D_01.

Segue-se ento segunda etapa: configurar a base de dados. Essa configurao foi feita no n SCADA, utilizando-se o software Database Manager, componente do iFIX. No programa foi criada uma tabela de dados contendo os itens adicionados ao grupo EC_05D_01. Cada item correspondia a um bloco (tag) e cada tag correspondia a uma linha na tabela de dados (figura 4.18). O bloco mais utilizado foi o de entrada analgica (AI).

Figura 4.18: Tabela do componente Database Manager

Com todas as configuraes feitas no n SCADA e confirmando-se a chegada correta dos dados, partiu-se ento para as confeco das telas, no n iClientTS.

86

Desenvolvimento das telas Configurao iClientTS

No n iClientTS foram desenvolvidas as interfaces grficas, utilizando as ferramentas disponveis no workspace e conforme os requisitos e a modelagem descrita na seo anterior. Buscou-se facilitar a navegabilidade dos usurios criando um sistema de telas de menu em seqncia. Dessa forma tambm torna-se mais fcil a expanso do sistema, caso se deseje acrescentar mais equipamentos. Na confeco das telas tentou-se copiar, da melhor forma possvel, a tela do sistema real, com a qual os profissionais j esto familiarizados. No entanto, as vlvulas (na cor vermelha) no so animadas, pois isso envolveria a criao de vrios outros tags tanto no servidor OPC quanto na PDB, embora o iFIX oferea tais recursos de animao (a vlvula fica verde quando abre e vermelha quando fecha, por exemplo) O resultado mostrado a seguir.

87

Figura 4.19: Interfaces desenvolvidas para o sistema de superviso mvel.

Para que os dados pudessem ser capturados do SCADA, foi necessrio configurar os links fazendo referncia ao n SUPMOV1, como mostra a figura 4.20.

Figura 4.20: Configurao de um datalink

Com os dados aparecendo corretamente no modo run do iClientTS concluiuse a etapa de configuraes do iFIX, faltando apenas as configuraes no Pocket PC.

Configuraes Pocket PC

O Pocket PC se comunica com o n iClientTS via wireless e Terminal Services (figura 4.21), para isso foi utilizado o aplicativo iPAQ Wireless para configurar a conexo de rede sem fio [70], e o programa Cliente de terminal, que j vem instalado no Pocket PC, porque faz parte dos componentes do sistema do Windows CE e cliente dos Terminal Services. Por esse motivo, no foi necessrio instalar nenhum aplicativo a mais no equipamento. A configurao do programa

88

Cliente de Terminal consiste, apenas em colocar o IP do iClientTS e clicar no boto conectar. Estabelecida a conexo apresenta-se ao usurio a tela de login do Windows, exatamente da forma como mostrada no computador ao lig-lo. Coloca-se o usurio e a senha e depois prossegue-se execuo do iFIX. A figura 4.21 e o quadro 4.3 mostram um resumo das configuraes feitas no sistema. Uma foto do sistema real apresentada na figura 4.22.

Figura 4.21: Esquema geral de clientes e servidores do sistema.

Quadro 4.3: Descrio dos softwares instalados e configuraes feitas. Equipamento Softwares instalados Configurao Single Node Driver OPC 7.36 e OPC Power Tool Configuraes de DCOM; Configuraes no projeto da filtrao. SCADA Wndows 2003 Server Configuraes de DCOM; iFIX 4.0 para SCADA Configuraes OPC e de Driver OPC 7.36 e OPC Power Tool base de dados. iClientTS Windows 2003 Server com Terminal Services iFIX 4.0 para View Interfaces grficas; Configuraes de Terminal Services; Configuraes de rede para comunicar com SCADA. Conexo de rede sem fio; Cliente de terminal.

Pocket PC

89

Figura 4.22: Usurio testando o Pocket PC, com destaque para o Pocket PC.

O desenvolvimento do sistema supervisrio mvel e dos demais subsistemas relacionados a ele foram explorados nesse captulo, principalmente no que se refere aos aspectos de instalao e configurao de cada um, em laboratrio. A diferena entre a estrutura da proposta inicial e a desenvolvida em laboratrio, utilizando-se o single node, tambm foi esclarecida e explicitada atravs de vrias figuras. No captulo seguinte sero apresentados os testes feitos com o sistema e os resultados alcanados.

90

5 APRESENTAO DOS RESULTADOS

Nas prximas sees apresentado o sistema final como um todo e os resultados dos testes desenvolvidos em laboratrio com a primeira verso do sistema.

5.1.

SISTEMA FINAL

De uma forma geral, o sistema descrito em detalhes no captulo 4 pode ser visto da seguinte forma:

Figura 5.1: Representao geral do sistema de superviso mvel.

Na figura 5.1 destacam-se as funes de cada equipamento dentro do sistema bem como as redes montadas para estabelecer a comunicao entre eles. notria a utilizao da arquitetura cliente-servidor em todo o sistema. Os procedimentos necessrios para inicializar o sistema, resumidamente so: 1. Ligar o single node, e inicializar o simulador da planta (figura 5.2);

91

Figura 5.2: Simulador da planta industrial utilizado no single node.

2. Abrir o software do SDCD e fazer o download no controlador. O procedimento de download, neste caso, consiste em colocar valores nos tags, que esto vazios, devido ao fato de se estar apenas realizando uma simulao da planta. O download preenche a maior parte dos tags com o valor zero. 3. Conectar o OPC Server Data Access no IP do projeto (172.16.120.75), conforme a figura 5.3;

Figura 5.3: Programa OPC Server Configuration.

4. No n SCADA, abrir a ferramenta OPC PowerTool, conectar o driver OPC localmente e em seguida procurar o arquivo de configurao (com extenso .opc) correspondente ao sistema. 5. Rodar o OPC e inicializar o iFIX (figura 5.4);

92

Figura 5.4: iFIX rodando.

6. No n iClientTS inicializar o iFIX (SUPMOV2) e execut-lo no modo run; 7. No Pocket PC, conectar-se rede wireless atravs do iPAQ Wireless e em seguida abrir o programa Cliente de Terminal; 8. No programa conectar-se ao IP 172.16.120.3 (iClientTS); 9. Autenticar usurio (mesmo login e senha usados em um acesso normal ao ligar o micro do iClientTS); 10. Inicializar o iFIX.

5.2.

TESTES

Os testes foram feitos no sistema com valores fictcios. Na figura 5.5 possvel ver uma tela do sistema real. No quadro 5.1 so apresentados os valores utilizados nos testes e discriminados por tag, dos 5 filtros. Em seguida sero descritos os procedimentos para cada teste, bem como os resultados obtidos.

93

Figura 5.5: Interface do SDCD real (online).

Quadro 5.1: Valores utilizados nos testes Filtro Tag Descrio 1 PT_05D_010 Transmissor de Presso do Filtro 1 1 LT_05D_010 Transmissor de Nvel do Filtro 1 1 FV_05D_010 Abertura (fluxo) da vlvula controladora do Filtro 1 1 FT_05D_010 Transmissor de Vazo do Filtro 1 2 PT_05D_020 Transmissor de Presso do Filtro 2 2 LT_05D_020 Transmissor de Nvel do Filtro 2 2 FV_05D_020 Abertura (fluxo) da vlvula controladora do Filtro 2 2 FT_05D_020 Transmissor de Vazo do Filtro 2 3 PT_05D_030 Transmissor de Presso do Filtro 3 3 LT_05D_030 Transmissor de Nvel do Filtro 3 3 FV_05D_030 Abertura (fluxo) da vlvula controladora do Filtro 3 3 FT_05D_030 Transmissor de Vazo do Filtro 3 4 PT_05D_040 Transmissor de Presso do Filtro 4 4 LT_05D_040 Transmissor de Nvel do Filtro 4 4 FV_05D_040 Abertura (fluxo) da vlvula controladora do Filtro 4 4 FT_05D_040 Transmissor de Vazo do Filtro 4 5 PT_05D_050 Transmissor de Presso do Filtro 5 5 LT_05D_050 Transmissor de Nvel do Filtro 5 5 FV_05D_050 Abertura (fluxo) da vlvula controladora do Filtro 5 5 FT_05D_050 Transmissor de Vazo do Filtro 5

Valor utilizado 2,65 kg/cm2 86,3% 100% 1326,8 m3/h 0,03 kg/cm2 0,0% 20% 0,0 m3/h 2,44 kg/cm2 88,2% 100% 1869,7 m3/h 0,25 kg/cm2 0,0% 20% 0,0 m3/h 2,93 kg/cm2 88,9% 100% 1900 m3/h

a) Primeiro Teste: Insero manual O procedimento para este teste foi simples: os valores que constam na tabela 5.1 foram sendo colocados manualmente no SDCD simulado do single node (figura ).

94

Como resultado pde-se perceber que quase instantaneamente os novos dados eram visualizados no n iClientTS e no sistema de superviso mvel, como pode ser visto nas figuras 5.7 (a),(b),(c),(d) e (e). H um destaque, com letras em azul, na figura (a), indicado qual o tag do campo. Os demais filtros seguem o mesmo padro. Comparando-se os valores dos tags da figura 5.5 e os valores do quadro 5.1 com os resultados mostrados na figura abaixo possvel perceber que nenhum dado chegou incorreto ao Pocket PC.

Figura 5.6: Modificando manualmente o valor de um tag, de 0.00 para 86.3.

LT_05D_010 PT_05D_010 FT_05D_010

FV_05D_010

(a)

(b)

95

(c)

(d)

(e)
Figura 5.7: Resultados dos testes com os filtros (a) 1; (b) 2; (c) 3; (d) 4; (e) 5.

b) Segundo Teste: Dados gerados automaticamente Aps o primeiro teste, realizado com sucesso, programou-se o SDCD simulado no single node para operar a vlvula controladora do Filtro 1 em automtico, ou seja, ela iria abrir ou fechar automaticamente, dependendo da

96

necessidade e conseqentemente os valores do tag FV_05D_010 seriam modificados rapidamente. Conforme a vlvula abria no SDCD simulado podiam-se ver alteraes no valor do tag, que crescia de 20 at parar em 100% (abertura total da vlvula). Em tempo real e automaticamente tambm se alteravam os valores no Pocket PC e no era possvel, visivelmente, perceber algum atraso na informao. Posteriormente, criou-se um algoritmo para que o valor do PT_05D_020 tambm se modificasse automaticamente, iniciando-se em 0.00 e variando, de 1.00 em 1.00 at atingir o limite de 6.00, valor mximo de presso suportado pelo filtro. A lgica desenvolvida foi bastante simples e pode ser vista na figura 5.8. O cdigo era executado repetidas vezes at que se parasse a execuo do programa (iniciar falso). O comportamento do sistema foi igual ao do teste automtico com a vlvula do Filtro 1: as atualizaes nos valores do tag eram mostradas em tempo real, no sendo possvel perceber algum tempo de atraso. Por esse motivo conclui-se que o resultado final desta avaliao foi muito satisfatrio.

Figura 5.8: Algoritmo desenvolvido para automatizar o valor do tag PT_05D_020, na linguagem do software e no pseudocdigo.

97

c) Terceiro Teste: Conectividade Durante a realizao dos dois testes anteriores foi observado tambm se havia queda de comunicao entre o n iClientTS e o SCADA e entre o Pocket PC e o iClientTS. O resultado da observao foi o seguinte: durante alguns instantes, enquanto visualizava-se o filtro 2, houve uma rpida perda de conexo entre os ns do iFIX. Porm a conexo foi rapidamente re-estabelecida sem necessidade de interveno. A comunicao wireless entre o Pocket PC e o iClientTS no apresentou problemas. De uma forma geral pode-se concluir que o desempenho do sistema, nos testes em laboratrio, foi muito bom trazendo os dados praticamente em tempo real e sem muitos problemas de comunicao, atravs de uma interface simples e sem distoro entre as informaes enviadas e recebidas.

5.3.

ANLISE ESTATSTICA DO OPC

Por fim realizou-se um levantamento estatstico, utilizando-se a ferramenta de estatstica do OPC Power Tool (Figura 4.14), no n SCADA, para mensurar os seguintes dados: Transmits (Transmitidos): Mostra o nmero de mensagens enviadas ao OPC Server a partir do item selecionado. Receives (Recebidos): Mostra o nmero total de mensagens recebidas do OPC Server, incluindo chamadas sncronas e assncronas. Errors (Erros): Mostra o nmero total de erros que foram enviados do OPC Server e recebidos pelo item selecionados. As principais causas de erros so: foi especificado um item ID invlido, foi feita uma requisio com um tipo de dado que o servidor no consegue manipular, a qualidade do OPC est ruim (bad), uma leitura ou escrita falharam. Os erros so identificados por cdigos. Intervalo: Intervalo de tempo, em minutos, que representa o tempo entre o momento em que comeou a comunicao entre o OPC Server e o OPC Client, indicado no campo Last Read Time, e o horrio em que foi feita a medio.

98

As medies foram realizadas a por trs vezes para validar os resultados, os quais podem ser vistos nas tabelas 5.1, 5.2 e 5.3. Cada tabela traz um grfico correspondente. A tabela 5.4 e seu respectivo grfico apresentam um resumo das informaes obtidas. Tabela 5.1: Resultados da primeira medio
TAG LT-05D-040 PT-05D-040 FV-05D-040 PT-05D-010 PT-05D-020 PT-05D-030 PT-05D-050 LT-05D-010 LT-05D-020 LT-05D-030 LT-05D-050 FT-05D-010 FT-05D-020 FT-05D-030 FT-05D-050 FV-05D-010 FV-05D-020 FV-05D-030 FV-05D-050 TOTAL MDIA TRANSMITIDO 38 38 38 38 38 38 38 38 38 39 39 39 39 39 39 39 39 39 39 732 38,53 RECEBIDO 41 38 38 38 41 40 40 40 38 41 41 41 39 40 41 40 39 40 40 756 39,79 ERROS 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 19 1 INTERVALO (minutos) 177 178 178 179 179 179 179 180 180 180 180 181 181 181 181 182 182 182 183 3422 180,11

Figura 5.9: Grfico com os resultados da primeira medio.

99

Tabela 5.2: Resultados da segunda medio

TAG LT-05D-040 PT-05D-040 FT-05D-040 FV-05D-040 PT-05D-010 PT-05D-020 PT-05D-030 PT-05D-050 LT-05D-010 LT-05D-020 LT-05D-030 LT-05D-050 FT-05D-010 FT-05D-020 FT-05D-030 FT-05D-050 FV-05D-010 FV-05D-020 FV-05D-030 FV-05D-050 TOTAL MDIA TRANSMITIDO 22 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 459 22,95 RECEBIDO 23 24 24 24 24 24 24 24 24 24 23 23 23 23 23 23 23 23 23 23 469 23,45 ERROS 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0,00 INTERVALO (minutos) 105 106 106 106 107 107 107 107 108 108 108 108 109 109 109 109 109 110 110 110 2158 107,90

Figura 5.10: Grfico com os resultados da segunda medio.

100

Tabela 5.3: Resultados da terceira medio

TAG LT-05D-040 PT-05D-040 FT-05D-040 FV-05D-040 PT-05D-010 PT-05D-020 PT-05D-030 PT-05D-050 LT-05D-010 LT-05D-020 LT-05D-030 LT-05D-050 FT-05D-010 FT-05D-020 FT-05D-030 FT-05D-050 FV-05D-010 FV-05D-020 FV-05D-030 FV-05D-050 TOTAL MDIA TRANSMITIDO 39 40 40 40 40 40 40 40 40 40 40 45 45 45 45 45 45 45 45 45 844 42,20 RECEBIDO 40 43 41 41 43 43 43 44 43 41 42 47 47 45 47 49 46 45 46 46 882 44,10 ERROS 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0,00 INTERVALO (minutos) 190 191 191 191 192 192 193 193 193 193 194 217 218 218 219 219 219 220 220 220 4083 204,15

Figura 5.11: Grfico com os resultados da terceira medio.

101

Tabela 5.4: Resumo dos dados levantados nas medies

ITEM Transmitidos Recebidos Total mensagens Erros Erros/Mensagem Erros/Mensagem (%) Intervalo Erros/Minuto Erros/Minuto (%) MDIA GERAL 34,49 35,71 70,20 0,32 0,004587 0,458716 163,78 0,001966 0,196626

Figura 5.12: Grfico com as mdias gerais obtidas nas trs medies.

Analisando-se os dados obtidos nas medies, apresentados nas tabelas e nos grficos anteriores, possvel perceber que normalmente o nmero de mensagens recebidas normalmente maior do que o de mensagens transmitidas isso se deve ao fato de o OPC Server enviar, logo no comeo da comunicao, mensagens de apresentao ao OPC Client. Pode-se perceber tambm que, em mdia, uma mensagem transmitida e outra recebida a cada 5 minutos. Isso ocorre por dois motivos: A comunicao foi configurada como assncrona e nesse tipo de comunicao o OPC Client no pode solicitar os dados ao OPC Server pois ele os envia ao cliente quando os dados so alterados e excedem o valor da deadband, a porcentagem mnima de variao que

102

eles podem sofrer. No entanto, assinalando-se a opo Enable Asynchronous Watchdog o OPC Client passa a ter permisso para solicitar dados ao servidor, garantindo que no haver perda de dados quando o servidor estiver muito ocupado, por exemplo. A freqncia com que essas requisies partem do cliente definida pela poll rate. Nesse caso, a poll rate estava definida para 5 minutos (figura 5.13). Conclui-se ento que durante as medies, mesmo quando os dados no estavam sofrendo alteraes, a troca de mensagens entre as interfaces OPC continuava.

Figura 5.13: OPC Power Tool, com destaque para dados estatsticos importantes.

Como a taxa de erros calculada foi muito pequena (menor do que 1% de erros por minuto e de erros por mensagem) possvel afirmar que o sistema bastante confivel. Durante os testes tambm no foram detectados erros na transmisso dos dados, o que confirma a afirmao. Ainda durante os testes foi observado que durante o teste com valores de presso variando automaticamente no filtro 2, descrito na seo 5.2 (c), a quantidade de dados recebidos para o tag em questo aumentou drasticamente, indicando o intenso trfego de mensagens do OPC Server em direo ao OPC Client, conforme mostra a figura 5.14. O intervalo mdio em que foram feitas as medies foi de 163,78 minutos ou aproximadamente 2 horas, 43 minutos e 46 segundos. Este tempo foi considerado satisfatrio para que se fizesse uma amostragem do sistema.

103

Figura 5.14: Diferena na estatstica do tag PT_05D_01, detectada durante os testes com o filtro 2.

5.4.

ANLISE ESTATSTICA DA REDE

Como o trabalho envolveu a instalao de duas redes, uma cabeada e outra sem fio, fez-se necessrio estabelecer parmetros para avaliar a qualidade do servio. Os mais comumente analisados so: atraso fim-a-fim, taxa de perda de pacotes, RTT, jitter e vazo. O retardo fim-a-fim (no ingls, one way delay) contabiliza o atraso total sofrido at atingir seu destino final na rede. Este parmetro de medida leva em conta o tempo que os pacotes esperam em filas, o tempo de propagao no meio fsico e o tempo gasto com processamento nos terminais da rede. A taxa de perda de pacotes a razo entre o nmero de pacotes recebidos e o nmero de pacotes enviados em um certo intervalo de tempo. O RTT round trip time, contabiliza o tempo que o pacote leva para ir do ponto A ao ponto Z e voltar origem (ponto A). Ele, juntamente com o retardo fim-afim indicam a latncia da rede.

104

O jitter ou variao do atraso do retardo fim-a-fim mostra as variaes no tempo de entrega de um pacote. um indicativo da demanda da rede. A vazo a banda da rede ocupada por uma aplicao. [71] No caso da rede desenvolvida para o sistema de superviso mvel os parmetros mais relevantes seriam o retardo fim-a-fim, o RTT e a taxa de perda de pacotes, j que a rede exclusiva para esta aplicao. No entanto, a medio do one way delay envolve o uso de ferramentas especficas de redes, de difcil manipulao, e por isso no foi possvel medi-lo. Quanto aos outros dois parmetros, a mensurao deles foi feita utiizando-se o software Ping Tester Professional 9.23, desenvolvido pela empresa Autobaup [72], que encontra-se disponvel na Internet para download. O Ping Tester Professional 9.23 (Figura 5.15) um programa que automatiza o uso e a configurao de um comando ping de rede, atravs do envio de pacotes testa se um computador, servidor, ou site em particular, est conectado rede e funcionando. O comando tambm oferece outras informaes, como quanto tempo a mquina leva para responder (RTT) e quantos pacotes foram perdidos no trfego (taxa de perda de pacotes). Um diferencial em relao ao ping convencional do Windows o relatrio que ele capaz de gerar ao final da anlise.

Figura 5.15: Interface do software Ping Tester Professional 9.23, com destaque para o resumo dos parmetros que ele capaz de avaliar.

105

Na avaliao, o Ping Tester foi instalado no single node e criou-se um grupo para que o programa desse o ping nos outros ns da rede, utilizando seus respectivos IPs, descritos na seo 4.4.1. Para validar os dados o teste foi realizado por quatro vezes e os resultados, mostrados a seguir, foram gerados pelos relatrios do programa e pelos indicativos de desempenho da tela principal, mostrados na figura 5.14.

Tabela 5.5: Resultados das anlises feitas pelo Ping Tester Professional
Parmetros Pacotes Enviados (Sent) Pacotes Recebidos (Received) Pacotes Perdidos (Lost) Taxa de perda de pacotes (Loss rate) Menor RTT (Min time) Maior RTT (Max time) Tempo Mdio (Avg time) Teste 1 1320 1295 25 1.89% 1 ms 43 ms 2 ms Teste 2 2212 2212 0 0.00% 1 ms 136 ms 3 ms Teste 3 2452 2452 0 0.00% 1 ms 54 ms 2 ms Teste 4 2236 2236 0 0.00% 1 ms 63 ms 5ms

Figura 5.16: Grfico de dados de pacotes.

106

Figura 5.17: Grfico da taxa de perda de pacotes.

Figura 5.18: Grfico do tempo mdio (RTT).

A descrio detalhada dos dados contidos na tabela e nos grficos anteriores feita atravs figuras a seguir, que so screenshots dos relatrios emitidos pelo programa.

107

Figura 5.19: Relatrio referente ao teste 1 do Ping Tester

Figura 5.20: Relatrio referente ao teste 2 do Ping Tester

108

Figura 5.21: Relatrio referente ao teste 3 do Ping Tester

Figura 5.22: Relatrio referente ao teste 4 do Ping Tester

109

A anlise dos dados obtidos nesse teste confirma o que j havia sido concludo observando-se os resultados dos testes descritos na seo anterior: o sistema funciona muito bem, com dados sendo transmitidos do single node ao Pocket PC em tempo real. Os trs tipos de testes realizados com o sistema e as anlises estatsticas foram o foco desse captulo. Mesmo sem fazer uma avaliao muito profunda possvel perceber que o desempenho do sistema foi muito bom. No entanto, h de se considerar que as situaes em que foram feitos os testes so ideais, ou seja, no refletem por completo a realidade j que: a base de dados utilizada pequena, a rede dedicada somente ao sistema, o Pocket PC e o AP estavam fisicamente bem prximos e o single node apenas uma simulao do sistema real, no qual tambm existem atrasos, o OPC Server nunca estava ocupado demais, j que somente um cliente o consultava. No sexto e ltimo captulo ser feita uma anlise geral do sistema e apresentadas as concluses e consideraes finais.

110

6 CONCLUSES E CONSIDERAES FINAIS

Apesar da notria evoluo acontecida nos ltimos anos nos sistemas de automao industrial, desenvolver um sistema de superviso mvel comunicando diferentes sistemas no uma tarefa simples, devido a pouca flexibilidade das tecnologias envolvidas. A viabilidade de um projeto desse tipo tambm um ponto relevante e que dificulta a criao de novas solues como esta, j que existem vrias alternativas prontas disponveis no mercado e que no requerem muitos esforos de configurao, como desprendido nesse trabalho. No entanto, avaliando-se os resultados obtidos nos testes em laboratrio e ponderando-se ainda as diferenas em termos de interferncia no sinal da rede wireless, pode-se afirmar que a implementao do sistema em campo perfeitamente vivel e ser de grande valia para os que o utilizarem. Quanto aos objetivos iniciais conclui-se que eles foram alcanados com sucesso, pois o funcionamento do sistema foi bastante satisfatrio disponibilizando as informaes corretas (sem perda ou modificao dos dados) e em tempo real ao usurio, em questo de milissegundos, conforme mostrado nos testes descritos no captulo 5. Um grande mrito deste trabalho est no fato de ter sido extremamente prtico e de ter aplicado padres e tecnologias modernas largamente utilizadas no meio industrial, como o OPC, por exemplo, na soluo de um importante problema em uma indstria de grande porte. O pleno domnio dessas tecnologias no fcil de ser alcanado. No entanto, toda a base de conhecimento necessria ao entendimento delas adquirida durante a graduao. Outro aspecto importante a transparncia no processo de desenvolvimento da soluo tanto para a empresa quanto para a equipe tcnica, o que diferencia e traz diferencial para este trabalho em relao s solues prontas vendidas no mercado. Como melhorias e trabalhos futuros destacam-se: (i) melhorar a interatividade das interfaces com o usurio adicionado vlvulas animadas, por exemplo; (ii) desenvolver um sistema de alarmes e eventos (requisito funcional) utilizando o servidor OPC de alarmes e eventos (OPC A &E) ou outras tecnologia; (iii) desenvolver mais interfaces com o usurio, para os demais equipamentos da rea

111

5D; (iv) implementar o sistema na rea da filtrao, efetivamente; (v) implementar as regras de segurana inicialmente idealizadas, trabalhando, entre outros, os pontos mencionados na seo 3.4.4; (vi) ampliar o projeto para as demais reas operacionais da empresa; (vii) ampliar a rede wireless para que os usurios possam ter acesso s informaes no apenas nas reas, mas tambm em outras dependncias da empresa, como no restaurante, por exemplo.

112

REFERNCIAS BIBLIOGRAFICAS [1] NEVES, Cleonor; DUARTE, Leonardo; VIANA, Nairon; LUCENA Jr, Vicente. Os dez maiores desafios da automao industrial: as perspectivas para o futuro. In: II Congresso de Pesquisa e Inovao da Rede Norte e Nordeste de Educao Tecnolgica. 2007, Joo Pessoa - PB. [2] Alunorte. Processo Bayer. Barcarena PA, 2004. 81 slides, color. [3] Alunorte. Empresa apresenta o processo. Disponvel em <http://www.alunorte.net>. Acesso em: 13 de maio de 2009. [4] Alunorte. ALUNORTE. Barcarena PA, 2006. No paginado. Folder. [5] Alunorte. ALUNORTE. Barcarena PA, 1993. No paginado. Folder. [6] Wikipedia. Balanced ScoreCard. Disponvel em <http://pt.wikipedia.org/wiki/Balanced_Scorecard>. Acesso em: 07 de maio de 2009. [7] ROCHA, Joseilton S. R.; SELIG, Paulo. Utlizando o Balanced ScoreCard para gerenciar pequenas e mdias empresas. [8] Sistema PI. Disponvel em <http://www.wateronline.com/product.mvc/The-PlantInformation-PI-System-0001>. Acesso em: 07 de maio de 2009. [9] ROLT, Carlos R. O planejamento e o controle da produo e o MES Manufacturing Execution System. Florianpolis, 1995. [10] Alunorte. Manual do Participante Filtrao de Licor Rico Mdulo 1. 3.ed. Barcarena, 2004. [11] Iconics. Genesis32. Disponvel em <http://www.iconics.com/Genesis32/ default.htm>. Acesso em: 27 de abril de 2009. [12] Honeywell. Intelatrac. Disponvel em <http://hpsweb.honeywell.com/NR/ Zrdonlyres/7C01A6F0-3976-496C-A15D- 9C16F39A41AD/0/IntelaTrac_ PKS.jpg>. Acesso em: 27 de abril de 2009. [13] SILVA, Marcelo. Curso de automao industrial. Piracicaba: 2006. 39p. [14] SENAI-SMAR.Apostila de Instrumentao.Curitiba: 2003.

113

[15] SILVA, Ana; SALVADOR, Marcelo. O que so sistemas supervisrios? 2005. 5p. Disponvel em <http://www.elipse.com.br/download/artigos/ rt025.04.pdf> Acesso em: 15 de abril de 2009. [16] SOUZA, Rodrigo. Uma arquitetura para sistemas supervisrios industriais e sua aplicao em processos de elevao artificial de petrleo. 2005. 71f. Dissertao (Mestrado em Engenharia Eltrica) UFRN, Natal. [17] What is a supervisory system? Disponvel em <http://www.techsolve.org/ ams_SupervisorySystems.php> Acesso em: 13 de abril de 2009. [18] PEROZZO, Reiner. Framework para construo de sistemas supervisrios em dispositivos mveis. 2007.108f. Dissertao (Mestrado em Engenharia Eltrica) UFRS, Porto Alegre. [19] IEEE Standard. Definition Specification and Analysis of Systems Used for Supervisory Control Data Acquisition and Automatic Control. ANSI, IEEE CR: Nova Iorque, 1986. 52p. [20] CASTRUCCI, Plnio; MORAES, Ccero. Engenharia de automao industrial. 2.ed. LTC, 2007. [21] Wikipedia. SCADA. Disponvel em <http://en.wikipedia.org/wiki/SCADA>. Acesso em: 18 de abril de 2009. [22] WOOLENBERG, Bruce. Power System Operation Control. In: GRIGBBY, L.L. The Electric Power Engineering Handbook. Minnesota: CRC Press LLC, 2001. [23] ACKERMAN, William; BLOCK, Wayne. Understanding Supervisory Systems. 1992. 4 p. [24] KRUTZ, Ronald. Securing SCADA Systems. Indianpolis: Wiley Publishing, 2005. 240p. [25] SMITH, H.; BLOCK, Wayne. RTUs Slave for Supervisory Systems. 1993. 6p. [26] BISHOP, Robert. The Mechatronics Handbook. Austin: CRC Press, 2002. 1229p. [27] IEEE. IEEE Standard for SCADA and Automation Systems: C37.1. New York, 2007. 146p.

114

[28] ARRIFANO, Natache. Desenvolvimento de um sistema de superviso e controle para uma planta industrial. 2000. Dissertao (Mestrado em Engenharia Eltrica) UFPA, Belm. [29] SOMMERVILLE, Ian. Engenharia de Software. 6.ed. So Paulo: Addison Wesley, 2003. [30] Artefato: Especificao de Requisitos de Software. Disponvel em <http://www.wthreex.com/rup/portugues/process/artifact/ ar_srs.htm>. Acesso em: 30 de maio de 2009. [31] Mdulo 2-Engenharia de Software. Disponvel em <http://sites.ffclrp.usp. br/ccp/(SEM%205)/ES1/M%C3%B3dulo2_Engenharia_de_Software_19571.doc> Acesso em: 30 de maio de 2009. [32] Usabilidade de software. 2007. 43 slides. Disponvel em <http://www.inf. ufrgs.br/~cabral/12.Usabilidade.Mai.2007.ppt> . Acesso em: 30 de maio de 2009. [33] GE FANUC. Electronic Books iFIX. Arquivos da Ajuda. CD-ROM. [34] Elutions. Wizcon. Disponvel em <http://www.elutions.com/products/ wizconsupervisor/index.cfm>. Acesso em: 23 de abril de 2009. [35] Elipse SCADA. Disponvel em <http://www.elipse.com.br/imagens/ produtos/ SCADA/scadawin1.png>. Acesso em 29 de abril de 2009. [36] Wikipedia. SDCD. Disponvel em <http://pt.wikipedia.org/wiki/Sistema_ digital_ de_controle_distribu%C3%ADdo>. Acesso em: 20 de abril de 2009. [37] BEMELMANS, Flvio. Sistema Digital de Controle Distribudo: robustez e alta disponibilidade. 5p. [38] GUEDES, Luiz Affonso. Redes para automao Industrial. Natal: 2005. 19 slides, color. [39] FACIT. Controladores Processo Contnuo. Montes Claros. 8 slides, color. Disponvel em <http://comunidade.femc.edu.br/~mauro/Informatica %20Industrial/ Apresentacoes/Controladores%20industriais_1.pdf>. Acesso em: 20 de abril de 2004. [40] BONGIORNO, Fabrizio; SANTANA, Mnica. SDCD X CLP: As diferenas que fazem a diferena. [41] A evoluo da automao. 21 slides, color.

115

[42] Redes Industriais, 14 slides, color. Disponvel em <http://giovanni.guarneri.googlepages.com/IntroducaoRedesIndustriais.pdf > Acesso em: 03 de maio de 2009. [43] TOVAR, Eduardo. Introduo Informtica Industrial: As normas do mercado das redes de comunicao industrial. 1996. 9p. [44] Foundation Fieldus. Disponvel em <http://www.fieldbus.org/index.php? option=com_content&task=view&id=23&Itemid=308 >. Acesso em: 04 de maio de 2009. [45] PACHECO, Nazareno. Redes Industriais de Comunicao. 41p. Disponvel em <http://www.joinville.udesc.br/portal/professores/nazareno/materiais/Redes _IndustriaisII.pdf >. Acesso em: 03 de maio de 2009. [46] SMAR. Fieldbus Tutorial. 29p. Disponvel em <http://www.smar.com/PDFs/ catalogues/FBTUTCE.pdf >. Acesso em: 03 de maio de 2009. [47] Ethernet. Disponvel em <http://informatica.hsw.uol.com.br/ethernet3.htm>. Acesso em: 29 de maio de 2009. [48] TCP/IP-Ethernet for beginners.1.ed.W&T.1999.58p. Disponvel em <http://www.wut.de/pdf/e-58www-11-prus-000.pdf >. Acesso em: 30 de maio de 2009. [49] Wikipedia. Transmission Control Protocol. Disponvel em <http://pt.wikipedia.org/ wiki/Transmission_Control_Protocol>. Acesso em: 30 de maio de 2009. [50] ABRAS, Gustavo; SANCHES,Jayme. Wireless LAN. Curitiba, 2002. 67p. [51] Wireless na indstria. Disponvel em <http://www.editoravalete.com.br/ site_controleinstrumentacao/arquivo/ed_144/cv1.html>. Acesso em: 30 de maio de 2009. [52] Process Automation Technologies. Disponvel em <http://www. controlglobal.com/articles/2007/028.html>. Acesso em: 02 de junho de 2009. [53] ROSS, John. O livro de Wi-Fi. Rio de Janeiro: Alta Books, 2003. [54] Wikipedia. Mobile Device. Disponvel em <http://en.wikipedia.org/wiki/ Mobile_device>. Acesso em: 27 de maio de 2009.

116

[55] BALL, Derek; SHILMOVER, Barry. How to do everything with your iPAQ Pocket PC. McGraw-Hill, 2002. 409p. [56] TI SAFE. Segurana em redes de automao. 2008. 27 slides, color. Disponvel em <http://www.tisafe.com/ppt>. Acesso em: 21 de maio de 2009. [57] Windows 2003 Server. Disponvel em <http://www.microsoft.com/brasil/ servidores/windowsserver2003/ howtobuy/licensing/ts2003.mspx>. Acesso em: 23 de maio de 2009. [58] Wikipedia. Terminal Services. Disponvel em <http://en.wikipedia.org/wiki/ Terminal_Services>. Acesso em: 23 de maio de 2009. [59] PUDA, Adriano. Padronizao da comunicao atravs da tecnologia OPC. [60] FONSECA, Marcos. Comunicao OPC Uma abordagem prtica. Vitria, 2002. 12p. [61] MATTILA, Marko. OPC XML. [62] OPC TASK FORCE.OPC Overview 1.0. Austin, 1998. Disponvel em <http://www.opcfoundation.org/DownloadFile.aspx/General/OPC%20Overview%201. 00.pdf?RI=1>. Acesso em: 03 de abril de 2009. [63] IWANITZ, Frank. OPC: Fundamentals, Implementation & Application. Huthig Pub. 2002. 220p. [64] OPC Foundation. Disponvel em <http://www.opcfoundation.org>. Acesso em: 03 de abril de 2009. [65] LOPES, Alexandre. Treinamento FIX32. Belford Roxo: 2005, 32p. [66] D-LINK. Manual D-Link Air Premier AG DWL-7100 AP. 52p. Disponvel em <http://download.modem-help.co.uk/mfcs-D/D-Link/DWL-7100AP-AirPremier-11agWLAN-Access-Point/Manuals/>. Acesso em: 24 de maio de 2009. [67] Switch. Disponvel em <http://www.infowester.com/hubswitchrouter.php> Acesso em: 25 de maio de 2009. [68] TIBOLA, Leandro. Gerao de Sistemas Supervisrios a Partir de Modelos Orientados a Objetos de Aplicaes Industriais. Disponvel em <http://www.inf.ufrgs.br/pos/SemanaAcademica/Semana99/tibola/tibola.html>. Acesso em: 27 de maio de 2009.

117

[69] BEZERRA, Eduardo. Princpio de anlise e projeto de sistemas com UML. Editora Campus/Elsevier. 374p. [70] HEWLETT PACKARD. Users Guide: HP iPAQ Pocket PC h4000 series. 1.ed.2003. Disponvel em <http://www.manualnguide.com/download/manualguide/hp-ipaq-pocket-pc-h4000-series-users-guide.html>. Acesso em: 24 de fevereiro de 2009. [71] SOUZA, Ricardo. QoS sobre redes de pacotes utilizando H.323. Rio de Janeiro, 2004. 17p. [72] Autobaup. Disponvel em <http://www.autobaup.com>. Acesso em: 04 de junho de 2009.

118

ANEXO 1

Questes da entrevista aplicada nas reas operacionais da Alunorte 1. Voc tem acesso s informaes do PI na rea? Sim ou No?

Se sim, com que freqncia voc faz uso dessas informaes? Sempre, ocasionalmente, raramente ou nunca? 2. Voc faz solicitaes de informaes sala de controle? Sim ou No? a. b. Com que freqncia? Sempre, ocasionalmente ou raramente? Como feita a comunicao? Via rdio, por celular, por ramal/fixo, Se SIM, responda:

pessoalmente, alta-voz ou outro(s)? Se outro(s), diga qual(is). c. Essa comunicao totalmente eficaz? Sim ou No? Se no, por qu? d. A demora na obteno dessas informaes afeta o bom funcionamento de sua rea? Sim ou No? 3. 4. Quais as informaes mais comumente solicitadas? Descreva-as. As informaes de que voc dispe hoje (indicadores dos instrumentos no

campo e dados da sala de controle) so suficientes para trabalhar satisfatoriamente? Sim ou No? Se NO, de quais informaes adicionais voc precisa? Descreva. 5. Existe alguma informao no campo que seja difcil obter? Exemplo: Precisar subir em algum tanque para ler informaes nos indicadores de um determinado instrumento. Sim ou No? Se SIM, descreva quais so. 6. Voc considera sua rea perigosa? Sim ou No? Se SIM, identifique os principais riscos. 7. As aes tomadas na sua rea impactam diretamente em outras etapas do Se SIM, descreva quais so. 8. Voc considera que as atividades de sua rea apresentam risco ambiental? Se SIM, identifique os principais riscos. 9. Voc gosta de novas tecnologias? Sim ou No? Sim ou No? processo? Sim ou No?

119

10.

Se voc j utilizou algum(ns) dispositivo(s) porttil(eis) da lista abaixo marque-

o(s). Se no utilizou marque NENHUM. ( ) Palmtop ( ) Pocket PC ( ) SmartPhone ( ) Notebook ( ) NENHUM ( ) Outro(s). Qual(is)? 11. Se voc tivesse um dispositivo porttil que lhe mostrasse informaes do Se voc respondeu SIM na pergunta anterior, responda: Quais facilidades lhe seriam proporcionadas pelo uso deste tipo de dispositivo? Coloque no mnimo 3. processo, seria til para voc? Sim ou No? Se NO, responda porqu.

120

ANEXO 2 CONFIGURAO DO MICROCOMPUTADOR DO N SERVIDOR SCADA Processador: Intel Pentium 4 3.20 GHz Memria: 1.50 GB Sistema Operacional: Microsoft Windows Server 2003 Enterprise Edition. CONFIGURAO DO MICROCOMPUTADOR DO N iCLIENTTS (VIEW) Processador: Intel Pentium 4 2.2 GHz Memria: 512 MB Sistema Operacional: Microsoft Windows Server 2003 Standard Edition.

Especificaes Tcnicas do Pocket PC HP iPAQ 4100 Series Caracterstica Descrio Sistema Operacional Windows Mobile 2003 (Windows CE 2003) Processador Intel XScale PXA255 400 MHz Memria 64MB SDRAM Display 3.8 polegadas Nmero de cores 65.536 cores Resoluo do Display 240 x 320 Dimenses 113.6mm (P) x 70.6mm (L) x 13.5mm (A) aproximadas Peso 132 g Bateria Removvel, recarregvel, de Lithium-Ion (1000 mAh) Expanso Suporta cartes de memria SD. Opes de USB integrado, serial RS-232 sincronizao Comunicao IrDA, Bluetooth, wireless WLAN 801.11b Temperatura Operao 0 a 400 C Umidade Operao 10% a 90% Fonte: [70] Especificaes Tcnicas do Ponto de Acesso D-Link DWL 7100AP Especificao Padro Segurana Descrio IEEE 802.11a/b/g 64-,128, 152-bit WEP WPA - Wi-Fi Protected Access (WPA TKIP/AES PSK) 802.1x (EAP-MD5/TLS/TTLS/PEAP) Suporta Advanced Encryption Standard (AES)

121

2.4 a 2.462GHz 5.15GHz a 5.35GHz OFDM(Orthogonal Frequency Division Multiplexing), PBCC, CCK (Complementary Code Keying) Para 802.11a: 54Mbps: -71dBm 11Mbps: -88dBm Para 802.11b: Sensibilidade durante a 11Mbps: -83dBm recepo 2Mbps: -89dBm 1Mbps: -92dBm Para 802.11g: 54Mbps: -72dBm 2Mbps: -91dBm Potncia de 15dBm (32mW) 2dB Transmisso Alcance do sinal Tipo de Antena Entrada Alimentao Interno: at 100m Externo: at 400m Dipolo (ohmini Direcional). 100 a 240 VAC, 50/60Hz fonte de alimentao universal. Operao at 95%. Fonte: [66]

Frequncia de Operao Tecnologia de Modulao

Temperatura Ambiente Operao 0 a 55C. Umidade