Maintenance of Way Software Problems: The 5 That Put Defects Past Their Date, and How to Avoid Them

Why does merging every inspection source into one register go wrong so often?

Every property already collects the findings. What no property does naturally is put them in one place with one clock. A geometry run produces several hundred exceptions in a vendor file with locations to the hundredth of a mile. A walking inspection produces handwritten entries with locations given as landmarks. Rail flaw testing produces suspect rails with follow up test obligations. A train crew reports a rough spot with no location precision at all. Each of those is a legitimate finding that carries an obligation from the day it was discovered.

Projects underscope this because the register looks like a table. It is not a table, it is a reconciliation problem. The same defect described three ways by three sources must resolve to one record, or your overdue list is padded with duplicates and your team stops trusting it within a month. Different sources also disagree about location by a few hundredths of a mile, which is enough to put a defect on the wrong side of a turnout.

The fix is to make the register the first thing you build and to give it a matching rule you can tune, not a matching rule buried in code. A new finding within a defined distance of an open finding of a compatible type gets proposed as the same defect and confirmed by a human. Every source keeps its own identifier so a supervisor can trace a merged record back to the geometry run or the inspection that produced it. Build that before any reporting, because reporting on a register nobody trusts is worse than no reporting at all.

What goes wrong with linear referencing and milepost equations?

Track is addressed by milepost and offset within a track number, and everything about it is a range rather than a point. Mileposts are not arithmetic. Equations and past realignments leave gaps and overlaps in the numbering, so milepost 44.30 plus 0.25 is not reliably milepost 44.55, and a system that assumes it will silently place findings in the wrong location for the life of the property.

The second half of this problem is resegmentation. A rail relay splits a range. A curve is realigned. A class boundary moves. Every historic defect, restriction and work record anchored to the old range has to remain readable and correctly located afterwards, because an auditor asking about milepost 44.4 wants the whole history at that point regardless of how many times the segmentation changed underneath it.

Then there is the inventory itself. Many properties cannot state precisely where curves begin and end, where continuous welded rail territory starts, or where the class boundaries sit, because the authoritative answer is in a track chart that has been amended by hand. That survey is real project time and it belongs in the plan rather than in a surprise. Do the addressing model and the survey for one division first, prove the timeline view works, then extend. Rolling the model out across the whole property before it has been tested against a real audit question is how a build ends up needing its data rebuilt.

Why do geometry car and rail flaw vendor feeds break after launch?

Because the feed was treated as a file format rather than as a relationship with an outside company. A geometry vendor changes a column name, adds a severity level, alters the precision of a location field, or switches from one export tool to another, and the ingestion silently drops records or misplaces them. Nobody notices until a supervisor asks why last week's run produced fewer exceptions than usual.

Two design decisions prevent most of this. First, every ingestion run is a record in its own right, with the file it consumed, the row count in, the row count matched, and the rows rejected with reasons. If a run brings in 412 rows and matches 389, that gap is visible on a screen instead of buried. Second, location matching must tolerate disagreement between the vendor's referencing and yours, with the tolerance set per vendor from observed behaviour rather than assumed. Beyond that tolerance the record goes to a review queue rather than being placed confidently in the wrong spot.

The other half of the answer is contractual rather than technical. Name in your vendor agreements that format changes come with notice and a sample file. Ingestion built by a competent team will survive a schema change with a configuration edit. Ingestion built as a one off script will need a developer, and by the time the developer is available two runs have been lost.

What happens when the remediation clock and restriction lifecycle are not covered?

This is the part that turns a maintenance system into a compliance system, and it is the part most often deferred to phase two. The federal track safety standards do not merely require inspection. When track does not meet the standard for its class, the railroad must bring it into compliance, restrict speed, or stop operating over it, and the rail defect provisions attach specific remedial actions with time limits. The obligation begins on the day of discovery.

