Patent Application
20070106434
1. Field of the Invention
This invention pertains generally to railroad dispatch monitoring and, more particularly, to user interfaces for railroad dispatch monitoring of one or more railroads. The invention also pertains to display systems employed for reporting, monitoring or displaying railroad information or for controlling a railroad.
2. Background Information
Many large metropolitan areas, Chicago being a particularly striking example, are witness to the convergence of multiple railroads' right-of-ways, which cross at grade in many locations and over which trains are frequently handed off from one property to another. Because these areas are centers of commerce, there are relatively large counts of trains simultaneously traveling within a relatively small geographic region. Not surprisingly, such areas have become choke points within the railroad network, causing trains to spend far too much time moving across them. Coupled with projected increases in railroad traffic (e.g., intermodal transport alone is rising approximately 10% per year), this foreshadows even greater congestion along with concomitant slowdowns and blocked highway crossings, threatening to severely curtail future growth opportunities within the railroad industry. This also suggests an increased likelihood of problems with the traveling public and with local, state and federal authorities.
Responding to this situation, for example, in the specific case of Chicago, the railroads, the State of Illinois, the City of Chicago, Cook County and the Federal government have teamed to form the Chicago Region Environmental And Transportation Efficiency Project (CREATE). The overall program includes a series of projects targeted at mitigating the effects of increasing railroad traffic, while at the same time improving safety and enhancing throughput. Central to the program and its success are civil projects involving highway grade crossing separations, rail-to-rail fly-overs, and the update/upgrade of older interlockings. The freight railroads along with the Chicago commuter railroad authority, Metra, coordinate freight/passenger operations in the Chicago area through the Chicago Transportation Coordination Office (CTCO).
It is believed that an overview capability for plural different railroads is currently not available because each railroad is not able to “see” all foreign railroad trains when the latter are approaching their tracks. Moreover, this information is communicated manually, leaving what is, at best, a fragmented view of traffic flow across the geographic region of interest. At present, each railroad monitors only its own right-of-way using computer screens that display where other railroads' tracks cross, but with little or no advance notice about approaching trains. When required to make a move into or across another railroad, a dispatcher has to contact his peer dispatcher on the other railroad to coordinate the move. Since neither dispatcher can see the condition of the other dispatcher's territory, one or more telephone calls (and/or facsimiles (i.e., faxes)) may be required to accomplish this operation. It is believed that there is presently no other way for acquiring the needed information.
While the dispatcher could obtain a schedule or train status lineup, there is no guarantee that the projected arrival times will be met. Updates would have to be obtained by telephone (or facsimile) as well. All of this is cumbersome, taking too much time and making it difficult to effectively manage train moves and congestion where plural railroads are involved.
As shown in
There is room for improvement in user interfaces for railroad dispatch monitoring.
There is also room for improvement in display systems for displaying information from railroad Computer-Aided Dispatch (CAD) systems.
These needs and others are met by the present invention, which provides a user interface for railroad dispatch monitoring of a geographic region in which train track diagrams are substantially oriented in (a) at least a first direction and (b) a different second direction, which is substantially normal to the first direction. Both of the at least a first direction and the different second direction approximate the directions of the train tracks of the geographic region. The invention also provides a plurality of data interfaces communicating to a server employing a common data format, in which each of the data interfaces receives a different and diverse data format from one of different and diverse railroad Computer-Aided Dispatch (CAD) systems and converts the same to the common data format.
As one aspect of the invention, a user interface is for railroad dispatch monitoring of a geographic region including at least one railroad having a plurality of train tracks. The user interface comprises: at least one display comprising a plurality of train track diagrams for the geographic region, wherein the train track diagrams are substantially oriented in (a) at least a first direction and (b) a different second direction, which is substantially normal to the first direction, and wherein both of the at least a first direction and the different second direction approximate the directions of the train tracks of the geographic region.
The at least one railroad may be a plurality of different railroads, and the geographic region may include the different railroads.
The train track diagrams may be substantially oriented in a North-South direction, an East-West direction and at least one diagonal direction in between the North-South direction and the East-West direction.
The at least one railroad may include at least one train having a position. The at least one display and the train track diagrams may display the position of the at least one train. The position of the at least one train may be displayed in real time as the at least one train moves through the geographic region.
As another aspect of the invention, a display system for displaying information from a plurality of different and diverse railroad CAD systems comprises: a server; a number of display clients served by the server; and a plurality of data interfaces communicating to the server employing a common data format, each of at least some of the data interfaces being structured to receive a different and diverse data format from a corresponding one of the different and diverse railroad CAD systems and convert the same to the common data format.
At least some of the data interfaces may include the same type of physical interface to corresponding ones of the different and diverse railroad CAD systems.
At least some of the data interfaces may include different types of physical interfaces to corresponding ones of the different and diverse railroad CAD systems.
The different and diverse railroad CAD systems may include a plurality of different proprietary data formats. The data interfaces may include corresponding conversion programs structured to translate a corresponding one of the proprietary data formats to the common data format.
The display clients may include a train dispatch display, which may include a plurality of train track diagrams for the geographic region. The train track diagrams may be substantially oriented in at least a first direction and a different second direction which is substantially normal to the first direction.
A full understanding of the invention can be gained from the following description of the preferred embodiments when read in conjunction with the accompanying drawings in which:
As employed herein, the term “number” shall mean one or an integer greater than one (i.e., a plurality).
As employed herein, the terms “railroad” or “railroad service” shall mean freight trains or freight rail service, passenger trains or passenger rail service, transit rail service, and commuter railroad traffic, commuter trains or commuter rail service.
As employed herein, the terms “traffic” or “railroad traffic” shall mean railroad traffic, which consists primarily of freight trains and passenger trains, and commuter railroad traffic, which consists primarily of passenger trains, although it can include freight trains.
The present invention is described in association with a particular geographic region and in association with particular railroad Computer-Aided Dispatch (CAD) systems, although the invention is applicable to a wide range of areas where plural railroads converge, and to display systems displaying information from a wide range of railroad CAD systems.
The disclosed plural railroad dispatch monitoring system includes a common data format that all railroads can utilize. The common data format specifies a data protocol schema for communicating information from different and diverse railroad CAD systems. The disclosed system improves the coordination of railroad service in, for example, relatively heavily trafficked metropolitan areas or where there are major interchanges between plural different railroads. The disclosed system and common data format enable the information from any railroad dispatch system (including, for example, tracks, signals, switches, train occupancy and train ids) to be integrated into a single overview display. The output of the system is the overview display for plural railroads that encompasses a geographic region of interest (e.g., without limitation, two or more railroads running through a relatively high percentage of the Chicago area; all the railroads running through the Chicago area, resulting in a fully integrated railroad overview display for the entire Chicago area).
Accordingly, one way to help address the congestion problem is to monitor and display, in real time, on a single screen, the patterns of all railroad traffic as they move through the geographic region of interest. This overview capability provides a mechanism for operational look-ahead and the ability to anticipate potential congestive situations because all trains would be viewed together, thereby enabling interested observers and, perhaps, railroad dispatchers who dispatch in that geographic region, to more effectively coordinate activities.
Referring to
One of the first direction and the different second direction is North-South.
One of the first direction and the different second direction is East-West.
The train track diagrams 120 are substantially oriented in a North-South direction, an East-West direction and at least one diagonal direction (e.g., as shown by the train track 116) in between the North-South direction and the East-West direction.
The train track diagrams 120 include one, some or all of the objects 104, such as a plurality of tracks, a plurality of switches, a plurality of signals, a plurality of train positions, a plurality of movement authorities, a plurality of field devices, a plurality of train occupancies, and a plurality of train symbols.
Each of the different railroads 106,108,110,112 include one, some or all of the objects 104 of Example 4.
The example overview display screen 100 is an all-encompassing track display that provides substantial improvements in railroad operational awareness. Since the tracks, such as 114,116,118, are drawn in order that they appear like those that dispatchers have on their computer screens, albeit for a single railroad and albeit for a single orientation (e.g., East-West), railroad operations personnel may use the overview display screen 100 to monitor trains, such as TRN002 and TRN003. Hence, there is at least one important difference between the disclosed overview display screen 100 for one or more railroads' tracks and what dispatchers currently see on their screens. As shown in
In the example of
The example overview display screen 100 of
The example overview display screen 100 shows tracks 114,116,118, including switches 122 and signals 124, and one or more example train occupancy or train symbols (TRN002 and TRN003, which are under (with respect to
The example overview display screen 100 of
Besides scrolling, navigation may also be based on control points (e.g., such as control point 126, Calumet Park, of
In order to realize the benefits of an overview display, such as the overview display screens 100,128 of
Referring to
The different and diverse railroad CAD systems 202 include a plurality of different proprietary data formats, such as 218,220. The data interfaces 214 include corresponding conversion programs, such as 222,224, structured to translate a corresponding one of the proprietary data formats 218,220 to the common data format 216.
At least some of the data interfaces 214, such as 226,228, include the same type of physical interface 230 to corresponding ones of the different and diverse railroad CAD systems, such as 232,234.
At least some of the data interfaces 214, such as 236,238, include different types of physical interfaces 240,241 to corresponding ones of the different and diverse railroad CAD systems, such as 242,244.
Examples of the different types of physical interfaces include a commercial middleware link 246 and a serial link 250 to a communication gateway 249 of one of the data interfaces 214 interfaced to the web server 206. Preferably, the outputs of the data interfaces 214 employ commercial middleware links to the web server 206.
Examples of the different data interfaces 214 include at least one of a commercial middleware interface 247, and a raw socket interface 248 to the web server 206.
Another example of the different data interfaces 214 is a communication gateway 249 including one or more serial links (e.g., serial port interfaces) 250 to one 251 of the different and diverse railroad CAD systems 202. As with Example 15, the communication gateway 249 may further include at least one of a commercial middleware interface and a raw-socket interface.
The data interfaces 214 communicate to the web server 206 by further employing at least one communication protocol, such as 252,254.
The display clients 208,210,212 include a plurality of displays, which may include the train track diagrams 120 of
Non-limiting examples of the display clients 208,210,212 include a number of personal computer clients 208 (e.g., without limitation, for displaying an overview display), one or more personal digital assistant clients 210 (e.g., without limitation, for displaying train status lineups) and a train dispatch display, such as the example real time train dispatch display 212. For example, the personal computer clients 208 employ a local area network connection 256 to the web server 206, the personal digital assistant client 210 employs a wireless connection 258 to the web server 206, and the train dispatch display 212 employs a web-based HTTP(S) Internet or intranet connection 260.
The display clients 208,210,212 are preferably structured to report, monitor or display railroad information and/or to control a railroad.
The common data format 216, as will be described, is employed for communicating data from plural different and diverse railroad CAD systems 202 to the web server 206, which uses that data. The common data format 216 enables the different suppliers to build data interfaces between their respective CAD systems 202 and the “outside world” without revealing proprietary information. The data interface 214 to each CAD system 202 consists of a corresponding conversion program, such as 222 or 224, that translates each supplier's proprietary data format, such as 218,220 to the common data format 216. The common data format 216 enables information to be selectively displayed for all the railroads of interest that have one or more tracks in the geographic region (e.g., 102 of
The common data format 216 (e.g., open interface data protocol) is preferably encoded using (e.g., written in) XML (eXtensible Markup Language), which is a data formatting language for exchange of data over IP networks. Other suitable languages may be employed which include device state descriptions; that is, the schema they provide represent devices at the state level. Example alternatives to XML include using Common Object Request Broker Architecture (CORBA) or any suitable Remote Procedure Calling (RPC) interface.
The example XML schema describes device state changes, in order that they can be interpreted at the web server 206 for use in updating the display clients 208,210,212. XML is also advantageous because of its use of strings to represent data, thereby making it relatively easy to extend. For example, Electronic Data Interchange (EDI) and Advanced Train Control System (ATCS) do not provide for the kind of extensibility inherent in XML. XML is becoming a widely accepted data formatting language for the exchange of data over IP networks. The disclosed message formats are intended to be structurally simple, in order for a conversion program, such as 222,224, to be readily provided for any CAD system, such as 202.
An example of the disclosed message formats is as follows:
Appendix A shows an example of XML schema (e.g., schemas are conventionally represented as XML documents; structures (http://www.w3.org/TR/xmlschema-1/); datatypes (http://www.w3.org/TR/xmlschema-2/); see, for example, http://www.w3.org/2001/XMLSchema) for various device states, such as, for example and without limitation, signal, switch and/or track states. The XML schema definition is employed to validate a state map as it is parsed into memory. The target namespace, http://www.domain.com/cop/statemap, is the namespace for the schema. This namespace uniquely identifies the schema and is used to avoid collisions with elements in other schemas.
Appendix B is an example output file showing the communication of XML messages. This includes a sample of the XML data that is exchanged between a particular CAD system, such as 202, and the web server 206. For example, one such XML messages is as follows:
This XML fragment conveys that Signal 9 at Control Point 5564 has a clear control issued. The XML schema of Appendix A is designed such that the devices are referenced using external nomenclature and the device states are represented using common operating state names. The string “http://www.domain.com/cop” of Appendix B is the namespace for the schema employed to validate the common operating messages.
Appendix C shows an example state map XML file for translation between CAD messages for one of the CAD systems 202 of
Continuing to refer to
At the bottom of
Each message that is translated into the example XML message format is communicated to the central web server 206. Just as the example XML message format is intended to facilitate conversion of the data, the communication of the data may be facilitated by a wide range of different physical communication protocols (e.g., without limitation, a serial connection or link to a communication gateway for CAD systems 202 employing relatively older platforms; a commercial network; commercial middleware for CAD systems 202 employing relatively modem platforms). The use of various communication protocols provides the various different CAD systems 202 with a plurality of different options for interfacing to the system 200.
When the web server 206 receives a message from one of the data interfaces 214, the received message is processed by a display subsystem 262, thereby rendering it accessible to any authorized user at the display clients 208,210,212 that has access through one of the example connections 256,258,260. Preferably, the web server 206 employs a secure login function 263 for the display clients 208,210,212. Hence, not only will the received message be available to those display clients monitoring the example Chicago geographic region, but it could also be made accessible to other railroad personnel for remote viewing. Moreover, as a message formatting language, XML allows any product or system that adheres to the common data format 216 to be interfaced to any CAD system 202, which will benefit the railroad industry as a whole.
The disclosed system 200 does not require a lot of expensive equipment or software in order to be used. Because no proprietary software is needed by the one or more display clients 208,210,212, the only software employed is a web browser, such as 264, which has become standard issue for all computers.
The overview displays of the display clients 208 preferably employ multiple railroad trackage in a separate track database (not shown) with respect to the different and diverse CAD systems 202 because of the nature of the overview display screens, such as 100,128 of
For purposes of showing all of the device state changes, the example system 200 is preferably event-driven, which means that whenever there is a change in the state of the field for any of the various railroads being displayed, that information is pushed out to the display clients 208,210,212 as soon as it is received by the web server 206. Preferably, latency is minimized. Furthermore, the freshness of the data will be known at all times because the web server 206 preferably continually monitors the connections to the respective CAD systems 202 to see if they are alive. The data interfaces 214 and the web server 206 are event-driven in response to changes in state of the different and diverse railroad CAD systems 202. The web server 206 receives one of the changes in state from a corresponding one of the different and diverse railroad CAD systems 202 and responsively outputs the same to the display clients 208,210,212.
As an alternative to being event-driven, the example system 200 may employ polling to manage updates. The polling system is accessed, for example, as a typical web application with a standard web browser, such as 264, on the display client, such as 212. The polling system may not show all of the device state changes, but can be accessed by more types of display client machines. The web server 206 polls the data interfaces 214 to receive changes in state of the corresponding CAD systems 202. The web server 206 receives one of the changes in state from a corresponding one of the CAD systems 202 and responsively outputs the same to the display clients 208,210,212.
As an alternative to Examples 23 and 24, the example system 200 may employ full screen updates in which data is acquired over a suitable predetermined time period (e.g., without limitation, during about five to about six seconds), before updating the full screens of the display clients 208,210,212 at one time for each screen. The web server 206 acquires from the data interfaces 214 a plurality of changes from the CAD systems 202 over the predetermined time period, and then outputs all of the changes.
The system 200 may employ data analysis tools (not shown) for trending and measurement. As non-limiting examples, these tools may include various functions to: (1) collect, store and analyze train position data; (2) generate reports on performance (e.g., by train; by train type; by area); and (3) access reports through data servers via the Internet.
The system 200 may employ event logging and playback capabilities. As non-limiting examples, these capabilities may include various functions to: (1) record all train moves and device state changes from messages sent to the display; (2) display simulated playback on overview screens; (3) filter event logs (e.g., by time; by events; by train number); and (4) display playback and event logs via the Internet.
Referring to
The disclosed system 200 of
A primary benefit of the disclosed plural railroad monitoring system 200 is to reduce congestion and improve on-time performance through the use of a single dispatch-like overview display screen, such as 100 of
While for clarity of disclosure reference has been made herein to the exemplary overview display screens 100,128 for displaying train track diagrams 120, data or information from plural different and diverse railroad CAD systems 202, it will be appreciated that such diagrams, data or information may be stored, printed on hard copy, be computer modified, or be combined with other data. All such processing shall be deemed to fall within the terms “display” or “displaying” as employed herein.
While specific embodiments of the invention have been described in detail, it will be appreciated by those skilled in the art that various modifications and alternatives to those details could be developed in light of the overall teachings of the disclosure. Accordingly, the particular arrangements disclosed are meant to be illustrative only and not limiting as to the scope of the invention which is to be given the full breadth of the claims appended and any and all equivalents thereof.
