Archive for the ‘Positive Train Control (PTC)’ Category

Don’t Drink the Kool Aid

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.

Risqué Assessment – PTC

In designing and implementing safety systems, risk assessments are made to identify and mitigate unsafe situations so as to ensure a certain level of safety is achieved (a level of risk is not exceeded). For traditional railroad signaling systems, each supplier in the North America has developed its individual qualitative approach referred to as V & V (validation & verification) for evaluating their respective systems. That is, the V&V process is meant to validate that the right thing is being done, and then verify that it was done correctly. For electrical / mechanical components and systems, such an approach makes sense.  But, when a most complex and highly unpredictable variable such as the human is introduced as part of the system, then the V&V process is not sufficient; the risk assessment process becomes much more risqué.

 

The design and implementation of Positive Train Control (PTC) has taken the traditional signaling suppliers outside of their comfort zone for risk assessment. With PTC designed to prevent the failures of humans to operate their trains within the limits of the active movement authorities, means that a qualification process has to be complimented with a quantitative process as well.  But, if humans are so unpredictable as to both the types and occurrence of errors that can be made, then how can even a quantification process be established?  Actually, the process is quite straightforward. It’s a matter of simulating the environment to be evaluated over an extensive period of time and/or iterations, and to use historical data as to the type and degree of threats that may occur.  The reason for the extensive time period and/or iterations is to provide for the randomness of events so as to ensure a statistically sound analysis.

 

Risk relative to evaluating PTC was defined by the Railroad Safety Advisory Committee (RSAC) to be the severity multiplied by the likelihood of the train being coincident in time and space with an unsafe condition. RSAC was composed of a mixture of regulators, rail management, labor, and supplier personnel, and one of their responsibilities was to evaluate a risk assessment process that was being specifically designed for PTC. Referred to as the Axiomatic Safety Critical Assessment Program (ASCAP), this tool was to be a very straightforward simulation program that could have readily provided a more than adequate analysis of PTC reducing risk – which everyone already intuitively understood anyhow.  I mean, if PTC eliminates the most dangerous source of train accidents, again human errors, then it’s a winner (assuming it doesn’t introduce any significant risk – and it doesn’t). Of course, the regulators can’t accept intuitive analysis. They need the mathematical proof, and hence ASCAP.

 

You noticed that I said that ASCAP could have been a great tool. But, it failed to be delivered due to extremely poor management of resources.  I am not referring to ASCAP’s developers, but rather to involvement by the RSAC participants that continuously battered the developers with “insights” and additional requirements of how to make the ASCAP simulate a railroad to the greatest exactness possible. What they failed to understand was that the error associated with simulating human-based events was much greater than correcting for the acceleration of a sample train from a railroad yard, for example.The bottom line here is that the RSAC advisors who were lacking in sound mathematical principles, including Operations Research (OR), and simple pragmatic analytical tools turned a straightforward simulation tool into an unachievable, complex quagmire of code. What was missing was a manager experienced in OR with railroad domain knowledge that could have separated the RSAC’s advisors appropriate advice from the fatuous comments.

 

ASCAP failed due to poor management and not due to its concepts or principles. Simulation is a quantification risk assessment approach that eliminates the risqué-ness in risk assessment processes involving humans.

PTC Interchangeability

The concept of interoperability is relatively new to the rail industry as railroads link their operations within and across country boundaries. In fact, the lack of interoperability between various European countries in the past century was a purposeful defense mechanism against invading armies that could use railways for rapid, massive troop and weapon movements. Now, interoperbility has been the driving force for deploying ETCS across Europe for the past decade or so.  And in the U.S., interoperability is currently the most costly and exasperating aspect of delivering Positive Train Control to meet the U.S. government’s mandate of it being implemented across most of the country’s trackage before 2016. Specifically as to PTC, the Interoperable Train Control (ITC) committees that are primarily manned by CSX, NS, UP, & BNSF have been working intensely to address issues such as system architecture, on-board functionality, message set, communication network, data management, and an all-encompassing method of operation.  However, what has not been addressed is dealing with the set of parameters that provide for interchangeability, i.e., the ability to exchange a component or entire on-board PTC unit when not on the owning railroad’s property. Actually, this can even be an issue within an individual railroad as is currently the case with one Class I railroad that has an inventory of on-board units with 8 different model #s.  Clearly, as the railroads begin to implement PTC, the challenges of interchangeability, and hence the costs, if not handled properly very soon, are going to grow exponentially.

 

