\documentclass{sbrt2016port}

\begin{document}

\hyphenation{Middleware}
\hyphenation{plenUS}
\hyphenation{EXEHDA}
\hyphenation{EXEHDA-IoT}
\hyphenation{EXEHDAbase}
\hyphenation{EXEHDAnodo}
\hyphenation{EXEHDAborda}
\hyphenation{EXEHDAgateway}
\newcommand {\ay} {\todo[inline, color=green!30]}
\newcommand {\pd} {\todo[inline, color=yellow!40]}
\newcommand {\rd} {\todo[inline, color=yellow!40]} % Dilli, quando quiseres comentar no pdf digite \rd + {comentário}


%\title{Ciência de Contexto Aplicada à Pesquisa Agropecuária: Explorando Tecnologias Abertas}

%\title{Ciência de Contexto com Tecnologias Abertas Aplicada à Pesquisa Agropecuária}

\title{Uma Abordagem Ciente de Contexto na IoT Aplicada à Pesquisa Agropecuária}

\author{Patrícia Davet\authorrefmark{1}, Renato Dilli\authorrefmark{1}, Lucas Xavier\authorrefmark{1}\authorrefmark{3}, Rodrigo Souza\authorrefmark{2}, Nelsi Warken\authorrefmark{4},\\ Anderson Afonso Cardozo\authorrefmark{3}, Nicácia Machado\authorrefmark{3}, Wemerson Parreira\authorrefmark{3}, Adenauer Yamin\authorrefmark{1}\authorrefmark{3}
\thanks{\authorrefmark{1}Universidade Federal de Pelotas (UFPEL), Pelotas, RS, Brasil. \vskip 0cm
Emails: \{ptdavet, renato.dilli, lmdsxavier\}@inf.ufpel.edu.br\vskip 0,1cm
\authorrefmark{2}Universidade Federal do Rio Grande do Sul (UFRGS), Porto Alegre, RS, \vskip 0cm Brasil.
Email: rssouza@inf.ufrgs.br\vskip 0,1cm
\authorrefmark{3}Universidade Católica de Pelotas (UCPEL), Pelotas, RS, Brasil.\vskip 0cm Emails: anderson.cardoso@ucpel.edu.br, nicacia@gmail.com,\vskip 0cm \{wemerson.parreira, adenauer.yamin\}@ucpel.edu.br \vskip 0,1cm
\authorrefmark{4}Embrapa Clima Temperado,  Pelotas, RS, Brasil.\vskip 0cm
Email: nelsi.warken@embrapa.br}}

%Este trabalho foi parcialmente financiado pelo CNPq (XX/XXXXX-X).

\maketitle

\markboth{XXXIV SIMPÓSIO BRASILEIRO DE TELECOMUNICAÇÕES - SBrT2016, 30 DE AGOSTO A 02 DE SETEMBRO, SANTARÉM, PA} {XXXIV SIMPÓSIO BRASILEIRO DE TELECOMUNICAÇÕES - SBrT2016, 30 DE AGOSTO A 02 DE SETEMBRO, SANTARÉM, PA}

%O formato do artigo deve ser A4, coluna-dupla, 10pt, lado-único, e possuir no máximo 05 páginas. O Resumo e Abstract devem ter no máximo 100 palavras cada um.
\begin{resumo}
As aplicações introduzidas pela Internet das Coisas, em função de sua escalabilidade, possuem em sua maioria caráter autônomo, e para tal necessitam terem ciência das informações contextuais que lhe interessam e, quando for o caso, reagirem as mesmas. Este artigo apresenta o projeto plenUS e a arquitetura de software para Ciência de Contexto que lhe dá suporte, denominada EXEHDA-IoT. Para avaliar as funcionalidades do EXEHDA-IoT, foi desenvolvido um estudo de caso junto a Embrapa Clima Temperado, empregando tecnologias de hardware disponíveis no mercado e soluções de software de natureza \textit{open-source}. Os resultados obtidos até o momento se mostraram promissores.
\end{resumo}

\begin{chave}
Ciência de Contexto, Internet das Coisas, Agropecuária.
\end{chave}

