BT

Uma arquitetura de referência para a Internet das Coisas - Parte 1

| Postado por Daniel Karzel Hannelore Marginean Tuan-Si Tran , traduzido por Tulius Lima em 07 Dez 2016. Tempo estimado de leitura: 20 minutos |

Esse é o primeiro de dois artigos onde tentamos trabalhar a partir de um nível abstrato de arquiteturas de referência de Internet das Coisas (ou IdC) em direção a uma arquitetura e implementação concreta para casos de uso selecionados. Esse primeiro artigo cobre a definição de uma arquitetura mais concreta e abrangente, e o segundo artigo irá aplicar essa arquitetura a casos de uso reais.

Estamos próximos de um novo mundo interconectado. Sob o nome "Internet das coisas" - IoT, em inglês Internet of Things - ou "Indústria 4.0", o qual empresas estão desenvolvendo uma nova rede de objetos interligados para nossa vida cotidiana. O objetivo da Internet das Coisas é de interligar objetos, a fim de trocar informações para cumprir tarefas para seus usuários. Para exemplificar, soluções de geladeiras que se comunicam não só com o seu smartphone, mas também com os servidores do fabricante ou com uma usina de energia em breve se tornarão realidade. As empresas por trás do crescimento dessa nova tecnologia e comunicação vêm de todas as indústrias - não só os grandes nomes de big data, como Google, Microsoft ou Apple, estão indo nessa direção, mas também grandes companhias de seguros, os produtores de periféricos e fabricantes de automóveis estão promovendo a Internet das Coisas..

A chave para permitir a comunicação entre todas estas diversas "coisas" é a padronização. Estabelecer um padrão, no entanto, é fácil de ser reivindicado num ambiente de pesquisa, mas difícil de ser alcançado no mundo real. Arquiteturas de referência são de grande ajuda para a padronização, já que definem diretrizes que podem ser usadas quando se planeja a implementação de um sistema utilizando a Internet das Coisas.

A fim de alcançar uma padronização é necessário criar arquiteturas de referência de alto nível como o definido pela IOT-A. No entanto, arquiteturas de referência de alto nível são difíceis de entender por serem muito abstratas. Se você está em um trabalho de consultoria, verá que é impossível mostrar essas arquiteturas de referência de alto nível para clientes reais na indústria.

Gostaríamos de ir além e fornecer diretrizes sobre como fundamentar uma arquitetura mais concreta a partir da arquitetura de referência IOT-A. A ideia é pegar a arquitetura de referência IOT-A e criar a partir dela uma arquitetura menos abstrata que poderia até mesmo ser colocada em um "Resumo Executivo" - que é o que está acontecendo neste artigo. Além disso, selecionamos alguns casos de uso e instanciamos nossa arquitetura de referência a fim de mostrar o ciclo de vida completo até a implementação de um sistema real dentro da IoT - que será apresentado em um artigo subsequente.

Primeiramente, vamos definir alguns termos:

  • Coisa: é um objeto do nosso dia a dia colocado em nosso ambiente diário. Uma coisa pode ser um carro, uma geladeira, mas também pode ser abstraído a uma casa ou uma cidade, dependendo do caso de uso;
  • Dispositivo: um sensor, atuador ou tag. Geralmente o dispositivo é parte de uma coisa. A coisa processa informações de um contexto e informa sobre os dados coletados para outras coisas. Além disso, a coisa pode passar ações para atuadores.

Há uma certa quantidade de "componentes inevitáveis da Internet das Coisas" que é possível encontrar (de uma forma ou de outra) em cada uma das arquiteturas de referência da Internet das Coisas (como por exemplo, em Brillo, no Google, ou na IOT-A ou Z-Wave). Entre elas, podemos destacar:

  • Componentes de interoperabilidade e integração em relação às coisas e dispositivos;
  • Técnicas de computação orientada a contextos, como a definição de um contexto e o modelo de ação, bem como as definições de objetivos por motores de regras;
  • Diretrizes de segurança que variam ao longo da arquitetura completa.

De certa forma as arquiteturas atuais para a Internet das Coisas podem ser vistas como uma versão em maior escala do context toolkit de Anind K. Dey. O context toolkit foi projetado em um nível de aplicação, já que foi projetado para Sistemas de Informação Geográfica (GIS, na sigla em inglês). Na Internet das Coisas temos que estender o context toolkit para a intercomunicação entre coisas. No entanto, a idéia básica de objetivo, informações de contexto e ações resultantes permanece no mundo da Internet das Coisas.

