2009 Eu D Isley Anjos

i
Universidade Federal da Paraba

Centro de Cincias Exatas e da Natureza
Programa de Ps-Graduao em Informtica

Sistema Embarcado Reconfigurvel para Automao
de Unidades de Bombeamento de Petrleo atravs de
Redes de Sensores sem Fios.

EUDISLEY GOMES DOS ANJOS

Joo Pessoa, Maro de 2009
ii


Dissertao de Mestrado



Orientadores:
Jos Antnio Gomes de Lima
Francisco Antnio Belo

iii




Orientadores:
Jos Antnio Gomes de Lima
Francisco Antnio Belo

Dissertao de Mestrado apresentada ao
Programa de Ps-Graduao em
Informtica, da Universidade Federal da
Paraba, como parte dos requisitos para a
obteno do ttulo de Mestre em
Informtica.

rea de concentrao: Cincia da Computao.
Linha de pesquisa: Processamento de Sinais e Sistemas Grficos.


iv

A597s Anjos, Eudisley Gomes dos.
Sistema embarcado reconfigurvel para automao de
unidades de bombeamento de petrleo atravs de redes de
sensores sem fios / Eudisley Gomes dos Anjos.- Joo
Pessoa, 2009.
144p. : il.
Orientadores: Jos Antnio Gomes de Lima, Francisco
Antnio Belo
Dissertao (Mestrado) UFPB/CCEN
1. Informtica. 2. Sistemas Embarcados. 3. Computao
Reconfigurvel. 4. FPGA. 5. Processador Nios II. 6. Protocolo
ModBus. 7. Protocolo ZigBee. 8. Redes de Sensores sem
Fios.

UFPB/BC CDU: 004(043)

v



Orientadores:
Prof. Dr. Jos Antnio Gomes de Lima
Doutor pela Universidade Federal de Campina Grande
Campina Grande Brasil

Prof. Dr. Francisco Antnio Belo
Doutor pela Universidade Estadual de Campinas
Campinas - Brasil

Banca Examinadora:
Prof. Dr. Antonio Carlos Cavalcanti
Doutor pelo Institut National Polytechnique de Grenoble
Grenoble Frana

Prof. Dr. Ivan Saraiva Silva
Doutor pela Universite de Paris VI
Paris - Frana

Coordenadora do Mestrado:
Prof. Dr. Valria Gonalves Soares
Doutora pela Universidade Federal de Pernambuco
Recife Brasil
vi

A esperana no murcha, ela no cansa,
tambm como ela no sucumbe crena.
Vo-se sonhos nas asas da descrena,
voltam sonhos nas asas da esperana.

Augusto Dos Anjos
vii

Dedicatria

Para minha famlia, especialmente minha me e irms pelo incentivo, amor,
apoio e opinies que me fizeram traar sempre os melhores e mais justos
caminhos frente.
A Bruno Maia que sempre esteve ao meu lado durante todo o processo de
elaborao e desenvolvimento desse trabalho, atuando direta e ativamente
para concluso do mesmo
A Jos de Andrade Martins pela fora, apoio e conselhos que foram cedidos
aumentando o meu potencial e minha experincia de vida.
viii

Agradecimentos

Primeiramente, eu agradeo ao meu orientador e amigo Prof.Dr. Jos Antnio
Gomes de Lima pela oportunidade oferecida, amizade conquistada e por suas
orientaes, conselhos e ensinamentos, depositados desde o incio do
mestrado e que foram essenciais para o desenvolvimento desse trabalho.
Agradeo tambm aos professores Francisco Antnio Belo, Antnio Carlos
Cavalcanti, Lucdio Cabral e Valria Elias que acompanharam, incentivaram, e,
principalmente acreditaram no meu potencial, estando sempre presentes nas
horas que eu mais precisei.
Aos amigos da UFPB: Bruno Maia, Jerry Lee, Yuri Gonzaga, Daniel Marx,
Ruan Delgado, Andr Ricardo e Abel Lima que sempre me ajudaram e
contriburam muito para realizao desse trabalho.
A todos os membros do LASID (Laboratrio de Sistemas Digitais), LES
(Laboratrio de Energia Solar) e amigos mais prximos, companheiros de
muitas atividades que me incentivaram e colaboraram para essa difcil jornada.
Ao CNPq e a PETROBRAS pelo apoio financeiro, e a todos os que de alguma
forma vibraram positivamente para a realizao desse trabalho.
ix

RESUMO

A constante evoluo dos sistemas embarcados tem requisitado
mudanas constantes em grandes e antigos mtodos de automao. Essas
alteraes no eram previstas na etapa de desenvolvimento desses sistemas
levando a necessidade de substituio de hardware e software e aumentando o
tempo de reconfigurao, custos e mo de obra. Este trabalho apresenta o
desenvolvimento de um sistema embarcado utilizando computao
reconfigurvel e o processador Nios II para ser aplicado na otimizao da
automao de Unidades de Bombeio de Petrleo. O atual mtodo de
automao possui um alto fator de erro, podendo atingir at 20% na
determinao dos valores de torque no eixo de sada do redutor. Com a
utilizao do sistema aqui apresentado, possvel obter valores referentes a
medidas reais de parmetros que indicam o atual estado da Unidade de
Bombeio. A utilizao da computao reconfigurvel proporciona a modificao
da arquitetura em tempo real para melhor se adequar aplicao que ser
executada, permitindo uma eficincia muito maior do que normalmente
encontrada em processadores de uso geral. Uma rede no padro ZigBee e um
conversor analgico-digital recebero dados digitais do novo torqumetro
implementado, enviam esses dados ao sistema, que realiza todos os clculos
necessrios e empacota no padro MODBUS, disponibilizando na rede de
automao dos campos de extrao de petrleo. Com o sistema proposto o
erro gerado chega a menos de 5%, alm de um monitoramento mais preciso e
maior facilidade de expanso.
Palavras Chave: Sistemas Embarcados, Computao Reconfigurvel, FPGA,
Processador Nios II, Protocolo ZigBee, Redes de Sensores sem Fios.
x

ABSTRACT

The constant evolution of embedded systems requires constant changes
in large and old automation methods. These changes were not specified in the
stage of development of these systems leading to the need to replace hardware
and software increasing the time of reconfiguration, costs and the workforce.
This work presents the development of an embedded system using
reconfigurable computing and Nios II processor to be applied in order to
optimize the Oil Pump Units Automation. The current method of automation has
a high error factor, and may reach up to 20% in determining the torque values
on the reducer output axle. With use of the presented system, it is possible to
obtain data from actual measures of values that indicate the current state of
Pump Unit. The use of reconfigurable computing allows the modification of the
architecture in real time to better fit the application that will be implemented,
allowing a much greater efficiency than is usually found in processors for
general use. A ZigBee standard network and an analog-digital converter will
receive the digital data from a new torque meter implemented, sending the data
to the system, which handles and packaging in MODBUS standard and
providing for network automation in the fields of oil extraction. With the
proposed system the error generated reaches less than 5%, and a more
accurate monitoring and easy expansion forms.
Key Words: Embedded Systems, FPGA, Nios II Processor, Reconfigurable
Computing, Wireless Sensor Networks, ZigBee Protocol.
xi

Lista de Figuras

Figura 2.1 Diagrama bsico de um sistema embarcado. ........................... 8
Figura 2.2 Sistemas embarcados em um veculo. ...................................... 9
Figura 2.3 Data logger para temperatura do ar. ........................................ 10
Figura 2.4 Nintendo Wii e sua grande interao com o usurio ............. 10
Figura 2.5 Sistema de controle industrial ................................................. 11
Figura 2.6 Ambiente de desenvolvimento DSP para o dsPIC. ................. 12
Figura 2.7 Roteador Cisco. ......................................................................... 12
Figura 2.8: Modelo de uma FPGA da Altera ................................................. 14
Figura 2.9: Esboo de um FPGA ................................................................... 14
Figura 2.10: Camadas do protocolo ZigBee ................................................. 18
Figura 2.11: Modelo das redes ZigBee ......................................................... 19
Figura 2.12: Aplicaes do padro ZigBee .................................................. 19
Figura 2.13: Modelo do ZigBee da MaxStream e seus 20 pinos ................. 21
Figura 2.14: Diagrama de fluxo do mdulo ZigBee ..................................... 23
Figura 2.15: Camadas das formas de implementao do MODBUS .......... 24
Figura 2.16: Modelo de um pacote MODBUS ............................................... 24
Figura 2.17: Kit de desenvolvimento Altera para o Nios II.......................... 26
Figura 2.18: Hardwares de referncia para prototipao do Nios II .......... 28
Figura 3.1: Atual modelo de automao de bombas de petrleo .............. 46
Figura 3.2: Esboo do sistema de instrumentao por rdio freqncia . 48
Figura 3.3: Leitura de tenso e corrente no primrio do motor ................. 49
Figura 3.4: Medio da velocidade do redutor. ........................................... 50
Figura 3.5: Medio da velocidade do motor. .............................................. 50
xii

Figura 3.6: Bancada de testes para torque esttico .................................... 52
Figura 3.7: Bancada de torque dinmico com eixo para frenagem ........... 52
Figura 3.8: Prottipo com manivela e contrapeso ...................................... 52
Figura 3.9: Simulador de UBM proporcional a unidade real. ...................... 53
Figura 3.10: Unidade de bombeio da PETROBRAS utilizada para testes . 54
Figura 3.11: PC embarcado utilizado para testes ........................................ 55
Figura 3.12: Conversor A/D utilizado para testes ........................................ 55
Figura 3.13: Mdulo ZigBee utilizado para testes. ...................................... 56
Figura 3.14: Abraadeira contendo a unidade remota ................................ 57
Figura 3.15: Unidade base usada para testes .............................................. 58
Figura 3.16: Interface do sistema MUB. ....................................................... 58
Figura 3.17: Mdulo de aquisio ................................................................. 59
Figura 3.18: Mdulo de tratamento de dados .............................................. 59
Figura 3.19: Mdulo de visualizao ............................................................ 60
Figura 3.20: Sinais dos sensores de posio e extensmetros. ................ 61
Figura 3.21: Grfico torque x ngulo ............................................................ 61
Figura 3.22: Grficos de corrente, e potncia calculada. ........................... 62
Figura 3.23: Medidas de corrente (branco) e tenso (vermelho) ............... 63
Figura 3.24 Grficos das potncias ativa, reativa e aparente. ................. 64
Figura 3.25: Curvas de torque pelos dois mtodos. ................................... 64
Figura 3.26: Torque observado no momento da quebra da haste polida .. 65
Figura 3.27: Curva interpolada do antigo mtodo de automao .............. 66
Figura 3.28: Curva de valores mais precisos obtida com extensmetros 66
Figura 3.29: Curva com valores referente potncia no motor ................. 67
Figura 4.1: Modelo arquitetural de um sistema embarcado ....................... 70
xiii

Figura 4.2: Camada de hardware .................................................................. 71
Figura 4.3: Camada de sistemas de software .............................................. 72
Figura 4.4: Camada de aplicao .................................................................. 74
Figura 4.5: Diagrama de blocos de comunicao entre PIO e USB ........... 78
Figura 4.6: Comunicao entre a interface USB e o controlador USB ...... 79
Figura 4.7: Ciclo de escrita pra o DLP-USB245M ........................................ 80
Figura 4.8: Ciclo de escrita pra o DLP-USB245M ........................................ 81
Figura 4.9: Algoritmos de transmisso e recepo de dados pela USB ... 83
Figura 4.10: Transmissor de RF ao lado das unidades de bombeio. ........ 85
Figura 4.11: Modelo do pacote ModBus TCP ............................................... 86
Figura 4.12: Diagrama de transmisso ZigBee. ........................................... 91
Figura 4.13: Modelo P-CAD da placa de recepo ZigBee ......................... 92
Figura 4.14: PCB contendo modelo de placa de recepo ZigBee ............ 92
Figura 4.15: Esquema eltrico da placa de recepo ZigBee. .................... 93
Figura 4.16: Prottipos com o circuito de recepo e o mdulo ZigBee .. 93
Figura 5.1: Fluxo de funcionamento do SoPC Builder ................................ 96
Figura 5.2: Arquitetura no SOPC Builder ..................................................... 96
Figura 5.3: Viso das funcionalidades do Nios II IDE ................................. 99
Figura 5.4: Abstrao de hardware do sistema de bibliotecas HAL ........ 100
Figura 5.5: DLP-USB245M. .......................................................................... 101
Figura 5.6: FT245BM. ................................................................................... 101
Figura 6.1: Tela inicial do sistema. ............................................................. 103
Figura 6.2: Sistema conectando ................................................................. 104
Figura 6.3: Status da unidade de bombeio ................................................ 105
Figura 6.4: Tela do programa para iniciar/parar a aquisio constante .. 106
xiv

Figura 6.5: Funcionamento completo do sistema. .................................... 107
Figura 6.6: Senide gerada atravs de um gerador de ondas. ................. 108
Figura 6.7: Funo dente de serra .............................................................. 108
Figura 6.8: Onda quadrada .......................................................................... 109
Figura 6.9: modulo ZigBee o gerador de ondas utilizado ......................... 109
Figura 6.10: Imagem com o prottipo instalado. ....................................... 110
Figura A.1: Diagrama de casos de uso ...................................................... 127
Figura A.2: Diagrama de sequncia (Aquisio RF) ................................. 128
Figura A.3: Diagrama de sequncia (Aquisio CAD) .............................. 128
Figura A.4: Diagrama de sequncia (Envio dos Dados) ........................... 129
Figura A.5: Diagrama de atividades ............................................................ 130
Figura A.6: Diagrama de componentes ...................................................... 131
Figura A.7: Diagrama de distribuio ......................................................... 132
Figura B.1: Sercref para automao residencial ....................................... 138
Figura B.2: Status dos dispositivos monitorados da casa. ...................... 139
Figura B.3: Estrutura onde o prottipo est sendo instalado. ................. 139
Figura B.4: Interface mostrando as medidas realizadas em cada trem . 142
Figura B.5: Interface para mostrar as medidas de um trem especifico. .. 143
Figura B.6: Amostras ................................................................................... 144
Figura B.7: Grfico indicando a velocidade do trem. ................................ 144
Figura B.8: Grfico da presso exercida pelo trem ................................... 145
xv

Lista de Tabelas

Tabela 2.1: Descrio dos 20 pinos presentes no ZigBee MaxStream. ..... 22
Tabela 4.1: Tempos para leitura estabelecidos pelo fabricante do DLP ... 80
Tabela 4.2: Tempos para escrita estabelecidos pelo fabricante do DLP. . 81
Tabela 4.3: Pacotes ModBus criados para controle das UB. ..................... 89
Tabela 6.1: Caractersticas da arquitetura desenvolvida para o sistema.111
Tabela 6.2: Comparao das tecnologias de automao de bombas ..... 112
Tabela B.1: Pacotes ModBus utilizados na automao residencial. ....... 138

xvi

Sumrio

Sumrio .......................................................................................................... xvi
CAPTULO 1 ...................................................................................................... 1
Introduo ......................................................................................................... 1
1.1 Motivao .......................................................................................................... 1
1.2 Objetivos ........................................................................................................... 2
1.3 Organizao ...................................................................................................... 4
CAPITULO 2 ...................................................................................................... 5
Fundamentao Terica .................................................................................. 5
2.1 Sistemas Embarcados ...................................................................................... 5
2.1.1 O que um sistema embarcado? ................................................................. 6
2.1.2 Sistemas embarcados de tempo real ........................................................... 7
2.1.3 Mudanas de Projetos de Sistemas Embarcados ........................................ 8
2.1.4 Exemplos de aplicaes ............................................................................... 9
2.2 Computao Reconfigurvel .......................................................................... 13
2.2.1 FPGAs ....................................................................................................... 13
2.3 Protocolo ZigBee ............................................................................................ 16
2.3.1 Arquitetura ................................................................................................. 17
2.3.2 Protocolo ZigBee e Redes de Sensores sem Fios...................................... 19
2.3.3 Hardware ZigBee ....................................................................................... 21
2.4 Protocolo ModBus .......................................................................................... 23
2.5 Processador Nios II ......................................................................................... 25
2.6 Linguagens de programao ......................................................................... 28
2.6.1 Linguagem C .............................................................................................. 28
xvii

2.6.2 Linguagem Java ......................................................................................... 30
2.6.3 Linguagem LabView ................................................................................... 32
2.6.4. Linguagem VHDL (VHSIC Hardware Description Language) .................... 35
2.7 Barramento USB ............................................................................................. 37
2.8 Bases de dados ............................................................................................... 38
Captulo 3 ........................................................................................................ 42
Medio de Torque ......................................................................................... 42
3.2 Sistemas de Automao de Unidades de Bombeio de Petrleo ................. 44
3.2.1 Atual Modelo de Automao ...................................................................... 45
3.3 Torqumetro Dinmico Telemtrico ............................................................... 47
3.4 Torque Atravs dos Parmetros Eltricos do Motor e Perda da Correia .... 49
3.5 Teste e Validao ............................................................................................ 51
3.5.1 Prottipos para obteno de torque ........................................................... 51
3.5.2 Sistema de Testes e Validao .................................................................. 54
3.5.3 Resultados Obtidos .................................................................................... 60
Capitulo 4 ........................................................................................................ 68
Sistema Embarcado para Automao de Bombas de Petrleo ................. 68
4.1 Arquitetura....................................................................................................... 69
4.1.1 Camada de Hardware ................................................................................ 70
4.1.2 Camada de Sistema de Software ............................................................... 71
4.1.3 Camada de Aplicao de Software ............................................................ 73
4.2 Componentes da Arquitetura ......................................................................... 75
4.2.1 PIO (Parallel input/output) .......................................................................... 75
4.2.2 JTAG Uart .................................................................................................. 76
4.2.3 Ncleo Nios II ............................................................................................. 77
xviii

4.2.4 Ethernet MAC ............................................................................................. 77
4.2.5 Controlador SDRAM ................................................................................... 77
4.2.6 Controlador USB ........................................................................................ 78
4.2.7 Controlador ZigBee e ModBus ................................................................... 83
4.2.8 Controlador Serial ...................................................................................... 84
4.2.9 Controlador ADC ........................................................................................ 84
4.3 Implementao do Empacotador MODBUS .................................................. 84
4.4 Funcionamento do Sistema ........................................................................... 89
4.5 Circuito ZigBee de Recepo ......................................................................... 90
CAPTULO 5 ................................................................................................... 94
Ferramentas e Metodologia ........................................................................... 94
5.1 Softwares Utilizados para Desenvolvimento ................................................ 95
5.1.1 SoPC Builder .............................................................................................. 95
5.1.2 Plataforma de Desenvolvimento de Software Nios II .................................. 97
5.2 Interface USB ................................................................................................ 100
CAPITULO 6 .................................................................................................. 102
Resultados .................................................................................................... 102
6.1 SERCREF ....................................................................................................... 102
6.2 Monitoramento de Unidades de Bombeio de Petrleo ............................... 106
6.3 Configurao do Hardware Utilizado ........................................................... 110
6.4 Comparao do Sistema Proposto com outros Sistemas ......................... 111
6.4.1 Controlador CAC ...................................................................................... 112
6.4.2 Controlador ZAP ...................................................................................... 113
6.4.3 Controlador Lufkin .................................................................................... 113
6.4.4. Sercref .................................................................................................... 114
6.4.5 Comparao................................................................................................113
xix

CAPITULO 7 .................................................................................................. 116
Concluses e Trabalhos Futuros ................................................................ 116
Referncias Bibliogrficas .......................................................................... 118
APNDICE A ................................................................................................. 123
Modelagem do Sistema Embarcado ........................................................... 123
A.1 O uso da UML ............................................................................................ 124
A.2 Diagramao ................................................................................................. 125
A.2.1 Casos de Uso .......................................................................................... 126
A.2.2 Diagramas de Seqncia ......................................................................... 127
A.2.3 Diagrama de Atividades ........................................................................... 129
A.2.4 Diagrama de Componentes ..................................................................... 130
A.2.5 Diagrama de Distribuio ......................................................................... 132
APNDICE B ................................................................................................. 133
Aplicabilidade do Sistema Embarcado Reconfigurvel Proposto ........... 133
B.1 Automao Residencial ............................................................................... 133
B.1.1 Sercref na Automao de Residncias .................................................... 134
B.1.2 Funcionamento ........................................................................................ 135
B.1.3 Testes ...................................................................................................... 135
B.2 Automao de Trens .................................................................................... 140
B.2.1 Aplicao do Secref na automao de Trens ........................................... 140
B.2.2 Funcionamento ........................................................................................ 141
B.2.3 Testes ...................................................................................................... 142

xx

1

CAPTULO 1

Introduo

1.1 Motivao
A evoluo das metodologias de projeto de hardware, apoiadas em
poderosas ferramentas de software que aceleram o ciclo de desenvolvimento,
e especialmente o surgimento de dispositivos reconfigurveis como os FPGA
(Field-Programmable Gate Arrays) abriu um novo horizonte entre os extremos
da computao de finalidade geral e o hardware dedicado. Os FPGAs
combinam a flexibilidade de dispositivos programveis, como PLD e
microprocessadores de finalidade geral, com o desempenho do hardware de
finalidade especfica, como o ASIC. (BROWN, 1997).
Ao mesmo tempo, os sistemas de automao vm sofrendo um
processo de evoluo na sua configurao, principalmente atravs da
utilizao de redes de sensores sem fios para monitoramento e controle de
dispositivos. A princpio o alto custo para implementao e o alto consumo de
energia desses sensores inviabilizava as mudanas no sistema. Hoje, a grande
concorrncia e a busca por qualidade aliada ao baixo consumo levaram as
empresas necessidade de substituio de seus grandes sistemas de
controle.
At agora os avanos realizados nos processos de determinao de
torque no foram muito relevantes. Por isso, diversas empresas de extrao de
petrleo continuaram com as suas antigas formas de automao. Entretanto
um novo torqumetro, proposto por Lima Filho, (2007) e Anjos (2008) permite
uma alta preciso na determinao dos valores de torque, pois, agora, o
2

mesmo no ser mais calculado, e sim medido diretamente nos equipamentos
das bombas de petrleo. Atravs dessa medio os valores se tornam bastante
precisos levando ao aumento da credibilidade no processo. Este torqumetro foi
patenteado e divulgado em congressos, obtendo prmios pela inovao
tecnolgica aplicada.
As atuais arquiteturas de automao no permitem uma expanso
satisfatria para a evoluo dos sistemas de automao. Devido a isso, muitas
empresas continuam a utilizar os mtodos antigos de automao, o que faz
necessrio um sistema que alm de permitir a possibilidade de substituio do
sistema sem modificao de hardware, possa ser integrado facilmente s
arquiteturas j existentes sem muitas mudanas. Uma implementao em
hardware levaria aos mesmos problemas enfrentados at agora,
impossibilitando expanso futura. Por isso, uma arquitetura reconfigurvel se
coloca como tcnica essencial para uma evoluo dessa tecnologia.
O desenvolvimento de um torqumetro dinmico telemtrico no LES
(Laboratrio de Energia Solar da UFPB) aumentou a exatido na determinao
do torque nas unidades de bombeio. Entretanto a atual tecnologia utilizada nos
controladores lgicos no aceitava a arquitetura do torqumetro e tambm no
permitia uma evoluo para se adequar ao mesmo. Essa foi uma das principais
motivaes para o desenvolvimento do sistema embarcado reconfigurvel.
1.2 Objetivos
Nosso objetivo geral consistiu no desenvolvimento de um sistema
embarcado reconfigurvel que permite a expanso e integrao dos mtodos
de automao de bombas de petrleo j existentes, alm de permitir a criao
de novos sistemas que j possuam uma arquitetura reconfigurvel. Esse
sistema possibilita a integrao do Torqumetro Dinmico Telemtrico proposto
por Lima Filho, (2007) e Anjos, (2008) e recentemente criado, ao atual sistema
de automao de poos dos campos de extrao de petrleo. Alm disso,
importante que essa nova tecnologia no obrigue grandes mudanas nos
atuais processos, levando a altos custos e tornando-se invivel.
3

O sistema deve possuir flexibilidade na atualizao de softwares;
oferecer de forma simples possibilidades de expanso e ser de fcil
manuteno. Para isso alm dos sistemas de testes criados, diversos estudos
foram realizados visando uma implementao completa e funcional do sistema.
Estudos de diagramao, pinos de transmisso de dados dos dispositivos e
arquiteturas de desenvolvimento foram realizados.
A computao reconfigurvel, aliada ao poder de um processador
embarcado foram utilizados de forma a atuarem satisfatoriamente no projeto.
Alm disso, propostas de melhorias em alguns processos de automao foram
realizadas e implementadas. Essas melhorias possibilitaram no somente a
criao do sistema para automao de poos de petrleo como permitiu uma
aplicabilidade em outras formas de automaes de redes de sensores sem fios,
como o caso da automao de trens e automao residencial (criao das
chamadas casas inteligentes). Essa aplicabilidade mostrada no apndice B
como estudo de caso.
Os principais objetivos do sistema so:
Customizao do processador Nios II para atender as funcionalidades
do projeto;
Implementao do mdulo de desempacotamento, tratamento e
empacotamento dos dados recebidos da rede de sensores sem fios que
ficar interno FPGA;
Desenvolvimento de um circuito capaz de receber um mdulo de
tecnologia ZigBee (protocolo que ser utilizado na rede de sensores) e
disponibilizar os valores recebidos para a FPGA;
Desenvolvimento de controladores para atuar junto ao Nios II
internamente a FPGA. Dentre eles: USB, MODBUS e ZigBee;
Criao de um sistema em JAVA que possa simular e testar os dados
finais recebidos pelo protocolo MODBUS, para avaliar a integrao
dessa tecnologia com os muitos sistemas de automao que utilizam
esse protocolo;
4

Implementao de um sistema de testes para mostrar que o
desenvolvimento dessa tecnologia vivel e necessrio.
Criao de uma base de dados para armazenamento das informaes e
disponibilizao para um servidor WEB.
1.3 Organizao
No Captulo II ser realizada uma fundamentao terica para introduzir
os principais conceitos que sero utilizados neste trabalho servindo como base
para entendimento do mesmo. O Captulo III mostra como realizado o atual
sistema de automao de unidades de bombeamento mecnico de petrleo
(UBM) na maior parte do mundo e detalha o funcionamento das novas tcnicas
desenvolvidas s quais este trabalho aplicado, alm disso, mostra o sistema
de testes desenvolvido como forma de validao da idia inicial proposta. No
captulo IV, detalharemos o sistema desenvolvido desde a sua arquitetura e
componentes de hardware sua implementao e funcionamento. No Captulo
V as ferramentas e a metodologia utilizada para desenvolvimento so
abordadas. O Captulo VI contm os resultados obtidos atravs do sistema
desenvolvido e uma comparao deste trabalho com outras tecnologias
existentes. No Captulo 7, por fim, algumas concluses, trabalhos futuros e em
andamento so citadas como forma de contribuir para a continuidade de
utilizao das idias aqui propostas e implementadas. Nos apndices finais a
diagramao UML e alguns estudos de caso so mostrados.
5

