Federated learning for tool condition monitoring in machining
Models that learn across machines and sites while raw process data stays on the shop floor.
Status quo: tool-wear models in machining
Single-site models reach good lab accuracy but rarely transfer to new machines and jobs.
Single-site models
One machine, one model- Trained on one machine and one setup, they reach good accuracy in the lab.
- Their accuracy drops on machines, tools and jobs they have not seen.
- Every new setup needs its own labeled data and retraining.
Why "one model per use case" rarely scales
Obstacles- Domain shift: a different machine, tool, material, coolant or parameter set changes the signal statistics.
- Label scarcity: wear labels require measurement and machine downtime, so ground truth is expensive.
- Rare failure cases: chatter and breakage are rare, so the data is heavily imbalanced.
- Data silos and governance: production data often cannot be merged into one central store.
- Drift: bearings, spindle and sensors change over time, so models age in operation.
A locally perfect model generalizes poorly, and maintenance and retraining effort increases sharply.
The federated learning process
Local training at the source machines, aggregation in the cloud, and a distributed, improved global model.
The diagram shows the general federated loop: each site trains locally and shares only its model, never the raw data, and a coordinating server combines these into a global model. This demonstrator runs the loop once rather than over many rounds; versioning, drift monitoring and secure aggregation are covered on the Model Aggregation and Data Ecosystems pages.
What is federated learning?
Federated learning trains a shared model across many data sources without moving the raw data.
Federated Learning (FL)
What it is- Each machine or site trains a model on its own data.
- Only the model updates leave a site, never the raw data.
- A server combines those updates into a model the whole fleet uses.
- Goal: better generalization across machines without pooling data.
Transfer Learning (TL)
How it differs- A model is pre-trained on a source task and fine-tuned on the target.
- Typically the data (or features) must be available at the target.
- It does not protect data sovereignty on its own.
Transfer learning means "transfer knowledge and adapt locally"; federated learning means "learn together without sharing raw data".
Data generation at a single machine
Each machine is instrumented to turn raw process signals into feature streams that can be labeled and learned from.
Milling process
From cutting process to feature streams
The kind of cutting process the sensor signals originate from. The machine shown is at the PTW and is not one of those used for the Stiehl et al. dataset.
Process signals
One real milling cycle, captured at the machine
Cutting force, spindle and feed-drive torque from a single milling cycle in the Stiehl dataset. Signals like these are windowed into features, and the tool's measured flank wear is the ground-truth label the model learns to predict.
Scaling across the fleet
In this demonstrator, three comparable milling machines each become a federated site that runs the same pipeline on its own local data.
Machine 1
Five-axis milling center. Signals: cutting force plus spindle and feed-drive control data. Features: windowing, RMS and FFT bands; labels from measured flank wear.
Local siteMachine 2
The same machine class, with its own tools and jobs. Identical feature pipeline, its own local configuration. Data stays on site; only the model is shared.
Local siteMachine 3
Its own wear history, so the data distribution differs (non-IID). No single site's model fits all three machines. This is why the sites train together.
Local siteWhat matters for scaling
- A unified time base (clock sync), the same window definition and the same units.
- Schema and metadata per job: tool ID, material, cutting parameters, sensor position.
- "Same code, different config": the pipeline as a template per machine type.
Application: condition monitoring on the shop floor
A single-site model overfits one setup; a federated model trades some peak accuracy for more consistent results across machines and jobs.
Single-site baseline
One machineStrong on the machine it was trained on, but its accuracy slips on machines and jobs it has never seen.
Federated global model
Whole fleetMore consistent across the fleet, with less local retraining and faster commissioning of a new machine.
The Model Aggregation page shows the measured comparison: each site's own model against the aggregated models and the centralized reference (which pools all raw data), computed live in your browser.
Open the aggregation labOperating mode in production
- Inference at the edge: condition indicator, remaining tool life or anomaly score in real time.
- Round-based training: locally during idle times or adaptively on drift and job changes.
- Rollout: the global model is signed, versioned and deployed to the fleet.
Outlook: challenges and pitfalls
Federated learning avoids raw-data centralization, but its success depends on standardized data, reliable orchestration and secure aggregation.
Data and semantics
Standardization- A unified data description: units, sensor position, sampling, job and tool metadata.
- Label definitions: what counts as a "wear state" or an "anomaly"?
- Quality: missing data, synchronization, drift, sensor changes.
MLOps and operations
Orchestration- Orchestration of model deployment (versioning, rollback, canary).
- Round control: when to train, who participates, how to handle outages?
- Monitoring: model drift, data drift, performance per machine and job.
Transferability of the knowledge
- How well does global knowledge fit new tools and materials (out-of-distribution)?
- Strategies: personalized FL, per-client bias correction, cluster-FL by machine type.
- Security and privacy: secure aggregation must be added on top of data locality; the Data Ecosystems page explains where it fits.
Key takeaways
- Federated learning fits deployments where raw data must not be centralized.
- The choice of aggregation method is decisive: a model can have a low average error and still miss almost every worn tool. The Model Aggregation page shows the live comparison.
- Standardized data, reliable orchestration and secure aggregation remain prerequisites in production.
Explore further
Model Aggregation
Try model aggregation
Combine the per-machine XGBoost models with different aggregation strategies and benchmark each one live against the local and centralized baselines.
Go to model aggregationData Ecosystems
Sovereign data ecosystems
See how Gaia-X, Ocean Protocol and Pontus-X keep raw data on the shop floor while models are shared.
Learn about data ecosystems