loconav.com

loconav.com

Amendment No. 2 (5th December 2018) To AIS-140: Intelligent Transportation Systems (ITS) Requirements for Public Transport Vehicle Operation 1. Page 3, Clause No 2.2.1, Substitute following text for existing text: Device Approval: Approval provided at Device level for compliance to this standard. These approved devices can be fitted / retro-fitted by manufacturer/ dealer/ permit holder/system integrator in any vehicle model provided it shall meet installation requirements as mentioned in Clause No. 5 of this standard. 2. Page 4 , First paragraph Substitute following text for existing text: Table below (Table 4A) contains the listing of fields that the vehicle tracking devices would be required to send to the Backend Control Centre. The first 3 fields (Start character, Header for VLT with Emergency Buttons and Vendor ID, who has supplied the device) must be fixed in position as well as format (Header part of frame). Rest all other fields are required to be present in the location data sent by the devices to the backend, but can be in any sequence and with any separator between fields. The data value can be either in American Standard Code for Information Interchange (ASCII) or in HEX format. Device must transmit the Login message whenever it establishes (re-establishes after disconnection) its connectivity with Server with the specified fields. Login Message will carry following information: 3. Page 5, Clause 3.1.1.1, Sub clause a a. shall be capable operating SubstituteDevice the following text for the for existing text: in L and/or S band and include support for NAVIC/IRNSS (Indian Regional Navigation Satellite System) for devices installed on vehicles on or after 1st April 2019. However VLT devices shall be compliant as per other GNSS constellation in the interim period. 4. Page 16, Clause 5.0 Substitute following text for existing text: CONSTRUCTION AND INSTALLATION Page 1 of 15 5. Page 16, Clause 5.1 Substitute the following test for the existing text: Requirements on vehicle interface for VLT with Emergency Button (This requirement is only a guideline for fitment and shall not be checked during component approval or on vehicle) Connector for Power The requirements for interface shall be as agreed between vehicle manufacturer and device manufacturer 6. Page 16, Clause 5.2 Substitute the following test for the existing text: Requirement of Emergency System (To be verified on component level) Emergency button shall be one time press type. Separate release action from authorized server shall be required to bring back the emergency button to normal mode or clear emergency flag. 7. Page 16, Clause 5.3 Substitute the following text for the existing text:

Physical Mounting (This requirement is only a guideline for fitment and shall not be checked during component approval or on vehicle) The VLT system shall be mounted in a suitable location such a way that it is not easily accessible /exposed to passengers. This requirement shall not be applicable in case of combined systems VLT with HMI (Human Machine Interface) display in front of driver. Emergency button(s) shall be fitted in such a way that every passenger including driver shall be able to access the Emergency button(s). Passenger Car shall have at least one emergency buttons on each passenger row easily accessible by each of the passenger. There shall also be one dedicated emergency button for the driver row. Passenger Transport bus shall have emergency buttons at locations easily visible & accessible to all the passengers such as every 2 meters on both the sides on passenger seating area. For seats reserved for ladies there shall be a dedicated panic button for each row. Page 2 of 15 It shall be permissible to have a single emergency button for two successive ladies rows on both sides of the vehicle provided each lady passenger in either rows are able to reach and operate the emergency button. In case of passenger transport bus which has a glass window covered between two pillars having pitch 2m or more, the emergency buttons shall be provided on each pillar National Permit Trucks, shall have one dedicated emergency button for the driver row. 8. Page 17, Clause 5.4 Substitute the following test for the existing text: Power Supply (The requirements related to vehicle are only a guideline for fitment and shall not be checked during component approval or on vehicle) The vehicle tracking device will be installed on vehicles in which the power supply voltage from vehicle battery is widely varying (12V, 24V etc.) and also the power supply is not as stable as that in case of fixed locations, especially during engine start-up and braking when the voltage can fall to as low as 9V. Typically electronic devices are very sensitive to power surges and spikes, and equipment may fail if they do not receive stable power supply. The devices will need to have a resilient power supply unit that can withstand such fluctuations and the devices also need to have power backup so that they continue to function for some duration when the vehicle battery is not functional or is disconnected from the devices. Vehicle power interface shall have One common ground linked to vehicle chassis One permanent power Supply (12/24V) connected to the vehicle battery (+Vbat). One non-permanent power line (12/24V) connect to the battery after ignition (IGN). 9. Page 17, Clause No 6.1, 6.1.1, 6.1.2 Delete these clauses and renumber subsequent clauses. 10. Page 18, Clause No 6.2.1.3 Substitute following text for existing text: The system shall transmit Emergency request information to one IP and PVT information to other IP of backend Control Center at user configurable frequency (minimum 5 seconds) via GSM/Cellular 11. Page 18 Page 3 of 15 Add following new clause 6.2.1.6 and 6.2.1.7 after clause 6.2.1.5 : 6. 12. System shall communicate to control center on the occurrence of the alerts captured in Communication Protocol Section 4. 7. When Emergency Button is pressed, emergency request message shall be sent from the system and received at the control center.

Page 31 ,Clause No 7.0 Add Below Text at the end of first paragraph The Communication from Device to backend should happen on a Secure channel over TCPIP protocol preferably on socket based connections where sessions are managed to send commands over the same connection to the device and are authenticated, identifiable, so as to prevent spoofing on IMEI/ Unique ID. 13. Page 33 Add following new clause 8.0 after clause 7.0: 1. CODE OF PRACTICE for Implementation of Vehicle Location Tracking (VLT) Device, Emergency Button(s) and Command and Control Centres This Code of Practice for AIS-140 has been formulated for facilitating smooth Implementation of Vehicle Location Tracking (VLT) Device, Emergency Button(s) and Command and Control Centres for the guidance of the stakeholders concerned. 2. General a. The VLT device manufacturers will get their devices tested and certified from the testing agencies referred to in rule 126 of the CMVR for compliance to the rule 125 H of CMVR b. The Backend System shall mean the backend Command and Control Centre set up/ authorized by State/UT or VLT manufacturers, providing interface to various stakeholders/systems such as State emergency response centre, the transport department or Regional Transport Offices, Ministry of Road Transport and Highways and its designated agency, Vahan (or any other State/UT system used for registration of vehicles and/or issuance of permits), VLT device manufacturers and their authorised dealers, testing agencies, permit holders, etc. In the absence of State/UT backend system, the registration, activation, health check and alert updates of VLT devices shall be through a common layer for updation in Vahan. The details of each VLT device (VLT device manufacturer code, device serial number, IMEI number, IccID number and other details as notified by the Central Government/State Government) shall be uploaded on the Vahan directly or through backend system by the VLT device manufacturer using its secure authenticated access. The VLT device manufacturers or their authorised dealers shall install the VLT devices in vehicles and register/activate the devices along with details Page 4 of 15 of vehicle and permit holder on the corresponding backend systems in real- time as per the process set out below. The backend system/common layer will update the details of device in the Vahan system against the respective vehicle record at the time of installation and registration/activation of VLT device. c. The VLT device manufacturers or their authorised dealers, at the time of installation of VLT device in vehicles, shall configure the IP address and SMS gateway details in the device for sending emergency alerts to the emergency response system of the State/UT concerned. d. The VLT device manufacturers or their authorised dealers, at the time of installation of VLT device in vehicles, shall configure the configuration parameters mentioned in AIS-140 in the device such as IP address and SMS gateway details for sending required data to the backend system. e. The VLT device manufacturers shall ensure that a control mechanism is established for the secure data transfer from VLT to the backend system and that only the authorized devices transfer data to the backend system. The VLT device manufacturers shall also ensure that the mechanism for authenticating the vehicle owner and devices is followed as per the protocol specified in AIS-140 or such additional requirements as specified by the States/UTs. Authentication of vehicle shall be done through an OTP sent on vehicle owners mobile number from the corresponding backend system. f. g.

h. i. j k. In case of press of an emergency button, the VLT device will send data directly to the emergency response system of the respective State/UT. In addition, the backend system will send the alert to the respective permit holder, as decided by the State/UT. VLT device manufacturers shall get their devices tested for conformity of production every year from the date of first certification, from the testing agencies referred to in rule 126 of the CMVR. VLT device manufacturers shall get their backend systems certified for the States/UTs from the testing agencies referred to in rule 126 of the CMVR/ STQC/NIC. The VLT device manufacturers or their authorised dealers, at the time of installation of VLT devices in vehicles, shall configure the VLT device to send a secure authenticated activation message directly to the State/UT backend system/common layer as per the details provided in this section 8 The VLT device manufacturers shall ensure that the Health Check parameters are configured in the VLT device to send Health Check messages, on request from the State/UT backend system/common layer, to the respective backend system through SMS as per reference protocol mentioned in this section 8 VLT device manufacturers or their authorised dealers shall provide comprehensive warranty/maintenance support for the VLT device and facilitate cellular connectivity in accordance with the guidelines issued by Page 5 of 15 central government vide Motor Vehicles (Vehicle Location Tracking Device and Emergency Button) Order, 2018 as amended from time to time. l. The testing agencies will verify the conformity of production for the VLT devices as prescribed in section 8.5. 8.2 Installation, Registration, Activation and Service Process for VLT Device a. VLT device manufacturers or their authorised dealers shall install VLT devices on permit holders vehicles (only tested and approved model). b. VLT device manufacturers shall ensure necessary uploading/integration of the installation/activation data to the backend system/Vahan. c. In case of any problem in updating Vahan, it will be VLT device manufacturers responsibility to resolve the same. d. VLT device manufacturers or their authorised dealers will also provide necessary print of installation/activation report to permit holder from the respective backend system. e. Regional Transport Offices shall be able to verify registration/activation/functional status of the VLT device Vahan/corresponding backend system at the time in of fitness thetesting. f. The permit holder will have option to check the installation and device working status in the Vahan. g.

The VLT device manufacture may offer value added services, in addition to the mandatory performance requirements to the permit holders as per the mutual agreement between them. Mandatory performance requirements shall mean the following: i. Uploading device data in Vahan ii. Updating registration and activation data of VLT device iii. Sending device health status to the backend system iv. Sending emergency alerts to the corresponding State/UT emergency response system v. Sending over speeding alerts to the backend system vi. Other performance requirements as per AIS 140 and as notified by central government vide Motor Vehicles (Vehicle Location Tracking Device and Emergency Button) Order, 2018 as amended from time to time. Page 6 of 15 h. The VLT device manufacturers may create their own system to monitor their supplied devices, emergency button/s & connectivity working / nonworking status for managing warrantee / AMC and Cellular services. i. The VLT device manufacturers or their dealers will update the SIM numbers and their validity/renewal details in the backend system. 8.3 VLT Device Manufacturers Backend Application/System Requirements In case VLT device manufacturer offers to provide its backend system for State/UT, the same will need to meet the following requirements, in addition to those specified in Clause 7 of AIS 140: a) The application will provide the ability to locate a vehicle at a given time. b) Facility to track defined vs. actual movement of vehicles, capture deviations if any. (For vehicles where scheduled movement can be defined on GIS map) c) The application should provide ability to track vehicle location on map. The map engine and data should comply with applicable regulations including guidelines as set out by Survey of India from time to time. d) Facility for users to access and view position / location information on GIS maps near real-time through web interface with historic data displayed on maps. e) Facility for providing current information location on demand. f) Facility for playing back the recorded details of the vehicle movement along the authorized route (where applicable). g)

Provide facility of alert generation i. Ability to define new alerts on specific events ii. From the on-board devices in case of tampering iii. Speed exceeds the permissible limit iv. Vehicle moves out of its designated route or area v. Data feed not received from the on-board device h) Provide facility to define rules for alerts/ notification and their delivery mode like SMS, email, pop-up etc. i) Management of notifications to various stakeholders by way of email or SMS e.g. permit holders, RTO about device not working, over-speed etc. j) Notification to the permit-holder through SMS in case any device stops functioning/sending data to the application. Page 7 of 15 k) Capability to update the on-board devices firmware from the backend. l) Capability to configure on-board device parameters from the backend. m) The tracking data will be kept live in the system for at least 90 days. Utilities will be provided to support archive and restore functions for older data. Alerts/reporting shall be available for one year in the backend. n) The backend will store VTS time-related data at the same resolution as received in the live application. The archived data after 90 days can also be restored using utilities provided. o) From a security perspective, the devices will not communicate to any IP address located outside India whether it be the manufacturers application or for purposes of configuration or firmware updates. p) Firmware of the device needs to be available for auditing to notified testing agencies. Firmware binary should be made available with version matching one in the device as well as binary size & modification timestamp and/ or checksum should match for the binary provided and one installed on device. Backend System should be able to remotely read the existing version number of the firmware via an OTA configuration read command. A new version of the firmware should be pushed over the air from the VLT manufacturers application. This shall be verified by the backend system remotely reading the new version number of the firmware in the device via and OTA configuration read command. q) The device will communicate only to whitelisted set of IP addresses located in India and will receive communication and commands also

from whitelisted set of IP addresses located in India. r) The application and all key components like device management, firmware control, GIS map shall be hosted at a data centre/ cloud in India and it will be available for auditing by regulatory agencies. s) The system shall provide > 99% availability and adhere to Infrastructure Security, Vulnerability Assessment and Penetration Testing guidelines as set out by Ministry of Electronics, Information and Technology, GoI. t) No data should flow out of the country under any circumstances in compliance with applicable laws/regulations/guidelines. u) The common layer shall be got tested from the testing agencies specified in CMVR Rule 126/STQC/NIC for the following minimum functionalities: i. Registration and activation of the device(s) fitted on the vehicle, including the details of vehicle registration number, engine number, chassis number, vehicle make and model, device make and model, and connectivity details (telecom service providers name, ICCid, SIM Nos., IMSI, date of validity, etc.). Page 8 of 15 ii. Publish VLT device details in the Vahan/ any other State/UT system used for registration of vehicles and/or issuance of permits iii. Re-registration/re-activation of the device(s) fitted on the vehicle in case of any change in device or telecom service provider, etc. iv. Periodic health check of the device(s) fitted on the vehicle through SMS, as per section 8.4. v. Receiving alerts from VLT devices in case of defined deviations by vehicle such as over-speeding, etc. Publish alerts and health check received from VLT device in the Vahan/ any other State/UT system used for registration of vehicles and/or issuance of permits. vi. Provide interface to Vahan, respective State/UTs, RTOs, testing agencies, VLT device manufacturers and their dealers. 8.4 Activation message and Health Check Message Protocol The protocols for activation message and health check message are given below. Device shall send the activation and health check messages on request as specified below directly to the backend system (i.e. backend Command and Control Centre set up/ authorized by State/UT or a Common Layer system providing interface to VLT device manufacturers backend applications). A. Activation SMS Format from Backend System to Device For completion of the installation process, the VLT device shall undergo Activation process as per below: Activation Message Request Format from the Backend System to the Device (Through SMS): ACTV, Random Code, Reply SMS Gateway no. Activation Message Reply Format from Device to the Backend System (Through SMS) as per Table 1 below: Table-1: Activation & Health Check Response SMS Format from Device to Backend System Characters Activation Example Health Check Example

