REQUEST FOR PROPOSAL

DEVELOPMENT, IMPLEMENTATION, OPERATION AND MAINTENANCE OF INTELLIGENT TRANSIT MANAGEMENT SYSTEM (ITMS) FOR SURAT MUNICIPAL CORPORATION, SURAT

PART 2 – SCOPE OF SERVICES AND TECHNICAL SPECIFICATIONS

AUGUST 2015 SURAT MUNICIPAL CORPORATION GUJARAT. INDIA Table of Contents

1. List of abbreviations used in the document 7 2. Introduction 9

2.1. Objective of Implementing ITMS 9 2.2. ITMS Requirement Summary 9 2.3. Purpose of Open ITS standards & Architecture 11

3. Solution Overview 13

3.1. Integrated ITMS Overview 13 3.2. BRTS Bus Station ITS Overview 14 3.3. City Bus Station ITS Overview 15 3.4. BUS ITS Infrastructure Overview 15 3.5. ITMS Communication System Overview 17

4. Functional Specifications for ITMS 18

4.1. Integrated Operations Management Platform 18 4.2. Automated Vehicle Location System 19 4.3. Passenger Information System 20 4.4. Vehicle Scheduling and Dispatch System 21 4.5. Depot Management System 22 4.6. Functional Solution Landscape 22

5. Technical Specifications for ITMS 24

5.1. GPS Based Automated Vehicle Location System 24 5.1.1. Bus Vehicle tracking device 24 5.1.2. AVLS Software: 25 5.1.3. AVLS Controller Software Functionalities 25 5.1.4. Driver Console Configuration & Management 27 5.1.5. PIS Display Configuration and Management 27 5.1.6. Maintenance Requirements 28

5.2. Passenger Information System 28 5.2.1. PIS at Bus Stations and terminals 28 5.2.2. Display System Technical Requirement (PIS): 29 5.2.3. PIS on bus 30

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 2 of 178

5.2.4. Web Portal for Bus Schedule &ETA 31

5.3. Depot Management System 31 5.3.1. Stores and Inventory 33 5.3.2. Depot Personnel HR and Payroll 34 5.3.3. Human Resource Management 34 5.3.4. Payroll Application Requirements: 34 5.3.5. Specifications for DMS work Stations: 35

5.4. Incident Management System 35 5.4.1. Emergency/incident management 35

5.5. Call Centre Management 36 5.6. Computer aided Scheduling and Dispatch 37 5.6.1. Computer Aided Dispatch 37 5.6.2. Schedule Adherence Support 38 5.6.3. Route Condition Monitoring 38 5.6.4. Dynamic rescheduling 39

5.7. Central Control Centre (CCC) 40 5.7.1. System Description of CCC 40 5.7.2. General Software Architecture for SMC 43 5.7.3. Typical View for Software Components and Interfaces 44 5.7.4. CCS Communication Links: 44 5.7.5. CCS hardware and software 44 5.7.6. Configuration Data Management 45 5.7.7. Data Storage 46 5.7.8. CCC Security 46 5.7.9. Clock Management 47 5.7.10. Reports 47

5.8. Fare Gate 48 5.8.1. Function of fare gate – Flap Type 48 5.8.2. SECURE ACCESS via GATE ADAPTATION KIT 49 5.8.3. Features of fare gate 49

5.9. Flap Gate Validator 51 5.10. Business Intelligence Platform for Reporting 53 5.10.1. Management Dashboard 53 5.10.2. Searching & Filtering 55

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 3 of 178 5.10.3. Reporting 56 5.10.4. Data Retrieval & Management 59 5.10.5. ETL 60 5.10.6. Data Quality Management 62 5.10.7. BI Configuration and Management 62 5.10.8. Dashboard and Reporting Requirement for ITMS 64 5.10.9. Transit Performance Measures 65

5.11. Enterprise Management System 67 5.11.1. Management of Infrastructure at Client-side locations 68 5.11.2. Detailed Specifications for Enterprise Management System 69 5.11.3. Network Fault Management System 69 5.11.4. Configuration Management 71 5.11.5. Service Level Management 72 5.11.6. Performance Management: 73 5.11.7. Server Performance Monitoring: 77 5.11.8. Database Performance Monitoring 78 5.11.9. Web-Application Performance Monitoring : 78 5.11.10. Helpdesk Management 80 5.11.11. Detailed Specifications for IT Asset Management 81 5.11.12. Enterprise Network Monitoring and Management Solution – Other Key Requirements 84

5.12. Enterprise Computing Security 85 5.12.1. Server security 85 5.12.2. Data security 85 5.12.3. Network Security 86 5.12.4. Edge security 86 5.12.5. Communication Security 86

5.13. ITMS Computing, Network & Storage infrastructure Specification 87 5.13.1. Design Principals 87 5.13.2. Non-Functional Requirements 88 5.13.3. Sizing Requirements 90 5.13.4. Enterprise Computing Architecture 90 5.13.5. Enterprise Computing Requirements 91 5.13.6. Hardware Requirements 91 5.13.7. Servers Requirements 92 5.13.8. Virtualization Requirements 95

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 4 of 178 5.13.9. Network Infrastructure Requirements 95 5.13.10. Internet Routers 96 5.13.11. Link Load Balancers 96 5.13.12. Firewalls 96 5.13.13. IPS/IDS 97 5.13.14. DMZ Switches 97 5.13.15. Servers Load Balancers 98 5.13.16. WAN Routers 98 5.13.17. L2/L3 Switches 99 5.13.18. Application Servers Load Balancers 99 5.13.19. Server Farm Switches 100 5.13.20. Wide Area Network (WAN) 101 5.13.21. Storage and Backup Requirements 101 5.13.22. ITMS Compute Infrastructure Architecture 105 5.13.23. Data Centre Safety and Security 107 5.13.24. Handheld Ticketing Terminal for City Bus Ticketing 110 5.13.25. Barcode based Ticket validator or Flap Barriers 111 5.13.26. UPS for BRTS Bus Station 112 5.13.27. UPS for Central Control Centre 113 5.13.28. Point of Sale system for BRTS stations 114 5.13.29. Station Server Specification 115 5.13.30. Specifications for LED based Video Wall Module 116 5.13.31. BRTS Bus Controller and Driver Console 119 5.13.32. Bus Passenger Information System Specifications 122 5.13.33. City Bus Station PIS Specifications 126 5.13.34. PIS Display Test Compliances 128 5.13.35. GPS based On-board unit for City Bus 131 5.13.36. BRT station LED TV based PIS Display System 134

5.14. Training Room and Test Systems 135 5.15. Human Resource Management 136 5.16. Commercial Operations and Maintenance - Bus stations, Bus Depots, Buses, Control Centre 136 5.17. Business Continuity Plan 136 5.18. Application and System Audit 137 5.19. Scope of Pilot Implementation 137 5.20. Change Management Procedure 138

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 5 of 178 5.21. Computerized Call Management System 138 5.22. Requirements 138 5.22.1. Project Management Personnel 139 5.22.2. Project Meetings 142 5.22.3. QUALITY ASSURANCE 151

5.23. ITMS SLA Requirements - Service Level Agreement 159 5.23.1. Management of Services/General principles 159 5.23.2. Scope of SLA 161 5.23.3. Severity Definition Chart 162 5.23.4. Fault rectification 164 5.23.5. Propose SLA Structure 167 5.23.6. Service Level Agreements for Handheld Ticketing Terminal 167 5.23.7. Service Level Agreements for AVLS Units 168 5.23.8. Service Level Agreements PIS 168 5.23.9. Service Level Agreements for ITMS Application 169 5.23.10. Service Level Agreements for Data Centre 170 5.23.11. Uptime Calculation for the month 172 5.23.12. Monitoring and Auditing 174 5.23.13. Service Levels for Fare Gates 176

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 6 of 178 1. List of abbreviations used in the document

SMC Surat Municipal Corporation ITMS Integrated Transit Management System SP Service Provider SC Smart Card AVLS Automated Vehicle Locator System AFCS Automated Fare Collection System HTT Handheld Ticketing Terminal BDC Bus Driver Console BCV Bus Card Validator STT Station Ticket Terminal SCV Station Card Validator DMS Depot Management System BTMS Bus Terminal Management System CCC Central Control Center MTBF Mean Time Before Failure MTTR Mean Time To Replace CCHS Central Clearing House System GSM Global System for Mobile communications GPRS General Packet Radio Service GPS Global Positioning System IMS Incident Management System DR Disaster Recovery VSDS Vehicle Scheduling and Dispatch System CAD Computer Aided Dispatch POS Point of Sale System GIS Geographical Information System

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 7 of 178 GPS Global Positioning System GPRS General Packet Radio System GSM Global System for Mobile Communications UMTS Universal Mobile Telecommunications System ETL Extract, Transform and Load BI Business Intelligence EMS Enterprise Management System NMS Network Management System SLA Service Level Agreement TAT Turn-Around-Time PMC Project Management Consultant TPA Third Party Auditor QA Quality Assurance QC Quality Control DC Data Centre PM Project Manager NDCS Hardware, Network & Data Centre Staff Member CRPA Control Room Process & Analyst STSM Senior Technical Staff Member

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 8 of 178 2. Introduction

The purpose of this document is to provide guidelines for development, implementation, operation and maintenance of integrated transit management system (ITMS) for Surat Municipal Corporation to be implemented within Surat City. The document underlines all functional, technology and end use requirements related to requirements of SMC to achieve integrated, highly automated and stable environment for integrated transportation operations management environment within city of Surat.

2.1. Objective of Implementing ITMS

SMC aims to enhance operational capability, citizen’s satisfaction, reliability and on-time availability of its services offered through various departments like public transportation, solid waste, engineering services and emergency services etc. SMC is soliciting proposals through this RFP from qualified services providers to implement an integrated operations management city platform which will render its services to different departments in a collaborative manner and augment SMC’s initiative of delivering quality services which meet citizen’s expectations. The services thereby are aimed at enhancing the efficiency of SMC’s operational capability and better management of fleet of vehicles which in-turn will instill confidence within citizens of Surat city. SMC, through this RFP is desirous of implementing the “Intelligent Transit Management System” (hereinafter referred to as the “ITMS” OR “The Project”). To this end, SMC has decided to monitor the movement and manage the fleet of vehicles owned and operated for SMC, collect data related to their geographical position, vehicle movement patterns and to provide relevant information to citizens / SMC’s management to better manage services. Onboarding of fare collection devices on its public transportation systems to enable electronic and integrated fare collection system delivery to its citizens.

2.2. ITMS Requirement Summary

SMC envisages implementing ITMS as a city wide integrated platform for its diverse set of transportation needs which include operations of public transportation, management of vehicles operating for other civic services like solid waste, engineering and emergency services. The aim of implementing ITMS is to bring in best-in-class operational efficiency and automation to its operations capability to ensure services are delivered on consistent basis and in a manner that meets objectives of SMC. ITMS is expected to meet the objectives of enhancing service standards, bring about paradigm shift in service quality and availability, better organization of planning and operations; integration of transit systems and overall improvements in line with service excellence.

ITMS shall enable SMC to automate its operational processes with respect to mobility management of its vehicles, better insight into operations and hence balance demand & supply

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 9 of 178 issues, perform analytics to optimize system capability to increase operational efficiency, bring in service sustainability, and enable forward looking environment which facilitates policy environment meeting corporation and citizen needs on continual basis.

ITMS system shall deliver above mentioned management objectives by integrating technologies and services using latest hardware, software, computing and communications technologies. The system shall offer relevant operational capability to individual departments while delivering services through an integrated and intelligent platform which is common to all the services. The system is expected to have capability to cater to diverse end use requirements from different service areas within SMC. ITMS will play an important role in delivering policy objectives of SMC, improving service accessibility, providing integrated transport solution and making best use of existing infrastructure and resources in delivering service resilience.

The system shall deliver noticeable economic benefits through reduced journey times and increased reliability, improvements in safety and reductions in pollution, easier service consumption systems, increased citizen trust in civic services, higher operations management capability to authority and integrated work management and delivery scenarios.

The aim of SMC is to implement AVLS and GIS and city platform which shall be utilized by diverse set of users to deliver individual or integrated services. The platform will be designed to add services on continual basis and same shall be achieved by establishing system using open protocols and integration capabilities driven by international standards. SMC does envisage that vehicles of all transport types and services like informal transit systems taxis’ autos etc. shall be on-boarded on the same platform in phases, so as to offer technologically advanced, integrated, safe and common transit services to citizens with the city.

ITMS Implementation Benefits:

 Making travel within city seamless and more efficient (safer, less polluting, economical, better informed travel) – increased PT usage;  Improving access to public transit system by augmenting easier access to service and information  Improved and scientific decision making;  Deliver accurate real time information about services;  Aid policy decision by availability of analytics platform.  Faster and efficient management of incidents within the city;  Higher economics within transport service by increased use of electronic fare services.  Enhanced and easier service platform for emergency and engineering services.  Optimized fleet management for higher availability.  Safe fleet availability by implementing controls of operations and SLA’s.  Improved communication between operations staff and management resulting in coordinated and managed service environment

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 10 of 178 In-order to deliver above stated objectives and benefits through technology intervention, ITMS shall comprise of following distinct application areas: . Integrated Automated Vehicle Location Monitoring System . Passenger Information System and ETA Prediction System . Vehicle Scheduling & Dispatch System . Depot Management System . Business Intelligence System . Enterprise Management System . Enterprise Security Management System . Call Centre Management System . City Transportation Control Centre

2.3. Purpose of Open ITS standards & Architecture

Interoperability: The ITMS Architecture shall be based on standards needed to provide a sound foundation for system interoperability (interfaces and products). Because the ITMS shall serve as the common foundation for ongoing ITS development work for Surat city, factoring it into current system implementation will facilitate transition to a standard interface definition. Using standard interfaces will provide for regional interoperability and even interchangeability of some devices used in ITS management, even though they may be from different manufacturers.

Increased competition: By implementing use of open standards (non-proprietary), multiple vendors will be able meet the standards and be able to respond to RFPs. Support and upgrades will also be available from multiple potential sources, avoiding the problems of being locked in to one source.

Future expandability: By designing within a common framework and using open standards, you will create an environment that integrates legacy systems with new ITS applications and allows more functionality to be added as needed.

Lower costs: ITS equipment and device compatibility will create larger total markets attracting more suppliers resulting in more capable products at lower prices. The resulting long-term costs of deployment will be pushed down by these economies of scale for off-the-shelf ITS equipment and products and by competition through open-system enabling of multiple vendors.

Increased transportation system integration: The open nature and structure of the ITS architecture and use of standards-compliant components will make integration of complex transportation management components and regional systems easier. Improved integration of systems operated by different agencies will permit effective information sharing and more

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 11 of 178 effective use of resources. Seamless mobility services across agency lines will become a reality.

Note: The solution provider shall be required to provide all protocols, API’s interfaces etc. to SMC and solutions should be delivered using standard globally accepted protocols and practices.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 12 of 178 3. Solution Overview

3.1. Integrated ITMS Overview

The integrated view of ITMS shall enable you to have a detailed understanding of SMC’s understanding of implementing city wide transit management system. The system being proposed to be implemented will act as a city foundation framework for integrating objectives of diverse set of stakeholders with Surat city. SMC provides several other services other than transportation to its citizens like solid waste, emergency services, engineering services etc. and hence all such services mentioned within the scope of this RFP shall utilize common ITS infrastructure like tracking and GIS systems to deliver its desirable end objectives.

Figure 1: Integrated Surat City ITMS Architecture**

**The figure 1 above is indicative and does not include all the activities that would need to be carried out as part of implementation of ITM. Detailed scope is mentioned in the document below.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 13 of 178

3.2. BRTS Bus Station ITS Overview

The BRTS bus station is essential a closed system of operations which allows off-board ticketing in electronic form such as smart card, electronic tokens and barcode. The station shall offer functionality of integrating all station equipment’s over a common local network and station manager (station server) so that the operations can be managed in an integrated manner and common resources like network, station server application and communication system are used by the different equipment’s installed in the station. The station is powered by conventional power however uninterrupted power supply shall be provisioned to ensure operations continuity in event of power outages.

Figure 2: BRTS Bus station ITS Equipment’s, Interfaces and Communication

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 14 of 178 3.3. City Bus Station ITS Overview

The city bus shelters are open kerb side shelters and are utilized by city bus service for passenger boarding / alighting services. The station shall provide a LED based PIS display to deliver estimated arrival time of city buses at individual stations. The devices shall be connected to central control centre via wireless interface like GSM / GPRS / 3G for data exchange purposes. The device shall operate in autonomous mode and can be managed centrally by central control centre. The device shall also be connected to uninterrupted power supply for information continuity.

Figure 3: City Bus station ITS Equipment’s, Interfaces and Communication

3.4. BUS ITS Infrastructure Overview

The bus ITS system is an integrated system installed on the bus to deliver primarily services pertaining to location tracking, operating parameters like speed, direction etc. The system will also provide passenger information system using visual and voice aids to enable passengers with diverse needs to know about the route and station information. The system shall be connected to central control center via wireless communication system provided using GSM /GPRS / 3G system. The essential components are:

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 15 of 178 BRTS Bus  Controller for GPS/GSM  Bus Driver Console  LED based PIS displays  Speaker System  Panic Alarm City Bus  Controller for GPS/GSM  Bus Driver Console  LED based PIS displays  Speaker System  Panic Alarm

The system shall provide two way communication with the drivers, so as to ensure services are delivered and adhered to, based on the expected operations levels.

Figure 4: Bus ITS Equipment’s, Interfaces and Communication

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 16 of 178 3.5. ITMS Communication System Overview

The communication system for ITMS project needs to be able to connect multiple types of assets, mobile and fixed. The communication system thus required for the purpose of connecting field devices to the central computing infrastructure shall depend on the type of asset. For mobile assets ITMS shall utilize wireless connectivity like GSM/GPRS/3G to establish connectivity with CCC and fixed assets like bus station, depots etc. shall be connected over fixed lines as these assets will need to manage a large volume of data. The data communication needs to be secured so that the sanctity and sanity of data is maintained at all times.

Figure 5: Communication Interfaces for ITMS ecosystem for SMC

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 17 of 178 4. Functional Specifications for ITMS

This section describes functional specification and end use requirements for different components within scope of this RFP. The functional specifications shall be the base requirement understanding given to bidders, however SMC expects the service provider to on- board best practices and enable a highly integrated and automated operations environment. The functional specifications section provides specification for major components for ITMS:  Automated Vehicle Location System  Passenger Information System  Vehicle Scheduling & Dispatch System  Depot Management System  Fare Collection Devices  Incident Management  Business Intelligence  Enterprise Management System

4.1. Integrated Operations Management Platform

SMC through ITMS project implementation intends to develop a city wide operations management platform which will be utilized by diverse set of users like transport, Solid waste, emergency service and engineering services to enhance service capabilities in terms of asset location identification and utilization. The system is expected to act as a city platform and allows individual services to leverage the common tracking and operations management platform. The common system shall deliver workflow and rules management capability so that individual departments can manage their operations compliant to their functional requirements. The service provider shall be required to implement central tracking infrastructure in a way that shall have provisioning capability to on-board functionality based on the user requirements in a template format. The integration shall be facilitated by publishing open interface protocols so that diverse set of hardware technologies can be integrated into the system. The system shall provide capability to individual users based on workflow, rules and authorization to carry out business functions designated for the user types. The central operation management platform shall create unique operational capability for individual stakeholders like fire, ambulance etc. to meet their operational requirement and hence augment their operational capability to better respond to the service requests. The service provider shall be required to procure GIS map of Surat city and conduct surveys to map required information for the purpose of ITMS project.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 18 of 178 4.2. Automated Vehicle Location System

The Automated Vehicle Locator System (AVLS) shall primarily use GPS based location tracking devices mounted on the vehicle as primary source of data for tracking purposes. The location and associated data acquired from the vehicle units shall act as input source for tracking and operations process management required by user executing their specific functions. The AVLS system shall enable SMC operations team to monitor vehicle movement in real-time and synthesize the AVL field data to deliver the same on the public information system devices installed on Bus stations, Terminals, Buses, SMC customer portal, mobile information delivery system in case of public transit application. The AVL data from vehicles other than the transit vehicles shall be delivered to individual process owners within SMC for further use and processing based on the requirements identified for individual departments. The AVLS shall be source for enabling public information system service which acts as a source of information to be made available across various types of end point devices like mobile, fixed displays, web etc. in form of text & voice. The AVLS for BRT and city bus shall essentially comprise of following components: . Bus Mounted GPS based driver console . On-board Passenger Information System . Off-board Passenger Information System . GIS Based Fleet Monitoring and Control System

The AVLS for solid waste & engineering vehicles shall comprise of: . Vehicle Mounted GPS console . GIS Based Fleet Monitoring and Control System

The AVLS for emergency vehicles like ambulance, security and fire shall comprise of: . Vehicle Mounted GPS based driver console . GIS Based Fleet Monitoring and Control System The central AVLS system should offer functionality to manage diversity of end use requirement as may be required by individual departments for operational use purposes. This should be facilitated by use of common GIS platform and allowing customization of views with respect to asset identification, tracking and process management. The AVLS system will essentially offer workflows, rules and SOP’s being mapped based on the process type and user authorization to carry out functional processes as may be required for specific operations. It may be noted that each department may have specific routing and tracking requirements which may be very specific in case of solid waste vehicles, emergency

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 19 of 178 vehicles and emergency vehicles. The system should offer dispatch and scheduling capability to manage vehicles with reference to end use requirement. The service provider shall be required to provide facility to ensure that end use requirement of different departments and vehicles is met and functional and technical processes are provided to meet the operational requirements. Emergency service vehicles will need to be provided with dispatch and schedule services along with navigational maps to ensure such vehicles reach point of interest in stipulated period of time, similarly other vehicles should be tracked and relevant SOP’s to be built for operations management purposes to ensure end use requirement is met. The system will also be compliant to GTFS / inter-operable data formats to enable external technology ecosystem provider to build complimentary applications to further boost consumer oriented delivery and service environment.

4.3. Passenger Information System

The passenger information system is a very important exponent of intelligent and integrated ITS system and renders a very important consumer facing service. Accurate and timely PIS delivery enables consumer trust on public transport service and also aids modal shift in long term, as the reliability and availability becomes evident to the users. The passenger information system is an integrated service which utilizes tracking data from vehicles which is centrally processed for the purpose of arrival and departure time estimation. Central PIS system shall deliver ETA/ETD information on schedule or request basis depending on the type of end point application or device. The central PIS delivers ETA / ETD to fixed display devices installed on bus stations at a set frequency or on bus movement basis. The PIS information on buses is driven by local geo location aided controller which has capability to deliver information in visual and audio formats, this controller can also be interrupted by CCC to display or play specific messages dynamically. The PIS to commuters will also be delivered via other electronic means like website, mobile app, SMS or IVRS. This multi-channel commuter interface enables quick access to transport system and ensure citizens see the city transit system as safe and reliable alternative for travel purposes. The system shall consist of following units to offer users access to real-time information regarding operations of bus transit service and extend ease of information access related to travel needs: . Display Screen on Bus Stations . Display Screen on Bus . Voice announcement system on Bus . SMC Transit web portal for Bus Schedule &ETA, SMS, Mobile App and IVRS. The PIS display systems at bus stations shall display real-time information of the route and estimated time of arrival using communication system installed within the station (Wired /

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 20 of 178 Wireless) with the central AVLS / PIS Application. The system will have capabilities to clearly indicate the direction and route no of the bus on the display to assist passengers. The bus display units on the front wind shield and the back window shall display bus route information and the internal display shall display real-time information of the stations bus in terms of route information, next stop etc. via text and voice interface. The voice information system shall also derive information of the next station based on the location information derived from the GPS unit and shall have capabilities of playing pre-recorded voice information in the bus. This system shall also be used to deliver consumer centric outreach information as may be required by the transit agency from time-to-time. The SMC web portal shall enable passengers to get information about the bus schedules on various routes operated by SMC and shall also have facility to deliver ETA based on the real- time data from central PIS system. PIS shall also be made available to users via mobile apps, SMS and IVRS. A call centre shall be maintained by the service provider on behalf of SMC for passengers to call into for information on bus routes and schedules as well as for any issues related to transit service. Call centre shall be able to log in complaints through call centre executive or IVR.

4.4. Vehicle Scheduling and Dispatch System

Scheduling/dispatch software shall be used to aid designing and modifying transit routes. It shall also be used to route, schedule, and dispatch vehicles in demand response operations. The application shall combine GIS and AVL to coordinate different transit functions. Combined technologies such as, computer-aided dispatching and AVL shall increase the efficiency of transit operations, enhance safety, improve service. For example, systems integrating automated scheduling and dispatching and AVL enable a dispatcher to know the exact location and status of each bus under control. This real-time information allows the dispatcher to address any problems with service or to respond to any emergency. In addition, automated dispatching software and AVL allows the coordination of services among many separate transportation agencies. Vehicle scheduling and dispatching system should be capable of dynamic planning and Capable of optimizing 1000s of vehicle movements, the system should be capable of automatic dispatch distribution and transport operations, dynamically rescheduling vehicle and driver assignments based on real-time events. Vehicle scheduling and dispatch system shall be capable of providing schedule adherence reporting, route condition monitoring, emergency / incident interfaces and dynamic scheduling apart for standard functions that would be required to deliver computer aided scheduling and dispatch services from designated operations locations within SMC operations framework. This system is expected to lend its functionality not only to transit vehicles but also to other municipal vehicles functioning under solid waste, engineering and emergency services.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 21 of 178 4.5. Depot Management System

Integrated Depot Management System This module enables to automate depot Operations, which include workshop management, fuel management, traffic management, vehicle management, and so on. The module shall also cover administrative activities and stores requirement. Stores & Inventory System This module shall enable automation of stores and inventory for various items at each depot, workshop, and division and so on. The module also covers purchase and procurement processes right from sampling to evaluation of products to tendering to purchases to consumption. It also enables to exchange the information across the depots, divisions and workshops for products availability and requisitions. Personal Information System This module covers the various processes related to Payroll and HR activities of Personnel working at Central Units, Divisions, Depots and Workshops. It offers centralized system for better control as well as employee satisfaction. Functional units of IT system and interrelation The IT system for SMC operations shall be designed to meet specific needs of following operational entities to achieve the above system needs: . Central Control Centre i) Central Computing Infrastructure ii) Central Vehicle Monitoring System . Bus Terminals . Bus Stations . Bus . Bus Depots 4.6. Functional Solution Landscape

The ITMS functional solution architecture is envisaged to be based on integrated approach wherein all the solution sub-components like AVLS, PIS, Scheduling, Dispatch etc. are loosely coupled to offer a modular design philosophy. The requirement for loosely coupled environment while the system works in an integrated manner is to ensure future innovation and scalability. The sub systems implemented as part of ITMS integrated project will integrate with each other through a well-defined and documented data and process exchange protocols which will be part of the overall deliverable to ensure SMC has ability to onboard new initiatives with ease. Since ITMS is being envisaged as a city wide open platform, the solution provider will have to ensure that the overall architecture maintains ability to interface or add / remove sub system components without going through a major change management process.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 22 of 178 ITMS being a field where major innovations are expected in coming times from the standpoint of hardware, software, interfaces and algorithms, it is thus imperative that SMC’s ITMS design and implementation is of the nature which could embrace such eco-systems changes with ease and in a well-defined manner. Sustainability and longevity of such solutions being of prime importance, the service provider shall be required to deliver designs and architecture which aligns with the expectation of SMC and also industry open standards.

SMC expects service provider to deploy maximum possible COTS products in terms of software, hardware and communication, so that technology being provided can be sourced easily, brings in economics and also migration is less cumbersome and aligns with industry’s technology upgradation curve.

The technology components proposed for the purpose of implementing ITMS should be generally available in country and through multiple product providers, this would create a competitive environment also allow onboarding of technology at significantly lower prices and generally ensure availability of such products at all times.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 23 of 178 5. Technical Specifications for ITMS

The technical specifications section provides detailed specifications for software, hardware, communication and interfaces required to achieve the objectives of the ITMS project.

5.1. GPS Based Automated Vehicle Location System

5.1.1. Bus Vehicle tracking device

GPS and GPRS based Vehicle tracking unit The Bus Driver Console shall be installed on the SMC BRTS buses. The service provider is required to interface with the on-board computer to take necessary data required for control & operations purposes. The Driver Console Unit with wireless communication module (based on GPRS/3G/Wifi) shall be used to provide vehicle tracking accurately and reliably. The back end system shall be able to produce MIS reports of the vehicle schedule adherence report and operated kilometres by each bus, by route and by fleet of each Service provider. SMC may require additional information to be extracted from the vehicle tracking information logged at the control centre. The unit would additionally have an interface module in front of the bus driver for two way communication, messages to be sent by driver and messages to be sent to the driver from the control centre. The Bus Driver Console unit has to be mounted on board the bus and the assembly has to be designed in a way that integrates with the dashboard of the bus. The bidder has to provide a design which should be theft proof and cannot be in normal circumstances removed from the bus unless standard technique specified by the bidder is applied. The bus driver console will act as the sole management console for devices onboard like PIS and AFCS equipment’s. The BDC shall operate PIS manually in-case of GPS outage.

Features of BDC UNIT: For detailed specification refer technical specifications section in this document. The Unit should primarily be able to help central monitoring system to generate minimum of following data points as minimum and at the time of finalization of requirements a comprehensive requirement shall be furnished to the service provider: . Start Stop . Begin – End Shift . Fleet Summary . Detailed Activity

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 24 of 178 . Speed . Fleet Status . Alerts . Battery Report . Unit ON/OFF Report . Ignition ON/OFF SMC can request for other reports / data / information as deemed necessary for management purposes. The unit will also be able to deliver real-time information to drivers with respect to route information, messages from control centre and any other intervention that may be required to ensure operational sanctity. The units supplied should have facility to for drivers to login/log-off facility and data should be linked with the AVLS server for authentication and tracking purposes.

5.1.2. AVLS Software:

The software shall be web based and utilizes high resolution digital map to show real-time position of the vehicles. The software shall provide map based tracking and transit route line based tracking of vehicles by the control centre operators. The software is expected to have enterprise capabilities which enables multiple user type to be enabled to carry out various functions like, Alarm Management, Vehicle Schedule Tracking, Speed Management, Stoppage management, Route replays, bus tracking dashboard etc. as a standard functionality. The software shall enable control centre management staff quick decision making capability, which shall be achieved by providing graphical tools for visualization. The software shall enable SMC to drill and analyze information and online data in a multi-dimensional manner. Comprehensive analysis and reporting capabilities are expected to be part of the application delivery which matches the world standard capabilities of AVLS systems. The software should have capability to have a multi-screen based tracking system, so as to enable tracking staff to quickly analyze activities and have a better insight into operational data of all activities within the system. The operations Management system installed and managed through integrated AVLS platform shall have functionalities (not limited to) (This is a partial list, SP will provide a full capable AVLS system based on best practices):

5.1.3. AVLS Controller Software Functionalities

 Ability to distribute control of services among controllers  Real Time Communication with the Fleet  Supervision and Monitoring Of Fleet Positions in Real-Time  Ability to Track Bus Service based on different operational state parameters  Time Monitoring Analysis

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 25 of 178  On-Line Assignment of Service Time  Management of Information Displays at Stops  Regulating Service by Time and Frequency  Ability to See Trips by different colours  Colour Legend of Vehicles  Status Tracking of Messages Sent To BDC  Status Tracking of Messages Sent To Internal Screens  Controller System Messages  Controller’s Authentication  Vehicles, Virtual Vehicles, Stops and Lines on Map  Vehicles, Virtual Vehicles, Stops and Lines on Straight-Line Diagram  Information on Vehicle on mouse overs  Information on PIS and Stops on Mouse Over  Vehicle Menu  Information on Drivers  Detailed Control information of Vehicle  Selection of Stop on Route  Ability to Define Types of Stops  Detailed Stop Control  Detailed Stop Control  Current Trip Views on Map, Lines etc.  Multi-Map Views  Ability for Zone Creation  Ability to Draw Detours on Map in Send it to Vehicles in Real-Time  Management of Detours  General Control of Lines  Control of Routes  Technical Alarms Management and Disposal  Bus Alerts management and Disposal  Messages to Console, Manually, Auto Mode, Event Activated  Automatic Messages with Acknowledgment  Messages to PIS Screens  Answering Messages from the Vehicle  Panic Button Messages Management  Information Panel Messages  Line Legend  Lines with Activated Legend  Bus Service Graph  Trip Graph  Information Signs – Checking On the Lines  Information Signs – Checking On Predefined Messages  Information Signs – Checking On On-Line Messages

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 26 of 178  Information Displays – Lines  Information Displays – Predefined Messages  Information Signs – On-Line Messages  Information Signs – Simulator  Statistics of Lines, Drivers, Routes etc.  Traffic Density using Colour Codes on Lines, Maps

5.1.4. Driver Console Configuration & Management

 Configuration of driver’s interface (console) messages  Configuration of predefined messages  Configuration of zone messages  Filtering lines for warning the controller  Calendar configuration  Configuration of voice types and frequency  Map data configuration  Incident types  Controller Authentication  Configuration of Vehicle Control Panel Messages  Configuration of Predefined Messages  Creation of Predefined Messages  Zone Indication Message to Buses  I/O Zone Warning Messages  Line Filter for which Warnings are sent to the Controller  Day Type Configuration, New Day  Day Type Configuration, Alter  Day Type Configuration, Search  Day Type Configuration, Seasons  Day Type Configuration, Results  Voice Time Configuration  Configuration of Reaction Times  Map Data

5.1.5. PIS Display Configuration and Management

 Configuration Tools  Creation of Information Displays  Line Configuration.  Predefined Messages  Associating Predefined Messages with Displays

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 27 of 178

5.1.6. Maintenance Requirements

