Issuu

FUTUREPROOFING INVESTMENTS IN INTELLIGENT TRANSPORT MANAGE MENT SYSTEMS FOR PUBLIC TRANSPORT PROCUREMENT RECOMMENDATIONS FOR EFFECTIVE DIGITAL INFRASTRUCTURE IN BUS SYSTEMS

Future proofing ITMS investments| i

Imprint Published by the Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH Registered offices Bonn and Eschborn, Germany Sustainable Urban Mobility- Air Quality, Climate Action and Accessibility (SUM- ACA) B- 5/2, Safdarjung Enclave New Delhi- 110029, India T 011- 49495353 https://www.giz.de/en/projects/sustainable - urban- mobility- air- quality- climate- protection- and- accessibility sut- aca As at June 2025 Commissioned by Federal Ministry for Economic Cooperation and Development (BMZ), Germany Political Partner Ministry of Housing and Urban Affairs (MoHUA), Government of India ImplementationPartner Ministry of Housing and Urban Affairs (MoHUA), Government of India Project Advisor Manjunath Sekhar, Project Director, SUM - ACA Project Coordinator Krishna Desai, Technical advisor, GIZ Zohra Mutabanna, Team Lead, GFA Consulting Group GmbH Project Team Simon Reed, IndependentITS Consultant and Former Head of Technology & Data for Surface Transport, Transport for London; Transit Intelligence: Ravi Gadepalli; Nikita Baliga Citation GIZ (2026). Futureproofinginvestments in intelligent transport management systems for public transport. SUMACA. 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. Copyright All rights reserved. On behalf of the German Federal Ministry for Economic Cooperation and Development (BMZ) Future proofing ITMS investments| ii

iii

FutureproofingInvestmentsin Intelligent Transport Management Systems for Public Transport Procurement recommendations for effective digital infrastructure in bus systems

Future proofing ITMS investments| iii

Contents Executive Summary................................ ................................ ................................ ................................ ...vii 1 Recommendations to improve intelligent transport management system procurement by public bus agencies................................ ................................ ................................ ............................... 1 1.1 Opportunities for improvement in India’s intelligent transport management system procurement ...................................................................................................................... 1 1.2

Overview of the ITMS RfPs reviewed ..................................................................... 3

1.3

Proposed approach to ITMS procurement.............................................................. 3

1.4

Recommended actions to improve the Indian ITMS ecosystem ............................. 4

1.4.1

Market consultations before RfP issuance.......................................................... 4

1.4.2

Transitioning from a fixed-life asset to a lifecycle approach ................................ 5

1.4.3

Extended contract length (10-20 yrs) instead of short duration contract (~5 yrs) 7

1.4.4

Moving from rigid non-functional requirements to outcome-oriented procurement8

1.4.5

Enhancing IT system interoperability .................................................................. 9

1.4.6

Data, data, and more data .................................................................................10

1.4.7

Expansion and change ......................................................................................13

1.4.8

Service level agreements ..................................................................................13

1.4.9

Unbundling of systems integrator and hardware vendors ..................................16

1.4.10

System ownership .........................................................................................17

1.5

Conclusions and the way forward..........................................................................18

Review of current ITMS procurement ................................ ................................ ...................... 19 2.1

Key components of an ITMS for buses .................................................................19

2.2

Key contents of the ITMS RfPs reviewed ..............................................................19

2.3

Contractual requirements ......................................................................................20

2.3.1

Scope of work ...................................................................................................20

2.3.2

Contract tenure .................................................................................................20

2.3.3

Change & exit management ..............................................................................21

2.4

Technical specifications for ITMS modules ...........................................................21

2.4.1

Automatic vehicle location system .....................................................................21

2.4.2

Contract management system...........................................................................23

2.4.3

Depot management system ..............................................................................23

2.4.4

Passenger information system ..........................................................................23

2.4.5

Incident management system............................................................................24

2.4.6

In-bus cameras & mobile number plate recognition ...........................................25

2.4.7

Automatic fare collection system .......................................................................25 Future proofing ITMS investments| iv

2.5

System requirements ............................................................................................25

2.5.1

Data standards ..................................................................................................26

2.5.2

Network hardware .............................................................................................26

2.6

Performance obligations and service level agreements in use ..............................26

2.6.1

Availability SLAs................................................................................................26

2.6.2

Quality SLAs .....................................................................................................27

2.6.3

ITMS performance SLAs ...................................................................................28

2.7

Financial specifications .........................................................................................28

2.7.1 2.8

Payment terms and penalties ............................................................................28 Conclusions ..........................................................................................................29

Next generation transit payment technologies in Indian public transport systems 30 3.1

Introduction ...........................................................................................................30

3.2

Key areas of focus for next generation transit payment technologies ....................30

Annexures................................ ................................ ................................ ................................ .............. 32 4.1 Annexure 1: Comparison of ITMS specifications across 3 RfPs and MoHUA guidelines (2021) 32 4.1.1

SCOPE OF WORK ...........................................................................................32

4.1.2

Payment terms ..................................................................................................33

4.1.3

Automatic vehicle location system .....................................................................34

4.1.4

Contract management system...........................................................................37

4.1.5

Depot management system ..............................................................................37

4.1.6

Passenger information system (PIS) .................................................................39

4.1.7

Incident management system............................................................................40

4.1.8

In-bus camera & mNVR ....................................................................................42

4.1.9

Automatic fare collection system .......................................................................42

4.1.10

Service level agreements ..............................................................................44

4.1.11

Change management and human resources .................................................46

4.2

Annexure 2: Webinar summary on next generation transit payment technologies for India 48

4.2.1

Key topics discussed .........................................................................................48

4.2.2

Panel discussion ...............................................................................................50

4.2.3

Summary of individual panellist views ...............................................................51

Future proofing ITMS investments| v

List of Tables Table 1: Potential ETA SLAs for AVLS contracts ..................................................................28

List of Figures Figure 1: Existing ITMS procurement approach with no end-of-life perspective ..................... 5 Figure 2: Proposed cyclical approach to ITMS procurement with transition plan across vendors 6 Figure 3: ITMS data interfaces .............................................................................................12 Figure 4: Potential accuracy thresholds for expected time of arrival information ...................15

Future proofing ITMS investments| vi

vii

Executive Summary ITS systems are crucial for several functions of STUs 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), ITMS 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 STUs and passengers. To understand the reason for failure and 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. Even as Indian bus agencies continue to implement ITMS to varying degrees of success, there is scope to learn from recent advancements in ITMS systems globally. The following are some of the key venues for improvement in the current Indian ITMS contracts: • Short contract tenures: ITS vendors typically get about 18 months to Go-Live and a contract for 5 years from the Go-Live event. As a result, there’s a gap between the end date of the first contract and the new contract going live leading to gap in ITS availability. We recommend at least 10-yr contracts with the vision for the system to last for 20 years. • Unbundling of ITS modules and contract tenures: Many ITS procurements by STUs have resulted in single contracts for vendors to provide the required AVLS and AFCS software, the hardware to run the software on, and the on-vehicle hardware and associated installation and integration services. In such contracts, the life of hardware (3-5 yrs) dictates the length of contract and the performance criteria of every single part of the solution. Unbundling hardware, data storage, and communication networks provides the opportunity to match the contract life with the asset life thereby improving the lifecycle commercial returns on ITS investments. • Continuity across vendors is recommended to be maintained either by asking vendors to develop open-source software or to provide access to the existing propriety software until the new vendor’s ‘Go-live’ through a software escrow mechanism • Skewed payment structure: 70% payments are currently made at the time of ‘Go-live’. As a result, the focus is on hardware and software deployment by the time of Go-live rather than its outcomes for the 5-year contract tenure given the smaller share of payments. • Lack of integration and interoperability across sub-systems such as the Automatic Vehicle Location System (AVLS), Automatic Fare Collection Systems (AFCS), depot management and incident management systems has been observed. This is due to the lack of data standards and a standardised interface catalogue to be adopted across hardware vendors. Internationally accepted standards such as the GTFS, GTFS-Transit Operations data standards etc. are recommended to be included in upcoming contracts. • Data standards, ownership and privacy so not receive adequate attention in the current contracts, which is recommended to be addressed • Contractual specifications are recommended to allow for fleet expansion/ change through provision for payment variations during the contract duration. • Service Level Agreements (SLAs) such as system availability, performance (recovery from down-time, time to address issues), data latency, speed of business process etc. are inconsistent across contracts and do not reflect global best practices. • Inadequate capacity of STUs to develop procurement specifications, manage ongoing contracts and review vendor performance is leading to repetition of the issues identified in the past contracts continuing in the new ones. The ability to design and manage unbundling of ITS contracts is also critically linked to in-house capacity of STUs. The current dependence on project management Future proofing ITMS investments| vii

viii

consultants for ITS procurement has led to limited continuity in the vision and execution of these contracts. Conclusions and key recommendations: • It is proposed that a shift be made from procuring IT solutions as hardware ‘boxes’ with a 5-year lifespan to approaching ITMS as an ecosystem, where each layer is developed in true partnership with the supplier community. • It is further recommended that emphasis be placed not only on the development phase but also on the longer-term operating phase of the contract. During this phase, the supplier should be held accountable for system performance through clear and appropriate SLAs that are well understood by all parties involved. • Although neither party can fully anticipate developments over the next 20 years, it is recommended that the journey begin with an RfP that is future-looking and flexible. While ensuring that the procuring authority receives exactly what it needs in the short term, the contract should be designed to support change, enable ongoing solution development, allow for expansion of scope, and facilitate a smooth handover to a potential new operator at the end of the contract term. • In this context, it is recommended that SaaS-based selection of the SI, with other ITMS components unbundled and procured separately, be considered. This approach may enable longer-term contracts with monthly, output-oriented payments, while also ensuring service continuity and system interoperability across vendors. Components such as AVLS, AFCS, and other hardware may be procured independently, with a mandate for integration into the backend system developed by the SI. • This approach would help ensure that the supplier remains committed to service quality throughout the system’s lifecycle, as a stable revenue stream would be tied to performance, and future business opportunities would depend on continued service delivery and system outcomes

Future proofing ITMS investments| viii

1. Recommendationsto improve intelligent transport management system procurement by public bus agencies 1.1 Opportunit ies for improvement in India’s intelligent transport management systemprocurement Digital transformation of public transport services is a key enabler to improve user convenience and service efficiency thereby attracting modal shift from private vehicles to public transport. This includes digitalising various user-facing functions of public transport agencies such as providing reliable passenger information and digital ticketing alternatives as well as internal applications such as performance monitoring, service planning, scheduling contracting and contract management. The digital infrastructure that enablers these activities need to be robustly designed to realise the intended benefits and create value for money on the investments made by the public transport authorities. Key aspects like data standards, governance, interoperability across systems, continuity across vendors etc. need to be defined at the time of its procurement to ensure effective outcomes. Intelligent transport management systems (ITMS), also referred to as intelligent transport systems (ITS), digitise several functions of public transport systems, such as passenger information, ticketing, service planning, performance monitoring, and contract management, thereby enabling improved service efficiency and passenger convenience. The following are the various modules of a typical ITS/ITMS for buses: • automatic vehicle location system (AVLS) for real-time tracking and passenger information • automatic fare collection system (AFCS), which comprises electronic ticketing machines (ETMs), smart cards (potentially National Common Mobility Card (NCMC)-compliant), and mobile tickets (potentially Open Network for Digital Commerce (ONDC)-compliant) • depot management system (DMS) covering operational functions such as bus dispatch, out-shedding, in-shedding, crew allocation, revenue management, performance monitoring, etc. • contract management system (CMS) to track the performance of contracted services and ensure timely payments • passenger information system (PIS), including passenger display boards, in-bus information, and journey planning applications • incident management system (IMS) to monitor services and respond to incidents like breakdowns, crashes, etc. • in-bus surveillance/on-bus CCTV to ensure passenger safety and security • inventory management to ensure timely maintenance and vehicle uptime

Future proofing ITMS investments| 1

The role of ITMS is becoming more prominent with the large-scale adoption of electric buses (e-buses), as such systems are being used to monitor real-time e-bus operations to meet the daily kilometre (km) targets of operations with the available battery capacity, as well as to manage the gross cost contracts (GCCs) that many agencies have adopted for e-buses. Public bus agencies in India have been investing in ITMS for close to two decades now, with varying degrees of success. Government of India (GoI) has recognised the key role of ITMS and attempted to address city-level challenges by standardising ITMS hardware specifications through regulatory methods such as the Automotive Indian Standard (AIS) 140.1 The Model ITS Request for Proposal (RfP) and guidelines were issued by the Ministry of Housing and Urban Affairs (MoHUA) in 2021. Similarly, ITS specifications across cities have been standardised through contractual specifications in the national aggregated and standardised e-bus procurement being carried out by Convergence Energy Services Limited (CESL) since 2022. Recent city- and state-level ITS RfPs in India are fostering open systems, flexibility, and the functionality to support GCC management and payments to e-bus operators. In spite of these efforts, no city has been able to provide reliable real-time passenger information and digital ticketing to users or use ITMS to improve service efficiency and conduct longer-term performance monitoring. The lack of success can be attributed to several factors, including lack of a customer centric outlook, gaps in procurement specifications, and implementing partners’ limited capacities.2 To address the challenges faced in city-level ITMS procurement, GoI is in the process of developing a centralised ITMS for all the cities participating in the PM-eBus Sewa programme, which is being implemented by the MoHUA.3 This involves onboarding a systems integrator (SI) to manage the AVLS, AFCS, CMS, PIS, and IMS for the 10,000 e-buses that are going to be deployed under the PM-eBus Sewa programme, with scope for expanding the system to cover more buses. The RfP assumes that the hardware procurement for these systems will be carried out separately. Typically, aggregated procurement results in specification standardisation across cities, thereby reducing the cost of procurement. A similar result is envisaged for ITMS procurement. Such centralised management of ITMS has already been successfully implemented internationally. The Bus Open Data Services (BODS)4 tracks around 26,000 buses across the United Kingdom to provide real-time passenger information and historic performance trends. Similarly, the Association of Dutch Public Transport Authorities (DOVA)5 provides passenger information and performance reports for 10,000 buses across the Netherlands. However, many information technology (IT) investments have failed in the past to deliver the contracted benefits, and without a change in the approach to ITMS procurement, there is a high risk of such failure within the critical landscape of the PM-eBus Sewa programme, as well as state transport undertaking (STU)-level ITMS investments.

Finalized_Draft_AIS_140_regarding_Intelligent_Transportation_Systems_.pdf

2 What Ails Intelligent Transport System: Roadmap for modernising bus services, CSE (2024) 3 PM-eBus-Sewa-Guidelines-Part-I.pdf 4 www.bus-data.dft.gov.uk 5 dova.nu

Future proofing ITMS investments| 2

This report provides guidance on ITMS procurement specifications that may be adopted in the national ITMS procurement by PM-eBus Sewa, as well as in procurement of other city or regional ITMS by STUs across India.

1.2 Overview of the ITMS RfPs reviewed Three representative ITMS RfPs from across India published by established STUs with several years of ITS implementation experience were reviewed in this study. This report has been prepared based on learnings for India derived from the current market direction and overall approaches taken in North America and the European Union (EU), along with the initiatives of other leading public transport providers. The authors have also reviewed the ITS Guidelines issued by MoHUA that, although published in 2021, still provide a useful framework for the approach to tendering for public transport IT solutions. Applying the concepts from these sources, the authors of this report reviewed RfPs for ITMS—including fare collection, vehicle tracking, and passenger information systems—across three cities covering 20,000 buses serving a population of 4.25 crores (Cr), which have been published in the last 3 years. The representativeness of these RfPs and guidelines, as well as the report findings, have been assessed through extensive consultations with STUs, Indian and international ITMS suppliers, consultants, and think-tanks actively working on the topic. The key recommendations for upcoming ITMS procurement are provided in Chapter 1, while a more detailed review of current ITMS practices is provided in Chapter 2. Digital ticketing-specific issues were taken up on a broader level in the form of a webinar discussion (‘Mobilogues’) with government and industry representatives (Chapter 3). The study is supported by the German Agency for International Cooperation (GIZ), under the Sustainable Urban Mobility – Air Quality, Climate Action, and Accessibility (SUM-ACA) project.

1.3 Proposed approach to ITMS procurement Globally, public transport authorities (PTAs) have recognised that advanced IT systems are required to support their transit business and fleet investment. The procurement of IT systems may be designed to meet the following objectives: ● The systems should run independently of the fleets they support. ● Procurement should be driven by clear outcome-oriented planning to exploit the IT solutions as an asset. ● Evolve, adapt and change: The IT systems should be adapted and modified over time to remain functional, and features should be added throughout the life of the asset to reduce costs. In Europe and North America, many ITMS have been in place for 10–20 years. Zurich, for example, had vehicle tracking systems installed in 2004, and London’s fare collection system has a history stretching back to the 1990s. All the examples in these regions, and there are many, align with the abovementioned objectives.

Future proofing ITMS investments| 3

The investment required for new ITMS for e-buses procured under PM-eBus Sewa or any other national/regional/city-level procurement should not be considered as the delivery of a single project with a start-middle-end lifecycle to facilitate bus procurement, but rather as the initial investment for a platform that will support the particular function of the transport agency for at least the next 20 years. For any transport authority or operator, the ultimate fleet asset—e.g. an e-bus—will have a start-middle-end (deliver-operate-scrap) asset lifecycle. However, the investment in ITMS should be independent of the vehicle and should be considered as an ecosystem installed to deliver today's priorities. At the same time, it needs to be flexible enough to provide a platform for: ● integration/interoperability between systems – to improve efficiency and avoid duplication of technology and data sources, to have only one source of the truth, and to avoid monolithic, single department-serving solutions ● data exchange – not only between fleet operators’ departments, but also between operators and transport authorities, central and local governments, and directly or indirectly between operators and passengers/the public. ● expansion and change – Fundamental to public transport operations, any IT solution now needs to evolve as the business changes and not be limited to when a short-term contract or fleet asset ends. The emphasis on expansion and change is particularly crucial. It should be possible to expand any existing IT solution to incorporate new fleet vehicles of any powertrain. Equally, if new IT systems are being purchased ‘today’ to support e-bus procurement, they should be flexible enough to support any other types of fleets/propulsion—not just those that exist now, but also any others that are going to be introduced in the future. The final point to note is that across many transport operators and authorities, the last day of any modern IT contract should be followed by the first day of a new contract, but not necessarily a new system. The new contract may have a replacement plan for components of the IT system or a plan for enhancements, but the priority is to maintain the existing system with lower costs and/or a new performance model. Based on this premise, the following recommendations have been compiled on how to create an enabling ecosystem for effective ITMS rollout.

1.4 Recommended actions to improve the Indian ITMS ecosystem 1.4.1 Market consultations before RfP issuance It has been observed across several agencies that RfPs are often prepared based on past experiences and references available from other bus agencies. The RfP is then issued post which the potential bidders provide feedback at the time of the customary pre-bid meeting(s). In some cases, the technology has evolved significantly compared to the systems detailed in the reference RfPs, and, hence, several clauses have to be revised, and some inputs may not even be feasible for implementation. Therefore, it is recommended that bus agencies do

Future proofing ITMS investments| 4

market research/consultations during RfP development and ensure that RfPs reflect a more comprehensive set of requirements based on technology advancement, market readiness, and the agency’s requirements.

1.4.2 Transitioning from a fixed- life asset to a lifecycle approach The primary conclusion from the review of RfPs is that they have been set up to purchase a fixed asset that will operate for the duration of the contract and then be totally replaced. None of the RfPs mentioned an exit process or contained clauses that allowed a new operator to take over the assets and services. Issues with the existing ITMS procurement model The ITMS covered in the reviewed RfPs were all being procured under a deliver-operate-scrap (end of contract) approach, as illustrated in Figure 1. The reviewed RfPs had a proposed operating period of 5–8 years and had the following shortcomings: ● No requirement to develop and accept an exit plan prior to the end of the contract. Such a plan should contain key resources, tasks, deliverables, and timescales for handover to a new supplier. ● No definition of who owns the solution during and at the end of the contract. The ownership of hardware was universally documented within the contract, whereas key intellectual property rights (IPR) aspects were rarely mentioned. ● No mechanism for handing over the solution (code/infrastructure) to a new contract holder. “As built” documents were usually contained within the project deliverable structure, but their maintenance and validation were often very weak. Regarding the software, open systems were specified in some of the RfPs, but IPR developed by the original supplier would be extremely difficult to hand over to a new support partner without more precise exit clauses.

Figure 1: Existing ITMS procurement approach with no end-of-life perspective Proposed approach to ensure technology upgradation by vendors within contract timelines When developing a procurement process, it is useful to look at the last day of the proposed contract and ask, “What does the procuring authority require at that point?” What the agency

Future proofing ITMS investments| 5

requires may be possible to acquire during the course of the project or even on the last day of ITMS operation, but it is unlikely that all the ITS requirements can be met on day 1 of the contract, as expected in existing contracts across the country. Moreover, developing the RfP for what can be achieved on day 1 of the project execution would lock us into today’s technology, with limited scope for evolution, which is not the desired outcome. Therefore, it is recommended that the vendor be allowed to ‘go-live’ with the minimum viable requirements of the system and be able to upgrade the technology within the contract timeline to meet all the authority’s intended objectives. Proposed approach to enable continuity across vendors What is equally important is the need to hand over the fully developed ITMS to the new vendor and allow the vendor to upgrade the system by replacing some parts, switching to a new platform, or capitalising on new technologies. The exit requirements for the transition need to be clearly defined. Once the exit requirements have been specified, the agency can revisit the RfP and determine whether the requirements are flexible enough to achieve the desired outcome. Figure 2 illustrates this approach, wherein the transition plan from the existing vendor to the new vendor is clearly articulated in the RfP, thereby ensuring system continuity across vendors. This will help avoid the current problem of many ITMS being non-functional for 1–1.5 years after one contract ends, while the new vendor is developing a replacement solution.

Figure 2: Proposed cyclical approach to ITMS procurement with transition plan across vendors

Future proofing ITMS investments| 6

1.4.3 Extended contract length (10- 20 yrs) instead of short duration contract (~5 yrs) The contractual relationship with the ITMS supplier should be for a much longer term than the current practice of 4–5 years adopted in most of the reviewed ITMS contracts. The basis of both the contract and RfP must change. Demerits of short-term contracts Many of the reviewed RfPs have a very short operational contract term. The system has an initial development and warranty period but an average operating period of 5 years. Short-term contracts and the build-operate model have led to a front-loaded payment model with 70% of the contract value or more disbursed after the ‘go-live’ milestone in the build phase is achieved, as shown in Figure 1. Since the majority of project revenue is recovered by the end of the development phase, suppliers have limited incentive to provide any form of service during the operational phase of the project. If the contract was longer-term, with quality service level agreements, it would be in both parties’ interest to maintain high levels of service, as this would be a longer-term business venture for the supplier. Internationally adopted model Outside of India, the operating period is far longer than that specified in the Indian RfPs under review, and the model is different: ● The build phase is a “capital expenditure (CAPEX)” project and just covers the construction costs. ● The operating phase covers operating expenditure (OPEX) costs. ● Supplier profit is delivered to the supplier throughout both phases and not at the ‘go-live’ milestone. This is a far different approach from that of hardware procurement, where the capital project (supply) includes the profit for the item and the supplier has minimal interest after the initial supply milestone has been met. Merits of long-term contracts In addition to the financial model, there is the issue of the type of ITMS being purchased. You should consider purchasing an ITMS for 10–20 years, and it should be designed as such. While extension clauses can allow a delivered system to continue operating under the same contract for longer than the initial operating period with the same supplier, in cases where the product has been designed for a short life system, this is just a stop-gap measure and is not a strategic solution. The concept is like a shopkeeper providing a paper bag to get the goods home and not a canvas sack that could be used for ten years. One can use the paper bag for a lot longer than just the trip home, but if you knew you were going to need a bag for longer, you would have purchased the sack. It follows that if a contracting party offers a supplier an IT contract for 5 operational years, the hardware/network/system will be provided under that constraint. If, at the end of the operating

Future proofing ITMS investments| 7

period, it is deemed sensible to keep running the system for a longer period, it is highly likely that the supplied system will require complete rebuilding or substantial rework. The paradigm and contract should be changed to allow for a flexible system with a 10–20 year lifespan but with a shorter initial contract term, as the initial solution can potentially be a very different system than the one in place by the end of the contract. This thinking and a system with longevity and maintenance integrated into its core design need to be incorporated into the ITMS and other future system procurement models.

1.4.4 Moving from rigid non - functional requirements to oriented procurement

outcome-

