Markedsorientering

A melhor abordagem, em geral, ´e considerar fazer sistemas de middleware de modo que sejam simples de configurar, adaptar e personalizar conforme necess´ario para uma aplicac¸˜ao. Quando

o assunto ´e uma Rede de Sensores sem Fio (RSSF) o middleware tamb´em deve permitir a gerac¸˜ao de comunicac¸˜ao de tarefas de alto n´ıvel, assim como a coordenac¸˜ao de tarefas entre os n´os, mesmo quando estes n´os possuam caracter´ısticas heterogˆeneas [37]. ´E necess´ario salientar que o alcance de um Middleware n˜ao se restringe unicamente `a rede de sensores e sim aos dispositivos e redes conectadas `a mesma.

Com o objetivo de atender `as restric¸˜oes de recursos computacionais das RSSF, a qual ´e propensa a falhas, o middleware deve ser projetado para ser robusto o suficiente para ser tolerante a falhas exigindo pouco processamento e armazenamento, limitando-se sempre a menor troca de mensagens poss´ıvel.

Os atuais projetos de RSSF evidenciam uma forte dependˆencia entre as aplicac¸˜oes e os protocolos de comunicac¸˜ao utilizados [38], isto devido `a necessidade de eficiˆencia em energia por parte da RSSF. As atuais pesquisas fundamentam esta teoria atrav´es da necessidade de um forte acoplamento entre as diversas camadas da pilha de protocolos de comunicac¸˜ao, sendo estes ´ultimos bastante diversos e em muitos casos com funcionalidade especifica para alguns cen´arios de aplicac¸˜ao.