CAPITULO 2

Fundamentao Terica

Este captulo limita-se apresentao dos principais conceitos tcnicos
e tericos necessrios ao desenvolvimento deste trabalho. Aqui so descritas
as diversas tecnologias utilizadas, desde dispositivos de hardware, passando
por protocolos e padres adotados e finalizando com as linguagens de
programao utilizadas.
2.1 Sistemas Embarcados
Um dos mais surpreendentes desenvolvimentos tecnolgicos das
ltimas dcadas tem sido a utilizao de computadores para afazeres
humanos. Hoje, a maioria dos computadores que existem no mundo, est em
nossas casas e escritrios e muitas vezes possumos mais computadores em
uma casa do que mesmo em um escritrio onde vrias pessoas trabalham
diretamente com eles. Assim, quando perguntamos a uma pessoa quantos
computadores ela possui, e a mesma responde apenas um, esta no leva em
considerao de que possui inmeros computadores embutidos na maioria dos
equipamentos que utiliza.
At poucas dcadas atrs era difcil de imaginar que os sistemas
embarcados iriam modificar drasticamente o modo como as pessoas vivem,
trabalham e se comunicam. Os sistemas embarcados apareceram em diversas
aplicaes, cada uma com caractersticas nicas. De acordo com um estudo
realizado por Tennenhouse (2000), e que ainda reflete o cenrio atual, somente
2% dos processadores produzidos so utilizados em computadores
convencionais (desktops e notebooks). O restante se encontra embarcado em
6

dispositivos como organizadores pessoais, eletrodomsticos, robs, veculos e
aeronaves.
Sistemas embarcados (ou sistemas embutidos) so utilizados
largamente na indstria. Esse fato acompanhou a histria desde o surgimento
dos primeiros microprocessadores, fornecendo solues digitais de baixo custo
e boa confiabilidade segundo Heath (2003). Existem diversas formas para se
dizer o que um sistema embarcado, entretanto, de acordo com Ganssle
(1999), a melhor forma de defini-lo com o uso de exemplos de como ele
usado, como veremos a seguir.
2.1.1 O que um sistema embarcado?
Um sistema embarcado a combinao de hardware, software e, a
utilizao ou no de peas mecnicas e outras partes, projetadas para
desempenhar uma funo especfica. Um bom exemplo o forno de
microondas. A maioria das residncias possui um e milhares so utilizados
todos os dias. Entretanto, poucas pessoas percebem que um processador e
um software esto envolvidos na preparao do seu almoo ou jantar. (BARR,
1999)
Isto est em contraste com o computador pessoal (PC) que possumos
em casa. Ele constitudo de hardware, software e equipamentos mecnicos
como o disco rgido. No entanto ele no foi projetado para desempenhar uma
funo especfica, pelo contrrio, capaz de fazer diversas tarefas diferentes.
Muitas vezes ouvimos o termo computadores de propsito geral para tornar
essa distino clara. Quando desenvolve um PC, o fabricante no sabe o que o
cliente vai fazer com ele. Um pode utiliz-lo como servidor de arquivos em uma
rede, enquanto outro utiliza exclusivamente para jogos e um terceiro apenas
redige e imprime textos ou assiste a um filme.
J um sistema embarcado possui uma funo bem clara e especfica.
Geralmente so produzidos em larga escala e se encontram dentro de um
sistema maior. Como exemplo, podemos citar diversos automveis que
circulam todos os dias. Diversos sistemas embutidos podem ser encontrados
em funcionamento nos mesmos. Enquanto um serve para abrir o vidro de uma
7

janela, o outro serve para controlar a velocidade do veculo e talvez ajustar
retrovisores. Muitas vezes esses sistemas embarcados formam uma rede de
sistemas podendo at comunicar-se um com o outro, embora isso no seja
obrigatrio.
2.1.2 Sistemas embarcados de tempo real
Uma classe especial desses sistemas distingue-se do restante devido
aos requisitos temporais de reposta a eventos externos. Essa categoria
classificada como sistemas em tempo real (real-time systems). (CASIMIRO;
KAISER; VERISSIMO, 2004)
Os sistemas embarcados de tempo real, como comumente so
conhecidos, so sistemas que possuem limitaes com relao ao tempo. Em
outras palavras, so sistemas que possuem suas caractersticas de resolver
clculos ou determinadas decises de forma temporal. Essas importantes
tarefas so realizadas com um determinado prazo a ser completado, e a perda
de um prazo considerada como um erro grave, como um mau funcionamento
do sistema. (BARR, 1999)
A questo em saber se um prazo cumprido, crucial para o bom
desempenho do sistema. Por exemplo, se um sistema em tempo real que
controla alguma funcionalidade de uma aeronave tem uma falha no
cumprimento de um prazo, os passageiros podem correr risco de vida pela
operao irregular da aeronave. Entretanto em uma comunicao em uma rede
sem fios que possua um sistema em tempo real o no comprimento do prazo
pode simplesmente significar a perda ou corrupo de um pacote de dados.
O projetista de um sistema em tempo real deve ser bastante diligente em
sua obra. Ele deve garantir o funcionamento correto de software e hardware
em quaisquer circunstncias possveis. E quando o sistema atinge o grau onde
vidas humanas dependem dele, o mesmo deve possuir uma engenharia de
clculos e ser bem descrito atravs de documentaes. (GANSSLE, 1999)
8

2.1.3 Mudanas de Projetos de Sistemas Embarcados
Ao contrrio dos softwares de propsitos gerais, os sistemas
embarcados, no podem simplesmente ser transportados para outros
dispositivos e serem normalmente executados sem modificaes significativas.
Isto se deve principalmente s incrveis variaes nas camadas de hardware.
Os projetos de hardware so adaptados para cada sistema embarcado em
desenvolvimento, para que os custos sejam reduzidos. Assim, qualquer circuito
desnecessrio eliminado do projeto.
Segundo Barr (1999) por definio, um sistema embarcado possui um
processador e um software que ser executado. Entretanto, outras
caractersticas comuns podem ser levadas em considerao como tempo de
desenvolvimento, custo, nmero de unidades e tempo de vida. Certamente, se
possumos um software, precisamos de um local para armazenar o cdigo
executvel e os dados manipulados em tempo de execuo. Este
armazenamento se dar atravs de memrias ROM e RAM, respectivamente,
embora alguns sistemas s possuam uma delas.
Alm disso, todos os sistemas devem tambm conter algum tipo de
entrada e sada. Por exemplo, no forno microondas, o painel para escolha do
tipo de comida, tempo, potncia, podem ser as entradas, e a radiao, o
controle de temperatura e o sinal sonoro de trmino as sadas. A Figura 2.1
mostra o modelo bsico de um sistema embarcado.

Figura 2.1 Diagrama bsico de um sistema embarcado.
9

Com a exceo de algumas dessas caractersticas comuns, o resto do
sistema geralmente nico. Esta variao se deve principalmente aos muitos
critrios de desenvolvimento. Cada sistema deve satisfazer um conjunto
completamente diferente de requisitos os quais podem afetar o sucesso ou
defeitos no desenvolvimento.
2.1.4 Exemplos de aplicaes
Os sistemas embarcados esto inseridos em milhares de dispositivos
comuns utilizados no dia a dia como em eletrodomsticos, aparelhos de udio
e vdeo, celulares e outros (GUPTA, 2002). A Seguir alguns exemplos de
aplicaes:
a) Setor Automobilstico
Um veculo que j possua equipamentos sofisticados possui diversos
sistemas embarcados em funcionamento. Centenas de sensores fornecem
informaes sobre todo o funcionamento do veculo. Diversos sistemas com
unidades de processamento independentes atuam em diversas funcionalidades
e se comunicam entre si, captando os sinais destes sensores e fazendo com
que as aes referentes a cada caso sejam tomadas.

Figura 2.2 Sistemas embarcados em um veculo.
b) Aquisio de Dados Data Logger
A aquisio de dados, um exemplo de aplicao mais utilizada em
sistemas embarcados, consistem de sistemas que atravs de sensores
(temperatura, umidade, pH e outros) capturam as variveis ambientes a serem
analisadas e so gravadas em memria para consultas posteriores. O Sistema
10

alm de monitorar o ambiente, com adio de atuadores ao projeto, pode ter a
capacidade de controlar as variveis ambiente com base em um critrio
estabelecido pelo projetista do sistema.

Figura 2.3 Data logger para temperatura do ar.
c) Propsito Geral
Estas aplicaes englobam diversos tipos de dispositivos e so muito
parecidos com computadores de propsitos geral, pois possuem uma grande
quantidade de interao com usurios, geralmente utilizando vdeos,
monitores, udio, etc. Como exemplo tem se os videogames, os conversores
de TV a cabo, caixas de banco.

Figura 2.4 Nintendo Wii e sua grande interao com o usurio
11

d) Sistemas de Controle
So sistemas mais robustos e dedicados, geralmente com realimentao
e execuo em tempo real. Devido importncia das aplicaes geralmente
so sistemas crticos e necessitam de aplicaes robustas, com partes
dedicadas e mltiplos sinais de entrada e sada. Usados nos motores de
automveis, processos qumicos, controle de vo, usinas nucleares, aplicaes
aeroespaciais e monitoramento e controle de variveis ambiente (temperatura,
umidade, pH do ar).

Figura 2.5 Sistema de controle industrial
e) Processamento de Sinais
Ocorrem em sistemas que envolvem um grande volume de informao a
ser processada em curto espao de tempo. Os sinais a serem tratados so
digitalizados atravs de conversores Analgico/Digital, processados e
novamente convertidos em sinais analgicos por conversores Digital/Analgico.
Casos de tratamento de udio, filtros, modems, compresso de vdeo, radares
e sonares, etc. Existem os DSP (Digital Signal Processor Processador Digital
12

de Sinais) os microcontroladores dotados deste recurso so os Blackfin da
Analog Devices e o DsPIC da Microchip.

Figura 2.6 Ambiente de desenvolvimento DSP para o dsPIC.
f) Comunicaes, Redes e TV Digital
Chaveamento e distribuio de informaes. Sistemas de telefonia e
telecomunicaes e internet. Hubs, Switchs e Roteadores so dotados de
microprocessadores e de microcontroladores para controle digital de sinais. Na
TV Digital estes controladores digitais tm um ncleo para processamento
digital de sinais, instalado na antena (smart antennas) e no receptor da TV
Digital, com objetivo de selecionar o melhor foco do canal e eliminar sinais
ruidosos.

Figura 2.7 Roteador Cisco.
13

2.2 Computao Reconfigurvel
Segundo Athanas, (1993) e Olukotun, (1994) a principal caracterstica da
computao reconfigurvel (reconfigurable computing RC) a presena de
um hardware que pode ser reconfigurado para implementar uma funcionalidade
especfica mais apropriada e sob medida, e no um processador de propsito
geral. Sistemas de RC unem os microprocessadores e o hardware programvel
com a finalidade de combinar o potencial do hardware e do software e ser
utilizado em aplicaes que vo desde um sistema embarcado a sistemas de
alta performance computacional.
Embora os conceitos bsicos tenham sido propostos na dcada de 60, a
RC s veio ser praticvel recentemente. Durante a ltima dcada um grande
nmero de sistemas de RC desenvolvidos pela comunidade cientfica tm
demonstrado o potencial para atingir alta performance para uma diversidade de
aplicaes. No entanto, as melhorias em desempenho desses sistemas
dependem normalmente da experincia de projetistas de hardware. Este
mtodo de programao, entretanto, no pode explorar plenamente o atual
aumento de densidade dos dispositivos reconfigurveis. Surge ento o desafio
atual de criar um compilador eficiente que ajude o projetista a possuir um
desempenho adequado, realizando melhorias, sem estarem envolvidas
complexas manipulaes em baixo nvel de programao.
2.2.1 FPGAs
Field Programmable Gate Arrays (FPGAs) so circuitos integrados
digitais que contm blocos lgicos reconfigurveis (reprogramveis), chamados
de CLB (Configuration Logical Blocks) que so formados por portas lgicas e
flip-flops que implementam funes lgicas, e interconexes entre eles que
tambm podem ser rearranjadas. Engenheiros de projetos podem reconfigurar
estes dispositivos para uma enorme variedade de tarefas. Dependendo da
maneira como implementada, alguns FPGAs podem ser reprogramados
somente uma vez, enquanto outras podem ser diversas vezes reconfigurados.
(MAXFILED, 2004). O modelo de um FPGA pode ser visto na Figura 2.8.
14

Figura 2.8: Modelo de uma FPGA da Altera
O termo Field programmable do nome FPGA refere-se ao fato de que
estes possuem uma rea reservada para programao em oposio aos
dispositivos que possuem suas funcionalidades implementadas diretamente em
hardware durante a sua fabricao. Isto significa que eles podem ser
implementados em laboratrio ou possvel reconfigurar a funo de um
dispositivo que j tenha sido implementado em algum sistema com alguma
funcionalidade especfica. Um esboo de um FPGA pode ser visualizado na
Figura 2.9.

Figura 2.9: Esboo de um FPGA
Disponvel em:
www.altera.com
15

O FPGA tambm formado por estruturas chamadas de blocos de
entrada e sada (IOB In/Out Blocks), os quais so responsveis pelo
interfaceamento entre as sadas provenientes das combinaes de CLBs. A
tpica estrutura interna de um bloco lgico configurvel de um FPGA consiste
em flip-flops, um determinado nmero de multiplexadores e uma estrutura de
funo combinatria para implementar as funes lgicas.
Os PLDs (Programmable Logic Devices) so dispositivos cuja
arquitetura interna predeterminada na fabricao, mas so criadas de tal
forma que podem ser configuradas por engenheiros para executar uma
variedade de diferentes funes. Em comparao com os FPGAs, esses
dispositivos contm um limitado nmero de portas lgicas e as funes que
eles podem implementar so geralmente muito pequenas e simples.
Os ASICs (Applications-Specific Integrated Circuits), por outro lado,
oferecem um maior desempenho, complexidade e tamanho (nmero de
transistores), entretanto projetar e construir um um processo extremamente
demorado e caro, acrescentado a desvantagem de que o processo final
congelado em uma pastilha de silcio e no pode ser modificada sem a
criao de um novo dispositivo. (MAXFILED, 2004)
Um FPGA ocupa um grupo entre os ASICs e os PLDs, pois suas
funcionalidades podem ser customizadas como um PLD e podem possuir
milhes de portas lgicas possibilitando a utilizao na implementao de
grandes e complexas funes que s poderiam ser feitas utilizando os ASICs.
O custo de um projeto para FPGAs muito mais baixo que dos ASICs, embora
este sejam mais baratos para produes em larga escala. Ao mesmo tempo a
implementao pode ser mudada diversas vezes, alm de se tornar bastante
rpida.
Existem diversos fabricantes de FPGA que atuam no desenvolvimento
de diversos tipos de chips com as mais variadas funcionalidades. Entre eles
podemos citar: Altera, Xilinx, Actel, Atmel, National Instruments entre muitos
outros.
16

2.3 Protocolo ZigBee
Atualmente o foco das redes wireless comerciais se encontra no
contexto das redes locais (WLANs), tanto em solues proprietrias como nos
padres desenvolvidos pelo IEEE, por exemplo. Com a evoluo natural das
tecnologias das redes sem fio, estas passaram a atender no s as aplicaes
corporativas mais sofisticadas como tambm aquelas envolvendo pequenos
volumes de dados que exigem baixas taxas de transmisso como, por
exemplo, o controle de equipamentos eletroeletrnicos. Alm disso, outras
tecnologias sem fio tm sido utilizadas tambm com o objetivo de proporcionar
a comunicao pessoal e o controle de dispositivos diversos, so as chamadas
redes pessoais (WPANs).
Basicamente, essas tecnologias tm o propsito de permitir o controle
remoto de equipamentos domsticos (televisores, videocassetes, geladeiras,
etc) e perifricos (teclados, mouse, impressoras, etc), eliminando os cabos e
tornando mais prtica a operao desses equipamentos pelos usurios.
Uma das tecnologias mais recentes dentro desse grupo de redes para
aplicaes pessoais e que permite o gerenciamento e controle desses
dispositivos o padro ZigBee, tambm conhecido como HomeRF Lite e que
corresponde ao IEEE 802.15.4. O ZigBee comeou de fato no ano de 2002
como um padro global e aberto para a comunicao sem fio de baixo custo e
pequeno alcance, com caractersticas adequadas para uso nos dispositivos
utilizados no dia a dia das pessoas. Ele foi desenvolvido pela ZigBee Alliance
junto ao IEEE. A ZigBee Alliance uma associao que conta com mais de 45
empresas que trabalham em conjunto para desenvolver um padro capaz de
possibilitar um controle seguro, de baixo custo e de baixa potncia em redes
sem fio. O padro ZigBee utilizado para o controle de diversos equipamentos,
incluindo solues para a automao predial, aplicaes em telemedicina e
entretenimento (jogos). (PINHEIRO, 2004)
Segundo Eduardo Prado, Num futuro no muito distante, no ser difcil
contar pelo menos 50 chips de "ZigBee" numa residncia. Eles sero
encontrados nos interruptores de lmpadas, em detectores de fogo e fumaa,
17

termostatos, eletrodomsticos na cozinha, e em controle remotos de vdeo e
udio. (PRADO, 2006)
O padro oferece atualmente interfaces com velocidades de conexo
compreendidas entre 10Kbps e 250Kbps, freqncias de at 2,4GHz e com um
alcance de transmisso entre 10m e 1000m, dependendo diretamente da
potncia dos equipamentos e de caractersticas ambientais (obstculos fsicos,
interferncia eletromagntica, etc.).
Quanto ao problema de alimentao dos dispositivos, os mdulos de
controle dotados com esta nova tecnologia podem ser alimentados at mesmo
por baterias (pilhas) comuns, sendo que sua vida til est relacionada
diretamente com a capacidade da bateria e a aplicao a que se destina.
Nesse aspecto, o protocolo ZigBee foi projetado para suportar aplicaes com
o mnimo de consumo.
Para se ter uma idia, uma pilha pequena utilizada em casa pode chegar
a 2500mAh. Um ZigBee com diversas funcionalidades consome cerca de
45mAh levando a uma durao de 55,6 horas de funcionamento ininterrupto.
Entretanto essa tecnologia possui diversas alternativas de reduo de
consumo, como um modo de pausa (diz-se que o mdulo est dormindo) em
que o consumo drasticamente reduzido.
2.3.1 Arquitetura
A arquitetura do protocolo ZigBee composta por camadas, sendo que
cada camada executa servios especficos para dispor a camada superior: a
entidade de dados fornece dados para o servio de transmisso e a entidade
de gesto fornece informao para todos os outros servios. Cada entidade de
servio expe uma interface para a camada superior atravs do ponto de
acesso ao servio (SAP) e cada SAP suporta um nmero de primitivas de
servio para ativar a funcionalidade que se pretende solicitar. Embora se
baseie no modelo OSI (Open Systems Interconnection) de sete camadas, a
arquitetura protocolar ZigBee apenas define, no entanto, as camadas de
interesse para atingir as funcionalidades desejadas.
18

De uma forma simplificada, as diferentes camadas podem ser esquematizadas
na Figura 2.10 da seguinte maneira:

Figura 2.10: Camadas do protocolo ZigBee
A definio das camadas fsica e de acesso ao meio da
responsabilidade da norma IEEE 802.15.4. Podemos identificar dois tipos de
dispositivos em uma rede ZigBee, definidos pelo IEEE:
Full Function Device (FFD) - pode funcionar em toda a topologia do padro,
desempenhando a funo de coordenador da rede e conseqentemente ter
acesso a todos os outros dispositivos. Trata-se de dispositivos de construo
mais complexa;
Reduced Function Device (RFD) - limitado a uma configurao com
topologia em estrela, no podendo atuar como um coordenador da rede. Pode
comunicar-se apenas com dispositivos FFD. So dispositivos de construo
mais simples. Podem ser receptores ou roteadores.
Existem diferentes topologias que podem variar de uma arquitetura
estrela passando por um agrupamento de rvores at uma rede mesh (malha).
Em ultimo caso possvel customizar um processo de roteamento adicional.
Possveis arquiteturas de rede ZigBee so apresentadas na Figura 2.11. Redes
em malha permitem aumentar a gama, a confiabilidade e a formao de redes
ad hoc (redes em que cada n possui os mesmos direitos e deveres, no existe
um n central).
19

Figura 2.11: Modelo das redes ZigBee
As aplicaes que utilizam o protocolo e dispositivos ZigBee so
definidas por convenincia, focando gerenciamento de energia e conectividade.
Diversos tipos de aplicaes aceitam esse padro de forma simples e bastante
satisfatria. Na Figura 2.12 podemos ver algumas das aplicaes que podem
utilizar o padro ZigBee.

Figura 2.12: Aplicaes do padro ZigBee
2.3.2 Protocolo ZigBee e Redes de Sensores sem Fios
Redes de Sensores Sem Fio (RSSFs) tm sido viabilizadas pela rpida
convergncia de trs tecnologias: microeletrnica, comunicao sem fio e
micro sistemas eletromecnicos (MEMS Micro Electro-Mechanical Systems).
Uma RSSF uma ferramenta de sensoriamento distribudo de fenmenos,
processamento e disseminao de dados coletados e informaes
20

processadas para um ou mais observadores. O potencial de observao e
controle do mundo real permite que as RSSFs se apresentem como uma
soluo para diversas aplicaes de monitoramento e controle.
Uma rede de monitoramento e controle ou de automao industrial
formada por sensores de grandezas fsicas (temperatura, umidade, presso,
etc.) e dispositivos atuadores (chaves, rels, etc.) no necessita de uma largura
de banda elevada para funcionar, mas sim de uma latncia pequena e baixo
consumo de energia para preservar a vida til das baterias. Segundo Santos
(2007) ainda so poucos os padres de redes sem fio para aplicaes em
redes locais utilizando sensores e outros dispositivos de controle. Um dos
segmentos onde mais tem crescido a aplicao de redes sem fio o das redes
domsticas, principalmente em aplicaes de automao comercial e
residencial. Atualmente encontramos diversos equipamentos controlados
remotamente, desde televisores, home theaters, DVDs, at computadores,
impressoras, etc. Neste contexto, o protocolo ZigBee definido pela ZigBee
Alliance e pelo padro IEEE 802.15.4, surge como uma alternativa para
atender s especificaes dessas aplicaes.
De acordo com Egan (2005) e ZigBee Document, (2004), o protocolo
ZigBee tem sido recentemente considerado um bom candidato para uso em
ambientes industriais. Ele apresenta algumas vantagens importantes sobre os
demais protocolos de comunicao como o WiFi e Bluetooth por exemplo. Seu
consumo de energia geralmente mais baixo que nas redes com WiFi ou
Bluetooth. Uma caracterstica importante do ZigBee que o diferencia dos outros
protocolos que ele permite expandir uma rede atravs de milhares de ns.
Teoricamente, uma rede ZigBee pode conter cerca de 65.536 ns, embora, na
prtica no recomendvel exceder 3000 ns em uma rede. Outra vantagem
dos dispositivos ZigBee a velocidade com que novos ns podem ser
adicionados a rede: 30ms; enquanto que um n que estava em estado de sono
pode ser acordado em 15ms, e ento comear a comunicao com outros ns
da rede. Este aspecto pode ser vital para muitas aplicaes industriais. (IEEE,
2008)
21

Para garantir a eficcia no desenvolvimento de sistemas de aquisio de
dados que utilizam tecnologia de transmisso por freqncia de rdio, faz-se
necessrio um estudo sobre os principais aspectos que influenciam o
desempenho destas tecnologias. Em Santos (2007) apresentado um estudo
do protocolo ZigBee sobre diferentes cenrios que levam em considerao
caractersticas como interferncia interna, confiabilidade, latncia e taxa de
dados de uma rede ZigBee.
2.3.3 Hardware ZigBee
Dentre as principais e mais conhecidas empresas que trabalham junto
aliana ZigBee podemos citar: Maxtream, Atmel, Radiocrafts, Texas
Instruments, Freestar. Cada empresa desenvolve diversos tipos de chips que
utilizam o protocolo ZigBee e possuem diversas funcionalidades.
Cada empresa desenvolve chips ZigBee com funcionalidades diferentes.
Muitas vezes em um pequeno circuito possvel encontrar diversas
funcionalidades como conversores analgico/digital, potencimetros, entradas
digitais e analgicas, e muitas outras tecnologias embutidas.
Um modelo de um chip ZigBee da MaxStream e os seus pinos
mostrado na Figura 2.13. Atravs da Tabela seguinte podemos ver os pinos
disponveis nesse mdulo ZigBee e quais so as funcionalidades de cada pino.
A funo de um pino do circuito definida atravs do firmware contido no chip.
Utilizando-se um programa disponibilizado pelo fabricante possvel atribuir as
caractersticas desejadas como, por exemplo, se aquele pino deve ser utilizado
como uma entrada analgica ou at mesmo uma sada digital.

Figura 2.13: Modelo do ZigBee da MaxStream e seus 20 pinos
22

