What is AIS 140?
A Complete Guide

AIS 140 is an Automotive Industry Standard published by ARAI (the Automotive Research Association of India) under the direction of the Ministry of Road Transport and Highways (MoRTH). Its full title is "Intelligent Transportation Systems (ITS): Requirements for Public Transport Vehicle Operation." It defines the functional and technical requirements for a Vehicle Location Tracking Device (VLTD), one or more emergency request buttons, and the communication interfaces that connect a vehicle to a state Backend Control Centre. The standard became enforceable through MoRTH notifications under the Central Motor Vehicle Rules (CMVR), which is what gives it legal teeth at the Regional Transport Office (RTO) level.

It is important to understand what AIS 140 is and is not. It is not a single device specification. It is a system standard that ties together a tracking device, a set of input sensors, the GNSS receiver, the cellular link, the emergency buttons, and the data format used to report to a government backend. A device that simply has a GPS chip and a SIM card does not make a vehicle AIS 140 compliant. Compliance is a property of the whole chain: a certified device, correct installation, an active SIM, and a live data feed reaching the designated state control centre in the prescribed packet format.

The standard sits inside a larger telematics stack. If you are new to the broader landscape of vehicle tracking and want the wider context before diving into the regulation, the overview of telematics and GPS tracking systems explains how devices, networks, and backends fit together. AIS 140 is the Indian regulatory layer that sits on top of that general architecture, adding mandatory features that most commercial telematics products would not include by default.

A defining feature of AIS 140, and the reason the standard exists in its current form, is the mandatory emergency request button. The 2012 Nirbhaya case was the policy trigger for emergency telematics in Indian public transport, and the panic button requirement is the direct technical outcome. The standard requires at least one emergency button to be installed within reach of passengers in public service vehicles. Larger vehicles such as buses require multiple buttons distributed through the cabin so that any passenger can reach one.

When a panic button is pressed, the VLTD must generate a high-priority emergency packet. This packet jumps the normal reporting queue and is transmitted immediately, carrying the current position, vehicle identity, and an emergency flag. The packet flows to the state Backend Control Centre, which is integrated with the Emergency Response Support System (ERSS), reachable by the public on the single emergency number 112. The intent is that a distress signal from a vehicle reaches a police dispatcher with live location, not just a phone call with a verbal description of where the caller thinks they are.

For engineers, the emergency path imposes real design constraints. The button input must be debounced and protected against false triggers, but it cannot be so aggressive that a genuine press is missed. The emergency packet must preempt any in-progress transmission, which means the firmware queue needs priority handling. And the device must keep its internal backup battery charged so that an emergency report still goes out even if the vehicle power has been cut. These constraints are why a generic fleet tracker repurposed as an AIS 140 device often fails certification on the emergency path even when the basic tracking works. This requirement is central to applications like public transport and bus tracking, where passenger safety is the explicit policy goal.

AIS 140 data does not stay inside a private fleet platform. Each state operates a Backend Control Centre (BCC) that receives the data feed from every compliant vehicle registered in that state. The device must transmit its data packets to the IP address and port designated by the state authority, in the packet format the state has adopted, which is generally based on the AIS 140 data specification. The BCC is what integrates with ERSS 112 and with the state transport department's monitoring and enforcement systems.

This creates a dual-reporting reality for most operators. The device typically sends its data to both the operator's own fleet platform and to the state BCC. Some devices do this with a single firmware that supports multiple server destinations, and some operators run a backend that ingests data and forwards it to the BCC. The packet format, login packet structure, heartbeat interval, and emergency packet handling all need to match what the specific state has implemented, and the details vary between states even though they all derive from the same base standard.

For OEMs and integrators, this is one of the most underestimated parts of compliance. Getting a certified device is necessary but not sufficient. The device must actually connect to the correct state backend, authenticate, and stream valid packets, and the state will often run a conformance test against its own BCC before approving devices for registration in that state. A device certified at the ARAI lab can still be rejected by a state if its live feed does not pass the BCC integration test. This is why backend integration belongs in the device program from the start, not as an afterthought, across commercial vehicle tracking deployments.

A VLTD cannot be sold for AIS 140 use until it is certified by an authorized test agency. The two principal agencies are ARAI (Pune) and ICAT (the International Centre for Automotive Technology, Manesar). Both are notified under the CMVR to test and certify automotive components, and both run the AIS 140 device test program. The certification covers functional conformance to AIS 140, the emergency button behavior, the GNSS and NavIC performance, the data packet format, and the environmental and electrical robustness expected of an automotive component.

The test program includes the AIS 140 functional clauses plus the relevant environmental and EMC standards that apply to automotive electronics, such as temperature, vibration, ingress protection, and electromagnetic compatibility under the E-mark style requirements. A device that passes functional tests but emits excessive RF noise or fails a thermal cycle will not be certified. This is why pre-compliance testing before the formal lab submission saves significant time and cost, the same way it does for any regulated electronics product.

This full path is covered under ARAI and ICAT tracker certification support, from test plan preparation through resolving any non-conformances found during testing. The detailed engineering steps that precede submission, including the hardware and firmware checklist and EMC pre-compliance, are in the guide on building an AIS 140 compliant VLTD.