Positive Train Control is not a universal autopilot and does not replace an engineer, dispatcher, signal system or operating rules. FRA describes PTC as communication- and processor-based technology designed to prevent four defined accident types. The practical evidence questions are whether the territory and movement were PTC-governed, what authority and restrictions the system held, what it displayed or enforced, and whether any component was unavailable or cut out. This is a general guide, not legal advice or a technical finding about any accident.
The four core PTC functions
FRA's PTC overview identifies four functions, while detailed requirements appear in 49 CFR Part 236, Subpart I. PTC was reported fully implemented on all federally required route miles at the end of 2020, but that does not mean every U.S. track or rail movement is covered.
| Designed prevention function | Questions after an event | Records to correlate |
|---|---|---|
| Train-to-train collision | What movement authority did each train and the back office hold, and were host and tenant systems interoperating? | Authorities, dispatch history, onboard logs, track occupancy, radio |
| Overspeed derailment | What permanent or temporary restriction was active, what braking curve was calculated and when did warning or enforcement begin? | Subdivision data, restriction upload, PTC display, event recorder, brake response |
| Incursion into established roadway work limits | Were the limits properly entered, validated and transmitted, and did the train receive them? | Work authority, dispatch and back-office logs, onboard database, RWIC communications |
| Movement through a main-line switch in the wrong position | Was the switch monitored, what position was reported and was the move within a covered main-line scenario? | Wayside interface, switch indication, signal log, onboard and dispatch data |
PTC does not promise to prevent grade-crossing collisions, trespasser strikes, broken-rail derailments or every switching accident. Some events involve functions outside its design. Identifying the event category prevents the misleading conclusion that any accident on equipped territory equals a PTC failure.
Where PTC accident data can exist
A PTC system may combine an onboard computer, location inputs, a back-office server, wireless communications, wayside interface units and railroad databases. The exact architecture varies: common freight and passenger systems are not identical. Investigators should identify the host railroad, tenant railroad, system type, software and database versions, locomotive and territory before asking for “the PTC log.”
A system-specific preservation request may identify:
- onboard initialization, train consist, position, authority, warning and enforcement logs;
- back-office movement authorities, subdivision files, temporary restrictions and message history;
- wayside interface and switch-position messages, signal indications and health alarms;
- communications status, failed messages, cutouts, enforcements and fault codes;
- software, map and braking-algorithm version information relevant to the trip;
- event-recorder, locomotive video, dispatch audio and crew statements for synchronization.
The host, tenant, system vendor and equipment maintainer may hold different portions. Clock alignment is crucial because a message's send time, receipt time and processing time are not necessarily the same. Compare PTC records with the independent event-recorder and camera evidence rather than treating one system as the sole clock.
Malfunctions, cutouts and limits of inference
“PTC unavailable” can describe different conditions: failure to initialize, a communications issue, bad position data, a component fault, a territory problem or a system intentionally cut out under a rule. The applicable operating restriction and response depend on the system and circumstances. A screenshot or crew recollection should be tested against raw diagnostic and dispatch data.
A failure code does not by itself show that the failure caused the accident. Investigators ask what protection remained, what operating rule applied, whether speed or authority was restricted, what the crew and dispatcher knew, and whether timely repair or reporting duties were followed. Product, carrier and employee responsibilities should not be assumed from the location of the failed component.
Worked evidence example
Hypothetical: a passenger train enters a temporary 45-mph restriction above the posted speed and derails. The event recorder shows braking two seconds before PTC enforcement. The onboard log shows the restriction, while a back-office message shows a later effective time. Dispatch audio confirms the restriction was issued earlier, and the crew timetable device displays it correctly.
The records raise multiple questions rather than one easy answer: which effective time governed, when the train received and acknowledged the restriction, whether the PTC database matched, why enforcement occurred when it did, and whether braking could prevent the derailment at that point. Versioned files and synchronized clocks allow engineers to test the braking curve instead of inferring failure from the wreck alone.
A focused preservation checklist
- Identify the host and tenant railroads, system type, territory, locomotive, train and exact time window.
- Preserve onboard, back-office, wayside and communications records, not just a crew display image.
- Request the versioned map, restriction, software and braking data used for that trip.
- Correlate event-recorder, dispatch, radio, signal and video sources using shared events.
- Document any reported cutout or initialization issue and the operating rule used in response.
- Use a qualified system-specific expert before reaching a technical conclusion.
PTC evidence often overlaps with fatigue, work-zone and derailment issues. Continue with the fatigue timeline guide, the roadway-worker guide or derailment claims as appropriate.
Frequently asked questions
Does every railroad line have Positive Train Control?
No. Federal law mandates PTC on specified main lines, subject to detailed definitions, exceptions and exclusions. Other lines may use different signal or train-control systems, so identify the territory and system actually in service.
Can PTC data show why a train did not stop?
It may help. Onboard, wayside and back-office records can show authorities, restrictions, warnings, initialization, enforcement and some failures, but they must be synchronized with the event recorder, dispatch, signal and operating records.
Does the absence of a PTC stop prove the system failed?
No. The event may have been outside PTC's required functions or territory, the train may have been operating under an authorized condition, or another technical factor may apply. A qualified system-specific analysis is required.