Pino Nome Direo Descrio
1 VCC - Alimentao
2 DOUT Sada Sada de dados da UART
3 DIN / CONFIG Entrada Entrada de dados UART
4 DO8 Sada Sada digital 8
5 RESET Entrada Reinicia o mdulo
6 PWM0 / RSSI Sada Sada PWM 0 / RSSI
7 PWM1 Sada Sada PWM 1
8 [Reservado] - No conectado
9 DTR / SLEEP_RQ/ DI8 Entrada
Pino de controle de espera ou
entrada digital 8
10 GND - Terra
11 AD4 / DIO4 Bidirecional
Entrada analgica 4 ou
entrada/sada Digital 4
12 CTS / DIO7 Bidirecional
Controle de fluxo ou
entrada/sada digital 7
13 ON / SLEEP Sada Indicador de status do mdulo
14 VREF Entrada
Voltagem de referncia para
entradas digitais e analogicas
15 Associate / AD5 / DIO5 Bidirecional
Indicador, Entrada analgica 5 e
16 RTS / AD6 / DIO6 Bidirecional
Controle de Fluxo, entrada
analgica 6 ou entrada/sada
digital 6
20 AD0 /DIO0 Bidirecional
Tabela 2.1: Descrio dos 20 pinos presentes no ZigBee MaxStream.
O fluxo de funcionamento de uma transmisso serial do mdulo ZigBee
MaxStream ocorre atravs dos pinos de DI (entrada) e DO (sada). O DO pode
ser mapeado para qualquer pino de sada que aceite sada digital ou atravs de
modulao PWM em um pino de sada analgica. Quando os dados seriais
entram no mdulo RF atravs do pino DI (pino 3), os dados so armazenados
no buffer DI at que eles possam ser processados. Quando o DI buffer atinge
dezessete bytes aps ter enchido, por padro, o mdulo modifica o sinal do
CTS para nvel alto solicitando que o dispositivo pare de enviar dados. O CTS
reconfigurado para nvel baixo quando o DI Buffer possuir 34 bytes de memria
disponvel. Quando os dados do RF so recebidos, eles entram no DO buffer e
so enviados atravs da porta serial para o dispositivo receptor. Um esboo do
funcionamento pode ser visualizado na Figura 2.14.
23

Figura 2.14: Diagrama de fluxo do mdulo ZigBee
2.4 Protocolo ModBus
O padro MODBUS define um protocolo de mensagens na camada de
aplicao, posicionada no nvel sete do modelo de referncia OSI que prov
comunicao cliente/servidor entre dispositivos conectados em diferentes tipos
de barramentos ou topologias de redes. (MODBUS APLICATION PROTOCOL
SPECIFICATION, 2002)
Este padro iniciou a sua incorporao pelas indstrias em 1979 e ainda
continua sendo utilizado por milhes de dispositivos de automao para
comunicao. Hoje, o MODBUS pode ser utilizado desde uma simples
estrutura de dados seriais a formas mais complexas como suporte a utilizao
da internet atravs da porta 502 no TCP/IP.
Alguns principais tipos de implementao do protocolo MODBUS, mostrados
na Figura 2.15, so:
MODBUS Padro (mestre/escravo): usado para comunicao de CLPs
(Controladores Lgico Programveis) com os dispositivos de entrada e sada
de dados, instrumentos eletrnicos inteligentes (IEDs) como rels de proteo,
controladores de processo, atuadores de vlvulas, transdutores de energia e
etc. o meio fsico o RS-232 ou RS-485 em conjunto com o protocolo mestre-
escravo.
24

MODBUS plus: usado para comunicao de controladores lgicos
programveis entre si, mdulos de E/S, chaves de partida eletrnica de
motores, interfaces homem mquina etc. O meio fsico o RS-485 com taxas
de transmisso de 1 Mbps, controle de acesso ao meio por HDLC (High Level
Data Link Control).
MODBUS TCP/IP: usado para comunicao entre sistemas de superviso e
controladores lgicos programveis. O protocolo ModBus encapsulado no
protocolo TCP/IP e transmitido atravs de redes padro ethernet com controle
de acesso ao meio por CSMA/CD.

Figura 2.15: Camadas das formas de implementao do MODBUS
O protocolo ModBus define um simples protocolo de unidade de dados
(Protocol Data Unit - PDU) independente das camadas de aplicao. O
mapeamento do protocolo para barramentos e redes especficas pode
introduzir alguns campos adicionais na unidade de aplicao de dados
(Application Data Unit ADU) . (MODBUS PROTOCOL REFERENCE GUIDE,
1996)

Figura 2.16: Modelo de um pacote MODBUS
25

A troca de pacotes no protocolo iniciada pelo cliente que faz alguma
requisio a um servidor. O pacote enviado possui o cdigo da funo
requerida e os dados necessrios para realizar aquela funo. O servidor
recebe o pacote, executa a ao e inicia a resposta para o cliente. Em caso de
erro, o cdigo da funo substitudo por um cdigo que indica qual tipo de
erro ocorreu.
Alm das funes pr-especificadas no protocolo, existem campos
disponveis para implementao de novas funes. O protocolo MODBUS
bastante susceptvel a adicionar funcionalidade e talvez seja por isso sua larga
utilizao na indstria. Em contrapartida, diversos fabricantes desenvolvem o
seu prprio protocolo baseado no MODBUS e no disponibilizam alteraes ou
manuais, para garantir o segredo de funcionamento do produto.
2.5 Processador Nios II
O Nios II consiste em um processador RISC de 32-bits de propsito
geral, desenvolvido para atender uma grande escala de dispositivos
embarcados. As principais caractersticas do Nios II so: conjunto de
instrues, espao de endereamento e endereamento de dados de 32-bits;
32 registradores de propsitos geral; 32 fontes de interrupes externas;
instrues dedicadas ao clculo de multiplicaes com 64-bits e 128-bits;
acesso a uma variedade de perifricos on-chip, e interfaces para acesso a
memrias e perifricos off-chip; oferece cerca de 2 Giga Bytes de espao de
endereamento e customizao de at 256 instrues. (BUENO ET AL, 2007)
Nios II um processador soft-core, pois a plataforma flexivelmente
modificvel e apresentada como um ncleo soft, ou seja, no uma pastilha
de silcio pronta, apresentado atravs de um projeto codificado atravs de
uma linguagem de descrio de hardware, como VHDL ou Verilog e pode ser
implementado em qualquer FPGA da famlia Altera que o suporte. A Figura
2.17 mostra o modelo de um kit de desenvolvimento Altera com o Nios II.
(PERON, 2007)
26

O kit mostrado na Figura atende adequadamente todos os requisitos de
projetos para o guia de referncia do Nios II da Altera. Entretanto pode-se
utilizar essas funcionalidades e implement-las nas plataformas de hardware
que esto sendo desenvolvidas, ou, caso contrrio, pode-se personalizar o
processador Nios II para que ele atenda os requisitos de custo e desempenho
necessrios.

Figura 2.17: Kit de desenvolvimento Altera para o Nios II
Segundo Peron (2007), a configurabilidade que o processador Nios II
possibilita, no implica que os projetistas devam implementar uma nova
configurao para cada projeto. O fabricante Altera disponibiliza alguns
sistemas Nios II prontos para uso. Ento, se algum se adqua a aplicao em
desenvolvimento, pode ser simplesmente incorporada ao projeto, no havendo
necessidade de configurao do processador. Alm disso, atravs do
simulador de instrues, o Nios II permite aos projetistas escrever e depurar
aplicaes antes que a configurao final do hardware seja determinada.
Um sistema com processador Nios II equivalente a um
microcontrolador ou um SoC (system-on-chip) que inclui uma CPU e uma
combinao de perifricos e memria em um nico chip. O termo sistema do
processador Nios II se refere a um core do processador Nios II, um conjunto
de perifricos on-chip, memria interna e interfaces para memria externa, tudo
implementado em um nico chip da Altera. Do mesmo modo que uma famlia
de microcontroladores, todos os sistemas do processador Nios II usam um
Disponvel em
www.altera.com

27

conjunto de instrues e um modelo de programao consistentes. (PERON,
2007)
Seu conjunto flexvel de perifricos uma das diferenas mais
importantes entre o processador Nios II e os microcontroladores. Devido
natureza soft-core do processador Nios II, os projetistas podem desenvolver
sistemas sob demanda com o conjunto exato de perifricos necessrios para
as aplicaes desejadas. Outro ponto importante de uma arquitetura flexvel
ter um mapa de endereamento flexvel. Variveis de software podem ter
acesso genrico memria e aos perifricos, independente da localizao do
endereo segundo Altera (2007). Portanto, o conjunto flexvel de perifricos
produzidos de acordo com a necessidade do projetista e o mapa de
endereamento no afetam os desenvolvedores de aplicaes e facilitam a
integrao de desenvolvimento plataforma.
Os perifricos podem ser aqueles comumente encontrados em
microcontroladores, tais como timers, interfaces de comunicao serial, E/S de
propsito geral, controladores SDRAM e outras interfaces de memria. Alm
disto, os projetistas podem adicionar seus prprios perifricos personalizados e
integr-los ao processador Nios II.
Para sistemas onde o desempenho crtico, onde a CPU gasta a
maioria dos ciclos de clock executando uma parte especfica do cdigo, uma
tcnica comum criar um perifrico personalizado que implementa a mesma
funo em hardware. Esta abordagem oferece uma melhora dupla no
desempenho: a implementao em hardware mais rpida que a em software,
e o processador fica livre para executar outras funes em paralelo enquanto o
perifrico personalizado opera nos dados.
O processador Nios II se comunica com um barramento de interconexo
denominado Avalon. O Avalon um barramento especial que prioriza a
velocidade de transmisso de dados, permitindo conexes em paralelo. Este
barramento responsvel pela integrao do ncleo de processamento e os
demais dispositivos, como memria, temporizadores, perifricos de entrada e
sada, e outros.
28

O ambiente de desenvolvimento do Nios II baseado no compilador
GNU C/C++ e na IDE Eclipse, e prov um ambiente familiar e conceituado para
o desenvolvimento de software. Usando a IDE do Nios II, possvel projetar e
simular aplicaes para esse processador. Utilizando-se os projetos de
hardware de referencia, como mostrado na Figura 2.18, o projetista pode
prototipar sua aplicao executando-a em um kit de desenvolvimento, antes de
construir uma plataforma de hardware personalizado. O projetista pode
personalizar o sistema do processador Nios II at que ele atenda aos requisitos
de custo ou desempenho. (ALTERA, 2007)

Figura 2.18: Hardwares de referncia para prototipao do Nios II
2.6 Linguagens de programao
2.6.1 Linguagem C
A linguagem C foi criada por Dennis Ritchie, em 1972, no centro de
Pesquisas da Bell Laboratories. Sua primeira utilizao importante foi a
reescrita do Sistema Operacional UNIX, que at ento era escrito em
Assembly. Em meados de 1970 o UNIX saiu do laboratrio para ser liberado
para as universidades. Foi o suficiente para que o sucesso da linguagem
atingisse propores tais que, por volta de 1980, j existiam vrias verses de
compiladores C oferecidas por vrias empresas, no sendo mais restritas
29

apenas ao ambiente UNIX, porm compatveis com vrios outros sistemas
operacionais. (SCHILDT, 1996)
O C uma linguagem de propsito geral, sendo adequada
programao estruturada. No entanto mais utilizada escrever compiladores,
analisadores lxicos, bancos de dados, editores de texto, etc.. A linguagem C
pertence a uma famlia de linguagens cujas caractersticas so: portabilidade,
modularidade, compilao separada, recursos de baixo nvel, gerao de
cdigo eficiente, confiabilidade, regularidade, simplicidade e facilidade de uso.
A gerao do programa executvel a partir do programa fonte obedece a
uma seqncia de operaes antes de tornar-se um executvel. Depois de
escrever o cdigo fonte em um editor de textos, o programador aciona o
compilador que no UNIX chamado pelo comando cc. Essa ao desencadeia
uma seqncia de etapas, cada qual traduzindo a codificao do usurio para
uma forma de linguagem de nvel inferior, que termina com o executvel criado
pelo linker (lincador). A seguir os passos necessrios para compilao de um
cdigo em C.
1. Editor (mdulo fonte em C)
2. Pr-processador (novo fonte expandido)
3. Compilador (arquivo objeto)
4. Lincador (executvel)
Inicialmente, C era usada na programao de sistemas. Um programa
de sistema forma uma poro do sistema operacional do computador ou de
seus utilitrios de suporte. Por exemplo, os programas que seguem so
frequentemente chamados de programas de sistema: sistemas operacionais,
interpretadores, editores, programas de planilha eletrnica, compiladores,
gerenciadores de banco de dados.
Em virtude da sua portabilidade e eficincia, medida que C cresceu em
popularidade, muitos programadores comearam a us-la para programar
todas as tarefas. Por haver compiladores C para quase todos os
computadores, possvel tornar um cdigo escrito para uma mquina, compil-
30

lo e rod-lo em outra com nenhuma ou pouca modificao. Os compiladores C
tambm tendem a produzir um cdigo-objeto muito compacto e rpido (menor e
mais rpido que aquele da maioria dos compiladores BASIC, por exemplo).
(SCHILDT, 1996)
2.6.2 Linguagem Java
Java uma linguagem computacional completa, adequada para o
desenvolvimento de aplicaes baseadas na rede Internet, redes fechadas ou
ainda programas stand-alone [CAM96]. Foi desenvolvida na 1a metade da
dcada de 90 nos laboratrios da Sun Microsystems com o objetivo de ser
mais simples e eficiente do que seus predecessores. O alvo inicial era a
produo de software para produtos eletrnicos de consumo (fornos de
microondas, agendas eletrnicas, etc.). Um dos requisitos para esse tipo de
software ter cdigo compacto e de arquitetura neutra.
A linguagem obteve sucesso em cumprir os requisitos de sua
especificao, mas apesar de sua eficincia no conseguiu sucesso comercial.
Com a popularizao da rede Internet, os pesquisadores da Sun Microsystems
perceberam que aquele seria um nicho ideal para aplicar a recm criada
linguagem de programao. A partir disso, adaptaram o cdigo Java para que
pudesse ser utilizado em microcomputadores conectados a rede Internet, mais
especificamente no ambiente da World Wide Web. Java permitiu a criao de
programas batizados applets, que trafegam e trocam dados atravs da Internet
e se utilizam da interface grfica de um web browser. Implementaram tambm
o primeiro browser compatvel com a linguagem, o HotJava, que fazia a
interface entre as aplicaes Java e o sistema operacional dos computadores.
(DEITEL, 2005)
Java uma linguagem poderosa em ambientes distribudos complexos
como a rede Internet. Mas sua versatilidade permite ao programador ir alm,
oferecendo uma poderosa linguagem de programao de uso geral, com
recursos suficientes para a construo de uma variedade de aplicativos que
podem ou no depender do uso de recursos de conectividade segundo Wutka
31

(1997). As principais caractersticas da linguagem foram divulgadas pela
primeira vez em The Java Language: A White Paper. (GOSLING, 1996).
Alm disso, o Java possui mais algumas caractersticas interessantes a
se ressaltar, tais como: sintaxe similar a linguagem C/C++, facilidades de
Internacionalizao (suporta nativamente caracteres Unicode), distribuda
com um vasto conjunto de bibliotecas (ou APIs), possui facilidades para criao
de programas distribudos e multi-thread (mltiplas linhas de execuo num
mesmo programa), desalocao de memria automtica por processo de
coletor de lixo, carga dinmica de cdigo (programas em Java so formados
por uma coleo de classes armazenadas independentemente e que podem
ser carregadas no momento de utilizao).
Algumas necessidades bsicas para se programar em Java so a
utilizao de algumas ferramentas como: JDK (Java development Kit) (um
pacote com as principais classes do Java e um compilador) e uma IDE. A ttulo
de exemplo temos: NetBeans patrocinado pela SUN MicroSystems
(netbeans.org) e o Eclipse patrocinado pela IBM.
A linguagem Java tanto compilada como interpretada. Aps escrever
um programa em Java, utilizando um editor de textos qualquer, salva-se o
programa como cdigo fonte. A seguir, pode-se compilar esse cdigo fonte, a
fim de produzir um tipo de arquivo binrio chamado de arquivo de classe.
Esses arquivos no so executados diretamente pois eles no contm
instrues que so entendidas diretamente pelos processadores atualmente
disponveis no mercado. Os programas Java so compilados em um formato
intermedirio chamado bytecodes. Assim, esses programas podem ser
executados em qualquer sistema atravs de um interpretador Java (runtime
environment). Com isso, o cdigo precisa ser escrito e compilado apenas uma
vez, pois os bytecodes gerados sero executados da mesma forma em
qualquer plataforma de hardware e software.
O Java a nica linguagem de programao realmente multi-plataforma
graas a JVM (Java Virtual Machine) , que a responsvel pela execuo de
um programa escrito em Java. Um cdigo fonte escrito em Java traduzido
32

para bytecode, que lido e executado pela Java Virtual Machine (que
obrigatoriamente tem que estar instalada na mquina). Esse processo de
compilao e execuo chega a ser at 20 vezes mais lento que a linguagem
C, mas isso no impede que o Java seja implantado com qualquer tipo de
software. A JVM cria um ambiente virtual para o Java independente da
mquina que estivermos trabalhando, isso deu ao Java o grande impulso para
sua disseminao ser to elevada quando comparada as outras linguagens.
(DEITEL, 2005)
O javac um compilador de cdigos Java com uma sada em bytecodes.
A execuo de programas Java, feita atravs do interpretador Java, que um
programa encontrado na pasta bin da instalao do JDK e executa aplicaes
Java compiladas (bytecodes extenso .class). Todo cdigo escrito em Java
deve ser salvo com a extenso .java. Quando compilado ser gerado no
mnimo um .class para cada .java existente. Como o Java case sensitive,
todo e qualquer comando, varivel, nome de classes e objetos escritos em
Java ser diferenciado entre maisculas e minsculas.
2.6.3 Linguagem LabView
LabVIEW (Laboratory Virtual Instruments Engineering Workbench)
uma linguagem de programao desenvolvida pela National Instruments. O
LabVIEW diferente das usuais linguagens de programao em um aspecto
importante. Ao invs de utilizar linhas de cdigo, ele utiliza uma linguagem
grfica conhecida como linguagem G que composta de muitos fios virtuais
conectados.
O LabVIEW tem um compilador grfico aperfeioado para maximizar o
desempenho do sistema. Este ambiente simplifica o desenvolvimento do
programa, e tambm diz imediatamente ao usurio quando um erro foi
cometido. Como tambm produz um cdigo que pode ser reutilizvel. LabVIEW
usado como um substituto para as linguagens baseadas em linhas de cdigo,
permitindo ao usurio observar o que o programa est fazendo literalmente,
deste modo, voc pode inserir um pedao de cdigo esquecido, e pode estudar
como o dados esto sendo executados e transferidos durante o programa. Ele
33

tem extensivas bibliotecas de funes para qualquer programa. Os programas
no LabVIEW so chamados de Virtual Instruments (VIs) porque a aparncia e
as operaes simulam instrumentos reais.
Sob este ponto de vista, podemos resumidamente citar as
caractersticas do LabVIEW: (BURNETT, ET. AL, 1995)
uma linguagem de programao visual - isto , suas instrues de
programao so representadas por cones que podem ser conectados de
modo a compor o programa
Suporta programao por texto - o LabVIEW possui blocos que
permitem que se digite o texto de um programa, com duas possveis
linguagens: (a) uma linguagem com sintaxe tipo C e (b) uma linguagem
com sintaxe tipo Matlab. Esses blocos podem ser interligados aos
cones da programao visual, permitindo que se trabalhe com os dois
modos de programar simultaneamente
uma linguagem modularizada - isto , permite que se crie sub-
programas, que correspondem a trechos do programa principal, que
podem ser encapsulados em cones criados pelo programador (sub-
programas ou sub-rotinas).
Suporta recursos de multiprocessamento e multiprogramao - ou seja,
explora os recursos de multi-tarefas (multitasking) e multi-
(multithreading), bem como a distribuio dos mesmos
automaticamente (ou manualmente, de forma explcita, se for
desejado) entre diferentes processadores ou ncleos de processadores
(multicore execution).
uma linguagem orientada pelo fluxo de dados (dataflow) - a sequncia
de execuo e interdependncia entre as instrues, procedimentos e
mdulos estabelecida por um grafo direcional (directed graph).
Suporta orientao a objetos - o LabVIEW nativamente uma linguagem
orientada a objetos, em sua implementao. Todavia, apresenta-se ao
programador principalmente como orientado ao fluxo de dados. Desde
34

a verso 8.2, o LabVIEW oferece construtores para a criao de
objetos, no sentido de programao orientada a objetos.
No suporta explicitamente programao recursiva - embora haja
meno de ser possvel conseguir-se isso com algum esforo.
Sob este ponto de vista, muito resumidamente, suas caractersticas so:
Prov a separao real entre a interface de usurio e o cdigo do
programa. Ao abrir, o LabVIEW oferece duas janelas distintas: painel
frontal - para desenvolvimento da interface grfica de operao do
programa (pelo usurio) e o diagrama de blocos - onde feito o
desenvolvimento do algoritmo, programado em linguagem visual.
Ambiente compilado - os blocos do LabVIEW so peas pr-compiladas,
que so ligadas ao corpo do programa medida que se vai editando.
No uma linguagem interpretada.
Permite produzir programas que funcionam fora do ambiente LabVIEW,
sozinhos, instalveis separadamente. O programa desse tipo (stand-
alone) produzido (built) com opes de ligao esttica ou dinmica
das bibliotecas (DLLs). Esse processo permite criar tambm o
instalador.
O cdigo desenvolvido na linguagem visual compilado diretamente
para linguagem de mquina, no traduzido para nenhuma outra
representao intermediria.
Aceita a ligao de DLLs ao cdigo, oferecendo um bloco de
prototipao da interface com o procedimento pr-compilado, que
permite ligar cada varivel do mesmo ao diagrama de blocos.
Oferece ferramentas de depurao (debug) avanadas, permitindo
acompanhar execuo passo a passo, monitorar visualmente as
variveis, produzir visualizaes de valores instantneos em qualquer
ponto do programa, no formato especfico de cada varivel (ex:
imagens so mostradas como imagens, tipos mistos de dados
aparecem conforme construdos, etc.).
35

Suporta diversos nveis de abstrao de comunicao entre mdulos,
objetos, partes de cdigo e o hardware. Aceita protocolos desde
Seriais, Paralelos, TCP-IP, UDP, at ActiveX, etc.
Suporta protocolos e representaes compatveis com sistemas
distribudos, dotados de mobilidade, persistncia, etc. Oferece
mecanismos para desenvolvimento de arquiteturas com .NET e outros.
J portado para diversas plataformas - Linux, Windows, MacOS.
Tambm disponvel em verses para sistemas operacionais de
tempo real.
Trata os componentes de hardware como se fossem objetos
programveis dentro do ambiente LabVIEW, expondo os parmetros e
variveis fsicos como tipos abstratos de dados no programa e as
operaes e mecanismos do hardware como chamadas de processos
de software.
Permite tratar tanto hardware local quanto remoto da mesma forma,
oferecendo ferramentas para desenvolvimento e monitorao de
processos distribudos.
Produz cdigo para ser utilizado diretamente em sistemas embarcados
que so especificados durante o desenvolvimento. Diversos fabricantes
de chips para sistemas embarcados esto disponveis.
Suporta o acesso de baixo nvel a componentes do hardware que o
permitam faz-lo.
2.6.4. Language VHDL (VHSIC Hardware Description Language)
VHDL uma linguagem para descrio de circuitos eletrnicos digitais.
Ela foi um resultado de um programa de desenvolvimento de circuitos
integrados de altssima velocidade (VHSIC) iniciado em 1980 pelo governo dos
Estados Unidos. Neste programa, tornou-se claro a necessidade de criao de
uma linguagem padro para descrio de estruturas a funcionamento de
circuitos integrados (CIs). Ento a VHSIC Hardware Description Language
(VHDL) foi desenvolvida, e em seguida adotada como um padro pelo Institute
36

of Electrical and Electronics Engineers (IEEE) nos Estados Unidos.
(ASHENDEN,1990)
Uma vez que o projeto VHSIC era de alta prioridade militar e havia
dezenas de fornecedores envolvidos, o DoD estava preocupado principalmente
com as questes de portabilidade, documentao e compreensibilidade dos
projetos. Cada um destes fornecedores atuava desenvolvendo partes dos
projetos ou mesmo fornecendo componentes que viriam a se encaixar em
outros sistemas maiores. Desta forma o DoD optou por buscar desenvolver
uma linguagem que servisse como base para troca de informaes sobre estes
componentes e projetos. Uma linguagem que, independente do formato original
do circuito, pudesse servir como uma descrio e documentao eficientes do
circuito, possibilitando os mais diferentes fornecedores e participantes a
entender o funcionamento das outras partes, padronizando a comunicao.
(DAMORE, 2005)
Aps o sucesso inicial do uso da VHDL, a sua definio foi posta em
domnio pblico, o que levou a ser padronizada pelo IEEE em 1987. O fato de
ser padronizada e de domnio pblico ampliou ainda mais a sua utilizao,
novas alteraes foram propostas, como natural num processo de
aprimoramento e a linguagem sofreu uma reviso e um novo padro mais
atualizado foi lanado em 1993. Atualmente ela continua a ser revisada e
dever ser lanado um novo padro. (DAMORE, 2005)
VHDL uma linguagem estruturada que oferece a possibilidade de
descrever e simular o hardware antes de sua sntese, facilitando a validao ou
verificao, tanto em termos de funcionamento quanto em termos de tempos
de atraso dos componentes e desempenho, sem a necessidade da
prototipao do sistema.
Um programa em VHDL pode ser dividido e implementado em parte
como software (hardware programvel) e outra, em hardware reconfigurvel.
Pode ser escrito basicamente usando dois tipos (modelos) de descrio:
estrutural e comportamental. Na descrio estrutural, a organizao fsica e
37

topolgica do sistema descrita, ou seja, so especificadas as entradas e/ou
sadas, os componentes lgicos, a interligao deles e os sinais que compem
o sistema.
Na descrio comportamental, no preciso descrever a organizao
fsica e topolgica do sistema, somente o comportamento. So descritas as
funes (comportamento) do sistema. Um programa que utiliza esse tipo de
descrio possui o mesmo formato de um programa fonte escrito em uma
linguagem de programao de alto nvel, como C++. Essa abordagem diminui a
necessidade de conhecimento em projeto de hardware, aumentando a
facilidade de desenvolvimento do sistema. Algumas vantagens no uso de
VHDL so: projetos independentes da tecnologia; maior facilidade de
atualizao dos projetos; explorao de alternativas arquiteturais em um nvel
mais alto de abstrao; reduo do tempo de projeto e custos; e simplificao
da documentao. Como desvantagem o hardware gerado menos otimizado,
simulaes mais lentas e falta de pessoal treinado para lidar com a tecnologia.
(DAMORE, 2005)
2.7 Barramento USB
USB a sigla de Universal Serial Bus. Trata-se de uma tecnologia que
tornou mais simples e fcil a conexo de diversos tipos de aparelhos (cmeras
digitais, drives externos, modems, mouse, teclado, etc) ao computador,
evitando o uso de um tipo especfico de conector para cada dispositivo. O
padro USB foi desenvolvido em meados da dcada de 1990 por um consrcio
de empresas, entre as quais se destacam: Microsoft, Apple, Hewlett-Packard,
NEC, Intel e Agere.
Uma caracterstica importante e interessante do USB, que sua
interface permite que o dispositivo conectado seja alimentado pelo cabo de
dados, ou seja, no necessrio ter outro cabo para ligar o aparelho tomada.
Mas, isso s possvel com equipamentos que consomem pouca energia.
O USB possui um conector universal que permite ao usurio adicionar
perifricos, apenas conectando-os ao computador atravs de um cabo,
38

