Vous êtes sur la page 1sur 56

+||za =z+|z

z =|n

GOVERNMENT OF INDIA
MINISTRY OF RAILWAYS



jseyV;qDr eklslj vk/kkfjr fu;af=r yd esa vkfIVekbTM yd
pkyu gsrq funsZ'ku ds fy, fof'kf"V

Specification of Guidance for Optimized Loco Driving (GOLD)
for Microprocessor based Locomotive Control System with
REMMLOT fitted locomotives
ii.|ie =an| =|c|c.c.,=c,.,=(==|cc:)
=|= ,c:,
Specification NO. MP.0.2402.24 (Rev.0.01)
March 2012




n=||n i+|+- |z =|n+ =msn
a|n=-,, c::.
RESEARCH DESIGN & STANDARDS ORGANISATION
MANAK NAGAR, LUCKNOW-226 011


SPECIFICATION FOR GUIDANCE FOR OPTIMIZED LOCOMOTIVE DRIVING
(GOLD)

1.0 OBJECTIVE:
The objective of this specification is to lay down the functional and hardware requirements
of an in-cab advice system that helps Loco Pilots of both freight & coaching trains to save
fuel and stay on time i.e. keep to the sectional running times as per the intended schedule.
Part A of this specification defines the functional requirements and part B defines the
broad hardware requirements.
1.1 Indian railways is installing a large number of locomotives with the following equipment:
1.1 DIALS: digital display screens provided on locomotive as per RDSO specification no:
MP.0.0400.10
1.2 REMMLOT: equipment for GPS/GPRS connectivity for transfer of locomotive data to a
remote land based server for diagnostics purpose. This is as per RDSO specification
no: MP.0.0402.04. (Rev0.05) Jan 12. All future procurement of REMMLOT shall be done
as per revised specification no.
1.3 Microprocessor: for locomotive controls per RDSO specification no. MP.0.2400.26
(Rev 0.06) March 12 for ALCO and specification no.MP.0.2400.43 (Rev0.04)
September 2011 for EMD locomotives.
1.4 Provision of GOLD on Locomotives also involves display screen, GPS/GPRS module
and a microprocessor. It is therefore likely that there may be duplication of such
equipment on locomotives by provision of GOLD.
1.5 This specification deals with installation of GOLD on locomotives that are already
equipped with equipment as defined in para-1.1 to 1.3 above or may get equipped at
some point in future. The tenderers shall therefore make themselves aware of DIALS,
REMMLOT and loco microprocessor. Integration of their offered system of GOLD with
these existing/ proposed hardware on the locomotive shall be their responsibility.
2.0 SYSTEM DESCRIPTION:
2.1 Brief Description of the System: GOLD shall be an in-cab advice system that shall
help Loco Pilots of both freight & coaching trains to save fuel and stay on time i.e. keep
to the sectional running times as per the intended schedule. GOLD shall use optimal
control theory to determine speed profiles that minimize fuel consumption subject to
completing the journey within the specified time. The recommended speed profile shall
be displayed on a screen in the cab of the locomotive along with additional advice about
track topography and train location that will assist the Loco Pilot to follow an energy-
efficient speed profile and stay on time. The system shall determine current location and
speed from an on-board GPS unit and continually update the displayed advice during the
journey, thereby ensuring that the advice is always optimized for the remaining journey
based on actual progress of the train from the recommended speed profile. Thus the in-
cab display shall always provide an optimal speed profile from the current position to the
next target location. This technology shall ensure that best driving practice becomes the
norm and hence consistently reduces fuel costs.



2
2.2 Aim of GOLD: The aim of GOLD shall not be to override Loco Pilots, but to provide them
with information that will help them drive more efficiently. GOLD may not take into
account signals or train-handling requirements. When it is not appropriate to follow the
ideal speed profile because of track conditions, restrictive speed signals or unexpected
speed restrictions, the Loco Pilot shall simply ignore the advice until it is appropriate to
follow the displayed speed profile. A document dealing with train handling is placed in the
annexure- A for guidance of the potential vendor. This document is only for guidance
and the firm shall rely entirely on its know- how and expertise to arrive at the optimum
driving solution to advise the driver.
2.3 Energy Savings: Energy savings shall result from the systems ability to anticipate the
upcoming topography i.e. increasing/decreasing gradients, horizontal curves and speed
limits while using the known performance characteristics of the train such as tractive
effort, weight, length, rolling resistance etc to calculate and communicate the optimal
driving profiles for any given journey.
2.4 Loco Pilot: At the beginning of a trip, the Loco Pilot shall specify information that is used
to calculate ideal speed profiles, including:
The number and types of locomotives
The type of train (used to determine which speed restrictions apply)
The number of and type of wagons / coaches.
The mass of the train
The maximum permissible speed of the train
The route and
Fuel balance at the start and end of journey and any additions in between for
diesel locos.
2.5 Data input: The above information may be selected from menus on the touch screen.
Alternatively, this information may be automatically downloaded from a central server.
Temporary speed restrictions shall be automatically uploaded to the on board processing
unit (OBPU) from a central server over a wireless data network.
2.5.1 The system shall be capable of computing and displaying several optimal profiles; each
of these optimal profiles shall have a different arrival time. The fastest profile shall have
the earliest arrival time, but shall use the most energy to complete the journey. Each of
the subsequent profiles shall use less energy than its predecessor, but shall take more
time. Destinations are key locations along a journey where the train has a specified
arrival time.
2.5.2 Destinations can be crossing loops where the train will pass or overtake another train,
key junctions, crew change locations, or terminals. Each time the Loco Pilot selects a
new destination, GOLD system shall have the facility to automatically adjust the optimal
driving strategy to ensure that the train arrives at its destination at the required time with
minimum use of energy by computing optimal driving profiles from the current location to
the destination.


2.6 Speed Profiles:



3
GOLD speed profiles shall save fuel by:
Cruising at speeds less than the speed limit, if time allows;
Coasting; and
Reducing the amount of braking, particularly at high speeds.
2.7 Display : During a journey, Loco Pilots shall glance at the display to check the progress
of the journey, and to see what control changes may be approaching. At the end of
each journey, GOLD shall upload a journey log to a central server using wireless
communications. The figure below shows a typical advice graph that shall be required
from a GOLD log for a specific journey. This is an indicative display screen and shall be
finalized after discussion. However, all successful tenderers shall have to design a
common screen so as to facilitate easy understanding by the locomotive drivers.


Figure 1 GOLD Main Display (Indicative)

The main GOLD display as shown on the screen at Figure 1 above shall be divided into three
areas:
2.7.1 Route Information: The bottom half of the display shall show track elevation, track
curvature, and trackside features such as level crossings, signals, kilometer posts and
crossing loops, for 6 km in front of the cab and 2 km behind the cab. The location of
the train shall be indicated by the white line superimposed on the elevation profile.
The vertical white lines shall indicate the front and rear of the train. Loco Pilots shall
find the route information useful because it shall show the location of the front and
rear of the train relative to hills, curves and speed restrictions, and because it shall
provide confirmation of the trains location.
2.7.2 Ideal Speed Profile: The part of the display immediately above the route information
shall show the ideal speed profile calculated by GOLD. The height of the thick line
shall indicate the ideal speed. The color of the line shall indicate how much power is
required to follow the ideal speed profile: green shall be full power, white coasting,



4
and red braking. The thin orange line above the ideal speed profile shall indicate the
track speed limit, including any temporary speed restrictions. The two white triangles
shall indicate the current speed of the train, as measured by the GPS unit. Whenever
possible, the Loco Pilot should drive such that the two triangles straddle the ideal
speed profile.
2.7.3 Destination: The top strip of the display shall show the current destination and the
estimated time of arrival. The various speed profiles generated shall be shown with
colored bar to indicate which of the possible profiles is being followed, from the least
efficient speed profile to the most efficient speed profile. It shall be possible for the
locomotive driver to select the destination of his journey on real time basis.
2.8 ON BOARD SYSTEM ARCHITECTURE
2.8.1 The GOLD System
In cases where locomotives are pre-equipped with a microprocessor, then the
GOLD software shall be loaded/integrated on to the same microprocessor. In
such case the GOLD system may pick up data from the loco microprocessor to
ascertain notch position, speed, brake application etc and display the same on
the GOLD screen.
Alternatively, a stand-alone system may also be offered that does not interface
with the existing microprocessor in case the onboard microprocessor is not
compatible with the offered GOLD system. It shall draw power from the loco
auxiliary power supply at 72 volts.
The base system shall consist of loco power supply providing power to a screen
and a separate processor including communications via GPRS/GSM/WLAN and
an integrated GPS receiver.

2.9 GOLD SYSTEM SCHEMATIC (CONCEPTUAL)

Figure 2: GOLD System Schematic (conceptual)




5

3.0 SCOPE OF SUPPLY

The purchaser may procure software and hardware modules as per requirement, ie in
case DIALS /REMMLOT are already available on the locomotive these need not be
procured. The OAU and the GPRS units have therefore been kept as optional and
procurement shall be done only if the requirement arises. However, the OBPU shall
necessarily be procured as a set along with software from the same vendor supplying the
software. Thus the nos. of OBPU procured shall be equal to the no. of software licenses
being procured and shall necessarily be procured from the vendor supplying software.
This is essential to ensure compatibility between the software and the hardware. OBPU is
discussed in para 3.5.2 of this document. Given under is a summary of the deliverables
along with further details classified according to mode of procurement:



Table -1

Item Responsibility for supply Mode of procurement
(3.1) Onboard advice
module
(3.1.2) TSR Entry
Module
(3.1.3) Reporting tool
(3.1.4) Time table
management software





Software
modules
(3.3) Application
design (advisory
system)



Shall be delivered by the
supplier of GOLD.


To be procured against
procurement tender of GOLD
(3.5.1) Onboard
advice unit (DIALS)*
(3.5.7) Onboard
antenna (REMLOTT)*
(3.5.5) Data entry
nodes


Not to be delivered by the
supplier of GOLD.



To be procured by railways
separately/use existing.
(3.5.2) OBPU
(3.5.3) Power supply
(3.5.1)Onboard advice
unit (Stand alone
screen)

Shall be delivered by the
supplier of GOLD.





Hardware
modules
(3.5.4) Land based
server
Shall be managed by the
supplier of GOLD

To be procured/managed against
procurement tender of GOLD

(3.5.6) Data up-linking Not to be delivered by the
supplier of GOLD.
Data up-linking between
REMLOTT and ground server
shall be part of REMLOTT
installation.
Up-linking between data
feeding nodes in shed and
ground server shall be borne
separately by the Railway.




Data
capture and
transfer
(3.6) GPS Route
mapping.
Shall be carried out by the
supplier of GOLD.
To be provisioned in procurement
tender of GOLD Shall be priced
separately in the tender.
To be procured from RDSO approved sources.




6
3.1 Software modules: It is intended to procure the software of GOLD on batches of
locomotives (as required) without having to pay license charges for each locomotive. The
tenderer shall quote for license for a minimum batch size of 50 locomotives. IR may place
order for a minimum order quantity for 50 locomotives or in batches thereof. The hardware
shall, however, be procured in a phased manner according to the implementation plan for
GOLD.

