About

Originally developed by live-departures.info for users of our Digital Signage Services (UK Rail) display network located within station premises, Darwin.EDGE is a Push Port client architecture for streaming location specific Real Time Train Information (RTTI) out to live arrivals and departure boards within a fraction of a second of updates being received on the nationwide XML feed. Compatible with both National Rail Data Portal (NRDP) and direct access schemas, Darwin.EDGE can be licensed on a per-location basis to run on your own network infrastructure with hosted options also available. Please contact us for more information.

Background and overview of the NRDP Open Data Services

National Rail Enquiries makes available two methods of accessing live train information for the UK rail network. The most straight forward is a request / response API whereby a client makes a call to a method of the Open Live Departure Boards Web Service (OpenLDBWS) such as GetDepartureBoard. This approach is ideal for ad-hoc requests, such as those made by a website or app to show live train information for any station upon request by a user. An OpenLDBWS response requires no interpretation by the client containing the data exactly as is it should be displayed.

It is not however ultimately suitable for Customer Information System (CIS) displays, dedicated to a particular application such as a departure board for a specific location. Theoretically of course (usage limits notwithstanding), a web service can be polled in a continuous loop however a low frequency refresh is not ideal for the client and correspondingly a much a higher frequency refresh is not ideal for the network or server.

So in order to provide developers with far more flexibility, the NRDP provides access to a service known as the Darwin Push Port. Darwin is the UK rail industry's core RTTI platform as used by station passenger information systems and various other applications. Push Port clients receive a continuous stream of train schedules, schedule updates, timing forecasts and actual timing.

To replicate the functionality of the web services but without the usage limits, Push Port can be consumed into a database containing a complete live picture of all in service and scheduled trains. The database can be queried on demand to generate the live station board data (departures, arrivals etc.) for any location on the network however the issue of request / response not being ideal for dedicated CIS displays remains.

Implementation

Darwin.EDGE extends the train schedule + update stream concept of Push Port right out to the display hardware in the form of a station board + update stream. A layered model keeps the data format independent of the state and subscribe transport layer by first defining a collection of complex types to be broadcast using JavaScript Object Notation. TRAIN objects contain the current live information for a service as it should be displayed regardless of position in the display order. ORDER objects then map services to each line of the station board. STATE objects enable clients to confirm end to end connection and data integrity.

Client initialisation is dependent upon transport layer implementation. The current state may be obtained from a REST endpoint (provided by Darwin.EDGE servers) or streamed privately to new clients upon subscription subject to broker functionality. Initialisation consists of processing all current TRAIN objects:

  {"type":"TRAIN","crs":"STA","key":"P583461555","std":"15:55","ds":["London Euston"],"pl":"1","dtd":"On time",...}
  {"type":"TRAIN","crs":"STA","key":"P451611601","std":"16:01","ds":["Bristol Temple Meads"],"pl":"4","dtd":"On time",...}
  {"type":"TRAIN","crs":"STA","key":"P490041610","std":"16:10","ds":["Birmingham New Street"],"pl":"4","dtd":"16:13",...}
  ⋮
  

...followed by the display ORDER:

  {"type":"ORDER","crs":"STA","key":"P583461555","index":1,"count":10}
  {"type":"ORDER","crs":"STA","key":"P451611601","index":2,"count":10}
  {"type":"ORDER","crs":"STA","key":"P490041610","index":3,"count":10}
  ⋮
  

When changes to board content occur only the affected objects are broadcast, so for example if the 16:01 Bristol Temple Meads service is forecast as 3 minutes delayed, the following would be broadcast:

  {"type":"TRAIN","crs":"STA","key":"P451611601","std":"16:01","ds":["Bristol Temple Meads"],"pl":"4","dtd":"16:04",...}
  

During normal service with no disruption a client can therefore expect a very low data volume consisting periodically of a TRAIN object for the next service coming on to the board followed by updated ORDER objects as trains depart or terminate. STATE objects providing confidence and acting as a keep-alive are at least every 60 seconds:

  {"type":"STATE","crs":"STA","ts":"2019-06-13T15:52:00","hash":"96de7b2b9fda4cb65f88f83fbeb66bcf"}
  

Object Reference »