Sistema Embarcado Reconfigurável para Automação de Unidades de ...ppgi.ci.ufpb.br/wp-content/uploads/2009eudisleyanjos.pdf · ... Modelo de uma FPGA da Altera ..... 14 Figura 2.9:

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




Dissertação de Mestrado





Orientadores:

José Antônio Gomes de Lima

Francisco Antônio Belo


iii








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.


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





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



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)

Documents

Sistema Embarcado Reconfigurável para Automação de Unidades de ...ppgi.ci.ufpb.br/wp-content/uploads/2009eudisleyanjos.pdf · ... Modelo de uma FPGA da Altera ..... 14 Figura 2.9: