Draft AIS-140/D1
July 2016
Page 1 of 109
DRAFT
AUTOMOTIVE INDUSTRY STANDARD
Intelligent Transportation Systems (ITS) -
Requirements for
Public Transport Vehicle Operation
ARAI
Date of hosting on website: 2nd
August 2016
Last date of comments: 26th
August 2016
Draft AIS-140/D1
July 2016
Page 2 of 109
CHECK LIST FOR PREPARING AUTOMOTIVE INDUSTRY STANDARD
AIS-140: Intelligent Transportation Systems (ITS) –
Requirements for Public Transport Vehicle Operation
SR. NO. PARTICULARS REMARKS
1. Indicate details of the base reference standard.
(e.g. ECE / EEC Directive/GTR etc.) NA
2.
Add an explanatory note indicating differences between
the above standard and the draft, if any.
3.
Specify details of technical specifications to be submitted
at the time of type approval relevant to the requirements of
this standard covered.
4. Are the details of Worst Case Criteria covered?
5. Are the performance requirements covered?
6. Is there a need to specify dimensional requirements?
7. If yes, are they covered?
8. Is there a need to specify COP requirements?
If yes, are they covered?
9.
Is there a need to specify type approval, and routine test
separately, as in the case of some of the Indian Standards?
If yes, are they covered?
10.
If the standard is for a part/component or sub-system;
i) AIS-037 or ISI marking scheme be implemented for this
part?
ii) Are there any requirements to be covered for this part
when fitted on the vehicle?
If yes, has a separate standard been prepared?
11.
If the standard is intended for replacing or revising an
already notified standard, are transitory provisions for re-
certification of already certified parts/vehicles by
comparing the previous test result, certain additional test,
etc. required?
If yes, are they included?
12.
Include details of any other international or foreign
national standards which could be considered as alternate
standard.
13. Are the details of accuracy and least counts of test
equipment/meters required to be specified?
Draft AIS-140/D1
July 2016
Page 3 of 109
If yes, have they been included?
14. What are the test equipment’s for establishing compliance?
15. If possible, identify such facilities available in India.
16.
Are there any points on which special comments or
information is to be invited from members?
If yes, are they identified?
17.
Does the scope of standard clearly identify vehicle
categories?
18. Has the clarity of definitions been examined?
Draft AIS-140/D1
July 2016
Page 4 of 109
Status chart of the Standard to be used by the purchaser for updating the record
Sr.
No.
Corrig
enda.
Amend-
ment
Revision Date Remark Misc.
General remarks:
Draft AIS-140/D1
July 2016
Page 5 of 109
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 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 ITS services across
the country.
The first steps taken for creation and implementation of ITS was 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 for Public Bus
Transportation. Nonetheless, the workshop helped to create the “National Intelligent Transport
System Architecture and Policy for Public Transport (Bus)”, which was submitted by ASRTU
and SIAM to the government (refer APPENDIX 1 for the architecture recommended in the
submitted document). Similar architecture recommendations have also been listed for cars and
auto rickshaws in APPENDICES 2 & 3.
A key need of the STUs identified during the workshop was establishment of a central body for
managing and implementing ITS and applications. A document ‘National ITS platform for
STU’s’ was prepared. It recommends to centrally deploy/host ITS Applications and Services on
a cloud based infrastructure for all STUs.
In the 44th
& 45th
CMVR-TSC, Chairman had directed - standardization activities to be initiated
on Intelligent Transportation Systems (ITS) - Vehicle Tracking, Camera surveillance system and
Emergency Request Button. The committee extended the above user requirements to all public
transportation namely – buses, taxis and auto rickshaws.
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. These are listed in APPENDIX 4.
Draft AIS-140/D1
July 2016
Page 6 of 109
This working draft has been prepared by considering inputs received from all stake holders on ITS,
mainly -
a. Direction in CMVR-TSC minutes
b. National ITS Architecture and Policy for Public Transport (Bus)
c. DIMTS specification reports on Vehicle Tracking Devices and CCTV systems (dated 4th
March 2015)
d. UBSII - Specifications for Intelligent Transport System (ITS) (dated April 2013)
e. UTIITSL document for Ticketing Systems: National Common Mobility Card - Minimum
standards & specification document for card and devices (dated April 2012)
f. IS 16490:2016 - LED Destination board system for buses - specification
This AIS on ITS, has been provisioned with both system level approval and vehicle level approval.
System level approval is needed to enable retro-fitment of ITS systems on in-use vehicles. This will
ensure ITS backend infrastructure already present with the STUs can be more fully utilized and make the
investment in the backend infrastructure more viable.
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 fastest 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 strongly recommend
the AIS route for regulation creation and first implementation.
The DIMTS document envisages that the hardware should be compliant with both GPS and IRNSS
satellite systems. The final satellite of the IRNSS (renamed NavIC) system has been launched on 28th
April 2016 and NavIC system is expected to be operational soon. A decision needs to be taken whether
the systems specified in this standard need to be aligned with both GPS and NavIC systems. GPS and
NavIC systems require entirely different hardware and software, both for the end user and for the
operator. If in future India is likely to abandon GPS, it may be worthwhile to specify only NavIC
compatibility in this standard. A decision will be sought before the next version of this draft.
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. In this AIS panel also, a view has been expressed that the ITS systems
proposed in this panel are not mindful enough of privacy matters. This issue needs to be suitably
addressed by the authorities.
The AISC panel and the Automotive Industry Standards Committee (AISC) responsible for
preparation of this standard are given in Annexure---- ( to be included) and Annexure ---- (to
be included) respectively.
Draft AIS-140/D1
July 2016
Page 7 of 109
Intelligent Transportation Systems (ITS) –
Requirements for Public Transport Vehicle Operation
Para No. Contents Page
No.
1.0 SCOPE 9
2.0 REFERENCES 9
PART I: INTELLIGENT TRANSPORTATION SYSTEMS (ITS) - REQUIREMENTS FOR
PUBLIC TRANSPORT VEHICLE OPERATION (PASSENGER VEHICLES SEATING
CAPACITY ≥ 23+D)
1.0 DEFINITIONS 11
2.0 APPLICATION FOR CMVR TYPE APPROVAL 11
3.0 ITS FUNCTIONS AND IN-VEHICLE REQUIREMENTS 12
3.1 AUTOMATIC VEHICLE LOCATION TRACKING AND VEHCILE
HEALTH MONITORING
13
3.2 IN-VEHICLE VIDEO SURVEILLANCE AND RECORDING 15
3.3 EMERGENCY REQUEST 17
3.4 IN-VEHICLE PASSENGER INFORMATION 18
3.5 IN-VEHICLE AUTOMATED TICKETING (SMART CARD BASED) 19
Part II: INTELLIGENT TRANSPORTATION SYSTEMS (ITS) – REQUIREMENTS FOR
PUBLIC TRANSPORT VEHICLE OPERATION (PASSENGER VEHICLES SEATING
CAPACITY< 23+D)
1.0 DEFINITIONS 21
2.0 APPLICATION FOR CMVR TYPE APPROVAL 21
3.0 ITS FUNCTIONS AND IN-VEHICLE REQUIREMENTS 22
3.1 AUTOMATIC VEHICLE LOCATION TRACKING 22
3.2 EMERGENCY REQUEST 24
Part III: INTELLIGENT TRANSPORTATION SYSTEMS (ITS) – REQUIREMENTS FOR
PUBLIC TRANSPORT VEHICLE OPERATION (AUTO RICKSHAW)
1.0 DEFINITIONS 25
2.0 APPLICATION FOR CMVR TYPE APPROVAL 25
3.0 ITS FUNCTIONS AND IN-VEHICLE REQUIREMENTS 26
3.1 AUTOMATIC VEHICLE LOCATION TRACKING 26
3.2 EMERGENCY REQUEST 28
LIST OF ANNEXURES
ANNEXURE-A INFORMATION TO BE SUBMITTED FOR TYPE APPROVAL 29
ANNEXURE-B CRITERIA FOR EXTENSION OF TYPE APPROVAL 32
ANNEXURE-C DATA COMMUNICATION PROTOCOL 33
Draft AIS-140/D1
July 2016
Page 8 of 109
ANNEXURE-D ALERTS MASTER (IN-VEHICLE) 46
ANNEXURE-E EMERGENCY MESSAGE FORMAT 48
ANNEXURE-F FUNCTIONAL, PERFORMANCE, DURABILITY AND
ENVIRONMENTAL TESTS
49
ANNEXURE-G HEALTH PARAMETERS- MASTER LIST 59
ANNEXURE-H PHYSICAL INTERFACES (CONNECTORS) FOR POWER AND
I/Os
61
ANNEXURE-I DEVICE/EQUIPMENT PACKAGE OPTIONS 65
ANNEXURE-J DEFENITIONS 67
ANNEXURE-K COMPOSITION OF PANEL 68
LIST OF APPENDICES
APPENDIX 1 INTELLIGENT TRANSPORTATION SYSTEMS (ITS) – USER NEEDS,
USER SERVICES/FUNCTIONS AND ARCHITCTURE FOR PUBLIC
TRANSPORT (BUS)
69
APPENDIX 2 INTELLIGENT TRANSPORTATION SYSTEMS (ITS) – USER NEEDS,
USER SERVICES/FUNCTIONS AND ARCHITCTURE FOR PUBLIC
TRANSPORT(PASSENGER CAR) To be added
APPENDIX 3 INTELLIGENT TRANSPORTATION SYSTEMS (ITS) – USER NEEDS,
USER SERVICES/FUNCTIONS AND ARCHITCTURE FOR PUBLIC
TRANSPORT(THREE WHEELER) To be added
Draft AIS-140/D1
July 2016
Page 9 of 109
Intelligent Transportation Systems (ITS) –
Requirements For Public Transport Vehicle Operation 1.0 SCOPE
1.2 This standard applies to:
1.2.1 Part I: INTELLIGENT TRANSPORTATION SYSTEMS (ITS) –
REQUIREMENTS FOR PUBLIC TRANSPORT VEHICLE OPERATION
(PASSENGER VEHICLES SEATING CAPACITY ≥ 23+D):
1.2.1.1 This part applies to passenger vehicle with seating capacity greater than equal to
23+Driver
1.2.1.2 Requirements on ITS functions - Automatic Vehicle Location Tracking and
Vehicle Health Monitoring, Emergency Request, In vehicle video surveillance and
recording, In-vehicle Passenger Information, In-vehicle automated ticketing (smart card
based).
1.2.2 Part II: INTELLIGENT TRANSPORTATION SYSTEMS (ITS) –
REQUIREMENTS FOR PUBLIC TRANSPORT VEHICLE OPERATION
(PASSENGER VEHICLES SEATING CAPACITY< 23+D):
1.2.2.1 This part applies to passenger vehicle with seating capacity less than 23+Driver
1.2.2.2 Requirements on ITS functions - Automatic Vehicle Location Tracking, and
Emergency Request
1.2.3 Part III: INTELLIGENT TRANSPORTATION SYSTEMS (ITS) –
REQUIREMENTS FOR PUBLIC TRANSPORT VEHICLE OPERATION (AUTO
RICKSHAW):
Requirements on ITS functions - Automatic Vehicle Location Tracking and Emergency
Request
1.2.4 Public Transport vehicles within the scope of 1.2.1, 1.2.2 and 1.2.3 above, shall be fitted
for type approval with all equipment specified as mandatory in Parts I, II and III
respectively. However, for specific government procurements, government may
authorize the vehicle manufacturer to supply the vehicles without one or more of the
equipment specified as mandatory.
2.0 REFERENCES
2.1 National Level Vehicle Security and Tracking System – Detailed Specification
Document on Vehicle tracking Devices (GPS) (prepared by DIMTS)
2.2 National Level Vehicle Security and Tracking System – Detailed Specification
Document for CCTVs (prepared by DIMTS)
Draft AIS-140/D1
July 2016
Page 10 of 109
2.3 IS 16490:2016 - “LED Destination board system for buses - specification”
2.4 NATIONAL COMMON MOBILITY CARD, MINIMUM STANDARDS &
SPECIFICATION DOCUMENT FOR CARD AND DEVICES – MOUD
2.5 APTA TCIP - American Public Transportation Association (APTA) Standard for Transit
Communications Interface Profiles (TCIP)
2.6 EBSF - European Bus System of the Future
2.7 ISO 11898-1:2003 Road vehicles — Controller area network (CAN)
2.8 SAE J 1939 Recommended Practice for a Serial Control and Communications Vehicle
Network
2.9 Bus-FMS-Standard
2.10 SAE USCAR 18 / USCAR18-3 - FAKRA SMB RF CONNECTOR SUPPLEMENT
2.11 National ITS Architecture - U.S. Department of Transportation
2.12 ISO 17185-1:2014 - Intelligent transport systems — Public transport user information —
Part 1: Standards framework for public information systems
2.13 Transmodel Standard (CEN/TC 278 WG3/SG4, Reference Entity-Relationship Data
Model for Public Transport) - European reference data model for Public Transport
operations developed within several European Projects - EN 12896:2006
2.14 Specification for Entity-Relationship for describing the main fixed objects in Public
transport CEN/TC 278, 2008 - EN 28701:2012
2.15 RTIG (Real Time Information Group Ltd) - Digital Air Interface Protocol
2.16 SIRI (Service Interface for Real Time Information) European Technical Specification
(TS) - CEN/TS 15531
2.17 NeTEx-Network Exchange European Technical Specification (TS) CEN/TS 16614
2.18 NaPTAN (National Public Transport Access Node)
2.19 ISO 15638-15:2014 Intelligent transport systems – Framework for cooperative telematics
applications for regulated vehicles (TARV) – Part 15: Vehicle location monitoring
2.20 ISO 15638-5:2013 Intelligent transport systems – Framework for collaborative
Telematics Applications for Regulated commercial freight Vehicles (TARV) – Part 5:
Generic vehicle information
Draft AIS-140/D1
July 2016
Page 11 of 109
PART I: INTELLIGENT TRANSPORTATION SYSTEMS (ITS) –
REQUIREMENTS FOR PUBLIC TRANSPORT VEHICLE
OPERATION (PASSENGER VEHICLES SEATING CAPACITY
≥ 23+D)
1.0 DEFINITIONS
For the purpose of Part I of this standard, definitions given in Annexure J shall apply.
2.0 APPLICATION FOR CMVR TYPE APPROVAL
2.1 The application for CMVR type approval shall be accompanied by information on the
system specification as mentioned in Annexure A.
2.2 Manufacture / system integrator shall take approval of complete system mentioned in this
part of standard. ITS functions covered in this part of standard can be implemented in one or
more devices. Individual devices or integrated system shall be tested approved for all
requirements at their level.
2.3
2.3.1
2.3.1.1
2.3.1.2
2.3.2
2.3.3
MODIFICATIONS AND EXTENSION OF APPROVAL
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 manufacturer to
the test agency.
If the changes are in parameters not related to the provisions, no further action need be
taken.
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 vehicle 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.
In case of 2.3.1.1, tests for only those parameters which are affected by the
modifications need be carried out based on Criteria for extension of approval as per
Annexure B.
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.
Draft AIS-140/D1
July 2016
Page 12 of 109
3.0 ITS FUNCTIONS AND IN-VEHICLEREQUIREMENTS
The list of ITS functions that addresses the user needs of public transport operation (bus) can
be referred in APPENDIX 1, Clause 3.3 ITS user functions and sub functions of Section 3:
ITS Architecture.
TABLE – 1: ITS functions and sub functions
Function Sub Functions
Operations
Management
Automatic Vehicle Location Tracking and Vehicle Health Monitoring
Performance management (Vehicle, Driver)
Route/Schedule management
Maintenance/Service management
Crew (Driver/Conductor) management
Reservations management
Passenger
Information
In-vehicle (Location based announcements)
Outside vehicle (at bus stops/depots)
On demand Information (via Personal Computing Devices)
Fare Collection
Management
In vehicle manual electronic ticketing
In vehicle automated ticketing (Smart card based)
Safety and
Security
Emergency Request
In vehicle video surveillance and recording
Reversing assistance
The following functions/sub functions will require individual systems or devices at vehicle
level and the requirements on the same is given from clause 3.1 to 3.5
Automatic Vehicle Location Tracking and Vehicle Health Monitoring
In vehicle video surveillance and recording
Emergency Request
In-vehicle Passenger Information
In-vehicle automated ticketing (smart card based)
Each of the individual ITS Functions can be implemented in separate individual systems /
devices / equipment package or alternately more than one ITS function can be implemented
in a single system / device / equipment package. Device/Equipment package
recommendation is given in ANNEXURE I.
The physical interfaces (connectors) and software interfaces (data communication protocols
and data configuration) of individual system / device / equipment package are standardized
so that the end users (Manufacturer / System integrator) can obtain vendor independent
systems and perform plug and play.
Draft AIS-140/D1
July 2016
Page 13 of 109
The physical interface standardization is provided in ANNEXURE H.
The software interface / data communication protocol standards are provided in
ANNEXURE C.
3.1 AUTOMATIC VEHICLE LOCATIONTRACKING (AVL) AND VEHICLE HEALTH
MONITORING
3.1.1 Functional Requirements
3.1.1.1 System shall be capable of obtaining position information using Global Navigation Satellite
System (GNSS). GNSS receiver specifications are as follows
a. System shall be capable for operating in L and/or S band and include support
for NAVIC/ IRNSS (Indian Regional Navigation Satellite System) with GAGAN
b. System shall have a position accuracy of minimum 2.5 m CEP or 6 m 2DRMS
c. System shall have an acquisition sensitivity of minimum (-) 148 dBm
d. System shall have an tracking sensitivity of minimum (-) 165 dBm
e. It is desirable to have an internal antenna; however if the fitment location
prevents the internal antenna from functioning, then external antenna shall be
provided.
3.1.1.2
System shall support standard I/Os (Digital, Analogue and Serial Communication) for
interfacing external systems (E.g Digital input for Emergency request button interfacing) to
meet the functional requirements.
3.1.1.3 System shall support built-in vehicle communication interface - Standard CAN interface as
per ISO 11898
3.1.1.4 System shall be capable of transmitting data to backend control center via Wide Area
(Mobile) Communications network (GSM/GPRS).
3.1.1.5
System shall be capable of collecting and transmitting Position, Velocity and Time (PVT
data) along with heading (direction of travel) in a fixed frequency to a backend control
center (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).
3.1.1.6 System shall capable of transmitting alerts (mandatory and user defined) to the backend
control center. The mandatory list of alerts is given in Annexure – D.
3.1.1.7 System shall capable of transmitting data (periodic and alerts) to 3 (Three) different IP
addresses (Two IP will be for regulatory purposes and one IP will be for operator services).
3.1.1.8
System 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 un-availability and transmit the data when the connection
resumes in first in first out (FIFO) manner. The live data shall be given higher priority for
transmission than back log at any point in time.
3.1.1.9
System shall have internal memory to store minimum 20000 positional logs (PVT Data) and
10000 alert records (The data shall not be overwritten, if the protected memory exceeds the
limits).
Draft AIS-140/D1
July 2016
Page 14 of 109
3.1.1.10 System shall meet the vehicle to center data communication protocol requirements as
defined in Annexure – C (Clause 2.1 and 2.2).
3.1.1.11
System shall support basic standard configuration (Mobile communications network
settings, control center server details, data frequencies, alert thresholds etc...) as per
configuration specification defined in Annexure - C.
3.1.1.12 System shall support over the air software and configuration update.
3.1.1.13 System shall support Embedded SIM.
3.1.1.14
The system shall have a unique identifier for identifying the unit and data from the unit. The
unique ID shall be stored in a read only memory area so that it cannot be altered or
overwritten by any person. IMEA (International Mobile Station Equipment Identity) Number
shall be the unique identifier.
3.1.1.15 System shall store/write the registration number of the vehicle in the internal nonvolatile
memory.
3.1.1.16 System shall be designed to operate in a wide range of DC power supply ranging from
9VDC to 32VDC (shall support 12VDC and 24VDC vehicle battery).
3.1.1.17 System shall have a sleep mode current < 5 mA (If the function is implemented in a
dedicated system/device).
3.1.1.18
System shall have an internal back-up battery to support 4 hours of normal operations.
However in the case of external power supply failure/disconnect, the device shall perform
limited functions to extend the internal battery support for more than 24 Hrs (Position
records shall be collected and send once in an hour)
3.1.1.19 Vehicle Health Monitoring - Functional Requirements
3.1.1.20
System shall be capable of reading vehicle health data available via CAN interface as per
SAE J1939 or OBDII. The mandatory list of vehicle health parameters are given in
Annexure - G.
3.1.1.21 System shall be capable of reading vehicle diagnostics codes available via vehicle CAN
interface as per SAE J1939 or via OBDII.
3.1.1.22
System shall be capable of transmitting vehicle health parameters in a fixed frequency to a
backend control center (Frequency shall be user configurable, minimum frequency shall be 5
sec).
3.1.1.23
System shall be capable of collecting and transmitting vehicle diagnostics codes to back end
control center as alerts on occurrence and on clearance. The alerts reserved for vehicle
diagnostics is given in Annexure - D.
3.1.1.24 The internal memory shall store minimum 20000 vehicle health logs and 10000 diagnostics
records (The data shall not be overwritten, if the protected memory exceeds the limits).
3.1.2 Construction and Installation
3.1.2.1 Requirements on vehicle interface
Connector for Power and I/Os and External Antennas:
The Connectors for Power and I/Os shall be as given in Annexure – H
In case of external antennas, connector recommendations are as per Annexure –H
3.1.2.2 Physical Mounting
Draft AIS-140/D1
July 2016
Page 15 of 109
The system shall be mounted in such a way that it is not directly accessible/exposed to
passengers. Any HMI (Human Machine Interface) shall be mounted in such a way that it
shall be easily accessible by the driver from the driver seat.
3.1.3 Functional, Performance, Durability and Environmental Tests
Components and Systems shall meet the requirements of clauses 2.0, 3.0 and 4.0 of
Annexure – F.
At Vehicle level requirements of clause 1.0 of Annexure - F shall be met
3.2 IN-VEHICLE VIDEO SURVEILLANCE AND RECORDING
3.2.1 Functional requirements
3.2.1.1 The system shall have provision for in-vehicle video surveillance, recording and data
retrieval.
3.2.1.2 The system shall support minimum 2 cameras and maximum up to 4
3.2.1.3 System shall support stream standards: ISO 1449, video compression standard H.264.
3.2.1.4 System shall have built in clock and the date/time shall overlaid on video
3.2.1.5
Video recording shall be possible with following options
a. CIF (352X288 ) up to 25 fps maximum each of 4 channel
b. DI (704X576) up to 12 fps maximum each of 4 channels
c. D1 (704X576) up to 25 fps maximum -one channels only
3.2.1.6 System shall have provision to record video at preselected resolution and FPS.
3.2.1.7
System shall record video files not in single file continuously; files shall be of configurable
fixed size. Once the configured size is reached, a new file shall be created automatically
and recording shall continue.
3.2.1.8 System shall store minimum 48 hours of video in its internal memory at any point in time.
The video files shall be overwritten if the memory is fully utilized.
3.2.1.9
System shall store and transfer video files well organized; The user must be able to
differentiate video files with respect to the cameras in the vehicle (E.g. front cam, rear cam
etc…).
3.2.1.10 System shall have provision to accept external inputs/trigger (E.g. Emergency request
trigger).
3.2.1.11 System shall have provision to record video at higher resolution and FPS based on
event/trigger (E.g. Emergency request trigger).
3.2.1.12 System shall have provision to detect camera disconnection.
3.2.1.13 System shall be capable of capturing self-diagnostics health parameters. The health
parameter list is given in Annexure – G.
3.2.1.14
System shall have provision to send snap shots to control center based on request or
event/alert (E.g. Emergency request trigger). The function is applicable only if the AVL
function mentioned in clause 3.1 is built into the system
3.2.1.15 System shall be capable of transmitting self-health parameters to a back end control center
(Applicable only if the AVL function mentioned in clause 3.1 is built into the system)
3.2.1.16 System shall operate on 12VDC and/or 24VDC vehicle battery.
3.2.1.17 System shall have a sleep mode current < 5 mA (If the function is implemented in a
Draft AIS-140/D1
July 2016
Page 16 of 109
dedicated system/device)
3.2.1.18
System shall have provision to transfer the recorded video files via SD card or USB and Wi-
Fi. The card location must not be easily accessible. Access must be enabled only through a
key or a special tool.
3.2.1.19 Software Interface: The Wi-Fi transfer of video files to control center shall be as per FTP
protocol.
3.2.1.20 Software Interface: System shall exchange data with other in-vehicle controller/s as per
protocol given in Annexure - C.
3.2.1.21 Software Interface: The basic configuration (No of cameras, resolution etc…) of system
shall meet the configuration format requirements as defined in Annexure - C.
3.2.1.22 System shall have provision to authenticate Video file downloads.
3.2.1.23
Optional – Reversing camera and Driver Display - An optional reversing camera and driver
display (LCD/TFT) can be provided for reversing assistance. The driver display functional
requirements are not in the scope of this standard.
3.2.2 Construction and Installation
3.2.2.1 Requirements on vehicle interface - Recorder
Recommended Connector for Power, I/Os and External Antennas
The Connectors for Power and I/Os shall be as given in Annexure – H
In case of external antennas, connector recommendations are as per Annexure –H
3.2.2.2 Physical Mounting - Recorder
The system shall be mounted in such a way that it is not directly accessible/exposed to
passengers or in-vehicle crew (driver or conductor)
3.2.2.3 Requirements on vehicle interface – Camera
Recommended Connector for Power, I/Os and External Antennas
Power and Signals to the camera shall be provided by the recorder.
3.2.2.4 Physical Mounting - Camera
The cameras shall be so installed such that the interior doors, driver zone, ticketing zone etc
are covered.
Minimum number of cameras to be fitted in the bus shall be decided as per the below criteria
Bus category Number of CCTV cameras
Non-articulated Bus Minimum 2 internal cameras +
1 optional reverse camera
Articulated Bus Minimum 3 internal cameras +
1 optional reverse camera
3.2.3 Functional, Performance, Durability and Environmental Tests
Components and Systems shall meet the requirements of clauses 2.0, 3.0 and 4.0 of
Draft AIS-140/D1
July 2016
Page 17 of 109
Annexure – F.
At Vehicle level requirements of clause 1.0 of Annexure - F shall be met
3.3 EMERGENCY REQUEST
3.3.1 Functional requirements
3.3.1.1 Passengers or in-vehicle crew present in the vehicle shall be able to make an Emergency
Request by pressing the emergency button provided.
3.3.1.2 The Emergency Request function shall not exist as standalone. Emergency Request button
shall be interfaced to
1. Automatic Vehicle Location Tracking (AVL) and Vehicle Health monitoring
function
a. An alert shall be send to the control center when emergency request is
activated and de-activated.
AND
2. In-vehicle video surveillance and recording function (If present in the vehicle)
a. The functional requirements are captured in clause 3.2.1.10, 3.2.1.11 and
3.2.1.14
3.3.1.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.
3.3.1.4 On pressing of Emergency button, the system implementing AVL function shall send
emergency Alert (Alert ID 8 as mentioned in ANNEXURE D) to the configured IP
addresses (all three) as per the communication protocol mentioned in ANNEXURE C. In the
absence of GPRS network, the alert shall be send as SMS message along with vehicle
location data to configured control center number. The SMS shall consist parameters as
given in Annexure E.
3.3.2 Construction and Installation
3.3.2.1 Emergency button shall be one time press type. Separate release action shall be required to
bring back to normal mode.
3.3.2.2 Physical Mounting
3.3.2.2.1 One Emergency Button shall be installed within easy reach of the driver.
3.3.2.2.2 Other Emergency Buttons shall be installed on both sides of the bus in such a way that the
distance between two buttons is not more than 3 meters.
3.3.2.2.3 The positioning of Emergency Buttons in different types of buses shall be decided based on
the length, seating and interior layout of the buses.
Draft AIS-140/D1
July 2016
Page 18 of 109
3.3.3 Functional, Performance, Durability and Environmental Tests
Emergency Button shall be tested along with Automatic Vehicle Location Tracking (AVL)
system or In-vehicle video surveillance/recording system as per clause 3.1.3 or 3.2.3 of Part
I and Annexure – F of this standard.
3.4 IN-VEHICLE PASSENGER INFORMATION (CONTROLLER AND LED
DESTINATION BOARDS)
3.4.1 Functional requirements
3.4.1.1 The LED destination boards shall meet the functional requirements as per “LED Destination
board system for buses - specification” - IS 16490:2016
3.4.1.2 The LED Destination board display content configuration shall be as per requirements given
in Annexure - C.
3.4.1.3
The system shall provide HMI (Human Machine Interface) for route selection and route
configuration upload. The HMI shall be a LCD/TFT display with built-in keypad or a touch
screen display. The detailed functional requirements of the HMI are not in the scope of this
standard.
3.4.1.4 The system shall comprise a public addressing system with MIC, Amplifier and Speaker.
3.4.1.5 The controller system shall communicate data with destination boards as per serial
communication protocol mentioned in Annexure - C.
3.4.1.6
The PIS configuration (Route configuration with bus stops and Point Of Interest (POI) with
geo-location, linked audio file and display content for location based announcements) shall
be as per standard given in Annexure - C.
Typical POIs are Bus station, railway station, airport, transit mode change points and others.
3.4.1.7 The controller system shall have internal memory to hold PIS configuration for minimum 75
routes UP and DOWN (150 numbers of destinations).
3.4.1.8 The controller system shall have minimum serial OIs for communicating with LED boards
and external systems.
3.4.1.9
Optionally the system shall obtain real time geo-position information from AVL
system/device present in the vehicle as per serial communication protocol mentioned in
Annexure - C.
3.4.1.10 The system shall provide geo-position triggered next stop display on Inner sign with
synchronized voice announcement for minimum 75 stops on each route.
3.4.1.11
The next stop information shall be provided
1. "Before arrival" of the bus at the bus stop, "on arrival" of the bus at bus stop and
"after departure" of the bus from the bus stop.
2. In audio visual form (Audio via speakers and text information via inner LED display
board).
3. In three different languages (English, Hindi and Local language) one after the other
in sequence
3.4.1.12 The system shall have a provision to load the configuration over the air (Applicable only if
the AVL function mentioned in clause 3.1 is built into the system)
3.4.1.13
The system shall have provision to update/report the route selected in the vehicle to control
center. (Applicable only if the AVL function mentioned in clause 3.1 is built into the
system).
Draft AIS-140/D1
July 2016
Page 19 of 109
3.4.1.14
The system shall have provision to select/change route in the vehicle remotely over the air
from control center. (Applicable only if the AVL function mentioned in clause 3.1 is built
into the system).
3.4.1.15
System shall have provision to display dynamic messages from control center. These
messages can be advertisements or travel specific information.(Applicable only if the AVL
function mentioned in clause 3.1 is built into the system).
3.4.1.16
System shall meet the center to vehicle data communication protocol requirements as
defined in Annexure - C. (Applicable only if the AVL function mentioned in clause 3.1 is
built into the system).
3.4.2 Construction and Installation
3.4.2.1 Requirements on vehicle interface (PIS Controller and Boards)
Recommended Connector/s for Power, I/Os and External Antennas
The Connectors shall be as given in Annexure - H
In case of external antennas, connector recommendations are as per Annexure –H
3.4.2.3 Physical Mounting
3.4.2.3.1 Display Boards
The system shall meet the requirements as per “LED Destination board system for buses -
specification” - IS 16490:2016
3.4.2.3.2 PIS Controller
Any HMI shall be mounted in such a way that it shall be easily accessible by the driver from
the driver seat.
If the controller is separate from the HMI, then the controller shall be mounted in such a way
that it is not directly accessible/exposed to passengers.
3.4.3 Functional, Performance, Durability and Environmental Tests
In-Vehicle Passenger Information System shall meet the testing requirements given in
Annexure – F.
3.5 IN-VEHICLE AUTOMATED TICKETING (SMART CARD BASED)
3.5.1 Functional requirements
3.5.1.1 The system shall meet the functional requirements as per NATIONAL COMMON
MOBILITY CARD, MINIMUM STANDARDS & SPECIFICATION DOCUMENT FOR
CARD AND DEVICES - MOUD)
3.5.1.2 The basic configuration of system shall meet the configuration format requirements as
defined in Annexure - C.
3.5.1.3 The system shall exchange data with other in-vehicle systems as per protocol defined in
Draft AIS-140/D1
July 2016
Page 20 of 109
Annexure - C.
3.5.1.4 The system shall exchange data with control center as per protocol defined in Annexure - C.
(Software interface standardization is not covered in NATIONAL COMMON
MOBILITY CARD, MINIMUM STANDARDS & SPECIFICATION DOCUMENT FOR
CARD AND DEVICES - MOUD)
3.5.2 Construction and Installation
3.5.2.1 Requirements on vehicle interface (Ticketing Machine)
Recommended Connector/s for Power, I/Os and external antennas
The Connectors shall be as given in Annexure - H
In case of external antennas, connector recommendations are as per Annexure –H
These requirements are not applicable if ticketing machine is portable / handheld.
3.5.2.2 Physical Mounting
The system shall meet the requirements as National Common Mobility Card, Minimum
Standards & Specification Document For Card And Devices – Moud
3.5.3 Functional, Performance, Durability and Environmental Tests
The system shall meet the requirements of NATIONAL COMMON MOBILITY CARD,
MINIMUM STANDARDS & SPECIFICATION DOCUMENT FOR CARD AND
DEVICES – MOUD
Draft AIS-140/D1
July 2016
Page 21 of 109
PART II: INTELLIGENT TRANSPORTATION SYSTEMS (ITS) –
REQUIREMENTS FOR PUBLIC TRANSPORT OPERATION
(PASSENGER VEHICLES SEATING CAPACITY < 23+D)
1.0 DEFINITIONS
For the purpose of Part II of this standard, definitions given in Annexure J shall apply.
2.0 APPLICATION FOR CMVR TYPE APPROVAL
2.1 The application for CMVR type approval shall be accompanied by information on the
system specification as mentioned in Annexure A.
2.2
2.3
AVL Manufacturer / System integrator/ Vehicle Manufacturer has the option of going for
individual system or device level approval. The individual systems or devices can
implement one or more AVL functions.
Type Approval can be requested with following methods :
1. Device Approval : Approval provided at Device level for compliance to this
standard and device can be fitted / retro-fitted in any model without any further
approval
2. Integrated system Approval: Approvals provided for systems meeting requirements
of this standard which are specific to vehicle models. Tests can be extended for
different models however type approval will be required separately.
2.4
2.4.1
2.4.1.1
2.4.1.2
2.4.2
MODIFICATIONS AND EXTENSION OF APPROVAL
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 manufacturer
to the test agency.
If the changes are in parameters not related to the provisions, no further action need be
taken.
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 vehicle 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.
In case of 2.4.1.1, tests for only those parameters which are affected by the
modifications need be carried out based on Criteria for extension of approval as per
Annexure B.
Draft AIS-140/D1
July 2016
Page 22 of 109
2.4.3
In case of fulfilment of criterion of clause 2.4.1.1 or after results of further
verification as per clause 2.4.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 addressing needs of passenger vehicles seating capacity < 23+D
are as below -
List of ITS functions and sub functions
Function Sub Functions
Safety and
Security
Emergency Request
Automatic Vehicle Location Tracking
The above functions and their requirements shall be met either using separate device(s) or
system integrated with vehicle. The communications to backend (Government) server shall
be done by device or integrated system including service provider’s server.
3.1 AUTOMATIC VEHICLE LOCATION TRACKING (AVL)
3.1.1 Functional requirements
3.1.1.1 System shall be capable of obtaining position information using Global Navigation Satellite
System (GNSS). GNSS receiver specifications are as follows
a. System shall be capable for operating in L and/or S band and include support for
NAVIC/ IRNSS (Indian Regional Navigation Satellite System) with GAGAN
b. System shall have a position accuracy of minimum 150 meters
c. System shall have an acquisition sensitivity of minimum (-) 148 dBm
d. System shall have an tracking sensitivity of minimum (-) 165 dBm
e. It is desirable to have an internal antenna; however if the fitment location prevents
the internal antenna from functioning, then external antenna shall be provided.
3.1.1.2 System shall support standard I/Os (Digital, Analogue and Serial Communication) for
interfacing external systems (E.g Digital input for Emergency request button interfacing).
3.1.1.3 System shall be capable of transmitting data to backend control center via Wide Area
(Mobile) Communications network (GSM/GPRS).
3.1.1.4
System shall be capable of transmitting Position, Velocity and Time (PVT data) along with
heading (direction of travel) on demand to a backend control center at required frequency
(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).
3.1.1.5
System shall support standard I/Os (Digital, Analogue and Serial Communication) for
interfacing external systems (E.g Digital input for Emergency request button interfacing) to
meet the functional requirements.
3.1.1.6 System shall capable of transmitting data to minimum 2 different IP addresses ( 1 IP address
for Regulatory purpose (PVT data) and 1 IP address for Operational purpose)
Draft AIS-140/D1
July 2016
Page 23 of 109
3.1.1.7
System shall have an internal back-up battery to support 4 hours of normal operations.
However in the case of external power supply failure/disconnect, the device shall perform
limited functions to extend the internal battery support for minimum 12 Hrs (Position
records shall be collected and send once in an hour)
3.1.1.8
System shall capable of transmitting alerts to the backend control center (Government
server) directly or through server of service provider. The applicable list of alerts is given in
Annexure – D (Alert ID 3 to 12).
3.1.1.9 System shall support over the air software and configuration update.
3.1.1.11
System 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 un-availability and transmit the data when the connection
resumes in first in first out (FIFO) manner. The live data shall be given higher priority for
transmission than back log at any point in time.
3.1.1.12
The system shall have a unique identifier for identifying the unit and data from the unit. 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
3.1.1.13 System shall store/write the registration number of the vehicle in the internal nonvolatile
memory.
3.1.1.14 System shall support Embedded SIM.
3.1.1.15 System shall be designed to operate in DC power supply ranging from 9VDC to 14VDC
(shall support 12VDC vehicle battery).
3.1.1.16 System shall meet the vehicle to center data communication protocol requirements as
defined in Clause 2.1 and Clause 2.2 of Annexure C
3.1.1.17 System shall have a sleep mode current < 5 mA (If the function is implemented in a
dedicated system/device).
3.1.2 Construction and Installation
3.1.2.1 Requirements on vehicle interface
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 – H, Clause 1.1 (S.No 1 - Low power systems 1)
These requirements do not apply to Integrated systems with vehicle.
3.1.2.2 Physical Mounting
The system shall be mounted in such a way that it is not easily accessible/exposed to
passengers. This requirement shall not be applicable in case of combined systems AVL with
HMI display in front of driver.
Draft AIS-140/D1
July 2016
Page 24 of 109
3.1.3 Performance and Durability requirements
In case of non-integrated system approval, performance and durability test requirements
shall be as per clause 3.0 of Annexure – F.
3.2 EMERGENCY REQUEST
3.2.1 Functional requirements
3.2.1.1 Passengers or in-vehicle crew present in the vehicle shall be able to make an emergency
request by pressing the emergency button provided.
3.2.1.2
The emergency request function shall not exist as standalone. The function shall be part of
Automatic Vehicle Location Tracking (AVL) system. An alert shall be send to the control
center when emergency request is raised.
3.2.1.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.
3.2.1.4
On pressing of Emergency button, the system implementing AVL function shall send
emergency Alert (Alert ID 8 as mentioned in ANNEXURE D) to the configured IP
addresses as per the communication protocol mentioned in ANNEXURE C. In the absence
of GPRS network, the alert shall be send as SMS message along with vehicle location data
to configured control center number. The SMS shall consist parameters as given in
Annexure E.
3.2.2 Construction and Installation
Emergency button shall be one time press type. Separate release action shall be required to
bring back to normal mode.
3.2.2.1 Physical Mounting
Emergency button(s) shall be such a way that every passenger including driver shall be able
to access.
Draft AIS-140/D1
July 2016
Page 25 of 109
PART III: INTELLIGENT TRANSPORTATION SYSTEMS (ITS)
– REQUIREMENTS FOR PUBLIC TRANSPORT OPERATION
(AUTO RICKSHAW)
1.0 DEFINITIONS
For the purpose of Part I of this standard, definitions given in Annexure J shall apply.
2.0 APPLICATION FOR CMVR TYPE APPROVAL
2.1 The application for CMVR type approval shall be accompanied by information on the system
specification as mentioned in Annexure A.
2.2
2.3
AVL Manufacturer / System integrator/ Vehicle Manufacturer has the option of going for
individual system or device level approval. The individual systems or devices can implement
one or more AVL functions.
Type Approval can be requested with following methods :
1. Device Approval : Approval provided at Device level for compliance to this standard
and device can be fitted / retro-fitted in any model without any further approval
2. Integrated system Approval: Approvals provided for systems meeting requirements of
this standard which are specific to vehicle models. Tests can be extended for different
models however type approval will be required separately.
2.3
2.3.1
2.3.1.1
2.3.1.2
2.3.2
2.3.3
MODIFICATIONS AND EXTENSION OF APPROVAL
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 manufacturer to
the test agency.
If the changes are in parameters not related to the provisions, no further action need be
taken.
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
vehicle 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.
In case of 2.3.1.1, tests for only those parameters which are affected by the modifications
need be carried out based on Criteria for extension of approval as per Annexure B.
In case of fulfillment 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.
Draft AIS-140/D1
July 2016
Page 26 of 109
3.0 ITS FUNCTIONS AND IN-VEHICLE REQUIREMENTS
To be taken up after four wheeler section is complete
List of ITS functions for public transport operation (Auto Rickshaw) are given below.
Function Sub Functions
Operations
Management Automatic Vehicle Location Tracking
Safety and
Security Emergency Request
Functional Requirements, Construction and Installation, and Performance requirements are
defined below.
ITS ARCHITECTURE IN AUTO RICKSHAW.
3.1 AUTOMATIC VEHICLE LOCATION TRACKING (AVL)
3.1.1 Functional requirements
3.1.1.1 System shall be capable of obtaining position information using Global Navigation Satellite
System (GNSS). GNSS receiver specifications are as follows
a. System shall be capable for operating in L and/or S band and include support for
NAVIC/ IRNSS (Indian Regional Navigation Satellite System) with GAGAN
b. System shall have a position accuracy of minimum 2.5 m CEP or 6 m 2DRMS
c. System shall have an acquisition sensitivity of minimum (-) 148 dBm
d. System shall have an tracking sensitivity of minimum (-) 165 dBm
e. It is desirable to have an internal antenna; however if the fitment location prevents the
internal antenna from functioning, then external antenna shall be provided.
Draft AIS-140/D1
July 2016
Page 27 of 109
3.1.1.2 System shall support standard I/Os (Digital, Analogue and Serial Communication) for
interfacing external systems (E.g Digital input for Emergency request button interfacing).
3.1.1.3 System shall be capable of transmitting data to backend control center via Wide Area (Mobile)
Communications network (GSM/GPRS).
3.1.1.4
System shall be capable of collecting and transmitting Position, Velocity and Time (PVT data)
along with heading (direction of travel) in a fixed frequency to a backend control center (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).
3.1.1.5
System shall support standard I/Os (Digital, Analogue and Serial Communication) for
interfacing external systems (E.g Digital input for Emergency request button interfacing) to
meet the functional requirements.
3.1.1.6 System shall capable of transmitting data to 2 different IP addresses (1 IP for regulatory
purpose and 1 IP for operator services).
3.1.1.7
System shall have an internal back-up battery to support 4 hours of normal operations.
However in the case of external power supply failure/disconnect, the device shall perform
limited functions to extend the internal battery support for more than 24 Hrs (Position records
shall be collected and send once in an hour)
3.1.1.8
System shall capable of transmitting alerts (mandatory and user defined) to the backend
control center. The applicable mandatory list of alerts is given in Annexure – D (Alert ID 1 to
13).
3.1.1.9 System shall support over the air software and configuration update.
3.1.1.10
System shall support basic standard configuration (Mobile communications network settings,
control center server details, data frequencies, alert thresholds etc...) as per configuration
specification defined in Annexure - C.
3.1.1.11
System 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 un-availability and transmit the data when the connection resumes in
first in first out (FIFO) manner. The live data shall be given higher priority for transmission
than back log at any point in time.
3.1.1.12
The system shall have a unique identifier for identifying the unit and data from the unit. The
unique ID shall be stored in a read only memory area so that it cannot be altered or overwritten
by any person. IMEA (International Mobile Station Equipment Identity) Number shall be the
unique identifier.
3.1.1.13 System shall store/write the registration number of the vehicle in the internal nonvolatile
memory.
3.1.1.14 System shall support Embedded SIM.
3.1.1.15 System shall be designed to operate in DC power supply ranging from 9VDC to 14VDC (shall
support 12VDC vehicle battery).
3.1.1.16 System shall meet the vehicle to center data communication protocol requirements as defined
in Annexure - C (Clause 2.1 and 2.2).
3.1.1.17 System shall have a sleep mode current < 5 mA (If the function is implemented in a dedicated
system/device).
3.1.1.18
System shall have internal memory to store minimum 20000 positional logs (PVT Data) and
10000 alert records (The data shall not be overwritten, if the protected memory exceeds the
limits).
Draft AIS-140/D1
July 2016
Page 28 of 109
3.1.2 Construction and Installation
3.1.2.1 Requirements on vehicle interface
Connector for Power:
Connector requirements shall be as per Annexure – H, Clause 1.1 Minimum connector
requirements, Sl No 1 (Low Power System 1)
3.1.2.2 Physical Mounting
The system shall be mounted in such a way that it is not easily accessible to passengers or
driver without using special tool.
3.1.3 Functional, Performance, Durability and Environmental Tests
System shall meet the applicable testing requirements given in Annexure – F.
3.2 Emergency Request
3.2.1 Functional requirements
3.2.1.1 Passengers or in-vehicle crew present in the vehicle shall be able to make an emergency
request by pressing the emergency button provided.
3.2.1.2
The emergency request function shall not exist as standalone. The function shall be part of
Automatic Vehicle Location Tracking (AVL) system. An alert shall be send to the control
center when emergency request is activated and de-activated.
3.2.1.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.
3.2.1.4
On pressing of Emergency button, the system implementing AVL function shall send
emergency Alert (Alert ID 8 as mentioned in ANNEXURE D) to the configured IP addresses
as per the communication protocol mentioned in ANNEXURE C. In the absence of GPRS
network, the alert shall be send as SMS message along with vehicle location data to configured
control center number. The SMS shall consist parameters as given in Annexure E.
3.2.2 Construction and Installation
Emergency button shall be one time press type. Separate release action shall be required to
bring back to normal mode.
3.2.2.1 Physical Mounting
Emergency button shall be mounted inside passenger compartment of Auto-Rickshaw easily
accessible to passengers.
3.2.3 Functional, Performance, Durability and Environmental Tests
Emergency button will be tested along with Automatic Vehicle Location Tracking (AVL) unit
as per Annexure – F.
Draft AIS-140/D1
July 2016
Page 29 of 109
ANNEXURE – A
INFORMATION TO BE SUBMITTED FOR TYPE APPROVAL
1. ITS SYSTEM DETAILS
a. Make
b. Type (For bus/car/Auto-rickshaw)
c. Model No:
d. Part No.
e. Installation layout: Attach drawing showing location in vehicle.
2. Automatic Vehicle Location Tracking and Vehicle Health Monitoring
a. Make
b. Model No:
c. Part No.
3. In vehicle video surveillance and recording
a. Make
b. Model No:
c. Part No.
d. No of Cameras
i. Normal inside Passenger area
1. Make
2. Model
ii. Reverse
1. Make
2. Model
e. Recording memory
i. Type: SD card or HDD
ii. Make
iii. Size (MB)
4. Emergency Request
a. Make
b. Model No:
c. No of Buttons
d. Installation layout: Attach drawing showing location(s) in vehicle.
5. In-vehicle Passenger Information
a. Controller
i. Make
ii. Model
iii. Part No
b. LED Destination Boards
i. No of Boards
1. Front:
Draft AIS-140/D1
July 2016
Page 30 of 109
2. Rear:
3. Side
4. Internal
ii. Model No (Front/Rear/Side/Internal)
iii. Type (Front/Rear/Side/Internal)
iv. Part No (Front/Rear/Side/Internal)
v. Size (Front/Rear/Side/Internal)
vi. Installation layout: Attach drawing showing location(s) in vehicle.
6. In-vehicle automated ticketing (smart card based)
a. Make
b. Model
c. Part No
d. Installation layout (if at fixed location): Attach drawing showing location(s) in
vehicle.
7. Driver Console or Display Unit
a. Make
b. Model
c. Part No
d. Installation layout: Attach drawing showing location(s) in vehicle.
8. Driver Announcement System (Mic , Amplifier, Speaker)
a. Make
b. Model
c. Part No
d. Installation layout: Attach drawing showing location(s) in vehicle.
9. System Software
a. Make
b. Version
c. Operating System Details with Version
10. Communication Protocol Used
10.1 In-Vehicle
10.1.1 Between Systems/Devices Implement ITS Functions
10.1.1.1 ITS Function(s) – Vehicle ECUs
10.1.1.2 ITS Function(s) – ITS Function (s)
10.1.2 Within a System/Function
10.1.2.1 LED/PIS Controller to LED Signs
10.2 Vehicle to Center
10.2.1 AVL and Vehicle Health Monitoring to Control Center
Draft AIS-140/D1
July 2016
Page 31 of 109
10.2.2 Video Surveillance and recording to Control Center
10.2.3 Passenger Information to Control Center
10.2.4 Ticketing Machine to Control Center
11. DESCRIPTION OF DEVICE
12. DRAWINGS
13. INSTRUCTIONS MANUAL
Draft AIS-140/D1
July 2016
Page 32 of 109
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 ofAutomatic vehicle location
Tracking (AVL) and Vehicle Health
Monitoring, In vehicle video
surveillance and recording (camera’s
& recorder), Emergency Request
button, In-vehicle Passenger
Information System (LED Destination
boards & Controller, In-vehicle
automated ticketing (smart card
based), Driver Console or Display
Unit, Driver Announcement System
(Mic , Amplifier, Speaker)
Applicable tests as per Annexure F and
Functional verification at system
integration level.
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.
Draft AIS-140/D1
July 2016
Page 33 of 109
ANNEXURE – C
DATA COMMUNICATION PROTOCOL
1. IN-VEHICLE
a. BETWEEN SYSTEMS/DEVICES IMPLEMENT ITS FUNCTIONS
a1 ITS Function (s) - Vehicle ECUs
Application layer data interpretation shall be based on SAE J1939.
a2 ITS Function (s) – ITS Functions (s)
a2.1 AVL Controller - PIS Controller
Applicability: If the AVL and PIS functions are implemented in two independent controllers
In-vehicle passenger information controller requires GPS data from the system where AVL
function is implemented
Physical Interface: RS232, Baud 4800 (Serial Configuration as per NMEA-0183)
Data Interface: Standard NMEA-0183 message – GPRMC sentence @ 1 Hz
a2.2 AVL Controller - IN-VEHICLE VIDEO SURVEILLANCE AND RECORDING controller
Applicability: If the AVL and Video Recorder/DVR functions are implemented in two
independent controllers
AVL system to obtain health information from IN-VEHICLE VIDEO SURVEILLANCE AND
RECORDING systems
Physical Interface: RS232, Baud 9600
Data Interface: To be defined
b. WITHIN A SYSTEM / FUNCTION
b1 LED/PIS Controller - LED Signs
b1.1 LED Sign ID
Every LED sign in the vehicle shall have a different ID to enable error free communication
between controller and LED sign. The ASCII of LED sign ID shall be
Sl. No. Description of LED sign ID in ASCII ID in Hex
1 Front LED sign 0 $30
2 Side LED sign 1 $31
3 Rear LED sign 2 $32
4 Inner LED sign 3 $33
5 Side LED sign-2 4 $34
6 Inner LED sign-2 5 $35
Table 1: LED sign identification
Note: Same LED sign can be used in different positions of the bus. Under such cases ID of
LED sign shall be changed according to the position (front, side, rear)
Draft AIS-140/D1
July 2016
Page 34 of 109
Communication:
RS485 at 9600 bps. 2 wire core cable
b1.2 LED sign communication format
Block - 1
Start Of Header (SOH)
LED sign ID
Length MSB
Length LSB
Reserved
Start of text (STX)
Block - 2
Function code (FC)
Data (variable length)
Block - 3
End of text (ETX)
CRS (MSB)
CRS (LSB)
End of Transmission (EOT)
LED sign communication packet format
b1.2.1 Block – 1
Draft AIS-140/D1
July 2016
Page 35 of 109
Start of header:
First byte of initialization is ASCII control character SOH. The hexadecimal value is $01.
LED sign ID:
This byte is ASCII character of LED sign ID for which bitmap is created. Refer section 1 for
LED sign IDs. The data communicated from controller will be processed by LED sign whose ID
matches with this.
Length:
This indicates the total number of bytes of content. This is counted from STX to ETX (including
STX and ETX). Byte 3 is MSB and byte 4 is LSB of length.
Start of text:
This byte is ASCII control character STX. The hexadecimal value is $02.
LED sign communication contains ASCII control characters as given in below.
Description ASCII control character Hex
Start of header Start of header (SOH) $01
Start of Text Start of Text (STX) $02
End of text End of Text (ETX) $03
End of transmission End of transmission (EOT) $04
Table 2: ASCII control characters for block-1 and block-3
b1.2.2 Block – 2
Function code
Function code will represent different type of packets and functions. The range of function code
is limited to $80 – $ 88. The range $C0 – $C8 shall be only used for giving response to any of
the packet. This is derived by adding $40 to the function code received. From this it can be
identified whether the packet is response packet or not.
Function
code command description
$80 Link check Link status
$81 Route data transfer Route info update
$82 DTC code DTC code status
$83 PID code PID code status
$84 Adhoc message Adhoc message
$85 Set configuration sending configuration data
$86 Get configuration Getting configuration data
$87 Reserved
$88 Reserved
$89 Reserved
Table 3: Command codes for different functions
Data
This filed is variable data length. The format of “Data” for different command codes are given in
section b1.3. The response code from the LED sign is given in below table
Draft AIS-140/D1
July 2016
Page 36 of 109
Sl.No Response
code Description Layer
1 $00 Packet received and processed successfully Protocol
2 $02 CRC fail Protocol
3 $03 Invalid LED sign ID Protocol
4 $04 Invalid Command code Protocol
5 $05 No configuration Protocol
6 $06 Operation fail due to other conditions Protocol
7 $07 $1F Reserved Application
8 $08 Abnormal start of data packet Application
9 $09 Mismatch in serial number of data packet Application
10 $A Internal buffer overflow Application
11 $B Invalid data length Application
12 $C Invalid data Application
13 $D Internal write error Application
Table 4: Response codes from LED signs
Bit position Significance
b7 1 = System Link ok
0 = System Link not ok
b6 1 = System in Reset State
0 = System in Normal state
b5-b4
00 = System configuration not available
01 = System configuration available
10 = System configuration with default values
11 = Not used
b3-b0 Not used
Table 5: System status byte
b1.2.3 Block – 3
End of text:
This will indicates the display message data is completed. This is represented by ASCII control
character “End of Text (ETX)”. The hex value is $03.
CRC:
This CRC is 16-bit value, and it is placed in the Block 3. This is calculated as CRC of all the
bytes starting from Length MSB to last byte stored in BLOCK 2. CRC-16-CCITT (also known as
CRC-CCITT) is used for data integrity. The polynomial of CRC-16 is “x16+x12+x5+1” and its
hex value is 1021.
End of Transmission:
This byte represents the bit map data transmission is completed. This is represented by ASCII
control character “End of Transmission (EOT)”. The hex value is $04.
b1.3 The format of “Data” for different command codes
b1.3.1 Command code - Link check command:
Draft AIS-140/D1
July 2016
Page 37 of 109
Request from controller
Block-1
Block-2 Command code - $80
No data bytes
Block-3
Response from LED sign
Block-1
Block-2 Command code - $C0
2 data bytes
Block-3
First byte of the data shall be response code of the LED sign as given in table 4. The response
code is $00 for successful execution of the command. Second byte of the data shall be status of
the LED sign as described in the Table 5.
b1.3.2 Command code - Route Info Update:
Request from controller
Block-1
Block-2 Command code - $81
N – bytes for screen data
Block-3
Data bytes are the data content to be displayed on LED signs. The data extraction for a given
display content is given in section b1.4
Response from LED sign for message receipt
Block-1
Block-2 Command code - $C1
10 - data bytes
Block-3
First byte of the data shall be response code of the LED sign as given in table 4. The response
code is $00 for successful execution of the command. It shall be followed by eight bytes of
ASCII characters “RECEIVED”. Last byte of block-2 shall be status of the LED sign as
described in the Table 5.
Response from LED sign for message displayed
Block-1
Block-2 Command code - $C1
11 - data bytes
Block-3
First byte of the data shall be response code of the LED sign as given in table 4. The response
code is $00 for successful execution of the command. It shall be followed by nine bytes of ASCII
characters “DISPLAYED”. Last byte of block-2 shall be status of the LED sign as described in
the Table 5.
Draft AIS-140/D1
July 2016
Page 38 of 109
b1.3.3 Command code – DTC code status:
Request from controller
Block-1
Block-2 Command code - $82
4 data bytes
Block-3
Every DTC code shall be described by four ASCII characters as given in table 6. Controller shall
send four ASCII characters to LED signs for these DTC request.
ASCII / hex Code Description
1 2 0 0 "Over voltage".
This DTC code shall be sent by LED sign in case the applied
voltage is more than 30V. $31 $32 $30 $30
1 2 0 1 "Under voltage".
This DTC code shall be sent by LED sign in case the applied
voltage is less than 20V. $31 $32 $30 $31
1 2 0 3 "Over heat".
This DTC code shall be sent by LED sign in case the
temperature is more than 70°C. $31 $32 $30 $33
Table 6: DTC codes for LED signs
Response from LED sign
Block-1
Block-2 Command code - $C2
7 data bytes
Block-3
First byte of the data shall be response code of the LED sign as given in table 4. The response
code is $00 for successful execution of the command. It shall be followed by four bytes for
describing DTC code. Sixth byte is reply from LED sign with ASCII character “Y” ($59) or “N”
($4E). Last byte of block-2 shall be status of the LED sign as described in the Table 5.
b1.3.4 Command code – PID code status:
Request from controller
Block-1
Block-2 Command code - $83
3 data bytes
Block-3
Every PID code shall be described by three ASCII characters as given in table 7. Controller shall
send three ASCII characters to LED signs for PID request.
PID Description
1 0 0 Hardware revision
1 0 1 Serial number
Draft AIS-140/D1
July 2016
Page 39 of 109
1 0 2 Boot loader SW revision
1 0 3 Application SW revision
1 0 4 Font library revision
1 0 5 CPU part number
1 0 6 CPU qualification
1 0 7 CPU temperature range
1 0 8 Compilation of FW date and time
1 0 9 Flash update status
1 1 0 Test date and time
1 1 4 Article number sign level
1 1 5 Production date (production date)
1 1 6 End customer
1 1 7 Order number
1 1 8 Bus/vehicle type
1 1 9 Bus builder number (bus build)
2 0 8 Language
4 0 1 Board temp sensor
4 0 2 Internal CPU temp
6 0 0 Minimum temp CPU
6 0 1 Maximum temp CPU
6 0 2 Maximum temp board
6 0 3 Minimum temp board
6 0 4 Maximum input power voltage
6 0 5 Minimum input power voltage
6 0 6 Operating hours
6 0 7 Number of resets
6 0 7 Number of resets
Table 7: PID codes for LED signs
Response from LED sign
Block-1
Block-2 Command code - $C3
N- data bytes
Block-3
First byte of the data shall be response code of the LED sign as given in table 4. The response
code is $00 for successful execution of the command. It shall be followed by three bytes for
describing PID code. Then it shall be followed by PID value in ASCII characters. Last byte of
block-2 shall be status of the LED sign as described in the Table 5.
b1.3.5 Command code – Adhoc messages:
Request from controller
Draft AIS-140/D1
July 2016
Page 40 of 109
Block-1
Block-2 Command code - $84
N - data bytes
Block-3
Controller shall send the Adhoc messages in the form of ASCII characters. Number of bytes is
equal to number of characters of Adhoc message.
Response from LED sign for message receipt
Block-1
Block-2 Command code - $C4
10 - data bytes
Block-3
First byte of the data shall be response code of the LED sign as given in table 4. The response
code is $00 for successful execution of the command. It shall be followed by eight bytes of
ASCII characters “RECEIVED”. Last byte of block-2 shall be status of the LED sign as
described in the Table 5.
Response from LED sign for message displayed
Block-1
Block-2 Command code - $C4
11 - data bytes
Block-3
First byte of the data shall be response code of the LED sign as given in table 4. The response
code is $00 for successful execution of the command. It shall be followed by nine bytes of ASCII
characters “DISPLAYED”. Last byte of block-2 shall be status of the LED sign as described in
the Table 5.
b1.3.6 Command code – Sending configuration:
Request from controller
Block-1
Block-2 Command code - $85
1 data byte
Block-3
The Intensity shall be controlled automatically based on ambient light. However the allowed
maximum intensity shall be controlled under special conditions such as low battery voltage. The
maximum intensity levels shall be set back to factory settings after power OFF and ON. Data
byte description is given in table 8.
Data byte value Description
$00 Max 100% Intensity
$01 Max 75% Intensity
Draft AIS-140/D1
July 2016
Page 41 of 109
$02 Max 50% Intensity
$03 Max 25% Intensity
Table 8: data code for LED intensity level setting
Response from LED sign
Block-1
Block-2 Command code - $C8
2 data bytes
Block-3
First byte of the data shall be response code of the LED sign as given in table 4. The
response code is $00 for successful execution of the command. Second byte of the data shall
be status of the LED sign as described in the Table 5.
b1.3.7 Command code – Getting configuration:
Request from controller
Block-1
Block-2 Command code - $86
no data byte
Block-3
Response from LED sign
Block-1
Block-2 Command code - $C8
3 data bytes
Block-3
First byte of the data shall be response code of the LED sign as given in table 4. The response
code is $00 for successful execution of the command. Second byte of the data shall be max
allowed brightness as per table 8. Third byte of the data shall be status of the LED sign as
described in the Table 5.
b1.4 Data extraction for a given display content
LED sign shall display route information in multiple screens one after the other. Different
screens shall display route information in different languages. Controller command for route
information update is shown below
Block-1
Block-2 Command code - $81
N – bytes for screen
data
Block-3
Screen data is variable length information which contains attributes and bitmap of each screen as
shown in table 9.
Screen - 1
Display Mode
Columns for route number
Scrolling speed
Draft AIS-140/D1
July 2016
Page 42 of 109
Reserved ($FF)
Reserved ($FF)
Bitmap data (variable length)
Screen
separator Page separator ($1C)
Screen - 2
Display Mode
Columns for route number
Scrolling speed
Reserved ($FF)
Reserved ($FF)
Bitmap data (variable length)
Table 9: Route information screen data
Screen Attributes
Page Attributes shall be defined by 5 bytes data. The details of page attributes are given blow
Display Mode:
This byte indicates mode of display. Message can be displayed on LED sign in different formats.
Table 10 describes type of display modes with description
Display style Mode in
ASCII
Mode in
hex Description of display
Single line
display
Mode A $41 Fixed message
Mode B $42 Scrolling message
Mode C $43 Blinking Message
Two line
display
Mode D $44 Fixed message
Fixed message
Mode E $45 Fixed message
Scrolling message
Mode F $46 Scrolling message
Scrolling message
Mode G $47 Scrolling message
Fixed message
Single line
display as two
parts
Mode H $48 Fixed Fixed
Mode I $49 Fixed Scrolling
Mode J $4A Fixed Blinking
Two line
display as two
parts
Mode K $4B Fixed Fixed
Fixed
Mode L $4C Fixed Scrolling
Fixed
Mode M $4D Fixed Scrolling
Scrolling
Mode N $4E Fixed Fixed
Scrolling
Table 10: Type of LED sign display modes
Columns for route number:
Draft AIS-140/D1
July 2016
Page 43 of 109
This byte gives number of columns reserved to display route number. The display message
content can be divided as route number and route information. Route number shall be displayed
in first few reserved columns and route information shall be displayed in remaining columns.
Scrolling speed:
This is applicable only for scrolling mode of display. This indicates the speed at which display
scrolling shall happen in terms of number of columns per second. Normal scrolling speed is 50
columns per second.
Bitmap data Separators
Provision shall be provided to display route information either in single line or in two lines on
each screen. The data between the screens shall be separated with ASCII control character “File
Separator (FS)” or $1C. Data shall be divided into multiple packets incase given screen data
content is more than 4kbytes. The packets shall be separated with ASCII control character
“Group Separator (GS)” or $1D. The route information on LED sign shall be displayed in one
line or two lines. In case of two line display, message shall be separated by ASCII control
character “Line Feed (LF)” or $0A.
Packet attributes
First byte of bitmap data shall indicate the serial number of the data packet ranging from $00 to
$FF. Second byte shall have continuity status of the data packet. $00 in second byte indicates No
more packet in continuation to current packet, $FF indicates next packet to arrive in continuation
to current packet. Bitmap data third byte onwards indicates status of LED in each column.
Data representation
The status of each LED shall be considered as OFF before receiving data packets. OFF state
LED shall be represented as binary zero and ON state LED shall be represented as binary one.
Outer LED signs shall have 16 rows and inner LED sign shall have 8 rows. The status of LEDs
in every column is represented by 16 bits for outer LED sign. These 16 bits shall be divided in to
four nibbles and each nibble shall be converted to ASCII character. The status of LEDs in every
column is represented by 8 bits for inner LED sign. These 8 bits shall be divided in to two
nibbles and each nibble shall be converted to ASCII character. The range of each nibble in
ASCII is “0” to “F”.
Example
Following figure shows status of LEDs to display text “1” on 16 row LED sign. Data to
represent status of LEDs in each column is represented by four ASCII characters as shown in
table 11.
Draft AIS-140/D1
July 2016
Page 44 of 109
Figure - LEDs status for LED sign
Column
number
LED status
In binary in
ASCII in hex
Column 1 0001 0000 0000 0001 1 0 0 1 $31 $30 $30 $31
Column 2 0010 0000 0000 0001 2 0 0 1 $32 $30 $30 $31
Column 3 0100 0000 0000 0001 3 0 0 1 $33 $30 $30 $31
Column 4 1111 1111 1111 1111 F FFF $46 $46 $46 $46
Column 5 0000 0000 0000 0001 0 0 0 1 $30 $30 $30 $31
Column 6 0000 0000 0000 0001 0 0 0 1 $30 $30 $30 $31
Column 7 0000 0000 0000 0001 0 0 0 1 $30 $30 $30 $31
Table 11: LED status representation
2. VEHICLE TO CENTER
Vehicle to Center/Backend communication shall be based on ISO 15638 family of standards
2.1 PVT Data As per ISO 15638-15:2014 Intelligent transport systems – Framework for cooperative telematics
applications for regulated vehicles (TARV) – Part 15: Vehicle location monitoring
And
ISO 15638-5:2013 Intelligent transport systems – Framework for collaborative Telematics
Applications for Regulated commercial freight Vehicles (TARV) – Part 5: Generic vehicle
information
Relevant sections to be added 2.2 Alerts Data
To de defined As per ISO 15638-5:2013
2.3 Vehicle Health Data To de defined As per ISO 15638-5:2013
Draft AIS-140/D1
July 2016
Page 45 of 109
3 DATA CONFIGURATIONS To be added
Draft AIS-140/D1
July 2016
Page 46 of 109
ANNEXURE – D
ALERTS MASTER (IN-VEHICLE)
System shall generate alerts and send alert data to backend control center for the below mentioned
conditions. Alert ID shall be fixed and standard (1-125 for standard defined alerts and 126-255 user
specific proprietary alerts). 1 Alert List
Alert ID
(Integer) Alert Type
1 Ignition ON
2 Ignition OFF
3 Main Power/Vehicle Battery Disconnect
4 Main Power/Vehicle Battery Reconnect
5 Low Vehicle Battery Voltage Alert
6 Low Internal Battery
7 Low Internal Battery – Condition Off
8 Emergency Button is pressed (Emergency state ON)
9 Emergency Button is released (Emergency state OFF)
10 Emergency Button Disconnect/Removal/Wire cut Event
11 SIM removed (Not applicable for Embedded SIM)
12 SIM Inserted (Not applicable for Embedded SIM)
13 Case/Enclosure Opened
14 Vehicle Diagnostics Active (Applicable for Vehicle Health Monitoring)
15 Vehicle Diagnostics In-Active (Applicable for Vehicle Health Monitoring)
16 Reserved for standard
.. ..
125 Reserved for standard
126 Reserved for user specific/defined alerts
.. ..
255 Reserved for user specific/defined alerts
2 Alert Data Fields
Alert
ID
Field 1 Field 2 Field 3 Field 4 Field 5 Field
6
Field 7 Field
8
1 Timestamp Latitude Longitude GPS
Speed NA NA NA NA
2 Timestamp Latitude Longitude GPS
Speed NA NA NA NA
3 Timestamp Latitude Longitude GPS
Speed
Battery
Voltage NA NA NA
4 Timestamp Latitude Longitude GPS
Speed
Battery
Voltage NA NA NA
5 Timestamp Latitude Longitude GPS
Speed
Battery
Voltage NA NA NA
Draft AIS-140/D1
July 2016
Page 47 of 109
6 Timestamp Latitude Longitude GPS
Speed
Int
Battery
Voltage
NA NA NA
7 Timestamp Latitude Longitude GPS
Speed
Int
Battery
Voltage
NA NA NA
8 Timestamp Latitude Longitude GPS
Speed Direction
Cell
ID
Location
Area Code NA
9 Timestamp Latitude Longitude GPS
Speed Direction
Cell
ID
Location
Area Code NA
10 Timestamp Latitude Longitude GPS
Speed Direction
Cell
ID
Location
Area Code NA
11 Timestamp Latitude Longitude GPS
Speed
Battery
Voltage NA NA NA
12 Timestamp Latitude Longitude GPS
Speed
Battery
Voltage NA NA NA
13 Timestamp Latitude Longitude GPS
Speed
Battery
Voltage NA NA NA
14 Timestamp Latitude Longitude GPS
Speed
Source
ECU
SPN
FMI
Occurrence
Count NA
15 Timestamp Latitude Longitude GPS
Speed
Source
ECU
SPN
FMI
Occurrence
Count NA
Draft AIS-140/D1
July 2016
Page 48 of 109
ANNEXURE – E
EMERGENCY MESSAGE FORMAT (SMS Format)
The Emergency message shall consist of the following data fields –
Sl. No. Data
1 IMEI
2 Date and Time (Timestamp)
3 Vehicle Registration Number
4 Latitude
5 Direction
6 Longitude
7 Direction
8 GPS fix
9 Speed
10 Cell ID
11 Location Area Code
Draft AIS-140/D1
July 2016
Page 49 of 109
ANNEXURE – F
FUNCTIONAL, PERFORMANCE, DURABILITY AND ENVIRONMENTAL TESTS
1.0 VEHICLE LEVEL FUNCTIONAL TESTS
Following functionalities for each of the systems shall be demonstrated at the vehicle.
1.1 AUTOMATIC VEHICLE LOCATION TRACKING AND VEHCILE HEALTH
MONITORING
1.1.1 Connecter provision as per the section Construction and Installation - Requirements on
vehicle interface as specified in PARTI, PARTII, PARTIII
1.1.2 System transmits PVT information to back office control center (3 different IPs) at user
configurable frequency (5 seconds or less) via GSM/GPRS.
1.1.3 System to communicate to control center on the occurrence of the alerts captured in
ANNEXURE – D
1.2 IN-VEHICLE VIDEO SURVEILLANCE AND RECORDING (not applicable to Part II
& Part III of this standard)
1.2.1 Power and other signals to the system is provided via standard connector
1.2.2 Proper labeling is insisted for standard connectors (E.g. “DVR/Single Controller”)
1.2.3 No of Camera’s as per clause No 3.2.2.4 of Part I of this standard.
1.2.4 Capability to transfer recording using USB
1.2.5 Event based recording
1.2.6 Mounted in a secured and ventilated compartment right above the driver
1.2.7 In the case of integrated controller, mounting shall be in a secured and ventilated
compartment right above the driver
1.3 EMERGENCY REQUEST
1.3.1 Emergency request function- When any of the emergency buttons placed anywhere in the
vehicle is pressed by any passenger, make sure emergency request message has send and
received at the control center.
1.4 IN-VEHICLE PASSENGER INFORMATION (not applicable to Part II & Part III of this
standard)
1.4.1 Power and other signals to the system is provided via standard connector/s. There shall be
two dedicated power connectors – one for LED boards and one for Controller
1.4.2 Proper labeling is insisted for standard connectors (E.g. “PIS/Single Controller”)
1.4.3 The route or and destination board configuration file upload to the PIS controller via USB
drive
1.4.4 Route selection from list of routes configured
1.4.5 The following tests are applicable only if the Automatic Vehicle Location Tracking
function is built into PIS controller
1.4.5.1 GPS triggered next stop display on Inner sign with synchronized voice announcement for
Draft AIS-140/D1
July 2016
Page 50 of 109
minimum 75 stops on each route.
1.4.5.2 Speakers with protective grill : one each near the doors and others equally distributed across
the length of the bus- Total no. 4
1.4.5.3 In the case of integrated controller, mounting shall be in a secured and ventilated
compartment right above the driver
2.0 COMPONENT LEVEL FUNCTIONAL TESTS
Following functionalities for each of the systems shall be demonstrated. At the choice of the
manufacturer, below functionalities can also be alternately demonstrated at the vehicle level
and shall be deemed to be complied with at component level as well.
2.1 AUTOMATIC VEHICLE LOCATION TRACKING AND VEHCILE HEALTH
MONITORING (VHM) (Note: VHM is not applicable to Part II & Part III of this
standard)
2.2.1 Standard connector provided for Power and other signals as per Annexure H
2.2.2 Configuration of device as per the standard format mentioned in ANNEXURE C
Local configuration upload shall be verified
Configuration upload from control center shall be verified
2.2.3 Vehicle Location data transmission to back office control center
2.2.4 Back office should be able to check the version of firmware loaded on the system.
2.2.5 Update the firmware of the system from back office
2.2 IN-VEHICLE VIDEO SURVEILLANCE AND RECORDING (not applicable to Part II
& Part III of this standard)
2.2.1 Digital Video Recorder or Controller
2.2.1.1 Standard connector provided for power and other signals as per Annexure -H
2.2.1.2 The configuration in standard format to be uploaded to controller
2.2.1.3 48 hours of recording and storage of information
Test Procedure
Recording on 1 camera with highest resolution and 4CIF for minimum 48Hrs
continuously and same on the another camera with lowest resolution and CIF, to be kept
ready)
Download thee data using a pen drive and check for the continuity of recording
Verify time stamp overlay on the video
Allow the system to further record and download the data using a pen drive and verify
that the old files are overwritten by the latest files.
Verify that the recording is not continuously done in single file; size based file
switching is recommended
2.2.1.4 Transfer of recordings to control center / depot
Test Procedure
Demonstrate data transfer of video files from controller via high speed WLAN network to
control center.
2.2.1.5 Continuous or schedule based recording
Draft AIS-140/D1
July 2016
Page 51 of 109
Test Procedure
Configure schedule based recording for 2 Hrs. : 10mins recording, with 5 min gaps.
Start system
Verify the schedule based on video files recorded.
2.2.1.6 Emergency Recording
Configure emergency recording at high resolution
Enable emergency input (digital input) fed to the system for 5 minutes and disable
emergency input
Download the files via USB and verify the files for emergency settings based recording
2.3 IN-VEHICLE PASSENGER INFORMATION (not applicable to Part II & Part III of this
standard)
2.3.1 Controller test requirements
2.3.1.1 Standard connector provided for power and other signals as per Annexure -H
2.3.1.2 The standard route configuration file/s to be uploaded to controller and verify the route
update
2.3.1.3 Following tests are applicable only if the Automatic Vehicle Location Tracking
function is built into PIS controller
2.3.1.3.
1
Change / Choose / Select a 'route' remotely over the air from back office ().
Test Procedure
Send the route change request packet from server to on-board controller.
Verify the update of route displayed in LED destination boards
2.3.1.3.
2
Provide current route information to back office -
Test Procedure
Select a new route in the PIS system
Verify the information receipt at the center configured
2.3.1.3.
3
Transmission of adhoc messages (English) from back office to internal sign
Test Procedure
Send the adhoc packet from server to PIS controller.
Verify the inner sign for the remotely selected content display
2.3.1.3.
4
Back office should be able to check, via the controller, the version of firmware loaded on
the signs and controller.
Check the firmware version of controller and boards locally.
Verify the receipt of firmware information at control center.
2.3.1.3.
5
The diagnostic trouble codes of the LED destination boards shall be retrievable via the
controller at back office.
Create/simulate diagnostic troubles in LED signs
Verify the receipt of diagnostics trouble codes information at control center.
2.3.1.3. System should be able to provide route configured, GPS information over TCP socket to
Draft AIS-140/D1
July 2016
Page 52 of 109
6 ticketing machine.
2.3.2 LED Destination Boards
The system shall meet the functional requirements as per “LED Destination board system
for buses - specification” – IS 16490:2016
3.0 COMPONENT LEVEL PERFORMANCE AND DURABILITY TESTS
The performance tests to be performed for device level approvals are as listed below. Below
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:
i) Tracking functionality shall be checked via backend for the AVL system
ii) Camera feed and recording functionality shall be available for the DVR and camera
system, wherever applicable.
( Note: Tests mentioned in S.No 4, 9, 17, 18 & 19 are not applicable for Part II)
Sl.
No Test Test Procedure
Camer
a
AV
L
DV
R
1 Shock test
As per IEC 60068-2-29 using the
following test parameters
Shock form(Pulse) : half sinusoidal
Acceleration : 100 m/s2 (10g)
Duration : 6 ms
Number of shocks : 10 per test direction
2 Vibration test
The unit to be mounted in the same
orientation as in vehicle and subject to
vibration test for 100 hours will the
following specifications
Frequency : 5 – 40 Hz
Acceleration : 3g condition
Duration :100 hours (Test duration shall
be 32 h for each plane)
Orientation : As in vehicle condition
3
Ingress
Protection
(IP)
AVL, DVR and Camera shall be tested
as per IS /IEC 60947-1:2004 in
conjunction with IS/IEC 60529:2001.
Cameras shall meet minimum IP66.
AVL and DVR shall meet minimum
IP65.
If external antenna is used, it shall be
minimum IP 66.
Draft AIS-140/D1
July 2016
Page 53 of 109
4 EMI /EMC
AIS 004 (Part 3)
Note: This requirement shall be
deemed to comply when test is
conducted at vehicle level and vehicle is
fitted with all necessary devices.
5
Over Voltage
protection
Test
Test shall be conducted as per ISO
16750-2:2010
AVL, DVR, Camera & antenna shall be
connected as a system as per vehicle
configuration. (this is in case of
controller alone being powered by
vehicle battery)
Apply 18 V for 12 V System or Apply
36 V for 24 System on power lines for
60 minutes to units which are powered
directly by the vehicle battery
Test shall be conducted as per ISO
16750-2:2010. Functional status shall be
Class A.
6
Reverse
Polarity
Protection
without Fuse
Test Devices shall be connected as a
system as per vehicle configuration.
Apply reverse voltage of 13.5V to 12 V
System or 27.0 V to 24 V System
to power lines for 120 seconds to the
components which are powered directly
by the vehicle battery.
The component must fulfill the function
and service life requirement after the
test.
Test shall be conducted as per ISO
16750-2:2010.
Device shall be Class A performance for
functional tests, after the reverse
polarity test.
7
Wiring
Harness -
Flammability
Test
As per IS 2465 or IS15061
Draft AIS-140/D1
July 2016
Page 54 of 109
8
Wiring
Harness -
Electrical
Properties
As per AIS 028
or DIN72551 or ISO 6722
9 Free fall IS 9000 (Part VII/Sec 4) Free fall at
500 mm ×
10
.
Performance
parametric
test
(Nine points,
tri
temperature/tr
i voltage)
During testing, controller shall be kept
inside test chamber in power ON
condition.
(System should 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
24 V System 12 V System
18V, -25°C 9V, -25°C
18V, +80°C 9V, +80°C
18V, Room
Temperature
9V, Room
Temperature
27V, -25°C 13.5 V, -25°C
27V, +80°C 13.5V, +80°C
27V, Room
Temperature
13.5 V, Room
Temperature
32V, -25°C 16V, -25°C
32V, +80°C 16V, +80°C
32V, Room
Temperature
16V, Room
Temperature
×
11
.
Insulation
Resistance
Test
Test shall be conducted as per ISO
16750-2:2010 with a voltage of 500 V
DC. Insulation Resistance shall be > 1
MΩ.
No arcing or puncturing of insulation
allowed shall be observed.
×
Draft AIS-140/D1
July 2016
Page 55 of 109
12 Load Dump
Test
AVL, PIS and Recorder shall be tested
for this.
A Voltage spike of 123V, 8 Ohms
200ms pulse-5a as per standard ISO
7637-2.
×
13 Location
Accuracy Test
This test shall be conducted be
conducted on AVL. Test shall be
conducted on DVR if the DVR has an
integrated AVL Function.
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 signal 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.
×
14
Acquisition
Sensitivity
Test
This test shall be conducted be
conducted on AVL. Test shall be
conducted on DVR if the DVR has an
integrated AVL Function.
Procedure: Set the simulator to output
GPS signal 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 is referred as to the
acquisition sensitivity.
Acceptance Criteria: The acquisition
sensitivity shall be minimum (-) 148
×
Draft AIS-140/D1
July 2016
Page 56 of 109
dBm.
15
Tracking
Sensitivity
Test
This test shall be conducted be
conducted on AVL. Test shall be
conducted on DVR if the DVR has an
integrated AVL Function.
Procedure: The device under this test is
locked on to the simulator's output
frequency 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 should be equal to or better than
(-) 165 dBm.
×
16 Battery
Backup Test
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.
× ×
17
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: Should be less than 60
seconds at (-)148 dBm
× ×
18
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
× ×
Draft AIS-140/D1
July 2016
Page 57 of 109
averaged.
Acceptance Criteria: The warm start TTFF
should be less than 30 seconds at (-) 148
dBm.
19
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
should be less than 5 seconds.
× ×
4.0 COMPONENT LEVEL ENVIRONMENTAL TESTS
The environmental tests to be performed for device level approvals are as listed below.
Below 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:
i) Tracking functionality shall be checked via backend for the AVL system
ii) Camera feed and recording functionality shall be available for the DVR and camera
system
Sl.
No Test Test Procedure Camera AVL DVR
1
Dry Heat /
High
Temperature
Test
During testing, systems shall be kept
inside test chamber in power ON
condition. Test shall be done as per IS
9000 (Part III/Sec 5) – 1977.
Camera shall be tested for minimum
+55°C for 16 hrs.
AVL and DVR shall be tested at 70°C for
16 hrs.
External DVR (if applicable) can be tested
for 70°C for 16 hrs
2 Cold Test
'During testing, systems shall be kept
inside test chamber in power ON
condition. Test shall be done as per IS
Draft AIS-140/D1
July 2016
Page 58 of 109
9000 (Part II/Sec 4) - 1977 (reaffirmed
2004).
Operate test systems at -15°C for 2 hours
with continuous monitoring.
3 Damp Heat
Test
'During testing, systems shall be kept
inside test chamber in power off
condition. IS 9000 (Part V/Sec 2)1981 at
+25deg/+55deg C, Humidity 95%, 24
hours for 6 Cycles in off condition.
Functional test with Power in ‘On’
condition at start of 2nd
, 4th and 6
th cycle.
4 Temperature
Shock
Test as per EN60068 or equivalent.
Device after the test shall meet the
requirements of functional tests.
5 Salt Spray
Test
Tested as per AIS: 012/ IS10250. Device
after the test shall meet the requirements
of functional tests.
5.0 DATA CONFIGURATION TESTING
To be added based on the protocol selection
6.0 DATA COMMUNICATION PROTOCOL TESTING
To be added based on the protocol selection
Draft AIS-140/D1
July 2016
Page 59 of 109
ANNEXURE – G
HEALTH PARAMETERS- MASTER LIST
1.0 AUTOMATIC VEHICLE LOCATION TRACKING (AVL) AND VEHCILE HEALTH
MONITORING FOR BUSES
1.1 AVL health Monitoring
Below listed system health parameters can be sent over the air from system on demand from
backend data server.
Sl. No. Data Element
1 Vendor ID
2 Firmware Version
3 IMEI
4 Battery percentage
5 Low battery threshold value
6 Memory percentage
7 Data update rate when ignition ON
8 Data update rate when ignition OFF
9 Digital I/O status
10 Analog I/O status
1.2 Vehicle Health Monitoring (Applicable for buses only)
The system shall support the following minimum vehicle health parameters.
1. Wheel Based Vehicle Speed
2. Engine RPM
3. Engine Coolant Temperature
4. Fuel Consumption
5. Odometer (If available)
2.0 IN-VEHICLE VIDEO SURVEILLANCE AND RECORDING
2.1 Self-Health Parameters
Below listed system health parameters can be sent over the air from system on demand from
backend data server.
Sl. No. Data Element
1 mDVR ID
2 mDVR Name
Draft AIS-140/D1
July 2016
Page 60 of 109
3 Manufacturer's ID
4 Date and Time of Health Status
5 Device Primary IP
6 Device Secondary IP
7 Firmware Version
8 Protocol Version
9 IMEI Number
10 Memory Status
11 Camera 1 Recording Status
12 Camera 2 Recording Status
13 Camera 3 Recording Status
14 Camera 4 Recording Status
15 Microphone 1 Recording Status
16 Microphone 2 Recording Status
17 Microphone 3 Recording Status
18 Microphone 4 Recording Status
19 Ignition Status
20 Emergency Buttons Status
3.0 IN-VEHICLE PASSENGER INFORMATION
To be added
(Health parameters are covered in “LED Destination board system for buses - specification” – IS
16490:2016)
4.0 IN-VEHICLE AUTOMATED TICKETING (SMART CARD BASED)
The system shall meet the requirements as NATIONAL COMMON MOBILITY CARD,
MINIMUM STANDARDS & SPECIFICATION DOCUMENT FOR CARD AND DEVICES -
MOUD
Draft AIS-140/D1
July 2016
Page 61 of 109
ANNEXURE – H
PHYSICAL INTERFACES (CONNECTORS) FOR POWER AND I/Os
1 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 Max Power Typical Systems / Packages
Low Power Systems Up to 120 W
Telematics Unit/AVL System with Emergency
Button, ITS Controller/Single Control Unit,
DVR, Ticketing Machine
High Power Systems 120 - 360 W LED Destination Boards and Controller.
*Power details are given for 24V systems
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 Sl
No Recommended
Electrical
Provisions
Max
Power Applicable ITS Systems
Minimum
Requirement Recommended
Connector
1
Low Power
System 1
(Mandatory
Provision)
Up to
120 W
Telematics Unit/AVL
System with Emergency
Button
B+, SW+,
GND
OEM to protect
ISO 15170-B1-
3.1-Sn/K1
Socket
(Female)
Connector
Draft AIS-140/D1
July 2016
Page 62 of 109
2
Low Power
System 2
(Mandatory
Provision)
Up to
120 W
ITS
Controller/SCU/DVR/Ticketing
Machine
B+, SW+,
GND
OEM to protect
ISO 15170-B1-
3.1-Sn/K1
Socket
(Female)
Connector
3
High Power
System 1
(Mandatory
Provision)
120 - 360
W LED Boards, Controller
B+, SW+,
GND
OEM to protect
ISO 15170-B2-
3.1-Sn/K1
Socket
(Female)
Connector
4
CAN Interface
(OBDII CAN)
(Mandatory
Provision)
NA Telematics/ITS
Controller/SCU/DVR
CAN H,
CAN L,
GND
OEM to protect
ISO 15170-B1-
4.1-Sn/K1 Pin
(Male)
Connector
The OEM shall provide optional auxiliary connectors of their choice for meeting other OE specific
functional requirements.
1.2 Connector labeling in Wiring Harness:
Vehicle side wiring shall have the following labeling for the connectors Recommended Electrical
Provisions Labeling Requirement
Low Power System 1
(Mandatory Provision) ITS 120 W
Low Power System 2
(Mandatory Provision) ITS 120 W
High Power System 1
(Mandatory Provision) ITS 360 W
CAN Interface (OBDII CAN)
(Mandatory Provision) ITS CAN
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
Draft AIS-140/D1
July 2016
Page 63 of 109
Pin 2 CAN Low
Pin 3 Option CAN Ground
Pin 4 Not used
1.4 External antenna connectors
In case of external antenna provisions, ISO 20860-1:2008 (a.k.a FAKRA) standard interface
connectors shall be used
Antenna cable termination shall use Jack/Female:
Main GSM Antenna Fakra Code D / Female / Bordeaux
GPS Antenna Fakra Code C / Female / Blue
WLAN Antenna Fakra Code I / Female / Beige
ISO 20860-1:2008 (FAKRA) Connector
Draft AIS-140/D1
July 2016
Page 64 of 109
2 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
Draft AIS-140/D1
July 2016
Page 65 of 109
ANNEXURE – I
Device/Equipment Package Options
ITS Functions
On-board
Equipme
nt
Packages
Applicable
vehicle
categories
AUTOMATIC
VEHICLE
LOCATION
TRACKING
(AVL),
VEHICLE
HEALTH
MONITORING
EMERGE
NCY
REQUEST
IN-VEHICLE
VIDEO
SURVEILLAN
CE AND
RECORDING
IN-
VEHICLE
PASSENGE
R
INFORMATI
ON
IN-
VEHICLE
AUTOMAT
ED
TICKETING
Package 1
Buses, Cars,
Three
Wheelers,
other
commercial
vehicles
(VEHICLE
HEALTH
MONITORIN
G shall
applicable for
only buses)
-- --
Independent
System
Package 2
Buses (Inter-
state, Long
Distance)
--
Package 3 Buses (City)
Package 1 shall be a single equipment which shall be used in all types of vehicles
Package 2 shall have the following equipment options
Options Interfacing AVL and IN-VEHICLE VIDEO
SURVEILLANCE AND RECORDING
in independent controllers
AVL system to obtain health information from IN-
VEHICLE VIDEO SURVEILLANCE AND
RECORDING systems
Draft AIS-140/D1
July 2016
Page 66 of 109
Physical Interface: RS232, Baud 9600
Data Interface: As per ANNEXURE C - a.2.2
AVL and IN-VEHICLE VIDEO
SURVEILLANCE AND RECORDING
in one controller
NA
Package 3 shall have the following options
Options Interfacing
Package 2 + In-vehicle passenger
information controller
In-vehicle passenger information controller requires
GPS data from the system where AVL function is
implemented
Physical Interface: RS232, Baud 4800 (Serial
Configuration as per NMEA-0183)
Data Interface: As per ANNEXURE C – a2.1
All in one controller NA
Draft AIS-140/D1
July 2016
Page 67 of 109
ANNEXURE – J
DEFINITIONS
1. Circular Error Probability (CEP)
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.
2.
3.
4.
5.
6.
7.
Draft AIS-140/D1
July 2016
Page 68 of 109
ANNEXURE – K
COMPOSITION OF PANEL [To be added]
Draft AIS-140/D1
July 2016
Page 69 of 109
APPENDIX I: INTELLIGENT TRANSPORTATION SYSTEMS
(ITS) – USER NEEDS, USER SERVICES/FUNCTIONS AND
ARCHITCTURE FOR PUBLIC TRANSPORT (BUS)
1. Scope The scope of this document is to capture user requirements in public transport operations (Bus) and
propose a unified National ITS Architecture framework for all public transport ITS developments in
the country. This document will also be used as an input for formation of standards and specifications
for National ITS architecture.
2. User Needs of Public Transport Systems (Bus) Transportation sector plays a very important role in Indian Economy. Public transport remains the
primary mode of transport for majority of the population, and India's public transport systems are
among the most heavily used in the world.
Figure 1: The Users involved in Public Transport Bus Operation
The identified users from state transport undertakings (STUs) perspective are listed below
Users in Public Transport
Operation Description
Draft AIS-140/D1
July 2016
Page 70 of 109
Passengers The people who use the public transport system; end users
Public Transport Operators -
Operations Team
The people who manage the day to day operations of public transport
systems (Scheduling, Trip management, Vehicle management, Route
management, Driver management, Depot management, etc…)
Public Transport Operators - Service
Team
The team who do the maintenance activates of the public transport
vehicles and maintains the uptime of the fleet.
Public Transport Operators - In
vehicle staff (Drivers/Conductors
etc...)
The in-vehicle crew who manage the public transport vehicle
operation.
Vehicle Manufacturer - Service Team
The vehicle manufacturer who offer after sales
service/AMC/Warranty support to transport authorities.
Industries - Chartered Services
The industries/organizations hire public transport vehicles for
private/chartered services
Other Transport Operators /
Authorities (For multimodal
transport/traveler information)
Other transport authorities in the same city such as railways, metros,
trams, private buses and others. Other authorities like traffic, police,
emergency and others.
Table 12: Users in Public Transport Operation
List of User Needs
The user needs are captured and consolidated for the identified users in Public Transport Operation
(Bus). The needs are further grouped to subsections for ease of classification.
The needs are mapped to
1. ITS functions that serve them
2. Applicability in the transport operation type; intercity or intra city.
The listed used needs are not mandated and transport operators shall choose the ITS functions
based on their needs and priority (For example a small operator shall opt for minimum number of
ITS functions compared to a large operator).
2.1 The List of Needs of Passengers
The passenger needs are grouped to needs during transit (inside the vehicle), needs while waiting
at stops/depots/stations and needs when travel is being planned. The consolidated needs are
tabulated in the following sections.
In-Vehicle
No User needs Functions Applicability
1.1.1.1 The system shall have a provision to display
route/destination information; day and night readable.
Information shall be provided in three languages
Passenger
Information Intra City
Draft AIS-140/D1
July 2016
Page 71 of 109
(Local Language, English and Hindi)
1.1.1.2
The system shall provide the route information and
travel/transit specific static information inside the
vehicle for convenience in audio and/or visual format.
Passenger
Information
Intra City/Inter
City
1.1.1.3
The system shall provide GPS triggered next stop and
points of interest (POI) information in audio and/or
visual format. POIs - Bus, railway stations, airports,
transit mode change points and others
Passenger
Information Intra City
1.1.1.4 The system shall provide Expected Time of Arrival
(ETA) in audio and/or visual format
Passenger
Information
Intra City/Inter
City
1.1.1.5
The system shall provide real time data on schedules,
timings, delays and others from other public transport
modes (metro, flight, tram and others), in case of
multimodal transportation
Passenger
Information
Intra City/Inter
City
1.1.1.6
The system shall provide real time data on traffic,
weather, incidents, traffic diversions, events and others
in audio and/or visual format.
Passenger
Information
Intra City/Inter
City
1.1.1.7
The system's information (ETA, Stop Information and
others) delivery, representation shall be in standard
format across all types of vehicle/operators.
Passenger
Information
Intra City/Inter
City
1.1.1.8 The system shall provide internet connectivity to
mobile phones, laptops and tablets.
Passenger
Information
Intra City/Inter
City
1.1.1.9
The system shall be able to provide electronic ticket
issue or/and electronic ticket payment for convenience
(Electronic ticketing machines, Smart card based
ticketing and others).
Fare Collection
Management Intra City
1.1.1.10
The system shall be able to provide single ticket for
multiple modes of transport, in case of multimodal
transportation
Fare Collection
Management Intra City
1.1.1.11
The system shall have a provision to make
emergency/panic message to control center from the
vehicle
Safety and Security Intra City/Inter
City
At Stops / Shelters
Draft AIS-140/D1
July 2016
Page 72 of 109
No User needs Category Applicability
1.1.1.11 The system shall provide Expected Time of Arrival
(ETA) in audio and/or visual format Passenger Information Intra City
1.1.1.12
The system shall provide real time data on schedules,
timings, delays and others from other public transport
modes (metro, flight, tram and others) , in case of
multimodal transportation
Passenger Information Intra City
1.1.1.13
The system's information (ETA, Stop Information and
others) delivery, representation shall be in standard
format across all stops/shelters/operators.
Passenger Information Intra City
At Depots
No User needs Category Applicability
1.1.1.14 The system shall provide Expected Time of Arrival
(ETA) in audio and/or visual format Passenger Information
Intra
City/Inter City
1.1.1.15 The system shall provide dynamic departure
information in audio and/or visual format Passenger Information
Intra
City/Inter City
1.1.1.16
The system shall provide real time data on schedules,
timings, delays and others from other public transport
modes (metro, flight, tram and others)
Passenger Information Intra
City/Inter City
1.1.1.17
The system shall provide real time data on traffic,
weather, incidents, traffic diversions, events and others
in audio and/or visual format.
Passenger Information Intra
City/Inter City
1.1.1.18
The system's information (ETA, Stop Information and
others) delivery, representation shall be in standard
format across all types of operators/depots/stations.
Passenger Information Intra
City/Inter City
SMS, Web (Mobile/Tablet/Laptop/PC)
No User needs Category Applicability
1.1.1.21 The system shall provide Expected Time of Arrival
(ETA) Passenger Information
Intra City/Inter
City
Draft AIS-140/D1
July 2016
Page 73 of 109
1.1.1.22
The system shall provide real time information on
schedule changes, route deviations, city traffic,
weather, incidents, traffic diversions, events and others
Passenger Information Intra City/Inter
City
1.1.1.23
The system shall provide real time departure
information, latest time table and frequency
information of public transport
Passenger Information Intra City/Inter
City
1.1.1.24
The system shall recommend public transport route
numbers to specified destinations with latest fare
details. Filtering options for transit changes, shortest,
fastest and cheapest route shall be provided.
Passenger Information Intra City/Inter
City
1.1.1.25
The system shall recommend travel plans for an
origin/destination input (With route switch points and
fare information). Filtering based on transit changes,
shortest, fastest and cheapest options shall be provided
Passenger Information Intra City/Inter
City
1.1.1.26
The system shall integrate information from other
public transport operations (Train, Metro, Tram and
others) and provide travel plan and fare for an
origin/destination input. Filtering based on transit
changes, shortest, fastest and cheapest options shall be
provided
Passenger Information Intra City
1.1.1.27 The system shall feature a single toll free helpline
number for any travel specific information request. Passenger Information
Intra City/Inter
City
1.1.1.28
The system shall have a provision for logging
complaints, ratings and grievances (Social media
linking shall be possible)
Passenger Information Intra City/Inter
City
1.1.1.29 The system shall have a provision to recharge smart
card based tickets online.
Fare Collection
Management Intra City
1.1.1.30
The system shall have a provision for online ticket
booking and management (Check Ticket/Seat
availability, Book Tickets, Cancel Tickets)
Operations
Management Inter City
2.2 The List of Needs of Operations/Control Team
No User needs Category Applicability
1.1.2.1 The system shall have a provision to manage
route/destination information displayed in the vehicle Passenger Information Intra City
Draft AIS-140/D1
July 2016
Page 74 of 109
1.1.2.2
The system shall have a provision to display Static
and/or Dynamic Advertisements and /or Information
inside the vehicles
Passenger Information Intra City
1.1.2.3
The system shall have provision for electronically
configuring new routes by physically accessing the
vehicle and/or over wireless
Passenger Information Intra City
1.1.2.4
The system shall have a provision to configure and
manage GPS triggered automatic next stop information
in the vehicle by physically accessing the vehicle and/or
over wireless
Passenger Information Intra City
1.1.2.5 The system shall ensure high level of accuracy in
location based features Passenger Information
Intra City/Inter
City
1.1.2.6
The system shall have a provision to real time Track-
Trace (Including route history playback) all the vehicles
in the fleet from control center.
Operations
Management
Intra City/Inter
City
1.1.2.7 The system shall have a provision to notify any
emergency message coming from vehicles
Operations
Management
Intra City/Inter
City
1.1.2.8
The system shall have a provision to centrally manage
advertisements/ travel specific information at stops,
depots, in-vehicle, Mobile/SMS/Web.
Passenger Information Intra City/Inter
City
1.1.2.9
The system shall have a provision to obtain information
(E.g. arrival/departure time) from other operators and
manage the information delivery to Passengers
Passenger Information Intra City/Inter
City
1.1.2.10
The system shall have a provision to centrally configure
and manage Routes, Schedules, Chartered Trips,
Vehicles, Crew, Stops, Depots, Division, Corporation,
Maintenance Schedules and Others (There shall be
unique numbering for all the
stops/depots/divisions/corporation for effective
management)
Operations
Management
Intra City/Inter
City
1.1.2.11 The system shall have a provision to manage MIS
reports
Operations
Management
Intra City/Inter
City
Draft AIS-140/D1
July 2016
Page 75 of 109
1.1.2.12
The system shall have a provision to capture vehicle
performance data (Including diagnostics) remotely in
real time.
Operations
Management
Intra City/Inter
City
1.1.2.13
The system shall have a provision to generate
operational reports (Time management, Schedule
adherence report and Others)
Operations
Management
Intra City/Inter
City
1.1.2.14
The system shall have a provision for driver
performance monitoring (Driver Scorecard) and
reporting
Operations
Management
Intra City/Inter
City
1.1.2.15
The system shall provide high level dashboards with
summary information for various users (Administrator
roles, Operation roles, Service/Support roles and Others)
Operations
Management
Intra City/Inter
City
1.1.2.16
The system shall provide alerts associated with business
rules - E.g. Exceptions/violations in the vehicles (Over
speeding, excessive idling, route deviation, harsh
acceleration, harsh braking, over stoppage, stop skipping
and others).
Operations
Management
Intra City/Inter
City
1.1.2.17
The system shall be able to provide management
solution bundle for both intercity and intra city
operations; certain modules shall be common
Operations
Management
Intra City/Inter
City
1.1.2.18
The system shall have provision for monitoring/doing
surveillance inside the vehicle. There shall be a
provision for storing and retrieving surveillance data on
need basis.
safety and security Intra City
1.1.2.19
The system shall provide electronic ticketing; it shall be
common for multimodal travel (Bus, Train, Metro and
others) in case of multimodal transportation
Fare Collection
Management Intra City
2.3 The List of Needs of In-vehicle Crew
No User needs Category Applicability
1.1.3.1 The system shall provide a user friendly interface for
managing route information display in the vehicle Passenger Information Intra City
1.1.3.2
The system shall have a provision to make
emergency/panic message to control center from the
vehicle
Safety and Security
Intra
City/Inter
City
Draft AIS-140/D1
July 2016
Page 76 of 109
1.1.3.3 The system shall have a provision to make public
announcements to the Passengers Passenger Information
Intra
City/Inter
City
1.1.3.4
The system shall provide an audio and/or visual
aid/assistance to reverse the vehicle. The assistance
shall be active when reverse gear is engaged
Safety and Security
Intra
City/Inter
City
1.1.3.5 The system shall provide the status of passenger doors
(Closed/Open). Safety and Security Intra City
1.1.3.6 The system shall enable electronic ticket issue Fare Collection
Management Intra City
1.1.3.7 The system shall do crew identification with electronic
ID cards.
Operations
Management
Intra
City/Inter
City
1.1.3.8 The system shall not provide display systems in driver
cabin which can distract the crew/driver Safety and Security
Intra
City/Inter
City
2.4 The List of Needs of STU Service/Maintenance Team
No User needs Category Applicability
1.1.4.1
The system shall have a provision to real time notify
vehicle issues (Diagnostics, Error Codes and Trouble
Codes from ECU/Other Electronic Systems) in the
backend for taking immediate corrective action and
thereby reducing the down time of the vehicle.
Operations
Management
Intra City/Inter
City
1.1.4.2
The system shall have a provision to remotely check the
software/firmware versions of electronic systems
installed in the vehicle.
Operations
Management
Intra City/Inter
City
1.1.5.3
The system shall have a provision to configure and
manage scheduled maintenance of vehicles (Distance or
time based schedules shall be created in the system and
the system shall notify the due for maintenance)
Operations
Management
Intra City/Inter
City
1.1.4.4
The system shall have a provision for remotely
upgrading the software or configuration in control units
in vehicle via remote/wireless and/or via tools
Operations
Management
Intra City/Inter
City
Draft AIS-140/D1
July 2016
Page 77 of 109
1.1.4.5
The system shall have a provision for manually
downloading the electronic system operational logs from
the vehicle.
Operations
Management
Intra City/Inter
City
2.5 The List of Needs of Vehicle Manufacturer Service Team
Transport operators purchase vehicles from multiple manufacturer and generally AMC (Annual
Maintenance Contract) is signed with the manufacturer for service support. If the system shall able to real
time notify the vehicle problems to service team at manufacturer end, then the service team can
proactively take action and fix the problem in a faster way. Further the data would help the manufacturer
to find the root cause of the issue and make product improvements.
No User needs Category Applicability
1.1.5.1
The system shall have a provision to real time notify
vehicle issues (Diagnostics, Error Codes and Trouble
Codes from ECU/Other Electronic Systems) in the
backend for taking immediate corrective action and
thereby reducing the down time of the vehicle.
Operations
Management
Intra City/Inter
City
1.1.5.2
The system shall have a provision to remotely check the
software/firmware versions of electronic systems
installed in the vehicle.
Operations
Management
Intra City/Inter
City
1.1.5.3
The system shall have provision for manually
downloading vehicle health data (Diagnostics and other
critical health parameters) for quick identification and
resolution of problems.
Operations
Management
Intra City/Inter
City
1.1.5.4 The system shall have provision for retrieving historic
vehicle health at any point in time.
Operations
Management
Intra City/Inter
City
1.1.5.5 The system shall have a provision to remotely track the
location of the vehicle on breakdown service request.
Operations
Management
Intra City/Inter
City
1.1.5.6
The system shall have a provision to obtain the vehicle
contact details and call driver/vehicle owner to provide
necessary service support/guidance.
Operations
Management
Intra City/Inter
City
2.6 The List of Needs of Chartered Service Users
No User needs Category Applicability
1.1.6.1 The system shall provide location based services (E.g.
Track and Trace)
Operations
Management Intra City
Draft AIS-140/D1
July 2016
Page 78 of 109
1.1.6.2
The system shall have a provision to check transport
vehicle availability (With cost details) for
booking/obtaining chartered services
Operations
Management Intra City
2.7 The List of Needs of Other Transport Operators / Authorities
No User needs Category Applicability
1.1.7.1
The system shall offer a provision to transport operators
to exchange dynamic arrival/departure information,
time table, schedules, travel time and fare information
with other transport operators
Passenger Information Intra City
1.1.7.2
The system shall offer a provision to other authorities to
obtain online and/or offline road speed profile data
(Route/Location Specific) for traffic analysis.
Operations Management Intra City
1.1.7.3 The system shall offer a provision to use single ticket
for multiple transport modes (Bus, Train, Metro etc…)
Fare Collection
Management Intra City
2.8 List of Standardization Needs Standardization is required for following sections to ensure inter-operability and compatibility between
various subsystems
Standardization needs
The system shall provide a nationwide unique number for travel specific information
All electrical/electronic interfaces shall be standardized
All physical installations shall be standardized
All information delivery shall be in standard formats
All configuration management shall be standardized
All reporting systems shall be standardized
All services shall be standardized
All data communication protocol shall be standardized (Vehicle to Control center, Systems to Systems,
Sub systems to Sub Systems, Node to Node, Vehicle to Vehicle and Others)
All system validation tests shall be standardized
All electrical/electronic interfaces shall be standardized
All physical installations shall be standardized
Draft AIS-140/D1
July 2016
Page 79 of 109
3. ITS Architecture
3.1 Introduction A system architecture for ITS is an ‘Overall framework for ITS’ that shows the major ITS
components and their interconnections. An ITS Architecture provides a common framework for
planning, defining, and integrating Intelligent Transportation Systems. It specifies how the different
ITS components would interact with each other to help solve transportation problems. It helps
transportation authorities to address their needs with a wide variety of options. It identifies and
describes various functions and assigns responsibilities to various stake-holders of ITS. The ITS
architecture should be common throughout the region / state / country so that it can address solution
to the several existing transportation problems while interacting with various transportation agencies.
It is the framework around which multiple design approaches can be developed, each one specifically
tailored to meet the individual needs of the user, while maintaining the benefits of a common
architecture.
A very important part of the system architecture is the identification and description of the interfaces
between major ITS components. These interfaces allow the major components of an overall ITS to
communicate with one another and to work together.
The National ITS Architecture for Bus Public Transport described in the forthcoming sections of this
document, provides overall guidance to ensure system, product, and service compatibility /
interoperability, without limiting the design options of the stakeholders.
This architecture defines –
Functions (e.g., gather traffic information or request a route) that must be performed to
implement a given user service,
Physical entities or subsystems where these functions reside (e.g., the roadside or the
vehicle),
Interfaces/information flows between the physical sub-systems and the communication
requirements for the information flows (e.g., fixed-point to fixed-point or wide area wireless).
Identifies and specifies the requirements for the standards needed to support national and
regional interoperability, as well as product standards needed to support economy of scale
considerations in deployment.
Key aspects taken care in the proposed architecture are - 1. Interoperability - The ITS architecture shall be such that the information collected, function
implemented or any equipment installed be interoperable by various agencies in different
state and regions.
2. Information exchange capability - The system information shall be accessible by various
services viz., emergency, police, etc.
3. Resource sharing – Communication infrastructure at any location becomes accessible for
ITS operations.
Draft AIS-140/D1
July 2016
Page 80 of 109
4. Compatibility - Software or hardware components in the system if replaced / upgraded will
still work with existing system.
5. Scalability - System shall be upgradable to handle greater volumes of work, operate in
additional locations, or incorporate new tasks.
3.2 Architecture Definition Approach
Figure 2: National ITS Architecture Definition Approach
The National ITS Architecture for Bus Public Transport consists of below sub-levels as defined in
forthcoming sections–
1. Logical Architecture
2. Physical Architecture
3. Communication Architecture
National ITS Architecture provides a platform and framework for defining and implementing ITS
user services. The document defines minimal reference architecture required for ITS for Public
Draft AIS-140/D1
July 2016
Page 81 of 109
Transport Operation and management. The architecture document is intended to define the
following.
1. The user functions and sub functions
2. How logically functions are linked – Logical Architecture
3. Physical aspect of functions – Physical Architecture
4. How the entities communicate with each other – Communication Architecture
3.3 ITS user functions and sub functions
Figure 3: ITS user functions and sub functions
3.4 Logical Architecture The Logical Architecture defines the functionality needed by the System to fulfill the user needs. It
illustrates the ITS system architecture at many levels of detail.
The logical architecture aims to explain the configuration of services, without worrying about how it
will get done. It takes the form of a series of data flow diagrams (DFDs) which depict logical
processes (shown as circles), entities (rectangles), data flows (arrows) and data stores (logical data
files, shown as a name between parallel lines). Figure below shows the very highest level DFD for the
logical architecture. Each of the processes is then blown up into an entire DFD of its own, with
additional lower level detail. This refinement continues for a number of levels.
Draft AIS-140/D1
July 2016
Page 82 of 109
Figure 4: DFD - Overall Logical Architecture
Draft AIS-140/D1
July 2016
Page 83 of 109
DFD - FN1. Operations Management
Figure 5: DFD - FN1. Operations Management
USE CASES - FN1. Operations Management
FN1.1 Operations Management - Automatic Vehicle Location Tracking and
Vehicle Health Monitoring
Use Case ID Use Cases
FN1.1_UC01
Manage users
System shall have provision to
a) Manage users and passwords
b) Manage roles assignment for all users
c) Manage accessibility rights (read/write/edit) for all users
Draft AIS-140/D1
July 2016
Page 84 of 109
FN1.1_UC02
Manage master data
The system shall manage master data for
a) Head Office
b) Zone
c) Region
d) Corporation
e) Depot
f) Vehicle
g) Controller(s)
h) Routes
i) Stops
j) Schedules
k) Chartered trips
There shall be unique numbering for all the stops/depots/divisions/corporation for
effective management
FN1.1_UC03
Manage master data for alerts
The system shall manage alert data for
a) Over speeding
b) Route Deviation
c) Low Fuel Warning
d) Route Schedule deviation
e) Over stoppage time
f) Non Stoppage
The system shall provide alerts under such conditions associated with business rules.
The alerts list shall be standardized with unique identifier for each alert.
FN1.1_UC04
Manage controller configuration
The system shall manage for:
a) Create controller configuration setting files
b) Upload configuration settings to controller
c) Retrieve configurations settings from controller
The system shall have a provision to remotely check the software/firmware versions of
electronic systems installed in the vehicle.
The system shall have a provision for remotely upgrading the software or
Draft AIS-140/D1
July 2016
Page 85 of 109
configuration in control units in vehicle via remote/wireless and/or via tools
FN1.1_UC05
Track the vehicle
The system shall track vehicles online and provide information like
a) Vehicle Current Location
b) Vehicle Travelled Route
c) Display of Actual vehicle Route
d) Route Deviation w.r.t Actual vehicle Route
e) Time of Arrival
f) Time of Departure
g) Vehicle Tracking via line diagram & bunching of buses
The system shall offer a provision to other authorities to obtain online and/or offline
road speed profile data (Route/Location Specific) for traffic analysis.
The system shall have a provision for vehicle OEM to track the location of the vehicle
remotely on breakdown service request.
FN1.2 Operations Management - Performance management (Vehicle, Driver)
Use Case ID Use Cases
FN1.2_UC01
Monitor vehicle/driver performance
The system shall generate performance (score card) reports for a given vehicle(s) /
Driver(s) for a selected duration. Some of the parameters to be considered for
performance analysis are
a) Speed Violation
b) Driver Duty Performance
c) Daily out shedding Deviation
d) Driver wise improper stopping
e) Details of missed Trip
f) Actual Trip
g) Extra Trip
h) Vehicle Distance Travelled
i) Average Speed
j) Accident analysis
k) Schedule adherence
l) KMPL Variation
m) Excessive idling
n) Harsh acceleration
Draft AIS-140/D1
July 2016
Page 86 of 109
o) Harsh braking
p) Over stoppage
q) Stop skipping
r) Green band driving
FN1.3 Operations Management - Route/Schedule management
Use Case ID Use Cases
FN1.3_UC01
Manage vehicle schedule
Operator shall manage vehicle (s) schedules
a) Create route schedule
b) Assign/Cancel route schedule
c) Route rescheduling
FN1.3_UC02
Manage chartered services
a) The system shall have a provision to check transport vehicle availability (With
cost details) for booking/obtaining chartered services
b) The system shall have a provision to allocate chartered schedules.
FN1.4 Operations Management - Maintenance/Service management
Use Case ID Use Cases
FN1.4_UC01
Manage vehicle maintenance/service
System shall have a provision to manage periodic Maintenance/Service
a) System shall have a provision to create maintenance/service schedules for
vehicle(s)
b) Notification Alerts shall be provided by system for maintenance/service
remainders reminders.{ARAI: Typo error}
c) System shall have a provision to maintain maintenance/service records
FN1.4_UC02
Monitor vehicle health online
a) The system shall monitor vehicle health online. System shall alert operator in
case of any of the parameter is beyond threshold values for taking immediate
corrective action and thereby reducing the down time of the vehicle. Few of the
health parameters are as follows
Draft AIS-140/D1
July 2016
Page 87 of 109
a. Engine Speed
b. Oil Pressure
c. Air Pressure
d. Vehicle Speed
e. Fuel Level
f. Diagnostics of controller(s)
g. Error codes and trouble codes from ECU/other electronic systems
b) The system shall have a provision to obtain the vehicle contact details and call
driver/vehicle owner to provide necessary service support/guidance.
c) The system shall have provision for retrieving historic vehicle health at any point
in time.
FN1.4_UC03
Download vehicle health data
a) The system shall have provision for manually downloading vehicle health data
(Diagnostics and other critical health parameters) for quick identification and
resolution of problems.
b) The system shall have a provision for manually downloading the electronic
system operational logs from the vehicle.
FN1.4_UC04
Share vehicle health data with respective vehicle OEMs
The system shall have a feature to provide vehicle health data access to respective
vehicle manufacturers
FN1.5 Operations Management - Crew (Driver/Conductor) management
Use Case ID Use Cases
FN1.5_UC01
Manage crew (Driver/Conductor) information
The system shall have provision to manage (Create/Edit) crew information.
The system shall have provision to assign crew for vehicle/schedules/shifts
The following minimal information shall be stored for crew
a) Crew ID
b) Name
c) Age
d) License details (including expiry)
Draft AIS-140/D1
July 2016
Page 88 of 109
FN1.5_UC02
Crew (Driver/Conductor) identification
The system shall do crew identification with electronic ID cards. This will enable
identifying crew details remotely.
FN1.6 Operations Management - Reservations management
Use Case ID Use Cases
FN1.6_UC0
1
Manage reservation data
The system shall have a provision manage reservations online
a) The system shall manage user login for passengers
b) The system shall provide seat availability
c) The system shall have the provision to book/cancel tickets online
d) The system shall provide secure e-payments
e) The system shall manage user details with reservation details (service number, seat
number etc.)
f) The system shall provide occupancy data and reports
Draft AIS-140/D1
July 2016
Page 89 of 109
DFD - FN2. Passenger Information
Figure 6: DFD - FN2. Passenger Information
Draft AIS-140/D1
July 2016
Page 90 of 109
USE CASES - FN2. Passenger Information
FN2.1 Passenger Information – In vehicle (Location based announcements)
Use Case ID Use Cases
FN2.1_UC01
Generate route configuration
a) The system shall have provision to create destination and route data for LED sign
boards in different languages.
b) All route information shall be managed by a central application
c) The system shall have provision to create route data in alphanumeric with
standard and customized graphics
d) The system shall have provision to create route data with special signs like signs
for "PWD enabled bus", "ladies special', etc.
e) The display content shall be in fixed, scrolling and flashing mode.
f) The system shall support single line and two line display and the height of
individual lines shall be adjustable to enable one line larger/smaller than other
line.
g) The system shall have provision to display different messages concurrently on
each LED sign.
h) The system shall have provision to configure route data in English and local
language using Microsoft fonts.
i) The system shall have provision to configure bus stops/Point Of Interest with geo-
location, audio file and display content for location based announcements. Some
of the POIs are Bus station, railway station, airport, transit mode change points
and others
FN2.1_UC02
Edit/Modify route configuration
The system shall have provision to edit existing route configurations
FN2.1_UC03
Load/Copy route configuration in vehicle
The system shall have provision to load route configuration via USB and Wireless
FN2.1_UC04
Select route in vehicle
a) The system shall store route configuration for minimum 75 routes (150
destinations) and 75 bus stops in each route in 3 different languages.
b) The system shall have provision to select/change route in the vehicle by the
driver.
c) The system shall have provision to update/report the route selected in the vehicle
to control center.
d) The system shall have provision to select/change route in the vehicle remotely
Draft AIS-140/D1
July 2016
Page 91 of 109
over the air from control center.
FN2.1_UC05
Display content on LED signs:
a) LED sign display shall be in amber color
b) Outer LED signs (Front, side and rear LED signs) shall be visible from a distance
of minimum 50 meters, for single line text in day and night light conditions.
c) Inner LED signs shall be visible from a distance of minimum 15 meters, for single
line text in day and night light conditions.
d) LED Signs shall have ability to retain the last message displayed in the memory
of the sign even in the event of power failure and without the message being
reloaded from controller.
e) LED sign shall have in-built light sensor with continuously variable brightness to
enable the display intensity to change based on ambient light condition
f) LED signs shall have provision to record diagnostics and share the information to
controller.
FN2.1_UC06
Auto announcement to in bus passenger
a) The system shall provide location based automatic announcements (Display and
Voice)
b) The system shall ensure high level of accuracy in location based features (less
than 1 meter).
c) The inner LED sign shall be able to display up to three languages, one after the
other in sequence.
d) The voice announcement shall be in synchronous to display.
e) Display and announcements shall be possible "before arrival" of the bus at the bus
stop, "on arrival" of the bus at bus stop and "after departure" of the bus from the
bus stop.
f) There shall be a provision for manual stop announcement in event of GPS failure.
FN2.1_UC07
Inner LED sign shall display driver ID and conductor ID once in between the stops
FN2.1_UC08
Inner LED sign shall display GPS based clock once in between stops
FN2.1_UC09
Driver/conductor announcement to in bus passenger
a) Inner LED sign shall have provision to display pre-recorded messages based on
driver selection. The pre-recorded messages can contain text with customized
graphics.
Draft AIS-140/D1
July 2016
Page 92 of 109
b) System shall have provision to interface with external Mic for in bus
announcement. Other announcement shall be on hold during announcements with
external mic.
FN2.1_UC10
Operator/STU announcement to in bus passenger
System shall have provision to display dynamic messages from control center on inner
LED sign. These messages can be advertisements or travel specific information.
FN2.1_UC11
Alert by the passenger(s)
System shall have provision to display customized graphics in case emergency stop
request button is operated.
FN2.1_UC12
System shall have provision to prioritize the announcements based on criticality of the
message.
FN2.2 Passenger Information – Outside Vehicle (At bus stops/depots)
Use Case ID Use Cases
FN2.2_UC01
ETA at bus stops
a) The system shall provide Expected Time of Arrival (ETA) in audio or visual
format or both. The system shall dynamically display updated ETA based on data
received from control center
b) The system shall display dynamic content (E.g. advertisements) received from
control center. System shall have provision to display dynamic messages from
control center at stops/depots. These messages can be advertisements or travel
specific information.
c) The system shall display current time.
d) ETA display shall have bus route number, Expected Time of Arrival in standard
format (font, size, style, lines etc.)
e) The display and formatting of display content shall be standardized
FN2.2_UC02
ETA at bus depots
a) The system shall provide Expected Time of Arrival (ETA) in audio or visual
format or both. The system shall have a provision to display departure time of
buses.
b) The system shall display dynamic content (E.g. advertisements) received from
control center
Draft AIS-140/D1
July 2016
Page 93 of 109
c) The system shall dynamically display updated ETA, departure time based on data
received from control center
d) ETA display shall have bus route number, Expected Time of Arrival in standard
format (font, size, style, lines etc…).
e) The display and formatting of display content shall be standardized
FN2.3 Passenger Information - On demand Information (via Personal computing
devices)
Use Case ID Use Cases
FN2.3_UC01
Get ETA over web/SMS
The system shall provide ETA information over SMS/Web based on request.
FN2.3_UC02
Get journey plan
a) The system shall provide journey plan over SMS/Web based on request.
b) The system shall provide recommended travel plans for an origin/destination
input (With route switch points and fare information). Filtering based on transit
changes, shortest, fastest and cheapest options shall be provided. The system shall
integrate information from other public transport operations (Train, Metro, Tram
and others) and provide travel plan and fare for the origin/destination input.
c) The system shall recommend public transport route numbers to specified
destinations with latest fare details. Filtering options for transit changes, shortest,
fastest and cheapest route shall be provided. {ARAI: This point is covered above}
d) The system shall provide real time arrival/departure information, time table,
schedules, delays, travel time and fare information. The system shall integrate
information from other public transport operations (Train, Metro, Tram and
others) as part of multimodal integration.
FN2.3_UC03
Give feedback/rating/complaints
a) The system shall have a provision for logging complaints, ratings and grievances
(Social media linking shall be possible)
b) The system shall feature a single toll free helpline number for any travel specific
information request.
Draft AIS-140/D1
July 2016
Page 94 of 109
DFD - FN3. Manage Fare Collection
Figure 7: DFD - FN3. Manage Fare Collection
USE CASES - FN3. Manage Fare Collection
FN3.1 Fare Collection Management - In vehicle manual electronic ticketing
Use Case ID Use Cases
FN3.1_UC01
Configure handheld ticketing machine
a) The system shall have provision to configure and assign ticketing machines to
vehicles
b) The configuration shall have route, fare table, stage and other details
c) The configurations shall be centrally stored
d) The configurations shall be downloaded from central system and loaded to
ticketing machines.
FN3.1_UC02
Issue tickets
a) The system shall have provision to electronically issue tickets
b) The system shall have provision to start and end a trip
Draft AIS-140/D1
July 2016
Page 95 of 109
FN3.1_UC03
Download fare collection data
a) The system shall have provision to upload fare collection data instantly to control
center
OR
b) The system shall have provision to manually download fare collection data from
ticketing machine at the end of the trip/day and upload to control center.
c) In case of un-availability of control center connectivity, the system shall store the
data locally and push data when connectivity resumes.
d) The data upload format shall be standardized in both cases.
e) The vehicle controller with control center connectivity shall act as a gateway
between ticketing machine and control center for real time upload of fare
collection data.
FN3.2 Fare Collection Management - In vehicle automated ticketing (Smart card
based)
Use Case ID Use Cases
FN3.2_UC01
Configure automated ticketing machine
a) The system shall have provision to configure and assign ticketing machines to
vehicles
b) The configuration shall have route, fare table, stage and other details
c) The configurations shall be centrally stored
d) The configurations shall be uploaded to ticketing machines from control center.
FN3.2_UC02
Issue tickets
a) The vehicle controller with GPS shall share the location data to ticketing machine.
b) Ticketing machine shall validate smart cards, internally calculate fare and issue
ticket.
FN3.2_UC03 Recharge smart cards
The system shall have a provision to recharge smart card based tickets online.
FN3.2_UC03
Download fare collection data
a) The system shall have provision to upload fare collection data instantly to control
center
Draft AIS-140/D1
July 2016
Page 96 of 109
b) The vehicle controller with control center connectivity shall act as a gateway
between ticketing machine and control center for real time upload of fare
collection data.
c) In case of un-availability of control center connectivity, the system shall store the
data locally and push data when connectivity resumes.
DFD - FN4. Safety and Security
Figure 8: DFD - FN4. Safety and Security
Draft AIS-140/D1
July 2016
Page 97 of 109
USE CASES - FN4. Safety and Security
FN4.1 Emergency Request
Use Case ID Use Cases
FN4.1_UC01
Emergency Request
a) The system shall have provision with which passengers shall make an emergency
request to control center.
b) Emergency button/s shall be provided in-side the vehicle.
FN4.2 Safety and Security - In vehicle video surveillance and recording
Use Case ID Use Cases
FN4.2_UC01
In vehicle video surveillance and recording
a) The system shall provide in-vehicle video surveillance and recording
b) The system shall record video files in standard format.
c) The system shall have provision to accept external inputs/trigger.
d) The system shall have built in clock and date/time shall overlay on video
e) The system shall have standard external connectivity options to share data with
other controllers
f) The system shall hold minimum 48 hours of video at any point in time. The
video files shall be overwritten if the memory is fully utilized.
g) The system shall have provision to record video at preselected resolution and
FPS.
h) The system shall have provision to record video at higher resolution and FPS
under emergency condition.
i) The system shall have a provision to make alert/panic message to control center
from the vehicle under emergency condition.
j) The system shall have provision to detect camera disconnection.
k) Video recording shall be possible with following options
a. CIF (352X288 ) up to 25 fps maximum each of 4 channel
b. DI (704X576) up to 12 fps maximum each of 4 channels
c. D1 (704X576) up to 25 fps maximum -one channels only
Draft AIS-140/D1
July 2016
Page 98 of 109
FN4.2_UC02
In vehicle snap shots on request
a) The system shall have provision to send snap shots to control center based on
request.
FN4.2_UC03
Video download
b) The system shall have provision to transfer the recorded video files via SD card,
USB or Wi-Fi.
c) The system shall have provision to authenticate Video file downloads.
FN4.2_UC04
Store and view video files at control center
a) The system shall have a provision to store/organize the video files centrally.
b) Video files shall be played with standard video players
FN4.3 Safety and Security - Reversing assistance
Use Case ID Use Cases
FN4.3_UC01
Reversing Assistance
c) The system shall have provision to assist driver during reversing the vehicle.
d) The system shall provide video from reverse camera when reverse gear is engaged.
Draft AIS-140/D1
July 2016
Page 99 of 109
3.5 Physical Architecture The physical architecture is a physical representation of the important ITS interfaces and major
system components. It defines and describes how the functionality created in the Logical
Architecture can be grouped to form Systems that can be produced. The principal elements in the
physical architecture are entities and architecture flows that connect these entities into an overall
structure.
The physical architecture assigns processes from the logical architecture to subsystems, and
groups data flows from the logical architecture into architecture flows. These flows and the
corresponding communication requirements define the interfaces.
Figure 9: Physical Architecture
Draft AIS-140/D1
July 2016
Page 100 of 109
Public Transport Vehicles
Figure 10: Public Transport Vehicles
The sub system handles primary source of data for all ITS services provided by the control center.
It manages interfaces and communication with the vehicle sub systems and the control center. The
vehicle sub systems provide real time operational data to control center, receives operational
commands from control center, delivers transit related information to passengers and delivers
safety and security services to passengers and crews. In public transport operational context, there
are twotypes of vehicle operation and the ITS service needs are different for them
Intra City - Vehicles operate within the city in fixed and dynamic routes; short distance operation
Intercity – Vehicles operate between two cities; long distance operation.
In-vehicle Architecture
Public Transport Vehicles can exhibit differing physical architectures within vehicle types or
brands within an operator. The logical entities perform different business functions within the
vehicle such as vehicle location tracking, emergency request management, vehicle health
monitoring, security camera surveillance and recording etc… The different logical entities with in
a vehicle shall communicate each other depending on the function requirements. Also the logical
entities shall communicate with external business functions (such as a backend control center). All
these communications shall be in standard format.
The logical entities shall be highly distributed into separate physical components or
The logical entities shall be grouped and partially distributed into separate physical
components or
The logical entities shall be a highly integrated package where more logical entities are
consolidated into the Vehicle Logic Unit.
Draft AIS-140/D1
July 2016
Page 101 of 109
The following figures represent the above mentioned alternatives and not represent all possible
permutations of the in-vehicle physical architecture.
Figure 11: Highly distributed architecture
Figure 12: Partially distributed architecture
Draft AIS-140/D1
July 2016
Page 102 of 109
Figure 13: Highly integrated architecture
Given below typical in-vehicle physical subsystems with multiple levels of ITS system complexity
based on end user needs. The level complexity is representational only; it can be further extended
or classified based on the user needs.
An operator opt for level 1 ITS functions shall adapt a TYPE 1 device which supports location
tracking and vehicle performance/health monitoring capabilities. The TYPE 1 device shall be used
in all types of vehicles – Buses, Trucks, Passenger cars, Three Wheelers etc....
Control Center
Figure 14: Control Center
The control center modules manage various control center functions to deliver the intended ITS
services to the end users (passengers and operators).
Draft AIS-140/D1
July 2016
Page 103 of 109
Manage Communication – The module manages data communications from the vehicle
controller (s) to control center.
Manage Database/Data – The module is responsible for managing static and dynamic data of the
complete system with backup and recovery mechanisms.
Manage Maps – The module manages map data and custom data layers required for various ITS
functions. It is often connected to the map provider for periodic updates.
Manage Vehicle Tracking and Operations – The module manages primary applications -
vehicle tracking and public transport operations.
Manage Passenger Information - The module co-ordinates generation of real time passenger
information based on live transit data from vehicles, dynamic operational data, information from
other authorities etc… and delivers the information to the passengers in user friendly formats.
Manage Ticketing - The module manages electronic ticketing machines and segregates the fare
collection in multiple ways to support operations.
Manage Online Booking - The module delivers online seat reservation services to the passengers.
The module is applicable for intercity transport management.
The system shall accommodate more and more modules as the user needs and transportation
management demands are growing.
Field Infrastructure
Figure 15: Field Infrastructure
The field infrastructure subsystem handles information management in the field with pre-defined
interfaces with control center.
Draft AIS-140/D1
July 2016
Page 104 of 109
Bus Stop Signs - Provides dynamic information (ETA, Delays etc…) to passengers at bus stops
driven by control center.
Bus Depot Signs - Provides dynamic information (ETA, Departure Information etc…) to
passengers at bus depots driven by control center.
Passengers
Figure 16: Passengers
Passenger sub-system represents the information delivery platform intended for the public
transport users provided by the operators. The various systems through which transit information
is delivered may be fixed (Like LED display boards) or portable (Cellular Phones / Tablets).
E-Services - Provides request/response based passenger information in computers and personal
computing devices, accessible from anywhere at any time.
Information Access – Passengers, Public and other transport authorities are provided access to
static and dynamic transit operation related information (Time tables, Schedules etc…) published
by public transport authority.
External Systems
Draft AIS-140/D1
July 2016
Page 105 of 109
Figure 17: External Systems
External systems provide services such as payment gateways, maps and passenger Information to
control center to deliver specific functions to the end users. Also control center shares data with
external systems/authorities for multimodal integration, city traffic planning etc.
3.6 Communication Architecture The Communication Architecture defines and describes what kind of communication links needs
to be used in a system in order to support its physical data flows. It provides an analysis of the
communication requirements for several of the “Example Systems” from the Physical
Architecture, and describes current communication technologies and standards.
Draft AIS-140/D1
July 2016
Page 106 of 109
Figure 18: Communication Architecture
Various Communications:
In-vehicle
The ITS sub systems (E.g. Automatic Vehicle Location Tracker) obtain vehicle
performance and diagnostics information from vehicle ECUs via standard CAN interface
over SAE Standards J1939
Draft AIS-140/D1
July 2016
Page 107 of 109
(E.g. AVL system obtains Engine RPM from Engine ECU via standard CAN interface
based on SAE J1939)
Various ITS sub systems within the vehicle use Ethernet for exchanging information.
(E.g. DVR - Digital Video recorder - system sends images/video to AVL system via
standard Ethernet interface based on IP protocol)
Sub system/Sub component of ITS sub systems within the vehicle use standard protocols
such as RS232, RS485 and USB for exchanging information.
(E.g. LED Destination board controller sends data to the LED boards via RS485)
Vehicle to Centers/Field
Wide Area (Mobile) Communications network – In-vehicle subsystems use public
networks (e.g. GSM/GPRS) for external communications/data exchanges.
(E.g. AVL system sends periodic data and alerts to a control center via Mobile network –
GSM/GPRS based on IP protocol)
Wireless LAN – In-vehicle subsystems use Standard commercial wireless LANs (802.11)
to communicate on a broadband basis with field (Control centers), portable and/or mobile
devices.
(E.g. DVR - Digital Video recorder - system sends images/video to a control center via
wireless LAN based on IP protocol)
Centers to Centers
The Center data network - “Center’s Fixed Point to Fixed Point Communications”. The
various business sub systems in center communicates with each other via Local Area
Network based Internet Protocols, Ethernet etc.
(E.g. Manage Passenger Information module obtains current location of vehicles rom
Manage Vehicle Tracking via Internet Protocols, Ethernet)
Control Center Communications with external entities – Control centers exchange
information with other control centers or other external authorities via Internet, Extranet,
or Other Fixed Point to Fixed Point Communications
(E.g. Manage Passenger Information module obtains time table/schedule of vehicles
managed by other centers via Internet, Extranet, or Other Fixed Point to Fixed Point
Communications)
Draft AIS-140/D1
July 2016
Page 108 of 109
APPENDIX -4
Document Type Sl. No. Document
Hardware and Software
Standards/Specifications
1 Controller (s)
2 LED signs - In vehicle
(Standard - Draft TED 11(921)P )
3 LED signs - Bus Stops
4 LED signs - Bus Depots
5 DVR - Digital Video Recorder
6 Ticketing Machines – Architecture
(TED 11(927)/ISO 24014-1:2007)
7 Ticketing Machines - Specifications
8 Smart Cards
9 Reversing Assistance System
10 Speakers (Hardware)
11 MIC (Hardware)
12 ITS Applications - Control center (Software)
Communication/Interface
Standards (Physical
Layer and Application
Layer)
13 Controller (s) - Control Center
14 Controller (s) - Vehicle ECUs
15 Controller (s) - LED Signs
16 Controller (s) - Ticketing Machines
17 Controller (s) - Host PC
18 Controller (s) - DVR
19 Ticketing Machines - Host PC
20 DVR - Control Center (Wireless)
21 DVR - Host PC
22 Control Center - LED Signs (Bus Stops)
23 Control Center - LED Signs (Bus Depot)
24 Host PC - LED Signs (Depot)
25 ITS Vehicle Interface Standard (Power/Signals)
26 ITS Service APIs - Control Center (Software/Protocol)
Algorithm Standards 27 ETA - Expected Time Of Arrival
28 Next Stop Announcement
29 Driver Scoring
Configuration Standards 30 PIS Configuration
31 DVR Configuration
Draft AIS-140/D1
July 2016
Page 109 of 109
32 Ticketing Machine Configuration
33 LED Boards Configuration (Bus Depot and Bus Stop)
34 Controller (s) Configuration
Server Side
Specifications
35 Server Hardware
36 Software (OS, Frameworks, Licensed Software/s,
Runtimes)
37 Networking Hardware
38 Storage Systems
39 Call Center