Railway (Best)

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

Software Requirement Specification For Control Office Application

Project

:

Control Office Application (COA)

Customer

:

Centre for Railway Information Systems(CRIS)

Page 1 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

Project Code:

COA_CRIS

Project Name:

Control Office Application for CRIS

Account:

CRIS

Vertical:

E-Governance Solutions

Location:

Delhi

Customer Name:

Centre for Railway Information Systems(CRIS)

Technical Manager/ Email ID:

Jeyaseelan J [email protected] Praveen Kumar Rajuladevi [email protected] Santosh Dharwadkar [email protected] Mr.Rajeev Gupta –GGM(IT) Centre for Railway Information Systems

Project Manager / Email ID: Quality Co-ordinator / Email ID: Customer Contact Information:

Chanakya Puri New Delhi

Prepared by/Date

Reviewed by/Date

Approved by/Date

Praveen Kumar Rajuladevi

Mr.Rajeev Gupta/ 05-Jul-2005

Mr.Rajeev Gupta/ 05-Jul-2005

Page 2 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

Revision History Version (x.yy) 1.0

Date of Revision 11-April05

1.1

05-July-05

Description of Change Draft Version for submission to CRIS Included Browser based access to MIS reports

Reason for Change

Affected Sections

Approved By

URD reqmnt

Page 3 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

Table of Contents (Re-generate the TOC after modifications to the document)

1 Background and Introduction.................................................................................6 2 Functional Requirements........................................................................................7 USE-CASE Specification – User Login......................................................7 2.1.1 Basic Flow – User Login ...............................................................................................................7

USE-CASE Specification – Order a Train .................................................8 2.1.2 Basic Flow – Train Ordering............................................................................................................8 2.1.3 Alternate Flow ..............................................................................................................................10

USE-CASE Specification – Maintain Train Information..........................17 2.1.4 Basic Flow – Maintain Train Information. ....................................................................................17

USE-CASE Specification – Train Movement...........................................26 2.1.5 Basic Flow – Manage Train Movement. .......................................................................................26

USE-CASE Specification – Report Unusual Occurances.........................39 2.1.6 Basic Flow ....................................................................................................................................39 2.1.7 Alternative Flow............................................................................................................................56

USE-CASE Specification – Management of Maintenance Blocks...........57 2.1.8 Basic Flow – Maintenance Blocks.................................................................................................58 2.1.9 Alternative Flow............................................................................................................................62

USE-CASE Specification – Caution Orders..............................................63 2.1.10 Basic Flow – Caution Order........................................................................................................63 2.1.11 Alternative Flow..........................................................................................................................66

USE-CASE Specification – Plot Graph ....................................................67 2.1.12 Basic Flow – Plot Graph .............................................................................................................68 2.1.13 Alternative Flow..........................................................................................................................70

USE-CASE Specification – Advance Plotting..........................................71 2.1.14 Basic Flow – Advance Plot .........................................................................................................72 2.1.15 Alternative Flow..........................................................................................................................72

USE-CASE Specification – Create/Maintain Referential Data.................82 2.1.16 Basic Flow – Maintain Referential Data .....................................................................................82

USE-CASE Specification – MIS Reports..................................................83 2.1.17 Basic Flow – MIS Reports...........................................................................................................83

USE-CASE Specification – Yard Management........................................93 2.1.18 Basic Flow – Manage Yard. .......................................................................................................93

USE-CASE Specification – Security & Administration...........................94 2.1.19 Basic Flow – Manage User .......................................................................................................95

USE-CASE Specification – Miscellaeneous Functions............................97 2.1.20 Basic Flow – Reporting Miscellaneous Tasks ...........................................................................97 2.1.21 Alternative Flows.........................................................................................................................97

USE-CASE Specification – ......................................................................98 2.1.22 Basic Flow – ...............................................................................................................................99 Integration with NTES...........................................................................................................................99

USE-CASE Specification – Instantaneous Alerts - SMS.......................102 Page 4 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS 2.1.23 Basic Flow – .............................................................................................................................102

USE-CASE Specification – Integration with Data Loggers....................104 2.1.24 Automatic Train Ordering..........................................................................................................105

3 Operational Concepts and Scenarios..................................................................106 Distributed Architecture:.........................................................................106 Highly Available System:........................................................................108 Evolutionary MIS:...................................................................................108 Security of the System.............................................................................109 4 Interface Requirements.......................................................................................110 Hardware Interfaces.................................................................................110 4.1.1 Dual Screen Capability................................................................................................................110 4.1.2 Chart Printing..............................................................................................................................110

Browser based access to MIS Queries/Reports.......................................111 5 Non functional/Specific Requirements...............................................................113 Risks 114 6 Assumptions/Dependencies/Limitations.............................................................118 7 Acceptance Criteria..............................................................................................119 8 Allocation of System Requirements....................................................................120 9 Others....................................................................................................................121 10 Acronyms and Glossary.....................................................................................121 11 Signoffs................................................................................................................122

Page 5 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

1 Background and Introduction Indian Railways comprises of about 70 divisions which are the operational arms and responsible for day-to-day operations . The divisional control office is the nerve centre for all activities related to train running. It has the following functionaries -

Chief Controller controlling overall train movement and related activities. Stock Controller for planning the demand and supply of wagons Dy Trains for planning and control of freight train movement Dy Punctuality for monitoring punctuality of passenger trains. Power controller for arranging locomotive and crew for trains. Section Controller for regulating the movement of all trains over a specified jurisdiction.

The duties of the Section Controller are very strenuous in nature involving high level of documentation work in addition to his primary duty of planning and reporting the movement of trains.The present system of operational practices also/ involves a lot of paper work by support staff to convert the operational related information from the Control Chart into various registers. Thus the core activity of advance plotting and timely reporting of movements is hampered . Thus, the management is forced to rely only on selective information about various events for decision making. In view of the above scenario, Indian Railways has prioritised the need to automate these operations and identified the need for technology enabled services as part of its automation strategy to achieve operational efficiency. The benefits of such an automated system would be - Integration of various distributed systems in a cost effective manner - Better operational efficiency and productivity by replacing manual processes with automated processes. - Establishment of faster and better interfaces with the consumers by streamlining of processes and enhancement of information availability - Greater cohesiveness among various divisions Divisional Control Office Operations Application (COA) is as an application capable of collaborating with FOIS/ NTES and Charting front end and other planned sub modules on an All-India basis. This would facilitate prevention of duplication of efforts, maintain uniformity of data and ensure that investments already made in these applications are fully utilized, thereby leading to a best value for money solution. The following considerations are being addressed while designing the architecture of COA.

Page 6 of 122



REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2 Functional Requirements USE-CASE Specification – User Login The purpose of this use case is to allow user to login to the system. The authenticity of user shall be checked and access to various functions shall be given as per his assigned group. Actors 1. Primary Actors 1.1 Section Controller 1.2 Dy. Trains 1.3 Dy. Coaching 1.4 Power Controller 1.5 Yard Manager 1.6 MIS User 2. Secondary Actors Flow Of Events 2.1.1 Basic Flow – User Login The use-case starts when user gets login screen on clicking COA icon or on selecting logout option. • User shall give user-id, password and Shift details. • On submitting, user details shall be validated. • If validation fails Message shall be displayed. Use-Case ends. • If valid,  Menu screen shall be displayed with options enabled as per group assigned at the time of user creation.  Any information to be given on login shall be displayed through an alert displayed on main menu screen.  In case a user is assigned more than one section highest priority section shall be enabled at the time of login with facility of changing the section any time after logging into the system. An indicative screen for the above functionality is illustrated below

Page 7 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.1.1 Pre-Conditions • User database information should be available.

USE-CASE Specification – Order a Train The purpose of this use case is to allow for entry of train details in to the system. Any changes in train details of existing trains shall also be facilitated through this use case. 3. Primary Actors 3.1 Section Controller (SC) 3.2 Dy. Coaching 3.3 Dy. Trains(Stock) 3.4 Data Logger 4. Secondary Actors 1.1 CAS System Flow Of Events 2.1.2 Basic Flow – Train Ordering. This use case starts when Section Controller selects “Order a Train” from the menu. The screen displays the available options. The options available are Page 8 of 122

•

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS (i) Add New Train (ii) Modify Train (iii) Cancel Train (iv) Link Trains 2.1.2.1 Add New Train User selects Add New Train only in cases where train does not exist in the system. Adding of Train shall be allowed within some pre-defined time interval before the departure of the train(To avoid overlap with train information coming from CAS). • The screen is displayed to enter train details. • List of trains available through CAS system but not linked to trains in this system shall be displayed (To avoid double entry of trains) • User can either select train or enter new train details. • If user selects train, available train details such as Train number/name, Train Type, Train Sub-Type, Originating Station, Destination Station, Day(s) of service (only for new passenger services), Expected Departure Time (ETD) shall be displayed. The user can modify only the ETD . Details of Division Entry Station, Division Exit Station (Interchange point) and Route shall be displayed by default. • Alternatively if the user does not select any train, he shall enter Train number/name, Train Type, Train Sub-Type, Originating Station, Destination station, Day(s) of service (only for new passenger services), Booked speed of the train (only for Goods) and Expected Departure Time (ETD). In the case of trains originating from non-computerized divisions, the user shall select the Division Entry Station, Division Exit Station (Interchange point) and Route • Whenever a Light Engine is ordered to proceed to an accident spot, the relevant sub-type shall (Traffic/Loco/ART) be selected. User shall submit the details. • System shall validate the from/to station and handing over station against a referential table containing all stations (populated from FOIS). • If validation fails,  Alternate flow Invalid Station is followed. • If valid,  System shall save the information.  System shall generate Train Id. for the train saved and that shall be the system identification number.  System displays a confirmation message. Plot Graph / Automatic Ordering. System shall display a dot on the plot graph in the display screen at pre-determined configurable time in advance of the expected departure time for scheduled passenger services and goods trains ordered by the system including those trains coming from the adjacent division. Refer Plot Graph use case. A screenshot illustrating the User Interface elements is shown below Page 9 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.3 Alternate Flow

2.1.3.1 Modify Train This option will enable the Section Controller or the Dy.CHC (Trains) or Dy.CHC (Punctuality) to modify only the Expected Time of Departure. The screen displays following options: (i) Passenger Trains (ii) Other Trains. • On selecting any one of the above options by default a complete list of trains due to depart within a configurable interval shall be displayed on the screen sorted by ETD and direction. • The user shall select one or more trains and then click on one of the following options Put Back/Forward Trains Page 10 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS  User can select any one of the following options (i) Put Back (ii) Put Forward.  If more than one train is selected, user shall enter No. Of hours/minutes by which each train is to be Put Back/ Put Forward  If a single train is selected user shall enter modified departure time.  User shall then submit modified Train Details.  When a train is put forward, the system shall validate that the revised ETD is not earlier to the current system time.  If validation fails,  Message is displayed. Use Case ends.  If valid,  System shall save the information.  System displays a confirmation message.  The modified ETD shall get displayed on the screen. An indicative screenshot illustrating the User Interface elements is shown below

Page 11 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

Change Of Destination   then

Section Controller shall enter new destination station. If there is change in the route but destination is in the current division

 User shall select required route.  User shall also give authorization details.  If there is change in the route but destination is in other division then  The system shall display all the divisional exit stations.  The User shall select the corresponding exit station.  User shall then select required route.  User shall also give authorization details.  User shall then submit the modified Train Details.  System shall validate destination station and division exit station.  If validation fails,  Alternate flow Invalid Station is followed.  If valid,  System shall save the information. System displays a confirmation message. An indicative screenshot illustrating the User Interface elements is shown below

Page 12 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

Diversion Diversion task shall be invoked when there is change in the route in current division but no change in destination.  If there is change in the route and destination is in the current division then  User shall select required route.  User shall also give authorization details.  If there is change in the route and destination is in other division then  User may give division exit station (Interchange Point).  User shall then select required route.  User shall also give authorization details.  User shall then submit modified Train Details.  System shall validate division exit station.  If validation fails,  Alternate flow Invalid Station is followed.  If valid,  System shall save the information.  System displays a confirmation message. An indicative screenshot illustrating the User Interface elements is shown below

Page 13 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

. Cancel Train Only the Dy. CHC (Trains) in respect of goods trains and Dy.CHC (Punctuality) can cancel a train whose departure is scheduled for that day or within a specified time interval and which has not yet departed. • The screen displays following options: (i) Passenger Trains (ii) Other Trains. • On selecting one of the above options, by default, the list of trains scheduled to depart over the Division for a configurable time interval shall be displayed on the screen. • The user shall select one or more trains for cancellation. • The user shall select the reason code from the pre-defined list for cancellation. If reason code is OTHR, specific details shall be entered. The user shall then save the details. Page 14 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS If successfully saved, System displays a confirmation message. • On saving, modified data shall be sent to CAS for updating the external/adjoining database. An indicative screenshot illustrating the User Interface elements is shown below

Link Train Linking is facilitated to be done between trains created in COA and train details that would come through CAS system from other applications like FOIS or from COA of a contiguous division. • • • •

A list of trains received from CAS system and trains created through this system shall be displayed. A train shall be selected from the list under CAS system, dragged and dropped on to COA trains list using identification parameters like Train Name, From Station, To Station, ETD and other details. It shall be possible to drag and drop multiple trains. The user may also de-link a train by dragging out the linked train from COA list, in case of error in selection.

Page 15 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS • 

A list of linked trains shall be shown to the user, on confirmation, the details shall be saved. System displays a confirmation message.

An indicative screenshot illustrating the User Interface elements is shown below

• •

Invalid Station In case station is not found message shall be displayed. Station entry may be corrected and submitted again or use case ends here. • •

Pre-Conditions Section Controller should have successfully logged on to the system. Static database information should be available. Post-Conditions • Graph should be refreshed whenever a new train is created or there is change in the details of a train. Business Rules

Page 16 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS • If train is coming from non-computerized control charting territory, train shall have to be created afresh in this system. Assumptions • Data from external systems should be available to this system through CAS server.

USE-CASE Specification – Maintain Train Information The purpose of this use case is to allow adding or updating details in respect of ordered/running trains. The information captured through this use-case shall include locomotive attachment/detachment, consist reporting, crew reporting and BPC reporting. These details may be entered even after the departure of a train. Actors 1.Primary Actors a)Section Controller b)CAS System 2.Secondary Actors Flow Of Events 2.1.4 Basic Flow – Maintain Train Information. The use-case starts when user selects “Maintain Train Information” option from the menu. • The following options shall be displayed to the user. (i) Trains To depart (ii) Trains Running • On selecting the option “Trains to depart”, the list of trains expected to depart within a pre-defined time interval shall be displayed on the screen. • On selecting the option “Trains running”, the list of trains running within the section based on specified direction shall be displayed on the screen. • On selecting a train from the list, the available train details shall be displayed on the screen. • The train details displayed shall include train number/name, train type, direction, from station, to station. The following options shall be available to the user for entering/updating train information. (i) Loco Attachment/Detachment (ii) Consist Reporting (iii) Wagon/Coach Attachment/Detachment (iv) Crew Reporting (v) BPC Reporting.

Page 17 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS 2.1.4.1 Loco Attachment/Detachment This screen captures all the details related to Loco Attachment/ Detachment for the selected train. •

•

User shall have the following three options (i) Attach (ii) Detach (iii) Re-Sequence If User selects Attach option then User shall select the train number. User shall enter the Loco number(s).  If Loco Type, Traction, Brake Type, Base shed, Schedule type, last attended/ Next due date are available, these details shall be displayed.  If loco number is not available in the database, then user shall enter the loco details.  The system shall provide for attaching one or more locomotives.  If more than one locomotive is attached, the position of the locomotive, working mode (double heading/Multiple operation/Banker) and working status (Working or Dead) shall also be captured.  The user shall select the station where the loco attached, reason code and attachment date/time If User selects Detach Option then  User shall select the train number  The system shall display row wise the loco number(s) attached to the selected train. The user shall select the loco number to be detached. Details of selected loco shall be displayed explicitly on the screen.  User shall then give details of detachment station, reason code and detachment date/time. • If user selects re-sequencing then User shall select the train number  The system shall display row wise the loco number(s) attached to the selected train in the order of their position.  The user shall have the facility to drag and drop any of the rows, which shall cause the re-sequencing of the position.. • In case of change of loco en-route, the detachment task shall precede the attachment task. On saving  System shall save the information.  System displays a confirmation message.  Saved changes details shall be shown on screen. An indicative screen is illustrated below.