With just a few exceptions, the RfPs reviewed had a very fixed view of the capabilities of the system that was being procured, specifying the inputs or outputs with exhaustive tables of information, but with few giving the scope for the supplier to innovate during the design/implementation phase. Issues with rigid non-functional requirements for eligibility, inputs, and outputs This inflexible approach gives rise to three problems: ● Many of the mandatory inputs/outputs were not crucial for actual system operations. A supplier who could provide an ideal solution overall was still rejected if they did not meet the strictly defined criteria. Specifications for hardware constraints, in an age of flexible hosting, could be challenging, as any supplier not able to port their application onto the hardware would be rejected, regardless of whether their solution was the best one. ● Some of the RfPs had requirements for previous delivery experience at the scale of some very large Indian cities or excessive balance sheet requirements. While this is approach can potentially reduce risk, this would inevitably reduce the number of potential bidders unless managed carefully. ● The commercial agreements are designed based on fixed asset procurement models that do not allow for innovation. It was also observed that many pages in the RfPs are dedicated to penalties for non-performance, while there are few, if any, incentives for innovation, change, and cost reduction during the contract term. This means, for example, that if a new cheaper hosting solution comes along during the contract term that the procuring authority wants to integrate, this would require a massive change in the contract and affected technology. Outcome-led approach to procurement It is recommended that future procurement processes adopt an outcome-led approach, where the focus of the RfP is on clearly articulating the desired outcomes, rather than prescribing specific technical solutions. While this principle is widely acknowledged, its effective implementation remains critical for ensuring flexibility, innovation, and value for money in supplier responses. The RfP should set out the functional objectives and performance expectations of the procuring authority, along with any relevant operational constraints, such as mandated technologies under an existing IT strategy or the need for integration with legacy or

Future proofing ITMS investments| 8

bespoke systems. However, suppliers should be given the freedom to propose how they can best meet these objectives within the stated parameters. Avoiding overly prescriptive requirements—such as specifying particular software or database systems—can help prevent the unintended exclusion of capable suppliers and enable the selection of more competitive, innovative, and fit-for-purpose solutions. This approach supports strategic alignment, technical compatibility, and long-term sustainability, while also allowing suppliers to leverage their own expertise to tailor the solution to the authority’s needs.

Outcome-oriented distributed payments throughout the contract duration It is recommended that the payment structure for ITMS contracts shift from the current frontloaded approach, i.e. ~70% or more of the payments made at the ‘go-live’ event, to a more outcome-oriented approach. Although the front-loaded approach was used previously, due to the hardware-intensive nature of past ITMS contracts, as the vendors had to incur the cost of GPS devices, on-premises servers, etc., this model has outlived its merits and should give way to a lifecycle approach to contracts. This would involve the payments being made throughout the project in an ‘ITMS as a service’ model, wherein substantial payment milestones are distributed over the course of the contract. Given that the new buses come with on-board ITMS hardware, an indicative CAPEX requirement for the vendor may be estimated and paid upfront at the ‘go-live’ event, as is currently the case. This may still involve paying 30–40% of the contract value to the vendor upfront. However, the remaining payments may be made on a monthly/quarterly basis for the entire project tenure. Such a payment structure would provide greater incentive for the vendors to focus on the outputs of the ITMS, rather than the initial deployment.

1.4.5 Enhancing IT system interoperability With just a few exceptions, IT solutions have been procured through RfPs as a set of ‘stovepiped’ independent modules. For example, fare collection systems have been procured entirely independently of AVLS for vehicle tracking and management. There are many reasons why this could be a good and robust route for procurement, as ideally the procuring authority will want best-of-breed from any procurement that it is running and will not want to let integration alone drive the eventual outcome. However, there is currently no standalone ITMS, meaning that integration is a factor that needs to be considered. Absence of integration frameworks To provide successful integration services, the system integrator needs to have full visibility of all systems in the proposed project. The interface standards, specifications, and test and acceptance criteria of all interdependent modules need to be provided—this was not done in any of the RfPs reviewed. In most cases, there were merely definitions of common regional or worldwide standards that were in use and under which the procurement would be performed. Such definitions tended to be loose and high-level statements and could not, on their own, enable successful integration.

Future proofing ITMS investments| 9

Need for an interface catalogue It is recommended that any ITMS procurement ensure that the relevant data standards are specified in the RFP and, more important, that an ‘interface catalogue’ be created that clearly provides details of all interfaces that are to be provided and the applicable standards and/or specifications. During the contract duration for the ITMS solution, the interface catalogue should be kept up to date. In this way, future integration projects, e.g. the addition of new fleet vehicles or replacement of associated systems, can incorporate the relevant sections of the interface catalogue into the new RfP, thereby substantially reducing the integration risks.

1.4.6 Data, data, and more data All organisations now recognise that data is the new lubricant in our business economy, and India’s Digital Public Infrastructure (DPI) initiative is just one of the schemes that is using data to transform daily lives. Any ITMS procurement must consider the data the system is going to process and how else that data could be used in the future. Data storage and management Modern AVLS and AFCS are often proposed as cloud-hosted or via Software as a Service (SaaS) contract. Based on the hosting costs, it may be more appropriate for the procuring authority to host the software with their own cloud, rather than accepting the supplier solution. Alternatively, due to the large volumes of solutions purchased by an STU or procuring authority, there may be pre-existing cloud or data centre rates that are cheaper than those provided by AVLS or AFCS providers. In case state-owned data centres are available to the STU for free or at a limited cost, those may also be preferred. However, the onus of server maintenance would then rest with the authority and the necessary staffing for effective functioning needs to be ensured. An informed decision on the data storage strategy would require the STUs to assess the total volume of server space required and its associated costs to host the historic and real-time data. For example, the volume of data generated would vary vastly depending on whether the AVLS transmits data every 1 sec, 10 secs or 30 secs. STUs may then define the data specifications in consultation with the potential vendors balancing functional requirements of the ITMS and the associated costs. Data integration In most reviewed RfPs, vehicle tracking and management was the main focus of the ITMS, where the data was expected to be used to reclaim revenue for operating subsidised services. The RfPs limited the tender scope to this data application alone but forgot to define who owns all the data associated with that process. Data that may be provided by the ITMS includes the vehicle location, driver details, and route and trip details. This data is an asset that should be clearly owned and made available under the RfP so that future requirements can easily exploit this data with minimal additional cost. Data ownership and data privacy Most of the reviewed tenders had some definitions of data ownership in their specifications, but it was unclear how data ownership was to be divided between the procuring authority and

Future proofing ITMS investments| 10

the supplier. For example, the general principles of cybersecurity and data privacy were usually specified in terms of a requirement to adhere to a process or standard, but it was unclear how and where that was going to be achieved and what the roles of both the authority and the supplier were. This may be because Indian legislation is less demanding in terms of data scrutiny than that of Western countries. However, it is likely that data privacy will become an increasingly important agenda item in India, and, taking a long-term view, it is clear that existing RfPs do not provide sufficient clarity on data ownership and the role of the supplier and the procuring party in terms of responsibility and accountability for data management. Therefore, currently, in the event of either a data privacy challenge or cyber-attack, it would be nearly impossible to define whose problem this was and therefore what and who would be required to take remedial action. Data standards The second major point deals with data standards and is linked to interoperability. It would be helpful if a single data model could be referenced at the start of the RfP; the data standards that are to be used should be listed as requirements and not just in definitions. Furthermore, a data interface catalogue needs to be an early deliverable of every project, agreed upon by the supplier and the procuring authority. This would provide the building blocks for the IT solution and a guarantee of quality data exchange throughout the various ITMS components of the public transport authority and onwards with the State and National Governments (in cases like the PM-eBus Sewa ITMS, Payment Security Mechanism etc.) if required. RfPs need to mention the need for standardised application programming interfaces (APIs) and/or the proposed interface catalogue and a flexible framework for compatibility across various hardware and systems. The data standards, protocols, or framework within which this data exchange shall be enabled also need to be clarified. General Transit Feed Specification (GTFS) is usually mentioned as a reference standard for interoperability and data exchange compatibility and is considered to be simpler than other global data standards such as TransXchange, NeTEx, and Service Interface for Real-Time Information (SIRI). However, GTFS only includes passenger information-related data points such as stops, routes, trips, and arrival and departure times at stops. Other system integration requirements on data points like depots, vehicle and crew schedules, and e-bus- and charging infrastructure-specific data items are not covered by standard GTFS. We recommend that GTFS continue to be mentioned as the base transit data format, along with other required data. This includes specific files and extensions/add-ons within GTFS, such as Transit Operations Data Standards (TODS) for planning and scheduling data and GTFS-RIDE for ridership data, as well as data standards to share e-bus performance and charger performance data, such as Open Charge Point Protocol (OCPP). Data interfacing between systems ITMS have several layers of data interfaces, as shown in Figure 3. The GTFS and proposed add-ons may still not adequately cover the data exchange. For example, the communication between the Contract Management Systems (CMS) and the escrow/bank/contracting authority is not covered. Similarly, the interface between existing ITMS in the city and the proposed ITMS is not specified.

Future proofing ITMS investments| 11

Figure 3 depicts the data interfaces in the proposed ITMS. The blue connections indicate interfaces covered by the data standards proposed above, while the red arrows indicate the interfaces not covered in existing ITMS RfPs. The RfPs need to add additional details on this after due consultation with the relevant stakeholders. It is recommended that an ‘interface catalogue’ be developed that starts with the ‘data interfaces for ITMS’ model (shown below) and provides details for each interface, the relevant data standard, extensions, performance requirements, and data quality requirements. Such an approach will ensure that the CMS is compatible with operators/authorities who use AVLS/IMS and other systems outside of the ITMS procurement specifications.

Figure 3: ITMS data interfaces

Future proofing ITMS investments| 12

1.4.7 Expansion and change The overall aim of the reviewed RfPs was to procure a single solution for a set job for a limited amount of time, under the build-operate model. As mentioned above, the problem with this approach is that the ITMS system build/ development phase scope will be closed/ predefined for the number of buses and the contract duration with limited scope for expansion and change. Rigid frameworks - hurdle for change or expansion In the reviewed RfPs, vehicle integration covered the number and types of vehicles, and the supplier would be held responsible for integrating these vehicles with the procured solution. As soon as the build phase was over, any additional vehicle that did not exactly match the scope of those in the original build phase would necessitate change control, implying extra cost, time, and effort. Interviews with vehicle original equipment manufacturers (OEMs) highlighted this as a major issue. OEMs will supply vehicles with the agreed specifications, and it will not be in their scope to integrate the vehicles into the wider ecosystem. Equally, the IT solution provider has a relatively short contract, and once they have completed the original build, they will not look to change the model to incorporate a new type of vehicle without contractual change. The example above on vehicles reflects recent interviews but also more broadly demonstrates how the current approach to change implied in existing RfPs can be problematic in the case of ITMS. Planning for expansion The scope of the overall procurement is limited, to enable the procuring authority to meet deadlines, but does not allow for simple progression or improvement that could benefit both the procuring authority and supplier during the project. This is another example where starting at ‘the end’ may be beneficial. If one assumes a 10-year timespan with the ITMS investment, what does the fleet look like? How many vehicles? Where will they be sourced from? Of course, the answers will be supposition, but you can provide room for flexibility within your RfP to enable easy expansion—or reduction—in fleet size. If that is done at the outset in initial ITMS procurement, it de-risks the project by providing room for future implementation requirements.

1.4.8 Service level agreements Service level agreements (SLAs) define the obligations against which ITMS performance is measured, non-adherence to which will attract penalties, i.e. deductions from the payments to vendors. Reviewed ITMS SLAs focus predominantly on input-oriented metrics such as system ‘availability’—often specified as 99.99%—and time to fix hardware or address system failure. In more modern global ITMS contracts, SLAs for the operating period define the service level throughout the life of the system and are subject to contractual, regular review and modification.

Future proofing ITMS investments| 13

Although the current metric of ‘availability’ is an important parameter to measure, it is insufficient to evaluate the overall efficacy of the system. Additional principles for the performance indicators should be incorporated into the SLAs: ●

Availability – 100% availability within business hours Measuring system availability as a percentage of a 24-hour day is no longer relevant in today’s technology-driven world. The first point to establish is when is the service required (business hours). For example, the business hours for a back-office system may be 6 a.m. to 6 p.m. on Monday and Saturday, whereas a customer-facing application may be required while transport services are running, e.g. 4 a.m. to 2 a.m. The requirement is for 100% availability during those business hours. Modern cloud systems can provide 100% availability 24/7, although the cost of this level of availability is likely to be very high.

●

Performance Performance metrics should reflect how system performance is measured over the entire operating period of the contract; they should cover not only the time to deal with interventions/incidents, but also any time critical system elements, like transactions, endto-end data transfer, latency, etc. o

Incidents – division of recovery time and resolution time and prioritisation ▪

Most reviewed contracts had a single metric: ‘time to fix a fault’. Many of the target times were unrealistic.

▪

Incidents should first be classified on a priority basis, e.g. component failure in fleet vehicles is far less significant than a payment system outage. Most contracts now have definitions of high (Priority 1 (P1)), medium (P2), and low (P3) priority incidents, linked to three time-based indicators: ▪

