TMS



TRACK MANAGEMENT SYSTEM (TMS)

Track Management System (TMS) is a computer aided system which will integrate  various inspection data, track structure data, track features data and gives various decisions support systems and Management Information Systems (MIS).

 

Minimum hardware configuration for running the TMS is PCAT-386 and run time version of ORACLE RDBMS VER. 5.1 is also required for the same limited module of Track Management System has also been developed which contains almost all the decision support systems and MISs and this can be run even on PC XTs. For running the limited module, no special application software is required and executable files can be directly run on the DOS platform.

A. SCOPE:  

This specification covers the functional requirements of Centralized Traffic Control (CTC) / Traffic Management Systems (TMS) for carrying out following two categories of functions: ·

Centralized Operation of Signalling Systems for a large section encompassing multiple interlocked stations. ·

Centralized Real time Monitoring of Train Traffic for enabling efficient decision making for traffic control of large section.

There are many secondary functionalities have emerged that enable efficient control and passenger information systems.  

It is seen that, on Indian Railways, some Zonal railways (CR & WR) have implemented TMS carrying out only second part (monitoring of train traffic) of functions listed above. Henceforth, in this specification, CTC & TMS will be used interchangeably and they would mean same thing that carries out above mentioned two major categories of functions.  

B. Functional requirements:  

SYSTEM RESPONSE TIME:

The system shall be so designed so as to achieve the overall objective of providing real time information related to train operation in section proposed to be covered by TMS. The following response time shall be considered in design.   

  1. The response time between a change of state at a way side station and its display at central control shall not be greater than 2 Seconds.  
  2. The time taken between initiation of a query relating to data /result /report and its response on terminals shall be as fast as possible.   

The system broadly envisages the functionality as described below: 

1.0 LIVE INDICATIONS  

1.1 Live Indication in Control office (On Overview Mimic Indication Panel):    

i. Overview Mimic Indication Panel consisting of Display panels shall be provided to display an overview of the monitored rail network covered by TMS.

ii. The Mimic Indication Panel shall display all track circuited lines and all interlocked signed aspects of track layouts of station & auto sections of section monitored by TMS.

iii. The Overview Mimic Indication Panel unit shall display important indications of wayside stations panel, aspects of auto signals, status of auto sections track circuits and LC gates, etc.  The panel will also provide alarm indications of failure of points, signals, track circuits etc., as the case may be. Less significant objects/indications like sidings etc. will not be shown on the overview panel.

iv. The Overview Mimic Indication Panel unit shall display the occupancy of various track sections along with the train description. (Train ID box shall indicate different colours for suburban, Long distance, Goods & other types of train).  In case train number is not keyed-in, the same shall be shown as flashing unknown train identifier mark along with Non-Described Alarm (NDA).  Alarm will stop as soon as the train number is keyed in by the controller / way side ASM.

v. If a train has stopped at any point enroute for more than the prescribed minutes, an alarm should be raised to draw attention of the controller.

vi. It should be possible to update changes in yard layout through software from the maintenance terminals without any requirement of changing in hardware. The uploading time of software changes should be minimum and it should be possible without complete shutdown of the indication system. 

vii. It shall be possible to show the temporary speed restriction by showing the track lines with different colours or by showing the Tagbox or by any other means.

viii. The various stabling lines (Track circuited) of station yards are not to be shown on Mimic Panel. It shall be possible to display the information of occupation of stabling lines whenever required by giving suitable commands through controller terminal. 

1.2. Live Indication to Train controller terminals  

i. Each section control position can log in as pre-defined section controller and the display will then change for the section required to be controlled by that controller.  

ii. Section controller / Chief controller terminals (work stations) will consist of 3 LCD/LED monitors each of size of 21”/54 cm. All the features available on Mimic panel shall also be available on these terminals.  

iii. All terminals shall be able to display complete information of yards covered by TMS with details of track circuits, signals, Points, LC gates etc. Any failure of signaling system on any of yard should be available in audio & visual form to draw attention of controller. It should be possible to acknowledge and stop the audio alarm of failures.

iv. On line display of train movements shall be available on the terminals with train details such as Train No., load, Driver, Guard, Type of Suburban, etc.

