Arquitectura de producto de la plataforma de IoT en Google Cloud

Last reviewed 2024-08-09 UTC

Los productos de plataformas de IoT suelen ofrecer conectividad de datos básica mediante MQTT y HTTPS. También te permiten aprovisionar dispositivos y proporcionan autenticación y gestión, almacenamiento y visualización de telemetría, procesamiento de datos y alertas. Las organizaciones suelen usar plataformas de IoT cuando un broker de MQTT independiente no es suficiente para un caso práctico y se necesita un producto de plataforma de IoT más completo. Una plataforma de IoT proporciona una interfaz unificada para gestionar 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 broker MQTT independiente. En este documento se describen las consideraciones y recomendaciones básicas sobre la arquitectura que debes tener en cuenta antes de implementar una arquitectura de producto de 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 arquitectura con un producto de plataforma de IoT genérico que se ejecuta en Google Cloud.

Arquitectura de una plataforma de IoT genérica (el flujo de eventos se explica en el texto siguiente).

Como se muestra en el diagrama anterior, la plataforma de IoT implementa un broker o un endpoint MQTT para la conectividad de los dispositivos. La plataforma de IoT está conectada a un balanceador de carga 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 mediante el conector MQTT de Dataflow.

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

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

Los productos de plataformas de IoT también suelen incluir servicios como funciones de gemelo digital, interfaces de desarrollo de low-code, funciones de alertas y notificaciones, y otras funciones analíticas.

Consideraciones y opciones de arquitectura

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

Endpoints de ingestión

La mayoría de las aplicaciones de plataformas de IoT comerciales incluyen un endpoint MQTT y, normalmente, también un endpoint HTTPS para la ingestión de datos de dispositivos conectados.

MQTT

Una plataforma de IoT implementa un endpoint MQTT de una de las siguientes formas:

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

Cuando evalúe plataformas de IoT comerciales, es importante que sepa cuál de los enfoques anteriores ha elegido el proveedor para el producto, de modo que pueda determinar las implicaciones para su caso práctico.

En algunos casos, el endpoint MQTT solo conecta los clientes MQTT con un servicio de mensajería backend, como Kafka o Pub/Sub. Este tipo de endpoint no suele implementar la especificación completa del protocolo MQTT y, a menudo, no incluye funciones como los niveles de QoS 1 y 2, ni las suscripciones compartidas. La ventaja de este enfoque es que reduce la complejidad de la plataforma de IoT, ya que no hay una aplicación de broker MQTT independiente. Los costes operativos son más bajos y el mantenimiento es más sencillo que si la plataforma usa un broker 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 con un broker MQTT independiente que implemente la especificación completa de MQTT.

Otras plataformas de IoT proporcionan un broker MQTT completo como parte de la plataforma, como se muestra en la arquitectura de ejemplo de este documento. Este intermediario puede ser uno de los intermediarios de código abierto que ya existen o una implementación de intermediario propietario. Un broker de MQTT completo proporciona la función bidireccional de MQTT descrita anteriormente, pero puede añadir complejidad y costes operativos a la gestión de la plataforma de IoT.

HTTPS y otros protocolos complementarios

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

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

Muchas aplicaciones de dispositivos con limitaciones usan el protocolo de aplicaciones con limitaciones (CoAP), definido en el RFC 7252, como alternativa a MQTT. CoAP se centra en clientes con poca sobrecarga y un tamaño reducido para dispositivos y sensores integrados. Muchas aplicaciones de plataformas de IoT comerciales también proporcionan un endpoint CoAP.

Balanceo de carga

Para obtener más información sobre cómo elegir el mejor balanceador de carga para tu arquitectura, consulta la sección sobre balanceo de carga de la arquitectura de broker MQTT independiente en Google Cloud, ya que esas consideraciones también se aplican a este caso.

Autenticación de dispositivos y gestión de credenciales

La gestión de las credenciales y la autenticación de los dispositivos es una parte fundamental 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 práctico de destino e implementar correctamente el esquema de autenticación elegido.

A diferencia de un broker de MQTT independiente, una plataforma de IoT proporciona servicios integrados para gestionar la identidad y las credenciales de los dispositivos. La mayoría de las plataformas de IoT usan la autenticación de clientes 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.