Page 18 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.4.2 Consist Reporting This screen captures all the Consist details for the selected train. • If train type selected is Freight and consist details are available through CAS  Details of consist shall be displayed (rake type wise) on the screen.  In case the user desires to modify any consist details, he shall select the required row corresponding to the particular rake type which shall cause corresponding details to be displayed  User can change the details displayed on the screen.  By default, the reporting station shall be the train-originating station but the user can change the reporting station.  4W units shall be displayed automatically by the system.

Page 19 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS Summary line shall be displayed at the bottom of screen. It shall display total no. of wagons/total 4 wheeler units/total gross weight of the train If train type selected is Freight and consist details are not available through CAS  User shall select one of the following options (i) Summary Reporting (ii) Rake Type-Wise Reporting  In case of summary reporting, the user shall enter total number of wagons and total gross weight.  In case of rake type-wise reporting user shall enter consist details like Reporting station, Rake Type, Loaded/Empty, Units, from Station, To Station, Gross weight and commodity.  By default, the train originating station shall be the reporting station, but the user can select any other station.  User shall click Next for entering more than one rake type by the train, which shall cause a new row to be added. The rake type shall be selected by the user from the pre-defined list maintained as a referential table by populating the data from FOIS.  Summary line shall be displayed at the bottom of screen. It shall display total no. of wagons/total 4 wheeler units/total gross weight. 

•

If train type selected is Passenger and consist details are available.  The user shall select the train number.  The details such as owning railway, coach type, coach number and coach position shall be displayed on the screen.  In case the user wants to modify any consist details, he shall select the required row and modify the details.  By default the originating station of the train shall be the reporting station, but the user can change it by selecting any other station  Summary line shall be displayed at the bottom of screen. It shall display total no. of coaches/total 4 wheeler units/gross weight of the train. • If train type selected is Passenger and consist details are not available.  The user shall enter consist details like Reporting station, Owning railway, Coach Type, Coach Number (optional), Reservation coach position, From Station, To Station.  The originating and destination station of the train shall by default be the from and to station. The user can enter any other station name.  The originating station shall be the reporting station by default but the user can change it.

Page 20 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS Summary line shall be displayed at the bottom of screen. It shall display total no. of coaches/total 4 wheeler units/gross weight of the train.  User shall click ‘Next’ for subsequent entries After entering/modifying consist details the user shall save the details. On saving, from station, to station shall be validated.  If validation fails,  Alternate flow Invalid Station is followed.  If valid, System shall save the information. System displays a confirmation message. 

•

•

   An indicative screen is illustrated below

Page 21 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS 2.1.4.3 Wagon/Coach Attachment/Detachment This screen allows for capturing attachment/detachment details for wagons/coaches for selected train. • Details of consist shall be displayed on the screen. Consist may be in summary or detailed form. • User shall select whether attachment or detachment is to be done. • User shall select the required row (rake type wise in case of a goods train) and corresponding details shall be displayed on the screen. • User shall then enter the number of wagons/coaches to be detached or attached, if the details are in summary format. • User shall also select the reason code, attachment/detachment station, line number (only when detaching) and date/time of attachment/detachment. • User shall then submit the details. • In case of detachment of wagons/coaches at a station, the stock inventory at the station and the line occupation status shall also get updated. If successfully saved, System displays a confirmation message. Details displayed on screen to reflect the saved changes. An indicative screen is illustrated below

Page 22 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.4.4 Crew Reporting This screen allows for capturing crew details for the selected train. • User shall select one of the following options (i) Sign On (ii) Modify • If user selects Sign On option  The user shall enter the crew details such as crew name, crew type, working from station, working to station and sign on time.  In case of more than one engine on the train, the user shall click ‘NEXT’ which shall cause a new row to be added for entering the details.  In case of change of crew en-route, working to station against the first crew shall be filled up before the details for the second crew is entered. • If user selects modify option  Crew details shall be displayed locowise on the screen.  User shall select the required row and modify any of the details displayed on the screen. • User shall then submit details. Page 23 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS •

 

On saving, from station, to station shall be validated.  If validation fails,  Alternate flow Invalid Station is followed.  If valid, System shall save the information. System displays a confirmation message. An indicative screen is illustrated below

2.1.4.5 BPC Reporting This screen shall allow for capturing/modifying BPC details for the selected train. • On selection of this option, if the BPC details of the train are available, the same shall be displayed on the screen. • User can modify only the Balance Kms (valid for) in case of a CC rake.

Page 24 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS •

•

On saving.  

If the BPC details are not available, User shall enter the Station of Issue, BPC No, Date, % Brake Power, Valid From, Valid To, Std of Exam, BPC Type, Base Station, Days Valid For and Kms Valid for. System shall save the information. System displays a confirmation message.

An indicative screen is illustrated below

• • •

Invalid Station In case station is not found message shall be displayed. Station entry may be corrected and submitted again or use case ends here. Pre-Conditions Section Controller should have successfully logged on to the system. • Detachment of loco option shall be enabled only when at least one loco is attached to the train. • Static database information should be available. Page 25 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

• •

Post-Conditions Changes saved should be shown on the screen after successful save. Changes in any of details shall affect the graph. Business Rules • If train is coming from non-computerized control charting territory, train shall have to be created afresh in this system. The various details pertaining to the train such as consist details, loco details, BPC details, Crew details shall also have to be entered.



Assumptions Data from external systems should be available to this system.

USE-CASE Specification – Train Movement This use case shall capture arrival and departure or run through of trains at a station, details of stabling, detentions and their reasons, facility to change priority for trains in case of necessity, special movement practices involving track machine and material trains. The details captured through this use-case shall be the input to plot graph use-case. These details may be entered even after the departure of train. (To be configured locally) Actors 1.Primary Actors a)Section Controller b)Data Logger 2.Secondary Actors a)CAS System Flow Of Events 2.1.5 Basic Flow – Manage Train Movement. The menu defined by this use-case shall be the default option in the touch screen. The list of running/ordered trains over the board shall be displayed direction wise separately for selection. On selecting the train number, the current location of the train shall be displayed The user shall then select any one of the following options:  Report Arrival/Departure/ Run Through  Line Occupation (Optional)  Detentions  Priority change  Abnormal Working (Optional)

Page 26 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS 2.1.5.1 Report Arrival/Departure/Run-Through Through this screen details of arrival/departure/run-through shall be captured for trains currently running on the board.In the data logger mode, the details pertaining to above activities shall be system driven through the interface software. In the manual mode, If the tracking of the selected train is current (up to the last station), then • User shall select the relevant option through mouse click or hot key. • He shall enter the corresponding timing at that station. • System shall compare the actual inter station running time with the permitted running time (over the block section) or actual duration of stoppage against booked stoppage(at a station) and calculate the difference between the actual and the scheduled. • System shall indicate the Loss (+) or Gain (-) and record it against the block section or station. The loss shall be indicated in red and gain in green color preceded by + or – sign. • The system shall also provide facility to enter the reason for the loss/detention whenever immediately known. • When a train is delayed in a block-section beyond normal running time plus a margin of 10 minutes in case of a passenger train or 20 minutes in case of a goods train, the system shall throw an alert message to the user, which shall be acknowledged. (For subsequent flow, Refer Abnormal working use caseAccidents). If the tracking of the selected train is not current due to communication disturbances (timings at a station or a series of stations were not obtained), then  User shall select the relevant station over the section  User shall then select the train number based on the direction.  User shall then enter the corresponding timing at that station.  System shall compare the actual inter station running time or actual duration of the stoppage with the permitted running time or duration of stoppage (over the block section or at station as the case may be) and calculate the difference between the actual and scheduled. On saving,  System shall validate that the time reported for the event (arrival/departure/run through) is neither less than the last reported time nor greater than the system time. 2.1.5.2 Line Occupation This option shall enable the user to enter the line number in which the particular train was dealt with at a station. The information captured will be made use of to indicate the occupation of running line at various stations on real time basis. Page 27 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS In the data logger mode, the details pertaining to above activity shall be system driven through the interface software. In the manual mode, in case of occupation of a line by a full train • User shall select the train number and type • The station at which the arrival was reported last shall be displayed by default. • Only the line numbers that are free at the chosen station shall be displayed for selection. • The selected line shall be deemed to be occupied by the specified train till the time of clearance either by departure or removal to yard. • If a line has been blocked by a goods train either due to termination or for other reasons and remains to be occupied for more than 24 hours from the time of arrival, it shall be deemed as stabling. • When the line has been cleared by the departure of the train after a brief stoppage, the system shall reckon the time of departure as time of removal by default and cause the line to be shown again as “Clear”. • When the train has reached the destination or terminated at a station, the time of removal shall be entered by the user on receipt from the station / cabin with brief reason which shall cause the line to be shown again as “Clear”. • If a train is to be dealt with on a line which is shown as already occupied, then  User shall select the station.  The list of occupied lines at the selected station shall be displayed for selection.  The user shall select the line number and fill in the time of removal for the previous train. This shall cause the line to be shown as “clear”. The user shall have the facility to enter the new train number for the same line. When the user enters the new train number, the time of arrival of the train at the same station shall be the default time of occupation and also cause the line to be shown again as occupied. • In the case of outgoing train at a station, the nominated platform line shall be shown by default as the line occupied by the train from 30 mins before the scheduled departure. • The details of nominated line, train wise, station wise shall be maintained as part of the referential data. The line shall be deemed to be “Clear” with the actual departure of the train. • If some other train already occupies the nominated line, the user shall have the option to choose one of the unoccupied lines for the other train. In the manual mode, in case of occupation of a line by part of a train(one or more vehicles ) • User shall select the station. • Only the line numbers that are free at the chosen station shall be displayed for selection.

Page 28 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS • •

User shall enter the number of wagons and rake type/ coach type and the time of detachment (occupation) on the line. The selected line shall be deemed to be occupied by part of a train until the time of clearance either through attachment to another train or removal.

When the line has been cleared by attaching the above wagons/coaches to a different train or through other means, the user shall enter the train number to which they were attached, time and date of attachment, remarks( if any). The line shall be deemed to be clear from the time of attachment or removal. 2.1.5.3 Detentions This option shall facilitate assigning the exact reason for all detentions affecting a train on its run over the board. The options under this task shall include the following : • Detention on run – Instantaneous Reporting • Detention at Major Stations or Yards • Detention-Based on Guard’s LTM (Only for passenger services) Detention on run – Instantaneous Reporting When the cause of the detention at a station or block section, is instantaneously known to the Section Controller (through the station staff or Guard of the train), then  The user shall select the train number.  System shall display, by default, the station code or the block section code, where the loss has been computed.  If the arrival has been reported for a train, the default display will be only the preceding block section.  If the departure has been reported for a train, the default display will be only the preceding station.  If run through has been reported for a train, the default display will be only the preceding block section  It shall also be possible for the user to select any other station or block section from the graph display through GUI, where the train has suffered detention.  System shall display by default the exact detention(in minutes) .  System shall also display the pre-defined list of departments to which the detention is attributable and the user shall select the concerned department.  On selection as above, system shall display the pre-defined causes(pertaining to the department) for the user to select one or more of them. Page 29 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS



 System shall also facilitate adding any remarks.  System shall also provide for a new cause to be assigned (when not found in the pre-defined list).  If the total detention was attributable to more than one department, system shall facilitate multiple entries for each department, cause and detention. The total detention under various heads should not be less than the loss calculated by the system. User shall then submit details. o On successful saving,  Confirmation Message shall be displayed Detention at Major Stations or Yards







This option shall be chosen by the user to enter detention details at major stations and yards including originating station, enroute station where shunting is involved for attaching/ detaching wagonsor coaches. The user shall select the train number.  The user shall then enter the station code where the task is to be reported. In case of trains ordered but not departed, the ETD shall be displayed.  In case of trains on run, the Arrival time and Departure time shall be displayed for guidance, if already reported. The form shall include the following fields : Time from Time to Activity Remarks The system should provide for multiple entries at the same station covering all activities.  The system shall facilitate back reporting for this task upto a period of 2 hours.  The system shall also facilitate reporting of this event by any other actor like TNC or Dy.CHC. Detention-Based on Guard’s LTM When the cause of the detention at a station or block section is immediately not known to the Section Controller and subsequently obtained from the LTM given by the Guard of the train, then



The user shall open the LTM form.

Page 30 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS  The system shall display all train numbers based on direction for which the LTM has not been recorded (for a time interval of 6 Hours)  User shall select the Train number.  The system shall display the list of stations, block sections (over the route of the train pertaining to the board) and enable the user to enter the detention time against each. The system shall also display the list of departments to which the delay can be attributed and the user shall select one of them.  The system shall then display the possible causes under the particular department for the user to select one or more of them.  The user shall also have facility to assign any new reason not defined in the list.  In case the reason for a detention had not been instantaneously reported, the system shall assign the reason specified through the LTM form after validating the block section or the station to be the same. The sum total of detentions that was reported through the LTM task in the same block section or station should not be more than the detention shown by the system (as per charting).  In case, the sum total of detentions reported through the LTM task in the same block-section or station is more than the delay shown as per charting, the same shall be maintained separately.  If the reason assigned for any detention (through LTM task) is different from what had been assigned earlier, such details shall also be maintained train wise separately without overwriting the reason initially reported Reckoning of utilization or non-utilization of Allowances The following are the allowances provided as part of the inter-station running time (shown distinctly) over each section to set off the loss on account of speed restrictions and traffic causes. 1. Engineering allowance. 2. Traffic Allowance The utilization or non-utilization of the allowance where provided should be arrived at based on comparing the actual inter station running time with the inter station running time excluding all allowances as per WTT. Engineering allowance  A specified time is given (train wise) at the last block section or in more than one block section over the section.

Page 31 of 122



REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS  If loss had been calculated by the system due to one or more speed restriction in a block section, the default reason for the detention to be shown as CD.  If gain had been calculated by the system due to absence of a speed restriction in a block section (only where engineering allowance has been provided), the gain shall be assigned to CD.  The cumulative loss on account of speed restrictions alone (not other engineering failures) should be compared against the total engineering allowance for the train in the section to arrive at net loss or gain under ‘Engineering’. The gain under engineering shall always equal the allowance provided over the section for the train. Traffic Allowance  A specified time is given (train wise) at the last block section or in more than one block section over the section.  The loss due to traffic may be due to any of the events given below : o Unscheduled crossing or precedence o Detention at signal (block section) due to arrival of a train from opposite direction. o Acceleration/Deceleration for any unscheduled stopping.  The gain due to traffic may be due to any of the events given below : o Shifting of scheduled crossing including the time for acceleration/deceleration and stoppage at station. o Reduced time for scheduled crossing. o Starting a train from a station as per shifted timings (PTT). o Traffic allowance provided as per WTT at a station or block section not being availed. The gain under traffic will include the allowance and additional time made up on run as described above. Loco Gain / Loss  There is no system of providing any allowance under this category in the inter-station running time (WTT).  The loss on account of loco in a section can be due to: o Bad running by the driver of the train. o Engine defects o Excessive load over and above the hauling capacity of the engine. The gain on account of Loco can be due to: o Running at Maximum permissible speed by the Driver. o Excessive over speeding

Page 32 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS These details can be assigned by the system where explicitly known or obtained from the LTM and the loss or gain so reflected should get assigned to the (+) or (-) shown in the chart. Any gain of more than 3 minutes in the inter station running time should be reckoned as ‘suspected over speeding’ and cause a blinking of the plot over that segment, till acknowledged by the user. This shall be repeated for every block section. At the end of the section, the details of (engineering/traffic/loco gain or loss) shall get saved and shown in summary form for each train as a tool tip. 2.1.5.4 Priority Change This option shall enable the user to change the priority for a train within the same group and over other groups on a particular day to cater to specific operational needs. However, the running of trains will be defined by pre-assigned priority under normal circumstances.

•