v. Ordinarily it should show complete yard at a time including all Track circuited and Non-Track circuited lines.   Big yards can be divided into many parts, with provision of selecting any one part on a screen with facility of scrolling to see the full yard on one /more screens.  

vi. If train identification has not been entered by the train arrival / dispatching station, all  the Section Controllers shall have facility for entering it on getting NDA.

vii. It shall be possible to view train graphs. The train graph shall also cover advance charting showing traffic blocks. Train graph lines/Train ID box should have tag with detail of train, crew etc.  

viii. In case of unusual events and delays of trains, system will prompt the controller to enter the reason and other details in the prescribed format.

ix. The details of occupancy of berthing lines and sidings shall also be available on the terminal.

x. The train controller terminal shall be capable of running the Decision Support System (DSS) feature.  

xi. The crew details available in the system shall also be available on the terminals provided with Sr. DOM, CHC, Dy. CHC, etc. apart from being available on SCOR & ASM work stations. xii. All the required traffic alarms shall be available on these terminals.  

1.3.  Live Indications on terminals provided with staff at Important Junction stations /Car shed/ lobbies etc.  

i. All stations with passengers’ services shall be provided with workstation type terminals having capability of graphic display and remaining other stations, carshed and lobbies will be provided with industrial Grade PCs.  

ii. ON Line display of train movements (including description) along with layout and status of signaling will be available on workstations as available on section controller’s terminal.

iii. It should be possible to input TRAIN ID in 8 digits from these terminals along with other information such as destination, platform No, rake details, crew details etc. System will generate an audio & video alarm on ASM’s terminal as well as in central control, if train ID has not been filled by concerned station Master. 

iv. It shall be possible to query the central control regarding details of trains, cancellation, rescheduling, delays, diversions etc, either through menu driven commands or through SQL commands.

v. Details of rakes stabled on sidings at concerned station shall be displayed. vi. Whenever a train / rake leaves / enters the control area or is put out of the system by placing it in the siding or sending it to car shed should be automatically registered by the system. In addition to this ASM shall have facility to delete / enter such trains.

vii. Flashing messages / instructions from the controller and information about expected arrival of next two trains on each line, cancellation and diversion of trains shall be displayed. 

2.0 TRAIN DESCRIBER SYSTEM  

i. It shall be possible to associate a train with an alpha-numeric mark called a train describer tag.

ii. A train describer tag shall be unique consisting up to 8 alphanumeric characters displayed in a text box.

iii. The train description tag shall track the train in sections controlled by TDS.

iv. The train describer system shall be able of automatically assigning train describer tags from a train number queue to trains originating/terminating at the stations covered by TDS.

v. The operator and / or the ASM at entry point shall be able to edit the train describer tag queue.

vi. The operators and / or the ASM at entry point shall be able to stop the automatic assigning of train descriptions tag as mentioned in para iv above temporarily.  

vii. The color of the train describer tag box shall be different for different type of trains.

viii. The train describer system shall be able to register in the Software & display following abnormal conditions

a. single track circuit failure

b. faulty position of points

c. change in direction of a train

d. division and joining of trains

e. unidentified trains

f. trains passing a signal showing a stop aspect

g. more trains on the same track circuit

h. Wrong marking of object/functions.

ix. Abnormal disappearing of train describer tag shall generate an alarm and display in different colour.

x. The train describer system shall be able to handle the commands for

a. Insertion of a train describer tag on a track or at a signal, which shall be assigned automatically to the train occupying the track.

b. Moving a train describer tag to a different location

c. Renaming a train describer tag.

d. Exchanging one train describer tag with another train describer tag.

e. Deleting a train describer tag.

xi. It shall be possible to find the location of trains by search command.

xii. It shall be possible to view list of trains in the train describer system with following criteria

a. All trains

b. Only operator identified (known) train.  

c. Trains in a given direction

d. Trains at or between specific station(s)

e. Unidentified or delayed or cancelled trains

xiii. The train describer system shall send log records of the event logged including the following information to data base 

a. Movement of train descriptions (track to track details with timing)

b. Operator’s commands to the train describer system.

