OpenIoT Doutorado em Informática PPGI/UFRJ Disciplina de Sistemas Distribuídos - Turma 2015/1 Prof. Paulo Pires e Profa. Flávia Delicato Definição do middleware OpenIoT Evaldo de Oliveira Aluno de Doutorado em Informática 2015
Sumário 1. O que é o Open IoT?... 3 2. Características Gerais da arquitetura OpenIoT... 3 3. Definições dos principais componentes da arquitetura do OpenIoT... 3 3.1. Camada do plano físico... 5 3.2. Camada do plano de Virtualização... 5 3.3. Camada de plano de aplicação... 7 4. Integração entre as camadas da Arquitetura do OpenIoT... 7 5. Resumo da apresentação de Nikos Kefalakis, co-fundador do OpenIoT... 8 6. Referências... 8
1. O que é o Open IoT? OpenIoT é um middleware opensource para obter informações de sensores disponibilizados como serviços na nuvem, seguindo os princípios de escalabilidade e disponibilidade existentes em Cloud Computing, sem se preocupar exatamente com quais sensores estão sendo utilizados para a troca de informações no plano físico[4]. 2. Características Gerais da arquitetura OpenIoT Os três principais componentes fornecidos pelo OpenIoT são o Global Sensor Network (xgsn, existente na camada do Plano Físico), que é responsável por fornecer a interface para acesso aos dados de sensores heterogêneos, o Linked Sensor Middleware (ou LSM), existente na camada de Plano de Virtualização, e o Request Definition, o qual permite especificar os serviços de requisição de dados dos sensores que estão virtualizados. O LSM permite "linkar" os dados coletados do GSN a fim de organizá-los, e também permite a descoberta de um sensor. Os dados dos sensores identificados são apresentados na camada de Plano de Aplicação. A seguir são descritas as camadas da visão arquitetural do OpenIoT [3][4]. 3. Definições dos principais componentes da arquitetura do OpenIoT Esta seção descreve os componentes oferecidos pelo middleware OpenIoT, os quais permitem a integração dos sensores do plano físico com a camada de tratamento de dados e visualização de serviços [2]. São elas: O Sensor Middleware utiliza o GSN para coletar os pedidos de consultas sobre os sensores. Também a troca de dados entre os sensores virtuais e os dispositivos físicos. Ele age como um hub entre a plataforma do OpenIoT e o mundo físico. O Sensor Middleware é implementando com base em uma ou mais instâncias (ou nós) de sensores. O Cloud Data Storage (ou Linked Stream Middleware Light, LSM-Light) permite o armazenamento de fluxo de dados originados do Sensor Middleware, assim agindo como um gerenciado de dados na nuvem. A infraestrutura na nuvem armazena também os metadados requeridos para tornar a plataforma de OpenIoT mais operacional reconhecendo as propriedades dos sensores identificados. Além disso, a nuvem funciona como um servidor de sensores oferecidos pela plataforma do OpenIoT. A implementação do protótipo da plataforma OpenIoT usa o middleware LSM, projetado com funcionalidades para recuperar e inserir dados sobre os sensores. Todas as requisições são processadas pelo Scheduler para a implantação sob demanda dos serviços, e garante acesso aos próprios recursos que os serviços solicitam. Este componente se compromete com as seguintes tarefas: a descoberta de sensores e os dados que os configuram; gerencia um serviço e seleciona a inserção dos novos serviços descobertos. O Service Delivery & Utility Manager executa um papel duplo. Por um lado, ele combina o fluxo de dados (ou stream) como serviços criados na camada de aplicação do OpenIoT, a fim de entregar o retorno da execução por meio de uma consulta em PPGI/UFRJ OpenIoT 3
SPARQL. Para este objetivo, este componente faz uso da descrição do serviço e recursos identificados e reservados pelo componente Scheduler. Por outro lado, este componente age como um serviço medindo cada serviço individualmente. Esta funcionalidade de medição é acordada usando funcionalidades, tais como, contagem de sensores disponíveis e otimização de recursos. O componente Request Definition permite uma especificação on-the-fly, a qual pode ser modificada a qualquer momento a fim de conter uma nova aplicação de consulta de dados aos sensores. Esta especificação permite criar uma requisição na camada de aplicação do OpenIoT. Este componente compreende uma coleção de serviços para especificação e formular tais requisições, embora também os submetam para o componente Global Scheduler. Este componente é baseado em uma GUI (Graphical User Interface). O componente Request Presentation gerencia a visualização das saídas de um serviço que é fornecido pela plataforma OpenIoT. O componente Request Presentation lê uma requisição de serviço para apresentar os dados consultados por meio de gráficos. O componente Configuration e Monitoring permite o gerenciamento e configuração das funcionalidades de vários sensores e os serviços criados no OpenIoT. Este componente é mantido também por uma GUI. A Figura 1 apresenta a visão geral da arquitetura com os respectivos componentes citados anteriormente. Figura 1. Visão Geral da arquitetura do OpenIoT. Fonte: Projeto OpenIoT [3] As próximas seções detalham o funcionamento de cada camada da arquitetura do OpenIoT. PPGI/UFRJ OpenIoT 4
3.1. Camada do plano físico É caracterizada por várias redes de sensores, e que permite que estes sensores sejam identificados, e seus dados sejam lidos, sofrendo transformações para estruturas de dados que possam ser armazenadas e consequentemente apresentadas para os usuários pela camada de apresentação. A camada de plano físico, é também uma camada de middleware que permite o acesso às funcionalidades dos sensores. O OpenIoT também está habilitado para integrar a troca de informações por meio de outras plataformas de middlewares para sensores na nuvem, como, por exemplo, o Xively. O Xively é uma plataforma como serviço (PaaS) para a Internet das coisas que permite simplificar a interligação entre dispositivos, dados, pessoas e lugares, acelerando a criação de soluções para ClouT (Cloud of Things). Desta forma, o OpenIoT possui conectores que servem para permitir comunicação com sensores disponíveis na plataforma Xively. O protocolo de comunicação utilizado para a troca de dados no plano físico é o CoAP (Constrained Application Protocol) [3]. O CoAP é um protocolo de software que é usado em dispositivos eletrônicos muito simples que permite-lhes comunicar interativamente através da Internet. Particularmente é usado por sensores pequenos de baixa potência, interruptores, válvulas e componentes similares que precisam ser controlados ou supervisionado remotamente, através da Internet. Além disso, é um protocolo de camada de aplicativo que se destina para uso em dispositivos na internet com recursos limitados, como nós de uma WSN (Wireless Sensor Network). Foi projetado para ser traduzido facilmente para HTTP a fim de ser integrar com a Web [3]. 3.2. Camada do plano de Virtualização Permite criar a nuvem de sensores por meio de sensores integrados pela LSM, onde também os dados são identificados e armazenados usando o formato RDF. Este formato permite o gerenciamento dos dados por meio do conceito de Linked Data. Na maioria dos casos, o gerenciamento clássico de Linked Data, por exemplo, geo-dados ou DBpedia pode ser bem suportado pela infraestrutura existente desde que os dados normalmente mudem com pouca frequência. No entanto, o OpenIoT permite manipular grandes volumes de dados, assim como novos itens de dados quando se tornam disponíveis. Integrar esses fluxos de informações com outras fontes permite uma vasta gama de novas aplicações, manipulando também dados heterogêneos [3]. Devido à natureza heterogênea de diversos tipos de dados, a integração e processamento dos mesmos é uma tarefa difícil. Além disso, o processamento destes dados pode ser prejudicado. Distribuir a carga de processamento de dados é uma estratégia para lidar com o problema de escalabilidade. Além disso, a tendência para infraestrutura em nuvem e não proprietária fornece um argumento adicional para processar dados em um ambiente heterogêneo. A Amazon EC2, Google Cloud e Microsoft Azure são os exemplos mais importantes do desenvolvimento de propostas semelhantes [3]. No caso do OpenIoT o plano de virtualização busca os dados dos sensores do plano físico, no formato RDF, e implanta o sensor utilizando o Amazon EC2, que é um serviço da web que fornece capacidade de computação redimensionável na nuvem, sendo projetado para facilitar a computação de escala tornando os serviços disponíveis para desenvolvedores. Um mecanismo de Linked Stream Data pode ser executado em um cluster permitindo elasticidade e adaptação às novas cargas de processamento ajustando dinamicamente o número de nós de processamento do cluster em tempo de execução [3]. Esta "elasticidade" é vital para o processamento de dados de sensores na nuvem. Os dados provenientes dos sensores virtuais são transformados em uma representação de dados em RDF, e classificados de acordo com a ontologia de sensores, que oferece suporte à criação da base de conhecimento sobre os sensores. Essa transformação é novamente feita usando wrappers que PPGI/UFRJ OpenIoT 5
adicionem anotações e significados aos dados processados pelos sensores. Os wrappers no OpenIoT são componentes capazes de transformar os dados enviados pelo Sensor para um formato que possa ser armazenado de acordo com o projeto de base de dados definido no LSM. O contrário também é feito, quando há a necessidade de fornecer um dado armazenado para ser publicado para outros sensores [3][4]. Os sensores virtuais são representações de sensores físicos podendo compreender um conjunto de fontes de dados a ser manipulado pela LSM. Desta forma, a LSM considera os sensores virtuais como fontes de dados de entrada. Os dados provenientes destes sensores virtualizados são transformados em uma representação de dados com seus significados, ou seja, em RDF [3], como definido anteriormente. O OpenIoT também suporta funcionalidades de recuperação de dados por meio de agregação no nível do sensor virtualizado[2]. Para permitir as consultas em sensores virtualizados ampliando estas consultas sob vários dispositivos existentes na rede, o OpenIoT está integrado ao SBOX, produto do SENSAP sediada na Suiça e o AspireRfid, a qual permite oferecer um suporte prontamente disponível para EPCs (Eletronic Product Code) [2]. O servidor SBOX é composto por uma suite em J2EE, e destina-se a apoiar a execução de operações, otimização do fluxo de trabalho, monitoramento de desempenho e rastreabilidade de EPC (Eletronic Product Code) e sensores. O AspireRfid é um projeto visa desenvolver e promover um middleware open-source, aberto, leve, compatível com padrões de comunicação, escalável e integrado com várias ferramentas para facilitar o desenvolvimento, a implantação e o gerenciamento de aplicativos baseados em RFID. Ele implementa várias especificações de consórcios como EPC Global, Fórum NFC, JCP e OSGi Alliance [3]. As iniciativas SBOX e AspireRfid permitem ampliar a capacidade gerenciamento de diversos dispositivos virtualizados. Com esta integração é possível executar wrappers que transformam os dados enviados pelos sensores para o armazenamento em um servidor de dados [4]. O Virtuoso é um servidor de banco de dados encarregado de armazenar os dados dos sensores mantidos na rede de dados. Também pelo Virtuoso, são executadas funções de agregação. A funções de agregação possuem algoritmos que permitem agilizar a recuperação dos dados. Por exemplo, se um usuário estiver interessado em saber se somente um sensor executou pelo menos um envio de mensagem, a aplicação pode oferecer funcionalidades para executar uma consulta agregada usando uma função chamada COUNT [3], semelhante às instruções de agregação utilizadas por outros servidores de banco de dados. Um sensor virtualizado é acessado nesta camada por meio do Global Scheduler. O Global Scheduler formula o pedido com base em entradas enviadas pelo usuário através do componente Request Definition. Estas entradas são definidas por meio de aplicativos Web. O Global Scheduler analisa cada solicitação de serviço e em seguida interage com o resto da plataforma de OpenIoT por meio de sensores armazenados na nuvem e pelo mecanismo de LSM descrito anteriormente. Além disso, o LSM fornece três tipos diferentes de wrapper: (1) wrappers na camada física, que são projetados para coletar dados dos sensores de outros tipos de dispositivos físicos. (2) na camada de virtualização, são os wrappers que expõem os dados de um sensor no formato RDF a partir de uma consulta no banco de dados. (3) wrappers mediadores que mediam as conexões com outras plataformas de middleware do sensor, transformando dados de uma variedade de formatos de dados em RDF. O LSM fornece os wrappers de mediação para middlewares como GSN, Xively, os serviços de gateway Web/sensor da National Oceanic and Atmospheric Administration (NOAA10) e a London Transport syndication [4]. Outro componente importante da camada de virtualização do OpenIoT é o Utility Manager (UM). No OpenIoT uma variedade de algoritmos está implementada para o gerenciamento de recursos, como, por exemplo, a otimização na leitura e recuperação dos dados de sensores, gerenciamento de privacidade e segurança, com base em métricas para manter níveis PPGI/UFRJ OpenIoT 6
de serviços (SLAs, Service Level Agreements) entre os provedores de serviços de nuvem em OpenIoT e os usuários finais [5]. As métricas definidas pelo UM são registradas como parte da implementação deste componente. Podem ser sobre a qualidade dos dados transmitidos, largura de banda, localização do ICOs (Internet Connected Objects). O Utility Manager classifica o resultado final e as várias métricas de uso em duas grandes categorias. Essas métricas são para sensores físicos e sensores virtuais, tais como, volumes de dados, largura de banda e consumo de energia [5]. 3.3. Camada de plano de aplicação Esta camada é composta por três módulos. O módulo de Request Definition que permite a criação de uma aplicação Web para que os usuários finais modelarem visualmente seus serviços baseados em OpenIoT [5]. Os serviços são modelados e agrupados em "aplicativos". Esses aplicativos são capazes de agrupar uma coleção de serviços diferentes que descreve uma aplicação da vida real (por exemplo, previsões do tempo). Isso permite aos usuários finais gerenciar aplicações diferentes com base em uma única aplicação. Todos os serviços modelados são armazenados pelo Scheduler do OpenIoT e são carregados automaticamente quando um usuário acessa o aplicativo da Web [5]. O módulo de Request Presentation é um Componente que seleciona mashups de uma biblioteca para facilitar a apresentação de serviço em uma interface Web 2.0. Para visualizar estes serviços, ele se comunica diretamente com o Utility Manager a fim de recuperar os dados relevantes [5]. E, finalmente, o módulo Configuration and Monitoring, que é componente que permite o gerenciamento e a configuração de funcionalidades sobre os sensores e os serviços que são implantados dentro da plataforma de OpenIoT. Além disso, ele permite que o usuário monitore a execução dos diferentes módulos implantados [5]. 4. Integração entre as camadas da Arquitetura do OpenIoT Diante das definições anteriores sobre o funcionamento de cada camada da arquitetura do middleware OpenIoT, esta seção apresenta um resumo do funcionamento em conjunto das camadas: 1. Os sensores são cadastrados na plataforma do OpenIoT. 2. Esses sensores existem no plano físico, produzindo dados sobre temperatura e humidade, por exemplo. 3. Os dados dos sensores são identificados e carregados para o plano de virtualização. Estes dados são transformados e armazenados em formato RDF pela LSM, e implementados na nuvem. 4. Os módulos de interfaces de usuários, Scheduler e SD&UM (Service Delivery and Utility Manager) são implementados pelos usuários. O componente Global Scheduler formula o pedido com base em entradas de dados e métricas implementadas pelo componente Request Definition, que é uma interface Web para o usuário realizar a modelagem para recuperação dos dados. O Request Definition descreve o pedido de leitura de dados e envia para o componente de Scheduler. PPGI/UFRJ OpenIoT 7
5. O Scheduler faz a descoberta do sensor e registra o pedido no LSM. O componente SD&UM recupera a demanda do nível de usuário enviada pelo Scheduler e formula um pedido para recuperação dos dados do sensor por meio do componente LSM. Neste passo a arquitetura executa consultas na base de dados armazenada no banco de dados Virtuoso. 6. Os dados recuperados suportam as consultas e gráficos do componente Request Presentation, onde os dados solicitados são apresentados. 7. A camada de plano de aplicação apresenta os dados em widgets predefinidos através do componente Request Presentation. 5. Resumo da apresentação de Nikos Kefalakis, cofundador do OpenIoT Esta seção descreve de forma resumida a palestra de Nikos Kefalakis, apresentada no evento FOSDEM em 2014, na Bélgica. Dr. Nikos Kefalakis é co-fundador e arquiteto de sistemas do projeto OpenIoT [1]: O que posso fazer com OpenIoT? Virtualizar vários sensores. Pode captar dados de sensores para a plataforma. Descobre tipos de dados de sensores. Cria facilmente serviços que podem ser usados sem muita complexidade. Cria mashups para uso privado. Arquitetura disponibiliza no plano físico o middleware para acesso às funcionalidades e dados trocados pelos sensores no plano físico. No plano de virtualização, gerencia-se os dados e definições dos sensores, as anotações dos dados e os armazena em uma plataforma de cloud, onde os serviços podem ser disponibilizados por uma nuvem privada ou pública. Na palestra Nikos demonstra os serviços disponível em Amazon Cloud. O Scheduler é responsável pode descobrir sensores disponíveis, e o request definition é uma ferramenta que descreve como construir o serviço de recuperação de dados que estão na nuvem. O componente de Service Delivery & Utility Manager recupera as descrições solicitadas para serem visualizadas pelo componente Request Presentation. As funcionalidades que o OpenIoT é capaz de oferecer, envolvem: a-) descoberta de novos sensores; b-) habilita o acesso aos novos sensores por meio de serviços armazenados na nuvem; c-) os serviços são descritos por SPARQL usado para acessar tanto os dados dos sensores. Outras funcionalidades envolvem encontrar ICOs e sensores, isto ocorre por meio do componente de Scheduler, que adota critérios de descoberta por tipo e localização de ICOs e sensores, disponibilizar a nuvem de sensores por meio do componente LSM, usar a linguagem SPARQL para acessar ambos dados de sensores e metadados dinamicamente. O serviço de visualização do OpenIoT fornece leitura e uso de componentes em mashups, disponibilizando uma biblioteca de mashups. 6. Referências [1] KEFALAKIS, Nikos. OpenIoT OS Project [Filme-vídeo]. Produção de FOSDEM. Greece, 2014. Disponível em https://www.youtube.com/watch?v=8ap0yoffaqu, 25:17 min. color. [2] CORDIS. D4.3.1 Core OpenIoT Middleware Platform. Disponível em: http://cordis.europa.eu/docs/projects/cnect/5/287305/080/deliverables/001- OpenIoTD431Draft. pdf. Acesso em 15 de maio de 2015. PPGI/UFRJ OpenIoT 8
[3] CORDIS. D4.4.2 OpenIoT Integrated Development Environment b. Disponível em: http://cordis.europa.eu/docs/projects/cnect/5/287305/080/deliverables/001-openiotd442 Draft.pdf. Acesso em 15 de maio de 2015. [4] OpenIoT. OpenIoT - The Open Source Internet of Things. Disponível em: https://github.com/ OpenIotOrg/openiot/wiki. Acesso em 06 de maio de 2015. [5] CORDIS. D6.3.1 Proof-of-Concept Validating Applications. Disponível em: http://cordis.europa.eu/docs/projects/cnect/5/287305/080/deliverables/001-openiot D631131224 DraftAresreg.pdf. Acesso em 15 de Maio de 2015. PPGI/UFRJ OpenIoT 9