Sistema Embarcado Reconfigurável para Automação de Unidades de Bombeamento de Petróleo através de Redes de Sensores sem Fios.

Transcrição

1 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 i

2 Universidade Federal da Paraíba Centro de Ciências Exatas e da Natureza Programa de Pós-Graduação em Informática Dissertação de Mestrado Sistema Embarcado Reconfigurável para Automação de Unidades de Bombeamento de Petróleo através de Redes de Sensores sem Fios. EUDISLEY GOMES DOS ANJOS Orientadores: José Antônio Gomes de Lima Francisco Antônio Belo João Pessoa, Março de 2009 ii

3 Universidade Federal da Paraíba Centro de Ciências Exatas e da Natureza Programa de Pós-Graduação em Informática Sistema Embarcado Reconfigurável para Automação de Unidades de Bombeamento de Petróleo através de Redes de Sensores sem Fios. EUDISLEY GOMES DOS ANJOS Orientadores: José Antônio Gomes de Lima Francisco Antônio Belo Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Informática, da Universidade Federal da Paraíba, como parte dos requisitos para a obtenção do título de Mestre em Informática. Área de concentração: Ciência da Computação. Linha de pesquisa: Processamento de Sinais e Sistemas Gráficos. João Pessoa, Março de 2009 iii

4 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, p. : 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) iv

5 EUDISLEY GOMES DOS ANJOS Sistema Embarcado Reconfigurável para Automação de Unidades de Bombeamento de Petróleo através de Redes de Sensores sem Fios. Orientadores: Banca Examinadora: 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 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 v

6 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 vi

7 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. vii

8 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. viii

9 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. ix

10 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. x

11 Lista de Figuras Figura 2.1 Diagrama básico de um sistema embarcado Figura 2.2 Sistemas embarcados em um veículo Figura 2.3 Data logger para temperatura do ar Figura 2.4 Nintendo Wii e sua grande interação com o usuário Figura 2.5 Sistema de controle industrial Figura 2.6 Ambiente de desenvolvimento DSP para o dspic Figura 2.7 Roteador Cisco Figura 2.8: Modelo de uma FPGA da Altera Figura 2.9: Esboço de um FPGA Figura 2.10: Camadas do protocolo ZigBee Figura 2.11: Modelo das redes ZigBee Figura 2.12: Aplicações do padrão ZigBee Figura 2.13: Modelo do ZigBee da MaxStream e seus 20 pinos Figura 2.14: Diagrama de fluxo do módulo ZigBee Figura 2.15: Camadas das formas de implementação do MODBUS Figura 2.16: Modelo de um pacote MODBUS Figura 2.17: Kit de desenvolvimento Altera para o Nios II Figura 2.18: Hardwares de referência para prototipação do Nios II Figura 3.1: Atual modelo de automação de bombas de petróleo 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ário do motor Figura 3.4: Medição da velocidade do redutor Figura 3.5: Medição da velocidade do motor xi

12 Figura 3.6: Bancada de testes para torque estático Figura 3.7: Bancada de torque dinâmico com eixo para frenagem Figura 3.8: Protótipo com manivela e contrapeso Figura 3.9: Simulador de UBM proporcional a unidade real Figura 3.10: Unidade de bombeio da PETROBRAS utilizada para testes. 54 Figura 3.11: PC embarcado utilizado para testes Figura 3.12: Conversor A/D utilizado para testes Figura 3.13: Módulo ZigBee utilizado para testes Figura 3.14: Abraçadeira contendo a unidade remota Figura 3.15: Unidade base usada para testes Figura 3.16: Interface do sistema MUB Figura 3.17: Módulo de aquisição Figura 3.18: Módulo de tratamento de dados Figura 3.19: Módulo de visualização Figura 3.20: Sinais dos sensores de posição e extensômetros Figura 3.21: Gráfico torque x ângulo Figura 3.22: Gráficos de corrente, e potência calculada Figura 3.23: Medidas de corrente (branco) e tensão (vermelho) Figura 3.24 Gráficos das potências ativa, reativa e aparente Figura 3.25: Curvas de torque pelos dois métodos 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 Figura 3.28: Curva de valores mais precisos obtida com extensômetros 66 Figura 3.29: Curva com valores referente à potência no motor Figura 4.1: Modelo arquitetural de um sistema embarcado xii

