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]
Project Manager / Email ID: Praveen Kumar Rajuladevi
[email protected]
Quality Co-ordinator / Email ID: Santosh Dharwadkar
[email protected]
Mr.Rajeev Gupta –GGM(IT)
Customer Contact Information: Centre for Railway Information Systems

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 Date of Description of Reason for Affected Approved By

(x.yy) Revision Change Change Sections
1.0 11-April- Draft Version for
05 submission to
CRIS
1.1 05-July-05 Included Browser URD reqmnt
based access to
MIS reports

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

 Section Controller shall enter new destination station.

 If there is change in the route but 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 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

• 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.
• On saving.
 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 case-
Accidents).
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
 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
o System shall only display “Both” option for selection.
• If the block section is in a Double line section, then
o 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

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.

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

• 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
o Train Number
o Locomotive(s) Number
o Driver Name
o Guard Name
o Load Summary

In case of Goods Trains

o Train Name
o Locomotive(s) Number
o Driver Name
o Guard Name

Page 68 of 122
 REQUIREMENT SPECIFICATION
COA_CRIS – P – 1.1 – RS

o Load Summary
o Sign on time.

In case of Light Engine

o To station
o Locomotive(s) Number
o Driver Name
o Guard Name (If available)
o Sign on time

In case of Track Machine/Tower wagon/Trolley

o Machine Name / Trolley or Tower wagon
Number
o 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 pre-
determined 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 well-
defined 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 pre-
defined 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:
1- Accident Relief Trains or Light Engine proceeding to accident spot
2- Mail/Express Trains [Rajdhani / Shatabdi]
3- Mail/Express Trains [Other than above]
4- Troop trains (Military Specials)
5- Passenger Trains
6- Mixed Trains
7- Inspection Specials
8- Goods Trains [Crack Trains / Other goods trains / Shunting trains]
9- Light Engine not going to accident spot.
10- Material 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 block-
section 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 co-
ordinates.
• 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

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

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

2.1.17.3 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 :
 No.of trains
 No.of Engines-Electric
 No.of Engines-Diesel
 Total No.of units

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

5. 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 Train Number(s) affected

o Delay in minutes
o Remarks

2. 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]

3. Utilisation of Maintenance Blocks

Page 90 of 122
 REQUIREMENT SPECIFICATION
COA_CRIS – P – 1.1 – RS

• 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

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

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

7. 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 From station
o To station
o Detachment-Train Number
o Detachment-Time/Date
o Detachment Reason
o No.of days since detachment (Sys date – detach date)
o 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 row-
wise.

Page 93 of 122
 REQUIREMENT SPECIFICATION
COA_CRIS – P – 1.1 – RS

 The status field against each line shall include the following options-
Vacant/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
 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.
i) 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.
ii) 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.
v) Duration of previous graph
The view of previous graph shall be configurable from 2-6 Hrs.
v) Line occupancy view on graph
Line occupancy view on graph may be switched off through this
option.
vi) Duration of chart save

Page 97 of 122
 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.
vii) 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. Load summary

v. Stock type wise summary
vi. Commodity
vii. Consignor
viii. 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.
d. BPC details.
i. Whether CC Rake or not
ii. BPC No.
iii. Date of Issue
iv. Valid for Kms.
v. Balance Kms.

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
Unusual- Y Y Y Y y
Sigg
Unusual- Y Y Y Y
Engg
Unusual- Y Y Y Y Y
Traffic

Page 102 of 122

 REQUIREMENT SPECIFICATION
COA_CRIS – P – 1.1 – RS

Unusual- Y Y Y Y
Comml
Unusual- Y Y Y Y y
Loco-
Elect
Unusual- Y Y Y Y
Loco-Dsl
Unusual- Y Y Y Y
C&W
Unusual- Y Y Y Y y
Elec-
TL/AC
Unusual- Y Y Y Y y
Elec-Trac
Unusual- y Y y
ACP
Unusual- Y Y Y y
Misc

Events SR. SR. SR. DEN DSC PRO

DME DME(D) DEN (SEC)
( C)
Accidents Y Y Y Y Y
Unusual-
Sigg
Unusual- Y Y
Engg
Unusual-
Traffic
Unusual-

Page 103 of 122

 REQUIREMENT SPECIFICATION
COA_CRIS – P – 1.1 – RS

Comml
Unusual-
Loco-
Elect
Unusual- y
Loco-Dsl
Unusual- y
C&W
Unusual-
Elec-
TL/AC
Unusual-
Elec-Trac
Unusual- y
ACP

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 Qty
Development Server Intel XEON processor 3.0 2 Nos
GHz/512 KB cache. Each
with 36 GB HDD
Development Clients Intel based Pentium PC’s 10 nos
with 40 GB HDD /512 MB
DDR RAM
Display/Testing Clients Intel Pentium –IV processor 2 nos
with 1 GB RAM / 80 GB

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 Layer