Header 5 ACTVR HCHKR Separator 1 , , Random code 6 343434 474747 Field Name Page 9 of 15 Separator 1 , , Vendor ID 4 Separator 1 , , Firmware version 6 V1.6.1 V1.6.1 Separator 1 , , IMEI 15 012345678912345 012345678912345 Separator 1 , , Alert ID

2 1 1 Separator 1 , , Latitude 12 14.034533 14.034533 Separator 1 , , direction 1 N N Separator 1 , , Longitude 12 79.32045 79.32045 Separator 1 , , Direction 1 E E Separator 1 , , GPS fix

1 1 1 Separator 1 , , Date and Time 15 16112018 120317 16112018 120317 Separator 1 , , Heading 6 263.19 263.19 Separator 1 , , Speed 4 25.4 25.4 Separator 1 , , GSM Strength 2 23 23 Separator 1 , , Country Code (MCC)

3 404 404 Separator 1 , , Network Code (MNC) 4 10 10 Separator 1 , , LAC 4 d6d6 d6d6 Separator 1 , , Main Power 1 1 1 Separator 1 , , IGN Status 1 1 1 Separator 1 , , Page 10 of 15

Battery Voltage 4 24.6 24.6 Separator 1 , , Frame Number 6 100000 100000 Separator 1 , , Vehicle mode 2 ID ID Total Characters 139 B.Health Check Random Messages from Backend System to Device Frequency: Twice Daily (Recommended), Health Check Message Request Format from the Backend System to the Device (Through SMS): HCHK, Random Generated ID, Reply SMS Gateway no. Health Check Message Reply Format from Device to Backend System (Through SMS): As per Table 1 above. C.Publish Data to Common Layer by VLT Device Manufacturers Applications (Sample) Requirement to be complied with by VLT device manufacturers applications Application shall publish the data to common layer in a specified frequency and format as mentioned below Services to publish data to the common layer a. Push Offence Details Type REST web service Data Type JSON Array Frequency 1 Hour A single request may contain JSON Array of maximum 500 JSON Objects of the following format. Sl No Key Value Length in bytes Description

In Parameters 1. oftyp 2 Offence Type OS= Overspeed 2. vno 16 Vehicle number without any delimiter like hyphen (-) or space. 3. imei 15 IMEI number. 4. date 8 Date in format DDMMYYYY 5. time 6 UTC in format hhmmss Page 11 of 15 6. lat 12 Latitude,decimal not less than 6 places 7. latd 1 Latitude Direction. N=North, S= South 8. lon 12 Longitude,decimal not less than 6 places 9. lond 1 Longitude Direction. E=East, W= West

10. spd 6 Speed in km/hrs, Upto One Decimal Value. 11. loc Location (Reverse Geo-coded) 12. rto RTO Code state 13. Response State Code resp OK/ Error 14. b. Push Alert Details Type REST web service Data Type JSON Array Frequency 1 Hour A single request may contain JSON Array of maximum 500 JSON Objects of the following format. Sl No Key Value Length in bytes Description In Parameters 1. alrtid 2 Alert ID as per AIS-140 2. vno 16 Vehicle number without any delimiter like hyphen (-) or space. 3. imei 15

IMEI number. 4. date 8 Date in format DDMMYYYY 5. time 6 UTC in format hhmmss 6. lat 12 Latitude,decimal not less than 6 places 7. latd 1 Latitude Direction. N=North, S= South 8. lon 12 Longitude,decimal not less than 6 places Page 12 of 15 9. lond 1 Longitude Direction. E=East, W= West 10. spd 6 Speed in km/hrs, Upto One Decimal Value. 11. loc Location (Reverse Geo-coded) 12. rto RTO Code state 13.

Response State Code resp OK/ Error 14. 8.5 Conformity of Production - Testing Parameters a. The VLT device manufacturers will get their devices tested and certified for conformity of production from the testing agencies referred to in rule 126 of the CMVR for compliance to the rule 125 H of CMVR every year from the date of first certification. The parameters for testing shall be as specified in Table 1 of this section. b. The VLT device manufacturers shall get their backend applications audited from the testing agencies referred to in rule 126 of the CMVR/STQC/NIC or by the agencies specified by States/UTs every year from the date of first certification. The parameters for auditing shall be as specified in Table 2 of this annexure. c. The testing agencies shall provide the details of the VLT devices and backend applications certified by them to the States/UTs by uploading the same on the respective backend systems or any other means. Table 1: Test for COP of VLT Device and Emergency Buttons Sl. No. Test Details (As per AIS-140) 1. Emergency button functionality (Clause No. 3.1.2.4) 2. SMS fall back (Clause 3.1.5) 3. Table 6A: Functional Testing (Sr. No. 1-9, Clause 6.3.1) 4. Performance Parametric Test of Table 6B (Clause 6.3.2, Sr. No.10) 5. Protocol & alerts verification as per -Clause No 4.1 and Table no 4A, -Clause No 4.2 and Table no 4B, 4C -Clause No 3.1.4 & Table no 3B - OTA Commands verification 6. Ingress Protection (IP) Test as per Sr. No. 3 of Table 6B Page 13 of 15 Table 2: Test Parameters for Auditing of VLT Device Manufacturers Backend Application/System Sl. No. 1. 2. Application availability test to be conducted over a 7 days period by periodic check of availability randomly or at specified intervals in an automated or manual manner.

3. Test functionality of application to allow user to map & un-map a device to a vehicle. 4. Test functionality to track a vehicle on a map over a period of 8 hours given either a device ID or vehicle registration number. The device ID and vehicle should be mapped beforehand. 5. Test replay of a vehicles location by specifying a start and end date and time and device ID or vehicle registration number. The start and end date and time should be from within the last 3 months at date of test. In case 3 months of historical data is not available, the VLT manufacturer can pre- populate test data for the duration. 6. Firmware binary should be made available with version matching one in the device as well as binary size & modification timestamp and/ or checksum should match for the binary provided and one installed on device. Test to confirm geographical location of IP addresses, the device communicates with by IP Geolocation for all IPs configured into the device to confirm they are in India. The IPs configured should be read from the firmware configuration via configuration read command and also separately confirmed against a list of IPs provided by the VLT manufacturer. 7. 14. Test Details Firmware over the air update. Backend application should be able to remotely read the existing version number of the firmware via an OTA configuration read command. A new version of the firmware should be pushed over the air. This should be verified by reading the new version number of the new firmware in the device via and OTA configuration read command. 8. VLT manufacturer to provide a certificate, statement or affidavit certifying the location of data centre/ cloud hosting region in India for user, device and vehicle data. 9. VLT manufacturer to provide a Vulnerability Analysis and Penetration Testing report from a 3rd party test agency authorised by CERT-In/STQC. Page 34 ANNEXURE A Delete clause no 6.2 15. Page 35 ANNEXURE B Page 14 of 15 Substitute the following test for the existing text: ANNEXURE B: CRITERIA FOR EXTENSION OF TYPE APPROVAL B1.0 In case of following changes, Functional, Performance, Durability and Environmental Tests which are necessary for establishing compliance are listed below Changes in System Tests to be conducted B1.1

Change in Make, Model, Type, accompanied with or without a Part No of Vehicle Location Tracking (VLT) and Vehicle Health Monitoring. Applicable tests as per Section 6 and Functional verification at system integration level or component level as applicable B1.2 Change in software of ITS Functional verification at system integration level. B1.3 System Change in wiring harness Wiring harness requirements specified in this standard PRINTED BY THE AUTOMOTIVE RESEARCH ASSOCIATION OF INDIA P. B. NO. 832, PUNE 411 004 ON BEHALF OF AUTOMOTIVE INDUSTRY STANDARDS COMMITTEE UNDER CENTRAL MOTOR VEHICLES RULES - TECHNICAL STANDING COMMITTEE SET-UP BY MINISTRY OF ROAD TRANSPORT & HIGHWAYS (DEPARTMENT OF ROAD TRANSPORT & HIGHWAYS) GOVERNMENT OF INDIA 5th December 2018 Page 15 of 15 Amendment 1 (11th December 2017) To AIS-140: Intelligent Transportation Systems (ITS) Requirements for Public Transport Vehicle Operation 1. Page 2 Replace Clause 1.B.7, Substitute the following text for the 1.B.7 Global Navigation Satellite System (GNSS) refers to a space-based existing text: radio navigation system. It provides positioning, navigation and timing services to military and civilian user on a continuous basis. 2. Page 2 Add new sub clause 1.B.12: 1.B.12 3. SIM/UICC refers to Subscriber Identification Module (SIM)/ Universal integrated circuit card (UICC) as per GSMA guidelines / DoT (TEC) Guidelines. Embedded SIM/UICC is a PCB soldered SIM/UICC/eUICC. Page 2 Add new sub clause 1.B.13: 1.B.13

4. Cellular Technology such as GPRS/UMTS/HSPA/LTE etc. Page 5 Clause 3.1.1.1. a, Substitute the following text for the existing text: a. 5. Device shall be capable for operating in L and/or S band and include support for NAVIC/IRNSS (Indian Regional Navigation Satellite System) for devices installed on vehicles on or after 1st October 2018. However VLT devices shall be compliant as per other GNSS constellation in the interim period. Page 5 Clause 3.1.1.1. d, Substitute the following text for the existing text: d. Device shall have an acquisition sensitivity of minimum (-) 145 dBm with GNSS/ (-) 140 dBm with IRNSS (NAVIC as applicable). 6. Page 5 Clause 3.1.1.1. e, Substitute the following text for the existing text: e. Device shall have a tracking sensitivity of minimum (-) 160 dBm with GNSS / (-) 153 dBm with IRNSS (NAVIC as applicable). 7. Page 5 Clause 3.1.1.1. f, Substitute the following text for the existing text: f. Device shall have an internal antenna; however, if in case of Integrated systems with vehicle OEM fitted kits if the fitment location prevents the internal antenna from functioning, then additional external antenna may be provided. Page 1 of 16 8. Page 5 Clause 3.1.1.2, Substitute the following text for the existing text: 3.1.1.2 9. Device shall support standard minimum I/Os as mentioned: 4 Digital, 2 Analog Input and 1 Serial Communication (e.g. RS232) for interfacing external systems (E.g. Digital input for Emergency request button interfacing). Page 5 Clause 3.1.1.3, Substitute the following text for the existing text 3.1.1.3 10. Device shall be capable of transmitting data to Backend Control Server (Government authorized server) via Wide Area (Mobile) Communications network (Cellular) as per Communication Protocol in Section 4. Page 5 Clause 3.1.1.4, Substitute the following text for the existing text : 3.1.1.4 Device shall be capable of transmitting Position, Velocity and Time (PVT data) along with heading (direction of travel) to a Backend Control Server (Government authorized server) at configurable frequency as per Communication Protocol of Section 4. The fixed frequency shall be user configurable. Highest data transmission rate shall be 5 sec during vehicle operation and not less than 10 minutes in sleep/IGN OFF) as per the protocol defined in Communication Protocol of Section 4. 11.

Page 5 Clause 3.1.1.6, Substitute the following text for the existing text : 3.1.1.6 On pressing of Emergency button, the system implementing VLT function shall send emergency Alert (Alert ID 10 as mentioned in Sub- section 4.2.1 of Communication Protocol Section 4) to the configured IP address(s) as per the Communication Protocol mentioned in Section 4. In the absence of Cellular network, the emergency alert shall be sent as SMS message along with vehicle location data to configured control center number(s). The SMS shall consist parameters as given in Subsection 4.2.2. 12. Page 6 Clause 3.1.1.12, Substitute the following text for the existing text: 3.1.1.12 The Device shall have a unique identifier for identifying the VLT device and data. The unique ID shall be stored in a read only memory area so that it cannot be altered or overwritten by any person. The unique identifier is IMEI (International Mobile Station Equipment Identity) Number. 13. Page 6 Clause 3.1.1.14, Substitute the following text for the existing text: 3.1.1.14 Device shall have an Embedded SIM/UICC. Page 2 of 16 14. Page 6 Clause 3.1.1.15, Substitute the following text for the existing text: 3.1.1.15 15. Device shall be designed to operate 12V DC and or 24 V DC. Page 6 Clause 3.1.1.16, Substitute the following text for the existing text: 3.1.1.16 16. Device shall have a sleep mode current 50 mA. Page 6 Clause 3.1.1.18, Substitute the following text for the existing text: 18. The Device shall support: Location on Cellular /SMS Non-volatile memory to store min 40,000 positional log Configurable backup SMS facility in case of Cellular failure Capability to send serving and adjacent cell ID as well as network measurement report (NMR) 17. Page 7 Clause 3.1.1.19, Substitute the following text for the existing text: 19. The VLT Device shall have: The capability of Hot start < 10s The capability of Warm start : < 60 s The capability of Cold start < 120 s 18. Page 7 Clause 3.1.1.20, Substitute the following text for the existing text: 3.1.1.20 Device shall support data Outputs as per protocol covered in this

standard. 19. Page 7 Clause 3.1.1.21, Substitute the following text for the existing text: 21. The Device Cellular module shall have: 20. Multi slot Cellular with In built Quad-band Cellular module/Modem Cellular class 10 or above Support Embedded SIM/UICC to cater to the operational requirement such as vibration, temperature and humidity and provide long life span with at least 10 years life and more than 1 million read/write cycles Cellular module & Embedded SIM/UICC shall support o SMS, Data (Cellular, TCP/IP) and o Support multiple network OTA switching (on-demand / automatic) capabilities. Page 7 Clause 3.1.1.23, Substitute the following text for the existing text: Page 3 of 16 3.1.1.23 Device shall be manufactured by manufacturer whose quality management system has been certified for compliance to ISO / TS 16949 or ISO 9001 or any equivalent National or International standard. 21. Page 8 Clause 3.1.2.3, Substitute the following text for the existing text: 3.1.2.3 The Emergency Buttons will be such that disconnection between switch and controller should be detected through controller logic or Normally Closed (NC) Type Switch. For Emergency button, there shall be indication of its working status visible for passengers in Ignition ON Condition. The form factor of Emergency Buttons will be such that the button is easy to press in the case of an emergency, and simultaneously also minimizes the possibility of accidental or unintended press thereby causing a false alert. 22. Page 8 Clause 3.1.2.4, Substitute the following text for the existing text : 3.1.2.4 On pressing of Emergency button, the system implementing VLT function shall send emergency Alert (Alert ID 10 as mentioned in Sub- section 4.2.1 of Communication Protocol Section 4) to the Backend Control Server (Government authorized server) as per the Communication Protocol mentioned in Section 4. In the absence of Cellular network, the alert shall be sent as SMS message along with vehicle location data to configured control center number. The SMS shall consist of parameters as given in Sub-section 4.2.2. 23. Page 8 Clause 3.1.2.5, Substitute the following text for the existing text : 3.1.2.5 In absence of both Cellular and GSM networks and on pressing of Emergency Button, the system implementing VLT function shall store the emergency Alert (Alert ID 10 as mentioned in Sub-section 4.2.1 of Communication Protocol Section 4). Once the Cellular or GSM is available, this alert information shall be sent on high priority to the configured IP addresses as per the communication protocol mentioned in Section 4 or as SMS message along with vehicle location data to configured control center number. The SMS shall consist of parameters as given in Sub-section 4.2.2. 24.

