# System design for physical AI: predictive maintenance from the 29 wayside detectors a freight railroad already runs

> Source: <https://dev.to/umar_bilal_fd6e1f54398cec/system-design-for-physical-ai-predictive-maintenance-from-the-29-wayside-detectors-a-freight-5g7o>
> Published: 2026-10-31 02:39:46+00:00

*By Muhammad Umar. This is the engineering summary of an open reference architecture. The paper, its object model as JSON and the model register are free to reuse under CC BY 4.0: [https://codeatoms.ai/wayside-detector-trending-rail-us/](https://codeatoms.ai/wayside-detector-trending-rail-us/). The operator is described by class, never by name.*

A freight railroad in the United States runs 29 wayside detectors: 22 hot box and hot wheel detectors, 4 wheel impact load detectors, 2 acoustic bearing detectors and 1 automated wheel profile system at its busiest yard entry. Each one judges every axle in isolation, and a stop alarm fires only when a single reading crosses a threshold. The weeks of rising readings that come before that alarm are already recorded, but nothing assembles them into a trend anyone acts on.

The design trends across the existing 29 detectors instead of installing new sites to close the spacing. Every reading is keyed to a serialized bearing and wheelset rather than to a car, so a bearing keeps its baseline across wheel changes, car renumbers and interchanges. Chronos-2 (Apache-2.0) forecasts each per-axle series zero-shot, with ambient temperature and train speed as covariates, and the residual against the forecast raises the trend flag. The warning interval is measured against detector spacing, so the forecast for an axle has to be ready before that axle reaches the next detector.

Five systems feed the design and none is replaced: the detector network, the maintenance system (CMMS/EAM), Railinc Umler and interchange services, the dispatcher advisory channel, and the contractor geometry and rail flaw reports, which arrive as PDFs and are digitized into the same pipeline. They enter through two adapter families. The integration adapter takes the detector network, the Railinc services and the digitized reports; the ops systems adapter takes the maintenance system and the dispatch advisory channel. Apache Kafka 4.3 in KRaft mode keys every reading on detector and axle position, so the passes for one bearing arrive in the order they were measured. The adapters upsert idempotently, so an at-least-once redelivery never double counts a reading.

The design adds a four-camera portal at the yard entry. D-FINE detects open doors, brake gear, wheel components and dragging equipment, and PP-OCRv6 reads the reporting mark, both on an octa-core NPU edge box beside the cameras under K3s. Streaming raw video to the data center was rejected because the cellular backhaul drops for hours. Only detections, OCR strings and short evidence frames cross the link, buffered store-and-forward until it returns. Reading the reporting mark at the edge makes the car number a join key before anything is uploaded.

The object model holds seven assets (freight car, locomotive, axle bearing, wheelset, traction motor, wayside detector, track segment), one measure (detector reading), five records (trend flag, work order, track geometry exception, rail flaw indication, AAR interchange record) and one event (train), joined by 13 typed links. One query walks from a flagged reading to the bearing it measured, the wheelset beside it, the car that rides on that wheelset, the work order that fixed that bearing last time, and the open geometry exception on the track segment where the reading was taken. It is one of our [industrial ontology examples](https://codeatoms.ai/industrial-ontology-examples/), published as JSON. The trend flag is where a person decides: it stays Open until a named person confirms it, dismisses it or raises a work order from it.

gpt-oss-120b (Apache-2.0, US origin) serves the ranked queue and the ontology-maintaining agents on vLLM. Its published checkpoint is about 65.2 GB, with the MoE weights in MXFP4 and the rest at 16 bit. With a 1.2 planning factor that is about 78.2 GB, so one 141 GB card in the railroad's own data center holds it with about 63 GB to spare. Every model is open weights on the railroad's hardware, and the only external link is the read-only Railinc feed. Appendix A prices the central card at about 54,000 US dollars to own over three years, against about 625,000 to rent the smallest AWS instance that holds one in US East on the deepest commitment. The system touches no signal, train control or PTC path. The single-reading stop alarm to the dispatcher stays exactly as it is, and a person decides every set out.

DOI: [https://doi.org/10.5281/zenodo.23556421](https://doi.org/10.5281/zenodo.23556421)

Designed on CodeNinja Praxis, the CodeNinja Atoms platform for designing physical AI systems. The object model imports into Hyper Ontology. Paper, ontology and register: [https://codeatoms.ai/wayside-detector-trending-rail-us/](https://codeatoms.ai/wayside-detector-trending-rail-us/)

More designs like this one: [sovereign AI reference architectures](https://codeatoms.ai/sovereign-ai-reference-architectures/).
