research designs & standards organisation manak … · 2020. 8. 4. · event log and alarm...

Document no. RDSO SPN /212/2020 Version 1.0 Date Effective:

Document Title : Specification for Train Management System/Centralized Traffic Control (TMS)

Printed: Prepared By: JE/Signal Checked By: DD/Signal Issued By: DirectorSignal-6 of 61

RESEARCH DESIGNS & STANDARDS ORGANISATION

MANAK NAGER, LUCKNOW - 226011

DRAFT SPECIFICATION FOR Train Management System/Centralized Traffic Control (TMS/CTC)

Specification No. RDSO/SPN/212/2012 Version 0.2 (Draft)




DOCUMENT DATA SHEET

Designation RDSO/SPN/212/2012

Version 0.2 (Draft)

Title of Document Draft Specification for Train Management

System (TMS}

Authors: Ajay Verma Designation: Exe. Director/Signal-III, RDSO

Approved by Name: R.K. Jain Designation: Executive Director/Signal (co-ord), RDSO

Abstract This document defines specification for Train Management System (TMS)




DOCUMENT CONTROL SHEET

NAME ORGANISATION FUNCTION LEVEL

K.K. Singh

RDSO

Member

Prepare

Ajay Verma

RDSO

Member

Review

R. K. Jain RDSO

Approving Authority

Approve




AMENDMENTS

Specification No. Version Amendment Amendment

Details Effective date

RDSO/SPN/212/2012 0.1 - draft -

RDSO/SPN/212/2012 0.2 Updating with Comments and suggestions received from EOI participants

RDSO/SPN/212/2020 Ver. 1.0 Final draft after adding details of various sub system on the basis of input given provided by stake holders ( firms & Railway)




Table of Content

Page No.

0. Foreword 6

1. Scope 7

2. Basic requirements of TMS 7

3. Functionalities of TMS 11

4. Event Log and Alarm Management System 21

5. Decision Support System (DSS) 22

6. Field interface unit 23

7. Backup control centre 23

8. National control centre 24

9. Software Details 24

10. Technical requirement of TMS system 25

11. Video display system 29

12. Features of CTC terminals 32

13. Various interface requirements 37

14. Communication network 42

15. Integration with Mobile Train Radio System 43

16. Power Supply 43

17. Lightning & Surge Protection Tests & Requirements 44

18. Test Procedure 44

19. Marking 45

20. Documentation 46

21. Packing 46

22. Information to be furnished by the Purchaser 47

Annexure-I Indicative Alarm List 48

Annexure-II Min. Tech detail of Laser based rear projection system 51

Annexure-III Calculation of video wall Screen size 53

Annexure-IV Methodology of Integration between CTC and COA 58

Annexure-V Tech details for Lightening & surge protection 59




FOREWORD:

0.1 This specification is issued under the fixed serial number RDSO/SPN/212 followed by the year of adoption as standard or in case of revision, the year of latest revision.

0.2 Whenever, reference to any specification appears in this document, it shall be taken

as a reference to the latest version of that specification unless the year of issue of the specification is specifically stated

0.3 Abbreviation:

Abbreviation Full form

ARS Automatic Route Setting

BCC Backup Control Center

COTS Commercial Off The Shelf

CTC Centralize Traffic Control

DSS Decision support system

EIS External Interface Server

ERTMS European Rail Traffic Management System

ETCS European Train Control System

FES Front-End of communications

GUI Graphical User Interface

HMI Human Machine Interface

IXL Interlocking

JMS Java Messaging Service

LOW Local Operator Workstation

ML Main Line

NCC National control centre

NTP Network Time Protocol

OCC Operation Control Center

PDF Portable Document Format

PIDS/PA Passenger Information Display System / Public Announcement

R&P Record and Playback

TDS Train describer system

TMS Traffic Management Systems

SCADA Supervisory Control And Data Acquisition

SIL Safety Integrity Level

SNMP Simple Network Management Protocol

TSR Temporary Speed Restriction

VDU Visual Display Unit

XML eXtensible Markup Language




1.0 SCOPE: 1.1 This specification covers the functional requirements of Traffic Management Systems

(TMS) for carrying out following functions:

1.1.1 Centralized Operation of Signalling Systems for a large section encompassing multiple interlocked stations and LC gates.

1.1.2 Centralized Real time Monitoring of Train Traffic for enabling efficient decision

making for traffic control of large section. 1.1.3 Interfacing & real time data sharing with COA, Crew management system, PA

system at station, ETCS L-2/TCAS etc. 1.1.4 This system should have facility of Automatic route setting (ARS), Long route setting,

Route stacking command for avoiding repetitive operation by controller. 1.1.5 The system shall be able to generate various MIS report, train graph and detect and

manage alarms and logs generated in the system.

1.2 The system shall enable interconnection with other TMS of adjacent Sections/ Backup control centre (BCC)/National control centre (NCC).

1.3 The system shall be designed to be Modular, Robust, Scalable, and Fault tolerant and based on Open architecture.

2.0 BASIC REQUIREMENTS OF TMS: 2.1 SYSTEM RESPONSE TIME:

2.1.1 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.

2.1.2 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.1.3 The time taken between initiation of a query relating to data /result /report and its response on terminals shall be as fast as possible and be never more than 3 seconds.

2.2 System Availability criteria shall be as follows:

2.2.1 For critical functions and interfaces: 99.99% (Train Describer, Traffic control, Live

indications on control terminals and wall display, remote operation of wayside signalling).

2.2.2 For non-critical functions and interfaces: 99.97% (passenger information systems, time table management, ARS, Crew & Rake controls, MIS reports etc).




2.3 Spare capacity: 2.3.1 The systems shall not use more than 40% of the available CPU in normal operation

and shall not use more than 60% of the CPU in rush hour. Calculations shall be performed on most demanding 10 seconds periods of operation.

2.3.2 The system shall leave a minimum of 45% RAM available. 2.3.3 The disk space shall be sufficient to store 30 days of historical data and leave 50% of

free space available.

2.5 Hardware and Operating Systems: 2.5.1 The TMS must be based on proven, non-proprietary and largely distributed

hardware, software and communication protocols. 2.5.2 The hardware of the system shall be based on the proven design philosophy and

shall be fault tolerant and modular. 2.5.3 The specification of the server shall be based on latest configuration available at the

time of supply. 2.5.4 Servers shall be 19” rack mount, with 2RU/4RU maximum height or other to be

approved by Railway.

2.5.5 Servers shall be a current product offering of a server manufacturer with at least 10%

server market share at time of procurement. 2.5.6 Servers’ operating systems shall be either Windows or LINUX, in line with the leading

server market distribution.

2.5.7 Workstations shall be Windows-based, in line with the leading workstation market

distribution. 2.5.8 The TMS database shall be based on a leading Relational Database Management

System such as SQL*Server or Oracle. Good open source data management system like postgre SQL, mySQL, SQLite, maria DB, Cassandra, neo4j, Firebird, orient DB, CUBRID can also be used with the approval of Railway.

2.5.9 Data from individual sub system to be saved in common data base enabling different

user to access the data on real time basis.

2.6 Environmental:

2.6.1 Design of OCC shall be as per ISO-11064 “Elements of Good Control Room Design”.

Environmental aspects should be as per ISO-11064 part 6. 2.6.2 The servers and workstations shall comply with operation at 0-45 deg C system inlet

temperature range at sea level.




2.6.3 The system shall be provided with A/C equipment with independent control of temperature as required depending on the equipments.

2.7 Redundancy: 2.7.1 The system shall be configured with redundant communication interfaces to the

signaling system. When one communication link is lost, the system shall switchover to redundant communication links without loss of information. When a system fails, it shall switchover to its backup without loss of information.

2.7.2 Redundancy shall be built in the hardware both in the external equipment interface

and also in the TMS network equipment interfaces/ link such that no single failure will lead to shut down of the TMS functioning.

2.7.3 Server redundancy shall be based on a dual-active or hot-standby redundancy

architecture. 2.7.4 The switchover of communication links or servers shall be transparent to the user.

Server switchover shall be accomplished in less than 5 seconds upon the detection of a failure.

2.8 Interlocking Interface: 2.8.1 Interlocking interface shall be based on open, non-proprietary standards.

2.8.2 The TMS interface to the Interlocking shall be developed and assessed according to

CENELEC 50128 SIL 2 safety integrity. 2.8.3 Critical functions like operation of point/signal/level crossing with Interlocking shall be

initiated by operator at OCC and then only interlocking accepts it as a valid request. 2.9 Acquisition Protocols: 2.9.1 The acquisition protocols shall be event driven, with polling utilized only if necessary. 2.9.2 The acquisition protocols shall include time stamping and data quality coding.

Quality coding shall be propagated to the data throughout the processing. 2.9.3 The TMS shall be capable of interfacing to compliant set of external servers for

communications to remote terminal units, programmable logic controllers and other data sources.

2.9.4 Communication Status – Communication status to devices shall be monitored by

the communication server and reported as server items/tags to the TMS system. Detailed communications status shall be available via communication server error and diagnostic displays.

2.9.5 Multiple Clients – The communication server(s) shall support connections from

multiple clients for operation, maintenance and diagnostics functions. An communication test client shall be provided to allow communication servers, devices and items to be browsed.




2.10 Safety: 2.10.1 The TMS system development process shall conform to CENELEC standard

EN50128 for software for railway control and protection system.

2.10.2 TMS shall be designed and manufactured to achieve Safety Integrity level 2 as defined in the CENELEC standard EN50128 in the context of a safety hazard analysis addressing safety functions of equipment blocking.

2.10.3 Interlocking interfaces shall be based on open, non-proprietary standards.

2.10.4 The TMS and its interface to the Interlocking shall assessed according to CENELEC 50128 SIL- 2 safety integrity by Independent safety assessor (ISA).

2.10.5 Network and system security shall be as per IEC 62443-2-1: Establishing an industrial automation and control system security program. Provision of suitable Firewall and security software to be used.

2.11 Logon 2.11.1 It shall be possible to partition the TMS system on multiple levels to control

distribution of alarms and events and to provide security. 2.11.2 Partitions shall be used to determine if a particular alarm or event is routed to a

specific HMI user and to validate if that user can execute a control or function.

2.11.3 The TMS system shall support the division into functional partitions. Each functional

partition shall represent a function such as sectional control, ASM etc. 2.11.4 The TMS system shall support the division into geographic partitions. Each partition

shall represent a geographically related group of assets. 2.11.5 Each indication, control, alarm and user action shall be assignable to anyone or

multiple functional partitions.

2.11.6 Each indication, control, alarm and user action shall be assignable to one

geographical partition. 2.11.7 Functional and geographical partitioning shall be assigned to a user upon logon to

the TMS. 2.11.8 TMS shall verify that all geographic partitions are covered by a controller during

operations.




3.0 FUNCTIONALITIES OF TMS:

The system broadly envisages the functionality as described below:

3.1 Live Indications:

3.1.1 Live Indication in Control office at OCC (On Overview Mimic Indication Panel):

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

3.1.1.2 The Mimic Indication Panel shall display all track circuited lines and all interlocked

signal aspects of track layouts of station & auto sections of section monitored by TMS.

3.1.1.3 The Overview Mimic Indication Panel unit shall display important indications of all

running lines of wayside stations panel, aspects of auto signals, and 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.

3.1.1.4 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.

3.1.1.5 If a train has stopped at any point enroute for more than the prescribed minutes (user

configurable parameter), an alarm should be raised to draw attention of the controller.

3.1.1.6 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 (worst case change over time should be less than 60 minutes) and it should be possible without complete shutdown of the indication system.

3.1.1.7 It shall be possible to show the temporary speed restriction by showing the track lines

with different colors or by showing the Tag box or by any other means.