. Device settings shall be updated including software/firmware updates through transmission via the secured communication network set up by the service provider. For reasons of security, device settings shall not be modifiable by field staff of the service provider/others. . Any device settings modifications including software/firmware updates as well as business rules such as fare settings, discounts etc. shall be done with prior authorization by SMC. A digital log of all changes of settings on each and every device shall be maintained and delivered to SMC. . Any faulty equipment shall be replaced with a tested unit from the spares maintained by service provider. . Repair and testing of equipment shall be done at the Service provider’s maintenance centre and not at site. . Only a maintenance engineer with maintenance access card shall be able to access maintenance mode of the device which shall allow the maintenance engineer to diagnose the faults and update the device settings directly, if required. . A repaired unit shall be tested for full functionality as at the time of initial deployment and certified before it is reinstalled at any site.

5.2. Passenger Information System

Passenger Information System hardware shall consist of LED based display system for bus stations, Terminals and Buses. Following are the technical specifications for the display units. The passenger information system shall comprise of following components: . Display Screen on Bus Stations . Display Screen on Bus . Voice announcement system on Bus . Web Portal for Bus route Schedule &ETA . Mobile Schedule Access System

5.2.1. PIS at Bus Stations and terminals

LED based display screens that provide sufficient visibility in broad daylight condition shall be installed at SMC bus stations and terminals. There shall be two displays per station. They shall display route and estimated arrival time (ETA) including digital advertisements and other digital content as may be approved by SMC. They may also be used to display public service information.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 28 of 178 The display shall receive encoded information of route and ETA from the AVTS control centre through the common wired/wireless communication link set up at each bus station as part of the AFCS system. The displays must have the ability to decode the information received from CCS and display appropriate message on the screen.

LED Board at Bus Stations shall have the following functional specifications:

 Display of PIS in a display unit at bus station shall be configurable based on bus station and platform. Single unit should display services of more than one platform.

 Information Display units will be supplied and mounted appropriately, configured and commissioned by the vendor.

 PIS information shall be displayed in Gujarati, Hindi and English alternatively (single or multiple language shall be configurable).

 At all these bus stations, display units will receive/display transmitted contents from the central system through a gateway or mention other suitable means in the technical architecture.

 Display systems needs to support full colour display for streaming advertisements, Digital display of text, images and video on LED screens.

 Displayed messages must be readable in high bright, day light.

 Display system in addition to the display of information for PIS shall be capable of displaying advertisements and multimedia content at the bus stops and may need to alternate between Passenger information and Advertisements.

 The frequency and period of information display on PIS display shall be configurable from central location for advertisements and other transit information.

 Display shall provide for modular configurable layout enabling parallel display of content on different areas of the screen – Real time Transit information (Routes, ETA, Type of service, Fare, Time/Date, Public announcements, Safety information, Commercial advertising, a ticker tape at the bottom for text announcements/advertisements, other local Tourist information).

 All displays for PIS will have a configurable refresh rate with minimum of 10 seconds.

5.2.2. Display System Technical Requirement (PIS):

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 29 of 178  Display units shall be mounted on a rugged enclosure to withstand harsh environmental conditions with reasonable physical security.

 Display will be located at a convenient height to have a clear view of the message of next arrival bus.

 Fitment provision will have to be provided in the Bus stations. The power supply shall be made available by SMC.

Display Hardware Specification

 One Integrated tamper proof casing for complete PIS Unit addressing physical security considerations.

 Provide any hardware like PC, networking, etc. required to run the PIS and advertisements on LED Display Units.

 Ensure smooth transition from main power supply to UPS in case of power outage.

 Aesthetic requirements such as fonts, colours, rows per page, display time to be remotely configurable and displayed based on business requirement.

5.2.3. PIS on bus

Passenger information system on bus shall function as an independent system and shall not be directly dependent on the CCS. They shall receive display information and voice announcement commands from the onboard GPS vehicle control module based on stored memory on the bus. Specifications of PIS units to be installed on bus: Refer Annexure 1: Urban Bus Specification II at the end of this document.

Voice Announcement system on Bus The Voice PIS must play clearly audible pre-recorded voice announcements informing passengers of next bus station on route. The voice PIS shall interface with the on-bus GPS module to gather location information and making the appropriate next station announcement. Voice Announcement system on Bus The Voice PIS must play clearly audible pre-recorded voice announcements informing passengers of next bus station on route. The voice PIS shall interface with the on-bus GPS module to gather location information and making the appropriate next station announcement.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 30 of 178 5.2.4. Web Portal for Bus Schedule &ETA

SMC’s web portal shall extend capabilities to passengers to download route information, route schedule and real-time ETA from the web portal. This information must be accessible using WAP enabled mobile phones also. The portal shall have facilities for pass application, card top- up using credit/debit cards. Etc. The service provider shall also be required to develop mobile App for iOS, Android, Windows mobile devices to enable commuter to use the same for the purpose of travel information relating to service which may include, route planning, ETA, Offers, Fare and route tables etc. The portal will act as a single source of information with regards to transportation system in Surat city and hence shall have all possible interfaces like logging complaints, viewing transport information, real-time updates, organizational structure, citizen blogs etc.

5.3. Depot Management System

Depot management plays a very important role in ensuring availability and safety of the transit system buses. Depot resources are required to carry out day-to-day maintenance of vehicles, preventive& predictive maintenance schedules. The depot management process shall be primarily responsible to following functions are carried out:

 Crew Rostering using DMS  Vehicle Scheduling using scheduling system  Vehicle Dispatch using CAD system  Vehicle maintenance and operational requirements like fuel etc. using DMS  Maintenance expenses

Depot management system shall primarily manage crew required for bus operations, vehicles, routes, schedule management etc. The operations & maintenance processes with respect to buses shall be captured by the system. The Bidder shall provide customization to the software based on the functional and technical requirements of the project.

Crew Rostering module shall be able to create group of users based on set of defined Parameter’s by SMC. The proposed rostering module shall plan, optimize and generate the rostering automatically for month to one year. It shall allow admin or authorized user to create and view the planning for a defined period of time. The proposed rostering application shall display or provide rostering using graphical representation for the selected period and shall interface with scheduling module to assign crews automatically to the schedule. The Rostering module shall interface with HR system to update crew absence, holidays, etc. In event schedule deviations, rostering shall update crew’s operation hours, ideal hours, etc., for day to improve the operation. Rostering system shall have optimization technique to minimize and identify the underperforming crew. The proposed rostering shall provide individual or group wise

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 31 of 178 performance in graphical user interface. That including working, non-working hours, holiday, leave, over time, etc.

DMS process shall provide productivity reports to ensure insights into operations such as:

 Crew allocation  Schedule allocation  Crew utilization report  Fleet departure at depot  Fleet dead KM per route/ fleet wise  Revenue kilometre  Schedule or trip cancellation  Crew license renewal history  Over time details per staff wise  Fuel stock per month/ week/ per day  Fuel consumption every day  Fleet wise fuel consumption  Vehicle service alerts

DMS shall also provide functionality for workshop management and following modules shall be offered:

 Body repairs  Fitness Certificate Renewal  Reconditioning of assemblies and engines  Retrieving of spares  Tyre re-treading  Repairs and reconditioning

The application shall provide query by fleet to view and update the fleet status. The application shall have features to capture daily progress of particular vehicle department-wise to track progress by type of workshop activity (accident, engine rebuild, fitness certificate, etc.). All the documents related to vehicles like vehicle registration, FC, Road permit, Staff ID proof, License, purchase orders etc. shall be scanned and uploaded into corresponding sub systems like DMS, WMS, Stores, and HR & Payroll.

Application shall have features to capture and report vehicle-wise insurance claims, road permit, etc. DMS module shall interface with workshop module to update maintenance detail.

The following MIS reports form the tentative list. Additional reports may be added during design discussions and pilot implementation.

 Breakdown

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 32 of 178  Accident  Vehicle In/Out  Pending Maintenance  KMPL for each Fleet  Vehicle FC, Road permit history  Complete history of each vehicle maintenance by month and year

5.3.1. Stores and Inventory

The proposed Stores and Inventory application shall have features to generate purchase orders, maintenance contractor details, previous quotes, etc. Asset management system to maintain all the physical items belongs to this project. Application shall have receipt of incoming goods/ GRN. The application shall support barcode reader to read the item information, warranty, etc. and register into application. Barcode reader to read the goods while procuring and it shall register into the system for inventory.

Barcode reader to check the goods warranty, batch, year of manufacture, etc. by reading the barcode label on the goods. The application shall have provision to track goods transferred to other depots. Each item shall set with threshold level for stock. When the stock is going below threshold then system shall send alerts to concerned person(s) or department. The system shall have warranty information for each item. There shall be a provision to note the physical stock location number on the application to identify the stock easily. All the items entered into system with date of manufacture, date of warranty expiry, batch, date of purchase, etc. Query screen to check warranty information of particular item shall be available. Asset will have unit make, model, part number and location of asset for both movable and immovable. Stock management shall be able to capture new and used items. The following MIS reports form the tentative list. Additional reports might be added during design/pilot stage.

 Monthly Stock detail  Item wise Stock  Item name & code with Warranty  Stores accounting value  Utilized stock  Inventory control  Maintenance of stock record  Stock transfer  Asset Detail  Asset Summary – depot wise, division wise

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 33 of 178 5.3.2. Depot Personnel HR and Payroll

The proposed application shall store employee related master details without any limitation. The employees from HDBRTS, NWKRTC, Contractors, etc.as identified during the design stage. Attendance shall be recorded using Proximity Readers installed at various places depots. The system shall not allow any records to be deleted. But it shall allow admin to edit employee personal info, others as required. HR & Payroll System is expected to be accessible from all the depots, terminals, Inter-changes and main office. Additional locations shall be identified during design stage.

HR & Payroll System access shall be configurable based on location/user type/user group. The Super User or Admin shall have access to all the data. The Master table will have minimum of Date of birth, Date of Joining, Earlier Service Experience, Department, Designation, Seniority, Salary, etc. HR system shall interface with Depot Management System to provide crew absence. The system shall maintain staff’s ESI, PF and other mandatory processes. Application shall have provision to request transfer to other depots or other places. Staff shall be able to generate their salary slip using their ID & password. Staff shall be able to check available vacation and sick leave using the system.

The following MIS reports form the tentative list. Additional reports might be added during design/pilot stage.

5.3.3. Human Resource Management

 Employee Management  Leave Management  Service Management  Training Management reporting  Etc. 5.3.4. Payroll Application Requirements:

Standard payroll application with following features:

 Monthly Salary management with statutory management functions like standard deduction, Payroll summary, Income tax, Form 16A and other reports as per Govt. of India  PF, ESI, Professional Tax, Labour laws etc.  Over time details and salary  Bonus statement & Insurance  Disbursals Management

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 34 of 178 5.3.5. Specifications for DMS work Stations:

Latest Windows based system with MS Office &Antivirus, etc. Minimum Core i3/i5, 4th Generation processor at minimum 2.8GHz with a minimum of 2MB secondary level cache. RAM shall be 4 GB or better. Hard drive (SATA) shall have a capacity of 500 GB or better. Media storage device capable of CD/ DVD RW with the latest industry standards. Integrated 10/100/1000 MB Ethernet NIC. At least 4 USB 2.0 spare ports. TFT LCD monitor that shall be 21” or larger and have SVGA quality or better & keyboard & mouse. Dual screen interface

5.4. Incident Management System

Incident management is the process of managing multi-agency, multi-jurisdictional responses to disruptions. Efficient and coordinated management of incidents reduces their adverse impacts on public safety, traffic conditions, and the local economy. Incident management yields significant benefits through reduced vehicle delays and enhanced safety to motorists through the reduction of incident frequency and improved response and clearance times.

Incident management is a planned effort to use all resources available to reduce the impact of incidents and improve the safety of all involved.

5.4.1. Emergency/incident management

Emergency/incident Management shall be handled through the CAD/AVLS. In general, the strategies for emergency/incident management will be developed at a broader organizational level, and shall involve many stakeholders including the CAD/AVM system. Emergency/incidents can be clustered in three levels, which have differing levels of response:  Individual vehicle or location  Impacting only the public transport services  Impacting the urban area and utilities, of which public transport is one Emergency/incidents cover the following scenarios:  Breakdown of vehicle or collision, requiring technical assistance or replacement  Collision, illness or other non-criminal incident requiring medical support  Assault, aggressive or security incident, requiring police/security response  Pre-advised diversion or restriction due to road construction/repairs or other cause  Unplanned diversion or restriction  Weather-related events and restrictions

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 35 of 178  Events, requiring diversions and/or additional services For the most part, when such incidents occur, the Operations Management is achieved through the CAD/AVLS system, and the Route Condition Monitoring and Schedule Adherence applications. SOP’s shall govern the management of various incident types, and activated as required. Specific ITS supports for emergency/incident management include:  Alarm/alert initiated by the driver. This can override the normal communication protocols and get priority alert to the dispatcher.  For known disruptions (e.g. planned road work, events) temporary route diversions, temporary schedules and adjusted sectional running times can be pre-programmed into the CAD/AVLS system and activated for the period of the works  For occasional disruptions (e.g. key street unavailable), alternative plans can be stored within the CAD /AVLS system, and activated whenever a trigger event occurs (e.g. weather alert, demonstration).  Data exchange among the transportation and security agencies  Traffic signal adjustment in the vicinity of the disruption areas

The incident management process shall include:

 Detection  Verification  Motorist Information  Response  Site Management  Traffic Management  Clearance

This system would ideally execute following phases:

 Notification phase  Response phase  Recovery phase  Restoration phase

Incident management system is envisaged to be implemented as part of ITMS which shall facilitate communication of activities internally and externally as well. 5.5. Call Centre Management

Service provider shall be required to implement a call management system which shall utilize AVLS / CAD system to management communication of information request internally and externally. Call centre system shall act as communication centre for external callers like

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 36 of 178 commuters or citizens for service information purposes. The system shall include standard function like call logging, call forwarding, call disposal etc. via use of predefined templates and SOP’s for individual call or process types. The system shall be supplemented by integration with digital exchange connected having single number facility for callers and multiple outgoing lines for dialling out facility. This system shall include call management system including PC’s, Call handling equipment and EPABX.

5.6. Computer aided Scheduling and Dispatch

5.6.1. Computer Aided Dispatch

CAD systems shall assist the processes of dispatching revenue & non-revenue service vehicles. The system will manage dispatch of buses from their terminal / depot points in case of public transport and dispatch of other vehicles to destination areas based on requests. The objectives of a CAD system shall be:  To dispatch vehicles according to the operational plan.  To dispatch the vehicle at the scheduled time; or  To dispatch vehicles according to a headway plan (e.g. vehicles at 5 minute intervals in the peak, 8 minutes in the inter-peak, 15 minutes in the evenings)  In case of late arrival of incoming vehicles and/or other disruptions, to arrange the departures as close as possible to the service plan, and maintain proper intervals  In case of more serious disruptions, to manage the departures to provide the best service possible with the resources available  In case of one or more vehicles being unavailable, to smooth the intervals  To liaise with support services for replacement vehicles and/or drivers  To record all departures for administration, analysis, planning and intervention measures Dispatch in case of SMC will be based on both centralization and hierarchy basis depending on the type of vehicle and department. E.g. public transit could be based on centralized policy of dispatch and other municipal vehicles could be on intervention basis. CAD system shall provide the following core functions to assist the dispatcher in the operations management and dispatch functions:  Display the routes and/or terminal points in graphical format  Present the current locations of the vehicles operating on the relevant routes, usually with indication of the their status (early/late)  Provide supporting information on schedules, dispatching sequence, vehicle availability  Provide status information and alerts about actual and missing departures  Support voice and data communication with drivers, vehicles and support staff to facilitate on-time departure  Capture data on all departures

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 37 of 178 The CAD application shall be integrated with other operations management functions like AVL to ensure end use requirement is met.

5.6.2. Schedule Adherence Support

Schedule adherence process shall provide information and tools to assist dispatchers to keep the service operating to schedule. The approach can be somewhat different depending on whether the service is operated to schedule/timetable, or to planned headways. Schedule adherence applications are invariably implemented within CAD / AVLS systems. Schedule adherence applications can be split among:  the CAD/AVM Control Centre, where the Dispatcher uses the information to determine the interventions required to improve schedule adherence  the vehicle, where schedule and relative headway information is provided to the driver, assisting him/her to manage schedule adherence on the road  the traffic priority system, which can grant priority to vehicles on-schedule or in delay, but not to vehicles running early, to reduce the risk of bunching (future scope)  the planning function, which uses information from the CAD/AVLS system to identify where the schedule may need to be adjusted to optimize schedule adherence The basic tools for schedule adherence are Computer-Aided Dispatch and Route Condition Monitoring. The dispatcher uses the information and tools available from these applications to make decisions on how to manage the service, and to get vehicles to depart on time or according to headway specification. Three additional software facilities can provide further assistance for Schedule Adherence:  Highlight delays and excessive intervals, so that the dispatcher focuses on these items  Predict and highlight to the dispatcher any vehicles that will arrive at the terminal point too late to commence their next trip on time. This uses a combination of current location, current delay status, and known sectional running times. This gives the dispatcher advance warning of delay events, allowing him/her to plan mitigating actions.  Predict and highlight to the dispatcher any vehicles that are likely to be in delay for a scheduled crew change or meal break, and thus cause cascading delays in services. This gives the dispatcher the opportunity to prioritize such vehicles for intervention, so that the change-over or meal-break happens on time.

5.6.3. Route Condition Monitoring

Route Condition/Status Monitoring application provides real-time information about the operational status of the route. They identify how the route is performing compared to the planned performance. They are typically implemented as a supporting application within a CAD/AVLS system.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 38 of 178 The application compares the real-time information about the route (vehicle location, speed, speed variances, delays) with the planned service (timetable, headways, running times). It identifies where the service is operating as planned, where it is at variance with the plan, and usually also analyses the severity of the variance. Optionally, it may acquire real-time and pre- planned information from external sources about events, disruptions, etc. The application presents the route condition to specified end-users. Most typically, this is to the CAD/AVLS dispatcher. In these cases, the route condition is presented in graphic and numeric format. This includes:  Summary indicator of status of all routes  Summary indicator of status of all routes assigned to the dispatcher or dispatcher cluster  Condition status of individual routes  Optionally, only alerts and variances beyond performance tolerance are shown Route condition monitoring application shall use visual tools to highlight the important information. Methods include:  Representation of the intervals between vehicles, either on the route map or as a separate screen  Color-coding of variances to indicate early/late running, bunching, excessive intervals  Flashing symbols for variances that need close attention  Audio alerts  Listing of key variances, optionally ordered by priority Route Condition Monitoring can also feed other systems. Real-time passenger information, traveler alert services, and journey planners can receive route condition information and include it in the advice provided to passengers. It can also be channeled to operations support staff, and to external entities.

5.6.4. Dynamic rescheduling

Dynamic Rescheduling is a facility within a CAD/AVLS system that allows the schedule to be adjusted in real time or semi-real time in response to prevailing circumstances. Dynamic rescheduling can operate at various levels of complexity, including the following situations:  Smoothing the schedule or headway pattern when a vehicle is missing  Recalculating the schedule or headway pattern when one or more additional vehicles are operated on a route (e.g. in response to unusually high demand)  Recalculating the schedule and intermediate times when a route diversion takes place  Recalculating the schedule based on the actual overall or sectional running times  Creating an alternative schedule in case of serious disruption In some cases, following the dynamic rescheduling process, the revised schedule is transmitted to the in-vehicle devices and to the real-time traveler’s information channels. This ensures that

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 39 of 178 the information channels can provide a reasonably accurate level of information to travelers. This is particularly important if the route or list/sequence of stops is adjusted.

5.7. Central Control Centre (CCC)

The central control centre represents the operational centre of the transport service where AVLS application system shall be used to manage inputs from the field devices, the schedule system, bus-stop database and radio system for general operational control, including vehicle dispatch and dynamic scheduling. Information retrieved by the control centre from the on-board AVLS devices shall be processed by PIS application for distribution of real-time passenger information services.

The central control centre shall act as a nerve centre for the purposes of operations management. The systems implemented as part of ITMS allow variety of technical and operations profiles to be deployed to manage transit needs on real-time basis. Some of the profile types are such as transit controllers, incident managers etc. including the technical staff ensure business services are delivered as expected and in-event of exceptions, the same are managed to reduce any impact on operations and business.

The job involves monitoring and maintaining operational functions of an electronic reporting facility requiring the ability to monitor and maintain a range of electronic & software services, security and telecommunications systems, receive, interpret and transmit information and determine responses to incidents and; monitoring the security of persons and infrastructure from a control room perspective requiring the ability to effectively operate security systems to monitor activities, co-ordinate appropriate responses to incidents and organise relevant procedures via stand operating procedures.

Some of the common functions carried out at CCC are:

 Monitor and maintain electronic & software systems  Process and organise data  Respond to incident  Prepare for operations  Monitor security activities  Maintain systems and information

5.7.1. System Description of CCC

The Central Control System shall act as the integration and common ITS infrastructure management centre which includes central applications, computing infrastructure and communication system. CCC will enable data and information from all equipment’s installed at Bus station/ Buses / Bus Terminals and other vehicles to be collected and processed for requirements mentioned in the scope of the implementation.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 40 of 178 The CCC shall process data in real time and schedule basis based on the process requirements from all the equipment through an online connected compute infrastructure to enable AVLS functions, service control and management, compliances and planning purposes. The service provider shall consult with the SMC on proposals for the type and range of operational and maintenance information to be prepared. The final content and format of presentation of processed data shall be discussed and finalised with SMC. All process as may be agreed between SMC and service provider at requirement finalization stage shall be process in term of SOP’s and implemented on the integrated platform using appropriate applications within the scope of implementation. The operator interface to the CCS shall facilitate operations management, reporting and service delivery based on the individuals functions identified for such resources. The service provider shall provide sufficient number of CCS workstations to facilitate audit, engineering, operations and maintenance functions. A hierarchical Access control system shall be incorporated across the system to ensure that persons can only gain access to the information or facilities that are relevant and authorised to their specific job. The CCS shall be capable of connectivity with various suitable communication service providers providing GPRS / CDMA / fixed line connectivity through leased lines. All communication networks shall be set up, managed and maintained by the service provider through appropriate contracting terms with communications service providers. The CCS shall be protected by appropriate fire walls from external access and outside world connections. The data transferred from the field to the CCS shall include, as minimum, information such as usage of various equipment. The CCS shall download configuration data to the equipment through Depot Management System/OTA for updating purposes. The information shall include system parameters, device parameters date and time synchronisation, sub-system application updates and employee identification number and password updates. The CCS shall be designed for autonomous operation of the various components of the ITMS to ensure that a failure in any one component of the system shall not disrupt the system as a whole. The CCS shall also provide stand-in facilities, in the event of prolonged communication failure with the systems. Such facilities may include updating on bus equipment via communication channels set up at Bus depots and other means for Bus station equipment. Depot configuration data files on the CCS shall be copied onto a backup media and hand carried to the Depots for Bus devices, if necessary. The system provider shall create a visual tracking space on the wall using LCD displays of appropriate sizes to enable control centre staff to monitor different tracking activities. This shall include and not limited to vehicle tracking console, Alerts console, Violations Console, Trip summary Controls etc.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 41 of 178 The central control centre operators should be provided with multi-screen option to perform analysis and event tracking in a way that data collaboration can be done. The system should additionally provide ad-hoc query based interface for the analysts to perform complex analysis. The system should provide functions to create new analysis / reports based on the user needs and same shall become part of the user report bin. The Central Control System shall generate the necessary management reports from all transaction information received from the field equipment’s. The CCS shall automatically collate all operations data; authenticate security features of operations data from the AVLS to provide secure and accurate audit and traffic statistics for the Buses / Routes of the depot. The Central Control System shall provide integrated console management for vehicle tracking and alerts management Controllers shall be responsible for ensuring safe and effective delivery of transit services to customers through responsible supervision and communication with Bus Operators. Controllers are responsible for direct supervision, prudent communications and support of operations service transit staff with regards to safety, service, scheduling and detailed documentation. Goals are to ensure a high quality transit service to customers, while maintaining a safety-first environment and cost effective system. The CCC shall be responsible for Public Transit communications, vehicle fleet management, planning and directing bus operations, utilization of transit supervisors, spontaneous decision-making, answering phone calls, performing detailed data entry, and overall street management of Public Transit operations. The CCC shall maintain duties including Help Desk and support functions, with a complete working knowledge of the Radio System, Reporting, AVL mapping and scheduling software. CCC Staff must be knowledgeable of work rules, transit contract parameters and be proficient with Microsoft Windows Applications. The CCC creates and implements all text/audio announcements for the transit system. CCC Controllers work closely with and in support of Bus Operators, Transit Supervisors, and any other contractor or city department / personnel, to ensure a high quality customer service experience to ridership. Primary Controller duties include; responding to all communications in a professional and helpful manner, ensuring that actions taken are quick and effective in handling the variety of situations that occur on a daily basis, including routine and emergency situations. Controller duties involve a high level of stress, while maintaining composure, professionalism and courtesy. Controllers are responsible for making on-the-spot analyses and decisions within the realm of authority, transit policy, contract terms and agreements. Controllers work varied hours, days and shifts, and may fill in as necessary. Controllers will perform other CCC related duties as assigned. The system should be able to provide Decision Support System to the control centre managers to dynamically manage despatch and scheduling system

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 42 of 178

5.7.2. General Software Architecture for SMC

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 43 of 178

5.7.3. Typical View for Software Components and Interfaces

5.7.4. CCS Communication Links:

The Service provider shall provide a reliable method of verifying the integrity of the data and programme files sent from the CCS to the field equipment’s and the correct reception of data uploads received from the devices at the CCS.

5.7.5. CCS hardware and software

The proposed set up should be capable to cater to meet the needs of a Real time Transit system involving more than 2000 vehicles, 1000 plus access gates and minimum 1,000,000 transactions per day. Additionally, the system should be capable of expanding and scaling with

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 44 of 178 additional deployment of hardware and necessary amendments to software for operations of 3 to 5 times the sizing stated above. The vendor is expected to deploy state of art monitoring screen systems for monitoring various activities like vehicles, exceptions, late & early buses, etc. on a video wall setting. Software: The software deployed shall include a package consisting of computer operating system software, diagnostic, testing, development and support software for the generation and modification of report contents and presentation. Security features shall be incorporated to prevent tampering with any data, programs, or other facilities of the CCS. The service provider shall provide an inventory / asset management and tracking tools for the management of all devices supplied. All computer software documentation for the CCS including workstations shall be provided by the service provider. Necessary technical information, concerning hardware, software and firmware including system architecture, shall be provided to SMC by the service provider upon full deployment of the system. Scope of software includes full functional AVLS and PIS etc. as mentioned in RFP document. The service provider shall provide asset / inventory management system managed through electronic tagging process. All equipment’s which form part of hardware supply shall have tags attached to them.

5.7.6. Configuration Data Management

Configuration data (CD) is the information transmitted from CCS to each device as a minimum package shall contain 1. Equipment Operations parameters 2. Configuration parameters 3. Application updates The CCS shall be capable of checking and handling exception, missing, duplicate, delayed and fabricated data. The system shall be able to track the continuity of all types of data of system devices in case the above problems occur. The CD Parameters shall have an effective date and time which may be any time in the future such that they are applied with immediate effect. If the effective date and time is set in the future, these parameters shall take effect on the specified date and time without further operator intervention. All the devices shall be able to handle at least one version of future CD parameters. However, there shall only be one current CD parameter list in the system and the system shall ensure that only one version of parameters takes effect in the system at any one time. Once a version of the CD parameters is deployed, it shall be locked to prevent any modification.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 45 of 178 The system shall allow only authorized staff to maintain parameters. A facility shall be provided as part of the CCS whereby the operational parameters can be modified and once verified and AUTHORISED can be transmitted to the Systems for implementation at a date and time to be specified. It shall be possible to use back-up media to allow for change in operational parameters to be implemented in the event that the communication links are down. The system shall allow CD parameters to be highly directive to the level of individual devices by the device ID and IP address The CD parameters shall be communication media independent, Shall be able to be sent via depot WAN / WiFi or via GPRS connections. The Configuration database shall be provided with a reporting tool to produce reports of various parameters and groups of parameters set on the system, sub-systems and devices

5.7.7. Data Storage

The database system shall satisfy the following requirements: Full-function RDBMS to Support complicated data structure will be deployed, multi-user, multiprocessing, large capacity operation, Offer data integration, data recovery and security, Support parallel processing, Provide disk mirroring functions , Authority control shall be independent of that of the operating system and Offer multilevel security management of database. Data storage capacity shall be sufficient to maintain six months transaction data available on line for ad hoc report generation and other investigations. The volume of data to be calculated for this requirement shall assume more than 1,000,000 transactions per day. The database shall be easily expandable to handle another 1 million transactions a day minimum. To maximise the utilization of the disk space of the system, system data shall undergo a regular housekeeping process. Housekeeping shall cover the files created by the CCS and the files relative to each subsystem. Any outdated or invalid files shall be archived. Duplicated records in the database and records where only the latest data need to be retained shall be merged and archived. The system shall be able to backup and recover data according to different modes and periods of backup required based on their criticality and data volume. The system shall have the functionality to backup and recover all key data (usage data, system data) and files.

5.7.8. CCC Security

Access security shall be implemented for Central Control System including data centre to manage authorized and authenticated movements only. The service provider shall be required to install biometric and card based system to secure operations centre.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 46 of 178 5.7.9. Clock Management

The Central Control System shall obtain the standard date and time and synchronize its clock automatically from SMC or its designated master clock system. The CCS shall synchronize its clock at least once every 15 minutes. If the clock is not synchronous to the standard time, the correction shall be completed in one second. The clock information shall be downloaded to all equipment’s. When the clock time of a device is different to the downloaded clock time, the device’s clock shall be corrected automatically to the downloaded clock time. The correction shall not happen with the trip of a bus to avoid incomplete transactions due to time variation.

5.7.10. Reports

The system as a minimum shall be delivered with capability to generate following reports, a comprehensive list of reports further than the mentioned below shall be finalized at the time of requirement finalization stage: a. Conductor / Driver Login reports for Day, week, month b. Non Compliance issues of different driver / conductors for the shift c. Trip summary. d. Bus Equipment Fault Summary e. Hourly Bus Usage Summary f. Total Commuters and revenue per Route, per Bus, per shift g. Revenues collected on same bus, same route, same trips by different Conductors h. ROI route wise, trip wise, shift wise i. Passengers boarding bus at a Bus stop – Time of day j. Daily pass usage and its ROI for the passes validated k. Student pass usage and the Cost of the subsidy that has to be refunded by Government- daily, weekly, monthly, yearly. l. Origin – Destination m. SC Bus Usage By Route Number n. Test Card Usage by route Number o. SMC employees usage of services p. Bus Service Disruption q. En-route Ticket Inspector Summary r. Boarding and Alighting Service

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 47 of 178 s. Boarding and Alighting statistics t. Passenger KMS analysis per trip configurable by the user u. Bus Rides and Revenue Statistics By Fare Code v. Bus Equipment Transactions w. Bus Faults Per Transactions Processed By Device x. Cash Revenues as per SMC MIS y. SCs not used for the week , Month z. Bus Equipment Fault Summary aa. Half-Hourly Bus Usage Summary bb. Total Patronage cc. Bus Patronage And Revenue Statistics By Service Number dd. Bus Service Revenue And Passenger Statistics Summary ee. Boarding Ride Bus Stop ff. Summary Of Bus Passengers Boarding By Service Number gg. System, Depot, Devices, STT CD parameters set current and pending future CD sets hh. Transfer Statistics The above state reports are only indicative, actual list could be exhaustive based on SMC’s requirements. The Service provider shall provide SMC a GRAPHICAL DASHBOARD to have visual view of all / some key reports/ parameters enabling quick decision making.

5.8. Fare Gate

5.8.1. Function of fare gate – Flap Type

The gates should provide fare processing ability to ensure that the transport system is only used by fare-paying passengers. It processes the fare media of each passenger wishing to enter or leave the transport system and allows or denies passage through the gate aisle according to the validity of the fare media. The gate can operate either under control of a station computer system or in a stand-alone mode. The barrier mechanism separates the paid zone and unpaid zone and gives an effective compromise between fraud prevention and physical safety of adult, child and handicapped passengers. The physical barriers are automatically opened in case of an emergency evacuation.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 48 of 178 5.8.2. SECURE ACCESS via GATE ADAPTATION KIT

The gate is identified by an electronics tag. Downloading security keys is protected through an authentication process between the gate and its host. The reader at the gate shall be a contactless smartcard reader supporting ISO 14443 cards type A and B. The gates should also have provision to install barcode based ticket validator.

5.8.3. Features of fare gate

 The different gate operating modes may be set locally or remotely. The modes are:  In service: Entry/Exit/Uni-Directional  Out of service: Out of service/Maintenance/Station Closed/Power Failure  Different fare modes are permitted by the business rules (set remotely and locally)  Business rules, operating parameters and fare tables updated by the central system

FARE PROCESSING  Fare media are checked for validity and updated in accordance with the business rules and fare tables currently in force  Media acceptable: Ultralight 'C'; DesFire , Mifare 4KB, DesFire 4K and equivalent (Mifare all types)  Other Media acceptable: RFID Tokens, Barcode based tickets For Barcode:  Read QR code printed on paper  Read digital QR code from mobile  Read Distance upto 4 cm from platen  Image Sensor 640 x 480 pixels min.  Scan Window 35mm x 50mm min.  10 mil resolution  White LED light source  Ambient Light 0 - 100,000 LUX FLAP GATES  Operate in normally- Open mode or Normally- Closed mode  Contact less smart Card or Token Passenger throughput: 40- 60 passengers/min  Barrier types: Central retractable flaps

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 49 of 178  Gap between flaps < 50 mm  Flap opening < 1 - 0.5 sec  Flap MTBF: > 6,000,000 movements  Flap MCBF: > 1,500,000 Cycles  MTTR: ≦30 Mins  Consumption: 250VA, 550VA peak  Minimum Clear Passage: 590 mm PHYSICAL CHARACTERISTICS  Integral body type unit made from stainless steel with a brushed finish  Passenger detection by optical sensors  Directional Display by LED Pictograms: Entry or Exit aisles visible up to 10m  User friendly display or LCD display provides clear and logical passenger interface  Invalid transaction warning (alarm and display)  Intrusion and fraud management (alarm and display)  Modular design with ease of maintenance  Recognition system, card readers and ticket validators should hidden in the cabinet.  Inner circuit - DC 24V and DC 12V to drive and control for safety  Built-in 8-digit counter - display passage records.  Cabinet with1.5mm thickness, ASIS/SUS-304 brushed stainless steel or coating.  40 mm soft polyurethane/plastic/PU-foam flap barrier.  High brightness LED light embedded panel emitting red cross and green arrow to enhance guidance for passengers.  Length of barrier should be minimum 1.6Mts and not more than 1.9 Mts ENVIORNMENT  Power supply: 220V ±10% 50Hz ± 2%  Operating Temperature Range: 0 oC to +50 oC  Humidity: 20% to 80% (non-condensing)  Power: AC110 / 220V, 50 / 60Hz, 1PH  Photocells: Minimum 14 pairs  Quality Certification: ISO 9001 / CE Input and Output

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 50 of 178

 Entry / exit direction input  Open status input  Compelling open signal input  Fire alarm input  Passage completion output  Error status alert

 Tailgating alert  Reverse intruding alert

