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/rail-fleet-condition-monitoring-us/. DOI 10.5281/zenodo.23365118. The operator is described by class, never by name.
On a 225-car commuter fleet in the United States, a fault becomes visible in one of three ways: a crew radios it in, a yard employee notices it on a walk-round, or the car fails in service. None of those paths involves reading the car. Each car already exposes 64 named signals through its car system (32 digital at 0 to 48 VDC, 32 analog), plus a 3-axis accelerometer and GPS. Nothing reads them continuously today.
1. Execute the operator's table, do not replace it
The operator supplies its own fault-logic table over the 64 signals. The onboard module executes that table verbatim at the car, so a fault is detected where the reading is made and means exactly what the operator's engineers already say it means. The module is specified as a class, not a part number: EN 50155 and IEC 60571 railway electronics, 8 by 8 by 8 inches, IP62, 24 to 48 VDC from the vehicle battery, CFR 238 fire-rated materials because this is FRA-regulated commuter stock. A 3-car prototype comes before the 222-car rollout.
2. Ride the routers that are already there
The modules send telemetry through the car system's existing cellular routers rather than new connectivity, so the telemetry design inherits their NAT and port-forwarding behaviour from day one. Coverage on a moving fleet is intermittent, so each module runs store-and-forward buffering sized to the longest expected coverage gap, queue depth is a first-class metric, and a staleness alert tells the mechanical desk the feed is old rather than letting it look live.
3. Own the telemetry store
Compute is contractor-hosted in the United States with no server room on the property. The design adopts the ClickHouse real-time analytics architecture's serving patterns for subsecond fleet-wide fault views, and replaces the managed service with self-managed Apache Kafka plus InfluxDB 3 Core that the operator owns outright, saying the substitution plainly. Thirteen months of history over 64 channels on 225 cars sits there. Keycloak provides role-based accounts with MFA, because the web view is internet-facing and the account surface, not a network perimeter, is the control.
4. Fourteen objects
The fleet ontology holds the car, its monitoring module, the car system, digital and analog input channels, the active fault, the fault history record, the alert notification, the mechanical desk controller, the yard employee, the control center, the yard office, the slippery rail hotspot and the notification recipient group. One query walks from a smoothing reactor overtemperature fault to the analog channel that produced it, the car and its module, the controller responsible for that territory, and the group that gets the text.
5. Models
Mistral Large 3 675B (Apache-2.0), self-hosted with vLLM, serves the agentic work surface over the ontology; Chronos-2 (Apache-2.0) does analog anomaly detection and seasonal trending. No training run. At eight bits the 675B model needs about 675 GB for weights, so it sits on one node of eight 141 GB cards. Appendix A prices that node in AWS US East at about 625,000 US dollars over three years on the deepest commitment, about three eighths of the 1.66 million on demand; the 225 modules are priced by quotation and left out.
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/rail-fleet-condition-monitoring-us/
This predictive maintenance design is listed with every other published design as one of our sovereign AI reference architectures, and its object model sits with the other industrial ontology examples.
Top comments (0)