No mundo da Internet das coisas nós não só definimos a meta no nível do usuário (por aplicação), mas as próprias coisas podem trabalhar em certas metas sem incluir ativamente do usuário. No final, os dispositivos ainda servem o usuário, mas eles agem de forma autónoma no fundo - que é exatamente a idéia de computação ubíqua.

De forma a obter uma melhor imagem do termo "contexto" vamos primeiro introduzir nosso modelo de contexto e, em seguida, saltar para a introdução de nossa arquitetura de referência.

Contexto define o estado de um ambiente (geralmente o ambiente do usuário) num determinado lugar e em um determinado momento. O modelo de contexto geralmente faz a distinção entre os elementos do contexto e da situação de contexto. Os elementos do contexto definem contextos específicos, geralmente no nível do dispositivo. Um elemento de contexto pode ser por exemplo um valor de temperatura num determinado momento e local.

Localização e tempo são elementos de contexto em si, mas eles desempenham um papel especial já que são necessários para localizar valores de sensores no espaço e no tempo. Afinal de contas, sem saber onde e quando a temperatura foi medida a temperatura não ajuda muito para a tomada de conclusões.

Certos elementos de contexto podem ser padronizados de imediato (por exemplo, um valor de temperatura já é definido por um valor double e uma unidade de medição, tais como graus Celsius ou Fahrenheit). Outros elementos de contexto são específicos de aplicação ("específico da coisa"), e não podem simplesmente ser padronizados imediatamente. Estes elementos são definidos como contexto "de alto nível" e requerem um mecanismo para defini-los para cada coisa.

A situação de contexto é uma agregação de elementos de contexto. A situação contexto é, portanto, uma visão sobre o ambiente em um determinado local em um determinado momento.

Como mencionado anteriormente, determinados elementos de contexto podem ser padronizados imediatamente (porque eles já são padronizados) mas outros não (porque tratam de caso de usos específicos). De forma a permitir que uma coisa saiba se ela pode realmente se comunicar com outra coisa, um certo padrão de comunicação deve ser acordado. Para este fim, apresentamos o esquema situação de contexto. O esquema situação de contexto define o que a coisa é capaz de fazer dentro de um contexto.

Você pode avançar o modelo de contexto ainda mais e definir certas "funcionalidades padrão" que devem ser introduzidas por todos e incluir funcionalidades adicionais que serão definidas para cada coisa, por exemplo, seguindo o padrão Z-Wave.

De forma similar ao modelo de contexto, também é possível definir um modelo de ação que defina o que as coisas podem ativar (por exemplo, abrir uma janela, tirar uma foto). Ações só podem ser ativadas com a combinação de informação de contexto e com objetivos definidos. Objetivos são geralmente descritos como regras de um motor de regras (por exemplo, se a temperatura for > 25º ENTÃO abra a janela). Sempre que uma situação de contexto é dado a uma coisa, a coisa avalia se uma ação deve ser acionada de acordo com seus objetivos definidos (ou seja, regras). Dependendo do caso de uso do modelo de contexto, ação e o objetivo, pode ser mais ou menos complexo para uma determinada coisa. Algumas coisas só podem consumir ações e não produzirão informações de contexto, enquanto outros vão publicar informações de contexto (ou mesmo objetivos) para serem consumidos por outras coisas.

Agora que entendemos o papel da computação contextualizada na âmbito da Internet das Coisas, podemos ir direto para a definição da nossa Arquitetura de Referência em Camadas da Internet das Coisas, ou "RILA" (da sigla em inglês, "Reference IoT Layered Architecture"). No contexto de IoC, a RILA atua entre coisas, dispositivos e o usuário, como mostrado na figura abaixo.

A RILA consiste em 6 camadas. Além dessas camadas existem duas "camadas transversais" que afetam todas as outras camadas, ou seja, "Segurança" e "Gestão".

Vamos analisar cada camada da RILA e dentro de cada componente. Iniciaremos a partir da camada inferior da pilha (camada "Integração de dispositivos") e subimos em direção ao topo.

A camada de integração de dispositivo conecta todos os diferentes tipos de dispositivos e consome as medições do dispositivo, bem como comunica ações (no nível do dispositivo). Esta camada pode ser vista como um tradutor que fala muitas línguas. A saída dos sensores e tags geradas dependem do protocolo o qual implementam. A entrada dos atuadores também são definidas pelo protocolo implementado.