Page 8 Clause 3.1.3, Substitute the following text for the existing text : 3.1.3 Configuration of Device Parameters Over the Air (OTA) The device shall support at least the below parameters to be configurable over the air (through SMS and Cellular). The updation/ configuration shall be allowed only over an authenticated channel: 1. Setting/ Change of the Primary or Secondary IP and port number 2. Setting/ Change of the APN 3. Set configuration parameter like sleep time, over speed limit, harsh braking, harsh acceleration, rash turning threshold limits etc. 4. Emergency control SMS Centre Number(s) 5. Configuring the vehicle registration number Page 4 of 16 6. Configuring the frequency of data transmission in normal / Ignition state / OFF state sleep mode/ Emergency state, etc. 7. Configuring the time duration for Emergency state 8. Capability to reset the device 9. Command to get the IMEI of the device Configurable commands must involve the following features: 1. SET: For setting the parameters. 2. GET: For enquiring regarding the parameters such as mobile number, GSM strength, vehicle number and other important parameters. 3. CLR: For clearing certain commands, alarms, alerts etc. except emergency alert After each SET, GET, CLR command the device should send alert to Backend Control Centre, as mentioned in Section 4 Alert 12, giving the details of Mode, mobile no/ IP of control center sending commands. 25. Page 9 Clause 3.1.5, Substitute the following text for the existing text : 3.1.15 In case of emergency state, (i.e. on pressing of Alert button), the device will shift to the SMS mode in case Cellular connectivity is not available. In such case, the device will send the Alert message and tracking data through SMS mode. Since SMS has the limitation of sending only 160 characters, so the tracking data to be sent in one SMS will have fields IMEI, Latitude, Direction, Longitude, Direction, location fix, speed, Cell ID, LAC (Location Area Code), Date and Time as per emergency alert . The details is provided in Sub-section 4.2.2. 26. Page 12 In Table 4 A , for the item Checksum and entries thereof, substitute the following: Checksum 27. Ensures No error in transmission (optimal) 16 Page 13 In Table 4 B, for the item Alert Id 2. Location Update (history) and entries thereof, substitute the following: 2. 28. Location Update (history) Would be sent, if Cellular is not available at the time of sending the message in protocol format Zero, BLANK, NIL, etc. Page 14 Clause 4.2.2, For first paragraph substitute the following text for the existing text: 4.2.2 In case of emergency alert, the alert message shall be sent to 2 different IP addresses hence the device shall support minimum 2 IP addresses (1 IP address for regulatory purpose (PVT data) and 1 IP address for Emergency response system other than the IPs required for Operational purpose. The PVT data will send the emergency alert to the system. Only Primary alert data will go to the emergency response Backend Control Centre (NERS/ MHA) as may be notified by the Government of India in the schema below: Page 5 of 16

29. Page 14 Substitute the following Table 4 C for existing Table 4 C : Table 4C: Indicative Format for Alert to Emergency Response System Attribute Value / Description Size Start Character $ 1 Byte Packet Header Packet Type EPB, The unique identifier Character, 3 bytes for all messages from VLT Message Types supported. Character, 3 bytes Emergency Message (EMR) or Stop Message (SEM) IMEI Number Unique ID of the Vehicle Character,15 bytes (IMEI Number) Packet Status NM Normal Packet, Character, 2 bytes SP Stored Packet Date Date and time of location Character,14 bytes the location obtained from the data in DDMMYYYY hhmmss format GPS Validity A Valid, Character, 1 byte V Invalid Latitude Latitude Direction Latitude degrees format - in decimal Double, 12 bytes dd.dddddd N North, Character, 1 byte S South Longitude Longitude in decimal Double, 12 bytes

degrees format dd.dddddd Longitude Direction E East Character, 1 byte W West Altitude Altitude in meters (above sea level) Speed Speed of Vehicle as Float, 6 bytes Calculated by GPS module in VLT. (in km/hr) Distance Distance calculated from previous GPS data Page 6 of 16 Double, 12 bytes Float, 6 bytes Provider G - Fine GPS Character, 1 byte N - Coarse GPS or data from the network Vehicle Regn. No Registration Number of the Vehicle Character, 16 bytes Reply Number The mobile number to which Test response needs to be sent. (Emergency Mobile No. as specified by MHA/MoRTH/States.) 0 End Character * 1 byte Check sum Ensure no error in transmission 8 bytes Note: No number needs to be sent. This field will with value zero *Above format is indicative only. These Format will be notified by the Government of India time to time. 30. Page 15 In Clause 4.3, for the words:

CLR: For clearing certain commands, alarms, alerts etc. Substitute the following text: CLR: For clearing certain commands, alarms, alerts etc. except emergency alert. 31. Page 16 Clause 5.1, Substitute the following text for the existing text : 5.1 Requirements on vehicle interface for VLT with Emergency Button Connector for Power The requirements for interface shall be as agreed between vehicle manufacturer and device manufacturer. 32. Page 16/17 Clause 5.3, Substitute the following text for the existing text : Page 7 of 16 5.3 Physical Mounting The VLT system shall be mounted in a suitable location such a way that it is not easily accessible /exposed to passengers. This requirement shall not be applicable in case of combined systems VLT with HMI (Human Machine Interface) display in front of driver. Test agency to verify this on vehicle level approval. Emergency button(s) shall be fitted in such a way that every passenger including driver shall be able to access the Emergency button(s). Passenger Car shall have at least one emergency buttons on each passenger row easily accessible by each of the passenger. There shall also be one dedicated emergency button for the driver row. Passenger Transport bus shall have emergency buttons at locations easily visible & assessable to all the passengers such as every 2 meters on both the sides on passenger seating area. For seats reserved for ladies there shall be a dedicated panic button for each row. It shall be permissible to have a single emergency button for two successive ladies rows on both sides of the vehicle provided each lady passenger in either rows are able to reach and operate the emergency button. Test agency to verify this on vehicle level approval. 33. Page 17 Clause 5.4, Substitute the following text for the existing text : 5.4 The vehicle tracking device will be installed on vehicles in which the power supply voltage from vehicle battery is widely varying (12V, 24V etc.) and also the power supply is not as stable as that in case of fixed locations, especially during engine start-up and braking when the voltage can fall to as low as 9V. Typically electronic devices are very sensitive to power surges and spikes, and equipment may fail if they do not receive stable power supply. The devices will need to have a resilient power supply unit that can withstand such fluctuations and the devices also need to have power backup so that they continue to function for some duration when the vehicle battery is not functional or is disconnected from the devices. Vehicle power interface shall have 34. One common ground linked to vehicle chassis One permanent power Supply (12/24V) connected to the vehicle battery (+Vbat). One non-permanent power line (12/24V) connect to the battery after ignition (IGN).

Page 17 Clause 6.1.1.2, Substitute the following text for the existing text : 6.1.1.2 System transmits PVT information to Backend Control Center (2 different IPs) at user configurable frequency (minimum 5 seconds) via GSM / Cellular. Page 8 of 16 35. Page 18 Clause 6.2.1.1, Substitute the following text for the existing text : 6.2.1.1 36. Standard connector provided for Power and other signals as per clause no 5.1. Page 18 Clause 6.2.1.5, Substitute the following text for the existing text : 6.2.1.5 37. Updating of the firmware of the system from Backend Control Centre only. Page 19 Substitute the following Table 6 A for existing Table 6 A : Table 6A: Functional Testing Sl. No Test 1 Tracking Functionality Test Test Procedure The test shall be conducted on VTL to determine the proper functioning of VLT with Emergency Button by testing its connectivity to Backend Control Centre (Government authorized server). Procedure: The VLT with Emergency Button shall be connected to vehicle battery to switch it on. The VLT with Emergency Button shall be tested for the connectivity to server and its capability to send two location messages 2 Location Accuracy Test This test shall be conducted on VLT with Emergency Button. The receiver is placed into a cold start state usually by a command sent to the receiver through a test connection and then a fairly strong navigation signal simulating in L and/or S band is sent. The time it takes for the receiver to determine its first good location fix is recorded. Test is done many times (>15 times) over many conditions and the results are averaged. Acceptance Criteria: 2.5 m CEP or 6 m 2DRMS. Page 9 of 16 3 Acquisition Sensitivity Test This test shall be conducted on VLT with Emergency Button. Procedure: Set the simulator to output navigation signal simulating L and/or S

band to a particular location with a very level so that the tracking is not possible. Gradually increase the signal level that allows the receiver to successfully perform a cold start TTFF. The minimum signal level that allows acquisition is referred as to the acquisition sensitivity. Acceptance Criteria: The acquisition sensitivity shall be minimum (-)145 dBm with GNSS/ (-) 140 dBm with IRNSS (NAVIC as applicable.). 4 Tracking Sensitivity Test This test shall be conducted on VLT. Procedure: The device under this test is locked on to the simulators output frequency (navigation signal simulating L and/or S band) and the simulator power output is lowered until the lock is lost. Multiple repetition of the test with different satellite geometries ensures that an accurate average measure is recorded. Acceptance Criteria: The tracking sensitivity shall be equal to or better than (-) 160 dBm with GNSS / (-) 153 dBm with IRNSS (NAVIC as applicable). 5 Cold-Start Time to First Fix (TTFF) Test The device in this test is placed into a cold start state. The time it takes for the device to determine its first good location fix is recorded. The cold start test is performed several times and the results are averaged. Acceptance Criteria: The cold start TTFF shall be less than 120 seconds at Open Sky condition or (-) 130 dBm. 6 Warm-Start Time to First Fix Test In this test the device is started in warm start mode and time taken by device to determine the first valid location fix is recorded. This is done several times and results are averaged. Acceptance Criteria: The warm start TTFF shall be less than 60 seconds at Open Sky condition or (-) 130 dBm. Page 10 of 16 7 Hot-Start Time to First Fix Test In this test the device is started in Hot start mode and time taken by device to determine the first valid location fix is recorded. This test is performed several times and results are averaged. Acceptance Criteria: The hot start TTFF shall be less than 10 seconds. 8 Embedded SIM/ UICC Test

This test is to check the suitability of the embedded SIM/ UICC and communication module. The test shall be conducted to determine the effectiveness and operation of the Cellular module with OTA network switching capabilities on demand as well as automatically in real-time. The test consist of two type of testing as below: 1. The device would be tested to perform as per the protocol using an embedded SIM/UICC. 2. The Cellular module & embedded SIM/UICC, shall support: o SMS, Data (Cellular, TCP/IP) and o Support multiple network OTA switching capabilities (On Demand as well as Automatic Switching on realtime basis) Acceptance Criteria: In the testing, vendors has to demonstrate the embedded SIM/UICC based tracking and multiple network OTA switching capabilities (On Demand as well as Automatic Switching on real-time basis) for effective network management and transmission. 9 Functional Endurance Test VLT device shall be operated for 96 hours with external power supply and internal battery connected to device. PVT data monitoring will be done for complete duration of test with data frequency defined after IGN switch ON mode. VLT device shall function successfully during and after test. 10 On Vehicle Dynamic Location Test VLT devices will be mounted on any target vehicle connected with vehicle battery. Target vehicle with VLT devices will be run for 10 km on pre-defined track/route to verify dynamic location test. VLT device PVT data shall be within 12 meter for more than 90% of the fixed location data (as arrived using DGPS device on the same route). VLT device PVT data shall be super imposed on followed route map to check its correctness of followed route. Page 11 of 16 38. Page 23 In Table 6 B, for the Sl. No. 5 and entries thereof, substitute the following: 5 39. Battery Backup Test Battery backup is the amount of time that the device battery can support sending the data without being

connected to the power source. This test will be performed by disconnecting the input charging voltage to the device. On disconnecting the external supply, battery would use its charge capacity to send data through Cellular. Time duration between external power disconnect to the last data packet time denotes the battery backup time. Acceptance Criteria: Device shall be able to work in active mode for a period of 4 hours or more at the polling/ transmission rate of 60 sec Page 19 Substitute the following Table 6 C for existing Table 6 C: Table 6C: Device Level Environmental Test Sl. No 1 Test Dry Heat / High Temperature Test Test Procedure The high temperature test is used to evaluate effects of high temperature conditions on safety, integrity, and performance of the device. The test shall be carried out in accordance with Indian Standard IS: 9000 (Part 3/Sec 5) the device shall be subjected to temperature of 70 2C for 16 h in high temperature. Test with device in working condition. The recovery period shall be 2 h. Acceptance Criteria: Device during and after the high temperature test the device shall be required to meet the provisions of Functional Test Number 1 as listed in Table 6A. Page 12 of 16 2 Cold Test The test shall be carried out in accordance with IS 9000 (Part 2/Sec 4 1977). The device under test shall be subjected to temperature of 10 2C for 2 h with device in working condition. The recovery period shall be 2 h. Acceptance Criteria: Device during and after the cold test, the device shall be required to meet the provisions of Functional Test Number 1 as listed in Table 6A. 3 4 5 6 Damp Heat Test Temperature Shock

Salt Spray Test High Voltage Test The device under test shall be tested according to IS 9000 (Part 5/Sec 2 1981). The test is carried out at +25 to +55 C, Humidity 95%. Six cycles (each test cycle of 24 h) shall be run with device in off condition. Functional test shall be carried out with power in On condition at start of 2nd, 4th and 6th cycle. Acceptance Criteria: Device during and after the test the device shall be required to meet the provisions of Functional Test Number 1 as listed in Table 6A. Temperature shock test is carried out to determine if the device can withstand sudden changes in the temperature of the surrounding atmosphere without experiencing physical damage or deterioration in performance. The device shall be tested as per IS 9000 (Part 14/Sec 2) 1978. Exposure time at temperature extremes -10C and 70 C would be 3 hours/cycle and number of cycles would be two. Acceptance Criteria: Device after the test the device shall be required to meet the provisions of Functional Test Number 1 as listed in Table 6A. The salt spray test is conducted to check corrosion resistance of device. The device shall be tested according to Clause 4.8 of IS 10250 for 96 h. Acceptance Criteria: The device shall be required to meet the provisions of Functional Test Number 1 as listed in Table 6A. The test is conducted to ensure service life requirements & functionality. The device under test shall be operated for 60 minutes at 18 V for 12 V systems & 36 V for 24 V systems. This test is as per ISO 167502:2010 Page 13 of 16 Acceptance Criteria: Device during and after the test the device shall be required to meet the provisions of Functional Test Number 1 as listed in Table 6A. 40. Page 27 In Table 6 D; for item Packet Type and Alert ID and entries thereof, substitute the following text for existing text : Packet Type Specify the packet type NR = Normal EA = Emergency Alert TA = Tamper Alert (Optional) HP = Health Packet IN = Ignition On IF = Ignition Off BD = Vehicle Battery Disconnect BR = Vehicle Battery Reconnect BL = Internal Battery Low HB= Harsh Braking HA= Harsh Acceleration RT= Rash Turning

Alert ID 41. 02 Character Page 29 After Table 6 D; for paragraph (a), substitute the following text for existing text a) 42. The device shall support 40000 or more positional logs/packets. This is a functional test and the device will be simulated to be in non Cellular coverage area and the logs will be maintained. The capacity of logging will be checked by monitoring the logs on the device. Page 29 In Table 6 E; for Alert ID 2 and entries thereof, substitute the following text for existing text : 2. 43. Location Update (history) Would be sent, if Cellular is not available at the time of sending the message Page 30 Substitute the following Table 6 F for existing Table 6 F: Page 14 of 16 Table 6F: Message Format Start Character Packet Header $ 1 byte EPB, The unique identifier for all messages from VLT Message Types supported. Emergency Message (EMR) or Stop Message (SEM) Character, 3 bytes IMEI Number Unique ID of the Vehicle (IMEI Number) Character,15 bytes Packet Status NM Normal Packet, SP Stored Packet Character, 2 bytes Date Date and time of the location obtained from the location data in DDMMYYYY hhmmss format Character,14 bytes GPS Validity A Valid, V Invalid

