Todd Crane and Jeff Eilenberg
Conrail manages a locomotive fleet of approximately 2,100 units, half of which are in long-haul service, operating both on Conrail owned trackage and off property. A Locomotive Condition Monitoring System (LCMS) was developed to monitor these $2 billion in assets, by providing near real-time location and operating characteristics.
Systems currently in use at Conrail do not provide timely and accurate data; and commercially available locomotive health monitoring systems are typically of a limited, closed architecture. Preliminary specifications and a prototype were developed based on an open system philosophy consistent with the company's information technology architecture. ArcView, Conrail's desktop GIS, was used as the front end to this highly dynamic and versatile data collection, management, and analysis system.
Prototype architecture and capabilities for the on-board computer (OBC), communications subsystem, and host/server modules are discussed. Integration of locomotive originated data and existing data sets, and proposed enhancements are discussed.
Competition. The driving force in corporate America. Until the 1980s, measuring success of a railroad involved comparison to other railroads. While this still holds true, comparative measurements today include competition posed by trucking. Though volume of freight continues to increase, the overall picture is one of eroding market share for the railroads. Consequently, the individual railroads are now examining the technologies and business practices of successful companies throughout the entire transportation industry.
The face of railroading has, and is, changing throughout North America. Currently, there are two dominant railroads in the west and three in the eastern part of the United States. This is about to change. Conrail, the largest freight railroad in the northeastern U.S., is in the middle of a merger/takeover battle that will result in two major railroads having access to all ports and markets east of the Mississippi River. Conrail operates approximately 11,000 miles of track in the northeastern and midwestern United States and the province of Quebec. Primary routes run between Chicago and E. St. Louis in Illinois, to Newark (northern NJ)/New York and Boston, Massachusetts.
The essentials of freight railroad operation are commodities to ship, trackage to transport these goods, the personnel to accomplish delivery, and reliable power (locomotives) to convey the shipment. Conrail's Locomotive Assets group, within the Operating Assets Department, is responsible for the availability and optimal performance of Conrail's locomotive fleet, which consists of approximately 2100 units. Half of this fleet constitutes long-haul road service critical to serving Conrail's customers. While Conrail jurisdiction has a defined geographic footprint, a significant segment of its locomotive fleet is free ranging throughout North America. Regardless of the location, fleet performance status and utilization statistics are critical to overall operations: scheduling, optimal fleet size, and off-property charges. En route failures of the road fleet manifest themselves after the fact and contribute to bottleneck conditions on our key routes. The logistics of diagnosing, servicing unscheduled shoppings, allocating new power, and returning the locomotive to service are resource intensive. The ability to predict incipient failures and suggest a most likely cause would greatly reduce cycle time and increase on-time performance.
Given the dynamics of freight transportation -- interchange delays, disposition of power, matching horsepower to the train consist, weather, and breakdowns -- locomotive fleet sizing has never been an exact science. Historically, possessing and maintaining a fleet in excess of demand addressed any potential shortages of locomotive power. It costs approximately $1.3 million to replace a locomotive and an additional $88,000 in annual maintenance. The average age of Conrail's locomotive fleet is 17 years -- on par with US Airways -- with a life expectancy of 30 years. Conservatively this translates into roughly $100 million annually in fleet turnover costs. With these significant numbers, is it necessary to maintain the current fleet size? A given in the past, this conflicts with another corporate goal of "improved asset utilization" -- getting more out of less. Tighter control and a clearer understanding of how and when the company's assets are being utilized is necessary. What are the spatial and temporal patterns of "trains without power" to "locomotives without trains"? How much time does a locomotive spend waiting for a train to pull (utilization)? Can the disparities be reduced such that locomotive dwell time and "light engine moves" are reduced to the point that we can reduce the locomotive inventory? Answers to these and other associated questions require improved data collection and processing tools. Tools, such as real-time GPS tracking (Locomotive 6724, Where Are You?) and GIS (Where is the nearest facility?), are available at relatively low cost and have been employed with reported success by the competition. Real time location information, for example, would allow scheduling personnel to analyze power (locomotive) distribution and power deficit (assembled trains without locomotives) disparities.
Typical measurements undertaken to assess fleet performance include Mean-Time-Between-Failures (MTBF), Mean-Time-To Repair (MTTR), availability, utilization, and en route failures. The Operating Department targeted goals for improvement of the fleet:
Additionally, maintenance should migrate from periodic or "run to failure" mode to "on condition" or usage-based repair -- from reactive to proactive.
Technology is available to raise current fleet utilization and lower maintenance costs, leading to modified maintenance policies and decreasing overall operating expenses. Advances in sensor, communications, and micro processor technology enable us to monitor, predict and react to adverse locomotive conditions in a real time environment, facilitating rapid and effective repairs while reducing inventory, and material handling costs. Increased availability translates into a lower number of maintained units and a smaller capital investment. Graphic presentation of the fleet's location and performance provides a "big picture" view to operations' personnel not currently available.
Collecting useable, pristine data on-board a locomotive and relaying it, in real time, to a central site for immediate presentation and analysis is requisite to obtaining these goals. Monitoring every device on-board that can potentially impact operating performance is not feasible. Decisions regarding proper sensor selection are necessary for effectively diagnosing a subsystem failure. Additional sensors may be required in the event a self-diagnosis can not be made. All information collected may need to be interpreted by a qualified locomotive specialist in order to correctly troubleshoot the problem. Utilization of GIS capabilities for display and network analysis will clearly expedite the process. The development of an accurate, timely, comprehensive locomotive location and condition database to store and disseminate this data ensures expeditious repair while also providing a foundation for other corporate-wide users and applications, such as power distribution and train scheduling applications.
Aside from collecting and processing locomotive condition monitoring data, the selection of an appropriate on-board computing architecture would enable other users to develop potential applications requiring access to information resident to a locomotive in transit.
The underlying communications infrastructure necessary to support message and data transfer between a locomotive and a central server can also provide a company-wide solution for extending its information network into the mobile environment. The combination of a multitasking computing environment aboard a locomotive, coupled with a reliable communications framework, would enable a variety of applications to be developed that require real time train information.
Conrail personnel conducted a fifteen month study through 1994 and 1995 collecting and collating historical data on locomotive utilization, failures, and repairs. The study covered over 6,000 locomotive incidents -- anomalies that required shopping or dispatch of field service personnel. Analysis of this data yielded MTTR, number of en route failures, failure classification, average transit time to repair figures, resulting in actual utilization and availability statistics. A subsequent report cited deficiencies in the following areas:
Among the recommendations cited was the need for an intelligent on-board monitoring system with a near real-time delivery mechanism and central repository. Visualization of location and status information would enhance decision making processes regarding the disposition of the locomotive fleet.
Locomotive Assets currently monitors and reports Conrail's' locomotive performance and availability using data reported through the Locomotive Information System (LIS) and the Locomotive Distribution System (LDS) -- both of which are mainframe based. In all instances, knowledge of locomotive failure is after the fact. These systems derive information from a variety of manual data collection processes at system and local levels. The primary function of the LIS system is to report locomotive failures and repairs. As the locomotive data becomes available, a subset is downloaded into a Windows-based relational database for measuring productivity.
Locomotive productivity measures developed from LIS data outline several disturbing facts. In the reporting of locomotive failures, the number one identified symptom is of the category "dead." This does not provide sufficient information to maintenance facilities to adequately identify the cause of the failure. Secondly, a large percentage of the reported failures, over 40% in one analysis, were non-existent -- no defects found upon a subsequent shop inspection. In either case, repair policy dictates a comprehensive check-up -- a waste of time and money. This combination of inadequate information about a reported failure with no defect identified, coupled with no information prior to the failure clearly indicates the need for pre-failure locomotive operating conditions to assist in identifying the underlying cause of failures. Present systems are highly reliant on oral exchange of information, manual data entry, and faxing of reports. The information may pass through several hands and reporting mechanisms prior to reaching shop personnel and are susceptible to errors, loss of information, and high data latency. These and other trends have led us to identify the need to perform centralized, remote monitoring of the location, operational status, and physical condition of each of locomotives in the fleet.
Conrail formed a cross departmental team to formalize the technical specifications necessary for implementing a condition monitoring system across the Conrail locomotive fleet. The team, representing various backgrounds and expertise, consisted of:
The team's early activities included establishing other railroads use and interest in locomotive condition monitoring systems, as well as scrutinizing commercially available systems. On the whole, other Class I railroads are utilizing these systems, and relying on other entities for integration of disparate systems. The team questioned this approach due to the unfactored costs associated with integration, let alone learning and maintaining different systems.
More than fifteen potential providers and system integrators proposed solutions. The result of this effort revealed inherent design and compatibility flaws in these condition monitoring systems:
The most prominent drawback of all systems reviewed is their inability to be deployed across the entire fleet. Conrail's locomotive fleet consists of a variety of makes and models, from different manufacturers. Some locomotives (e.g., EMD's SD80MAC) come equipped with sensors and processors to collect certain types of locomotive statistics. Additional moneys are required to move this data off board. Older models, such as the EMD SD50 utilized in the test pilot, are not instrumented and therefore need to be retrofitted with an entire LCMS system, from sensors, to on-board computer, to communication transceivers.
These deficiencies reinforced the LCMS Team's recommendation that Conrail design and specify a locomotive condition monitoring system compatible to both present and future locomotive fleets. The team was chartered to field test a prototype and draft system specifications. Subsequent to testing and approval, the specification would be circulated to potential Locomotive Condition Monitoring System builders for construction of the on-board system. Conrail would then be able to test their products in a real-time, working environment with the prototype functioning as a control.
Conrail's intention is to incrementally equip the road service locomotive fleet with a health and welfare monitoring system based upon open architecture/open systems principles. The system will incorporate the monitoring of significant locomotive subsystem parameters; convey that information to a central site, and display that information in a manner expediting troubleshooting by qualified Locomotive Assets personnel. There should be continuous performance monitoring of:
Communication with the locomotives will be bi-directional in near real-time. Continuous railroad-wide data communications will be necessary for:
A database server at the central site will function as a data storage mechanism providing a feed to the LCMS display module and other client applications. Examples of client applications include existing mainframe applications such as Locomotive Information System (LIS) and Location Distribution System (LDS) as well as potential applications for Shop facilities and service dispatch. This extended functionality will permit "closing the loop" on locomotive status, availability, and repair history.
Due to the magnitude of information collected and stored in the database, the system must have an easy to navigate interface. Since the data is primarily spatial in nature, a geographic-based interface is appropriate. For temporal trending and identification of recurring problems, the collected data needs to be integrated with other data sources -- another task well suited for GIS. Operator-selectable displays must be available to analyze and sort through all routine messages and anomaly reports. The system must support links to expert systems and other modeling tools.
The Association of the American Railroads (AAR) establishes recommendations for the industry, which members often codify into standards and scope specifications. Applicable AAR specifications include Locomotive System Integration (LSI) and Advanced Train Control Specifications (ATCS), the predecessor of Positive Train Separation (PTS). The former encompasses environmental criteria, interoperability and communications between devices, component and subassembly MTBF, and test parameters. The latter defines vehicle movement authority and enforcement, with heavy emphasis on communications protocol and messaging. Cognizant of these industry recommendations, the team deliberated over full versus selective compliance. Of greatest concern were the environmental aspects of the LSI specification. As to the ATCS specification, messaging regarding locomotive condition monitoring was incomplete.
By following Conrail's defined computing and technology guidelines and maximizing the use of commercial off-the-shelf components, subsystems, and software, the team was able to leverage in-house expertise and, in turn, speed the development process. ArcView, for example, has been certified by the Information Systems department as the corporate desktop GIS and was utilized by the LCMS team as an integration mechanism and data visualization tool. Incorporating these GIS resources not only aided rapid prototype development, but provided immediate access to data in the corporate spatial database. General reference information (political boundaries, streets), railroad industry (ownership), and Conrail-specific data (route structure, facilities) are all available to the LCMS operator. By knowing the locomotive's location in real time and the specific condition prior to dispatching repair personnel, the LCMS can improve the efficiency of locomotive repair. With the assistance of GIS tools, the operator will be able to determine the closest equipped facility or crew to the ailing locomotive.
Since the final end-to-end system consists of many complicated subsystems, the team planned to implement a modular proof-of-concept system in order to evaluate performance of all components, both individually and collectively. Three major benefits of a well- constructed modular architecture are that it provides expandability, avoids obsolescence, and prevents high costs associated with major code rewrites. Conrail plans to install components, both hardware and software, of various manufacturers so as to reduce the company's dependence on any one supplier or manufacturer inclusive of communication network providers. Aside from the obvious reason of not being "locked" into purchasing equipment from any one supplier, it is important to keep up with an ever changing computing environment. As technology, and more importantly, our needs change, Conrail staff should be able to take advantage of a competitive marketplace for improving the Locomotive Condition Monitoring System.
The design approach adopted also called for phased development of the total system. This would let the team focus first on the construction of the "core" technology and infrastructure necessary for collecting on-board data, and communicating messages with a central server. Further system development would allow for an increase in the number of sensors, additional on-board decision making capabilities, choice of alternative communication methods, and a variety of data presentation mechanisms.
There are three functional subsystems within the LCMS prototype: the On-Board Computer (OBC), the Trouble Desk, and the Communication Subsystem.
The On-Board Computer (OBC) collects information about locomotive condition and location, stores the data, reports the status at predetermined intervals, detects and forwards anomaly conditions and supporting information, and responds to Trouble Desk initiated requests. Under existing processes, locomotive failures are manually classified by a symptom code and description after the fact. Within the LCMS OBC, the association between sensor values and corresponding symptom code is calculated on-board as the readings are taking place. This "self-diagnosis" is accomplished by determining which sensors are required to evaluate the status of a particular subsystem, and by having decision-making capability on-board the locomotive. Physical components include the locomotive subsystem sensors (both analog and digital), a GPS receiver, an on-board processor, and communications transceivers.
The Trouble Desk can be further broken down into two components: a data storage, management, and distribution subsystem and a presentation and analysis subsystem. The data management subsystem receives messages from the locomotives (via the communication subsystem) or the trouble desk operator, logs them in a relational database, and notifies either the presentation subsystem or the locomotive that a new message has arrived. The presentation subsystem serves as the primary interface to the Trouble Desk Operator. This is a map-based interface that displays requested information in a "railroad-centric" perspective, such as "What route, track, and milepost marks the location of this locomotive?" or "Where is the closest shop or facility equipped with a fuel pad?". When an incoming message is received by the presentation subsystem, the locomotive's position is updated on the map. If the message contains an anomaly, the trouble desk operator is notified by:
The underlying data values used by the OBC to generate the symptom code are also available for immediate viewing, should the operator need to confirm the diagnosis or explore other conditions. This method makes troubleshooting much faster and provides an immediate entry point into the log files instead of having an expert pour through multiple (hundreds?) rows of data in order to, hopefully, arrive at the same conclusion.
The Communications Subsystem provides the interface between the OBC and the Trouble Desk. It receives a message from the OBC processor or the Trouble Desk subsystem, establishes and maintains the communication link, and transmits the packets to the target subsystem to parse and process. Since continuous coverage is required to ensure timely delivery of messages between the locomotive and OBC, multiple communication channels are needed. While a satellite communication link provides ubiquitous coverage, it is not well-suited to large file transfers and is also an expensive transport mechanism. Cellular technology and packet data radio are cheaper and allow larger and faster message throughput than a satellite link, but tend to cover only local service areas. Our solution was to isolate the communication links from the OBC and Trouble Desk subsystems and adopt an application programming interface (API) between these modules. This API would allow the OBC and Trouble Desk to write out a message without concern of which communication link it traverses. It is the job of the communications subsystem to prepare the messages for transport over the desired link and to ensure they are delivered in their entirety.
With the architecture divided into separate processing subsystems, messaging formats had to be defined for requesting and delivering data between them. As previously stated, the Trouble Desk operator can always review any information used to generate any OBC generated message. There are occasions, however, when a user would like to review a subset of parameters over varying degrees of time. For example, would a set of values representing one reading satisfy the question? Or is a ten-minute history of all subsystem sensors required? To handle this disparity, the team established different types of messages. A snapshot request -- sent by the Trouble Desk to the OBC -- would return one reading for all selected subsystem parameters. The snapshot response from the locomotive would represent the latest values recorded by the OBC. In contrast, when the OBC received a buffer request, it would return to the Trouble Desk all values recorded for a ten-minute period prior to an anomaly report with the last values representing the triggering event. Status messages are sent by the OBC at periodic intervals to the Trouble Desk. The frequency of status messages sent is a user-defined parameter and can vary between locomotives. Anomalies manifest themselves as Alert and Alarm messages. An Alert is a reading out of specification, but with no immediate failure pending. An example of this could be elevated engine temperature while the locomotive is pulling up a steep grade -- while the value is out of range, it can be expected to return to normal once even grade is reached. An Alarm is a value out of range with imminent failure. This may require shopping the locomotive or dispatching a repair crew immediately.
The LCMS prototype has been functional since April 1996. Since its installation, the system has logged thousands of messages -- some have been alarms. Last June, we began to notice a failure report for one of the digital sensors associated with fan controller #2. (The fan controllers start fans to help regulate engine temperature.) Throughout the next few weeks, similar alarm messages were generated, but not continuously. Since the condition was not persistent, immediate action was not taken after the first reading, but a review of the location, time, and activity associated with each anomaly report revealed that Locomotive 6724's fans may not be firing properly. In each instance, Locomotive 6724 was pulling a heavy consist, some times up hill, and was therefore required to work harder -- and hotter. All fans are needed to regulate engine temperature in these situations. The LCMS intimated that fan controller #2 had stopped working. The locomotive was inspected at the next shopping and, as it turns out, the fuse for fan controller #2 was blown. Success! While not a show stopper, if unknown, this condition would contribute to unnecessary engine stress and decreased life expectancy. Further, possessing this information beforehand precluded an en route failure.
With the successful performance of the prototype, and a functional specification completed, the team is ready to test and evaluate systems. Next steps include:
The complexity imposed on the present system by these enhancements extends the functionality of, and reliance on, middleware and APIs. The isolation of application software from transport mechanisms and supporting infrastructure is critical. The logistics of capturing a 100+ ton moving target to tweak software or switch communication networks are diametrically opposed to the goals of increased efficiency and asset utilization.
Obviously, as the number of outfitted locomotives and sensors increases, there will be a dramatic increase in the amount of data collected and reported back to the central site. Further data modeling, data warehousing, and data "mining" techniques must be employed to guarantee fast and easy access to this data. Automated trending tools will assist users in correlating anomalies and suggest previously unforeseen relationships within classes of locomotives and/or across the fleet. The use of Esri's Spatial Database Engine (SDE) would ensure immediate access to comprehensive geographic datasets while an Oracle-based Locomotive Maintenance Database would provide a flexible repository and delivery mechanism capable of satisfying many different users. Future expansions, based on a full-scale production LCMS platform, include establishing terminal and shop diagnostic workstations, interfacing with train inspection devices, performing train consist reconciliation, and assisting power and train scheduling.
No longer an isolated technology reserved for "closet" or "behind-the-scenes" mapping, GIS is coming into its own supporting mission critical operations. Recent advances in GIS and related technologies, coupled with wider political acceptance, has promoted utilization of GIS throughout multiple application domains. Whether for asset or shipment tracking, commodity flow, crew dispatch, or vehicle/locomotive repair, GIS and GPS technologies are playing an increasing role throughout the transportation industry.
Senior Analyst, GIS
2001 Market St. 19B
Philadelphia, PA 19103
Senior Systems Engineer
LS Transit Systems
14 Washington Rd., Suite 722
Princeton Jct., NJ 08850