Arquitetura do produto da plataforma de IoT em Google Cloud

Last reviewed 2024-08-09 UTC

Normalmente, os produtos de plataformas de IoT oferecem conetividade de dados MQTT e HTTPS básica. Também lhe permitem aprovisionar dispositivos e oferecem autenticação e gestão, armazenamento e visualização de telemetria, tratamento de dados e alertas. As organizações usam frequentemente plataformas de IoT quando um agente MQTT autónomo não é suficiente para um exemplo de utilização e é necessário um produto de plataforma de IoT mais completo. Uma plataforma de IoT oferece uma interface unificada para gerir uma coleção heterogénea de dispositivos. Esta interface é importante para muitas aplicações de dispositivos ligados e é uma diferença fundamental entre uma plataforma de IoT e um agente MQTT autónomo. Este documento descreve as considerações arquitetónicas básicas e as recomendações que tem de fazer antes de implementar uma arquitetura de produto de plataforma de IoT no Google Cloud.

Este documento faz parte de uma série de documentos que fornecem informações sobre as arquiteturas de IoT no Google Cloud. Os outros documentos desta série incluem o seguinte:

O diagrama seguinte mostra um exemplo de arquitetura com um produto de plataforma de IoT genérico em execução no Google Cloud.

Uma arquitetura de plataforma de IoT genérica (fluxo de eventos explicado no texto seguinte).

Conforme mostrado no diagrama anterior, a plataforma de IoT implementa um agente MQTT ou um ponto final para a conetividade de dispositivos. A plataforma de IoT está ligada a um Network Load Balancer de proxy externo para distribuir o tráfego dos dispositivos periféricos. As aplicações de IdC adicionais podem ligar-se à plataforma de IdC através do Pub/Sub ou usando o conetor MQTT do Dataflow.

A plataforma de IoT oferece um conjunto de serviços de gestão de dispositivos. Conforme mostrado no diagrama, estes serviços são os seguintes:

  • Armazenamento de credenciais do dispositivo
  • Motor de regras
  • Autenticação e autorização do dispositivo
  • Gestão da configuração do dispositivo
  • Registo de dispositivos
  • Gestão de atualizações de dispositivos

Geralmente, os produtos de plataformas de IoT também incluem serviços como funcionalidades de gémeos digitais, interfaces de desenvolvimento de código reduzido, capacidades de alertas e notificações, e outras funcionalidades de estatísticas.

Considerações e escolhas arquitetónicas

As secções seguintes descrevem as escolhas de arquitetura que pode fazer para uma arquitetura de produto de plataforma de IoT e o impacto dessas escolhas.

Pontos finais de carregamento

A maioria das aplicações de plataformas de IoT comerciais inclui um ponto final MQTT e, normalmente, também um ponto final HTTPS para o carregamento de dados de dispositivos ligados.

MQTT

Uma plataforma de IdC implementa um ponto final MQTT de uma das seguintes formas:

  • Um conetor entre o MQTT e outro serviço de mensagens
  • Um agente MQTT que implementa a especificação MQTT completa

Quando avalia plataformas de IoT comerciais, é importante saber qual das abordagens anteriores o fornecedor escolheu para o produto, para poder determinar as implicações para o seu exemplo de utilização.

Em alguns casos, o ponto final MQTT só liga os clientes MQTT a um serviço de mensagens de back-end, como o Kafka ou o Pub/Sub. Normalmente, este tipo de ponto final não implementa a especificação completa do protocolo MQTT e, muitas vezes, não inclui funcionalidades como os níveis de QoS 1 e 2 ou subscrições partilhadas. A vantagem desta abordagem é que diminui a complexidade na plataforma de IoT, porque não existe uma aplicação de agente MQTT separada. Os custos operacionais são inferiores e a manutenção é mais simples do que se a plataforma usasse um agente MQTT separado. No entanto, devido ao suporte reduzido para funcionalidades do protocolo MQTT mais avançadas, esta abordagem significa que existe menos flexibilidade e funcionalidade para o transporte de mensagens MQTT do que um agente MQTT autónomo que implementa a especificação MQTT completa.