Response time: the time taken for the supplier to respond to the incident

▪

Recovery time: the time taken to get the failed system operating again.

▪

Resolution time: the time taken to fix the problem, usually based on the incident priority level.

▪

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.

▪

Resolution times are very application-specific and are usually set during RfP development, in consultation with the potential suppliers.

Latency or speed of specific transactions. System architectures vary, but it should be possible to specify the maximum amount of time between sending an instruction and receiving a response. For online systems with human input, this would normally be specified in less than so many seconds, unless otherwise agreed. For example, in machine-to-machine instructions, the system should avoid latency in: ▪

financial transactions in the AFCS

Future proofing ITMS investments| 14

▪ ▪

Speed of business processes. For PM-eBus Sewa, the original draft RfP mentions generating all reports in the CMS within 7 days of the close of the period as a key objective. It is possible that this implies either system or business processing to be performed to ensure that authorities are not disadvantaged or penalised through lack of a functioning ITMS for issues that are beyond their control. For example, all operational data from vehicles will need to be processed, validated, and submitted days before these deadlines, and these requirements need to be handed down to suppliers for any critical services in the ecosystem.

●

GTFS transactions describing the bus position estimated time of arrival (ETA) estimates being sent to customer devices (the mobile solution) and similar sensitive transactions

Quality Quality SLAs specify measurable metrics linked to the continuous performance of the system that add value to the service. For example, having a system that is transmitting ‘location’ data according to the agreed protocol in the interface catalogue, with the performance as agreed but with positional data that is not within a quality metric range, is potentially useless. Examples of quality metrics include: o

Estimated time of arrival in real-time passenger information systems is usually calculated based on the progress of the vehicle along a route path. Suppliers are usually held accountable for the accuracy of the estimate given based on when the estimate was calculated.

Figure 4: Potential accuracy thresholds for expected time of arrival information

The accuracy of the reported vehicle location in vehicle tracking CAD/AVL systems needs to be appropriate to the application using the data. For many systems, 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. However, if the location data is being used to open/close gates/doors/bridges, that level of accuracy is probably too low, and figures closer to +5 metres will be required.

For payment systems, it is clear that transaction data must not be lost. The question is how to specify this within an SLA. 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.

Future proofing ITMS investments| 15

Other quality metrics could include: ▪

the number of failures or repeat failures over time. If these figures increase, it is either a sign of a failing system or failure to effectively repair a damaged system.

▪

sensor data accuracy – e.g. passenger counting, axle counters, or CCTV data

▪

data completeness – Has all data been captured/selected for the report, transaction, or business function?

1.4.9 Unbundling of systems integrator and hardware vendors Many ITMS procurements by STUs/PTAs have resulted in single contracts for vendors to provide the required AVLS and AFCS software, the hardware to run the software on, and the on-vehicle hardware and associated installation and integration services. The advantage of this approach is that there is a single contract to manage. However, in this case, as mentioned above, one component (often the hardware) dictates the length of contract and the performance criteria of every single part of the solution. The architecture schematic in Figure 3 shows that the vehicles in the bottom tier will have an asset life commensurate with their usage and an average life expectancy of 10–15 years. With software, data storage, and computer hardware, the same principles of contract duration matching life matching asset life hold true. Software, when upgraded and revised, can last at least 10 (e.g. in London) and up to 20 years for both AVLS and AFCS. The platforms they are on will have been replaced several times during the lifecycle of the software, and the vehicles that those systems support will also have been replaced at least once. Therefore, in addition to longer contracts (1.3.3) and greater contract flexibility (1.3.7), there is a case for unbundling hardware, data storage, and perhaps the communication networks from the procured system. To do this, there has to be the motivation and capability in the STU or procuring authority to make this happen. In most cases, the justification will be a commercial advantage in taking this approach or simply a strategy that ensures that the procuring authority retains ownership of all system assets. The way to explore this approach—without immediately committing to it—in the procurement process is straightforward: ●

●

Clarify in your procurement documents that the procuring authority may wish to provide its own hardware or communication network but that the decision will be made based on the outcome of the procurement process. Ask each potential supplier, as part of their submission, to specify the hardware or communication requirements for their proposed solution.

Future proofing ITMS investments| 16

●

Ask each potential supplier, as part of their submission, how much they would charge to provide the required hardware or communication network.

This gives the procuring authority the opportunity to see how different suppliers’ requirements vary. For example, one may have an extremely high specification and the other a very low one. With this information, different variations can be explored, through dialogue to ensure that the most appropriately sized solution is being proposed. The procuring authority also gets a benchmark and costs that can be used to determine if there is a business case for providing the hardware or communication network through existing means, rather than by purchasing equipment from the AVLS/AFCS provider. The institutional capacity to execute such refined procurement processes also needs to be evaluated. While larger and more established STUs may be able to undertake this process, smaller STUs are typically used to referring to RfPs from other STUs to execute their own RfPs, due to lack of in-house capacity. Given the longterm cost incurred in the form of failed ITMS execution, it is recommended that the necessary capacity for efficient procurement and contract management be institutionalised, either at the STU level or at least as a pool of trained resources at the state level who can assist authorities with procurement across several STUs.This is particularly relevant to cloud-based hosting. Another opportunity lies in the role of the SI and whether the responsibilities for integration should be covered in the contract for the AVLS and AFCS or tendered and contracted separately. The SI is responsible for the end-to-end integration of the new system, module, or component within the ecosystem. Again, there are three recommended options here: - The procuring authority could be the SI. Provided there is both motivation and capability, this ensures that all parties work together for the benefit of the procuring authority. - The SI role is delegated to an organisation that acts as the procuring authority but also has sufficient experience and competence to deliver the end-to-end solution. - The SI function could also be the responsibility of the supplier, provided the supplier has access to and cooperation from all other providers in the ecosystem. It must be noted that this can increase the risk of project failure if there is insignificant domain knowledge. In summary, unbundling is an attractive option for authorities with sufficient motivation and capacity to implement it. While not without risks, dividing the system components into separate contracts (e.g. networks, hosting hardware, and software) may provide a commercial opportunity and a solution landscape that better reflects the asset strategy of the solution.

1.4.10

System ownership

The PTA/STU managing the ITMS procurement needs to take ultimate ownership of the system. While the procurement specifications are a necessary prerequisite, the success of ITS implementation depends on the level of ownership shown by the PTA/STU in data management, the process transformation needed for ITMS-based operations such as data standardisation, and performance monitoring of the ITMS contract. Hence, PTAs/STUs need

Future proofing ITMS investments| 17

to continuously build/strengthen their in-house capacity for ITMS management to ensure successful delivery of the procured systems.

1.5 Conclusions and the way forward This chapter has detailed many shortcomings in the ITMS RfPs of leading transport authorities in India, which exist due to short-termism being an underlying principle of this type of procurement. It is proposed that a shift be made from procuring IT solutions as hardware ‘boxes’ with a 5year lifespan to approaching ITMS as an ecosystem, where each layer is developed in true partnership with the supplier community. It is further recommended that emphasis be placed not only on the development phase but also on the longer-term operating phase of the contract. During this phase, the supplier should be held accountable for system performance through clear and appropriate SLAs that are well understood by all parties involved. Although neither party can fully anticipate developments over the next 20 years, it is recommended that the journey begin with an RfP that is future-looking and flexible. While ensuring that the procuring authority receives exactly what it needs in the short term, the contract should be designed to support change, enable ongoing solution development, allow for expansion of scope, and facilitate a smooth handover to a potential new operator at the end of the contract term. In this context, it is recommended that SaaS-based selection of the SI, with other ITMS components unbundled and procured separately, be considered. This approach may enable longer-term contracts with monthly, output-oriented payments, while also ensuring service continuity and system interoperability across vendors. Components such as AVLS, AFCS, and other hardware may be procured independently, with a mandate for integration into the backend system developed by the SI. This approach would help ensure that the supplier remains committed to service quality throughout the system’s lifecycle, as a stable revenue stream would be tied to performance, and future business opportunities would depend on continued service delivery and system outcomes. It is recommended that all inputs—both strategic and procurement-related—be compiled into a comprehensive guideline document. This document could aid government authorities in streamlining the procurement process and ensuring that robust, efficient ITMS are in place to meet public transport needs over the next two decades.

Future proofing ITMS investments| 18

2. Review of current ITMS procurement Chapter 1 provided recommendations on strategic priorities for ITMS procurement. This chapter delves deeper into the different sub-components of ITMS contracts to identify the various specific issues that need to be covered in RfPs used for procurement and propose changes to the current approach, where applicable.

2.1 Key components of na ITMS for buses The following are the main modules of typical ITS/ITMS for buses: • AVLS for real-time tracking and passenger information • AFCS, which comprises ETMs, smart cards (potentially NCMC compliant), and mobile tickets (potentially ONDC compliant) • DMS covering operational functions such as bus dispatch, out-shedding, in-shedding, crew allocation, revenue management, performance monitoring, etc. • CMS to track the performance of contracted services and ensure timely payments • PIS, including passenger display boards, in-bus information, and journey planning applications • IMS to monitor services and respond to incidents like breakdowns, crashes, etc. • In-bus surveillance/on-bus CCTV to ensure passenger safety and security • Inventory management to ensure timely maintenance and vehicle uptime

2.2 Key contentsof the ITMS RfPs reviewed Three representative ITMS RfPs from across India published by established STUs with several years of ITS implementation experience were reviewed in this study. One of the RfPs covered multiple urban bus agencies (RfP A), while the remaining two were from STUs at the metropolitan city scale (RfP B & RfP C). The names of the cities & RfPs are not disclosed so that the focus remains on procurement specifications, rather than STU-specific issues. The RfP procurement specifications were divided into five key categories: 1. contractual requirements such as tenure, scope, etc. 2. technical specifications for AVLS and AFCS system software and hardware 3. system specifications concerning network requirements, data standards, etc. 4. performance obligations and service level agreements 5. financial specifications such as payment timelines and penalties Some procurement specifications that do not have associated recommendations have also been included to provide a comparative assessment across RfPs.

Future proofing ITMS investments| 19

2.3 Contractualrequirements 2.3.1 Scope of work The three RfPs compared had different components in their scope. RFP A was the most exhaustive, comprising six components: AVLS, CMS, PIS, IMS, in-bus surveillance, and AFCS. RfPs B & C only covered AVLS and PIS. The key observations are as follows: A. Common components: AVLS & PIS feature in all three RfPs and are mutually dependent components. The PIS component includes a mobile application with a journey planner. B. Exclusion of AFCS: The fare collection system is complex, with multiple NCMC compliance requirements, system security, and multiple payment modes. While fare collection requires a different approach and focus, the ticketing data generated by the system must be seamlessly integrated to enable route performance evaluation and optimise operations. Hence, it is recommended that, despite the exclusion of the AFCS from the scope of the reviewed ITMS RfPs, the ticketing data interface within the ITMS system be defined in the central ITMS RfP to ensure future integration.

2.3.2 Contract tenure A. Timeline for development and implementation: The development and implementation timeframe for ITMS ranges from 6 months to 2 years, while the timeframe of the operations & maintenance phase is in the range of 4–6 years. This results in a limited operational tenure relative to the time required to get the system running. It is recommended that the contract tenure be increased to a minimum of 10 years, which is a sufficient amount of time for the system to be run, tested, and improved to have a meaningful impact. It also aligns better with bus lifespan and can incorporate hardware modifications or upgradation requirements. B. Scope for expansion: The reviewed RfPs specified the exact number of buses for the ITMS design, thereby not covering additional buses that were likely to be procured and added to the city’s fleet during the contract period. To ensure flexibility within the system, it is recommended that RfPs specify a minimum and maximum number of buses the system should support, in alignment with the STU’s strategic plan/vision. This approach will enable the system to seamlessly expand and integrate new buses. C. Pilot testing before the go-live event: ‘Go-live’ is defined as the system is tested and implemented at a pilot scale, and a substantial chunk of the payment is linked to this event. The reviewed RfPs specified a range from one bus to one depot as the qualification for the pilot, after which the full-scale deployment of the hardware and software installation was to be taken up, followed by the system acceptance testing for the go-live event. Conducting a pilot for a fleet that can fill at least one depot is recommended to assess all aspects of system operations before full-scale implementation.

Future proofing ITMS investments| 20

