Background and Context

The solution to the problem lies in matching Train Services to Rolling Stock.

Train Operators use the term Train Service to refer to a sequence of locations and times at which a particular service is expected to arrive at or depart from. For instance a service A might depart at 7 am from King’s Cross, arrive at 7.10 am at Holloway and depart at 7.12 from Holloway to Finsbury Park and so on. However, it does not state which physical train (or Rolling Stock) will run service A.

Usually, the Train Operators will create a Diagram that states which particular Rolling Stock will run (part of) a service. Under normal circumstances, the operators follow these plans. But when any disruption occurs, everything needs to be re-planned. Depending on the severity of the problem and the size of the company, it is not always possible to keep track of all the decisions that were made.

If no accurate record was kept, at the end of the day the operators need to manually figure out which Rolling Stock ended up running which Service. This is a very time-consuming and error-prone task. However, since Rolling Stock usually have GPS and we know exactly what happened to each Service, we can use that data, together with the Diagrams and the Schedule, to automate this process. A potential algorithm would consume various real-time data feeds and give as an output which Rolling Stock actually ran which Service.

Client information

Atos is a European IT services company that provides consulting, managed services and system integration. The company also provides management services to Network Rail. Essentially, Atos provides all of the resource planning, diagramming and the services to distribute data amongst multiple systems. But since the railway is very old and large organization, managing it is a very difficult task. Therefore our challenge is to an essential part of the entire system more efficient and effective.

Project Requirements

The two main deliverables in the project can be summarised concisely as:

  1. Efficient real-time service matching algorithm
  2. Prototype application using this algorithm to match units and services based on data received and display output

However, this can be broken down into many more detailed requirements&emdash;these are listed in the MoSCoW format below:

Must have

  • The algorithm should work in real time. This comes with several sub-goals that needs to be achieved namely :
    • Consume data feeds in real time (Feeds that needs to be consumed in real time include TRUST data and GPS data)
    • Store newly consumed data in a suitable format for processing as they come in
    • Process the pattern matching with the new data along with static data sources( Schedule data, Diagram data)
  • The prototype also has several components to it
    • Return list of units that have diverged
    • Visualise the output data

Should have

  • You can select any Rolling Stock, to get more accurate information
  • Track all Rolling Stock throughout the day
  • Deploy system to be accessible via the web
  • Search by service headcode, or unit ID

Could have

  • Support more complex scenarios, discussed in under discoveries
  • Test system using real data instead of test data

Would have

  • Return the data in the same form as the diagrams and highlights where changes have happened
  • Compare the milage record obtained from the algorithm to the milage record calculated from all GPS events
  • Handle situations where Rolling Stock go to the maintenance depot after running the Services

Our prototype as of April 2016 satisfies all of the must and should have requirements. We have not been able to test the system using real-time data as we don’t have access to ATOS systems, but we have tested it on different static data sets. This is as good as it helped us to quantify how well our algorithm works on different datasets.