Outras plataformas de IoT fornecem um agente MQTT completo como parte da plataforma, conforme mostrado na arquitetura de exemplo neste documento. Este agente pode ser um dos agentes de código aberto existentes ou uma implementação de agente proprietária. Um agente MQTT completo oferece a capacidade MQTT bidirecional completa descrita anteriormente, mas um agente completo pode adicionar complexidade e custos operacionais à gestão da plataforma de IoT.

HTTPS e outros protocolos suplementares

Além do MQTT, muitas plataformas de IoT oferecem mais pontos finais de carregamento de dados do que os apresentados na arquitetura principal descrita neste documento.

O HTTPS é um protocolo alternativo comum ao MQTT para exemplos de utilização de dispositivos ligados. Tem uma sobrecarga superior à do MQTT, mas é mais amplamente suportado por dispositivos móveis, como telemóveis, e por navegadores de Internet e outras aplicações. É usado frequentemente em determinadas aplicações de dispositivos ligados e é suportado por plataformas de código aberto, como o Eclipse Hono e muitos produtos comerciais.

Muitas aplicações de dispositivos restritos usam o (protocolo de aplicação restrito [CoAP], definido na RFC 7252) como alternativa ao MQTT. O CoAP destina-se a clientes de baixa sobrecarga e pequena ocupação para dispositivos e sensores incorporados. Muitas aplicações de plataformas de IoT comerciais também fornecem um ponto final CoAP.

Balanceamento de carga

Para mais informações sobre como escolher o melhor balanceador de carga para a sua arquitetura, consulte a secção Balanceamento de carga da arquitetura de agente MQTT autónomo Google Cloud, uma vez que essas considerações também se aplicam a este caso.

Autenticação de dispositivos e gestão de credenciais

A gestão das credenciais e da autenticação dos dispositivos é uma parte fundamental do funcionamento de uma plataforma de IoT. Os métodos de autenticação suportados pelos dispositivos associados variam bastante entre as aplicações e os formatos dos dispositivos. É importante selecionar o método de autenticação adequado para o exemplo de utilização de destino e implementar corretamente o esquema de autenticação escolhido.

Ao contrário de um agente MQTT autónomo, uma plataforma de IoT fornece serviços integrados para gerir a identidade e as credenciais do dispositivo. A maioria das plataformas de IoT usa a autenticação por certificado de cliente X.509 para autenticação, a autenticação baseada em tokens JWT (frequentemente combinada com o OAuth 2.0) e a autenticação por nome de utilizador e palavra-passe. Algumas plataformas também suportam a integração com um fornecedor de autenticação LDAP externo.

Para alguns dispositivos restritos, a autenticação JWT ou de nome de utilizador e palavra-passe pode ser mais adequada, porque estes esquemas requerem menos recursos num dispositivo ligado. Quando usa a autenticação JWT ou por nome de utilizador e palavra-passe, é importante encriptar a ligação de rede separadamente da autenticação mTLS, porque nenhuma destas formas de autenticação requer uma ligação encriptada. A autenticação de certificados X.509, por outro lado, consome mais recursos no dispositivo ligado, mas é normalmente usada numa ligação encriptada com mTLS e, por isso, oferece um elevado nível de segurança.

O aprovisionamento das credenciais de autenticação no dispositivo periférico no momento da fabricação também é uma parte importante do esquema de autenticação de dispositivos ligados, mas está fora do âmbito deste documento.

Para mais informações sobre a autenticação e a gestão de credenciais, consulte o artigo Práticas recomendadas para executar um back-end de IoT no Google Cloud.

Faça a gestão dos dispositivos ligados

Normalmente, os dispositivos ligados publicam eventos de telemetria e informações de estado na plataforma através de um dos pontos finais de carregamento, como o MQTT. Se estiver a usar uma plataforma de IdC multiprotocolo, os dispositivos podem comunicar através de qualquer um dos protocolos suportados.

