The product
Working software, not a roadmap.
RailExchange is running today. It models the network to railML, takes in what each party already produces, and gives every party the view of a movement that its role entitles it to.
Live running
Where every train is, as the parties report it
Movement reports, forecasts and ready-to-depart times arrive from the parties that know them, and every view is rebuilt from the same record.
Trains running now
last report and next call
| Train | Status | Last report | Next call | Expected |
|---|---|---|---|---|
| 2MB6 | In progress | Taree | Kempsey | 14:22+6 min |
| 4BM4 | In progress | Gloucester | Dungog | 14:41−2 min |
| 5SB3 | Ready to depart | Islington Jn | Maitland | 15:050 min |
| 3WB9 | Scheduled | Moss Vale | Goulburn | 16:30 |
- Trains running now
- A live board of every run under way: last report, next call, expected arrival and variance against the plan. It refreshes itself every minute, and each company sees only the trains it is entitled to.
- Electronic train graph
- Time and distance on one chart for a corridor: planned paths against actual running, crossings and loops, with links on to the adjoining territory.
- Live line view
- The corridor as a schematic, with each train placed on the track it last reported, for the people who think in sections rather than timetables.
- Movement reports
- Positions and events submitted by page or API, matched to the dated run and applied in the order they were accepted. They feed shared actual times that every entitled party sees.
- Ready to depart
- The operator's ready time reaches the network and the terminal the moment it is set, instead of by phone.
- Public transport feeds
- Passenger services from public real-time feeds can be placed on the same network, so freight paths are seen against the traffic they share track with.
Capacity
Capacity that can be found while it is still worth having
The three things operators ask a network for — available capacity, short-term availability and utilisation performance — answered as data, current at the moment of the question.
- Capacity register
- Spare paths and cancelled runs offered back to the market, by corridor and day, while there is still time to use them.
- Capacity watches
- A standing search over the register. When a matching path is relinquished or offered, the watcher is told at once.
- Path requests
- A scheduled or ad hoc path requested, offered, accepted or declined through one recorded workflow, with each step taken only by the party it belongs to.
- Path utilisation and performance
- Paths booked against paths run, and the load each run carried against what its path could take — reconciled to the same record the operator keeps.
Consists and forecasts
The train as actually loaded, and when it will really arrive
What is on the train, and how it will run, recorded by the party that knows and reused by everyone downstream.
- Consists
- Locomotives, wagons, load and gross mass as actually marshalled, submitted by page or API and updated in place — a box added at the terminal does not mean resending the train.
- Running-time forecasts
- A speed and distance model of each run from the route's speed limits and gradients and the train's own consist, so the expected arrival reflects the train that is actually running.
- Station forecasts and completion
- Expected times at each call, kept current as the run progresses, and a clear record of when a run is complete.
Freight
Freight followed by the people who own it
The shipment and its units, tied to the trains that carry them, using the identifiers the supply chain already prints on its labels.
- Shipments, consignments and units
- Containers, swap bodies and bulk loads identified by GS1 keys (SSCC, GSIN, GINC), placed in wagon slots and followed from leg to leg.
- Standard status events
- Milestones recorded against the UN/CEFACT Recommendation 24 status codes, so “accepted at interchange point” means the same thing to everyone.
- A view for freight owners
- A beneficial owner sees the trains carrying its freight and its own units in full. Other customers' freight on the same train appears only as an occupied slot.
The network model
One model of the railway, built to railML 3.3
Infrastructure, timetables, rolling stock and interlocking held to the railML 3.3 standard, so every party's data lands in the same shape.
- Infrastructure
- Lines, net elements, operational points, crossing loops and sidings, with line speeds taken from the published route access standards.
- Timetables
- Base itineraries, operational and commercial trains, and dated runs materialised for the weeks ahead.
- Rolling stock and interlocking
- Vehicle classes, formations and engines; signal boxes, routes and train detection sections.
The platform
Open to your systems, closed to everyone else
Everything the pages do is available to your systems, and every request is answered through the same access rules.
- Versioned REST API
- A documented OpenAPI interface with token authentication. Submissions accept idempotency keys, so a retry never records an event twice.
- Dashboards by role
- Infrastructure manager, operator, terminal, forwarder and freight owner each get the view their role on the movement calls for.
- Rule-based access
- Every company sees its own data, the reference data everyone shares, and what others have chosen to share with it — nothing else.
- Audit history and who-can-see
- Every change is attributed and kept. Any record can answer who changed it, and which companies can see it.
The ask
See it with your own data.
No procurement, no integration project and no lock-in. A short session to look at one of your existing data extracts together, and you are live inside two weeks.