In case of a need for assigning higher priority to a specific train within the same group, then The user shall choose one of the options : o Passenger o Other trains • The user shall then select the sub-group under the broad category (as above) and the system shall display the list of all running trains under the same group. • The user shall then rearrange the sequence order for a train (to be accorded the higher priority) through drag and drop feature. • The system shall then display a message seeking confirmation of the task. If the user confirms, the information shall be saved. The system shall also signify this train in the chart through suitable visual indication. • The system will cause all other trains within the defined group (based on relative position of the train) to wait for the prioritized train in case of a precedence/crossing. In respect of conflict with trains with lower or higher priority, the normal rules shall apply. • In a double line section, such kind of prioritization can be assigned for one train in each direction. • On successful saving,  Advance plotting graph shall get automatically refreshed. Refer to Plot Graph use-case. In case of a need for assigning higher priority to a specific train over all other groups, then • The user shall choose one of the options : o Passenger o Other trains

Page 33 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS • The user shall then select the sub-group under the broad category (as above) and the system shall display the list of all running trains under the same group. • The user shall then shuffle the priority group for a train (to be accorded the higher priority) through drag and drop feature. If the sequence within the higher group is also to be changed, the same shall be facilitated as explained earlier. • The system shall then display a message seeking confirmation of the task. If the user confirms, the information shall be saved. The system shall also signify this train in the chart through suitable visual indication. • The system will cause all other trains with priority lower than the specified train to wait in case of a precedence/crossing. • In respect of conflict with trains with higher priority, the normal rules shall apply. • On successful saving, o Advance plotting graph shall get automatically refreshed. Refer to Plot Graph use-case. 2.1.5.5 Abnormal Working This option shall enable the user to control the movement of trains during abnormal working situations and capture all essential data concerned with such movements. The following situations shall be grouped under abnormal working of trains :  Obstruction in Mid-section.  Train Engine failed in Mid-section.  Trains unable to haul its full load & Train parting.  Work on line – Material Trains/Track Machines/Tower wagon  Single line working on Double line. 2.1.5.5.1 Obstruction in Mid-section This option shall enable the user to capture the movement of a train back to the starting station owing to obstruction on the line (block-section).  The user shall select the train number  The user shall select the block section by default.  The time of stoppage at the mid-section and the location (in terms of KMs or OHE Mast) shall be entered.  The reason for stopping shall also be entered.  The time of restarting from the spot shall be entered.  On reaching the starting station, the time of arrival shall be entered.  The date and time of removal of the obstruction and the certifying authority shall also be captured.

Page 34 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS  The affected block section shall be shown as obstructed in the plot graph from the date and time of message until the date and time of removal of the obstruction. No other train shall be facilitated to enter the affected block section till the removal of the obstruction. 2.1.5.5.2 Train Engine failed in Mid-section. This option shall enable the user to capture the movements associated with failure of Train engine in a block section.  The user shall select the train number  The user shall select the block section by default.  The time of receipt of the message, location of failure and brief details of the message shall be recorded.  Any engine that is available closer to the location shall be made use of to clear the affected train from the block section. This would mean using the engine of a train (Exp or Pass or Goods) waiting for crossing/precedence.  The system shall validate that an engine of a waiting train cannot be sent for assistance unless detached from the said train. Like wise starting of a waiting train shall not be made possible unless an engine is attached to it.  The station from which the relief engine is sent shall be selected and the time of departure shall be recorded.  The time of arrival at the spot shall be recorded.  The time of departure from the mid-section shall be recorded. On arrival at either of the stations, the time of arrival shall be recorded along with the station code. 2.1.5.5.3 Train unable to haul its load & Parting This option shall enable the user to capture the movements associated with situations where the train is unable to haul its load or the train has parted in a block section.  The user shall select the train number  The user shall select the block section by default.  The time of receipt of the message, location and brief details of the message shall be recorded.  The time of departure of the front portion (haul able no. of wagons)shall be recorded.  On arrival at the station in advance, the time of arrival of the front portion shall be recorded.  The same engine or any other engine shall be sent from either of the stations to clear the rear portion.

Page 35 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS  The system shall validate that an engine of a waiting train cannot be sent for assistance unless detached from the said train. Like wise starting of a waiting train shall not be made possible unless an engine is attached to it.  The time of departure of the engine and the station from it was sent shall be recorded.  The time of arrival of this engine at the spot shall be entered.  The time of departure of the rear portion from the spot shall be entered.  The time of arrival of the rear portion at either of the stations shall also be recorded.  In case of clearance in more than two portions,entry of details shall be facilitated for each such movement.

2.1.5.5.4 Work on line – Material Trains/Track Machines/Tower wagon This option shall enable the user to capture the movements associated with work on line permitted in the block section for maintenance or unloading of materials etc.  The user shall select the train number from the list of running trains.  The user shall select the block section and the line (Up/Dn) where required.  The duration for which the work on line is permitted, reason and the station where the train/machine shall clear section shall also be entered.  The departure time and the station shall be entered.  The train/machine shall be deemed to remain in the block section for the specified duration.  The arrival time and the station shall be recorded.  The actual duration for which the work on line was availed will be reckoned between the departure from the starting station till clearance of the block section at either of the stations. 2.1.5.5.5 Single line working on Double line This option shall enable the user to capture the movements associated with temporary single line working on a double line section either due to maintenance blocks or due to accidents.  The user shall enter the time and date of introduction of single line working.  The user shall select the block section and the line (Up/Dn). In the event of single line working spanning over more than two stations, then from station and to station shall be captured. The name of intermediate stations being temporarily closed shall also be captured.

Page 36 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS  The user shall also select one of the pre-defined causes for imposition of single line working.  The movement of trains during this phase shall be captured by the Arrival/Departure use case. Any wrong line movement shall be distinctly shown in the chart.  The inter station running time for wrong direction trains shall be calculated at a speed of 25 KMPH. A delay of 10 minutes shall be added for dispatch and reception of each wrong direction train between the two stations for the purpose of advance plotting.  The date and time of cancellation of single line working along with the certifying authority shall also be captured. 2.1.5.5.6 Accidents This option shall enable the user to capture the movements associated with accident situation including ordering of relief trains and their despatch details from the base station.  The time of sounding the siren shall be captured along with the names of stations. This shall be deemed as the ordering time for accident relief trains. The user shall use the “Add New Train” option and create train for all the relief trains ordered immediately.  The system shall automatically suspend “advance plotting” of all trains in the section excluding accident relief trains.  User shall enter the details pertaining to Accident relief trains (ART) through this screen such as Time of sounding siren (appears by default), Time Train Engine Bahar line out, Time of attaching Train Engine, Train Ready time, Driver Name, Guard Name, Load summary.  The details of coaches/ wagons by train such as coach/wagon type, coach/wagon number and position from engine shall be entered.  The date/ time of departure and the station with reason for late departure, if any, shall be recorded.  After entering the details, the user shall submit details.  On successful saving,  Confirmation message shall be displayed.  The movement of all other trains except the ART’s shall be regulated at convenient stations until further instructions.  In the event of other trains running in the section to be diverted/terminated short of destination/cancelled, the task shall be carried out through the menu under Train Ordering use-case. In respect of movement of relief trains, Light Engine, Tower wagon and other departmental trains into the affected block-section, the following events shall be captured by the system.

Page 37 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS  The time of departure of the train/vehicle and the station from shall be recorded. The destination shall be the affected block section. In case of a double line section, the line on which the train/vehicle was sent shall also be recorded.  On arrival in the mid-section, the time of arrival shall be recorded (whenever known).  The train/vehicle may be sent from either or both of the stations into the affected block section.  When the train/vehicle departs from the mid-section, the time of departure and the to station shall also be recorded (whenever known).  The time of arrival of the train/vehicle at the station and the station name shall also entered.  The date and time of removal of obstruction, the date and time of track certification, certifying authority shall also be captured.  The affected block section shall be shown as obstructed in the plot graph from the date and time of accident until the date and time of removal of the obstruction.  The movement of trains at restricted speed, if any, after certification shall be captured through the Caution Order use-case. •

Pre-Conditions Section Controller should have successfully logged on to the system. • Detachment of loco option shall be enabled only when at least one loco is attached to the train. • Static database information should be available. Post-Conditions • Changes saved should be shown on the screen after successful save. • Changes in any of details shall affect the graph. • In an accident situation, the system shall be capable of retrieving and displaying essential information on the various resources available (department wise) at stations over the Control Board for decision making by the Controller. The information shall include the following: o List of Level Crossings in the affected block section. o Availability of Medical relief-Railway Hospitals/Dispensary, Portable Medical kit at stations, Location of Medical Relief Van. o Availability of Catering facilities-Refreshment room, Restaurant o Availability of Travelling Crane, Re-railing equipment under Mechanical department. o Telephone number of the Railway Stations. o Civil district of the place, important phone numbers of civil administration.

Page 38 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS Business Rules • In the event of any abnormal working like, Single line working on Double line due to Engineering Blocks and Accident situation, the clearance of all trains that have entered the section from either end shall be ensured before allowing any traffic train into the block section. The ‘Advanced plotting’ use-case shall be functional only after ensuring this pre-condition. • All timings reported under ART details should be between Time of sounding of siren and Departure from the base station. •

Assumptions Data from external systems should be available to this system. • Maintenance of referential data on essential information pertaining to assistance required during accidents and updating of the information.

USE-CASE Specification – Report Unusual Occurances The purpose of this use case is to capture unusual happenings in the section. It also affects the plot graph use-case. It helps in locating the place of unusual occurrence over the section, cause, time/date and its effect on train movement. Primary Actors Section Controller (SC) Dy. Controller (Punctuality) Flow of Events 2.1.6 Basic Flow • System shall provide facility for the User to capture the unusual occurrences over the sections within the board. • System shall facilitate entering start date/time of all unusual occurrences. • If an Unusual occurrence has happened at a station then o System shall provide option for choosing the respective station where it has happened. This will also include provision for capturing the failure at a cabin, level crossing within the control of the station. • If an Unusual occurrence has happened in a block section then o System shall provide option for choosing the block section. o System shall also provide option for entering exact location in terms of Kilometrage or OHE mast number. o If the failure has occurred at level crossing, then the level crossing number and its location shall also be captured.

Page 39 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS • • • •

•

System shall have facility to enter the expected rectification time for the unusual occurrence (This shall be useful for plot graph use-case (For Advance Plotting)) User shall have facility to enter the preliminary cause of failure and expected delay time for UP/DN/all Trains. System shall also provide option for entering any remark for each train affected by the failure. During periods of fog, heavy rainfall and other adverse weather conditions affecting train services, the system shall be capable of capturing the duration of such phenomenon and display the same against a station through suitable icons. After the failure is rectified or the cause of occurrence no longer exists, the system shall provide entering the end date/time of failure and the actual cause of failure (occurrence) as communicated by the maintenance staff or the station master. The duration of failure shall be computed automatically by the system.

Unusual occurrences in Block-Section • If an unusual occurrence will result in detention to train(s) passing through the affected block section during the period of failure, the system shall provide facility for identifying those trains distinctly as under:  Up Trains  Down Trains  All Trains  Select Train. The default option shall be ‘All Trains’. • Based on the above selection, the system shall implicitly assign the same as the reason for detention. This shall be facilitated in both ways-instantaneous reporting and back reporting. • Whenever back reporting is done, the cause shall be assigned only in respect of trains where manual reporting has not been done. If already done, the specific remarks shall prevail. • Where the total detention in a block section or station is to be apportioned to more than one unusual occurrence, the same shall be displayed for guidance and the user shall manually enter the detention pertaining to each occurrence. Unusual occurrences at Stations • In respect of failures at stations (e.g Signal or Point failure), which may or may not affect all trains, the system shall provide facility for identifying those trains distinctly as under:  Up Trains  Down Trains  All Trains Page 40 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS  Select Train. The default option shall be ‘Select Train’. • Based on the above selection, the system shall implicitly assign the same as the reason for detention. Unusual occurrences affecting select trains • The user shall select the Train number based on direction. • The system shall facilitate entering brief details of the incident.

2.1.6.1 Unusuals – Signals System shall have facility to capture different type of Signal Failures. They include o Signal Failure o Point Failure o Track Failure o Block Failure 2.1.6.1.1 Signal Failure • User shall have facility to choose the Type of Signal, Signal Number, Direction and Road Number for which the failure has occurred. • User shall have facility to add new Signal type. An indicative screenshot depicting the UI elements is illustrated below

Page 41 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.6.1.2 Point Failure •

User shall have facility for capturing the Point Number, Position of Point and also the road number (line) for which the failure has occurred.

An indicative screenshot is illustrated below

Page 42 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.6.1.3 Track Failure • User shall have facility to choose the Road number and the specific Track number. An indicative screenshot depicting the UI elements is illustrated below

Page 43 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.6.1.4 Block Failure • This failure shall be block section and direction specific(only in Double line) and not station specific. • User shall have facility for selecting the pre-defined block failure types. • User shall have facility for adding any new type of Block Failure also. • This feature will also cater to circumstances in which Block instrument working is suspended for obvious reason like entry of motor trolley into the block section, etc. A screenshot depicting the UI elements is illustrated below

Page 44 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.6.1.5

Unusual – Telecommunication • System shall have facility for capturing Telecom failures affecting stations, cabins, level crossing gates and control. • The user shall enter the location1 and location2 between the equipment has failed. • System shall have facility for selecting the pre-defined list of types of failures under this head. • System shall also provide facility for adding new type of failure, which is not present in the pre-defined list of causes. An indicative screenshot depicting the UI elements is illustrated below

Page 45 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.6.2 Alarm Chain Pulling (ACP) • System shall have facility for capturing instances of ACP • User shall have facility to choose the UP/DN passenger Train in which the event has taken place. • User shall also have facility to enter or select the Coach Type, Coach Number, position from engine. • User shall also enter brief description of the incident. An indicative screenshot depicting the UI elements is illustrated below

Page 46 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.6.3 Unusual - Commercial • System shall have facility for capturing unusual occurrences attributable to the Commercial department. • User shall have facility to choose the UP/DN Trains. • User shall have facility for selecting the pre-defined types of occurrences under this head. • User shall also have facility for adding new type of occurrences • In case of delay in loading/unloading, the user shall also have facility to enter the number of articles loaded/unloaded by the train leading to the extra time delay. • User shall have facility to enter the preliminary cause for the occurrence and expected time delay for each or all Trains. • User shall also have facility to enter the actual delay for single/multiple trains, which have been affected by the occurrence. System shall provide option for entering additional remark for each train affected by the event. An indicative screenshot is illustrated below Page 47 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.6.4 Unusual -Traffic • System shall have facility for capturing unusual instances attributable to the traffic department. • User shall select the UP/DN Train number. • User shall have facility for selecting the pre-defined instances under this category . • User shall also have facility to add new type of instances. • User shall also have the option to indicate the exact cause for all instances under this category. An indicative screenshot is illustrated below

Page 48 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

Page 49 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.6.5 Unusual - Loco • System shall have facility for capturing all types of delays attributable to the locomotive including failure. • User shall have facility to choose the UP/DN Train. • System shall provide the list of Locos attached to the selected Trains. • User shall have facility for selecting the one or more of pre-defined Loco Failures types and other occurrences. • User has also facility to add new types of failures or instances. An indicative screen is illustrated below

Page 50 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.6.6 Unusual - Engineering • System shall have facility for capturing all delays and failures attributable to the Engineering department. • User shall select one of the options : o Open line (Default option) o Construction • User shall have facility for selecting the pre-defined types of failures and other instances. • User has also facility to add new type of failures or instances. An indicative screen is illustrated below

Page 51 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.6.7 Unusual – C&W • System shall have facility for capturing all delays and failures attributable to the mechanical department. • User shall have facility to choose the UP/DN Train. • If selected train is passenger type, then  User shall have facility to select or enter the Owning Railway, Coach Type and Coach Number. • If selected train is goods, then  User shall have facility to select or enter the Owning Railway, Wagon Type and Wagon Number. • User shall have facility to select one or more of the pre-defined failures type or instances. • User shall have facility to add new types of failures or instances. An indicative screenshot is illustrated below

Page 52 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.6.8 Unusual - Electrical System shall have facility for capturing various type of failures or instances attributable to the following branches of Electrical department o Train lighting and A/C o Traction 2.1.6.8.1 Train Lighting and A/C • User shall have facility to choose the UP/DN Passenger Trains • User shall have facility to select one or more of the pre-defined failure types or instances. • User shall also have facility to add new types of failures or instances. • User shall select the Owning railway, Type of Coach, Coach Number affected by the event (This information shall be pushed from the Maintain Train information use-case) Page 53 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.6.8.2 Traction • •

User shall have facility to select one or more of the pre-defined failure types or instances. User shall also have facility to add new types of failures or instances.

