Sistema Supervisório para Poços de Petróleo

UNIVERSIDADE DO RIO GRANDE DO NORTE FEDERAL
UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

CENTRO DE CINCIAS EXATAS E DA TERRA
PROGRAMA DE PS-GRADUAO EM CINCIA E ENGENHARIA
DE PETRLEO
Sistema Supervisrio para Poos de Petrleo
Baseados no Mtodo de Elevao Articial
Plunger Lift
Lennedy Campos Soares
Orientador: Prof. Dr. Adelardo Adelino Dantas de Medeiros
Dissertao de Mestrado apresentada ao
Programa de Ps-Graduao em Cincia e
Engenharia de Petrleo da UFRN (rea de
concentrao: Automao) como parte dos
requisitos para obteno do ttulo de Mestre
em Cincia e Engenharia de Petrleo.
Natal, RN, maro de 2010
Seo de Informao e Referncia
Catalogao da Publicao na Fonte. UFRN / Biblioteca Central Zila Mamede
Soares, Lennedy Campos.
Sistema supervisrio para poos de petrleo baseados no mtodo de elevao
articial Plunger Lift. - Natal, RN, 2011.
52f. ; il.
Orientador: Adelardo Adelino Dantas de Medeiros
Dissertao (Mestrado) - Universidade Federal do Rio Grande do Norte. Cen-
tro de Cincias Exatas e da Terra. Programa de Ps-Graduao em Cincia e
Engenharia do Petrleo.
1. Mtodos de elevao - Dissertao. 2. Sistemas supervisrios - Disser-
tao. 3. Plunger Lift - Dissertao. 4. Redes de Petri - Dissertao. I. Medeiros,
Adelardo Adelino Dantas de. II. Universidade Federal do Rio Grande do Norte.
III. Ttulo.
RN/UF/BCZM CDU 622.276.5: 681.5
Sistema Supervisrio para Poos de Petrleo
Baseados no Mtodo de Elevao Articial
Plunger Lift
Lennedy Campos Soares
Dissertao de Mestrado aprovada em 22 de maro de 2010 pela banca examinadora
composta pelos seguintes membros:
Prof. Dr. Adelardo Adelino Dantas de Medeiros (orientador) . . . . DCA/UFRN
Prof. Dr. Andr Laurindo Maitelli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DCA/UFRN
Eng. Dr. Benno Waldemar Assmann . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Petrobras
Prof. Dr. Luiz Affonso Henderson Guedes de Oliveira . . . . . . . . . . . DCA/UFFN
Aos meus pais que me forneceram
todo o apio por toda a minha vida e
principalmente no curso deste
trabalho.
Agradecimentos
Ao meu orientador e amigo, professor Adelardo pelos inestimveis conhecimentos trans-
mitidos ao longo deste trabalho.
Ao professor Maitelli pelo apoio durante o desenvolvimento deste trabalho.
Aos colegas do LAUT pelas momentos de descontrao e incentivo sem os quais, a con-
cluso deste trabalho, seria mais difcil. Em especial para Alan, Cristiano, Evellyne e
Filipe pela amizade, sugestes e auxlio.
Aos demais colegas de ps-graduao, pelas crticas e sugestes.
minha famlia pelo apoio durante esta jornada.
Petrobras, pelo apoio nanceiro.
Resumo
Os vrios mtodos de elevao articial de petrleo e os diferentes equipamentos de
automao existentes muitas vezes levam a que os sistemas supervisrios sejam dedica-
dos a um nico mtodo e/ou a um nico fabricante de equipamentos. Para contornar este
problema, foi desenvolvido o sistema SISAL, capaz de supervisionar poos com difer-
entes mtodos de elevao e equipamentos de automao. Atualmente, o SISAL est
em operao em diversos poos em vrios estados do Brasil, supervisionando poos de
bombeio mecnico. O objetivo deste trabalho desenvolver um mdulo de superviso
para o mtodo de elevao articial plunger lift, com as mesmas caractersticas de poder
trabalhar com hardwares de automao de diferentes fabricantes. O mdulo desenvolvido
ser integrado ao SISAL, de forma a incorporar ao sistema a capacidade de supervisionar
este novo mtodo de elevao.
Palavras-chave: Mtodos de Elevao, Sistemas Supervisrios, Plunger Lift, redes
de Petri.
Abstract
The several existing methods for oil articial lifting and the variety of automation
equipment for these methods many times lead the supervisory systems to be dedicated
to a unique method and/or to a unique manufacturer. To avoid this problem, it has been
developed the supervisory systemnamed SISAL, conceived to supervise wells with differ-
ent lifting methods and different automation equipments. The SISAL system is working
in several Brazilian states but, nowadays, it is only supervising rod pump-based wells.
The objective of this work is the development of a supervision module to the plunger lift
articial lift method. The module will have the same characteristics of working with au-
tomation hardware of many manufacturers. The module will be integrated to the SISAL
system, incorporating the capacity to supervise the plunger lift articial lift method.
Keywords: Supervisory Systems, SCADA, Articial Lift , Plunger Lift, Petri net.
Sumrio
Sumrio i
Lista de Figuras iii
Lista de Smbolos e Abreviaturas v
1 Introduo 1
1.1 Organizao do texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Mtodo de Elevao Plunger Lift 4
2.1 Outros Mtodos de Elevao Articial . . . . . . . . . . . . . . . . . . . 5
2.1.1 Bombeio Mecnico . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Bombeio por Cavidades Progressivas . . . . . . . . . . . . . . . 5
2.1.3 Bombeio Centrfugo Submerso . . . . . . . . . . . . . . . . . . 7
2.1.4 Gas-Lift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Plunger Lift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Classicao de Acordo com o Tipo de Instalao . . . . . . . . 10
2.2.2 Fases de Operao . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 Acompanhamento do Poo . . . . . . . . . . . . . . . . . . . . . 13
3 Sistemas Supervisrios 15
3.1 Caractersticas dos Sistemas Supervisrios . . . . . . . . . . . . . . . . . 15
3.1.1 Componentes de um Sistema de Superviso . . . . . . . . . . . . 15
3.1.2 Arquitetura de Hardware . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Sistema Supervisrio SISAL . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 Estado da Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4 Desenvolvimento e Resultados 23
4.1 Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.1 Tela de Superviso . . . . . . . . . . . . . . . . . . . . . . . . . 24
i
4.2.2 Histrico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.3 Tela de Ciclos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.4 Congurao do Poo . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.5 Comandos Avanados . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.6 Cadastro de Poos . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.7 Comunicao do Cliente-Servidor . . . . . . . . . . . . . . . . . 30
4.3 Mestre de Banco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.1 Compresso de Dados . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 Mestre de Campo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4.1 Comunicao com o Servidor . . . . . . . . . . . . . . . . . . . 34
4.4.2 Estudo do Controlador . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.3 Estudo da Comunicao . . . . . . . . . . . . . . . . . . . . . . 34
4.4.4 Reestruturao do Mestre . . . . . . . . . . . . . . . . . . . . . 40
4.4.5 Modelagem em Rede de Petri . . . . . . . . . . . . . . . . . . . 44
5 Concluses e Trabalhos Futuros 50
Referncias bibliogrcas 52
Lista de Figuras
2.1 Equipamento para Elevao Bombeio Mecnico [Thomas 2001] . . . . . 6
2.2 Equipamento para Elevao por Bombeio Mecnico [Thomas 2001] . . . 7
2.3 Equipamento para Elevao Bombeio Centrfugo Submerso [Thomas 2001] 8
2.4 Equipamento Bsico para Gas-Lift [Thomas 2001] . . . . . . . . . . . . 9
2.5 Equipamento Bsico para o Mtodo de Elevao Articial Plunger Lift . . 11
3.1 Arquitetura de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Arquitetura do SISAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1 Posio do Servidor na Arquitetura . . . . . . . . . . . . . . . . . . . . . 24
4.2 Tela de Superviso Sem Dreno . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Tela de Superviso Com Dreno . . . . . . . . . . . . . . . . . . . . . . . 25
4.4 Tela de Dados Histricos . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5 Tela de Histricos de Ciclos . . . . . . . . . . . . . . . . . . . . . . . . 27
4.6 Tela de Congurao do Poo 1 . . . . . . . . . . . . . . . . . . . . . . 28
4.10 Tela de Comandos Avanados . . . . . . . . . . . . . . . . . . . . . . . 30
4.11 Tela de Cadastro de um Poo com o Mtodo de Elevao Plunger Lift . . 31
4.12 Janelas de Comunicao de Aquisio de Dados . . . . . . . . . . . . . . 37
4.13 Rotina para determinar o mnimo tempo para a aquisio de dados histricos 38
4.14 Rotina para modicar taxa de aquisio entre dados histrico e dados atuais 39
4.15 Algoritmo para realizar a aquisio dos dados . . . . . . . . . . . . . . . 40
4.16 Mdulos do mestre de campo plunger lift . . . . . . . . . . . . . . . . . 41
4.17 Buffer do Mestre de Campo para diversos controladores e mtodos de
elevao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.18 Buffer do Mestre de campo antes da reestruturao . . . . . . . . . . . . 43
4.19 Estrutura Existente para cada Controlador . . . . . . . . . . . . . . . . . 44
4.20 Rede de Petri para determinar qual o tipo de dado deve ser lido . . . . . . 45
iii
4.21 Rede de Petri para thread que adquire dados do sistema . . . . . . . . . . 47
4.22 Thread que envia os dados ao mestre de banco . . . . . . . . . . . . . . . 49
Lista de Smbolos e Abreviaturas
JN Janela de tempo disponvel para um dia
P
i
Tempo para obter os dados do poo i (segundos)
TT Tempo total comunicao para obter os dados de todos os poos
TT
h
Tempo total para aquisio dos dados histricos
T
a
Tempo de aquisio dos dados Atuais e de Ciclo (segundos)
T
h
Tempo de aquisio dos dados de histrico (segundos)
T
x
Taxa de produo de dados (dados/segundo)
T
min
Tempo mnimo de aquisio de dados histricos
nH
i
Nmero de dados histricos para o poo i
totalHist Nmero total de dados histricos
PCab Presso existente na cabea do poo
PLS Presso existente na linha que escoa o petrleo at os tanques de separao
PRev Presso existente entre a coluna de produo e o revestimento do poo
TAF Tempo de After Flow: Tempo logo aps a chegada do pisto enquanto retirado
o excesso de gs do poo
TF Tempo Fechado: tempo em que a vlvula do poo est fechada acumulando
energia atravs do aumento de presso
TVP Tempo de Viagem do Pisto: Tempo enquanto a vlvula do poo est aberta e
esperada a chegada do pisto
v
Captulo 1
Introduo
Devido constante necessidade de aumentar produo e diminuir os custos nos mais
diversos meios de produo, a automao mostrou-se uma tima alternativa para substi-
tuio de mtodos manuais de controle e gerenciamento. Desta forma, a utilizao de
equipamentos capazes de armazenar e executar tcnicas de controle de forma automtica
vem sendo feita para tornar mais eciente a produo. No entanto, quando tais equipa-
mentos se encontram muito dispersos em uma regio, em locais de difcil acesso ou em
grande nmero, a inspeo de cada equipamento para anlise de seu funcionamento ou do
processo torna-se difcil ou at mesmo impraticvel. Para solucionar tal problema, os sis-
temas supervisrios surgiram com a incumbncia de adquirir os dados dos equipamentos
dispersos em uma regio, centraliz-los e ento expor aos operadores do processo.
A automao est presente em diversos campos da produo humana, sendo um destes
campos a indstria de explorao do petrleo. Uma das aplicaes da automao na in-
dstria do petrleo a de controlar a extrao de petrleo dos poos de forma a garantir
a maior produo possvel com o menor custo. Devido ao grande nmero de poos dis-
persos em uma vasta regio, o uso de um sistema supervisrio, adquirindo informaes
do sistema automatizado que controla os poos, torna-se essencial para o funcionamento
e aperfeioamento da extrao do petrleo.
Existem vrias diferenas entre as reservas de petrleo existentes, tais como: pro-
fundidade, diferentes composies de hidrocarbonetos e presso no reservatrio. Estas
diferenas fazem da extrao de hidrocarbonetos dos reservatrios uma atividade onde
podem ser aplicados diferentes mtodos. Estes diferentes mtodos para extrair os hidro-
carbonetos dos reservatrios so chamados de mtodos de elevao. Uma caracterstica
essencial para determinar qual o mtodo de elevao ser instalado no poo determinar a
presso existente no reservatrio, pois ser possvel determinar se um poo pode produzir
os seus hidrocarbonetos ou se ser necessrio o uso de algum mtodo auxiliar na retirada
dos hidrocarbonetos. Um mtodo de elevao que auxilia a elevar o petrleo existente no
CAPTULO 1. INTRODUO 2
poo chamado de mtodo de elevao articial.
Existemdiversos mtodos de elevao articial, tais como: bombeio mecnico, bombeio
centrifugo submerso, bombeio por cavidades progressivas, gas-lift contnuo, gas-lift in-
termitente e plunger lift. Cada mtodo indicado para um poo que possu caractersticas
que permitam ao mtodo elevar o petrleo com uma maior ecincia.
O mtodo de elevao bombeio mecnico, por exemplo, utiliza um sistema que trans-
forma um movimento de rotao de um motor, presente na superfcie, em um movimento
alternado. Este movimento transferido para uma bomba de subsuperfcie encarregada
de elevar o lquido para a superfcie. O equipamento utilizado no bombeio mecnico pode
ser visto na gura 2.1 na pgina 6 .
O princpio de funcionamento do mtodo de elevao plunger lift difere do mtodo de
elevao bombeio mecnico, pois o mtodo plunger lift utiliza o gs expelido do reser-
vatrio para o poo para impelir um pisto em direo superfcie, carregando junto con-
sigo o lquido que estiver presente acima do pisto, provocando produes intermitentes
de lquido na superfcie.
O controle da subida do pisto feito abrindo ou fechando uma vlvula presente no
m do poo e no comeo do duto que leva o petrleo para receber os primeiros tratamen-
tos.
Como cada mtodo de elevao articial possui um princpio de funcionamento difer-
ente, isto obriga a que a automao presente em um determinado poo seja diferente da
automao de um poo com outro mtodo de elevao. Por exemplo, as principais var-
iveis para anlise do comportamento do mtodo bombeio mecnico so a produo e o
grco da carga elevada emrelao posio da haste que provoca o movimento alternado
(carta dinamomtrica), enquanto no mtodo plunger lift as principais variveis analisadas
so as presses existentes no poo, a velocidade do pisto e a produo. Com variveis
analisadas to diferentes, os sistemas automatizados de cada mtodo so diferentes.
Com uma diferente automao para cada mtodo de elevao e diferentes variveis
para serem adquiridas e exibidas, uma soluo comum seria utilizar um sistema super-
visrio para cada mtodo de elevao, o que aumentaria a complexidade da anlise de
dados de um mesmo campo de produo de petrleo. Para solucionar este problema,
a Universidade Federal do Rio Grande do Norte, em parceria com a Petrobras, desen-
volveu um supervisrio com capacidade de supervisionar diferentes mtodos de elevao
chamado SISAL [de Souza et al. 2006].
O software SISAL constitudo por vrios mdulos diferentes, onde cada mdulo
responsvel por realizar uma determinada tarefa dentro da arquitetura projetada. Os m-
dulos so: cliente, servidor, mestre de campo e mestre de banco. O cliente responsvel
CAPTULO 1. INTRODUO 3
por apresentar os dados ao usurio; o servidor encarregado de interligar os mestres e o
cliente; o mestre de banco encarregado de comunicar-se com o banco de dados que ar-
mazena os dados do supervisrio; o mestre de campo responsvel por adquirir os dados
dos poos.
Apesar do supervisrio SISAL ter sido concebido para supervisionar diversos mto-
dos de elevao, este foi destinado, inicialmente, para supervisionar somente poos de
bombeio mecnico. Com o desenvolvimento do supervisrio concentrado em poos
que utilizam o mtodo de elevao bombeio mecnico, o supervisrio SISAL ainda no
atingiu completamente as expectativas iniciais de ser um software com a capacidade de
supervisionar vrios mtodos de elevao. Este trabalho pretende preencher parcialmente
esta lacuna, acoplando ao SISAL a capacidade de supervisionar poos com o mtodo de
elevao plunger lift.
1.1 Organizao do texto
O segundo captulo deste trabalho apresenta alguns mtodos de elevao, dando maior
nfase ao mtodo de elevao Plunger Lift. Ocaptulo 3 apresenta as principais caracters-
ticas dos sistemas supervisrios, como tambm o software utilizado para este trabalho,
detalhando sua arquitetura e caractersticas. O quarto captulo apresenta os resultados
deste trabalho.
Captulo 2
Mtodo de Elevao Plunger Lift
A indstria do petrleo responsvel por explorar, produzir e renar o petrleo. A
explorao consiste em determinar onde as reservas de petrleo esto depositadas atravs
de mtodos ssmicos, gravimtricos, geolgicos, etc. Depois de determinada uma reserva
de petrleo, se inicia a produo, que consiste em extrair o petrleo, encontrado no reser-
vatrio, para a superfcie. Quando o petrleo encontra-se na superfcie, este renado
para obter os seus derivados.
Das trs reas apresentadas, o trabalho ter um foco na produo. Existem duas for-
mas bsicas de extrao de petrleo: quando o mesmo encontra-se com presso suciente
no reservatrio para elevar-se sozinho superfcie (poo surgente) e quando a presso no
suciente para gerar uma produo aceitvel e se faz necessrio utilizar algum mtodo
de elevao articial, para prover energia necessria elevao.
Elevao Natural ( Poo Surgente): Neste caso, o nico equipamento necessrio na
cabea de poo um conjunto de vlvulas encarregadas de cessar ou diminuir o
uxo dos uidos. Tal conjunto de vlvulas chamando de rvore de natal.
Elevao Articial: Neste caso necessrio utilizar tcnicas que permitam extrair
o petrleo que no consegue chegar superfcie. Estas tcnicas so chamadas de
Mtodos de Elevao Articial de Petrleo. Atualmente, as principais tcnicas uti-
lizadas so: Gas-Lift, Bombeio Centrifugo Submerso (BCS), Bombeio Mecnico
(BM) e Bombeio por Cavidades Progressivas (BCP) [Thomas 2001]. Alm destes
mtodos, tambm importante citar um mtodo de elevao que trabalha com um
princpio semelhante ao gas-lift, chamado de Plunger Lift, ao qual este trabalho se
refere.
CAPTULO 2. MTODO DE ELEVAO PLUNGER LIFT 5
2.1 Outros Mtodos de Elevao Articial
Na presente seo apresentado um resumo sobre o funcionamento dos principais
mtodos de elevao utilizados pela indstria do petrleo.
A escolha de um mtodo de elevao em detrimento de outro feita levando em con-
siderao fatores como o nmero de poos, a produo de areia, profundidade do reser-
vatrio, disponibilidade de energia, viscosidade do uido, presena de gs, equipamento
disponvel, treinamento de pessoal e custo operacional.
2.1.1 Bombeio Mecnico
O mtodo de elevao bombeio mecnico o mais utilizado no mundo. Seus prin-
cipais elementos so bomba de subsuperfcie, coluna de hastes, unidade de bombeio e
motor, como pode ser visto na gura 2.1. O princpio do bombeio mecnico transfor-
mar o movimento rotativo, fornecido por um motor, em um movimento alternado. Esse
movimento alternado transmitido pela coluna de hastes at a bomba de subsuperfcie.
Na bomba de subsuperfcie, o movimento alternado transformado em diferencial de
presso, o que provoca a elevao do uido.
Este mtodo tem a caracterstica de funcionar bem para vazes mdias e poos no
profundos. No entanto, para poos muito profundos, este mtodo no pode produzir a uma
grande vazo. Este mtodo tambm no se adapta bem em poos onde existe a produo
de areia, j que areia danica a bomba de subsuperfcie. Poos que possuem uma alta
razo gs-leo tambm no so indicados a produzir atravs deste mtodo, devido ao fato
do gs diminuir a ecincia da bomba.
O acompanhamento de um poo em produo atravs do mtodo de elevao bombeio
mecnico realizado atravs de testes de produo e cartas dinamomtricas. Cartas di-
namomtricas consistem de grcos da carga elevada pela coluna de hastes em relao
posio da coluna.
2.1.2 Bombeio por Cavidades Progressivas
O mtodo de elevao bombeio por cavidades progressivas faz a transferncia de
energia atravs de uma bomba de cavidades progressivas. uma bomba de desloca-
mento positivo que trabalha dentro do poo de petrleo, constituda por rotor e esta-
tor. A geometria do conjunto tal que forma uma srie de cavidades hermticas idn-
ticas. O rotor, ao girar no sentido da suco para a descarga, realiza a ao de bombeio
[Thomas 2001, Assmann 2008].
Figura 2.1: Equipamento para Elevao Bombeio Mecnico [Thomas 2001]
Os componentes bsicos do mtodo de elevao BCP so: um motor, normalmente de
superfcie; uma transmisso composta por polias e uma caixa de reduo; uma coluna de
hastes que transmite o movimento de rotao; uma bomba de subsuperfcie.
O mtodo de elevao BCP utilizado para poos com uidos de alta e de baixa
viscosidade, leos parafnicos e uidos com areia. No entanto, este mtodo no acon-
selhado para poos muito profundos devido limitao do diferencial de presso sobre a
bomba e de como a energia transmitida bomba.
Figura 2.2: Equipamento para Elevao por Bombeio Mecnico [Thomas 2001]
2.1.3 Bombeio Centrfugo Submerso
Oprincpio bsico do Bombeio Centrfugo Submerso gerar umdiferencial de presso
que permita ao poo produzir ou aumentar a sua produo. Para gerar este diferencial de
presso, o mtodo BCS possui um motor localizado no fundo do poo que transforma a
energia eltrica em um movimento de rotao. Este movimento transferido para uma
bomba centrifuga que gera o diferencial de presso. Os principais elementos que formam
o conjunto BCS so a bomba, a admisso da bomba, o motor eltrico, o protetor e o cabo
eltrico. Este mtodo se adapta bem a poos que possuem uma alta vazo sob inuncia
do inuxo de gua e com baixa razo gs-lquido.
2.1.4 Gas-Lift
O princpio do mtodo de elevao Gas-Lift utilizar o gs para elevar o lquido para a
superfcie. possvel elevar o uido atravs do mtodo gas-lift de duas formas diferentes.
A primeira utiliza o princpio da gaseicao do uido e chamado de Gas-Lift Contnuo.
Esta funciona, como o prprio nome sugere, pela injeo contnua de gs a alta presso na
Figura 2.3: Equipamento para Elevao Bombeio Centrfugo Submerso [Thomas 2001]
coluna de produo. O gs na coluna faz o uido car com uma densidade menor, o que
diminui a presso no fundo do poo com o conseqente aumento do uxo. Alm disso,
como o gs possui uma densidade menor que a do lquido, este se eleva e o movimento
de subida do gs acaba elevando tambm o lquido. A segunda forma de elevar o uido
chamada de Gas-Lift Intermitente e funciona com a injeo de gs na coluna de produo
de forma intermitente. O gs injetado se expande ao subir para a superfcie, carregando
junto parte do uido que estiver acima do ponto onde o gs foi injetado e produzindo na
superfcie uma sada intermitente de uido (golfada).
Os principais equipamentos para permitir a elevao por gas-lift podem ser vistos na
gura 2.4: fontes de gs de alta presso (compressores); controlador de injeo de gs na
superfcie (choke ou motor valve); controlador de injeo de gs de subsuperfcie (vlvu-
las de gas-lift); equipamentos para separao e armazenamento dos uidos produzidos
(separadores, tanques, etc.).
Figura 2.4: Equipamento Bsico para Gas-Lift [Thomas 2001]
O mtodo de elevao por gas-lift tem aplicaes em poos com vrias profundidades
(at 2.600 metros, dependendo da presso do gs) e vazes (1 a 1.600 m
3
); tambm
aconselhvel utilizar este mtodo em poos com alto teor de areia e/ou elevada razo
gs lquido. Outra caracterstica deste mtodo que o mesmo possui custos de operao
relativamente baixos [Thomas 2001].
2.2 Plunger Lift
O mtodo de elevao plunger lift possui um princpio de funcionamento semelhante
ao mtodo de elevao gas-lift. Ambos os mtodos de elevao utilizam o gs para elevar
os uidos presentes no poo para a superfcie. A diferena fundamental entre o mtodo
de elevao plunger lift para o mtodo gas-lift intermitente que o mtodo plunger lift
possui um pisto que separa o gs injetado do lquido que ser elevado.
Opisto possui funo primria de fazer com que todo o lquido que se encontra acima
do pisto alcance a superfcie, impedindo, desta forma, que o lquido retorne ao fundo do
poo (fallback). Em poos que possuem deposio de parana, incrustaes ou hidratos,
o pisto exerce uma funo to ou mais importante do que elevar o lquido que evitar o
acmulo destes depsitos [Baruzzi 1994].
O mtodo de elevao plunger lift indicado para poos que possuem uma alta razo
gs lquido, na remoo do lquido acumulado no fundo de poos de gs, no controle de
parana e em poos de gas-lift intermitente que possuam problema de fallback [Morrow
et al. 2006].
2.2.1 Classicao de Acordo com o Tipo de Instalao
Os equipamentos bsicos de um mtodo plunger lift podem ser vistos na gura 2.5.
Nesta gura possvel observar o motor e a vlvula que fecham e abrem o uxo de
uidos do poo permitindo que o funcionamento do mtodo. Na parte superior da gura
est o lubricador resposvel por absorver o impacto de subida do pisto. Ainda na parte
superior est a vlvula mestre resposvel por fechar o poo manualmente. Na parte de
baixo da gura est a mola amortecedora e o batente resposveis por absorver o impactor
da queda do pisto. Logo acima da mola amortecedora est o plunger tambm chamado
de pisto. Por m o lquido que vai ser elevado esta representado acima do pisto com o
nome de golfada.
O mtodo de elevao plunger lift pode ser classicado em trs tipos diferentes quanto
ao tipo de instalao: plunger lift comgs intermitente; Plunger lift comumisolador entre
o anular do poo e a regio produtora (packer); Plunger lift sem packer.
Plunger Lift com gs intermitente: normalmente utilizado para aumentar a produtivi-
dade em poos que utilizam gas-lift intermitente atravs da conteno do fallback.
utilizado em poos profundos que possuem baixa presso esttica. Os equipa-
mentos utilizados assemelham-se aos do gas-lift. O conjunto de subsuperfcie deve
ser assentado logo acima da vlvula injetora de gs.
Figura 2.5: Equipamento Bsico para o Mtodo de Elevao Articial Plunger Lift
Plunger Lift com packer: utilizado normalmente em poos produtores de gs que ne-
cessitam remover lquido do fundo do poo. o menos utilizado. Possui um iso-
lador que impede a comunicao entre o anular do poo e a formao impedindo,
desta forma, a injeo de gs no fundo do poo.
Plunger Lift sem packer: a instalao mais comum em poos produtores de lquido.
utilizada para poos produtores de lquido que possuem alta razo gs lquido.
As instalaes de plunger lift sem packer podem ser divididas em mais 3 tipos de
instalaes com relao quantidade de gs existente na formao. Os trs tipos de
instalao de plunger lift sem packer so descritas abaixo:
Autnomo: Utiliza somente o gs da formao para operar.
Assistido: Uma poro adicional de gs deve ser adicionada no poo para elevar o lquido.
Esta poro adicional de gs injetada atravs do espao entre a coluna de produo
e o envoltrio do poo chamado anular.
Dreno: utilizado um dreno para remover o excesso de gs existente na formao. Tam-
bm utilizado o espao anular do poo para remover o excesso de gs existente na
formao
2.2.2 Fases de Operao
A operao de um poo que utiliza o mtodo de elevao plunger lift pode ser dividida
em quatro fazes: after-ow, buildup, viagem do pisto e produo.
After-Flow: Esta fase corresponde ao tempo em que a vlvula de controle ca aberta per-
mitindo o uxo do excesso de gs existente no poo, e ao mesmo tempo empurrando
a golfada de lquido que se encontra a na linha de produo para os tanques de sep-
arao. Esta fase ocorre sempre aps a produo de uma golfada de lquido.
Buildup: Aps o after-ow ocorre a fase de buildup, quando a vlvula de controle
fechada e o gs existente no sistema comea a acumular-se, aumentando a presso
na cabea do poo. Durante este perodo, o pisto que se encontrava na superfcie
deve percorrer o seu trajeto at o fundo do poo.
Viagem do Pisto: Aps o perodo de acumulao de energia com o aumento da presso
dentro do poo, a vlvula de controle aberta, o que nalizar a fase de buildup
e inicializar o fase de viagem do pisto. Nesta fase, o gs aprisionado no poo
impulsiona o pisto para cima e conseqentemente tambm impulsiona o lquido,
no fundo do poo, em direo a superfcie.
Produo: O m da fase de viagem do pisto ocorre quando o lquido em deslocamento
alcana a superfcie e comea a ser transferido da coluna de produo para a linha
de produo. Ao nalizar a fase de produo ocorrer novamente a fase de after-
ow reiniciando o ciclo.
2.2.3 Acompanhamento do Poo
Para acompanhar o funcionamento de um mtodo de elevao necessrio determinar
quais variveis devem ser monitoradas como forma de determinar o comportamento do
poo ou do reservatrio que o alimenta.
O mtodo de elevao plunger lift utiliza dois tipos de informaes para analisar o seu
funcionamento: a presso e a velocidade de viagem do pisto.
Em princpio quanto maior a velocidade do pisto, mais rpido o mesmo chega a su-
perfcie, o que conseqentemente implica em um maior nmero de ciclos, em um mesmo
intervalo de tempo, com um conseqente aumento da produo. Tambm com uma ve-
locidade maior do pisto, uma menor quantidade de gs passa pelo espao entre o pisto
e a parede do tubo de produo para o lquido, o que aumenta a ecincia do mtodo. No
entanto, uma velocidade muito grande pode causar danos mecnicos aos equipamentos
de superfcie e pode aumentar o fallback, o que acarretaria uma perda de produo.
Alm da velocidade do pisto, tambm necessrio monitorar algumas presses exis-
tentes, tais como: presso na cabea do poo (PCab), presso no revestimento (PRev) e
presso na linha de surgncia (PLS).
PCab A presso na cabea do poo corresponde presso medida na regio da rvore de
natal
PRev A presso de revestimento a presso medida no revestimento do poo que cor-
responde presso do fundo do poo. Este ocorre devido ao fato de no haver um
packer que isole o revestimento do fundo do poo.
PLS A presso na linha de surgncia corresponde a presso medida na linha que leva o
uido produzido para os vasos de separao.
O acompanhamento destas presses em relao ao tempo informa se o poo est pro-
duzindo de forma eciente. A presso na cabea a presso correspondente parte acima
do pisto, enquanto a presso de revestimento informa a presso abaixo do pisto. Quanto
maior esta diferena de presso maior ser a energia transmitida ao pisto, o que elevar
a velocidade do mesmo, gerando tempos menores para a subida do pisto, com o con-
seqente aumento da produo. Portanto, ao observar as presses durante o perodo de
buidup, de se esperar que a diferena de presso entre PCab e PRev aumente gradual e
continuamente, devido ao acumulo de lquido no fundo do poo. No entanto, se a dife-
rena entre as duas presses diminui isto pode signicar que o poo est trabalhando com
excesso de gs no sistema, ou mesmo se a presso aumenta rapidamente pode ser devido
ao fato do poo est trabalhando com pouco gs.
O uso de uma presso maior do que a necessria impe uma presso maior no fundo
do poo, diminuindo a produo do poo. Alm disso, com uso de uma presso PRev
muito elevada, a tendncia que a diferena entre PRev e PCab diminua o que tambm
diminui a ecincia do mtodo.
Uma quantidade menor de gs do que a necessria faz com que a diferena de presso,
que eleva o pisto superfcie, no possua energia suciente para elevar todo o lquido.
Desta forma, uma quantidade sempre crescente de lquido vai se acumulando no fundo
do poo, o que cedo ou tarde leva o mtodo de elevao plunger lift a no possuir energia
suciente para elevar o lquido existente no poo (amortecimento).
Captulo 3
Sistemas Supervisrios
O crescimento da automao dos mais diversos sistemas exigiu que os equipamentos
utilizados na automao de poos fossem supervisionados para encontrar algum dispos-
itivo com falha ou para aperfeioar o funcionamento do processo. Os sistemas super-
visrios surgiram para suprir esta carncia da indstria, sendo encarregados de adquirir as
variveis do processo, exibi-las e controlar os dispositivos de automao para interferirem
nos processos.
3.1 Caractersticas dos Sistemas Supervisrios
Um sistema supervisrio tem como funes bsicas adquirir dados, exibir os dados
adquiridos e permitir a interveno do usurio no sistema supervisionado [de Souza 2005].
Estas caractersticas bsicas impem que o sistema supervisrio esteja conectado aos dis-
positivos de automao, para obteno dos dados e envio de comandos. Alm disso, o su-
pervisrio deve possuir uma interface para apresentao intuitiva dos dados aos usurios
do sistema.
Os sistemas supervisrios so formados por elementos de hardware e software. O
primeiro responsvel por adquirir as variveis do sistema supervisionado e envi-las
para o segundo. O software responsvel por receber e armazenar os dados supervision-
ados, realizar algum tratamento nos dados e apresentar estes ao usurio. Abaixo sero ap-
resentadas as caractersticas gerais do hardware de um sistema supervisrio e em seguida
sero apresentadas as caractersticas do software de superviso utilizado neste trabalho.
3.1.1 Componentes de um Sistema de Superviso
Os componentes fsicos de um sistema de superviso podem ser descritos, de forma
simplicada, em sensores e atuadores, estaes remotas (UTRs) ou controladores lgicos
CAPTULO 3. SISTEMAS SUPERVISRIOS 16
programveis (CLPs), rede de comunicao e sistema de monitorao central (sistema
computacional SCADA).
Os sensores e atuadores so componentes presentes no cho de fbrica, responsveis
por fazer a leitura das variveis monitoradas ou atuar no processo supervisionado, tais
como: sensores de presso, sensores de temperatura e vlvulas. As estaes remotas so
responsveis por executar algoritmos de controle para automatizao dos processos obser-
vados, armazenar os dados monitorados que no futuro estaro disponveis aos operadores
e realizar algum tratamento dos dados obtidos dos sensores. As redes de comunicao so
formadas para permitir que uma estao central obtenha os dados armazenados nos diver-
sos CLPs utilizados para monitorar os processos. As tecnologias utilizadas para realizar
este intento so as mais diversas possveis, por exemplo: redes sem o, redes Ethernet e
bras pticas. Por m a monitorao central formada por um ou mais computadores
que possuem a responsabilidade de adquirir os dados desejados dos CLPs.
3.1.2 Arquitetura de Hardware
A arquitetura de Hardware de um Sistema Supervisrio pode ser dividida em 3 ca-
madas [Qingquan & Sitao 2000]: a primeira a camada dos CLPs, encarregada de
adquirir dados dos sensores; a segunda a camada do cliente; e a ltima a camada de
dados. Na camada de dados so encontrados os dispositivos que realizam a comunicao
entre os controladores de processos (CLPs) e a camada do cliente, que utilizam redes para
a comunicao. Na camada do cliente esto os dispositivos encarregados de realizar a
interao com os usurios do sistema e estes dispositivos normalmente so interligados
por redes ethernet [Daneels & W.Salter 1999].
Hardware Utilizado para Este Trabalho
O hardware utilizado na aquisio de dados possui algumas caractersticas que inu-
enciaro o desenvolvimento deste supervisrio para plunger lift.
Neste trabalho, a rede de comunicao utilizada para realizar a comunicao com os
CLPs formada por um enlace de rdio utilizando uma topologia mestre escravo onde
um rdio central comunica-se com todos os rdios presentes nos CLPs.
A superviso de poos que utilizam o mtodo de elevao plunger lift 2 possui a car-
acterstica de, na maior parte dos casos, utilizar somente a energia do prprio reservatrio
para mover o pisto e assim expelir o lquido. Quando o reservatrio do poo no pos-
sui gs suciente para realizar a elevao com o mtodo plunger lift injetado gs no
poo para compensar esta decincia. Portanto, como o mtodo plunger lift no faz uso
Figura 3.1: Arquitetura de Hardware
de energia eltrica para elevar o lquido do poo torna-se um empecilho o uso de cabos
eltricos para alimentar exclusivamente os CLPs. Para evitar este empecilho os CLPs uti-
lizados so alimentados por baterias e estas so carregadas utilizando painis solares. O
uso de baterias alimentando os CLPs vai inuenciar algumas das caractersticas do CLP
e conseqentemente na forma de aquisio dos dados.
O uso de baterias pelos CLPs leva impossibilidade de comunicao com os CLPs
durante a noite, j que estas so alimentadas por luz solar. Devido a esta realidade os CLPs
possuem memrias persistentes que armazenam durante toda a noite os dados adquiridos
pelos sensores. Dependendo das conguraes de aquisio dos sensores esta memria
pode adquirir uma massa de dados signicativamente grande que devem ser adquiridos
pelo supervisrio.
As caractersticas dos CLPs utilizados que inuenciaro o desenvolvimento deste tra-
balho so: alimentao provida por baterias, as quais so carregadas por energia solar,
e a existncia de uma memria persistente que acumula uma quantidade signicativa de
dados quando o supervisrio no pode adquirir os mesmos.
A Arquitetura de Hardware e os Sistemas Supervisrios
Na gura 3.1 possvel observar que a rede de campo comunica-se com diversos
CLPs. Tais CLPs podem ser do mesmo fabricante, o que facilita a aquisio de dados pois
todos os CLPs se comunicam utilizando o mesmo protocolo. Apesar de ser possvel mon-
itorar todo um conjunto de plantas com CLPs de um mesmo fabricante, isto incmodo,
pois torna o usurio do sistema refm de um nico fabricante. A utilizao de conjun-
tos de CLPs fabricados por empresas diferentes leva necessidade de dois supervisrios
diferentes, o que tambm indesejvel pois acarreta um novo fator de complexidade para
a superviso dos equipamentos. A soluo para este problema a utilizao de um super-
visrio que seja capaz de se comunicar com vrios tipos de CLPs utilizados, independente
do fabricante do CLP. Para este objetivo foi desenvolvido o software supervisrio SISAL
[de Souza et al. 2006].
O mesmo problema ao utilizar CLPs de diferentes fabricantes pode ser observado
quando se supervisiona diferentes mtodos de elevao de petrleo. Ao supervisionar
vrios mtodos de elevao, existem diferentes variveis a serem monitoradas e mtodos
com diferentes princpios de funcionamento. Isto obriga os CLPs a possurem diferenas
para cada mtodo de elevao. A diferena entre os diversos mtodos de elevao obri-
garia a haver um supervisrio para cada mtodo de elevao; no entanto, o supervisrio
SISAL se props a solucionar este problema.
3.2 Sistema Supervisrio SISAL
O sistema supervisrio SISAL foi elaborado para supervisionar a elevao articial
de petrleo. O SISAL foi concebido para permitir que diferentes tipos de equipamento
de hardware realizem a leitura dos dados no campo. Este tambm foi desenvolvido para
realizar a superviso de vrios mtodos de elevao diferentes. Adicionalmente, o SISAL
foi desenvolvido para otimizar o uso do rdio utilizado para adquirir os dados de interesse
dos poos de petrleo.
Com o objetivo de atender s necessidades apresentadas no pargrafo anterior, o
SISAL foi concebido com uma arquitetura apresentada na gura 3.2. A arquitetura
formada por clientes, servidor e mestres. O mdulo cliente do SISAL responsvel por
exibir os dados adquiridos atravs de interfaces grcas amigveis e intuitivas para o
usurio. O mdulo servidor possui a responsabilidade de interligar todos os outros mdu-
los. Os dados exibidos pelo cliente so adquiridos atravs do mdulo servidor e estes m-
dulos interagem atravs de uma topologia cliente-servidor. Os mestres interagem com
o servidor seguindo uma topologia mestre-escravo, onde o servidor comporta-se como
mestre enquanto os mestres so os escravos em relao ao servidor. Os mestres so
responsveis por adquirir dados nos poos de petrleo atravs de um enlace de rdio. Ex-
iste tambm um mestre responsvel por se comunicar com o banco de dados e adquirir
os dados ali existentes. Do ponto de vista dos mestres, os CLPs presentes nos poos so
seus escravos, por isso, a comunicao entre os dois segue uma topologia mestre-escravo.
O objetivo da arquitetura apresentada na gura 3.2 dividir o sistema em mdulos
onde as caractersticas de cada CLP possam car concentradas em um nico mdulo. Esta
proposta concentra a complexidade de comunicao do sistema em um nico mdulo do
software simplicando o funcionamento e desenvolvimento dos outros mdulos.
A arquitetura apresentada no SISAL se baseia em um paradigma cliente/servidor
quando disponibiliza os dados para os usurio e apresenta um paradigma mestre/escravo
quando obtm os dados da rede campo.
3.3 Estado da Arte
O estado da arte deste trabalho exibe dois temas relacionados concepo dos soft-
wares de superviso. So estes: a arquitetura de sistemas supervisrios on-line e o geren-
ciamento de aquisio de dados para sistemas supervisrios. Existem poucos trabalhos
prticos na literatura a respeito, principalmente na literatura de petrleo. Isto ocorre de-
vido, principalmente, maior parte das solues encontradas nesta rea serem solues
Figura 3.2: Arquitetura do SISAL
proprietrias as quais no so amplamente divulgadas.
Esta seo tratar dos artigos de arquitetura dos sistemas supervisrios, exibindo ar-
quiteturas propostas e em que aplicaes estas so utilizadas. Os artigos subsequentes
exploram tcnicas de aquisio de dados, levando em considerao que o fornecimento
de energia do sistema se d s no momento em que houver luz solar.
Jie et al. (2006) desenvolveram um sistema supervisrio para uma planta de produo
de energia elica, utilizando uma rede CAN (Controller Area Network) para comuni-
cao. O sistema foi desenvolvido em trs camadas: camada de aquisio, camada de
processamento, camada de transmisso e camada de usurio. Os autores utilizaram um
protocolo mestre escravo sobre o protocolo CAN e desenvolveram um software para ex-
ibir os dados adquiridos. De acordo com os autores, o sistema desenvolvido tem um
bom desempenho, com relao a anlise de tempo real. O uso de redes CAN indicado
para realizar superviso em tempo real, devido a sua fcil implementao; alm disso, a
topologia das redes CAN mais indicada para redes dispersas. Neste artigo os autores
utilizaram uma arquitetura de software de superviso, onde existe um servidor adquirindo
os dados de superviso e repassando para os clientes. A arquitetura de software apresen-
tada possui a caracterstica de ser dependente do sistema supervisionado e o hardware
que supervisiona o sistema, representando um bom exemplo da maioria dos sistemas de
superviso atuais.
Vinh et al. (2007) tratou do desenvolvimento de um modelo e de um software para
sistemas SCADA baseados em web. Utilizando polticas de segurana e o atual acesso de
baixo custo internet, o autor prope a utilizao de um modelo que permita a utilizao
de um sistema SCADA de tempo real. De acordo com os resultados experimentais, obti-
dos no trabalho, possvel obter uma rpida e fcil mudana dos sistemas desenvolvidos
para o modelo proposto. Aarquitetura apresentada neste artigo aproxima-se da arquitetura
do software SISAL, pois ambos propem sistemas modulares. Alm disso, a arquitetura
do SISAL apresenta caractersticas que o enquadram no conceito de sistemas SCADA
baseados em web. Apesar das semelhanas tericas entre as arquiteturas, a arquitetura
do artigo no trata de independncia dos equipamentos de hardware, como ocorre com a
arquitetura do SISAL.
Chikuni & Dondo (2007) realizou este trabalho que trata da segurana de sistemas
SCADA em um ambiente onde o sistema encontra-se conectado a redes internas e ex-
ternas, o que leva a vulnerabilidades de segurana aplicadas as redes serem aplicadas
aos sistemas SCADA. De acordo com o autor, os sistemas SCADA devem possuir todas
as polticas de segurana usuais como: autenticao de usurios e dados criptografados.
Alm das solues usuais, o sistema supervisrio deve possuir uma robusta poltica de
segurana, que impea que comandos prejudiquem o funcionamento do sistema moni-
torado. Para tanto, o sistema SCADA deve se certicar da necessidade dos comandos
antes de execut-los na planta.
O autor realizou os estudos para aplicao em redes de distribuio de energia. No
entanto, o seu trabalho vlido para qualquer sistema de superviso. As polticas sugeri-
das pelo autor sero aplicadas durante o transcorrer do desenvolvimento do supervisrio
deste trabalho, com excees. Atualmente o SISAL no faz uso de dados criptografa-
dos na transmisso de dados na rede local, devido ao uso de uma rede local privada que
supem-se que seja segura. No entanto, este um trabalho para ser desenvolvido em
etapas futuras.
Jian et al. (2005) trata do estudo de uma base de dados para tempo real. No artigo
introduzido o conceito de uma base de dados e um supervisrio para tempo real. Alm
disso, comenta-se sobre a implementao de uma base de dados de tempo real para um
supervisrio de um sistema de gerao de energia. O autor comenta as diculdades para
realizar a aquisio de dados em supervisrios de tempo real. importante observar que
este artigo trata do relacionamento entre o banco de dados e o sistema supervisrio de
tempo real, da mesma forma como necessrio haver neste trabalho, devido gerao
contnua e volumosa de dados.
Wang et al. (2006) prope arquitetura e scheduling para acessar dados em redes wire-
less, emambientes industriais, emtempo real. Oautor aplicou o seu modelo de scheduling
em uma arquitetura com dois nveis de acesso que suportam duas diferentes freqncias
de comunicao. Oscheduling apresentado trabalha com recepo de dois tipos diferentes
de dados, no entanto, em canais de freqncia separados. O mecanismo de scheduling ap-
resenta uma comunicao baseada em deadline, ou seja, quando uma mensagem estiver
sendo enviada o espao somente ser liberado para outras quando o tempo programado for
cumprido. O modelo de scheduling utilizado neste artigo feito para sistemas de tempo
real e portanto trabalha com pacote de dados pequenos o que no o caso da aplicao
deste trabalho.
Sastry et al. (2006) props a apresentao de uma arquitetura de sensores sem o al-
imentados por baterias, e de um algoritmo para obteno de dados, chamado, Pipelined
Time-division Model (PTM). O PTM utiliza uma tcnica que divide o tempo de comuni-
cao entre os sensores, como forma de otimizar a obteno de dados, ao mesmo tempo
que utiliza mais de um canal de freqncia para comunicar-se com os sensores. O PTM
baseado em uma arquitetura em rvore com vrios nveis, onde os ns lhos s podem
comunicar-se com os ns pais. De acordo com o trabalho a comunicao entre nveis
diferentes sempre se dar de forma intercalada, ou seja, enquanto o nvel 4 da rvore
comunica-se com o nvel 3, o nvel 2 comunica-se com o nvel 1. O trabalho ainda exibe
que o PTM possui uma menor complexidade de execuo em relao ao TinyDB [Zhao
& Guibas 2004] e o Direct Diffusion [Intanagonwiwat et al. 2000]. O artigo baseia-se
no princpio que devem existir diversos canais de transmisso para enviar os dados o que
difere do pretendido neste trabalho, alm do que, prope o uso de uma arquitetura difer-
ente da utilizada neste trabalho. O uso de diviso do tempo para adquirir dados uma
interessante proposta apontada neste artigo e que deve ser utilizada, pois como o prprio
artigo comenta: a tcnica de diviso do tempo importante para prolongar o uso de bate-
rias.
Captulo 4
Desenvolvimento e Resultados
Este trabalho consistiu em acrescentar ao supervisrio SISAL a capacidade de su-
pervisionar poos com o mtodo de elevao articial plunger lift. A metodologia para
realizar este trabalho subdividiu o problema principal em sub-problemas, de acordo com
a estrutura modular existente no software SISAL: Mestre de Campo, Mestre de Banco,
Cliente e Servidor. A comunicao entre os mdulos internos do mestre de campo e com
os controladores foi modelada em rede de Petri.
Por m importante salientar que foi publicado o artigo Sistema Supervisrio para
o Mtodo de Elevao Plunger Lift no congresso no 5
o
congresso brasileiro de P&D em
petrleo e gs que remete ao trabalho desenvolvido nesta dissertao.
4.1 Servidor
O servidor SISAL tem o propsito de interligar todos os mdulos existentes no sis-
tema supervisrio, como pode ser visto na gura 4.1. Devido a esta atividade, o servidor
receber todas as informaes dos vrios mdulos, o que obriga a que qualquer mudana
ou adio de funcionalidades leve a alteraes no servidor.
Portanto, as alteraes no servidor foram a adio de novas funes do protocolo do
sistema SISAL. Estas funes so para a aquisio dos novos tipos de dados necessrios
superviso do mtodo de elevao plunger lift.
4.2 Cliente
Como a gura 4.1 explicita, o cliente est localizado mais prximo ao usurio do que
qualquer outro mdulo, o que portanto leva a alteraes signicativas na implementao
deste mdulo. O mdulo cliente encarregado de exibir as variveis adquiridas do poo
CAPTULO 4. DESENVOLVIMENTO E RESULTADOS 24
Figura 4.1: Posio do Servidor na Arquitetura
fazendo uso de grcos, imagens ou quaisquer outros meios que tornem a viso do pro-
cesso mais intuitiva ao usurio.
4.2.1 Tela de Superviso
Para desenvolver um mdulo cliente com capacidade de expor as variveis do mtodo
de elevao plunger lift necessrio desenvolver diversas telas que exponham as var-
iveis deste mtodo de elevao. A primeira e mais importante tela desenvolvida a tela
que representa o poo e que concentra as principais informaes do mtodo de elevao,
chamada tela de superviso.
A tela de superviso, alm de exibir os dados de superviso, permite acessar diver-
sas funcionalidades. Alguns exemplos das funcionalidades propostas so: habilitar ou
desabilitar controles PIDs existentes no CLP, fechar ou abrir vlvulas e observar alguns
alarmes especcos do plunger lift.
A tela de superviso uma representao do poo e de seu comportamento. Esta
representao de um poo com o mtodo de elevao plunger lift pode ser vista na gura
4.2 e na gura 4.3, onde a primeira representa um poo sem a presena de dreno enquanto
a segunda representa um poo com o dreno (captulo 2).
Atravs da tela de superviso ainda possvel acessar um conjunto de outras telas para
Figura 4.2: Tela de Superviso Sem Dreno
Figura 4.3: Tela de Superviso Com Dreno
exibir os dados coletados dos controladores. Tais telas so: dados histricos, histrico de
ciclos, alarmes, congurao de poo e comandos avanados.
4.2.2 Histrico
Esta interface exibe todas as informaes adquiridas, de um determinado poo, desde
o ponto onde foi iniciada a superviso deste. Como pode ser visto na gura 4.4, os dados
so exibidos em forma de grco e possvel ltrar os dados para exibir somente uma
faixa de tempo de interesse.
Figura 4.4: Tela de Dados Histricos
4.2.3 Tela de Ciclos
O Histrico de Ciclo possui a funo de exibir os dados recentes do poo. Os dados
recentes do poo so exibidos atravs de uma tabela, onde so apresentados os ltimos 10
ciclos de um determinado poo. Cada ciclo composto das seguintes variveis: o horrio
da aquisio do dado, o Tempo de After-Flow (TAF), Tempo de Fechamento (TF), Tempo
de Viajem do Pisto (TVP), Janela de chegada do Pisto, Fluxo de Gs (QGI), Presso na
Linha de Surgncia (PLS) mnima e mxima, Presso no Revestimento (PRev) mnima
e mxima, Presso na Cabea do poo (PCab) mnima e mxima. possvel observar a
interface na gura 4.5.
Figura 4.5: Tela de Histricos de Ciclos
4.2.4 Congurao do Poo
A funcionalidade de Congurao do Poo tem o objetivo de permitir ao usurio con-
gurar os dados do mtodo de elevao plunger lift remotamente. Cada interface foi
concebida para concentrar os parmetros que possuam caractersticas em comum; como
por exemplo, todos os parmetros relacionados calibrao dos instrumentos estaro con-
centrados na mesma interface.
possvel observar as interfaces grcas desenvolvidas nas guras 4.6, 4.7, 4.8 e 4.9.
Cada gura, apresentada nesta subseco, mostra uma interface que responsvel por
exibir um conjunto de dados que possuem caractersticas em comum.
interessante observar que, nestas telas de congurao, para cada parmetro pos-
svel observar dois valores. Os valores que esto esquerda correspondem aos valores
que esto no controlador neste exato momento, enquanto os valores que esto a direita
correspondem aos valores que esto no banco. O usurio pode alterar somente os da-
dos do banco de dados mas o sistema automaticamente envia uma cpia da informao
modicada para o controlador.
4.2.5 Comandos Avanados
A funcionalidade Comandos Avanados conta com uma srie de comandos para o
poo, que esto disponveis somente a um grupo restrito de usurios. Tais comandos
englobam aes como limpar a memria do controlador, fechar o poo, etc. possvel
observar esta interface grca na gura 4.10
Figura 4.6: Tela de Congurao do Poo 1
Figura 4.10: Tela de Comandos Avanados
4.2.6 Cadastro de Poos
Esta interface grca utilizada para cadastrar novos poos no banco de dados do
supervisrio SISAL.
Na gura 4.11 possvel observar a interface grca de cadastro de um poo para o
mtodo de elevao plunger lift. Esta interface grca subdividida em5 subgrupos difer-
entes: Identicao, Controlador, Fluido e Reservatrio, Grupos de Uso Geral e Plunger
Lift. importante salientar que nesta interface grca s foi desenvolvido o subgrupo
Plunger Lift; todos os outros subgrupos j esto presentes atualmente no SISAL e so re-
sponsveis por especicar dados gerais de cadastro de um poo, enquanto que o subgrupo
Plunger Lift responsvel por cadastrar dados especcos ao mtodo plunger lift.
4.2.7 Comunicao do Cliente-Servidor
De forma simplicada, o cliente do sistema supervisrio SISAL deve possuir duas
capacidades bsicas: exibir os dados e comunicar-se com o servidor para obter tais dados.
As interfaces grcas so responsveis por exibir os dados. A comunicao com o servi-
dor responsabilidade de um conjunto de funes de comunicao, capazes de receber
os dados enviados pelo servidor e trat-los para apresentar na interface grca. Para cada
interface grca foi desenvolvida tambm a funcionalidade de comunicao que permite
Figura 4.11: Tela de Cadastro de um Poo com o Mtodo de Elevao Plunger Lift
ao cliente obter os dados destas interfaces do servidor.
4.3 Mestre de Banco
O mestre de banco o mdulo encarregado de realizar a comunicao com o banco
de dados. O desenvolvimento deste mdulo pode ser dividido nas seguintes linhas de
ao: adio de novas tabelas ao banco, desenvolver novas funes de comunicao com
o servidor e desenvolver a capacidade de compresso de dados.
Novas tabelas do banco de dados foram criadas pois novos e diferentes dados foram
incorporados ao sistema supervisrio.
O desenvolvimento da comunicao entre o servidor e o mestre de banco equivale
ao mesmo trabalho para desenvolver a comunicao entre o cliente e o servidor. Neste
caso foram desenvolvidas diversas funes de comunicao entre o mestre de banco e o
servidor para toda nova comunicao entre os mdulos do SISAL e o banco de dados.
4.3.1 Compresso de Dados
At este trabalho o software SISAL era utilizado somente para a superviso de poos
com o mtodo de elevao bombeio mecnico. No entanto, o volume de dados produzidos
em um poo com este mtodo de elevao muito inferior ao volume de dados produzi-
dos por um poo com o mtodo de elevao plunger lift. Devido a esta constatao e
sabendo que os dados devem ser armazenados em banco de dados, interessante que seja
desenvolvido dentro do mestre de banco a funcionalidade que permita comprimir dados.
De outra forma, o tamanho do banco pode crescer e tornar impraticvel o armazenamento
de dados por um perodo prolongado.
O conjunto de dados que devem ser comprimidos, como pode ser visto na tabela 4.1,
formado por trs tipos de dados: booleanos, reais e inteiros. Os dados inteiros e reais
adquiridos dos controladores se caracterizam por apresentarem uma pequena variao nos
valores, desta forma, os inteiros e reais que so formados por 4 bytes armazenam valores
que variam normalmente de 0 a 1000. Devido faixa de valores limitada destes tipos de
dados possvel representar os dados com uma menor quantidade de bytes, realizando
uma compresso de dados. Alm dos dados de tipo inteiro e real, ainda existem os dados
booleanos que podem ser representados em um nico byte.
Como pode ser visto na tabela 4.1 o nmero de bytes retirados os bytes redundantes
25 enquanto que o nmero de bytes com redundncia de 52, portanto, foi possvel
realizar uma compresso de aproximadamente 52%.
Tabela 4.1: Caractersticas dos dados de compresso
Tipo de dado Nmero de Dados Nmero de Bytes Total de Bytes Bytes Sem Redundncia
Booleano 4 1 4 1
Inteiro 4 4 16 8
Real 8 4 32 16
Total 16 9 52 25
Para aumentar a taxa de compresso os dados resultantes da primeira compresso
so submetidos a uma nova compresso. Esta nova compresso realizada atravs de
um algoritmo de Ruffman modicado disponibilizado pela biblioteca Zlib [Roelofs &
Adler n.d.].
Tabela 4.2: Resultado da compresso utilizando o algoritmo de Ruffman
Poo Amostra Bytes no Comprimidos Bytes Comprimidos Taxa Compresso
1 1 132462 38097 71%
1 2 140994 43404 69%
1 3 232605 61471 74%
2 1 183546 55686 70%
2 2 221562 73794 67%
2 3 67446 24329 64%
3 1 145206 41901 71%
3 2 43227 10679 75%
3 3 94311 25727 72%
Utilizando dados coletados em poos reais foi possvel obter os valores presentes na
tabela 4.2. A taxa mdia de compresso entre os dados de todos os poos cou em torno
de 70%. Se for adicionada ainda a primeira compresso realizada, a taxa de compresso
aumenta para 86%.
4.4 Mestre de Campo
O mestre de campo tem a funo de adquirir os dados dos poos e repass-los ao
servidor. Este mdulo do SISAL o mais especializado, pois possui a incumbncia de
representar os CLPs dentro da arquitetura do SISAL.
Tal como no cliente e no mestre de banco, possvel armar, de forma simplicada,
que o mestre de campo possui duas funcionalidades bsicas. So estas funcionalidades:
comunicar-se com o servidor e comunicar-se com os CLPs. Portanto, para desenvolver
o mestre de campo necessria a realizao das seguintes tarefas: desenvolvimento das
funes de comunicao com o servidor e o desenvolvimento da comunicao com os
CLPs. A segunda tarefa ainda pode ser subdividida em estudo do CLP para determinao
das variveis a serem adquiridas e estudo da comunicao para determinao da forma
mais eciente de realizar a leitura dos controladores. Ainda proposta uma terceira tarefa
para a reestruturao do mestre em termos de engenharia de software para permitir um de-
senvolvimento mais rpido, menos propenso a erros e tornar a manuteno mais eciente.
Por m necessrio modelar a comunicao do mestre de campo com os controladores
para otimizar o funcionamento do sistema.
4.4.1 Comunicao com o Servidor
A comunicao entre o mestre de campo e o servidor consiste em utilizar o protocolo
denido pelo SISAL [de Souza 2005] para enviar os dados que sero lidos pelo cliente
quando os dados chegarem ao seu destino. Portanto, esta atividade consiste em encapsular
os dados para envi-los ao servidor.
Todas as novas funcionalidades criaram a necessidade de novas funes de comuni-
cao com o servidor, as quais foram todas desenvolvidas.
4.4.2 Estudo do Controlador
Esta atividade consistiu em estudar o CLP para determinar quais registradores contm
os dados que esto sendo adquiridos para o sistema supervisrio. possvel observar a
lista de variveis adquiridas pelo sistema supervisrio abaixo.
Dados Atuais So dados adquiridos a cada pooling do sistema para serem exibidos na
tela de superviso do poo. possvel observar tais dados na tela da gura 4.2 na
pgina 25.
Dados de Ciclo So dados que formam um histrico recente dos dados adquiridos do
poo e so exibidos na tela da gura 4.5 na pgina 27.
Dados Histricos So dados armazenados no CLP que representam o histrico propria-
mente dito do poo. Estes dados so exibidos na tela da gura 4.4 na pgina 26.
4.4.3 Estudo da Comunicao
O mestre de campo, alm de ser o elemento mais especializado da arquitetura do
SISAL, tambm o elemento que gerencia a aquisio de dados. A aquisio de dados
deve ser realizada de tal forma que otimize a aquisio das informaes dos poos. Alm
disso, a quantidade de dados gerados em um poo com o mtodo de elevao plunger lift
muito superior quantidade de dados hoje adquirida no supervisrio SISAL. Devido a
estas duas realidades, necessrio alterar a estratgia de aquisio dos diferentes tipos de
dados, necessrios superviso deste mtodo, em relao ao que ocorre hoje no SISAL.
No supervisrio SISAL existem, atualmente, trs tipos de dados pedidos ao poo.
O primeiro consiste em um pedido direto do usurio, o segundo corresponde aos dados
atuais e o ltimo corresponde ao pedido de carta dinamomtrica, j que at este trabalho
o supervisrio era voltado unicamente para a superviso do mtodo de elevao bombeio
mecnico.
Abaixo possvel observar uma breve explicao sobre cada um dos pedidos ao poo
que ocorre atualmente no SISAL.
Pedidos do Usurio Havendo necessidade, o usurio do SISAL pode fazer um pedido
diretamente ao controlador de diversos dados. Para garantir que o usurio seja
atendido o mais rpido possvel, esta categoria de pedido possui uma prioridade
superior a todas as outras.
Dados Atuais So dados adquiridos a todo instante pelo sistema para serem exibidos
na tela de superviso do poo. Antes deste trabalho todos dados eram do mtodo
bombeio mecnico.
Carta Dinamomtrica O pedido carta dinamomtrica consiste somente em um pedido
de dados atuais acrescido do pedido de uma carta dinamomtrica. Ao fazer um
pedido de carta dinamomtrica so adquiridos um nmero de bytes cerca de 10
vezes superior ao pedido nos dados atuais; por isso, esta forma de pedido ocorre
de forma intermitente, por exemplo, a cada 5 pedidos dos dados atuais ocorrer um
pedido de carta dinamomtrica.
Um supervisrio para trabalhar com o mtodo de elevao plunger lift deve trabalhar
com os seguintes pedidos ao poo:
Pedidos do Usurio Tal como ocorre hoje no SISAL os pedidos do usurio so para
observar as variveis presentes no controlador. Ao solicitar um dado o pedido deve
ser atendido com a maior prioridade.
Dados Atuais um conjunto de dados adquiridos a todo instante pelo sistema, sem a
interferncia do usurio, para serem exibidos na tela de superviso do poo. Neste
caso, so exibidos dados do mtodo de elevao plunger lift.
Dados de Ciclo Estes dados tmo objetivo de mostrar o comportamento recente do poo.
Os dados de ciclo so adquiridos em conjunto com os dados atuais. Estes possuem
um tamanho equivalente aos dados da carta dinamomtrica do mtodo de elevao
bombeio mecnico.
Dados de Histrico Estes dados possuem a funo de informar a histria do poo. Os
dados histricos so adquiridos no decorrer do pooling. No entanto, a quantidade
de bytes adquiridos nos dados histricos, no pior caso, da ordem de 100 vezes o
tamanho dos dados de ciclo. Esta diferena ocorre pois a quantidade deste tipo de
dado se acumula no decorrer do tempo no CLP, o que pode gerar uma quantidade
de dados muito superior aos outros tipos de pedidos.
A aquisio de dados, atravs do pedido do usurio e atravs dos dados atuais, sero
executados como ocorre atualmente no SISAL, ou seja, em qualquer momento o sistema
deve fazer a aquisio dos dados atuais e no momento que o usurio solicitar qualquer
pedido, este ser atendido antes do prximo pedido de dados atuais.
Os dados de ciclo possuem um tamanho aproximado ao da carta dinamomtrica. Por
essa razo, a sua lgica de aquisio semelhante utilizada na aquisio da carta di-
namomtrica, ou seja, depois de n pedidos ao conjunto de todos os poos feita a
aquisio dos dados de ciclo.
Existe ainda a possibilidade de otimizar o uso da banda de comunicao ao diminuir o
nmero de pedidos de aquisio dos dados de ciclo, pois, ao contrrio do que ocorre com
uma carta dinamomtrica, os dados de ciclo correspondem aos dados de vrios momentos
acumulados no controlador, at o limite de 10 dados de ciclo. Desta forma, sabendo
quando feita aquisio dos dados de ciclo de um poo, possvel determinar quanto
tempo levaria para que todos os dados de ciclo fossem completados, e s ento adquirir
tais dados. O tempo de aquisio de um dado de ciclo uma informao armazenada no
controlador. Este tempo pode ser adquirido automaticamente pelo mestre de campo, para
calcular o tempo necessrio para adquirir sempre 10 novos dados de ciclo.
Ao contrrio dos dados de ciclo e dos dados atuais, os dados de histrico possuem
um volume de dados armazenados no CLP muito grande, j que os dados histricos so
armazenados dentro do controlador, o que impossibilita a utilizao das estratgias ante-
riores para solucionar o problema. Outro problema enfrentado, para realizar a leitura dos
dados histricos, que estes dados so armazenados em uma memria de tamanho nito
no CLP e quando a memria estiver completamente preenchida qualquer adio de dados
gerar uma perda dos dados mais antigos.
A leitura dos dados histricos deve permitir que todos os dados armazenados na
memria do CLP sejam adquiridos. Quando no for possvel realizar tal tarefa, o usurio
deve ser informado que dados esto sendo perdidos. Apesar da necessidade de obter os
dados de histrico o mais rapidamente possvel, a leitura destes dados no pode ocupar
todo o tempo de transmisso, impedindo que os dados atuais e os dados de ciclo sejam
adquiridos e, principalmente, impedindo que os pedidos do usurio sejam atendidos.
Existem, portanto, dois problemas opostos a serem resolvidos na leitura dos dados de
histrico:
1. No perder os dados na memria do controlador.
2. No impedir que outros tipos dados sejam adquiridos.
Para adquirir os dados histricos semdeixar os dados atuais desatualizados, proposto
um modelo de aquisio de dados atravs de janelas de tempo dinmicas. Na gura 4.12
possvel observar a janela JN, que tem incio quando houver luz do sol e naliza quando
anoitecer. Esta janela, portanto, possui um tamanho xo que depende do tempo de luz
solar durante o dia.
O tempo que leva para todos os poos serem lidos denominado Tempo Total de
Comunicao (TT) e pode variar dependendo do nmero de poos como tambm do
tempo levado para realizar a leitura de um poo. Os tempos P
1
, P
2
e P
n
representam o
tempo para realizar a leitura do poo 1, poo 2 e do n-simo poo, respectivamente.
Figura 4.12: Janelas de Comunicao de Aquisio de Dados
TT =
n
i
P
i
(4.1)
P
i
= T
a,i
+T
h,i
(4.2)
Onde i = 1,2,...,N.
O valor de T
a
, em uma transmisso sem falhas, sempre constante, pois obtm sempre
a mesma quantidade de dados, ao contrrio de T
h
que pode variar dependendo do nmero
de dados histricos pedidos ao controlador.
Tabela 4.3: Denio dos smbolos utilizados neste trabalho
Smbolo Signicado
JN Janela de tempo disponvel para um dia
TT Tempo total comunicao para obter os dados de todos os poos
P
i
Tempo para obter os dados do poo i (segundos)
T
a
Tempo de aquisio dos dados Atuais e de Ciclo (segundos)
T
h
Tempo de aquisio dos dados de histrico (segundos)
T
x
Taxa de produo de dados (dados/segundo)
T
min
Tempo mnimo de aquisio de dados histricos
Controlando o valor de T
h
possvel determinar se a aquisio dos dados dos contro-
ladores vai privilegiar a leitura dos dados histricos ou dos dados atuais. Quanto menor T
h
maior o nmero de perodos TT que aparecero em uma mesma janela JN, o que informa
que os dados atuais esto sendo atualizados numa frequncia maior.
No entanto, para evitar o aumento do nmero de dados histricos no controlador:
T
h,i
> T
min,i
(4.3)
Onde:
T
min,i
= T
x,i
N
j1
P
j
(4.4)
O algoritmo para realizar o clculo do tempo mnimo exibido na gura 4.13.
float MinTempoHistorico(int pocoAtual){
for(i=1 ate numero_Pocos){
if(i != pocoAtual){
TempoMinimo += P[i]
}
}
TempoMinimo = TempoMinimo * Tx[pocoAtual]
return TempoMinimo;
}
Figura 4.13: Rotina para determinar o mnimo tempo para a aquisio de dados histricos
Determinar o tempo mnimo para adquirir os dados histricos impede que os mesmos
sejam perdidos sem o conhecimento dos usurios. Pois quando se tem o tempo mnimo
determinado possvel gerar alarmes aos usurios para que os mesmos sejam alertados
sobre o problema da perda de dados. No entanto, ainda possvel aperfeioar a aquisio
dos dados permitindo que uma quantidade maior de dados histricos possam ser adquiri-
dos em um menor tempo. Para aumentar a quantidade de dados histricos adquiridos
possvel aumentar o tempo de aquisio dos dados histricos em detrimento dos dados
atuais. O favorecimento de um tipo de aquisio em relao ao outro possvel pois
em muitos momentos os usurios no estaro necessitando dos dados atuais o que torna
desnecessria uma freqncia alta na atualizao dos dados atuais.
Na gura 4.14 apresentado umalgoritmo para permitir comportamento adaptativo na
aquisio dos dados histricos e dados atuais. Este algoritmo baseia-se na freqncia dos
pedidos dos usurios para determinar se deve privilegiar a aquisio dos dados histricos
ou atuais. Portanto, quando muitos pedidos forem feitos ao sistema os dados atuais sero
adquiridos com uma freqncia maior. Quando no houver pedidos de dados atuais, por
parte dos usurios, os dados histricos sero privilegiados em relao aos dados atuais.
No algoritmo da gura 4.14 possvel observar que existe um limite de tempo mnimo
para aquisio dos dados histricos j que necessrio esvaziar os dados existentes no
controlador. Da mesma forma que existe um tempo mnimo para a aquisio dos dados
de histrico tambm interessante que exista um tempo mnimo para os dados atuais
(MinTempoDadoAtual) para impedir que os dados atuais quem desatualizados por um
longo perodo de tempo.
void modificaTempoAquisicao(){
TempoDadoAtual = MinTempoDadoAtual + ConstDA * frequencia_requisicoes;
TempoHistorico = TEMPO_MAX - TempoDadoAtual;
if(TempoHistorico < MinTempoHistorico()){
TempoHistorico = MinTempoHistorico();
TempoDadoAtual = TEMPO_MAX - TempoHistorico;
}
}
Figura 4.14: Rotina para modicar taxa de aquisio entre dados histrico e dados atuais
Com o algoritmo apresentado na gura 4.14 possvel determinar se os dados histri-
cos vo ser privilegiados em relao aos dados atuais ou o oposto. No entanto, quando um
poo produzir uma maior quantidade de dados histricos em relao aos outros, no pos-
svel, com o algoritmo da gura 4.14, privilegiar o poo com a maior quantidade de dados.
Para proporcionar uma nova otimizao proposto um algoritmo que divida a quantidade
de tempo total do histrico em partes no iguais entre os poos. Desta forma, os poos
com maior nmero de dados devem receber uma maior parte do tempo de aquisio en-
quanto os poos com menor quantidade de dados recebem um tempo menor.
O algoritmo apresentado na gura 4.15 permite a mudana nos tempos de leitura de
cada poo, permitindo que os poos com a maior quantidade de dados sejam privilegiados
em relao aos poos que possuem uma menor quantidade de dados. Esta mudana
realizada atravs de uma mdia ponderada onde a quantidade de dados de um poo
dividida pela quantidade total de dados de todos os poos e por m e multiplicado pelo
tempo total para leitura de todos os dados histricos.
T
h,i
= (nH
i
/totalHist) TT
h
(4.5)
O algoritmo para aquisio dos dados apresentado na gura 4.15 possui a incumbn-
cia de modicar a relao entre tempo de dados atuais e tempo de dados histricos. O
prximo passo consiste em aumentar o tempo de leitura de histrico dos poos que pos-
suem uma maior quantidade de dados e diminuir o tempo dos poos que possuem poucos
dados. E por m so adquiridos os dados de todos os poos.
void AdquireDados(){
modificaTempoAquisicao();
for(i=1 ate num_poco)
totalDadosHist += DadosPoco[i].numDados();
for(i=1 ate num_poco)
TempoPedido[i]=(DadosPoco[i].numDados/totalDadosHist)*TempoTotalHist();
for(i=1 ate num_poco){
tempoInicial=tempoAtual();
while(tempoInicial-tempoAtual() < TempoPedido[i]){
adquireDadosHistoricos(i);
}
adquireDadosAtuais(i);
}
}
Figura 4.15: Algoritmo para realizar a aquisio dos dados
4.4.4 Reestruturao do Mestre
O software SISAL foi idealizado para trabalhar com vrios mtodos de elevao; no
entanto, o SISAL supervisionava somente poos com o mtodo de elevao bombeio
mecnico. Este fato levou a que a programao do mestre de campo casse, durante este
perodo, muito voltada s necessidades do mtodo de elevao bombeio mecnico. Isso
gerou diculdades na manuteno e desenvolvimento do cdigo, pois tornou o mesmo
muito especco ao mtodo de elevao bombeio mecnico. Portanto, para desenvolver
o mestre de campo para o mtodo de elevao plunger lift, foi necessrio refazer a en-
genharia de software deste mdulo. A reestruturao do mestre consistiu em refazer a
engenharia de software de uma parte do mestre de campo e esta subseo tratar deste
assunto.
De forma simplicada, o mestre de campo pode ser denido em trs mdulos expos-
tos na gura 4.16. A Comunicao com o Servidor desempenhada pelo mdulo de
mesmo nome. O mdulo de Comunicao com Controladores se encarrega de realizar
a comunicao com os controladores, utilizando a rede campo e os protocolos especcos
de cada controlador. O mdulo de Representao dos Controladores tem a funo de
representar os controladores supervisionados, como tambm armazenar temporariamente
os dados adquiridos dos controladores para serem enviados ao servidor.
A interao entre os mdulos acontece com cada pedido recebido no mestre, seguindo
a ordem apresentada na gura 4.16, ou seja, o pedido recebido na comunicao com o
servidor, repassado para o mdulo de representao dos controladores para em seguida
ser feito o pedido pela rede de campo aos controladores.
Figura 4.16: Mdulos do mestre de campo plunger lift
Dos trs mdulos apresentados, a reestruturao deu-se somente no mdulo de rep-
resentao dos controladores. Para armazenar os dados obtidos do campo este mdulo
representa cada poo supervisionado atravs de uma instncia que possui variveis rep-
resentando todos os dados supervisionados. O conjunto destas instncias so agrupados
em um buffer o qual atualizado pelo mdulo de comunicao com os controladores. O
buffer tambm responsvel por fornecer os dados pedidos pelo mdulo de comunicao
com o servidor.
O buffer em questo pode conter representaes de controladores com caractersticas
diferentes. Com isto a estrutura do mdulo de representao dos controladores foi con-
struda, como pode ser visto na gura 4.18, por vrios buffers diferentes. Desta forma,
para cada controlador especco havia um buffer para armazenar seus dados. Por exem-
plo, existindo trs tipos de controladores diferentes para o mtodo de elevao bombeio
mecnico, existiriam trs buffers. Esta estrutura comeou a apresentar problemas me-
dida em que houve um aumento do nmero de controladores diferentes supervisionados
pelo SISAL. Aprincipal diculdade gerada foi o aumento da complexidade para gerenciar
os vrios buffers o que dicultava a insero de novas representaes de controladores,
alm de uma maior diculdade na manuteno do software.
Para desenvolver este trabalho necessrio fazer comque todas as informaes adquiri-
das estejam armazenadas em um nico buffer. Portanto este buffer deve ser capaz de
armazenar dados de todos os mtodos de elevao e tambm de qualquer tipo de contro-
lador. A gura 4.17 mostra como o buffer deve ser formado, ou seja, por vrias instncias
que representammtodos de elevao diferentes ou ummesmo mtodo comcontroladores
diferentes.
Figura 4.17: Buffer do Mestre de Campo para diversos controladores e mtodos de ele-
vao
A possibilidade de agrupar a representao de todos os controladores em um nico
buffer torna mais eciente o desenvolvimento do cdigo. Ao utilizar a estrutura apre-
sentada na gura 4.19, o programador diminui a possibilidade de produzir erros j que
concentra a representao em mdulos que podem ser reutilizados.
Na gura 4.19 possvel observar uma estrutura para representar os controladores com
3 nveis de especicidade, onde o nvel superior representa os dados mais genricos dos
Figura 4.18: Buffer do Mestre de campo antes da reestruturao
controladores, ou seja, os dados sempre requisitados pelo SISAL: o horrio da aquisio
dos dados, a produo do poo, alarmes, etc. Osegundo nvel de especicidade representa
os dados de um mtodo de elevao, tal como, uma carta dinamomtrica para o bombeio
mecnico ou um dado de ciclo para o plunger lift. O terceiro nvel possui a representao
do controlador utilizado no poo onde est sendo realizada a aquisio dos dados, ou seja,
neste nvel esto presentes os endereos de memria do controlador onde esto os dados
a serem lidos ou qualquer outra particularidade de hardware do controlador necessria
superviso.
Para codicar a estrutura da gura 4.19 foram utilizados conceitos de programao
orientada a objetos tais como herana e classe virtual. Na gura 4.19 os nveis mais
baixos representam classes que herdam, das classes representadas pelos nveis superiores,
caractersticas genricas dos mtodos de elevao e dos dados do SISAL.
Para permitir que os dados sejam representados em um nico buffer, como represen-
tado na gura 4.16, foi necessrio utilizar o conceito de classe virtual. Esse conceito de
programao permite criar interfaces para que as classes mais genricas possam utilizar
os recursos das classes mais especcas. Utilizando-se deste recurso possvel criar um
vetor de controladores genricos, que representa todos so poos, mas permite acessar os
recursos especcos das classes que representam os mtodos de elevao e os contro-
ladores reais.
Figura 4.19: Estrutura Existente para cada Controlador
4.4.5 Modelagem em Rede de Petri
Nesta subseo apresentada a modelagem da aquisio dos trs tipos de dados do
mestre de campo: dados atuais, dados histricos e dados de ciclo. A modelagem da
comunicao foi feita utilizando redes de Petri [Cardoso & Valette 1997] que podem ser
observadas na guras 4.20, 4.21 e 4.22. A rede de Petri da gura 4.20 modela a escolha
do tipo de dado que ser adquirido, a rede da gura 4.21 modela a aquisio dos dados
histricos enquanto que na gura 4.22 modelado o envio dos dados de histrico para o
mestre de banco.
As redes de Petri das guras 4.22, 4.21 e 4.20 foram simuladas utilizando o software
Abaixo so exibidos os lugares e as suas correspondentes aes na rede de Petri da
gura 4.20:
Ler_DA: Realizando a leitura dos dados Atuais
Ler_DH: Realizando a leitura dos dados Histricos
Ler_DC: Realizando a leitura dos dados de Ciclo
Num_DA: Representa o nmero de aquisies dos Dados Atuais
Num_DH: Representa o nmero de aquisies dos dados Histricos
Os passos abaixo exibem o comportamento da rede de Petri da gura 4.20. No in-
cio, da rede de Petri da gura 4.20, o nmero de tokens dos lugares L3 e L4 devem
ser respectivamente as constantes N
1
-1 e N
2
para, desta forma, modelar corretamente o
comportamento algoritmico de um if .
Passo 1 A aquisio comea em L2 enquanto a thread de aquisio de dados espera para
iniciar a leitura dos dados atuais.
Ler_DA
Ler_DH
Num_ DH
L1
Num_DA L2
Ler_DC
L3
L4
A
B
N
1
N
1
-1
N
2
N
2
Figura 4.20: Rede de Petri para determinar qual o tipo de dado deve ser lido
Passo 2 retirado um token de L2 e L4 e ento passado para Ler_DA onde iniciada a
leitura dos dados atuais
Passo 3 O token passado para Ler_DH onde iniciada a leitura dos dados histricos.
Este passo visto com maior detalhe nas guras 4.21 e 4.22
Passo 4 Realizada a leitura dos dados histricos um token passa para L1 e um token
adicionado a Num_DH.
Passo 5 Chegando neste passo existem duas possibilidades:
Existe pelo menos umtoken em L3: Umtoken que esta em L1 e L3 e removido
e em seguida realizada uma nova leitura de Dados histricos voltando para
o passo 3.
Existem N
1
tokens em Num_DH: Quando N
1
leituras de dados histricos
foram realizadas adicionado um token em L2 e em Num_DA, informando
quantas leituras de dados atuais foram realizadas.
Passo 6 Quando o token estiver presente em L2 existem duas possibilidades:
Se existir algum token em L4: Retira-se um token de L4 e o token que est em
L2 passa para Ler_DA. Desta forma, realizando uma nova leitura do dados
atuais, o ciclo reiniciado.
Se existem N
2
tokens em Num_DA: Quando N
2
leituras de dados atuais so
realizadas iniciada uma leitura de dados de ciclo.
Passo 7 Finalizada a leitura dos dados de ciclo N
2
tokens so enviados para L4 e um token
enviado para L2, No prximo passo o ciclo de aquisio de dados reiniciado.
A rede da gura 4.20 exibe o comportamento da aquisio de todos os trs tipos de
dados obtidos pelo supervisrio plunger lift, enquanto as redes das guras 4.21 e 4.22
detalham a aquisio e envio dos dados histricos. A rede de Petri da gura 4.21 modela
parte da mesma thread da rede da gura 4.20 enquanto que a rede da gura 4.22 representa
o comportamento de uma segunda thread. A primeira thread encarregada de adquirir
os dados dos controladores enquanto a segunda thread encarregada de envia-los para o
mestre de banco.
Para a comunicao entre as threads so utilizados:
Fifo Uma estrutura onde so armazenados os dados para o envio.
Semaforo Estrutura para proteo dos compartilhados
BufferSize Quantidade mxima de dados que podem ser armazenados antes de serem
enviados.
L1
Erro1
BufferSize
Semaforo
Fifo
A
T1
T2
B
Lugar
Transio Temporizada
Transio Imediata
Figura 4.21: Rede de Petri para thread que adquire dados do sistema
Os passos da aquisio de dados histricos que esto modelados na gura 4.21 so
descritos abaixo:
Passo 1 No momento em que a transio A acionada o sistema efetua a comunicao
com o rdio para obter os dados de histrico. A transio temporizada T1 modela
o tempo levado para obter os dados do atravs do rdio.
Passo 2 No passo dois o semforo de proteo adquirido. iniciada a contagem da
transio T2
Passo 3 Existem duas possibilidades para este passo:
Se o tempo da transio temporizada T2 se encerrar um erro gerado e um
tratamento do mesmo realizado.
Se existem tokens em BufferSize existe espao na la de envio, portanto, os
dados so copiados na estrutura destinada a esse m.
Passo 4 O semforo liberado indicando que os dados podem ser lidos pela thread de
envio.
A rede da gura 4.22 modela o comportamento do envio dos dados histricos ao
mestre de banco e os passos correspondentes a esta interao podem ser visto abaixo:
Passo 1 Quando existir qualquer dado na la de envio (Fifo) o semforo de proteo
dos dados compartilhados adquirido.
Passo 2 No passo dois os dados so lidos. Aps a leitura dos dados o semforo liberado.
Passo 3 Neste passo os dados so enviados para o mestre de banco e emseguida o sistema
aciona as transies temporizadas T1 e T2. A transio T2 modela o tempo de
resposta do retorno da funo, enquanto T1 modela o tempo para considerar que
ocorreu um erro:
Se T1 ocorrer signica que a resposta no chegou e o tratamento deste erro
acionado
Se T2 ocorrer os dados chegaram em segurana ao mestre de banco.
Passo 4 O semforo adquirido novamente.
Passo 5 O espao para o recebimento de mais mensagens liberado junto com o sem-
foro.
Erro2
Altera BuffSize
Espera retorno Funo
Lendo Fifo
BufferSize
Semaforo
Fifo
T1 T2
Lugar
Transio Temporizada
Transio Imediata
Figura 4.22: Thread que envia os dados ao mestre de banco
Captulo 5
Concluses e Trabalhos Futuros
Este trabalho apresentou como foi desenvolvido um mdulo para o software de su-
perviso de mtodos de elevao articial chamando SISAL. Este mdulo capaz de
supervisionar poos com mtodo de elevao plunger lift. A metodologia deste trabalho
subdividiu o problema de desenvolvimento em quatro partes as quais constituem o soft-
ware de superviso SISAL: cliente, servidor, mestre de banco e mestre de campo.
Para o cliente foram desenvolvidas diversas interfaces grcas com o objetivo de ex-
ibir os dados coletados do sistema.
No servidor foram criadas funes de comunicao, do protocolo utilizado no SISAL,
para permitir a troca de dados do mtodo de elevao plunger lift.
Com relao ao mestre de banco, responsvel pela interface entre o banco de dados
e o SISAL, foram realizadas modicaes nas tabelas do banco de dados para salvar as
novas informaes adquiridas. Alm das alteraes no banco de dados foi desenvolvida a
capacidade de comprimir dados pois o mtodo de elevao plunger lift produz um grande
volume de dados. Os resultados dos dados reais comprimidos mostraram uma taxa de
compresso em torno de 86%, o que corresponde a uma taxa satisfatria nesta aplicao.
No mestre de campo, responsvel pela aquisio dos dados dos controladores, foi de-
senvolvida a capacidade de adquirir os dados do mtodo de elevao plunger lift. Omestre
de campo foi desenvolvido seguindo uma nova estrutura de engenharia de software para
tornar mais eciente a sua manuteno. Foram realizados estudos sobre a comunicao
do mestre com os controladores os quais deniram polticas e algoritmos para aquisio
dos dados. Durante os estudos sobre a comunicao foi modelado, atravs de rede de
Petri, a comunicao entre o mestre e o rdio.
Atualmente o mdulo de superviso desenvolvido est supervisionando aproximada-
mente 15 poos. Devido a este pequeno nmero de poos supervisionados no houve a
necessidade de implementar as polticas sugeridas para otimizar a comunicao. Como
trabalho futuro interessante realizar a implementao destas polticas de otimizao para
CAPTULO 5. CONCLUSES E TRABALHOS FUTUROS 51
permitir a superviso de forma eciente de um nmero maior de controladores.
Referncias Bibliogrcas
Assmann, Benno Waldemar (2008), Estudo de estratgias de otimizao para poos de
petrleo com elevao por bombeio de cavidades progressivas, Tese de doutorado,
Universidade Federal do Rio Grande do Norte.
Baruzzi, J.O.A. (1994), Modelagem do plunger lift convencional, Dissertao de
mestrado, Universidade Estadual de Campinas Faculdade de Engenharia Mecnica
Departamento de Engenharia de Petrleo.
Cardoso, Janette & Robert Valette (1997), Redes de Petri, Editora da UFSC.
Chikuni, E. & M. Dondo (2007), Investigating the security of electrical power systems
SCADA, em AFRICON, pp. 1 7.
Daneels, A. & W.Salter (1999), What is SCADA?, em International Conference on Ac-
celerator and Large Experimental Physics Control Systems.
de Souza, Rodrigo B., Joo M. A. Nascimento, Andr L. Maitelli, Heitor P. Gomes &
Adelardo A. D. Medeiros (2006), SISAL - um sistema supervisrio para elevao
articial de petrleo, em Rio Oil & Gas Expo and Conference, Vol. 1, pp. 16.
de Souza, Rodrigo Barbosa (2005), Uma arquitetura para sistemas supervisrios indus-
triais e sua aplicao em processos de elevao articial de petrleo, Dissertao de
mestrado, Universidade Federal do Rio Grande do Norte.
Intanagonwiwat, C., R. Govindan & D. Estrin (2000), Directed diffusion: A scalable and
robust communication paradigm for sensor networks", em the Proceedings of the
6th Annual ACM/IEEE International Conference on Mobile Computing and Net-
working.
Jian, Wu, Cheng Yong & N.N. Schulz (2005), Overview of real-time database manage-
ment system design for power system SCADA system, em Proceedings of the IEEE
SoutheastCon., pp. 62 66.
52
REFERNCIAS BIBLIOGRFICAS 53
Jie, Wu, Yang Jinming, Zhang Song-Guang, Xu Qing & Wu Xiao-Chao (2006), Design of
supervisory system based on CAN bus for wind power plant, em IEEE International
Symposium on Industrial Electronics., Vol. 3, pp. 1679 1682.
Morrow, Stanley J., William Hearn & Ramiro Cisneros (2006), New techniques for
plunger lift in conventional and nonconventional gas, em Society of Petroleum En-
gineers Eastern Regional Meeting, Vol. 1.
Qingquan, Qian & Wu Sitao (2000), Using device driver software in SCADA systems,
em Power Engineering Society Winter Meeting, Vol. 3, pp. 20462049.
Roelofs, Greg & Mark Adler (n.d.), Biblioteca para compresso, http://www.zlib.net/.
Sastry, Chellury, Chi Ma, Michael Loiacono, Nazif Tas & Vladimir Zahorcak (2006),
Peer-to-peer wireless sensor network data acquisition system with pipelined time
division scheduling, em Sarnoff Symposium, 2006 IEEE.
Thomas, Jos Eduardo (2001), Fundamentos de Engenharia de Petrleo, Editora Inter-
cincia.
Vinh, Ich Nguyen, W. Benjapolakul & K. Visavateeranon (2007), A high-speed, low-cost
and secure implementation based on embedded ethernet and internet for SCADA
systems, em Society of Instrumentation and Control Engineers Annual Conference,
2007., Vol. 1, pp. 1692 1699.
Wang, Jun, Hong Wang, Haibin Yu & Aidong Xu (2006), Research of architecture and
scheduling for wireless industrial control system, em Proceedings of the 2006 IEEE
International Conference on Information Acquisition.
Zhao, Feng & Leonidas Guibas (2004), Wireless Sensor Networks, Morgan Kaufmann.

Sistema Supervisório para Poços de Petróleo

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Sistema Supervisório para Poços de Petróleo

Caricato da

Copyright:

Formati disponibili

UNIVERSIDADE DO RIO GRANDE DO NORTE FEDERAL

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

Potrebbero piacerti anche