3.1.1.8 The various stabling lines (even if 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 on controller’s terminal whenever required by giving suitable commands through controller terminal.

3.1.2 Live Indication to Train controller terminals: 3.1.2.1 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.




3.1.2.2 Section controller / Chief controller terminals (work stations) will consist of 4

LCD/LED (as specified by user- by default it should be 32” LED type) monitors operated by one computer with GPU . All the features required for efficient display and control of the section shall be available on these terminals.

3.1.2.3 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. A list of possible alarms is given as Annexure-1.

3.1.2.4 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. 3.1.2.5 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.

3.1.2.6 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. 3.1.2.7 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.

3.1.2.8 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. 3.1.2.9 The details of occupancy of berthing lines and sidings shall also be available on the

terminal. 3.1.2.10 The train controller terminal shall be capable of running the Decision Support

System (DSS) feature. Decision support system shall identify operational conflicts (like precedence, crossing etc.) in advance and suggest optimized control options to the controller.

3.1.2.11 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.

3.1.2.12 All the required traffic alarms shall be available on these terminals.

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

3.1.3.1 All stations with passengers’ services, car shed and lobbies will be provided with industrial Grade PCs (Specification of Industrial grade PC to be decided by Railway).




3.1.3.2 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.

3.1.3.3 It should be possible to input TRAIN ID in 8 alphanumeric 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.

3.1.3.4 Minimum Crew details required to be managed by system shall be provided by purchaser. By default following crew details must be managed by system even if crew management and rake management modules are not part of TMS/CTC supply:

(i) Crew Details : Crew names, base stations, time of duty joining and

competing – 6 crew records of 4 field (16 characters each) (ii) Rake details: Train number, train type (passenger/ goods/ mail/ EMU/

MEMU/ DMU), Loco Number, number of coaches/wagons, starting point, destination, received from station, handed over station

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

3.1.3.6 Details of rakes stabled on sidings at concerned station shall be displayed.

3.1.3.7 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.

3.1.3.8 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.

3.2 Train Describer System:

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

3.2.2 A train describer tag shall be unique consisting up to 8 alphanumeric characters displayed in a text box with arrow for direction color of arrow mark will green for on time train, yellow for minor delay train (say upto 30”) and red for in case of major delayed. In case of delayed trains there could be two trains with same number, in such cases delayed train shall be prefixed by letter ’D’.

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

3.2.4 The train describer system shall be able of automatically assign train describer tags from a train number queue to trains originating/terminating at the stations covered by TDS based on time table.

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




3.2.6 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 3.2.4 above temporarily.

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

3.2.8 The train describer system shall be able to register & display abnormal conditions in the Software such as following:

(i) Single track circuit failure

(ii) Faulty position of points

(iii) Change in direction of a train

(iv) Division and joining of trains (not time tabled ones)

(v) Unidentified trains

(vi) Trains passing a signal showing a stop aspect

(vii) More trains on the same track circuit

(viii) Wrong marking of object/functions.(For example- A train with electric loco being marked onto non-electrified line, A passenger train marked to a goods line, A train being routed to wrong destination etc.)

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

3.2.9 The train describer system shall be able to handle the commands for –

(i) Insertion of a train describer tag on a track or at a signal, which shall be assigned

automatically to the train occupying the track.

(ii) Moving a train describer tag to a different location

(iii) Renaming a train describer tag. (iv) Exchanging one train describer tag with another train describer tag. (v) Deleting a train describer tag.

3.2.10 It shall be possible to find the location of trains by search command. 3.2.11 It shall be possible to view list of trains in the train describer system with following

criteria:

(i) All trains (ii) Only operator identified (known) train. (iii) Trains in a given direction (iv) Trains at or between specific station(s) (v) Unidentified or delayed or cancelled trains

3.2.12 The train describer system shall send log records of the event logged including the

following information to data base:

(i) Movement of train descriptions (track to track details with timing). (ii) Operator’s commands to the train describer system.




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

3.3 Control Function:

3.3.1 After taking control of an area, the central controller will be able to send commands

to the corresponding interlocking. The possible commands are,

a) Setting / cancellation of route

b) Moving point to Normal or Reverse

c) Controlling signal ( ON/OFF) as permitted by interlocking.

d) Setting/cancellation of traffic & power block

e) Turning the ARS mode ON/OFF

f) Loading of Timetable/Train Chart

3.3.2 The CTC function performs a pre-check of signalling rules for feasibility of the command. The commands shall be forwarded to IXL only if conditions are fulfilled.

3.3.3 CTC system receives all the train operation information (position data) and field information including Point, signals, Track circuit, Set route data of station and level crossings data..

3.3.4 Captured data is processed and displayed on the individual console on a real time basis and supports the train control operation. Also, comprehensive judgment on the train operation status of entire section is allowed and support is provided for controlling the train operation by providing the same information on a large Video Wall Display.

3.3.5 Station control mode is classified into Local Mode and CTC Mode. Under Local Mode, SM at station controls the train operation. In CTC, control function is restricted, and only monitoring is done. Under CTC Mode, train operation control is possible by sending command for train operation, generated by Timetable or manually through the CTC console manually by controller.

3.3.6 It should also be possible for CTC to take control of only important lines (pre- assigned at time of design) and other lines (goods yards, non important lines on which shunting etc has to be done) shall be in control of ASM at station.

3.3.7 All emergency operation shall be done locally by ASM at station or can be done from CTC under exchange of private number, this aspect shall be approved by Railway at the time of design.

3.3.8 CTC also manages both train schedule written on the timetable and the train schedule modified by the controller, later one will prevail over first one.

3.3.9 In addition, train tracking function is provided, and unique identification number is given to the train which enters the CTC boundary section for train tracking. When the train exits the CTC section, the identification number is deleted.

3.3.10 It controls the field signaling equipment such as route, signal, Point machine and level crossing etc. in real time and remotely. The most of remote control can be performed by manual on the console.

3.3.11 CTC shall transfer control to local station as and when operational need arises. 3.3.12 In case of OCC got disconnected due to any reason local control shall prevail at all

station under jurisdiction.




3.4 Automatic Route Setting (ARS): 3.4.1 ARS can only be enabled if CTC functionality (remote control of signaling gears at

wayside interlocking) is being provided. 3.4.2 The automatic route setting feature shall be possible to be provided for identified

stations/routes/sections. 3.4.3 The ARS system relieves the operator from repetitive route setting tasks for the

trains at these station and the operator can monitor the train operation from OCC. 3.4.4 The system shall execute the commands according to timetable manual control

(CTC mode) is possible even when ARS function is operating, and manual control has higher priority than ARS control. Operator can cancel ARS mode (AUTO mode) at any time. Once the manual mode is set, the manual mode is valid and operated until operator changes the mode into ARS Mode.

3.4.5 System shall have online editing facility to enable the operator to reschedule trains, if required. The system should permit operator to receive/ dispatch any unscheduled train manually.

3.4.6 In case of perturbations, System should generate routing plans based on the schedule that is influenced by other current operational circumstances

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

3.5 Long Route Setting & Route stacking:

Long Route Setting is to generate the route set command from Home

signal of one station to Advance starter signal of another station by the CTC

server. The chief controller/section controller in OOC can set long route for one

station to another station. Provision of Route stacking shall be made to set

routes of several trains ( at least 6 trains) in advance.

3.6 Block Working Operation:

3.6.1 Block Operation for EI station shall be done through CTC controller from OCC.

Suitable fail safe provision of inbuilt block operation system in EI is needed for this and Conventional block instrument/panel will not be used for block operation. In case same is not available, local operation of block instrument will be done by SM at station.

3.6.2 For PI/RRI stations operation of block instruments/panel will be done by SM at station.

3.6.3 For block operation from OCC for RRI/PI station, conventional block instrument needs to be replaced with SSBPAC/UFSBI along with suitable fail safe block interface if developed.

3.7 MANAGEMENT INFORMATION SYSTEM: 3.7.1 MIS Edit: 3.7.1.1 The system shall allow user to enter any free text tag to be associated with any train.




3.7.1.2 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.

3.7.2 MIS Reports: 3.7.2.1 The system shall generate report for trains run delayed by time table. 3.7.2.2 Based on the events logged and the operator input, the system shall generate

various traffic management reports including but not limited to those given below:

(i) Various Train control charts

(ii) Various Punctuality reports (iii) Bad runner report (iv) Actual Rake Link Report (v) Rake Composition report (vi) Rake Maintenance/overhauling reports. (vii) Suburban punctuality analysis report in suitable format. This may be daily,

weekly or monthly as per prescribed format. (viii) 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.

(ix) Analytical report of crew link/ utilization. (x) Analytical report on rake link utilization. (xi) Total traffic/power blocks granted / refused along with locations, time blocked,

time cleared. (xii) Sectional running time taken by trains of any ID. (xiii) Delay report of trains along with train nos., delayed time (at stations) etc. (xiv) Difference between actual and scheduled running time in tabulated as well

as in graphical form. 3.8 Train Graph: 3.8.1 The train graph, as specified below, should be made available on the specified

terminals -

(i) The system shall plot historical train graph for analysis. (ii) It shall plot time on X axis and stations on Y axis. (iii) The train graph shall have facility to show different train types in different

color. 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 during data entry.

