www.pst.informatik.uni-muenchen.de/dagstuhl -> www.pst.informatik.uni-muenchen.de/dagstuhl/
Bay Area Rapid Transit District Advance Automated Train Control System Case Study Description By Victor Winter (2615), Raymond Berg (2615) and Jim Ringland (8112) All from Sandia National Laboratories Objective This document contains an informal description of a portion of the Advanced Automatic Train Control (AATC) system being developed for the Bay Area Rapid Transit (BART) system. BART provides commuter rail service for part of California's San Francisco bay area. Specifically, the informal specification given below focuses on those aspects of BART that are necessary to control the speed and acceleration for the trains in the system. Other aspects of BART control such as communication error recovery, routing (via switches) and right-of-way signaling (via "gates") are largely ignored. The scope of this case study is narrower than the AATC project as a whole, but within this narrowed scope, enough detail has been supplied to give a sense of the level of complexity involved. The overall objective of this case study is to construct a system (software or otherwise) within the infrastructure given, that can control the speed and acceleration of trains in the system subject to the various constraints that are described in the specification. In particular, it is not the purpose of the case study to criticize the infrastructure. You are asked to present your research in the context of this case study. Specifically, how would your work positively impact the construction of the speed and acceleration control system? Also, since the purpose of this case study is to provide a context for presenting your research, it is perfectly acceptable to make simplifications when necessary. And finally, the informal specification given will no doubt contain ambiguities. Again, given that this is an academic exercise, feel free to resolve any ambiguities in whatever manner seems most reasonable to you.
BACK TO TOP General Background on the BART Train System It is not assumed that those participating in this case study have an extensive knowledge of train systems and terminology. This section gives a general overview the BART train system. BART provides heavy commuter rail service in the San Francisco Bay Area. On a typical work day it serves around 250,000 passengers. During commute hours over 50 trains, most consisting of 10 cars, will be in service. Cars are driven by electric motors powered by a 1000 VDC, "third rail." On-board operators have a limited role in normal operations. Operators signal the system when the platforms are clear so a train can depart a station. More importantly, operators trouble-shoot problems, and can operate trains manually (at low speeds) when there is a problem. The system operates most of the day, but there is some maintenance time available at night. Trains run on the BART system from 4:00 AM, when the first trains leave the yards to position themselves for the day's service, until about 1:30 AM, when the last trains return to the yards. With a few minor exceptions, the BART system consists of double track: one track going one direction and one track going the other. At the end of the line, the front and back controllers are redefined and the train goes in the other direction. gif (20885 bytes) As the map shows, the lines feed from points north, south and east into San Francisco, with the critical link being the section from Oakland to points west where four lines share one pair of tracks. To serve more passengers, BART needs to utilize this section more efficiently. Adding new tracks to this segment -- in a tube under the bay and underground in the heart of San Francisco -- would be prohibitively expensive. A gate can be viewed as a traffic light of sorts, where a closed gate corresponds to a red light and an open gate corresponds to a green light. Gates establish the right-of-way where tracks join or merge at switches. The purpose of gates is to keep trains from passing through switches before they are appropriately positioned. Gates not associated with switches can be used to control traffic flow.
BACK TO TOP Informal Specification for the AATC System The AATC system replaces part but not all of BART's current control system. AATC consists of new station computers, a radio communications network that links the stations with the trains (communications currently are through the running rails, with very low bandwidth), and software modifications to the front and back controllers on-board the trains. The communications system provides ranging information (from wayside radios to train radios and back) that allows the system to track train positions. On the trains, the control computer is located in the lead car. This computer controls the operations of the brakes and motors on all the cars in the consist. Most of the control computation is done at the stations; Each station controls trains only in its immediate area. A station must thus communicate with its neighbors to receive and hand-off trains. BART has asked its contractors to size the system to be able to handle 20 trains in each station's control zone. In locations where stations are closely spaced, such as in downtown Oakland or San Francisco, one computer may manage a zone that spans several stations. This case study will concentrate on one of the most critical functions of the new station computers - calculation of the speed and acceleration commands that are sent to the trains. For this study we will assume that the communications link, the on-board train control system, and station computer functions other than speed and acceleration selection work as intended. The latter include conversion of ranging data into train position estimates, managing entry and exit of trains into the system, and hand-offs between stations. The other major aspect of train control is interlocking - the management of track switches and associated signals to enter or not enter whole blocks of track. The AATC system will simply see "go" or "stop" indicators at various track locations in the system. A train should enter such a location (a "gate") only if allowed. The responsibility of the speed and acceleration selection process is to get trains from one point to another as fast and smoothly as possible, subject to various constraints. These constraints include: * A train should not enter a closed gate. This is a simplification - this case study is omitting many details with which system designers must deal. Each half-second the station computer receives ranging and - speed information (derived from tachometer data) from the trains. It uses that information to compute an uncertainty envelope for the location of each train (mean and standard deviation). For this study, assume this function works as intended and provides fully reliable inputs to the speed/acceleration selection problem. This information, along with track signal and track layout information, is used to compute speed and acceleration commands. Commands are time stamped and become invalid 2 seconds after the identified time. This time stamping (or time tagging) is done by what is called a Message Origination Time Tag (MOTT). When a train sends performance data back to the station, it attaches the time that it sends (originates) the message. When that information is used to update the position estimate, the MOTT is associated with that position estimate. The time stamp provides a measure of the currency of a position estimate. When that position estimate is used to compute a speed/acceleration command, that MOTT is attached to the command. The train then checks the MOTT before exercising a command. A train will continue to exercise that command until a new one arrives or until that command expires, 2 seconds after the originating time. If the train does not have a currently valid command, it goes into maximum braking. The control algorithms thus have to be designed so that if all communications are lost, then when commands expire and trains come to a stop, no safety violations will have occurred. That is, the stopping location of any train after lost communications, has timed out, and has come to a stop will be behind any closed g...
|
http://csua.com/feed/