sistema embarcado reconfigurável para automação de ... · pdf file2....
TRANSCRIPT
i
Universidade Federal da Paraíba
Centro de Ciências Exatas e da Natureza
Programa de Pós-Graduação em Informática
Sistema Embarcado Reconfigurável para Automação
de Unidades de Bombeamento de Petróleo através de
Redes de Sensores sem Fios.
EUDISLEY GOMES DOS ANJOS
João Pessoa, Março de 2009
ii
Universidade Federal da Paraíba
Centro de Ciências Exatas e da Natureza
Programa de Pós-Graduação em Informática
Dissertação de Mestrado
Sistema Embarcado Reconfigurável para Automação
de Unidades de Bombeamento de Petróleo através de
Redes de Sensores sem Fios.
EUDISLEY GOMES DOS ANJOS
Orientadores:
José Antônio Gomes de Lima
Francisco Antônio Belo
João Pessoa, Março de 2009
iii
Universidade Federal da Paraíba
Centro de Ciências Exatas e da Natureza
Programa de Pós-Graduação em Informática
Sistema Embarcado Reconfigurável para Automação
de Unidades de Bombeamento de Petróleo através de
Redes de Sensores sem Fios.
EUDISLEY GOMES DOS ANJOS
Orientadores:
José Antônio Gomes de Lima
Francisco Antônio Belo
Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Informática, da Universidade Federal da Paraíba, como parte dos requisitos para a obtenção do título de Mestre em Informática.
Área de concentração : Ciência da Computação. Linha de pesquisa: Processamento de Sinais e Sistemas Gráficos.
João Pessoa, Março de 2009
iv
A597s Anjos, Eudisley Gomes dos. Sistema embarcado reconfigurável para automação de
unidades de bombeamento de petróleo através de redes de sensores sem fios / Eudisley Gomes dos Anjos.- João Pessoa, 2009.
144p. : il. Orientadores: José Antônio Gomes de Lima, Francisco
Antônio Belo Dissertação (Mestrado) – UFPB/CCEN
1. Informática. 2. Sistemas Embarcados. 3. Computação Reconfigurável. 4. FPGA. 5. Processador Nios II. 6. Protocolo ModBus. 7. Protocolo ZigBee. 8. Redes de Sensores sem Fios.
UFPB/BC CDU: 004(043)
v
EUDISLEY GOMES DOS ANJOS
Sistema Embarcado Reconfigurável para Automação
de Unidades de Bombeamento de Petróleo através de
Redes de Sensores sem Fios.
Orientadores:
Prof°. Dr. José Antônio Gomes de Lima Doutor pela Universidade Federal de Campina Grande
Campina Grande – Brasil
Prof°. Dr. Francisco Antônio Belo Doutor pela Universidade Estadual de Campinas
Campinas - Brasil
Banca Examinadora:
Prof°. Dr. Antonio Carlos Cavalcanti Doutor pelo Institut National Polytechnique de Grenoble
Grenoble – França
Prof°. Dr. Ivan Saraiva Silva Doutor pela Universite de Paris VI
Paris - França
Coordenadora do Mestrado:
Profª. Drª. Valéria Gonçalves Soares Doutora pela Universidade Federal de Pernambuco
Recife – Brasil
vi
“A esperança não murcha, ela não cansa,
também como ela não sucumbe à crença.
Vão-se sonhos nas asas da descrença,
voltam sonhos nas asas da esperança.”
Augusto Dos Anjos
vii
Dedicatória
Para minha família, especialmente minha mãe e irmãs pelo incentivo, amor,
apoio e opiniões que me fizeram traçar sempre os melhores e mais justos
caminhos à frente.
A Bruno Maia que sempre esteve ao meu lado durante todo o processo de
elaboração e desenvolvimento desse trabalho, atuando direta e ativamente
para conclusão do mesmo
A José de Andrade Martins pela força, apoio e conselhos que foram cedidos
aumentando o meu potencial e minha experiência de vida.
viii
Agradecimentos
Primeiramente, eu agradeço ao meu orientador e amigo Prof.° Dr. José Antônio
Gomes de Lima pela oportunidade oferecida, amizade conquistada e por suas
orientações, conselhos e ensinamentos, depositados desde o início do
mestrado e que foram essenciais para o desenvolvimento desse trabalho.
Agradeço também aos professores Francisco Antônio Belo, Antônio Carlos
Cavalcanti, Lucídio Cabral e Valéria 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
contribuíram muito para realização desse trabalho.
A todos os membros do LASID (Laboratório de Sistemas Digitais), LES
(Laboratório de Energia Solar) e amigos mais próximos, companheiros de
muitas atividades que me incentivaram e colaboraram para essa difícil jornada.
Ao CNPq e a PETROBRAS pelo apoio financeiro, e a todos os que de alguma
forma vibraram positivamente para a realização desse trabalho.
ix
RESUMO
A constante evolução dos sistemas embarcados tem requisitado
mudanças constantes em grandes e antigos métodos de automação. Essas
alterações não eram previstas na etapa de desenvolvimento desses sistemas
levando a necessidade de substituição de hardware e software e aumentando o
tempo de reconfiguração, custos e mão de obra. Este trabalho apresenta o
desenvolvimento de um sistema embarcado utilizando computação
reconfigurável e o processador Nios II para ser aplicado na otimização da
automação de Unidades de Bombeio de Petróleo. O atual método de
automação possui um alto fator de erro, podendo atingir até 20% na
determinação dos valores de torque no eixo de saída do redutor. Com a
utilização do sistema aqui apresentado, é possível obter valores referentes a
medidas reais de parâmetros que indicam o atual estado da Unidade de
Bombeio. A utilização da computação reconfigurável proporciona a modificação
da arquitetura em tempo real para melhor se adequar à aplicação que será
executada, permitindo uma eficiência muito maior do que normalmente é
encontrada em processadores de uso geral. Uma rede no padrão ZigBee e um
conversor analógico-digital receberão dados digitais do novo torquímetro
implementado, enviam esses dados ao sistema, que realiza todos os cálculos
necessários e empacota no padrão MODBUS, disponibilizando na rede de
automação dos campos de extração de petróleo. Com o sistema proposto o
erro gerado chega a menos de 5%, além de um monitoramento mais preciso e
maior facilidade de expansão.
Palavras Chave: Sistemas Embarcados, Computação Reconfigurável, 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 básico de um sistema embarcad o. ........................... 8
Figura 2.2 – Sistemas embarcados em um veículo. ... ................................... 9
Figura 2.3 – Data logger para temperatura do ar. .. ...................................... 10
Figura 2.4 – Nintendo Wii e sua grande interação co m o usuário ............. 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: Esboço de um FPGA ..................... .............................................. 14
Figura 2.10: Camadas do protocolo ZigBee .......... ....................................... 18
Figura 2.11: Modelo das redes ZigBee .............. ........................................... 19
Figura 2.12: Aplicações do padrão ZigBee .......... ........................................ 19
Figura 2.13: Modelo do ZigBee da MaxStream e seus 2 0 pinos ................. 21
Figura 2.14: Diagrama de fluxo do módulo ZigBee ... .................................. 23
Figura 2.15: Camadas das formas de implementação do MODBUS .......... 24
Figura 2.16: Modelo de um pacote MODBUS ........... .................................... 24
Figura 2.17: Kit de desenvolvimento Altera para o N ios II.......................... 26
Figura 2.18: Hardwares de referência para prototipa ção do Nios II .......... 28
Figura 3.1: Atual modelo de automação de bombas de petróleo .............. 46
Figura 3.2: Esboço do sistema de instrumentação por rádio freqüência . 48
Figura 3.3: Leitura de tensão e corrente no primári o do motor ................. 49
Figura 3.4: Medição da velocidade do redutor. ..... ...................................... 50
Figura 3.5: Medição da velocidade do motor. ....... ....................................... 50
xii
Figura 3.6: Bancada de testes para torque estático .................................... 52
Figura 3.7: Bancada de torque dinâmico com eixo par a frenagem ........... 52
Figura 3.8: Protótipo com manivela e contrapeso ... ................................... 52
Figura 3.9: Simulador de UBM proporcional a unidade real. ...................... 53
Figura 3.10: Unidade de bombeio da PETROBRAS utiliz ada 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: Módulo ZigBee utilizado para testes. . ..................................... 56
Figura 3.14: Abraçadeira 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: Módulo de aquisição .................. ............................................... 59
Figura 3.18: Módulo de tratamento de dados ........ ...................................... 59
Figura 3.19: Módulo de visualização ............... ............................................. 60
Figura 3.20: Sinais dos sensores de posição e exten sômetros. ................ 61
Figura 3.21: Gráfico torque x ângulo .............. .............................................. 61
Figura 3.22: Gráficos de corrente, e potência calcu lada. ........................... 62
Figura 3.23: Medidas de corrente (branco) e tensão (vermelho) ............... 63
Figura 3.24 – Gráficos das potências ativa, reativa e aparente. ................. 64
Figura 3.25: Curvas de torque pelos dois métodos. . .................................. 64
Figura 3.26: Torque observado no momento da quebra da haste polida .. 65
Figura 3.27: Curva interpolada do antigo método de automação .............. 66
Figura 3.28: Curva de valores mais precisos obtida com extensômetros 66
Figura 3.29: Curva com valores referente à potência no motor ................. 67
Figura 4.1: Modelo arquitetural de um sistema embar cado ....................... 70
xiii
Figura 4.2: Camada de hardware .................... .............................................. 71
Figura 4.3: Camada de sistemas de software ........ ...................................... 72
Figura 4.4: Camada de aplicação ................... ............................................... 74
Figura 4.5: Diagrama de blocos de comunicação entre PIO e USB ........... 78
Figura 4.6: Comunicação entre a interface USB e o c ontrolador 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 transmissão e recepção 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 transmissão ZigBee. ...... ..................................... 91
Figura 4.13: Modelo P-CAD da placa de recepção ZigB ee ......................... 92
Figura 4.14: PCB contendo modelo de placa de recepç ão ZigBee ............ 92
Figura 4.15: Esquema elétrico da placa de recepção ZigBee. .................... 93
Figura 4.16: Protótipos com o circuito de recepção e o módulo ZigBee .. 93
Figura 5.1: Fluxo de funcionamento do SoPC Builder ................................ 96
Figura 5.2: Arquitetura no SOPC Builder ........... .......................................... 96
Figura 5.3: Visão das funcionalidades do Nios II ID E ................................. 99
Figura 5.4: Abstração de hardware do sistema de bib liotecas 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 a quisição constante .. 106
xiv
Figura 6.5: Funcionamento completo do sistema. .... ................................ 107
Figura 6.6: Senóide gerada através de um gerador de ondas. ................. 108
Figura 6.7: Função dente de serra ................. ............................................. 108
Figura 6.8: Onda quadrada ......................... ................................................. 109
Figura 6.9: modulo ZigBee o gerador de ondas utiliz ado ......................... 109
Figura 6.10: Imagem com o protótipo instalado. .... ................................... 110
Figura A.1: Diagrama de casos de uso .............. ........................................ 127
Figura A.2: Diagrama de sequência (Aquisição RF) .. ............................... 128
Figura A.3: Diagrama de sequência (Aquisição CAD) . ............................. 128
Figura A.4: Diagrama de sequência (Envio dos Dados) ........................... 129
Figura A.5: Diagrama de atividades ................ ............................................ 130
Figura A.6: Diagrama de componentes ............... ....................................... 131
Figura A.7: Diagrama de distribuição .............. ........................................... 132
Figura B.1: Sercref para automação residencial .... ................................... 138
Figura B.2: Status dos dispositivos monitorados da casa. ...................... 139
Figura B.3: Estrutura onde o protótipo está sendo i nstalado. ................. 139
Figura B.4: Interface mostrando as medidas realiza das 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: Gráfico indicando a velocidade do trem. ................................ 144
Figura B.8: Gráfico da pressão exercida pelo trem . .................................. 145
xv
Lista de Tabelas
Tabela 2.1: Descrição dos 20 pinos presentes no Zig Bee 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 da s UB. ..................... 89
Tabela 6.1: Características da arquitetura desenvol vida para o sistema.111
Tabela 6.2: Comparação das tecnologias de automação de bombas ..... 112
Tabela B.1: Pacotes ModBus utilizados na automação residencial. ....... 138
xvi
Sumário
Sumário ........................................... ............................................................... xvi
CAPÍTULO 1 ........................................ .............................................................. 1
Introdução ........................................ ................................................................. 1
1.1 Motivação ..................................... ..................................................................... 1
1.2 Objetivos ..................................... ...................................................................... 2
1.3 Organização ................................... ................................................................... 4
CAPITULO 2 ........................................ .............................................................. 5
Fundamentação Teórica ............................. ..................................................... 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 Mudanças de Projetos de Sistemas Embarcados ........................................ 8
2.1.4 Exemplos de aplicações ............................................................................... 9
2.2 Computação Reconfigurável ..................... ..................................................... 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 programação ..................... .................................................... 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
Capítulo 3 ........................................ ................................................................ 42
Medição de Torque ................................. ........................................................ 42
3.2 Sistemas de Automação de Unidades de Bombeio de Petróleo ................. 44
3.2.1 Atual Modelo de Automação ...................................................................... 45
3.3 Torquímetro Dinâmico Telemétrico .............. ................................................. 47
3.4 Torque Através dos Parâmetros Elétricos do Moto r e Perda da Correia .... 49
3.5 Teste e Validação ............................. ............................................................... 51
3.5.1 Protótipos para obtenção de torque ........................................................... 51
3.5.2 Sistema de Testes e Validação .................................................................. 54
3.5.3 Resultados Obtidos .................................................................................... 60
Capitulo 4 ........................................ ................................................................ 68
Sistema Embarcado para Automação de Bombas de Petró leo ................. 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 Aplicação 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 Núcleo 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 Implementação do Empacotador MODBUS ........... ....................................... 84
4.4 Funcionamento do Sistema ...................... ..................................................... 89
4.5 Circuito ZigBee de Recepção ................... ...................................................... 90
CAPÍTULO 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 Petróle o ............................... 106
6.3 Configuração do Hardware Utilizado ............ ............................................... 110
6.4 Comparação do Sistema Proposto com outros Siste mas ......................... 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 Comparação................................................................................................113
xix
CAPITULO 7 ........................................ .......................................................... 116
Conclusões e Trabalhos Futuros .................... ............................................ 116
Referências Bibliográficas ........................ .................................................. 118
APÊNDICE A ........................................ ......................................................... 123
Modelagem do Sistema Embarcado .................... ....................................... 123
A.1 – O uso da UML ................................ ............................................................ 124
A.2 Diagramação ................................... .............................................................. 125
A.2.1 Casos de Uso .......................................................................................... 126
A.2.2 Diagramas de Seqüência ......................................................................... 127
A.2.3 Diagrama de Atividades ........................................................................... 129
A.2.4 Diagrama de Componentes ..................................................................... 130
A.2.5 Diagrama de Distribuição ......................................................................... 132
APÊNDICE B ........................................ ......................................................... 133
Aplicabilidade do Sistema Embarcado Reconfigurável Proposto ........... 133
B.1 Automação Residencial ......................... ...................................................... 133
B.1.1 Sercref na Automação de Residências .................................................... 134
B.1.2 Funcionamento ........................................................................................ 135
B.1.3 Testes ...................................................................................................... 135
B.2 Automação de Trens ............................ ........................................................ 140
B.2.1 Aplicação do Secref na automação de Trens ........................................... 140
B.2.2 Funcionamento ........................................................................................ 141
B.2.3 Testes ...................................................................................................... 142
xx
1
CAPÍTULO 1
Introdução
1.1 Motivação
A evolução das metodologias de projeto de hardware, apoiadas em
poderosas ferramentas de software que aceleram o ciclo de desenvolvimento,
e especialmente o surgimento de dispositivos reconfiguráveis como os FPGA
(Field-Programmable Gate Arrays) abriu um novo horizonte entre os extremos
da computação de finalidade geral e o hardware dedicado. Os FPGAs
combinam a flexibilidade de dispositivos programáveis, como PLD e
microprocessadores de finalidade geral, com o desempenho do hardware de
finalidade específica, como o ASIC. (BROWN, 1997).
Ao mesmo tempo, os sistemas de automação vêm sofrendo um
processo de evolução na sua configuração, principalmente através da
utilização de redes de sensores sem fios para monitoramento e controle de
dispositivos. A princípio o alto custo para implementação e o alto consumo de
energia desses sensores inviabilizava as mudanças no sistema. Hoje, a grande
concorrência e a busca por qualidade aliada ao baixo consumo levaram as
empresas à necessidade de substituição de seus grandes sistemas de
controle.
Até agora os avanços realizados nos processos de determinação de
torque não foram muito relevantes. Por isso, diversas empresas de extração de
petróleo continuaram com as suas antigas formas de automação. Entretanto
um novo torquímetro, proposto por Lima Filho, (2007) e Anjos (2008) permite
uma alta precisão na determinação dos valores de torque, pois, agora, o
2
mesmo não será mais calculado, e sim medido diretamente nos equipamentos
das bombas de petróleo. Através dessa medição os valores se tornam bastante
precisos levando ao aumento da credibilidade no processo. Este torquímetro foi
patenteado e divulgado em congressos, obtendo prêmios pela inovação
tecnológica aplicada.
As atuais arquiteturas de automação não permitem uma expansão
satisfatória para a evolução dos sistemas de automação. Devido a isso, muitas
empresas continuam a utilizar os métodos antigos de automação, o que faz
necessário um sistema que além de permitir a possibilidade de substituição do
sistema sem modificação de hardware, possa ser integrado facilmente às
arquiteturas já existentes sem muitas mudanças. Uma implementação em
hardware levaria aos mesmos problemas enfrentados até agora,
impossibilitando expansão futura. Por isso, uma arquitetura reconfigurável se
coloca como técnica essencial para uma evolução dessa tecnologia.
O desenvolvimento de um torquímetro dinâmico telemétrico no LES
(Laboratório de Energia Solar da UFPB) aumentou a exatidão na determinação
do torque nas unidades de bombeio. Entretanto a atual tecnologia utilizada nos
controladores lógicos não aceitava a arquitetura do torquímetro e também não
permitia uma evolução para se adequar ao mesmo. Essa foi uma das principais
motivações para o desenvolvimento do sistema embarcado reconfigurável.
1.2 Objetivos
Nosso objetivo geral consistiu no desenvolvimento de um sistema
embarcado reconfigurável que permite a expansão e integração dos métodos
de automação de bombas de petróleo já existentes, além de permitir a criação
de novos sistemas que já possuam uma arquitetura reconfigurável. Esse
sistema possibilita a integração do Torquímetro Dinâmico Telemétrico proposto
por Lima Filho, (2007) e Anjos, (2008) e recentemente criado, ao atual sistema
de automação de poços dos campos de extração de petróleo. Além disso, é
importante que essa nova tecnologia não obrigue grandes mudanças nos
atuais processos, levando a altos custos e tornando-se inviável.
3
O sistema deve possuir flexibilidade na atualização de softwares;
oferecer de forma simples possibilidades de expansão e ser de fácil
manutenção. Para isso além dos sistemas de testes criados, diversos estudos
foram realizados visando uma implementação completa e funcional do sistema.
Estudos de diagramação, pinos de transmissão de dados dos dispositivos e
arquiteturas de desenvolvimento foram realizados.
A computação reconfigurável, aliada ao poder de um processador
embarcado foram utilizados de forma a atuarem satisfatoriamente no projeto.
Além disso, propostas de melhorias em alguns processos de automação foram
realizadas e implementadas. Essas melhorias possibilitaram não somente a
criação do sistema para automação de poços de petróleo como permitiu uma
aplicabilidade em outras formas de automações de redes de sensores sem fios,
como é o caso da automação de trens e automação residencial (criação das
chamadas “casas inteligentes”). Essa aplicabilidade é mostrada no apêndice B
como estudo de caso.
Os principais objetivos do sistema são:
• Customização do processador Nios II para atender as funcionalidades
do projeto;
• Implementação do módulo 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 módulo 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;
• Criação de um sistema em JAVA que possa simular e testar os dados
finais recebidos pelo protocolo MODBUS, para avaliar a integração
dessa tecnologia com os muitos sistemas de automação que utilizam
esse protocolo;
4
• Implementação de um sistema de testes para mostrar que o
desenvolvimento dessa tecnologia é viável e necessário.
• Criação de uma base de dados para armazenamento das informações e
disponibilização para um servidor WEB.
1.3 Organização
No Capítulo II será realizada uma fundamentação teórica para introduzir
os principais conceitos que serão utilizados neste trabalho servindo como base
para entendimento do mesmo. O Capítulo III mostra como é realizado o atual
sistema de automação de unidades de bombeamento mecânico de petróleo
(UBM) na maior parte do mundo e detalha o funcionamento das novas técnicas
desenvolvidas às quais este trabalho é aplicado, além disso, mostra o sistema
de testes desenvolvido como forma de validação da idéia inicial proposta. No
capítulo IV, detalharemos o sistema desenvolvido desde a sua arquitetura e
componentes de hardware à sua implementação e funcionamento. No Capítulo
V as ferramentas e a metodologia utilizada para desenvolvimento são
abordadas. O Capítulo VI contém os resultados obtidos através do sistema
desenvolvido e uma comparação deste trabalho com outras tecnologias
existentes. No Capítulo 7, por fim, algumas conclusões, trabalhos futuros e em
andamento são citadas como forma de contribuir para a continuidade de
utilização das idéias aqui propostas e implementadas. Nos apêndices finais a
diagramação UML e alguns estudos de caso são mostrados.
5
CAPITULO 2
Fundamentação Teórica
Este capítulo limita-se à apresentação dos principais conceitos técnicos
e teóricos necessários ao desenvolvimento deste trabalho. Aqui são descritas
as diversas tecnologias utilizadas, desde dispositivos de hardware, passando
por protocolos e padrões adotados e finalizando com as linguagens de
programação utilizadas.
2.1 Sistemas Embarcados
Um dos mais surpreendentes desenvolvimentos tecnológicos das
últimas décadas tem sido a utilização de computadores para afazeres
humanos. Hoje, a maioria dos computadores que existem no mundo, está em
nossas casas e escritórios e muitas vezes possuímos mais computadores em
uma casa do que mesmo em um escritório onde várias pessoas trabalham
diretamente com eles. Assim, quando perguntamos a uma pessoa quantos
computadores ela possui, e a mesma responde apenas um, esta não leva em
consideração de que possui inúmeros computadores embutidos na maioria dos
equipamentos que utiliza.
Até poucas décadas atrás era difícil 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
aplicações, cada uma com características únicas. De acordo com um estudo
realizado por Tennenhouse (2000), e que ainda reflete o cenário atual, somente
2% dos processadores produzidos são utilizados em computadores
convencionais (desktops e notebooks). O restante se encontra embarcado em
6
dispositivos como organizadores pessoais, eletrodomésticos, robôs, veículos e
aeronaves.
Sistemas embarcados (ou sistemas embutidos) são utilizados
largamente na indústria. Esse fato acompanhou a história desde o surgimento
dos primeiros microprocessadores, fornecendo soluções 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 combinação de hardware, software e, a
utilização ou não de peças mecânicas e outras partes, projetadas para
desempenhar uma função específica. Um bom exemplo é o forno de
microondas. A maioria das residências possui um e milhares são utilizados
todos os dias. Entretanto, poucas pessoas percebem que um processador e
um software estão envolvidos na preparação do seu almoço ou jantar. (BARR,
1999)
Isto está em contraste com o computador pessoal (PC) que possuímos
em casa. Ele é constituído de hardware, software e equipamentos mecânicos
como o disco rígido. No entanto ele não foi projetado para desempenhar uma
função específica, pelo contrário, é capaz de fazer diversas tarefas diferentes.
Muitas vezes ouvimos o termo computadores de propósito geral para tornar
essa distinção clara. Quando desenvolve um PC, o fabricante não 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 função bem clara e específica.
Geralmente são produzidos em larga escala e se encontram dentro de um
sistema maior. Como exemplo, podemos citar diversos automóveis 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 veículo e talvez ajustar
retrovisores. Muitas vezes esses sistemas embarcados formam uma rede de
sistemas podendo até comunicar-se um com o outro, embora isso não seja
obrigatório.
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 são
conhecidos, são sistemas que possuem limitações com relação ao tempo. Em
outras palavras, são sistemas que possuem suas características de resolver
cálculos ou determinadas decisões de forma temporal. Essas importantes
tarefas são 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 questão 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
operação irregular da aeronave. Entretanto em uma comunicação em uma rede
sem fios que possua um sistema em tempo real o não comprimento do prazo
pode simplesmente significar a perda ou corrupção 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 circunstâncias possíveis. E quando o sistema atinge o grau onde
vidas humanas dependem dele, o mesmo deve possuir uma engenharia de
cálculos e ser bem descrito através de documentações. (GANSSLE, 1999)
8
2.1.3 Mudanças de Projetos de Sistemas Embarcados
Ao contrário dos softwares de propósitos gerais, os sistemas
embarcados, não podem simplesmente ser transportados para outros
dispositivos e serem normalmente executados sem modificações significativas.
Isto se deve principalmente às incríveis variações nas camadas de hardware.
Os projetos de hardware são adaptados para cada sistema embarcado em
desenvolvimento, para que os custos sejam reduzidos. Assim, qualquer circuito
desnecessário é eliminado do projeto.
Segundo Barr (1999) por definição, um sistema embarcado possui um
processador e um software que será executado. Entretanto, outras
características comuns podem ser levadas em consideração como tempo de
desenvolvimento, custo, número de unidades e tempo de vida. Certamente, se
possuímos um software, precisamos de um local para armazenar o código
executável e os dados manipulados em tempo de execução. Este
armazenamento se dará através de memórias ROM e RAM, respectivamente,
embora alguns sistemas só possuam uma delas.
Além disso, todos os sistemas devem também conter algum tipo de
entrada e saída. Por exemplo, no forno microondas, o painel para escolha do
tipo de comida, tempo, potência, podem ser as entradas, e a radiação, o
controle de temperatura e o sinal sonoro de término as saídas. A Figura 2.1
mostra o modelo básico de um sistema embarcado.
Figura 2.1 – Diagrama básico de um sistema embarcad o.
9
Com a exceção de algumas dessas características comuns, o resto do
sistema é geralmente único. Esta variação se deve principalmente aos muitos
critérios 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 aplicações
Os sistemas embarcados estão inseridos em milhares de dispositivos
comuns utilizados no dia a dia como em eletrodomésticos, aparelhos de áudio
e vídeo, celulares e outros (GUPTA, 2002). A Seguir alguns exemplos de
aplicações:
a) Setor Automobilístico
Um veículo que já possua equipamentos sofisticados possui diversos
sistemas embarcados em funcionamento. Centenas de sensores fornecem
informações sobre todo o funcionamento do veículo. 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 ações referentes a cada caso sejam tomadas.
Figura 2.2 – Sistemas embarcados em um veículo.
b) Aquisição de Dados – Data Logger
A aquisição de dados, um exemplo de aplicação mais utilizada em
sistemas embarcados, consistem de sistemas que através de sensores
(temperatura, umidade, pH e outros) capturam as variáveis ambientes a serem
analisadas e são gravadas em memória para consultas posteriores. O Sistema
10
além de monitorar o ambiente, com adição de atuadores ao projeto, pode ter a
capacidade de controlar as variáveis ambiente com base em um critério
estabelecido pelo projetista do sistema.
Figura 2.3 – Data logger para temperatura do ar.
c) Propósito Geral
Estas aplicações englobam diversos tipos de dispositivos e são muito
parecidos com computadores de propósitos geral, pois possuem uma grande
quantidade de interação com usuários, geralmente utilizando vídeos,
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 interação co m o usuário
11
d) Sistemas de Controle
São sistemas mais robustos e dedicados, geralmente com realimentação
e execução em tempo real. Devido à importância das aplicações geralmente
são sistemas críticos e necessitam de aplicações robustas, com partes
dedicadas e múltiplos sinais de entrada e saída. Usados nos motores de
automóveis, processos químicos, controle de vôo, usinas nucleares, aplicações
aeroespaciais e monitoramento e controle de variáveis 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 informação a
ser processada em curto espaço de tempo. Os sinais a serem tratados são
digitalizados através de conversores Analógico/Digital, processados e
novamente convertidos em sinais analógicos por conversores Digital/Analógico.
Casos de tratamento de áudio, filtros, modems, compressão de vídeo, radares
e sonares, etc. Existem os DSP (Digital Signal Processor – Processador Digital
12
de Sinais) os microcontroladores dotados deste recurso são os Blackfin da
Analog Devices e o DsPIC da Microchip.
Figura 2.6 – Ambiente de desenvolvimento DSP para o dsPIC.
f) Comunicações, Redes e TV Digital
Chaveamento e distribuição de informações. Sistemas de telefonia e
telecomunicações e internet. Hub´s, Switch´s e Roteadores são dotados de
microprocessadores e de microcontroladores para controle digital de sinais. Na
TV Digital estes controladores digitais têm um núcleo 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 Computação Reconfigurável
Segundo Athanas, (1993) e Olukotun, (1994) a principal característica da
computação reconfigurável (reconfigurable computing – RC) é a presença de
um hardware que pode ser reconfigurado para implementar uma funcionalidade
específica mais apropriada e sob medida, e não um processador de propósito
geral. Sistemas de RC unem os microprocessadores e o hardware programável
com a finalidade de combinar o potencial do hardware e do software e ser
utilizado em aplicações que vão desde um sistema embarcado a sistemas de
alta performance computacional.
Embora os conceitos básicos tenham sido propostos na década de 60, a
RC só veio ser praticável recentemente. Durante a última década um grande
número de sistemas de RC desenvolvidos pela comunidade científica têm
demonstrado o potencial para atingir alta performance para uma diversidade de
aplicações. No entanto, as melhorias em desempenho desses sistemas
dependem normalmente da experiência de projetistas de hardware. Este
método de programação, entretanto, não pode explorar plenamente o atual
aumento de densidade dos dispositivos reconfiguráveis. Surge então o desafio
atual de criar um compilador eficiente que ajude o projetista a possuir um
desempenho adequado, realizando melhorias, sem estarem envolvidas
complexas manipulações em baixo nível de programação.
2.2.1 FPGAs
Field Programmable Gate Arrays (FPGAs) são circuitos integrados
digitais que contém blocos lógicos reconfiguráveis (reprogramáveis), chamados
de CLB (Configuration Logical Blocks) que são formados por portas lógicas e
flip-flops que implementam funções lógicas, e interconexões entre eles que
também 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 programação em oposição aos
dispositivos que possuem suas funcionalidades implementadas diretamente em
hardware durante a sua fabricação. Isto significa que eles podem ser
implementados em laboratório ou é possível reconfigurar a função de um
dispositivo que já tenha sido implementado em algum sistema com alguma
funcionalidade específica. Um esboço de um FPGA pode ser visualizado na
Figura 2.9.
Figura 2.9: Esboço de um FPGA
Disponível em: www.altera.com
15
O FPGA também é formado por estruturas chamadas de blocos de
entrada e saída (IOB – In/Out Blocks), os quais são responsáveis pelo
interfaceamento entre as saídas provenientes das combinações de CLBs. A
típica estrutura interna de um bloco lógico configurável de um FPGA consiste
em flip-flops, um determinado número de multiplexadores e uma estrutura de
função combinatória para implementar as funções lógicas.
Os PLD’s (Programmable Logic Devices) são dispositivos cuja
arquitetura interna é predeterminada na fabricação, mas são criadas de tal
forma que podem ser configuradas por engenheiros para executar uma
variedade de diferentes funções. Em comparação com os FPGAs, esses
dispositivos contêm um limitado número de portas lógicas e as funções que
eles podem implementar são geralmente muito pequenas e simples.
Os ASICs (Applications-Specific Integrated Circuits), por outro lado,
oferecem um maior desempenho, complexidade e tamanho (número 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 silício” e não pode ser modificada sem a
criação 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
milhões de portas lógicas possibilitando a utilização na implementação de
grandes e complexas funções 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 produções em larga escala. Ao mesmo tempo a
implementação pode ser mudada diversas vezes, além de se tornar bastante
rápida.
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 (WLAN’s), tanto em soluções proprietárias como nos
padrões desenvolvidos pelo IEEE, por exemplo. Com a evolução natural das
tecnologias das redes sem fio, estas passaram a atender não só as aplicações
corporativas mais sofisticadas como também aquelas envolvendo pequenos
volumes de dados que exigem baixas taxas de transmissão como, por
exemplo, o controle de equipamentos eletroeletrônicos. Além disso, outras
tecnologias sem fio têm sido utilizadas também com o objetivo de proporcionar
a comunicação pessoal e o controle de dispositivos diversos, são as chamadas
redes pessoais (WPAN’s).
Basicamente, essas tecnologias têm o propósito de permitir o controle
remoto de equipamentos domésticos (televisores, videocassetes, geladeiras,
etc) e periféricos (teclados, mouse, impressoras, etc), eliminando os cabos e
tornando mais prática a operação desses equipamentos pelos usuários.
Uma das tecnologias mais recentes dentro desse grupo de redes para
aplicações pessoais e que permite o gerenciamento e controle desses
dispositivos é o padrão ZigBee, também conhecido como HomeRF Lite e que
corresponde ao IEEE 802.15.4. O ZigBee começou de fato no ano de 2002
como um padrão global e aberto para a comunicação sem fio de baixo custo e
pequeno alcance, com características 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 associação que conta com mais de 45
empresas que trabalham em conjunto para desenvolver um padrão capaz de
possibilitar um controle seguro, de baixo custo e de baixa potência em redes
sem fio. O padrão ZigBee é utilizado para o controle de diversos equipamentos,
incluindo soluções para a automação predial, aplicações em telemedicina e
entretenimento (jogos). (PINHEIRO, 2004)
Segundo Eduardo Prado, Num futuro não muito distante, não será difícil
contar pelo menos 50 chips de "ZigBee" numa residência. Eles serão
encontrados nos interruptores de lâmpadas, em detectores de fogo e fumaça,
17
termostatos, eletrodomésticos na cozinha, e em controle remotos de vídeo e
áudio. (PRADO, 2006)
O padrão oferece atualmente interfaces com velocidades de conexão
compreendidas entre 10Kbps e 250Kbps, freqüências de até 2,4GHz e com um
alcance de transmissão entre 10m e 1000m, dependendo diretamente da
potência dos equipamentos e de características ambientais (obstáculos físicos,
interferência eletromagnética, etc.).
Quanto ao problema de alimentação dos dispositivos, os módulos 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 aplicação a que se destina.
Nesse aspecto, o protocolo ZigBee foi projetado para suportar aplicações com
o mínimo de consumo.
Para se ter uma idéia, uma pilha pequena utilizada em casa pode chegar
a 2500mAh. Um ZigBee com diversas funcionalidades consome cerca de
45mAh levando a uma duração de 55,6 horas de funcionamento ininterrupto.
Entretanto essa tecnologia possui diversas alternativas de redução de
consumo, como um modo de pausa (diz-se que o módulo 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 serviços específicos para dispor a camada superior: a
entidade de dados fornece dados para o serviço de transmissão e a entidade
de gestão fornece informação para todos os outros serviços. Cada entidade de
serviço expõe uma interface para a camada superior através do ponto de
acesso ao serviço (SAP) e cada SAP suporta um número de primitivas de
serviço 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 definição das camadas física 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 padrão,
desempenhando a função de coordenador da rede e conseqüentemente ter
acesso a todos os outros dispositivos. Trata-se de dispositivos de construção
mais complexa;
Reduced Function Device (RFD) - é limitado a uma configuração com
topologia em estrela, não podendo atuar como um coordenador da rede. Pode
comunicar-se apenas com dispositivos FFD. São dispositivos de construção
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 é possível customizar um processo de roteamento adicional.
Possíveis arquiteturas de rede ZigBee são apresentadas na Figura 2.11. Redes
em malha permitem aumentar a gama, a confiabilidade e a formação de redes
ad hoc (redes em que cada nó possui os mesmos direitos e deveres, não existe
um nó central).
19
Figura 2.11: Modelo das redes ZigBee
As aplicações que utilizam o protocolo e dispositivos ZigBee são
definidas por conveniência, focando gerenciamento de energia e conectividade.
Diversos tipos de aplicações aceitam esse padrão de forma simples e bastante
satisfatória. Na Figura 2.12 podemos ver algumas das aplicações que podem
utilizar o padrão ZigBee.
Figura 2.12: Aplicações do padrão ZigBee
2.3.2 Protocolo ZigBee e Redes de Sensores sem Fios
Redes de Sensores Sem Fio (RSSFs) têm sido viabilizadas pela rápida
convergência de três tecnologias: microeletrônica, comunicação sem fio e
micro sistemas eletromecânicos (MEMS – Micro Electro-Mechanical Systems).
Uma RSSF é uma ferramenta de sensoriamento distribuído de fenômenos,
processamento e disseminação de dados coletados e informações
20
processadas para um ou mais observadores. O potencial de observação e
controle do mundo real permite que as RSSFs se apresentem como uma
solução para diversas aplicações de monitoramento e controle.
Uma rede de monitoramento e controle ou de automação industrial
formada por sensores de grandezas físicas (temperatura, umidade, pressão,
etc.) e dispositivos atuadores (chaves, relés, etc.) não necessita de uma largura
de banda elevada para funcionar, mas sim de uma latência pequena e baixo
consumo de energia para preservar a vida útil das baterias. Segundo Santos
(2007) ainda são poucos os padrões de redes sem fio para aplicações em
redes locais utilizando sensores e outros dispositivos de controle. Um dos
segmentos onde mais tem crescido a aplicação de redes sem fio é o das redes
domésticas, principalmente em aplicações de automação comercial e
residencial. Atualmente encontramos diversos equipamentos controlados
remotamente, desde televisores, home theaters, DVD’s, até computadores,
impressoras, etc. Neste contexto, o protocolo ZigBee definido pela ZigBee
Alliance e pelo padrão IEEE 802.15.4, surge como uma alternativa para
atender às especificações dessas aplicações.
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 comunicação como o WiFi e Bluetooth por exemplo. Seu
consumo de energia é geralmente mais baixo que nas redes com WiFi ou
Bluetooth. Uma característica importante do ZigBee que o diferencia dos outros
protocolos é que ele permite expandir uma rede através de milhares de nós.
Teoricamente, uma rede ZigBee pode conter cerca de 65.536 nós, embora, na
prática não é recomendável exceder 3000 nós em uma rede. Outra vantagem
dos dispositivos ZigBee é a velocidade com que novos nós podem ser
adicionados a rede: 30ms; enquanto que um nó que estava em estado de sono
pode ser acordado em 15ms, e então começar a comunicação com outros nós
da rede. Este aspecto pode ser vital para muitas aplicações industriais. (IEEE,
2008)
21
Para garantir a eficácia no desenvolvimento de sistemas de aquisição de
dados que utilizam tecnologia de transmissão por freqüência de rádio, faz-se
necessário um estudo sobre os principais aspectos que influenciam o
desempenho destas tecnologias. Em Santos (2007) é apresentado um estudo
do protocolo ZigBee sobre diferentes cenários que levam em consideração
características como interferência interna, confiabilidade, latência e taxa de
dados de uma rede ZigBee.
2.3.3 Hardware ZigBee
Dentre as principais e mais conhecidas empresas que trabalham junto à
aliança 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 é possível encontrar diversas
funcionalidades como conversores analógico/digital, potenciômetros, entradas
digitais e analógicas, e muitas outras tecnologias embutidas.
Um modelo de um chip ZigBee da MaxStream e os seus pinos é
mostrado na Figura 2.13. Através da Tabela seguinte podemos ver os pinos
disponíveis nesse módulo ZigBee e quais são as funcionalidades de cada pino.
A função de um pino do circuito é definida através do firmware contido no chip.
Utilizando-se um programa disponibilizado pelo fabricante é possível atribuir as
características desejadas como, por exemplo, se aquele pino deve ser utilizado
como uma entrada analógica ou até mesmo uma saída digital.
Figura 2.13: Modelo do ZigBee da MaxStream e seus 2 0 pinos
22
Pino Nome Direção Descrição 1 VCC - Alimentação 2 DOUT Saída Saída de dados da UART 3 DIN / CONFIG Entrada Entrada de dados UART 4 DO8 Saída Saída digital 8 5 RESET Entrada Reinicia o módulo 6 PWM0 / RSSI Saída Saída PWM 0 / RSSI 7 PWM1 Saída Saída PWM 1 8 [Reservado] - Não conectado
9 DTR / SLEEP_RQ/ DI8 Entrada Pino de controle de espera ou entrada digital 8
10 GND - Terra
11 AD4 / DIO4 Bidirecional Entrada analógica 4 ou entrada/saída Digital 4
12 CTS / DIO7 Bidirecional Controle de fluxo ou
entrada/saída digital 7 13 ON / SLEEP Saída Indicador de status do módulo
14 VREF Entrada Voltagem de referência para
entradas digitais e analoógicas
15 Associate / AD5 / DIO5 Bidirecional Indicador, Entrada analógica 5 e
entrada/saída digital 5
16 RTS / AD6 / DIO6 Bidirecional Controle de Fluxo, entrada
analógica 6 ou entrada/saída digital 6
17 AD3 / DIO3 Bidirecional Entrada analógica 3 ou entrada/saída digital 3
18 AD2 / DIO2 Bidirecional Entrada analógica 2 ou entrada/saída digital 2
19 AD1 / DIO1 Bidirecional Entrada analógica 1 ou entrada/saída digital 1
20 AD0 /DIO0 Bidirecional Entrada analógica 0 ou entrada/saída digital 0
Tabela 2.1: Descrição dos 20 pinos presentes no Zig Bee MaxStream.
O fluxo de funcionamento de uma transmissão serial do módulo ZigBee
MaxStream ocorre através dos pinos de DI (entrada) e DO (saída). O DO pode
ser mapeado para qualquer pino de saída que aceite saída digital ou através de
modulação PWM em um pino de saída analógica. Quando os dados seriais
entram no módulo RF através do pino DI (pino 3), os dados são armazenados
no buffer DI até que eles possam ser processados. Quando o DI buffer atinge
dezessete bytes após ter enchido, por padrão, o módulo modifica o sinal do
CTS para nível alto solicitando que o dispositivo pare de enviar dados. O CTS é
reconfigurado para nível baixo quando o DI Buffer possuir 34 bytes de memória
disponível. Quando os dados do RF são recebidos, eles entram no DO buffer e
são enviados através da porta serial para o dispositivo receptor. Um esboço do
funcionamento pode ser visualizado na Figura 2.14.
23
Figura 2.14: Diagrama de fluxo do módulo ZigBee
2.4 Protocolo ModBus
O padrão MODBUS define um protocolo de mensagens na camada de
aplicação, posicionada no nível sete do modelo de referência OSI que provê
comunicação cliente/servidor entre dispositivos conectados em diferentes tipos
de barramentos ou topologias de redes. (MODBUS APLICATION PROTOCOL
SPECIFICATION, 2002)
Este padrão iniciou a sua incorporação pelas indústrias em 1979 e ainda
continua sendo utilizado por milhões de dispositivos de automação para
comunicação. Hoje, o MODBUS pode ser utilizado desde uma simples
estrutura de dados seriais a formas mais complexas como suporte a utilização
da internet através da porta 502 no TCP/IP.
Alguns principais tipos de implementação do protocolo MODBUS, mostrados
na Figura 2.15, são:
MODBUS Padrão (mestre/escravo): É usado para comunicação de CLPs
(Controladores Lógico Programáveis) com os dispositivos de entrada e saída
de dados, instrumentos eletrônicos inteligentes (IEDs) como relés de proteção,
controladores de processo, atuadores de válvulas, transdutores de energia e
etc. o meio físico é o RS-232 ou RS-485 em conjunto com o protocolo mestre-
escravo.
24
MODBUS plus: É usado para comunicação de controladores lógicos
programáveis entre si, módulos de E/S, chaves de partida eletrônica de
motores, interfaces homem máquina etc. O meio físico é o RS-485 com taxas
de transmissão de 1 Mbps, controle de acesso ao meio por HDLC (High Level
Data Link Control).
MODBUS TCP/IP: é usado para comunicação entre sistemas de supervisão e
controladores lógicos programáveis. O protocolo ModBus é encapsulado no
protocolo TCP/IP e transmitido através de redes padrão ethernet com controle
de acesso ao meio por CSMA/CD.
Figura 2.15: Camadas das formas de implementação do MODBUS
O protocolo ModBus define um simples protocolo de unidade de dados
(Protocol Data Unit - PDU) independente das camadas de aplicação. O
mapeamento do protocolo para barramentos e redes específicas pode
introduzir alguns campos adicionais na unidade de aplicação 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
requisição a um servidor. O pacote enviado possui o código da função
requerida e os dados necessários para realizar aquela função. O servidor
recebe o pacote, executa a ação e inicia a resposta para o cliente. Em caso de
erro, o código da função é substituído por um código que indica qual tipo de
erro ocorreu.
Além das funções pré-especificadas no protocolo, existem campos
disponíveis para implementação de novas funções. O protocolo MODBUS é
bastante susceptível a adicionar funcionalidade e talvez seja por isso sua larga
utilização na indústria. Em contrapartida, diversos fabricantes desenvolvem o
seu próprio protocolo baseado no MODBUS e não disponibilizam alterações 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 propósito
geral, desenvolvido para atender uma grande escala de dispositivos
embarcados. As principais características do Nios II são: conjunto de
instruções, espaço de endereçamento e endereçamento de dados de 32-bits;
32 registradores de propósitos geral; 32 fontes de interrupções externas;
instruções dedicadas ao cálculo de multiplicações com 64-bits e 128-bits;
acesso a uma variedade de periféricos on-chip, e interfaces para acesso a
memórias e periféricos off-chip; oferece cerca de 2 Giga Bytes de espaço de
endereçamento e customização de até 256 instruções. (BUENO ET AL, 2007)
Nios II é um processador soft-core, pois a plataforma é flexivelmente
modificável e é apresentada como um núcleo soft, ou seja, não é uma pastilha
de silício pronta, é apresentado através de um projeto codificado através de
uma linguagem de descrição de hardware, como VHDL ou Verilog e pode ser
implementado em qualquer FPGA da família 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 referência do Nios II da Altera. Entretanto pode-se
utilizar essas funcionalidades e implementá-las nas plataformas de hardware
que estão sendo desenvolvidas, ou, caso contrário, pode-se personalizar o
processador Nios II para que ele atenda os requisitos de custo e desempenho
necessários.
Figura 2.17: Kit de desenvolvimento Altera para o N ios II
Segundo Peron (2007), a configurabilidade que o processador Nios II
possibilita, não implica que os projetistas devam implementar uma nova
configuração para cada projeto. O fabricante Altera disponibiliza alguns
sistemas Nios II prontos para uso. Então, se algum se adéqua a aplicação em
desenvolvimento, pode ser simplesmente incorporada ao projeto, não havendo
necessidade de configuração do processador. Além disso, através do
simulador de instruções, o Nios II permite aos projetistas escrever e depurar
aplicações antes que a configuração 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
combinação de periféricos e memória em um único chip. O termo “sistema do
processador Nios II” se refere a um core do processador Nios II, um conjunto
de periféricos on-chip, memória interna e interfaces para memória externa, tudo
implementado em um único chip da Altera. Do mesmo modo que uma família
de microcontroladores, todos os sistemas do processador Nios II usam um
Disponível em www.altera.com
27
conjunto de instruções e um modelo de programação consistentes. (PERON,
2007)
Seu conjunto flexível de periféricos é uma das diferenças 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 periféricos necessários para
as aplicações desejadas. Outro ponto importante de uma arquitetura flexível é
ter um mapa de endereçamento flexível. Variáveis de software podem ter
acesso genérico à memória e aos periféricos, independente da localização do
endereço segundo Altera (2007). Portanto, o conjunto flexível de periféricos
produzidos de acordo com a necessidade do projetista e o mapa de
endereçamento não afetam os desenvolvedores de aplicações e facilitam a
integração de desenvolvimento à plataforma.
Os periféricos podem ser aqueles comumente encontrados em
microcontroladores, tais como timers, interfaces de comunicação serial, E/S de
propósito geral, controladores SDRAM e outras interfaces de memória. Além
disto, os projetistas podem adicionar seus próprios periféricos personalizados e
integrá-los ao processador Nios II.
Para sistemas onde o desempenho é crítico, onde a CPU gasta a
maioria dos ciclos de clock executando uma parte específica do código, uma
técnica comum é criar um periférico personalizado que implementa a mesma
função em hardware. Esta abordagem oferece uma melhora dupla no
desempenho: a implementação em hardware é mais rápida que a em software,
e o processador fica livre para executar outras funções em paralelo enquanto o
periférico personalizado opera nos dados.
O processador Nios II se comunica com um barramento de interconexão
denominado Avalon. O Avalon é um barramento especial que prioriza a
velocidade de transmissão de dados, permitindo conexões em paralelo. Este
barramento é responsável pela integração do núcleo de processamento e os
demais dispositivos, como memória, temporizadores, periféricos de entrada e
saída, 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, é possível projetar e
simular aplicações para esse processador. Utilizando-se os projetos de
hardware de referencia, como mostrado na Figura 2.18, o projetista pode
prototipar sua aplicação 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 referência para prototipa ção do Nios II
2.6 Linguagens de programação
2.6.1 Linguagem C
A linguagem C foi criada por Dennis Ritchie, em 1972, no centro de
Pesquisas da Bell Laboratories. Sua primeira utilização importante foi a
reescrita do Sistema Operacional UNIX, que até então era escrito em
Assembly. Em meados de 1970 o UNIX saiu do laboratório para ser liberado
para as universidades. Foi o suficiente para que o sucesso da linguagem
atingisse proporções tais que, por volta de 1980, já existiam várias versões de
compiladores C oferecidas por várias empresas, não sendo mais restritas
29
apenas ao ambiente UNIX, porém compatíveis com vários outros sistemas
operacionais. (SCHILDT, 1996)
O C é uma linguagem de propósito geral, sendo adequada à
programação estruturada. No entanto é mais utilizada escrever compiladores,
analisadores léxicos, bancos de dados, editores de texto, etc.. A linguagem C
pertence a uma família de linguagens cujas características são: portabilidade,
modularidade, compilação separada, recursos de baixo nível, geração de
código eficiente, confiabilidade, regularidade, simplicidade e facilidade de uso.
A geração do programa executável a partir do programa fonte obedece a
uma seqüência de operações antes de tornar-se um executável. Depois de
escrever o código fonte em um editor de textos, o programador aciona o
compilador que no UNIX é chamado pelo comando cc. Essa ação desencadeia
uma seqüência de etapas, cada qual traduzindo a codificação do usuário para
uma forma de linguagem de nível inferior, que termina com o executável criado
pelo linker (lincador). A seguir os passos necessários para compilação de um
código em C.
1. Editor (módulo fonte em C)
2. Pré-processador (novo fonte expandido)
3. Compilador (arquivo objeto)
4. Lincador (executável)
Inicialmente, C era usada na programação de sistemas. Um programa
de sistema forma uma porção do sistema operacional do computador ou de
seus utilitários de suporte. Por exemplo, os programas que seguem são
frequentemente chamados de programas de sistema: sistemas operacionais,
interpretadores, editores, programas de planilha eletrônica, compiladores,
gerenciadores de banco de dados.
Em virtude da sua portabilidade e eficiência, à medida que C cresceu em
popularidade, muitos programadores começaram a usá-la para programar
todas as tarefas. Por haver compiladores C para quase todos os
computadores, é possível tornar um código escrito para uma máquina, compilá-
30
lo e rodá-lo em outra com nenhuma ou pouca modificação. Os compiladores C
também tendem a produzir um código-objeto muito compacto e rápido (menor e
mais rápido 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 aplicações baseadas na rede Internet, redes fechadas ou
ainda programas stand-alone [CAM96]. Foi desenvolvida na 1a metade da
década de 90 nos laboratórios da Sun Microsystems com o objetivo de ser
mais simples e eficiente do que seus predecessores. O alvo inicial era a
produção de software para produtos eletrônicos de consumo (fornos de
microondas, agendas eletrônicas, etc.). Um dos requisitos para esse tipo de
software é ter código compacto e de arquitetura neutra.
A linguagem obteve sucesso em cumprir os requisitos de sua
especificação, mas apesar de sua eficiência não conseguiu sucesso comercial.
Com a popularização da rede Internet, os pesquisadores da Sun Microsystems
perceberam que aquele seria um nicho ideal para aplicar a recém criada
linguagem de programação. A partir disso, adaptaram o código Java para que
pudesse ser utilizado em microcomputadores conectados a rede Internet, mais
especificamente no ambiente da World Wide Web. Java permitiu a criação de
programas batizados applets, que trafegam e trocam dados através da Internet
e se utilizam da interface gráfica de um web browser. Implementaram também
o primeiro browser compatível com a linguagem, o HotJava, que fazia a
interface entre as aplicações Java e o sistema operacional dos computadores.
(DEITEL, 2005)
Java é uma linguagem poderosa em ambientes distribuídos complexos
como a rede Internet. Mas sua versatilidade permite ao programador ir além,
oferecendo uma poderosa linguagem de programação de uso geral, com
recursos suficientes para a construção de uma variedade de aplicativos que
podem ou não depender do uso de recursos de conectividade segundo Wutka
31
(1997). As principais características da linguagem foram divulgadas pela
primeira vez em The Java Language: A White Paper. (GOSLING, 1996).
Além disso, o Java possui mais algumas características interessantes a
se ressaltar, tais como: sintaxe similar a linguagem C/C++, facilidades de
Internacionalização (suporta nativamente caracteres Unicode), é distribuída
com um vasto conjunto de bibliotecas (ou APIs), possui facilidades para criação
de programas distribuídos e multi-thread (múltiplas linhas de execução num
mesmo programa), desalocação de memória automática por processo de
coletor de lixo, carga dinâmica de código (programas em Java são formados
por uma coleção de classes armazenadas independentemente e que podem
ser carregadas no momento de utilização).
Algumas necessidades básicas para se programar em Java são a
utilização de algumas ferramentas como: JDK (Java development Kit) (um
pacote com as principais classes do Java e um compilador) e uma IDE. A título
de exemplo temos: NetBeans patrocinado pela SUN MicroSystems
(netbeans.org) e o Eclipse patrocinado pela IBM.
A linguagem Java é tanto compilada como interpretada. Após escrever
um programa em Java, utilizando um editor de textos qualquer, salva-se o
programa como código fonte. A seguir, pode-se compilar esse código fonte, a
fim de produzir um tipo de arquivo binário chamado de arquivo de classe.
Esses arquivos não são executados diretamente pois eles não contêm
instruções que são entendidas diretamente pelos processadores atualmente
disponíveis no mercado. Os programas Java são compilados em um formato
intermediário chamado bytecodes. Assim, esses programas podem ser
executados em qualquer sistema através de um interpretador Java (runtime
environment). Com isso, o código precisa ser escrito e compilado apenas uma
vez, pois os bytecodes gerados serão executados da mesma forma em
qualquer plataforma de hardware e software.
O Java é a única linguagem de programação realmente multi-plataforma
graças a JVM (Java Virtual Machine) , que é a responsável pela execução de
um programa escrito em Java. Um código fonte escrito em Java é traduzido
32
para bytecode, que é lido e executado pela Java Virtual Machine (que
obrigatoriamente tem que estar instalada na máquina). Esse processo de
compilação e execução chega a ser até 20 vezes mais lento que a linguagem
C, mas isso não impede que o Java seja implantado com qualquer tipo de
software. A JVM cria um ambiente virtual para o Java independente da
máquina que estivermos trabalhando, isso deu ao Java o grande impulso para
sua disseminação ser tão elevada quando comparada as outras linguagens.
(DEITEL, 2005)
O javac é um compilador de códigos Java com uma saída em bytecodes.
A execução de programas Java, é feita através do interpretador Java, que é um
programa encontrado na pasta bin da instalação do JDK e executa aplicações
Java compiladas (bytecodes – extensão .class). Todo código escrito em Java
deve ser salvo com a extensão .java. Quando compilado será gerado no
mínimo um .class para cada .java existente. Como o Java é case sensitive,
todo e qualquer comando, variável, nome de classes e objetos escritos em
Java será diferenciado entre maiúsculas e minúsculas.
2.6.3 Linguagem LabView
LabVIEW (Laboratory Virtual Instruments Engineering Workbench) é
uma linguagem de programação desenvolvida pela National Instruments. O
LabVIEW é diferente das usuais linguagens de programação em um aspecto
importante. Ao invés de utilizar linhas de código, ele utiliza uma linguagem
gráfica conhecida como linguagem G que é composta de muitos fios virtuais
conectados.
O LabVIEW tem um compilador gráfico aperfeiçoado para maximizar o
desempenho do sistema. Este ambiente simplifica o desenvolvimento do
programa, e também diz imediatamente ao usuário quando um erro foi
cometido. Como também produz um código que pode ser reutilizável. LabVIEW
é usado como um substituto para as linguagens baseadas em linhas de código,
permitindo ao usuário observar o que o programa está fazendo literalmente,
deste modo, você pode inserir um pedaço de código esquecido, e pode estudar
como o dados estão sendo executados e transferidos durante o programa. Ele
33
tem extensivas bibliotecas de funções para qualquer programa. Os programas
no LabVIEW são chamados de Virtual Instruments (VI’s) porque a aparência e
as operações simulam instrumentos reais.
Sob este ponto de vista, podemos resumidamente citar as
características do LabVIEW: (BURNETT, ET. AL, 1995)
É uma linguagem de programação visual - isto é, suas “instruções” de
programação são representadas por ícones que podem ser conectados de
modo a compor o programa
• Suporta programação por texto - o LabVIEW possui blocos que
permitem que se digite o texto de um programa, com duas possíveis
linguagens: (a) uma linguagem com sintaxe tipo C e (b) uma linguagem
com sintaxe tipo Matlab. Esses blocos podem ser interligados aos
ícones da programação 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 multiprogramação - ou seja,
explora os recursos de multi-tarefas (multitasking) e multi-
(multithreading), bem como a distribuição dos mesmos
automaticamente (ou manualmente, de forma explícita, se for
desejado) entre diferentes processadores ou núcleos de processadores
(multicore execution).
• É uma linguagem orientada pelo fluxo de dados (dataflow) - a sequência
de execução e interdependência entre as instruções, procedimentos e
módulos é estabelecida por um grafo direcional (directed graph).
• Suporta orientação a objetos - o LabVIEW é nativamente uma linguagem
orientada a objetos, em sua implementação. Todavia, apresenta-se ao
programador principalmente como orientado ao fluxo de dados. Desde
34
a versão 8.2, o LabVIEW oferece construtores para a criação de
objetos, no sentido de programação orientada a objetos.
• Não suporta explicitamente programação recursiva - embora haja
menção de ser possível conseguir-se isso com algum esforço.
• Sob este ponto de vista, muito resumidamente, suas características são:
• Provê a separação real entre a interface de usuário e o código do
programa. Ao abrir, o LabVIEW oferece duas janelas distintas: painel
frontal - para desenvolvimento da interface gráfica de operação do
programa (pelo usuário) e o diagrama de blocos - onde é feito o
desenvolvimento do algoritmo, programado em linguagem visual.
• Ambiente compilado - os blocos do LabVIEW são peças pré-compiladas,
que são ligadas ao corpo do programa à medida que se vai editando.
Não é uma linguagem interpretada.
• Permite produzir programas que funcionam fora do ambiente LabVIEW,
sozinhos, instaláveis separadamente. O programa desse tipo (stand-
alone) é produzido (built) com opções de ligação estática ou dinâmica
das bibliotecas (DLLs). Esse processo permite criar também o
instalador.
• O código desenvolvido na linguagem visual é compilado diretamente
para linguagem de máquina, não é traduzido para nenhuma outra
representação intermediária.
• Aceita a ligação de DLL’s ao código, oferecendo um bloco de
prototipação da interface com o procedimento pré-compilado, que
permite ligar cada variável do mesmo ao diagrama de blocos.
• Oferece ferramentas de depuração (debug) avançadas, permitindo
acompanhar execução passo a passo, monitorar visualmente as
variáveis, produzir visualizações de valores instantâneos em qualquer
ponto do programa, no formato específico de cada variável (ex:
imagens são mostradas como imagens, tipos mistos de dados
aparecem conforme construídos, etc.).
35
• Suporta diversos níveis de abstração de comunicação entre módulos,
objetos, partes de código e o hardware. Aceita protocolos desde
Seriais, Paralelos, TCP-IP, UDP, até ActiveX, etc.
• Suporta protocolos e representações compatíveis com sistemas
distribuídos, dotados de mobilidade, persistência, etc. Oferece
mecanismos para desenvolvimento de arquiteturas com .NET e outros.
• Já é portado para diversas plataformas - Linux, Windows, MacOS.
Também é disponível em versões para sistemas operacionais de
tempo real.
• Trata os componentes de hardware como se fossem objetos
programáveis dentro do ambiente LabVIEW, expondo os parâmetros e
variáveis físicos como tipos abstratos de dados no programa e as
operações 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 monitoração de
processos distribuídos.
• Produz código para ser utilizado diretamente em sistemas embarcados
que são especificados durante o desenvolvimento. Diversos fabricantes
de chips para sistemas embarcados estão disponíveis.
• Suporta o acesso de baixo nível a componentes do hardware que o
permitam fazê-lo.
2.6.4. Language VHDL (VHSIC Hardware Description La nguage)
VHDL é uma linguagem para descrição de circuitos eletrônicos digitais.
Ela foi um resultado de um programa de desenvolvimento de circuitos
integrados de altíssima velocidade (VHSIC) iniciado em 1980 pelo governo dos
Estados Unidos. Neste programa, tornou-se claro a necessidade de criação de
uma linguagem padrão para descrição de estruturas a funcionamento de
circuitos integrados (CIs). Então a VHSIC Hardware Description Language
(VHDL) foi desenvolvida, e em seguida adotada como um padrão 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 questões de portabilidade, documentação 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 informações sobre estes
componentes e projetos. Uma linguagem que, independente do formato original
do circuito, pudesse servir como uma descrição e documentação eficientes do
circuito, possibilitando os mais diferentes fornecedores e participantes a
entender o funcionamento das outras partes, padronizando a comunicação.
(D’AMORE, 2005)
Após o sucesso inicial do uso da VHDL, a sua definição foi posta em
domínio público, o que levou a ser padronizada pelo IEEE em 1987. O fato de
ser padronizada e de domínio público ampliou ainda mais a sua utilização,
novas alterações foram propostas, como é natural num processo de
aprimoramento e a linguagem sofreu uma revisão e um novo padrão mais
atualizado foi lançado em 1993. Atualmente ela continua a ser revisada e
deverá ser lançado um novo padrão. (D’AMORE, 2005)
VHDL é uma linguagem estruturada que oferece a possibilidade de
descrever e simular o hardware antes de sua síntese, facilitando a validação ou
verificação, tanto em termos de funcionamento quanto em termos de tempos
de atraso dos componentes e desempenho, sem a necessidade da
prototipação do sistema.
Um programa em VHDL pode ser dividido e implementado em parte
como software (hardware programável) e outra, em hardware reconfigurável.
Pode ser escrito basicamente usando dois tipos (modelos) de descrição:
estrutural e comportamental. Na descrição estrutural, a organização física e
37
topológica do sistema é descrita, ou seja, são especificadas as entradas e/ou
saídas, os componentes lógicos, a interligação deles e os sinais que compõem
o sistema.
Na descrição comportamental, não é preciso descrever a organização
física e topológica do sistema, somente o comportamento. São descritas as
funções (comportamento) do sistema. Um programa que utiliza esse tipo de
descrição possui o mesmo formato de um programa fonte escrito em uma
linguagem de programação de alto nível, 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 são: projetos independentes da tecnologia; maior facilidade de
atualização dos projetos; exploração de alternativas arquiteturais em um nível
mais alto de abstração; redução do tempo de projeto e custos; e simplificação
da documentação. Como desvantagem o hardware gerado é menos otimizado,
simulações mais lentas e falta de pessoal treinado para lidar com a tecnologia.
(D’AMORE, 2005)
2.7 Barramento USB
USB é a sigla de Universal Serial Bus. Trata-se de uma tecnologia que
tornou mais simples e fácil a conexão de diversos tipos de aparelhos (câmeras
digitais, drives externos, modems, mouse, teclado, etc) ao computador,
evitando o uso de um tipo específico de conector para cada dispositivo. O
padrão USB foi desenvolvido em meados da década de 1990 por um consórcio
de empresas, entre as quais se destacam: Microsoft, Apple, Hewlett-Packard,
NEC, Intel e Agere.
Uma característica importante e interessante do USB, é que sua
interface permite que o dispositivo conectado seja alimentado pelo cabo de
dados, ou seja, não é necessário ter outro cabo para ligar o aparelho à tomada.
Mas, isso só é possível com equipamentos que consomem pouca energia.
O USB possui um conector universal que permite ao usuário adicionar
periféricos, apenas conectando-os ao computador através de um cabo,
38
permitindo transferências a 1,5 ou 12 Mbits/s para a versão 1.0/1.1 e até 480
Mbits/s para a versão 2.0.
Dois identificadores são usados para marcar um dispositivo: o ID de
vendedor e o ID de produto. Ambos IDs são 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 número de 16 bits e marca o produto. A
atribuição é feita pelo fabricante do dispositivo. Para o PID não há nenhuma
restrição administrativa do USBIF como no VID.
Com todas as vantagens, o barramento USB tornou-se o meio mais fácil
de conectar periféricos ao computador. Qualquer usuário pode instalar
dispositivos USB na máquina, pois, utilizando o padrão PnP (Plug and Play), o
sistema operacional reconhece e disponibiliza imediatamente o dispositivo a
ser instalado. Para isso é necessário que a placa mãe da máquina e o sistema
operacional sejam compatíveis com o barramento.
Outra facilidade é a de se conectar e desconectar qualquer dispositivo
com o computador ligado (Hot Putting) sem que ele sofra danos, não sendo
necessário reiniciar o computador para que o aparelho instalado possa ser
usado.
Um fato interessante é a possibilidade de conectar alguns periféricos a
outros (por exemplo, uma impressora a um scanner), mas isso só é possível 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 não é viável, uma vez que a velocidade de transmissão
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
disponíveis na época, os quais não controlavam o acesso concorrente por
vários usuários ou processos. Os SGBDs evoluíram desses sistemas de
39
arquivos de armazenamento em disco, criando novas estruturas de dados com
o objetivo de armazenar informações. Com o tempo, os SGBD’s passaram a
utilizar diferentes formas de representação, ou modelos de dados, para
descrever a estrutura das informações contidas em seus bancos de dados.
Atualmente, os seguintes modelos de dados são normalmente utilizados pelos
SGBD’s: modelo hierárquico, modelo em redes, modelo relacional (amplamente
usado) e o modelo orientado a objetos. (TAKAI, 2007)
Os bancos de dados são utilizados em muitas aplicações, abrangendo
praticamente todo o campo dos programas de computador. Os bancos de
dados são o método de armazenamento preferencial para aplicações
multiusuário, nas quais é necessário haver coordenação entre vários usuários.
Entretanto, são convenientes também para indivíduos, e muitos programas de
correio eletrônico e organizadores pessoais baseiam-se em tecnologias
padronizadas de bancos de dados.
Um banco de dados é um conjunto de informações com uma estrutura
regular. Um banco de dados é normalmente, mas não necessariamente,
armazenado em algum formato de máquina legível 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 milhões de registros, armazenados em salas cheias de discos rígidos.
O PostgreSQL (conhecido anteriormente como Postgres95) derivou do
projeto Postgres da universidade de Berkley, cuja última versão foi a 4.2. O
Postgres foi originalmente patrocinado pelo DARPA (Agência de Projetos de
Pesquisa Avançada para Defesa), ARO (Departamento de Pesquisa Militar),
NSF (Fundação Científica Nacional) e ESL Inc. A implementação do projeto
POSTGRES iniciou em 1986, já em 87 tornou-se operacional. A primeira
versão lançada para o público externo foi em 1989. Devido a uma crítica feita
ao seu sistema de regras, o Postgres teve essa parte re-implementada e
lançada em uma segunda versão em 1990. Em 1991 foi lançada a versão 3,
com melhorias no executor de consultas e algumas partes do código foram re-
escritas. As versões subsequentes, até o Postgres95, foram focadas em
confiabilidade e portabilidade. O Postgres foi utilizado para diversos sistemas
40
de pesquisa e de produção, uma aplicação de análise financeira, um banco
com rotas de asteróides, e diversos sistemas de informações geográficas. O
código 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 padrões, ele é um
SGBD muito adequado para o estudo universitário do modelo relacional, além
de ser uma ótima opção para empresas implementarem soluções de alta
confiabilidade sem altos custos de licenciamento. É um programa distribuído
sob a licença BSD, o que torna o seu código fonte disponível e o seu uso livre
para aplicações comerciais ou não. O PostgreSQL foi implementado em
diversos ambientes de produção no mundo, entre eles, um bom exemplo do
seu potencial é o banco de dados que armazena os registros de domínio .org,
mantido pela empresa Afilias.
Alguns recursos presentes na versão mais recente.
• Sub-consultas;
• Controle de concorrência multi-versão (MVCC);
• Integridade Referencial;
• Funções armazenadas (Stored Procedures), que podem ser escritas em
várias linguagens de programação (PL/PgSQL, Perl, Python, Ruby, e
outras);
• Gatilhos (Triggers);
• Tipos definidos pelo usuário;
• Esquemas (Schemas);
• Conexões SSL.
• Áreas de armazenamento (Tablespaces)
• Pontos de salvamento (Savepoints)
• Commit em duas fases
41
• Arquivamento e restauração do banco a partir de logs de transação
• Diversas ferramentas de replicação
• Extensões para dados geoespaciais, indexação de textos, xml e várias
outras.
No jargão de banco de dados, o PostgreSQL utiliza o modelo cliente-
servidor. Uma sessão do PostgreSQL consiste nos seguintes processos
(programas) cooperando entre si. Um processo servidor, que gerencia os
arquivos de banco de dados, recebe conexões dos aplicativos cliente com o
banco de dados, e executa ações no banco de dados em nome dos clientes. O
programa servidor de banco de dados se chama postmaster.
O aplicativo cliente do usuário (frontend) que deseja executar operações
de banco de dados. Os aplicativos cliente podem ter naturezas muito diversas:
o cliente pode ser uma ferramenta no modo caractere, um aplicativo gráfico,
um servidor Web que acessa o banco de dados para mostrar páginas Web, ou
uma ferramenta especializada para manutenção do banco de dados. Alguns
aplicativos cliente são fornecidos na distribuição do PostgreSQL, sendo a
maioria desenvolvido pelos usuários.
Como é típico em aplicações cliente-servidor, o cliente e o servidor
podem estar em hospedeiros diferentes. Neste caso se comunicam através de
uma conexão de rede TCP/IP. Deve-se ter isto em mente, porque arquivos que
podem ser acessados na máquina cliente podem não ser acessíveis pela
máquina servidora (ou somente podem ser acessados usando um nome de
arquivo diferente).
O servidor PostgreSQL pode tratar várias conexões simultâneas de
clientes. Para esta finalidade é iniciado um novo processo para cada conexão.
Deste ponto em diante, o cliente e o novo processo servidor se comunicam
sem intervenção do processo postmaster original. Portanto, o postmaster está
sempre executando aguardando por novas conexões dos clientes, enquanto os
clientes e seus processos servidor associados surgem e desaparecem
(obviamente tudo isso é invisível para o usuário, sendo mencionado somente
para ficar completo). (MANUAL POSTRGEE, 2001)
42
Capítulo 3
Medição de Torque
A eficiência 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. É necessário que
exista um mecanismo de instrumentação que garanta eficiência e qualidade e
que propicie, na maioria das vezes, a segurança de todo equipamento e do
pessoal envolvido no processo (PREOBRAZHENSKY, 1980).
Torque ou momento de uma força é uma grandeza física associada a
o movimento de rotação de um corpo, em torno de um eixo, que resulta da
aplicação de uma força a esse corpo. O torque é definido a partir da
componente perpendicular ao eixo de rotação da força 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 rotação.
O torque se configura como uma das mais importantes características
dos parâmetros de máquinas de produção. Tendo em vista que os torquímetros
atuais não atendem a demanda social, existe uma necessidade de uma
solução em curto prazo no desenvolvimento de sensores de torque que tenham
uma larga faixa de atuação, alta definição, baixa depreciação com o tempo e
fácil instalação (MENG AND LIU, 2006).
Atualmente existem vários estudos relacionados à medição do torque
na indústria, envolvendo processos de desenvolvimento de peças, motores,
engrenagens e eixos, ligados a diferentes fins de produção, que envolvem
desde a área automobilística à aeroespacial.
43
Quanto à medição do torque especificamente de peças de seção
transversal circular, esta pode estar relacionada ou não ao movimento do corpo
em questão. Chama-se de torque estático, ou momento torcional estático
conjugado que tende a torcer peças que não se encontre em movimento de
rotação e, de modo análogo, o torque rotacional está ligado ao movimento de
rotação do eixo em questão. O torque rotacional na presença de aceleração
angular é chamado de torque dinâmico.
O torque exercido por uma mola, por exemplo, seria considerado um
torque estático. Enquanto que o torque transmitido através de um eixo na roda
de um carro que se movimenta a uma velocidade constante, seria um exemplo
de um torque estático, porque mesmo existindo um movimento rotacional do
eixo o mesmo não apresenta aceleração angular. O torque no eixo do redutor
de uma unidade de bombeio é um exemplo de torque dinâmico, já que a
velocidade de rotação do eixo varia de acordo com a carga nas hastes e ao
movimento dos contrapesos.
Atualmente existem instrumentos (torquímetros) bastante precisos,
dependendo da aplicação, para obtenção do torque estático, mas ainda
existem sérios desafios quando se deseja medir o torque dinâmico, uma vez
que o local de medição encontra-se em rotação, dificultando o acesso. Tendo
em vista que a maioria dos processos de conversão ou transferência de
energia utiliza dispositivos mecânicos rotativos, existe um grande interesse em
se obter um sistema de medição adequado, o que tem impulsionado vários
estudos. Porém, devido ao interesse financeiro nesta área por empresas do
ramo, a abordagem final do instrumento é lacrada para se impedir uma análise
técnica dos seus elementos constituintes, preservando o segredo industrial do
produto. O que reflete na ausência de publicações técnicas no que diz respeito
à arquitetura destes dispositivos (BRITO, 1994).
Os métodos utilizados para se realizar a medida do torque, aplicados
nos torquímetros existentes, são principalmente divididos em três categorias:
por absorção (HOLMAN, 1984), por extensômetros de resistência elétrica
(ERE) (CHEONG ET AL., 1999) e pelo ângulo de torção (NORTON, 1969).
44
Compreender o tipo de torque a ser medido, assim como os tipos diferentes de
sensores do torque que estão disponíveis, é de fundamental importância para
se obter uma boa exatidão e na escolha do método que atenda as
necessidades do projeto com menor custo. Além disso, no critério de seleção
do torquímetro dinâmico adequado, deve-se observar a faixa de atuação,
exatidão, frequência máxima de rotação, resistência às condições do ambiente,
capacidade de sobrecarga e circuito de transdução capaz de minimizar o ruído
na transmissão e saturação do sinal.
3.2 Sistemas de Automação de Unidades de Bombeio de Petróleo
A automação consiste em desenvolver sistemas automáticos pelos quais
algum mecanismo controle seu próprio funcionamento quase sem a
interferência do homem. (DICIONÁRIO AURÉLIO, 2000)
O bombeio mecânico é um método de elevação artificial em que uma
unidade de bombeamento é instalada na superfície, próximo à cabeça do poço,
para transformar movimento rotativo de um motor em movimento alternativo.
Este movimento alternativo é transmitido por meio de uma coluna de hastes de
aço, colocada dentro da coluna de produção, para uma bomba que está
localizada no fundo do poço. A bomba alternativa, localizada próximo ao fundo
da jazida, fornece energia ao petróleo para elevá-lo até a superfície.
O método de bombeamento mecânico mais utilizado no mundo para
extração de petróleo (80 % dos poços mundiais) apresenta um sério desafio no
que diz respeito ao torque excedido no eixo de saída do redutor. Não são 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 inutilizável, tendo em vista que o mesmo representa aproximadamente
50% do custo total de uma Unidade de Bombeamento Mecânico (UBM) é de
fundamental importância que se monitore o torque no seu eixo de saída
evitando a quebra do equipamento (THOMAS, 2004). Além do seu alto custo,
deve-se atentar que o tempo entre a quebra e a sua substituição pode
45
ocasionar em vários dias sem produção, o que deve ser evitado,
principalmente, em um mercado competitivo como o petrolífero.
O atual acompanhamento do torque na saída do redutor da unidade de
bombeio é feito através da API Specification 11E de 1994. De acordo com a
mesma, é bastante difícil identificar e oferecer soluções para todas as
influências que afetam a engrenagem redutora.
A análise experimental do torque no redutor é baseada na medida da
carga no cabresto que sai da cabeça da massa polida e do ângulo da manivela.
Para proteção da Unidade de Bombeio, a avaliação do torque de pico no
redutor deve ser relacionada com o torque de escavação (pitting), com a
avaliação do momento fletor e a medida do torque estático, conforme
determinadas fórmulas que se encontra na API Specification 11E. Esta
especificação define apenas a forma de cálculo através de parâmetros, não
trabalha com medições dos valores reais. (AMERICAN PETROLEUM
INSTITUTE, 1994)
Na equação de determinação do torque no eixo utilizada pela norma,
não se toma em consideração o desbalanço estrutural com a mudança 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 circunstâncias, os cálculos possuem uma margem de erro da ordem de
até 20%, criando, em alguns casos, uma grande distorção dos valores reais.
dos valores de torque e ângulo obtidos, é possível gerar uma carta
dinamométrica utilizando uma interpolação de valores. Essa carta determina os
picos de torque na subida e na descida da cabeça do cavalo, indicando os
possíveis pontos críticos para quebra da unidade.
3.2.1 Atual Modelo de Automação
Atualmente a automação das unidades de bombeio terrestre na maior
parte do mundo é realizada através de CLPs localizadas próximo às bombas
de extração. Essa automação 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 saída do eixo do redutor.
Para aquisição desses dados e controle da unidade, um sistema é
colocado próximo a bomba de extração. Esse sistema recebe dados analógicos
da célula de carga e do read switch localizados na bomba de petróleo. Um
esboço pode ser visualizado na figura 3.1.
Figura 3.1: Atual modelo de automação de bombas de petróleo
Os valores são recebidos pelo CLP através de fios e empacotados no
padrão ModBus, em seguida são disponibilizados em uma rede sem fios
localizada nos campos de extração de petróleo que possui uma antena ligada
ao controlador lógico. Essa rede ModBus é responsável 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 serão analisados e monitorados por profissionais
capacitados.
Além do empacotamento, o atual sistema pode receber um comando
também pelo protocolo ModBus para desativação da unidade por um
47
determinado momento. Isso se faz necessário para que a quebra da unidade,
devido a um torque muito elevado, seja evitada.
Um dos principais problemas encontrados com o atual método de
determinação de torque é o erro gerado a partir cálculo do valor de toque
obtido através da API 11E. Como através desse método o torque é calculado
através de alguns parâmetros e interpolação de dos valores, o resultado obtido
possui uma margem de erro de até 20%. Devido ao erro existente não é
possível determinar com precisão os valores de pico e da quebra do eixo do
redutor da unidade. Já em um torque medido diretamente no eixo é possível
obter um valor mais exato reduzindo a margem de erros para até 5%, como no
caso do torquímetro dinâmico telemétrico.
3.3 Torquímetro Dinâmico Telemétrico
Um torquímetro dinâmico telemétrico proposto por Lima Filho (2007),
Anjos et. al (2008) elimina os erros encontrados nas técnicas utilizadas e
desenvolvidas anteriormente com precisão e baixo custo. Este dispositivo já foi
testado em unidades de bombeamento terrestre de petróleo que se encontram
em funcionamento na PETROBRAS S.A.. Atualmente encontram-se em fase
de elaboração de um produto final para que seja adquirido pela empresa e
incorporado às unidades.
O torquímetro idealizado possui diversos tipos de aplicação, entretanto,
os torquímetros dinâmicos existentes no mercado não podem ser aplicados nas
medições do eixo de saída do redutor das Unidades de Bombeio. Isto se deve
principalmente a problemas encontrados na utilização de fios, de anéis
deslizantes e devido à indução eletromagnética. Então este torquímetro foi
desenvolvido para suprir essa deficiência.
O sistema funciona como no esquema mostrado na Figura 3.2. O sinal,
proveniente da deformação no eixo, captado pelo extensômetro é processado e
amplificado através do circuito de transdução eletrônica e enviado ao Módulo
Remoto Transceptor (MRT) localizado internamente ao módulo RF. No MRT o
sinal analógico é 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 freqüência de rádio. No Módulo Base Transceptor (MBT), já no RF
base, o sinal RF captado pela antena é, através do chip transceptor e do
microcontrolador, filtrado (passa-faixa de banda estreita), demodulado,
amplificado e disponibilizado em modulação por largura de pulso PWM (Pulse-
Width Modulation).
O sinal passa por um circuito integrador que disponibilizará a tensão
elétrica equivalente e em seguida um Loop de corrente AD 694 4-20 mA
fornece o sinal praticamente imune à ruído a uma caixa de controle de uma
UBM (Unidade de Bombeio Mecânico de Petróleo). Além disso o módulo base
também disponibiliza os dados de forma digital para leitura através de qualquer
dispositivo. A leitura do torque pode ser feita no próprio local de operação da
UBM ou transmitido para uma central de monitoramento.
Figura 3.2: Esboço do sistema de instrumentação por rádio freqüência
49
3.4 Torque Através dos Parâmetros Elétricos do Moto r e Perda da Correia
O redutor da unidade de bombeio atua reduzindo a velocidade do motor
e aumenta o torque na saída do redutor propiciando movimento alternativo para
extração do petróleo. Desta forma, medindo-se a potência entregue e a
freqüência de rotação na saída do redutor pode-se calcular o torque no eixo. A
medida da potência fornecida ao redutor pode ser conhecida a partir da
equação fundamental de potência média do motor.
Para se determinar a potência elétrica foram utilizados transformadores
de potência (TPs) e de corrente (TCs). A Figura 3.3 ilustra a disposição destes
elementos no circuito do estator do motor da unidade de bombeio estudada.
Figura 3.3: Leitura de tensão e corrente no primári o do motor
Os transformadores de potência foram interligados paralelamente às
bobinas de entrada do motor que se encontram na configuração estrela,
enquanto que os transformadores de corrente por efeito Hall foram
posicionados circundando os cabos de alimentação do primário do motor.
Para se determinar a velocidade angular do redutor foram utilizados
sensores de efeito Hall e imãs, que foram posicionados no eixo do redutor,
conforme pode ser visto na Figura 3.4 No mesmo eixo a posição da manivela é
detectada por ímãs de referência e pelo sensor de efeito Hall.
50
Figura 3.4: Medição da velocidade do redutor.
Além do sensor do eixo de saída do redutor foram utilizados mais dois
sensores de feito Hall: um no motor e outro na entrada do redutor. Foram
colados imãs na polia do motor e na polia da entrada do redutor e fixados os
sensores rente aos ímãs, conforme a Figura 3.5.
Figura 3.5: Medição da velocidade do motor.
O elemento de efeito Hall fornece um aumento de tensão em seus
terminais quando submetido a campos magnéticos, então cada vez que um
ímã se aproxima de um sensor sua tensão se eleva formando um pico. A
distância entre os imãs é constante e conhecida, portanto através do tempo
entre dois picos consecutivos se determina a velocidade angular.
Através da diferença entre a velocidade da polia do motor e a da
entrada do redutor têm-se como determinar as perdas na polia. Esta perda na
transferência de potência para o redutor indicará o rendimento das polias.
Para calibração do torque por este método é necessário que se saiba o
valor do torque da máquina operando sem carga. Então, o torque do eixo do
51
redutor será obtido através do valor do torque real do motor, menos o seu
torque operando em vazio.
O torque obtido é então relacionado com a posição da manivela
fornecida pelo sensor de efeito Hall.
Devido à condição de baixa velocidade no eixo de saída do redutor,
uma condição quase-estática, a potência mecânica desenvolvida no eixo do
motor elétrico mais a perda na correia será aproximadamente igual a potencia
mecânica no eixo do redutor. Baseado nestas suposições, o torque no eixo da
engrenagem redutora poderá ser determinado em função da potência
mecânica do eixo do motor e da perda da correia.
Quando existe um meio calibrador pode-se utilizar o método de
regressão linear para obtenção do torque baseado nos parâmetros elétricos.
Para a potência e conseqüentemente o torque na saída do redutor,
deverá ser incluído a velocidade de entrada do redutor (VR) e a velocidade do
motor (VM). Este parâmetro também é levado em conta no cálculo da perda da
correia. Desta maneira, através de uma regressão linear múltipla, faz-se a
calibração do torque. A fórmula abaixo determinaria o torque no redutor:
TREDUTOR = REG (v, i, VR, VM, T)
Onde: v e i são os valores de tensão instantânea e corrente elétrica e T é o
torque de referência.
3.5 Teste e Validação
A necessidade de validação do projeto e verificação de sua viabilidade
de implantação levou a elaboração de inúmeros testes. Os testes realizados
iniciaram utilizando protótipos desenvolvidos em laboratório, até chegar a
testes em campo utilizando verdadeiras UBMs. (ANJOS ET. AL, 2008)
3.5.1 Protótipos para obtenção de torque
Para que os testes com o Torquímetro Dinâmico Telemétrico fosse
possível, diversas bancadas foram projetadas e desenvolvidas nas
52
dependências do Laboratório de Energia Solar da UFPB. As bancadas
serviram inicialmente para testes de obtenção do torque estático e em seguida
o torque dinâmico que é o foco do novo torquímetro desenvolvido. Para simular
o torque exercido, processos de frenagem foram acoplados aos protótipos. As
Figuras a seguir mostram a evolução das bancadas de testes.
Figura 3.6: Bancada de testes para torque estático
Figura 3.7: Bancada de torque dinâmico com eixo par a frenagem
Figura 3.8: Protótipo com manivela e contrapeso
53
O último protótipo desenvolvido se assemelha a uma mini unidade de
bombeio e possui um redutor semelhante em menores proporções. Esta
característica foi de extrema importância para uma maior aproximação da
realidade. Observe na Figura 3.9 a manivela e a cabeça do cavalo.
Por fim, testes em uma verdadeira UBM foram realizados. As avaliações
foram feitas no campo de extração de petróleo da PETROBRAS na cidade de
Carmópolis em Sergipe. Neste campo centenas de unidades terrestres extraem
petróleo o tempo todo e a parada em uma unidade deve ser extremamente
calculada para que não ocorram muitas perdas na extração.
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 obtenção de torque através do cálculo das duas variáveis,
célula de carga e read switch. O sistema de testes não 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 utiliz ada para testes
3.5.2 Sistema de Testes e Validação
Para testes com o novo Torquímetro e validação desta proposta, um
sistema foi implantado na unidade de bombeio citada. Este sistema contém
dois conversores analógico-digital, um módulo ZigBee e um PC embarcado que
faz aquisição de todos os dados e os armazena para análises. (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, memória RAM de 1GBe encaixes PCI. Opera
entre 0 e 50ºC e 0 a 95% de umidade relativa do ar, entretanto como se
encontra dentro de um gabinete com coolers, pode suportar até 90ºC de
temperatura, ideal para operações ao ar livre. Entre outras características têm-
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 são desenvolvidos pela National Instruments
modelo NI-6008. Possuem oito canais de entrada analógica e uma resolução
de 12 bits. O conversor desenvolvido para o sistema embarcado final possui 12
bits, entretanto sua resolução pode ser aumentada, elevando a precisão dos
valores adquiridos.
Figura 3.12: Conversor A/D utilizado para testes
O Módulo ZigBee utilizado foi o XBee da empresa MaxStream. Seu
alcance em lugares com obstáculos chega a 300m e mais de 1Km em campos
abertos. Possui uma taxa de transmissão de 250Kbps e trabalha com uma
alimentação de 2.8 a 3volts e freqüência de 2.4 GHz. O módulo opera a altas
temperaturas, podendo suportar até 85°C. Possui 4 c anais com conversores
Disponível em:
http://www.cinelformacao.com
56
A/D embutidos de 10 bits de precisão que foram utilizados para aquisição de
valores de torque, temperatura e flexão no eixo. A imagem do módulo pode ser
visualizado na Figura 3.13.
Figura 3.13: Módulo ZigBee utilizado para testes.
O sistema de testes foi desenvolvido na linguagem G utilizando o
ambiente LabVIEW de programação, que é uma programação gráfica usada
para automação e medição que utiliza ícones em vez de linhas de texto. Sua
programação é baseada em fluxo de dados que determinam o caminho de
execução de uma aplicação. Possui rápida e fácil integração a diversos
dispositivos de comunicação, sendo, portanto fácil e prático para
desenvolvimento de testes. (RAHMAN, PICHLIK, 1999)
O conjunto Torquímetro/Sistema de testes foi dividido em duas unidades
para facilitar o trabalho. Uma unidade remota, localizada diretamente na
unidade de bombeio e responsável 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, módulo ZigBee, sensores,
etc. Os dados recebidos são disponibilizados para o PC através de interfaces
de comunicação USB e/ou serial.
A unidade remota contém o torquímetro com ZigBee acoplado e
sensores de efeito hall para determinação de outras formas de aquisição do
torque. Isto é necessário, pois em algumas unidades a instalação do
torquímetro se torna inviável, então uma forma alternativa de determinação de
torque, melhor que a já utilizada, deve ser proposta. Por isso parâmetros de
57
rotação, tensão e corrente do motor também foram adquiridos. A unidade fica
localizada dentro de uma abraçadeira, usada para proteção contra intempéries
como na Figura 3.14.
Figura 3.14: Abraçadeira contendo a unidade remota
A unidade base contém dois conversores A/D para recepção dos
parâmetros citados, um módulo ZigBee para receber os dados do torquímetro 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 dínamo
foi utilizado para geração de energia. O circuito criado aproveita a rotação do
eixo para gerar energia por indução que alimentará o circuito de transdução e o
ZigBee que são utilizados no sistema.
58
Figura 3.15: Unidade base usada para testes
O sistema localizado no PC executará três funções em paralelo para que
possibilite todas as aquisições ao mesmo tempo, provendo sincronismo nos
dados. Para facilitar o projeto e implementação, o mesmo foi desenvolvido em
três módulos que podem ser acessados através de uma interface comum
(Figura 3.16).
Figura 3.16: Interface do sistema MUB.
Os módulos desenvolvidos são:
Módulo de Aquisição: Neste módulo os dois conversores A/D e o módulo
ZigBee recebem os dados relevantes aos testes. O ZigBee nó final, localizado
no torquímetro, envia os dados para o ZigBee coordenador localizado na
Conversores A/D
Módulo
PC Embarcado
Sensores de corrente
Sensores de Tensão
Transformador 110v - 220v
59
unidade base. O sistema recebe os valores disponibilizados por esses três
dispositivos através de programação concorrente. A Figura 3.17 mostra a
interface do sistema de aquisição de dados chamado de DataMUB³.
Figura 3.17: Módulo de aquisição
Módulo de Tratamento: Aqui os dados já adquiridos são processados para
gerar os valores relevantes para estudo. Nesta etapa, valores de potência de
motor, torque e ângulo são disponibilizados para que possam ser visualizados.
O módulo é chamado de JoinFileMUB e pode ser visualizado na Figura 3.18.
Figura 3.18: Módulo de tratamento de dados
60
Módulo de Visualização: Módulo que provê ao usuário a capacidade de
visualizar através de gráficos todos os dados relevantes que foram adquiridos e
tratados. É chamado de MUBView e pode ser visualizado na Figura 3.19.
Figura 3.19: Módulo de visualização
3.5.3 Resultados Obtidos
Os testes realizados mostraram a viabilidade de se utilizar o novo
torquímetro, e deixam claro que a tecnologia atual é obsoleta para receber
suas funcionalidades, já que a velocidade de aquisição e outras
funcionalidades providas pelo torquímetro dinâmico não são atendidas por ela.
As cartas dinamométricas 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 através do
módulo de visualização. Na Figura 3.20 é possível observar o gráfico com
valores de torque obtidos por extensômetros e os gráficos referentes aos ímãs
que determinam a posição da manivela e a velocidade angular do eixo redutor
da UBM.
61
Figura 3.20: Sinais dos sensores de posição e exten sômetros.
A Figura 3.21 mostra um gráfico com valores de torque obtido dos
extensômetros e o ângulo da rotação da manivela gerado através do módulo
de tratamento. Assim, é possível determinar em que pontos da rotação o torque
é máximo.
Figura 3.21: Gráfico torque x ângulo
62
Na Figura 3.22 é possível observar o gráfico gerado por valores de
corrente e tensão e um gráfico com a potência calculada a partir desses
valores.
Figura 3.22: Gráficos de corrente, e potência calcu lada.
A partir do estudo realizado, foi possível determinar o torque também
através da potência do motor, mostrando-se como alternativa para as unidades
de eixo pequeno que não aceitam o torquímetro. Os valores de torque são
gerados utilizando os valores de potência, determinada a partir das três
tensões e três correntes provenientes do motor, e da velocidade angular.
Apesar do sistema final ser contemplado com um CAD que possui alta
taxa de aquisição (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 calibração 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 são adquidos os
dados do motor e um programa em LabView fornece a curva de torque. O
programa recebe os valores de tensão e corrente dos dados armazenado no PC
embarcado. O gráfico da Figura 3.23 mostra exemplos de curvas de tensão e
corrente correspondentes a um ciclo da manivela.
Figura 3.23: Medidas de corrente (branco) e tensão (vermelho)
Em seguida é obtida a potência instantânea 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 média, utilizada para o cálculo do torque,
observe que neste estágio ainda não foi feita a sincronização com o ângulo da
manivela, a abcissa é o número de aquisições.
Para determinação da velocidade do motor, velocidade e a posição da
manivela utiliza-se o sinal do efeito Hall. Então são inseridos no programa os
dados dos parâmetros elétricos do motor funcionando sem carga e se determina
o valor do torque nesta situação. Para o cálculo da potência transferida é
necessário que se determine o rendimento do motor e o rendimento de
transmissão de potência do motor para o redutor. O rendimento da
64
transferência de potência é calculado analizando a diferença de amplitude entre
as velocidades do motor e da entrada do redutor.
Figura 3.24 – Gráficos das potências ativa, reativa e aparente.
A Figura 3.25 ilustra as curvas de torque (em graus) pelos dois métodos
para um rendimento do sistema de 81%, apresentando um índice de correlação
de 81,4%. A curva em vermelho indica o torque a partir do motor, e a curva
branca, o torque a partir do extensômetro.
Figura 3.25: Curvas de torque pelos dois métodos.
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 freqüência na aquisição de
dados para que a curva ficasse mais otimizada. Além disso, no gráfico para
potência falta definir o valor dos parâmetros necessários para o cálculo da
velocidade angular para obtermos o gráfico referente aos valores de torque.
Isso tudo aperfeiçoa ainda mais este método de determinação de torque.
As Figuras a seguir contêm gráficos que mostram os valores de torque
no método da API e com a medição através de extensômetros e potência,
observe que algumas diferenças existentes nos gráficos se devem
principalmente a precisão dos métodos e devido ao fato de que as medidas
não foram obtidas na mesma rotação da unidade de bombeio. A comparação
dos métodos é primordial para demonstrar a viabilidade do projeto. Na Figura
3.27 é possível visualizar-se a curva de torque do antigo método.
66
Figura 3.27: Curva interpolada do antigo método de automação
Embora o gráfico obtido através do método antigo possua uma curva
bem definida, esses valores são interpolados através de uma função definida
pela API 11E. Isso deixa mascarado o erro existente. Na Figura 3.28 é
mostrada a curva de valores obtidos pelo extensômetro.
Figura 3.28: Curva de valores mais precisos obtida com extensômetros
No gráfico obtido através do torquímetro dinâmico, mesmo com poucos
valores na aquisição, já é possível visualizar algumas diferenças com os
valores da antiga forma de aquisição. Isso se deve a redução do fator de erro
existente em tal método. A curva ainda está menos atenuada que a anterior,
mas com uma elevação no número de pontos pode-se gerar uma curva mais
67
bem definida. Além disso, nesse gráfico não se utilizou nenhum método de
interpolação, o que geraria uma curva ainda mais perfeita.
No gráfico obtido através dos valores de potência, Figura 3.29 é possível
observar a semelhança com o gráfico dos valores de torque obtidos através de
extensômetros. Este gráfico pode ainda ser otimizado através do cálculo da
velocidade angular do motor, determinando assim os valores reais de torque
exercido na bomba.
Figura 3.29: Curva com valores referente à potência no motor
68
Capitulo 4
Sistema Embarcado para Automação
de Bombas de Petróleo
A necessidade de uma nova tecnologia para automação de bombas de
petróleo que viabilizasse o uso do torquímetro dinâmico telemétrico (Lima Filho,
2007) e Anjos (2008), levou a elaboração de uma proposta que utilizasse
sistemas embarcados e computação reconfigurável. A capacidade de
reconfigurabilidade permite que se utilize uma mesma arquitetura para várias
formas de automação, dentre elas a determinação do torque pelo torquímetro
dinâmico.
O sistema deve ser flexível na atualização de softwares, oferecer
possibilidades simples de expansão e ser de fácil manutenção. Diversas
tecnologias são incorporadas ao sistema tais como a transmissão de dados da
bomba para o sistema embarcado através de uma rede sem fios que é utilizada
no torquímetro dinâmico telemétrico. Embora o protocolo utilizado tenha sido
ZigBee (ZigBee Document, 2004), outros protocolos podem ser implementados
devido à característica de reconfigurabilidade. O módulo do protocolo ModBus
também pode ser substituído por outro protocolo. Além disso, a interface
Ethernet disponível permite que diversas outras tecnologias sejam acopladas
ao sistema.
O alto poder de processamento do sistema embarcado torna o sistema
capaz de realizar cálculos e funções que antes só poderiam ocorrer no sistema
central devido ao baixo poder de processamento dos microcontroladores
utilizados pelos CLP. A realização desses cálculos facilita a transmissão de
dados para a CIC devido à redução na quantidade de dados e permitem ao
69
sistema embarcado tomar decisões próprias em relação ao funcionamento do
sistema.
Outra vantagem da aplicação dessas tecnologias é a manutenção
preditiva que através de alguns parâmetros pode definir os estados atuais e
futuros de partes do sistema. Assim, torna-se possível uma previsão de tempo
até a quebra do redutor e a parada da bomba.
4.1 Arquitetura
A arquitetura de um sistema embarcado é uma abstração dos seus
dispositivos, o que significa que é uma generalização do sistema que
normalmente não mostra informações detalhadas de implementação, como o
código fonte do software ou os projetos de circuitos do hardware. No nível
arquitetural, os componentes de hardware e software em um sistema
embarcado são representados como composição de alguns elementos que
interagem entre si. Elementos são representações de hardware e/ou software
cujos detalhes de execução tenham sido abstraídos, deixando apenas
comportamentos de interdependência de informação. Eles também 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 relações
entre os elementos interativos. (NOEGARD, 2005).
O que torna a abordagem de uma arquitetura de sistemas embarcados
tão poderosa e importante é a sua capacidade para informalmente e
rapidamente se comunicar com um projeto através de uma grande variedade
de pessoas com ou sem antecedentes técnicos, mesmo agindo como um
alicerce no planejamento do projeto ou realmente conceber um dispositivo.
Uma arquitetura pode agir como uma base sólida para analisar e testar a
qualidade de um dispositivo, bem como o seu desempenho em diversas
circunstâncias, pois define claramente os requisitos do sistema.
70
O modelo arquitetural utilizado para este trabalho foi apresentado por
Noergaard (2005). Este padrão define uma formação típica de um sistema
embarcado dividido em camadas interdependentes: camada de hardware,
software e aplicação, 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 aplicação tornando essas
camadas opcionais para determinadas implementações. Embora dispensáveis
como na arquitetura de Noergaard, essas camadas são bastante importante
para se obter as vantagens da modelagem arquitetural.
Figura 4.1: Modelo arquitetural de um sistema embar cado
4.1.1 Camada de Hardware
A arquitetura proposta define uma camada de hardware, representada pela
plataforma Nios II e demais módulos físicos, para que seja fornecido suporte ao
funcionamento da camada de software. Nesta camada estão 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 Analógico/Digital (CAD)
71
• Conversor Digital/Analógico (CDA)
• Módulo de Comunicação por Frequências de Rádio ZigBee
• Módulo de Empacotamento e Comunicação ModBus
Dentro do chip FPGA destacamos a plataforma Nios II e os
controladores do módulo ZigBee e do CAD. Constituem a plataforma Nios II os
seguintes componentes: núcleo do processador Nios II, barramento interno
Avalon, módulo JTAG (Join Test Action Group) UART, memória interna,
módulo de Ethernet MAC (Media Access Controller), memória externa,
controlador USB, Controlador ZigBee, controlador ModBus, controlador serial,
controlador ADC e os módulos PIO (Parallel Input/Output). Finalmente, a
camada de hardware é uma composição de todos os elementos enunciados
acima.
Figura 4.2: Camada de hardware
4.1.2 Camada de Sistema de Software
Seguindo o modelo de referência apresentado, a camada de sistema de
software (Figura 4.3) é subdividida em drivers de dispositivos, sistema
operacional e middleware. Inicialmente, cada periférico 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 nível
72
de abstração ao fornecer uma biblioteca de funções 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 funções 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 físicas, a camada IP pode ser configurada como uma máquina
cliente padrão, um roteador IP ou um servidor. Pode também atuar como um
poderoso acessório para empacotamento na rede onde diversos padrões estão
inclusos tais como: FTP, Telnet, DNS, DHCP, IGMPv1 e IGMPv2.
Da necessidade de utilização de múltiplos processos de software
executando concorrentemente, a arquitetura proposta utiliza o sistema
operacional µC/OS-II. Ele é fornecido em uma versão 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 importância dentro do
sistema proposto. Nesse sentido, ela oferece um serviço à camada de
aplicação, configurando-se como um middleware. Utilizou-se a nichestack, uma
implementação simplificada dos protocolos que compõe o TCP/IP, própria 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 é distribuída com o código fonte completamente
desenvolvido em ANSI “C” e também inclui o NicheTool, uma das melhores
ferramentas para depuração e otimização de código para pilhas TCP/IP
existente no mercado.
4.1.3 Camada de Aplicação de Software
Na aplicação, nove itens implementam as funcionalidades do sistema.
São elas:
• Recebimento de torque,
• Ângulo de rotação,
• Tensão,
• Corrente,
• Conversão analógico/digital,
• Desempacotamento do protocolo ZigBee,
• Manipulação dos dados,
• Empacotamento e envio ModBus.
O Funcionamento da camada de aplicação segundo um diagrama de
fluxo de dados (DFD) pode ser visualizado na Figura 4.4. Neste diagrama os
processos são mostrados seqüencialmente como acontecem no sistema, assim
é possível ter uma visão detalhada do seu funcionamento. (ANJOS, ET. AL.,
2008)
74
Figura 4.4: Camada de aplicação
A seguir é especificado um roteiro dos acontecimentos do sistema na
camada de aplicação:
75
• Os dispositivos de aquisição de dados fazem a leitura dos valores na
unidade de bombeio de petróleo como: torque no eixo, ângulo de
rotação, corrente e tensão no motor, etc.
• Os dispositivos de aquisição podem ser módulos ZigBee ou CADs,
dependendo da aplicação. 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, cálculos de torque, potência aparente ou
outros, são realizados sobre os dados recebidos. Isto ocorre para que
sejam determinados os valores de torque, ângulo, potência,
velocidade, etc.
• Os dados calculados são convertidos para o protocolo ModBus ou, se
preciso, pode ser facilmente adaptado para outro protocolo.
• O sistema embarcado envia os pacotes ModBus pela saída Ethernet
se comunicando com o CIC (Central Integrada de Controle).
4.2 Componentes da Arquitetura
A seguir será apresentada uma breve descrição dos componentes
presentes na arquitetura citada. Alguns componentes podem ser encontrados
no kit de desenvolvimento Nios II Altera. Outros foram desenvolvidos e
incorporados à arquitetura através do software SOPC Builder, utilizado para
customização de arquitetura embarcada e disponível na plataforma de
programação Quartus II.
4.2.1 PIO (Parallel input/output)
O módulo 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 possível uma
customização do sistema através da escolha de dispositivos e sinais de
interface para a placa de desenvolvimento. O código fonte do PIO está
76
disponível em Verilog HDL ou VHDL para possibilitar o desenvolvimento e
inclusão de subrotinas de software necessárias a uma fácil integração do
sistema.
A utilização de módulos PIO permite que controladores ou outras
funcionalidades desenvolvidas para a arquitetura do sistema sejam
incorporadas à arquitetura do processador Nios II. Dessa forma não é
necessária uma comunicação diretamente com o barramento Avalon do
sistema.
A utilização dessa abstração para facilitar o desenvolvimento foi possível
devido a baixa velocidade de atuação do sistema ser lenta em relação ao poder
de processamento do Kit de desenvolvimento. Em situações em que a
velocidade de comunicação seja crucial, é possível utilizar-se o barramento
Avalon através de uma ligação direta com os controladores, não existindo os
PIO.
4.2.2 JTAG Uart
O controlador JTAG Uart junto a interface Avalon, implementam um
método de comunicação serial através de fluxos de caracteres entre o
computador, utilizado para desenvolvimento, e o sistema SOPC Builder na
FPGA Altera. Na maioria dos projetos, o núcleo JTAG Uart elimina a
necessidade de separar a conexão serial RS-232 com o PC para caracteres de
entrada e saída. Este controlador provê uma integração com o barramento
Avalon que esconde a complexidade das interfaces JTAG para programadores
de softwares embarcados. Periféricos se comunicam com esse controlador
através do controle de leitura e escrita nos registradores de dados.
Através do módulo JTAG Uart é possível enviar o software embarcado
para a FPGA e, além disso, pode-se monitorar e até mesmo depurar, todo o
funcionamento do sistema através do PC de desenvolvimento já que a interface
JTAG Uart tanto escreve como lê dados.
77
4.2.3 Núcleo Nios II
Nios II é um processador 32 bits soft-core de arquitetura embarcada
projetado especificamente para a família de FPGAs Altera. Nios II incorpora
muitas melhorias em relação à arquitetura original Nios, tornando-o mais
apropriado para uma larga faixa de aplicações que utilizam computação
embarcada, desde processadores de sinais digitais (DSP) a sistemas de
controle.
4.2.4 Ethernet MAC
O controlador de Ethernet MAC implementa uma comunicação no
padrão Ethernet entre o barramento Avalon e a interface disponível no Kit de
desenvolvimento. Através desse controlador é possível enviar os dados
empacotados no protocolo desejado e disponibilizados através do socket de
comunicação.
4.2.5 Controlador SDRAM
O controlador SDRAM através da interface Avalon, provê uma interface
mapeamento de memória 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 padrões
SDRAM como os descritos na especificação PC100.
SDRAM são comumente utilizadas em aplicações de baixo custo e
muitas memórias voláteis. Enquanto a SDRAM é relativamente barata,
controladores lógicos são necessários para executar operações de refresh e
outros atrasos e sequência de comandos. O controlador SDRAM conecta um
ou mais chips e agrega todos os protocolos necessários. Internamente, na
FPGA, o núcleo apresenta uma porta Avalon-MM que aparece como memória
linear para periféricos mestres Avalon-MM.
O núcleo pode acessar subsistemas SDRAM com barramentos de dados
de tamanhos variados (8, 16, 32 ou 64 bits), diversos tamanhos de memórias e
muitos tipos de chip. O núcleo também pode, opcionalmente, compartilhar
78
endereços e barramento de dados com outros chips. Este recurso é útil em
sistemas que tem pinos de entrada e saída limitados, e ainda devem se
conectar a múltiplos chips memória além da SDRAM.
4.2.6 Controlador USB
Embora os kits de desenvolvimento da Altera mais recentes possuam
portas USB disponíveis no kit utilizado não existe interfaces disponíveis, então,
desenvolveu-se um controlador em VHDL para que fosse possível a sua
utilização. No controlador USB desenvolvido utilizou-se a linguagem VHDL
para criação dos códigos de transmissão e recepção, depois disso o
controlador foi incorporado à arquitetura do sistema e assim pode ser acessado
através de funções em C disponibilizadas pela biblioteca HAL.
O controlador pode ser utilizado através dos pinos reserva que são
disponibilizados na placa de desenvolvimento. O código fonte projetado foi para
um chip USB da DLP Design (DLP-USB245M USER MANUAL, 2002),
entretanto, através de uma mudança no código VHDL é possível criar-se
controladores para outros chips de USB ou até mesmo outros controladores.
Na Figura 4.5 é possível visualizar o diagrama de blocos indicando como
funciona a comunicação entre o módulo PIO da arquitetura Nios e o chip USB
da DLP Design. Essa comunicação é realizada pelo controlador USB
desenvolvido em VHDL e incorporado à arquitetura.
Figura 4.5: Diagrama de blocos de comunicação entre PIO e USB
79
A comunicação entre o módulo DLP e o controlador USB ocorre como
mostrado na Figura 4.6. Os pinos WR e RD são 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 transmissão está cheia ou se a FIFO de recepção está
vazia, respectivamente. O DLP-USB245M é dotado de um cristal de quartzo
com freqüência de 6MHZ. Através dele é possível disparar os ciclos de leitura e
escrita.
Figura 4.6: Comunicação entre a interface USB e o c ontrolador USB
O sinal RXF indica quando a FIFO está pronta para ser lida, ou seja, há
no mínimo 1 byte na FIFO (RXF = 0). Jogando o sinal RD para zero, faz-se
com que os dados existentes no buffer de recepção sejam lidos. Para a
captação desses dados, o sinal de RD dever permanecer em zero por no
mínimo 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 Descrição Mínimo Máximo
T1 Largura do pulso ativo do RD 50 ns
T2 Tempo de carga do RD 50 ns
T3 RD está ativo para validação de dados 30 ns
T4 Tempo de espera de dados válidos 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 transmissão é feita através do
barramento D[7..0] e do sinal WR. O dado presente no barramento é escrito na
FIFO na transição 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 Descrição Mínimo Máximo
T7 Largura do pulso ativo do WR 50 ns
T8 Tempo de carga do WR 50 ns
T9 Tempo de configuração 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 módulo PIO interno a plataforma Nios II possui os sinais necessários a
conexão com o módulo controlador da USB, que por sua vez faz a interface
com o dispositivo DLP. Desses sinais, 4 são de entrada (TXE_n, transmitido,
dados_in e RD_n) e 3 são de saída (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 abstração de
leitura e escrita já que transforma o barramento bidirecional do DLP em dois
82
barramentos distintos para comunicação com a PIO, sendo um para leitura e
outro para escrita (dados_in e dados_out, respectivamente). Essa abstração é
necessária para o correto funcionamento do barramento bidirecional,
diretamente através do software embarcado. Na Figura 4.9 é possível visualizar
um diagrama de fluxo indicando a lógica 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 não poderá escrever se estiver
lendo, devido ao barramento bidirecional. Em seguida, é feita uma verificação
se o sinal TXE_n é igual a zero. Essa comparação objetiva saber se o
controlador USB terminou de fazer leitura do dispositivo DLP, pois só será
possível 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
operação de escrita. O controlador USB deverá atribuir 0 ao sinal transmitido,
permanecendo assim até o fim da operação. Assim, quando esse sinal voltar
para 1, significa que a transmissão do byte foi realizada. Para finalizar a escrita,
coloca-se o sinal transmite_n em 1.
83
Figura 4.9: Algoritmos de transmissão e recepção de dados pela USB
Já para a leitura do barramento dados_in, o algoritmo é o seguinte:
primeiramente, é necessário indicar ao controlador USB que inicie a leitura da
fila do dispositivo DLP. Para tanto, coloca-se o sinal leitura_fifo em 1. Então,
espera-se que o controlador faça a leitura do byte. Primeiro, o sinal RD_n deve
ir para 0 indicando início da operação de leitura. Depois, deve ir para 1
indicando seu término, quando, então, pode-se ler do barramento dados_in o
byte desejado. Para finalizar a operação 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 mudança de protocolo
para outros projetos e também pela fácil mutabilidade já que não interferia
diretamente na arquitetura do sistema.
84
Através do controlador ZigBee, os dados recebidos através da unidade
ZigBee são 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 funções requisitadas pelo
mesmo.
4.2.8 Controlador Serial
O núcleo UART com a interface Avalon implementa um método para
comunicação serial através de streams de caracteres entre sistemas
embarcados na FPGA Altera e dispositivos externos. O núcleo implementa o
protocolo RS-232 e disponibiliza taxa de dados ajustável, paridade,bits de
dados e de parada e opcionalmente sinais de fluxo de controle RTS/CTS. Este
conjunto de características é configurável, permitindo aos projetistas
implementarem apenas as funcionalidades necessárias para determinado
sistema.
4.2.9 Controlador ADC
O controlador ADC foi desenvolvido para atuar diretamente nos dados
recebidos através do conversor desenvolvido em laboratório para o projeto. O
controlador foi desenvolvido em VHDL e incorporado à arquitetura. O ADC
recebe os dados analógicos do ambiente, converte-os para digital com 12 bits
de precisão e os disponibiliza para o sistema embarcado através dos pinos
existentes no kit de desenvolvimento.
4.3 Implementação do Empacotador MODBUS
O empacotador ModBus atuará nos dados tratados na FPGA,
disponibilizando-os em interfaces de comunicação já convertidos no formato
desejado. Os dados contendo os valores das aquisições 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 extração aceita entradas de dados já empacotados em formato
ModBus através de uma entrada serial o que facilitou os testes iniciais.
A outra forma, utilizada no protótipo final, usa o protocolo ModBus TCP.
A utilização desse tipo de implementação se deve a possibilidade de
reutilização de transmissores de freqüências de rádio de alta potência, 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 estão
em uso perderão sua funcionalidade podendo ser substituídas pelo novo
sistema reconfigurável, mais robusto, expansível 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
hipóteses de implementação foram levantadas: Implementação em Software e
Implementação em Hardware. Em Hardware, o sistema desenvolvido ficaria
dentro da FPGA, independente do sistema Nios II, já na implementação em
software, o sistema atuaria de uma maneira bastante simples e usando o
processamento disponibilizado pelas tecnologias utilizadas (como processador
Nios II, memórias, etc.), inseridas no sistema embarcado.
Para definir qual a melhor forma de implementação estudos e testes
foram desenvolvidos através de simuladores e de implementações em FPGAs.
Estes estudos dimensionaram as características de cada implementação,
86
distinguindo vantagens e desvantagens de cada uma. Assim, optou-se pela
implementação em software, principalmente pela facilidade de mudança para
outros tipos de protocolos.
A implementação em software traz uma enorme vantagem que é a
possibilidade de desenvolvimento na linguagem C/C++, facilitando e
acelerando o desenvolvimento e mudanças de código. Entretanto torna o
processamento um pouco mais lento que para a aplicação desejada não
impediu o funcionamento satisfatório do sistema.
O protocolo MODBUS/TCP basicamente inclui um pacote ModBus
dentro de um pacote TCP de uma maneira simples. Esta é uma transação
orientada à conexão na qual toda solicitação espera uma resposta. Esta
técnica de solicitação/resposta se adéqua bem com a natureza mestre/escravo
do ModBus, adicionando a isso a grande vantagem que o padrão Ethernet
oferece na utilização industrial. O uso do Open ModBus dentro de um pacote
TCP provê uma solução totalmente escalável de dez a dezenas de milhares de
nós na rede sem o risco de comprometer outras técnicas 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 endereço
do mestre ou escravo (dependendo se for solicitação ou resposta) o código da
função que será realizada e os dados necessários. Como em nosso sistema
apenas utilizamos um mestre e um escravo, simplificamos o pacote ModBus
retirando o campo de endereço. Observe que isso não afeta o funcionamento
do protocolo, entretanto para uma rede de mais nós é necessário que seja
87
reprogramado essa característica que pode ser implementada devido à
reconfigurabilidade já citada.
Para confirmar o recebimento também faz-se necessário que o mestre
(aquele que requisitou o serviço) 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, são
mostrados os pacotes ModBus criados e utilizados para o projeto. Cada pacote
possui seis caracteres hexadecimal onde os dois primeiros indicam a função
ModBus e os quatro últimos indicam os dados referentes à função. Não foi
utilizado o campo endereço pelo fato de todos os testes terem sido feitos
somente com um mestre e um escravo.
PACOTE FUNCIONALIDADE
Aquisição de uma Quantidade Pré-Definida de Dados
7AXXXX
Mestre: Solicita aquisição de dados da unidade de bombeio
através de uma quantidade definida através do valor XXXX
que são números hexadecimais. Ex: Mestre solicita 10
aquisições 7A000A
Escravo: Retorna o valor adquirido da unidade de bombeio
através das 4 variáveis hexadecimais. Ex: 7A001F, 7A0020,
7A001D...
Aquisição de Dados por Tempo Indeterminado
7BFFFF
Mestre: Solicita aquisição constante ao escravo. Nesta
função o escravo manda os dados adquiridos
constantemente até que um comando de parada seja
enviado.
7BXXXX Escravo: Envia através das 4 variáveis XXXX os valores
adquiridos durante a aquisição constante.
Parar Aquisição Quando Estiver Constante A11000 Mestre: Solicita o cancelamento da aquisição constante.
A11001 Escravo: Avisa ao mestre que a solicitação de parada não
foi realizada porque o sistema não se encontrava em
88
aquisição constante.
A11002 Escravo: Avisa ao mestre que a aquisição constante foi
parada com sucesso.
A11003
Escravo: Avisa ao mestre que a aquisição constante não
está sendo realizada porque o sistema não está adquirindo
no momento ou a bomba está desligada.
Desligamento da Bomba de Petróleo
A21000 Mestre: Solicita a parada da bomba de petróleo, 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 petróleo, 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 automática da
bomba. Isso permite ao sistema desligar ou diminuir a
rotação do motor da bomba se uma situação crítica for
encontrada.
A23001 Escravo: Parada automática configurada com sucesso.
A24000
Mestre: Solicita o cancelamento da parada automática da
bomba tornando a parada manual, entretanto, se uma
situação crítica for encontrada o escravo sempre avisará ao
mestre.
A24001 Escravo: Informa ao mestre que a parada automática foi
cancelada.
A25001 Escravo: Avisa ao mestre que uma situação crítica foi
encontrada na bomba mas que não havia permissão para
89
resolver a situação. Este aviso deixa a cargo do mestre
(usuário) a decisão que será tomada.
A26001
Escravo: Informa que uma situação crítica foi encontrada e
que a bomba foi desligada ou reduziu a rotação do motor
para evitar acidentes ou situações indesejáveis.
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 conexão com o escravo.
Tabela 4.3: Pacotes ModBus criados para controle da s UB.
4.4 Funcionamento do Sistema
Para um funcionamento adequado do sistema, o processador se utiliza
da memória interna para armazenamento de dados e instruções com um tempo
de resposta bastante pequeno, já que a comunicação 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 são:
Obtenção de Dados: O processo inicial do sistema, que se localiza ainda na
camada de aplicação, é obter os dados referentes aos dispositivos de hardware
externos à FPGA. O módulo ZigBee disponibiliza em seus pinos de saída os
pacotes de dados recebidos através das ondas de rádio. Ou, para outro caso, o
conversor A/D disponibiliza os dados adquiridos de tensão e corrente.
Tratamento de Dados: Como mostrado anteriormente, a utilização do CAD ou
do módulo ZigBee dependerá da unidade de bombeio a ser utilizada. A
princípio a transmissão via rádio freqüência será adotada, menos nas bombas
de pequeno eixo que não possuam espaço para acoplamento da abraçadeira,
neste caso os dados do motor adquiridos pelo conversor serão necessários.
Isso reforça a vantagem de utilização de um dispositivo reprogramável.
90
Envio de Dados: Após o recebimento e armazenamento dos dados os mesmo
são processados para se obter as medidas desejadas. Este tratamento nos
dados torna-os propícios a serem enviados através do protocolo MODBUS. Na
etapa de testes, os dados foram enviados para a CLP já existente nos campos
próximo a UB, através de uma freqüência muito baixa, entretanto na etapa final
deste projeto a interface Ethernet foi utilizada enviando diretamente para a
antena ModBus, sem utilização da CLP. Com o uso do ModBus TCP, uma das
melhorias existentes neste protocolo, os dados são transmitidos através de
redes sem fios de alta potência para a estação de controle dos campos de
extração, denominada Central Integrada de Controle (CIC).
Cada módulo de aquisição possui um controlador específico que é
gerenciado para que os dados possam ser adquiridos. Os controladores
desenvolvidos se comunicam com os módulos PIO do sistema abstraindo
bastante o desenvolvimento de código, pois não é necessária uma
comunicação direta com o barramento Avalon. Estes módulos PIO são de
extrema importância na implementação do sistema processado, pois os
mesmos oferecem portas de entrada e de saída, estabelecendo uma
comunicação entre a plataforma Nios II e os blocos do sistema.
4.5 Circuito ZigBee de Recepção
Para utilização do módulo ZigBee na recepção de dados, uma interface
foi desenvolvido para acoplar o módulo e disponibilizar os dados através de
barramentos desenvolvidos. O ZigBee que está sendo utilizado é o Xbee da
MaxStream. Este dispositivo possui 20 pinos que serão utilizados para integrar
ao circuito. Os dados recebidos pelo módulo base são disponibilizados já na
forma serial através do pino 2. O dispositivo ZigBee contém um
microcontrolador para processamento de dados e também um módulo ZigBee
que empacota/desempacota os dados no protocolo ZigBee. Um diagrama de
comunicação entre os dois dispositivos pode ser visualizado na Figura 4.12.
91
Figura 4.12: Diagrama de transmissão ZigBee.
Após recebidos, processados e empacotados, os valores são enviados
de um dispositivo ZigBee para outro. Os valores podem então ser enviados
para a FPGA que receberá em seus pinos os pacotes no formato ZigBee. Os
pacotes e algumas características inerentes ao dispositivo possuem um padrão
já determinado através de normas estabelecidas no manual. Assim é possível
ler os valores contidos no pacote e transformá-los adequadamente, tornando-
os suscetíveis ao empacotamento MODBUS.
O circuito desenvolvido para receber o módulo ZigBee foi ligado ao Kit
de desenvolvimento da Altera® para a fase de testes. Essa comunicação se
dá através de pontos de conexão 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 elétrico da mesma na figura
4.15. Através desse software foi possível realizar todo o desenho elétrico que
depois foi impresso em uma placa feita de fenolite. Uma das placas
desenvolvidas contendo o módulo ZigBee que ficará dentro da abraçadeira no
redutor da bomba de petróleo é mostrada na Figura 4.16.
92
Figura 4.13: Modelo P-CAD da placa de recepção ZigB ee
Figura 4.14: PCB contendo modelo de placa de recepç ão ZigBee
93
Figura 4.15: Esquema elétrico da placa de recepção ZigBee.
Figura 4.16: Protótipos com o circuito de recepção e o módulo ZigBee
94
CAPÍTULO 5
Ferramentas e Metodologia
A metodologia utilizada para este trabalho consiste na divisão dos
processos em etapas. Desta forma, tem-se uma estrutura consistente que
serve de guia durante a personalização de um sistema (ALTERA, 2004). Nas
etapas inicias fora realizados estudos de tempo e hardware necessário para
desenvolvimento e implementação do sistema. Após essa fase iniciaram-se os
estudos referentes a cada dispositivo e tecnologia utilizada para que facilitasse
sua utilização.
O processo de implementação foi orientado pelas necessidades do
sistema, embora algumas poucas mudanças tenham sido necessárias em
relação aos modelos de projeto criados. Durante essa etapa foram necessárias
comparações, estudos de caso e verificação de aplicações em áreas similares
para que as melhores decisões pudessem ser tomadas e a proposta se
aproximasse cada vez mais do que foi desejado.
No processo de diagramação e engenharia de requisitos foram
abordados todos os principais focos do projeto. Os diagramas UML elaborados
servem como base para um desenvolvimento satisfatório do sistema. A
elaboração de tais diagramas foi norteada pelas necessidades que foram
sendo percebidas no sistema de testes. Os modelos devem produzir uma visão
abrangente da realidade, mostrando todos os fatores envolvidos e todos os
relacionamentos, existentes ou não, entre eles. Estes diagramas são
detalhados no Apêndice II desta proposta.
95
5.1 Softwares Utilizados para Desenvolvimento
Para desenvolvimento foi utilizada a plataforma de programação Quartus
II. O software Altera Quartus II fornece um completo ambiente de projeto
multiplataforma que se adapta facilmente às necessidades específicas de
concepção. Trata-se de um ambiente global para projetos de sistema em chips
programáveis (system-on-a-programmable-chip - SOPC). O software Quartus II
versão 8.0, inclui soluções para todas as fases de projetos de FPGAs e CPLDs.
Além disso, o Quartus II permite que você use o a interface gráfica e interface
de linha de comando para cada fase do fluxo de projeto.
5.1.1 SoPC Builder
O desenvolvimento teve início com a customização do processador Nios
II através do SoPC Builder que é uma ferramenta exclusiva do Quartus II.
Através dele é possível construir uma arquitetura embarcada de maneira forma
prática.
O SoPC Builder é uma ferramenta da Altera integrada ao Quartus para
automatizar a criação de sistemas compostos por diversos cores como
processadores, co-processadores, periféricos, memórias e lógicas de usuários
baseados em barramentos. Um componente SOPC Builder é um projeto cujo
módulo SOPC Builder reconhece automaticamente e pode integrar um sistema.
Podem ser também definidos e adicionados componentes personalizados. O
SOPC Builder conecta múltiplos componentes em conjunto para criar um
arquivo HDL de nível mais alto chamado módulo do sistema. Ele gera o
sistema de interconexão que contém a lógica 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
lógica de interconexão ao barramento especificado. O barramento utilizado
neste projeto é o Avalon. Sua biblioteca de componentes inclui itens como:
• Processadores;
• Microcontroladores Periféricos;
• Digital Signal Processing (DSP) cores;
• Intellectual Property (IP) cores;
• Periféricos de Comunicação;
• Interfaces:
– Memórias (on-chip ou off-chip);
– Barramentos e Pontes;
– Application-Specific Standard Products (ASSPs);
– Application-Specific Integrated Circuits (ASICs);
• Componentes de Software:
– Arquivos header;
– Drivers Genéricos em Linguagem C;
5.1.2 Plataforma de Desenvolvimento de Software Nio s II
O ambiente de desenvolvimento integrado (IDE) Nios II é a principal
ferramenta para o desenvolvimento de software para a família 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 características esperadas de um
ambiente de desenvolvimento de projetos de software profissional (gestor de
projeto, editor código, depurador, etc.), mas também oferece recursos
adicionais para aumentar a produtividade em FPGA baseado no
desenvolvimento do sistema. (ZAMMATTIO, 2006). Estas incluem:
98
• Importação de todos os parâmetros de hardware relevantes para o
ambiente de software
• Geração de uma biblioteca ANSI "C" que é customizado para o sistema
de hardware
• inclusão automática e configuração dos controladores de periféricos
• Funções ANSI "C" e UNIX para auxiliar classes de dispositivo padrão
• Um framework pré-definido para a criação de controladores de
periféricos que são captadas a partir de dependências de hardware
Quando o sistema de hardware é criado, a ferramenta SOPC Builder
grava todos os parâmetros do sistema em um formato de arquivo de texto
simples (*.ptf). Este arquivo contém informações sobre a configuração 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 localização do
arquivo .ptr no sistema. A informação contida neste arquivo é então usada para
criar um ambiente de desenvolvimento de software adaptado para
corresponder ao processador e a configuração do sistema.
Um arquivo chamado system.h é criado após a análise do arquivo .ptr. O
system.h contém toda a informação relevante de hardware para o processador,
periféricos e configuração do sistema, sob a forma de declarações #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 aplicação desenvolvida. Por
exemplo, o IDE constrói uma biblioteca ANSI 'C', com base no código fonte da
newlib, que foi adaptado para corresponder à configuração do processador; isto
é muito importante para características como sistema de inicialização,
interromper handlers e gerenciamento de código em cache. As funcionalidades
e relacionamentos do Nios II IDE podem ser vistas na Figura 5.3.
(ZAMMATTIO, 2006)
99
Figura 5.3: Visão das funcionalidades do Nios II ID E
A fim de delimitar claramente a aplicação e o código do sistema de
hardware específico, o Nios II IDE cria dois subprojetos, um projeto de
aplicação e um projeto de biblioteca do sistema. O projeto de aplicação é
usado pelo desenvolvedor para adicionar e gerenciar os arquivos usados para
criar a aplicação. O sistema de biblioteca contém todo o hardware específico
para as funções 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 programação
C/C++, independentemente das características de hardware subjacentes ao
sistema e separa o código da aplicação do código 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
aplicação (API) HAL está integrada com o padrão ANSI C e permite o acesso à
biblioteca e dispositivos periféricos e arquivos usando biblioteca e funções
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: Abstração de hardware do sistema de bib liotecas HAL
O sistema de bibliotecas HAL provê os seguintes serviços:
• Integração com a biblioteca newlib do padrão ANSI C (Funções
Familiares da biblioteca padrão;
• Drives de dispositivos periféricos (Acesso a todos os dispositivos
periféricos do sistema);
• API HAL (Provê um consistente padrão de estilos de interfaces UNIX
para os serviços HAL);
• Inicialização do sistema (Executa as tarefas de inicialização para o
processador);
• Inicialização de dispositivos (Instancia e inicializa os dispositivos no
sistema antes do main( )).
5.2 Interface USB
A interface de comunicação USB utilizada foi criada pela DLP Design
que possui baixo custo e uma alta usabilidade na construção 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 método fácil e eficaz na transmissão de dados entre o
host e o controlador. (DLP-USB245M USER MANUAL, 2002)
Figura 5.5: DLP-USB245M.
Em sua composição consta um de uma EEPROM de referência 93C46 e
outro chip de nome FT245BM cuja fabricação pertence à FTDI (Future
Technology Devices International Ltd). A EEPROM possibilita a customização
de parte da configuração básica da interface, como a taxa de transmissão e a
forma de comunicação, informações como o PID e VID da interface USB, bem
como seu número serial. O responsável por implementar uma FIFO tanto de
leitura como de escrita que utiliza os 8 bits do barramento de comunicação de
forma bidirecional é o FT245BM, mostrado na Figura 5.6.
Figura 5.6: FT245BM.
O dispositivo DLP-USB245M, possui 24 pinos de comunicação. Destes
pinos 8 são reservados para a comunicação bidirecional, formando assim um
barramento de 8 bits.
102
CAPITULO 6
Resultados
Para que fosse possível testar o sistema desenvolvido foi necessária a
criação 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 extração recebe os dados
para controle e monitoramento de todas as unidades de bombeio.
Atualmente diversos sistemas de controle e monitoração são 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
funções que a automação de bombas atinge (torque, ângulo de rotação, etc.),
pois, além disso, o Sisal possui diversas outras finalidades, dentre elas a
utilização de inteligência artificial para determinar situações ótimas no
funcionamento das Unidades de Bombeio como por exemplos a determinação
ótima da posição 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 Reconfigurável para Controle de Redes Sem Fios) visto que o
mesmo poderia ser aplicado a outros tipos de automação como mostrado no
estudo de caso apresentado no apêndice B.
O sistema de monitoramento e controle desenvolvido para etapa de
testes e simulações foi desenvolvido em Java, uma linguagem poderosa em
103
ambientes distribuídos complexos como a rede Internet. Mas sua versatilidade
permite ao programador ir além, oferecendo uma poderosa linguagem de
programação de uso geral, com recursos suficientes para a construção de uma
variedade de aplicativos que podem ou não depender do uso de recursos de
conectividade. (WUT, 1997)
O sistema desenvolvido em Java se conecta ao sistema embarcado
através de sockets e utilizando o padrão Ethernet de comunicação. Isto faz-se
necessário para utilização do ModBus TCP. Através da troca de pacotes é
possível monitorar o sistema e controlar diversas funcionalidades através de
comandos com o usuário. Na Figura 6.1 é possível visualizar a interface inicial
do sistema e na Figura 6.2 o sistema se conectando ao servidor (escravo)
através 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
Após a conexão o sistema possui duas funções principais que é o
monitoramento/controle de unidades de bombeio de petróleo e o
monitoramento de automação residencial. As funcionalidades podem ser
monitoradas através do status da unidade de bombeio como visualizado na
Figura 6.3. Através do status é possível visualizar o atual funcionamento da
bomba.
As características abordadas são:
Ativada: Indica se a bomba está ligada ou não.
Adquirindo: Informa se o sistema está adquirindo dados naquele momento.
Modo Automático: Se o sistema está em modo automático, ele permite que o
sistema embarcado tome decisões em relação à bomba de petróleo,
desligando ou diminuindo a rotação em casos de situação crítica.
105
Situação: Indica se uma situação crítica foi encontrada ou não. Na Figura a
situação normal indica que os valores de torque encontram-se dentro dos
padrões aceitáveis. Mesmo quando o sistema está em modo automático ele
avisa se alguma situação crítica for encontrada.
Método: Mostra o método que está sendo utilizado na aquisição de dados.
Método Telemétrico utilizando o módulo ZigBee ou método de aquisição dos
parâmetros elétricos do motor utilizando o CAD.
Figura 6.3: Status da unidade de bombeio
Além disso, as funcionalidades podem ser modificadas através de
comandos designados pelo usuário. Na Figura 6.4 pode-se ver a solicitação de
uma aquisição de dados constante no módulo ZigBee. Após iniciar a aquisição
constante é possível visualizar o gráfico dos dados recebidos através da
funcionalidade visualizar dados.
106
Figura 6.4: Tela do programa para iniciar/parar a a quisição constante
6.2 Monitoramento de Unidades de Bombeio de Petróle o
Após iniciar a aquisição, o sistema disponibiliza ao usuário a
possibilidade de acompanhar através de um gráfico os valores de torque
adquiridos. Na aquisição constante os dados são 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 módulo 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 petróleo); Ou no caso da aquisição dos
parâmetros elétricos do motor, os dados são convertidos pelo CAD
criado em laboratório e disponibilizados através da conexão USB
desenvolvida.
• O sistema embarcado que contém a FPGA recebe os pacotes ZigBee
(ou do CAD) com os dados adquiridos e os interpreta, faz os cálculos
107
desejáveis, empacota-os no protocolo ModBus e os disponibiliza no
servidor de sockets criado também interno à FPGA;
• O Sistema em Java localizado em um computador de uso geral recebe
os dados através da rede, independente do meio físico (nos testes em
laboratório rede de cabos Ethernet e no caso dos campos de extração
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 através 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 confiável, contendo todas as
características dos principais bancos de dados do mercado. Possui licença
para uso gratuito, seja para fins estudantis seja para realização de negócios,
possibilitando que empresas o utilizem livremente.
Enquanto os dados são armazenados, o usuário pode acompanhar o
gráfico dos valores adquiridos através do sistema. Exemplos de ondas como
senóide, dente de serra e quadrada, obtidas através de um gerador de ondas
ligado ao módulo ZigBee, são mostrados nas Figuras 6.6, 6.7 e 6.8.
108
Figura 6.6: Senóide gerada através de um gerador de ondas.
Figura 6.7: Função dente de serra
109
Figura 6.8: Onda quadrada
Figura 6.9: modulo ZigBee o gerador de ondas utiliz ado
Alguns testes foram realizados no simulador desenvolvido na fase inicial.
Estes testes tinham como objetivo gerar um gráfico 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 protótipo instalado.
6.3 Configuração do Hardware Utilizado
Na arquitetura desenvolvida foram inseridas as funcionalidades que são
utilizadas em qualquer modo de aquisição (torquímetro dinâmico ou parâmetros
elétricos do motor). Na Tabela 6.1 são mostradas as características do sistema
disponibilizadas no relatório de compilação da ferramenta Quartus II 8.0.
A freqüência máxima 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 memória SDRAM que
contém 16MB disponíveis utilizando somente 1,12MB para carregar o
programa desenvolvido. Durante a execução do sistema, a criação de
111
variáveis, buffers e outros elementos de programação aumentam um pouco a
utilização da memória, mas mesmo assim o espaço é bem mais do que
suficiente para esse processo.
Características da Arquitetura do Sistema
Status de fluxo: Successful (Fri Nov 27 10:34:21 2008)
Versão do Quartus II: 8.0 build 215 05/29/2008
Nome de Revisão: Arquitetura_Final
Nome da entidade de alto nível: Arquitetura_Final
Família: Stratix
Dispositivos: EP1S10F780C6
Modelos de Temporização: Final
Requisitos de tempo encontrados: Sim
Total de elementos lógicos: 6.160 / 10.570 (58%)
Total de pinos: 153 / 427 (36%)
Total de pinos virtuais: 0
Total de bits de memória: 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: Características da arquitetura desenvol vida para o sistema.
6.4 Comparação do Sistema Proposto com outros Siste mas
Para que fosse possível uma comparação entre a utilização do sistema
embarcado reconfigurável e as tecnologias utilizadas hoje, os dados mais
relevantes foram comparados e montados na Tabela 6.2 para análise e
comparação. Dentre as marcas utilizadas principalmente pela PETROBRAS
estão o ZAP da HI tecnologia, a CAC e os controladores da LUFKIN.
112
Sercref CAC ZAP LUFKIN
Tecnologia Wireless
Sim (Protocolo ZigBee)
Não Não Não
Reconfigurabilidade
Sim (Completa)
Sim (Parcial)
Sim (Parcial)
Sim (Parcial)
Possibilidades de expansão
Sim (Muitos
Módulos)
Sim (Alguns
Módulos)
Sim (Alguns
Módulos)
Sim (Alguns
Módulos)
Portas seriais Sim(2) Sim(2) Sim (2) Sim(2)
Porta USB Sim Não Não Não
Porta Ethernet Sim Não Não Não
Processamento 50 Mhz 16 Mhz 4KHz 500KHz
Saída PWM Sim Não Não Não
Protocolo MODBUS Sim Sim Sim Sim
Outros Protocolos Sim Não Não Não
Memória Externa Sim Não Sim Não
Tabela 6.2: Comparação das tecnologias de automação de bombas
6.4.1 Controlador CAC
O Controlador de Bomba de Haste (CBH) CAC Modelo 2000 é projetado
para operação com uma unidade de bombeio cavalo-de-pau. Dentre os
benefícios do CBH 2000, pode-se citar menor consumo de energia, aumento
na produção do poço, menor custo de manutenção e melhor uso de mão-de-
obra.
O CBH 2000 é projetado para instalação em uma "área segura", com os
dispositivos das pontas instalados em lugares perigosos de Classe I, Grupo C e
D. Barreiras de segurança podem ser montadas no CBH para isolar
dispositivos de campo para não comprometer a segurança. Sob condições
normais no campo, o CBH 2000 é cercado por uma caixa resistente ao tempo
113
que protege a unidade, e ao mesmo tempo permite acesso fácil ao
equipamento.
6.4.2 Controlador ZAP
A família de controladores lógicos programáveis ZAP900 foi
desenvolvida para atender aplicações 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 não interface
homem-máquina incorporada, a família ZAP900 é fornecida em sua
configuração básica com 2 canais de comunicação serial e 16 canais de I/O
digitais. Possui suporte para um módulo de expansão adicional podendo atingir
até 33 pontos de I/O, incluindo entradas e saídas analógicas e digitais,
interfaces para encoder, contador rápido e saídas geradoras de frequencia, etc.
Sucessor do ZAP500, este novo CLP reúne peformance e flexibilidade
tornando-o uma opção atrativa para o mercado de automação de máquinas,
predial, sistemas de aquisição 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
automação de bombas de petróleo. Este controlador é uma tecnologia
importante e patenteada, que calcula a carta dinamométrica para todos os
tempos desejáveis da unidade de bombeio, utilizando complexas computações
matemáticas encontradas no software de monitoramento. A sua memória flash
disponibiliza rápidas atualizações sem a necessidade de mudança de
componentes. Um barramento de expansão adicional permite a unidade
aumentar os seus requisitos adicionais a partir de portas de comunicação de
entrada e saída.
SAM é seguramente mais do que um simples controlador de bombas de
petróleo. Ele possui um sistema de monitoramento com algoritmos patenteados
para assegurar o controle, análise e um bom gerenciamento de seu sistema de
bombeio.
114
6.4.4 Sercref
O sistema embarcado Sercref aliado ao torquímetro dinâmico telemétrico
desenvolvido surgiu para suprir as carências existentes nas atuais tecnologias
de determinação de torque. Através desse sistema o erro na obtenção dos
valores de monitoramento é reduzido drasticamente. Além disso, a utilização
de uma arquitetura embarcada e reconfigurável permite uma expansão rápida
de funcionalidades do sistema.
Diversas tecnologias são utilizadas no sistema, para que seja possível
implementar as funções desejadas além de deixar outras possibilidades de
utilização já implementadas, facilitando o desenvolvimento de novas
aplicações. O Sercref também possibilita a utilização de uma rede Ethernet
para monitoramente e controle de dados, aumentando ainda mais a área de
aplicação.
O kit de desenvolvimento utilizado pode aceitar uma freqüência ainda
maior do que a citada na Tabela de comparação através da utilização de um
clock externo.
6.4.5 Comparação
Na tabela de comparação mostra-se que somente o sercref possui
tecnologia wireless na aquisição de dados da unidade de bombeio e permite
uma reconfiguração completa do sistema, uma vez que as outras tecnologias
somente permitem a expansão de algumas funcionalidades pré-existentes.
Devido a essa reconfigurabilidade o Sercref permite a utilização de diversos
módulos que podem ser incrementados ao sistema.
Embora todos os sistemas possuam duas portas seriais o sistema
embarcado desenvolvido permite a customização de novas portas, se
necessário. As portas ethernet e USB foram incrementadas para melhoria do
sistema, permitindo assim a integração direta de dispositivos USB e facilitando
a comunicação do sistema com a rede ModBus TCP, uma vez que nos atuais
sistemas essa comunicação é realizada por outro módulo externo ao sistema.
115
A freqüência de processamento existente no kit utilizado é de 50MHz,
embora esse valor possa ser aumentado através da utilização de um clock
externo. A saída PWM existente permite uma fácil conversão dos dados para
sinais analógicos que podem ser requeridos em testes e até mesmo no
desenvolvimento de novas funcionalidades.
Além de todas as funcionalidades mencionadas, o Sercref inclui a
possibilidade de utilização de diversos protocolos de comunicação e não
somente do protocolo ModBus como as outras tecnologias. A presença de
memória externa indica se o sistema permite a utilização de outro tipo memória
além da memória RAM para armazenamento de dados, como por exemplo uma
memória flash.
116
CAPITULO 7
Conclusões e Trabalhos Futuros
Os protótipos e testes realizados mostram a viabilidade do projeto,
principalmente quando comparado com o atual sistema de determinação de
torque. É importante ressaltar que pela característica reconfigurável do
sistema, o chip FPGA propicia grande mutabilidade. Assim, tanto as funções
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
automação de bombas de petróleo como em Xu e Gao (2008). Entretanto,
esses trabalhos não utilizam esse protocolo para aquisição de dados de torque,
e sim substituindo onde hoje é utilizado o protocolo ModBus. Esta proposta
facilita a integração desses novos projetos se os mesmos vierem a existir, pois
com as atuais arquiteturas seriam necessárias inúmeras alterações de
hardware existentes.
Esta proposta apresenta uma forma de pesquisa inovadora para redução
de custos na extração de petróleo, pode ser ampliado para outras formas de
determinação de torque que possam surgir.
A incorporação de processamento local, na bomba de petróleo, diminuiu
a carga de dados transferida para a central de controle e deu ao sistema
embarcado um maior poder de decisão local em situações não desejadas de
funcionamento. Esperar que o usuário que monitora o sistema analise e tome
uma decisão pode ser crítico para a quebra ou danos na unidade.
117
Além desta proposta desenvolvida e mostrada aqui, outras estão em
andamento aplicando as soluções propostas como mostrado no apêndice B.
Dentre os projetos estão:
Utilização do Sercref para monitoramento de trens unidades elétricas.
Nesta proposta,pretende-se monitorar variáveis que indicam o funcionamento
do trem tais como: peso, velocidade, aceleração, etc. Atualmente esses dados
somente são vistos pelo maquinista. Através do sistema proposto o centro de
controle e operações possuirá os dados necessários para monitoramento e até
mesmo, em alguns casos, o controle dos trens unidades elétricas.
Aplicação do sistema reconfigurável na integração de tecnologias e
serviços, aplicadas a lares, escritórios e pequenos prédios, com o propósito de
automatizar e obter um aumento de segurança, conforto, comunicação e
economia de energia. Através da utilização do sistema reconfigurável 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 automação residencial atuando como a
estão 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 divulgação dos métodos
desenvolvidos e resultados encontrados através deste trabalho. Além disso, o
torquímetro telemétrico ganhou o 4° Prêmio Petrobrá s de Tecnologia, ficando
em primeiro lugar para o tema de tecnologia de perfuração e de produção.
No projeto de automação de trens artigos e trabalhos foram destaque,
como o 4° lugar no prêmio Alston de Tecnologia.
118
Referências Bibliográficas
ALTERA CORPORATION, Nios II Software Developer’s Handbook . San Jose: Altera Corporation, 2007. 620 p. Disponível em: <http://www.altera.com>. Acesso em: 10 de mar. de 2008. ALTERA. Nios II Processor Reference Handbook . 2007. Disponível 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: SIMPÓSIO BRASILEIRO DE REDES DE COMPUTADORES, 2008. Rio de Janeiro, 2008. ANJOS, E. G. et al. Sistema de testes para um torquímetro dinâmico telemétrico 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 Com piler . IEEE Computer. v. 26, n. 3, Mar, 1993, p. 11-18. BARR, M. Programming Embedded Systems in C and C++. O´Reilly, 1999. BERKELEY Software Design. Disponível em: <http://www.bsd.org/>. Acesso em: 5 de set. 2004.
119
BRITO, R. M. Sistema Eletro-Eletrônico para Medição Direta de To rque em Dispositivos Girantes Utilizando Extensômetros de R esistência Elétrica. 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. D´AMORE R. VHDL: Descrição e síntese 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, Arurélio Buarque de Olanda. Dicionário Aurélio eletrônico: século XXI. Rio de Janeiro: Nova Fronteira e Lexicon Informática, 2000, versão 3.0. GANSSLE, J. The Art of Designing Embedded Systems, Academic, Pr ess Inc .,S. Diego, 1999.
120
GOSLING, J.; JOY, B.; STEELE,G. The Java Language Specification. Sun Microsystems , 1996. Disponível em: <http://java.sun.com/doc/language_specification.html.>. Acesso em: 07 de jul. 2007. GUPTA, R. K. Introduction to Embedded Systems . Disponível 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 . Disponível 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. Torquímetro dinâmico telemétrico aplicado ao eixo redutor de uma unidade de bombeio mecânico. 2007. Dissertação de Mestrado, Engenharia Mecânica. Universidade Federal da Paraíba, 2007. MAXFILED Max C. The Design Warrior’s Guide to FPGAs . USA, 2004. MENG, Z.; LIU, B. Research on the Laser Doppler Torque Sensor. Journal of Physics : Conference Series. v. 48, p.202–206. 2006. MENG, Z.; LIU B. Research on the Laser Doppler Torque Sensor. Journal of Physics : Conference Series. v. 48, 2006. p. 202–206. MODBUS.Org. ModBus Application Protocol Specification . v. 1, n.1, 2002. MODICON, Inc.; ModBus Protocol Reference Guide, Industrial Automat ion 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. Otimização de código fonte C para o processador embarcado Nios II . 2007. Dissertação de Mestrado. Instituto de Ciências Matemáticas e de Computação - Universidade de São Paulo, 2007. PINHEIRO, J. M. S. As Redes com ZigBee. Julho de 2004. Disponível 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 Negócios, 2005. Disponível 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 contro le. 2007. Dissertação de Mestrado (Engenharia Elétrica). - COPPE/UFRJ, 2007. SCHILDT, H. C. Completo e Total . São Paulo: Makron Books, 1996. TAKAI, O. K. Introdução 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 Petróleo . 2. ed. Rio de Janeiro, Editora Interciência (PETROBRAS). 2004. ZAMMATTIO, S. Delivering a Consistent Software Development Environment on a Changing Processor Platform , 2006. Disponível em: <http://www.fpgajournal.com/whitepapers_2006/q1_altera.htm>. Acesso em: 02 de Abr. 2008. WUTKA, M. Java: técnicas profissionais . Berkeley, 1997. XU, J.; GAO, M. ZigBee Wireless Mesh Networks for Remote Monitoring System of Pumping Unit; World Congress on Intellige nt Control and Automation . China, 2008. ZAMMATTIO, S. Delivering a Consistent Software Development Environment on a Changing Processor Platform , 2006. Disponível 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
APÊNDICE A
Modelagem do Sistema Embarcado
Sistema pode ser definido como uma coletânea de estruturas e recursos
que são interagidos segundo uma lógica de tal forma a alcançar 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 implementações e, ou, alterações de procedimentos até
que sejam obtidas as condições ideais. Estas ações fazem requerer do
tomador de decisão a condução de estudos preliminares e experiência,
para que as alterações não prejudiquem a performance do sistema.
• A segunda refere-se a utilização de modelos que representem os
sistemas reais. Os modelos podem apresentar-se como protótipos ou
como modelos matemáticos, os quais podem prestar-se a soluções
analíticas, como por exemplo um modelo de regressão, ou a simulação,
permitindo assim, reconstituir a rotina funcional de um dado sistema real.
Uma das tarefas mais árduas em simulação está em determinar se o
modelo proposto retrata com consistência o sistema em estudo. Para o alcance
desta meta são recomendados a observância de três preceitos básicos que
devem ser observados nas várias fases do desenvolvimento de um modelo.
(JAGADEV, et. al., 1995) Esses preceitos são:
• Verificação: conjunto de ações para certificar se a forma conceitual
adotada na formulação do modelo foi transcrita corretamente ao utilizar-
se das linguagens de programação ou de simulação;
124
• Validação: Coletânea de ações utilizadas para analisar se um dado
modelo representa com fidedignidade o sistema em estudo. Podendo
este procedimento ser conduzido em conjunto com a verificação, fato
que imprimirá maior confiabilidade ao modelo.
• implementação de confiabilidade: conforme citações em literaturas
especializadas, para a obtenção de modelos validados e confiáveis
deve-se ater aos seguintes preceitos: desenvolver modelos interativos
com os potenciais usuários, testar as considerações empíricas utilizadas
e determinar o quanto os dados gerados são representativos.
A.1 – O uso da UML
O grande problema do desenvolvimento de novos sistemas nas fases de
análise de requisitos, análise de sistemas e design é que não existe uma
notação padronizada e realmente eficaz que abranja qualquer tipo de aplicação
que se deseje. Cada simbologia existente possui seus próprios conceitos,
gráficos e terminologias, resultando numa grande confusão, especialmente
para aqueles que querem utilizar a orientação a objetos não 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 consistência, fácil comunicação com outras aplicações,
simples de ser atualizado e compreensível.
Existem várias 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 idéias
de cada uma destas metodologias.
A Linguagem de Modelagem Unificada (UML) fornece uma linguagem
gráfica para visualização, especificação, construção e documentação dos
artefatos de um sistema de software. Este Sistema de Software, com outras
informações, 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, ações e respostas profissionais,
como:
• Uma forma de comunicação que funciona igualmente bem na análise e
no projeto;
• Uma apresentação visual que funciona igualmente bem para usuários,
projetistas, programadores e engenheiros (membros técnicos e não
técnicos);
• Um padrão formal, porém flexível, para garantir a coerência e clareza;
• Uma Linguagem Extensível que pode ser ajustada a qualquer setor ou
tipo de aplicação;
A.2 Diagramação
Devido às razões citadas e a muitas outras que tornam a UML tão
utilizada e difundida, adotamos suas regras para modelagem do sistema. Os
diagramas gerados servem como forma de nortear as pesquisas e
desenvolvimentos. Vários diagramas foram desenvolvidos para que fosse
possível uma boa interpretação da camada de hardware, aplicação e software.
• Diagrama de Casos de Uso: É usado para modelar o modo como
as pessoas esperam usar um sistema. O diagrama descreve quem
serão os usuários relevantes, os serviços que eles exigem do sistema e
os serviços 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 Seqüência: Este diagrama fornece uma visão orientada
para o tempo das interações, 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 gráfico de fluxo, mostrando o
fluxo de controle de uma atividade para outra. Comumente isso envolve
a modelagem das etapas seqüenciais em um processo computacional.
• Diagrama de Componentes: Mostra a organização entre arquivos de
código fonte, bibliotecas, tabelas de banco de dados, etc. A relação mais
usada é a dependência, mostrando como um arquivo de código fonte
depende de um outro que ele inclui, e como, por exemplo, um
executável depende de uma biblioteca. Um componente é uma parte
física do sistema. Muitas vezes um componente mostra um arquivo
específico do sistema.
• Diagrama de distribuição ou implantação: Modela o hardware do
ambiente da implementação. Cada nó em um diagrama de distribuição
normalmente representa um tipo de hardware, como uma unidade de
disco, um PC cliente, um servidor ou um dispositivo de aquisição de
dados.
A.2.1 Casos de Uso
O caso de uso (use case) é um elemento gráfico exclusivo usado para
modelar o modo como as pessoas esperam usar o sistema. (Figura A.1)
Descrição: O diagrama mostra a interação do usuário e do administrador com
o sistema.
Caso de Uso 1 – Adquirir Dados: O usuário escolhe a opção de adquirir dados
no sistema e o mesmo inicia a sua aquisição e armazenamento.
Caso de Uso 2 – Visualizar Dados: O usuário escolhe a opção de visualizar
dados, configura os parâmetros necessários e então pode analisar gráficos
gerados a partir dos dados armazenados.
Caso de Uso 3 – Atualiza Firmware: O administrador pode atualizar o firmware
tanto da FPGA quanto do módulo RF existente no sistema.
Caso de Uso 4 – Configurar Parâmetros: O administrador pode configurar
parâmetros para a forma de aquisição escolhida
127
Figura A.1: Diagrama de casos de uso
A.2.2 Diagramas de Seqüência
Diagrama de seqüência é um tipo de diagrama usado para representar a
seqüência de processos (mais especificamente, de mensagens trocadas entre
objetos) em um programa de computador.
Descrição (Aquisição de Dados por RF ): O FPGA recebe dados do módulo
RF provenientes das medidas adquiridas através do torquímetro dinâmico
telemétrico. Essas medidas serão armazenadas e processadas para posterior
envio no formato MODBUS.
128
Figura A.2: Diagrama de sequência (Aquisição RF)
Descrição (Aquisição de Dados por CAD ): O FPGA recebe dados do
conversor analógico-digital provenientes das medidas. Semelhante ao anterior,
mudando a forma de aquisição.
Figura A.3: Diagrama de sequência (Aquisição CAD)
Descrição (Aquisição de Dados por CAD ): O FPGA trata os dados e os
disponibiliza no formato MODBUS para o sistema de envio RF central. Essa
disponibilização pode ocorrer de três formas: utilizando um conversor digital-
analógico para entrada de 4 a 20mA existente na CLP, utilizando a interface
serial existente na CLP ou utilizando a interface Ethernet existente no módulo
de rádio freqüência de alta potência.
129
Figura A.4: Diagrama de sequência (Envio dos Dados)
A.2.3 Diagrama de Atividades
Este diagrama descreve a seqüência de atividades realizadas pelo
sistema desde a ação do usuário no estado inicial da execução, até a exibição
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 organização dos softwares e
componentes de software que compõem o sistema.
131
Figura A.6: Diagrama de componentes
132
A.2.5 Diagrama de Distribuição
Este diagrama descreve a distribuição dos componentes do sistema no
ambiente de sua aplicação. É possível visualizar o hardwares e equipamentos
necessários à instalação do sistema.
Figura A.7: Diagrama de distribuição
133
APÊNDICE B
Aplicabilidade do Sistema Embarcado
Reconfigurável Proposto
Diversas características do sistema reconfigurável embarcado,
desenvolvido para aplicações em bombas de petróleo, acarretam em uma
grande aplicabilidade do sistema. Dentre as diversas aplicabilidades do sistema
podemos citar a automação de residências e de trens que atualmente se
encontram em estudo no LASID (UFPB). A seguir será descrito um pouco do
estudo de caso da aplicação dessa tecnologia. Estudos ainda estão sendo
realizados para desenvolvimento de dissertações de mestrado.
B.1 Automação Residencial
Domótica é a integração de tecnologias e serviços, aplicadas a lares,
escritórios e pequenos prédios, com o propósito de automatizar e obter um
aumento de segurança, conforto, comunicação e economia de energia. Por
automação entende-se a capacidade de se executar comandos, obter medidas,
regular parâmetros e controlar funções de uma casa automaticamente.
A palavra domótica (“domotique”) surgiu na França, onde houveram as
primeiras experiências relacionadas a domótica. Domótica é a contração da
palavra domus do Latim (equivalente a lar ou casa) com a palavra telemática.
Outro sinônimo para domótica é casa inteligente (smart house), porém neste
trabalho usaremos o termo domótica. A domótica pode substituir o homem em
diversas atividades rotineiras de forma a propiciar uma otimização nas
condições de vida em uma casa. O próprio sistema zela pela satisfação dos
moradores, sem que seja necessário a contínua intervenção dos mesmos.
134
O grau de controle alcançado pode ser variável, sendo uma função de
custo, desejo pessoal dos moradores, estrutura do prédio e tecnologia usada.
Casas que podem ter, por exemplo, ajuste automático de temperatura,
escalonamento automático de tarefas rotineiras como ligar a cafeteira,
acionamento automático de serviços de segurança e comunicação eficiente
com o mundo externo têm vários benefícios.
Outro termo importante a se definir é o conceito de teleação (teleaction).
Teleação é a capacidade de se controlar algum dispositivo remotamente.
Unindo os dois conceitos acima descritos (domótica e teleação) surgiu a idéia
de interligar a rede interna de uma casa (domótica) com a rede externa à casa
(Internet ou outro meio) de forma que os moradores da casa possam controlar,
monitorar e administrar seu lar a distância. Alem disso, a crescente utilização
de TVs Digitais no mundo vem possibilitando a concentração de
processamento em um dispositivo comum e muito utilizado, a televisão.
B.1.1 Sercref na Automação de Residências
A idéia de aplicação do SERCREF em automação residencial surgiu
com a possibilidade de inserir tal sistema junto ao firmware das televisões
digitais ou dos aparelhos set-top-box que podem ser utilizados para transformar
TVs analógicas em digitais.
A necessidade de gerenciar processos automatizados executados por
dispositivos domésticos consiste em um desafio para os sistemas domóticos,
pois a centralização do gerenciamento se torna complexa à medida que a
quantidade e a diversidade de dispositivos aumentam.
Este trabalho visa desenvolver uma aplicação para TVs digitais e uma
possibilidade de expansão do projeto Ginga@Home que tem como objetivo a
utilização da Televisão Digital (DTV) como centro de controle e monitoramento
remoto de dispositivos residenciais. O projeto consiste em ampliar a atuação do
OpenGinga, uma implementação de código aberto do Ginga, o middleware do
Sistema Brasileiro de TV Digital, onde as aplicações executadas são
classificadas em duas categorias dependendo se o conteúdo inicial da
aplicação é declarativo ou procedural. O ambiente de execução que processa
135
aplicações Nested Context Language (NCL) é chamado de Ginga-NCL e o
ambiente que controla a execução de aplicações baseadas na Java TV é
chamado de Ginga-J.
Para que a administração dos dispositivos seja possível, foi
desenvolvido um módulo de tratamento de dados empacotados no protocolo
ZigBee, baseado no padrão IEEE 802.15.4, que tem como função o controle de
dispositivos remotos através de módulos de radiofreqüência (RF), que ficam
acoplados tanto no set-top box (STB), chamados de unidades base, como nos
dispositivos que são monitorados (condicionadores de ar, câmeras de
segurança, alarmes, bomba de irrigação, entre outros), chamados de unidades
remotas.
B.1.2 Funcionamento
O funcionamento do sistema é bastante simples. Os dispositivos
residenciais monitorados trocam informações com os módulos ZigBee através
de canais analógicos e digitais. Os módulos ZigBee remotos enviam os dados
para o módulo base, coordenador, que disponibiliza-os para o sistema
embarcado.
O software do sistema embarcado trata os dados empacotados no
protocolo ZigBee e troca informações com o sistema de monitoramento na
web, conectado através de sockets.
B.1.3 Testes
O firmware desenvolvido para controle de bombas de petróleo foi
modificado para receber pacotes em ModBus referentes a controle da
automação residencial. Dentro do sistema embarcado foram simulados alguns
equipamentos como ar condicionado, alarme, detector de incêndio, etc. Através
da simulação foi possível verificar a possibilidade de controle através do
sistema embarcado e da rede ethernet.
Os comandos eram enviados através 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 realização de determinada ação ou não. Se for possível
efetuar, o sistema retorna um pacote indicando o processo realizado, se não
indica que não 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 automação de
bombas de petróleo. Entretanto qualquer outro protocolo pode ser adotado e
customizado devido a capacidade de reconfiguração do sistema embarcado
proporcionado pela FPGA.
A Tabela B.1 a seguir contém alguns dos pacotes utilizados para
tratamento de dados do projeto de testes na automação residencial. É descrito
cada pacote utilizado para cada funcionalidade implementada. Para cada
função, diversos pacotes foram utilizados para mapear as características do
dispositivo. Os pacotes estão divididos em pacotes de entrada de dados e de
saída de dados. Os pacotes de entrada são enviados pelo mestre da rede que
solicita uma função ao escravo. O escravo retorna a função através dos
pacotes de saída de dados.
Tabela de Pacotes ModBus da Automação Residencial
Lâmpadas - A3
Entrada de dados
A31000: Ligar a lâmpada A32000: Desligar a lâmpada A3000F: Solicitação de status
Saída 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
Saída de dados
A41001: Já estava ligado A41002: Ligado com sucesso A42001: Já estava desligado
137
A44000: Solicitação 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 A5000F: Solicitação de status
Saída 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 Incêndio – A6
Entrada de dados
A61000: Ativar detector A62000: Desativar detector A6000F: Solicitação de status
Saída 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 A7000F: Solicitação de status
Saída 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 Confirmação: CC0000 Pacote Desconhecido: EE0000
Finaliza Conexão: FF0000
Tabela B.1: Pacotes ModBus utilizados na automação residencial.
A Figura B.1 mostra como o sistema Sercref foi adaptado para os testes
realizados e como se dá a interação com cada funcionalidade do sistema. Na
Figura B.2 é mostrado como o status da casa é verificado e na Figura B.3 o
protótipo em desenvolvimento.
Figura B.1: Sercref para automação residencial
139
Figura B.2: Status dos dispositivos monitorados da casa.
Figura B.3: Estrutura onde o protótipo está sendo i nstalado.
140
B.2 Automação de Trens
A transmissão de dados remota é um recurso fundamental para
empresas que necessitam de informações em tempo real, como fator
estratégico para tomadas de decisões. No segmento de transporte
metroferroviário, a necessidade de informações precisas se torna ainda mais
crítica, pois é baseada nestas que são tomadas grandes decisões de tráfego
de metrôs no sistema de transporte.
B.2.1 Aplicação do Secref na automação de Trens
Atualmente, encontra-se em desenvolvimento um sistema telemétrico
para monitoramento de malhas ferroviárias utilizando redes de sensores sem
fio com tecnologia ZigBee e controle em sistemas embarcados. Este sistema,
denominado Railbee, é alvo de uma dissertação de mestrado em informática
e de uma tese de doutorado em engenharia mecânica e conta com a
participação de estudantes e pesquisadores do LASID (UFPB) e LES (UFPB).
O RailBee tem como principal objetivo a obtenção, em tempo real, de
informações importantes relacionadas as medidas de grandezas como
velocidade, pressão nas bolsas de ar, corrente de armadura, dentre outras.
Essas medidas podem ser utilizadas para calcular dados como posição e
numero médio de passageiros em cada trem.
A disponibilidade de informações para a gestão metro-ferroviária trará
uma série de benefícios para os controladores de tráfego do Centro de
Controle de Operações (CCO) e para os técnicos responsáveis pela
manutenção, como por exemplo: Dinamismo, otimização e flexibilidade nos
processos de planejamento e controle de tráfego dos TUE e Dados, bem como
alarmes serão mostrados em tempo real nos consoles do CCO.
A constante avaliação do desempenho dos TUE permitirá a realização
de diagnósticos mais precisos e a tomada de ações preventivas de operação
e manutenção, como também às decisões preditivas com base em
prognósticos auferidos das medidas em tempo real, de forma a possibilitar
uma estratégia de intervenção, evitando assim uma degradação parcial ou
total dos serviços de transporte prestados à população.
141
B.2.2 Funcionamento
O sistema proposto é dividido em três subsistemas: Sistema de
Aquisição de Dados, Sistema de Tratamento de Dados e Sistema de
Supervisão Geral.
O sistema de aquisição é formado pelas redes de sensores sem fio que
são responsáveis pela captação das medidas remotas e por seu envio até o
sistema de tratamento. Essa rede é constituída de três tipos de módulos RF:
nó coordenador, nós roteadores e nós finais, onde cada módulo possui uma
função especifica dentro da rede. Os nós finais, estarão localizados dentro das
cabines dos trens e terão suas entradas analógicas ligadas as sensores de
velocidade, pressão, etc. Esses nós transmitirão os dados obtidos para os nós
roteadores instalados ao longo das vias férreas que por sua vez repassam os
dados recebidos para outros nós roteadores ou para o nó coordenador da rede
caso este esteja ao alcance. O nó coordenador é responsável por receber os
dados obtidos pelos nós finais e enviá-los para o sistema de tratamento através
de uma porta serial UART ou USB. Para aumentar a confiabilidade do sistema,
haverá vários nós coordenadores. Cada nó coordenador ficará situado em uma
das estações de passageiros e controlará a subrede de sensores instalada nas
proximidades desta estação.
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 tensão
medidos nos sensores, realiza os cálculos de velocidade, pressão, posição,
etc, e os envia para o sistema de supervisão através da rede ethernet.
O sistema de supervisão geral ficará instalado na Central de Controle de
Operações. Este sistema receberá as medidas já calculadas no sistema de
tratamento de todas as estações de passageiros e as exibirá em tempo real na
forma de gráficos ou tabelas, como também as armazenará em um banco de
dados ou em arquivos para analise posterior. A visualização em tempo real
142
agilizará o trabalho dos controladores de tráfego permitindo que estes tomem
decisões de forma mais rápida 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
supervisão.
Figura B.4: Interface mostrando as medidas realiza das em cada trem
B.2.3 Testes
Para validar a telemetria via ZigBee alguns testes foram realizados em
uma cabine de trem na estação central do metrô do Recife. Utilizou-se um
oscilógrafo, que é o atual instrumento usado nos trens para medição de sinais,
e três módulos ZigBee (roteador, coordenador e nó final). Dois canais
analógicos do módulo ZigBee e de oscilógrafo foram utilizados para registro
dos parâmetros de velocidade e pressão média nas bolsas de ar (indicando o
peso do trem), respectivamente. Os dois equipamentos, ZigBee e oscilógrafo,
143
utilizaram os mesmos pontos de captação dos sinais concomitantemente para
garantir a comparação posterior dos dados.
Figura B.5: Interface para mostrar as medidas de um trem especifico.
Na comparação das curvas geradas a partir dos dados registrados nos
dois instrumentos, verificou-se uma semelhança na sua resposta dos
parâmetros velocidade real e pressão média das bolsas de ar. A Figura B.6
demonstra essa semelhança para a medida da tensão referente à velocidade.
O fator de correlação das curvas foi 0,994 para velocidade e 0,992 para a
pressão.
144
Figura B.6: Amostras
Também foram realizados alguns testes com os módulos ZigBee para
obtenção das medidas de velocidade e pressão em toda a linha de Recife a
Jaboatão. As Figuras B.7 e B.8 abaixo demonstram as medidas de velocidade
e pressão nesse trecho. Através dos gráficos é possível saber a velocidade
máxima e mínima e a posição do trem em determinado instante. É possível
ainda saber o tempo que o trem ficou parado em qualquer estação de
passageiros. A medida da variação da pressão pode ser utilizada para calcular
a média de passageiros que entram e saem em cada estação através do peso
do trem.
Tempo (s)
Figura B.7: Gráfico indicando a velocidade do trem.
Vel
ocid
ade
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: Gráfico da pressão exercida pelo trem
Através da analise destes gráficos, os engenheiros e técnicos podem
identificar possíveis falhas e problemas ocorridos durante a operação de cada
TUE.
O sistema telemétrico aqui proposto apresenta uma relação
custo/beneficio bem mais favorável que o atual sistema utilizado. Além de
empregar tecnologia de custo muito mais baixo que o sistema atual, ele permite
a aquisição e envio de dados em tempo real com os TUE em movimento,
permitindo assim que os dados possam ser analisados de forma rápida e
prática.
Pre
ssão
(ps
i)