Strategic Railroading

Archive for the ‘wireless’ Category

There is unlikely to be anyone significantly involved with the U.S. freight industry that has not been exposed to the phrase railroad interoperability given the Federal mandate of Positive Train Control (PTC), an overlay enforcement system. This mandate, via the Rail Safety Improvement Act of 2008, has consumed extensive capital and human resources of the railroads and selected suppliers to design and implement PTC before 2016 in such a fashion that the movement across railroad borders will be transparent to the on-board PTC system. This transparency of interchange, a.k.a. railroad INTERoperability, is unprecedented in the U.S. as to both technologies and cooperation between the railroads, and only exceeded by the European countries in their development and deployment of ETCS, a traffic control system with integrated enforcement. However, unlike ETCS which has been handled by the supplier community, PTC is primarily an effort of the 4 primary Class I railroads, much to dismay of the commuter railroads that are basically at the mercy of what the Class Is provide (see a previous posting on this blog: A Wag of the Finger).

While providing for PTC interoperability across railroads is an extraordinary effort for which the Class Is deserve tremendous credit for addressing the technology challenges (albeit a tremendous overkill as to wireless – see previous posting: Don’t Drink the Kool Aid), the railroads are failing to an equal or even greater extent to address the functionality issues of this effort that are available to them. That is, the technicians for PTC are doing what they are required to do to address PTC functionality, but the Class Is’ senior management teams are not considering what can be achieved across the industry as to operations and resource management given the wireless network that is to be deployed for PTC. I refer to this industry-wide functionality as Industry INTRAoperability (I/I) as was introduced in the FRA-funded study I performed in 2008: A Demand and Supply Analysis of the Opportunities for Wireless Technologies in Passenger and Freight Rail Operations (www.fra.dot.gov/downloads/Research/ord0802.pdf).

So! Why are railroads not pursuing I/I ? The answer involves two components. First, railroad executives are highly motivated, if not exclusively so, by the executive bonus programs that are provided them. Second, to pursue I/I requires resources that are not generally available in the railroads, i.e., technologists (not technicians) that can envision and develop cost-effective, strategic technology plans in sync with strategic business plans, a.k.a. Strategic Railroading. As to both of these components, I offer a primary example.  If railroads truly wanted to pursue scheduled operations, then to do so would mean that the railroads with which they interchange must be striving for schedule operations as well. That means reliable cooperation within and between roads . . . which means that the executive bonus programs must be so structured  – but they aren’t.  If they were, then perhaps the railroads would provide for the second component, the technologists that could work together just as the technicians from the railroads have been doing for the last several years to pursue railroad interoperability for PTC deployment.

So! How can I/I be pursued given the lack of both appropriate executive bonuses and technologists?  The answer to this question is two-fold: 1. Education and 2. Process.  Both of these points will be addressed in the next two postings to the blog. So! Please check back into this blog during the next several weeks.

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.

In the November 2002 issue of Harvard Business Review (HBR) there was an article titled “The Six IT Decisions Your IT People Shouldn’t Make”. It was a great article about how Operations management for so many companies have abdicated responsibility for IT decisions to IT executives, thereby resulting in a significant loss in the return on their IT investments.  The underlying truth is quite straightforward. That is,  Operations management “failed to recognize that adopting systems posed a business – not just a technological- challenge. Consequently, they didn’t take responsibility for the organizational and business process changes the systems required.”   The result of this lack of involvement was that the CIO, with a technology perspective exclusively, was constraining the advancement of the company’s business processes, and most likely the return on IT investment and, more importantly, the company’s bottom line.

Shift now to railroads and their nearly total dependence on managing mobile and remote resources. In this environment, the strategic IT environment extends to the “mobile node”, the locomotive platform, by incorporating a strategic wireless data perspective in sync with the IT strategy. And, has been so unfortunately demonstrated in the North American railroad industry, it’s the wireless technicians that are constraining the advancement of business processes by their pursuit of non-strategic wireless networks, most recently in the name of PTC.  I refer specifically to the intended deployment of the 220 MHz band in parallel with the 160 MHz band that will be shifting to a digital platform to meet the FCC’s narrow-banding mandate. In line with the HBR article, the railroads’ Operations management have not been involved with the evaluation of how wireless technologies will be deployed. I stress that it is not the technicians’ fault that they have such a free hand, but rather that of the railroads’ upper management that have failed to be involved.