IP Rating

Degree of protection of the enclosure: IP 43

5.9. Flap Gate Validator

Smart card validator shall be mounted inside the flap barrier and shall become integral part of the flap barrier assembly. Contactless card reader should be sleek and elegant, versatile and highly reliable. The validator will connect to flap barrier for operations purposes and also connect with station server to push and pull data from central use purposes. The built-in buzzer should signal the card holder when the card is read and provide transaction process details. Validator should supports contactless and EMV program specifications from Mastercard, Visa and Rupay.

The device should have minimum of 32-bit ARM 9 CPU and 12 MB memory that enable the development and operation of multiple types of payment applications. The device should be mountable through assembly system to flap barrier and should have suitable I/O and data ports to manage required processes. Features

Supports contactless applications - MasterCard PayPass - Visa payWave - American Express ExpressPay - Discover Zip - Interac Flash - ISIS

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 51 of 178 Should have large capacity memory to store at least 7 days of transaction data.

Technical Specifications

Processor Minimum 32-bit ARM9

Memory Minimum 12MB (4MB Flash, 8MB SDRAM) Up to 24MB (8MB Flash, 16MB SDRAM)

Contactless Card Reader 13.56MHz, ISO14443 Type A/B, Mifare®,Ultralight 'C'; DesFire, NFC, 4 RF Indicators

Card Slots 4 SAM Slots, ISO7816

Peripheral Ports 1 x RS232 or 1 x USB

Buzzer 95dB

Environmental 0°C to 50°C ( 32°F to 122°F ) operating temperature 5% to 90% relative humidity, non-condensing -30°C to 70°C ( -22°F to 158°F ) storage temperature

External power supply DC5V, 500mA

Physical Reader: Length: 137mm, Width: 88mm, Height: 28mm Approx

Certifications MasterCard PayPass, Visa payWave, Rupay, Discover Zip, Interac Flash, ISIS, EMV Contactless L1

Operating System Windows / Linux / Android (4.2 or above)

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 52 of 178

5.10. Business Intelligence Platform for Reporting

BI platform shall enable SMC to build reports from operations data to perform multi-dimensional analysis enabling to have better insight into parameters and enable SMC to take business decisions leading to higher operational efficiency. The BI tool hence should offer following:

5.10.1. Management Dashboard

Interactive Visualization

1. Display information in an easy-to understand format and use intuitive and interactive visualization to enable management users within SMC to quickly navigate, understand, and investigate data elements to make informed decisions.

2. Allow users to capture and export the current display through electronic reports and in different printer-friendly formats, including, at a minimum, MS-Excel, PDF, and Web formats.

3. Have a default configuration and landing page for each user or user-group that are editable.

4. Allow multiple visual elements to be laid out on the same display.

5. Have the ability to display dashboards and reports using different visual elements including charts, maps, calendars, gauges, images, tables, visual and textual lists, and alerts as follows:

 All visual elements shall have editable titles, labels, legends, axes, icons, and colors, where applicable.

 Interactive visualization component shall display the overall aggregate status of a SMC’s KPI with proper color coding (green, yellow, red, or as defined by SMC’s preferences). It will allow the user to drilldownand switch between differentKPIs (e.g. KPI for average vehicle utilization, average vehicle duration, etc.)

 Display clickable contextual information related to the metrics being viewed and allows the user to drilldown on contextual information as required. Charts shall support at least the following chart types:

a. Bar Charts b. Histograms c. Line Charts

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 53 of 178 d. Heat Maps e. Pie Charts f. Grids g. Area Charts h. Timeline Charts i. Bubble Charts j. Radar Charts k. Scatter Plots l. Doughnut Charts m. Pyramid Charts

6. Maps shall have GIS Maps extension to allow plotting different mark-ups and indications on a map view using base and spatial map layers and allow the user to zoom and pan freely through the map, and be able to present heat map visualizations on GIS map data.

7. Calendars shall allow the user to intuitively navigate through calendar fields, such as day, month, and year. Calendars shall allow the user to intuitively navigate through calendar fields, such as day, month, and year. Gauges shall have the look and feel of an analog gauge (needle) with configurable level markings (green, yellow, red, or as defined SMC’s management preferences) that gives a visual display of the amount, level, and measure of defined KPI

Tables shall be able to:

 Hold a large amount of data.

 Allow the user to scroll through the data in all directions.

 Freeze the header columns and rows when the user scrolls.

 Allow the user to enlarge/decrease the font.

Visual and textual lists shall allow the user to scroll through all of the available list items with smooth scrolling.Allow the user to choose the proper visual element required to display the required KPI data and allow the user to easily switch between alternative visual elements.

8. Have view-management tools, allowing the user to move, reorder, enlarge, shrink, open, and close visual elements with intuitive interaction.

9. Allow the user to create a new visual element based on the available visual element types and customize an existing visual element with an easy-to-use graphical interface.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 54 of 178 10. Allow the user to save any customization done on a visual element.

11. Have zero-programming mashup capability that allows the user to configure queries and data mashups visually through drag-and drop functionality.

12. Allow the user to drill down to display increasingly detailed data on various data elements

13. Allow intuitive visual filtering, focusing, and selection of the displayed data and information.

14. Automatically update the parameters and filters of the displayed data when the user drills down through visual elements and update the other visual elements accordingly. Also, enable selection of filters through the visual elements and propagate selection to all visual elements in the dashboard.

15. Allow the user to filter and sort the presented data based on a number of attributes including the time period or on multiple attributes simultaneously.

16. Allow the user to search through visual elements that display numerous data entries such as tables and lists.

17. Allow the user to save the current filter and selection parameters.

18. Understand different types of structured data including numbers, percentages, fractions, general text, coordinates, and objects.

19. Store the user configuration and customizations information.

20. Have the ability to mashup different types of data from multiple sources with automatic detection of relationships between the data components and an option to manually define/overwrite relationship.

21. Run mathematical, statistical, and analytical operations on available data.

22. Compute trends and projections from data based on available historical data and based on data from external systems to enable informed decision-making.

5.10.2. Searching & Filtering

1. Allow the user to drill down and search through the large amounts of data easily and quickly by time periods and other search criteria defined by the user. Also, provide user guidance for searching & filtering through data

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 55 of 178 2. Generate reports from the current view in different electronic formats including at least MS-Word, MS-Excel, PDF, and Web formats and that are printer-friendly Not require programming knowledge or knowledge of SQL or databases to perform searches, queries, and filters.

3. Allow reports to be sent directly to a network printer.

4. Display a huge amount of data in a clear and organized view

5. Allow the user to hide or show parts of the data

6. Offer the capability to search multiple data sources effortlessly through a GUI

7. Allow the user to search, filter, and sort the presented data based on any attribute or on multiple attributes simultaneously

8. Allow the user to graphically define complex queries that contain multiple parameters and span different data sources.

9. Allow the user to search through historical data

10. Allow the user to save the current queries, filters, and selection parameters

11. Have data-pivoting capabilities

12. Understand different types of structured data including numbers, percentages, fractions, general text, coordinates, and objects

13. Store saved custom queries

5.10.3. Reporting

1. The system shall have the ability to allow the user to generate reports based on predefined report templates or by manually selecting the data and the corresponding visual elements.

2. The system shall have the ability to provide a GUI with drag-and-drop functionality for creating custom formatted reports that include visual elements, objects, and formulas.

3. The system shall have the ability to Display the list of available report templates, saved reports, and recently used report templates when the user logs in.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 56 of 178 4. The system shall have the ability to Allow the user to create, load, modify, delete, and save report templates graphically.

5. The system shall allow reports to be generated and published on an ad-hoc or scheduled basis with the ability to predefine a list of recipients and a regular schedule through a GUI.

6. The system shall be able to generate reports in different electronic formats including at least MS-Word, MS-Excel, PDF, and Web formats and that are printer-friendly.

7. The system shall allow reports to be sent directly to a network printer.

8. The system should have the ability to generate planning and forecasting reports for providing the information related to planning for no of buses to be transported

9. The system shall have the ability for the reports to have the ability to drill down to multiple levels

10. Reports should have the ability to print

11. Publish reports and dashboards for planned Vs. actual data, for example the system should allow the management user to view the planned budget vs. the actual revenue spent for a particular route

12. The system shall allow to publish reports and send them to recipients through email attachments and to a central data store to be accessed by different users.

13. The system should not require any programming knowledge, knowledge of SQL, or dataset to create self-service ad-hoc reports.

14. The system shall allow the user to use previously defined objects and formulas or create new custom objects and formulas and save them for repeated use.

15. The system shall allow the user to save any configuration done on a visual element.

16. The system shall have the ability to display data elements using different visual elements including charts, maps, calendars, gauges, images, tables, visual and textual lists, and alerts as follows:

 All visual elements shall have editable titles, labels, legends, axes, icons, and colors where applicable.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 57 of 178  Display the overall aggregate status of KPI with proper color coding (green, yellow, red, or as defined per SMC’s preference) and allow the user to perform an interactive visual drilldown and to switch between different KPIs.

 Display clickable contextual information related to the KPI being viewed and allows the user to drill-down on contextual information as required.

 Charts shall have different types including: Bar Charts, Histograms, Line Charts, Heat Maps, Pie Charts, Grids, Area Charts, Timeline Charts, Bubble Charts, Radar Charts, Scatter Plots, Doughnut Charts, and Pyramid Charts.

 Maps shall have capabilities to show different mark-ups and KPIs on a map and allow the user to zoom and pan freely through the map.

 Calendars shall allow the user to intuitively and visually change the selected day, month, and year.

 Images shall allow the user to zoom and pan within an image and move between images intuitively.

 Tables shall be able to hold a large amount of data, allow the user to scroll through the data in all directions, freeze the header columns and rows when the user scrolls, and allow the user to enlarge/decrease the font.

 Visual and textual lists shall display an unlimited number of entries and allow the user to scroll through them.

 Alerts shall be configurable allowing for different alerts with various icons and colours to be defined and displayed.

17. The system shall allow conditional formatting, based on thresholds or data ranges, for any cell/object in the report.

18. The system shall allow the display of multiple data elements and result sets in the same report.

19. The system shall allow the user to display historical data side-by-side or overlapping in views where applicable.

20. The system shall display the generated report on screen.

21. The system shall have zero-programming mashup capability that allows the user to configure queries and data mashups visually through drag-and-drop functionality.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 58 of 178 22. The system shall automatically update the parameters and filters of the displayed data when the user drills down through views.

23. The system shall allow the user to display historical data for the current filter and selection

24. The system shall offer the capability to add new data sources easily through a GUI.

25. The system shall allow the user to filter and sort the presented data based on any attribute including time period

26. The system shall allow the user to filter and sort the presented data based on one or multiple attributes simultaneously.

27. The system shall have mathematical capabilities to be used to manipulate data, including basic and advanced arithmetic and statistical operations.

28. The system shall allow the user to filter and search through the different data sources.

29. The system shall allow the user to save the current queries, filters, and selection parameters.

30. The system shall have data-pivoting capabilities. 31. The system shall store the report templates and generated reports.

32. The system shall understand different types of structured data including numbers, percentages, fractions, general text, coordinates, and objects.

33. The system shall have the ability to mashup different types of data from multiple sources with automatic detection of relationships between the data components and an option to manually select the required relationship.

34. The system shall run mathematical and statistical operations on available data.

35. The system shall compute trends and projections from data series.

5.10.4. Data Retrieval & Management

General Data Retrieval

1. Provide fast, secure, reliable, and easy mechanisms to retrieve information and data from the different data sources to meet the dashboard KPI requirements.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 59 of 178 2. Provide different mechanisms for retrieving data from different data sources including ETL, File Transfer, and Real-time integration.

3. Log all received information from entities.

4. Allow the user to define and connect new data sources and data stores effortlessly through a GUI.

5.10.5. ETL

1. Perform ETL to extract, transform, and load operations to move the data from internal and external data sources to the staging environment and from the staging environment to the Storage environment.

2. The system shall have the ability to perform multiple transformations on data including but not limited to

a. Selection b. Translation c. Encoding d. Derivation e. Sorting f. Joining (merging) g. De-duplicating h. Aggregation i. Transposing (pivoting) j. Splitting k. Lookup

3. Provide the ability to define, configure, and manage ETL jobs

4. Support import and export wizard and supporting connections with source and destination adapters including but not limited to OLEDB, flat files, and XML formats

5. Have scheduling capabilities based on time, events, and triggers

6. Offer the capability to define and connect new data sources and destinations effortlessly through a GUI

7. Provide a user-friendly GUI to allow the user to handle ETL processes including: a. Modifying data feeds b. Changing of business logic used for data ETL

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 60 of 178 c. Modifying ETL parameters d. Creating e. Editing f. Executing a large number of transformation rules

8. Allow the user to view the data at different stages

9. Allow the user to search, filter, and sort the data by stage, source, and type 10. Allow the user to search the metadata 11. Support batch data extraction, transformation and loading 12. Store ETL rules and schedule 13. Store the data at different stages including the raw data

Real-Time Integration with data sources

1. The system shall have the capability to integrate with data sources on the real time basis to fetch the information

2. The system shall be able to quickly retrieve the data with minimal time lag 3. The system shall have the ability to capture the failed transaction

File Transfer

1. The system shall support data retrieval through transferring files automatically using secure file transfer protocols such as the Secure File Transfer Protocol (FTP over SSL) protocol.

2. The system shall support automatic file upload capabilities that can detect a new file and upload it.

3. The system shall automatically rename the uploaded file to a proper filename including the source, date and version, based on configurable file-naming rules

4. The system shall properly manage duplicate submissions by keeping the old file and applying proper versioning and renaming

5. The system shall provide an intuitive graphical interface to AVLS Backend Users to:

 Define the methods and rules for the file transfer such as maximum file size and supported types.

 Define and manage the connections, file sources, file destinations, file processing, and file storage.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 61 of 178 6. The system shall allow the Backend Users to view file transfer history with filter and sort capabilities

7. The system shall perform quality management on data provided through file transfer including validation and verification of file type and size and return errors and required corrections accordingly.

8. The system shall be able to receive and store large files as specified in the configurable file transfer rules

9. The system shall Be able to store a history of uploaded files information and content

5.10.6. Data Quality Management

1. Perform data cleansing, verification, validation, and reconciliation automatically and based on defined rules

2. Allow the user to manage the data quality process workflow and rules using a GUI

3. Compare the data to historical data as reference data for detecting anomalies

4. Rank the completeness and validity of the processed data

5. Store data quality verification rules and process workflow

6. Store historical data

Data Stores

1. Retrieved data from different data sources should be temporarily stored and processed in separate Operational Data Stores (ODSs).

2. Data used to perform visualization, reporting, and searching operations should be stored in appropriate Storage environment (e.g. Data warehouse)

5.10.7. BI Configuration and Management

BI Configuration Management

1. The system shall allow the authorized user to complete the following functions:

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 62 of 178  Manage the different KPIs available by adding, modifying, or deleting KPIs or KPI groups areas using a GUI.

 Enable or disable KPI which activates or inactivates it but does not delete it (soft deletion).

 Configure a KPI including its ID, name, description, area, data source, format, unit, frequency, and formula.

 Configure the user access level required to view each KPI.

 Choose the default and alternate views for displaying a KPI.

 Drill down by clicking on a KPI to view its details and edit it.

 Search, sort, and filter KPIs by ID, name, frequency, measure, and indicator area.

 Show/hide disabled KPIs from the KPI management screen.

 Manage data sources for the KPIs easily through a GUI.

2. The system shall have the ability to present an intuitive GUI allowing the authorized user to configure the threshold values and levels (green, yellow, red, or as defined per management preference) for a KPI by defining score card algorithms.

3. The system shall have the ability to clearly present multiple KPIs in the same view

4. The system shall have the ability to Configure KPIs that are aggregates of multiple other KPIs from different areas

5. The system shall have the ability to instantly and automatically update the other dashboard components with any new KPI or changes to the configuration of current KPIs

6. The system shall have the ability to Store each KPIs current and historical measure

7. The system shall have the ability to Configure KPIs with multiple data sources

8. The system shall have the ability to run algorithms to calculate the measure of a KPI based on data from subset KPIs

9. The system shall have the ability to Store the different access levels for each of the authorized users.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 63 of 178

5.10.8. Dashboard and Reporting Requirement for ITMS

The list of reports given below is partial list and is being provided for the sake of understanding from the perspective of providing insight into the type of solution required to meet SMC’s business process requirement. List of Daily Reports needed for the service performance monitoring:

Category: Bus Maintenance and Availability

o Bus Availability How many buses are available in the depot at the beginning of the shift daily? o Bus Breakdowns How many buses are in the workshop for repairs, how many buses breakdown during while in service? When multiple routes are operations, this information will be needed per individual route as well. Bus kilometers between two breakdowns of same bus (individual bus wise) o Bus Maintenance Individual Bus report consists of preventive maintenance and all other work done on that bus with kilometers. o Schedule Adherence of individual trip of bus Scheduled adherence report based on published schedule and actual schedule. Ability to sort the report by the operator by the trip will be useful. o Operational Issues on Field: Bus bunching etc. Incident reports to be generated based on information gathered by the control room on a daily basis. These reports should have bus number, trip number, operator number, time of the day, type of incident.

Category: On Time Performance

Definition of On Time Performance will be finalized in consultation with SMC. Time Points within individual routes will be introduced for OTP. For all OTP, need % early, % OT and % late.

o Scheduled KM by trip versus Actual KM by trip and Summary for day The report will have scheduled kilometers against actual kilometer by trip and by day. When multiple routes are operational, this information will be needed per individual route as well. The report should generate missed trips or missed kilometers per individual routes. o On Time Performance (OTP) for Individual Trip System and trip on time performance report for individual routes and feeder routes. o Daily peak, base and evening performance OTP o Cumulative daily performance OTP o Weekdays and weekend performance OTP o Waiting time of bus at the junction and time to clear the junction during off peak, medium peak and peak hours.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 64 of 178 o Speed of a bus between stations o Speed violation Category: Station and Passenger Information

o Arrival and departure per station by individual trip The report should be generated to give arrival and departure information per station for individual trips. Then for each station, the average dwell time should be calculated and measured against the total number of boarding if available. o Using Smart Card o Origin and destination of a trip and length of trip o Boarding and alighting information by individual stations by direction of route o No of trips per day and per month o No of trips per day and per month of individual smart card user o Per station Revenue o Per Bus Revenue o Ticket Consolidation report o Settlement report

Data for fare and revenue shall be provided by the fare collection software provider agency and Service provider shall be required to incorporate the same in dashboards and reporting.

5.10.9. Transit Performance Measures

Service Offered / Utilization Total no. of passengers travelled in 1 Average Daily Ridership a month / No. of days Total no. of passengers travelled in 2 Total Monthly Ridership a month Average Trip Length Total of (Passenger * KMS travelled) 3 Week day in a day / Total passengers travelled Week End in a day Vehicles operated in Maximum Service Total no. of buses operated during 4 / day peak hours Total KMS travelled by a bus in a 5 Vehicle utilization / day day Economics Total passengers travelled in a bus / 6 Passenger / revenue KM total revenue KMS of buses in a month

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 65 of 178 Total fare collection in a month / total 7 Fares / revenue km revenue KMS of buses in a month

Vehicle Operating expenses / revenue 8 As per contract km 9 Operating Ratio Cost per bus / earning per bus Total staff utilized for each bus 10 Staff / bus ratio operations Availability 11 Service Coverage As per the corridor in operation Frequency of buses During Peak 12 Medium Peak During off peak 13 Hours of Service No. of operational hours of BRTS 14 Average Waiting Time for users Convenience Passengers / trip Total no. of passengers in a day / 15 During peak hours total no. of trips of buses in a day During off peak hours Avg. dwell time of buses at bus 16 Dwell Time stops 17 Load factor (passenger-km / capacity-km) * 100 Inverse of (Breakdown/million KM) Safety Inverse of (accidents/million KM) Total fatalities / total length of BRTS Fatality rate / Km 18 corridor Total no. of fatalities of pedestrian Fatality rate for pedestrian & NMT and NMT / total fatalities on road Waiting time of pedestrians at Signalized intersection delay for 19 intersections to reach BRTS bus pedestrians stop Vehicular Capacity 20 Bus Capacity Designed capacity of bus Passengers in peak hour peak Bus lane Capacity 21 direction 22 Volume–to–capacity ratio Comparison of capacity usage Speed / Delay Average travel speed of BRTS bus 23 Average Travel Speed of BRTS during peak hours

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 66 of 178 24 Signalized intersection delay of BRTS

5.11. Enterprise Management System

An EMS solution consists of the following core modules:

1. Network Fault Management System: This provides fault and performance management of the network infrastructure that various services operate in. It provides Network Discovery & Reporting, Fault Analysis, Configuration Management, Advance IP Services Management, Service Management and Integrations with other modules.

2. Integrated Performance Management System: This provides a comprehensive end-to-end performance management across key parts of the IT infrastructure. It allows identifying trends in performance in order to avert possible service problems and consists of :

a. Network Performance Monitoring: The Network Performance Management consoles provides a consistent report generation interface from a single central console. This central console also provides all the required network performance reports (including latency, threshold violations, packet errors, availability, bandwidth utilization etc.) for the network infrastructure. b. Integrated Network Traffic Analysis System: This provides details of applications, hosts, and conversations consuming WAN bandwidth to isolate and resolve problems. Traffic monitoring system is able to track 100% of all flow traffic on the network and identify malicious behaviour with all IP conversations. It uses non-intrusive monitoring to reduce the impact on the monitored network and improve scalability. c. Server Performance Monitoring: This integrates network performance management systems and give the unified performance state view in a single console. The performance state of the entire network and server infrastructure is visible in an integrated console. d. Database Performance Monitoring: This integrates network and server performance management systems and provides the unified view of the performance state in a single console. It automates monitoring, data collection and analysis of performance from single point.

3. Application Performance Management System a. Application Transaction Performance Monitoring System: This determines if the root cause of the performance issues is inside the monitored application, in connected back- end systems or at the network layer from a single console view. It proactively monitors 100% of real user transactions, detect failed transactions, gather evidence necessary for triage and diagnosis of problems that affect user experiences and prevent completion of critical business processes. b. End-user Experience Monitoring System: This measures the end users' experiences based on transactions without the need to install agents on user desktops. It detects user impacting defects and anomalies and reports them in real-time - Slow Response Time,

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 67 of 178 Low Throughput, Partial Response, Missing component within transaction.

4. Integrated Helpdesk Solution: A Helpdesk Management Solution improves quality and responsiveness of IT support by automating help desk, self-service and root cause analysis. It provides flexibility of logging, viewing, updating and closing incident manually via web interface.

5.11.1. Management of Infrastructure at Client-side locations

Under the proposed RFP, there will be a number of client-side IT infrastructure components (Desktops, Servers, Laptops, and Printers etc.) that will need to be managed from various aspects like asset management. Specific management solutions should be provisioned to carry out Asset Management, Software inventory and Hardware inventory at client side locations and central data center.

1. Security Management System: With the ever-increasing number of security breaches and the potential of crippling the entire transport system of a city down with such kind of a breach, the importance of security of the entire system cannot be under-mined. While the external threats are warded off with provisioning of firewalls, anti-virus, Intrusion Detection and Prevention systems and cordoning off DMZs, the threat from internal users (departmental users and personnel of the contracted agencies) to the system also need to be recognized and guarded from. The Security Management solution must consist of the following core module : a. Log Record Collection and Management : This helps automatically collate logs from the various infrastructure elements across the system, provides a graphical user interface/wizard to rules for normalizing custom log sources or modifying existing integrations, provides automated update mechanism for Content (product integrations and reports) and monitors the current status and relative health of the logging infrastructure. Client end agents may be used for collection / analyse such logs.

2. Service Level Management: The entire operations would be run in a services model, with several parts of the operations contracted to various agencies/ vendors (including a number of bus operators who will run buses on various routes, IT service providers and numerous other vendors). Service Level Management for each of these service vendors and the associated contracts with each of them will be a challenge.

In such a scenario it is necessary to automate, activate and accelerate the management, monitoring and reporting of Service Level Agreements (SLAs) and service delivery. Provisions should be made for a Service Level Management (SLM) tool that takes a top-down approach – starting from business relevant service descriptions and measurement, define service metrics, establish contractual obligations and performance targets in real-time, take action based on this performance, and collaboratively report performance to both service provider and service consumer.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 68 of 178 5.11.2. Detailed Specifications for Enterprise Management System

Enterprise Management Solution should provide end-to-end, comprehensive, modular and integrated management of IT infrastructure components to maximize the availability of IT services and SLA performance. The management system needs to aggregate events and performance information from the domain managers and tie them to service definitions.

The proposed tools should automatically document problems and interruptions for various IT services offered and integrate with the service level management system for reporting on service level agreements (SLAs). The proposed solution must be unified and also generate a comprehensive view of a service with real-time visibility into service status and identify the root cause of various infrastructure problems as well as prioritize resources based on impact. The proposed EMS solution must consist of the following core modules: 1. Network Fault Management System 2. Integrated Performance Management System for: a. Network Performance Monitoring b. Integrated Network Traffic Analysis System c. Server Performance Monitoring d. Database Performance Monitoring 3. Application Performance Management System a. Application Performance Monitoring System b. End-user Experience Monitoring System 4. Integrated Helpdesk Solution 5.11.3. Network Fault Management System

Provide fault and performance management of the network infrastructure that various services operate in. The proposed System will provide the following features: a. The Network Fault Management consoles must provide the topology map view from a single central console. b. The proposed Network Fault Management console must also provide network asset inventory reports and SLA reporting for the managed network infrastructure.

Network Discovery and Reporting:

 The proposed solution must automatically discover manageable elements connected to the network and map the connectivity between them.  The proposed system must support multiple types of discovery including the following : o IP range discovery – including built-in support for IPv6 o Import data - from pre-formatted files (IPs, ranges, strings or ports) o Host Name discovery o Service based discovery – including ping, FTP, JDBC, HTTP etc.  The system should provide discovery & inventory of heterogeneous physical network devices like Layer-2 & Layer-3 switches, Routers and other IP devices and do mapping of

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 69 of 178 LAN & WAN connectivity with granular visibility up to individual ports level.  The system must be able to support mapping and modelling of the infrastructure grouped by network connectivity, physical location of equipment and user groups or departments.  The modelling of network connectivity must be performed using standard or vendor- specific discovery protocols to ensure speed and accuracy of the network discovery.  The system should support maps grouped by network topology, geographic locations of the equipments and user group/departments. These should help in understanding physical Network, virtual Network services and the relationships between them.  It shall be possible to reduce the set of displayed devices in the topology views by flexible rules, based on the attribute contents stored with each device.  The system must provide visualization tools to display network topology and device to device connectivity. The system must also be able to document connectivity changes that were discovered since the last update.  The system must provide a user-configurable event to alarm mapping system that sets a differentiation that events do not necessarily need an alarm to be generated.  The proposed solution must provide a detailed asset report, organized by vendor name and device, listing all ports for all devices. When a report is run the administrator must have an option of specifying the number of consecutive days the port must be “unused” in order for it to be considered “available”.  The proposed solution must provide sufficient reports that identify unused ports in the managed network infrastructure that can be reclaimed and reallocated. The proposed management system must also intelligently determine which ports are operationally dormant.  The proposed solution must poll all the ports to determine if any traffic has passed through it. If not the port must be marked unused for that day.

Fault Analysis:

 The proposed solution should provide out of the box root cause analysis with multiple root cause algorithms inbuilt for root cause analysis. It should also have a strong event correlation engine which can correlate the events on the basis of event pairing, event sequencing etc.  The system must be able to ‘filter-out’ symptom alarms and deduce the root cause of failure in the network automatically.  The system should support creating and monitoring of rising or falling thresholds with respect to basic key performance indicators for network, system and application infrastructures and provide immediate notification when service metrics fall outside the baselines.  The proposed system must include the ability to monitor and visualize a virtualized system infrastructure by discovering and monitoring virtual machines and providing ability to depict the logical relationships between virtual servers and virtual machines.  The proposed solution must detect virtual server and virtual machine configuration

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 70 of 178 changes and automatically update the topology.  The proposed system must support enhanced fault isolation to suppress alarms on logical VMs.  The proposed solution must have the ability to collect data from the virtual systems without solely relying on SNMP.  The proposed solution must support WMI for collecting and isolating Windows host issues.  The proposed solution must support SSH polling method to collect and isolate Linux host issues.  The proposed solution must support an architecture that can be extended to support multiple virtualization platforms and technologies.

5.11.4. Configuration Management

 The system should be able to clearly identify configuration changes as root cause of network problems.  The system should support secure device configuration capture and upload and thereby detect inconsistent “running” and “startup” configurations and alert the administrators.  The proposed system should be able to administer configuration changes to network elements by providing toolkits to automate the following administrative tasks of effecting configuration changes to network elements : o Capture running configuration o Capture startup configuration o Upload configuration o Compare configuration  The proposed solution must be able to perform real-time or scheduled capture of device configurations.  The proposed solution must be able to store historical device configurations captured in the database and thereby enable comparison of current device configuration against a previously captured configuration as well as compare the current configuration against any user-defined standard baseline configuration policy.  The proposed system should be able to monitor compliance & enforce change control policies within the diverse infrastructure by providing data & tools to run compliance reports, track & remediate violations, and view history of changes.

Advanced IP Services Management:  The proposed solution should be able to monitor MPLS – VPNs by automating the provider connection resolution and monitoring the service health with an option to auto-provision service assurance tests to proactively calculate the availability of remote sites  The proposed solution should be capable of managing the VPN Service including a complete Service Discovery of all the Devices and components that support each VPN. The solution must be able to automatically configure and provision site-to-site VRF Ping tests on each router that support VPNs to verify the ability to ping each other.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 71 of 178  The proposed solution should be able to support response time agents to perform network performance tests to help identify network performance bottlenecks.  The proposed solution should be able to monitor QoS parameters configured to provide traffic classification and prioritization for reliable traffic transport.  The proposed solution should provide the ability to discover, map & monitor multicast sources & participating routers wherein the system should be able to visualize the distribution tree in the topology map.

5.11.5. Service Level Management

 The proposed service management system should provide a detailed service dashboard view indicating the health of each of the departments / offices in the organization and the health of the services they rely on as well as the SLAs.  The proposed Service Dashboard should provide a high level view for executives and other users of the system. The system should provide an outage summary that gives a high level health indication for each service as well as the details and root cause of any outage.  The system must breakdown SLA by the hour and should allow to drill down on each hour to report violations.  The system must be capable of managing IT resources in terms of the business services they support, specify and monitor service obligations, and associate users / Departments / Organizations with the services they rely on and related Service / Operational Level Agreements.  The Users definition facility must support defining person(s) or organization(s) that uses the business Services or is a party to a service level agreement contract with a service provider or both. The facility must enable the association of Users with Services and SLAs.  The Service Level Agreements (SLAs) definition facility must support defining a set of one or more service Guarantees that specify the Service obligations stipulated in an SLA contract for a particular time period (weekly, monthly, and so on). Guarantees supported must include one that monitors service availability (including Mean Time to Repair (MTTR), Mean Time between Failure (MTBF), and Maximum Outage Time thresholds) and the other that monitors service transaction response time.  Root cause analysis of infrastructure alarms must be applied to the managed Business Services in determining service outages.  SLA violation alarms must be generated to notify whenever an agreement is violated or is in danger of being violated.  The system must provide the capability to designate planned maintenance periods for services and take into consideration maintenance periods defined at the IT resources level. In addition the capability to exempt any service outage from impacting an SLA must be available.  The system must provide the capability of Advanced Correlation for determining Service health, performing root cause analysis, and fault isolation. This must include applying complex Boolean logic on multiple attributes and infrastructure alarms.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 72 of 178  The system must provide a real time business services Dashboard that will allow the viewing of the current health of required services inclusive of real-time graphical reports.

Deployment Features:  The operations console and associated management system should be deployable in a separate physical web-server to reduce the load on the primary management server.  The system should allow to install at least 4 to 5 modules on a single server to save on operational cost and TCO.  The security must be able to permit or restrict operator access to different areas of information based on user security rights assigned by the administrator.  The system needs to support concurrent multi-user access to the management system, enabling multiple read-write access to different areas of the management domain and support operator workflows.

Integrations:  The proposed NMS should provide unified workflow between the fault and performance management systems including bi-directional and context-sensitive report generation.  The proposed system should integrate with the performance management system using a synchronized discovery and single sign-on for operators / administrators between them to enable unified Administration and ease of workflow.  The system must support seamless bi-directional integration to helpdesk or trouble ticketing system.  The proposed system should integrate with the helpdesk system by updating the Asset with information to support viewing history or open issues in helpdesk on the particular managed asset and associate an SLA to the ticket in the helpdesk.  The proposed system should allow to attach/describe an asset identifier when submitting a helpdesk ticket.

5.11.6. Performance Management:

This provides a comprehensive end-to-end performance management across key parts of the network infrastructure. It should allow identifying trends in performance in order to avert possible service problems.  The proposed performance management system shall integrate network, server and database performance information and alarms in a single console and provide a unified reporting interface for network components. The current performance state of the entire network & system infrastructure shall be visible in an integrated console.  The proposed solution must scale to large networks while supporting a single web interface for access to reports. The system must support multiple locations and a distributed deployment for collection and monitoring. Primary instrumentation should exist in the data center.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 73 of 178  Provide SNMP device management of the network and server infrastructure.  Provide flow-based reporting for network troubleshooting and capacity management.  Provide Server Performance Monitoring as described.  Provide Database Performance Monitoring.  Provide Application Transaction Deep-Dive Monitoring for Web-Based Business Applications.  Provide End-User Response Time Monitoring for Browser-Based Applications.

Network Performance Management and Performance Reporting System:  The Network Performance Management consoles must provide a consistent report generation interface from a single central console.  This central console will also provide all required network performance reports (including latency, threshold violations, packet errors, availability, bandwidth utilization etc.) for the network infrastructure.  The proposed system shall collect, analyze and summarize management data from LAN/WAN, MIB-II interfaces and various servers for performance management.  The proposed system shall identify over-and under-utilized links and assist in maximizing the utilization of current resources  The proposed system shall provide Performance of Network devices like CPU, memory & buffers etc, LAN and WAN interfaces and network segments.  It shall provide comprehensive health reporting to identify infrastructure in need of upgrades and immediate attention. Capacity planning reports shall identify network traffic patterns and areas of high resource utilization, enabling to make informed decisions about where to upgrade capacity and where to downgrade or eliminate capacity. It should also support ‘What if’ analysis and reporting to enable understanding the effect of growth on available network resources.  The proposed system shall provide easy to read representations of health, utilization, latency and availability.  It shall provide Real time network monitoring and Measurement of end-to-end Network performance & availability to define service levels and further improve upon them.  The proposed system must have a report authoring capability built-in which will enable complete customization flexibility of performance reports for network devices and monitored servers.  The proposed system should provide a real-time performance view for all the managed systems and networks along with the various threshold violations alarms in them. It should be possible to drill-down into the performance view to execute context specific reports.  The tool should have the capability to configure different polling speeds for different devices in the managed infrastructure with capability to poll critical devices using 30 second poll periods.  The system must provide the following reports as part of the base performance monitoring product out-of-the-box to help network operators quickly identify device problems : o Trend Reports to present a single graph of a single variable (e.g. CPU utilization) for

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 74 of 178 multiple devices across time. This would help network operators & IT managers plan for capacity and identify long drawn problems. o Top N Reports to present a list of elements that exceed / fall below a particular threshold value. This would help network operators to identify elements that share specific performance characteristics (for example, to identify over utilized elements, you would run a Top-N report for all elements whose bandwidth utilization exceeds 90% or availability falls below 95%). o What-If Reports to perform capacity planning by observing the effect of changes in capacity & demand (for example, the report should indicate what the bandwidth utilization would be if the demand was double the historical value). o Executive Summary Report that gives an overall view of a group of elements, showing volume and other important metrics for the technology being viewed. o Capacity Planning Report which provides a view of under-and-over-utilized elements. o Service Level Reports to analyze & display service level information for an enterprise, region, department or business process. This report must show the elements with the worst availability and worst response time-the two leading metrics used to monitor SLAs. o Health Reports to analyze trends calculate averages and evaluate the health of the infrastructure. With this information, operators should be able to determine how efficiently applications and systems are running, whether critical resources are available, and what capacity planning initiatives would make sense.  The system must provide capability to measure & generate detailed performance reports for the following common TCP/IP applications: o DHCP: Measure the round trip latency required to obtain an IP address. o DNS: Measure the DNS lookup time including Latency and Packet Loss. o FTP: Measure the time it takes to connect and transfer a file including Latency and Packet Loss. o ICMP Ping: Measure round trip source to destination including Latency and Packet Loss. o Latency and Packet Loss for : . POP3 . SMTP . TCP . UDP Echo Test  The proposed system should be able to auto-calculate resource utilization baselines for the entire managed systems and networks and allow user to set corresponding upper and lower threshold limits.  The tool should provide Latency (both one way and round trip times) report for critical devices and links.  The proposed system should use intelligent alarm de-duplication and automatic baselining capability to learn the behaviour of the managed infrastructure components over a period of time.

Flow-based Traffic Analysis System:

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 75 of 178

 The proposed traffic monitoring system must be able to track all flow of traffic on the network and identify malicious behaviour with all IP conversations.  The proposed system must use non-intrusive monitoring to reduce the impact on the monitored network and improve scalability.  The proposed system must provide details of applications, hosts, and conversations consuming WAN bandwidth to isolate and resolve problems.  The proposed system must provide eight-hour, daily, weekly, monthly, yearly, or customizable reporting time periods.  The bidder must provide a solution for collecting Flow data from multiple devices simultaneously across the network. The solution must provide the following Flow-based metrics: o Utilization o Flow Count o IP conversation pairs o Router/interface o Protocol breakdown by host, link, ToS or conversation. o IPv6 addresses  The proposed solution must be able to monitor and report on a minimum of 15000 unique protocols per day and display utilization data for each protocol individually. This capability must be available for each monitored interface uniquely.  The proposed solution must keep historical rate and protocol data for a minimum of 12 months (most recent) in its current long term operating database. All data in that database must have a maximum 15 minute window granularity.  The proposed solution must keep historical rate and protocol data for a minimum of 30 days (most recent) in its short term operating database. All data in that database must have a maximum 5 minute window granularity.  The system must support the ability to specify which hosts, conversations, IP ports, custom ToS matches and interfaces are included or excluded from the web based report.  The system must support the ability to create reports that allow the user to search all IP traffic over a specified historical period, for a variety of conditions. The system must have the ability to search all IP traffic without loss or exclusion of any traffic. The system must support search within this period for the following at minimum; o Search for any traffic using a specific configurable destination port, or port range. o Search for any traffic using a specific autonomous system (AS) number. o Search for any traffic using a specific IP subnet mask. o Search for any traffic using a specific IP ToS bit. o Search for any clients or servers communicating with more than a specific number of other unique clients or servers. o Search for any clients or servers that are experiencing more than a specified number of TCP resets per hour within a specified reporting period. o Search for any IPv4 or IPv6 conversation across the entire network. o Search for any protocol in use by a specific host, interface or list of hosts or interfaces.  The proposed system must be capable of automatically detecting anomalous behaviour

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 76 of 178 such as virus attacks or unauthorized application behaviour. The system should analyze all Flow traffic and alert via SNMP trap and syslog of any suspicious activity on the network.  Flow collection systems must support a minimum of 5 million flows per minute and be capable of storing gathered information in a common database where all long term reporting information is held.  The proposed system must spot potential bottlenecks with color-coded indicators for interfaces that breach defined thresholds and durations

5.11.7. Server Performance Monitoring:

 The proposed server performance management system shall integrate network performance management systems and provide the unified performance state view in a single console.  The current performance state of the entire network and server infrastructure shall be visible in an integrated console.  The proposed tool must provide lightweight server agents to ensure availability and performance for target server nodes and deliver scalable, real-time management of critical systems.  The proposed tool should be able to monitor various operating system parameters such as processors, memory, files, processes, file systems, etc. where applicable, using agents on the servers to be monitored.  It should be possible to configure the operating system monitoring agents to monitor based on user-defined thresholds for warning/critical states and escalate events to event console of enterprise management system.  The proposed tool should integrate with network performance management system and support operating system monitoring for various platforms including Windows, UNIX and Linux.  It should also be able to monitor various operating system parameters depending on the operating system being monitored yet offer a similar interface for viewing the agents and setting thresholds.  The proposed tool should be able to gather information about resources over a period of time and provide historical performance and usage information through graphical reports, which will quickly show performance trends.  The proposed solution should support management following parameters: o Processors: Each processor in the system should be monitored for CPU utilization. It should compare Current utilization against user specified warning and critical thresholds. o File Systems: Each file system should be monitored for the amount of file system space used, which should be compared to user-defined warning and critical thresholds. o Log Files: Logs should be monitored to detect faults in the operating system, the communication subsystem, and in applications. System agents should also analyze

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 77 of 178 log files residing on the host for specified string patterns. o System Processes: System agents should provide real-time collection of data from all system processes. Using this it should help identify whether or not an important process has stopped unexpectedly. It should provide an ability to automatically restart Critical processes. o Memory: System agents should monitor memory utilization and available swap space and should raise an alarm in event of threshold violation.

5.11.8. Database Performance Monitoring

 The proposed database performance management system shall integrate network and server performance management systems and provide the unified view of the performance state in a single console.  It should be able to automate monitoring, data collection and analysis of performance from single point.  It should also provide the ability to set thresholds and send notifications when an event occurs, enabling database administrators (DBAs) to quickly trace and resolve performance-related bottlenecks.  Database performance management solution for Distributed RDBMS must include hundreds of predefined scans for monitoring various database, operating system and network resources. This should minimize the need to write and maintain custom scripts. If a special monitoring situation exists, you can modify an existing script to meet your requirements.  The event management system must send alerts for an array of server conditions, including inadequate free space, runaway processes, high CPU utilization and inadequate swap space.  The database performance management solution must support historical archive store for performance information in a compressed time-series form. DBAs should be able to drill down through layers of data to discover the cause of a condition occurring with the databases, operating system or network. These historical reports must also be usable to perform trend analysis and capacity planning.  The database performance management solution must have a console to enable users to monitor, analyze and take corrective action from a centralized point. It should also include a platform-independent, browser-based console to monitor performance from remote locations.

5.11.9. Web-Application Performance Monitoring :

Application Performance Monitoring System:  The proposed solution must determine if the root cause of performance issues is inside the monitored application, in connected back-end systems or at the network layer from a

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 78 of 178 single console view.  The proposed solution must proactively monitor 100% of real user transactions, detect failed transactions, gather evidence necessary for triage and diagnosis of problems that affect user experiences and prevent completion of critical business processes.  The proposed solution must provide deeper end-to-end transaction visibility by monitoring at transactional level.  The proposed solution must provide a single view that shows entire end-to-end real user transaction and breaks down times spent within the application components, SQL statements, backend systems and external 3rd party systems.  The proposed solution must be able to provide root-cause probability graphs for performance problems showing the most probable root-cause area within application infrastructure.  The proposed solution must support any combination of operating platforms that support JDKs higher than 1.2 or Application Server (or .NET v1.1 and above) with a single methodology.  The proposed solution must provide a real-time application topology map to triage and quickly pinpoint the component causing a performance bottleneck in the end-to-end transaction flow.  The proposed solution must gather available performance indicator metrics from all within real-time production environments and real user transactions 24x7 with minimal overhead on monitored applications without sampling.  The proposed solution must provide for easy dynamic instrumentation of application code, i.e. be able to enhance out of the box monitoring with extra monitoring definitions without having to restart application or JVM.  The proposed solution must be able to detect production Memory Leaks from mishandled Java Collections and Sets and isolate exact component creating leaking Collection or Set (or .NET Memory Leaks within the CLR).  The proposed solution must allow monitoring granularity of no more than 15 seconds for all transactions.  The proposed solution must provide real-time monitoring of resource utilization like JVM memory usage, Servlets, EJB pools, DB connection pools and Threads.  The proposed solution must be able to identify socket and file Input / Output activity from the application.  As a means of detecting poorly performing SQL, the solution must be able to proactively record all SQL calls, and report on the slow performing ones.  The proposed solution must monitor performance of all stored procedures being executed from within the Java/.NET application.  The solution should have provision for automatic transaction discovery, for example by setting up some bounding parameters to describe transactions like the web site, the language, and parameters (such as post, query, and cookies).  The proposed solution must provide ability to monitor performance of applications up to the method level of execution (Java/.Net method) 24x7 in production environments with negligible impact on monitored application.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 79 of 178  The proposed solution must be able to report on any application errors occurred while executing application functionalities and pinpoint exact place of error within the transaction call stack.  The proposed solution must provide for at least 2 levels of thresholds which can be set on alerts and provide for actions so that alerts can automatically trigger other processes when thresholds are breached. The proposed solution must not necessitate any changes to application source code.  The proposed solution must proactively identify any thread usage problems within applications and identify stalled (stuck) threads.  The proposed solution should allow SQL statement normalization by aggregating hundreds of related SQL statements into a single performance metric using regular expressions and pattern matching.  The proposed solution must monitor individual web service and performance transaction debugging for web services. The proposed solution must also monitor web services across multiple processes (cross JVM tracing).

End-User Experience Management System:

 The proposed solution should measure the end users' experiences based on transactions.  The solution should be deployable as an appliance-based system acting as a passive listener on the network thus inducing zero overhead on the network and application layer.  The proposed system must be able to detect user impacting defects and anomalies and reports them in real-time: o Slow Response Time o Fast Response time o Low Throughput o Partial Response  The proposed system must be able to provide the ability to create user groups based on application criteria or location and link user ids to user names and user groups.  The proposed system must be able to provide user usage analysis and show how user's success rate, average time and transaction count has changed over a specific period of time such as current week versus previous week.  The proposed system must be able to provide the ability to detect and alert when users experience HTTP error codes such as 404 errors or errors coming from the web application.  The proposed system must be able to provide root-cause probability graphs for performance problems showing the most probable root-cause area within application infrastructure.

5.11.10. Helpdesk Management

 The proposed Helpdesk Management System must provide support for various defined

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 80 of 178 ITIL processes.  It must provide flexibility of logging, viewing, updating and closing incident manually via web interface. The web interface console would also offer power-users tips.  It must provide seamless integration to log incident automatically via system and network management.  It must provide classification to differentiate the incident via multiple levels/tiers of categorization, priority levels, severity levels and impact levels.  It must be able to provide flexibility of incident assignment based on the workload, category, location etc.  Each escalation policy must allow easy definition on multiple escalation levels and notification to different personnel via window GUI/console with no programming.  The escalation policy would allow flexibility of associating with different criteria like device/asset/system, category of incident, priority level, organization and contact.  It must provide web-based knowledge database to store useful history incident resolution.  It must contain built-in knowledge tools system that can provide grouping access on different security knowledge articles for different group of users.  It must integrate with EMS event management and support automatic problem registration, based on predefined policies.  It must be able to log and escalate user interactions and requests.  It must provide status of registered calls to end-users over email and through web.  It must have an updateable knowledge base for technical analysis and further help end- users to search solutions for previously solved issues.  It must have the ability to track work history of calls to facilitate troubleshooting.  It must support tracking of SLA (service level agreements) for call requests within the help desk through service types.  It must be capable of assigning call requests to technical staff manually as well as automatically based on predefined rules, and should support notification and escalation over email, web etc.  It must have an integrated CMDB for better configuration management & change management process.  It must have a top management dashboard for viewing the helpdesk KPI in graph & chart formats.  It must support remote management for end-user & allow analysts to do the desktop sharing for any system located anywhere, just connected to internet.

5.11.11. Detailed Specifications for IT Asset Management

 The proposed solution shall provide inventory of hardware and software applications on end- user desktops including information on processor, memory, operating system, mouse, key board of desktops etc. through agents installed on them.  It shall have reporting capabilities; provide predefined reports and the possibility to create customized reports on data in the inventory database.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 81 of 178  It shall provide facility for user defined templates to collect custom information from users at desktops / workstations.  It shall provide facility to recognize and provide inventory for custom applications on desktops.  It shall provide facility for queries and automated policies to be set up on existing data in database and permit scheduling of data collecting engines to pick up the data at defined intervals.  It shall support UNIX, Linux, Apple OSX apart from Windows environment for inventory management.  It shall provide file management capabilities for the monitored systems: it should be able to find out specific files and directories on a workstation based on queries.  It shall allow collection / restoration of configuration files at remote desktops, using which standardization of configuration can be achieved of all the desktops. e.g. configuration files / settings related to a particular application which involves changing of registry parameters and configuration files  It shall display the names of the applications being monitored for usage.  It shall support dynamic grouping for enabling assets to be grouped dynamically based on some pre-defined criterions. Like a Group can be able to display how many and which computers have a specific application installed. As and when a new computer get the new application installed it should dynamically get added to the group. Another Example: If a hardware upgrade is taking place, two Dynamic Groups can be created; one to reflect the computers not yet upgraded, the other group, the upgraded computers.  It shall be able to use the query tool to identify specific instances of concern like policy violation (presence of prohibited applications/games and old versions etc.), inventory changes (Memory change etc) and accordingly it could perform several actions as reply. These actions could be: o Sending an email o Sound an alarm o Adding the computer to a Group o Message to scroll on Monitor screen of the administrator

 It shall provide the facility to track changes by maintaining history of an asset. History period shall be configurable.  It shall provide a web-based console.  It shall be able to collect inventory from add/remove program functionality in Windows environment.  It shall support event policies such that pre-defined actions can be triggered when key events occur such as software license violations etc.  It shall provide an option to share the database with the proposed service desk solution such that it can leverage information available in Asset management database.  It shall support software Package Creation using Generic scripts. The software delivery software should provide a Wizard for auto script builder.  It shall support reinstall after crash for the systems which crashes and requires the same set of software after it has been serviced. It should identify such machines and would

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 82 of 178 automatically install the required software.  It shall have the intelligence to install a required set of software for any computers added in a particular department/group based on the predefined criteria.  It shall ensure that software deliveries run in the background ensuring that the end user cannot click any buttons or change settings.  It shall support software distribution to Dynamic groups. Administrators should have the ability to create distribution groups based on relevant criterion. Dynamic Groups to be built using search arguments presented to an asset and inventory management solution.  It shall support a wide variety of clients. This includes all desktop systems, including Windows Server and Desktop operating systems, various flavours of UNIX & Linux. It shall also provide inventory collection functionality from mobile operating platforms such as Windows Mobile etc.  It shall offer several levels of security for remote control, ranging from defining users with specific rights to requiring a specific IP address and local confirmation before a remote session is enabled.  It shall have the ability to perform diverse tasks on multiple remote systems simultaneously, view a host machine from multiple viewers, transfer control between users and allow a host machine to initiate a connection to a viewer.  It shall provide users the ability to record a session of remote control for later playback.  It shall provide chat functionality between remote control viewer and host as well as a file transfer utility for drag and drop transfer of files between remote control viewer and host.  It shall support remote reboot functionality  It shall provide the facility to throttle the bandwidth used by the tool while communicating over the network if required.  It shall provide the facility for encrypting the authentication traffic and additionally encrypt viewer/host traffic as well.  It shall support personalized global address book.  It shall support centralized session management.  It shall provide Windows integrated authentication as well as its own application based authentication option to choose from the agent installed.  It shall manage and preserve desktop software configuration, such as user settings, preferences and data so that it helps in seamless migration or upgrades to new OS such as Vista/Windows 7 etc.  It shall provide a web access console for a comprehensive view of asset management information, including : Computers, Software, Hardware details.  It shall provide support for ITIL support and integration with tools like service desk/helpdesk.  It shall collect and report information such as antivirus signature data and information on host based intrusion prevention system agents.  It shall provide Request Management functionality.  It shall provide Software Inventory features.

Log Record Collection and Management

 The system shall provide a graphical user interface/wizard to rules for normalizing custom log

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 83 of 178 sources or modifying existing integrations  The system shall provide automated update mechanism for Content (product integrations and reports). This process shall occur seamlessly and transparently without any customer intervention as part of the subscription update process.  The system shall support the following methods for log collection : o Windows Management Instrumentation (WMI) for remote collection from the Windows Event Log o Syslog o Raw Flow data o Text Log (flat file)  The system shall provide a mechanism to monitor the current status and relative health of the logging infrastructure.  The system shall have the capability to drag and drop building of custom queries & reports.  The system shall be capable of operating at a sustained 3000 EPS per collection device. The system shall provide the ability to scale to higher event rates by adding multiple collection devices.  The system shall have the capability for updates delivered and applied via an update service provided by the vendor to keep the system up-to-date. This includes the agents and it should be pushed centrally without having to reinstall the agents.  The system shall have a secure and preferably embedded log repository to store logs that does not require separate database expertise to administer and manage.

5.11.12. Enterprise Network Monitoring and Management Solution – Other Key Requirements

1. The Solution should provide all the modules to monitor Networks, Servers and Applications in the same appliance. 2. The proposed system should provide correlation between Network, Server and Application automatically. 3. The proposed system should provide Business Service Management functionality to track Service quality by logically grouping Network, Server and Application components. 4. The solution must provide way to define key performance indicators (KPIs) within the Business Service Management module. 5. The solution must provide SLA measurement module to track service quality from both Availability and Performance perspective. 6. The solution must provide pre-defined reports. 7. The solution must provide custom data widgets to create custom dashboards for the teams, so as to visualize and collect real time and historical data from custom widgets. 8. The solution must provide multi-tenancy. Eg. Database Admin should have access to Database monitors only.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 84 of 178 5.12. Enterprise Computing Security

Security technologies/solutions requirements for ITMS shall be required to protect the servers, data, storage, and operating system. The Enterprise Computing Security includes host anti- malware/virus, host IDS/IPS, data encryption (data in rest & data in motion), data access control, data backup, and data restore requirements. The following shall be the requirements of enterprise computing security:

5.12.1. Server security

The server security solution shall provide:

 Real-time monitoring of malicious attacks on the servers/end user machines  Automatic update and push of malware signatures  Configuration of different actions based on identified malware  Configuration of scheduled scanning jobs  Automatic reporting/alerting of machine status to centralized anti-malware solution in addition to local alerting feature  Centralized control/policy of functionalities so that end user cannot disable key functionalities of the host antimalware agent

5.12.2. Data security

The data security solutions shall restrict access of business data, and utilize data encryption and data backup. The solution shall:

 Restrict database administrators to view, modify and delete business data stored in the database.  Create log for all the database administrator activities.  Prohibit modifying or deleting system-created logs.  Encrypt data using international and industry standards, such as AES, SHA1, RSA, based on data sensitivity as agreed with SMC. Encryption support for data-at-rest and data-in-motion.  Support scheduled unattended backup using policy-based management for all server and OS platforms of the project (utilizing disk and tape media).  Support on-line backup and restoration of any running applications and databases.  Allow multiple back-up sessions simultaneously.  Support different types of backup such as full backup, incremental backup, differential backup, selective backup, point in time backup and progressive incremental backup and snapshot.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 85 of 178

5.12.3. Network Security

Security technologies/solutions shall be required at the network layer to secure the communications and exchange of data across the network LAN and WAN. The network security includes requirements for edge security, Authentication, Authorization and Accounting (AAA), and secure communication over virtual private network (VPN). The Service Provider can leverage the existing security services if sufficient. The following are the components of network security:

5.12.4. Edge security

The edge security solutions shall provide network access to the authorized user and identify, detect, and prevent any unauthorized access by implementing the following requirements:

Filter network traffic based on identifiers such internet protocol (IP address), port and protocol. Provide protection features against attacks such as denial of service (DoS), distributed denial of service (DDoS), (SYN) flood, transmission control protocol (TCP) flood, (UDP) flood and (SSL) based attacks. Provide protection against security exploits and threats. Monitor and analyse unusual or anomalous network behaviour. Provide mechanism for data and time synchronization with all the components such as network elements, operating system, and applications. Support redundant, fault-tolerant protection with state-full packet inspection capabilities (e.g. signature detection with automatic, scheduled updates of signature files). Support detection and prevention mechanisms such as protocol decode, anomaly detection, simple pattern matching, state-full pattern recognition. Support protection for Layers 3–7 of the Open System Interconnect (OSI) model. Define custom rule sets for packet analysis and filtering.

5.12.5. Communication Security

The communication security solutions shall:

 Provide secure connection to remote users by creating a VPN tunnel based on industry standards such as IPsec.  Provide network access to users only after authentication and authorization.  Create authentication and access logs.  Store private keys or digital certificates in a secure manner according to Federal Information Processing Standards (FIPS) Levels 2 and 3.  Provide AAA services based on industry standard protocols such as Remote Authentication Dial-in User Service (RADIUS) and Diameter.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 86 of 178  Provide internet security and be able to block or filter internet traffic based on the aspects such as content and URL.

Data centre The data centre shall be secured access control and operated by authorised personnel only. The data centre shall have adequate band width and established DMZ for WEB casting The data centre shall be capable of handling a minimum of 1000 transaction packets per second The data centre shall have fault tolerant UPS system powering all the equipments. (The service provider has to recommend if any changes are required). The data centre shall have back up power from a diesel generator set and same shall be provided by SMC. The data centre shall be protected from fire hazards by suitable fire extinguisher system. The data centre servers shall work on reliable / stable / multi tasking operating systems The data centre shall have reliable communication, processing and web hosting software packages for the transit management application Secure data centre facility shall be provided by SMC and Service provider shall be required to carry out all ITS related installation.

5.13. ITMS Computing, Network & Storage infrastructure Specification

5.13.1. Design Principals

The proposed solution architecture shall meet the following key design principles:

1. Shall be modular in design to accommodate a phased implementation. Once implemented, the systems must be able to easily expand to include new functions without requiring major reconfiguration or cause major impact.

2. Shall perform optimally and function without any degradation in the event of any single failure of any main component that will result in partial or total service disruption.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 87 of 178

3. Shall be highly available with no single point of failure with an aim to reach the target of 99.9% availability which allows for eight hours of unplanned outages per year.

4. Shall be scalable with no single component / bottleneck limiting the architecture to a maximum capacity.

5. Shall include high performance components thereby supporting performance requirements. 6. Shall be secure with multiple mechanisms protecting the architecture operating at different layers.

7. Shall utilize virtualization and blade server’s technology for space optimization of solution resource utilization efficiency. 8. Shall specify the method as well as the necessary measures the Service Provider shall make to ensure that the entire solution and its related components perform optimally.

5.13.2. Non-Functional Requirements

This section outlines the non-functional requirements that shall be strictly adhered to when implementing all the components within the scope of this RFP.

Service Providers are required to design the overall solution with high performance and scalability to handle the load from the newly introduced services. Service Providers are required to highlight how their proposed solutions meet the non-functional requirements provided in this section and that once project is awarded, the Service Provider must design the solution that meets or exceeds the non-functional requirements.

Scalability Requirements

The proposed solution architecture shall meet the following scalability requirements:

1. Shall support scalability both vertically (scale-up) and horizontally (scale-out) across architecture tiers.

2. Shall ensure well-balanced load distribution on the various hardware and software components to ensure that no congestion in any of the solution hardware components occurring with the growing load on environment.

3. Shall propose suitable multi-processor servers capable of handling the calculated loads. Multi-processing must be natively supported by the hardware serves and operating system to support scalability.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 88 of 178 4. Shall clearly specify upgrade path for the solution components (software and hardware) and how the overall solution can handle additional loads. It is required that the various components can be upgraded vertically (e.g. Processors and memory) and horizontally (e.g. servers to a cluster) to increase the solution capacity and ability to handle additional loads without degrading performance.

5. Shall clearly indicate the maximum upgrades that can be performed to increase the solution capacity vertically or horizontally.

Performance Requirements The proposed solution architecture shall meet the following performance requirements:

1. Shall deliver the project providing measurable and acceptable performance targets for various internal user groups, external transactions and connectivity bandwidths.

2. Shall conduct a formal sizing exercise to determine the required number of software and hardware components as well as their configuration. The sizing exercise shall be based on defining user profiles of the various applications and systems, and running simulation to determine the required hardware and software configurations.

3. Shall conduct a formal sizing exercise to determine bandwidth requirements for all connectivity (MPLS, internet, 3G/4G/LTE, etc.)

4. Shall provide an optimal and high performance solution satisfying response time for Internet and WAN connections.

5. Shall illustrate and justify how the software and hardware components can meet the performance requirements with average response time for expected number of users. 6. Shall benchmark the sizing exercise results and average response time with published statistics.

6. Shall ensure that frequent stress testing exercises to be performed on the testing hardware environment to confirm sizing results.

7. Shall be expected to conduct comprehensive stress testing of different solution functionalities and services as they are developed to ensure the implementation is headed towards the right direction and addressing key performance issues as early as possible (For instance Service Providers should not delay stress testing to the final stages of development/QA to avoid further delays to the project that might result in heavy code change).

8. Shall support around 500,000 registered users.

9. Shall support 5,000 concurrent users at peak hours.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 89 of 178

10. The solutions’ total number of internal users is expected to be 500 employees with 200 users using the system concurrently. Volume of transactions that need to be supported is based on the number of visitors to portal and is expected to exceed 50,000 visitors daily.

11. The total number of buses / vehicles that the system shall support is 4,000. Thus system shall be sized to support the real-time tracking and complex processing of notifications and data exchange.

12. Reporting information, stored logs / audit trails shall be stored for 3 – 5 years.

13. Shall support the expected annual growth of 20% for five (5) years.

Important Note: the information provided in this section is based on preliminary analysis. The Service Provider is required to assess and confirm the performance requirements during requirement gathering and detailed design phases.

5.13.3. Sizing Requirements

Planning for adequate capacity is crucial for SMC; this is driven by an expected capacity demand of 20% over 5 years, considering future projects / initiatives which shall demand additional processing power. The capacity is considered from two important aspects, available rack space and power supply capacity. As SMC is looking to leverage high density blade architecture server technology, the power demand per unit area of equipment room floor space in the existing data centre shall be taken into account by the Service Provider. The high density blade servers considered in the design as the preferred option for servers.

5.13.4. Enterprise Computing Architecture

The envisioned solution enterprise computing architecture shall be represented by three (3) tiers (web, application and database). The multi-tier architecture shall be designed with a production environment, along with development, testing, and staging environment. The Service Provider shall ensure that the environments adhere to the multi-tier architecture. It is preferable that all layers shall utilize virtualization technology;

The Service Providers shall be fully responsible for the design, procurement, installation, configuration, testing and commissioning of all hardware / software (production, development, testing and staging environments) in order to host the solution applications.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 90 of 178 5.13.5. Enterprise Computing Requirements

The Service Provider shall implement the below hardware/software as required and adhere to their requirements, but not limited to:

1. Hardware Requirements 2. Servers Requirements 3. Virtualization Requirements 4. Storage and Backup Requirements a. Unified Storage System b. Virtual Tape Library c. Backup Software d. Tape Library

Please note that this is not an exhaustive list, and Service Providers shall be responsible for identifying all components (hardware / software) required to implement the solution as per design architecture meeting SMC’s design principals, performance and scalability requirements.

5.13.6. Hardware Requirements

The Service Providers shall comply with the below hardware requirements.

1. All hardware components (e.g. servers, storage devices, network) must be redundant with no single point of failure. 2. All hardware shall have a clear and easy upgrade-path in support of the scalability requirements. 3. The storage use on any provided server / hardware shall not exceed 80% at any time. 4. The processor use on any provided server / hardware shall not exceed 80% at any time and the average processor use shall be below 60% during a period of 24 hours. 5. All servers shall have hot-swap capable disk and network components. 6. All SSL traffic must be offloaded from web servers to hardware based SSL accelerators with load balancing across back-end servers. SSL acceleration devices shall have linear scalability, fault tolerance and compatible with standards based server load balancing products. 7. All hardware servers shall be multi-processor, multi-threading capable severs, with native support for these features by the operating system. 8. All hardware severs shall enable clustering and load balancing as required. 9. All hardware servers shall be managed by direct and remote console access. 10. The total number of existing hardware servers along with all hardware servers and their installed software components shall satisfy SMC’s scalability, performance, availability and redundancy requirements.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 91 of 178 11. All hardware servers shall be capable of consolidating several applications / workloads in a minimum number of servers as appropriate. 12. All hardware components and equipment shall be based on latest models by the respective Service Providers to support the requirements. 13. The Service Provider shall explain purpose of all hardware components and products as well as specify the software product / components they run. 14. The Service Provider is required to specify manufacturer, model number, and complete specifications of all proposed hardware components. 15. The Service Provider shall specify virtual servers’ mappings of computing resources and application modules. 16. The virtual machine/server shall not exceed 80% utilization of the allocated hardware resources at any time of operations.

5.13.7. Servers Requirements

Service Providers shall provide servers solution in adherence to the below requirements:

1. Blade technology and virtualization concepts are key considerations in the deployment of solution servers supporting segregated development, testing, staging, and production environments.

2. Each blades chassis shall be equipped with high availability arrangements in order to respond to components specific failure (non-chassis failure cases) to maintain the service availability, such arrangements include, but not limited to: a. Blades chassis shall be supplied with dual and redundant management blades b. Blades chassis shall be supplied with switch blades that include two controllers c. Blades chassis shall be supplied with multiple power supplies that are connected to redundant power sources d. Blades chassis shall be supplied with redundant fans

3. Solution server blades shall be supplied with adequate LAN interface ports, these ports will be utilized to connect each server blade with the switching blade controllers via redundant Gigabit Ethernet links.

4. SMC required server blades shall be supplied with redundant fiber channel (FC) ports (not less than 8Gb) that are built-in the server blade or added through the deployment of I/O slots.

5. Each required server blade shall be connected to both the primary and the backup fiber/ether switches via redundant fiber channels/ether ports by utilizing the redundant ports/interfaces supplied with each server blade.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 92 of 178 6. The blades chassis shall be connected to both production primary and backup core switches using redundant 10Gb Ethernet links through the switching blades’ uplinks. In order to enhance the performance, availability and reliability of this LAN connectivity, aggregated links considering the ports located at both switching blade controllers are required to be configured to manage the connectivity between the solution switches and both core and backup switches. The Service Provider shall ensure the availability of 10Gb line cards on both core switches. If the line cards are not available, then the Service Provider shall be fully responsible for the upgrade.

7. The solution primary and backup chassis shall be implemented within a separate VLAN and configured in the core switches level to enhance the security and performance. This VLAN shall be scalable for the addition of any new system, service or application.

8. The solution servers virtualization shall be capable of deploying a combination of different modes including: a. One blade hosts one virtual server b. One blade hosts multiple virtual servers c. Multiple blades host one virtual server

9. The deployment of virtualization shall consider the deployment of a virtual centre of pooled and shared resources for a flexible, dynamic and efficient usage. The components of this centre shall include (but not limited to): Management server, database, repository, agents and clients.

10. Servers shall be mixed of physical and virtual servers supporting different services.

11. The virtualization management server shall be hosted on a physical server; this will be used to manage the solution servers deployed within the solution VLAN.