An indicative screenshot is illustrated below

Page 54 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.6.9 Unusual - Accidents • System shall have facility for capturing all information relating to accident situations. • User shall have facility to select one of relevant pre-defined Accident Type and its Sub Type. • User shall have facility to enter Date & Time of Accident, Section, Block Section, Location (KM Pole/OHE Mast), Station/Yard, Line No., Gauge Type, Track Type (Single/Double), Electrified / Non-Electrified, Route. • User shall have facility to enter Particulars of trains involved in the accident. System shall capture following particulars for each train - Train No/Name, Loco No/ Nos., Load, BPC details, Rolling Stock involved ( Owning Railway, Coach Type, Coach No, Position from Loco) , Loco Involved in the Accident (Loco No, Loco Type), Estimated Speed at the time of accident. • User shall have facility to specify the Casualty details (Killed, Grievous and Simple). • User shall have facility to enter the nature of damage (Track, Signal, Rolling Stock and Traction) and its details. • User shall have facility to enter brief description of Accident. • User shall also specify the assistance required at accident site and fill in details. The type of assistance includes the following: ART/ ARMV, Special Trains, Crane, Engineering Material, No. Of Men required, Medical Facility, Transport, Tent, Food, Water, Telecommunication Equipment, etc. • User shall have facility to enter the prima facie cause for the accident. • User shall identify the trains to be regulated/ diverted / terminated / cancelled in coordination with Dy. Chief Controller. These tasks shall be further driven by Train Ordering use-case. • User shall have facility for systematic logging of various events with time stamp (These details shall be used for generating the Section controller’s diary). • System shall have facility to enter the expected restoration time for the accident and expected delay time for all trains.

2.1.6.10

Unusual - Miscellaneous • System shall have facility for capturing all types of miscellaneous instances. • User shall have facility to choose the UP/DN Train.

Page 55 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS • User shall have facility to select one or more of the pre-defined instances. • User shall also have facility to add new instances. An indicative screenshot is illustrated below

2.1.7 Alternative Flow

• •

2.1.7.1 Update/Modify the unusual System shall list out all unusual occurrences over the section for the day or particular type of unusual occurrences. User shall have facility to select particular unusual instances for modification. • If pre-conditions satisfy, then  System shall display all details for the selected occurrence for updating/modification. Page 56 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.7.2 Mark for Wrong Entry • If pre-conditions satisfy ,then o System shall freeze deletion of the selected occurrence but only enable the user to mark it as wrong entry. o System shall ask for the remarks for this operation. Pre-Conditions • If the Primary Actor is Section Controller, then  He can view, add, and modify all type of occurrences only over his jurisdiction • If the Primary Actor is Deputy Controller(Punctuality), then  He can view, add, and modify all type of occurrences for all boards. Post-Conditions • System shall automatically reflect the changes due to unusual occurrences on the graph (Absolute/Advance) – Refer plot-graph use case. • The system shall be capable of providing an instantaneous messaging service of all events affecting a train over all the boards to Dy. Chief Controllers, Chief Controller, AOM, DOM and Sr.DOM. Business Rules • If Primary Actor is Deputy Controller(Punctuality), then  He can perform updating/modification of already completed events also. Assumptions Data from external systems should be available to this system.

USE-CASE Specification – Management of Maintenance Blocks The purpose of this use case is to facilitate management of maintenance blocks including permission, control of trains and extension of blocks. It interacts actively in the plot graph use case. It helps in identifying the location of block, duration, reason and its effect on the running of trains. It would also facilitate a visual indication on real time basis on the progress of the block. Primary Actors Section Controller Page 57 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS Deputy Controller (Punctuality) Flow of Events 2.1.8 Basic Flow – Maintenance Blocks • System shall provide facility to capture the details of proposed block(s) over a section on a specified date. • If the block is given at station, then o System shall provide option for choosing the respective station from the list of stations over the given section. • If the block is to be given in a block-section, then o System shall provide option for choosing the block section. o System shall also provide option for entering the exact location in terms of Kms or OHE Mast number. • System shall provide facility to select one or more of the following types of Blocks: (Engineering / S&T / Traction). • The details of programmed corridor blocks shall be captured and maintained as referential data. They shall include : Section, From station, To station, Line, Duration_Hr, Duration_Mts, Spell_No., From time, To time, Bet_train1, Bet_train2, Days permitted. o If the duration and location of the block is the same as per corridor block, the user shall select the particular row from the list of corridor blocks permitted over that section,which shall cause the details for the block to be displayed by default • If commencement of the block is definite and independent of the train movements, then o System shall provide facility to enter Requested Start Date/Time, Requested End Date/Time, Permitted Start Date/Time and Permitted End Date/Time (The Requested and Permitted Time can be same or different). • If commencement of the block is dependent on the train movements, then o System shall permit the user to enter the Train No after the passage of which the block is supposed to start. o In such case, the Permitted Start Date/Time shall commence only after the train clears the block section. • System shall provide facility to enter Requested End Date/Time, Permitted End Date/Time. • System shall also provide facility to select one or more of the pre-defined Reasons for the Block. • Adding of new reasons for the Block by the user shall also be facilitated.

Page 58 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS 2.1.8.1 At Station • User shall have facility to select the line Number over which the block is proposed. • System shall also display the type of the line (Main/Loop) along with Line No. • When a line is blocked for a specified duration, the line shall be deemed to be out of use for such duration and shall also be shown as unavailable for train movements. The blocked line at that station shall be shown in a distinct colour (Orange). • If the blocking of the line is to result in additional time loss for the train movement , then o The estimated time delay for each train shall also be entered.. This shall be of use in the Advanced plotting use-case. An indicative screen shot is illustrated below:

Page 59 of 122

• o • o •

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.8.2 At block-Section • System shall display the direction (Up/Dn) and/or the number of lines available in the block section. If the block Section is in Single Line section, then System shall only display “Both” option for selection. If the block section is in a Double line section, then System shall show UP/DN/Both options for selection. If block section is having more than two lines, then o System shall show the line numbers available in the block section for selection.

Page 60 of 122

•

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS 2.1.8.3 Control of Trains If the block has been permitted in a Single line section, then o No traffic train can be allowed to enter the affected block section during the period of the block. • If the block has been permitted in a Double line section and only one of the two lines is affected (Up or Down), then o Temporary single line working to be introduced for running trains in the unaffected line during the period of the block. o The additional delay for trains to be entered for each direction. • If the block has been permitted in a Double line section and both the lines are affected (Up and Down), then o No traffic train can be allowed to enter the affected block section during the period of the block. • If the block has been permitted in a Triple line section and two of the lines are affected (a pair of Up and Down), then o The Trains shall be dealt in the unaffected third line under rules for Single line. • If the block has been permitted in a Quadruple line section and two of the lines are affected (a pair of Up and Down), then o The trains shall be run in the other pair of Double line. The above features will have a bearing on the Train Movement use-case. 2.1.8.4 Block Clearance • If Primary conditions satisfy ,then o System shall facilitate selection of the particular block for the day. o System shall also enable the user to enter the actual end time/date on completion of the block. 2.1.8.5 Block Extension • If the extension is permitted before the expected end time/date of the block then o System shall facilitate selection of the particular block for the day. o System shall provide facility to the user to enter the revised end time/date. o System shall also facilitate entering the reason for the extension of the block.

Page 61 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS o System shall provide facility to enter multiple extension (start/End) time for the same block. 2.1.8.6 Block Burst • If a train has been started into the affected block section after the permitted end time/date of the block, then o If the user gets information about the non-completion of block, then  If primary condition is satisfied ,then  System shall provide facility to the user to mark the bursting of the block from the permitted end time/date to actual end time/date.  The delay to the train on account of block bursting shall also be entered after confirmation. 2.1.9 Alternative Flow 2.1.9.1 Find Block • System shall provide facility for showing all the blocks for the day over the section.(Completed and proposed blocks shall be displayed in distinct colours). • If the selected block has already been completed, then o System shall provide facility to modify specific details and also view the actual duration of the block, extension permitted and bursting of the block, if any. 2.1.9.2 Update/Modify the Block Entry • If primary condition is satisfied, then o System shall allow the user to modify specific details of any block for the day only. 2.1.9.3 Mark for Wrong Entry of Block Entry • If primary condition is satisfied, then o System shall not provide facility to delete the block entry but user can only mark it for wrong entry. System shall also facilitate entering of reason for this operation. Pre-Conditions • If Primary Actor is Section Controller then

Page 62 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS o Section Controller can view, add, and modify the block only for the particular shift and particular board. o If Primary Actor is Deputy Controller(Punctuality), then  He can view and add blocks of all sections of the division for (D-1) day. Post-Conditions • System shall create row into the log file for each and every modification of block entry. • System shall automatically and immediately reflect the changes due to block on the graph (Absolute/Advance) – Refer plot-graph use case. Business Rules • During all blocks, any number of Departmental and Engineering trains can be allowed into the affected block section from either end and the system should facilitate movement of such trains with out any restriction. Assumptions Data from external systems should be available to this system.

USE-CASE Specification – Caution Orders The purpose of this use case is to facilitate imposition and cancellation of Cautions over the section and document processes related to this task. The use case would enable identifying the location of cautions, their duration, cause and its effect on train movement in terms of additional time delay for each train Primary Actors Section Controller Deputy Controller (Punctuality) Flow of Events 2.1.10 Basic Flow – Caution Order • System shall provide facility to enter the Caution Orders over the section within the jurisdiction of the board. • System shall have facility to capture the time/date of imposition of each caution order. • System shall also have facility to enter the message number, details of the authority, who imposed the caution by his designation, department and HQ station (These would be facilitated through pre-defined list). • If a new Caution is advised with its location within the station section, then o System shall provide option for choosing the station

Page 63 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

  

o User shall have facility for selecting the Line number over which the speed restriction is to be enforced. o System shall also show the type of the line (Main/Loop). • If a new Caution is advised with its location over a block section, then o System shall provide option for choosing the block section. o System shall also provide option for entering the exact location in terms of Kms or OHE Mast number. o If the block Section is in a Single Line section, then System shall only display “Both” option for selection. o If the block section is in a Double line section, then System shall show UP/DN options for selection. o If block section is having more than two lines, then System shall show the line numbers available in the block section for selection. • System shall have facility to capture the Restricted Speed(s). • System shall have facility to capture the special restrictions also. It will take the input whether the Caution Order shall be applicable to Passenger / Goods / Both. • If time/date of removal of caution order is pre- advised at the time of the imposition, then o The User shall have facility to enter the expected cancellation time/date of the Caution. • System shall have facility to choose one of the pre-defined reasons for imposing the Caution. • System shall also provide facility to the user for adding new reason, if any, which is not in the pre-defined list. . • System shall have facility to enter any additional remark for the cautions to be enforced. 2.1.10.1 •

Temporary Speed Restrictions If a new caution is to be imposed, then o System shall facilitate selection of “Impose caution” option. o System shall have facility to capture the additional information pertaining to location of Indicators for each speed restriction. • Location of Caution Indicator. • Location of Speed Indicator (SI1 / SI2 / SI3 / Stop Indicator). • Location of Termination Indicator for Passenger / Goods separately. [The Location shall be in terms of either Kms (Hectometer post) or OHE Mast]

Page 64 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

•

• System shall also have provision to capture exchange of Private Numbers between the Section Controller and Stations on both side and Notice Stations after the Sr. DOM permits the imposition of the caution. • If an existing caution is to be cancelled, o System shall facilitate selection of “Cancellation” option. o System shall facilitate the selection of the caution from the list of cautions presently in force over the section. o System shall also facilitate entering the actual cancellation time/date, when the speed restriction is removed. o System shall also have provision to capture exchange of Private Numbers between the Section Controller and Stations on both side and Notice Stations after cancellation of the caution. If the location remains the same but only the speed is to be changed, then o System shall facilitate selection of “Change of Speed” option. o System shall facilitate selection of the block section over the section. o System shall display the list of existing cautions over the defined block section. The user shall select the caution for which the location is to be changed. o System shall display all details for the above selection and facilitate modification of time/date of imposition and only the Speed. o System shall treat this as a new caution and implicitly cancel the pre-selected caution reckoning the modified time/date of imposition as the cancellation time/date. o System shall also have provision to capture exchange of Private Numbers between the Section Controller and Stations on both side and Notice Stations after the change of location. • If the location of an existing caution is to be changed (within the same block section) o System shall facilitate selection of “Change of location” option. o System shall facilitate selection of the block section over the section. o System shall display the list of existing cautions over the defined block section. The user shall select the caution for which the location is to be changed. o System shall display all details for the above selection and facilitate modification of time/date of imposition, location (From and To Kms), and Location of the Indicators. o System shall treat this as a new caution and implicitly cancel the pre-selected caution reckoning the modified time/date of imposition as the cancellation time/date.

Page 65 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS





2.1.10.2

o System shall also have provision to capture exchange of Private Numbers between the Section Controller and Stations on both side and Notice Stations after the change of location. If the location of an existing caution and speed is also to be changed (within the same block section), the tasks under Change of Speed and Change of location shall be facilitated. Any change affecting a new block section or station shall be dealt under ‘Impose Caution’ option.

Permanent Speed Restrictions • System shall facilitate the user to enter any new permanent speed restriction. • If a permanent speed restriction was to be carried forward from the previous year, the system shall have facility to enter the Renewal Date. If it is a case of being carried forward for more than 2 years, the user shall update the renewal date. • In case of a permanent speed restriction being cancelled during the year, the system shall facilitate entering date of cancellation against the selected permanent speed restriction over the section.

2.1.11 Alternative Flow Find Caution Order • System shall facilitate the user to select the Permanent or Temporary speed restrictions over the section. • System shall provide facility for showing all the speed restrictions for the day over each section and line (Up/Dn) Update/Modify the Caution Order • If pre-condition is satisfied, then o System shall allow the user to modify the details of any entry pertaining to speed restrictions.. Mark for Wrong Entry • If pre-condition is satisfied, then o System shall not provide facility to delete the Caution Order entry but user can only mark it for wrong entry. System shall also facilitate entering of reason for this operation. Pre-Conditions Page 66 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS •

If Primary Actor is Section Controller then o He can view, add, and modify the Temporary Speed Restrictions only for the particular board. o If Primary Actor is Deputy Controller(Punctuality), then  He can view, add, and modify the Temporary Speed Restrictions of all sections of the division.  He can also add, and modify the Permanent Speed Restrictions of all sections of the division.

Post-Conditions • System shall create one row into the log file for every modification in the details pertaining to speed restrictions. • System shall automatically reflect the changes due to Caution Order on the graph (Absolute/Advance) – Refer plot-graph use case. • The list of all cautions in force for a day shall be printed (section wise and/or line-wise) on the right hand side of the chart for each shift in geographical order of the location. (The details should include Station name or Block-section name, Location, Speed and Reason). Business Rules • Primary Actor can enter new Speed Restrictions only up to a margin of 2 hours from the Permitted Start Date/Time of Speed Restrictions. Assumptions Data from external systems should be available to this system.

USE-CASE Specification – Plot Graph The purpose of this use case is to draw the movement of trains on the screen for all sections under the jurisdiction of the board as a time-distance graph. The display shall show all the running trains with their present location. The display shall also include the physical status of running lines at stations, failure of equipment, speed restrictions between block stations or at stations, and maintenance blocks programmed including those in force. In respect of Express/passenger trains, the display shall also include time lost or gained between stations with facility to ascertain the cause through a tool tip. Primary Actors System Flow of Events

Page 67 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS 2.1.12 Basic Flow – Plot Graph • This use case shall get invoked automatically on 24*7 basis • The system should be capable of refreshing the graph automatically at an interval of every 3 minutes (configurable) or at the request of the user. • When the arrival/departure or run through has been reported for a train at a station, the system shall cause the event to be captured and display the same on the screen-Refer Train Movement use-case • If two or more sections are under the control of a board, the arrangement of the sections in the display screen shall correspond to the geographical order of the sections. There should also be a physical separation between the sections.

o o o o o

• The display should also facilitate zoom in and zoom out facility to get a better understanding of the events over the selected area. • The system shall also enable the user of a particular board to have a view of the current chart of other boards in the division. In case of interfacing with the adjacent division, this facility shall be available for the user only for the contiguous board. • The details to be shown only on the display screen shall include: Section name Direction (Up and Down)  Station name in the geographical order with Km from the reference point. Block Stations (In Bold) Non-Block stations. (In italics) Inter station distance (To scale) Line occupation icon for each line against each station. Entry/Exit of a train from and to adjacent board. Train Id information  In case of Passenger Trains Train Number Locomotive(s) Number Driver Name Guard Name Load Summary

