HAISSAM YEBAHI

INOSENSOR: FERRAMENTA PARA GERENCIAMENTO DE SENSORES PARA ARDUINO

Monografia apresentada no Centro de Educao do Planalto Norte/CEPLAN, da Universidade do Estado de Santa Catarina/UDESC, como requisito parcial para concluso do curso de Ps-graduao Lato Sensu de Especializao em Desenvolvimento de Software. Orientador: Alex Luiz de Sousa

SO BENTO DO SUL, SC 2013

HAISSAM YEBAHI INOSENSOR: FERRAMENTA PARA GERENCIAMENTO DE SENSORES PARA ARDUINO Monografia apresentada no Centro de Educao do Planalto Norte/CEPLAN, da Universidade do Estado de Santa Catarina/UDESC, como requisito parcial para concluso do curso de Ps-graduao Lato Sensu de Especializao em Desenvolvimento de Software.

Banca Examinadora

Orientador: __________________________________________ M.Eng. Alex Luiz de Sousa Universidade do Estado de Santa Catarina

Membro:

__________________________________________ Dr. Nilson Ribeiro Modro Universidade do Estado de Santa Catarina

Membro:

__________________________________________ Dr. Mrio Ezequiel Augusto Universidade do Estado de Santa Catarina

So Bento do Sul, SC, 03/10/2013.

Ao meu amor, Thalita Gabriela Costa, pelo carinho, pacincia e apoio durante a realizao deste trabalho.

AGRADECIMENTOS

Agradeo a todos que direta ou indiretamente contriburam com a concretizao deste trabalho. Em primeiro lugar agradeo a Deus, por ter me guiado diante de tantas dvidas mesmo quando a esperana parecia no ser suficiente. Ao professor e o orientador Alex Luiz de Sousa, de maneira especial, por confiar na minha capacidade, pelo apoio e contribuio. A minha amiga e coordenadora de TI da empresa Tigre S.A. Palmira Bozzola Serpa por sempre apoiar e permitir a ausncia do trabalho para comparecer s aulas da ps graduao durante os dias de semana. Ao meu amigo Bruno Hasse por me apresentar o Arduino e que serviu de base para este projeto. Ao meu amigo Cleomar Roeper pela parceria durante as viagens a So Bento do Sul durante os dias de aula e pela indicao do curso de Ps-Graduao. As demais pessoas, amigos, professores que apoiaram ou contriburam para este projeto com ideias, sugestes e crticas.

RESUMO

YEBAHI, Haissam. InoSensor: Ferramenta para gerenciamento de sensores para Arduino. 2013. 141 f. Monografia apresentada no Centro de Educao do Planalto Norte/CEPLAN, da Universidade do Estado de Santa Catarina/UDESC, como requisito parcial para concluso do curso de Ps-graduao Lato Sensu de Especializao em Desenvolvimento de Software, So Bento do Sul, 2013.

As tecnologias esto cada vez mais inseridas no cotidiano das pessoas. Com o passar do tempo, novas solues surgem com o intuito de facilitar a execuo de tarefas manuais e reduzir o tempo gasto em tarefas rotineiras, que poderiam ser executadas por equipamentos eletrnicos de maneira mais eficaz e controlada. Independente do ambiente em que aplicada, a Automao pode proporcionar o gerenciamento de recursos de forma bastante eficiente e sustentvel em ambientes residenciais, prediais ou industriais. A Domtica, ou automao residencial, composta por dispositivos e sistemas interconectados atravs de uma rede de comunicao, responsvel por prover os mecanismos necessrios superviso e gerenciamento do ambiente relacionado. A Domtica est se tornando cada vez mais acessvel devido principalmente grande disseminao e ao baixo custo oriundo do aumento do nmero de fabricantes desses dispositivos. O emprego de solues integradas gera inmeras vantagens como reduo de custos, facilidade de instalao e expanso do sistema. Esto disponveis no mercado diferentes plataformas para prototipao e desenvolvimento de sistemas baseados em microcontroladores de forma bastante simples a custos relativamente baixos. Arduino uma plataforma open source que combina diferentes tipos de hardware e possui uma arquitetura padro composta por portas analgicas e digitais e um microcontrolador da famlia Atmel. O microcontrolador responsvel pelo gerenciamento de sensores e perifricos conectados ao dispositivo. Apesar da simplicidade da plataforma, o desenvolvimento de solues exige conhecimentos bsicos de eletrnica e programao durante a elaborao do firmware do Arduino. Seguindo esse conceito, a ferramenta InoSensor foi desenvolvida com o objetivo de facilitar o uso de sensores e permitir o gerenciamento e monitoramento da plataforma Arduino remotamente, sem realizar a programao do hardware sempre

que houver a necessidade de modificar as configuraes dos sensores conectados. A soluo da ferramenta InoSensor composta dos seguintes mdulos: (i) Sistema Web para gerenciamento de Arduino, responsvel por cadastrar o Arduino, seus sensores e as aes que devem ser executadas na ocorrncia de eventos configurados; (ii) Firmware do Arduino, para interpretar as aes e comunicar com o sistema gerenciador Web; e (iii) Sistema para atualizao de firmware do Arduino, desenvolvido para simplificar as etapas de atualizao do Arduino, sem a necessidade da IDE de desenvolvimento. Entre os diferenciais existentes na ferramenta InoSensor, em comparao a solues similares existentes, destaca-se a capacidade de monitoramento remoto de sensores atravs de redes locais ou Internet e de uso da soluo por pessoas sem conhecimento em programao, pois as configuraes dos sensores e atuadores so realizadas pelo servidor Web. Este projeto teve como objetivo relacionar as diferentes reas de conhecimento estudadas no curso de Especializao em Desenvolvimento de Software. A soluo desenvolvida responsvel por apresentar uma alternativa de baixo custo na rea de Domtica e de fcil utilizao, pois seu uso no necessita de conhecimentos em programao.

Palavras-chave: Arduino. Monitoramento de sensores. Eletrnica. Domtica.

ABSTRACT

YEBAHI, Haissam. InoSensor: Management Tool for Arduino Sensors. 2013. 141 f. Monograph (Ps-graduao Lato Sensu de Especializao em Desenvolvimento de Software) - Universidade do Estado de Santa Catarina. Programa de Ps-graduao em Desenvolvimento de Software, So Bento do Sul, 2013.

The technologies are becoming more present on people's lives. Over time, new solutions come up to facilitate the execution of manual works and reduce the time spent on routine tasks that could be executed by electronic devices more effectively and controlled. Regardless the environment that it is applied, Automation can provide resource management more efficiently and sustainably in residential and industrial environments. Home Automation consists in devices and systems interconnected through a network, which are responsible for providing a mechanism for monitoring and managing the related environment. Home Automation is increasing its accessibility due to the large spread and low cost provided by the growing number of manufacturers of these devices. The use of integrated solutions generates numerous advantages such as cost reduction, simple installation and system expansion. There are available different platforms for development of systems based on microcontrollers fairly simple and with a relative low costs. Arduino is an open source platform that combines different hardware types and a standard architecture made by analog and digital ports with an Atmel microcontroller. This microcontroller is responsible for managing sensors and peripherals connected to the Arduino. Despite the simplicity of the platform, the development for solutions requires basic knowledge about electronics and programming. According to this concept, the InoSensor tool was developed to facilitate the use of sensors and enable easy management and monitoring of the Arduino platform remotely, with no need to perform programming of the firmware whenever is needed to modify sensors settings. The InoSensor solution consists in the following modules: (i) a Web management system, responsible to register the Arduino, its sensors and the actions that must be performed when an event occurs; (ii) Arduino firmware, to interpret the action and

communicate with the Web Management System; and (iii) firmware update wizard, developed to simplify the steps for updating the Arduino with no need to use Arduinos IDE. Among the existing differentials in InoSensor tool, compared to existing solutions, there is the ability of remote monitoring sensors across a local network or the Internet, and the use of the solution by people without programming knowledge because the sensors and actuators setting are carried out on the Web server. This Project aimed to relate the different knowledge areas studied in the course of Software Development Specialization. The developed solution is responsible for presenting a low-cost and easy to use alternative in Home Automation area, because no programming knowledge is required to use this tool. Keywords: Arduino. Sensors monitoring. Electronic

Automation. Home automation.

LISTA DE ILUSTRAES Figura 1 Interdisciplinaridade na Automao .................................... 26 Figura 2 Exemplos de sensores para Arduino .................................... 28 Figura 3 Exemplo de sensor de umidade do solo ............................... 31 Figura 4 Mdulo de comunicao sem fio Xbee ................................ 33 Figura 5 Transmissor X10 .................................................................. 34 Figura 6 Exemplo de Receptor ........................................................... 35 Figura 7 Esquemtica de comunicao dos mdulos IHC ................. 37 Figura 8 Primeiro modelo de Arduino projetado ............................... 40 Figura 9 Modelo atual do Arduino Uno ............................................. 40 Figura 10 Arduino Mega .................................................................... 41 Figura 11 Principais componentes do hardware do Arduino ............. 41 Figura 12 Alimentao de energia do Arduino .................................. 42 Figura 13 Portas de alimentao de energia para sensores ................. 43 Figura 14 Identificao de operao na comunicao serial .............. 44 Figura 15 Microcontrolador Atmel no Arduino ................................. 45 Figura 16 Estrutura interna de um microcontrolador Atmel .............. 46 Figura 17 Arquitetura Harvard ........................................................... 47 Figura 18 Boto para reiniciar o Arduino........................................... 49 Figura 19 Conectores de expanso ..................................................... 51 Figura 20 Shields sobrepostos e conectados sobre um Arduino ......... 52 Figura 21 Exemplo de circuito integrado em um sensor .................... 53 Figura 22 Portas utilizadas pelo shield ethernet no Arduino Mega.... 56 Figura 23 Exemplo de sketch carregada na IDE do Arduino ............. 57 Figura 24 Seleo do modelo do Arduino na IDE ............................. 58 Figura 25 Framework Noduino .......................................................... 60 Figura 26 Ferramenta Breakout.......................................................... 61 Figura 27 Viso macro da representao do sistema .......................... 65 Figura 28 Sensor Temperatura e Umidade DHT11 ............................ 66 Figura 29 Fotoresistor ........................................................................ 66 Figura 30 Sensor de chama ................................................................ 67 Figura 31 Sensor de gs ..................................................................... 67 Figura 32 Sensor de vibrao ............................................................. 68 Figura 33 Sensor magntico ............................................................... 68 Figura 34 Sensor presena PIR .......................................................... 69

Figura 35 Rel .................................................................................... 69 Figura 36 LED RGB .......................................................................... 70 Figura 37 Buzzer ................................................................................ 70 Figura 38 Arduino conectado protoboard ....................................... 72 Figura 39 Modelo de protoboard ....................................................... 72 Figura 40 Shield ethernet ................................................................... 73 Figura 41 Diagrama de casos de uso .................................................. 82 Figura 42 Diagrama de pacotes PHP do framework CodeIgniter ...... 84 Figura 43 Diagrama de pacotes ExtJS ............................................... 87 Figura 44 Diagrama de classes Java................................................... 88 Figura 45 Diagrama entidade relacionamento ................................... 90 Figura 46 Diagrama de atividades...................................................... 92 Figura 47 Diagrama MVC da aplicao InoSensor ........................... 96 Figura 48 Prompt de comando do Arduino Builder........................... 98 Figura 49 Estrutura simplificada do arquivo CSV ........................... 100 Figura 50 Tela inicial da ferramenta InoSensor ............................... 102 Figura 51 Tela de usurios da ferramenta InoSensor ....................... 103 Figura 52 Tela de detalhes do sensor ............................................... 104 Figura 53 Exibio das configurao de portas do Arduino ............ 105 Figura 54 Lista de Arduinos cadastrados ......................................... 106 Figura 55 Tela de cadastro de Arduino ............................................ 107 Figura 56 Lista de sensores e aes do Arduino .............................. 108 Figura 57 Tela para cadastro de sensor ............................................ 109 Figura 58 Tela para cadastro de ao de um sensor ......................... 110 Figura 59 Tela de verificao de configurao ................................ 111 Figura 60 Tela de notificaes ......................................................... 112 Figura 61 Tela do assistente de configurao .................................. 113 Figura 62 Memria utilizada pelo Arduino Mega2560.................... 119 Figura 63 Memria utilizada pelo Arduino Uno .............................. 120

LISTA DE QUADROS Quadro 1 Comparao da especificao dos Arduinos ...................... 51 Quadro 2 Comparativo com ferramentas similares ............................ 62 Quadro 3 Tipos de portas utilizadas por cada sensore ....................... 71 Quadro 4 Componentes eletrnicos do projeto ................................ 116 Quadro 5 Equipamentos para testes do projeto ................................ 117

LISTA DE ABREVIATURAS E SIGLAS ADC AJAX ALU API CABA CEDIA CI CPU DHCP EEPROM ER FTDI GLP GND GPRS GSM HTML HTTP I2C IDE IHC IP JSON KB LCD LDR LED MAC MISO MOSI MVC Analog Digital Convert Asynchronous JavaScript And XML Arithmetic Logic Unit Application Programming Interface Continental Automated Buildings Associations Custom Electronic Design and Installation Association Circuito Integrado Central Processing Unit Dynamic Host Configuration Protocol Electrically Erasable Programmable Read-Only Memory Entidade Relacionamento Future Technology Devices International Gs Liquefeito de Petrleo Ground General Packet Radio Service Global System for Mobile Hyper Text Markup Language Hyper Text Transfer Protocol Inter Integrated Circuit Integrated Development Environment Intelligent Home Control Internet Protocol JavaScript Object Notation Kilobyte Liquid Crystal Display Light Dependent Resistor Light Emitting Diode Media Access Control Master In Slave Out Master Out Slave In Model View Controller

OSGI OSI PC PDT PHP PING PIR PWM P2P RAM RGB ROM RX SCK SMD SPI SRAM TCP TX UDP UML USART USB

Open Service Gateway Initiative Open System Interconnection Program Counter PHP Development Tool Hypertext Preprocessor Packet Internet Grouper Passive InfraRed Pulse Width Modulation Peer to Peer Random Access Memory Red Green Blue Read Only Memory Receiver Serial Clock Semi Metalic Disc Serial Peripheral Interface Static Random Access Memory Transmission Control Protocol Transmitter User Datagram Protocol Unified Modeling Language Universal Synchronous Asynchronous Receiver Transmitter Universal Serial Bus

SUMRIO 1 1.1 1.2 1.3 1.3.1 1.3.2 1.4 2 2.1 INTRODUO ....................................................................... 18 FORMULAO DO PROBLEMA ......................................... 19 SOLUO PROPOSTA........................................................... 20 OBJETIVOS .......................................................................... 201 Objetivo geral .......................................................................... 21 Objetivos especficos ............................................................... 21 METODOLOGIA ..................................................................... 22 FUNDAMENTAO TERICA ......................................... 25 AUTOMAO......................................................................... 25

2.1.1 Sensores.................................................................................... 27 2.2 2.3 2.3.1 DOMTICA ............................................................................. 29 SOLUES PARA AUTOMAO DOMTICA ................. 33 X10............................................................................................ 33

2.3.3 Sistema Lonworks ................................................................... 38 2.4 2.4.1 ARDUINO ................................................................................ 39 Hardware ................................................................................. 39

2.4.1.1 Fonte de alimentao ................................................................ 41 2.4.1.3 Microcontrolador ...................................................................... 44 2.4.1.4 Reset.......................................................................................... 49 2.4.1.5 Conectores de expanso e portas............................................... 49 2.4.1.6 Shields ....................................................................................... 52 2.4.1.7 Sensores .................................................................................... 53 2.4.2 Comunicao ........................................................................... 53 2.4.2.1 Redes e Internet......................................................................... 54 2.4.3 Armazenamento de Dados Externo ....................................... 55

2.4.4 Plataforma de Desenvolvimento............................................. 56 2.4.4.1 Compilao de cdigo ............................................................... 59 2.4.5 Modelos e variantes ................................................................. 59 2.5 FERRAMENTAS SIMILARES................................................ 60

2.5.1 Noduino .................................................................................... 60 2.5.2 Breakout ................................................................................... 61 2.5.3 Arduino-Homebot ................................................................... 61 2.6 2.7 3 3.1 ANLISE COMPARATIVA ENTRE AS FERRAMENTAS . 62 CONCLUSES DO CAPTULO ............................................. 63 PROJETO ................................................................................ 64 COMPOSIO DO SISTEMA ................................................ 64

3.1.1 Sensores Utilizados .................................................................. 65 3.1.2 Plataforma de Prototipao.................................................... 71 3.1.3 Shield ethernet e SD ................................................................. 73 3.2 COMPORTAMENTO DO SISTEMA ...................................... 73

3.2.1 Aes ......................................................................................... 74 3.3 PROTOCOLO DE COMUNICAO...................................... 75

3.3.1 Monitor de Notificaes .......................................................... 75 3.4 MODELAGEM DO SISTEMA ................................................ 76

3.4.1 Requisitos ................................................................................. 76 3.4.1.1 Requisitos Funcionais ............................................................... 76 3.4.1.2 Regras de Negcio .................................................................... 77 3.4.1.3 Requisitos No-Funcionais........................................................ 79 3.4.2 Casos de Uso ............................................................................ 80 3.4.3 Diagramas de Pacotes e Classes ............................................. 83 3.4.4 Diagrama Entidade-Relacionamento..................................... 89

3.4.5 Diagrama de Atividades ......................................................... 92 3.5 4 4.1 4.2 CONCLUSES DO CAPTULO ............................................. 93 IMPLEMENTAO .............................................................. 94 PADRES DE PROJETO MVC .............................................. 94 TECNOLOGIAS E FERRAMENTAS ..................................... 94

4.2.1 Servidor Web ........................................................................... 94 4.2.2 ExtJS ........................................................................................ 95 4.2.3 C/C++ ....................................................................................... 96 4.2.4 Java .......................................................................................... 97 4.2.5 Arduino Builder ...................................................................... 97 4.3 4.4 4.5 BANCO DE DADOS................................................................ 98 PROTOCOLO DE CONFIGURAES DO ARDUINO ........ 99 APRESENTAO DA FERRAMENTA .............................. 101

4.5.1 Mdulo Web InoSensor ........................................................ 101 4.5.1.1 Cadastro de Usurios .............................................................. 102 4.5.1.2 Configurao Geral ................................................................. 103 4.5.1.3 Configurao de E-mail .......................................................... 103 4.5.1.4 Tipo de Ao ........................................................................... 103 4.5.1.5 Sensor...................................................................................... 104 4.5.1.6 Tipo de Porta ........................................................................... 104 4.5.1.7 Modelo de Arduino ................................................................. 105 4.5.1.8 Arduino ................................................................................... 105 4.5.1.9 Monitoramento ........................................................................ 111 4.5.2 Mdulo Atualizao de Firmware ....................................... 113 4.6 5 CONCLUSES DO CAPTULO ........................................... 113 TESTES E VALIDAO .................................................... 115

5.1 5.2 5.3 5.4 5.5 6 6.1

TESTES DO FIRMWARE DO ARDUINO ........................... 115 TESTES DE INTEGRAO ................................................. 117 TESTE DE ESCALABILIDADE DO FIRMWARE .............. 118 PROBLEMAS IDENTIFICADOS.......................................... 119 CONCLUSES DO CAPTULO ........................................... 121 CONCLUSES ..................................................................... 122 TRABALHOS FUTUROS ...................................................... 124 REFERNCIAS .................................................................... 125 APNDICES .......................................................................... 128

18 1 INTRODUO O uso de dispositivos eletrnicos, seja para a realizao de tarefas do cotidiano ou para Automao industrial, est presente nos mais variados ambientes. O simples fato de utilizar um sensor infravermelho para detectar a presena de movimento, ou ligar uma lmpada automaticamente ao escurecer, envolve componentes eletrnicos que reduzem a necessidade de executar tarefas manualmente. Independente da aplicao, o uso de tecnologia para Automao, seja para residncias, empresas ou indstrias, proporciona o gerenciamento de recursos de forma bastante eficiente e sustentvel, alm de obter diversos benefcios como reduo de custos, manuteno e segurana (DIAS; PIZZOLATO, 2004). A automao residencial, tambm conhecida como Domtica, formada por um conjunto de dispositivos e equipamentos interconectados atravs de uma rede para comunicao. Nesse contexto, as informaes so coletadas e processadas, conforme as regras so definidas. Determinadas aes podem ser executadas com o objetivo de supervisionar ou gerenciar o ambiente em que esto inseridas e assim satisfazer as necessidades de comunicao, conforto e segurana (DIAS; PIZZOLATO, 2004). Devido s constantes mudanas e s necessidades individuais de cada cenrio, o comportamento de sistemas automatizados deve proporcionar flexibilidade e uma fcil adaptao s condies do ambiente (SGARBI; TONIDANDEL, 2006). Para Sousa (2009), com a crescente popularizao da Internet, tornou-se possvel desenvolver novos modelos de sistema baseados em aes executadas de forma remota e transparente para controle e atuao de forma bastante rpida e segura. Atualmente a velocidade de acesso a rede mundial de computadores, possibilita que as informaes sejam transmitidas por diferentes meios e entre dispositivos geograficamente distribudos, sem a necessidade de altos investimentos em infraestrutura. Esto disponveis no mercado, plataformas que permitem a programao de microcontroladores de forma bastante simplificada a custos relativamente baixos se comparados prototipao de hardware customizado para Automao. Arduino uma das plataformas para prototipao e desenvolvimento baseada em microcontroladores mais populares da atualidade. Em 2011, j haviam sido vendidas mais de trezentas mil