\begin{abstract}

Applications introduced by the Internet of Things, due to its scalability, have mostly autonomous character, and for this, they need to be aware of contextual information that interest you and, when necessary, react the same. This paper presents the PlenUS project and its software architecture for Context-Awareness support, called EXEHDA-IoT. To evaluate the functionalities of the EXEHDA-IoT,  a case study was developed with Embrapa Temperate Climate, using available hardware technologies  and  open-source software solutions. The results obtained until now are promising.

\end{abstract}

\begin{keywords}
 Context-Awareness, Internet of Things, Agricultural and Livestock.
\end{keywords}


\section{Introdução}
O projeto plenUS (\textit{plentiful Ubiquitous Systems}) tem como premissa o emprego do middleware EXEHDA com o objetivo de disponibilizar Sistemas Ubíquos, que explorem relações pró-ativas entre usuários, softwares e equipamentos, auxiliando nas pesquisas em desenvolvimento na Embrapa Clima Temperado. O mesmo vem sendo desenvolvido por um consórcio de pesquisa envolvendo o LUPS~(\textit{Laboratory of Ubiquitous and Parallel Systems}) da Universidade Federal de Pelotas (UFPEL) e a Embrapa Clima Temperado.

De modo mais específico o projeto plenUS tem como foco atender as demandas referentes ao provimento de serviços computacionais cientes de contexto, permitindo um registro histórico dos estados contextuais em que se encontram os equipamentos dos seguintes laboratórios da Embrapa: (i) Laboratório de Qualidade do Leite (Lableite), (ii) Laboratório de Reprodução Animal e (iii) Laboratório de Análise de Sementes Oficial (LASO), como também outras necessidades de sensoriamento em ambientes administrativos como o do Núcleo de Tecnologia da Informação (NTI), e de uma Sala de Testes do plenUS.

Com a implementação do sistema de qualidade nestes laboratórios, aumentaram as exigências no controle dos equipamentos onde são realizadas as análises, visando precisão e confiabilidade nos resultados. Deste modo, tornam-se necessários registros das leituras de grandezas físicas como temperatura, umidade e luminosidade dos equipamentos envolvidos (germinadores, câmaras frias, salas de trabalho, etc.), bem como uma atuação automatizada em função das informações sensoriadas, sempre que for o caso.

A infraestrutura computacional proporcionada pela Internet das Coisas (\textit{Internet of Things} - IoT) possibilita que estes equipamentos possam trocar informações entre si e/ou com usuários via Internet, permitindo o desenvolvimento de aplicações com maior valor agregado. Isto é possível devido a incorporação de dispositivos, unicamente identificados, e com capacidade de sensoriamento, comunicação, armazenamento e processamento~\cite{paulo-flavia:2015}.

Porém, para o desenvolvimento de aplicações neste cenário da IoT, há uma série de funcionalidades que devem ser providas, envolvendo desde a aquisição de informações contextuais adquiridas por sensores, a partir de um conjunto de fontes heterogêneas e distribuídas, até a representação dessas informações, seu processamento, armazenamento, e realização de inferências para seu uso em procedimentos de atuação~\cite{Perera:2013}.

Neste sentido, este trabalho tem como objetivo a concepção de uma arquitetura de software comprometida com a premissa de fornecer mecanismos para o desenvolvimento de aplicações cientes de contexto na IoT, denominada EXEHDA-IoT. Esta arquitetura foi modelada segundo os pressupostos do CoIoT (Context+IoT) e sua avaliação aconteceu junto ao projeto plenUS. O CoIoT especializa o middleware EXEHDA (\textit{Execution Environment for Highly Distributed Applications}) no tratamento das questões de Ciência de Contexto na IoT~\cite{souza:2015}.


O artigo está organizado da seguinte forma: a seção 2 descreve a modelagem e principais funcionalidades da arquitetura de software proposta. A seção 3 apresenta a avaliação da arquitetura pelo projeto plenUS. A seção 4 discute os trabalhos relacionados, e, por fim, a seção 5 apresenta as considerações finais.

