UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CINCIAS EXATAS E DA TERRA DEPARTAMENTO DE INFORMTICA E MATEMTICA APLICADA CURSO DE CINCIAS

DA COMPUTAO

DESENVOLVIMENTO DE UM SISTEMA DE MONITORAMENTO DE POOS DE PETRLEO EM TEMPO REAL PARA O TESTE DE FORMAO

CLLIO FEITOSA DE SOUZA ORIENTADOR: Prof. Dr. Ivan Saraiva (DIMAP/CCET) CO-ORIENTADOR: Prof. Tarclio Viana Dutra Jr. (DEQ/CT)

Natal, 2004

CLLIO FEITOSA DE SOUZA

DESENVOLVIMENTO DE UM SISTEMA DE MONITORAMENTO DE POOS DE PETRLEO EM TEMPO REAL PARA O TESTE DE FORMAO

Relatrio final de graduao em cincias da computao do departamento de informtica e matemtica aplicada da universidade federal do rio grande do norte como requisito para obteno do ttulo de BACHAREL EM CINCIAS DA COMPUTAO.

NATAL, 2004

Cllio F. de Souza

Este trabalho foi desenvolvido com o apoio da Agncia Nacional do Petrleo, atravs do Programa de Formao de Recursos Humanos N 22 Formao em Geologia, Geofsica e Informtica no Setor Petrleo & Gs Natural na UFRN com especializao em Sistemas em Tempo Real para Otimizao e Automao do Setor Petrleo e Gs Natural.

Cllio F. de Souza

RESUMO
Diversos setores da indstria requerem amparo tecnolgico em grandes propores,

principalmente no setor da indstria de petrleo e gs natural. Da extrao de leo bruto comercializao de produtos, diversas etapas e diferentes tecnologias so acionadas. As atividades relacionadas ao monitoramento de poos de petrleo, tais como, o Teste de Formao de Poos, so de extrema importncia para a tomada de decises rpidas e corretas, com base em dados confiveis nas caractersticas do poo, sendo assim, o desenvolvimento de um sistema embarcado de baixo custo e de fcil instalao que permita o monitoramento em tempo real do Teste de Formao se torna uma soluo vivel e fundamental para a Engenharia do Petrleo atual.

Cllio F. de Souza

ABSTRACT
Many industrys sectors need a technological support in great ratios, manly in the sector industry of oil and natural gas. Of the rude oil extration to the generation and commercialization of products, many stages and diferents technologies are used. The activities related with monitoration of oil wells, like Drill Steam Test, are of extreme importance for the taking of fast and correct decisions, on the base of trustworthy datas on characteristics of well, so the development of a system embedded of low cost and easy installation that allows the monitoration in real time of the Drill Steam Test, if become a viable and basic solution of Oil Engineering of today.

Cllio F. de Souza

SUMRIO
1 2 INTRODUO ............................................................................................................................. 9 ENGENHARIA DO PETRLEO: O CAMINHO DO PETRLEO .............................................. 11 2.1 AVALIAO DE FORMAES ......................................................................................... 16 PERFILAGEM A POO ABERTO............................................................................... 16 PERFILAGEM DE PRODUO.................................................................................. 17 TESTES DE PRESSO EM POOS.......................................................................... 18 TESTE DE FORMAO ............................................................................................. 19

2.1.1 2.1.2 2.1.3 2.1.4 3

SISTEMAS EMBARCADOS ...................................................................................................... 25 3.1 3.2 3.3 3.4 CONCEITO ......................................................................................................................... 25 HISTRIA E FUTURO ....................................................................................................... 26 CARACTERSTICAS DOS SISTEMAS EMBARCADOS ................................................... 27 CONTEXTO COM O TRABALHO ...................................................................................... 29

SISTEMAS DE TEMPO REAL................................................................................................... 31 4.1 CLASSIFICAO DOS SISTEMAS DE TEMPO REAL..................................................... 32

5 6

SISTEMAS DE OPERACIONAIS DE TEMPO REAL ................................................................ 34 MODELAGEM DE SISTEMAS EMBARCADOS DE TEMPO REAL ......................................... 36

7 SISTEMA EMBARCADO DE MONITORAMENTO DE POO PARA O TESTE DE FORMAO...................................................................................................................................... 38 7.1 7.2 7.3 7.4 7.5 CONCEPO E DEFINIO............................................................................................. 38 OBJETIVO .......................................................................................................................... 38 BENEFCIOS SOCIOECONMICOS ................................................................................ 39 ESPECIFICAO............................................................................................................... 39 ELABORAO ................................................................................................................... 42 DEFINIO DA PLATAFORMA DE DESENVOLVIMENTO DO SISTEMA............... 42 PROBLEMAS ENCONTRADOS ................................................................................. 46 SOLUO ADOTADA................................................................................................. 48

7.5.1 7.5.2 7.5.3 7.6

IMPLEMENTAO PARCIAL VERSUS IMPLEMENTAO IDEAL ................................ 49

Cllio F. de Souza

7.6.1 7.7 7.8 8 9

COMPILAO, DEPURAO, SIMULAO ............................................................ 52

MODELAGEM DO SISTEMA (COMPLETA)...................................................................... 53 VALIDAO DA MODELAGEM DO SISTEMA ................................................................. 56

CONCLUSO ............................................................................................................................ 62 REFERNCIAS BIBLIOGRFICAS .......................................................................................... 64

ANEXO I ............................................................................................................................................ 65

Cllio F. de Souza

LISTA DE FIGURAS
Figura 1 Sonda de Poo.................................................................................................................... 13 Figura 2 Esquema de uma coluna tpica de teste de formao. ...................................................... 20 Figura 3 Grficos de presso gerados a cada intervalor de medio do teste de formao ........... 23 Figura 4 Arquitetura de um sistema embarcado de tempo real........................................................ 34 Figura 5 Sistema de Monitoramento de Poo em Tempo Real para o Teste de Formao ............ 39 Figura 6 Ambiente de desenvolvimento do sistema ......................................................................... 45 Figura 7 Email com desenvolvedores do projeto RTEMS/TSIM ...................................................... 47 Figura 8 Site do instituto de pesquisa Gaisler com os preos das verses do TSIM ...................... 48 Figura 9 Cdigo-fonte das rotinas ASR do sistema.......................................................................... 49 Figura 10 Cdigo-fonte da tarefa que simula os sensores de presso do sistema ......................... 50 Figura 11 Cdigo-fonte de acesso (leitura e escrita) do registrador de E/S do Leon ...................... 51 Figura 12 Pgina 33 do Manual do Usurio do Processador Leon .................................................. 51 Figura 13 Cdigo-fonte da tarefa responsvel pelo controle interno do sistema ............................. 51 Figura 14 Diagrama de casos de uso do sistema............................................................................. 53 Figura 15 Diagrama de seqncia do sistema ................................................................................. 55 Figura 16 Diagrama de componentes............................................................................................... 56 Figura 17 Diagrama de Seqncia com restries de tempo........................................................... 58 Figura 18 Rede de Petri de modelagem do sistema......................................................................... 60

Cllio F. de Souza

1 INTRODUO
Nos testes de formaes convencionais, utilizado, para os registros de presso, um formato analgico de medio (carta de metal sendo rabiscada por uma agulha acoplada ao medidor de presso), tendo assim, uma possvel margem de erro na sua leitura e interpretao, isso devido s imperfeies provenientes do formato analgico da prpria carta e condies do meio na qual o teste est inserido. Esse fato pode conduzir a repetio de todo o teste de formao, acarretando assim, um desperdcio adicional de tempo, e conseqentemente, um aumento no custo do projeto do poo. Outro inconveniente desse tipo de teste, que as informaes para anlise s so disponibilizadas ao final de sua fase operacional, ou seja, a carta para anlise dos parmetros do poo deve ser retirada da coluna de perfurao do poo no final do teste, no podendo assim, obter nenhuma informao do reservatrio em anlise, durante a fase operacional do teste de formao. Novamente, isso impacta em um desperdcio de tempo e aumento no custo do projeto do poo de petrleo. Hoje em dia existem empresas especializadas que estudam formas para aperfeioar o teste de formao com a utilizao de equipamentos computacionais. Estes equipamentos auxiliam na obteno dos dados monitorados durante o teste, proporcionando equipe responsvel pelo teste, dados confiveis em tempo real (durante a fase operacional) das caractersticas do poo. Esses equipamentos, em geral, formam, juntamente com outros perifricos de hardware, um sistema embarcado para monitoramento em tempo real dos parmetros do poo. Tecnologias como essa, proporcionam tomadas de decises mais rpidas e precisas durante o teste de formao. neste contexto que se insere a realizao do presente trabalho de pesquisa. O objetivo , ento, o desenvolvimento de um sistema embarcado de baixo custo e de fcil instalao que permita o monitoramento em tempo real do teste de formao durante sua fase operacional. importante que certas decises sejam tomadas durante a operao do teste, pois, com isso, permitido analisar os dados j obtidos e realizar certos ajustes em parmetros e procedimentos durante o teste, procurando diminuir o tempo de funcionamento do teste e maximizar a qualidade das informaes obtidas. Para a realizao deste trabalho, foi necessrio realizar um estudo abrangente da rea de Engenharia do Petrleo. Obter um conhecimento das diversas fases e operaes envolventes na Engenharia do Petrleo atual, assim como, as tecnologias que esto associadas estas fases, foi imprescindvel para a elaborao e execuo deste trabalho. Sendo assim, este trabalho est organizado em sees, onde cada seo aborda um tpico especfico do trabalho. Inicialmente, uma contextualizao da rea de Engenharia do Petrleo explanada, ou seja, os aspectos gerais da Engenharia do Petrleo como um todo ser abordado, desde a fase inicial de descoberta ou indcios do petrleo fase final de transporte, tratamento e refino do petrleo ser contemplado. Em seguida, as sees correntes referenciam a rea de sistemas
Cllio F. de Souza

embarcados, sistemas de tempo real, modelagem de sistemas embarcados de tempo real, explorando os conceitos envolvidos e tambm seus aspectos mais gerais. Por final, a especificao do sistema de monitoramento em tempo real para o teste de formao, proposta deste trabalho, abordado, explicando como se deu sua concepo, elaborao e implementao, assim como, os problemas encontrados durante este trabalho, e qual a soluo adotada diante destes problemas. Ao final do trabalho, sero apresentadas as algumas concluses, consideradas pelo autor, sobre o trabalho. A seqncia das sees proposta para este trabalho, foi tomando por base uma metodologia que facilitasse o aprendizado dos conceitos envolvidos no trabalho, ou seja, procurouse organizar este trabalho de forma a permitir uma boa compreenso para ambas as partes, pessoal da rea do petrleo e o pessoal de computao, dos conceitos at ento pouco explorados pelas reas afins envolvidas neste trabalho.

Cllio F. de Souza

10

2 ENGENHARIA DO PETRLEO: O CAMINHO DO PETRLEO

Diversos setores da indstria requerem amparo tecnolgico em grandes propores, principalmente no setor da indstria de petrleo e gs natural. Nesse setor, investimentos econmicos em grande escala so destinados para tecnologia e desenvolvimento, conseguindo extrair, dos diversos ramos da cincia, as melhores solues possveis para os problemas encontrados. Grandes investimentos atualmente destinam-se pesquisa e desenvolvimento do setor, contribuindo para sua atuao mais eficiente, elevando sua produtividade e reduzindo o impacto de sua atuao. Entretanto, dadas as suas dimenses, o setor precisa lidar com inmeros problemas em aberto e outros novos que surgem com a sua expanso. Problemas que, no setor do petrleo, se encontram bastante diversificados nas mais variadas operaes e atividades na Engenharia do Petrleo atual. Da extrao de leo bruto gerao e comercializao de produtos, vrias etapas e diferentes tecnologias so acionadas. Assim, a operao do setor requer as mais avanadas solues tecnolgicas de acordo com os diversos segmentos da Engenharia do Petrleo. Em suma, os segmentos da Engenharia do Petrleo so: explorao, perfurao, produo, monitorao de poos, transporte, armazenamento, refino e distribuio. O caminho do petrleo, desde as pesquisas para sua descoberta at sua chegada a uma refinaria, passa pelas mos de inmeros especialistas. So gelogos de petrleo paleontlogos, estratgrafos, sedimentlogos, qumicos, geodesistas, geoqumicos, geofsicos, engenheiros mecnicos, eltricos, engenheiros de manuteno, de minas, de perfurao, de completao, de reservatrios, de produo, cada um deles responsvel por uma etapa especfica, falando uma linguagem prpria e utilizando jarges peculiares. O petrleo constitudo, basicamente, por uma mistura de compostos qumicos orgnicos (hidrocarbonetos, compostos orgnicos formados por carbono e hidrognio). O petrleo tem origem a partir da matria orgnica depositada junto com outros sedimentos aplicados a certas condies termoqumicas. Essa matria orgnica basicamente originada de microorganismos e algas que no sofrem processos de oxidao. Para se ter uma acumulao de petrleo necessrio que, aps o processo de gerao, ocorra a migrao e que essa tenha seu caminho interrompido pela existncia de algum tipo de armadilha geolgica. O petrleo, aps ser gerado e ter migrado, eventualmente acumulado em uma rocha que chamada de reservatrio. A descoberta de uma jazida de petrleo uma tarefa que envolve um longo e dispendioso estudo e anlise de dados geofsicos e geolgicos das bacias sedimentares (locais de deposio de sedimentos orgnicos que do origem formao de hidrocarbonetos). Somente aps exaustivo prognstico do comportamento das diversas camadas do subsolo, os gelogos e geofsicos decidem propor a perfurao de um poo, que a etapa que mais investimentos exige em todo processo de prospeco. Um programa de prospeco visa fundamentalmente a dois objetivos: (i) localizar dentro de uma bacia sedimentar as situaes geolgicas que tenham
Cllio F. de Souza

11

condies para a acumulao de petrleo; e (ii) verificar qual, dentre estas situaes, possui mais chance de conter petrleo. No se pode prever, portanto, onde existe petrleo, e sim os locais mais favorveis para sua ocorrncia. A identificao de uma rea favorvel acumulao de petrleo realizada atravs de mtodos geolgicos e geofsicos, que, atuando em conjunto, conseguem indicar o local mais propcio para a perfurao. Todo o programa desenvolvido durante a fase de prospeco fornece uma quantidade muito grande de informaes tcnicas, com um investimento relativamente pequeno quando comparado ao custo de perfurao de um nico poo. A primeira etapa de um programa exploratrio1 a realizao de um estudo geolgico com o propsito de reconstituir as condies de formao e acumulao de hidrocarbonetos em uma determinada regio. Para esse fim, o gelogo elabora mapas de geologia de superfcie com o apoio da aerofotogrametria e fotogeologia, infere a geologia de subsuperfcie a partir dos mapas de superfcie e dados de poos, como tambm analisa as informaes de carter paleontolgicos e geoqumicos. Aps essa primeira etapa, diversos outros tipos de mtodos so utilizados, sendo o principal deles o mtodo da ssmica de reflexo. Este mtodo pode fornecer alta definio das feies geolgicas em subsuperfcie propcias acumulao de hidrocarbonetos, a um custo relativamente baixo. Mais de 90% dos investimentos em prospeco so aplicados em ssmica de reflexo. Os produtos finais so, entre outros, imagens das estruturas e camadas geolgicas em subsuperfcie, apresentadas sob as mais diversas formas, que so disponibilizadas para o trabalho dos intrpretes. O levantamento ssmico inicia-se com a gerao de ondas elsticas, atravs de fontes artificiais, que se propagam pelo interior da Terra, onde so refletidas e refratadas nas interfaces que separam rochas de diferentes constituies petrofsicas, e retornam superfcie, onde so captadas por sofisticados equipamentos de registro. Tanto em terra quanto no mar, a aquisio de dados ssmicos consiste na gerao de uma perturbao mecnica em um ponto da superfcie e o registro das reflexes em centenas de canais de recepo. Todo o conjunto fonte/receptores tem seu posicionamento dinmico definido por levantamentos topogrficos em terra e por radioposicionamento e satlites no mar. Os tipos de receptores que atuam na superfcie da terra so denominados geofones, j os que se encontram no mar, so chamados de hidrofones. Os dados obtidos pelos mtodos ssmicos so interpretados para gerar os mapas estruturais, onde serviram de tomadas de decises por gelogos e geofsicos. Hoje em dia, com o avano desse mtodo, temos o chamado, ssmica tridimensional ou ssmica 3D. Esse mtodo consiste em executar o levantamento dos dados ssmicos e migr-los para computadores de alta performance que realiza o processamento de transformao em dados tridimensionais. Aps todo o levantamento das informaes obtidas na fase de prospeco e os estudiosos decidirem prosseguir com o projeto do poo, temos a perfurao do poo de petrleo. A perfurao realizada atravs de uma sonda, conforme ilustrado na Figura 1 Sonda de poo. Na perfurao,