19 unidades da verso original. Isso se deve principalmente sua caracterstica open source1, o que torna possvel o desenvolvimento de diversas solues para uma mesma arquitetura (TORRONE, 2011). Sua concepo envolve a combinao de diferentes modelos de hardware, empregados atravs de uma arquitetura e software padro para a prototipao de circuitos eletrnicos sem exigir grandes conhecimentos, pois grande parte dos componentes so construdos para facilitar a utilizao de sensores. Desenvolvida para controlar o ambiente em que est inserida, a interao entre os componentes na plataforma Arduino ocorre por meio dos sinais recebidos por sensores conectados as portas analgicas e digitais existentes na placa principal. O gerenciamento realizado por um microcontrolador Atmel AVR. A programao feita com o uso de uma variante da linguagem C, que permite criar projetos autnomos ou a comunicao com software de outros dispositivos eletrnicos (Arduino, 2013). Ainda que a simplicidade da plataforma facilite o desenvolvimento das mais variadas solues, necessrio que os interessados, alm de conhecimento em eletrnica bsica, tambm tenham conhecimentos mais avanados de lgica e programao. Devido ausncia de um sistema operacional, a codificao de microcontroladores com limitaes de processamento e memria exige maior ateno na elaborao do software que estar embarcado no dispositivo, pois todo controle necessrio deve estar presente na soluo. 1.1 FORMULAO DO PROBLEMA Muitas das aes envolvidas ao se criar projetos baseados em sensores incluem padres e rotinas em cdigo programado bastante semelhantes, mas que necessitam de retrabalho para ajustar as aes executadas. Essas atividades despendem tempo e dificultam a manuteno, quando uma simples parametrizao poderia adaptar as regras e comportamentos desejados a um novo contexto. Segundo alguns princpios presentes na Automao e Domtica, necessrio que haja uma forma simples de gerenciar os dispositivos e
1

Software de utilizao livre e sem custo que permite a alterao e distribuio de cpias de forma gratuita de acordo com a licena de software livre, visando beneficiar a comunidade de todos os desenvolvedores e usurios (SEABRA, 2007)

20 as aes que devem ser executadas com base nas regras estabelecidas. Levando-se em conta o ambiente que se deseja controlar ou monitorar, preciso que se considere a possibilidade de realizar um monitoramento remoto de forma centralizada, para facilitar e acelerar o processo de anlise de informaes. A plataforma Arduino possui solues simples para as mais variadas tarefas, porm necessrio programar os sensores sempre que for preciso ajustar as condies e aes que devem ser automatizadas. Esto disponveis na Internet solues com as quais possvel executar comandos de forma remota no Arduino com o uso da comunicao serial. Isso acaba por limitar a autonomia do dispositivo em ambientes distribudos, devido necessidade de um computador para prover o servio de conexo da rede ou Internet para o Arduino. 1.2 SOLUO PROPOSTA Neste trabalho, foi desenvolvida a ferramenta InoSensor, com o propsito de facilitar e simplificar o processo de adio de sensores e permitir o monitoramento e controle de Arduino em uma rede local ou Internet. Sua utilizao estende-se como uma ferramenta de apoio para disciplinas como Eletrnica Bsica e Redes de Computadores, pois pode facilitar a compreenso de conceitos tericos aprendidos em cursos de graduao com foco em tecnologia ou para pessoas interessadas em alternativas para Automao de baixo custo. A proposta da soluo InoSensor contempla o desenvolvimento dos seguintes mdulos: (i) Sistema Web para gerenciamento de Arduino; (ii) Firmware para interpretar as aes e comunicar com o sistema gerenciador Web; e (iii) Sistema para atualizao de firmware de Arduino. A execuo e desenvolvimento deste projeto justificam-se por contemplar e integrar diversas reas do curso de Especializao de Desenvolvimento de Software, como engenharia de software, sistemas web, padres de projeto, programao, sistemas distribudos, redes de computadores e banco de dados, alm de contribuir para o meio acadmico como uma ferramenta de apoio para disciplinas como Eletrnica Bsica, Programao e Sistemas Distribudos.

21 1.3 OBJETIVOS Esta subseo define as metas e caractersticas necessrias para que a proposta da ferramenta desenvolvida atinja os objetivos definidos para a soluo do problema. 1.3.1 Objetivo geral Desenvolver um sistema de monitoramento de sensores para a plataforma Arduino por meio de uma rede local ou Internet para simplificar o processo de ajuste de configuraes, sem a necessidade de reprogramar o firmware em caso de mudanas de regras e aes. 1.3.2 Objetivos especficos Estudar os conceitos relacionados Domtica, sensores, comunicao via rede ethernet e armazenamento de dados para Arduino; Pesquisar solues similares de ferramentas para gerenciamento de sensores com Arduino; Pesquisar as tecnologias necessrias para o desenvolvimento do projeto; Elaborar a modelagem conceitual do sistema; Implementar o sistema; Mdulo para gerenciamento de Arduino; Mdulo para cadastro de sensores; Sensor de temperatura e umidade; Rel; Foto resistor; Sensor de fogo; Sensor de vibrao; Sensor magntico; LED RGB; Buzzer; Sensor de presena infravermelho. Mdulo para cadastro de aes Enviar e-mail; Acionar sensor; Ligar LED RGB.

22 Mdulo para reset remoto de alarme; Mdulo para atualizao de configuraes; Firmware para controle de sensores e aes para Arduino; Sistema de apoio atualizao de firmware; Desenvolver protocolo para troca de informaes entre gerenciador e Arduino. Testar e validar a implementao das funcionalidades propostas pela ferramenta; Documentar o desenvolvimento e resultados alcanados.

1.4 METODOLOGIA A estrutura deste trabalho foi dividida em seis grandes etapas, listadas abaixo: Levantamento bibliogrfico: Documentar os temas envolvidos neste trabalho para facilitar a compreenso e selecionar as solues mais adequadas para o desenvolvimento da ferramenta InoSensor; Fundamentao terica sobre a rea de Automao e Domtica na rea da Computao; Fundamentao terica sobre Arduino, shields e sensores com o objetivo de identificar as caractersticas e particularidades da plataforma, bem como os mecanismos necessrios para gerenciar os dispositivos conectados; Pesquisa de solues similares para Automao com Arduino a fim de avaliar inovaes e solues eficazes existentes. Anlise tcnica: Estudo das tecnologias necessrias para o desenvolvimento da ferramenta proposta, suas particularidades e compatibilidades; Estudo das tecnologias envolvidas na ferramenta: JavaScript Object Notation (JSON), framework ExtJS, Javascript, PHP, MySQL, Java e C++ para microcontroladores Atmel presentes no Arduino; Padres de projetos Model View Controller (MVC) para PHP e JavaScript, com o objetivo de facilitar a ampliao da ferramenta em verses futuras; Avaliar os protocolos de comunicao e bibliotecas disponveis para Arduino, tanto para comunicao via

23 ethernet quanto para armazenamento de dados em carto de memria SD; Pesquisar solues para atualizao de firmware sem a necessidade da IDE de desenvolvimento para Arduino. Levantamento de requisitos e modelagem: Definio dos requisitos e funcionalidades da ferramenta proposta; Definio dos requisitos e regras de negcio necessrios para contemplar o funcionamento da ferramenta InoSensor; Modelagem Unified Modeling Language (UML) do sistema, a anlise dever abranger a especificao e componentes de software necessrios para desenvolver os mdulos propostos no escopo do trabalho. Para isto sero modelados, casos de uso, diagrama de atividades e diagrama de pacotes e diagrama de classes; Definio do modelo Entidade Relacionamento (ER) para o banco de dados utilizado no servidor Web. Desenvolvimento: Desenvolvimento do sistema, seguindo o escopo e a definio do projeto; Definio da estrutura de banco de dados para suprir as necessidades do sistema; Implementao dos mdulos propostos conforme a definio dos requisitos. Todo o desenvolvimento deve seguir a modelagem e as funcionalidades descritas no escopo do trabalho. Testes e validao: Executar testes e validaes da soluo proposta e verificar as funcionalidades desenvolvidas, corrigindo-as caso seja necessrio; Testes das funcionalidades presentes, avaliando se os servios implementados alcanaram os resultados esperados; Testes de comunicao de rede e atualizao de dispositivos via ethernet para certificar-se de que a atualizao executada corretamente. Documentao: Durante o projeto, so registradas as etapas executadas desde o levantamento do problema, a fundamentao terica, a proposta da soluo, o desenvolvimento, testes, validaes, os resultados finais e as concluses. Esta documentao deve permitir que interessados possam compreender a soluo, acrescentar novas

24 funcionalidades em verses futuras e efetuar os mesmos testes executados para a validao do projeto. 1.5 ESTRUTURA DO TRABALHO No primeiro captulo, apresentada uma introduo sobre o projeto, objetivos, a devida importncia do projeto na assimilao e aplicao dos temas abordados no curso de Especializao em Desenvolvimento de Software. No segundo captulo (Fundamentao Terica), so definidos os conceitos relacionados a Automao, Domtica, solues para automao residencial e Arduino e meios de comunicao, alm de um estudo de solues similares disponveis, para comparao com a ferramenta InoSensor. O terceiro captulo (Projeto) descreve as especificaes das funcionalidades da ferramenta InoSensor, sua documentao, diagrama de atividades da UML, requisitos e regras de negcio, diagrama de pacotes, diagrama de classes e modelo ER do banco de dados. No quarto captulo (Implementao) e quinto captulo (Apresentao da Ferramenta), so apresentados os resultados obtidos durante a implementao da ferramenta, descrevendo as funcionalidades implementadas. O quinto captulo apresenta os resultados dos testes aplicados para avaliar a conformidade dos requisitos e verificar a integrao entre os mdulos desenvolvidos. O sexto e ltimo captulo apresentam as concluses, dificuldades encontradas durante o desenvolvimento e sugestes para trabalhos futuros que possam aprimorar e expandir as funcionalidades presentes na ferramenta.

25 2 FUNDAMENTAO TERICA Neste captulo, so abordados os conceitos necessrios para o projeto, a fim de servir como base para o desenvolvimento da soluo proposta pela ferramenta InoSensor. A seo 2.1 apresenta o estudo sobre Automao, sua evoluo com o uso de computadores e os conceitos relacionados a esse trabalho, como sensores e atuadores. Na seo 2.2, so abordados os temas relacionados a Domtica e os benefcios que podem ser gerados com o seu uso. Na seo 2.3, so apresentadas algumas das solues existentes no mercado para a Automao residencial e predial. Os estudos da plataforma Arduino, suas particularidades e os conceitos necessrios ao desenvolvimento da soluo proposta, so apresentados na seo 2.4. A seo 2.5 apresenta um estudo de ferramentas similares existentes e um comparativo entre as funcionalidades das ferramentas pesquisadas e a ferramenta InoSensor. Por fim, na seo 2.6, so apresentadas as consideraes dos estudos da fundamentao terica. 2.1 AUTOMAO Desde a antiguidade o homem tem buscado ferramentas para reduzir a carga de trabalho e para facilitar a execuo de tarefas de forma automatizada, desenvolvendo instrumentos que o auxiliem a controlar e alcanar seus objetivos de forma mais rpida. A rea de Automao foi impulsionada com o crescimento adjunto da Revoluo Industrial e trouxe diversos benefcios, tanto para o setor industrial, com a introduo das mquinas para substituir o homem e melhorar os processos produtivos, quanto para as pessoas, que puderam despender seu tempo em atividades mais importantes para melhorar a sua condio de vida (BIONDO, 2011). Para Martins (2012), a Automao pode ser definida por um conjunto de tcnicas que possibilitam construir sistemas ativos, capazes de atuar de forma autnoma com base em informaes recebidas no meio que atuam, de forma bastante eficiente. Uma das caractersticas presentes na Automao a realizao de trabalhos por sistemas apoiados por computadores, com o objetivo de reduzir a interveno humana e obter maior segurana, qualidade e rapidez. Um erro comum confundir a Automao com automatizao, que est relacionada execuo de movimentos automticos, repetitivos e mecnicos.

26 A Automao permite a integrao de conhecimentos, substituindo observao, esforos e decises humanas por dispositivos (mecnicos, eltricos e eletrnicos) e software desenvolvido para gerenciamento e controle. Essa integrao ilustrada na Figura 1 e demonstra a interdisciplinaridade entre reas afins como: (i) a computao, responsvel por prover os mecanismos necessrios modelagem, anlise e simulao do software, (ii) a eletrnica, responsvel por processar os sinais e controlar os equipamentos, (iii) a mecnica, formada por todos os equipamentos conectados que formam a parte fsica do sistema e (iv) sistema de controle, responsvel por definir o comportamento e aes desejadas do sistema (MARTINS, 2012).
Figura 1 Interdisciplinaridade na Automao

Fonte: ROSARIO (2009)

Antes da Automao ser realizada por computadores, o controle de tarefas e comandos de mquinas era feito por circuitos com vlvulas eletrnicas e equipamentos de controle, medio eltrica e pneumtica conectados a fios eltricos. A adaptao a um novo contexto exigia a modificao nas conexes, sendo que em muitos casos tornava-se mais barato substituir o sistema por um novo painel controlador (ROSARIO, 2009).

27 Por volta da dcada de 70, os avanos tecnolgicos permitiram a substituio das vlvulas por transistores e dos fios por circuitos integrados, trazendo inmeros benefcios. Esses avanos possibilitaram transferir as modificaes de hardware para o software e deram origem aos Controladores Lgicos Programveis (CLPs), que possuem memria programvel e executam instrues de entrada e sada (MARTINS, 2012). A produo desses equipamentos em larga escala, possibilitou o desenvolvimento de microprocessadores dedicados a um baixo custo. A utilizao de componentes eletrnicos como sensores, atuadores e circuitos controladores no est mais limitada a ambientes industriais e so empregados em diversas reas de aplicaes como robtica, medicina, automao predial e Domtica (MARTINS, 2012). Qualquer que seja o emprego da Automao, necessrio que existam mecanismos para determinar condies variveis (e.g., temperatura, luminosidade, umidade) do ambiente e informar ao circuito eletrnico a ocorrncia de eventos para avaliar e comandar a execuo de aes desejadas (WENDLING, 2010). Dois dos principais elementos que podem ser encontrados na Automao so os sensores e os atuadores. 2.1.1 Sensores Um sensor pode ser descrito como um dispositivo eletroeletrnico que possui a propriedade de transformar uma grandeza fsica (e.g., calor, luz, som, movimento) relacionada ao material utilizado na fabricao do sensor em um sinal eltrico. Pode-se citar como exemplos: (i) sensores de fotodiodos para converso eltrica/luminosa, (ii) termistores para converso eltrica/trmica e (iii) sensores magnticos para converso eltrica/magntica (WENDLING, 2010). A Figura 2 ilustra diferentes tipos de sensores que podem ser utilizados com a plataforma Arduino.

28
Figura 2 Exemplos de sensores para Arduino

Fonte: Adaptado de DX2 (2013)

Os sinais gerados por sensores podem ser manipulados, armazenados ou servir como base para processamento por outros dispositivos. Podem ser utilizados em sistemas de monitoramento para detectar abertura de portas, movimento de pessoas, vibraes, rudos, princpios de incndio e temperatura (SOUSA, 2009). Alguns sensores no possibilitam a leitura do sinal gerado diretamente pelo sistema de controle, sendo necessrio um circuito de interface responsvel por produzir um sinal que possa ser lido pelo controlador. O dispositivo completo, formado pelo sensor e o circuito de interface, denominado transdutor. Como exemplos, podem ser citados os transdutores de temperatura, deteco de presena, velocidade, campo eletromagntico, etc. (WENDLING, 2010). 2.1.2 Atuadores Um sistema automatizado deve possibilitar a execuo de aes baseadas em eventos e informaes coletadas do ambiente pelos sensores. Os atuadores agem sobre o ambiente atravs de um sinal gerado pelo controlador e normalmente so compostos por uma interface eletromecnica que tem suas caractersticas alteradas conforme os impulsos eltricos recebidos (PINHEIRO, 2013). Como os atuadores esto relacionados interface de sada, existem basicamente dois tipos:
2

Disponvel em: http://www.dx.com/

29 Sadas digitais: representadas por valores discretos, que permitem determinar se uma grandeza fsica atingiu um valor predeterminado e admitem o estado ligado e desligado. Essas sadas possibilitam controlar dispositivos como rels, solenoides, LEDs (WENDLING, 2010); Sadas analgicas: convertem valores contnuos em sinais de sada de tenso, normalmente variando entre 0V e 5V. Essas sadas podem controlar motores e luminosidade (ALIEVI, 2005).

2.2 DOMTICA Por volta dos anos 80, a Automao presente nas indstrias alcanou as edificaes corporativas e originou um novo conceito denominado de edifcio inteligente, que possibilitou o emprego de componentes e solues para proporcionar diversos benefcios, tais como: gerenciamento, conforto, economia e preveno de acidentes (DIAS, PIZZOLATO, 2004). A aplicao dos conceitos de Automao em edifcios torna os ambientes mais produtivos, saudveis e eficientes, alm de contribuir para o aumento da produo e reduo de custos operacionais. Estes fatores permitiram o emprego mais fcil da Automao em ambientes comerciais e industriais, em relao aos habitacionais (DIAS, PIZZOLATO, 2004). Com o passar dos anos, os mesmos princpios de Automao passaram a ser aplicados nas residncias, utilizando equipamentos direcionados a criao de casas inteligentes com nfase no controle de recursos, iluminao, segurana, temperatura, conforto e entretenimento. Com a grande popularizao, a Automao residencial passou a ter uma designao prpria, conhecida como Smart House ou Intelligent House. No Brasil, empregado o termo Domtica, sob influncia do termo francs Domotique (ROSARIO, 2009). A Domtica agrega diversos conceitos de outras cincias, como arquitetura, engenharia, computao e possui o objetivo de oferecer novas possibilidades, introduzidas pelas tecnologias digitais frente as necessidades do usurio, e uma maior interao com a residncia (BOLZANI, 2007). Um sistema Domtico formado por diversos componentes, dispositivos e sistemas interconectados por meio de uma rede de comunicao. Essa rede responsvel pela troca de informaes e pela

30 execuo de aes para supervisionar e gerenciar o ambiente no qual o sistema est inserido (DIAS, PIZZOLATO, 2004). A Automao residencial est cada vez mais acessvel, devido ao barateamento das tecnologias e ao aumento da concorrncia no setor. O uso de solues integradas gera ainda mais vantagens, podendo ser citadas a reduo de custos, maior facilidade para a instalao e expanses do sistema (ROSARIO, 2009). No Brasil, a Associao Brasileira de Automao residencial (AURESIDE) menciona que o emprego da Domtica em construes residenciais e prediais, alm de ser uma ferramenta de marketing, um diferencial para o setor, pois agrada tanto os desejos de pessoas interessadas por tecnologia, que esto sempre em busca de novidades, quanto pessoas que anseiam por maior segurana, ambas caractersticas que podem ser encontradas em sistemas de automao predial (DIAS, PIZZOLATO, 2004). As inmeras solues tecnolgicas que podem ser incorporadas na Domtica criam novas oportunidades, aumentando a qualidade de vida das pessoas e at mesmo removendo impedimentos que dificultam a mobilidade de pessoas portadoras de necessidades especiais, alm de possibilitar um maior racionamento no consumo de recursos como gua e luz e auxiliar na preservao do meio ambiente (DIAS, PIZZOLATO, 2004). Uma das utilidades da Domtica aliar o uso de dispositivos eletrnicos equipamentos da informtica de forma sistmica e possibilitar uma gesto integrada de recursos presentes em um ambiente. Segundo Rosrio (2009), essa cincia tem tornado a vida mais confortvel, segura e at mais divertida, com a programao de tarefas rotineiras para serem executadas de acordo com as necessidades. De face a essa nova realidade, as residncias podem usufruir de benefcios de sistemas denominados complexos, que no atuam somente como controladores, mas sim como gerenciadores, com a troca de informaes entre todos os sistemas que compem as instalaes automatizadas, para que as funcionalidades possam ser personalizadas pelo cliente (DIAS, PIZZOLATO, 2004). As necessidades de economia, conforto e segurana criam as condies ideais para viabilizar o emprego da Domtica em questes como (ROSRIO, 2009): Controle de Energia e gua: O uso de mdulos apropriados possibilita uma melhor gesto de recursos, levando-se em considerao os aspectos do ambientes que se deseja controlar.

31 possvel, por exemplo, o acionamento noturno de equipamentos, deteco de presena e desligamento automtico aps um determinado tempo. J para o racionamento de gua, possvel realizar o controle com o emprego de sensores de presena, boto temporizador, irrigao do solo conforme as condies de umidade da terra (Figura 3);
Figura 3 Exemplo de sensor de umidade do solo

Fonte: DX (2013)

Controle de Segurana: Existem diversos sensores para controle da segurana em diferentes nveis, que determinam as aes a serem executadas, baseadas nos eventos ocorridos. Com apenas alguns componentes, possvel detectar situaes de emergncia como: vazamento de gs, deteco de presena, preveno de incndios, controles de acessos, abertura de portas e janelas e emisso de sinais sonoros ou luminosos. O uso de sensoriamento em um sistema de alarme possibilita proteger reas comercias e residncias e foi desenvolvido para manter as dependncias seguras de forma simples, executando aes como disparo de alarmes, acendimento de lmpadas, etc; Controle de Temperatura e Umidade: So fatores de comodidade. Atravs do controle trmico, possvel programar equipamentos de aquecimento, ventilao, desumidificadores e condicionadores de ar para serem ligados ou desligados e propiciar um melhor nvel de conforto, alm de gerar maior comodidade e propiciar o uso racional de energia.

32 Levando-se em conta as necessidades da Automao, primordial que os equipamentos sejam integrados e interligados com o objetivo de oferecer aos usurios a ampliao dos resultados desejados. Em relao tecnologia empregada, os sistemas de automao podem ser categorizados de duas formas (DIAS, PIZZOLATO, 2004): Centralizado: So os sistemas nos quais o processamento ocorre de forma centralizada em uma central de controle, onde so conectados todos os dispositivos presentes no circuito. Essa central responsvel por receber os sinais e informaes dos sensores e enviar os comandos das aes e ajustes que devem ser executados no sistema; Distribudo: Os dispositivos conectados possuem processamento inteligente, cada qual com uma funo especfica para atender uma necessidade do sistema. Os dispositivos apresentam-se conectados por meio de uma rede, realizando a comunicao e troca de informaes entre sensores e atuadores, alm de possibilitar o controle e monitoramento do sistema.

