Arquitetura de produto da plataforma de IoT no Google Cloud

Last reviewed 2024-08-09 UTC

Os produtos da plataforma de IoT geralmente oferecem conectividade de dados MQTT e HTTPS básica. Eles também permitem provisionar dispositivos e fornecem autenticação e gerenciamento, armazenamento e visualização de telemetria, processamento de dados e alertas. As organizações geralmente usam plataformas de IoT quando um agente do MQTT autônomo não é suficiente para um caso de uso e um produto de plataforma de IoT mais completo é necessário. Uma plataforma de IoT oferece uma interface unificada para gerenciar uma coleção heterogênea de dispositivos. Essa interface é importante para muitos aplicativos de dispositivos conectados e é uma diferença fundamental entre uma plataforma de IoT e um agente MQTT autônomo. Neste documento, descrevemos as considerações básicas e as recomendações arquitetônicas que você precisa fazer antes de implantar uma arquitetura de produto da plataforma IoT no Google Cloud.

Este documento faz parte de uma série de documentos que apresentam informações sobre Arquiteturas de IoT no Google Cloud. Os outros documentos desta série incluem:

O diagrama a seguir mostra um exemplo de arquitetura com uma plataforma de IoT genérica produto em execução no Google Cloud.

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

Conforme mostrado no diagrama anterior, a plataforma de IoT implanta um agente ou endpoint do MQTT para conectividade do dispositivo. A plataforma de IoT está conectada a um balanceador de carga de rede de proxy externo para distribuir o tráfego dos dispositivos de borda. Outros aplicativos de IoT podem se conectar à plataforma por meio do Pub/Sub ou do conector MQTT do Dataflow.

A plataforma IoT fornece um conjunto de serviços de gerenciamento de dispositivos. Conforme mostrado no diagrama, esses serviços são os seguintes:

  • Armazenamento de credenciais do dispositivo
  • Mecanismos de regras
  • Autenticação e autorização do dispositivo
  • Gerenciamento de configuração do dispositivo
  • Registro de dispositivos
  • Gerenciamento de atualização do dispositivo

Os produtos da plataforma de IoT também incluem serviços como recursos gêmeos digitais, interfaces de desenvolvimento com pouco código, recursos de alerta e notificação e outras funcionalidades de análise.

Considerações e escolhas sobre arquitetura

As seções a seguir descrevem as opções de arquitetura que podem ser feitas para uma arquitetura de produto da plataforma de IoT e o impacto dessas escolhas.

Endpoints de ingestão

A maioria dos aplicativos comerciais de plataformas de IoT inclui um endpoint MQTT e, geralmente, um endpoint HTTPS para ingestão de dados de dispositivos conectados.

MQTT

Uma plataforma de IoT implementa um endpoint MQTT de uma das seguintes maneiras:

  • Um conector entre o MQTT e outro serviço de mensagens
  • Um corretor MQTT que implementa a especificação completa do MQTT

Ao avaliar as plataformas de IoT comerciais, é importante saber quais das abordagens anteriores o fornecedor escolheu para que você possa determinar as implicações para seu caso de uso.

Em alguns casos, o endpoint MQTT conecta apenas os clientes MQTT a um serviço de mensagens de back-end, como Kafka ou Pub/Sub. Esse tipo de endpoint geralmente não implementa a especificação completa do protocolo MQTT e geralmente não inclui recursos como os níveis de QoS 1 e 2 ou assinaturas compartilhadas. A vantagem dessa abordagem é que ela diminui a complexidade da plataforma IoT, porque não há um aplicativo agente MQTT separado. Os custos operacionais são mais baixos, e a manutenção é mais simples do que se a plataforma usasse um agente MQTT separado. No entanto, devido à compatibilidade reduzida para recursos mais avançados do protocolo MQTT, essa abordagem significa que há menos flexibilidade e funcionalidade para o transporte de mensagens MQTT do que um agente MQTT autônomo que implementa a especificação completa do MQTT.

