INSTITUTO FEDERAL DO ESPÍRITO SANTO
PÓS-GRADUAÇÃO LATO SENSU EM ENGENHARIA ELÉTRICA COM ÊNFASE
EM SISTEMAS INTELIGENTES APLICADOS À AUTOMAÇÃO
GABRIEL LORENZONI BENZ
SISTEMA MULTIPLATAFORMA DE AQUISIÇÃO DE DADOS
VITÓRIA
2015
GABRIEL LORENZONI BENZ
SISTEMA MULTIPLATAFORMA DE AQUISIÇÃO DE DADOS
Monografia apresentada ao Curso de PósGraduação Lato Sensu em Engenharia Elétrica
com Ênfase em Sistemas Inteligentes Aplicados à
Automação do Instituto Federal do Espírito Santo
como requisito parcial para obtenção do
certificado
de
Especialista
em
Sistemas
Inteligentes Aplicados à Automação.
Orientador: Prof. Me. Marcelo Brunoro
VITÓRIA
2015
(Biblioteca Nilo Peçanha do Instituto Federal do Espírito Santo)
B471s Benz, Gabriel Lorenzoni.
Sistema multiplataforma de aquisição de dados / Gabriel
Lorenzoni benz. – 2015.
65 f. : il. ; 30 cm
Orientador: Marcelo Brunoro.
Monografia (especialização) – Instituto Federal do Espírito
Santo, Coordenadoria de Pós-Graduação em Engenharia Elétrica,
Curso Pós-Graduação Lato Sensu em Engenharia Elétrica com
Ênfase em Sistemas Inteligentes Aplicados à Automação, 2015.
1. Engenharia elétrica. 2. Sistemas embarcados
(Computadores). 3. Integração de aplicações corporativas (Sistemas
de computação). 4. Engenharia de Sistemas. I. Brunoro, Marcelo. II.
Instituto Federal do Espírito Santo. III. Título.
CDD 21 – 621.3
GABRIEL LORENZONI BENZ
SISTEMA MULTIPLATAFORMA DE AQUISIÇÃO DE DADOS
Monografia apresentada ao Curso de PósGraduação Lato Sensu em Engenharia Elétrica
com Ênfase em Sistemas Inteligentes Aplicados à
Automação do Instituto Federal do Espírito Santo
como requisito parcial para obtenção do
certificado
de
Especialista
em
Sistemas
Inteligentes Aplicados à Automação.
Aprovada em 16 de março de 2015
COMISSÃO EXAMINADORA DECLARAÇÃO DO AUTOR
Declaro, para fins de pesquisa acadêmica, didática e técnico-científica, que este
Trabalho de Conclusão de Curso pode ser parcialmente utilizado, desde que se faça
referência à fonte e ao autor.
Vitória, 16 de março de 2015
Dedico a minha família e ao meu avô Roberto, por não terem medido esforços para
que eu concluísse mais esta etapa e por serem fiéis incentivadores da minha eterna
busca por conhecimento.
RESUMO O aumento do número de dispositivos com capacidade de se conectar à Internet
contribui para uma rede de comunicação de dados cada vez mais difusa e
heterogênea. Dessa forma, prover uma comunicação confiável entre dispositivos
cada vez mais distintos em arquitetura e em recursos computacionais se torna uma
tarefa complexa. O objetivo deste trabalho é, portanto, propor uma forma de
comunicação entre sistemas heterogêneos, estruturando um sistema multiplataforma
de aquisição de dados, que coleta e transmite informações para um sistema de
interface web remoto, onde os dados podem ser analisados e monitorados. Para
isso, o sistema é composto por um Middleware Orientado a Mensagens, que é
projetado para suportar uma vasta gama de protocolos, ser utilizável em uma ampla
variedade de servidores de aplicação e possuir clientes em diferentes linguagens de
programação, possibilitando o sistema de aquisição de dados a enviar informações
para o sistema de monitoramento de diferentes formas, de acordo com sua
capacidade e interoperabilidade.
Palavras Chave: Internet das coisas. Sistemas embarcados. Integração de sistemas.
Middleware orientado a mensagens.
ABSTRACT
The increasing number of internet-capable devices contributes to a data
communication network increasingly diffuse and heterogeneous. Thus, to provide a
reliable communication among devices that are distinct in architecture and
computational resources becomes complex over time. Therefore, the purpose of this
paper is to suggest a configuration of communication among heterogeneous devices
and systems, by structuring a multi platform data acquisition system, which collects
and transmits data to a remote web application, where the data can be analyzed and
monitored. To perform this, it's used a message-oriented middleware, designed to
support a large number of Cross Language Clients, to speak a wide range of
Protocols and to be usable in a wide variety of Containers, allowing the acquisition
system to send information to the monitoring system in different ways, according to
their capacity and interoperability.
Keywords: Internet of Things. Embedded Systems. Message Oriented Middleware.
LISTA DE FIGURAS
Figura 1 - Modelo de comunicação com M.O.M. ...................................................... 11
Figura 2 - Sistema de Baixo Custo para Termometria de Grãos. ............................. 14
Figura 3 - Sistema Web de Monitoração de Dados .................................................. 14
Figura 4 - Sistema com utilização de Computação nas Nuvens ............................... 15
Figura 5 - Modelo de Comunicação Síncrona ........................................................... 18
Figura 6 - Modelo de Comunicação Assíncrona ....................................................... 19
Figura 7 - Acoplamento do MOM com aplicações .................................................... 23
Figura 8 - Fila de Mensagens com produtores e consumidores ............................... 24
Figura 9 - Fluxograma do Sistema ............................................................................ 28
Figura 10 - Sistema de Aquisição de Dados - Beaglebone....................................... 30
Figura 11 - Diagrama de Circuitos ............................................................................ 30
Figura 12 - Console de Administração do ActiveMQ ................................................ 32
Figura 13 - Diagrama de blocos ................................................................................ 34
Figura 14 - Log do Sistema de Aquisição na Beaglebone ........................................ 38
Figura 15 - Lista de tópicos do ActiveMQ - dl.topic.data ........................................... 39
Figura 16 - Lista de filas do ActiveMQ - dl.newData.queue ...................................... 39
Figura 17 - Organização dos projetos ....................................................................... 41
Figura 18 - Dashboard do Sistema de Monitoramento ............................................. 42
Figura 19 - Página de Listagem de Data (informação) ............................................. 43
Figura 20 - Página Real Time com informações dos últimos 5 minutos ................... 43
Figura 21 - Página de Listagem de Devices (dispositivos) ....................................... 44
Figura 22 - Página de Formulário de Device (dispositivo) ........................................ 44
Figura 23 - Página de Listagem de Setpoints ........................................................... 45
Figura 24 - Página de Formulário de Setpoints......................................................... 45
Figura 25 - Página de Notifications (notificações) ..................................................... 46
Figura 26 - Console de Administração - Amazon EC2.............................................. 47
SUMÁRIO
1
INTRODUÇÃO ............................................................................................... 9
1.1
OBJETIVO GERAL ....................................................................................... 10
1.2
ORGANIZAÇÃO DO TRABALHO ................................................................ 12
2
REFERENCIAL TEÓRICO ........................................................................... 13
2.1
TRABALHOS CORRELATOS ...................................................................... 13
2.2
FUNDAMENTAÇÃO TEÓRICA .................................................................... 15
2.2.1
Data Logger ................................................................................................. 16
2.2.2
Aplicações Web .......................................................................................... 17
2.2.3
Modelos de Comunicação ......................................................................... 17
2.2.3.1 Comunicação Síncrona ................................................................................ 18
2.2.3.2 Comunicação Assíncrona ............................................................................. 18
2.2.4
Middleware e a Integração de Sistemas ................................................... 20
2.2.5
Middleware orientado a mensagens ......................................................... 21
2.2.6
Gerenciadores de Fila de Mensagens ...................................................... 23
2.2.7
JMS – Java Message Service .................................................................... 25
2.2.7.1 Topic – tópicos ............................................................................................. 25
2.2.7.2 Queues – filas ............................................................................................... 26
3
METODOLOGIA .......................................................................................... 27
3.1
SISTEMA DE AQUISIÇÃO DE DADOS ....................................................... 28
3.2
SISTEMA GERENCIADOR DE MENSAGENS ............................................ 31
3.3
SISTEMA DE MONITORAMENTO DE DADOS ........................................... 32
3.4
PUBLICAÇÃO NA NUVEM .......................................................................... 35
4
IMPLEMENTAÇÃO E RESULTADOS ......................................................... 36
4.1
SISTEMA DE AQUISIÇÃO DE DADOS ....................................................... 36
4.2
SISTEMA DE GERENCIAMENTO DE MENSAGENS ................................. 38
4.3
SISTEMA DE MONITORAMENTO .............................................................. 40
4.4
PUBLICAÇÃO NA NUVEM .......................................................................... 50
5
CONCLUSÕES E TRABALHOS FUTUROS ............................................... 49
REFERÊNCIAS ............................................................................................ 53
APÊNDICE A - Código do Sistema de Aquisição de Dados (Beaglebone White) .... 56
APÊNDICE B - Código e configuração do ActiveMQ ................................................ 63
9 1 INTRODUÇÃO
A inserção de dispositivos computacionais inteligentes no mercado e no cotidiano
das pessoas é um fato inquestionável. Pesquisas evidenciam que o número de
dispositivos capazes de se conectar à Internet é cada vez maior.
Stamford (2013) cita um estudo feito pela empresa de consultoria e pesquisa
Gartner Inc., concluindo que essa quantidade de dispositivos com a capacidade de
se conectar à Internet chegará a 26 bilhões em 2020. Outra pesquisa, realizada pela
ABI Research, estima que esse número será ainda maior no mesmo ano, chegando
a expressivos 30 bilhões de dispositivos.
É importante ressaltar que esses dispositivos não são apenas smartphones ou
tablets, mas todo dispositivo capaz de transmitir dados pela rede, desde pequenos
sensores para monitoramento de um ambiente a microcontroladores com
Inteligência Artificial.
Esse aumento do número de dispositivos vinculados à Internet colabora para que
termos como "internet das coisas", "computação ubíqua" e "computação
onipresente" estejam cada vez mais em discussão e presentes em estudos em
diversas áreas, tais como: monitoramento ambiental, apresentado por Li et al.
(2011); operações de monitoramento e controle de infraestruturas, conforme
trabalhos de Gubbi et al. (2013); aplicações industriais, em Severi et al. (2014);
gerenciamento de energia, citado por Ersue et al. (2014); sistemas de assistência
médica, mostrado por Istepanian et al. (2011); automação residencial Alkar, A. Z.;
Buhur, U. (2005).
A Internet das Coisas é, segundo Holler et al. (2014), a interconexão de dispositivos
embarcados unicamente identificáveis dentro da infraestrutura da Internet.
Normalmente, é esperado que a Internet das Coisas ofereça conectividade
avançada entre dispositivos, sistemas e serviços que vão além da comunicação
máquina-a-máquina (M2M - Machine to Machine) e abrange uma variedade de
protocolos, domínios e aplicações.
10 A Internet das Coisas tem como objetivo facilitar a troca de informações sobre entre outros - bens em uma rede de fornecimento global, isto é, a infraestrutura de
tecnologia de informação deveria prover informações sobre essas “coisas” de
maneira segura e confiável (WU et al., 2010).
No entanto, o grande número de dispositivos, dos mais variados tipos, favorece para
que a troca de informações se torne uma tarefa difícil, principalmente em sistemas
heterogêneos, ou seja, quando os dispositivos do sistema são divergentes quanto à
arquitetura (plataforma), sistema operacional, configurações de hardware, fabricante,
entre outras.
Nota-se uma crescente difusão da Internet, que evolui constantemente buscando
acomodar todas as tecnologias de redes emergentes que apresentam novas
características e requisitos. Essas redes emergentes variam desde simples acesso
residencial até controles industriais complexos através da Internet.
Portanto, como prover, nessa rede heterogênea, uma interação eficiente e confiável
entre
dispositivos
cada
vez
mais
distintos
em
arquitetura
e
recursos
computacionais?
Tanenbaum (2002) cita que um recurso bastante utilizado nos dias de hoje está
relacionado às tecnologias para comunicação entre processos e dispositivos através
de troca de mensagens (programação distribuída).
1.1 OBJETIVO GERAL
O objetivo deste trabalho é propor uma forma de comunicação entre sistemas
heterogêneos, estruturando um sistema multiplataforma de aquisição de dados,
responsável por coletar e transmitir informações para um sistema de interface web
remoto, onde os dados podem ser analisados e monitorados.
11 Para isto, foi desenvolvida uma estrutura distribuída, composta por um middleware
responsável por fazer a comunicação entre o sistema de aquisição de dados e o
sistema de monitoramento através de troca de mensagens.
O Middleware Orientado a Mensagens (representado pela sigla M.O.M.) é projetado
para suportar um grande número de clientes implementados em diferentes
linguagens de programação, além de conseguir trabalhar com uma vasta gama de
protocolos e ser utilizável em uma ampla variedade de servidores de aplicação,
possibilitando o sistema de aquisição de dados a enviar informações para o sistema
de monitoramento de formas variadas, de acordo com sua capacidade.
A Figura 1 exibe o modelo de comunicação entre um emissor e um receptor,
simulando uma rede heterogênea, com dispositivos emissores de dados de tipos e
arquiteturas variados, interagindo com um receptor (no caso deste trabalho, um
sistema web, onde os dados serão monitorados) por intermédio de um gerenciador
de fila de mensagens (M.O.M.).
Figura 1 - Modelo de comunicação com M.O.M.
Fonte: Elaborado pelo autor, 2015.
A utilização do Middleware Orientado a Mensagens no modelo de comunicação
proposto permite que os emissores de informação sejam desacoplados do receptor.
Segundo Curry(2005), esse tipo de middleware permite a criação de sistemas
12 coesos e flexíveis; um sistema coeso é aquele que permite que as alterações em
uma parte do sistema seja feita sem comprometer outras partes do sistemas.
1.2 ORGANIZAÇÃO DO TRABALHO
A estrutura deste trabalho apresenta-se com os seguintes capítulos:
•
Capítulo 1, Introdução, que contextualiza o trabalho por meio da explicação
da proposta e motivo de construção de um sistema multiplataforma de
aquisição de dados;
•
Capítulo 2, Referencial Teórico, onde são destacados alguns trabalhos
correlatos, levantando suas limitações e vantagens. Além disso, nesse
capítulo também é feito o estudo de fundamentação teórica, em que são
apresentados conceitos fundamentais para a compreensão do trabalho;
•
Capítulo 3, Metodologia, aborda como o sistema foi separado em etapas, os
métodos de desenvolvimento e os materiais utilizados em cada etapa;
•
Capítulo 4, Implementação e Resultados, contempla todo o desenvolvimento
em cada sistema, como os projetos foram organizados e implementados, as
configurações feitas, os resultados obtidos, as páginas e os logs dos
sistemas desenvolvidos; e
•
Capítulo 5, Conclusões e Trabalhos Futuros, onde são apresentadas as
considerações finais, abordando os aprendizados e deduções obtidas com o
trabalho proposto, bem como sugestões para posteriores evoluções do
sistema.
13 2 REFERENCIAL TEÓRICO
Neste capítulo são apresentados os aspectos teóricos relevantes à elaboração do
presente trabalho.
Este capítulo está dividido em duas partes: na primeira, são analisadas as
características de alguns trabalhos correlatos que serviram de base para a
elaboração do sistema apresentado. Na segunda parte, são apresentados os
conceitos, descrições, esquemas de arquitetura que esclarecem e justificam as
tecnologias computacionais utilizadas.
2.1 TRABALHOS CORRELATOS
Os trabalhos correlatos analisados nesta seção apresentam características
semelhantes: todos possuem um sistema de aquisição de dados (seja preparado
para coletar diferentes informações ou apenas uma informação específica) que
alimenta um sistema (podendo ser remoto ou local) que faz o monitoramento dos
dados coletados.
Cantú, Dyego (2013) e Ferrasa e Mayer (2013) optaram por embarcar todo o data
logger (sistema de aquisição e sistema de monitoramento dos dados) em um único
dispositivo. Os autores fizeram essa opção tendo como principais justificativas o
baixo custo e a facilidade de implementação.
A Figura 2 exibe a estrutura do sistema proposto por Ferrasa e Mayer (2013),
mostrando desde a aquisição dos dados por meio de sensores de temperatura, a
forma de transmissão e recepção dos dados, até o acesso e monitoramento das
informações em um sistema escrito na linguagem de programação Java.
14 Figura 2 - Sistema de Baixo Custo para Termometria de Grãos
Fonte: Ferrasa e Mayer (2013)
Um grande diferencial encontrado nos trabalhos de Inácio et al. (2012), Cantú,
Dyego (2013), Ferrasa e Mayer (2013) foi uso da interface web para exibição das
informações coletadas. Dessa forma, os dados obtidos podem ser acessados em
tempo real a partir de qualquer lugar (e qualquer dispositivo) que acesse a Internet,
o que, segundo os autores, facilita e agiliza a análise dos dados.
A Figura 3 mostra uma das telas do sistema web de monitoramento de dados
proposto por Cantú, Dyego (2013).
Figura 3 - Sistema Web de Monitoração de Dados
Fonte: Cantú (2013)
15 Inácio et al. (2012) ainda fez a opção de publicar os dados coletados na nuvem1, o
que tende a aumentar a disponibilidade do sistema, além de diminuir custos de sua
manutenção, hospedagem e implantação. Para isso, foi feita a utilização do Sistema
web API Cosm, que permite, entre outras coisas, consultar as informações coletadas
em um determinado período de tempo.
A Figura 4 exibe a proposta do sistema elaborado por Inácio et al. (2012), que
possui um gateway que recebe todos os dados coletados em diferentes sistemas de
aquisição e depois os envia para um sistema remoto em que os dados serão
monitorados.
Figura 4 - Sistema com utilização de Computação nas Nuvens
Fonte: Inácio et al. (2012)
2.2 FUNDAMENTAÇÃO TEÓRICA
Para melhor entendimento do problema e de sua solução, é importante familiarizarse com alguns termos e conceitos. Por este motivo, são descritas nesta seção as
1
Segundo Mell, Peter e Grance, Timothy (2011), computação em nuvem (em inglês, cloud
computing), é um modelo para permitir acesso à rede de forma ubíqua, conveniente e sob demanda,
provendo acesso a recursos computacionais configuráveis (por exemplo, redes, servidores,
armazenamento, aplicações e serviços) que podem ser fornecidos e liberados com um esforço
mínimo de gerenciamento ou interação com o provedor de serviços.
16 definições e características das tecnologias que foram utilizadas no presente
trabalho com o intuito de facilitar a comunicação entre dispositivos de diferentes
plataformas e sanear (ou pelo menos, minimizar) alguns dos problemas
evidenciados anteriormente nos trabalhos correlatos.
2.2.1 Data Logger
Em Omega Tech (2009), o termo data logger é definido como:
[...] qualquer dispositivo que pode ser usado para armazenar dados. Isto
inclui muitos dispositivos de aquisição de dados, tais como placas plug-in ou
sistemas de comunicação serial que usam um computador como um
sistema de gravação de dados em tempo real. No entanto, a maioria dos
fabricantes de instrumentos considera um data logger um dispositivo stand
alone, que pode ler vários tipos de sinais elétricos e armazenar os dados na
memória interna para ser carregado mais tarde para um computador. A
vantagem dos Data Loggers é que eles podem funcionar
independentemente de um computador, ao contrário de muitos outros tipos
de dispositivos de aquisição de dados.
No presente trabalho, o termo Data Logger, proveniente do inglês e comumente
utilizado na literatura será substituído, em sua maioria, para seu equivalente em
português: “Sistema de Aquisição de Dados”.
Esses sistemas, segundo Rajmond (2010), têm sido amplamente utilizados, não só
em ambientes eletrônicos, mas em todos os sistemas que se referem à tecnologia.
Mahzan et al. (2013) afirmam que, além de ser um dispositivo cujo o trabalho
principal é armazenamento de dados, ele também tem a capacidade de monitorar
um sistema, isto é, pode gravar todos os dados requeridos pelo usuário e informar
ao usuário, quando necessário, como em uma situação de defeito ou qualquer erro
ocorreu ao sistema. Além disso, têm a capacidade de armazenar todos os dados
armazenados em memória de armazenamento para que o usuário seja capaz de
recuperar estes dados com facilidade a qualquer momento necessário. São
construídos juntando-se o microcontrolador com o armazenamento da memória e
sensor.
17 Conforme Wei et al. (2012), na maioria das vezes, os data loggers são equipados
com um relógio de tempo real para que ele seja capaz de registrar a hora e a data
ao registrar todos os dados.
2.2.2 Aplicações Web
Segundo Cantú, Dyego (2013), os serviços web utilizam a infraestrutura de rede
Internet para disponibilizar acesso à informação e a aplicativos. A arquitetura dos
aplicativos que executam utilizando serviços Internet é denominada cliente/servidor.
Um servidor pode disponibilizar acesso a um aplicativo ou conter páginas
hospedadas de texto a serem exibidas no cliente. O cliente é o aplicativo
denominado navegador para acesso ao conteúdo de páginas web ou para prover
acesso a aplicativos desenvolvidos para execução na Internet.
Cantú, Dyego (2013) ainda afirma que a conexão entre o cliente e o servidor é,
geralmente, realizada pelo protocolo TCP/IP (Transmission Control Protocol/Internet
Protocol), pelo menos nas aplicações denominadas web tradicionais que são as
baseadas em HTML (HyperText Markup Language).
Em termos de serviços, de um lado está o cliente web (browser ou navegador) que
solicita dados ao servidor web, que recebe as respostas, formata a informação e a
apresenta ao usuário; do outro lado está o servidor web que recebe as requisições,
executa as instruções necessárias (podendo, se necessário, buscar informações em
um repositório de dados externo) e retorna os dados para o cliente.
2.2.3 Modelos de Comunicação
Dois modelos de comunicação denominam a forma de interação entre ambientes
computacionais distribuídos: o modelo de comunicação síncrona e o modelo de
comunicação assíncrona.
18 Esta seção introduz conceitos básicos sobre as duas abordagens, explicando suas
características e evidenciando suas vantagens e desvantagens.
2.2.3.1 Comunicação Síncrona
Segundo Curry (2005), quando um procedimento, função ou método é chamado
usando o modelo de interação síncrona, o emissor (ou caller, quem faz a chamada
do procedimento remoto) deve bloquear e esperar (suspender o processamento) até
que o receptor (called, procedimento que é chamado) conclua a execução e retorne
o controle para ela; o código chamador pode então continuar o processamento.
Neste caso, o sistema não tem controle de processamento independente, ou seja, o
sistema precisa confiar no retorno do controle do método chamado para então
continuar o processamento.
Figura 5 - Modelo de Comunicação Síncrona
Fonte: Curry. (2005)
2.2.3.2 Comunicação Assíncrona
19 Curry (2005), afirma que modelo de interação assíncrona, ilustrado na Figura 6,
permite que o emissor (caller) mantenha o controle de processamento. Dessa forma,
o emissor não precisa bloquear e esperar o receptor (called) retornar.
Este modelo permite que o emissor continue o processamento, independentemente
do estado de processamento do procedimento / função / método chamado. Este
modelo de interação requer um intermediário para lidar com a troca de requisições;
normalmente este intermediário é uma fila de mensagens.
Embora mais complexo do que o modelo síncrono, o modelo assíncrono permite
todos os participantes a manter a independência de processamento. Os
participantes podem continuar o processamento, independentemente do estado dos
outros participantes.
Figura 6 - Modelo de Comunicação Assíncrona
Fonte: Curry. (2005)
A natureza assíncrona de comunicação fornece as seguintes vantagens no design2,
implementação e manutenção de um sistema:
(1) flexibilidade, já que a estrutura de comunicação desacopla as aplicações e
as deixa independentes e autônomas, provendo maior flexibilidade ao atualizar e/ou
2
Design de Software, segundo Freeman e Hart (2004), se refere a todas as atividades envolvidas na
conceituação, enquadramento, implementação e modificação de sistemas complexos.
20 integrar outras aplicações com menor efeito colateral no sistema todo ou outros
componentes;
(2) Eficiência, uma vez que o sender pode continuar com seu trabalho
imediatamente depois de enviar a mensagem. Isso é especialmente importante para
operações que levam muito tempo para serem finalizadas;
(3) Robustez, já que o sender pode enviar a mensagem mesmo se o
recebedor não estiver disponível no momento. M.O.M.s podem também fornecer
níveis de tolerância de falhas, usando filas de mensagens persistentes que permitem
que mensagens não enviadas ou não lidas sejam enviadas novamente depois de
falhas do sistema.
2.2.4 Middleware e a Integração de Sistemas
Para Bakken (2001), middleware é:
[...] uma classe de software projetada para ajudar a
gerenciar a complexidade e heterogeneidade inerente a
sistemas distribuídos. Define-se como uma camada de
software acima do sistema operacional, mas abaixo do
programa de aplicação que fornece uma abstração de
programação comum em um sistema distribuído. Isto
reduz significativamente a carga sobre programadores de
aplicativos por aliviá-los desse tipo de programação
tediosa e propensa a erros.
Middleware também são conhecidos como programas intermediadores. Qiyang
(2006) cita que middleware pode ser classificado como sendo de banco de dados,
Remote Procedure Call (RPC), servidor de aplicação, orientado a mensagem
(MOM), Object Request Broker (ORB), monitores de processamento de transações e
Middleware Web.
21 Em Hohpe, Gregor e Woolf, Bobby (2003), a integração enterprise envolve o uso
uma das anteriores tecnologias para conectar díspares e sistemas heterogêneos. A
integração por mensagens é, supostamente, uma das opções mais utilizadas para a
integração, uma vez que pode suportar a operação assíncrona, prover baixo
acoplamento3, facilidade de encaminhamento e suporte a transformação e transação
de mensagem4.
Nos middlewares orientados à mensagem, as aplicações se comunicam entre si
através de um sistema de mensagens que controla a recepção e entrega da
mensagem. Há muitos exemplos de middleware orientado a mensagens
proprietários como IBM MQSeries, MSMQ da Microsoft e Tibco (RAMKUMAR I.;
BALASUNDARAM C., 2012).
Muitas das soluções proprietárias usam protocolos não padronizados e envolvem
custos de licenciamento enormes. Há muitas alternativas de código aberto para a
mensagem middleware orientado como a suíte de produtos Apache (Apache Camel,
Apache ServiceMix, Open ESB, Apache ActiveMQ e Apache CXF), Mule, Spring
Integration e JBoss Enterprise Application Platform. Muitos deles oferecem suporte a
todos os padrões empresariais de integração, bem como fornecem uma linguagem
de domínio específico que pode ser usada para criar endpoints, rotas, filas e regras
de tradução.
2.2.5 Middleware orientado a mensagens
Os sistemas MOM (middleware orientado a mensagens) proporcionam comunicação
distribuída em função do modelo de interação assíncrona.
3
Segundo Eder, Kappel e Schrefl (1992), no desenvolvimento de software, o acoplamento é a medida
das interdependências entre métodos e classes de objetos. O baixo acoplamento leva um programa a
ser mais confiável e de fácil manutenabilidade.
4
Segundo Prakash Malani (2012), na especificação JMS, uma transação organiza e agrupa a
mensagem em uma unidade atômica de processamento.
22 Segundo Curry (2005), este modelo sem bloqueio permite o MOM resolver muitas
das limitações encontradas nos sistemas de comunicação síncrona. Os participantes
de um sistema baseado em MOM não são obrigados a bloquear e esperar uma
mensagem de envio, eles são autorizadas a continuar o processamento, uma vez
que uma mensagem foi enviada. Isto permite a entrega de mensagens quando o
emissor ou receptor não está ativo ou disponível para responder no momento da
execução.
Esse tipo de middleware suporta a entrega de mensagens que pode demorar alguns
minutos para entregar, ao contrário de mecanismos como RPC (RMI) que entregam
em milissegundos ou segundos.
Ao utilizar MOM, um aplicativo de envio não tem qualquer garantia de que sua
mensagem será lida por outro aplicativo nem é dada uma garantia sobre o tempo
que levará a mensagem a ser entregue. Estes aspectos são determinados
principalmente pela aplicação de recepção.
Implementações de sistemas distribuídos baseados em MOM, como mostrado na
Figura 7, oferecem uma abordagem baseada em serviços para comunicação entre
processos.
Segundo Tanenbaum (2002), mensagens MOM são semelhantes ao serviço postal.
As mensagens são entregues aos correios; em seguida, o serviço postal leva
responsabilidade para a entrega segura da mensagem.
As principais vantagens do MOM consistem no baixo acoplamento entre os
sistemas, alta confiabilidade, escalabilidade 5e disponibilidade.
5
Segundo Bondi (2000), escalabilidade é uma característica desejável em todo o sistema, em uma
rede ou em um processo, que indica sua capacidade de manipular uma porção crescente de trabalho
de forma uniforme, ou estar preparado para crescer.
23 Figura 7 - Acoplamento do MOM com aplicações
Fonte: Curry. (2005)
2.2.6 Gerenciadores de Fila de Mensagens
A fila de mensagens é um conceito fundamental dentro MOM, já que elas fornecem
a capacidade de armazenar mensagens em uma plataforma MOM. Dessa forma,
clientes MOM são capazes de enviar e receber mensagens de e para uma fila.
Segundo Curry (2005), a filas são fundamentais para a implementação do modelo de
interação assíncrona dentro do MOM. Uma fila, como mostrado na Figura 8, é um
destino para onde as mensagens podem ser enviadas e recebidas; geralmente, as
mensagens contidas em uma fila são classificadas em uma ordem particular.
A fila padrão encontrada em um sistema de mensagens é (FIFO) First-In First-Out;
como o nome sugere, a primeira mensagem a entrar na fila é a primeira mensagem
a sair (e, por isso, também conhecido como PEPS).
24 Figura 8 - Fila de Mensagens com produtores e consumidores
Fonte: Curry. (2005)
Um gerenciador de filas de mensagem (message broker) é um programa que traduz
mensagens de um protocolo de um remetente (sender) para um recebedor (receiver)
em uma rede, em outras palavras, faz o intermédio da comunicação entre
aplicações.
Segundo Yamamoto (2009), um gerenciador de filas de mensagem pode ser visto
como um conjunto de filas (embora Curry represente apenas um), no qual as
mensagens são armazenadas e enviadas de acordo com a ordem de chegada.
O objetivo desse tipo de ferramenta em um sistema distribuído é realizar o
balanceamento de carga entre os servidores através da gerência dos dados das
filas, ou seja, uma vez que determinada fila estiver cheia devido a uma grande
quantidade de mensagens que estiverem sendo processadas pelo servidor, o broker
pode ser configurado para enviar mensagens para as filas de outro servidor que
dispõe de maior quantidades de recursos ociosos e subutilizados, e com isso,
aproveitar de forma mais eficiente os recursos do ambiente.
O gerenciador de filas utilizado no presente trabalho é o AtiveMQ, uma ferramenta
open source que implementa Serviços de Mensagem Java (Java Message System JMS) permitindo comunicação entre processos com suporte para clientes em várias
linguagens, entre elas Java (HORSTMANN, 2001), C++ (STROUSTRUP, 1993),
Ruby (FLANAGAN, 2008), Python (LUTZ, 2006).
Além disso, o ActiveMQ tem muitas características avançadas, como por exemplo, o
25 suporte a JMS 1.1 e J2EE 1.4, que fornece recursos como agrupamento (clustering)
e armazenamento de múltiplas mensagens.
2.2.7 JMS – Java Message Service
Atualmente, existe uma série de implementações MOM, incluindo ActiveMQ,
RabbitMQ, WebSphere MQ, TIBCO, SonicMQ, Herald, Hermes, Siena, OpenJMS e
etc.
Segundo Curry (2005), para simplificar o desenvolvimento de sistemas utilizando
MOMs, um padrão foi preciso para fornecer uma interface universal para as
interações através de mensagens. Com isso, alguns padrões surgiram, tais como
CORBA Event Service, CORBA Notification Service e a mais importante: Java
Message Service, JMS.
Curry (2005) ainda afirma que o JMS fornece uma forma comum para o
programador criar, enviar, receber e ler mensagens, já que a especificação JMS
provê uma base sólida para a construção de infraestrutura de mensagens que
podem ser aplicadas a uma larga quantidade de aplicações.
A especificação JMS define uma API de proposta geral para serviços de mensagem
e um conjunto de semânticas que descrevem a interface e o comportamento geral
de um serviço de mensagem.
O objetivo da especificação JMS é, portanto, fornecer de uma maneira consistente
um padrão de interagir com múltiplos sistemas de mensagem heterogêneos.
2.2.7.1 Topic – tópicos
Na especificação JMS, um topic (tópico) implementa a semântica de publicação e
assinatura.
26 Quando uma mensagem é publicada, ela é enviada para todos os assinantes que se
inscreveram para receber as mensagens daquele tópico, logo, zero ou muitos
assinantes irão receber uma cópia da mensagem enviada.
Somente os assinantes que tiverem a assinatura no momento em que o broker
recebe a mensagem receberão uma cópia da mensagem.
2.2.7.2 Queues – filas
Uma fila JMS implementa a semântica de balanceamento de carga. Uma mensagem
única será recebida por exatamente um consumidor. Se não houver consumidores
disponíveis no momento em que a mensagem é enviada, ela será mantida na fila até
que um consumidor disponível possa processá-la.
27 3 METODOLOGIA
Para o desenvolvimento do trabalho, optou-se pela implementação de cada
componente do sistema separadamente.
O trabalho foi dividido em 4 etapas, descritos a seguir:
(1) Desenvolvimento do sistema de aquisição de dados: nesta etapa foi
necessário
o
estudo
do
dispositivo
escolhido,
compreender
seu
funcionamento, bem como entender como ocorre sua interface com
periféricos e componentes que fazem a coleta de informações.
Após esse estudo, foi desenvolvido um programa escrito em Java para
coletar informações e enviá-las para o gerenciador de fila de mensagens;
(2) Configuração do gerenciador de fila de mensagens: em que foi feito
um levantamento dos principais brokers do mercado e optou-se pelo uso
do ActiveMQ.
Nesta etapa também foi feita toda a configuração do broker e a definição
dos protocolos de comunicação, que recebem e transportam as
mensagens entre os sistemas;
(3) Desenvolvimento do sistema de monitoramento dos dados: nesta
etapa foi desenvolvido um sistema web para monitoramento dos dados,
com funções para acompanhamento em tempo real e acesso a dados
históricos, que podem ser acessados de qualquer dispositivo com acesso
à Internet; e
(4) Disponibilização do sistema: nesta etapa foi feito um estudo para definir
a
infraestrutura
computacional
em
nuvem
que
seria
utilizada.
Posteriormente, foi feito o deploy (disponibilização) do sistema de
gerenciamento de fila de mensagens e o sistema de monitoramento dos
dados em uma micro instância da Amazon EC2.
A Figura 9 mostra o fluxograma do processo, apresentando desde o seu início,
coleta do dado, a montagem da mensagem e o envio para o gerenciador de filas
(processos realizados pelo sistema de aquisição de dados), até a mensagem chegar
28 ao destino final, que é o sistema de monitoramento, passando antes pelo sistema
gerenciador de fila de mensagens.
Figura 9 - Fluxograma do Sistema
Fonte: Elaborado pelo autor, 2015.
3.1 SISTEMA DE AQUISIÇÃO DE DADOS
O sistema de aquisição de dados tem como responsabilidade fazer a coleta da
informação e manipular essa informação de forma a garantir que ela seja enviada
corretamente para o broker (sistema de gerenciamento de fila de mensagens).
29 O sistema foi escrito utilizando a linguagem de programação Java, em sua versão
JDK 7 64-bit da Oracle e embarcado em uma Beaglebone White, que é baseada no
SoC (System on Chip) AM3359, um ARM Cortex-A8 da Texas Instruments que roda
em até 720MHz e possui 32KiB de cache L1, 256KiB de cache L2, 176KiB de ROM
e 64KiB de SRAM interna, mais 256 MiB de RAM DDR2.
Além disso, a Beaglebone White possui acelerador gráfico 3D, controlador LCD de
24 bits, controlador para a interface touchscreen e já possui em seu SoC um
controlador de ethernet (a nível de hardware), bem como a pilha TCP/IP provida pelo
Sistema Operacional (distribuição Linux, Angstrom) instalado em seu SD Card.
No caso do presente trabalho, são coletados os dados de temperatura (em graus
Celsius) e a intensidade luminosa do ambiente.
A coleta de temperatura foi feita utilizando um Thermistor NTC 10 kΩ (Negative
Temperature Coefficient). Nesse tipo de termistor, por ter o coeficiente de
temperatura negativo, como sugere o nome, sua resistência diminui com o aumento
da temperatura.
Já para coletar os dados de intensidade luminosa, foi utilizado um sensor de luz
baseado em um divisor resistivo entre um LDR e um resistor de 10 kΩ, em que o
primeiro está conectado à 1,8 V e o segundo conectado à referência (GND_ADC).
A Figura 10 mostra o circuito utilizado para coletar as informações de temperatura e
luminosidade na Beaglebone.
30 Figura 10 - Sistema de Aquisição de Dados - Beaglebone
Fonte: Elaborado pelo autor, 2015.
A Figura 11 mostra o diagrama de circuitos para obtenção das informações.
Figura 11 - Diagrama de Circuitos
Fonte: Elaborado pelo autor, 2015.
Na Beaglebone White é possível ler cada uma das 8 entradas analógicas de 12 bits
no subdiretório tsc. No entanto, somente 7 estão disponíveis em seu conector de
expansão.
31 Nessas entradas analógicas, o valor de tensão aplicado deve ser de 0 a 1,8 V,
obtendo um valor convertido para o digital de 0 a 4095, sendo que a entrada ain1 do
Sistema Operacional (e consequentemente, a entrada de leitura do programa em
Java), corresponde à entrada analógica 0 do AM3359 (AIN0 - pino 39, do conector
P9 da Beaglebone). A mesma lógica se aplica às demais entradas.
Portanto, a implementação do programa consiste na leitura da informação analógica
convertida para o valor digital. Após a coleta da informação, o valor é adequado para
a unidade de medida escolhida (no caso da temperatura, usou-se “Celsius” e no
caso da intensidade luminosa, adotou-se o valor digital coletado), a mensagem é
estruturada e então enviada para o broker.
Após a estruturação da mensagem, foi construída a lógica de transmissão da
mesma para o gerenciador de filas de mensagens. Como se trata de enviar
informações para um sistema remoto, foi anexado à Beaglebone um cabo ethernet
RJ-45 com acesso à Internet.
Com isso, foi possível enviar mensagens com informações coletadas no sistema
embarcado (Beaglebone) através do protocolo TCP para o endereço de IP externo
do sistema gerenciador de fila de mensagens.
3.2 SISTEMA GERENCIADOR DE MENSAGENS
A comunicação entre os sistemas de aquisição e o sistema de monitoramento no
presente trabalho foi feita por meio de um middleware orientado a mensagens, do
tipo gerenciador de fila de mensagens.
Esse middleware foi projetado para remover a dependência (acoplamento) entre os
sistemas de coleta de dados e o de monitoramento, possibilitando a integração e o
compartilhamento de dados entre as partes sem qualquer interrupção por espera de
resposta para as mensagens enviadas, ou seja, assíncrono.
32 A ferramenta escolhida para coordenar essa comunicação foi o Apache Active MQ,
conforme mostrado na Figura 12, por ser uma ferramenta open source6 e bastante
popular no mercado, além de suportar clientes de várias linguagens de programação
(como Java, C, C++, C#, Ruby, Perl, Python, PHP), diferentes protocolos (OpenWire,
Stomp, AMQP, MQTT), possuir suporte às melhores práticas de integração de
sistemas e seguir a especificação JMS.
Figura 12 - Console de Administração do ActiveMQ
Fonte: Elaborado pelo autor, 2015.
Toda mensagem recebida pelo ActiveMQ foi configurada para ser persistida
(gravada) em um repositório de dados específico chamado KahaDB, que é um
banco de dados baseado em arquivo, otimizado para gravar informações de forma
rápida e confiável.
Persistir a mensagem é um passo importante para garantir que o sistema consiga se
recuperar sem perder informações em caso de qualquer problema com o envio da
mensagem para o destino.
3.3 SISTEMA DE MONITORAMENTO DE DADOS
6
Open source: denota um software cujo código-fonte original é disponível livremente e pode ser
redistribuído e modificado.
33 Após os dados serem enviados para o broker, a mensagem é então enviada para o
sistema de monitoramento de dados que tem dois principais objetivos:
(1) gravar a informação recebida em um banco de dados; e
(2) exibir as informações adquiridas em um sistema web, que pode ser
acessado por qualquer dispositivo que tenha acesso à Internet.
Todo o sistema de monitoramento foi escrito utilizando a linguagem de programação
Java, em sua versão JDK 7 64-bit da Oracle, com utilização do framework Spring
MVC 3.0.7 e do servidor de aplicação Apache Tomcat 7.0.54.
A escolha de um framework para o desenvolvimento de um sistema web é
extremamente recomendada, uma vez que praticamente todas as funcionalidades
de desse tipo de sistema lidam diretamente com o protocolo HTTP.
Mesmo com a ajuda dos containers (servidores de aplicação como o Apache
Tomcat) e a API de Servlets, que encapsulam o protocolo e facilitam o trabalho do
desenvolvedor, muito conhecimento é necessário e muito trabalho é feito
repetidamente para desenvolver até as lógicas mais simples.
Sendo assim, frameworks MVC (model-view-controller), como o Spring, diminuem o
impacto da API de Servlets e permitem o desenvolvedor se preocupar mais com a
lógica de negócios, que é o código que gera valor para aplicação.
Para o gerenciamento, construção e implementação do projeto, a ferramenta
adotada foi o Apache Maven 3.0.5. Existem várias ferramentas de construção (build)
no mercado, a mais conhecida delas é o Make, muito utilizado em projetos escritos
em C e C++, mas esse possui algumas desvantagens em Java e não é muito
utilizado.
O Maven, portanto, se encarrega de fazer de forma automatizada algumas
atividades repetitivas que sem ele, teriam que ser executadas manualmente, como o
gerenciamento de dependências, build do código, geração dos artefatos, geração de
relatórios e documentação, etc.
34 Todas as informações recebidas no sistema de monitoramento que são enviadas
pelo broker (gerenciador de filas) são persistidas em um banco de dados MySQL
5.6, escolhido principalmente por ser um banco de dados gratuito, de código aberto,
simples e muito utilizado no mercado.
A Figura 13 ilustra o sistema através de um diagrama de blocos, mostrando os
principais componentes do sistema, desde os emissores de mensagens, passando
pelo M.O.M., com seu repositório de dados KahaDB até o sistema de
monitoramento, com seu banco de dados MySQL.
Figura 13 - Diagrama de blocos
Fonte: Elaborado pelo autor, 2015.
Além das ferramentas acima, foram utilizados:
(a) Hibernate 4.3.6, como framework de persistência ORM (mapeamento
objeto-relacional) que implementa a especificação JPA (Java Persistence API);
(b) Apache Camel 2.11.1, como um ESB embutido para facilitar o manuseio e
roteamento das mensagens;
(c) Spring Security 3.1.4, para segurança e autenticação no sistema;
(d) JUnit 4.11 e JMock 2.6.0, para testes unitários automatizados;
(e) Log4j 1.2.17 e Slf4j 1.7.2, como ferramentas de log; e
(f)
Twitter
Bootstrap
3.2.0,
framework
desenvolvimento de elementos de interface.
front-end,
para
facilitar
o
35 As ferramentas utilizadas no projeto foram escolhidas de acordo com suas
funcionalidades, por serem de código aberto, possuírem uma documentação técnica
rica, serem bastante utilizadas no mercado e por serem previamente conhecidas
pelo autor.
3.4 PUBLICAÇÃO NA NUVEM
Depois de finalizados o protótipo do sistema de monitoramento de dados e a
configuração do gerenciador de fila de mensagens, foi feita a publicação das
aplicações na nuvem, utilizando uma micro instância da Amazon EC2 (Elastic
Compute Cloud). Tanto o sistema de monitoramento quanto o gerenciador de fila de
mensagens foram publicados na nuvem.
Fazer o uso de computação na nuvem é uma tendência do mercado atual. As
diversas plataformas existentes no mercado já são bem maduras e vêm sendo cada
vez mais utilizadas.
Atualmente, é possível fazer uso de plataformas que fazem provisionamento de
infraestrutura (IaaS - Infrastructure as a Service), como Amazon ou Azure, que
permitem utilizar recursos computacionais (processamento, memória, espaço em
disco, etc.) à medida em que forem sendo utilizados.
A Amazon Web Services (AWS), plataforma escolhida para o presente trabalho,
fornece uma estrutura elástica de fácil escalabilidade, bastante flexível para
progredir de acordo com as necessidades e evolução do sistema. Além de toda
infraestrutura, uma série de serviços são oferecidos, podendo ser contratados
conforme necessidade.
36 4 IMPLEMENTAÇÃO E RESULTADOS
Este
capítulo
apresenta
os
sistemas
implementados
como
resultado
do
desenvolvimento deste trabalho, desde o programa para a aquisição do dado,
passando pela lógica de envio de mensagem para o broker até as páginas
desenvolvidas para o sistema de monitoramento.
4.1 SISTEMA DE AQUISIÇÃO DE DADOS
O desenvolvimento do projeto iniciou-se com a implementação do sistema de
aquisição de dados, que consiste no desenvolvimento de um programa capaz de
coletar dados e transmiti-los para um sistema remoto.
O código fonte do programa pode ser encontrado no Apêndice A.
No caso do presente trabalho, para leitura dos dados de temperatura, fez-se a leitura
da entrada analógica 0 da Beaglebone (equivalente à ain1 no sistema operacional).
Para os dados de intensidade luminosa, leu-se a entrada analógica 1, que
corresponde à entrada ain2 no sistema operacional.
Após os dados serem coletados, as informações adquiridas foram estruturadas em
forma de mensagem, fazendo o uso de uma sintaxe específica (JSON), conforme
mostra o Quadro 1.
Quadro 1 - Exemplos de Mensagens de Luminosidade e Temperatura
{
"eventType":{
"@class":"DataEventType",
"name":"NEW_DATA"
},
"guid":"ABCD",
"data":{
"type":"Light",
"unit":"",
"value":900,
37 "device":"Beaglebone White"
}
}
{
"eventType":{
"@class":"DataEventType",
"name":"NEW_DATA"
},
"guid":"DEFG",
"data":{
"type":"Temperature",
"unit":"C",
"value":27.5,
"device":"Beaglebone White"
}
}
Fonte: Elaborado pelo autor, 2014.
O formato JSON é apenas um dos muitos dos formatos conhecidos e foi escolhido
para o protótipo por ser de fácil entendimento e implementação.
As estruturas mostradas no Quadro 1 exemplificam mensagens do tipo
"NEW_DATA", que são compostas por um GUID (identificador universal) e pelas
informações do tipo de dado coletado (“Temperature” para informações de
temperatura e “Light” para intensidade luminosa), unidade de medida (C, Celsius), o
valor coletado e o dispositivo em que o dado foi coletado (ambas Beaglebone
White).
Após estruturada a mensagem, foi feita a configuração da conexão entre os
sistemas para que a troca de informações fosse possível. Para isso, foram
configurados 3 conectores de transporte, que operam em 3 protocolos diferentes,
TCP (porta 61616), Stomp (porta 61613) e HTTP (porta 61615).
O programa embarcado na Beaglebone se conecta com o gerenciador de fila de
mensagens através do protocolo TCP, na porta 61616 e, em caso de qualquer
eventual falha nessa conexão, o protocolo Stomp é utilizado, fazendo uso da porta
61613.
38 A Figura 14 mostra o log gerado ao ser executado o programa que faz a coleta das
informações e as envia para o gerenciador de mensagens.
Figura 14 - Log do Sistema de Aquisição na Beaglebone
Fonte: Elaborado pelo autor, 2015.
Conforme mostrado no log da aplicação, o programa primeiramente tenta fazer a
conexão com o sistema de gerenciamento de fila de mensagens e, após obter
sucesso neste passo, iniciam-se a coleta e o envio das informações.
4.2 SISTEMA DE GERENCIAMENTO DE FILA DE MENSAGENS
Todas as mensagens referentes às informações coletadas são estruturadas ainda
nos sistemas de aquisição de dados com o tipo NEW_DATA. Então, essas
mensagens são enviadas para o tópico dl.data, que agrupa todas as mensagens do
tipo data (NEW_DATA, DATA_UPDATED, etc.).
39 Todo o código de configuração do ActiveMQ é mostrado no Apêndice B.
Assim que a mensagem chega ao tópico dl.data (JMS topic), ela é persistida em um
repositório de arquivos (KahaDB). Só após persistir a mensagem o broker considera
a mensagem enviada com sucesso.
Passada essa etapa, um consumidor JMS transfere a mensagem do tópico para a
fila dl.newData.queue e então a mensagem enviada para um processador, já no
Sistema de Monitoramento, que irá transformar a mensagem recebida para um
objeto Java, e depois persistirá esse objeto no banco de dados.
As Figuras 15 e 16 exibem, nesta ordem, os tópicos e filas no console administrativo
do ActiveMQ.
Figura 15 - Lista de tópicos do ActiveMQ - dl.topic.data
Fonte: Elaborado pelo autor, 2015.
Figura 16 - Lista de filas do ActiveMQ - dl.newData.queue
Fonte: Elaborado pelo autor, 2015.
40 4.3 SISTEMA DE MONITORAMENTO
O Sistema de Monitoramento tem 2 funções:
(1) persistir as informações vindas do broker no banco de dados; e
(2) permitir a visualização e monitoramento dessas informações (seja em
tempo real ou com possibilidade de acesso à base histórica) via navegador.
O sistema foi estruturado em 9 projetos, separados de acordo com suas respectivas
propostas e responsabilidades, conforme descrito na Tabela 1:
Tabela 1 - Descrição das responsabilidades de cada projeto
Projeto
Proposta
dl-base
Fornecer classes básicas necessárias a todos os demais
projetos;
dl-persistence-api
Prover estruturas básicas para persistência dos dados;
dl-jms
Estruturar configurações JMS, tais como propagação de
transações, cache, conexões jms, etc.;
dl-messaging-api
Prover estruturas básicas para o envio e tratamento de
mensagens;
dl-messaging-
Fornecer classes úteis ao tratamento de mensagens, como
camel
classes que serializam ou desserializam mensagens, classes
de evento de mensagem, rotas, etc.;
dl-new-data-
Configurar rotas de mensagem para consumir eventos do tipo
messaging-
NEW_DATA e também estruturar os processadores desse tipo
consumer
de mensagem;
dl-core
Fornecer classes (entidades, serviços e estruturas de dados)
fundamentais do projeto;
dl-application
Estruturar controladores da aplicação web, configurações de
41 segurança e autenticação;
dl-web-application
Configurar projeto web, fornecer recursos como páginas html,
arquivos CSS e Javascript, configurações de filtros e listeners,
etc.
Fonte: Elaborado pelo autor, 2014.
A Figura 17 exibe a organização dos projetos e a maneira como eles são publicados
no servidor de aplicação (container), Apache Tomcat 7.0.54:
Figura 17 - Organização dos projetos
Fonte: Elaborado pelo autor, 2014.
O sistema é composto por quatro estruturas principais:
(1) Data (informação), que é enviada pelos dispositivos;
(2) Device (dispositivo), que captura a informação a ser monitorada e envia
para a fila de mensagens;
(3) Setpoints, que representa a faixa de valores esperada para uma
determinada informação; e
42 (4) Notification (notificação), que é criada sempre quando uma informação
estiver fora dos valores estipulados nos setpoints.
A Figura 18 mostra a página inicial do sistema, logo após o usuário ser autenticado
com sucesso na tela de login.
Figura 18 - Dashboard do Sistema de Monitoramento
Fonte: Elaborado pelo autor, 2015.
Logo na página inicial, o usuário pode ter acesso a um resumo de tudo que foi
coletado e está sendo monitorado pelo sistema.
Na parte superior, são mostradas a quantidade de informações registradas no dia, a
quantidade de dispositivos cadastrados, os setpoints e as notificações. Na parte
inferior, é mostrado um gráfico com as últimas 100 amostras registradas e um
comparativo dos tipos de informações coletadas.
Todas as informações recebidas pelo sistema de monitoramento através do
gerenciador de fila de mensagens são persistidas em banco de dados, podendo
servir como base histórica de monitoramento.
A Figura 19 mostra a listagem das informações recebidas.
43 Figura 19 - Página de Listagem de Data (informação)
Fonte: Elaborado pelo autor, 2015.
Além da base histórica, também é possível fazer o acompanhamento dos dados que
estão sendo cadastrados nos últimos 5 minutos, através da página de tempo real,
conforme mostrado na Figura 20.
Figura 20 - Página Real Time com informações dos últimos 5 minutos
Fonte: Elaborado pelo autor, 2015.
O sistema também foi desenvolvido de forma a possibilitar o usuário a cadastrar os
dispositivos que são os responsáveis por coletar as informações, montar a
44 mensagem no formato conhecido pelo sistema e então enviá-la para o gerenciador
de mensagens.
As Figuras 21 e 22 mostram, respectivamente, a listagem de dispositivos
cadastrados no sistema e o formulário de cadastro.
Figura 21 - Página de Listagem de Devices (dispositivos)
Fonte: Elaborado pelo autor, 2015.
Figura 22 - Página de Formulário de Device (dispositivo)
Fonte: Elaborado pelo autor, 2015.
45 Uma vez cadastrado o(s) dispositivo(s) que pode(m) enviar informações para o
sistema, pode-se também cadastrar setpoints, indicando a faixa de valores esperada
para uma determinada informação.
As Figuras 23 e 24 exibem respectivamente a listagem e formulário de setpoints.
Figura 23 - Página de Listagem de Setpoints
Fonte: Elaborado pelo autor, 2015.
Figura 24 - Página de Formulário de Setpoints
Fonte: Elaborado pelo autor, 2015.
46 No cadastro de setpoints, o usuário pode cadastrar os valores mínimo e máximo
esperados em um determinado tipo de informação, que pode vir de um ou muitos
dispositivos.
Para cada informação recebida pelo sistema que não estiver em conformidade os
setpoints cadastrados, o sistema cria uma nova notificação, avisando que o valor
recebido está fora do esperado.
A Figura 25 mostra a tela de listagens de notificações.
Figura 25 - Página de Notifications (notificações)
Fonte: Elaborado pelo autor, 2015.
4.4 PUBLICAÇÃO NA NUVEM
Tanto o sistema de monitoramento, quanto o gerenciador de fila de mensagens
foram publicados em uma micro instância da Amazon AWS - EC2, que possui as
especificações técnicas conforme a Tabela 2:
47 Tabela 2 - Especificações Técnicas - Micro instância EC2
Tipo
t2.micro
Memória (RAM)
1 GiB
ECU (unidade de CPU)
1 unidade
Cores
1
Memória Secundária (HD)
Sistema Operacional
8 GiB
Amazon Linux AMI 64bit
Fonte: Elaborado pelo autor, 2014.
A configuração dos recursos computacionais dessa instância foi escolhida de forma
a minimizar os custos operacionais, sem comprometer a utilização dos sistemas de
monitoramento e de gerenciamento de fila de mensagens.
A Figura 26 exibe o console de administração do AWS - EC2, onde podem ser feitas
configurações de DNS, alocação ou desalocação de recursos computacionais,
configurações de monitoramento e alertas, grupos de segurança, etc.
Figura 26 - Console de Administração - Amazon EC2
Fonte: Elaborado pelo autor, 2014.
48 Após a configuração da instância, foi feita toda a instalação e configuração das
ferramentas necessárias, conforme previamente citado (Apache Tomcat, Apache
Maven, MySQL, Java, etc.).
Terminadas as devidas configurações, as aplicações passam a ser acessadas pelo
endereço correspondente ao DNS público da instância.
Assim
sendo,
o
sistema
de
monitoramento
é
acessado
no
endereço
http://54.207.4.130/ e o sistema de gerenciamento de fila de mensagens, no
endereço http://54.207.4.130/activemq-broker.
49 5 CONCLUSÕES E TRABALHOS FUTUROS
A forma com que o projeto foi estruturado permite que qualquer dispositivo com
capacidade de acessar à Internet e estruturar alguma informação em forma de
mensagem (com um formato predefinido) consiga enviar dados para o sistema de
monitoramento desenvolvido.
Em todos os testes realizados pelo autor, concluiu-se que o sistema desenvolvido
atendeu aos objetivos propostos, minimizando limitações levantadas nos trabalhos
correlatos,
como
limitações
de
escalabilidade
e
recurso
e
melhorando
significativamente questões de desempenho e confiabilidade ao fazer o uso da
comunicação assíncrona e a publicação dos sistemas na nuvem.
A arquitetura distribuída do sistema possibilitou a comunicação assíncrona entre o
emissor de informação (no caso, o sistema de aquisição) com o receptor (o sistema
de monitoramento) e, com isso, o sistema ganhou melhor desempenho e
escalabilidade, já que o emissor não fica ocupado esperando qualquer resposta do
receptor.
Em testes realizados com a Beaglebone White, conseguiu-se enviar mais de 1000
(mil) mensagens por minuto para um sistema remoto, em redes distintas. Em
sistemas distribuídos, a velocidade da(s) rede(s) em que as aplicações se
encontram influencia diretamente nesse tipo de teste.
Utilizando somente a conexão local, a mensagem não chega a sair para uma rede
externa, por isso, seu desempenho aumenta consideravelmente. Em testes locais,
foi possível enviar pouco mais de 900.000 (novecentas mil) mensagens.
Outra vantagem da arquitetura assíncrona é o baixo acoplamento entre quem envia
a mensagem e quem recebe. Com a utilização de um middleware orientado a
mensagens, o emissor não precisa conhecer quem recebe a mensagem, ele precisa
apenas trabalhar apenas um dos muitos protocolos conhecidos pelo middleware
para que a troca de informações possa ser feita.
50 A utilização de sistemas distribuídos trouxe ainda mais vantagens ao projeto, entre
as quais, a robustez do sistema, flexibilidade, eficiência e o aumento na confiança no
seu funcionamento (ou dependabilidade).
A dependabilidade é composta por um conjunto de atributos de qualidade, como a
disponibilidade, que caracteriza a probabilidade de um sistema funcionar
corretamente em um determinado espaço de tempo. Isso é possível porque, com a
carga de trabalho distribuída entre diversos computadores, caso uma das máquinas
venha a falhar, o sistema continuará ativo.
No entanto, sistemas desse tipo também possuem desvantagens que devem ser
consideradas, tais como, a segurança dos dados, sincronização de eventos de
comunicação, complexidade do sistema (gerando uma maior dificuldade de
implementação e implantação) e o congestionamento de mensagens.
Tais desvantagens surgem com maior frequência em momentos de picos de acesso,
alta utilização de recursos e tráfego de dados. Outra consequência do alto tráfego de
informações entre sistemas é um possível aumento no tempo de processamento
dessas requisições, influenciando diretamente nos tempos de resposta.
Uma das soluções para resolver esse tipo de problema é aumentar o poder
computacional das máquinas que hospedam esse sistema, fazendo uso da
escalabilidade horizontal, replicando cópias de instâncias das máquinas em cluster.
Para isso, tanto o sistema de monitoramento quanto o sistema gerenciador de fila de
mensagens foram hospedados na nuvem, utilizando uma micro instância da Amazon
EC2, podendo ser escalado horizontalmente com facilidade, aumentando os
recursos computacionais e criando clusters à medida em que for necessário, sem
impactar tanto no custo do sistema.
Apesar de não estar listado entre os objetivos do projeto, minimizar custos
operacionais é sempre um requisito não funcional no desenvolvimento de software.
51 A opção de hospedar as aplicações na nuvem contribuiu significativamente para que
esse objetivo também fosse alcançado.
Até o presente momento, com pouco mais de 3 meses de projeto, os custos de
hospedagem e utilização dos recursos computacionais da instância na nuvem não
ultrapassaram U$ 1,00 (um dólar). Nos 2 últimos meses, em que o sistema ficou
ativo por mais de 20 dias para testes de stress e disponibilidade, os custos foram de
apenas U$ 0,16 (dezesseis centavos de dólar) e U$ 0,21 (vinte e um centavos de
dólar) respectivamente.
Outra vantagem com publicação desses sistemas na nuvem possibilitam é, além da
escalabilidade horizontal, a alta disponibilidade do sistema, uma vez que nesse tipo
de serviço as falhas de hardware são gerenciadas e previamente acertadas pelo
provedor, no caso do presente trabalho, a Amazon Web Services.
Portanto, pode-se concluir que o projeto de estruturar um sistema multiplataforma de
aquisição de dados foi cumprido em sua essência, com todos os módulos
funcionando conforme o esperado, estando pronto para ser testado em ambiente
comercial.
5.1 TRABALHOS FUTUROS
Todos os módulos elaborados no trabalho são extensíveis, permitindo que trabalhos
futuros possam evoluir a proposta de monitorar dados em sistemas heterogêneos.
Neste contexto, considera-se relevante sugerir aos seguintes trabalhos:
•
Evoluir o desenvolvimento das notificações criadas, possibilitando avisos
diversos, via SMS, e-mail, ou qualquer sistema considerado relevante para
receber o aviso;
•
Utilizar mais eventos a fim de preparar o sistema para se integrar com
sistemas terceiros;
•
Configurar mais conectores de transporte, utilizando outros protocolos;
52 •
Estruturar os objetos para permitir que outros tipos de informações
(grandezas) sejam monitoradas;
•
Testar o sistema em um ambiente comercial, com melhorias em desempenho
e segurança.
53 REFERÊNCIAS
ALKAR, A. Z.; BUHUR, U. An Internet based wireless home automation system for
multifunctional devices. IEEE Transactions on Consumer Electronics. Volume 51 Issue (4). Páginas 1169-1174. Novembro 2005.
A Review of PC-based Data Logging and Recording Techniques. NI Developer Zone
website. Disponível em: <http://www.ni.com/white-paper/2963/en/>. Acesso em
Junho, 2014.
BAKKEN, David E. Middleware. Kluwer Academic Press. Washington State
University, Encyclopedia of Distributed Computing. 2003.
BONDI, B. André. Characteristics of scalability and their impact on performance.
Proceedings of the 2nd International workshop on Software and performance.
Ottawa, Canadá. Páginas 195 – 203. 2000.
CANTÚ, Dyego. Sistema web para monitoramento de sensores de temperatura
e umidade. 2013. 87 f. Monografia de Trabalho de Conclusão de Curso - Curso
Superior de Tecnologia em Análise e Desenvolvimento de Sistemas, Universidade
Tecnológica Federal do Paraná. Pato Branco, 2013.
CURRY, Edward. Message-Oriented Middleware. John Wiley and Sons,
Chichester. England, p.1-28. 2004.
Data Loggers. Introduction to Data Loggers. Omega Tech website. Disponível em:
<http://www.omega.com/prodinfo/dataloggers.html>. Publicado em 2011. Acesso em
Junho 2014.
EDER, Johann; KAPPEL, Gerti; SCHREFL, Michael. Coupling and Cohesion in
Object-Oriented Systems. Conference on Information and Knowledge
Management. 1992. LNCS, vol. 752.
ERSUE, M; ROMASCANU, D; SCHOENWAELDER, J; SEHGAL, A. Management of
Networks with Constrained Devices: Use Cases. IETF Internet Draft. 4 Julho 2014.
FERRASA, Marcelo; MAYER, Thiago Ives. Sistema de baixo custo para
termometria de grãos com servidor WEB embarcado. Departamento de
Informática – Universidade Estadual de Ponta Grossa (UEPG), 2013.
FLANAGAN, David; MATSUMOTO, Yukihiro. The Ruby Programming Language.
O’Reilly Media. 2008.
FREEMAN, Peter; HART, Davit. A Science of Design for Software-intensive
Systems. Communications of the ACM 47. Pags 19-21, 2004.
54 GUBBI, Jayavardhana; BUYYA, Rajkumar; MARUSIC, Slaven; PALANISWAMI,
Marimuthu. Internet of Things (IoT): A vision, architectural elements, and future
directions. Technical Report CLOUDS-TR-2012-2, Cloud Computing and Distributed
Systems Laboratory, The University of Melbourne. Junho, 2012
HOHPE, Gregor; WOOLF, Bobby. Enterprise Integration Patterns: designing,
building and deploying messaging solutions. Pearson Education, Inc. Addison
Wesley, 2003.
HOLLER, J.; TSIATSIS, V., MULLIGAN C.; KARNOUSKOS S.; AVESAND S.;
BOYLE D. From Machine-to-Machine to the Internet of Things: Introduction to a
New Age of Intelligence. Elsevier, 2014.
HORSTMANN, Cay. Big Java: Programming and Practice. John Wiley, 2001.
INÁCIO, Maurílio José et al. Sistema Embarcado Baseado em Hardware Livre com
Utilização de Computação nas Nuvens Aplicado no Monitoramento de Ambientes.
Revista Pesquisa & Extensão / FACIT. Vol. 2, Nº 1, Montes Claros: FACIT, 2012.
ISTEPANIAN, R.; HI, S.; PHILIP, N.; SUNGOOR, A. The potential of Internet of mhealth Things "m-IoT" for non-invasive glucose level sensing. Annual International
Conference of the IEEE Engineering in Medicine and tBiology Society (EMBC).
30 Agosto - 3 Setembro 2011.
LI, Shixing; WANG, Hong; XU, Tao; ZHOU, Guiping. Application Study on Internet of
Things in Environment Protection Field. Lecture Notes in Electrical Engineering.
Volume 133: p. 99 –106. 2011.
LUTZ, Mark. Programming Python. O’Reilly Media. 2006.
MAHZAN, N. N.; OMAR A. M.; MOHAMMAD S. Z. N.; RODZI M. Z. M. Design of
Data Logger with Multiple SD Cards. IEEE Conference on Clean Energy and
Technology (CEAT). 2013.
MALANI, Prakash. Transaction and Redelivery in JMS. JavaWorld website.
Disponível em: <http://www.javaworld.com/article/2074123/java-webdevelopment/transaction-and-redelivery-in-jms.html>. Acesso em Março, 2015.
MELL, Peter; GRANCE, Timothy. The NIST Definition of Cloud Computing.
Recommendations of the National Institute of Standards and Technology.
Special Publication 800 – 145. 2011.
QIYANG, Chen. Middleware components for E- commerce Infrastructure: An
Analytical Review. Issues in Information Science and Information Technology.
Volume 3, p.137 – 141. 2006.
RAJMOND, J.; PITICA, D. Data logger for signal analysis and failure prediction.
Design and Technology in Electronic Packaging (SIITME), 2010. IEEE 16th
International Symposium. p. 263-266. 2010.
55 RAMKUMAR, Iyer; BALASUNDARAM, Chandramouleeswaran. Best Practices and
Case Study for Open Source Middleware Migration: Egate to Apache Camel
migration. Software Engineering and Mobile Application Modelling and
Development (ICSEMA 2012). International Conference, 2012.
SEVERI, S.; ABREU, G.; SOTTILE, F.; PASTRONE, C.; SPIRITO, M.; BERENS, F.
M2M Technologies: Enablers for a Pervasive Internet of Things. The European
Conference on Networks and Communications (EUCNC2014). P. 23-26 Junho
2014.
STAMFORD, Conn. Gartner Says the Internet of Things Installed Base Will Grow to
26 Billion Units By 2020. 2013. Disponível em
<http://www.gartner.com/newsroom/id/2636073>. Acessado em: 02 Jan 2015.
STROUSTRUP, Bjarne. A History of C++: 1979-1991. International Conference on
History of Programming Languages. p. 271-279. 1993.
TANENBAUM, A. S.; STEEN, M. V. Distributed Systems: Principles and
Paradigms. 1st ed., Prentice Hall, 2002.
WEI S. Z. et al. Design and development of a tablet based real time wireless data
logger. Global High Tech Congress on Electronics (GHTCE). IEEE, 2012, p. 111 116. 2012.
WU, Miao; LU, Ting-lie; LING, Fei-Yang; SUN, Ling; DU, Hui-Ying. Research on the
architecture of Internet of Things. 3rd International Conference on Advanced
Computer Theory and Engineering (ICACTE). Volume 5. Pag. 484-487. 2010.
YAMAMOTO, Junichi; NAKAGAWA, Hiroyuki; NAKAYAMA, Ken; TAHARA,
Yasuyuki; OHSUGA, Akihiko. A Context Sharing Message Broker Architecture to
Enhance Interoperability in Changeable Environments. International Conference on
Mobile Ubiquitous Computing, Systems, Services and Technologies, p. 31–39,
2009.
56 APÊNDICE A - Código do Sistema de Aquisição de Dados (Beaglebone White)
src/main/java - SimpleProducer.java
package producer;
import helper.DataHelper;
import helper.LightHelper;
import helper.TemperatureHelper;
import
import
import
import
import
import
import
import
import
javax.jms.Connection;
javax.jms.ConnectionFactory;
javax.jms.Destination;
javax.jms.JMSException;
javax.jms.MessageProducer;
javax.jms.Session;
javax.jms.TextMessage;
javax.naming.Context;
javax.naming.InitialContext;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class SimpleProducer {
private static Logger logger =
LoggerFactory.getLogger(SimpleProducer.class);
private static final Boolean NON_TRANSACTED = false;
private static final long MESSAGE_TIME_TO_LIVE_MILLISECONDS = 0;
private static final int MESSAGE_DELAY_MILLISECONDS = 10000;
private static final int NUM_MESSAGES_TO_BE_SENT = 100000;
private static final String CONNECTION_FACTORY_NAME =
"jms/JMSConnectionFactory";
private static final String DESTINATION_NAME = "topic/data";
public static void main(String args[]) {
Connection connection = null;
try {
// JNDI lookup of JMS Connection Factory
// and JMS Destination
Context context = new InitialContext();
ConnectionFactory factory =
(ConnectionFactory) context.lookup(CONNECTION_FACTORY_NAME);
Destination destination =
(Destination) context.lookup(DESTINATION_NAME);
logger.info("Connecting to " + factory.toString());
connection = factory.createConnection();
connection.start();
57 logger.info("Connected successfully");
Session session = connection.createSession(
NON_TRANSACTED,
Session.AUTO_ACKNOWLEDGE);
MessageProducer producer =
session.createProducer(destination);
producer.setTimeToLive(MESSAGE_TIME_TO_LIVE_MILLISECONDS);
for (int i = 1; i <= NUM_MESSAGES_TO_BE_SENT; i++) {
Double temperature =
TemperatureHelper.getTemperature();
Double light =
LightHelper.getLightDigitalValue();
String msgTemperature =
DataHelper.buildMessageNewDataWithValue(
temperature,
"Temperature",
"C");
logger.info(msgTemperature);
String msgLight =
DataHelper.buildMessageNewDataWithValue(
light,
"Light");
logger.info(msgLight);
TextMessage messageTemperature =
session.createTextMessage(msgTemperature);
TextMessage messageLight =
session.createTextMessage(msgLight);
producer.send(messageTemperature);
producer.send(messageLight);
logger.info("Sleep " +
(MESSAGE_DELAY_MILLISECONDS / 1000) + " s.");
Thread.sleep(MESSAGE_DELAY_MILLISECONDS);
}
// Cleanup
producer.close();
session.close();
} catch (Throwable t) {
t.printStackTrace();
logger.error(t.getMessage());
} finally {
if (connection != null) {
try {
connection.close();
} catch (JMSException e) {
e.printStackTrace();
logger.error(e.getMessage());
58 }
}
}
logger.info("All data collected.");
}
}
src/main/java - DataHelper.java
package helper;
import
import
import
import
java.io.FileReader;
java.io.IOException;
java.util.Scanner;
java.util.UUID;
public class DataHelper {
public static Double getDigitalValue(final String analogInput)
throws IOException {
Scanner scanner = new Scanner(
new FileReader(
"/sys/devices/platform/omap/tsc/" + analogInput)
);
Double digitalValue = 0d;
while (scanner.hasNextDouble()) {
digitalValue = scanner.nextDouble();
}
scanner.close();
if (digitalValue == null) {
throw new IllegalStateException(
"Digital Value is invalid."
);
}
return digitalValue;
}
public static String buildMessageNewDataWithValue
(Double value, String type) {
return buildMessageNewDataWithValue(value, type, "");
}
public static String buildMessageNewDataWithValue
(Double value, String type, String unit) {
StringBuilder resultado = new StringBuilder();
resultado.append(
"{\"eventType\":{\"@class\":\"DataEventType\",\"name\":\"
NEW_DATA\"},\"guid\":\""
);
resultado.append(getGuid());
resultado.append("\",\"data\":{");
59 resultado.append("\"type\":\"");
resultado.append(type);
resultado.append("\",");
resultado.append("\"unit\":\"");
resultado.append(unit);
resultado.append("\",");
resultado.append("\"value\":");
resultado.append(value);
resultado.append(",\"device\":\"BEAGLEBONE_WHITE\"}}");
return resultado.toString();
}
private static String getGuid() {
return UUID.randomUUID().toString();
}
}
src/main/java - LightHelper.java
package helper;
import java.io.IOException;
import java.util.LinkedList;
import java.util.Queue;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class LightHelper {
private static Logger logger
= LoggerFactory.getLogger(LightHelper.class);
private static final Queue<Double> filterLight
= new LinkedList<Double>();
public static Double getLightDigitalValue() throws IOException {
Double digitalValue = DataHelper.getDigitalValue("ain1");
logger.debug("Digital Value read: " + digitalValue);
return digitalValue;
}
}
src/main/java - TemperatureHelper.java
package helper;
import java.io.IOException;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class TemperatureHelper {
60 private static Logger logger
= LoggerFactory.getLogger(TemperatureHelper.class);
public static Double getTemperature() throws IOException {
Double digitalValue = DataHelper.getDigitalValue("ain2");
logger.debug("Digital Value read: " + digitalValue);
return calculateCelsiusTemperature(digitalValue);
}
private static Double calculateCelsiusTemperature(Double digitalValue)
{
Double scaledDV = (digitalValue) / 4095d;
logger.debug("scaledDV: " + scaledDV);
Long thermistorResistence =
Math.round(((1 / scaledDV) - 1) * 10000);
logger.debug("thermistorResistence: " + thermistorResistence);
Long celsiusTemperature =
Math.round(10 * ((3435 / (Math.log(thermistorResistence /
0.09919))) - 273.15)) / 10;
logger.debug("Celsius Temperature: " + celsiusTemperature);
return (double) celsiusTemperature;
}
}
src/main/resources - jndi.properties
java.naming.factory.initial =
org.apache.activemq.jndi.ActiveMQInitialContextFactory
java.naming.provider.url = failover:(
tcp://ec2-54-207-4-130.sa-east-1.compute.amazonaws.com:61616,
tcp://ec2-54-207-4-130.sa-east-1.compute.amazonaws.com:62626)
?randomize=false
connectionFactoryNames = jms/JMSConnectionFactory
topic.topic/data = dl.topic.data
src/main/java/resources - log4j.properties
log4j.rootLogger=INFO, CONSOLE, FILE
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.Target=System.out
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=%t %-5p %c{2} - %m%n
# specify the location of the log file
# relative to the web application root
# or use an absolute path as show below.
log4j.appender.FILE=org.apache.log4j.RollingFileAppender
61 log4j.appender.FILE.File=log/data-logger.log
log4j.appender.FILE.MaxFileSize=10MB
log4j.appender.FILE.MaxBackupIndex=1
log4j.appender.FILE.layout=org.apache.log4j.TTCCLayout
log4j.appender.FILE.layout.DateFormat=ISO8601
pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>br.com.dataLogger</groupId>
<artifactId>producer</artifactId>
<version>1.0</version>
</parent>
<artifactId>beaglebone</artifactId>
<packaging>jar</packaging>
<name>Beaglebone Message Producer</name>
<description>Project to produce messages from Beaglebone</description>
<dependencies>
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-client</artifactId>
<version>5.10.0</version>
</dependency>
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-spring</artifactId>
<version>5.7.0</version>
</dependency>
<dependency>
<groupId>org.apache.xbean</groupId>
<artifactId>xbean-spring</artifactId>
<version>3.12</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.5</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>prepare-package</phase>
62 <goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/lib</outputDirectory>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>false</overWriteSnapshots>
<overWriteIfNewer>true</overWriteIfNewer>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>lib/</classpathPrefix>
<mainClass>beaglebone.SimpleProducer</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
</build>
</project>
63 APÊNDICE B – Código e configuração do ActiveMQ
pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>br.com.dataLogger</groupId>
<artifactId>jms</artifactId>
<version>1.0</version>
</parent>
<artifactId>activemq-broker</artifactId>
<packaging>war</packaging>
<properties>
<activemq.tomcat.port.http>18081</activemq.tomcat.port.http>
<activemq.contextUrl>/jms</activemq.contextUrl>
</properties>
<name>ActiveMQ JMS Broker</name>
<dependencies>
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-web-console</artifactId>
<version>${org.apache.activemq.version}</version>
<type>war</type>
</dependency>
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-optional</artifactId>
<version>5.7.0</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.2.1</version>
</dependency>
<dependency>
<groupId>xstream</groupId>
<artifactId>xstream</artifactId>
<version>1.1.3</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<webResources>
<resource>
64 <directory>src/main/webapp/WEBINF</directory>
<filtering>true</filtering>
<targetPath>WEB-INF</targetPath>
</resource>
</webResources>
<overlays>
<overlay>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-webconsole</artifactId>
</overlay>
</overlays>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>tomcat-maven-plugin</artifactId>
<configuration>
<path>${activemq.contextUrl}</path>
<port>${activemq.tomcat.port.http}</port>
</configuration>
</plugin>
</plugins>
</build>
</project>
src/main/java/resources - log4j.properties
log4j.rootLogger=INFO, stdout, FILE
log4j.logger.org.apache.activemq=INFO
log4j.logger.org.apache.activemq.spring=WARN
log4j.logger.org.springframework=WARN
log4j.logger.org.apache.xbean.spring=WARN
# CONSOLE appender not used by default
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d [%-15.15t] %-5p %30.30c{1} - %m%n
# specify the location of the log file relative to the web application root
# or use an absolute path as show below.
log4j.appender.FILE=org.apache.log4j.RollingFileAppender
log4j.appender.FILE.File=log/active-mq.log
log4j.appender.FILE.MaxFileSize=10MB
log4j.appender.FILE.MaxBackupIndex=1
log4j.appender.FILE.layout=org.apache.log4j.TTCCLayout
log4j.appender.FILE.layout.DateFormat=ISO8601
src/main/webapp/WEB-INF – activemq.xml
<beans
xmlns="http://www.springframework.org/schema/beans"
65 xmlns:amq="http://activemq.apache.org/schema/core"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:osgi="http://www.springframework.org/schema/osgi"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://activemq.apache.org/schema/core
http://activemq.apache.org/schema/core/activemq-core.xsd
http://www.springframework.org/schema/osgi
http://www.springframework.org/schema/osgi/spring-osgi.xsd">
<broker brokerName="web-console"
xmlns="http://activemq.apache.org/schema/core" >
<persistenceAdapter>
<kahaDB directory="${project.build.directory}/activemq.data/kahadb"
journalMaxFileLength="100mb" cleanupInterval="5000" />
</persistenceAdapter>
<transportConnectors>
<transportConnector name="openwire" uri="tcp://0.0.0.0:61616" />
<transportConnector name="stomp" uri="stomp://0.0.0.0:61613"/>
<transportConnector name="http" uri="http://0.0.0.0:61615"/>
</transportConnectors>
<systemUsage>
<systemUsage>
<memoryUsage>
<memoryUsage limit="20 mb"/>
</memoryUsage>
<storeUsage>
<storeUsage limit="200 mb"/>
</storeUsage>
<tempUsage>
<tempUsage limit="100 mb"/>
</tempUsage>
</systemUsage>
</systemUsage>
</broker>
</beans>