Independente da arquitetura, um sistema de Automao deve prover flexibilidade no desenvolvimento das solues e na integrao dos dispositivos, dessa forma necessrio escolher a tecnologia adequada ao projeto de Automao. Apesar dos benefcios propostos pela Domtica, ainda existem diversos desafios a serem superados principalmente por existirem poucos protocolos e dispositivos padronizados para a aplicao de solues em residncias, onde muitas destas solues so herdadas dos ambientes de Automao industrial. Devido crescente demanda, existem diversas entidades nacionais e internacionais que buscam definir mecanismos para padronizar o emprego de solues tecnolgicas residenciais, como a Continental Automated Buildings Associations (CABA), a Open Service Gateway Initiative (OSGI) e a Custom Electronic Design and Installation Association (CEDIA) (BOLZANI, 2007). Atualmente, no Brasil, existem normas internacionais relacionadas definio dos padres de cabeamento para sistemas de Automao. Destacam-se a ANSI/EIA/TIA-570-A para cabeamento residencial e a norma ANSI/EIA/TIA-862, para edifcios comerciais (PINHEIRO, 2004).

33 Um dos destaques no cenrio atual do mercado a Zigbee Alliance, responsvel por desenvolver um padro de redes sem fio (Figura 4) de baixo custo, tambm conhecido como Xbee, destinado a aplicaes embarcadas, formada por dezenas de empresas como Mitsubishi, Samsung, Cisco, Philips, Motorola, entre outras (DIAS, PIZZOLATO, 2004).
Figura 4 Mdulo de comunicao sem fio Xbee

Fonte: DX (2013)

2.3 SOLUES PARA AUTOMAO DOMTICA Grandes corporaes esto se unindo para formar consrcios e associaes para aperfeioar e desenvolver solues integradas de produtos e sistemas de Automao residencial. Nas subsees a seguir, so descritas algumas das solues convencionais existentes para aplicao da Domtica. 2.3.1 X10 Desenvolvida na dcada de 70 pela empresa escocesa Pico Electronics, uma tecnologia para controlar dispositivos em residncias atravs da transmisso de dados binrios pela corrente eltrica. Atualmente, o protocolo tambm est disponvel para operar via rdio frequncia (WOLLZ, 2012). Devido ao tempo de mercado, o sistema X10 um dos protocolos mais utilizados no mundo para Automao residencial, principalmente devido a expirao da patente no ano de 1997, que possibilitou a fabricao dos dispositivos por diferentes empresas, alm de uma grande difuso e diversificao de produtos (WOLLZ, 2012).

34 Uma das grandes vantagens desse sistema a facilidade de instalao, j que a comunicao feita na prpria estrutura de rede eltrica (DIAS, PIZZOLATO, 2004). Existem dois tipos de dispositivos no sistema X10, os transmissores e os receptores. Os transmissores (Figura 5) so responsveis por enviar sinais de comando para os equipamentos que sero controlados (ROSARIO, 2009). Existem diferentes tipos de controladores, podendo ser citados: (i) mdulo transmissor serial, para envio de comandos para a rede eltrica e gerenciamento dos receptores pelo computador; (ii) mdulo transmissor termostato, que possibilita ligar e desligar equipamentos com base na temperatura ajustada; (iii) mdulo transmissor para controle via telefone, pelo qual pode-se receber comandos via linha telefnica e controlar os equipamentos da rede.
Figura 5 Transmissor X10

Fonte: ROSARIO (2009)

Os receptores so os equipamentos que recebem os comandos dos transmissores, sendo que um receptor pode ser controlado por mais de um controlador (ROSARIO, 2009). Entre os modelos convencionais de receptores, podem ser citados: (i) o mdulo receptor de lmpada com funo de ligar, desligar, ajuste de intensidade luminosa (dimmer); (ii) mdulo receptor para tomada, para ligar e desligar equipamentos eltricos.

35 O funcionamento bastante simples. Cada receptor (Figura 6) deve ser configurado com um endereo formado por um cdigo da casa representado por uma letra (A-P), seguido por um identificador para o receptor (A1-A16), totalizando 256 endereos possveis de serem configurados. Aps a configurao, um transmissor conectado na mesma rede eltrica ou frequncia pode enviar um comando para controlar um equipamento em um endereo especfico ou at mesmo todos os equipamentos configurados em um mesmo cdigo de casa (ROSARIO, 2009).
Figura 6 Exemplo de Receptor

Fonte: ROSARIO (2009)

Os modelos mais simples de receptores no permitem que seu status seja detectado pelos transmissores. Os modelos que possibilitam desenvolver sistemas mais robustos com comunicao em mo dupla e retroalimentao de status, custam de duas a quatro vezes mais (WOLLZ, 2012). Apesar dos benefcios propostos pelo X10, existem limitaes que devem ser consideradas e solucionadas com o emprego de tcnicas e recursos apropriados. Em relao segurana, necessrio instalar filtros nas entradas da residncia para impedir a entrada ou sada de

36 sinais gerados por outros mdulos X10. Para casos em que a residncia utilize circuito bifsico ou trifsico, a transmisso do sinal deve ser feita em diferentes fases. Outro fator importante a limitao da velocidade de comunicao, pois a taxa mxima de transmisso de 60bps. Em condies que necessitam de maior velocidade e confiabilidade, deve-se optar por solues mais robustas e confiveis (DIAS, PIZZOLATO, 2004). 2.3.2 IHC A Inteligent Home Control (IHC) uma tecnologia proprietria para Automao residencial com comunicao via cabeamento estruturado. Baseada em uma arquitetura centralizada, os dispositivos presentes na instalao do sistema so conectados a um equipamento central, responsvel pelo gerenciamento local por um controle remoto ou, remotamente, com o uso de telefone, Internet e smartphones (DIAS, PIZZOLATO, 2004). A configurao do sistema feita atravs da programao das funes dos dispositivos em um software baseado em perguntas e respostas, responsvel por adaptar as necessidades e preferncias do usurio. Como o IHC desenvolvido em uma plataforma modular padronizada, suas funcionalidades podem ser adaptadas e expandidas de forma gradativa e implantadas em etapas (TERUEL, 2008). Entre os principais mdulos responsveis pelo funcionamento existentes no sistema IHC (Figura 7), podem ser citados (DIAS, PIZZOLATO, 2004): Mdulo gerenciador: responsvel pelo gerenciamento do sistema, uma unidade composta por um microprocessador responsvel por receber os comandos dos dispositivos e pelas aes feitas com base nas configuraes do usurio. Possui uma capacidade mxima de 128 entradas e 128 sadas (SCHNEIDER ELECTRIC, 2013); Mdulos de Entrada: Possibilitam ao sistema ler informaes do ambiente e so responsveis por receber os sinais provenientes de dispositivos acionadores conectados na rede. Cada mdulo de entrada possui 16 portas digitais; Mdulo de Sada: Possui a funo de acionar os dispositivos de sada conectados e ativar luzes e LEDs de acordo com o

37 estado dos equipamentos e do sistema. Cada mdulo de sada suporta 8 sadas digitais ou dimmerizadas; Mdulos de alimentao de energia: So empregados quando os mdulos de entrada e sada no fornecem corrente eltrica suficiente para equipamentos que necessitam de tenso prpria para o funcionamento; Mdulo de comunicao remota: Permite gerenciar e controlar os equipamentos do sistema pela linha telefnica ou Internet.
Figura 7 Esquemtica de comunicao dos mdulos IHC

Fonte: SCHNEIDER ELECTRIC (2013)

A tecnologia IHC pode ser considerada uma plataforma bastante slida com inmeras solues para Automao de residncias e edifcios, porm a arquitetura proprietria reduz a possibilidade de

38 integrar os equipamentos a outros sistemas e as funcionalidades de software esto limitadas s solues disponibilizadas pela empresa. 2.3.3 Sistema Lonworks Tambm conhecido como LON, foi projetado pela empresa Echelon Corporation em 2005. Foi originado de um grande conjunto de protocolos e do sistema Fieldbus, empregado na Automao Industrial na dcada de 60 (BIONDO, 2011). A principal motivao no desenvolvimento de um novo padro era fornecer uma plataforma comum para a interoperabilidade de dispositivos de diferentes fabricantes. A comunicao entre os equipamentos feita por cabeamento estruturado atravs do protocolo LonTalk, implementado com base no modelo Open Systems Interconnection (OSI) que permite distribuir o processamento de carga e controlar de dois at trinta e dois mil dispositivos (TERUEL, 2008). No sistema LON, o controle descentralizado. Os dispositivos denominados Ns, so compostos por um microcontrolador Neuron, comunicando-se por um protocolo Peer to Peer (P2P) entre os atuadores e sensores, sem a necessidade de transmitir as informaes para uma central de processamento. Esse sistema tambm faz a comutao das mensagens em diferentes meios fsicos, como fibra tica, infravermelho, radio frequncia, par tranado, bastando para isso que transmissores e receptores sejam compatveis a um mesmo meio (BIONDO, 2011). Todo o controle realizado pelo software Lonwork Network Service, composto por uma Application Programming Interface (API) para permitir a programao, gerenciamento e diagnstico, alm de suportar o protocolo IP que possibilita a integrao da rede com a Internet (BIONDO, 2011). A aplicao da tecnologia LON reconhecida pela American National Standards Institute (ANSI) e adotada como padro aberto para instalao em ambientes industriais, prediais e residenciais, alm de ser uma das trs tecnologias recomendadas para automao predial pela Inteligent Building Institute (IBI) (WOLLZ, 2012). Apesar dos benefcios propostos, a interoperabilidade entre equipamentos desenvolvidos por diferentes fabricantes baixa pois, por serem equipamentos importados, o custo de implantao torna-se caro para o uso na Domtica.

39 2.4 ARDUINO Arduino uma plataforma open source criada para a prototipao de circuitos eletrnicos de forma flexvel e foi desenvolvida com o intuito de ser utilizado por pessoas com conhecimentos bsicos em eletrnica, engenharia ou programao (GERTZ; JUSTO, 2012). Criado originalmente na Itlia no ano de 2005 por Massimo Banzi e David Cuartielles, Arduino um nome prprio originado de um rei italiano que significa forte amigo (WHEAT, 2011). A placa normalmente na cor azul o objeto mais conhecido da plataforma e composta por portas de conexo para comunicao com outros dispositivos. Um dos principais componentes presentes na placa principal do Arduino o microcontrolador AVR Atmel, responsvel pelo processamento e que pode ser facilmente programado com instrues para possibilitar a interao com o meio externo por meio das portas de entradas e sada (GERTZ; JUSTO, 2012). 2.4.1 Hardware Apesar de existirem diferentes modelos de placas, sua arquitetura de hardware bastante semelhante, sendo que as principais diferenas esto na capacidade de memria, processamento e o nmero de portas analgicas e digitais disponveis (BOXALL, 2013). O Arduino Uno (Figura 8) foi anunciado em setembro de 2011 e foi o marco inicial para o lanamento oficial da verso 1.0 do software de desenvolvimento. Nessa verso, a comunicao serial era feita com um conector SRS-232 e o hardware era equipado com um microcontrolador ATmega8 com frequncia mxima de 16MHz e 8KB de memria de programa (WHEAT, 2011). Desde o lanamento oficial, novas verses foram lanadas e suas funcionalidades aprimoradas. Nos modelos mais recentes (Figura 9), a comunicao serial feita por uma interface Universal Serial Bus (USB), com um circuito Future Technology Devices International (FTDI), que faz a converso de SRS-232 para USB (WHEAT, 2011).

40
Figura 8 Primeiro modelo de Arduino projetado

Fonte: WHEAT (2011) Figura 9 Modelo atual do Arduino Uno

Fonte: WHEAT (2011)

Semelhante ao Arduino UNO, o Arduino Mega (Figura 10) diferencia-se pelo tamanho um pouco maior, pela quantidade de portas disponveis e pelo emprego de um processador ATmega com maior capacidade de memria.

41
Figura 10 Arduino Mega

Fonte: WHEAT (2011)

O diagrama da Figura 11 apresenta uma arquitetura simplificada dos principais componentes presentes na placa de um Arduino: porta serial USB, fonte de energia, portas de entrada e sada (tambm conhecidas como conectores de expanso) e o microcontrolador. Os componentes deste diagrama so descritos nas subsees a seguir.
Figura 11 Principais componentes do hardware do Arduino

Interface Serial USB

Conectores de Expanso
Placa de I/O Arduino

Microcontrolador Atmel Fontes de Alimentao Conectores de Expanso

Fonte: Adaptado de WHEAT (2011)

2.4.1.1 Fonte de alimentao Por se tratar de um dispositivo eletrnico, necessrio que exista uma fonte de energia para o funcionamento do Arduino. A

42 alimentao de energia pode ser fornecida de trs formas (Figura 12): pela porta USB, pelo conector de alimentao externa ou pela porta de tenso no regulada (VIn) com limite de 5V. Nas placas atuais, mais de uma alimentao de energia pode ser usada, devido presena de um circuito inteligente capaz de identificar e selecionar a fonte de alimentao com maior voltagem. Este circuito regulador tambm possui a funo de estabilizar a tenso de 5V que ser fornecida para o circuito (WHEAT, 2011).
Figura 12 Alimentao de energia do Arduino

Fonte: WHEAT (2011)

A alimentao de energia, quando fornecida pela porta USB, prov uma tenso de 5V e corrente variando de 100mA quando conectado como um dispositivo no enumerado, e at 500mA quando conectado como um dispositivo enumerado (WHEAT, 2011). Essa energia pode ser suficiente para fornecer tenses de 3.3V e 5V nas portas de alimentao, para sensores de baixo consumo (Figura 13), porm para sensores e dispositivos que necessitam de maior carga (e.g., reles, motores, solenoides), deve-se considerar uma fonte de alimentao alternativa para lig-los, caso contrrio poder ocorrer uma sobrecarga de tenso, ocasionando a queima do circuito. Em alguns modelos de Arduino, existe um regulador de tenso de 3.3V utilizado principalmente por modelos de placas mais antigos na interface de comunicao USB FTDI (WHEAT, 2011). No mesmo conjunto de portas de energia, existe uma porta denominada reset, para reinicializar o dispositivo ao se fornecer uma tenso de 5V. Os conectores tambm so equipados com duas portas GND, que esto relacionadas com o polo negativo do circuito.

43
Figura 13 Portas de alimentao de energia para sensores

Fonte: WHEAT (2011)

importante ressaltar que a alimentao fornecida afeta diretamente a frequncia com que o processador ir operar. Por exemplo, o microcontrolador ATmega328 (Arduino Uno) pode operar com tenso variando entre 1.8V e 5.5V, o que permite trabalhar com frequncias entre 4MHz e 20 MHz. Para o modelo ATmega2560 (Arduino Mega) a frequncia de 16MHz e no possui variao com tenso menor (WHEAT, 2011). 2.4.1.2 Porta USB Nos modelos convencionais do Arduino, a interface USB possui trs funes bsicas (BOXALL, 2013): Alimentao de energia: Fornece energia para o circuito do Arduino e sensores conectados s portas; Gravao de firmware: Um dos mecanismos bsicos para a atualizao de cdigo do microcontrolador feito com o envio das instrues programadas atravs da porta USB, tambm conhecido como upload de cdigo. Essa tarefa normalmente feita pela Integrated Development Environment (IDE) do Arduino; Troca de informaes: A interface USB oferece conectividade para a troca de informaes do computador com os dispositivos conectados e vice-versa.

44 O modo de operao para comunicao serial realizado pelo padro SRS-232. Esse mecanismo baseado em um modo assncrono, que opera no mesmo clock do processador durante a comunicao serial. Quando a comunicao serial feita via interface USB, duas portas so utilizadas para essa tarefa, a porta zero RX para recepo e a porta um TX para transmisso, portanto o uso destas portas para outros fins depende da necessidade da comunicao serial ou no. As placas do Arduino normalmente so equipadas com Light Emitting Diode (LED) para facilitar a identificao da recepo e a transmisso de informaes pela comunicao serial (Figura 14).
Figura 14 Identificao de operao na comunicao serial

Fonte: WHEAT (2011)

2.4.1.3 Microcontrolador O microcontrolador (Figura 15) responsvel pelo processamento das instrues do firmware e pelo controle das operaes do Arduino. Esse componente pode estar presente de duas formas: soldado na placa no modelo Semi Metalic Disc (SMD) ou montado sob um invlucro conectado na placa principal, sendo que o segundo modelo permite a troca do chip apenas desconectando-o da placa principal (WHEAT, 2011). Os microcontroladores so circuitos integrados caracterizados por incorporar diversos elementos dentro de um mesmo componente. Um microprocessador necessita que outros componentes sejam adicionados para poder operar, como por exemplo memria, chipset e barramentos para enviar e receber dados. A existncia desses

45 componentes dentro do mesmo circuito o principal aspecto que diferencia um microprocessador de um microcontrolador, tornando-o um sistema computacional completo (SALLES, 2009).
Figura 15 Microcontrolador Atmel no Arduino

Fonte: WHEAT (2011) Nota: Na parte superior da figura, um exemplo de microcontrolador montado, na parte inferior exemplo de um microcontrolador soldado.

Os microcontroladores Atmel AVR possuem a caracterstica de serem eficientes em termos de consumo energtico e desempenho. So desenvolvidos com a tecnologia Reduced Complexity Instruction Set Computer (RISC) de 8 bits formado por instrues de 16 e 32 bits (ATMEL, 2013). Apesar de muitos acharem que a arquitetura RISC objetiva reduzir o nmero de instrues, na realidade o objetivo reduzir a complexidade das instrues para serem executadas no menor nmero de ciclos possveis, fazendo com que no seja necessrio executar processamentos adicionais para decodificar as instrues (ATMEL, 2013). O software escrito para Arduino, tambm denominado firmware, carregado para a rea de memria dos microcontroladores Atmel atravs de um software conhecido como bootloader. O bootloader fica armazenado na rea de memria de programa e sua

46 responsabilidade possibilitar a comunicao do dispositivo com a interface USB pela qual o firmware carregado. Esse cdigo sempre executado na inicializao e permite ao ambiente de desenvolvimento enviar o comando de reinicializao para comear o envio do novo firmware. Em processadores, a velocidade pode ser medida em Million Instructions Per Second (MIPS). Uma caracterstica importante na famlia dos microcontroladores AVR a velocidade de processamento, pois o seu conjunto de instrues necessita de apenas um ciclo de mquina para executar a maioria das instrues. Tomando como exemplo um microcontrolador AVR operando com um oscilador de 4MHz, pode-se considerar que a velocidade de processamento de 4 MIPS. Essa informao pode ser de grande importncia quando for necessrio executar operaes com alta velocidade e desempenho (SOARES, 1998). A Figura 16 mostra um diagrama simplificado dos principais componentes existentes em um microcontrolador Atmel AVR, descritos na sequncia (WHEAT, 2009):
Figura 16 Estrutura interna de um microcontrolador Atmel

Fonte: WHEAT (2011)

Central Processing Unit (CPU): As instrues presentes no firmware so executadas pela CPU e normalmente so compostas por: uma Arithmetic Logic Unit (ALU) responsvel

47 por executar operaes lgicas e aritmticas, registradores de 8 bits, registrador de status, Program Counter (PC), um decodificador de instrues, interfaces para acesso a memria interna e perifricos (WHEAT, 2009). So baseados na arquitetura Harvard (Figura 17), que utiliza dois barramentos, um para memria de dados e outro para memria de programa, que possibilitam maior velocidade no processamento (SOARES, 1998).
Figura 17 Arquitetura Harvard

Modelo Harvard
Memria de Dados CPU Memria de Programas

Fonte: Adaptado de SOARES (1998)

Memria de programa e dados (ROM, Flash, RAM, EEPROM): As memrias presentes nos microcontroladores so caracterizadas pela volatilidade. Normalmente a capacidade bastante reduzida (na ordem de KBs) se comparada aos computadores atuais e varia com o modelo. Vale ressaltar que as memrias no volteis possuem a vida til reduzida a cada escrita. A Read Only Memory (ROM) uma memria no voltil responsvel por armazenar o conjunto de instrues que formam a aplicao. Um microcontrolador possui apenas um programa na memria que sempre executado quando inicializado ou reiniciado (desconsiderando o bootloader). J a memria Random Access Memory (RAM) responsvel por armazenar as variveis durante a execuo do programa. Como as aplicaes so pequenas, no h a necessidade de copi-las para a memria RAM (WHEAT, 2011). Memria Flash uma memria no voltil e regravvel, cujas informaes permanecem salvas mesmo aps o desligamento do Arduino.

48 Suporta at dez mil gravaes e pode gravar configuraes ou persistir dados em caso de queda de energia. A Electrically Erasable Programmable Read-Only Memory (EEPROM) semelhante memria Flash, mas usa uma tecnologia mais antiga. Essa uma memria bastante limitada (menor que 1KB), porm com uma vida til bem maior, em torno de cem mil gravaes (ARDUINO, 2013); Clock: Tambm conhecido como circuito de relgio, um circuito oscilador responsvel por controlar a sincronizao das operaes do sistema. A frequncia ajustada por um cristal de quartzo, presente na placa principal do Arduino. O ajuste da frequncia dependente da alimentao fornecida, permitindo trabalhar em modo de economia de energia ou alto desempenho (WHEAT, 2013); Perifricos: Os microcontroladores Atmel so formados por circuitos adicionais que facilitam a comunicao com outras partes do sistema e a integrao com novos componentes. Podese citar: (i) a presena de portas de entrada e sada, sendo essas divididas em analgicas ou digitais, utilizadas para comunicao com outros dispositivos, (ii) interrupo externa para executar aes na ocorrncia de eventos externos ao sistema, (iii) temporizador ou contador com a funo de controlar tempo ou at mesmo interrupes para serem tratadas por outros sistemas, (iv) watchdog timer para reinicializao do sistema periodicamente para se recuperar de falhas e o (v) Universal Synchronous Asynchronous Receiver Transmitter (USART), um padro universal para comunicao serial de forma sncrona ou assncrona; Conversores analgicos-digitais: Os microcontroladores usados no Arduino possuem um perifrico Analog Digital Converter (ADC) para a converso de sinais analgicos em um respectivo sinal digital variando entre 0 e 1023. Estes conversores tornam-se importantes quando se trabalha com dispositivos e sensores que operam com informaes variveis (e.g., som, luminosidade) que necessitam de um meio para mapear e tratar as informaes recebidas; Geradores de sinal Pulse Width Modulation (PWM): Permite simular sadas analgicas em uma interface digital, o que torna possvel controlar, por exemplo, o escurecimento de lmpadas e

