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

Qué lugar ocupa ThingsBoard entre OT y operación

¿Qué función cumple ThingsBoard entre los sistemas OT y la operación? Centraliza datos, reglas y visualización, mientras el control y las responsabilidades permanecen en los sistemas y equipos definidos por la arquitectura.

Lectura · 6 min

Integración OT · Datos

Cuando la variable existe, pero llega tarde a la decisión

Un variador registra corriente, estado y fallas. El PLC utiliza parte de esa información para gobernar el equipo. El operador ve otra parte en la HMI. Mantenimiento recibe un aviso cuando la parada ya ocurrió. La variable existe, pero no está disponible con el contexto y el recorrido que necesita quien debe actuar.

En ese escenario, ThingsBoard puede funcionar como una capa transversal. La documentación oficial describe una plataforma capaz de conectar dispositivos, administrar entidades, almacenar datos temporales, ejecutar reglas y construir dashboards. El flujo básico es reconocible: una fuente se autentica, publica un mensaje, la plataforma lo transforma en un formato común, el Rule Engine lo procesa y una acción lo guarda, genera una alarma o lo envía a otro sistema.

Ese recorrido no determina por sí solo qué dato conviene enviar ni qué sistema debe seguir siendo responsable del control.

Qué aporta la plataforma

ThingsBoard distingue entre telemetría y atributos. La telemetría conserva valores asociados a una marca de tiempo: presión, corriente, estado, contador o temperatura. Los atributos representan información más estable o el último estado conocido: ubicación, capacidad nominal, versión o configuración. Dispositivos, activos y relaciones permiten representar equipos físicos, sectores y jerarquías.

Sobre ese modelo, los dashboards pueden combinar valores actuales, tendencias, tablas y alarmas. El Rule Engine recibe mensajes y aplica cadenas de filtrado, enriquecimiento, transformación y acción. Estas piezas facilitan que datos provenientes de tecnologías distintas lleguen a una interfaz y a una lógica común.

La capacidad es amplia, pero no conviene interpretar “plataforma común” como “única plataforma”. Un PLC debe conservar las funciones deterministas y de seguridad para las que fue diseñado. Un SCADA puede seguir siendo la interfaz de control del proceso. Un historiador regulado o un CMMS mantienen responsabilidades propias. ThingsBoard puede complementar esos sistemas con una vista distribuida, una lógica de notificación o una integración; el límite se define en la arquitectura.

Qué debe resolver la ingeniería de Nodira

La primera tarea no es crear widgets. Es establecer un contrato de datos:

  • qué activo origina cada señal;
  • nombre, tipo y unidad de cada variable;
  • marca de tiempo que se conservará;
  • frecuencia y condición de reporte;
  • tratamiento de valores inválidos, duplicados o tardíos;
  • comportamiento esperado ante pérdida de comunicación;
  • dueño del dato y sistema que conserva la autoridad.

Nodira releva las fuentes OT, mapea dispositivos y activos y prueba el recorrido completo. Junto con operación y mantenimiento se determina qué significa una desviación y qué sistema recibe el resultado. La experiencia previa ayuda a identificar dependencias y fallas de puesta en marcha, pero no reemplaza la validación de cada proceso.

Un antecedente concreto

Nodira implementó un paquete industrial para monitorear el vuelco de efluentes. En campo se observan variables de calidad del efluente y condición hidráulica; el conjunto de instrumentación llega a un tablero local con adquisición, control y visualización. Desde allí, una conexión celular publica datos por MQTT hacia ThingsBoard, donde un dashboard permite consultar información actual e histórica.

La selección no es universal. Para trasladar el patrón hay que relevar el vuelco, la matriz, los métodos y los requerimientos aplicables, y definir qué decisiones debe habilitar cada vista. ThingsBoard recibe, conserva y muestra la información; la integración de señales, el montaje, la calibración y las pruebas determinan si ese recorrido representa correctamente el proceso.

Una frontera útil

ThingsBoard ofrece un lenguaje común entre campo y operación. La selección de señales, el modelo y la integración quedan del lado de la ingeniería; el proceso conserva la autoridad sobre cada condición. Con esa frontera clara, el siguiente paso es ingresar datos sin perder identidad, tiempo ni calidad.

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.