3.1.1 Onboard Advice module: This software module will be presented via the onboard
advice unit (OAU). The hardware of the OAU is detailed at para- 3.5.1 of this specification.
The software module for driving optimization resides on the onboard processing unit
(OBPU), that is in turn located on the locomotive. It downloads the required train, track and
timetable data from the land based server (via a suitable mobile network) and provides
driving profiles to the driver for optimum energy consumption without compromising on
arrival times. The driver shall interact with this module via the TFT/LCD screen (OAU). As
and when the new Loco Pilot logs on to the OAU, the previous journey log will be uploaded
to the central server via the mobile network Database
This shall be a relational database management system, such as Microsoft SQL Server or
Oracle database (or any other suitable database). This database shall hold the track data,
TSRs/ESRs, timetable data and journey logs. To the extent possible the track and other
data shall be stored in the onboard server so that the quantum of data to be transferred
between the ground based server and GOLD is minimised along with the cost of data
transfer.
3.1.2. TSR Entry Module
This shall be a browser-based application, which shall allow users to enter the TSR data
(data such as speed restrictions, that are liable to change frequently) into GOLD database.
The TSR data shall be converted to GOLD format and saved to the database. This TSR
data shall then be uploaded onto the Onboard Advice Unit/onboard processing unit
(OBPU) at the start of each journey. As a customization, the TSR entry process shall be
automated if the required data is available in electronic format. This software tool shall
reside in the land-based data feeding units located at various points.
3.1.3 Reporting Tool
This tool shall allow users to access the journey logs and generate / view reports of the
same from the central server. This tool shall reside in the land based nodes that are
used for analysis of journey data.
3.1.4 Timetable Management
GOLD shall require train, track and timetable data, including Temporary Speed
restrictions (TSRs), and the current journey information to provide advice to the
driver for energy savings. In order to keep the track data up-to-date, GOLD
shall check and upload track data, timetable data and the TSR data at the start
of each journey.
Maintaining the Timetable data for the GOLD system may be a significant task
due to the large volume of information. Similarly, maintaining the TSR data on a
daily basis, which changes from one day to the next, may also be a complex
and time-consuming activity especially when there may be several track routes
and when they may come from multiple sources in various forms. As such, the
timetable data and the TSR data shall be uploaded as part of the GOLD system,



7
using an automated and/or upload process. In addition, the system shall allow
users to view and edit this information as and when required, before being used
by the GOLD onboard Advice Units (OAUs) that shall be installed on trains.
Timetable Optimization Module: This module shall be used for optimizing
timetables that are available in the system. If current location of trains are
available, then this module shall be used to optimize timetables in real-time
during major delays disruptions (e.g. derailments, breaches etc) and optimized
timetable information shall be loaded onto the OAU. This module is optional and
may be priced separately.

3.1.4.1 Timetable Architecture Overview (Conceptual)
TSR Entry
Module
Reporting
Module
GOLD
OAU
Software
Module
Database:
Locomotives
Rolling Stock
Track Data
TSR
Timetables
Journey Logs
Reports
Input /
Output
External
GPS
Legend
Back Office System
Central Server
Optimised
Timetables
Timetables
Track Data
TSR
Journey Log
Mobile Network
Comms
External
TSR
File(s)
Timetable
File(s)
Timetable
Module
Timetable
Optimisati
on Module
To be decided:
Data Formats and transmission
methodology
Train
Configuration


Figure 3: GOLD Timetable Architecture Overview (conceptual overview)

3.2 Data requirement: The GOLD system shall need basic train, timetable information and
track data based upon which the optimum profiles shall be generated. Following data is
generally available and shall be made available by IR. In case some other information is
needed, the tenderer shall spell it out clearly in their offer and the same shall be
provided subject to availability with the purchaser. The data shall be in relational
database management system, such as Microsoft SQL Server or Oracle database
3.2.1 Timetable Data Requirements
Journey Header Data
Train ID or Head Code: unique identification of each journey within the timetable
Days of Operation: days of week on which the current journey is operated
Train and consist information; including type of rolling stock, locomotives etc.
Effective dates: start/end dates of the journey or the timetable
Journey Details



8
Locations traversed by the current journey: this is the order of locations traversed
by the current journey. This includes all stations and junctions on the current rail
network traversed by the journey.
Stopping mode at each location traversed by the journey, such as passing,
dwelling, etc.
Arrival and departure times at each location traversed by the journey.
3.2.2 TSR Data
The design should permit storage of as much track data on the onboard microprocessor
to minimise the cost of communication to the Railways.
TSR Start/End Location
The start and end locations shall be specified in terms of route kilometers. In this
case, the following details of the start and end locations shall be made available:
Start Track Segment
Start Km
End Track Segment
End Km
TSR Dates
Start and end dates of the TSRs shall be made available
TSR Speeds
TSR speeds for all types of trains shall be made available separately, e.g.: if the TSR
speeds differ between passenger trains and other, then each TSR speed shall be
available for each category.
Directionality
Whether the TSR is applicable for the direction Up, Down or Both
TSR Description (optional)
Other TSR details, such as Speed Restriction Number and Speed Restriction Year,
may be made available for record keeping purposes.
3.3 APPLICATION DESIGN (advisory system)
The Successful Software Developer shall provide an Advisory System which, once
installed and configured, shall provide real-time advice to the Loco Pilot in the cab
(power/hold/coast) that, when followed, shall allow progress of the train to be regulated to
give the lowest calculated energy consumption whilst achieving compliance with the
timetable. This advice shall have to be based on profiles for each route, but also
calculated in real-time based on current speed/location. Logged data of driving behavior
shall be sent to a central server for analysis and reporting. The system shall:
Upload base data to the central server.
Upload base data from the central server to the onboard processor
Upload display modifications from the central server to the onboard processor



9
Display real-time advice to Loco Pilots based on profile recommendations and on
their current locations / speed and next expected stop e.g. when to start coasting/
braking etc.
Log the driving behavior for each journey.
Automatically download journey logs from the onboard processor to the central
server.
Allow for analysis and reporting of that data.
Store and Manage timetables for passenger services and train running
information for freight services and be capable of editing that information and
uploading changes to the onboard processor
Manage temporary speed limits and emergency speed limits and upload these to
the on board processor

3.4 Software Solution Being Offered
Bidders shall specify technologies proposed for at least the following:
3.4.1 Solution Design Proposed
Describe the existing products/modules that will be deployed for this project and their
inter-relationships (diagrams maybe attached if necessary).
3.4.2 Change Management Methodology Proposed
Describe the problem escalation mechanism with name, designation and contact
details at each level up to the level of CEO
Proposed quality plan setting out methods and agencies controlling quality at
different stages of the project and a proposed inspection schedule shall be described
Commitment to provide warranty support as per the standard IRS conditions (24
months from date of fitment or 30 months from date of supply) at no additional
charge after acceptance of the system by the competent IR authority.
Commitment to provide post-warranty support for at least five years (An affirmative
response means a commitment to support the application if so desired by the IR, at
charges to be determined before expiry of the warranty period or at the time of
entering into the maintenance contract)
Confirmation of ownership of source code (An affirmative response confirms that all
source code customized / developed under this contract shall be the property of IR
as specified in this document)
3.4.3 SPECIFICATION REQUIREMENTS AND GAP ANALYSIS
A document on Gap Analysis of the software modules being offered for customization
as compared to the system requirements provided in this document. It shall specify the
extent to which the system requirements are:
Fulfilled by existing & proven software modules of the bidder
Needs customization (details shall be furnished)



10
Fresh development (bidder shall substantiate his capability to develop by way
of past proven developmental effort relating to railway fuel optimization
application)
This document shall also describe the specific modules that are part of the bidders
Software package that shall have to be deployed to meet the requirements of this
specification
3.5 Hardware modules: The hardware essentially comprises the following items:

OAU (On board advice unit, optional): 3.5.1
(a) In locomotives provided with DIALS; integration of GOLD with DIALS is
mandatory..

1) Integration with DIALS: in such case the GOLD system shall be integrated
with DIALS (complete functionality of DIALS shall be retained) against RDSO
specification no- MP.0.0400.10 and the screen of DIALS shall be used as the OAU for
GOLD. The specification of DIALS shall be purchased separately by the bidder.

2) At present some locomotives are equipped with DIALS conforming to revision
1 of the specification no. MP.0.0400.10. A document is placed at annexure B of this
specification that defines the basic integration protocol needed for integration with
DIALS.RDSO shall only act as a facilitator for integration of proposed GOLD with
existing DIALS and REMMLOT, the responsibility of perfect matching and working shall
remain with the vendor supplying the GOLD

3) In case DIALS is already available on the locomotive, the OAU modules shall
not be procured by the purchaser.

(b) In locos where there is no immediate plan for installing DIALS, a standalone
screen shall be provided.

1) Standalone display unit: in this case integration with DIALS
system/functionality of DIALS shall not be required. A stand-alone screen for
information display of GOLD shall be supplied by the tenderer. The screen shall
conform to the specification placed in part B of this specification. The testing of the
screen shall be as detailed in the specification. It is however, likely that these
locomotives may get equipped with DIALS at a later date. Therefore, integration with
DIALS shall have to be arranged by the successful tenderer within one year of fitment
of DIALS.

The purchaser shall decide the mix of locomotives to be equipped with GOLD
and procure systems to cover both type of locomotives as detailed above.

3.5.2 OBPU: Onboard processing unit. This shall be state of the art microprocessor capable
of processing and handling the required information. In locomotives that are already
equipped with microprocessor the OBPU shall be integrated with it and the onboard
software shall be loaded on this in this case the OAU shall be interfaced with the loco
control computer. Alternatively, a stand-alone system may also be offered that does not
interface with the existing microprocessor in case the onboard microprocessor is not
compatible with the offered GOLD system.



11
The OBPU shall be procured from the same sources as that for the GOLD software to
ensure compatibility between the two. It shall be procured as a set with the software for
every license of software procured.
3.5.3 Power Supply: Display Systems and OBPS shall draw power from the locomotive
auxiliary power that is at 72 volts/DC.

3.5.4. Land based central server: The successful bidder shall maintain the track and other
data needed for operation of GOLD in its own server or on server of any external
agency confirming to T1A-942, Tier-III compliant. A penalty clause shall be worked out
by the purchaser of GOLD for downtime of the server.

3.5.4 Land based nodes: Nodes for uploading / updating the TSR and Track Data shall be
located at the various control units of IR. The cost of data communication between
these nodes shall be borne by the user Railway.

3.5.6 Data up linking: Mobile Network connections/cost of data transfer between the
OBPUs and the land based server shall be borne by the purchaser as part of
REMLOTT installation. The cost of data unlinking between the data entry nodes and
the land based server shall also be borne by the user railway and not against the
tender of GOLD.