A camada de integração de dispositivo é formada por três componentes principais. O componente de nível mais baixo é o componente driver que se comunica com os diferentes sensores, tags e atuadores de baixo nível, informações específicas do fornecedor e protocolos de comunicação. Ele contém instâncias do driver para cada tipo de dispositivo de nível baixo conhecido para o sistema. O próximo componente é nomeado de componente de descoberta de dispositivos. Este componente pode ser acionado por dois eventos, uma vindo da camada de gestão do dispositivo, que diz a este componente para adicionar um novo dispositivo e por outro vindo do componente driver, que notifica este componente no caso de um novo dispositivo ser adicionado. Da mesma forma o componente de descoberta de dispositivos também lida com cancelamento do registro de dispositivos. O último componente é o de comunicação do dispositivo. É a ponte entre a camada de gerenciamento de dispositivos e o driver. Este componente decide qual o driver é chamado quando a camada de gerenciamento de dispositivos trata um dispositivo.

O gerenciamento de dispositivos é responsável por tomar registros de dispositivos e medições dos sensores da camada de integração de dispositivos. Além disso, comunica mudanças de status para os atuadores da camada de integração de dispositivos. A camada de integração de dispositivos, em seguida, apenas confirma que a mudança de status (ou seja, a ação) está em conformidade com o atuador e, em seguida, traduz a alteração de status para o atuador.

A camada de gerenciamento de dispositivo controla os dispositivos de uma forma que ela saiba quais dispositivos estão conectados ao sistema. Cada modificação no registo de um dispositivo, bem como os dados de medição recebidos precisam ser comunicados da camada de integração de dispositivo para a camada de gestão do dispositivo, de modo que a informação possa ser atualizada e armazenada. Dessa forma, a camada de integração de dispositivos gere o registo do dispositivo (que inclui o enriquecimento dos metadados, como por exemplo informações sobre qual unidade ou frequência um sensor está enviando dados) e a comunicação do dispositivo (capture as medições atuais e mova para a gestão de dados, bem como passe as ações adiante para o atuador de dispositivos).

A gestão de dados pode ser vista como uma base de dados central que armazena todas as informações de uma "coisa", mas esta é apenas uma das possíveis implementações. Para coisas maiores dentro do sistema (por exemplo, um sistema de monitoramento de ciclo de vida de dispositivo que colhe de dados de outras coisas) o gerenciamento de dados pode ser um data warehouse ou até mesmo um farm de dados completo. A aplicação da camada de gerenciamento de dados depende fortemente do caso de uso específico para a coisa o qual se está trabalhando.

O gerenciamento de contexto define a lógica de negócios central dentro da RILA e é responsável por seis tarefas:

  1. Definir os objetivos da coisa;
  2. Consome as situações de contexto de outras coisas;
  3. Produz a (própria) situação de contexto da coisa;
  4. Avalia a (própria) situação de contexto em direção ao objetivo;
  5. Dispara ações que ajudem a cumprir o objetivo de acordo com as regras avaliadas;
  6. Publica situações de contexto para outras coisas.

De acordo com estas tarefas podemos dividir a gestão de contexto em oito componentes, como mostrado na figura a seguir.

Motor de Regras / Inteligência Artificial (IA): Define e gerencia todas as regras necessárias para a avaliação de contexto. Isso inclui o objetivo (que é basicamente como um conjunto de regras), bem como as regras para criar a situação de contexto e as ações.

Módulo de Integração de Situação de Contexto: escuta situações de contexto de outras coisas e integra as situações de contexto recebidas.

Módulo de Integração de Ação: ações recebidas de outras coisas são avaliadas e repassadas à camada de gerenciamento de dispositivos por esse componente. As regras precisam ser consideradas pois definem em quais situações uma ação recebida de outra coisa pode ser transmitida para disparar um atuador.

Módulo Criador de Situação de Contexto: coleta dados do sistema e constrói as situações de contexto. Isto também pode ser conduzido por regras.

Módulo Criador de Ações: similar ao Módulo Criador de Situação de Contexto, objetos de ação tem que ser criados quando acionados durante a avaliação de regras.

Módulo Publicador de Situação de Contexto: fornece situações de contexto para a camada de integração de coisas. De acordo com o nível de sofisticação da implementação, o publicador de situação de contexto pode fornecer um conjunto de situações de contexto para coisas diferentes que são assinantes dos eventos ou uma situação de contexto para todos. O Módulo Publicador de Situação de Contexto tem que cuidar de níveis de permissão de dados para outras coisas. Apenas outras coisas confiáveis devem receber informações de contexto selecionadas. Além disso, este módulo deve se encarregar de definir os esquemas de situação de contexto que são comunicados a outras coisas que desejam se inscrever para receber seus eventos. O esquema é usado para avaliar se uma coisa é capaz de se comunicar com outra coisa.