49 velocidades de motores devido a oscilao da energia entre 0V e 5V nas portas que possuem essa interface. 2.4.1.4 Reset O Arduino equipado com um boto (Figura 18) para reiniciar o dispositivo, caso ele se encontre travado ou no esteja operando corretamente. Essa funcionalidade bastante til quando se est testando uma soluo e se deseja depurar o cdigo pelas sadas enviadas para interface serial. Ao pressionar esse boto, o microcontrolador reiniciar a execuo do firmware (WHEAT, 2011).
Figura 18 Boto para reiniciar o Arduino

Fonte: WHEAT (2011)

2.4.1.5 Conectores de expanso e portas Uma das caractersticas que tornam o uso do Arduino bastante prtico, a possibilidade de adicionar componentes que possam interagir com o ambiente de forma simples e rpida. Atravs das portas (tambm conhecidas como sockets) digitais e analgicas, possvel realizar a troca de informaes entre os componentes e executar aes baseadas em condies e eventos que venham a ocorrer. O modo de operao configurado com instrues presentes no firmware e possibilita que elas operem como portas de entrada, ou seja, recebendo sinal, ou como portas de sada, enviando um sinal. Todas as portas so numeradas para facilitar a sua identificao. Normalmente esto agrupadas em conectores de expanso conforme o tipo e esto posicionadas nas laterais e extremidades para facilitar a adio de circuitos mais complexos.

50 A nomenclatura segue uma conveno e amplamente adotada na documentao e na programao. As portas analgicas iniciam com a letra A seguida de um nmero sequencial (e.g., A0, A1, A2) e as portas digitais iniciam com a letra D seguida de um nmero sequencial (e.g., D0, D1, D2). As portas (Figura 19) so formadas por conectores que fazem com que no seja necessrio soldar os componentes diretamente na placa de prototipao, conhecida tambm como breadboard, muito usada para conectar e desconectar os fios a sensores e outros componentes eletrnicos. Existem basicamente trs tipos de portas no Arduino (ARDUINO, 2013): Portas digitais sem PWM: trabalham com valores discretos quando configuradas como portas de sada e podem gerar dois nveis de sinais: (i) sinal baixo (0V) ou (ii) sinal alto (5V). Quando configuradas como portas de entrada, permitem ler o sinal eltrico identificado como sinal alto (tenso superior a 3V) ou sinal baixo (tenso inferior a 3V); Portas digitais PWM: Operam da mesma forma que as portas digitais convencionais, porm possuem a capacidade de representar resultado analgico de forma digital. Ao executar um comando de escrita analgica em uma porta digital PWM, possvel obter valores que variam em uma escala de 0 a 255 e esses valores so modulados de forma digital em voltagem variando de 0V a 5V. Assim, por exemplo, pode-se controlar a intensidade de um LED ou a velocidade de um motor. As portas que podem gerar sinal eltrico varivel so marcadas com til (~). Portas Analgicas: So utilizadas para ler valores analgicos dos componentes conectados. Os sinais so convertidos em um valor entre 0 e 1023, que ser proporcional tenso eltrica aplicada na porta.

51
Figura 19 Conectores de expanso

Fonte: WHEAT (2011) Nota: Exemplo de conectores de expanso de portas digitais (superior) e analgicas (inferior)

O Quadro 1 apresenta as principais diferenas de processamento, portas e memria entre os modelos mais populares, Arduino Uno e Arduino Mega (WHEAT, 2011).
Quadro 1 Comparao da especificao dos Arduinos

Especificao Modelo Processador Clock Processador Memria Programa (FLASH) Memria Dados (SRAM) EEPROM Pinos Processador Portas Entradas/Sadas Portas Analgicas Portas PWM

Arduino Uno ATmega 328 16MHz 32KB 2KB 1KB 28/32 14 6 6

Arduino Mega 1280 ATmega 1280 16MHz 128KB 8KB 4KB 100 54 16 14

Arduino Mega 2560 ATmega 2560 16MHz 256KB 8KB 4KB 100 54 16 14

Fonte: WHEAT(2011)

52 2.4.1.6 Shields Muitos dos componentes que podem ser integrados plataforma Arduino so comercializados em mdulos (e.g., GPS, GSM, LCD, Sensores). Esses mdulos possuem uma interface simplificada e j disponibilizam bibliotecas desenvolvidas para operar com o Arduino. Dessa forma, possvel manter o foco na soluo desejada, sem exigir grandes esforos na elaborao de um circuito desde o incio (BOXALL, 2013). Quando existe a necessidade de se usar componentes mais complexos, as portas de expanso servem de base para conectar placas diretamente sobre o Arduino, as quais so conhecidas como shields. Como exemplos, podem ser citados: (i) o shield ethernet, para comunicao via conexo ethernet, (ii) shield XBee, para a comunicao sem fio com outras placas Arduino e distncias variando de trinta a cem metros, (iii) shield para controle de motores, que operam em corrente contnua, (iv) shield GPS, para receber sinal GPS e possibilitar a localizao global via satlite e (v) shield GSM, responsvel por prover mecanismos de acesso Internet via rede GPRS. Como nem todas as portas so utilizadas pelos Shields, as portas so expandidas em novos conectores de expanso para possibilitar a adio de novas funcionalidades e sensores ao Arduino. A Figura 20 ilustra dois shields conectados a um Arduino, sendo o primeiro um shield ethernet e o segundo um shield composto por um visor numrico e sensor de temperatura.
Figura 20 Shields sobrepostos e conectados sobre um Arduino

Fonte: BOXALL (2013)

53 2.4.1.7 Sensores A utilizao de sensores para ler informaes do ambiente torna vasta a possibilidade de solues que podem ser desenvolvidas. Dependendo do sensor, deve se levar em conta a necessidade de circuitos adicionais, como o caso de um rel que necessita de um circuito de controle para evitar que uma sobrecarga danifique tanto o Arduino quanto o dispositivo conectado. Quando as pessoas interessadas no possuem muito conhecimento sobre eletrnica, esto disponveis mdulos de sensores, semelhante ao shield, que fornecem uma interface mais simples para a comunicao com o Arduino. Esses sensores so montados com todo o circuito necessrio para o correto funcionamento. Em casos mais complexos, so adicionados microcontroladores para traduzir os dados em informaes mais claras atravs de bibliotecas disponibilizadas na Internet pelos fabricantes e pela comunidade de desenvolvedores. Um caso bastante comum o sensor de temperatura e umidade (Figura 21), tambm conhecido como DHT11, composto por um Circuito Integrado (CI) com apenas trs portas: uma porta para GND (Negativo), uma para os 5V (Positivo) e uma porta digital para leitura das informaes. Normalmente, os componentes eletrnicos so acompanhados de uma folha de dados (datasheet), um documento que apresenta de forma resumida todas as caractersticas tcnicas de um CI.
Figura 21 Exemplo de circuito integrado em um sensor

Fonte: DX (2013)

2.4.2 Comunicao Uma das caractersticas que expande as funcionalidades do Arduino a possibilidade de realizar a comunicao de diferentes

54 formas com outros equipamentos eletrnicos, sendo a comunicao serial via porta USB o mtodo convencional. Com as bibliotecas disponveis para o Arduino, possvel que a comunicao seja feita por diferentes protocolos, como por exemplo: Inter Integrated Circuit (I2C): Disponvel na biblioteca Wire do Arduino, um protocolo desenvolvido pela Philips na dcada de 80, com o objetivo de reduzir a complexidade das conexes em circuitos eletrnicos e torn-los menos suscetveis a interferncias eletromagnticas. Seu funcionamento consiste em um barramento de dois fios para possibilitar a conexo de perifricos ao barramento de dados e endereos da CPU atravs de um decodificador de endereos e uma unidade de controle para gerenciar o barramento. Todos os dispositivos conectados no barramento possuem um endereo e podem atuar como mestre (master) ou escravo (slave). O dispositivo que iniciar a transmisso considerado o master, alm disso os dispositivos conectados podem atuar como transmissores ou receptores (PRADO, 2007). Serial Peripheral Interface (SPI): Semelhante ao protocolo I2C, um protocolo serial sncrono empregado por microcontroladores para controlar um ou mais perifricos, podendo inclusive servir para comunicao entre microcontroladores. Em uma conexo SPI, existe um dispositivo atuando como master (normalmente o microcontrolador) responsvel por controlar os perifricos. Nessa comunicao, so usadas trs linhas, comuns a todos os dispositivos: (i) Master In Slave Out (MISO), para enviar informaes do slave para o master, (ii) Master Out Slave In (MOSI), para envio de informaes do master para os perifricos e (iii) Serial Clock (SCK), responsvel por sincronizar a transmisso de informaes entre os dispositivos. Para cada dispositivo slave utilizado um pino para o master habilitar ou desabilitar a comunicao que est ativa no barramento em um determinado momento (ARDUINO, 2013).

2.4.2.1 Redes e Internet Os diferentes protocolos disponveis no Arduino reduzem a complexidade necessria para a comunicao em diferentes meios, seja

55 via cabo ou sem fio. Muitas das solues esto disponveis em shields fabricados e montados para serem conectados diretamente na placa principal de forma bastante prtica. Com esses mecanismos, novos horizontes se abrem para prover meios alternativos de acesso a dispositivos de forma remota, em redes locais ou Internet, alm de possibilitar o gerenciamento remoto de dispositivos para coleta de informaes em ambientes geograficamente distribudos. Com o uso do shield ethernet ou rede sem fio, a conectividade do Arduino se expande e possibilita sua atuao em uma arquitetura cliente-servidor. Nesse modelo, possvel transferir processamentos mais pesados para serem executado em equipamentos de maior desempenho, como microcomputadores e servidores. As bibliotecas disponveis para Arduino permitem a comunicao por sockets, requisies HTTP, DHCP, conexes TCP e UDP, etc. Com o shield ethernet, o Arduino pode operar tanto como cliente quanto como servidor. Sua biblioteca suporta um total de quatro conexes simultneas (Arduino, 2013). A comunicao desse shield controlada pelo barramento SPI, conectado a quatro portas, sendo trs dessas para comunicao e uma para ativar e desativar o acesso ao barramento. 2.4.3 Armazenamento de Dados Externo Alguns shields comercializados, como o caso do shield ethernet, so equipados com um circuito adicional para manipular arquivos em carto de memria SD. Consequentemente, se reduz a limitao de memria disponvel no Arduino, tornando possvel, por exemplo, o gerenciamento de configuraes gravadas em arquivo. Para evitar o uso de portas adicionais, a comunicao do circuito de armazenamento em SD com o Arduino feito sob o mesmo barramento utilizado para ethernet, atravs do protocolo SPI. Esse controle feito com a adio de uma nica porta adicional, responsvel pela seleo do barramento pelo dispositivo controlador (master) (ARDUINO, 2013). Existem diversas bibliotecas para manipulao de arquivo com suporte aos sistemas de arquivos FAT16 e FAT32. Entre as operaes disponveis, podem ser citadas: manipulao de diretrio e arquivo e execuo de leitura e escrita. A Figura 22 ilustra as portas de comunicao e controle utilizadas pelo shield ethernet em um Arduino Mega.

56
Figura 22 Portas utilizadas pelo shield ethernet no Arduino Mega

Fonte: ARDUINO (2013)

2.4.4 Plataforma de Desenvolvimento Para facilitar a programao, a plataforma Arduino disponibiliza a Integrated Development Environment (IDE), responsvel por prover os mecanismos necessrios comunicao do computador com o Arduino. A IDE para Arduino desenvolvida em Java e est disponvel em ambiente multiplataforma (e.g., Windows, Mac OS X e Linux). Todo desenvolvimento para Arduino iniciado com a criao de um projeto, tambm conhecido como sketch, que contm o cdigofonte do programa e normalmente salvo em arquivo com a extenso .ino (ARDUINO, 2013). Dentro da IDE (Figura 23), possvel executar diversas aes, como compilar o cdigo, o monitoramento e troca de mensagens via interface USB e principalmente o upload do firmware para o Arduino. Na parte inferior da IDE (Figura 23), existe uma rea de cor preta que exibe informaes importantes, como o tamanho do projeto e a memria total do firmware.

57
Figura 23 Exemplo de sketch carregada na IDE do Arduino

Fonte: produo do prprio autor

Outra opo importante existente na IDE, a escolha do modelo do Arduino (Figura 24). Devido aos diferentes modelos, necessrio definir o modelo correto, para que o cdigo compilado seja possvel de ser gravado no microcontrolador, principalmente devido s limitaes de memria. Quando houver a necessidade de alterar o modelo do Arduino, basta selecionar o modelo correspondente e todos os ajustes necessrios para compilao com o novo hardware sero feitos automaticamente sem afetar o cdigo escrito.

58
Figura 24 Seleo do modelo do Arduino na IDE

Fonte: produo do prprio autor

A linguagem de programao do Arduino foi desenvolvida baseada na plataforma Wiring e implementada em C/C++. Wiring um framework open source multiplataforma de desenvolvimento de software para controlar dispositivos conectados a microcontroladores da famlia AVR Xmega, AVR Tiny, TI MSP430 e Microchip PIC24/32. O objetivo principal da plataforma permitir que pessoas com diferentes nveis de conhecimento em eletrnica possam desenvolver solues criativas e realizar a interao entre objetos, espao e experimentos fsicos (WIRING, 2013).

59 2.4.4.1 Compilao de cdigo Quando se desenvolve um software em linguagem de alto nvel (e.g., C, Java. .NET), o compilador responsvel por transformar o cdigo em linguagem de mquina, para que as instrues possam ser interpretadas pelo microcontrolador. O Arduino utiliza o pacote AVR LibC, composto por um conjunto de bibliotecas desenvolvidas para operar com os microcontroladores Atmel AVR. Essa biblioteca, juntamente com o compilador GCC, forma o compilador denominado AVR-GCC. Na compilao do cdigo, os objetos gerados so transformados em um arquivo no padro Intel HEX, um formato de arquivo especial que codifica imagens de arquivos binrios, que pode ser reconhecido por outros tipos de software. Existe um utilitrio para fazer a gravao do firmware no Arduino, denominado AVRDUDE. Para que seja possvel executar essa tarefa, o Arduino vem de fbrica com um cdigo prgravado, denominado de bootloader, uma espcie de cdigo que sempre executado quando o Arduino ligado ou reinicializado. Dessa forma, a IDE consegue reinicializar o Arduino e enviar o comando para o bootloader gravar o programa na rea de memria correta, sem sobrescrever essa rea (WHEAT, 2011). 2.4.5 Modelos e variantes Por se tratar de uma plataforma open source, a equipe responsvel pelo Arduino disponibiliza toda a documentao, esquemtica, layouts de placas e cdigo-fonte necessrio, possibilitando a qualquer pessoa ou fabricante montar o seu prprio Arduino. A nica restrio quanto ao uso do nome Arduino, que de uso exclusivo. Sendo assim, existem diversos fabricantes que usam nomes similares com caractersticas padres para desenvolver solues compatveis com o modelo original (e.g., Freeduino, Meeeno). importante ressaltar que devido aos diferentes fabricantes, os preos variam, juntamente com a qualidade dos componentes de fabricao. Com isso, a durabilidade do circuito pode ser comprometida, reduzindo a confiabilidade do equipamento, portanto o ideal sempre optar por fabricantes licenciados oficialmente pelo Arduino.

60 2.5 FERRAMENTAS SIMILARES Na elaborao deste projeto, foram feitas pesquisas de ferramentas similares para o gerenciamento de sensores com Arduino. 2.5.1 Noduino Framework open source desenvolvido em JavaScript e HTML5, permite a configurao das portas, o envio de comandos e o tratamento de eventos gerados no Arduino em uma interface Web. A comunicao do computador com o Arduino pode ser feita via interface serial ou WebSocket (disponvel para HTML 5). Para que as informaes sejam interpretadas, foi desenvolvido um firmware para o Arduino denominado duino, que controla e trata as aes recebidas (NODUINO, 2013). Na ferramenta Noduino, necessrio que as funcionalidades sejam programadas com o uso das bibliotecas disponveis pelo framework. A execuo das aes depende da comunicao do servidor com o Arduino. As informaes da comunicao com o Arduino (Figura 25) podem ser facilmente atualizadas na tela, utilizando-se os recursos da biblioteca JavaScript Node.js presente no framework da ferramenta Noduino.
Figura 25 Framework Noduino

Fonte: NODUINO (2013)

61 2.5.2 Breakout A ferramenta Breakout foi desenvolvida para controlar as portas de entrada e sada do Arduino atravs de uma interface Web. composta por bibliotecas que facilitam a utilizao de sensores. Para program-la, necessrio conhecimento apenas em JavaScript. A comunicao com o Arduino feita via socket, por uma ferramenta desenvolvida em Java (Figura 26), que atua como servidor e envia os comandos para o Arduino. A ferramenta tambm disponibiliza um firmware, responsvel por interpretar e executar as aes recebidas do cliente (BREAKOUT, 2013).
Figura 26 Ferramenta Breakout

Fonte: Breakout (2013)

2.5.3 Arduino-Homebot O Arduino-Homebot um projeto experimental de Automao residencial para controle de sensores via comunicao sem fio. Os Arduinos so definidos por suas caractersticas e so divididos em dois tipos: (i) Arduino rob, que transmite as informaes e (ii) Arduino mestre, que recebe as informaes. Os robs so nomeados como: (i) Horai para controle de temperatura e umidade e (ii) Itus para controle de gs e fumaa. O Arduino mestre, denominado Uranus, recebe as informaes dos diversos robs, exibe as informaes em um display LCD e opcionalmente pode enviar as informaes para tratamento em um servidor Web. O firmware especfico e deve ser gravado no

62 Arduino de acordo com a responsabilidade desempenhada (HOMEBOT, 2013). 2.6 ANLISE COMPARATIVA ENTRE AS FERRAMENTAS O Quadro 2 apresenta uma comparao das funcionalidades existentes nas ferramentas similares pesquisadas, em relao ferramenta InoSensor em sua verso atual.
Quadro 2 Comparativo com ferramentas similares

Descrio Gerenciamento Web Configurao de sensores Monitoramento remoto Conhecimentos em programao Controle de Acesso Envio de notificaes Alterao remota de configurao Operao autnoma (sem conectividade) Persistncia de configurao (no voltil)

InoSensor 1.0 X X X

Noduino X X X X

Breakout X X X X

Arduino Homebot

X X

X X X X X X

Fonte: produo do prprio autor

Com essa pesquisa, foi possvel observar que existem diversos projetos para o controle do Arduino de forma remota, cada um com as suas particularidades e caractersticas semelhantes. Um dos aspectos presentes em todas as ferramentas a capacidade de monitoramento remoto de sensores via rede local ou Internet e a existncia de solues desenvolvidas para serem executadas

63 diretamente do navegador Web. Vale destacar que a maioria dessas ferramentas necessita de conhecimentos em programao para implementar a lgica de controle dos sensores, o que acaba dificultando o uso e adaptao para alcanar o objetivo desejado. A ausncia de um mecanismo para alterar as aes, sem a necessidade de atualizar o firmware do Arduino, outro fator importante, pois dependendo da situao, pode se tornar invivel o ajuste das aes que devem ser executadas. Em relao segurana, as ferramentas pesquisadas no possuam uma forma efetiva para controle de acesso aos dispositivos, diminuindo a segurana e tornando os dispositivos vulnerveis a modificaes indevidas. Com exceo da ferramenta Arduino-Homebot, os Arduinos no possuem um mecanismo autnomo para executar aes. Esse fator os torna dependentes do servidor, sendo necessrio o envio de comandos pela ferramenta Web toda vez que o usurio desejar realizar uma nova tarefa. Nessa comparao, foi possvel identificar alguns aspectos ausentes na ferramenta InoSensor. Um deles se refere ausncia de um meio de comunicao sem fio em ambientes onde no exista uma conexo via rede ethernet. Outro aspecto ausente um display LCD para exibir informaes importantes do funcionamento do dispositivo. De forma geral, a ferramenta InoSensor pode contribuir na rea acadmica, atravs do uso da ferramenta como objeto de estudo para Arduino, e como uma soluo para monitoramento de sensores de baixo custo. 2.7 CONCLUSES DO CAPTULO Nesse captulo, foram documentados os estudos relacionados ao tema do projeto, para facilitar a compreenso dos conceitos pertinentes Automao, Domtica e arquitetura da plataforma Arduino, alm da pesquisa de ferramentas similares relacionadas ao contexto do projeto. Ainda que as solues existentes para a Domtica no sejam adaptveis a diferentes situaes, existem estudos e projetos que buscam empregar a Automao de forma mais simples. Assim, diferentes dispositivos em uma residncia podero ser integrados e gerenciados por um computador ou smartphone.

64 3 PROJETO Este captulo apresenta a definio do escopo, a metodologia, bem como os hardware e software utilizados no desenvolvimento deste trabalho. No que se refere a modelagem fsica e lgica do sistema, foram adotados alguns dos conceitos convencionais da engenharia de software, para facilitar a compreenso da soluo a todos os interessados. 3.1 COMPOSIO DO SISTEMA A ferramenta InoSensor foi desenvolvida baseada em uma arquitetura distribuda, onde o servidor responsvel por monitorar as informaes, enviar e-mails, desligar alarmes remotamente e alterar o comportamento das aes executadas por cada Arduino. J o Arduino, ser responsvel por processar as informaes geradas pelos sensores e executar as aes com base nas condies configuradas em cada sensor. Para exemplificar o funcionamento do sistema, a Figura 27 ilustra, de forma geral, como feita a comunicao entre o servidor InoSensor e o Arduino. Aps devidamente configurado com o firmware padro, o Arduino necessita se conectar a uma rede local ou Internet, para permitir a comunicao com o servidor e assim receber as configuraes dos sensores. A ferramenta InoSensor foi desenvolvida para gerenciar um ou mais Arduinos. Para adicionar um novo dispositivo ao sistema, necessrio cadastrar e configurar os sensores e aes que iro fazer parte do conjunto. Em seguida, as configuraes devem ser transmitidas para o Arduino poder operar com as funes desejadas. A partir desse momento, o Arduino pode controlar os sensores e notificar o servidor sobre a ocorrncia de eventos. Caso um Arduino tenha disparado algum alarme, possvel deslig-lo remotamente atravs do servidor. Se for necessrio alterar as aes, adicionar ou remover sensores, os ajustes podem ser feitos no servidor e as configuraes sero retransmitidas sem a necessidade de atualizar o firmware do Arduino. Uma das vantagens desse modelo a possibilidade de alterar remotamente o comportamento geral do Arduino sem a necessidade de programao via cdigo.