(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.

(ix) The Train Graph shall be available to display the current timetable, with a thick line for past data and a thin line for future data.

(x) It shall be possible to edit the timetable graphically from the Train Graph display by drag and drop operations.

(xi) The timetable software shall automatically perform the reforecasting of the future train trips when modifications are being performed either by the operator or due to traffic perturbations.

(xii) The Train Distance Graph refresh shall be event driven to maximize performances.

(xiii) The Train Distance Graph shall allow for comparing the theoretical and the actual timetable.

(xiv) The passenger information shall be driven by the actual re-forecasted timetable data.

(xv) The Train Distance Graph shall highlight traffic conflicts and shall assist the regulator in identifying and implementing solutions to resolve conflicts.

The system shall detect and resolve the following conflict situation: Same platform use, same route use, incompatible routes use, same section use between two stations. .

3.8.2 It shall be possible to select the direction, line type and of the day for which the

graph needs to be plotted. 3.8.3 It shall be possible to take printout of train graph on a printer/plotter. 3.9 Simulation studies on Simulation terminal 3.9.1 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.

3.9.2 It should be possible to simulate and observe the effect of various parameters such as Speed restrictions, on sectional density (capacity) and to produce train graphs in pictorial or tabular form. The parameters shall be decided in consultation with the Railways.

3.9.3 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.

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

3.9.5 The simulation can take place in real time or in reduced / accelerated time scale. 3.9.6 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.

3.9.7 Traffic simulation is performed by a complete simulation system devoted to Mainlines applications.

3.9.8 It shall simulate the whole set of interlocking equipment. It is connected to the TMS/CTC for two purposes:

(i) TMS/CTC Validation: before connecting the TMS/CTC to the real field, it is

connected to the simulator to validate the interfaces and the functionalities.




(ii) Training: the TMS/CTC operators may be trained to use the TMS/CTC and to learn how to react in case of incidents.

3.9.9 The simulation provides the following facilities:

(i) The activation of the TMS/CTC inputs, either one by one, or as an automated reaction to the TMS/CTC controls, or also to test scenario programs;

(ii) A consistent simulation of all the simulated equipment: track circuits, switch points, alarms, signals, routes, platforms and other functions as overlaps, axle counters, inter-stations, etc.;

(iii) Management of the trains movements respecting a fixed or controlled speed and mutual distance.

(iv) Tracing of all the messages exchanged and all the events with timestamp; (v) Scripting and running tests scenarios, thanks to a user friendly language

including a large set of specialized primitives; (vi) Management of timetable: it shall be possible to create, inject and insert trains

based on inputs from the timetable. 3.10 Crew Management system (CMS) 3.10.1 Crew Management system must be closely integrated with TDS system to provide

following functionalities:

(i) Crew management software system shall be provided wherever required (user specified requirement).

(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 Loco Pilot/motorman & guard).

(iv) It shall be possible to change Loco Pilot/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. 3.11 Interfacing of TDS with Crew Management System(CMS):

3.11.1 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. 3.11.2 TDS based on this information will show online position of motorman/ guards on

train details query on controllers terminals. 3.11.3 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. 3.11.4 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.

3.11.5 It shall be possible to get query based details of crew like running details, etc. 3.12 Interfacing with OHE SCADA system (optional) 3.12.1 TDS will take OHE shut down reports from existing OHE SCADA system.




3.12.2 The various power block granted and their duration from SCADA system. 3.12.3 OHE failures and tripping details of FP, SP and SSP. 3.13 Time Table builder and editing: 3.13.1 Time table builder software system shall be provided for identified sections. 3.13.2 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.

3.13.3 Time table shall be able to give section wise train graph. 3.13.4 Suitable interfacing shall be provided with TDS so that related data can be taken

from timetable builder to TDS or vice versa. 3.13.5 It is envisaged that the Time table builder tool shall be available on a simulation

terminal to aid the operator to prepare timetable. 3.13.6 It shall also have simulation facility to find any Headway, crossover and platform

conflicts in the time table.

3.13.7 The time table builder module shall have following features: 3.13.7.1 The system shall have a standalone Windows based tool to do the timetable

planning in the offline system. 3.13.7.2 It shall be possible to edit timetable. 3.13.7.3 It shall be possible to Create/Edit/Delete a train service. 3.13.7.4 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.

3.13.7.5 It shall be possible to use train service template while creating a new train. 3.13.7.6 It shall be possible to mark the rake link for the train service. 3.13.7.7 It shall be possible to define trains for a specific day of the week. 3.13.7.8 It shall be possible to define holidays for a given calendar year. 3.13.7.9 The time table compilation and proving system shall calculate and generate

number of train trips and train kilometers for all time table trains.




3.13.7.10 It shall be possible to transfer the timetable to TDS by authorized user only.

3.13.7.11 It shall be possible to take train frequency reports from the timetable database. 4.0 EVENT LOG AND ALARM MANAGEMENT SYSTEM: 4.1 Event Log: 4.1.1 All important events (command, indications, errors, system information etc.) shall be

logged in a database for later printing and analysis. 4.1.2 The time span of log shall be minimum 30 days of events.

4.2 Replay of Event log:

4.2.1 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.

4.2.2 The replay function will display, among other details, the dynamic status for

infrastructure, train number and alarm list. 4.2.3 Replay function should be capable to replaying events upto current time. 4.3 Traffic Related Alarms: 4.3.1 Vital traffic operation related alarms should be -

(i) Failure of any Signalling gear in the entire section under scope. (ii) Routes not released after passage of train. (iii) Train not described alarm (ND Alarm). (iv) Train waiting for more than a minute at signal not taken off should be alarmed and

logged. (v) Train stopping at off signal for more than a minute should be alarmed. (vi) Any other unscheduled train stoppage shall be alarmed. (vii) Any unscheduled train detention in excess of prescribed time shall be alarmed. (viii) Any OHE tripping should be alarmed and logged.

4.4 Network Related Alarms:

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

related alarms. 4.4.2 These shall be flashed on the maintenance terminal only. 4.4.3 These can be arranged in priority levels in consultation with the Railways.




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

5.0 DECISION SUPPORT SYSTEM (DSS):

5.1 Two types of DSS are envisaged from the system:

5.1.1 Based on the constraints & logic given by Railways, system should give

optimized decision to admit or dispatch particular train at entry/exit points of a particular section.

5.1.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, DSS 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.

5.2 TMS detects conflicts between trains and/or possession (simultaneous use of the

same or not compatible resources) based on current timetables (shunting movements included). 5.2.1 Conflicts in Station: System shall be able to detect following conflicts:

i) Usage of the same platform (if not planned a merge/split or if additional platform sections are not defined allowing presence of two trains considering however the next trip and direction of the trains);

ii) Usage of the same routes;

iii) Usage of incompatible routes;

iv) Conflicts between two Stations:

v) Usage of the same section and same directions;

vi) Usage of the same section and opposite directions;

5.2.2 TMS response after conflict detection:

i) In case of conflicts, TMS display a specific icon on the train graph and generates a solution which consists in the rescheduling of the involved activities.

ii) TMS solves conflicts “pair by pair” of trains applying the objective function only

to the trains involved in the conflict under analysis, but trying to limit next conflict generation. This approach allows to have clear solutions easily understandable and checkable by the Operator, limiting however the propagation of new conflicts in the future.




iii) The TMS elaborates the solution by applying the objective function within the using of Priority concept: this permits a uniformity of the logic used. The Priority concept is configurable and defined by elements such as:

Type of the train (passenger, freight, …);

Time of the day (off-peak / peak-hour, specific timeslot, …);

Amount of current delay;

Weight of priority.

iv) The solution is found by:

Changing the conflicting resource, if a resource/path (platform, route or inter-stations link) alternative to the currently planned one is available;

Stopping the train in a station before the conflicting resource;

v) The traffic operator remains in charge to apply the proposed solution or to manually change the timetable.

6.0 Field Interface Unit (FIU):

6.1 This unit will interface with the potential free contacts in Signal Equipment Room and extend data to/ from PI/RRI Interlocking.

6.2 The RRI/PI/ALH station’s and independent LC gates signaling field gear data shall be fetched through FIU using potential free contacts.

6.3 System to be used for communication with interlocking shall be as per IEC 870-5-101 communication protocol.

6.4 The FIU system design shall ensure that SIL2 level is maintained during communication between CTC and FIU.

6.5 In case of failure FIU control shall be automatically transferred to Station Master at station.

6.6 For interfacing of EI with CTC, protocol converter shall designed by CTC vendors. Data protocol used for EI may be shared by EI vendors.

7.0 Backup Control Center (BCC):

7.1 A Backup Control Centre (BCC) will be provided at designated Place (Preferably any Major stations location to be identify during execution of Order) to take over controls in case of exigencies/breakdown as a Disaster Management Plan. In case of exigencies/breakdown at OCC the control of OCC shall be transfer to BCC seamlessly such that all functionality of OCC shall be achieve through BCC.

7.2 The CTC Server Configuration of BCC shall be identical as OCC using the same server configuration. With minimum Controller workstations such that one Dy chief controller workstation, one offline timetable workstations. One Signal Fault controller of similar configuration as in OCC. There may be a requirement of one FT server to make a similar configuration of OCC.

7.3 BCC should use independent system resource, in case failure of OCC due to failure of any subsystem of OCC, the working of BCC should not get affected.




7.4 The communication channel from station to BCC shall be different from that of OCC as far as possible.

8.0 National Control Centre: 8.1 Provision of national control centre shall be made to monitor zonal CTC system

& to take over control of any CTC system under its jurisdiction. 8.2 Transfer of control can also be extended through BCC so that in case of non

functioning of OCC it is possible to monitor and control CTC from NCC. 8.3 Connectivity between CTC and NCC should be on high bandwidth MPLS

network or any better system to maintain all functionalities of OCC from NCC. 8.4 Redundancy in communication network shall also be planned. 8.5 All the functionalities of OCC should be made available on NCC. 8.6 Provision of NCC is required to be made for once with first CTC and all future

CTC shall be networked to that NCC.

9.0 SOFTWARE DETAILS:

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

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

9.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 Technical Requirements of TMS:

10.1 General: 10.1.1 All Servers and Terminals to be provided at OCC shall be of same type and make as

approved by the Engineer. 10.1.2 All Terminals to be provided at wayside locations shall be of same type and make as

approved by the Engineer. The hardware installed at wayside locations shall be modular and rugged and of appropriate size, capability and capacity.

10.1.3 All Servers and Terminals at OCC & wayside locations shall be provided with printer slot and minimum 2 spare slots for future use.

10.1.4 Servers and Terminals shall be of Industrial grade. Vendor of Servers and terminals

shall have service centers in India. 10.1.5 LED Indications and test points shall be available on various cards Modules for easy

fault diagnostics by the maintenance personnel. 10.1.6 The system designed and implemented shall be flexible and modular enough to permit

easy alterations in terms of change in site data, addition or deletion of user, stations etc.

10.1.7 The TMS shall support communication with neighboring TMS based on UIC 407-1 or similar standards.

10.2 Central Server(s):The following shall be the main functions of the Central server(s): 10.2.1 It shall maintain and update in real time the position of all Information of all field nodes to

the last second. 10.2.2 It shall provide drive for the Video Wall Display Panel. It shall display all the incoming

information data and shall revert back to the field nodes for incomplete information to ensure the latest information is obtained.

10.2.3 It shall accept input data from the authorized operator node only. The access to the server shall be through a gateway with the correct level of authority. It shall process the data as per requirements of the system.

10.2.4 It shall reply to the queries requested by various SMs in the background without interrupting the Traffic Controllers.

10.2.5 It shall provide necessary data to print the various reports in suitable formats. 10.2.6 It shall enable display of both information and alarms on any of the terminals in OCC,

Station etc. as per pre-programming. 10.2.7 It shall be connected via data channels with the entire station signal interlocking

through a suitable interface. The OFC data channels for connectivity will be used. 10.2.8 The aggregate information status of Track sections, signals, points, route set, and LC

gate closed l open etc. of station and block section shall be transmitted from wayside stations to Central server.

10.2.9 The Central server(s) shall also be interconnected to Central server(s) o f other section for exchange of necessary data as per the interface requirement. The des igner shall propose their own networking methods between field stations and Central server to achieve desired performance. All network elements shall be capable of being monitored and managed in the event of malfunction.




10.2.10 It shall be provided with adequate flexibility so that alterations and additions to the present functions and facilities are carried out with minimum disruption in the working system as and when required. It shall be compatible with future interlocking changes yard alterations at wayside stations.

10.2.11 It shall be compatible for running off line forecasting module for computing expected arrival of trains.

10.2.12 Central server equipment shall be provided with Disc storage device to store real time database reflecting CTC information as well as an event logging database. Various terminal/equipment in the OCC office shall be interconnected with applications server using a dual local area network (LAN). Adequate redundancy of critical system, software and database shall be ensured.

10.2.13 Central server equipment shall be redundant fault tolerant server. The FT Server eliminates single points of failure using replicated components that continue uninterrupted processing even in the event of a component malfunction. Hardware faults are handled automatically by the system, without the delay of a failover (as on a cluster) and without loss of data.

10.2.14 The proposed configuration of central server shall be discussed and got approved by engineer in charge of Railway. Typical configuration of Central server for reference is given as under as under: (i) Type: Redundant Fault Tolerant Server. (ii) Processor - 2 x Intel® Xeon® Silver 4114 Processor (iii) Speed - Minimum 2.2 GHz. (iv) Memory – 32 GB. (v) 4 PCIe 3x8 (2 Per CRU). (vi) 10/100/1000 Ethernet Ports – 4 (2 per CRU) (vii) Serial Ports – 2 (9 Pin ) ports per system. (viii) Storage – 600GB + Minimum 1.2 TB (ix) Input Voltage – 100-127, 200-240 VAC; 50 Hz , 60 HZ (x) USB Ports – 4 USB 2.0 and 4 USB 3.0 (xi) Accessories - As required. (xii) Supporting operating system - Red Hat Enterprise Linux 7.6 (xiii) Server shall be mountable on 19" rack. (xiv) The hardware requirements described above are minimum

