Extracción de Datos de Fábrica
Una planta de producción real es un mosaico. Controladores de distintos fabricantes, distintas generaciones y distintos protocolos conviven uno junto a otro: un Siemens S7 en una bancada, un PLC de Allen-Bradley en la siguiente, medidores de energía Modbus y variadores de frecuencia en la subestación, sensores IO-Link en la línea de empaquetado, máquinas herramienta CNC en el taller y controladores BACnet que gestionan la climatización del edificio. Casi nada de esto fue diseñado para compartir datos con otra cosa.
La tarea de la extracción de datos de fábrica consiste en obtener mediciones fiables, nombradas y con marca de tiempo de todo este equipamiento y reunirlas en un solo lugar — sin recablear la planta, sustituir controladores ni reescribir programas de PLC. En la práctica eso significa hablar el protocolo nativo de cada dispositivo, convertir registros y tags en bruto en valores de ingeniería nombrados con sus unidades, adjuntar una señal de calidad para que sepa si una lectura es fiable, y hacerlo de forma confiable en el edge incluso cuando la red se cae.
IronFlock resuelve esto con una familia de apps recopiladoras ligeras desplegadas en el edge, una por familia de protocolo. Cada una se ejecuta como un contenedor Docker normal en cualquier gateway Linux, descubre lo que puede de forma automática, normaliza las direcciones en bruto en valores nombrados, almacena en búfer durante las interrupciones y transmite todo a la base de datos de series temporales de su proyecto. Cada recopilador se configura íntegramente en el navegador y viene con un modo de demostración, de modo que puede evaluar la experiencia completa antes de conectar cualquier hardware.
La realidad brownfield
No existe un único protocolo que cubra una fábrica. La pregunta práctica es siempre “¿qué recopilador lee mi equipo?” La siguiente tabla relaciona el equipamiento que es probable que encuentre con el recopilador que lo gestiona.
| Equipo que encontrará | Protocolo típico | Recopilador a usar |
|---|---|---|
| Siemens S7-1200/1500/300/400, Allen-Bradley Logix, cualquier servidor OPC UA, además de dispositivos Modbus | S7comm, EtherNet/IP, OPC UA, Modbus | Industrial Collector |
| Maestros IO-Link y los sensores inteligentes que hay detrás (ifm, Balluff, Pepperl+Fuchs) | IO-Link sobre HTTP / OPC UA / MQTT | IO-Link Collector |
| Medidores de energía, VFD, compresores de aire, inversores, cualquier controlador basado en registros | Modbus TCP / RTU | Modbus Collector |
| Máquinas herramienta CNC y equipos de taller (HAAS, Mazak, DMG Mori, Fanuc, Okuma) | MTConnect | MTConnect Collector |
| Climatización, enfriadoras, iluminación, medidores de energía, sistemas de gestión de edificios | BACnet/IP | BACnet Collector |
Modbus y OPC UA funcionan hoy, al igual que IO-Link, MTConnect y BACnet. Los drivers de Siemens S7 (S7comm) y Allen-Bradley (EtherNet/IP) del Industrial Collector se basan en el motor Apache PLC4X y se están validando en distintos dispositivos — los controladores S7-1200/1500 ya pueden leerse hoy a través de su servidor OPC UA integrado.
Dónde los recopiladores de IronFlock comparten enfoque
Cualquiera que sea el protocolo que recopile, las cinco apps funcionan igual por dentro. Escriben en las mismas tablas de base de datos por proyecto (gateways, assets, datapoints, measurements, assetstatus), almacenan las lecturas localmente y las reenvían en orden cuando vuelve el enlace ascendente con la plataforma, aíslan cada dispositivo de modo que una máquina inalcanzable nunca bloquee a las demás, y se configuran en vivo en el navegador sin archivos de configuración ni reinicios. Esto se cumple independientemente de cómo se despliegue IronFlock — nube gestionada, nube privada o un appliance on-premises totalmente sin conexión. Cada página a continuación repite estos rasgos compartidos para que se sostenga por sí misma.
Límites conocidos
Algunos equipos heredados aún no tienen una ruta directa. Los Allen-Bradley MicroLogix / SLC heredados (PCCC sobre DF1), las celdas solo Profibus sin un puerto Ethernet libre, los conjuntos operados únicamente desde un DCS de planta, y los equipos sin ningún controlador digital (solo cableado físico) necesitan un gateway, un puente de protocolo o una adaptación de sensores. Si no está seguro de si su equipo está cubierto, póngase en contacto — si un dispositivo habla Modbus o OPC UA casi con seguridad funciona hoy, y se añaden nuevos drivers y packs de perfiles bajo petición.
Los recopiladores
- Industrial Collector — una app para toda la planta: Siemens S7, Allen-Bradley, Modbus y OPC UA uno junto a otro, con un catálogo de perfiles de equipos pre-mapeados.
- IO-Link Collector — maestros IO-Link y sensores inteligentes con descubrimiento automático y decodificación IODD automática sobre HTTP, OPC UA o MQTT.
- Modbus Collector — la forma más ligera de leer la enorme base instalada de medidores, variadores y controladores Modbus.
- MTConnect Collector — máquinas herramienta CNC y equipos de taller a través del estándar abierto MTConnect, con descubrimiento sin configuración.
- BACnet Collector — automatización de edificios, climatización y sistemas de energía a través de BACnet/IP, con descubrimiento automático de red y de puntos.
Adónde van los datos
Cada recopilador almacena sus lecturas en la base de datos de series temporales privada de su proyecto, donde quedan inmediatamente disponibles para el resto de la plataforma: consúltelas y modélelas mediante el Data Backend, visualícelas en vivo en Paneles IoT y tableros SCADA, y vigílelas con la app de Alarmas para recibir notificaciones por SMS/correo electrónico. Para poner los dispositivos en línea e instalar estas apps, consulte Gestión de dispositivos y Gestión de aplicaciones.
De la recopilación al insight: un patrón de implementación típico
La extracción es la base, no el objetivo. Nadie quiere registros y tags — las plantas quieren cifras de OEE, avisos tempranos antes de que falle un husillo, energía por pieza, un informe de turno que se escribe solo. Por eso, el despliegue típico de IronFlock se organiza en dos capas que se mantienen claramente separadas:
Capa 1 — recopilar. Instale las apps recopiladoras que correspondan a su equipamiento en los gateways contiguos a él, y mapee sus máquinas en el navegador. A partir de ese momento, mediciones nombradas, con marca de tiempo y con indicador de calidad se acumulan de forma continua en la base de datos estandarizada de su proyecto — cada proyecto obtiene la misma, de modo que un recopilador se comporta de forma idéntica dondequiera que se instale, y el propietario del proyecto dispone de un punto central para inspeccionar todo lo que se está recopilando. Dentro de ella, los datos de cada app viven en su propio esquema aislado: un activo único y creciente que le pertenece, privado por app de forma predeterminada.
Capa 2 — consumir. Instale (o desarrolle) las apps que convierten esas mediciones en decisiones, y deje que lean los datos de los recopiladores mediante el acceso a datos entre apps:
- Una app de panel OEE lista para usar consume estados de máquina y contadores de producción y ofrece disponibilidad, rendimiento y calidad por línea — en vivo en la pared, sin una sola reunión de integración.
- Una app de mantenimiento predictivo se entrena con meses de historial de vibración, corriente y temperatura que los recopiladores ya han reunido, y luego puntúa el flujo en vivo para señalar el rodamiento que ha empezado a desviarse.
- La analítica energética cruza el consumo de los medidores Modbus con los contadores de producción de las máquinas para informar de la energía por pieza, el desperdicio por carga en vacío y el riesgo de picos de carga.
- Las apps de informes y calidad leen las mismas tablas para rellenar automáticamente libros de turno, registros de lote y pistas de auditoría.
- Un runtime de Node-RED (o cualquier banco de trabajo general) declara que consume todos los datos del proyecto con un único comodín, y luego descubre las tablas disponibles en tiempo de ejecución — de modo que un ingeniero puede cablear flujos a través de cada recopilador y app de analítica de la planta sin escribir una integración para cada uno.
Cada app consumidora declara qué datos de los recopiladores necesita — una lista específica, o - app: "*" para todo — y usted aprueba o revoca ese acceso por proyecto con un interruptor — siempre de solo lectura. Como todos los recopiladores de IronFlock escriben el mismo esquema de tablas (gateways, assets, datapoints, measurements, assetstatus), una app consumidora escrita para un recopilador funciona con todos ellos: al panel OEE no le importa si los estados de máquina llegaron por S7, Modbus, MTConnect o IO-Link.
El resultado es una arquitectura que crece con usted en lugar de atarlo: empiece con un recopilador en una línea, añada apps de analítica cuando esté listo, sustituya o amplíe cualquier capa de forma independiente — y si las apps listas para usar no encajan, desarrolle su propio consumidor sobre los datos que ya recopila.