3.5.7 Onboard antenna (optional): This shall be needed for linking the OBPU to the land
based servers via the mobile network. The system shall be capable of communicating
through GSM / CDMA / WLAN networks depending upon availability at the location.
This module shall confirm to RDSO specification of REMMLOT no. MP.0.0402.04.
(Rev0.05) Jan 12. In case the target locomotives are already equipped with
REMMLOT this unit shall not be procured.

3.5.7.1 For the purpose of integration with the existing of DIALS and REMMLOT a document
providing details for integration is being attached in the specification. The document
gives details for the existing system. RDSO shall only act as a facilitator for integration
of proposed GOLD with existing DIALS and REMMLOT. The responsibility of perfect
matching and working shall, remain with the vendor supplying the GOLD.

3.5.7.2 All interconnecting cables, mounting angles, hardware etc shall also be supplied by
the successful bidder.

3.6 ROUTE DATA AND GPS MAPPING
Route data e.g. line of route, stopping points, permanent speed restrictions,
elevation, gradients, curvature etc shall be provided by the purchaser. Based on this
the successful bidder shall have to carry out the GPS mapping of the sections taken up
for GOLD implementation.
3.6.1 A general format for mapping is placed at annexure - C. The format shall be finalized
in consultation with the successful bidders. For the routes mapped by the successful
bidder the GPS co-ordinates shall be within an accuracy of +/- 10m.The accuracy of
the mapping shall have to be demonstrated by the successful bidder to IR.
3.6.2 The Route mapping work shall be priced separately and the bidder shall indicate the
cost per 100km for route mapping. The actual work to be carried out shall depend
upon the nos. of GOLD units procured/implemented and the sections on which the



12
locomotives intend to operate. Since the freight locomotives may travel over a very
wide network on IR, it is likely that very large area of the rail network may have to be
mapped by all the successful bidders
3.6.3 The firm shall declare the protocol/standard being employed for this mapping. The data
captured shall be property of Indian Railway and shared with the successful tender
under agreement of confidentiality.
3.6.4 The purchaser /Railway may award the work of mapping to a single successful bidder
or multiple bidders based upon deployment pattern of the GOLD over IR.


4.0 GENERAL REQUIREMENTS
Failure of GOLD system shall not compromise, nor in any way affect the
operational safety of the train. GOLD shall be universally suitable for all types of
sections of Indian Railways like single line, double line, twin single line, multiple
lines etc.
GOLD shall be able to work with distributed power mode/multiple loco operation
also.
Gold shall be suitable for both freight and coaching trains. It shall have suitable
train planning software so as to upload coaching train timetable on central server
to enable the system to save fuel while maintaining punctuality.
GOLD shall be suitable for all types of electric and diesel locomotives.
GOLD shall be capable of working in all types of electrified as well as non-
electrified territories.
GOLD shall be suitable for all train speeds, loads and length.
Journey logs of each GOLD unit shall be stored for a period of 45 days on the
central server. The information stored on the central server shall be available on
a controlled access basis to relevant supervisory/managerial personnel to review
the performance of individual Loco Pilots/sections etc. It shall be possible to
download all the events to a PC/ Laptop. Analysis & diagnostic software shall be
provided to analyze the events on PC/ Laptop. The relevant
supervisory/managerial personnel shall also be able to print reports of these
journey logs in user friendly and easily readable format.
It shall work on the locomotive power of 72 Volt DC
The System shall start up automatically when the locomotive power is on and
shall have security access via Loco Pilot ID.
The system shall have a comprehensive server side data base to manage track
and train data as well as timetable data, train running data and reporting
The system shall be configurable to the display advice if the train deviates from
the expected speed profile, or detects a GPS drift away from the track centerline.
Hence the system shall have route divergence capability.

4.1 Interfaces with other sub-systems: interface of GOLD is required with the following
subsystems existing on the locomotive:



13
Locomotive microprocessor; this interface is optional. Stand alone systems
can also be supplied.
REMMLOT; for GPS and GPRS connectivity and communication with land
based server.
DIALS: as OAU interface in locos equipped with DIALS (optional).

The firm must necessarily share all hardware and software details for interfacing/
integrating the OBPU and GOLD software with the REMMLOT and DIALS on the
locomotive. The specification of REMMLOT and DIALS may be refereed in this
respect. Apart from declaring such information in the tender, the firm shall also
furnish an unconditional declaration to provide all such information (for
interfacing/ integrating) GOLD (hardware/software) with REMMLOT and DIALS
as and when the need arises. To achieve this objective, a security deposit may be
retained by the tender committee for a minimum period of two years from award
of the contract.

5.0 CHANGES AND ENHANCEMENTS IN THE SCOPE OF WORK
If during the execution of the project it is found that IR wants changes in the Scope of
Work, then the Successful bidder and IR may renegotiate the contract upon mutual
agreement in writing subject to the tender not getting vitiated. In the absence of a
mutual agreement, the scope of the work shall be as detailed in this document.


6.0 VALIDATION OF THE OFFER:

1. The extent of fuel savings that can be effected on a particular route/ train depends also
upon the sectional profile i.e., gradients, curvatures, speed restrictions etc. Therefore
this document is not defining any threshold or qualifying limits of fuel savings in terms of
a predefined value.
2. Before selecting a system/systems it shall be tested in actual operation and the average
fuel consumption/savings over several runs shall be evaluated against established
values of a proven system (if any).
3. Bidder(s) whose offers are found to be technically suitable shall be called upon to make
available their product (at their own cost) for trials on nominated routes/ trains as
decided by the purchaser. The product shall be made available within 45 days of
intimation from IR. The unit shall also be undertaken for integration with REMMLOT and
DIALS (if required).
4. The trials shall essentially comprise of comparison of base line data with that obtained
with GOLD system. The trials shall be done in association with the short listed Bidder (s)
of GOLD. The exact modalities for trial and the trial scheme shall be finalized by IR in
consultation with the short listed Bidder(s) prior to commencement of such trials.
5. In case there is more than one shortlisted Bidder for such trials, the trials shall be
conducted on the same route, locomotive & type of trains for all the bidders. In such a
case comparative evaluation shall be carried out for the shortlisted systems.
6. The decision of IR in regard to the outcome of these trials shall be final.



14
7.0. QUALIFYING CRITERIA

The bidder should have proven design and software to offer complete system
capable of being used for both freight and coaching trains with a view to obtain
substantial fuel saving.
The bidder should also be able to demonstrate that the product has already been
proven out on a Railway network.
The bidder should produce documentary proof thereof along with the resultant fuel
savings achieved in % age terms.
The bidder must have in-house capabilities for developing software and hardware
modules in order to have quick attention to in-service problems.

8.0 DOCUMENTATION
Manuals & guides: Successful bidder shall provide manuals and guides (number to be
agreed at the appropriate stage) both in soft and hard copy format covering the following
aspects:
Driver setup and operation
Diagnostics/maintenance of software
Alteration and addition of any information
Administrator function and access
Report generation
Drivers operating instructions and trouble shooting handbook
Training manual for Loco Inspectors i.e. Trainers
Training manual for Loco Pilots
Installation manual
9.0 SCOPE FOR SOFTWARE ANNUAL TECHNICAL SUPPORT (ATS)
9.1 System Software
For the system software, installation, configuration & ATS charges for first year shall form
part of the Quotation. Annual Technical Support prices for the second through to the sixth
year to be quoted separately.
9.2 Application Software Annual Technical Support (ATS)
For the first year after commissioning, the software shall be under the developmental
support and warranty and the ATS shall commence thereafter. The scope of ATS is as
given below:
1. Delivery, installation, configuration, tuning and performance of the System and
Application Software shall be the responsibility of the Vendor.
2. Production and development environment shall be set up by successful bidder for all
releases and testing purposes.
3. The bidder shall enclose documentary evidence along with escalation matrix that they
have the necessary organizational infrastructure to provide support to IR for maintaining
system health and fine-tuning system performance.



15
4. For ATS, payment shall be released after satisfactory maintenance provided by the
vendor.
5. ATS shall cover free upgrades as and when due.
10.0 TRAINING
10.1 Scope of Training
The Software Developer shall arrange free of cost training to the personnel of
Indian Railways for 500 man days in India or 250 man days abroad (in case the
system is procured from overseas sources) to make them proficient in the
operation of GOLD system, including, but not limited to, upkeep of database,
generation of reports, trouble shooting, debugging of the system, providing
adequate guidance to enable them to train their subordinate staff in these
functions.
Training to nominated end users and core team members shall be organized in
suitable batches of appropriate duration in consultation with Indian Railways.
Training material and documentation for each course shall be provided to each
member.
Details of the training proposed to be provided shall be detailed & agreed upon
by the successful bidder within 45 days of the contract being signed.
11.0 SOFTWARE
11.1 Language
Software shall preferably be in a higher-level language. Software interface to the user
(Uploading, Calibration, Configuring, Data pack, Downloading, Decoding etc.) shall be
menu driven and user friendly.
11.2 Ownership of customizations/developments
For any software developed/customized for IR under this project, complete source code
including the enhancements developed as a part of this project in partnership with IR
shall be handed over to IR along with intermediate code and executable code.
The rights for any intellectual property created, as part of this project shall be shared
equally between the vendor and IR. Though in the normal course, IR may not modify the
software without notifying the vendor, it reserves the right to make any change in the
software at any stage without assigning any reason. The above applies to all software
developed or customized exclusively for IR. It however does not include any standard
software product loaded into the system.
All documentation shall similarly become the property of IR as soon as it is handed over
for scrutiny or acceptance. Such documentation shall include application software plans,
drawings, specification designs, reports, user manuals, system documents etc.
Notwithstanding any of the above, the Successful bidder shall indemnify IR against any
damages or liabilities arising out of infringement of any intellectual property right
whatsoever as a result of development, customization, installation or deployment of the
software on any hardware belonging to IR, at any stage of the project.



16
12.0 ROLE OF RAILWAY PERSONNEL
IR shall have the option of associating its personnel with each stage of the work. The
Successful bidder shall provide these personnel with all the necessary information and
facilities to carry out their functions. But the fact that IR personnel are associated with
the Successful bidders personnel in the contracted work shall not in any way reduce the
Successful bidders responsibilities under this contract. Final responsibility to satisfy
Railways of the satisfactory completion of the work shall rest with the Successful bidder.
13.0 TIME TABLES
Working time tables for coaching trains shall be provided by the purchaser. These shall
be in electronic format. The bidder shall have train planning software to enable the
timetable data to be stored on a central server and uploaded to each trains OBPU. The
offered software shall be capable of facilitating easy input of temporary/special train
timetables as and when required. The offered system shall be able to adhere to the
published timetable & at the same time save energy.
The system offered shall be capable of handling real time changes in the timetable.

14.0 IPR disclaimer pin pointing responsibility for violation if any on
supplier

14.1 Undertaking by equipment manufacturer
All the specifications issued by RDSO shall include a requirement of undertaking to be
signed by Vendors on INFRINGEMENT OF PATENT RIGHTS. The undertaking can be
as under;