requirements but are not definitive. All hardware to fulfil all functionality, reliability and availability requirements as specified shall be provided.

10.2.15 The number of Servers and their configuration shall be proposed by the designer of the

system. RAMS analysis should also be done in order to demonstrate that the proposed solution satisfy the availability requirements.

10.2.16 Central Server shall be provided in Redundant FT mode. The Primary server shall be exact replica of Secondary Server. In the event of problem with Primary server, execution of application shall be seamlessly transferred to secondary server without interrupting the operation and affecting the quality of service of operation. Similarly, if system is running on Standby server and it fails, working shall be transferred to primary server. Central Server shall be capable enough to deliver the required performance. It shall be possible to disconnect the secondary server for repair/replacement without affecting the server in operation. More than one equipment / set of equipment may be used to achieve the required performance along with its hot standby.

10.2.17 Following data should be logged on Servers to be archived for subsequent use:




i. All train related information. (Signalling indications, train movements

details, trains description details etc.)

ii. All system related data viz. Node failures, hardware failures,

communication failures etc.

iii. All inputs made by the way side terminals (inclusive of crew

lobby/crew booking point) or by terminals at the OCC.

iv. The data shall be stored in a compressed and organized form so as to

conserve the disc space.

v. The storage shall be for a minimum period of 30 days. It shall be possible to

take Incremental back up on hard disc, additional hardware for this purpose may

be provided.

vi. It shall be ensured that the data is not lost while copying.

vii. The notes recorded by the Section controllers/SMs shall also be logged on

the storage devices. These notes shall be linked to the concerned screen and

context.

10.3 Training Server:

10.3.1 This Server shall be provided as a separate Server with its own LAN at the OCC or any other location as decided by Railway for training and simulation purposes as per following (but not limited to) details:

(i) One terminal with 3X32" (minimum) VDUs for Simulation and Time Table Planning.

(ii) Five terminals for Trainees with 1X32" VDU (minimum). (iii) HDD - Minimum 2 X 64 GB, Hot swappable, Ultra SCSI in RAID 1. (iv) It shall be possible to configure Trainer's terminal to work as active Controller's

terminal in case of any of the Controller's terminal becomes defective/ out of

service or any other reason. (v) The hardware requirements described above are minimum requirements

but are not definitive. All required hardware to be arranged to fulfil all functionality, reliability and availability requirements. The above configuration is only for guidance and configuration of training server shall be designed as requirement of Railway and got approved by engineer in charge.

10.3.2 It shall be possible to access the database for analysis and simulation

studies. The data or results thus generated after simulation study or analysis shall not be stored on the main memory of the Central server permanently. To prevent the same, both hardware and software checks shall be provided. It shall be possible to store it in its own hard disc.

10.4 TMS Terminals Hardware:

10.4.1 All TMS terminals shall have similar hardware configuration. Typical




Hardware Configuration is given as under:

i) Type: Industrial Workstation. ii) Processor: 64 Bit Multi Core Multi Processor. iii) RAM: Minimum 8 GB.

iv) FLASH MEMORY: Minimum 120 GB. v) Monitor: LED Back lit Color monitor, high resolution 1920 X1200, and 32"

(minimum). vi) I/O card: Adequate I/O facility, Integrated Drive Controllers, Dual network

Interface cards, High End Graphics card etc. vii) Accessories: As per requirement.

viii) A printer shall be connected for on line logging with the TMS Maintenance

Terminal for logging all network related alarms.

(ix) The hardware requirements described above are minimum

requirements but are not definitive. All required hardware to be provided to fulfil

all functionality, reliability and availability requirements as specified and should

be got approved by engineer in charge.

10.4.2 Table below shows the various operational posts for which the TMS terminals are provided and the number and sizes of monitors with the controllers.

Operational Post Monitor Size (inches)

No. of monitors per position

Chief Controller 32" 4

Dy. Chief Controller 32" 4

Assistant Controller 32" 4

Section Controller(s) 32" 4

CTC Maintenance Terminal at OCC

32” 1

Signal Fault Controller 32” 1

Track Controller 32” 1

Traction Power Controller

32” 1

Station Master at Station 32” 1

Crew Controller 32” 1

Signal Maintainer at Station, IMD and IMSD

32” 1

Miscellaneous User CTC Terminals

32” 1

In the OCC separate workstations for offline timetable management shall be provided having the same configuration as those for TMS terminals.




11.0 Video Display System:

11.1 Video Wall Display:

11.1.1 Laser based rear projection system type video wall may be used. It shall consist of Display modules and Display Controller which will integrate various display modules into a single logical Display Wall.

11.1.2 Display resolution of video wall should be minimum 1920X1080 pixel.

11.1.3 The Video Wall Display system shall be rugged and shall be able to work on 24x7

basis.

11.1.4 The display windows shall be freely resizable, re-scalable and repositionable on any part of the display wall.

11.1.5 Suitable Interface equipment and drivers for linking Indication panel with applications server shall be provided.

11.1.6 The terminal server/ driver for driving the Video Wall Display Panel shall have full-fledged capacity to drive described displays from provided equipment + 20% spare.

11.1.7 The placement of Video Wall Display Panels, seating arrangement of the Controller's, viewing angle in vertical and horizontal plane etc. inside OCC shall be carefully planned. To ensure a user-friendly environment, an ergonomic study shall be performed to guarantee uniformity and consistency. Design of Video Display wall shall be as per ISO 11064 Part 5.

11.1.8 Legibility, lighting, contrast, content, font size, viewing distance etc. shall be kept in

view while designing graphics for the display.

11.1.9 Station layouts can be arranged in a number of rows- top, middle and bottom.

11.1.10 The lowest row shall not be below 1.5 meters (approx.) from the floor to ensure proper viewing angle. The exact height of the lowest row shall be decided and agreed with in consultation with the Engineer.

11.1.11 Pedestal shall be made of Aluminum extruded and anodized members. Front of the

pedestal shall be covered. 11.1.12 It shall be compatible with the international VIDEO Standards.

11.1.13 Projection system shall have cooling fan with dust filter and have rear service

access 11.1.14 It shall be possible to increase / decrease the color intensity, contrast adjusting etc.

screen wise through the system console. It shall be possible to memorize the parameters of one screen and use the same parameters for all the other screens.

11.1.15 The unit shall be compact and energy efficient so as to conserve on space and power consumption.




11.1.16 The video wall support software packages, documentation and details of maintenance shall also be supplied.

11.1.17 Any other facility to make the system more user friendly shall be incorporated.

11.1.18 Indigenous service support shall be available for the selected equipment in India.

11.1.19 Video Display wall shall be designed as per ISO 11064 Part 5 to include all functionalities required for the section.

11.1.20 The Video wall system shall be generally similar in appearance to the other Video wall system planned/ provided in other section , so as to have uniformity with existing system.

11.1.21 The designer shall submit the color scheme to be used for the symbols to be adopted for the Video Display Wall for approval by the Engineer. The Designer shall also provide a mock-up of the display prior to the commencement of implementation for approval by the Engineer.

11.1.22 Technical specification of video wall shall be got approved by Railway engineer ( Minimum technical requirement of Laser based rear projection system is given in annexure-II for ready reference).

11.1.23 Calculation for size of video display wall for 300kms section having 40 stns with auto signalling is enclosed as Annexure III for reference.

11.2 Display Controller: 11.2.1 The Display controller shall be dual redundant with auto switchover including dual

redundant hot swappable power supply. 11.2.2 The Display controller shall have the possibility of connecting the various types

of analog and digital sources which can be shown in freely scalable and moveable windows on the graphics wall.

11.2.3 Design of display controller shall fulfill all functionality, reliability and availability requirements as specified.

11.2.4 The display controller shall have following minimum configuration: (i) The Display Controller shall be housed in an industrial 19" rack mounted

casing (6U) based on Intel Quad Core CPU 2.66 GHz. (ii) The Display controller shall have minimum memory of 4 GB. (iii) The Display controller unit shall be equipped with a DVD RAM Drive. (iv) The Display controller system shall be equipped with 500 GB HDD in

RAID1 Configuration. (v) The Display controller shall have 10/100/1000 Mbps Redundant Ethernet

port for LAN connection. (vi) The Display controller shall be supplied with a Keyboard and mouse with 20

m cable extension. (vii) The Display Controller shall be based on 64 bit operating system.




(viii) It shall support minimum 2 DVI/VGA/HDMI Inputs and 8 Composite video

inputs. (ix) The hardware requirements described above are minimum requirements

but are not definitive. Technical specification of video controller compatible with video wall shall be got approved by Railway engineer.

11.3 Wall Management Software:

11.3.1 The Wall Management software shall provide control and management of

application windows and display devices connected with the display controller. 11.3.2 It shall be able to pre configure various display layouts and access them at any

time with a simple mouse click. 11.3.3 The software shall enable the users to see the desktop of the graphics

display wall remotely on any Windows as workstation connected with the Display Controller over the Ethernet and change the size and position of the various windows being shown.

11.3.4 The software shall enable various operators to access the display wall from the local keyboard and mouse of their workstation connected with the Display Controller on the Ethernet.

11.3.5 The software shall copy the screen content of the workstation connected on the Ethernet with the Display Controller to be shown on the Display wall in scalable and moveable windows in real time environment.

11.3.6 The wall management software shall support open APIs to enable system integrators to integrate it with their Software.

11.3.7 The Diagnostic software shall perform health monitoring that allows timely detection of faults.

(i) Wall health.

(ii) Cube health.

(iii) Cube IP-address.

(iv) Brightness.

11.3.8 The software shall support control of brightness, contrast, saturation, hue, filtering, and crop and rotate function on the various displays connected to the display controller.

11.3.9 The integrated view shall provide a database that: (i) Records all events.

(ii) Can record full status at given time intervals.

(ii) Can be exported to EXCEL/HTML; and Show internal patterns.

(iii)




12 Features of CTC terminals:

12.1 Common features of CTC terminals:

12.1.1 For standard monitoring, supervision and control purposes all operator

interfaces to the CTC system should be through universal type of workstations (CTC terminals) which can be easily configured to required operator functionality based on the users log in profile. Irrespective of whatever may be the operational role of user, the CTC terminals shall have the same look and feel to maximize the operational synergies between the various operator roles.

12.1.2 All the CTC terminals shall show the real time display of train movements and status of signalling infrastructure.

12.1.3 All user initiated functions shall be accessible using Mouse & Key Board. It shall be

possible to enter commands through menus, selection in the pictures, functional keys or via text input through GUI based user-interface. The precise operation of objects and the content of menus must be as agreed with the Engineer.

12.1.4 It shall be possible to scroll from left to right and vice versa from one station to another

without flicker. In case of big yards with a number of lines, the yard shall not look congested on the screen. In addition, it shall be possible to divide the bigger yards into suitable no. of pictures.

12.1.5 It shall be possible to open many windows on each terminal. A window must be active when the cursor is moved in its frame and the operator must be able to issue commands only to those objects in active window. The display shall be dynamic even if the related window on the screen is not active.

12.1.6 The Various input displays and reporting formats ( to b e d e c i d e d i n consultation with Engineer) shall be used for dialogue between the operator and the terminal.

12.1.7 It shall be possible to mute the audio or change the volume. It shall be possible to alter the viewing angle of the VDU monitor in the vertical and horizontal planes.

12.1.8 Current time and date shall be continuously displayed on the VDU screen conspicuously. Furthermore, the display shall be provided with an indication, which ensures the VDU screen is communicating in real-time and is not "frozen".

12.1.9 In case of unusual events, the system shall prompt the controller to enter the reason and other details in the prescribed format. This shall form part of database and shall be used for MIS reports later.

12.1.10 Any failure or unusual event will generate an audio/visual alarm as per user requirements to draw attention of the operator. It shall be possible to acknowledge and stop the alarm of failures by the user.

