01 · Punto de partida
El viaje de un dato
Cuando mirás en el celular que el invernadero está a 24 °C, esa cifra hizo un recorrido largo: un sensor la midió, un microcontrolador le dio formato, una radio la transmitió, una red la llevó hasta un servidor, una base de datos la guardó y una aplicación la dibujó. Si cualquiera de esos pasos falla, el número no llega o llega viejo, y a veces nadie se entera.
En el tema anterior vimos las cuatro capas en forma general. Ahora las abrimos: qué componentes concretos hay en cada una, cómo se conectan entre sí, qué tipos de mensajes circulan y, sobre todo, dónde conviene tomar cada decisión. Esa última pregunta tiene consecuencias en la velocidad de respuesta, la energía, el costo y la tolerancia a fallas.
Todo lo que sigue en el curso (protocolos, almacenamiento, seguridad, actualización) se apoya en este mapa.
02 · Componentes
Las piezas del sistema
Además de las cuatro capas del tema 1 aparece un componente intermedio muy frecuente, el gateway (o pasarela), que no está presente en todos los sistemas. La tabla resume qué hace cada pieza, con qué hardware o servicio se implementa y qué suele fallar.
| Componente | Función | Ejemplos | Falla típica |
|---|---|---|---|
| Dispositivo (nodo) | Medir, actuar y comunicar | ESP32 con un sensor, placa con LoRa, módulo celular | Batería agotada, sensor sucio, firmware colgado |
| Gateway | Unir redes distintas, traducir protocolos, guardar y decidir localmente | Raspberry Pi, router industrial, hub doméstico | Es un único punto de falla de todos los nodos que atiende |
| Red de acceso | Llevar los datos desde el dispositivo hasta Internet | Punto de acceso Wi-Fi, antena LoRa, red celular | Señal débil, interferencia, cobertura insuficiente |
| Broker o API de entrada | Recibir los mensajes y repartirlos | Broker MQTT, servidor HTTP | Saturación, caída, credenciales vencidas |
| Almacenamiento | Guardar el historial y el estado | Base de series temporales, base de documentos | Crecimiento del volumen, consultas lentas |
| Procesamiento y reglas | Detectar condiciones, calcular, generar alertas | Motor de reglas, funciones en la nube | Reglas mal ajustadas, falsos avisos |
| Aplicación | Mostrar datos y permitir el control | Panel web, aplicación móvil, notificaciones | Datos viejos presentados como actuales |
La tabla deja ver algo que sorprende al principio: la mayoría de los fallos no están en el dispositivo sino en los eslabones del medio. Una red que se cae o una credencial vencida dejan mudo a un equipo que funciona perfectamente. Por eso un sistema IoT bien diseñado vigila todos los eslabones, no solo los sensores.
03 · Topologías
Cómo se conectan los dispositivos
Hay cuatro maneras habituales de llevar los datos del dispositivo a la plataforma. Elegir una define el consumo, el costo por unidad, el alcance y qué pasa cuando algo falla.
| Topología | Cómo funciona | Alcance | Ventaja | Limitación |
|---|---|---|---|---|
| Directa | Cada nodo llega solo a Internet (Wi-Fi, celular) | Alcance del punto de acceso o de la antena | Simple, sin intermediarios | Radio con consumo alto; cada equipo necesita red propia |
| Con gateway | Los nodos hablan con un concentrador local | Metros a decenas de metros | Nodos baratos y de bajo consumo; decisión local | El gateway es un punto único de falla |
| Malla | Los nodos se retransmiten entre sí | Se extiende con cada nodo | Cubre edificios grandes; hay rutas alternativas | Más complejo; los nodos intermedios gastan energía |
| Largo alcance | Nodos con radio LPWAN hablan con antenas lejanas | Kilómetros | Años de batería en campo abierto | Mensajes cortos y poco frecuentes |
No hay una opción mejor en abstracto. Un sensor de humedad en un campo de 200 hectáreas pide largo alcance; sesenta sensores de temperatura en un edificio de oficinas piden gateway o malla; un electrodoméstico enchufado y con Wi-Fi en la casa puede ir directo. La pregunta no es «¿qué tecnología es mejor?» sino «¿qué combina bien con la energía, el alcance y la cantidad de nodos que tengo?».
04 · Recorrido y demoras
El camino de un dato, paso a paso
Seguir un dato de punta a punta sirve para ubicar dónde se pierde tiempo y dónde se pueden perder mensajes. Tomemos una lectura de temperatura enviada por Wi-Fi con MQTT hasta una notificación en el celular:
| Etapa | Qué ocurre | Tiempo típico | Qué puede fallar |
|---|---|---|---|
| 1. Medición | El sensor convierte y el firmware lee el valor | 1 a 100 ms | Lectura inválida o ruidosa |
| 2. Armado del mensaje | Se le agrega identificador, momento y formato | menos de 1 ms | Reloj sin hora correcta |
| 3. Transmisión local | La radio envía el paquete al punto de acceso | 5 a 50 ms | Interferencia, señal débil |
| 4. Viaje por Internet | El paquete llega al servidor | 20 a 150 ms | Cortes, saturación, DNS |
| 5. Broker | Recibe y reparte a quienes están suscritos | 1 a 10 ms | Credenciales rechazadas, caída |
| 6. Almacenamiento y reglas | Se guarda y se evalúa la condición de alarma | 10 a 500 ms | Base lenta, reglas mal escritas |
| 7. Notificación | El servicio de mensajería avisa al celular | 0,5 a 5 s | Servicio externo demorado |
Sumando, una lectura llega al panel en menos de un segundo y a una notificación en unos pocos segundos. Dos conclusiones para el diseño. Primera: el camino depende de Internet, y su demora y su disponibilidad no las controlás vos. Segunda: los pasos más lentos están fuera del dispositivo, por lo que ahorrarle microsegundos al firmware no cambia nada si el viaje cuesta cientos de milisegundos.
05 · Mensajes
Cuatro tipos de información
Por el sistema circulan cuatro clases de mensajes con necesidades distintas. Tratarlas igual es un error común de diseño.
| Tipo | Sentido | Ejemplo | Característica |
|---|---|---|---|
| Telemetría | Dispositivo → plataforma | Temperatura cada 5 minutos | Muchos mensajes pequeños; perder uno no es grave |
| Evento | Dispositivo → plataforma | «Puerta abierta», «batería baja» | Poco frecuente pero importante; no debe perderse |
| Comando | Plataforma → dispositivo | «Encender la bomba 10 minutos» | Requiere confirmación y no ejecutarse dos veces |
| Configuración | Plataforma → dispositivo | Cambiar el período de medición | Debe persistir tras un reinicio |
La telemetría tolera pérdidas: si falta la lectura de las 14:05, la de las 14:10 la reemplaza. Un evento, en cambio, se envía con garantía de entrega, y un comando necesita una confirmación de recibo para saber si se ejecutó. Esta distinción es la que justifica los niveles de calidad de servicio de MQTT que veremos en el bloque correspondiente.
También cambia el modelo de comunicación. La telemetría y los eventos se prestan al esquema de publicación y suscripción: el dispositivo publica sin saber quién escucha. Los comandos pueden usar el mismo esquema o pedido y respuesta (como HTTP), y la configuración suele consultarse al arrancar. Los temas 19 a 30 profundizan ambos modelos.
06 · Diseño
Dónde conviene decidir
Una misma regla («si la temperatura pasa de 8 °C, avisar») se puede ejecutar en tres lugares: en el dispositivo, en el gateway (o servidor local, llamado a veces borde) o en la nube. Cada uno tiene ventajas.
| Criterio | Dispositivo | Gateway local | Nube |
|---|---|---|---|
| Demora de respuesta | Milisegundos | Decenas de milisegundos | Cientos de milisegundos o más |
| Funciona sin Internet | Sí | Sí, mientras funcione la red local | No |
| Datos que hay que subir | Pocos (solo eventos) | Pocos (filtrados) | Todos |
| Ve varios dispositivos a la vez | No | Los de su red | Todos |
| Cambiar la regla | Exige actualizar el firmware | Fácil | Muy fácil |
| Capacidad de cálculo | Muy limitada | Media | Casi ilimitada |
Una regla práctica: lo que tiene un plazo corto o debe funcionar sin red va lo más cerca posible del sensor; lo que necesita ver muchos dispositivos o cambiar seguido va a la nube. Apagar un motor que se sobrecalienta es una decisión del dispositivo. Detectar que, entre mil sensores, la temperatura sube en toda una zona, es de la nube. Lo habitual es combinarlas: el equipo protege y filtra, el gateway coordina el sitio y la nube analiza el conjunto.
07 · Gestión
Identidad y estado de cada dispositivo
Con un dispositivo, todo es fácil: sabés cuál es. Con cien, la plataforma necesita saber quién es cada uno y en qué estado está. De ahí salen dos elementos de la arquitectura que es mejor pensar desde el primer día.
- Identidad. Cada dispositivo lleva un identificador único (y, en un sistema seguro, credenciales propias) para que sus mensajes se asocien a él y para poder revocarlo si se pierde o se compromete. Un identificador compartido por todos los equipos impide saber de quién viene cada dato.
- Estado conocido. La plataforma mantiene lo último que supo de cada equipo: última lectura, versión de firmware, nivel de batería, si está en línea. Cuando un dispositivo no reporta, se distingue entre «no pasó nada» y «dejó de funcionar» con un mensaje periódico de «sigo vivo» (heartbeat).
A esa copia del estado dentro de la plataforma se la llama más adelante gemelo digital o shadow. Su valor es práctico: permite mandar un comando a un equipo que está apagado, porque la plataforma guarda el estado deseado y el dispositivo lo aplica al volver a conectarse. Lo estudiamos en el bloque de control remoto.
08 · Analogía con programación
Simular dónde se decide en Python
Para ver el efecto de la arquitectura basta un modelo simple. En una instalación ocurre un evento crítico por hora, durante 24 horas, y el sistema debe reaccionar dentro de un plazo_ms. La reacción se decide en el dispositivo (5 ms), en un gateway local (35 ms) o en la nube, donde se suma el tiempo de ida y vuelta por Internet y 20 ms de procesamiento en el servidor. La red tiene tres calidades; la peor sufre cortes de hasta tres horas por día, y durante un corte la nube no puede decidir nada. El programa cuenta cuántos de los 24 eventos se atienden a tiempo y cuántos mensajes y bytes se suben.
Python en tu navegador. Los bloques son editables: cambiá los valores y presioná «Ejecutar Python». La primera vez tarda unos segundos en cargar.
CAPAS_MS = {"dispositivo": 5, "gateway": 35} # decidir en el equipo o en el gateway local
REDES = {"buena": (80, 0), "regular": (300, 30), "mala": (1200, 180)} # (ida y vuelta en ms, minutos de corte por día)
MSG_BYTES = 120
def simular(lugar, red, plazo_ms):
rtt, corte_min = REDES[red]
if lugar == "nube":
latencia = 5 + rtt + 20 # lectura + viaje de ida y vuelta + proceso en el servidor
else:
latencia = CAPAS_MS[lugar]
atendidos = 0
for k in range(24): # un evento crítico por hora, al minuto 15 de cada hora
minuto = 15 + 60 * k
sin_red = lugar == "nube" and minuto < corte_min # el corte ocupa el comienzo del día
if latencia <= plazo_ms and not sin_red:
atendidos += 1
mensajes = 1440 if lugar == "nube" else 48 # nube: cada lectura; otros: 24 eventos + 24 latidos
return latencia, atendidos, mensajes, mensajes * MSG_BYTES / 1024
print("lugar red plazo latencia a tiempo mensajes KB/día")
for lugar, red, plazo in [("dispositivo", "buena", 100), ("gateway", "buena", 100),
("nube", "buena", 100), ("nube", "buena", 500),
("nube", "regular", 500), ("nube", "mala", 500),
("gateway", "mala", 500), ("nube", "mala", 5000)]:
lat, ok, msgs, kb = simular(lugar, red, plazo)
print(f"{lugar:<12} {red:<7} {plazo:>5} {lat:>6} ms {ok:>5}/24 {msgs:>8} {kb:>6.1f}")Resultado con los valores iniciales: con un plazo de 100 ms, el dispositivo y el gateway atienden los 24 eventos (5 ms y 35 ms), pero la nube, aun con red buena, tarda 105 ms y no atiende ninguno. Con un plazo de 500 ms la nube con red buena atiende 24 de 24, con red regular 23 (el corte de 30 minutos se lleva el evento de las 00:15) y con red mala 0, porque la respuesta tarda 1225 ms. Dando 5 segundos de plazo con la red mala, la nube atiende 21 de 24: el corte de 180 minutos se lleva tres eventos. En mensajes, la nube sube 1440 por día (168,8 KB) y las otras opciones 48 (5,6 KB).
Dos ideas surgen del modelo. Una: el plazo decide el lugar, porque la demora de Internet es un piso que ninguna optimización del código baja. Otra: la nube compra flexibilidad pagando demora, dependencia de la red y volumen de datos. Elegir es equilibrar esas tres cosas según la función que se trata.
09 · Exploración interactiva
Dispositivo, gateway o nube, de extremo a extremo
Este laboratorio ejecuta el mismo modelo del código anterior y dibuja los 24 eventos críticos del día. Los círculos celestes son eventos atendidos a tiempo y los rojos, los que se perdieron por llegar tarde o por un corte de red; la franja naranja marca la duración del corte. Los tiempos son valores didácticos de orden de magnitud, no mediciones de una red real.
Decidir cerca o lejos
Elegí los parámetros y presioná «Simular un día».
Recorrido guiado
- Con los valores iniciales (nube, red regular, 500 ms), simulá. La respuesta tarda 325 ms y entra en el plazo, pero se atienden 23 de 24 eventos: el corte de 30 minutos del comienzo del día se lleva el de las 00:15.
- Poné el plazo en 100 ms y la red en «Buena». La nube responde en 105 ms: ningún evento llega a tiempo, aun sin cortes. Es el piso que impone Internet.
- Cambiá el lugar a gateway: 35 ms, 24 de 24. Cambiá a dispositivo: 5 ms. Ninguno de los dos depende de la red, y suben 48 mensajes por día en lugar de 1440.
- Volvé a la nube con red «Mala» y plazo de 500 ms. La respuesta tarda 1225 ms y se pierden los 24 eventos. Con plazo de 5 s, ahora sí responde a tiempo, pero 21 de 24: el corte de tres horas se lleva tres eventos.
- Con red «Mala» y plazo de 500 ms, elegí «gateway»: 24 de 24. La calidad de Internet ya no importa para la decisión; solo para subir el resumen.
- Compará los mensajes por día de la nube (1440, 168,8 KB) con los del dispositivo y el gateway (48, 5,6 KB): casi 30 veces menos datos subidos.
Desafío: el precio de decidir en el equipo
Decidir en el dispositivo parece ganar siempre, ¿por qué no se hace con todo? Porque cambiar una regla exige actualizar el firmware de cada equipo. Si el umbral de alarma de 8 °C pasa a 7 °C, con 1000 dispositivos en el campo hay que distribuir y verificar 1000 actualizaciones, con el riesgo de que alguna falle. En la nube la misma modificación es un cambio de configuración. Una solución intermedia es que el firmware decida con parámetros (por ejemplo, el umbral) que la nube puede cambiar sin actualizar el programa: el equipo conserva la rapidez y la autonomía, y la plataforma, la flexibilidad.
10 · Método de trabajo
Cómo diseñar la arquitectura
Para esbozar la arquitectura de un sistema nuevo, recorré estas preguntas en orden:
- ¿Cuántos dispositivos habrá y dónde? Uno en una casa, cincuenta en un edificio o diez mil dispersos cambian toda la arquitectura.
- ¿Tienen energía de la red o batería? Con batería, el consumo de la radio manda y favorece gateway o LPWAN.
- ¿Qué alcance necesita cada enlace? Metros, edificio o kilómetros: define la tecnología de radio.
- ¿Qué decisiones tienen plazo corto o deben funcionar sin Internet? Esas viven en el dispositivo o en el gateway.
- ¿Qué mensajes circulan? Separá telemetría, eventos, comandos y configuración, y fijá para cada uno cuánta pérdida admite.
- ¿Cómo se identifica cada equipo y cómo se sabe si está vivo? Identificador, credenciales y mensaje de latido.
- ¿Qué pasa en cada eslabón cuando falla? Para cada flecha del diagrama, definí qué hace el sistema si ese enlace cae.
- ¿Cómo crece? Qué cambia si los dispositivos se multiplican por diez.
Dibujá el diagrama de bloques antes de elegir ningún componente. Un buen esquema, con cada flecha rotulada con el protocolo y el tipo de mensaje, evita decidir por moda («usemos todo en la nube») en lugar de por requisitos.
11 · Comprensión
Confusiones frecuentes
«Un gateway es lo mismo que un router»
Un router enlaza redes del mismo tipo reenviando paquetes IP. Un gateway IoT además traduce entre tecnologías distintas (por ejemplo, de Zigbee a MQTT sobre Ethernet) y puede almacenar datos y tomar decisiones. A veces un mismo equipo cumple ambas funciones, pero son tareas diferentes.
«Con una nube potente no hace falta inteligencia en el dispositivo»
La nube no puede reaccionar más rápido que el tiempo de ida y vuelta de Internet ni funcionar cuando se corta la conexión. Las funciones de seguridad, las de plazo corto y el filtrado de datos para ahorrar energía y red deben estar cerca del sensor.
«Si el dispositivo no reporta, está roto»
Puede estar sin batería, sin cobertura, con credenciales vencidas o simplemente el broker puede estar caído. El silencio tiene muchas causas. Por eso se envían latidos y la plataforma registra desde cuándo no hay noticias, para distinguir el origen de la falla.
«La telemetría y los comandos se tratan igual»
No: la telemetría tolera pérdidas, mientras que un comando debe confirmarse y no ejecutarse dos veces. Mezclarlos lleva a perder órdenes importantes o a repetir acciones (por ejemplo, abrir dos veces una válvula).
«Más capas es mejor arquitectura»
Cada capa agrega un posible punto de falla, un costo y una demora. Un sensor doméstico con Wi-Fi no necesita gateway ni procesamiento de borde. La arquitectura correcta es la más simple que cumple los requisitos.
«La arquitectura se puede cambiar después sin problemas»
Cambiar de Wi-Fi a LoRa implica otro hardware, y cambiar los mensajes obliga a actualizar equipos en el campo. Las decisiones sobre la radio, el formato de datos y la identidad son difíciles de modificar una vez fabricado el producto, por eso conviene pensarlas con cuidado al inicio.
12 · Práctica guiada
Predecí antes de comprobar
1. Elegir la topología
Indicá qué topología conviene para: (a) 40 sensores de temperatura de oficina alimentados por batería, dentro de un edificio; (b) un medidor de caudal en un río a 8 km del pueblo; (c) una cámara de seguridad enchufada con Wi-Fi.
Ver solución
(a) Con gateway o malla, con radios de bajo consumo (BLE, Zigbee o Thread): los nodos son baratos y viven años con batería. (b) Largo alcance (LoRa o celular de bajo consumo): el alcance de kilómetros y el consumo mínimo son decisivos. (c) Directa por Wi-Fi: tiene energía de la red y buen ancho de banda.
2. Clasificar mensajes
Clasificá como telemetría, evento, comando o configuración: (a) temperatura cada minuto; (b) «apagar la bomba»; (c) «nuevo período de medición: 5 minutos»; (d) «tanque vacío».
Ver solución
(a) telemetría; (b) comando; (c) configuración; (d) evento. Los eventos y los comandos necesitan garantía de entrega y confirmación; la telemetría y la configuración toleran más.
3. Plazo y lugar de decisión
Un sistema debe cortar un calefactor en menos de 200 ms si la temperatura supera un límite peligroso. El tiempo de ida y vuelta a la nube es de 150 ms más 25 ms de procesamiento en el servidor. ¿Se puede decidir en la nube?
Ver solución
Hay unos 180 ms de reacción (más la lectura del sensor), que apenas entran en el plazo en el mejor momento. Cualquier demora de red lo supera y, además, un corte de Internet dejaría el calefactor sin control. Se trata de una función de seguridad: debe decidirse en el dispositivo. La nube puede registrar el evento.
4. Volumen de datos
Si 500 dispositivos suben cada lectura (1 por minuto) en lugar de enviar solo 48 mensajes por día, ¿cuántos mensajes diarios recibe la plataforma en cada caso?
Ver solución
Con una lectura por minuto: 1440 × 500 = 720.000 mensajes por día. Con 48 por dispositivo: 48 × 500 = 24.000. Es una reducción de 30 veces en lo que el servidor debe recibir, guardar y procesar.
5. Cortes de Internet
Una conexión sufre cortes de 3 horas por día. ¿Qué fracción del día está sin servicio? Si todas las decisiones se toman en la nube, ¿qué consecuencia tiene?
Ver solución
180 / 1440 = 0,125, es decir 12,5 % del día. Durante ese tiempo el sistema no tendría ninguna decisión: no apagaría nada ni daría alarmas locales. Por eso las funciones críticas se toman cerca del equipo y la nube analiza y coordina.
6. El punto único de falla
Veinte sensores BLE dependen de un único gateway. ¿Qué ocurre si se apaga y cómo se mitiga?
Ver solución
Los veinte quedan incomunicados al mismo tiempo, aunque todos funcionen. Se mitiga con un segundo gateway en cobertura redundante, con almacenamiento local en cada sensor mientras no hay quien reciba, y con vigilancia del propio gateway (latido) para enterarse enseguida de la falla.
13 · Síntesis
Ideas para recordar
- Un sistema IoT tiene dispositivos, red de acceso, un gateway opcional, una plataforma con broker, almacenamiento y reglas, y una aplicación.
- La mayoría de las fallas están en los eslabones del medio (red, credenciales, servidor); por eso se vigila todo el recorrido y no solo los sensores.
- Hay cuatro topologías habituales: directa, con gateway, malla y largo alcance; se elige según energía, alcance y cantidad de nodos.
- El camino de un dato suma milisegundos de medición y transmisión y cientos de milisegundos de Internet; el viaje por Internet es un piso que el firmware no puede reducir.
- Circulan cuatro clases de mensajes: telemetría, eventos, comandos y configuración, con distintas exigencias de entrega.
- Lo que tiene plazo corto o debe funcionar sin red se decide en el dispositivo o en el gateway; lo que necesita ver muchos equipos o cambiar seguido, en la nube.
- Las funciones de seguridad física nunca deben depender de un mensaje desde Internet.
- Cada dispositivo necesita identidad propia y un estado conocido por la plataforma, con latidos para saber si sigue vivo.
- La arquitectura correcta es la más simple que cumple los requisitos, porque cada capa agrega costo, demora y puntos de falla.
¿Listo para el tema 3?
Antes de avanzar, dibujá de memoria la arquitectura de un sistema que conozcas (con o sin gateway), rotulá qué mensaje circula en cada flecha y explicá dónde ubicarías una función de seguridad y dónde un análisis que compara mil dispositivos. Si podés justificarlo, tenés el mapa que usaremos en todo el curso.
En el próximo tema recorremos dispositivos conectados y casos de uso: hogar, industria, agro, ciudad y salud, qué se mide y qué se controla en cada uno y qué exigencias de arquitectura imponen.