Módulo de Publicação de Ações: similar ao módulo publicador de situação de contexto este módulo é responsável por comunicar ações para a camada de integração de coisas para ser comunicado a outras coisas. Além disso, os esquemas de ação são geridos por este componente.

Módulo de Avaliação de Contexto: avalia as regras usando a situação de contexto (atual) e dispara ações que são comunicadas para os dispositivos ou para o Módulo Criador de Ação. O Módulo Criador de Ação, por sua vez, passa as ações criadas para a Publicador de Ações que comunica as ações para outras coisas. Uma forma de avaliar regras de forma simples é criar árvores de decisão a partir das regras definidas pelo mecanismo de regras.

A arquitetura concreta e a complexidade da funcionalidade oferecida dependem fortemente do caso de uso para a coisa em desenvolvimento. Especialmente o motor de regras e o componente de inteligência artificial podem não precisar ser muito sofisticados para as coisas menos inteligentes (por exemplo, um geladeira). No entanto, para coisas que coletam informações de contexto de outros sistemas estes componentes serão muito sofisticados. Um exemplo de maior sofisticação pode ser no uso em ciência de dados e técnicas de mineração dados.

A Camada de Integração de Coisas é responsável por encontrar outras coisas e se comunicar com elas.

Uma vez que duas coisas se encontram elas têm que passar por um mecanismo de registro. A Camada de Integração de Coisas precisa avaliar se é possível realizar a comunicação com a coisa que está chegando. Com esse intuito, a situação de contexto e/ou esquemas de ação tem que ser comparados. Estes são fornecidos pela Camada de Gestão de Contexto.

Se o esquema de correspondência é avaliado de forma positiva, a coisa pode notificar a outra coisa sobre a nova situação de contexto ou criação de ação. As situações e ações de contexto a serem comunicadas a outras coisas são fornecidos pela camada de gerenciamento de contexto.

O registro da coisa pode ser feita em um componente central ou pela própria coisa (por exemplo, a varredura de rede com auto-discovery).

A camada de integração de aplicativo conecta o usuário à coisa. Aplicativos que estão (diretamente) em cima da arquitetura RILA estão localizados aqui. A integração de aplicações pode ser vista como uma camada de serviço, ou até mesmo como um simples interface de usuário no topo da pilha. A implementação concreta da camada depende do caso de uso.

Neste momento concluímos a explicação sobre as camadas. Agora vamos lembrar os desafios das camadas transversais e dar uma olhada em segurança. Quando construímos um sistema de Internet das Coisas temos de considerar a segurança em todas as camadas. As fontes de ataque de ataque precisam ser identificados a fim de mapear padrões de segurança adequados.

As seguintes fontes de ataque podem ser identificados.

Usuário: O usuário final é uma possível fonte de ataque, pois pode afetar o sistema seja de propósito ou sem o seu conhecimento. Um ataque comum deste tipo é um ataque de phishing, que tenta adquirir informações confidenciais da vítima.

Interface Web: Se o aplicativo oferece uma interface web, então esta pode ser sujeita a ataques "convencionais", como injeção de SQL ou XSS. O OWASP (Open Web Application Security Project) criou uma lista dos 10 cenários de ataque mais provável contra sites.

A Coisa: Dispositivos inteligentes se comunicam muitas vezes com um sistema externo por meio de um aplicativo, que se baseia em alguma forma de sistema operacional. As duas dependências principais são o próprio app que pode não oferecer mecanismos de segurança suficientes ou o sistema operacional que pode ser invadido ou infectado.

Componentes de hardware de baixo nível: Quando consideramos componentes de hardware e a segurança que eles oferecem, devemos levar em consideração seu poder computacional. A dependência principal é representada por dispositivos de baixa potência que simplesmente não têm o poder de processamento necessário para fazer uma comunicação criptografada segura. Quando se trabalha com vários sensores, pode-se eliminar os valores discrepantes para obter uma imagem precisa, mas a segurança não pode ser alcançada. Se a exatidão dos dados fornecidos pelos sensores é essencial, então é necessário um hardware mais potente, aumentando o custo de aquisição por uma ordem de grandeza.

