Intelligent Transportation Systems (ITS) - Requirements ... · part i: intelligent transportation systems (its) - requirements for ... 3.1 automatic vehicle location tracking and

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



3.1 AUTOMATIC VEHICLE LOCATION TRACKING 22


Part III: INTELLIGENT TRANSPORTATION SYSTEMS (ITS) – REQUIREMENTS FOR

PUBLIC TRANSPORT VEHICLE OPERATION (AUTO RICKSHAW)

1.0 DEFINITIONS 25



3.1 AUTOMATIC VEHICLE LOCATION TRACKING 26


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



TRANSPORT(PASSENGER CAR) To be added



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


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.


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.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


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


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.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.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.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


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.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.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



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.


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.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.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


These requirements are not applicable if ticketing machine is portable / handheld.


The system shall meet the requirements as National Common Mobility Card, Minimum

Standards & Specification Document For Card And Devices – Moud


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.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


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.


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,


or,


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


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)




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



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




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



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.11


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


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


memory.


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


dedicated system/device).



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.


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.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


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.


Emergency button shall be one time press type. Separate release action shall be required to



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.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


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.


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,


or,


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.


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)




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



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




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



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.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


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


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.


memory.


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



Connector for Power:

Connector requirements shall be as per Annexure – H, Clause 1.1 Minimum connector

requirements, Sl No 1 (Low Power System 1)


The system shall be mounted in such a way that it is not easily accessible to passengers or

driver without using special tool.


System shall meet the applicable testing requirements given in Annexure – F.

3.2 Emergency Request


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


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.


Emergency button shall be one time press type. Separate release action shall be required to



Emergency button shall be mounted inside passenger compartment of Auto-Rickshaw easily

accessible to passengers.


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


8. Driver Announcement System (Mic , Amplifier, Speaker)

a. Make

b. Model

c. Part No


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:


Block-1


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


10 - data bytes

Block-3


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


11 - data bytes

Block-3


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:


Block-1


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


Block-1


7 data bytes

Block-3


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:


Block-1


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


Block-1


N- data bytes

Block-3


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:


Draft AIS-140/D1

July 2016

Page 40 of 109

Block-1


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


10 - data bytes

Block-3


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


Response from LED sign for message displayed

Block-1


11 - data bytes

Block-3


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:


Block-1


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


Draft AIS-140/D1

July 2016

Page 41 of 109



Table 8: data code for LED intensity level setting


Block-1


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:


Block-1


no data byte

Block-3


Block-1


3 data bytes

Block-3


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


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


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


Speed NA NA NA NA


Speed

Battery

Voltage NA NA NA


Speed

Battery

Voltage NA NA NA


Speed

Battery

Voltage NA NA NA

Draft AIS-140/D1

July 2016

Page 47 of 109


Speed

Int

Battery

Voltage

NA NA NA


Speed

Int

Battery

Voltage

NA NA NA


Speed Direction

Cell

ID

Location

Area Code NA


Speed Direction

Cell

ID

Location

Area Code NA


Speed Direction

Cell

ID

Location

Area Code NA


Speed

Battery

Voltage NA NA NA


Speed

Battery

Voltage NA NA NA


Speed

Battery

Voltage NA NA NA


Speed

Source

ECU

SPN

FMI

Occurrence

Count NA


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.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


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.


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


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





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





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


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


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




15 Microphone 1 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


High Power System 1


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


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


(ETA) in audio and/or visual format Passenger Information Intra City

1.1.1.12



modes (metro, flight, tram and others) , in case of

multimodal transportation

Passenger Information Intra City

1.1.1.13



format across all stops/shelters/operators.


At Depots



(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



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,


in audio and/or visual format.


City/Inter City

1.1.1.18



format across all types of operators/depots/stations.


City/Inter City

SMS, Web (Mobile/Tablet/Laptop/PC)



(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,


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


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.


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


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


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)


City

1.1.1.29 The system shall have a provision to recharge smart

card based tickets online.

Fare Collection


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


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


1.1.2.3

The system shall have provision for electronically

configuring new routes by physically accessing the

vehicle and/or over wireless


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


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.


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


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


2.3 The List of Needs of In-vehicle Crew


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


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


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.


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


1.1.6.1 The system shall provide location based services (E.g.

Track and Trace)

Operations


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


2.7 The List of Needs of Other Transport Operators / Authorities


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


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


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)


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


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


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


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


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)


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)


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)


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


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)


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


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


FN4.2_UC01


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


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

Documents

Intelligent Transportation Systems (ITS) - Requirements ... · part i: intelligent transportation systems (its) - requirements for ... 3.1 automatic vehicle location tracking and