Strategic Railroading

Archive for the ‘Railroad Business’ Category

In the previous 2 posts of this set of 3 regarding Industry INTRAoperability (not Railroad INTERoperability for PTC) I addressed both the opportunity and the rail executive education that are required for the unprecedented opportunity to advance the railroads’ operations, both individually and as an industry. The underlying logic is that rail executives are motivated by their bonus plans to optimize the handling of their responsibilities. Hence, a strategic perspective that is beyond the horizon of their bonus program requires that top management be so educated to provide the incentive to think strategically as to the deployment of technologies to satisfy a strategic business plan, a.k.a. Strategic Railroading™. In this posting I discuss a well-proven process that provides the structure to do so.

In other postings on this blog I have referenced IBM’s efforts in the 70s and 80s to introduce the usage of computers across industries to replace manual business processes as well as to re-engineer business processes given the integration of computers with telecommunications, thereby establishing new flows of information within and between enterprises.  In addition to the prestigious executive sessions that IBM provided for its clients back then, IBM developed a very formal process for identifying the information flow architecture that would support the advancement of computers. Referred to as Business System Processing (BSP), the Wikipedia description properly identifies the primary objectives, i.e.,

• understand the issues and opportunities with the current applications and technical architecture,
• develop a future state and migration path for the technology that supports the enterprise,
• provide business executives with a direction and decision making framework for IT capital expenditures,
• provide information system (IS) with a blueprint for development.

Why BSP can be of great value to the railroads in particular at this point is the opportunity of developing “a future state and migration path” given the proliferation of wireless networks, both private and commercial. Even more to the point is the tremendous effort and investment that the railroads are making to lay in a 220 MHz network in the name of PTC. And, as noted in other postings on this blog, this decision by the railroads to deploy 220 MHz is really pathetic in two primary ways.  First, the railroads have failed to justify the need for additional 220 MHz as evidenced by FCC’s rejection of the railroads’ request for such spectrum in addition to what they already own. Second, there is no strategic business plan associated with any strategic technology plan (other than to just install 220 MHz) to cost-effectively use all of the spectrum that the railroads now possess. It is in support of both of these points that a BSP could lay the foundation of how wireless can benefit not only the individual railroads, but also the industry overall. In fact, had the railroads already performed a BSP for the industry, one that was truly understood and accepted by senior management, then the 220 MHz sham by the railroads’ technicians would have never gained any ground in my opinion.

So! It’s agreed then. A BSP can be greatly beneficial. But how is such a process performed?

BSP Process

There are 8 primary, structured & well-proven steps in performing a BSP, as follows:

1. Gain Executive Authority: This is often the most critical part of a BSP. Without the proper level of commitment to support the need for incorporating multiple departments of an organization within the study, the effort will fail with the first major disagreement between the departments, a disagreement that is inevitable;

2. Define the Business Strategy: This steps sounds difficult perhaps, but it actually is quite simple if the participants can be honest about the successes and failings of the organization and their individual departments;

3.Define the Business Processes: This is the most creative part of the BSP in that it requires visionaries that can look beyond the current processes and recognize the possible changes due to advancing technologies. For railroads it is the focus on wireless data that can provide for more timely and accurate management of the vast sets of mobile assets;

4. Define the Business Classes: Defining data classes (aggregates of related data elements) is very straightforward once the business processes have been defined.  (Note the very simplified example below of which business processes create / use the various business classes.);

5. Validate Finds with Management: This process establishes a line in sand with the management team that demonstrates the study is meeting the objectives of the study so as to ensure on-going commitment.

