19 Sistemas Supervisórios PDF

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
U NIVERSIDADE F EDERAL DO R IO G RANDE DO N ORTE C ENTRO DE T ECNOLOGIA P ROGRAMA DE P S -G RADUAO EM E NGENHARIA E LTRICA
Uma Arquitetura para Sistemas Supervisrios Industriais e sua Aplicao em Processos de Elevao Articial de Petrleo
Rodrigo Barbosa de Souza
Orientador: Prof. Dr. Adelardo Adelino Dantas de Medeiros
Dissertao de Mestrado apresentada ao Programa de Ps-Graduao em Engenharia Eltrica da UFRN (rea de concentrao: Engenharia de Computao) como parte dos requisitos para obteno do ttulo de Mestre em Cincias.
Natal, RN, fevereiro de 2005
Diviso de Servios Tcnicos Catalogao da publicao na fonte. UFRN / Biblioteca Central Zila Mamede Souza, Rodrigo Barbosa de. Uma Arquitetura para Sistemas Supervisrios Industriais e sua Aplicao em Processos de Elevao Articial de Petrleo / Rodrigo Barbosa de Souza - Natal, RN, 2005 53 p. Orientador: Adelardo Adelino Dantas de Medeiros Dissertao (Mestrado) - Universidade Federal do Rio Grande do Norte. Centro de Tecnologia. Programa de Ps-Graduao em Engenharia Eltrica. 1. Automao Industrial - Dissertao. 2. Sistema Supervisrio - Dissertao. 3. SCADA - Dissertao. 4. Redes de Petri - Dissertao. I. Medeiros, Adelardo Adelino Dantas de. II. Ttulo. RN/UF/BCZM CDU 681.5
Uma Arquitetura para Sistemas Supervisrios Industriais e sua Aplicao em Processos de Elevao Articial de Petrleo
Rodrigo Barbosa de Souza
Dissertao de Mestrado aprovada em 4 de fevereiro de 2005 pela banca examinadora composta pelos seguintes membros:
Prof. Dr. Adelardo Adelino Dantas de Medeiros (orientador) . . . . DCA/UFRN
Profa . Dra . Silvia S. da Costa Botelho . . . . . . . . . . . . . . . . . . . . . . . . . DFIS/FURG
Prof. Dr. Luiz Affonso H Guedes de Oliveira . . . . . . . . . . . . . . . . . . . DCA/UFRN
Mr. Edson Henrique Bolonhini . . . . . . . . . . . . . . . . . . . . . . . . UN-RNCE/Petrobras
minha me, Giselda, pelo esforo, incentivo e dedicao durante toda a minha caminhada acadmica.
Agradecimentos
Ao meu orientador, professor Adelardo, sou grato pelo inestimvel conhecimento transmitido. Ao professor Maitelli pelo incentivo durante a elaborao deste trabalho. minha esposa Gleyce pela compreenso nos momentos de ausncia. Petrobras, pela contribuio prtica e o apoio nanceiro.
Sumrio
Sumrio Lista de Figuras Lista de Tabelas 1 Introduo 1.1 Automao de Processos Industriais . . . . . . . . . 1.1.1 Processos Fsicos . . . . . . . . . . . . . . . 1.1.2 Sensores e Atuadores . . . . . . . . . . . . . 1.1.3 Controladores Lgicos Programveis - CLPs 1.1.4 Rede de Comunicao . . . . . . . . . . . . 1.1.5 Superviso . . . . . . . . . . . . . . . . . . 1.1.6 Gerncia de Informaes . . . . . . . . . . . 1.2 Sistemas Supervisrios . . . . . . . . . . . . . . . . 1.2.1 Aquisio de Dados . . . . . . . . . . . . . 1.2.2 Acesso aos Dados . . . . . . . . . . . . . . 1.2.3 Alarmes e Eventos . . . . . . . . . . . . . . 1.2.4 Tolerncia a Falhas . . . . . . . . . . . . . . 1.2.5 Estrutura Funcional . . . . . . . . . . . . . . 1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . 1.4 Estrutura do Documento . . . . . . . . . . . . . . . 2 A Indstria do Petrleo 2.1 Prospeco de Petrleo . . . . . . . . . . . . . . . . 2.2 Perfurao de Poos . . . . . . . . . . . . . . . . . . 2.2.1 Revestimento de um Poo de Petrleo . . . . 2.2.2 Cimentao . . . . . . . . . . . . . . . . . . 2.3 Avaliao de Formaes . . . . . . . . . . . . . . . 2.4 Completao de Poos . . . . . . . . . . . . . . . . 2.5 Elevao de Petrleo . . . . . . . . . . . . . . . . . 2.5.1 Gas-Lift . . . . . . . . . . . . . . . . . . . . 2.5.2 Bombeio Centrfugo Submerso (BCS) . . . . 2.5.3 Bombeio Mecnico com Hastes (BM) . . . . 2.5.4 Bombeio por Cavidades Progressivas (BCP) . i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i iii v 1 2 2 3 4 4 4 5 5 6 6 6 7 7 7 8 11 11 11 12 13 14 14 14 15 16 16 17
3 Arquitetura do Sistema 3.1 Rede de Campo . . . . . . . . . . . . . . . . . 3.2 Rede de Superviso Local . . . . . . . . . . . 3.3 Protocolo de Comunicao Inter-redes . . . . . 3.3.1 Funcionamento do PCI . . . . . . . . . 3.3.2 Interface de Comunicao . . . . . . . 3.3.3 Identicao das Requisies . . . . . 3.3.4 Funes PCI . . . . . . . . . . . . . . 3.3.5 Acesso s Estaes da Rede de Campo 3.3.6 Utilizao do campo de Dados . . . . . 3.3.7 Cdigos de Erro . . . . . . . . . . . . 3.4 O Software de Superviso . . . . . . . . . . . . 3.4.1 Funcionamento dos Clientes . . . . . . 3.4.2 Funcionamento do Servidor . . . . . . 4 Implementao e Resultados 4.1 Processo Fsico . . . . . . . . 4.2 Hardware de Controle . . . . 4.3 Rede de Comunicao . . . . 4.4 Software de Superviso . . . . 4.4.1 Projeto . . . . . . . . 4.4.2 Implementao . . . . 4.5 Resultados . . . . . . . . . . . 4.5.1 Caso de Uso . . . . . 4.5.2 Anlise de Resultados 5 Concluses Referncias bibliogrcas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
19 19 20 20 21 22 23 23 24 25 25 25 25 28 39 39 39 40 40 40 43 44 45 46 49 51
Lista de Figuras
1.1 1.2 1.3 2.1 2.2 2.3 2.4 2.5 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 4.1 4.2 4.3 4.4 4.5 4.6 Automao Industrial em Nveis de Abstrao . . . . . . . . . . . . . . . Automao Industrial - Topologia . . . . . . . . . . . . . . . . . . . . . Estrutura Fsica de um Sistema Supervisrio . . . . . . . . . . . . . . . Sonda Utilizada na Perfurao de Poos de Petrleo Revestimento dos Poos de Petrleo . . . . . . . . Sistema de Bombeio Mecnico . . . . . . . . . . . Carta Dinamomtrica . . . . . . . . . . . . . . . . Elevao articial com BCP . . . . . . . . . . . . Fluxo de Dados: Requisies Externas Fluxo de Dados: Requisies Internas Quadro de Requisies PCI . . . . . . Quadro de Respostas PCI . . . . . . . Processo Transmissor . . . . . . . . . Processo Receptor . . . . . . . . . . . Processo de Vericao . . . . . . . . Processo Leitor . . . . . . . . . . . . Processo Local . . . . . . . . . . . . Transio No Habilitada . . . . . . . Transio Habilitada . . . . . . . . . Processo Remoto . . . . . . . . . . . Processo Escritor . . . . . . . . . . . Processo Interno . . . . . . . . . . . . Rede de Comunicao . . Interao entre os Mdulos Login do Usurio . . . . . Gerenciamento dos Poos . Interveno em um Poo . Histrico do Poo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 8 12 13 17 18 18 21 22 22 23 27 29 30 32 33 34 34 35 36 37 41 42 43 44 45 46
iii
Lista de Tabelas
3.1 3.2 3.3 3.4 4.1 Requisies e Respostas Funes de Controle . . Cdigos de Erro . . . . . Estados das Requisies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 24 25 26 46
Tempo de Resposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resumo
A utilizao de sistemas de superviso tem se tornado cada vez mais essencial ao acesso, gerenciamento e obteno de dados dos processos industriais, devido ao constante e frequente desenvolvimento da automao industrial. Estes sistemas supervisrios (SCADA) tm sido amplamente utilizados em diversos ambientes industriais para armazenar dados do processo e control-lo de acordo com alguma estratgia adotada. O hardware de controle de um sistema SCADA o conjunto de equipamentos responsveis pela execuo desta tarefa. O software de superviso SCADA acessa os dados dos processos atravs do hardware de controle e torna-os disponveis para os usurios. Atualmente, muitos sistemas de automao industrial utilizam softwares de superviso desenvolvidos pelo mesmo fabricante do hardware de controle. Normalmente, estes softwares no podem ser usados com equipamentos de controle de outros fabricantes. Este trabalho prope uma metodologia de desenvolvimento de sistemas de superviso capaz de acessar informaes dos processos atravs de diferentes equipamentos de controle. Inicialmente, deni-se uma arquitetura para sistemas supervisrios que garanta comunicao e troca de dados ecientes. Em seguida, a arquitetura aplicada em um sistema de superviso de poos de petrleo que utilizam diferentes equipamentos de controle. A implementao foi modelada utilizando o mtodo formal de redes de Petri. Os resultados so apresentados para demonstrar a aplicabilidade da soluo proposta. Palavras-chave: Sistema supervisrio, SCADA, automao industrial, redes de Petri, elevao articial de petrleo.
vii
Abstract
The using of supervision systems has become more and more essential in accessing, managing and obtaining data of industrial processes, because of constant and frequent developments in industrial automation. These supervisory systems (SCADA) have been widely used in many industrial environments to store process data and to control the processes in accordance with some adopted strategy. The SCADAs control hardware is the set of equipments that execute this work. The SCADAs supervision software accesses process data through the control hardware and shows them to the users. Currently, many industrial systems adopt supervision softwares developed by the same manufacturer of the control hardware. Usually, these softwares cannot be used with other equipments made by distinct manufacturers. This work proposes an approach for developing supervisory systems able to access process information through different control hardwares. An architecture for supervisory systems is rst dened, in order to guarantee efciency in communication and data exchange. Then, the architecture is applied in a supervisory system to monitor oil wells that use distinct control hardwares. The implementation was modeled and veried by using the formal method of the Petri networks. Finally, experimental results are presented to demonstrate the applicability of the proposed solution. Keywords: Supervisory systems, SCADA, industrial automation, Petri networks, oil articial lift.
ix
Captulo 1 Introduo
A automao industrial tem crescido continuamente devido necessidade de substituir os antigos mtodos de controle manual pelos ecientes mtodos de controle automatizados [Mai03]. Neste contexto, a utilizao de um hardware de controle possibilita o armazenamento de dados do processo e, associada a tcnicas de controle atuando sobre ele, d um maior grau de conabilidade ao seu funcionamento. Todavia, sempre que preciso acessar esses dados necessrio um contato direto com o hardware de controle, o que pode se tornar um trabalho custoso quando os equipamentos operam em locais distantes ou de difcil acesso. Assim, surge a necessidade de tornar os dados disponveis remotamente. Os sistemas supervisrios suprem essa necessidade, pois permitem coletar dados do processo, alm de monitor-lo e atuar sobre ele com algum controle em nvel de superviso [LY02]. Para executar essas tarefas o sistema supervisrio deve utilizar algum sistema computacional, ou software de superviso, que seja capaz de se comunicar com o processo indiretamente atravs do hardware de controle. Quando estes dois elementos que precisam se comunicar utilizam algum protocolo de comunicao privado, normalmente de propriedade do fabricante do hardware de controle, gerada uma relao de dependncia do software em relao ao hardware, comprometendo o sistema supervisrio no sentido de que ele s ser capaz de supervisionar processos automatizados que utilizam um nico tipo de equipamento de controle [SQ00]. Sistemas de superviso de processos de extrao de petrleo em poos automatizados representam um caso tpico do problema de software dependente. Neste tipo de processo o mtodo utilizado para elevar o uido do reservatrio natural subterrneo pode variar de acordo com a localizao do poo, o custo operacional e o equipamento disponvel, alm de outros fatores [Tho01]. Assim, como geralmente so utilizados equipamentos de controle distintos para diferentes mtodos de elevao, cada fabricante elabora um projeto de sistema de superviso diferente, acarretando um gasto excessivo da empresa com softwares de superviso. importante ressaltar que um mesmo mtodo de elevao de petrleo tambm pode utilizar equipamentos de controle de diferentes fabricantes, o que agrava ainda mais o problema. Neste contexto, as prximas sees abordaro os aspectos gerais da automao de processos industriais e dos sistemas de superviso e as principais caractersticas do
2 processo de extrao em poos de petrleo.
CAPTULO 1. INTRODUO
1.1 Automao de Processos Industriais