%\section{EXEHDA-IoT: Visão e Modelagem da Arquitetura Direcionada à IoT}
\section{EXEHDA-IoT: Arquitetura e Funcionalidades}
O EXEHDA é um middleware baseado em serviços que visa criar e gerenciar um ambiente ubíquo, bem como promover a execução de aplicações sobre esse ambiente. O mecanismo de adaptação proposto para o EXEHDA emprega uma estratégia colaborativa entre aplicação e ambiente de execução, através da qual é facultado ao programador individualizar políticas de adaptação para reger o comportamento de cada um dos componentes que constituem o software da aplicação~\cite{Lopes:jucs:2014}.

O fato do EXEHDA ter uma origem enquanto middleware para UbiComp (Computação Ubíqua), faz com que o tratamento da Ciência de Contexto seja inerente à sua arquitetura.
%O desafio, o qual este trabalho tem como objetivo tratar,
Para que o EXEHDA continue provendo Ciência de Contexto tendo em vista os desafios do cenário da IoT, onde a aquisição das informações de contexto ocorre a partir de um grande número de dispositivos heterogêneos, distribuídos dinamicamente e com capacidade restrita, está em desenvolvimento o CoIoT~\cite{souza:2015}.


Considerando isso, O EXEHDA-IoT propõe um ambiente computacional constituído por células de execução, nas quais os dispositivos computacionais são distribuídos (vide Figura \ref{amb_ubiq_v6}). Cada célula é constituída dos seguintes componentes: (i) EXEHDAbase, o elemento central da célula, sendo responsável por todos serviços básicos e constituindo referência para os demais elementos; (ii) o EXEHDAnodo que corresponde aos dispositivos computacionais responsáveis pela execução das aplicações; (iii) o EXEHDAnodo móvel, um subcaso do anterior, que corresponde aos dispositivos tipicamente móveis que podem se deslocar entre as células do ambiente ubíquo, como \textit{notebooks}, \textit{tablets} ou \textit{smartphones}, (iv) o EXEHDAborda, responsável por fazer a interoperação entre os serviços do middleware e os diversos tipos de \textit{gateways}; e (v) o EXEHDAgateway, que consiste no elemento responsável por setorizar pontos de coleta e/ou atuação distribuídos, disponíveis no meio físico, realizando a interação destes com os outros componentes do middleware.


\begin{figure}[ht]
\centering
\includegraphics[width=\columnwidth]{imagens/amb_ubiq_v6.png}
\caption{Organização Celular do Ambiente Ubíquo Gerenciado pelo EXEHDA-IoT}
\label{amb_ubiq_v6}
\end{figure}


Para provimento de Ciência de Contexto na IoT, o EXEHDA-IoT se vale de dois tipos principais de servidores: Servidor de Borda e Servidor de Contexto~(vide Figura \ref{amb_ubiq_v6}). O Servidor de Borda é instanciado em um equipamento do tipo EXEHDAborda e se destina a gerenciar a interação com o meio físico através de \textit{gateways}, bem como a execução de regras de contingência e armazenamento temporário das informações contextuais coletadas, em caso de falha de comunicação. O Servidor de Contexto, por sua vez, é alocado no EXEHDAbase e atua no armazenamento e no processamento das informações contextuais, integrando informações históricas e aquelas provenientes de diferentes Servidores de Borda distribuídos no ambiente ubíquo.

Na proposta do EXEHDA-IoT a premissa é que os sensores e/ou atuadores sejam incorporados ao Servidor de Borda através de \textit{gateways}. Os \textit{gateways} são utilizados então, para tratar a heterogeneidade, tanto de hardware como de software, inerentes a dispositivos de sensoriamento e/ou atuação, realizando a conversão de protocolos e o gerenciamento dos dispositivos, além de fornecer a estes capacidade de comunicação via Internet.