6. Define the Information Architecture: Ah Yes! This is the most fantastic step where the BSP effort really clicks and all participants and management can see what they have been missing as to information flow between the primary entities, and processes. (Note below a simplified example of a BSP that I performed for the intermodal industry. The arrows indicate the flow of specific data classes (descriptions not included) between operational entities and/or data bases. The black objects and arrows are current, the red objects and arrows are new relative to the changes in the business processes, and blue objects are hardware that need to be developed;

7. Establish Information System Priorities: The appropriateness and credibility of the information architecture developed via the BSP is first tested here as each player pulls for particular interests in establishing the priorities of the future information systems. Using the above diagram as an example, the order in which the red blocks are developed, either individually or collectively, can greatly affect the actual success of reaching the desired overall objective.

8. Make the Business Case for Management: YES! The most important business case. If nothing else, the BSP process takes the control of technology investment out of the hands of the technicians who seemingly have the desire to deliver the optimum system as to capability, whether it is required or not.  Again, the most current, and capital-wasting example of this is that of PTC deployment where the technologists are out of control as to wireless (220 MHz), a train positioning platform, and the use of wayside interface units to interface with Intermediary Signals ( see the previous posting on this block “IS … Not”).

Voila!  I have managed or participated in 4 BSPs … and this is really good stuff.

This is the 2^nd of 3 postings that address Industry INTRAoperability (I/I), i.e. the development of systems that support the business interest of the entire rail industry, versus the advances in technologies and systems made by each individual railroad for its singular purposes.  I/I is not the same as Railroad INTERoperability, as is required to deploy Positive Train Control (PTC) as a safety enhancement to the traffic control systems that provide for the integrity of movement operations. Rather, I/I addresses the business perspective of the advantages to the industry by the improved management of key resources subject to the interchange of trains between railroads. The assets that I am referring include the full array: track time, train crews, yards, locomotives, rolling stock, and shipments of high value and/or involving security issues.

Yes! I did state track time, train crews, and yards even those assets don’t cross borders. The reason for doing so is that the use of those assets increases in efficiency as the degree of scheduled operations increases . . . And, the ability of an individual railroad to run to scheduled operations is partially dependent upon the schedule reliability of the railroads with which it interconnects . . . And, since most railroads have yet to demonstrate their ability to run to schedule to a significant extent, contrary to their claims, then a valuable opportunity of pursuing I/I is that of providing timely data of train movements, both position and speed, across all interconnecting railroads so as line-ups can be adjusted in a timely fashion.  Unfortunately, even with such data, a number of roads are incapable of using it to any great extent given their lack of Proactive Traffic Management techniques that I introduced 6 years or so ago in my quarterly publication, Full Spectrum. However, it is encouraging that at least NS and BNSF have made such advancements via the deployment of pragmatic wireless solutions that can report the speed and position of their own trains on their respective properties.

As to the locomotives, rolling stock, and shipments that do cross railroad borders I identified a number of I/I applications 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). As the result of that study, I decided shortly thereafter to take the same approach that IBM used in the 60s and 70s to bring about major changes in the traditional business processes of a full range of industries with the introduction of main frame computers. That is, IBM established major executive education facilities and curriculums across the U.S. to expose their prospective clients’ top management teams to what could be done with computers. As noted in the previous posting, the initial efforts focused on replacing manual data handling processes, e.g., payroll, accounts receivables / payables, with computerized data processing. However, with the introduction of affordable disk storage and the integration of telecommunications with computers, the curriculums expanded in scope by identifying how to change the traditional business processes given the opportunities to rethink the flow of information within and between enterprises (The process of structuring a strategic information flow architecture will be discussed in the next posting: It Takes an Industry: Process).

So, following IBM’s lead I put together an Strategic Railroading Symposium for top railroad executives that would be sponsored by the supplier community overall to remove even the perception of bias. The symposium schedule (presented below) that I put together consisted of 2 tracks, Operations & Engineering, with two categories of topics each, that addressed I/I opportunities as well as other possible applications that I believed at that time would be valuable exposure for railroad top management. Actually, this effort was progressing well with the expression of key suppliers to participate . . . that is until the ramifications of the just-ordered PTC mandate took effect. At that point, rail’s management teams withdrew into their caves rejecting the consideration of anything other than the challenges of implementing PTC. The suppliers, hence, backed away from the opportunity given their inability to market even their current products and services, yet alone the challenges and risks of developing a long-term strategic perspective.

As you will see in the agenda below, several of those applications have had sporadic initiations across the industry in the last several years.

When rail management surfaces from the PTC abyss, then perhaps there will be an opportunity to reconsider some version of the Strategic Railroading Symposium.

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.

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.

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.

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.

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.

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.

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.

“The way of paradoxes is the way of truth”

“To test reality, we must see it on the tight-rope. When the Verities become acrobats, we can judge them.”

With these two statements the reader is soon introduced to the underlying principle of paradox throughout Oscar Wilde’s only novel, The Picture of Dorian Gray. This piece of literature drips with often-veiled aphorisms that either challenge or enlighten one’s intuition of humanity and society. While the author’s nearly-religious pursuit of beauty was the motivation behind this writing, the truisms revealed have applicability today … and, if you will grant me some wide-ranging poetic freedom,  within the rail industry.  Consider the following quotes and their applicability to railroads;  the OSCARS if you will.

“I can stand brute force, but brute reason is quite unbearable.  There is something about its use.  It is hitting below the intellect.” . . . Operations management if pressured to run to schedule.

“The true mystery of the world is the visible … not the invisible.” . . .  Operations management if pressured to recognize and integrate yard status in managing the main line lineup.

“Punctionality is the thief of time.” . . . Advocates for running a truly-scheduled railroad.

“People know the price of everything and the value of nothing.” . . .  Why the railroads need technologists (and not technicians) to pursue NOW the transition of analog VHF to digital VHF.

“Faithfulness is to the emotional life what consistency is to the life of the intellect – simply a confession of failure.” . . .  An evaluation of those who refuse to break with traditional methods of operations even though there are substantial benefits to be had.

“Good artists exist simply in what they make, and consequently are perfectly uninteresting in what they are …  inferior poets are absolutely fascinating.” . . . The boredom of running a scheduled (but efficient) operation vs. the “excitement” of traditional crisis-based railroad management.

“To be good is to be in harmony with one’s self … discord is to be forced to be in harmony with others “ . . . Why non-scheduled operations causes strife within a railroad.

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.

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.