Strategic Railroading

Posts Tagged ‘railroad’

With the introduction of overlay PTC just over a decade ago, the concept of vitality needed to be expanded at that point beyond the mantra of signaling engineers as to a vital component or system being one that fails in a safe manner, i.e., failure without introducing any additional risk.  In addition to this design vitality, it was necessary to introduce a concept of functional vitality to prove that PTC was and remains not vital. That is, a functionally vital entity is one that generates the movement authorities for trains, thereby providing for the integrity of train movements. For signal engineers the two concepts are inseparable, and in their viewpoint, anything associated with traffic control must by vital. Such fatuous rationalization can be quite unfortunate for the deployment of advancing technologies in railroads, including PTC. Two current examples here are ITC’s efforts in designing the wireless and positioning platforms for PTC that are way beyond what is required for a non-vital system, if even a vital one.

In anticipation of such design tangents by railroad technicians ( as demonstrated in the past by UP with it Precision Train Control project that died from overdesign), I introduced the functionally vital perspective a decade ago to demonstrate that overlay PTC is not vital and therefore not subject to the design and regulatory complexities associated with vital systems. Stated otherwise, PTC’s ability to enhance the safety of rail operations is substantially less critical than that of the traffic control systems that provide for the integrity of train movements. PTC only addresses human errors whereas traffic control systems are absolute.

Being the architect of the first overlay PTC system, I was continuously challenged during the early years by labor, FRA, suppliers, and even my counterparts on other railroads, to explain why PTC is not vital. The forum for these discussions was primarily that of the Rail Safety Advisory Committee (RSAC) for PTC that was charged with defining the core objectives of PTC. Understandably, RSAC-PTC was primarily manned by signal engineers who live and breathe vitality with their natural inclination being that everything is vital. Again, for them PTC had to be vital, I assume, because it addresses safety, and it is related to vital traffic control systems. At the same time, signal engineers when asked during the courses I teach on PTC and railroad operations “What is vital in dark territory?”, will respond that there is nothing vital since there is no wayside equipment. The solution for addressing both of these ill-structured mind-sets of signal engineers as to PTC and dark territory was to provide the functional definition of vitality that really goes to the core of running a safe railroad, i.e., the generation of authorities.

In parallel with the functional vitality effort was the extraordinary task of convincing the masses that PTC did not deliver those business benefits that continue to be so widely and wildly proclaimed by FRA and suppliers as to increasing traffic density and the efficiency of the key operating assets, e.g., crews, locomotives, and even maintenance crews. I quote the FRA’s website “In addition to providing a greater level of safety and security, PTC systems also enable a railroad to run scheduled operations and provide improved running time, greater running time reliability, higher asset utilization, and greater track capacity.” Here is the simple, and one would think very obvious, logic as to why overlay PTC can’t provide such business benefits. To increase traffic density means that the generation of movement authorities need to be done more efficiently … and since PTC does not generate movement authorities (nor deliver them as the FRA website proclaims – that is the purpose of digital authorities – not PTC), then it cannot provide those benefits.  Actually, if not properly designed, PTC can actually decrease both the traffic density and safety by making unnecessary enforcements. What the FRA and others who flaunt PTC business benefits refuse to understand is that it is the wireless data path required by PTC that also permits train tracking status data to be delivered to back office management systems.  As demonstrated by NS and BNSF at least, a railroad doesn’t need PTC to obtain the stated business benefits; a railroad only needs a wireless data platform, whether it be cellular, satellite, and/or private. In any event, the bottom line remains, i.e., PTC is not vital in any sense.

OK, at this point you may be thinking about VPTC (where V means vital) which is one title given to the PTC systems being pursued by the freight and commuter railroads. Clearly such a title suggests that PTC is vital, but it isn’t. VPTC means that the platforms upon which those PTC systems are deployed are design vital so as to reduce the failure of the PTC system, but PTC is still not functionally vital. The purpose of VPTC is to provide a pragmatic economical solution to regulatory issues that requires a restricted speed for a train should its PTC platform fail. In heavy density corridors, the application of restricted speed could result in significant business costs.

With the distinction between design and functional vitality now established above, I introduce a new vitality phrase: “Vital Employee”. Simply stated, a vital employee is one that generates a movement authority. For U.S. railroads, the primary example is the Employee-In-Charge (EIC) that provides the authority to a train to move through a work zone, a work zone that is encapsulated (nested) within an authority generated by a traffic control system. Handling the enforcement of the nested EIC authority was a major design issue that I had to provide for the first overlay PTC system … and is now used by the PTC systems being deployed by the freight railroads.  Again this was done in a non-vital way by not affecting the underlying Method of Operations, thereby avoiding regulatory complexities.

The vital employee perspective has proven to be particularly challenging in my assignment as Project Leader for a consulting effort in Egypt to advance both the safety and efficiency of the majority of the Egyptian National Railways (ENR) operations that use token block and TYER, a.k.a. British Absolute Block, traffic control systems. In the case of ENR, their operations have mechanical interlockings that are handled by operators independent of the central movement office. Instead of a centralized dispatcher, ENR uses block/interlocking operators to generate block-by-block authorities thereby compromising the efficiency and safety of train movements compared to that which railroads around the world achieve with dark and signaled operations. For this engagement, a “virtual” CTC (V-CTC) system is being designed that will provide for multiple block authorities subjected to nested, manual interlocking authorities. This solution provides for enforcement for the authorities generated by both V-CTC as well as the interlocking operator.