12.1.11 Authority to log in shall be protected through a password. Only authorized persons shall be able to log in and access related database.

12.1.12 Access to the server's application software & system software shall be restricted through the gateway and proper authority check.

12.1.13 The designer shall to the extent possible design the user interface of the CTC terminals, similar to the user interface of CTC of other sections.

12.2 Specific Features on various CTC terminals:




12.2.1 CTC Terminals for Controllers - Chief Controller, Dy. Chief Controller, Traffic Controller(s) and Assistant Traffic Controller:

(i) These CTC terminals with each of the Controller shall have three

monitors, one will show the overview, another detailed view and the

third one would show the alarm/event view. There shall be full

flexibility, however with regard to display of information on any of

the 3 monitors. (ii) CTC Terminal shall facilitate all functions of Train Describer

System (iii) All the Traffic related alarms shall be available on these terminals.

(iv) The crew details available in the system shall also be available on

these terminals, apart from being available on the CTC Terminals of

Station Masters and Crew controllers. (v) It shall be possible to view Train Graphs be it historical, previous or

current. The Train Graph shall also cover advance charting showing traffic blocks. Messages/Information of diversion/cancellation of trains issued from these Terminals will draw attention of SM by flashing audio visual indication.

(vi) The Traffic Controller shall be able to enter any inputs regarding

rescheduling of trains. This data shall be considered temporary and

the operator shall be prompted to input the duration for which the

data shall be held valid. (vii) The temporary valid data shall be given the same status as that of

permanent data and all the time tables and trains graphs shall be

generated as per this data. (viii) It shall be possible to view various MIS reports.

12.2.2 CTC Terminal for Signal Fault Controller at OCC:

(i) Remote monitoring of status of Signalling equipment at stations and

in Block Sections, shall be provided on these terminals. This shall

include logging in of events in central system, generating alarms,

alerts etc. (iv) Signalling equipment failure alarms as decided by the Engineer along

with category shall be available on the terminal. It shall be possible to

acknowledge the alarms by the user.

(v) All Traffic related alarms also shall be available on these terminals. (vi) It shall be possible to gain access to all reports as can be accessed by

the Traffic controller(s).

(v) All the formats for the displays /reports shall be decided in

consultation with the Engineer. (vii) It shall be possible to send message to the other controllers through




the terminal by video flash /audio buzzer.

(viii) Facility of viewing the train graph on the same monitor shall be

available on these terminals.

12.2.3 CTC Terminals for Track Controller and Traction Power Controller at OCC:

(i) It shall be possible to input remarks/ Information pertaining to various

unusual occurrences e.g. failures & delays to operation etc.

(ii) It shall be possible to gain access to all reports as can be accessed

by the Traffic controller.

(iii) It shall be possible to access the Central server for retrieving reports in

suitable format. All the formats for the reports shall be decided in

consultation with the Engineer. System will have a provision that a

report retrieved by a particular controller pertains to him only.

(iv) It shall be possible to send message to the other controllers through

his terminal by video flash audio buzzer.

(v) Equipment failure alarms specific to Track or Traction Power, as

decided by the Engineer along with category shall be available on

the respective terminals.

12.2.4 CTC Maintenance Terminal at OCC:

(i) The Maintenance Terminal shall be used for supervisory functions

of the network and for observing any required nodes and their

configuration at any time. (ii) It shall be used for indication of all alarms, both operators related

and network related.

(iii) It shall be possible to bypass any node if so required and configure

other terminals from this terminal.

(iv) It shall have fault logging & diagnostics for network equipment

at element level. (vi) Displays of equipment faults, communication failure

occurring anywhere in the OCC or field network shall be readily

available on this terminal. (vii) In case of faults, this terminal shall provide all assistance for

rapid detection of faults. (vii) Alarms shall be available on this terminal and few of the Emergency

Alarms are as follows:

Power supply failures at control center,

station, block section location or any node in network. Central control internal communication failure.

Communication equipment failure.

Field control unit failure.




System failure. Interlocking interface failure (Way Side Communication

Equipment). Failure of node Any other indication considered essential by the Employer.

(viii) Alarms shall be logged on real time basis. These shall be

recorded in format so as to access particular file as required at a later

date. Exception report (failure report of desired elements) shall be

generated. File format shall be decided in consultation with the

Engineer.

(ix) This terminal shall have access to MIS reports.

(x) Terminal will provide a pop up window to display a table to

allow maintainer to correlate data communication with its associated

field objects. Also, online display about the following shall be available: • Station being polled. • Station transmitting. • Station faulty.

(xi) Element level Network Management System (NMS)

module shall be available on this terminal and shall show:

• The position of various nodes.

• Identification of faults and their nature.

• Current status and health of equipment and communication

channels.

• Memory utilization.

• Remote bypassing and changeover of faulty equipment.

• Ability to check quality of communication from any node to the

other on the network including bridges and routers. This shall

be done in background without visibly downgrading the

system.

(xii) Facility to view system network performance statistics on

this terminal shall be provided. From this terminals other work station

computers, terminal servers, voice and data switching nodes and SM

terminals shall be able to be monitored at element level for performance

and switching to alternate communication channel.

(xiii) It shall be possible to monitor all elements of network of

OCC and field units through NMS.




(xiv) SNMP or a similar standard protocol as approved by the Engineer

shall be used. (xv) It shall have facility for real time diagnostics of Communication

network automatically as well as manually. (xvi) Facility for Network performance statistics, communication testing and

managing internal or external node on the network shall be made

available. (xvii) Fault Diagnostics:

• All malfunction in vital hardware subsystem modules in the OCC

shall result in audio & visual alarm at the maintenance terminal. • The maintenance terminal shall have diagnostic software

through which it will periodically scan all elements. • Diagnostic routine to check hardware like CTC field equipment

(excluding interlocking installation) and data communication

circuits shall be available.

• Shall have monitor programs to test connectivity. • Facility shall exist in the system to switch from one

communication line to the other in case of fault. • It shall be possible to display polling status of stations. • It shall be possible to capture all transmission events for

analysis and fault finding of data transmission. • It shall be possible to change the password configuration of the

Controllers ISMs terminals.

12.2.5 CTC Terminal for Station Master at Station:

(i) One CTC Terminal for Station Master at every Station shall be

provided. (ii) CTC Terminal for Station Master shall facilitate all functions of Train

Describer System. (iii) It shall be possible to query the system regarding details of trains,

cancellation, rescheduling, delays, diversions, siding occupancy etc. either

through menu driven commands or through SQL commands. (iv) The details of occupancy of berthing lines and sidings shall be available.

Details of loads available on sidings at concerned station shall be displayed when cursor is placed on the siding. Whenever a train leaves I enters the control area or is put out of the system by placing it in the siding it shall be automatically registered by the system. In addition to this, SM shall have facility to delete I enter such trains. Whenever a train I load leaves I enters the control area of concerned station or is put out of the system by placing it in the siding the SM shall have facility to delete I enter such trains from I into the system.




(v) 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. (vi) It shall be possible to view various MIS reports. (vii) Communication arrangements available at the station shall also be

displayed symbolically. (viii) It shall be possible to send pre-defined routine messages by the Station

Master to Central server either pre-stored or entered through a dialogue

box. (ix) Crew details information shall also be available with these terminals.

12.2.6 CTC Terminal with Signal Maintainer at Station:

(i) The alarms for failure of vital Signalling and Power Supply Equipment in

the jurisdiction of Station shall be available on the terminal. (ii) Traffic related alarms shall also be available on these terminals.

(iii) It shall be possible to view various MIS reports as agreed to by the Engineer during design stage.

(iv) Facility of sending the messages to Central controllers including the

signal fault controller shall be available on these terminals.

12.2.7 Miscellaneous User Terminal:

Required Nos. of Miscellaneous User CTC Terminals tp important offices locations shall be provided. The locations may be station, Divisional and Zonal office as decided by the Engineer. The exact locations and features to be made available on these terminals shall be approved by the Engineer. These terminals will provide first-hand information about running of trains in visual form and in required format.

13 Various Interface Requirements:

13.1 Interface between CTC and SCADA system:

Interfacing with the OHE SCADA system shall be provided to achieve following

information exchanges between CTC & SCADA:

(a) The RPS display screens, including display controllers, for SCADA system shall be provided. CTC shall interface with SCADA system to exchange any data between two systems. The designer shall exchange and agree on the protocols and hardware / software interfaces between the systems. In case of conflict, the Engineer's decision shall be final.

(b) CTC will take OHE shut down reports from SCADA system. (c) CTC will take details of the various power blocks granted and their duration

from SCADA system.




(d) CTC will take details of OHE failures and tripping details of FP, SP, and SSP. (e) SCADA will pick up failure of AT supply details from CTC.

(f) Any other information considered necessary by the Engineer. 13.2 Interface with Master Clock System:

The system clock shall be synchronized with Master clock provided in OCC under

PS (Telecommunications). A suitable synchronization system in the event of

failure of the Master Clock shall also be provided. 13.3 Interface with COA:

CTC shall provide suitable interface for providing online train arrival and departure time of all passengers & goods trains with train identification for COA application. The information shall be provided as per COA format/protocol to directly access this information by COA server. Methodology of integration between CTC & COA system is given in Annexure-IV.

13.4 Interface with other CTC:

(a) The CTC provided under one section shall be designed to interface with CTC provided for other sections.

(b) Train ID generated in one CTC system continues to be maintained or

updated automatically with relevant information when the train moves into the

adjacent section, provided with CTC of another vendor. (c) Similarly, the Signaling indications of one CTC section are exchanged with

CTC of other sections when train crosses the boundary of the two sections. (d) Interface specification shall be prepared according to requirement of CTC

of adjacent sections detailing the information required to be shared with CTC of adjecent sections. One CTC will share all the required information of his CTC, including the data formats, protocols, physical / logical connectivity and limitations related to the interface, with the other CTC to enable them design their i n t e r f a c e .

(e) The Central Server provided in one CTC shall interface with Central server

provided in other sections for seamless exchange of information, including

but not limited to the following:

(i) Train schedule information: Daily / seasonal Time table etc. (ii) Train running information: Train identification, type, composition, crew

details, dynamic location etc. (iii) Train approaching the boundary of adjacent section. (iv) Special events: Unusual delays, loco fault, any unusual alarms etc. (v) Any other information as required during the execution of the work.

(f) The CTC shall normally use the Timetable and Crew Management system

provided in section. To aid implementation, the sectional data of one section




shall be shared with other section. Not only that the CTC provided under

one contract be designed to receive the Timetable and Crew Management

information from the Central server of CTC of other sections but also it

shall have facility to carry out any updates in the Timetable and Crew

Management information provided in Central Server of other sections. (g) The format of data exchange should be non-proprietary and vendor

independent open type such as XML, CSV, text strings etc. The protocol used for interface shall be industry standard open protocol, which shall be easily configurable such as Modbus TCP, Webserver etc. It shall be possible to establish1configure logical link between server / systems of adjacent CTC. The communication protocol used for CTC-CTC interface shall be TCP/IP based and data routing shall be possible by IP configuration.

(h) The TMS system shall support communication with neighboring

TMS/CTC based on UIC 407-1 or other equivalent standards..

13.5 Interfaces with Passenger Information System (PIS):

13.5.1 Interfacing PIS System: 13.5.1.1 TMS supplier will provide industrial grade workstation at each of the stations

where PIS system is required to be interfaced with TMS system. This workstation will drive the PIS systems either directly (for new installations of PIS as per RDSO specification RDSO/SPN/TC/61/2012) or through existing PIS terminals at stations. For existing PIS systems, necessary software details regarding database of PIS system shall be made available by railway.