Character, 1 byte Latitude Latitude in decimal degrees - dd.mmmmmm format Double, 12 bytes Latitude Direction N North, S South Character, 1 byte Longitude in decimal degrees dd.mmmmmm format E East W West Double, 12 bytes Altitude Altitude in meters (above sea level) Double, 12 bytes Speed Speed of Vehicle as Calculated by GPS module in VLT. (in km/hrs.) Float, 6 bytes Distance Distance calculated from previous GPS data Float, 6 bytes G - Fine GPS Character, 1 byte Packet Type Longitude Longitude Direction Character, 3 bytes Character, 1 byte Provider N Coarse GPS or data from the network Vehicle RegnNo Registration Number of the Vehicle Character, 16 bytes The mobile number to which Test response need to be sent. (Emergency Mobile No. as specified by MHA/MoRTH/States.) 0

End Character * 1 byte Check sum Ensure no in transmission. Reply Number Page 15 of 16 error 8 bytes 44. Page 31 In Clause no. 7 for first paragraph substitute the existing text with following text : The VLT device would transmit data to the Backend Control Centre using Cellular wireless connectivity (with SMS fall back) as per the protocol provided in respective sections (Sub-section 6.3.4). The data from the devices would travel over the wireless telecom service provider network and finally get delivered at the Backend Control Centre. Since the permit holders/Device suppliers would require to have a valid communication plan on embedded SIM/UICC cards on the devices and would avail services from multiple telecom service providers, the data would be transmitted to the Backend Control Centre using the networks of multiple telecom service providers. 45. Page 31 In Clause no. 7 for second paragraph substitute the existing text with following text : A suitable control mechanism would be established for the data transfer from VLT to Backend Control Centre, as only the authorized devices should be able to transfer data to the Backend Control Centre and a mechanism for authenticating the devices/ embedded SIM/UICC shall also be put into place. 46. Page 36 Delete Annexure C : PRINTED BY THE AUTOMOTIVE RESEARCH ASSOCIATION OF INDIA P. B. NO. 832, PUNE 411 004 ON BEHALF OF AUTOMOTIVE INDUSTRY STANDARDS COMMITTEE UNDER CENTRAL MOTOR VEHICLES RULES - TECHNICAL STANDING COMMITTEE SET-UP BY MINISTRY OF ROAD TRANSPORT & HIGHWAYS (DEPARTMENT OF ROAD TRANSPORT & HIGHWAYS) GOVERNMENT OF INDIA 11th December 2017 Page 16 of 16 AIS-140 AUTOMOTIVE INDUSTRY STANDARD Intelligent Transportation Systems (ITS) - Requirements for Public Transport Vehicle Operation PRINTED BY THE AUTOMOTIVE RESEARCH ASSOCIATION OF INDIA P.B. NO. 832, PUNE 411 004 ON BEHALF OF AUTOMOTIVE INDUSTRY STANDARDS COMMITTEE UNDER CENTRAL MOTOR VEHICLE RULES TECHNICAL STANDING COMMITTEE

SET-UP BY MINISTRY OF ROAD TRANSPORT and HIGHWAYS (DEPARTMENT OF ROAD TRANSPORT and HIGHWAYS) GOVERNMENT OF INDIA October 2016 1 AIS-140 Status chart of the Standard to be used by the purchaser for updating the record Sl. No. Corrigenda Amendment General remarks: 2 Revision Date Remark Misc. AIS-140 INTRODUCTION The Government of India felt the need for a permanent agency to expedite the publication of standards and development of test facilities in parallel when the work on the preparation of the standards is going on, as the development of improved safety critical parts can be undertaken only after the publication of the standard and commissioning of test facilities. To this end, the erstwhile Ministry of Surface Transport (MoST) has constituted a permanent Automotive Industry Standards Committee (AISC) vide order No. RT-11028/11/97-MVL dated September 15, 1997. The standards prepared by AISC will be approved by the permanent CMVR Technical Standing Committee (CTSC). After approval, the Automotive Research Association of India (ARAI), Pune, being the secretariat of the AIS Committee, will publish this standard. Intelligent Transport Systems (ITS) are globally proven systems to optimize the utilization of existing transport infrastructure and improve transportation systems in terms of efficiency, quality, comfort and safety. Having realized the potential of ITS, Government bodies and other organizations in India are presently working towards implementing various components of ITS across the country. The first step taken for creation and implementation of ITS was holding a National Workshop titled User Requirements for Interactive ITS Architecture, which was conducted as a collaboration between SIAM and ASRTU on 26th & 27th February 2015. This was primarily focused on ITS in Public Bus Transportation. Nonetheless, the workshop helped to create the outline for National Intelligent Transport System Architecture and Policy for Public Transport (Bus), which was submitted by ASRTU and SIAM to the government In the 44th & 45th CMVR-TSC, Chairman had directed - standardization activities to be initiated on Intelligent Transportation Systems (ITS) - Vehicle Location Tracking, Camera Surveillance System and Emergency Request Button. The committee intended to extend the above user requirements to all public transportation namely buses, taxis, etc. The current document covers the requirements for Vehicle Location Tracking and Emergency Button. The other ITS components like PIS, CCTV system, Fare collection etc. are deliberated and would be addressed in later phase and could be added as separate parts to the current document.. Based on these directions, the AISC Panel on ITS has prepared this AIS-140 titled, Intelligent Transportation Systems (ITS) - Requirements for Public Transport Vehicle Operation The panel has also deliberated and identified the necessary elements for an effective implementation of vehicle level ITS system. 3 AIS-140 This standard has been prepared by considering inputs received from all stake holders on ITS, mainly a. Directions of CMVR-TSC b. Detailed Specification Document on Vehicle Tracking Devices (dated 4th March 2015, published by MoRTH) c. Report of Department of Telecom (Telecom Engineering Centre) Automotive Working Group on M2M enablement in Intelligent Transport System (ITS) This AIS on ITS, has been provisioned for device level approval; including construction and target vehicle level approval. Device level approval is needed to enable retro-fitment of ITS systems on in-use vehicles. This will ensure ITS Backend Control Centre infrastructure already presents with the STUs can be more fully

utilized and make the investment in the Backend Control Centre infrastructure more viable. As per the direction of CMVR-TSC which needed the Communication Protocol and Backend Control Centre requirement for tracking and handling the alerts to be detailed, the same has been addressed in Section 6 & 7, as detailed below. The devices would transmit data to the Backend Control Centre using 2G/3G/4G wireless connectivity (with SMS fall back) as per the protocol provided in respective sections (Section 6). The data from the devices would travel over the wireless telecom service provider network and finally get delivered at the Backend Control Centre. The detail about Device to Backend Communication Mechanism is mentioned in Section 7. BIS and AIS both have panels which are formulating standards on ITS. It is our belief that taking the AIS route for the 1st implementation would give the faster time for adoption. Experts in the BIS panel and in DIMTS who are working on these subjects have been co-opted and invited to work in the AIS panel to make the AIS as robust as possible. Once implemented and all implementation problems in this emerging technology have been eliminated, BIS standard can be made with further inclusions if any resulting from consultations with the wider stakeholder community. Because of these reasons, we recommend the AIS route for regulation creation and first implementation. One of the major concerns which has been raised during the panel meetings is on the issue of privacy encroachments by ITS systems. Some overseas member countries of the 1958 agreement have been continuously emphasizing in WP29 forums that the regulated ITS system must not encroach on privacy. Towards this, the panel has submitted a document titled Data Privacy in Transportation ITS To help the system developers deal with these issues. Further, system developer can also take guidance from IS/ISO/TR 12859: 2009 - Intelligent Transport Systems System Architecture Privacy Aspects in ITS Standards and Systems while developing their systems to meet the requirements of this standard. The Panel and the Automotive Industry Standards Committee (AISC) responsible for preparation of this standard are given in Annexure-D and Annexure -E respectively. 4 AIS-140 CONTENTS Clause No. Details Page No. 1.0 Scope 1/40 2.0 Application For CMVR Type Approval 3/40 3.0 ITS Functions and Requirements 4/40 4.0 Communication Protocol 10/40 5.0 Construction and Installation 16/40 6.0

Functional, Performance, Durability, Environmental and Protocol Tests 17/40 7.0 Device to Backend Communication Mechanism 31/40 List of Annexures ANNEXURE-A Information to be Submitted for Type Approval 34/40 ANNEXURE-B Criteria for Extension of Type Approval 35/40 ANNEXURE-C Physical Interfaces (Connectors) for Power and I/Os 36/40 ANNEXURE-D Composition of Panel 38/40 ANNEXURE-E 40/40 Committee Composition 5 AIS-140 Intelligent Transportation Systems (ITS) - Requirements for Public Transport Vehicle Operation 1.0 SCOPE 1.A.0 This standard applies to both individual components as well as system environment intended to be used in Public transport vehicles. 1.A.1 INTELLIGENT TRANSPORTATION SYSTEMS-VLT WITH AN EMERGENCY SYSTEM Requirements on ITS devices and functions - Vehicle Location Tracking and Emergency Button. 1.B.0 DEFINITIONS: For the purpose of this standard, definitions are given below: 1.B.1 Acquisition sensitivity refers to the minimum signal level at which the device is able to successfully perform a cold start TTFF. The acquisition sensitivity test is a simulated signal test. 1.B.2 Assisted GPS (A-GPS) is a system allowing satellite receivers to obtain information from communication network resources to assist in acquiring satellite location. A-GPS system is especially useful when the receiver is in a location where it is difficult for the satellite signals to penetrate. In addition to providing better coverage, A-GPS also improves the start-up time, which is the time required by the satellites and the receivers to establish a reliable connection. 1.B.3

Circular Error Probability (CEP) is defined as the radius of a circle centered on the true value that contains 50% of the actual GPS measurements. So a receiver with 5 meter CEP accuracy will be within 5 meter of the true measurement 50% of the time. The other 50% of the time the measurement will be in error by more than one meter. 1.B.4 Dilution of Precision (DOP) is the degree of proximity of the location data to their mean value. The relative position of satellites affects the accuracy of location calculation by the locating module. Location coordinates computed when the satellites are clustered together suffer from dilution of precision (DOP), a factor that multiplies the associated errors. The DOP for an ideal satellites constellation arrangement equals close to 1, which does not magnify the underlying errors. 1.B.5 Distance Root Mean Square (DRMS also called RMS, 1Sigma) This is computed as square root of the average of the squared horizontal position errors with 65% probability. The position expressed has the probability of being within a circle with radius with 65% probability. A locating module with 6 metre DRMS accuracy would be within 6 meters of its actual position 65% of the time. 1/40 AIS-140 1.B.6 Emergency Button A button provided in vehicle for passengers or crew members to send specialized data packet /SMS to Centralized regulatory server to indicate safety/panic situation caused by human or natural disaster or vehicle accident etc. 1.B.7 Global Positioning System (GPS) is a space-based radio navigation system. It provides positioning, navigation, and timing services to military and civilian users on a continuous basis. 1.B.8 Sensitivity refers to the minimum signal strength level at which locating module can successfully perform a location fix. A GNSS locating module has two different sensitivity levels acquisition sensitivity and tracking sensitivity. 1.B.9 Time to First Fix (TTFF) describes the time required for a tracking device to acquire adequate satellite signals and related data (almanac and ephemeris data) to compute location. 1.B.10 Tracking Sensitivity refers to the minimum signal level at which the device is able to successfully maintain the location fix. The acquisition sensitivity test is a simulated signal test. 1.B.11 Vehicle Location Tracking (VLT) device uses satellite based location technology to determine and record the precise location of a vehicle at regular intervals. The location data so determined can be stored within the device, and/or can be transmitted to the Backend Control Centre using a wireless communication modem built in the device. 1.C REFERENCES: The References are listed below. 1.C.1 National Level Vehicle Security and Tracking System Detailed Specification Document on Vehicle Tracking Devices (GPS) (Published by MoRTH MoRTH). 1.C.2

