AI / ML in CBTC: Real Use Cases vs Hype (2026)

In late 2024, every major CBTC vendor and most major transit agencies had at least one slide in their conference deck on artificial intelligence. By early 2026, the slides have been refined, the demonstrations have been published, and a small set of US deployments have crossed the line from pilot to production. This is also the period in which the gap between what AI in CBTC can actually do and what the marketing suggests it does has become hardest to ignore. The sober version is that machine learning is delivering real value in a narrow set of CBTC applications, the value is concentrated outside the safety-critical layer, and the deployments that have produced credible operational improvements have done so through unglamorous data-engineering work rather than through the model architectures the press releases highlight. This post is a 2026 audit of where AI in CBTC actually works, where it does not, and what an agency or vendor planning a deployment should treat as signal versus noise.

The safety boundary that matters most

The single most important fact about AI in CBTC in 2026 is the safety boundary. The Automatic Train Protection layer of any CBTC system is a SIL 4 safety-critical function governed by IEC 61508, EN 50126, EN 50128, EN 50129, and the US-specific IEEE 1474 framework. These standards require deterministic, formally provable, traceable behavior. As the manuscript states plainly, current software-safety standards do not provide a recognized pathway for machine-learned models to make safety-critical decisions such as braking interventions, because behavior derived from training data cannot satisfy the traceability and evidence requirements for SIL 4 systems.

The implication is that machine-learned ATP, ML-driven Movement Authority calculation, and learned vision-based collision avoidance are not deployed in revenue service in any US CBTC system in 2026, and the consensus standards that would permit them are years away. The European Union Agency for Railways and the IEC have working groups exploring methodology for safety assurance of learned components, but no consensus standard exists, and the agencies and vendors that publish credible technical material on this topic agree the timeline is in the 2030s at the earliest. (For the foundational layer where the safety boundary is enforced, see ATP, ATO, ATS: The Three-Layer Triad of Modern Train Control.)

This is not a temporary state. It is the structural reality of safety-critical infrastructure. AI deployments in CBTC in 2026 work because they live above or beside the safety layer, not inside it.

Where AI is actually delivering value

Three application domains have produced credible operational results in US transit CBTC by early 2026.

Predictive maintenance and condition-based monitoring

Predictive maintenance is the highest-value and most mature AI application in transit CBTC today. The basic idea is to ingest the rich diagnostic data streams that CBTC systems already generate — VOBC event logs, wayside interlocking databases, access point received-signal-strength trends, axle counter health signals, point-machine stroke profiles, track-circuit continuity records — and apply machine learning to detect degradation before it produces a service-affecting failure. The technical recipes are unglamorous: isolation forests for anomaly detection on individual signals, gradient-boosted tree ensembles (XGBoost, LightGBM) for multi-sensor failure-probability estimation, Long Short-Term Memory recurrent networks for time-series anomaly detection on context-dependent signals like point-machine motor current.

US transit agencies and vendor platforms have built operational predictive-maintenance programs of varying maturity. Washington Metropolitan Transit Authority has invested in data analytics platforms that correlate maintenance history with asset telemetry to identify high-risk rolling stock and signaling components ahead of failure. Metropolitan Transportation Authority runs asset-health programs that combine historical maintenance records with real-time condition monitoring to optimize the timing of major overhauls. Chicago Transit Authority has integrated SCADA analytics into its preventive-maintenance workflows. Vendor platforms — Hitachi Lumada, Siemens Railigent X, and Alstom HealthHub — provide pre-built predictive-maintenance capabilities tailored to rolling stock, signaling, and infrastructure assets.

The credible operational results from mature programs are 10 to 25 percent reduction in unplanned failures, 15 to 30 percent extension of mean time between failures, and return on investment in 2 to 4 years. These numbers are real, they are reproducible across multiple agencies, and they are the strongest empirical support for AI in CBTC in 2026. They are also less impressive than the marketing material implies — the gains are incremental rather than transformative, and they require significant up-front investment in data engineering, taxonomy definition, and quality-assurance processes.

Dispatch and scheduling optimization (advisory only)

The second application domain is real-time dispatch and adaptive scheduling. When a CBTC line experiences a delay, the Automatic Train Supervision layer and the human dispatchers work to restore service through complex optimization — minimizing passenger-minute delay, respecting safety headways, maintaining power-budget constraints, and avoiding cascading bunching. Reinforcement-learning algorithms have shown promise in academic and operational trials.

