Cierre y puente al Internet de las Cosas

01 · Mirar hacia atrás

Lo que recorrimos

El curso tuvo once bloques, y conviene verlos juntos porque cada uno resuelve un problema que el siguiente da por resuelto:

Mirados desde el final, los bloques dibujan un camino. Se empieza entendiendo qué restricciones tiene el problema (1), se aprende cómo arranca y se organiza un firmware (2), cómo reacciona al tiempo (3 y 4) y cómo se modela su lógica (5). Luego se atienden los recursos escasos: memoria (6) y energía (7). Después, lo que ocurre cuando las cosas salen mal: fallas y watchdog (8), cortes de energía y actualización (9). Más tarde, cómo encontrar y prevenir errores (10). Y por fin, cómo se decide y se sostiene todo eso en un producto real (11). Cada bloque del curso puede leerse también como una pregunta que se le hace al diseño: ¿qué tengo?, ¿cómo arranca?, ¿cuándo responde?, ¿cómo se decide?, ¿cuánto cabe?, ¿cuánto dura?, ¿qué pasa si falla?, ¿qué pasa si se corta?, ¿cómo lo encuentro?, ¿cómo lo sostengo?

02 · Lo que queda cuando se olvidan los detalles

Los principios que se repiten

Los registros de un chip concreto se olvidan con el próximo modelo. Lo que perdura son unas pocas ideas que reaparecieron en casi todos los bloques, con distinta forma. Si hubiera que quedarse con ocho:

Tres de estas ideas merecen una frase más, porque se olvidan primero. El peor caso es incómodo porque casi nunca se ve: el equipo funciona meses sin que aparezca, y el día que aparece, aparece en el campo. Medir lo previsto contra lo observado es lo único que convierte un modelo en una herramienta confiable: un modelo que nunca se contrastó es una opinión con fórmulas. Y diseñar para fallar no es pesimismo: es aceptar que en una flota de miles de equipos, durante años, lo que tiene una probabilidad de una en un millón sucede todos los días (la cuenta del tema 46 con una carrera de 6,25 × 10^-5 por segundo lo mostró: 54 000 fallos por día en 10 000 equipos).

03 · Salir del dispositivo

De un dispositivo a un sistema conectado

El Internet de las Cosas (IoT, por Internet of Things) es, sencillamente, el conjunto de dispositivos embebidos conectados a una red para enviar datos, recibir órdenes y actualizarse. Lo que cambia para quien diseña es que el producto ya no es el dispositivo: es el dispositivo más todo lo que lo rodea. Un sistema conectado tiene cinco capas, y cada una tiene dueños, costos y fallas propias:

Cada capa agrega una pregunta de diseño. El enlace decide cuánta energía cuesta hablar y a qué distancia. La pasarela (un equipo intermedio que habla con varios dispositivos y con la red) existe porque a un dispositivo chico le conviene un protocolo local barato (como BLE) y no una conexión directa a Internet, que cuesta mucha energía (sección siguiente). La nube recibe los mensajes, los guarda, avisa y administra la flota. Las aplicaciones son lo que ve el usuario. Y la franja inferior es lo que más se olvida: la identidad de cada equipo, la seguridad de cada enlace y la actualización no son una capa más sino una propiedad de todas.

Una decisión central es qué se calcula dónde. En el dispositivo conviene hacer lo que reduce lo que hay que transmitir (promediar, detectar un evento, comprimir, decidir una alarma), porque transmitir es lo más caro en energía. En la nube conviene lo que necesita datos de muchos equipos o mucho cálculo (comparar, predecir, entrenar modelos). Y hay un criterio de seguridad funcional: las funciones críticas no deben depender de la nube. En el registrador, la alarma se decide a bordo y se informa por radio; si no hay cobertura, el equipo igual registra y guarda, y entrega al volver. Un dispositivo que deja de funcionar cuando se cae el servicio es un producto frágil.

04 · El costo de hablar

Elegir la conectividad

Hay muchas tecnologías de enlace, y suelen compararse por velocidad, que es casi lo único que no importa en un sensor: lo que decide es la energía por reporte, la cobertura y el costo de la infraestructura y del servicio. La tabla resume, con órdenes de magnitud, cómo se reparten:

La energía se calcula con el mismo modelo del tema 48, con una novedad: cada reporte tiene un costo fijo (despertar la radio, encontrar la red, asociarse, negociar el cifrado) y uno proporcional a los datos. La carga de un reporte es (tiempo fijo + 8 × bytes / velocidad) × corriente de transmisión. La Parte 2 del programa la calcula para cinco enlaces con parámetros de orden de magnitud supuestos (en un proyecto real se miden con el módulo elegido):

La tabla enseña la lección más importante de la conectividad de bajo consumo: con una conexión que dura segundos, no hay pila AA que alcance para reportar cada pocos minutos. Por Wi-Fi, un reporte cada 15 minutos agota las dos pilas en menos de 8 meses (0,66 años), y cada 5 minutos, en menos de 3 meses (0,23 años). Lo que mata la autonomía no son los 16 bytes, sino los 1500 ms de asociarse. Hay cuatro caminos, y suelen combinarse: elegir una tecnología con conexión barata (BLE a una pasarela, LPWAN), reportar mucho menos seguido (por Wi-Fi, al menos cada 75 minutos para mantener el objetivo de diseño), agrupar muchas medidas por conexión (siguiente sección) o alimentar al dispositivo de otra manera (red eléctrica, panel solar). Y fuera de la energía, la elección depende de la cobertura real del lugar de uso (un contenedor en un puerto, un campo sin red celular), de la infraestructura que el cliente acepta instalar y de la cuota mensual por equipo, que en una flota grande pesa más que el costo del hardware. También de la homologación: un módulo de radio ya certificado ahorra meses frente a un diseño propio (tema 49).

05 · Qué se dice y cómo llega

Mensajes: protocolos, formatos y entrega

Entre el dispositivo y la nube viajan mensajes, y hay que decidir tres cosas: el protocolo (cómo se transporta), el formato (cómo se codifican los datos) y la garantía de entrega (qué pasa si el mensaje se pierde).

El formato importa por el tamaño. La Parte 1 del programa codifica el mismo reporte (identificador, instante, temperatura, batería, estado y versión del firmware) de tres maneras: en JSON (texto legible), en CBOR (un formato binario compacto con la misma estructura que el JSON, ya normalizado) y en un binario propio de campos fijos:

El JSON de una medida pesa 4,6 veces el binario; con quince medidas, 2,4 veces. ¿Cuánto importa? Depende del enlace (Parte 2). Con la radio del registrador (100 kb/s y 0,4 s de costo fijo), cambiar de binario a JSON sube el consumo de 15,98 a 16,13 µA, un 1 %: el tamaño casi no importa, porque lo que cuesta es conectarse. Con un enlace lento de tipo LoRa (5 kb/s) el mismo cambio sube la carga de 5,0 a 8,7 mC, un 74 % más. Es la misma idea en otra escala: el tamaño del mensaje importa cuando el enlace es lento, y la cantidad de conexiones importa siempre.

De ahí la técnica más rentable del IoT de bajo consumo: agrupar (batching). Con la radio del registrador, enviar quince medidas en una conexión (binario, 136 B) cuesta 11,50 mC contra los 11,24 mC de enviar una: el 2 % más de energía transporta quince veces más datos. Con un enlace LoRa, quince reportes separados costarían 15 × 5,0 = 75 mC, y uno solo con las quince medidas (136 B) cuesta unos 12,7 mC, casi seis veces menos. El costo de la agrupación es la latencia (el dato más viejo del lote espera hasta 15 minutos) y la pérdida del lote entero si la conexión falla, de modo que lo urgente (la alarma) sale aparte y de inmediato, y el historial, en lotes.

Queda la garantía de entrega. Con un enlace que pierde el 20 % de los mensajes en cada sentido (un valor exagerado, para verlo con claridad) la Parte 3 compara dos políticas con 100 000 mensajes simulados:

La confirmación sube la entrega del 80 % al 99,2 % por un 49 % más de transmisiones, pero introduce duplicados (el mensaje llegó, la confirmación se perdió, y el equipo lo reenvía). La consecuencia es una regla de diseño: el servidor debe ser idempotente, es decir, procesar dos veces el mismo mensaje debe dar el mismo resultado. Para eso cada mensaje lleva un identificador único (un número de secuencia junto al identificador del equipo) y el servidor descarta los repetidos. Existe una tercera política, «exactamente una vez», que cuesta más intercambios; en sensores suele reemplazarse por «al menos una vez» con identificadores. Y los mensajes llevan también la versión del protocolo y el instante de la medida (no el de la recepción, porque con el reenvío y el lote difieren; hay que sincronizar el reloj, sección 7).

06 · Cientos de miles de equipos