65
Figura 27 Viso macro da representao do sistema

Sensores
Arduino 1

Rede/ Internet
Arduino 2

Sensores

Sensores InoSensor Arduino 3

Fonte: produo do prprio autor

3.1.1 Sensores Utilizados A escolha dos sensores foi feita com base nos mdulos disponveis para o estudo da soluo proposta, evitando gerar custos financeiros desnecessrios ao projeto. Os sensores so fabricados em circuitos prontos para o uso, bastando conectar as portas do sensor diretamente s portas do Arduino. A alimentao de energia de 5V para todos os sensores. Os componentes selecionados podem ser considerados os mecanismos bsicos para o monitoramento e segurana de ambientes residenciais ou prediais. Dependendo da aplicao do sistema, deve-se avaliar a aquisio de sensores mais robustos e mais precisos, reduzindo a chance de ocorrncia de falhas. Abaixo so detalhados os principais aspectos tcnicos dos sensores para a comunicao com o Arduino. Sensor de Temperatura e Umidade: Foi usado o sensor conhecido como DHT11 (Figura 28), um sensor digital de baixo custo para efetuar a leitura de informaes de temperatura e umidade do ambiente. Esse sensor composto por um sensor capacitivo de umidade e um termistor para medir a temperatura do ar. A leitura das informaes simplificada, com o uso de uma biblioteca (DHT11) disponvel junto a IDE do Arduino, que possibilita ler a umidade e converter a temperatura em diferentes unidades de medida, atravs de uma porta digital. Como uma alternativa, existe o modelo DHT22, com maior

66 preciso na medio das informaes. Esse sensor pode servir para acionar equipamentos de acordo com a temperatura ou umidade.
Figura 28 Sensor Temperatura e Umidade DHT11

Fonte: DX (2013)

FotoResistor: Tambm conhecido como Light Dependent Resistor (LDR), nada mais do que um resistor sensvel a luminosidade para detectar a presena ou ausncia de luz em um ambiente (Figura 29). um componente simples, que pode apresentar grande variao, portanto seu uso se torna limitado. Quanto maior a luminosidade, maior ser a resistncia e menor ser o valor de leitura na porta analgica. Por se tratar de uma porta analgica, a leitura varia entre 0 (zero) para alta luminosidade at 1023 para baixa luminosidade.
Figura 29 Fotoresistor

Fonte: DX (2013)

67 Sensor de Fogo: Esse sensor (Figura 30) serve para detectar a presena de fogo em distncias de vinte a cem centmetros do dispositivo. No requer o uso de bibliotecas e pode detectar a presena ou ausncia de fogo pela leitura de uma porta digital, sendo retornado o valor 1 (um) para presena de fogo ou 0 (zero) para ausncia de fogo.
Figura 30 Sensor de chama

Fonte: DX (2013)

Sensor de Gs: um sensor eletroqumico (Figura 31) que reage presena de gs no ar, em temperatura ambiente. Existem diferentes modelos para identificar gases como metano, butano, LPG, fumaa, gases inflamveis e combustveis, etc. O gs detectado atravs de uma porta analgica que retorna um valor entre 0 (zero) para ausncia de gs e 1023. Quanto maior o valor retornado, maior a presena de gs no ar.
Figura 31 Sensor de gs

Fonte: DX (2013)

68 Sensor de Vibrao: um sensor digital (Figura 32) composto por um circuito para detectar vibrao. O sinal lido por uma porta digital que retorna o valor 0 (zero) quando detectar algum tipo de vibrao ou 1 (um) para ausncia de vibrao. Pode ser utilizado como mecanismo de deteco de arrombamento.
Figura 32 Sensor de vibrao

Fonte: DX (2013)

Sensor Magntico: Tambm conhecido como sensor de proximidade ou sensor de efeito hall (Figura 33), pode detectar a presena de objetos que tenham campo magntico. composto por uma porta digital que retorna o valor 0 (zero) quando detectar a presena de magnetismo ou 1 (um) para ausncia de campo magntico. Pode servir como mecanismo para detectar abertura de portas e janelas.
Figura 33 Sensor magntico

Fonte: DX (2013)

Detector de presena InfraVermelho: Seu funcionamento baseado em um sensor infravermelho passivo (PIR) que detecta o movimento por calor infravermelho (Figura 34). Esse sensor utiliza uma porta digital que retorna o valor 1 (um) quando

69 detectar a presena de movimento ou o valor 0 (zero) na ausncia de movimento.

Figura 34 Sensor presena PIR

Fonte: DX (2013)

Rel: O uso do rel (Figura 35) estende-se como um circuito eletromecnico para acionar equipamentos eltricos com corrente eltrica maior que a fornecida pelo Arduino. O funcionamento semelhante a um interruptor e pode ser acionado atravs da aplicao de um sinal alto (valor um), em uma porta digital que fecha o circuito eltrico ou um sinal baixo (valor zero), que abre o circuito e interrompe a passagem da corrente eltrica. Pode ser utilizado para ligar ou desligar equipamentos eltricos como motores e eletrodomsticos ligados rede eltrica convencional com tenso de at 240V e corrente mxima de 10 amperes.
Figura 35 Rel

Fonte: DX (2013)

70 LED RGB: um componente eletrnico (Figura 36) que possui a capacidade de emitir luz nas trs cores primrias: vermelho (Red), verde (Green) e azul (Blue). O acionamento de mais de uma cor ao mesmo tempo permite combin-las e gerar novas cores. Esse circuito possui trs portas digitais, uma para cada cor. A luz se acende quando enviando um sinal alto (valor um) e se apaga quando se envia um sinal baixo (valor zero) para a porta do mdulo.
Figura 36 LED RGB

Fonte: DX (2013)

Buzzer: um pequeno alto-falante (Figura 37) que pode emitir sons em diferentes frequncias e intervalos. Pode ser empregado quando houver a necessidade de emitir alertas e alarmes. Para o funcionamento do buzzer, necessrio conectlo a uma porta digital PWM, responsvel por definir a frequncia do som. Ao aplicar um sinal na porta conectada (1255), o buzzer ir soar um alarme. Ao aplicar o valor zero, o som ser desligado.
Figura 37 Buzzer

Fonte: DX (2013)

71 O Quadro 3 apresenta os tipos de portas e as respectivas quantidades utilizadas por cada sensor.
Quadro 3 Tipos de portas utilizadas por cada sensor

Sensor DHT11 Fotoresistor Fogo Gs Vibrao Magntico Infravermelho Rel LED RGB Buzzer

Portas Digitais 1 1

Portas Analgicas 1 1

Portas PWM

1 1 1 1 3 1
Fonte: produo do prprio autor

3.1.2 Plataforma de Prototipao Um dos benefcios da plataforma Arduino, a facilidade de criar prottipos de circuitos eletrnicos sem a necessidade de soldar os componentes, conectando-os a fios eltricos em placa de ensaio, tambm conhecidas como protoboard ou breadbord (Figura 38). A protoboard composta de diversos orifcios adjacentes, conectados em trilhas verticais e horizontais, formando uma matriz, que variam de oitocentos at seis mil furos, dependendo do modelo. O espaamento entre cada orifcio de 2,54 mm (0,1 polegada), uma medida que foi padronizada e seguida por diversos fabricantes de componentes eletrnicos (WHEAT, 2011). A Figura 39 mostra um desenho esquemtico de como os furos esto conectados no modelo de protoboard deste projeto. Em cada lateral, existem duas trilhas com os furos conectados verticalmente, as quais so normalmente utilizadas para conexo dos componentes no polo positivo e negativo do circuito. J os furos verticais so conectados horizontalmente e separados por uma fenda, agrupados de cinco em cinco furos. Para facilitar a identificao, os furos das trilhas verticais so identificados por nmeros e os furos nas linhas horizontais, por letras (MARGOLIS, 2011).

72
Figura 38 Arduino conectado protoboard

Fonte: MARGOLIS (2011) Figura 39 Modelo de protoboard

Fonte: ClarkZapper.net (2004)

Ao manipular uma protoboard, deve-se atentar alguns cuidados. O uso constante e a m qualidade do produto podem causar intermitncia nos sinais eltricos, ocasionando a leitura de informaes erradas e at mesmo o mau funcionamento do circuito (MARGOLIS, 2011).

73 3.1.3 Shield ethernet e SD Para possibilitar a comunicao do Arduino com a ferramenta InoSensor, foi utilizado um shield ethernet, conforme ilustrado na Figura 40. Esse shield funciona tanto no modelo Uno quanto no modelo Mega2560. Por ser conectado na parte superior do Arduino, acaba cobrindo parte da placa principal. Dessa forma, os conectores, o boto de reset e os LEDs indicadores de transmisso (RX e TX) so expandidos e disponibilizados na parte superior do shield ethernet.
Figura 40 Shield ethernet

Fonte: DX (2013)

3.2 COMPORTAMENTO DO SISTEMA A ferramenta InoSensor permite cadastrar os sensores e atuadores para executarem as aes de acordo com as necessidades. De forma simplificada, o processo iniciado com o cadastro dos sensores. Ao cadastrar um sensor, deve-se informar as portas disponveis que sero utilizadas para o mdulo do sensor, em seguida so cadastradas as aes que devem ser executadas com base nas condies especficas para cada tipo de sensor e, ao finalizar a configurao, deve ser feita a transmisso, para o Arduino entrar em funcionamento. O Arduino responsvel pelo gerenciamento dos sensores conectados e pela execuo das aes que foram configuradas por meio

74 da ferramenta InoSensor. As configuraes, condies e aes so armazenadas em um arquivo na memria externa no carto SD. Ao iniciar o Arduino, o firmware configura todas as portas de entrada e sada com base nas informaes coletadas do arquivo de configurao e em seguida, a interface ethernet inicializada para possibilitar a troca de informaes com o servidor. A partir desse momento, iniciada a leitura das informaes dos sensores que esto configurados e caso uma condio seja verdadeira, iniciada a execuo dos atuadores. Alm disso, o Arduino pode notificar o servidor InoSensor da ocorrncia de um evento e at mesmo solicitar ao servidor o envio de um e-mail para notificao dos responsveis. 3.2.1 Aes O sistema foi desenvolvido com a capacidade de responder ocorrncia de eventos externos e possibilitar o controle e gerenciamento dos sensores conectados, sendo assim, o Arduino possui a capacidade de executar trs tipos de aes distintas, descritas abaixo: Acionar Atuador: Possui a funo de executar um atuador do sistema, disparar alarmes atravs de um buzzer, ligar ou desligar algum equipamento eltrico por meio de um rel ou ligar e desligar LED RGB; Enviar e-mail: Para situaes de emergncia que devem notificar algum responsvel, possvel configurar o Arduino para disparar para o servidor uma solicitao de envio de email. Isso permite deixar todo o trabalho necessrio para envio de e-mail, como autenticao, configurao e tratamento de erros, a cargo do servidor e manter a responsabilidade do Arduino no gerenciamento dos sensores; Notificar servidor: possvel configurar quando da ocorrncia de um condio de um sensor, o envio de uma notificao para o servidor InoSensor. Essa ao ir aparecer no painel de monitoramento do servidor, informando a data, hora, dispositivo e informao relativa ao sensor (e.g., temperatura, fogo) que disparou a ao.

75 3.3 PROTOCOLO DE COMUNICAO Uma caracterstica importante, implementada na ferramenta InoSensor, a possibilidade de ajustar as configuraes dos sensores e atuadores sem a necessidade de atualizar o firmware do Arduino, facilitando o uso da ferramenta e eliminando a necessidade de conhecimento em linguagem de programao do firmware. Em relao conectividade do Arduino ao Servidor InoSensor, foi usado o protocolo TCP/IP para viabilizar a comunicao atravs da Internet ou Local Area Network (LAN). Entre as vantagens desse protocolo, podem ser citadas: (i) a grande utilizao, (ii) velocidade de comunicao, (iii) ser um protocolo rotevel, ou seja, permite interligar computadores em diferentes redes, (iv) disponvel na arquitetura ethernet, (v) comunicar-se com o servidor PHP via socket de forma bastante prtica e (vi) testar a conectividade com o uso do utilitrio de rede PING. Devido capacidade de ajuste varivel das configuraes, as informaes so armazenadas em arquivo texto, gravadas na memria externa do carto SD. O uso da memria externa diminui as limitaes de memria do Arduino, pois as particularidades de cada dispositivo so ajustadas e gravadas na memria externa, sem comprometer o funcionamento do hardware por estouro de memria. Outra vantagem tornar o firmware do Arduino mais robusto e facilitar a depurao de erros, j que o firmware se torna padro. 3.3.1 Monitor de Notificaes O Arduino pode controlar os sensores de forma isolada, executando as aes com base nas condies configuradas, desde que as configuraes estejam devidamente gravadas na memria do carto SD. Nesse modelo, a operao do Arduino est restrita aos atuadores conectados no prprio dispositivo, como rel, buzzer e LED RGB. J para possibilitar o monitoramento remoto do dispositivo, necessrio que haja uma conexo ativa. Nesse modo de operao o Arduino pode trocar informaes com o servidor InoSensor e notific-lo da ocorrncia de eventos e, se necessrio, o servidor pode enviar e-mail para notificar os responsveis. A ferramenta InoSensor conta com um painel de notificaes atualizado constante e automaticamente, responsvel por mostrar os ltimos eventos ocorridos em cada Arduino configurado no sistema.

76 3.4 MODELAGEM DO SISTEMA A fase de modelagem tem como objetivo confeccionar um documento para delimitar o escopo e mapear as tarefas e atividades que sero executadas pelo sistema InoSensor. A modelagem do sistema foi elaborada seguindo a notao UML. Os artefatos gerados possibilitam avaliar o projeto em diferentes vises, definir a estrutura necessria para a implementao e mostram as caractersticas particulares do sistema. 3.4.1 Requisitos As subsees seguintes apresentam o levantamento de requisitos da ferramenta InoSensor. 3.4.1.1 Requisitos Funcionais Os requisitos funcionais esto descritos abaixo. O termo manter empregado nos requisitos est relacionado s operaes de listar, cadastrar, editar e deletar. RF01. O sistema deve permitir ao administrador manter o cadastro de administradores no sistema; RF02. O sistema deve permitir ao administrador manter as configuraes do servio de envio de e-mail; RF03. O sistema deve permitir ao administrador manter as configuraes do servidor InoSensor; RF04. O sistema deve permitir ao administrador visualizar os tipos de aes disponveis para o Arduino; RF05. O sistema deve permitir ao administrador visualizar os tipos de sensores/atuadores disponveis para uso com o Arduino; RF06. O sistema deve permitir ao administrador visualizar os tipos de portas disponveis no Arduino; RF07. O sistema deve permitir ao administrador visualizar os modelos compatveis de Arduino; RF08. O sistema deve permitir ao administrador manter o cadastro de Arduinos gerenciados pela ferramenta;

77 RF09. O sistema deve permitir ao administrador manter sensores e atuadores em um Arduino; RF10. O sistema deve permitir ao administrador manter as aes de um sensor; RF11. O sistema deve permitir ao administrador resetar os alarmes de um Arduino; RF12. O sistema deve permitir ao administrador enviar configurao de aes para o Arduino; RF13. O sistema deve permitir ao administrador monitorar os Arduinos cadastrados no sistema e identificar as notificaes geradas por cada sensor; RF14. O sistema deve permitir ao administrador fazer upload do firmware para o Arduino; RF15. O sistema deve permitir ao administrador validar as configuraes antes de enviar as configuraes para o Arduino.

3.4.1.2 Regras de Negcio As regras de negcio so: RN01. O acesso ao sistema deve ser restrito a administradores cadastrados; RN02. Os tipos de aes sero somente visualizados e no podem ser cadastrados ou alterados pelos administradores. As aes disponveis so: enviar e-mail, acionar atuador e ligar LED RGB; RN03. Os tipos de sensores sero somente visualizados e no podem ser cadastrados ou alterados pelos administradores; RN04. Os tipos de portas sero somente visualizados e no podem ser cadastrados ou alterados pelos administradores. Os tipos de portas so: digital com PWM, digital sem PWM e analgica; RN05. Os modelos de Arduino sero somente visualizados e no podem ser cadastrados ou alterados pelos administradores. Para a verso 1.0 da ferramenta InoSensor, s est disponvel o Arduino Mega; RN06. Ao cadastrar um sensor em um Arduino, o sistema deve restringir as portas necessrias para o funcionamento do sensor selecionado;

78 RN07. Para a verso 1.0 da ferramenta InoSensor, estaro disponveis os sensores: temperatura e umidade, fotoresistor, fogo, vibrao, magntico, presena (PIR) e fumaa; RN08. Para a verso 1.0 da ferramenta InoSensor, estaro disponveis os atuadores: rel, LED RGB e buzzer. RN09. Um Arduino pode ter vrios sensores. Um sensor cadastrado pertence a um nico Arduino; RN10. Um sensor pode ter vrias aes. Uma ao deve estar relacionada a um sensor que est cadastrado em um Arduino. Atuadores no podem ter aes; RN11. Ao reiniciar o alarme de um Arduino pela ferramenta InoSensor, todos os alarmes do dispositivo so desligados; RN12. A configurao de um Arduino s pode ser transmitida se no forem encontrados erros na validao da configurao; RN13. Ao modificar uma configurao, o Arduino deve ser marcado como no sincronizado para alertar o administrador. Aps sincronizar, deve ser marcado como sincronizado; RN14. Ao cadastrar uma ao, deve ser possvel informar se o servidor deve ser notificado da ocorrncia do evento; RN15. Um Arduino deve possuir um IP e MAC Address, que devem ser nicos no sistema; RN16. O envio de configurao para o Arduino deve ser validado com o usurio e senha, antes de gravar a nova configurao no dispositivo; RN17. A atualizao de firmware s pode ser feita por administradores com cadastro no sistema; RN18. Ao atualizar o firmware, deve ser selecionado o dispositivo j cadastrado no sistema; RN19. Uma porta analgica de um sensor s pode ser conectada em uma porta analgica do Arduino; RN20. Uma porta digital sem PWM de um sensor pode ser conectada a uma porta digital com PWM ou uma porta digital sem PWM do Arduino; RN21. Uma porta digital com PWM de um sensor s pode ser conectada a uma porta digital com PWM do Arduino; RN22. Uma porta do Arduino s pode ser conectada a um nico sensor; RN23. A tela de monitoramento de sensores deve ser atualizada automaticamente, de cinco em cinco segundos;

79 RN24. As configuraes do servidor devem ser gravadas no firmware, para permitir a comunicao entre o servidor e o Arduino; RN25. O envio de e-mails deve ser configurvel e permitir a modificao da conta de e-mail pelo administrador; RN26. Cada Arduino deve possuir um usurio e senha no cadastro, que ser utilizado para atualizar as configuraes.

3.4.1.3 Requisitos No-Funcionais Os requisitos no-funcionais identificados so: RNF01. O sistema Web da ferramenta INOSensor ser desenvolvido para ser executado em um servidor PHP utilizando o framework MVC CodeIgniter; RNF02. O banco de dados utilizado ser o MySQL verso 5.1; RNF03. O acesso s funcionalidades do sistema ser realizado por controle de acesso atravs de login e senha; RNF04. O sistema InoSensor deve ser compatvel com os navegadores Firefox 10 ou superior, Internet Explorer 8 ou superior e Google Chrome; RNF05. A camada de viso da ferramenta InoSensor ser desenvolvida utilizando o padro MVC do framework JavaScript ExtJS verso 4.1; RNF06. O mdulo para atualizao de firmware ser desenvolvido em Java; RNF07. O desenvolvimento do firmware para Arduino ser desenvolvido em C utilizando a IDE do Arduino; RNF08. Para o funcionamento da comunicao USB na atualizao do Arduino, ser utilizada a biblioteca Java RXTXcomm; RNF09. A comunicao do Arduino com o mdulo Web InoSensor ser feita via socket pela porta 80 do prprio servidor PHP; RNF10. A comunicao dos dispositivos com o servidor ser feita utilizando o protocolo TCP/IP; RNF11. As configuraes devem ser gravadas em um arquivo texto, denominado config.dat, no formato Comma Separated Value (CSV), salvo em carto SD no Arduino;

80 RNF12. Para facilitar a atualizao de firmware pelo administrador sem conhecimentos em programao, ser utilizada a ferramenta ArduinoBuilder, que dever ser integrada ao mdulo de atualizao de firmware; RNF13. Para simplificar o processo de envio de notificao por e-mail, deve ser utilizada a biblioteca PHPMailer.

3.4.2 Casos de Uso Esta seo apresenta, resumidamente, os casos de uso das funcionalidades implementadas. A Figura 1 apresenta o diagrama contendo os casos de uso da ferramenta InoSensor. UC01. Manter usurio: O acesso a ferramenta InoSensor restrito a usurios cadastrados. Esse caso de uso, possibilita ao administrador do sistema cadastrar, editar e excluir usurios por meio de um formulrio; UC02. Configurar e-mail: Devido a capacidade de enviar emails pelo servidor Web em que a ferramenta InoSensor est configurada e instalada, essa funcionalidade possibilita a configurao do servio de envio de mensagens eletrnicas; UC03. Configurar Servidor: O Arduino precisa se comunicar com a ferramenta InoSensor. Essa funo permite configurar as informaes de rede do servidor; UC04. Monitorar Eventos de Sensores: Permite ao administrador monitorar os eventos disparados pelos sensores de todos os Arduinos que esto configurados no sistema, informando o total de eventos disparados na ltima hora e, caso necessrio, os detalhes desses eventos; UC05. Visualizar tipo de aes: Permite ao administrador visualizar os tipos de aes possveis de serem executadas quando uma condio verdadeira ocorrer em um sensor. Pensando na capacidade de expanso do sistema, a ferramenta foi desenvolvida de forma flexvel, permitindo que aes possam ser adicionadas sem interferir no funcionamento das aes existentes; UC06. Visualizar tipo de portas: Permite ao administrador visualizar os tipos de portas existentes no Arduino; UC07. Visualizar Modelo Arduino: Permite ao administrador visualizar os modelos de Arduino suportados pela ferramenta