12. The solution virtualization shall provide the features related to the monitoring of shared resources like: a. Dynamic provisioning by creating a repository with master images b. Load balancing to ensure continuous network-based services c. Predefine QoS metrics for system performance d. Live migration option to be available to make sure that data is replicated on a real time in order to maintain high availability

13. Operating systems shall be supporting the virtualization scalability in terms of the number of possible configured virtual servers.

14. The virtual environment shall utilize virtual network appliances (e.g. virtual switches, firewalls, load balancers).

15. Server blades shall support the following minimum baseline technical specifications:

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 93 of 178 a. Support large number of external ports for creation of physical sub networks b. Support multiple Ethernet interfaces per server blade (1Gbps/10 Gbps) c. Support the connectivity through fibre channels with redundant interfaces d. Support two hot-plug hard disks per server blade in RAID 0 or 1 e. Support multiple processors f. Scalable for adding I/O slots including PCI, fibre channels and Ethernet ports

16. The solution blades chassis shall support the following minimum baseline technical specifications:

a. The solution blades chassis to include management, servers and switching blades b. Support redundant and hot-swap fans and power supplies c. Support the installation of redundant switch blades and/or Pass-Thru blades and management blades for highly flexible network integration and reliable management d. Support the installation of multiple hot-plug server blades per chassis that are supporting multiple processors. e. Support the virtualization, consolidation and load balancing features f. Support multiple processor server blades g. Support the deployment of redundant management blades to support hot-plug, master/slave role of management blade with web GUI interface for monitoring, managing and controlling of all components

17. The switch blades to support the following minimum baseline technical specifications: a. Have flexible connectivity through use of SFPs with RJ45 or LC connectors, also in mixed configurations. b. Support 802.1Q port-based tagged VLANs and 802.3ad trunking for links aggregation c. Support L2 switch functionality with multiple downlinks (to support connectivity with server blades) and uplinks connectivity (to support the connectivity with other network switches) d. Be SNMP manageable and support for TACACS+ and RADIUS integration e. Support failover protocols (e.g. VRRP, HSRP)

18. The secondary server blades shall be configured in a similar setup of the primary server blades within the production network in a way that guarantees smooth recovery in case of a disaster. The server blades shall be connected to the switches in the same approach that is followed in the production network.

19. The solution servers shall be flexible to be managed and monitored by different LAN network monitoring and analysis tools.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 94 of 178 20. Virtualization of hardware and software components including storage must be considered and shall be recommended to receive higher scores.

21. Shall have the ability to migrate a VM/container without downtime.

22. Shall have the ability to expand VM/container resources without downtime.

23. Shall support fault tolerance. 24. Shall have a unified console to manage all VMs/containers. 25. Shall have the ability to backup VMs/containers without downtime or performance impact.

5.13.8. Virtualization Requirements

The SERVICE PROVIDER shall ensure that the solution infrastructure shall be designed and implemented with consideration to virtualization. The virtualization solution to be implemented shall be responsible for resource pooling, dynamic allocation of virtual resources and attaching these virtual resources to the underlying specific physical resources and moving these virtual resources among the available physical resources. The Service Provider shall ensure that the virtualization solution shall offer the highest capacity utilization of the physical infrastructure and high availability and scalability to the services by using the above mentioned functionalities.

The solution shall also provide management functionalities and interfaces to manage the physical and virtual resources in terms of capacity demands, provisioning and scalability. The Service Provider shall ensure that virtualization technology will be the core operation model of the servers; all hardware resources shall be pooled into a unified resource pool and shall be assigned dynamically based on the ITMS applications’ requirements. However, if the system application performance cannot be met when virtualized; the SERVICE PROVIDER is allowed to configure some of the effected applications / servers in a non- virtualized environment. The Service Provider shall choose a mix of virtualized and non- virtualized servers (non-virtualized if absolutely necessary) in such a manner that the overall solution is highly scalable, reliable, optimized and redundant.

5.13.9. Network Infrastructure Requirements

Infrastructure for network management infrastructure shall include the below but not limited to:

1. Internet routers, firewalls, IPS/IDS and switches 2. DMZ switches 3. Core backbone switches 4. WAN connectivity infrastructure 5. Voice gateway

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 95 of 178 6. SMS gateway

5.13.10. Internet Routers

1. The routers must be modular to allow future expansion and scalability. 2. Support for multiple, high-speed WAN interfaces. 3. Provide scalable throughput and performance. 4. Support hardware CPU offload "services" cards for CPU load reduction. 5. Support integration with network management solutions for monitoring, management, and logging. 6. Support IPv4 and IPv6 standard internal and external routing protocols and WAN services, such as tunnelling and encryption, QoS, congestion management and bandwidth optimization, multicasting, and Protocol Independent Multicasting (PIM). 7. Support traffic filtering. 8. Support QoS mechanisms: queuing, scheduling, traffic shaping, signalling, and policing. 9. Support Network Address Translation (NAT). 10. Support for traffic statistics capturing features with the ability to customize and filter the captured streams (e.g. IP accounting). 11. Support Dynamic Host Configuration Protocol (DHCP) relay. 12. Support Tunnelling (GRE). 13. Support Border Gateway Protocol (BGP) and the needed BGP protocol extensions according to the detailed design and functional requirements.

5.13.11. Link Load Balancers

1. Form factor as an integrated service module within internet routers or as an independent appliance. 2. Provide internet link-load balancer with automatic failover of the internet links. 3. Support a minimum of 2 Gbps throughput. 4. Support active-active and active-standby redundancy. 5. Supports secure web-based management. 6. Support SNMP v1, 2, 3

5.13.12. Firewalls

1. Redundant, fault tolerant firewalls protection for layers 3–7 of the OSI model. 2. Support IPSEC and SSL VPN termination capabilities. 3. Provide scalable throughput and performance. 4. Support a minimum of one hundred thousand (150,000+) concurrent connections. 5. Support high-availability operational modes such as active-active and active-standby. 6. Support protection features against attacks such as, but not limited to DoS, DDoS, and exploit attacks. 7. Define custom rule sets for packet analysis and filtering.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 96 of 178 8. Support integration with network management solutions for monitoring, management, and logging in addition to robust authentication methods such as active directory, Lightweight Directory Access Protocol (LDAP), and Kerberos. 9. Support proactive and reactive protection mechanisms. 10. Enforce differentiated policies based on the user, device, role, application type, and threat profile

5.13.13. IPS/IDS

1. Form factor as an integrated service module within the firewalls, an independent appliance, or built-in service within the firewalls. 2. Redundant, fault tolerant protection with stateful packet inspection capabilities (signature detection with automatic or scheduled updates of signature files). 3. Provide scalable throughput and performance. 4. Support detection mechanisms such as protocol decode, anomaly detection, heuristics, simple pattern matching, and stateful pattern recognition. 5. Support protection features against attacks, including, but not limited to DoS, DDoS, SYN-flood, TCPflood, UDP-flood, reconnaissance, cross-site scripting, SQL injection, and exploit attacks. 6. Support the ability to prevent against encrypted data over SSL.

7. Support logging and auditing of different event types including, but not limited to: a. Any traffic breaching preset thresholds for traffic levels b. Any traffic identified with a recognized attach vector or pattern c. Attempts to initiate a DoS or DDoS attacks on the network d. Any suspicious traffic activities or patterns

8. Detect, classify, and block network-based threats via attack signatures associated with worms, viruses, and various application abuse scenarios on a per-connection basis.

5.13.14. DMZ Switches

1. Be capable of full duplex and auto-sensing. 2. Support redundant power supplies for high availability (N+1 mode). 3. Support logical and physical redundancy mechanisms. 4. Support for integrated service modules for integrated services. 5. Provide scalable throughput and performance. 6. Support multiple interface options such as 10 gigabit, gigabit, and fast Ethernet. 6. Support Standard L3 and L2 features. 7. Comply with the following standards a. IEEE 802.1X security standards. b. IEEE 802.1W/S for RST and MST protocols. c. IEEE 802.1P and 802.1Q for QoS and VLANs-trunking

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 97 of 178 d. IEEE 802.3ad/802.1ax for link aggregation

5.13.15. Servers Load Balancers

1. Form factor as an independent appliances, modular design with individual network & security capabilities, and scalable. 2. Provide Layers 4–7 load balancing and traffic segregation capabilities to support the web servers and appliances. 3. Redundant and high availability features while providing web servers’ availability through load balancing and health monitoring of the environments. 4. Ensure scalability of web servers’ load balancing, health monitoring, and session persistence policies. 5. Support for reverse proxy and hardware based SSL offloading functionality, caching mechanisms, compression, optimization techniques, support for application security, thereby providing additional layer of security. 6. Support security services including Access Control Lists (ACLs) and transport encryption, such as SSL and Transport Layer Security (TLS) between virtual contexts, client population, and associated server farms. 7. Able to support load balancing across geographically distributed server farms. 8. Support for multi-core processing 9. Shall provide for deep packet inspection for specific traffic flows 10. Provide centralized management for all modules 11. Include scalable high performance and throughput capabilities. 12. Include virtualization capabilities such as multiple device contexts to support the cloud multi-tenant architecture. 13. Ensure scalability of application load balancing, health monitoring, and session persistence policies within each virtual partition.

5.13.16. WAN Routers

1. Shall be modular to allow future expansion and scalability 2. Hardware CPU offload “services” cards should be available for CPU load reduction 3. Shall support for multiple high speed WAN interfaces as well as a minimum of 4 LAN interfaces 4. Shall provide scalable throughput and performance 5. Shall support for voice, video and data services 6. Shall support hardware data compression and encryption options 7. Shall support physical redundancy through hot swappable components as well as logical redundancy through standard first hop routing protocols and gateway load balancing protocols

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 98 of 178 8. Shall support IPv4 and IPv6 standard internal and external routing protocols and WAN services such as virtual routing and forwarding (VRF), multiprotocol border gateway routing protocol extensions (MPBGP), multiprotocol label switching (MPLS) and multiprotocol label switching virtual private networks (MPLS VPNs), tunnelling and encryption, quality of service (QoS), congestion management and bandwidth optimization, multicasting and protocol independent multicasting (PIM) 9. Shall support for integration with network management solutions for monitoring, management, and logging 10. Shall support control plane protection features (CPP)

5.13.17. L2/L3 Switches

1. Offer basic OSI layer 2 or 3 functionality in a managed configuration. 2. Shall support redundant power supplies, operating in an N+1 mode. 3. Support for integrated service modules for integrated services. 4. Shall support hot-swap capability of all major components. 5. Shall support interchangeable interface cards including copper and fibre connectivity. 6. Shall support 1Gbps ports supporting 802.3z and 802.3ab with interchangeable modules. 7. Shall support 10 Gbps ports supporting 802.3ae and 802.3ak with interchangeable modules. 8. Shall support 1000Base-T, 1000Base-LX, and 1000Base-SX. 9. Shall support dynamic VLAN assignment. 10. Shall support standard AAA control protocols and RADIUS authentication. 11. Shall support dynamic trunk configuration across all switch ports. 12. Shall support multicasting. 12. Shall comply with 802.1q Trunking standard. 13. Shall support port aggregation. 14. Shall support IGMP v3 Snooping for IPv4 and IPv6 MLD v1 and v2 Snooping. 15. Shall support IGMP filtering. 16. Shall comply with IEEE 802.1x standards

5.13.18. Application Servers Load Balancers

1. Form factor as integrated service modules within the L2 / L3 switches or as an independent appliances. 2. Include scalable high performance and throughput capabilities. 3. Provide Layers 4–7 load balancing and traffic segregation capabilities to support the server farm servers and appliances. 4. Include virtualization capabilities such as multiple device contexts to support the cloud multi-tenant architecture. 5. Redundant and high availability features while providing server farm availability through load balancing and health monitoring of the environments.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 99 of 178 6. Ensure scalability of application load balancing, health monitoring, and session persistence policies within each virtual partition. 7. Support for caching mechanisms, compression, optimization techniques, support for application security, and thereby providing additional layer of security. 8. Support security services including Access Control Lists (ACLs) and transport encryption, such as SSL and Transport Layer Security (TLS) between virtual contexts, client population, and associated server farms. 9. Support for multi-core processing 10. Shall provide for deep packet inspection for specific traffic flows 11. Provide centralized management for all modules

5.13.19. Server Farm Switches

1. Form factor as an integrated switch module within the server blade chassis 2. Be capable of full duplex and auto-sensing. 3. Support redundant power supplies for high availability. 4. Support logical and physical redundancy mechanisms. 5. Be in non-blocking mode supporting physical and virtual servers. 6. Provide scalable throughput and performance with low latency fast packet switching. 7. Support for converged switching technologies, including, but not limited to Unified Fabric, Qfabric, and VCS. 8. Support Fiber Channel over IP/Ethernet. 9. Support multiple interface speed options on the same interface (10gigabit/1gigabit). 10. Support multicast features. 11. Support security features, such as DHCP snooping, dynamic Address Resolution Protocol (ARP) inspection and IP source guard. 12. Support private VLAN configuration. 13. Support VoIP technology features, such as voice VLANs and QoS configuration. 14. Standard L3 and L2 features. 15. Shall comply with: a. IEEE 802.1X security standards b. IEEE 802.1W/S for RST and MST protocols c. IEEE 802.1P and 802.1Q for QoS d. VLAN, IEEE 802.3ad/802.1ax for link aggregation

16. Support control plane protection (CPP) features such as control plane policing and rate limiting.

Other Equipment as required Service Providers shall be fully responsible for identifying all required network equipment requirements for a fully operational and optimized ITMS infrastructure.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 100 of 178 5.13.20. Wide Area Network (WAN)

The connectivity of data centre with other entities such as government entities, vehicles, and for other business needs need to be considered and adequate capacities shall be planned with provisions to meet demand spikes for bandwidth. The Service Provider shall be responsible for connecting all locations and entities. The Service Provider shall be fully responsible for the connectivity’s equipment including customer premise equipment, firewalls, switches, rack cabinets to ensure a seamless connectivity between the selected locations and SMC.

5.13.21. Storage and Backup Requirements

The service provider shall implement the following storage and backup system to support ITMS solution requirements.

5.13.21.1. Unified storage system

1. Service provider shall be responsible for meeting or exceeding the following unified storage system requirements:

2. The solution shall be supported with the implementation of its own unified storage system to host all solution applications, databases and transactions related to different servers. The capacity of the unified storage shall be calculated based on the Service Providers sizing exercise to accommodate the solution current and future data and backup requirements.

3. The system shall support SAN, NAS, and Scale-out-NAS, via IP-based and/or FC- based.

4. The system shall support the following minimum baseline technical specifications: a. Pre-configured with Fabric operating software and web based management tools b. Support storage expansion shelves (Fibre Channel, SATA, NL-SAS, SSD) c. Supplied with direct fabric attached server operating system d. Support high availability features and dynamic path rerouting in the event of a link failure e. Equipped with hot pluggable and redundant power supplies 5. Ability to support replication of data remotely to the DR site using latest technologies and protocols 6. Capable of providing data replication between remote sites ensuring business continuity preventing any data loss, data corruption, or impact to the end-users whilst using latest technologies and protocols.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 101 of 178

7. The system shall have been in production from OEM for at least 6 months and shall be supported locally.

8. The system shall have minimum of fifteen (15) Terabytes (TB) of usable space on disk arrays. However, the Service Provider is required to verify the size of usable disk space specified here to ensure that enough disk space is available for data storage, to meet the requirements of the applications as detailed in this RFP, also taking into consideration future annual growth of 20% for 5 years.

9. The system shall be used for storing user, systems, and applications data. The system shall interface with all server platforms and OSs as part of the solution.

10. The system shall be an enterprise-class, modular (including controllers and HDD modules), unified storage system, with built-in virtualization, providing high performance, scalability, reliability, availability, and fault tolerance.

11. The system shall have no single point of failure. It shall support non-disruptive component replacement and hot-replacement of interfaces, disk controllers, disk drives, cache memory cards, micro-code, power supplies, battery systems, fan subsystems, FC/IP controllers, and ports.

12. The unified storage disk array shall be connected to both primary and backup fibre/ether switches through redundant ports. The unified storage disk array shall be equipped with redundant controllers and fibre/ether switches.

13. LUNs shall be configured for each service. HDD assigned to each LUN shall formulate a RAID 6 that includes HDD from different shelves to enhance the solution availability. Service Providers are to suggest the leading design for storage RAID configuration taking into consideration the reliability, availability and speed of the solution.

14. The system shall support automated storage tiering and movement of data within different tiers including SATA, NL-SAS and SSD disks without requiring user intervention.

15. The system shall be optimized for multiple virtualization platforms such as VMware and Hyper-V and similar technologies. 16. The system shall support data encryption.

17. The system shall ensure appropriate number of controllers, hard drives, software, peripheral devices, and cables necessary to provide a fully optimised, functional and operational system to support the requirements of all solution applications.

18. Redundant array controllers shall be provided for load balancing and failover.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 102 of 178

19. The system shall support minimum hardware-based, RAID 5, RAID 6 and RAID 10. Mix and match of disks types and RAID levels shall be supported on the same storage subsystem.

20. The hard disk size and type shall be chosen by the Service Provider to achieve a minimum footprint of the storage rack units, while taking into consideration performance requirements of the solution.

21. The system shall be capable of providing 1 GbE, 10 GbE, iSCSI, Fiber Channel IP, and 10 Gb FCoE connectivity, and must support latest future high speed connectivity.

22. The system shall support self-monitoring, self-diagnosing and self-repairing features.

23. The system shall support cache data protection mechanisms in the event of a power failure.

24. The system shall be configured with GUI-based storage management system. A single command console shall be used for the entire storage system for all functionalities such as storage configuration and management, performance monitoring and reporting, performance data analysis, report generation and customization.

5.13.21.2. Virtual tape library

Service Providers shall be responsible for meeting or exceeding the following VTL system requirements:

1. The Service Provider shall design the VTL in order to achieve low cost per terabyte (TB), while meeting all performance parameters.

2. The system shall have capacity of 30TB usable data. The proposed system shall also meet the future growth requirements. The Service Provider is required to verify the size of usable disk space specified here to ensure that enough disk space is available for data backup, to meet the requirements of the applications as detailed in this RFP and backup policy, also taking into consideration future annual growth of 20% for 5 years.

3. The system shall be used for storing user, systems, and applications data. The system shall interface with all server platforms and OSs as part of the solution.

4. Redundant array controllers shall be provided for load balancing and failover.

5. VTL system to support the following minimum baseline technical specifications: a. Integration with different backup management utilities and applications

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 103 of 178 b. Ability to support disaster recover (DR) / remote site replication and expiration of backup copies c. Supports features of bandwidth optimization required to achieve bandwidth consumption reduction d. Modular storage architecture and scalable for storage expansion e. Supports integrated high availability with backup management utility server f. Supports as minimum the following protocols: NFS v3/v4 over TCP, pNFS, CIFS, NDMP v2/v3/v4, tape library, emulation (VTL) over Fibre Channel g. Supports management through GUI, SNMP and command line management interface h. Supports the configuration of QoS settings i. Allows configuration of an unlimited number of virtual tape cartridges j. Supports the configuration of capacity on demand and tape capacity settings k. Supports multi-site tape consolidation

5.13.21.3. Backup software

1. Service Providers shall be responsible for meeting or exceeding the following backup system requirements:

2. The solution shall be supported with a backup utility that is required to be implemented on redundant server blades. Each server blade installed at both primary and backup blades chassis shall be connected to both primary and backup fibre/ether switches through redundant links.

3. The backup management utility shall be supplied with the required agent licenses in alignment with ITMS solution used databases and operating systems, SAN and LAN based backups. Additionally, the utility shall support backup solution functionalities.

4. The backup shall support backup of virtual servers.

5. The software shall support scheduled automated backup using policy-based management for all server and OS platforms of the solution environment.

6. The software shall support online backup and restore of any running solution applications and databases. 7. The backup software shall be capable of having multiple backup sessions simultaneously.

8. The backup software shall support different types of backup such as full backup, incremental backup, differential backup, selective backup, point in time backup and progressive incremental backup, and snapshot.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 104 of 178 9. The backup software shall support different types of user interfaces (e.g. GUI, web- based interface). Tape library

10. Service Providers shall be responsible for meeting or exceeding the following tape library system requirements:

11. The tapes library shall support the following minimum baseline technical specifications: a. Include multiple tape drives b. Contain LTO based tape media slots (support LTO-6 with 8 Gbps interface) c. Scalability for future expansion d. Include a robotic system for the handling of media e. Include built-in component level diagnostic capabilities and provide alerting capabilities via SNMP f. The tape library shall be directly supported by different backup software packages g. An internal fibre channel shall be included for direct SAN fabric connectivity

12. The system shall meet current and future growth requirements.

13. The Service Provider shall provide enough tape media to ensure that enough is available for data backup, to meet the requirements as detailed in this RFP and backup policy, also taking into consideration future annual growth of 20% for 5 years

14. The system shall back up all critical information of the solution from all applications for long term archival purposes.

15. The Service Provider shall be responsible for developing a solution backup and recovery policy, and applying the policy to the backup system.

5.13.22. ITMS Compute Infrastructure Architecture

It envisioned that the solution architecture shall be represented by two (2) major segments, enterprise computing and network infrastructure. The enterprise computing segment shall have three (3) main components, servers, storage and backup. Additionally, the network infrastructure shall have two (2) main components, Local Area Network (LAN) and Wide Area Network (WAN). All of the components of which shall be hosted in the SMC data centre.

Some of the equipment to be supplied as part of solution but not limited to:

 Internet Routers  Link Load Balancers  WAN MPLS Routers (including MPLS connectivity)  Firewalls  IPS / IDS

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 105 of 178  DMZ Switches  DMZ Load Balancers  L2/L3 Switches  FC/Ethernet Switches – for server farms  Enterprise Computing Infrastructure

The proposed solution shall meet the following general requirements:

1. The Service Provider shall provide detailed specification of all hardware, software and infrastructure components needed to deliver and operate the solution.

2. The Service Provider shall design, procure, deliver, install, configure, test, deploy and commission the required servers, storage, backup, network, security components, and any other additional equipment.

3. The solution shall include all hardware equipment necessary to host and manage all software components, products, and applications as part of the scope of this RFP.

4. The Service Provider shall assess, review, analyze and confirm hardware & software architecture, design and the setup needed to meet the project requirements as stated in this RFP.

5. The Service Provider shall design a secure, reliable, scalable, and a resilient solution infrastructure that shall interface with other systems as required.

6. The Service Provider shall use a layered-approach model to design the solution infrastructure architecture in order to allow for modularity and ease of deployment, management, and elimination of any bottlenecks in any of the layers.

7. The solution infrastructure equipment shall be currently in production and shall have been present on the market for at least six (6) months. SMC will not accept any OEM equipment that is planned to cease production within one (1) year.

8. The design to be developed shall give clear view of the individual infrastructure components and shall also show the overall integrated solution infrastructure.

9. The proposed infrastructure shall support VPN connections to guarantee secure, remote access, end-to-end communication for remote staff.

10. The Service Provider shall design the solution IT infrastructure architecture taking into consideration the design principals and the non-functional requirements listed in this RFP.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 106 of 178 11. Ensure that the infrastructure has the latest stable software release with the manufacturer’s recommended fixes and patches at the time of installation. 12. Arranging any necessary installation equipment and tools required for the installation of the system.

13. The Service Provider shall apply and adhere to the defined security requirements listed in this RFP.

14. The Service Provider shall ensure that all network components deployed are hardened.

15. The network security solution shall incorporate the use of security domains/zones, such as DMZs and VLANs, to segregate systems with specific security requirements or different levels of trust.

16. The Service Provider shall ensure the enterprise computing and network is configured to provide audit trails including, at a minimum, source of origin and destination, timestamp, status, and protocols.

17. The Service Provider shall ensure that all internet access and WAN access to the data center is firewalled. The firewalls shall be able to prevent external and internal intruders from bypassing VLAN segments.

18. Ensure that all the components and subcomponents are in compliance with the requirements indicated in this RFP.

19. The requirements provided in this document are the minimum; thus, the Service Provider shall propose equal or better components as required to ensure that the IT Infrastructure performs optimally.

20. The Service Provider shall bear all costs until commissioning of the entire solution.

5.13.23. Data Centre Safety and Security

5.13.23.1. FM 200

Sr. No. Description

1 Required Cylinder with Valve 2 FM200 3 Standard Primary Complete Kit complete with Solenoid & Gauge Assembly, Discharge Tube, Manual Pneumatic Actuator, Flex Hoses, Warning Sign, Name plate and Connectors.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 107 of 178 4 Nozzles 5 Supply with laying of the M.S. Seamless pipes as per ASTM

6 Cylinder Rack 7 Manual Abort Station 8 Manual Release Station 9 Hand held fire extinguisher, Type ABC 10 Integration of fire alarm with FM200 gas release panel

11 Installation, testing & documentation

5.13.23.2. Rodent Repellent System

Sr. No. Description 1 Supply of 2c Cu cable in the PVC pile 2 Laying of the 2 Cu cable in the PVC pipe 3 Supply and fixing of 2 pair 1 sq mm copper wire along with 20MM PVC conduit.

4 Supply and fixing of VHFO Model Master Console along with the indicators. The rate shall be inclusive of termination, testing and commissioning of the system.

5 Supply and fixing of satellites above false ceiling, below ceiling and below false flooring. 6 MS Stand for fixing the maser console unit. 7 Installation, testing & documentation

5.13.23.3. Water Leakage Detection

Sr. No. Description

1 4 Zone Hybrid Control Panel with with Power supply. 2 Water leak detection module

3 Length water leak detection cable 4 Hooter - Electronic Sounder 85db 5 2C, 1.5 Sq. Un-armoured Cable 6 25mm PVC Conduits with accessories

7 Laying of the cable in PVC pipe

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 108 of 178 8 Installation, testing and commissioning of WLD System

5.13.23.4. Fire Alarm System

Sr. NO. Description

1 Single Zone Fire alarm Panel 2 Conventional Optical Smoke detector with Base 3 Conventional Optical Smoke detector with Base (Above false ceiling) 4 Response indicator 5 Conventional Hooter with Power supply 6 Conventional Manual Call point 7 Supply & laying of 2C, 1.5 Sq.mm FRLS Un-armoured Cable

8 Supply & laying 25mm PVC Conduits for Laying of Cable 9 Laying of cable in PVC Conduits 10 Installation testing and commissioning of Fire alarm system

5.13.23.5. Access Control System

Sr. No Description 1 Stand-alone controller with Reader Fingered Print 2 Software for Access control 3 Single door Lock with mounting bracket 4 Power supply for door lock 5 Exit Switch with required accessories 6 6C, 1Sq.mm Unarmored Cable 7 25mm PVC Conduits with accessories 8 Laying of Cable in conduits

9 Installation, testing and commissioning of access control system

5.13.23.6. Close Circuit TV System

Sr. No Description UL Listed Color Dome camera with fixed lens of 3mm,1/4" CCD color, IP based a camera should be provide.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 109 of 178 Resolution : 470 TVL, PAL Power supply : 12/24V, including power supply & all accessories require for mounting Backlight compensation feature

Sr. No Description

a Supply of RG 6 Video shielded, PVC sheathed, Copper cable

b Supply of 3 Core X 1.5 sq mm core power FRLS cable

Supply, installation, testing, commissioning & documentation with 1 year warranty of c product

d Any other accessories as required for system

5.13.24. Handheld Ticketing Terminal for City Bus Ticketing

HTT SPECIFICATION Sr. Parameters Minimum Required Specification No 1 Processor 400 MHz, ARM 9 or higher 2 Memory 128 MB Flash, 64 MB RAM 3 External Memory Micro SD card 4 Display 3.5 Inch, 320X240 Color TFT Touch Screen Magnetic Card Triple Track, Bi-Directional 5 reader 6 Card slots Minimum 2 SAM Slots Smart card Contact Smartcard reader 7 reader Contactless card ISO 14443 A/B, Mifare Family (Classic, Desfire, etc), Felica etc. 8 reader contactless smartcard reader 9 Printer Thermal Printer 57mm, 18 lines per second 10 Keypad Minimum 15 keys 11 Battery Li-ion batteries, 1800 mAH or higher 12 Communication GPRS 14 Peripheral ports USB OTG RS232 15 Security DES, 3DES, AES, DUKPT Environmental 0°C to 50°C (32°F to 122°F) operating temperature, 16 5% to 95% relative humidity non condensing 17 Voltage Input: 100~240VAC, 50Hz / 60Hz, 1.0A, Output: 9VDC, 2.5A

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 110 of 178 Certification EMV Certified Level 1 & 2 18

Operating Linux / Windows/ Android (4.2 or above) 19 System Accessories Shoulder bag, AC Charger, Memory Card – 2GB, Extra Battery

Administration Remote Administration, OTA for firmware, Application and

Configuration Support Database handling API, Embedded TCP/IP Stack, Parallel

Programming Support Communication USB & RS232 – 1 Each

Ports

5.13.25. Barcode based Ticket validator or Flap Barriers

The barcode base ticketing shall be made available for dispensing as a travel credential on BRTS and City bus HTT and same shall be allowed to be validated on BRT as well as city bus system. The tickets issues and validated by the ticketing devices should be based on secure codes and the service provider shall ensure the serial keys used for ticketing are not replicable by unauthorized users. The specifications of the barcode reader shall be as given below:

Barcode Based Ticket Validator for BRT Stations

 CCD Barcode reader 1D / bi-dimensional 2D  Ticket branding printing  200 dpi thermal printing head  200 m/sec printing speed  From 80 to 350gr/m2 paper thickness  Heavy-duty applications  24 Volt power supply  MTBF up to 360000 hours  USB/RS232 interfaces & USB 1.1 and above

Barcode based ticket validation and printing for handheld terminals

 CCD Barcode reader 1D / bi-dimensional 2D  Ticket branding printing  and quality as may be required Read QR  code printed on paper  Read digital QR code from mobile

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 111 of 178  Read Distance upto 4 cm from platen  Image Sensor 640 x 480 pixels min.  Scan Window 35mm x 50mm min.  10 mil resolution  White LED light source  Ambient Light 0 - 100,000 LUX

5.13.26. UPS for BRTS Bus Station

Online UPS 2 KVA-4 Hours backup Sr. No. Description Minimum Required Specification 1 Rating (in KVA) 2 KVA [ A ] Input 1 Nominal Voltage 230 V AC 2 Nominal Frequency 50 Hz 3 Input Power Factor >0.95 4 Input Voltage Range 165 ~ 275 VAC 5 Frequency Range 45 to 55 Hz [ B ] Output 1 Invertor Design IGBT Based Technology 2 Voltage 220 V / 230V / 240 VAC 3 Voltage Regulation 1% to 2% 4 Waveform Pure Sine wave

5 Total Harmonic Distortion < 3% for linear load

6 Crest Factor 3 :1 [ C ] Environmental 1 Operational Temperature 0 to 40 Deg. 2 Relative Humidity 20 ~ 90% (Non Condensing) [ D ] Physical 1 Enclosure Protection IP 20 2 Cooling Forced Air Cooling [ E ] Bypass 1 Static Bypass Auto & Manual 2 Transfer No Break [ F ] Battery 1 Type Sealed Maintenance Free 2 DC Voltage 36 V 3 Recharge Time 8-10 hrs 4 VAH Required 3600 VAH

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 112 of 178 5 Battery Backup 4 hours 6 Battery make Exide / Quanta / Rocket [ G ] General Overall Efficiency on Full 1 > 87% load 2 Acoustic Noise (in dbA) < 50 dBA @ 1 Meter Audible Alarm required for Mains Failure, Low Battery, 3 Alarms Over Load LCD Display with Measurements (Input / 4 Display Panel Output/Frequency, Battery Voltage) [ H ] Communications 1 Connection type USB 2 SNMP Interface Intelligent slot for SNMP / AS400/ Modbus

5.13.27. UPS for Central Control Centre

Online UPS 6 KVA-1 Hours backup for Data Center Sr. No. Description Minimum Required Specification 1 Rating (in KVA) 6 KVA / 5400W [ A ] Input 1 Nominal Voltage 230 V AC 2 Nominal Frequency 50 Hz 3 Input Power Factor >0.95 4 Input Voltage Range 165 ~ 275 VAC 5 Frequency Range 45 to 55 Hz [ B ] Output 1 Voltage 220 V / 230V / 240 VAC 2 Voltage Regulation 1% to 2% 3 Waveform Pure Sine wave

4 Total Harmonic Distortion < 3% for linear load

5 Crest Factor 3 :1 [ C ] Environmental 1 Operational Temperature 0 to 40 Deg. 2 Relative Humidity 20 ~ 90% (Non Condensing) [ D ] Physical 1 Enclosure Protection Dust Resistant [ E ] Battery 1 Type Sealed Maintenance Free

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 113 of 178 2 DC Voltage 12 V 3 VAH Required 312 VAH 4 Battery Backup 1 hours 5 Battery make Exide / Quanta / Rocket [ F ] General 1 Acoustic Noise (in dbA) < 50 dBA @ 1 Meter LCD Display with Measurements (Input / 2 Display Panel Output/Frequency, Battery Voltage) [ G ] Communications 1 Connection type USB 2 SNMP Interface Intelligent slot for SNMP / AS400/ Modbus

5.13.28. Point of Sale system for BRTS stations

POS System- Minimum Required Specification

Sr Description Minimum Required Specification No

1 Processor Intel Atom / Dual Core & Above

2 Processor Speed 1.6 GHz and above

3 Cache Memory 1 MB

4 RAM 1 GB RAM

5 Nos. of Slots 4

6 HDD 160 GB HDD

7 USB Port 4 USB Ports

8 Serial Port 2 x RS232 Ports

9 Parallel Port 1 x Parallel Port

10 Monitor (Size) 15" TFT LCD - Touch

11 Operating System Linux / Windows / Android 4.2 and above with required OS and licenses

12 Thermal Printer 3” Width, Auto Cutter

13 Accessories Cash Till/Cash Vault

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 114 of 178 14 Customer Display LCD Based Customer Display