13.5.1.2 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.

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

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

13.5.1.5 The interface should also drive the existing Indicators. 13.5.2 Indicator Boards on Platforms & FOBs:

13.5.2.1 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.

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

13.5.2.3 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.

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

13.5.3 VDU monitors at Stations: 13.5.3.1 High resolution colour LCD/LED display (as specified by user- by default it should

be 42’’ LED type) shall be installed at the entrances /FOBs or other suitable locations decided by Railways.

13.5.3.2 Monitor will display details of 4 trains sequenced as per arrival time. 13.5.3.3 Information to be displayed will consist of alphanumeric characters in three

languages (Hindi, English & Local Language). 13.5.3.4 VDUs will be driven through ASM terminal & information displayed on VDUs can

be monitored on ASM terminal. 13.5.3.5 It should be possible to show video clippings through station terminal. 13.5.3.6 It shall be possible to send Scrolling Message/ full screen message on the Video

system. 13.5.4 Central Announcement (CA) system and way side station announcement

system:

13.5.4.1 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:

(i) General (slogans/public awareness/messages)

(j) Corridor wise late running

(k) Unusual /disruption

(l) Rescheduling, cancellations of trains

(m) Special train services planned

13.5.4.2 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.

13.5.4.3 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.

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

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

13.5.5 Additional Passenger information system (PIS) information on ASM PC:




13.5.5.1 The existing PIS system is PC based provided in station office which drive the

indicator, Video and announcement system. The additional workstation provided by TDS shall interface with existing PIS system at stations to update the PIS database and trigger update of display/indicators and make automatic announcements as required by central control.

13.5.5.2 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.

13.5.5.3 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.

13.5.5.4 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.

13.5.5.5 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.

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

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

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

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

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

13.5.5.11 The system shall be able to query the TDS Server about the trains standing on the station.

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

13.5.5.13 The system shall keep log of all the messages received from the TDS during last 7 days.

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

13.6 Interface with ETCS L-2/IRATP ( TCAS): 13.6.1 CTC system shall have interface to share information with RBC of ETCS

L-2 and TSRMS of IRATP (TCAS) if provided in the section. 13.6.2 Provision of accessing location data of trains from RBC in case of ETCS

& stationary TCAS equipment housed at stations in case of IRATP shall be made in CTC.

13.6.3 The scheme/protocol mentioned in RDSO/SPN/196/2012 version 4.0 or latest shall be followed for interfacing TSRMS system with the CTC system. In case of interfacing with ETCS L-2 system, necessary protocol of ETCS shall be made available.




14 Communication Network:

14.1 Communication network at OCC: 14.1.1 Dedicated Communication Network at OCC for interconnection of CTC Equipment

(Servers, Terminals, Video Wall Systems, Data Storage, Printers etc.) shall be fault tolerant.

14.1.2 Networking Equipment used in Communication Network such as Bridges, Gateways, Routers, Switches and Repeaters shall have redundancy.

14.1.3 The local area network employed shall be Dual LAN Network based on FDD/Ethernet/Serial communication.

14.1.4 Dual redundant link shall provide highly resilient communications network. System shall be tolerant to multiple simultaneous link failures, maintaining operation without degradation of performance. It shall be possible to perform maintenance on communication links without stopping the Signalling system.

14.1.5 Data transfer to peripherals like printers & plotters can be at lower speed for each device using appropriate media with duplicate path.

14.1.6 For connecting peripherals, screened twisted pair cables shall be used.

14.1.7 The cables used shall be of rugged type with capability to work data up to at least 1000 Mbps.

14.1.8 30% spare Ports on Switches & Hubs etc. shall be kept spare for future use.

14.1.9 Failure of any single Wayside Communication Equipment shall not cause failure of complete communication of CTC other than that of particular Wayside Communication Equipment.

14.1.10 It shall be possible to interface and transfer the circuits on to the backup communication on redundant OFC, wherever available.

14.1.11 All equipment shall be installed in standard 19" racks.

14.1.12 The time slots working shall have redundancy. However, it shall be possible to transfer all data from one time slot to a redundant time slot, if required.

14.1.13 The transmission with field station shall be controlled by polling wherever transmission is in serial mode and not in star configuration.

14.1.14 In-built safety provisions shall be available to detect data corruption / non- receipt of packets/node defect problems.

14.2 Data Communication network between CTC & Field interlocking system:

14.2.1 Dedicated OFC network in ring network shall be used for interconnecting field

interlocking system with CTC. 100% redundancy in design shall be planned.

Protection of this network may also be planned through hired channel from Railnet

or other service provider.




14.2.2 Preferably Multi-Protocol Layering Switch (MPLS) data transport protocols shall be

used for better resource sharing.

14.2.3 WAN network shall be used for networking of field functions like Freight Operations

Information System (FOIS), Crew Management System (CMS), Wagon

Management System (WMS).

14.2.4 Design and bandwidth planning shall be done ensure that data between various

stations or OCC to Stations or stations to OCC can be transported

simultaneously without any delay or jitter or drop in packets with Guaranteed

QoS. The designer shall provide bandwidth details during detail design phase

and the telecom network to be provided accordingly.

14.3 Wayside Communication Equipment :

14.3.1 Integrated digital communication shall be provided covering all field nodes (Station,

Hut, LC gate etc).

14.3.2 It should be based on client-server technology on IP platform. Facility of Voice

logging shall also be made.

14.3.3 OFC should be used for media.

15 INTEGRATION WITH MOBILE TRAIN RADIO (MTRC) SYSTEM (optional):

15.1 A Mobile communication may be available between the motorman/Loco pilot/guard

& the section controller.

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

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

15.4 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.

16 POWER SUPPLY:




16.1 The CTC system in OCC shall be provided with UPS of suitable capacity based on the load requirement at OCC.

16.2 Power supply units of all modules shall be operated from AC source ranging from 160

to 270 Volts (with tolerance of +10 V), 50 Hz AC, single phase with over voltage, under voltage and short circuit protection.

16.3 All the power supply units shall be operated at 50% load of maximum working capacity. Power supply units shall be SMPS type of standard make.

16.4 PVC insulated flexible 3 core x 2.5 sq mm multi strand power cables provided shall conform to specification no. IS: 694:1990 reaffirmed 1995 or latest.

16.5 Suitable protection against transient voltages coming in the power supply source or generated by some other source shall be provided by providing Class C protection device.

16.6 Data Cable and Power Supply cable shall be taken through separate pipes/ conduits.

17 LIGHTNING AND SURGE PROTECTION FOR ELECTRONIC SIGNALLING

EQUIPMENTS:

17.1 The equipment shall be suitably protected against atmospheric voltage surges both

for common mode (voltage that appears between phase conductors and earth) and differential mode (voltage that appears between neutral & earth) in order to limit the harmful effects of lightning.

17.2 The IEC standards 61312, 61024, 61643, 62305 and VDE 0100-534 pertaining to

protection against lightning and surges shall apply for all electronic equipment to withstand static electricity, electric fast transient and surge voltage.

17.3 The power line of electronic signalling equipment shall have Class B & C type 2-

stage protection in TT configuration. Stage 3 protection is also required for protection of power/signalling/data lines. Class B & class C type protection devices shall preferably be pluggable type to facilitate easy replacement.

17.4 Stage wise details of lightning and surge protection is given in annexure-V.

18 TESTS AND REQUIREMENTS:

18.1 Conditions of Tests:

18.1.1 Unless otherwise specified all tests shall be carried out at ambient atmospheric conditions.

18.1.2 For inspection of material, relevant clauses of IRS: S 23 and RDSO/SPN/144 shall apply.

18.1.3 Inspection and testing shall be carried out to the effect that all requirements of this specification are complied with.




18.2 SAFETY PLAN:

18.2.1 Safety plan shall be prepared and submitted which shall include system description, safety Integrity Level and safety case.

18.2.2 Manufacturer shall check and verify that the system being offered meets the

requirements of safety integrity laid down by railways.

18.2.3 Routine test (which must be carried out on each equipment by the manufacturer) and acceptance test(which are to be carried out on each equipment in the firm’s premises before delivery ) formats with test procedures and its significance

18.3 TEST PROCEDURE:

The test procedure shall be based on the system design. The methodologies to be adopted for various tests shall be decided taking into account the system design / configuration.

18.4 Visual Inspection:

Each equipment of the system shall be visually inspected to ensure compliance with the requirement. The visual inspection shall broadly include:

18.4.1 System Level Checking: i) Constructional details. ii) Dimensional check. iii) General workmanship. iv) Configuration. v) Mechanical polarization on cards.

18.4.2 Card Level Checking:

i) General track layout. ii) Quality of soldering and component mounting. iii) Conformal Coating. iv) Legend printing. v) Green or Black masking.

18.4.3 Module Level Checking:

i) Indications and displays. ii) Mounting and clamping of connectors. iii) Proper housing of cards.

19 MARKING:

19.1 All markings/ indications shall be easily legible and durable. Where the marking is by

use of labels, the labels shall be metallic and shall be firmly fixed and shall not be

capable of being removed by hand. Durability of marking shall be checked by rubbing

the marking by hand with a piece of cloth soaked with petroleum spirit. This

requirement shall also be met after completion of climatic test.




19.2 All markings/ indications shall be placed in the vicinity of the components to which

these refer and shall not be placed on removable parts, if these parts can be

replaced in such a way that the marking / indications can become misleading.

19.3 The words ‘Indian Railway Property’ shall be etched, engraved or embossed on the

equipment at a conspicuous position. For it, the size of the letters shall be chosen

depending upon the equipment but shall not be less than 20mm high in any case.

19.4 The anodized name plate shall be firmly attached to the equipment and shall show

the following information:

(a) Name or trade mark of the manufacturer. (b) IRS number. (c) Serial number of the equipment. (d) Installation for which meant. (e) Month and year of manufacture. (f) Version number.

20 DOCUMENTATION:

Two copies of the following manuals shall be supplied:

a. Instruction Manual

b. Installation and Maintenance Manual including Dos & Don’ts.

c. Mechanical drawings of each sub-system/ rack.

d. Guaranteed performance data, technical & other particulars of the equipment.

e. Schematic block diagram showing mounting arrangement of various components & details of each type of assembled PCB.

f. Trouble shooting procedures along with test voltages and waveforms at

various test points in the PCBs.

g. Details of software viz. Source code, algorithm, flow chart, machine code along with test/ validation procedure used and the results thereof.

h. Details of Hardware e.g. schematic diagrams of the system circuits/

components, details for each type of assembled PCB and part-list.

i. Pre-commissioning check list.

21 PACKING:

21.1 The equipment and its sub assemblies shall be wrapped in bubble sheet and then

packed in thermocole boxes and the empty spaces shall be filled with suitable filling

material. All PCBs shall be enclosed in anti-static shield cover. The equipment shall




be finally packed in a wooden case of sufficient strength so that it can withstand

bumps and jerks encountered in a road/ rail journey.

21.2 Each box shall be marked with code numbers, contents and name of manufacturer.

The upside shall be indicated with an arrow. Boxes should have standard signages to

indicate the correct position and precaution “Handle with Care” with necessary

instructions.

21.3 Printed circuit boards shall be separately and individually packed to prevent damage.

22 INFORMATION TO BE PROVIDED BY THE PURCHASER:

i. Signaling details of stations in section.

ii. If interface with ETCS/TCAS is needed.

iii. Details of location where CTC terminal shall be required.

iv. Location of OCC, BCC & NCC.

*****




Annexure-I: Indicative alarm list - (In absence of any specific requirement from purchaser following minimum set of alarms should be provided at appropriate terminal/s)

GROUP

INDICATIVE ALERT TEXT

DESCRIPTION

1. Emergency actions/events

