Escenario de aplicación: consulta centralizada de datos de equipos de varias fábricas

Imaginemos una empresa manufacturera con talleres de producción en distintas ubicaciones. Al preparar una reunión de coordinación de la producción, la persona responsable necesita preguntar a cada fábrica por el estado de los equipos y el avance de la producción: algunas envían fotos de las pantallas de las máquinas, otras entregan tablas rellenadas a mano y otras siguen esperando una comprobación en planta. Cuando por fin se reúne toda la información, el estado que muestran las imágenes puede haber cambiado.

El problema no es solo la distancia entre fábricas, sino la falta de un punto de acceso común a la información. Si los gateways industriales inteligentes de cada fábrica adquieren los datos de los equipos y los envían a una plataforma unificada, primero se pueden consultar de forma centralizada los estados y contadores de los equipos conectados y después contactar con cada planta para aclarar cuestiones concretas. El gateway se encarga de proporcionar los datos; la plataforma organiza la información de las distintas fábricas en páginas útiles para su consulta.

Obtener primero los datos necesarios de cada fábrica

No hace falta trasladar a la sede central todos los parámetros de los equipos desde el principio. Para la coordinación diaria, se puede comenzar por los identificadores de los equipos, su estado de funcionamiento, las alarmas existentes y los valores de los contadores que puedan servir para las estadísticas de producción.

Los gateways industriales inteligentes de Woody admiten la adquisición de datos de diversos PLC/CNC de uso habitual. En cada fábrica, el personal técnico comprueba el modelo concreto del equipo, sus interfaces, protocolos y permisos de lectura. Después configura en la interfaz web de administración del gateway los controladores compatibles, los parámetros de comunicación y los puntos de datos, y contrasta los valores leídos con la pantalla del equipo o con la lógica de la instalación.

Por ejemplo, el contador de un centro de mecanizado puede indicar ciclos de mecanizado, no piezas conformes. Para determinar si sirve para calcular la producción, hay que verificar las señales del equipo y los criterios de recuento de la planta. No se puede cambiar directamente el nombre de un valor adquirido por el de «producción».

El modelo de gateway se elige según las interfaces y las condiciones de red de cada instalación. Un despliegue en varias fábricas tampoco exige utilizar el mismo modelo de hardware en todas ellas. Primero conviene obtener correctamente los datos clave y después ampliar la integración de forma gradual.

Un mismo campo debe tener un mismo significado

Al consultar datos de varias fábricas, el problema más habitual no es que falte un gráfico, sino que los campos con el mismo nombre tengan significados diferentes. En una fábrica, «En funcionamiento» puede indicar mecanizado automático; en otra, quizá solo que el equipo está encendido. Mostrar ambos valores en una misma columna puede llevar a interpretaciones erróneas.

Antes de la integración, se deben acordar los identificadores de fábricas y equipos, el significado de los estados, los criterios de recuento, las unidades y el momento de adquisición. Los identificadores de los equipos deben ser únicos dentro del ámbito acordado. Los estados que no tengan una correspondencia clara no deben clasificarse a la fuerza: pueden mostrarse explícitamente como «Desconocido» o «Pendiente de confirmar».

Para los resúmenes por turno o por día, también hay que definir las zonas horarias, los límites de los turnos y el tratamiento de los reinicios de los contadores. No se pueden sumar sin más los recuentos de distintos procesos y productos y presentarlos como la producción total del grupo. Estas reglas de negocio deben configurarse o implementarse mediante desarrollo en la plataforma correspondiente.

El gateway publica los datos; la plataforma organiza la consulta

Una vez adquiridos los datos en planta, los gateways de cada fábrica pueden publicarlos mediante MQTT o HTTP/HTTPS, entre otras opciones, según los requisitos de la plataforma receptora. El personal técnico debe configurar la dirección de la plataforma, los datos de autenticación, los temas o las rutas de las interfaces y la correspondencia de los campos. El protocolo concreto depende de las interfaces admitidas por ambas partes.

En esta cadena deben distinguirse las responsabilidades:

