Factory Data Extraction

A real factory floor is a patchwork. Controllers from different vendors, different generations, and different protocols sit side by side — a Siemens S7 on one skid, an Allen-Bradley PLC on the next, Modbus energy meters and variable-frequency drives in the substation, IO-Link sensors on the packaging line, CNC machine tools in the workshop, and BACnet controllers running the building’s HVAC. Almost none of it was designed to share data with anything else.

The task of factory data extraction is to get trustworthy, named, time-stamped measurements off all of this equipment and into one place — without rewiring the plant, replacing controllers, or rewriting PLC programs. In practice that means speaking each device’s native protocol, turning raw registers and tags into named engineering values with units, attaching a quality signal so you know whether a reading can be trusted, and doing it reliably at the edge even when the network drops.

IronFlock solves this with a family of lightweight, edge-deployed collector apps — one per protocol family. Each runs as a normal Docker container on any Linux gateway, discovers what it can automatically, normalizes raw addresses into named values, buffers through outages, and streams everything into your project’s time-series database. Every collector is configured entirely in the browser and ships with a demo mode, so you can evaluate the full experience before any hardware is connected.

The brownfield reality

There is no single protocol that covers a factory. The practical question is always “which collector reads my equipment?” The table below maps the equipment you are likely to find to the collector that handles it.

Modbus and OPC UA work today, as do IO-Link, MTConnect and BACnet. The Industrial Collector’s Siemens S7 (S7comm) and Allen-Bradley (EtherNet/IP) drivers are powered by the Apache PLC4X engine and are being validated across devices — S7-1200/1500 controllers can already be read today through their built-in OPC UA server.

Where IronFlock collectors share an approach

Whichever protocol you collect, all five apps work the same way under the hood. They write into the same per-project database tables (gateways, assets, datapoints, measurements, assetstatus), buffer readings locally and forward them in order when the upstream link to the platform returns, isolate each device so one unreachable machine never stalls the others, and are configured live in the browser with no config files or restarts. This holds whichever way IronFlock is deployed — managed cloud, private cloud, or a fully offline on-premises appliance. Each page below repeats these shared traits so it stands on its own.

Known limits

Some legacy gear has no direct path yet. Legacy Allen-Bradley MicroLogix / SLC (PCCC over DF1), Profibus-only cells without a spare Ethernet port, packages operated only from a plant DCS, and equipment with no digital controller at all (hardwired-only) need a gateway, a protocol bridge, or a sensor retrofit. If you’re unsure whether your equipment is covered, get in touch — if a device speaks Modbus or OPC UA it almost certainly works today, and new drivers and profile packs are added on request.

The collectors

• Industrial Collector — one app for the whole floor: Siemens S7, Allen-Bradley, Modbus and OPC UA side by side, with a catalog of pre-mapped equipment profiles.
• IO-Link Collector — IO-Link masters and smart sensors with automatic discovery and automatic IODD decoding over HTTP, OPC UA or MQTT.
• Modbus Collector — the lightest way to read the huge installed base of Modbus meters, drives and controllers.
• MTConnect Collector — CNC machine tools and shop-floor equipment over the open MTConnect standard, with zero-configuration discovery.
• BACnet Collector — building automation, HVAC and energy systems over BACnet/IP, with automatic network and point discovery.

Where the data goes

Every collector stores its readings in your project’s private time-series database, where they are immediately available to the rest of the platform: query and model them via the Data Backend, visualize them live in IoT Dashboards and SCADA boards, and watch them with the Alarms app for SMS/email notifications. To bring devices online and install these apps, see Device Management and App Management.

From collection to insight: a typical implementation pattern

Extraction is the foundation, not the goal. Nobody wants registers and tags — plants want OEE numbers, early warnings before a spindle fails, energy per part, a shift report that writes itself. The typical IronFlock deployment therefore comes in two layers that stay cleanly separated:

Layer 1 — collect. Install the collector apps that match your equipment on the gateways next to it, and map your machines in the browser. From this point on, named, time-stamped, quality-flagged measurements accumulate continuously in your project’s standardized database — every project gets the same one, so a collector behaves identically wherever it is installed, and the project owner gets one central point to inspect everything that is being collected. Inside it, each app’s data lives in its own isolated schema: a single, growing asset that belongs to you, private per app by default.

Layer 2 — consume. Install (or build) the apps that turn those measurements into decisions, and let them read the collectors’ data through cross-app data access:

• A ready-made OEE dashboard app consumes machine states and production counters and delivers availability, performance, and quality per line — live on the wall, without a single integration meeting.
• A predictive-maintenance app trains on months of vibration, current, and temperature history the collectors have already gathered, then scores the live stream to flag the bearing that has started to drift.
• Energy analytics joins the Modbus meters’ consumption with the machines’ production counters to report energy per part, idle-load waste, and peak-load risk.
• Reporting and quality apps read the same tables to fill shift books, batch records, and audit trails automatically.
• A Node-RED runtime (or any general workbench) declares it consumes all project data with a single wildcard, then discovers the available tables at runtime — so an engineer can wire flows across every collector and analytics app on the floor without writing an integration for each one.

Each consuming app declares which collector data it needs — a specific list, or - app: "*" for everything — and you approve or revoke that access per project with a switch — read-only, always. Because every IronFlock collector writes the same table schema (gateways, assets, datapoints, measurements, assetstatus), a consuming app written against one collector works with all of them: the OEE dashboard doesn’t care whether the machine states arrived via S7, Modbus, MTConnect, or IO-Link.

The result is an architecture that grows with you instead of locking you in: start with one collector on one line, add analytics apps when you’re ready, swap or extend any layer independently — and if off-the-shelf apps don’t fit, build your own consumer on the data you already collect.