The parameters of interchangeability include the physical dimensions, electrical interfaces, as well as ensuring software and hardware compatibility at both the component and platform level.  Perhaps some folks think that the issue of PTC interchangeability will not be that significant given that Wabtec is the only supplier of the on-board Train Management Computer (TMC).  However, that point is quickly dismissed based upon a number of other considerations, including

  • Other suppliers are looking to compete with Wabtec as to the TMC;
  • Again, one Class I railroad already has 8 different model #’s for the Wabtec TMC;
  • Railroads will want to ensure that a foreign unit is properly configured as to software and hardware;
  • Railroads will want assurance as to a long-term supply of components and units;
  • There is a vast number of individual locomotive configurations;
  • Proprietary backplanes work against the railroads’ best interests in most cost-effectively deploying on-board systems;
  • Lastly, given that industry politics seemingly are always at play, there are bound to be conflicts within the “standards” that are being provided by ITC. BTW, what about the one most critical standard that is not being provided by ITC.  I refer to the TMC source code.  More on this latter.

 

Volume 59 of my quarterly publication, Full Spectrum, that will be released around October 1st this year, will be addressing interchangeability in substantial detail as to the challenges and the opportunities.

Risk Credits

With a cost / benefit ratio of 20/1, there is no incentive for railroads to implement PTC on their own. As discussed in a number of postings on this blog, there are no business benefits provided by PTC directly, in that PTC has nothing to do with the efficiency of traffic management. Some folks are still confused on this point in that they refuse to accept the fact that it is the wireless data system that PTC requires which can deliver data required for advanced resource management, as in “Where is my train and how fast is it moving”.  PTC is just one user of the wireless network.  This point has been well demonstrated by Norfolk Southern, that by means of a simple wireless data system, is currently implementing proactive traffic management before and without PTC. However, there is, or rather there was before the mandate, a possibility of railroads to achieve indirect business benefits from the deployment of PTC.

Prior to the mandate, there had been some possible movement in the FRA to consider the overall risk of a track segment as to whether or not a combination of changes could be made that may have a NET decrease in risk even though one or more of the changes may actually increase risk, e.g., removing signals that were no longer required … or … making the transition to one-man crews. HOWEVER, by implementing PTC in concert with doing either or both of those would result in a net decrease in risk given the safety value of PTC that prevents train crew errors. Therefore, prior to the mandate, implementing PTC provided the railroads with the possibility to implement other projects of significant business value that may not have been accepted by the FRA otherwise. With the mandate, the railroads no longer have that bartering position … or maybe they do.

Jumping to the present, and again thinking about the PTC mandate and the phenomenal cost for which the railroads so far are near-totally responsible, then perhaps a concept can be brought to the table to ease the financial blow of the knee-jerk PTC mandate by Congress due to the Metrolink-UP accident in September 2008. I am referring to the railroads being given Risk Credits relative to their degree of PTC implementation. That is, for every segment of PTC installed, then the railroads get a certain amount of risk credits to use for the pursuit of other activities that may be deemed to increase risk, but provide substantial business benefits, again one-man crews, removing signals, whatever. Such credits, like pollution credits, may even be tradable between railroads by those who don’t need the credits and those that could use them. Hmmmmmm! Great Idea, me thinks. Spread the word.

PTC Spring Sale – 80% off

ACT NOW! Don’t wait any longer. This is your last chance opportunity to get PTC before the technicians take your railroad to the edge of the PTC investment abyss and give you the financially-fatal push.

"PTC is on Sale! Act now to capture these amazing prices!"