• Los equipos proporcionan las señales originales: ponen a disposición datos legibles, como estados, contadores y alarmas.
• Los gateways de cada fábrica adquieren y publican los datos: leen los puntos de datos configurados y los transmiten en el formato acordado.
• La plataforma unificada proporciona las páginas de consulta: implementa los filtros por fábrica, las listas de equipos, la consulta del historial y las reglas estadísticas y los permisos necesarios.

La plataforma puede ser un sistema existente o una aplicación creada por separado. Que el gateway admita la publicación de datos no significa que incluya un panel de gestión para varias fábricas. Las interfaces receptoras y las funciones de visualización de la plataforma deben concretarse e implementarse.

Comprobar primero la hora de actualización y después el estado del equipo

Volvamos a la reunión de coordinación de la producción. Una vez completadas la integración y la configuración de las páginas, la persona responsable puede consultar primero las listas de equipos por fábrica, identificar cuáles están funcionando y cuáles presentan alarmas existentes y después confirmar la situación con la planta correspondiente. Ya no hace falta recopilar capturas de cada fábrica para conocer un estado.

Sin embargo, que la página muestre «En funcionamiento» no significa necesariamente que el dato sea actual. La plataforma debe mostrar también la hora de actualización y señalar los datos obsoletos o las incidencias de comunicación según los umbrales acordados, para no confundir el último estado recibido con el estado actual en planta. Estos avisos deben configurarse o implementarse mediante desarrollo en la plataforma.

El gateway admite el almacenamiento temporal sin conexión y la reanudación de transferencias interrumpidas, lo que permite reenviar datos cuando se restablece la red. En el uso real hay que comprobar la configuración, el almacenamiento disponible y el comportamiento de la cadena de publicación; no se garantiza que no se pierdan datos en cualquier tipo de interrupción. Si la solución requiere registros históricos, durante la integración se deben definir las marcas de tiempo de adquisición y su tratamiento en la plataforma para distinguir los registros reenviados de los datos actuales. El reenvío no elimina el periodo sin información consultable durante la caída de la red.

Tampoco se puede concluir que un equipo tiene una avería o le falta material solo porque su estado indique que está detenido. La consulta centralizada aporta indicios para contactar con la planta. La causa de la parada debe confirmarse con las alarmas, la información del personal en planta o un registro de causas configurado por separado.

Qué confirmar antes de la integración

• Comprobar en cada fábrica los modelos de equipos, protocolos, interfaces, permisos de lectura y datos disponibles. La compatibilidad con una marca no implica que se admitan todos sus modelos.
• Unificar los identificadores de fábricas y equipos, las definiciones de los estados, el significado de los contadores, las unidades, las marcas de tiempo y las reglas de agregación; definir el tratamiento de los datos anómalos.
• Confirmar las condiciones de acceso a la red de cada fábrica, las interfaces receptoras de la plataforma y los métodos de autenticación. Utilizar conexiones cifradas compatibles según los requisitos del receptor y configurar las credenciales y los permisos de acceso.
• Acordar con el personal de mantenimiento en planta la frecuencia de adquisición y la carga de comunicación. Implementar las páginas de la plataforma, los permisos, los registros históricos y los avisos de datos obsoletos; planificar el almacenamiento temporal y la conservación del historial según los recursos de almacenamiento reales.

La solución descrita solo lee y publica datos de los equipos. No incluye arranques o paradas remotos, escritura de parámetros ni descarga de programas a los equipos. Tampoco requiere una red Grid de varios gateways como condición para la consulta centralizada entre fábricas.

Empezar por la información que realmente necesita una reunión de coordinación

Conviene comenzar por la información que se pide repetidamente cada día en las fábricas y que realmente puede leerse de los equipos. Seleccione un conjunto de datos clave, unifique su interpretación y los criterios temporales y deje que quienes utilizarán las páginas de la plataforma comprueben su utilidad.

Así, la consulta centralizada no consiste solo en colocar las cifras de varias fábricas en una pantalla. Permite que la persona responsable disponga primero de información trazable cuya vigencia pueda evaluar y que después contacte con la planta con preguntas concretas. La comunicación con el personal en planta sigue siendo importante, pero no tiene que empezar siempre por recopilar capturas de nuevo.