Rail Maintenance of Way Software: How a Recorded Defect Ends Up Past Its Remediation Date With Nobody Noticing

How a known defect ends up past its remediation date

A geometry car runs the territory on a Wednesday. The vendor delivers a file on Friday containing several hundred exceptions across ninety miles, each with a location expressed to the hundredth of a mile, a parameter, a magnitude and a severity. The track supervisor opens it on Monday, filters to the ones that matter, and starts a list. Meanwhile the walking inspection from Thursday recorded a defective joint bar by hand in a bound book, and the ultrasonic testing vendor's report from three weeks ago flagged a suspect rail that was scheduled for a follow up test that has not been booked.

Every one of those findings carries an obligation. The federal track safety standards do not simply require inspection, they require that when track does not meet the standard for its class the railroad brings it into compliance, restricts speed, or halts operations, and the rail defect table assigns each defect type a specific remedial action with a time limit attached. The obligation attaches on the day the defect was found, not on the day someone got to the spreadsheet.

What goes wrong is rarely negligence. It is that the finding exists in four places, the remediation clock exists in one person's head, the gang that can fix it needs a work window that the dispatcher controls, and the follow up test needs a vendor who is on another division. Then a supervisor takes annual leave and a defect quietly ages past its date. Nobody discovers it until an auditor, a regulator or a derailment investigation reconstructs the timeline.

Problem 1: track is a linear asset, and asset management systems are built for boxes

A pump has a serial number and a location. A rail does not work like that. Track is referenced linearly by milepost and offset within a track number, and everything about it is a range rather than a point: curve from 42.10 to 42.63, continuous welded rail from 38.00 to 51.20, Class 4 from 30.00 to 62.00 with a temporary restriction between 44.30 and 44.55. Assets overlap, ranges get resegmented when work is done, and mileposts themselves are not reliable arithmetic because equations and realignments leave gaps and overlaps in the numbering.

General enterprise asset management systems can be configured to represent this, and Maximo, Hexagon EAM and Bentley AssetWise all have customers who have done it. The honest position is that Bentley has the strongest native linear asset and inspection data heritage of the three, and Maximo has the strongest general work management. The gap they share is that a defect with a regulatory remediation clock, tied to a track class, resegmented when a rail is replaced, and blocked on a dispatcher issuing track and time, is a domain object none of them ship. You configure it, and then you own that configuration forever with a consultant on retainer.

A custom build makes linear referencing the foundation rather than an extension: an addressing model that handles equations, a resegmentation engine that preserves history when ranges split, and every finding, restriction and work record anchored to a range rather than to a point.

Problem 2: the remediation clock is the product

If you build one thing, build this. Every finding, whether it came from a walking inspection, a geometry car, ultrasonic testing, a bridge inspection or a train crew report, becomes a defect record with a classification, a location range, a discovery timestamp, the resulting remedial action and the date by which that action must be complete. Speed restrictions attach to the defect and are lifted by an authorised person with a record, not by a phone call to the dispatcher.

Then the daily view every roadmaster needs: what is due this week, what is due next week, what is overdue, and what is protected by a restriction versus what is not. This sounds obvious. It does not exist on most properties because the findings arrive in different formats from different sources and nobody has ever merged them into one register. Merging them is the whole job, and it is why the ingestion work matters more than the reporting layer.

Problem 3: geometry and testing data arrives in vendor formats and nobody normalises it

Geometry cars, rail flaw detection vehicles, ground penetrating radar for ballast, and increasingly track mounted sensors on revenue equipment all produce data in vendor specific formats, at vendor specific location precision, with vendor specific severity conventions. Two vendors will describe the same defect differently, and a vendor changing their export format will silently break a manual process that nobody documented.

The build needs an ingestion layer per source with location matching that accounts for the fact that a vendor's milepost and yours may disagree by a few hundredths, which is enough to put a defect on the wrong side of a turnout. Once normalised, the real value appears: repeat exception analysis. A location that produces geometry exceptions run after run is not a maintenance item, it is a subgrade or drainage problem, and surfacing it once a quarter does not fix it. That analysis is only possible when historic runs are stored in a comparable form, which is precisely what a spreadsheet workflow throws away.

Problem 4: the work window is the constraint, and dispatch does not know your plan

A gang cannot touch track without protection. Track and time authority, or its equivalent on your property, comes from the dispatcher, and roadway worker protection rules govern how the work is protected and briefed. So the maintenance plan is not really a maintenance plan, it is a negotiation with the operating department for windows, and windows are worth more than labour because a surfacing gang standing at a crossing for three hours costs the same as one working.

What a build adds is a work plan that carries its protection requirement, its expected duration and its geographic footprint, so that requests to dispatch are consolidated rather than made one at a time by four supervisors on the same subdivision. Where the property has an integration path to the dispatch system, granted windows flow back to the plan and to the gang's mobile device. Where it does not, the system at least stops two gangs requesting overlapping windows on the same territory, which happens more than anyone admits.

What a custom platform must include

Linear referencing with equations and resegmentation. A unified defect register with classification, remediation clocks and speed restriction lifecycle. Inspection recording on a phone or tablet, offline first, because signal on the right of way is not a given, with the inspection record itself being the regulatory artefact. Ingestion for geometry, ultrasonic and any other testing vendor you use. Work orders and gang scheduling tied to windows. Materials, particularly rail, ties and other track material, because a gang that arrives without the right rail section wastes the window. Bridge and structure inspection, which carries its own inspection and reporting obligations and is routinely run as a separate silo. Signals and crossing surfaces if you own them. Then reporting built for the regulator and the internal audit, meaning a complete timeline for any location on demand.

What it costs, how long it takes, and what drives the number

Across the 2,000 plus projects Digital Heroes has delivered, this is the shape. A first release covering linear referencing, the defect register with remediation clocks, mobile inspection capture and one testing vendor ingestion runs $110,000 to $240,000 and ships in 16 to 24 weeks. A full platform adding work orders and gang scheduling, window management, materials, bridges and structures, additional vendor feeds and audit reporting runs $300,000 to $800,000 phased over 9 to 18 months.

What drives the cost up specifically here: the number of testing vendors and whether their formats are stable. Bridges and structures, which are effectively a second asset domain. Transit properties, where third rail, catenary and station assets come with the track and the oversight regime differs from freight. Integration with dispatch, which is technically feasible and politically slow. And the quality of your existing asset inventory, because if nobody can tell you where the curves and the continuous welded rail territory actually start and end, that survey is real project time.

What keeps it down: start with one division, the defect register and mobile inspection. Those two together change behaviour within a month.

How to choose a developer for maintenance of way software

Ask them how they will handle a milepost equation. If they do not know what that is, they will build an addressing model that fails silently on your property and puts defects in the wrong place, which is the worst possible failure mode for this system. Follow up by asking what happens to historic defect records when a rail relay resegments a range.

Ask how the mobile inspection app behaves after six hours with no signal, and whether the record it produces is designed to be the regulatory artefact or a convenience copy of a paper book. If they intend the paper book to remain authoritative, you are buying a duplicate data entry system.

Ask which geometry or rail testing vendor formats they have ingested in production, by name, and how they handle location offsets between the vendor's referencing and yours. Ask to see how they would present a location timeline to an auditor: every inspection, every finding, every restriction and every repair at a given milepost, in order, with no assembly required. Then get ownership in writing before kickoff. You should hold the repository, the infrastructure accounts and the right to appoint another supplier. At Digital Heroes the client owns the code from the first commit, and for a system whose records may be examined after an incident, ownership of the data and the audit trail is not something to leave to a support contract.