The PTC approach being pursued by the Class Is via the Interoperable PTC Committee (ITC) manned by CSX, UP, BNSF, and NS, is tremendously overdesigned as to functionality, technology, and infrastructure. The net of this is a 5-fold increase in investment (my estimate). However, it still is not too late to scream “ I’m not going to take anymore!” and design your PTC implementation in a fashion to avoid most of the unnecessary stuff.  Here’s the story in 3 simple bullets.

  • As was addressed in an earlier posting on this blog, YOY WIUs, it is clear that the recent estimate of 50,000 wayside interface units (WIUs) that provide wireless data paths from wayside infrastructure components to the PTC client on the locomotive and the PTC server in the office is off by a factor of 60%, minimum. As explained in the earlier posting, WIU’s are not required for Intermediary Signals (ISs) and control points. The former is not a required function of the PTC mandate (in fact, doing so may actually increase risk), and the latter can be done via the already installed code line.
  • I find no evidence of anyone doing an actual data throughput analysis for PTC. From my personal experience, having been the architect for the first overlay PTC system that provided the foundation for the Class I pursuits, there is very little data throughput required (save track data base downloads that can be handled via WiFi in the yard).  And yet, the ultimate wireless data system is being developed by ITC.  It is clear that PTC has nothing to do with this development in actuality. The railroad technicians want the network (they love the challenge), and perhaps someday they will need it (there currently is little to no strategy as to how the network could be used), and they are using PTC as the excuse.
  • Complimentary to the above point, the railroads actually don’t even need the 220 MHz network.  What they failed to do several years ago was to use digital trunked radio technology to outfit the current analog 160 MHz infrastructure to meet the FCC’s narrowbanding requirement.  They are already switching that network from analog to digital, but they have chosen to use conventional radio instead of trunked. Granted it would have been a complicated transition, but $1 billion cheaper by avoiding the 220 MHz infrastructure. Again, the railroads’ technicians took it upon themselves to address challenges without proper executive management understanding and oversight which would have required proper business case analyses.

 

Last Chance! Positive Train Control at great prices!

The bottom line on the railroads’ bottom lines is that the cost of PTC implementation could be reduced from the estimate $10 Billion to a mere $2 billion, give or take a $1 billion. But to take advantage of this Spring reduction, someone has to stand up now and say scrap the 220 MHz, install digital trunk 160 MHz, and ignore 60% of those WIU’s.  Of course that won’t happen. What a shame.

YOY WIUs ?

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.

PTC: Caveat Emptor

Prior to the PTC mandate in November 2008, the misunderstandings about PTC were starting to narrow down to just a few issues. Fortunately, the fact that PTC is not vital had fairly well stabilized across the industry. But there remained the most persistent, fatuous belief that PTC delivered business value, followed closely by the corollary that such business benefits would be achieved after the deployment of PTC. Actually, the second point is pathetically true somewhat because there is a tremendous lack of understanding, proper management direction, and executive bonus incentives as to what railroads can do NOW without PTC with the use of the simplest of wireless data infrastructures, whether it be owned and/or commercial (cellular / satellite). As proof of this point, as noted in previous postings on this blog (Really! You Gotta Let It Go), NS is leading the charge in the industry, followed by BNSF in actually achieving such business benefits now without PTC.

Since the mandate of PTC, a whole new plateau of misunderstandings and misrepresentations regarding PTC has been reached.  Some of these are perhaps innocent mistakes, but others are clearly the result of  misleading, if not fraudulent, activities by suppliers and consulting firms alike. This is not a point of concern for the Class Is in that they know what PTC is and what it will take. Afterall, they have taken the charge to define PTC themselves with little to no interest in help from the supplier community. My concern, rather, is for the commuters and regional rail transit systems that are looking for a path through the PTC implementation mine field armed with regulations, budget constraints, the challenge of public financing, and long-established relationships with selected suppliers who have no experience in PTC.

PTC, as to be deployed in the U.S, is only one form of enforcement systems that are meant to ensure that movement authorities are not violated as to some combination of time, distance, and speed. They are deployed to prevent train crew errors (whereas traffic control systems prevent dispatcher errors). Examples of enforcement systems in addition to PTC include, Advanced Civil Speed Enforcement System (ACSES) as used by Amtrak on the NE Corridor,  various forms of Automatic Train Protection (ATP) as deployed across Europe and elsewhere (e.g., ETCS, LZB ), and various forms of Automatic Train Control (ATC) over the years. The critical point here is that while all of these systems are enforcement systems, they can differ substantially as to the technologies and challenges involved in designing, implementing and maintaining. Consider the following differences between PTC and ACSES.

