PAN Lab example
Predictive maintenance on a high-speed rail fleet
The contract that prices every miss
Siemens analytics read sensor data from Renfe's Velaro E trains to forecast part failures. Renfe promises a full refund for delays over 15 minutes.
See more
Siemens built the Velaro E high-speed trains that the Spanish train operator Renfe uses, and monitors their key components. Siemens analytics read the trains' sensor data in near real time to predict when a component is likely to fail. A train that shows abnormal patterns is sent for inspection.
What the published article reports
A 2016 article in the trade publication RCR Wireless News describes the deployment. It draws on a case study provided by Teradata, the company whose data platform Siemens uses.
The article reports that only one of 2,300 journeys was noticeably delayed, and only by five minutes. Passengers are reimbursed in full if a delay is over 15 minutes.
The main source is a vendor-side trade case study. It documents the fleet's delay figure. It does not publish the analytics' own precision, meaning the share of flagged failures that were real.
The pilot behind the published analysis
The sensor figures and the failure pattern in the article come from a separate pilot. Siemens ran it in the UK with a large European train operator, on one of its regional routes.
The pilot analyzed 1 million sensor-log readings, taken every five minutes over a year. The readings came from 300 different sensors and measured variables such as component temperature and pressure. Analysts overlaid them with many thousands of reports of failures and fixes.
Using Teradata's Aster Discovery platform, Siemens found sensor patterns that came before engine failures. In one, the engine temperature dropped from mid to low, then rose to mid again. An engine failed three days later.
The article gives no sensor counts, reading intervals, or discovered patterns for Renfe's fleet.
Who runs it and who pays
The case file describes Siemens as the service provider that maintains the fleet, and Renfe as the operator whose flagship promise is the full refund.
The case file reads the contract as putting the cost of late trains on Siemens, which runs the analytics and schedules the interventions. In that reading, every missed failure has a price, and the bill goes to the company that holds the analytics.
In most of this domain's cases, the company that tunes the tool and the company that bears its mistakes are different. A vendor sells, and a deployer suffers. The case file's lesson is that the contract, not the analytics, puts the cost of a miss on the company that tunes them. It also reads the response side as well resourced for the same reason. In the case file's reading, the domain's other cases only aspire to that.
The article itself does not state Renfe's contract terms or say who pays the refunds. It quotes Gerhard Kress, director of mobility data services at Siemens. He said Siemens can provide new services with up-time guarantees, risk-sharing models, and performance-based contracts. The case file's reading rests on that general statement.
Two dependencies
The case file names two dependencies that temper the picture.
First, the failure patterns were found by joining sensor data to reports of failures and fixes. The case file says crews write those reports for their own purposes. So what the analytics can learn is bounded by what people keep writing down. Reports that thin out, or drift toward phrasing that avoids blame, would quietly starve that search.
Second, sensor readings are the analytics' only view of the machine. A failing sensor and a failing train look the same in the data, until someone goes to the train and looks.
What this network is drawn from
This network is drawn from the public record, not from Siemens' own system. It shows the maintenance operation: the analytics, the planner and crews, their joined record, and the count of late journeys.
The article does not describe who schedules maintenance for Renfe's fleet or who writes its failure reports. The planner and crews here follow the case file's reading. Passengers are outside the network.
What the available tools can and cannot address
Service means the useful work the analytics do: predictions that get a train repaired before it fails.
A failure pathway is a link between two parts of the network where a mistake made by one part can be passed on to the other. Closing a pathway means mistakes stop passing along it. The work it carries goes on.
Explore (No Targets) sets no targets. Under Service Targets Only, the targets can be met within this case's budget of 10 units. The cheapest way costs 8 units and uses three tools together: Escalate checks, Upgrade model, and Check with a second model. Escalate checks adds checking by the planner and crews when trouble is flagged.
Under Service and Safety Targets and under All Governance Targets, the targets are not fully addressable with the available tools. Those levels require closing every failure pathway. Even with every tool at its strongest setting, eight stay open.
Those eight run among the sensor readings, the analytics, the planner, the crews, the record, and the delay count. No tool offered here acts on them.
More checking is not always better here. Every tool at its strongest setting misses even the Service Targets Only targets. The added checks and waits cut the analytics' service too far.
Open this example in PAN Lab v0.1 to apply pressures and levers and watch what the system does.
What this models
This example runs on the Fleet-maintenance-class whose contract prices the miss network: 6 components and 13 pathways between them. Every context in the Lab is a stylized model, never a reconstruction of any actual deployment, and each assumption behind it carries a provenance label.
Evidence base: 3 assumed · 1 published baseline. In the Lab, the shaded evidence band behind each headline readout draws its width from the least-established class below.
Show all 4 assumptions
- assumed
This example assumes the maintenance contract puts the cost of late trains on Siemens, which also runs and tunes the analytics. That reading comes from the case file. The published article does not state the contract's terms. In the domain's other cases, the company that tunes a tool and the company that bears its mistakes are different. Here the case file reads the contract as joining them. The example assumes the count of late journeys against the refund promise runs as a check. The article reports the fleet's delay record: one noticeably delayed journey in 2,300. The example assumes a modest workload and ample staff to respond, because in the case file's reading the contract pays for the response.
- assumed
This example draws two dependencies the case file names. First, it includes a check that tells a failing sensor from a failing train. Sensor readings are the analytics' only view of the machine, so the two look the same until a person goes and looks. Second, the crews' failure reports are drawn as a pathway into the record the analytics search. The failure patterns were found by joining sensor data to reports people wrote for their own purposes. So what the analytics can learn is bounded by what people keep writing down, an input nobody puts a price on.
- baseline
The main source is a vendor-side trade case study. It documents the fleet's result: one journey in 2,300 noticeably delayed, by five minutes. The sensor figures and the engine-temperature pattern come from a separate Siemens pilot in the UK. The analytics' own precision is not published. So this example gives no figure for it, and none may be invented.
- assumed
This example does not model any passenger outcome. It shows how errors move among the analytics, the maintenance staff, and their records. Passengers are outside the network. The delay figures, the refund promise, and the discovered failure patterns come from the case file. Nothing in this example computes them.
What this example does not show
Show all 2 limitations
- This example does not show any passenger outcome. It shows how errors move among the analytics, the maintenance staff, and their records. Passengers are outside the network. The delay figures, the refund promise, and the discovered failure patterns come from the case file. Nothing in the network computes them.
- The main source is a vendor-side trade article. It reports the fleet's delay figure but not the analytics' own precision, so this example gives no figure for it. Its sensor figures and engine-temperature pattern come from a separate Siemens pilot in the UK, not from Renfe's fleet.
Sources and evidence
What this example rests on, claim by claim. Every entry resolves to the same ledger the Evidence Registry publishes.
A rail service provider operates sensor-based predictive maintenance on a high-speed fleet under what the case reads as a priced availability contract: continuous monitoring of the trains' key components (the published method figures, 300 sensors read at five-minute intervals for a million readings over a year, overlaid with human-written failure reports, come from a separate pilot on a UK regional route), maintained against a promise that refunds the full fare if a journey is delayed more than fifteen minutes. The documented fleet result is only one noticeably delayed journey in 2,300 (by five minutes). The pilot discovered failure signatures such as an engine-temperature pattern preceding failure by three days. The fleet outcome is documented in a vendor-side trade case study; the analytics' own precision is not published, so the model-level figures remain unstated while the operational outcome is on the record.
empirical- Trade press RCR Wireless News (2016, September 12). Case study: Siemens reduces train failures with Teradata Aster (Renfe Velaro E predictive maintenance). https://www.rcrwireless.com/20160912/big-data-analytics/siemens-train-teradata-tag31-tag99
The case reads this deployment's governance shape as uptime-as-contract: the party that operates and tunes the analytics is the service provider, which would bear the cost of misses under the refund promise, so the incentive to prevent a delay would be priced into the same organization that holds the model levers - an alignment the domain's other deployments lack. The reading rests on the provider's general statement that it can offer "up-time guarantees, risk-sharing models and performance-based contracts". The cited article does not state the operator's contract terms or who pays the refunds. Two documented dependencies temper it: the failure signatures were discovered by joining sensor streams to human-written failure reports, so the discovery loop runs on documentation crews write for their own purposes; and a continuous sensor stream is the analytics' only view of the machine, so a failing sensor and a failing train arrive looking the same until someone goes and looks.
empirical- Trade press RCR Wireless News (2016, September 12). Case study: Siemens reduces train failures with Teradata Aster (Renfe Velaro E predictive maintenance). https://www.rcrwireless.com/20160912/big-data-analytics/siemens-train-teradata-tag31-tag99
Where this connects
Institutional pressures in this domain
- Reviewer bottleneck — One fixed-capacity checking stage sits between AI output and consequence; everything queues behind it.
- Austerity & recovery incentives — Cost-cutting and overpayment-recovery targets tilt the system toward denial and enforcement errors.
- Data & policy drift — The world, the intake process, and the rules change under a system trained on how things used to be — two mechanisms with different remedies: the statistical properties of what the system processes move (concept drift), or the mixture of inputs arriving in deployment differs from the mixture it was trained on (covariate shift).
- Vendor opacity — The deploying institution cannot inspect the model, data, or update pipeline it is accountable for.
- Compliance over substance — Paper controls (sign-offs, checklists) satisfy audits while the behavior they describe erodes.
All of them in context on the Industrial QA & operations AI domain page.
Levers available here and the patterns behind them
- Upgrade model — Improve the model
- Check with a second model — Cross-model verification
- Check copied records — Reconcile copied records
- Review on schedule — Oversight cadence & retrospectives
- Review the riskiest first — Risk-tiered oversight
- Train the staff — AI literacy & boundary rules
- Escalate checks — State-feedback vigilance