permitindo transferncias a 1,5 ou 12 Mbits/s para a verso 1.0/1.1 e at 480
Mbits/s para a verso 2.0.
Dois identificadores so usados para marcar um dispositivo: o ID de
vendedor e o ID de produto. Ambos IDs so registrados no descritor do
dispositivo USB. O ID de vendedor (VID) marca o fabricante e normalmente
designado pelo USBIF (Universal Serial Bus Implementers Forum). O ID de
produto (PID) (como o VID) um nmero de 16 bits e marca o produto. A
atribuio feita pelo fabricante do dispositivo. Para o PID no h nenhuma
restrio administrativa do USBIF como no VID.
Com todas as vantagens, o barramento USB tornou-se o meio mais fcil
de conectar perifricos ao computador. Qualquer usurio pode instalar
dispositivos USB na mquina, pois, utilizando o padro PnP (Plug and Play), o
sistema operacional reconhece e disponibiliza imediatamente o dispositivo a
ser instalado. Para isso necessrio que a placa me da mquina e o sistema
operacional sejam compatveis com o barramento.
Outra facilidade a de se conectar e desconectar qualquer dispositivo
com o computador ligado (Hot Putting) sem que ele sofra danos, no sendo
necessrio reiniciar o computador para que o aparelho instalado possa ser
usado.
Um fato interessante a possibilidade de conectar alguns perifricos a
outros (por exemplo, uma impressora a um scanner), mas isso s possvel se
tais equipamentos vierem com conectores USB integrados. Utilizando-se de
hubs USB, teoricamente podemos conectar at 127 dispositivos USB em uma
nica porta, mas isso no vivel, uma vez que a velocidade de transmisso
de dados de todos os equipamentos envolvidos seria comprometida.
2.8 Bases de dados
O primeiro Sistema Gerenciador de Banco de Dados (SGBD) comercial
surgiu no final de 1960 com base nos primitivos sistemas de arquivos
disponveis na poca, os quais no controlavam o acesso concorrente por
vrios usurios ou processos. Os SGBDs evoluram desses sistemas de
39

arquivos de armazenamento em disco, criando novas estruturas de dados com
o objetivo de armazenar informaes. Com o tempo, os SGBDs passaram a
utilizar diferentes formas de representao, ou modelos de dados, para
descrever a estrutura das informaes contidas em seus bancos de dados.
Atualmente, os seguintes modelos de dados so normalmente utilizados pelos
SGBDs: modelo hierrquico, modelo em redes, modelo relacional (amplamente
usado) e o modelo orientado a objetos. (TAKAI, 2007)
Os bancos de dados so utilizados em muitas aplicaes, abrangendo
praticamente todo o campo dos programas de computador. Os bancos de
dados so o mtodo de armazenamento preferencial para aplicaes
multiusurio, nas quais necessrio haver coordenao entre vrios usurios.
Entretanto, so convenientes tambm para indivduos, e muitos programas de
correio eletrnico e organizadores pessoais baseiam-se em tecnologias
padronizadas de bancos de dados.
Um banco de dados um conjunto de informaes com uma estrutura
regular. Um banco de dados normalmente, mas no necessariamente,
armazenado em algum formato de mquina legvel para um computador. H
uma grande variedade de bancos de dados, desde simples tabelas
armazenadas em um nico arquivo at gigantescos bancos de dados com
muitos milhes de registros, armazenados em salas cheias de discos rgidos.
O PostgreSQL (conhecido anteriormente como Postgres95) derivou do
projeto Postgres da universidade de Berkley, cuja ltima verso foi a 4.2. O
Postgres foi originalmente patrocinado pelo DARPA (Agncia de Projetos de
Pesquisa Avanada para Defesa), ARO (Departamento de Pesquisa Militar),
NSF (Fundao Cientfica Nacional) e ESL Inc. A implementao do projeto
POSTGRES iniciou em 1986, j em 87 tornou-se operacional. A primeira
verso lanada para o pblico externo foi em 1989. Devido a uma crtica feita
ao seu sistema de regras, o Postgres teve essa parte re-implementada e
lanada em uma segunda verso em 1990. Em 1991 foi lanada a verso 3,
com melhorias no executor de consultas e algumas partes do cdigo foram re-
escritas. As verses subsequentes, at o Postgres95, foram focadas em
confiabilidade e portabilidade. O Postgres foi utilizado para diversos sistemas
40

de pesquisa e de produo, uma aplicao de anlise financeira, um banco
com rotas de asterides, e diversos sistemas de informaes geogrficas. O
cdigo do Postgres foi aproveitado em um produto comercializado pela Illustra
Information Technologies (posteriormente incorporada Informix, que agora
pertence IBM). (MANUAL POSTRGEE, 2001)
Pela riqueza de recursos e conformidade com os padres, ele um
SGBD muito adequado para o estudo universitrio do modelo relacional, alm
de ser uma tima opo para empresas implementarem solues de alta
confiabilidade sem altos custos de licenciamento. um programa distribudo
sob a licena BSD, o que torna o seu cdigo fonte disponvel e o seu uso livre
para aplicaes comerciais ou no. O PostgreSQL foi implementado em
diversos ambientes de produo no mundo, entre eles, um bom exemplo do
seu potencial o banco de dados que armazena os registros de domnio .org,
mantido pela empresa Afilias.
Alguns recursos presentes na verso mais recente.
Sub-consultas;
Controle de concorrncia multi-verso (MVCC);
Integridade Referencial;
Funes armazenadas (Stored Procedures), que podem ser escritas em
vrias linguagens de programao (PL/PgSQL, Perl, Python, Ruby, e
outras);
Gatilhos (Triggers);
Tipos definidos pelo usurio;
Esquemas (Schemas);
Conexes SSL.
reas de armazenamento (Tablespaces)
Pontos de salvamento (Savepoints)
Commit em duas fases
41

Arquivamento e restaurao do banco a partir de logs de transao
Diversas ferramentas de replicao
Extenses para dados geoespaciais, indexao de textos, xml e vrias
outras.
No jargo de banco de dados, o PostgreSQL utiliza o modelo cliente-
servidor. Uma sesso do PostgreSQL consiste nos seguintes processos
(programas) cooperando entre si. Um processo servidor, que gerencia os
arquivos de banco de dados, recebe conexes dos aplicativos cliente com o
banco de dados, e executa aes no banco de dados em nome dos clientes. O
programa servidor de banco de dados se chama postmaster.
O aplicativo cliente do usurio (frontend) que deseja executar operaes
de banco de dados. Os aplicativos cliente podem ter naturezas muito diversas:
o cliente pode ser uma ferramenta no modo caractere, um aplicativo grfico,
um servidor Web que acessa o banco de dados para mostrar pginas Web, ou
uma ferramenta especializada para manuteno do banco de dados. Alguns
aplicativos cliente so fornecidos na distribuio do PostgreSQL, sendo a
maioria desenvolvido pelos usurios.
Como tpico em aplicaes cliente-servidor, o cliente e o servidor
podem estar em hospedeiros diferentes. Neste caso se comunicam atravs de
uma conexo de rede TCP/IP. Deve-se ter isto em mente, porque arquivos que
podem ser acessados na mquina cliente podem no ser acessveis pela
mquina servidora (ou somente podem ser acessados usando um nome de
arquivo diferente).
O servidor PostgreSQL pode tratar vrias conexes simultneas de
clientes. Para esta finalidade iniciado um novo processo para cada conexo.
Deste ponto em diante, o cliente e o novo processo servidor se comunicam
sem interveno do processo postmaster original. Portanto, o postmaster est
sempre executando aguardando por novas conexes dos clientes, enquanto os
clientes e seus processos servidor associados surgem e desaparecem
(obviamente tudo isso invisvel para o usurio, sendo mencionado somente
para ficar completo). (MANUAL POSTRGEE, 2001)
42

Captulo 3

Medio de Torque

A eficincia de um processo industrial, assim como a qualidade do
produto gerado, est intrinsecamente ligada ao monitoramento adequado do
mesmo e uma medida acurada das grandezas relacionadas. necessrio que
exista um mecanismo de instrumentao que garanta eficincia e qualidade e
que propicie, na maioria das vezes, a segurana de todo equipamento e do
pessoal envolvido no processo (PREOBRAZHENSKY, 1980).
Torque ou momento de uma fora uma grandeza fsica associada a
o movimento de rotao de um corpo, em torno de um eixo, que resulta da
aplicao de uma fora a esse corpo. O torque definido a partir da
componente perpendicular ao eixo de rotao da fora aplicada sobre um
objeto (corpo) que efetivamente utilizada para faz-lo girar em torno de um
eixo ou ponto central, conhecido como ponto piv ou ponto de rotao.
O torque se configura como uma das mais importantes caractersticas
dos parmetros de mquinas de produo. Tendo em vista que os torqumetros
atuais no atendem a demanda social, existe uma necessidade de uma
soluo em curto prazo no desenvolvimento de sensores de torque que tenham
uma larga faixa de atuao, alta definio, baixa depreciao com o tempo e
fcil instalao (MENG AND LIU, 2006).
Atualmente existem vrios estudos relacionados medio do torque
na indstria, envolvendo processos de desenvolvimento de peas, motores,
engrenagens e eixos, ligados a diferentes fins de produo, que envolvem
desde a rea automobilstica aeroespacial.
43

Quanto medio do torque especificamente de peas de seo
transversal circular, esta pode estar relacionada ou no ao movimento do corpo
em questo. Chama-se de torque esttico, ou momento torcional esttico
conjugado que tende a torcer peas que no se encontre em movimento de
rotao e, de modo anlogo, o torque rotacional est ligado ao movimento de
rotao do eixo em questo. O torque rotacional na presena de acelerao
angular chamado de torque dinmico.
O torque exercido por uma mola, por exemplo, seria considerado um
torque esttico. Enquanto que o torque transmitido atravs de um eixo na roda
de um carro que se movimenta a uma velocidade constante, seria um exemplo
de um torque esttico, porque mesmo existindo um movimento rotacional do
eixo o mesmo no apresenta acelerao angular. O torque no eixo do redutor
de uma unidade de bombeio um exemplo de torque dinmico, j que a
velocidade de rotao do eixo varia de acordo com a carga nas hastes e ao
movimento dos contrapesos.
Atualmente existem instrumentos (torqumetros) bastante precisos,
dependendo da aplicao, para obteno do torque esttico, mas ainda
existem srios desafios quando se deseja medir o torque dinmico, uma vez
que o local de medio encontra-se em rotao, dificultando o acesso. Tendo
em vista que a maioria dos processos de converso ou transferncia de
energia utiliza dispositivos mecnicos rotativos, existe um grande interesse em
se obter um sistema de medio adequado, o que tem impulsionado vrios
estudos. Porm, devido ao interesse financeiro nesta rea por empresas do
ramo, a abordagem final do instrumento lacrada para se impedir uma anlise
tcnica dos seus elementos constituintes, preservando o segredo industrial do
produto. O que reflete na ausncia de publicaes tcnicas no que diz respeito
arquitetura destes dispositivos (BRITO, 1994).
Os mtodos utilizados para se realizar a medida do torque, aplicados
nos torqumetros existentes, so principalmente divididos em trs categorias:
por absoro (HOLMAN, 1984), por extensmetros de resistncia eltrica
(ERE) (CHEONG ET AL., 1999) e pelo ngulo de toro (NORTON, 1969).
44

Compreender o tipo de torque a ser medido, assim como os tipos diferentes de
sensores do torque que esto disponveis, de fundamental importncia para
se obter uma boa exatido e na escolha do mtodo que atenda as
necessidades do projeto com menor custo. Alm disso, no critrio de seleo
do torqumetro dinmico adequado, deve-se observar a faixa de atuao,
exatido, frequncia mxima de rotao, resistncia s condies do ambiente,
capacidade de sobrecarga e circuito de transduo capaz de minimizar o rudo
na transmisso e saturao do sinal.
3.2 Sistemas de Automao de Unidades de Bombeio de Petrleo
A automao consiste em desenvolver sistemas automticos pelos quais
algum mecanismo controle seu prprio funcionamento quase sem a
interferncia do homem. (DICIONRIO AURLIO, 2000)
O bombeio mecnico um mtodo de elevao artificial em que uma
unidade de bombeamento instalada na superfcie, prximo cabea do poo,
para transformar movimento rotativo de um motor em movimento alternativo.
Este movimento alternativo transmitido por meio de uma coluna de hastes de
ao, colocada dentro da coluna de produo, para uma bomba que est
localizada no fundo do poo. A bomba alternativa, localizada prximo ao fundo
da jazida, fornece energia ao petrleo para elev-lo at a superfcie.
O mtodo de bombeamento mecnico mais utilizado no mundo para
extrao de petrleo (80 % dos poos mundiais) apresenta um srio desafio no
que diz respeito ao torque excedido no eixo de sada do redutor. No so raros
os casos em que o redutor danificado, devido falta de um monitoramento
adequado do torque. Na maioria das vezes que o redutor se danifica ele se
torna inutilizvel, tendo em vista que o mesmo representa aproximadamente
50% do custo total de uma Unidade de Bombeamento Mecnico (UBM) de
fundamental importncia que se monitore o torque no seu eixo de sada
evitando a quebra do equipamento (THOMAS, 2004). Alm do seu alto custo,
deve-se atentar que o tempo entre a quebra e a sua substituio pode
45

ocasionar em vrios dias sem produo, o que deve ser evitado,
principalmente, em um mercado competitivo como o petrolfero.
O atual acompanhamento do torque na sada do redutor da unidade de
bombeio feito atravs da API Specification 11E de 1994. De acordo com a
mesma, bastante difcil identificar e oferecer solues para todas as
influncias que afetam a engrenagem redutora.
A anlise experimental do torque no redutor baseada na medida da
carga no cabresto que sai da cabea da massa polida e do ngulo da manivela.
Para proteo da Unidade de Bombeio, a avaliao do torque de pico no
redutor deve ser relacionada com o torque de escavao (pitting), com a
avaliao do momento fletor e a medida do torque esttico, conforme
determinadas frmulas que se encontra na API Specification 11E. Esta
especificao define apenas a forma de clculo atravs de parmetros, no
trabalha com medies dos valores reais. (AMERICAN PETROLEUM
INSTITUTE, 1994)
Na equao de determinao do torque no eixo utilizada pela norma,
no se toma em considerao o desbalano estrutural com a mudana do
ngulo, os efeitos inerciais da viga, peso da viga, equalizador, virabrequim,
manivela, contrapeso da manivela e os atritos dos mancais. Devido a essa e
outras circunstncias, os clculos possuem uma margem de erro da ordem de
at 20%, criando, em alguns casos, uma grande distoro dos valores reais.
dos valores de torque e ngulo obtidos, possvel gerar uma carta
dinamomtrica utilizando uma interpolao de valores. Essa carta determina os
picos de torque na subida e na descida da cabea do cavalo, indicando os
possveis pontos crticos para quebra da unidade.
3.2.1 Atual Modelo de Automao
Atualmente a automao das unidades de bombeio terrestre na maior
parte do mundo realizada atravs de CLPs localizadas prximo s bombas
de extrao. Essa automao consiste em um sistema onde alguns dispositivos
46

capturam dados referentes a algumas medidas da unidade e os processa,
gerando valores do torque exercido na sada do eixo do redutor.
Para aquisio desses dados e controle da unidade, um sistema
colocado prximo a bomba de extrao. Esse sistema recebe dados analgicos
da clula de carga e do read switch localizados na bomba de petrleo. Um
esboo pode ser visualizado na figura 3.1.

Figura 3.1: Atual modelo de automao de bombas de petrleo
Os valores so recebidos pelo CLP atravs de fios e empacotados no
padro ModBus, em seguida so disponibilizados em uma rede sem fios
localizada nos campos de extrao de petrleo que possui uma antena ligada
ao controlador lgico. Essa rede ModBus responsvel por enviar os dados
referentes a todas as unidades de bombeamento terrestre para uma torre
receptora que disponibiliza os mesmos para uma Central Integrada de Controle
(CIC). Na CIC os dados sero analisados e monitorados por profissionais
capacitados.
Alm do empacotamento, o atual sistema pode receber um comando
tambm pelo protocolo ModBus para desativao da unidade por um
47

determinado momento. Isso se faz necessrio para que a quebra da unidade,
devido a um torque muito elevado, seja evitada.
Um dos principais problemas encontrados com o atual mtodo de
determinao de torque o erro gerado a partir clculo do valor de toque
obtido atravs da API 11E. Como atravs desse mtodo o torque calculado
atravs de alguns parmetros e interpolao de dos valores, o resultado obtido
possui uma margem de erro de at 20%. Devido ao erro existente no
possvel determinar com preciso os valores de pico e da quebra do eixo do
redutor da unidade. J em um torque medido diretamente no eixo possvel
obter um valor mais exato reduzindo a margem de erros para at 5%, como no
caso do torqumetro dinmico telemtrico.
3.3 Torqumetro Dinmico Telemtrico
Um torqumetro dinmico telemtrico proposto por Lima Filho (2007),
Anjos et. al (2008) elimina os erros encontrados nas tcnicas utilizadas e
desenvolvidas anteriormente com preciso e baixo custo. Este dispositivo j foi
testado em unidades de bombeamento terrestre de petrleo que se encontram
em funcionamento na PETROBRAS S.A.. Atualmente encontram-se em fase
de elaborao de um produto final para que seja adquirido pela empresa e
incorporado s unidades.
O torqumetro idealizado possui diversos tipos de aplicao, entretanto,
os torqumetros dinmicos existentes no mercado no podem ser aplicados nas
medies do eixo de sada do redutor das Unidades de Bombeio. Isto se deve
principalmente a problemas encontrados na utilizao de fios, de anis
deslizantes e devido induo eletromagntica. Ento este torqumetro foi
desenvolvido para suprir essa deficincia.
O sistema funciona como no esquema mostrado na Figura 3.2. O sinal,
proveniente da deformao no eixo, captado pelo extensmetro processado e
amplificado atravs do circuito de transduo eletrnica e enviado ao Mdulo
Remoto Transceptor (MRT) localizado internamente ao mdulo RF. No MRT o
sinal analgico convertido em digital por um microcontrolador e transmitido a
48

um chip transceptor que modula o sinal e excita a antena full duplex, irradiando
o sinal em freqncia de rdio. No Mdulo Base Transceptor (MBT), j no RF
base, o sinal RF captado pela antena , atravs do chip transceptor e do
microcontrolador, filtrado (passa-faixa de banda estreita), demodulado,
amplificado e disponibilizado em modulao por largura de pulso PWM (Pulse-
Width Modulation).
O sinal passa por um circuito integrador que disponibilizar a tenso
eltrica equivalente e em seguida um Loop de corrente AD 694 4-20 mA
fornece o sinal praticamente imune rudo a uma caixa de controle de uma
UBM (Unidade de Bombeio Mecnico de Petrleo). Alm disso o mdulo base
tambm disponibiliza os dados de forma digital para leitura atravs de qualquer
dispositivo. A leitura do torque pode ser feita no prprio local de operao da
UBM ou transmitido para uma central de monitoramento.

Figura 3.2: Esboo do sistema de instrumentao por rdio freqncia
49

3.4 Torque Atravs dos Parmetros Eltricos do Motor e Perda da Correia
O redutor da unidade de bombeio atua reduzindo a velocidade do motor
e aumenta o torque na sada do redutor propiciando movimento alternativo para
extrao do petrleo. Desta forma, medindo-se a potncia entregue e a
freqncia de rotao na sada do redutor pode-se calcular o torque no eixo. A
medida da potncia fornecida ao redutor pode ser conhecida a partir da
equao fundamental de potncia mdia do motor.
Para se determinar a potncia eltrica foram utilizados transformadores
de potncia (TPs) e de corrente (TCs). A Figura 3.3 ilustra a disposio destes
elementos no circuito do estator do motor da unidade de bombeio estudada.

Figura 3.3: Leitura de tenso e corrente no primrio do motor
Os transformadores de potncia foram interligados paralelamente s
bobinas de entrada do motor que se encontram na configurao estrela,
enquanto que os transformadores de corrente por efeito Hall foram
posicionados circundando os cabos de alimentao do primrio do motor.
Para se determinar a velocidade angular do redutor foram utilizados
sensores de efeito Hall e ims, que foram posicionados no eixo do redutor,
conforme pode ser visto na Figura 3.4 No mesmo eixo a posio da manivela
detectada por ms de referncia e pelo sensor de efeito Hall.
50

Figura 3.4: Medio da velocidade do redutor.
Alm do sensor do eixo de sada do redutor foram utilizados mais dois
sensores de feito Hall: um no motor e outro na entrada do redutor. Foram
colados ims na polia do motor e na polia da entrada do redutor e fixados os
sensores rente aos ms, conforme a Figura 3.5.

Figura 3.5: Medio da velocidade do motor.
O elemento de efeito Hall fornece um aumento de tenso em seus
terminais quando submetido a campos magnticos, ento cada vez que um
m se aproxima de um sensor sua tenso se eleva formando um pico. A
distncia entre os ims constante e conhecida, portanto atravs do tempo
entre dois picos consecutivos se determina a velocidade angular.
Atravs da diferena entre a velocidade da polia do motor e a da
entrada do redutor tm-se como determinar as perdas na polia. Esta perda na
transferncia de potncia para o redutor indicar o rendimento das polias.
Para calibrao do torque por este mtodo necessrio que se saiba o
valor do torque da mquina operando sem carga. Ento, o torque do eixo do
51

redutor ser obtido atravs do valor do torque real do motor, menos o seu
torque operando em vazio.
O torque obtido ento relacionado com a posio da manivela
fornecida pelo sensor de efeito Hall.
Devido condio de baixa velocidade no eixo de sada do redutor,
uma condio quase-esttica, a potncia mecnica desenvolvida no eixo do
motor eltrico mais a perda na correia ser aproximadamente igual a potencia
mecnica no eixo do redutor. Baseado nestas suposies, o torque no eixo da
engrenagem redutora poder ser determinado em funo da potncia
mecnica do eixo do motor e da perda da correia.
Quando existe um meio calibrador pode-se utilizar o mtodo de
regresso linear para obteno do torque baseado nos parmetros eltricos.
Para a potncia e conseqentemente o torque na sada do redutor,
dever ser includo a velocidade de entrada do redutor (V
R
) e a velocidade do
motor (V
M
). Este parmetro tambm levado em conta no clculo da perda da
correia. Desta maneira, atravs de uma regresso linear mltipla, faz-se a
calibrao do torque. A frmula abaixo determinaria o torque no redutor:
T
REDUTOR
= REG (v, i, V
R
, V
M
, T)
Onde: v

e i so os valores de tenso instantnea e corrente eltrica e T o
torque de referncia.
3.5 Teste e Validao
A necessidade de validao do projeto e verificao de sua viabilidade
de implantao levou a elaborao de inmeros testes. Os testes realizados
iniciaram utilizando prottipos desenvolvidos em laboratrio, at chegar a
testes em campo utilizando verdadeiras UBMs. (ANJOS ET. AL, 2008)
3.5.1 Prottipos para obteno de torque
Para que os testes com o Torqumetro Dinmico Telemtrico fosse
possvel, diversas bancadas foram projetadas e desenvolvidas nas
52

dependncias do Laboratrio de Energia Solar da UFPB. As bancadas
serviram inicialmente para testes de obteno do torque esttico e em seguida
o torque dinmico que o foco do novo torqumetro desenvolvido. Para simular
o torque exercido, processos de frenagem foram acoplados aos prottipos. As
Figuras a seguir mostram a evoluo das bancadas de testes.

Figura 3.6: Bancada de testes para torque esttico

Figura 3.7: Bancada de torque dinmico com eixo para frenagem

Figura 3.8: Prottipo com manivela e contrapeso
53

O ltimo prottipo desenvolvido se assemelha a uma mini unidade de
bombeio e possui um redutor semelhante em menores propores. Esta
caracterstica foi de extrema importncia para uma maior aproximao da
realidade. Observe na Figura 3.9 a manivela e a cabea do cavalo.
Por fim, testes em uma verdadeira UBM foram realizados. As avaliaes
foram feitas no campo de extrao de petrleo da PETROBRAS na cidade de
Carmpolis em Sergipe. Neste campo centenas de unidades terrestres extraem
petrleo o tempo todo e a parada em uma unidade deve ser extremamente
calculada para que no ocorram muitas perdas na extrao.

Figura 3.9: Simulador de UBM proporcional a unidade real.
A bomba de testes, Figura 3.10, possui modelo C-456D-305-144 da
marca PumpJack e extrai milhares de litros de leo por dia. Ainda utiliza o
modelo antigo de obteno de torque atravs do clculo das duas variveis,
clula de carga e read switch. O sistema de testes no parou o sistema j
utilizado, ele acoplou o mesmo aos seus dispositivos para que os valores
pudessem ser comparados.
54

Figura 3.10: Unidade de bombeio da PETROBRAS utilizada para testes
3.5.2 Sistema de Testes e Validao
Para testes com o novo Torqumetro e validao desta proposta, um
sistema foi implantado na unidade de bombeio citada. Este sistema contm
dois conversores analgico-digital, um mdulo ZigBee e um PC embarcado que
faz aquisio de todos os dados e os armazena para anlises. (ANJOS, ET.
AL., 2008)
O PC Embarcado que foi utilizado possui modelo EPIA-CN10000EG da
marca VIA e pode ser visualizado na Figura 3.11. Em apenas 17cm a placa
possui um processador de 1GHz, memria RAM de 1GBe encaixes PCI. Opera
entre 0 e 50C e 0 a 95% de umidade relativa do ar, entretanto como se
encontra dentro de um gabinete com coolers, pode suportar at 90C de
temperatura, ideal para operaes ao ar livre. Entre outras caractersticas tm-
se duas entradas PS2, uma entrada VGA, uma serial, uma RJ-45 (rede) e
quatro USB 2.0. No modelo montado o HD possui 120GB de capacidade de
armazenamento.
55