The credible deployments are advisory rather than autonomous. The Paris RATP has undertaken research programs in automatic traffic regulation using RL-based techniques. Transport for London has conducted AI research projects on the Underground. In these deployments, the AI system computes a recommended action that a human dispatcher reviews before execution. This human-in-the-loop architecture preserves safety and matches the regulatory environment.

In US transit CBTC, full closed-loop autonomous dispatch is not standard practice. BART has piloted advisory AI components in its Operations Control Center, with the AI providing recommendations that dispatchers can accept, modify, or override. MTA’s ATS and operations technology teams have published research on AI-assisted dispatch. The advisory-mode architecture is what works in practice, and the productive question for an agency in 2026 is not whether to automate dispatch but how to integrate machine recommendations into existing dispatcher workflows without introducing new failure modes.

Anomaly detection and cybersecurity

The third domain is anomaly detection in operational data and on the cybersecurity layer. Two distinct uses are relevant. Operational anomaly detection — early identification of subsystem degradation through subtle declines in access-point coverage, interlocking processor response times, or rolling-stock power efficiency — sits adjacent to predictive maintenance and uses similar techniques. Cybersecurity anomaly detection — unsupervised models on OCC and wayside network traffic that flag patterns consistent with reconnaissance or unauthorized access — fits inside the security operations center workflow, complements rule-based intrusion detection, and is encouraged by TSA Security Directives 1580 and 1582 and NIST SP 800-82 Revision 3.

Both anomaly-detection uses are non-safety-critical, both are advisory, and both have produced operational value at the agencies that have invested in them.

AI in CBTC works above and beside the safety boundary. The safety-critical core remains deterministic and formally provable.

What AI cannot yet do in CBTC

Several uses are commonly proposed in marketing material and have no credible production deployment in 2026.

Machine-learned ATP braking decisions are not deployable in revenue service. Braking-curve calculation, Movement Authority generation, and collision-avoidance interventions are SIL 4 functions. The standards that would permit a learned model to make a safety-critical braking decision do not exist. Vendor research programs are exploring formal-verification techniques for learned components, but no consensus pathway has emerged.

Autonomous vision-based collision avoidance is not yet a SIL 4 sensor. Computer-vision systems can detect obstacles and classify objects with high accuracy in normal conditions. The safety case for vision as a primary sensor requires multiple independent redundant sensors, fully characterized adversarial robustness, and a certification pathway that current standards do not provide. The Las Vegas Monorail and several recent European light-rail networks have integrated LiDAR for real-time scanning, but as a complementary sensor, not as the primary source of safety decisions.

Autonomous cybersecurity defense is not yet appropriate. Machine learning excels at detecting anomalies; human experts must validate that detected anomalies are genuine threats rather than false positives. Closed-loop automated responses to detected threats — for example, isolating a suspected compromised access point without human review — are not standard practice in critical infrastructure and are not encouraged by TSA or NIST guidance.

Generative AI for safety-critical artifacts is not appropriate. Large language model generation of code that goes into the safety-critical path, of safety case prose that an independent assessor will sign, or of certification artifacts is not aligned with the certification culture or the standards. Generative AI is increasingly used for non-safety-critical artifacts (documentation, training material, internal procedures) and that use is unobjectionable; the safety boundary applies here as elsewhere.

What an agency or vendor planning a deployment should treat as signal

Several practical points for someone in 2026 evaluating an AI deployment in a CBTC context.

Predictive maintenance is the highest-confidence starting point. The data is already being generated, the technical recipes are mature, the vendor platforms are available, the operational benefit is reproducible across multiple agencies, and the safety boundary is not crossed. An agency starting an AI program should start here unless there is a specific reason to start somewhere else.

Data engineering is the bottleneck, not modeling. The agencies and vendors that have built productive AI programs spent the first 12 to 24 months on data taxonomy, data quality, and integration of historical data sources rather than on model selection. The agencies that started with the model and then asked for the data tend to deliver less.

MLOps and model lifecycle management matter. ML models drift as the operational environment changes. The agency or vendor that does not invest in monitoring, retraining, and re-validation of deployed models will find the model’s performance degrades over the life of the system. The transit IT environment is not historically strong on these capabilities; vendor partnership or consultancy support is typical.

Workforce planning matters as much as technology selection. Predictive maintenance does not displace signal maintainers; it shifts skill demand toward data interpretation, anomaly validation, and integration of machine recommendations with domain expertise. The agency that deploys AI without investing in training and career-path frameworks for its existing maintenance staff will see the deployment underperform or stall.