Canais de comunicação: proteger o canal de comunicação depende do protocolo usado. Iremos discutir os protocolos relevantes para a Internet das Coisas e o que eles oferecem para proteger a comunicação:

  • RFID e NFC: A comunicação entre a etiqueta e o leitor é sem fio e pode ser facilmente escutada. Utilizar criptografia de dados é, portanto, essencial. Os algoritmos de criptografia simétrica que hoje são considerados suficientemente seguros são 3DES e AES-128. Ao gravar dados em uma nova etiqueta, a chave de autenticação padrão deve ser alterada. A gestão de chaves para as etiquetas é feito pelo sistema que controla o leitor. As etiquetas RFID em si são muito variadas e com isto, a segurança também deve ser levada em conta quando adquiri-las. A etiqueta Mifare Plus, por exemplo, é uma atualização da etiqueta Mifare Classic, porque oferece criptografia AES-128. A etiqueta Mifare Classic usa um algoritmo proprietário com base em uma chave de 48 bits que já foi violado;
  • Zigbee: A comunicação entre um dispositivo Zigbee e a aplicação é protegida porque o algoritmo usado para criptografia é o AES-128. Por outro lado, a troca de chave inicial deve ser considerada insegura. Quando um novo dispositivo é adicionado à rede, a chave é enviada para o dispositivo na forma de texto aberto (não criptografado) e pode ser encontrada por sniffers, se o timing for correto;
  • Thread: A comunicação entre dois dispositivos Thread é protegida por uma criptografia AES. O estabelecimento de chaves entre um novo dispositivo e a aplicação é feito de forma segura usando um algoritmo de troca de chaves.

Fontes de ataque também podem ser agrupados em tipos de ataques mais técnicos que miram componentes específicos do sistemas. São eles:

  • Autenticação;
  • Autorização;
  • Validação de autenticidade: assinatura para mensagens;
  • Mecanismos de troca de chaves;
  • Encriptação;
  • Configurações - podem ser uma ameaça de segurança para configurações ruins e que sejam padrões;
  • Bibliotecas de terceiros: quando não atualizados podem conter vulnerabilidades e exploits conhecidos;
  • Segurança de rede.

O Triângulo da Segurança nos mostra o dilema de escolher a quantidade certa de segurança de acordo com nosso caso de uso.

Este triângulo de alguma forma representa um compromisso que ocorre em todos os casos de uso. Você só pode escolher um ponto no interior do triângulo que representa o que você quer ou precisa em termos de requisitos de segurança, custo e de negócios. Vejamos alguns exemplos:

  • Exemplo 1: Banco Acme constrói um cofre: É crucial usar hardware seguro para este caso de uso, que não pode ser adulterado. Para alcançar o máximo de cobertura em requisitos de negócios e de segurança, os custos vão aumentar muito.
  • Exemplo 2: O fazendeiro Billy Bob quer comprar alguns sensores novos para saber em seu smartphone como sua lavoura está indo, mas ele não precisa de um monte de segurança. Por agora, o fazendeiro Billy Bob tem seus requisitos cumpridos, teve poucos custos e pode seguir vivendo feliz. Bem, pelo menos até que o filho do fazendeiro Jimmy Junior, que foi estudar engenharia da computação se gradue...

Portanto, encontrar as medidas de segurança adequadas ao longo da arquitetura completa é sempre uma caminhada na corda bamba, uma vez que os requisitos de negócios e os custos muitas vezes se contradizem com relação às medidas de alta segurança. Além disso, pode acontecer que certos requisitos técnicos nos restrinjam de utilizar as mais altas medidas de segurança, como por exemplo dispositivos de baixa potência que não são capazes de aceitar uma certa sobrecarga ao enviar pacotes, pois isso resultaria em consumir mais energia.

Neste artigo, buscamos mostrar que é possível quebrar o mundo da Internet das Coisas em um nível mais compreensível. Técnicas de computação contextual ajudam a fazer certas partes deste mundo mais compreensíveis. Em um próximo artigo mostraremos como casos de uso podem ser derivados da arquitetura de referência RILA para fornecer um quadro mais completo sobre como a RILA pode realmente nos ajudar com a implementação de sistemas da Internet das Coisas.

Sobre os Autores

 Hannelore Marginean é desenvolvedora na Senacor Technologies, Alemanha. Entre outras atividades, gosta de descobrir tecnologias inovadoras e passou um tempo pesquisando sobre as possibilidades, os riscos de segurança e os benefícios da IoT. No seu tempo livre, ela gosta de pintura e de tocar violão.

 Daniel Karzel é consultor técnico na Senacor Technologies, Alemanha. Durante seus estudos de mestrado em computação móvel trabalhava com Computação Contextualizada e a Internet das Coisas. Além de ficar pensando sobre arquitetura de software para o futuro, em suas horas vagas, gosta de tocar acordeon e viajar pela China.

 Tuan-Si Tran é desenvolvedor na Senacor Technologies, Alemanha. É entusiasta de interfaces visuais e interessado em tecnologia de ponta. Em seu tempo livre gosta de jogar tênis.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião
BT