81 InoSensor. Para permitir a expanso do sistema, a ferramenta foi desenvolvida de forma flexvel, permitindo que novos modelos sejam adicionados sem interferir no funcionamento dos modelos existentes; UC08. Visualizar tipos de sensores: Permite ao administrador visualizar os tipos de sensores e atuadores possveis para serem conectados ao Arduino. Para facilitar a conexo dos sensores ao Arduino, essa funcionalidade exibe detalhes de cada sensor, informando as caractersticas fsicas, modo de funcionamento e portas utilizadas alm de apresentar a identificao de cada pino respectiva porta; UC09. Manter Arduino: Essa uma das funes mais complexas da ferramenta, pois permite ao administrador cadastrar, editar e excluir os Arduinos atravs de um formulrio com as informaes de identificao e dados para conexo de rede. Aps o cadastro, possvel adicionar, editar e excluir os sensores e atuadores. Depois de selecionar um sensor, so exibidas as portas disponveis para sua conexo com o Arduino. Para os sensores, possvel cadastrar as aes disponveis. Dependendo do sensor selecionado, deve ser configurada a condio para executar a ao e informar se o servidor deve ser notificado da ocorrncia do evento; UC10. Validar Configurao: Aps o cadastro do Arduino e configurao dos sensores, essa funo permite ao administrador validar se o cadastro, sensores e aes esto devidamente configurados e se comunicao com o Arduino est ativa, para que a transmisso possa ser realizada; UC11. Atualizar Firmware: Para que o Arduino possa interpretar as aes e se comunicar com o servidor, inicialmente ele deve estar cadastrado no sistema. Em seguida, deve-se utilizar o utilitrio para atualizao de firmware. Esse utilitrio permite ao administrador gravar o firmware com verso mais recente, com as devidas configuraes necessrias para a comunicao em rede.

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unr
UC10. Validar Configurao extend UC16. Atualizar Firmw are UC12. Resetar Alarme

82

uc Viso Casos de Uso

UC01. Manter Usurio

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unr

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unr
extend

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unr
extend

UC02. Configurar E-Mail

UC013. Manter Arduino Manter UC09. Trial Version EA 9.3 Unr EA 9.3 Unregistered Version Trial EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Sensor/Atuador Administrador

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unr
extend

UC03. Configurar Serv idor

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unr

UC07. Visualizar UC04. Monitorar Aes Version EA 9.3 Unr UC14. ManterTrial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Unregistered EA 9.3 Modelo Arduino Ev entos

Trial Version EA 9.3 Unr EA 9.3 Unregistered Version Trial Trial Version EA 9.3 Unregistered Unregistered EA 9.3 UC15. Visualizar Tipos Visualizar UC08. Visualizar Tipo UC05.
UC11. Atualizar Firmw are Sensores extend Detalhes Sensor

Figura 41 Diagrama de casos de uso

Fonte: produo do prprio autor

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unr

Aes

UC06. Visualizar Tipo Portas

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unr

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unr

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unr

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unr

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unr

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unr

83 3.4.3 Diagramas de Pacotes e Classes A ferramenta InoSensor foi desenvolvida com dois frameworks de desenvolvimento Web. A escolha dessas plataformas foi feita com base em trabalhos anteriores, que demonstraram qualidade e estabilidade na execuo das aplicaes atravs de padres de desenvolvimento de software. Outra caracterstica importante a documentao existente na Internet, que facilita o estudo das tecnologias empregadas. Para o servidor Web, foi escolhido o framework MVC CodeIgniter. Para a camada de apresentao, foi usado o framework ExtJS 4.1, que em sua verso mais recente emprega uma arquitetura baseada tambm no padro MVC, facilitando inclusive a manuteno por diferentes desenvolvedores. Devido complexidade da estrutura de ambos os frameworks, optou-se por elaborar um diagrama de pacotes da UML contendo as principais estruturas implementadas na ferramenta e dividir o sistema em agrupamentos lgicos, para facilitar a compreenso. Somente para a modelagem da camada de apresentao do framework ExtJS, existem cento e sete classes responsveis por controlar todos os componentes. Para a ferramenta de upload de firmware, foi elaborado um diagrama de classes, com a modelagem da ferramenta desenvolvida. Conforme ilustrado na Figura 42, os pacotes no servidor da aplicao InoSensor so divididos nas trs camadas correspondentes a arquitetura MVC: Controller: Para cada funcionalidade, existe uma classe responsvel por tratar as requisies vindas do cliente. O controlador inosensor.php o controlador principal da aplicao e possui a funo de carregar a aplicao da camada de viso desenvolvida atravs do framework ExtJS; Model: Responsvel por acessar o modelo de dados. O framework possui uma camada de abstrao com funes genricas para acesso a diferentes bancos de dados; View: Como a camada de viso foi implementada com o framework ExtJS, todas as informaes retornadas so geradas no padro JSON e so tratadas pelo arquivo json_result.php.

84
Figura 42 Diagrama de pacotes PHP do framework CodeIgniter

Fonte: produo do prprio autor

85 A arquitetura da camada de viso utiliza o padro do framework ExtJS e ilustrada na Figura 43. Cada classe salva em um arquivo separado. As classes so organizadas conforme a sua responsabilidade e so carregadas atravs de uma classe principal denominada Ext. Para iniciar a aplicao, definida uma classe que executa o mtodo launch da classe Application presente no pacote ExtJS. A partir desse ponto, a chamada das funcionalidades ocorre conforme as requisies feitas pelo cliente. Abaixo so descritos os principais pacotes com suas respectivas responsabilidades: App: Pacote que possui o agrupamento de todas as classes que fazem parte da aplicao ExtJS; UX: Nesse pacote so armazenadas classes de extenso do framework, desenvolvidas pela comunidade. Para essa aplicao, foram usadas e adaptadas para a ferramenta duas extenses: gerenciamento de layout e autenticao definido na classe Initialization.js e gerenciamento de rotas de ao, responsvel por gerenciar as funes executadas dentro da aplicao; Controller: Possui as classes separadas de acordo com as responsabilidades e funes disponveis na ferramenta. Dentro dos controladores, so definidas: (i) as classes de modelo que sero acessadas, (ii) aes de botes, (iii) criao de objetos de janela para cadastro, edio, listagem e excluso, (iv) validao das informaes e (v) submisso dos dados para o servidor de aplicao. A classe Viewport responsvel por controlar a diviso das reas da aplicao, como: menu, tela principal e cabealho; View: Esse pacote possui todas as classes responsveis por montar os formulrios e demais objetos visveis na aplicao. Esse objeto criado pela classe da camada de controle. Dentro de cada diretrio, existem subdiretrios contendo basicamente duas classes principais: List, para montar as telas de listagem dos registros exibidos na tela e Edit, responsvel por exibir o formulrio para cadastro ou edio de informaes; Model: Todos os modelos de dados acessados pela ferramenta devem estar criados em classes especficas. Ao definir uma classe de modelo, feito o mapeamento de todos os campos e seus respectivos tipos de dados. Essa classe tambm pode

86 conter informaes de associao com outras classes (um para muitos, muitos para muitos); Store: O framework ExtJS possui uma camada adicional, responsvel por configurar o acesso s informaes e permitir o armazenamento em cache, fornecendo funes de ordenao, filtro e consulta local no lado cliente. Para cada modelo, existe uma respectiva classe Store. Para valores estticos (e.g., Sim, No, Ligado, Desligado) possvel definir as informaes dentro da prpria classe, para o uso em listas de valores (Combo Box).

A ferramenta InoSensor conta com um aplicativo desenvolvido em Java para facilitar o processo de atualizao de firmware do Arduino. Esse aplicativo se comunica com trs ferramentas: (i) o servidor InoSensor, responsvel por prover as informaes de identificao do dispositivo e verses de firmware, (ii) a biblioteca RXTXComm para comunicao via interface serial USB e (iii) o utilitrio ArduinoBuilder, responsvel por compilar o cdigo e fazer o upload do firmware para o Arduino. A biblioteca RXTXComm e o utilitrio ArduinoBuilder so descritos em mais detalhes na seo 4.2.5. As classes relacionadas so ilustradas na Figura 44 e so descritas abaixo: InoSensor: Classe principal, responsvel por iniciar a execuo do utilitrio de atualizao de firmware e controlar as etapas existentes no processo; DefaultStep: Classe responsvel por definir uma janela padro, desenvolvida com a toolkit Swing. A ferramenta composta por trs etapas, todas herdadas desta mesma classe, alterando-se apenas as particularidades de cada janela; ArduinoDao: Classe contendo as informaes relacionadas ao modelo de dados da entidade Arduino; FirmwareDao: Classe contendo as informaes relacionadas ao modelo de dados da entidade firmware; Output: Classe responsvel por exibir o log de atualizao do firmware.

87
Figura 43 Diagrama de pacotes ExtJS

Fonte: produo do prprio autor

88

class Class Model

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version javax.swing.JFrame

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistere
+arduino

InoSensor

DefaultStep

Database

#main

ArduinoDao

-windows

- btAvancarActionPerformed(java.awt.event.ActionEvent) EA 9.3 Unregistered Trial Version Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version+ EA 9.3 Unregistered Trial Version EA 9.3 :Connection getConnection() :I... getCurrentStep() + :void setServidor(String) InoSensor() + EA 9.3 Unregistered Trial Version Unregistered Trial Version:void Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version+ EA 9.3 EA 9.3 # btAvancarClick(java.awt.event.ActionEvent) :void :void setUser() :void main(String[]) + EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version - btVoltarActionPerformed(java.awt.event.ActionEvent) + NextStep() :void EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version :void + PreviousStep() :void EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version DefaultStep(InoSensor) # Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial + setCurrentStep(Inte... :void Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version display() + EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered :void initComponents() EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version
javax.swing.JFrame

0..*

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version

Step2 Trial Version EA 9.3 Unregistered

EA 9.3 Unregistered Trial Version

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version

Step1

Output

EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere

+ display() :void Unregistered Trial Version EA 9.3 Unregistered Trial Version Trial Version EA 9.3 EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered :ArduinoDao + getArduino() - initComponents() :void - btTestarActionPerformed(java.awt.event.ActionEvent) :void :FirmwareDao + getFirmware() Trial Version EA 9.3 Unregistered Trial Version Trial Version EA 9.3 Unregistered Unregistered Trial Version EA 9.3 EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version + :void EA 9.3 Unregistered main(String[]) # DefaultStep(InoSensor) + GetInstance(InoSensor) :DefaultStep Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version + Output() GetInstance(InoSensor) :DefaultStep + :void initComponents() :voidEA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version setText(String) Unregistered Trial Version EA 9.3 EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version + Unregistered Trial Version :void initComponents() -EA 9.3 - selecionarArduino(java.awt.event.ItemEvent) :void Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version Step1(InoSensor) -EA 9.3 - selecionarVersao(java.awt.event.ItemEvent) :void :void testarConexao() + Version EA 9.3 Unregistered Trial Version Trial Version EA 9.3 Unregistered Trial EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Unregistered Trial Version EA 9.3 :void + setArduino(ArduinoDao) Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered :void EA 9.3 Unregistered Trial Version + setFirmware(FirmwareDao) - Step2(InoSensor) Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version Step3
-winOutput +firmware

Figura 44 Diagrama de classes Java

Fonte: produo do prprio autor

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version

+ atualizarPortaSerial() :void EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version # btAvancarClick(java.awt.event.ActionEvent) :void FirmwareDao EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version - btLogActionPerformed(java.awt.event.ActionEvent) :void RXTXcomm Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered 9.3 Unregistered Trial Version Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA EA 9.3 Unregistered Trial Version EA 9.3 Unregistered :Date + getData() :void - TrialbtRefreshActionPerformed(java.awt.event.ActionEvent) :String + getFonte() :void + Trialdisplay() Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version Version EA 9.3 EA 9.3 Unregistered Trial Version EA 9.3 Unregistered :int Trial Version EA 9.3 Unregistered Trial Version + getId() ArduinoBuilder + TrialGetInstance(InoSensor) EA 9.3 Unregistered Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version Version EA 9.3 Unregistered Trial:DefaultStep Trial Version EA 9.3 Unregistered EA 9.3 Unregistered + getModelo_arduino_id() :int - getWinOutput() :Output EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version + getVersao() :String - initComponents() :void EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version + setData(Date) :void - selecionarArduino(java.awt.event.ItemEvent) :void EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version + setFonte(String) :void - Step3(InoSensor) Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version :void + setId(int) :void + setModelo_arduino_id(int) Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version :void EA 9.3 Unregistered Trial Version + setVersao(String) EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version :String toString() + EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version

+ getAtivo() :String 9.3 Unregistered Trial Version Trial Version EA :String EA 9.3 Unregistered + getDescricao() :int EA 9.3 Unregistered Trial Version + getId() Trial Version EA 9.3 Unregistered :String getIp() + EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version + getMac_address() :String EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version + getMascara_rede() :String EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version + getModelo_arduino_id() :int EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version + getSenha() :String 9.3 Unregistered Trial Version Trial Version EA EA 9.3 Unregistered :String + getUsuario() :void + setAtivo(String) Unregistered Trial Version Trial Version EA 9.3 EA 9.3 Unregistered :void Trial Version + setDescricao(String) Trial Version EA 9.3 Unregistered EA 9.3 Unregistered :void setId(int) + EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version + setIp(String) :void EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version + setMac_address(String) :void EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version + setMascara_rede(String) :void Version Trial Version EA 9.3 Unregistered Trial EA 9.3 Unregistered :void + setModelo_arduino_id(int) + setSenha(String) Unregistered Trial Version Trial Version EA 9.3:void EA 9.3 Unregistered :void Trial Version + setUsuario(String) Trial Version EA 9.3 Unregistered EA 9.3 Unregistered + toString() :String EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere

EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregistere

89 3.4.4 Diagrama Entidade-Relacionamento Na Figura 45, apresentado o Diagrama Entidade Relacionamento (DER) do banco de dados da ferramenta InoSensor. A descrio das entidades geradas so descritas na sequncia.

90
Figura 45 Diagrama entidade relacionamento

Fonte: produo do prprio autor

91 config_email: Entidade responsvel por armazenar as configuraes, para que o servidor Web possa enviar e-mail; config_sistema: Entidade responsvel por armazenar as configuraes de rede do servidor de aplicao que sero utilizadas para a atualizao do firmware do Arduino; usuario: Entidade responsvel por armazenar o cadastro de administradores que tero acesso ferramenta e atualizao de firmware; tipo_acao: Entidade responsvel por armazenar os tipos de aes possveis de serem executadas pelo Arduino; tipo_porta: Entidade responsvel por armazenar os tipos de portas existentes em um Arduino; porta_arduino: Entidade responsvel por mapear as portas existentes em cada modelo de Arduino, de acordo com a identificao existente; sensor: Entidade responsvel por armazenar os tipos de sensores suportados pela ferramenta, a descrio dos sensores e a classe JavaScript correspondente ao sensor para carregamento dinmico; porta_sensor: Entidade responsvel por armazenar o nmero e os tipos de portas utilizadas por cada sensor. arduino: Entidade responsvel por armazenar os Arduinos cadastrados para gerenciamento no sistema; sensor_arduino: Entidade responsvel por armazenar os sensores conectados a cada Arduino, sua descrio e estado inicial; sensor_arduino_porta: Entidade responsvel por armazenar a porta em que um sensor est conectado respectiva porta do Arduino; acao_sensor_arduino: Entidade responsvel por armazenar as condies de verificao dos sensores e aes que devem ser executadas quando uma condio verdadeira ocorrer; notificacao: Entidade responsvel por armazenar as notificaes geradas pelo Arduino, para serem exibidas no painel de notificaes; email: Entidade responsvel por armazenar as solicitaes de envio de e-mail geradas pelo Arduino; Firmware: Entidade responsvel por armazenar as verses de firmware por modelo de Arduino.

92 3.4.5 Diagrama de Atividades O diagrama de atividades da Figura 46 apresenta a sequncia das atividades que devem ser executadas na ferramenta, para possibilitar o gerenciamento do Arduino.
Figura 46 Diagrama de atividades

Fonte: produo do prprio autor

93 3.5 CONCLUSES DO CAPTULO A elaborao do projeto foi responsvel por delimitar o escopo da ferramenta InoSensor, visando contemplar os objetivos propostos pelo trabalho. Os artefatos e diagramas gerados durante a especificao da ferramenta serviram de base para o desenvolvimento e so importante fonte de referncia para trabalhos futuros, pois alm de simplificar a compreenso, so responsveis por abstrair a complexidade de todos os componentes utilizados na fase de desenvolvimento. Durante a implementao, algumas funcionalidades sofreram alteraes e foram posteriormente atualizadas na documentao.

94 4 IMPLEMENTAO Neste captulo, so apresentados os resultados obtidos durante a fase de implementao e integrao das solues da ferramenta InoSensor. Tambm so abordadas as bibliotecas utilizadas, capazes de acelerar o desenvolvimento em verses futuras do sistema. 4.1 PADRES DE PROJETO MVC Visando oferecer uma plataforma robusta e facilitar a expanso das funcionalidades existentes na verso inicial da ferramenta InoSensor, optou-se por utilizar na camada do servidor Web, padres e bibliotecas bastante difundidos e documentados na Internet. A arquitetura MVC bastante comum em linguagens como PHP, Java e .NET. Durante as pesquisas em busca de solues para serem empregadas no projeto, foi encontrada a biblioteca JavaScript ExtJS em uma verso reformulada para adotar o padro MVC atravs do framework Sencha. Entre as inmeras vantagens dessa soluo, est a capacidade de separao das funcionalidades, alm da possibilidade de identificar os componentes de forma rpida, durante uma manuteno ou expanso. 4.2 TECNOLOGIAS E FERRAMENTAS O desenvolvimento da ferramenta InoSensor envolveu o uso de diferentes tecnologias, linguagens de programao e ferramentas. Com exceo da modelagem dos diagramas da UML, que foram elaborados na ferramenta Enterprise Architect em verso de avaliao, as demais tecnologias e ferramentas so todas open source. 4.2.1 Servidor Web Para o desenvolvimento da camada de aplicao da ferramenta InoSensor, foi utilizado o servidor Web Apache3 juntamente com a linguagem de programao PHP4 na verso 5.3.0, uma linguagem bastante prtica que conta com diversos recursos para realizar tarefas

3 4

Disponvel em: http://www.apache.org/ Disponvel em: http://www.php.net/

95 como comunicao via socket, gerao de arquivos e acesso a banco de dados de forma bastante simples e rpida. Juntamente com o PHP, foi utilizado o framework MVC CodeIgniter verso 2.1, para separar as camadas da aplicao, prover os mecanismos de acesso ao banco de dados e para a comunicao com a camada de viso com o uso de requisies Asynchronous JavaScript And XML (AJAX) e JSON. O sistema foi implementado na IDE de desenvolvimento Eclipse, juntamente com o plug-in PHP Development Tools (PDT), responsvel por suportar as particularidades e extenses da linguagem. 4.2.2 ExtJS Toda a interface do servidor InoSensor foi desenvolvida com a nova SDK do framework EXTJS5, baseada nos padres MVC e de orientao a objetos. A partir da verso 4.0, toda a arquitetura do framework foi remodelada seguindo os mais recentes padres de desenvolvimento de software. Sua API composta de centenas de componentes, para criar as mais diversas solues com interfaces semelhantes aplicaes desktop, com a vantagem de serem executadas diretamente do navegador Web, inclusive com suporte para recursos do HTML5. O desenvolvimento de aplicaes para Web exige grande esforo durante a elaborao da interface, pois os navegadores usam mecanismos de renderizao diferentes, sendo necessrio adaptar diferentes verses de cdigo e layout para manter a compatibilidade. No framework ExtJS, essa tarefa feita de forma transparente, devido a compatibilidade com as verses mais recentes dos principais navegadores, como Internet Explorer, Mozilla, Opera, Chrome e Safari. A Figura 47 exemplifica a arquitetura do framework. Ao desenvolver um projeto, definida uma aplicao, carregada uma nica vez pela pgina principal. Essa aplicao gerencia todos os componentes e carrega o controlador de acordo com a funo selecionada. Ao executar uma ao, o controlador responsvel por enviar as solicitaes para buscar os dados do servidor e por instanciar os objetos e componentes que fazem parte da camada de viso para serem exibidos para o usurio. O framework ExtJS permite manipular os dados localmente (e.g., ordenao, armazenamento em cache), reduzindo o
5

Disponvel em: http://www.sencha.com/products/extjs

96 nmero de acessos ao servidor da aplicao. Outra caracterstica importante do framework a possibilidade de carregar classes JavaScript de forma dinmica, fazendo com que as classes sejam baixadas do servidor na medida em que as solicitaes so feitas, o que gera uma menor sobrecarga na inicializao da aplicao.
Figura 47 Diagrama MVC da aplicao InoSensor

App.js

Aplicao

Controlador

Navegador Web

Modelo

Viso

Fonte: produo do prprio autor

Como no existem ferramentas com suporte total a programao em JavaScript, foram utilizados o editor Notepad++ para codificao e o utilitrio Firebug do navegador Mozilla Firefox, para depurao do cdigo. 4.2.3 C/C++ Para implementar o firmware do Arduino, foram estudadas as particularidades da linguagem C/C++, para o desenvolvimento da soluo. A documentao das bibliotecas e exemplos existentes na