APTA TCIP - American Public Transportation Association (APTA) Standard for Transit Communications Interface Profiles (TCIP) 1.C.3 EBSF - European Bus System of the Future 1.C.4 ISO 11898-1:2003 Road vehicles Controller area network (CAN) 1.C.5 SAE J 1939 Recommended Practice for a Serial Control and Communications Vehicle Network. 1.C.6 Bus-FMS-Standard 1.C.7 SAE USCAR 18 / USCAR18-3 - FAKRA SMB RF CONNECTOR SUPPLEMENT 1.C.8 National ITS Architecture - U.S. Department of Transportation 1.C.9 ISO 17185-1:2014 - Intelligent transport systems Public transport user information Part 1: Standards framework for public information systems 2/40 AIS-140 1.C.10 Trans model Standard (CEN/TC 278 WG3/SG4, Reference EntityRelationship Data Model for Public Transport) - European reference data model for Public Transport operations developed within several European Projects - EN 12896:2006 1.C.11 Specification for Entity-Relationship for describing the main fixed objects in Public transport CEN/TC 278, 2008 - EN 28701:2012 1.C.12 RTIG (Real Time Information Group Ltd) - Digital Air Interface Protocol 1.C.13 SIRI (Service Interface for Real Time Information) European Technical Specification (TS) - CEN/TS 15531 1.C.14 NeTEx-Network Exchange European Technical Specification (TS) CEN/TS 16614 1.C.15 NaPTAN (National Public Transport Access Node) 1.C.16 ISO 15638-15:2014 Intelligent transport systems Framework for cooperative telematics applications for regulated vehicles (TARV) Part 15: Vehicle location monitoring 1.C.17 ISO 15638-5:2013 Intelligent transport systems Framework for collaborative Telematics Applications for Regulated commercial freight Vehicles (TARV) Part 5: Generic vehicle information 1.C.18

NMEA-0183: The NMEA 0183 standard defines an electrical interface and data protocol for communications between marine instrumentation. 1.C.19 IS/ISO/TR 12859:2009 Intelligent Transport SystemArchitecture-Privacy Aspects System in ITS standards and systems 1.C.20 Report of Department of Telecom (Telecom Engineering Centre) Automotive Working Group on M2M enablement in Intelligent Transport System (ITS) 1.C.21 URL: http://tec.gov.in/pdf/M2M/M2M%20Enablement%20in%20ITS.pdf 2.0 APPLICATION FOR CMVR TYPE APPROVAL 2.1 The application for CMVR device level approval shall be accompanied by information on the system specification as mentioned in Annexure A. 2.2 Type approval shall involve following steps: 2.2.1 Device Approval: Approval provided at Device level for compliance to this standard. These approved devices can be fitted / retro-fitted by manufacturer/ dealer/ permit holder/system integrator in any vehicle model provided it shall meet installation requirements as mentioned in Clause No. 5 of this standard. For manufacturers seeking vehicle level approval with approved VLT with Emergency Buttons fitted shall only require installation approval as per the provisions of Clause 5 and Sub-Clause 6.1 of Clause 6. 3/40 AIS-140 2.3 Modifications and Extension of Approval 2.3.1 Every modification pertaining to the information, even if the changes are not technical in nature declared in accordance with clause 2.1, shall be intimated by the VLT with Emergency Button Manufacturer to the test agency. 2.3.1.1 If the changes are in parameters not related to the provisions, no further action need be taken. 2.3.1.2 If the changes are in parameters related to the provisions, the test agency, which has issued the certificate of compliance, may then consider, based on the justification provided by the VLT with Emergency Button Manufacturer and reviewed by the test agency, whether, The model with the changed specifications still complies with provisions; Or, Any further verification is required to establish compliance. 2.3.2 In case of 2.3.1.2, tests for only those parameters which are affected by the modifications need be carried out based on Criteria for extension of type approval as per Annexure B. 2.3.3 In case of fulfilment of criterion of clause 2.3.1.1 or after results of further