Identidad, seguridad y gestión de flota

Cuando hay miles de equipos, cada uno necesita ser identificable y confiable, y el conjunto, administrable. Las bases son las del tema 43, con la escala como novedad:

• Identidad única por dispositivo: cada equipo tiene su propia clave o su propio certificado, generado y guardado de forma segura (idealmente en un elemento seguro o en una zona protegida del chip) y nunca una contraseña común a toda la flota: si se descubre una, se compromete todo.
• Aprovisionamiento (provisioning): cómo llega la identidad al equipo. Lo más seguro es en la fábrica, con un puesto de programación que genera o inyecta las claves; lo más cómodo, un proceso de primer arranque. Cualquiera sea, se diseña antes de la producción y se prueba.
• Autenticación mutua y cifrado del enlace: el equipo verifica al servidor y el servidor al equipo. El cifrado cuesta energía (el intercambio de claves es parte del costo fijo de cada conexión), y por eso se prefiere mantener sesiones o usar protocolos diseñados para dispositivos pequeños.
• Rotación y revocación: poder cambiar una clave y dar de baja a un equipo perdido o comprometido, sin visitar cada uno.
• Privacidad: los datos de personas y lugares tienen reglas legales; se envía solo lo necesario, y se decide cuánto tiempo se guarda.

La gestión de flota es lo que mantiene vivo al producto (tema 50) cuando son miles. Cada equipo informa su versión de firmware, su salud (causa del último reinicio, contadores, tensión de la pila, calidad del enlace) y su estado, y la nube mantiene una imagen de cada uno (un «gemelo digital» o device shadow: el estado deseado y el último estado informado). Con eso se contesta en minutos qué equipos tienen una biblioteca vulnerable, cuáles están por quedarse sin pila, cuáles reinician demasiado. Y se habilita lo más delicado: actualizar la flota.

Una actualización defectuosa a toda la flota a la vez es el peor escenario. La Parte 4 lo cuantifica con una flota de 17 800 equipos y una versión que daña al 2 % de los que la reciben: actualizando todos a la vez se dañan en promedio 356 equipos; actualizando por etapas (el 1 %, después hasta el 10 %, el 50 % y el 100 %) y deteniendo la campaña si una etapa tiene una sola falla, se dañan en promedio 4,4: unas 80 veces menos. La primera etapa (178 equipos) detecta el problema con una probabilidad del 97,3 %. Es la razón de combinar tres cosas del tema 42: la actualización con vuelta atrás (la versión nueva debe confirmarse), el despliegue gradual con criterios de parada y la telemetría de salud que alimenta esos criterios. Funciona solo si el criterio es medible («más de 0,5 % de reinicios en las primeras 24 horas detiene la campaña») y si la primera etapa es representativa de la flota (todas las versiones de hardware, todas las regiones).

07 · Lo que cambia al conectar

Qué cambia en el diseño al conectar

Conectar un dispositivo modifica las decisiones de todos los bloques del curso:

La Parte 3 mostró la consecuencia más importante en la práctica, el almacenar y reenviar. El registrador guarda un registro por minuto con capacidad de 43 200 (30 días). Con una falta de cobertura de 9 días, junta 12 960 registros sin perder ninguno, y al volver la cobertura los entrega en 432 mensajes de 30 registros (256 B cada uno): 5086 mC, es decir, el 0,09 % de la pila, en unos 36 minutos a un mensaje cada 5 s. Con una falta de 40 días, sobrepasa la capacidad: se pierden los 14 400 registros más viejos (el registro circular sobrescribe), y la entrega de los 43 200 restantes son 1440 mensajes y el 0,31 % de la pila. La pila alcanza de sobra para ponerse al día; lo que se agota es el espacio, y por eso el dimensionamiento del registro incluye «cuánto tiempo sin conexión se tolera».

/* Cabecera de un mensaje binario del registrador: identifica el equipo, el mensaje y el protocolo, y permite descartar duplicados */
typedef struct __attribute__((packed)) {
    uint32_t id_equipo;        /* identidad del dispositivo */
    uint16_t secuencia;        /* número del mensaje: el servidor descarta los repetidos (entrega al menos una vez) */
    uint8_t  version_proto;    /* versión del formato del mensaje (tema 50: se versiona igual que el firmware) */
    uint8_t  tipo;             /* 1 = alarma, 2 = reporte periódico, 3 = lote de historial, 4 = falla */
    uint32_t instante_s;       /* cuándo se hizo la medida (no cuándo se envió) */
} CabeceraMsg;                 /* 12 bytes; después van los datos y un CRC (o la firma, si se la exige) */

