Todo diagrama de proveedor sobre un despliegue de IoT tiene tres cajas: sensor, nube, dashboard. El dibujo no está equivocado. En una plataforma decente, conectar esas piezas es la parte fácil.
Donde el dibujo se equivoca es en el tiempo. Un despliegue real es una secuencia de pasos poco vistosos con un orden de dependencias, y la mayoría de los equipos que lo hacen por primera vez los ejecutan al revés: primero el dashboard porque es entretenido, después el hardware porque ahí el proyecto empieza a parecer real, y los usuarios al final porque alguien recuerda, una semana antes del go-live, que el personal del cliente necesita iniciar sesión. Cada vez que se invierte ese orden, cuesta semanas.
Lo que sigue es un despliegue genérico recorrido en orden: un integrador de sistemas que instala sensores de temperatura y de apertura de puerta en 40 cámaras frigoríficas de 6 sitios para un distribuidor de alimentos. Cambia las cámaras por tanques o medidores; las fases son las mismas.
Alcance y criterios de aceptación (semana 1 a 2)
“Queremos monitorear las cámaras frigoríficas” es un deseo, no un alcance. El despliegue necesita una definición de terminado por escrito. Aquí: temperatura cada 10 minutos, puerta abierta más de 5 minutos marcada como evento, alarma por encima de 5 C durante 20 minutos, notificación push al encargado del sitio y correo al responsable de operaciones, una página por sitio con el historial de cada cámara.
Dos semanas parece mucho para un documento. El tiempo se va en esperar: el responsable de operaciones y el contratista de mantenimiento no se ponen de acuerdo sobre quién responde las alarmas, y nadie lo resuelve hasta que lo preguntas por escrito. Omitir esta fase mueve esas dos semanas al go-live, donde cuestan más. Hay más en la guía de planificación para PMs no técnicos.
Inspección de sitio y prueba de conectividad (semana 2 a 3)
Las cámaras frigoríficas son cajas de metal con puertas aisladas. A la radio no le gustan. Antes de pedir 40 sensores hay que saber, cámara por cámara, si un gateway LoRaWAN en el pasillo alcanza el interior con la puerta cerrada, y si ese gateway tiene energía y backhaul.
Una persona, dos sensores de prueba, un gateway, un día por sitio. La inspección reescribe la lista de hardware: dos sitios necesitan un segundo gateway y uno no tiene señal celular en la sala de máquinas. Descubrirlo ahora cuesta una semana; descubrirlo durante la puesta en marcha cuesta una visita extra a cada sitio. El alcance de LoRaWAN en el mundo real tiene los números.
Compra de hardware (semana 3 a 8) y configuración de la plataforma (semana 3 a 5), en paralelo
Los sensores y los gateways llegan en cuatro a seis semanas. Quien lo hace por primera vez espera. Los equipos con experiencia construyen todo el lado de la plataforma en esa ventana, sin hardware en la mano: es la mayor ganancia de calendario del proyecto.
En TagoIO el orden es:
- Crea un Device con el Connector del modelo de sensor y el Network del proveedor LoRaWAN. El Connector decodifica los bytes del fabricante en temperatura, estado de la puerta y batería.
- Pasa un uplink de ejemplo de la hoja de datos por el Payload Parser y verifica que produzca los nombres de variables que van a usar el dashboard y las alertas. Las conversiones de unidades y los cambios de nombre entran en el Parser ahora, una sola vez.
- Define la convención de tags antes de que exista cualquier otra cosa: site, room,
asset_type, customer. Los dashboards, las alertas, las políticas de acceso y los reportes filtran por ellos. - Arma un Blueprint Dashboard que resuelva los Devices por tag. Un solo dashboard sirve para las 40 cámaras y para todas las que vengan después. Envía datos simulados al Device de prueba para que los widgets tengan algo que mostrar.
Dos semanas de un ingeniero. Cuando llega el hardware, la plataforma está terminada, no empezada.
Puesta en marcha del hardware y disciplina de tags (semana 8 a 10)
La instalación toma lo que toma: un sensor por cámara, gateways en la pared, etiquetas en todo. Seis sitios a dos días cada uno son dos semanas para un instalador.
El lado de la plataforma es donde rinde la disciplina de tags. Para cada sensor, crea el Device desde el mismo Connector, pon en sus tags la cámara en la que queda instalado y confirma el primer uplink. La cámara 17 del sitio 3 aparece en el Blueprint Dashboard en el momento en que su Device tiene los tags correctos y un dato. Nadie construye un dashboard durante la puesta en marcha. Si alguien lo está haciendo, se omitió la fase anterior.
Mantén una planilla de puesta en marcha: EUI del dispositivo, sitio, cámara, fecha de instalación, instalador. Cuando un sensor se queda mudo en el tercer mes, esa planilla convierte una tarde de trabajo en un arreglo de cinco minutos.
Alertas con Actions, y quién las recibe (semana 10)
Los umbrales ya venían del alcance; la semana se va en acordar quién recibe qué. Configura Actions que se disparen con la condición de la variable (temperatura por encima del límite durante el tiempo acordado, puerta abierta demasiado tiempo) y envíen una notificación push a los usuarios de TagoRUN de ese sitio más un correo al responsable de operaciones. Una Action por tipo de alarma, filtrada por tag, cubre todas las cámaras. Agrega también una Action de “dispositivo sin datos por 2 horas”: una batería agotada es la falla más común y no produce datos, así que ningún umbral se dispara nunca. Los primeros días, dirige todo hacia ti.
Acceso de usuarios finales con TagoRUN (semana 10 a 11)
Los encargados de sitio nunca ven el Admin de TagoIO. Entran a un portal de TagoRUN con la marca del integrador, en la web y en la app móvil de TagoRUN para que las notificaciones push lleguen a sus teléfonos. Una política de Access Management le da a cada usuario el Blueprint Dashboard limitado a los Devices cuyo tag site coincide con el suyo; el responsable de operaciones recibe una política que abarca los seis sitios. Crea los usuarios una semana antes del go-live y recorre la app con un encargado de sitio en una llamada. Sus preguntas se convierten en la primera página del runbook.
Go-live y las primeras dos semanas (semana 11 a 13)
El go-live es un correo que avisa que las alertas ya van al cliente. Después empiezan las falsas alarmas.
Todo despliegue en cámaras frigoríficas produce las mismas dos semanas: el umbral de 5 C se dispara cada vez que un montacargas traba la puerta para reponer mercadería, la alarma de puerta salta durante la limpieza programada y una cámara trabaja más caliente por diseño porque guarda frutas y verduras. Nada de esto se podía saber a partir del documento de alcance. Las Actions pasan a duraciones más largas, se excluye una ventana de limpieza, la cámara 22 recibe su propio umbral a través de un tag. Avisa al cliente de antemano que estas semanas son de ajuste, o va a leer el ruido como un sistema roto.
Entrega a operaciones (semana 13)
La entrega es un documento y una reunión: el runbook (qué significa cada alarma, quién responde, cómo reemplazar un sensor y volver a etiquetar su Device), la planilla de puesta en marcha, los umbrales vigentes y un responsable con nombre propio en cada lado. Si se vende como servicio administrado, aquí arranca la cuota mensual y aquí termina el presupuesto del proyecto.
El tercer mes
Para el tercer mes el despliegue es aburrido, que es justamente el objetivo. Entonces llegan los pedidos no planificados.
El volumen de datos pasa a ser un rubro de costo. Cuarenta sensores cada 10 minutos son más de 5.700 lecturas por día, y el historial en crudo no hace falta más allá de unos meses. Data Retention en cada Device le pone un techo.
El cliente pide un reporte mensual. Un Analysis programado calcula los minutos fuera de rango y los minutos de puerta abierta por sitio, y escribe un resumen para un widget o un correo. Un día de código, porque los tags ya dividen los datos por sitio.
El cliente quiere dos sitios más. Expandir es inspección, hardware, Devices con el mismo Connector y el nuevo valor de site, y usuarios con una política para ese sitio. El dashboard, las Actions y el reporte ya funcionan.
Trece semanas hasta la entrega: el trabajo de plataforma cabe dentro del plazo del hardware y la mayor parte del calendario se va esperando a personas, a la radio y a las entregas. Las tres cajas nunca fueron el problema.