verification as per clause 2.3.1.2 are satisfactory, the approval of compliance shall be extended for the changes carried out. 3.0 ITS FUNCTIONS AND REQUIREMENTS The list of ITS functions envisaged from this device type is set out below in Table 3A Table 3A: List of ITS Functions and Sub Functions Function Safety and Security Sub Functions Emergency Buttons Vehicle Location Tracking (VLT) The above functions and their requirements shall be met by only single device that can be interfaced by external emergency buttons. The communications to Backend Control Server (Government authorized server) shall be done by device as per the protocol and functionalities defined below. 3.1 Vehicle Location Tracking (VLT) With Emergency Button 3.1.1 Functional Requirements for VLT 4/40 AIS-140 3.1.1.1 Device shall be capable of obtaining position information using Global Navigation Satellite System (GNSS). GNSS receiver specifications are as follows: a. Device shall be capable for operating in L and/or S band and include support for NAVIC/IRNSS (Indian Regional Navigation Satellite System) for devices installed on or after 1st April, 2018. b. The Device shall support GAGAN, the Indian SBAS (Satellite Based Augmentation System). c. Device shall have a position accuracy of minimum 2.5 m CEP or 6 m 2DRMS. d. Device shall have an acquisition sensitivity of minimum (-) 148 dBm. e. Device shall have a tracking sensitivity of minimum (-) 165 dBm. f. Device shall have an internal antenna; however if in case of Integrated systems with vehicle / aftermarket OEM approved kits if the fitment location prevents the internal antenna from functioning, then external antenna shall be provided. 3.1.1.2 Device shall support standard minimum I/Os as mentioned: 4 Digital, 2 Analogue and 1 Serial Communication (e.g. RS232) for interfacing external systems (E.g. Digital input for Emergency request button interfacing). 3.1.1.3 Device shall be capable of transmitting data to Backend Control Server (Government authorized server) via Wide Area (Mobile) Communications network (GSM/GPRS) as per Communication Protocol in Section 4. 3.1.1.4 Device shall be capable of transmitting Position, Velocity and Time (PVT data) along with heading (direction of travel) to a Backend Control Server (Government authorized server) at configurable frequency as per Communication Protocol of Section 4. The fixed frequency shall be user configurable, minimum frequency shall be 5 sec during vehicle operation and not less than 10 minutes in sleep/IGN OFF) as per the protocol defined in Communication Protocol of Section 4. 3.1.1.5 Device shall be capable of transmitting data to minimum 2 different IP addresses (1 IP address for regulatory purpose (PVT data) and 1 IP address for Emergency response system other than the IPs required for

Operational purpose. 3.1.1.6 On pressing of Emergency button, the system implementing VLT function shall send emergency Alert (Alert ID 10 as mentioned in Sub-section 4.2.1 of Communication Protocol Section 4) to the configured IP address(s) as per the Communication Protocol mentioned in Section 4. In the absence of GPRS network, the emergency alert shall be sent as SMS message along with vehicle location data to configured control center number(s). The SMS shall consist parameters as given in Sub-section 4.2.2. 5/40 AIS-140 7. Device shall have an internal back-up battery to support 4 hours of normal operations (to be tested for positional record transmission at a frequency of 60 sec). 8. Device shall be capable of transmitting alerts to the Backend Control Server (Government authorized server) directly. The applicable list of alerts is given in Section 4.2 (Alert ID 3 to 12) of Section 4. 9. Device shall support over the air software and configuration update. 10. Device shall support basic standard configuration (Mobile communications network settings, Backend Control Server (Government authorized server) details, data frequencies, alert thresholds etc.) as per configuration specification defined in Section 4. 11. Device shall support store and forward mechanism for all type of data (periodic data and alerts) meant for backend transmission. The system shall store data in internal memory during communication network unavailability and transmit the data when the connection resumes in last in first out (LIFO) manner. The live data shall be given higher priority for transmission than back log (stored data) at any point in time. 12. The Device shall have a unique identifier for identifying the VLT device and data. The unique ID shall be stored in a read only memory area so that it cannot be altered or overwritten by any person. The unique identifier may be Vehicle Identification number or IMEI (International Mobile Station Equipment Identity) Number. 13. Device shall store/write the registration number of the vehicle in the internal nonvolatile memory. 14. Device shall have an Embedded SIM. 15. Device shall be designed to operate between 8VDC and 32VDC using vehicle battery input voltage range 12 /24Volts. 16. Device shall have a sleep mode current 20 mA (If the function is implemented in a dedicated system/device). 17. Device shall support any operational GNSS system with 12 (minimum) acquisition channels. 18.

The Device shall support: Location on GPRS/SMS Non-volatile memory to store min 40,000 positional log Configurable backup SMS facility in case of GPRS failure Capability to send serving and adjacent cell ID as well as network measurement report (NMR) 6/40 AIS-140 19. The Device GNSS module shall have: The capability of Hot start <5s The capability of Warm start : < 30s The capability of Cold start < 40 s 20. Device shall support Outputs as per NMEA 0183 21. The Device GPRS module shall have: Multi slot GPRS with In - built Quad-band GPRS module/Modem GPRS class 10 or above Support Embedded SIM to cater to the automotive operational requirement such as vibration, temperature and humidity and provide long life span with at least 10 years life and more than 1 million read/ write cycles GPRS module & SIM shall support o SMS, Data (GPRS, TCP/IP) and o Support multiple network OTA switching (on-demand/automatic) capabilities. 3.1.1.22 Device shall be dust, temperature, vibration, water splash resistant, IP 65 rated or better, tamper proof as per Section 6. 23. Device shall be manufactured using processes as per quality management standard for automotive industries i.e. ISO/TS 16949 updated from time to time. 24. Device shall support A-GPS (Assisted GPS). 25. Device shall have provision of secured data transmission to the Backend Control Centre from the devices through secured channel (e.g. secured dedicated APN). 26. Device shall have 3 axis accelerometer and 3 axis gyroscope for getting the alerts on harsh breaking harsh acceleration, and rash turning. 1. Functional Requirement for Emergency System 1. Passengers or in-vehicle crew present in the vehicle shall be able to make an emergency request by pressing the emergency button provided. 2. The emergency request function shall not exist as standalone. The function shall be part of Vehicle Location Tracking (VLT) system. An alert shall be sent to the Backend Control Server (Government authorized server) when emergency request is raised. De-activation shall always be from authorized government server who receives alert message i.e. NERS system as mentioned in Sub-section 4.2.2. 7/40

AIS-140 3. The Emergency Buttons will be 'Normally Closed' (NC) type. The form factor of Emergency Buttons will be such that the button is easy to press in the case of an emergency, and simultaneously also minimizes the possibility of accidental or unintended press thereby causing a false alert. 4. On pressing of Emergency button, the system implementing VLT function shall send emergency Alert (Alert ID 10 as mentioned in Subsection 4.2.1 of Communication Protocol Section 4) to the Backend Control Server (Government authorized server) as per the Communication Protocol mentioned in Section 4. In the absence of GPRS network, the alert shall be sent as SMS message along with vehicle location data to configured control center number. The SMS shall consist of parameters as given in Sub-section 4.2.2. 5. In absence of both GPRS and GSM networks and on pressing of Emergency Button, the system implementing VLT function shall store the emergency Alert (Alert ID 10 as mentioned in Sub-section 4.2.1 of Communication Protocol Section 4). Once the GPRS or GSM is available, this alert information shall be sent on high priority to the configured IP addresses as per the communication protocol mentioned in Section 4 or as SMS message along with vehicle location data to configured control center number. The SMS shall consist of parameters as given in Sub-section 4.2.2. 3.1.3 Configuration of Device Parameters Over the Air (OTA) The device shall support at least the below parameters to be configurable over the air (through SMS and GPRS). The updation shall be allowed only over an authenticated channel: 1. Setting/ Change of the Primary or Secondary IP and port number 2. Setting/ Change of the APN 3. Set configuration parameter like sleep time, overspeed limit, harsh braking, harsh acceleration, rash turning threshold limits etc. 4. Emergency control SMS Centre Number(s) 5. Configuring the vehicle registration number 6. Configuring the frequency of data transmission in normal / Ignition state / OFF state sleep mode/ Emergency state, etc. 7. Configuring the time duration for Emergency state 8. Capability to reset the device 9. Command to get the IMEI of the device Configurable commands must involve the following features: SET: For setting the parameters. GET: For enquiring regarding the parameters such as mobile number, GSM strength, vehicle number and other important parameters. CLR: For clearing certain commands, alarms, alerts etc. After each SET, GET, CLR command the device should send alert to 8/40 AIS-140 Backend Control Centre, as mentioned in Section 4 Alert 12, giving the details of Mode, mobile no/ IP of control center sending commands. 3.1.4 Tracking Device Health Monitoring Parameters The device shall send status of health parameters at configurable interval and this threshold value shall also be configurable over the air. It shall be possible for health parameters to be fetched on demand via command as set out below in Table 3B. Table 3B: Health Monitoring Parameter Sl. No. 3.1.5 Field Description 1 Start Character $

2 Header The header of the packet/ identifier 3 Vendor ID Vendor identification header 4 Firmware Version Version details of the Firmware used in EX.1.0.0 5 IMEI Identified of the sending unit. 15 digit standard unique IMEI no. 6 Battery percentage Indicates the internal battery charge percentage 7 Low battery threshold value 8 Memory percentage Indicates value on which low battery alert generated in percentage Indicates flash memory percentage used 9 Data update rate when ignition ON Indicates Packet on ignition ON frequency 10 Data update rate when ignition OFF Indicates Packet on ignition OFF frequency 11 Digital I/o status Inputs connected to the device. 12 Analog I/o status Analog input status

13 End character * SMS Fall Back In case of emergency state, (i.e. on pressing of Alert button), the device will shift to the SMS mode in case GPRS connectivity is not available. In such case, the device will send the Alert message and tracking data through SMS mode. Since SMS has the limitation of sending only 160 characters, so the tracking data to be sent in one SMS will have fields IMEI, Latitude, Direction, Longitude, Direction, location fix, speed, Cell ID, LAC (Location Area Code), Date and Time as per emergency alert . The details is provided in Sub-section 4.2.2. 9/40 AIS-140 4.0 COMMUNICATION PROTOCOL 4.1 Data Frame Format Table below (Table 4A) contains the listing of fields that the vehicle tracking devices would be required to send to the Backend Control Centre. The first 3 fields (Start character, Header for VLT with Emergency Buttons and Vendor ID, who has supplied the device) must be fixed in position as well as format (Header part of frame). Rest all other fields are required to be present in the location data sent by the devices to the backend, but can be in any sequence or with any separator between fields. The data value can be either in American Standard Code for Information Interchange (ASCII) or in HEX format. Device must transmit the Login message whenever it establishes (re-establishes after disconnection) its connectivity with Server with the specified fields. Login Message will carry following information: $DeviceName Vehicle number on which the device is installed. $IMEI 15 Digit IMEI number. $Firmware Version of the firmware used in the hardware. $Protocol -Version of the frame format protocol. $LastValidLocation Last location info saved at the device. Table 4A: Data Message Format Field Description Sample Data Start Character $ $ Header The header of the packet/ identifier Vendor ID Vendor identification header Firmware Version Version details of the Firmware used in EX.1.0.0 1.0.0 Packet Type Specify the packet type Depending upon the

context, every frame from tracking device must carry a qualification code. This helps to determine the state in which vehicle is at that time. NR = Normal EA = Emergency Alert TA = Tamper Alert (Optional) HP = Health Packet IN = Ignition On IF = Ignition Off BD = Vehicle Battery Disconnect BR = Vehicle Battery 10/40 AIS-140 Reconnect Packet Status BL = Internal Battery Low L=Live or H= History L IMEI Identified of the sending unit. 15 digit standard unique IMEI no. Vehicle Reg. No DL1PC9821 Mapped vehicle registration number 1 = GPS fix OR 0 = GPS 1 invalid GPS Fix 123456789012345 Date Date value as per GPS date time per GPS date time (DDMMYYYY) Time 050656 Time value as per GPS date time in UTC format (hhmmss) Latitude Latitude value in decimal degrees (not less than 6 places) 28.758963 Latitude Dir Latitude Direction. Example N

220714 N=North, S= South Longitude Longitude value in decimal degrees (not less than 6 places). 77.6277844 Longitude Dir Longitude Direction. W E=East, W= West Speed Speed of Vehicle as Calculated by GPS module in VLT. (in km/hrs.) (Upto One Decimal Value) Course over ground in degrees 25.1 No of Satellites Number of satellites available for fix 8 Altitude Altitude of the device in meters 183.5 PDOP Positional dilution of precision HDOP Horizontal dilution of precision Network Operator Name of Network Heading 11/40 310.56 INA Airtel AIS-140 Name Operator Ignition 1= Ignition On , 0 = Ignition Off 0 = Vehicle Battery disconnected Main Power Status

Main Input Voltage Internal Battery Voltage Emergency Status Tamper Alert (Optional) GSM Signal Strength 1= Vehicle Battery reconnected Indicator showing source voltage in Volts. (Upto One Decimal Value) Indicator for level of battery charge remaining. (Upto One Decimal Value) 1= On , 0 = Off 1 1 12.5 4.2 0 C MCC C = Cover Closed, O = Cover Open Value Ranging from 0 31 Mobile Country Code 404 MNC Mobile Network Code 10 LAC Location Area Code 00D6 Cell ID GSM Cell ID CFBD 25 NMR Neighbouring 4 cell ID (Network along with their LAC & Measurement Report) signal strength Neighbouring Cell ID Digital Input Status 4 external digital input status (Status of Input 1 to Input 3 (0=Off; 1=On)) Digital Output Status 2 external digital output status Frame Number Checksum

End Character (0=Off; 1=On) Sequence Number of the messages (000001 to 999999) Insures No error in transmission (optimal) Indicated End of the frame 12/40 0001 01 000005 16 * AIS-140 4.2 Messages & Alerts from Devices 4.2.1 Table below (Table 4B) contains the listing of alerts that need to come from the tracking devices. These alerts are applicable for both live packets as well as the history packets. Table 4B: Messages & Alerts Supported Alert ID Message & Alerts Remarks 1. Location Update Default message coming from each device 2. Location Update (history) Would be sent, if GPRS is not available at the time of sending the message in protocol format Zero, BLANK, NIL, etc. 3. Alert Disconnect from main battery If device is disconnected from vehicle battery and running on its internal battery 4. Alert Low battery If device internal battery has fallen below a defined threshold 5. Alert Low battery removed Indicates that device

internal battery is charged again 6. Alert Connect back to main battery Indicates that device is connected back to main battery 7. Alert Ignition ON Indicates that Vehicles Ignition is switched ON 8. Alert Ignition OFF Indicates that Vehicles Ignition is switched OFF 9. Alert GPS box opened (Optional) Optional message would be generated indicating GPS box opened 10. Alert Emergency state ON* When any of the emergency button is pressed 11. Alert emergency State OFF When emergency state of vehicle is removed 12. Alert Over the air parameter change When any parameter is changed over the air. Shall include the name of parameter changed and source of command 13. Harsh Braking Alert indicating harsh braking. for 14. Harsh Acceleration Alert indicating harsh acceleration. for 13/40 AIS-140

4.2.2 15. Rash Turning Alert indicating for Rash turning. 16 Device Tempered Alert Indicating Emergency button wire disconnect/ wire cut etc. In case of emergency alert, the alert message shall be sent to 2 different IP addresses hence the device shall support minimum 2 IP addresses (1 IP address for regulatory purpose (PVT data) and 1 IP address for Emergency response system other than the IPs required for Operational purpose. The PVT data will send the emergency alert to the system. Primary alert will go to the emergency response Backend Control Centre (NERS/ MHA) as may be notified by the Government of India in the schema below: Primary alert will go to the emergency response Backend Control Centre as notified by the Government of India in the indicative format below (Table 4C): Table 4C: Indicative Format for Alert to Emergency Response System Attribute Value / Description Size Packet Header EPB, The unique identifier for all messages from VLT Character, 3 bytes Packet Header EPB, The unique identifier for all messages from VLT Character, 3 bytes Message Type Message Types supported. Emergency Message (EMR) or Stop Message (SEM) Unique ID of the Vehicle Character, 2 bytes Vehicle ID Character,15 bytes (IMEI Number) Packet Type NM Normal Packet, SP Stored Packet 14/40 Character, 2 bytes AIS-140

Date Date and time of location the location obtained from the data in DDMMYYYY hhmmss format Character,14 bytes GPS Validity A Valid, Character, 1 byte Latitude Latitude Latitude Direction V Invalid in decimal degrees - dd.mmmmmm format N North, Double, 12 bytes Character, 1 byte S South Longitude Longitude in decimal degrees dd.mmmmmm format Double, 12 bytes Longitude Direction E East Character, 1 byte Altitude Altitude in meters (above sea level) Double, 12 bytes Speed Speed of Vehicle as Calculated by GPS module in VLT. (in km/hr) Float, 6 bytes Distance Distance calculated from previous GPS data Float, 6 bytes Provider G - Fine GPS Character, 1 byte W West N - Coarse GPS or data from the network Vehicle RegnNo

Registration the Vehicle Reply Number The mobile number to which Test response needs to be sent. (Emergency Mobile No. as specified by MHA/MoRTH/States.) The 32 bit checksum of all the characters from the header up to the CRC field CRC Number of Character, 16 bytes 0 8 bytes *Above format is indicative only. These Format will be notified by the Government of India time to time. 4.3 Testing of Configuration of Device Parameters Over the Air (OTA) The following testing will be done for 1. Setting/ Change of the Primary or Secondary IP and port number 2. Setting/ Change of the APN 3. Set configuration, parameter like sleep time for speed, harsh braking, rash turns, etc. 15/40 AIS-140 4. Emergency SMS Centre Number 5. Configuring the vehicle registration number 6. Configuring the frequency of data transmission in normal / Ignition state / OFF state sleep mode, Emergency state, etc. 7. Configuring the time duration for Emergency state 8. Capability to reset the device 9. Command to get the IMEI of the device Configurable commands must involve the following features: SET: For setting the parameters. GET: For enquiring regarding the parameters such as mobile number, GSM strength, vehicle number and other important parameters. CLR: For clearing certain commands, alarms, alerts etc. 5.0 CONSTRUCTION AND INSTALLATION (To be verified on component level and target vehicle level approval) 5.1 Requirements on vehicle interface for VLT with Emergency Button Connector for Power The requirements for interface shall be as below or as agreed between vehicle manufacturer and device manufacturer. Standard connectors conforming to ISO 15170 shall be used at vehicle side. Connector requirements shall be as per Annexure C, Clause 1.1 (Sl. No 1 - Low power systems 1) However, Device/System side connector/s shall be pre-agreed with equipment manufacturer by Vehicle OEM in the case of OE fitment of the systems System supplier in case of retro fitment in aftermarket. These requirements do not apply to integrated systems with vehicle where integration is done by vehicle manufacturer and /or System Integrator. 5.2 Requirement of Emergency System Emergency button shall be one time press type. Separate release action

from authorized server shall be required to bring back the emergency button to normal mode or clear emergency flag. 5.3 Physical Mounting The VLT system shall be mounted in a suitable location such a way that it is not easily accessible /exposed to passengers. This requirement shall not be applicable in case of combined systems VLT with HMI (Human Machine Interface) display in front of driver. 16/40 AIS-140 Test agency to verify this on vehicle level approval. Emergency button(s) shall be fitted in such a way that every passenger including driver shall be able to access the Emergency button(s). Passenger Car shall have 2 emergency buttons on each passenger row easily assessable by each of the passenger. There shall also be one dedicated emergency button for the driver. Passenger Transport bus shall have emergency buttons at locations easily visible & assessable to all the passengers such as every 2 meters on both the sides on passenger seating area. For seats reserved for ladies there shall be a dedicated panic button for each row. Test agency to verify this on vehicle level approval. 5.4 Power Supply The vehicle tracking device will be installed on vehicles in which the power supply voltage from vehicle battery is widely varying (12V, 24V etc.) and also the power supply is not as stable as that in case of fixed locations, especially during engine start-up and braking when the voltage can fall to as low as 9V. Typically electronic devices are very sensitive to power surges and spikes, and equipment may fail if they do not receive stable power supply. The devices will need to have a resilient power supply unit that can withstand such fluctuations and the devices also need to have power backup so that they continue to function for some duration when the vehicle battery is not functional or is disconnected from the devices. Vehicle power interface shall have One common ground linked to vehicle chassis One permanent power Supply (12/24V) connected to the vehicle battery One non-permanent power line (12/24V) connect to the battery after ignition 5.4.1 Electrical Wiring The wiring harness used in the device shall be tested for flammability as per IS 2465. 6.0 FUNCTIONAL, PERFORMANCE, DURABILITY, ENVIRONMENTAL AND PROTOCOL TESTS 6.1 Vehicle Level Functional Tests Following functionalities for each of the systems shall be demonstrated at the vehicle, in case system is provided by the vehicle OEM. 1. Vehicle Location Tracking With Emergency Button 1. Vehicle OEM shall only provide/ installed devices approved under component level testing. 2. System transmits PVT information to Backend Control Center (2 different IPs) at user configurable frequency (minimum 5 seconds) via GSM/GPRS. 17/40 AIS-140 6.1.1.3

System to communicate to control center on the occurrence of the alerts captured in Communication Protocol of Section 4. 6.1.2 Emergency Request Emergency request function - When the emergency buttons (as applicable) placed anywhere in the vehicle is pressed by any passenger / crew, make sure that the emergency request message is send/received at the control center. 6.2 Component Level Functional Tests Following functionalities for each of the systems shall be demonstrated. At the choice of the manufacturer, these functionalities can also be alternately demonstrated at the vehicle level and shall be deemed to be complied with at component level as well. 1. Vehicle Location Tracking 1. Standard connector provided for Power and other signals as per Annexure C. 2. Configuration of device as per the standard format mentioned in Section 4. Local configuration upload shall be verified. Configuration upload from control center shall be verified. 3. Vehicle Location data transmission to Backend Control Center. 4. Backend Control Centre shall be able to check the version of firmware loaded on the system. 5. Update the firmware of the system from Backend Control Centre 2. Device Level Functional, Performance & Durability Tests The tests to be performed for device level approvals are as listed below. These functionality check will be performed after each test as acceptance criteria Tested systems shall satisfy general functional requirements at all the specified ranges during the test and after the test. Following to be checked after testing: 6.3.1 i) Tracking functionality shall be checked via Backend Control Centre for the VLT system (Functional Test number 1 as per Table 6A Functional Testing. Functional Testing Functional Testing as described in the Table 6A below shall be done with the acceptance criteria in Table 6A after completion of all the Performance & Durability Tests as listed in Table 6B. 18/40 AIS-140 Table 6A: Functional Testing Sl. No 1 Test Tracking Functionality Test Test Procedure

The test shall be conducted on VTL to determine the proper functioning of VLT with Emergency Button by testing its connectivity to Backend Control Centre (Government authorized server). Procedure: The VLT with Emergency Button shall be connected to vehicle battery to switch it on. The VLT with Emergency Button shall be tested for the connectivity to server and its capability to send two location messages 2 Location Accuracy Test This test shall be conducted on VLT with Emergency Button. The receiver is placed into a cold start state usually by a command sent to the receiver through a test connection and then a fairly strong navigation signal simulating in L and/ or S band is sent. The time it takes for the receiver to determine its first good location fix is recorded. Test is done many times (>15 times) over many conditions and the results are averaged. Acceptance Criteria: 2.5 m CEP or 6 m 2DRMS 3 Acquisition Sensitivity Test This test shall be conducted on VLT with Emergency Button. Procedure: Set the simulator to output navigation signal simulating L and/or S band to a particular location with a very level so that the tracking is not possible. Gradually increase the signal level that allows the receiver to successfully perform a cold start TTFF within a specified time frame. The minimum signal level that allows acquisition 19/40 AIS-140 is referred as to the acquisition sensitivity. 4 5 Tracking Sensitivity Test Cold-Start Time to First Fix (TTFF) Test Acceptance Criteria: The acquisition sensitivity shall be minimum (-) 148 dBm. This test shall be conducted on VLT. Procedure: The device under this test is locked on to the simulator's output frequency (navigation signal simulating L and/or S band) and the simulator power output is lowered until the lock is lost. Multiple repetition of the test with different satellite geometries ensures that an accurate average measure is recorded. Acceptance Criteria: The tracking sensitivity shall be equal to or better than (-) 165 dBm.

The device in this test is placed into a cold start state. The time it takes for the device to determine its first good location fix is recorded. The cold start test is performed several times and the results are averaged. Acceptance Criteria: The cold start TTFF shall be less than 40 seconds at Open Sky condition or (-) 130 dBm. 6 Warm-Start Time to First Fix Test In this test the device is started in warm start mode and time taken by device to determine the first valid location fix is recorded. This is done several times and results are averaged. Acceptance Criteria: The warm start TTFF shall be less than 30 seconds at Open Sky condition or (-) 130 dBm. 7 Hot-Start Time to First Fix Test In this test the device is started in Hot start mode and time taken by device to determine the first valid location fix is recorded. This test is performed several times and results are averaged. Acceptance Criteria: The hot start TTFF shall be less than 5 seconds. 8 SIM Test This test is to check the suitability of the SIM and communication module. The test shall be conducted to determine the effectiveness and operation of the GPRS module with OTA network switching capabilities on demand as well as automatically in real-time. The test consist of two type of testing as below: 20/40 AIS-140 1. The device would be tested to perform as per the protocol using an embedded SIM. 2. The GPRS module & SIM, shall support: o SMS, Data (GPRS, TCP/IP) and o Support multiple network OTA switching capabilities (On Demand as well as Automatic Switching on realtime basis) Acceptance Criteria: In the testing, vendors has to demonstrate the embedded SIM based tracking and multiple network OTA switching capabilities (On Demand as well as Automatic Switching on real-time basis) for effective network management and transmission. 9 Interference Test Interference testing is a type of test, in which Cold Start/Hot Start test are performed with device exposed to interfering signals and the performance as recorded. In this test, the GPS receiver is turned on and allowed to achieve a location fix. The jamming signal is

then added to the GPS signal at a level that is detectable to the GPS receiver. The jamming signal power level is increased in 1 dB increments until the first degradation of the GPS receiver is noticed. This is typically a dropped satellite. The jamming signal power level is again slowly increased until the GPS receiver loses its 3D navigation fix. Acceptance Criteria: The Interference shall not result in any degradation of the Cold Start/Hot Start TTFF times. In addition, it shall not result in any degradation of the absolute location accuracy required and the same shall be 2.5 m CEP or 6 m 2DRMS. 10 Multipath Test This test is a simulated frequency test conducted to determine the effect of multipath signals. The signal from a single satellite is simulated to arrive at the device via two or more paths. One path is typically a direct path, and other paths are typically a reflection of the same signal from building or structure. Multipath testing is a kind of a meta-test in that some of the above tests are done with the addition of multi-path simulation of one or more satellites by the GPS signal simulator. 21/40 AIS-140 Acceptance Criteria: The multipath shall not result in any degradation of the Cold Start/Hot Start TTFF times. In addition, it should not result in any degradation of the absolute location accuracy required and the same shall be 2.5 m CEP or 6 m 2DRMS. 6.3.2 Performance & Durability Test The Performance & Durability Test is listed in Table 6B. Sl. No 1 2 Table 6B: Performance & Durability Test Test Procedure Test Shock Test Shock test is performed to provide a degree of confidence that the device can physically and functionally withstand the relatively infrequent, non-repetitive shocks encountered in transportation environments. This test provides an assessment of the effect of the shocks on the performance of the device. The test shall be performed as per IS 9000-part 7 2006. Severity Level = 15g, Impact duration = 11ms, Impact Type = Half sine, Total number of impact = 9 (3 on each axis) Vibration Test Acceptance Criteria: Device after the shock test shall be required to meet the provisions of Functional Test Number 1 as listed in Table 6A. This test is performed to check that the device the device can physically and functionally withstand the vibration

exposures in the life cycle typically encountered in a vehicular environment. The test shall be performed as per IS 9000-part 8 1981. The test specimen mounted on a suitable support shall be rigidly fixed on a suitable vibrating machine constructed to produce simple harmonic function (total amplitude of 1.5 mm) and shall be subjected to vibration through a frequency range of 1055-10 Hz in a sweep period of 1 min with continuously varying frequencies. The vibration shall be applied for not less than 1 h in the directions of each of the 3 major axes of the light. Acceptance Criteria: During and after the test the device shall be required to meet the provisions of Functional Test Number 1 as listed in Table 6A. 22/40 AIS-140 3 Ingress Protection (IP) The vehicle tracking devices must be able to work in dusty environment that are typically encountered by the public transport vehicles where these would be installed. IP rating (IS/ IEC 60529 - 2001) is used for specifying the environmental protection characteristics of the tracking device. The device will be tested for dust and water ingress according to IP 65 rating. Acceptance Criteria: The device shall be required to meet the provisions of Functional Test Number 1 as listed in Table 6A. 4 EMI /EMC The Electromagnetic Interference (EMI) and Electromagnetic Compatibility (EMC) tests are performed to assess whether the device performs its intended functions in the electromagnetic environment to which it would be exposed. Further, the device shall not generate electromagnetic disturbances that may influence other equipment in the vicinity. Acceptance Criteria: The device shall meet the EMI/EMC requirements as per AIS 004 (Part 3). 5 Battery Backup Test Battery backup is the amount of time that the device battery can support sending the data without being connected to the power source. This test will be performed by disconnecting the input charging voltage to the device. On disconnecting the external supply, battery would use its charge capacity to send data through GPRS. Time duration between external power disconnect to the last data packet time denotes the battery backup time. Acceptance Criteria: Device shall be able to work in active mode for a period of 4 hours or more at the polling/ transmission rate of 60 sec 6 Reverse Polarity Protection without

Fuse The device to be tested shall be connected to a reversed voltage of 14 V for 12 V systems and 27 V for 24 V systems for 2 min after connecting the system to the suitable circuit. Acceptance Criteria: After test; the device shall be required to meet the provisions of Functional Test Number 1 as listed in Table 6A. 23/40 AIS-140 7 8 9 Wiring Harness Flammab ility Test Wiring Harness Electrical Properties Free Fall Flammability Test: The wiring harness used in the device shall be tested for flammability as per IS 2465. As per AIS 028 or DIN72551 or ISO 6722 IS 9000 (Part VII/Sec 4) Free fall at 500 mm. Acceptance Criteria: After test the device shall be required to meet the provisions of Functional Test Number 1 as listed in Table A 10 Performance Parametric Test During testing, VLT with Emergency button shall be kept inside test chamber in power ON condition. (Nine points, tri temperature/tri voltage) (System shall be stabilized for minimum 5 min at each condition. At each test point the system will be powered on and shut down 5 times with a duration of 1 min ON and 1 min OFF time) Following are the various voltages & temperatures 24V System 12V System 18V, -25C 9V, -25C 18V, +80C 9V, +80C 18V, Room Temperature 9V, Room Temperature 27V, -25C

13.5V, -25C 27V, +80C 13.5V, +80C 27V, Room Temperature 13.5 V, Room Temperature 32V, -25C 16V, -25C 32V, +80C 16V, +80C 32V, Room Temperature 16V, Room Temperature Acceptance Criteria: The device shall be required to meet the provisions of Functional Test Number 1 as listed in Table A for each value of the temperature and voltage. 24/40 AIS-140 11 Insulation Resistance Test Test shall be conducted as per ISO 167502:2010 after damp heat test mentioned in point 3 of the Section 6.4. System/components shall remain 0.5 h at RT after the damp heat test. Test shall be conducted With a voltage of 500 V DC. Acceptance Criteria: Insulation Resistance shall be > 1 M. No arcing or puncturing of insulation allowed shall be observed 12 Load Dump Test Pulse 5a VLT shall be tested for this. For 12 V System: A Voltage spike of 65V, 4 Ohms 200ms pulse-5a as per standard ISO 7637-2: 2004 For 24 V System: A Voltage spike of 123V, 8 Ohms 200ms pulse-5a as per standard ISO 7637-2: 2004. Acceptance Criteria: Device shall meet functional class A as per ISO 7637-2: 2004. After test, the device shall be required to meet the provisions of Functional Test Number 1 as listed in Table 6A. 6.3.3 Device Level Environmental Tests The environmental tests to be performed for device level approvals are as listed in Table 6C. Following to be checked after testing: i) Tracking functionality shall be checked via Backend Control Centre for the VLT with Emergency Button. Table 6C: Device Level Environmental Test Sl. No 1

Test Test Procedure Dry Heat / High Temperature Test The high temperature test is used to evaluate effects of high temperature conditions on safety, integrity, and performance of the device. The test shall be carried out in accordance with Indian Standard IS: 9000 (Part 3/Sec 5) the device shall be subjected to temperature of 70 2C for 16 h in high temperature. Test with device in working condition. The recovery period shall be 2 h. 25/40 AIS-140 Acceptance Criteria: Device during and after the high temperature test the device shall be required to meet the provisions of Functional Test Number 1 as listed in Table 6A. 2 3 Cold Test Damp Heat Test The test shall be carried out in accordance with IS 9000 (Part 2/Sec 4 - 1977). The device under test shall be subjected to temperature of 10 2C for 2 h with device in working condition. The recovery period shall be 2 h. Acceptance Criteria: Device during and after the cold test, the device shall be required to meet the provisions of Functional Test Number 1 as listed in Table 6A. The device under test shall be tested according to IS 9000 (Part 5/Sec 2 - 1981). The test is carried out at +25 to +55 C, Humidity 95%. Six cycles (each test cycle of 24 h) shall be run with device in off condition. Functional test shall be carried out with power in On condition at start of 2nd, 4th and 6th cycle. Acceptance Criteria: Device during and after the test the device shall be required to meet the provisions of Functional Test Number 1 as listed in Table 6A. 4 Temperature Shock Temperature shock test is carried out to determine if the device can withstand sudden changes in the temperature of the surrounding atmosphere without experiencing physical damage or deterioration in performance. The device shall be tested as per IS 9000 (Part 14/Sec 2) 1978. Exposure time would be 3 hours/cycle and number of cycles would be two. Acceptance Criteria: Device after the test the device shall be required to meet the provisions of Functional Test Number 1 as listed in Table 6A. 5 High Temperature Test The high temperature test is used to evaluate effects of high temperature conditions on safety, integrity, and performance of the

device. The test shall be carried out in accordance with Indian Standard IS: 9000 (Part 3/Sec 5) the device shall be subjected to temperature of 70 2C for 16 h in high temperature. Test with device in working condition. The recovery period shall be 2 h. Acceptance Criteria: Device during and after the high temperature test the device shall be required to meet the provisions of Functional Test Number 1 as listed in Table 6A. 26/40 AIS-140 6 Salt Spray Test The salt spray test is conducted to check corrosion resistance of device. The device shall be tested according to Clause 4.8 of IS 10250 for 96 h. Acceptance Criteria: The device shall be required to meet the provisions of Functional Test Number 1 as listed in Table 6A. 7 6.3.4 High Voltage Test The test is conducted to ensure service life requirements & functionality. The device under test shall be operated for 60 minutes at 18 V for 12 V systems & 36 V for 24 V systems. This test is as per ISO 16750-2:2010 Acceptance Criteria: Device during and after the test the device shall be required to meet the provisions of Functional Test Number 1 as listed in Table 6A. Protocol Testing This set of testing needs to be done for all cases namely vehicle level testing and component (Device) level testing. Protocol is a set of rules to be followed by the device while sending data to the Backend Control Centre. The protocol comprises data update rate, number of fields, start character, end character, alert type etc. Protocol testing involves checking the compliance of data sets received by the Backend Control Centre against the protocol both with respect to the data fields as well the format. It is expected that the data coming to a central server shall be exactly as required under the protocol. Table below (Table 6D) mentions the validation process for the protocol communication. Table 6D: Protocol Testing Parameters Field Description Validation Process Field Description Start Character $ Header The header of the packet/ identifier Vendor ID Vendor identification header Firmware Version Version details of the Firmware used in EX.1.0.0 Packet Type Specify the packet type

NR = Normal EA = Emergency Alert TA = Tamper Alert 27/40 AIS-140 HP = Health Packet IN = Ignition On IF = Ignition Off BD = Vehicle Battery Disconnect BR = Vehicle Battery Reconnect BL = Internal Battery Low Packet Status L=Live or H= History IMEI Identified of the sending unit. 15 digit standard unique IMEI no. Vehicle Reg. No Mapped vehicle registration number GPS Fix 1 = GPS fix OR 0 = GPS invalid Date per GPS date time Date value as (DDMMYYYY) Time value as per GPS date time in UTC format (hhmmss) Time Latitude Latitude value in decimal degrees (with minimum 6 decimal places) Latitude Dir. Latitude Direction. Example N=North, S= South Longitude Longitude value in decimal degrees (with minimum 6 decimal places) Longitude Dir. Longitude Direction. Example E=East, W= West Speed Speed of Vehicle as Calculated by GPS module in VLT.(in km/hr) Heading Course over ground in degrees No. of Satellites Number of satellites available for fix Altitude Altitude of the device in meters PDOP Positional dilution of precision

HDOP Horizontal dilution of precision Network Operator Name Name of Network Operator. Ignition 1= Ign On , 0 = Ign Off Main Power Status 0 = Vehicle Battery Disconnected 1= Vehicle Battery Reconnected Main Input Voltage Indicator showing source voltage in Volts. Internal Battery Indicator for Level of battery charge remaining 28/40 AIS-140 Voltage Emergency Status 1= On , 0 = Off Tamper Alert (Optional) C = Cover Closed , O = Cover Open GSM Signal Strength Value Ranging from 0 31 MCC Mobile Country Code MNC Mobile Network Code LAC Location Area Code Cell ID GSM Cell ID NMR (neighbouring Cell ID) Neighbouring 4 cell ID along with their LAC and signal strength Digital Input Status 4 external digital input status (Status of Input 1 to Input 3 (0=Off; 1=On)) Digital Output Status 2 external digital output status (0=Off; 1=On) Frame Number Sequence Number of the messages (000001 to 999999) Checksum

Insures No error in transmission (optional) End Character Indicated End of the frame The following test would be performed along with the protocol testing of the device: a) Memory Storage The device shall support 40000 or more positional logs/packets. This is a functional test and the device will be simulated to be in non GPRS coverage area and the logs will be maintained. The capacity of logging will be checked by monitoring the logs on the device. b) Messages & Alerts from Devices Table below (Table 6E) contains the listing of alerts that need to come from the tracking devices. These alerts are applicable for both live packets as well as the history packets. Table 6E: Messages & Alerts Alert ID 1. Message & Alerts Location Update 2. Location Update (history) 3. Alert Disconnect from main battery 29/40 Remarks Default message coming from each device Would be sent, if GPRS is not available at the time of sending the message If device is disconnected from vehicle battery and running on its internal battery AIS-140 4. Alert Low battery If device internal battery has fallen below a defined threshold 5. Alert Low battery removed Indicates that device internal battery is charged again 6. Alert Connect back to main battery Indicates that device is connected back to main battery 7. Alert Ignition ON Indicates that Vehicles Ignition is switched ON 8.

