Arquiteturas de dispositivos conectados no Google Cloud
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Last reviewed 2024-09-09 UTC
Para maximizar o valor dos dados dos dispositivos conectados, as organizações precisam
fazer análises de dados. Há muitas maneiras de as organizações
conectarem os dispositivos a aplicativos de análise, e os benefícios de
arquiteturas de dispositivos conectados específicas podem variar dependendo do caso de uso da
sua organização. Para ajudar você a se orientar, este documento descreve um conjunto de arquiteturas de dispositivos
conectados no Google Cloud. Essas arquiteturas abordam uma ampla variedade de casos de uso e requisitos para dispositivos conectados.
Este documento faz parte de uma série de documentos que fornecem informações sobre
arquiteturas de IoT no Google Cloud. Os outros documentos desta série
incluem:
Visão geral das arquiteturas de dispositivos conectados no Google Cloud (este documento).
Um agente MQTT autônomo:
um agente
MQTT
oferece comunicação bidirecional entre dispositivos conectados e
Google Cloud projetos, e entre os dispositivos.
Uma arquitetura de plataforma de IoT no Google Cloud:uma
plataforma de IoT oferece outros recursos de gerenciamento de dispositivos, além da
conectividade de dados, que é importante para a implantação de uma grande frota de
dispositivos conectados.
Uma conexão direta com o Pub/Sub: para ingestão de dados, a
melhor opção pode ser para seus dispositivos se conectarem diretamente ao Pub/Sub.
Resumo das arquiteturas de dispositivos conectados
Este documento agrupa os casos de uso de dispositivos conectados em três categorias, com base nas seguintes dimensões que você precisa considerar ao planejar uma
arquitetura de dispositivo conectado:
Número de dispositivos: é importante considerar quantos dispositivos estão
conectados diretamente ao aplicativo. Se o aplicativo tiver muitos dispositivos
finais (como máquinas, sensores ou câmeras) e esses dispositivos estiverem conectados
a um gateway intermediário ou outro dispositivo (como um smartphone),
é importante identificar se esses dispositivos finais precisam ser representados e
gerenciados no aplicativo. Em alguns casos, é necessário representar cada
dispositivo individual. Em outros casos, apenas o dispositivo intermediário
precisa ser representado.
Gerenciamento de frotas: considere se você precisa de recursos como
monitoramento de status do dispositivo, atualizações de software e firmware, gerenciamento de
configurações e outros recursos de gerenciamento de frotas. Esses requisitos
ajudam a determinar sua escolha da arquitetura de aplicativo.
Mensagens entre dispositivos: a comunicação do dispositivo pela
arquitetura do aplicativo é um fator importante. Por exemplo, alguns
aplicativos dependem da comunicação entre os dispositivos conectados usando
a arquitetura do seu aplicativo. Outros aplicativos têm fluxos de dados que
ocorrem estritamente entre cada dispositivo e o aplicativo, sem mensagens
entre dispositivos.
Tabela de resumo
Entender as características do seu aplicativo pode ajudar você a escolher
a melhor arquitetura para seu caso de uso. Para ajudar a orientar sua escolha, a
tabela a seguir resume a compatibilidade de cada uma das arquiteturas conectadas
descritas nesta série:
Limites de compatibilidade com dispositivos
Mensagens entre dispositivos
Compatibilidade com gerenciamento de frotas
Agente do MQTT
Milhões
Recomendações
Sem suporte
Plataforma de IoT
Milhões
Compatibilidade parcial
Recomendações
Dispositivo para Pub/Sub
Centenas
Compatibilidade parcial
Sem suporte
A seguir
Leia sobre a melhor arquitetura de dispositivo conectado para seu caso de uso:
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2024-09-09 UTC."],[[["\u003cp\u003eOrganizations need data analysis to maximize the value of data from connected devices, and there are various ways to connect these devices to analytics applications.\u003c/p\u003e\n"],["\u003cp\u003eThis document outlines several connected device architectures on Google Cloud, addressing a variety of use cases and requirements.\u003c/p\u003e\n"],["\u003cp\u003eKey considerations when planning a connected device architecture include the number of devices, the necessity of fleet management, and the need for inter-device messaging.\u003c/p\u003e\n"],["\u003cp\u003eThe document classifies connected device use cases into three categories, considering the number of devices, fleet management needs, and inter-device communication requirements.\u003c/p\u003e\n"],["\u003cp\u003eThe document provides a summary table that compares connected architectures: MQTT Broker, IoT Platform, and device to Pub/Sub, highlighting their support for device limits, inter-device messaging, and fleet management.\u003c/p\u003e\n"]]],[],null,["# Connected device architectures on Google Cloud\n\nTo maximize the value of data from their connected devices, organizations need\nto be able to perform data analysis. There are many ways for organizations to\nconnect their devices to their analytics applications, and the benefits of\nspecific connected device architectures can vary depending on the use case of\nyour organization. To help guide you, this document describes a set of connected\ndevice architectures on Google Cloud. These architectures address a broad\nrange of use cases and requirements for connected devices.\n\nThis document is part of a series of documents that provide information about\nIoT architectures on Google Cloud. The other documents in this series\ninclude the following:\n\n- Connected device architectures on Google Cloud overview (this document).\n- [A standalone MQTT Broker](/architecture/connected-devices/mqtt-broker-architecture): An [MQTT](https://mqtt.org/) broker provides bidirectional communication between connected devices and Google Cloud projects, and between the devices.\n- [An IoT platform architecture on Google Cloud:](/architecture/connected-devices/iot-platform-product-architecture) An IoT platform provides additional device management capabilities along with data connectivity, which is important when you deploy a large fleet of connected devices.\n- [A direct connection to Pub/Sub](/architecture/connected-devices/device-pubsub-architecture): For data ingestion, the best choice might be for your devices to connect directly to Pub/Sub.\n- [Best practices for running an IoT backend on Google Cloud](/architecture/connected-devices/bps-running-iot-backend-securely).\n- [Best practices for automatically provisioning and configuring edge and bare metal systems and servers](/architecture/connected-devices/best-practices-provisioning-configuring-bare-metal).\n\nConnected device architectures summary\n--------------------------------------\n\nThis document groups connected device use cases into three categories, based on the following dimensions that you need to consider when you plan a\nconnected device architecture:\n\n- **Number of devices:** It's important to consider how many devices are\n directly connected to your application. If your application has many end\n devices (such as machines, sensors, or cameras), and if these devices are connected\n to an intermediate gateway or other device (such as a mobile phone),\n it's important to identify whether those end devices must be represented and\n managed in your application. In some cases you might need to represent each\n individual device; in other cases, only the intermediate device might\n need to be represented.\n\n- **Fleet management:** Consider whether you need capabilities like\n device status monitoring, software and firmware updates, configuration\n management, and other fleet management features. These requirements\n help to determine your choice of application architecture.\n\n- **Inter-device messaging:** Device communication through your\n application architecture is an important factor. For example, some\n applications depend on communication between the connected devices through\n your application architecture. Other applications have data flows that\n occur strictly between each device and your application, with no messaging\n between devices.\n\nSummary table\n-------------\n\nUnderstanding the characteristics of your application can help you to choose\nthe best architecture for your use case. To help guide your choice, the\nfollowing table summarizes the support that each of the connected architectures\nthat are described in this series offers:\n\nWhat's next\n-----------\n\n- Read about the best connected device architecture for your use case:\n - [A standalone MQTT Broker](/architecture/connected-devices/mqtt-broker-architecture):\n - [An IoT platform architecture on Google Cloud](/architecture/connected-devices/iot-platform-product-architecture).\n - [A direct connection to Pub/Sub](/architecture/connected-devices/device-pubsub-architecture).\n- Learn how to connect devices and build IoT applications on Google Cloud using [Intelligent Products Essentials](/architecture/intelligent-products-essentials-architecture).\n- Learn about practices for [automatically provisioning and configuring edge and\n bare metal systems and servers](/architecture/best-practices-provisioning-configuring-bare-metal).\n- For more reference architectures, diagrams, and best practices, explore the [Cloud Architecture Center](/architecture)."]]