o o o o

In case of Goods Trains Train Name Locomotive(s) Number Driver Name Guard Name Page 68 of 122

o o

o o o o

o

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS Load Summary Sign on time. In case of Light Engine To station Locomotive(s) Number Driver Name Guard Name (If available) o

Sign on time

In case of Track Machine/Tower wagon/Trolley o Machine Name / Trolley or Tower wagon Number Driver Name (Only items in bold shall be displayed on the display screen. Other details shall be printed only in chart)  Failures at a station or Block section through suitable icons.  Maintenance blocks-programmed and in force  Engineering – Red  Traction - Green  Signal - Blue If in a double line section and only one line is affected, the slope of the shading within the rectangle should correspond to the direction of the movement on that line. If both the lines are affected, then the shading should be interwoven corresponding to both the directions.

 

 Suitable icon to indicate speed restrictions in force (at station or between stations).  Occupation of running line at a block station. o If one or more lines are occupied, a hexagonal icon with the no. of lines occupied in the center. o If all lines are occupied, a blinking hexagonal icon with red in the center. Work on line – Material Trains/Track Machines. Communication failure with stations.

The details to be shown on the print version of chart shall include the following in addition to the above:  Actual cause of detentions including failures.

Page 69 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS Interchange of goods trains and light engine from and to adjacent division (only in respect of boards controlling divisional interchange point) o Train Name, Engine(s) Number, Time, Load Summary (Separately for Handing over and Taking over) Details of speed restrictions (in geographical order) o To be shown section wise. o In case of Double line, to be shown for Up and Down line separately. o The details shall include:  Station / Block section Name  Location (Kms)  Speed  Reason  Time/date of imposition  Time/date of cancellation  Line position at important yards at specified intervals. Name of the controller on duty. Shift time & date. 



2.1.13 Alternative Flow When the path of a train is selected, through right click option, the system shall facilitate the user to get the actual arrival and departure of the train including detention at all stations over the section in a tabular form. Pre-Conditions  The user should have successfully logged in to the system.  Referential data base is maintained in respect of the basic information. Post-Conditions  The system shall cause the current chart to be saved as an image file after two hours from the close of the shift time for each board. This activity shall be triggered at 0200, 0800, 1400, and 2000 Hours each day.  The system shall facilitate the printing of the chart for specified duration at the instance of the Dy.CHC (Punctuality) or the CHC.  Till the time of saving the chart as an image file, any request for view of the chart (of any board) shall be facilitated through dynamic generation each time.  Once the chart has been saved as an image file, subsequent request for view option shall be browser based.

Page 70 of 122

   

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS Business Rules • X-axis depicts time in hours and minutes in interval of 10 minutes with further sub-division in units of 2 minutes. • Y-axis depicts the stations over the section in geographical order (To scale) • The graph should show all the movements over that section for a predetermined time duration (e.g. 6 Hrs.). • The display should also facilitate horizontal and vertical scrolling. • The plot color for different type of trains should be as under and configurable: Rajdhani/Shatabdhi/Jan Shatabdhi - Purple Mail/Express trains - Red Passenger trains - Blue Goods Trains/Deptl trains/Material trains/Tower wagons /Track Machines - Green Light Engine on Traffic account - Black • The default size of the print chart shall be 36 inches. It shall also be possible to take customized print in A0-A3 size, if required. Assumptions Data from external systems should be available to this system, where required.

USE-CASE Specification – Advance Plotting The purpose of this use case is to project the estimated arrival,departure, run through of a train(s) over the defined section(s), indicate ideal precedence/crossing points based on the actual running of the train(s) under dynamic situation with the core objective of ensuring punctuality. The projections should be based on consideration of all specified parameters and business logic explained herein duly ensuring right time arrival of all scheduled passenger/express trains at the section/divisional interchange point or destination if within the division. At any or all points of conflict, the detention should be to the bare minimum and still provide for maintaining the punctuality of the services. In respect of Goods trains, the system should facilitate minimum possible hours of run over the section.The system should thus cause the projections to be reflected in the display screen within reasonable response time. Primary Actors System Secondary Actors Section Controller

Page 71 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS Flow of Events 2.1.14 Basic Flow – Advance Plot • This use case shall be invoked automatically on a user logging in to the system. • The projections shall be for a minimum period of 2 hours (configurable) from the current system time. • The projections should be based on the schedule of services for the specified day and also include additional trains added up to that point including trains from contiguous board and from adjacent division captured through CAS. • The projections should be based on scheduled departure,halt at stations and the last reported event for trains (where applicable). • The projections shall get refreshed in two ways:  Automatic refresh after every 3 Minutes.  Instantly at the request of the user. • The projections to be shown distinctly as dotted lines in the same colour assigned to different types of train. • The system shall also display the probable status of all passenger/express train as [BT/RT/LT (Actual quantum of delay in minutes)] instantly as a tool tip on pointing to the path of the train at every station and also at the end of the section or on reaching the destination (if within the same section), based on the direction of the train. • In the case of goods train, the probable total hours of duty of the crew from the signing on time, shall be shown as a tool tip when pointed on the path of the train. • The system shall also enable filtering the view of advance plotting based on either the direction of trains or on the type of the train (Pass/goods) or only for selected trains. 2.1.15 Alternative Flow The system shall facilitate the user through a GUI to select the path of a particular train and alter its path manually (drag and drop). • The events that can be changed as above shall include:  Increasing the inter station running time.  Change of crossing station.  Change of precedence station.  Change the reception order of a train during crossing.  Increase or decrease the scheduled halt at station (only for passenger trains). Every such act shall cause the projections to change dynamically based on the revised co-ordinates assigned to the train.

Page 72 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS • The system shall also facilitate the user (menu driven) to force welldefined detentions to a chosen train at a particular station or a block section based on expected outcome of a preceding event. This shall cause the projections to dynamically change based on the defined input. Pre-Conditions The user should have successfully logged in to the system. • The basic referential data is maintained for validation under different situations. • In non-data logger environment and during failure of data-loggers, the absolute responsibility to ensure the occupation of running lines shall rest with the station staff. Post-Conditions The projections regarding the arrival of a train with the train name shall automatically be shown on the contiguous board (same or adjacent division) at predefined interval of time. The CAS, in case of interfacing between adjacent divisions, shall enforce this. Business Rules The Advance plotting logic initially shall be based on averaging actual data for 5 to 7 days picked up from the relevant physical charts. A matrix comprising of the different types of trains and their intersectional timings for various speeds would be developed based on this data. This matrix would be used as a base to forecast the position of the train. In the enhancement phase, this matrix would be continually refined by way of replacing the older data with more current data through a configurable untility. The process of advance plotting of trains shall depend on the following parameters: 2.1.15.1 System of Working • The System shall capture the type of block working between two stations over the section. • If the system followed is Absolute Block System, then  There can be only one train at any time over a block section under normal working conditions.  In exceptional circumstances like abnormal working due to Engine failure, Maintenance Blocks and Accidents, there can be more than one departmental train in the same block section. This relaxation is not applicable for a traffic train ( train carrying passengers or commercial goods).  The block stations are primarily of two types-‘B’ Class and ‘C’ Class. ‘B’ class stations are commonly available in Single line and Double line and have one or more loop lines for trains to cross or precede. Page 73 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

•

‘C’ class stations are ideally located only in Double line sections and without any loop line. Therefore trains cannot precede at these stations. They are located between two ‘B’ class stations. The system should reckon the portion of the line between B-C-B as two block sections. If the system followed is Automatic Block System then  There can be normally more than one train in the block section running in the same direction. The number of trains shall usually depend on the number of signaling sections available between the two stations. In reality, the number of trains at any point of time can also be more than the number of signaling sections.  The movement of trains is controlled automatically through the track circuit/axle counters, which are interlocked to the signals affecting the run of the train.  In case of a Single line section, more than one train can follow in the same direction from X to Y, but no train can leave from Y in the opposite direction till the arrival of all trains from X at Y, based on the established direction of traffic.

2.1.15.2 • •

Characteristic of the section-Single Line/Double Line The system shall identify the section as single line or double line. If double line, then  Only precedence shall be projected between trains running in the same direction based on speed differential. If Single line, then  Both precedence and crossing and shall be projected based on the running pattern of following train in the same direction and trains running in the opposite direction. 2.1.15.3 Pattern of services on the day of run The number of express/passenger trains to be run on a particular day of the week is dependent on the schedule of services. This would mean that a train might run over the division only on Wed or Fri or on both days. A few of the passenger trains are also not run on Sundays. • The system shall identify the trains to be run normally on that day of the week based on referential data. • The projections for crossing or precedence shall be governed by this critical factor. • In the event of a daily train to wait for a non-daily train for scheduled crossing at a station, the daily train shall not be allowed to wait on days in which the other train does not run.

Page 74 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS 2.1.15.4 Priority of trains • The system shall follow the pre-defined order of precedence of trains, which may be temporarily re-defined in exceptional necessity, through manual intervention by section controller. The default priority of train shall be: 1Accident Relief Trains or Light Engine proceeding to accident spot 2Mail/Express Trains [Rajdhani / Shatabdi] 3Mail/Express Trains [Other than above] 4Troop trains (Military Specials) 5Passenger Trains 6Mixed Trains 7Inspection Specials 8Goods Trains [Crack Trains / Other goods trains / Shunting trains] 9Light Engine not going to accident spot. 10Material Trains [Includes Track Maintenance Machines] Based on the above order, the system shall assign a priority tag to each train in the following format “X.Y” where X shall indicate the priority order and Y shall indicate the sequence number of the train based on direction and the chronological order of its entry . The sequence number of Up trains shall be in the order 2,4,6,8 etc and for the Down trains as 1,3,5,7 etc. The sequence number shall be assigned separately for each section and get shuffled with exit of other trains from the section. • In case of default priority being re-defined through manual intervention, over the same group, the system shall re-assign the priority in relation to the preceding train. • If the priority is to be changed temporarily to higher group, it shall be assigned corresponding to that group. • The re-assigning of priority shall be valid only for the particular day of run and do not change the pre-defined priority. 2.1.15.5 Commuter-sensitivity • Some of the Passenger trains have been defined as commuter sensitive over the entire run or over a specific section. • These details are to be captured train wise and section wise and flagged suitably. • Such trains shall have over riding priority over trains immediately above in the order. (e.g Passenger Train[5] over Express Train [3] ). • In the event of a conflict between two trains in the same group, the train assigned as commuter sensitive shall have priority over the other train, independent of all other parameters.

Page 75 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS 2.1.15.6 Availability of Running lines at stations. • System shall maintain the details of number of lines, main or loop with platform availability at all stations over the section. • When the occupation details (optional) have been advised by the station staff, the current status of the line shall be shown as occupied. • When the occupation or non-availability has not been expressly advised, the system shall deem the status of the line to be vacant. • System shall ensure that at least one vacant line is available at a station to permit movement of a train through that station. o If the train is a stopping passenger train, the system shall also ensure that the vacant line is also a platform line (main or loop). • System shall validate the no. of vacant lines at the station versus the number of trains to be handled on account of crossing/precedence of trains at the time of conflict. The number of trains to be handled at a station shall always be equal to or less than the number of vacant lines at that point of time. • If the number of vacant lines is less than two for a crossing/precedence to take place, then  System shall not allow a crossing/precedence of trains at that station.  If at least two lines are vacant at one of the adjacent stations on either side nearest to the point of original conflict, then o The crossing/precedence shall be fixed at this station. • During crossing of two trains in a single line section, the system shall always assign a vacant loop line for the first arriving train and the main line for the run through train (second arriving train).However,  If the first arriving train is a stopping passenger train at that station, it shall always be assigned a platform line (loop or main) and the second train dealt with on the other vacant line.  If the first arriving train is a non stopping train (passenger or goods) and the second arriving train is a stopping passenger train at that station, then the first arriving train shall be assigned the main line (if not the only platform line at that station) and the platform line (loop or main) shall always be assigned to the second arriving train. 2.1.15.7 Inter Station Running Time: The inter-station running time (between two adjacent block stations) has to be computed based on the following factors: (1) Bare running time Passenger Trains • The inter station running time based on booked speed is defined in the working time table (train wise). Page 76 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS •

•

If the inter station running time is inclusive of any engineering or traffic allowance, then  The bare running time shall be computed duly deducting any such allowance. If the inter station running time is inclusive of any additional time for deceleration, operational stoppage (identified by a flag) and acceleration, on account of a scheduled crossing, then  The bare running time shall be computed by deducting 2 mts for deceleration, 2 mts for acceleration in addition to the authorized duration of stoppage.

(2)

• •

•

Goods Trains The inter station running time for goods trains is based on a uniform maximum permissible speed of 75 KMPH in BG and mentioned block section wise and direction wise separately. As loaded and empty goods trains do not run at 75 KMPH under actual field conditions, the actual inter station running time shall be reckoned from the referential data for each block section (direction wise) based on the sub type of the goods train (in terms of type of wagons and load/empty condition). In respect of specified sub type of goods train where historical data is not available for a particular section, the inter station running time (provided in WTT) shall be reckoned as detailed below :  In the case of empty goods trains, the value shall be decremented by 15 %.  In the case of loaded goods trains up to a gross load of 2500 Tonnes , the value shall be incremented by 15 %.  In the case of loaded goods trains above a gross load of 2500 Tonnes , the value shall be incremented by 20 %.  In the case of Light Engines, the inter station running time shall be theoretically calculated by the system based on the Maximum Permissible Speed for the particular type of locomotive over that section. (Time=Distance/Speed)

Page 77 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS 2.1.15.8 Block operating time The block operating time is the additional time to be provided to facilitate the process of obtaining line clear. This would be necessitated in the following circumstances:  When trains run in the same direction in single line and double line sections, then o If T1 train has entered X-Y block section and T2 train has already arrived at X, the train T2 shall only leave after the arrival of T1 at Y plus an interval of:  5 minutes in Token Working sections.  2 minutes in Token less section. 

When trains run in the opposite direction (in single line) and wait for crossing at a station, then o If T1 train has entered X-Y block section and T2 train has arrived at Y and waits for the arrival of T1 at Y, then T2 train shall only leave after the arrival of T1 plus an interval of:  5 minutes in Token Working sections.  2 minutes in Token less section.

2.1.15.9 Temporary Speed Restrictions The loss of time on account of negotiating a stretch of temporary speed restriction shall be defined as under: • A referential table shall be maintained (configurable based on experience) to determine the time loss for various types of work depending on the length of the work spot, restricted speed and the type of the train. • The trains shall be grouped as defined below:  Express/Passenger Trains (up to 10 coaches)  Express/Passenger Trains (11 –18 coaches)  Express/Passenger Trains (19 –24 coaches)  Loaded BOXN rakes.  Loaded Jumbo rakes  Empty Blocks.  Other goods trains  Light Engine/Tower wagon. • The values shall be populated in units of 200 Metres (upto a maximum length of 1000 Metres) for different speeds and different category of works. • Based on the actual length, the system shall pick up the values from the referential data and compute the cumulative time loss for

Page 78 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS that type of the train (e.g 1200 Metres means, value for 1000 plus value for 200). • For works, which are not categorized, the user shall specify the detention for each train(s). • These offset values should be added to the bare running time. 2.1.15.10 Passing through on a Loop If a non stopping train (passenger/goods) is assigned to pass through on a loop line at a station during crossing or precedence, then • A referential table shall be maintained (configurable based on experience) to determine the time loss for various types of train. • The trains shall be grouped as defined below:  Express/Passenger Trains (up to 10 coaches)  Express/Passenger Trains (11 –18 coaches)  Express/Passenger Trains (19 –24 coaches)  Loaded BOXN rakes.  Loaded Jumbo rakes  Empty Blocks.  Other goods trains.  Light Engine/Tower wagon.  The system shall select the time loss based on the type of the train from the referential table.  The values forming part of the referential data shall not be station specific in the initial phase.  This value shall be added to the bare running time. 2.1.15.11 Unusual occurrences including Failures In the event of any unusual occurrences including failures at a station or blocksection affecting the train, then • In case of Block Failure between X-Y, a default time loss of 5 minutes shall be reckoned for each train only at X. (During Block Failure, no train can run through a station even if not booked to stop). • In case of failure of reception signals and the Calling On-signal facility is available at this station, the extra time during failure shall be reckoned as 3 minutes in the block section for each train. • In respect of other failures, the user shall assign the anticipated detention for each train(s). The inter station running time shall be calculated based on all factors covered under 2.9.2.7 to 2.9.2.11.