Indian Railways shall not be responsible for infringement of patent rights arising due to
similarity in design, manufacturing process, use of similar components in the design &
development of this item and any other factor not mentioned herein which may cause
such a dispute. The entire responsibility to settle any such disputes/matters lies with the
manufacturer/ supplier. Details / design/documents given by them are not infringing any
IPR and they are responsible in absolute and full measure instead of railways for any
such violations. Data, specifications and other IP as generated out of interaction with
railways shall not be unilaterally used without the consent of RDSO and right of Railways
/ RDSO on such IP is acceptable to them.

14.2 Declaration of confidentiality of submitted documents by manufacturers
While submitting a new proposal/design, manufacturer must classify their documents
confidentiality declaration, such as;
This document and its contents are the property of M/s XYZ (Name of the vendor) or its
subsidiaries. This document contains confidential proprietary information. The
reproduction, distribution, utilization or the communication of this document or any part
thereof, without express authorization is strictly prohibited. Offenders will be held liable
for the payment of damages. Indian Railways/RDSO is granted right to use, copy and
distribute this document for the use of inspection, operation, maintenance and repair
etc.

-------------------------------------



17


SECTION B



1.0 This section deals with the hardware requirements of GOLD system. The hardware shall
be procured as per Table-1 given in part A of the specification. All hardware shall be
sources recommended by RDSO if applicable and /or from reputed suppliers. The
sources shall be declared by the bidders in the tender offer.

1.1 It is intended to procure the software in batches of 50 (as per para 3.1 of section A). The
hardware may, however, be procured in a phased manner according to the
implementation plan for GOLD. The hardware is detailed in para 2.0 below.
1.1.1 OBPU: shall necessarily be procured as a set along with software from the same vendor
supplying the software. Thus the OBPU shall necessarily be procured from the vendor
supplying software and in phases as per the implementation plan of Railway. This is
essential to ensure compatibility between the software and the hardware.
1.1.2 OAU and the GPS/GPRS units: these are optional and shall be procured only if the
target locos are not equipped with these equipments. REMLOTT and DIALS shall be
procured from RDSO approved/recommended sources only. The stand alone screen
may be procured from any source meeting the specification given below:

1.2 In case the locomotive is not equipped with loco control microprocessor or the existing
microprocessor is not compatible with the offered GOLD system, the GOLD unit shall be
a standalone system with minimal integration with the loco. It shall draw power from the
loco auxiliary power supply at 72 volts. The system is modular providing a fully
upgradeable system. The base system shall consist of loco power supply providing
power to the screen and separate processor including communications via mobile
network including an integrated GPS receiver.
1.3 The tenderers shall make themselves acquainted with the locomotives on which the
system is intended to be fitted. They shall submit the outline drawings of the offered
equipments that shall be evaluated by Railway for suitability of fitment on the locomotive.
Alterations if any shall have to be carried out by the shortlisted bidders.
1.4 The photographs given below are only indicative and the actual equipment offered may
differ.




18


2.0 The hardware shall essentially consist of the following items:
2.1 OBPU - On-Board Processing Unit (mandatory):
In locomotives that are already equipped with microprocessor the OBPU shall be
integrated with it and the onboard software shall be loaded on the OBPU. Alternatively, a
stand-alone system may also be offered that does not interface with the existing
microprocessor in case the onboard microprocessor is not compatible with the offered
GOLD system..
The On Board Processing Unit shall load the optimal profile data in the Display (OAU).
The OBPU shall have a state of the art 32 bit processor with high computational power
to process all the data analysis requirements
The OBPU shall continuously monitor the current speed profile and estimate the delay or
advancement of the time taken by the current profile.
The OBPU shall auto-reload or provide a new optimal profile in case of a
delay/advancement in the schedule.
The OBPU shall be capable to simulate a new optimized profile on board as and when
required.
The OBPU shall be mounted at a suitable location on the locomotive and shall be
connected to Oahus
The OBPU shall update speed advice via GPS receiver using standard NEMA protocols
The firm must necessarily share all hardware details and software interface for
integrating the OBPU and GOLD software with the REMMLOT and DIALS on the
locomotive.
2.2 OAU- on-board advice unit (optional); please refer to clause3.5.1 of this
specification (section-A)
Shall be procured in case it is not already available on the target locomotive.
2 nos. industrial grade LCD/TFT screens capable of day/night visibility.
Take input from the OBPU.



19
Be of rugged design and suitable for railway applications.
Be the key interface between the GOLD system and the Loco pilot.
Show the optimal speed profile and current speed
Show the train position including the start and the end of the train
Show the optimal speed profile as well as the control mode power, speed holding,
coasting and braking (slow) and shall do this on a colored graph that allows loco pilot to
make the decision about throttle notch and braking.
Give a clear indication for coasting, braking and powering
Show the current time, target journey time (ETA).
Indicate gradients, speed limits including TSRs and curves.
Have a provision to select the train route via the Train ID.
Be mounted on the control desks of the locomotive in both long & short hood
configuration leading position.
Have appropriate background and dimming features so as not to have glaring effect for
the loco pilot, both in the night & day.
The Loco Pilot may use the destination button to bring up a menu of alternative
destinations. The Loco Pilot may also use the "Earlier" and "Later" touch-screen buttons
to select a faster and less efficient profile with an earlier arrival time or a slower and more
efficient speed profile with a later arrival time. The estimated time of arrival shall be
updated accordingly.
Have a delay attribution screen that shall be automatically invoked in the event of an
unscheduled stop and shall allow the loco pilot to enter the cause of the delay from a list
and these delays shall be logged.
At the end of the trip, the loco pilot shall be able to enter fuel information and shall be
able to view a report on the journey and energy efficiency.
The final screen display shall be finalized in consultation with the successful bidder.
The stand alone screen shall comply to the specification as given under:

LCD Screen

The following specifications for the LCD screen to be used on the system are provided as
guidelines for selection of display. The manufacturer shall get the display selection approved
from RDSO before first time use on the locomotive.










Parameter Recommended value



20
(or better)
Size 10.4
Aspect Ratio 4:3
Resolution 800 X 600
Type of LCD ST-NLT (sunlight
readable)
Pixel Pitch 0.264x0.264mm
Response time 18 ms
Brightness 800 cd/m2
Backlight LED Backlight
Colour 16777216
Viewing angle - Horizontal Horizontal right side
80 (typ.) left side 80
(typ.)
Viewing angle - Vertical Vertical upside 80
(typ.), down side 80
(typ.)
Contrast ratio 900:1
Operating temperature
(as per AAR S-5702 and
RDSO spec)
-30 to +80 C


Table 2: LCD screen hardware specifications

This screen shall be of suitable design permitting easy reading during daytime and nighttime
and the screen outer surface shall be glare free.

2.2.1 Screen protection

The LCD screen shall be suitably protected from impacts and scratches likely to occur in usual
operations. Corning Gorilla Glass is desirable for use on the outer layer for protection.
The equipment manufacturer shall get the screen selection and protection features approved by
RDSO before use on the locomotive.

2.2.2 Luminance control for LCD panel

The LCD panel shall use LED backlights with inverter based control. It shall be possible to
control the luminance of the LED backlights using keys on the front panel, application software
and also through an automatic ambient light sensor. Option for switching on / off the automatic
luminance control shall be provided.

2.2.3 Keypads

The equipment shall have keypads for management and data-entry. All keypads shall be of
rugged design suitable for use on locomotives.





21

2.2.4 Dedicated function keys

The display panel shall have dedicated keys for the following:

Switching on / off



Adjusting display brightness
Cursor control up/down/left/right / cancel / enter
Any other key as required by the equipment manufacturer

The design of the key location and function shall be approved by RDSO during type test.

2.2.5 Communication Interfaces

2.3 Power Supply
Display Systems and OBPS shall work with the locomotive auxiliary power that is at 70+-
2 volts/DC.
2.4 GPS/GPRS (optional):

Shall be procured in case it is not already available on the target locomotive.
Shall confirm to RDSO specification no MP.0.0402.04. (Rev0.05) Jan 12 for
REMMLOT.
2.4.1 GPS antenna along with its cable of sufficient length shall be provided with each unit.
The antenna shall be fixed on loco body outside. The mounting shall be strong
enough to keep the antenna fixing intact even under vibrations experienced by a
running locomotive. The length of the antenna cable shall be sufficient to connect
between antenna & GOLD unit kept on the cab counter.
2.4.2 System shall determine the correctness & quality of the GPS signal received and in
case quality of signal is not considered adequate to correctly identify its location, the
same shall be indicated on the LCD display.
2.5 LAND BASED HARDWARE:
2.5.1 MAIN SERVER: The successful bidder shall maintain the track and other data
needed for operation of GOLD in its own server or on server of any external agency
conforming to T1A-942, Tier-III compliant. A penalty clause shall be worked out by the
purchaser of GOLD for downtime of the server.
2.5.2 DATA ENTRY NODES: The hardware equipment required at the user end i.e. Zonal
headquarters, divisional headquarters, diesel sheds, and lobbies shall be clearly defined
by the bidder and procurement shall be the responsibility of the respective IR unit. The
requirement of this hardware shall essentially depend upon the data entry and review
scheme finalized by IR/purchaser.

2.6 An indicative server utility and specification is given below for reference (land
based main server):
The hardware proposed by the bidder shall support fast/acceptable response times even
at very high concurrent user loads where Concurrent users may be around 50 at a time in



22
the worst condition. Vendor shall describe the proposed architecture for the solution. It
shall have:
Reference for having demonstrated these technologies in actual production
environment.
Performance, High Availability and Scalability:
Along with scalability, performance and high availability, security shall also be a
design element for dealing with data transfers using common infrastructure.
Security entails reliable authentication and robust end-to-end confidentiality.
A comprehensive, fully documented disaster recovery and business continuity
plan shall be indicated; all costs shall be included and separately indicated.
Application Software/Hardware shall have:
Built in support for maintaining the client state between successive client
calls.
Many options and algorithms for load balancing amongst servers.
Capability of clustering of Application Servers both vertical as well as
horizontal.
Capability of clustering Application Servers running on different operating
systems as platform. Essentially allow for Mixed Clusters.
Reference for having demonstrated these technologies in actual
production environment.
Support for hardware load balancers.
Ability to pull or push data and import /export to Excel, MS Access and
Oracle.
Common Metadata
Consistent User Interface
Seamless Navigation
OS independent
Seamless scalability of the system
The methodology used for the sizing of hardware shall be clearly defined
and shared with IR.
If client machines need a software installation, then mode of maintenance
(central maintenance) shall be available for up gradation/downloading of
the software to client machines.
The out of the shelf system software shall be standard Industry products
and working at enterprise level and shall have strong market presence.
There are a variety of users who may have different types of requirements
and options. There shall be role-based security to define policies based
on Indian Railways structure and roles so that any access policy can be
applied to a whole group of users through their association with a
particular role participating in the rule:



23
Around 800 persons at HQ/Zone/Division Level; these persons shall be able to view and
alter/input data through different levels of password protection.
Report level Users-The users shall not be able to update any data but have the
permissions to view all the reports.
Issue tracking system shall be a part of the solution being offered.
Standard Case Tools shall be utilized for complete life cycle of the project.
Logging/Tracking: The application shall provide transaction logs and audit trails by
date time and user ID for all tasks covered within it.
The solution shall be built preferably using open standard like SOAP, XML, WEB
services, XSL, XSLT etc.
Quality Assurance processes followed for full life cycle of software development
shall be indicated clearly and the detailed test plans for specific requirements of IR
shall also be given.
2.7 Data entry nodes: These shall be located at the various control/operating units of IR.
These shall be of a simple PC configuration that is already available in IR
control/operating units. Their requirements shall be estimated by the purchaser depending
upon the phased implementation plans.

2.8 Data up linking: all requisite hardware/equipment such as internet modem, broadband,
internet service provider etc for up-linking of remote data entry nodes with the central
server shall be identified by purchaser and procured as per implementation phase of
GOLD.
2.9 Hardware OEM shall be of world repute for the offered category of servers. They shall
have presence in the international server market for at least four calendar years, including
the current year. Once the specifications are agreed upon, the procurement of the NODES
is the responsibility of IR, who may procure it separately or procure it along with the
software portion (part A).


3.0 PERFORMANCE & ENVIRONMENTAL REQUIREMENTS

3.1 The OBPS and the OAU shall conform to the following test parameters (as applicable)
detailed in para 3.0 through para 5.0.

3.2 The unit shall meet the requirements of RDSO specification no. ELRS/SPEC/SI/0015/ Rev
1-October 2001 for Reliability of Assurance specification for Electronic components for
use in rolling stocks.

3.3 The climatic and environmental conditions prevailing in India are the following. The unit
shall be designed to work satisfactorily in these conditions:

Atmospheric temperature (i) Maximum temperature of metallic surface under
the sun: 75 C.
(ii) Minimum temperature: -10C (Also snow fall in
certain areas during winter season.
Humidity 100% saturation during rainy season.
Reference site conditions (i) Ambient temperature: 50 C
(ii) Humidity: 100%
(iii) Altitude: 1776 m above mean sea level.



24
Rainfall Very heavy in certain areas.
Atmospheric conditions Extremely dusty and desert terrain in certain areas. The
dust content in air may reach a high value of 1.6 mg /
m. In many iron ore and coal mine areas, the dust
concentration is very high affecting the filter & air
ventilation system.
Coastal area Humid & salt laden atmosphere with maximum pH value
of 8.5, sulphate of 7 mg per liter, maximum concentration
of chlorine 6 mg per liters and maximum conductivity of
130 micro Siemens/cm
Vibration The equipment, system and their mounting arrangement
shall be designed to withstand satisfactorily the vibration
and shocks encountered in service as specified in IEC
61373.
Wind speed High wind speed in certain areas, with wind pressure
reaching 150 kg/m
3
.

4.0 ACCEPTANCE TEST

Type and routine test schemes shall be prepared in accordance with the relevant
IEC/UIC/IS/AAR specifications and furnished to RDSO for approval. Prototype test shall
be conducted on the basis of the approved type test scheme in the presence of the RDSO
representative.

The inspection and acceptance norms shall be finalized mutually depending upon the type
and routine test requirement otherwise frozen. The acceptance norms proposed shall,
however, be submitted along with the offer by the supplier.

A-1. Type and Routine Test

The System shall be tested for functional tests and the test programme shall be finalized
at design approval stage between the firm and RDSO.

A-2. Following tests shall be carried out on the prototype unit as per relevant IEC specification
or mutually agreed upon test program. Manufacturer shall bear the expenses of the tests.

A-3 The type tests shall be carried out in the premises of the manufacturer of the systems by
RDSO.


SL
NO
TEST CLAUSE TYPE
ROUTINE
1. Visual inspection

2. Tolerance & Dimension
As per the Equipment
Drawings

3. Cooling IEC 60571 clause 10.2.3





25
4. Insulation Resistance

5. Di Electric
As per Clause-11(b) this
spec.

6. Vibration and shock IEC 60571 clause 10.2.11


7. Performance test on test
jig


8. Voltage surge IEC 60571.1 clause
10.2.6.2



9. Electrostatic Discharge
test
IEC 60571.1 clause
10.2.6.4


test
C
attached Annexure 1
finalized during design
approval state


10. Transient susceptibility IEC 60571.1 clause 10.2.7

11. Radio interference test IEC 60571.1 clause 10.2.8

12. Salt mist test IEC 60571.1 clause 10.2.10

13. Damp heat IEC 60571.1 clause 10.2.5

14. Dry heat up to 70 degree IEC 60571.1 clause 10.2.4

15. Burn in As per Burn-in cycle

16. Functional Test As per test program to be


he following clarifications are issued on the tests above.
The object of visual inspection is to
T

4.1 Visual inspection of Tolerance & Dimension
check that the equipment is free from defects and the equipment is as per approved
drawing. Bill of materials shall be submitted. The make, rating of equipments
subassemblies shall be checked with the details as per approved design. If a change is
needed in make or rating of important equipments, sub-assemblies, it shall be
intimated and shall have approval of RDSO. The equipment with modified



26
subassemblies shall be given separate revision number. All the important dimensions
shall be measured and shall be in permissible tolerance.

.2 Insulation resistance and Dielectric test The insulation resistance with 500 Volt

4.3 Burn in test The cards used on the equipment shall be subjected to burn in as per

.0 VALIDATION TEST
Validation tests like wiring integrity and installation checks, Hi-pot, insulation resistance and
6.0 HARDWARE DETAILS:
The successful tenderer shall provide detailed description of proposed solution covering
7.0 SCOPE OF WARRANTY/AMC OF HARDWARE
4
megger shall not be less than 100 M ohms at 70% relative humidity for all the circuits.
The dielectric test shall be carried out after earthing special cards if necessary before
applying Dielectric voltage. The dielectric test shall be carried out at a test voltage of
1.5 kV rms for 60 secs. The leakage current shall be less than 5 mA.
the temperature cycle in Annexure 1. The cards shall be kept energized during the
test. Functional test of each card shall be carried out after the burn in test. This shall
be part of internal test by manufacturer, whose results shall be submitted during
routine test.
5

self tests, complete performance establishment, load box examination, parasitic load
management verification, track test etc. shall be carried out on the load box at any
nominated place mentioned by IR to establish the performance capability and integration of
the microprocessor system with other locomotive systems.
the architectural details and component-based design.
1. The bidder shall provide warranty in respect of the hardware for 1 years included
in the contract value and quote separately for AMC charges for the second
through to sixth year. These AMC charges may not be considered for evaluation
of the commercial bid.
Delivery, transportation 2. to site, commissioning and installation of Hardware shall
be the responsibility of the bidder.
Total System Integration (e.g. RDB 3. MS along with Active-Active installation) shall
be the responsibility of the bidder.
Bidders shall disclose as to how 4. they propose to provide onsite support for
maintaining system health and fine-tuning system performance.
Documentary evidence for back-to-back agreement with the 5. OEM to provide
support including availability of spares and software upgrades for 5 more years
from date of expiry of warranty is required to be attached along with the offer.
All licenses supplied shall be unlimited (no expiration with time). 6.
7. The bidder shall ensure through documentary proof from the OEM that RDBMS
shall be released in future on the machine supplied by him for a period of at least
six years from the date of installation.
The vendor shall provide sufficient 8. documentary evidence that the offered
environment (i.e. Hardware platform, OS, RDBMS, and Active-Active solution
together) has been successfully tested under the Lab conditions.



27
9. OEM shall certify the binary compatibility between the Production Servers and
Development/Offline Servers offered.
During the warranty period the vendor shall maintain the system in 10. good working
order. The service shall consist of preventive and corrective maintenance and
shall include:
I. Carrying out of all necessary repairs and replacements of parts without any
additional cost.
II. Shall also include supply and installation of patches, upgrades and tuning
of the operating system.
The vendor sha III. ll have a written commitment from the OEM to provide
onsite support in case required.
Maintenance coverage sh IV. all be on site all working days during day time (8
am to 8 pm) and at least 99.5% (or more) uptime.
The preventive maintenance sha V. ll be carried out at least once a month. The
preventive maintenance schedule shall not affect the online operations. If
the preventive maintenance brings application to halt, then the preventive
maintenance time shall also be included in the down time.
Bidder/server OEM shall have to maintain their own inventory of spares so
as to give fast and efficient service.
The engineer of bidder/ server OEM shall reach the site w
VI.
VII. ithin 6 hours. In
the event of a part failure, i.e. CPU/memory card etc the replacement shall
be installed within 24 hrs.
VIII. The bidder shall provide the contact number i.e., home address, residential
phone number, mobile phone number etc. of the engineers, Project
Managers, Regional Managers and Country Managers of server OEM.
IX. The server OEM support provided shall be of the highest level and the
same shall be very clearly mentioned in detail along with complete
escalation mechanism in case of a failure.
X. The system shall be treated as down if there is disruption of services due to
system failure at a given site or location.
For the purposes of calculating the down tim XI. e, the starting time shall be the
lodging of the complaint.
In case of down time beyond 99.5% uptim XII. e, both during warranty and post
warranty AMC shall attract the penalty clause, a cash penalty of Rs. 2000/-
per hour or part thereof shall be levied.
XIII. In case the problem is not resolved within the time slot allowed by
Railways, the next planned downtime shall also be added in the down time
for charging of penalty.





28
ANNEXURE - A

TRAIN HANDLING TECHNIQUE

This train handling document outlines the preferred method for handling of goods /
passenger trains so as to maximise safety, minimise components damage and service
disruptions.

For safe and smooth operation of train the drivers should know and observe the
following aspects adopted in simulator for practicing better driving techniques.

1. Driving Rules
2. Train Management
3. Brake management
4. Coupler forces i.e Draft, Buff force
5. Fuel Conservation
6. Travel Time
7. Brake Wear

1. DRIVING RULES

The driver should observe not to exceed maximum permissible speed.

2. TRAIN MANAGEMENT RULES

a. Maintain 5 sec time gap between notch up.
b. Avoid wheel slip during staring and acceleration.
c. Maintain 10 sec dwell time between dynamic to power change over.
d. Draft and buff force in train should be maintained up to 70 tons for smooth
operation.
e. Broken train/train parting occurs at more than 170 tons of Draft force.
f. Derailed train occurs at more than 170 tons of Buff force.



1
3. BRAKE MAMANGEEMNT RULES

FAULT CAUSE REQUIRED DRIVER ACTION
Brake pipe pressure low B.P. dropped more than 1.5
kg/cm
B.P. not to drop more than 1.5
kg/cm at any occasion except
emergency.
Heavy application i) B.P. dropped more than 1.5
kg/cm at speed more than 25
Km/h within 5 sec.
B.P. not to drop more than 0.7
kg/cm within 5 sec when the
train speed is more than 25
km/h
Using Air Brake without
dynamic
Brake pipe dropped more than
0.7 kg/cm when dynamic
braking grid current is less than
100 Amps and train speed more
than 5 km/h
Do not keep A9 dropped more
than 0.7 kg/cm when grid
current is less than 100 Amps at
more than 5 km/h speed.
Power Braking B.P. dropped more than 0.7
kg/cm in notch 4
th
or greater
Not to apply brake more than
0.7 kg/cm when train is in 4
th