As a closing point, I wish to remind all that the Book of Rules provides the underlying threshold of vitality for all rail systems. In my 40+ years in the industry, I find that too many tend to ignore this point – just as signal engineers tend to ignore dark territory.

The elixir of fatuous rationalization being served up by PTC-220,LLC to gain more spectrum in the name of PTC has been poisoning the efforts of both freight and passenger operations to cost-effectively meet the mandated implementation of PTC before 2016.

Point 1: In May 20011, the Federal Communications Commission (FCC) of the U.S. released WT Docket No 11-7, with Public Notice, regarding the “Spectrum Needs for the Implementation of the PTC Provisions of the Rail Safety Improvement Act of 2008”. Subsequently, in addition to my written response, a number of submissions were made by various parties, most notably several passenger operations and PTC-220, LLC (the entity owned by BNSF, CSX, NS, and UP that owns and manages the 220 MHz spectrum to be used for the implementation of PTC).  The FCC’s Docket was the result of the request by PTC-220 to obtain additional spectrum in the same band reportedly to service both the freight and passenger rail requirements of the PTC mandate.

Point 2: At the end of 2010, the Federal Transit Authority (FTA) released several RFQ’s for studies to be performed relative to PTC and CBTC. The primary study was to evaluate the issues associated with implementing PTC on commuter and regional rail systems. As I will be explaining in a posting I will be making shortly, this effort by the FTA is a very pathetic example of how a Federal agency can spend a fair amount of money and achieve nearly nothing of interest to the intended recipients. The proposal was poorly written as to both objectives and understanding of the subject,  along with a process for evaluating and awarding the contract that was clearly inappropriate and unfair. (Yes! My team’s proposal was not selected. But, I will explain the madness of the process in the forthcoming posting). The point for now is that in preparing the proposal, my team discussed the wireless issues with a number of passenger operators and gained some understanding in a very short period of time as to the concerns that they have as to the use of 220 for PTC.

To be addressed in greater detail in the forthcoming issue of my quarterly journal, Full Spectrum, titled Wireless Gone Awry, I will highlight below a number of points as well as statements  that PTC-220 made in their submission to the FCC’s Public Hearing, that are critical to understand in consideration of providing more 220 to PTC-220.

• First of all, I am not saying that PTC-220 is incorrect in requesting more spectrum if they really need it.  However, by their own admission, they really don’t know what they need in that they have not done any credible data modeling relative to PTC. They are spectrum hungry and may even be looking at this spectrum as a “for profit” operation for dealing with the passenger operators.

• In their submission, PTC-220 likened PTC to advanced traffic control / management systems and the need for complex wireless networks to service the latter. I find such a comparison either to be shamelessly naïve or quite devious.

• The passenger operators have been led to believe by PTC-220, reportedly, that they must obtain 220 specifically for their own property to be compatible with the freight railroads. Hence, from some of the submissions by passenger operations, it appears that they were pressured, or unfairly influenced, to support PTC-220’s position. The requirement to use 220 only is clearly incorrect and could be very costly for those operators that will be extremely pressed to find the public funds to implement PTC.

• PTC-220 states that they had engaged TTCI (which is operated by the AAR and hardly free of conflict of interest), to perform data modeling nearly 6 months prior to the submission, and yet there were no results that they could include in the submission. Really? I have team members that could handle that analysis quite quickly.

• The onboard PTC platform, a.k.a. TMC, incorporates a Mobile Access Router (MAR) that supports the use of alternative wireless paths, including 220, WiFi, and cellular.

• The rail industry is poorly utilizing a fair amount of spectrum, including conventional 160 MHz instead of trunked operation, 44 MHz now owned by PTC-220 and which was the choice of BNSF for PTC, and 900 MHz that was given to the railroads 2 decades ago to do ATCS.  ATCS was never implemented and the railroads have used the spectrum for business purposes instead of giving the spectrum back (BTW, using 900 for code line is a business decision and not a safety one).

In summary as to the above, PTC-220 should be required to define their requirements clearly and with the proper level of legitimate data analysis done by an independent entity.  As a point of further consideration, there is also a need to break down that requirement as to the type of traffic control involved as well as traffic density.  For example, deploying PTC across dark territory has a substantially different wireless requirement than deploying PTC across signaled territory with either medium or heavy traffic volumes. In short, there is a need to identify various PTC “wireless corridors” as to throughput and coverage requirements, and to model them individually.

In addition to my initial submission, I made a subsequent submission commenting on the falsehoods and misrepresentation that were made in some of the other submissions, most notably PTC-220.  Additionally, 2 weeks ago I made a presentation to the FCC to provide them with a modicum of rail domain knowledge that would assist them in understanding the true requirements of wireless for PTC.

Both of my submissions as well as the presentation to the FCC were on a fee basis for a client, Skybridge Foundation.  SBF placed no restrictions on what I wrote / presented, and did not interfere with the objectivity of my material. Both of those submissions and a PDF of my presentation are of public record and can be obtained via the FCC’s website or by emailing a request to me at comarch@aol.com. Additionally, those individuals that seek to further understand wireless corridors are encouraged to contact me on that topic as well.