Alert Ignition OFF Indicates that Vehicles Ignition is switched OFF 9. Alert GPS box opened (Optional) Message would be generated indicating GPS box opened 10. Alert Emergency state ON* When any of the emergency button is pressed 11. Alert emergency State OFF Emergency state of switch will be cancelled by backend server, when emergency state of vehicle is removed 12. Alert Over the air parameter change When any parameter is changed over the air. Shall include the name of parameter changed and source of command 13. Harsh Braking Alert indicating for harsh braking. 14. Harsh Acceleration Alert indicating for harsh acceleration. 15. Rash Turning Alert indicating for Rash turning. * In case of Emergency Alert ON system, the alert message should go in the below format as set out in Table 6F. This emergency alert message shall be sent to 2 different IPs; i.e. the device shall support minimum 2 IPs simultaneously. Table 6F: Message Format Attribute Value / Description Size Packet Header EPB, The unique identifier for all messages from VLT Character, 3 bytes

Message Type Message Types supported. Emergency Message (EMR) or Stop Message (SEM) Character, 2 bytes 30/40 AIS-140 Device ID Vehicle ID Unique ID of the Vehicle (IMEI Number) Character,15 bytes Packet Type NM Normal Packet, SP Stored Packet Character, 2 bytes Date Date and time of the location obtained from the location data in DDMMYYYY hhmmss format A Valid, V Invalid Character,14 bytes Latitude Latitude in decimal degrees dd.mmmmmm format Double, 12 bytes Latitude Direction N North, S South Character, 1 byte Longitude Longitude in decimal degrees dd.mmmmmm format Double, 12 bytes Longitude Direction E East W West Character, 1 byte Altitude Altitude in meters (above sea level) Double, 12 bytes GPS Validity Speed Distance Provider Vehicle RegnNo Reply Number CRC