Paraphrasing the key points of the HBR article, below are the 6 decisions that a wireless manager should not make about the deployment of wireless technologies, from both a strategy and execution standpoint.

Strategy

• How much should we spend on wireless?
• Which business processes should receive our wireless dollars?
• Which wireless capabilities need to be company-wide ( and industry-wide)?

Execution

• How good do our wireless services really need to be?
• What security and privacy risks will we accept?
• Whom do we blame if a wireless initiative fails?

Via several following postings to this blog, I will address some of these questions in greater detail.

Ron Lindsey was recently commissioned to write a white paper titled ” Wireless for Railroads”.

The paper addresses the extraordinary opportunities railroads have, both individually and collectively as an industry, to advance their operations via the use of advanced wireless technologies, as well as to improve the efficiency of their spectrum usage. This perspective is expanded to consider the relationship of the freight rail industry with passenger rail, other transportation modes, and the intersection with public safety. This is a STRATEGIC PERSPECTIVE based upon identifying both the DEMAND for and SUPPLY of wireless technologies which provides the basis for structuring an approach for MOVING FORWARD.

The white paper will soon be available for download. But, to request an exclusive advance copy email Ron Lindsey at comarch@aol.com

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 5^th 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.

At the PTC Congress last week in Miami, a Union Pacific (UP) panelist was asked about the real estate on top of the locomotive as to the placement of antennas in the light of the 220 MHz band that is to be used for PTC. The UP manager stated that, in fact, there can be up to 14 antennae mounted on a locomotive, and Yes! they are getting crowded. The number was quite a surprise for me in that my quick count could only come up with 10 (which is a pathetic number in itself), i.e., GEO satellite, 40MHz, 160 MHz-voice, 160 MHz-data, 450 MHz, 900 MHz, cellular, WiFi, GPS, and 220 MHz. Now, moving into the cab, the large number of antennae implies that there is a significant number of radio units mounted in nooks and crannies, with each unit most likely servicing singular applications with singular protocols via singular frequencies, e.g., voice, end-of-train (EOT), locomotive diagnostics, event recorder download, and distributed power.

Ah Yes! I can’t help but think back just 20 years ago when railroad communications engineering was so straightforward. At that time, wireless on the locomotive was limited to voice radio with the introduction of EOT as the first major use of radio telemetry across the industry. Granted, railroads were even less efficient than they are today, but there was plenty of excess of everything, so what the heck? We didn’t need wireless data to advance resource management processes. The big thrust then was the transition from crystals to the use of synthesizers to provide a full slate of channels on a single locomotive radio unit. While the railroads’ communication forces may consider their expansion of wireless data technology since then to be progressive, as suggested by the locomotive’s antenna farm, I view the transition as being totally tactical and not at all strategic. So! Is that being progressive … or is it just being evolutionary? The difference between those two perspectives is extraordinary. That is, the additional cost of being tactical instead of strategic includes an extraordinary amount of capital investment, maintenance, opportunities to delay trains due to inoperable equipment, as well as an extraordinarily poor IT architecture (both physical and logical) due to the lack of system integration resulting in an extraordinary inhibiting of advancing railroad operations in a revolutionary fashion instead of an evolutionary one. By this last point I mean that railroads have failed to use wireless technologies to advance the management of their key resources from that of being reactive to that of being proactive, as discussed in other postings on this blog.

Unfortunately, the technicians have been free to do what they like to do most, i.e., design communication solutions that are tailored to specific applications. If they were asked to justify why they didn’t consider pooling applications on a single radio, for example, they would have a number of seemingly good technical reasons, of which some would have some merit. However, the bottom line is that they have not been required to build a multi-function or multi-band wireless platform that would reduce many if not all of those extraordinary items mentioned above. This is where software define radio (SDR) comes into play.

With the term SDR being introduced as recently as 1991, it can most simply be described as replacing a number of hardware components of a radio unit with software. The underlying principle for doing so is the use of some form of digital signaling processers (DSPs) that can replace specifically designed hardware such as RF filters, mixers, amplifiers, and modulators/demodulators. While that sounds interesting, the truly great point is that a single signal processing platform can service an unlimited number of combinations of bands and protocols. It only needs the appropriate software; software which can be accessed instantaneously to provide a different radio platform to the same user.