APPLICATION

ACSES is an overlay on cab signaling for the NE corridor. Contrarily, PTC is an overlay system for traffic control systems other than cab signaling, including both dark (non-signaled) and signaled operations.

FUNCTIONALITY

ACSES, as originally designed, does not provide for 1 of the 4 core objectives of PTC as mandated. That is, it doesn’t provide protection for work gangs in the NEC in that those workers do not have authorities, per se’, to be there. The maintainers use watchmen to inform them of approaching trains. (BTW, I have a patent pending for a slick solution to this problem. But getting funding, yet alone purchase orders, has been impossible.)  ACSESS II will provide for such protection I understand. Additionally, neither PTC nor ACSES have addressed the likelihood that additional capabilities will be required by commuter and regional rail operators – more on this in a forthcoming posting. Lastly, the critical aspects of the braking algorithm for freight trains, compared to the relative simplicity of passenger trains, will be an on-going challenge as to the reliability and acceptance of PTC.

ARCHITECTURE

PTC is dependent upon a ubiquitous wireless data network with a different set of wayside / in-track components than that of ACSES. Also, PTC requires a central-office server that links with the dispatching and signaling platforms through various means. PTC requires its own on-board platform that will most likely be integrated at some point with other on-board systems for advanced train / locomotive management.

MAINTENANCE

Given the substantial difference in architecture and functionality between ACSES and PTC, it is not difficult to understand that the maintenance issues are substantially different.

TRAINING

Given the substantial difference in architecture and functionality between ACSES and PTC, it is not difficult to understand that the training issues are substantially different.

INSTALLATION

Given the substantial difference in architecture and functionality between ACSES and PTC, it is not difficult to understand that the installation issues are substantially different.

MANAGEMENT

I know nothing of the type of management overview that is used by Amtrak’s operations management regarding attempted violations, etc. of ACSES operations, but providing the same for PTC will be more complex . . . that is once the railroads recognize that this is a requirement.

Considering the above, I come back to the point of misunderstanding / misrepresentation by suppliers and consultants following the mandate of PTC.  First, I provide the They’re Just Stupid perspective followed by the They’re Lying perspective of what is happening in North America to the likely disadvantage of both the commuter / regional rail operators as well as the suppliers / consultants with legitimate PTC credentials.

They’re Just Stupid

Yes! ACSES / ATP / ATC / ETCS, etc. do provide for various combinations of PTC functionality as mandated. However, having designed, implemented, and/or consulted on ACSES, ATP, ATC, ETCS, etc. does not qualify a supplier or consultant in any fashion to say that they have PTC experience given the above comparison between PTC and ACSES.  But yet, consulting firms and suppliers that had not been involved with PTC development in any fashion prior to the mandate have since expanded their credentials and list of brochures presenting themselves as PTC experienced.  To do so is an act of stupidity and/or blind arrogance on their part. BTW, CBTC credentials are not appropriate either.

They’re Lying

Yes! ACSES / ATP / ATC / ETCS,etc. do provide for various combinations of PTC functionality as mandated. However, having designed, implemented, and/or consulted on ACSES, ATP, ATC, ETCS, etc. does not qualify a supplier or consultant in any fashion to say that they have PTC experience given the above comparison between PTC and ACSES. But yet, consulting firms and suppliers that had not been involved with PTC development in any fashion prior to the mandate are scamming clients that they have such expertise with a hope and a prayer that they will get the contracts and learn on the job or hire the necessary truly qualified talent. BTW, CBTC credentials are not appropriate either.

In closing, a RFP was issued by the FTA to study the issues of deploying PTC across commuter and regional rail operators. That RFP has now closed as to the submission of proposals. It will be interesting to see what team is awarded that contract as to their actual vs. promoted credentials; definitely a forthcoming posting.

Traffic Movement: Safety vs. Management