Outrossim, o EXEHDA-IoT possibilita a identificação e descoberta automática dos dispositivos de sensoriamento e/ou atuação a partir dos \textit{gateways} integrados à arquitetura, por meio do protocolo de comunicação UPnP (\textit{Universal Plug and Play})~\cite{UPnP:2015}.
As características de descoberta e autoconfiguração de dispositivos inerentes ao UPnP, que constituem um facilitador quando da inclusão e/ou remoção de dispositivos em ambientes escaláveis e dinâmicos, associado ao fato deste utilizar protocolos e padrões consolidados da Internet, tais como HTTP, SOAP e XML, tornam o UPnP bastante utilizado no cenário da IoT.


Com o intuito de garantir a interoperabilidade com as tecnologias de mercado, e também potencializar a distribuição das iniciativas de coleta e/ou atuação, foram previstos três tipos distintos de \textit{gateways}:

	\begin{itemize}
	\item Gateways Proprietários (GW-PR), que tem funcionalidades e protocolos heterogêneos variando de acordo com seus fabricantes;
	\item Gateways Nativos (GW-SB), cujas funcionalidades operam de maneira integrada à arquitetura do EXEHDA, sendo instanciados em equipamentos do tipo EXEHDAgateway, e;
	\item Gateway Virtual (GWV-SB), localizado no mesmo hardware em que executa o Servidor de Borda, constituindo-se em uma virtualização do Gateway Nativo, dispensando quando possível a necessidade de um hardware específico para o \textit{gateway}.
	\end{itemize}

A arquitetura de software do EXEHDA-IoT (vide Figura~\ref{fig_arquitetura}) provê comunicação: (i) entre os \textit{gateways} e o Servidor de Borda; (ii)~entre os Servidores de Borda e o Servidor de Contexto; (iii)~entre os Servidores de Contexto localizados em diferentes células do ambiente ubíquo; e (iv)~com outros serviços do \textit{middleware} ou aplicações.
As linhas tracejadas na representação dos \textit{gateways} indicam que algum dos tipos de \textit{gateways} podem não estar presentes na arquitetura, a qual possibilita utilizar somente \textit{gateways} físicos (Nativos ou Proprietários), somente Gateway Virtual, ou ambos.



\begin{figure}[!htb]
			\centering
			\includegraphics[width=\columnwidth]{imagens/sarc.png}
			\caption{Arquitetura de Software do EXEHDA-IoT}
			\label{fig_arquitetura}
		\end{figure}


\subsection{Servidor de Contexto}

O Servidor de Contexto no EXEHDA-IoT tem suas funcionalidades organizadas através dos seguintes módulos arquiteturais.

\textbf{Repositório de Contextos}: armazena dados de configuração da arquitetura, e os valores sensoriados publicados pelos Servidores de Borda existentes no ambiente ubíquo.



\textbf{Processador de Contexto}: realiza tarefas de manipulação e dedução das informações contextuais. Baseia-se em regras do tipo ECA (Evento-Condição-Ação), de forma a tratar eventos gerados a partir de mudanças nos estados dos contextos de interesse.



\textbf{Notificador}: utiliza uma estratégia de notificação baseada no modelo \textit{publish/subscribe}, em que recebe subscrições de todos os serviços e/ou aplicações que requerem notificações a respeito das mudanças nos estados contextuais. Também é função do Notificador enviar comandos de atuação aos Servidores de Borda quando necessário, bem como a realização de notificação pela aplicação Web de novo \textit{gateway} descoberto, o qual só será utilizado mediante autenticação pelo usuário interessado.


\textbf{Módulo de Interoperação}: considerando o perfil inerentemente distribuído das aplicações alvo do EXEHDA-IoT, o Módulo de Interoperação foi concebido para gerenciar a troca de informações com os Servidores de Borda, bem como os demais serviços do middleware em execução em outros equipamentos, como também as aplicações, oferecendo para isso uma interface padronizada e bem definida. A concepção deste módulo teve como referência o estilo arquitetural REST, sendo utilizado o protocolo HTTP e suas operações (GET, PUT, POST, DELETE) no suporte às trocas de informações.



\textbf{Configurador}: aglutina todos os procedimentos de configuração necessários para o funcionamento do EXEHDA-IoT. Através deste módulo é disponibilizada uma aplicação através da qual é possível gerenciar dispositivos \textit{gateways} e regras de processamento de contexto, bem como realizar todo tipo de cadastro necessário ao funcionamento da aplicação IoT ciente de contexto.