SPAD alarm Control system has detected that a train has passed beyond the limits of its movement authority

SPAD inhibit failure Operator request to inhibit SPAD alarm on a signal has been unsuccessful

2. Out of Sequence Track

Circuit Occupation

Track section occupied out of sequence

Track section failure or incursion

Track circuit cleared out of sequence Possible loss of train detection (e.g. rusty track)

Train long time in section Train too long in section

3. Signalling Equipment failure to operate on request

Points failed to set normal/reverse/free Operator request for manual point movement failed

Route failed to set TM or operator route request failed

Route failed to cancel Operator action to cancel route unsuccessful

Automatic signal failed to replace to danger or to return to normal

Operator request to operate emergency replacement on auto signal failed

4. Level crossing events Level crossing failed Level crossing has failed (may

be separate alarm for level crossing

power failure)

Level crossing recovered Level crossing has returned to service

Level crossing switched to local control Level crossing switched to local control

5. Axle counter reset events

Axle counter restoration failed Attempt to restore operation of an axle counter has been unsuccessful

6. Signalling power events Earth leakage alarm Signalling power fault that can affect operation of signalling equipment

Signalling power primary supply lost Main electrical supply lost

Generator started Generator has started

Generator failed to start Where secondary supply provided by diesel generator - so running on UPS battery supply only with loss of power imminent

Generator stopped Generator has run out of fuel or has stopped working, whilst primary supply still out of operation

Signalling power primary supply restored

Main electrical supply restored

UPS fault Fault detected in UPS system

7. Train description events Non-described train entered area Train received into control area without a

headcode being assigned (shown by

**** on current NR TD systems)




GROUP


DESCRIPTION

Berth warning alarm Pre-configured alarm when train enters specific TD berth to alert operator to a manual action - such as warning a train is approaching a level crossing

Train not in timetable Train received into control area with headcode that is not in timetable

Train description duplicated Train received into control area with duplicate of headcode of another train in the area

8. Interlocking events – Electronic interlocking

Interlocking critical alarm High priority group alarm from Electronic

interlocking - includes some field

equipment faults such as signal lamp

failed, point detection failed, point

operation failed, route indicator

lamp failed, but also major hardware

failures in the interlocking

Interlocking non-critical alarm Low priority group alarm from

interlocking that is not service affecting

(e.g. first filament failure)

Interlocking /non-critical alarms cleared

Interlocking have a limited alarm buffer that has to be flushed by technician when full - this advises that the action has been completed

9. Interlocking events – Relay interlocking

First filament failure Common alarm for first filament failure in one signal in group of signals attached to a relay interlocking

Train operated route release failed to operate

Failure of interlocking to release route after passage of train (Train Operated Route Release)

Pulse generator fault Indicative type of faults that might be

communicated from a relay interlocking -

impact upon operations depends upon

effect on functioning of interlocking

Fuse fault

Panel processor fault

Local panel in operation Control of interlocking switched to standby signalling panel

10. Interlocking events Points loss of correspondence Points not detected in requested position

Signal lamp failure Main signal aspect failed

Position Light Junction Indicator lamps failure (<3 lamps lit)

Position Light Junction Indicator with less than 3aspects lit

Position Light Junction Indicator lamp failure(3-4 lamps lit)

Position Light Junction Indicator with only 3 or 4 aspects lit

SRI/MRI lamp failure Indicator lamp failure

Track circuit failure Failure in interface with track circuit

Ground frame interface failure Failure in ground frame interface system

11. Communication Loss of communication with LINK Failure in communications links causing complete loss of communications




GROUP


DESCRIPTION

Loss of communication between LINK and interlocking

Failure in communications links causing complete loss of communications

Loss of communication with GSM-R Failure in communication link for train

descriptions with GSM-R

12. TMS workstation events Workstation failure Failure in TM workstation causing a key function or the whole workstation to stop operating

Workstation restoration Workstation restored to operation after a

previous failure

13. TMS automation sub-system events

Automation switched off Automation in an area has been switched off

Automation not switched off/on TM or operator request to switch off or on

automation in an area unsuccessful

14. TMS planning event Joining portion of train overdue Current ARS alarm for joining trains

Timetable not received Current ARS alarm when timetable file not downloaded

Train has invalid timetable data Current ARS alarm when downloaded timetable found to have invalid timetable data for a train

15. TMS sub-system failure System data logger failed TM system event logger has stopped operating

System data logger recovered TM system event logger has resumed working

Automation system failure Failure in automation system causing loss of function

Automation system restoration Automation system returned to normal working




Annexure-2:Minimum technical requirement of Laser based rear Projection system

Parameters Minimum Technical Requirements

Display Overview

The Rear Projection Modules must be based on Single Chip DLP, Full HD (1920X1080) Native, Rear Projection technology. The displays shall utilize RGB Laser having different laser bank for different colours respectively without any moving part

Display Requirements All cubes shall of 70” diagonal size and optimized to work in a multi-screen arrangement

Brightness > 2000 lumen on screen

Light Source Laser with lifetime 100000 hours

Automatic colour and brightness adjustment

The system should have a continuous duty cycle of 24/7 for colour calibration and brightness uniformity using automated software via external server and should also support manual override function and feature on demand.

Panel uniformity >95%

Colour Formation Colour repetition speed must be 18X Frame Rate or higher with 3 x 12-bit colour and Brightness correction

Input signal flexibility: Each display module shall have minimum Redundant DP1.2 and HDMI 1.4 (HDCP compliant), DVI-DL inputs for redundancy purposes. RS232/RS

Moving Part No moving Part like colour wheel or Phosphor wheel should be present as moving parts has more failure tendency

Remote control

The control of the wall shall be possible via a network. All cubes shall have their own IP address, and the control software can access all of them at the same time. The available features shall be: On/Off, Brightness and Colour, Input control

Separate hardware server for monitoring features Wall or Panel On/Off, Brightness and Colour, Input control, health monitoring.

Also, software have feature to show maximum, minimum and current brightness / colour values of all the projectors.

Night Mode To protect operator’s eyes from blue light coming from screen sitting in front of video wall can also be reduced during night time

Idle Indicator Projector should in-built green colour indicator when projector is in idle state

Control option The system should support RS 232/ RS 422, IP & IR.

Schedule On/Off Schedule/time based ON/OFF complete system can also be possible without any human intervention

Automatic Backup/ Restore

Automatic / Schedule/time based backup/restore of colour/brightness settings also possible

Schedule Input Selection Schedule/Time based selection of input source can also be possible




Consistency Continuous consistency checking of complete system like: Duplicate IP Address, Firmware, Software Health, Cooling Load, Colour & Brightness Mode, Temperature factors, etc.

Automatic Projector Alignment

Projector is equipped with Automatic motorised alignment no manual alignment needed

Modular Design To reduce single point of failure projector is divided into multiple modules

Redundant Power Supply Redundant Power Supply internal as well as external

Dust Protection Should be IP6X certified by third party laboratory

Safety

Projector should complies with EMC (Electro-Magnetic Compatibility) Standard

System should be green focus in the product design, 100% free of harmful substances, eco-friendly materials

Display wall enclosure is 100% manufactured with recyclable materials to allow recycling for future use once the product has served its useful life

Serviceability Rear

Native Resolution per Panel

Minimum 1920x1080

Aspect Ratio 16:09

Screen Gap Less Than 1mm

Contrast ratio 1800:01

Input Power supply AC 90 V- 240V & 50 Hz frequency

Power consumption Less than 200 watt in Normal/Typical Mode

Heat Dissipation Less than 800 BTU/hr.

Operating Temperature system shall operate properly under 10ºC to 40ºC Temperature

Humidity 20%-80%

OEM Certification

All features and functionality should be certified by the OEM.

The Display Modules, Display Controller & Software should be from a single OEM.




ANNEXURE-3

CALCULATION OF VIDEO WALL SCREEN SIZE

Video wall refers to the common display system provided for the easy monitoring by different personnel. The display is of Rear View projection type which receives the image to be displayed from the CTC & SCADA systems.

1. Parameters affecting the size of Video Wall 1.1 Viewing angle: The total height of the display as positioned on the screen wall

must fall within the comfortable viewing cone. As per ISO 11064 standards, viewing angle should not exceed 38 degree for comfortable viewing with vertical head rotation. This criterion will decide the minimum distance at which 1st row of seating arrangement can be placed. Picture given below gives the minimum distance for first row for screen height of 3488mm. ( Min Distance = 3488/tan38 i.e 4465)

1.2 Maximum distance of clear visibility: This is the factor for deciding the

minimum size of the character and subsequently the size of the screen. It is proposed to have 04 layers of seating arrangement with stair like raised platform to achieve the clear visibility requirements. First two layers of Section controller and Dy. Controller working in the theater room will come within 7.5 meter,it is proposed to have clear visibility from these two rows, so7.5 meters has been taken as the maximum distance for the requirement of clear visibility.

1.3 Minimum text height:(a)To determine the critical height of the characters for easy readability and legibility, the maximum viewing distance ‘D’ from the display is first determined. Then the minimum size of the characters of the text is calculated, using the following formula:

H = D* tan (σ)

Video wall screen (3488mm)

Floor level

EYE 15 arc min A Height of Character

38 degree

degdegree Eye level Min distance for first row

(4465 mm) Height above Floor




D

(b) Where D is the distance of operator position and H is the height of character. ‘σ’ is visual arc angle subtended on eye by a character/symbol. As per ISO 11064 ‘σ’ should be minimum 15 minutes for clear visibility.

(c) The minimum height of character based on above, for a distance of 7.5 meters (second row) comes to 33 mm. (H = 7.5x tan (15/60) = 7.5x0.00436 i.e. 33mm)

(d) This shows that character of minimum 33 mm heightwith correct color,

contrast and back ground is clearly legible from a distance of 7.5 meters. Resolution of the screen: (a)This isanother main parameter affecting the size of the video wall since, it gives the information of number of pixels in unit length. For calculation, Full HD LED screens of resolution 1920x1080 of 70” (diagonal) has been taken as used in OCC at ALD. However, the size of Video wall screen will reduce if screen of higher resolution is used.

1550 mm 872mm Dimensions of one screen of 1920 X 1080 resolution

(b) Dimensions of one screen of resolution1920X1080is 1550 mm (W) x 872 mm (H). Number of vertical pixels per mm is = 1080/872 i.e.1.2 pixels per mm.As per calculation minimum character height is -33 mm. So text size shall be of 33*1.2 = 40 pixels.

(c) By using character of 40 pixels (on a screen of resolution 1920x1080) the number of video wall required will be calculated. Now by keeping the pixel to be minimum 40 and representing all necessary symbols/information in the display, the total pixels required for one station and one auto block section is calculated and then further for the entire arrangement.

(d) The major focus while doing the calculations is on the horizontal pixel arrangement, as sufficient space is available in the vertical section. One Screen of resolution 1920x1080 is further divided in blocks of 40x40 pixels for ease of calculation as one unit. One Video Wall screen will have 48 horizontal & 27 vertical such blocks.

2. Calculation of Screen size for CTC system

Based on above parameters for calculating screen size for CTC system, the whole depiction is divided in two parts. One is Auto section and other is Station section. LC gates & train identity are also covered in auto section.

70” diagonal




2.1 For Auto Section

In one auto section information of signal aspect, train ID, track circuit status and LC gate is required to be displayed.

(a) As per the viewing requirement explained above, Max. 4 blocks of 40x40 pixels each required to represent one 4 aspect auto signal i.e. 4x40=160 pixels/Signal. Signal number will be displayed just above the signal with in the same length.

(b) Train ID (8 digits) requires minimum 06 Blocks i.e.06x40=240 pixels. (c) One track circuit status can be displayed in each auto section. (d) Length of one Auto Section requires minimum 06 blocks of 40x40 pixels each