Recently on this blog I posted the article Dangerous Railroading in which I identified 4 primary areas that a railroad needs to address for safe operations, i.e., 1. choice of safety systems deployed, 2. critical infrastructure maintenance practices, 3,  personal / personnel accountability, and 4. theft of critical infrastructure. The primary point of that posting was that a railroad’s slack in any one of the four areas would result in the safety of its operations being readily compromised. In that posting I addressed each of the areas in a cursory fashion with the commitment that I would address each in greater detail in subsequent postings. As such, this posting addresses safety systems with additional discussion as to Traffic Management.

There are two levels of safety systems to consider for the movement of trains from both the dispatching and train crew’s perspectives, i.e.. traffic control and enforcement, respectively.

TRAFFIC CONTROL

Simply stated, traffic control is the functional vitality of the railroad that ensures the integrity of train movement authorities. It does that by employing vital logic / hardware / systems that generate the movement authorities in a fashion that fails safely, i.e, unsafe authorities are not delivered. I am purposely pointing out the difference between functional vitality and logic / hardware / system vitality here in that the distinction is often overlooked, if even recognized by many railroaders. Logic / hardware / system vitality is that which signal engineers solely identify with. Too often, signal engineers mistakenly believe that signals are installed for safety purposes.  Of course, signals provide for safety, but they are installed for traffic throughput in that it is possible to operate a railroad safely without signals, e.g., 50% of the trackage in the US is non-signaled traffic control. … as is ETCS level 3, … as is the most primitive token block system.  Signal engineers don’t identify with functional vitality, a point which is quickly proven by asking ANY signal who has not taken my Railroad Immersion Course (brochure is available on the blog),  “What’s vital in non-signaled (dark) operations?”  Their response will always be “Nothing!” since there is no hardware installed along the wayside.  They are so, so wrong from a functional standpoint.  Vital functionality is what a railroad requires, and the vital logic / hardware of signaling systems is only one way to achieve that. (Further discussion on this point, as well as the answer as to what is vital in dark territory, is provided in a previous posting on this blog in the Teddy Bears category: There’s Nothing Vital in Dark Territory).

Arguably, the most disturbing issue currently about traffic control is the willingness by too many railroads to blindly accept both the traditional and advanced traffic control systems that are offered to them by traditional suppliers pushing what they have, versus what those railroads really require. I am not referring to high speed, high capacity operations as in Europe’s passenger operations where interoperability and traffic density are the driving factors. Rather, I am referring to all of those railroads across the other 90% of the globe that are struggling to develop a core transportation infrastructure to expand their country’s economy. How dare traditional signaling companies and consulting firms provide only products that feed the seller’s bottom line instead of pragmatic cost-effective solutions that service a railroad’s bottom line. These suppliers are providing, as well as the consultants are promoting, products instead of true solutions. (Again, I refer you to another posting on this blog: In the Light of Dark in the Railroad Business category.)

ENFORCEMENT

Unlike traffic control which is meant to prevent dispatching errors, enforcement is meant to prevent train crew errors. Simply stated, enforcement systems monitor the status of a train’s movement relative to its authorites. Should the system determine that the train is in jeopardy of violating an authority as to some combination of speed, distance, and time, then the enforcement system takes some combination of actions such as warnings to the crew, slowing the train, or bringing the train to a complete stop. As such, enforcement functionality can be integrated with advanced traffic control systems such as ETCS in Europe, or it can provided as an overlay system, as is the case with PTC in North America. In any event, enforcement systems are not vital as to functionality or logic / hardware (as discussed above) in that they do not generate authorities. Should, the enforcement system fail in some fashion, then the train is no less safe than it was without the enforcement system . . . Well! Almost always. One possible exception is that of an improperly designed enforcement system that makes an emergency brake application that for some reason results in a derailment.

Various types of enforcement systems have been in use in passenger operations for decades. However, for freight operations across most of the globe, enforcement systems have been extremely limited in their deployment and functionality compared to what is now available with PTC and the European flavor of Automatic Train Protection (ATP) as well as enforcement functionality incorporated in ETCS for Europe’s High Speed Passenger operations. What is unique about PTC relative to ATP / ETCS, is that no significant additional wayside infrastructure (other than a commercial or private wireless data network) is required for a very basic approach in signaled territory, with only switch monitors required in non-signaled operations.   NOTE: For the hardcore PTC followers who feel tempted to correct me regarding WIU’s being required in signaled territory, I request that you first think about why WIU’s are needed if interim signals are not enforced.