/* Reconexión con espera creciente: 5, 10, 20... hasta un máximo de 15 minutos, con algo de azar para que una flota no se reconecte toda a la vez */
static uint32_t espera_s = 5u;
void conexion_fallo(void) {
    uint32_t jitter = (uint32_t)(rand_hw() % (espera_s / 4u + 1u));       /* hasta un 25 % de azar */
    energia_programar_reintento(espera_s + jitter);
    if (espera_s < 900u) { espera_s = (espera_s * 2u > 900u) ? 900u : espera_s * 2u; }
}
void conexion_exito(void) { espera_s = 5u; }                              /* al lograr conectarse, se reinicia la espera */

La reconexión con espera creciente (exponential backoff) es una defensa doble. Protege la pila: reintentar cada 5 s consumiría unos 8000 mC por hora (ejercicio 6), de modo que una falta de cobertura de un mes la vaciaría; con el máximo de 15 minutos, 45 mC por hora. Y protege al servidor: miles de equipos que pierden la conexión por el mismo corte y se reconectan todos en el mismo segundo sobrecargan el servicio justo cuando se recupera, y el azar (jitter) reparte el pico.

08 · Cómo seguir

Próximos pasos

Este curso dio los cimientos comunes. A partir de aquí, el camino depende de qué se quiera construir. Algunas direcciones naturales, cada una con su continuación del curso:

La mejor manera de aprender es construir y medir. Cinco proyectos propuestos, cada uno con una restricción que obliga a aplicar un bloque:

• Un registrador de temperatura con una placa de desarrollo: reproducir el proyecto integrador con el sensor y el microcontrolador reales, medir la corriente de cada modo con un medidor y comparar con el modelo (bloque 7 y tema 51).
• Un medidor de consumo de bajo costo: construir el instrumento que mide el perfil de corriente de otro dispositivo, y usarlo para el proyecto anterior (tema 36).
• Un cargador de arranque con actualización segura: implementar dos imágenes, la vuelta atrás y una prueba exhaustiva con corte de energía en cada paso (temas 42, 43 y 47).
• Una pasarela BLE a la nube: recibir medidas de varios sensores, agruparlas y enviarlas por un protocolo ligero, con almacenamiento y reenvío durante un corte de red (sección 7).
• Un banco de pruebas automático: una placa que carga firmware, aplica estímulos, mide con un analizador lógico y reporta cumple o no cumple en la integración continua (tema 47).

Y algunas costumbres que acompañan una carrera: leer las hojas de datos y los manuales de referencia (la fuente de verdad sobre un chip, incluida la lista de erratas), leer código ajeno bien hecho (los núcleos de sistemas operativos abiertos, los controladores del fabricante, las bibliotecas de los protocolos) y escribir lo que se aprende (un cuaderno de laboratorio con mediciones y errores resueltos vale más que cualquier curso). Cada error de depuración bien documentado es un patrón que no se vuelve a pagar.

09 · Comprobar que funciona

Verificación y diagnóstico

10 · Analogía con programación

Probar el modelo en Python

El programa reúne cuatro piezas del tema: la codificación del mismo reporte en JSON, CBOR (con un codificador mínimo escrito allí mismo) y binario; el costo de energía de un reporte para cinco tecnologías de enlace, con el efecto del formato y del agrupamiento; la entrega de mensajes con pérdidas y la recuperación tras una falta de cobertura; y la actualización escalonada de una flota.

# Puente al Internet de las Cosas: tamaño de los mensajes, costo de energía de la conectividad, entrega con pérdidas y actualización escalonada de una flota.
import json, math, random, struct

# ---- Parte 1: el mismo reporte en tres formatos -------------------------------------------------------------------------------------------------
def cbor(x):                                                       # un codificador CBOR mínimo (enteros, texto, listas y mapas)
    def cab(mayor, n):
        if n < 24: return bytes([mayor << 5 | n])
        if n < 256: return bytes([mayor << 5 | 24, n])
        if n < 65536: return bytes([mayor << 5 | 25]) + n.to_bytes(2, "big")
        return bytes([mayor << 5 | 26]) + n.to_bytes(4, "big")
    if isinstance(x, int): return cab(0, x) if x >= 0 else cab(1, -1 - x)
    if isinstance(x, str): b = x.encode(); return cab(3, len(b)) + b
    if isinstance(x, list): return cab(4, len(x)) + b"".join(cbor(i) for i in x)
    if isinstance(x, dict): return cab(5, len(x)) + b"".join(cbor(k) + cbor(v) for k, v in x.items())