The real breakthrough in SDR began with the rapid, exponential increase in the power of general purpose processors to service the PC market. Again, simply stated, that meant that a standard computer and the corresponding advancements in software programming could advance SDR much more rapidly than continuing to rely on the much slower advancement in specialized DSP technology. What better example of this is there than the iphone and its competitors that can handle multiple protocols, e.g., 3G, 4G, in a fashion transparent to the user?

It was a decade ago that I reached out to several companies that were then beginning to use the general purpose processors found in PCs instead of specialized DSP to deliver SDR to the military – industry complex. One such company accepted an invitation to present their concepts, using a laptop computer, to the AAR’s wireless committee. They came, they saw, and they retreated. The interest by the railroads’ technicians was one of moderate curiosity without any incentive to do anything different than what they were then doing to avoid the inevitability of meeting the FCC’s narrow-banding push of the railroads’ 160-161 MHz band. That was then, What about now? Interestingly, the answer is that the technicians have totally swung to the other extreme of the pendulum. That is, instead of spinning wheels to achieve nothing, they are totally involved in creating the ultimate wireless data network and thereby ignoring all other possibilities as to advancing technologies as well as alternative approaches to spectrum usage.

SDR is only one possibility for advancing the cost-effective and efficient use of wireless across the rail industry that will be discussed in future posts on this blog. For example, I will be addressing soon the software defined antennae (SDA), that in sync with SDR, provides the basis for cognitive radio.

So many words, phrases, and processes that were used in 70s regarding computers have faded to the point that it is likely that few under 50 years of age would have heard of them, yet alone understand their usage. I am referring to terms such as core memory, thrashing, I/O bound, DP, TOS, DOS, boot strap, JCL, punched cards, re-IPLing, LCS, and core dump. This was the era of mainframe computers with orders-of-magnitude less processing power and storage than available today at orders-of-magnitude higher prices.  Indeed, as the phrase DP suggested, this was a period of batch processing of data, e.g., payroll or inventory update, versus that of dynamic generation of information.

Back then, one process in particular was extremely important when making decisions about the investment in computer systems. That is, customers would often require that a computer supplier to benchmark it’s various levels of systems, or against competitor systems, to compare the efficiency and adequacy relative to the cost of those systems.  In truth, having been actively involved in such activities as an IBM DP Marketing Representative, benchmarking was more often than not a shell game played by the vendors’ System Engineers that tweaked each part of their computer parameters (constraints such as I/O speed, partition size, disk access speed, etc.) to maximize the throughput of a particular a system in favor of each customer’s individual expectations. Getting the customer’s order was often the result of the vendor’s Marketing Representatives and System Engineers working together to set up the customer expectations and then to demonstrate the ability to meet them, respectively, euphemistically referred to as having account control.

With the move from back-office / mainframe computing to that of distributed client/server, the art and science of benchmarking has become that of legends for those still able to remember the good ole days.  With seemingly unlimited computer power and communication links, there is rarely an issue today of whether or not the IT architecture will handle the requirements and at what cost. Over the last several decades the investment decision has shifted from costs/power to that of developing / obtaining the software relative to business value. Well, that’s almost totally true. For industries that rely on substantial mobile and remote resources, advancing IT can also be a significant infrastructure and hardware cost as well and therefore worthy of benchmarking.  Unfortunately, that continues to NOT be the case for railroads.

As I have noted in other postings on this blog, and in my quarterly publication, Full Spectrum, most of the major railroads in North America have failed to develop a strategic technology plan in sync with a strategic operations plan (Strategic Railroading™). What is not understood, and therefore not appreciated or evaluated by railroads, is the paradigm shift that can be made for these predominantly unscheduled railroads by increasing the accuracy and timeliness of the status of their key assets, including track time, locomotive diagnostics, fuel, crews, and yard occupancy. And, the primary technology to do that is wireless data.  So, if companies found it appropriate to benchmark computer systems for the paradigm shift that they made in the 70s by replacing clerks with MIPS, then why are the railroads not doing the same in pursuing their deployment of wireless? There are two points to consider to address this question, i.e., MOTIVATION and PROCESS.

MOTIVATION