97 Internet facilitaram o aprendizado e auxiliaram durante o desenvolvimento da comunicao entre o Arduino e o Servidor Web InoSensor. A ferramenta para o desenvolvimento foi a prpria IDE do Arduino. 4.2.4 Java A forma convencional de atualizar o firmware do Arduino atravs da IDE, com o dispositivo conectado porta USB do computador. Como o objetivo da ferramenta InoSensor era facilitar o gerenciamento de Arduino, mesmo por pessoas sem conhecimentos em programao, optou-se por desenvolver um utilitrio para atualizar o firmware sem a necessidade de instalar a IDE. Devido necessidade de enumerar os dispositivos USB conectados ao computador, foi encontrada a biblioteca Java RXTXComm. Desenvolvida pela empresa americana MFizz, responsvel por prover os mecanismos necessrios para deteco e comunicao de dispositivos conectados interface serial ou paralela, a qual se mostrou bastante prtica e eficiente. Entre outros benefcios obtidos com o uso do Java, esto a capacidade de comunicao com o banco de dados do servidor InoSensor para controlar o acesso a usurios cadastrados e a possibilidade do usurio selecionar verses sempre atualizadas, j que o cdigo fonte fica armazenado no servidor. O desenvolvimento das interfaces foi feito pela IDE NetBeans verso 7.1.2 que facilitou a integrao com todas as bibliotecas. 4.2.5 Arduino Builder O firmware padro para todos os Arduinos usados com a ferramenta, porm devido s necessidades de configurao da comunicao (e.g., IP, mscara, MAC Address) e segurana (e.g., usurio, senha), foi necessrio compilar o cdigo com as particularidades de cada Arduino. Essas informaes so gravadas no cdigo fonte, no momento de iniciar a compilao do cdigo. A compilao de cdigo exige diversas etapas como compilao, gerao de arquivo-objeto e linking, para finalmente gerar o arquivo final (HEX) para upload no Arduino. A IDE do Arduino no possui uma verso simplificada para execuo via linha de comando, por isso optou-se por utilizar o Arduino

98 Builder, uma ferramenta alternativa para compilao de cdigo e atualizao de firmware para Arduino, formado pelo compilador AVRGCC, juntamente com as bibliotecas da prpria IDE do Arduino. O Arduino Builder6 conta com um utilitrio via linha de comando, denominado Arduino Uploader, tanto para compilar o cdigo quanto para atualizar o firmware do Arduino conectado na interface USB do computador. Sua execuo bastante simples, sendo necessrio informar basicamente trs parmetros: nome do arquivo de sketch, modelo do Arduino e porta USB.
Figura 48 Prompt de comando do Arduino Builder

Fonte: produo do prprio autor

4.3 BANCO DE DADOS Para armazenar as informaes no servidor InoSensor, foi utilizado o SGBD relacional MYSQL7 verso 5.1. Esse banco de dados foi escolhido devido sua popularidade em aplicaes Web e principalmente velocidade, facilidade e ao suporte pela grande maioria das linguagens de programao. A modelagem do banco de dados foi feita com a ferramenta MySQL Workbench CE na verso 5.1.
6 7

Disponvel em: http:// arduinodev.com/arduino-uploader/ Disponvel em: http:/www.mysql.com/

99 4.4 PROTOCOLO DE CONFIGURAES DO ARDUINO Para a comunicao entre o Servidor InoSensor e o Arduino, foi definido um protocolo de comunicao com socket TCP/IP. O Arduino pode atuar de duas formas: como um cliente socket, responsvel por enviar as notificaes da ocorrncia de eventos diretamente para o servidor PHP, ou atravs do envio de mensagens com o protocolo HTTP 1.18. J para receber novas configuraes do servidor InoSensor, o Arduino cria um servidor socket, realiza a autenticao para validar o usurio e senha armazenados no Arduino e em seguida inicia a transmisso das informaes para finalmente grav-las em um arquivo texto no padro CSV. Para evitar que uma nova configurao seja transmitida incompletamente e impea o funcionamento, a nova configurao gravada em um arquivo temporrio e s passa a ser vlida aps a devida finalizao da conexo entre o Servidor InoSensor e o Arduino. A Figura 49 mostra a estrutura simplificada do arquivo de configuraes. Cada n possui um identificador iniciado com o prefixo begin (e.g., beginauth) seguido do nome do bloco e pela palavra end (e.g., endauth), que informa o fim de um bloco.

Disponvel em: http://w3.org/Protocols/rfc2616/

100
Figura 49 Estrutura simplificada do arquivo CSV

101
Fonte: produo do prprio autor

Os cinco ns principais existentes no arquivo de configurao so descritos abaixo: Authorization: formado pelas informaes para autenticao. Como o Arduino possui uma senha, no arquivo devem ser informados os respectivos usurio e senha cadastrados no sistema. Caso a autenticao falhe, o firmware ir abortar as verificaes e aes dos sensores; Version: Possui as informaes da verso do firmware, permitindo ao servidor identificar a verso instalada no Arduino; Network: Possui as informaes necessrias configurao e ao acesso rede, alm de conter as informaes para comunicao com o servidor InoSensor; Pins: Possui as informaes relacionadas s configuraes das portas do Arduino, identificando-as como portas de entrada ou sada e inicializando seu estado; Checks: Esse bloco pode conter uma ou mais verificaes, armazenadas linha a linha. Para cada tipo de sensor existe uma regra padro para montar o registro. Ao final de cada registro de verificao existe a ao que deve ser executada quando a condio do sensor for verdadeira. Em cada registro tambm est presente um flag, informando se o servidor deve ser notificado da ocorrncia do evento ou no.

4.5 APRESENTAO DA FERRAMENTA Nesta seo, so apresentados todos os mdulos desenvolvidos na ferramenta InoSensor e so relacionados com os devidos identificadores dos requisitos funcionais e regras de negcio a que se referem, com o objetivo de demonstrar a execuo das atividades previstas na etapa de projeto. 4.5.1 Mdulo Web InoSensor A interface principal do sistema possui uma estrutura padro de navegao. Em sua parte central so carregadas as funcionalidades, de acordo com a funo que deve ser selecionada no menu, posicionado esquerda da tela (Figura 50). O painel de notificaes fica disponvel na

102 parte inferior da aplicao para que, durante o uso da ferramenta, novas notificaes possam ser visualizadas rapidamente.
Figura 50 Tela inicial da ferramenta InoSensor

Fonte: produo do prprio autor

4.5.1.1 Cadastro de Usurios Para manter a segurana e garantir que as modificaes sejam feitas somente por usurios autorizados, necessrio que os responsveis tenham um usurio cadastrado (RF01, RN01; ver subseo 3.4.1) no servidor InoSensor. Esse usurio necessrio para acessar a ferramenta Web e controlar a atualizao do firmware do Arduino. Ao acessar a funo do menu, so listados todos os usurios cadastrados no sistema (Figura 51). Caso necessrio, um usurio pode ser desativado diretamente da lista. Ao clicar no boto superior direito, no sinal positivo (+), exibida a janela para o cadastro de usurio. Para alterao, basta executar um duplo clique na linha em que se encontra o usurio que se deseja alterar.

103
Figura 51 Tela de usurios da ferramenta InoSensor

Fonte: produo do prprio autor

4.5.1.2 Configurao Geral Para tornar as configuraes da ferramenta mais flexveis, foi desenvolvido um mdulo para armazenar o endereo do servidor (RF03, RN24) e permitir ao firmware do Arduino se comunicar com a ferramenta. Esto disponveis nessa configurao trs temas, que modificam as caractersticas e cores do layout. 4.5.1.3 Configurao de E-mail Para gerar maior flexibilidade na configurao do servio de email (RF02, RN25), possvel alterar as informaes da conta de e-mail responsvel pelo envio das mensagens. 4.5.1.4 Tipo de Ao Essa funo exibe uma relao de todos os tipos de aes (RF04, RN02) possveis de serem executadas pelo Arduino e que esto disponveis na verso atual. No caso de novas aes serem adicionadas em verses futuras, elas sero facilmente visualizadas dentro da ferramenta. Os tipos de aes no podem ser alterados, pois impactam em mudanas no Servidor e no firmware do Arduino.

104 4.5.1.5 Sensor Essa funo exibe uma relao de todos os sensores e atuadores (RF05, RN03) disponveis na verso atual, exibindo os detalhes dos sensores suportados pela ferramenta InoSensor e facilitando a conexo dos sensores ao Arduino. Ao executar um duplo clique sobre um registro da lista, exibida uma janela contendo informaes como a identificao dos pinos e detalhes do sensor ou atuador selecionado (Figura 52). Os tipos de sensores no podem ser alterados, pois impactam em mudanas no Servidor e no firmware do Arduino.
Figura 52 Tela de detalhes do sensor

Fonte: produo do prprio autor

4.5.1.6 Tipo de Porta Os tipos de portas existentes no Arduino so categorizados e exibidos nessa funo (RF06, RN04). Essas categorias so utilizadas na fase de configurao dos sensores, conforme as suas caractersticas. Os

105 tipos de portas no podem ser alterados, pois esto relacionados ao hardware do Arduino. 4.5.1.7 Modelo de Arduino Os modelos de Arduino (RF07, RN05) compatveis com a ferramenta InoSensor so listados nessa funo. Para cada modelo so informadas as portas e as respectivas quantidades. Ao executar um duplo clique, possvel visualizar os detalhes (Figura 53) de todas as portas, como nmero, identificao presente no hardware, tipo de porta correspondente e se possui suporte a PWM.
Figura 53 Exibio das configurao de portas do Arduino

Fonte: produo do prprio autor

4.5.1.8 Arduino Para iniciar a configurao de um Arduino, necessrio cadastrar o dispositivo (RF08, RN15, RN26). Ao acessar a listagem, so exibidos todos os Arduinos cadastrados (Figura 54), com indicao de conectividade e sincronizao. Caso um Arduino esteja com o alarme disparado, possvel desligar o alarme remotamente, atravs do boto de reset de alarme (RF11, RN11).

106
Figura 54 Lista de Arduinos cadastrados

Fonte: produo do prprio autor

107 Ao clicar no boto para cadastrar um Arduino, exibida uma janela com as informaes necessrias para o funcionamento e identificao do dispositivo na rede (Figura 55).
Figura 55 Tela de cadastro de Arduino

Fonte: produo do prprio autor

Aps o cadastro, devem ser configurados todos os sensores que estaro presentes no Arduino. Ao selecionar um sensor, so listadas as respectivas aes cadastradas (Figura 56). Tambm possvel excluir e alterar tanto as aes quanto os sensores, com um duplo clique.

108
Figura 56 Lista de sensores e aes do Arduino

Fonte: produo do prprio autor

109 Inicialmente, ao cadastrar um novo sensor (RF09, RN06, RN07, RN08, RN09, RN19, RN20, RN21, RN22), deve ser selecionado um dos tipos de sensores suportados (Figura 57). Abaixo do lado esquerdo da janela, so exibidas todas as portas disponveis no Arduino para serem conectadas. Essas portas esto categorizadas por tipo e nome, para facilitar a identificao. Do lado direito, so exibidas as portas necessrias para o sensor selecionado. Para conectar uma porta do Arduino porta do sensor ou atuador, basta arrastar a porta desejada do Arduino at a respectiva porta do sensor, respeitando-se o tipo de porta. Aps uma porta ser conectada a um sensor, ela no estar mais disponvel para uso por outro sensor.
Figura 57 Tela para cadastro de sensor

Fonte: produo do prprio autor

Aps um sensor ser cadastrado, possvel adicionar uma ou mais aes (RF10, RN10, RN14) disponveis na ferramenta. Ao abrir a janela para cadastro de ao, deve ser informada uma descrio e a condio desejada (Figura 58). Essa condio dependente do tipo de sensor. Em seguida, deve ser informada a ao que ser executada caso a condio informada seja verdadeira. Nesse momento, deve ser

110 informado se a ocorrncia da condio deve notificar o servidor InoSensor.

Figura 58 Tela para cadastro de ao de um sensor

Fonte: produo do prprio autor

Aps a configurao, deve ser executada a validao (RF15), para certificar-se de que nenhuma informao importante esteja faltando ou seja incorreta (Figura 59). As verificaes so categorizadas em dois tipos: uma advertncia simplesmente responsvel por alertar o usurio de possveis problemas que possam ocorrer, como uma senha muito curta, j uma mensagem de erro informa que alguma informao est ausente ou incorreta e ir impedir o envio das configuraes para o Arduino. Somente aps a correo dos erros, ser possvel atualizar as configuraes do Arduino (RF12, RN12, RN13, RN16). Antes de um Arduino receber as configuraes, realizada uma autenticao com o usurio e senha armazenados no firmware do Arduino, impedindo que novas configuraes sejam gravadas indevidamente. Caso ocorra alguma alterao no Arduino, ser exibido um cone, informando que as configuraes devem ser sincronizadas novamente.

111
Figura 59 Tela de verificao de configurao

Fonte: produo do prprio autor

4.5.1.9 Monitoramento Com o Arduino atualizado e devidamente configurado no servidor, j possvel monitorar os sensores (RF13, RN23) conectados a cada dispositivo. Periodicamente, o sistema verifica se novas notificaes esto disponveis e as exibe em um painel com detalhes como identificao do Arduino, o sensor que criou a notificao e a data em que o servidor foi notificado (Figura 60).

112
Figura 60 Tela de notificaes

Fonte: produo do prprio autor

113 4.5.2 Mdulo Atualizao de Firmware O utilitrio responsvel por atualizar o firmware (RF14, RN17, RN18, RN24) com a verso mais recente disponvel no servidor InoSensor. Para utiliz-lo, necessrio ter um usurio cadastrado no servidor InoSensor. O utilitrio executado localmente em um computador com interface USB, atravs da qual ser conectado o Arduino para atualizao (Figura 61). O processo composto de trs etapas. Na primeira fase, devem ser informados os dados do servidor e usurio para autenticao. No segundo passo, deve ser selecionado o Arduino que se deseja atualizar e, por fim, deve ser conectado o Arduino interface USB, para que o sistema possa detect-lo e assim iniciar a gravao do firmware.
Figura 61 Tela do assistente de configurao

Fonte: produo do prprio autor

4.6 CONCLUSES DO CAPTULO Para a implementao dos mdulos da ferramenta InoSensor, as tecnologias do servidor Web tiveram que ser estudadas para tornar vivel o emprego do padro MVC proposto pelos framework. O material da fundamentao terica do Arduino serviu de base para a implementao do firmware. A documentao existente na Internet

114 tambm foi fundamental para resolver todos os problemas identificados durante o desenvolvimento.

115 5 TESTES E VALIDAO Este captulo apresenta os resultados dos testes executados para validao da ferramenta, com o objetivo de avaliar seu funcionamento em condies normais de uso. Segundo Dijkstra (1972 apud GOLDMAN; KON, 2004), a realizao de testes uma maneira eficaz de detectar a presena de erros, porm insuficiente para demonstrar a sua total ausncia. A execuo de testes pode ser considerada uma tentativa sistemtica para encontrar erros em programas que espera-se estar em pleno funcionamento (GOLMAN; KON, 2004). Os testes da ferramenta InoSensor foram efetuados em paralelo ao desenvolvimento, com o objetivo de identificar possveis falhas e garantir a integrao entre todos os mdulos. 5.1 TESTES DO FIRMWARE DO ARDUINO Durante o desenvolvimento do firmware do Arduino, foram realizados testes individuais para avaliar o funcionamento das caractersticas especficas de cada sensor e atuador. Foram testados dois modelos de Arduino, o Arduino Uno e Arduino Mega2560. Todos os componentes de hardware do projeto foram conectados ao Arduino com o uso de uma protoboard. O Quadro 4 mostra a relao de todos os equipamentos utilizados durante os testes e o preo mdio unitrio, em dlares, dos componentes comprados pela Internet no site http://www.dx.com.

116
Quadro 4 Componentes eletrnicos do projeto

Componente Arduino Uno Arduino Mega2560 Shield ethernet com interface para carto SD Carto Memria MicroSD 2GB Protoboard Sensor Fogo Sensor de Fumaa Sensor de Temperatura e Umidade Fotoresistor Sensor Vibrao Sensor Magntico Sensor IR de presena Rel LED RGB Buzzer

Quantidade 1 1 1 1 1 1 1 1 1 1 1 2 3 2 2

Preo USD 18,6 23,0 15,0 4,9 4,5 3,0 3,8 3,1 2,2 3,1 2,4 5,3 2,4 2,0 2,6

Fonte: produo do prprio autor

Durante os testes, optou-se por definir rotinas especficas para cada sensor, visando facilitar os testes individuais e uma melhor integrao entre todas as partes que compem o firmware do Arduino. Aps os testes dos sensores e atuadores, foi desenvolvido o firmware do Arduino. Para simular o arquivo de configuraes que posteriormente seria gravado na memria externa do carto SD, foi montada uma estrutura de dados para armazenar as informaes. A partir desse ponto, foi possvel ter uma ideia de como o sistema se comportaria aps as configuraes serem transmitidas do servidor InoSensor para o Arduino. A qualidade dos sensores um ponto que merece destaque. Devido ao baixo custo dos sensores adquiridos inicialmente, observouse que a acurcia das informaes lidas de alguns senores acabava sendo afetada, tornando o sistema ineficaz e em alguns casos at gerando informaes incorretas. Para resolver esse problema, foram adquiridos novos sensores com um custo um pouco mais alto, porm que mostraram ser mais precisos e tolerantes a falhas.

117 Os testes dos sensores e atuadores foram realizados com o uso do monitor da interface serial USB presente na IDE do Arduino, para verificar o comportamento do firmware. 5.2 TESTES DE INTEGRAO Aps testar todos os sensores individualmente, foram iniciados os testes de integrao entre o servidor InoSensor e o Arduino, para avaliar o comportamento de todo o conjunto. Nessa fase, iniciaram-se os testes do shield ethernet, atravs da comunicao com o servidor em uma rede TCP/IP e do armazenamento das configuraes do Arduino em memria externa. Para isso, foram utilizados os equipamentos listados no Quadro 5.
Quadro 5 Equipamentos para testes do projeto

Componente Roteador TPLINK Cabo ethernet Servidor InoSensor

Descrio Roteador com 4 portas ethernet Cabos para conectar o Arduino e o servidor no roteador Microcomputador Processador Intel Core i7 2.4GHz, 8GB RAM, 256GB SDD, Sistema Operacional Windows 8 Professional, XAMPP LITE (PHP 5.3, MySQL 5.1, APACHE)
Fonte: produo do prprio autor

Quantidade 1 2

Para facilitar o estudo das funes de rede disponveis para o Arduino, inicialmente foram feitos os testes atravs dos exemplos disponveis na prpria IDE do Arduino. Em seguida, foram criadas as rotinas de conexo via socket no servidor PHP, necessrias tanto para o envio de notificaes do Arduino para o Servidor, quanto para a transmisso de configuraes do Servidor para o Arduino. As bibliotecas disponveis em ambos os ambientes facilitaram a integrao

118 e se mostraram bastante estveis durante o envio e recebimento de informaes. O mesmo processo foi realizado para testar o armazenamento das configuraes no carto de memria SD, disponvel no shield ethernet. Foi identificada uma caracterstica interessante, que facilitou bastante o uso de ambas as solues: a seleo automtica do barramento de comunicao serial entre o microcontrolador e os perifricos, j que somente um perifrico por vez pode acessar o barramento. Em verses mais antigas das bibliotecas do Arduino, o controle era feito de forma manual e a responsabilidade ficava por conta do desenvolvedor. Nas verses mais recentes, possvel deixar que a prpria biblioteca gerencie os perifricos no barramento SPI. Aps a integrao entre todos os mdulos, foi testada a atualizao do firmware do Arduino atravs do assistente de configuraes desenvolvido com o Arduino Builder. Essa ferramenta se mostrou bastante simples e funcional para a compilao do firmware sem a utilizao da IDE. 5.3 TESTE DE ESCALABILIDADE DO FIRMWARE Ao desenvolver solues de firmware para microcomputadores, convencionalmente no necessrio controlar a alocao de memria, j que esses recursos possuem grande capacidade de armazenamento. Normalmente, essa tarefa controlada pelo sistema operacional, que gerencia a memria. Porm, o desenvolvimento para microcontroladores exige um conhecimento aprofundado da plataforma e deve se levar em considerao as limitaes de processamento e memria de cada dispositivo. A ferramenta Arduino Builder possui um recurso para exibir o percentual de consumo por cada tipo de memria. Essas informaes so geradas pelo compilador AVR para os microcontroladores Atmel e so exibidas em grficos para facilitar a visualizao da memria total. Na Figura 62 so exibidos trs grficos. O primeiro para a memria Flash, onde fica armazenado o firmware do Arduino, o segundo para a memria SRAM e o terceiro e ltimo para a memria EEPROM. O tamanho total da verso do firmware ficou em aproximadamente 53KB (53954 bytes) e a memria das variveis em torno de 3KB (3116 bytes). Como o Arduino Mega2560 possui uma memria de programa de 256KB, isso representa aproximadamente 20,6% da capacidade total do Arduino, o que permite ampliar as funcionalidades sem comprometer as limitaes do hardware.

119
Figura 62 Memria utilizada pelo Arduino Mega2560

Fonte: produo do prprio autor

5.4 PROBLEMAS IDENTIFICADOS Para testar o desempenho e disponibilidade do hardware, foi aplicado um teste de estresse do firmware com o objetivo de avaliar o funcionamento do Arduino. Aps algumas iteraes no programa principal, observou-se o congelamento do microcontrolador, tornando o sistema inoperante. O microcontrolador voltou ao funcionamento somente aps a reinicializao feita pelo boto reset. Para identificar o problema, as partes do sistema foram isoladas e testadas individualmente at que se identificou que o problema estava sendo ocasionado na leitura das configuraes em variveis do tipo String. Aps pesquisas feitas na Internet, identificou-se que o problema era causado pela biblioteca String.h, responsvel por controlar a memria para alocao de variveis. Esse problema havia sido corrigido

120 na verso 1.0.5 da IDE do Arduino, ento aps a atualizao da IDE no ocorreram mais travamentos. Inicialmente, a proposta contemplava o uso de ambos os modelos do Arduino citados anteriormente, porm somente o Arduino Mega2560 se mostrou compatvel, devido ao tamanho final do firmware e memria para o Arduino Uno ser de apenas 32KB. Mesmo com as configuraes armazenadas no carto SD e com a otimizao do cdigo, no foi possvel utiliz-lo na verso 1.0 da ferramenta InoSensor. Para tentar identificar os cdigos do programa que estavam consumindo a maior quantidade de memria, todas as funcionalidades foram isoladas. Ao final dos testes, foi identificado que somente as bibliotecas para comunicao via ethernet e SD consumiam aproximadamente 19KB (18716 bytes), cerca de 57,1% da memria total do Arduino Uno, conforme ilustra a Figura 63.
Figura 63 Memria utilizada pelo Arduino Uno

Fonte: produo do prprio autor