Page 79 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS This factor shall enable the system to identify the first arriving train at a point during conflict. 2.1.15.12 Shifted Timings (PTT) In the event of a passenger/express train arriving before time at specified stations, shifted timings have been prescribed adhering to which trains can start ahead of the departure time notified in the working time table from that station. • In such situation, the system shall reckon the scheduled halt at that station from the time of arrival only up to the shifted departure time. • If not specified, the train can depart only at the departure time as per WTT even if it arrives before time.

•

•

2.1.15.13 Engineering /Traction Blocks If any maintenance block has been permitted in a block-section, then In single line sections,  The system shall cause all traffic trains to get regulated at stations on either side based on availability of vacant lines till the completion of block.  The advanced plotting shall project further movement of trains only on expiry of the block period (estimated end time). In double line sections,  If only Up or Down line is affected, then only trains scheduled to run on the relevant line shall be regulated. The advance plotting should continue to be displayed for the trains running in the in unaffected line.  If the user enforces temporary single line working, system should enforce the rigidity of single line working on the unaffected line during such period.  The inter station running time for wrong direction trains shall be calculated at a speed of 25 KMPH. A delay of 10 minutes shall be added for dispatch and reception of each wrong direction train between the two stations for the purpose of advance plotting 2.1.15.14 Running characteristics of the train • This feature shall be applicable only for goods trains. • The system shall have the capability to calculate the actual running time for the train over a continuous stretch of 3 block sections (without any temporary speed restrictions or unusual occurrences or halts for the train) from the third station reckoned from the starting station. This value shall be compared with

Page 80 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS the bare running time for the same stretch based on the referential data to arrive at the percentage of increase or decrease in the actual running time.  If there is an increase of 10 - 20% in the actual running time, the system shall cause the further advance plotting to be based at a incremented rate of 10 % over the values prescribed in the referential data for the specified sub type of the train.  If there is a decrease of 10 - 20% in the actual running time, the system shall cause the further advance plotting to be based at a decremented rate of 10 % below the values prescribed in the referential data for the specified sub type of the train.  Any increase or decrease over 20 % shall be reckoned as an aberration and discarded. • The system shall also have the capability to calculate the average speed of the train over a continuous stretch of 3 block sections from the third station reckoned from the starting station. If the system finds that the average speed is exceeding 75 KMPH, then o System shall prompt the user through an alert about possible over speeding by the driver of the train.. The user shall acknowledge. o In case of such situations, the path of the train over such contiguous section shall be distinctly marked. 2.1.15.15 Handling of Conflicts The system shall evaluate the effect of all the above parameters in arriving at the point of conflict. While resolving the conflict to determine the crossing/precedence point for trains, • The cumulative effect of all precedence/crossing for the train shall be assessed till the scope of duration for which advance plotting is done or the exit of the train from the section, which ever is earlier.  If the system finds that a train would reach late at the destination or interchange point by virtue of a crossing/precedence, the system should re-assign the crossing/precedence to the other station at the end of the block section and make fresh projections.  Such change of projection should also be facilitated at the intervention of the user manually. • The projections should take care of ensuring further punctual running of trains running right time upto that point of time. • In the event of one or more trains running late, the projection should facilitate minimum detention to such trains in addition to ensuring the punctuality of right time trains. • If two trains of same priority (belong to same group) lead to a conflict in the same block section, then Page 81 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS  The train running late at that point of time shall have priority over the other train and  The train which is nearer to its destination or interchange point shall have priority over the other train. Intersection of trains • System should able to detect the intersection point over the graph by its coordinates. • If not commuter trains, In case of the same priority group  If the intersection point is closer to A, the crossing/precedence shall be fixed at A.  If the intersection point is closer to B, the crossing/precedence shall be fixed at B. In case of different groups  If the conflict involves T1(High) and T2(Low) trains, the intersection point shall be fixed, by default, at the station at the end of the block section where T2(Low) shall be the first arriving train. • In respect of Rajdhani trains, the system shall enforce that at least next two block sections are kept clear under normal circumstances while handling conflicts. Assumptions Data from external systems should be available to this system.

USE-CASE Specification – Create/Maintain Referential Data The purpose of this use case is to allow user to create and maintain referential data. The tables containing the referential data shall be used as base data for train running and other reporting events Primary Actors Administrator Flow Of Events 2.1.16 Basic Flow – Maintain Referential Data The use-case starts when user clicks the Referential Data option from the main menu. • System shall display a list of all referential tables with the option of selecting any table from the list to add or update records.

Page 82 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS • • • • • • • •

User shall select either From Database or From Other Source options. If the User selects From Database, the existing data from the selected table shall be displayed. User can then modify the existing records with audit details or add new records to the table. If the user selects From Other Source, system shall enable provision to browse and select the file (only excel and access formats). System shall validate the file format according to the selected table from the referential list. If format is invalid o System shall display appropriate message and use case ends If format is valid o The contents of the file shall be displayed. o System shall enable Save button. User shall save the data by clicking the Save button.

Pre-Conditions • Data in Flat files or other sources should be in valid formats

USE-CASE Specification – MIS Reports The purpose of this use case is to facilitate the Management with the reports related to punctuality, loco, and operations of trains. Primary Actors Deputy Controller (Punctuality) Secondary Actors Flow of Events 2.1.17 Basic Flow – MIS Reports System shall provide reports related to punctuality, loco and operation of trains to the Management users. 2.1.17.1

Reports related to punctuality of trains: 1.

Trains Lost • This report shall show the details of the trains lost over a division on a particular date. The details shall be shown category wise(MR Trains,Daily Mail/Exp trains, Non-daily Mail/Exp trains, Special Trains and

Page 83 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

• •

2. • •

Passenger trains) and direction wise and train wise, which shall include the time lost, station at which the time is lost, reason for time loss and remarks. System shall provide option for choosing the date for getting the Divisional Trains Lost report. System shall show the data for time loss at different stations and reason/remarks against a train. The report shall have following attributes: o Sl.No o Train Number o Orign/Taking over station code o Dep Status (RT/LT-If LT in Mts) o Enroute Junction code o Arrl/Dep Status (RT/LT-If LT in Mts) o Destn/Handing over station code o Arrl Status (RT/LT-If LT in Mts) o Primary Responsibility-Department o Place of Detention (Sttn or Block-section) o Time Loss o Reason o Remarks o Recovery Details [Summary for the entire run over the Division]  Engg Gain  Engg Loss  Traffic Gain  Traffic Loss  Loco Gain  Loco Loss

Punctuality Performance(Summary) • This report shall show the punctuality performance of all trains as a percentage in summary form. System shall provide option for choosing the date for getting the Divisional Punctuality Report. System shall have capability to show report for the following categories of trains.  M.R. Trains  Mail Express Trains  Passenger Trains • The report should include the following headings  Daily percentage (% of RT Trains over Total No of trains run)  Average Percentage for the month Page 84 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS Average Percentage for the year (1st April to 31st March)  Late Trains for the day • Under each category of trains, the punctuality performance to be reckoned separately under following categories:  On dot Trains – RT Dep and BT/RT Arrl  NLT Trains-Taken over Late and Arrl Late(No additional loss) o Example –TO 45 Mts and Arrl 45 Mts 

3.

Punctuality performance of all trains • This report shall show the punctuality performance of all trains run over a division on a particular date. The details shall be shown category wise(MR Trains,Daily Mail/Exp trains, Non-daily Mail/Exp trains, Special Trains and Passenger trains) and direction wise and train wise. • System shall provide option for choosing the date for getting the Divisional Punctuality performance report. • The report shall have following attributes: o Sl.No o Train Number o Orign/Taking over station code o Dep Status (RT/LT-If LT in Mts) o Enroute Junction code * - Only for Express Trains o Arrl/Dep Status (RT/LT-If LT in Mts)* - Only for Express Trains o Destn/Handing over station code o Arrl Status (RT/LT-If LT in Mts) o Place of Detention (Sttn or Block-section code) o Time Loss o Reason The details in respect of the last three columns should be be shown in a delimited form in a single row for each train.

4.

Punctuality performance of specified train • This report shall show the punctuality performance of a specific train run over a division for a configurable period System shall provide option for choosing the Train Number, From date and To date for getting the Punctuality performance Report. The report shall have following attributes: o Sl.No o Date of run o Orign/Taking over station code o Dep Status (RT/LT-If LT in Mts) o Enroute Junction code * - Only for Express Trains o Arrl/Dep Status (RT/LT-If LT in Mts)* - Only for Express Trains

• •

Page 85 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS o Destn/Handing over station code o Arrl Status (RT/LT-If LT in Mts) o Place of Detention (Sttn or Block-section code) o Time Loss o Reason The details in respect of the last three columns should be be shown in a delimited form in a single row for each date of run. 2.1.17.2 Reports related to locomotives: 1. • • • •

2.1.17.3

Locomotives due for Schedule • This report shall show the details of locomotives due for schedule as at 0000 Hours. If there is more than one gauge in a Division, the report shall be gauge wise The report shall be grouped traction wise-Diesel and Electric. The No.of locomotives on line at 0000 Hrs shall be shown under each group. The report shall have the following columns : o Loco Number o Base shed o Train worked o Location at 0000 Hours o Schedule Due Code o Schedule due Date

Reports related to freight operations. 1. • • •

Interchange of Trains (‘Y’ day) This report shall give the details of goods trains including Light engine taken over and handed over from/to adjacent divisions during 24 hours for (D-1) day i.e yesterday. The details shall be furnished division wise. The sub-division shall include :  Taken over  Handed over • Under each sub-division, the details shall include :

Sl.No Train Name Loco Numbers(s) Double headed or Multiple Unit (If more than 2 locomotives) Time

Page 86 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS No.of units (Load) •

Summary for each sub-division showing :    

2. • • •

No.of trains No.of Engines-Electric No.of Engines-Diesel Total No.of units

Interchange Forecast This report shall give the details of goods trains including Light engine planned to be taken over and handed over from/to adjacent divisions during 24 hours for the current day (Sys date). The details shall be furnished division wise. The sub-division shall include :  To be taken over  To be Handed over • Under each sub-division, the details shall include :

Sl.No Train Name Loco Numbers(s) Double headed or Multiple Unit (If more than 2 locomotives) Expected Time No.of units (Load) • Summary for each sub-division showing :  No.of trains  No.of Engines-Electric  No.of Engines-Diesel  Total No.of units 3. • • •

Hours of Run (Section wise) This report shall show the details of the goods trains run in a division, section wise and direction wise on a particular date. System shall provide option for choosing the date for generating the Divisional Hours of Run report. System shall have capability to show report with the following attributes. o Section o Length in Kms o No.of Trains run o Total Hours of run o Average Hours of run per Train o Average speed per train

Page 87 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS 4. • • •

5.

  

Hours of Run (Train wise) This report shall show the details of the goods trains run in a division, section wise and direction wise on a particular date. System shall provide option for choosing the date for generating the Divisional Hours of Run report. System shall have capability to show the following headings : o Train Name o Train sub type o Loco Number o Gross Load o Stock Type o Arrival and Departure Timings at various stations o Time taken sectionwise o Average speed section wise o Total Time taken for the entire run o Average speed POL Rakes Position • This report shall show the details of POL rakes in a division at 0000 hours for a given date. • System shall provide option for choosing the date for generating the report. • The report shall be grouped under :  Loaded Rakes  Empty Rakes Under each group, the details shall include :

• Train Name Station (Based on departure) No.of units

Page 88 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

2.1.17.4

Reports related to operations of trains:

1.

•

  

Unusual Occurrence Report • This report shall reflect the details of of all unusual occurrences occurring within the division during a day (from 0000 hrs to 2400 hrs). • System shall provide option for choosing the from and to date for getting the Divisional Unusual Occurrence report (By default it shall be only for D-1 date) • System shall have capability to report the occurrences under two major parts:  Part-A : Events affecting punctuality of trains.  Part-B : Events not affecting punctuality of trains. The report shall be grouped department wise. • The first part of the report under each department shall include the summary details : Total no.of failures for the day (Section wise) Cumulative no.of failures for the current month(section wise) Cumulative no.of failures for the current year(section wise) Under each department, the details to be shown shall include : o Failure sub-type [e.g Signal/Point/Block/Track Failure] o Place of failure [ Station or Block section] o Time & date of failure o Time & date of rectification o Id of Equipment or Gear at fault. [Signal No./ Loco No. etc] o Base Shed [Only in case of Loco failure] o Next Schedule due & date due [Only in case of Loco failure] o Brief description Page 89 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS o o o 2. •

• • • • •

•

3.

Train Number(s) affected Delay in minutes Remarks

Temporary Speed Restrictions (Day Wise) • This report shall show the details of temporary speed instructions in force over a division on a given date. The user may also specify a period (by giving the from and to date) for which the report is to be generated. In this case only the cautions in force during the specified period shall be listed [(i.e) imposed and cancelled/not cancelled as on to_date] The user may also have option to select a particular gauge or section. The default parameter will however be all gauge and all sections. The report shall be grouped – gauge wise, section wise In respect of Double line and multiple line sections, the report shall be shown separately line wise and direction wise The report shall also be sub grouped on department-open line / construction / others. The number of temporary speed restrictions permitted for each department, section wise ith permitted time loss shall be maintained as a referential table. This shall be shown against each section as under : o Number of works permitted o Total duration (in minutes) The report shall include the following columns: o Sl.No o From station o To station o Location from (Kms or OHE post) o Location To (Kms or OHE post) o Length in Kms o Speed o Reason o Date of initial imposition o Date from which changed o No.of days in force (reckoned as on to_date) o Date of probable removal [ Any caution with more than one stretch of speed restriction for the same work will be deemed as a single caution. If two or more works are in force in the same block section, they shall be deemed as separate cautions] Utilisation of Maintenance Blocks

Page 90 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS • • •

4. • •

This report shall give the details of maintenance blocks requested and blocks granted during a day (24 Hours) for a given date. The user shall also be facilitated to specify from and to date for the report to be generated for any period. The details shall include :  Sl.No  Section  Between Stations  Line – Up/Dn (where applicable)  Location (Kms or OHE mast)  Requested-From time  Requested-To time  Requested duration  Permitted-From Time  Permitted-To Time  Permitted Duration  Availed-From Time  Availed-To Time  Availed Duration  Purpose or Nature of work  Whether corridor block or not.  % of Permitted Duration to Requested Duration.  % of Availed Duration to Requested Duration.  Remarks Programmed Maintenance Blocks • This report shall reflect the details of blocks requested during the period of next 72 hours (D + 2day) System shall provide option for choosing the from and to date also, if when required. The details shall include:  Date  Section  Line No  Between stations  Location (Kms or OHE Mast)  Requested-From time  Requested-To time  Requested Duration  Reason

Page 91 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS 5.

• •

6. • •

• •

7. • •

Running Lines out of use at Stations / Yards • This report shall reflect the details of running lines not available for traffic use at a station/yard either due to maintenance work or other reasons. System shall provide option to the user for specifying the from date and to date in case of any specific requirement. The details shall include :  Station code  Line Number  Main or Loop  With or without Platform  Date from which not available  Reason Stabled Trains Report • This report shall furnish the details of stabled loads over the division as at 0000 Hours for each day. System shall provide option to the user for specifying the from date and to date in case of any specific requirement The report shall be grouped under : • Coaching stock • Freight Stock In respect of Freight stock , a train shall be deemed to have been stabled only after lapse of 24 Hours from the time of arrival at the station. This factor should be taken care of while identifying such trains. The details shall include : o Station o Train Number o Load Summary o Time & Date of Arrival o Reason Delayed Wagons Report This report shall include the details of delayed loaded and empty wagons at intermediate stations in a division as at 0000 Hours. The report shall include the following columns : o Sl.No o Section o Station code o Wagon Details – Owning Railway, Wagon type, Wagon Number o Load/Empty Page 92 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS o o o o o o o

From station To station Detachment-Train Number Detachment-Time/Date Detachment Reason No.of days since detachment (Sys date – detach date) Remarks