13 Figura 4.2: Camada de hardware Figura 4.3: Camada de sistemas de software Figura 4.4: Camada de aplicação Figura 4.5: Diagrama de blocos de comunicação entre PIO e USB Figura 4.6: Comunicação entre a interface USB e o controlador USB Figura 4.7: Ciclo de escrita pra o DLP-USB245M Figura 4.8: Ciclo de escrita pra o DLP-USB245M Figura 4.9: Algoritmos de transmissão e recepção de dados pela USB Figura 4.10: Transmissor de RF ao lado das unidades de bombeio Figura 4.11: Modelo do pacote ModBus TCP Figura 4.12: Diagrama de transmissão ZigBee Figura 4.13: Modelo P-CAD da placa de recepção ZigBee Figura 4.14: PCB contendo modelo de placa de recepção ZigBee 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.. 93 Figura 5.1: Fluxo de funcionamento do SoPC Builder Figura 5.2: Arquitetura no SOPC Builder Figura 5.3: Visão das funcionalidades do Nios II IDE Figura 5.4: Abstração de hardware do sistema de bibliotecas HAL Figura 5.5: DLP-USB245M Figura 5.6: FT245BM Figura 6.1: Tela inicial do sistema Figura 6.2: Sistema conectando Figura 6.3: Status da unidade de bombeio Figura 6.4: Tela do programa para iniciar/parar a aquisição constante xiii

14 Figura 6.5: Funcionamento completo do sistema Figura 6.6: Senóide gerada através de um gerador de ondas Figura 6.7: Função dente de serra Figura 6.8: Onda quadrada Figura 6.9: modulo ZigBee o gerador de ondas utilizado Figura 6.10: Imagem com o protótipo instalado Figura A.1: Diagrama de casos de uso Figura A.2: Diagrama de sequência (Aquisição RF) Figura A.3: Diagrama de sequência (Aquisição CAD) Figura A.4: Diagrama de sequência (Envio dos Dados) Figura A.5: Diagrama de atividades Figura A.6: Diagrama de componentes Figura A.7: Diagrama de distribuição Figura B.1: Sercref para automação residencial Figura B.2: Status dos dispositivos monitorados da casa Figura B.3: Estrutura onde o protótipo está sendo instalado Figura B.4: Interface mostrando as medidas realizadas em cada trem. 142 Figura B.5: Interface para mostrar as medidas de um trem especifico Figura B.6: Amostras Figura B.7: Gráfico indicando a velocidade do trem Figura B.8: Gráfico da pressão exercida pelo trem xiv

15 Lista de Tabelas Tabela 2.1: Descrição dos 20 pinos presentes no ZigBee MaxStream Tabela 4.1: Tempos para leitura estabelecidos pelo fabricante do DLP Tabela 4.2: Tempos para escrita estabelecidos pelo fabricante do DLP.. 81 Tabela 4.3: Pacotes ModBus criados para controle das UB Tabela 6.1: Características da arquitetura desenvolvida para o sistema.111 Tabela 6.2: Comparação das tecnologias de automação de bombas Tabela B.1: Pacotes ModBus utilizados na automação residencial xv

16 Sumário Sumário... xvi CAPÍTULO Introdução Motivação Objetivos Organização... 4 CAPITULO Fundamentação Teórica Sistemas Embarcados O que é um sistema embarcado? Sistemas embarcados de tempo real Mudanças de Projetos de Sistemas Embarcados Exemplos de aplicações Computação Reconfigurável FPGAs Protocolo ZigBee Arquitetura Protocolo ZigBee e Redes de Sensores sem Fios Hardware ZigBee Protocolo ModBus Processador Nios II Linguagens de programação Linguagem C xvi

17 2.6.2 Linguagem Java Linguagem LabView Linguagem VHDL (VHSIC Hardware Description Language) Barramento USB Bases de dados Capítulo Medição de Torque Sistemas de Automação de Unidades de Bombeio de Petróleo Atual Modelo de Automação Torquímetro Dinâmico Telemétrico Torque Através dos Parâmetros Elétricos do Motor e Perda da Correia Teste e Validação Protótipos para obtenção de torque Sistema de Testes e Validação Resultados Obtidos Capitulo Sistema Embarcado para Automação de Bombas de Petróleo Arquitetura Camada de Hardware Camada de Sistema de Software Camada de Aplicação de Software Componentes da Arquitetura PIO (Parallel input/output) JTAG Uart Núcleo Nios II xvii

