Rail Software Development Services for Transport Operators
Rail software development for operational systems that keep the timetable honest
A rail or bus operator runs on one plan and a day that departs from it: a late crew, a failed unit, a blocked line. ZingZee builds the operational systems that hold the planned timetable, record what was run, handle the disruption from a pre-approved scenario, and tell passengers the same thing on every screen, app, and platform announcement.
- Cyprus, engineers across the globe
- Five-phase delivery
- Typed, tested, handed over
What rail software development covers
Rail software development is the design, build, and long-term support of the operational systems a rail or public transport operator runs the service on: timetable planning and publication, disruption handling, crew and fleet allocation, depot and maintenance scheduling, passenger information, and the performance reporting the authority reads.
ZingZee builds these systems for operators, infrastructure managers, and transport authorities that need the planned service, the actual service, and what passengers were told to come from one record. Each system runs around the clock, connects to the signalling, ticketing, and vehicle data already in place, and is delivered with the documentation a franchise or concession requires.
Rail and transport software services ZingZee provides
Timetable planning and publication
ZingZee builds timetable systems that hold the base plan and its variants, validate a change against rolling stock diagrams, crew rules, and platform occupancy, and publish one version to every channel. Engineering possessions and seasonal changes are planned as amendments with a start and an end.
Disruption handling and control room tools
The control room view shows the service against the plan in real time, with a library of pre-approved disruption scenarios for blocked lines, failed units, and staff shortages. Applying a scenario amends the plan, reallocates resources, and issues passenger messages, with every action recorded against the controller who took it.
Crew, fleet, and depot allocation
Allocation tools assign crew and units to diagrams under the operator's working agreements and maintenance intervals, show the consequences of a change before it is made, and hand the amended allocation to the control room and the depot. Maintenance windows are planned against the timetable, so a unit due for exam is never diagrammed for service.
Passenger information across every channel
The passenger information layer generates departures, platforms, delays, and alternatives from the amended plan and delivers them to station screens, announcements, the operator's app and website, and the national feeds. Messages are written once by the controller and rendered for each channel, and screens and apps are tested to WCAG 2.2 AA.
Performance reporting and delay attribution
Reporting compares planned and actual to the authority's definitions of punctuality and reliability, attributes each delay to a cause with its evidence, and produces the periodic returns the concession or franchise requires. Each figure traces to the service records it was derived from, so a query from the authority is answered from the system.
Rail software development for operational systems that keep the timetable honest
Operators and authorities ZingZee builds for
ZingZee builds rail software for passenger train operators running under a franchise, a concession, or public ownership, for metro and light rail operators with high-frequency services and short recovery times, and for freight operators whose paths, crews, and locomotives are planned against a shared network. It builds for bus and coach operators that need timetable, allocation, and passenger information under a municipal or regional contract, and for ferry operators with the same planning problem on water. It also builds for infrastructure managers and transport authorities that need performance reporting, possession planning, and passenger information consolidated across several operators on one network.
Why ZingZee for rail and transport work
ZingZee designs every rail system so the planned service, the actual service, and what passengers were told are three views of one record. A performance return, a delay attribution, and a passenger complaint are answered from the same data with no reconciliation between systems.
ZingZee connects to signalling, train describer, and vehicle systems through read-only interfaces and the gateways the infrastructure manager approves, and takes no part in a safety function. The boundary is written into the architecture and the controls document, so the safety case is unaffected by the operational platform.
Operational systems run twenty-four hours with no maintenance window that suits a night service, so ZingZee builds for rolling deployment, failover, and a degraded mode in which the control room keeps working while a component is replaced.
Franchises and concessions run for a decade or more, so ZingZee delivers source code, infrastructure definitions, and a runbook into the operator's repositories, and builds on a stack with long-term support. A second supplier can take over at a re-tender.
When rail software development is the right choice
Rail software development is the right choice when an operator's timetable lives in one system, its control log in another, and its passenger information in a third, with staff re-keying between them on a bad day. The same applies when disruption is handled from a controller's memory and a phone, when the authority queries performance figures the operator cannot trace to a source, and when a concession or franchise requires reporting and passenger information standards a packaged product cannot meet. A new operator or a new line that needs an operational platform before the first service runs is also a fit.
When custom rail software is the wrong choice
Custom rail software is the wrong choice when the operator's infrastructure manager or authority mandates a national system for timetabling or passenger information and the gap is integration with it. It is the wrong choice for a safety-critical function: signalling, interlocking, train protection, and anything else that requires a safety integrity level is the domain of suppliers approved for that work, and ZingZee builds beside those systems, never inside them. An operator with no control manager to own the disruption scenarios should also wait, because a scenario library nobody maintains is out of date at the first incident.
Rail and transport use cases
One timetable version feeding the app, the screens, and the national feed
A regional rail operator replaces a planning spreadsheet, a separate screen system, and a manual feed export with a timetable model that validates changes and publishes a single version to every channel. An engineering possession planned on Monday appears correctly on the screens, the app, and the trip planners on the day.
A blocked line handled from a prepared scenario
A metro operator prepares scenarios for its most common disruptions, each with a revised service pattern, a crew and unit reallocation, and passenger messages by station. When a line is blocked, the controller applies the scenario in minutes, every channel updates at once, and the incident log records the decision and its timing.
Bus fleet and driver allocation under working agreements
A municipal bus operator allocates drivers and vehicles to duties under its working time rules and maintenance intervals in a tool that shows the effect of a change before it is confirmed. Depot staff, the control room, and the drivers read the same allocation, and a sickness call is reallocated without a phone chain.
Performance figures the authority can trace
A concession operator produces its periodic punctuality and reliability returns from the operational record, with each delay attributed to a cause and its evidence held against the service. When the authority queries a figure, the operator opens the services behind it and answers from the record, with no spreadsheet reconciliation.
Passenger information that says the same thing everywhere
An operator whose station screens, announcements, and app disagreed during disruption generates all three from the amended plan. The controller writes one message per station, the system renders it for each channel, and a passenger with a screen reader receives the same information as one reading the board.
Rail and transport engagement scope
Deliverables
The agreed systems in production, source code and infrastructure definitions in the operator's repositories, the timetable and service data model, the interface specifications for signalling, ticketing, and vehicle feeds, the disruption scenario library structure, the test suite with results, and the control room runbook.
Included as standard
A strategic assessment with planning, control, and performance teams, architecture for around-the-clock operation with failover, build in reviewed increments, integration testing against recorded live feeds, WCAG 2.2 AA testing for passenger channels, a penetration test, control room training, and go-live support during live running.
Priced separately
Historical timetable and performance data migration, additional feed integrations beyond the agreed set, station screen and announcement hardware and its installation, the onboarding fees a national feed body charges, and the aftercare arrangement agreed at go-live, with around-the-clock cover.
What the client provides
The current timetable, diagrams, and working agreements, access to the planning, control, and depot teams, interface documentation and credentials for signalling, ticketing, and vehicle systems, the authority's performance definitions and reporting formats, and an operations director who signs off the design and each release.
Outside the engagement
Signalling, interlocking, train protection, and any function with a safety integrity level, the safety case itself, the operator's relationship with the infrastructure manager and the authority, the content of the disruption scenarios, and rolling stock and depot decisions remain with the operator.
How a rail and transport engagement with ZingZee runs
A rail and transport engagement follows ZingZee's five-phase delivery framework, timed around the operator's timetable change dates. The strategic assessment reads the current timetable, the control log, the performance returns, and the interface documentation, interviews planners, controllers, and depot staff, and maps where the plan, the day, and the passenger message diverge. It produces a prioritised list of modules and the feeds each depends on. The AI roadmap fixes the architecture for continuous operation, the hosting, the integration boundary with safety-critical systems, and the order of delivery. Integration and deployment builds each module against recorded and then live feeds, runs it in shadow beside the current system, and takes it into production at a timetable change. Adoption and enablement trains the control room on live scenarios. Governance, optimisation and scale keeps the scenario library, the feeds, and the reporting definitions current as the network and the concession change.
Strategic assessment
We assess how the business operates today: its processes, its data and the systems it runs on. From that we identify the use cases with the highest return and confirm the organisation is ready to adopt them, so the programme starts from a defined baseline.
AI roadmap
Findings become a phased roadmap that balances early wins with the longer build. ZingZee sets the milestones, the resourcing and the governance that keep delivery on schedule and aligned to business objectives.
Integration and deployment
Our engineers develop, validate and deploy the solution into your production environment, integrated with the enterprise systems you already run and sized for the workloads it will carry.
Adoption and enablement
Enablement programmes prepare business users and technical teams to work with the new capability, and structured change management ensures the organisation captures the full value of what has been deployed.
Governance, optimisation and scale
Ongoing governance, monitoring and optimisation keep the solution accurate, compliant and performing. Proven solutions are then scaled across departments and regions under the same data governance standards.
Rail and transport tooling
Transport operational systems are built on a stack chosen for continuous operation, long-term support, and the message formats the industry uses. The tooling covers:
- Java or Go services for the timetable model, control view, and allocation engines
- PostgreSQL for the service record with time-series storage for vehicle positions and events
- Message handling for GTFS, GTFS-Realtime, SIRI, NeTEx, and operator-specific train describer feeds
- Redis and message queues for real-time distribution to screens, apps, and announcement systems
- Angular or React front ends for the control room and passenger channels, tested to WCAG 2.2 AA
- Rolling deployment, failover, and monitoring built for around-the-clock operation
Rail and transport delivery practices
Every operational system ZingZee builds keeps the plan, the amendments, and the actual events as an append-only record, so the state at any minute of any day can be reconstructed for an incident review or an authority query. Integrations with signalling, train describer, and vehicle systems are read-only and pass through the gateways the infrastructure manager requires. Deployments roll one node at a time with the control room informed, and a degraded mode keeps the core view available while a component is replaced. Passenger channels are tested with screen readers and on station hardware before release. Releases pass automated tests, a shadow run against live feeds, and the operator's change control before production.
Cost and time for rail software development
The cost of rail software development depends on the number of modules in scope, the feeds and systems to integrate, the number of passenger channels to serve, the authority's reporting definitions, and whether the system replaces an existing platform or runs beside one. A passenger information layer over an existing timetable feed is a matter of weeks to a few months from strategic assessment to production. A timetable and control platform with disruption scenarios and allocation is a matter of months, delivered in phases so each module goes live at a timetable change date with a shadow run before it. Reporting and delay attribution are added as a phase once the service record is live. ZingZee provides a written estimate after the strategic assessment.
What happens next?
You send a description of the network and the service, the systems the timetable, control room, and passenger information run on today, and the reporting the authority requires.
An engineer reads it and replies within two working days with the shape of a strategic assessment and the teams that will be interviewed.
You sign a non-disclosure agreement if you need one, and you receive a proposal with the modules, the timetable change dates they would go live at, the estimate, and the team.
Frequently asked questions
Straight answers on Rail and transport work with ZingZee.