Cllio F. de Souza

12

as rochas so perfuradas pela ao da rotao e peso aplicado a uma broca existente na extremidade de uma coluna de perfurao, a qual consiste basicamente de comandos (tubos de paredes espessas) e tubos de perfurao (tubos de paredes finas). Os fragmentos da rocha so removidos continuamente atravs de um fluido de perfurao ou lama. O fluido injetado por bombas para o interior da coluna de perfurao atravs da cabea de injeo, e retorna superfcie atravs do espao anular formado pelas paredes do poo e a coluna. Ao atingir determinada profundidade, a coluna de perfurao retirada do poo e uma coluna de revestimento de ao, de dimetro inferior ao da broca, descida no poo. O anular entre os tubos do revestimento e as paredes do poo cimentado com a finalidade de isolar as rochas atravessadas permitindo ento o avano da perfurao com segurana. Aps a operao de cimentao, a coluna de perfurao novamente descida no poo, tendo na sua extremidade uma nova broca de dimetro menor do que a do revestimento para prosseguimento da perfurao. Do exposto, percebe-se que um poo perfurado em diversas fases, caracterizadas pelos diferentes dimetros das brocas.

Figura 1 Sonda de Poo Num projeto de poo real, aps a fase de perfurao do poo, segue a fase de avaliaes de formaes, que imprescindvel na definio da viabilidade ou no de levar o projeto do poo

Procedimentos e mtodos utilizados para encontrar reas em potencial para explorao do petrleo.

Cllio F. de Souza

13

para as fases finais de completao e produo propriamente dita, mas por convenincia avaliaes de formaes ser abordado na seo 2.1 Avaliao de Formaes. Ao terminar a perfurao de um poo, necessrio deix-lo em condies de operar, de forma segura e econmica, durante toda a sua vida produtiva. Ao conjunto de operaes destinadas a equipar o poo para produzir leo ou gs (ou ainda injetar fluidos nos reservatrios) denomina-se completao do poo. Quanto aos aspectos tcnico e operacional, deve-se buscar otimizar a vazo de produo (ou de injeo) e tornar a completao a mais permanente possvel, ou seja, aquela que minimize a necessidade de intervenes futuras para a manuteno do poo. Uma completao tpica de poo consiste basicamente das seguintes operaes: (i) instalao de equipamentos de superfcie. So instaladas a cabea de produo e um conjunto de vlvulas que permitem o acesso ao interior do poo com toda a segurana necessria, para execuo das demais fases; (ii) condicionamento do poo. Uma vez instalados os equipamentos de superfcie, procede-se fase de condicionamento do revestimento de produo e substituio do fluido de perfurao, que se encontra no interior do poo, por um fluido de completao; (iii) canhoneio. Para comunicar o interior do poo com a formao produtora, perfura-se o revestimento utilizando-se cargas explosivas, especialmente moldadas para esta finalidade. A exploso dessas cargas gera jatos de alta energia que atravessam o revestimento, o cimento e ainda podem penetrar at cerca de um metro na formao, criando os canais de fluxo da formao para o poo (ou vice-versa); (iv) instalao da coluna de produo. A coluna de produo constituda basicamente por tubos metlicos, onde so conectados os demais componentes. descida pelo interior do revestimento de produo com as seguintes finalidades bsicas: Conduzir os fluidos produzidos at superfcie, protegendo o revestimento contra fluidos agressivos e presses elevadas; Permitir a instalao de equipamentos para a elevao artificial; Possibilitar a circulao de fluidos para o amortecimento do poo, em intervenes futuras. Aps a fase de completao do poo, podemos objetivamente colocar o poo para produzir. Mas para isso, diversas tcnicas so aplicadas, cada qual especificamente s caractersticas do poo. Essas tcnicas so chamadas de tcnicas de elevao. Quando a presso do reservatrio suficientemente elevada, os fluidos nele contidos alcanam livremente a superfcie, dizendo-se que so produzidos por elevao natural. Os poos que produzem desta forma so denominados de poos surgentes. Quando a presso do reservatrio relativamente baixa, os fluidos no alcanam a superfcie sem que sejam utilizados meios artificiais para elev-los. O mesmo ocorre no final da vida produtiva por surgncia ou quando a vazo do poo est muito abaixo do que poderia produzir, necessitando de uma suplementao da energia natural atravs de elevao artificial. Utilizando-se equipamentos especficos reduz-se a presso de fluxo no fundo do poo, com o
Cllio F. de Souza

14

conseqente aumento do diferencial de presso sobre o reservatrio, resultando em um aumento de vazo. Os mtodos de elevao artificial mais comuns na indstria do petrleo so: Gs-lift contnuo e intermitente (GLC e GLI); Bombeio centrfugo submerso (BCS); Bombeio mecnico com hastes (BMH); Bombeio por cavidades progressivas (BCP).

A seleo do melhor mtodo de elevao artificial para um determinado poo ou campo depende de vrios fatores. Os principais a serem considerados so: nmeros de poos, dimetro do revestimento, produo de areia, razo gs-lquido, vazo, profundidade do reservatrio, disponibilidade de energia, acesso aos poos, distncia dos poos s estaes ou plataformas de produo, equipamentos disponveis, pessoal treinado, investimento, custo operacional,

segurana, entre outros. Cada mtodo apresenta vantagens e desvantagens. Somente aps conhecer com detalhes os quatro mtodos de elevao artificial que se poder optar por um deles para determinado poo. A ltima fase do processo o tratamento ou processamento primrio dos fluidos produzidos. Ao longo da vida produtiva de um campo de petrleo ocorre, geralmente, a produo simultnea de gs, leo e gua, juntamente com impurezas. Como o interesse econmico somente na produo de hidrocarbonetos (leo e gs), h necessidade de dotar os campos (martimos ou terrestres) de facilidades de produo, que so instalaes destinadas a efetuar, sob condies controladas, o processamento primrio dos fluidos, ou seja: Separao do leo, do gs e da gua com as impurezas em suspenso; O tratamento ou condicionamento dos hidrocarbonetos para que possam ser transferidos para as refinarias onde efetuado o processamento propriamente dito; O tratamento da gua para re-injeo ou descarte.

Cllio F. de Souza

15

2.1 AVALIAO DE FORMAES

Esta fase realizada aps a fase de perfurao do poo, ou durante a fase de produo do poo, com o objetivo de avaliar as condies e caractersticas do poo em anlise, para com isso, auxiliar em tomadas de decises por estudiosos e especialistas. Denominam-se Avaliao de Formaes as atividades e estudos que visam definir em termos qualitativos e quantitativos o potencial de uma jazida petrolfera, isto , a sua capacidade produtiva e a valorao das suas reservas de leo e gs. A avaliao de formao baseia-se principalmente na perfilagem a poo aberto, na perfilagem de produo e nos testes de presso em poos (teste de formao). O processo inicia-se com a perfurao do poo pioneiro2, cuja localizao definida no estudo geolgico e geofsico, basicamente a partir de dados ssmicos. Durante a perfurao do poo, vrios indcios podem indicar a possibilidade da presena de hidrocarbonetos numa determinada formao. Esses indcios so observados, dentre outras formas, em testemunhos3 coletados da formao. A pesar dos indcios obtidos durante a perfurao indicarem a presena de hidrocarbonetos na formao, isto no significa que possam ser produzidos economicamente. Somente o teste de formao (isto , somente a colocao do poo em fluxo) poder confirmar, com segurana, a presena de hidrocarbonetos na formao e fornecer dados a respeito das condies de fluxo nas imediaes do poo. Nas prximas sees, so abordados os principais procedimentos de avaliao de formaes que so utilizados pela engenharia de petrleo.

2.1.1 PERFILAGEM A POO ABERTO

O perfil de um poo a imagem visual, em relao profundidade, de uma ou mais caractersticas ou propriedades das rochas perfuradas. Tais perfis, obtidos atravs do deslocamento contnuo de um sensor de perfilagem dentro do poo, so denominados genericamente de perfis eltricos, independentemente do processo fsico de medio utilizado. Existem muitos tipos perfis que podem ser obtidos na perfilagem a poo aberto, todos com o objetivo de melhor avaliar as formaes geolgicas quanto ocorrncia de uma jazida comercial de hidrocarbonetos. Todos estes perfis se baseiam em uma determinada propriedade fsico-qumica da formao em anlise. Dentre os perfis utilizados na perfilagem, temos: Raios Gama (GR): detecta a radioatividade total da formao geolgica. utilizado para a identificao da litologia e de minerais radioativos, e para o clculo do volume de argilas;

Tambm chamado de poo exploratrio, refere-se a primeiro poo com indcios de hidrocarbonetos em uma rea de explorao de petrleo. 3 Fragmentos de rocha extrada do poo em anlise com finalidade de constatar a presena de hidrocarbonetos.

Cllio F. de Souza

16

Induo (ILD): fornece leitura aproximada da resistividade da rocha, atravs da medio de campos eletromagnticos induzidos nas rochas; Snico (DT): mede a diferena nos tempos de trnsito de uma onde mecnica atravs das rochas. utilizada para estimativas de porosidade, deteco de fraturas, apia ssmica para a elaborao do sismograma sinttico e dentre outros.

2.1.2 PERFILAGEM DE PRODUO

A perfilagem de produo feita atravs de perfis ocorridos, aps a descida do revestimento de produo e completao inicial do poo, visando determinar a efetividade de uma completao ou as condies de produtividade do poo. Assim como a perfilagem a poo aberto, a perfilagem de produo, tambm possui diversos perfis cada qual com caractersticas prprias. Os perfis mais utilizados so: Gradiomanmetro: este perfil registra continuamente a densidade da mistura de fluido dentro do poo em funo da profundidade, atravs da medio de presso em dois pontos distintos. Com esse mtodo possvel determinar a contribuio e percentagem de cada fluido (leo e gs) em cada intervalo aberto para produo. Pode ser aplicado em conjunto com outros tipos de perfis. Perfil de densidade: apresenta a densidade do fluido que passa por dentro da prpria ferramenta atravs de um sistema radioativo semelhante ao dos perfis que medem a densidade da formao a poo aberto. Hidrolog: este perfil mede a constante dieltrica do fluido que passa por dentro da prpria ferramenta, indicando a percentagem de gua presente na mistura. Esta indicao baseia-se no fato de que dentre os trs tipos de fluidos (gs, leo, gua) apenas a gua apresenta alta constante dieltrica. Assim, o perfil ajustado para fornecer valores da percentagem de gua numa mistura. Perfil de temperatura: utilizado para registrar a temperatura do fluido do poo. O estudo de anomalias de temperatura pode fornecer diversas indicaes, tais como: intervalos produzidos ou recebendo fluidos, localizao de vazamentos, topo do cimento, altura de fraturas, etc.

Cllio F. de Souza

17

2.1.3 TESTES DE PRESSO EM POOS

Imagine um poo em um reservatrio novo, selado nos seus limites externos. Inicialmente o reservatrio est em equilbrio, isto , e qualquer ponto a sua presso a mesma e igual chamada presso esttica original. Quando o poo colocado em produo (durante um teste, por exemplo), o equilbrio quebrado: a presso menor no poo e vai crescendo medida que se afasta dele em direo aos limites do reservatrio. Quando o volume de fluido produzido pequeno, em comparao ao tamanho do reservatrio, observam-se quedas de presso (em relao presso original) apenas em uma regio prxima ao poo. Neste caso, as presses nas pores do reservatrio mais afastadas do poo permanecem iguais presso original. Com o avano da produo, a regio afetada (onde se observam quedas de presso) vai aumentando e, eventualmente, se propaga para todo o reservatrio. Quando mais fluido retirado maiores so as quedas de presso observadas. O perodo de tempo em que o poo est produzindo chamado de perodo de fluxo. Imagine agora que, aps um certo tempo de fluxo, o poo seja fechado. Embora a vazo de produo seja nula, continuar ocorrendo movimento de fluidos no reservatrio at que no se haja diferena de presso no seu interior. Assim, a presso medida no poo crescer com o passar do tempo e, aps um longo perodo, eventualmente se estabilizar. Esta presso de equilbrio denominada presso mdia do reservatrio4. O perodo de tempo em que o poo est fechado chamado de perodo de esttica ou perodo de crescimento de presso. importante notar que as variaes de presso ao longo do tempo observadas no poo, tanto no perodo de fluxo quanto no perodo de esttica, dependem de trs fatores: 1) das caractersticas do reservatrio (tamanho, propriedades da rocha, etc.); 2) das propriedades dos fluidos nela contidos; 3) do histrico de produo, isso , do perfil de vazo versus tempo. Assim, conhecendo-se as vazes e presses no fundo do poo (monitorados durante um teste) e as propriedades dos fluidos produzidos (obtidos a partir da anlise de amostras coletadas durante o teste), podem ser obtidas informaes a respeito das caractersticas da rochareservatrio. Diversos tipos de teste podem ser programados e executados, dependendo dos objetivos que se esperam alcanar. Dentre os objetivos podem ser citados: identificao dos fluidos contidos na formao; verificao da presso esttica; determinao da produtividade da formao, dos parmetros da formao e do dano da formao, alm da amostragem de fluidos para PVT (Presso, Volume e Temperatura). Existem diversos tipos de testes de presso, sendo cada um deles especficos a um dado objetivo do teste. Os principais so:

Local de acumulao do petrleo dentro da rocha sedimentar em explorao.

Cllio F. de Souza

18

Teste de produo: caracteriza-se pela no-utilizao de vlvula de fundo5. A abertura (perodo de fluxo) e o fechamento do poo (perodo de esttica) so feitos na superfcie. Os registradores so descidos por dentro da coluna atravs de um cabo.

Registro de presso: consiste na descida de registradores de presso a cabo dentro da coluna, para obter presses de fluxo e /ou esttica. Diferentemente dos testes de produo, no registro de presso no se faz medio de vazo na superfcie.

2.1.4 TESTE DE FORMAO

O teste de formao, tambm chamado de Teste da Coluna de Perfurao ou Drill Stem Testing (DST), do ingls, um dos mtodos de avaliao de formao baseado em dados de presso do poo e com ele poder confirmar, com segurana, a presena de petrleo na formao e fornecer dados a respeito das condies de fluxo nas imediaes do poo. Pode ser de dois tipos: a poo aberto ou a poo revestido. Teste de formao a poo aberto: realizado durante a fase de perfurao, antes de se revestir o intervalo. O fato de o intervalo estar aberto faz com que o teste seja curto, devido possibilidade de priso da coluna (decantao de slidos do fluido de perfurao ou desmoronamento da formao), ao risco de entupimento da coluna e ao isolamento precrio do intervalo. Alm da estimativa da capacidade de fluxo, os testes de formao a poo aberto tm grande vantagem de possibilitar a identificao dos fluidos das formaes de interesse antes da descida do revestimento e produo. Teste de formao a poo revestido: caracteriza-se pelo bom isolamento do intervalo de interesse e pelas melhores condies mecnicas do poo. O isolamento entre os diversos portadores de gua ou hidrocarbonetos conseguido pela cimentao do revestimento. As melhores condies mecnicas propiciam tempos para testes suficientes para que todos os objetivos possam ser alcanados, alem dos testes serem mais seguros e menos sujeitos falhas mecnicas. O teste de formao consiste basicamente em: Isolar o intervalo a ser testado atravs de um ou mais obturadores; Estabelecer um diferencial de presso entre a formao e o interior do poo, forando os fluidos da formao a serem produzidos; Promover, atravs da vlvula de fundo, perodos intercalados de fluxo (com medies das vazes de produo na superfcie, se for o caso) e de esttica;
5