A tecnologia que utiliza sistemas mecnicos, eletromecnicos e computacionais para operar no controle de processos pode ser denida, no contexto industrial, como automao [Mai03]. Os principais motivos que levam as empresas a automatizarem os seus processos so:
reduo de custos de pessoal devido substituio por mquinas; aumento da qualidade dos produtos devido preciso das mquinas; reduo de produtos em estoque devido ao aumento da produtividade; reduo de perdas de produtos; e diminuio no tempo de fabricao.
Os processos automatizados utilizam tcnicas que permitem, atravs do uso de controladores e algoritmos de controle, armazenar suas informaes, calcular o valor desejado para as informaes armazenadas e, se necessrio, tomar alguma ao corretiva. Este tipo de comportamento representa o funcionamento de um sistema realimentado ou em malha fechada. A montagem de automveis atravs de robs um dos exemplos mais comuns de processos automatizados na indstria atualmente. Uma representao da automao industrial em nveis de abstrao pode ser observada na gura 1.1 [dO03]. A estrutura topolgica que representa a distribuio dos principais elementos envolvidos na automao de um processo industrial pode ser observada na gura 1.2. Nvel de Gerncia Nvel de Superviso Nvel de Rede de Comunicao Nvel de Controle Nvel de Sensores e Atuadores Nvel de Processos Fsicos Figura 1.1: Automao Industrial em Nveis de Abstrao
1.1.1 Processos Fsicos

Os processos fsicos representam o objeto da automao, sendo supervisionados e monitorados, fornecendo informaes que so utilizadas tanto no controle dos processos
1.1. AUTOMAO DE PROCESSOS INDUSTRIAIS

Gerncia de Informaes Supervisor
Rede de Comunicao de Dados
Controlador 1
Controlador N
Sensores
Atuadores
Sensores
Atuadores
Processo Fsico 1
Processo Fsico N
Figura 1.2: Automao Industrial - Topologia quanto na gerncia dos dados [BJP99]. A elevao de uido em poos de petrleo um exemplo de processo fsico. Este processo, quando automatizado, permite um alto nvel de controle sobre a quantidade de uido sendo extrado do reservatrio.
1.1.2 Sensores e Atuadores

Os sensores podem ser analogamente comparados aos olhos, pois capturam as informaes relativas ao estado do processo fsico industrial e as transmitem ao controlador do processo, assim como os olhos capturam as imagens e as transmitem ao crebro. Os instrumentos de medio utilizados na indstria tm os sensores como elemento primrio e podem ser classicados, de acordo com o tipo de sinal transmitido, como digitais ou analgicos [Wer96]. Uma outra classicao, de acordo a aplicao, divide os sensores em detectores e medidores. Detectores: so capazes de capturar e sinalizar informaes representado-as somente nos estados ON/OFF. Os detectores de m 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.
CAPTULO 1. INTRODUO
Os atuadores podem ser comparados s mos, pois eles executam sobre o processo as tarefas ordenadas pelo controlador, assim como as mos executam as tarefas ordenadas pelo crebro. Incluem-se no grupo dos atuadores os rels auxiliares, os contatores e conversores eletrnicos e os variadores de velocidade/frequncia. Na gura 1.2 possvel observar a relao dos sensores e atuadores com um processo automatizado e seu controlador.
1.1.3 Controladores Lgicos Programveis - CLPs

Um CLP um aparelho digital que usa memria programvel para armazenar instrues que implementam funes lgicas como: sequenciamento, temporizao, contagem e operaes aritmticas, para controlar diversos tipos de mquinas e processos [Mai03]. A forma bsica de sua programao oriunda da lgica de programao dos diagramas eltricos a rels. O seu funcionamento se d atravs de uma rotina cclica de operao operando somente com variveis digitais, o que o caracteriza como um controlador discreto. Quando este tipo de equipamento manipula variveis analgicas ele chamado de Controlador Programvel (CP). As principais vantagens apresentadas pelo CLP so:
interfaces de operao e programao facilitadas ao usurio; instrues de aritmtica e manipulao de dados poderosas; recursos de comunicao em redes de CLPs; conabilidade; exibilidade; e velocidade.
1.1.4 Rede de Comunicao

Uma das grandes vantagens na automao de processo industriais est na possibilidade de utilizar controladores e dispositivos digitais com capacidade de processamento autnomo de uma forma geral juntamente com os PCs (Computadores Pessoais) [CV02]. Assim, possvel conseguir uma intercomunicabilidade entre todos os elementos da estrutura da automao atravs de um meio fsico adequado denido para a transmisso de dados, criando um sistema de comunicao em rede em que os elementos podem trocar dados e compartilhar recursos entre si [Tai98]. Ao estabelecer a integrao dos dados digitalmente por meio de uma rede de comunicao entre os mais diferentes nveis hierrquicos dentro de uma indstria, reduz-se o custo de fabricao, pela ecincia da manipulao do produto, aumenta-se a produtividade e se estabelece um novo conceito em automao industrial: a integrabilidade de seus componentes nos mais diferentes nveis.
1.1.5 Superviso
Os sistemas de superviso devem ser capazes de processar as informaes do processo e torn-las disponveis para o operador do processo ou qualquer outro usurio do software supervisrio [PJ03]. Podem tambm realizar atividades de controle em nvel de superviso e, automaticamente, com o auxlio de algum mecanismo especco aplicado
1.2. SISTEMAS SUPERVISRIOS
ao sistema computacional, tomar decises e executar aes sobre o processo [OK02]. A estrutura geral dos sistemas supervisrios e outras atividades que lhes so peculiares sero comentadas na seo 1.2.
1.1.6 Gerncia de Informaes

O nvel de gerncia representado na gura 1.1 responsvel pela manipulao e manuteno de uma base de dados com as informaes sobre a coordenao, o planejamento e as vendas de uma empresa. Acrescentar as informaes do processo a essa base de dados, a partir de dados coletados por meio de dispositivos sensores e processados por um sistema de superviso, implica beneciar todas as tarefas do nvel de gerenciamento, melhorando a coordenao, a programao e o controle da produo, planejando o processo de fabricao como um todo e estabelecendo uma nova gesto de gerenciamento dos negcios [ZJ99].
1.2 Sistemas Supervisrios

Os sistemas de superviso de processos industriais so tambm conhecidos como sistemas SCADA (Supervisory Control And Data Acquisition) [MCdlR01]. Os primeiros sistemas SCADA, basicamente telemtricos, permitiam informar periodicamente o estado corrente do processo industrial monitorando apenas sinais representativos de medidas e estados de dispositivos atravs de um painel de lmpadas e indicadores, sem que houvesse qualquer interface de aplicao com o operador. Com a evoluo da tecnologia, os computadores passaram a ter um papel importante na superviso dos sistemas, coletando e tornando disponveis os dados do processo. O acesso remoto aos dados facilita tanto o monitoramento quanto o controle do processo, fornecendo, em tempo til, o estado atual do sistema atravs de grcos, previses ou relatrios, viabilizando tomadas de decises, seja automaticamente ou por iniciativa do operador [EHH 00]. Os sistemas supervisrios tm se mostrado de fundamental importncia na estrutura de gesto das empresas, fato pelo qual deixaram de ser vistos como meras ferramentas operacionais, ou de engenharia, e passaram a ser vistos como uma relevante fonte de informao. Os sistemas de superviso de processos industriais automatizados desempenham trs atividades bsicas [UNS00]:

superviso; operao; e controle.
Na superviso, incluem-se todas as funes de monitoramento do processo tais como grcos de tendncias de variveis analgicas ou digitais, relatrios em vdeo e impressora, dentre outras [Cam88]. A operao nos atuais sistemas SCADA tem a grande vantagem de substituir as funes da mesa de controle, otimizando os procedimentos de ligar e desligar equipamentos ou sequncias de equipamentos, ou ainda mudar o modo de operao dos equipamentos de controle. No controle supervisrio os algoritmos de controle
CAPTULO 1. INTRODUO
so executados numa unidade de processamento autnomo (CLP). Assim, o sistema de superviso responsvel somente por ajustar os set-points do mecanismo de controle dinamicamente, de acordo com o comportamento global do processo. Um sistema de superviso caracteriza-se por [MMP97]:
fazer a aquisio de dados do processo; tornar os dados disponveis visualmente; processar eventos e ativar alarmes; e ser tolerante a falhas.
Essas caractersticas, detalhadas a seguir, garantem a execuo das trs atividades bsicas de um sistema SCADA.
1.2.1 Aquisio de Dados

A aquisio de dados um procedimento que envolve a coleta e a transmisso de dados desde as instalaes das indstrias, eventualmente remotas, at as estaes centrais de monitoramento [KLN99]. O procedimento se inicia com a solicitao de dados do processo. Quando a requisio de informaes sobre o processo feita pelo controlador do processo, ocorre uma solicitao local. Se a solicitao feita por alguma estao da Rede Local de Superviso, ocorre uma solicitao remota. Na ocorrncia de uma solicitao, uma unidade de processamento autnomo, que pode ser um CLP ou uma RTU (Unidade de Transmisso Remota), l os dados do processo atravs de dispositivos sensores. Se a solicitao for local, os dados so utilizados no controle do processo pelo CLP. Caso contrrio, eles so transmitidos remotamente, atravs da Rede de Campo, at a estao central, que armazena as informaes em uma base de dados e as torna disponveis atravs da Rede Local de Superviso.
1.2.2 Acesso aos Dados

A visualizao de dados consiste na apresentao de informaes atravs de interfaces homem-mquina, geralmente utilizando animaes capazes de simular a evoluo dos estados do processo controlado na indstria [Gho96]. Os sistemas SCADA permitem visualizar os dados lidos na fase de aquisio, alm de fornecer previses e tendncias do processo produtivo com base nos valores dos dados e valores parametrizados pelo operador, exibindo grcos e relatrios relativos a dados atuais ou existentes em histrico.
1.2.3 Alarmes e Eventos

Visando garantir maior segurana no processo, um sistema de superviso capaz de gerar alarmes a partir da ocorrncia de algum evento especco [Qiz98]. Os alarmes so classicados por nveis de prioridade em funo da sua gravidade, sendo reservada a maior prioridade para os alarmes relacionados com questes de segurana. Atravs da informao proveniente do login de acesso ao sistema , os sistemas SCADA identicam e localizam os operadores, de modo a ltrar e encaminhar os alarmes em funo das
1.3. OBJETIVOS
suas reas de competncia. Os sistemas SCADA armazenam em arquivos as informaes relativas a todos os alarmes gerados, de modo a permitir que posteriormente proceda-se uma anlise mais detalhada das circunstncias que os originou.
1.2.4 Tolerncia a Falhas

Para atingir nveis aceitveis de tolerncia a falhas, usual a existncia de informao redundante na rede de comunicao e de mquinas utilizadas como sistema de recuperao (backup) situadas dentro e fora das instalaes das indstrias. Desta forma, permite-se que, sempre que se verique uma falha num equipamento, as operaes de sua responsabilidade sejam transferidas automaticamente para um substituto, de tal forma que no haja interrupes signicativas na superviso.
1.2.5 Estrutura Funcional

Um sistema de superviso em um ambiente industrial automatizado essencialmente composto por quatro elementos [DS99]: Processo Fsico: o elemento principal do sistema e representa o objeto da superviso; 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; e Rede de Comunicao: responsvel pelo trfego das informaes, constituindo-se, geralmente, de duas sub-redes denominadas rede de campo e rede local de superviso. A rede de campo responsvel pela aquisio dos dados do processo. Am de conseguir uma comunicao determinstica, as redes de campo, em sua maioria, utilizam uma arquitetura mestre/escravo. Neste tipo de rede, os controladores que desempenham a funo das estaes escravas jamais iniciam a comunicao, respondendo somente s solicitaes feitas pelo controlador mestre. Algumas das implementaes mais comuns de redes que utilizam esta arquitetura so as redes modbus [Mod03] e probus [PRO02]. A rede local de superviso [Tru95] responsvel por tornar disponveis e compartilhar os dados do processo em uma LAN (Rede de rea Local) [Tan97]. Neste caso, os sistemas de superviso, geralmente, utilizam arquiteturas do tipo cliente/servidor para acessar as informaes do processo disponveis na rede de campo, como observado por Giovanni Bucci [BL03] e Liu Zhi [ZQY 00]. A disposio fsica dos elementos de um sistema supervisrio pode ser observada na gura 1.3.
1.3 Objetivos
Almejando solucionar o problema de software de superviso dependente do hardware de controle, ser projetada uma arquitetura para sistemas supervisrios que elimine essa
8 Rede de Campo Processo 1 Processo 2
CAPTULO 1. INTRODUO
Processo 3
Escravo
Escravo Mestre
Escravo
Rede Local de Superviso Servidor

Cliente
Cliente
Cliente
Figura 1.3: Estrutura Fsica de um Sistema Supervisrio relao de dependncia. Am de garantir a aplicabilidade da arquitetura projetada como soluo, ser desenvolvida uma implementao prtica para um processo fsico industrial em que se verique a ocorrncia do problema. Para atingir tais objetivos, as seguintes tarefas foram realizadas:
elaborao de um interface de comunicao entre o software e o hardware de modo que para o usurio do software o acesso aos dados do processo seja transparente em relao ao hardware utilizado; desenvolvimento de um protocolo de comunicao que permita uma troca de dados rpida e eciente utilizando a interface de comunicao elaborada; proposio de um modelo de implementao para o protocolo desenvolvido; e implementao da arquitetura proposta em um processo de elevao articial de petrleo em poos automatizados com equipamentos de fabricantes distintos.
1.4 Estrutura do Documento