18 4.2.4 Ethernet MAC Controlador SDRAM Controlador USB Controlador ZigBee e ModBus Controlador Serial Controlador ADC Implementação do Empacotador MODBUS Funcionamento do Sistema Circuito ZigBee de Recepção CAPÍTULO Ferramentas e Metodologia Softwares Utilizados para Desenvolvimento SoPC Builder Plataforma de Desenvolvimento de Software Nios II Interface USB CAPITULO Resultados SERCREF Monitoramento de Unidades de Bombeio de Petróleo Configuração do Hardware Utilizado Comparação do Sistema Proposto com outros Sistemas Controlador CAC Controlador ZAP Controlador Lufkin Sercref Comparação xviii

19 CAPITULO Conclusões e Trabalhos Futuros Referências Bibliográficas APÊNDICE A Modelagem do Sistema Embarcado A.1 O uso da UML A.2 Diagramação A.2.1 Casos de Uso A.2.2 Diagramas de Seqüência A.2.3 Diagrama de Atividades A.2.4 Diagrama de Componentes A.2.5 Diagrama de Distribuição APÊNDICE B Aplicabilidade do Sistema Embarcado Reconfigurável Proposto B.1 Automação Residencial B.1.1 Sercref na Automação de Residências B.1.2 Funcionamento B.1.3 Testes B.2 Automação de Trens B.2.1 Aplicação do Secref na automação de Trens B.2.2 Funcionamento B.2.3 Testes xix

20 xx

21 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 1

22 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. 2

23 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; 3

24 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. 4

25 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 5

26 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 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 6

27 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 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) 7

28 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 embarcado. 8

29 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 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 9

30 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 com o usuário 10

31 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 11

32 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. 12

33 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 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

34 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. Disponível em: Figura 2.9: Esboço de um FPGA 14

35 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. 15

36 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 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, 16

37 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 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. 17

38 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 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 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). 18

39 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 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 19

40 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 , 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 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) 20

41 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 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 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 20 pinos 21

42 Pino Nome Direção Descrição 1 VCC - Alimentação 2 DOUT Saída Saída de dados da UART 3 DIN / CONFIG Entrada Entrada de dados UART 4 DO8 Saída Saída digital 8 5 RESET Entrada Reinicia o módulo 6 PWM0 / RSSI Saída Saída PWM 0 / RSSI 7 PWM1 Saída Saída PWM 1 8 [Reservado] - Não conectado 9 DTR / SLEEP_RQ/ DI8 Entrada Pino de controle de espera ou entrada digital 8 10 GND - Terra 11 AD4 / DIO4 Bidirecional Entrada analógica 4 ou entrada/saída Digital 4 12 CTS / DIO7 Bidirecional Controle de fluxo ou entrada/saída digital 7 13 ON / SLEEP Saída Indicador de status do módulo 14 VREF Entrada Voltagem de referência para entradas digitais e analoógicas 15 Associate / AD5 / DIO5 Bidirecional Indicador, Entrada analógica 5 e entrada/saída digital 5 16 RTS / AD6 / DIO6 Bidirecional Controle de Fluxo, entrada analógica 6 ou entrada/saída digital 6 17 AD3 / DIO3 Bidirecional Entrada analógica 3 ou entrada/saída digital 3 18 AD2 / DIO2 Bidirecional Entrada analógica 2 ou entrada/saída digital 2 19 AD1 / DIO1 Bidirecional Entrada analógica 1 ou entrada/saída digital 1 20 AD0 /DIO0 Bidirecional Entrada analógica 0 ou entrada/saída digital 0 Tabela 2.1: Descrição dos 20 pinos presentes no ZigBee 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

43 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 mestreescravo. 23

44 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 24

45 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) 25

46 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. Disponível em Figura 2.17: Kit de desenvolvimento Altera para o Nios 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 26

47 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. 27

48 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 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 28

49 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á- 29

50 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) 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 30

51 (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 31

52 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 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 32

53 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 subprogramas, que correspondem a trechos do programa principal, que podem ser encapsulados em ícones criados pelo programador (subprogramas 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 33

54 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 (standalone) é 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.). 34

55 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 Language VHDL (VHSIC Hardware Description Language) 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 35

56 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 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 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 36

57 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, 37

58 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 38

59 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 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 Em 1991 foi lançada a versão 3, com melhorias no executor de consultas e algumas partes do código foram reescritas. As versões subsequentes, até o Postgres95, foram focadas em confiabilidade e portabilidade. O Postgres foi utilizado para diversos sistemas 39

60 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 40

61 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 clienteservidor. 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) 41