Vlvula que permite intervalos variados de fluxo para medies de anlise do reservatrio.

Cllio F. de Souza

19

Registrar continuamente as presses de fundo em funo do tempo durante o teste. A anlise dos dados coletados durante um teste de presso possibilita avaliar o potencial produtivo da formao testada.

Uma coluna de teste de formao composta de um conjunto de ferramentas, escolhidos em funo do tipo de sonda (flutuante, posicionamento dinmico, fixa, etc.), das condies mecnicas do poo (aberto, revestido, direcional, profundidade do intervalo a ser testado, etc.) e dos objetivos do teste. A figura a seguir mostra, esquematicamente, uma coluna tpica de teste de formao.

Figura 2 Esquema de uma coluna tpica de teste de formao.

De baixo para cima a coluna apresenta: Registrador mecnico de presso externo. Constitudo de uma unidade de presso e de uma unidade de registro capaz de registrar continuamente a presso em funo do tempo. O registrador dito externo por registrar somente a presso externa coluna de teste. Tubos perfurados. Permitem a passagem dos fluidos da formao para dentro da tubulao. Obturadores. Quando assentado, suas borrachas vedam o espao anular, isolando a formao da presso hidrosttica do fluido de amortecimento (fluido de perfurao ou de completao) contido no espao anular. Registradores de presso interno inferior. idntico ao registrador externo, registrando, porm as presses por dentro da coluna de teste, abaixo da vlvula testadora.
Cllio F. de Souza

20

Conjunto de vlvulas. Operadas da superfcie permitem a abertura ou fechamento da coluna de teste. Durante a descida da coluna a vlvula de fundo evita a entrada de fluido na coluna de teste.

Registrador de presso acima da vlvula. Idntico aos outros registradores, registra a presso acima da vlvula de fundo. Vlvula de circulao reversa (circulao no sentido do anular para o interior da coluna). Quando aberta no final do teste, conecta o anular com o interior da coluna de tubos, permitindo a remoo dos fluidos produzidos durante o teste.

Tubulao. Coluna de tubos ate a superfcie.

O teste de formao realizado em duas etapas ou fases: a fase operacional do teste, que lida com os procedimentos de manipulao das ferramentas de controle (sonda em superfcie, vlvulas de circulao, vlvulas de segurana, etc.) para melhor obteno dos dados monitorados, esta fase realizada pelo engenheiro de perfurao ou de produo; e a fase de anlise dos resultados do teste, esta realizada pela equipe de anlise de reservatrios.

a) Fase operacional
Esta fase inicia-se com a preparao da coluna de teste. Todos os equipamentos, anteriormente descritos, para uma coluna tpica de teste de formao so instalados. Aps instalao dos equipamentos, a coluna de teste pode ser descida. Antes da descida da coluna, o poo est cheio de fluido de amortecimento (fluido de perfurao ou de completao) com peso suficiente para conter os fluidos das formaes. Durante a descida da coluna, o fluido de amortecimento penetra pelos tubos perfurados e sai pelos orifcios de uma vlvula de desvio (by-pass) localizada acima do obturador. A vlvula testadora esta fechada, e, portanto, a tubulao acima desta mantida vazia. Ao atingir a profundidade desejada no intervalo de teste, a presso hidrosttica exercida pelo fluido de amortecimento, desde a superfcie (onde zero) at a posio de teste (onde mxima), medida, e sendo considerada a presso hidrosttica inicial (PHI). Em seguida so instalados os equipamentos de superfcie (cabea de teste, linhas de surgncia, separador, etc.), que permitiro o controle, a medio e o descarte dos fluidos porventura produzidos. Aps instalao dos equipamentos de superfcie, o obturador assentado, isolando o intervalo a ser testado da presso do fluido de amortecimento. Imediatamente entra em ao um mecanismo de retardo na vlvula de fundo, a qual se abre (que estava inicialmente fechada) aps alguns minutos. Neste instante, o fluido de armotecimento existente abaixo do obturador se expande para dentro da coluna, liberando a formao da presso hidrosttica. Tem incio, ento, o primeiro perodo de fluxo, onde o fluido de amortecimento sobe por dentro da coluna. O valor de PHI cai at PFI (presso de fluxo inicial) quase que instantaneamente, pois a formao comunicada com a presso atmosfrica atravs da coluna vazia.
Cllio F. de Souza

21

 medida que os fluidos vo sendo produzidos, os registradores acusam o aumento da presso devido ao crescimento da quantidade de fluido de dentro da tubulao. Durante os perodos de fluxo, o sopro (deslocamento de ar para fora da coluna devido ao crescimento da quantidade de fluido de dentro da tubulao), que um indicativo da abertura da vlvula e fornece informao qualitativa da vazo, deve ser observado, e se houver produo de lquido ou gs na superfcie, deve-se medi-la. Aps o primeiro fluxo, a vlvula de fundo novamente fechada e o registrador comea a registrar o primeiro crescimento de presso. O ultimo ponto registrado do crescimento de presso denominado PE1 (presso esttica 1). Durante o perodo de fechamento, o registrador acima da vlvula dever registrar uma presso constante e igual ltima presso de fluxo (PFF presso de fluxo final). Prosseguimos a operao, a vlvula de fundo aberta para o segundo perodo de fluxo e, posteriormente, novamente fechada para o segundo crescimento de presso. Ao ser desassentado o obturador, a presso hidrosttica final (PHF) registrada e, medida que a coluna vai sendo retirada do poo, presses hidrostticas decrescentes so registradas at se chegar superfcie. Durante a retirada da coluna feita a circulao reversa. A vlvula de circulao reversa aberta e o fluido de amortecimento bombeado pelo espao anular, recuperando-se os eventuais fluidos produzidos durante o teste. O procedimento termina com a retirada da coluna de testes de dentro do poo, e tambm a retirada da carta de presso (pressure chart) de dentro dos tambores de presso que so acoplados junto aos registradores de presso. As cartas de presso contendo as informaes de todo o teste so repassadas para a equipe de reservatrio que realiza anlises para inferir e tomar decises. A realizao de todos os procedimentos descritos nesta fase gasto, em mdia, 4horas de trabalho contnuo, podendo chegar at a uma carga horria de 1dia de trabalho. Apenas ao final desta fase, as cartas de presso podem ser repassadas e analisadas pela equipe responsvel.

b) Fase de anlise dos resultados

Nessa fase os especialistas em anlises de dados do reservatrio recebem, da equipe de operao, as cartas de presso do final do teste. Das informaes das cartas de presso, podem ser obtidas caractersticas importantes da formao, tais como, presso esttica do reservatrio, permeabilidade efetiva do fluido produzido, transmissibilidade do reservatrio, fator de pelcula (skin factor), raio de investigao do reservatrio, indicaes sobre a existncia de anomalias e principalmente a produtividade do poo.

Cllio F. de Souza

22

Uma carta de presso extrada aps o procedimento operacional do teste, representa um grfico bidimensional das medies de presso do fundo do poo em relao ao tempo medido a cada intervalo da fase operacional do teste. Uma visualizao das cartas de presso para os intervalos de medio durante a execuo da fase operacional do teste de formao pode ser observada nos grficos que seguem:

Figura 3 Grficos de presso gerados a cada intervalos de medio do teste de formao

Neste ponto chegamos a um marco importante deste trabalho de pesquisa, visto que vale salientar a justificativa para sua realizao. O fato de que nos testes de formao convencionais (o analisado acima) utilizado, para os registros de presso, um formato analgico de medio (carta de metal sendo rabiscada por uma agulha acoplada ao medidor de presso), acarreta uma possvel margem de erro em sua leitura e interpretao, isso devido s imperfeies provenientes do formato analgico da prpria carta. Esse fato pode conduzir a repetio de todo o teste de formao, acarretando assim, um desperdcio adicional de tempo, e conseqentemente, um aumento no custo do projeto do poo. Outro inconveniente desse tipo de teste, que as informaes para anlise s so disponibilizadas ao final de sua fase operacional, ou seja, a carta para anlise dos parmetros do poo deve ser retirada da coluna de perfurao do poo no final do teste, no podendo assim, obter nenhuma informao, do reservatrio em anlise, durante a fase operacional do teste de formao. Apenas quando ao trmino da operao, decises precisas podem ser tomadas. Novamente, isso impacta em um desperdcio de tempo e aumento no custo do projeto do poo de petrleo.
Cllio F. de Souza

23

Hoje em dia existem empresas especializadas que estudam formas para aperfeioar o teste de formao com a utilizao de equipamentos computacionais. Estes equipamentos auxiliam na obteno dos dados monitorados durante o teste, proporcionando equipe responsvel pelo teste, dados confiveis em tempo real (durante a fase operacional) das caractersticas do poo. Esses equipamentos, em geral, formam, juntamente com outros perifricos de hardware, um sistema embarcado para monitoramento em tempo real dos parmetros do poo. Tecnologias como essa, proporcionam tomadas de decises mais rpidas e precisas durante o teste de formao. neste contexto que se insere a realizao do presente trabalho de pesquisa. O objetivo , ento, o desenvolvimento de um sistema embarcado de baixo custo e de fcil instalao que permita o monitoramento em tempo real do teste de formao durante sua fase operacional. importante que certas decises sejam tomadas durante a operao do teste, pois, com isso, permitido analisar os dados j obtidos e realizar certos ajustes em parmetros e procedimentos durante o teste, procurando diminuir o tempo de funcionamento do teste e maximizar a qualidade das informaes obtidas. A seguir sero abordados os temas levantados anteriormente e sua contextualizao para a realizao deste trabalho.

Cllio F. de Souza

24

3 SISTEMAS EMBARCADOS
Uma das coisas mais surpreendentes no progresso das ltimas dcadas tem sido o avano dos computadores diante da vida do homem. Hoje em dia, h mais computadores em nossas casas e escritrios do que pessoas que vivem e trabalham ao nosso redor. Ainda hoje, muitos destes computadores no so percebidos pelos seus usurios. O custo do hardware est continuamente em um declive acelerado, enquanto ao mesmo tempo agrega um crescente poder em processamento e funcionalidade. Como resultado, sistemas embarcados que no foram considerados viveis poucos anos atrs esto, de repente, sendo uma soluo efetiva de custo. Sistemas embarcados ou embutidos, do ingls embedded systems esto presentes em praticamente todos os aspectos na vida do homem moderno. Estes sistemas encontram-se numa parceria incontestvel s necessidades atuais do homem moderno, seja s necessidades pessoais ou s encontradas nos diversos setores da indstria. A situao tal que a renda bruta oriunda da venda de microprocessadores de uso prioritrio em computadores deve, em breve, ser superada por aquela derivada da comercializao de micro-controladores, sobretudo em produtos de uso especfico. Solues encontradas por diversos problemas tecnolgicos foram baseadas no forte uso de sistemas embarcadas, sendo cada qual, especfico a um determinado contexto de atuao. Nas sees seguintes, conceituaremos o termo sistema embarcado, citaremos exemplos de tais sistemas presentes na nossa vida, levantaremos um pouco da histria destes sistemas e suas perspectivas para o futuro, discutiremos as suas principais caractersticas, e por fim, sua contextualizao com este trabalho.

3.1 CONCEITO
Um sistema embarcado uma combinao do hardware e software do computador, e possivelmente, outras partes adicionais (equipamentos eletrnicos digitais e analgicos, dispositivos mecnicos, sensores, etc.), que so projetados para desempenhar uma funcionalidade especfica. Eles possuem a mesma estrutura geral de um computador, mas a especificidade de suas tarefas faz com que no sejam nem usados nem percebidos como um computador. Um bom exemplo so os fornos de microondas. Quase sempre presente em nossas casas, e existem milhes deles que so utilizados todos os dias, mas muitas poucas pessoas percebem que um processador e um software esto por trs preparando seu almoo ou jantar. Com outros exemplos temos, o telefone celular, estaes base para comunicao mvel, sistemas de controle automotivos, aparelhos domsticos, sistemas de controle de trfego areo, sistemas para armas militares, linha de controle de produo de automveis, de equipamentos eletrnicos, aplicaes da robtica e automtica, sistemas de misses espaciais, etc. Estes sistemas so diferentes a um computador pessoal utilizado em nossos lares ou escritrios. Muitas pessoas usam o termo computador de propsito geral para fazer a distino
Cllio F. de Souza

25

clara. Os fabricantes de computadores de propsitos gerais no sabem que tipo de cliente ou usurio ir manuse-lo. Um cliente pode us-lo como um servidor de arquivos, um outro pode usar exclusivamente para jogar jogos eletrnicos, e um terceiro pode us-lo como ferramenta de trabalho do dia-dia. Geralmente, um sistema embarcado um componente inserido em um sistema maior. Por exemplo, carros modernos que contm muitos sistemas embarcados. Um sistema para controle de frenagem, um outro para monitorao e controle de emisso de poluentes, e um terceiro para visualizar as informaes do carro num painel digital. Em alguns casos, esses sistemas embarcados so conectados a algum dispositivo de comunicao de rede, mas, certamente, isso no um requisito essencial. Se um sistema embarcado for bem projetado, a existncia do processador e do software, poderiam ser completamente despercebidos pelos seus usurios. Tal como o caso do forno de microondas. Em alguns casos, at seria possvel projetar um dispositivo similar que fosse capaz de realizar a mesma funo, sem o uso de um processador e software. Isso poderia ser feito substituindo essa combinao com um circuito integrado que realiza as mesmas funcionalidades somente pelo hardware. Contudo, muito da flexibilidade perdida ao projetar um dispositivo diretamente no hardware. muito mais fcil mais barato e conveniente mudar em poucas linhas de cdigo do que re-projetar todo circuito em hardware. Muito mais alm, seria a possibilidade de reaproveitar cdigos existentes, que foram previamente desenvolvidos e testados, para desempenhar certas funcionalidades no sistema. Os softwares embarcados devem, para acompanhar o crescimento do hardware, executar as atividades imaginadas para ele no menor tempo possvel. Com isso, sua complexidade aumenta, sendo comum que um software embarcado contenha milhes de linhas de cdigo ou mais.

3.2 HISTRIA E FUTURO

O primeiro sistema embarcado no poderia ter aparecido antes de 1971. Naquele ano a Intel (fabricante de microprocessadores) introduziu o primeiro microprocessador do mundo. Esse chip, o 4004, foi projetado para uso na linha de mquinas de calcular produzida pela companhia japonesa Busicom. Em 1969, Busicom pediu a Intel para projetar um conjunto especifico de circuitos integrados um para cada modelo das novas mquinas de calcular. O chip 4004 foi a resposta da Intel. Ao invs de projetar os circuitos de hardware um para cada modelo de mquina, a Intel props um circuito de propsito geral que poderia ser usado por qualquer linha ou modelo de mquina de calcular. Esse processador de propsito geral foi projetado para ler e executar um conjunto de instrues software armazenados num chip de memria externo. A idia da Intel era que o software poderia dar para cada calculadora seu nico conjunto de especificaes. Esse microprocessador foi um imenso sucesso, e seu uso cresceu rapidamente na dcada seguinte. As primeiras aplicaes embarcadas de que se tem noticia foram os satlites espaciais no tripulados pelo homem, sistemas de controle de trfego urbano, sistemas de controle de trfego areo. Em
Cllio F. de Souza

26

meados de 1980, sistemas tranqilamente passaram a era dos microcomputadores e trouxeram os microprocessadores em toda parte de nossas vidas pessoais e profissionais. Muitos dos dispositivos eletrnicos em nossas cozinhas (forno de microondas, torradeiras eltricas), salas de estar (televiso, controle remoto) e locais de trabalho (aparelhos de fax, pagers, impressoras a laser, caixas eletrnicos, leitores de cartes de crdito) so sistemas embarcados. Parece inevitvel que o nmero de sistemas embarcados continuar a crescer rapidamente. J existem promessas para novos sistemas embarcados com enorme potencial para o mercado: dispositivos de iluminao e termostatos que podem ser controlados por um computador central sob comando de voz, geladeiras com computadores incorporados num painel frontal que conectados a um dispositivo de comunicao remota capaz de realizar as compras dos produtos que esto faltando e realizar o pagamento ao conectar o sistema bancrio do usurio, sistemas inteligentes de air-bag que no inflam quando uma criana est presente, sistema de navegao de bordo em automveis, pagers, PDAs e celulares com funcionalidades adicionais, sistemas de segurana que utilizam a identificao pela ris do olho, impresso digital do polegar, ondas sonoras da voz, etc. notvel que a utilidade para os sistemas embarcados so quase que imaginveis, e que profissionais dessa rea ser de grande valia pelo mercado.