Este documento est organizado em quatro captulos. O presente captulo relata uma breve descrio do problema de software dependente em sistemas supervisrios e apre-
1.4. ESTRUTURA DO DOCUMENTO
senta uma viso introdutria dos aspectos relevantes para a obteno de uma soluo. O segundo captulo expe as principais caractersticas da indstria do petrleo, explorando as peculiaridades do processo fsico de elevao articial de petrleo. O terceiro captulo descreve a arquitetura para sistemas supervisrios utilizada como soluo para o problema apresentado, sugerindo um modelo de implementao para esta arquitetura. O quarto captulo trata da implementao do software de superviso e avalia sua utilizao. O ltimo captulo analisa as vantagens da soluo adotada e sua aplicabilidade a problemas similares.
10
CAPTULO 1. INTRODUO
Captulo 2 A Indstria do Petrleo

A crescente utilizao do petrleo como fonte de energia um dos fatores que mais tem contribudo para a evoluo tecnolgica industrial neste setor. Atualmente, com o advento da petroqumica, a utilizao dos derivados do petrleo tem se tornado cada vez mais comum. Alm disso, centenas de novos compostos utilizados diariamente passaram a ser produzidos, como plsticos, tintas, corantes, adesivos, solventes, detergentes, etc. Assim, o petrleo passou a ser indispensvel s comodidades da vida moderna, alm de ser utilizado como combustvel. At que seja possvel extrair o petrleo do subsolo preciso seguir vrias etapas que garantem a existncia de petrleo numa determinada regio e viabilizam fsica e economicamente a elevao do uido. Resumidamente, essas etapas consistem na prospeco do petrleo, perfurao dos poos, avaliao das formaes, completao dos poos e aplicao dos mtodos de elevao [Tho01].
2.1 Prospeco de Petrleo

A busca de novas jazidas de petrleo, chamada de programa de prospeco de petrleo, tem como objetivos fundamentais localizar dentro de uma bacia sedimentar as situaes geolgicas que tenham condies para a acumulao de petrleo e vericar qual, dentre essas situaes, apresenta maior possibilidade de conter petrleo. A existncia ou no de petrleo no pode ser prevista, porm possvel determinar regies onde a probabilidade de existir seja maior. As regies de provvel acmulo de petrleo so identicadas atravs de mtodos geolgicos e geofsicos. Assim, o programa de prospeco disponibiliza uma srie de informaes tcnicas que indicam a localizao mais propcia para a perfurao dos poos. importante ressaltar que os custos com a prospeco so relativamente pequenos se comparados com os custos de perfurao, o que torna o programa de prospeco indispensvel.
2.2 Perfurao de Poos

Com o auxlio das informaes obtidas na fase de prospeco, so escolhidas as localizaes dos poos que so perfurados utilizando-se um equipamento denominado sonda.
12
CAPTULO 2. A INDSTRIA DO PETRLEO
A gura 2.1 representa a ilustrao de uma sonda.
Figura 2.1: Sonda Utilizada na Perfurao de Poos de Petrleo No mtodo de perfurao atualmente utilizado na indstria, chamado de perfurao rotativa, as rochas so perfuradas pela ao da rotao e peso aplicados a uma broca posicionada na extremidade inferior de uma coluna de perfurao. Os fragmentos da rocha so removidos continuamente atravs de um uido de perfurao ou lama. Ao atingir determinada profundidade, a coluna de pefurao retirada do poo e uma coluna de revestimento de ao descida no poo com objetivo inicial de evitar o desmoronamento das paredes do poo. O espao entre os tubos de revestimento e as paredes do poo so cimentados am de isolar as rochas atravessadas e garantir maior segurana na perfurao. Aps a cimentao, a coluna de perfurao descida novamente, agora com uma broca de dimetro menor que a largura da coluna de revestimento, at determinada profundidade para a insero de uma nova coluna de revestimento, de dimetro menor que a anterior, procedendo-se a uma nova cimentao. Esse processo se repete at que seja alcanada a profundidade desejada para o poo. Assim, possvel perceber que o processo de perfurao se d em diversas fases, caracterizadas pelo dimetro das brocas de perfurao, que reduzido em cada uma delas.
2.2.1 Revestimento de um Poo de Petrleo

O nmero de fases no processo de perfurao de um poo de petrleo depende das caractersticas das zonas a serem perfuradas e da profundidade nal prevista. Esse nmero geralmente, trs ou quatro e, dependendo da situao pode chegar a oito [Tho01]. A concluso de uma fase se d com a descida de uma coluna de revestimento e sua cimentao. As principais funes das colunas de revestimento so:
prevenir o desmoronamento das paredes dos poos; evitar a contaminao da gua dos lenis freticos mais prximos a superfcie;
2.2. PERFURAO DE POOS

impedir a migrao de uidos das formaes; e sustentar outra coluna de revestimento.

13
A gura 2.2 ilustra os tipos de colunas de revestimento utilizadas em um poo perfurado em trs fases.
# " $ ! % $ # " $ ! % $
Tubo Condutor
$
#
"

$ ! %

!
Revestimento de Superfcie
! !

Revestimento de Produo

Coluna de Produo

Figura 2.2: Revestimento dos Poos de Petrleo
Tubo Condutor: tem o objetivo de sustentar os sedimentos superciais no consolidados. o primeiro revestimento do poo, assentado a uma pequena profundidade (10 m a 50 m); Revestimento de Superfcie: protege os horizontes superciais de gua e evita o desmoronamento de formaes no consolidadas. assentado em uma profundidade maior que a do tubo condutor; Revestimento de Produo: tem a nalidade de permitir a produo do poo suportando suas paredes; e Coluna de Produo: o tubo que viabiliza o uxo do petrleo at a superfcie.
2.2.2 Cimentao
Para xar a tubulao de revestimento e evitar a migrao de uidos entre as zonas permeveis por trs dessa tubulao, o espao anular entre a coluna de revestimento e as paredes do poo preenchido com cimento. O bombeio da pasta de cimento e gua neste espao anular responsvel pela cimentao do poo. A cimentao pode ser primria ou secundria. A cimentao primria, ou principal, feita logo aps a descida da coluna de revestimento no poo. Sua qualidade avaliada atravs de pers acsticos corridos no revestimento. Se, por qualquer motivo, a cimentao primria no atingir o seu
14
objetivo, pode-se efetuar uma recimentao, ou cimentao secundria, atravs de perfuraes realizadas no revestimento denominadas canhoneios. possvel ainda a utilizao da cimentao quando se decide abandonar um poo. Neste caso o cimento utilizado como um tampo.
2.3 Avaliao de Formaes

A avaliao das formaes representa o conjunto de atividades que visa denir quantitativa e qualitativamente o potencial de uma jazida petrolfera, determinando sua capacidade produtiva e o valor estimado de suas reservas de leo e gs [Tho01]. Uma das principais tcnicas utilizadas na avaliao das formaes a perlagem, que consiste em traar pers para os poos. Os pers dizem respeito imagem visual, em relao profundidade, de uma ou mais caractersticas das rochas perfuradas no poo. Caractersticas como resistividade eltrica, radioatividade natural ou induzida e potencial eletroqumico natural determinam o perl de um poo. Os pers so obtidos com o deslocamento de um sensor de perlagem dentro do poo, sendo denominados de pers eltricos, independentemente do processo fsico de medio utilizado. Com base na anlise dos pers, decide-se quais intervalos do poo so de interesse econmico potencial para um possvel teste de formao, colocando o poo em uxo, que fornecer dados sobre a capacidade produtiva do poo.
2.4 Completao de Poos

O conceito de completao relaciona-se com o conjunto de operaes destinadas a equipar o poo para produzir leo ou gs de forma segura e econmica durante toda a sua vida produtiva. A otimizao da vazo de produo representa um dos aspectos tcnicos mais relevantes a ser planejado na fase de completao. Am de minimizar a necessidade de intervenes futuras na manuteno do poo, preciso fazer com que a completao seja feita da forma mais permanente possvel. Tendo em vista os altos custos envolvidos na etapa de completao, deve-se planejar cuidadosamente a execuo desta etapa e fazer uma anlise minuciosa da viabilidade econmica.
2.5 Elevao de Petrleo

Os mtodos de elevao de petrleo so classicados como naturais ou articiais [Tho01]. Na elevao natural os uidos contidos no reservatrio subterrneo alcanam a superfcie devido, exclusivamente, energia contida no reservatrio. Os poos que produzem desta forma so chamados de surgentes. Se a presso do reservatrio for baixa, para que os uidos alcancem a superfcie necessria a adio de alguma energia externa. Essa situao pode ocorrer em poos recentemente perfurados, porm mais comum em poos no nal da sua vida produtiva. Neste caso, utilizam-se os mtodos de elevao articiais que, utilizando equipamentos especcos, reduzem a presso do uxo no fundo do
2.5. ELEVAO DE PETRLEO
15
poo, aumentando o diferencial de presso sobre o reservatrio, resultando no aumento da vazo. Os principais mtodos de elevao articial utilizados atualmente na indstria so [AdSdB 01]:

Gas-lift Contnuo e Intermitente (GLC e GLI); Bombeio Centrfugo Submerso (BCS); Bombeio Mecnico com Hastes (BM); Bombeio por Cavidades Progressivas (BCP).
A escolha de um mtodo de elevao articial depende de fatores como o nmero de poos, a produo de areia, profundidade do reservatrio, disponibilidade de energia, equipamento disponvel, treinamento do pessoal, custo operacional, entre outros.
2.5.1 Gas-Lift
O mtodo de elevao articial que utiliza a energia contida em gs comprimido para elevar uidos at a superfcie chamado de gas-lift. Este mtodo, alm de exigir investimentos relativamente baixos para poos de grande profundidade, ideal em poos que produzem uidos com elevado teor de areia. Os dois principais tipos de gas-lift so o contnuo e o intermitente. O gas-lift contnuo bastante similar elevao natural. Esse mtodo tem como objetivo gaseicar o uido produzido atravs da injeo contnua de gs a alta presso na coluna de produo. Assim, possvel diminuir a presso de uxo no fundo do poo e, consequentemente, aumentar a vazo do uido. A injeo de gs na coluna de produo se d continuamente, sendo controlada na superfcie atravs de um regulador de uxo conhecido como choke. O gas-lift intermitente desloca golfadas do uido at a superfcie injetando gs a alta presso na base das golfadas. Neste caso, a injeo de gs possui tempos bem denidos e geralmente controlada na superfcie por um intermitor de ciclo e uma vlvula controladora ou motor valve. Os sistemas de elevao de uido que utilizam gas-lift so compostos por:
fonte de gs a alta presso (compressores); controlador de injeo de gs na superfcie (choke ou motor valve); controlador de injeo de gs de subsuperfcie (vlvulas de gas-lift); e equipamentos de separao e armazenamento dos uidos produzidos (separadores e tanques).
A injeo de gs na coluna de produo em um sistema de gas-lift contnuo proporcional vazo do lquido que vem do reservatrio. Assim, o orifcio das vlvulas de controle de injeo pode ser relativamente pequeno. O sistema de gas-lift intermitente requer uma elevada vazo peridica de gs para imprimir uma grande velocidade ascendente ao uido, de forma que ele seja deslocado at a superfcie. Neste caso, as vlvulas precisam ter orifcios maiores e aberturas mais rpidas, reduzindo a penetrao de gs na golfada de uido.
16
2.5.2 Bombeio Centrfugo Submerso (BCS)

Num sistema de BCS, um cabo eltrico transmite energia para o fundo do poo. Essa energia utilizada por um motor de subsuperfcie que a transmite para o uido sob a forma de presso, utilizando uma bomba centrfuga. A tcnica de BCS tem evoludo entre os mtodos de elevao articial devido exibilidade dos equipamentos disponveis. H alguns anos, o BCS era utilizado somente em poos que produziam a altas vazes sobre a inuncia do inuxo da gua. Hoje em dia, j se considera o uso dessa tcnica em poos com uidos de alta viscosidade e poos com altas temperaturas.
2.5.3 Bombeio Mecnico com Hastes (BM)

