Recopilación de datos, panel local y envío a una plataforma gubernamental en una planta de tratamiento de aguas residuales

Durante el relevo de turno, a menudo hay que consultar por separado las lecturas de los instrumentos de calidad del agua, el estado de las bombas y los soplantes en el PLC y los caudales anotados en los registros del turno. Al preparar el envío de datos, también es necesario comprobar los nombres de los puntos de medida, las horas de muestreo y el formato exigido por la plataforma. Los datos ya están en los equipos, pero falta un flujo que facilite su consulta e integración.

Tomemos como ejemplo un escenario ilustrativo de una planta de tratamiento de aguas residuales típica: una pasarela industrial inteligente Woody lee los datos que los equipos ponen a disposición, los presenta de forma centralizada en una App local de la pasarela y después los estructura y envía según los requisitos de la plataforma gubernamental. Es un planteamiento de integración genérico, no un proyecto ya ejecutado para un cliente concreto, ni una indicación de que haya superado la aceptación de una plataforma regulatoria de una jurisdicción determinada.

Primero, incorporar los datos de los equipos

En este ejemplo se utiliza WD2EC, aprovechando sus dos puertos Ethernet, sus múltiples puertos serie y su conectividad 4G. Un PLC compatible con Modbus TCP se conecta a Ethernet2; los instrumentos de medición en línea compatibles con Modbus RTU se conectan por RS485 a COM1. La pasarela lee las variables según el mapa de direcciones que facilita el equipo. El intervalo de adquisición, los tipos de datos y los parámetros de comunicación deben configurarse conforme a los requisitos de los equipos.

Entre las variables que podrían incorporarse están el caudal, el nivel, el pH, la demanda química de oxígeno (COD), el nitrógeno amoniacal y el estado de funcionamiento de bombas y soplantes. Son únicamente puntos de medida candidatos: el alcance real de la adquisición depende de los instrumentos instalados, los datos que ya reúne el PLC y los permisos de acceso disponibles. No significa que todos los equipos puedan conectarse directamente. La pasarela lee datos de comunicación; no mide directamente la calidad del agua ni recibe directamente las señales analógicas de los instrumentos en la configuración de este ejemplo.

Tras la conexión, se unifican, según lo acordado, los nombres de las variables, los códigos de los puntos de medida, las unidades, las marcas de tiempo y los estados de validez. Por ejemplo, si se interrumpe la comunicación con un instrumento, debe conservarse la hora de la última actualización y marcarse el dato como no válido, en lugar de seguir tratando la lectura anterior como un valor en tiempo real. Si intervienen tanto la hora del equipo como la de la pasarela, también deben definirse el origen de la hora y el método de sincronización.

El esquema utiliza la conexión 4G de WD2EC como ejemplo de acceso a Internet. Ethernet1 se conecta a la red de gestión de la planta para que el navegador de la sala de control acceda a la pasarela. La planificación de direcciones de las redes de equipos y de gestión, los permisos de acceso y las rutas de salida por 4G deben verificarse con la configuración de red del emplazamiento. No se presupone una conmutación automática entre conexiones cableadas e inalámbricas. La solución puede plantearse con acceso WiFi, 4G o cableado, siempre seleccionando un modelo compatible. Si se cambia a una configuración cableada que conecte tanto Internet como el PLC, se utiliza Ethernet1 para el lado de Internet y Ethernet2 para el lado de los equipos.

Consultar la información de forma centralizada desde la sala de control

El personal de turno no necesita iniciar sesión primero en una plataforma externa en la nube. A través de la red de gestión de la planta, puede utilizar el navegador de un ordenador o de una pantalla de gran formato para acceder a la App local integrada en la interfaz de gestión Web de la pasarela. La página puede organizar los valores actuales por zonas del proceso y mostrar a la vez la hora de actualización y el estado de comunicación. Cuando sea necesario conocer la evolución, se consultan las tendencias históricas guardadas conforme a la política de registro.

Por ejemplo, las unidades de tratamiento, las tuberías y los puntos de medida de caudal y calidad del agua pueden reunirse en un mismo sinóptico de proceso. Junto con los estados de los equipos y las tablas de puntos de medida, permite consultar los datos por zonas en lugar de recorrer una larga lista de nombres de variables.

Demostración del sinóptico de la App local con datos de funcionamiento simulados. Las lecturas, los estados de los equipos y las horas de los eventos son simulados, no mediciones de campo ni registros de aceptación. El proceso real y los puntos de medida deben configurarse según el emplazamiento. La imagen muestra supervisión de solo lectura y no incluye controles de equipos.

Este panel para el tratamiento de aguas residuales no es un producto terminado preinstalado. La pasarela proporciona un entorno para App locales: las páginas concretas se desarrollan con JS/CSS/HTML, el procesamiento de datos y las interfaces de backend se programan en Lua, y los registros históricos pueden almacenarse en el SQLite integrado. La distribución de los puntos de medida, la representación de estados, la frecuencia de registro, las consultas históricas y el alcance de acceso de los usuarios requieren configuración o desarrollo según las necesidades del proyecto.