Recomendamos que a sua organização use uma plataforma de IoT com as seguintes capacidades:

  • Atualizações de software e do sistema: a entrega e a reversão de atualizações de firmware, software e aplicações aos dispositivos ligados. Normalmente, estas atualizações também envolvem o armazenamento e a gestão das próprias atualizações.
  • Atualizações de configuração: a entrega, o armazenamento e a reversão de atualizações à configuração de aplicações implementadas nos dispositivos ligados.
  • Criação e gestão de credenciais: a criação de novas credenciais de dispositivos, a entrega dessas credenciais ao dispositivo ligado, a auditoria das tentativas de acesso e da atividade do dispositivo, e a revogação das credenciais comprometidas ou expiradas no momento adequado.
  • Motor de regras e tratamento de dados: a definição e a execução de regras baseadas em dados e outros passos de tratamento de dados. Esta capacidade inclui frequentemente algum tipo de interface de código reduzido para definir regras e pipelines de processamento de dados.

Cargas de trabalho de back-end

A maioria das plataformas de IoT oferece as suas próprias capacidades de armazenamento e transporte de dados internos que lhe permitem estabelecer ligação às suas cargas de trabalho e aplicações de back-end. O AMQP, o RabbitMQ e o Kafka são usados frequentemente para fornecer transporte de dados interno. Todos estes podem ser ligados ao Pub/Sub através do SDK do Pub/Sub. Também pode usar um sistema de base de dados integrado, como o PostgreSQL, para armazenar dados na plataforma. Em muitos casos, a plataforma de IoT pode ser configurada para usar um dos produtos do Cloud Storage diretamente, como o Cloud SQL, o Firebase ou o BigQuery.

Se a plataforma de IoT tiver um agente MQTT completo, as aplicações de back-end também podem comunicar com os dispositivos através da capacidade MQTT da plataforma. Se a aplicação suportar MQTT, pode estabelecer ligação ao agente como subscritor. Se não existir suporte para MQTT, o Apache Beam fornece um controlador MQTT, que permite a integração bidirecional com o Dataflow, bem como outras implementações do Beam.

Exemplos de utilização

As secções seguintes descrevem cenários de exemplo em que uma plataforma de IoT é uma melhor escolha de arquitetura do que um agente MQTT autónomo ou uma ligação direta ao Pub/Sub.

Gestão de eletrodomésticos inteligentes

As aplicações que gerem vários eletrodomésticos inteligentes são adequadas para uma plataforma de IdC. Um exemplo de uma aplicação deste tipo é uma plataforma para gerir eletrodomésticos de cozinha, como máquinas de lavar louça e máquinas de café. Geralmente, estes dispositivos ligam-se a uma aplicação baseada na nuvem, diretamente através de Wi-Fi ou através de um gateway local que usa um Bluetooth Low Energy (BLE) ou outro protocolo local. As capacidades de gestão de uma plataforma de IoT são importantes aqui para monitorizar o estado de cada dispositivo, gerir atualizações de software e patches de segurança, e captar a atividade do dispositivo para fornecer informações críticas ao fabricante e ao cliente. Estas capacidades estão fora do âmbito de um agente MQTT básico. No mínimo, um repositório de informações do dispositivo, uma base de dados do estado do dispositivo, um armazenamento de dados de telemetria e uma interface de estatísticas são essenciais para criar uma plataforma de eletrodomésticos inteligentes bem-sucedida.

Logística e monitorização de recursos

Para uma aplicação de logística e acompanhamento de recursos, um produto de plataforma de IoT oferece uma funcionalidade mais completa do que um agente MQTT básico, pelo que é uma melhor escolha para este exemplo de utilização. A monitorização do estado e da localização atuais e anteriores de uma grande frota de recursos depende de uma base de dados de estado do dispositivo robusta e de um sistema de gestão de identidades. À medida que são implementados novos recursos, estes têm de ser ligados à plataforma com o mínimo de atrito possível e, posteriormente, monitorizados ao longo do ciclo de vida do recurso. Em muitos casos, a aplicação também recolhe outras informações de sensores sobre o recurso, como a temperatura local, a humidade e a pressão atmosférica, ou dados de posicionamento e aceleração 3D para detetar movimentos ou quedas inesperados. Todos estes dados têm de ser carregados e associados ao recurso correto para análise em qualquer aplicação de back-end. Por isso, a gestão de dispositivos com todas as funcionalidades fornecida pela plataforma de IdC é uma capacidade importante.

O que se segue?