ID, T0, FW = 0x0A1B2C3D, 1_767_225_600, "1.5.0"
uno = {"id": ID, "t": T0, "temp": 425, "bat": 2870, "est": 1, "fw": FW}
muestras = [[T0 - 60 * (14 - i), 400 + 3 * i, 1] for i in range(15)]                 # quince medidas, una por minuto: instante, temperatura (centésimas) y estado
lote = {"id": ID, "fw": FW, "m": muestras}
TAM = {"json1": len(json.dumps(uno, separators=(",", ":")).encode()), "cbor1": len(cbor(uno)),
       "bin1": len(struct.pack(">IIhHB3s", ID, T0, 425, 2870, 1, bytes([1, 5, 0]))),
       "json15": len(json.dumps(lote, separators=(",", ":")).encode()), "cbor15": len(cbor(lote)),
       "bin15": 16 + 15 * len(struct.pack(">IhH", T0, 400, 1))}
print("Parte 1: tamaño de un reporte según el formato (bytes de datos, sin cabeceras del protocolo)")
print(f"  una medida:       JSON {TAM['json1']} B, CBOR {TAM['cbor1']} B, binario propio {TAM['bin1']} B")
print(f"  quince medidas:   JSON {TAM['json15']} B, CBOR {TAM['cbor15']} B, binario propio {TAM['bin15']} B")
print(f"  el JSON de una medida es {TAM['json1'] / TAM['bin1']:.1f} veces el binario; con quince medidas, {TAM['json15'] / TAM['bin15']:.1f} veces; el binario de quince cuesta {TAM['bin15'] / TAM['bin1']:.1f} veces el de una")
print("  JSON de ejemplo:", json.dumps(uno, separators=(",", ":")))

# ---- Parte 2: costo de energía de un reporte según la tecnología de radio -----------------------------------------------------------------------
TEC = {"radio propia (la del registrador)": (0.40, 100, 28), "BLE a un gateway cercano": (0.06, 200, 8), "Wi-Fi": (1.5, 5000, 150),
       "LPWAN tipo LoRa": (0.10, 5, 40), "celular para IoT": (3.0, 50, 60)}      # (segundos fijos por reporte, kb/s, mA al transmitir): ÓRDENES DE MAGNITUD SUPUESTOS para el ejemplo
RESTO_UA, AUTODESC, CAP = 3.5, 5.70, 1500                          # reposo 2,0 µA más medidas 1,5 µA; autodescarga; mAh utilizables
def reporte(tec, bytes_, periodo_s):
    seg, kbps, ma = TEC[tec]
    t = seg + bytes_ * 8 / (kbps * 1000)
    mc = t * ma
    ua = RESTO_UA + mc / periodo_s * 1000
    return t, mc, ua, CAP / ((ua + AUTODESC) / 1000) / 24 / 365
print()
print("Parte 2: un reporte cada 15 minutos con la medida en binario (16 B): tiempo de radio, carga y vida con 2 pilas AA")
for tec in TEC:
    t, mc, ua, vida = reporte(tec, TAM["bin1"], 900)
    print(f"  {tec:<34} {t * 1000:7.0f} ms, {mc:6.1f} mC por reporte, {ua:7.2f} µA, vida {vida:5.2f} años {'(NO cumple 2 años)' if vida < 2 else ''}")
print("  con la radio propia, el mismo reporte según el formato y si se envían una o quince medidas:")
for nombre, clave in (("JSON, una medida", "json1"), ("binario, una medida", "bin1"), ("CBOR, una medida", "cbor1"), ("JSON, quince medidas", "json15"), ("binario, quince medidas", "bin15")):
    t, mc, ua, vida = reporte("radio propia (la del registrador)", TAM[clave], 900)
    print(f"    {nombre:<24} {TAM[clave]:>4} B, {mc:5.2f} mC, {ua:5.2f} µA, vida {vida:5.2f} años")
print("  con Wi-Fi y 5 minutos de período:", f"{reporte('Wi-Fi', TAM['bin1'], 300)[2]:.0f} µA, vida {reporte('Wi-Fi', TAM['bin1'], 300)[3]:.2f} años")