c. System will display crew details from the detailed link available in crew management software, on query from various terminals of controllers & lobbies.  

3.0 AUTOMATIC ROUTE SETTING (ARS)   

i. The automatic route setting feature shall be possible to be provided for identified stations/routes/sections

ii. The ARS system relieves the operator from repetitive route setting tasks for the trains at above stations.

iii. The system shall execute the commands according to timetable with manual override facility.

iv. System shall have online editing facility to enable the operator to reschedule trains, if required.

v. The system should permit operator to receive/ dispatch any unscheduled train manually.

vi. ARS System shall make use of time table processor and train describer subsystems to carryout automatic route setting for ARS enabled routes. 

4.0 INTERFACES WITH PASSENGER INFORMATION SYSTEM (PIS)  

i. The TDS will drive the PIS available on the stations by sending data telegram to station terminals. This in turn will drive the PIS i.e. Indicators, VDUs, Announcements system etc, with an option of automatic or manual mode. However at way side stations without crossover, operator less PIS should be provided.

ii. The interface should drive existing centralized announcement system to facilitate automatic announcements actuated by passage of trains.  

iii. All the future passenger display/ information systems after introduction of the TDS shall be driven through the central control.

iv. The interface should also drive the existing Indicators.  

4.1 Indicator Boards on Platforms & FOBs  

i. With the introduction of Train Describer system, existing microprocessor/ EPROM/ Diode Matrix based indicator system at various stations shall be directly driven from the Central control/ TDS system. The data telegram will be sent to existing indicator system by TDS.

ii. At the way side stations without crossover, indicators should be driven by TDS without help of operator.

iii. Additional information of expected arrival of train in form of countdown in minutes shall be provided. The countdown time in minutes should be reckoned based on distance of track circuits from the station and passage of trains on that particular track circuits.

iv. As far as possible, indicators shall be driven through station TDS terminals in addition to driven by existing PC.  

4.2 VDU monitors at Stations   

i. High resolution colour video monitors of size 29” shall be installed at the entrances /FOBs or other suitable locations decided by Railways.

ii. Monitor will display details of 4 trains sequenced as per arrival time.

iii. Information to be displayed will consist of alphanumeric characters in three languages (Hindi, English & Marathi) 

iv. VDUs will be driven through ASM terminal & information displayed on VDUs can be monitored on ASM terminal.

v. It should be possible to show video clippings through station terminal.

vi. It shall be possible to send Scrolling Message/ full screen message on the Video system

4.3 Central Announcement (CA) system and way side station announcement system  

i. Presently PC based Central Announcement systems are available at many mainline & suburban stations for announcing Schedule/expected arrival of Mail express trains, courtesy messages and emergency messages. Other announcements are made on microphone. The type of announcements are as under ·

  • General (slogans/public awareness/messages) ·
  • Corridor wise late running ·
  • Unusual /disruption ·
  • Rescheduling, cancellations of trains ·
  • Special train services planned

ii. The above CA system shall be integrated with TDS so that it can directly send data telegrams to station PC terminal to trigger voice file stored in PC to make announcement of schedule, expected arrival / departure of Mail/express trains.  

iii. All the way side stations are provided with PC based announcement system. TDS shall transmit data packets to trigger the voice file stored in memory of PC for auto announcement prompted by passage of the train.

iv. Facility for auto announcement in case of diversion / cancellation of train shall be made available by TDS.

v. Scope of work may include modification required in hardware and software of present CA system at identified stations.  

4.4 Additional Passenger information system (PIS) information on ASM PC  

i. The existing PIS system is PC based provided in station office which drive the indicator, Video and announcement system. The additional PIS provided by TDS shall run on this PC/ASM terminal.

ii. It shall be possible to transfer maximum of two trains per platform.

iii. On transfer of third train, after departure of the first train, the second train should become first and the newly transferred train should take second place on the list.

iv. It shall transmit information about the first train of the list to serial port of driver of external indicator provided on each platform.  The format of this data shall be ASCII and  the details shall be given by Railways

v. The real time PIS driven by TDS should have facility to incorporate traffic block & other disruption in train services. Based on above TDS shall automatically change the platform time table information for that day and CA & indicator system will be driven accordingly.