7.0 Character, 1 byte Float, 6 bytes Speed of Vehicle as Calculated by GPS module in VLT. (in km/hrs.) from Float, 6 bytes Distance calculated previous GPS data G - Fine GPS Character, 1 byte N Coarse GPS or data from the network of the Character, Registration Number Vehicle bytes The mobile number to which 0 Test response need to be sent. (Emergency Mobile No. as specified by MHA/MoRTH/States.) The 32 bit checksum of all the characters from the header up to 8 bytes the CRC field 16 DEVICE TO BACKEND COMMUNICATION MECHANISM The VLT device would transmit data to the Backend Control Centre using GPRS wireless connectivity (with SMS fall back) as per the protocol provided in respective sections (Sub-section 6.3.4). The data from the devices would travel over the wireless telecom service provider network and finally get delivered at the Backend Control Centre. Since the permit holders/Device suppliers would require to have 31/40 AIS-140 a valid communication plan on SIM cards on the devices and would avail services from multiple telecom service providers, the data would be transmitted to the Backend Control Centre using the networks of multiple telecom service providers. A suitable control mechanism would be established for the data transfer from VLT to Backend Control Centre, as only the authorized devices should be able to transfer data to the Backend Control Centre and a mechanism for authenticating the devices/SIMs shall also be put into place. The following mandatory provisions will have to be made in the Backend Control Centre: 32/40 AIS-140 1. Registration and activation of the device(s) fitted on the vehicle, including the details of vehicle registration number, engine number, chassis number, vehicle make and model, device make and model, and telecom service providers name. 2. Re-registration/re-activation of the device(s) fitted on the vehicle in case of any change in device or telecom service provider, etc. 3. Regular health check of the device(s) fitted on the vehicle, as per the parameters and frequency defined in Sub-section 3.1.4. 4. Administration/configuration of devices for any changes in the parameters as decided by the respective state from time to time. 5. Notification of alerts in case of press of an Alert Button fitted on the vehicle, in the protocol defined in Section 4. 6. Notification of alerts in case of defined deviations by vehicle such as over-speeding, deviation from defined route/geographic area, time of operation, etc. 7. Location tracking of the vehicle including real-time as well as history tracking for up to last 90 days. 8. Notification to the permit-holder through SMS in case any device(s) stops functioning/sending data to the Backend Control Centre. 9. Reports of the vehicles with devices not working/sending data beyond defined number of days (1 day, 3 days, 7 days and 30 days). 10. Ensure that the security and privacy of the data is maintained in accordance with applicable laws/guidelines of various government

authorities. In addition to the above mandatory provisions, the Backend Control Centre can provide any other optional features. The mechanism to set up the Backend Control Centre shall be decided by the respective states. The states can chose any of the following options for setting up the Backend Control Centre: 11. States can set up their own dedicated Backend Control Centre, meeting the above listed mandatory provisions and any other optional features as they may decide. 12. States can allow telecom service providers to offer Backend Control Centre as a Value Added Service (VAS) to the permit holders, meeting the above listed mandatory provisions and any other optional features as they may decide. In this case, the telecom service providers shall provide access to the Backend Control Centre to government officials, as decided by the respective state. 33/40 AIS-140 ANNEXURE A: INFORMATION TO BE SUBMITTED FOR TYPE APPROVAL 1.0 VLT SYSTEM DETAILS a. Make b. Type c. Model No. d. Part No. e. Installation layout: Attach drawing showing location in vehicle. 2.0 VEHICLE LOCATION TRACKING AND EMERGENCY BUTTONS f. Make g. Model No. h. Part No. i. Connector used j. Connector used for antennas 1. main GSM antenna 2. GPS antenna 3. WLAN antenna 3.0 SYSTEM SOFTWARE k. Make l. Version m.Operating System Details with Version 4.0 COMMUNICATION PROTOCOL USED a. Vehicle to Center VLT to Control Center Command Set for Configurations 5.0 DESCRIPTION OF DEVICE 6.0 DRAWINGS 6.1 Device/System Drawing. 6.2 Vehicle installation Drawing. 7.0 INSTRUCTIONS MANUAL 34/40 AIS-140 ANNEXURE B: CRITERIA FOR EXTENSION OF TYPE APPROVAL

B1.0 In case of following changes, Functional, Performance, Durability and Environmental Tests which are necessary for establishing compliance are listed below Changes in System Tests to be conducted B1.1 Change in Make, Model, Type, accompanied with or without a Part No of Vehicle Location Tracking (VLT) and Vehicle Health Monitoring. Applicable tests as per Section 6 and Functional verification at system integration level or component level as applicable. B1.2 Change in onboard layout of ITS component or complete system Verification at system integration level along with target vehicle B1.3 Change in software of ITS System Functional verification at system integration level. B.1.4 Change in wiring harness and connectors Connector requirements specified in this standard. 35/40 AIS-140 ANNEXURE C: PHYSICAL INTERFACES (CONNECTORS) FOR POWER AND I/Os The below section is for new vehicles and not for the retro-fitment of ITS systems on in-use vehicles. Device/System side connector/s shall be as per the equipment manufacturer by in case of retro fitment in aftermarket. Provisions for Power connectors and Power supply to be made by Manufacturers in case of OE fitment & Dealer / Permit holder in case of retro fitment of systems outside vehicle manufacturer facility. These requirements do not apply to integrated systems with vehicle where integration is done by vehicle manufacturer and /or System Integrator. 1.0 Vehicle Side Connectors The vehicles shall be equipped with connectors with appropriate fuse protection for interfacing systems implements the functions Power for physical systems are supplied by vehicle battery which supplies power to all electrical system in the vehicle. When the engine is running, the vehicle battery is in charge and the systems shall consume normal power needs. But when the engine is turned off, the power consumption by systems shall be limited by means of sleep modes or auto shut off. Considering the power requirements for equipment packages, the systems are grouped as ITS System Classification Low Power Systems Max Power Up to 120 W Typical Systems / Packages VLT with Emergency Button

The power interface shall have One common GROUND linked to vehicle chassis - GND One permanent power line (12/24V) linked to the battery after Manual Switch B+ One non-permanent power line (12/24V) linked to the battery after Main Switch SW+ 1.1 Minimum Connector Requirements The minimum connector requirements are formulated as following. 36/40 AIS-140 Sl. No. Recommended Electrical Provisions 1. Low Power System 1 (Mandatory Provision) Max Power Up to 120 W Applicable ITS Systems Telematics Device/VLT System with Emergency Button Minimum Requirement Recommended Connector B+, SW+, GND OEM to protect ISO 15170-B13.1-Sn/K1 Socket (Female) Connector The OEM may provide optional auxiliary connectors of their choice for meeting other functional requirements. 1.2 Connector labeling in Wiring Harness: Vehicle side wiring shall have the following labeling for the connectors Labeling Requirement Recommended Electrical Provisions Low Power System 1 ITS 120 W (Mandatory Provision) Low Power System 2 ITS 120 W (Mandatory Provision) High Power System 1

ITS 360 W (Mandatory Provision) CAN Interface (OBDII CAN) ITS CAN (Mandatory Provision) 1.3 Connector Cavity/PIN Assignment Power Connector: ISO 15170-B1-3.1-Sn/K1, ISO 15170-B2-3.1-Sn/K1 Pin 1 B+ Pin 2 SW+ Pin 3 GND CAN Connector: ISO 15170-B1-4.1-Sn/K1 Pin 1 CAN High Pin 2 CAN Low Pin 3 Option CAN Ground Pin 4 Not used 37/40 AIS-140 1. Device/System connectors Device/System side connector/s shall be pre-agreed with equipment manufacturer by 1. Vehicle OEM in the case of OE fitment of the systems 2. Permit holder or Dealer in case of retro fitment of systems outside vehicle manufacturer facility 38/40 AIS-140 ANNEXURE D: (See Introduction) COMPOSITION OF AISC PANEL * Name Organization Convener Mr. Rakesh Jain Delhi Integrated Multi-Modal Transit System Ltd. (DIMTS) Members Representing Mr. Prashant Tiwari /Shri Alok Sethi Delhi Integrated Multi-Modal Transit System Ltd. (DIMTS) Mr. A. A. Deshpande/ Mr. M. M. Desai / Mr. K. B. Patil

The Automotive Research Association of India (ARAI) Director / Mr. Samir Sattigeri /Shri M. M. Pathak Central Institute of Road Transport (CIRT) Mr. G. R. M. Rao Vehicle Research & Dev. Estt. (VRDE) Dr. Madhusudan Joshi International Centre for Automotive Technology (ICAT) Mr. K. K. Gandhi SIAM Mr. S. Ravishankar/ Mr. D. Balakrishnan/Ms. Suchismita Chatterjee Ashok Leyland Technical Centre (SIAM) Mr. Girish Kodolikar Force Motors Ltd. (SIAM) Mr. Sanjay Tank Mahindra and Mahindra Ltd. (SIAM) Mr. Shrikant V. Joshi / Mr. P S Gowrishankar, / Mr. Sharad S. Bhole Tata Motors Ltd. (SIAM) Mr. Suchindran M Toyota Kirloskar Motor Pvt. Ltd. (SIAM) Mr. Jitendra Malhotra/ Mr. Sumit Sharma/ Mr. Raj Kumar Diwedi Maruti Suzuki India Ltd.(SIAM) Mr. RajendraKhile/Mr Karuppasamy Renault Nissan Technology and Business Centre (SIAM) Mr. S Ramiah TVS Motor Company Ltd. (SIAM) Mr. Arun Sivasubrahmaniyan Hero Motocorp Ltd. (SIAM) Mr. R. Narasimhan Bajaj Auto Ltd. (SIAM) Mr. Uday Harite ACMA Mr. Raju Agarwal / Castmaster Mobitec India Pvt Ltd. Mr. Rahul Jain Mr. Vishwajit Joshi KPIT Cummins Infosystems Ltd * At the time of approval of this Automotive Industry Standard (AIS)

39/40 AIS-140 ANNEXURE E (See Introduction) COMMITTEE COMPOSITION * Automotive Industry Standards Committee Chairperson Mrs. Rashmi Urdhwareshe Director The Automotive Research Association of India, Pune Members Representing Shri Priyank Bharti Ministry of Road Transport and Highways (Dept. of Road Transport and Highways), New Delhi Representative from Ministry of Heavy Industries and Public Enterprises (Department of Heavy Industry), New Delhi Shri S. M. Ahuja Office of the Development Commissioner, MSME, Ministry of Micro, Small and Medium Enterprises, New Delhi Shri Shrikant R. Marathe Former Chairman, AISC Shri R.R. Singh Bureau of Indian Standards, New Delhi Director Central Institute of Road Transport, Pune Director Indian Institute of Petroleum, Dehra Dun Director Vehicles Research and Establishment, Ahmednagar Director International Centre for Automotive Technology Director Global Automotive Research Centre Director Indian Rubber Manufacturers Research Association Representatives from Society of Indian Automobile Manufacturers Shri T. R. Kesavan Tractor Manufacturers Association, New Delhi Shri Uday Harite Automotive Components Manufacturers Association of India, New Delhi

Member Secretary Shri Vikram Tandon Dy. General Manager The Automotive Research Association of India, Pune * At the time of approval of this Automotive Industry Standard (AIS) 40/40 Development

Recently Viewed Presentations

  • Between the Wars

    Between the Wars

    Music History Lecture Notes Twentieth Century Art Music 1900 - 2000 This presentation is intended for the use of current students in Mr. Duckworth's Music History course as a study aid.
  • SEG 2100 Software Design II - Philadelphia University

    SEG 2100 Software Design II - Philadelphia University

    What is an Activity Diagrams? An activity diagram is like a state diagram.. Except most transitions are caused by . internal. events, such as the completion of a computation. It shows actions and of control and data between them.
  • Searching for Axionic Blue Isocurvature Perturbations Daniel J.

    Searching for Axionic Blue Isocurvature Perturbations Daniel J.

    gravity induced secular growth effects imprint adiabatic. information onto the isocurvature fields. A measurement of a blue spectral index larger than 2.4 gives . evidence for a field with time dependent mass during inflation [1509.05850] improved the computation of 0904.3800...
  • International Trade: Testing Comparative Advantage

    International Trade: Testing Comparative Advantage

    These hold both in final equilibrium, and in transient equilibrium where specie is flowing. Equations (32') and (33') imply that the equilibrium relative wage does depend on the distribution of the world money supply.
  • UCSD Linguistics/CSE 256: Topic Models

    UCSD Linguistics/CSE 256: Topic Models

    Winter 2009 Lecture 5: Unsupervised text categorization Roger Levy Many thanks to Tom Griffiths for use of his slides * * * * * * * * * * * * * * * * * * * * Comparison...
  • February 19, 2017 Colleen Talbot, Chair Ron Grender,

    February 19, 2017 Colleen Talbot, Chair Ron Grender,

    Symington Endowment Fund (autism and mobility/competitive gymnastics) Trevor Wingrove Bursary Fund (to lacrosse player) DY. These Family & Memorial funds include those established by families to honour a loved-one or create a special legacy - to provide grant monies for...
  • Chapter 26 Outline - Mr. Wolford&#x27;s World History

    Chapter 26 Outline - Mr. Wolford's World History

    vs. France, started off well, almost reached Paris but defeated at battle of the Marne and had to retreat. eventually reaches a stalemate. trench warfare - digging large ditches on each side of a battle. ... Chapter 26 Outline Last...
  • Development of eContent for Delivery of an Undergraduate

    Development of eContent for Delivery of an Undergraduate

    Ammar Al-Atiat, International Turnkey Systems, Egypt. Distance Learning eLearning Mobile Learning Web- Based Learning Computer- Based Learning CD-ROM Based Learning Many universities worldwide are re-examining their tools and methodologies for creating and delivering educational material.