notch power or more.
Applied brakes too fast B.P. dropped more than 0.5
kg/cm without holding for 20
secs.
Apply A9 to minimum reduction,
hold for 20 secs and then drop
further.
Running release A9 released at a speed between
5 to 15 km/h when B.P. dropped
more than 0.5 kg/cm.
Do not released A9 from service
application at speed between 5
to 15 km/h
Short brake application i) A-9 release from less than 0.6
kg/cm application or
ii) A-9 release within 60 secs
from application.
Apply service application and
hold for minimum 60 secs
before release.
Cyclic braking Repeated application of Auto
brake above 0.7 kg/cm within
50 secs of release.
Do not re- apply service
application within 50 secs of A-9
brake release.















2
TRAIN HANDLING PROCEDURE
(Starting, Negotiating & stopping the train)

1. TRAIN ON A LEVEL SECTION:



Starting Procedure

I. Keep all brakes in released condition (If train has been stopped in slack
stretched method)
II. Open the throttle to position 1 (if train was stopped with slack bunched) and
simultaneously begin to release SA-9.
III. Pause for a minimum period of 5 sec and as the load meter starts dropping
open 2
nd
notch.
IV. In this manner notch up to 4
th
notch and sec train should start moving, if not
closed throttle and check for cause of trains non movement.
V. If train starts moving and is in stretched conditions advanced throttle as
required.
VI. Accelerate rapidly (avoiding wheel slip) and achieve booked speed keeping
8
th
notch.

CAUTION

When switching on to higher notches i.e. from 5
th
to 6
th
and onwards let the train
attain speed at least 10km/h. Apply 6
th
to 7
th
notch at 12 km/h speed and 7
th
to 8
th
notch at
15 km/h otherwise wheel slip may be experienced.

Negotiation

I. After achieving booked speed, reduce notch to 6
th
or 7
th
as required to
maintain the booked speed.
II. If notch setting can not maintain booked speed, increase /decrease notch as
required.
III. Avoid too much frequent notch changing as this develops slack coupler in the
train.


3
Slowing
I. Well in advance of point of slowing down, start notching down.
II. Ease throttle one notch at a time and bring throttle to idle.
III. Allow train slack to adjust naturally.
IV. Engage dynamic brake (as per procedure) in advance of slowing down point.
V. Observe speed restriction by dynamic brake and auto brake if required.
VI. Release dynamic brake as the limitation indicator approached.
VII. Maintain at least 10 sec gap between dynamic and further powering up.

Stopping
I. At a sufficient distance in advance of point of stopping, ease the throttle one
notch at a time for the slack to adjust to a bunched condition.
II. Apply dynamic brake (as per procedure) at a sufficient distance in advance
keeping in view the load and speed of the train.
III. Apply A-9 to minimum reduction (Keep loco brake release)
IV. After the automatic brake becomes effective through out the train (after 20sec
approx.) make a further application 0.2 kg/cm or more as required.
V. When the speed has reduced sufficiently so that dynamic brake effect fades
(below 5km/h), bring selector to B position & apply SA9 then finally release
dynamic so that train would stop in bunched condition. This will help in
smooth starting of the train.
VI. As the train comes to stop apply loco brake.

2. ASCENDING GRADE :

Ascending Grade - Steeper than 1 in 100


Grades steeper than 1 in 100 (1%) is defined as heavy ascending grade.

Starting Procedure
Assuming train brakes applied:
I. Use minimum power : put notch 1 , release SA-9
II. Start one wagon at a time : release A-9, increase notch 2
4
III. Wheel slip: For wheel slip reduce notch.
IV. Train wont move: If train does not move at notch 4 reduce throttle to IDLE.
Assuming Loco brake applied :
I. Move throttle to notch 1 , note LA
II. Gradually reduce loco brake cylinder pressure , advance notch 2.
III. Allow loco & entire train to move
IV. Fully release SA9

NOTE: Avoid stall burn to T/M commutators or rail burn from wheel slip.
Negotiation
I. Keep 4
th
or 5
th
notch on level track to maintain speed.
II. Before arriving gradient, notch up to 8
th
notch at least 1.5 km ahead of the
foot of the gradient.
III. Maintain 8
th
notch up to crest of upgrade.
IV. Avoid wheel slip, use sand
V. Reduce throttle to 4
th
or 5
th
notch till of the entire train comes on level track.
VI. Maintain allowable speed by changing notch as required.
Stopping
I. Reduce the throttle at sufficient distance in advance of the stopping point one
notch at a time pausing between each throttle reduction to allow speed to
reduce naturally due to the grade such that a slack stretched conditions is
maintained.
II. After the grade stalls the train, apply SA9 fully and then bring the throttle to
idle.

3. DESCENDING GRADE:

Descending Grade - Steeper than 1 in 100


Starting Procedure :
I. Release SA9, allow train to slowly move forward until entire train is moving.
II. Use dynamic to retard the speed.

5
CAUTION :
I. Use only sufficient B.C. pressure to control speed and avoid wheel skidding.
II. Avoid train separation: Train slack is bunched during stopping and locomotive
will move some distance before rear end moves at the time of starting. The
train speed forward portion of train will increase rapidly and train may be
separated.
Negotiation
I. Reduce throttle to notch 3
rd
of 4
th
after passing half of train in the down
gradient.
II. Close throttle gradually when 3/4
th
of train has moved to down grade.
III. Watch speed of the train with respect to grade and distance to be covered.
IV. Check the speed by means of dynamic brake instead of Air/Vacuum brakes
in descending gradient.
V. Apply Air/vacuum brake if required.
VI. Notch up again at the end of down grade and obtain maximum speed by
keeping 8
th
notch.

Stopping
I. Apply dynamic (as per procedure) so that the slack gets bunched.
II. Once the slack is bunched at a sufficient distance before of the stopping
point, apply A9 to minimum reduction to ensure stopping at the desired point.
III. Additional brake pipe reduction of 0.2 kg/cm or more should be made as
required to reduce the speed. All along loco brakes should be kept in
released condition.
IV. When the speed comes below 20 km/h, additional brake pipe reduction may
be made.
V. Just after the speed comes to 5 km/h release A9, apply SA9 then start
releasing dynamic brake to avoid locomotive from running out.








6
4. UNDULATING GRADE

Reduce Notch
Increasing Notch


Undulating Grade is defined as a track profile with the grade changing so often that average
train passing over the track has some vehicle on three or more alternately ascending and
descending grades

Starting Procedure
I. Apply SA-9 , put throttle in notch 1, observe amperage increase.
II. Gradually release SA-9 until locomotive moves.
III. Advance throttle to notch 2.
IV. Observe load meter drop and advance further notches.
Negotiation:
I. Manipulate throttle without speed reduction at ascending grade
II. Reduce power when locomotive begins at descending grade.

Important Steps
I. Reduce power on approach to descending part of undulating grade.
II. Concentrate on rear end location of train to avoid rear end running in.
III. Increase notch at approach to ascending grade.
IV. Decrease power at approach to descending grade.
V. Maintain uniform speed through section.
Negotiation
On undulating grade train slack generates high drawbar forces. Skilful operation
reduces severity of slack changes to tolerate limit.

Throttle manipulation
I. As locomotive approaches on up grade, increase power (just enough, without
speed reduction).
7
II. As locomotive begins to descent, gradually reduce power (to maintain uniform
speed).
Stopping
In undulating grade stopping procedure should be followed as per ascending or
descending grade, where the train has to stop after running.

5. CRESTING GARDE:


Front of Ascending, Grade Rear on Level
Front of Descending Grade,
Rear on Ascending Grade
Front of Level, Rear on Descending Grade

Cresting grade is defined as a long ascending grade, which changes to a long descending
grade, (usually 1:75 or greater).
Starting Procedure:
Same procedure for ascending grade (Clause 2)
CAUTION
I. The load meter should be monitored constantly and the throttle should be
advanced only after the amperage falls to a moderate level.
II. Take Precaution for wheel slip & stall burn.

Negotiation
I. Changing of Slack Condition: The train slack is required to change from a
stretched condition (power mode) while ascending or approaching to crest to a
bunched condition (braking mode) or while on the descending portion.
II. Road Knowledge : The driver must be aware of the characteristics of terrain for
adequate braking on the descending grade following the summit.
8
III. Maintain Constant Speed: As locomotive reaches the crest of grade, the driver
should attempt to maintain speed by reducing throttle one or two position to
relieve stress on couplers at the crest.
IV. Use dynamic brake after a crest: If falling down grade is long steep, the
dynamic brake should be engaged after 3/4
th
of train has crested over the
summit to control speed and gradually bunch the train.
V. Balancing a Cresting grade: If the grade following the summit is a light
descending grade, throttle manipulating may be done to control speed and train
slack movement.

Stopping
I. As the locomotive crests the grade, the throttle is to be gradually reduced.
II. Apply minimum reduction at a sufficient distance then advance of stopping point.
Keep loco brake in released condition.
III. Make further brake pipe reduction to 0.2 kg/cm as needed and continue
reducing the throttle (Loco brake to be in released condition).
IV. When the stopping point is further nearing apply up to 1.4 kg/cm Brake pipe
pressure as required.
V. As the train is coming to a stop at the point of stop, apply SA9 and then release
A9.

6. SAG OR DIP GRADE:


Sag or dip grade is defined as a descending grade followed by an ascending grade, the
combination of which is sufficient to result in significantly greater slack adjustment than in
most other territories. Train operating through a sag or dip have natural tendency for the
head end to decelerate when entering a level or ascending grade while the rear portion of
the train is still on the descending grade resulting in a run-in of the slack

Starting Procedures:
I. Open throttle to notch 1, note amperage increase in LA.
II. Release SA9.
III. Advance throttle to notch 2 , note LA reading.
9
IV. When train is stretched and moves increase throttle slowly as required.
Throttle Advance
Load meter provides the best guide for throttle handling during acceleration. As soon
as increased power is absorbed, LA moves to the left, then throttle should be advanced. For
rapid acceleration without wheel slipping advance one notch at each time the load indicator
needle moves back.
Negotiation
To control slack, the train speed must be allowed to reduce before train moves into
sag or dip.
Normally dynamic brake is not allowed , since the grade are not long and there is
inadequate time to SET UP, APPLY and RELEASE dynamic brake.
So dynamic brake should not be used for freight trains and must not be used for
passenger trains when traversing sag or dip grade.
Stopping on Sag or Dip:
I. In advance of the Sag or Dip, apply dynamic brake and allow the slack to be
bunched.
II. As the train approaches the Dip , A9 to be minimum reduction (Loco brake to
be in released)
III. As the brakes get effective through out the train, apply A9 further up to 1.4
kg/cm
IV. As the speed is reduced below 5 km/h release A9
V. Apply SA9.
VI. Release dynamic
This method is to be adopted when the train is to be stopped on the descending part of the
Dip. If it is to be stopped on ascending part, then adopt the same technique as in ascending
grade.