# ---- Parte 3: entrega con pérdidas y reenvío tras un corte de cobertura ------------------------------------------------------------------------
print()
print("Parte 3: mensajes sobre un enlace con pérdidas (20 % de pérdida en cada sentido) y reenvío tras una falta de cobertura")
rnd = random.Random(52)
P, MSG, INTENTOS = 0.20, 100_000, 3
q0_entrega = sum(rnd.random() > P for _ in range(MSG))
llegados = duplicados = transmisiones = 0
for _ in range(MSG):
    copias = 0
    for intento in range(INTENTOS):
        transmisiones += 1
        if rnd.random() > P:                                       # el mensaje llegó al servidor
            copias += 1
            if rnd.random() > P: break                             # y su confirmación llegó al equipo: no se reintenta
    llegados += copias > 0; duplicados += copias > 1
print(f"  sin confirmación (a lo sumo una vez): llega el {q0_entrega / MSG * 100:.1f} % (teoría 80,0 %), 1,00 transmisiones por mensaje")
print(f"  con confirmación y hasta {INTENTOS} intentos (al menos una vez): llega el {llegados / MSG * 100:.2f} % (teoría {(1 - P ** INTENTOS) * 100:.1f} %), "
      f"con duplicados en el {duplicados / MSG * 100:.1f} % de los mensajes y {transmisiones / MSG:.2f} transmisiones por mensaje")
REG_MIN, CAP_REG, LOTE, HDR = 1, 43_200, 30, 16
bytes_lote = HDR + LOTE * 8
t_lote, mc_lote, _, _ = reporte("radio propia (la del registrador)", bytes_lote, 900)
def miles(n): return f"{n:,}".replace(",", " ")
for dias in (9, 40):
    pendientes = dias * 24 * 60 * REG_MIN
    perdidas = max(0, pendientes - CAP_REG)
    guardadas = pendientes - perdidas
    mensajes = math.ceil(guardadas / LOTE)
    print(f"  falta de cobertura de {dias} días: {miles(pendientes)} registros; se pierden {miles(perdidas)}; al volver la cobertura hacen falta {miles(mensajes)} mensajes de {bytes_lote} B "
          f"({miles(round(mensajes * mc_lote))} mC = {mensajes * mc_lote / 3600:.2f} mAh = {mensajes * mc_lote / 3600 / CAP * 100:.2f} % de la pila); a un mensaje cada 5 s: {mensajes * 5 / 60:.0f} minutos")

# ---- Parte 4: actualización escalonada de una flota ------------------------------------------------------------------------------------------------------
N, Q, ETAPAS = 17_800, 0.02, (0.01, 0.10, 0.50, 1.0)
todos = N * Q
esperado, vivo, previo = 0.0, 1.0, 0
for f in ETAPAS:
    n = round(N * f) - previo; previo += n
    esperado += vivo * n * Q                                       # los equipos de la etapa se dañan aunque se detecte después
    vivo *= (1 - Q) ** n                                           # la campaña sigue solo si no hubo ninguna falla en la etapa
print()
print(f"Parte 4: una versión defectuosa daña al {Q * 100:.0f} % de los equipos que la reciben; flota de {N:,} equipos".replace(",", " "))
print(f"  actualizando todos a la vez se dañan en promedio {todos:.0f} equipos")
print(f"  por etapas ({', '.join(f'{f * 100:.0f} %' for f in ETAPAS)}), deteniendo la campaña si una etapa tiene una sola falla: {esperado:.1f} equipos dañados en promedio")
d1 = 1 - (1 - Q) ** round(N * ETAPAS[0])
print(f"  la primera etapa ({round(N * ETAPAS[0])} equipos) detecta el problema con probabilidad {d1 * 100:.1f} %; el escalonamiento reduce el daño unas {todos / esperado:.0f} veces")