vi. The existing coach guidance indicator system (available at mainline stations) should be integrated with TDS. It shall also be possible to send coach information (coach guidance information) about mail/express trains on the Video display.

vii. It shall keep log of all the messages sent for display, trains transferred/departed from system for maximum of 7 days.

viii. It shall be possible to edit the train information of the timetable database simultaneously when the train is being displayed on indicators.

ix. The system should be capable of driving any additional Voice System connected to the network.  

x. The system shall be able to trigger various announcements supported by the Voice System. 

xi. Once the connectivity is available from TDS, it shall display EIM (Expected in Minutes) for the trains on the respective platform.

xii. The system shall be able to query the TDS Server about the trains standing on the station for any given train or rake ID.

xiii. It shall be possible to send message from TDS controller to ASM terminal and station VDUs.

xiv. The system shall keep log of all the messages received from the TDS.

xv. It shall be possible to direct a station terminal to go to Centralize Announcement mode or Local mode or TDS driven mode

5.0  MANAGEMENT INFORMATION SYSTEM  

5.1 MIS Edit  

i. The system shall allow user to enter any free text tag to be associated with any train. ii. The system shall allow user to create a unusual report, describing a failure with the department that it belongs to and the trains that were affected by it.  

5.2 MIS REPORTS  

i. The system shall generate report for trains run delayed by prescribed reference.  

ii. Based on the events logged and the operator input, the system shall generate specified/following reports  

  • Various Train control charts
  • Various Punctuality reports
  • Bad runner report
  • Actual Rake Link Report
  • Rake Composition repory
  • Rake Maintenance/overhauling reports
  • Suburban punctuality analysis report in suitable format. This may be daily, weekly or monthly as per prescribed format.
  • Analytical report of various unusual occurrences, i.e. signal failures, OHE break down, rake failure etc. This can be again generated on daily, weekly or monthly basis on prescribed format
  • Analytical report of crew link/ utilization.
  • Analytical report on rake link utilization.
  • Total traffic blocks granted / refused along with locations, time blocked, time cleared
  • Sectional running time taken by trains of any ID.
  • Delay report of trains along with train nos., delayed time (at stations) etc.
  • Difference between actual and scheduled running time in tabulated as well as in graphical form  

5.3  Train Graph  
The train graph, as specified below, should be made available on the terminals with Sr. DOM, DOMs, CHC, Dy. CHC, SCOR -  

i. The system shall plot historical train graph for analysis.

ii. It shall plot time on X axis and stations on Y axis.

iii. It shall be possible to show schedule time and the actual time in the same graph but with different color. 

iv. It shall be possible to show mainline trains /Suburban /Goods/Spl. trains in different color.

v. It shall be possible to select the direction of train and the line.

vi. On clicking / selecting a particular train graph it should give complete information about the train details viz. train no, crew information, rake details etc.

vii. Advance charting: In case controller defines the traffic block on particular line for particular time, system should be able to prepare train graph showing advance/predictive movements of available trains in particular section in different colours.

viii. It shall be possible to deduce average speed of trains between any two stations.  

5.4 Simulation studies on Simulation terminal  

i. Separate terminal shall be provided for simulation studies & training purpose. The replay of log, time table editing, editing of train graph etc. shall be provided on this terminal.

ii. It should be possible to simulate and observe the effect of various parameters such as Speed restrictions, Change in yard layouts etc. on sectional density (capacity) and to produce train graphs in pictorial or tabular form. Simulation of the effect of addition / deletion of a signal shall also be possible. The parameters shall be decided in consultation with the Railways.

iii. Simulation of train movements:- Train movement shall be simulated by occupying & releasing track circuits on sections in accordance with movement of trains. The replay of log with predefined begin & end time.

iv. The simulator shall work with the same data as the on line system or separate Master data can be kept on the system  

v. The simulation can take place in real time or in reduced / accelerated time scale.

vi. The system should be capable of simulating the existing time-table and compare it with actual running on periodic basis to create Management Information to identify any shortcomings in the system / time-table.   

5.5 Crew Management system (CMS) for suburban trains (On line)  

