Photo: Andrew Van Hofwegen / UnsplashMulti-plant manufacturers face a paradox. The plant with the rarest defect has the least data to learn from, while the sister plant 800 km away has seen the same defect a hundred times. Pooling data in a central lake would solve the learning problem and create a governance problem. Federated learning resolves the paradox: the model travels, the data stays. This is how it works and what we have learned setting it up for industrial sensing.
The basic idea in one paragraph
Each plant trains the shared model on its own data, locally, on its own hardware. Only the model updates (weights or gradients) are sent to an aggregator, which combines them into a new global model and sends it back. No raw recordings, images or process logs ever leave a site. With secure aggregation, even the individual updates are not readable by the aggregator, only their combination.
Where it fits in manufacturing
- Multi-plant condition monitoring. The same machine type at five sites, each with different noise and load profiles. The federated model is more robust than any single-site model.
- Rare-defect detection. Quality events too infrequent at one plant to train on become learnable across the group.
- Supplier and OEM collaboration. Two companies improve a shared model without either revealing its process data. This is now a realistic option for automotive supply chains.
- Regulated and defence-adjacent industry. Where data residency is non-negotiable, federated learning is often the only way to benefit from group-wide learning at all.
What it takes to run it for real
Heterogeneous data
Plants differ. Sensor placement, machine age, product mix and labelling habits all vary. Federated algorithms that assume identical data distributions underperform. We use methods designed for non-identical sites and validate per site, not only on the global average.
Infrastructure at each site
Local training needs a modest on-premise machine and a reliable, approved channel for exchanging updates. This is usually simpler than sites expect, and far simpler than getting approval to export raw data.
Versioning and monitoring
Every global model version is tracked, every site's contribution and validation score is logged, and drift is monitored per site. When a plant's data changes (new product, new sensor), the system notices before the model quietly degrades.
Governance
Who can trigger a training round, who approves a new global model, what happens when a site leaves the federation. These are organisational questions, and we help write the answers down before the first round runs.
Federated is not the same as private by default
Model updates can, in theory, leak information about training data. For industrial sensing this risk is small and manageable, but it is not zero. Secure aggregation, update clipping and, where required, differential privacy close the gap. We document which measures are in place so the security review can assess them rather than guess.
The plant keeps its data, the group gets the model. That is the deal, and with the right engineering it holds.
Key takeaways
- Federated learning lets plants train a shared model while raw data stays on site.
- It shines for multi-plant monitoring, rare defects and supplier collaboration.
- Non-identical site data needs algorithms and validation designed for it.
- Versioning, per-site drift monitoring and governance make it operable.
- Secure aggregation and clipping address the residual privacy risk; document them.
If any of this matches a problem on your line, the fastest way to find out what is possible is a free discovery call followed, where it makes sense, by a feasibility study of two to ten days.