Any other user requirement in the form of MIS Reports shall be taken up in the later phase of development based on mutual discussion. Assumptions Data from external systems should be available to this system.

USE-CASE Specification – Yard Management This use case shall facilitate capturing of line position at configurable intervals at nominated yards/stations or at specified hours of the day. Primary Actors Section Controller Train Clerk. Flow Of Events 2.1.18 Basic Flow – Manage Yard. The menu defined by this use-case shall be named as :  Line position This option shall enable the user to record the stock presently located on the various lines at a yard/station at configured time intervals (say every 4 hours). The line number, length of the line (in metres) and capacity (in terms of 4-wheelers) at each station/yard shall be maintained as part of the referential data. Main Flow Line Position. The system shall invoke the screen for capturing the line position automatically at pre-defined hours of the day (configurable locally). Once invoked,  The user shall select the nominated yard/station.  The line numbers at the chosen yard/station shall be displayed rowwise.

Page 93 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS  The status field against each line shall include the following optionsVacant/Occupied/Nominated/Out of use. The default option shall be ‘Vacant’. If chosen, the system should display the no.of 4-wheeler units as ‘0’ and the description of the stock/train as ‘Null’.  If ‘Occupied’ option is chosen, the system shall enable the user to enter the no.of 4-wheeler units and brief description of the stock against the particular line.  Once entered, the no.of 4-wheeler units and the description of the stock shall be displayed by default. If the above details, at the time of subsequent reporting too, remain the same, the user shall confirm the details. If the no.of 4-wheeler units or the description of the stock is different, the system shall enable the user to modify the details.  If ‘Nominated’ option is chosen, the no.of 4-wheeler units shall be left blank and the user can enter the train name for which the line is reserved under description of the stock. In this case, the Expected arrival of the train shall also be captured additionally. The system time shall be shown as default option and the user shall modify the ETA based on forecast.  If the “out of use’ option is chosen, the system shall disable the no.of 4-wheeler units and description of the stock details. Pre-Conditions • The user should have successfully logged on to the system. • Static referential database information should be available. Post-Conditions  The line occupation at different hours of the day shall be printed on the right hand side of the plot graph for each shift. Business Rules Assumptions Data from external systems should be available to this system.

USE-CASE Specification – Security & Administration The purpose of this use case is to allow user to create/modify logins, change password, create/modify user groups, activate/deactivate user. The association of a user group to a user determines the access rights to be granted to that particular user. Primary Actors Administrator Page 94 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

Secondary Actors Section Controller Dy. Trains Dy. Coaching Power Controller Yard Manager MIS User Flow Of Events 2.1.19 Basic Flow – Manage User The use-case starts when user clicks the Administration option from the main menu. System shall display the following options to the user. 1) Change Password 2) Manage User If the user is an administrator, both the above options shall be available else only the Change Password option shall be available. 2.1.19.1

Change Password This option shall apply to users of all groups. • When User clicks the Change Password option, a screen shall be displayed with login details • User shall enter the old password and the new password (twice) and submit the details. • System shall validate the old password and the new password • If both are valid then o System shall display confirmatory message and use case ends.

2.1.19.2

Admin Tasks This option shall apply only to the administrator When the user clicks the Manage User option, system shall display the following options. 1) Manage Users To create new login, user shall click New button on the screen.  User shall enter details like login id, login name, designation, group, active status, active from date or de-active to date and submit the details  System shall validate login id, group and active from date

Page 95 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS 

If valid •



System shall generate the default password, which would be the same as the login id and shall display the confirmatory message. If Invalid • System shall generate appropriate message and set focus on the invalid detail

To modify existing login details, user shall select the required record and change the details whichever required.  System shall also have provision to re-initialize the password by clicking the Reset Password option.  If Reset Password is clicked, system shall re-initialize the password to the existing login id after a confirmation from user.  If a certain login id needs to be deactivated, user shall select the deactivate option and enter the deactivate to date. System shall validate the changed details. If valid o System shall save the details and confirmatory message shall be displayed

 

2.1.19.3

Manage User Groups With this option user can create and modify new user groups. A user group can have one or more different functionalities clubbed into it. • User shall enter the Group Id and select the functions to be included in the group by checking the corresponding tasks. • If the Group Id already exists, the details shall be overwritten else a new User Group shall be created. • User shall submit the details and system shall save the information.

Pre-Conditions • Super User id and password should have been pre-populated in the relevant database table • Task information should have been pre-populated in the relevant database table. •

Post-Conditions Password entities shall be saved in encrypted format in the database Business Rules

Page 96 of 122

)

i)

ii)

v)

v)

vi)

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS Assumptions

USE-CASE Specification – Miscellaeneous Functions The purpose of this use case is to allow for reporting through certain exception tasks. Primary Actors Section Controller Dy. Trains Dy. Coaching Secondary Actors Flow Of Events 2.1.20 Basic Flow – Reporting Miscellaneous Tasks The use-case consists of following tasks, which are accessible from different menu options 1) Preferences Setting 2) Station Layout 3) Master Chart View/Print 2.1.21 Alternative Flows 1) Preference Settings User shall be able to change the default settings in certain cases. A list of settings along with default/current values shall be displayed. User shall then give the desired value by selecting from list of given values or by entering the value and save it. The various configurable parameters shall be Lead Time of appearance of train on graph. The lead-time for appearance of dot on the graph shall be determined through this parameter. The default value for this shall be two hours. Graph refresh time frequency This parameter shall determine the frequency with which the graph shall be refreshed. Default value of 5 minutes shall be set. Duration of advance plotting The duration of view of advance plotting shall be configurable through this parameter. The duration shall vary from 2-6 Hrs. Duration of previous graph The view of previous graph shall be configurable from 2-6 Hrs. Line occupancy view on graph Line occupancy view on graph may be switched off through this option. Duration of chart save

Page 97 of 122

vii)

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS The duration of chart after which it has to be saved by the system shall be set through this parameter. The default value shall be every 8 Hrs. Train line width The line width of trains being displayed on graph can be changed through this option. 2) Station Layout User shall select the station from list of stations in the section. Station layout of selected station shall be displayed on the screen. 3) Master Chart View/Print Facility of viewing/printing of master charts shall be available to the user. User shall select the day and required shift from the given list. Default value of current day and current shift shall be displayed. System shall display master chart for selected day and shift. User shall have facility of printing the displayed chart. Pre-Conditions Preference Setting option shall be enabled on administrator login. Interface with Allied Systems: Some data generated in the divisional control office is shared periodically with other divisions, higher operating units like Zonal Headquarters and Railway Board and allied systems like FOIS, NTES. Considering that COA is a real time application, the data generated from this system has more reliability and consistency and can be leveraged for use by other systems like NTES, FOIS . Moreover for seamless integration of neighbouring divisions, such data would facilitate smooth operational transition and better efficiency through a single point data entry across the network. The common data would thus flow electronically through the system to other/adjacent divisions and allied systems. This would initially be a asynchronous interface (loosely coupled) using optimum bandwidth between divisional tier and central tier. A low level design document on Integration would be included along with the main Detailed Design document.

USE-CASE Specification – Integration of COA with FOIS/NTES/Neighbouring Division The purpose of this use case is to facilitate mutual sharing of specific data between Divisional COA’s , NTES and FOIS (in the initial phase). Primary Actors Divisional COA System Page 98 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS CAS NTES Client FOIS Client Secondary Actors Flow Of Events 2.1.22 Basic Flow – Integration with NTES The NTES sub system currently provides information to the users about the arrival and departure time at nominated stations for specified passenger services on a country wide basis. The present limitations of this feature includes non availability of real time information on account of time lag in the occurrence of the event and reporting. There is also some level of inconsistency in the information made available to the public due to human errors. The COA would therefore provide continuous flow of the following data to NTES through CAS messaging server and bring about high degree of reporting accuracy and reliability. The details include :  Train Number  Date of Departure  Station Id  Arrl/Dep Flag  Arrl/Dep Time  Status of the train. Initially the above details would be pushed only in respect of reporting stations specified for the train under NTES.(These details shall be mapped through the NTES flag in the Train schedule under COA). There would however be flexibility to report for more stations in the route of the train in case of future requirement from NTES . Integration with FOIS The FOIS presently provides vital information related to operations concerning freight trains and terminal performance. These include demand for wagons (destination wise), loads in sight for Divisions/Terminals, dissipation of freight stock and other performance indices such as average speed of trains, hours of run, engine utilization etc. The COA would initially pull the following data from FOIS to supplement the information needs in respect of freight trains : a. Consist details i. Train id ii. From sttn iii. To sttn Page 99 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS iv. v. vi. vii. viii.

Load summary Stock type wise summary Commodity Consignor Consignee

b.

Crew details i. Name of the Driver ii. Name of the Asst Driver iii. Name of the Guard iv. Sign on time-Driver v. Sign on time-Guard

c.

Locomotive details i. Locomotive Number ii. Locomotive type iii. Base shed iv. Last schedule attended v. Last schedule date. BPC details. i. Whether CC Rake or not ii. BPC No. iii. Date of Issue iv. Valid for Kms. v. Balance Kms.

d.

e.

Trains on run in adjacent division (Non COA implemented) i. Section Name ii. Direction iii. Train Id iv. Loco Number v. From sttn vi. To sttn vii. Last Reporting station viii. Departure time ix. ETA at I/C Point The details under (e) shall be displayed only in respect of goods trains and light engine whose To sttn (Destination) is either the Divisional Interchange Point or beyond that point.

Considering the fact that COA would ultimately become the core application and drive FOIS , the scope of the integration functionality shall be scalable and facilitate inter system information exchange.

Page 100 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS Integration with COA of Neighbouring Division In the present system of railway working, the operational efficiency of a division is inter dependent on the working of a neighbouring division and restricts availability of vital inputs in decision making. This also leads to ineffective utilization of assets and frequent human interaction. To overcome this limitation, the relevant operational data needs to be exchanged between two neighbouring divisional COA’s. The functionality in the initial phase shall provide for train running information in respect of passenger services and freight trains based on appropriate model (NTES or advance plotting). A station shall be nominated for this purpose in rear of the divisional interchange point in either direction and reporting of the departure time at this station shall trigger the flow of information to adjacent division. The details shall be displayed in respect of all trains including light engine whose To_sttn (Destination) is either the Divisional Interchange Point or beyond that point. In respect of Passenger services, the details shall include :  Train number  From sttn  To sttn  Load summary  Station Id  Departure time  ETA at Interchange point. In respect of freight trains including Light Engine, the details shall include :  Train Id  Loco Number  From sttn  To sttn  Crew on duty time  Load summary  Station Id  Departure time  ETA at Interchange point.

Page 101 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

USE-CASE Specification – Instantaneous Alerts - SMS The purpose of this use case is to facilitate the system to generate and transmit instantaneous alerts to specified users in the form of short messaging service (SMS). The recipients of these SMS’s will include only the COA specific divisional users initially but will provide flexibility to include global users, when required. Actors Primary Actors COA System Flow Of Events 2.1.23 Basic Flow – During the course of train operations, certain events are to explicitly defined as occurrences of critical importance and need to be instantaneously communicated to relevant operational personnel for information and follow up. A matrix mapping the events with the list of personnel to whom the information need to be conveyed is given below :

Intended recipients Events DRM ADRM SR. DOM AOM CHC SR. SR. SR. SR.DEE SR. DOM DCM DEE DEE (RS) DSTE (TRD) Accidents Y Y Y Y Y Y Y Y Y Y Y UnusualY Y Y Y y Sigg UnusualY Y Y Y Engg UnusualY Y Y Y Y Traffic

Page 102 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS UnusualComml UnusualLocoElect UnusualLoco-Dsl UnusualC&W UnusualElecTL/AC UnusualElec-Trac UnusualACP UnusualMisc

Events Accidents UnusualSigg UnusualEngg UnusualTraffic Unusual-

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

y

Y

y

Y

Y

y

Y

SR. DME Y

SR. SR. DME(D) DEN ( C) Y Y Y

DEN DSC (SEC) Y

y

y y

PRO Y

Y

Page 103 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS Comml UnusualLocoElect UnusualLoco-Dsl Unusual- y C&W UnusualElecTL/AC UnusualElec-Trac UnusualACP

y

y

The mapping of events and the intended recipients shall be configurable locally according to the divisional requirement. The message content shall include : • Location • Train Number (Where involved) • Time of occurrence (Start time) • Unusual-Type • Cause The size of the message shall be limited to the default size as prescribed by the service provider and the content requirement configurable. 2.1.23.1

Pre-Conditions

USE-CASE Specification – Integration with Data Loggers Brief Description The purpose of this use case is to document the scope of work and flow pertaining to integration of COA application with Data logger equipment. Actors Primary Actors Data logger Flow Of Events Page 104 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS 1.0 Basic Flow 2.1.24 Automatic Train Ordering The Use case starts whenever a train enters a station in a section, which is equipped with data loggers. The relays integrated with tracks/signals and points at the station transmit the raw data to the data logger, which in turn is networked to a central server at the divisional control. Whenever detection of a train on the track occurs or a signal device is operated, the data logger logs the event and transmits the data to the divisional control. The interface software will map the individual events received from the data logger and map to COA application specific events This raw data (in hexadecimal or any other format) contains information like RelayId, LineId, Data Logger Id, Sequence Numbers, Record Id , Timestamp and Status/Value. This information would be mapped to relevant details required by COA application like arrival time/departure time/run through time, line no and station id. Train Linking The sequence of steps to link a train entering into a section equipped with data loggers is as follows • • • • •

Train enters into the station equipped with data loggers Raw data is generated by data logger equipment and gathered by the interface software COA application extracts the relevant raw data, refines the same and stores them in data logger interface tables after mapping A pre scheduled process extracts this information from the data logger interface tables and trigger the appearance of a dot on the chart at the station representing the beginning of the section. User then links the train to the dot on the chart by entering the train id.

In the event of the non-working of data logger equipment, the system shall have the provision of turning off this option and switch to the manual mode of train ordering through the Train Ordering screen. The system shall also generate suitable alerts informing the user about the event of non functioning of data logger equipment and also intimate the resumption of functioning of the same.

6.0 • •

Assumptions Datalogger equipment is assumed to installed on a complete board in continuous fashion. The data along with relevant formats required for interfacing with COA application shall be made available by the OEM vendor of data logger equipment.

Page 105 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

3 Operational Concepts and Scenarios Distributed Architecture: The system would be implemented initially on two pilot divisions of Southern Rly and ultimately across the IR territory covering approximately 80 control offices. The entire geographical area is divided into various sub-areas for operational and administrative control. Each divisional control office is more or less independent of other divisions and requires interaction with adjoining divisions only for incoming trains and a major portion of the data generated is thus consumed within the division. Therefore a division should be able to work independently even if adjoining divisions’ systems are down through a Page 106 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS distributed architecture. A divisional level illustration of COA implementation is depicted below

COA Application will have an integrated approach where there will be multiple divisional implementations each of which will have individual physical storage. Certain amount of data will be passed across using the messaging via CAS. Each division will comprise of a 2 servers interconnected with each other with clustered database. And each division will have a storage in which the physical data will be stored. The system is based on the three-tier architecture comprising of the Presentation, Business and Data Layers. Presentation Layer: This layer is basically the user interface developed in C#; this will have the basic logic for the validation and presentation of the incoming and outgoing data.

Page 107 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS Business Layer: This layer captures the business rules as classes/components that can be reused across application. As a whole this layer houses the full logic of the application developed in C# Data Layer: This layer the repository of information/data of the whole application in a centralized place, which can be accessed from the business rules. This layer implements the concept of both physical and logical independence of data and would be in Oracle 10g. Physical Architecture:

The Client Desktop will have windows xp to access the application server. The application server, which will have Windows 2003 server, serves the data and passes on to the database and inturn it passes to the Storage where the physical data would be stored. Some part of the data would be passed from the storage to the CAS via Messaging.

Highly Available System: 24x7 availability to users with minimum down time is an important requirement of Control Office Application. The system is highly critical and thus would be having a very high redundancy to ensure non-stop operation. The system would give priorities to certain important requests and be scalable enough to increase the number of clients without degrading performance. Although, the interface with other divisions allied systems is asynchronous, the system would be near real time so that the response is compromised only to a limited extent. The exchange of information within the division as well as with other divisions and allied systems would be highly reliable. The divisional servers shall be in cluster with fail over features