15 Smartcard Reader Contactless Card Reader ISO 14443 A/B, MiFare family (classic, Ultralight ‘c’ DesFire, etc.). contactless smartcard reader

5.13.29. Station Server Specification

The service provider shall determine the actual require and according decide on the specifications, However industrial design is a must to comply with harsh conditions.

CPU Dual core or Above

Frequency 1.66 GHz & above

Processor Core Number 2

L2 Cache 1 MB

BIOS AMI EFI 16Mbit

Technology DDR2 667MHz

Memory Capacity 2 GB

Socket 1 x 200-pin SODIMM

Slot Type 1

Expansion Mini PCI 1

MIOe 1

Controller Support wake on LAN.

Ethernet Speed 10/ 100/ 1000 Mbps

Connector RJ45 x 3

Audio Interface HD Audio Audio Connector 1 (Line-in, Line out, Mic-in)

Watchdog Watch Dog Timer Yes Timer

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 115 of 178 SATA 1 x SATA II Storage CompactFlash 1

USB2.0 6

I/O GPIO 8 6 (1 x RS232, 3 x RS232/ 422/ 485, 2 COM Port x RS-422/ 485)

Power Type ATX, AT

Power Supply Voltage Vin: 12-24V

Connector 2-pin Power Power Consumption (Idle) 12.62W

Power Consumption (Full Load) 15.87W

Power Adaptor Optional

-40~ 85° C and 40° C @ 95% RH Non- Environment Non-Operational Temperature Condensing

Dimension (mm) 264.5 x 133.0 x 69.2 mm

Weight 2 kg (4.4 lb) Physical Construction Aluminum / Iron

Mounting Desk/ Wall/ VESA/ DIN-Rail mounting

Microsoft Windows Yes Operating System Linux Yes SUSI Access Yes

EMC CE, FCC, CCC, BSMI, KC Certification Safety Certifications UL, CCC, BSMI, KC

5.13.30. Specifications for LED based Video Wall Module

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 116 of 178 Specification Item Description LCD Video wall of (Columns) x(Rows)of Super narrow Configuration Bezel LCD panels of 55" Resolution 1920 x 1080 Pixel Pitch 0.53 mm Light Source LED Contrast Ratio 4000:1 Color Capability 1.07 Billion Response Time 8 ms Viewing Angle H : 178°, V : 178° Scan Rate H: 30~75kHz, V: 50~85Hz NTSC, PAL, SECAM Video 480i, 480p, 720p, 1080i, 1080p, 1x Digital DVI-I ; 1x Digital DVI-D ; 1x CVBS BNC ; 1x Standard Inputs Component Video BNC ; 1x 5BNC (RGBHV or YPbPr) Standard Outputs 1x Digital DVI-D ; 1x CVBS BNC Control RS-232/RS-422/IR Input Voltage AC 90~240V@50/60 Hz Power Consumption < 160W Standby Mode < 2W at 110V Temperature 0°C - 35°C (32°F - 95°F) Humidity 10% - 90%, non-condensing Operating Life > 50,000 hours Maintenance Feature Quick Swap Modules Combined Bezel (Typical) 5.7 mm Video Wall Tiling 20 X 15 Controller to control Display module in a matrix of 2 ( C) x 2 Display controller ( R) with 4 outputs, DUAL LAN input & 8 DVI inputs along with necessary software’s Single Quad Core Intel® Xeon 64-bit 2.0 GHz CPU or Processor latest Ram 8 GB minimum Min 500 GB Hard Disk HDD Hard disk Capacity should be upgradable Dual-port Gigabit Ethernet Controller inbuilt Networking Support for Add on Network adapters Support for Optical Fiber interface Adapters Accessories DVD-R,DVD+RW,, Keyboard, mouse OS Support 64-bit Operating Systems Windows 7 (1 + 1) Redundant AC-DC high-efficiency power supply w/ Power Supply PFC AC Voltage 100 - 240V, 50-60Hz

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 117 of 178 19” industrial Rack mount movable Chassis Front Panel should have lockable Door to Protect Drives Wall configuration 4 DVI-D Outputs Resolution output support 1920x1200 per output minimum Universal Inputs 2 DVI Inputs System Should have the redundancy support for following: Fans Redundancy Support Power Supply LAN Display & Controller Display & Controller should be from the same manufacturer OEM should have a manufacturing facility in India with its Manufacturing own service center manned by its own engineers for providing support

Display Control System Specifications

 Server-grade super computer architecture with 19" rack mountable chassis: Single or multiple based on configuration  Runs on all standard operating systems: Win XP, Vista, Windows 2003 Server-64 bit, Windows 7 and with Linux Emulation  Core 2 Duo and Xeon Quad Core with multiple processor support  Redundant & hot swappable components: Power supplies, cooling fans, hard disk drives; dual redundant networking with optical fiber support  Raid 0,1, 5 & 10 support  Hardware decoding of IP streams: Supports decoding of multiple camera types, multiple formats, custom formats and resolutions from QCIF, D1 to megapixel  Displays resolutions up to 1920 x 1200  Single source window per channel up to 64 sources windows per channel  Advanced control systems provide edge blending features to create seamless displays  Full control on window sizing, positioning and scaling  Switch fabric chassis for high demanding applications  CPU, fan, temperature and chassis intrusion detection & alarm  Remote management for hardware functions  KVM over LAN, serial over LAN, LAN alert  SNMP trap, event log, remote power control, command line interface

Input Sources and Capability

 Analog & digital sources supported and displayed on the same canvas  DVI -D, RGBHV, HD Video, display over LAN , VNC, IP stream decoding

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 118 of 178  Hardware based cards as well as software based decoding

5.13.31. BRTS Bus Controller and Driver Console

The main function of OBU is to:

 Acquire data related to the bus real-time scenarios and transmit it to the control centre.  Fetch driver demands to the control center and send them through the communications system.  Receive messages and voice communications from the CCC controllers.

Data received from OBU shall provide following (this is minimum list and actual list may vary depending on requirement finalization):

 Geographic position of the bus, calculated with the GPS receiver and odometer data.  Service related data: driver number, line, route etc.  Real-time Stop information.  Time of reaching expected locations.  Time when the bus leaves the expected locations.  Current speed.  Bus ignition status.

The BDC shall provide functions for drivers to login / log-off, read predefined messages, read messages received form control centre, voice call request, volume control etc.

The bus driver console shall provide facility for drivers to send information to control centre like call initiation, Message retrieval, vehicle stoppage, detour information, occupancy, medical help, accident info, service requirement etc.

Architecture

The architecture defines the overall inter connectivity of the different sub system inside the vehicle, communication within the sub systems and connectivity to the backend solution for the transmission of the real time vehicle information. It shall consists of following sub systems

i Passenger information system (PIS) On-Bus ii Automatic vehicle location system (AVL) On –Bus iii Controller and Bus Driver Console-On Bus

Automatic vehicle location (AVL) system

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 119 of 178 Controller will transmit raw GPS data ,of vehicle locations, in NMEA protocol , to back office control centre at user configurable frequency ( 5 seconds or less),via 3G(GSM)/GPRS, for further processing and use ,including that for signs on bus stops ,BRTS and bus terminals.

Controller and BDC architecture

Usability/Functionality/Capability

a Provide the driver/user interface/display on BDC b Control PIS functionality as specified elsewhere in the document c Provide two-way voice and data link with control centre to communicate data and information. d The link will be based on open public communications network services 3G (GSM) with downward compatibility with 2G e Provide audio interface to the driver’s microphone and earpiece or speaker using wired link to Controller f BDC ,on a selectable ‘menu’ will have ‘panic’ options’ for communicating pre- configured messages to control centre g BDC should provide Mic and speaker system for manual announcement. h It should be possible to transmit to CCC : Device IMEI, SIM No., Driver ID, Conductor ID, Panic Button (E) pressing, Ignition on/off, Door Open Close, Battery Volts any other i It should be able to provide Time Table related information to the Driver and CCC j Two way communication with central control centre (CCC) via Contoller i. It should be possible to change/choose/select a 'route' remotely over the air from back office and provide current route information to back office ii. It should be possible to transmit adhoc messages (English) from back office to internal sign. k To comply with test standards Technical specifications: Controller a Processor : 32 bit minimum b Operating system: embedded Windows/Linux with programming software c Memory : flash: 2 GB minimum, RAM 512 MB minimum (RAM memory includes SCU and BDC) d Interface : As required for the functionality e Interface protocols :as specified elsewhere in this document f In built GPS and 3G(GSM) modules g Combi antenna h In built /external two channel amplifier minimum 10 Watts rms each suitable for 4 ~8 Ohm impedance with input for external microphone i In-built MP3 files storage/playback function.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 120 of 178 Technical Specifications: BDC

a Display i Size 5.7” diagonal minimum ii Full color graphic TFT-640 x 480 dots minimum, capable of showing minimum 20 lines in English. iii Viewing angle (horizontal) 70°/70° (right/left)/ (vertical) 60°/60° (up and down) iv Adjustable back lighting b Key board :4 keys minimum

Technical specifications: GPS modules

a Tracking sensitivity :-165 dBm typ b Navigation sensitivity ; -148 dBm typ c Update rate I Hz (configurable to 10 Hz) d Time to first fix cold acquisition 35-42 seconds typ e Hot acquisition 1-2 second typ. f Navigation accuracy 3M horizontal

Technical specifications: 3G(GSM) modules

a GSM/GPRS SMT quad band and UMTS (3G) b Temperature range -15°C to +80°C

Technical specifications: ‘Combi’ Antenna

a AMPS 850MHz, GSM900MHz, DCS1800MHz, PCS1900MHz, 3G UMTS 2.1GHz, GPS (1575.42MHz). b GPRS i Impedance 50 Ohm ii Radiation pattern Omni-directional iii Polarization linear (vertical) c GPS i Impedance 50 Ohms ii VSWR <1.5:1 iii Polarization RHCP d Waterproof IP-66 e Temperature range -15°C to +80°C f RG174 cable

Fitment on bus

a All equipment including wiring harness, antennas to be original factory fitment. b Front, side, rear signs should be mounted with a gap with the glass so that the glass on signs and of the bus can be cleaned by swiping

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 121 of 178 c All equipment should be fitted in a way to minimize unintentional damage, shielded from direct engine heat, protected from water splash and dust. d All cables need to be properly anchored e Others: i Front sign: central ii Rear sign: central iii Side sign: first window ahead of rear door (central line of sign should coincide with central line of window) iv Inner sign: centralize along the width of bus behind the driver's partition v Speakers with protective grill : one each near the doors and others equally distributed across the length of the bus- Total no. 4 vi Controller, recorder, amplifier : secured and ventilated compartment right above the driver vii BDC: ergonomically placed for driver ease viii Camera: as specified else where ix Combi antenna: suitable place to define inside the bus (preferably) with direct line of view for 'affixing' the unit.

Communication amongst sub systems

a 'Signs' to 'SCU'/’BDC’ RS 485 b Controller to 'BDC' Ethernet/DVI/VGA/HDMI/RS232/RS485 as required.

Approvals

a The notified agencies, as under rule number 126 of CMVR, will be responsible for approvals and certification of the system as defined above.

5.13.32. Bus Passenger Information System Specifications

Specification PIS –On Bus

PIS System

Usability/Functionality/Capability All drivers related interfaces for PIS must be provided on Information Control Unit ICU The route programming file to be uploaded on ICU via USB upto 8GB minimum

Route selection function is to be provided on ICU with easy sorting of Routes

All driver related route information to be displayed on ICU

Amber colored, alphanumeric with graphic capability

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 122 of 178 In-built light sensor with continuously variable brightness control to enable the display intensity to change based on ambient light conditions

Viewing distance

Front, side and rear signs 50 meters minimum, for single line text, in day and night.

Inner 15 meters minimum, for single line text in day and night.

Display Characteristics

Fixed, scrolling and flashing mode (with fixed route number, upto 6 characters, on front, side and rear signs).

Capability to show customized graphics.

Two lines English /one line local language.

Total display height should accommodate two lines in English language and the Individual heights of each line should be adjustable to enable one line to be larger/smaller than the second line. However during next stop announcement only single line text is required

It should be possible to display, concurrently, different messages on each of the signs (front, rear, side and inner).

It should be able to display special signs like signs for 'PWD enable bus', ‘ladies special’.

Capability to show special characters like (, ‘ “ . ! + - * : ?)

Signs should have ability to retain the last message displayed in the memory of the sign even in the event of power failure and without the message being reloaded. from ICU. Test will be performed by disconnecting the ICU from the sign and power to the sign will be switched ‘off’ and ‘on’ to see if the Last message is retained and displayed.

Display and voice announcement in English and local languages using Microsoft fonts via window based software package –Window 8.1

The system should have a programming capability as under

Minimum 75 routes UP and DOWN (150 numbers of destinations) on front, side and rear signs.

GPS triggered next stop display on Inner sign with synchronized voice announcement for minimum 75 stops on each route.

The inner sign should be able to display and announce upto three languages, one after the other in sequence. For example make display and announcement in English, then Hindi or gujarati to be followed by local language for benefit of the passengers. Display

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 123 of 178 and announcements should be possible "before arrival" of the bus at the bus stop, "on arrival" of the bus at bus stop and "after departure" of the bus from the bus stop.

In event of GPS failure the above functionality should be possible through manual intervention on ICU.

Display driver and conductor ID once in between the stops on Inner sign

Inner sign should be able to display text and customized graphics and announce upto pre-recorded messages by driver selecting 1~9 on ICU display panel of the controller.

Display customized graphics plus synchronized voice announcement – preferably location based in case of Million plus population cities

Functionality of Display 'clock'-GPS based or ‘Default Messages’ on Inner sign

Emergency 'stop' request function- by pressing an emergency switch placed anywhere in the bus the inner sign should display 'stop' message and buzzer located near the driver makes the sound alerting the driver to stop the bus.

In case one or more signs get disconnected (malfunction), the rest of the Signs should continue to function regardless (including fresh communication from ICU)

Sign should be able to store 'diagnostic trouble codes' (DTC)’,'parameters identifiers (PID) and data should be retrievable.

To comply with test standards as per Separate List

Dimensions and technical specifications of signs Display size / Board Size Front minimum 200x1800 mm –one

Type I : 220x1800 mm min, Type II: 220x1200 mm min,Type III ;220x1200 mm min, Mini Midi :220x800 mm min

AIS 052 2.2.15 Destination Board for Public Service Vehicles

Rear and side: minimum 200x900 mm-one each

Type I : 220x900 mm min x2, Type II: 220x900 mm min, Type III ;220x900 mm min, Mini Midi :220x800 mm min

AIS 052 2.2.15 Destination Board for Public Service Vehicles

Inner : minimum100x800 mm –one Pitch Front- maximum. H 13.4 mm x V14.1 mm

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 124 of 178 Side and rear maximum. H10.5 mm x V 14.1mm

Inner 8 x 8 mm maximum.

LED and display quality front, side and rear signs Amber colored LED, dominant wave length 591~595nm

UV resistant, diffused lens 4 mm (minimum)

Wide viewing angle 120⁰ horizontal & 80⁰ Vertical

Ensure enhanced readability with full clarity on scrolls and long life usage by incorporating non multiplexed system (constant current drive circuit) with typical LED Intensity 400~700 mCd at If =20 mA,

LED and display quality inner sign LED amber dot matrix viewing angle 45⁰ all around, intensity minimum 40 mCd, dominant wave length 591 ~595 nm

Structure

Front ,side and rear signs : light weight structure with toughened glass fixed with UV resistant adhesive in front

Inner sign: light weight structure with poly glass /acrylic/toughened glass.

Conformal coated PCBA and ROHS Compliant

ICU architecture Usability/Functionality/Capability

The ICU should control complete Public Information System on Bus including Destination Signs, External Amplifier and Speakers.

The Driver has to select a ‘Route’, from a Pre-loaded Route Data Base and all information will be displayed and or announced automatically based on Bus Location (GPS).

Provide capability to upload firmware on Signs via RS 485.

A ‘beep’ sound is made when vehicle speed exceeds set speed limit. The limit is configurable through Software and preset at 50 Kmph

Should be possible to check Firmware Version, Route Data base version.

Technical specifications: ICU Operating Voltage 9~32 Volts

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 125 of 178 Processor : 32 bit minimum

Operating system: embedded Windows (8.1) /Linux with programming software

Memory : 256 MB minimum

Interface minimum : RS 485, RS 232, USB, GPS Antenna

Conformal coated PCB boards

Route Data upload on Controller from PC via USB port (USB 1.1, USB 2.0, FAT, FAT 32, 8 GB capacity). Devices prone to pilferage e.g. SD Card is not permitted. Buzzer indication when loading is complete

Integrated with External GPS Receiver and Antenna’ via RS 232 using Standard NMEA 1083 GPRMC sentence, transmission Protocol to be provided by the Manufacturer under a ‘NDA’.

In-built MP3 files storage/playback function and compatibility with external two channel amplifier minimum 10 Watts rms each suitable for 2 ~8 Ohm impedance with input for external microphone

LCD Panel (resolution 64 x 256 minimum), Illuminated with automatic brightness Control and Backlit Keypad with minimum 20 soft keys including alphanumeric.

Mounting in Radio Slot acc ISO 7736

Programming Software (including simulation, Brightness control, scroll speed control, scroll direction, Template configuration, Graphic library, customised graphics)

Amplifier, Speakers and Wire Harness (with water proof connectors)

5.13.33. City Bus Station PIS Specifications

Specification PIS – On City Bus Station

PIS System

Usability/Functionality/Capability Amber colored, alphanumeric with graphic capability

In-built light sensor with continuously variable brightness control to enable the display intensity to change based on ambient light conditions

Viewing distance Front, side and rear signs 30 meters minimum, for single line text, in day and night.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 126 of 178 Display Characteristics Fixed, scrolling and flashing mode (with fixed route number, upto 6 characters, on front, side and rear signs).

Capability to show customized graphics.

Two lines English /one line local language.

Total display height should accommodate two lines in English language and the Individual heights of each line should be adjustable to enable one line to be larger/smaller than the second line. However during next stop announcement only single line text is required

Capability to show special characters like (, ‘ “ . ! + - * : ?)

Signs should have ability to retain the last message displayed in the memory of the sign even in the event of power failure and without the message being reloaded.

Sign should be able to store 'diagnostic trouble codes' (DTC)’,'parameters identifiers (PID) and data should be retrievable.

To comply with test standards as per Separate List

Dimensions and technical specifications of signs Display size / Board Size

Front minimum 200x1800 mm –one

Pitch Front- maximum. H 13.4 mm x V14.1 mm

LED and display quality front, side and rear signs

Amber colored LED, dominant wave length 591~595nm

UV resistant, diffused lens 4 mm (minimum)

Wide viewing angle 120⁰ horizontal & 80⁰ Vertical

Ensure enhanced readability with full clarity on scrolls and long life usage by incorporating non multiplexed system (constant current drive circuit) with typical LED Intensity 400~700 mCd at If =20 mA, light weight structure with toughened glass fixed with UV resistant adhesive in front with anti-theft and anti-vandalism proof

Station PIS Specific

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 127 of 178  There shall be two displays per station.  They shall display route and estimated arrival time (ETA).  They may also be used to display public service information  They shall display route and estimated arrival time (ETA) and public service information.  The display shall receive encoded information of route and ETA from the AVLS control Centre through the common wired/wireless communication link set up and Station Server at each bus station.  Power Supply: 24 Volt DC, supplied through external 230 AC >DC Converter

5.13.34. PIS Display Test Compliances

Test PIS Station PIS Sr. standards Signs Signs Controller Specifications No compliance

Nine points, tri temperature/tri Y Y Y voltage- 18V, 27V, 32V,-25°C, room temperature, +80°C test. At Performance each test point the system will be 1 parametric powered on and shut down 5 test times as per the supplier’s designated procedure and thereafter evaluated for malfunction if any IS 9000 (Part II/Sec 4)-1977 Y Y Y 2 Cold (reaffirmed 2004) at -15⁰C for 2 hours in ‘on’ condition IS 9000 (Part III/Sec 5)-1977: at + Y Y Y 3 Dry heat 80⁰C for 16 hours in ‘on’ condition. IS 9000 (Part V/Sec 2)1981 at Y Y Y +25⁰C /+55⁰C, Humidity 95%, 24 hours for 6 cycles in off condition. 4 Damp heat Functional test with power in ‘on’ condition at start of 2nd, 4th and 6th cycle 5 Vibration  Frequency 5~55Hz and return Y Y Y

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 128 of 178 standard AIS to 5Hz at a linear sweep 012/AIS:062 - period of 1 minute/complete 10g sweep cycle and 10g at maximum frequency  Excursion -1.65 mm peak to peak over the specified frequency range  Test duration 60 minutes Direction of vibration –X, Y, Z axis of device as it is mounted on the vehicle.  Test to be carried out in ‘on’ condition as per ARAI Dust and IS /IEC 60947-1:2004 in Y Y Y water conjunction with IS/IEC 6 ingress 60529:2001– ‘Signs IP66, protection Controller IP 66 IS 9000 (Part VII/Sec 4) Free fall N N Y 7 Free fall at 500 mm ,(applicable ‘controllers’ only) 8 Fire resistant Wiring Harness Y Y Y The component must fulfill the Y Y Y Reverse function- and service life polarity requirements after being 9 protection subjected to reversed polarity up without fuse to 27 V for 2 minutes. ISO 17650- 2 To ensure service life Y Y Y requirements and functionality. Over voltage The component shall run for 60 10 protection minutes at 38V, without effecting the service life or function. ISO 16750-2 The Insulation résistance Y Y Y measured as per ISO 16750-2 with a voltage of 500 V dc shall not be less than 1Mega ohm. Insulation Insulation Resistance Test will 11 resistance be carried out after completion of ‘Damp Heat Test’ and then the Test sample to be kept at room temperature for at least 0.5 hrs. 13 Load dump 123V, 8 Ohms 200ms pulse 5a as N N Y

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 129 of 178 per standard ISO 7637-2. After Test DUT should meet at least class B as per ISO 7637-2 Salt spray (AIS: 012/ IS10250) 96 hours Y Y Y 14 test 15 EMC/EMI AIS 004 (PART 3) Y Y Y EMC/EMI ‘e’ Certificate Y Y Y Operating Supply voltage 24 V± 25% Y Y Y 16 parameters LED color Y Y NA 17 test – dominant AIS -010 (Part 5), (Rev 1),2010 wave length amber Limit towards green: y ≤ x-0.120 Y Y NA Limit towards red: y ≥ 0.390 Limit towards white: y ≥ 0.790- LED 0.670x chromaticity 18 Reference to AIS010, (Part 5), coordinates (Rev 1), 2010 In accordance with CIE 127 condition B LED Y Y NA bulb/SMT In accordance with CIE 127 19 intensity condition B and viewing angle Apply a Voltage of 0V to 27V at Y Y Y increasing rate of 0.5V per second Slow for slow Increase of Power Increase and Supply. 20 decrease Apply a Voltage of 27V to 0V at (Ramp up/ decreasing rate of 0.5V per Down) second for slow Increase of Power Supply. Short Circuit Y Y Y 21 ISO 16750-2 Protection Momentary Y Y Y 22 ISO 16750-2 Interruption 23 Ripple ISO 16750-2 Y Y Y Thermal ISO 16750-4 Clause 5.3.2 N N Y Shock- 24 Controller Only

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 130 of 178 Powered Y Y Y  Direct Contact ± 6 kV ± 8 kV ESD Test  Direct Air ± 8 kV ± 15 kV 25 Unpowered  Direct Contact ± 6 kV ± 8 kV  Direct Air ± 8 kV ± 15 kV

Ambient Temperature, preferably Y Y Y 27 ± 2°C, 28 V, 100 000 cycles. Endurance Each cycle shall consist of Test switching ON & OFF the system 26 with dwell time as follows: Dwell time: 10 s ± 1 s (ON condition), 4 s ± 1 s (OFF condition). USB Port Pin No. 1 (+5 VDC) & NA NA Y Pin No. 4 (GND)to be Short USB port Circuited with external wire in 27 over loading “ON” condition as shown below. test The System should continue to work without any problem.

5.13.35. GPS based On-board unit for City Bus

Sr. No Specification Details

1 Input Voltage Range 5.5V - 36V

2 Average current 90 to 100mA

3 Average current with Battery 125 to 135mA charging

4 Battery Specification Lithium-ion 3.7V /1000mAh

5 Battery Backup Time 40 min with 30 sec tracking interval

6 GPS Cold Start<55 sec

Hot Start < 10 sec

8 GPS Sensitivity Tracking -157 dBm

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 131 of 178 navigation -154 dBm

Acquisition -142 dBm

11 Antenna Internal Antenna for GPS and GPRS

12 Horizontal Position Accuracy upto 16 meter (4 sat fix, 9 sat search)

13 Digital Inputs 3 minimum

14 Digital outputs 2 minimum

15 Analog Inputs 2 minimum

16 GEO Fence User settable Distance range, SMS alert packet when out of Geo-fence

17 Over speed User Settable Speed limit, SMS alert packet when speed cross over speed limit(maximum)

18 Movement control 100 metre range, SMS alert packet when vehicle moves out of movement area

19 Parameters Setting Through SMS APN, live ip1, live ip2, unit id, server reconnect frequency, server_change frequency, reset odometer, geofence control, over speed control, movement control , sms serving numbers, UTC time configuration, factory setting, digital output control, memory data erase

20 EEPROM 2MBit

21 GPS Track Recording and Built in 2MBit large flash memory to Resending store data when out of GPRS radio coverage

Automatically resend Non- GPRS coverage data when device goes into GPRS coverage

23 Ignition status ON/OFF status

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 132 of 178 24 POWER SUPPLY External & Internal Battery

25 Internal Battery Should provide GPS data for at- least 4 hours when external power supply is disconnected.

26 Battery Status Battery Health indication

27 GPS based Speed measurement up to 180 KMPH Range:

28 GPS based Odometer Required

29 Factory setting Switch for default factory setting

30 Data send frequency settable Adjustable upto 8 seconds or more

31 Server change frequency settable min. 1minute

32 Server reconnect frequency settable, min. 1minute

33 LED status Power

34 USB for parameter configuration Required

35 Multi IP connection two server Primary, Secondary

36 AGPS supported Required

37 Operating Temperature -10°C to +50°C

38 Storage Temperature -10°C to +50°C

39 Humidity 95% non-condensing

40 Protection IP 40 and above

41 API/SDK Should provide API's protocols and necessary documentation for integration purpose.

42 Connection USB/RS232 port

43 GPRS 1 Sim slot internal

Driver Feedback System

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 133 of 178  Provides continuous real time, visual and audible feedback to the driver, via a display regarding driving parameters.  Integration capability with major GPS devices via APIs protocols.  It should detect and report event for fuel consumption, emission and accelerated wear and tear (brakes, axles, engine, etc.)  It should provide logs and reports a wide set of events, accident events and/or raw data concerned with hazardous or aggressive driving behavior for later re-construction on the server side.  It should provide trip statistics information, which includes information gathered and processed on-board during a trip.  It should provide the below mentioned events

 Acceleration  Braking  Harsh Lane Crossing  Turn  ON/Off Road  Over Speed  Idling

5.13.36. BRT station LED TV based PIS Display System

Sr. No Parameter Min. Requirement 1 Type of Display, Screen Full Colour, LED Display, Day Light Readable Size Min 50 Inch LED TV 2 Min & max viewing Viewing distance 20 - 100 meters distance and angle of Minimum 60°V – 110°H viewing

3 Environmental Temperature: 0 to +55 deg C; Sealing: IP 65 (Front), specifications IP 54 (Rear) Humidity: 95% RH, Industrial Grade 4 Minimum life of the 100,000 hours display system

5 Power supply 90 V to 250 V AC 6 Display format Multimedia content, Text in Gujarati, Hindi & English with presentation in tables, Fixed and scrolling Text

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 134 of 178

5.14. Training Room and Test Systems

Scope: The service provider shall set up training and test facility adequate for training all staff of the service provider. Each staff member shall be deployed on the front end or at CCS centre only after certification jointly by Service provider and SMC. Service provider shall create training manuals and other necessary aids to ensure the perpetual need for training as and when required for SMC/Operator Personnel is required. The training room shall be general training room pertaining to all ITMS components and operational requirements. Handover/Takeover The service provider shall ensure that SMC is sufficiently trained and skills are continuously upgraded to ensure complete takeover of the system at completion of the contractual agreement. The service provider is required to impart training and necessary tools in-order to take-up operations whenever necessary. Service provider shall six months before the end of the contractual period go through a process of hand-over take-over with SMC personnel’s and act in supervisory role for smooth take over. Functional Requirements: The devices and sub-systems shall be connected to the test CCS by an independent LAN / WAN that will permit the exchange of controls and data in a similar manner to that implemented for equipment installed in field. Use as Prototype The service provider shall develop software applications / manufacture equipment or accessories at the training and testing facility for testing as a prototype. Deployment will follow after joint evaluation by SMC and the service provider.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 135 of 178 5.15. Human Resource Management

There shall be a Project manager as a representative of the service provider at the time of implementation followed by an Operations manager, employed as the head of operations by the service provider, after the start of commercial operations. Project manager shall act as the single point of contact and shall be responsible for all the deliverables of this agreement. The operations manager shall be the single point of contact with SMC after the start of operations. Central Control System All the manpower required for Central Control System including the hardware maintenance shall be arranged by the service provider. Required database, SW and report experts shall be organised by the service provider. The proposal must include the costs for these operational personnel. Any shortcomings shall be made good by service provider, and if needed, deploy additional personnel to ensure satisfactory services.

5.16. Commercial Operations and Maintenance - Bus stations, Bus Depots, Buses, Control Centre

The service provider shall provide cost of such services on annuity basis, payable monthly. This should be clearly indicated in the financial proposal. The personnel shall be responsible for the smooth functioning of equipment’s and its connectivity to CCS. They shall attend to the problems with tracking devices, fare equipments, PIS equipment, connectivity problems and any other hardware related at stations and bus depots. Service provider personnel shall also attend to any problem with equipment on bus installed by it. At least second and third line maintenance shall be provided and may take the form of remote connectivity and help desk. 5.17. Business Continuity Plan

The service provider has to design control centre system in high availability mode to mitigate risk of any outages on account of Hardware /Software / Connectivity failure. The service provider has to guarantee up time of 99.9%.

The Business Continuity Plan will be based upon Backup and Restore strategy. The devices (such as SCU) will be able to retain usage data up to a period of 7 days.

Nevertheless, our backend solution will be able to support the replication/hot redundancy if it is needed in a later phase of the implementation.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 136 of 178 5.18. Application and System Audit

SMC shall at its discretion appoint a third party auditor capable of auditing IT systems envisaged as part of ITMS implementation. The service provider shall be required to provide necessary information to the third party auditor to facilitate testing and audit of hardware, software and processes related to ITMS.

5.19. Scope of Pilot Implementation

The pilot demonstration will comprise the following tests which need to be cleared in terms of specification compliance and operational performance. Automatic Fare Collection System BRT Bus Station . Flap Barriers operations . Local LAN at Bus Station . Usage demonstration of Flap Gates to check specifications compliance. . Point of Sale demonstration for ticketing operations compliance. . Card and Barcode Validator operations. . PIS Display compliance to requirements. Central Computer System . One System with the required software will be installed (use of Cloud is permitted) . Upload data from Field equipment’s to Central computer system . Processing the data and generating the reports . Reports and MIS will be generated GPS Based Fleet Management System . GPS Unit will be fitted in minimum two Vehicle . Operations shall be tested for one full day of working with the operations and communications requirements as stated in RFP. . System can be accessed over the internet . MIS & Reports will be generated . Passenger Information System in minimum two stations and rest can be shown via software interface. . Two Destination Sign and one Next Bus Stop Sign with Announcement

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 137 of 178 Public Information System . Bus Stop Display Boards will be fitted at Two bus stops and they will fetch the information over GPRS or fixed line . System can be accessed over the internet . MIS & Reports will be generated Vehicle Dispatch & Scheduling System . Sample route shall be given with actual current operations items like time, buses and route and service provider shall demonstrate implementable schedule and dispatch files on proposed software.

5.20. Change Management Procedure

Any changes having technical or commercial implications will have to be mutually agreed upon in advance, prior to making the change. In case of situations, that the impact is not dependent on one or both parties’ agreement, the revised commercials will be effective from the date of impact. For avoidance of doubt, the parties expressly agree that  Change Request shall not be effective and binding unless agreed in writing and signed by both SMC and Service Provider.  The payment of any additional cost agreed under a Change Request shall be in addition to the payments agreed upon under this Agreement.  Upon a Change Request becoming effective, the Project Schedule shall automatically stand adjusted by the additional time required for implementing the Change Request. 5.21. Computerized Call Management System

The service provider shall be required to implement service call management system capable of logging service request call within the enterprise of SMC ITMS. The system shall uniquely identify all calls by way of assigning ticket numbers and resolution procedure. This system shall provide SMC a computerized log of all incidents logged as part of the ITMS operations. The system should further provide analytical reports to evaluate problem areas and escalation system to ensure problems are reported properly and resolved.

5.22. Project Management Requirements

The scope, duration and size of this project require the service provider to create an effective Project Management team to assure the success of the work. The following Project Management elements shall be incorporated as a key component of the project.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 138 of 178

5.22.1. Project Management Personnel

The Service Provider shall establish a Project Manager, who shall be highly responsive to the needs of SMC as required in these Specifications and subject to SMC acceptance. The Project Manager shall coordinate design and engineering activities and provide a technical liaison to SMC. This person shall be highly competent and fully qualified in all aspects of the System. Where support is provided from individuals or groups outside the project, the support personnel shall be under the control of the Project Manager during the period of support, and support groups shall be required to provide support as their highest priority. An organization structure that diffuses responsibility and does not require that resources be assigned at management request is not responsive to this Contract and will not be accepted or tolerated by SMC. To accomplish the above, the Service Provider shall assign a permanent Project Manager and Senior Technical Staff Member (STSM), subject to SMC approval and assure compliance with the project management requirements of the Specifications and Agreement. 5.22.1.1. Project Manager