Software that records findings without modelling that obligation gives you a nicer looking version of the problem you already have. What the register needs is a classification that drives a required remedial action, a due date computed from the discovery timestamp, and a speed restriction that is an object with a life of its own: applied by a named person, visible to everyone who needs it, and lifted only by an authorised action that records who lifted it and on what basis. A restriction lifted by a phone call is a restriction that exists in one person's memory.

Then build the one screen that changes behaviour: due this week, due next week, overdue, and overdue but protected by a restriction. A roadmaster who opens that every morning catches the ageing defect. Nothing here substitutes for your own regulatory counsel's reading of the standards, and the classification table should be owned and signed off by the people accountable for it rather than by a developer.

Should you build custom or configure what you already own?

If you are a short line with a hundred miles, one roadmaster and one testing vendor, do not build. A disciplined mobile inspection app feeding a shared register, with a weekly review the roadmaster runs personally, is proportionate. Your risk lives in process rather than in platform, and a $200,000 system will not make a small team more attentive than a weekly meeting does.

If you already run IBM Maximo or Hexagon EAM for your wider asset estate, configuring track into it is a defensible route, and Bentley AssetWise carries the strongest native linear asset and inspection heritage of the three. Be honest about what you are taking on. None of them ships the domain object that matters most here: a defect carrying a regulatory remediation clock, tied to track class, resegmented when rail is replaced, and blocked on a dispatcher granting protection. You configure that in, and you then own the configuration indefinitely, usually with consultant support on retainer.

Build when you own more than a few hundred track miles, you take geometry and rail flaw data from outside vendors, and the remediation clock currently lives on a supervisor's spreadsheet. Keep the enterprise system for work management and materials if it is already embedded. The case for building is the defect register and the mobile capture, not a wholesale replacement of a system your finance team depends on.

How do hidden costs get into the quote?

The estimates in this category move for reasons that have nothing to do with software complexity.

• Testing vendor count. Each vendor is a separate ingestion with its own format, precision and severity convention. Two vendors is not twice one vendor's effort, but four is not close to one either, and a proposal quoting ingestion as a single line item has not asked how many you use.
• Bridges and structures. These carry their own inspection and reporting obligations and are effectively a second asset domain. They are routinely dropped into scope late because they were assumed to be part of track.
• Asset inventory quality. If nobody can state where curves, continuous welded rail territory and class boundaries actually begin and end, surveying that is project time before anything else is trustworthy.
• Offline capture. Right of way connectivity is not a given, and offline first mobile capture with queued synchronisation roughly doubles the testing burden. It is also not optional, because an app that needs signal will be worked around with a notebook.
• Dispatch integration. Technically feasible, politically slow. Price it as a phase with a dependency on another department's approvals rather than as a sprint.

Transit properties should add third rail, catenary and station assets to that list, since they arrive with the track and their oversight regime differs from freight.

What separates a build that works from one that fails here?

Four things, and you can check all of them before a contract exists.

The team can explain a milepost equation without being told what one is. If they cannot, they will build an addressing model that fails quietly on your property, which is the worst possible failure mode for a system whose whole purpose is knowing where a defect is. Follow up by asking what happens to historic defect records when a relay resegments a range, because that answer separates people who have modelled linear assets from people who have read about them.

The mobile inspection record is designed to be the regulatory artefact rather than a convenience copy of the bound book. If the paper book stays authoritative, you have bought duplicate data entry, and inspectors will treat it accordingly.

They can name geometry or rail flaw formats they have ingested in production and describe how they handled the offset between the vendor's referencing and the railroad's. Specifics here are cheap to give and impossible to fake.

And they build the location timeline early, not last. Ask them to show how an auditor would see every inspection, finding, restriction and repair at a given milepost in order with no assembly required. That view is what proves the data model is right, and it is also the view that catches an ageing defect before anyone external does. Settle code and infrastructure ownership in writing before kickoff, because records that may be examined after an incident should never sit behind a supplier's support contract.