Resultado, parte 1: una medida ocupa 74 B en JSON, 45 B en CBOR y 16 B en binario; quince medidas, 320, 171 y 136 B (el JSON de una medida es 4,6 veces el binario; con quince, 2,4 veces). Parte 2: un reporte de 16 B cada 15 minutos con dos pilas AA da, para la radio propia, 401 ms, 11,2 mC, 15,98 µA y 7,90 años; BLE, 61 ms, 0,5 mC, 4,04 µA y 17,58 años; LoRa, 126 ms, 5,0 mC, 9,08 µA y 11,58 años; Wi-Fi, 1500 ms, 225,0 mC, 253,50 µA y 0,66 años; celular, 3003 ms, 180,2 mC, 203,67 µA y 0,82 años. Con la radio propia: JSON de una medida 16,13 µA, CBOR 16,06 µA y binario 15,98 µA; quince medidas en JSON 16,74 µA y en binario 16,28 µA. Con Wi-Fi cada 5 minutos: 754 µA y 0,23 años. Parte 3: sin confirmación llega el 80,0 %; con confirmación y 3 intentos, el 99,19 % (teoría 99,2 %) con 18,1 % de duplicados y 1,49 transmisiones por mensaje; tras 9 días sin cobertura hay 12 960 registros (0 perdidos) y 432 mensajes de 256 B cuestan 5086 mC (0,09 % de la pila, 36 minutos); tras 40 días se pierden 14 400 y 1440 mensajes cuestan 16 954 mC (0,31 %, 120 minutos). Parte 4: actualizando 17 800 equipos a la vez se dañan 356; por etapas con parada ante una falla, 4,4 (unas 80 veces menos), y la primera etapa de 178 equipos detecta el problema con probabilidad de 97,3 %.

Probá cambiar en la Parte 2 la corriente de transmisión o el tiempo fijo de un enlace, agregar una tecnología propia, subir el número de medidas por lote o el período de reporte; en la Parte 3, reducir la pérdida a 5 % y ver cómo bajan los duplicados, o aumentar los intentos a 5; y en la Parte 4, cambiar la fracción de equipos dañados o el tamaño de la primera etapa. La lección del programa es que cada decisión de conectividad se puede calcular antes de comprar el módulo, con unas pocas líneas y con las hipótesis a la vista.

11 · Exploración interactiva

La energía de conectarse

El laboratorio implementa el modelo de la Parte 2. Elegís la tecnología de enlace (con parámetros de orden de magnitud supuestos), el formato del mensaje, si se envía una medida o un lote de quince y el período de reporte, y calcula los bytes, el tiempo de radio, la carga por reporte, la corriente media y la vida con dos pilas AA. El resto del circuito consume 3,5 µA (reposo y medidas, como en el tema 51) y la autodescarga son 5,70 µA.

Recorrido guiado

1. Con la radio propia del registrador (binario, una medida, cada 15 minutos): 16 B, 401 ms, 11,24 mC, 15,98 µA y 7,90 años. Es el punto de partida del tema 51, y el 100 % del costo del reporte es el costo fijo de conectarse.
2. Cambiá a JSON con 15 medidas: 320 B, 426 ms, 11,92 mC, 16,74 µA y 7,63 años. Un mensaje veinte veces más grande y con quince veces más datos, y la vida casi no cambia (de 7,90 a 7,63 años). Con este enlace, el tamaño no es el problema; la cantidad de conexiones sí.
3. Elegí BLE: 61 ms, 0,49 mC por reporte, 4,04 µA, 17,58 años. Es la tecnología más barata del laboratorio, a costa de necesitar una pasarela o un teléfono cerca (sección 4).
4. Elegí Wi-Fi: 1500 ms de conexión, 225 mC por reporte, 253,50 µA y 0,66 años: no cumple los 2 años. Cambiá el período a 5 minutos: 753,51 µA y 0,23 años; y a 1 hora: 66,00 µA y 2,39 años, que ya cumple los 2 años pero no el objetivo de 3. El formato no cambia nada: la conexión es el costo.
5. Elegí celular para IoT: 3003 ms y 180 mC por reporte, 203,67 µA y 0,82 años. Lo mismo: una conexión de segundos no es compatible con reportar cada 15 minutos con dos pilas AA. Las soluciones están en reportar menos seguido, agrupar o usar los modos de ahorro de la tecnología (que el laboratorio no modela).
6. Elegí LPWAN tipo LoRa con JSON y 15 medidas: 320 B, 612 ms, 24,48 mC, 30,70 µA y 4,70 años, y el costo de los datos ya es el 84 % del reporte. Pasá a binario con 1 medida: 126 ms, 5,02 mC, 9,08 µA y 11,58 años. Con un enlace lento, el formato y el tamaño sí pesan: es el caso donde comprimir y agrupar con criterio importa.

12 · Método de trabajo

Método: de un dispositivo a un producto conectado