\subsection{Servidor de Borda}

No EXEHDA-IoT o Servidor de Borda tem suas funcionalidades sistematizadas através dos seguintes módulos arquiteturais.

\textbf{Módulo de Interoperação}: é destinado a gerenciar a comunicação com o Servidor de Contexto, tendo também como referência o estilo arquitetural REST. Com isso, todas as funcionalidades associadas ao Servidor de Borda, \textit{gateways}, sensores e atuadores são mapeadas na forma de recursos e acessadas via URIs (\textit{Uniform Resource Identifiers}).


\textbf{Configurador}: é responsável pelos ajustes necessários para o funcionamento do Servidor de Borda. Entre as funcionalidades oferecidas tem-se: definição do Servidor de Contexto para a publicação das informações sensoriadas, bem como a inserção, atualização, ativação e desativação dos \textit{gateways} e seus serviços por meio do protocolo de comunicação UPnP.

\textbf{Publicador}: promove a publicação de todas as informações contextuais coletadas e garante uma \textbf{Persistência Local} das mesmas nos períodos em que a publicação ficar inviabilizada. As transações ocorrem sobre o protocolo HTTPS (\textit{HyperText Transfer Protocol Secure}), o que garante que as informações serão transferidas criptografadas, evitando acessos indevidos aos mesmos.

\textbf{Processador de Contexto}: é responsável por tratar regras de contingência, com a intenção de evitar que os dispositivos envolvidos atinjam estados críticos, o que faz com que este módulo adquira elevada importância quando a comunicação com o Servidor de Contexto for interrompida por problemas na infraestrutura de rede.

\textbf{Supervisor}: possui como objetivo aglutinar os comandos de atuação. Uma vez recebidos os parâmetros para controle da atuação, o módulo Supervisor avalia eventuais conflitos entre as requisições de atuação oriundas de diferentes fontes, para após enviar o comando de atuação ao Módulo de Atuação.

\textbf{Módulo de Atuação}: recebe do Supervisor comandos com o ID do atuador e os correspondentes padrões de operação (tempo de duração, potência de ativação, etc.), sob demanda tanto do Motor de Regras, como do Servidor de Contexto ou das aplicações a qualquer momento e os envia ao Módulo de Comunicação a fim de serem interpretados e direcionados ao \textit{gateway} responsável pelo efetivo tratamento.

\textbf{Módulo de Coleta}: trata os pedidos de coleta recebidos de forma assíncrona, repassando o ID do sensor a ser lido pelo \textit{gateway} responsável. Também tem a função de direcionar aos demais elementos da arquitetura as informações sensoriadas enviadas pelos \textit{gateways}, produzidas a partir de eventos do ambiente.

\textbf{Módulo de Comunicação}: gerencia a comunicação com os diferentes tipos de \textit{gateways}, além de prover aos demais módulos da arquitetura acesso padronizado aos recursos disponibilizados pelos \textit{gateways} no que tange ao tratamento de sensores e/ou atuadores.

\textbf{Gerenciador de Recursos}: administra procedimentos, como a entrada e saída de operação de dispositivos, bem como a reposição por avaria ou necessidade de adicionar outro ponto de monitoramento. É neste módulo que é instanciado o Ponto de Controle UPnP, que possui como tarefa descobrir os dispositivos UPnP presentes na rede, armazenando as informações sobre os dispositivos e seus respectivos serviços descobertos (sensores e/ou atuadores) em um diretório, para eventual controle destes.

\textbf{Gateway Virtual}: realiza o interfaceamento entre sensores e/ou atuadores (dispositivos sem conexão Internet) ligados diretamente ao Servidor de Borda. Possui dois módulos básicos: \textbf{Drivers} e \textbf{Trigger}. Os Drivers são responsáveis pelo encapsulamento individualizado de aspectos tecnológicos, tanto de sensores como atuadores, o que evita que as suas diferenças operacionais se projetem nos demais módulos da arquitetura. O Trigger é um módulo que tem a finalidade de gerenciar a leitura dos sensores através de eventos. Consiste em um tipo simplificado de regra de produção, que dá suporte a um conjunto limitado de funções para o tratamento de condições e ações.