Figura 3.11: PC embarcado utilizado para testes
Os conversores utilizados so desenvolvidos pela National Instruments
modelo NI-6008. Possuem oito canais de entrada analgica e uma resoluo
de 12 bits. O conversor desenvolvido para o sistema embarcado final possui 12
bits, entretanto sua resoluo pode ser aumentada, elevando a preciso dos
valores adquiridos.

Figura 3.12: Conversor A/D utilizado para testes
O Mdulo ZigBee utilizado foi o XBee da empresa MaxStream. Seu
alcance em lugares com obstculos chega a 300m e mais de 1Km em campos
abertos. Possui uma taxa de transmisso de 250Kbps e trabalha com uma
alimentao de 2.8 a 3volts e freqncia de 2.4 GHz. O mdulo opera a altas
temperaturas, podendo suportar at 85C. Possui 4 c anais com conversores
Disponvel em:
http://www.cinelformacao.com
56

A/D embutidos de 10 bits de preciso que foram utilizados para aquisio de
valores de torque, temperatura e flexo no eixo. A imagem do mdulo pode ser
visualizado na Figura 3.13.

Figura 3.13: Mdulo ZigBee utilizado para testes.
O sistema de testes foi desenvolvido na linguagem G utilizando o
ambiente LabVIEW de programao, que uma programao grfica usada
para automao e medio que utiliza cones em vez de linhas de texto. Sua
programao baseada em fluxo de dados que determinam o caminho de
execuo de uma aplicao. Possui rpida e fcil integrao a diversos
dispositivos de comunicao, sendo, portanto fcil e prtico para
desenvolvimento de testes. (RAHMAN, PICHLIK, 1999)
O conjunto Torqumetro/Sistema de testes foi dividido em duas unidades
para facilitar o trabalho. Uma unidade remota, localizada diretamente na
unidade de bombeio e responsvel por adquirir os dados dos respectivos
sensores. E, uma unidade base que contem o PC embarcado e os dispositivos
utilizados para receber os dados como: conversores, mdulo ZigBee, sensores,
etc. Os dados recebidos so disponibilizados para o PC atravs de interfaces
de comunicao USB e/ou serial.
A unidade remota contm o torqumetro com ZigBee acoplado e
sensores de efeito hall para determinao de outras formas de aquisio do
torque. Isto necessrio, pois em algumas unidades a instalao do
torqumetro se torna invivel, ento uma forma alternativa de determinao de
torque, melhor que a j utilizada, deve ser proposta. Por isso parmetros de
57

rotao, tenso e corrente do motor tambm foram adquiridos. A unidade fica
localizada dentro de uma abraadeira, usada para proteo contra intempries
como na Figura 3.14.

Figura 3.14: Abraadeira contendo a unidade remota
A unidade base contm dois conversores A/D para recepo dos
parmetros citados, um mdulo ZigBee para receber os dados do torqumetro e
o PC embarcado que armazena todos os dados adquiridos. Pode ser
visualizado na Figura 3.15.
Para evitar a troca de baterias utilizadas na fase de testes, um dnamo
foi utilizado para gerao de energia. O circuito criado aproveita a rotao do
eixo para gerar energia por induo que alimentar o circuito de transduo e o
ZigBee que so utilizados no sistema.

58

Figura 3.15: Unidade base usada para testes
O sistema localizado no PC executar trs funes em paralelo para que
possibilite todas as aquisies ao mesmo tempo, provendo sincronismo nos
dados. Para facilitar o projeto e implementao, o mesmo foi desenvolvido em
trs mdulos que podem ser acessados atravs de uma interface comum
(Figura 3.16).

Figura 3.16: Interface do sistema MUB.
Os mdulos desenvolvidos so:
Mdulo de Aquisio: Neste mdulo os dois conversores A/D e o mdulo
ZigBee recebem os dados relevantes aos testes. O ZigBee n final, localizado
no torqumetro, envia os dados para o ZigBee coordenador localizado na
Conversores A/D
Mdulo
PC Embarcado
Sensores
de corrente
Sensores
de Tenso
Transformador
110v - 220v
59

unidade base. O sistema recebe os valores disponibilizados por esses trs
dispositivos atravs de programao concorrente. A Figura 3.17 mostra a
interface do sistema de aquisio de dados chamado de DataMUB.

Figura 3.17: Mdulo de aquisio
Mdulo de Tratamento: Aqui os dados j adquiridos so processados para
gerar os valores relevantes para estudo. Nesta etapa, valores de potncia de
motor, torque e ngulo so disponibilizados para que possam ser visualizados.
O mdulo chamado de JoinFileMUB e pode ser visualizado na Figura 3.18.

Figura 3.18: Mdulo de tratamento de dados
60

Mdulo de Visualizao: Mdulo que prov ao usurio a capacidade de
visualizar atravs de grficos todos os dados relevantes que foram adquiridos e
tratados. chamado de MUBView e pode ser visualizado na Figura 3.19.

Figura 3.19: Mdulo de visualizao
3.5.3 Resultados Obtidos
Os testes realizados mostraram a viabilidade de se utilizar o novo
torqumetro, e deixam claro que a tecnologia atual obsoleta para receber
suas funcionalidades, j que a velocidade de aquisio e outras
funcionalidades providas pelo torqumetro dinmico no so atendidas por ela.
As cartas dinamomtricas geradas a partir dos valores de torque se aproximam
das j existentes, eliminado os erros das anteriores.
As Figuras a seguir mostram alguns dos resultados obtidos atravs do
mdulo de visualizao. Na Figura 3.20 possvel observar o grfico com
valores de torque obtidos por extensmetros e os grficos referentes aos ms
que determinam a posio da manivela e a velocidade angular do eixo redutor
da UBM.
61

Figura 3.20: Sinais dos sensores de posio e extensmetros.
A Figura 3.21 mostra um grfico com valores de torque obtido dos
extensmetros e o ngulo da rotao da manivela gerado atravs do mdulo
de tratamento. Assim, possvel determinar em que pontos da rotao o torque
mximo.

Figura 3.21: Grfico torque x ngulo
62

Na Figura 3.22 possvel observar o grfico gerado por valores de
corrente e tenso e um grfico com a potncia calculada a partir desses
valores.

Figura 3.22: Grficos de corrente, e potncia calculada.
A partir do estudo realizado, foi possvel determinar o torque tambm
atravs da potncia do motor, mostrando-se como alternativa para as unidades
de eixo pequeno que no aceitam o torqumetro. Os valores de torque so
gerados utilizando os valores de potncia, determinada a partir das trs
tenses e trs correntes provenientes do motor, e da velocidade angular.
Apesar do sistema final ser contemplado com um CAD que possui alta
taxa de aquisio (taxa de amostragem de 20 kHz), os primeiros testes
realizados em unidades de bombeio utilizaram um CAD com baixa taxa de
amostragem (500 Hz), o que aumentou em torno de 6,5% o erro.
Para calibrao do torque, foi retirada a carga do motor e desacopladas
as correias que o liga ao redutor. O motor foi acionado e permeneceu ligado por
3 minutos e os dados dos sensores foram aquiridos e armazenados no PC
63

embarcado. O programa desenvolvido fornece o torque sem carga a partir
desses dados.
J com a unidade de bombeio em funcionamento so adquidos os
dados do motor e um programa em LabView fornece a curva de torque. O
programa recebe os valores de tenso e corrente dos dados armazenado no PC
embarcado. O grfico da Figura 3.23 mostra exemplos de curvas de tenso e
corrente correspondentes a um ciclo da manivela.

Figura 3.23: Medidas de corrente (branco) e tenso (vermelho)
Em seguida obtida a potncia instantnea e separada a energia
ativa da reativa, conforme pode ser visto na Figura 3.24. Ainda nesta Figura,
pode ser vista a curva da potencia mdia, utilizada para o clculo do torque,
observe que neste estgio ainda no foi feita a sincronizao com o ngulo da
manivela, a abcissa o nmero de aquisies.
Para determinao da velocidade do motor, velocidade e a posio da
manivela utiliza-se o sinal do efeito Hall. Ento so inseridos no programa os
dados dos parmetros eltricos do motor funcionando sem carga e se determina
o valor do torque nesta situao. Para o clculo da potncia transferida
necessrio que se determine o rendimento do motor e o rendimento de
transmisso de potncia do motor para o redutor. O rendimento da
64

transferncia de potncia calculado analizando a diferena de amplitude entre
as velocidades do motor e da entrada do redutor.

Figura 3.24 Grficos das potncias ativa, reativa e aparente.
A Figura 3.25 ilustra as curvas de torque (em graus) pelos dois mtodos
para um rendimento do sistema de 81%, apresentando um ndice de correlao
de 81,4%. A curva em vermelho indica o torque a partir do motor, e a curva
branca, o torque a partir do extensmetro.

Figura 3.25: Curvas de torque pelos dois mtodos.
65

Durante o tempo em que foram realizados os testes na unidade de
bombeio ocorreu o rompimento da haste polida fazendo com que a UB
operasse um tempo sem carga, apenas com o peso da coluna de hastes que
ficaram presas no cabrestro e com o torque devido ao contrapeso. A Figura 3.26
ilustra o momento da quebra.

Figura 3.26: Torque observado no momento da quebra da haste polida
Testes foram realizados com uma maior freqncia na aquisio de
dados para que a curva ficasse mais otimizada. Alm disso, no grfico para
potncia falta definir o valor dos parmetros necessrios para o clculo da
velocidade angular para obtermos o grfico referente aos valores de torque.
Isso tudo aperfeioa ainda mais este mtodo de determinao de torque.
As Figuras a seguir contm grficos que mostram os valores de torque
no mtodo da API e com a medio atravs de extensmetros e potncia,
observe que algumas diferenas existentes nos grficos se devem
principalmente a preciso dos mtodos e devido ao fato de que as medidas
no foram obtidas na mesma rotao da unidade de bombeio. A comparao
dos mtodos primordial para demonstrar a viabilidade do projeto. Na Figura
3.27 possvel visualizar-se a curva de torque do antigo mtodo.
66

Figura 3.27: Curva interpolada do antigo mtodo de automao
Embora o grfico obtido atravs do mtodo antigo possua uma curva
bem definida, esses valores so interpolados atravs de uma funo definida
pela API 11E. Isso deixa mascarado o erro existente. Na Figura 3.28
mostrada a curva de valores obtidos pelo extensmetro.

Figura 3.28: Curva de valores mais precisos obtida com extensmetros
No grfico obtido atravs do torqumetro dinmico, mesmo com poucos
valores na aquisio, j possvel visualizar algumas diferenas com os
valores da antiga forma de aquisio. Isso se deve a reduo do fator de erro
existente em tal mtodo. A curva ainda est menos atenuada que a anterior,
mas com uma elevao no nmero de pontos pode-se gerar uma curva mais
67

bem definida. Alm disso, nesse grfico no se utilizou nenhum mtodo de
interpolao, o que geraria uma curva ainda mais perfeita.
No grfico obtido atravs dos valores de potncia, Figura 3.29 possvel
observar a semelhana com o grfico dos valores de torque obtidos atravs de
extensmetros. Este grfico pode ainda ser otimizado atravs do clculo da
velocidade angular do motor, determinando assim os valores reais de torque
exercido na bomba.

Figura 3.29: Curva com valores referente potncia no motor

68

Capitulo 4

Sistema Embarcado para Automao
de Bombas de Petrleo

A necessidade de uma nova tecnologia para automao de bombas de
petrleo que viabilizasse o uso do torqumetro dinmico telemtrico (Lima Filho,
2007) e Anjos (2008), levou a elaborao de uma proposta que utilizasse
sistemas embarcados e computao reconfigurvel. A capacidade de
reconfigurabilidade permite que se utilize uma mesma arquitetura para vrias
formas de automao, dentre elas a determinao do torque pelo torqumetro
dinmico.
O sistema deve ser flexvel na atualizao de softwares, oferecer
possibilidades simples de expanso e ser de fcil manuteno. Diversas
tecnologias so incorporadas ao sistema tais como a transmisso de dados da
bomba para o sistema embarcado atravs de uma rede sem fios que utilizada
no torqumetro dinmico telemtrico. Embora o protocolo utilizado tenha sido
ZigBee (ZigBee Document, 2004), outros protocolos podem ser implementados
devido caracterstica de reconfigurabilidade. O mdulo do protocolo ModBus
tambm pode ser substitudo por outro protocolo. Alm disso, a interface
Ethernet disponvel permite que diversas outras tecnologias sejam acopladas
ao sistema.
O alto poder de processamento do sistema embarcado torna o sistema
capaz de realizar clculos e funes que antes s poderiam ocorrer no sistema
central devido ao baixo poder de processamento dos microcontroladores
utilizados pelos CLP. A realizao desses clculos facilita a transmisso de
dados para a CIC devido reduo na quantidade de dados e permitem ao
69

sistema embarcado tomar decises prprias em relao ao funcionamento do
sistema.
Outra vantagem da aplicao dessas tecnologias a manuteno
preditiva que atravs de alguns parmetros pode definir os estados atuais e
futuros de partes do sistema. Assim, torna-se possvel uma previso de tempo
at a quebra do redutor e a parada da bomba.
4.1 Arquitetura
A arquitetura de um sistema embarcado uma abstrao dos seus
dispositivos, o que significa que uma generalizao do sistema que
normalmente no mostra informaes detalhadas de implementao, como o
cdigo fonte do software ou os projetos de circuitos do hardware. No nvel
arquitetural, os componentes de hardware e software em um sistema
embarcado so representados como composio de alguns elementos que
interagem entre si. Elementos so representaes de hardware e/ou software
cujos detalhes de execuo tenham sido abstrados, deixando apenas
comportamentos de interdependncia de informao. Eles tambm podem ser
integrados internamente dentro do dispositivo embutido, ou existir fora do
sistema e interagir com elementos internos. Em suma, uma arquitetura
embarcada inclui elementos do sistema, elementos que interagem com o
sistema, as propriedades individuais de cada um dos elementos e as relaes
entre os elementos interativos. (NOEGARD, 2005).
O que torna a abordagem de uma arquitetura de sistemas embarcados
to poderosa e importante a sua capacidade para informalmente e
rapidamente se comunicar com um projeto atravs de uma grande variedade
de pessoas com ou sem antecedentes tcnicos, mesmo agindo como um
alicerce no planejamento do projeto ou realmente conceber um dispositivo.
Uma arquitetura pode agir como uma base slida para analisar e testar a
qualidade de um dispositivo, bem como o seu desempenho em diversas
circunstncias, pois define claramente os requisitos do sistema.
70

O modelo arquitetural utilizado para este trabalho foi apresentado por
Noergaard (2005). Este padro define uma formao tpica de um sistema
embarcado dividido em camadas interdependentes: camada de hardware,
software e aplicao, como pode ser visto na Figura 4.1. Para qualquer sistema
embarcado a camada de hardware deve estar presente. Entretanto algumas
modelagens abstraem as camadas de software e aplicao tornando essas
camadas opcionais para determinadas implementaes. Embora dispensveis
como na arquitetura de Noergaard, essas camadas so bastante importante
para se obter as vantagens da modelagem arquitetural.

Figura 4.1: Modelo arquitetural de um sistema embarcado
4.1.1 Camada de Hardware
A arquitetura proposta define uma camada de hardware, representada pela
plataforma Nios II e demais mdulos fsicos, para que seja fornecido suporte ao
funcionamento da camada de software. Nesta camada esto presentes os
seguintes dispositivos: (ANJOS, ET. AL., 2008)
FPGA Stratix II ou equivalente
Interface UART (Universal Asynchronous Receiver/Transmiter)
Interface Ethernet
Interface RS-232
Interface USB
Conversor Analgico/Digital (CAD)
71

Conversor Digital/Analgico (CDA)
Mdulo de Comunicao por Frequncias de Rdio ZigBee
Mdulo de Empacotamento e Comunicao ModBus
Dentro do chip FPGA destacamos a plataforma Nios II e os
controladores do mdulo ZigBee e do CAD. Constituem a plataforma Nios II os
seguintes componentes: ncleo do processador Nios II, barramento interno
Avalon, mdulo JTAG (Join Test Action Group) UART, memria interna,
mdulo de Ethernet MAC (Media Access Controller), memria externa,
controlador USB, Controlador ZigBee, controlador ModBus, controlador serial,
controlador ADC e os mdulos PIO (Parallel Input/Output). Finalmente, a
camada de hardware uma composio de todos os elementos enunciados
acima.

Figura 4.2: Camada de hardware
4.1.2 Camada de Sistema de Software
Seguindo o modelo de referncia apresentado, a camada de sistema de
software (Figura 4.3) subdividida em drivers de dispositivos, sistema
operacional e middleware. Inicialmente, cada perifrico da plataforma Nios II
deve fornecer um driver para que o software saiba utiliz-los corretamente,
formando o conjunto dos drivers de dispositivos. A Altera oferece um alto nvel
72

de abstrao ao fornecer uma biblioteca de funes em C denominada HAL
(Hardware Abstraction Layer) que padroniza o uso dos drivers de tal forma que
o programador possa utiliz-los pelo simples manuseio de funes GNU C.
(ANJOS, ET. AL., 2008).

Figura 4.3: Camada de sistemas de software
A pilha de protocolos NicheStack IPv4 uma das 4 pilhas InterNiche que
utilizam o protocolo TCP/IP embarcado onde cada uma foi projetada para atuar
em dispositivos embarcados. A NicheStack combina um pequeno tamanho,
extrema portabilidade e alta performance. Suportando uma larga variedade de
interfaces fsicas, a camada IP pode ser configurada como uma mquina
cliente padro, um roteador IP ou um servidor. Pode tambm atuar como um
poderoso acessrio para empacotamento na rede onde diversos padres esto
inclusos tais como: FTP, Telnet, DNS, DHCP, IGMPv1 e IGMPv2.
Da necessidade de utilizao de mltiplos processos de software
executando concorrentemente, a arquitetura proposta utiliza o sistema
operacional C/OS-II. Ele fornecido em uma verso especializada ao
processador Nios II. Chamado de RTOS (Real Time Operating System), ele
possui um kernel de tempo real e um ambiente multitarefa [LABROSSE, 2002].
A pilha de protocolos TCP/IP de fundamental importncia dentro do
sistema proposto. Nesse sentido, ela oferece um servio camada de
aplicao, configurando-se como um middleware. Utilizou-se a nichestack, uma
implementao simplificada dos protocolos que compe o TCP/IP, prpria para
Sistema
Operacional
Protocolo
73

sistemas embarcados [Dunkels, 2001]. Ela fornece uma API (Application
Programming Interface) baseada no modelo Berkeley de sockets. (BERKELEY,
2004)
A pilha NicheStack distribuda com o cdigo fonte completamente
desenvolvido em ANSI C e tambm inclui o NicheTool, uma das melhores
ferramentas para depurao e otimizao de cdigo para pilhas TCP/IP
existente no mercado.
4.1.3 Camada de Aplicao de Software
Na aplicao, nove itens implementam as funcionalidades do sistema.
So elas:
Recebimento de torque,
ngulo de rotao,
Tenso,
Corrente,
Converso analgico/digital,
Desempacotamento do protocolo ZigBee,
Manipulao dos dados,
Empacotamento e envio ModBus.
O Funcionamento da camada de aplicao segundo um diagrama de
fluxo de dados (DFD) pode ser visualizado na Figura 4.4. Neste diagrama os
processos so mostrados seqencialmente como acontecem no sistema, assim
possvel ter uma viso detalhada do seu funcionamento. (ANJOS, ET. AL.,
2008)
74

Figura 4.4: Camada de aplicao
A seguir especificado um roteiro dos acontecimentos do sistema na
camada de aplicao:
75

Os dispositivos de aquisio de dados fazem a leitura dos valores na
unidade de bombeio de petrleo como: torque no eixo, ngulo de
rotao, corrente e tenso no motor, etc.
Os dispositivos de aquisio podem ser mdulos ZigBee ou CADs,
dependendo da aplicao. Eles recebem os sinais e os converte para
digital.
Os dispositivos armazenam os dados em algum buffer ou base de
dados e os disponibiliza para o sistema embarcado.
No sistema embarcado, clculos de torque, potncia aparente ou
outros, so realizados sobre os dados recebidos. Isto ocorre para que
sejam determinados os valores de torque, ngulo, potncia,
velocidade, etc.
Os dados calculados so convertidos para o protocolo ModBus ou, se
preciso, pode ser facilmente adaptado para outro protocolo.
O sistema embarcado envia os pacotes ModBus pela sada Ethernet
se comunicando com o CIC (Central Integrada de Controle).
4.2 Componentes da Arquitetura
A seguir ser apresentada uma breve descrio dos componentes
presentes na arquitetura citada. Alguns componentes podem ser encontrados
no kit de desenvolvimento Nios II Altera. Outros foram desenvolvidos e
incorporados arquitetura atravs do software SOPC Builder, utilizado para
customizao de arquitetura embarcada e disponvel na plataforma de
programao Quartus II.
4.2.1 PIO (Parallel input/output)
O mdulo PIO Nios II um componente da biblioteca Altera SOPC
Builder incluso no kit de desenvolvimento Nios II. Ele trabalha como um
barramento paralelo de 1 a 32 bits. O componente PIO torna possvel uma
customizao do sistema atravs da escolha de dispositivos e sinais de
interface para a placa de desenvolvimento. O cdigo fonte do PIO est
76

disponvel em Verilog HDL ou VHDL para possibilitar o desenvolvimento e
incluso de subrotinas de software necessrias a uma fcil integrao do
sistema.
A utilizao de mdulos PIO permite que controladores ou outras
funcionalidades desenvolvidas para a arquitetura do sistema sejam
incorporadas arquitetura do processador Nios II. Dessa forma no
necessria uma comunicao diretamente com o barramento Avalon do
sistema.
A utilizao dessa abstrao para facilitar o desenvolvimento foi possvel
devido a baixa velocidade de atuao do sistema ser lenta em relao ao poder
de processamento do Kit de desenvolvimento. Em situaes em que a
velocidade de comunicao seja crucial, possvel utilizar-se o barramento
Avalon atravs de uma ligao direta com os controladores, no existindo os
PIO.
4.2.2 JTAG Uart
O controlador JTAG Uart junto a interface Avalon, implementam um
mtodo de comunicao serial atravs de fluxos de caracteres entre o
computador, utilizado para desenvolvimento, e o sistema SOPC Builder na
FPGA Altera. Na maioria dos projetos, o ncleo JTAG Uart elimina a
necessidade de separar a conexo serial RS-232 com o PC para caracteres de
entrada e sada. Este controlador prov uma integrao com o barramento
Avalon que esconde a complexidade das interfaces JTAG para programadores
de softwares embarcados. Perifricos se comunicam com esse controlador
atravs do controle de leitura e escrita nos registradores de dados.
Atravs do mdulo JTAG Uart possvel enviar o software embarcado
para a FPGA e, alm disso, pode-se monitorar e at mesmo depurar, todo o
funcionamento do sistema atravs do PC de desenvolvimento j que a interface
JTAG Uart tanto escreve como l dados.
77

4.2.3 Ncleo Nios II
Nios II um processador 32 bits soft-core de arquitetura embarcada
projetado especificamente para a famlia de FPGAs Altera. Nios II incorpora
muitas melhorias em relao arquitetura original Nios, tornando-o mais
apropriado para uma larga faixa de aplicaes que utilizam computao
embarcada, desde processadores de sinais digitais (DSP) a sistemas de
controle.
4.2.4 Ethernet MAC
O controlador de Ethernet MAC implementa uma comunicao no
padro Ethernet entre o barramento Avalon e a interface disponvel no Kit de
desenvolvimento. Atravs desse controlador possvel enviar os dados
empacotados no protocolo desejado e disponibilizados atravs do socket de
comunicao.
4.2.5 Controlador SDRAM
O controlador SDRAM atravs da interface Avalon, prov uma interface
mapeamento de memria Avalon (Avalon-MM) para o chip SDRAM. O
controlador permite aos projetistas criarem e customizarem sistemas na FPGA
que se conectam facilmente a chips SDRAM. Este controlador suporta padres
SDRAM como os descritos na especificao PC100.
SDRAM so comumente utilizadas em aplicaes de baixo custo e
muitas memrias volteis. Enquanto a SDRAM relativamente barata,
controladores lgicos so necessrios para executar operaes de refresh e
outros atrasos e sequncia de comandos. O controlador SDRAM conecta um
ou mais chips e agrega todos os protocolos necessrios. Internamente, na
FPGA, o ncleo apresenta uma porta Avalon-MM que aparece como memria
linear para perifricos mestres Avalon-MM.
O ncleo pode acessar subsistemas SDRAM com barramentos de dados
de tamanhos variados (8, 16, 32 ou 64 bits), diversos tamanhos de memrias e
muitos tipos de chip. O ncleo tambm pode, opcionalmente, compartilhar
78

endereos e barramento de dados com outros chips. Este recurso til em
sistemas que tem pinos de entrada e sada limitados, e ainda devem se
conectar a mltiplos chips memria alm da SDRAM.
4.2.6 Controlador USB
Embora os kits de desenvolvimento da Altera mais recentes possuam
portas USB disponveis no kit utilizado no existe interfaces disponveis, ento,
desenvolveu-se um controlador em VHDL para que fosse possvel a sua
utilizao. No controlador USB desenvolvido utilizou-se a linguagem VHDL
para criao dos cdigos de transmisso e recepo, depois disso o
controlador foi incorporado arquitetura do sistema e assim pode ser acessado
atravs de funes em C disponibilizadas pela biblioteca HAL.
O controlador pode ser utilizado atravs dos pinos reserva que so
disponibilizados na placa de desenvolvimento. O cdigo fonte projetado foi para
um chip USB da DLP Design (DLP-USB245M USER MANUAL, 2002),
entretanto, atravs de uma mudana no cdigo VHDL possvel criar-se
controladores para outros chips de USB ou at mesmo outros controladores.
Na Figura 4.5 possvel visualizar o diagrama de blocos indicando como
funciona a comunicao entre o mdulo PIO da arquitetura Nios e o chip USB
da DLP Design. Essa comunicao realizada pelo controlador USB
desenvolvido em VHDL e incorporado arquitetura.

Figura 4.5: Diagrama de blocos de comunicao entre PIO e USB
79

