Aplicación técnica · Planta conectada
Conectar una estación de bombeo sin rehacer la integración
Presión, nivel y estados de operación pueden alimentar históricos y supervisión sin trasladar el control de las bombas a una plataforma remota. La integración empieza por definir qué significa cada dato.
Una estación abastece agua desde un tanque a una red interna. Tiene dos bombas con alternancia, una bomba regulada mediante variador, un PLC y una HMI local. La estación cuenta con medición de presión de descarga y nivel del tanque, y comprobación de flujo en la impulsión. El variador regula la presión; la señal de flujo permite verificar que, cuando existe demanda y una bomba está en marcha, el agua circula. El operador puede ver la presión y el nivel, pero cuando un sector informa falta de agua tiene que reconstruir qué ocurrió: qué bomba estaba seleccionada, si hubo una falla y cuánto duró la caída de presión.
Trabajamos con una estación de bombeo simulada como caso de aplicación. Primero definimos la conexión de sus datos; luego analizamos la recuperación de sus equipos y sus alarmas. El caso no presenta resultados de ensayos: la arquitectura hidráulica y las condiciones de operación se verifican para cada instalación real.
Empezar por la pregunta del operador
Para explicar una caída de presión necesitamos relacionar la medición con el estado de la estación. Una curva aislada puede mostrar cuándo empezó el problema, pero no si la bomba estaba detenida por falta de nivel, en modo manual o fuera de servicio.
El relevamiento reúne presión de descarga, nivel del tanque, presencia de flujo en la impulsión, marcha confirmada de cada bomba, selección manual o automática, disponibilidad y código de falla del variador. La orden de marcha y la confirmación de funcionamiento deben registrarse como señales distintas: pedir que un motor arranque no demuestra que esté girando ni que entregue el caudal esperado.
También definimos el origen de cada variable. Algunas llegan al PLC por señales de 4–20 mA; otras provienen de contactos o comunicaciones. La selección del instrumento exige revisar rango, conexión al proceso, materiales y condiciones ambientales. Conectar el dato no corrige una medición mal elegida o calibrada.
Dar identidad y contexto a las señales
Antes de construir el tablero, elaboramos un diccionario de datos. Para cada variable indicamos equipo, nombre, unidad, escala, origen, frecuencia de adquisición y tratamiento de valores inválidos. Una presión de 4,2 necesita unidad y fecha; un estado de marcha necesita identificar la bomba.
Conservamos además la diferencia entre una medición nueva y el último valor recibido. Si se pierde comunicación, mostrar una presión antigua como vigente puede llevar a una interpretación incorrecta. La pantalla debe indicar la antigüedad del dato y la condición de comunicación. Un valor ausente tampoco debe convertirse automáticamente en cero.
La frecuencia se define según el uso. Un histórico destinado a revisar tendencias no necesita necesariamente la misma resolución que un análisis de transitorios. Cuando interesa capturar cambios rápidos, verificamos si sensores, adquisición y almacenamiento pueden registrarlos; un tablero IIoT de actualización lenta no reemplaza ese ensayo.
Conectar supervisión conservando el control local
La documentación de ThingsBoard IoT Gateway describe un conector OPC UA que permite configurar conexión, seguridad y mapeo de atributos y series temporales. Su disponibilidad no implica que cualquier PLC tenga un servidor OPC UA: debemos comprobar modelo, firmware, licencias e interfaces, o incorporar una capa compatible de adquisición.
En esta primera etapa habilitamos lectura de las variables necesarias. El PLC conserva la alternancia, las condiciones de marcha y la respuesta prevista ante fallas. La HMI sigue disponible para la operación local. La plataforma reúne históricos y estados para consultar la estación desde otros puestos autorizados.
El diseño de red evita exponer directamente el controlador a Internet. La guía NIST SP 800-82 Rev. 3 aborda la seguridad OT considerando disponibilidad, desempeño y seguridad física. Aplicamos esos criterios al segmentar comunicaciones y definir accesos; cada implementación requiere revisar la arquitectura existente.
Comprobar que los datos pueden reutilizarse
En Del sensor al KPI analizamos cómo relacionar señales para construir indicadores. Aquí comprobamos otra condición: que la adquisición pueda alimentar una aplicación nueva conservando el significado de esas señales.
Separar adquisición, diccionario de datos y visualización facilita agregar después una aplicación de mantenimiento. Sin esa separación, cada nueva pantalla puede terminar usando sus propios nombres y reglas para la misma bomba.
La aceptación incluye comparar lecturas con la HMI, verificar escalas y horarios, provocar una pérdida controlada de comunicación y comprobar cómo aparece el dato vencido. También probamos una exportación de históricos y documentamos las configuraciones necesarias para reconstruir la integración. En un entorno de prueba conectamos un segundo consumidor al punto de acceso previsto, verificando permisos, carga y frecuencia. Comparamos nombres, unidades y marcas de tiempo; anotamos qué configuraciones son reutilizables y cuáles dependen de la plataforma. Un protocolo abierto facilita el intercambio, pero no garantiza que pantallas, reglas o históricos migren sin trabajo adicional.
En Nodira resolvemos este recorrido desde las señales disponibles hasta su presentación y comprobación: definimos el alcance, seleccionamos la adquisición, configuramos la conectividad y dejamos identificadas las variables y dependencias. El primer paso es relevar una estación y una pregunta operativa concreta. Con esa base podemos dimensionar una integración que siga siendo mantenible cuando se agreguen equipos o aplicaciones.
Continuar la serie
Estación de bombeo
Revisemos tu instalación.
Compartí los equipos instalados y la condición operativa que necesitás resolver.