Not so much profits over safety as an improperly defined and implemented government mandate that kept being expanded with bureaucratic afterthoughts.
I’m not going to be tiresome reiterating the idiocy of NAJPTC (which at one point had programmers coding in a train length of ‘zero’) or implementing what should have been at least four technical systems as an overlay on ‘overloaded’ (in the information-theory sense) legacy signal systems.
But the point of an effective anticollision system was definitively solved in principle by QNS&L, and it need go no further than reliable beaconing, with the locomotive and EOT signals relayed through the PTC communications infrastructure where radio or cell would be insufficiently reliable. A certain amount of metadata and expert-system ‘artificial intelligence’ would be needed to determine track-center separation, etc. where local fixed beaconing (differential beaconing a la Apple Find My being nonreliable and excessively prone to jitter and drift), but you’d have a 100% assurance of actual front- and end-of-train position, both for engineers of following trains and more ‘global’ system monitoring.
The requirements for a moving block PTC are formidable, full moving block even more so. Basic signal system protections such a broken rail detection go out the window and rail continuity has to be determined by alternative means. And much of the technology is still being developed: https://railroads.dot.gov/sites/fra.dot.gov/files/2023-11/FMB%20Concept%20and%20Specs.pdf
The problem with much of the historical automatic train control development was that it was justified and designed as punitive enforcement – only the Miller and Sprague systems were phrased as ‘train operating helps’, and the latter was designed into the existing framework of ‘penalty braking’ unless ‘forestalled’.
Some functions of PTC do need to function as emergency train stop – and they need to be absolute, not depending on manual forestalling action or the usual run of ‘vigilance’ controls or ‘alerters’ rhat in practice prove repeatedly to be anything but. But this was at the heart of the initial realization that “PTC” should be interworked separate systems, and it was something that I think the NTSB never fully appreciated in their chronic insistence on ‘positive train control’ of some inchoate perfected kind in their accident reports.
A system that informs three things – train separation; relative rate of closure; safe stopping distance of consist – is the thing necessary here. Note that except in some forms of CBTC this is NOT automatic block-signal specific, any more than coded speed or cab-signal indication needs to be, but some of its functionality can help with that great British no-no, “signal passed at danger”. And its operation should be an aid to train-handling, not a penalty if some detail or other isn’t carefully followed.
The one thing to remember - Trains ARE NOT line of sight vehicles if they are to be operated at any speed above a crawl.
Too many people thought PTC would solve EVERY operating condition that can be experienced during the normal and even abnormal course of the railroad working day.
All the while allowing trains, cars, and engines to perform coupling operations when necessary along the line of road. For example, engine swaps between trains, running around train to reverse direction, picking up cars set out on passing sidings, assisting another train up a grade, etc. Inevitably some sort of override will be needed. And with the override comes the possibility of something bad happening.
I don’t care who is pushing what - there is no magic that 100% solves every possible situation that happens in life. The only absolute is that birth causes death - the only question is how long it will take.
Obviously not but some are better than others. Whining that nothing is 100 % or that the only answer is to eliminate human idiots are not part of a serious dialogue.
I don’t believe that at all. There is no perfect system, despite what some of the “experts” say. Often those “experts” are lobbying for their particular system. I’ve seen that in articles in Railway Age written by “contributing editors.” Many of those articles are by someone pushing their latest and greatest idea, across all parts of the industry.
Regarding overrides for switching, etc. That feature exists and incidents have happened during the override.
Would a GPS mounted on the coupler have half of the sky blocked by the bulk of the back of the car it is attached to? Would it be a challenge to pick up enough satellites to get an accurate location?
The override mode is called Restricted Mode. When in restricted mode, PTC only enforces movement at restricted speed. The display map showing track segments and signals disappears.
The problems with restricted sight and multipath are much more complicated than that. Note that a ‘safety’ system really needs to be nondifferential, and much of the ‘consumer’ perception of GPS navigation with phones or in vehicles involves cheap differential enablement.
The only solution I could advocate involves a system of beacons with local accurate (not just precise) local disciplined time standards. This would best be implemented together with the enhanced GIS integration proposed by researchers at Carnegie-Mellon for predictive operation of train ‘automation’ like TO or Leader. Repeaters much like those that provide cell telephony or FM radio in vehicular tunnels.
Of course now that we have multiple systems of a great many satellites for Starlink and its competitors, if there were any desire for a “GPS”-like system with a great number of satellites for HA-NDGPS it could be provided with relatively little incremental/marginal expense…
Rubidium time/frequency standards are getting small enough to mount in a FRED, but I’m not sure if they would survive the shock and vibe inherent with a coupler mount.
It only prevents you from going over 20. I think 22 is enforcement.
Since as we all know: RESTRICTED SPEED IS NOT A SPEED - IT IS A METHOD OF OPERATION. That used to be drilled in our heads. Maybe they don’t train new guys like that, I don’t know.