Guía técnica · Capítulo 06 de 06

Cómo pasar de un piloto de ThingsBoard a una operación mantenible

¿Cuándo está listo un piloto de ThingsBoard para ampliarse? Cuando el flujo completo está probado, los fallos son observables y existen documentación, responsables, respaldo y criterios de aceptación.

Lectura · 8 min

Arquitectura · Continuidad

Una demostración que nadie puede repetir

El dashboard mostró datos durante una reunión. Dos semanas después nadie recuerda qué versión del gateway se instaló, qué claves se transformaron ni cómo se recupera la conexión. La demostración probó que era posible mostrar valores; no probó que el sistema pudiera operarse.

El objetivo de un piloto industrial no es acumular pantallas. Debe reducir incertidumbre técnica y operativa.

Elegir un alcance que pueda cerrarse

Un piloto útil combina:

  • uno o pocos activos conocidos;
  • variables con fuente y unidad confirmadas;
  • una condición que alguien necesita reconocer;
  • una respuesta que puede ejecutarse;
  • una ventana suficiente para observar operación normal y excepciones.

Acotar no reduce la calidad: permite comprobar el recorrido completo antes de sumar activos, variables o funciones.

Caso integrador: monitoreo del vuelco de efluentes

Nodira ya implementó un paquete industrial para esta aplicación. El conjunto de instrumentación cubre pH con temperatura y conductividad, oxígeno disuelto, turbidez, demanda química de oxígeno (DQO) y caudal/nivel. Estas son funciones de medición; no expresan una cantidad física exacta de sensores o instrumentos.

El caso integra el recorrido desarrollado en la serie: campo, tablero local con adquisición, control y visualización, conectividad celular, publicación MQTT, ThingsBoard y dashboard actual e histórico. Reportes periódicos y avisos ante eventos son extensiones posibles cuando se definen reglas, destinatarios y respuesta.

Para reproducir el enfoque hay que validar la selección para cada vuelco, matriz, método y requerimiento aplicable; luego definir instrumentación, adquisición, frecuencia, calidad del dato y comportamiento ante fallas. También corresponde acordar propiedad del dato, accesos, continuidad, mantenimiento y calibraciones. El antecedente no prueba cumplimiento normativo, precisión, homologación, resultados ni validez ante autoridades.

La ingeniería integral abarca integración de señales, montaje, calibración inicial, pruebas de comunicación, puesta en marcha, documentación y capacitación. La experiencia ayuda a ordenar esas tareas; no permite anticipar resultados cuantitativos sin medir el proceso específico.

Antes de desarrollar conviene acordar el funcionamiento esperado: alcance incluido y excluido, equipamiento, comunicaciones, señales, condiciones iniciales, modos, transiciones, restricciones y criterios de aceptación. Ese acuerdo evita que una demostración parcial se convierta en especificación implícita y permite gestionar revisiones sin perder trazabilidad.

Criterios de aceptación por capa

Adquisición

Cada variable llega con identidad, tipo, unidad y timestamp correctos. Se prueba pérdida de red, almacenamiento local, reconexión, reinicio y recuperación. Se documenta qué datos pueden perderse cuando el buffer alcanza su límite.

Se diferencia señal cruda, valor escalado y variable calculada, incluida la versión de cualquier tabla o relación de conversión. Las funciones deshabilitadas, simuladas o con calibración pendiente/error no se presentan como mediciones válidas.

Modelo

Dispositivos, activos y relaciones corresponden a la planta y pueden ampliarse sin renombrar todo el sistema. Las convenciones distinguen telemetría, atributos y estados de calidad.

Procesamiento

Las reglas se prueban con valores normales, límites, persistencia, histéresis, datos faltantes, duplicados y tardíos. Los caminos de falla quedan conectados y observables. Si el orden es material, la cola se configura y verifica para conservarlo en el alcance necesario.

Visualización

El usuario identifica el activo, la última actualización y la condición relevante. Puede pasar de resumen a detalle sin perder contexto. La vista funciona en los dispositivos previstos y no expone información a roles incorrectos.

Alarmas y respuesta

Crear, reconocer y cerrar una alarma tiene significado acordado. Hay responsable, canal, tiempo de respuesta y evidencia de intervención. Una falla de notificación se distingue de una condición de proceso.

Alarmas y protecciones se documentan por separado. Una alarma informa y organiza respuesta; una protección actúa sobre el proceso mediante la capa de control definida. Probar una notificación en ThingsBoard no valida una función de seguridad o enclavamiento.

Operación de plataforma

Existe inventario de componentes y versiones, respaldo de configuración, monitoreo, procedimiento de actualización y una restauración ensayada. Los secretos no quedan en documentos o repositorios sin protección.

Medir la calidad del dato

La cantidad de mensajes recibidos no alcanza. Conviene observar completitud, atraso, duplicados, valores inválidos y tiempo desde la última actualización. La frecuencia se define por la decisión: enviar cada segundo una temperatura que cambia lentamente puede aumentar almacenamiento sin aportar respuesta; reportar cada hora un estado crítico puede ocultar una parada.

El Gateway ofrece estrategias de reporte por recepción, cambio o período, según conector y configuración. El ajuste combina la dinámica del proceso, relevada por Nodira, con la capacidad de la infraestructura. Operación valida que la reducción de datos no esconda eventos relevantes.

Transferir antes de escalar

La puesta en marcha termina cuando el equipo puede mantener el sistema. La entrega debería incluir:

  • diagrama de flujo y fronteras de responsabilidad;
  • inventario de dispositivos, fuentes y credenciales administradas;
  • diccionario de variables;
  • export o control de versiones de dashboards y reglas;
  • matriz de alarmas;
  • registro de modos, secuencias, transiciones y restricciones relevantes;
  • estados y permisos de mantenimiento, calibración y simulación;
  • procedimientos de diagnóstico, respaldo y restauración;
  • registro de pruebas y excepciones conocidas;
  • responsables de plataforma, integración y respuesta operativa.

Luego se decide la expansión. Agregar diez activos similares puede reutilizar perfiles y convenciones; incorporar otra planta o un protocolo distinto puede requerir nueva arquitectura.

Cierre de la serie

ThingsBoard reúne conectividad, modelado, procesamiento, alarmas y visualización. Nodira convierte esas capacidades en una solución industrial mediante relevamiento, integración, reglas, pruebas y puesta en marcha. El resultado depende de una responsabilidad compartida: OT conserva el control que le corresponde, infraestructura opera la plataforma, ciberseguridad aprueba la exposición y los usuarios sostienen la respuesta.

La primera conversación puede empezar con una sola pregunta: ¿qué decisión debería tomar hoy alguien que todavía no tiene el dato correcto a tiempo?

Fuentes técnicas

Documentación oficial consultada.

Referencias utilizadas para verificar capacidades, límites y criterios técnicos desarrollados en este capítulo.

También podés consultar el centro de recursos técnicos de Nodira.

Evaluar una aplicación

Empecemos por un proceso y una decisión operativa concretos.

Contanos qué fuentes existen, cómo opera el proceso y qué debería ocurrir ante una desviación. Con ese contexto podemos definir un piloto proporcionado y verificable.