TRAFFIC MANAGEMENT

Neither traffic control nor enforcement is traffic management.  Traffic management deals with the efficient generation of authorities, but not the generation itself. It is designed to meet the operating directives (business value) of the railroad in managing the key resources, and as such has nothing to do with the safety of the railroad. Until recently, traffic management has been dependent upon the analytical and the rationalization of a railroad’s management team as to what was most important, i.e, moving high priority trains regardless of the cost associated with other traffic. It has only been within the last decade that advanced traffic management has introduced the mathematical tools that can displace the limited human-mentality of dispatchers to deal with the most simplistic prioritization of track time only, yet alone consider fuel utilization, crew availability, balance of locomotive distribution, and the constraints of track maintenance. I should point out that I am referring primarily to non-scheduled operations that are prevalent in North America.  I am not referring to high speed passenger operations that are highly scheduled. (One more time, I offer two other postings on this blog relative to traffic management, both from the Teddy Bear category: 1) CAD Delivers Traffic Management, and 2) Train Dispatching is too Difficult for that Math Stuff.

Hey! Watch this.

Last week there was the story on National Public Radio about the young fellow who challenged his friends to the old chestnut about not licking a stop sign’s metal pole in freezing weather.  The story went on to state how the boy was standing on the tips of his toes for 15 minutes until the firemen were able to release his tongue.

Hey!  Watch this! (H!WT)  Ah yes! The last spoken (and printable) words of impetuous young males who fatuously attempt to perform ridiculous if not impossible acts. Whether it is a passion for the limelight, a flash of perceived brilliance, or a display of bravado, whatever, such acts of pure stupidity can result in serious degradation of the soul, if not destruction of the body. Fortunately, somewhere in our post-teen years we mature and we take on a sense of self-preservation for the benefit of ourselves and our family and learn to not yield to such temptations. We become responsible and reflective and make clear cut, well-justified analyses of the matters at hand before we take action.  And, should we find that we are in error with the actions we took, then we adjust our reasoning by adding a new variable to the equation, or perhaps adjusting the coefficients, and we are then just that more effective should the situation occur in the future. Yes! Life is good … and all makes sense . . .  eventually.      Well! Maybe not always.

Unfortunately, stuff happens that is forced upon us, instead of being of our choice, and the manner in which we respond is more often than not, I believe, directly related to the level of the chaos of the situation. That is, the more chaotic / disturbing the situation, the more ill-structured, the more irresponsible our reaction may be. In such situations, the impulsive H!WT response still occurs but in a reactive fashion versus the proactive fashion of our youth.  Now, if you mix this reactive response with politics and a high level of public exposure, then you have the underlying explanation of why Positive Train Control (PTC) has been mandated in the U.S. This is a situation where a proactive H!WT begot a passive H!WT. First, some statistics.

According to the U.S.’s General Accounting Office (GOA) report of December, 2010 regarding Rail Safety, Human errors have been the primary cause of rail accidents (34%) for the past decade relative to 5 other common causes.  Track issues are a close second (32%), with the remaining 1/3 due to crossings, equipments, signals (only 2%), and the ever present other. As to the movement of trains, the two primary human factors are dispatchers and train crews. While traffic control systems are used to prevent dispatcher errors, there has been very little provided prior to PTC to prevent crew errors across North America’s freight railroads. Back to H!WT.