3.3 CARACTERSTICAS DOS SISTEMAS EMBARCADOS

Ao contrario de um software para computadores de propsito geral, um software de um sistema embarcado no pode geralmente rodar em outro sistema embarcado sem significativas alteraes. Isso porque cada sistema embarcado possui um conjunto de dispositivos de hardware especficos para um determinado contexto na qual o sistema est inserido, ou seja, o hardware de um sistema embarcado especifico para uma aplicao. Nessa seo veremos quais dispositivos de hardware so comuns em quase todos os sistemas embarcados, assim como, outras caractersticas importantes em se tratando de sistemas embarcados. Por definio todo sistema embarcado contm um processador e um software. Mas certamente, para se ter um software necessrio de um local para ser armazenado o cdigo executvel e um outro local para armazenar os dados manipulados em tempo de execuo. Isso leva a termos em um sistema embarcado dois tipos de memria: memria ROM e RAM, respectivamente. Se pouco de memria e requerido, a memria pode estar contida no mesmo chip junto com o processador, caso contrrio, um ou ambos os tipos de memria residir em chips externos de memria. Todo sistema embarcado contm algum tipo de entrada e sada. Por exemplo, no forno de microondas a entradas o teclado alfanumrico no painel frontal, e a sada um display indicando o tempo da operao. Quase sempre as sadas dos sistemas embarcados so em resposta a um evento de entrada. As entradas dos sistemas embarcados so geralmente sensores, sinais de comunicao com o meio ou controle de botes. As sadas so tipicamente displays, sinais de comunicao (LEDs), ou alteraes ao meio na qual o sistema est inserido.
Cllio F. de Souza

27

Com exceo destes poucos componentes, o resto dos componentes de hardware de um sistema embarcado nico. Cada sistema deve conhecer o conjunto de requisitos e conter os dispositivos de hardware necessrios para compor o sistema. Outros aspectos ao projetar um sistema embarcado devem ser considerados: Poder de processamento: o quanto de processamento ser necessrio para executar a tarefa que foi designada. Uma forma comum de medir o poder do processador a taxa em MIPS (Millions of Instructions Per Second). Se dois processadores tm um taxa de 25 MIPS e 40 MIPS, o ltimo dito mais potente dentre os dois. Contudo, outras importantes especificaes para os processadores devem ser consideradas. Uma delas o tamanho dos registradores, que tipicamente trabalha a uma faixa de 8 a 64 bits. Os computadores de propsito gerais usam exclusivamente processadores de 32 e 64 bits, mas os sistemas embarcados era at ultimamente projetado para processadores com 8 ou 16 bits; Memria: o quanto de memria (ROM e RAM) requerido para armazenar o software executvel e manipular dos dados em execuo. O quanto de memria requerida pode tambm depender do tipo do processador selecionado. Em geral, o tamanho dos registradores do processador estabelece o limite mximo da memria que pode ser acessada (por exemplo, um registradores de endereo de 8 bits pode enderear posies de memria ate 256 = 28); O custo de desenvolvimento: o custo em projetar o hardware e software. Esse custo deve ser o mnimo possvel, para alcanar o custo de produo do hardware que vem diminuindo gradativamente nos ltimos anos. Tempo de desenvolvimento: o quanto tempo se leva para projetar os requisitos de hardware e software do sistema. Esse fator tambm chamado de time-tomarket de fundamental importncia, e muito tem sido feito para reduzir o tempo necessrio para que o produto seja migrado da idia inicial ao mercado. Como conseqncia, vertentes relacionadas ao projeto de sistemas embarcados tm crescido ultimamente, como por exemplo, desenvolvimento baseado em plataforma, reutilizao de componentes, projeto de sistemas operacionais embarcados, modelagem de especificaes de hardware e software seguindo a UML (Unified Modelling Language) para sistemas embarcados, etc. Neste trabalho voc pode encontrar assuntos referentes aos sistemas operacionais utilizados nos sistemas embarcados, e tambm aspectos de modelagem de especificaes de hardware e software para sistemas embarcados e na bibliogrfica voc pode encontrar mais a respeito sobre os demais assuntos. Expectativa de vida: o quanto de tempo o sistema deve permanecer funcionando sem sofrer alteraes. Isso afeta os outros aspectos at ento levantados, ou seja,

Cllio F. de Souza

28

decises dos componentes de hardware do sistema, o custo e tempo de desenvolvimento; Confiana: o quanto seguro e confiante o sistema deve ser. Isso ir depender da aplicao que o sistema foi projetado para desempenhar, ou seja, se um brinquedo de criana, vdeo game, por exemplo, o sistema no precisa ser totalmente seguro, confiante, caso uma falha ocorra, no implica em um dano grave. Mas se o sistema embarcado for parte de um sistema de controle areo, ou um sistema de monitoramento de pacientes em UTI, esses tipos de sistemas devem no podem falhar, eles devem funcionar correto a todo tempo, um simples descuido pode causar um dano irreparvel. Aspectos temporais: o quanto de tempo que o sistema embarcado deve responder a certos eventos do mundo real. E o quanto critico o no cumprimento dos prazos estabelecidos. Sistemas que possuem esse tipo de restrio so os chamados sistemas de tempo real. Esse tpico ser abordado na seo 4 Sistemas de Tempo Real. Plataforma de desenvolvimento versus plataforma alvo: definir a plataforma de desenvolvimento e a plataforma alvo. A plataforma de desenvolvimento (host plataform, do ingls) consiste no conjunto de ferramentas necessrias para projetar o componente de software do sistema embarcado. Dentre as ferramentas necessrias, temos: sistema operacional de propsito geral - SOPG, linguagem de programao, compilador multi-plataformas (cross-compiler, do ingls),

depuradores, simuladores da plataforma alvo, etc. Neste caso, um SOPG permite um melhor e mais completo ambiente de desenvolvimento, pois tipicamente possui mais recursos do que a plataforma alvo. Entretanto, a depurao exige o sistema operacional de tempo real - SOTR e as caractersticas da plataforma alvo. Isso obtido atravs de simuladores disponveis para a plataforma alvo, ou a prpria plataforma alvo. A plataforma alvo, tambm chamada, target plataform, como j citado anteriormente, so todos os componentes de hardware e software que iro compor o sistema embarcado (microprocessador, sinais de comunicao, conversores de sinal digital-analgico e vice-versa, sensores e atuadores, meios de comunicao, SOTR, etc.). A plataforma de desenvolvimento utilizada para realizao deste trabalho, pode ser vista na seo 7 Especificao do Sistema de Monitoramento de Poo para o Teste de Formao.

3.4 CONTEXTO COM O TRABALHO

O uso de sistemas embarcados na indstria do petrleo est atingindo propores significativas tanto em relao magnitude dos problemas envolvidos quanto ao seu uso cada vez
Cllio F. de Souza

29

mais crescente. Dentre algumas aplicaes de sistemas embarcados que podem ser aplicadas/encontradas na indstria do petrleo, temos: sistemas de deteco e controle de vazamentos em dutos de petrleo, conhecido na literatura por pig, estes sistemas utilizam uma ferramenta de monitorao que inserida por dentro do tubo e, sendo condicionada pelo prprio leo, capaz de realizar a monitorao de vazamentos em dutos de leo de forma precisa e em tempo real transmitir as informaes do meio a uma estao de apoio; sistemas que auxiliam a perfurao de poos de petrleo em algas profundas, atravs de robs monitorados em superfcies; sistemas capazes de prover mecanismos automticos de posicionamento global em navios de plataformas de perfurao em algas profundas, evitando danos durante a perfurao do poo. Considerando as inovaes tecnolgicas que os problemas da indstria do petrleo esto recorrendo, a utilizao de sistemas embarcados para monitorao e controle do meio vem a se tornar um amparo tecnolgico bastante significante para a engenharia do petrleo atual como um todo. Sendo isto, o entusiasmo maior para a realizao deste trabalho de pesquisa, ou seja, vislumbrar uma aplicabilidade de sistemas embarcados na rea do petrleo e estudar meios para compreenso e soluo de um problema especfico. nisso que se fundamenta este trabalho de pesquisa, i.e, propor a soluo de um problema particular da indstria do petrleo atravs do uso de um sistema embarcado de monitorao de poos de petrleo capaz de monitorar, em tempo real, determinados parmetros para o teste de formao.

Cllio F. de Souza

30

4 SISTEMAS DE TEMPO REAL

Sistemas de tempo real so uma subclasse dos sistemas embarcados, mas nem todo sistema de tempo real um sistema embarcado. Existem algumas definies erradas para sistemas de tempo real. Sistemas de tempo real no exatamente um sistema que rpido, ou que possui alta taxa de processamento. Por definio, um sistema de tempo real um sistema computacional que tem restries temporais, i.e, deve reagir a estmulos do meio em prazos (deadline, do ingls) especficos. O atendimento desses prazos resulta em requisitos de natureza temporal sobre o comportamento desses sistemas. Em conseqncia, em cada reao, os sistemas de tempo real devem entregar um resultado correto dentro de um prazo especfico, sob pena de ocorrer uma falha temporal. O comportamento correto de um sistema de tempo real, portanto no depende s da integridade dos resultados obtidos (correo lgica ou correctness, do ingls) mas tambm dos valores de tempo em que so produzidos (correo temporal ou timeliness). Uma reao que ocorra alm do prazo especificado pode ser sem utilidade ou at representar uma ameaa. A maior parte das aplicaes de tempo real se comporta ento como sistemas reativos com restries temporais. A reao dos sistemas de tempo real aos eventos vindo do ambiente externo ocorre em tempos compatveis com as exigncias do ambiente e mensurveis na mesma escala de tempo. A concepo do sistema de tempo real diretamente relacionada com o ambiente na qual est relacionado e com o comportamento temporal do mesmo. Existem tambm situaes nas quais as restries temporais no so impostas pelo comportamento dinmico de um eventual sistema a controlar, mas pelas exigncias dos servios a serem oferecidos a um usurio humano ou computacional (por exemplo, no caso de transmisso de dados multimdias pela rede). Nesses casos utiliza-se a noo de servios de tempo real como sendo um servio que deve ser oferecido dentro de restries de tempo impostas por exigncias externas ao prprio sistema computacional. Portanto, podemos encontrar em bibliografias da rea, definies mais genricas, como em: Um Sistema de Tempo Real deve ser capaz de oferecer garantias de correo temporal para o fornecimento de todos os seus servios que apresentam restries temporais [9]. Uma das crenas mais comuns que o problema de tempo real se resolve pelo aumento da velocidade computacional. A rapidez de clculo visa melhorar o desempenho de um sistema computacional, minimizando o tempo de resposta mdio de um conjunto de tarefas, enquanto o objetivo de um clculo em tempo real o atendimento dos requisitos temporais de cada uma das atividades de processamento caracterizadas nesses sistemas. Ter um tempo de resposta curto, no d nenhuma garantia que os requisitos temporais de cada processamento no sistema sero atendidos. O desempenho mdio no tem importncia para o comportamento de um sistema composto de diversas atividades com restries temporais. Mais do que a rapidez de clculo, para os sistemas de tempo real, importa o conceito de previsibilidade.
Cllio F. de Souza

31

Um sistema de tempo real dito ser previsvel no domnio lgico e no domnio temporal quando, independentemente de variaes ocorrendo em nvel de hardware, da carga e de falhas, o comportamento do sistema pode ser antecipado, antes da sua execuo. Para se poder prever a evoluo de um sistema de tempo real e garantir dentro de certos limites as suas restries temporais, necessrio definir um conjunto de hipteses sobre o comportamento do ambiente externo no que diz respeito carga e as falhas: Hiptese de carga: determina o que corresponde a carga computacional de pico (carga mxima) gerada pelo ambiente em um intervalo de tempo; Hiptese de falhas: descreve as situaes e freqncias das falhas com os quais o sistema deve conviver em tempo de execuo, continuando a atender os seus requisitos temporais. Portanto, sendo rigoroso, para se assumir a previsibilidade de um sistema ou servio de tempo real, precisa-se conhecer a priori todo o comportamento do sistema, levando-se em conta a pior situao de carga, e simultaneamente, com as hipteses de falhas. Ainda mais, para a garantia da previsibilidade no somente a carga computacional e as hipteses de carga devem ser conhecidas, mas tambm um conjunto de outros fatores ligados arquitetura de hardware e software do sistema. Ou seja, os tempos gastos, no pior caso, na execuo de cdigos da aplicao (tempo de computao) e em funes de suportes devem ser perfeitamente conhecidos ou determinados previamente. Esses tempos limites so necessrios nas anlises e verificaes do comportamento temporal do sistema de tempo real. Os aspectos do hardware tambm influenciam sobe a previsibilidade de comportamento dos sistemas de tempo real. Na literatura em estudo para realizao deste trabalho, foram encontradas diversas formas que tomadas de decises no hardware dos sistemas embarcados dificultam a determinao dos tempos de computao no pior caso e conseqentemente a anlise da previsibilidade. Mas esse tipo de aspecto foi desconsiderado para elaborao deste trabalho. Diante do exposto acima, importante enfatizar que em cada etapa do ciclo de desenvolvimento de um sistema de tempo real, torna-se necessrio o uso de ferramentas e metodologias apropriadas que permitam verificar o comportamento do sistema e sua implementao como previsveis. A previsibilidade o requisito necessrio que deve ser introduzido aos sistemas convencionais para se poder atender aplicaes de tempo real, em particular quando estas apresentam requisitos temporais rgidos ou crticos, como veremos a seguir.

4.1 CLASSIFICAO DOS SISTEMAS DE TEMPO REAL

Os sistemas de tempo real podem ser classificados a partir do ponto de vista da segurana em: (i) sistemas no crticos de tempo real, ou brandos, ou soft, do ingls, quando as conseqncias de uma falha devidas ao tempo so da mesma ordem de grandeza que os benefcios do sistema em operao normal, ou seja, caso haja uma falha em algum prazo do
Cllio F. de Souza

32

sistema isso no tem uma implicao grave. Como exemplo de sistema de tempo real no critico, temos: sistema de comutao telefnico, sistema de processamento bancrio, servios de transmisso de dados multimdia pela rede. (ii) sistemas crticos de tempo real, ou duros, ou hard, quando as conseqncias de pelo menos uma falha temporal excedam em muito os benefcios normais do sistema. Exemplos de sistemas de tempo real crtico so: sistemas de controle de vo, sistema de sinalizao de ferrovias, sistema de controle de planta nuclear, sistema de monitoramento de paciente em UTI. Neste caso, uma falha dita catastrfica. O fato dos prazos ser considerados crticos ou brandos depende do contexto do sistema como um todo no qual o sistema embarcado est inserido. Uma aplicao de tempo-real pode ser composta por componentes de software e de hardware para tempo real, como citado anteriormente aspectos de hardware do sistema de tempo real pode afetar a sua previsibilidade. Um tpico exemplo de um sistema de tempo-real crtico com requisitos de hardware e software para tempo real um sistema de controle de reator nuclear que deve no somente detectar falhas no sistema, mas como responder rpido o suficiente para evitar uma catstrofe. Essa aplicao deve ter requerimento de software para tempo-real crtico, assim como os componentes de hardware do sistema responsveis por acionar o alarme, devem ser capazes de responder a um tempo limite para que o operador possa interagir com o sistema de controle da usina de modo que se evite um dano maior.

Cllio F. de Souza

33

5 SISTEMAS DE OPERACIONAIS DE TEMPO REAL

Em geral, aplicaes so construdas a partir dos servios oferecidos por um sistema operacional. No caso das aplicaes de tempo real, o atendimento dos requisitos temporais depende no somente do cdigo da aplicao, mas tambm da colaborao do sistema operacional no sentido de permitir previsibilidade ou pelo menos um desempenho satisfatrio. Sistemas operacionais de tempo real (SOTR) so sistemas operacionais onde especial ateno dedicada ao comportamento temporal. Em outras palavras, so SOs cujos servios so definidos no somente em termos funcionais, mas tambm em termos temporais. Certos autores diferenciam o termo SOTR de ncleo de tempo real (kernel), afirmando que os ncleos de tempo real oferecem uma funcionalidade mnima, mas so capazes de apresentar excelente comportamento temporal em funo de sua simplicidade interna. Nesse trabalho essa diferenciao no ser feita. Alm do aspecto temporal, algumas funcionalidades especficas so normalmente exigidas em um SOTR. Estas exigncias decorrem do fato da maioria das aplicaes de tempo real serem construdas como programas concorrentes. Logo, conveniente que o SOTR fornea as abstraes necessrias, isto , tarefas e mecanismos para comunicao e sincronizao entre tarefas, tratamento de interrupes internas e externas, gerenciamento de memria, interfaces de E/S com o meio externo, algoritmos de escalonamento de tempo real, etc. Diminuindo com isso, o custo e tempo de desenvolvimento dos sistemas embarcados. A arquitetura de uma aplicao de tempo real embarcada com o uso de sistemas operacionais de tempo real pode ser ilustrada na figura abaixo: Aplicao (SW Embarcado)

SOTR

Devices Drivers

Plataforma (HW Alvo)

Figura 4 Arquitetura de um sistema embarcado de tempo real

Para prover as funcionalidades de um sistema embarcado de tempo real, e ao mesmo tempo, diminuir o custo e tempo do desenvolvimento do software embarcado para monitoramento de poo, foi utilizado, para realizao deste trabalho, um sistema operacional de tempo real disponvel para a plataforma de hardware alvo especificada. Esses, e outros aspectos
Cllio F. de Souza

34

relacionados ao trabalho sero abordados na seo 7 - ESPECIFICAO DO SISTEMA EMBARCADO DE MONITORAMENTO DE POO PARA O TESTE DE FORMAO.

Cllio F. de Souza

35

6 MODELAGEM DE SISTEMAS EMBARCADOS DE TEMPO REAL

Um sistema embarcado algo muito complexo que envolve camadas diferentes. A primeira camada a camada de hardware, que fornece os requisitos mnimos de componentes de hardware para a aplicao; na camada mais superior, temos a camada de software, que prover toda funcionalidade lgica da aplicao; entre estas duas camadas, temos a camada de infraestrutura, como por exemplo, o sistema operacional de tempo real. Nesse modelo em multicamadas, cada camada corresponde a uma camada diferente de abstrao, isso bastante familiar no domnio de protocolos de rede de computadores, onde existem vrias camadas sobrepostas, e a mais inferior oferece servio camada imediatamente superior a esta. Para atingir uma boa especificao do projeto baseado em camadas, h a necessidade de utilizar uma notao padronizada, de forma que todas as camadas sejam bem representadas e compreendidas. A UML Unified Modeling Language tem sido reconhecida como uma linguagem padro de modelagem de sistemas complexos, provendo um canal de comunicao entre os projetistas e clientes do sistema. A UML uma linguagem de modelagem de propriedade da OMG Object Management Group. A verso inicial da UML V1.1 foi lanada em 1997, desde ento muito tem sido feito para padronizao da UML para modelagem e especificao de sistemas computacionais. Hoje em dia, com a proposta da UML 2.0, possvel modelar tanto as especificaes do software como dos aspectos de hardware envolvidos no sistema, considerando para tais aspectos relevantes de sistemas de tempo real, como os j citados anteriormente. O propsito da UML permitir ao usurio definir um modelo de sistema que seja integrado, coerente atravs de um conjunto de abstraes que representam o sistema a ser implementado. A UML prov de modelos abstratos para especificar/detalhar o sistema a ser implementado, sobre duas vises: a viso esttica, onde abstraes do modelo representam aspectos de componentes do sistema, o que o sistema possui, mas no como os mesmos componentes se relacionam; e vises dinmicas, cabendo representar o comportamento dinmico do sistema atravs dos diversos relacionamentos entre seus componentes. Os modelo abstratos so chamados, na UML, de diagramas. Os diagramas que possuem uma viso esttica do sistema so: diagrama de casos de uso especificam as funcionalidades do sistema; os diagramas de componentes especificam como o sistema ser integrado atravs de seus componentes no ambiente real de operao; diagrama de classes do sistema especificam a modelagem dos componentes de software do sistema, etc. Os diagramas que representam o comportamento dinmico do sistema so: diagramas de seqncias especificam os eventos e trocas de mensagens entre os diversos objetos do sistema; diagramas de estados representam os possveis estados do sistema; diagramas de atividades representam os fluxos das atividades envolvidas no sistema, etc.

Cllio F. de Souza

36

A modelagem do sistema de monitorao de poos para o teste de formao pode ser encontrada na seo 7.7 Modelagem do Sistema.

Cllio F. de Souza

37

7 SISTEMA EMBARCADO DE MONITORAMENTO DE POO PARA O TESTE DE FORMAO 7.1 CONCEPO E DEFINIO
O sistema embarcado de monitoramento de poo para o teste de formao surgiu como interesse a um dos assuntos abordados na disciplina Introduo Engenharia do Petrleo, ministrada pelos professores Jos Romualdo Dantas Vidal e Tarcilio V. Dutra Jr., dentro do programa de recursos humanos (PRH) da ANP. Interesse tal que levou a mais pesquisas sobre o assunto (pesquisas em livros acadmicos da rea, trocas de informaes com pessoas especializadas na rea, etc.) e definio final deste trabalho de pesquisa. Esse sistema pode ser visto como uma ferramenta computacional de auxlio aos engenheiros de operao e de anlise em reservatrios, para otimizar todo o processo operacional do teste de formao em relao ao mtodo convencional do teste, possibilitando analisar os dados obtidos de maneira clara e objetiva em tempo real, assim como, possibilitando realizar ajustes em parmetros e procedimentos durante o teste, visando diminuir o tempo de funcionamento e maximizar a qualidade das informaes obtidas. O intuito auxiliar e no automatizar o teste, visto que, os procedimentos da fase operacional so imprescindveis execuo do teste de formao.

7.2 OBJETIVO
O objetivo do sistema possibilitar a coleta, transmisso e visualizao de dados em tempo real de parmetros do poo que so monitorados durante a fase operacional do teste de formao. Esses dados so coletados no fundo do poo e transmitidos superfcie onde possvel um acompanhamento preciso do estado atual do teste com base nos dados monitorados no fundo do poo em tempo real. Uma figura Esquemtica do Sistema de Monitoramento de Poo em Tempo Real para o Teste de Formao pode ser visualizada abaixo:

Cllio F. de Souza

38

Figura 5 Sistema de Monitoramento de Poo em Tempo Real para o Teste de Formao

7.3 BENEFCIOS SOCIOECONMICOS

Realizar uma monitorao em tempo real para testes de formao implica, substancialmente numa reduo de tempo, isto em comparao ao tempo gasto em relao aos testes convencionais que so realizados. Uma reduo do tempo, impacta na reduo do custo total do teste, gasto em equipamentos e recursos humanos alocados para atividade e, conseqentemente, reduz todo o custo do projeto do poo. Portanto, a adoo da tecnologia proposta por este trabalho proporciona diversos benefcios econmicos para a engenharia de petrleo como um todo.

7.4 ESPECIFICAO
Nessa seo, sero abordados os aspectos bsicos necessrios para projetar um sistema embarcado de tempo real. Aspectos tais como, componentes de hardware bsicos do sistema (processador, memria, hardwares adicionais), componentes de software, restries temporais impostas pela aplicao. Aspectos tais como, tempo e custo de desenvolvimento, expectativa de vida e confiana imposta ao sistema, no sero considerados dentre do escopo deste trabalho de pesquisa. Os aspectos descritos a seguir so referentes, apenas plataforma alvo (target plataform) na qual o sistema embarcado ser colocado em funcionamento. As definies da plataforma de desenvolvimento sero abordadas na seo 7.5.1 Definio da plataforma de desenvolvimento do sistema. importante salientar que os requisitos de hardware do sistema esto margem do escopo deste trabalho, sendo o mesmo definido apenas para validao do software embarcado de tempo real, objetivo central do trabalho.

Cllio F. de Souza

39

Ao final, um tpico sobre as caractersticas do poo monitorado levantado, assim como os equipamentos de sonda necessrios para implantao e realizao do sistema embarcado de monitoramento em tempo real do teste de formao. Componentes de hardware: como arquitetura de hardware bsica para o sistema, foi definido um processador embarcado, baseado na arquitetura SPARC V8, bastante utilizado no mercado em aplicaes embarcadas. O processador especificado para a aplicao foi o LEON, desenvolvido pela Agncia Espacial Europia - European Space Agency (ESA), do ingls - sendo livremente disponvel com todo cdigo fonte da arquitetura (descrio em VHDL) sob a LGPL (GNU Lesser General Public License)6. O LEON foi inicialmente projetado e implementado por Jiri Gaisler, pesquisador na rea de sistemas embarcados, enquanto estava na ESA e agora mantido sob contrato do instituto de pesquisa Gaisler Gaisler Reserch. O processador LEON verso 2 (verso atual at o presente trabalho) tem as seguintes especificaes: Pipeline de 5 estgios com unidade de inteiro compatvel ao SPARC v8; Caches de instrues e de dados separadas; Implementao completa do AMBA-2.0 AHB e barramentos on-chip APB; Perifricos onchip tal como UARTs, temporizadores, controlador de interrupo e porta de E/S de 16 bits; Interfaces para Unidade de ponto flutuante Meiko e co-processador definido pelo usurio. Ser necessrio 2048Kb de memria ROM para armazenar o executvel da aplicao e as rotinas do sistema operacional utilizadas (criao de tarefas, controle de concorrncia e sincronizao entre as tarefas, tratamento de interrupes, etc.), e 4096Kb de memria voltil (RAM) para suportar operaes com manipulao dos dados em execuo. Essas informaes foram extradas atravs do ambiente de desenvolvimento (simulador) Como componentes de hardware adicionais necessrios para a aplicao, temos: sensores de presso, com alta capacidade de preciso, resistente a um meio crtico de atuao (alta presso e temperatura, resistncia a fortes atritos externos, etc.). Meio de comunicao sem fio (wireless) de longo alcance ou atravs de algum tipo de protocolo especfico de comunicao wireless ou por mecanismos de rdio freqncia. Componentes de software: como arquitetura de software da aplicao, foi especificado um sistema operacional de tempo real (SOTR), bastante presente em aplicaes embarcadas de vrias reas de atuao. A escolha de utilizar um SOTR como arquitetura para a aplicao, foi devido ao fato do mesmo dar suporte a: criao de tarefas para o sistema; controle de concorrncia e sincronizao das tarefas; tratamento de interrupes internas e externas ao sistema; tratamento dos aspectos temporais imposta ao sistema, atravs de algoritmos de escalonamentos de alta preciso e escalabilidade; e entre outras, levando, conseqentemente, a uma diminuio do custo e tempo de desenvolvimento do sistema. O SOTR utilizado foi o RTEMS Real Time Executive Multiprocessor System

GNU Lesser General Public License, mais informaes em http://www.gnu.org/licenses/lgpl.html

Cllio F. de Souza

40

 desenvolvido pela OAR - On-Line Applications Research Corporation para uso das foras armadas do Estados Unidos. O objetivo do RTEMS inicialmente foi prover portabilidade e funcionalidades bsicas de um sistema de tempo real para aplicaes na qual serviria de suporte (aplicaes militares). RTEMS est sob licena de domnio pblico GNU General Public License (GPL) e atualmente est disponvel em diversas famlias de arquiteturas, por exemplo, Motorola MC68xxx, Motorola MC683xx, Motorola ColdFire, Hitachi SH, Intel i386, Intel i960, MIPS, PowerPC, SPARC, etc. Embora anteriormente desenvolvido para aplicaes militares, ele hoje usado tambm para aplicaes de sistemas embarcados de propsitos diversos, tais como, monitoramento de ambientes, controle em ambientes crticos sensveis a mudanas, aplicaes em explorao espacial, entre outras. A palavra executive possui o mesmo significado para ncleo ou kernel, ou sistemas operacionais que como foi relatado anteriormente no contexto deste trabalho no ser feita distino alguma. O RTEMS prover diretivas para criao e gerenciamento de tarefas, escalonamento, sincronizao, gerenciamento de tempo e multiprocessamento, referencia ao seu nome (M - Multiprocessor). As diretivas so agrupadas num conjunto de especificaes logicamente relacionadas que so chamadas de gerenciadores. A documentao do RTEMS ([8] RTEMS C Users Guide) apresenta descries detalhadas para cada um destes gerenciadores, que so: gerenciador de inicializao, de tarefa, de interrupo, de relgio, de temporizao, de semforo, de troca de mensagem, de eventos, de sinais, de E/S, de controle de erros crticos, de taxa monotnica, de multiprocessador. Obviamente que, no necessariamente todos os gerenciadores sero instanciados numa mesma aplicao, sendo seu uso de acordo com a necessidade de um contexto especfico. Para este sistema de monitorao de poo, foram instanciados os gerenciadores de: inicializao (responsvel pela inicializao do sistema operacional, portanto necessrio em qualquer aplicao), de tarefas (responsvel pela

criao/destruio de tarefas), de interrupo (lida com tratamento de interrupes internas/externas), de sinais (envio de sinais para sincronizao e/ou comunicao entre tarefas ou entre rotinas de tratamento de interrupes e tarefas). Restries temporais: considerando os aspectos temporais do sistema, em geral podemos classific-lo como um sistema de tempo real no crtico, onde o no cumprimento dos prazos previsto pelo sistema no impacta em um dano grave, ou seja, desejvel que a obteno, transmisso e visualizao dos dados que esto sendo monitorados sejam disponibilizados dentro de um limite de tempo imposta pelos especialistas, para que certas decises possam ser tomadas durante a fase operacional do teste, mas um provvel no cumprimento de algum dos prazos estabelecidos no causa um dano irreversvel operao do teste. Portanto, considerando-se a classificao estabelecida acima para o sistema, podemos estimar um tempo limite para que os dados monitorados no fundo do poo possam estar disponveis para anlise em superfcie. Para
Cllio F. de Souza

41

estimativa deste tempo, deve-se levar em conta algumas caractersticas do poo, tal como profundidade do poo, dessa forma, estima-se que os dados devem ser processados (obteno, transmisso e visualizao) em um tempo limite de 1s/1000m, ou seja, considerando um poo perfurado a uma profundidade de 10 km, teramos o tempo limite para processamento dos dados em 10s. Caractersticas do poo e equipamentos de sonda: o poo a ser monitorado um poo de explorao terrestre, unidirecional, com profundidade de 500 m a 10 km, pode ser um poo aberto (durante a perfurao) ou revestido (aps a completao do poo). Como equipamentos de sonda necessrio: equipamentos bsicos de um sonda de perfurao (torre ou mastro, estaleiros para o sistema de sustentao da coluna de teste, guinchos, Catarina, cabo de perfurao, elevador para o sistema de movimentao de cargas, mesa rotativa para o sistema de rotao, tanques e bombas de injeo de lama para o sistema de circulao), assim como, todos os equipamentos bsicos para a coluna de teste descritos na seo 2.1.4 Teste de Formao.

7.5 ELABORAO
Nos tpicos que seguem, sero descritos passos relevantes que levaram realizao deste trabalho de pesquisa. Eles esto organizados de forma seqencial dentro do que foi a realizao deste trabalho. Inicialmente foi definida toda a plataforma de desenvolvimento do sistema (todas as ferramentas utilizadas que guiaram a realizao do trabalho), em seguida alguns problemas foram encontradas que impactaram substancialmente ao trabalho (questes de limitaes do ambiente utilizado), implementao parcial do sistema (visto s limitaes descritas no tpico de problemas encontrados, apenas uma parte do sistema pode ser implementado), soluo encontrada (qual soluo foi adotada para resolver os problemas encontrados).

