INTELLIGENT TRANSPORT SYSTEMS IN PUBLIC BUS SERVICES
Imprint
Published by the Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH
Registered offices
Bonn and Eschborn, Germany
B-5/2, Safdarjung Enclave
New Delhi-110029, India
T 011-49495353
F 011-49495391
E giz-indien@giz.de
As at June 2026, New Delhi
Prepared under Sustainable Urban Mobility – Air Quality, Climate Action and Accessibility (SUM-ACA)
Commissioned by Federal Ministry for Economic Cooperation and Development (BMZ), Germany
Political Partner Ministry of Housing and Urban Affairs (MoHUA), Government of India
Implementation Partners Ministry of Housing and Urban Affairs (MoHUA), Government of India
Responsible
Manjunath Sekhar - Project Director, SUM-ACA
Project Coordinator
Rana Amani, Technical Advisor, GIZ
Krishna Desai, Technical advisor, GIZ
Zohra Mutabanna, Team Lead, GFA Consulting Group GmbH
Project Team
Ravi Gadepalli, Transit Intelligence
Dibyaranjan jena , independent Consultant (ITS)
Parajwal Gudadoor, Transit intelligence
Photo and Map Credits
GIZ; Transit Intelligence
Citation GIZ (2026).
Model Request for Proposal (RFP): Intelligent Transport Systems in Public Bus Services. SUM-ACA. New Delhi, India.
Disclaimer
Maps in this document are for informational purposes only and do not imply recognition of boundaries or regions. GIZ does not guarantee their accuracy or completeness and accepts no liability arising from their use.
GIZ is responsible for the content of this publication. On behalf of the German Federal Ministry for Economic Cooperation and Development (BMZ)
Copyright
All rights reserved.
MODEL REQUEST FOR PROPOSAL (RFP):
INTELLIGENT TRANSPORT SYSTEMS IN PUBLIC BUS SERVICES
Summary
This document provides a ready reference for key specifications to be included in ‘Intelligent Transport Systems’ (ITS) Request for Proposals (RfP) to be taken up by Public Transport Authorities (PTAs). The model RfP specifications have been prepared as a part of the SUMACA project of GIZ by Transit Intelligence LLP. The specifications included in this document build upon the recommendations on ‘Futureproofing ITS systems in India’ developed under SUMACA and converts the key recommendations of the report into procurement specifications. This model RfP is accompanied by a guidance document that assists PTAs in outlining the key requirements of the RfP before developing the full specifications.
The Model RfP is designed to:
• Provide clear and structured technical specifications
• Promote standardization across ITS procurements
• Reduce ambiguity in bidding documents
• Encourage future-ready and interoperable systems
• Minimize risks of vendor lock-in
• Improve transparency and comparability of bids
The recommendations provided in this RfP are based on the prevailing ITS technologies and requirements in February 2026. Given the constantly evolving technology landscape, users are advised to evaluate their relevance at the time of issuance of their RfP.
However, ITS technologies evolve rapidly due to advancements in:
• AI-based analytics
• IoT devices
• 5G connectivity
• Cloud infrastructure
• Cybersecurity protocols
• Integrated mobility platforms
Therefore, PTAs are advised to review and update the specifications before issuing their RfP, ensuring alignment with:
• Latest standards
• National transport policies
• Security norms
• Emerging integration requirements
The Model RfP provides a structured, expert-backed foundation for procuring Intelligent Transport Systems in a scalable, interoperable, and future-proof manner.
Its adoption will strengthen governance, reduce technology risk, and support long-term digital transformation of public transport operations.
1. INTRODUCTION
1.1 About Public Transport Authority
(About Public Transport Authority)
1.2 Objectives of the Authority under the current program (Objectives)
2. INSTRUCTIONS
TO BIDDERS
2.1 General
(1) While every effort has been made to provide comprehensive and accurate background information and requirements and specifications, Bidders must form their own conclusions about the solution needed to meet the requirements. Bidders and recipients of this RFP may wish to consult their own advisers in relation to this RFP.
(2) All information supplied by Bidders may be treated as contractually binding on the Bidders, on successful award of the assignment by the PUBLIC TRANSPORT AUTHORITY on the basis of this RFP.
(3) No commitment of any kind, contractual or otherwise shall exist unless and until a formal written contract has been executed by or on behalf of the PUBLIC TRANSPORT AUTHORITY. Any notification of preferred Bidder status by the PUBLIC TRANSPORT AUTHORITY shall not give rise to any enforceable rights by the Bidder. The PUBLIC TRANSPORT AUTHORITY may cancel this public procurement at any time prior to a formal written contract being executed by or on behalf of the PUBLIC TRANSPORT AUTHORITY.
2.2 Completeness of Response/Proposal
(1) Bidders are advised to study all instructions, forms, terms, requirements, and other information in the RFP documents carefully. Submission of the bid shall be deemed to have been done after careful study and examination of the RFP document with full understanding of its implications.
(2) Failure to comply with the requirements of this paragraph may render the Proposal noncompliant and the Proposal may be rejected. Bidders must:
• Include all documents as specified in this RFP,
• Follow the format of this RFP and respond to each element in the order as set out in this RFP, and
• Comply with all requirements as set out within this RFP.
2.3 Code of Integrity
(1) No official of a procuring entity or a bidder shall act in contravention of the codes which include:
a. Prohibition of
i. Making offer, solicitation or acceptance of bribes, reward or gift or any material benefit, either directly or indirectly, in exchange for an unfair advantage in the procurement process or to otherwise influence the procurement process.
ii. Any omission, or misrepresentation that may mislead or attempt to mislead so that financial or other benefit may be obtained, or an obligation avoided.
iii. Any collusion, bid rigging or anticompetitive behavior that may impair the transparency, fairness and the progress of the procurement process.
iv. Improper use of information provided by the procuring entity to the bidder with an intent to gain unfair advantage in the procurement process or for personal gain.
b. Disclosure of conflict of interest.
c. Disclosure by the bidder of any previous transgressions made in respect of the provisions of sub-clause (a) with any entity in any country during the last three years or of being debarred by any other procuring entity.
(2) In case of any reported violations, the procuring entity, after giving a reasonable opportunity of being heard, concludes that a bidder or prospective bidder has contravened the code of integrity, may take appropriate measures.
2.4 Pre-bid Meeting and Clarifications
Pre-bid Conference
(1) PUBLIC TRANSPORT AUTHORITY shall organize a pre-bid meeting with the prospective Bidders on date, time and venue as specified in the Factsheet.
(2) The Bidders will have to ensure that their queries for pre-bid meetings should reach to PUBLIC TRANSPORT AUTHORITY by email on or before date and time as specified in the Factsheet.
(3) The queries should be submitted in the following format:
(4) PUBLIC TRANSPORT AUTHORITY shall not be responsible for ensuring that the Bidders’ queries have been received by them. Any requests for clarifications post the indicated date and time may not be entertained by the PUBLIC TRANSPORT AUTHORITY.
Responses to Pre-bid Queries and Issue of Corrigendum
(1) PUBLIC TRANSPORT AUTHORITY will endeavor to provide timely response to all queries. However, PUBLIC TRANSPORT AUTHORITY makes no representation or warranty as to the completeness or accuracy of any response made in good faith, nor does PUBLIC TRANSPORT AUTHORITY undertake to answer all the queries that have been posed by the Bidders.
(2) At any time prior to the last date for receipt of bids, PUBLIC TRANSPORT AUTHORITY may, for any reason, whether at its own initiative or in response to a clarification requested by a prospective Bidder, modify the RFP Document by a corrigendum.
(3) The corrigendum (if any) & clarifications regarding the queries from all Bidders will be posted on the e-procurement portal (as specified in the Factsheet) and may be emailed to all participants at the pre-bid conference.
(4) Any such corrigendum shall be deemed to be incorporated into this RFP.
(5) In order to provide prospective Bidders with a reasonable time for taking the corrigendum into account, the PUBLIC TRANSPORT AUTHORITY may, at its discretion, extend the last date for the receipt of Proposals.
2.5 Key Instructions of the bid
Right to Terminate the Process
(1) PUBLIC TRANSPORT AUTHORITY may terminate the RFP process at any time and without assigning any reason. PUBLIC TRANSPORT AUTHORITY makes no commitments, express or implied that this process will result in a business transaction with anyone.
(2) This RFP does not constitute an offer by the PUBLIC TRANSPORT AUTHORITY. The Bidder's participation in this process may result in the PUBLIC TRANSPORT AUTHORITY selecting the Bidder to engage towards execution of the subsequent contract.
RFP Document Fees
(1) The RFP documents have been made available for download without any fee from the eprocurement portal as specified in the fact sheet.
(2) The demand draft of RFP document fees (if any, as mentioned in the Fact Sheet) should be submitted along with the bidder’s proposal. Proposals received without or with inadequate RFP Document fees shall be rejected.
Earnest Money Deposit / Bid Security
(1) Bidders shall submit, along with their Proposals, an EMD of Rs. 6,00,00,000 (Rupees Six Crores) only, in the form of a demand draft OR Bankers Cheque OR bank guarantee OR and electronic Bank Guarantee under Structured Financial Messaging System (SFMS). The payment transfer related information is as follows:
a. EMD BG in the format specified in Form 3 issued by a commercial bank in favor of PUBLIC TRANSPORT AUTHORITY. The EMD BG should remain valid for a period of 45 days beyond the final tender validity period.
b. Demand Draft/Banker cheque: Payable <location/city>
c. Electronic Bank Guarantee under Structured Financial Messaging System (SFMS):
(2) EMD of all unsuccessful Bidders would be refunded by the PUBLIC TRANSPORT AUTHORITY within <time period> of the Bidder being notified as being unsuccessful. The EMD, for the amount mentioned above, of successful Bidder would be returned upon submission of Performance Bank Guarantee as per the format provided in Form 3.
(3) The EMD amount is interest free and will be refundable to the unsuccessful Bidders without any accrued interest in it.
(4) Proposals do not accompany with the EMD or containing EMD with infirmity(ies) (relating to the amount or validity period etc.), mentioned above, shall be summarily rejected.
(5) The EMD may be forfeited in the event of:
a. A Bidder withdraws its bid during the period of bid validity.
b. A successful Bidder fails to sign the subsequent contract in accordance with this RFP.
c. The Bidder being found to have indulged in any suppression of facts, furnishing of fraudulent statement, misconduct, or other dishonest or other ethically improper activity, in relation to this RFP.
d. A Proposal contains deviations (except when provided in conformity with the RFP) conditional offers and partial offers.
Inclusion of MSMEs in Project Delivery
(1) Bidders are encouraged to include Micro, Small & Medium Enterprises (MSMEs) in the delivery of the project by Subcontracting or Outsourcing a certain value of the total contract. The MSME partner should be registered under the Micro Small Medium Enterprise Act, 2006.
Submission of Proposals
(1) Bidders should submit their responses as per the procedure specified in the e-Procurement portal (as specified in the Factsheet) being used for this purpose. Generally, the items to be uploaded on the portal would include all the related documents mentioned in this RFP, such as:
a. Tender Fee
b. EMD
c. Response to Eligibility criteria
d. Response to Technical Evaluation criteria
e. Financial proposal
f. Additional certifications/documents such as - Power of Attorney, CA certificates on turnover, etc.
(2) However, each of the above documents must be uploaded in the format specified for this purpose and as per the specified folder structure in the e-Procurement portal.
(3) The bidder must ensure that the bid is digitally signed by the Authorized Signatory of the bidding firm and has been duly submitted within the submission timelines. The PUBLIC TRANSPORT AUTHORITY will in no case be responsible if the bid is not submitted online within the specified timelines.
(4) All the pages of the Proposal document must be sequentially numbered and must contain the list of contents with page numbers. Any deficiency in the documentation may result in the rejection of the Bidder’s Proposal.
Bidder’s Authorized Signatory
(1) A Proposal should be accompanied by an appropriate board resolution or power of attorney as per Form 9, in the name of an authorized signatory of the Bidder stating that he is authorized to execute documents and to undertake any activity associated with the Bidder’s Proposal.
(2) A copy of the same should be uploaded under the relevant section/folder on the eProcurement portal. Furthermore, the bid must also be submitted online after being digitally signed by an authorized representative of the bidding entity.
2.6 Preparation and Submission of Proposals
Proposal Preparation Cost
(1) The Bidder shall be responsible for all costs incurred in connection with participation in the RFP process, including, but not limited to, costs incurred in conduct of informative and other diligence activities, participation in meetings/discussions/presentations, preparation of proposal, in providing any additional information required by PUBLIC TRANSPORT AUTHORITY to facilitate the evaluation process, and in negotiating a definitive contract or all such activities related to the bid process.
(2) PUBLIC TRANSPORT AUTHORITY will in no event be responsible or liable for those costs, regardless of the conduct or outcome of the bidding process.
Language
(1) The Proposal should be filled by the Bidder in English language only. If any supporting documents submitted are in any language other than English, translation of the same in English language is to be duly attested by the Bidders. For purposes of Proposal evaluation, the English translation shall govern.
Submission Timelines
(1) The response to RFPs must be submitted on the eProcurement portal by the date and time specified for the RFP.
(2) Any proposal submitted on the portal after the above deadline will not be accepted and hence shall be automatically rejected. PUBLIC TRANSPORT AUTHORITY shall not be responsible for any delay in the submission of the document.
Proposals Submitted After Designated Time of Submission
(1) Bids submitted after the due date will not be accepted by the e-Procurement system and hence will automatically be rejected. The PUBLIC TRANSPORT AUTHORITY shall not be responsible for any delay in the online submission of the proposal.
2.7 Deviations
(1) The Bidders are expected to submit the bid without any deviations to scope of work, obligations, functional technical and integration requirements and all other terms and conditions specified in this RFP and subsequent corrigendum/addendum if any.
(2) Bidders are expected to submit declaration conforming to ‘Nil deviation’ as per Form 10.
2.8 Evaluation Process
(1) The PUBLIC TRANSPORT AUTHORITY will constitute a committee to evaluate the responses of the Bidders (Purchase Committee).
(2) The Evaluation Committee constituted by the PUBLIC TRANSPORT AUTHORITY shall evaluate the responses to the RFP and all supporting documents / documentary evidence. Inability of a Bidder to submit requisite supporting documents / documentary evidence within a reasonable time provided to it, may lead to the Bidder’s Proposal being declared nonresponsive.
(3) The decision of the Evaluation Committee in the evaluation of responses to the RFP shall be final. No correspondence will be entertained outside the process of negotiation/ discussion with the Evaluation Committee.
(4) The Evaluation Committee may ask for meetings with the Bidders to seek clarifications on their proposals.
(5) The Evaluation Committee reserves the right to reject any or all Proposals on the basis of any deviations contained in them.
(6) Each of the responses shall be evaluated as per the criteria and requirements specified in this RFP.
Proposal Opening
(1) The Proposals submitted up to <Time> on <Date> will be opened at <Time> on <Date, Time> by the Nodal Officer or any other officer authorized by the PUBLIC TRANSPORT AUTHORITY, in the presence of the Bidder’s representatives who may be present at the time of opening.
(2) The representatives of the Bidders are advised to carry an identity card or a letter of authority from the Bidding entity to identify their Bonafide for the opening of the Proposal.
Proposal Validity
(1) The offer submitted by the Bidders should be valid for 180 days from the date of submission of the Proposal.
Proposal Evaluation
(1) Initial Proposal scrutiny will be held to confirm that Proposals do not suffer from the infirmities detailed below. Proposals will be treated as non-responsive if a Proposal is found to have been:
a. submitted in manner not conforming with the manner specified in the RFP document.
b. submitted without appropriate EMD as prescribed herein.
c. received without the appropriate or power of attorney.
d. containing subjective/incomplete information.
e. submitted without the documents requested in the checklist.
f. non-compliant with any of the clauses stipulated in the RFP.
g. having less than the prescribed validity period.
(2) All responsive Bids will be considered for further processing as below.
(3) PUBLIC TRANSPORT AUTHORITY will prepare a list of responsive Bidders, who comply with all the Terms and Conditions of the Tender. All eligible bids will be considered for further evaluation by a committee according to the Evaluation process define in this RFP document. The decision of the Committee will be final in this regard.
3. SCOPE OF WORK
3.1 Objectives
(1) The Authority seeks to implement an Integrated Transit Management Solution comprising comprehensive technology suite to improve service reliability, passenger convenience, and operational efficiency through automation, data intelligence, and digital audit mechanisms. The Selected Bidder shall be responsible for end-to-end design, development, integration, operation and maintenance of the solution in accordance with this RFP.
(2) The Authority plans to implement a modern, comprehensive technology suite to achieve the following key objectives:
a. Provide ease and benefits to users by providing reliable services leading to increase in ridership and adoption of public transport.
b. Enhance digital tickets options for passengers; and
c. Provide efficient and effective management support services to improve the performance of bus operations.
d. Increase the total number of audits and efficiency of the overall audit process; and introduce data intelligence for conducting targeted audits at relevant buses and bus stops.
(3) The Selected Bidder shall be responsible for the design, development/ procurement, supply, integration, implementation, operations, and maintenance of both hardware & software) as per the Scope of Work outlined herein.
3.2 Fleet Size and Other details of TRANSPORT OPERATOR
3.3 Key Components for ITS
A brief description of the various ITS components is provided below while the details of each of the components and their functional specifications are defined in the ‘Software Requirements’ section (Chapter 17).
1
2
Automatic Fare Collection System
The Selected Bidder shall design, supply, install, integrate, operate and maintain an Automatic Fare Collection System (AFCS).
The AFCS shall inter alia include:
a. Onboard Electronic Ticket Issuing Machines (ETIMs) capable of accepting multiple payment modes including NCMC/closed smart card, Debit/Credit cards, QR code, UPI, digital wallet and cash. Devices shall operate in both online and offline modes with automatic synchronisation to the central server.
b. Central Clearing House System (CCHS) for fare reconciliation, settlement and MIS reporting. The backend shall expose open, documented APIs for integration with Passenger App, WhatsApp-based ticketing solution
c. Each fare transaction shall carry a unique identifier timestamp, and operator ID. Every configuration change to AFCS such as fare tables, route settings, user permissions, etc shall be logged in an immutable audit trail accessible to the Authority.
d. The AFCS shall conform to PCI-DSS, EMVco, and RBI PA/PG guidelines for financial transactions.
e. The Selected Bidder shall provide real-time dashboards for route-wise ridership analysis, revenue, and any incident reporting.
f. The AFCS backend shall maintain a minimum 99.5% uptime, and the Selected bidder shall ensure scalability for additional buses introduced during the contract period.
Automatic Vehicle Location System
a. The successful bidder shall supply GPS Devices with SIM/Data cards for enabling GPRS on the GPS Device for Vehicle Tracking. Monthly recurring charges for the same will be paid by supplies for Guarantee period of one year and later on Annual charge basis for further period of 4 years. GPRS devices are required to hold data for at least 60 days.
b. Monitoring Routes and Stoppages of state buses and keeping a record of the trip, they have made route wise and bus wise.
c. Web based application Software with hosting services, SMS gateway and Google maps.
d. The successful bidder shall provide off the shelf Web based Vehicle Tracking Software and customize the
S.No.
Key Component
3 Mobile Application
Description
same as per the requirements of transport operator to operate and maintain the GPS based Vehicle Tracking devices installed in transport vehicles across the state.
e. The successful bidder shall install the GPS devices in all the buses within the time frame set transport operator. The reports generated from system should be sufficient to calculate the performance of the entire system and penalties as prescribed.
f. It is assumed that the entire route of a vehicle is covered by GPS and leading mobile network. But there might be some parts of the route where there is no network coverage. So, the system must work in off-line mode too for these areas and will provide the data once the vehicle enters the GPRS zone.
g. The Bidder shall be responsible for updating and upgrading (if required) of all Software and Hardware for successful operation of the Project during the Contract Period. Transport operator would be eligible to demand free upgrades as and when they are launched within the contract period.
h. All data generated during the operation period shall be the property of transport operator. The vendor is also required to submit the data every two months in the form of soft and hard copy to transport operator.
i. All the supporting accessories and associated software monitoring dashboards will be provided by the bidder and apart from the quoted in the financial proposal, no other cost will be offered by transport operator thereafter.
a. The Selected Bidder shall design, develop, deploy, integrate and operate a Digital Tracking System along with a Passenger Mobile Application.
b. The mobile application shall adhere to the brand guidelines of the Authority with or without the cobranding of the Selected Bidder.
c. The system shall capture real-time vehicle location, route adherence, speed, and schedule compliance at intervals not exceeding 10 seconds. Data shall be presented to the Authority through an administrative dashboard and secure APIs.
d. The Passenger Mobile Application shall have features like live bus location, expected arrival time, ticket
S.No. Key Component
Description
purchase, pass purchase and renewal options, passenger feedback and grievance redressal etc. It shall be integrated with the AFCS backend for ticket validation and the Authority's payment gateway for secure UPI and card transactions.
e. The Selected Bidder shall ensure that the Passenger Mobile Application is designed and developed in accordance with universal accessibility principles, ensuring that differently abled persons can use all its features independently. The application shall comply with Guidelines for the Indian Government Website (GIGW 3.0) accessibility standards, as amended from time to time, ensuring support for screen readers, text scaling, colour contrast and non-visual navigation.
a. The Selected Bidder shall design, implement and operate a Smart Card Platform. The platform shall enable passengers to make seamless fare payments across transport operator services through all types of contactless cards that can be used across multiple modes of transport and payment networks in the future.
b. The Smart Card Platform shall include:
1. Card Management System (CMS) – for registration, activation, and lifecycle management of all cards issued under the Authority's scheme
f. The Passenger Mobile Application shall be made available in multiple languages, including English, Marathi and Konkani. 4 Smart Card Platform (NCMC/ Closed loop card)
2. Top-up and Recharge options through the Passenger-facing Mobile Application and designated physical counters
3. Integration with AFCS for automatic fare deduction, balance validation and transaction synchronisation with the central clearing system.
c. The Selected Bidder shall ensure compliance with RBI PA/PG guidelines, PCI-DSS standards, EMVco specifications, and provisions of DPDP Act, 2023.
d. The Selected Bidder shall be responsible for distribution management of Smart Cards.
e. The selected bidder shall ensure to integrate the existing smart cards in the system.
5
S.No.
Operator Dashboard and Analytics System
a. The Selected Bidder shall design, develop and maintain an Operator Dashboard for the Authority management, providing real-time insights and analytics on ridership, revenue, route performance, and system health.
b. The dashboard shall consolidate data from the AFCS, Digital Tracking System and Digital Audit system integrated analytical platform to support evidencebased decision making and operational planning.
c. The dashboard shall present key performance indicators such as ridership trends, route-wise occupancy, ticketing efficiency, punctuality and exception reports.
d. The dashboard shall allow authorised officials of the Authority to view customisable charts, export datasets, and generate daily, weekly and monthly performance summaries.
e. The dashboard shall also include a feature for publishing selected non-sensitive analytics such as ridership statistics on the official website of the Authority for public viewing through automated integration.
f. Access to the Operator Dashboard shall be rolebased, with user authentication and activity logging. All data processing and visualisation shall be hosted on MeitY- approved data centres located in India with a minimum uptime of 99.5 percent.
g. The Selected Bidder shall provide training to the Authority's management and technical staff in the use of the dashboard and ensure continuous technical support during the contract period.
h. Billing Reports enable automated generation of comprehensive financial reports, including revenue summaries, operator-wise earnings, route-wise collections, transaction details, and settlement statements.
i. The system provides real-time and period-based reporting (daily, weekly, monthly, custom range) with filters for depot, route, vehicle, conductor, payment mode, and ticket type.
j. Integrated analytics offer visual dashboards, reconciliation support, GST/tax computation (if applicable), and export options (PDF/Excel) to
S.No. Key Component
8.
Description
support financial monitoring, audit compliance, and management decision-making.
k. Selected Bidder can generate billing and SLA reports.
a. Incident Management is a coordinated, multi-agency and multi-jurisdictional approach to handle disruptions, aimed at reducing impacts on public safety, traffic flow, and the local economy through faster response and clearance times.
b. It is a planned and resource-optimized process leveraging AVLS and Command & Control platforms to detect, monitor, and manage incidents efficiently with involvement from multiple stakeholders.
c. The core incident management process includes: Detection, Verification, Motorist Information, Response, Site Management/Action, Traffic Management, and Clearance.
d. The system operates through four key operational phases: Notification, Response, Recovery, and Restoration.
e. The Incident Management System functions as part of an integrated Emergency Response and Alert/Event Management framework, ensuring coordinated communication and effective incident resolution.
The objective of the Contract Management Solution (CMS) is to facilitate efficient and transparent management of contracts of the PUBLIC TRANSPORT AUTHORITY, ensuring compliance with contractual obligations and enhancing communication and collaboration between cities, bus operators, and overseeing authorities. The CMS aims to provide streamlined processes related to contract creation/configuration, performance monitoring, invoice generation, and payment processing, ultimately contributing to the successful implementation and operation of the scheme while promoting accountability and effective utilization of resources.
a. Automates complete depot operations, including workshop, fuel, traffic, vehicle management, administrative functions, and stores/inventory management.
b. Enables centralized vehicle and staff management, covering vehicle details, manufacturing data, depot
6. Incident Management System
7. Contract Management System
Depot Management System
S.No. Key
Component
9. Maintenance and Technical Support Services
Description
configuration, user roles, and crew/staff records (employee code, role, contact and personal information).
c. Provides an integrated and seamlessly connected depot management system, ensuring all modules and sub-modules function cohesively for efficient operations.
a. The Selected Bidder shall be responsible for providing comprehensive Maintenance and Technical Support of integrated Services for all hardware, software and systems implemented under this project throughout the Term.
b. These services shall inter alia include:
1. Preventive maintenance such as period inspection, calibration and testing of all hardware components, network devices and communication links at intervals not exceeding 90 days.
2. Timely repair or replacement of defective components, restoration of services and resolution of software or network issues as per the service levels defined below.
3. Regular software updates, security patches, and version upgrades to maintain functionality, interoperability and compliance with evolving standards.
4. A centralised helpdesk to record, track and resolve complaints. On-demand technical support shall be available during Business Support Hours, with escalation mechanisms for critical failures.
5. The Selected Bidder shall ensure a minimum system uptime of 99 percent across all digital components. The following Service Level Targets shall apply:
i. Critical issues (system downtime, payment failure): Response withing 1 hours, resolution within 4 hours
ii. Maintenance issues (module malfunction, device fault): Response within 4 hours, resolution within 24 hours.
S.No. Key Component
Data Hosting, Security and Privacy Compliance
Description
iii. Minor issues (UI errors, data inconsistencies): Response within 24 hours, resolution within 72 hours.
c. The Bidder shall maintain a log of all maintenance activities, accessible to the Authority and furnish monthly performance and downtime reports. Preventive and corrective maintenance schedules shall be shared with the Authority in advance.
d. All spare parts, consumables and replacement devices required for maintenance shall be supplied by the Selected Bidder at no additional cost to the Authority during the Term.
a. The Selected Bidder shall be responsible for ensuring the secure hosting, transmission and management of all data generated under the Integrated Smart Transport Solution, including but not limited to transaction, data, passenger data, video footage and system logs.
b. All data generated during the implementation operation of the ISTS shall be hosted on MeitY-India, located within data centres approved of Information to the requirements conforming Personal Data 2000, Digital Technology Act, the notifications issued and relevant Protection Act, 2023 thereunder.
c. All data generated, processed, or stored under this and primary, derived, analytical project, including metadata, shall be the exclusive and perpetual property of the Authority. The Selected Bidder, its employees or affiliates shall not share, transfer, disclose, sell or otherwise use any data with or to any third party without the prior written consent of the Authority.
d. All data centres used for hosting data under this project shall comply with ISO/IEC 270001:2013 and maintain firewalls, intrusion detection, and continuous threat monitoring.
e. Personally identifiable information (PII) and financial data shall be encrypted both at rest and in transit (AES-256/TLS 1.2 or higher). Access shall be controlled through role-based permissions and multi-factor authentication.
f. All web, mobile, and API interfaces shall undergo annual VAPT by a CERT-in empanelled auditor.
S.No. Key Component
11. Training, Capacity Building and Knowledge Transfer
12. Manpower Support
Description
g. The Selected Bidder shall maintain an off-site disaster recovery facility with real-time replication and data resolution capability within 24 hours of any incident and restoration within 72 hours.
h. The Selected Bidder shall maintain an off-site disaster recovery facility with real-time replication and data resolution capability within 24 hours of any incident and restoration within 72 hours.
i. The Authority reserves the right to inspect and audit any data centre, process or log system used in this project. The Selected Bidder shall fully cooperate with such audits and furnish required access or documentation on demand.
j. In the event of any data breach, unauthorised access or cyber incident, the Bidder shall notify the Authority within two hours of detection, followed by a detailed incident report and remedial actions taken within 24 hours.
a. The Selected Bidder shall conduct comprehensive Training and Capacity Building programmes for the Authority's operational, technical and administrative personnel to ensure effective operation, monitoring and management of all systems implemented under the ITS.
b. All training sessions shall include hands-on demonstration supported by printed reference materials and digital manuals in English and local language. The Selected Bidder shall provide refresher training every six months during the first two years of the Term and whenever new modules or upgrades are introduced.
c. Before the closure of the contract, the Selected Bidder shall carry out Knowledge Transfer sessions for the Authority's designated personnel.
a. The Selected Bidder shall provide all necessary manpower for day-to-day operations, management, maintenance of the total ITS deployed during the Agreement period.
b. The manpower requirement, qualification, experience and skill set are defined in Annexure: Manpower Requirement, Experience, Qualification & Skill Sets
The Selected Bidder shall be responsible for providing SIM cards and internet connectivity for smooth functioning of the deployed system.
The Selected Bidder shall be responsible for the maintenance of all hardware and software components during the Term of the Agreement. 15. Integration with Existing IT Systems
The Selected Bidder shall be responsible for integrating with the existing IT systems/ Smart transit cards of the Authority. Maintenance of pre-fitted ITS components in new buses as per UBS II or applicable norms will also be the responsibility of the Selected Bidder including SLAs.
4. BIDDER ELIGIBILITY CRITERIA:
TURNOVER, EXPERIENCE:
4.1 Financial Eligibility (Turnover)
(1) The bidder should be a registered legal entity (Company / LLP / Partnership / Proprietorship).
(2) The bidder must have a minimum average annual turnover of ₹ ___ Crores during the last three financial years (FY ___, FY ___, FY ___).
(3) Turnover should be derived from IT/ITS/Smart Mobility/Transport Technology solutions.
(4) Audited financial statements duly certified by a Chartered Accountant shall be submitted.
4.2 Technical Experience & Past Performance
Core ITS Experience
(1) The bidder must have successfully implemented Integrated Transport Management System (ITS) or similar large-scale transport technology projects.
(2) Experience should include end-to-end implementation, such as:
a. Automatic Fare Collection System (AFCS)
b. Vehicle Tracking System (GPS/AVLS)
c. Passenger Information System (PIS)
d. Mobile Ticketing
e. Scheduling, Depot Management, or Operations Monitoring
Project Value & Scale
(1) At least one project of value not less than ₹ ___ Crores, OR
(2) At least two projects each of value not less than ₹ ___ Crores
(3) Projects should have been implemented for:
a. State Transport Undertakings (STUs), OR
b. Urban Local Bodies (ULBs), OR
c. Government / PSU / Smart City SPVs
Operational Track Record
(1) Implemented ITS solution should be operational for a minimum of ___ months/years prior to bid submission.
(2) Proof of completion / Go-Live / operational acceptance required.
4.3 Specific Domain Capabilities (Desirable / Mandatory)
(1) Experience in public transport systems.
(2) Integration experience with:
a. Ticketing systems (ETIM / AFC / NCMC / QR / Mobile Ticketing)
b. Payment gateways / banks
c. Mobile applications & web portals
(3) Experience with real-time dashboards, analytics, and reporting.
4.4 Compliance & Legal Eligibility
(1) Bidder should not be blacklisted by any Government / PSU / Autonomous Body.
(2) Bidder should have:
a. Valid GST registration
b. PAN
c. Statutory compliance with labour and tax laws
(3) Self-declaration / affidavit to be submitted.
4.5 Supporting Documents
(1) Audited financial statements
(2) Work orders / completion certificates
(3) Client reference letters
(4) Self-declarations and affidavits as per annexure
5. CONSORTIUMS / JOINT VENTURE (JV) AND SUBCONTRACTING
5.1 Consortium / Joint Venture (JV)
(1) Bidders may participate either as a single entity or as a Consortium / Joint Venture (JV).
(2) A Consortium/JV shall consist of maximum ___ members (including the Lead Member).
(3) One member shall be designated as the Lead Member, who shall:
a. Be responsible for overall project delivery, coordination, and contractual obligations.
b. Hold at least ___% equity/participation in the consortium/JV.
c. Meet minimum turnover and core ITS experience criteria on its own.
(4) The Consortium/JV shall submit:
a. A legally binding Consortium / JV Agreement
b. Roles & responsibilities matrix for each member
c. An Authorization Letter nominating the Lead Member
(5) Consortium/JV members shall be jointly and severally liable for the project.
5.2 Subcontracting
(1) Subcontracting is permitted for specific components only, such as:
a. Hardware supply and installation
b. OEM software modules
c. Field-level deployment and maintenance
(2) Core ITS software, system integration, command & control center operations, and project management shall NOT be subcontracted.
(3) The bidder shall remain fully responsible for the performance of all subcontracted components.
(4) Details of subcontractors, scope, and responsibilities must be declared at the time of bidding.
5.3 Bank as a Partner (NCMC)
Role of Bank
(1) A bank shall be allowed only as a technology/payment ecosystem partner for NCMC enablement.
(2) The bank’s role may include:
a. Issuance and management of NCMC-compliant cards
b. Payment settlement, clearing, and reconciliation
c. Key management and security as per NPCI / NCMC guidelines
(3) The bank shall not be considered as a Consortium/JV member for:
a. Turnover eligibility
b. ITS experience qualification
c. Technical evaluation of ITS components
Eligibility of Bank
(1) The bank must be:
a. A scheduled commercial bank in India, OR
b. An NPCI / NCMC-authorized issuing or acquiring bank
(2) The bank shall submit:
a. Letter of Authorization / MoU with the bidder
b. Proof of NCMC certification / authorization (as applicable)
Responsibility & Risk
(1) The Prime Bidder / Lead Member shall remain solely responsible for:
a. End-to-end system integration
b. Compliance with NCMC specifications
c. Performance of the NCMC-enabled solution
(2) Any failure or delay on part of the bank shall not absolve the bidder of contractual obligations.
6. ITS – TECHNICAL EVALUATION CRITERIA
6.1 Technical Evaluation Overview
(1) Technical evaluation shall be carried out to assess the bidder’s technical capability, solution robustness, compliance with standards, and relevant experience.
(2) Only bidders meeting the minimum technical qualifying score of ___% shall be considered for financial evaluation.
(3) Evaluation shall be based on documentary evidence, demonstrations, and presentations, as applicable.
6.2 Technical Evaluation Parameters & Weightage
Experience & Past Performance
Criteria Description
Similar ITS Projects
Govt./STU/Smart City ITS deployments
Scale of Deployment Vehicles, depots, command centers
(1) The ITS shall be implemented using a phased Go-Live approach.
(2) Initial Go-Live shall be based on Bare Minimum Functionalities required for operational visibility and control.
(3) Additional features, optimizations, and enhancements shall be rolled out through a continuous improvement model during the contract period.
10.2 Go-Live Milestones
Milestone 1: System Readiness (Pre-Go-Live)
Timeline: ___ weeks from LoA
Minimum requirements:
(1) Core ITS platform deployed
(2) Data center / cloud infrastructure operational
(3) Integration readiness with AVLS / AFCS
(4) User roles, access control, and security setup
(5) Sample vehicles onboarded and tested
Deliverable: System Readiness Certificate
Milestone 2: Bare Minimum Go-Live (Day-1 Operations)
Timeline: ___ weeks from LoA
Bare Minimum Functions (Mandatory for Go-Live)
(1) Vehicle & Operations Visibility
a. Real-time vehicle tracking (AVL)
b. Route and trip mapping
c. Planned vs actual trip visibility
d. Basic geo-fencing (depots / terminals)
(2) Command & Control Dashboard
a. Live fleet status dashboard
b. Vehicle health and connectivity status
c. Basic alerts (vehicle offline, delay, deviation)
(3) Scheduling – Basic
a. Digitized routes, stops, and timetables
b. Assignment of schedules to vehicles
c. Manual schedule updates (if required)
(4) Passenger Information (Basic)
a. Real-time arrival prediction (basic ETA)
b. PIS feed for terminals / mobile app (limited)
(5) Reports (Essential)
a. Daily vehicle run report
b. Trip completion / missed trip report
c. Basic uptime and availability report
Milestone 3: Stabilization Period
Duration: ___ days post Go-Live
(1) System performance monitoring
(2) Bug fixes and tuning
(3) User handholding and support
(4) SLA measurement starts post stabilization
Deliverable: Stabilization Completion Report
10.3 Continuous Improvement & Enhancement Phase
Functional Enhancements (Illustrative)
To be rolled out in planned phases:
(1) Advanced scheduling & optimization
(2) Crew / duty integration (if applicable)
(3) Advanced analytics & KPIs
(4) Predictive ETA and delay analysis
(5) Incident & breakdown management
(6) AFC / NCMC deep integration
(7) Mobile app feature expansion
Improvement Mechanism
(1) Enhancements shall be delivered through:
a. Quarterly / Half-yearly release cycles
b. Authority-approved roadmap
(2) Changes shall be classified as:
a. Included improvements
b. Change Requests (CRs), if outside scope
10.4 Governance & Review Structure
(1) A Steering Committee shall review:
a. System performance
b. Enhancement roadmap
c. User feedback
(2) Periodic reviews:
a. Monthly (initial year)
b. Quarterly (thereafter)
10.5 Payment & SLA Linkage (Strongly Recommended)
(1) Payments shall be linked to:
a. Achievement of Go-Live milestones
b. Successful stabilization
(2) SLAs shall:
a. Apply only after stabilization
b. Be enhanced progressively with feature maturity
10.6 Key Safeguards
(1) Failure to deliver Bare Minimum Functions shall delay Go-Live.
(2) Cosmetic or non-critical features shall not block Go-Live.
(3) Authority reserves the right to:
a. Accept Go-Live with bare minimum functionalities
b. Enforce improvement timelines contractually
11.TRANSITION TO NEW VENDOR AND SOFTWARE ESCROW
11.1 Seamless Transition and Contract Commencement
(1) The Authority intends to ensure uninterrupted operation of the Integrated Transport Management System (ITS).
(2) The contract awarded pursuant to this RFP shall commence from the day immediately following the expiry or termination date of the existing ITS contract.
(3) There shall be no gap, suspension, or overlap between the outgoing vendor’s contract and the incoming vendor’s contract.
(4) The incoming vendor shall assume full responsibility for ITS operations from Day One of the new contract.
11.2 Software Escrow
The successful bidder shall establish and maintain a Software Escrow Arrangement with a mutually acceptable escrow agent for the entire contract duration, including the Operations & Maintenance period. The escrow deposit shall include, but not be limited to:
(1) Complete and latest source code of all ITS applications
(2) Database schemas, configuration files, and build scripts
(3) APIs, integration interfaces, and system documentation
(4) Deployment manuals and operating procedures
The escrow shall be:
(1) Updated periodically, and at least upon every major software release
(2) Kept valid till successful completion of the contract and transition, if applicable
11.3 Escrow Release Conditions
The Authority shall have the unconditional right to access and obtain the escrow materials upon occurrence of any of the following events:
(1) Expiry of the contract without renewal
(2) Termination of the contract due to bidder default
(3) Insolvency, liquidation, or inability of the bidder to support the ITS
(4) Failure to provide transition support as stipulated in this RFP
Release of escrow materials shall not require the consent of the bidder upon occurrence of the above events.
11.4 Transition Support Obligations
The outgoing vendor shall provide mandatory transition support for a minimum period of ___ months or until completion of transition, whichever is earlier.
Transition support shall include, but not be limited to:
(1) Knowledge transfer and handover sessions
(2) Delivery of system architecture, configuration, and operational documents
(3) Handover of databases, credentials, and system access
(4) Support for data migration and system takeover
(5) Transition support shall be provided without any additional cost to the Authority.
11.5 Data Ownership and Handover
All data generated under the ITS, including operational, transactional, and historical data, shall be the exclusive property of the Authority.
Upon expiry or termination of the contract, the outgoing vendor shall:
(1) Hand over all data in open and non-proprietary formats
(2) Certify complete transfer of data to the Authority or the incoming vendor
(3) Permanently delete all Authority data from its systems, except as required by law
11.6 Obligations of Incoming Vendor
(1) The incoming vendor shall accept the ITS in its existing operational condition and ensure continuity of services from the effective date of the new contract.
(2) The incoming vendor shall ensure compatibility with escrowed software, documentation, and transferred data.
11.7 Linkage with Performance Security and Payments
(1) Release of final payments and/or Performance Bank Guarantee of the outgoing vendor shall be subject to successful completion of transition and handover activities.
(2) Failure to comply with transition obligations shall entitle the Authority to:
a. Invoke Performance Bank Guarantee, in full or part
b. Withhold payments
c. Initiate other remedies available under the Contract
11.8 Survival of Obligations
(1) Transition, data handover, and escrow-related obligations shall survive the expiry or termination of the Contract.
(2) Non-appointment of a new vendor or delay in procurement shall not absolve the outgoing vendor of its transition responsibilities.
12.SCOPE FOR EXPANSION AND CHANGE
12.1 Provision for Expansion
(1) The ITS solution proposed under this RFP shall be scalable and future-ready, enabling expansion in scope, scale, and functionality during the contract period.
(2) Expansion may include, but shall not be limited to:
a. Increase in number of vehicles, depots, terminals, and routes
b. Addition of new modules such as advanced analytics, AI-based monitoring, additional Passenger Information Systems (PIS), or new fare media
c. Integration with additional systems including ticketing, payment platforms (including NCMC), ERP, and government platforms
(3) Such expansion shall be supported without any fundamental change to the core ITS architecture.
12.2 Compliance During Expansion
(1) All expansions shall continue to comply with:
a. AIS-140 requirements for vehicle-mounted systems, where applicable
b. NCMC specifications for ticketing and payment systems, where applicable
c. Open data standards and interoperability requirements defined in this RFP
(2) Any hardware or software introduced during expansion shall be subject to the same technical eligibility and compliance criteria as the original scope.
12.3 Change Management
(1) The Authority may require changes in scope due to:
a. Regulatory or policy changes
b. Operational requirements of the transport authority
c. Technology upgrades or security requirements
(2) Such changes shall be managed through a formal Change Management process, including:
a. Change Request (CR) submission by either party
b. Impact assessment covering cost, timelines, and system performance
c. Approval by the Authority prior to implementation
12.4 Commercial Treatment of Changes
(1) Changes within the original functional and architectural framework of the ITS shall be implemented at no additional cost, unless explicitly approved otherwise by the Authority.
(2) For approved scope expansions involving additional hardware, licenses, or services:
a. Commercials shall be based on rates quoted in the financial bid, or
b. Mutually agreed rates, where items are not covered in the original BOQ
(3) No change shall be implemented without written approval of the Authority.
12.5 No Vendor Lock-In
(1) Expansion or changes shall not result in:
a. Dependence on proprietary hardware or software
b. Restriction of data access or interface portability
(2) All new components shall integrate through open and documented interfaces as per the Data Interface Catalogue.
12.6 Backward Compatibility
(1) All changes and expansions shall ensure backward compatibility with existing systems, data, and interfaces.
(2) Existing operations shall not be disrupted during implementation of changes.
12.7 Right of the Authority
(1) The Authority reserves the right to:
a. Add, modify, or remove components of the scope
b. Integrate third-party systems or solutions
c. Migrate or expand the ITS to new platforms or vendors in future
(2) The bidder shall extend all reasonable cooperation to enable such changes.
13.ROLES AND RESPONSIBILITIES
13.1 Roles and Responsibilities of the Authority
The Authority shall be responsible for:
(1) Providing overall project governance, approvals, and policy directions.
(2) Nominating an Authorized Project Officer / Project Management Team for coordination with the bidder.
(3) Providing access to:
a. Depots, vehicles, terminals, and Command & Control Centre premises
b. Existing systems, data, and infrastructure required for integration
(4) Facilitating approvals from relevant stakeholders, including transport departments, enforcement agencies, and banks (where applicable).
(5) Reviewing and approving:
a. Project plans, designs, and deliverables
b. Change Requests and scope expansions
(6) Making payments to the bidder as per the payment milestones defined in the Contract.
(7) Ensuring availability of existing ITS data for migration and continuity, where applicable.
13.2 Roles and Responsibilities of the Bidder / System Integrator
The successful bidder shall be responsible for:
(1) End-to-end design, supply, development, integration, testing, commissioning, and operation of the ITS as per the RFP.
(2) Ensuring compliance with:
a. AIS-140 standards for vehicle-mounted systems
b. NCMC specifications for ticketing/payment systems, where applicable
c. Data standards, interoperability, and cybersecurity requirements defined in the RFP
(3) Supplying and integrating certified, compliant, and hardware-agnostic devices.
(4) Developing and maintaining:
a. Core ITS software
b. APIs and data interfaces as per the Data Interface Catalogue
(5) Providing training, documentation, and knowledge transfer to Authority personnel.
(6) Operating and maintaining the ITS during the O&M period in accordance with defined SLAs and KPIs.
(7) Ensuring data security, data privacy, and system availability at all times.
(8) Providing full transition and handover support at contract expiry or termination, including software escrow compliance.
13.3 Roles and Responsibilities of OEMs / Subcontractors (If Applicable)
(1) OEMs and subcontractors shall:
a. Supply compliant hardware/software components
b. Provide OEM certifications, warranties, and technical support
(2) Subcontracting of core ITS software, system integration, and CCC operations shall not be permitted unless expressly allowed in the RFP.
(3) The bidder shall remain solely responsible for the performance and compliance of OEMs and subcontractors.
13.4 Roles and Responsibilities of Consortium / JV Members (If Applicable)
(1) The Lead Member shall:
a. Act as the single point of contact for the Authority
b. Be responsible for overall project delivery and contractual obligations
(2) All Consortium/JV members shall be jointly and severally liable for performance of the contract.
(3) Roles and responsibilities of each member shall be clearly defined in the Consortium/JV Agreement submitted with the bid.
13.5 Roles and Responsibilities of Bank / Payment Partner (NCMC) (If Applicable)
(1) The bank/payment partner shall be responsible for:
a. NCMC card issuance and lifecycle management
b. Transaction processing, settlement, and reconciliation
c. Compliance with NPCI/NCMC guidelines
(2) The bank shall not be responsible for ITS system performance or integration, which shall remain the responsibility of the bidder.
(3) Any failure on part of the bank shall not absolve the bidder of contractual obligations.
13.6 Joint Responsibilities
Both the Authority and the bidder shall:
(1) Participate in periodic review meetings and governance forums.
(2) Cooperate to resolve issues impacting timelines, performance, or service continuity.
(3) Support audits, inspections, and compliance checks as required.
13.7 Escalation & Communication
(1) A formal escalation matrix shall be established within ___ days of contract signing.
(2) Communication shall follow defined protocols for:
a. Incident management
b. SLA breaches
c. Change requests
13.8 Survival of Obligations
Roles and responsibilities relating to:
(1) Data ownership and handover
(2) Transition to new vendor
(3) Confidentiality and security shall survive contract expiry or termination.
14.PROJECT MILESTONES AND GO-LIVE REQUIREMENTS
14.1 Implementation Milestones
The successful bidder shall execute the project in accordance with the milestones defined below. Any deviation shall be subject to approval of the Authority. The key milestones (Indicative) are mentioned in the table below.
14.2 Mandatory Pilot Deployment
(1) The bidder shall implement a pilot deployment covering at least one (1) complete depot, including associated vehicles and routes.
(2) The pilot shall demonstrate:
a. End-to-end functionality of the ITS
b. Integration of hardware, software, and backend systems
c. Real-time data flow and reporting
(3) The pilot shall be considered successful only after:
a. Completion of a minimum stabilization period of ___ days, and
b. Written acceptance/sign-off by the Authority.
(4) Full-scale rollout shall commence only after successful completion and approval of the pilot.
14.3 Functionalities Required at Go-Live (Mandatory)
The following minimum functionalities shall be fully operational at the time of Go-Live. Partial or deferred functionality shall not be accepted unless explicitly approved by the Authority.
(1) Core ITS Functionalities
a. Real-time vehicle tracking (AIS-140 compliant where applicable)
b. Command & Control Center (CCC) dashboard
c. Route, trip, and schedule monitoring
d. Alerts and exception management (breakdown, deviation, SOS, etc.)
e. Historical data playback and reports
(2) Hardware & Field Systems
a. GPS/AVL devices operational and reporting
b. CCTV / PIS (where applicable) integrated and functional
c. Reliable data transmission from field devices to backend systems
(3) Data, Interfaces & Interoperability
a. All mandatory APIs and interfaces operational as per the Data Interface Catalogue
b. Data storage, retrieval, and export in open, non-proprietary formats
c. Integration with ticketing / AFC / NCMC systems, where in scope
(4) Security & Access Control
a. Role-based user access
b. Audit logs and system monitoring
c. Basic cybersecurity controls as specified in the RFP
(5) Reporting & MIS
a. Standard operational and management reports
b. Configurable dashboards for Authority users
14.4 Go-Live Acceptance Criteria
(1) Go-Live shall be declared only after:
a. Successful completion of pilot and stabilization
b. Verification of all mandatory Go-Live functionalities
c. Resolution of critical and high-severity defects
d. Formal Go-Live approval issued by the Authority
(2) Any functionality not meeting Go-Live requirements may result in:
a. Delay of Go-Live
b. Levy of penalties as per SLA
c. Withholding of milestone payments
14.5 Payment Linkage (Optional but Recommended)
(1) Payments shall be linked to achievement of clearly defined milestones.
(2) No advance payment shall be released unless explicitly approved.
(3) Payments shall be released only after formal acceptance by the Authority.
a. The balance Seventy-Five Percent (75%) of CAPEX and 100% of O&M charges shall be paid through equal monthly payments over the contract period.
b. Monthly payments shall be released subject to:
i. Compliance with applicable SLAs
ii. Submission of monthly performance reports
iii. Certification by the Authority or its authorized representative
c. Applicable taxes shall be paid as per prevailing laws.
15.2 Service Level Agreements (SLAs)
The bidder shall comply with the SLAs defined below. SLAs shall be applicable from the date of Go-Live.
SLA During Implementation Phase
(1) The Selected Bidder shall adhere to the Project Timelines.
(2) The Selected Bidder shall be penalised with the 'Implementation Amount' as defined below for each full calendar week of delay beyond the Go Live date (T + 60 days + any delay in approvals), except under Force Majeure conditions.
(3) Implementation Penalty Amount of ₹3,00,000 (Rupees Three Lakh Only) per week of delay
(4) The cumulative maximum Implementation Penalty Amount levied on the Selected Bidder shall be limited to 10 (Ten) full calendar weeks.
SLA During Operations Phase and Maintenance
(1) The Selected Bidder shall adhere to the SLA defined below for each component.
(2) The Selected Bidder shall be penalised the 'SLA Penalty Amount' defined below for failing to meet SLA.
(3) The cumulative maximum SLA Penalty Amount levied on the Selected Bidder in any given quarter shall be limited to 3% ((three percent) of the Quarterly Invoice Amount.
(4) SLA calculations shall always exclude:
a. Scheduled Maintenance Time;
b. Any time period when Force Majeure conditions are in effect; and
c. Any impact due to a failure on the part of the Authority to meet their obligations.
d. If Critical SLA availability falls below threshold for three consecutive months, Authority shall have right to terminate for default without penalty or compensation.
(5) The system is required to meet 100% availability requirements during business hours.
(6) Incident handling:
a. Incidents to be classified on a priority basis, i.e., high (Priority 1 (P1)), medium (P2), and low (P3) priority incidents.
b. The priorities are linked to three time-based indicators: Response time, Recovery time and Resolution time.
c. Critical P1 incidents will have a response time measured in minutes and a recovery time of typically less than two hours, whereas for a minor (P3) incident, the response time may still be short, but the resolution time is a working day or more.
15.2.2.1 SLA for ETIM Platform
Definition: 'Availability Of ETIM' means that the ETIM is able to perform intended functions.
SLA: The cumulative average Availability of ETIMs for all ETIMs should be at least 99% (ninety nine percent) in a calendar month.
SLA Measurement: Availability Of ETIMs = (Working ETIM Days / Total ETIM Days) x 100% Where,
Working ETIM Days = Daily functional ETIM count x days of operation in the month.
Total ETIM Days = Total required ETIM count x days of operation in the month.
Total Required ETIM count is No. of operational buses x 1.5, Spare ETIMs provided by the Selected Bidder for better operational maintenance shall not be counted in the Total Required ETIM.
SLA Penalty:
Performance Level (Uptime %)
99% or more
Penalty on Quarterly Invoice Amount
0% (Zero)
98% to 98.99% 1% (One percent)
97% to 97.99% 1.5% (One-point five percent)
Less than 97% 2.5% (Two-point five percent)
Critical SLA Threshold 96%
15.2.2.2 SLA for AFCS
Definition: Availability of AFCS' refers to the total time when the AFCS and its applications are available for performing operations.
SLA: The Availability of AFCS should be at least 99% (ninety nine percent) in a calendar month.
SLA Measurement: SLA measurement: Availability of AFCS = ((AFCS Scheduled Operation Time – AFCS Platform Downtime)/ AFCS Scheduled Operation Time)) x 100%
No transaction data shall be lost.
SLA Penalty:
Performance Level (Uptime %)
99% or more
Penalty on Quarterly Invoice Amount
0% (Zero)
98% to 98.99% 1% (One percent)
97% to 97.99% 1.5% (One-point five percent)
Less than 97% 2.5% (Two-point five percent)
Critical SLA Threshold
15.2.2.3 SLA for Digital Tracking on Mobile App
Definition: Availability Of Digital Tracking' refers to the total time when the digital tracking is available.
SLA: The Availability Of digital tracking should be at least 99% (ninety nine percent) in a calendar month.
SLA Measurement: Availability of Digital Tracking = ((Digital Tracking Scheduled Operation Time – Digital Tracking Platform Downtime)/ Digital Tracking Scheduled Operation Time)) x 100%
SLA Penalty:
Performance Level (Uptime %)
99% or more
Penalty on Quarterly Invoice Amount
0% (Zero)
98% to 98.99% 1% (One percent)
97% to 97.99%
(One-point five percent) Less than
(Two-point five percent)
15.2.2.4 SLA for Vehicle Tracking Units (VTU)
Definition: Availability Of VTU' means that the VTU is able to perform intended functions.
SLA: The cumulative average Availability of VTUs for all VTUs should be at least 95% (ninety-five percent) in a calendar month.
SLA Measurement: Availability Of VTUs = (Working VTU Days / Total VTU Days) x 100% Where,
Working VTU Days = Daily functional VTU count x days of operation in the month. Total VTU Days = Total VTU count x days of operation in the month.
SLA Penalty:
Performance Level (Uptime %)
Penalty on Quarterly Invoice Amount
99% or more 0% (Zero)
98% to 98.99% 1% (One percent)
97% to 97.99% 1.5% (One-point five percent)
Less than 97% 2.5% (Two-point five percent)
Critical SLA Threshold 96%
15.2.2.5 SLA for ACCURACY OF ESTIMATED TIME OF ARRIVAL (ETA)
Definition: Accuracy of ETA means that the ETA calculations meet user requirements according to the time left for the arrival of the bus.
SLA: The cumulative average accuracy of ETA for all VTUs should be at least 97% (ninety-five percent) in a calendar month.
SLA Measurement: The following accuracy standards shall be used for the estimate given based on when the estimate was calculated.
6-12 minutes
12-18 minutes
minutes
SLA Penalty:
99% or more
Level (Uptime %)
seconds
(Zero) 98% to 98.99%
to 97.99%
15.3 Latency
(One percent)
(One-point five percent)
(Two-point five percent)
The system should avoid latency in financial transactions in the AFCS, GTFS transactions describing the bus position, estimated time of arrival (ETA) estimates being sent to customer devices and similar sensitive transactions
15.4 Penalty for SLA Breach
(1) Penalty Quantum
a. Penalties shall be levied for failure to meet SLAs on a Quarterly basis.
b. Total penalty in any given month shall be capped at 3% of the applicable Quarterly payment.
(2) Penalty Application
(3) Penalties shall be:
a. Adjusted against Quarterly invoices, or
b. Recovered from Performance Bank Guarantee, if required.
(4) Penalties shall not absolve the bidder from meeting SLA requirements.
15.5 Repeated or Chronic SLA Breach
(1) Failure to meet SLAs for ___ consecutive months or ___ months in a contract year may result in:
a. Escalated penalties
b. Withholding of payments
c. Invocation of Performance Bank Guarantee
d. Termination of contract, as per Contract provisions
15.6 No Waiver Clause
Levy or non-levy of penalties in any month shall not be construed as a waiver of the Authority’s right to enforce SLAs in subsequent periods.
15.7 SLA Measurement & Reporting
(1) SLA performance shall be measured based on:
a. System-generated logs and reports
b. KPI dashboards
c. Quarterly SLA compliance reports submitted by the bidder
(2) The Authority’s determination of SLA compliance shall be final and binding.
15.8 Linkage with Go-Live and O&M
(1) Quarterly payments and SLA enforcement shall commence only after Go-Live.
(2) Any delay in Go-Live attributable to the bidder shall:
a. Delay payment milestones
b. Attract penalties as per contract terms
15.9 Authority’s Rights
(1) The Authority reserves the right to:
a. Revise SLA thresholds based on operational needs
b. Introduce additional SLAs during contract period through Change Management
c. Withhold payments in case of material non-performance
15.10 Survival of Obligations
SLA compliance and penalty provisions shall remain applicable throughout the contract period, including any extensions.
16.HARDWARE SPECIFICATIONS
Specifications
Magstripe:
Smartcard:
Contactless:
16.2 Technical Specifications of VTU
S.No. Component/Feature Specifications
1 VLTD
AIS140 Certified VLTD with emergency button complying with IS 16833:2018 standards
2 ARM Cortex Microcontroller 256KB Program Memory & 96KB RAM
64Mb. Supports 45000 Data Packets
3 Internal Memory
Storage When No GSM/GPRS Network 100K Erase & Program Cycles. 20Years Data Retention Expandable to 128Mb
4 Power Supply 7 – 36V DC
5 2G GSM Quad Band GSM Sensitivity: -109dBm
6 LED Indications Main Power, Internal Battery, GSM and GPS Network
7 IRNSS & GPS
Supports IRNSS, GPS & GLONASS 33 Tracking and 99 Acquisition channels, -167 dBm Sensitivity, Horizontal Position Accuracy of <3 meters CEP -130 dBm
8 Configuration & Firmware Update Local and OTA Configuration. Supports SMS & GPRS Configuration Supports FOTA
9 Input & Output Interfaces
4 Digital Inputs & 2 Analog Input
2 Digital Outputs & One SOS Input One RS-232 & One CAN* Interface
10 Protections Main Power Over Voltage Reverse Connection Tamper Detection ESD Protection
(1) The smart cards must contain a MiFare Plus SE 1K chip. (2) The smart cards must support ISO/IEC 14443-3A UIDs.
17.SOFTWARE REQUIREMENTS
17.1 Automated Vehicle Locating System
The Automated Vehicle Locating System (AVLS) shall primarily use GPS devices mounted on the vehicle as primary source of data for tracking purposes. The AVLS shall also facilitate Central Control Centre (CCC) as a source of information for real time on field operations and equip them with the details log for drill down of the critical events. The AVLS shall essentially comprise of following components:
(1) GPS Tracking Device
(2) Bus Mounted GPS based driver console (Available on the buses)
(3) Driver Display Unit (Available on the buses)
(4) Controller (For controlling on bus equipment already available on the buses)
(5) AVLS software & Integration with existing hardware
The AVLS system shall enable operations team to monitor vehicle movement in real-time and synthesize the AVL field data to deliver the same on the public information system devices installed on Bus Stops, Terminals, Buses, Customer portal and mobile information delivery system.
AVLS Specifications:
(1) Web based software with high resolution GIS Map for showing real time information of vehicles (both buses & e-rickshaws) should be provided.
(2) System should be capable to give comparative connectivity analysis between any two preferred geographical areas in graphical and tabular manner
(3) System should be capable to configure user accessibility, organization and operational structure based on client’s existing structure.
(4) AVLS system should have capability to define and track trips using user defined templates.
(5) AVLS system should be capable to automatically identify and notify major and minor route violations as per authority’s definition.
(6) AVLS system should be smart to automatically force close the trips either in the cases where in GPS Device is in coverage area showing abnormalities in terms of schedules time and distances or in case GPS Device is outside coverage area. Such alerts/events/reports shall be provided to the central system.
(7) The software shall provide customized GIS Maps along with vector Maps and line map for better decision support facility.
(8) The system should be capable to map and plot all fleet performance relevant incidents live on map.
(9) Vehicle transit history / Replay should also highlight distance travelled with over speed, low speed, all stoppages, deviated path, other vehicles of same route and their current location, GPS data loss zones etc.
(10) System shall have dedicated dashboard where user shall be able to analyse every scheduled trip, its adherence and other performance relevant information and regularity in single window.
(11) The software shall provide map-based tracking and transit route line-based tracking of vehicles for control centre operators.
(12) The software shall have enterprise capabilities which enables multiple user type to carry out various functions like Alarm Management, Vehicle Schedule Tracking, Speed Management, Stoppage management, Route replays, bus tracking dashboard etc. as a standard functionality.
(13) The software shall enable Authority to drill and analyse information and online data in a multidimensional manner.
(14) Comprehensive analysis and reporting capabilities are expected to be part of the application delivery which matches the world standard capabilities of AVLS systems.
(15) The system should store the running time whenever a vehicle transits between two waypoints, system should have the ability to accumulate and constantly refines a database of travel times that have occurred to accurately predict the ETA.
(16) Ability to measure vehicle’s actual movements against these predicted values to determine how late or early a vehicle is running against the historical averages. These predictions should be disseminated to PIS and other stakeholders.
(17) The system should interface with data sources such as the schedule and planning tool to obtain operational route and timetable data. The system should also support a standard webservice interface for third party consumers of real-time public transport information.
(18) Solution should have On-vehicle hardware and software that provides AVL tracking and integration with on-vehicle equipment including next stop displays and audio systems.
(19) The system should have track routes being running, where the stops are located, the timetables for these routes at these stops, all must be current and accurate.
(20) System should have functionality to load each vehicle with the complete schedule for a shift when the operator dispatches the vehicle.
(21) The system should store the running time whenever a vehicle transits between two waypoints.
(22) The system should also have the ability to accumulate and constantly refines a database of travel times that have occurred to accurately predict the ETA.
(23) The system should obtain crew and vehicle allocations through the schedule and planning system.
(24) The software should have capability to have a multi-screen-based tracking system, so as to enable tracking staff to quickly analyse activities and have a better insight into operational data of all activities within the system.
(25) Proposed AVL solution should have the capability to track buses in real time and predict ETA at stops and disseminate this information to PIS and on-board PIS systems.
(26) Ability to define geo-fencing for different locations like parking, depots, stations, authorized stoppage points, etc with Entry & Exit both being of different radius.
(27) System should notify the operator of the communication error in case vehicle is untracked.
(28) System should have facility to reproduce the path taken by vehicle with different colour according to vehicle status.
(29) Solution should have functionality to change the speed of reproduced path while displaying it on GIS map for better analysis.
(30) System should be able to display overall fleet status with colour legend in graphical manner.
(31) Overall performance analysis based upon operational regularity should be displayed.
(32) System should be capable of showing adherence to defined schedule online diagram of all previous and present trips.
(33) System should have ability to show fleet and trip status overview in graphical manner.
(34) System should have facility to monitor live station details with self-regulating in-time and out time of vehicle.
(35) System should have functionality to check unassigned vehicle and crew assignment details at any time.
(36) Solution should be able to configure incidents with its severity, level as well as authority responsible for handling those incidents.
(37) System should be capable of defining route boundary over GIS map and displaying it in software.
(38) Solution should be capable of showing all stoppage locations with its details given any stoppage time.
(39) All unauthorized stoppage should be measured and monitored through the system.
(40) System should have multi selection functionality for tracking multiple trips information at a same time.
(41) Solution should have event management module for configuring special occasions.
(42) Solution should be able to depict tabular and graphical representation of trips and fleets statistics.
(43) System should be easily configurable based upon user rights and user roles for different modules.
(44) Solution should cover all aspects for routes, schedules and vehicles based on user role such as,
a. All stop details (name, location, number, type with functionality to add/edit/delete)
b. All route details (boundary, order, stops with functionality to add/edit/delete)
c. All passenger information details (final & mid-point destination name numbering with functionality of add/edit/delete)
d. All vehicle details (with add/edit/delete)
e. All crew details (with functionality of add/edit/delete)
f. All schedule details (with add/edit/delete)
(45) Solution should cover the gtfs standards
Type Description
GTFS Static Fixed schedule, routes, stops, and trips
GTFS Realtime
Live data: vehicle positions, trip updates, service alerts
Used to configure AFCS backend and devices with route and stop mapping
Used for real-time validation, dynamic fare calculation, and app updates
Generated by AFCS for ridership analytics and reporting
Used for operational planning and linking validator logs to driver duty
(46) System GUI should provide the ability to perform assignments of crews and vehicles
(47) System should have ability to automatically import Routes and timetables and validate against existing route and timetable data within the system and are tested for any timing or route changes.
(48) System should automatically detect the route deviated by vehicle from its predefined one.
(49) Solution should be able to show trip with different colour legend based upon its operational status.
(50) Solution should be deprived of showing live vehicles, stops and lines on map.
(51) Solution should have functionality to display stops, vehicles, lines on straight line diagram.
(52) System should be able to generate reports such as,
a. Performance report
b. Exception report
c. Monitoring report
d. Validating report
e. Summary report
(53) Solution should be able to display information of vehicle, crew and trip on mouse over.
(54) System should show detailed control information of vehicle with detailed stop control.
(55) Solution should have multi-map view and ability of zone creation.
(56) System should have panic button message management and management of detours.
(57) System should be able to integrate existing hardware (on bus components) & all third-party software
17.2 Automatic Fare Collection System
The functional specifications section provides specification for major components for AFCS:
(1) Automatic Fare Collection System
(2) Fare Collection Devices & Integration with existing devices
(3) Integration with Incident Management
(4) Integration with Business Intelligence
(5) Integration with existing Hardware & AFC system
The core objective of implementing AFCS is to create an integrated fare collection mechanism using interoperable standards, hence the devices and media thereby have to be complementary in nature. The end state requirement of this implementation shall be that of integrated fare management and collection regime which will render its services to all types of transit system operated within the city in a unified manner. In-order to meet diverse need of commuter and application, following media types shall be offered to users for payment of fare purposes:
(1) Contactless Smartcards
(2) QR code-based Paper Tickets
(3) Mobile application-based ticketing using QR code
(4) Booking through web portal
These AFCS fare media shall be made available to user at several locations such as Terminals within the city, designated branches, Web application, Mobile application, etc.
AFC Devices:
The station ticketing facility shall facilitate the commuter travel by providing an ecosystem for issuance and acceptance of fare media. The station ticketing facilities shall consist of the following:
(1) Point of Sale: The POS shall offer functionality to conduct the activities like issuing smart card, QR/Barcode code-based paper tickets, topping up of the smart cards and handle customer queries related to ticketing. POS shall have ability of ticket issuing / cancelling / refunding / adjusting etc. POS should be able to read and write from all the fare media as defined in the business rules.
(2) Handheld Ticket Terminal (HTT): Handheld electronic ticketing terminals shall be deployed for checking/ validating the fare media with the commuters and shall be used by station AFC staff for
issuing Barcode/QR code-based paper tickets. This equipment is a portable hand-held device to facilitate the ticket checking capability as well.
(3) Mobile App for ticketing: Mobile application (Android/iOS) shall be developed to enable users to generate secure Barcode/QR based tickets for use on ticket validation devices.
(4) Central system of AFCS: The Central system shall consist of the AFC transaction & Configuration Application integrated with a smart card host system. The system shall be used to set configuration parameters (such as tariff tables etc.) that would be required to operate the system.
(5) Central Back-office system/AFC Software is the heart of entire AFC ecosystem consisting of the core components for daily operations of AFC system. The system shall be used to set configuration parameters (such as tariff, device configuration, product configuration, user configuration etc.) that would be required to operate the system. The system would host all the information required for processing the fare media within the transit ecosystem. It shall function as a Management Information System (MIS).
(6) Solution should include Paper based ticketing, Smartcard based ticketing, Passenger Pass management. AFCS system shall dynamically control Concession/Discount Management vs. Passenger category, Special services, pre-planned change/configuration at fare update etc. Ticket Stock Management, Dynamic configuration of Shift times etc., Handheld Ticketing Machine allocation, Pass issuing management, etc.
ETIM Functionalities
(1) The ETIMs must facilitate the issuance and / or validation of tickets, passes, and other travel plans via the following fare media:
a. Cash tickets
b. NFC-based NCMC Compliant smart cards
c. Mobile app, and
d. other media as may be developed from time to time and mutually agreed between the Parties.
(2) The printed travel receipts issued shall comply with the requirements of the Authority, and as may vary from time to time. The Authority's intention of minimizing the paper printed tickets is expressed herewith.
(3) The conductor shall be able to manually adjust the current origin location.
(4) The ETIM must have the ability to add a configurable fine (either optional or mandatory for use by the conductor) to a ticket or any travel receipt.
(5) The ETIM must be able to record and print various types of tickets and travel receipts - general ticket, group ticket (adult + child + concession), other concession tickets, differential fare ticket, various schemes tickets, luggage ticket, package ticket etc.
(6) Types of fares and tickets should be able to be created centrally and updated to ETIM devices via OTA updates.
(7) The ETIMs should be able to issue refunds of fare in case of change in service type or full / partial cancellation of service or face value revision.
(8) The ability to view the details of any ticket issued by the conductor.
(9) Record the details of passengers travelling on a valid ticket from whom fare is not collected by the conductor, such as mobile ticket holders, pre-paid smart card passes holders, monthly / quarterly pass holding passengers, employee duty passes holders, etc.
(10)Tickets and passenger information should be encrypted and relayed in real-time to the AFCS without data loss, and also available in batches for reconciliation and settlement as per operational cycles, e.g. for each trip, for each shift, at the end of each day, etc.
(11)In the case of loss of data connection, transactions must be stored locally and then transmitted to the AFCS upon re-establishment of the data network.
(12)All ticketing functions must work in offline mode in the case of loss of data connection and then be settled by batch mode as required once online.
(13)The user interface shall allow an experienced conductor to issue a ticket in less than 4 (four) seconds on average.
(14)At the end of each trip, the ETIM should be able to print a trip summary report.
(15)The ETIM should have the capability to update fare rules, fare tables etc. dynamically via OTA updates.
(16)The ETIM should be able to hold a different set of fare structure to be implemented from a given date and time.
(17)The ETIM must be able to validate all forms of pre-purchased tickets, passes, or other travel plans (mobile tickets or passes, smart card tickets or passes, paper-based tickets) in both online and offline mode. These tickets could be single-journey, return and / or monthly passes, or other multijourney tickets.
(18)The ETIM shall be compatible with National Common Mobility Cards ('NCMC').
Access To ETIM
(1) The conductor should be able to login to the ETIM via a combination of username + password (ID + PIN), or via any other secure means
(2) Other roles may be required to login to the device based on varying operational needs
Data Stored and Transmission
(1) The ETIM shall store all required transaction data on-board, including:
a. Date and time of transaction
b. Device ID
c. Route ID
d. Trip ID
e. Vehicle ID
f. Passenger trip ID
g. Origin terminal
h. Destination terminal
i. Terminal arrival time
j. Terminal departure time
k. Origin stop ID
l. Destination stop ID
m. Passenger category
n. Number of Passengers
o. Payment ID
p. Transaction Value
q. Mode of Payment
r. Smart Card Serial Number
s. Employee ID of Driver
t. Employee ID of conductor
u. Vehicle Number
v. Depot ID
w. Transmission status (i.e. successfully or not successfully transmitted to AFCS)
(2) The ETIM shall have sufficient memory to store a minimum of one week's worth of transaction records apart from other mandatory software/ firmware etc.
(3) Only successfully transmitted transaction data records shall be overwritten by new transaction data records.
(4) ETIMs shall be connected to the AFCS through mobile network data connection, and have the capability to transmit real-time ticket transactions, battery status, count of tickets, etc. to the AFCS.
Smart Card and Mobile Application Usage With ETIM
(1) The ETIM shall have a trip validation functionality whereby when a smart card is brought in proximity to the reader or when a QR code is scanned with the ETIM's camera, the ticket details necessary for the conductor to verify are displayed on the ETIM's display.
(2) Upon successful completion of any transaction with a smart card or mobile application, the ETIM shall indicate successful completion via its display and optionally a distinct audio message as well.
(3) The ETIM device shall have balance check functionality whereby the prepaid wallet balance available on a smart card, any outstanding trip details, and status of the smart card are displayed on the ETIM display.
Performance Requirements
(1) The ETIMs should be able to perform without any material degradation of performance over time.
(2) The ETIMs should have an accuracy of 99% for every transaction, and any MIS reports generated through the ETIM.
(3) The time taken to print a ticket through the ETIM after data entry should not 2 (two) seconds per transaction.
(4) The Selected Bidder shall ensure availability and uptime of ETIMs and any related software Platform as per SLA mentioned.
(5) The ETIMs must be rugged enough to withstand the harsh public transport and be dust and water resistant.
(6) The ETIMs must have multiple means of transferring data to the cloud in case of lack of mobile network data connectivity such that there is no loss of data for the Authority.
(7) The ETIMs should have an integrated display that can be easily read under all conditions of ambient light throughout the day and night.
Functional Details of AFCS
(1) Integration with All System Components:
a. Acquire and process all the transactions from all fare media at acceptance infrastructure.
b. Push all necessary fare media parameters and fare tables information to ETIMs via OTA updates.
c. Communicate with each ETIM via the network and process the data received to provide overall audit, statistical and operational information.
d. Generate the necessary management reports from the fare media transaction information.
e. Dynamically refresh the mobile application for products, fares, ticket and pass types, and other parameters.
(2) Reconciliation and Real-Time Reporting:
a. Automatic generation of daily, weekly, monthly, and yearly reports, and for any time period selected, for revenue reconciliation using the transactions and revenue data.
b. Reports shall be generated vehicle-wise, route-wise, depot-wise, and shift-wise.
c. Reconciliation reports should be generated at the end of each shift and end of each day for each device.
d. The functionality should have the ability to correct manual errors, if any.
e. The AFCS should reconcile tickets / passes issued at the end of each day for each device.
f. Each depot's information shall be collated, and the collective revenue generation report shall be made available to the Authority's officials.
g. The AFCS should provide a functionality to book tickets over a WhatsApp chatbot
(3) Database Management System:
a. Support exception handling, validation, and security.
b. Parallel processing of transactions.
c. Maintain historic data for the entire Term of the Project.
(4) Product Configuration Management
a. Configure transport products with parameters such as product ID, name, duration of product, number of trips per day, routes or stops, device type, fare, discounted fare, applicable passenger categories, etc.
(5) Security Management
a. Restrict access to entire AFCS only to authorised users.
b. Create different user groups and assign different access levels / privileges.
c. Maintain transaction logs to record all changes to database, etc.
d. Security breach reports must be sent to authorised personnel as per the SLA.
(6) Tickets and Revenue Reports
a. Facility to generate and view online, real-time project and MIS reports for transactions handled during a specific period, transaction density trends for any specific periodicity (hourly, weekly, daily etc.) and any bottleneck situation creating dependency at any stage.
b. The MIS details would be worked out during the System Requirement Specifications ('SRS') stage in mutually decided
c. The following is an indicative list of MIS reports. The Authority and the Selected Bidder can mutually agree on more reports that might add value to the Project.
i. Machine detail report indicating number of online ETIMs, number of ETIMs in depots and unmoved / idle ETIMs in depot on at a date and time.
iv. Passenger count by trip, route, on a daily, weekly, monthly basis de-boarding reports.
v. Stop-wise boarding and
vi. Maintenance and failure reports
vii. End of day reports to report all transactions from an ETIM
viii. Network availability report
(7) All reports to be available daily, weekly, monthly, quarterly, annually or for any selected time period, as mutually decided by the Authority and the Selected Bidder. The Authority and the Selected Bidder shall decide the format of the reports and the need for any additional reports during the Term.
Mobile Tickets
(1) Mobile Ticketing:
a. Passengers can purchase any form of tickets available through the mobile application deployed under this Project that the Authority permits to be launched for the benefit of passengers.
b. The various tickets options available are - single journey, or monthly / quarterly passes (or for any other duration), or concession (special category) passes etc. The Selected Bidder may choose to innovate and introduce new travel plans, in close coordination and with the approval of the Authority, for the benefit of the travelling public.
c. Tickets once purchased to be stored securely in such a manner that they can be presented for validation even if the user's mobile phone is offline without a data connection.
d. Multiple passengers may ride using one ticket on one phone as long as the correct number of tickets or rides have been validated.
e. The application shall have the capability to store preferred routes, source and destination stations etc. to allow quick booking of tickets for frequent travellers.
f. The bidder will be responsible for integration with ONDC web portal to enhance interoperability and provide passengers with more booking options, aligning with current trends in digital ticketing and improving user accessibility across platforms.
(2) Mobile Passes and Other Travel Plans:
a. Passengers can purchase any form of passes or other travel plans available through the mobile application deployed under this Project that the Authority permits to be launched for the benefit of passengers.
b. Various types of passes shall be available - one day pass, weekly pass, monthly pass, tourist pass, student concession pass, and any other pass or travel plan that the Authority permits.
c. Passes once purchased to be stored securely in such a manner that they can be presented for validation even if the user's mobile phone is offline without a data connection.
(3) Other Functionality on The Mobile App:
a. In addition to the above, the mobile application should also let users live track their buses with live time of arrival functionality for planning their journey better.
b. The Authority will let the Selected Bidder integrate with their existing live bus tracking platform so that the Selected Bidder can display buses live on the mobile application, thereby bettering the mobile tickets and passes experience for passengers.
c. The mobile application also should have a live passenger indicator feature by which users can view how crowded the bus is on a live basis, whether seats are available, or standing space is available, or if the bus is filled to capacity.
d. The mobile application should have a trip planner where a user can enter their point of origin and destination and see all the bus route combinations along with fares and live arrival times available for their trip.
e. The mobile application should enable users to locate their nearest bus stops.
f. The mobile application should have an SOS function to enable sending an emergency message to selected contacts on their mobile phone. The Purchase should have the option to also be notified of all SOS messages.
g. The mobile application should be able to display service update messages to users based on the routes they are searching for.
h. The application shall have the capability to push notifications to users for important updates, notices from the Authority, promotions, etc.
i. The mobile application should be user friendly with suitable text available in English, and other languages as may be agreed between the Authority and Selected Bidder from time to time.
(4) Validation / Authentication of Mobile Tickets and Passes:
a. The mobile ticket / pass must withstand both digital authentication through QR using the ETIMs provided under this Project and / or any other secure method of validation that the Authority may approve.
b. Mobile ticket / pass validation must function fully offline on both the ETIM and the passenger's mobile phone.
(5) Security of Mobile Tickets and Mobile Passes:
a. Mobile tickets / passes should be free from duplication.
b. All the basic details of the passenger should be visible on the ticket / pass screen for easy verification by the bus crew and ticket checkers.
c. The QR code displayed for validation should be dynamic and refresh each second for an enhanced layer of security to the tickets feature.
d. The application must prevent users from taking screenshots and / or video recordings of the pass in order to avoid fraud.
e. There should be a feature for users to 'activate' their tickets / passes at the time of boarding the bus. Tickets / passes once activated shall remain active only for a specified time period.
f. Tickets / passes purchased on a specific mobile device shall be 'locked' on to that specific mobile device and shall only be transferred from one device to another via the approved process of the Authority.
g. At any point in time, it should be possible for a ticket inspector to inspect the QR code ticket / pass using an ETIM or any other device and impose a fine on the passenger if s/he is found to travel with an invalid ticket / pass.
(6) Payment Integration and Security
a. All online payments must use state of the art 128 bit or higher security.
b. Payment options include RBI-approved digital payment options, including UPI, debit cards, credit cards, net banking, and others.
c. The Authority shall have the option to bear the payment gateway charges on digital tickets (if any) themselves or pass them on to passengers transparently. UPI payments would be free under the government framework.
d. MDR Charges will be passed on to the passengers unless the Authority agrees to bear the cost.
Smart Card Platform
(1) Smart cards shall work as 100% contactless tap-to-pay cards
(2) The smart cards must be NFC enabled.
(3) The smart card should be able to concurrently store:
a. Closed System PPI; and
b. A travel plan such as a pass, or any other travel plan as defined by the Authority.
(4) The Platform shall have the capability to remotely blacklist smart cards in circulation.
(5) The Platform shall have the capability to reject expired, invalid, or blacklisted smart cards.
(6) At any point in time, it shall be possible for a ticket inspector to validate smart card tickets and passes using an ETIM or any other device and impose a fine on the passenger if s/he is found travelling with an invalid ticket / pass.
(7) The Authority shall set up distribution points for the sale of cards.
(8) Conductors should be able to issue and recharge smart cards in the bus using their ETIM device.
(9) The Selected Bidder shall ensure sufficient training is provided to the Authority's employees on all aspects of the smart card Platform and smart card usage.
(10)The Selected Bidder shall setup guidelines and processes for the Authority and the bus crew to be able to issue smart cards, take deposits, and return deposits at the time of return of card, if required.
(11)The Selected Bidder shall provide software to support and scale for 2 (Two) lakhs card transactions per day.
(12)The Selected Bidder shall provide dashboards, reports, MIS, and SLA Tools as agreed with the Authority.
(13)The Selected Bidder shall create an ability for the Authority to be able to validate and audit smart card tickets / passes without requiring printing ticket receipts from ETIMs.
(14)Smart card tickets shall be contactless by eliminating the need to hand over paper ticket to passengers for validation or proof purposes.
17.3 Passenger Information System
The Passenger Information System is an important component of ITS system and renders an important consumer facing services. Accurate and timely PIS delivery facilitates consumer trust on public transport service and also aids modal shift in long term, as the reliability and availability become evident to the users.
The passenger information system is an integrated service which utilizes tracking data from vehicles which is centrally processed for the purpose of arrival and departure time estimation. Central PIS system shall deliver ETA/ETD information on schedule or request basis depending on the type of end point application or device. The central PIS delivers ETA / ETD to fixed display devices installed on bus stations at a set frequency or on bus movement basis. The PIS to commuters will also be delivered via other electronic means like web portal and mobile app. This multi-channel commuter interface enables quick access to transport system and ensure citizens see the city transit system as safe and reliable alternative for travel purposes. The system shall consist of following units to offer users access to real-time information regarding operations of bus transit service and extend ease of information access related to travel needs:
(1) PIS Display Screen at Bus Stops
(2) Display Screen on Bus (should have the capability by integrating BDC)
(3) Transit web portal for Bus Schedule & ETA, SMS
(4) Mobile App
(5) Integration with existing PIS software & hardware
The PIS display systems at bus stations shall display real-time information of the route and estimated time of arrival using communication system installed within the station (Wired / Wireless) with the central AVLS / PIS Application. The system will have capabilities to clearly indicate the route no of the bus on the display to assist passengers.
The Authority’s web portal shall enable passengers to get information about the bus schedules on various routes operated by Authority and shall also have facility to deliver ETA based on the real time data from central PIS system. PIS shall also be made available to users via mobile apps.
PIS Specifications
(1) Display of PIS in a display unit at bus station shall be configurable based on bus station. Single unit should display services of more than one platform.
(2) Information Display units shall be supplied and mounted appropriately, configured and commissioned by the vendor.
(3) PIS information shall be displayed in Odia, Hindi and English alternatively (multiple language shall be configurable).
(4) At all these bus stations, display units shall receive/display transmitted contents from the central system through a gateway or mention other suitable means in the technical architecture.
(5) Displayed messages must be readable in high bright, day light.
(6) The frequency and period of information display on PIS display shall be configurable from central location for advertisements and other transit information.
(7) Display shall provide for modular configuration setting for enabling parallel display of content on different areas of the screen – Real time Transit information (Routes, ETA, Type of service, Fare, Time/Date).
(8) All displays for PIS will have a configurable refresh rate with minimum of 10 seconds.
(9) Display units shall be mounted on a rugged enclosure to withstand harsh environmental conditions with reasonable physical security.
(10)Display will be located at a convenient height to have a clear view of the message of next arrival bus.
(11)Fitment provision will have to be provided in the Bus stations. Bidders need to evaluate the requirement by visiting the BQS and consider whatever is required to do a neat installation. There should not be any wires hanging out in the BQS.
(12)The raw power supply shall be made available by Authority. Bidders need to provide UPS for the power distribution to various devices.
(13)The LED board shall be installed in such a way that it is vandal proof as far as possible.
(14)The station PIS display at Bus Station shall display at least 2 lines for city buses.
(15)The bidder should ensure integration of on bus PIS with ITS
17.4 Depot Management System/Solution
Depot Management
(1) This module enables to automate depot operations, which include workshop management, fuel management, traffic management, vehicle management, and so on. The module shall also cover administrative activities and stores requirement.
(2) Depot Management shall automate Depot Operations by providing Vehicle Management, Services Management, Integrated depot management and stores and inventory management
(3) This module enables to manage and update depot Operations. It should be enabling maintaining Vehicle Details, manufacture details, depot and roles of users, staff management etc.
(4) Shall provide managing and adding the Crew/staff details such as employee code, role, current address, contact number, personal information.
(5) All modules/sub modules of Depot management should be seamlessly integrated
(6) The depot management process shall be primarily responsible to carry out the following functions:
a. Crew Rostering using DMS
b. Vehicle Dispatch using CAD system
c. Vehicle maintenance and operational requirements like fuel etc. using DMS
d. Maintenance expenses
(7) The operations & maintenance processes with respect to buses shall be captured by the system. The Bidder shall provide customization to the software based on the functional and technical requirements of the project.
(8) Crew Rostering module shall be able to create group of users based on set of defined parameters by PTA. The proposed rostering module shall plan, optimize and generate the rostering automatically for month to one year. It shall allow admin or authorized user to create and view the planning for a defined period of time. The proposed rostering application shall display or provide rostering using graphical representation for the selected period and shall interface with scheduling module to assign crews automatically to the schedule. The Rostering module shall have an interface with HR system to update crew absence, holidays, etc. In any event schedule deviations, rostering shall update crew’s operation hours, ideal hours, etc., for each day to improve the operation.
(9) Rostering system shall have optimization technique to minimize and identify the underperforming crew. The proposed rostering shall provide individual or group wise performance in graphical user interface. That including working, non-working hours, holiday, leave, over time, etc.
(10) DMS process shall provide productivity reports to ensure insights into operations such as:
a. Crew allocation
b. Schedule allocation
c. Crew utilization report
d. Fleet departure at depot
e. Fleet dead KM per route/ fleet wise
f. Revenue Kilometre
g. Schedule or trip cancellation
h. Crew license renewal history
i. Over time details per staff wise
j. Fuel stock per month/week/per day
k. Fuel consumption every day
l. Fleet wise fuel consumption
m. Vehicle service alerts
(11) DMS shall also provide functionality for workshop management and following modules shall be offered:
a. Body repairs
b. Fitness Certificate Renewal
c. Reconditioning of assemblies and engines
d. Retrieving of spares
e. Tyre re-treading
f. Repairs and reconditioning
(12) The application shall provide query by fleet to view and update the fleet status.
(13) The application shall have features to capture daily progress of particular vehicle department wise to track progress by type of workshop activity (accident, engine rebuild, fitness certificate, etc.). All the documents related to vehicles like vehicle registration, FC, Road permit, Staff ID proof, License, purchase orders etc. shall be scanned and uploaded into corresponding sub systems like DMS, WMS, Stores, and HR & Payroll across in-house fleet and Gross Cost Contract (GC) operators.
(14) Application shall have features to capture and report vehicle-wise insurance claims, road permit, etc. DMS module shall have an interface with workshop module to update maintenance detail.
(15) The following MIS reports form the tentative list. Additional reports may be added during design discussions and pilot implementation.
a. Breakdown
b. Accident
c. Vehicle in/out
d. Pending Maintenance
e. KMPL for each Fleet
f. Vehicle FC, Road permit history
g. Complete history of each vehicle maintenance by month and year
Stores & Inventory
(1) The proposed Stores and Inventory application shall have features to generate purchase orders, maintenance contractor details, previous quotes, etc. Asset management system to maintain all the physical items belongings to this project. Application shall have receipt of incoming goods/GRN. The application shall support barcode reader to read the item information, warranty, etc. and register into application. Barcode reader should read the goods while procuring and it shall register into the system for inventory.
(2) Barcode reader has to check the goods warranty, batch, year of manufacture, etc. by reading the barcode label on the goods. The application shall have provision to track goods transferred to other depots. Each item shall set with threshold level for stock. When the stock is going below threshold then system shall send alerts to concerned person(s) or department.
(3) The system shall have warranty information for each item. There shall be a provision to note the physical stock location number on the application to identify the stock easily. All the items entered into system with date of manufacture, date of warranty expiry, batch, date of purchase, etc. Query screen to check warranty information of particular item shall be available. Asset will have unit make, model, part number and location of asset for both movable and immovable. Stock management shall be able to capture new and used items.
(4) The following MIS reports form the tentative list. Additional reports might be added during design/pilot stage.
a. Monthly Stock detail
b. Item wise Stock
c. Item name & code with Warranty
d. Stores accounting value
e. Utilized stock
f. Inventory control
g. Maintenance of stock record
h. Stock transfer
i. Asset Detail
j. Asset Summary – depot wise, division wise
17.5 Vehicle Planning, Scheduling and Dispatch Management (VPSD)
The Bidder shall conduct a detailed study of the existing IT infrastructure and data of city during the planning stage of the project and propose a migration plan into the new VPSD.
(1) The VPSD system should be scalable in terms of performance for future increase of users, fleet, crew, depots, etc.
(2) The Bidder shall provide required number of VPSD licenses for all necessary users and the entire fleet for the entire duration of the Project.
(3) VPSD application shall consist of:
a. Planning & Scheduling
b. Vehicle Scheduling and timetable
c. Crew Scheduling and Roster
d. Dispatch and Daily Management
e. Dispatch of Vehicles & Crew
f. Daily Management of Vehicles and Crew
(4) VPSD to be integrated with AVLS as per the requirements.
(5) VPSD related data shall be available for a minimum period of 3 years. Data of 1 year to reside in the primary storage while the remaining to be stored in secondary storage.
(6) Data nomenclature shall follow existing structure as per authority’s requirements such as by division, depot, operation, route, schedule, bus type, employee type, employee, bus, etc.
(7) All terminology in the VPSD application shall be consistent with the current operational terminology used by the authority.
(8) Application shall have ability to have a separate database instance for testing purposes.
(9) All its major features shall be available through toolbar icons and all features shall be accessible with dialog boxes.
(10) All data shall only need to be entered once with no retyping of data necessary.
(11) Application shall have role-based access with read and write level access.
(12) Flexibility in access of individual screens of the application shall be provided so that each user shall have different (no access/read/write) privileges.
(13) All components of VPSD shall be integrated with other ITS subsystems so that data entry shall be done only once between the subsystems.
(14) The system shall be modular so that improvements in one sub system/component do not make other subsystems/components to fail.
(15) The Bidder shall identify steps to ensure migration to the Bidder’s VPSD from the current system with least operational challenges for the authority.
(16) Ability to produces printouts of crew schedules, duty rosters, route timetables, bus stop timetables etc.
(17) The system shall provide necessary reports, operations monitoring dashboards and MIS environment.
(18) The objective of network modelling is to digitalize and maintain the GIS information (stops, depots, routes, distances, etc.) and produce a statistical speed analysis to be applied during vehicle scheduling.
(19) The bidder shall collect the existing network databases from authority and propose a migration plan.
(20) The solution shall have map-based interface with the option to use Google Map/ TomTom/ Bing/ MapmyIndia/ OpenStreet map etc. as a background and being compatible with Google Transit.
(21) All GIS objects shall be editable in the map-based interface (stops, stations, depots, distances, paths, etc).
(22) The solution shall allow the user to change the path automatically based on road network (with the option to use google map) or enter distances manually.
(23) The solution shall provide specific features for managing and optimizing the dead run (noncommercial trip) on the map.
(24) The solution shall have a schematic view of the routes / network.
(25) The solution shall provide statistical module for analysing GPS data from AVLS in order to build a speed / travel model for the entire network.
(26) The speed / travel time model shall be based on type of days and hours of the day for each path / section (including dead run) of the network. The model shall be further used to produce the timetables and schedules in order to integrate the traffic conditions into the planning process.
(27) The objective of vehicle scheduling is to define the schedules / trips of the vehicles based on targeted frequencies depending on routes, types of day and hours of the day and traffic conditions and available resources.
(28) The bidder shall collect the existing timetable databases from authority and propose a migration plan.
(29) The proposed system to allow frequency or number of vehicle approach for producing the vehicle scheduling plan.
(30) For frequency approach, the user shall be able to give as a parameter the targeted frequency depending on the hour of the day for a type of day. The system will calculate the necessary number of vehicles.
(31) For number of vehicle approach, the user shall be able to give the maximum number of vehicles (depending on the hour of the day), the system will calculate the optimum frequency at peak hours.
(32) The system shall further support scheduling for routes operating with multiple trips per vehicle within a shift/day; and routes having partial trips (cut trips), including short-turn services or truncated route operations.
(33) The scheduling engine shall ensure proper vehicle allocation, trip sequencing, and frequency optimization for both full-length and cut-trip operations.
(34) The proposed application shall display vehicle scheduling using graphical representation for the selected period (time-vehicle graph), with different color for each vehicle (stops for Y-scale and time for X-scale).
(35) Ability to define types of day (weekdays, weekends, holidays, festivals, etc.). Each type of day can have different vehicle scheduling and timetables.
(36) System should have ability/edit specify inbound and/or outbound timetable for a specified day type.
(37) Ability to add, edit and copy/duplicate timetables
(38) Ability to link/add trips to the selected timetable.
Crew Scheduling Module
The objective of crew scheduling is to optimize the crew allocation to the vehicle services. Key indicators are number of crew, hours (driving and non-driving), extra hours, etc. The crew scheduling also helps in providing crew schedules according to personal preferences and social constraints. The proposed solution shall have automatic and manual features for building a roster grid of crew scheduling to be applied to the different types of day.
(1) The system shall support existing crew rules and regulations of the authority and in-turn authority shall be open to the process improvements suggested by the implementation of VPSD system and tailor their processes for the optimal solution.
(2) System shall have ability to create crew schedules considering different shifts parameters such as shift spreads, mealtime etc.
(3) System shall have ability to define shift start and end points, break times, etc.
(4) System shall have ability to support minimizing/maximizing crew hours (driving, breaks…), extra hours, total weekly / monthly respecting the rules & regulations.
(5) System should be capable of creating crew schedules for Bus schedules which operate from specific depot / division and transfer crew.
(6) System shall support following reports but not limited to:
a. Detailed Crew report for each duty / crew day(s) of the week clearly indicating Sign On, Sign Off, Trip details that are to be performed, meal break location, etc.
b. Consolidated Crew report for all duties in a depot for day(s) of the week clearly indicating Sign On, Sign Off, On Vehicle, OFF Vehicle, Steering time and hours of duty for driver and conductors
c. Statistics reports of crew and depot.
d. Horizontal Blocks to provide duty wise details of each crew along with the Route number on which they will perform duty
(7) The Bidder shall provide a Crew Rostering Software with choice-based duty.
(8) Crew Rostering module shall be able to create group of users based on set of defined parameters.
(9) System shall have provisions to easily make changes to the planned roster
(10) System shall have provision to create rosters for user definable day types such as Public Holidays, weekends etc.
(11) System should have provision to include non-driving work in the roster
(12) System should have provision to utilise drivers from other Depots
(13) Schedule master shall have minimum start place, end place, starting and end time of each trip, rest time in between the trips, distance between the start and end place, distance between stops, overnight stay, etc.
(14) The crew scheduling module shall provide following MIS reports, but are not limited to:
a. Crew Reports
b. Driving and non-driving hours
c. Depot / division reports
d. Crew Allocation alerts and reports
Daily Dispatch Module
The objective of the daily dispatch module is to allocate on a daily basis the vehicles and crew to the planned services, depending on maintenance planning for the vehicles and crew holidays or trainings, etc… For each operational day, a type of day shall be applied and physical resources to be allocated.
(1) The solution shall have interfaces at the depot for recording the crew operations and store the attendance information (worked and driving hours, absence, etc...).
(2) The proposed solution shall have a vehicle and crew master database with their attributes (type of vehicle, identification, names, etc…).
(3) The proposed solution shall have specific features for preparing the allocation plan for the next days / weeks / months depending on the rules and regulations for the crew.
(4) The proposed solution shall allow change of allocation (vehicle / crew) during the operations at the depot level.
(5) The proposed solution shall record the crew operations of each day (to be further used by other systems for salary calculation or statistics…).
(6) The dispatch module shall provide following MIS reports, but are not limited to:
(7) Vehicle and crew allocation plan for specific periods (weeks, months, year...)
(8) Statistics based on vehicle (KMs, maintenance...) and crew (driving and non-driving hours, extra hours...)
(9) Depot / division reports
17.6 Contract Management Solution
The objective of the Contract Management Solution (CMS) is to facilitate efficient and transparent management of contracts of the PUBLIC TRANSPORT AUTHORITY, ensuring compliance with contractual obligations and enhancing communication and collaboration between cities, bus operators, and overseeing authorities. The CMS aims to provide streamlined processes related to contract creation/configuration, performance monitoring, invoice generation, and payment processing, ultimately contributing to the successful implementation and operation of the scheme while promoting accountability and effective utilization of resources.
Following is the illustrative workflow of the proposed CMS module:
Sr. No. Particulars
1. CMS for Cities
Functional Requirements
1. Cities should be able to configure multiple GCC contracts with one or more bus operators.
2. Contract configuration page should allow cities to record timelines and upload documents as applicable for activities including but not limited to:
a. Date of issuance of LOA
b. Prototype testing and approval
c. Depot fits out works.
d. Bus Delivery inspection
e. Operational readiness of the operator
3. Contract configuration section should also allow cities to record, including but not limited to, following parameters:
a. Start date of operations
b. Term of Contract
c. Number and types of buses
d. Minimum assured kilometer for each type of bus
e. Email ID and contact details of the operator
i. Per kilometer rate – if monthly run kilometers is equal to monthly assured kilometers
ii. if monthly run kilometers are less than minimum assured kilometers
iii. if monthly run kilometers are more than minimum assure kilometers
For example:
o If the actual Bus Kilometers travelled by all Buses is equal to aggregated Monthly Assured Kilometers, then Fee shall be calculated by multiplying the PK Fee (INR) with such actual Bus Kilometers
o If the actual Bus Kilometers travelled by all Buses is less than the aggregated Monthly Assured Kilometers, then Fee shall be calculated by using the following formula:
Fee = (PK Fee * actual Bus Kilometers) + (PK Fee * 75%* (Monthly Assured Kilometers - actual Bus Kilometers))
o If the actual Bus Kilometers travelled by all Buses is more than the aggregated Monthly Assured Kilometers, then Fee shall be calculated, in accordance with clause 22.3.3 by using the following formula:
500%* (actual Bus Kilometers - Monthly Assured Kilometers))
f. Key performance indicators (parameters to be fetched from AVLS), service levels (equal to, less than or more than threshold) and corresponding penalties/incentives (amount or percentage of monthly payment) – System shall populate KPI, SLA and penalties and allow cities to edit via formula builder
g. Limit of damages - system shall populate KPI, SLA and penalties and allow cities to edit –
I. for KPIs
II. for Operational Infractions
h. Payment timelines – system shall populate KPI, SLA and penalties and allow cities to edit –
I. Part 1: No. of days after submission of invoice and % of payment to be released.
II. Part 2: No. of days after submission of invoice and % of payment to be released subject to penalties and deductions.
4. The CMS shall integrate with proposed AVLS solution to capture performance against parameters, including but not limited to:
a. Number of buses planned for operations vs. actual.
b. Number of Breakdowns
c. On-time departure and arrival of buses
d. Number of trips planned vs. actual.
e. Number of Accidents
If cities have existing ITS modules like AFCS, AVLS, DMS, IMS etc. the above data shall be pushed to CMS through APIs.
5. CMS shall generate alerts on dashboards for proforma/tax invoices submitted by the operator/s. The remaining days for payment shall be highlighted considering the payment timelines configured during creation of the contract.
6. CMS shall allow city to verify the amount calculated as part of proforma invoice and approve the payment of Part 1 post upload of the required documents including approval obtained on files. The payment screen shall have ability to capture one of more deductions including statutory deductions like TDS.
7. CMS shall allow cities to access the operators’ performance against KPIs and operations infractions and to classify whether to impose penalty/incentive against each parameter.
8. CMS shall allow cities to record whether to include/exclude each parameter during the final payment, i.e., Part 2 payment. It should allow to record the justification against each inclusion/exclusion before sharing the final calculation of penalties and incentives with the operator.
9. CMS shall generate alert on dashboard and shall notify the cities if the proposed final calculation is accepted by the operator/s and tax invoices is submitted, or operator/s has raised grievance against the proposed calculation.
10. In case of grievance, after offline deliberations with the operator/s, cities should be able to publish revised calculations of penalties/incentives.
11. CMS shall generate alert on dashboards to notify cities upon submission of tax invoice by the operator/s.
12. Payment process page shall allow cities to record penalties/incentives, TDS and other statutory deductions and documents including approval obtained on files, before releasing the payment of Part 2.
13. Processing payment from escrow account and generate payment advice.
14. Upon successful contract configuration by the cities operator shall receive confirmation along with login credentials to access the CMS.
15. Operators should be able to see key details such as, run kilometers, KPIs and operational infractions on the CMS dashboard. (It is expected that these datapoints will be fetched from the proposed AVLS solution at least twice; manual refresh option shall be provided)
16. CMS shall allow operators to automatically generate proforma invoices having details including but not limited to:
a. Date of Invoice
b. Month for which the invoice is generated.
c. Type and no. of buses
d. Minimum assured kilometers
e. Actual run kilometers
f. Amount receivable (run kilometer X per km rate as applicable)
g. Performance against KPIs and operational infractions
h. Approx penalty/incentives
i. Adjusted invoice amount and taxes
17. CMS shall allow operators to submit proforma invoices for the approval of the cities. The remaining days for payment shall be visible considering the payment timelines configured during creation of the contract.
18. CMS shall generate alert on dashboard in case the proforma invoice and payment of the Part 1 (as specified during contract configuration) is approved and processed.
19. CMS shall generate alerts on dashboard and notify operator upon final calculation of penalties and incentives is completed by the
2 CMS for Operator
3
CMS for MoHUA / PUBLIC TRANSPORT AUTHORITY
4 General Requirements
cities. Operators shall have functionality to accept the proposed calculation and process for generation of tax invoice; or generate grievance against any or each of the parameters.
20. CMS shall generate alerts on dashboards and notify operators if the grievance has been processed and shall populate the revised final calculation as published by the cities.
21. CMS shall provide features for operators to generate tax invoices for remaining payment, i.e., payment of Part 2 and submitting the same to the cities for approval.
22. MoHUA should be able to see the dashboard of active contracts in each city and shall be able to drill down to access contract configurations and performance of the bus operators
23. CMS will generate alerts to notify MoHUA/PUBLIC TRANSPORT AUTHORITY in case the payment is not processed within timelines as specified during the contract configurations.
24. The CMS shall provide reports and insights with graphical reports for monitoring contract compliance and performance.
25. A visual for invoice generation to payment disbursement shall be displayed with different colour code for ease of process tracking.
26. The CMS shall maintain an audit trial for all transactions and should be made available to as and when requested by MoHUA/ PUBLIC TRANSPORT AUTHORITY/cities. The retention period for audit trail data shall be determined and configured in the system.
27. The CMS shall support Hindi and English language.
17.7 Incident Management System
Incident management is the process of managing multi-agency, multi-jurisdictional responses to disruptions. Efficient and coordinated management of incidents reduces their adverse impacts on public safety, traffic conditions, and the local economy. Incident management yields significant benefits through reduced vehicle delays and enhanced safety to motorists through the reduction of incident frequency and improved response and clearance times.
Incident management is a planned effort to use all resources available to reduce the impact of incidents and improve the safety of all involved. Emergency/Incident Management shall be handled through the AVLS or through some Command & Control Platform. In general, the strategies for emergency/incident management will be developed at a broader organizational level and shall involve many stakeholders including the AVL system. The incident management process shall include:
(1) Detection
(2) Verification
(3) Motorist Information
(4) Response
(5) Site Management / Action
(6) Traffic Management
(7) Clearance
This system should execute following phases:
(1) Notification phase
(2) Response phase
(3) Recovery phase
(4) Restoration phase
Incident management system is envisaged to be implemented as part of emergency response and alert/event management which shall facilitate communication of activities internally and externally as well.
System Requirements:
(1) System should be able to facilitate user to define Incident Definition during System configuration. And allow user to redefine it as per the need at any later stage. All incident reports should reflect such user driven Incident definition from the immediate effect.
(2) System should have dedicated Incident handling dashboard to View, Analyse and Handle incidents easily.
(3) System should have analytical graphical dashboard to evaluate live and historical incidents (such as Route performance analysis, transporter performance analysis) for pattern analysis and better decision making
(4) System should be able to automatically identify Incident severity and exact location of incident along with all previous incidents of same route or trip
(5) Incident handling mechanism should enable control centre staff member to manage incidents based on Priority & severity or escalate it if needed based on user authorization assigned.
(6) System should be able to auto prepare driver score card based on incident reported
(7) System should be capable enough to auto close incidents based on predefined system configuration
(8) System should be able to prompt all incident alerts.
(9) System should be able to support at least following incidents but actual incident list to be finalized with the authority and bidder to propose an exhaustive list covering all possible incidents which may be thought of. The system should be flexible enough to include incidents as and when experienced.
a. Vehicle running with Over Speed
b. Vehicle Running with Minimum Speed
c. Vehicle attempting Route Deviation
d. Vehicle having Unidentified Stoppage
e. Vehicle having Missed Stoppage
f. Vehicle having Miss out Trip
g. Vehicle having Early Trip Start
h. Vehicle having Delayed Trip Start
i. Vehicles in state of Bunching / Bundling / Headway
j. Passenger Overload
k. Organizational Level/Depot/Terminal wise Operational Regularity
l. Vehicle in Breakdown
m. Vehicle in Accident / Panic Situation
n. Equipment Performance
o. GPS/BDC Device not connected
p. Low Battery
q. Shelter PIS Out of order
r. On board PIS Out of order
s. Incidents Recorded by External Entities Damaged Lane
t. Blocked Road due to Roadside Accident
u. Blocked Road due to Roadside Working Progress
v. Excess Passenger Flow due to Event/Festival
w. The bidder may also provide leading readymade solutions along with all perpetual licenses.
17.8 Web Portal
(1) Service provider / bidder shall have to develop web pages which shall allow user to view and download route information, route schedule and real-time ETA.
(2) Web Portal shall allow user to plan their journey based on source and destination preferred.
(3) The portal will act as a single source of information with regards to transportation system in Authority’s city and hence shall have all possible interfaces like logging complaints, viewing transport information, real-time updates, organizational structure, citizen blogs etc.
17.9 Mobile Application
Category
Ease of Finding
Bus stop / Bus / route / schedule etc.
Mobile App Features
Ease Of travelling
Mobile App Features
System should show Current Location of user with nearby Bus stop on Map along with the distance & time to travel.
User should be able to search for nearby station, where the user can get the bus for the route selected by him/her or the Source & destination pair.
Show routes and the details of bus reaching in next 15/30 min for the selected bus station.
Should be able to search all the routes connecting the source and destination provided by them, along with upcoming bus details in those routes.
Should be able to view all the schedule time for a selected route and between the selected bus stations.
Should be able to provide details of Bus location, last stop crossed, last stop time along with ETA of the particular bus.
Should be able to see the real time expected travel time between his selected source and destination or at the station.
Should be able to mark favourite for a route or for a particular bus stop. Favourites should be displayed in the front for easy access to know upcoming Busses in the favourite route and their ETA/ETD etc.
Ease of Ticket
Booking
Ease of Management
Should be able see the fare between two stations with relevant details like distance, routes connecting two stops etc.
Should be able to book tickets for travel. The e-ticket/SMS should be verifiable by the ticket collector inside the bus through the hand-held machine.
Should have a provision to pay for ticket directly through mobile application.
Should be able to give feedback to authority with photograph of problem/ suggestion.
Should be able generate desired reports as per the Operation team & CRUT Management.
Should be available in Android and iOS Only.
Others
Should have an Emergency panic button which can be used by user to send exact location of Bus to all relevant persons during emergency.
Should have a provision to host various promotion & brand display
17.10 MIS & KPI Reports
Management Information System is a single window dashboard for higher management and key decision maker. The dashboard is designed considering typical requirement of Decision Support Tool for Higher Management. It can be used as navigation to various reports and other functionalities as well. The dashboard may be used as one of the best tools available to authorities of Public Transit System for various comparison and Decision Analysis.
System should offer at least following features under MIS module:
(1) Ability to capture Operational Performance KPI events as and when they occur
(4) Ability to analyse Exceptions/Events/Incidents
(5) Ability to capture Fleet & Crew performance and prepare Driver performance scorecard
(6) Ability to capture depot performance
(7) Ability to capture incidents and trigger the training requirements for the crew
(8) Ability to define level of detail from minor to complex as per company or regulatory requirements
(9) MIS Reporting is used to perform day to day monitoring of the ticketing operations and be responsible for generation of MIS reports.
(10) The Back Office generates reports automatically at end of day. The Back office collate, format and enable end of day and ad-hoc reports to be printed from the data transmitted by the AFC Devices. Data will be stored in a relational data base structure to permit ad-hoc and detailed log reporting.
(11) MIS reporting should be capable of extracting reports from the day of operations
(12) Details of the parameters of report will be finalized during the design phase.
(13) Below are the minimum number of reports required, and all the reports will be finalized during the design phase.
General Reporting Requirements – KPI Reports
(1) The ITS shall provide module-wise KPI reports and dashboards for operational monitoring, performance evaluation, and decision-making.
(2) KPI reports shall be:
a. Available through the Command & Control Centre (CCC) and web-based dashboards
b. Configurable by authorized users
c. Exportable in open formats (CSV, Excel, PDF)
(3) KPI data shall be derived from real-time and historical system data and shall support:
a. Daily, weekly, monthly, and custom reporting periods
b. Drill-down and trend analysis
AVLS (Automatic Vehicle Location System)
The system shall generate the following minimum AVLS KPI reports:
(1) Operational Performance
a. Vehicle availability and uptime
b. Trip adherence (scheduled vs actual trips)
c. On-time departure and arrival performance
d. Route deviation and geofence violation reports
(2) Service Reliability
a. GPS device health and data reporting status
b. Communication downtime and data latency
c. SOS and emergency alert summary
(3) Fleet Utilization
a. Vehicle utilization (km operated vs planned)
b. Idle time and stoppage analysis
c. Speed violations and driving behaviour indicators
(4) Compliance Reports
a. AIS-140 compliance status
b. Historical playback and audit trail reports
AFCS (Automated Fare Collection System)
Where AFCS / ETIM / NCMC systems are in scope, the following mandatory KPI reports shall be provided:
(1) Revenue & Transactions
a. Total transactions by mode (card, QR, cash, etc.)
b. Route-wise, trip-wise, and vehicle-wise revenue
c. Daily reconciliation and settlement reports
(2) Payment & Settlement
a. NCMC transaction success/failure rates
b. Bank-wise and issuer-wise settlement status
c. Pending, failed, and reversed transactions
(3) Device & System Health
a. ETIM / validator uptime and availability
b. Transaction processing latency
c. Device error and exception reports
(4) Audit & Compliance
a. Fare rule compliance
b. Ticket issuance vs trip completion analysis
c. Audit trail of fare changes and overrides
Depot Management – Rostering
The Depot Management System shall provide rostering and workforce KPI reports, including but not limited to:
(1) Crew Planning & Allocation
a. Crew roster utilization (planned vs actual)
b. Duty assignment compliance
c. Unassigned duties and shortfall analysis
(2) Attendance & Productivity
a. Attendance vs rostered duties
b. Overtime and excess duty reports
c. Crew productivity indicators (trips/hrs/km per crew)
(3) Exception & Compliance
a. Duty violations and rest-hour non-compliance
b. Absenteeism and last-minute replacements
c. Shift deviation reports
(4) Management Dashboards
a. Depot-wise and route-wise rostering efficiency
b. Trend analysis of crew availability and utilization
Performance management and service improvement KPIs
The ITS system shall generate these KPIs in MIS formats as well as BI dashboards that can be used to analyse KPI trends for performance management and service improvements.
Category
Service, Availability, Quality and Productivity
Key Performance Indicator (KPI)
Fleet availability (Average fleet on road)
Fleet utilisation (Ratio of fleet on road to fleet held)
Schedule level performance
Buses per route
Vehicle utilisation (Effective km per bus)
Effective (Revenue) hours of service per bus
Schedule adherence (% of scheduled km performed)
Reasons for cancelled km (in % of daily cancelled km)
Schedule adherence (% of scheduled hours performed)
Number of skipped stops
Total hours of delay + early arrival
Reliability (To be measured at the last stop of each route as ratio of 'Average headway maintained between buses' and 'Average headway scheduled')
Punctuality (To be measured at the last stop of each route as 'Total vehicle Hours of delay+Total vehicle hours of early arrival')
Total number of passengers per bus
Service effectiveness (operators’ perspective)
Service effectiveness (passengers’ perspective)
Cost efficiency
Labour efficiency
Safety
Occupancy Ratio
Passenger-km travelled
Number of passengers per bus per day
Passenger trips per revenue vehicle hour of bus
Passenger trips per revenue vehicle hours of bus
Number of passengers per bus per day
No. of transfers per passenger
Journey time of users split by in-vehicle, access, egress and wait time
Breakdown Factor
Crowding
Punctuality
Dwell Time at stops
Operations cost per km (cpkm)
Earnings per km (ticket +pass revenue) (epkm)
Operating Ratio
Average daily revenue per shift (to be reported by shift type)
Total staff deployed (staff on road+ spare staff) Vs Total staff on rolls
Total vehicle hours per employee (to be reported by shift type)
Number of accidents (Fatal & Total)
Ratio of vehicle kilometres to Number of accidents
Number of accidents on each route
17.11 Financial Management System
The Financial Management System shall be standard corporate financial management system including P/L and Balance sheet management.
The financial management system shall comprise of enterprise reporting management which shall take care of all accounting functions including fare accounting, disbursal to operations, profit and loss calculations, asset management etc.
The financial management system should also manage fare or any other financial transactions with companies offering services. It is envisaged to offer single ticket to passengers to travel across all urban transport systems and hence the financial management system should have capability to account for all such activities and suitably have function to enable payment receivables and deliverables to respective entities – Central Clearing House System. The reporting for the automated fare collection (AFC) component of the system and the accounting package shall be separate. The AFC system shall provide reporting on transactions and other financial data in its own right and shall be separate from a third-party corporate accounting system.
Central Accounting System:
The central accounting system shall consist of following sub-systems/ modules but not limited to:
The receipt of funds shall be a centralized/de-centralized activity and shall be managed by central financial management system. The receipts from the transportation and allied activities shall be managed in the central accounting system. The RAM shall cover the following major activities:
(1) Receipt of Funds (Treasury Section)
(2) Posting in Daily Sheets
(3) Consolidation into Classified Registers
(4) Cross Check with Collection Centres and Treasury Section
(5) Trial Balance (monthly & annually)
18. DATA GOVERNANCE, OWNERSHIP, AND STANDARDS
18.1 Ownership of Data and Solution
(1) All data generated, collected, processed, or stored under this ITS, including operational, transactional, analytical, and historical data, shall be the exclusive property of the Authority.
(2) The bidder shall have no ownership rights over the data and shall use the data only for the purpose of performing obligations under the Contract.
(3) Ownership of the solution architecture, configurations, data models, interfaces, and custom developments created specifically for the Authority shall vest with the Authority, except for preexisting proprietary components, which shall be clearly disclosed.
18.2 Data Interface Catalogue (Mandatory)
(1) The bidder shall submit a comprehensive Data Interface Catalogue as part of the Technical Bid and maintain the same throughout the contract period.
(2) The Data Interface Catalogue shall include, for each interface, the following minimum details:
a. Interface name and purpose
b. Source and target systems
c. Applicable data standard
d. Data schema and field definitions
e. Extensions or custom attributes (if any)
f. Data exchange method and protocol
g. Performance requirements (latency, throughput, availability)
h. Data quality requirements (accuracy, completeness, timeliness, consistency)
i. Error handling, retries, and audit mechanisms
(3) Any interface not declared in the Data Interface Catalogue shall be treated as non-compliant.
18.3 Data Latency Requirements
(1) The ITS shall support configurable data latency options based on operational requirements, including:
a. Near real-time (≤ 1 second)
b. Low latency (≤ 10 seconds)
c. Standard latency (≤ 30 seconds)
(2) The bidder shall clearly indicate:
a. Which modules and interfaces support each latency level
b. Network, infrastructure, and cost implications for each latency option
(3) Provision shall be made for additional commercial costs where lower latency requirements (e.g., 1 second) demand enhanced infrastructure or connectivity, subject to approval of the Authority.
(4) Failure to meet committed data latency shall be treated as an SLA breach.
18.4 Data Privacy and Security
(1) The bidder shall ensure data privacy and protection in accordance with:
a. Applicable Government of India guidelines, advisories, and policies
b. Cybersecurity and data protection best practices
(2) The bidder shall implement:
a. Role-based access control
b. Encryption of data in transit and at rest
c. Secure authentication and authorization mechanisms
d. Audit logs and monitoring
(3) The bidder shall ensure that no data is shared with third parties without explicit written approval of the Authority.
18.5 Data Standards (Mandatory Compliance)
The ITS shall support and comply with the following open transport data standards, as applicable to the scope:
(1) Public Transport & Scheduling
a. GTFS-Static – Routes, stops, schedules, calendars
b. GTFS-Real Time (GTFS-RT) – Vehicle positions, trip updates, service alerts
(2) Operations & Performance
a. Transit Operations Data Standards (TODS)
b. GTFS-RIDE – Ridership and passenger counts
(3) System Integration
a. Transit Integrated Data Exchange Specification (TIDES)
(4) Electric Mobility (If Applicable)
a. Open Charge Point Protocol (OCPP) – For integration with EV charging infrastructure
(5) Any deviation, extension, or customization of the above standards shall:
b. Be explicitly documented
c. Not break compatibility with the base standard
d. Be approved by the Authority
18.6 Open Formats and Portability
(1) All data shall be stored and exchangeable in open, non-proprietary formats.
(2) The Authority shall have the unrestricted right to:
a. Access raw and processed data
b. Export data at any time
c. Integrate the data with third-party systems or future platforms
(3) The bidder shall support data migration and portability during expansion, hosting changes, or transition to a new vendor, at no additional cost unless otherwise approved.
18.7 Software Portability Across Hardware
(1) The ITS software shall be hardware-agnostic and shall not be tightly coupled with any specific OEM hardware.
(2) The software shall be capable of operating with:
a. Different makes and models of GPS/AVL devices
b. CCTV, PIS, and peripheral devices from multiple OEMs
c. Standard server and network infrastructure
(3) Replacement or upgrade of hardware during the contract period shall not require rewriting or relicensing of the core ITS software.
18.8 Decoupling of Software and Hardware
(1) The bidder shall ensure clear logical separation between:
a. Core ITS software
b. Device drivers and hardware adapters
(2) Device integration shall be handled through:
a. Configurable adapters, connectors, or middleware layers
b. Well-documented APIs and data contracts
18.9 Data Portability and Migration
(1) All ITS data shall be stored in standard, non-proprietary database formats.
(2) The system shall support:
a. Export of data in open formats (CSV, JSON, XML, SQL dumps)
b. Migration of data to new hardware or platforms without loss or corruption
18.10 Verification and Compliance
(1) The Authority reserves the right to:
a. Verify interface compliance during implementation
b. Seek demonstrations of hardware portability
c. Require submission of sample APIs and data schemas
(2) Non-compliance with this clause may result in:
a. Rejection during technical evaluation, or
b. Withholding of acceptance and payments during implementation.
18.11 Ownership and Usage Rights
(1) All interfaces, data models, and integration documentation developed under this contract shall be the property of the Authority.
(2) The Authority shall have the unrestricted right to use the interfaces for:
a. Integration with third-party systems
b. Migration to alternate hardware or vendors in future.
(3) Interface Catalogue is provided in Annexure 1 of this document.
18.12 Hardware Standards Compliance
(1) All hardware proposed under this RFP, including Vehicle Location Tracking Devices (VLTD/GPS-AVL), Passenger Information Systems (PIS), Electronic Ticketing / AFC devices, validators, and backend integration hardware, shall comply with applicable national transport and payment standards, including but not limited to:
a. AIS-140 and subsequent amendments issued by MoRTH
b. ETIMS with L1, L2, Qsparq certificates
c. NCMC specifications issued by NPCI and relevant authorities (where ticketing/payment is in scope)
d. Open transport data and interoperability standards as defined in this RFP
(2) Compliance with the above standards is a mandatory technical eligibility requirement.
(1) Where Automated Fare Collection (AFC), ETIM, validators, or payment systems are in scope:
a. Hardware shall be NCMC-compliant and certified / approved by NPCI or its authorized agencies.
b. Devices shall support interoperable, bank-agnostic NCMC transactions.
(2) Hardware that:
a. Is tied to a single bank, closed wallet, or proprietary payment ecosystem, or
b. Restricts transaction or settlement data access shall be considered non-compliant and ineligible.
18.15 Transport System Interoperability
(1) All hardware shall support open and standardized data interfaces to enable integration with:
a. ITS Command & Control Center
b. Passenger Information Systems
c. Ticketing and payment systems
d. Third-party government platforms and future systems
(2) Interfaces shall use:
a. Open protocols (REST, HTTPS, MQTT, etc.)
b. Standard data formats (JSON, XML, CSV)
c. Documented APIs as per the Data Interface Catalogue
18.16 Ineligibility Due to Non-Compliance
(1) Any hardware that:
a. Is not AIS-140 compliant (where applicable), OR
b. Is not NCMC compliant (where applicable), OR
c. Does not support transport interoperability standards defined in the RFP, shall be deemed technically ineligible.
(2) Inclusion of such hardware shall result in:
a. Rejection of the specific hardware component, and/or
b. Rejection of the bid at the technical evaluation stage.
18.17 Verification and Demonstration
(1) The Authority reserves the right to:
a. Verify AIS-140 and NCMC certificates
b. Conduct live data extraction and interoperability demonstrations
c. Seek third-party validation, if required
(2) Claims of future compliance or post-award certification shall not be accepted.
18.18 Replacement and Rectification
(1) If non-compliant hardware is identified at any stage of the project:
a. The bidder shall replace such hardware with compliant hardware
b. Replacement shall be done at no additional cost and without impact on timelines or SLAs
18.19 Declaration of Compliance
(1) The bidder shall submit a Hardware Standards Compliance Declaration confirming:
a. AIS-140 compliance
b. NCMC compliance (if applicable)
c. Transport interoperability compliance
(2) False declarations shall be treated as material misrepresentation and may lead to contract termination.
18.20 Survival of Obligation
Compliance with AIS-140, NCMC, and interoperability standards shall remain mandatory throughout the contract period, including O&M and transition phases.
18.21 Data Retention and Archival
(1) The bidder shall comply with data retention periods as specified by the Authority or applicable regulations.
(2) Archival data shall remain accessible in usable formats throughout the retention period.
18.22 Data Server Requirements
Indicative server requirements for 1,000-5,000 buses mentioned below. Bidders are required to comment on the proposed specifications and propose alternative specifications, if required, with adequate justification.
Sr. No. Particulars
1. If the servers are hosted in the authority’s data centre or premises:
Details
• Hardware Requirements
o High-performance servers (multi-core CPUs, minimum 64–128 GB RAM)
o Storage arrays (SAN/NAS) with redundancy (RAID 10/RAID 6)
o Minimum 20–40 TB storage (scalable, depending on data growth)
o High-availability network switches, firewalls, and load balancers
• Software & Virtualization
o Virtualization (VMware/Hyper-V/KVM) for scalable workloads
o Database servers (PostgreSQL, MySQL, MS SQL, or Oracle)
o Application servers (Linux/Windows-based)
o Backup and disaster recovery solutions
• Security
o Firewalls and intrusion detection/prevention systems (IDS/IPS)
o Role-based access controls & encryption at rest and in transit
o Regular patching and vulnerability management
• Operational Needs
o 24x7 monitoring (NOC/SOC)
o Disaster Recovery Site (DRS) for failover
o Skilled IT staff for maintenance
2. If hosted on AWS, Azure, Google or Government Community Cloud (MeitY empanelled):
• Infrastructure
o Virtualized compute instances (scalable CPU/RAM)
o Object storage & block storage with automated scaling
o Load balancers, CDNs for performance
• Software & Services
o Managed databases (RDS/Cloud SQL/NoSQL for large-scale ticketing data)
o API gateways for payment & AFCS integration
o Cloud monitoring & logging services
• Security
o End-to-end encryption (TLS 1.2/1.3)
o Compliance with CERT-In, ISO 27001, PCI-DSS for payment data
o Cloud-native IAM & zero-trust policies
• Operational Advantages
o On-demand scaling based on commuter load (e.g., festival/holiday rush)
o Built-in disaster recovery across regions
o Pay-as-you-go model reduces CAPEX
18.23 Server Configuration
18.24 Verification and Compliance
(1) The Authority reserves the right to:
a. Audit data standards compliance
b. Validate data latency and quality
c. Inspect interface implementations
(2) Non-compliance with data ownership, standards, or privacy requirements shall be treated as a material breach of contract.
18.25 Survival of Obligations
Obligations relating to:
(1) Data ownership
(2) Data privacy
(3) Interface documentation
(4) Data handover shall survive expiry or termination of the Contract.
19.NETWORKS, HOSTING HARDWARE, AND SOFTWARE
19.1 Network Requirements (SLA-Driven)
(1) All bidders shall propose end-to-end network architecture required for ITS operations, covering:
a. Vehicle-to-server communication
b. Depot and terminal connectivity
c. Command & Control Centre (CCC) connectivity
d. Integration with external systems and stakeholders
(2) Network requirements shall be proposed by the bidder based on the Service Level Agreements (SLAs) specified in this RFP, including but not limited to:
a. System availability and uptime
b. Data latency and refresh rates
c. Real-time monitoring requirements
d. Incident and alert response times
(3) The bidder shall clearly specify:
a. Bandwidth requirements (per vehicle, depot, and CCC)
b. Redundancy and failover mechanisms
c. Network security controls (encryption, firewalls, VPNs)
d. Assumptions and dependencies on telecom service providers
(4) The bidder shall be responsible for ensuring that the proposed network design is adequate to meet all SLAs. Any shortfall in performance due to network design shall be the responsibility of the bidder.
(5) Connectivity Requirements for Vehicle Location Tracking Device (VLTD)
Primary Network: 4G LTE (with 2G/3G fallback)
SIM Type: M2M/IoT SIM
Data Usage: Approx. 300–500 MB per vehicle per month (based on 10–30 sec tracking interval)
(6) Connectivity Requirements for Electronic Ticketing Machine (ETIM)
Primary Network: 4G LTE
Fallback: 3G/2G
Data Usage: 500–1028 MB per device per month (based on ticket sync frequency)
Real-Time Sync: Every transaction or batch sync every 5–10 minutes
(1) The ITS solution shall support flexible hosting options, including:
a. Cloud-based deployment
b. On-premise deployment
c. Hybrid deployment
(2) The bidder shall clearly specify the proposed hosting model and justify its suitability with respect to:
a. Performance and scalability
i. Data security and privacy
ii. Availability and disaster recovery
iii. Compliance with Government of India data hosting policies
b. For cloud-based hosting:
i. Data centers shall be located in India
ii. Hosting shall comply with applicable Government guidelines on data sovereignty
iii. Adequate disaster recovery and backup mechanisms shall be provided
c. For on-premise hosting:
i. Servers, storage, and networking equipment shall be OEM-certified and scalable
ii. High availability and redundancy shall be ensured
iii. Detailed infrastructure specifications shall be provided
(3) The Authority reserves the right to decide the final hosting model based on technical and commercial evaluation.
19.3 Approach to Determining Cloud Requirements
(1) The bidder shall provide a structured approach for determining cloud infrastructure requirements, including:
a. Expected number of vehicles, users, and concurrent sessions
b. Data ingestion rates from field devices
c. Storage requirements (operational and archival)
d. Reporting, analytics, and dashboard workloads
(2) The bidder shall submit a Cloud Sizing and Capacity Plan covering:
a. Compute, storage, and network resources
b. Peak vs average load assumptions
c. Auto-scaling and elasticity mechanisms
d. Backup, retention, and disaster recovery strategy
(3) The sizing shall be:
e. Aligned with SLA requirements
f. Scalable for future expansion as defined in the RFP
g. Transparent, with assumptions clearly documented
(4) Under-provisioning or incorrect sizing leading to SLA breaches shall be treated as bidder responsibility, without additional cost to the Authority.
19.4 Software Architecture Considerations
(1) The ITS software shall be designed for:
a. Horizontal and vertical scalability
b. Modular deployment
c. Stateless services where feasible
(2) Software shall be deployable across:
a. Different cloud service providers
b. Standard on-premise infrastructure without requiring re-engineering or license changes.
19.5 Verification and Compliance
(1) The Authority reserves the right to:
a. Seek clarification or revisions to proposed network and hosting architecture
b. Validate sizing assumptions during implementation
c. Conduct audits or performance tests post-deployment
(2) Any deviation from approved network or hosting architecture shall require prior written approval of the Authority.
19.6 No Vendor Lock-In
(1) The proposed network, hosting, and software architecture shall not result in:
a. Dependency on a single cloud service provider
b. Restriction on migration between cloud and on-premise environments
(2) The bidder shall support migration or change in hosting model, if required by the Authority, as per change management provisions.
20.KEY PERSONNEL
20.1 Positions Identified for Operations and Maintenance Team
20.2 Initial Composition; Full Time Obligation; Continuity of Personnel
(1) The bidder shall ensure that each member of the Key Personnel devotes substantial working time to perform the services to which that person has been assigned as per the proposal.
(2) The bidder shall use commercially reasonable efforts to ensure it retains the services of its Key Personnel, including provisioning of competitive compensation, benefits and other conditions to its Key Personnel so as to incentivize them to remain in 's employment.
(3) The bidder shall not make any changes to the composition of the Key Personnel and not require or request any member of the Key Personnel to cease or reduce his or her involvement in the provision of the services during the Term:
a. unless that person resigns, is terminated for cause, dies, is long-term disabled, is on permitted mandatory leave under Applicable Law or retires; or
b. without PUBLIC TRANSPORT AUTHORITY's prior written consent.
(4) The bidder shall promptly notify PUBLIC TRANSPORT AUTHORITY of its intention to rehire
any member of the Key Personnel who had resigned from the bidder in the previous 12month period. PUBLIC TRANSPORT AUTHORITY shall have the right to request that any member of the Key Personnel who resigns and is re-hired by bidder within 12 months of the resignation date be re-assigned to the provision of the services.
20.3 Evaluations
(1) The bidder shall carry out an evaluation of the performance of each member of the Key Personnel in connection with the services at least once in each Contract Year. Bidder shall provide reasonable written notice to PUBLIC TRANSPORT AUTHORITY of the date of each evaluation of each member of the Key Personnel and PUBLIC TRANSPORT AUTHORITY shall be entitled to provide the bidder with input for each such evaluation.
(2) The bidder shall promptly provide the results of each evaluation to PUBLIC TRANSPORT AUTHORITY, subject to Applicable Law.
20.4 Replacement
(1) In case the resource has resigned then the Bidder has to inform within one week of such resignation.
(2) The bidder shall promptly initiate a search for a replacement and use commercially reasonable efforts (including the expenditure of reasonable sums, such as to engage the services of a recruiting firm) to ensure that the role of any member of the Key Personnel is not vacant for any longer than 7 days, subject to reasonable extensions requested by the bidder and approved by the PUBLIC TRANSPORT AUTHORITY.
(3) Before assigning any replacement member of the Key Personnel to the provision of the Services, bidder shall provide PUBLIC TRANSPORT AUTHORITY with:
a. a resume, curriculum vitae and any other information about the candidate that is reasonably requested by PUBLIC TRANSPORT AUTHORITY; and
b. an opportunity to interview the candidate.
(4) If PUBLIC TRANSPORT AUTHORITY does object to theappointment, bidder shall not assign the individual to that position and shall seek an alternative candidate in accordance with this Section.
(5) The Bidder has to ensure at least 4 weeks of overlap period in such replacements.
20.5 Reducing Attrition
(1) In any rolling 12-month period during the Operation and Maintenance phase, 15 percent or more of the members of the Key Personnel cease or reduce their involvement in the Services for any reason other than with PUBLIC TRANSPORT AUTHORITY's prior written consent, bidder shall:
a. provide PUBLIC TRANSPORT AUTHORITY with a reasonably detailed explanation as to the reasons for such change, including, where applicable and permitted, notes from any exit interviews conducted by bidder with any departing member of the Key Personnel; and
b. if such change to Key Personnel has or is likely to have any material adverse impact on the provision of the Services or any substantial part thereof, undertake, at its own costs, such remediation acts as are reasonably necessary in order to improve the retention of the Key Personnel including making reasonable changes to the human resources policies and procedures applicable to the Key Personnel (including those related to compensation, benefits and other conditions so that they are competitive with the market) as may be necessary to ensure that such policies and procedures comply with Good Industry Practice.
21.MINIMUM QUALIFICATIONS FOR THE MANPOWER
Sr. No.
1. Project Director
2. Technical Team Lead
• MBA & B.Tech / B.E./M.Tech/MCA or equivalent from a recognized institute with minimum 15 years of experience.
• At least 8 years of relevant experience in handling IT/ITS projects at union/state level.
• MBA & B.Tech / B.E./M.Tech/MCA or equivalent from a recognized institute with minimum 10 years of experience.
• At least 6 years of relevant experience in handling ITS projects.
• Should have experience in solution design, development, and implementation of public transport operations and management
• Should have project management experience.
• MBA & B.Tech / B.E./M.Tech/MCA or equivalent from a recognized institute with minimum 8 years of experience.
3. Senior public transport planner
• At least 5 years of relevant experience in handling ITS projects.
• Should have experience in planning, designing, optimizing, and managing urban and intercity transport.
• B.Tech / BE/M.Tech in IT/ CS/ECE or MCA or M.Sc. in IT/CS or equivalent with minimum of 6 years of work experience in software development (web and mobile).
4. Senior DevOps Engineer
5. DevOps Engineer
• At least 4 years of relevant experience in software deployment in cloud infrastructure.
• Experience in, dockers/container-based development projects.
• Experience in API development and management.
• B.Tech / BE/M.Tech in (IT/ CS/ECE) or MCA or equivalent with minimum of 3 years of work experience in software development (web and mobile).
• At least 1.5 years of relevant experience in software application development.
• Experience in application testing, bug fixing, patch upgrading, API development, etc.
6. Cloud Expert
• B.Tech / BE /M.Tech in IT/CS/ECE or MCA or equivalent with minimum 10 years of experience in cloud platforms
7. Database Admin
such as AWS, Azure, Google etc. with relevant certification.
• At least 6 years of relevant experience in handling cloudbased solution.
• Experience with cloud or on-premises migration tools and strategies.
• Relevant certificate in cloud infrastructure.
• B.Tech / BE /M.Tech in IT/CS/ECE or MCA or M.Sc. in IT/CS equivalent with Certified Database Administrator having minimum of 10 years of work experience as a database expert/database engineer/ database admin.
• At least 6 years of relevant experience in handling database, query optimization, database performance tuning etc.
• Experience in database management activities like SQL queries, instance tuning, schema management, space management, backup and recovery, disaster recovery, data replication, database refresh etc.
• B.Tech / BE /M.Tech in IT/CS/ECE or MCA or equivalent with minimum 10 years of experience in IT sector.
8. Integration Expert
9. Data Analytics Expert
• At least 6 years of relevant experience in developing and managing internal and external integration at device level, software level through API, protocol and web sockets etc.
• B.Tech / BE/M.Tech in IT/CS/ECE or MCA or M.Sc. in IT/CS orequivalent withminimum 10 yearsof experience in Data Analytics, data warehouse.
• At least 6 years of relevant experience in data modelling, visualization, data analytics.
• Experience in data visualization tools with modelling.
• Experience in analytical solution building.
• Experience in integration and data loading from other solutions into analytic platforms. Understanding Extract, Transform and Load functions.
• B.Tech / BE /M.Tech in IT/CS/ECE or MCA or M.Sc. in IT/CS or equivalent with minimum 10 years of experience in Information/data security.
10. Cyber Security
• At least 6 years of relevant experience in data security, vulnerabilities identification and rectification.
• Experience in identification and fixing security breach.
• Understanding security tests for vulnerabilities.
• Understanding IT trends and security standards.
• Relevant certificate in cyber security.
11. Trainers
12. Helpdesk Executives
• B.Tech / BE/M.Tech in IT/CS/ECE or MCA or M.Sc. in IT/CS or equivalent with minimum 6 years of experience in training/change management.
• At least 4 years of relevant experience in user training, user assessment, manual and presentation preparation for training.
• Technical knowledge of domain for training.
• Experience in presentation/charts/graphs preparation.
• Good communication skills.
• B.Tech/BE/MCA/BCA or equivalent with minimum 3 years of experience in IT sector.
• Should have experience in customer support management.
• B.Tech / BE/M.Tech in IT/CS/ECE or MCA or M.Sc. in IT/CS or BCA or equivalent with minimum 6 years of experience in IT sector.
13. City Coordinator
• At least 4 years of relevant experience in monitoring operations of IT solutions and providing troubleshooting support.
• Should have skills including stakeholder management, reporting, documentation and presentation.
22.OTHER CONDITIONS
22.1 Interpretation
In this Tender unless a contrary intention is evident:
(1) Unless otherwise specified, a reference to a clause number is a reference to all of its sub-clauses.
(2) Unless otherwise specified, a reference to a clause, sub-clause or section is reference to a clause, sub-clause or section of this Tender including any amendments or modifications to the same from time to time
(3) A word in the singular includes the plural and a word in the plural includes the singular
(4) A word importing a gender includes any other gender
(5) A reference to a person includes a partnership and a corporate body
(6) A reference to legislation includes legislation repealing, replacing, or amending that legislation.
(7) Where a word or phrase is given a meaning, it includes the appropriate grammatical forms of that word or phrase which have corresponding meanings.
22.2 Extension of Timelines
As soon as it is apparent that the Project Timelines cannot be adhered to, an application shall be sent by Selected Bidder to the Authority. If the failure on the part of the Selected Bidder to adhere to the Project Timelines has arisen due to any reason which the Authority may admit as reasonable ground for an extension of the time, the Authority may allow such additional time as it considers to be justified by the circumstances.
22.3 Trademark and Publicity
(1) Neither Party may use the trademarks of the other Party without the prior written consent of the other Party.
(2) Neither Party shall publish nor give permission to publish either along with or in conjunction with any other person any press release, information, article, photograph, illustration, or any other material of whatever kind relating to this Tender, the Agreement, the SLA, or the business of the Parties without prior reference to and approval in writing from the other Party.
22.4 Indemnity
(1) The Parties agree to indemnify each other under the Agreement in accordance with the terms and principles set out.
(2) Either Party shall indemnify the other Party against all actions, suits, claims, damages and demands brought or made against it in respect of anything done or omitted to be done by the first Party in the execution of or in the connection with the Project.
(3) Either Party shall indemnify the other Party against loss or damage to the other Party in consequences of any action or suit being brought against the first Party.
22.5 Termination
(1) Authority reserves the right to terminate the Agreement to be executed with the Selected Bidder, in whole or in part, for convenience or default, by written notice, without any liability other than payment for duly performed and accepted services up to the effective date of termination.
(2) Upon expiry or termination, the Selected Bidder shall provide all data, documentation and technical support for transition to the Authority or its designated agency for a minimum of ninety (90) days at no additional cost.
22.6 Force Majeure
(1) "Force Majeure Event" means any event(s) beyond the reasonable control of the Selected Bidder, such as natural disasters, war, terrorism, epidemics, government embargoes that render delivery of services under the Agreement impossible.
(2) The Selected Bidder shall notify the Authority in writing within five (5) days of occurrence, describing the nature, likely duration and mitigation measures, and shall resume performance as soon as practicable.
22.7 Settlement of Disputes
(1) A Party claiming that a dispute has arisen must give the other Party to the dispute, notice setting out details of the dispute.
(2) During 14 (fourteen) days (or longer if the Parties agree in writing) after a notice is given, each Party to the dispute must use its reasonable efforts to resolve the dispute amicably.
(3) If the Parties cannot resolve the dispute within that period, then any such dispute or difference whatsoever arising between the parties to the Agreement shall be referred to a sole arbitrator to be appointed by mutual consent of both the parties herein.
(4) If the parties cannot agree on the appointment of the arbitrator within a period of 1 (one) month from the notification by one Party to the other of existence of such dispute, then the arbitrator shall be appointed by the High Court of xxx State.
(5) The provisions of the Arbitration and Conciliation Act, 1996 will be applicable and the award made there under shall be final and binding upon the parties hereto, subject to legal remedies available under the law.
22.8 Jurisdiction of Courts
In case of any claim, dispute or difference rising in respect of the Agreement, the case of action there of shall be deemed to have arisen in xxx State and all legal proceedings in respect of any such claim, dispute or difference shall be instituted in competent court in xxx State only.
23.Annexures
Form 1: Compliance in response to eligibility criteria
1 Letter of Proposal
per Form 4 Yes/No
2 Particulars of Bidders As per Form 2 Yes/No
3 Declaration regarding Restrictions on procurement from a Bidder of a country which shares a land border with India.
4 Declaration on No-blacklisting
5 Power of Attorney
4 In case of Consortium/ Joint Venture
1. Power of Attorney for Consortium
2. Authorisation letter
3. Consortium Agreement
per Form 15 Yes/No
per Clause 3.1 and Form 16 Yes/No
per Form 9 Yes/No
4. Letter of consent from consortium members 1. As per Form 11 2. As per Form 12 3. As per Form 13 4. As per Form 14 Yes/No
5 Debarment
Form 2: Particulars of Bidder
Sr. No. Information Sought
A. Name and address of the bidding Company
B. Incorporation status of the firm! (public limited / private limited, etc.)
C. Year of Establishment
D. Date of registration
E. ROC Reference No.
F. Details of company registration
G. Details of registration with appropriate authorities for service tax
H. Name, Address, email, Phone nos. and Mobile Number of Contact Person
Details to be furnished
To, CGM
[ADDRESS]
Form 3: Bank Guarantee for EMD
Whereas <<name of the Bidder» (hereinafter called 'the Bidder') has submitted the bid for Submission of RFP # <<RFP. Number»> dated <<insert date>> for <<name of the assignment>> (hereinafter called "the Bid") to <PUBLIC TRANSPORT AUTHORITY>
Know all Men by these presents that we << >> having our office at <<Address>> (hereinafter called "the Bank") are bound unto the < PUBLIC TRANSPORT AUTHORITY > (hereinafter called "the Purchaser") in the sum of Rs. <<Amount in figures>> (Rupees <<Amount in words>> only) for which payment well and truly to be made to the said Purchaser, the Bank binds itself, its successors and assigns by these presents.
Sealed with the Common Seal of the said Bank this <<insert date>>
The conditions of this obligation are:
1. If the Bidder having its bid withdrawn during the period of bid validity specified by the Bidder on the Bid Form; or
2. If the Bidder, having been notified of the acceptance of its bid by the Purchaser during the period of validity of bid
(a) Withdraws his participation from the bid during the period of validity of bid document; or
(b) Fails or refuses to participate for failure to respond in the subsequent Tender process after having been short listed.
We undertake to pay to the Purchaser up to the above amount upon receipt of its first written demand, without the Purchaser having to substantiate its demand, provided that in its demand the Purchaser will note that the amount claimed by it is due to it owing to the occurrence of one or both of the two conditions, specifying the occurred condition or conditions.
This guarantee will remain in force up to <<insert date> and including <<extra time over and above mandated in the RFP>> from the last date of submission and any demand in respect thereof should reach the Bank not later than the above date.
Notwithstanding anything contained herein:
I. Our liability under this Bank Guarantee shall not exceed Rs. <<Amount in figures>> (Rupees <<Amount in words>> only)
Il. This Bank Guarantee shall be valid up to <<insert date>>)
IlI. It is condition of our liability for payment of the guaranteed amount or any part thereof arising under this Bank Guarantee that we receive a valid written claim or demand for payment under this Bank Guarantee on or before <<insert date>>) failing which our liability under the guarantee will automatically cease.
(Authorized Signatory of the Bank)
Seal:
Date:
Attachment -I to Form 3
Form 4: Letter of Technical Proposal
To, CGM [ADDRESS]
Subject: Submission of the technical proposal for Request for Proposal for selection of system integrator for design, development, operations, and maintenance of ITS procured by PUBLIC TRANSPORT AUTHORITY
Dear Sir/Madam,
We, the undersigned, offer to provide Systems Implementation solutions to PUBLIC TRANSPORT AUTHORITY in response to Request for Proposal, for selection of system integrator for design, development, operations, and maintenance of ITS procured, dated <insert date>.
We are hereby submitting our Proposal, which includes our response to the eligibility criteria, technical evaluation criteria and financial proposal.
We hereby declare that all the information and statements made in this proposal are true and accept that any misinterpretation contained in it may lead to our disqualification. We understand that by submitting this proposal, it is deemed to be agreed that our solution shall comply with policy on Open Application Programming Interfaces (APIs) for Government of India and associated guidelines during the entire contract tenure.
We undertake, if our Proposal is accepted, to initiate the Implementation services related to the assignment not later than the date indicated in Fact Sheet.
We agree to abide by all the terms and conditions of the RFP document. We would hold the terms of our bid valid for <180> days as stipulated in the RFP document.
We understand you are not bound to accept any Proposal you receive. Yours sincerely,
Authorized Signature [In full and initials]:
Name and Title of Signatory:
Name of Firm:
Address:
Location:
Date:
Form 5: Proposed Work Plan
(1) Indicate all main activities of the assignment, including delivery of reports (e.g.: inception, interim, and final reports), and other benchmarks such as PUBLIC TRANSPORT AUTHORITY approvals. For phased assignments indicate activities, delivery of reports, and benchmarks separately for each phase.
(2) Duration of activities shall be indicated in the form of a bar chart.
Form 6: Approach and Methodology
Approach & Methodology document should consist of Maximum 35 pages and should cover the following points.
(1) Understanding of the PUBLIC TRANSPORT AUTHORITY’s requirement,
(2) Proposed solution, Technologies and Innovation,
(3) Key considerations from similar implementations,
(4) Understanding of Open API and Open Data guidelines,
(5) Work plan.
Form 7: Letter of Financial Proposal
To, < Date>
CGM [ADDRESS]
Subject: Submission of the financial proposal/bid for Request for Proposal for selection of system integrator for design, development, operations, and maintenance of ITS for PTA
Dear Sir/Madam,
We, the undersigned, offer to provide this proposal in response to Request for Proposal for selection of system integrator for design, development, operations, and maintenance of ITS for PTA dated «Date». Our attached Financial Proposal is for the sum of «Amount in words and figures». This amount is inclusive of the local taxes.
1. PRICE AND VALIDITY
All the prices mentioned in our proposal are in accordance with the terms as specified in the RFP documents. All the prices and other terms and conditions of this Bid are valid for a period of 180 calendar days from the date of opening of the Bid.
We hereby confirm that our prices include all taxes. However, all the taxes are quoted separately under relevant sections.
We understand that the actual payment would be made as per the existing tax rates during the time of payment.
2. UNIT RATES
We have indicated in the relevant forms enclosed, the unit rates for the purpose of on account of payment as well as for price adjustment in case of any increase to / decrease from the scope of work under the contract.
3. TENDER PRICING
We further confirm that the prices stated in our bid are in accordance with your Instruction to Bidders included in Tender documents.
4. QUALIFYING DATA
We confirm having submitted the information as required by you in your Instruction to Bidders. In case you require any other further information/documentary proof in this regard before evaluation of our Tender, we agree to furnish the same in time to your satisfaction.
5. BID PRICE
We declare that our Bid Price is for the entire scope of the work as specified in the Section 5 of the RFP. These prices are indicated Commercial Bid attached with our proposal as part of the Tender.
6. PERFORMANCE BANK GUARANTEE
We hereby declare that in case the contract is awarded to us, we shall submit the Performance Bank Guarantee as specified in the Form 16 of this RFP document.
Our Financial Proposal shall be binding upon us subject to the modifications resulting from Contract negotiations, up to expiration of the validity period of the Proposal, i.e., [Date].
We understand you are not bound to accept any Proposal you receive.
We hereby declare that our proposal is made in good faith, without collusion or fraud and the information contained in the proposal is true and correct to the best of our knowledge and belief.
We understand that our proposal is binding on us and that you are not bound to accept a proposal you receive.
Thanking you,
We remain, Yours sincerely,
Authorized Signature:
Name and Title of Signatory:
Name of Firm:
Address:
Form 8: Financial Proposal
1 Development (as per Table F1)
2 Deployment (as per Table F2)
3 Implementation (as per Table F3)
4 Operations and Maintenance for ten years (as per Table F4)
GRAND TOTAL (to be considered to arrive at financial score)
Table F2: Deployment Cost
Table F5: Man-month cost for software developer to incorporate change request/s (Not considered to arrive at financial score)
1 Man-month cost for software developer to incorporate change request/s Man Month 1
Note:
1. The prices quoted shall be valid for quantities specified +/- 50%.
2. The O&M (as per table F4) cost should not be more than 60% of the grand total of financial proposal.
3. For any of the ten years of O&M, per year cost should be at least 10% of the grand total of financial proposal.
4. The delivery of buses and ETM will be in a staggered manner in any year and payment will be made as per actual no. of buses and ETMs active during the given year. Overall O&M period shall remain 10 years irrespective of no. of buses or ETMs activated.
Form 9: Power of Attorney
(To be on non-judicial stamp paper of appropriate value as per Stamp Act relevant to place of execution)
Know all men by these presents, We ......................................................... (name and address of the registered office of the Bidder) do hereby constitute, appoint and authorize Mr./Ms……………………………………………… (name and residential address) who is presently employed with us and holding the position of as our attorney, to do in our name and on our behalf, all such acts, deeds and things necessary in connection with or incidental to our Bid for Request for Proposal (RfP) for <RfP Name> (Bid Document No. dated ), including signing and submission of all documents related to the Bid, including, undertakings, letters, certificates, acceptances, clarifications, guarantees, etc., making representations to the PUBLIC TRANSPORT AUTHORITY, and providing information / responses to the PUBLIC TRANSPORT AUTHORITY, representing us in all matters before the PUBLIC TRANSPORT AUTHORITY, and generally dealing with the PUBLIC TRANSPORT AUTHORITY in all matters in connection with our Bid for the said Project till the completion of the bidding process in accordance with the RfP.
We hereby agree to ratify all acts, deeds and things lawfully done by our said attorney pursuant to this Power of Attorney and that all acts, deeds and things done by our aforesaid attorney shall and shall always be deemed to have been done by us.
All the terms used herein but not defined shall have the meaning ascribed to such terms under the RfP.
For [Insert name of the Bidder on whose behalf PoA is executed]
We hereby declare that we have completely read & understood the above bid Document (s) including the RFP <> and Corrigendum /Addendum (if any), Pre Bid Meeting Minutes (if any) & Technical, Functional and Integration Specifications/Scope of Work etc. given in the tender and Confirm NIL deviation with respect to it andshallcomply with all Commercial/technical specifications and scope given in the tender in toto.
Name and Title of Signatory: Name of Firm:
Address:
Form 11: Power of Attorney for Consortium
To be provided by each of the other members of the consortium in favour of the lead member
(To be on non-judicial stamp paper of appropriate value as per Stamp Act relevant to place of execution)
KNOW ALL MEN BY THESE PRESENTS THAT M/s……………………… having its registered office at ………………………………………… and M/s………………………….…. having its registered office at …………………………………………… (Insert names and registered offices of all Members of the Consortium), the Members of Consortium, have formed a Bidding Consortium named …………. (insert name of the Consortium) (hereinafter called the “Consortium”) vide Consortium Agreement dated……….………… and having agreed to appoint M/s………………………………………………as the Lead Member of the said Consortium do hereby constitute, nominate and appoint M/s………………a company incorporated under the laws of ……….………and having its Registered / Head Office at as our duly constituted lawful Attorney (hereinafter called as “Lead Member”) which is one of the Members of the Consortium, to act as the Lead Member and our true and lawful attorney, to do in our name and on our behalf, all such acts, deeds and things necessary in connection with or incidental to submission of Consortium's Bid for the Bid for Request for Proposal (RfP) <RFP Name> (Bid Document No. dated ),, including signing and submission of the Bid and all documents related to the Bid, including, undertakings, letters, certificates, acceptances, clarifications, guarantees, etc, making representations to the PUBLIC TRANSPORT AUTHORITY, and providing information / responses to the PUBLIC TRANSPORT AUTHORITY, representing us and the Consortium in all matters before the PUBLIC TRANSPORT AUTHORITY, and generally dealing with the PUBLIC TRANSPORT AUTHORITY in all matters in connection with our Bid for the said Project, till completion of the bidding process in accordance with the RfP.
It is expressly understood that in the event of the Consortium being selected as Successful Bidder, this Power of Attorney shall remain valid, binding and irrevocable until the Consortium achieves execution of Concession Agreement, through its SPV.
We, as the Member of the Consortium, agree and undertake to ratify and confirm all whatsoever the said Attorney/Lead Member has done on behalf of the Consortium Members pursuant to this Power of Attorney and the same shall bind us and deemed to have been done by us.
All the terms used herein but not defined shall have the meaning ascribed to such terms under the RfP.
IN WITNESS WHEREOF M/s …………….. as the Member of the Consortium have executed these presents on this…………. day of …………
For and on behalf of Consortium
(Signature of the Authorized Signatory)
Name: …………………………..
Designation:
Place:
Name:
Designation:
Place:
Accepted
Specimen signatures of attorney attested.
………………………..(Signature)
(Signature of Notary Public) ………………………
(Name, Designation and
Address of the Attorney)
Place: …………………….. Date: …………………….
Notes:
The mode of execution of the power of attorney should be in accordance with the procedure, if any, laid down by the applicable law and the charter documents of the executant(s) and when it is so required, the same should be under common seal of the executant affixed in accordance with the applicable procedure.
Further, the person whose signatures are to be provided on the power of attorney shall be duly authorized by the executant(s) in this regard.
Also, wherever required, the executant(s) should submit for verification the extract of the charter documents and documents such as a Board resolution / power of attorney, in favour of the Person executing this power of attorney for delegation of power hereunder on behalf of the executant(s).
Form 12: Authorization
(In case of Consortium, to be given separately by each Member)
(To be on non-judicial stamp paper of appropriate value as per Stamp Act relevant to place of execution) and duly attested by notary public)
The undersigned hereby authorize(s) and request(s) all our Bankers, including its subsidiaries and branches, any person, firm, corporation or authority to furnish pertinent information deemed necessary and requested by PUBLIC TRANSPORT AUTHORITY to verify our Bid for Request for Proposal (RfP) <RFP Name> under PM-eBus Sewa or regarding our project development experience, financial standing and general reputation.
For and on behalf of M/s…………………….. (Insert Name of Bidder or Member of the Consortium)
(Signature)
Name of Authorized Signatory:
(Signature and Name of the authorized signatory of the Company)
Place: ………………………… Date: ……………………
(Company rubber stamp/seal)
…………………………………. (Signature of Notary Public)
Place: ………………………… Date: ……………………
Form 13: Consortium Agreement
(To be on non-judicial stamp paper of appropriate value as per Stamp Act)
THIS CONSORTIUM AGREEMENT executed on this....................... day of two thousand.................. between M/s................................................................, a company incorporated under the laws of ...................................... and having its Registered Office at.....................(hereinafter called the "Party 1”, which expression shall include its successors, executors and permitted assigns) and M/s………a Company incorporated under the laws of ......................................................... and having its Registered Office at ................................... (hereinafter called the "Party 2", which expression shall include its successors, executors and permitted assigns) and for the purpose of submitting the Bid, executing the Project (in case of award) and entering into other Agreement(s) as specified in the RfP (hereinafter referred to as “Agreements”) as may be entered into with the PUBLIC TRANSPORT AUTHORITY and Authority.
WHEREAS, the PUBLIC TRANSPORT AUTHORITY had invited Bid in response to RfP issued to …………… (insert the name of purchaser of RfP) for Request for Proposal (RfP) for <RFP Name>
AND WHEREAS, Clause 8.2 of the RfP document stipulates that the Bidders qualifying on the strength of a Consortium will have to submit a legally enforceable Consortium Agreement in a format specified in the RfP document wherein the Consortium Members have to commit equity of a specific percentage in the Project.
NOW THEREFORE, THIS INDENTURE WITNESS AS UNDER:
In consideration of the above premises and agreement all the parties in this Consortium do hereby mutually agree as follows:
1) In consideration of the selection of the Consortium as the selected bidder by the PUBLIC TRANSPORT AUTHORITY, we the Members of the Consortium and parties to the Consortium Agreement do hereby unequivocally agree that M/s. (Insert name of the Lead Member), shall act as the Lead Member as defined in the RfP for self and agent for and on behalf of .................., .............., (the names of all the other Members of the Consortium to be filled in here).
2) The Lead Member is hereby authorized by the Members of Consortium and parties to the Consortium Agreement to bind the Consortium and receive instructions for and on behalf of the Member
3) Notwithstanding anything contrary contained in this Consortium Agreement, the Lead Member shall always be liable for the equity investment obligations of all the Consortium Members, i.e., for both its own equity contribution as well as the equity contribution of other Members.
4) The Lead Member shall be liable and responsible for ensuring the individual and collective commitment of each of the Members of the Consortium in discharging all their respective equity obligations. Each Consortium Member further undertakes to be individually liable for the performance of its part of the obligations without in any way limiting the scope of collective liability envisaged in this agreement.
5) Subject to the terms of this agreement, the share of each Member of the Consortium in the “issued equity share capital of the SPV” shall be in the following proportion: (if applicable)
[Note: The percentage equity holding for any Consortium Member in the Project cannot be zero in the above table]
6) The Lead Member shall inter alia undertake full responsibility for liaising with lenders and mobilizing debt resources for the Project and achieving financial closure.
7) In case of any breach of any of the equity investment commitment by any of the Consortium Members, the Lead Member shall be liable for the consequences thereof.
8) Except as specified in the Agreement, it is agreed that sharing of responsibilities as aforesaid and equity investment obligations thereto shall not in any way be a limitation of responsibility of the Lead Member under these presents.
9) It is further specifically agreed that the financial liability for equity contribution of Lead Member shall, not be limited in any way so as to restrict or limit its liabilities. The Lead Member shall be liable irrespective of their scope of work or financial commitments.
10) It is expressly understood and agreed between the Members that the responsibilities and obligations of each of the Members shall be as delineated as annexed hereto as Attachment - I to this Consortium Agreement, forming integral part of this Agreement. It is further agreed by the Members that the above sharing of responsibilities and obligations shall not in any way be a limitation of joint and several responsibilities and liabilities of the Members, with regards to all matters relating to the Project.
11) It is clearly agreed that the Lead Member shall ensure performance under the Agreements and if one or more Consortium Members fail to perform its /their respective obligations under the Agreement(s), the same shall be deemed to be a default by all the Consortium Members.
12) This Consortium Agreement shall be construed and interpreted in accordance with the Laws of India and courts at Delhi alone shall have the exclusive jurisdiction in all matters relating thereto and arising there under.
13) It is hereby agreed that the Lead Member shall furnish the bid security, on behalf of the Consortium Members.
14) It is hereby agreed that in case of selection of Consortium as the Selected bidder, the parties to this
Consortium Agreement do hereby agree that they shall furnish the Performance security in favor of the Authority, as stipulated in the RfP and Concession Agreement.
15) It is further expressly agreed that the Consortium Agreement shall be irrevocable and shall form an integral part of the RfP Document and shall remain valid till the execution of the Concession Agreement, unless expressly agreed to the contrary by the PUBLIC TRANSPORT AUTHORITY.
16) It is hereby agreed that in case of selection of Consortium as the Selected bidder, the members of the Consortium shall form an SPV (Project Implementing Entity) to execute the Concession Agreement and implement the Project. The OEM or its Associate whose technical capacity has been used to fulfill the Technical Qualification Criteria shall mandatorily hold minimum 26% subscribed and paid-up equity share capital in the SPV, throughout the period of the Agreement.
17) The Lead Member is authorized and shall be fully responsible for the accuracy and veracity of the representations and information submitted by the Consortium Members respectively from time to time in response to the RfP and for the purposes of the Project.
18) It is hereby expressly agreed between the parties to this Consortium Agreement that neither party shall assign or delegate its rights, duties or obligations under this Agreement except with the prior written consent of the PUBLIC TRANSPORT AUTHORITY.
THIS CONSORTIUM AGREEMENT:
1) has been duly executed and delivered on behalf of each party hereto and constitutes the legal, valid, binding and enforceable obligation of each such party, sets forth the entire understanding of the parties hereto with respect to the subject matter hereof
2) may not be amended or modified except in writing signed by each of the parties and with prior written consent of the PUBLIC TRANSPORT AUTHORITY.
IN WITNESS WHEREOF, the parties to the Consortium Agreement have, through their authorized representatives, executed these present on the Day, Month and Year first mentioned above.
For and on behalf of Consortium Member 1 (Party 1)
M/s…………………………. (Signature of authorized signatory)
Name:………………………….
Designation:............………………….
Place: ………………………………..
Date:
For and on behalf of Consortium Member 2 (Party 2)
M/s………………………….(Signature of authorized signatory)
Name:……………………………
Designation:…………………………
Place:……………………………….
Date:………………………………...
Attested:
(Signature) (Notary Public)
Place:……………………….
Date: ……………………….
Attachment-I to Consortium Agreement
Name of the Consortium Member Responsibilities under the Consortium Agreement
M/s (Party 1)
M/s
M/s (Party n)
Form 14: Letter of consent from Consortium Members
(On the letter head of each Member of the Consortium including Lead Member)
We, the undersigned Member of (Insert name of the Bidding Consortium) have read, examined, and understood the document for “Request for Proposal (RfP) <RFP Name>. We hereby confirm our concurrence with the Bid including in particular the Consortium Agreement submitted by (Insert name of the Lead Member) in response to the RfP document.
We hereby confirm our commitment to participate in the said Bidding Consortium and invest……. % of the total equity requirement for the Project as per the terms of the Consortium Agreement dated and board resolution for such investment commitment is enclosed herewith.
We hereby confirm that in accordance with Clause xxx of the RfP, we are enclosing a legally binding board resolution from the (Insert name of Parent Company/Associate, as the case may be) that all the equity investment obligations of (Insert name of the Member) shall be deemed to be equity investment obligations of the......................... (Insert name of Parent Company/Associate, as the case may be) and in the event of any default by…(Insert name of the Member), the same shall be met by………………. (Insert name of Parent company/Associate, as the case may be). [Insert if applicable]
[To be inserted by the Lead Member only] We are also enclosing legally binding board resolution for the total equity requirement of the Project in case of any breach of any of the equity investment commitment by any of the Consortium Members, in line with the provisions of the Consortium Agreement dated [Bidder to insert date of Consortium Agreement].
The details of contact person are furnished as under:
(Signature, Name, Designation of Authorized Signatory of Consortium Member and Company's Seal)
Form 15: Compliance for Land Border Restrictions
Declaration regarding "Restrictions on procurement from a Bidder of a country which shares a land border with India"
(To be submitted on Bidder's Letter Head)
To, CGM [Address]
Dear Sir/Madam,
I have read and understood the provisions of order no. F.7/10/2021-PPD (1) Dated 23.02.2023 regarding "Exclusions from Restriction under Rule 144(xi) of General Financial Rules" issued by Public Procurement Division, Department of Expenditure, Ministry of Finance, Government of India [hereinafter collectively "DoE Order"].
AND
I have read and understood the clause regarding restrictions on procurement from a 'Bidder of a country which shares a land border with India' and on sub-contracting to contractors from such countries.
AND
I certify that this bidder is not from such a country or, if from such a country, has been registered as per provisions of the requisite Order/Circular/Document with the Competent Authority and will not subcontract any work to a subcontractor/sub vendor from such countries unless such contractor is registered with Competent Authority. I hereby certify that this bidder fulfils all requirements in this regard and is eligible to be considered. [Where applicable, evidence of valid registration by the Competent Authority shall be attached.]
AND
I have read the clause regarding restrictions on procurement from a Bidder having Transfer of Technology (ToT) arrangement. I certify that this Bidder does not have any ToT arrangement registration with competent authority OR " I have read the clause regarding restriction on procurement from a Bidder having transfer of Technology (ToT) arrangement. I certify that this Bidder has valid registration to participate in this procurement."
AND
"I certify that the (product/service)" for supplied, installed, commissioned under this procurement would not be from such a country or, if from such a country, has been registered with the Competent Authority. I hereby certify that the......... (product/services)" for supplied under this procurement fulfils all requirements in this regard and is eligible to be considered. [Where applicable, evidence of valid registration by the Competent Authority shall be attached.]
I further declare that any misrepresentation or submission of false/forged document/information in this regard shall be dealt with as per the provisions of RFP Documents and/or PUBLIC TRANSPORT AUTHORITY's policy and procedures.
Date:
Place: Seal of Organization & Signature of Authorized Applicant
Form 16: Format of No Blacklisting Certificate
{Notarization is required}
Format of self-certificate stating that the Entity/Promoter/s / Director/s of Entity are not blacklisted (To be on non-judicial stamp paper of appropriate value as per Stamp Act)
[All Consortium Members should provide in case Bidder is a Consortium]
M/s ........................ (Name of the Bidder), (the names and addresses of the registered office)hereby certify and confirm that we or any of our promoter/s / director/s (not barred by Government of India (GoI)/ any state government/ any other entity of Central or State Govts or blacklisted by any State Government or Central Government / Department / Local Government Agency in India or similar agencies from foreign countries from participating in Project/s, either individually or as member of a Consortium.
We further confirm that we are aware that our Bid for the Project would be liable for rejection in case any material misrepresentation is made or discovered with regard to the requirements of this RFP at any stage of the Bidding Process or thereafter during the agreement period.
Dated this ............................................................ Day of……………………………(Year).
Signature of bidder with stamp & Address
Form 17: Compliance Sheet as per Technical Evaluation
Criteria
1. Experience of implementing largescale IT solution for government/PSUs/large enterprises in India/abroad.
2. Experience of implementing any of following module/s as part of Integrated/Intelligent Transport Management System/AFCS project for government/PSUs/large enterprises in India/abroad.
• Automatic Fare Collection System (AFCS)
• Automatic Vehicle Location System (AVLS)
• Passenger Information System (PIS)
3. In any of the project/s proposed against criterion 2 above, the bidder/ any member in case of consortium should have experience of implementing any of following module/s:
• Incident Management System (IMS)
• Mobile Application
4. Experience of integrating hardware devices of multiple make and model for any Information Technology/Operational Technology (IT/OT) projects in field of transport/logistics/smart- city for government/PSUs/large enterprises in India/abroad.
5. Approach & Methodology
As per Clause 3.3 and Form 18 Yes/No
As per Clause 3.3 and Form 18
Yes/No
As per Clause 3.3 and Form 18 Yes/No
As per Clause 3.3 and Form 18
Yes/No
As per Clause 3.3 and Form 6 Yes/No
Form 18: Project Citation Format
Relevant project experience
General Information
Name of the project
Client for which the project was executed
Name and contact details of the client
Project Details
Description of the project
Scope of services
Highlight details complied with respective evaluation criteria
Technologies used
Outcomes of the project
Other Details
Total cost of the project
Duration of the project (no. of months, start date, completion date, current status)
Other Relevant Information
Letter from the client to indicate the successful completion of the projects
Copy of Work Order
To:
Form 19: Format of Performance Guarantee
(PUBLIC TRANSPORT AUTHORITY)
[ADDRESS]
Whereas «name of the supplier and address» (hereinafter called "the Bidder") has undertaken, in pursuance of contract no. <lnsert Contract No.> dated. <Date> to provide Implementation services for in response to Request for Proposal for selection of system integrator for design, development, operations, and maintenance of ITS published by PUBLIC TRANSPORT AUTHORITY (hereinafter called "the beneficiary")
And whereas it has been stipulated by in the said contract that the Bidder shall furnish you with a bank guarantee by a recognized bank for the sum specified therein as security for compliance with its obligations in accordance with the contract.
And whereas we, <Name of Bank> a banking company incorporated and having its head /registered office at <Address of Registered Office> and having one of its offices at <Address of Local Office> have agreed to give the supplier such a bank guarantee.
Now, therefore, we hereby affirm that we are guarantors and responsible to you, on behalf of the supplier, up to a total of Rs.<lnsert Value> (Rupees <lnsert Value in Words> only) and we undertake to pay you, upon your first written demand declaring the supplier to be in default under the contract and without cavil or argument, any sum or sums within the limits of Rs. <lnsert Value> (Rupees <lnsert Value in Words> only) as aforesaid, without your needing to prove or to show grounds or reasons for your demand or the sum specified therein.
We hereby waive the necessity of your demanding the said debt from the Bidder before presenting us with the demand.
We further agree that no change or addition to or other modification of the terms of the contract to be performed there under or of any of the contract documents which may be made between you and the Bidder shall in any way release us from any liability under this guarantee and we hereby waive notice of any such change, addition, or modification.
This Guarantee shall be valid until «Insert Date») Notwithstanding anything contained herein:
I. Our liability under this bank guarantee shall not exceed Rs. <lnsert Value> (Rupees <Insert Value in Words> only).
II. This bank guarantee shall be valid up to <insert Expiry Date>)
III. It is condition of our liability for payment of the guaranteed amount or any part thereof arising, under this bank guarantee that we receive a valid written claim or demand for payment under this bank guarantee on or before (<lnsert Expiry Date>) failing which our liability under the guarantee will automatically cease.
Change Control Note
Part A: Initiation
Title:
Originator:
Sponsor:
Date of Initiation:
Form 20: Format of Change Control Notice
CCN Number:
Details of Proposed Change
(To include reason for change and appropriate details/specifications. Identify any attachments as Al, A2, and A3 etc.)
Authorized by : Date:
Name:
Signature: Received by the IP Date:
Name:
Signature:
Change Control Note
Part B: Evaluation
CCN Number:
(Identify any attachments as Bl, B2, and B3 etc.) Changes to Services, charging structure, payment profile, documentation, training, service levels and component working arrangements and any other contractual issue.
Brief Description of Solution:
Impact:
Deliverables:
Timetable:
Charges for Implementation:
(Including a schedule of payments)
Other Relevant Information:
(Including value-added and acceptance criteria)
Authorized by the Implementation Partner Date:
Name:
Signature:
Form 21: CV of Key Personnel
General Information
Name of the person
Current Designation / Job Title
Current job responsibilities
Proposed Role in the Project
Proposed Responsibilities in the Project
Academic Qualifications:
• Degree
• Academic institution graduated from
• Year of graduation
• Specialization (if any)
• Key achievements and other relevant information (if any)
Professional Certifications (if any)
Total number of years of experience
Number of years with the current company
Number of years in ITS experience
Summary of the Professional / Domain Experience
Number of complete life cycle implementations carried out
The names of customers (Please provide the relevant names)
Past assignment details (For each assignment provide details regarding name of organizations worked for, designation, responsibilities, tenure) Prior Professional Experience covering:
• Organizations worked for in the past
o Organization name
o Duration and dates of entry and exit
o Designation Location(s)
o Key responsibilities
• Prior project experience
o Project name
o Client
o Key project features in brief
o Location of the project
o Designation
o Role
o Responsibilities and activities
o Duration of the project Please provide only relevant projects.
Proficient in languages (Against each language listed indicate if speak/read/write)
Annexure 2: Data Interface Catalogue
(To be submitted by the Bidder along with the Technical Proposal)
Interfaces usable by Authority for future integrations Yes / No
No additional license required for interface usage Yes / No
9. Compliance Statement
We hereby certify that the interfaces described above are based on open standards, are hardwareagnostic, and comply with the requirements specified in the RFP. Any deviation has been clearly disclosed.
Authorized Signatory
Name & Designation
Signature & Seal
Date
Annexure 3: Guideline for ITS Procurement for public bus systems
ITS systems are crucial for several functions of Public Transport Authorities (PTAs) providing bus services including passenger information systems, digital ticketing, performance monitoring and service planning. With the large-scale adoption of electric buses (e-buses) through Gross Cost Contracts (GCC), ITS plays a more prominent role in contract management and payments as well. ITS procurements in India have often failed to deliver their promised benefits for PTAs and their passengers. To avoid repeating the mistakes of the past, we have carried out a thorough review of the existing ITS procurement practices in India and compared them with good practice examples from outside India.
Several recommendations to improve ITS system performance have been identified covering increasing contract tenures, ensuring integration and interoperability between various ITS systems, Data standards, ownership and privacy requirements to be adopted, improved payment and penalty structures, ensuring continuity of systems across successive procurements, improving robustness of contractual specifications and Service Level Agreements (SLAs) etc.
This document is intended to be a brief checklist/ ready reckoner for PTAs, consultants or industry stakeholders working on ITS projects to understand the key features to be included in the Request for Proposal (RfP) for the new ITS system. Further, these recommendations have been incorporated into the typical RfP template followed by Indian PTAs operating/ managing buses and is enclosed with this report.
The key items recommended to be included in ITS RfPs to enhance their effectiveness are listed below. Additional details of contractual specifications to be included against each of these items are provided in the model RfP document released along with this guideline.
1. Scope of Work (Hardware and software requirements to be defined based on the PTA’s requirements)
a. Automatic Vehicle Location System (AVLS)
• Automotive Industry Standard (AIS)-140 compliant Global Positioning System (GPS) devices- for non AIS-140 compliant buses
• Web based software with high resolution GIS maps
• Estimated Time of Arrival (ETA) prediction based on real-time and historic database of GIS data
• Map-based tracking and transit route/line-based tracking of vehicles for control centre operators.
b. Automatic Fare Collection Systems (AFCS)
• Electronic Ticketing Machines (ETMs)
• Contactless smart cards
• Quick Response (QR) code-based paper tickets
• Mobile application-based ticketing using QR codes
• Booking through web portal
c. Passenger Information Systems (PIS)
• PIS display screen at bus stops and on buses
• Transit web portal for bus schedule, ETA and Short Message Services (SMS)
• Information on the mobile app
d. Depot Management System (DMS) and Business Intelligence (BI)
• Automation of depot operations by providing Vehicle dispatch management, Services management, depot operations management, performance reporting, BI dashboards, stores and inventory management
• Generation of relevant performance and Management Information Systems (MIS) reports
e. Contract Management System (CMS)
• Streamline processes related to contract creation/configuration, performance monitoring, invoice generation, payment processing
• Contributing to successful implementation and operation of contracts while ensuring transparency and performance efficiency
f. Vehicle and crew planning and scheduling
• Timetable generation, Vehicle scheduling, crew scheduling, crew rostering, dispatch and daily management of vehicles and crew
g. Incident Management System (IMS)
• Incident detection and management and an incident handling dashboard to view, analyse and handle incidents
h. Software portability across hardware
• The ITS software shall be hardware-agnostic and shall not be tightly coupled with any specific OEM hardware
2. Eligibility criteria of the bidder
a. Financial turnover of the bidder, i.e., the minimum average annual turnover required in proportion to the of ₹ ___ Crores during the last three financial years (FY ___, FY ___, FY ___).
b. Experience with successful ITS implementation including details such as:
• At least one project of value not less than ₹ ___ Crores, or at least two projects each of value not less than ₹ ___ Crores
• Implementation experience of the ITS solution for a minimum of ___ months/years prior to bid submission
c. Partnerships eligible for the bidder:
• Consortiums / Joint Venture (JV) – Allowed
• Subcontracting – Allowed for specific components
• Bank as a partner – Allowed as a technology/payment ecosystem partner
3. Technical Evaluation Criteria for the bidders
a. Similar ITS projects with PTAs/ Smart Cities
b. Scale of deployment: Vehicles, depots, command centres covered
c. Operational track record, i.e., operational duration
d. Client references: Completion certificates or proof of ‘go-live’ events
e. Implementation Approach: Deployment methodology and rollout plan
f. Training & Change Management: User training, manuals and knowledge transfer
g. Operation and Maintenance, Service Level Agreement (SLA) management approach including Helpdesk, uptime SLAs and escalation mechanisms
h. Local Presence: Local office/support team availability
i. Bidder certifications such as ISO 9001, ISO 27001
j. Original Equipment Manufacturer (OEM) certifications for ISO, Electromagnetic Interference (EMI) and Electromagnetic Compatibility (EMC) compliance and safety compliance
k. Statutory compliance with standards such as AIS-140, Ministry of Road Transport and Highways (MoRTH), National Payments Council of India (NPCI), National Common Mobility Card (NCMC) protocols
l. Use-case handling approach for incident management, trip deviations and breakdowns
m. Live Demo / proof of concept for business intelligence dashboards, reports, and alerts
n. Analytics & Reporting for Management Information Systems (MIS), Key Performance Indicators (KPIs), decision-support dashboards etc.
4. Financial Evaluation Criteria
a. Lowest cost (L1) based selection or
b. Quality and Cost Based Selection (QCBS) with a recommended weightage of 70:30 or 60:40 for Technical: Financial scores
5. Performance Bank Guarantee (PBG) requirement
a. Amount: 5% of project cost for longer term (~10yrs) contracts and ~10% of project cost for shorter term (~5 yrs) contracts
b. Duration of PBG: Project implementation period + O&M period + 90 days claim period post the completion of the contract
6. Contract Tenure
a. System Integrator: 10-12 years
b. Automatic Vehicle Location System (AVLS) hardware: 5 years
c. Automatic Fare Collection System (AFCS): 5 years
d. DMS, CMS, IMS: 10-12 years
7. Transition plan to new vendor
a. Software Escrow during transition to the new vendor
• Escrow deposit must have the latest and complete source code, database schemas, Application Program Interfaces (APIs)
b. Avoid gap between successive contracts
• No time gap between outgoing vendor's software/ hardware expiry and incoming vendor's contract
c. Transition support
• Outgoing vendor to provide mandatory transition support until Go-live period of incoming vendor
• Transition away from current approach of Go-live after 18 months-creating a transition gap between vendors
• Initial Go-live within 3-6 months based on bare minimum functionalities required for operational visibility and control.
• Additional features, optimisations, and enhancements to be rolled out through a continuous improvement model during the contract period.
b. Initial Go-live requirements
• Core ITS:
o Real-time vehicle tracking
o Command and Control Centre (CCC) Dashboard
o Route, trip and schedule monitoring
o Alerts and exception management
o Historical data playback and reporting
• Hardware and field systems
o GPS/AVL devices operational and reporting
o CCTV/PIS integrated and functional
o Reliable data transmission from field devices to backend systems
• Data, Interfaces & Interoperability
o APIs and Interfaces operational
o Data storage, retrieval, and export in open, non-proprietary formats
o Integration with ticketing / AFC / NCMC systems
• Security and Access Control
o Role-based user access
o Audit logs and system monitoring
o Basic cybersecurity controls as specified in the RFP
• Reporting and MIS
o Standard operational and management reports
o Configurable dashboards for PTA
• Go-live Acceptance Criteria
o Mandatory pilot for at least one depot and upon verification of all the go-live functionalities
9. Payment timelines and key milestones
a. Contract signing and project initiation
• 5% of Total Contract Value (TCV)
b. System readiness acceptance
• 5% of TCV
c. Initial Go-live
• 15% of TCV
d. Enhancements and O&M
• 75% of TCV as monthly payments over the contract tenure
10. Hardware specifications
a. Vehicle Location Tracking Devices (VLTD)
• AIS-140 compliant GIS devices allowing direct and unrestricted access to AIS-140 compliant data streams
b. AFCS/ETMs
• Hardware shall be NCMC-compliant and certified/approved by NPCI or its authorized agencies
• Devices shall support interoperable and bank-agnostic NCMC transactions
c. Transport system interoperability
• All hardware shall support open and standardized data interfaces to enable integration with Command-and-Control Centres (CCC), PIS, ticketing and payment systems.
• Interfaces shall use open protocols, standard data format and document APIs as per the Data Interface Catalogue
11. Scope for expansion and change during the contract tenure
a. Provision for expansion
• The ITMS must be scalable and future-ready, enabling expansion in scope, scale, and functionality during the contract period
b. Commercial treatment of changes
• Changes within original functional and architectural framework shall be implemented with no extra cost
• Changes requiring additional hardware, licenses or services, commercials shall be based on rates quoted in financial bid, or mutually agreed rates
c. Compliance during expansion
• All expansions shall comply with AIS-140, NCMC, open data standards and interoperability
d. Change management
• Changes shall be managed through a formal change management process
e. No vendor lock-in
f.
• Changes shall not result in dependency on proprietary hardware or software or restrict data access and interface portability
g. Backward compatibility
• All changes and expansions shall ensure backward compatibility with existing systems, data, and interfaces.
h. Operational continuity
• Existing operations shall not be disrupted during implementation of changes
12. Roles and Responsibilities
a. PTA
• Provide overall project approvals and policy directions and access to vehicles, depot, CCC premises, existing system, data and infrastructure required for integration.
• Nominating an Authorized Project Officer / Project Management Team for coordination with the bidder.
• Reviewing and approving project plans, designs, deliveries and change requests
• Making payments to the bidder as per the payment milestones defined in the Contract
b. Bidder/System Integrator
• End-to-end design, supply, development, integration, testing, commissioning, and operation of the ITS
• Ensure compliance with hardware and data standards as specified in RfP
• Providing training, documentation, and knowledge transfer to PTA personnel
• Operating and maintaining the ITS during the O&M period in accordance with defined SLAs
• Ensuring data security, data privacy, and system availability at all times
• Providing full transition and handover support at contract expiry or termination, including software escrow compliance
c. OEMs/Subcontractors
• Supply compliant hardware and software components and provide OEM certifications, warranties, and technical support
• The lead bidder shall remain solely responsible for the performance and compliance of OEMs and subcontractors.
d. Consortiums / Joint Venture (JV)
• The lead member shall act as the single point of contact for the PTA and is responsible for overall project delivery
• All Consortium/JV members shall be jointly and severally liable for performance of the contract
• Roles and responsibilities of each member shall be clearly defined in the Consortium/JV Agreement submitted with the bid
e. Bank/Payment partners8
• Issuance of NCMC, compliance with NPCI/NCMC guidelines and lifecycle management
• Transaction processing, settlement and reconciliation
f. Joint Responsibilities
• Participate in periodic review meetings, resolve issues and support audits, inspections and compliance checks
g. Escalations and Communication
• Communication shall follow defined protocols incident management, SLA breaches and change requests
13. Service Level Agreements (SLAs)
a. Availability
• Measuring system availability as a percentage of a 24-hour day is no longer relevant.
• Establish when is the service required (business hours). The requirement is for 100% availability during business hours.
b. Performance
• Incidents
o Incidents should first be classified on a priority basis.
o Most contracts now have definitions of high (Priority 1 (P1)), medium (P2), and low (P3) priority incidents.
o The priorities are linked to three time-based indicators: Response time, Recovery time and Resolution time.
o Critical P1 incidents will have a response time measured in minutes and a recovery time of typically less than two hours, whereas for a minor (P3) incident, the response time may still be short, but the resolution time is a working day or more.
o Resolution times are very application-specific and are usually set during RfP development, in consultation with the potential suppliers.
• Latency/ speed of specific transactions
o The system should avoid delay in financial transactions in the AFCS, real-time transactions describing the bus position, ETA estimates being sent to customer devices and similar sensitive transactions
• Speed of business processes
o All ITS data need to be processed, validated, and submitted before the deadline, and these requirements need to be handed down to suppliers for any critical services in the ecosystem
c. Quality
• ETA accuracy: Suppliers to held accountable for the accuracy of the estimate based on when the estimate was calculated.
minutes
• Vehicle location accuracy: Accuracy of +15-20 metres is usually sufficient for punctuality, ETA calculation, and arrival/departure measurement, and suppliers should be able to meet this level of quality for 97–100% of all reported figures.
d. Payment Systems
• No transaction data to be lost: It is probably best to specify this as an ‘audit’ measured SLA, where validation of the total number and value of all transactions for a vehicle, trip, route, or depot is done on a spot-check basis and compared with the data reported by the system.
14. Data standards, interoperability
a. Open data standards and interfaces
• All data standards and interfaces shall be based on open and industry-standard protocols
b. Data standards proposed
• Service schedule and real-time information: General Transit Feed Specification (GTFS) Static – Routes, stops, schedules, calendars; GTFS-Real Time (GTFS-RT) – Vehicle positions, trip updates, service alerts
• Operations and Performance: Transit Operations Data Standards (TODS); GTFS-RIDE –Ridership and passenger counts
• System Integration: Transit Integrated Data Exchange Specification (TIDES)
• Electric Mobility (if applicable): Open Charge Point Protocol (OCPP) – For integration with EV charging infrastructure
c. Data interface catalogue
• The catalogue shall include interface name and purpose of the various interfaces shown in the figure including: source target systems, data standards, data schemas, field
definitions, extensions or custom attributes, data exchange methods and protocols, performance requirements, data quality requirements, error handling and audit mechanisms.
d. Data latency requirements
• ITS shall support configurable data latency options based on operational requirements: Near real-time (≤ 1 second); Low latency (≤ 10 seconds); Standard latency (≤ 30 seconds)
e. Data privacy and security
• Ensure data privacy and protection in accordance with Government of India (GoI) guidelines and data protection best practices
f. Data portability and migration
• All ITS data shall be stored in standard, non-proprietary database formats
g. Ownership and Usage rights
• All interfaces, data, data models, and integration documentation developed under this contract shall be the property of the Authority
15. Key Performance Indicator (KPI) reports from MIS and BI dashboards
a. The ITS systems shall produce KPI reports that provide Management Information Systems (MIS) reports covering the operational and financial performance of individual buses, routes, crew etc. Traditional ITS solutions generate several reports towards this objective.
b. Additionally, KPIs which provide insights on service improvement and performance efficiency at the depot, route and network level also need to be specified by the PTA. The following table provides a few reference KPIs that PTAs may consider including in the RfP.
c. The ITS system shall generate these KPIs in MIS formats as well as BI dashboards that can be used to analyse KPI trends for service improvements
Category Key Performance Indicator (KPI)
Fleet availability (Average fleet on road)
Fleet utilisation (Ratio of fleet on road to fleet held)
Schedule level performance
Buses per route
Vehicle utilisation (Effective km per bus)
Effective (Revenue) hours of service per bus
Service, Availability, Quality and Productivity
Service effectiveness (operators’ perspective)
Schedule adherence (% of scheduled km performed)
Reasons for cancelled km (in % of daily cancelled km)
Schedule adherence (% of scheduled hours performed)
Number of skipped stops
Total hours of delay + early arrival
Reliability (To be measured at the last stop of each route as ratio of 'Average headway maintained between buses' and 'Average headway scheduled')
Punctuality (To be measured at the last stop of each route as 'Total vehicle Hours of delay+Total vehicle hours of early arrival')
Total number of passengers per bus
Occupancy Ratio
Passenger-km travelled
Number of passengers per bus per day
Passenger trips per revenue vehicle hour of bus
Passenger trips per revenue vehicle hours of bus
Number of passengers per bus per day
No. of transfers per passenger
Journey time of users split by in-vehicle, access, egress and wait time
Breakdown Factor
Service effectiveness (passengers’ perspective)
Cost efficiency
Labour efficiency
Safety
Crowding
Punctuality
Dwell Time at stops
Operations cost per km (cpkm)
Earnings per km (ticket +pass revenue) (epkm)
Operating Ratio
Average daily revenue per shift (to be reported by shift type)
Total staff deployed (staff on road+ spare staff) Vs Total staff on rolls
Total vehicle hours per employee (to be reported by shift type)
Number of accidents (Fatal & Total)
Ratio of vehicle kilometres to Number of accidents
Number of accidents on each route
Data storage and management
a. Data centre: Deciding on cloud Vs. on-premises server
• The ITS system may be cloud-hosted by the SI or hosted on pre-existing cloud or data centre of the PTA-if available at cheaper rates. In case state-owned data centres are available to the PTA for free or at a limited cost, those may also be preferred. However, the onus of server maintenance would then rest with the PTA and the necessary staffing for effective functioning needs to be ensured
b. Approach to determine cloud/ data-centre requirements
• The bidder shall provide a structured approach for determining cloud infrastructure requirements, based on expected number of vehicles, users, and concurrent sessions, data ingestion rates from field devices, storage requirements (operational and archival), reporting, analytics, and dashboard workloads
• The bidder shall submit a Cloud Sizing and Capacity Plan covering, compute, storage, network resources, peak vs average load assumptions, auto-scaling and elasticity mechanisms, backup, retention, and disaster recovery strategy
c. Indicative server configuration for 1,000-5,000 buses is provided below for PTA to be compared with the bidder’s proposed configuration.
S. No. Particulars Details
1. If the servers are hosted in the authority’s data centre or premises
• Hardware Requirements
o High-performance servers (multi-core CPUs, minimum 64–128 GB RAM)
o Storage arrays (SAN/NAS) with redundancy (RAID 10/RAID 6)
o Minimum 20–40 TB storage (scalable, depending on data growth)
o High-availability network switches, firewalls, and load balancers
• Software & Virtualization
o Virtualization (VMware/Hyper-V/KVM) for scalable workloads
o Database servers (PostgreSQL, MySQL, MS SQL, or Oracle)
o Application servers (Linux/Windows-based)
o Backup and disaster recovery solutions
• Security
o Firewalls and intrusion detection/prevention systems (IDS/IPS)
o Role-based access controls & encryption at rest and in transit
o Regular patching and vulnerability management
• Operational Needs
o 24x7 monitoring (NOC/SOC)
o Disaster Recovery Site (DRS) for failover
o Skilled IT staff for maintenance
2. If hosted on AWS, Azure, Google or Government Community Cloud (MeitY empanelled):
• Infrastructure
o Virtualized compute instances (scalable CPU/RAM)
o Object storage & block storage with automated scaling
o Load balancers, CDNs for performance
• Software & Services
Server configuration
o Managed databases (RDS/Cloud SQL/NoSQL for large-scale ticketing data)
o API gateways for payment & AFCS integration
o Cloud monitoring & logging services
• Security
o End-to-end encryption (TLS 1.2/1.3)
o Compliance with CERT-In, ISO 27001, PCI-DSS for payment data
o Cloud-native IAM & zero-trust policies
• Operational Advantages
o On-demand scaling based on commuter load (e.g., festival/holiday rush)
o Built-in disaster recovery across regions
o Pay-as-you-go model reduces CAPEX
17. Network, Hosting and Software Requirements
a. Network Requirements
• All bidders shall propose end-to-end network architecture required for ITMS operations covering, vehicle-to-server communication, depot and terminal connectivity, CCC connectivity, integration with external systems and stakeholders
• Network requirements shall be based on the SLAs including system availability and uptime, data latency and refresh rates, real-time monitoring requirements, incident and alert response times
• A minimum requirement of 4G connectivity with 2G/3G as fallback may be included with internet bandwidth requirement of a minimum of 50 Mbps for depots with up to 50 buses, 100 Mbps for depots with 50-150 buses and 200 Mbps for depots with more than 200 buses may be specified.
b. Hosting Architecture
• The ITMS solution shall support flexible hosting options, including cloud-based deployment, onpremises deployment, and hybrid deployment