En algunos dispositivos con limitaciones, puede ser más adecuado usar la autenticación mediante JWT o nombre de usuario y contraseña, 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 cifres la conexión de red por separado de la autenticación mTLS, ya que ninguno de estos métodos de autenticación requiere una conexión cifrada. Por el contrario, la autenticación con certificado X.509 consume más recursos en el dispositivo conectado, pero se suele usar en una conexión cifrada 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 no se incluye en este documento.

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

Gestionar dispositivos conectados

Normalmente, los dispositivos conectados publican eventos de telemetría e información de estado en la plataforma a través de uno de los endpoints de ingestión, como MQTT. Si usas una plataforma de IoT multiprotocolo, los dispositivos pueden comunicarse mediante cualquiera de los protocolos admitidos.

Recomendamos que tu organización use una plataforma de IoT que tenga las siguientes funciones:

  • Actualizaciones de software y del sistema: envío y reversión de actualizaciones de firmware, software y aplicaciones a los dispositivos conectados. Estas actualizaciones suelen implicar también el almacenamiento y la gestión de las propias actualizaciones.
  • Actualizaciones de configuración: la entrega, el almacenamiento y la reversión de las actualizaciones de la configuración de las aplicaciones implementadas en los dispositivos conectados.
  • Creación y gestión de credenciales: creación de nuevas credenciales de dispositivo, envío de esas credenciales al dispositivo conectado, auditoría de los intentos de acceso y la actividad del dispositivo, y revocación de las credenciales vulneradas o caducadas en el momento oportuno.
  • 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 función suele incluir algún tipo de interfaz con poco código para definir reglas y flujos de procesamiento de datos.

Cargas de trabajo de backend

La mayoría de las plataformas de IoT proporcionan sus propias funciones de almacenamiento y transporte de datos internos, que te permiten conectarte a tus cargas de trabajo y aplicaciones backend. AMQP, RabbitMQ y Kafka se suelen usar para proporcionar transporte de datos interno. Todos ellos se pueden conectar a Pub/Sub mediante 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 directamente uno de los productos de Cloud Storage, como Cloud SQL, Firebase o BigQuery.

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

Casos prácticos

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

Gestión de electrodomésticos inteligentes

Las aplicaciones que gestionan varios electrodomésticos inteligentes son adecuadas para una plataforma de IoT. Un ejemplo de este tipo de aplicación es una plataforma para gestionar electrodomésticos de cocina, como lavavajillas y cafeteras. Estos dispositivos suelen conectarse a una aplicación basada en la nube, ya sea directamente a través de Wi-Fi o mediante una pasarela local que utiliza Bluetooth de bajo consumo (BLE) u otro protocolo local. Las funciones de gestión de una plataforma de IoT son importantes en este caso, ya que permiten monitorizar el estado de cada dispositivo, gestionar las actualizaciones de software y los parches de seguridad, y registrar la actividad de los dispositivos para proporcionar información valiosa al fabricante y al cliente. Estas funciones van más allá de las de un broker MQTT básico. Como mínimo, se necesitan un repositorio de información de dispositivos, una base de datos de estado de dispositivos, un almacén de datos de telemetría y una interfaz de analíticas para crear una plataforma de electrodomésticos inteligentes que funcione.

Logística y seguimiento de recursos

En el caso de una aplicación de logística y seguimiento de activos, un producto de plataforma de IoT ofrece una funcionalidad más completa que un broker MQTT básico, por lo que es una mejor opción para este caso práctico. Para monitorizar el estado y la ubicación actuales y anteriores de una gran flota de recursos, se necesita una base de datos de estados de dispositivos y un sistema de gestión de identidades sólidos. A medida que se implementan nuevos recursos, deben conectarse a la plataforma con la menor fricción posible y, posteriormente, monitorizarse durante todo el ciclo de vida del recurso. En muchos casos, la aplicación también recoge información de otros 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 ingerirse y asociarse al activo correcto para analizarlos en cualquier aplicación backend, por lo que la gestión de dispositivos con todas las funciones que ofrece la plataforma de IoT es una función importante.

Siguientes pasos