Um dos pontos mais importantes de uma arquitetura de hardware ´e a comunicac¸˜ao en- tre os dispositivos. Cada componente precisa ser compat´ıvel com o protocolo dos dados que transitam nos barramentos para que possam distribu´ı-los de uma forma r´apida e otimi- zada. Para isso, alguns protocolos de comunicac¸˜ao bem definidos j´a s˜ao utilizados, como ´e o caso do I2C, SPI, UART, etc. Cada protocolo apresenta caracter´ısticas peculiares que apresentam vantagens e desvantagens em sua utilizac¸˜ao.
2.5. COMUNICAC¸ ˜AO 13
Como abordado anteriormente, os EZOTMs suportam a comunicac¸˜ao UART e I2C. Como ´e necess´ario receber dados de v´arios sensores diferentes, tudo gerenciado pelo computador de processamento, o protocolo I2C se apresenta como melhor alternativa para utilizac¸˜ao neste projeto.
Al´em dos dois protocolos citados, o Socket tamb´em ´e utilizado na comunicac¸˜ao entre o processo principal do sistema e o servidor.
2.5.1
Protocolo SPI
A comunicac¸˜ao SPI (Serial Peripheral Interface) [Leens 2009] utiliza o princ´ıpio de mestre e escravo. O mestre coordena e tem o controle total dessa comunicac¸˜ao, enviando e recebendo dados dos escravos, atrav´es de requisic¸˜oes diretas. A figura 2.5 mostra um diagrama de blocos de funcionamento desse protocolo.
Figura 2.5: Arquitetura do protocolo de comunicac¸˜ao SPI.
Para o seu funcionamento s˜ao utilizados quatro pinos digitais: Tabela 2.3: Pinos da comunicac¸˜ao SPI.
Pino Descric¸˜ao
SCLK Clock
MISO Master In Slave Out
MOSI Master Out Slave In
SS Slave Selected.
Os pinos MISO e MOSI enviam e recebem os dados, o clock sincroniza a comunicac¸˜ao e o pino SS ´e utilizado pelo mestre para selecionar com qual escravo ele pretende fazer a troca de mensagens.
Neste projeto, a comunicac¸˜ao com os sensores anal´ogicos ´e feita utilizando o proto- colo SPI.
2.5.2
Protocolo I
2C
O protocolo de comunicac¸˜ao I2C (Inter-Integrated Circuit) [Leens 2009], desenvol- vido pela Philips, assim como o protocolo SPI, tamb´em funciona sobre o modelo de mestre e escravo. Por´em, este protocolo s´o necessita de duas linhas bidirecionais: a linha de dados (SDA) e a linha serial de clock (SCL) com resistores pull-up, como mostrado na figura 2.6.
Figura 2.6: Arquitetura do protocolo de comunicac¸˜ao I2C.
Para a comunicac¸˜ao iniciar, o mestre precisa gerar o clock e comunicar com o es- cravo, enviando um bit inicial, seguido de um enderec¸o de 7-bits, que corresponde a qual escravo o mestre precisa enviar a mensagem. O escravo que recebe a mensagem retorna a solicitac¸˜ao para o mestre.
Algumas operac¸˜oes de baixo n´ıvel, como o formato do sinal que ´e enviado na comunicac¸˜ao, tanto SPI quanto I2C, foram omitidos deste trabalho. Dado que, neste trabalho, s˜ao utili- zadas bibliotecas que gerenciam essa comunicac¸˜ao em alto n´ıvel, esses detalhes n˜ao pre- cisam ser estudados com ˆenfase. Para este trabalho, ser´a utilizada a biblioteca de c´odigo aberto WiringPi [Library WiringPi 2015], feita de modo a facilitar as comunicac¸˜oes com o computador de processamento sobre v´arios protocolos, entre eles os dois apresentados anteriormente. Al´em dessa biblioteca, implementac¸˜oes diretas na biblioteca spidev do kernel do linux tamb´em ´e utilizada, dada a necessidade de adaptar algumas mensagens para utilizac¸˜ao dos EZOs.
A grande vantagem na utilizac¸˜ao deste protocolo ´e a facilidade de inserc¸˜ao de novos componentes. Por exemplo, caso deseje-se adicionar um novo sensor da Atlas Scientfic, basta adiciona-lo aos barramentos SDA e SCL e atruibuir-lhe um enderec¸o.
2.6. INTERFACE WEB 15
2.5.3
Comunicac¸˜ao Socket
A interface Socket surgiu no in´ıcio de 1980 na Universidade de Berkeley como parte de um ambiente UNIX [Forouzan & Mosharraf 2013]. Consiste em um mecanismo de comunicac¸˜ao, usado normalmente para implementar um modelo cliente/servidor, que per- mite a troca de mensagens entre os processos de uma m´aquina/aplicac¸˜ao servidor e de uma m´aquina/aplicac¸˜ao cliente.
Como uma arquitetura de rede de computadores est´a fora do escopo deste trabalho, basta entender que, basicamente, a comunicac¸˜ao via socket acontece da seguinte forma:
1. O servidor espera por conex˜ao dos clientes;
2. O cliente estabelece conex˜ao com o servidor, conectando-se a um porta da m´aquina em que este est´a sendo executado;
3. O servidor aceita a conex˜ao e aguarda por requisic¸˜oes; 4. O cliente solicita dados ao servidor;
5. O servidor responde a solicitac¸˜ao do cliente;
6. O servidor aguarda nova requisic¸˜ao ou o cliente/servidor fecha a comunicac¸˜ao.
Utilizando este mecanismo de comunicac¸˜ao, ´e simples enviar e receber dados de m´aquinas/processos separados do sistema. Com isso, o sistema se torna escalon´avel `a criac¸˜ao de novos m´odulos externos.
2.6
Interface Web
Depois que os dados s˜ao adquiridos pelos sensores e pr´e-processados, eles s˜ao dis- ponibilizados `as comunidades de usu´arios por meio da rede mundial de computadores, a Internet. Esse processo se utiliza de algumas ferramentas e linguagens necess´arias para a criac¸˜ao do servidor de dados e da tela de interac¸˜ao com o usu´ario.
2.6.1
Servlet
A tecnologia Servlet Java fornece um paradigma baseado em solicitac¸˜oes e respostas HTTP em servidores web [Qian et al. 2010]. Basicamente, os Servlets podem lidar com solicitac¸˜oes gen´ericas de servic¸os e respondem `as solicitac¸˜oes de um cliente. A figura 2.7 mostra o funcionamento b´asico de um servlet Java.
Percebe-se, pela figura 2.7, a utilizac¸˜ao de mais uma tecnologia ligada ao funciona- mento de um servlet Java: o JSP - Java Server Page. O JSP ´e uma tecnologia que permite
Figura 2.7: Funcionamento B´asico de um Servlet.
ao desenvolver Web gerar p´aginas est´aticas e dinˆamicas com c´odigos Java adicional em- butidos.
Este projeto utilizou-se dessas ferramentas para a criac¸˜ao do servidor web e de uma p´agina dinˆamica, acess´ıvel pelo usu´ario, para a visualizac¸˜ao dos dados dos sensores e aquisic¸˜ao de dados armazenados em banco de dados.
2.6.2
AJAX
Com a utilizac¸˜ao do servlet, mostrado anteriormente, ´e poss´ıvel criar p´aginas de acesso dinˆamico para o usu´ario. No caso do sistema proposto, essa p´agina fornece gr´aficos, com atualizac¸˜ao em tempo real, dos dados adquiridos pelos sensores. Para que o sistema funcione como desejado, uma ferramenta adicional foi utilizada: o Ajax.
O Ajax ´e acrˆonimo para Asynchronous JavaScript and XML e consiste em um grupo de pad˜ores e t´ecnicas que permitem aos aplicativos no ambiente do cliente repassar dados para aplicativos no ambiente do servidor sem necessitar de atualizac¸˜ao ou recarregamento da p´agina [Rutter 2009]. Para isso, o Ajax cria um fluxo de dados em segundo plano, sem interrupc¸˜ao, por isso o termo ass´ıncrono.
Como os gr´aficos da aplicac¸˜ao do cliente do sistema proposto precisam se atualizar automaticamente, sem a necessidade de recarregamento da p´agina, e, al´em disso, rece- ber os dados do servidor de forma autom´atica, o Ajax se encaixa como uma ferramenta primordial para o funcionamento do sistema.
2.7. BANCO DE DADOS: MYSQL COMO FERRAMENTA DE PERSIST ˆENCIA 17
2.7
Banco de Dados: MySQL como Ferramenta de Per-
sistˆencia
Dada a importˆancia do armazenamento dos dados dos sensores para poss´ıveis an´alises posteriores ou at´e para garantir a aquisic¸˜ao dos dados mesmo que seja perdida a comunicac¸˜ao com o servidor, um m´odulo de persistˆencia foi inserido ao sistema. Esse m´odulo utiliza-se da tecnologia MySQL.
O MySQL ´e um sistema de gerenciamento de banco de dados relacional de c´odigo aberto que utiliza a linguagem SQL (Structure Query Language - Linguagem de consulta estruturada) que ´e a linguagem mais utilizada para inserc¸˜ao, acesso e gerenciamento de dados armazenados em um banco de dados. Atrav´es de acessos e consultas ao banco, ´e poss´ıvel armazenar dados e, posteriormente, acess´a-los de forma simples.
2.8
Multiprogramac¸˜ao
O conceito de multiprogramac¸˜ao ´e importante para o desenvolvimento deste sistema, dado que este se apresenta como uma aplicac¸˜ao com v´arias tarefas simultˆaneas. Para tal, ´e necess´ario utilizar bem os rescursos dispon´ıveis pelo computador embarcado e, com isso, garantir a transmiss˜ao de dados de uma forma r´apida e sem perdas de desempenho. Neste sentido, utiliza-se o conceito de threads para melhor utilizac¸˜ao desses recursos.
O conceito de threads est´a associado diretamente aos processos de m´ultiplos fluxos, onde, a partir da utilizac¸˜ao das threads, diminui-se o overhead de gerˆencia e de mudanc¸a de contexto. Dessa forma, um ´unico processo pode ser executado utlizando v´arias threads de modo a paralelizar o funcionamento do algoritmo.
Todas as tecnologias, conceitos e ferramentas apresentados neste cap´ıtulo foram uti- lizados para a construc¸˜ao do sistema proposto de forma a garantir todos os pontos ne- cess´arios para o seu funcionamento.
Cap´ıtulo 3
Estado da Arte
Alguns projetos de monitoramento da qualidade da ´agua e de veleiros rob´oticos autˆonomos s˜ao apresentados a seguir de uma forma resumida, apenas para o conhecimento do leitor. Estes projetos serviram como base e como meio comparativo para o sistema proposto.