SOME USEFUL TIPS

A. To maintain travel time :
I. Come on 8
th
notch as soon as possible without experiencing wheel slip or
Notch changed too fast.
II. Cautions driving should be observed by dynamic brake, A9 to avoid as far as
possible.
III. Try to run at booked speed and if required at maximum speed also.

10
B. Brake Wear:
I. Before starting ensure that all brakes are in released condition.
II. Observe all cautions driving by the help of dynamic brake as far as possible
III. For stopping use dynamic brake to check the speed and then apply A-9 as
per procedure.
IV. Keep watch on Air flow indicator movable needle it should be in alignment
with fixed Red needle.
V. Make minimum use of A-9 as far as possible.
VI. Avoid over controlling.

C. Coupler Damage:
I. Use dynamic as per procedure i.e. avoid sudden application and released of
dynamic
II. Throttle to be increased or decreased as per procedure, avoid double notching
and sudden closing of throttle.
III. Brake application to be done as per procedure.
IV. Avoid Heavy application of Auto Brake.
V. Avoid Running release.
VI. For starting, negotiating, Slowing down & stopping adopt the driving technique
prescribed for the respective terrain.
VII. Avoid slack stretch & try to minimise Draft & Buff force.

D. Fuel Economy:
I. Before starting ensure that all brakes are in released condition.
II. Try to come on 8
th
notch as soon as possible without experiencing wheel slip or
notch changed too fast.
III. As the desired speed is achieved reduced throttle and set it at a notch where
desired speed can be maintained.
IV. Before slowing down or stopping well in advance of the point of slowing or
stopping bring the throttle to IDLE and take maximum benefit of Coasting.
V. Do not pull the train in case of Alarm Chain Pulling (ACP), in other words if you
feel that the train is heavy, stop and check for cause.




11
ANNEXURE B
Interface Control Document
GOLD, DIALS and REMMLOT
Draft
1
ANNEXURE B
Table of Contents
1Introduction:.......................................................................................................................................3
1.1Purpose:.......................................................................................................................................3
1.2Scope:..........................................................................................................................................3
1.3Definitions, Acronyms and Abbreviations:.................................................................................3
2General Description............................................................................................................................4
2.1Interface Diagram.......................................................................................................................4
2.2Functional Block Diagram..........................................................................................................4
2.3Description..................................................................................................................................5
3Communication Protocol....................................................................................................................5
3.1Frame Formats............................................................................................................................5
4Communication between OBPU and REMMLOT.............................................................................9
4.1How do you do............................................................................................................................9
4.2Communication Configuration:..................................................................................................9
4.3Data frame Tx.............................................................................................................................9
4.4Data frame Rx:..........................................................................................................................10
4.5Real Time Data Transfer ..........................................................................................................11
5Communication between OBPU and OBDU....................................................................................11
5.1Initial Configuration..................................................................................................................13
5.2Run Time Communication:.......................................................................................................14
2
ANNEXURE B
1 Introduction:
1.1 Purpose:
The purpose of this document is to detail the interface between GOLD, DIALS and REMMLOT.
GOLD consists of one OBPU and 2 OBDU's. This document gives the details of the interface
between Remmlot, OBDU and OBPU. In this document OBDU and DIALS should be read
interchangeably.
1.2 Scope:
This document shall be used by vendors of GOLD to interface their systems with REMMLOT for data
transfer and real time GPS Data.
This document shall be used by vendors of OBPU to interface their system with OBDU (DIALS).
1.3 Definitions, Acronyms and Abbreviations:
GOLD Guidance for Optimized Loco Driving
REMMLOT Remote monitoring System for Locomotives
OBPU On-Board Processing Unit
OBDU On-Board Display Unit
DIALS LCD TFT Display 10.4"
Tx Transmit
Rx Receive
RT Real Time
GPS Global positioning System
CRC Cyclic redundancy check
APS As per Section
3
ANNEXURE B
2 General Description
2.1 Interface Diagram
2.2 Functional Block Diagram
4
REMMLOT
GOLD
SERVER
Data from Server
Data to Server
RT Data
TX RX
OBDU
1
OBDU
2
OBPU
Profile
Requests
Profile
Data
OBPU
(MASTER)
REMMLOT
OBDU1
OBDU2
R R
S S
4 4
8 8
5 5