\section{EXEHDA-IoT: Avaliação no Domínio Agropecuário}
As funcionalidades propostas para o EXEHDA-IoT, foram avaliadas através de estudo de caso no domínio agropecuário relacionado ao projeto plenUS. Os ambientes priorizados pelo projeto, para recebimento de infraestrutura para ciência do contexto em que se encontram seus equipamentos, bem como os tipos de grandezas mensuradas e a disposição dos equipamentos utilizados podem ser visualizados na Figura \ref{ec-embrapa}.

	\begin{figure}[!ht]
	\centering \includegraphics[width=\columnwidth]{imagens/ec-plenus_v2.png}
	\caption{Estudo de Caso - Projeto plenUS}
	\label{ec-embrapa}
	\end{figure}


Considerando a estrutura física do estudo de caso, um Servidor de Contexto, cinco Servidores de Borda e quatro Gateways Nativos foram instalados para atender as demandas da Embrapa como um todo (vide Figura \ref{ec-embrapa}), constituindo uma célula de execução do ambiente ubíquo.

O Servidor de Contexto e o Servidor de Borda 4 (SB 4) foram posicionados no NTI, localizado na unidade Sede da Embrapa Clima Temperado, enquanto os outros Servidores de Borda foram posicionados na unidade Estação Experimental Terras Baixas (ETB), distante 21Km.

