Arquitectura de productos de la plataforma de IoT en Google Cloud

Last reviewed 2024-08-09 UTC

Por lo general, los productos de plataformas de IoT proporcionan conectividad básica de datos a través de MQTT y HTTPS. También te permiten aprovisionar dispositivos y proporcionan autenticación y administración, almacenamiento y visualización de telemetría, procesamiento de datos y alertas. Las organizaciones suelen usar plataformas de IoT cuando un agente de MQTT independiente no es suficiente para un caso de uso y se necesita un producto de plataforma de IoT más completo. Una plataforma de IoT proporciona una interfaz unificada para administrar una colección heterogénea de dispositivos. Esta interfaz es importante para muchas aplicaciones de dispositivos conectados y es una diferencia clave entre una plataforma de IoT y un agente de MQTT independiente. En este documento, se describen las consideraciones básicas de la arquitectura y las recomendaciones que debes realizar antes de implementar una arquitectura de productos de la plataforma de IoT en Google Cloud.

Este documento forma parte de una serie de documentos que proporcionan información sobre las arquitecturas de IoT en Google Cloud. Los otros documentos de esta serie incluyen lo siguiente:

En el siguiente diagrama, se muestra un ejemplo de la arquitectura con un producto genérico de plataforma de IoT que se ejecuta en Google Cloud.

Una arquitectura genérica de plataforma de IoT (flujo de eventos que se explica en el siguiente texto).

Como se muestra en el diagrama anterior, la plataforma de IoT implementa un agente o un extremo de MQTT para la conectividad de los dispositivos. La plataforma de IoT está conectada a un balanceador de cargas de red de proxy externo para distribuir el tráfico de los dispositivos perimetrales. Se pueden conectar aplicaciones de IoT adicionales a la plataforma de IoT a través de Pub/Sub o con el conector de MQTT de Dataflow.

La plataforma IoT proporciona un conjunto de servicios de administración de dispositivos. Como se muestra en el diagrama, estos servicios son los siguientes:

  • Almacén de credenciales del dispositivo
  • Motor de reglas
  • Autenticación y autorización de dispositivos
  • Administración de la configuración del dispositivo
  • Registro de dispositivos
  • Administración de actualizaciones de dispositivos

Por lo general, los productos de la plataforma de IoT también incluyen servicios como funciones de gemelo digital, interfaces de desarrollo con poco código, capacidades de alertas y notificaciones, y otras funciones de análisis.

Consideraciones y elecciones de arquitectura

En las siguientes secciones, se describen las opciones de arquitectura que puedes tomar para la arquitectura de un producto de la plataforma de IoT y el impacto de estas opciones.

Extremos de transferencia

La mayoría de las aplicaciones de plataformas de IoT comerciales incluyen un extremo MQTT y, por lo general, también un extremo HTTPS para la transferencia de datos desde dispositivos conectados.

MQTT

Una plataforma de IoT implementa un extremo de MQTT de una de las siguientes maneras:

  • Un conector entre MQTT y otro servicio de mensajería
  • Un agente de MQTT que implementa la especificación completa de MQTT

Cuando evalúas plataformas comerciales de IoT, es importante saber cuál de los enfoques anteriores eligió el proveedor para el producto, de modo que puedas determinar las implicaciones para tu caso de uso.

En algunos casos, el extremo de MQTT solo conecta los clientes de MQTT con un servicio de mensajería de backend, como Kafka o Pub/Sub. Por lo general, este tipo de extremo no implementa la especificación completa del protocolo MQTT y, a menudo, no incluye funciones como los niveles de QoS 1 y 2, o las suscripciones compartidas. La ventaja de este enfoque es que disminuye la complejidad de la plataforma de IoT, ya que no hay una aplicación de agente de MQTT independiente. Los costos operativos son más bajos y el mantenimiento es más simple que si la plataforma usa un agente de MQTT independiente. Sin embargo, debido a la menor compatibilidad con las funciones más avanzadas del protocolo MQTT, este enfoque implica que hay menos flexibilidad y funcionalidad para el transporte de mensajes MQTT que un agente de MQTT independiente que implementa la especificación completa de MQTT.