Crew Management system must be closely integrated with TDS to reap the benefit as below.  

i. Crew management software system shall be provided wherever required.  

ii. Crew management details shall be fed by lobby staff separately for each Motorman/loco pilot & guard. The database will have all the information related to personal & safety of motorman & guard.

iii. Software will prepare detailed link program based on data fed by lobby staff for crew (separately for LocoPilot/motorman & guard).

iv. It shall be possible to change LocoPilot/motorman/ guard booking details for next 24 Hrs.

v. Daily report of planned booking and actual booking of crew shall be possible.

vi. Monthly reports of motormen/guard in terms of KM & duty hours, individual date wise shall be possible based on real time data from TDS.  

vii. It shall be possible to calculate running allowance of crew based on real time data from TDS & manual data for balance section.  

5.6 Interfacing of TDS with Crew Management System(CMS)  

i. TDS will be suitably interfaced with this module to take automatically the crew details from the detailed link table or the online data fed by lobby staff.  

ii. TDS based on this information will show online position of motorman/ guards on train details query on controllers terminals.  

iii. The online position of crew shall be available to lobby staff either on TDS terminal of lobby or separate crew management terminal having CMS loaded.

iv. In case online position not fed by lobby staff, TDS will take data from detailed link table with suitable tag that data is from link table. It shall be possible to change the name of motorman / guard when prompted to do so by server.

v. It shall be possible to get query based details of crew like running details, etc.  

5.7 Interfacing with OHE SCADA system (optional)  

i.  TDS will take OHE shut down reports from existing OHE SCADA system.

ii.  The various power block granted and their duration from SCADA system.

iii.  OHE failures and tripping details of FP, SP and SSP.  

5.8  Time Table builder and editing (offline)  

i. Time table builder software system shall be provided for identified sections.

ii. Data base of infrastructure like signal distances, permitted speed of trains, Signal interlocking, track circuit lengths etc, required for generation of time table shall be provided on main/simulation server or on separate server. Based on this data, time table builder, off-line software, shall prepare a time table. Time table so generated can be modified /edited offline and after testing of same on simulator terminal, can be loaded on the TDS system.  

iii. Time table shall be able to give section wise train graph.  

iv. Suitable interfacing shall be provided with TDS so that related data can be taken from timetable builder to TDS or vice versa.

v. It is envisaged that the Time table builder tool shall be available on a simulation terminal to aid the operator to prepare timetable.  

vi. It shall also have simulation facility to find any Headway, crossover and platform conflicts in the time table  

vii. The time table builder module shall  have following features  

a. The system shall have a stand alone Windows based tool to do the timetable planning in the offline system.

b. It shall be possible to edit timetable.  

c. It shall be possible to Create/Edit/Delete a train service.

d. A train service shall have following attributes

i. Train Id

ii. Type of Train (Suburban , goods , mail etc)

iii. Stopping pattern telling which station it stops at

iv. Running section telling which path it takes  

v. Time and platform detail at each stations

vi. Length of train in number of coaches. (9/12)

vii. Creating train Id if required.  

e. It shall be possible to use train service template while creating a new train

f. It shall be possible to mark the rake link for the train service

g. It shall be possible to define trains for a specific day of the week.

h. It shall be possible to define holidays for a given calendar year.

i. The time table compilation and proving system shall calculate and generate number of train trips and train kilometers for all time table trains.

j. It shall be possible to transfer the timetable to TDS by authorised user only

6.0 TRAIN GRAPH REQUIREMENTS FOR TIME TABLE BUILDER  

i. The train graph shall draw time in X-axis and stations on Y-axis

ii. The train graph shall have facility to show different train types in different color

iii. It shall be possible to select the direction, line type and of the day for which the graph needs to be plotted

iv. It shall be possible to take printout of train graph on a printer/plotter

v. It shall be possible to take train frequency  reports from the timetable database  

7.0 LOG AND ALARM SYSTEM  

7.1 EVENT LOG

i. All important events (command, indications, errors, system information etc.) shall be logged in a log SQL database for later printing and analysis.  

ii. Log database shall be separated into 3 sections; system log, short term log & long term log. The time span of log will depend on the size of database and intensity of log events.  