1. Partí de lo que el producto hace sin red: el dispositivo debe cumplir sus funciones críticas (medir, decidir, alarmar, guardar) por sí solo. La conectividad es un complemento, no una dependencia.
2. Escribí los requisitos de conectividad con números: cada cuánto se reporta, qué latencia se tolera para una alarma, cuánto tiempo sin conexión hay que soportar, qué cobertura hay en el sitio y cuántos equipos habrá.
3. Elegí el enlace por la energía y la cobertura, no por la velocidad: calculá la carga por reporte (tiempo fijo + datos) con parámetros del módulo real y recalculá la vida. Descartá lo que no cumple antes de comparar lo demás.
4. Reducí el número de conexiones: agrupá el historial, mandá las alarmas aparte, reportá lo mínimo. Cada conexión tiene un costo fijo que domina.
5. Diseñá los mensajes: formato compacto, cabecera con identificador de equipo, número de secuencia, versión del protocolo y el instante de la medida; servidor idempotente.
6. Diseñá para la red que falla: almacenamiento y reenvío con un registro dimensionado para el tiempo sin conexión que se tolera, reconexión con espera creciente y azar, timeouts en todo.
7. Resolvé la identidad y la seguridad antes de producir: identidad única por equipo, aprovisionamiento en fábrica, cifrado, firma de actualizaciones, rotación y revocación.
8. Planificá la flota desde el principio: el equipo informa su versión y su salud, la nube mantiene el estado de cada uno, y las actualizaciones son escalonadas y con criterio de parada.
9. Probá la red como un componente más: enlace con pérdidas, cortes largos, caída del servidor, reconexión masiva, saltos del reloj. Medí la energía con la radio real.
10. Calculá el costo por equipo por año durante toda la vida (datos, nube, soporte, reposición) y planificá el fin de los servicios de los que depende el producto.

13 · Comprensión

Confusiones frecuentes

14 · Práctica guiada

Ejercicios

1. Wi-Fi con el objetivo de diseño

Un reporte por Wi-Fi cuesta 225 mC. El circuito (reposo y medidas) consume 3,5 µA y el objetivo de diseño del registrador es 53,28 µA para el circuito completo. ¿Cada cuánto como mínimo se puede reportar?

2. Cuánto importa el formato

Un reporte pasa de 16 B (binario) a 74 B (JSON). ¿Cuánta carga adicional cuesta en la radio propia (100 kb/s, 28 mA) y en un enlace lento (5 kb/s, 40 mA)? ¿Qué porcentaje del reporte de 16 B es cada una?

3. Agrupar o no agrupar

En el enlace lento (0,10 s fijos, 5 kb/s, 40 mA), ¿cuánto cuesta enviar 15 medidas en 15 reportes separados de 16 B, y en un solo mensaje de 136 B? ¿Cuántas veces menos?

4. Entrega con confirmación

Un enlace pierde el 10 % de los mensajes en cada sentido y se permiten 3 intentos. ¿Con qué probabilidad llega el mensaje al servidor? ¿Cuántas transmisiones se esperan por mensaje?

5. Etapa inicial de una campaña

Una flota de 10 000 equipos recibe una versión que daña al 1 % de los que la instalan. Se actualiza primero el 2 %. ¿Con qué probabilidad esa etapa detecta el problema (al menos un equipo dañado)? ¿Cuántos equipos se habrían dañado actualizando todos a la vez?

6. Reintentos sin espera creciente

Cada intento de conexión fallido cuesta 11,2 mC. Se compara reintentar cada 5 s con la espera creciente que llega a un máximo de 15 minutos (900 s). ¿Cuánta carga por hora cuesta cada política, y cuánto tarda cada una en agotar una pila de 1500 mAh si la falta de cobertura dura indefinidamente?

15 · Síntesis y cierre del curso

Ideas para recordar

Cierre

Empezamos preguntando qué es un sistema embebido y terminamos con un producto que mide, decide, ahorra energía, se recupera de sus fallas, se actualiza solo y se mantiene durante años. En el camino, cada tema agregó una herramienta; los once bloques juntos construyen un método. Lo que conviene llevarse no son los detalles de un chip, que cambiarán, sino la costumbre de hacer las cuentas antes de construir, medir después de construir y dejar escrito por qué. Esa costumbre vale para un sensor de 8 bits y para una flota conectada de miles de equipos.

El mejor siguiente paso es el más simple: elegir un proyecto propio, escribir sus cinco requisitos con números, construir un modelo de veinte líneas, medirlo en una placa real y comparar. Donde lo previsto y lo medido no coincidan, está lo que todavía no se sabía. Mucho éxito con ese primer producto.