O BM a tcnica de elevao articial de petrleo mais utilizada no mundo, podendo ser utilizado para elevar uido a mdias vazes em poos rasos [Tho01]. Se utilizado em poos de grande profundidade, obtm baixas vazes. O bombeio mecnico com hastes transforma o movimento rotativo de um motor eltrico ou de combusto interna em movimento alternado das hastes para o fundo do poo, acionando uma bomba que eleva os uidos at a superfcie em ciclos de bombeio. Cada ciclo de bombeio composto por um curso ascendente das hastes, chamado de upstroke, e outro descendente, downstroke. Esse mtodo de elevao se torna problemtico em poos que produzem muita areia e em poos desviados ou direcionais. A presena de areia no uido desgasta os equipamentos utilizados no bombeio devido sua abrasividade. Nos poos direcionais, a utilizao do bombeio mecnico resulta num elevado atrito entre as hastes e a coluna de produo, desgastando-os prematuramente. Os principais elementos envolvidos em um sistema de elevao de uidos por bombeio mecnico so:
bomba de subsuperfcie; coluna de hastes; unidade de bombeio ou UB; e motor.
O esquema representado na gura 2.3 ilustra um sistema de bombeio mecnico com hastes. A bomba de subsuperfcie responsvel por fornecer energia ao uido vindo da formao. Essa transmisso de energia ocorre sob a forma de aumento de presso. A coluna de hastes, atravs do seu movimento alternativo, transmite energia para a bomba de subsuperfcie. A primeira haste no topo da coluna chamada de haste polida, por ter sua superfcie externa polida. A haste polida, devido ao movimento alternativo da coluna, entra e sai constantemente do poo e tem a funo de proporcionar uma maior vedao cabea do poo. A unidade de bombeio responsvel pela converso do movimento de rotao do motor em movimento alternado transmitido s hastes. A escolha da unidade de bombeio deve atender a trs solicitaes, de modo a no sofrer danos durante a sua operao. So elas: o torque mximo aplicado, a mxima carga das hastes, e o mximo curso da haste polida.
2.5. ELEVAO DE PETRLEO
17
Unidade de Bombeio
& ' & ' & ' & ' & ' & '
& '
& '
& '
Motor Linha de Produo Sada de Ar RTU
Coluna de Hastes
Bomba de Subsuperfcie
Figura 2.3: Sistema de Bombeio Mecnico O motor, atravs do seu movimento de rotao, responsvel por transmitir energia unidade de bombeio. Os motores podem ser eltricos ou de combusto interna. A disponibilidade de energia eltrica implicar sempre na utilizao de um motor eltrico, tendo em vista que so mais ecientes, tm menor custo operacional e apresentam menor rudo em relao aos motores de combusto interna. Estes so utilizados, geralmente, em locais isolados, onde a construo de uma rede para distribuio eltrica economicamente invivel. O acompanhamento da produo de um poo que utiliza o sistema de bombeio mecnico se d principalmente pela anlise de cartas dinamomtricas [dABF93]. As cartas dinamomtricas so grcos que representam a variao da carga na haste polida em funo do tempo, durante o perodo de um ciclo de bombeio. A carga na haste polida o peso por ela suportado. A carta obtida instalando-se um dinammetro para registrar as cargas na haste polida durante um ciclo completo. A gura 2.4 representa um exemplo de carta dinamomtrica.
2.5.4 Bombeio por Cavidades Progressivas (BCP)

No mtodo de elevao articial conhecido com BCP a transferncia da energia necessria elevao do uido feita atravs de uma bomba de cavidades progressivas.
18
Upstroke
Carga na haste polida
Peso do uido Downstroke
Peso das hastes no uido
Figura 2.4: Carta Dinamomtrica Este tipo de bomba passou a ser utilizada na elevao articial de petrleo, no Brasil, em 1984. Por se revelar um mtodo muito simples e eciente na produo de uidos viscosos, a utilizao destas bombas tem se expandido rapidamente. Uma bomba de cavidades progressivas funciona imersa em um poo de petrleo, sendo constituda de rotor e estator. A geometria do conjunto forma uma srie de cavidades hermticas idnticas. A ao de bombeio se d quando o movimento giratrio do rotor no interior do estator gera um movimento axial das cavidades de maneira progressiva no sentido da suco para a descarga do uido. A bomba pode ser acionada diretamente no fundo do poo atravs de um acionador eltrico ou hidrulico acoplado bomba. Outra forma de acionamento por meio de uma coluna de hastes e um cabeote de acionamento. Neste caso, a bomba pode ser acionada da superfcie. A gura 2.5 ilustra um esquema de elevao articial utilizando uma bomba de cavidades progressivas.
Figura 2.5: Elevao articial com BCP
Captulo 3 Arquitetura do Sistema

Os elementos que compem um sistema de superviso so o processo fsico, o hardware de controle, o software de superviso e a rede de comunicao, como descrito na seo 1.2 e ilustrado na gura 1.3. A arquitetura de sistema de superviso proposta deve garantir que os dados do processo possam ser acessados pelos usurios do sistema, de forma independente e transparente em relao ao hardware de controle. Assim, a arquitetura no deve impor restries quanto ao equipamento utilizado para este m ou quanto ao processo sendo supervisionado. A forma de comunicao utilizada para acessar os dados da superviso atravs da rede de comunicao tem inuncia direta no problema de software de superviso dependente do hardware de controle. Assim, para eliminar essa relao de dependncia necessrio estabelecer uma forma de comunicao que permita o acesso aos dados de forma transparente em relao ao hardware de controle e garantir que o software de superviso seja capaz de se comunicar na rede utilizando o formato estabelecido para a comunicao. A rede de comunicao dos sistemas de superviso industriais subdividem-se em rede de campo e rede local de superviso. As redes de campo utilizam, em sua maioria, o padro de comunicao mestre/escravo para obter os dados do processo armazenados nos controladores (CLPs ou RTUs). Neste padro somente a estao mestre pode iniciar qualquer procedimento de comunicao, cando as estaes escravas condicionadas a responder s solicitaes do mestre. As redes locais de superviso, geralmente, permitem que suas estaes se comuniquem utilizando o padro cliente/servidor, como concludo por John Marcuse [MMP97]. Neste caso, toda comunicao se d entre cada cliente e o servidor, no podendo ocorrer diretamente entre clientes. Os clientes enviam requisies que solicitam ou remetem informaes ao servidor, que deve atend-las em tempo til.
3.1 Rede de Campo

O padro de comunicao mais utilizado nas redes de campo industriais o mestre/escravo. Com isso, e baseando-se no fato de que o padro de comunicao utilizado na rede de campo no atinge o nvel de aplicao do software de superviso, portanto no afeta o problema de dependncia, a arquitetura proposta para o sistema de superviso adota o padro mestre/escravo para a rede de campo.
20
CAPTULO 3. ARQUITETURA DO SISTEMA
Um dos protocolos de comunicao mais conhecidos da indstria que utilizam o padro mestre/escravo o modbus [Mod03]. Todavia, a arquitetura proposta tambm no restringe o protocolo de comunicao utilizado na rede de campo, desde que obedea o padro mestre/escravo adotado pela arquitetura. No funcionamento dos protocolos mestre/escravo, a solicitao de informaes deve partir do mestre. Essa solicitao deve ser enviada para todos os escravos atravs do canal nico de comunicao, o que caracteriza uma comunicao em broadcast. Entretanto, somente o escravo para o qual destina-se a mensagem deve responder solicitao. O tempo de transmisso de dados em redes que utilizam este padro determinstico, pois, apesar de o canal de comunicao ser nico, o incio de um procedimento de comunicao de competncia exclusiva da estao mestre, implicando a inexistncia de colises no trfego deste tipo de rede.
3.2 Rede de Superviso Local

As maioria das redes de superviso local utilizam o padro de comunicao cliente/servidor na troca de informaes. Nesta rede, o servidor deve atender s requisies de servio dos clientes. O servidor em uma rede de superviso local tem como objetivo principal interconectar esta rede rede de campo, permitindo que qualquer cliente seja capaz de acessar, de forma indireta, os dados do processo fsico adquiridos na rede de campo [MMP97]. Em alguns casos, por simplicidade, servidor e mestre podem residir logicamente na mesma aplicao e sicamente na mesma mquina. A forma de comunicao entre as redes de campo e superviso tem inuncia direta no problema de software de superviso dependente, tendo em vista que esse software utiliza a rede de comunicao para acessar os dados do processo fsico. Assim, a arquitetura proposta como soluo deste problema sugere um protocolo, denominado Protocolo de Comunicao Inter-redes (PCI), e sua interface de comunicao capazes de integrar as redes de superviso e campo, estabelecendo um padro que pode ser utilizado em qualquer rede de comunicao de sistemas supervisrios para processos fsicos industriais.
3.3 Protocolo de Comunicao Inter-redes

A solicitao ou envio de informaes utilizando o PCI deve ser iniciada sempre atravs de requisies que so processadas pela estao que interliga as duas redes, o servidor. No caso geral, as requisies tm origem no cliente, sendo chamadas de requisies externas. Em um caso particular, uma requisio pode ter sua origem no prprio servidor. A este tipo de requisio, denomina-se requisio interna. O destino de uma requisio ser sempre o servidor, que deve coloc-la em uma la do tipo FIFO (First In First Out), process-la e respond-la. No PCI, para cada requisio recebida pelo servidor, duas respostas correspondentes, sendo uma parcial e outra denitiva, devem ser enviadas em resposta. A resposta parcial, ou rplica intermediria (RI), gerada pelo servidor sempre que recebe uma requisio. O servidor deve enviar uma RI para a origem da requisio, am de informar se tem condies de processar a requisio recebida. O servidor deve ainda, aps processar a requisio, enviar para o(s) cliente(s) apropriado(s) uma resposta
3.3. PROTOCOLO DE COMUNICAO INTER-REDES
21
denitiva (RD) contendo os dados solicitados ou a conrmao dos dados enviados na requisio. A RD encerra a troca de informaes iniciada por uma requisio. A Tabela 3.1 descreve a relao das requisies e respostas com seus destinos e origem na transmisso utilizando o PCI. Transmisso Requisies Internas Requisies Externas Rplica Intermediria Resposta Denitiva Origem Servidor Cliente Servidor Servidor Destino Servidor Servidor Cliente ou Servidor Cliente ou Clientes
Tabela 3.1: Requisies e Respostas
3.3.1 Funcionamento do PCI

Um sistema utilizando o PCI deve garantir que a requisio chegue estao de interligao das redes. Assim, para cada requisio recebida, o servidor deve enviar uma RI para a estao de origem da requisio. O tempo decorrido desde a sada de uma requisio de sua origem at o recebimento da RI deve ser da ordem de dezenas de milissegundos. Esse perodo chamado de timeout intermedirio. A RI dever indicar se o servidor tem condies de processar a requisio. Uma RI do tipo not acknowledge indica que o servidor no poder processar a requisio, enquanto a RI do tipo acknowledge indica que a requisio ser normalmente processada no servidor. Processada a requisio, uma RD dever ser enviada ao cliente. Se a requisio for externa, o tempo decorrido entre o envio da requisio e o recebimento da RD dever ser da ordem de alguns segundos, denominado timeout nal. O recebimento de uma RD originada por uma requisio interna no deve obedecer critrios de tempo, j que a origem da requisio, o servidor, no coincide com o destino da resposta, o cliente. A Figura 3.1 ilustra o uxo de mensagens PCI iniciado por uma requisio externa. Cliente Requisio Externa Rplica Intermediria (RI) Resposta Denitiva (RD) Servidor
Figura 3.1: Fluxo de Dados: Requisies Externas
22
Na gura 3.2 possvel observar como o PCI prev o uxo de dados originado por uma requisio interna. Servidor Requisio Interna Rplica Intermediria (RI) Servidor
Cliente Resposta Denitiva (RD)
Figura 3.2: Fluxo de Dados: Requisies Internas
3.3.2 Interface de Comunicao

Para denir uma interface lgica e padronizada e permitir que qualquer informao trafegue na rede de comunicao estabelecida utilizando o PCI de forma segura, so utilizados dois quadros, ou frames, de comunicao. O primeiro quadro, observado na Fgura 3.3, responsvel pelo envio das requisies. ID (4 bytes) Funo (4 bytes) Estao (4 bytes) Dados (n bytes)
Figura 3.3: Quadro de Requisies PCI Os campos encontrados nos quadros de requisies so: ID: representa o identicador nico para cada requisio enviada. Esse campo tem um tamanho xado em quatro bytes. Funo: indica a funo lgica que deve ser executada pelo servidor. O campo de funo tem seu tamanho xado em quatro bytes. Estao: informa a estao da rede de campo que deve ser acessada. Esse campo tem tamanho xo equivalente a quatro bytes. Dados: transmite os eventuais parmetros a serem utilizados pelo servidor na execuo da funo solicitada. O tamanho deste campo no constante, sendo determinado de acordo com a funo.
3.3. PROTOCOLO DE COMUNICAO INTER-REDES

O segundo quadro, ilustrado na Fgura 3.4, utilizado no envio das respostas. ID (4 bytes) Funo (4 bytes) Dados (n bytes)
23
Figura 3.4: Quadro de Respostas PCI No quadro de respostas, os campos tm o seguinte signicado: ID: o mesmo identicador da requisio que originou a resposta. Funo: corresponde funo executada pelo servidor. Dados: contm o resultado da funo executada pelo servidor.
3.3.3 Identicao das Requisies

O ID representa o identicador nico de cada requisio, sendo codicado, no caso geral, por nmeros positivos. Este identicador gerado na origem da requisio e enviado ao servidor no quadro de requisies PCI para que, aps o processamento das requisies, o quadro de respostas PCI enviado pelo servidor contenha o mesmo ID da requisio, permitindo que a respostas recebidas possam ser associadas s requisies enviadas. Se uma resposta recebida sem que tenha sido enviada uma requisio com um ID positivo corresponde para ela, esta resposta deve ser descartada. Um ID negativo gerado, exclusivamente, em requisies internas. As requisies internas representam uma iniciativa prpria do servidor de se comunicar com os clientes. Deste modo, o cliente poder aceitar a resposta mesmo sabendo que a requisio que originou a resposta no foi enviada por ele.
3.3.4 Funes PCI