121 A biblioteca nativa para manipulao de memria SD era bastante limitada, pois no permitia, por exemplo, renomear arquivos. Sendo assim, foram pesquisadas bibliotecas alternativas e mais eficientes para tornar essa tarefa mais segura e fazer com que a nova configurao somente seja ativada aps a concluso da transmisso das informaes pelo servidor. 5.5 CONCLUSES DO CAPTULO Os testes de integrao entre os mdulos da ferramenta foram fundamentais para garantir o funcionamento de acordo com os objetivos propostos pelo trabalho. As informaes disponveis na Internet foram essenciais para a soluo dos problemas encontrados durante as fases de desenvolvimento e testes do projeto. Para testar a compatibilidade da interface visual do framework ExtJS, foram executados os testes nos principais navegadores disponveis (Internet Explorer verso 10, Firefox verso 23 e Google Chrome na verso 28). Os resultados mostraram total funcionamento no Firefox e no Google Chrome. J o navegador Internet Explorer se comportou de maneira inesperada em algumas situaes, sendo necessria a atualizao da pgina Web do servidor para continuar a utilizao da ferramenta. A otimizao do cdigo para a execuo do firmware no modelo Uno necessitaria de um grande trabalho e maior conhecimento da linguagem C. Para tentar solucionar o problema, o firmware deveria ser programado com recursos de baixo nvel, porm ainda assim, o desenvolvimento de novas verses da ferramenta seria limitado.

122 6 CONCLUSES Esse trabalho teve como objetivo desenvolver uma ferramenta para gerenciamento de sensores na plataforma Arduino e facilitar o processo de atualizao de configuraes sem a necessidade de reprogramar o firmware, alm de permitir que interessados possam utilizar a plataforma mesmo sem conhecimentos em programao. A ferramenta InoSensor tambm pode servir de apoio disciplinas como Programao, Redes de Computadores e Eletrnica Bsica, pois muitos dos componentes e bibliotecas podem ser facilmente adaptados e modificados, melhorando a absoro de conhecimento com exemplos prticos. Devido aos diferentes sensores disponveis, foram selecionados os mdulos com caractersticas similares e que poderiam atuar em conjunto para serem empregados no monitoramento de ambientes. Na fundamentao terica (Captulo 2), foram apresentados os estudos relacionados Automao e a sua consequente evoluo, que deram origem a Domtica. Tambm foram analisadas algumas das solues atuais para Automao residencial e as particularidades da plataforma Arduino, com o objetivo de compreender o seu funcionamento e aplicar a soluo mais adequada ao projeto. Para finalizar esses estudos, foram pesquisadas e comparadas solues similares disponveis, a fim de verificar as contribuies geradas pela ferramenta InoSensor. Na parte de projeto (Captulo 3), foi definida a soluo proposta atravs da especificao e modelagem da ferramenta, com o uso da notao UML. Para a documentao, foram elaborados os casos de uso, requisitos e regras de negcio. Tambm foram elaborados diagrama de classe, ER, pacotes e atividades, para que as pessoas interessadas possam compreender a soluo desenvolvida. Todas as etapas da fase de implementao (Captulo 4) foram documentadas com os mdulos desenvolvidos. Optou-se pelo emprego de framework para facilitar que novas verses possam ser desenvolvidas em trabalhos futuros. Para melhorar a usabilidade da ferramenta e garantir compatibilidade com os navegadores, devido as caractersticas Web da ferramenta InoSensor, optou-se por um framework desenvolvido com os padres da Web 2.0. A escolha do framework ExtJS foi feita com base em trabalhos acadmicos j realizados anteriormente e que se mostraram bastante prticos e funcionais.

123 Com a verso 4.0 do ExtJS, foi necessrio estudar as novas particularidades, devido aos padres e a estrutura MVC do framework. Mesmo com a complexidade, a soluo proposta por essa verso se mostrou bastante eficiente, principalmente durante a manuteno do cdigo. Aps a implementao da soluo, foi testada a integrao entre todos os mdulos, para avaliar o funcionamento correto em condies normais de uso. Devido limitao do tempo disponvel, no foi possvel executar um teste mais elaborado para avaliar o uso da ferramenta em condies reais de utilizao, portanto essa tarefa fica como sugesto de um trabalho futuro. Inicialmente, a proposta era empregar os dois modelos convencionais de Arduino, Uno e Mega. Porm, durante o desenvolvimento, foi identificado que a limitao de 32KB de memria disponvel no Arduino Uno impediu seu uso na verso final da ferramenta. Apesar do custo maior do modelo Mega em relao ao modelo Uno, a diferena compensada pela maior capacidade de memria e quantidade de portas do modelo Mega, que consequentemente permite adicionar uma maior quantidade de sensores. Em relao estabilidade do firmware, foi identificado um problema na biblioteca de Strings, que acabava congelando o processamento do Arduino. Aps pesquisas feitas na Internet, foi identificado que o problema havia sido solucionado em uma nova verso da IDE. Como o microcontrolador Atmel possui o recurso Watchdog, foi inserida no firmware a rotina responsvel por reinicializar o dispositivo automaticamente, caso ocorra o travamento inesperado. Ao avaliar a verso final do trabalho, pode-se concluir que todos os objetivos foram alcanados, baseados na soluo proposta, e novos conhecimentos foram absorvidos. Com o desenvolvimento da ferramenta InoSensor, foi possvel aplicar, na prtica, os principais contedos vistos no curso de Especializao, como ambientes de desenvolvimento de software, padres de projeto, redes de computadores e sistemas distribudos. A verso final da soluo integra quatro linguagens de programao: Java, PHP, JavaScript e C. Essa integrao demonstra que, apesar das particularidades de cada tecnologia, elas podem se complementar, para que a soluo desenvolvida alcance os objetivos desejados.

124 6.1 TRABALHOS FUTUROS A proposta da ferramenta InoSensor pode ser de grande contribuio para solues baseadas em monitoramento de sensores na plataforma Arduino, sem a necessidade de conhecimentos em programao. Como existe a dependncia de um meio fsico para comunicao com o servidor, sugere-se o desenvolvimento de um firmware para comunicao sem fio, atravs do padro XBee, ou at mesmo via GPRS, para o monitoramento em ambientes em que no seja possvel realizar o uso de rede ethernet. Em relao ao comportamento dos sensores, fica como sugesto a aplicao de alguma tcnica de inteligncia artificial para melhorar o gerenciamento e apoio tomada de decises de todo o conjunto, inclusive com o emprego de autmatos para modelar e analisar os estados do sistema. Sugere-se tambm como proposta, a adio de novos sensores e atuadores e a incluso de um relgio de tempo real (RTC) para executar aes ou verificaes de acordo com o tempo. Como o Arduino no possui um relgio interno, o RTC serviria de base para atuar como temporizador, acionador de atuadores e verificador de sensores.

125 REFERNCIAS ALIEVI, C. Automao residencial com utilizao de controlador lgico programvel, 2008. Disponvel em: <http://www.aureside.org.br /temastec/tcc_0410.pdf>. Acesso em: 05 jul. 2013. ARDUINO. Arduino Reference, 2013. Disponvel em: <http://arduino.cc/en/Reference/HomePage>. Acesso em: 13 June 2013. ATMEL. AVR 8-bit and 32-bit Microcontroller, 2013. Disponvel em:<http://www.atmel.com/products/microcontrollers/avr/default.aspx> Acesso em: 10 July 2013. BIONDO, R. Domtica: Sistemas e Aplicabilidade, 2011. Disponvel em: <http://www.tcc.sc.usp.br/tce/disponiveis/18/180450/tce-19102011122815/>. Acesso em: 15 jun. 2013. BOLZANI, C. Desmistificando a Domtica, 2007. Disponvel em: <http://www.bolzani.com.br/artigos/art01_07.pdf>. Acesso em: 05 jul. 2013. BOXALL, J. Arduino Workshop. 1st. ed. California. No Starch Press, 2013. BREAKOUT, Breakout, 2013. Disponvel em: <http://breakoutjs .com/>. Acesso em: 22 ago. 2013. DIAS, C, L. de A.; PIZZOLATO N. D. Domtica: Aplicabilidade e Sistemas de Automao residencial, 2004. Disponvel em: <http://www.essentiaeditora.iff.edu.br/index.php/vertices/article/view/9 8/86>. Acesso em: 10 jun. 2013. GERTZ, E.; JUSTO, P. Environmental Monitoring with Arduino. 1st. ed. California. OReily Media, 2012. GOLDMAN, A.; KON, F. Testes de Software, 2004. Disponvel em: <www.ime.usp.br/~kon/presentations/testes2004.ppt>. Acesso em: 25 out. 2013.

126 HOMEBOT. Arduino Homebot, 2013. Disponvel em: <https://github .com/indyfromoz/Arduino-Homebot/>. Acesso em: 22 ago. 2013. MARGOLIS, M. Arduino Cookbook. 1 st. ed. California. OReily Media, 2011. MARTINS, G. Princpios de Automao Industrial, 2012. Disponvel em: <www.ufsm.br/desp/geomar/automacao/Apostila_032012.pdf>. Acesso em: 15 jun. 2013. NODUINO. Noduino, 2013. Disponvel em: <http://semu.github.io/nod uino/>. Acesso: 22 ago. 2013. PINHEIRO, J. Sistema de Automao, 2004. Disponvel em: <http://www.projetoderedes.com.br/artigos/artigo_sistemas_automacao. php>. Acesso em: 07 jul. 2013. PINHEIRO, J., Automao e controle de processos, 2013. Disponvel em: <http://www.projetoderedes.com.br/aulas/unifoa_automacao_contro le_processos/aula02_unifoa_automacao_controle_processos.pdf>. Acesso em: 02 jul. 2013. PRADO, S. Barramento I2C, 2007. Disponvel em: <http://www.embarcados.com.br/Artigos/Hardware-Embarcado/Barram ento-I2C.html>. Acesso em: 20 jul. 2013. ROSARIO, J. Automao Industrial. 1. ed. So Paulo. Editora Barana, 2009. SALLES, T. Projeto do Controle de Varredura Automtica do Tanque Acstico, 2009. Disponvel em: <http://www.tcc.sc.usp.br/tce/disponiveis/18/180500/tce-20042010-135 025/publico/Salles_Tito_Pagoto.pdf>. Acesso em: 01 jul. 2013. SCHNEIDER ELECTRIC. Automao residencial IHC, 2013. Disponvel em: <http://www.schneider-electric.com.br/documents/electr icians/manual-residencial.pdf>. Acesso em: 20 jul. 2013. SEABRA, R. M. S. O que Software Livre, 2007. Disponvel em: <http://ansol.org/filosofia>. Acesso em: 20 ago. 2013.

127 SGARBI, J. A.; TONINANDEL, F. Domtica Inteligente: Automao residencial baseada em Comportamento, 2006. Disponvel em: <http://fei.edu.br/~flaviot/pub_arquivos/wtdia06.pdf>. Acesso em: 10 jun. 2013. SOARES, M. Os microcontroladores AVR Atmel - Noes Bsicas, 1998. Disponvel em: <http://www.arnerobotics.com.br/eletronica/Micr ocontroladores_AVR_basico.htm>. Acesso em: 15 jul. 2013. SOUSA, A. Um sistema de apoio tomada de deciso para o monitoramento remoto de centrais de alarmes patrimoniais, 2009. Disponvel em: <http://www.tede.udesc.br/tde_busca/arquivo.php?codA rquivo=2943>. Acesso em: 20 mar. 2013. TERUEL, E. Uma proposta de framework para sistemas de Automao residencial com interface Web, 2008. Disponvel em: <http://www.centropaulasouza.sp.gov.br/posgraduacao/Trabalhos/Disse rtacoes/evandro-carlos-teruel.pdf>. Acesso em: 15 jul. 2013. TORRONE, P. Why the Arduino won and why its here to stay, 2011. Disponvel em: <http://makezine.com/2011/05/12/why-googlechoosing-arduino-matters-and-the-end-of-made-for-ipod-tm/>. Acesso em: 11 June 2013. WENDLING, M. Sensores. Disponvel em: <http://www2.feg.unesp.br/ Home/PaginasPessoais/ProfMarceloWendling/4---sensores-v2.0.pdf>. Acesso em: 01 jul. 2013. WHEAT, D. Arduino Internals. 1st. ed. New York. Apress, 2011. WIRING. Wiring, 2013. Disponvel em: <http://wiring.org.co/about.ht ml>. Acesso em: 25 July 2013. WOLLZ, F. Estratgias para Otimizao da Iluminao e Reduo do Consumo Energtico em Edifcios Residenciais, 2012. Disponvel em: <http://www.ipog.edu.br/uploads/arquivos/bdeddbda29d57021a03d bc9cb249abe7.pdf >. Acesso em: 07 jul. 2013.

128 APNDICE A Dicionrio de dados O dicionrio de dados apresenta a relao de todas as entidades do banco de dados do servidor InoSensor. ENTIDADE CONFIG_EMAIL Esta entidade responsvel por armazenar as configuraes utilizadas para conexo com a conta responsvel por enviar os e-mails de notificao. Atributo id servidor_email porta_email usuario_email senha_email autenticacao Definio do atributo Identificador nico para configurao. Endereo do servidor de e-mail. Porta do servidor de e-mail. Usurio da conta de e-mail. Senha da conta de e-mail. Informa se o servidor de e-mail requere autenticao. Os valores possveis so: S Sim N No char(1) Tipo Dado int varchar(45) int varchar(50) varchar(50)

129 ENTIDADE CONFIG_SERVIDOR Esta entidade responsvel por armazenar as configuraes de rede utilizadas para permitir ao Arduino realizar a comunicao com o Servidor. Atributo id servidor mascara_rede Definio do atributo Identificador nico para configurao. Endereo IP do servidor InoSensor. Mscara de rede do Servidor InoSensor. gateway Gateway da rede do Servidor InoSensor. porta_gateway Porta do Gateway da rede do Servidor InoSensor. tema Define o tema visual utilizado pela aplicao Web. Os valores possveis so: Neptune Classic Gray Accessibility varchar(20) Tipo Dado int varchar(20) varchar(20)

varchar(50)

int

130 ENTIDADE USUARIO Esta entidade responsvel por armazenar os usurios com acesso ao sistema. Atributo id nome email usuario senha ativo Definio do atributo Identificador nico para usurio. Nome do usurio. E-mail do usurio Identificador do usurio. Senha do usurio. Define se o usurio est ativo. Os valores possveis so: S Ativo N No Ativo char(1) Tipo Dado int varchar(45) varchar(45) varchar(45) varchar(45)

131 ENTIDADE MODELO_ARDUINO Esta entidade responsvel por armazenar os modelos de Arduino disponveis na ferramenta InoSensor. Um modelo pode estar relacionado a um Arduino e s portas que compem o Arduino. Atributo id Definio do atributo Identificador nico para modelo de Arduino. modelo ativo Nome do modelo do Arduino. Define se o modelo est ativo. Os valores possveis so: S Ativo N No Ativo char(1) Tipo Dado int varchar(50)

ENTIDADE FIRMWARE Esta entidade responsvel por armazenar as verses de firmware de um Arduino. Um firmware relacionado a um modelo de Arduino. Atributo id versao fonte Definio do atributo Identificador nico do firmware. Descrio da verso do firmware. Armazena o cdigo fonte do firmware. modelo_arduino_id Identificador de um modelo de Arduino. data Data de criao do firmware. Tipo Dado int varchar(5) text

int datetime

132 ENTIDADE TIPO_PORTA Esta entidade responsvel por armazenar os tipos de portas existentes no Arduino. Um tipo de porta relacionado s portas de cada modelo de Arduino e s portas utilizadas por cada tipo de sensor. Atributo id Definio do atributo Identificador nico para tipo de porta de Arduino. nome porta_pwm Nome do tipo de porta do Arduino. Define se a porta possui a funo PWM. Os valores possveis so: S Possui PWM N No possui PWM tipo Define se a porta digital ou analgica. Os valores possveis so: A Analgica D Digital char(1) char(1) Tipo Dado int varchar(50)

133 ENTIDADE TIPO_ACAO Esta entidade responsvel por armazenar os tipos aes para serem executadas pelo Arduino. Um tipo de ao relacionado ao de um sensor de um Arduino. Atributo id nome descricao classe Definio do atributo Identificador nico do tipo de ao Nome do tipo de ao. Descrio detalhada da ao. Nome da classe JavaScript para carregamento dinmico durante a incluso de uma ao. varchar(100) Tipo Dado Int varchar(45) Text

ENTIDADE PORTA_ARDUINO Esta entidade responsvel por definir as portas existentes em cada Arduino de acordo com o modelo. Uma porta do Arduino pode ser relacionada a um sensor conectado em um Arduino. Atributo id Definio do atributo Identificador nico de uma porta de Arduino. modelo_arduino_id Identificador de um modelo de Arduino. id_porta num_porta Identificador da porta do Arduino. Nmero real da porta do microcontrolador. tipo_porta_id Identificador do tipo de porta. Tipo Dado int

int varchar(5) int int

134 ENTIDADE SENSOR Esta entidade responsvel por definir os tipos de sensores e atuadores existentes e suportados pela ferramenta InoSensor. Um tipo de sensor relacionado a um sensor conectado em um Arduino e s portas utilizadas por cada tipo de sensor. Atributo id Definio do atributo Identificador nico de um tipo de sensor/atuador. nome descricao imagem tipo_sensor Nome do tipo de sensor. Descrio detalhada do tipo de sensor. Endereo da imagem do tipo de sensor. Identificador do tipo de sensor. Os valores possveis so: E Entrada (Sensor) S Sada (Atuador) classe Nome da classe JavaScript para carregamento dinmico da condio de acordo com o tipo de sensor durante a incluso de um sensor. caracteristicas Caractersticas das portas utilizadas por cada tipo de sensor. codigo Identificador para o tipo de sensor, utilizado internamento no firmware do Arduino e no arquivo de configurao. Os valores possveis so: rele - Rele temp Sensor Temperatura varchar(10) Text varchar(50) char(1) Tipo Dado Int varchar(45) varchar(5) varchar(45)

135 foto - Fotoresistor fogo Sensor Fogo vibr Sensor Vibrao magn Sensor Magntico rgb LED RGB buzz - Buzzer gend Sensor Genrico Porta Digital pres Sensor de Presena

ENTIDADE PORTA_SENSOR Esta entidade responsvel por definir os tipos de portas e as respectivas quantidades utilizadas por cada tipo de sensor. Um sensor pode ter uma ou vrias portas. Atributo Definio do atributo Tipo Dado sensor_id tipo_porta_id qt_porta_id Identificador para tipo de sensor. Identificador do tipo de porta. Quantidade de portas utilizadas. int int int

136 ENTIDADE ARDUINO Esta entidade responsvel por armazenar os Arduinos que sero controlados pela ferramenta InoSensor. Um Arduino deve ser relacionado a um modelo de Arduino e pode ter vrios sensores. Atributo id Definio do atributo Identificador nico para o Arduino. modelo_arduino_id Identificador de um modelo de Arduino. descricao usuario Descrio do Arduino. Usurio gravado no firmware, utilizado para autenticao durante a gravao e leitura de novas configuraes. Senha Senha gravado no firmware para autenticao. ip mascara_rede mac_address ativo IP do Arduino na rede. Mscara de rede do Arduino. MAC Address do Arduino. Identificador de status do Arduino no sistema. Os valores possveis so: S Sim N No sincronizado Informar se as ltimas configuraes foram enviadas char(1) char(1) varchar(50) varchar(50) varchar(50) varchar(50) varchar(50) Tipo Dado Int

Int varchar(100)

137 para o dispositivo. Os valores possveis so: S Sim N No gateway porta_gateway Gateway da rede do Arduino. Porta do Gateway da rede do Arduino. varchar(50) int

ENTIDADE SENSOR_ARDUINO Esta entidade responsvel por definir os sensores conectados ao Arduino. Atributo id Definio do atributo Identificador nico do sensor do Arduino. sensor_id arduino_id descricao estado_inicial Identificador para tipo de sensor. Identificador do Arduino. Descrio do sensor. Estado inicial do Sensor para informar se est ligado ou desligado. Os valores possveis so: S Sim N No char(1) int int varchar(100) Tipo Dado int

138 ENTIDADE SENSOR_ARDUINO_PORTA Esta entidade responsvel por definir as portas utilizadas por cada sensor conectado a um Arduino. Um sensor de um Arduino deve estar conectado a uma ou mais portas. Atributo Definio do atributo Tipo Dado porta_arduino_id Identificador de uma porta de um tipo de Arduino. sensor_id Identificador de um sensor de um Arduino. ordem Ordem de conexo da porta. int int int

139 ENTIDADE ACAO_SENSOR_ARDUINO Esta entidade responsvel por definir as aes para cada sensor de um Arduino. Uma ao relacionada a um tipo de ao e a um sensor de um Arduino. Atributo id Definio do atributo Identificador nico de uma ao de um sensor. sensor_arduino_id Identificador de um sensor de um Arduino. tipo_acao_id descricao acao[1-5] Identificador do tipo de ao. Descrio da ao. Campo flex para armazenar detalhes da acao executada. condicao[1-9] Campo flex para armazenar detalhes da condio da ao. notificar_servidor Identificador para informar se o servidor ser notificado da ocorrncia do evento. Os valores possveis so: S Sim N No int int varchar(50) varchar(45) Tipo Dado int

varchar(45)

140 ENTIDADE NOTIFICACAO Esta entidade responsvel por armazenar as notificaes enviadas pelos sensores de um Arduino. Uma notificao relacionada a um sensor de um Arduino. Atributo id Definio do atributo Identificador nico da notificao. acao_sensor_arduino_id Identificador da ao relacionada a notificao dt_notificacao Data e hora em que o servidor foi notificado. mensagem verificada Mensagem da notificao. Identificador se a notificao j foi exibida no painel. Os valores possveis so: S Sim N No char(1) int Tipo Dado int

timestamp text

141 ENTIDADE EMAIL Esta entidade responsvel por armazenar as solicitaes de envio de e-mail enviadas pelo Arduino, na ocorrncia de um evento. Um e-mail associado a uma ao de um Arduino. Atributo id Definio do atributo Identificador nico de envio de e-mail. acao_sensor_arduino_id Identificador da ao relacionada a notificao dt_notificacao Data e hora em que o servidor foi notificado. destinatario E-mail do destinatrio da mensagem assunto Assunto da mensagem de email mensagem Mensagem do corpo do email. int Tipo Dado int

timestamp

varchar(45)

Varchar(200)

text