Geographic train position information system

Transcription

1 Geographic train position information system K. Kapila&S. Reusche Booz Allen & Hamilton Inc. 707 Ca/z/brm'a (3We JJOO) San Francisco, CA Abstract This paper describes the development, functionality, and implementation of a Geographic Train Position Information System for the San Francisco Municipal Railway (MUNI). The system has been put in place as a cooperative effort of the consultancy Booz Allen & Hamilton, the private supplier NextBus [1] Information Systems, and MUNI. This initiative was undertaken as a part of a larger overall Booz Allen project to improve MUNI operations and quality of service, known as the MUNI Improvement Project. The primary goal of this system is to improve real time information flow to railway operations and management staff, with other benefits being improved public information, reliable historic data and decision support. At the time of writing, the system as a whole has been implemented in its core elements, i.e. vehicle tracking equipment installed, tested and fully functional, with graphical displays developed and deployed in various locations in the field. Further secondary elements and uses of this system are envisioned and will be deployed in incremental phases over the coming year. 1 Introduction 1.1 The MUNI situation: Identifying the need One of the unique elements of the San Francisco Municipal Railway (MUNI) is its multimodal nature, i.e. it's trains run not only underground in a dedicated underground subway, but also aboveground sharing street space with vehicle and

2 Computers in Railways VII pedestrian traffic. This arrangement has advantages in terms of reducing capital costs and increasing flexibility, however it complicates railway operations because of the variables associated to running alongside traffic and the integration of two modes of operation: automatic (subway) and line of sight (street). One of the first deficiencies identified by Booz Allen upon commencement of the MUNI Improvement program was the lack of timely and reliable information regarding vehicle operations. This was aggravated by the multimodal nature of MUNI. For street running, the information was not timely enough as it relied on voice communication from inspectors on an overused radio channel. In contrast, though subway information was available in real-time from the train control system, this was not adequate as many problems were associated to the entry of the trains to the system, which the ATCS (Advanced Train Control System) could not predict. In light of the above, it was clear that an improved operational data flow to the MUNI operators was required. Ideally, the operators of the railway should be able to know where any trains were, in both modes, in an integrated fashion. This information needed to be provided in as timely a manner possible, in an intuitive, easily discernible and reliable format. Finally, as practical constraints of the Booz Allen contract, the information needed to be provided at a reasonably low cost, and within an accelerated time frame (i.e. less than a year). 1.2 Solving the problem technologically To meet the above mentioned requirements, in particular reliability, time frame and costs, certain design and technology decisions have been made: To reduce the overall cost and to provide high availability, scalability and maintainability only commercial off the shelf (COTS) products have been used to implement the system. To collect the above ground data in a reliable fashion without building a whole new expensive infrastructure of detection devices, the existing and established Global Positioning System (GPS) has been chosen. The position information is made available on the Internet, which was the fastest way as no infrastructure had to be built. As a result any user over the world can access this information via any browser. No client software has to be installed. Finally the link between the trains, that receive the position information via GPS and the Server that provides the connection to the Internet is established via a private digital cellular network (PDN) as no capital funds were available to build a dedicated communications system.

