SMART Berth Offsets - inaccuracy?

[greaterangrier]

From my understanding, berth offsets are used to estimate the departure/arrival times at stations.

So, a if a train moved from the berth 1054 to 1052 on a train's departure on City Thameslink at 10:52:16, the train would have been said to have departed at 10:52:00.

If a TOC chose to have berth offsets not reflective of real-world values, whether intentionally or accidentally, they would save on Delay Repay as they could claim a train arrived at 10:51 to the minute or 10:51:59, when it actually arrived at 10:52:30, since a particular berth offset would be too short. Bad offsets also affect connections, arguably a lot more.

Additionally, by doing a TOC could also improved performance statistics because they could claim their trains run to T-3 far more often than they actually do.

Is there any incentive to make sure this data is inputted correctly?
Who manages these offsets?
Have you had any success challenging delay repay claims, where railway systems have claimed a train arrived earlier than it actually did?
Or where they claim you could have caught a connection, which you physically could not have?

If this was done on purpose everywhere, would a saving be made in theory?

 

[CapabilityB]

Just asking some questions to make this thread accessible:

- What's a berth offset?

- what do you perceive the incentive to be for operators to lie to their customers? (That's the underlying message I took from your post)

 

[The Planner]

Berth offsets are dealt with by NR.

 

[Vexed]

You can download the Performance Data Accuracy Code (PDAC) September 2024 edition from the Delay Attribution Board on Network Rail's site. It sets out the responsibilites Network Rail and operators have.

Delay Attribution Board - Network Rail

A resource which practitioners can use to access information on the rules that govern the Rail Industry’s Delay Attribution process,...

www.networkrail.co.uk

It's a long document which will answer most of your questions.
Specifically sections 7 is about offsets and section 12 is about good faith, though there is a lot more in there on the process if you want to read more about it and other (most) sections are relevant as well. The appendices have flow charts on the process for changes to be made.

 

[TSG]

From my understanding, berth offsets are used to estimate the departure/arrival times at stations.

So, a if a train moved from the berth 1054 to 1052 on a train's departure on City Thameslink at 10:52:16, the train would have been said to have departed at 10:52:00.

If a TOC chose to have berth offsets not reflective of real-world values, whether intentionally or accidentally, they would save on Delay Repay as they could claim a train arrived at 10:51 to the minute or 10:51:59, when it actually arrived at 10:52:30, since a particular berth offset would be too short. Bad offsets also affect connections, arguably a lot more.

Additionally, by doing a TOC could also improved performance statistics because they could claim their trains run to T-3 far more often than they actually do.

Is there any incentive to make sure this data is inputted correctly?
Who manages these offsets?
Have you had any success challenging delay repay claims, where railway systems have claimed a train arrived earlier than it actually did?
Or where they claim you could have caught a connection, which you physically could not have?

If this was done on purpose everywhere, would a saving be made in theory?

Why would SMART need to estimate the time of departure from City Thameslink? That would be among the densest concentrations of sections, and thus train describer berths, on the network. No adjustment would be necessary as you can tell how far along the platform a train is, let alone when it moves off. I would imagine offsets would be useful only where stations are situated well within long sections.

What would be the point of trying to fool about with them anyway? Unless you do it for the entire route, late trains would suddenly have a jump in delay where the offsets stopped surely?

 

[Gaelan]

- What's a berth offset?

In most parts of the country, realtime train status information is derived from signaling data: the system determines when the train enters a particular signal block (aka "berth"), and uses that time to determine when the train arrived at (or departed from) a particular station.

Unfortunately, signals aren't always placed exactly before and after stations, so there's no way to determine exactly when a train arrived at a station from signaling data alone. Instead, they take the time at the closest block boundary, and add or subtract a certain fixed amount of time (specific to the location in question) to get a best estimate of when the train would have arrived/departed the station. This fixed amount of time is known as the "berth offset".

The industry (Network Rail, I assume) maintains a database of berth offsets in a system called SMART. I believe Realtime Trains also has its own collection of independently calculated berth offsets.

 

[Tazi Hupefi]

Amidst your conspiracy theory, you probably neglect that it works both ways, some berth offsets can work against a TOC, just as much as for it - this is the signalling system in general. Where train running data relies on manual reports from signallers in older Absolute Block areas, signallers very rarely use fractional times, almost always using a full number, so if your train arrives at 10:00¼ - they'll enter it at 10:01.

In any event, the train operators don't get a say - it's managed by Network Rail, the state owned infrastructure provider.

 

[Vexed]

Unless you do it for the entire route, late trains would suddenly have a jump in delay where the offsets stopped surely?

There is very comprehensive SMART offset data so this isn't an issue for signalling areas where Train Describers are in use. As the OP inferred with their 10:52:16 to 10:52:00 time the offset for an Up Departure from Plat 1 at City Thameslink is -16 seconds.

I include SMART data on my website (you need to scroll down a little) and there are 13 different offsets for City Thameslink! Though without a berth map it's not the most useful data.

TIPLOC data - Vail Data

View data for locations on the GB rail network. You can view location information, geospatial information from BPLAN and TPS, and berth offset and step data from SMART.

vaildata.uk

 

[greaterangrier]

I wasn't aware of the role that NR & Delay Attribution worked into all of this, so thanks all for answering in that regard.

I created this post because of the amount of times Delay Repay said my train was earlier than it actually was. It's very frustrating to go through the Delay Repay and the appeals process every time, for which my claims always go through secondary quality checks, and so I get extended delays each time.

But also, train departure data is very variable on my line. Trains show Delayed and turn up on time (thankfully), and lateness displayed on train tracking websites is always limited in accuracy - I would like to know whether I'm likely to catch my connection or not.

It's nice to know that it's under NR's control, but also as driver behaviour changes/stopping positions change/resignalling occurs, disappointing to see how long some of these values haven't been reflective of real-world data. It feels a bit like the P-coding, obviously though with far less impact. After all, a TOC doesn't have much of an incentive to change these times (I assume TOCs mostly do this as suggested in the PDAC)

 

[endofthetunnel]

In terms of recorded times, regardless of what open data like RTT shows, TRUST, which is the only system against which train delays are officially measured, only works in whole minutes.
TRUST schedules can use and display half minute increments but recordings are always truncated (not rounded up/down). This is after the offset is applied (in seconds).
So a 8am departure calculated at 08:00:01 and 08:00:59 are both ‘on time’, but 08:01:00 is 1L and 07:59:59 is 1E despite there being just seconds difference

I don’t know if TOCs use a different system for their delay repay.

 

[Tazi Hupefi]

They all use different systems and sources of data - normally selecting the source that is most favourable to the customer if there is a material difference. TOCs want to pay out compensation as quickly as possible - they're not particularly bothered about being on the hook for it, as it's almost always funded by the government (open access aside). The main metric they're measured against is how quickly they are paid and how many appeals etc are received.

Some TOCs with newer Hitachi (and a few other) trains are able to get the time that the doors were actually released, not just the time it got to the platform. The GPS data has become so effective and reliable that this is often used to, (this even sometimes goes directly into TRUST).

 

[Belperpete]

In most parts of the country, realtime train status information is derived from signaling data: the system determines when the train enters a particular signal block (aka "berth"), and uses that time to determine when the train arrived at (or departed from) a particular station.

The most public manifestation of this is when an automated announcement tells you "the train at platform xx is for ...." when the train hasn't yet arrived at the platform. The system has seen the train description step into the platform berth, and so assumes that the train has arrived, when in fact the train itself has only just passed the signal governing entry to the platform, which can be some distance away.

 

[Freightmaster]

The most public manifestation of this is when an automated announcement tells you "the train at platform xx is for ...." when the train hasn't yet arrived at the platform. The system has seen the train description step into the platform berth, and so assumes that the train has arrived, when in fact the train itself has only just passed the signal governing entry to the platform, which can be some distance away.

That's what berth offsets are supposed to prevent!



MARK

 

[Javelin_55]

I wasn't aware of the role that NR & Delay Attribution worked into all of this, so thanks all for answering in that regard.

When I was in attribution, we had several berth offset errors that would crop up regularly which were a nightmare to deal with. The TRUST schedule would show the train's recorded timings jumping about and recording false delays. We always had to contact the NR side to get them to P-code the delay, but sometimes reactionary delays were added in, which obviously weren't right, so we would have to unpick each one of those as well and find out where they were supposed to go.

 

[james_the_xv]

The most public manifestation of this is when an automated announcement tells you "the train at platform xx is for ...." when the train hasn't yet arrived at the platform. The system has seen the train description step into the platform berth, and so assumes that the train has arrived, when in fact the train itself has only just passed the signal governing entry to the platform, which can be some distance away.

At least at Rugby and MKC, these announcements are 'the train now arriving' which makes sense.

 

[Surreytraveller]

That's what berth offsets are supposed to prevent!



MARK

I believe CIS systems have their own berth offsets

 

[Wilts Wanderer]

It would be interesting to know to what extent Network Rail routinely review and correct berth offsets in SMART. Given that the offsets themselves are making an assumption about an ‘average’ type of rolling stock on a route, any significant change to the rolling stock on a route (for instance, diesel HSTs replaced by electric 80x) should trigger a full review of all berth offsets. I wonder if it happens in practice?

 

[Bald Rick]

Is there any incentive to make sure this data is inputted correctly?

Who manages these offsets?

It's nice to know that it's under NR's control, but also as driver behaviour changes/stopping positions change/resignalling occurs, disappointing to see how long some of these values haven't been reflective of real-world data.

To add what others have said, Berth offsets are checked regularly by Data Quality Specialists in the NR Performance teams. Their work is audited by a central team, and monthly reports isued on the quality of berth offset checking. And then the ORR audits NR on it every year.

The issue is that offsets have to be calculated as an average of observed values. Variability in driving styles - and particularly the (in my view) disease of crawling up the length of platforms at little more than walking pace before stopping means that the recorded arrival time will be earlier than in practice.

It’s fairly rare that this would have an impact on a Delay repay claim though.

 

[FGW_DID]

A TOC can request the berth offsets are changed, we got ours changed for departures exiting the various connections at Reading TCD to reflect the distance between the departure signals (one of the TCD‘s ground position lights ‘GPLs’) and the first timing point they encountered, usually the first TVSC controlled signal.

For example, at the Reading Station end (depot connection E), a unit departing from one of the GPLs may take over a minute before it reaches T1708 where the first timing point is encountered.

 

[louis97]

To add what others have said, Berth offsets are checked regularly by Data Quality Specialists in the NR Performance teams. Their work is audited by a central team, and monthly reports isued on the quality of berth offset checking. And then the ORR audits NR on it every year.

The issue is that offsets have to be calculated as an average of observed values. Variability in driving styles - and particularly the (in my view) disease of crawling up the length of platforms at little more than walking pace before stopping means that the recorded arrival time will be earlier than in practice.

It’s fairly rare that this would have an impact on a Delay repay claim though.

As you say the SMART offsets are checked regularly, however if Darwin has its own data for a particular move it will use that. Unfortunately Darwin is full of incorrect offsets, and this is what is used, in most instances, for delay repay claims.

Darwin tends to be OK for areas with shorter signal sections, however not so much for areas with longer sections. Some of the errors within Darwin have been around for a long time, and I suspect they stem from SMART offset errors that have since been corrected.