2.3.3 Change & exit management A. Change management during the contract term: Changes within the system like technology upgradation or addition of buses to the system are not comprehensively addressed in the RfPs. RfP B provides specifics on changes, but only those in the period up to go-live. As a result, significant changes that could be potentially be taken up during the life of the contract such as upgrading the network capabilities, hardware, and software, are not covered. Given the constantly evolving nature of ITMS, it is recommended that the contract incorporate provisions for periodic upgrades and the necessary approval mechanisms for the technical and financial evaluation of these upgrades. B. Exit management - Continuity through open source/software escrow: None of the RfPs specify the modalities of the system handover to the next vendor. Details on the end-of-life ownership of the system being procured, the source code of the solution, and the hardware are not provided, leaving the responsibility for the handover ambiguous. This creates a high risk of service disruption across vendors and long development timelines for the new vendor. Apart from increasing the contract tenure, there need to be provisions for continuity across vendors, as well. While some STUs tried accessing the vendors’ source code, the likelihood of the new STU and vendor being able to use previous vendor’s source code is low. Alternatively, the ITMS vendor may be asked to develop an open-source version of their software during the project and make it available in publicly verifiable locations such as the Github. In case vendors are reluctant to share source code publicly, a software escrow may be created, where a tripartite agreement is signed between the STU, the incumbent vendor, and the new vendor, with the new vendor having licence to use the incumbent’s software under specific conditions, e.g. during the development phase of the new contract. C. Training requirements: All the RfPs included training modules, presentations, or manuals for ITMS users, which is a welcome measure, but our consultations indicated that such materials are rarely used, resulting in continued capacity limitations of STUs in managing ITMS.

2.4 Technical specifications forITMSmodules 2.4.1 Automatic vehicle location system A. Hardware specifications and the limitations of AIS 140: RfP A and B mandated hardware compliance with AIS 140. AIS 140 includes 17 parameters related to the vehicle location, acceleration, deceleration, etc. but does not cover any of the service characteristics of public transport, such as routes, depots, trips, bus stops, and so on. It also does not include the data interface format/communication protocols. This standard is primarily relevant for incident management such as SOS calls, rather than public transport management. Therefore, seamless flow of data to the ITMS is a hurdle. It is recommended that the AIS 140 itself be revised to make it more relevant for public transport agencies. Irrespective of the AIS 140 revisions, a standard interface

Future proofing ITMS investments| 21

catalogue for all the datasets can be created to enable seamless information exchange between the vehicle and the backend ITMS. B. Software requirements and difficulties with planning and scheduling: The software requirements include route replay, route network planning and scheduling, operational & key performance indicator (KPI) dashboards, etc. that are related to vehicle tracking, passenger information, and service monitoring. The city-level RfPs typically include the planning, scheduling, duty allocation, rostering, and dispatch management modules as part of the scope of the ITMS vendor. However, consultations indicated that ITMS vendors often deliver on the crew rostering and vehicle dispatch solutions but are unable to deliver on service planning and scheduling at the depot, fleet, and crew levels. These sub-components need personnel with specific domain expertise, which is typically outside the scope of an ITMS hardware and software vendor. Hence, it is recommended that future ITMS contracts remove planning, scheduling, and rostering and make these activities a separate solution independent of the vehicle tracking and passenger information systems. C. Prediction software for ETA: This optional feature can dynamically predict the ETA. It was included in RfPs A and C but not in RfP B. The need for prediction software is implicit if the city asks for a journey planning application from the supplier base. In recent years, several open-source ETA prediction software engines have become available on the market, and many customers already use Google Maps and similar applications that have journey planning and ETA functions. These developments may make this requirement redundant. Rather than such input-oriented requirements, cities may be able to specify the level of accuracy of the journey planning application (see SLA in section 1.3.7), which will allow the supplier to develop their own prediction software or use one of the readily available solutions. D. Data latency: RfPs B and C mandate the transfer of location data from vehicles every 10 seconds, while RfP A mandates data packet transfer every 5 seconds. While more accurate information is desirable, the cost of sending data more frequently is a cost that may be unnecessary when passenger information is the primary target. With average bus speeds often being less than 10 kilometres per hour (km/h), a bus location telegram every 10 seconds can deliver high-quality passenger information while significantly limiting network and data storage requirements and costs. However, in case the city intends to integrate the AVLS data into the traffic signal management system to deliver signal priority for buses, data may even be required at a frequency of 1 second to enable real-time bus priority signalling. Cities need to evaluate the intended application of the AVLS when determining the data latency for RfPs. E. Dashboards and reports for performance monitoring: All RfPs included a list of KPIs that had to be reported in management information systems (MIS), as well as dashboards. While this is desirable, the KPIs varied between RfPs and sometimes did not match the traditional KPIs used by Indian STUs, leading to some STUs having multiple MIS. Hence, there is scope for standardisation of KPIs at the national level to ensure that every STU includes all the key KPIs in their RfPs, with room for additional context-specific requirements. For example, RfP A had specific KPIs like reliability, availability, punctuality, frequency, safety of operations, operational infractions, etc. that are key to managing bus systems. RfPs B & C did not include some of these indicators, which limits their monitoring effectiveness. All three RfPs included MIS reporting requirements, but the types of reports varied significantly. Only RfP A Future proofing ITMS investments| 22

mentioned ITMS status reporting, which helps in monitoring the uptime of the ITS, along with the system performance-specific KPIs and reports. Such monitoring allows the STU to verify whether extreme KPI values, if any, stem from ITMS performance issues or bus-related performance issues.

2.4.2 Contract management system A. The CMS module was only present in RfP A and was used to derive the KPIs specific to GCCs issued by the STU, generate the operator invoices, and enable timely payments. The data for key CMS KPIs such as payments for the distance travelled and penalties for non-adherence to KPIs such as punctuality, trip frequency, km frequency (scheduled Vs actual km performed), etc. predominantly comes from the AVLS. Given the potential gaps in AVLS data, as well as the need to enter information like operational infractions or other changes required while managing operations, it is recommended that the system have the scope for manual verification and revisions where needed.

2.4.3 Depot management system A. The DMS module supports depot-level functions such as bus dispatch information for passenger information and to monitor schedule adherence, bus and crew scheduling, crew allocation to the fleet (crew rostering/duty rota), and manual data entry on performance metrics corresponding to the fleet, crew, revenue, and ridership. B. Consultations with STUs revealed that ITMS vendors have been able to deliver as per STU expectations on dispatch details, crew rostering, and manual data management. C. Planning and scheduling: Across India, ITMS vendors have not been able to deliver on STUs’ service planning and scheduling requirements. Given that the majority of the payments and KPIs are linked to hardware deployment, passenger information, and reporting, ITMS vendors made limited investments in developing in-house expertise or forming external partnerships to support STUs in planning and scheduling. ITMS vendors with AVLS and KPI reporting expertise may not be the best suited for planning and scheduling activities, which require skills in transport planning and operations research, in addition to data management. Hence, it is recommended that planning and scheduling be taken up as an exclusive contract by the STUs, building on the data generated by the ITMS, and not be included as a part of the DMS.

2.4.4 Passenger information system A. Mobile (and web) applications for journey planning information: All three RfPs had the PIS component, whose primary function is the mobile application. RfP B also included a web-based application and SMS-based information sharing. B. RfP A specified that the main purpose of the mobile app was to provide real-time updates on bus arrival times and service disruptions. The real-time updates specify the current stop name, route number & name, and ETA for the next five buses. C. RfP B detailed 14 key features of the application, such as service/route number, origin, destination, en route stops, and ETA. RfP A only specified current stop name, route

Future proofing ITMS investments| 23

number and name, and ETA for the next five buses for the mobile application. RfP C specified 14 features, including multimodal options, parking locations, and the provision of the application’s content in two languages. D. RfP B specified more information beyond the transport-related information (bus schedules, alerts, etc.) mentioned by the other RfPs, including safety information, localised community information, GPS-driven localised data, environmental data, advertising (still images, animation, and video), and tourist information. a. Hardware requirements: The hardware requirements in all the RfPs consisted of bus stop-based passenger information display boards. Only RfPs B and C provided the technical specifications for the boards. The detailed location and number of PIS boards was only specified in RfP B.The content refresh rate (CRR) for the PIS boards was specified in all the RfPs, although the rates differed: i. RfP A: 1 minute or less ii. RfP B: 1 minute or less, display time: at least 10 sec iii. RfP C: automatically every 10 seconds E. Like the observations made on planning and scheduling, providing journey planning applications in a user-centric manner for large-scale adoption requires specific skillsets that ITMS vendors specialising in hardware and data management may not always have. Journey planning information is likely to be consumed more from mapping applications such as Google, Moovit, Bing maps, etc. or exclusive public transport applications such as Chalo. While the STU may be required to provide a base journey planning application as the ‘official’ source of information, enabling real-time information on third-party applications will facilitate access to information for a wider audience. Therefore, ensuring open access to journey planning information in standard, machine readable formats is recommended.

2.4.5 Incident management system A. The IMS module was included in RfPs A and B and is intended to allow STUs to record various key incidents that require attention by operational staff/management. a. RfP A divided the modules into four parts: 1. user management: username, access level, groups 2. incident master: incident category, sub-category, incident severity level (e.g. low, medium, critical), operational infractions category, incident status, turnaround time (open, in progress, closed, re-opened)) 3. module master: CMS, AVLS, AFCS, PIS, mobile app for selection filter 4. operation master (operating hours, non-operating hours). The output display requirement included total incidents (accidents/breakdown/module not working/other issue), total open incidents, total closed incidents, and total re-opened incidents. The AVLS was to provide the input data, while externally a network management module would be used to capture data on system health, performance, and device uptime & downtime. b. RfP B made the IMS part of the AVLS module. This IMS contains 25 different incidents, where each incident is given an ID, and the STU hierarchy is applied to delegate incident resolution and track the incident until successfully resolved. c. With increasing e-bus adoption via GCCs and the standardised contracts issued by Convergence Energy Services Limited (CESL) focused on monitoring KPIs and

Future proofing ITMS investments| 24

operational infractions, the IMS will play a greater role in contract management. Hence, it is recommended that the IMS parameters and their definitions be aligned with the standardised GCCs issued by CESL for greater applicability.

2.4.6 In- bus cameras & mobile number plate recognition A. This module is primarily for safety and was included in RfPs A and B. B. RfP A mandated the use of camera-based automatic passenger counters (APCs) and CCTV, with mobile network video recorder (mNVR) used for panic alerts (AIS 140 compliant). RfP B specified two cameras per bus, mNVR, and an emergency button. C. The specifications of RfP A were observed to be the most comprehensive and may be used as the reference case for future RfPs.

2.4.7 Automatic fare collection system A. Only RfP A included this module as a SaaS solution with back-office functions such as NCMC integration and mobile ticket integration. B. The AFCS module is internally integrated with the AVLS, mobile application, and ticketing system and externally with validators and banks. C. The system choice for AFCS and the alternative approaches available are discussed in Chapter 3. The key observation on AFCS from the RfP review and the Mobilogues webinar is that there is a need to unbundle AFCS procurements, where possible, to separate multimodal ticketing and STU-specific requirements. STU-specific requirements such as ETMs, NCMC compliant smart cards, and mobile ticketing, along with their associated network, data, software, and hardware requirements, may be taken up through an independent contract. Multimodal ticketing through mobile applications would require other mass transit modes (metro, suburban rail, water metro, etc.) and on-demand modes on aggregator platforms (Ola, Uber, Namma yatri, and Rapido) and may be best achieved by enabling the ONDC for better interoperability across systems—as is being demonstrated in Delhi. However, AFCS business models vary across India and are constantly evolving. Active market consultation before procurement may be the best way forward to identify the most suitable approach.

2.5 System requirements The RfPs reviewed provided some details on data standards and network requirements, while other key aspects discussed in Chapter 1, such as interoperability between various layers of data and details of the business intelligence to be derived from the data collected, did not receive adequate attention. Similarly, the function requirement specifications (FRS) were listed as a vendor responsibility. The procuring agency clarifying the functional needs is more likely to ensure consistency in outputs irrespective of the vendor selected through the bidding process.

Future proofing ITMS investments| 25

2.5.1 Data standards A. All cities have mandated data sharing in GTFS format. B. Although GTFS works for commuter information provision and is already being used in multiple Indian cites, a standard data format for all other components to communicate is required. This includes the operational data, ticketing data, and duty allocation data, which have not been defined yet and should be integrated with the specified GTFS data format. C. We recommend that GTFS continue to be used as the base transit data format but that additional required information also be mentioned. This includes specific files and extensions/add-ons within GTFS such as TODS for planning- and scheduling-related data and GTFS-RIDE for ridership data, as well as data standards for e-bus performance and charger performance data sharing, such as OCPP.