3 Computers in Railways VII System architecture 2.1 Obtaining aboveground train position information A number of solutions were looked at in terms of acquiring reliable train position information for the street running portions of MUNI. MUNI had an existing system based upon signpost transponders located throughout the city. However, this system was badly maintained and ran on antiquated mainframe hardware with associated reliability problems. A second option considered was to install a parallel data radio communications system, which would cover the aboveground train lines and periodically poll or receive updates from the MUNI LRVs. This option was again discounted for practical reasons of capital costs and the inability of system implementation within the project time frame. With the practical and time frame considerations in mind it was evident that a significant implementation of new infrastructure was not feasible. Therefore, existing available infrastructure needed to be leveraged wherever possible. For obtaining real-time train position information, the obvious choice was to use Global Positioning System (GPS) data. GPS position data is readily available with sufficient position accuracy (to 100 metres) and at significant cost savings as no infrastructure hardware or custom software needs to be implemented. GPS receivers are commercially available at low cost and with excellent coverage. With GPS being selected as the suitable localisation source, the remaining decision was the choice of wireless communications used to centralise the train position information from the tracked vehicles. A number of existing wireless networks were discussed, each with varying data rates and coverage areas. The technology chosen was Cellular Digital Packet Data (CDPD). Table 1 illustrates the advantages and disadvantages of using CDPD. Advantages Coverage in the majority States metro areas of United High quality over the air data rate available (1 9.2 kbps) Receivers available of the shelf and at low costs from multiple suppliers Service is available from multiple competing service providers. Disadvantages Monthly operating costs can become prohibitively high at high polling/reporting frequencies ( > twice per minute). Table 1: Advantages/Disadvantages of CDPD

4 1030 Computers in Railways VII With these parameters in mind, the polling/reporting frequency of the tracking units has been initially set at approximately once per two minutes. At this rate the train position is updated sufficiently and yet does not cause undue monthly CDPD charges. Once these technologies were decided upon, the private company NextBus Information Systems [1], were retained to install tracking units upon the MUNI vehicles. The specifications for the units installed upon the MUNI Light Rail Vehicles (LRVs) are attached in Appendix A. 2.2 Integrating the subway data As mentioned earlier, a significant part of the MUNI system is running under ground. As soon as a train enters the subway the GPS system is useless to localise the train, as the receiver cannot detect the satellites anymore. To overcome this problem, the train control system is used to locate the trains within the subway. The whole MUNI System is signalled with standard wayside signals. However, the subway has recently been upgraded to the Alcatel moving block Advanced Train Control System (ATCS) to increase performance. The train position information needed to control the trains, is transmitted from the Vehicle On Board Control system (VOBC) via an inductive loop communications subsystem that is installed on the tracks. This data gets evaluated in the Vehicle Control Center (VCC). total Area Network Train Postiorting Setrwer Bata Feed omp</fer Figure 1: The subway position access

5 Computers in Railways VII 1031 The operator has a graphical user interface (System Management Center SMC) to enter routing commands, etc. The SMC will communicate these commands back to the VCC, which transmits them to the vehicle via the inductive loop again. The SMC is permanently logging the system data. This data stream is finally taken to get information about train positions in the tunnel. A Data Feed Computer (DFC) located at the MUNI Control Center is interfaced to one of the non-vital SMC's via a standard serial connection. At a speed of 9600 Baud, the systems logging data is send from the SMC to the DFC. This data is parsed by a JAVA application that runs on the data feed machine. From all the system data only the relevant train position data is extracted. This data is then sent to the Train Position Server via the Internet. At the Train Position Server, the subway data and the surface data then get merged. 3 Gateway to the Internet 3.1 Implementation Once the position data is received and available for further processing, it is edited for the graphical presentation to the end-user. As the information gets distributed over the World Wide Web, the graphical user interface (GUI) is developed in JAVA. Because of JAVA'S ideal attributes for developing Internet applications (platform independent, reliable and secure), it was chosen to develop the user interface. Two implementations of the GUI for the train position information system have been implemented, one as an applet and one as a stand-alone application. The applet is a small program that is executed by a JAVA enabled web browser, while the application does not need the help of a web browser and can be executed from the command line. Both, the applet and the application run on all supported platforms, it doesn't matter whether the end-user is working under Microsoft Windows, Solaris or OS/ The applet The first version of the graphical user interface is an applet that is accessed via a web browser. When the user reaches the homepage of the MUNI train information site, the applet is automatically downloaded to the local hard-drive and then executed. The applet receives the train position information and generates the trains as little icons on a scalable map. The train number is shown close to the icon. Train positions are updated every time when new position information is send from the server. Colour-coded lines on top of the scalable map of San Francisco represent the tracks. By selecting the different Lines (J, K, L, M and N) the user can reduce or increase the amount of information that is shown. If a Line is not selected, the