Con esta organización, el relevo de turno puede apoyarse en una misma página para comprobar «qué se está leyendo ahora», «cuándo se actualizaron los datos» y «con qué equipo se ha perdido la comunicación», en lugar de limitarse a contrastar cifras que parecen normales. El periodo de conservación del histórico, las políticas de muestreo o de registro por cambios y el método de copia de seguridad deben definirse según los recursos de almacenamiento de la pasarela. No se garantiza una conservación ilimitada.

Organizar los envíos según los requisitos de la plataforma gubernamental

La visualización local y el envío de información a la plataforma tienen finalidades distintas: la App se encarga de la consulta en planta y del almacenamiento conforme a la política definida, mientras que el módulo de publicación estructura los datos acordados en los mensajes que exige la plataforma de destino. Ambos pueden utilizar las mismas variables adquiridas y verificadas, pero «visible en la página» no equivale a «recibido por la plataforma».

Antes de la integración, deben obtenerse la documentación de la interfaz que ofrece la plataforma y la autorización de acceso. Es necesario definir los códigos de los puntos de medida, el formato de las marcas de tiempo y la zona horaria, las unidades y los criterios de definición de los datos, la representación de su validez, el método de autenticación, el intervalo de envío y el significado de las respuestas. La pasarela admite vías de publicación como HTTP/HTTPS y MQTT, y permite programar una lógica de publicación personalizada en Lua. No obstante, la vía que se utilice y la estructura de los mensajes deben ajustarse a los requisitos de la plataforma de destino.

Si la plataforma exige un protocolo específico o un procedimiento de acceso especial, habrá que confirmar por separado su viabilidad y completar la adaptación y las pruebas de integración. Esta solución no afirma que admita protocolos aún no confirmados, como HJ 212, ni equipara la conectividad de red con la obtención de la habilitación para conectarse al sistema regulatorio.

El proceso de publicación también debe registrar los fallos de envío, las respuestas de error y las confirmaciones de la plataforma que sea posible obtener. Si el panel muestra el estado «recibido», debe basarse en la confirmación correspondiente proporcionada por la plataforma. No basta con haber enviado la solicitud o haber almacenado los datos en la caché para considerar que la entrega se ha realizado correctamente.

Distinguir los fallos de adquisición de los fallos de envío

Cuando falla la comunicación con un equipo o los datos no son válidos, primero se marcan los puntos de medida afectados y se gestionan los datos ausentes y los estados no válidos según lo acordado con la plataforma. No se deben utilizar valores antiguos para simular datos normales en tiempo real. Si el problema afecta a Internet o a la conexión con la plataforma, se registra el fallo de envío y se utiliza la capacidad de caché sin conexión de la pasarela según la configuración.

La capacidad de la caché, el tiempo de conservación, el comportamiento al llenarse y la política de reintentos deben definirse durante la implantación. Una vez restablecida la red, los reintentos o envíos de datos pendientes solo se realizan según lo acordado y dentro de la ventana temporal y las reglas de deduplicación que permita la plataforma; no todas las plataformas aceptan el envío posterior de datos históricos. Que un dato esté en caché no significa que la plataforma lo haya recibido, ni permite prometer que nunca se perderán datos. Los estados de la consulta local y del envío al exterior deben presentarse por separado para que el personal de turno pueda identificar en qué etapa se produce el problema.

Qué confirmar antes de la integración

• Equipos y puntos de medida: comprobar los modelos de PLC e instrumentos, los protocolos de comunicación, los mapas de direcciones, los tipos de datos, las unidades y los permisos de lectura; confirmar que los indicadores propuestos tienen una fuente de datos fiable.
• Páginas y registros: definir el alcance del desarrollo de la App local, los criterios para declarar los datos no válidos, el origen de la hora, los permisos de acceso y las políticas de conservación y copia de seguridad.
• Red y plataforma: verificar las redes de gestión y de equipos, la cobertura 4G y las rutas de salida; obtener la interfaz de la plataforma y las autorizaciones, y completar las pruebas de integración de los campos, la autenticación, los intervalos, las respuestas y las reglas de envío de datos pendientes.
• Requisitos regulatorios: confirmar con la autoridad competente o el operador de la plataforma si se permite la conexión directa de la pasarela, si es obligatorio utilizar un dispositivo de adquisición de datos especificado, equipos certificados o una red dedicada, y cuáles son los requisitos de aceptación aplicables.

La visualización de datos operativos de la planta no equivale a resultados de monitorización con validez legal. La pasarela no sustituye la calibración de los instrumentos de calidad del agua, los equipos de monitorización exigidos legalmente ni las determinaciones de la plataforma gubernamental. Este ejemplo se limita a la lectura, consulta y envío de datos; no se extiende al control remoto, la dosificación automática de reactivos ni los enclavamientos de seguridad.

De consultas dispersas a un flujo de datos claro

Para las plantas de tratamiento de aguas residuales que ya disponen de PLC e instrumentos de medición en línea con capacidad de comunicación, esta solución enlaza la lectura de los equipos, la consulta local y el envío a la plataforma. El personal de turno puede contrastar la información operativa de forma centralizada desde el navegador, mientras que el integrador adapta los mensajes conforme a una interfaz claramente definida. Lo esencial no es añadir otra tabla aislada, sino disponer de una base verificable para el origen de los datos, la hora de actualización, su validez y el resultado del envío, manteniendo al mismo tiempo los límites de responsabilidad de los equipos, la aplicación y la plataforma regulatoria.