As funes lgicas representam a essncia da requisio, denindo que tipo de informao est sendo solicitada ou enviada na requisio e como essa informao deve ser processada no servidor. No quadro de requisio o campo Funo deve indicar a funo a ser excutada pelo servidor e o campo de dados deve conter os parmetros necessrios execuo. O resultado obtido na execuo das funes pelo servidor deve ser enviado no campo de dados do quadro de resposta. Neste quadro, o campo Funo deve conter o cdigo da funo executada. As funes lgicas PCI classicam-se, quanto a nalidade, em:
funes de controle; e funes utilitrias.
As funes de controle so aquelas utilizadas no gerenciamento da troca de dados utilizando o PCI. Essas funes tm origem, exclusivamente, no servidor e so utilizadas para informar aos clientes a chegada de requisies no servidor, erros ocorridos no processamento das requisies ou qualquer evento relevante que precise ser avisado aos clientes. A Tbela 3.2 mostra as funes de controle previstas pelo PCI:
24 Funo PCI_ERROR PCI_ACK PCI_NACK PC_WARN

Descrio Erro no processamento da requisio Requisio recebida e ser processada Requisio recebida, mas no ser processada Avisos ou eventos que devem ser informados Tabela 3.2: Funes de Controle
Sempre que o servidor receber alguma requisio, ele dever enviar uma RI para a origem da requisio. Assim, o campo Funo da RI deve conter o cdigo PCI_ACK, caso o servidor seja capaz de processar a requisio, ou PCI_NACK, se o processamento da requisio no for possvel. Nos dois casos o campo Dados deve ser vazio. Sempre que uma requisio for processada, o servidor dever enviar uma RD para o(s) cliente(s). No caso de erro no processamento da requisio, o campo Funo da RD deve conter o cdigo PCI_ERROR e o campo Dados deve conter o cdigo do erro ocorrido (ver seo 3.3.7). Os avisos representam o conjunto de funes utilizadas pelo servidor para noticar a ocorrncia de qualquer evento aos clientes. Como o destinatrio da noticao, o cliente, no originou a requisio para a resposta contendo a noticao, as funes de aviso devem utilizar requisies internas. As funes utilitrias representam os servios oferecidos pelo servidor e, portanto, devem ser utilizadas pelos clientes. As funes dessa classe devem ser denidas de acordo com os servios exigidos do servidor. No uso destas funes, os clientes devem enviar uma requisio contendo o cdigo da funo e receber uma RI e uma RD correspondentes requisio que as originou. Assim, as funes utilitrias devem ser enviadas atravs de requisies externas. As funes lgicas PCI subdividem-se ainda quanto forma de execuo no servidor como:
locais; e remotas.
As funes locais so aquelas executadas no servidor, sem que haja a necessidade de se comunicar com qualquer estao da rede de campo. As funes remotas exigem, obrigatoriamente, a comunicao com a rede de campo na sua execuo.
3.3.5 Acesso s Estaes da Rede de Campo

O campo Estao do quadro de requisio deve indicar o endereo da estao da rede de campo que precisa ser acessada na execuo da funo lgica. Esse endereo deve ser representado por um nmero inteiro positivo. Se a funo a ser executada pelo servidor for local, o servidor no precisar acessar nenhuma estao da rede de campo. Neste caso, o endereo da estao dever ser descartado. Esse campo tem uma funo especial quando a requisio contm uma funo de aviso. Nesta hiptese, o campo Estao contm o endereo do cliente ao qual se destina a noticao. Neste caso, o endereo zero indica que o aviso deve ser enviado para todos os clientes conectados.
3.4. O SOFTWARE DE SUPERVISO
25
3.3.6 Utilizao do campo de Dados

No quadro de requisio PCI o campo de dados responsvel por transportar os parmetros a serem utilizados na execuo das funes, sendo varivel para cada uma delas. No quadro de resposta esse campo representa a resultado da funo executada pelo servidor. Se o quadro de resposta contiver a funo PCI_ERROR, o campo Dados dever conter o cdigo do erro ocorrido (ver seo 3.3.7). Se o quadro de respostas contiver as funes PCI_ACK ou PCI_NACK, esse campo tem tamanho nulo.
3.3.7 Cdigos de Erro

Se a funo retornada pelo servidor for PCI_ERROR, o campo Dados do quadro recebido pelo cliente deve conter um dos cdigos de erro apresentados na tabela 3.3. Erro PCI_ERROR_OUT_COM PCI_ERROR_FAIL_FUNC Descrio Falha de comunicao na rede de campo Falha genrica de execuo da funo
Tabela 3.3: Cdigos de Erro
3.4 O Software de Superviso

A arquitetura proposta para o sistema de superviso sugere um modelo para implementao de software capaz de acessar os dados do processo fsico, remotamente, utilizando o PCI.
3.4.1 Funcionamento dos Clientes

A aplicao cliente deve ser capaz de enviar requisies ao servidor e tratar as respostas enviadas por ele. Para isso sugere-se a utilizao de trs processos concorrentes. O primeiro processo, chamado de processo transmissor, deve aguardar solicitaes dos usurios do software, gerar uma requisio para essa solicitao, envi-la para o servidor e inserir uma cpia da requisio em um buffer de requisies sem resposta, chamado de BC1. O segundo processo, denominado processo receptor, deve aguardar a chegada de respostas, repassar o resultado ao usurio e retirar sua requisio correspondente de BC1. O terceiro processo, chamado de processo de vericao, percorre continuamente o buffer BC1, avaliando o tempo decorrido desde o envio de cada requisio, garantindo a aplicabilidade dos timeouts exigidos no PCI. As cpias das requisies devem ser armazenadas em BC1 juntamente com o momento do armazenamento e o estado da requisio. O estado de uma requisio indica se o cliente j recebeu alguma resposta correspondente. A tabela 3.4 identica os estados possveis para as requisies em BC1. O processo transmissor responsvel por armazenar as requisies em BC1. Para cada requisio enviada ao servidor, o processo transmissor deve armazenar em BC1 uma
26 Estado PCI_WAIT_RI PCI_WAIT_RD

Descrio Aguardando rplica intermediria (ACK ou NACK ) Aguardando resposta denitiva Tabela 3.4: Estados das Requisies
cpia da requisio no seu estado inicial. O estado inicial de uma requisio deve indicar que nenhuma resposta foi recebida ainda e, portanto, uma RI esperada (PCI_WAIT_RI). O processo receptor responsvel pelo controle interno de recebimento das respostas, modicando o estado das requisies e retirando-as de BC1. Quando uma RI do tipo acknowledge recebida, o estado da requisio correspondente deve ser alterado de modo a indicar que uma RD aguardada (PCI_WAIT_RD). Caso a RI seja do tipo not acknowledge, a requisio deve ser eliminada de BC1, pois indica que o servidor no ser capaz de process-la, e o usurio deve ser noticado. No recebimento de uma RD, o resultado deve ser repassado ao usurio e a sua requisio correspondente deve ser eliminada de BC1. O recebimento de uma RD para uma requisio no estado PCI_WAIT_RI viola o protocolo de comunicao e, portanto, a resposta deve ser descartada. O mesmo deve acontecer no recebimento de uma RI para uma requisio correspondente no estado PCI_WAIT_RD. A busca por uma requisio correspondente s respostas deve ser feita comparando-se o campo ID dos quadros PCI. A inexistncia de uma requisio em BC1 correspondente a uma resposta recebida com um ID positivo deve fazer com que o cliente despreze tal resposta. As respostas com ID negativo devem ser processadas sem a busca por uma requisio correspondente, pois so originadas de requisies internas do servidor que podem indicar a ocorrncia de avisos ou alarmes. O processo de vericao deve percorrer BC1 a cada perodo de tempo estabelecido para o timeout intermedirio e avaliar o tempo decorrido desde a chegada de cada requisio no buffer. Se a requisio estiver no estado PCI_WAIT_RI e esse tempo for maior que o timeout, caracteriza-se a ocorrncia de algum problema de comunicao na rede local de superviso que deve ser informado ao usurio. Caso a requisio esteja no estado PCI_WAIT_RD e esse tempo seja maior o tempo estabelecido para o timeout nal, houve algum problema no processamento da requisio e, provavelmente, no servidor do sistema. O usurio tambm deve ser noticado neste caso. O acesso concorrente memria compartilhada representada por BC1 torna necessria a criao de uma zona de excluso mtua, ZEMC1, para esse buffer. Para gerenciar o acesso a essa zona utiliza-se um semforo de djkistra, ou mutex [Tan95], denominado de MC1. O funcionamento do processo transmissor ilustrado na gura 3.5 utilizando-se uma rede de petri [CV97] e pode ser descrito nos seguintes passos: Passo 1: processo ca bloqueado aguardando solicitaes do usurio. Passo 2: monta uma requisio com ID inequvoco positivo para a solicitao. Passo 3: processo ca bloqueado aguardando acesso ZEMC1, tentando decrementar MC1. Passo 4: insere cpia da requisio no estado PCI_WAIT_RI em BC1, juntamente com o momento do armazenamento.

Passo 5: incrementa MC1, liberando o acesso ZEM1. Passo 6: envia requisio para o servidor e retorna ao Passo 1.
27
Usurio Solicita Informao
Aguardando Solicitao
MC1
Montando Requisio
Tentando Acessar ZEMC1
Insere Requisio PCI_WAIT_RI em BC1
Envia Requisio ao Servidor
Figura 3.5: Processo Transmissor A rede de petri na gura 3.6 mostra o funcionamento do processo receptor. Uma descrio mais detalhada da atividade realizada por este processo na aplicao cliente feita nas seguintes etapas: Passo 1: processo ca bloqueado esperando a chegada de respostas. Passo 2: verica ID da resposta. Passo 3: se ID 0, toma ao programada para o aviso recebido e retorna ao Passo 1. Passo 4: se ID 0, processo ca bloqueado aguardando acesso ZEMC1, tentando decrementar MC1. Passo 5: busca requisio correspondente vericando ID das requisies em BC1. Passo 6: se no existe requisio correspondente, descarta resposta, incrementa MC1 e retorna ao Passo 1. Passo 7: se existe requisio correspondente, analisa requisio. Passo 8: se a requisio correspondente est no estado PCI_WAIT_RI, analisa resposta. Passo 9: se a resposta uma RI, verica o tipo da RI.
( )
28
Passo 10: se a RI do tipo acknowledge, muda o estado para PCI_WAIT_RD, incrementa MC1 e retorna ao Passo 1. Passo 11: se a RI do tipo not acknowledge, informa ao usurio que o servidor no foi capaz de processar a requisio e retorna ao Passo 1. Passo 12: se a resposta uma RD, descarta resposta, incrementa MC1 e retorna ao Passo 1. Passo 13: se a requisio correspondente est no estado PCI_WAIT_RD, analisa resposta. Passo 14: se a resposta uma RI, descarta a resposta, incrementa MC1 e retorna ao Passo 1. Passo 15: se a resposta uma RD, incrementa MC1, exibe resultado ao usurio e retorna ao Passo 1. O processo de vericao, ilustrado na gura 3.7, realiza as seguintes atividades: Passo 1: processo ca bloqueado aguardando acesso ZEMC1, tentando decrementar MC1. Passo 2: Enquanto no houver requisies em BC1, incrementa MC1, bloqueia por 10 ms e retorna ao Passo 1. Passo 3: seleciona uma requisio em BC1. Passo 5: analisa o estado da requisio e mede o tempo passado desde a sua chegada ao buffer. Passo 6: se o estado for PCI_WAIT_RI e o tempo medido for maior que 200 ms, informa ao usurio problema de comunicao com o servidor e retira requisio de BC1. Passo 7: se o estado for PCI_WAIT_RD e o tempo medido for maior que 5 s, informa ao usurio problema no servidor e retira requisio de BC1. Passo 8: retorna ao Passo 2.
3.4.2 Funcionamento do Servidor

A aplicao do servidor precisa armazenar, processar e responder s requisies que tm origem no cliente ou no prprio servidor. primeira vista podem no ser to bvios os motivos que levam o PCI a separar as funes locais e remotas em classes distintas apenas por necessitarem ou no de se comunicarem com as estaes da rede de campo em sua execuo. Todavia, fazendo-se uma anlise da arquitetura mestre/escravo utilizada nas redes de campo, no que diz respeito velocidade da transmisso de dados entre o mestre e seus escravos, razovel admitir que o processamento de funes locais deve ser bem mais rpido do que o processamento de funes remotas. Assim, a especicao do protocolo permite que essas funes sejam tratadas de forma diferente na implementao do servidor, evitando que a lentido na execuo de funes remotas prejudique o tempo de resposta s requisies que contm funes locais. Para realizar suas funes, o servidor utiliza cinco processos distintos e paralelos. O primeiro processo, denominado de processo leitor, recebe as requisies, envia as RIs para os seus emissores e armazena as requisies. Se a requisio contm alguma funo local,
29
Recebe Resposta do Servidor
Aguardando Respostas MC1
Verifica ID da Resposta ID < 0 ID > 0 Liberando ZEMC1 e Retornando ao Estado Inicial
Informa Aviso ao Usurio
Tentando Acessar ZEMC1
Busca Requisio Correspondente No Encontrou Descarta Resposta Analisa Requisio Encontrou
PCI_WAIT_RI
PCI_WAIT_RD Analisa Resposta
Analisa Resposta RI RD
RI
RD
Analisa RI ACK NACK
Descarta Resposta
Descarta Resposta
Exibe Resultado ao Usurio
Muda Estado para PCI_WAIT_RD
Requisio No Processada
Figura 3.6: Processo Receptor
30