7.5.1 DEFINIO DA PLATAFORMA DE DESENVOLVIMENTO DO SISTEMA

Como discutido anteriormente, para o desenvolvimento (construo, depurao e simulao) do cdigo do sistema embarcado no suficiente apenas utilizar a plataforma de hardware real onde o sistema ir operar, mas sim, um conjunto de outras ferramentas de apoio ao desenvolvedor necessrio, visto que o tempo de compilao cruzada e descarga da aplicao na plataforma de hardware real invivel. O que guiou a definio da plataforma de desenvolvimento, ou seja, o conjunto de ferramentas necessrias para desenvolvimento do sistema, foi justamente a definio inicial da plataforma alvo na qual o sistema ir atuar, portanto antes mesmo da definio da plataforma de desenvolvimento foi definida a plataforma alvo do sistema. A definio da plataforma alvo do sistema foi realizada em conjunto com o prof. Ivan Saraiva (orientador do trabalho) levantando aspectos relevantes ao hardware do sistema: processador LEON, meio de comunicao sem fio,

Cllio F. de Souza

42

etc, e o prof. Tarclio (co-orientador) validando a plataforma junto ao ambiente real de domnio de operao. A plataforma alvo do sistema pode ser vista na seo 7.4 Especificao. Baseado na plataforma alvo do sistema, foi definido um conjunto de ferramentas que guiaram o desenvolvimento do sistema. A plataforma de desenvolvimento vista como um conjunto de hardware e software necessrios para modelar, implementar, depurar, testar, simular e validar, ou seja, todos os passos necessrios para o desenvolvimento do sistema embarcado. A plataforma de desenvolvimento do sistema descrita a seguir: Hardware de propsito geral: arquitetura de hardware utilizada foi um processador Intel de 32 bits com 256Mb de memria RAM e 2.8GHz de processamento, sendo esse requisito bastante flexvel para o desenvolvimento deste trabalho, visto o requerimento de hardware necessrio para o

desenvolvimento bastante plausvel. Experimentos foram realizados em ambientes Linux-x86 com 64Mb de RAM e processador Pentium-233MHz. Sistema operacional de propsito geral (SOPG): o SOPG utilizado para desenvolvimento do sistema foi baseado em ambiente de plataforma

Windows/Cygwin, contudo, experimentos foram realizados em ambientes para a plataforma Linux-x86, sem nenhuma restrio imposta. O Cygiwn um emulador do ambiente Linux que roda em ambiente Windows, desenvolvido pela Red Hat GNU (distribuio do Linux) e livremente disponibilizado sob licena livre em www.cygwin.com. A utilizao do Cygwin para este trabalho foi fundamental, pois todo o ambiente de desenvolvimento disponvel (LECCS, e RTEMS), como veremos a seguir, est disponvel preferencialmente para a plataforma Linux-x86. Ambiente de desenvolvimento: editor de texto convencional do Windows (NotePad), utilizao do pacote de desenvolvimento (toolkit) LECCS LEon Cross-Compiler System nesse pacote temos um conjunto de ferramentas para o desenvolvimento de sistemas embarcados de tempo real para o processador LEON. O centro de pesquisa Gaisler, citado anteriormente, que dispe deste toolkit de desenvolvimento (LECCS LEON/ERC32 Cross Compilation System) para a arquitetura do LEON e ERC32. Nesse toolkit, temos um completo conjunto de ferramentas de software para o apoio ao desenvolvimento na plataforma do LEON, tal como um compilador GNU C/C++ que gera cdigo para a plataforma do LEON (cross-compiler), um depurador gdb, assim como um front-end DDD, um conjunto de arquivos binrios utilitrios (sparc-rtems-size.exe, mkprom.exe, sparcrtems-gdb.exe, etc.), conjunto de bibliotecas C para o compilador, sistema operacional de tempo real RTEMS. O toolkit LECCS foi usado nesse projeto em toda parte do desenvolvimento do sistema embarcado. Mais informaes sobre esse toolkit de desenvolvimento pode ser obtida em www.gaisler.com.
Cllio F. de Souza

Nesse 43

mesmo centro de pesquisa (Gaisler) foi desenvolvido um simulador (TSIM) da arquitetura SPARC capaz de simular o conjunto de instrues do LEON. TSIM roda em plataformas com ambiente Linux x86, Sparc ou Windows/Cygwin. Com isso, desenvolvedores podem desenvolver, testar e depurar seus programas atravs do simulador TSIM em suas estaes de trabalho sem ter nenhum contato com a plataforma de hardware real. Esse aumento de velocidade drasticamente alcanado em todo processo de desenvolvimento (da codificao aos testes finais de integrao do sistema). O TSIM pode ser conectado com a ferramenta de depurao gdb, sendo capaz de realizar a operao de depurao para inspeo do cdigo em desenvolvimento. Como ferramenta de modelagem dos requisitos de hardware e software do sistema foi utilizada a verso demo da ferramenta Rhapsody Development Edition. Essa ferramenta desenvolvida pela I-Logix (www.ilogix.com) especializada na modelagem de sistemas embarcados de tempo real. Em sua verso completa, possui mecanismos de simulaes do modelo atravs de ferramentas de execuo automticas para os diagramas de seqncia, de atividades e de estados. Essa funcionalidade no est presente na verso demo da ferramenta (utilizada neste trabalho). Para validao da modelagem do sistema, foi utilizado a ferramenta gratuita JPetriNets V1.1 de modelagem de sistema atravs das Redes de Petri. O conceito de Redes de Petri ser abordado da seo 7.8 Validao da Modelagem do Sistema. A figura abaixo resume a plataforma de desenvolvimento utilizada para desenvolvimento do software embarcado.

Cllio F. de Souza

44

Figura 6 Ambiente de desenvolvimento do sistema

Cllio F. de Souza

45

7.5.2 PROBLEMAS ENCONTRADOS

A idia inicial deste trabalho era desenvolver o software embarcado responsvel pelo monitoramento em tempo real do teste de formao, porm ao decorrer do desenvolvimento deste trabalho alguns problemas foram detectados e que afetaram, significativamente, o andamento e concluso do mesmo. A seguir, os problemas encontrados sero levantados e analisados, assim como, os impactos causados no trabalho. Todos os problemas encontrados foram devido verso de avaliao (evaluation version) do simulador utilizado (TSIM), mais especificamente devido o mesmo no dar suporte a implementao de dispositivos externos ao sistema (Device Driver, do ingls). Essa verso pode ser baixada no site da Gaisler Research7 livremente, sem nenhum custo adicional. Embora essa ferramenta ter sido bastante til para o trabalho, a mesma, ao decorrer do desenvolvimento do software embarcado de monitoramento, deixo muito a desejar. A idia inicial do trabalho com esse simulador era, simular a monitorao em tempo real para o teste de formao, atravs de mecanismos necessrios para coletar os dados do meio externo, tratar a leitura dos dados e enviar, via especificao de protocolo sem fio wireless, para o sistema em superfcie. A especificao do protocolo em particular seria um dos pontos chaves para elaborao do trabalho, pois seria necessrio codificar, utilizando as rotinas do RTEMS, a especificao do protocolo wireless, visto que o RTEMS no d suporte para esse tipo de comunicao. O RTEMS s d suporte a comunicao padro (com fio, TCP/IP, UDP, etc.), sendo assim, esse trabalho teria uma contribuio maior e mais significativa para a rea em estudo, caso fosse possvel implementar a funcionalidade de envio de dados segundo um protocolo wireless. Para implementar essa funcionalidade seria necessrio que o ambiente de simulao (verso de avaliao do TSIM) do sistema desse suporte definio de um Device Driver que proveria esta funcionalidade. Para realizar o mecanismo de coleta dos dados do meio, necessrio utilizar o conceito de interrupes externas ao sistema. Com isso, foi detectado o primeiro problema. Pesquisas foram feitas, experimentos e testes foram executados para confirmar o fato de que a verso de avaliao do TSIM no daria suporte ao tratamento de interrupes externas ao sistema (ISR Interrupt Service Routine), apesar das rotinas, responsveis por implementar essa funcionalidade, estarem presentes no RTEMS. O fato, mais especificamente, constado foi que o TSIM (verso de avaliao) no daria suporte a utilizao de Devices Drivers que seria responsvel na arquitetura do Leon de gerar sinais de interrupes externas ao sistema. Outro limitante dessa verso do TSIM seria justamente o mecanismo necessrio para definio de dispositivos de E/S do sistema. Tambm pela mesma razo exposta acima, i.e, seria necessrio definir um Device Driver de E/S para o sistema, onde este seria responsvel por tratar

www.gaisler.com

Cllio F. de Souza

46

todos os eventos de entrada-sada do sistema, onde este mecanismo no poderia ser simulado com a utilizao da verso disponvel do TSIM. Finalmente, para a implementao da especificao do protocolo de comunicao sem-fio, tambm seria necessrio construir um Device Driver que implementaria a especificao do protocolo de comunicao definido. At mesmo os mecanismos j implementados pelas rotinas do RTEMS para comunicao padro (com fio), seria necessrio definir um Device Driver do sistema onde este apenas instanciaria as funcionalidades j disponibilizadas pelo sistema operacional. Como foi dito anteriormente, essas limitaes da verso de avaliao do TSIM foram comprovadas atravs de experimentos e testes no ambiente, e a constatao definitiva foi atravs do contato direto (via e-mail) com os desenvolvedores do ambiente, como pode ser percebido abaixo:

Figura 7 Email com desenvolvedores do projeto RTEMS/TSIM

Esse problema da verso de avaliao do TSIM foi bastante impactante para realizao deste trabalho, visto que a nica verso do simulador que forneceria as funcionalidades necessrias seria a verso profissional do TSIM (licena no gratuita). Os preos das verses completas do TSIM podem ser obtidos no site da Gaisler Research (www.gaisler.com).

Cllio F. de Souza

47

Figura 8 Site do instituto de pesquisa Gaisler com os preos das verses do TSIM

Visto estas limitaes impostas pelo ambiente, algumas medidas foram tomadas para elaborao e concluso deste trabalho. Inicialmente, uma parte da implementao do sistema foi realizada com os aspectos (funcionalidades) suportados pelo ambiente (RTEMS e TSIM), de forma que pudessem ser feitas simulaes iniciais do sistema. Os aspectos sobre a implementao parcial do sistema sero abordados no tpico 7.6 Implementao Parcial versus Implementao Ideal do sistema. E a soluo adotada para os problemas levantados definida na seo seguinte.

7.5.3 SOLUO ADOTADA

A soluo para contornar estes problemas foi definir uma implementao parcial do sistema com base no que o ambiente (RTEMS e TSIM) podia nos oferecer e comparar coma a implementao ideal do sistema, tambm elaborar e validar a modelagem completa do sistema, supondo que todos os recursos necessrios estivessem disponveis para essa aplicao. Essa soluo foi definida em conjunto com o prof. Ivan Saraiva, orientador do trabalho. A especificao detalhada da soluo adotada ser abordada nas prximas sees.

Cllio F. de Souza

48

7.6

IMPLEMENTAO PARCIAL VERSUS IMPLEMENTAO IDEAL

A implementao parcial do sistema consiste basicamente no software embarcado de

monitoramento visto como um mdulo isolado do sistema, ou seja, nesse mdulo esto presentes as funcionalidades de obteno dos dados e controle interno para tratamento dos dados recebidos do meio. Apesar destas funcionalidades estarem presentes, as mesmas no so exatamente as funcionalidades reais para a obteno e controle de um sistema embarcado real, pois na verdade essas funcionalidades foram simuladas para validao de alguns aspectos do sistema. Para simular a obteno dos dados foi utilizado o conceito de interrupes internas ao sistema (ASR Assyncron Service Routine). Essas interrupes so interrupes de software, onde os mdulos do sistema (tarefas ou outras ASRs) disparam os sinais de interrupo, sendo os sinais tratados por uma rotina ASR do sistema especfica para aquele sinal, igualmente como funciona nas ISRs num ambiente real com suporte as interrupes externas (de hardware). As ASRs do sistema, similarmente com as ISRs, devem ter seu processamento o mais curto possvel, pois as rotinas de tratamento de interrupes no sofrem preempo do sistema, isso justificado para no perder algum novo sinal gerado. Contudo, as ASRs apenas recebem os dados do meio de E/S do sistema e inserem num fila definida pelo sistema. O cdigo da aplicao que realiza esta funcionalidade pode ser visualizado abaixo:

rtems_asr control_routine_pressao(rtems_signal_set signal) { // Acesso direto ao registrador de E/S unsigned int z = *(volatile unsigned int*)0x800000A0; addOnFIFO(z); rtems_task_resume(Task_id[0]); } void addOnFIFO(unsigned int val) { rtemsFIFO[head]=val; printf("\nAdicionar valor %d de pressao na fila.\n", rtemsFIFO[head]); head++; if(head==max) head=0; }

Figura 9 Cdigo-fonte das rotinas ASR do sistema

Na implementao atual, quem dispara os sinais de interrupo interna (ARS) so as tarefas do sistema que simulam os sensores de presso. Os valores de presso gerados pelas tarefas que simulam o comportamento dos sensores so gerados de forma aleatria.

rtems_task Pressao_task(rtems_task_argument arg) { rtems_id rtems_unsigned32 Cllio F. de Souza tid; task_index, timeSleep;

49

rtems_status_code status; printf("\n"); put_name(Task_name[arg-1], FALSE); printf(" INICIALIZADA!\n\n"); status = rtems_task_ident( RTEMS_SELF,RTEMS_SEARCH_ALL_NODES, &tid ); task_index = task_number( tid ); // Associa uma ASR a um evento de sinal de interrupcao interna rtems_signal_catch(control_routine_pressao,RTEMS_DEFAULT_MODES); while (1) { // INICIO DA REGIAO CRITICA: obtem o acesso ao semaforo Status = rtems_semaphore_obtain(Semaphore_id, RTEMS_DEFAULT_OPTIONS, RTEMS_NO_TIMEOUT); if(!rtems_is_status_successful(status)) printf("Erro ao tentar obter o semaforo de pressao, %d\n",status); valorPressao += 50 ; // FIM DA REGIAO CRITICA: libera o acesso ao semaforo status = rtems_semaphore_release(Semaphore_id); if(!rtems_is_status_successful(status)) printf("Erro ao liberar o semaforo de pressao, status: %d\n",status); // Acesso direto ao registrador de E/S *(volatile unsigned long *) (0x800000A0) = valorPressao; // Envio do sinal de interrupcao interna rtems_signal_send(Task_id[task_index-1], 1); timeSleep = Task_timeToSleep[task_index-2] * get_ticks_per_second(); put_name(Task_name[task_index-1], FALSE); printf("dorme por %d segs!\n\n", timeSleep/100); status = rtems_task_wake_after(timeSleep); } } status:

Figura 10 Cdigo-fonte da tarefa que simula os sensores de presso do sistema

Cllio F. de Souza

50

A simulao do mecanismo de E/S do sistema realizado atravs da manipulao direta do registrador com endereo de E/S da arquitetura do Leon, ou seja, para entrar ou sair com um dado ao sistema escreve-se ou l-se diretamente no registrador de E/S.

// Acesso direto ao registrador de E/S unsigned int z = *(volatile unsigned int*)0x800000A0; . . . // Acesso direto ao registrador de E/S *(volatile unsigned long *) (0x800000A0) = valorPressao;

Figura 11 Cdigo-fonte de acesso (leitura e escrita) do registrador de E/S do Leon

A especificao do endereo de memria que mapeia o registrador de E/S da arquitetura do Leon foi retirada da referncia do manual do usurio do Leon [10], sendo resumida abaixo:

Figura 12 Pgina 33 do Manual do Usurio do Processador Leon Existe ainda uma outra tarefa responsvel pelo controle interno do sistema. Esse controle interno significa pegar os valores de presso armazenados na fila do sistema e enviar de alguma forma superfcie. O envio superfcie simulado com a impresso dos dados transmitidos na tela do simulador.

rtems_task Control_task(rtems_task_argument arg) { put_name(Task_name[arg-1], FALSE); printf(" INICIALIZADA!\n\n"); while (1) { rtems_task_suspend(Task_id[0]); printf("Enviando o dado: %d\n",rtemsFIFO[tail]); tail++; if (tail==max) tail=0; } }

Figura 13 Cdigo-fonte da tarefa responsvel pelo controle interno do sistema

Cllio F. de Souza

51

Considerando a implementao ideal do sistema, as interrupes externas (hardware) seriam geradas por mdulos externos ao sistema (Devices Drivers) que simulariam os sensores de presso externos responsveis em lanar os sinais de interrupes para o Leon, onde o mesmo encaminharia o sinal a um ISR do sistema responsvel pelo tratamento daquele sinal de interrupo. O tratamento efetivo da interrupo gerada pelos sensores de presso seria ler da entrada do sistema, atravs do mdulo de E/S descrito como um Device Driver, e colocar o dado lido numa fila, onde aps o trmino da rotina de tratamento da interrupo uma tarefa se encarregaria de pegar o primeiro elemento da fila e transmitir pela rede at o sistema de monitoramento em superfcie onde realizaria a visualizao dos dados monitorados permitindo a interpretao por parte de um especialista do domnio. A implementao parcial do sistema pode ser visualizada por completo no anexo I deste trabalho.

7.6.1 COMPILAO, DEPURAO, SIMULAO

Para compilar o cdigo-fonte da aplicao necessrio utilizar o compilador disponvel pelo toolkit de desenvolvimento LECCS. O compilador baseado em ANSI C que gera cdigo para a arquitetura do Leon/Sparc. Para linkar com as bibliotecas do RTEMS necessrio passar uma diretiva de compilao para o compilador. A diretiva para incorporar os servios do RTEMS passada pela linha de comando da seguinte forma: $sparc-rtems-gcc rtems app_rtems.c o app_rtems.exe. Dessa forma passado ao compilador (sparc-rtems-gcc) o arquivo fonte (app_rtems.c) com a opo de linkagem dos servios do RTEMS (-rtems) para gerar o arquivo executvel (app_rtems) para a plataforma do Leon/Sparc. Gerado o arquivo executvel da arquitetura alvo, basta utilizar o simulador (TSIM) do Leon para executar o cdigo binrio gerado pelo compilador. Em linha de comando realizado da seguinte forma: $tsim-eval.exe app_rtems.exe, passando o arquivo executvel como parmetro para o simulador. Outra forma de simular o sistema seria chamar o simulador (tsim-eval.exe) sem nenhum parmetro, dessa forma um prompt de linha comando (tsim>) mostrado na tela na e dentro do simulador carregar o executvel com o comando: tsim> load app_rtems.exe. Carregado o executvel no TSIM podemos execut-lo com o comando: tsim> go. possvel tambm depurar o programa para poder inspecionar um possvel erro no programa. Para depurar um programa necessrio utilizar o utilitrio sparc-rtems-gdb do LECCS passando o arquivo executvel como parmetro. Dessa forma um prompt para depurao visualizado na tela com o programa carregado na memria pronto para o processo de inspeo. importante lembrar que, assim como para o compilador C convencional (plataforma x86), necessrio compilar o arquivo fonte passando a diretiva ggdb ou g para o compilador, possibilitando a depurao do programa.

Cllio F. de Souza

52

7.7 MODELAGEM DO SISTEMA (COMPLETA)

Para a modelagem do sistema, como dito anteriormente, foi utilizada a ferramenta Rhapsody para criao dos diagramas da modelagem do sistema. O diagrama inicial para definio do escopo do sistema embarcado dentro do contexto o diagrama de casos de uso. Esse diagrama representa todas as funcionalidades do sistema, assim como delimita bem os papis externos do contexto geral onde o sistema est inserido. Este diagrama pode ser visualizado a seguir:

Figura 14 Diagrama de casos de uso do sistema

No diagrama de casos de uso, so apresentadas todas as funcionalidades do sistema. Cada elipse represente um caso de uso em particular, e as setas pontilhadas so dependncias entre os casos de uso do sistema. O retngulo maior define o escopo do sistema em desenvolvimento. Os bonecos so os atores do sistema. Os atores podem ser os usurios do sistema, ou componentes de hardware e software que interagem com o sistema. A seta no orientada associa um ou mais ator(es) ao caso de uso em questo. Basicamente as funcionalidades do sistema so: Capturar Sinal, Gerar Interrupo, Tratar Interrupo e Enviar Dados. O detalhamento de cada caso de uso do diagrama mostrado a seguir:

Cllio F. de Souza

53

CASO DE USO: Capturar Sinal ATORES: Sensor de presso FLUXO DE EXECUO: Esse caso de uso inicia-se com um envio de sinal do sensor de presso externo ao sistema. O valor de presso obtido pelo sensor ento repassado ao dispositivo responsvel por E/S do sistema. O caso de uso termina com o envio de um sinal interrupo externa ao sistema emitido pelo sensor de presso, informando que um novo valor de presso foi gerado.

CASO DE USO: Gerar Interrupo ATORES: Caso de uso Capturar Sinal FLUXO DE EXECUO: Esse caso de uso inicia-se exatamente ao trmino do caso de uso anterior, onde uma interrupo gerada pelo sensor de presso, disparando uma rotina de tratamento de interrupo (ISR) responsvel pelo tratamento daquela interrupo especfica do sistema. Este caso de uso termina quando uma ISR, responsvel em tratar a interrupo gerada, executada.

CASO DE USO: Tratar Interrupo ATORES: Caso de uso Gerar Interrupo FLUXO DE EXECUO: Inicia-se com a execuo da ISR do sistema que trata o sinal de interrupo do sensor. Disparada uma ISR do sistema, a mesma l da entrada do sistema um valor de presso emitido pelo sensor. Aps a leitura, o valor de presso inserido na fila do sistema para envio dos dados. O caso de uso termina quando o dado lido da entrada do sistema foi inserido na fila do sistema e quando o sinal de wake up ou resume enviado tarefa responsvel pelo envio dos dados acionado.

CASO DE USO: Enviar Dados ATORES: Caso de uso Enviar Dados e Sistema Receptor na Superfcie FLUXO DE EXECUO: Esse caso de uso inicia-se com o disparo do sinal de wake up ou resume, transmitido pela ISR, tarefa do sistema encarregado de enviar os dados. Quando a tarefa acionada a mesma l os valores disponveis na fila do sistema e empacota os dados segundo o protocolo wireless especificado. Aps o envio dos dados, o sistema receptor dos dados na superfcie recebe o pacote de informaes transmitido e interpreta os dados contidos nele. O caso de uso termina quando os dados, j interpretados, so visualizados atravs dos grficos de presso do teste de formao na tela do monitor do usurio.

Cllio F. de Souza

54

Os casos de uso especificam o que o sistema faz e no como o sistema faz tal funcionalidade e nem como o sistema se comporta. Isso porque ele d apenas uma viso esttica do sistema. Para definir os aspectos dinmicos do sistema utilizado o diagrama de seqncia, onde mostra as trocas de mensagens entre os componentes do sistema (tarefas, ISRs, Devices Drivers externos, usurios do sistema, etc.) atravs da linha de tempo de execuo de cada componente. A figura abaixo define o diagrama de seqncia para o sistema.

Figura 15 Diagrama de seqncia do sistema

Observe que nesse diagrama temos uma viso dinmica do sistema, e tambm uma definio do comportamento e interao entre seus componentes, diferente da viso esttica dos diagramas de casos de uso. Neste diagrama, as caixas superiores representam uma instncia do componente especificado pelo nome. A instncia pode ser de um componente de hardware ou software do sistema, assim como do usurio. A linha tracejada que segue abaixo de cada caixa significa a linha de tempo que uma instncia pode estar ativa, o retngulo vertical em cima da linha significa o intervalo de tempo efetivo de ativao/utilizao do objeto (componente). Cada componente realiza trocas de mensagens entre outros componentes do sistema. As mensagens podem ser interpretadas como um conjunto de vrias interaes seqenciais entre os componentes do sistema. A interao pode ser um sinal emitido, uma chamada a uma rotina ou um envio de uma mensagem propriamente dita. Um outro diagrama importante para modelagem do sistema o diagrama de componentes. Esse diagrama especifica o relacionamento dos componentes de hardware e software do sistema, assim como as interfaces de comunicao entre eles.

Cllio F. de Souza

55

Figura 16 Diagrama de componentes Neste diagrama, os componentes de hardware do sistema e os usurios so representados pelas caixas, . Os componentes de software, componentes do sistema

embarcado e tambm o mdulo de visualizao em superfcie so representado como pacotes, . J as interfaces (elo) de comunicao entre os componentes de hardware e software so representadas por crculos, componentes do sistema. . A seta tracejada representa dependncias entre os

7.8 VALIDAO DA MODELAGEM DO SISTEMA

Para validao da modelagem foi tomado por base o diagrama de seqncia do sistema, onde possui uma viso dinmica do funcionamento dos casos de usos e trocas de mensagens entre os componentes (hardware e software do sistema). Tambm os outros diagramas so validados segundo a especificao real do sistema (diagrama de componentes). importante salientar que para a validao da modelagem necessrio considerar a execuo do sistema com a implementao completa (implementao dos Devices Drivers para os sensores de presso e dispositivos de E/S), assim como, a utilizao do ambiente completo (verso profissional do TSIM). O procedimento de validao da modelagem do sistema levado em conta os prazos (deadlines) estabelecidos pela especificao do sistema, verificando o cumprimento ou no dos mesmos (diagrama de seqncia), e tambm considerada a forma de como os componentes so integrados no sistema (diagrama de componentes) e sua justificativa com base na idealizao do sistema no ambiente real de uso. Analisando o diagrama de componentes do sistema, observamos que os sensores de presso, componente de hardware do sistema, realizam a comunicao com o componente de software do sistema de duas formas. A primeira forma de comunicao seria a comunicao
Cllio F. de Souza

56

responsvel por gerar as interrupes de hardware do sistema, essa comunicao realizada atravs dos pinos IRQ de controle das interrupes. Os pinos IRQ de interrupo so representados, no diagrama, pela interface de HW IRQ. Gerada a interrupo, o sensor l do ambiente um valor de presso e repassa o valor ao dispositivo de E/S do sistema, representado pela interface de comunicao de E/S no diagrama. Com a notificao do sinal de interrupo de hardware, uma ISR, associada quela interrupo, l do dispositivo de entrada do sistema o valor de presso emitido pelo sensor e armazena o valor lido numa fila do sistema. A comunicao de E/S e o sinal de interrupo externo so representados pelas interfaces E/S e HW IRQ, respectivamente. Inserido o valor de presso na fila, uma notificao de wake up emitida a tarefa do sistema responsvel pelo controle interno. Essa tarefa ao ser executada l da fila e empacota o valor lido para ser transmitido ao sistema em superfcie, atravs da interface de Protocolo Wireless. Em superfcie, o componente de captao do sinal wireless recebe o pacote e interpreta os dados contidos e repassa ao sistema de visualizao, possibilitando a gerao dos grficos de presso e interpretao pelo usurio. Os prazos definidos para o atendimento das funcionalidades do sistema foram especificados na seo 7.4 Especificao, sendo os mesmos validados pelo prof. Tarclio levando em conta um ambiente real de operao. Tomando por base o diagrama de seqncia proposto acima, mas agora considerando as restries de tempo, temos:

Cllio F. de Souza

57

Figura 17 Diagrama de Seqncia com restries de tempo.

Para validar um diagrama de seqncia com restries temporais necessrio utilizar algum tipo de ferramenta que possui um engine de execuo. Um engine pode ser visto como um mecanismo de tratamento de dados para a validao de um modelo, considerando uma situao real de uso e as respectivas limitaes de tempo impostas pelo modelo. A verso completa da ferramenta Rhapsody possui este mecanismo para validaes dos diagramas de seqncia, de estados e de atividades. Essa funcionalidade no est presente na verso demo da ferramenta (verso utilizada neste trabalho). Para suprir essa necessidade de validao do modelo, visto a limitao da verso demo do Rhapsody, foi utilizado o conceito de Redes de Petri, ou P-Nets, da abreviao do ingls. A seguir, ser dada uma breve explorao do conceito de Redes de Petri, assim como, sua utilizao para este trabalho de pesquisa. Redes de Petri foram definidas, em 1960, por Carl Adam Petri com o intuito de permitir expressar eventos concorrentes do mundo real, assim como, complementar a teoria de autmatos.
Cllio F. de Souza

58

As Redes de Petri so basicamente utilizadas para trs propostos. O primeiro deles que um modelo de Redes de Petri uma descrio do sistema modelado, podendo ser usado como uma especificao (de um sistema a ser construdo) ou uma representao (de um sistema para ser mostrado para outras pessoas, ou ns mesmos). Pela criao de um modelo ns podemos investigar um novo sistema antes dele ser construdo. Isso leva vantagem, em particular para sistema onde erros de projeto podem comprometer a segurana de ambiente onde ele est inserido. O segundo propsito das Redes de Petri, que o comportamento de um modelo de Redes de Petri pode ser analisado, tanto pelo mecanismo de simulao (equivalente a uma execuo do programa para validao, anlise e/ou depurao do sistema), quanto por mtodos de analise formais (que equivale a uma verificao do programa). Finalmente, o terceiro propsito que o modelo de Redes de Petri pode ser altamente compreendido pelo projetista do sistema, atravs da criao da descrio e anlise da performance do sistema modelado. Alguns benefcios da utilizao das Redes de Petri so: Possuem uma representao grfica; Podem ser estendidas para suportar o conceito de tempo; Permitem analisar a viso dinmica do sistema; Integram o conceito do controle e sincronizao com o conceito de manipulao dos dados; So utilizadas para propsito geral, podendo ser usada para descrever uma grande variedade de sistemas; Possuem diversas ferramentas computacionais para modelagem, simulao e anlise do modelo a ser implementado. Uma Rede de Petri consiste de posies (places), transies (transitions) e arcos direcionais (directed arcs). Os arcos conectam uma posio a uma transio e vice-versa. Cada arco tem um peso (weight) associado, representando o nmero mximo de fichas que podem ser transportadas naquela transio. No existem arcos entre duas posies, e entre duas transies. As posies podem conter algum nmero de fichas (tokens). As transies so disparadas quando elas consomem as fichas das posies de entradas e produzem fichas nas posies de sada. Uma transio s disparada quando a mesma for habilitada, e para habilitar uma transio preciso ter fichas em todas as posies de entrada para aquela transio. Como j dito anteriormente, a utilizao do conceito de Redes de Petri neste trabalho surgiu para suprir a necessidade de validar o modelo do sistema (diagrama de seqncia), visto que a verso utilizada (demo) da ferramenta de modelagem Rhapsody, neste trabalho, no suportar os mecanismos de execuo automtica para validao do modelo proposto. A figura a seguir, representa um instante da execuo do mesmo diagrama de seqncia temporal proposto, sob a viso de Redes de Petri.

Cllio F. de Souza

59

Figura 18 Rede de Petri de modelagem do sistema As posies da rede esto numerados de 1 a 8, sendo: 1 a 4 representando os quatro sensores de presso do sistema; a posio de nmero de 5 (p5) representa a ISR do sistema, assim como, o primeiro acesso a fila (escrita) e a emisso do sinal de wake up tarefa de controle do sistema; a posio 6 (p6) representa a execuo da tarefa de controle do sistema (rtemsTaskControl), essa execuo leva em conta o segundo acesso fila (leitura) e o empacotamento dos dados lidos para transmisso na rede; a posio 7 (p7) representa o tempo de envio do pacote transmitido at a superfcie e finalmente, a posio 8 (p8) representa a chegada e visualizao pelo sistema de monitoramento em superfcie ao usurio, para simplificao da rede este tempo desconsiderado. As transies, total de 7, representam o tempo de processamento/execuo para cada posio da rede. Esses tempos foram determinados considerando as restries de tempo impostas ao sistema e o processamento de execuo mnimo e mximo de cada objeto do sistema, para que os prazos estabelecidos fossem cumpridos. Sendo assim, as transies que representam os sensores de presso (t1 a t4) possuem tempos variados dentro de um intervalo de 45 a 60 segundos, esse tempo significa o perodo de tempo na qual um novo valor de presso ser gerado pelo sensor. O peso (nmero mximo de fichas a transportar) de cada arco direcional 1, significando o prprio valor de presso sendo gerado e transmitido pelo sistema. Aps representar o modelo do sistema na Rede de Petri acima, foi feita uma validao do modelo, utilizando a ferramenta JPetriNets, de modo a observar o comportamento dinmico e temporal do sistema, verificando se as respectivas restries temporais do sistema foram cumpridas. Essa validao foi feita utilizando o engine de execuo da ferramenta utilizada para modelagem da rede com uma taxa (rating) de 0.01. importante observar no modelo de Rede de Petri que o tempo da transio 5 (t5) deve ser o menor possvel, visto que esta transio representa o processamento para tratar a interrupo externa gerado pelos sensores. Isso fundamental, pois o processamento de uma ISR (Rotina de Tratamento de Interrupo) no pode

Cllio F. de Souza

60

sofrer preempo, podendo perder um valor de presso gerado, isso justifica o fato de que seu processamento deve ser o menor possvel (1s no mximo). Como concluso da simulao do modelo podemos afirmar que para os limites temporais pressupostos e especificados na seo 7.4 Especificao, o sistema conseguiu atender a todas as restries de tempo solicitadas, ou seja, nenhum valor de presso perdido e todos os valores so visualizados dentro de um tempo limite de 10s (considerando um poo de 10km de profundidade).

Cllio F. de Souza

61

8 CONCLUSO E TRABALHOS FUTUROS

A utilizao de sistemas embarcados na engenharia do petrleo tem se mostrado como um amparo tecnolgico de extrema importncia nas vrias formas de utilizao, proporcionando um suporte fundamental diante s dificuldades dos diversos problemas encontrados. O benefcio alcanado pela utilizao desta tecnologia em monitorao de poos tem proporcionado melhores resultados e reduo significativa no custo total do projeto do poo. Este trabalho de pesquisa fundamentou-se especificamente em tratar o problema de monitorao de poos para o teste de formao, visando utilizar a tecnologia de sistemas embarcados para atacar os entraves percebidos na fase operacional dos testes de formao convencionais, que utilizam um formato analgico (cartas de metal) para medies de parmetros do poo. As limitaes encontradas na fase operacional do teste (impreciso/qualidade dos dados monitorados, impossibilidade da obteno dos dados durante a realizao do teste, confiabilidade dos dados monitorados) podem acarretar algumas limitaes ao teste, e conseqentemente ao aumento do custo do projeto do poo, como visto anteriormente neste trabalho. Apesar das dificuldades encontradas durante o desenvolvimento deste trabalho, conclui-se que sua elaborao foi significativa no que este trabalho se props a realizar. Uma implementao parcial e experimental foi realizada de forma a validar alguns aspectos importantes do sistema para validao do mesmo, caso fosse implantado em um ambiente real de operao. Aspectos tais como: simulao de um tratamento adequado de interrupo do sistema, controle de tarefas do sistema, mecanismos bsicos de E/S do sistema embarcado, etc. Uma modelagem completa do sistema foi realizada (componentes de hardware e software do sistema), assim como uma validao da modelagem caso fosse utilizado um ambiente completo de desenvolvimento. Para validao foram levados em conta a compatibilidade dos aspectos da modelagem com os aspectos de um caso real de operao, ou seja, verificar se o modelo adequado aos aspectos reais de funcionamento (recursos de hardware e software do ambiente, mecanismos de comunicao, etc.). Tambm considerando a validao da modelagem do sistema, uma especificao das Redes de Petri foi elaborada para observar os aspectos temporais do sistema, i.e, se os prazos estabelecidos esto compatveis como o modelo do sistema. Diversos aspectos, antes inexplorados pelo autor, sobre a rea em domnio da aplicao (Teste de Formao) foram contemplados, mesmo considerando que se tratava de uma rea nova de estudo, bastante complexa e abrangente. Isso foi de extrema importncia, pois um conhecimento do domnio em questo era necessrio para a elaborao deste trabalho, e muito foi alcanado atravs de pesquisas na literatura da rea e interaes com especialistas, prof. Tarclio e prof. Romualdo, onde deixo minha satisfao pessoal pelas vossas contribuies para com o trabalho. Muito tambm foi instigado sobre a rea de sistemas embarcados de tempo real, onde foram levantados diversos aspectos que foram analisados, compreendidos e implantados para que

Cllio F. de Souza

62

o trabalho pudesse ser desenvolvido, isso com a contribuio do prof. Ivan Saraiva, orientador do trabalho e especialista na rea. Como trabalhos futuros desse trabalho, podemos destacar os aspectos relevantes a plataforma alvo do sistema, ou seja, especificada a plataforma na qual o sistema embarcado ser inserido necessrio adquirir, ou elaborar a plataforma de hardware necessria para o sistema e com isso realizar experimentos mais reais com a plataforma real de operao. Isso pode ser em conjunto com outros trabalhos de pesquisa na rea de concepo de sistemas digitais ou arquitetura de computadores, visto que a elaborao de toda a plataforma de hardware do sistema abrange os aspectos do processador embarcado, mecanismos de entradas de dados, comunicao remota com o sistema em superfcie, entre outros. Pode-se tambm concentrar mais em funcionalidades especficas do software embarcado de monitoramento, tais como, controle em recuperao de falhas do sistema, atravs de logs de gerenciamento, mecanismos de correo dos dados (CRC) transmitidos superfcie, isso devido possibilidade de danos nos dados ocorrido por rudos do meio, entre outras. Pode-se estender esse sistema de monitoramento de poos para outros meios de aplicao dentre da prpria Engenharia do Petrleo ou no. Enfim, as possveis extenses deste trabalho so bem abrangentes a diversos domnios de atuao, tais como: a rea de sistemas embarcados, sistemas de tempo real, sistemas de tolerncia falhas, sistemas distribudos, concepo de sistemas digitais e arquitetura de computadores.

Cllio F. de Souza

63

9 REFERNCIAS BIBLIOGRFICAS
[1] THOMAS, Jos Eduardo. Fundamentos de Engenharia do Petrleo. Ed. Intercincia, Rio de Janeiro 2001. [2] ALLEN, T.O, ROBERTS, A. P. Production Operations - Well Completions, Workover, and Simulation. Vol. 1. [3] GATTIN, Carl. Petroleum Engineering Drilling and Well Completions. Prentice-Hall, 1960. [4] Composite Catalog of Oil Field Equipment and Service. Vol. 2. pp 2054 2063 e 2530 2555. [5] FREITAS, Ricardo Dantas Gadelha. Um Sistema de Monitoramento em Tempo Real de Parmetros de Perfurao de Poos de Petrleo. Tese de Mestrado, UFRN Engenharia Eltrica, 1992. [6] SIMON, David E. Embedded Software Primer.Ed. Addson-Wesley, 1999. [7] Getting Start with RTEMS for C/C++ Users. Edition 1. 26/09/2000 [8] RTEMS C Users Guide. Edition1, for RTEMS 4.5.0. 06/09/2000 [9] Farines, Jean-Marie; Fraga, Joni da Silva, et al. Sistemas de Tempo Real. Escola de computao, 2000. [10] LEON2 Processor Users Manual, XST Edition, Version 1.0.23, May 2004 [11] DOUGLASS, Bruce Powel. Real-Time Design Patterns, Addison Wesley. [12] www.daimi.au.dk/designCPN. Acesso em 29/11/2004.

Cllio F. de Souza

64

ANEXO I

#include <rtems.h> #include <stdio.h> rtems_task Init(rtems_task_argument argument); rtems_task Control_task(rtems_task_argument arg); rtems_task Pressao_task(rtems_task_argument arg); void addOnFIFO(unsigned int val); #define RTEMS_MY_MODES RTEMS_PREEMPT | RTEMS_TIMESLICE #define RTEMS_MY_SEMAPHORE RTEMS_DEFAULT_ATTRIBUTES /* configuration information */ #include <bsp.h> /* for device driver prototypes */ #define CONFIGURE_INIT #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER #define CONFIGURE_MAXIMUM_TASKS #define CONFIGURE_RTEMS_INIT_TASKS_TABLE #define CONFIGURE_EXTRA_TASK_STACKS #include <confdefs.h> static inline rtems_unsigned32 get_ticks_per_second( void ) { rtems_interval ticks_per_second; (void)rtems_clock_get(RTEMS_CLOCK_GET_TICKS_PER_SECOND, &ticks_per_second); return ticks_per_second; } #define task_number( tid ) \ ( rtems_get_index( tid ) - \ rtems_configuration_get_rtems_api_configuration()>number_of_initialization_tasks ) #define put_name( _name, _crlf ) \ Cllio F. de Souza (3 * RTEMS_MINIMUM_STACK_SIZE) 7

65

do { \ rtems_unsigned32 c0, c1, c2, c3; \ \ c0 = ((_name) >> 24) & 0xff; \ c1 = ((_name) >> 16) & 0xff; \ c2 = ((_name) >> 8) & 0xff; \ c3 = (_name) & 0xff; \ putchar( (char)c0 ); \ if ( c1 ) putchar( (char)c1 ); \ if ( c2 ) putchar( (char)c2 ); \ if ( c3 ) putchar( (char)c3 ); \ if ( (_crlf) ) \ putchar( '\n' ); \ } while (0)

unsigned head=0; /* Cabea da fila */ unsigned tail=0; /* Cauda da fila */ unsigned max = 10; /* Tamanho mximo de elementos na fila */ rtems_unsigned32 rtemsFIFO[ 10 ]; /* Fila do sistema */ rtems_id Task_id[ 5 ]; /* Array para os identificadores ID das tarefas*/

rtems_name Task_name[ 5 ]; /* Array dos nomes das tarefas */ rtems_unsigned32 Task_timeToSleep[ 4 ] = {5, 10, 2, 7}; /* Tempo fixo de dormir para cada tarefa */ rtems_id Semaphore_id; /* Identificador ID do objeto semaforo do sistema */ rtems_unsigned32 valorPressao; /* Varivel auxiliar para simular os valores de presso do sistema */ rtems_task Init(rtems_task_argument argument) { rtems_name Semaphore_name; rtems_status_code status; puts("\n\n*** Monitoramento do Teste de Poco ***"); // task de controle interno Task_name[ 0 ] = rtems_build_name( 'C', 'T', 'R', 'L' ); // tasks p/ os sensores de pressao Task_name[ 1 ] = rtems_build_name( 'P', '1', ' ', ' ' ); Task_name[ 2 ] = rtems_build_name( 'P', '2', ' ', ' ' ); Task_name[ 3 ] = rtems_build_name( 'P', '3', ' ', ' ' ); Cllio F. de Souza

66

Task_name[ 4 ] = rtems_build_name( 'P', '4', ' ', ' ' );

// task CTRL (Controle): status = rtems_task_create( Task_name[ 0 ], 1, RTEMS_MINIMUM_STACK_SIZE * 2, RTEMS_MY_MODES, RTEMS_DEFAULT_ATTRIBUTES, &Task_id[ 0 ]); if(!rtems_is_status_successful(status)) { printf("Task DST: Erro na criacao, status: %d\n",status); exit(1); } // task P1 (Pressao 1): status = rtems_task_create( Task_name[ 1 ], 10, RTEMS_MINIMUM_STACK_SIZE * 2, RTEMS_MY_MODES, RTEMS_DEFAULT_ATTRIBUTES, &Task_id[ 1 ]); if(!rtems_is_status_successful(status)) { printf("Task P1: Erro na criacao, status: %d\n",status); exit(1); } // task P2 (Pressao 2): status = rtems_task_create( Task_name[ 2 ], 10, RTEMS_MINIMUM_STACK_SIZE * 2, RTEMS_MY_MODES, RTEMS_DEFAULT_ATTRIBUTES, &Task_id[ 2 ]); if(!rtems_is_status_successful(status)) { printf("Task P2: Erro na criacao, status: %d\n",status); exit(1); } // task P3 (Pressao 3): status = rtems_task_create( Task_name[ 3 ], 10, RTEMS_MINIMUM_STACK_SIZE * 2, RTEMS_MY_MODES, RTEMS_DEFAULT_ATTRIBUTES, &Task_id[ 3 ]); if(!rtems_is_status_successful(status)) { printf("Task P3: Erro na criacao, status: %d\n",status); exit(1); } // task P4 (Pressao 4): status = rtems_task_create(

Cllio F. de Souza

67

Task_name[ 4 ], 10, RTEMS_MINIMUM_STACK_SIZE * 2, RTEMS_MY_MODES, RTEMS_DEFAULT_ATTRIBUTES, &Task_id[ 4 ]); if(!rtems_is_status_successful(status)) { printf("Task P4: Erro na criacao, status: %d\n",status); exit(1); } // criacao do semaforo do sistema Semaphore_name = rtems_build_name('S','E','M','A'); status = rtems_semaphore_create(Semaphore_name, 1, RTEMS_MY_SEMAPHORE, 1, &Semaphore_id); if (!rtems_is_status_successful(status)) { printf("Erro na criacao do semaforo de pressao, status: %d\n", status); exit(1); } // valor iniciail de pressao valorPressao = 1000; // inicializacao das tarefas do sistema status = rtems_task_start( Task_id[ 0 ], Control_task, 1 ); status = rtems_task_start( Task_id[ 1 ], Pressao_task, 2 ); status = rtems_task_start( Task_id[ 2 ], Pressao_task, 3 ); status = rtems_task_start( Task_id[ 3 ], Pressao_task, 4 ); status = rtems_task_start( Task_id[ 4 ], Pressao_task, 5 ); status = rtems_task_delete( RTEMS_SELF ); } rtems_asr control_routine_pressao(rtems_signal_set signal) { // Acesso direto ao registrador de E/S unsigned int z = *(volatile unsigned int*)0x800000A0; addOnFIFO(z); rtems_task_resume(Task_id[0]); } void addOnFIFO(unsigned int val) { rtemsFIFO[head]=val; printf("\nAdicionar valor %d de pressao na fila.\n", rtemsFIFO[head]); head++; if(head==max) head=0; }

Cllio F. de Souza

68

rtems_task Control_task(rtems_task_argument arg) { put_name(Task_name[arg-1], FALSE); printf(" INICIALIZADA!\n\n"); while (1) { rtems_task_suspend(Task_id[0]); printf("Enviando o dado: %d\n",rtemsFIFO[tail]); tail++; if (tail==max) tail=0; } } rtems_task Pressao_task(rtems_task_argument arg) { rtems_id rtems_unsigned32 tid; task_index, timeSleep;

rtems_status_code status; printf("\n"); put_name(Task_name[arg-1], FALSE); printf(" INICIALIZADA!\n\n"); status = rtems_task_ident( RTEMS_SELF, RTEMS_SEARCH_ALL_NODES, &tid ); task_index = task_number( tid ); // Associa uma ASR a um evento de sinal de interrupcao interna rtems_signal_catch(control_routine_pressao, RTEMS_DEFAULT_MODES); while (1) { // INICIO DA REGIAO CRITICA: obtem o acesso ao semaforo status = rtems_semaphore_obtain(Semaphore_id, RTEMS_DEFAULT_OPTIONS, RTEMS_NO_TIMEOUT); if(!rtems_is_status_successful(status)) printf("Erro ao tentar obter o semaforo de pressao, status: %d\n",status); valorPressao += 50 ; // FIM DA REGIAO CRITICA: libera o acesso ao semaforo status = rtems_semaphore_release(Semaphore_id); if(!rtems_is_status_successful(status)) printf("Erro ao liberar o semaforo de pressao, status: %d\n",status); // Acesso direto ao registrador de E/S *(volatile unsigned long *) (0x800000A0) = valorPressao; Cllio F. de Souza

69

// Envio do sinal de interrupcao interna rtems_signal_send(Task_id[task_index-1], 1); timeSleep = Task_timeToSleep[task_index-2] * get_ticks_per_second(); put_name(Task_name[task_index-1], FALSE); printf("dorme por %d segs!\n\n", timeSleep/100); status = rtems_task_wake_after(timeSleep); if(!rtems_is_status_successful(status)) printf("Erro ao tentar executar a rotina 'rtems_task_wake_after', status: %d\n",status); } }

Cllio F. de Souza

70