Outras plataformas de IoT oferecem um agente MQTT completo como parte da plataforma, conforme mostrado no exemplo de arquitetura neste documento. Esse agente pode ser um dos agentes de código aberto existentes ou uma implementação proprietária de intermediário. Um agente MQTT completo fornece o recurso MQTT bidirecional completo descrito anteriormente, mas um agente completo pode aumentar a complexidade e os custos operacionais do gerenciamento da plataforma IoT.

HTTPS e outros protocolos complementares

Além do MQTT, muitas plataformas de IoT oferecem mais endpoints de ingestão de dados do que os que são mostrados na arquitetura principal descrita neste documento.

O HTTPS é um protocolo alternativo comum para MQTT em casos de uso de dispositivos conectados. Ele tem mais sobrecarga do que o MQTT, mas é mais amplamente compatível com dispositivos móveis, como smartphones, navegadores da Web e outros aplicativos. Ele é usado com frequência em determinados aplicativos de dispositivos conectados e é compatível com plataformas de código aberto como Eclipse Hono e muitos produtos comerciais.

Muitos aplicativos de dispositivos restritos usam (Protocolo de aplicativo restrito (CoAP), definido na RFC 7252) como uma alternativa MQTT. O CoAP é destinado a clientes de baixa sobrecarga e ppequenos para dispositivos e sensores incorporados. Muitos aplicativos de plataforma comercial de IoT também fornecem um endpoint CoAP.

Balanceamento de carga

Para mais informações sobre como escolher o melhor balanceador de carga para sua arquitetura, consulte a seção de balanceamento de carga da arquitetura de agente MQTT autônomo no Google Cloud, porque essas considerações também são aplicáveis a esse caso.

Autenticação de dispositivos e gerenciamento de credenciais

O gerenciamento de credenciais e autenticação do dispositivo é uma parte essencial da operação de uma plataforma de IoT. Os métodos de autenticação com suporte nos dispositivos conectados variam muito entre aplicativos e formatos. É importante selecionar o método de autenticação adequado para o caso de uso de destino e implementar corretamente o esquema de autenticação.

Ao contrário de um agente MQTT autônomo, uma plataforma de IoT fornece serviços integrados para gerenciar a identidade e as credenciais do dispositivo. A maioria das plataformas de IoT usa autenticação X.509 de certificado do cliente para autenticação, autenticação baseada em token JWT (geralmente combinada com OAuth 2.0) e autenticação por nome de usuário e senha. Algumas plataformas também oferecem suporte à integração com um provedor de autenticação LDAP externo.

Para alguns dispositivos restritos, o JWT ou a autenticação por nome de usuário e senha podem ser mais apropriados, porque esses esquemas exigem menos recursos em um dispositivo conectado. Ao usar o JWT ou a autenticação por nome de usuário e senha, é importante criptografar a conexão de rede separadamente para a autenticação mTLS, porque uma conexão criptografada não é exigida por nenhum desses métodos de autenticação. A autenticação por certificado X.509, por outro lado, consome mais recursos no dispositivo conectado, mas normalmente é usada em uma conexão criptografada com mTLS e, assim, oferece um alto nível de segurança.

O provisionamento das credenciais de autenticação no dispositivo de borda no momento da fabricação também é uma parte importante do esquema de autenticação de dispositivos conectados, mas está fora do escopo deste documento.

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

Gerenciar dispositivos conectados

Normalmente, dispositivos conectados publicam eventos de telemetria e informações de estado na plataforma por meio de um dos endpoints de ingestão, como MQTT. Se você estiver usando uma plataforma de IoT com vários protocolos, os dispositivos poderão se comunicar usando qualquer um dos protocolos compatíveis.