to represent the information of one signal including track circuit status, train ID and LC gate i.e. 06x40=240 pixels. Typically inter signal distance of auto signals is 01 Km, the minimum display length of one auto section is 240 pixels/Km. Even if the intersignal distance is less or more than 01 Km in auto section, the minimum display length for one auto section will remain same as 240 pixels.

(e) Based on above, Minimum width of one Auto Block section required is 240

pixels and Height of section required = 160 pixels.

2.2 For Station Section In station section information of signal aspect, point status, track circuit status, and LC gate is required to be displayed. To depict this information for a way side station of 04 lines having emergency crossover at both ends, minimum 07 blocks of 200 pixels each are required. So, total pixels required = 7x200=1400 pixel/Station. This will increase or decrease depending upon the actual length of the station.

Fig: Typical requirement for depicting one station

3. Screen size for Typical Section of 300 Km with 40 Stations & remaining auto section: Based on above results the screen size for a typical section of 300 Km with approx. 40 stations and auto signaling is being calculated including SCADA system.

1

01 block of 200pixels

2 3 4 5 6 7




3.1 For CTC system

(a) Length of one station section is taken approximately 1.8 Km.For 40 Station the

total length is 40x1.8=72Km. Balance length of Auto Section = 300 – 72 =228 Km. With inter signal distance of 01 km there will be 228 auto sections.

(b) For 40 Stations total pixels required are 40x1400=56000, as 1400 pixels are required for one station and for 228 blocks of auto signal, the total pixels required are 228x240= 54720 pixels. Total pixel requirement for the typical section is 56,000+54720= 110720 pixels.

(c) Since, resolution of each screen is 1920 pixels, total No. of Video Wall Screens

required will be = 110720/1920 = 57.7. Arranging one above other in 4 rows, we will require 57.7/4= 14.41Video Wall screens i.e. approx. 14 Video Wall screens in each row.

(d) Size of one screen in mm is 1550x872(mm) so total length required for placing

14 screens is – 14x1550= 21700 mm and total Height is- 4x872= 3488 mm as shown below

1st Row

1 ----------------------------------------------------------

14

2nd Row

15 ----------------------------------------------------------

28

3rd Row

29 ----------------------------------------------------------

42

4th Row

43 ----------------------------------------------------------

56

21700mm

(e) Size of CTC Video Wall with 14 x 4 screen configuration for 300 km section

length having 40 stations and 228 km auto section comes to 21700mm (W) and 3488mm (H). i.e. 21.7 meter x 3.488 meter.

3.2 For SCADA system

(a) Similarly, the calculation of screen size for the display of SCADA system is also done. Based on the data taken from the video wall for SCADA at OCC Allahabad, following minimum pixel requirement is taken to represent different parts of overhead catenary system

Sl. No.

Location Pixels Required (Horizontal)

Pixels Required (Vertical)

1 TSS 580 1080

2 SP 510 1080

3 SSP 345 1080




4 Stations Varies, approx. 280 Varies, approx. 440

(b) For the typical section of 300 Km with 40 stations and 04 TSS, 08 SP, 12 SSP

(No. taken approximately) the horizontal requirement of pixels is as given below:

Sl. No.

Location Pixels Required (Horizontal)

No. of Locations

Total pixel Requirement

1 TSS 580 04 2320

2 SP 510 08 4080

3 SSP 345 12 4140

4 Stations Varies, approx. 280 40 11200

Total 21740

(c) For total pixels 21740 for SCADA system, No. of Video Wall Screens required

is = 21740/1920 = 11.32. Arranging one above other in 4 rows, we will have 11.32/4= 2.83 Video Wall screens i.e.03 Video Wall screens in each row.

(d) Size of one screen in mm is 1550x872(mm) so total length required for placing 03 screens is –03 x1550= 4650 mm and total Height is- 4x872= 3488 mm as shown below

1st Row 1 2 3

2nd Row 4 5 6

3rd Row 7 8 9

4th Row 10 11 12

(e) Size of SCADA Video Wall with 3 x 4 screen size for this typical section comes

to 4650mm (W) and 3488mm (H).

3.3 Total video wall screen size required for 300km section length having 40 Stns and 228 km auto section for CTC and 04 TSS, 08 SP, 12 SSP for SCADA system is 21700 + 4650 = 26350mm. (Approx. 27mtrs length)

3488 343488888




Annexure-IV

Methodology of Integration between CTC and COA Systems

In order to integrate both the systems, handshaking will be required to uniquely identify the train in COA system. Prima facia, there are two methods to integrate the systems. The details are as follows: 1. CTC shall provide the Train Number and Schedule date of train arrival at Station in case of

Passenger trains and Loco Number (which is attached to the train) in case of Goods trains.

The data in the following format will be required to update train movement in COA system by

invoking the Oracle stored procedure by CTC:

S.No. Data Element Type and Size

1. Train Number VARCHA R2 (6)

2. Train Schedule date at Station VARCHA R2 (10)

3. Loco Number VARCHA R2 (6)

4. Station Code VARCHAR2 (4)

5. Arrival/Departure Status Flag CHAR (1)

6. Arrival/Departure Time VARCHAR2 (16)

7. Line Number NUMBER (2)

2. The detail of the trains approaching to CTC territory along with unique Train ID of COA

system with following details can be provided by COA to CTC system by invoking the Oracle

procedure by CTC:


1. Train ID VARCHA R2 (22)

2. Train Number/Name VARCHA R2 (30)

3. Train Schedule date at station VARCHA R2 (16)

4. Loco Number VARCHAR2 (20)

5. Direction VARCHAR2 (4)


7. Arrival/Departure Status Flag CHAR (1) The CTC system needs to store the data provided by COA and accordingly map the respective train at entry point of CTC system and subsequently, same Train ID shall be used to send following data to COA by invoking the Oracle stored procedure by CTC:


1. Train ID VARCHA R2 (22)

2. Train Number VARCHA R2 (6)

3. Train Schedule date at station VARCHA R2 (10)

4. Loco Number VARCHAR2 (6)


6. Arrival/Departure Status Flag CHAR (1)

7. Arrival/Departure Time VARCHAR2 (16)

8. Line Number NUMBER (2)




Annexure-V 1. Stage 1 Protection (Power line protection at Distribution Level):

The protection of class 'B' type, against Lightning Electromagnetic Pulse (LEMP) & other high surges shall be provided at the power distribution panel. Wherever available, the modules shall have an indication function to indicate the prospective life and failure mode to facilitate the replacement of failed SPDs. The device shall be spark gap type and certified as per the VDE 0675 A1/A2 & IEC 61643. It shall be provided with a 63 Amp fuse in phase line. The protection shall be in compliance of IEC 61312, IEC 61024 & VDE 0100-534 with the following characteristics:

SN Parameters Limits

Line & Neutral

Neutral & Earth

1 Nominal Voltage (U0) 230V 230V

2 Maximum continuous operating voltage (Uc) 255V 255V

3 Lightning Impulse current between R, Y, B & N (Imp)

50KA,

10/350s for each phase

--

4 Lightning Impulse current between N & E (Imp)

-- 100KA,

10/350s

5 Response time (Tr) 100 ñs 100 ñs

6 Voltage protection level (Up) between L & N 1.3KV --

7 Voltage protection level (Up) N & PE -- 1.5KV

8 Short circuit withstand and follow up current extinguishing capacity without back up fuse (Isc)

10KA --

9 Operating temperature / RH 70O C / 95% 70O C / 95%

10 Mounted on din rail din rail

2. Stage 2 Protection (Power line protection at Equipment Level):

The protection of class 'C' type against low voltage surges shall be provided at the equipment input level connected between line & neutral. This shall have an indication function to indicate the prospective life and failure mode to facilitate the replacement of failed SPDs. This shall be thermal disconnecting type and equipped with potential free contact for remote monitoring. The device shall be a single compact varistor of proper rating and in no case a number of varistors shall be provided in parallel. This protection shall be in compliance of IEC 61643-12, 61312 & 61024 and VDE 0100-534 with the following characteristics:

SN Parameters Limits

1 Nominal Voltage (U0) 230V

2 Maximum continuous operating voltage (Uc)

300V

3 Nominal discharge current between 10KA, 8/20s for each phase




R,Y,B & N (In)

4 Maximum discharge current between L & N (Imax)

40KA, 8/20s

5 Response time (Tr) 25 ñs

6 Voltage protection level (Up) at In 1.6 KV

7 Operating temperature / RH 70O C / 95%

8 Mounted on din rail

3 Stage 3 protection (Protection for Power /signalling / data lines)

All external Power/signalling/data lines (AC/DC) shall be protected by using preferably pluggable stage 3 surge protection devices which consists of a combination of varistors /suppressor diodes and GD tube with voltage and current limiting facilities.

4 Power line Protection (Class D)

The device for power line protection shall be of Class D type. This shall have an indication function to indicate the prospective life and failure mode to facilitate the replacement of failed SPDs. This shall be thermal disconnecting type and equipped with potential free contact for remote monitoring. This protection shall be in compliance to IEC 61643-1 and VDE -0675 Pt. 6 with following characteristics:

Nominal Voltage (U0) 24V 48V 60V 110V 230V

Max. continuous operating voltage (UC)

30V 60V 75V 150V 253V

Rated load current (IL) 16A 16A 16A 16A 16A

Nominal discharge current

(In) 8/20 s 700A 700A 700A 2.0KA 2.5KA

Max discharge current (Imax)

8/20 s 2KA 2KA 2KA 5KA 5KA

Voltage protection level (UP) 200V 350V 500V 700V 1100V

Response time (Tr) 25 ñs 25 ñs 25 ñs 25 ñs 25 ñs

Note: Minor variations from above given parameters shall be acceptable.

5 Signalling/Data line protection

These devices shall preferably have an indication function to indicate the prospective life and failure mode to facilitate the replacement of failed SPDs. If the device has any component which comes in series with data/ signalling lines, the module shall have "make before break" feature so that taking out of pluggable module does not disconnect the line. This protection shall be in compliance to IEC 61643-21 & VDE 0845 Pt. 3 with the following characteristics:

Nominal Voltage(U0) 5V 12V 24V 48V

Arrester Rated Voltage(UC) 6V 13V 28V 50V

Rated load current(IL) 250mA 250mA 250mA 250mA

Total discharge current, 8/20 s ( In) 20KA 20KA 20KA 20KA

Lightning test current 10/350 s 2.5KA 2.5KA 2.5KA 2.5KA

Voltage protection level (UP) 10V 18V 30V 70V




Note: Minor variations from above given parameters shall be acceptable.

6. If power supply /data/signalling lines (AC/DC) are carried through overhead wires or cables above ground to any nearby building or any location outside the equipment room, additional protection of Stage 2 (Class C) type shall be used at such locations for power supply lines and Stage 3 protection for signal / data lines.

7. Coordinated type Class B & C arrestor shall be provided in a separate enclosure

adjacent to each other. This enclosure should be wall-mounting type. 8. Length of all cable connection from input supply and earth busbar to SPDs shall be

minimum possible. This shall be ensured at installation time. 9. Stage 1 & Stage 2 (Class B & C) protection should be from the same

manufacturer/supplier. Manufacturer shall provide Stage 1 & Stage 2 protection. Stage 3 protection shall be got provided by Railways separately.

10. The cross sectional area of the copper conductor for first stage protection shall not be <16 mm2 and for second stage shall not be < 10mm2

11. Batch test report of OEM should be submitted by the manufacturer /supplier of

Lightning & Surge protection devices to RDSO at the time of acceptance test of equipment.

research designs & standards organisation manak … · 2020. 8. 4. · event log and alarm...

Documents