Diagrama de arquitectura IoT: dispositivos, MQTT, procesamiento de flujos y almacenamiento

La mayoría de los diagramas IoT tienen tres cajas: dispositivos, un icono de nube y un panel. Las preguntas importantes viven entre ellas. ¿Cómo sabe el broker qué dispositivo está hablando? ¿Qué pasa cuando un sitio pierde la conexión durante una hora? ¿Qué mensajes pueden perderse o entregarse dos veces? ¿Cómo llega un comando a un sensor entre miles?

Un diagrama de arquitectura IoT debería responder a esas preguntas en la página. Este artículo construye uno para un caso concreto, la monitorización de temperatura en almacenes frigoríficos, y repasa las decisiones detrás de cada salto: MQTT y sus niveles de calidad de servicio, el diseño de topics, la identidad de los dispositivos, los sitios sin conexión y el tiempo de evento, y dónde acaban los datos.

Las capas de un sistema IoT

No todos los sistemas necesitan todas las capas. Los dispositivos con módulos celulares o Wi-Fi suelen publicar directamente en el broker sin gateway. Dibuja las capas que de verdad operas.

Por qué MQTT

MQTT es un protocolo de publicación/suscripción en el que los clientes se conectan a un broker e intercambian mensajes por topic. La especificación MQTT 5.0, estándar de OASIS desde marzo de 2019, lo describe como ligero, abierto y sencillo de implementar. El puerto 1883 está registrado en la IANA para MQTT sin TLS y el 8883 para MQTT sobre TLS. Todo lo que salga del sitio debería usar el 8883.

Cada mensaje se publica con un nivel de calidad de servicio (QoS):

La QoS se aplica a cada salto, no de extremo a extremo: un suscriptor recibe un mensaje con la menor entre la QoS con la que se publicó y la QoS concedida a su suscripción. Con QoS 1, el broker puede entregar duplicados, así que cada consumidor tiene que tolerar recibir dos veces la misma lectura. Un ID de mensaje generado por el dispositivo o una marca de tiempo por sensor lo facilitan.

MQTT 5 añade algunas funciones que merece la pena poner en el diagrama:

• Mensajes retenidos (retained). El broker guarda el último mensaje de un topic y lo envía a los nuevos suscriptores, lo que encaja con el estado actual de un dispositivo.
• Mensajes de última voluntad (will). El broker publica el mensaje de última voluntad de un cliente cuando su conexión se cae sin una desconexión limpia, así un gateway puede anunciar que se ha quedado sin conexión.
• Caducidad de mensajes. Si un mensaje caduca antes de que empiece la entrega, el broker lo elimina. Úsala para comandos que solo son válidos durante un tiempo.
• Suscripciones compartidas. Varios consumidores comparten una suscripción y cada mensaje va solo a uno de ellos, así el puente hacia la plataforma de streaming puede escalar horizontalmente.

Diseño de topics

Los topics son jerárquicos, y los suscriptores usan + para un nivel y # para el resto. Una estructura como site/{site}/device/{id}/telemetry permite suscribirse a un sitio, a un dispositivo o a todo, y permite al broker limitar cada dispositivo a sus propios topics. Los topics que empiezan por $ están reservados para el broker, y los filtros que empiezan por un comodín no coinciden con ellos.

Usa los topics para enrutar y para los permisos. Pon la versión del esquema y la hora de la medición en la carga útil, donde pueden cambiar sin romper todas las suscripciones.

Identidad de los dispositivos

Dale a cada dispositivo o gateway su propio certificado X.509 firmado por tu CA de dispositivos, y haz que el broker exija certificados de cliente. El sujeto del certificado se convierte en el ID de cliente, y el broker concede los topics en función de él. Así, un dispositivo robado puede revocarse por separado y no queda ninguna contraseña compartida en el firmware de miles de unidades. Decide cómo se emiten los certificados, en fabricación o en el primer arranque, y cómo se rotan antes de que caduquen, y dibuja la CA en el diagrama.

Sitios sin conexión y tiempo de evento

Los sitios pierden la conexión. Un gateway que almacena las lecturas en búfer localmente envía una hora de datos de golpe cuando vuelve el enlace, así que los datos llegan tarde y desordenados. Marca cada lectura con la hora en que se midió, mantén sincronizados los relojes de los gateways y procesa en tiempo de evento con un margen para los retrasos. Una alerta como "congelador por encima de -18 °C durante diez minutos" tiene que calcularse según cuándo se tomaron las lecturas, no según cuándo llegaron. El mismo razonamiento vale para cualquier arquitectura orientada a eventos.

El ejemplo: monitorización de almacenes frigoríficos

Cada almacén tiene unos cuarenta sensores de congeladores que informan cada 30 segundos y una docena de sensores de puertas que informan cuando cambian. Un gateway del sitio recoge sus lecturas por radio local, las guarda en búfer cuando no hay conexión y las publica en el broker MQTT con QoS 1 sobre TLS mutuo. El broker valida cada certificado de cliente contra la CA de dispositivos. Un puente con una suscripción compartida copia la telemetría en Kafka. Un consumidor archiva los mensajes en bruto en almacenamiento de objetos; un procesador de flujos calcula agregados de un minuto en tiempo de evento, los escribe en una base de series temporales para los paneles y lanza alertas de temperatura. La gestión de dispositivos envía comandos y configuración de vuelta a través del broker.