The train accident at Chatsworth, CA on September 12, 2008 between Metrolink and UP in which 25 people died was a proactive H!WT on the part of the Metrolink driver that thought he could text message while operating his train. In less than 5 weeks Congress did their H!WT knee-jerk reaction, as in we have to stop the carnage due to train crew errors, by passing the Rail Safety Improvement Act of 2008. This act mandates PTC before 2016 across most of the nation’s trackage. Clearly, there was no cost vs. value justification, even though it was already known by the FRA and the railroads from the RSAC-PTC process that PTC was not cost justified on safety benefits. From Congress’s standpoint, something just had to be done, regardless of the cost. And, about those costs, the price tag is horrific. Specifically, as estimated by the FRA, the cost of meeting the mandate ranges from $9. Billion to $13.1 billion. As to the benefits, the safety value of PTC over 20 years is estimated to range between $440 million to $674 million. That is a 20-to-1 cost/value ratio that is way beyond any rational business decision that would be made in the private sector. Undoubtedly, to their defense, Congress was being fed misleading statements of PTC delivering business benefits (see my previous posting Really! You Gotta Let it Go), Additionally, NTSB was stoking the PTC fire with its long standing proclamation that PTC was on its Most Wanted list. Rational financial thinking was out of the window, and self-preserving politics were in play for those on the Hill.

Although the Chatsworth tragedy was directly responsible for the mandating of PTC, it was not the first to tempt such fate. In 1996, a MARC commuter collided with Amtrak in Silver Springs, MD resulting in 11 deaths.    Given that its engineer was the driver of the MARC commuter and was at fault, CSX decided to pursue the development of the yet-to-be defined overlay PTC concept. CSX did this in anticipation of a H!WT by Congress, especially considering that the accident took place in Congress’s backyard. This is where I entered the picture in that I was hired by CSX at that time to deliver what was then referred to as  Positive Train Separation (PTS).  The resulting system, known as Communications Based Train Management (CBTM), provided the underlying architecture and functionality of the current PTC pursuits by the freight railroads to meet the mandate.

So! Why did Congress not do a H!WT after the Silver Springs’ accident? The answer, I believe, is two-fold. First, UP was in the process of abandoning an extremely expensive and undeliverable Precision Train Control (PTC™) system. Although the same acronym as Positive Train Control, there is a key difference between PTC™ and PTC.  That is, PTC™ was meant to be both a traffic control (moving block) and enforcement system, whereas PTC is only the latter. Undoubtedly, UP and its Class I siblings had to be all over the Hill at that time to prevent a mandate of such a technology. The second reason is that CSX took the initiative to “develop something that is effective, but cheap” as were my marching orders, thereby lessening of the pressure on Congress to H!WT .

There was also a second accident that could have resulted in the mandate of PTC. In January 2005, a NS train proceeded through a misaligned switch and collided with a standing NS train in Graniteville, SC. This accident involved hazardous material and resulted in 9 deaths and the evacuation of 5400 residents within a mile of accident for 2 weeks. While it didn’t result in a mandate, the accident did result in a fourth core objective of PTC, i.e., prevent movement through a misaligned switch, in addition to the original 3 core objectives defined in the RSAC-PTC process nearly a decade earlier: 1. prevent train-to-train accidents (PTS), 2. prevent over-speeding, and 3. prevent trains from endangering on-track workers.

PTC is definitely not justified on safety benefits, and it doesn’t deliver business benefits. At first that seems bad for PTC deployment outside of the U.S. However, that is really not true in that there are so many railroads, whether private or state owned, that don’t incorporate safety as part of the mantra of operations. There are so many railroads, whether private or state owned, that are being forced by traditional suppliers with traditional solutions to deploy traffic control and enforcement systems that are totally unjustified for their level of operations.  In these environments, the consideration of PTC in concert with non-signaled traffic control, a.k.a. dark territory, would present a solid, cost-effective solution for both safe and efficient operations – that is if they were willing to listen. Now, as to North America, PTC is really not a loser financially as well, that is if there would be a strategic technology plan associated with its implementation that permits the necessary wireless data platform to be used for business benefits as well. Unfortunately, however, most of the Class I’s have not gained such a perspective. This is due to the fact that there are so few technical staffs of the railroads, and even less executive management teams of railroads and suppliers alike, that are willing to do a proactive H!WT as to syncing a strategic technology plan with a strategic operations plan. Yes! I am referring to Strategic Railroading.

In closing, I will be the Chairman of the PTC Congress in Miami, FL on February 22. If you and/or your colleagues are attending that event, then I would appreciate the opportunity to meet you.

Really! You Gotta Let It Go

Norfolk Southern Logo

Norfolk Southern is a Class I Railroad in North America