2.5.2 Network hardware A. RfP A mandated 4G/5G network-based communication technology for data to be updated, while RfP C permitted 3G, 4G, and 5G. RfP B did not specify the network requirements. B. With technology being upgraded at a fast pace, updates will be required over the course of the contract period. Hence, specifying the network/technology might not be necessary in the RfP. C. It is recommended that the STUs do not pre-specify the network requirements but rather allow the vendors to identify network requirements to meet the outputs and obligations of the system. Vendors can be asked to provide their technical specifications as part of their submissions, and this information should be technically assessed as a part of the evaluation process.

2.6 Performanceobligations andservice level agreements in use 2.6.1 Availability SLAs Availability of each of the components is an SLA across RfPs, but with a varying level of detail: a. RfP A: The availability requirement for all the components—CMS, PIS, AVLS, and AFCS—was 99%. It is recommended that the availability of all components be 100%. While components like CMS might be required in the period 9 a.m.–9 p.m., others like AVLS and PIS, where commuters will access information, should be online 24/7. b. RfP C: Availability of PIS, single control unit (SCU) & Bus driver unit (BDU), Depot Management System (DMS), and AVLS ranged from 99.0% to 99.9%. c. RfP B: AVLS availability was 95%, the lowest among the RfPs studied. Availability of PIS was less than 30 seconds, which was differently measured. Vehicle-related online information availability was 90%. d. CMS availability: 24/7 availability of the CMS application is unnecessary (increased cost); it would be useful to define a service period (e.g. 6 a.m. to 7 p.m. MondaySaturday) and specify 100% availability during that time. Future proofing ITMS investments| 26

AVLS availability: There should be 24/7 AVLS availability. The expectation should be either that the vendor either signs up for 100% availability or is disqualified. The supplier should be able to build a resilient backend system to ensure availability at all times. AFCS availability: This should match the service hours being offered by the transport service and the timings of the user community. If the city only has bus services between 5:00 a.m. and 1:30 a.m., the availability window may be specified accordingly. However, the interfaces to the mobile application (public facing) will probably be required 24/7. AFCS quality: While fare collection needs to be recording 100% of passengers, expressing this as a metric needs to be carefully considered. If the desired metric is ticket sales broken down by tendered method (cash/closed loop/concessions), one needs to consider whether this should be expressed per stop, trip, or journey. There would need to be a qualifier as to how the data accuracy is verified. This should be expressed as a percentage measured against manual surveys or third-party systems, as specified by the authority.

2.6.2 Quality SLAs Beyond component availability, the data quality was specified in the RfPs, e.g. ETA accuracy. 70% accuracy was expected in RfP B, compared to 95% in RfP Cand 90% in RfP A. Forecast accuracy in RfP C was set at -2 minutes to +7 minutes, and in RfP B, less than 5 minutes. RfP A did not specify the required accuracy of the forecast. a. ETA accuracy: The specification for this function should explicitly rule out timetable offset as a method of ETA calculation. The offset method takes the bus delay at the start of the trip and applies this delay uniformly to estimate the time of arrival and departure at each stop. For example, if the bus is 10 minutes late leaving the starting point, the ETA at each stop becomes the scheduled arrival time plus 10 minutes. Today's systems should be accurately (re)calculating the ETA across all trips/stops throughout the journey. The data accuracy is currently specified as ±3 minutes, and it is unclear from the specification how this is to be measured. This level of accuracy is unrealistic to achieve for every prediction. The data accuracy can fluctuate over the period for which the prediction is made. For example, when the bus is 30 minutes away, the variance can be higher, at say ±5 minutes, whereas when the bus is less than 10 minutes away, the accuracy should be set to ±2 minutes. When the bus is 3 minutes or less away, the accuracy should be ±1 minute. b. Table 1 provides a sample ETA accuracy requirement specification followed in the United Kingdom.6 The ‘BUCKET’ column specifies the time for the bus to reach the point of measurement (bus stop/terminal), while the ‘ALLOWABLE EARLY’ and ‘ALLOWABLE LATE’ columns specify the accuracy threshold.

6 RTIGT041-1.0 Accuracy and Quality of Real Time Predictions.pdf (SECURED)

Future proofing ITMS investments| 27

c. Table 1: Potential ETA SLAs for AVLS contracts Bucket 0-3 minutes 3-6 minutes 6-12 minutes 12-18 minutes 18-30 minutes

Allowable early 60 seconds -90 seconds -120 seconds -150 seconds -180 seconds

Allowable late +60 seconds +120 seconds +210 seconds +240 seconds +360 seconds

2.6.3 ITMS performanceSLAs The resolution time in RfP A was 4 hours, and in RfP C, between 2 hours and a day, based on the level of urgency. RfP B did not specify any resolution timeframe; however, the PISrelated rectification time was specified, at 48 hours. a. AVLS performance: ● expected AVLS location accuracy: +<15 metres ● See 2.6.2a (ETA accuracy) if the calculation is to be performed in the AVLS. b. AFCS performance: The latency or speed of specific financial transactions should be less than 250 milliseconds or that recommended by target banks/clearing services. c. Overall performance: The monthly reports are crucial for the payment process. An exercise should be conducted to specify the required speed of business processes and the speed requirements for data transactions within the ITMS. d. Resolution time - The resolution time for the system can be classified according to Priority 1, 2, and 3 based on road user safety and impact on system control/monitoring and provision of information to the public. The P1 resolution time should be 15 minutes, P2 - 2 hours, and P3 - 1 working day. B. It is recommended that STUs form a coalition and develop a common SLA framework applicable across bus agencies, even though STU-specific mandatory values/requirements may be permitted to ensure local compatibility.

2.7 Financial specifications 2.7.1 Payment terms and penalties A. Payment distribution: The reviewed RfPs mentioned payment of up to 70% at golive. This approach results in the majority of payment being disbursed before the operational period, which leaves the vendor with limited incentive and low accountability to operate and maintain the system beyond the go-live event. It is recommended to equally spread payments across the contract period to ensure the vendor stays invested in provision of the project’s deliverables with high quality. B. Invoice frequency: The frequency of invoicing is either monthly or quarterly. If the invoicing occurs monthly, there is high dependence on the quality of the system’s

Future proofing ITMS investments| 28

output, and there might not be enough time to manually verify operations to ensure there are no errors. C. Penalty: The penalty cap in RfPs A and C was 10%, while RfP B capped penalties at 25%, which is rather high. D. Incentive: RfP B included an incentive for consistent good performance across 3 months, which is a welcome strategy to encourage vendors to improve their performance.

2.8 Conclusions The comparative analysis of the RfPs identified several procurement scenarios that have scope to provide greater levels of detail, as well as items like KPIs that are specified differently across documents. A national initiative to harmonise ITS RfP specifications and establish a benchmark for good practice based on the evolving global ITMS landscape is therefore recommended.

Future proofing ITMS investments| 29

3. Next generation transit payment technologies in Indian public transport systems 3.1 Introduction Payment digitalisation in public transport systems is an agreed objective across national, state, and city governments, as well as public transport operators and users, given the various benefits, like ease of use for customers, lower cost of revenue collection for operators, and better data on system usage, which can facilitate the development of improved fare products for users and better service planning for operators. GoI is promoting the National Common Mobility Card, a smart card-based payment system to digitise fare payments. While NCMC rollout has been successful in some cities, it is yet to achieve large-scale adoption across cities. Another GoI initiative, the Open Network for Digital Commerce, is accelerating mobile ticketing across cities. Separately, cities like Delhi, Bengaluru, and others have taken up various initiatives to promote mobile ticketing. The next phase of innovation in payment digitalisation needs to focus on multimodal ticketing and Mobility as a Service (MaaS), which requires a seamless ticketing experience across smart card/mobile tickets, as well as facilitating the use of public transport within passengers’ overall journey, which may also include other on-demand modes. Globally, cities with advanced ticketing have been focusing on account-based ticketing (ABT), which tracks user journeys across modes and payment technologies to understand travel patterns better and design fare products accordingly. Given the rapidly evolving nature of the topic, the key recommendations on ticketing have been identified in consultation with leading industry experts in India and worldwide through Mobilogues, a webinar hosted by GIZ. The recommendations are summarised here, while the detailed discussions are captured in Annexure 2.

3.2 Key areas of focus for next generation transit payment technologies 1. Open loop payments: Open loop cards cover for ‘first ride risk’ wherein the card issuer, i.e., the transit agency covers the cost of the first ride if the payment made by the user is not validated due to causes like insufficient account balance or payment failures. This guarantee of cover is capped at a certain amount by the card issuing agency. The first ride risk shared liability is of prime concern in the case of open loop payment implementation, because of which Indian transit agencies still prefer stored value cards. To address the risk, there should be a strong backend framework to keep the ‘deny list’ (passengers denied entry due to insufficient balance) updated to ensure that further authorisations of the same card are prevented. Experience from cities with experience in open loop cards demonstrates that

Future proofing ITMS investments| 30

the revenue lost due to first ride risk would be limited and the advantages associated with the ease of open loop payments would outweigh the losses incurred by transit agencies.

2. Tokenisation of smart cards Another important issue in the open loop model to be resolved is the protection against fraudulent use of the account numbers. This can be achieved through tokenisation by adding another factor of authorisation at an additional charge. The RBI guidelines currently allow the NCMC to be issued with a limit of Indian Rupee (Rs.) 3000 without Know Your Customer (KYC) verification. There is work to be done in changing policies and regulations around the use of other cards for transit transactions to ensure security. 3. Service-based models for payment solutions One way to facilitate the technological upgradation of payment systems is to switch from the traditional product-based model to a service-based one. This model promotes the constant upgrading of the system without overhaul, while the onus is on the vendor to upgrade the system as and when required. The product-based model tends to lock in the vendor’s currently used technology and does not allow for change. 4. Modular, outcome-based procurement approach The modular procurement approach separates the back office from the front, where the system that manages fares and fare rules is different from the card issuer and the validation technology. This type of procurement provides the flexibility needed for the system to adapt to newer validation technologies on the front end, while the back end has a fixed role to play. 5. Leveraging existing apps to promote multimodal journey payments As cities are moving towards multimodality, the need for multiple payment modes through different applications is becoming increasingly important. To enable this, there is a need for interface standardisation for APIs, software development kits (SDKs), etc. This will encourage current users of ride hailing applications to shift to public transport, thanks to the ease of payment systems and availability of information on one platform.

Future proofing ITMS investments| 31

4. Annexures 4.1 Annexure 1: Comparison ofITMSspecifications across 3 RfPs and MoHUA guidelines (2021) 4.1.1 SCOPE OF WORK Particulars

Description

Components

Automatic vehicle location system (AVLS)

Request for proposal (RfP) A Present

Contract management system (CMS)

Present

RfP B

RfP C

MoHUA ITS Guidelines

Present

Present Present

Depot management system (DMS)

Present

Passenger information system (PIS)

Present

Incident management system (IMS)

Present

In-bus surveillance/on-bus CCTV

Present

Automatic fare collection system (AFCS)

Present

Inventory management

Present

Development & implementation

48 weeks

24 weeks

Operations & maintenance

6 years

4 years

Number of buses

10000

5000* (e-buses come with builtin AVLS)

25 months* (includes traffic information & management system) 5 years

Not specified

3500

Not specified

Future proofing ITMS investments| 32

Pilot

Bus monitoring system coverage

5 cities

No pilot

Number of routes

Not specified

Number of buses

DMS coverage

1 depot

4.1.2 Payment terms Particulars Capital expenditure (CAPEX) Operating expenditure (OPEX) Invoice frequency Payment mechanism Penalty Penalty cap

Description

RfP A

RfP B

No CAPEX

RfP C 68%

MoHUA ITS Guidelines Not specified

70% CAPEX

25% of yearly per bus cost and cost per electronic ticketing machine (ETM) Monthly

32% of CAPEX + OPEX

Not specified

Quarterly

Through escrow account linked to CMS Up to 3% of monthly payment The penalty is capped at 10% of the quarterly invoice. If this 10% cap is exceeded for the 2nd consecutive quarter, Convergence Energy Services Limited (CESL) will have the right to take appropriate penalising actions, including

Request for payment to Chief System Manger, BMTC Up to 1% of monthly payment 10%

Unclear

Not specified

Lumpsum

Not specified

Maximum penalty applicable on quarterly applicable payment for not adhering to the service level agreements (SLAs) is capped at 25% of the quarterly applicable payment proposed by the contractor.

Not specified

Future proofing ITMS investments| 33

termination of the contract.

Incentive

Not specified

3 months of sustained performance = 0.25%

Not specified

4.1.3 Automatic vehicle location system Particulars

Description

RfP A

RfP B

RfP C

MoHUA ITS Guidelines

Functional requirement

Project scope (HARDWARE)