The NIST AI Risk Management Framework 1.0 is the right governance template for US agencies. Map (purpose, scope, stakeholders, harms), Measure (baselines, bias, fairness, data governance), Manage (monitoring and response procedures), Govern (accountability, incident response, transparency). The framework is non-prescriptive but it forces the right questions.

Open data architecture matters more than vendor model claims. Whichever vendor’s predictive-maintenance platform an agency adopts, the agency should negotiate explicit data-ownership clauses, ensure data can be extracted in open formats, and avoid platforms that lock the agency’s operational data into a vendor-specific store. The model claims are similar across vendors; the data architecture is where the lock-in lives.

What the next three to five years are likely to bring

Three projections that are reasonably hedged.

Production predictive-maintenance programs are expected to expand from the early adopters (WMATA, MTA, BART, CTA) to most US transit agencies with operational CBTC by 2028 to 2030. The benefits are reproducible enough and the vendor platforms are mature enough that the laggards face increasing pressure to adopt.

Advisory-mode dispatch optimization is likely to expand from the current pilot deployments to operational use in several US transit agencies by 2028 to 2030. Closed-loop autonomous dispatch is unlikely in revenue service before 2030 and is more likely to remain advisory through the decade. (For the broader 2030 picture, see The 2030 CBTC Landscape: 5 Predictions.)

Machine-learned safety-critical functions are unlikely to enter US CBTC revenue service before 2032 to 2035, and the path forward depends on consensus emerging in the international standards bodies. The European Union Agency for Railways and the IEC are the venues to watch. US agencies should expect to be implementers of standards developed elsewhere rather than first adopters of any safety-critical AI capability.

What this means in practice

• The safety boundary is the most important fact about AI in CBTC in 2026. Machine-learned models cannot make SIL 4 decisions in production today, and the consensus standards that would permit them are years away. AI deployments work above and beside the safety layer.
• Predictive maintenance is the highest-value and most mature AI application in US transit CBTC. Mature programs achieve 10 to 25 percent reduction in unplanned failures, 15 to 30 percent extension of mean time between failures, and 2- to 4-year ROI. Real, reproducible, but incremental rather than transformative.
• Advisory-mode dispatch optimization is maturing. RATP, TfL, BART, and MTA have credible programs. Closed-loop autonomous dispatch remains rare and contentious.
• Anomaly detection on operational and cybersecurity data is delivering value when integrated into existing SOC and operations workflows. The frameworks (TSA SD 1580/1582, NIST SP 800-82 Rev 3, NIST AI RMF 1.0) are the right governance templates.
• The bottleneck is data engineering and MLOps, not model selection. Workforce planning matters as much as technology selection. Open data architecture matters more than vendor model claims.
• Machine-learned ATP braking, autonomous vision collision avoidance, autonomous cyber-defense, and generative AI for safety-critical artifacts are not appropriate for production in 2026 and are not expected to become so before the early 2030s.

Where to go next

This post is a 10-minute briefing. The full discussion of vendor AI roadmaps and the NIST AI RMF lens applied to transit lives in Chapter 15 of Communications-Based Train Control (Volume 2): Buy on Amazon.

Sources

• Wang, C. (2026). Communications-Based Train Control, Volume 2: Operations, Lifecycle & US Deployment. Independent. ISBN 979-8-258-54295-3. — Chapter 15, “Vendor Landscape and Technology Trends.”
• National Institute of Standards and Technology. AI Risk Management Framework 1.0. nist.gov/itl/ai-risk-management-framework
• National Institute of Standards and Technology. NIST Special Publication 800-82 Revision 3: Guide to Operational Technology (OT) Security.
• Transportation Security Administration. Security Directives 1580 and 1582. tsa.gov
• International Electrotechnical Commission. IEC 61508: Functional safety of electrical/electronic/programmable electronic safety-related systems.
• European Committee for Electrotechnical Standardization (CENELEC). EN 50126, EN 50128, EN 50129: Railway applications standards.
• Washington Metropolitan Area Transit Authority. Asset Management and Predictive Maintenance Reports. wmata.com
• Metropolitan Transportation Authority (NY). Capital Program and Asset Management Documentation. new.mta.info
• Bay Area Rapid Transit. Train Control Modernization Program Status Reports. bart.gov
• Transport for London. AI and Innovation Reports. tfl.gov.uk