A comunicao entre o mdulo DLP e o controlador USB ocorre como
mostrado na Figura 4.6. Os pinos WR e RD so pinos de entrada e servem
para que um dispositivo externo dispare o ciclo de escrita ou de leitura,
respectivamente. Os pinos TXE e RXF indicam o estado atual da FIFO, ou
seja, se a FIFO de transmisso est cheia ou se a FIFO de recepo est
vazia, respectivamente. O DLP-USB245M dotado de um cristal de quartzo
com freqncia de 6MHZ. Atravs dele possvel disparar os ciclos de leitura e
escrita.

Figura 4.6: Comunicao entre a interface USB e o controlador USB
O sinal RXF indica quando a FIFO est pronta para ser lida, ou seja, h
no mnimo 1 byte na FIFO (RXF = 0). Jogando o sinal RD para zero, faz-se
com que os dados existentes no buffer de recepo sejam lidos. Para a
captao desses dados, o sinal de RD dever permanecer em zero por no
mnimo 50 ns. Na Figura 4.7 e na Tabela 4.1 mostrado o ciclo de leitura e os
tempos pr-estabelecidos pelo fabricante.
80

Figura 4.7: Ciclo de escrita pra o DLP-USB245M

Tempo Descrio Mnimo Mximo
T1 Largura do pulso ativo do RD 50 ns
T2 Tempo de carga do RD 50 ns
T3 RD est ativo para validao de dados 30 ns
T4
Tempo de espera de dados vlidos para o
RD estar inativo
10 ns
T5 RD inativo para o RXF 5 ns 25 ns
T6 RXF inativo depois do ciclo RD 80 ns
Tabela 4.1: Tempos para leitura estabelecidos pelo fabricante do DLP

A escrita de um byte na FIFO de transmisso feita atravs do
barramento D[7..0] e do sinal WR. O dado presente no barramento escrito na
FIFO na transio negativa do sinal WR. O sinal TXE indica quando a FIFO
est cheia (TXE = 1). Na Figura 4.8 e na Tabela 4.2 mostrado o ciclo de
escrita e os tempos pr-estabelecidos pelo fabricante.
81

Figura 4.8: Ciclo de escrita pra o DLP-USB245M

Tempo Descrio Mnimo Mximo
T7 Largura do pulso ativo do WR 50 ns
T8 Tempo de carga do WR 50 ns
T9
Tempo de configurao de dados antes de
o WR ficar inativo
20 ns
T10 Tempo de espera para o WR inativo 10 ns
T11 WR inativo para o TXE 5 ns 25 ns
T12 TXE inativo depois do ciclo de leitura RD 80 ns
Tabela 4.2: Tempos para escrita estabelecidos pelo fabricante do DLP.
O mdulo PIO interno a plataforma Nios II possui os sinais necessrios a
conexo com o mdulo controlador da USB, que por sua vez faz a interface
com o dispositivo DLP. Desses sinais, 4 so de entrada (TXE_n, transmitido,
dados_in e RD_n) e 3 so de sada (transmite_n, leitura_fifo e dados_out),
sendo dados_in e dados_out barramentos de 1 byte cada um e os demais
sinais de 1 bit cada. Nota-se que o controlador USB cria uma abstrao de
leitura e escrita j que transforma o barramento bidirecional do DLP em dois
82

barramentos distintos para comunicao com a PIO, sendo um para leitura e
outro para escrita (dados_in e dados_out, respectivamente). Essa abstrao
necessria para o correto funcionamento do barramento bidirecional,
diretamente atravs do software embarcado. Na Figura 4.9 possvel visualizar
um diagrama de fluxo indicando a lgica que foi utilizada nos dois algoritmos
implementados.
Para a escrita no barramento dados_out, o protocolo o seguinte:
coloca-se o valor 0 no sinal leitura_fifo, indicando ao controlador USB que ele
deve desabilitar a leitura da fila do DLP, pois ele no poder escrever se estiver
lendo, devido ao barramento bidirecional. Em seguida, feita uma verificao
se o sinal TXE_n igual a zero. Essa comparao objetiva saber se o
controlador USB terminou de fazer leitura do dispositivo DLP, pois s ser
possvel escrever na fila quando ela tiver sido esvaziada pela leitura do
controlador. Quando o controlador USB estiver pronto para receber do
barramento dados_out, ele colocar o sinal transmitido em 1. Por isso, deve-se
verificar tal sinal antes de iniciar a escrita propriamente dita. Para tanto,
escreve-se o byte a ser transmitido no barramento dados_out e coloca-se o
sinal transmite_n em 1, indicando que ao controlador que ele pode realizar a
operao de escrita. O controlador USB dever atribuir 0 ao sinal transmitido,
permanecendo assim at o fim da operao. Assim, quando esse sinal voltar
para 1, significa que a transmisso do byte foi realizada. Para finalizar a escrita,
coloca-se o sinal transmite_n em 1.
83

Figura 4.9: Algoritmos de transmisso e recepo de dados pela USB
J para a leitura do barramento dados_in, o algoritmo o seguinte:
primeiramente, necessrio indicar ao controlador USB que inicie a leitura da
fila do dispositivo DLP. Para tanto, coloca-se o sinal leitura_fifo em 1. Ento,
espera-se que o controlador faa a leitura do byte. Primeiro, o sinal RD_n deve
ir para 0 indicando incio da operao de leitura. Depois, deve ir para 1
indicando seu trmino, quando, ento, pode-se ler do barramento dados_in o
byte desejado. Para finalizar a operao de leitura, deve-se colocar o sinal
leitura_fifo em 0.
4.2.7 Controlador ZigBee e ModBus
O controlador ZigBee e o controlador ModBus foram desenvolvidos em
software e incorporados ao sistema. A escolha pelo desenvolvimento em
software se deu principalmente pela possibilidade de mudana de protocolo
para outros projetos e tambm pela fcil mutabilidade j que no interferia
diretamente na arquitetura do sistema.
84

Atravs do controlador ZigBee, os dados recebidos atravs da unidade
ZigBee so convertidos, ou seja, desempacotados, interpretados e
disponibilizados para que outro processo do sistema possa manipular esses
dados e envi-los ou disponibiliz-los para outro processo.
O controlador ModBus por sua vez, empacota os dados em ModBus e
se comunica com o mestre da rede realizando as funes requisitadas pelo
mesmo.
4.2.8 Controlador Serial
O ncleo UART com a interface Avalon implementa um mtodo para
comunicao serial atravs de streams de caracteres entre sistemas
embarcados na FPGA Altera e dispositivos externos. O ncleo implementa o
protocolo RS-232 e disponibiliza taxa de dados ajustvel, paridade,bits de
dados e de parada e opcionalmente sinais de fluxo de controle RTS/CTS. Este
conjunto de caractersticas configurvel, permitindo aos projetistas
implementarem apenas as funcionalidades necessrias para determinado
sistema.
4.2.9 Controlador ADC
O controlador ADC foi desenvolvido para atuar diretamente nos dados
recebidos atravs do conversor desenvolvido em laboratrio para o projeto. O
controlador foi desenvolvido em VHDL e incorporado arquitetura. O ADC
recebe os dados analgicos do ambiente, converte-os para digital com 12 bits
de preciso e os disponibiliza para o sistema embarcado atravs dos pinos
existentes no kit de desenvolvimento.
4.3 Implementao do Empacotador MODBUS
O empacotador ModBus atuar nos dados tratados na FPGA,
disponibilizando-os em interfaces de comunicao j convertidos no formato
desejado. Os dados contendo os valores das aquisies podem ser enviados
de duas formas distintas. Uma forma foi adotada na fase de testes e utilizou a
interface serial RS232. Isso se deve ao fato de que a CLP j existente nos
85

campos de extrao aceita entradas de dados j empacotados em formato
ModBus atravs de uma entrada serial o que facilitou os testes iniciais.
A outra forma, utilizada no prottipo final, usa o protocolo ModBus TCP.
A utilizao desse tipo de implementao se deve a possibilidade de
reutilizao de transmissores de freqncias de rdio de alta potncia, j
existentes nas unidades de bombeio. As antenas podem ser vistas na Figura
4.10. Quando o protocolo ModBus TCP utilizado as antigas CLPs que esto
em uso perdero sua funcionalidade podendo ser substitudas pelo novo
sistema reconfigurvel, mais robusto, expansvel e preciso. Agora o sistema
pode se conectar diretamente aos transmissores inutilizando as CLPs.

Figura 4.10: Transmissor de RF ao lado das unidades de bombeio.
Para desenvolvimento do empacotador MODBUS no sistema duas
hipteses de implementao foram levantadas: Implementao em Software e
Implementao em Hardware. Em Hardware, o sistema desenvolvido ficaria
dentro da FPGA, independente do sistema Nios II, j na implementao em
software, o sistema atuaria de uma maneira bastante simples e usando o
processamento disponibilizado pelas tecnologias utilizadas (como processador
Nios II, memrias, etc.), inseridas no sistema embarcado.
Para definir qual a melhor forma de implementao estudos e testes
foram desenvolvidos atravs de simuladores e de implementaes em FPGAs.
Estes estudos dimensionaram as caractersticas de cada implementao,
86

distinguindo vantagens e desvantagens de cada uma. Assim, optou-se pela
implementao em software, principalmente pela facilidade de mudana para
outros tipos de protocolos.
A implementao em software traz uma enorme vantagem que a
possibilidade de desenvolvimento na linguagem C/C++, facilitando e
acelerando o desenvolvimento e mudanas de cdigo. Entretanto torna o
processamento um pouco mais lento que para a aplicao desejada no
impediu o funcionamento satisfatrio do sistema.
O protocolo MODBUS/TCP basicamente inclui um pacote ModBus
dentro de um pacote TCP de uma maneira simples. Esta uma transao
orientada conexo na qual toda solicitao espera uma resposta. Esta
tcnica de solicitao/resposta se adqua bem com a natureza mestre/escravo
do ModBus, adicionando a isso a grande vantagem que o padro Ethernet
oferece na utilizao industrial. O uso do Open ModBus dentro de um pacote
TCP prov uma soluo totalmente escalvel de dez a dezenas de milhares de
ns na rede sem o risco de comprometer outras tcnicas I que poderiam ser
usadas. (MODICON, 1996) Um exemplo de pacote ModBus/TCP pode ser visto
na Figura 4.11.

Figura 4.11: Modelo do pacote ModBus TCP
Como visualizado na Figura o pacote ModBus (azul) conter o endereo
do mestre ou escravo (dependendo se for solicitao ou resposta) o cdigo da
funo que ser realizada e os dados necessrios. Como em nosso sistema
apenas utilizamos um mestre e um escravo, simplificamos o pacote ModBus
retirando o campo de endereo. Observe que isso no afeta o funcionamento
do protocolo, entretanto para uma rede de mais ns necessrio que seja
87

reprogramado essa caracterstica que pode ser implementada devido
reconfigurabilidade j citada.
Para confirmar o recebimento tambm faz-se necessrio que o mestre
(aquele que requisitou o servio) retorne para o escravo um pacote dizendo
que recebeu os dados certos. Neste caso foi criado um pacote de resposta que
indica que o pacote recebido est correto. A seguir, na Tabela 4.3, so
mostrados os pacotes ModBus criados e utilizados para o projeto. Cada pacote
possui seis caracteres hexadecimal onde os dois primeiros indicam a funo
ModBus e os quatro ltimos indicam os dados referentes funo. No foi
utilizado o campo endereo pelo fato de todos os testes terem sido feitos
somente com um mestre e um escravo.
PACOTE FUNCIONALIDADE
Aquisio de uma Quantidade Pr-Definida de Dados
7AXXXX
Mestre: Solicita aquisio de dados da unidade de bombeio
atravs de uma quantidade definida atravs do valor XXXX
que so nmeros hexadecimais. Ex: Mestre solicita 10
aquisies 7A000A
Escravo: Retorna o valor adquirido da unidade de bombeio
atravs das 4 variveis hexadecimais. Ex: 7A001F, 7A0020,
7A001D...
Aquisio de Dados por Tempo Indeterminado
7BFFFF
Mestre: Solicita aquisio constante ao escravo. Nesta
funo o escravo manda os dados adquiridos
constantemente at que um comando de parada seja
enviado.
7BXXXX
Escravo: Envia atravs das 4 variveis XXXX os valores
adquiridos durante a aquisio constante.
Parar Aquisio Quando Estiver Constante
A11000 Mestre: Solicita o cancelamento da aquisio constante.
A11001
Escravo: Avisa ao mestre que a solicitao de parada no
foi realizada porque o sistema no se encontrava em
88

aquisio constante.
A11002
Escravo: Avisa ao mestre que a aquisio constante foi
parada com sucesso.
A11003
Escravo: Avisa ao mestre que a aquisio constante no
est sendo realizada porque o sistema no est adquirindo
no momento ou a bomba est desligada.
Desligamento da Bomba de Petrleo
A21000
Mestre: Solicita a parada da bomba de petrleo, ou seja, o
desligamento do motor.
A21001
Escravo: Informa ao mestre que a bomba j se encontra
parada.
A21002
Escravo: Informa ao mestre que a bomba foi parada com
sucesso.
A22000
Mestre: Solicita o acionamento da bomba de petrleo, isto ,
ligar o motor da mesma se estiver parado.
A22001
Escravo: Avisa ao mestre que a bomba j se encontra em
funcionamento.
A22002
Escravo: Avisa ao mestre que a bomba foi acionada com
sucesso.
A23000
Mestre: Solicita ao sistema que ative a parada automtica da
bomba. Isso permite ao sistema desligar ou diminuir a
rotao do motor da bomba se uma situao crtica for
encontrada.
A23001 Escravo: Parada automtica configurada com sucesso.
A24000
Mestre: Solicita o cancelamento da parada automtica da
bomba tornando a parada manual, entretanto, se uma
situao crtica for encontrada o escravo sempre avisar ao
mestre.
A24001
Escravo: Informa ao mestre que a parada automtica foi
cancelada.
A25001
Escravo: Avisa ao mestre que uma situao crtica foi
encontrada na bomba mas que no havia permisso para
89

resolver a situao. Este aviso deixa a cargo do mestre
(usurio) a deciso que ser tomada.
A26001
Escravo: Informa que uma situao crtica foi encontrada e
que a bomba foi desligada ou reduziu a rotao do motor
para evitar acidentes ou situaes indesejveis.
CC0000
Mestre ou Escravo: Indica que o pacote recebido est
correto e foi ou est sendo processado.
EE0000
Mestre ou Escravo: Avisa que o pacote recebido
desconhecido.
FF0000 Mestre: Finaliza a conexo com o escravo.
Tabela 4.3: Pacotes ModBus criados para controle das UB.
4.4 Funcionamento do Sistema
Para um funcionamento adequado do sistema, o processador se utiliza
da memria interna para armazenamento de dados e instrues com um tempo
de resposta bastante pequeno, j que a comunicao entre esses dois
elementos se d pelo barramento interno Avalon.
Diversos processos atuam nos dados recebidos pelo sistema. As
principais etapas no funcionamento destes processos so:
Obteno de Dados: O processo inicial do sistema, que se localiza ainda na
camada de aplicao, obter os dados referentes aos dispositivos de hardware
externos FPGA. O mdulo ZigBee disponibiliza em seus pinos de sada os
pacotes de dados recebidos atravs das ondas de rdio. Ou, para outro caso, o
conversor A/D disponibiliza os dados adquiridos de tenso e corrente.
Tratamento de Dados: Como mostrado anteriormente, a utilizao do CAD ou
do mdulo ZigBee depender da unidade de bombeio a ser utilizada. A
princpio a transmisso via rdio freqncia ser adotada, menos nas bombas
de pequeno eixo que no possuam espao para acoplamento da abraadeira,
neste caso os dados do motor adquiridos pelo conversor sero necessrios.
Isso refora a vantagem de utilizao de um dispositivo reprogramvel.
90

Envio de Dados: Aps o recebimento e armazenamento dos dados os mesmo
so processados para se obter as medidas desejadas. Este tratamento nos
dados torna-os propcios a serem enviados atravs do protocolo MODBUS. Na
etapa de testes, os dados foram enviados para a CLP j existente nos campos
prximo a UB, atravs de uma freqncia muito baixa, entretanto na etapa final
deste projeto a interface Ethernet foi utilizada enviando diretamente para a
antena ModBus, sem utilizao da CLP. Com o uso do ModBus TCP, uma das
melhorias existentes neste protocolo, os dados so transmitidos atravs de
redes sem fios de alta potncia para a estao de controle dos campos de
extrao, denominada Central Integrada de Controle (CIC).
Cada mdulo de aquisio possui um controlador especfico que
gerenciado para que os dados possam ser adquiridos. Os controladores
desenvolvidos se comunicam com os mdulos PIO do sistema abstraindo
bastante o desenvolvimento de cdigo, pois no necessria uma
comunicao direta com o barramento Avalon. Estes mdulos PIO so de
extrema importncia na implementao do sistema processado, pois os
mesmos oferecem portas de entrada e de sada, estabelecendo uma
comunicao entre a plataforma Nios II e os blocos do sistema.
4.5 Circuito ZigBee de Recepo
Para utilizao do mdulo ZigBee na recepo de dados, uma interface
foi desenvolvido para acoplar o mdulo e disponibilizar os dados atravs de
barramentos desenvolvidos. O ZigBee que est sendo utilizado o Xbee da
MaxStream. Este dispositivo possui 20 pinos que sero utilizados para integrar
ao circuito. Os dados recebidos pelo mdulo base so disponibilizados j na
forma serial atravs do pino 2. O dispositivo ZigBee contm um
microcontrolador para processamento de dados e tambm um mdulo ZigBee
que empacota/desempacota os dados no protocolo ZigBee. Um diagrama de
comunicao entre os dois dispositivos pode ser visualizado na Figura 4.12.
91

Figura 4.12: Diagrama de transmisso ZigBee.
Aps recebidos, processados e empacotados, os valores so enviados
de um dispositivo ZigBee para outro. Os valores podem ento ser enviados
para a FPGA que receber em seus pinos os pacotes no formato ZigBee. Os
pacotes e algumas caractersticas inerentes ao dispositivo possuem um padro
j determinado atravs de normas estabelecidas no manual. Assim possvel
ler os valores contidos no pacote e transform-los adequadamente, tornando-
os suscetveis ao empacotamento MODBUS.
O circuito desenvolvido para receber o mdulo ZigBee foi ligado ao Kit
de desenvolvimento da Altera para a fase de testes. Essa comunicao se
d atravs de pontos de conexo tipo jumper j existentes no kit.
Para desenvolvimento do circuito utilizou-se um sistema CAD chamado
P-CAD. O modelo de um dos circuitos ZigBee desenvolvido pode ser
visualizado nas Figuras 4.13 e 4.14 e o esquema eltrico da mesma na figura
4.15. Atravs desse software foi possvel realizar todo o desenho eltrico que
depois foi impresso em uma placa feita de fenolite. Uma das placas
desenvolvidas contendo o mdulo ZigBee que ficar dentro da abraadeira no
redutor da bomba de petrleo mostrada na Figura 4.16.
92

Figura 4.13: Modelo P-CAD da placa de recepo ZigBee

Figura 4.14: PCB contendo modelo de placa de recepo ZigBee

93

Figura 4.15: Esquema eltrico da placa de recepo ZigBee.

Figura 4.16: Prottipos com o circuito de recepo e o mdulo ZigBee

94

CAPTULO 5

Ferramentas e Metodologia

A metodologia utilizada para este trabalho consiste na diviso dos
processos em etapas. Desta forma, tem-se uma estrutura consistente que
serve de guia durante a personalizao de um sistema (ALTERA, 2004). Nas
etapas inicias fora realizados estudos de tempo e hardware necessrio para
desenvolvimento e implementao do sistema. Aps essa fase iniciaram-se os
estudos referentes a cada dispositivo e tecnologia utilizada para que facilitasse
sua utilizao.
O processo de implementao foi orientado pelas necessidades do
sistema, embora algumas poucas mudanas tenham sido necessrias em
relao aos modelos de projeto criados. Durante essa etapa foram necessrias
comparaes, estudos de caso e verificao de aplicaes em reas similares
para que as melhores decises pudessem ser tomadas e a proposta se
aproximasse cada vez mais do que foi desejado.
No processo de diagramao e engenharia de requisitos foram
abordados todos os principais focos do projeto. Os diagramas UML elaborados
servem como base para um desenvolvimento satisfatrio do sistema. A
elaborao de tais diagramas foi norteada pelas necessidades que foram
sendo percebidas no sistema de testes. Os modelos devem produzir uma viso
abrangente da realidade, mostrando todos os fatores envolvidos e todos os
relacionamentos, existentes ou no, entre eles. Estes diagramas so
detalhados no Apndice II desta proposta.
95

5.1 Softwares Utilizados para Desenvolvimento
Para desenvolvimento foi utilizada a plataforma de programao Quartus
II. O software Altera Quartus II fornece um completo ambiente de projeto
multiplataforma que se adapta facilmente s necessidades especficas de
concepo. Trata-se de um ambiente global para projetos de sistema em chips
programveis (system-on-a-programmable-chip - SOPC). O software Quartus II
verso 8.0, inclui solues para todas as fases de projetos de FPGAs e CPLDs.
Alm disso, o Quartus II permite que voc use o a interface grfica e interface
de linha de comando para cada fase do fluxo de projeto.
5.1.1 SoPC Builder
O desenvolvimento teve incio com a customizao do processador Nios
II atravs do SoPC Builder que uma ferramenta exclusiva do Quartus II.
Atravs dele possvel construir uma arquitetura embarcada de maneira forma
prtica.
O SoPC Builder uma ferramenta da Altera integrada ao Quartus para
automatizar a criao de sistemas compostos por diversos cores como
processadores, co-processadores, perifricos, memrias e lgicas de usurios
baseados em barramentos. Um componente SOPC Builder um projeto cujo
mdulo SOPC Builder reconhece automaticamente e pode integrar um sistema.
Podem ser tambm definidos e adicionados componentes personalizados. O
SOPC Builder conecta mltiplos componentes em conjunto para criar um
arquivo HDL de nvel mais alto chamado mdulo do sistema. Ele gera o
sistema de interconexo que contm a lgica de administrar a conectividade de
todos os componentes do sistema. Seu funcionamento mostrado na Figura
5.1 e na Figura 5.2 pode-se visualizar a arquitetura que foi customizada para
este projeto utilizando o SOPC Builder.
96

Figura 5.1: Fluxo de funcionamento do SoPC Builder

Figura 5.2: Arquitetura no SOPC Builder
97

A ferramenta da Altera suporta atualmente os barramentos Avalon e
AMBA Advanced High-Performance Bus (AHB), gerando automaticamente a
lgica de interconexo ao barramento especificado. O barramento utilizado
neste projeto o Avalon. Sua biblioteca de componentes inclui itens como:
Processadores;
Microcontroladores Perifricos;
Digital Signal Processing (DSP) cores;
Intellectual Property (IP) cores;
Perifricos de Comunicao;
Interfaces:
Memrias (on-chip ou off-chip);
Barramentos e Pontes;
Application-Specific Standard Products (ASSPs);
Application-Specific Integrated Circuits (ASICs);
Componentes de Software:
Arquivos header;
Drivers Genricos em Linguagem C;
5.1.2 Plataforma de Desenvolvimento de Software Nios II
O ambiente de desenvolvimento integrado (IDE) Nios II a principal
ferramenta para o desenvolvimento de software para a famlia de
processadores embarcados Nios II. O IDE Nios II baseado no IDE Eclipse
utilizando as ferramentas de desenvolvimento C/C++ CDT (C/C++
Development Tools). Ele oferece todas as caractersticas esperadas de um
ambiente de desenvolvimento de projetos de software profissional (gestor de
projeto, editor cdigo, depurador, etc.), mas tambm oferece recursos
adicionais para aumentar a produtividade em FPGA baseado no
desenvolvimento do sistema. (ZAMMATTIO, 2006). Estas incluem:
98

Importao de todos os parmetros de hardware relevantes para o
ambiente de software
Gerao de uma biblioteca ANSI "C" que customizado para o sistema
de hardware
incluso automtica e configurao dos controladores de perifricos
Funes ANSI "C" e UNIX para auxiliar classes de dispositivo padro
Um framework pr-definido para a criao de controladores de
perifricos que so captadas a partir de dependncias de hardware
Quando o sistema de hardware criado, a ferramenta SOPC Builder
grava todos os parmetros do sistema em um formato de arquivo de texto
simples (*.ptf). Este arquivo contm informaes sobre a configurao de cada
componente e como ele tem sido conectado dentro do sistema. Quando o
desenvolvedor de software cria um novo projeto a IDE solicita a localizao do
arquivo .ptr no sistema. A informao contida neste arquivo ento usada para
criar um ambiente de desenvolvimento de software adaptado para
corresponder ao processador e a configurao do sistema.
Um arquivo chamado system.h criado aps a anlise do arquivo .ptr. O
system.h contm toda a informao relevante de hardware para o processador,
perifricos e configurao do sistema, sob a forma de declaraes #define
claramente especificadas para cada parte do sistema. Isto significa que essa
biblioteca pode ser utilizada ao longo de todo o sistema de software para
abstrair todos os detalhes de hardware a partir da aplicao desenvolvida. Por
exemplo, o IDE constri uma biblioteca ANSI 'C', com base no cdigo fonte da
newlib, que foi adaptado para corresponder configurao do processador; isto
muito importante para caractersticas como sistema de inicializao,
interromper handlers e gerenciamento de cdigo em cache. As funcionalidades
e relacionamentos do Nios II IDE podem ser vistas na Figura 5.3.
(ZAMMATTIO, 2006)
99

Figura 5.3: Viso das funcionalidades do Nios II IDE
A fim de delimitar claramente a aplicao e o cdigo do sistema de
hardware especfico, o Nios II IDE cria dois subprojetos, um projeto de
aplicao e um projeto de biblioteca do sistema. O projeto de aplicao
usado pelo desenvolvedor para adicionar e gerenciar os arquivos usados para
criar a aplicao. O sistema de biblioteca contm todo o hardware especfico
para as funes para abstrair todos os detalhes de hardware do desenvolvedor,
por isso conhecida como a biblioteca de sistema Hardware Abstraction Layer
(HAL). Esta biblioteca oferece um consistente ambiente de programao
C/C++, independentemente das caractersticas de hardware subjacentes ao
sistema e separa o cdigo da aplicao do cdigo dos dispositivos de
hardware.
O sistema de bibliotecas HAL um ambiente leve que proporciona uma
interface simples do controlador de dispositivos para os programas se
comunicarem com o a camada de hardware. A interface do programa de
aplicao (API) HAL est integrada com o padro ANSI C e permite o acesso
biblioteca e dispositivos perifricos e arquivos usando biblioteca e funes
familiares de C, tais como printf (), fopen (), fwrite (), etc. Um exemplo do
sistema de bibliotecas pode ser visto na Figura 5.4.

