Use case · Industry
Failures anticipated, and an alert before downtime
Your sensor readings and maintenance history feed a model that estimates the failure risk of each piece of equipment. The score is recomputed with every new batch of readings, served to your applications, and the list of equipment to watch is ready before anything stops.
The challenge
Plenty of readings, few failures
- Large sensor series, at different frequencies from one machine to the next.
- Rare failures, described in a maintenance history typed in by hand.
- Production sites that are sometimes isolated from the company network.
- Production data that does not leave the plant.
How graal handles it
From sensor to served score
Step 01
Collect
Readings exported by your PLCs or your historian land on S3, and work orders are read from your database. Every new drop triggers what follows.
Step 02
Prepare the signals
A pipeline computes rolling windows, averages and deviations per machine. Quality checks set aside silent or aberrant sensors.
Step 03
Train
Your data scientists train the risk model on distributed Spark or on GPUs. Every attempt is tracked as an experiment.
Step 04
Serve
The chosen model enters the registry, then it is served over REST behind your SSO: your maintenance tools query it directly.
Step 05
Monitor
A scheduled job publishes the equipment to watch every day. Data drift is tracked, and an alert warns the team when the model degrades.
The typical scenario brings together three sources most sites already have: sensor readings, the intervention history and the equipment list. The pilot starts with one equipment family — the one whose downtime costs the most — and the model then extends to the rest of the fleet.
The Data Act, applicable since 12/09/2025, gives businesses the right to access the data produced by their use of connected machines and devices, and to share it, for instance for repair and maintenance.
What you get
- A risk score per machine, recomputed with every new batch of readings
- A REST endpoint your maintenance tools query
- Monitored drift, so you know when to retrain
- Planned interventions rather than unplanned ones
What stays with you
- Your sensor readings and maintenance history
- The model, its versions and its training data
- The endpoint, served within your infrastructure
Capabilities involved
- Connectors
S3, databases and your historian's REST API.
- Low-code pipelines
Rolling windows, aggregates and quality checks.
- Orchestration and compute
Event triggers, distributed Spark and GPUs.
- Machine learning
Experiments, registry, REST serving and drift monitoring.
- Governance
One project per site, with per-project permissions and audit.
Frequently asked questions
Do we need a real-time data stream?
No. Regular batches of readings, dropped on S3 or read from a database, are enough: every drop triggers the computation.
What if the site has no Internet access?
graal installs offline, from your own image registry, on the site's Kubernetes.
Can we bring our existing models?
Yes. A model logged with the MLflow client is registered and served like any other.
Start with one equipment family
In 8 weeks, a first risk model on your readings, served within your infrastructure.