In a previous posting on this blog, Hey! Watch This, I reported on some of the findings stated in the U.S.’s General Accounting Office (GAO) report on PTC dated December 2010. The bottom line of that report was that the cost / benefit ratio over 20 years for implementing PTC is hovering around 20/1; an absolutely unacceptable criteria for private investment. And yet, that is the burden, the cost of doing business, for the freight railroads it seems. For the commuter and regional rail systems that require public funding to stay in gear, the challenges of obtaining the necessary funding are likely to be even more severe. Given these circumstances, the question needs to be asked as to what can be done (other than obtaining Federal funding) to make the cost/benefit ratio more reasonable.
The opportunities to obtain a more reasonable cost/benefit ratio fall into three categories obviously, i.e., reduce the costs, increase the benefits, or do both. Until now, the only focus has been on increasing the benefits. However, as I have noted in the referenced posting, as well as others on this blog, there are no business benefits directly associated with PTC; PTC is only a safety-enhancement system. Those fatuous attempts by either naïve or mischievous individuals to identify business benefits have been rejected mostly by now, with only the occasional exception as discussed in my posting, Really! You Gotta Let It Go. So, the safety benefits that have been identified for PTC are all that there are.
So! If the benefit denominator of the cost/benefit ratio can’t be increased, then the only option is to decrease the cost numerator. Interestingly, there are three very significant ways to do that, although they still may not provide a reasonable cost/benefit ratio. The first possibility, again, has been addressed on this blog already. I am referring to tightly integrating the PTC platform with an IT / wireless data platform to provide a mobile node architecture for a railroad’s management system just as a manufacturer would do with fixed nodes to manage its facilities. The second possibility to reduce costs is to go after the wireless infrastructure that is being developed by the Class Is. As also addressed on this blog, this network is a tremendous overkill for what is needed for PTC as currently structured. And as will be described immediately below, the wireless infrastructure is even more irrational if the third method of reducing costs is taken into consideration, i.e., significantly reducing the number of Wayside Interface Units (WIUs).
Why Oh Why the WIUs ?
The implementation of PTC requires 4 primary components.
1. On-board PTC platforms (clients);
2. A back-office PTC platform (server);
3. Wayside interface units that provide for the interchange of data between the critical wayside infrastructure components and the PTC clients / server; and
4. A wireless communication network to deliver the necessary data between the other 3 components.
There simply is no way to reduce the number of PTC clients or to eliminate the server. However, when it comes to the WIU’s there is in fact a major opportunity to minimize the number of units required, that is if one doesn’t accept what is being said by the industry. Specifically, the estimated number of WIUs that will need to be installed to implement PTC across the U.S. has gone from 75,000 for shock value by the freight railroads following the mandate, to the current estimate of 50,000. Now, with the recent agreement by the Obama Administration to reduce the amount of trackage requiring PTC by 10,000 miles, due to changes in traffic by 2016, the estimated requirement for WIUs is probably now around 45,000. But, the kicker is that such a number is still way too high, at least from a regulatory standpoint.
To understand what can be done to reduce the WIU requirement first requires understanding the functionalities that are provided by the use of WIUs, as follows:
1. Reporting status of a manual switch to the PTC server for routing a train in dark territory;
2. Reporting status of a manual switch to the PTC server or clients for supporting enforcement of a train to prevent unauthorized movement through a misaligned switch;
3. Reporting aspects of the control points to the PTC server or clients so as to set up the “targets” for possible enforcement; and
4. Report aspects of the intermediary signals (ISs) to the PTC server or clients so as to set up the “targets” for possible enforcement.
There is a 5th functionality supported by the use of WIUs that is not directly associated with PTC deployment, i.e.
5. Permitting the operator to operate a switch remotely from the locomotive either within the train’s authority if PTC is operable, or without checking for authority should PTC not be available.
Now, like everyone else, did you accept #4 regarding ISs without question? In fact, to incorporate ISs into PTC functionality is not a regulatory requirement of PTC. Additionally, not only does incorporating ISs into PTC not provide any true advantage, but one could argue that to monitor ISs could become more of a hazard than a benefit, as well as a source for decreased velocity, due to the increase likelihood of false enforcements.
Note: the issue of false enforcements is primarily due to the significant variance in determining the braking curve necessary for enforcement, thereby possibly enforcing the train to a stop when it fact the operator could have managed to handle the train properly.
So, why have ISs been incorporated into the PTC platform? It all stems back, in my opinion, to one individual at one Class I who took the dark territory solution for PTC for which I was the architect at CSX, and put a non-pragmatic signal territory spin on top of it. However, it may go deeper than that it seems. Just as with the resistance that existed by Labor to reduce the trackage that requires PTC by 10,000 miles, as noted earlier, it seems that Labor has had its hands in the design of PTC as well. I guess it comes down to jobs. In short, not only is PTC not a rationally justified safety system, but there is an irrational level of infrastructure being required to satisfy Labor.
I am not quite through as to reducing the use of WIU’s. I now look at point #3 as to the WIUs for control point. The point here is that the control points are already connected to the CAD platform via a wireless or wired pole line. These communication links provide the same data to CAD that are required by PTC. That means that WIUs are not required for control points either in that the code line infrastructure can be tapped by the PTC server at the back office to get the information required to generate targets. Wait, I am still not done with reducing the number of WIUs.
Consider point #2 as to ensuring no movement through a misaligned switch. This situation is somewhat similar to the approach I developed for handling work gangs and the Employee in Charge (EIC), which by the way is the approach being used for PTC by the freight railroads. That is, the on board PTC client notifies the operator of the train’s approach to a work gang and requests that s/he indicates via the on board PTC display whether or not s/he has approval provided by the EIC to proceed into the work zone. If no positive response is received by the PTC client within certain distance / speed / time parameters, then an enforcement is made. This same approach could be used to notify the operator of an upcoming switch and to request an input by the operator that s/he can verify that the switch is properly aligned. Again, as with the work gang, if a positive response is not received within a certain combination of distance / speed/ time, then an enforcement is made. While this approach may seem a bit awkward, it is in fact a solution that is directly aligned with the operating rules.
Finally, as to point #1, the use of WIU’s for routing trains in dark territory. Actually, that one is still appropriate in that it was the solution I conceived for the development of PTC at CSX. As mentioned above, that PTC project was for dark territory and the other alternatives for routing trains at that time were too outlandish and/or too expensive, including the failed pursuit by the joint venture of GE and Harris to deploy Precision Train Control (not positive train control), a vital, moving block operation.
One last thought here. If indeed the railroads were to greatly reduce the number of WIUs based upon the above, then the cost of the wireless network would be significantly reduced as well, me thinks.
I await your comments.