WR Connectivity Diagram - Complete PDF

  System Requirements Specification of ====================================  SIGNAL & TELECOM DIRECTORATE ============================  -- -- --...

  System Requirements Specification of ====================================  SIGNAL & TELECOM DIRECTORATE ============================  -- -- -- -- -- --  -- -- -- -- -- --  -- -- -- -- -- --  +-----------------------+-----------------------+-----------------------+ | | | \- | +-----------------------+-----------------------+-----------------------+  +-----------------------+-----------------------+-----------------------+ | | | \- | +-----------------------+-----------------------+-----------------------+  -- -- -- -- -- --  \- -- -- ---- -- -- -- ---- ---- -- \- \- \- \-  Table of Contents ================= 1. 2. 3. 2. 3. 4. 2. 3. 4. 5. 5. 6. 7. 8. 9. 10. 4. 7. 8. 9. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 1. 2. 3. 4. 5. 6.  20. **LOGGING OF EVENTS 57** 21. **ENVIRONMENTAL REQUIREMENTS 60** 2. OTHER TYPE TESTS: (ONLY APPLICABLE FOR ROLLING STOCK EQUIPMENT) 61 3. REMOTE INTERFACE UNIT (RIU) 62 22. **DESIGN AND V&V DOCUMENTS 62** 1. DESIGN DOCUMENTS 62 2. VERIFICATION AND VALIDATION (V&V) DOCUMENT 63 23. **OPERATIONAL AVAILABILITY 63** 24. **TESTS AND VERIFICATION 64** 2. ROUTINE TESTS 64 3. ACCEPTANCE TESTS 64 4. TYPE TESTS 65 5. FUNCTIONAL TESTS 65 6. INTEROPERABILITY TESTS 65 7. FIELD TRIALS 66 25. **FOR APPROVAL UNDER DEVELOPMENTAL ORDER 66** 26. **FOR APPROVAL 66** 27. **QUALITY ASSURANCE 67** 28. **PACKING 67** 29. **MARKING 67** 30. **DOCUMENTATION AND TRAINING 67** 31. **SAMPLING PROCEDURE FOR ACCEPTANCE TEST 68** 32. **PURCHASER RAILWAYS -ROLE 68** 33. **SITE ACCEPTANCE OF KAVACH SYSTEM IN RAILWAY 69** 34. **INFRINGEMENT OF PATENT RIGHTS 69**  1. Introduction ============ 1. This document sets forth system, technical and performance requirements in detail for KAVACH, The Indian Railway Automatic Train Protection System (formerly known as Train Collision Avoidance System*)*. 2. Advantage of an interoperable system ==================================== 1. The possibility of step-by-step introduction of the new technology. 2. Enabling Pan-India competition between the manufacturers of KAVACH components. Strengthening the position of the Indian Railway industry on the world market. 3. Enabling preconditions for future harmonisation in other areas of rail traffic management. 3. How to read and use SRS ======================= 4. The reader may refer to the functional requirement specification of KAVACH initially before going through this document. 5. The abbreviation, applicable documents and definition may be referred from functional requirement specification. 6. The technical details such as mode transition, interface protocols & require- ment etc. shall be read from Annexure. 4. Requirements ============ 7. This document offers solutions on how to implement a specific function. 8. The Optional and future requirements are mentioned tively. 9.  10. The implementation of track side functions will have to be defined by OEM according to the characteristics of the specific lines and the related operational needs. In any case, the requirements of this SRS related to the implemented functions shall be respected. 11. The Onboard equipment shall implement all mandatory requirements for in- teroperability. 2. Content of System Requirement specification =========================================== 1. The SRS defines the System Requirements Specification of Kavach (The In- dian Railway ATP). 2. This sub-section is intended to give a rough overview of the contents of each Annexure. 1. **Annexure-A1** -**Mode Transitions, SOS and MA Handling, SR Authori- zation:** This Annexure describes the Mode Transitions and Conditions, mode based Onboard functions, Stationary KAVACH function w.r.t. Onboard modes. SOS and MA handling by Stationary KAVACH for the various track side condition is also detailed. Further, the requirements of SR Authorization and recovery are also detailed. (**MI)** 2. **Annexure-A2** - **Onboard KAVACH Configurable parameters**: This An- nexure describes the configurable parameters of Onboard KAVACH. 3. **Annexure-A3** - **Stationary KAVACH Configurable parameters:** This Annexure describes configurable parameters of Stationary KAVACH. 4. **Annexure-B- LP-OCIP-** **-cum-indication Panel (DMI)) Display Requirements**: This Annexure details general, operational, system, technical and functional requirements for Onboard KAVACH Driv- er Machine Interface so that there is clear and consistent understanding be- tween the Loco Pilot and the KAVACH system**. (MI)** 5. **Annexure-C- KAVACH Multiple Access Scheme & Radio Communica- tion Protocol:** This document describes the requirements for data transmis- sion over the air (through radio), Multiple Access scheme and Radio com- munication protocol for Onboard and Stationary KAVACH sub-systems. It also defines the Radio communication transmission time slots required for operation of KAVACH system. **(MI)** 6. **Annexure-D- KAVACH RFID Tag Data Format**: This Annexure de- scribes the RFID tag data formats for all the possible RFID tags defined for KAVACH System**. (MI)** 7. **Annexure-E1-KAVACH UHF Radio Modem Requirements:** This An- nexure describes the UHF Radio modem (406 to 470 MHz) requirements to be used for the purpose of KAVACH System. (**MI)** 8. **Annexure-E2: KAVACH LTE Interface Requirements:** This Annexure describes the LTE interface requirements for the purpose of KAVACH Sys- tem operation**. (O)** 9. **Annexure-F-KAVACH RFID Tag and Fixing Arrangement Guidelines**: This Annexure describes the RFID fixing arrangement guidelines for the purpose of Kavach System. 10. **Annexure-G-KAVACH Network Monitoring System Protocol:** This Annexure describes the protocol structure for Centralized Network Monitor- ing System for the purpose of KAVACH System**. (MI)** 11. **Annexure-H- KAVACH RFID Tag-TIN Layout Guidelines**: This An- nexure presents the guideline for preparation of RFID tag TIN layout fo ther station and block section**. (MI)** 12. **Annexure-I -KAVACH Control Table Guidelines**: This Annexure de- scribes the guideline for preparation of KAVACH control table based on the 13. **Annexure-J-Remote Interface Units**: This annexure refers to requirement of Remote interface unit which can be installed in auto, IB or gate signal etc**.(M)** 14. **Annexure-K-KAVACH Interface for Electronic Interlocking**: This An- nexure describes the protocol between Stationary KAVACH and Electronic Interlocking (EI) System. **(F)** 15. **Annexure-L-KAVACH Traffic Management System Integration:** This Annexure describes the requirement for interfacing of Traffic Management system with Network monitoring system of KAVACH**. (O)** 16. **Annexure-M-KAVACH TSR Integration:** This Annexure describes the interface requirements of Stationary KAVACH with TSRMS based on the subset specification**. (MI)** 17. **Annexure-N-KAVACH BTM Integration:** This Annexure details the specifications o thef BTM interface of Onboard KAVACH interoperability in TPWS territory. **(O)** 18. **Annexure-O-KAVACH Braking Algorithm**: This Annexure describes the standard braking algorithm for uniformity. (**F)** 19. **Annexure-P- SKAVACH to SKAVACH Interface Requirements**: This Annexure specifies the interface requirements for the neighbouring Station- ary KAVACH communication to perform soft handing over and taking over of Onboard KAVACH. **(MI)** 20. **Annexure-Q-KAVACH Station Master Operation and Indication Panel (SMOCIP) Requirements**: This Annexure describes the SM-OCIP re- quirements for the purpose o thef Stationary KAVACH System**. (MI)** 21. **Annexure-R-KAVACH Cyber Security Requirements**: This Annexure defines a common, minimum set of security measures and risk management etc. To be considered to design a system /subsystem for more stringent se- curity levels to address the threats during cyber attack. (F) 22. Annexure-S-E-Authority to Pass Signal at Danger (F) =================================================== 23. **Annexure-T-KAVACH-VCU Integration** (F) 24. Annexure-U -KAVACH-EOTT Integration (F) ======================================= 25. **Annexure-V -KAVACH-CTC Integration** (F) 26. Annexure-W- RFID Tag and Reader integration (O) =============================================== 27. **Annexure-X- Radio MODEM integration (O)** Subset of specification is listed below: ======================================== a. Temporary Speed Restriction (TSR) Management System b. Requirements for Report Generation Software Tool in NMS c. Requirements of Display Screen Software Tool in NMS 3. Basic system description ======================== 5. The KAVACH system shall comprise of: a. Trackside subsystem b. Onboard KAVACH unit c. Network monitoring system d. Temporary speed restriction management System. 6. KAVACH shall be capable of working in electrified as well as non-electrified territories. 7. The Onboard KAVACH unit and Track side subsystem shall not in any way infringe the schedule of dimensions being followed by the purchaser Railway. 8. Trackside Subsystem =================== 12. **The Trackside subsystem shall be comprised of** a. RFID tag b. Stationary KAVACH Unit c. Remote Interface Unit d. Tower and Antennae 13. RFID Tag ======== 1. RFID tags shall be fitted on the sleepers between the track in both stations and block section for giving trackside information to Onboard KAVACH. 2. RFID tags at all the places shall be duplicated. 3. RFID tag shall be as per following specifications: a. Suitable for reliable working at train speed upto 250 KMPH (minimum). b. Frequency of operation: 865-867 MHz c. Can be programmable with minimum 128 bits (including CRC) of user data.  d. Communication Protocol ISO-18000-6D e. Shall have minimum IP 68 protection. It shall work after being sub- merged in 1m depth water for 24 hours. f. Other requirements like environmental, climatic etc. As per RDSO/ SPN/144 or for any contradiction, requirement mentioned in the specifi- cation will be prevailed. g. Under field operating conditions RFID reader antenna shall be able to read RFID tag from a vertical distance of 700mm (maximum) from bot- tom of RFID reader antenna to the top of the rail level. Linking: (SIL-4) ================ h. To determine whether an RFID tag has been missed or not found within the expectation window, and to take the appropriate action. i. To correct the accumulated Odometry error (5 m location accuracy of RFID Tag + 5% of the distance travelled from last read tag) j. All linking information on the tag is sent from the Stationary KAVACH to the Onboard KAVACH over Radio communication. k. An RFID tag is linked when its linking information is known in advance. 5. **Classification of Tags:** RFID tags are categorized as follows: l. Normal Tag m. LC gate Tag n. Adjacent Line Tag o. Adjustment/Junction Tag 6. Normal tag: =========== p. Normal tags shall be provided in the block section as well as in station sec- tion. The maximum distance between the two normal tags shall not be more than 1000m. q. The Normal tag shall cater the requirement of the Inline section, Signal foot, TIN discrimination/ Turn Out, Dead Stop and Exit Tag as per the placement of the tag. 7. **The LC gate tag** shall be provided on both sides of the LC gate as required by operating Railway and is an optional requirement. Action in Loco Cab for LC Gate approach would be a non-SIL requirement. 8. **The adjacent Line tag** is used to specify the adjacent line information to  9. **The Adjustment/Junction Tag** is used for absolute location correction or/and direction reset. Stationary KAVACH Unit: ======================= e. Station/LC/IB KAVACH Vital Computer. f. Stationary KAVACH Radio Unit. g. Station Master Operation and Indication Panel. 15. Station/LC/IB KAVACH Vital Computer =================================== 1. The Vital Computer shall generate messages to be sent to the Onboard KAVACH based on information received from interlocking inputs, adjacent Stationary KAVACH, TSR Management system and information ex- changed with the Onboard KAVACH units. Vital Computer architecture shall be minimum 2 out of 2. 2. The Vital Computer shall have Real Time Clock synchronization facility with GNSS clock to synchronize with other KAVACH systems in hot standby manner. 3. The Vital Computer shall have provision for the following: a. To interface with signalling inputs in a fail-safe manner. b. The data shall be recorded at three levels (See FRS). c. Ethernet port and two GSM/LTE interfaces for connectivity with Network Monitoring System (NMS) and Key Management System. d. To interface adjacent Stationary KAVACH, TSRMS and Radio communication (LTE/5G), EI etc. Minimum 08 no of Communica- tion Ethernet port is required in Stationary KAVACH. e. To interface with OFC (Dark Fibre) for connectivity with Remote Interface unit (minimum six Port). f. USB/Ethernet interface to connect the laptop for downloading of log & other data for diagnostic purposes. g. To interface with Video Display Unit (VDU) to show real time dis- play of Loco movements and signal aspects of the yard. However, Video Display Unit (VDU) itself is not part of the KAVACH system and optional as per requirement of the Zonal Railways needs. h. To interface with two numbers of Radio units. i. To interface with SM-OCIP. 4. There shall be provision of switching off display of Signal Aspect and Sig- 5. Stationary KAVACH and Remote Interface unit (RIU) shall work with in- put voltage of +110 V DC, (+30%, -20%). If any other voltage used, neces- sary provision for conversion of voltage to be ensured by the firm. 6. Stationary KAVACH shall be universally suitable for various types of sig- nalling of Indian Railways with or without provision of colour light signal- ling. By default, it shall be suitable for interfacing with relays. 16. Stationary KAVACH Radio Unit ============================ 1. The radio communication network shall be used for the bi-directional ex- change of messages between Stationary KAVACH and Onboard KA- VACH. 2. UHF full-duplex radio communication unit shall have hot standby provision with separate cable & antenna for each radio, to communicate with Onboard KAVACH. 3. If no communication is received from a registered Onboard KAVACH unit for continuous 2 minutes (configurable) for absolute block section and 30 seconds (Configurable) for automatic block section), the same shall be de- registered by the Stationary KAVACH. 4. The Stationary KAVACH to Onboard KAVACH regular Packet shall be sent by switching radio modems at predetermined interval not exceeding 3 cycles for transmission purpose, if both radio modems are working proper- ly. 5. Redundant received packet shall be discarded using sequence number. The sequence number shall be a combination of frame number, packet type, Source ID, Destination ID as shown in the table below. -- -- -- -- -- -- -- -- -- -- Table Possible combination for validating Sequence ID ===================================================== 6. The communication mandatory area for a Stationary KAVACH shall in- clude at least two RFID tags prior to a distance of 1km from first approach- ing signal of the respective Stationary KAVACH in Absolute Block Sec- tion. Communication is mandatory for the entire Automatic Block section. 7. The Station / Interlocked LC Gates / IBS unit shall periodically transmit in 8. In order to improve the throughput, on recognition of radio message from a fresh loco pertaining to the territory of the Stationary KAVACH unit, the Stationary KAVACH shall allocate a Timeslot and Frequency Channel pair for Communication with that particular Onboard KAVACH unit. 9. Stationary and Onboard KAVACH timeslots and frequency channel pairs shall be approved by User Railway. Care should be taken so as to not allo- cate adjacent time slots at the same station. The typical scheme is included in Annexure-C. 17. Station Master Operation cum Indication Panel ============================================= 1. Following indications/ buttons/ buzzers shall be given in the Station Mas- e. (e) f.  g. (g) h. (h) 2. Signalling cable shall be used for button, counter, and power supply. CAT- 6 armoured cables or OFC shall be used for communication 3. Health Indication shall be flashing green if Stationary KAVACH is healthy and it shall be made blank when Stationary KAVACH is not healthy and Red indication shall glow. 4. The requirements are detailed in **Annexure-Q.** 18. Remote Interface Unit (RIU) =========================== 1. Remote Interface Unit (RIU) shall be used where remote signalling functions are required to be fetched to a nearby Stationary KAVACH. 2. Remote Interface Unit (RIU) shall have provision for interfacing with signal- ling inputs in a fail-safe manner. 3. OFC shall be the only as the media for connecting the various RIUs to the Stationary KAVACH unit. The maximum number of dark fibres shall be four Single mode OFC per ring. Primary and Secondary rings shall be used for -- -- -- -- -- -- -- -- -- -- 4. The OFC ring network shall be formed to increase availability of the net- work. RIU shall be connected with two modems each with two ports. The typical scheme is included in Annexure-J. 5. The vital communication protocol shall be compliant to CENELEC norma- tive EN-50159 (closed communication system). 6. A single RIU shall be capable of communicating with two adjacent RIU units so that the operations are not affected in case of communication link failure on one side only. 7. A single RIU shall be capable of handling at least 32 field inputs. 8. RIU shall consist of Vital Input modules with minimum Two-Out-Of-Two architecture. Each vital input module shall have independent read channels to read the status of each input. If the same state is not detected after the timeout (6 Seconds-Configurable) by any channel, a comparison of the ob- tained input state between input channels shall be performed by vital com- puter. Unless same status is detected in the same input through various input channels for the definite time, corresponding input state will not be consid- ered as safe for further processing. Tower and Antenna ================= 2. The Stationary communication system for station/IBS/mid-section inter- locked Gate unit shall provide communication coverage at least in the com- munication mandatory area for the Stationary KAVACH. 3. The antenna cable & antenna shall be suitable to provide a minimum range of communication. The antenna shall be tuned to minimum frequency of 425 to 430 Mhz preferably with a minimum gain of 5 dBi. 4. Throughout the Communication Mandatory area, the Radio Signal Strength shall have a minimum fade margin of 30 dB above receiver sensitivity. If this signal strength is not achievable, then additional Stationary KAVACH/Tower shall be planned in the block section. 5. The maximum length of the permanent dark zone for which radio communi- cation interruption is permitted at single stretch is 100m. As far as possible and such dark zone shall not be in the vicinity of a stop signal. 6. The communication need not be mandatory in tunnels except for those which are o then immediate approach (distance corresponding to 30 seconds at the highest permissible speed of any KAVACH equipped train at that spot) of a signal. 7. Requirements of Radio Holes: (F) ============================================================================== -- -- -- -- -- -- -- -- -- --  a. All efforts shall be made to avoid Radio Holes. b. There shall not be any stop signal or track section boundary inside a ra- dio hole. If this is unavoidable, Movement Authority shall be extended only up to the first approaching stop signal in the radio hole area. The other signals are to be crossed by the Loco Pilot in SR Mode. c. The radio hole shall be indicated in the RFID layout and shall also re- flect in KAVACH Control Table. d. When Radio hole information is received from Stationary KAVACH, Onboard KAVACH LP-OCIP (DMI). The Ra- e. When Radio hole is there, Onboard KAVACH can continue in FS mode until approaching signal foot, beyond it can continue in SR mode. f. Stationary KAVACH shall deregister the Onboard after deregistration timeout. g. Actual Radio hole distance + 10 seconds (default, 6-12 seconds) x cur- rent speed (Kmph) shall be calculated as the radio hole distance by Onboard KAVACH. h. Upon resumption of radio communication, a new session is to be estab- lished. The Loco Pilot may continue any valid movement authority. 8. Design of the Stationary KAVACH tower and foundation not being part of this Specification, Purchaser railway shall take the following actions: i. Purchaser railway shall decide the type of Tower - Whether Lattice type or Concrete or monopole type or any other type. j. Purchaser railway shall decide height of the tower. Normally tower height shall be 40 meters above the ground level. The height of the tower can be reduced as per requirement of the site by the purchaser Railway. k. In case of the tower on top of building, the typical height shall be on 4 m on top of the building. l. Purchaser railway to ensure that basis of design of the tower and founda- tion shall include wind velocity, soil bearing capacity, tower site, ladder, platform, staging, aviation lamp and earthing arrangement. m. Design of the tower and its foundation shall have acceptance of purchas- er railway prior to commencement of their execution work. n. Required WPC, SACFA and any other regulatory authority clearances shall be obtained by Purchaser Railway. Onboard KAVACH unit ===================  20. **The Onboard KAVACH unit shall be comprised of** 1. Onboard KAVACH Vital Computer. 2. Two RFID readers consisting of RFID Reader Antenna in hot standby. 3. Onboard KAVACH Radio Unit consisting of two Radio Modems in hot standby with separate cables and antennae for each radio or LTE router unit (02Nos) as prescribed by the purchaser. 4. Two Driver Machine Interface (LP-OCIP (DMI)) for each locomotive or one LP-OCIP (DMI) for each Driving motor coach of EMU/DMU/MEMU/DEMU/Trainset etc. 5. Brake Interface Unit (BIU), where required. 6. The system shall be interfaced with LTE (O) and BTM Reader (O). Currently, ETCS SRS 2.3.0d and 2.2.2 is in vogue on Indian Railways. 21. Onboard KAVACH Vital Computer ============================= 1. The Onboard KAVACH vital computer is a system that supervises the move- ment of the train to which it belongs, on the basis of information exchanged with Stationary KAVACH units and other Onboard KAVACH units. Vital Computer architecture shall be minimum 2 out of 2. 2. The onboard KAVACH vital computer shall have Real Time Clock synchroni- zation facility with GNSS clock to synchronize with other KAVACH systems in hot standby manner. 3. Onboard KAVACH vital computer shall have provision for the following**:** a. To interface with train interface unit & brake interface unit. b. The data shall be recorded at three levels (See FRS). c. Two Direction sensing type Speed Sensor in each pulse generator shall be used to interface for direction determination, distance and speed measurement. d. To interface with two RFID readers to read RFID tags fitted to the track. e. To interface with the BTM reader to read Balise fitted to the track in TPWS sections. (Optional) f. To interface with two Driver Machine Interfaces (LP-OCIP (DMI)) con- sisting of display arrangement & buttons/ switches for operation. g. Two commercial GSM/LTE interfaces for connectivity with centralized Network Monitoring System and Key Management System. It should al- so be operable with LTE where LTE is provided. h. USB interface for downloading of log & other data for diagnostic pur-  4. Onboard KAVACH shall be suitable for use on AC/DC Traction, EMUs/DMUs/MEMUs/ Trainsets single or multi-headed electric/diesel loco- motives/ banking locomotives. The onboard KAVACH unit shall be suitable for all types of electric and diesel locomotives, including all types of micro- processor-based locomotives and Locomotives wih Distributed Power Control System (DPCS)/ Distributed Power Wireless Control System (DPWCS) run- ning fn Indian Railways. 5. The equipment shall work on DC supply source normally consisting of accu- mulator battery and or an auxiliary generator. The nominal and limits of volt- age in which the equipment shall operate satisfactorily are as under. -- -- -- -- -- -- 6. Voltage fluctuations lying between 0.6 to 1.4 times of Nominal voltage and not exceeding 0.1 second shall not cause any deviation in the functioning of the unit (Clause 5.1.1.2 of IEC 60571:2012). Voltage fluctuations lying be- tween 1.25 to 1.4 times of Nominal voltage and not exceeding 1 second shall not cause damage to the unit. The unit may not be fully functional during these fluctuations. (Clause 5.1.1.2 of IEC 60571:2012). 7. The onboard KAVACH unit shall be suitable for various types of braking sys- tems of Diesel and Electric Locomotives/EMUs/MEMUs/ DEMUs/Trainsets. The type of loco or other self-propelled vehicle, braking system and inputs for the interface would be provided by the Purchaser for retro-fitment. 8. Electromechanical non-resettable 6-digit counters for the recording operation of the Loco unit to Isolation Mode, Trip/Override & SoS (transmit/receive) are to be provided. The installation scheme is included in Annexure-B. 9. Onboard KAVACH shall interface with Loco Cab controls to determine train direction. For retro-fitment, the Loco dependent details for an interface are to be provided by the Purchaser. 10. Cables and Connectors ===================== i. **Data Cables**: Fire Retardant STP (Shielded twisted Pair) CAT-6 Cable or Co-Axial Cable shall be compliant to IEC 60332-1, 60332-2 & 60332-3/ EN45545 for fire. j. **Power Supply Cables**: Shall meet RDSO specification ELRS /SPEC/ ELEC /0019 Rev 4 or latest. k. The Connectors provided shall be suitable for Rolling stock application of AMPHENOLI/PHOENIX/ALLIED/HARTING or any other ap- proved make from Electric Loco/ PS&EMU/ Motive Power directorates  l. Ingress Protection for dust and water by providing gasket & sealing of cable entry/exit along with heavy duty industrial type lock and key. Lock and key & hinges shall be of Southco/EMKA/Dirak/Jin Tay make. 22. Onboard KAVACH Radio Unit (If UHF is used) ========================================== 1. The Onboard KAVACH Radio Unit specifications shall be similar to the Sta- tionary KAVACH radio unit. 2. It shall have provision to switch to another frequency channel, whenever re- quired. 3. The Onboard KAVACH Antenna shall be tuned to minimum frequency of 425-430 Mhz preferably with a minimum gain of 3 dBi antenna. 4. The onboard KAVACH antenna shall be able to withstand air pressure when the loco is running at a speed of 250 kmph. 5. The outdoor cable for connecting Onboard KAVACH and GPS / GSM / UHF Antennae shall be waterproofs (Preferably IP-67) and flame retardant. 6. The Onboard KAVACH, when not allotted with any time slot, it shall start transmitting in one of the reserved time slots nominated for this purpose in frequency f0. 7. In Block sections, if communication is not required with Stationary KA- VACH, Onboard KAVACH should transmit the access request message on f0 frequency in the portion of the frame cycle nominated for this purpose so that other nearby Onboard KAVACH can directly receive the messages. 8. The Onboard KAVACH shall transmit through alternative radio and receive on both the Radios simultaneously and discard the redundant packet of same sequence number. The sequence number shall be a combination of frame number, packet type, source ID, Destination ID as shown in below table. -- -- -- -- Table: Possible combination for validating Sequence ID ====================================================== 23. **RFID Reader** 1. Each Onboard KAVACH unit shall have two RFID readers for getting the infor- mation from RFID tags fitted on the trackside in hot standby manner.  2. The RFID reader shall be as per following technical specifications: a. Suitable to be fitted underneath Locomotive body & shall be rugged enough to withstand vibrations. b. Suitable for reliable working at Train speed to 250 KMPH. c. Frequency of operation: 865-867 MHz d. Should meet EN 55022, Class B for Radio Frequency disturbances. e. Communication Protocol shall be: ISO-18000-6D f. Shall have minimum IP 65 protection, if the RFID reader is placed outside of the locomotive or IP 64 protection, if the RFID reader is placed inside the locomotive. However, IP 67 is preferable. g. Other requirements like environmental, climatic etc. as per RDSO/ SPN/144 or as per specification. In case of contradiction, the require- ment as per specification will prevail. h. Under field operating conditions RFID reader antenna shall be able to read RFID tag from a vertical distance of 700mm (Max) from bottom of RFID reader antenna to the top of the rail level. i. The installation of RFID reader antenna would be done in such a manner so that the vertical distance from bottom of RFID reader an- tenna to the top of the rail level is 350mm ± 50mm. The lateral centre of RFID reader antenna shall be within ± 50mm of the track centre with antennae in the horizontal plane. 3. When an Onboard mounted RFID reader passes over RFID tags, RFID tag shall transmit the programmed data to the RFID reader. The horizontal range of RFID reader shall not be more than 750mm under field operating conditions. 4. The Onboard KAVACH shall calculate the location of the train between two RFID tags dynamically based on the distance travelled from last RFID tag through speed sensing arrangement. 5. The Onboard KAVACH shall act as per the information received from even one RFID tag out of duplicated tags. However, in such case, it shall log the missing RFID tag & transmit the same to NMS. 6. On registering, the Stationary KAVACH shall send all the expected RFID tags in the route. The Onboard KAVACH shall monitor the same. In case of single or duplicated missing tags, information shall be sent to the NMS. On not receiving any information from any RFID tag either due to both tags missing or due to any other reason, within the window limits of L\_doubt over and L\_doubt under, Tag missing indication shall be displayed on LP- OCIP (DMI). The tag missing information shall be sent to the NMS. How- ever, the details of Tag read shall be stored in the event logger.  7. If the Onboard KAVACH reads the Exit RFID tag (non-KAVACH territory), it shall  stop the radio communication -cum-indication panel (LP-OCIP) =============================== 2. The following functions of LP-OCIP (DMI) shall be verified & validated to Safety Integrity Level (SIL-2) of CENELEC or equivalent international stand- ards. a. Communication with Onboard KAVACH. b. Train configuration selected by the loco pilot. c. SOS operation by the loco pilot. d. Signal Aspect display e. Train length display f. Train configuration display g. The function in LP-OCIP (DMI) for displaying the context messages for h. Display of all modes of loco operation i. Current speed j. Over speed k. Permissibled speed l. Target speed m. Section speed n. Movement Authority (MA) o. Target distance- (distance from approaching target of EOA / Turn Out / TSR/PSR/Collision /SoS). 3. LP-OCIP shall have minimum 12 soft keys (including 2 spare keys for fu- ture use), 4 navigations (Up/Down/Left/Right), Brightness Control Keys, Clear Key and Enter Key. 4. LP-OCIP shall have three push buttons, namely SoS, Common/ACK and Cancel. 5. The onboard KAVACH unit shall transmit SoS message, when SoS and  6. The onboard KAVACH unit shall stop the transmission of SoS message, when Common/ACK push button and Cancel push button are pressed sim- ultaneously. 7. Common/ ACK push button shall be used for Loco pilot acknowledgement, such as inhibiting the unusual stoppage message in block section, when transiting from Full supervision mode to Onsight mode/Limited supervision mode/Staff Responsible mode, Onsight mode to Limited supervision mode/Staff Responsible mode & Limited supervision mode to Staff Re- sponsible mode. 8. LP-OCIP shall have two indications (both in bi-color) to display system health status and SoS status. 9. The Onboard KAVACH unit shall display the System health status as Green as long a thes system is healthy otherwise it shall be displayed as Red. 10. The Onboard KAVACH unit shall display the SoS indication as Green as long as no SoS (Transmit/Receive). It shall be displayed as Red, if SoS is received or transmitted. 11. LP-OCIP/DMI shall have a two-position switch i.e. to change from/to lead- ing/nonleading mode. This switch is not required for a self-propelled vehi- cle. 12. -cum-indication panel (LP-OCIP/DMI) shall have an electronic buzzer to generate audio alerts / alarms. 25. Brake Interface Unit (BIU) ========================== 1. The KAVACH shall be capable of giving following three levels of brake commands for train braking: a. Normal Brake (NB) command (not applicable for EMUs and other self-propelled vehicles) b. Full-Service Brake (FSB) command c. Emergency Brake (EB) command 2. The Onboard KAVACH shall also give additional command, i.e. Loco Brake command in conjunction with Normal Brake / Full-Service Brake / Emergency Brake, to develop Brake Cylinder pressure up to maximum val- ue corresponding to loco independent brake, if the train is identified as a Light Engine. 3. The Brake Interface Unit (BIU) features: d. BIU shall apply Normal, Full service & Emergency brakes of locomo- tives respectively based on the type of brake command received from the e. BIU shall not reduce the braking level initiated by the Loco Pilot. How- ever, Onboard KAVACH can increase the level of braking over loco pi- lot initiated braking as and when need arises. It shall be possible to in- crease the extent of the brake level (initiated by Loco unit) by the loco pilot, if he desires so. f. BIU shall not modify the existing braking characteristics of the locomo- tive (single/Multi Unit/Banking) as well as other self-propelled vehicles treated as trainers. g. It shall automatically cut off traction/ regression at the instance of the Onboard KAVACH unit-initiated braking & traction sha thell be enabled only after withdrawal of Onboard KAVACH unit brake commands. Lo- co pilot has to physically operate the traction notch subsequently, to power the train. h. The Onboard KAVACH hardware design shall have feasibility for inter- facing to BIU either through potential free contacts or through DC volt- age or current loop or Serial Communication ports as specified by Pur- chaser. Purchaser needs to provide interface details. i. The Onboard KAVACH shall have feasibility for interfacing with Uni- versal BIUas per relevant Motive Power Directorate Specification No MP.0.01.00.31 (Rev.02) Or latest. It shall have feasibility to interface with E-70, CCB and Electro-Pneumatic (EP) or any other braking sys- tem used in Indian Railway. 4. Brake Characteristics ===================== j. The Onboard KAVACH shall have provision for acquiring the braking characteristics through LP-OCIP (DMI) as per the selections made by Loco Pilot at the start of the mission or whenever there is change in train consists. k. On formation of a new train, the Onboard KAVACH unit shall prompt Loco Pilot for selecting the train configuration. l. The brake characteristics shall be such that in the event of perceived danger, the Onboard KAVACH unit shall be able to stop train short of safe distance or control the speed to the desired value before target. This distance should be possible to be configured during installation with nominal values as 300m (Configurable) for Rear-end Collision preven- tion, stop immediately on detection or a distance of 5000m (Configura- ble) whichever is less for Head on Collision prevention and short of Sig- nal at Danger in case of SPAD prevention. m. It shall be possible to test the working of all brake valves of Brake Inter- face Unit (BIU) in a Stationary condition of the train by pressing Manual  n. The MBT shall be possible to be initiated through a soft key on the LP- OCIP. o. The braking logic of the Onboard KAVACH unit shall be so intelligent that based on the brake characteristics of the train and depending upon the speed of the train, average gradient of the location & the target, Onboard KAVACH shall decide which type(s) of brake and when to be applied to stop the train short of safe distance or control the speed to de- sired value before target. p. In case the distance available between the train and target at the instance of perceived danger is not adequate, the Onboard KAVACH unit shall apply maximum brake to reduce the speed of the train as much as possi- ble under the circumstances so that impact can be minimized. 26. Isolation of Onboard KAVACH =========================== h. The design of the Onboard KAVACH unit equipment shall be such that its brake interface unit can be isolated by the Loco Pilot as and when required. i. The isolation switch and other switches along with the counters shall be provided in a uniform manner in an encapsulated box at an iden- tifiable place within Loco. j. The isolation of KAVACH from brake interface shall be communi- cated to the Network Monitoring System through commercial GSM/LTE. k. The isolation mechanism must be protected and isolation of braking interface must be recorded through the counter provided. l.  m. Isolation of KAVACH/ BIU shall not affect existing brake charac- teristics of the loco/other self-propelled vehicles. n. Traction cut off feature through KAVACH shall also be isolated un- der such events. 1. The system design shall be such that in case of Stop Signals at ON / End of Authority: a. The train shall stop as close as possible to the signal at ON. b. The train stops within 5m on the approach of the signal for 90% of the cases. c. The train stops within 30 m on the approach of the signal for 98% of the cases.  d. On detection of incident of stop signal subsequently put back to ON, the train stops with Train Trip through application of Emergency Brakes at least after crossing the Signal if not earlier. 2. The speed and distance monitoring of the on-board system can only assure this when the necessary conditions are fulfilled. e. Brake system of the train functions as specified. f. Wheel/rail adhesion is sufficient for the required safe deceleration. g. Brake characteristics (and other train related inputs) are correctly entered into the Onboard system. 3. Train type/configuration shall be selected through LP-OCIP to acquire the braking characteristics of the train. 4. The braking algorithm used shall be suitable to the application environment, including all types of rolling stock and section. 5. The system should be designed in such a way to detect slip or slide and miti- gate their effect to keep the error in speed (5kmph or 5%, whichever is lower) and distance (±50 m) within the limits specified. If the wheel is slipping con- tinuously for more than 90 seconds (default, Min: 60, Max 180 seconds), Onboard KAVACH shall transit to SR Mode and prompt for acknowledge- ment. It shall continue to do so, till the condition of wheel slip/slide is re- moved. No braking to be applied if acknowledgement is received from Loco Pilot. 4. Radio Communication Security and Key Management System ====================================================== 10. Communication technique based on AES-128 security coding shall be used for communication between Stationary and Onboard KAVACH Units to comply with EN-50159. 11. Radio Communication shall use cryptographic techniques with security keys to transfer messages between Onboard KAVACH and Stationary KAVACH units. 12. When the Stationary KAVACH unit is communicating the safety related data with Onboard KAVACH, it shall verify that communication is established with an authorized Onboard KAVACH unit and vice versa. Consequently, the authenticity and integrity of any information exchanged between Onboard KAVACH and Stationary KAVACH unit shall also be verified. 13. In order to ensure complete protection, the above procedure shall take place each time the Onboard KAVACH and Stationary KAVACH unit effectively start a new communication session between them. 14. After each successful Identification & Authentication (I&A) dialogue, the data shall be protected using a Message Authentication Code (MAC).  15. All messages in time slots reserved for emergency messages and Loco-to-Loco direct communication, are not subjected to the aforesaid procedure of I&A dia- logue due to the nature of the information conveyed by such messages. 16. Key Definition & Type of Keys: ============================== 27. The key is defined as a sequence of 128 bits. The following table summa- rizes the key types and usage of each type of key. -- -- -- -- 28. **Authentication Key (KA):** Authentication Keys are a group of 2 keys. Authen- tication shall be identical for a group of Stationary KAVACH and Onboard KAVACH pairs, adjacent Stationary KAVACH pair and TSRMS and Stationary KAVACH pairs. This group of keys shall be stored in separate memory. The following table shows one set of Authentication keys for example. -- -- -- -- -- -- 29. Derivation of Authentication Key KA, for a pair of Stationary KA- VACH and Onboard KAVACH ========================================================================================= 1. Authentication key shall be selected based on the below formula: Example: ======== 2. For the pair of Stationary KAVACH (00501) and Onboard KAVACH (27854) the Authentication Key is stored in the first memory location -1 (i.e. Authentication Key 2).  30. Derivation of Authentication Key KA, for a pair of Stationary KA- VACH and Stationary KAVACH ============================================================================================ 1. The Primary partner shall generate a unique random number (two bytes) for each adjacent station and send it to secondary partner, when a new connec- tion is required to be established. The Stationary KAVACH with higher unique ID shall be primary partner. 2. The Secondary partner shall generate a unique random number (two bytes) for each adjacent station and send it to the primary partner when a primary partner requests a new connection. 3. Authentication key will be selected based on the below formula: Example: 31. Derivation of Authentication Key KA, for a pair of TSRMS and Sta- tionary KAVACH ================================================================================ 1. The TSRMS shall generate a unique random number (two bytes) and send it for each Stationary KAVACH, when a new connection is required to be es- tablished. The TSRMS is primary partner and the Stationary KAVACH is secondary partner. 2. The Stationary KAVACH shall generate a unique random number (two bytes) and send it to the TSRMS when the TSRMS requests a new connec- tion. 3. Authentication key will be selected based on the below formula. 4. Example: 5. For the pair of TSRMS (10501) and Secondary Stationary KAVACH (27854) the Authentication Key is stored in the Zeroth memory location (i.e. Authentication Key 1). 32. Transmission of Authentication Key: =================================== 1. Key management system (KMS) shall generate sets of Authentication Keys with a valid time period for each set. The following table illustrates the structure of Authentication Keys.  2. **Authentication Keys Unique ID:** Four Bytes (KMS will generate Unique ID at the time of generation of Authentication keys). Number of Key Sets One Byte (Value: 4 in this example) ====================================================== -- -- -- -- -- -- -- -- 3. The Key validity period shall be defined by the beginning date followed by the end date of the validity period for each set (in HH DD MM YY format 4. KMS shall generate Unique ID at the time of generation of Authentication Keys. This Unique ID shall be used to know the latest Authentication Keys available with the KMS. 5. KMS shall maintain 30 sets of Authentication Keys. However, the total time duration of all the Authentication Key set shall not be less than 120 days. The KMS shall add the required number of keys when the total time duration of key sets available falls to less than 60 days. However, the previ- ous remaining keys shall not be changed during this addition of keys. 6. KAVACH Sub System (Stationary KAVACH, Onboard KAVACH and TSRMS Management System) shall send the Authentication Query mes- sage to KMS every 6 hours to detect whether a new set of Authentication keys is generated or not. 7. If KAVACH sub-systems find that new set of Authentication keys is avail- able at KMS, it shall send a first request to Key Management System at randomized time over next 2 hours. 8. Randomized request shall be as follows: a. If the first request is not successful, it shall send request for every 5 minutes until it receives the information from the Key Management System.  b. KMS shall send Authentication keys to KAVACH subsystem when it receives the request for same. c. KMS shall verify the authenticity of the request before transmitting the Authentication Keys. d. KMS shall have the database to store the mobile numbers of all the KAVACH subsystem units. These mobile numbers shall be used to verify the authenticity of Authentication Keys request. These mobile numbers will be fed online through a secured transaction by the RDSO. 33. Process flow for authentication key transmission ================================================ 1. KMS is responsible for distribution of authentication keys to KAVACH systems for radio security. 2. KMS shall have a registered URL or a constant public domain IP for packet reception. All the KAVACH systems shall use GPRS or commercial LTE to communicate with KMS. SIM cards for this purpose shall be provided by purchaser Railway. 3. For LTE, the Private Key certificate shall be installed on Stationary and Onboard KAVACH systems. This shall be stored in non-volatile memory. (Optional) 4. KMS shall use OTP (One Time Password) over SMS technique, through GSM, to authenticate the KAVACH subsystems before sharing the Authen- tication Keys. KMS shall send an OTP (SMS) to the registered mobile number after receipt of Identification message. 5. KAVACH subsystems shall verify currently used Authentication Key set in the KMS by validating the Key set ID received in the Authentication Re- quest message with the current Authentication set ID in the KMS. 6. KAVACH subsystem shall send and identification message to KMS at the  7. When the request is received by the KMS for Authentication Keys, it shall send OTP to the respective KAVACH unit through SMS. KMS shall also send Identification acknowledgment message, to update the status of SMS (OTP). 8. KMS shall send the Authentication key message to KAVACH entities, if it receives the expected OTP. 9. KAVACH units shall store the Authentication Keys in non-volatile memory. 34. Packet structure between KAVACH entities and KMS ================================================ 1. Following tables shows the packet structure to be used for communication between KMS and KAVACH units for the purpose of transmission of Au- thentication Keys. The packet transmission protocol shall be in UDP. 2. **Identification Message, 20 bytes** (KAVACH to KMS) -- -- -- -- -- -- 3. **Identification Acknowledge Message**, 20 bytes (KMS to KAVACH) -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  -- -- -- -- -- -- 4. **Authentication Key Request Message**, 24 bytes (**KAVACH to KMS**) -- -- -- -- -- -- Authentication Key Message (KMS to KAVACH) ========================================== -- -- -- -- -- --  -- -- -- -- -- -- Authentication Query Message, 19 bytes (KAVACH to KMS) ====================================================== -- -- -- -- -- -- 7. **Authentication Key Status Message**, **23 bytes (KMS to KAVACH)** -- -- -- -- -- --  Format for One Time Password (OTP) in SMS ========================================= Computation of Session Key (KS): ================================ Example: ======== 10. Onboard KAVACH shall generate a unique two-byte random number and send it in Access Request Packet. 11. On receipt of the Access Request Packet, Stationary KAVACH shall gener- ate another unique two-byte random number and send it in Access Authori- ty Packet. 12. Generic Message Authentication Calculation (CBC-MAC): =====================================================  Cipher Block Chaining Message Authentication Code (CBC- MAC) Application: ========================================================================= 14. **Security considerations for** KAVACH **Data Packets:** KAVACH subsystem data packets will be in multiple of bytes. **Example:** 15. Process Flow for Onboard KAVACH Registration: ============================================= a. On entering Communication Mandathe tory area in vicinity of Sta- tionary KAVA theCH territory, Onboard KAVACH unit generates Random number RL and sends the Access Request Packet to Station- ary KAVACH b. On reception of Access Request Packet from Onboard KAVACH Unit, Stationary KAVACH unit generates its own Random Number (RS) and computes the session key KS and transmits the Access Au- thority Packet in f0 frequency with CBC-MAC code. The access Au- thority message contains frequency channel, Tim slot and Random Number RS. c. The onboard KAVACH unit receives the Access Authority Packet and compute the session key KS. The CBC-MAC will be computed for the Access Authority Packet and verify with received CBC-MAC. If CBC-MAC is successful, Onboard KAVACH starts communi- cating the Onboard Regular Packet. d. Further, Onboard KAVACH shall continue transmission of Access Request Packet if it is in the block section. e. In station section, if the Onboard is registered with Stationary KA- VACH and continuous receipt of the regular packet, Onboard KA- VACH shall stop sending Access Request Packet in f0. f. The Stationary KAVACH shall send its regular packet and the com- munication with the registered Onboard KAVACH shall continue till the end of Stationary KAVACH communication mandatory area. g. When Stationary KAVACH receives the Onboard Regular Packet, it stops communicating the Access Authority message and initiates the Stationary regular packet & other packet transmission. h. Further, Stationary KAVACH and Onboard KAVACH units verify the CBC-MAC code for every message before processing. 16. Process Flow for Stationary entity KAVACH authentication: ========================================================= i. The primary partner shall send its ID and the random number in j. The secondary partner shall generate its random number after receiv- ing the request. k. The secondary partner shall generate MAC code based on random numbers. l. The secondary partners send its random number and MAC code in re- sponse to request received. The primary partner shall verify the re- ceived MAC . m. The primary partner after receipt of valid MAC, it shall start com- municating with the secondary partner. n. The session Key derived from this session shall be updated automati- cally on every update of Authentication key. o. The primary partner is TSRMS and Stationary KAVACH is second- ary partner. p. In Stationary KAVACH to adjacent Stationary KAVACH communi- cation, anyone can e thbe primary partner (configured in Stationary KAVACH data base). q. All KAVACH subsystems shall automatically update their session key when there is a change in Authentication Keys due to expiry of time validity or due to changse in input key set from user Railways. 35. CRC polynomial & Calculation Algorithm ====================================== o. **CCITT-32 BIT Polynomial**  \- 32 bit CCITT CRC Calculation Algorithm =============================================================   5. Full Supervision Movement Authority Handling Procedure (SIL-4) ============================================================== 17. If communication with Onboard KAVACH is lost for more than 6 seconds, Full Supervision Movement Authority shall be held by the Stationary KA- VACH unit until the frame offset cycle becomes maximum value. 18. Due to signal aspect transitions, Full Supervision Movement Authority shall be held by Stationary KAVACH for 2 seconds. 19. Other than these events, Full Supervision Movement Authority shall be up- dated as soon as information is available with the Stationary KAVACH. 20. Onboard KAVACH shall receive following information from Station- ary KAVACH =========================================================================== a. Aspect of the approaching signal on route. b. Approaching signal distance from the reference RFID. c. Approaching signal identity. d. Next signal aspect as defined in KAVACH table of control, if the sig- nal on approach is OFF. e. Movement authority Type and MA (the distance for which the train is authorized to travel). f. Train length Information. g. Track Profile (PSR, TSR, Tag Linking, LC gate & Track condition) 21. All the above is applicable for Onsight movement authority also except for special condition mentioned in FRS and OSMA will be Non SIL. 6. Determination of Speed (SIL-4) ============================== 22. Directional type Pulse generators with high reliability shall be used for speed sensing. 23. Each Pulse generator shall have at least two independent speed output channels. 24. Two Pulse generators shall be fitted on either side of the locomotive on dif- ferent axles preferably. 25. Each channel of the PGs is to be compared for determination of speed. 26. In case of detection of malfunction of speed determination exceeding speed sense time out or failure of a channel in a Pulse generator, the Onboard Ka- vach shall transit to System Failure Mode. The same shall be recorded in event logger and NMS alert is to be generated. 7. Direction (SIL-4) ================= 27. There shall be three types of direction of movements, one for train such as forward or reverse, second for traffic such as UP or DN or UPDOWN or UPFAST or DNFAST etc. and the other for movement of direction such as Nominal or Reverse. 28. On start-up or restart, the Onboard KAVACH unit shall assume the move- ment of direction as undefined. It shall be derived, when Loco/Train has passed two different sets of RFID tags. 29. The onboard KAVACH unit shall set its absolute location and TIN as unde- fined before determining the direction. 30. The direction of movement of the train shall be determined through RFID Tags data reported by same RFID readers. Tag data reported by different RFID readers shall not be used for determination of direction. 31. If Absolute location value is incrementing, it shall be treated as Nominal di- rection. If Absolute location value is decrementing, it shall be treated as Reverse direction. 32. The direction of movement of trains and TIN shall be used for determining whether two trains are approaching, one following the other or going away from each other with the exception in vicinity of Adjustment tag. 33. The direction of operation of Onboard KAVACH shall be determined based on the position of cab control. This direction shall be used for detecting Roll back/ Forward and Reverse movement. 34. The Stationary KAVACH unit shall use the direction of movement of Onboard KAVACH, to find an approaching signal of the Loco/Train. 8. Train Length Assignment (Non-SIL) ================================= 1. Every Stationary KAVACH unit shall monitor the status of track section identified for measurement of train length. Stationary KAVACH located at IB/LC/Auto Section are not required to carry out Train Length assessment. 2. The stationary KAVACH unit shall communicate the time of occupation and clear status of these track sections to every Onboard KAVACH unit. Onboard KAVACH unit, based on its odometer and the timings so received,  3. The train length so calculated by Onboard KAVACH unit shall be updated by replacing the previously stored train length under one or more of the fol- lowing conditions: a. If the previous train length was default train length; b. If the train length calculated by Onboard KAVACH differs from the previously stored train length by more than 25m (Configurable). 4. The accuracy of the train length measurement by Onboard KAVACH unit shall be within ± 25 meters. 5. The stationary KAVACH unit shall have provision of configuring the time correction offset from +1000 ms to -1000 ms with resolution 10 ms to com- pensate for delay, if any, in clear / occupied status of track sections due to track repeater relays. 6. The stationary KAVACH unit shall also have provision for configuring the maximum time period of occupation of track sections, to differentiate be- tween occupation by Train or by probable fault of track detection. If the oc- cupation period of these track sections is beyond the configured period of time, Stationary KAVACH unit shall abort transmission of the timings for calculation of train length. This time period limit for occupation would be configured as per characteristics of track section as provided by purchaser railway. Typically, in case of failure of AT & BT track circuits i.e. remain- ing occupied for more than 3 minutes (programmable from 0 to 10 minutes in step of 30 seconds), Stationary KAVACH unit shall not transmit packet & shall log it. 7. Two track circuit (say AT & BT in sequence in the traffic direction of train movement) at the entry to the block section shall be identified at each sta- tion for train length measurement. The track circuits identified shall be such that all the trains entering into a block section pass over these track circuits. Stationary KAVACH shall be able to handle Train length assignment for minimum 6 directions. 8. The status of these track circuits shall be taken as input to the Stationary KAVACH unit. 9. Stationary KAVACH, on establishing AT occupied & then BT occupied, shall communicate the time offset from the  an AT/BT boundary) & corrected time offset from the cleared over 10. Onboard KAVACH shall log its location at a resolution of better than 200 ms for the last 20 Seconds which shall be used by Onboard KAVACH for precise location for train length calculation.  9. Train location (SIL-4) ====================== 35. The onboard KAVACH unit shall compensate the location of the train with RFID mount distance, operating cab and direction of travel. 36. The functional Onboard KAVACH unit shall transmit the location of the train to the Stationary KAVACH unit every 2 seconds. 37. The onboard KAVACH unit shall transmit the position, speed and length of the train every 2 seconds to its CTC, when LTE is available. (F) 38. The onboard KAVACH unit shall transmit the event-based health packet to the NMS, when LTE is available. (F) 10. Track Profile supervision (SIL-4) ================================= 11. Track Conditions (Non-SIL) (F) ============================== 39. The Track Condition function is used to inform the loco pilot about special condition in front of the train. 40. There are two types of track condition profile type and location type. 41. The starting point of a profile type (P) or location type (L) track condition shall be evaluated considering the max safe front end of the train. 42. The end point of the profile type (P) or Location type (L) shall aconsider the min safe rear end the of the train for Non stopping area (P), Tunnel stopping area (P), Reversing area (P), fouling mark (L) and Kavach territo- ry exit (L). 43. The end point of other track conditions shall take into account the min safe front end of the train. 1. **Max Safe front end-** The maximum safe front end position differs from the es- timated position by the Under reading amount in the distance measured from the reference RFID tag plus the Location accuracy of the reference RFID tag. 2. **Min safe front end:** The minimum safe front end position differs from the es- timated position by the Over reading amount in the distance measured from the reference RFID tag plus the Location accuracy of the reference RFID tag. 3. **Min safe rear end:** It is the train length plus min safe front end of the train. 44. The following actions shall be performed once a track condition has been received: a. Indicate on DMI b. Supervision of track conditions by Onboard KAVACH. 45. The train is permitted to run without any track condition information given from the trackside. The default state shall then be used by the Onboard KAVACH. 12. Prevention of Signal Passing at Danger (SIL-4) ============================================== 46. In case of any conflict between signal aspect, point, position, berthing track section, signal aspect sequence and TIN, the Stationary KAVACH unit shall transmit most restrictive aspect of that signal and shall reduce the movement authority accordingly. 47. The stationary KAVACH unit shall check route information configured on the basis of the KAVACH Control Table of Stationary KAVACH. 48. The off aspect and Full Supervision movement authority for LSS shall be transmitted by Station/LC/ IB unit only when LSS is off, and it is ensured that the concerned Line Clear is available. -- -- -- -- -- -- -- -- -- --  13. Protection of Roll Back (Non-SIL) ================================= 49. The onboard KAVACH unit shall be capable of detecting Roll Back of the train through train interface. It shall apply brake and give audio/visual warning if the train has rolled back by more than 5 meters (configurable). 50. During roll back, movement authority and other target distances shall be in- cremented or decremented depending on the locomotive absolute position. 51. It shall be possible for the Loco Pilot to reverse the train, if the situation so warrants, by changing the mode of Onboard KAVACH 52. To protect a traction unit from roll away and unwanted reverse movements, the Onboard KAVACH shall monitor the direction of movement in relation to the permitted direction. 53. The roll away/reverse movement intervention shall be indicated on the LP- OCIP (DMI). 14. Prevention of Head on & Rear end Collisions (Non-SIL) ===================================================== 54. Onboard KAVACH units either directly or through the Stationary KA- VACH unit, shall be capable of detecting head on collisions, rear end colli- sions of trains/locos on a single line, multiple lines in all possible scenarios based on the track identification, the speed of the trains, train location, train length, train direction movement (Nominal/Reverse) etc. 55. In case of head on collision situation, Onboard KAVACH units of both the trains shall automatically apply brakes immediately with warning either in Absolute or in Automatic Block Section. 56. In case of a rear end collision situation, the Onboard KAVACH unit of only rear train shall automatically apply brakes to bring it to stop short of a stipu- lated distance (300m in block section, configurable) from the train ahead. There shall be no brake application in the train ahead on account of rear end collision situation. The rear end collision message shall be displayed with the details to the rear approaching Onboard KAVACH only. 57. When the speed of the Onboard KAVACH reaches Zero Kmph, the brakes shall be released. 58. As soon as the head-on collision or rear end collision, as the case may be, the situation is over, the application of brakes of the Onboard KAVACH unit shall be withdrawn. 59. In Station sections, the Stationary KAVACH shall prevent train collisions with the help of SPAD and TIN conflict. 60. In case two Onboard KAVACH units are detected by Stationary KAVACH moving towards each other on same TIN in block section in the communi- cation mandatory area, the SoS command would be generated by Stationary KAVACH for both. On reception of such Onboard KAVACH specific SoS 61. The target distance and permitted speed shall be displayed on DMI. 15. Auto whistling on approach of Level Crossing Gate (Non-SIL) =========================================================== 62. The feature of auto whistling on approach of level crossing gate is optional and Purchaser Railway shall decide for its incorporation. 63. The Onboard KAVACH shall display the level crossing gate information (Gate ID) on LP-OCIP (DMI), when the approach of LC Gate is detected through LC Gate Tags/ track profile received through radio. The format for displaying LC gate information is as follows: 64. The Onboard KAVACH unit shall blow the Loco horn at LC gate, based on the information received from the LC gate tag / track profile. Whenever in- formation regarding LC gate is available from both track profile and LC tag, Onboard KAVACH shall process the first input. 65. The Onboard KAVACH unit shall not blow the horn for LC gate, if move- ment authority is less than the LC gate distance from its current position. 66. The Onboard KAVACH shall not blow the horn for LC gate, if the loco is at standstill. 67. The Onboard KAVACH unit shall blow the horn for LC gate, on reading the tag, if MA information is not available. 68. The Onboard KAVACH unit shall not blow the horn for LC gate, when it is in Standby, Isolation, Non-Leading and System failure mode. 69. A continuous whistling shall commence from a distance of 600m on the ap- proach of LC Gate till the time that train reaches LC Gate. However, whis- tling pattern shall be configurable and shall be decided by the purchaser Railway in case pattern other than continuous whistling is required. 70. It shall be possible to cancel the auto-whistling by pressing Common /Ack button alone. 71. The Interface details for auto-whistling shall be provided by the Purchaser. 16. Track Identification Number (Non SIL) ===================================== 72. Each track shall have a designated Track Identification Number (TIN). 73. Each Block section shall have a single unique designated TIN. Block Sec- tion TIN can be repeated after a designated distance (50 km minimum along the track route). 74. To avoid unnecessary SOS generation, adjacent TINs to be incorporated in the radio packet and adjacent line tag. Adjacent line info data is to be com- municated over the radio only after physical separation of tracks. 75. Each line in the station section having berthing portion shall have different TINs. Station section TIN can be repeated after a designated distance (10 km minimum along the track route) 76. TINs shall be allotted in such a manner not to restrict permissible simulta- neous movements. 77. The onboard KAVACH unit shall be able to self-deduce the change in its TIN whenever it changes the TIN section. 78. There shall be no case of assignment or deduction of wrong TIN by Onboard KAVACH unit on reading the RFID tag. 17. Radio Communication Arrangement =============================== 79. Station/ IB/ Gate KAVACH unit as well as an Onboard KAVACH unit shall have hot standby radio for higher availability. 80. **Initiating a Radio Communication:** The Onboard KAVACH unit shall commence transmission of the Radio packet to the Stationary KAVACH unit: 36. While the start of mission in KAVACH communication mandatory ar- ea & while entering the from non KAVACH area to KAVACH com- munication mandatory area. ======================================================================================================================================================= 1. On reading RFID Tag, Onboard KAVACH shall display the message 2. Prior to the determination of the direction, Onboard Kavach shall transmit Absolute location as read from the Tag, direction as undefined, TIN as zero, and RFID tag read. 3. After establishing the direction, the Onboard KAVACH unit shall com- mence transmission of absolute location and TIN as per the direction on the basis of data read from RFID Tag through Access Request Packet. When- ever Onboard KAVACH unit tries to establish communication with a new Stationary unit for the first time, it shall do so by Random Access Method within the time slots reserved for this purpose on frequency f0. 4. Subsequently, Stationary KAVACH shall register the Onboard KAVACH. 37. While entering to KAVACH communication mandatory area from non communication mandatory area: ============================================================================================ 1. Onboard KAVACH determines that it has entered a communication manda- tory area based on the information received from RFID Tag. 2. On entering a communication mandatory area in the vicinity of Stationary -- -- -- -- -- -- -- -- -- --  3. On reception of Access Request Packet from Onboard KAVACH Unit, Sta- tionary KAVACH unit generates its own Random Number (RS) and com- putes the session key KS and transmits the Access Authority Packet in f0 frequency with CBC-MAC code. Access Authority Packet contains fre- quency, Timeslot and Random Number RS. 4. The onboard KAVACH unit receives the Access Authority Packet and compute the session key KS. The CBC-MAC will be computed for the Ac- cess Authority Packet and verify with received CBC-MAC. If CBC-MAC is successful, Onboard KAVACH starts communicating the Onboard Regular Packet. 5. When Stationary KAVACH receives the Onboard Regular Packet, it stops communicating the Access Authority Packet and initiates the Stationary regular packet & other packet transmission. 6. Further, Stationary KAVACH and Onboard KAVACH units verify the CBC-MAC code for every message before processing. 81. The Stationary KAVACH unit shall transmit the Access Authority Packet in f0 to the Onboard KAVACH unit, if it receives the Access Request Pack- et from Onboard KAVACH unit with valid Absolute location and direction. 82. Once, the Onboard KAVACH unit receives an Access Authority Packet from Stationary KAVACH unit, the Onboard KAVACH unit shall send its regular packet in the frequency channel and time slot as specified in the Ac- cess Authority Packet sent by Stationary KAVACH. Further, Onboard KAVACH shall continue transmission of Access Request Packet if it is in the block section. 83. The Stationary KAVACH shall send its regular packet and the communica- tion with the registered Onboard KAVACH shall continue till the end of Stationary KAVACH communication mandatory area. 84. In the station section, if the Onboard KAVACH is registered with Station- ary KAVACH and on continuous receipt of the regular packet, Onboard KAVACH shall stop sending Access Request Packet in f0. 85. If the registered Onboard KAVACH does not receive the Stationary KA- VACH regular packet for beyond time out, the Onboard KAVACH shall send Access Request Packet in f0 in the station section also. 86. The Manual SOS and Unusual stoppage messages shall be transmitted by Onboard KAVACH unit as and when required, on frequency (f0). 87. The Onboard KAVACH and the Stationary KAVACH shall not interfere mutually while transmitting on frequency f0.  88. **Terminating a Radio Communication:** The Stationary KAVACH shall stop communication with the Onboard KAVACH unit, when one of the fol- lowing conditions occurs Onboard KAVACH unit. a. When the Onboard KAVACH unit moves beyond the Last Stop Sig- nal of the Stationary KAVACH Unit as per communication mandato- ry, are configured (typically 1.5km from Last Stop Signal of Station- ary KAVACH in Absolute Block Section and u pto a distance of train length beyond border tag in Automatic Block Section) b. If the direction is invalid. c. No radio packet is received from the Onboard KAVACH for more than 60 cycles (Configurable) in station section / Absolute Block Sec- tion & 15 cycle (Configurable) in Automatic Block Section. 89. The radio frame cycle refresh rate shall be 2 seconds for the Stationary KAVACH. 90. If a packet having a source frame number prior to that of any other packets processed by a KAVACH unit, the same shall be discarded by the KA- VACH unit for the purpose of the operation. However, such packet shall be forwarded to NMS by the Stationary KAVACH. 91. In case there is no gap between the Communication Mandatory area of two adjacent Stationary KAVACH the procedure defined in **Annexure-P** to be followed. 92. Frame Offset cycle calculation by the Stationary KAVACH unit ============================================================ 38. This clause describes how the Stationary KAVACH unit prepares the 39. The stationary KAVACH unit calculates the frame offset cycle based on the frame number received in the Onboard KAVACH packet.  40. Depending on the Time slots allocated for the Stationary and the Onboard KAVACH units as per the multiple access protocol, the frame offset cycle will be zero or one. 41. Case 1: Frame Offset cycle = Zero =================================  Case 2: Frame Offset cycle = One ================================ Case 2(a): The Onboard KAVACH Packet received after Stationary KAVACH unit Time Slot ====================================================================================  44. **Case 2 (b): The Onboard KAVACH packet received within 150ms- 200ms prior to the Stationary KAVACH time slot.** 18. Connectivity of Stationary KAVACH unit with interlocking. ========================================================= 93. The Stationary KAVACH unit shall be capable of taking potential free inputs  94. When the Stationary KAVACH interfaces with EI directly, there is no need of Vital Input Cards. However, a minimum of two vital input cards shall be supplied along with each such Stationary KAVACH for connecting other hardwired field inputs. 95. The status of track circuits nominated for computing the train length meas- urement shall be read through Vital Input Cards only. If these relay statuses are read through Remote Interface Units, the delays are to be accounted for, by the Stationary KAVACH. 96. The capacity of the Stationary KAVACH shall be restricted to 70% of its 97. The break status of potential free contact shall indicate absence of input. 98. Signal aspect status, position of points, berthing track circuit status, status of track circuits nominated for computing train length, status of the block in- strument Line Closed condition shall be interfaced to Stationary KAVACH. 99. The IBS & Gate unit shall not require inputs for point position, track circuits nominated for computing train length & berthing track circuit status. The gate unit shall not require input for status of the block instrument Line Closed condition. 100. The movement authority shall be held by Stationary KAVACH for a period of 2 second (minimum) to 5 seconds (maximum) in case of flickering of sig- nal. Further a provision to adjust this duration in multiples of 100 m sec is to be made available. 19. Other Requirements ================== 101. In case of more than one situations/ scenario existing at the same time, the Onboard KAVACH unit shall take action as per the most restrictive situation/ scenario. 102. The Onboard KAVACH unit shall make speed profile/ brake curve for dif- ferent situations based on movement authority, speed restriction and other in- formation as received from the Stationary KAVACH unit or other Onboard KAVACH unit. 103. The Onboard KAVACH unit shall take action as per the most restricted speed profile/ brake curve at any point of time.  104. Once a situation is detected by the Onboard KAVACH unit based on the in- formation received by it, which warrants application of brake & further up- date of information is not available, the action for brake application shall be initiated or continued if already initiated as per the brake curve at the time re- ceipt of last information. Further update of the brake curve shall be done only after start of receipt of further information. 105. The RFID tag sequence (shall include Gate tags if available) received from the Stationary KAVACH shall be verified for their availability and send the information to NMS over commercial GSM/LTE in case of missing tags. 106. The RFID tag sequence received from Stationary KAVACH shall be validat- ed by the Onboard KAVACH and the Onboard KAVACH shall apply brakes in case of reading an unexpected tag (except for gate tags). In case of Tag missing, the brakes shall not be applied. 20. Failures and fallback Procedures ================================ 107. **Radio communication failures:** 45. A radio communication failure shall be deemed to have occurred when 30 seconds (configurable) for Absolute Block Section and 10 seconds (configu- rable) for Automatic Block Section have passed since the last packet received from Stationary KAVACH in the communication mandatory area. 46. If the last packet received from Stationary KAVACH is more than 6 seconds older, the signal aspect and signal description shall be made blank. However, the Onboard KAVACH shall continue to function in Full Supervision mode and shall supervise the Full Supervision Movement Authority received in lat- est packet till the commencement of brake in the current route section. 47. In the event of a Radio Communication failure longer than applicable time- out, the Onboard KAVACH unit shall transit to degraded mode as specified in mode transition table and shall seek acknowledge from Loco Pilot. If Loco Pilot does not acknowledge within stipulated time of 15 seconds (Configura- ble), Onboard KAVACH shall apply the brake. In addition, it shall send the message to Network Monitoring System through commercial GSM/LTE. Stationary KAVACH shall send the Fault message to Network Monitoring System through Ethernet/GSM/ commercial LTE interface. 48. In the event of a failure of only one radio when other radio is providing radio communication in hot standby, the Onboard KAVACH unit should log the fault. The Onboard KAVACH unit shall also send the message to Network Monitoring System through GSM/ commercial LTE. The Stationary KA- VACH unit shall send the Fault message to Network Monitoring System. The system shall be functional with one radio. 108. RFID Reader failures: ===================== 49. In the event of an RFID reader failure (both readers), the Onboard KA- VACH unit should stop radio communication and shall switch to System Failure mode. Fault shall be logged. In addition, it shall send the message to  50. In the event of any one RFID reader failure, the Onboard KAVACH unit should log the event. In addition, it shall send the message to Network Monitoring System through GSM/commercial LTE. A system shall be functional with one RFID reader. 109. GPS/GNSS failure (F) ==================== 51. **When the Aerial View is available:** Incremental difference between the CPU time and GPS time is to be cross checked. If the incremental differ- ence between CPU and GPS time is not matched, the time reference shall change to other GPS. If the difference between two GPS is greater than the frame interval, a message shall be sent to the NMS. 52. Diverse make of GPS is preferable to avoid common cause failures. 53. In the event of failure of both GPS/GNSS and Real Time Clock (RTC), the Onboard KAVACH unit shall stop radio communication and shall switch to System Failure mode. In addition, it shall send the message to Network Monitoring System through commercial GSM/LTE. 54. In the event of failure of both GPS/GNSS and RTC, Stationary KAVACH unit should stop radio communication and shall switch to System Failure mode. Fault message shall be communicated to Network Monitoring Sys- tem through an Ethernet interface. In addition, it shall send the message to Network Monitoring System either through Ethernet or commercial GSM. 55. If the incremental difference is also not matching with second GPS or both systems are failing, then the system shall work on CPU time for 30 minutes, (default, Min:10, Max:60) until the situation is stabilized. If there is no sta- bility after GPS time-out, the Loco shall transit out of FS Mode to SR mode. The following message shall be displayed on LP OCIP. Ack SR mode- GPS Fail. +---------+---------+---------+---------+---------+---------+---------+ | | | | | | **GPS | | | | | | | | Selecti | | | | | | | | on** | | +=========+=========+=========+=========+=========+=========+=========+ | | 0 | x | x | x | a. b. | | | | | | | | | | +---------+---------+---------+---------+---------+---------+---------+ | | 1 | x | 0 | x | System | | | | | | | | failure | | +---------+---------+---------+---------+---------+---------+---------+ | | 1 | x | 1 | x | | | +---------+---------+---------+---------+---------+---------+---------+ | | 0 | 0 | x | x | System | | | | | | | | failure | | +---------+---------+---------+---------+---------+---------+---------+ | | 0 | 1 | x | x | | | +---------+---------+---------+---------+---------+---------+---------+ | | 1 | 0 | 0 | x | System | | | | | | | | failure | | +---------+---------+---------+---------+---------+---------+---------+ **GPS Selection** -- --- --- --- --- ------------------- -- 1 0 1 x 1 1 0 x 1 1 1 0 1 1 1 1 LP-OCIP (DMI) communication failures: ===================================== a. In the event of Active Cab/Desk LP-OCIP (DMI) communication failure, the Onboard KAVACH unit shall switch to System failure mode. In ad- dition, it shall send the message to Network Monitoring System through GSM/ Commercial LTE. b. In the event of Non-Active Cab/Desk LP-OCIP (DMI) communication failure, the Onboard KAVACH unit shall log the fault. In addition, it shall send the message to Network Monitoring System through GSM/ Commercial LTE. 111. Pulse Generator (PG) Failure: ============================= 56. A pulse generator failure shall be deemed to have occurred when the differ- ence of the speed detected by both the PG is more than 5 Kmph (Configu- rable) for a frame cycle time. 57. Onboard KAVACH shall transit to system failure mode. The Onboard KA- VACH unit shall log the fault. In addition, it shall send the message to Network Monitoring System through Commercial GSM/ LTE. 112. Brake Interface Failure: ======================== 58. If there are failures of brake interface such as pressure feed back fail or traction cut off feed back fail, etc. which compromise the safety of train su- pervision, the Onboard KAVACH shall switch to system failure mode**.** 59. The Onboard KAVACH unit shall log the fault. In addition, it shall send the message to Network Monitoring System through Commercial GSM/ LTE. 113. Odometry error: =============== 60. Stationary KAVACH shall generate Onboard-specific SOS when it deter- 8. Communication fails with TSRMS or adjacent Stationary Kavach or Electronic Interlocking: ======================================================================================== 1. Stationary KAVACH shall extend **SR Authorization** to Onboard Kavach when the communication fails with TSRMS or adjacent Stationary Kavach or Electronic Interlocking. On recovery of the link, Stationary Kavach shall extend Onsight Movement Authority. 21. Logging of events ================= 114. Logging of events shall be done with date, time and location stamp. 115. Time reference for the entire KAVACH network should be synchronized. Logging shall be done every two seconds. In addition, logging shall also be done based on the occurrence of certain events. 116. Following events related to dangerous situations shall be logged along with date, time and location stamp in the Stationary and the Onboard KAVACH units. a. Signal Passing at Danger b. Head On Collision c. Rear End Collision d. All SoS messages e. Train Trip f. Unusual stoppage g. Loco Pilot Alert Messages on LP-OCIP (DMI) h. Roll back 117. Following the events of failures/abnormal/ Specific conditions and their recov- ery shall be logged along with the date, time and location stamp in relevant KAVACH. a. Communication failure of Onboard KAVACH/ Adjacent Stationary KAVACH/TSR Management System/ Electronic Interlocking. b. Input failures wherever applicable c. Failure of KAVACH unit due to any reason shall be logged in the Network Monitoring System. d. Brake interface unit isolation e. All types of Brake application actuated by KAVACH unit with dura- tion, speed & distance measurements f. Restart of KAVACH unit due to any reason g. All failure messages -- -- -- -- -- -- -- -- -- --  h. Non-Leading Mode i. Train Length Assignment/measurement j. Mode Transition k. MBT l. Every RFID tag 118. The following information shall be logged every two seconds or based o then occurrence of certain events: -- -- -- -- -- -- 119. The following events shall trigger the logging: a. In Onboard KAVACH unit event logger: i. Update of Movement Authority ii. Initiation of br