6 1032 Computers in Railways VII associated trains and tracks are faded out. Additional information about a train is displayed when the user positions the cursor over the train icon. The information includes the destination station, source station, overhead towards the preceding train and the time that has passed since the train last reported its position. Figure 2: The applet in a browser window The user menu provides zooming functions like zoom in, zoom out and zoom to vehicle. A find function allows the user to enter a train number and the display will point to the position of that particular vehicle. To check the path that a train has taken, the show trail function marks the path that has been followed by the selected vehicle. 3.3 The application While the applet is downloaded automatically via a web browser, the stand-alone application of the graphical user interface must be installed manually. The local installation has the advantage that less memory is used and that the execution is not dependent on a web browser. Three different zoom levels are provided. The user has the possibility to fade out the trains that are in the yard. The trucks of the MUNI Inspectors are shown as well, so that the management can see at which points the Lines are regulated.

7 Computers in Railways VII 1033 To scroll to different locations, the user is able to move the viewpoint by dragging the map in the wanted position. Future developments include the prediction of arrival times for the stations. This will be of particular importance to the passengers that use the information system. Before heading towards a station, the passenger will be able to check the current status of the system and leave the office or home just in time to catch the next train. In cases of delays, he/she will be informed in advance and can avoid waiting times. Figure 3: The stand-alone application 3.4 Distribution So far displays of the Train Position Information System have been installed in the Muni Control Center and in the terminal subway station for line management. Additional installations are planned at each portal to the subway and at all terminal stations. For public information, a prototype display has been installed at Embarcadero station platform. There is a plan to equip all subway stations and to open access to the internet site to the public.

8 1034 Computers in Railways VII 4 Conclusion The implementation of the Geographic Train Position Information System for the MUNI Railway in San Francisco has shown how a reliable and extensive asset localization/information system can be installed in a timely and inexpensive manner by using modern technologies. Once implemented, the system helped to increase the reliability of the whole railway system as the controler/operator had the ability to obtain the overall system status from anywhere just by a mouse-click. Problems that may lead to congestion could be noticed in advance and the knowledge of the position of any train in the system greatly supports the dispatcher in making his decisions. Future applications are not only foreseen for passenger transit systems but also for freight traffic, as it would be of great interest for the operators as for the clients to have an overview of where their assets are at any point in time.

9 Computers in Railways 171 Appendix A 1035 The Tracker Unit Specifications Weight- Size: Status LEDs: <21b. 6.8" x 3.3" x 2" Power GPS Status Channel Block Acq. Errors Link Status RSSI Transmit Receive Network Registration Integrated TCP/IP Transmit Power Transmit Receive RF Protocol Over-the-air Data Rate Serial Protocols Full Duplex 600 mw max MHz MHz CDPD 1.0, Kbps AT Commands, PPP, SLIP 50 Ohm TNC Housing: Pins: SV6-CM3, SMB Connector Requires antenna with pre-amp. RS-232 DB-9F ,200 bps Multi-protocol Input Voltage Input Current Typical Receive Typical Transmit 9 VDC to 30 VDC.16 to.65 Amps VDC VDC Operating Temperature Range -30 C to 70 C With transmissions limited to a 10% cycle above 60 C Humidity: 5% - 95% Non-condensing duty Software Hardware 1 year updates & feature enhancements 1 year parts and labor, extended warranty available These conditions have been simulated to the extent practical. See [2] for status on the GPS receiver. A slight problem exists with the model used, the SveeSix PLUS During the 3 days prior to WNRO, units that are cold started may experience degraded performance. As the NextBus tracker has almanac memory, this should not occur unless a unit is replaced from cold storage in the three days prior to August 21, The problem will correct itself on August 21, 1999 regardless. References [1] : Background information [2] : Y2K readiness of the GPS receiver