AIS 140 complied GPS Tracking Device
AIS 140 complied GPS Tracking Device
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
The panel has also deliberated and identified the necessary elements for an effective
implementation of vehicle level ITS system.
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
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
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.
22.214.171.124 Device shall be capable of obtaining position information using Global
Navigation Satellite System (GNSS). GNSS receiver specifications are as
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
c. Device shall have a position accuracy of minimum 2.5 m CEP or 6 m
d. Device shall have an acquisition sensitivity of minimum (-) 148 dBm
e. Device shall have an 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.
126.96.36.199 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
188.8.131.52 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.
184.108.40.206 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.
220.127.116.11 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 IP’s required for
18.104.22.168 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 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
22.214.171.124 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)
126.96.36.199 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.
188.8.131.52 Device shall support over the air software and configuration update.
184.108.40.206 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.
220.127.116.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.
18.104.22.168 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.
22.214.171.124 Device shall store/write the registration number of the vehicle in the
internal nonvolatile memory.
126.96.36.199 Device shall have an Embedded SIM.
188.8.131.52 Device shall be designed to operate between 8VDC and 32VDC using
vehicle battery input voltage range 12 /24Volts.
184.108.40.206 Device shall have a sleep mode current ≤ 20 mA (If the function is
implemented in a dedicated system/device).
220.127.116.11 Device shall support any operational GNSS system with 12 (minimum)
18.104.22.168 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)