On-Board Intelligent Transport System (OBITS) pre-installed in the e-bus (AIS 140 compliant): (Single control unit (SCU)/onboard unit (OBU) Driver Display Unit (DDU), Passenger display boards CCTV with mNVR, camera-based automatic passenger counters (APCs), panic button, amplifier, speaker, route network)

ATD & emergency button to be AIS 140 compliant

OBITS (SCU & BDC) specification for procurement clearly mentioned: (SCU, Global Positioning System (GPS) module, combi antenna, bus driver console)

Geographic information system (GIS)-based AVLS and integrated PIS application software

Future proofing ITMS investments| 34

Particulars

Communication requirements/ dashboard & graphics interface

Description

RfP A

RfP B

RfP C

MoHUA ITS Guidelines

Project scope (SOFTWARE)

Route network Roster, duty allocation Maps – real-time vehicle tracking Route replay Dashboard Management information system (MIS) reports

CAD/AVL central software Location playback Maps Prediction software requirements System security requirements Operational requirements Performance requirements MIS reports

Operational requirements Software location playback System requirement Maintenance mode Operational requirement Scalability/future operational requirement Reports Web page & maps Real-time PIS requirement: prediction software

PREDICTION Software requirements

Predictive algorithms to estimate travel time to upcoming stops, considering traffic conditions, historical travel patterns, and current route dynamics Module shall receive data packet from pre-installed OBITS every 5 seconds.

Operations dashboard Key performance indicator (KPI) dashboard Live bus location module Route replay module Planning and scheduling module Dispatch management module Incident management module Reporting/MIS module Data master module Not specified

As specified in the Ministry of Housing and Urban Affairs (MoHUA) guidelines

The system shall use the real-time location and schedule adherence data to create a continuously updated table and XML data feed of the last reported location for all vehicles and the next arrival predictions for all stations/stops.

ATD to send data every 10 seconds

Onboard computer will send the location data every 10 seconds

Not specified

Communication between the CAD/AVL server and the OBU shall be wireless 3G/4G or upcoming 5G connectivity provided by a

COMMUNICATION requirements

Network & hardware requirements

Data shall be updated through the latest available communication technology (4G/5G)

Future proofing ITMS investments| 35

Particulars

Description

RfP A to the central solution for all the buses. Dashboard to display KPIs 1. Operational monitoring (reliability, availability, punctuality, frequency, safety of operations, operational infractions, etc.)

RfP B

RfP C

MoHUA ITS Guidelines

single communication company KPI dashboard 1. Buses in operation 2. Plan vs. actual model 3. Incident count 4. Earnings per kilometre (km) 5. Running averages of buses 6. Crew utilisation 7. Bus utilisation 8. Schedule adherence

I. Schedule master II. Route master III. Bus stop master IV. Depot master (for future requirements) V. Crew master VI. Onboard computer master VII. PIS master VIII. Landmark master

AVLS data reports 1. Headway adherence 2. Active fleet 3. Service hours and mileage 4. Schedule adherence 5. Speed report 6. Route deviation report 7. Trip performance report

29 MIS reports

Integration requirements

DATA FORMAT requirements

2. Intelligent management transport system (ITMS) status (ITMS solution functioning, OBITS) Export bus operations data in GTFS format.

Integrate with General Transit Feed Specification (GTFS).

Capable of sharing the bus probe data in GTFS format

<< GTFS or journey web 2.0 >> format or any other application programming interface (API) as required (including the GTFS Real-Time Extension and fare attributes), (and through public access APIs to ensure all potential users (in both the public and private sectors) have access and for integration with the future AVLS and PIS or any other public information methods, as decided by the purchaser.)

Future proofing ITMS investments| 36

4.1.4 Contract management system Particulars

Description

RfP A

RfP B

RfP C

MoHUA ITS Guidelines

CMS for cities

KEY OUTPUTS

Shall be integrated with the AVLS.

Not present

Service parameters such as km travelled, schedule and timetable adherence, and service infractions can be monitored through AVLS and MIS in order to compute service payments, performance incentives, and deductions.

Not present

Not specified

Not applicable

Not specified

Per km rate, performance against parameters like planned vs. actual operations, breakdowns, accidents, etc. CMS for operator

Pro forma invoice with details of assured km, run km, amount receivable, penalties, incentives, performance against KPIs Dashboard with city operations, payment information

CMS for MoHUA/CESLor any other relevant supervising authority

4.1.5 Depot management system Particulars

Description

RfP A

RfP B

RfP C

MoHUA ITS Guidelines

Functional requirement

Project scope (SOFTWARE)

Not present

Planning and scheduling module Dispatch management module *Both the modules are included in the AVLS module

Vehicle scheduling & dispatching & crew rostering

Vehicle scheduling & crew allocation

Detailed requirements of the application provided

Future proofing ITMS investments| 37

Particulars

Communication requirements/ dashboard & graphics interface

Description

RfP A

RfP B

RfP C

MoHUA ITS Guidelines

Project scope (HARDWARE)

Not present

Not specified

KEY OUTPUTS

Not present

Planning functionalities (network and trip plan, timetable and vehicle planning, crew scheduling, roster and dispatch, crew efficiency, performance monitoring)

Details of workstations, printers, biometric readers, & uninterruptible power supply (UPS) provided Planning reports (route, schedule, timetable, crew rostering, allocation, utilisation, actual vs. schedule, etc.)

Dispatch management functionalities (dead km, running km, Earnings per km (EPKM), km per litre (KMPL) of operation, crew utilitsation, bus utilisation %, incidents/alerts)

Installation requirements

Not present

Performance analytics (Managed reporting, Online Analytical Platform (OLAP) analysis, ad hoc querying, score carding, business activity monitoring, data extraction from AVLS, scheduling & dispatch and IMS, ticketing) Not specified

Not specified

MIS reports (Distance, depot, station, route reports, anomalies, comparative)

Other reports (Breakdowns, accidents, vehicles in/out, pending maintenance, KMPL for each fleet, vehicle fitness certificate , road permit history, complete history of individual vehicle maintenance by month and year)

Detailed installation location requirements provided

Not specified

Future proofing ITMS investments| 38

4.1.6 Passenger information system (PIS) Particulars

Description

RfP A

RfP B

RfP C

MoHUA ITS Guidelines

Functional requirements

Project scope (SOFTWARE)

Mobile app to display the following info: - Current stop name - Route no. and name - Estimated time of arrival (ETA) for the next 5 buses (bus registration no.), (number should be configurable through the application)

Passenger mobile application

Website requirement SMS Mobile application requirement

-Mobile ticketing with journey planner -Journey planner - Integration with payment gateway/wallet - Open architecture/API - Concessional management - Feedback system

All 14 features required in the app - service/route number - origin - destination - enroute stops - ETA

To deliver real-time updates on - bus arrival times - service disruptions Project scope (HARDWARE)

PIS boards at all bus stops Specifications not present

Content refresh rate (CRR) deviation

For bus stop/station PIS boards - content mentioned

PIS boards at all bus stops (LED display boards with detailed specifications, including board size, viewing size or visible display area,, functionality, storage, electrical parameters (such as input voltage, power consumption, frequency), memory, environmental parameters) Maximum deviation from ETA of 5 minutes, Content refresh rate of 1 minute or

Content can include: - transport-related information (bus schedules, alerts, etc.) - safety information - localised community information - GPS-driven localised data, - environmental data - advertising (still images, animation, video) - tourist information Real-time PIS display boards (Detailed specifications of LED display boards, power supply and UPS, pole provided)

Content, storage, display refreshed

Future proofing ITMS investments| 39

Particulars

Communication requirements/ dashboard & graphics interface

Installation requirements

Description

INPUT, PROTOCOLS, DASHBOARD, MIS REPORT

RfP A

RfP B

RfP C

displayed for the next 5 (configurable) buses CRR for PIS display: ideally 1 minute or less Synced with PIS through AVLS

less, display time at least every 10 seconds and specifications of content of PIS boards

automatically every 10 seconds

Information pushed to/pulled from the central server

Inputs from the central system - system management commands, static display, real-time display, ad hoc info

MIS reports - list of PIS, availability, and message delivery

LOCATION & NUMBER

Not specified

MoHUA ITS Guidelines

API and integration document to be provided to integrate with PIS, that complies with National Transportation Communications for Intelligent Transportation Systems Protocol (NTCIP) Detailed location requirements provided

Not specified

4.1.7 Incident managementsystem Particulars General requirements

Description

RfP A

RfP B

RfP C

MoHUA ITS Guidelines

Effectively manage and resolve any incidents that occur during bus service operations, enhancing safety and minimising disruptions.

Incident management module is part of the AVLS

Not present

Incident response and management can be supported by AVLS, and PIS can help in communicating the disruption/change in service to commuters.

Future proofing ITMS investments| 40

System functional requirement

Hardware requirement Communication requirements/ dashboard & graphics interface

Integration requirements

a. User management (username, access level, groups) b. Incident master (incident category, sub-category, incident severity level (e.g. low, medium, critical), operational infractions category, incident status, turnaround time (open, in-progress, closed, re-opened)) c. Module master (CMS, AVLS, AFCS, PIS, mobile app for selection filter) d. Operation master (operating hours, non-operating hours) Not specified

25 different types of incidents

Not present

Not specified

Not present

Not specified

− Total incidents (day wise, month wise) (accidents/breakdown/module not working/other issue) − Total open incidents (day wise, month wise) − Total closed incidents (day wise, month wise) − Total re-opened incidents (day wise, month wise)

Each incident to be given an ID, and incident resolution to be delegated based on predefined hierarchy and tracked until successfully completed.

Not present

Not specified

Not present

Not specified

Filtered - hourly, daily, monthly, by user Internally with AVLS, mobile app Externally with network management module - for system

Future proofing ITMS investments| 41

health, performance, device uptime & downtime

4.1.8 In- bus camera & mNVR Particulars

Description

RfP A

RfP B

RfP C

MoHUA ITS Guidelines

General requirements Functional requirement

PURPOSE

Primarily for emergency Camera-based APCs CCTV with mNVR used for panic alerts (AIS 140 Compliant)

Primarily for emergency

Not present

- 2 cameras per bus - Mobile Network Video Recorder (mNVR) - emergency button

Not present

Not specified

Detailed specifications provided

Not present

Provide onboard CCTV system feed to be accessible on mobile phones for authorised users 4 on-board CCTV cameras installed in each bus, including a dashboard camera Ensure image and video storage and recording, integrate with SCU to enable data transfer to the video management software via Wi-Fi at depot on request by the dispatcher Not specified

Project scope (HARDWARE)

Hardware requirement

4.1.9 Automatic fare collection system Particulars

Description

RfP A

RfP B

RfP C

MoHUA ITS Guidelines

Functional requirement

Project scope (SOFTWARE)

Software as a service (SaaS) based, with back office, NCMC card integration, smart card, etc.

Not present

- General requirements - GUI requirements - System security requirements - System & other equipment - operational requirements - cash up & deposit- operational requirements - smart card requirements issuance/renewal/management/operational/validation is

- system security - industry standards - NCMC card compliant

Future proofing ITMS investments| 42

Project scope (HARDWARE) Communication requirements/ dashboard & graphics interface Integration requirements

- all payment modes - central AFCS - ETM - Graphical User Interface (GUI) - configuration management - transaction management - fare & media products - settlement and revenue reconciliation - inventory management - audit trail - MIS reports Not specified

displayed on the handheld device - paper tickets - user interface - onboard storage - user login - paper ticket sales

Not present

Not specified

20 MIS reports for the fare collected

Not present Not present

Not present

Data requirements - transactional database - scalability/future operational requirements -reports of operational requirements

Internally with AVLS, mobile app, ticketing

Not present

Not specified

Externally with validators, bank interface

Future proofing ITMS investments| 43

4.1.10

Service level agreements

Particulars

Description

RfP A

RfP B

RfP C

O&M Phase

CMS availability

99.90%

Availability of operations vehicle-mountable OBITS

Not specified

>90%

Not specified

Vehicle-related online information availability

Not specified

>90%

Not specified

ATD - maximum 10 second update time

Not specified

Bus camera uptime

Not specified

IMS availability

99.00%

Not specified

Commuter mobile application service

99%

<90%

Not specified

Commuter mobile application screen load

Not specified

<5 seconds

Not specified

PIS availability

99%

<30 seconds

99.90%

ETA accuracy

90%

<95%

70%

ETA/estimated time of departure (ETD)

Not specified

<90%

Forecast accuracy

Not specified

<5 min

70 (-2 to +7 min)

Availability of SCU & BDC

Not specified

99.00%

AVLS availability

<95%

99.50%

AVLS accuracy

Not specified

<96%

Not specified

Avg OBU rectification time

Not specified