In the case of railroads with 1000s of locomotives and the possibility of incorporating them as mobile nodes on the IT architecture, as a manufacturer would consider fixed nodes, then there is definitely something missing. What is missing is the understanding by railroad management, and suppliers failing to taking a proactive position, of what can be done with IN-TIME data. I am not referring to REAL-time data. The difference between IN-TIME and REAL time is critical in understanding the constraints of using wireless data, versus the seemingly infinite capability of wired links as in a manufacturing environment.  To be explained in a future posting, IN-TIME data for train speed and position information in unscheduled operations is no more frequent than every 5 minutes for other than moving block operations. Hence, the railroad technicians that are charged with designing wireless networks can’t help themselves, nor are they held responsible, in making technical decisions which are not related to true business evaluation. Stated simply, technicians will always over design to make sure that they don’t come up short.

PROCESS

As nearly everyone now appreciates with the proliferation of cell phones and laptop computing, wireless is clearly limited in its throughput speed and coverage. It has been an eye-opening experience for those folks that expected that their internet connectively on their cell phone and notebook would match their in-the-office-cubicle desktop performance. There are two primary ways to determine what needs to be done.

1.      evaluate every possible wireless-based application as to data requirements and calculate the ultimate throughput requirements.  At least one railroad tried this approach several years ago, and the process bogged down in detail thereby insuring nothing would be resolved.

2.      evaluate on an 80/20 basis as to evaluating throughput requirements relative to a variety of wireless options recognizing the two key parameters of wireless data parameters. i.e. throughput and coverage. This approach was used a decade ago when I structured such a study that was participated in by the big 4 railroads in the U.S. with oversight by the AAR. The results of that study were used at that point by the AAR to justify the industry’s usage of the 160 VHF spectrum to the FAA. However, that was all the farther it went. Basic details follow.

Developing a Wireless Strategy for a railroad, or for an industry, needs to be pragmatic and adjustable to each railroad’s technical agenda, assuming there is one.

The process is rather simplistic in structure, but a true commitment is required by a railroad’s upper management to provide the players involved with the proper motivation to address the bottom line at the same time. To be brief, the process requires developing a matrix that plays off THROUGHPUT requirements against COVERAGE.  For railroads, the THROUGHPUT requirements may include simple categories such as Voice, Monitoring (locomotive diagnostics, shipment status), Out-bound Transactions (PTC targets), Process Control (moving block), and Interactive (M of W activities, in-train management). As to COVERAGE, the categories can be as simple as Terminal, Metropolitan (major cities with multiple railroads), Main Line, and Group (M of W gangs, Trains/Cars).  Within each Throughput / Coverage block of  the matrix, the possible applications are identified with a pragmatic evaluation of data requirements.  This provides the Demand perspective.

The next step is to evaluate the various wireless data options, both commercial and private, as to their ability to service the demand. This is the Supply perspective that results in Wireless Corridors, if you will, that permits structuring a manageable number of wireless strategies based upon business evaluation as to costs vs. value. Such an analysis, in my belief, would have prevented the phenomenal, unwarranted investment in the 220 MHz spectrum that is being made in the name of PTC, even though the railroads are required to spend $100s millions to rebuild the 160 MHz infrastructure as required by the FCC by 2013.

For those small to medium railroads outside of North America that are being slammed with ETCS, and the requirement for GSM, the analysis goes even deeper. That is, as described in other postings on this blog, the use of dark territory (with or without PTC) and the deployment of cost-effective wireless solutions can provide substantially lower capital investments to run a railroad both safely and efficiently.

Bottom Line, railroads should be benchmarking the use of wireless technologies with a pragmatic understanding of both Demand and Supply. Further details of such a process can be obtained by contacting me to discuss individual situations. This is what I provide as a consultant.

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! 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.

Rail professionals, whether from the railroads or the suppliers, associated with North American freight rail or European/Asian high speed passenger live and breathe some form of fixed block, signaled operation, either wayside or in-cab, as the means to provide crews with reliable movement authorities to advance trains. However, of that group only a relatively small percentage is operationally-familiar with the well-established, non-signaled operation (a.k.a. Dark Territory [DT]) that is used across 50% of U.S. rail trackage (albeit handling only 20% of the traffic).

What causes this lack of awareness?  Essentially, traditional traffic control suppliers have nothing to sell in DT  – there is no infrastructure required other than wireless – hence no business interest. Additionally, the heretofore, manual-only processes of DT have made it incapable of handling the requirements of high speed and/or high density operations, whether freight or passenger.  I say heretofore in that the digital age has now come to DT.