62 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. 42

63 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). 43

64 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 44

65 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 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 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 45

66 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 46

67 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 47

68 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 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 48

69 3.4 Torque Através dos Parâmetros Elétricos do Motor 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ário 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. 49

70 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 50

71 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 (V R ) e a velocidade do motor (V M ). 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: T REDUTOR = REG (v, i, V R, V M, 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) 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 51

72 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 para frenagem Figura 3.8: Protótipo com manivela e contrapeso 52

73 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 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. 53

74 Figura 3.10: Unidade de bombeio da PETROBRAS utilizada para testes 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 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êmse 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. 54

75 Figura 3.11: PC embarcado utilizado para testes Os conversores utilizados são desenvolvidos pela National Instruments modelo NI 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. Disponível em: 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 55

76 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 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 56

77 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 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 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. 57

78 Módulo PC Embarcado Conversores A/D Transformador 110v - 220v Sensores de corrente Sensores de Tensão 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 58

79 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 Figura 3.18: Módulo de tratamento de dados 59

80 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 Figura 3.19: Módulo de visualização 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. 60

81 Figura 3.20: Sinais dos sensores de posição e extensô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 61

82 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 calculada. 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 62

83 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 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 63

84 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. 64

85 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. 65

86 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 66

87 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 67

88 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 68

89 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. 69

90 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 embarcado 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) 70

91 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 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 71

92 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). Protocolo Sistema Operacional 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 72

93 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 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) 73

94 Figura 4.4: Camada de aplicação A seguir é especificado um roteiro dos acontecimentos do sistema na camada de aplicação: 74

95 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 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á 75

96 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 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. 76

97 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 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 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 77

98 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 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 78

99 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 controlador 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. 79

100 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. 80

101 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 T10 Tempo de espera para o WR inativo 10 ns 20 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 81

102 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. 82

103 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 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. 83

104 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 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 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 84

105 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 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, 85

106 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 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 86

107 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 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 7AXXXX 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 Mestre: Solicita aquisição constante ao escravo. Nesta função o escravo manda os dados adquiridos 7BFFFF constantemente até que um comando de parada seja enviado. Escravo: Envia através das 4 variáveis XXXX os valores 7BXXXX adquiridos durante a aquisição constante. Parar Aquisição Quando Estiver Constante A11000 Mestre: Solicita o cancelamento da aquisição constante. Escravo: Avisa ao mestre que a solicitação de parada não A11001 foi realizada porque o sistema não se encontrava em 87

108 A11002 A11003 A21000 A21001 A21002 A22000 A22001 A22002 A23000 A23001 A24000 A24001 A25001 aquisição constante. Escravo: Avisa ao mestre que a aquisição constante foi parada com sucesso. 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 Mestre: Solicita a parada da bomba de petróleo, ou seja, o desligamento do motor. Escravo: Informa ao mestre que a bomba já se encontra parada. Escravo: Informa ao mestre que a bomba foi parada com sucesso. Mestre: Solicita o acionamento da bomba de petróleo, isto é, ligar o motor da mesma se estiver parado. Escravo: Avisa ao mestre que a bomba já se encontra em funcionamento. Escravo: Avisa ao mestre que a bomba foi acionada com sucesso. 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. Escravo: Parada automática configurada com sucesso. 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. Escravo: Informa ao mestre que a parada automática foi cancelada. Escravo: Avisa ao mestre que uma situação crítica foi encontrada na bomba mas que não havia permissão para 88

109 A26001 CC0000 EE0000 FF0000 resolver a situação. Este aviso deixa a cargo do mestre (usuário) a decisão que será tomada. 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. Mestre ou Escravo: Indica que o pacote recebido está correto e foi ou está sendo processado. Mestre ou Escravo: Avisa que o pacote recebido é desconhecido. Mestre: Finaliza a conexão com o escravo. Tabela 4.3: Pacotes ModBus criados para controle das UB. 4.4 Funcionamento do Sistema Para um funcionamento adequado do sistema, o processador se utiliza da 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. 89

110 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

111 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, tornandoos 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 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

112 Figura 4.13: Modelo P-CAD da placa de recepção ZigBee Figura 4.14: PCB contendo modelo de placa de recepção ZigBee 92

113 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 93