Federated Learning Across Plant Sites Without Sharing Sensitive Data

You can train a fleet-wide predictive maintenance model while keeping raw sensor data at each participating site. That is what federated learning does: each site trains locally on its own historian and sends model updates to an aggregator. NIST describes this approach as collaborative training over distributed data rather than central collection of the underlying training records ^[1]. It is a practical option for multi-site manufacturers, joint ventures, and operators that need a shared model while retaining site-level control of raw data.

Picture a fleet-analytics project with historian exports ready and a data lake provisioned. A joint-venture clause or data-residency requirement can stop the export before training starts. Federated learning gives the team another architecture to evaluate when centralizing raw records is not acceptable.

The catch is that the tidy academic version of federated learning breaks the moment you point it at a real plant floor with mixed equipment, uneven failure histories, and OT networks that drop connections. This article covers what actually works.

The Data You Legally Cannot Move

Consider a planning scenario: three companies operate a shared turbine fleet under a joint-venture agreement, and each partner runs a subset of the machines. If the agreement restricts raw sensor exports, a central training lake is not an available starting point. The architecture has to preserve each partner's control of its operating records while defining exactly which model artifacts can cross the boundary.

Before using SCADA setpoints or recipe parameters in a shared training design, ask the data owner, operations team, and counsel to document their classification and permitted use. Do this even when the analytics team sees the same records as ordinary telemetry.

Data-residency and contract requirements can add another boundary. If you run plants across jurisdictions, document where raw records, model updates, logs, and backups are processed. Federated learning can help reduce raw-data movement ^[1], but you still need to assess model updates, metadata, access controls, and each participant's obligations.

When a central lake cannot clear that review, change the architecture instead of waiting on an export that may never be approved. Start by identifying which records must remain local and which derived artifacts participants may exchange.

How Federated Learning Actually Works in an OT Context

The core inversion is simple. Instead of moving training records to one model, you send a model to each participating site. Each site trains against its local historian and PI System tags, then returns a model update. Raw vibration, temperature, and pressure records can remain in the site's data boundary when the implementation is configured that way ^[1].

An aggregator collects weight updates from participating sites, combines them into an updated global model, and sends the new version back out for the next round. With secure aggregation, sites can contribute to the shared model without receiving another site's underlying records. NIST describes how this approach reveals the aggregate update while protecting each participant's individual update ^[1].

Here is how the three main patterns compare on the dimensions that matter for OT.

At each edge gateway, run the local training job against the site historian and keep raw records within the selected data boundary. Before sharing model updates, test the privacy controls described by NIST ^[1]. In the aggregation layer, combine the protected updates and manage model versions. This follows the same edge-and-cloud split used in many predictive maintenance programs, which gives operations teams a familiar starting point.

Why Standard FL Frameworks Break on the Plant Floor

Federated learning research has had to address both systems heterogeneity and non-identically distributed data ^[3]. A plant fleet makes those issues concrete: equipment, sensors, labels, sampling rates, connectivity, and compute capacity differ by site.

Equipment heterogeneity is the first wall. Two compressor models doing the same job may produce different feature distributions because their sensors, sampling logic, and failure signatures differ. FedProx research documents how statistical heterogeneity can weaken naive federated averaging ^[3]. Benchmark the shared model against each site-local model before deciding which assets belong in one aggregation group.

Non-IID and unbalanced data is the second. One site may log far more failure events than another because it runs older assets or because its technicians tag work orders more diligently. A higher-volume site's updates can dominate naive averaging, leaving lower-volume sites with predictions tuned to conditions they rarely see. Measure that imbalance before choosing an aggregation method.

Connectivity is the third. OT networks are segmented on purpose. A training round that expects all clients to respond within a fixed window will constantly time out when a plant's edge gateway is behind a firewall that only opens for scheduled syncs. Frameworks built for always-on mobile clients treat a missed round as a rare dropout. On the plant floor, missed rounds are routine.

The takeaway: benchmark a shared model against site-local baselines. If naive averaging underperforms at one or more sites, test a heterogeneity-aware approach before expanding the fleet ^[3].

Architectures That Survive Equipment Heterogeneity

The fix is to stop pretending every site is the same. Three architectural patterns handle real fleet heterogeneity, and you often combine them.

Clustered federated learning groups sites by asset class before aggregating. Siemens compressors might train into one cluster model while GE units form another. You aggregate within clusters where feature distributions are comparable, then test whether a common layer across clusters adds value. This avoids treating different equipment as interchangeable.

Personalized federated learning keeps a shared base model but gives each site its own fine-tuned head. The base model learns the general physics of the failure mode. The site-specific head adapts to local operating conditions: ambient temperature, load profile, that one compressor everyone knows runs hot. Each site ends up with a model that benefits from fleet-wide learning while still fitting its own reality.

Swarm learning removes a permanent central coordinator. The published architecture uses peer-to-peer networking and a permissioned blockchain to coordinate membership and parameter merging ^[5]. For a joint venture where no partner will operate the central aggregation service, it is one pattern worth testing against operational and governance requirements.

In practice, a mixed fleet uses clustered aggregation for the equipment heterogeneity and personalized heads for the local-conditions problem, layered together. You cluster by asset class, aggregate within clusters, and let each site fine-tune. Swarm coordination sits underneath if the trust model demands it.

Gradient Leakage, Secure Aggregation, and Privacy Budgets [1][4]

Sending weight updates instead of raw data is not automatically private. Gradient inversion attacks can reconstruct training examples from shared gradients under documented experimental conditions ^[4]. For a plant, that means the threat model must cover model updates as well as historian records.