Tentando Acessar ZEMC1 MC1
No H
Verifica se H Requisies em BC1
H Requisies
Bloqueia por 10 ms
Seleciona Requisio
PCI_WAIT_RI
Verifica Estado da Requisio
PCI_WAIT_RD
t < 200 ms
Verifica Tempo Informa Falha de Comunicao
t > 200 ms
t>5s
Verifica Tempo
t<5s
Informa Problema no Servidor
Retira Requisio de BC1
Retira Requisio de BC1
Figura 3.7: Processo de Vericao
ela armazenada em um buffer de requisies, denominado de BS1. Caso a requisio contenha alguma funo remota, ela armazenada em outro buffer de requisies, chamado de BS2. O segundo processo, chamado de processo local, processa as requisies em BS1 retirando-as do buffer, executando a funo solicitada ao servidor e armazenando a RD em um buffer de respostas, chamado de BS3. O terceiro processo, chamado de processo remoto, processa as requisies em BS2 retirando-as do buffer, comunicando-se com alguma estao da rede de campo e armazenando a RD em BS3. O quarto processo, denominado processo escritor, retira as RDs de BS3 e as envia aos clientes. O quinto processo, chamado de processo interno, utilizado para gerar as requisies internas. Portanto, pode ser utilizado na gerao de alarmes e avisos.
31
A criao de buffers e processos distintos para armazenar e tratar as requisies que contm funes locais e remotas de forma diferenciada se deve diferena de velocidade do processamento inerente aos tipos de funes. Tratar estas requisies da mesma maneira introduziria um atraso desnecessrio no tempo de resposta a requisies processadas rapidamente. Ao contrrio das requisies, as RDs so processadas nos clientes. Portanto, no servidor, so tratadas da mesma forma, utilizando um nico buffer para armazen-las e um nico processo para envi-las. Para evitar que os processos local e remoto quem em espera ocupada enquanto no houver requisies nos buffers BS1 e BS2, respectivamente, so utilizados dois semforos bloqueantes denominados de SBS1 e SBS2 que sinalizam a existncia de requisies nos buffers. A esperada ocupada no processo escritor evitada utilizando-se um semforo bloqueante, chamado de SBS3, que sinaliza a existncia de respostas em BS3. O acesso simultneo s zonas de excluso mtua ZEMS1, ZEMS2 e ZEMS3 representadas, respectivamente, pelos buffers BS1, BS2 e BS3 pode ser evitado utilizando-se os semforos de dijkstra MS1, MS2 e MS3. Antes de inserir cada requisio ou resposta nos seus respectivos buffers, necessrio vericar a existncia de, pelo menos, uma vaga disponvel no buffer em que ser inserido o dado. Para isso, so utilizados os semforos no-bloqueantes SNS1, SNS2 e SNS3 que sinalizam a existncia de vagas em BS1, BS2 e BS3, respectivamente. Esses semforos devem ser inicializados com o tamanho mximo permitido em cada buffer. A existncia de vaga em BS1 ou BS2 indica que o servidor ser capaz de processa a requisio recebida. Assim, uma RI do tipo acknowledge dever ser enviada para o emissor da requisio. Caso no haja vaga no buffer para a requisio recebida, o servidor no processar a requisio, devendo enviar uma RI do tipo not acknowledge para o emissor da requisio. A indisponibilidade de vagas em BS3 indica que o processo escritor no est conseguindo enviar as respostas em tempo hbil. Esta situao jamais deve ocorrer, pois os processos local e remoto, por processarem as requisies, so bem mais lentos que o processo escritor. Caso ocorra, esta situao indicar um falha no funcionamento do servidor e deve ser tratada, no prprio servidor, como uma exceo fatal. O funcionamento do processo leitor, ilustrado na gura 3.8, pode ser descrito nos seguintes passos: Passo 1: processo ca bloqueado aguardando recebimento de requisies. Passo 2: l a requisio recebida e identica o tipo de funo. Passo 3: se a funo local, verica se h espao em BS1 tentando decrementar SNS1. Passo 4: se no h espao em BS1, envia RI do tipo not acknowledge para o emissor da requisio e retorna ao Passo 1. Passo 5: se h espao em BS1, processo bloqueia aguardando acesso ZEMS1, tentando decrementar MS1. Passo 6: coloca requisio em BS1. Passo 7: incrementa MS1, liberando o acesso ZEMS1. Passo 8: SBS1 sinaliza requisio em BS1. Passo 9: envia RI do tipo acknowledge para o emissor da requisio e retorna ao Passo 1.
32
Passo 10: se a funo remota, verica se h espao em BS2 tentando decrementar SNS2. Passo 11: se no h espao em BS2, envia RI do tipo not acknowledge para o emissor da requisio e retorna ao Passo 1. Passo 12: se h espao em BS2, processo bloqueia aguardando acesso ZEMS2, tentando decrementar MS2. Passo 13: coloca requisio em BS2. Passo 14: incrementa MS2, liberando o acesso ZEMS2. Passo 15: SBS2 sinaliza requisio em BS2. Passo 16: envia RI do tipo acknowledge para o emissor da requisio e retorna ao Passo 1.
SBS1
MS1
SNS1
Chegada de uma Requisio
SNS2 Aguardando Requisies
MS2
SBS2
Local Identifica Tipo de Funo Tenta Acessar ZEMS1 Envia RI NACK
Remota
Envia RI NACK
Tenta Acessar ZEMS2
Insere Requisio em BS1
Insere Requisio em BS2
Sinaliza Requisio em BS1
Sinaliza Requisio em BS2
Envia RI ACK
Envia RI ACK
Figura 3.8: Processo Leitor O processo local, cujo funcionamento pode ser observado na gura, 3.9, realiza as

seguintes tarefas:
33
Passo 1: processo ca bloqueado aguardando requisies em BS1. Passo 2: processo ca bloqueado aguardando acesso ZEMS1, tentando decrementar MS1. Passo 3: retira requisio de BS1. Passo 4: incrementa MS1, liberando o acesso ZEMS1. Passo 5: sinaliza vaga em BS1 incrementado SNS1. Passo 6: processa a requisio executando uma funo local. Passo 7: verica se h espao em BS3 tentando decrementar SNS3. Passo 8: se no h espao em BS3, pra a aplicao servidora, indicando falha no processo escritor. Passo 9: se h espao em BS3, processo bloqueia aguardando acesso ZEMS3, tentando decrementar MS3. Passo 10: coloca resultado da requisio em uma RD e insere em BS3. Passo 11: incrementa MS3, liberando o acesso ZEMS3. Passo 12: SBS3 sinaliza resposta em BS3 e retorna ao Passo 1.
SNS1
MS1
SBS1
SNS3
MS3
SBS3
Aguardando Requisies em BS1
Tenta Acessar ZEMS1
Tenta Acessar ZEMS3
Pra Servidor
Remove Requisio de BS1
Insere Resposta (RD) em BS3
Sinaliza Vaga em BS1
Sinaliza RD em BS3
Executa Funo Local
Figura 3.9: Processo Local
34
No Passo 8 possvel observar a ocorrncia de uma situao anormal. O processo local o responsvel direto pela execuo das funes locais. Considerando que a atividade do processo escritor limita-se a retirar as respostas do buffer de respostas e enviar as RDs aos clientes, conclui-se que esse processo bem mais rpido do que aquele. Assim, razovel supor que o buffer de respostas jamais dever estar cheio, pois o uxo de sada bem maior que o de entrada. Desta forma, a situao de ausncia de vagas nesse buffer deve ser tratada como uma exceo fatal no funcionamento do sistema. Para representar esta situao, na gura 3.9 utiliza-se de um recurso que no faz parte do padro de modelagem por Redes de Petri, o arco inibidor. Normalmente, para que uma transio seja disparada necessrio que haja pelo menos uma marca em todos os estados que condicionam o disparo dessa transio. O arco inbidor representa a operao complementar a esta. A existncia de uma marca em qualquer estado que condicione o disparo de uma transio atravs de um arco inibidor impedir o disparo da transio. As guras 3.10 e 3.11 ilustram as condies de disparo de uma transio atravs de um arco inibidor.
arco inibidor
no habilita transio
Figura 3.10: Transio No Habilitada
habilita transio
transio disparada
Figura 3.11: Transio Habilitada O funcionamento do processo remoto, mostrado na gura 3.12, semelhante ao do
35
processo local, pois processa requisies e gera respostas. A principal diferena est no tempo de processamento. Os passos de execuo deste processo so descritos a seguir:
SNS2 MS2 SBS2 SNS3 MS3 SBS3
Aguardando Requisies em BS2
Tenta Acessar ZEMS2
Tenta Acessar ZEMS3
Pra Servidor
Remove Requisio de BS2
Insere Resposta (RD) em BS3
Sinaliza RD em BS3
Executa Funo Remota
Figura 3.12: Processo Remoto Passo 1: processo ca bloqueado aguardando requisies em BS2. Passo 2: processo ca bloqueado aguardando acesso ZEMS2, tentando decrementar MS2. Passo 3: retira requisio de BS2. Passo 4: incrementa MS2, liberando o acesso ZEMS2. Passo 5: sinaliza vaga em BS2 incrementado SNS2. Passo 6: processa a requisio executando uma funo remota e se comunicando com alguma estao na rede de campo. Passo 7: verica se h espao em BS3 tentando decrementar SNS3. Passo 8: se no h espao em BS3, pra a aplicao servidora, indicando falha no processo escritor. Passo 9: se h espao em BS3, processo bloqueia aguardando acesso ZEMS3, tentando decrementar MS3. Passo 10: coloca resultado da requisio em uma RD e insere em BS3. Passo 11: incrementa MS3, liberando o acesso ZEMS3.
36
Passo 12: SBS3 sinaliza resposta em BS3 e retorna ao Passo 1. O processo escritor, cujo funcionamento mostrado na gura 3.13, pode ser descrito nos seguintes passos: Passo 1: Passo 2: Passo 3: Passo 4: Passo 5: Passo 6: processo ca bloqueado aguardando respostas em BS3. processo bloqueia aguardando acesso ZEMS3, tentando decrementar MS3. retira resposta de BS3. incrementa MS3, liberando o acesso ZEMS3. sinaliza vaga em BS3 incrementado SNS3. envia resposta para o cliente e retorna ao Passo 1.
SBS3 MS3 SNS3
Aguardando Respostas em BS3
Tentando Acessar ZEMS3
Retira Resposta de BS3
Envia Resposta (RD) para o Cliente
Figura 3.13: Processo Escritor O processo interno responsvel pela gerao das requisies internas. Esse processo envia requisies com funes de aviso para o processo leitor. As requisies so processadas pelo processo local ou remoto, e o aviso deve ser enviado aos clientes pelo processo escritor. O funcionamento do processo interno, observado na gura 3.14, descrito nos seguintes passos: Passo 1: processo executado ciclicamente at surgir a necessidade de enviar um aviso ao(s) cliente(s).

Passo 2: Passo 3: Passo 4: Passo 5: monta requisio interna e remete ao processo leitor. aguarda RI por at 200 ms. se no receber RI, indica falha de comunicao com o processo leitor. se receber RI, retorna ao Passo 1.
37
Sim
Verifica Necessidade de Aviso
No
Monta Requisio Interna
Envia ao Processo Leitor
Aguarda RI por at 200 ms
Recebeu
No Recebeu
Falha Interna no Servidor
Figura 3.14: Processo Interno
38
Captulo 4 Implementao e Resultados

Com o objetivo de validar a arquitetura proposta neste trabalho, implementou-se um sistema de superviso para poos produtores de petrleo da indstria Petrobras na Unidade de Negcios UN-RN/CE. As sees a seguir descrevem os principais elementos deste sistema, bem como alguns resultados de sua aplicao.
4.1 Processo Fsico

A elevao articial de petrleo um dos processos mais importantes na indstria do petrleo. Conforme observado anteriormente no Captulo 2, so vrios os mtodos de elevao articial. A elevao por gas-lift contnuo uma metodologia ainda no muito explorada e cujas tcnicas de controle esto em fase de desenvolvimento ou aprimoramento. Nestas fases essencial obter dados que permitam avaliar o comportamento do sistema. Este foi um dos fatores que mais inuenciou na deciso de utilizar este processo fsico como objeto do sistema de superviso desenvolvido. O mtodo gas-lift contnuo consiste basicamente em gaseicar o petrleo atravs da injeo de gs na coluna de produo. Isto far com que a presso no fundo do poo (Pffp) diminua e o petrleo possa ser escoado. A injeo de gs se d atravs de uma vlvula de injeo que controla a vazo de gs injetado (Qgi). Neste tipo de processo fsico essencial que o sistema de superviso interaja com estas variveis, alm de outras.
4.2 Hardware de Controle

