Sector · Rail and transportation
Physical AI for rail and transportation
These are the questions engineers ask first, answered from 1 published CodeNinja Atoms reference architecture.
- What does a physical AI system for rail and transportation look like?
- Which AI models can a rail and transportation operator run on its own hardware?
- How much compute and hardware does AI in rail and transportation need?
- Is it cheaper to own AI hardware or rent cloud GPUs in rail and transportation?
- What ontology or object model does a rail and transportation AI system need?
- Who approves the decisions an AI system makes in rail and transportation?
What does a physical AI system for rail and transportation look like?
A complete physical AI design for rail and transportation names what to sense, which existing systems to join, the object model that joins them, the models and hardware, the three-year cost and the person who approves every action. CodeNinja Atoms has published 1 such reference architecture for rail and transportation, each free to reuse under CC BY 4.0.
| Design | Country | What it does |
|---|---|---|
| Consist Watch | United States | An open reference architecture for system design in physical AI. A real time condition monitoring system for a 225-car commuter fleet in the United States: onboard modules read 64 named signals per car and execute the operator's own fault-logic table at the car, telemetry rides the car system's existing cellular routers to a contractor-hosted US cloud, and severity-ranked faults reach the mechanical desk and the yard through one fleet ontology. |
Which AI models can a rail and transportation operator run on its own hardware?
Each published rail and transportation design names its models and why, and every model is open-weight or no model is used at all, so the operator can run it on hardware it owns.
| Design | Models |
|---|---|
| Consist Watch | Mistral Large 3 675B (Apache-2.0, self-hosted with vLLM) for the agentic work surface over the fleet ontology; Chronos-2 (Apache-2.0) for analog anomaly detection and seasonal trending; no training run |
| Design | Choice | What was picked | Why |
|---|---|---|---|
| Consist Watch | Model | Mistral Large 3 675B Instruct, Apache-2.0, served with vLLM | Reasons over the fleet ontology for the agentic work surface and ontology maintenance, self-hosted in the contractor's US cloud with no training run |
| Consist Watch | Model | Amazon Chronos-2, a universal time series forecasting model, Apache-2.0 | Analog channel anomaly detection and seasonal trending over 64 signals per car without a training run |
| Consist Watch | Hardware class | 141 GB HBM GPU class, one node | Holds the 675B model at eight bits with KV headroom |
| Consist Watch | Hardware class | Onboard monitoring module, EN 50155 and IEC 60571 railway electronics, IP62, 24 to 48 VDC, CFR 238 materials | Executes the operator's own fault-logic table at the car, so a fault is visible before it reaches the cloud |
| Consist Watch | Tool: event streaming and messaging | Apache Kafka 4.3 (KRaft mode, three dedicated controllers), Apache License 2.0 | 225 cars bursting over intermittent cellular links need a buffered backbone that decouples onboard store-and-forward from the fault engine and the dashboard, and Kafka 4.3 KRaft is the self-managed production pattern the customer owns outright. |
| Consist Watch | Tool: time series and telemetry storage | InfluxDB 3 Core, dual licensed MIT OR Apache 2.0 at the user's choosing | 64 channels on 225 cars for 13 months of tabular and graphical history (C8, intake A3) is a telemetry-store workload first, and InfluxDB 3 Core is the permissive, self-hosted default the customer owns; TimescaleDB was weighed and set aside because its compression and continuous-aggregate features sit behind the non-OSI Timescale License. |
| Consist Watch | Tool: on site language model serving | vLLM, Apache-2.0 | The agent work surface model is self-hosted on the contractor's US cloud so the operator owns the weights, and vLLM 0.29.0 serves the 675B FP8 checkpoint with paged attention and continuous batching behind an OpenAI-compatible API; the version is pinned and change-boarded because the release cadence moves memory behaviour between minor versions. |
| Consist Watch | Tool: time synchronisation across sensors and systems | chrony 4.9 with linuxptp 4.x where sub-second ordering is required, GPL-2.0 | Slippery-rail hotspot logic joins slip/slide events across all trains by location and time (§3.4), so unsynchronised module clocks would produce confident wrong orderings; GNSS time from the Digi router disciplines onboard clocks and NTP/PTP discipline the cloud tier. |
| Consist Watch | Tool: observability of the running system | Prometheus with Grafana and Loki, Prometheus Apache-2.0; Grafana and Loki AGPL-3.0 (run unmodified for internal use) | A monitoring system must itself be monitored: message delivery per car, queue depth behind cellular gaps, module heartbeats and alert delivery latency are the metrics whose silence is the first sign the fleet has gone blind. |
| Consist Watch | Tool: identity and access on site | Keycloak, Apache-2.0 | A4 commits standalone user accounts with role-based access and MFA over an internet-facing view with unlimited user-specific licences, and Keycloak provides exactly that — OIDC login for the desk, yard and agent surfaces with roles mapped to mechanical-desk, yard, engineer and administrator. |
How much compute and hardware does AI in rail and transportation need?
The compute follows from the models: the published rail and transportation designs size it as follows, from no new hardware to a full GPU node.
| Design | Part | The design |
|---|---|---|
| Consist Watch | Compute | At the car, an EN 50155 and IEC 60571 module (8 by 8 by 8 inches, IP62, 24 to 48 VDC, CFR 238 materials); centrally, one 141 GB HBM GPU class node in a contractor-hosted US cloud |
Is it cheaper to own AI hardware or rent cloud GPUs in rail and transportation?
Each rail and transportation design prices three years of ownership in its Appendix A, with every price cited, against renting the same capacity from a cloud region at its deepest three-year commitment where hardware is bought.
| Design | Line | Three years |
|---|---|---|
| Consist Watch | Three-year cost | About 625,000 US dollars to run the eight-card node for three years on the deepest AWS commitment in US East, about three eighths of the 1.66 million on demand; the 225 modules are priced by quotation (Appendix A) |
What ontology or object model does a rail and transportation AI system need?
The object model is the part that makes the system an ontology rather than a pipeline: typed objects for the things in the rail and transportation operation, with properties, status values and typed links. Every published design ships its object model as hyper-ontology/1 JSON that loads into Hyper Ontology.
| Design | Size | Objects | Download |
|---|---|---|---|
| Consist Watch | 14 objects, 13 links | the operator's car, Onboard monitoring module, The car system, Digital input channel, Analog input channel, Active fault, Fault history record, Alert notification, Mechanical desk controller, Yard employee, the control center mechanical desk, the yard office, Slippery rail hotspot, Notification recipient group | objects.json |
Who approves the decisions an AI system makes in rail and transportation?
In every published rail and transportation design a named person makes the decision that changes the physical world; the system prepares it.
| Design | Human control |
|---|---|
| Consist Watch | The module executes the operator's own fault logic verbatim; a named mechanical desk controller owns every active fault in that car's territory, and alerts go by severity to named recipient groups |
Every answer on this page is drawn from the papers linked in it: each paper's At a glance table, model register and cost appendix. Full text for agents: llms-full.txt. Designed on Praxis; object models load into Hyper Ontology.
Want one of these designs for your own operation? Talk to us.