Two protections address this, and you generally use both.

Secure aggregation using secure multiparty computation (SMPC) is designed so the coordinator receives an aggregate rather than each participant's update. NIST explains a secret-sharing construction and the boundary it provides, while also noting the added communication among participants ^[1]. Google's published protocol provides another implementation and reports its communication overhead for specific test configurations ^[2].

Differential privacy adds calibrated noise to an update before it leaves the site. NIST describes how a privacy budget bounds the influence of individual training records and must be managed across training rounds ^[1]. Test the resulting model quality against the privacy setting your threat model requires.

Use threat-model and dropout testing to decide how secure aggregation should be configured ^[1][2]. Tune differential-privacy settings against representative model-quality tests instead of choosing a default. Sites under one control framework may reach a different setting than a joint venture with separate participants.

A Practical Rollout: From Two-Site Pilot to Fleet

Do not start with the full fleet. Start with two sites running the same asset class, then compare the aggregated model with both site-local baselines. If aggregation does not meet the agreed evaluation thresholds, revisit the data, labels, and training design before introducing equipment heterogeneity.

Define the local training contract before any code runs. Each participating site documents specific things:

• Which historian tags feed the model, mapped to a common schema so a "discharge pressure" tag means the same thing at every site
• Sampling rate and any resampling applied locally, because a 1-second tag and a 10-second tag are not interchangeable
• Label quality, meaning how failure events and work order outcomes are tagged, since the model learns from these labels
• Sync schedule for when the edge gateway participates in training rounds, matching the plant's OT network windows

This contract is the difference between a pilot that produces a usable model and one that produces garbage the team spends months debugging. Poor label quality at one site will drag down the whole cluster, and you want that agreed and monitored up front. Cleaning up work order data quality is often the real prerequisite here; the federated math is fine, but it cannot fix labels that were never trustworthy.

Run the governance checklist in parallel with the technical pilot:

1. Data-flow review documenting which records and model artifacts can cross each border 2. IP review by legal confirming the JV or corporate constraints are satisfied by the FL design 3. Protocol evidence showing what the coordinator can access during normal, dropout, and recovery conditions 4. Model card per site documenting what the local model was trained on, its performance, and its known limits

Monitory can help teams test three parts of this architecture: local training at each plant, protection of updates during aggregation, and per-site model personalization. Evaluate each part against the data-flow boundary ^[1], the selected aggregation protocol ^[2], and site-local performance baselines ^[3].

What to Do in the Next 30 Days

Start with an inventory, not a model. Map which of your sites share asset classes and which contracts or regulations restrict data movement. This single spreadsheet tells you where federated learning is worth the effort and where a simple site-local model is enough. Sites with unique equipment and no data-sharing partners do not need FL at all.

Start by tracking the performance gap between a global model and each site-local model. Train a local model per site as the baseline, then compare the federated result using the same labels and evaluation window. This shows where fleet-wide learning adds value before you invest in an aggregation service.

Run a two-site clustered federated learning proof on one critical asset class where both sites use comparable equipment. Compare the aggregated model with both local baselines. Test secure aggregation with protocol traces and dropout cases ^[1][2], and have data owners review the resulting data flow. Add a third site after the pilot meets its agreed performance and control criteria.

FAQ

How should you compare federated and centralized models? Use the same failure labels and evaluation window for each candidate. Results depend on data distribution, participation, local training, aggregation, and privacy settings. The FedProx study shows that heterogeneity-aware optimization can outperform FedAvg in the study's heterogeneous benchmarks ^[3], but that result is not a plant-specific forecast. Compare each candidate against site-local and permitted centralized baselines using your own failure labels.

What connectivity does each site actually need? Training can happen locally, but the update schedule still has to fit the protocol, model size, available bandwidth, and plant change windows. Measure update payloads and dropout behavior in the pilot, then set a sync schedule your OT team can support. Do not assume a laboratory communication profile will fit the production network.

How do we convince JV partners to trust this? Evaluate swarm learning when the partners do not want a permanent central coordinator ^[5]. Pair the coordination design with secure aggregation when individual model updates need protection ^[1]. Bring security, data owners, and counsel into the pilot design early so they can review actual data flows and records.

Remember the three JV partners with the shared turbine fleet from the opening. The reason their project can move is that the model, not the data, is what travels. Get the inventory done this week, baseline your site-local models, and pick one asset class for a two-site proof. That is the whole path from stalled to shipping.

References

[1] NIST, "Protecting Model Updates in Privacy-Preserving Federated Learning" (March 21, 2024) https://www.nist.gov/blogs/cybersecurity-insights/protecting-model-updates-privacy-preserving-federated-learning

[2] Bonawitz et al., "Practical Secure Aggregation for Privacy-Preserving Machine Learning" (CCS 2017, foundational protocol) https://research.google/pubs/practical-secure-aggregation-for-privacy-preserving-machine-learning/

[3] Li et al., "Federated Optimization in Heterogeneous Networks" (MLSys 2020, foundational heterogeneity study) https://proceedings.mlsys.org/paper/2020/hash/1f5fe83998a09396ebe6477d9475ba0c-Abstract.html

[4] Zhu, Liu, and Han, "Deep Leakage from Gradients" (NeurIPS 2019, foundational attack study) https://proceedings.neurips.cc/paper_files/paper/2019/hash/60a6c4002cc7b29142def8871531281a-Abstract.html

[5] Warnat-Herresthal et al., "Swarm Learning for decentralized and confidential clinical machine learning" (Nature 2021, foundational architecture study) https://www.nature.com/articles/s41586-021-03583-3