Tram 629 was already about 14 minutes behind schedule. Instead of turning round quickly at the end of the line, it stood still for 18 minutes and its schedule offset fell to −1,380 s (23 minutes behind). Is something wrong with the vehicle, or is this an operational decision? What should the operator check?
The answerNo sign of a vehicle fault. The data fits an operational recovery at the terminus: the tram was first attached to its next scheduled trip, which was already overdue, held with its doors shut, and then moved onto a later departure. It left about 5 minutes behind that later trip and was back on time by the following terminus.
The data said “23 minutes late”. InduQT said “no vehicle fault: check the dispatch log, not the tram”. A number is not a diagnosis.
Replay the data
Every reading below came in live through InduQT’s MQTT connector from Helsinki Region Transport high-frequency positioning (mqtt.hsl.fi), and this is InduQT’s own replay of it: press Play, or click a numbered marker to jump to that moment. A red strip means more than 5 minutes behind schedule, the point where InduQT raises an alert.
Replay of the real readings. Press Play, drag the slider, or click a numbered marker to jump to that moment. Times are UTC (Helsinki is UTC+2).
Each strip is one signal (click its name to show its trend):stronger = more (further behind, doors more open, harder braking)more than 5 minutes behind: InduQT raises an alertthe 18-minute stop
Speed drops to zero and the doors open. The offset jumps from −820 s to −430 s: it is now measured against the next trip, which was due to leave about 7 minutes earlier.
Static charts of the same readings
What happened, minute by minute
- 16:30–17:55 In service, steadily 13–14 minutes behind schedule (offset −780 to −860 s). Speeds up to about 65 km/h, doors cycling at stops, nothing unusual.
- 17:56 Stops at the terminus. The offset jumps from −820 s to −430 s: the tram is now reported against its next trip, whose departure time was already about 7 minutes in the past.
- 17:56–18:00 Doors open for 4½ minutes: passengers get off and on.
- 18:01–18:12 Doors closed, tram stationary. The offset falls by exactly 60 s every minute, to −1,380 s: the clock is running on a departure the tram is not making.
- 18:13 The offset jumps to −270 s: the tram is now reported against a later trip. Doors open again for about a minute.
- 18:14 Departs, about 5 minutes behind the later trip, and reaches 60 km/h within a minute.
- 18:14–19:12 Runs 5–7 minutes behind the later trip.
- 19:14 At the next terminus it is back on schedule (offset near zero).
What the data shows
The 23 minutes is not real lateness
While a vehicle waits at a terminus, the feed reports its offset against the trip it is attached to. A stationary tram attached to a departure that has already passed loses exactly 60 seconds of offset per minute, which is what the chart shows from 18:01 to 18:12. The tram never ran that trip 23 minutes late; it ran a later trip about 5 minutes late.
Two jumps in the offset mark two trip assignments
An offset cannot jump by hundreds of seconds while a vehicle is standing still unless the timetable it is measured against changes. The jump at 17:56 (−820 → −430 s) and the one at 18:13 (−1,380 → −270 s) are both trip changes, not anything the tram did.
Doors closed for 11 minutes rules out a long boarding stop
A long dwell for boarding or a wheelchair ramp would keep the doors open. Here the doors were shut from 18:01 to 18:12 apart from two brief openings, so the tram was being held, not loading.
Speed, acceleration and doors look healthy
Before and after the stop the tram accelerates normally (up to about 1 m/s²), reaches 60–70 km/h between stops and opens and closes its doors at every stop. Nothing in these signals suggests a traction, brake or door fault.
Likely causes and the check for each
Planned recovery at the terminus (re-slotted to a later departure)
Arrived 14 minutes late, attached to an already overdue trip, held with doors shut, then moved to a later trip and left close to its time. Typical of a controller restoring the timetable rather than running every following trip late.
Check: Ask the operator (or check the control log) whether tram 629 was re-slotted or swapped at the terminus at about 17:56–18:13 UTC.
Driver change or break at the terminus
A long stop with doors closed after the passenger exchange is also what a crew change or a mandatory break looks like, and a late arrival can push it onto the next trip.
Check: Check the crew roster for a relief at that terminus around 18:00 UTC.
A short vehicle check
A stop like this could also be a quick inspection, but the tram left at full speed with normal acceleration and stayed in service, and nothing in speed, acceleration or doors looked abnormal before or after.
Check: Look for a fault or defect report for vehicle 629 that evening; if there is none, close this hypothesis.
Data, decision, judgement
Three different jobs, and InduQT does each one deliberately.
Connected in minutes, kept, replayable
Four trams stream into InduQT through the same MQTT connector a plant uses for its own equipment. Every reading was captured and saved with this case, so the whole episode can be replayed second by second. On its own, though, the data only said one thing loudly: tram 629 was 23 minutes behind. True as a number, wrong as a conclusion.
Rules first, AI second, never a fault without a cause
InduQT’s diagnosis read speed, acceleration and door behaviour, found nothing wrong with the vehicle, and named the real event: an operational hold at the end of the line. Its next step pointed to the dispatch log, not the workshop. And InduQT’s decision engine will not label anything a fault unless it can show the cause behind it; without one it says “insufficient data” and asks for the check that would settle it.
The person who knows the operation, with the evidence in front of them
The final call stays with people. In InduQT’s replay the two jumps in the schedule offset, both while the tram was standing still, are visible in seconds. That turned “held at the terminus” into the full story: moved to a later departure, left about 5 minutes behind, back on time an hour later. The replay also put one figure in the AI’s write-up right: the 23 minutes belonged to a trip the tram never ran, not to its departure.
InduQT’s answer, in its own words: “Operational hold at the terminus, high likelihood; no evidence of a vehicle fault in speed, acceleration or doors. Next check: the operator’s log or dispatch records for 17:56–18:12 UTC.”
What this case made better
- Tram alerts now fire only on real lateness (more than 5 minutes behind schedule), so the people watching see the events that matter.
- The decision engine never reports a fault without a cause it can show; it says “insufficient data” and names the check instead.
- The case is saved with its data, so it can be replayed long after the live readings are gone.
The moral of the story
- A number is not a diagnosis. The feed said 23 minutes late; what really happened was a tram moved to a later departure that ran 5 minutes behind.
- The right decision sends people to the right place: the dispatch log, not the workshop. No technician sent looking for a fault the tram never had.
- Data, decision and judgement are different jobs. InduQT keeps the data, makes a decision it can explain, and gives the person who knows the operation the replay to check it in seconds.
- Plants fall into the same trap: a batch timer, a cycle-time KPI or an OEE loss that keeps counting against an order that is not running. The answer is the same: look at the data in context before acting on the number, which is what InduQT’s replay and decision engine are built for.
Watch the trams liveTroubleshoot your own feeds with Claude
Data: Helsinki Region Transport high-frequency positioning (mqtt.hsl.fi), CC BY 4.0, Helsinki Region Transport. The readings shown are a saved copy taken when this case was written, so the page stays complete after live data is purged. InduQT has no connection with HSL; the causes above are read from public data and have not been confirmed by the operator.