Cómo leerlo:

• A la izquierda, el sitio. Los sensores solo hablan con el gateway del sitio; el gateway es el único cliente que el broker ve desde ese sitio.
• En el centro, el broker. La telemetría sube con QoS 1. Las conexiones discontinuas son los comandos que bajan al sitio y la validación de certificados contra la CA de dispositivos.
• A la derecha, el camino de los datos. Kafka alimenta el archivo en bruto y el procesador de flujos, que escribe agregados en la base de series temporales y lanza alertas.
• El bloque Markdown contiene la estructura de topics, la QoS por topic y la regla de identidad.

Qué etiquetar

• El protocolo, el puerto y la QoS en el enlace del sitio al broker.
• La tasa de mensajes por clase de dispositivo. Cuarenta sensores cada 30 segundos son 80 mensajes por minuto por sitio; multiplícalo por el número de sitios antes de dimensionar el broker.
• La identidad: qué certificado, qué CA y cómo se rotan y revocan los certificados.
• El búfer: cuánto tiempo puede guardar datos el gateway sin conexión.
• La retención de cada almacenamiento, de horas en el flujo a años en el archivo.
• El camino de los comandos, incluida la caducidad de mensajes y qué hace un dispositivo con un comando desconocido.

Errores comunes

• Credenciales compartidas entre dispositivos. Una sola contraseña filtrada abre entonces todos los dispositivos. Usa un certificado por dispositivo.
• El puerto 1883 en internet. Sin TLS, las lecturas y las credenciales viajan en texto claro.
• Dar por hecho la entrega exactamente una vez. QoS 1 puede entregar duplicados; haz idempotentes a los consumidores en lugar de recurrir a QoS 2 en todas partes.
• Procesar en tiempo de llegada. Los datos almacenados en búfer disparan entonces falsas alertas u ocultan las reales.
• Dispositivos que escriben directamente en la base de datos. Pierdes la autenticación, el búfer y el reparto del broker.
• Sin camino de actualización. Las actualizaciones de firmware y los cambios de configuración forman parte de la arquitectura; dibújalos.
• Permisos con comodines para los dispositivos. Un dispositivo que puede suscribirse a # puede leer los datos de todos los demás.

El diagrama de topología de red cubre la red propia del sitio, que un diagrama IoT suele dejar fuera.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade un Marco del pack Básico para el sitio. Dentro, del pack Red, añade un Dispositivo por cada grupo de sensores con el tipo IoT / hogar inteligente, y otro Dispositivo con el tipo Módem / puerta de enlace para el gateway del sitio.
3. Del pack Modelo C4, añade nodos Contenedor para el broker MQTT, la gestión de dispositivos y el procesador de flujos, y una Base de datos para la base de series temporales.
4. Del pack Seguridad, añade un Certificado para la CA de dispositivos.
5. Del pack Datos, añade Kafka y un Almacén de objetos para el archivo en bruto. Del pack DevOps, añade Métricas para los paneles y un nodo Alerta.
6. Conéctalos de izquierda a derecha, etiqueta el enlace de subida con su QoS, dibuja discontinuos los comandos y la validación de certificados, y añade un bloque Markdown del pack Básico con el diseño de topics.

El ejemplo usa 14 nodos de diagrama, dentro del plan Free. La página de diagramas de red muestra el resto del pack Red.

Preguntas frecuentes

¿Los dispositivos IoT deben usar MQTT o HTTP? MQTT mantiene una conexión abierta, así que la nube puede enviar comandos, y su sobrecarga por mensaje es pequeña. HTTP es más sencillo para dispositivos que informan pocas veces y nunca reciben comandos.

¿Qué nivel de QoS debo usar? QoS 1 para la mayoría de la telemetría y los comandos, con consumidores que toleren duplicados. QoS 0 para lecturas de alta frecuencia que puedes permitirte perder. QoS 2 solo donde los duplicados no se puedan gestionar aguas abajo.

¿Necesito Kafka si ya tengo un broker MQTT? No siempre. El broker enruta mensajes a los suscriptores conectados; no es un log a largo plazo que puedas reproducir. Añade una plataforma de streaming cuando varios consumidores necesiten los mismos datos o cuando tengas que reprocesar el histórico.

¿Cómo obtienen los dispositivos sus certificados? En fabricación o en el primer arranque, mediante un servicio de aprovisionamiento, cada uno con su propio par de claves. Guarda la clave privada en hardware seguro si el dispositivo lo tiene.

¿Las reglas deben ejecutarse en el borde o en la nube? Las reglas que deben funcionar durante una caída, como una alarma local por una puerta que se quedó abierta, se ejecutan en el gateway. Las reglas que necesitan datos de muchos sitios se ejecutan en la nube.

Empieza gratis — un puesto, sin tarjeta de crédito.