Otras plataformas de IoT proporcionan un agente de MQTT completo como parte de la plataforma, como se muestra en la arquitectura de ejemplo de este documento. Este agente puede ser uno de los agentes de código abierto existentes o una implementación de agente propietario. Un agente de MQTT completo proporciona la capacidad bidireccional completa de MQTT que se describió anteriormente, pero puede agregar complejidad y costos operativos a la administración de la plataforma de IoT.

HTTPS y otros protocolos complementarios

Además de MQTT, muchas plataformas de IoT proporcionan más extremos de transferencia de datos de los que se muestran en la arquitectura principal que describe este documento.

HTTPS es un protocolo alternativo común a MQTT para casos de uso de dispositivos conectados. Tiene una sobrecarga más alta que MQTT, pero es más compatible con dispositivos móviles, como teléfonos, navegadores web y otras aplicaciones. Se usa con frecuencia en ciertas aplicaciones de dispositivos conectados y es compatible con plataformas de código abierto, como Eclipse Hono y muchos productos comerciales.

Muchas aplicaciones de dispositivos restringidos usan el Protocolo de aplicación restringida (CoAP), definido en el RFC 7252, como alternativa a MQTT. CoAP se orienta a clientes con una sobrecarga baja y una huella pequeña para sensores y dispositivos integrados. Muchas aplicaciones de plataformas de IoT comerciales también proporcionan un extremo de CoAP.

Balanceo de cargas

Si deseas obtener más información para elegir el mejor balanceador de cargas para tu arquitectura, consulta la sección de balanceo de cargas de la arquitectura del agente de MQTT independiente en Google Cloud, ya que esas consideraciones también se aplican a este caso.

Administración de credenciales y autenticación de dispositivos

La administración de las credenciales y la autenticación de dispositivos es una parte clave del funcionamiento de una plataforma de IoT. Los métodos de autenticación admitidos por los dispositivos conectados varían mucho según las aplicaciones y los factores de forma de los dispositivos. Es importante seleccionar el método de autenticación adecuado para el caso de uso objetivo y, luego, implementar el esquema de autenticación elegido correctamente.

A diferencia de un agente de MQTT independiente, una plataforma de IoT proporciona servicios integrados para administrar la identidad y las credenciales de los dispositivos. La mayoría de las plataformas de IoT usan la autenticación de certificados de cliente X.509, la autenticación basada en tokens JWT (a menudo combinada con OAuth 2.0) y la autenticación con nombre de usuario y contraseña. Algunas plataformas también admiten la integración con un proveedor de autenticación LDAP externo.

Para algunos dispositivos con limitaciones, la autenticación con JWT o nombre de usuario y contraseña podría ser más adecuada, ya que estos esquemas requieren menos recursos en un dispositivo conectado. Cuando usas la autenticación con JWT o con nombre de usuario y contraseña, es importante que encriptes la conexión de red por separado de la autenticación con mTLS, ya que ninguno de estos métodos de autenticación requiere una conexión encriptada. En cambio, la autenticación de certificados X.509 consume más recursos en el dispositivo conectado, pero se suele usar en una conexión encriptada con mTLS y, por lo tanto, proporciona un alto nivel de seguridad.

El aprovisionamiento de las credenciales de autenticación en el dispositivo perimetral durante la fabricación también es una parte importante del esquema de autenticación de dispositivos conectados, pero está fuera del alcance de este documento.

Para obtener más información sobre la autenticación y la administración de credenciales, consulta Prácticas recomendadas para ejecutar un backend de IoT en Google Cloud.

Administrar dispositivos conectados

Por lo general, los dispositivos conectados publican eventos de telemetría y la información de estado en la plataforma a través de uno de los extremos de transferencia, como MQTT. Si usas una plataforma de IoT multiprotocolo, los dispositivos pueden comunicarse con cualquiera de los protocolos admitidos.