The Project Manager shall be identified to SMC, within seven (7) days after notice to proceed. Authority The Project Manager shall have the contracting authority to issue and approve purchase orders and to contractually bind the Service Provider. The Project Manager shall have the authority to assign and schedule Service Provider to perform all of the Work required by this Agreement, and act as Service Provider’s representative for dispute resolution. Responsibility The Project Manager shall provide a single point of contact for SMC to resolve all issues related to this Contract. The Project Manager shall be responsible for directing all Subservice providers’ designs and work. Project Understanding The Project Manager shall have a full and complete understanding of the Contract Documents and site conditions sufficiently to provide adequate direction for coordination of work. Qualifications The Project Manager shall have at least 10 years’ experience in design and management of Transit ITS projects, with at least one completed project assignment for a fleet in excess of 200 vehicles. SMC shall be the sole determinant of the suitability of the proposed Project Manager’s qualifications. SMC reserves the right to have the service provider replace the Project Manager if qualifications are not met. Availability to the Project

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 139 of 178 The Project Manager shall be available to SMC on a twenty-four hour per day, seven days per week basis and shall respond promptly to any reasonable SMC request. Coverage of this requirement by any alternates shall be subject to approval by SMC. The Project Manager shall be on site during all significant project events, as necessary to facilitate meetings, project activities, and information flow between the service provider and SMC, and as requested by SMC.

5.22.1.2. Senior Technical Staff Member

The STSM shall be available to the Project within seven days after LOI issuance. Responsibility The STSM shall act as a technical resource for coordinating all system design and implementation issues and Management of AVLS/PIS/Scheduling systems etc. The STSM shall check each technical submittal prior to its being sent to SMC for approval. The STSM shall all technology related work to assure quality. Project Understanding The STSM shall have a complete understanding of the technical requirements of the Contract Documents and site conditions sufficiently to provide design direction and to determine compliance of the service provider’s design submittals and work. Qualifications The STSM shall be a Professional Engineer, who qualifies as acceptable to SMC. The STSM will have a minimum of 10 years of experience, including three years or equivalent experience in coordinating engineering and administrative support activities for ITMS. SMC shall be the sole determinant of the suitability of the proposed STSM’s qualifications. SMC reserves the right to have the service provider replace the STSM if these qualifications are not met. Availability to the Project The STSM shall be on site during all significant project events, as necessary to facilitate meetings, project activities, and information flow between the service provider and SMC, and as requested by SMC. In no case shall it be considered acceptable for the STSM to be on site less than ten (10) days per month. Coverage of this requirement by any alternates shall be subject to approval by SMC.

5.22.1.3. Hardware, Network & Data Centre Staff Member

The NDCS shall be available to the Project within seven days after LOI issuance. Responsibility The NDCS shall act as a technical resource for coordinating all network and compute design and implementation issues. The NDCS shall check each technical submittal prior to its being

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 140 of 178 sent to SMC for approval. The NDCS shall be responsible for all technology related work to assure quality. Project Understanding The NDCS shall have a complete understanding of the technical requirements of the program requirements to provide design direction. Qualifications The NDCS shall be a professional engineer, who qualifies as acceptable to SMC. The NDCS will have a minimum of 10 years of experience, including three years or equivalent experience in coordinating network and data centre support activities for ITMS. SMC shall be the sole determinant of the suitability of the proposed NDCS’s qualifications. SMC reserves the right to have the service provider replace the NDCS if these qualifications are not met. Availability to the Project The STSM shall be on site during all times, as necessary to facilitate meetings, project activities, and information flow between the service provider and SMC, and as requested by SMC. In no case shall it be considered acceptable for the NDCS to be off site. Coverage of this requirement by any alternates shall be subject to approval by SMC.

5.22.1.4. Control Room and Process Analyst

The CRPA shall be available to the Project within seven days after LOI issuance. Responsibility The CRPA shall act as operations management expert for coordinating all operations related decision making and controller staff / work management. The CRPA shall be responsible to manage SOP’s and operational requirements required for the control room operations and shall work along SMC designated authorized resources for management and operations purposes. Project Understanding The CRPA shall have a complete understanding of the technical requirements of the program requirements to provide operations direction. Qualifications The CRPA shall be a professional engineer with specialization in urban transport management, who qualifies as acceptable to SMC. The CRPA will have a minimum of 10 years of experience, including three years or equivalent experience in coordinating operations management support activities for ITMS. SMC shall be the sole determinant of the suitability of the proposed CRPA’s qualifications. SMC reserves the right to have the service provider replace the CRPA if these qualifications are not met. Availability to the Project The CRPA shall be on site during all times, as necessary to facilitate meetings, project activities, and information flow between the service provider and SMC, and as requested by SMC. In no

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 141 of 178 case shall it be considered acceptable for the CRPA to be off site. Coverage of this requirement by any alternates shall be subject to approval by SMC.

5.22.2. Project Meetings

Attendance The service provider’s Project Manager and STSM shall attend Progress Meetings held weekly. The service provider’s Project Manager and STSM shall conduct a Project Kickoff Meeting with SMC stakeholders, Steering Committee, and the SMC Consultants. The service provider’s Project Manager and STSM shall attend additional meetings, as requested by SMC and the SMC Consultants pursuant to the coordination of the Work. Location Progress meetings shall be held at SMC facilities unless otherwise specifically approved by SMC. Other meetings shall be held at a mutually agreeable location, conducive to the topic of the meeting. For any project meetings conducted by conference call, service provider shall, at the service provider’s expense, provide a conference call-in number. Meeting Minutes The service provider shall prepare minutes for each meeting, unless specifically instructed otherwise by SMC. The Service provider shall prepare the minutes and distribute them to the attendees within two working days after the meeting. Minutes of Meetings shall include names of attendees, significant proceedings, decisions, unresolved issues, and a list of information requested by SMC. The minutes shall be of sufficient detail to record any decisions made at the meeting and any follow-up actions required. The minutes shall include a summary of open action items, the party responsible for each, scheduled date for the action, and the respective resolution. Service provider shall provide a rolling project report, adding and deleting items as necessary. Agenda The Service provider shall prepare the agenda for each progress meeting. The Service provider shall provide a draft agenda to SMC at least one week prior to each meeting and request that SMC add any additional items. Review of the previous meeting minutes and any outstanding action items shall be included on the agenda for each meeting. Each progress meeting agenda shall also include the item, “Additional SMC Issues and Concerns.” Schedule Detailed Contract Schedule The detailed contract schedule shall be a critical-path-method schedule constructed using Microsoft Project or other software application acceptable to SMC. The detailed contract schedule shall show each activity, including interface activities, for completion of the Work, and shall be properly ordered and sequenced. Printed copies (if required) and one electronic copy of

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 142 of 178 the detailed contract schedule shall be submitted for SMC approval within 07 calendar days after LOI. Task Duration Limits The detailed contract schedule shall be sufficiently detailed to preclude the use of activity durations greater than 07 working days. Activity durations shall include allowances for lost time and inefficiencies. Task Designations Each task designation shall delineate the phase or stage of the work, and the component of the work such as design, submittal, submittal review, procurement, fabrication, delivery, installation, and testing. Task Details Where appropriate to the understanding of the task, additional details shall be provided, such as: • A clear description of the activity, including its location. • The duration expressed in full working days. • A responsibility code denoting the Service provider, a subservice provider, SMC, a government Agency, or a utility performing the activity. • BOM, Activities. • The integer percent complete representing the installed progress. • The actual start and finish dates when applicable. • Unless specifically agreed to in writing by SMC, Service provider is responsible for all Work to complete any task. Critical Path The detailed contract schedule shall show a clear and definable critical path(s) for the Work and each specified milestone. Requirements and events which impose limitations, as well as dates and milestones which constrain the time, shall be clearly identified. Days of float time shall be shown. Items that require SMC inputs and response shall be clearly identified. Updates The detailed schedule shall be updated every 07 days or as decided by SMC from time-to-time to show actual progress and changes to projected dates. Each update shall include a narrative describing the changes made since the last update. Each update shall be provided to SMC within 5 working days from the month end cut-off date and submitted with each invoice. Hard copies and one electronic copy shall be provided. Four-Week Rolling Schedules The four-week rolling schedule shall show one week of historical information and two weeks of planned activities in support of and consistent with the detailed contract schedule.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 143 of 178 Format The four-week rolling schedule shall be presented as a chart with tasks along the left side and days along the top of the table. A shaded bar or “X” entered in the chart shall indicate work to be performed on each day for that task. Task Detail The level of detail shown on the four-week rolling schedule shall be greater than the level shown on the detailed contract schedule. In general, it shall show the Work to be done each day and the location(s) where the work will be done and by whom. Work done in buses and other vehicles shall be identifiable uniquely or as part of an easily traceable group of buses. Work that requires SMC input or response shall be clearly identified. Updates The four-week rolling schedule (or as decided by SMC) shall be updated weekly and provided to SMC by the end of the first day of the active week. Printed copies and one electronic copy shall be provided. Submittals General This Section describes general requirements and procedures for preparing and transmitting information to SMC for review, acceptance or approval. Scheduling of Submittals Transmit submittals sufficiently in advance of contract requirements to permit at least Ten (10) calendar days for review (or need basis), checking and appropriate response by SMC or designated representative. Transmittal Forms Furnish the transmittal forms sequentially numbered and clearly indicate the Project Name; Project Number; Date; "To:"; "From:"; names of subservice providers, suppliers or manufacturers; required Specification references; category and type of submittal; purpose; description; distribution record (for transmittals and submittals); and signature of transmitter. Checking of Submittals Examine and check the submittal for accuracy, completeness, and compliance with the Contract before delivery to SMC. Stamp and sign each submittal with the statement reading as follows: "Having checked this submission, we certify that it conforms to the requirements of the Contract in all respects, except as otherwise indicated". By reviewing, approving, and submitting a submittal, the Service provider has determined and verified materials, field measurements, and field implementation criteria related thereto, and has checked and coordinated the information contained within such submittals with the requirements of the work and the Contract. Record of Submittals

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 144 of 178 Maintain at the worksite a complete up-to-date, organized file of all past and current submittals including an index and locating system, which identifies the status of each submission. • Assign sequential numbers to each submittal. • Assign revisions levels (A, B, C, etc.) to all re-submittals. Assign new transmittal numbers and cross references to previous submittals. Electronic Format All submittals shall be provided in electronic format as well as hardcopy. File formats for electronic copies shall be subject to SMC approval. Current version, industry prevalent software shall be utilized for preparing all submittals. Relevant drawings shall be submitted in AutoCAD & PDF format. Drawings or studies involving geographic information shall be submitted in a format that can be viewed by GIS software. SMC Review SMC and/or designated representative will review and approve or take other appropriate action upon the Service provider's submittals only for the limited purpose of checking for conformance with information given and the design concept expressed in the Contract requirements. SMC's action will be taken as to cause no delay in the Work or in the activities of the Service provider. Review of such submittals is not conducted for the purpose of determining the accuracy and completeness of other details such as dimensions and quantities, or for substantiating instructions for installation or performance of Equipment or systems, all of which remain the responsibility of the Service provider as required by the Contract. SMC's or designated representative's review will not constitute approval of safety precautions or, unless specifically stated by SMC or designated representative of any construction means, methods, techniques, sequences, or procedures. SMC's or designated representative's approval of a specific item does not indicate approval of an entire assembly of which the item is a component. SMC Review Stamp All Service provider's submittals will be stamped by SMC or designated representative with (a) the date of receipt, and (b) one of the following dispositions (see Review Stamp Exhibit hereafter). 1. APPROVED 2. APPROVED AS NOTED (Correct and resubmit): Work may proceed, provided: a. It complies with the Contract as well as the corrections on the submittals, and the Service provider resubmits within fifteen (7) days corrected copies of the specifications or miscellaneous submittals for final approval; and b. Work performed by the Service provider prior to receiving final approval will be at the Service provider's risk. 3. DISAPPROVED (Revise and Resubmit): Work not recognized as being able to proceed.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 145 of 178 Revise submittal in accordance with notations thereon, and resubmit without delay. Handle re- submittals in the same manner as first submittals, except designated with suffix A, B, C, etc. to indicate 1st, 2nd, or 3rd re-submittals. On re-submittals, direct specific attention in writing on re- submitted documents, working drawings, samples, mock-ups, sample panels, or miscellaneous submittals to revisions other than the corrections required on previous submissions. Make corrections required by SMC or designated representative. Actions Following Review If APPROVED, each of the documents will be identified as having received such approval by being so stamped and dated. Documents stamped DISAPPROVED and with required corrections shown will be returned to the Service provider for correction and re-submittal. Drawings Quality of Drawings The Service provider shall be responsible for accuracy and correctness of all drawings. The Service provider's Project Manager and STSM shall initial each drawing after checking it, indicating that it complies with all requirements of this Specification and accurately reflects intended or actual field conditions. The Service provider shall check each drawing for: • Conformance with Contract Documents • Logical grouping and arrangement • Accuracy • Legibility • Neatness • Line Quality • Lettering Quality • Reproduction Quality • Completeness Product Data Submittals Quality of Submittals A submittal shall be prepared for each major piece of material or Equipment that the Service provider intends to furnish. These submittals shall be known as "Product Submittals". Copies of each product submittal shall be furnished. Each submittal shall be accompanied by a cover letter with reference number, signed by the Project Manager. Each submittal shall contain a list of any parameters for which the submitted products do not meet the Specifications and a description of how these changes will affect system design. Each submittal shall contain a description of any changes in design or products that the submitted products will cause. Content

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 146 of 178 Each submittal shall contain sufficient information to determine that the System Component complies with the Specifications and Agreement. Actual values of all specified parameters shall be listed; a simple statement that the product complies will not be sufficient. Each product submittal shall be accompanied by appropriate documentation necessary to determine the product's applicability to SMC ITMS design. All closely related products shall be submitted as a single package. When pre-printed material is used in a submittal, the specific model number and options to be furnished shall be clearly identified. Standard data sheets can be used, subject to the following: • Modify manufacturer's standard and/or schematic drawings to delete information, which is not applicable to the Contract. Supplement standard information with additional information applicable to this contract. • Modify manufacturer's standards, diagrams, schedules, performance charts, illustrations, calculations, and other descriptive data to delete information, which is not applicable to the contract. Indicate dimensions, clearances, performance characteristics, capacities, and any other diagrams, as applicable. • Modify installation, erection, application, and placing instructions to delete information, which is not applicable to the Contract. Test Procedures The Service provider shall submit copies of each test procedure description, accompanied by a cover letter with reference number. Submittal Organization Each test procedure description shall include the following information: • A statement of the purpose of the tests. • The location, date(s) and time(s) tests will be performed. • The quantity of units to be tested. • The test equipment to be used, identified by manufacturer and model number. • A step by step description of the procedure to be performed. • Specific pass/fail criteria for each test. • A sample of the form(s) to be used to record test data. Each test form shall include the following information: a. Test title b. The manufacturer, model number and calibration date of each piece of test equipment. c. A table to record individual readings taken and inspections performed for each unit tested, identified by the serial number of the unit tested. d. An indication that the unit has passed or failed each individual test.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 147 of 178 e. A line for signature of the technician performing the test and date. f. A line for signature of the Project Manager and date. g. A line for signature of SMC representative witnessing the test. h. Drawings illustrating the configuration of the Equipment tested and all test equipment utilized. Test Results Content One original and copies of the results of each test shall be submitted. The original of the test results shall contain the original test forms filled out by the technician(s) performing the tests and original signatures. Test forms shall be filled out in ink and no erasures shall be made. Errors shall be crossed out with a single line and initialed by the person making the correction. Each set of test results shall be accompanied by a cover letter with reference number. Organization Each set of test results shall include the following information: • The complete test procedures used. • The completed, signed test forms. • A summary of the test, indicating quantity tested, quantity that failed, quantities that failed each individual procedure, and a statement of the remedy to be applied for failed units. AS-BUILT DOCUMENTATION As-built documentation shall include drawings and software documentation. As-built documentation shall include:  Design and Installation Plans of the On-Bus Subsystems for each Bus and Vehicle Type  Design and Installation Plans of the BQS Subsystem  Design and Installation Plans of the Central Control Centre Subsystem  Design and Installation Plans of the LAN and WAN.  Design and Installation Plans of the Scheduling & Dispatch Subsystem  Design and Installation Plans of the communication Subsystem  Design and Installation Plans of the AVLS Subsystem  Design and Installation Plans of the Passenger Information Subsystem As Built Software Documentation The Service provider shall provide all "Computer Software" and "Data" to allow SMC to fully maintain and update all "Applications Software". "Computer Software" and "Data" shall include as-built versions of ITM:  Software Requirements Specification;  Software Version Description Document, or equivalent;

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 148 of 178  All "batch" or equivalent files, and all object libraries and "include" files, for editing, compiling, linking, and installing application software. Corresponding instructions shall also be provided;  All files required to define, allocate, and load the database, and any other data files required to define, configure, load, or operate the system. Corresponding instructions shall also be provided.  All protocols and interfaces used within ITMS project (Mandatory) Copies of each document shall be submitted in electronic form (CD-ROM, DVD ROM or other media and in a format that is accessible by SMC) in order for it to be incorporated into SMC’s Electronic Document Library. Proposers shall explain, in detail, the documentation to be supplied, provide samples, and guarantee of content with proposals. PROJECT CLOSEOUT

Project closeout shall include an initial survey and a final survey.

Initial Survey

Pre-Requisites

Prior to requesting an initial closeout survey of ITMS, the following conditions shall have been met:  The systems acceptance test has been conducted.  The Service provider has listed those items yet to be completed or corrected and has submitted a detailed plan of action and schedule for completion of the outstanding items.  The Service provider has submitted special guarantees, warranties, maintenance agreements, final certifications and similar documents.  The Service provider has obtained and submitted operating certificates, if required, final inspection and test certificates, and similar releases enabling full and unrestricted use of the work.  The Service provider has submitted operations and maintenance manuals and final as- built documentation.  The Service provider has delivered tools, including special tools, test equipment, standby equipment, and similar items.  The Service provider has submitted all protocols, API’s and interfaces used within ITMS

Conducting the Survey

Upon receipt of the request for initial survey, SMC will prepare a listing of any additional work items that are outstanding.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 149 of 178 Final Survey Pre-Requisites The Service provider shall perform the Work necessary to complete and correct the items noted during the initial survey. The Service provider shall provide written notice to SMC that the items have been completed and ITM is ready for final survey. Conducting the Survey Upon receipt of the notice, SMC will schedule a final survey to verify that all of the Work items have been completed satisfactorily. SYSTEM DELIVERABLES ITM deliverables provided by the Service provider shall include all work required to deliver the System and System Components in accordance with this Specification and Agreement. Manuals, Training, and Training Tools The Service provider shall provide manuals, training, and training tools for the proper operation, maintenance, and repair of ITM equipment’s and applications. Delivery of the manuals, training, and training tools shall be accomplished per the Service provider-provided and SMC-approved schedule. Design Submittals The Service provider shall provide preliminary and final design submittal packages, as well as individual design details for all elements specified herein. The Service provider shall provide detailed cut-over plans and procedures. All submittals shall be in both hardcopy and electronic format. As Built Documentation The Service provider shall provide As Built Documentation. Delivery of the As Built documentation shall be accomplished per the Service provider-provided and SMC-approved schedule. All as-built documentation shall be provided in both hardcopy and in electronic format. Monthly Status Reports Monthly status reports shall be submitted to SMC on the 7th of each month detailing the previous month’s progress. The monthly status report shall contain a description of the activities and accomplishments, an updated schedule showing the progress, and any issues or concerns. Service provider format is acceptable. Test Plans/Procedures and Test Results Service provider shall provide all Test Plans/Procedures required for the ITM project and the Test Results. The Test Plans/Procedures and Test Results format shall be submitted to SMC for approval. System Support Prior to System Acceptance

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 150 of 178 Support for the maintenance and operation of installed ITMS subsystems shall be provided after incremental acceptance and prior to System Acceptance. It is SMC’s intent to begin operating ITMS after completion of the first incremental acceptance. • Support shall be provided on-site at SMC during testing and cut-over of Equipment on a continuous basis. • Support for in-service ITMS Equipment shall be provided twenty-four hours per day, seven days per week. A request by SMC for assistance shall be answered within SLA parameters as required by SMC. Post System Acceptance The Service provider shall provide end-to-end support during the contract period as mentioned in part -1 of this RFP.

5.22.3. QUALITY ASSURANCE

The Service provider shall submit to SMC within 07 days of the Notice-To-Proceed (NTP) or LOI a comprehensive Quality Assurance (QA) Program Plan designed to ensure the quality of all activities, including design, purchasing, inspection, handling, assembly, fabrication, testing, storage, shipping, and warranty/repair work. The plan shall describe all quality control procedures of the Service provider and any sub-suppliers. The Service provider shall conduct regular inspections in accordance with guidelines defined by the QA Program Plan. Project work shall not commence until the Quality Assurance and Control Plan relating to such Work has been accepted by SMC. The Service provider shall update the QA Program Plan as necessary, when any deficiencies in the Work are discovered. SMC will, at its own discretion, perform QA monitoring of work done under this Contract, including monitoring of the Service provider’s or Subservice provider’s QA activities. Upon request, the Service provider’s QA records shall be made available to SMC for inspection. Such QA activities performed (or not performed) by SMC shall not reduce nor alter the Service provider’s QA responsibilities or its obligation to meet the requirements of this document. At any time during the manufacturing process, SMC may choose to visit the Service provider's facility or a Subservice provider's facility during normal working hours to audit the manufacturing and quality control processes. Technical Documents

A key component of the ITMS implementation is the accuracy and value of all deliverables. The technical documents prepared by the Service provider during the course of this project will include design reports, installation drawings, test plans, test reports, progress reports, and other technical memos. A review process shall be established by the Service provider to assure all System Components are checked for accuracy, correctness, uniformity, and compliance with standards of practice. The various tiers of the review cycle are detailed below:

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 151 of 178  The Service provider’s Project Manager shall review project products for adherence to the standards of care common to the profession.  The Service provider’s Project Manager shall be responsible for assigning qualified professionals to check all work products for accuracy, uniformity, and clarity. Responsibility for interface, control, and integration of disciplines into a uniform and coordinated document set is also included in this role.  The Senior Technical Staff Member and individuals assigned as technical discipline leaders within the Service provider team shall provide another review. The reviews shall be initiated by the Project Manager and shall focus on a technical discipline review of selected project products.  SMC will provide a final review. This review will occur only after the Service provider’s internal review cycles have been completed. When review comments result in a change to any technical document, the Service provider’s Project Manager shall be responsible for change coordination and document back-check. In addition to the formal and on- going quality control review, timely coordination meetings with all project staff shall be held to provide for interdisciplinary liaison and interface coordination. These meetings shall be utilized to schedule work assignments, identify and resolve coordination issues, and track progress associated with any problems encountered and their resolution.

Document Management Due to the substantial amount of documentation involved in this project, Service provider shall work with SMC’s Project Manager to develop and submit to SMC a Documentation Management System (Open Source). The Document Management System shall include an organized electronic library of all versions of all submittals and a log of the contents. This shall be completed within 30 days after Notice-to-Proceed. SMC and the Service provider shall mutually agree on a documentation file index that shall provide an overall methodology for referencing documents generated in the course of the project. File type and organization of electronic versions of documentation shall be mutually agreed on by SMC and Service provider. All subsequent documentation shall be referenced to the file index, and Service provider and SMC shall mutually maintain the file index in current condition so as to show all documents that have been generated and their status. Documentation in the DMS should be readily available to SMC’s Project Manager, designated personnel within the Service provider’s organization, ITMS Consultant, and SMC-designated additional personnel. Security methods shall be available to restrict access by others. System Components The Service provider shall conduct regular inspections and audits in accordance with guidelines defined by the QA Program Plan. The Service provider’s Project Manager shall establish a quality assurance process and be responsible for assigning qualified professionals to check all system Components for compliance with the ITMS Specifications and consistency in production quality. This quality assurance program shall supplement the formal testing requirements to verify that:

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 152 of 178  Prior to installation, all System Components delivered by the Service provider shall pass rigorous screening that complies with standards of practice.  All delivered System Components shall be tested after installation. Testing shall include hardware and software interface tests. Manufactured Products The Service provider shall utilize products manufactured by companies that utilize formal, documented quality assurance practices that meet or exceed the standard of care established by the industry. The Service provider shall proactively monitor each supplier’s quality system. Quality systems that conform to ISO/CMMI practices are preferred or as may be relevant to product type by international standards. MANUALS

This section identifies the manuals to be provided to support training and give on-going documentation needed for SMC staff to manage, maintain, and expand the ITMS. GENERAL REQUIREMENTS FOR MANUALS Development Process The Service provider shall prepare a complete plan for providing the manuals described herein. The plan shall include at least the following:  Service provider shall submit for approval the outline of each manual as a part of the Preliminary Design Review.  Service provider shall develop and submit a draft version of each manual submitted with the Final Design Review.  Service provider shall deliver one complete set of manuals prior to the start of the acceptance testing.  Service provider shall incorporate information gathered during installation and acceptance testing, throughout the maintenance and warranty period into the manuals for the updated and final submittals. Content Manuals shall contain all of the information material required to support the area of activity. All Manuals All manuals shall:  Be in concise form, with minimal redundancy.  Be organized in clear, logical fashion, and indexed and tabbed for rapid access.  Be in English.  Be written for comprehension by persons with a high school education.  Contain table of definitions for all abbreviations and special terms.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 153 of 178 All Operations Manuals All operations manuals shall contain:  Instructions on navigation from one function to another.  The meaning of all display symbols and labels.  The meaning and interpretation of all alarms and messages, and the recommended remedial action for each alarm and message.  A reference card defining each cursor command, control key, and status indication. All Equipment Maintenance Manuals All Equipment maintenance manuals shall contain:  A section on safety procedures and precautions necessary to prevent damage to equipment, injury to personnel, and unsafe operational conditions.  A section with an overview of the test equipment and tools necessary to troubleshoot and maintain ITMS equipment’s.  Wiring diagrams and physical layout drawings for all equipment  A section addressing the intervals and procedures for all preventive maintenance including level adjustments and cleaning. Medium and Formats for Delivery Hardcopy The Service provider shall deliver to SMC the manuals for all sub-systems in hardcopy form, with appropriate binding and labeling. Manuals shall be designed for continuous, long-term service in a maintenance shop or vehicle environment.  Manuals shall lie flat when opened  Pages shall be printed on both sides.  Manuals shall permit adding and replacing pages.  Covers shall be oil, water, and wear resistant. Softcopy In addition, the Service provider shall deliver to SMC in electronic form all manuals and manuals components that are developed by the Service provider, or by vendors in response to the requirements of this Contract.  The electronic form shall consist of two good copies of each final manual on an electronic storage medium (CD-ROM or other approved media).  The format of the storage medium shall be one that is widely used and easily available to SMC.  The manuals shall be stored as MS Word, Portable Document File, or other SMC- approved format.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 154 of 178 BUS OPERATORS MANUAL The Service provider shall provide a manual for bus operators. The manual shall provide a clear and concise description of operator interface with ITMS and related SMC operating policies and procedures. It shall include:  Overview of the ITMS System  On-Bus Subsystem Description  How the Bus Operators are to perform all communications and bus fleet management functions provided at the Bus Driver Console.  Procedures for wireless calls.  Procedures for sending canned messages and receiving text messages.  Procedures for SOS.  Procedures for logon/logoff.  Help guide for functional failures and problems.  Pocket size Reference Card. SUPERVISOR MANUAL The Service provider shall provide a manual for supervisors. The manual shall provide a clear and concise description of supervisor interface with ITMS and related SMC operating policies and procedures. It shall include:  Overview of the ITMS System  On-Bus Subsystem Overview  Procedures for radio calls using mobile or as applicable.  Procedures for sending and receiving text messages.  How the supervisors are to perform all communications and bus fleet management functions provided at the CCC.  Help guide for functional failures and problems DISPATCH CENTER DISPATCHER AND SUPERVISOR MANUAL The Service provider shall provide a manual for Dispatch Center dispatch supervisor, dispatchers, and supervisors performing dispatch duties. The manual shall provide a clear and concise description of the ITMS operator interface for Dispatch Center dispatchers and supervisors for all console functions provided, including normal call, messaging, and schedule and route adherence functions. It shall include:  ITMS Overview  On-Bus Subsystem Overview  CAD Subsystem Description  How the dispatchers and supervisors are to perform all communications and bus fleet management functions provided at the dispatcher consoles.  How the Dispatch Supervisor can assign work assignments.  How to manage work assignments, the work queue, and incident reports at their various stages.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 155 of 178  How to perform rudimentary remedial action for limited-scope failures, including: shutting down and restarting console processors, shutting down and restarting console-based software processes, and replacing printer paper, restarting printers, restarting printer queues. Depot SUBSYSTEM USER MANUAL The Service provider shall provide a manual for users of the depot Subsystem. The manual shall provide a clear and concise description of the ITMS operator interface for depot Subsystem users for all console functions provided, including:  ITMS Overview  Depot Subsystem Description  On-Bus Subsystem Overview  How the Depot Subsystem functions are provided.  How the Depot Subsystem users are to perform all communications and fleet management functions provided at the depot Subsystem workstations.  How to perform rudimentary remedial action for limited-scope failures, including: shutting down and restarting console processors, shutting down and restarting console-based software processes, and replacing printer paper, restarting printers, restarting printer queues. VEHICLE COMMUNICATIONS MAINTENANCE MANUAL The manual shall provide a logical structure and organization for the maintenance manuals provided by the manufacturers of the On-Bus subsystem communication equipment, and shall provide any necessary information to supplement them to fulfill the requirements of this section. Manuals shall include the following topics, as a minimum:  ITMS Overview,  On-Bus Subsystem Description  Communication Subsystem Description  How to identify the source of a problem to a specific replaceable element. Provide a logical procedure for isolation a problem.  How to replace an element. Provide detailed procedure, or reference to a manufacturer manual detailed procedure, for removal and replacement of each on bus subsystem element. This shall include setting and verification of options, programming, and testing of the replaced unit and associated equipment to verify correct On-Bus subsystem operation.  Verification of correct operation of the repaired on-bus subsystem. FIXED COMMUNICATIONS MAINTENANCE MANUAL The fixed communications and radio subsystem maintenance manual shall complement the maintenance training provided. The manual shall supplement the maintenance manuals provided by the manufacturers of the fixed radio subsystem equipment. The manual shall provide a logical structure and organization for the maintenance manuals provided by the manufacturers of the On-Bus subsystem radio equipment, and shall provide any necessary

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 156 of 178 information to supplement them to fulfill the requirements of this section. Manuals shall include the following topics, as a minimum:  ITMS Overview  Radio Subsystem Functional Description  System diagnostic procedures  Identification of the source of a problem to a specific replaceable element, provide a logical procedures for isolating a problem. Provide a description of self-diagnostic features and system administrator reports.  How to replace an element. Contain detailed procedure, or reference to a manufacturer manual detailed procedure, for removal and replacement of each fixed radio subsystem element.  Verification of correct operation of the repaired radio subsystem. Include instructions for setting and verification of options, programming, and testing of the replaced unit and associated equipment to verify correct operation.  This requirement shall apply only if the Service provider provides the fixed data radio system. IN-VEHICLE EQUIPMENT MAINTENANCE MANUAL The manual shall focus on guiding technicians in verifying the presence of a failure and performing first echelon replacements. Manuals shall include the following topics, as a minimum:  ITMS Overview  On-Bus Subsystem Functional Description  Identification of the source of a problem to a specific replaceable element, provide a logical procedures for isolating a problem. Provide a description of self-diagnostic features.  How to replace an element. Contain detailed procedure, or reference to a manufacturer manual detailed procedure, for removal and replacement, and verification of first echelon replaceable elements.  Verification of correct operation of the repaired On-Bus Subsystem. Include instructions for setting and verification of options, programming, and testing of the replaced unit and associated equipment to verify correct operation. DISPATCH CENTER AND Depot WORKSTATION MAINTENANCE MANUAL The manual shall focus on guiding technicians in identifying the source of a problem to a specific replaceable element, replacement of the element, and verification of correct operation of the repaired subsystem. Manuals shall include the following topics, as a minimum:  ITMS Overview  CAD Subsystem Functional Description  Depot Subsystem Functional Description

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 157 of 178  Identification of the source of a problem to a specific replaceable element, provide a logical procedures for isolating a problem. Provide a description of self-diagnostic features and reports.  How to replace an element. Contain detailed procedure, or reference to a manufacturer manual detailed procedure, for removal and replacement or repair of an element.  Verification of correct operation of the repaired ITMS Workstations and Dispatch Center equipment. Include instructions for setting and verification of options, programming, and testing of the repaired unit and associated equipment to verify correct operation. COMPUTER SYSTEM ADMINISTRATOR MANUAL The Service provider shall provide a system administrator’s manual that provides a clear, organized description of all of the configurable computers of ITMS, the tools and procedures for managing their configuration, and for diagnosing their performance and problems. It shall contain at least the information described below.

Fleet Management Reporting This section shall provide details on the standard reports that are automatically generated by ITM and instructions on how to perform custom queries to generate ad-hoc reports. ITMS Computer Configuration The configuration section shall contain at least:  A high level and detailed description of computer configurations and interfacing equipment at the Dispatch Center, bus depots, fixed communication site(s), mobile units, configuration of ITM LAN/WAN logical and physical entities, and connections to SMC LAN/WAN.  Description of operation of interfaces to connected systems (SMC LAN/WAN, Vehicle Health System, depot Subsystem.)  A listing and functional description of software components for each computer. Configuration Management and Operation The Configuration Management and Operation section shall contain at least: Procedures and tools for defining ITMS users, function access and privileges, and console function assignments. Computer startup, interconnected systems communications restart, and shutdown procedures. Overview and details of procedures and tools for installing and verifying new software and rolling back old software for Dispatch Center, Computer Subsystem, Depot Subsystem, fixed communication site(s), and mobile units. Monitoring, maintaining, archiving, and restoring the ITMS database. Maintaining, updating AVLS databases.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 158 of 178  Procedures for modifying the Route and Stop databases.  Procedures for importing updated route and schedule databases.  Monitoring, analysis, and optimization of computer/LAN/WAN performance Manual shall include procedure for configuring ITMS for each separate fleet, setting access privileges for SMC personnel and SMC service provider personnel.