7.2 Replay of Event log   

i. The replay function shall show an history of events that has happened earlier in the TDS system, The replay of train movement shall be either on simulation terminal and /or on Mimic indication panel.

ii. When replay shall be started, the dynamic status for infrastructure, train number, system pre test and alarm list as well as the pictures on the screen shall be initialized.  

7.3 TRAFFIC RELATED ALARMS  

i. Vital traffic operator related alarms should be

a. Failure of any Signalling gear in the entire section under scope.

b. Routes not released after passage of train.  

c. Train not described alarm (ND Alarm).

d. Train waiting for more than a minute at signal not taken off should be alarmed and logged.

e. Train stopping at off signal for more than a minute should be alarmed.

f.  Any other unscheduled train stoppage shall be alarmed.

g. Any unscheduled train detention in excess of prescribed time shall be alarmed.

h. Any OHE tripping should be alarmed and logged.  

7.4 NETWORK RELATED ALARMS  

i. All alarms not directly related to traffic operations shall be considered to be Network related alarms.

ii. These shall be flashed on the maintenance terminal only.

iii. These can be arranged in priority levels in consultation with the Railways.

iv. Failure of Network Communication / inability to access any of the nodes, defective terminals, and hardware & software failures shall be flashed.  

8. DECISION SUPPORT SYSTEM (DSS)  

Two types of DSS are envisaged from the system

8.1. Based on the constraints & logic given by Railways, system should give optimised decision to admit or dispatch particular train at entry/exit points of a particular section.

8.2. Train running at the time of disruption: System should suggest effect of disruption on train service. Based on constraints, facilities & logic provided by railways, system should give solution for running of trains, diversion, cancellation or regulation of train services. The data related to availability of nearest crossover, priority of trains, duration of disruption, type of failures, other available paths etc. on the basis of order of priority given by operator and based on criteria fed in the system, TDS will give appropriate solution in the form of train graph or tabular form. The system may suggest more than one alternative and its effect. The Section Controller will select the suitable solution. This solution must integrate with functioning of all sub-systems connected to TDS.  

9.0 SOFTWARE DETAILS  

1.  All software shall be based on open system concept and shall be independent of type of processor or hardware platform.

2. It shall be based on co-operative or client server processing architecture with distributed processing logic.

3.  Following modification should be possible without modifying the source program.  

i. Facility to add users with password authentication.

ii. Facility to delete an existing user.

iii. Change the priorities allocated to users.

iv. Change areas of jurisdiction.

v. Change various particulars of a train.

vi. Change the rake number vis-à-vis train number.

vii. Introduce new alarms with varying priorities.

viii. Changing the details of any node.

ix. Introduction of new nodes.

x. Create, modify and delete sectional area on the train graph display.

xi. Change the various colours allocated for various trains tag.

xii. Change x & y cordinate scales.

xiii. Menu and contents of formats on ASM terminal.

xiv. Addition & alteration to the screen formats on VDUs at entrances.

xv. Incorporation of additional infrastructure such as yards, sidings, new lines etc.   

10.0 INTEGRATION WITH MOBILE TRAIN RADIO (MTRC) SYSTEM  

i. A Mobile communication may be available between the motorman/Loco pilot/guard & the section controller.  

ii. TDS shall send the Train ID/rake details file for auto registration of Mobile cab radio.

iii. It shall be possible to send the emergency caution order in the form of SMS through his TDS/ MTRC terminal.

iv. It shall be possible to generate SMS message for the drivers of trains stating name of next halt station for that particular train. This SMS message shall be transmitted by MTRC terminal.   

11.  CTC FUNCTIONS (optional)  

When this functionality is required by user, it shall have following additional subsystems and their functionalities as defined below: 

i. Centralized operation of Signalling along the section: Section controller should be provided with  control facilities that should enable him to control signals, points and other signal & control equipment along the section  

ii. Remote Control of wayside interlocking: When interlocking systems are distributed along the section at various stations then remote control system (working on dual redundant communication channel) shall enable section controller at a remote place to set/cancel routes.  

iii. Degraded Mode operation: Facilities should be provided to enable train operations under degraded modes of signalling

*****