Miscrosoft .NET C# and ASP.NET UI and Presentation Layer
Miscrosoft .NET C# Middle Layer/Business Logic
Oracle 10 g Database
Microsoft Visual SourceSafe Version Control
Rational Rose 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 Browser Browser

Interface Interface Interface
(asp.net) (asp.net) (asp.net)

Divisional Server

COA
COA IIS Server Clien
Clien Reports webroot
t
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. 1

No.
Risk Item Identified / Added Frequent Changes in functionality
Impact of Risk (High / Medium / Medium
Low )
Probability of Occurrences of Medium
Risk (High / Medium / Low )
Action Plan (MUST for High Mitigation Plan * Contingency Plan *
Impact Risks or High
Probability of Occurrences of
Risks)

Page 114 of 122

 REQUIREMENT SPECIFICATION
COA_CRIS – P – 1.1 – RS

Make the Specification An impact analysis will be

clear as far as done for each change
possible by conducting request that comes and a
frequent reviews and change management
signoffs strategy will be made.
Names of Affected Groups The whole team
Date Plan ---- As and when it happens

Replan---

Actual ---
Remarks

Risk 2
Risk Identification checklist SL. 2
No.
Risk Item Identified / Added The unavailability of the client supplied items
Impact of Risk (High / Medium / High
Low )
Probability of Occurrences of Medium
Risk (High / Medium / Low )
Action Plan (MUST for High Mitigation Plan * Contingency Plan *
Impact Risks or High
Probability of Occurrences of
Risks)
The client has been A re-estimation of the
informed well in schedule will be done and
advance about the the new dates will be
same intimated to the client.
Names of Affected Groups The whole team
Date Plan ---- As and when it happens
Replan---
Actual ---
Remarks

Risk 3
Risk Identification checklist SL. 3
No.
Risk Item Identified / Added Hardware Failure
Impact of Risk (High / Medium / Medium
Low )
Probability of Occurrences of Low
Risk (High / 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. 4
No.
Risk Item Identified / Added Software Failure
Impact of Risk (High / Medium / Medium
Low )
Probability of Occurrences of Low
Risk (High / Medium / Low )
Action Plan (MUST for High Mitigation Plan * Contingency Plan *
Impact Risks or High
Probability of Occurrences of
Risks)
Checking up the Cleaning up database
database and other regularly
software tools
regularly
Names of Affected Groups The whole team
Date Plan ---- As and when it happens
Replan---
Actual ---
Remarks

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

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. 6
No.
Risk Item Identified / Added Resource attrition
Impact of Risk (High / Medium / High
Low )
Probability of Occurrences of Medium
Risk (High / Medium / Low )
Action Plan (MUST for High Mitigation Plan * Contingency Plan *
Impact Risks or High
Probability of Occurrences of
Risks)
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.
Names of Affected Groups The whole team
Date Plan ---- As and when it occurs
Replan---
Actual ---
Remarks

Risk 7
Risk Identification checklist Sl. 6
No.
Risk Item Identified / Added Technology/Platform Obsolescence
Impact of Risk (High / Medium / Low
Low )
Probability of Occurrences of Low

Page 117 of 122

 REQUIREMENT SPECIFICATION
COA_CRIS – P – 1.1 – RS

Risk (High / Medium / Low )

Action Plan (MUST for High Mitigation Plan * Contingency Plan *
Impact Risks or High
Probability of Occurrences of
Risks)
Alternate support Design of the system
system needs to be facilitates migration to
identified and put in updated technology.
place.
Names of Affected Groups The whole team
Date Plan ---- As and when it occurs
Replan---
Actual ---
Remarks

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 Acronym/Abbreviation Expansion/Description

1. CCA Control Charting Application
2. COA Control Office Automation
3. FOIS Freight Operations Information System
4. NTES National Train Enquiry System
5. MIS Management Information System
6. CAS Central Application Server
7. OHE Over Head Equipment
8. ETD Estimated Time of Departure
9. ETA Estimated Time of Arrival
10. SC Section Controller
11. AOM Assistant Operations Manager
12. DOM Divisional Operations Manager
13 ART Accident Relieff Train
14. BPC Brake Power Certificate
15. LE Light Engine
16 LTM Late Train Movement (report)
17. SM Station Master
18. CMS Crew Management System
19. SMS Short Messaging Service
20. CTR Combined Train Report
21. TSR Temporary Speed Restriction
22. EOL Engine On Load
23. HQ 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