Wayside Signalling - An unnecessary cost

The availability of a wireless data network (with or without PTC) permits the time consuming, and possibly compromised, voice transmissions of the movement authorities between the crews and the dispatcher in DT operations to be handled as data presented via an on-board display. Additionally, that same wireless data path can be used to release authorities in the back office DT platform logic, a.k.a., conflict checker.  This double time-reduction whammy provides for a quantum increase in the capacity that a dispatcher can handle in DT operations.

But, outside of the Americas, the capability of DT, with or without the quantum improvement, is one of best kept secrets that, if known, could have a phenomenal effect on small and emerging railroads; railroads that are critical to the business and social welfare of their respective countries.  Again, I am not talking about the sophisticated railways of Europe, but the railways that are being considered across Africa, the Middle East, India, Indonesia, and elsewhere. These railroads could see a massive increase in capacity for minimal investment in a green-field operation to a net-savings for a railroad operating on an older signaling system (removing the older system would save future operating and maintenance costs, often resulting in a net savings). In addition, a traffic control system without wayside infrastructure results in less expensive equipment to be stolen or damaged by harsh environs reducing operating costs and increasing safety.

The railroads across the globe that could benefit from DT come in two types. First, there are railroads that are emerging either as green-field developments or as rebuilds of railways that have been reduced to rumble or abandoned for civil and/or economic reasons. Second, there are those railroads that are fully functional but are dependent upon the most antiquated traffic control system generically known as Token Block (TB). With its development stemming from the middle of the 19^th century in Britain, TB can be found in patches across the globe. TB is safe in concept. That is, to operate within a particular segment of track , a crew must possess a token, physical /electronic that is uniquely assigned to that segment. However, as I witnessed in my assignment in Egypt regarding the Egyptian National Railways (ENR) to evaluate safe railroading, including both traffic control and enforcement, the manual processes involved in TB ( 85% of ENR’s trackage) permit the vitality of operation to be greatly compromised. When those processes are violated; major accidents have occurred.

So! Here’s the problem. While DT is an excellent traffic control approach for small and emerging railroads, these operators are not being informed of its availability. Instead, major suppliers are selling (and traditional consultants are promoting) the major systems that have been deployed across major rail operations as the only solutions. Such solutions put these railroads at considerable financial risk , not only due to the initial investment required, but also as to the on-going profitability due to a combination of extensive maintenance and training costs, a likely lack of disciplined and educated maintenance personnel, and the susceptibility to theft of wayside infrastructure.

Hopefully, the safety project I mentioned in Egypt, as well as the marketing efforts of myself and my colleagues (we don’t represent suppliers nor accept commissions) will help spread the knowledge of Dark Territory and bring it into the light of those nationalized and private railroads that can truly benefit from its deployment.

I thought I had covered all of the important Teddy Bears in my prior posts as to the issue of vitality in railroad operations, but I forgot about one.  Several weeks ago at a PTC conference where I was the luncheon speaker, I addressed a number of topics. Arguably, the most important two points I discussed were:

PTC does not deliver business benefits; and

The fervent pursuit of PTC by the railroads to meet the mandate requirement is actually preventing the pursuit of opportunities to advance railroad operations. The reason for the latter is explained by the fact that most railroads lack both the Strategic Railroading perspective and the necessary resources, Technologists, to develop and deploy such a perspective.

At the conclusion of the presentation, the audience was asked if they had questions or comments. The first question was as to whether or not I thought Digital Authorities are vital. Indeed, there are many that believe them to be … with the sequential logic being that the wireless communication system required would have to be vital as well. In fact, the digital authorities are no more vital than the aspects on the signal post or the authorities that are provided via voice radio in non-signaled territory. All of these are only the display of the results of the vital process that was in effect to generate the authority.

With that said, it doesn’t mean that the transmission of authorities need not be accurate and reliable. For voice authorities, those attributes are provided by the crew member repeating the authority back to the dispatcher, and then starting over if there is any disagreement.  For DA’s, the accuracy and reliability factors are provided by a mathematical algorithm that performs error detection and correction on bits. And for signals, the issue is whether or not the light source is operable.  In all cases, should the transmission fail, then the crew knows what to do.  They revert to the threshold level of vitality referred to as the Book of Operating Rules.

The bottom line is that DA’s are not vital.

Therefore neither the transmission process nor the equipment need to be either.