Para [39] o principal objetivo do middleware para RSSF ´e de apoiar o desenvolvimento, implementac¸˜ao, execuc¸˜ao e manutenc¸˜ao de aplicac¸˜oes baseadas em sensores. Entre estes objetivos incluem-se mecanismos para formulac¸˜ao de complexas tarefas como as de comunicac¸˜ao, coordenac¸˜ao, entre outras, as quais facilitam a distribuic¸˜ao de atividades para os n´os sensores de forma individual. Assim mesmo, devem ser fornecidos abstrac¸˜oes e mecanismos adequados para lidar com a heterogeneidade dos n´os sensores. Todos os mecanismos previstos por um middleware devem respeitar os princ´ıpios de projeto e as caracter´ısticas de uma RSSF resumidas `a energia, escalabilidade e robustez.

O projeto de middlewares parece ser cada vez mais diversificado quando se trata de uma RSSF, arriscando poder de processamento atrav´es de um middleware orientado a servic¸os para redes de sensores e atuadores com comunicac¸˜ao sem fio que prop˜oe uma padronizac¸˜ao na comunicac¸˜ao da rede com as aplicac¸˜oes cliente; isto acontece atrav´es da utilizac¸˜ao de tecnologias de Web Service como o protocolo SOAP e uma sintaxe para a troca de dados e documentos orientados a texto chamado de XML [40]. A proposta apresenta um modelo superficial de camadas, com apresentac¸˜ao de resultados de processos de comunicac¸˜ao obtidos atrav´es de simulac¸˜oes.

Outro projeto de Middleware ´e descrito em [41], os autores prop˜oem um middleware que oferece uma camada entre aplicac¸˜oes e a rede de sensores e oferece um mecanismo padr˜ao para representar consultas, tarefas e dados. Al´em disso, fornece a escolha automatizada da

configurac¸˜ao da rede e da estrat´egia de disseminac¸˜ao de dados usada, permitindo ao usu´ario acessar a rede sem tomar conhecimento de infra-estrutura e software subjacentes.

Redes de Sensores possuem uma forte integrac¸˜ao com o mundo f´ısico, e suas caracter´ısticas especiais (limitac¸˜oes computacionais) fazem da sua implementac¸˜ao uma tarefa nada trivial. Para [42] ´e necess´ario no projeto de um middleware conter um ambiente de execuc¸˜ao que suporte e coordene v´arios aplicativos e servic¸os padronizados, tais como a agregac¸˜ao de dados, pol´ıticas de gest˜ao de dados, controle e pol´ıticas de gest˜ao de adaptac¸˜ao para aplicac¸˜oes e outros mecanismos adaptativos que promovam a utilizac¸˜ao eficiente de recursos do sistema para prolongar a vida ´util da rede de sensores.

Para [43] projetar um Middleware para RSSF, considerando o reduzido poder computacional e outras caracter´ısticas restritivas destes pequenos dispositivos embarcados, n˜ao ´e uma tarefa trivial e, ´e preciso lidar com muitos desafios ditados pelas caracter´ısticas da RSSF, assim como das aplicac¸˜oes. Entre estes, temos: Recursos de hardware, escalabilidade e topologia de rede, heterogeneidade, organizac¸˜ao da rede, integrac¸˜ao com o mundo real e o conhecimento da aplicac¸˜ao, neste ´ultimo o middleware deve incluir mecanismos para injetar conhecimento da aplicac¸˜ao na infra-estrutura da RSSF, o que, permitir´a que os requisitos de mapeamento de comunicac¸˜ao de aplicativos para os parˆametros de rede permitam um ajuste fino do processo de monitoramento da rede, mantendo ao mesmo tempo padr˜oes m´ınimos de qualidade de servic¸o (QoS), como j´a ´e caracter´ıstico numa RSSF.

A lista de propostas de middlewares para RSSF ´e bastante extensa, algumas passam unicamente por estudos baseados em an´alises bibliogr´aficas dos modelos existentes, outros apresentam resultados baseados em simulac¸˜ao e descrevem modelos de servic¸os de detecc¸˜ao de eventos em tempo real atrav´es de um middleware chamado de DSWare [44]. A proposta argumenta sobre a falta de confiabilidade no servic¸o de eventos em tempo real, e apresenta uma soluc¸˜ao com t´ecnicas de confiabilidade e semˆantica, a proposta inclui a detecc¸˜ao parcial de eventos cr´ıticos. Um levantamento das principais aplicac¸˜oes para RSSF se faz necess´ario para caracterizar as funcionalidades do mesmo e a necessidade de um middleware que permita aos aplicativos especificar uma pol´ıtica de gest˜ao para as RSSF, j´a que os atuais n˜ao atendem as necessidades especificas de todas as aplicac¸˜oes para redes de sensores [45]. A demonstrac¸˜ao ´e realizada atrav´es do middleware MILAN para aplicac¸˜oes de sa´ude baseada em sensores pessoais.

2.3.4

Observac¸˜oes para os Middlewares de Integrac¸ao Redes de Sensores

e Sistemas Ciber-F´ıscos

N˜ao se pode esquecer que os dispositivos f´ısicos que fazem parte de um CPS, na sua maior parte, s˜ao tipicamente limitados pelos seus recursos de energia, processamento e potˆencia de c´alculo e nem sempre ´e poss´ıvel projetar e executar processos complexos de computac¸˜ao sobre estas arquiteturas, na sua maioria embarcada.

Quando se trata de uma RSSF as caracter´ısticas antes mencionadas tornam-se cr´ıticas, j´a que al´em da limitac¸˜ao de recursos computacionais, devido a sua reduzida fonte de energia, ´e necess´ario tamb´em considerar a dinamicidade da sua estrutura organizacional enquanto topologias e diversidade de protocolos de comunicac¸˜ao de um ´unico salto (single-hop) e de m´ultiplos saltos (Multihop). Existe aqui uma grande dificuldade j´a que para diversas aplicac¸˜oes a escolha do protocolo de comunicac¸˜ao determinar´a a eficiˆencia no gerenciamento dos recursos e atividades da RSSF. Esta complexidade de caracter´ısticas e escolhas se estende at´e os CPS onde cobram um n´ıvel exponencial j´a que a integrac¸˜ao e funcionalidades de uma RSSF dentro de um CPS pretendem ir al´em de unicamente monitorar ambientes. Na pr´atica estes elementos de hardware com caracter´ısticas especiais dever˜ao coletar valores do ambiente f´ısico e associar estes valores a novos parˆametros que permitam acionar e integrar outros sistemas computacionais.

´

E tamb´em necess´ario ressaltar que o processo de desenvolvimento de um middleware passa por demandar um grande esforc¸o e em muitas ocasi˜oes o projeto e a estruturac¸˜ao progressiva dos eventos de comunicac¸˜ao entre camada superior e as camadas subjacentes ´e bastante lenta. As etapas de modelamento s˜ao trabalhosas e muitas vezes acabam sendo dif´ıcil registrar a qualidade do middleware, entretanto, ´e essencial capturar e registrar todas as etapas do projeto e do desenvolvimento que podem determinar a implementac¸˜ao e utilizac¸˜ao bem sucedida do middleware por parte do usu´ario do CPS. No projeto de middleware para o CPS ´e necess´ario considerar alguns requisitos caracter´ısticos destes sistemas, assim como de muitos sistemas distribu´ıdos, a diferenc¸a ´e que dentro de um CPS alguns requisitos exigem um maior cuidado na sua identificac¸˜ao e descric¸˜ao para uma posterior codificac¸˜ao, isto devido `a alta densidade de componentes de hardware associados, assim como as caracter´ısticas de mobilidade e heterogeneidade de protocolos de comunicac¸˜ao e arquiteturas que fazem parte do CPS. Na figura2.1, s˜ao apresentados alguns destes requisitos.

Figura 2.1: Diagrama de Requisitos Globais num Sistema Ciber-F´ısico.

Os requisitos apresentados (Figura 2.1), n˜ao s˜ao de car´ater definitivo e espec´ıfico e obedecem unicamente a uma forma de caracterizac¸˜ao das funcionalidades que deve atingir um CPS dentro de um pequeno dominio de sensoriamento, controle e atuac¸˜ao.