B B
U U
S S
ANNEXURE B
2.3 Description
The GOLD(OBPU and 2 OBDUs) system and REMMLOT shall be connected through an RS485
interface.
OBPU shall be the master and shall initiate all transfers according to the protocol.
REMMLOT shall act as a gateway for data transfer to and from the Server. The destination server
shall be selected by OBPU.
REMMLOT shall provide the real-time data of locomotive control system on request.
The baud rate of communication is fixed at 115200 bps
REMMLOT shall have circular Tx and Rx buffers of 2.5 MB each. The buffer full shall be indicated to
OBPU. It is assumed that OBPU shall have sufficient memory buffer to receive data from REMMLOT
as long as it is being transferred correctly.
The rest of this document describes the protocol for communication and the frame formats.
3 Communication Protocol
3.1 Frame Formats
3.1.1 The communication between OBPU and REMMLOT/OBDU1/OBDU2 shall happen in the following
format
Start
Byte
Address Control Byte Frame Id Length Data field CRC End Byte
3.1.1.1 Start Byte (1 byte) 0xAA
3.1.1.2
Address for frame transfers to
OBPU 0x80
OBDU1 0x81
OBDU2 0x82
REMMLOT 0x83
5
ANNEXURE B
3.1.1.3 Control Byte (1 byte) as per the type of Frame.
3.1.1.4 Frame ID (1 byte) When a set of frames of same type(same control byte) with continuous data is
being transferred, each frame should be given frame ID (start from 0 and increment till 255 and
restart from 0) in order to maintain the sequence of the data. The Frame ID for an acknowledgment
(positive or negative) shall be the same as the frame to which it is responding.
3.1.1.5 Length (1 byte) :- (No. of bytes in the Data Field 1); Max no. of bytes in data field is 256 bytes.
3.1.1.6 CRC(2 Bytes [MSB:LSB]) Remainder to be obtained for all the bytes from Control byte through
Last byte in Data field in that order from Generator polynomial: x
15
+ x
13
+1
3.1.1.7 End Byte 0x55 (1 byte)
3.1.2 REMMLOT Status Bits (2bytes): These are transmited in the data field in all frames from REMMLOT
except Data frame Rx.
Bits(15-7) Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Spare Tx Buffer full Tx Buffer Empty Data
Ready
Rx Buffer Empty Rx Buffer Full CRC
Error
Frame
ID
Error
Spare: Dont cares Reserved for future use
Tx Buffer full: When set indicates that the transmit buffer in Remmlot is filled up completely. Data sent by
OBPU to Remmlot when this flag is set is not stored in the buffer.
Tx Buffer Empty: When set indicates that the transmit buffer in Remmlot is empty(No data awaiting a transfer
to server)
Data Ready: Set when there is atleast one byte of data in the Rx Buffer.
Rx Buffer Empty: Set when there is no data in Rx buffer. Incoming server data will not be stored in the buffer
until this data is read by OBPU.
Rx Buffer Full: Set when the Rx Buffer is full.
CRC Error: When set indicates there is an error in CRC of the frame in Frame ID. When this bit is set, OBPU
is required to resend the Frame ID. If the same repeats thrice a communication fault shall be logged.
Frame ID Error: When set indicates that the frame ID in the last transfer is not in order.When this bit is set,
OBPU is required to resend the Frame ID. If the same repeats thrice a communication fault shall be logged.
In case of Frame ID Error or CRC Error in a frame received by OBPU, it shall request the data again for upto
three times after which a communication fault is logged.
6
ANNEXURE B
3.1.3 Acknowledgment Frame Format:
3.1.3.1 Control Byte: 0x90 for REMMLOT communication; 0x91 and 0x92 for OBDU1 and OBDU2
communication.
3.1.3.2 Frame ID: Frame ID of the frame that is being acknowledged
3.1.3.3 Length: 0x02 for REMMLOT communication; 0x08 for OBDU Communication.
3.1.3.4 Data field:
For REMMLOT Communication:
1 byte 2 bytes
Acknowledgment Status Bits
For OBDU Communication:
1 byte 2 bytes 4 bytes 2 bytes
Acknowledgment Status Bits Current Distance Current
Recommended Speed
Acknowledgment: Positive acknowledgment 0x51; Negative acknowledgment 0x52
In case of communication between REMMLOT and OBPU, REMMLOT Status Bits as per definition in 3.1.2
In case of communication between OBDU and OBPU, OBDU Status Bits as per definition in 3.1.4
Current Distance: GPS synchromized distance(in m)
Recommended Speed: Current Recommended Speed from profile being followed ( in kmph)*10
3.1.4 The time out for reply from REMMLOT/OBPU is 40ms
3.1.5 In case of time out/Frame ID failure/CRC Error successively for 3 times a communication fault shall
be logged in OBPU and the fault shall be recovered automatically if there is a positive
acknowledgement for 3 successive "How do you do" packets(See Sec xxxx).
3.1.6 OBDU Status Bits (2bytes): These are transmited in the acknowledgment frames from OBDU to
OBPU.
Bits(15-
9)
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Spare Frame ID
Error Bit
CRC
Error Bit
Start
Intial
Config
Signal
Green
Signal
Red
Decrease
Target
Time
Increase
Target
Time
Unscheduled
Stop
Request
Profile
Selection
Mode
Spare: Dont cares Reserved for future use
7
ANNEXURE B
Profile Selection Mode Auto(1, set)/Manual(0, not set) selction of profiles
Unscheduled Stop Request Set when unscheduled stop is required.
Target times In order to Increase or decrease target time depending which bit is set.
(incase both are set or both are not set, ignored)
Signal if approching signal is Red/Green corresponding bit is to be set. If both are set or both are not set it
is considered as RED.
Start Intial Config Set when user wants to start a new journey and hence perform initial configuration .
8
ANNEXURE B
3.1.7 All other fields as per definition in 3.1.1
4 Communication between OBPU and REMMLOT
4.1 How do you do
4.1.1 Control Byte:0x44
4.1.2 Data 0x00
4.1.3 Reply Positive acknowledge/Negative acknowledge
4.2 Communication Configuration:
4.2.1 Communication configuration has to be performed initially. This configuration includes destination
server selection and baud rate selection.
4.2.2 Communication Configuration frame:
4.2.2.1 Control Byte: 0x40
4.2.2.2 Length: length of Server ID + baud rate
4.2.2.3 Data field: Server ID and baud rate <format for this to be decided later>
4.2.3 Configuration Acknowledgment: As per 3.1.3
4.2.4 All other fields in frame as per definition in 3.1.1
4.3 Data frame Tx
4.3.1 OBPU shall transmit data in the defined frame format to REMMLOT to be transferred to the
destination mentioned in configuration.
4.3.2 REMMLOT shall transfer store the data in its Tx buffer and send a positive acknowledgment to
OBPU.
4.3.3 REMMLOT shall send a negative acknowledgment incase of Frame ID error or CRC error or buffer
full with the coresponding bit set.
4.3.4 Data frame:
4.3.4.1 Control Byte: 0x41
4.3.4.2 Data field: Data to be transmitted to server
9
ANNEXURE B
4.3.5 Acknowledgment: As per 3.1.3
4.3.6 All other fields in frame as per definition in 3.1.1
4.4 Data frame Rx:
4.4.1 OBPU shall send a Data Receive Request to REMMLOT, when it intends to obtain data from the
server.
4.4.2 OBPU shall keep polling for data until received.
4.4.3 When all the data is transferred from the Rx Buffer, REMMLOT shall send a positive acknowledgment
with the REMMLOT Status Bits(with Rx Buffer Empty set)
4.4.4 REMMLOT shall transmit the data in the receive buffer to OBPU and indicate when Rx buffer empty.
4.4.5 Data frame Request:
4.4.5.1 Control Byte: 0x42
4.4.5.2 Length: 0x00
4.4.5.3 Data field: 0xXX(Dont Care)
4.4.6 Server Data frame :
4.4.6.1 Control Byte: 0x42
4.4.6.2 Frame ID: Frame ID of Data request frame being serviced
4.4.6.3 Data field:
N bytes
Data from Server
10
ANNEXURE B
4.4.7 End Acknowledgment frame: As per 3.1.3
4.4.8 All other fields in frame as per definition in 3.1.1
4.5 Real Time Data Transfer
4.5.1 OBPU shall request for Real-Time data from REMMLOT when required. Update rate in Remmlot is 1
second.
4.5.2 REMMLOT shall transfer the GPS data frame to OBPU as per the defined format.
4.5.3 RT Data Request:
4.5.3.1 Control Byte: 0x43
4.5.3.2 Length: 0x00
4.5.3.3 Data field: 0xXX(Dont care)
4.5.4 RT Data:
4.5.4.1 Control Byte: 0x43
4.5.4.2 Frame ID: Frame ID of RT Data request frame being serviced
4.5.4.3 Length: (Data field size-1)
4.5.4.4 Data field:
N bytes 2 bytes
RT Data REMMLOT Status Bits
4.5.4.4.1 RT Data:
Current Time Stamp(BCD DDMMYYHHMMSS) 6 Bytes,
GPS Co-ordinates:Latitude(ASCII), Longitude,(ASCII) Altitude(ASCII)(as per NMEA Format)
Current Speed bytes(2 bytes [MSB:LSB]) = Speed(in kmph)*10
Notch is given as as it is (range: 1 to maximum notch).
4.5.5 All other fields in frame as per definition in 3.1.1
5 Communication between OBPU and OBDU
11
ANNEXURE B
SEQ COMMAND ID SRC->DST DESCRIPTION Length Data Format
1 0x20 OBPU -> OBDU Poll for Journey Start 0x00 NA
1A 0x21 OBDU->OBPU REPLY with Initial Configuration
Data if available
Depends As Per
Section 5.1.4
1B 0x21 OBDU->OBPU Reply data not available 0x00 0x00
2 0x22 OBPU -> OBDU Send Initial Configuration Data
received from server
Depends APS 5.1.5
2A 0x91/0x92 OBDU->OBPU Acknowledge (current distance
and recommended speed fields
zero)
0x08 APS 3.1.3
3_1 0x23 OBPU -> OBDU Optimal Profile Fixed data Depends
Multiframe
possible
APS 5.1.6
3_2 0x24 OBPU -> OBDU Optimal Profile Variable data Depends
Multiframe
possible
APS 5.1.7
3A 0x91/0x92 OBDU->OBPU Acknowledge (current distance
and recommended speed fields
zero)
0x08 APS 3.1.3
4 0x25 OBPU -> OBDU Run Time Data APS 5.2.3 APS 5.2.3
4A 0x91/0x92 OBDU->OBPU Acknowledge with current
distance and recommended
speed
0x08 APS 3.1.3
5 0x26 OBPU -> OBDU How do you do 0x00 NA
5A 0x91/0x92 OBDU->OBPU Acknowledge (current distance
and recommended speed fields
zero)
0x08 APS 3.1.3
12
ANNEXURE B
5.1 Initial Configuration
5.1.1 Initial configuration request is sent by OBPU to each OBDU for every 30 Sec before the start of
journey (1).
5.1.2 OBDU responds to OBPU with Initial Configuration Data(1A). If data is unavailable OBDU responds
that data is not availabale(1B).
5.1.3 In case initial configuration data is obtained from server via REMMLOT, then OBPU sends the same
to OBDU (2). OBDU acknowledges this data (2A).
5.1.4 OBPU shall generate optimal profile and send profile data (fixed data and variable data) to OBDU
(3_1 and 3_2). OBDU shall acknowledge this data(3A). Whenever a new optimal profile is sent for
the same journey, only variable data shall be sent.
5.1.5 Initial Configuration Data Field:
Route
Selection
Load Train
Length
Fuel
Level
Driver
ID
Train
No.
No. of
Wagons
MPS Formation
type
Caution
order
data
OBDU
Status
Bits
All data is in Ascii Format and each field is separated by a Comma.
Route Selection: <STN1> ,<STN2>,
Load : Load in tonnes,
Train Length : Train length in m,
Fuel Level : Present Fuel level in lit,
Driver ID : Driver ID Entered by the Loco Pilot,
Train No. : Train no. given by railways in ASCII,
No. of wagons/Coaches : No. of wagons/coaches in formation,
MPS: Maximum permissible Speed Limit in kmph,
Fomation type: Type of Formation<exhaustive list to be defined later>
Caution order data: Distance vs Caution orders in the following format
<Number of Caution Orders>,<Start Distance1(ASCII)>,<Start Distance2(ASCII),<SpeedLimit(ASCII)>
OBDU Status bits (2 bytes): As per definition in 3.1.4
5.1.6 Optimal Profile Fixed Data: This data shall be as follows:
Line 1 Start code(10) , Profile ID
following lines: These fields shall be in ASCII and separated by a comma and each data line shall end with
'\n'(CSV FORMAT)
13
ANNEXURE B
Distance Latitude Longitude Gradient Curvatu
re
Station Signal Level
Crossi
ng
Grade
Height
Curve
Height
Notch Spare
End Line End code(99)
Latitude and Longitude As per GPS co-ordinates
Gradient Gradient at given distance (+/-)
Curvature Curvature at given distance (+/-)
Station 1 if distance in row is a station, else 0
Signal 1 if distance in row is a signal, else 0
Level crossing 1 if distance in row is a level crossing, else 0
5.1.7 Optimal Profile Variable Data: This data shall be as follows:
Line 1 Start code(10), Profile ID
following lines: These fields shall be separated by a comma and each data line shall end with '\n'
Distance(in m) Recommended Velocity
(in kmph)
Recommended Notch Expected Time of Arrival
to the next station(in
Seconds)
End Line End code(99)
Distance GPS synchronized distance in m.
Recommended velocity and notch from the generated optimal profile.
Expected time of arrival expected time of at each distance
5.1.8 All other fields in frames as per definition in 3.1.1
5.2 Run Time Communication:
5.2.1 During the journey, OBPU sends RT Data to OBDU every 1 sec .
5.2.2 OBDU responds to this data with an acknowledgment.
5.2.3 Run Time Data Frame to OBDU (4):
RT Data format is as defined in 4.4.4.4.1
5.2.4 Acknowledgment (4A):
As per definition in 3.1.3
14
ANNEXURE B
5.2.5 All other fields in frames as per definition in 3.1.1
Note: This Interface control document (ICD) is for preliminary information is intended for overall
GOLD system interface functional and logical understanding, once total equipment functional usage
is tested in actual locomotive the final ICD document will be released to confirm interoperability
with third party equipments.
15
ANNEXURE -C
DATA FORMAT FOR TRACK SURVEY
1 Requirements
1.1 Track data shall be specified for a section, which is defined as the stretch of the track
between two stations which are junctions
1.2 If the section has UP and Down lines the survey has to be done for both lines.
1.3 The surveyed track data shall be referenced with respect to the hectometer/telegraph posts.
1.4 The GPS co-ordinates shall be available for every hectometer/telegraph post along with the
distance from the previous hectometer/telegraph post.
1.5 The following data shall be surveyed and referenced with respect to the distance
synchronized to hectometer/telegraph posts
1.5.1 Gradient
1.5.2 Curvature
1.5.3 Stations
1.5.4 Signals
1.5.5 Level Crossings
1.5.6 Points
1.5.7 Loops
1.6 Accuracy of GPS Distance should be +/- 10m.
1.7 Accuracy of gradient data should be 0.01 degrees.
1.8 The resolution of data captured should be for at least every 25m
1.9 The data should be in the form of individual Comma Separated Values(.CSV)files for all of
the above.
2 Data Format
2.1 For each section, the following data shall be given in separate CSV file in a folder with
Section name(<Source Station ID>2<Destination Station ID>). Station Ids shall comply to the
IR station ID codes.
ANNEXURE -C
2.2 GPS Co-ordinates with hectometer/Telegraph, File: GPS.CSV

DISTANCE GPS Longitude GPS Latitude Altitude Distance from
Previous
hectometer/tel
egraph post
34/200
<Hectometer or Telegraph
post>
<NMEA
FORMAT>
<NMEA
FORMAT>
<NMEA
FORMAT>
<Distance
accurate up to
1m>
2.3 Gradients/Curvatures File: G.CSV/C.CSV
There gradients and curvatures shall be two different files.
DISTANCE Gradient/Curvature
34.200
<Reset the base value from the nearest
hectometer/telegraph post resolved up to 1m>
<Gradient shall be given in
Rise/Run(1inX) format>
<Curvature shall be given as radius of
curvature>

2.4 Signal Posts(SP.CSV)

DISTANCE Signal Type
34.200
<Reset the base value from the nearest
hectometer/telegraph post resolved up to 1m>
Number Indicating the type of
signal(Distant Starter, Home, etc).
The number starts from 1 and
increases for each new type of signal

This data need not be surveyed if it is available with Railways.
2.5 Level Crossings/Stations(LC.CSV/STN.CSV)
These files shall be two different files.
DISTANCE
34.200
<Reset the base value from the nearest hectometer/telegraph post resolved upto 1m>
<Distances at which level crossings exist>
This data need not be surveyed if it is available with Railways.

2.6 LOOPS(LO.CSV)
This data shall contain information on loops and points.
Distance Line number GPS Latitude GPS
Longitude
As defined earlier
This is the mainline
distance.
Line number for different lines
originating from a point.
<NMEA
Format>
<NMEA
Format>

Shall contain the GPS co-ordinates of the loops and points. The data shall be resolved for every
hectometer. The points'(start and end of the loop) GPS co-ordinates are mandatory.

Vous aimerez peut-être aussi