100

Figura 5.4: Abstrao de hardware do sistema de bibliotecas HAL
O sistema de bibliotecas HAL prov os seguintes servios:
Integrao com a biblioteca newlib do padro ANSI C (Funes
Familiares da biblioteca padro;
Drives de dispositivos perifricos (Acesso a todos os dispositivos
perifricos do sistema);
API HAL (Prov um consistente padro de estilos de interfaces UNIX
para os servios HAL);
Inicializao do sistema (Executa as tarefas de inicializao para o
processador);
Inicializao de dispositivos (Instancia e inicializa os dispositivos no
sistema antes do main( )).
5.2 Interface USB
A interface de comunicao USB utilizada foi criada pela DLP Design
que possui baixo custo e uma alta usabilidade na construo dos mais variados
tipos de sistemas digitais (prototipagem de dispositivos). A interface DLP-
USB245M mostrada na Figura 5.5, funciona basicamente como uma fila do tipo
101

FIFO, o que a torna um mtodo fcil e eficaz na transmisso de dados entre o
host e o controlador. (DLP-USB245M USER MANUAL, 2002)

Figura 5.5: DLP-USB245M.
Em sua composio consta um de uma EEPROM de referncia 93C46 e
outro chip de nome FT245BM cuja fabricao pertence FTDI (Future
Technology Devices International Ltd). A EEPROM possibilita a customizao
de parte da configurao bsica da interface, como a taxa de transmisso e a
forma de comunicao, informaes como o PID e VID da interface USB, bem
como seu nmero serial. O responsvel por implementar uma FIFO tanto de
leitura como de escrita que utiliza os 8 bits do barramento de comunicao de
forma bidirecional o FT245BM, mostrado na Figura 5.6.

Figura 5.6: FT245BM.
O dispositivo DLP-USB245M, possui 24 pinos de comunicao. Destes
pinos 8 so reservados para a comunicao bidirecional, formando assim um
barramento de 8 bits.
102

CAPITULO 6

Resultados

Para que fosse possvel testar o sistema desenvolvido foi necessria a
criao de um software que pudesse atuar como mestre (cliente) na rede
ModBus. Portanto, um sistema em Java foi criado para simular a central
integrada de controle. Esse sistema, nos campos de extrao recebe os dados
para controle e monitoramento de todas as unidades de bombeio.
Atualmente diversos sistemas de controle e monitorao so utilizados
nas centrais de monitoramento. Um dos mais softwares atuais que est
substituindo muitos outros antigos existentes no mercado se chama Sisal e foi
desenvolvido pela UFRN e a RN Tecnologia em parceria com a PETROBRAS.
Nosso sistema tenta simular apenas as funcionalidades do Sisal referentes s
funes que a automao de bombas atinge (torque, ngulo de rotao, etc.),
pois, alm disso, o Sisal possui diversas outras finalidades, dentre elas a
utilizao de inteligncia artificial para determinar situaes timas no
funcionamento das Unidades de Bombeio como por exemplos a determinao
tima da posio dos contrapesos.
6.1 SERCREF
O sistema como um todo, incluindo a parte de sistema embarcado,
sistema de monitoramento e outros, foi chamado de SERCREF (Sistema
Embarcado Reconfigurvel para Controle de Redes Sem Fios) visto que o
mesmo poderia ser aplicado a outros tipos de automao como mostrado no
estudo de caso apresentado no apndice B.
O sistema de monitoramento e controle desenvolvido para etapa de
testes e simulaes foi desenvolvido em Java, uma linguagem poderosa em
103

ambientes distribudos complexos como a rede Internet. Mas sua versatilidade
permite ao programador ir alm, oferecendo uma poderosa linguagem de
programao de uso geral, com recursos suficientes para a construo de uma
variedade de aplicativos que podem ou no depender do uso de recursos de
conectividade. (WUT, 1997)
O sistema desenvolvido em Java se conecta ao sistema embarcado
atravs de sockets e utilizando o padro Ethernet de comunicao. Isto faz-se
necessrio para utilizao do ModBus TCP. Atravs da troca de pacotes
possvel monitorar o sistema e controlar diversas funcionalidades atravs de
comandos com o usurio. Na Figura 6.1 possvel visualizar a interface inicial
do sistema e na Figura 6.2 o sistema se conectando ao servidor (escravo)
atravs do IP e da porta configurada no sistema em C (localizado no interior da
FPGA).

Figura 6.1: Tela inicial do sistema.
104

Figura 6.2: Sistema conectando
Aps a conexo o sistema possui duas funes principais que o
monitoramento/controle de unidades de bombeio de petrleo e o
monitoramento de automao residencial. As funcionalidades podem ser
monitoradas atravs do status da unidade de bombeio como visualizado na
Figura 6.3. Atravs do status possvel visualizar o atual funcionamento da
bomba.
As caractersticas abordadas so:
Ativada: Indica se a bomba est ligada ou no.
Adquirindo: Informa se o sistema est adquirindo dados naquele momento.
Modo Automtico: Se o sistema est em modo automtico, ele permite que o
sistema embarcado tome decises em relao bomba de petrleo,
desligando ou diminuindo a rotao em casos de situao crtica.
105

Situao: Indica se uma situao crtica foi encontrada ou no. Na Figura a
situao normal indica que os valores de torque encontram-se dentro dos
padres aceitveis. Mesmo quando o sistema est em modo automtico ele
avisa se alguma situao crtica for encontrada.
Mtodo: Mostra o mtodo que est sendo utilizado na aquisio de dados.
Mtodo Telemtrico utilizando o mdulo ZigBee ou mtodo de aquisio dos
parmetros eltricos do motor utilizando o CAD.

Figura 6.3: Status da unidade de bombeio
Alm disso, as funcionalidades podem ser modificadas atravs de
comandos designados pelo usurio. Na Figura 6.4 pode-se ver a solicitao de
uma aquisio de dados constante no mdulo ZigBee. Aps iniciar a aquisio
constante possvel visualizar o grfico dos dados recebidos atravs da
funcionalidade visualizar dados.

106

Figura 6.4: Tela do programa para iniciar/parar a aquisio constante
6.2 Monitoramento de Unidades de Bombeio de Petrleo
Aps iniciar a aquisio, o sistema disponibiliza ao usurio a
possibilidade de acompanhar atravs de um grfico os valores de torque
adquiridos. Na aquisio constante os dados so armazenados em uma base
de dados no computador que possui o sistema instalado. Como mostrado na
Figura 6.5 o sistema funciona da seguinte maneira:
O mdulo ZigBee base da rede de sensores sem fios recebe os dados
do ZigBee remoto que adquire os dados da fonte (que no nosso caso a
unidade de bombeio de petrleo); Ou no caso da aquisio dos
parmetros eltricos do motor, os dados so convertidos pelo CAD
criado em laboratrio e disponibilizados atravs da conexo USB
desenvolvida.
O sistema embarcado que contm a FPGA recebe os pacotes ZigBee
(ou do CAD) com os dados adquiridos e os interpreta, faz os clculos
107

desejveis, empacota-os no protocolo ModBus e os disponibiliza no
servidor de sockets criado tambm interno FPGA;
O Sistema em Java localizado em um computador de uso geral recebe
os dados atravs da rede, independente do meio fsico (nos testes em
laboratrio rede de cabos Ethernet e no caso dos campos de extrao
redes sem fios MODBUS TCP), e os armazena em uma base de dados.
A base de dados pode ser acessada por um servidor web que
disponibiliza os dados atravs de um site para monitoramento.

Figura 6.5: Funcionamento completo do sistema.
A base de dados utilizada foi PostgreSQL que um excelente
gerenciador de bancos de dados, extremamente confivel, contendo todas as
caractersticas dos principais bancos de dados do mercado. Possui licena
para uso gratuito, seja para fins estudantis seja para realizao de negcios,
possibilitando que empresas o utilizem livremente.
Enquanto os dados so armazenados, o usurio pode acompanhar o
grfico dos valores adquiridos atravs do sistema. Exemplos de ondas como
senide, dente de serra e quadrada, obtidas atravs de um gerador de ondas
ligado ao mdulo ZigBee, so mostrados nas Figuras 6.6, 6.7 e 6.8.
108

Figura 6.6: Senide gerada atravs de um gerador de ondas.

Figura 6.7: Funo dente de serra
109

Figura 6.8: Onda quadrada

Figura 6.9: modulo ZigBee o gerador de ondas utilizado
Alguns testes foram realizados no simulador desenvolvido na fase inicial.
Estes testes tinham como objetivo gerar um grfico de torque semelhante aos
110

obtidos nas verdadeiras unidades de bombeio antes dos testes em campo. Isso
acarreta uma maior credibilidade no sistema.

Figura 6.10: Imagem com o prottipo instalado.
6.3 Configurao do Hardware Utilizado
Na arquitetura desenvolvida foram inseridas as funcionalidades que so
utilizadas em qualquer modo de aquisio (torqumetro dinmico ou parmetros
eltricos do motor). Na Tabela 6.1 so mostradas as caractersticas do sistema
disponibilizadas no relatrio de compilao da ferramenta Quartus II 8.0.
A freqncia mxima assumida pela arquitetura de aproximadamente
56MHz importante ressaltar que o sistema aceita um clock externo maior que
o utilizado.
O sistema desenvolvido em C foi inserido na memria SDRAM que
contm 16MB disponveis utilizando somente 1,12MB para carregar o
programa desenvolvido. Durante a execuo do sistema, a criao de
111

variveis, buffers e outros elementos de programao aumentam um pouco a
utilizao da memria, mas mesmo assim o espao bem mais do que
suficiente para esse processo.
Caractersticas da Arquitetura do Sistema
Status de fluxo: Successful (Fri Nov 27 10:34:21 2008)
Verso do Quartus II: 8.0 build 215 05/29/2008
Nome de Reviso: Arquitetura_Final
Nome da entidade de alto nvel: Arquitetura_Final
Famlia: Stratix
Dispositivos: EP1S10F780C6
Modelos de Temporizao: Final
Requisitos de tempo encontrados: Sim
Total de elementos lgicos: 6.160 / 10.570 (58%)
Total de pinos: 153 / 427 (36%)
Total de pinos virtuais: 0
Total de bits de memria: 669.968 / 920.448 (73%)
Blocos DSP de 9 bits: 8 / 48 (17%)
Total de PLLs (phase-locked loop): 1 / 6 (17%)
Total de DLLs (delay-locked loop): 0 / 2 (0%)
Tabela 6.1: Caractersticas da arquitetura desenvolvida para o sistema.
6.4 Comparao do Sistema Proposto com outros Sistemas
Para que fosse possvel uma comparao entre a utilizao do sistema
embarcado reconfigurvel e as tecnologias utilizadas hoje, os dados mais
relevantes foram comparados e montados na Tabela 6.2 para anlise e
comparao. Dentre as marcas utilizadas principalmente pela PETROBRAS
esto o ZAP da HI tecnologia, a CAC e os controladores da LUFKIN.
112

Sercref CAC ZAP LUFKIN
Tecnologia
Wireless
Sim
(Protocolo
ZigBee)
No No No
Reconfigurabilid
ade
Sim
(Completa)
Sim
(Parcial)
Sim
(Parcial)
Sim
(Parcial)
Possibilidades
de expanso
Sim
(Muitos
Mdulos)
Sim
(Alguns
Mdulos)
Sim
(Alguns
Mdulos)
Sim
(Alguns
Mdulos)
Portas seriais Sim(2) Sim(2) Sim (2) Sim(2)
Porta USB Sim No No No
Porta Ethernet Sim No No No
Processamento 50 Mhz 16 Mhz 4KHz 500KHz
Sada PWM Sim No No No
Protocolo
MODBUS
Sim Sim Sim Sim
Outros
Protocolos
Sim No No No
Memria
Externa
Sim No Sim No
Tabela 6.2: Comparao das tecnologias de automao de bombas
6.4.1 Controlador CAC
O Controlador de Bomba de Haste (CBH) CAC Modelo 2000 projetado
para operao com uma unidade de bombeio cavalo-de-pau. Dentre os
benefcios do CBH 2000, pode-se citar menor consumo de energia, aumento
na produo do poo, menor custo de manuteno e melhor uso de mo-de-
obra.
O CBH 2000 projetado para instalao em uma "rea segura", com os
dispositivos das pontas instalados em lugares perigosos de Classe I, Grupo C e
D. Barreiras de segurana podem ser montadas no CBH para isolar
dispositivos de campo para no comprometer a segurana. Sob condies
normais no campo, o CBH 2000 cercado por uma caixa resistente ao tempo
113

que protege a unidade, e ao mesmo tempo permite acesso fcil ao
equipamento.
6.4.2 Controlador ZAP
A famlia de controladores lgicos programveis ZAP900 foi
desenvolvida para atender aplicaes de pequeno porte (aproximadamente 40
pontos de I/O), porem, com recursos de software encontrados apenas em
CLP's de grande porte e custo muito superior. Possuindo ou no interface
homem-mquina incorporada, a famlia ZAP900 fornecida em sua
configurao bsica com 2 canais de comunicao serial e 16 canais de I/O
digitais. Possui suporte para um mdulo de expanso adicional podendo atingir
at 33 pontos de I/O, incluindo entradas e sadas analgicas e digitais,
interfaces para encoder, contador rpido e sadas geradoras de frequencia, etc.
Sucessor do ZAP500, este novo CLP rene peformance e flexibilidade
tornando-o uma opo atrativa para o mercado de automao de mquinas,
predial, sistemas de aquisio e pequenos processos.
6.4.3 Controlador Lufkin
O controlador de bombas estudado da Lufkin Automation, SAM, combina
tecnologia do Delta-X e Nabla. SAM pode controlar diversos tipos de
automao de bombas de petrleo. Este controlador uma tecnologia
importante e patenteada, que calcula a carta dinamomtrica para todos os
tempos desejveis da unidade de bombeio, utilizando complexas computaes
matemticas encontradas no software de monitoramento. A sua memria flash
disponibiliza rpidas atualizaes sem a necessidade de mudana de
componentes. Um barramento de expanso adicional permite a unidade
aumentar os seus requisitos adicionais a partir de portas de comunicao de
entrada e sada.
SAM seguramente mais do que um simples controlador de bombas de
petrleo. Ele possui um sistema de monitoramento com algoritmos patenteados
para assegurar o controle, anlise e um bom gerenciamento de seu sistema de
bombeio.
114

6.4.4 Sercref
O sistema embarcado Sercref aliado ao torqumetro dinmico telemtrico
desenvolvido surgiu para suprir as carncias existentes nas atuais tecnologias
de determinao de torque. Atravs desse sistema o erro na obteno dos
valores de monitoramento reduzido drasticamente. Alm disso, a utilizao
de uma arquitetura embarcada e reconfigurvel permite uma expanso rpida
de funcionalidades do sistema.
Diversas tecnologias so utilizadas no sistema, para que seja possvel
implementar as funes desejadas alm de deixar outras possibilidades de
utilizao j implementadas, facilitando o desenvolvimento de novas
aplicaes. O Sercref tambm possibilita a utilizao de uma rede Ethernet
para monitoramente e controle de dados, aumentando ainda mais a rea de
aplicao.
O kit de desenvolvimento utilizado pode aceitar uma freqncia ainda
maior do que a citada na Tabela de comparao atravs da utilizao de um
clock externo.
6.4.5 Comparao
Na tabela de comparao mostra-se que somente o sercref possui
tecnologia wireless na aquisio de dados da unidade de bombeio e permite
uma reconfigurao completa do sistema, uma vez que as outras tecnologias
somente permitem a expanso de algumas funcionalidades pr-existentes.
Devido a essa reconfigurabilidade o Sercref permite a utilizao de diversos
mdulos que podem ser incrementados ao sistema.
Embora todos os sistemas possuam duas portas seriais o sistema
embarcado desenvolvido permite a customizao de novas portas, se
necessrio. As portas ethernet e USB foram incrementadas para melhoria do
sistema, permitindo assim a integrao direta de dispositivos USB e facilitando
a comunicao do sistema com a rede ModBus TCP, uma vez que nos atuais
sistemas essa comunicao realizada por outro mdulo externo ao sistema.
115

A freqncia de processamento existente no kit utilizado de 50MHz,
embora esse valor possa ser aumentado atravs da utilizao de um clock
externo. A sada PWM existente permite uma fcil converso dos dados para
sinais analgicos que podem ser requeridos em testes e at mesmo no
desenvolvimento de novas funcionalidades.
Alm de todas as funcionalidades mencionadas, o Sercref inclui a
possibilidade de utilizao de diversos protocolos de comunicao e no
somente do protocolo ModBus como as outras tecnologias. A presena de
memria externa indica se o sistema permite a utilizao de outro tipo memria
alm da memria RAM para armazenamento de dados, como por exemplo uma
memria flash.

116

CAPITULO 7

Concluses e Trabalhos Futuros

Os prottipos e testes realizados mostram a viabilidade do projeto,
principalmente quando comparado com o atual sistema de determinao de
torque. importante ressaltar que pela caracterstica reconfigurvel do
sistema, o chip FPGA propicia grande mutabilidade. Assim, tanto as funes
aqui expostas podem ser modificadas para atender a outros requisitos, como
outras funcionalidades podem ser incorporadas ao sistema.
Existem trabalhos em andamento que utilizam o protocolo ZigBee na
automao de bombas de petrleo como em Xu e Gao (2008). Entretanto,
esses trabalhos no utilizam esse protocolo para aquisio de dados de torque,
e sim substituindo onde hoje utilizado o protocolo ModBus. Esta proposta
facilita a integrao desses novos projetos se os mesmos vierem a existir, pois
com as atuais arquiteturas seriam necessrias inmeras alteraes de
hardware existentes.
Esta proposta apresenta uma forma de pesquisa inovadora para reduo
de custos na extrao de petrleo, pode ser ampliado para outras formas de
determinao de torque que possam surgir.
A incorporao de processamento local, na bomba de petrleo, diminuiu
a carga de dados transferida para a central de controle e deu ao sistema
embarcado um maior poder de deciso local em situaes no desejadas de
funcionamento. Esperar que o usurio que monitora o sistema analise e tome
uma deciso pode ser crtico para a quebra ou danos na unidade.
117

Alm desta proposta desenvolvida e mostrada aqui, outras esto em
andamento aplicando as solues propostas como mostrado no apndice B.
Dentre os projetos esto:
Utilizao do Sercref para monitoramento de trens unidades eltricas.
Nesta proposta,pretende-se monitorar variveis que indicam o funcionamento
do trem tais como: peso, velocidade, acelerao, etc. Atualmente esses dados
somente so vistos pelo maquinista. Atravs do sistema proposto o centro de
controle e operaes possuir os dados necessrios para monitoramento e at
mesmo, em alguns casos, o controle dos trens unidades eltricas.
Aplicao do sistema reconfigurvel na integrao de tecnologias e
servios, aplicadas a lares, escritrios e pequenos prdios, com o propsito de
automatizar e obter um aumento de segurana, conforto, comunicao e
economia de energia. Atravs da utilizao do sistema reconfigurvel e de
outras tecnologias pode-se, utilizando essa proposta, incluir os controladores
de dispositivos no middleware de TVs digitais permitindo que as mesmas
sirvam de interface para controle da automao residencial atuando como a
esto base de uma rede de sensores sem fios.
Diversos artigos e trabalhos foram e continuam sendo publicados em
congressos e revistas nacionais e internacionais para divulgao dos mtodos
desenvolvidos e resultados encontrados atravs deste trabalho. Alm disso, o
torqumetro telemtrico ganhou o 4Prmio Petrobr s de Tecnologia, ficando
em primeiro lugar para o tema de tecnologia de perfurao e de produo.
No projeto de automao de trens artigos e trabalhos foram destaque,
como o 4lugar no prmio Alston de Tecnologia.

118

Referncias Bibliogrficas

ALTERA CORPORATION, Nios II Software Developers Handbook. San
Jose: Altera Corporation, 2007. 620 p. Disponvel em: <http://www.altera.com>.
Acesso em: 10 de mar. de 2008.

ALTERA. Nios II Processor Reference Handbook. 2007. Disponvel em:
<http://www.altera.com/literature/lit-nio2.jsp>. Acesso em: 13 de Nov. 2007.

AMERICAN PETROLEUM INSTITUTE (API). Specification for Pumping Unit.
API Specification. 11e. 17. ed., 1994.

ANJOS, E. G. et al. Embedded system architecture for oil pump using
reconfigurable computing. Brazilian Workshop on Real-Time and Embedded
Systems. In: SIMPSIO BRASILEIRO DE REDES DE COMPUTADORES,
2008. Rio de Janeiro, 2008.

ANJOS, E. G. et al. Sistema de testes para um torqumetro dinmico
telemtrico aplicado a eixos rotativos. In: CONGRESSO INFOBASIL, 2008.
Fortaleza, 2008.

ASHENDEN, P. J. The Vhdl Cookbook. Dept. Computer Science University of
Adelaide. South Australia, 1990.

ATHANAS, P.; SILVERMAN, H. Processor Reconfiguration through
Instruction-Set Metamorphosis: Architecture and Compiler. IEEE
Computer. v. 26, n. 3, Mar, 1993, p. 11-18.

BARR, M. Programming Embedded Systems in C and C++. OReilly, 1999.

BERKELEY Software Design. Disponvel em: <http://www.bsd.org/>. Acesso
em: 5 de set. 2004.

119

BRITO, R. M. Sistema Eletro-Eletrnico para Medio Direta de Torque em
Dispositivos Girantes Utilizando Extensmetros de Resistncia Eltrica.
1994. Tese de Doutorado (PPGEMM/UFRGS), Porto Alegre, 1994.

BROWN, S. et al. Field Programmable Gate Arrays, Kluwer Academic
Publisher, 1997.

BUENO, M. A. F.; BRASIL, C. R. S.; MARQUES, E.. Sistema operacional
embarcado eCos com suporte a SMP para o processador Nios II, 2007
Congresso SBC Anais, Rio de Janeiro RJ. P. 765.

BURNETT, M. M.; GOLDBERG, A.; Lewis T.G. Visual Object-Oriented
Programming: concepts and environments. Manning, Greenwich, 1995.

CASIMIRO, A.; KAISER, J.; VERISSIMO, P. An Architectural Framework and
a Middleware for Cooperating Smart Components. 2004. In: 1st
CONFERENCE ON COMPUTING FRONTIERS. Ischia, 2004. p. 2839.

CHEONG, Y.D. et al. Analysis and Development of the Angular Twist Type
Torque-meter. Composite Structures. v. 47, p. 457-462, 1999.

DAMORE R. VHDL: Descrio e sntese de circuitos digitais, LTC, 2005.

DEITEL, P. J. Java Como Programar. 6. ed. [S.l.]: Ed. Pearson, 2005.

DLP-USB 245M user manual: DLP-USB245M-G USB to FIFO parallel
interface module. [S.l.]: DLP Design, 2002.

EGAN , D. The Emergence of ZigBee in Building Automation and Industrial
Controls. IEE Computing & Control Engineering, v. 16, n. 2, p. 14-19,
Apr./May., 2005.

FERREIRA, Arurlio Buarque de Olanda. Dicionrio Aurlio eletrnico:
sculo XXI. Rio de Janeiro: Nova Fronteira e Lexicon Informtica, 2000, verso
3.0.

GANSSLE, J. The Art of Designing Embedded Systems, Academic, Press
Inc.,S. Diego, 1999.
120

GOSLING, J.; JOY, B.; STEELE,G. The Java Language Specification. Sun
Microsystems, 1996. Disponvel em:
<http://java.sun.com/doc/language_specification.html.>. Acesso em: 07 de jul.
2007.

GUPTA, R. K. Introduction to Embedded Systems. Disponvel em:
<http://www.ics.uci.edu/~rgupta/ics212/w2002/intro.pdf>. Acesso em: 07 de jul.
2007. UCLA, 2002.

HEATH, S.. Embedded Systems Design. 2. ed. Oxford: Newnes, 2003. 541 p.

HOLMAN, J. P. Experimental Methods for Engineers. 4. ed. Tokyo: Ed.
McGraw-Hill, 514 p. 1984.

IEEE (Aug, 2008). IEEE 801.15 WPAN Document Archive. Disponvel em:
<http://grouper.ieee.org/groups/802/15/> Acesso em: 10 de Out. 2007.

LABROSSE, J. J.. MicroC/OS-II: the real-time kernel. St. Louis: Focal Press,
2002. 605 p.

LIMA FILHO, A. C. Torqumetro dinmico telemtrico aplicado ao eixo
redutor de uma unidade de bombeio mecnico. 2007. Dissertao de
Mestrado, Engenharia Mecnica. Universidade Federal da Paraba, 2007.

MAXFILED Max C. The Design Warriors Guide to FPGAs. USA, 2004.
MENG, Z.; LIU, B. Research on the Laser Doppler Torque Sensor. Journal of
Physics: Conference Series. v. 48, p.202206. 2006.

MENG, Z.; LIU B. Research on the Laser Doppler Torque Sensor. Journal of
Physics: Conference Series. v. 48, 2006. p. 202206.

MODBUS.Org. ModBus Application Protocol Specification. v. 1, n.1, 2002.

MODICON, Inc.; ModBus Protocol Reference Guide, Industrial Automation
Systems. Massachusetts, 1996.

121

NOERGAARD, T. Embedded Systems Architecture: a comprehensive guide
for engineers and programmers. Oxford: Elsevier, 2005. 656 p.

NORTON, H. N. Handbook of transducers for electronic measuring
systems. Prentice-Hall, 1969.

OLUKOTUN, K. A. et al. A Software-Hardware Cosynthesis Approach to Digital
System Simulation. IEEE Micro. v. 14, p. 48-58. Nov. 1994.

PERON, R. V. Otimizao de cdigo fonte C para o processador
embarcado Nios II. 2007. Dissertao de Mestrado. Instituto de Cincias
Matemticas e de Computao - Universidade de So Paulo, 2007.

PINHEIRO, J. M. S. As Redes com ZigBee. Julho de 2004. Disponvel em:
<http://www.projetoderedes.com.br/artigos/artigo_ZigBee.php>. Acesso em: 30
de jan. 2006.

POSTGREE Reference Manual. The postgree global development group.
[S.l.] 2001.

PRADO, E. Novas Tecnologias, Novos Negcios, 2005. Disponvel em:
<http://www.wirelessbrasil.org/eduardo_prado/ep01.html>. Acesso em: 01 de
mar. 2008.

PREOBRAZHENSKY, V. P. Measurements and Instrumentation in the heat
engineering. URSS: Mirr Publishers, 1980.

RAHMAN, J.; PICHLIK, H. LabVIEW applications and solutions. Rio de
Janeiro: Prentice Hall, 1999.

SANTOS, S. T. Redes de Sensores sem fio em monitoramento e controle.
2007. Dissertao de Mestrado (Engenharia Eltrica). - COPPE/UFRJ, 2007.

SCHILDT, H. C. Completo e Total. So Paulo: Makron Books, 1996.

TAKAI, O. K. Introduo a Banco de Dados: DCC-IME-USP, 2005.

122

TENNENHOUSE, D. Proactive Computing. Communications of the ACM, 2000,
v. 43, n. 5, p. 4350.

THOMAS, J. E. Fundamentos da Engenharia de Petrleo. 2. ed. Rio de
Janeiro, Editora Intercincia (PETROBRAS). 2004.

ZAMMATTIO, S. Delivering a Consistent Software Development
Environment on a Changing Processor Platform, 2006. Disponvel em:
<http://www.fpgajournal.com/whitepapers_2006/q1_altera.htm>. Acesso em: 02
de Abr. 2008.

WUTKA, M. Java: tcnicas profissionais. Berkeley, 1997.

XU, J.; GAO, M. ZigBee Wireless Mesh Networks for Remote Monitoring
System of Pumping Unit; World Congress on Intelligent Control and
Automation. China, 2008.

ZAMMATTIO, S. Delivering a Consistent Software Development
Environment on a Changing Processor Platform, 2006. Disponvel em:
<http://www.fpgajournal.com/whitepapers_2006/q1_altera.htm>. Acesso em: 02
de Abr. 2008.

ZIGBEE ALLIANCE, ZIGBEE Document, Version 1.0. 14, 2004,

123

APNDICE A

Modelagem do Sistema Embarcado

Sistema pode ser definido como uma coletnea de estruturas e recursos
que so interagidos segundo uma lgica de tal forma a alcanar um ou mais
objetivos. Os estudos destes sistemas podem dar-se sob diferentes formas de
abordagem: (LAW, KELTON, 1991)
A primeira seria interferindo diretamente sob rotinas operacionais
promovendo implementaes e, ou, alteraes de procedimentos at
que sejam obtidas as condies ideais. Estas aes fazem requerer do
tomador de deciso a conduo de estudos preliminares e experincia,
para que as alteraes no prejudiquem a performance do sistema.
A segunda refere-se a utilizao de modelos que representem os
sistemas reais. Os modelos podem apresentar-se como prottipos ou
como modelos matemticos, os quais podem prestar-se a solues
analticas, como por exemplo um modelo de regresso, ou a simulao,
permitindo assim, reconstituir a rotina funcional de um dado sistema real.
Uma das tarefas mais rduas em simulao est em determinar se o
modelo proposto retrata com consistncia o sistema em estudo. Para o alcance
desta meta so recomendados a observncia de trs preceitos bsicos que
devem ser observados nas vrias fases do desenvolvimento de um modelo.
(JAGADEV, et. al., 1995) Esses preceitos so:
Verificao: conjunto de aes para certificar se a forma conceitual
adotada na formulao do modelo foi transcrita corretamente ao utilizar-
se das linguagens de programao ou de simulao;
124

Validao: Coletnea de aes utilizadas para analisar se um dado
modelo representa com fidedignidade o sistema em estudo. Podendo
este procedimento ser conduzido em conjunto com a verificao, fato
que imprimir maior confiabilidade ao modelo.
implementao de confiabilidade: conforme citaes em literaturas
especializadas, para a obteno de modelos validados e confiveis
deve-se ater aos seguintes preceitos: desenvolver modelos interativos
com os potenciais usurios, testar as consideraes empricas utilizadas
e determinar o quanto os dados gerados so representativos.
A.1 O uso da UML
O grande problema do desenvolvimento de novos sistemas nas fases de
anlise de requisitos, anlise de sistemas e design que no existe uma
notao padronizada e realmente eficaz que abranja qualquer tipo de aplicao
que se deseje. Cada simbologia existente possui seus prprios conceitos,
grficos e terminologias, resultando numa grande confuso, especialmente
para aqueles que querem utilizar a orientao a objetos no s sabendo para
que lado aponta a seta de um diagrama, mas sabendo criar modelos de
qualidade para ajud-los a construir e manter sistemas cada vez mais eficazes.
A UML uma tentativa de padronizar a modelagem orientada a objetos
de uma forma que qualquer sistema, seja qual for o tipo, possa ser modelado
corretamente, com consistncia, fcil comunicao com outras aplicaes,
simples de ser atualizado e compreensvel.
Existem vrias metodologias de modelagem orientada a objetos que at
o surgimento da UML causavam uma guerra entre a comunidade de
desenvolvedores. A UML acabou com esta guerra trazendo as melhores idias
de cada uma destas metodologias.
A Linguagem de Modelagem Unificada (UML) fornece uma linguagem
grfica para visualizao, especificao, construo e documentao dos
artefatos de um sistema de software. Este Sistema de Software, com outras
informaes, serve para visualizar o Sistema do Projeto. A UML oferece
125

ferramentas (mais de 90% das principais Empresas a utilizam de alguma
forma) que permitem aos desenvolvedores, aes e respostas profissionais,
como:
Uma forma de comunicao que funciona igualmente bem na anlise e
no projeto;
Uma apresentao visual que funciona igualmente bem para usurios,
projetistas, programadores e engenheiros (membros tcnicos e no
tcnicos);
Um padro formal, porm flexvel, para garantir a coerncia e clareza;
Uma Linguagem Extensvel que pode ser ajustada a qualquer setor ou
tipo de aplicao;
A.2 Diagramao
Devido s razes citadas e a muitas outras que tornam a UML to
utilizada e difundida, adotamos suas regras para modelagem do sistema. Os
diagramas gerados servem como forma de nortear as pesquisas e
desenvolvimentos. Vrios diagramas foram desenvolvidos para que fosse
possvel uma boa interpretao da camada de hardware, aplicao e software.
Diagrama de Casos de Uso: usado para modelar o modo como
as pessoas esperam usar um sistema. O diagrama descreve quem
sero os usurios relevantes, os servios que eles exigem do sistema e
os servios que eles precisam oferecer ao sistema. Ele pode ser
aplicado a muitos tipos de desenvolvimento, incluindo sistemas manuais,
mais usado mais comumente para sistemas e subsistemas.
Diagrama de Seqncia: Este diagrama fornece uma viso orientada
para o tempo das interaes, mais especificamente, de mensagens
passadas entre objetos, para realizar um objetivo comportamental do
sistema.
126

Diagrama de Atividades: Representa os fluxos conduzidos por
processamentos. essencialmente um grfico de fluxo, mostrando o
fluxo de controle de uma atividade para outra. Comumente isso envolve
a modelagem das etapas seqenciais em um processo computacional.
Diagrama de Componentes: Mostra a organizao entre arquivos de
cdigo fonte, bibliotecas, tabelas de banco de dados, etc. A relao mais
usada a dependncia, mostrando como um arquivo de cdigo fonte
depende de um outro que ele inclui, e como, por exemplo, um
executvel depende de uma biblioteca. Um componente uma parte
fsica do sistema. Muitas vezes um componente mostra um arquivo
especfico do sistema.
Diagrama de distribuio ou implantao: Modela o hardware do
ambiente da implementao. Cada n em um diagrama de distribuio
normalmente representa um tipo de hardware, como uma unidade de
disco, um PC cliente, um servidor ou um dispositivo de aquisio de
dados.
A.2.1 Casos de Uso
O caso de uso (use case) um elemento grfico exclusivo usado para
modelar o modo como as pessoas esperam usar o sistema. (Figura A.1)
Descrio: O diagrama mostra a interao do usurio e do administrador com
o sistema.
Caso de Uso 1 Adquirir Dados: O usurio escolhe a opo de adquirir dados
no sistema e o mesmo inicia a sua aquisio e armazenamento.
Caso de Uso 2 Visualizar Dados: O usurio escolhe a opo de visualizar
dados, configura os parmetros necessrios e ento pode analisar grficos
gerados a partir dos dados armazenados.
Caso de Uso 3 Atualiza Firmware: O administrador pode atualizar o firmware
tanto da FPGA quanto do mdulo RF existente no sistema.
Caso de Uso 4 Configurar Parmetros: O administrador pode configurar
parmetros para a forma de aquisio escolhida
127

Figura A.1: Diagrama de casos de uso
A.2.2 Diagramas de Seqncia
Diagrama de seqncia um tipo de diagrama usado para representar a
seqncia de processos (mais especificamente, de mensagens trocadas entre
objetos) em um programa de computador.
Descrio (Aquisio de Dados por RF): O FPGA recebe dados do mdulo
RF provenientes das medidas adquiridas atravs do torqumetro dinmico
telemtrico. Essas medidas sero armazenadas e processadas para posterior
envio no formato MODBUS.
128

Figura A.2: Diagrama de sequncia (Aquisio RF)
Descrio (Aquisio de Dados por CAD): O FPGA recebe dados do
conversor analgico-digital provenientes das medidas. Semelhante ao anterior,
mudando a forma de aquisio.

Figura A.3: Diagrama de sequncia (Aquisio CAD)
Descrio (Aquisio de Dados por CAD): O FPGA trata os dados e os
disponibiliza no formato MODBUS para o sistema de envio RF central. Essa
disponibilizao pode ocorrer de trs formas: utilizando um conversor digital-
analgico para entrada de 4 a 20mA existente na CLP, utilizando a interface
serial existente na CLP ou utilizando a interface Ethernet existente no mdulo
de rdio freqncia de alta potncia.
129

Figura A.4: Diagrama de sequncia (Envio dos Dados)
A.2.3 Diagrama de Atividades
Este diagrama descreve a seqncia de atividades realizadas pelo
sistema desde a ao do usurio no estado inicial da execuo, at a exibio
no estado final, dos resultados obtidos pelo RF ou pelo Conversor A/D,
processados e enviados no protocolo MODBUS.
130

Figura A.5: Diagrama de atividades

A.2.4 Diagrama de Componentes
Neste diagrama apresentamos a organizao dos softwares e
componentes de software que compem o sistema.
131

Figura A.6: Diagrama de componentes

132

A.2.5 Diagrama de Distribuio
Este diagrama descreve a distribuio dos componentes do sistema no
ambiente de sua aplicao. possvel visualizar o hardwares e equipamentos
necessrios instalao do sistema.

Figura A.7: Diagrama de distribuio

133

APNDICE B

Aplicabilidade do Sistema Embarcado
Reconfigurvel Proposto

Diversas caractersticas do sistema reconfigurvel embarcado,
desenvolvido para aplicaes em bombas de petrleo, acarretam em uma
grande aplicabilidade do sistema. Dentre as diversas aplicabilidades do sistema
podemos citar a automao de residncias e de trens que atualmente se
encontram em estudo no LASID (UFPB). A seguir ser descrito um pouco do
estudo de caso da aplicao dessa tecnologia. Estudos ainda esto sendo
realizados para desenvolvimento de dissertaes de mestrado.
B.1 Automao Residencial
Domtica a integrao de tecnologias e servios, aplicadas a lares,
escritrios e pequenos prdios, com o propsito de automatizar e obter um
aumento de segurana, conforto, comunicao e economia de energia. Por
automao entende-se a capacidade de se executar comandos, obter medidas,
regular parmetros e controlar funes de uma casa automaticamente.
A palavra domtica (domotique) surgiu na Frana, onde houveram as
primeiras experincias relacionadas a domtica. Domtica a contrao da
palavra domus do Latim (equivalente a lar ou casa) com a palavra telemtica.
Outro sinnimo para domtica casa inteligente (smart house), porm neste
trabalho usaremos o termo domtica. A domtica pode substituir o homem em
diversas atividades rotineiras de forma a propiciar uma otimizao nas
condies de vida em uma casa. O prprio sistema zela pela satisfao dos
moradores, sem que seja necessrio a contnua interveno dos mesmos.
134

O grau de controle alcanado pode ser varivel, sendo uma funo de
custo, desejo pessoal dos moradores, estrutura do prdio e tecnologia usada.
Casas que podem ter, por exemplo, ajuste automtico de temperatura,
escalonamento automtico de tarefas rotineiras como ligar a cafeteira,
acionamento automtico de servios de segurana e comunicao eficiente
com o mundo externo tm vrios benefcios.
Outro termo importante a se definir o conceito de teleao (teleaction).
Teleao a capacidade de se controlar algum dispositivo remotamente.
Unindo os dois conceitos acima descritos (domtica e teleao) surgiu a idia
de interligar a rede interna de uma casa (domtica) com a rede externa casa
(Internet ou outro meio) de forma que os moradores da casa possam controlar,
monitorar e administrar seu lar a distncia. Alem disso, a crescente utilizao
de TVs Digitais no mundo vem possibilitando a concentrao de
processamento em um dispositivo comum e muito utilizado, a televiso.
B.1.1 Sercref na Automao de Residncias
A idia de aplicao do SERCREF em automao residencial surgiu
com a possibilidade de inserir tal sistema junto ao firmware das televises
digitais ou dos aparelhos set-top-box que podem ser utilizados para transformar
TVs analgicas em digitais.
A necessidade de gerenciar processos automatizados executados por
dispositivos domsticos consiste em um desafio para os sistemas domticos,
pois a centralizao do gerenciamento se torna complexa medida que a
quantidade e a diversidade de dispositivos aumentam.
Este trabalho visa desenvolver uma aplicao para TVs digitais e uma
possibilidade de expanso do projeto Ginga@Home que tem como objetivo a
utilizao da Televiso Digital (DTV) como centro de controle e monitoramento
remoto de dispositivos residenciais. O projeto consiste em ampliar a atuao do
OpenGinga, uma implementao de cdigo aberto do Ginga, o middleware do
Sistema Brasileiro de TV Digital, onde as aplicaes executadas so
classificadas em duas categorias dependendo se o contedo inicial da
aplicao declarativo ou procedural. O ambiente de execuo que processa
135

aplicaes Nested Context Language (NCL) chamado de Ginga-NCL e o
ambiente que controla a execuo de aplicaes baseadas na Java TV
chamado de Ginga-J.
Para que a administrao dos dispositivos seja possvel, foi
desenvolvido um mdulo de tratamento de dados empacotados no protocolo
ZigBee, baseado no padro IEEE 802.15.4, que tem como funo o controle de
dispositivos remotos atravs de mdulos de radiofreqncia (RF), que ficam
acoplados tanto no set-top box (STB), chamados de unidades base, como nos
dispositivos que so monitorados (condicionadores de ar, cmeras de
segurana, alarmes, bomba de irrigao, entre outros), chamados de unidades
remotas.
B.1.2 Funcionamento
O funcionamento do sistema bastante simples. Os dispositivos
residenciais monitorados trocam informaes com os mdulos ZigBee atravs
de canais analgicos e digitais. Os mdulos ZigBee remotos enviam os dados
para o mdulo base, coordenador, que disponibiliza-os para o sistema
embarcado.
O software do sistema embarcado trata os dados empacotados no
protocolo ZigBee e troca informaes com o sistema de monitoramento na
web, conectado atravs de sockets.
B.1.3 Testes
O firmware desenvolvido para controle de bombas de petrleo foi
modificado para receber pacotes em ModBus referentes a controle da
automao residencial. Dentro do sistema embarcado foram simulados alguns
equipamentos como ar condicionado, alarme, detector de incndio, etc. Atravs
da simulao foi possvel verificar a possibilidade de controle atravs do
sistema embarcado e da rede ethernet.
Os comandos eram enviados atravs de um sistema desenvolvido na
linguagem Java, enviados pela rede e recebidos pelo sistema embarcado. O
sistema embarcado verificava o status do dispositivo para determinar a
136

necessidade de realizao de determinada ao ou no. Se for possvel
efetuar, o sistema retorna um pacote indicando o processo realizado, se no
indica que no ocorreu e o motivo.
Para tratamento de dados foi utilizado o protocolo ModBus TCP, uma
vez que o mesmo j estava sendo utilizado no projeto base de automao de
bombas de petrleo. Entretanto qualquer outro protocolo pode ser adotado e
customizado devido a capacidade de reconfigurao do sistema embarcado
proporcionado pela FPGA.
A Tabela B.1 a seguir contm alguns dos pacotes utilizados para
tratamento de dados do projeto de testes na automao residencial. descrito
cada pacote utilizado para cada funcionalidade implementada. Para cada
funo, diversos pacotes foram utilizados para mapear as caractersticas do
dispositivo. Os pacotes esto divididos em pacotes de entrada de dados e de
sada de dados. Os pacotes de entrada so enviados pelo mestre da rede que
solicita uma funo ao escravo. O escravo retorna a funo atravs dos
pacotes de sada de dados.
Tabela de Pacotes ModBus da Automao Residencial
Lmpadas - A3

Entrada de dados

A31000: Ligar a lmpada
A32000: Desligar a lmpada
A3000F: Solicitao de status

Sada de dados

A31001: J estava acesa
A31002: Acesa com sucesso
A32001: J estava apagada
A32002: Apagada com sucesso
A30000: status: apagada
A30001: status: acesa

Ar Condicionado A4

Entrada de dados

A41000: Ligar o ar condicionado
A42000: Desligar o ar condicionado
A430XX: Modificar temperatura

Sada de dados

A41001: J estava ligado
A41002: Ligado com sucesso
A42001: J estava desligado
137

A44000: Solicitao de status

A42002: Desligado com sucesso
A30000: Temperatura modificada
A440XX: Mostra temperatura atual

Portas A5

Entrada de dados

A51000: Abrir porta
A52000: Fechar porta
A53000: Travar porta
A54000: Destravar porta

Sada de dados

A51001: J est aberta
A51002: Aberta com sucesso
A51003: Tentou abrir porta travada
A52001: J est fechada
A52002: Fechada com sucesso
A53001: J est travada
A53002: Travada com sucesso
A54001: J est destravada
A54002: Destravada com sucesso
A50000: Status: aberta
A50001: Status: fechada
A50002: Status: travada

Detector de Incndio A6

Entrada de dados

A61000: Ativar detector
A62000: Desativar detector

Sada de dados

A61001: J est ativado
A61002: Ativado com sucesso
A62001: J est desativado
A62002:Desativado com sucesso
A63001: Mensagem de Alerta!
A60000: Status: desligado
A60001: Status: ligado

Alarme A7

Entrada de dados

A71000: Ativar alarme
A72000: Desativar alarme

Sada de dados

A71001: J est ativado
A71002: Ativado com sucesso
A72001: J est desativado
A72002:Desativado com sucesso
A73001: Mensagem de Alerta!
A60000: Status: desligado
A60001: Status: ligado

138

Demais Pacotes
Pacote de Confirmao: CC0000
Pacote Desconhecido: EE0000
Finaliza Conexo: FF0000
Tabela B.1: Pacotes ModBus utilizados na automao residencial.

A Figura B.1 mostra como o sistema Sercref foi adaptado para os testes
realizados e como se d a interao com cada funcionalidade do sistema. Na
Figura B.2 mostrado como o status da casa verificado e na Figura B.3 o
prottipo em desenvolvimento.

Figura B.1: Sercref para automao residencial

139

Figura B.2: Status dos dispositivos monitorados da casa.

Figura B.3: Estrutura onde o prottipo est sendo instalado.

140

B.2 Automao de Trens
A transmisso de dados remota um recurso fundamental para
empresas que necessitam de informaes em tempo real, como fator
estratgico para tomadas de decises. No segmento de transporte
metroferrovirio, a necessidade de informaes precisas se torna ainda mais
crtica, pois baseada nestas que so tomadas grandes decises de trfego
de metrs no sistema de transporte.
B.2.1 Aplicao do Secref na automao de Trens
Atualmente, encontra-se em desenvolvimento um sistema telemtrico
para monitoramento de malhas ferrovirias utilizando redes de sensores sem
fio com tecnologia ZigBee e controle em sistemas embarcados. Este sistema,
denominado Railbee, alvo de uma dissertao de mestrado em informtica
e de uma tese de doutorado em engenharia mecnica e conta com a
participao de estudantes e pesquisadores do LASID (UFPB) e LES (UFPB).
O RailBee tem como principal objetivo a obteno, em tempo real, de
informaes importantes relacionadas as medidas de grandezas como
velocidade, presso nas bolsas de ar, corrente de armadura, dentre outras.
Essas medidas podem ser utilizadas para calcular dados como posio e
numero mdio de passageiros em cada trem.
A disponibilidade de informaes para a gesto metro-ferroviria trar
uma srie de benefcios para os controladores de trfego do Centro de
Controle de Operaes (CCO) e para os tcnicos responsveis pela
manuteno, como por exemplo: Dinamismo, otimizao e flexibilidade nos
processos de planejamento e controle de trfego dos TUE e Dados, bem como
alarmes sero mostrados em tempo real nos consoles do CCO.
A constante avaliao do desempenho dos TUE permitir a realizao
de diagnsticos mais precisos e a tomada de aes preventivas de operao
e manuteno, como tambm s decises preditivas com base em
prognsticos auferidos das medidas em tempo real, de forma a possibilitar
uma estratgia de interveno, evitando assim uma degradao parcial ou
total dos servios de transporte prestados populao.
141

B.2.2 Funcionamento
O sistema proposto dividido em trs subsistemas: Sistema de
Aquisio de Dados, Sistema de Tratamento de Dados e Sistema de
Superviso Geral.
O sistema de aquisio formado pelas redes de sensores sem fio que
so responsveis pela captao das medidas remotas e por seu envio at o
sistema de tratamento. Essa rede constituda de trs tipos de mdulos RF:
n coordenador, ns roteadores e ns finais, onde cada mdulo possui uma
funo especifica dentro da rede. Os ns finais, estaro localizados dentro das
cabines dos trens e tero suas entradas analgicas ligadas as sensores de
velocidade, presso, etc. Esses ns transmitiro os dados obtidos para os ns
roteadores instalados ao longo das vias frreas que por sua vez repassam os
dados recebidos para outros ns roteadores ou para o n coordenador da rede
caso este esteja ao alcance. O n coordenador responsvel por receber os
dados obtidos pelos ns finais e envi-los para o sistema de tratamento atravs
de uma porta serial UART ou USB. Para aumentar a confiabilidade do sistema,
haver vrios ns coordenadores. Cada n coordenador ficar situado em uma
das estaes de passageiros e controlar a subrede de sensores instalada nas
proximidades desta estao.
O sistema de tratamento um sistema embarcado em uma FPGA que
fica conectada diretamente ao n coordenador. Este sistema recebe os dados
do n coordenador, decodifica o pacote ZigBee, extrai os dados de tenso
medidos nos sensores, realiza os clculos de velocidade, presso, posio,
etc, e os envia para o sistema de superviso atravs da rede ethernet.
O sistema de superviso geral ficar instalado na Central de Controle de
Operaes. Este sistema receber as medidas j calculadas no sistema de
tratamento de todas as estaes de passageiros e as exibir em tempo real na
forma de grficos ou tabelas, como tambm as armazenar em um banco de
dados ou em arquivos para analise posterior. A visualizao em tempo real
142

agilizar o trabalho dos controladores de trfego permitindo que estes tomem
decises de forma mais rpida e eficaz.
As Figuras B.4 e B.5 abaixo demonstram a interface de um programa de
testes que est sendo desenvolvido em LabVIEW para o sistema de
superviso.

Figura B.4: Interface mostrando as medidas realizadas em cada trem
B.2.3 Testes
Para validar a telemetria via ZigBee alguns testes foram realizados em
uma cabine de trem na estao central do metr do Recife. Utilizou-se um
oscilgrafo, que o atual instrumento usado nos trens para medio de sinais,
e trs mdulos ZigBee (roteador, coordenador e n final). Dois canais
analgicos do mdulo ZigBee e de oscilgrafo foram utilizados para registro
dos parmetros de velocidade e presso mdia nas bolsas de ar (indicando o
peso do trem), respectivamente. Os dois equipamentos, ZigBee e oscilgrafo,
143

utilizaram os mesmos pontos de captao dos sinais concomitantemente para
garantir a comparao posterior dos dados.

Figura B.5: Interface para mostrar as medidas de um trem especifico.

Na comparao das curvas geradas a partir dos dados registrados nos
dois instrumentos, verificou-se uma semelhana na sua resposta dos
parmetros velocidade real e presso mdia das bolsas de ar. A Figura B.6
demonstra essa semelhana para a medida da tenso referente velocidade.
O fator de correlao das curvas foi 0,994 para velocidade e 0,992 para a
presso.
144

Figura B.6: Amostras
Tambm foram realizados alguns testes com os mdulos ZigBee para
obteno das medidas de velocidade e presso em toda a linha de Recife a
Jaboato. As Figuras B.7 e B.8 abaixo demonstram as medidas de velocidade
e presso nesse trecho. Atravs dos grficos possvel saber a velocidade
mxima e mnima e a posio do trem em determinado instante. possvel
ainda saber o tempo que o trem ficou parado em qualquer estao de
passageiros. A medida da variao da presso pode ser utilizada para calcular
a mdia de passageiros que entram e saem em cada estao atravs do peso
do trem.

Tempo (s)

Figura B.7: Grfico indicando a velocidade do trem.
V
e
l
o
c
i
d
a
d
e

0
10
20
30
40
50
60
70
80
90
0,0 200,0 400,0 600,0 800,0 1000,0 1200,0 1400,0
145

0
10
20
30
40
50
60
70
0,0 200,0 400,0 600,0 800,0 1000,0 1200,0 1400,0

Tempo (s)
Figura B.8: Grfico da presso exercida pelo trem
Atravs da analise destes grficos, os engenheiros e tcnicos podem
identificar possveis falhas e problemas ocorridos durante a operao de cada
TUE.
O sistema telemtrico aqui proposto apresenta uma relao
custo/beneficio bem mais favorvel que o atual sistema utilizado. Alm de
empregar tecnologia de custo muito mais baixo que o sistema atual, ele permite
a aquisio e envio de dados em tempo real com os TUE em movimento,
permitindo assim que os dados possam ser analisados de forma rpida e
prtica.

P
r
e
s
s
o

(
p
s
i
)

2009 Eu D Isley Anjos

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

2009 Eu D Isley Anjos

Transféré par

Droits d'auteur :

Formats disponibles

i

Universidade Federal da Paraba

Vous aimerez peut-être aussi