O hardware utilizado para o Servidor de Contexto foi um desktop com processador Intel Pentium E2160-1.8GHz de dois núcleos, com 3GB de memória RAM e com o Sistema Operacional Ubuntu Server. Já os Servidores de Borda foram prototipados sobre o Sistema Operacional Raspbian, sendo usado como hardware a Raspberry PI Modelo B+\footnote{http://www.raspberrypi.org}.

Quanto aos \textit{gateways} previstos pelo EXEHDA-IoT e utilizados para o estudo de caso, estes são de duas naturezas: \textbf{Gateways Virtuais}, internos ao Servidor de Borda (SB), e \textbf{Gateways Nativos} com conexão Wi-Fi com o SB. Os Gateways Nativos foram utilizados no caso onde as demandas de sensoriamento introduziram a sua necessidade, seja pela disposição física dos equipamentos e/ou salas ou pela quantidade significativa de sensores.

Para a escolha do hardware utilizado na concepção do Gateway Nativo foram considerados aspectos como: baixo consumo energético, possibilidade de operação em regime sem fio (Wi-Fi) e emprego de plataforma de software disseminada. Após revisão de literatura a escolha recaiu sobre o processador ESP8266-12~\cite{ESP8266:2015}.

A operacionalização do cenário propiciado pelo estudo de caso é realizada através de regras distribuídas do tipo ECA (Evento-Condição-Ação). Uma contextualização da forma de processamento dessas regras no cenário de avaliação é apresentado na Figura~\ref{BPMN_EXEHDA-IoT} por meio de uma notação BPMN~\cite{Group2015}.

\begin{figure}[!ht]
\centering
\includegraphics[width=\columnwidth]{imagens/BPMN_EXEHDA-IoT}
\caption{Processamento de Regra Tipo ECA no Cenário de Avaliação (Notação BPMN)}
\label{BPMN_EXEHDA-IoT}
\end{figure}

O cenário consiste em monitorar uma determinada grandeza e produzir registro histórico. Enquanto a grandeza é coletada e armazenada, a mesma tem seu valor avaliado tendo em vista as faixas de operação para cada dado de contexto coletado. Alertas são enviados aos usuários envolvidos, quando os valores estiverem fora da faixa de operação especificada para o experimento.

A interação do usuário com o cenário é disponibilizada por meio de uma aplicação desenvolvida para navegadores Web, que contempla tanto tarefas de gerenciamento do EXEHDA-IoT como de visualização do registro histórico das informações contextuais, de forma gráfica ou textual.

Para atender o fato da rotina de trabalho dos laboratoristas implicar em uma mobilidade nos diversos recintos do laboratório, a aplicação Web desenvolvida possui características responsivas, o que veio agregar maior funcionalidade ao seu uso, pois possibilitou que as configurações e testes dos dispositivos de sensoriamento e/ou atuação pudessem ser realizadas no local de instalação por meio de \textit{smartphones}, devido ao seu \textit{layout} se adaptar ao dispositivo computacional utilizado.

\section{Trabalhos Relacionados}

Uma análise dos trabalhos relacionados EcoDif~\cite{pires:2014}, S$^{3}$OIA~\cite{vega:2012}, LinkSmart~\cite{LinkSmart:2015} e Carriots~\cite{Carriots:2015} em relação à satisfação dos requisitos IoT considerados neste trabalho é apresentada na Tabela~\ref{tabela_requisitos}, onde o símbolo ``X'' denota que o requisito é completamente atendido, o símbolo ``O'' indica que o requisito é parcialmente atendido, e o símbolo ``-'' indica que o requisito não é atendido.

\begin{table}[!h]
	\caption{Análise dos Trabalhos Relacionados}
	\centering
	\label{tabela_requisitos}
	\includegraphics[width=\columnwidth]{imagens/analise_trelacionados.pdf}
\end{table}


Registre-se que o único requisito endereçado de uma maneira ou outra por todos os trabalhos relacionados, foi o de interoperabilidade. Isto é devido ao fato deste ser um requisito primordial e que deve ser imperativamente endereçado por qualquer plataforma de middleware para IoT.

Dentre os trabalhos analisados, o S$^{3}$OIA destaca-se por ser o único a apresentar uma abordagem de descoberta automática de dispositivos, por meio do protocolo UPnP. De tal forma, o EXEHDA-IoT se utiliza do UPnP como estratégia de autoconfiguração e descoberta automática de seus dispositivos, tendo o gateway como elemento básico do mecanismo de descoberta e a partir dele, os sensores e atuadores são facilmente descobertos e gerenciados. Além disso, a abordagem utilizada considera todo o potencial de protocolos de uso consolidado.

A ciência de contexto é contemplada por todos os trabalhos relacionados, porém o suporte oferecido, como no caso do EcoDif e Carriots mostra-se limitado. Já o EXEHDA-IoT fornece uma organização distribuída para coleta e processamento de contexto através de regras, como também para atuação em ambientes com características heterogêneas e escaláveis. Além disso, por ter sido desenvolvido a partir de um middleware para UbiComp, o EXEHDA, também provê suporte a outros serviços ubíquos disponibilizados pelo middleware, como adaptação, comunicação desacoplada, migração de código, etc.

Outrossim, a abordagem distribuída do processamento do contexto entre os Servidores de Borda e Contexto proposta pelo EXEHDA-IoT também contribui com a minimização do fluxo de informações contextuais em relação as abordagens centralizadas, empregadas pelos trabalhos relacionados.

Por fim, outra abordagem adotada pelo EXEHDA-IoT, que trouxe benefícios principalmente no que tange à otimização do tráfego de rede e ao consumo de energia, é a proposição do uso de \textit{triggers} para gerenciar o fluxo de informações transmitidas.

\section{Considerações Finais}
O principal diferencial do EXEHDA-IoT em relação aos trabalhos relacionados diz respeito a possibilidade de gerenciar a aquisição, armazenamento e processamento das informações de contexto, de forma distribuída, independente das aplicações, em uma perspectiva autonômica baseada em regras.

Os resultados obtidos pelo estudo de caso, no domínio agropecuário atenderam as demandas dos usuários, além de fornecer um \textit{feedback} para avanços futuros, estimulando a continuidade das pesquisas na área.

Como trabalhos futuros, os seguintes aspectos foram priorizados: (i)~explorar estudos de caso em que as regras de processamento contextual utilizem outros mecanismos de inferência de mais alto nível; e (ii)~implantação de um \textit{framework} para gerenciamento do motor de regras, tanto no Servidor de Borda como no Servidor de Contexto.

\bibliography{bibliografia_ptdavet}
\bibliographystyle{IEEEtran}

\end{document}