In a recent issue of a rail industry periodical there was an informative article on Norlfolk Southern’s use of advancing technologies to advance their operations. What was most interesting to me was the very brief description of GE’s RailEdge Movement Planner that is being rolled out across NS’s network in concert with their next generation CAD platform.  This 1-paragraph discussion validated the Proactive Traffic Management concept that I introduced 5-6 years ago in my quarterly publication, Full Spectrum, as well in Railway Age and more recently in postings on this blog.

The successful deployment of such capability has been a long time coming. Going back a decade, the GE-Harris combo first attempted to implement their moving block, Precision Train Control (PTC™), platform on Union Pacific.  PTC™ (not to be confused with Positive Train Control) was abandoned eventually for 2 primary reasons. First, there was not a cost-effective wireless data solution at the time and second, the Harris side of the operation, driven by Jack Welch’s progressive positioning of technologies , had the “if we can place a man on the moon, then we can run a railroad.” attitude. They truly missed the 80/20 solution – developing solutions that will work … versus the fatuous pursuit of perfection.  It seems that GE and NS have now figured it out, including the evolutionary expansion to include yards, crew operations, and locomotives into RailEdge.  This is great stuff, but this is not the primary purpose of this posting.

In the same issue as the NS article there is a Guest  Comment, PTC – the next great railroad revolution by a gentlemen with impeccable rail credentials.  Here is an individual that has held very responsible positions across all aspects of the industry, i.e. Class I & II railroads, FRA, major supplier, and even education.  But, with all of that said, this fellow just can’t give it up. He can’t give up on associating business benefits with PTC.

Below are two quotes from his commentary:

Business won’t be the same after PTC, if railroads implement it properly, business will be better – for everyone.

The continuous, accurate, real-time train location and speed information from PTC is not available to precision dispatching systems, thus making train meets and passes less efficient

Stop! No more erroneous PTC promotions!

Stop! You gotta let it go. PTC alone does not provide business benefits.

In addition to the above comments, he references several FRA-supported studies that “point to the potential for substantial business benefits (from PTC).”  What he doesn’t state is that he drove several if not all of those studies, and those studies were rightfully dismissed by railroads and independent consultants that could see through the primary folly. That is, PTC requires a wireless data path, as do the primary business benefits to be derived from knowing the position and speed of trains.  However, a railroad doesn’t require PTC to get the wireless data network.   A secondary fundamental point here is that the advancement of traffic management is dependent upon the more efficient generation and delivery of movement authorities. PTC doesn’t do either. PTC only uses the parameters of the movement authorities once they have been generated. You can read more on this subject in my previous post: “PTC Delivers Business Benefits?

What this gentleman doesn’t understand by forcing PTC at the beginning of events to achieve business benefits is that all of the excessive PTC-design activity in the name of operability is actually holding back railroad advancement for most railroads. These railroads have failed to take a business perspective of how to use technologies now, most specifically wireless data.  But, that’s not the case for NS, is it?  They saw the light 2 or so years ago when it was decided to put train position/speed reporting devices on the locomotives to bring in that most simple, but most critical data that could be used by “precision dispatching systems”, to quote the commentator.  And, they did it without PTC.

While I appreciate the commenter’s passion in pressing his perspective that goes back 2 decades, his lack of objectivity is a very costly, if not a financially dangerous perspective for railroads. Really! You gotta let it go.

Follow StratRail on Twitter
Strategic Railroading™
Given recent tech advances there is now an unprecedented opportunity to advance railroad operations and the integration of high speed rail with freight. Real-time traffic management and communication is possible without significant development and deployment costs, but it will take a technology strategy working hand-in-hand with an operational strategy, it will take Strategic Railroading.™
Full Spectrum - Quarterly Journal

Full Spectrum is a quarterly railroading journal authored by Mr. Ron Lindsey. The majority of executives in the US railroad industry, including top members of the FRA and the major railroads, have subscribed to Full Spectrum for the past fifteen years.

Full Spectrum subscriptions are available by contacting Ron via email. If you are concerned with staying abreast of the newest advances in rail technology or operations strategy, it is highly recommended you subscribe in order to maintain your competitive advantage.

Back issues are on sale here.

Purchase Full Spectrum Issues
Your cart is empty
Visit The Shop