Recomendamos que sua organização use uma plataforma de IoT que tenha os seguintes recursos:

  • Atualizações de software e sistema:a entrega e a reversão de atualizações de firmware, software e aplicativos para os dispositivos conectados. Essas atualizações geralmente envolvem armazenamento e gerenciamento das próprias atualizações.
  • Atualizações de configuração: a entrega, o armazenamento e a reversão de atualizações na configuração de aplicativos implantados nos dispositivos conectados.
  • Criação e gerenciamento de credenciais: a criação de novas credenciais do dispositivo, a entrega delas ao dispositivo conectado, a auditoria de tentativas de acesso e a atividade do dispositivo e a revogação de credenciais comprometidas ou credenciais expiradas no momento apropriado.
  • Mecanismo de regras e processamento de dados:a definição e a execução de regras baseadas em dados e outras etapas de processamento de dados. Esse recurso geralmente inclui algum tipo de interface de baixo código para definir regras e pipelines de processamento de dados.

Cargas de trabalho de back-end

A maioria das plataformas de IoT fornece os próprios recursos internos de armazenamento e transporte de dados que permitem a conexão com suas cargas de trabalho e aplicativos de back-end. AMQP, RabbitMQ e Kafka são normalmente usados para fornecer transporte de dados interno. Todos eles podem ser conectados ao Pub/Sub usando o SDK do Pub/Sub. Também é possível usar um sistema de banco 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 Cloud SQL, Firebase ou BigQuery.

Se a plataforma de IoT tiver um agente MQTT completo, os aplicativos de back-end também poderão se comunicar com dispositivos usando o recurso MQTT da plataforma. Se o aplicativo for compatível com MQTT, ele poderá se conectar com o agente como um assinante. Se não houver suporte para MQTT, o Apache Beam fornece um driver MQTT, que permite a integração bidirecional com o Dataflow, bem como outras implantações do Beam.

Casos de uso

As seções a seguir descrevem cenários de exemplo em que uma plataforma de IoT é uma opção de arquitetura melhor do que um agente MQTT autônomo ou uma conexão direta com o Pub/Sub.

Gerenciamento de eletrodomésticos inteligentes

Os aplicativos que gerenciam vários dispositivos inteligentes são adequados para uma plataforma de IoT. Um exemplo desse tipo de aplicativo é uma plataforma para gerenciar eletrodomésticos para cozinha, como lava-louças e cafeteiras. Esses dispositivos geralmente se conectam a um aplicativo baseado na nuvem diretamente pelo Wi-Fi ou por um gateway local que usa um Bluetooth de baixa energia (BLE) ou outro protocolo local. Os recursos de gerenciamento de uma plataforma de IoT são importantes aqui para monitorar o estado de cada dispositivo, gerenciar atualizações de software e patches de segurança e capturar a atividade do dispositivo para fornecer inteligência crítica ao fabricante e ao cliente. Esses recursos estão além do escopo de um agente MQTT básico. No mínimo, um repositório de informações, um banco de dados de estado do dispositivo, um repositório de dados de telemetria e uma interface de análise são essenciais para criar uma plataforma de dispositivo inteligente bem-sucedida.

Logística e acompanhamento de ativos

Para um aplicativo de logística e rastreamento de recursos, um produto da plataforma de IoT oferece uma funcionalidade mais completa do que um agente básico do MQTT. Portanto, é uma escolha melhor para esse caso de uso. O monitoramento do estado e do local atuais e antigos de uma grande frota de recursos depende de um banco de dados de estado de dispositivo e de um sistema de gerenciamento de identidade robustos. À medida que novos recursos são implantados, eles precisam estar conectados à plataforma com o mínimo de atrito possível e, em seguida, monitorados durante o ciclo de vida do recurso. Em muitos casos, o aplicativo também coleta outras informações do sensor sobre o recurso, como temperatura local, umidade e pressão atmosférica ou dados de aceleração e posicionamento 3D para detectar movimentos ou quedas inesperados. Todos esses dados precisam ser ingeridos e associados ao recurso correto para análise em qualquer aplicativo de back-end. Portanto, o gerenciamento de dispositivos com todos os recursos fornecido pela plataforma de IoT é uma capacidade importante.

A seguir