Os dispositivos de controle do processo fsico industrial normalmente so tambm responsveis por tornar disponveis os dados do processo para o supervisor. Quando um processo fsico bastante conhecido, geralmente a sua tcnica de controle no sofre muitas alteraes com o tempo. Nestes casos utilizam-se controladores dedicados ao processo. Por outro lado, as tcnicas de controle em fase de experimentao so bastante alteradas visando otimizar os seus resultados. Nestas condies os controladores programveis (CLPs) so mais adequados. A elevao por gas-lift na Unidade de Negcios UN-RN/CE da Petrobras utiliza CLPs fabricados pela empresa HI Tecnologia [Tec04].
40
CAPTULO 4. IMPLEMENTAO E RESULTADOS
4.3 Rede de Comunicao

A Rede Local de Superviso utilizada na implementao do sistema supervisrio foi a rede de comunicao privada da empresa Petrobras. Essa rede de comunicao do tipo Ethernet (100 Mbps)[Tan97] e abrange todas as Unidades de Negcio da Petrobras no territrio nacional. O sistema foi testado com 9 usurios clientes conectados ao servidor. Estes usurios utilizaram o sistema de superviso de pontos geogracamente distribudos, tais como as cidades de Mossor-RN, Natal-RN, Salvador-BA e Rio de Janeiro-RJ. O servidor do sistema foi instalado na cidade de Mossor. A Rede de Campo testada com o sistema de superviso proposto foi uma rede mestre/escravo que j existia e estava em funcionamento na empresa. Essa rede se comunica a 9600 bps atravs de enlace de rdio com protocolo de comunicao desenvolvido pela empresa HI Tecnologia (SCPHI). A rede est situada na regio de Mossor-RN e foi congurada com 7 CLPs escravos ligados a uma estao mestre. Para executar as atividades de metre na rede de campo e servidor do sistema de superviso utilizou-se uma nica estao (PC). neste ponto da rede de comunicao que as duas subredes se interconectam, conforme observado na Figura 4.1.
4.4 Software de Superviso

O software reponsvel por tornar remotamente disponveis os dados do processo fsico foi chamado de ADSPetro ( Aquisio de Dados e Superviso do Petrleo ). O ADSPetro foi desenvolvido com o objetivo de levar ao seu usurio a possibilidade de trocar informaes com o processo atravs de um ambiente visual amigvel.
4.4.1 Projeto
Para que se pudesse denir todas as funcionalidades e caractersticas essenciais para o funcionamento do ADSPetro, foi necessrio adquirir junto a alguns engenheiros da Petrobras um conhecimento maior sobre o processo fsico. Desta maneira, foi possvel estabelecer as atividades desejveis para o software, inferindo os requisitos essenciais para o seu funcionamento. Os principais requisitos inferidos dizem respeito capacidade do ADSPetro de permitir:
acesso remoto aos dados do poo a partir da Petrobras; comunicar-se com poos controlados por qualquer tipo de controlador ou CLP; visualizar a situao de funcionamento dos poos; ativar alarmes visuais que identiquem condio de falha nos poos; ligar/desligar o poo remotamente; vericar o estado do sistema de controle dos poos; congurar o poo em relao sua instrumentao, bem como calibrar os seus instrumentos remotamente; avaliar os parmetros de controle do processo, bem como alter-los remotamente; vericar o comportamento de um poo em um perodo de tempo passado;
4.4. SOFTWARE DE SUPERVISO
41
REDE DE CAMPO
MESTRE
SERVIDOR
REDE DE SUPERVISO
Figura 4.1: Rede de Comunicao
visualizar atravs de grcos o comportamento das variveis do processo; e restringir o acesso ao sistema para determinados usurios
A m de viabilizar a execuo das atividades requeridas para o ADSPetro, elaborouse um modelo para o software. Visando organizar o projeto do ADSPetro e permitir a sua implementao baseada na arquitetura cliente/servidor, o modelo dividiu o software em duas aplicaes, chamadas de servidor e cliente. As aplicaes so divididas em mdulos que organizam as funes e devem ser projetados para permitir a utilizao do protocolo PCI. A aplicao do servidor se divide em quatro mdulos servidores: Mdulo de Armazenamento de Dados (MSAD): responsvel pelo armazenamento dos dados de gerncia do sistema, de controle dos usurios e das variveis que denotam o comportamento dos poos; Mdulo do Sistema de Segurana (MSSS): responsvel pela segurana do sistema. Ele gera alarmes na ocorrncia de falhas e armazena qualquer evento incomum em arquivos especcos.
42
Mdulo de Gerenciamento de Informaes (MSGI): gerencia a chegada das requisies e o envio das respostas. Basicamente, executa as atividades pertinentes aos processos leitor e escritor. Mdulo de Execuo da Funes (MSEF): Executa as funes solicitadas pelos clientes. Suas tarefas esto diretamente relacionadas com a execuo dos processos local e remoto. A aplicao cliente foi dividida em 3 mdulos: Mdulo de Interao Humana (MCIH): realiza a interao homem-mquina, apresentando os dados para o usurio em um ambiente amigvel. Esta funo representa o que chamado de upload, enviando informaes do nvel mais baixo (poo) para o nvel mais alto (usurio) na pirmide de automao observada na Figura 1.1. responsvel ainda por fornecer os meios necessrios para o envio de informaes de controle e calibrao dos isntrumentos para o poo. Estas funes so classicadas como download de dados, pois enviam dados do nvel mais alto (usurio) para o nvel mais baixo (poo). Mdulo de Gerenciamento de Requisies (MCGR): gerencia as requisies enviadas para o servidor. Basicamente, este mdulo representa as atividades desempenhadas pelo processo transmissor. Mdulo de Tratamento de Respostas (MCTR): trata os dados recebidos em resposta s requisies, inclusive avaliando o seu tempo de chegada. Suas atividades esto diretamente relacionadas com os processos receptor e de vericao. A Figura 4.2 ilustra uma simulao da interaao entre os mdulos do ADSPetro. Neste exemplo, o usurio do software solicita a presso de uxo no fundo do poo.
Usurio em contato com o software MCIHM Solicita Pffp MCGR Envia requisio ao servidor MSGI
Exibe o resultado
Solicita execuo
MCTR Envia resposta ao cliente
MSGI Busca Pffp do poo
MSEF
Figura 4.2: Interao entre os Mdulos
4.4. SOFTWARE DE SUPERVISO
43
4.4.2 Implementao
A fase de implementao do software visa cumprir os requisitos do projeto. Desta maneira, importante ressaltar as solues de implementao para os requisitos do ADSPetro. As aplicaes cliente e servidor ADSPetro foram desenvolvidas atravs da linguagem de programao C++. Com o auxlio da ferramenta de programao visual Borland C++ Builder 5.0 um conjunto de telas foi elaborado, a m de tornar o software de superviso uma ferramenta computacional amigvel para o usurio. Estas atividades, como visto anteriormente, so gerenciadas pelo mdulo MCIH. Com o objetivo de proteger o sistema de usurios no autorizados, agregaram-se base de dados do sistema informaes cadastrais dos usurios contendo, inclusive, dados de identicao para permitir o acesso ao supervisrio. A identicao do usurio feita na inicializao da aplicao cliente e deve ser conrmada pelo servidor. A Figura 4.3 ilustra essa situao.
Figura 4.3: Login do Usurio Para permitir uma viso geral da situao dos poos e o gerenciamento dos alarmes que identicam condies de falha nos poos, elaborou-se a tela de interface com o usurio ilustrada na Figura 4.4. As indicaes coloridas sinalizam o estado dos poos. A instrumentao do poo, a requisio de dados especcos, o acionamento do modo de funcionamento (manual/automtico) e a ao de ligar/desligar o poo possvel atravs da interface fornecida pela observada na Figura 4.5. A implementao do ADSPetro na arquitetura cliente/servidor atravs de sockets utilizando a tecnologia TCP/IP [Tan97] garante que os usurios do sistema podero ter acesso remoto aos dados de qualquer poo conectado ao sistema supervisrio. O mdulo MSGI o responsvel pela comunicao entre os clientes e o servidor. Ao utilizar o protocolo PCI nas aplicaes cliente e servidor, o ADSPetro possibilita que os dados do poo sejam adquiridos independentemente do tipo de controlador utilizado. A comunicao com a rede de campo feita exclusivamente atravs do servidor e
44
Figura 4.4: Gerenciamento dos Poos portanto somente este elemento do sistema precisar conhecer o protocolo de comunicao com a rede de campo. Deste modo, qualquer aplicao cliente acessa os dados dos poos de forma transparente em relao comunicao com a rede de campo. O servidor ADSPetro utiliza o protocolo SCPHI [Tec04] para se comunicar com os controladores da HI Tecnologia atravs de um driver cedido pela empresa. O mdulo MSEF viabiliza a execuo das funes e, para tanto, determina como ser realizada a comunicao com os controladores. Se for necessrio acrescentar qualquer outro controlador ao sistema, basta implementar a sua forma de comunicao no MSEF, sem que haja a necessidade de qualquer alterao nas aplicaes cliente.
4.5 Resultados
Algumas das funes PCI criadas para realizar as tarefas do ADSPetro foram: PCI_READ_PFFP: funo remota responsvel por ler o valor atual da presso de uxo no fundo do poo; PCI_PID_QGI: funo remota utilizada para congurar os parmetros da malha de controle PID responsvel pela vazo de gs injetado no poo; PCI_SCAN: funo remota responsvel pela captura e armazenamento dos dados mais relevantes do poo, a m de formar uma base de dados histrica; e PCI_CLOSE_PORT: funo local utilizada para forar o fechamento do canal de comunicao com a rede de campo. Uma das mais importantes funes do sistema implementado a PCI_SCAN. Esta funo permite avaliar o comportamento das variveis de controle e processo no tempo. Ela adquire uma base de dados histrica do controlador e armazena em um banco de
4.5. RESULTADOS
45
Figura 4.5: Interveno em um Poo dados. Por este motivo responsvel pela aquisio da maior quantidade de dados de uma s vez. Com o objetivo de no sobrecarregar a rede de comunicao e, consequentemente, o sistema de superviso, foram criadas duas formas distintas de executar esta funo. A primeira consiste em programar uma execuo automtica pelo servidor em horrios em que o sistema tem pouco ou nenhum uso. O processo interno do servidor ADSPetro o responsvel pela execuo do scan automtico. Todavia, faz-se necessrio, algumas vezes, saber como o processo se comportava h alguns instantes de tempo. Neste caso, a segunda forma de execuo da funo permite que determinados usurios executem esta funo a qualquer tempo. Avaliaremos a seguir o comportamento do sistema de superviso implementado quando da execuo da funo PCI_SCAN solicitada por um usurio.
4.5.1 Caso de Uso

A execuo de um scan por um usurio gera a seguinte sequncia de eventos: 1. A partir da solicitao de um scan em um poo por um usurio gerada uma requisio contendo a funo PCI_SCAN. 2. O processo transmissor do cliente envia esta requisio ao servidor. 3. O processo leitor do servidor recebe a requisio e envia uma RI ao cliente indicando se est apto a executar a funo. 4. Se a requisio for processada, por se tratar de uma funo remota, o processo remoto do servidor realizar a aquisio dos dados histricos do poo.
46

5. O processo escritor envia uma RD para o cliente contendo a conrmao do scan ou uma indicao de falha de comunicao com o poo.
No caso de sucesso na execuo da funo os dados histricos do poo podem ser visualizados em uma tela como a ilustrada na Figura 4.6.
Figura 4.6: Histrico do Poo
4.5.2 Anlise de Resultados