Evolutionary MIS: The Control Office Application would have a robust database to cater to any changes in the database design in preliminary stages of its development. Any decision to introduce new data structures or modifications to existing data structures would be easily addressed. There is, therefore, a requirement for evolutionary MIS and scalability of the Control Office Application. The divisional Control Room Operations software shall be developed on a Standard XA Compliant RDBMS and .Net Application server. Page 108 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

Security of the System The system will have various security levels namely Application Level Security, Database Security and Physical Security. The security of COA shall be the responsibility of shall be at two levels. Central Level The Central Security Administrator(CSA) shall be responsible for creating and modifying the users for the central level referential and timetabling data Divisional Level The Divisional Security Administrator shall be responsible for the security of COA and other divisional level interfaces Physical Security The Divisional/Central Security Administrator shall be responsible for the physical security of the system Their responsibilities shall include o Maintenance of security of Database Servers by keeping it locked and prohibiting entry of any unauthorized person to prevent thefts and other untoward incidents o Access to the database server shall be protected by password and only the System Administrator shall be aware of the same. o Maintenance of multiple power supply connections for uninterrupted power supply Database Security The following measures shall be taken for ensuring database security • Role based access Only the Divisional Security Administrator shall have access to the database directly. All the other users shall access the database through the application. • Encryption of Stored Data Certain important and sensitive data shall be stored in encrypted format to prevent unauthorized access. Application Security Application Security shall be implemented by way of User Maintenance and Client Maintenance Page 109 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS • User Maintenance The DSA shall create userids of of various roles such and each of the roles shall have tasks associated with it. Access shall thus be controlled by role based security. E.ach role shall have a list of tasks associated with it. New roles can be created by the DSA which may have additional tasks associated with it. Tasks are in turn are mapped to various functionalities provided by the COA frontend application.

4 Interface Requirements The COA Application would have a user friendly GUI interface with rapid data entry capability and actions through a minimum of keystrokes /clicks. The User Interface and design is liable to changes, at least initially, on account of addition or modification in functionality as the system has to be implemented at various locations with varied kind of operations

Hardware Interfaces 4.1.1 Dual Screen Capability The COA Application functionality would be visually displayed on two monitors. The larger 21” monitor would be used to display the movement of trains and other related information like Blocks, Caution Orders, Crossings and Precedences on Time vs Stations graph format.The other monitor would be used to capture train, track and movement related data and other necessary inputs needed for sectionwise monitoring. This monitor would also have a Touchscreen capabilities wherever it is deemed to be suitable and feasible.

4.1.2 Chart Printing Sectional Control charts are required by senior operational railway officials on a periodic basis for decision making. For this requirement , the COA shall interface with a Graphic Plotter to print Control Charts along with relevant related information. This shall provide the capability to print current as well as back dated/historic control charts. Hardware Environment Item

Specification

Development Server

Intel XEON processor 3.0 2 Nos GHz/512 KB cache. Each with 36 GB HDD Intel based Pentium PC’s 10 nos with 40 GB HDD /512 MB DDR RAM Intel Pentium –IV processor 2 nos with 1 GB RAM / 80 GB

Development Clients Display/Testing Clients

Qty

Page 110 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS HDD Graphic Plotter for chart 42” width/1200dpi/16 MB 1 nos printing RAM Common External Storage 4 X 146 GB capacity 1 nos GSM Modem Nokia GSM Terminal with 1 1 nos MB flash memory Software Specifications COA software would be developed using Microsoft .NET framework architecture with both the UI middle layer being in C#. The backend would be in Oracle 10g with clustered design on an external storage. Software Component Miscrosoft .NET C# and ASP.NET Miscrosoft .NET C# Oracle 10 g Microsoft Visual SourceSafe Rational Rose

Layer UI and Presentation Layer Middle Layer/Business Logic Database Version Control Software Engineering /Testing

Browser based access to MIS Queries/Reports The proposed COA application shall have provision for displaying query based MIS reports. The report types and formats are comprehensively described in the MIS Use case ( refer Use Case specification - MIS Reports). These initial set of reports shall be made available as static ones with a fixed content format. Customizable reports as per divisional requirements shall be taken up in the subsequent enhancement and support phase. Architecture for Reports The reports shall be primarily available through a browser interface as a set of web pages which can be accessed through the divisional intranet. These web pages shall be developed using ASP.NET having a thin presentation layer for report display. These web Page 111 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS pages shall be hosted in the IIS (Internet Information Server) running on the production server. The business logic for processing the queries shall be encapsulated as a set of shared C# classes in the middle-tier. This will facilitate re-use of the same classes for any such corresponding requirement by the COA application. An illustration of the architecture is shown below Browser Interface (asp.net)

Browser Interface (asp.net)

Browser Interface (asp.net)

Divisional Server

COA Clien t

IIS Server

Reports webroot

COA Clien t

COAQuery Application Server Classes – C#

DB

C# classes for query processing ( Middle layer constituent) ASP.NET Webpage interface

The proposed browser interface shall be made available in two different ways depending upon the type of user. These will be made available as a list of logically grouped hyperlinks. Clicking on any of these hyperlinks would result in the corresponding report to be displayed in a tabular format. The user shall also have provision to print the displayed report •

Independent Browser Interface – Through this option, users who do not have COA client like senior railway officials can access various kinds of reports by opening the browser directly invoking a URL pointing to the home page of the reporting module. The advantage of this would be the capability to access these reports from any location in the divisional intranet. A standard machine connected to the intranet with a compatible browser would be Page 112 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

•

sufficient. To protect the COA application from undesirable security hazards, virus etc it would be isolated from the internet as adequate security infrastructure is not available in the initial phase. Menu invocation from COA Application – Through this option , users like the Section Controller and others using the COA application, can access these reports by clicking on this menu option. A form acting as a container to the browser shall be invoked with the URL of the web page for the reports

5 Non functional/Specific Requirements Compatibility Since the system would be built on a .NET platform and deployed on Windows Server 2003 it would be compatible and will be able to comfortably interface with other Microsoft platform based technologies in case of future needs of COA. Interoperability The basic high level design of COA application shall ensure Interoperability with other industry platforms .As the COA application is based on a .NET platform it shall facilitate easy interfacing with industry standards. Portability and Migration There will be a high degree of modularization in the architecture of the system .In case if there is a need to migrate to a different platform, bulk of the changes would only need to be made at the platform level. This shall be facilitated by using relevant Rational Rose methodology.

Quality Assurance All the deliverables and developed objects would be configuration items, which will be managed for their version control. Each configuration item would undergo review by peer review team headed by a review leader. The quality records are maintained in the Wipro formats with the available guidelines and templates. For documentation purpose WIPRO ISO9002 standards and guidelines would be used . Software Engineering. Rational Rose shall be the design tool used for capturing the user and functional requirements through the use case template. For testing purposes Rational PurifyPlus shall be used for unit testing of the COA application modules.

Page 113 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS Performance Performance of the COA application shall largely depend on the application architecture that would be proposed in the detailed design document. Periodic refinements to the architecture would be taken up depending upon the levels of performance exhibited by the application at the time if unit testing and integration testing. To some extent the performance would also be dependant on the hardware configuration proposed for the solution. However the application would be tweaked periodically to maximize the performance over a period of time. Reliability The COA application would be reliable and available with minimum downtime. This would be facilitated with failover mechanism on the application server. This would be implemented by running two instances of the application on the server and incase of failure of the primary instance, the control would be automatically be passed on to the secondary instance. The same would be applicable in case of the database server also wherein the application database would be maintained in a mirrored fashion with failover support in case of db failure The system administrator/database adminstrator would also be taking a periodic backup for data loss prevention. Deployment The COA system shall easily portable and installable with minimum effort. Since the solution is .Net based , all the required files can be ported on to a cd and installed with the xcopy utility.

Risks Risk 1 Risk Identification checklist SL. No. Risk Item Identified / Added Impact of Risk (High / Medium / Low ) Probability of Occurrences of Risk (High / Medium / Low ) Action Plan (MUST for High Impact Risks or High Probability of Occurrences of Risks)

1 Frequent Changes in functionality Medium Medium Mitigation Plan *

Contingency Plan *

Page 114 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

Names of Affected Groups Date Plan ----

Make the Specification clear as far as possible by conducting frequent reviews and signoffs The whole team As and when it happens

An impact analysis will be done for each change request that comes and a change management strategy will be made.

Replan--Actual --Remarks Risk 2 Risk Identification checklist SL. No. Risk Item Identified / Added Impact of Risk (High / Medium / Low ) Probability of Occurrences of Risk (High / Medium / Low ) Action Plan (MUST for High Impact Risks or High Probability of Occurrences of Risks)

Names of Affected Groups Date Plan ---Replan--Actual --Remarks Risk 3 Risk Identification checklist SL. No. Risk Item Identified / Added Impact of Risk (High / Medium / Low ) Probability of Occurrences of Risk (High / Medium / Low )

2 The unavailability of the client supplied items High Medium Mitigation Plan *

Contingency Plan *

The client has been informed well in advance about the same The whole team As and when it happens

A re-estimation of the schedule will be done and the new dates will be intimated to the client.

3 Hardware Failure Medium Low

Page 115 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS Action Plan (MUST for High Mitigation Plan * Contingency Plan * Impact Risks or High Probability of Occurrences of Risks) Regular check up of All hardware patch ups and the hardware checking up of the hardware regularly. Names of Affected Groups The whole team and users Date Plan ---As and when it happens Replan--Actual --Risk 4 Risk Identification checklist SL. No. Risk Item Identified / Added Impact of Risk (High / Medium / Low ) Probability of Occurrences of Risk (High / Medium / Low ) Action Plan (MUST for High Impact Risks or High Probability of Occurrences of Risks)

Names of Affected Groups Date Plan ---Replan--Actual --Remarks Risk 5 Risk Identification checklist Sl. No. Risk Item Identified / Added Impact of Risk (High / Medium / Low ) Probability of Occurrences of Risk (High / Medium / Low )

4 Software Failure Medium Low Mitigation Plan *

Contingency Plan *

Checking up the Cleaning database and other regularly software tools regularly The whole team As and when it happens

up

database

5 Virus Attack High Medium

Page 116 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS Action Plan (MUST for High Mitigation Plan * Contingency Plan * Impact Risks or High Probability of Occurrences of Risks) Apply latest antivirus CD cuts, Backup’s on tape patches drives and stops the spreading of virus by isolating the systems. Names of Affected Groups The whole team Date Plan ---As and when it occurs Replan--Actual --Remarks Risk 6

Risk Identification checklist Sl. No. Risk Item Identified / Added Impact of Risk (High / Medium / Low ) Probability of Occurrences of Risk (High / Medium / Low ) Action Plan (MUST for High Impact Risks or High Probability of Occurrences of Risks)

Names of Affected Groups Date Plan ---Replan--Actual --Remarks

6 Resource attrition High Medium Mitigation Plan *

Contingency Plan *

Replace resource with Identify backup resources for similar skillset in the each critical resource. shortest time possible Backup resource should be in sync with the main resource. The whole team As and when it occurs

Risk 7

Risk Identification checklist Sl. No. Risk Item Identified / Added Impact of Risk (High / Medium / Low ) Probability of Occurrences of

6 Technology/Platform Obsolescence Low Low Page 117 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS Risk (High / Medium / Low ) Action Plan (MUST for High Mitigation Plan * Impact Risks or High Probability of Occurrences of Risks) Alternate support system needs to be identified and put in place. Names of Affected Groups The whole team Date Plan ---As and when it occurs Replan--Actual --Remarks

Contingency Plan *

Design of the system facilitates migration to updated technology.

6 Assumptions/Dependencies/Limitations Assumptions 1)The data to be used for development and testing of COA application would be derived from the existing information in the Working Time Tables ( WTT ) for each division across the Railway network. 2) Certain data like intersectional running times and time loss speed restrictions for goods trains are derived from historical charts collected over a period of time. 2) The data that is received from external sources like FOIS is assumed to be consistent and accurate.(mentioned Dependencies The integration of various sub systems with COA application will be having the following dependencies. 1)The readiness of FOIS subsystem in terms of the the necessary client software developed and tested prior to integration 2)The readiness of NTES to receive the messages/files from the messaging server Limitiations The following are the limitations of the proposed COA Application. 1) The Advance Plotting functionality is only a guiding feature to assist the user. It just gives a visual representation of possible train movements and is not intended to control the same.

Page 118 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

7 Acceptance Criteria Approach In order to identify errors at an early stage and hence prevent a breakdown at a later stage, various levels of the testing will be carried out for this project. Test plans will be prepared, reviewed and approved before testing commences. Test plan will be documented and testing will be done as per the approved plan. Listed below are the various kinds of testing that is identified for various stages of the project.Rational Rose shall be used for this purpose • Unit testing • Integration testing • Acceptance testing • Stress testing All the above levels of testing planned will be conducted systematically. The activities that are to be carried out for each of these testing will include: • • •

Test planning Test case preparation Test execution

Unit Testing Activities that will be followed for Unit Testing are the following. The Unit test plan shall ensure the following activities • Ensure that instructions related to the test cases are executed properly. • Verify operation at normal value range. • Verify operation outside range values. • Verify program execution at boundary conditions. • Ensure that all loops are terminated normally. • Identify and remove abnormal termination of all loops. • Ensure all errors are trapped. • Ensure all the objects opened are closed

Integration Testing When all the modules are fully developed functionally, all these modules will be integrated and tested for all types of compatibility issues and other kind of issues. For this testing all the above mentioned checkpoints will be there. These tests will be derived from the design document.

Page 119 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS At the end of these testing the following documents will be made and handed over to the concerned people. Test Cases (Unit test cases, Integrated test Cases) Proof of testing done. Acceptance Testing The acceptance test plans will be made and will be handed over to CRIS. The CRIS representative can check the acceptance test plans and verify that the whole functionality is covered to ensure the computer system will fit the operational procedures. Acceptance Criteria Wipro team and CRIS Team will evolve acceptance test specification during the end of the design phase. Wipro proposes that, the successful execution of Acceptance Test plans in the Acceptance test environment shall be the acceptance criteria for this project. Acceptance Process The acceptance procedure shall be • • • •

Wipro Team delivers the configured system Wipro and CRIS build the Acceptance testing Environment and load the test data Perform acceptance testing by CRIS representatives with support by Wipro Team Review of Acceptance test results and Sign off by CRIS

CRIS needs to conduct Acceptance testing within two weeks from the date of delivery of the software for acceptance testing phase. It is assumed that CRIS will perform similar acceptance process on all other deliverables and will complete the acceptance with in 5 days from the delivery.

8 Allocation of System Requirements System Allocated to Hardware Allocated to Requirement Software Reference (Tick if applicable) Failover Mechanism Clustered Database on for Database Server Storage Failover Mechanism for Application Server Failover Mechanism for Message Queue Server Page 120 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

9 Others Existing systems – Control/Train Charting Application at Divisional/Sectional level A system study was done to evaluate the various features and functionalities provided by existing Control Charting Applications in operation at following places 1) KOTA Division 2) Chennai Division The analysis was undertaken at these locations in order to evaluate the best features/functionalities provided by these existing systems and every effort would be taken to incorporate the same in the proposed COA application. Features/Functionalities that are not relevant or that or not within the current scope of the development shall be excluded.

10 Acronyms and Glossary S.No 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13 14. 15. 16 17. 18. 19. 20. 21. 22. 23.

Acronym/Abbreviation CCA COA FOIS NTES MIS CAS OHE ETD ETA SC AOM DOM ART BPC LE LTM SM CMS SMS CTR TSR EOL HQ

Expansion/Description Control Charting Application Control Office Automation Freight Operations Information System National Train Enquiry System Management Information System Central Application Server Over Head Equipment Estimated Time of Departure Estimated Time of Arrival Section Controller Assistant Operations Manager Divisional Operations Manager Accident Relieff Train Brake Power Certificate Light Engine Late Train Movement (report) Station Master Crew Management System Short Messaging Service Combined Train Report Temporary Speed Restriction Engine On Load HeadQuarters

Page 121 of 122

REQUIREMENT SPECIFICATION COA_CRIS – P – 1.1 – RS

11 Signoffs Requirements for Control Office Application (COA) As per the requirement study conducted by Wipro team, this document includes the complete list of requirements of the Control Office Application(COA)

For Wipro

For CRIS

Page 122 of 122