<48 hours

Not specified

<48 hours

Not specified

Avg PIS rectification time AFCS availability

99.00%

Not specified

ETM availability

99.90%

Not specified

Missing transactions

Penalty defined per missing transaction Not specified

Not specified

Application module access to the authority on 24/7 basis Availability/uptime of cloud services resources for production environment

Future proofing ITMS investments| 44

Particulars

Description

RfP A

RfP B

RfP C

Availability of the network links at Data centre and Data recovery, (DC and DR) Vulnerability management

Not specified

Service level for Data Recovery – Recovery Point Objective (DR – RPO) Service level measurement of cash collection for depot wise allocated ETMs Availability/uptime of ETMs

Not specified

ETM connectivity - reliable Sim card connectivity without any data loss, seamless connectivity when moving between bus stops Mean ETM repair time

Not specified

Business Operations Analytics Platform (BOAP)

Not specified

<95%

Not specified

App response time

>3 sec

Not specified

Resolution time

4 hours

Not specified

>2/4/8 hours

DMS availability

Not specified

99.50%

Security breach

Per instance

Not specified

Mock drill of DC and DR

Every 6 months

Not specified

Helpdesk

>15 min

Not specified

Unavailability of key personnel

Daily

Not specified

Future proofing ITMS investments| 45

4.1.11

Change management andhuman resources

Particulars

Description

RfP A

RfP B

RfP C

Training and capacity building

Key outputs

Training shall be provided to the depot staff, drivers, and bus operators, along with user manuals and standard operating procedures (SOPs) for effective use of proposed solution, i.e. all software modules and ETMs - Integrating the ITMS with existing or new hardware or software systems, including but not limited to existing ITMS implemented in the cities and existing/new hardware devices procured during the term of the contract • Collaborate with third parties to develop and test APIs as per the requirement of the CESL or cities. • Conduct end-to-end testing and prepare integration documents for future references.

-Training manuals and ppts to be prepared - Operation and maintenance manual - Regular updates of training aids

Detailed training modules for every user, details of training material content mentioned

Integration (overall)

Change management

Exit management/ transition planning

Unclear

MoHUA ITS Guidelines Detailed steps to carry out the training and agency responsibility have been laid out

- Responsibility of implementing agency to integrate with existing city-level ITMS - Submission to public transport authority (PTA) or appointed third party

- Change before go-live possible - After go-live, only changes that requires less than 5 man-days possible - Approvals to be taken Unclear

Unclear

Future proofing ITMS investments| 46

Human resources: Implementation agency Human resources: Contracting agency Team

Roles listed

Project team listed - 21 people, 1 person per city

Project team listed - 2 people in implementation phase, 6 people after go-live

Defined for each module

Future proofing ITMS investments| 47

4.2 Annexure 2: Webinar summary on next generation transit payment technologies for India GIZ is conducting the Mobilogues series of online dialogues on urban mobility issues. A Mobilogues session was conducted on 15 October 2024 to take stock of the existing developments in payment technologies in India, identify potential areas for improvement, and discuss strategies to bring in the next phase of technology advancement towards accountbased ticketing (ABT) and Mobility as a Service (MaaS). The format of the session was as follows: ● Welcome remarks and introduction to the Sustainable Urban Mobility – Air Quality, Climate Action, and Accessibility (SUM-ACA) project by Narendra Verma, Technical Advisor, GIZ ● Ravi Gadepalli, independent consultant provided an overview of the current Indian practice on transit payments and potential venues for improvement based on good practices followed globally. ● Introductory remarks by panellists (5 min each): ‘Key trends shaping digital payments in public transport’ ○ Denny Thomas, NPCI ○ Thea Fisher, VISA ○ Giacomo Biggiero, Masabi (MaaS provider) ○ Nitin Nair, ONDC ● Q&A with the moderator (2-5 min each): ‘Key challenges in expanding your solution in India’ ● Q&A with participants ● Closing remarks by speakers and moderator

4.2.1 Key topics discussed Account based ticketing: challenges, risks, & mitigation The NCMC is a stored value card that requires balance top-up. Currently, users need to visit add value terminals to recharge their cards, which can be inconvenient. ABT is a good option to address this issue. However, the primary challenge with ABT, which the National Payments Corporation of India (NCPI) faced during the NCMC design phase, is the risk associated with first rides, which no entity was willing to absorb. As a result, the NPCI developed specifications for a stored value product to mitigate these risks. Worldwide, there are useful examples of how this first ride risk has been overcome. In the case of Transport for London (TfL), open loop payment entails a user tapping their contactless card at a gate. First, the system checks for card validity (expiry and stolen status) through a locally stored deny list. If the card is valid, it moves onto the next step of authorisation, where nominal value authorisation occurs during travel. If the card is declined (e.g. due to insufficient funds), it is added to a deny list, preventing future access until the outstanding debt is resolved. The next time the commuter travels, the card will be denied. In some regions, there are shared Future proofing ITMS investments| 48

liability limits that protect transit agencies against first ride risks, allowing them to accept open loop payments even if payment is not immediately successful. There are many advantages of account based or open loop payments. A recent market survey of 3000 transit agencies that had implemented open loop payments showed an average 9.5% increase in ridership7. However, one of the downsides of upgrading transit networks to support open loop payments is the significant investment and complex design required. High transaction volumes during peak times can strain bandwidth, necessitating robust infrastructure. There are existing solutions that can enhance transaction processing capabilities for acquirers and back-office providers that are yet to be explored. Advantages of the modular procurement approach There are advantages to unbundling the payment solution. By using an open platform approach, the solution provides back-office components that support a plug-and-play model. This model allows transit agencies to easily integrate various components without the need to overhaul their entire system. With this, agencies can replace or upgrade specific elements like validators, acquiring solutions or customer relationship management (CRM) systems independently. This modularity fosters rapid innovation and prevents vendor lock-in. If an agency wants to introduce new technology, such as a new gate line or station, they can do so without reworking the entire system, enhancing operational efficiency. In this integration process, it is crucial is that the interfaces (APIs and SDKs) between the modules are standardised. This requires thoughtful selection of both back office and hardware components, enabling smooth collaboration between systems. Agencies should maintain control over their applications and configurations to easily adapt to new capabilities as requirements change. Overall, advocating for a modular approach not only promotes innovation but also provides transit agencies with the flexibility needed to adapt to changing technologies based on consumer needs. Merchant discount rate in payment transactions Currently, payment systems operate independently, but the Open Network for Digital Commerce (ONDC) has the goal of developing an integrated approach that encompasses various modalities and use cases. The role of the ONDC is limited to facilitating payment and ticketing without directly issuing tickets. Both transit entities and buyer apps have the flexibility to collect payments on behalf of consumers. Hence, any associated costs will likely be passed on to consumers. Initially, one entity may absorb the costs, but as the system stabilises, these costs will need to be accounted for. For example, Delhi Transport Corporation (DTC) has stated that additional costs, such as buyer app commissions, are charged to consumers. It is anticipated that a lifecycle for fees similar to early utility payments, which charged a convenience fee, may be introduced. The initial free service might prevail until the system matures. Over time, as digitisation reduces costs (e.g. those associated with physical ticketing and cash handling), these fees could decrease or be eliminated. Ultimately, as digital payments

7 VISA (2023) Reimagining ridership:

Open-loop payments and the future of urban mobility (URL: veei-reimagining-

ridership.pdf)

Future proofing ITMS investments| 49

become more prevalent, the efficiency gains and cost offsets may lead to a situation where the benefits outweigh the initial costs, allowing for a more sustainable model.

4.2.2 Panel discussion Question: In the cities where you have worked, supported cities purely on just as a ticketing solution for the public transport versus being a mobility as a service (MaaS) provider providing integrated multimodal journey planning and ticketing solutions, how has the user acceptance changed? Has it grown at all? Has it not been impacted? Or how has it worked? And what are the costs? And we are not sure of the extra cost associated with mass versus integrated ticketing. MaaS vs. leveraging existing applications There are two approaches to MaaS in urban environments. First, there are city-centric applications, where cities have decided to invest heavily in developing their own MaaS platforms. This involves creating a new application, integrating various transport modes, and implementing marketing efforts to promote it to citizens. The alternate approach is leveraging existing apps. If popular mobility apps (like Uber, Lyft, and transit apps) are identified that users have already installed, instead of building a new platform, integrating mass transit ticketing into these existing apps allows users to discover public transit options during their rides. This makes information more accessible without significant new investment from transit agencies. This second approach not only reduces costs but also increases ridership by using apps that users are already familiar with, while simultaneously raising questions about data ownership and control. The way to enable this has been to provide interfaces, i.e. APIs and SDKs, to third-party apps to sell rights for mass transit. Question: In an evolving ecosystem where there is a trend towards mobile payments or something else, how does the city decide for the next 5–7 years which technology to procure and, more than the procurement issue, how do you see the overall ecosystem panning out there? Regarding tokenisation, even if you have a smart card that can be tokenised and included in a mobile phone, is that the way forward? How do you see the future of cards in general? Technology procurement Payment methods are ever-changing, and building flexibility of choice for the customer into the system is key. There has been success in the service-based model approach, rather than traditional design-and-build contracts. The service-based model allows transit agencies to specify desired solutions and experiences, promoting innovation and efficiency. Furthermore, a modular approach enables transit agencies to replace or adopt a system component (like validators or payment systems) without disrupting the entire system. There needs to be a shift from the large CAPEX to OPEX model, which facilitates scaling over time based on increased usage. This is a more forward-looking approach, where the solution is built for the next 5–7 years and beyond.

Future proofing ITMS investments| 50

Question: People want to validate or use their cards on their mobiles. But is it possible to tokenise a public transport ticket, put it on a mobile, and validate it online? So that's one question. And the second question is on the pay as you go service as London calls it or the mobility transaction framework that Tia explained earlier, where at the back end of the system, you keep track of all the transactions that the user did and then cap off the payment at a given point. You don't need account-based ticketing for that; even with the rupee card, you can do that, right? So, are there any plans to get into that at all, the tokenisation and the pay as you go service? Challenges of NCMC tokenisation There are currently limitations imposed by regulators on stored value for payment systems, with a maximum limit of ₹2,000 per card. This presents a challenge when larger transactions occur, creating ambiguity around the overall spending limit for customers. Tokenisation of smart cards or a stored value card is not a technology problem; it is more of a policy or regulator problem that needs to be sorted. The pay as you go model is technologically possible, but the frameworks for it are not in place.

4.2.3 Summary of individual panellist views Mr. Denny Thomas, NPCI Mr. Denny Thomas mentioned that, based on discussions with transit operators, it is clear that the issues pertaining to India within the transit ecosystem are very specific. The payment solutions have thus far focused predominantly on metro rail systems, while the bus agencies, with higher demand, have seen limited adoption. The payment solutions will have to be tested for the bus systems and specific customer segments. The system ought to be looked at holistically to solve issues like digitisation of paper tickets, reducing leakages, etc. Ms. Thea Fisher, VISA Ms. Thea Fisher emphasised the need for a consumer focus when looking at payment modes. She proposed the introduction of open loop ABT, in addition to NCMC cards, to provide the consumer the freedom to choose. She also suggested looking at existing systems and figuring out ways to incorporate or improve payment management systems to simplify payment and make the business profitable for transit operators. Mr. Giacomo Biggiero, Masabi (MaaS provider) Mr. Giacomo Biggiero had three strong recommendations for the way forward for the Indian public transport sector. First, procurement for payment technologies should shift from the design, build, operate, and maintain (DBOM) model to a service model. With the fast pace of technological advancements and changing payment modes, the service model facilitates continuous innovation, whereas a DBOM model means lock-in for the agency for long periods of time. The second is to create outcome-based procurement, where the focus of the vendors is on the business outcomes. This allows vendors to innovate and provides them the freedom to define the appropriate innovation and technology to achieve the assigned business outcomes. Finally, he pushed for splitting up the solution into different modules, primarily to separate the front end from the back office. This modular approach will lead to the back office being focused on calculating the best fare, regardless of the token, while the front end can be replaced as and when the tokens change or need updating.

Future proofing ITMS investments| 51

Mr. Nitin Nair, ONDC Mr. Nitin Nair mentioned that the unified payments interface (UPI) from the National Payments Corporation of India (NCPI) is the precedent for digitisation and a software-led approach, and the goal should be to not only replicate the UPI’s success story, but also go beyond payments. This would mean looking at the entire ecosystem of schedule information, availability, multimodal integration, etc. He believes this will add value for commuters, as it will make travel simpler and more convenient than in the standalone digitisation scenario.

Future proofing ITMS investments| 52

Future proofing ITMS investments| 53

Futureproofing ITMS Investments