Com o objetivo de avaliar o desempenho do sistema em relao resposta no tempo, foi gerado um arquivo de armazenamento das requisies e respostas do cliente relacionados com os seus tempos de sada e chegada, respectivamente. Realizou-se um teste com at cinco usurios solicitando informaes simultaneamente. Neste teste todos os clientes requisitam a mesma informao, a presso de uxo no fundo do poo (Pffp), a cada 1s. A Tabela 4.1 mostra o valor mdio dos tempos de resposta intermediria (RI) e denitiva (RD), de acordo com o nmero de usurios, medidos em um determinado cliente. Usurios(N ) TRI TRD 1 100ms 500ms 2 100ms 700ms 3 100ms 1100ms 4 100ms 1600ms 5 100ms 2000ms
Tabela 4.1: Tempo de Resposta
4.5. RESULTADOS
47
Observando a tabela 4.1 pode-se concluir que o nmero de usurios utilizando o sistema de superviso no exerce uma forte inuncia no tempo de resposta intermediria (TRI ). Isto ocorre porque a janela de tempo entre as requisies feitas pelos clientes (1s) relativamente grande em relao ao tempo de resposta de uma RI (100ms). Como o processamento de uma RI no servidor no deve ser demorado, a velocidade da rede local de superviso ter muito mais inuncia sobre TRI . Ao contrrio das RIs, o tempo de resposta das RDs (TRD ) tem um alto grau de dependncia do nmero de usurios requisitando informaes do sistema. Neste caso, o perodo passado entre as solicitaes de um cliente curto em relao ao tempo de processamento e retorno da RD testada (500ms). importante ressaltar que a requisio da Pffp de um poo contm uma funo PCI remota e, portanto, naturalmente mais demorada. possvel inferir que, no pior caso, o tempo de resposta de uma RD, para o teste realizado, obtido multiplicando-se o nmero de usurios pelo tempo de resposta de uma RD quando h somente um usurio conectado ao sistema. Portanto, TRD Nx500, em que TRD o tempo de resposta, em ms, da RD com a Pffp e N o nmero de usurios requisitando esta funo. Ao implementar um sistema supervisrio, podem-se utilizar os tempos medidos na Tabela 4.1 como referncia para denio dos timeouts intermedirio e nal conceituados no Captulo 3. importante avaliar a velocidade da rede local de superviso ao se denir o timeout itermedirio do sistema. Para se denir um limite de tempo que represente o timeout nal, faz-se necessrio avaliar a velocidade da rede de campo e o tempo de resposta mximo aceitvel para o sistema a ser implementado. necessrio observar que TRD depende tambm da complexidade da funo a ser executada pelo servidor e, portanto, deve inuenciar na escolha do timeout nal.
0
48
Captulo 5 Concluses
Atualmente existem solues para sistemas de superviso que tornam transparente a comunicao com a rede de campo. O protocolo OPC - OLE for Process Control a mais conhecida. Todavia, para que o OPC funcione necessrio utilizar a ferramenta DCOM - Distributed Component Object Model distribuda exclusivamente pela empresa Microsoft, o que torna a soluo completamente dependente do sistema operacional. O protocolo PCI permite que a sua implementao seja feita utilizando sockets, o que o torna exvel para ser utilizado em qualquer sistema operacional. Um fator importante a ser considerado na utilizao da metologia descrita neste trabalho que somente o elemento de interconexo, o servidor, precisa conhecer os detalhes da comunicao com as estaes escravas. Consequentemente, o acesso aos dados do processo pelo cliente ser realizado de forma transparente e independente do hardware utilizado na rede de campo. No sistema de superviso utilizado nos testes de implementao da arquitetura, e para qualquer sistema com caractersticas e elementos semelhantes a este, ser possvel agregar outros dispositivos de controle e comunicao com o processo simplesmente criando funes utilitrias que atendam s necessidades do usurio. A adoo da metodologia proposta implica uma converso da topologia mestre/escravo em cliente/servidor. Uma das principais vantagens da arquitetura proposta neste trabalho a sua aplicabilidade a solues de acesso remoto. O acesso s informaes do processo podero ser feitas remotamente por qualquer usurio com acesso rede de superviso. mister raticar a potencialidade de conexo simultnea ao mesmo processo por vrios usurios neste tipo de arquitetura. Os sistemas de superviso que s permitem o acesso de um usurio por vez s informaes do processo no aproveitam o canal de comunicao quando o usurio est conectado ao sistema, porm sem solicitar informaes. Neste caso, a comunicao com a rede de campo estar totalmente comprometida com este usurio. Na arquitetura proposta o servidor gerencia o acesso rede de campo e portanto aproveita muito melhor o canal de comunicao com esta rede. A baixa velocidade da rede de campo fator limitante no tempo de resposta do sistema. Por este motivo, uma grande quantidade de usurios utilizando o supervisrio tende a tornar o sistema mais lento. Cada sistema de superviso tem suas peculiaridades em relao quantidade de usurios e o tempo mximo aceitvel de resposta do sistema. Essas
50
CAPTULO 5. CONCLUSES
so caractersticas que devem ser considerados na implementao do sistema. Uma possvel soluo seria limitar a quantidade de usurios simultneos do sistema, o que garantiria um tempo mximo de resposta. Uma aplicao baseada na arquitetura proposta poder ser projetada e implementada em tipos diversos de interface com o usurio, tais como aplicaes dedicadas ou Web Browsers. Esta caracterstica pode ser denominada de multi-clientes e se deve independncia de qualquer sistema operacional inerente a este tipo de sistema. Outro fator relevante a ser abordado nesta arquitetura a sua capacidade de interconectar a rede de superviso a vrias redes de campo ao mesmo tempo atravs de um nico servidor. Neste caso, o servidor desempenha as funes de mestre em cada uma das redes de campo. A arquitetura proposta pode ento ser classicada tambm como uma soluo multi-mestres.
Referncias Bibliogrcas
[AdSdB 01] Dario Jos Aloise, Andra Cynthia dos Santos, Carlos Avelino de Barros, Maurcio Cardoso de Souza, and Thiago Ferreira de Noronha. Um algoritmo grasp reativo aplicado ao problema da unidade mvel de pistoneio. In XXXIII Simpsio Brasileiro de Pesquisa Operacional, 2001.
[BJP99]
Leandro Buss Becker, Wilson Pardi Junior, and Carlos Eduardo Pereira. Proposal of an integrated object-oriented environment for the design of supervisory software for real-time industrial automation systems. In Fourth International Workshop on Object-Oriented Real-Time Dependable Systems, 1999. Giovanni Bucci and Carmine Landi. A distributed measurement architecture for industrial applications. IEEE Transactions on Instrumentation and Measurement, 52(1), February 2003. Douglass L. Campbell. How customer need focused the development of a new renote terminal unit line. In IEE Computer Applications in Power, 1988. Janette Cardoso and Robert Valette. Redes de Petri. Editora da UFSC, 1997. Gianluca Cena and Adriano Valenzano. A high performance eld network based on a tree topology. In IEEE International Workshop on Factory Communication Systems, pages 105109, Vsters, Sweden, August 2002. Manuel de Almeida Barreto Filho. Gerao de carta dinamomtrica de fundo para diagnstico do bombeio mecnico em poos de petrleo. Masters thesis, Universidade Estadual de Campinas, 1993. Luiz Affonso Henderson Guedes de Oliveira. Curso de redes para automao industrial. http://www.dca.ufrn.br/~affonso, Julho 2003. Axel Daneels and Wayne Salter. What is SCADA? In International Conference on Accelerator and Large Experimental Physics Control Systems, Trieste, Italy, October 1999. 51
[BL03]
[Cam88]
[CV97] [CV02]
[dABF93]
[dO03] [DS99]
52 [EHH 00]
REFERNCIAS BIBLIOGRFICAS
Yoshio Ebata, Hideki Hayashi, Yoshiaki Hsegawa, Satoshi Komatsu, and Kuniaki Suzuki. Development of the intranet-based SCADA (supervisory control and data acquisition system) for power system. In IEEE Summer Meeting, 2000. Soumitra K. Ghosh. Changing role of SCADA in manufacturing plant. In Thirty-First IAS Annual Meeting, 1996. Ryszard Kemplous, Barbara Lyakowska, and Jan Nikodem. A data acquisition and processing system. In IEEE AFRICON99, 1999. Zhihao Ling and Jinshou Yu. The design of SCADA based on industrial ethernet. In 4th World Congress on Intelligent Control and Automation, June 2002. Andr Laurindo Maitelli. Controladores lgicos programveis. http:// www.dca.ufrn.br/~maitelli, 2003. Joaquim Melendez, Joan Colomer, and Josep Luis de la Rosa. Expert supervision based on cases. In 8th IEEE International Conference on Emerging Technologies and Factory Automation, 2001. John Marcuse, Brad Menz, and Jeffrey R. Payne. Servers in SCADA applications. In IEEE Transactions on Industry Applications, 1997. Modicon Industrial Automation Systems. Modbus protocol reference. http://www.eecs.umich.edu/~modbus, 2003. Engin Ozdemir and Mevlut Karacor. Run time position estimation with basic sensors in real time SCADA applications. In 7th International Workshop on Advanced Motion Control, 2002. Carlos Eduardo Pereira and Wilson Pardi Junior. A supervisory tool for real-time industrial automation systems. In Sixth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing, 2003. PROFIBUS. Descrio tcnica probus 2002. http://www.profibus. org.br/, 2002. Chen Qizhi. Optimization of a SCADA system based on client/server mode. In International Conference on POWERCON98, 1998. Wu Sitao and Qian Qingquan. Using device driver software in SCADA systems. In IEEE Power Engineering Society Winter Meeting, 2000. Alan Tait. Internets and intranets for industrial applications. In Hypermedia in Manufacturing Seminar, 1998.
[Gho96] [KLN99] [LY02]
[Mai03] [MCdlR01]
[MMP97] [Mod03] [OK02]
[PJ03]
[PRO02] [Qiz98] [SQ00] [Tai98]
REFERNCIAS BIBLIOGRFICAS
[Tan95] [Tan97] [Tec04] [Tho01] [Tru95]
53
Andrew S. Tanenbaum. Sistemas Operacionais Modernos. Prentice Hall do Brasil, 1995. Andrew S. Tanenbaum. Redes de Computadores. Editora Campus, 1997. HI Tecnologia. Empresa hi tecnologia. http://www.hitecnologia.com. br, 2004. Jos Eduardo Thomas. Fundamentos de Engenharia de Petrleo. Editora Intercincia, 2001. Duong Trung. Modern SCADA systems for oil pipelines. In IEEE Petroleum and Chemical Industry Conference, pages 299305, Denver, USA, September 1995. Sa Uddin, Khalid Mohamed Nor, and Sayeed Salam. Integration technique for an expert system on to a real-time system. In Proceedings of the TENCON2000, 2000. Marcelo Martins Werneck. Transdutores e Interfaces. Livros Tcnicos e Cientcos, 1996. G. Zecevic and Z. Jovanovic. Company intranet access to SCADA information. In International Conference on PowerTech, 1999. Liu Zhi, Jiang Shi Qin, Tang Bao Yu, Zhang Jun Hu, and Zhong Hao. The study and realization of SCADA system in manufacturing enterprises. In IEEE World Congress on Intelligent Control and Automation, Hefei, China, June-July 2000.
[UNS00]
[Wer96] [ZJ99] [ZQY 00]

19 Sistemas Supervisórios PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

19 Sistemas Supervisórios PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

Rodrigo Barbosa de Souza

Orientador: Prof. Dr. Adelardo Adelino Dantas de Medeiros

Natal, RN, fevereiro de 2005

Rodrigo Barbosa de Souza

Prof. Dr. Adelardo Adelino Dantas de Medeiros (orientador) . . . . DCA/UFRN

Profa . Dra . Silvia S. da Costa Botelho . . . . . . . . . . . . . . . . . . . . . . . . . DFIS/FURG

Prof. Dr. Luiz Affonso H Guedes de Oliveira . . . . . . . . . . . . . . . . . . . DCA/UFRN

Mr. Edson Henrique Bolonhini . . . . . . . . . . . . . . . . . . . . . . . . UN-RNCE/Petrobras

2 processo de extrao em poos de petrleo.

1.1 Automao de Processos Industriais

1.1.1 Processos Fsicos

1.1. AUTOMAO DE PROCESSOS INDUSTRIAIS

Rede de Comunicao de Dados

1.1.2 Sensores e Atuadores

1.1.3 Controladores Lgicos Programveis - CLPs

1.1.4 Rede de Comunicao

1.2. SISTEMAS SUPERVISRIOS

1.1.6 Gerncia de Informaes

1.2 Sistemas Supervisrios

superviso; operao; e controle.

1.2.1 Aquisio de Dados

1.2.2 Acesso aos Dados

1.2.3 Alarmes e Eventos

1.2.4 Tolerncia a Falhas

1.2.5 Estrutura Funcional

8 Rede de Campo Processo 1 Processo 2

Rede Local de Superviso Servidor

1.4 Estrutura do Documento

1.4. ESTRUTURA DO DOCUMENTO

Captulo 2 A Indstria do Petrleo

2.1 Prospeco de Petrleo

2.2 Perfurao de Poos

CAPTULO 2. A INDSTRIA DO PETRLEO

A gura 2.1 representa a ilustrao de uma sonda.

2.2.1 Revestimento de um Poo de Petrleo

2.2. PERFURAO DE POOS

Figura 2.2: Revestimento dos Poos de Petrleo

CAPTULO 2. A INDSTRIA DO PETRLEO

2.3 Avaliao de Formaes

2.4 Completao de Poos

2.5 Elevao de Petrleo

2.5. ELEVAO DE PETRLEO

CAPTULO 2. A INDSTRIA DO PETRLEO

2.5.2 Bombeio Centrfugo Submerso (BCS)

2.5.3 Bombeio Mecnico com Hastes (BM)

bomba de subsuperfcie; coluna de hastes; unidade de bombeio ou UB; e motor.

2.5. ELEVAO DE PETRLEO

Motor Linha de Produo Sada de Ar RTU

2.5.4 Bombeio por Cavidades Progressivas (BCP)

CAPTULO 2. A INDSTRIA DO PETRLEO

Peso do uido Downstroke

Peso das hastes no uido

Figura 2.5: Elevao articial com BCP

Captulo 3 Arquitetura do Sistema

3.1 Rede de Campo

CAPTULO 3. ARQUITETURA DO SISTEMA

3.2 Rede de Superviso Local

3.3 Protocolo de Comunicao Inter-redes

3.3. PROTOCOLO DE COMUNICAO INTER-REDES

Tabela 3.1: Requisies e Respostas

3.3.1 Funcionamento do PCI

Figura 3.1: Fluxo de Dados: Requisies Externas