Diagnostics and Troubleshooting The Diagnostics and troubleshooting section shall contain at least the following:  Equipment and operating system error messages and diagnostics, with remedial action for each.  Tools and procedure to troubleshoot equipment and software problems on all ITM equipment  Procedures to manage and diagnose interfaces with connected systems. COMPUTER MANUAL The Service provider shall provide a programmer’s guide for each of the programmable computers in ITM. For each, the guide shall:  Provide an overview of software organization.  Provide internal / external interfacing data format, semantics, and protocols for all the equipment’s, software and hardware supplied.  Define internal modules, data interfaces, tasking, and considerations for timing, priorities, and resource use.  Identify and detail use of programming and database maintenance tools used to create the software.  Include complete documentation of non-application components such as operating system, communications handlers, database, and report generators.  Detail the procedures for building and managing software configuration.  Describe the metrics embedded in ITM to evaluate its performance.  Identify the error conditions detected within the software, and the messages or indications for those conditions.  Identify parameters used to adjust ITM operation

5.23. ITMS SLA Requirements - Service Level Agreement

5.23.1. Management of Services/General principles

Definitions

In this Agreement, unless the context otherwise requires:

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 159 of 178 “Account Manager” means the ITMS Service Provider employee designated by ITMS Service Providers to deal with the Customer’s account as notified from time to time to the Customer;

“Call Close Time” means in respect of any Fault the time at which that Fault is cleared and notified to the Customer

“Call Open Time” means the date and time which is recorded by the ITMS Service Provider Representative as the time the Fault Call is logged;

“Customer” means an artificial person created under the law(SMC) whose order for Services is accepted by ITMS Service Provider in accordance with the Terms of Service Provider Agreement;

“Customer Components” means such of the Components as are delivered to the Customer;

“Customer Representative” means the individual nominated by the Customer from time to time to represent the Customer in all matters relating to the Customer’s and the End User’s use of the Services;

“ITMS Service Provider Representative” means any employee of ITMS Service Providers or its sub-contractors nominated by ITMS Service Provider from time to time to be responsible, in liaison with the Customer Representative, for delivering the Services;

“Fault” means any recorded failure of any part (s) of the Services;

“Fault Call” means any telephone call, fax or e-mail from the Customer to the ITMS Service Provider Representative;

“Fault Duration” means the length of time between the Call Open Time and the Call Close Time for a Fault or, if any Fault is re-opened after the Call Close Time, the length of time between the Call Open Time and the final Call Close Time;

“Hours of Cover” means the hours of cover specified in Appendix A below;

“Response Time” means the length of time between the Call Open Time and the time at which an engineer arrives at the Customer’s premises or any other premises agreed between the parties with the aim of restoring the normal operations of the services to the customer including rectifying any Fault;

“Service(s)” means the service(s) provided by ITMS Service Provider

“Time to Restore” means the target time to restore specified for each Component;

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 160 of 178 “Technical Helpdesk” means those ITMS Service Provider Representatives available to respond to Customers’ requests for assistance from time to time;

“Terms of Business” means ITMS Service Provider’s standard terms and conditions in force from time to time.

5.23.2. Scope of SLA

This SLA describes the target performance levels which ITMS Service Providers shall aim to deliver for the Services, ITMS Service Provider’s procedures for managing unavailability of the Services, and the penalties which will be applied if ITMS Service Provider fails to deliver any service performance targets in accordance with this Agreement.

Targets and availability Because of the varying nature of the Components each Component has an individual target set for performance and availability. However SMC shall expect ITMS Service Provider to guarantee 99.5% availability of the Services in general.

Service monitoring ITMS Service Provider will put in place a monitoring mechanism to monitor all Components of ITMS. ITMS Service Provider through its monitoring system should provide data which is sufficient to allow analysis and reporting of Component performance and availability to the detail and frequency described in this Agreement.

ITMS Service Provider will additionally use data gathered from its monitoring of the Components to inform & take approval from competent authority its decisions in respect of any changes to its infrastructure which it, in its sole discretion, deems necessary to maintain or improve the availability and performance of the services delivered to SMC.

Performance reporting ITMS Service Provider shall record performance and availability of each of the Customer Components and report this information to the Customer, as described in below. Where periodic account reviews are agreed by both parties to be held between the Customer and ITMS Service Providers, these reports will form an agenda for such reviews. If the Customer Components include access to ITMS Service Provider’s service system, ITMS Service Provider will enable the Customer to view the reports via ITMS Service Provider’s service system.

Complaints procedure If the Customer has any complaints about the way in which ITMS Service Provider’s support facilities are being managed, the Customer Representative shall initially contact ITMS Service Provider, in writing.

Non-delivery of Services

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 161 of 178 Planned suspension ITMS Service Provider will, on occasion, need to suspend part(s) of the Services in accordance with the Terms of Business. In such cases, the unavailability of any part(s) of the Services will not constitute a Fault. Where practical, any such suspension will be arranged to fall outside the Customer’s normal working hours and ITMS Service Provider shall use its reasonable commercial endeavours to see that the following procedure is followed:

ITMS Service Providers should by e-mail or other means (relevant) give the Customer Representative reasonable notice of the time and duration of the suspension;

After completion of the planned work, ITMS Service Providers will report the outcome to the Customer Representative by updating the call management system on ITMS helpdesk system / incident management system; and

All work at the premises of Customers or End Users will be carried out in accordance with both local and national health and safety regulations.

Service failures Any Faults arising from failures of components which are not Customer Components or failure of any End Users’ system (for instance, the failure of a local telecommunications line) shall not be a Fault for the purposes of this Agreement.

Managing Service failure

Fault Calls

Notification of faults The SMC Representatives or users will report a Fault during the Hours of Cover by notifying ITMS Service Provider’s Technical Helpdesk by telephone, email, Service System or any other means identified as call logging point.

Setting Fault priority

The priority of a Fault reported by the SMC will be categorised by agreement between the SMC and the ITMS Service Providers Representative taking the relevant Fault Call. In the absence of agreement SMC will determine the Fault priority. Faults will generally be categorised as follows:

5.23.3. Severity Definition Chart

Support Maximum Criteria Resolution Category Response Time

Critical The system is unable to 90 Minutes Escalated after 15 Minutes be used for normal this period to –Stage 2 business activities.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 162 of 178 There is certainty of Escalated after 1 hour financial loss or (cumulative) to - Stage 3 operational inefficiency to SMC. Escalated after 2 hours (cumulative) to - Stage 4

Urgent There is a problem with 3 Hours Escalated after 1 Hour part of the system, this period to - which impacts on SMC’s decision making. No Stage 2 viable Work around is Escalated after 4 hours available. There is a (cumulative) to - likelihood of financial or operational loss. Stage 3

Escalated after 5 hours (cumulative) to -

Stage 4

High The efficiency of users 6 hours Escalated after this 2 Hours is being impacted, but period to - has a viable workaround. Stage 2 Escalated after 8 hours (cumulative) to -

Stage 3

Escalated after 9 hours (cumulative) to -

Stage 4

Medium A low impact problem 12 Hours Escalated after 8 Hours that affects the this period to - efficiency of users but has a simple Stage 2 workaround Escalated after 14 hours (cumulative) to -

Stage 3

Escalated after 16 hours

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 163 of 178 (cumulative) to -

Stage 4

Low A fault, which has no One Week 8 Hours particular impact on processing of normal business activities.

Recording the Fault

The ITMS Service Providers Representative will ask SMC Representative for information about the Fault to obtain a clear description of its nature and the circumstances in which it occurred and confirm eligibility or non-eligibility of support for the Fault.

Faults initially reported by ITMS Service Provider Notification of Faults ITMS Service Provider will notify the Customer Representative, either by e-mail, telephone or other identified methods, within a reasonable period of time of any Fault of which it is aware, unless that Fault is cleared before it can be notified to the Customer Representative.

Setting the Fault priority ITMS Service Provider will allocate a priority to any Fault notified by the Customer Representative in accordance with the Fault designations set out in Table 1 above. The Customer should notify ITMS Service Provider’s Customer Services Manager by telephone if it disagrees with the allocated priority.

Recording the Fault report ITMS Service Provider will record the date and time at which ITMS Service Provider notifies the Customer of any Fault and the other details.

5.23.4. Fault rectification

Fault handling and escalation ITMS Service Provider will allocate to any Fault a Response Time in accordance with the details set out in Table below. Faults which remain unresolved at the end of the Response Time will be escalated as shown in Table below. Descriptions of the activities associated with each stage are shown in Tables below.

Stage Response Activity

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 164 of 178 The ITMS Service Provider Representative on the Technical Helpdesk will acknowledge the Fault Call and advice on tests and actions required in order to resolve the problem, consulting as necessary with other ITMS Service Provider Representatives and third parties. Should Stage 1 the ITMS Service Provider Representative be unable to resolve the problem or provide an action plan suitable to the Customer, the Fault Call will be escalated to ITMS Service Provider’s of respective ITMS services Operations Team and ITMS Service Provider’s Account Manager will also be informed.

ITMS Service Provider’s Operations Team will determine a suitable action plan and agree it with the Customer. Where appointed, the Account Managers of respective ITMS services will be notified. ITMS Stage 2 Service Provider’s Implementation Team may also be involved at this point and third party manufacturers and/or ITMS Service Providers may be contacted for additional technical support.

If unresolved following Stage 2, the Fault will be escalated to ITMS Service Provider’s Customer Services or Operations Managers, as appropriate. They will involve all necessary resources, Both internally Stage 3 and externally, to ensure an acceptable resolution for the Customer. ITMS Service Provider’s Technical Services Director will also be informed.

If unresolved following Stage 3, then ITMS Service Provider’s Technical Services Director will take responsibility for the call and involve all necessary senior and management resources, Both Stage 4 internally and externally, to ensure an acceptable resolution for the Customer. ITMS Service Provider’s Managing Director will be appraised of the situation.

Response Times will start to run at the Call Open Time. The ITMS Service Provider Representative may amend any Fault priority by agreement with the Customer. All telephone calls may be recorded or monitored for training purposes.

Should the same Fault re-occur within 48 hours, the original call will be reopened with the same log number and the same Response Time will apply from the time that the call is re-opened.

ITMS Service Provider reserve the right to ‘stop the clock’ should a third party ITMS Service Provider be unable for any reason to issue or release pertinent details or information.

Progress recording Mechanism for notification of progress, escalations and resolution

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 165 of 178 Appendix below sets out how ITMS Service Provider will notify the Customer Representative about Fault progress, escalation and/or resolution. In the event that the Customer Representative cannot be contacted by one of the methods set out in Appendix below, the ITMS Service Provider Representative shall be entitled to use any other method that it deems appropriate for any such notification.

In respect of any priority one Fault, the Customer Representative will, upon request, be updated with regular progress reports during the Hours of Cover. Such progress reports, where issued, will not be produced more frequently than hourly.

General Assistance ITMS Service Provider will aim to provide assistance to the Customer in the resolution of difficult “end-to-end” Faults. This will include incidents where the location of a particular Fault is unclear, and may not eventually lie in ITMS Service Provider’s area of supply. Such incidents may require the active co-operation of ITMS Service Provider, the Customer and third parties, in order to undertake the tests necessary for successful Fault isolation and resolution. ITMS Service Provider reserves the right to charge for time and materials where the Fault does not lie within the Service boundaries described in, Appendix below.

Closing a Fault Any Fault will remain open until the Call Close Time is notified to the Customer.

In the event that the Customer reports that a Customer Component remains out of operation after the Call Close Time has been noted, then the Fault will be re-opened.

Guaranteeing a Fault Duration Time Although ITMS Service Provider will use its reasonable commercial endeavours to clear any Fault within the shortest possible time, the Customer should be aware that it is impossible for ITMS Service Provider to guarantee any time limits.

Recurring and intermittent faults ITMS Service Provider will use its reasonable commercial endeavours to record the cause of all Faults and monitor them to try and isolate recurring or intermittent Faults.

ITMS Service Providers Representative may request certain Fault details from the Customer in order to rectify a recurring or intermittent Fault. The Customer may be asked to record certain information relating to recurring or intermittent Faults; the Customer must comply with any such request.

A Fault may be closed by ITMS Service Provider if it is found to be and recorded as “no fault found” or “right when tested,” even if an investigation is ongoing to isolate a recurring or intermittent fault.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 166 of 178 5.23.5. Propose SLA Structure

SERVICE LEVEL ACCEPTANCE (SLA) MATRIX AND PROPOSED PENALTY AMOUNT FOR DEFAULT/S

Minimum Service levels to be maintained for ITMS system operations by the ITMS Service Provider.

5.23.6. Service Level Agreements for Handheld Ticketing Terminal

Measurement S Measuring Module Service Level Description Measured by l Duration Baseline Lower Critical Minimum Performance Breach

HTT available for entire shift, Time Availability/Up time of HTT (with log from HTT, 1 HTT respect to allocated schedule in a Daily 99.90% 99% to 99.90% < 99% Data transferred day) to ITS server from GPRS Adequate memory on devices for HTT Report on 2 HTT fare tables, rules, transaction data Quarterly 100% 80% < 80% schedule related (No of Schedules of Depot) data loaded

Replacement Time of Malfunction Issue logged in HTT Daily (01/02) (03/05) (05/07) 3 HTT (Major (Days)/Minor (Days)) Helpdesk app.

Periodic field/lab 9 to 15 4 HTT Time/Ticket Print (Seconds) Quarterly 3 to 4 sec 5 to 8 sec testing/conductor sec reports HTT Battery Performance [No of Tickets/Full charge of Battery or 500 Periodic field/lab 5 HTT Quarterly 800 Tickets 600 Tickets 12 Hours (Per-Shift)/Schedule in Tickets testing case of Night out] SLA with ISP, 6 HTT Availability of GPRS Network Daily 98% 90% to 98% <90% NMR

Replacement of faulty machine Issue logged in 7 HTT Daily 2 Hours 6 Hours 12 Hours buttons due to constant use Helpline app. Permissible/day; No. of restarts of HTT by the 8 HTT Daily 0/day 1/day 2/day Conductor report conductor and HTT Log Extra HTT - with SP (@ each 9 HTT Quarterly 10% 5% 2% SMC to decide Depot)

1) An investigation will be conducted by SMC into the reason as to why the machine was not available for at least "XX" HTT days in that month. 2) It will be investigated whether that machine was non-functional due to mishandling/mismanagement or due to any HTT other reason. The investigation will be completed within 7 working days of filing of complaint from SP and based upon the results of the investigation further action will be initiated by SMC.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 167 of 178 5.23.7. Service Level Agreements for AVLS Units

Measurement Service Level Measuring Sl Module Measured by Description Duration Baseline Lower Critical Minimum Performance Breach

Availability of Operational Vehicle Mountable Units. Unit is 99% -to- AVLS device sending GPS data 1 AVLS Daily 99.90% < 99% operational when it is 99.90% to server with time stamp able to support providing necessary data (“VTS Availability” is defined as the proper functioning of the AVLS device with all its features & functions along with required AVLS Central System 99% -to- hardware & software as per the 2 AVLS Monthly >99.9% < 99% Availability 99.90% functional & technical specifications defined in the bidding documents. GPRS connection availability is excluded from this) Reliable without any loss of data, Seamless 95% -to- 3 AVLS connectivity when Monthly >97% <95% NMR report from AVLS device 96.99% moving between Bus Stops {GPRS Network} Each AVLS Unit should ensure maximum 10 95% -to- Hourly Data Packet received to 4 AVLS Monthly >97% <95% second update time for 96.99% ITS server report vehicle location Replacement Time of Issue logged in Helpline app, 5 AVLS Daily 1 day 2 day 4 day Malfunction AVLS Unit NMR report from AVLS device

5.23.8. Service Level Agreements PIS

Measurement Service Level Measuring Sl Module Measured by Description Duration Baseline Lower Critical Minimum Performance Breach

(“PIS Display Availability” is defined as the proper functioning of the PIS Passenger Information with all its features & functions (service) displays shall along with required hardware & be available for all 1 PIS Daily > 97% 97% -to- 95% < 95% software as defined in the bidding passengers to view documents. PIS displays showing without delay in the distorted/ partial/ non-readable frequency mentioned. messages/ information shall also be considered as unavailable) 1. By interface provided to CCC- Operators. Issue logged by CCC Accuracy of forecast Staff/ /Conductor/Driver/Commuter. arrival at bus-stops (ETA 2. “ETA Accuracy” is calculated for 2 PIS Daily 99% 99% – 98 % < 98% Accuracy from AVLS each hour at a given location as the System) difference between the expected and actual arrival times. This should be within +1 minutes, predicted 15

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 168 of 178 minutes before the actual measured arrival time. Screen refresh of panels < 10 > 10 to < 20 > 20 Information displayed/refreshed 3 PIS Daily at bus stations seconds sec sec with new content from server log Connectivity availability Log from data card usage, NMR 4 PIS Daily 98% 98% to 90% <90% over Data card/BB report for GPRS connectivity PIS Server availability Default value 10 sec or as soon as and On time >10 & <30 > 30 5 PIS Daily < 10 sec the bus touches the Geo Fence of synchronization of data sec sec Bus stop. from the server Display of Additional Time stamp captured from PIS Text messages 6 PIS Weekly 100% 99.90%-95 % < 95% Control module and time stamp (Advertisements/free from Display device texts) Correctness of Display fields - Line number & Destination, Departure By interface provided to CCC- Time (absolute/ 7 PIS Daily 100% 99.90%-95 % < 95% Operators. Issue logged by CCC Staff relative), Via- /Conductor/Driver/Commuter destination, Trip-related text message, Arrival time Replacement Time of 9 PIS Daily 1 day 2 day 4 day Issue logged in Helpdesk app. Malfunction PIS display

5.23.9. Service Level Agreements for ITMS Application

Measurement Service Level Measuring Sl Module Measured by Description Duration Baseline Lower Critical Minimum Performance Breach

Report Generation ITMS 1 Time(Query time BI Daily <10 sec 30 to 90 sec > 90 sec Query time Application Tool) ITMS Total Application 99% -to- 2 Application Monthly > 99.90 % < 99% Report from EMS Availability 99.90%

ITMS Grievance and > 12 3 Application Complaints Monthly < 7 Days 08 to 12 days Helpdesk ticket days settlement ITMS Client Access - 4 Application Daily 99.90% 99.89% to 98% < 98% No of Hits/Day 24*7*365

ITMS Predetermined Report (Incl Database log, Server 5 Application Daily < 7 Secs 08 to 20 sec > 20 sec Exception Reports) query log Generations ITMS Query based Report Database log, Server 6 Application Daily < 15 Secs 16 to 30 sec > 30 sec generations query log

Response time for ITMS data input after 7 Application pressing the enter Daily < 5 sec 06 to 20 sec > 20 sec Server Log (save) key to display a response.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 169 of 178 ITMS Response time for 8 Application Daily < 5 sec 06 to 20 sec > 20 sec Server Log on‐line inquiry

ITMS Depot attendance & Manpower Depot manager report 9 Application Daily 3 days 5 days 7 days Deployment Resource Deployment Timeline to be submitted 1. Helpdesk Tickets

2. “DOA & EIA System Availability” (“DOA System Availability” is defined as the proper functioning of the Depot with all applicable ITMS Depot Offline & EIA features & full 10 Application Application Daily 99.95% 99.94% to 98% < 98% functionality along with Availability the required applicable hardware associated with Depot including but not limited to Workstation, Printer, Document Scanner & software as per the functional & technical specifications defined in the bidding documents.)

5.23.10. Service Level Agreements for Data Centre

Measurement Measuring Sl Module Service Level Description Measured by Duration Baseline Lower Critical Minimum Performance Breach

IT Infrastructure for production environment should be designed in such EMS Report & Server 1 DC a way that the Monthly 99.50% 99.49% to 97% < 97% Log infrastructure shall be made available % without single point of failure. The system shall be operational, reliable, and EMS Report & Server 2 DC available for business Monthly 24*7*365 - - Log processes and mission – critical operation. CPU utilization must not EMS Report & Server 3 DC cross beyond % at any Monthly 75% 76% to 80% > 80% Log time of processing

Resumption of online ITMS 45min to 60 4 DC Monthly <45 min > 60 min Network log services (Per Event) min

Local Area Network 5 DC Daily 99.99% 99.98% to 98% < 98% Helpdesk ticket availability

Fixing a bug or issue (Low/ 16 / 12/ 8 - 12 16 / 12/ 6 DC Monthly < 11 / 8 / 4 Hours Helpdesk ticket Medium/ High) /8/ 4 Hour 8 Hour

Website uptime with all 7 DC Monthly 99% 99% to 98% <98% Helpdesk ticket the features

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 170 of 178 Point to Point (P2P) Network log & SLA 8 DC Monthly 98% 98% to 90% <90% Communication with ISP ITMS Application Log from ITS server 10 DC Daily 99% 99%-98% <98% Availability Uptime/Downtime Functional requirements > 75 Application Update 11 DC Monthly < 60 Days 60 to 75 days upgrade (No of Days) days Log Minimum Concurrent Log of number of 12 DC Connects to ITMS Daily >100 99 to 75 < 75 Hits per day (Internal) Minimum Concurrent Log of number of 13 DC Connects to ITMS Daily > 5000 4999 to 4500 < 4500 Hits per day (External)

Minimum Connects to Log of number of 14 DC Daily > 200 199 to 175 < 175 ITMS (Internal) Hits per day

Minimum Connects to Log of number of 15 DC Daily > 15000 14999 to 14000 < 14000 ITMS (External) Hits per day

Availability of systems at 16 DC Daily 99% 98.99% to 95% < 95% Report from EMS Data Centre Average transaction Capacity of the Database Average size from all field 17 DC Server (Service Daily - - transaction/Hour equipment’s per Transactions/Hour) minute *60 Average transaction Capacity of the Application Average size from all field 18 DC Server (Service Daily - - transaction/Hour equipment’s per Transactions/Hour) minute *60 Availability of agreed 19 DC Daily 100% 99.99% to 95% <95% Report from EMS services over the internet

20 DC Network availability Daily 99% 98.99% to 98% < 98% Report from EMS

Network Latency Average 21 DC Monthly > 75 <75% to 72% <72% Report from EMS of (Milliseconds/Month)

Uptime of Back Office 22 DC Monthly 100% - - Report from EMS Servers

Time to restore back office 60mins -to- > 90 23 DC Daily < 1 Hr Report from EMS servers from failure 90mins mins Roll out of latest anti-virus report generated by definition file on work 24 DC Quarterly 98% 98% to 96% <95% antivirus software station and server being console made available by SP Roll out of latest updated 25 DC patches/fixes, version Quarterly 98% 98% to 96% <95% Patch update report upgrades Report from EMS, SMC would periodically(once a Data backup and Restore 26 DC Quarterly 99% 99%to97% <97% quarter on a random management day) tell SP to restore the data back up System Handling capacity 27 DC Monthly 99% 99%to97% <97% Report from EMS for 25% additional load

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 171 of 178 5.23.11. Uptime Calculation for the month

{[(Actual Uptime + Scheduled Downtime) / Total No. of Hours in a Month] x 100}

"Actual Uptime" means, of the Total Hours, the aggregate number of hours in any month during which each equipment is actually available for use.

"Scheduled Downtime" means the aggregate number of hours in any month during which each equipment, is down during total Hours, due to preventive maintenance, scheduled maintenance, infrastructure problems or any other situation which is not attributable to Service Provider’s (or Service provider's) failure to exercise due care in performing Service Provider’s responsibilities.

The SMC would provide a maximum of 04 hours of planned downtime for the preventive maintenance (as part of scheduled downtime) per month per equipment/service.

The downtime for scheduled maintenance (patch application, upgrades – OS, Database, etc.) would need to be mutually agreed between SMC and the Bidder. To reduce this time, various maintenance activities can be clubbed together with proper planning.

"Total Hours" means the total hours over the measurement period i.e. one month (24 * number of days in the month).

Downtime Calculation:

The recording of downtime shall commence at the time of registering the call with Service Provider or Service Provider for any downtime situation for the equipment.

Downtime shall end when the problem is rectified and the application/ service is available to the user.

Down time will not be considered for following:

1. Pre-scheduled preventive maintenance and health checks (Scheduled Downtime).

2. Failover time (30 minutes) in case of cluster environment. Beyond which the service would be considered to be not available and appropriate penalty shall be imposed on the Service Provider.

3. Bug in any application which causes the non-availability of the service.

If the SMC elects to continue the operation of the machine / equipment, when a part of the machine is giving problem and leading to downtime, the commencement of downtime shall be deferred until the SMC releases the machine / equipment to the Bidder for remedial action.

a) The compliance report shall be submitted monthly, by the ITMS Service Provider. b) These compliance reports shall be verified by SMC officials or the nominated representatives of SMC. Any disputes on the compliance report shall be escalated to a

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 172 of 178 nominee of the senior management of SMC and the decision of that nominee shall be binding on both the parties. c) Elaborate list of SLA shall be furnished to successful bidder at the time of agreement stage.

d) The compliance to the SLA metrics as listed above shall be monitored on the monthly basis.

e) If SMC finds that ITMS Service Provider has breached any of the SLA Metrics more than three (3) times in a year then SMC, in its sole discretion, may terminate the Agreement in accordance with the provisions thereof. Such termination of the Agreement shall be without prejudice to any other rights available to SMC.

f) The compliance report shall be submitted along with the Monthly invoice by the ITMS Service Provider.

g) With reference to SLA of field Equipment, If the camera units are non-operational due to mishandling by SMC users and the same is verified by SMC officials, then ITMS Service Provider shall not be penalized for non-compliance.

h) These compliance reports shall be verified by SMC officials or the nominated representatives of SMC. Any disputes on the compliance report shall be escalated to a nominee of the senior management of SMC and the decision of that nominee shall be binding on both the parties.

Breach of SLA

In case the Service Provider does not meet the service levels mentioned in document, for three (3) continuous time-periods as specified in the relevant clause, the SMC will treat it as a case of breach of Service Level Agreement. The following steps will be taken in such a case:-

1. SMC issues a show cause notice to the Service Provider.

2. Service Provider should reply to the notice within three working days.

3. If the SMC authorities are not satisfied with the reply, the SMC will initiate termination process.

Exclusions

The Service Provider will be exempted from any delays or slippages on SLA parameters arising out of following reasons:-

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 173 of 178 Delay in execution due to delay (in approval, review etc.) from SMC’s side. Any such delays will be notified in written to the IT Team.

The network links if provided by a third party, in that case the Service Provider will monitor and report any problems on behalf of third party. If Service Provider notifies and SMC approves that the delay or fault was due to the third party link services then such loss will not be considered for tracking Service Provider’s SLA parameters (Also reduced from total service time).

5.23.12. Monitoring and Auditing

IT Team of SMC or appointed by SMC will review the performance of Service Provider against the SLA parameters each month, or at any periodicity defined in the contract document. The review / audit report will form basis of any action relating to imposing penalty or breach of contract. Any such review / audit can be scheduled or unscheduled. The results will be shared with the Service Provider as soon as possible. SMC reserves the right to appoint a third-party auditor to validate the SLA.

Reporting Procedures

The Service Provider’s representative will prepare and distribute SLA performance reports in an agreed upon format by the 10th working day of subsequent month of the reporting period. The reports will include “actual versus target” SLA performance, a variance analysis and discussion of appropriate issues or significant events. Performance reports will be distributed to the SMC’s IT Team.

Issue Management Procedures

General

This process provides an appropriate management structure for the orderly consideration and resolution of business and operational issues in the event that quick consensus is not reached between SMC and Service Provider. It is expected that this pre-defined process will only be used on an exception basis if issues are not resolved at lower management levels.

Issue Management Process

Either SMC or Service Provider may raise an issue by documenting the business or technical problem, which presents a reasonably objective summary of both points of view and identifies specific points of disagreement with possible solutions.

SMC and the Service Provider’s representative will determine which committee or executive level should logically be involved in resolution.

A meeting or conference call will be conducted to resolve the issue in a timely manner. The documented issues will be distributed to the participants at least 24 hours prior to the discussion if the issue is not an emergency requiring immediate attention.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 174 of 178 Management of SMC and Service Provider will develop a temporary, if needed, and the permanent solution for the problem at hand. The Service Provider will then communicate the resolution to all interested parties.

SLA Change Control

General

It is acknowledged that this SLA may change as SMC’s business needs evolve over the course of the contract period. As such, this document also defines the following management procedures:

 A process for negotiating changes to the SLA.  An issue management process for documenting and resolving particularly difficult issues.  SMC and Service Provider management escalation process to be used in the event that an issue is not being resolved in a timely manner.

Any changes to the levels of service provided during the term of this agreement will be requested, documented and negotiated in good faith by both parties. Either party can request a change. Changes will be documented as an addendum to this document and consequently the contract.

SLA Change Process

Both the parties may amend this SLA by mutual agreement in accordance. Changes can be proposed by either party. Normally the forum for negotiating SLA changes will be SMC’s monthly review meetings.

Version Control

All negotiated SLA changes will require changing the version control number. As appropriate, minor changes may be accumulated for periodic release (e.g. every quarter) or for release when a critical threshold of change has occurred.

Management Escalation Procedures

The purpose of this escalation process is to provide a quick and orderly method of notifying both parties that an issue is not being successfully resolved at the lowest possible management level. Implementing this procedure ensures that SMC and Service Provider management are communicating at the appropriate levels. Escalation should take place on an exception basis and only if successful issue resolution cannot be achieved in a reasonable time frame.

 All issues would be raised to the project management team, which is completely responsible for the day to day aspects of the implementation. The project management team shall classify the issues based on their severity level and resolve them within appropriate timelines.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 175 of 178  If project management team is unable to resolve an issue, the issue would be escalated to the top management with options/ risks detailed for decision. Top management will make decisions based on the options/ risks presented by the IT team.

5.23.13. Service Levels for Fare Gates

System Availability

The System could be required to be functional round the clock, and the availability of the System should be in excess of 99.50% of the operations time. Any other service level metrics, as might be appropriately required, would be finalized during the contract signing stage.

Service monitoring

 ITMS Service Provider will put in place a monitoring mechanism to monitor all Components ITMS Service Provider through its monitoring System should provide data which is sufficient to allow analysis and reporting of Component performance and availability to the detail and frequency described in these Conditions.  ITMS Service Provider will additionally use data gathered from its monitoring of the Components to inform & take approval from competent authority for its decisions in respect of any changes to its infrastructure which in its sole discretion, deems necessary to maintain or improve the availability and performance of the services delivered to Authority.

Performance reporting

 ITMS Service Provider shall record performance and availability of each of the Customer Components and report this information to the Customer. Where periodic account reviews are agreed by both parties to be held between the Customer and ITMS Service Provider, these reports will form an agenda for such reviews. If the Customer Components include access to ITMS Service Provider’s service System, ITMS Service Provider will enable the Customer to view the reports via ITMS Service Provider’s service system.

Complaints procedure

 If the Customer has any complaints about the way in which ITMS Service Provider support facilities are being managed, the Customer Representative should contact the ITMS Service Provider.

General Maintenance Conditions:

 The maintenance shall include both Preventive Maintenance and Corrective Maintenance.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 176 of 178  This Service Level Conditions shall cover each and every part/component of the System. The ITMS Service Provider shall examine, clean, lubricate and adjust various components/parts of the entire System including all parts and components every month and shall take necessary measures to maintain the units in proper working conditions in accordance with the Specifications in the Service Level Conditions.  The ITMS Service Provider shall supply and replace any part/components which are discovered to be potentially detrimental to the safety of the user and/or to the efficient and cost effective operation of the units and which require immediate replacement.  In case of need to replace any part/component, the ITMS Service Provider shall provide original make genuine parts/components of similar/higher quality.  In case of emergencies, the ITMS Service Provider shall respond immediately to take the necessary actions irrespective of the provisions regarding time limit in these SLCs.  The ITMS Service Provider shall be liable for any kind of damage to the user of the units caused by poor maintenance, delay in any repair/maintenance works and shall pay for the damage.  Repairs may be carried out generally during nonoperational hours.

Nature of Distress, Remedy Periods and Damages payable for Breach.

The ITMS Service Provider shall during both the warranty period and the Operation &Maintenance period attain following standards of remedy for each nature of distress specified for flap gates. In the event of the ITMS Service Provider not being able to deliver the services, damages shall be payable by the ITMS Service Provider against default in service as shown as follows.

Nature of Distress Maximum Damages payable for delay in Turnaround / restoring operations beyond remedy Remedy period period. (hours) allowed per incident

Operations not possible/ 2 0.02% of the value of the unit/s* not jammed remedied per every hour of delay.

Reader sensing issues 2 0.02% of the value of the unit/s* not remedied per every hour of delay.

Performance below capacity 2 0.04% of the value of the unit/s* not in terms of number of people remedied per every hour of delay. being able to pass per minute

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 177 of 178 Any other To be specified by 0.01% of the value of the unit/s* not the ITMS Service remedied per every hour of delay. Provider at the time of call login. *For the purposes, the value of the unit shall be the billed value of the unit.

In addition to the above, for any non-availability of the System below 99% of total operations time in hours, damages shall be recoverable separately on a pro rata basis per every hour of non-operations below 99%.

Training Requirements

Training is an important activity for the successful implementation of Work. To make the Work a success, the following training programs shall be arranged by the ITMS Service Provider from time to time depending on the requirement and understanding of the service centre operators, participating users, etc. For all these training programs, ITMS Service Provider shall provide adequate course material documents. The following are the trainings to be imparted by the ITMS Service Provider:

 ITMS Service Provider shall impart training to Authority nominated trainer staff, so that they are aware of the operations of the solution and further impart training to the relevant staff of Authority ensuring smooth running of System at the selected sites. ITMS Service Provider shall also be responsible for re-training the Authority nominated trainers staff whenever changes are made in the System and it shall be the responsibility of the ITMS Service Provider to ensure that the operators are familiar with new versions of system and its allied services.

ITMS FOR SURAT MUNICIPAL CORPORATION, GUJARAT, INDIA Page 178 of 178