Te recomendamos que tu organización use una plataforma de IoT que tenga las siguientes capacidades:

  • Actualizaciones de software y del sistema: Se refiere a la entrega y la reversión de actualizaciones de firmware, software y aplicaciones a los dispositivos conectados. Por lo general, estas actualizaciones también implican el almacenamiento y la administración de las actualizaciones en sí.
  • Actualizaciones de configuración: Entrega, almacenamiento y reversión de actualizaciones a la configuración de las aplicaciones implementadas en los dispositivos conectados
  • Creación y administración de credenciales: La creación de credenciales de dispositivos nuevos, la entrega de esas credenciales al dispositivo conectado, la auditoría de los intentos de acceso y la actividad del dispositivo, y la revocación de las credenciales vencidas o vulneradas en el momento adecuado.
  • Motor de reglas y procesamiento de datos: Definición y ejecución de reglas basadas en datos y otros pasos de procesamiento de datos Esta capacidad suele incluir algún tipo de interfaz con poco código para definir reglas y canalizaciones de procesamiento de datos.

Cargas de trabajo de backend

La mayoría de las plataformas de IoT proporcionan sus propias capacidades internas de almacenamiento y transporte de datos que te permiten conectarte a tus cargas de trabajo y aplicaciones de backend. AMQP, RabbitMQ y Kafka se usan comúnmente para proporcionar transporte interno de datos. Todos estos se pueden conectar a Pub/Sub con el SDK de Pub/Sub. También puedes usar un sistema de base de datos integrado, como PostgreSQL, para almacenar datos en la plataforma. En muchos casos, la plataforma de IoT se puede configurar para usar uno de los productos de Cloud Storage directamente, como Cloud SQL, Firebase o BigQuery.

Si la plataforma de IoT tiene un agente de MQTT completo, las aplicaciones de backend también pueden comunicarse con los dispositivos usando la capacidad de MQTT de la plataforma. Si la aplicación admite MQTT, puede conectarse con el agente como suscriptor. Si no hay compatibilidad con MQTT, Apache Beam proporciona un controlador de MQTT, que permite la integración bidireccional con Dataflow y otras implementaciones de Beam.

Casos de uso

En las siguientes secciones, se describen situaciones de ejemplo en las que una plataforma de IoT es una mejor opción de arquitectura que un agente de MQTT independiente o una conexión directa a Pub/Sub.

Administración de electrodomésticos inteligentes

Las aplicaciones que administran varios electrodomésticos inteligentes son adecuadas para una plataforma de IoT. Un ejemplo de este tipo de aplicación es una plataforma para administrar electrodomésticos de cocina, como lavavajillas y cafeteras. Por lo general, estos dispositivos se conectan a una aplicación basada en la nube, ya sea directamente a través de Wi-Fi o a través de una puerta de enlace local que usa Bluetooth de bajo consumo (BLE) o algún otro protocolo local. Las capacidades de administración de una plataforma de IoT son importantes aquí para supervisar el estado de cada dispositivo, administrar las actualizaciones de software y los parches de seguridad, y capturar la actividad del dispositivo para proporcionar información crítica al fabricante y al cliente. Estas capacidades van más allá de las de un agente de MQTT básico. Como mínimo, un repositorio de información del dispositivo, una base de datos de estado del dispositivo, un almacén de datos de telemetría y una interfaz de análisis son fundamentales para crear una plataforma de electrodomésticos inteligentes exitosa.

Logística y seguimiento de activos

Para una aplicación de seguimiento de activos y logística, un producto de plataforma de IoT ofrece una funcionalidad más completa que un agente de MQTT básico, por lo que es una mejor opción para este caso de uso. Supervisar el estado y la ubicación actuales y anteriores de una gran flota de activos depende de una sólida base de datos de estado de dispositivos y de un sistema de administración de identidades. A medida que se implementan nuevos recursos, deben conectarse a la plataforma con la menor fricción posible y, luego, supervisarse durante todo el ciclo de vida del recurso. En muchos casos, la aplicación también recopila otra información de los sensores sobre el activo, como la temperatura local, la humedad y la presión atmosférica, o datos de posicionamiento y aceleración en 3D para detectar movimientos o caídas inesperados. Todos estos datos deben transferirse y asociarse con el activo correcto para su análisis en cualquier aplicación de backend, por lo que la administración de dispositivos con todas las funciones que proporciona la plataforma de IoT es una capacidad importante.

¿Qué sigue?