Volume 2 – Scope of Work RFP Number: GSCDL-ICCC-RFP-ICT-3-2017-18 Date: 23/10/2017

REQUEST FOR PROPOSAL (RFP) for SELECTION OF MASTER SYSTEM INTEGRATOR FOR IMPLEMENTATION OF INTELLIGENT TRANSPORT MANAGEMENT SYSTEM ADAPTIVE TRAFFIC CONTROL SYSTEM, SMART POLES, SOLID WASTE MANAGEMENT, KIOSK & WAY FINDER SIGNBOARDS & INTEGRATED COMMAND AND CONTROL CENTRE (ICCC) IN GANDHINAGAR CITY

Invited by Gandhinagar Smart City Development Limited (GSCDL)

Gandhinagar-382011, Gujarat.

Table of Contents

1. Disclaimer ...... 11

2. Glossary ...... 13

3. Introduction ...... 14 3.1. Project Background ...... 14 3.2. Project Objectives ...... 14

4. Scope of Services for the Project ...... 16 4.1. Components & Services Overview ...... 16 4.2. Scope of services - Phases ...... 19 4.2.1. Solution Architecture ...... 20 4.3. Scope and Architecture of Adaptive Traffic Control System ...... 23 4.3.2. Assessment and Site Survey for finalization of detailed technical architecture and project plan ...... 26 4.3.3. Site Clearance obligations & other relevant permissions ...... 30 4.3.3.1. Survey and Commencement of Works ...... 30 4.3.3.2. Existing Traffic Signal system ...... 30 4.3.3.3. Road signs ...... 30 4.3.3.4. Electrical works and power supply ...... 30 4.3.3.5. Lightning-proof measures ...... 30 4.3.3.6. Earthing System ...... 31 4.3.3.7. Junction Box, Poles and Cantilever ...... 31 4.3.3.8. Cabling Infrastructure ...... 32 4.4. Design, Supply, Installation & Commissioning of the ATCS Field Equipment ...... 32 4.4.1.1. Adaptive Traffic Control System (ATCS) ...... 33 4.4.1.2. ANPR Cameras ...... 33 4.4.1.3. Red Light Violation Detection (RLVD) System ...... 34 4.4.1.4. Speed Violation Detection System ...... 34 4.4.1.5. Variable Message Sign (VMS) Boards ...... 35 4.4.1.6. Public Address (PA) System & Emergency Call Box (ECB) System ...... 35 4.4.1.7. E-Challan Devices ...... 36 4.5. Design, Supply, Installation, Commissioning and Testing of Smart Pole ...... 36 Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System, Adaptive Traffic Management System, Solid Waste Management System and other Smart Elements & Integrated Command and Control Centre (ICCC) in Gandhinagar City

4.5.1. LED based Smart Street Light ...... 36 4.5.2. Technical Architecture of the Smart Street Light ...... 39 4.5.3. Recommended Levels of Illumination (as per BEE guidelines) ...... 39 4.5.4. Public Wi-Fi ...... 40 4.5.5. Surveillance ...... 43 4.5.6. Variable Messaging Boards ...... 44 4.5.7. Environmental Sensor ...... 44 4.5.8. Integrated Command and Control Centre ...... 45 4.6. Design, Supply, Installation and Commissioning of Solid Waste Management ...... 45 4.6.1. Scope of Work ...... 45 4.6.2. Components of Proposed Architecture ...... 47 4.7. Smart Elements- Kiosks and Wayfinders ...... 49 4.7.1. The essential components of the Integrated Transport management system are: .. 49 4.7.2. Geographical Scope of services ...... 51 4.8. Integrated Transport Management system Architecture and Scope ...... 52 4.8.1. Geographical Scope of services ...... 55 4.8.2. Assessment and Site Survey for finalization of detailed technical architecture and project plan ...... 56 4.8.3. Site Clearance obligations & other relevant permissions ...... 59 4.8.3.1. Survey and Commencement of Works ...... 59 4.8.3.2. Existing Bus stops ...... 59 4.8.3.3. Electrical works and power supply ...... 59 4.8.3.4. Lightning-proof measures ...... 59 4.8.3.5. Earthing System ...... 60 4.8.3.6. Cabling Infrastructure ...... 60 4.8.4. Design, Supply, Installation & Commissioning of the Integrated Transport Management solution ...... 61 4.9. Design, Configuration, Installation and Commissioning of DC and DR on Cloud ...... 61 4.9.1. DR Plan and Implementation ...... 62 4.9.2. Testing ...... 65 4.9.3. Post Implementation Maintenance & Support ...... 65 4.9.4. Security Audit ...... 66 4.9.5. Cloud Management Portal ...... 66

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System, Adaptive Traffic Management System, Solid Waste Management System and other Smart Elements & Integrated Command and Control Centre (ICCC) in Gandhinagar City

4.10. Design, Supply, Installation and Commissioning of IT Infrastructure at Viewing Center, Interim ICCC, main ICCC ...... 66 4.11. Responsibility Matrix ...... 69 4.12. Project Deliverables ...... 76 4.13. Project Timelines ...... 78

5. Annexure I- Functional Requirements & Technical Specifications ...... 80 5.1. Adaptive Traffic Control System (ATCS) ...... 80 5.1.1. Functional Requirement - Adaptive Traffic Control System ...... 80 5.1.1.1. Functional Requirement -Traffic Signal Controller...... 80 5.1.1.2. Functional Requirement -Camera based Vehicle Detector ...... 88 5.1.1.3. Functional Requirement -Countdown Timer ...... 88 5.1.1.4. Functional Requirement -Communication Network ...... 89 5.1.1.5. Functional Requirement -ATCS Software Application ...... 89 5.1.2. Technical Specifications - Adaptive Traffic Control System ...... 95 5.1.2.1. Adaptive Traffic Control- Traffic Sensor...... 95 5.1.2.2. Adaptive Traffic Control- Traffic Controller ...... 95 5.1.2.3. Adaptive Traffic Control- Traffic Light Aspects ...... 95 5.1.2.4. Countdown Timer ...... 97 5.1.2.5. Poles for Traffic Signals ...... 98 5.1.2.6. Cables for Traffic Signals ...... 98 5.2. Traffic Enforcement System ...... 99 5.2.1. Functional Requirements of the Red Light Violation Detection System ...... 99 5.2.2. Functional Requirements of the Speed Violation Detection System...... 105 5.2.3. Technical Specifications: Red Light Violation Detection Systems ...... 110 5.2.4. Technical Specifications: Speed Violation Detection System ...... 113 5.3. Surveillance System ...... 117 5.3.1. Functional Requirement - Surveillance System ...... 117 5.3.1.1. Information to be captured by Edge Devices ...... 117 5.3.1.2. Information to be analyzed at Interim ICCC/ICCC ...... 118 5.3.1.3. Role Based Access to the Entire System ...... 118 5.3.1.4. Storage/Recording Requirements ...... 118 5.3.1.5. Other General Requirements ...... 120

5.3.2. Technical Specifications - Surveillance System ...... 123 5.3.2.1. PTZ Cameras...... 123 5.3.2.2. Fixed Box Cameras ...... 124 5.3.2.3. IR Illuminators ...... 126 5.3.2.4. Fixed Bullet IR Cameras ...... 126 5.3.2.5. Network Video Recorder ...... 127 5.3.2.6. Public Address (PA) System ...... 129 5.3.2.7. Emergency Call Box (ECB) System ...... 130 5.3.2.8. Field Junction Box ...... 130 5.3.2.9. Poles for Camera ...... 131 5.3.2.10. Edge Level Switch (at Traffic Junctions) (Edge Level Switch(at Field Locations) 132 5.3.2.11. Online UPS for field locations ...... 134 5.3.2.12. ANPR System ...... 135 5.4. Variable Message Signage System ...... 138 5.4.1. Functional Requirements of the Variable Message Signage System ...... 138 5.4.2. Technical Specifications: Variable Message Signage System ...... 142 5.5. Integrated Transport Management System ...... 146 5.5.1. Functional Requirement of Automatic Vehicle Locator System ...... 147 5.5.2. Technical Specification of OBU (On Board Unit)/GPS/Bus Driver Console ...... 152 5.5.3. Technical Specification of PIS ...... 157 5.5.4. Controller ...... 159 5.5.5. Fixed Box Cameras ...... 161 5.5.6. Functional requirements Vehicle planning, schedule and dispatch system ...... 162 5.5.7. Functional Requirement Incident management system ...... 170 5.5.8. Functional Requirement Web Portal ...... 172 5.5.9. Functional Requirements Mobile application ...... 173 5.5.10. Functional Requirement MIS ...... 174 5.5.11. Functional Requirement Financial Management System...... 176 5.5.12. Functional Requirement Business Intelligence System ...... 179 5.5.13. Functional Requirement Smart Bus stops ...... 186 5.6. Smart Elements ...... 188 5.6.1. Functional Specification of the Internal Wayfinder & Kiosks ...... 188

5.6.2. Technical Specifications of the Media Player ...... 189 5.7. Smart Poles ...... 190 5.7.1. Intelligent Pole – Specifications ...... 190 5.7.2. LED based Smart Street light ...... 191 5.7.3. LED Specifications ...... 191 5.7.4. Smart Street Light Solution ...... 191 5.7.5. LED Luminaire ...... 192 5.7.6. Feeder Panels ...... 193 5.7.7. Centralized Management Software ...... 195 5.7.8. Recommended Levels of Illumination (as per BEE guidelines) ...... 196 5.7.9. Minimum desired illumination levels during peak hours ...... 196 5.7.10. Conformance Standards ...... 196 5.7.11. Public Wi-Fi - Specification ...... 197 5.7.11.1. WLAN Controller ...... 197 5.7.11.2. Access Point...... 198 5.7.12. Variable Messaging Boards ...... 198 5.7.13. L2+ 8 Ports Managed PoE Switch (Edge Level switch (For field Locations)) .... 199 5.7.14. Environmental Sensors ...... 200 5.8. Cloud Functional and Technical Specification ...... 203 5.8.1. Cloud Network Requirement ...... 203 5.8.2. Cloud Datacenter Specification ...... 203 5.8.3. Cloud Storage Service Requirement ...... 204 5.8.4. Cloud Security Requirement ...... 204 5.9. Solid Waste management ...... 204 5.9.1. Automatic Vehicle Locator Management System ...... 204 5.9.2. Mobile GPS based Staff Attendance Management System ...... 205 5.9.3. Mobile application for customer ...... 206 5.9.4. Unified Dashboard View for Solid Waste Management ...... 206 5.9.5. Infrastructure Solutions ...... 206 5.9.6. Functional Requirement – SWM ...... 207 5.9.7. Technical Requirement – SWM ...... 209 5.9.7.1. GPS/GSM Tracker ...... 209 5.9.7.2. Technical Specification- Pan Tilt and Zoom – based Cameras CC TV ...... 210

5.9.7.3. Technical Specification- RFID Tag and Reader UHF Passive RFID Tag Specifications ...... 212 5.9.7.4. Technical Specification- RFID Reader Specifications ...... 213 5.10. Data Centre ...... 214 5.10.1. Core Router ...... 214 5.10.2. Internet Router ...... 216 5.10.3. Firewall ...... 218 5.10.4. Data Center Switch (Manageable)...... 219 5.10.5. Data Center Switch ...... 223 5.10.6. Fire proof enclosure ...... 226 5.10.7. KVM Module ...... 227 5.10.8. Server/Networking rack specifications ...... 228 5.10.9. Enterprise Management Systems (EMS) for Cloud based Services ...... 230 5.10.10. Centralised Anti-virus Solution ...... 233 5.10.11. Database Licenses ...... 234 5.10.12. Backup Software ...... 234 5.10.13. Directory services ...... 235 5.10.14. Structured Cabling Components ...... 235 5.10.15. Electrical cabling component ...... 235 5.11. Integrated Command and Control Center & Viewing Centers ...... 235 5.11.1. Integrated Command and Control Center Application ...... 235 5.11.2. Contact Centre: ...... 247 5.11.3. IP Push to Talk (interpretability Communication Channel) ...... 248 5.11.4. Video Wall Screen ...... 249 5.11.5. Video Wall Controller ...... 251 5.11.6. Video Wall Management Software ...... 254 5.11.7. Monitoring Workstations ...... 255 5.11.8. LED Display ...... 257 5.11.9. IP Phones ...... 258 5.11.10. Network Color Laser printer ...... 260 5.11.11. IP PBX (Call Control System) ...... 260 5.11.12. Contact Centre Specifications...... 262 5.11.13. Video Conferencing Unit ...... 263

5.11.14. Multiparty Conference Unit (Video and Audio Conferencing Bridge with Secure VC over Internet) ...... 264 5.11.15. Online UPS ...... 266 5.11.16. Fixed Dome camera for Indoor Surveillance ...... 268 5.12. Non-IT Requirements & Specifications ...... 270 5.12.1. Civil and Architectural Work ...... 270 5.12.2. PVC Conduit ...... 273 5.12.3. Wiring ...... 274 5.12.4. Cable Work ...... 276 5.12.5. Earthing ...... 276 5.12.6. Fire Detection and Control Mechanism ...... 277 5.12.7. Access Control System ...... 279

6. Annexure II: Detailed Scope of Work and Considerations 281 6.1. Scope of Work ...... 281 6.1.1. Inception Phase ...... 281 6.1.2. Requirement Phase ...... 281 6.1.3. Design Phase...... 282 6.1.4. Development Phase ...... 282 6.1.5. Integration Phase and use cases for ICCC ...... 284 6.1.6. Go-Live Preparedness and Go-Live ...... 295 6.1.7. Operations and Maintenance ...... 295 6.1.7.1. Project Management & Facilities Management Services ...... 296 6.1.7.2. Provision of the Operational Manpower to view the feeds at Command Center 296 6.1.7.3. Basic Infrastructure Services ...... 297 6.1.7.4. Network Monitoring Services ...... 297 6.1.7.5. Integration Testing ...... 297 6.1.7.6. Vendor Management Services ...... 298 6.1.7.7. Network Management ...... 298 6.1.7.8. Physical Infrastructure Management and Maintenance Services ...... 299 6.1.8. Exit Management ...... 299 6.1.8.1. Cooperation and Provision of Information ...... 299 6.1.8.2. Confidential Information, Security and Data ...... 300

6.1.8.3. Transfer of Certain Agreements ...... 300 6.1.8.4. General Obligations of the MSI ...... 300 6.1.8.5. Exit Management Plan ...... 301 6.1.9. Compliance to Standards & Certifications ...... 302 6.1.10. Project Management and Governance ...... 303 6.1.10.1. Project Management Office (PMO) ...... 303 6.1.10.2. Helpdesk and Facilities Management Services ...... 304 6.1.10.3. Steering Committee ...... 305 6.1.10.4. Project Monitoring and Reporting ...... 305 6.1.10.5. Risk and Issue management...... 305 6.1.10.6. Governance procedures ...... 306 6.1.10.7. Planning and Scheduling ...... 306 6.1.10.8. License Metering / Management ...... 306 6.1.11. Change Management & Control ...... 307 6.1.11.1. Change Orders / Alterations / Variations ...... 307 6.1.11.2. Change Order ...... 307 6.1.12. Testing and Acceptance Criteria ...... 308 6.1.12.1. Factory Testing ...... 311 6.1.12.2. Final Acceptance Testing ...... 311

7. Annexure III: Payment Schedule and Milestones ...... 313

7.1 Milestones and Payment Schedules for Implementation Phase ...... 316

7.2 Milestones and Payment Schedules for Operations and Maintenance Phase ...... 320

8. Annexure IV : Smart City-Design Consideration ...... 321 8.1. Key Design Considerations ...... 321 8.1.1. Guiding Architecture Principle ...... 323 8.1.1.1. Platform Approach ...... 323 8.1.1.2. Openness ...... 323 8.1.1.3. Data as an enterprise asset ...... 323 8.1.1.4. Performance ...... 323

8.1.1.5. Scalability ...... 324 8.1.1.6. No Vendor lock-in and Replace-ability ...... 325 8.1.1.7. Security ...... 325 8.1.1.8. User Interface...... 326 8.1.1.9. Reliability ...... 327 8.1.1.10. Manageability ...... 328 8.1.1.11. Availability ...... 329 8.1.1.12. SLA driven solution ...... 329 8.1.1.13. Reconstruction of truth ...... 329 8.1.1.14. Integration Architecture ...... 330 8.2. Security ...... 335 8.2.1. User Security and Monitoring ...... 335 8.2.2. Data Security ...... 336 8.2.3. Application Security ...... 337 8.2.4. Infrastructure Security ...... 338 8.3. Software Development Lifecycle ...... 340 8.4. Quality Assurance ...... 340 8.4.1. Performance and Load Testing ...... 341

9. Annexure V- Common guidelines regarding compliance of systems/equipment ...... 343

10. Annexure VI - Status of the Systems to be integrated in ICCC in Gandhinagar City ...... 345

11. Annexure VII- Smart Governance application details ...... 346

12. Annexure VIII- List of Locations ...... 347 12.1. List of Traffic Signals ...... 347 12.2. List of locations ATCS ...... 347 12.3. List of locations for proposed ATCS Systems ...... 348 12.4. List of locations for RLVD System ...... 348 12.5. List of locations for Speed Violation Detection System ...... 348 12.6. List of locations for proposed Variable Message Sign Boards ...... 349 12.7. List of locations for proposed PA system ...... 349

12.8. List of locations for proposed ECB system ...... 349 12.9. List of locations for proposed Smart Poles ...... 350 12.10. List of locations for proposed Kiosk system ...... 350 12.11. List of locations for proposed Internal Wayfinder system ...... 351 12.12. List of locations for proposed Smart Bus Stops ...... 351

1. Disclaimer The information contained in this Request for Proposal document (“RFP”) whether subsequently provided to the bidders, (“Bidder/s”) verbally or in documentary form by Gandhinagar Smart City Limited (henceforth referred to as “GSCDL” in this document) or any of its employees or advisors, is provided to Bidders on the terms and conditions set out in this Tender document and any other terms and conditions subject to which such information is provided. This RFP is not an agreement and is not an offer or invitation to any party. The purpose of this RFP is to provide the Bidders or any other person with information to assist the formulation of their financial offers (“Bid”). This RFP includes statements, which reflect various assumptions and assessments arrived at by GSCDL in relation to this scope. This Tender document does not purport to contain all the information each Bidder may require. This Tender document may not be appropriate for all persons, and it is not possible for the Managing Director, GSCDL and their employees or advisors to consider the objectives, technical expertise and particular needs of each Bidder. The assumptions, assessments, statements and information contained in the Bid documents, may not be complete, accurate, adequate or correct. Each Bidder must therefore conduct its own analysis of the information contained in this RFP and to seek its own professional advice from appropriate sources. Information provided in this Tender document to the Bidder is on a wide range of matters, some of which may depend upon interpretation of law. The information given is not intended to be an exhaustive account of statutory requirements and should not be regarded as a complete or authoritative statement of law. GSCDL accepts no responsibility for the accuracy or otherwise for any interpretation of opinion on law expressed herein. GSCDL and their employees and advisors make no representation or warranty and shall incur no liability to any person, including the Bidder under law, statute, rules or regulations or tort, the principles of restitution or unjust enrichment or otherwise for any loss, cost, expense or damage which may arise from or be incurred or suffered on account of anything contained in this RFP or otherwise, including the accuracy, reliability or completeness of the RFP, and any assessment, assumption, statement or information contained therein or deemed to form part of this RFP or arising in any way in this Selection Process. GSCDL also accepts no liability of any nature whether resulting from negligence or otherwise howsoever caused arising from reliance of any Bidder upon the statements contained in this RFP. GSCDL may in its absolute discretion, but without being under any obligation to do so, can amend or supplement the information in this RFP. The issue of this Tender document does not imply that GSCDL is bound to select a Bidder or to appoint the Selected Bidder (as defined hereinafter), for implementation and GSCDL reserves the right to reject all or any of the Bidders or Bids without assigning any reason whatsoever. The Bidder shall bear all its costs associated with or relating to the preparation and submission of its Bid including but not limited to preparation, copying, postage, delivery fees, expenses associated with any demonstrations or presentations which may be required by GSCDL or any other costs

incurred in connection with or relating to its Bid. All such costs and expenses will remain with the Bidder and GSCDL shall not be liable in any manner whatsoever for the same or for any other costs or other expenses incurred by a Bidder in preparation for submission of the Bid, regardless of the conduct or outcome of the Selection process.

2. Glossary Terms Meaning GSCDL Gandhinagar Smart City Limited RFP Request for Proposal CCTV Closed Circuit Television BOM Bill of Material GIS Geographical Information Systems GPS Global Positioning System ICT Information and Communication Technology OEM Original Equipment Manufacture MSI Master System Integrator SOP Standard Operating Procedures UAT User Acceptance Testing VM Virtual Machine ICCC Integrated Command and Control Centre ITMS Intelligent Transport Management System ATCS Adaptive Traffic Control System MMTS Multi-Modal Transport Systems ECB Emergency Call Box DC Data Centre IT Information Technology IP Internet Protocol AMC Annual Maintenance Contract OFC Optical Fiber Cable PA Public Address ANPR Automatic Number Plate Recognition RLVD Red Light Violation Detection SVD Speed Violation Detection PTZ Pan Tilt Zoom PoP Point of Presence TPA Third Party Auditor FMS Facility Management Services UPS Uninterrupted Power Supply VMS Variable Message Sign GSM Global System for Mobile Communication AP Access Points,

3. Introduction 3.1. Project Background One of the primary objective of Gandhinagar under its smart city mission is to improve efficiency of municipal services, enhance the safety and security, and promote a better quality of life for residents. In order to achieve these objectives, Gandhinagar desires to foster the development of a robust ICT infrastructure that supports digital applications and ensures seamless steady state operations, transport and traffic management, emergency response mechanisms and real time tracking of services and vital city metrics throughout the city and in government departments. GSCDL is considering the appointment of an agency to set up these priority initiatives identified under the Smart City mission which will include Integrated Command and Control Center (ICCC) and Smart Elements, Intelligent Transport Management System (ITMS), Adaptive Traffic Control System(ATCS), Solid Waste Management(SWM), City Wi-Fi, environment sensors, Digital Signages, Smart Poles, smart parking etc. 3.2. Project Objectives The key objective of this project is to establish a collaborative framework where input from different functional departments of Gandhinagar Municipal Corporation and other stakeholders such as transport, water, fire, police, e-governance, etc. can be assimilated and analysed on a single platform; consequently resulting in aggregated city level information. Further this aggregated city level information can be converted to actionable intelligence, which would be propagated to relevant stakeholders and citizens. Following are the intangibles that should be addressed by the proposed interventions: a. Efficient traffic management b. Efficient transport management c. Enhanced safety and security d. Better management of utilities and quantification of services e. Asset Management f. Disaster Management and Emergency Response g. Integration with all existing and future services as identified by Gandhinagar Smart City limited (GSCDL) in the city including but not limited to(with provision for future scalability):  Adaptive Traffic Control System  Intelligent Transport Management System  Solid waste management  Smart Parking  Panic Button/Emergency Call Box

 Public Address System  Environmental sensors  Smart Poles  Smart Lighting  Smart Governance  City Network  City Wifi  Water SCADA & Smart Meters  Sewerage  Storm water Drainage  E-Medicine/Health  E-Education  Disaster Management  Grievance Management  Geographical Information System  Fire  GIS based Property Management  Gandhinagar City MobileApp and Portal  Any other sensors/systems

4. Scope of Services for the Project 4.1. Components & Services Overview The Master System Integrator (MSI) should ensure the successful implementation of the proposed “Intelligent Transport Management System(ITMS), Adaptive Traffic Managemet System(ATCS), Smart Poles, other smart elements like kiosks and wayfinders, Solid Waste Management(SWM) and Integrated Command and Control Center in Gandhinagar city” and provide capacity building support to city authorities as per the scope of services described below. Any functionality not expressly stated in this document but required to meet the needs of the GSCDL as specified in the scope in this RFP and captured during assessment/requirement gathering phase of project shall essentially be under the scope of the MSI to ensure successful operations of the system and for that no extra charges shall be admissible. MSI shall implement and deliver the following systems and components: Establishment of ITMS, Smart Poles, Solid Waste Management, ATCS, Integrated Command and Control Center with provisioning of Cloud based Data centre and Disaster Recovery along with integration of the following sub systems already present in the city or envisaged. 1. Intelligent Transport Management System 2. Adaptive Traffic Control System 3. Solid waste management 4. Smart Poles 5. Kiosks and wayfinders 6. Smart Parking 7. Panic Button/Emergency Call Box 8. Public Address System 9. Environmental sensors 10. Smart Lighting 11. Smart Governance 12. City Network 13. City Wifi 14. Water SCADA 15. Sewerage 16. Storm water Drainage 17. Health 18. Education 19. Disaster Management

20. Grievance Management 21. Geographical Information System 22. Fire 23. GIS based Property Management 24. Gandhinagar City MobileApp and Portal 25. Any other sensors/systems

The MSI’s scope of work shall include but will not be limited to the following broad areas. Details of each of these broad areas have also been outlined in Annexure II. 1. Assessment, Scoping and Survey Study: Conduct a detailed assessment, scoping study and develop a comprehensive project plan, including: a. Assess existing systems, street infrastructure and connectivity within the city for the scope items mentioned in section 4.1 b. Conduct site survey for finalization of detailed technical architecture, gap analysis and project plan c. Conduct site surveys to identify need for site preparation activities d. Obtain site Clearance obligations & other relevant permissions 2. Design, Supply, Installation, Commissioning and Testing which includes the following components: a. Part I: Implementation of following Systems: 1. Intellingent Transport Management System (ITMS) 2. Adaptive Traffic Control System 3. Solid Waste Management 4. Smart Pole 5. Wayfinders and Kiosks 6. Integrated Command and Control Center 7. Cloud based Data Centre (DC) and Disaster Recovery Centre b. Part II: Phase wise Integration of the ICT systems with Integrated Command and Control Centre 1. Intelligent Transport Management System 2. Adaptive Traffic Control System 3. Solid waste management

4. Smart Poles 5. Kiosks and wayfinders 6. Smart Parking 7. Panic Button/Emergency Call Box 8. Public Address System 9. Environmental sensors 10. Smart Lighting 11. Smart Governance 12. City Network 13. City Wifi 14. Water SCADA 15. Sewerage 16. Storm water Drainage 17. Health 18. Education 19. Disaster Management 20. Grievance Management 21. Geographical Information System 22. Fire 23. GIS based Property Management 24. Gandhinagar City MobileApp and Portal 25. Any other sensors/systems 3. Operation and Maintenance Phase

The selected vendor will also be responsible for supply of IT solution for the management of hardware and application software, networking, installation, Training, Maintenance and operations of the solution for 5 year from the Go Live date of implemented solutions for Gandhinagar in an efficient and effective manner. 4. Integrate with provisions available for Network Connectivity within the city which includes a. Lease line/MPLS connectivity procured through a separate tender b. Fiber optic network planned in future c. Internet connectivity procured through a separate tender

5. Provisioning Hardware and Software Infrastructure on cloud which includes design, supply, installation, and commissioning of DC Infrastructure for Integrated command control center and DR. This consist of: a. Basic Site preparation services b. IT Infrastructure including server, storage, other required hardware, application portfolio, licenses as required for cloud based hosting. c. Command Center infrastructure including operator workstations, IP phones, joystick controller etc. d. Establishment of LAN and WAN connectivity at command center and DC for component of ATCS only limited to scope of infrastructure procured for the project e. Establishment of internet connectivity at the command and control centre for cloud hosted DC and DR for all smart interventions. f. Application integration services with other GSCDL applications

6. Capacity Building for GSCDL and any other department which includes preparation of operational manuals, training documents and capacity building support, including: a. Training of the city authorities, police personnel and operators on operationalization of the system b. Support during execution of acceptance testing c. Preparation and implementation of the information security policy, including policies on backup and redundancy plan d. Preparation of revised KPIs for performance monitoring of various urban utilities monitored through the system envisaged to be implemented e. Developing standard operating procedures for operations management and other services to be rendered by ICCC f. Preparation of system documents, user manuals, performance manuals, Operation manual etc. 7. Operations and Maintenance services for the software, hardware and other IT and Non-IT infrastructure installed as part of the project after Phase wise Go-Live and for 5 years after implementation or phase wise Go-Live i.e. Warranty period of the product supplied under project i.e hardware, software, IT/Non-IT etc., will be considered after phase wise Go-Live.

4.2. Scope of services - Phases The following is a summary of the geographical extent of the project.

Implemen Integrati # System Description Phases tation on 1. Integrated Command and  NA Phase I Control Centre 2. Intelligent Transport   Phase I Management System (ITMS) 3. Adaptive Traffic C ontrol   Phase I System (ATCS) 4. Solid Waste Management   Phase I 5. Smart Pole(Environmental   Phase I Sensors, Variable Messaging Boards, Smart Lights, ECB, CCTV) 6. Existing City wide network ×  Phase I 7. Existing City Surveillance ×  Phase I 8. Internal and External   Phase I Wayfinders 9. Existing City Wi-Fi ×  Phase I 10. Kiosks   Phase I 11. Variable Messaging   Phase I Displays 12. Disaster Recovery   Phase I 13. Existing Environmental ×  Phase I Sensor 14. Existing Smart Lighting ×  Phase I 15. e-Healthcare ×  Phase II 16. GIS ×  Phase II 17. City App Portal and mobile ×  Phase II app 18. e- Learning ×  Phase II 19. ERP and e-Governance ×  Phase II 20. Smart Parking ×  Phase III 21. Sewerage System ×  Phase III 22. Knowledge Centre ×  Phase III 23. Water SCADA ×  Phase III

4.2.1. Solution Architecture

Indicative architecture of the components envisaged under the ““Integrated Command and Control Center” is as given below.

a. Sensor and actuator layer The sensor layer will help the city administration gather information about the ambient city conditions or capture information from the edge level devices like intelligent Transport system, cameras, enforcement sensors, emergency call boxes, etc. Gandhinagar city is expected to have multiple environmental sensors across the city, to measure ambient conditions such as light intensity, temperature, water level (for chronic flood spots), air pollution, noise pollution and humidity.

b. Data Collection Layer (Controllers) Controller processes data, that is input from the sensor applies the logic of control and causes an output action to be generated. This signal may be sent directly to the controlled device or to other logical control functions and ultimately to the controlled device. The controllers function is to compare its input (from the sensor) with a set of instructions such as set point, throttling range and action, then produce an appropriate output signal. It usually consists of a control response along with other logical decisions that are unique to the specific

control application. After taking the logical decision of the information it will hand over the information to the next layer (Network Layer) which will subsequently available at the ICCC.

c. Network Layer The secured network layer will serve as the backbone for the project and provide connectivity to gather data from sensors and communicate messages to display devices and actuators. It will support the Wi-Fi services and other smart elements (sensors and displays) at given locations. The network layer will be scalable such that additional sensors, actuators, display devices can be seamlessly added and more Wi-Fi spots created in future. Provisioning of bandwidth will not be included in the scope of the Implementation Vendor; however, entire network backbone shall be provided by GSCDL.

d. Data Center Layer The data center layer will house centralized computing power required to store, process and analyze the data to decipher actionable information. This layer includes servers, storage, ancillary network equipment elements, security devices and corresponding management tools. Similar to the network layer, it will be scalable to cater to the increasing computing and storage needs in future.

e. Smart Application and Integration Layer The smart applications layer will contain data aggregation and management systems (rules engines, alerting systems, diagnostics systems, control systems, messaging system, events handling system), and reporting / dashboard system to provide actionable information to city administrators and citizens. It will be an evolving layer with applications added and integrated as and when new applications are developed at GSCDL. While aspects of ambient conditions within the city will be gathered through various sensors deployed, some city specific data will come from other government and non-government agencies. It is through the integration layer – that data will be exchanged to and from the under lying architecture components and other data from system developed by government (such as police department, meteorological department, street lights department, water department, irrigation department, transport organizations within Gandhinagar , etc.) and non-government agencies.

f. Service delivery and consumption Layer The output field devices layer will contain display devices or bi-directional (input & output) devices connected to the network which will be used by citizens to consume - and for administrators to provide - actionable information. Such field devices include digital messaging boards, environmental data displays, etc.

g. Control Units & Command Center Layer The command center and control units will enable citizens and administrators alike to get a holistic view of city conditions. Such control units will take shape of either an exhaustive command center or control applications which can be viewed over a web browser or available in form of a mobile application. The implementation vendor will have to develop a command center

at a site location determined by GSCDL and web/ mobile based viewing tools for understanding the ambient city conditions.

h. Security Layer As ambient conditions, actuators and display devices are now connected through a network, security of the entire system becomes of paramount significance and the MSI will have to provide:  Infrastructure security- including policies for identity and information security policies  Network security- including policies and practices adopted to prevent and monitor unauthorized access, misuse, modification, or denial of a computer network and network-accessible resources, etc.  Identity and Access Management – including user authentication, authorization, SSL & Digital Signatures  Application security- including Hosting of Government Websites and other Cloud based services, Adoption of Technical Standards for Interoperability Framework and other standards published by GoI for various eGovernance applications  End device security, including physical security of all end devices such as display boards, emergency boxes etc. Following security parameters should be included for all smart elements, but not limited to:  Identity and access management  User/administrator audit log activity (logon, user creation, date-time of PA announcements, voice recording etc.)  Secured data storage (storage of video/image/voice/location/data captured by various smart elements)  SSL/TLS encryption for web and mobile application based interfaces for sensitive data transfer

 Protection against Denial of Service (DoS) and Interference attacks to public Wi-Fi Devices

4.3. Scope and Architecture of Adaptive Traffic Control System The MSI should ensure the successful implementation of the proposed Adaptive Traffic Control System (ATCS) and provide capacity building support to city authorities as per the scope of services described below. Any functionality not expressly stated in this document but required to meet the needs of the GSCDL to ensure successful operations of the system shall essentially be under the scope

of the MSI and for that no extra charges shall be admissible. MSI shall implement and deliver the following systems and capabilities linked with Interim ICCC/ICCC. 1. Adaptive Traffic Control System (ATCS) 2. Automatic Number Plate Recognition (ANPR) System 3. Red Light Violation Detection (RLVD) System 4. Speed Violation Detection (SVD) System 5. Traffic Violation Cameras 6. Variable Message Sign boards 7. Public Address (PA) 8. Emergency Call Box (ECB) System 9. Integration with existing eChallan System The schematic diagram below shows the systems envisaged under ATCS and the information flow across the systems to be integrated.

Figure: Logical Architecture of ATCS

The MSI’s scope of work shall include but will not be limited to the following broad areas. Details of each of these broad areas have also been outlined in subsequent sections of this document: 1. Assessment and Site Survey: Conduct a detailed assessment, site survey and develop a comprehensive project plan, including: a. Assess the existing infrastructure of traffic junctions, traffic management systems, applications. etc. including traffic signaling systems and junction management b. Conduct the site surveys to finalize the location of traffic signal controller, number of traffic signal aspects, Camera distribution systems, locations and height of poles, cantilever, junction box, and cable routing etc. c. Finalization of detailed technical architecture, gap analysis and project plan d. Develop traffic management plans for individual signal controls and groups of signal controllers along with pre-planned intervention strategies for special scenarios e. Obtain site Clearance obligations & other relevant permissions 2. Design, Supply, Installation and Commissioning of Field Equipment which includes the following components: a. Adaptive Traffic Control System (ATCS) b. Automatic Number Plate Recognition (ANPR) System c. Red Light Violation Detection (RLVD) System d. Speed Violation Detection System e. Traffic Violation Cameras f. Variable Message Sign boards g. Public Address (PA) h. Emergency Call Box (ECB) System 3. Requirement analysis and design of Network Connectivity for Adaptive Traffic Control. a. MSI is required to carry out detailed network requirement analysis and design for supporting ATCS solution and live data streaming to Data Centre, ICCC. b. Last mile connectivity including customer premise equipment (CPE) will be responsibility of GSCDL/Service provider. c. Integration and migration onto the city fiber network backbone envisaged as future Smart Solution Projects under Gandhinagar Smart City initiatives.

4. Capacity Building for Gandhinagar Police, GSCDL, and GMC which includes preparation of operational manuals, training documents and capacity building support, including: a. Training of the city authorities, Gandhinagar Police personnel and Interim ICCC/ICCC operators on operationalization of the system b. Support during execution of acceptance testing c. Preparation and implementation of the information security policy, including policies on backup and redundancy plan d. Preparation of revised traffic signal control plans, alternate signal control plans, KPIs for performance monitoring of transport network, dashboards for MIS e. Developing standard operating procedures for operations management and other technical services to be rendered by Interim ICCC/ICCC f. Preparation of system documents, user manuals, performance manuals, etc. 4.3.1. Operations and Maintenance services for the software, hardware and other IT and Non-IT infrastructure installed as part of the project after Phase wise Go-Live and for 5 years after implementation or phase wise Go-Live i.e. Warranty period of the product supplied under project i.e hardware, software, IT/Non-IT etc., will be considered after phase wise Go-Live. Geographical Scope of services The following is a summary of the geographical extent of the project. # System Description Locations

1. Adaptive Traffic Control System 10 2. Red Light Violation Detection System at Intersection 5 3. Speed Violation Detection Systems 5 4. Traffic Violation Cameras 0 5. Variable Message Sign Boards 5 6. Public Address (PA) System 10 7. Emergency Call Box (ECB) System 10 8. ICCC Interim 1 Location 9. ICCC Main 1 Location The Indicative list of locations to be covered under this project are provided as Annexure VIII. 4.3.2. Assessment and Site Survey for finalization of detailed technical architecture and project plan After signing of contract, the Systems Integrator needs to deploy local team (based out of Gandhinagar) proposed for the project and ensure that a Project Inception Report is submitted to GSCDL which should cover following aspects: 1. Names of the Project Team members, their roles and responsibilities

2. Approach and methodology to be adopted to implement the Project (which should be in line with what has been proposed during bidding stage, but may have value additions / learning in the interest of the project). 3. Responsibility matrix for all stakeholders 4. Risks the MSI anticipates and the plans they have towards their mitigation 5. Detailed project plan specifying dependencies between various project activities / sub- activities and their timelines 6. Installation locations geo mapped preferably on google earth to visually identify the geographical area The MSI shall conduct a comprehensive As-Is study of the existing infrastructure of traffic junctions/intersections (identified for ATCS) during various time periods of day including peak and non-peak hours to establish the key performance indicators(KPI) for the project. The KPIs of the study shall be included in the survey. The following minimum parameters should be captured during the comprehensive study 1. Volumes of vehicles moving in the road network within the area identified for ATCS implementation 2. Vehicle type distribution 3. Directional distribution 4. Physical and visual characteristics of the area 5. Travel times, delays between different points of the network 6. Additional dependencies with respect to the available infrastructure and geometry at the junctions 7. Any other relevant data which the MSI anticipates will assist in establishing the benchmarks for the project The report shall also include the expected measurable improvements against each KPI as detailed out in the above ‘As-Is’ study after implementation of ATCS. The benchmarking data should also be developed to track current situation and desired state. The MSI shall study the existing business processes, functionalities, existing traffic management systems and applications including MIS reporting requirements. The proposed strategy should clearly provide approach and plan for implementing the new signals and field components while ensuring minimum disturbance to the road traffic and shall use appropriate static signage designating the work in progress status. Additionally, the MSI should provide a detailed To-Be designs (Junction layout plans) specifying the following:

1. High Level Design (including but not limited to) Application architecture, Logical and physical database design, Data dictionary and data definitions, ER diagrams and other data modelling documents and Physical infrastructure design for devices on the field 2. Application component design including component deployment views, control flows, etc. 3. Low Level Design (including but not limited to) Application flows and logic including pseudo code, GUI design (screen design, navigation, etc.), Database architecture, including defining data structure, data dictionary as per standards laid-down by Government of India/ Government of Gujarat 4. Location of all field systems and components proposed at the junctions, (KML /KMZ file plotted on GIS platform like google earth etc.) 5. Height and foundation of Cameras, Traffic Signals and Standard Poles for Pedestrian signals, Height and foundation of Poles, cantilevers, gantry and other mounting structures for other field devices 6. Location of Junction Box 7. Location of Network Provider’s Point of Presence (PoP) 8. Design of Cables, Ducts routing, digging and trenching 9. Electrical power provisioning The MSI shall also identify the customizations/ workaround that would be required for successful implementation and operation of the project. The report should take into consideration following guiding principles: 1. Scalability - Important technical components of the architecture must support scalability to provide continuous growth to meet the growing demand of the Gandhinagar city. The system should also support vertical and horizontal scalability so that depending on changing requirements from time to time, the system may be scaled upwards. There must not be any system imposed restrictions on the upward scalability in number of field devices. Main technological components requiring scalability are storage, bandwidth, computing performance (IT Infrastructure), software / application performance. 2. Availability - Components of the architecture must provide redundancy and ensure that are no single point of failures in the key project components. Considering the high sensitivity of the system, design should be in such a way as to be resilient to technological sabotage. To take care of remote failure, the systems need to be configured to mask and recover with minimum outage. The MSI shall make the provision for high availability for all the services of the system. 3. Security - The architecture must adopt an end-to-end security model that protects data and the infrastructure from malicious attacks, theft, natural disasters etc. MSI must make provisions for security of field equipment as well as protection of the software system

from hackers and other threats. Using Firewalls and Intrusion detection systems such attacks and theft should be controlled and well supported (and implemented) with the security policy. The virus and worms attacks should be well defended with gateway level Anti-virus system, along with workstation level anti-virus mechanism. Furthermore, all the system logs should be properly stored & archived for future analysis and forensics whenever desired. GSCDL may carry out the Security Audit of the entire system post acceptance / operationalization through a Third Party Auditor (TPA) if required and will bear the cost. The following guidelines need to be observed for security: a. Build a complete audit trail of all activities and operations using log reports, so that errors in system – intentional or otherwise – can be traced and corrected. b. Access controls must be provided to ensure that the system is not tampered or modified by the system operators. c. Implement data security to allow for changes in technology and business needs. d. The security of the field devices must be ensured with system architecture designed in a way to secure the field devices in terms of physical damage & unauthorized access. 4. Manageability - Ease of configuration, ongoing health monitoring, and failure detection are vital to the goals of scalability, availability, and security and must be able to match the scalability of the system 5. Interoperability - The system should have capability to take inputs from other third party systems as per situational requirements. 6. Open Standards - System should use open standards and protocols to the extent possible without compromising on the security 7. Convergence - GSCDL has already initiated many projects which have state of the art infrastructure at field locations deployed under them. The ATCS Infrastructure should be made scalable for future convergence needs. Under the smart city program, GSCDL has envisaged to create a state of the art infrastructure and services for the citizens of Gandhinagar, hence it is imperative that all infrastructure created under the project shall be leveraged for maximum utilization. Hence the MSI is required to ensure that such infrastructure will allow for accommodation of equipment’s being procured under other smart city projects. Equipment like Junction Boxes and poles deployed under the ATCS project at the field locations will be utilized to accommodate field equipment’s created under the other projects of GSCDL. The procedure for utilization of the infrastructure will be mutually agreed between the GSCDL and MSI Sub-contracting / Outsourcing shall be allowed only for the work which is allowed as mentioned in the clause with prior written approval of GSCDL. However, even if the work is sub-contracted / outsourced, the sole responsibility of the work shall lie with the MSI. The MSI shall be held responsible for any delay/error/non-compliance etc. of its sub-contracted vendor. The details of the

sub-contracting agreements (if any) between both the parties would be required to be submitted to GSCDL. Sub-contracting / outsourcing would be allowed only for work such as: 1. Passive Networking & Civil Work during implementation, 2. FMS staff for non- IT support during post-implementation 3. Services of professional architect for design of Interim ICCC/ICCC and viewing centers 4.3.3. Site Clearance obligations & other relevant permissions 4.3.3.1. Survey and Commencement of Works Prior to starting the site clearance, the MSI shall carry out survey of field locations as specified in Annexure VIII, for buildings, structures, fences, trees, existing installations, etc. The GSCDL shall be fully informed of the results of the survey and site clearance shall then be agreed with the GSCDL. 4.3.3.2. Existing Traffic Signal system The infrastructure of existing traffic signal systems including the aspects, controllers etc. will be dismantled and replaced with the new systems which are proposed and required under the scope of the ATCS project. The dismantled infrastructure shall be delivered at the GSCDL designated location without damage at no extra cost. 4.3.3.3. Road signs All existing road signs which are likely to be effected by the works are to be carefully taken down and stored. Signs to be re-commissioned shall be cleaned, provided with new fixings where necessary and the posts re-painted in accordance with GSCDL guidelines. Road signs, street name plate, etc. damaged by the MSI during their operation shall be repaired or replaced by MSI at no additional cost. 4.3.3.4. Electrical works and power supply The MSI shall directly interact with electricity boards for provision of mains power supply at all desired locations for ATCS field solution. The MSI shall be responsible to submit the electricity bill including connection charge, meter charge, recurring charges etc. to the electricity board directly. MSI shall have to submit the challan of bill submission to GSCDL. GSCDL will reimburse the amount submitted to the MSI after verification in next billing cycle.

4.3.3.5. Lightning-proof measures The MSI shall comply with lightning-protection and anti –interference measures for system structure, equipment type selection, equipment earthing, power, signal cables laying. The MSI shall describe the planned lightning-protection and anti –interference measures in the As-Is report. Corresponding lightning arrester shall be erected for the entrance cables of power line, video line, data transmission cables. All crates shall have firm, durable shell. Shell shall have dustproof, antifouling, waterproof function & should capable to bear certain mechanical external force. Signal separation of low and high frequency; equipment’s protective field shall be connected with its own public equal power bodies; small size/equipment signal lightning arrester shall be erected before the earthling. The Internal Surge Protection Device for Data Line Protection shall be selected as per zone

of protection described in IEC 62305, 61643-11/12/21, 60364-4/5. Data line protection shall be used for security system, server data path and other communication equipment. Data line protection shall be installed as per zone defined in IEC 62305.Type 1 device shall be installed between zone 0B and zone 1. Type 2 devices shall be installed before the equipment in zone 2 and 3. 4.3.3.6. Earthing System All electrical components are to be earthen by connecting two earth tapes from the frame of the component ring and will be connected via several earth electrodes. The cable arm will be earthen through the cable glands. The entire applicable IT infrastructure i.e signal junction or command centre shall have adequate earthing. Further, earthling should be done as per Local state national standard in relevance with IS standard. 1. Earthing should be done for the entire power system and provisioning should be there to earth UPS systems, Power distribution units, AC units, etc. so as to avoid a ground differential. GSCDL shall provide the necessary space required to prepare the earthing pits. 2. All metallic objects on the premises that are likely to be energized by electric currents should be effectively grounded. 3. There should be enough space between data and power cabling and there should not be any cross wiring of the two, in order to avoid any interference, or corruption of data. 4. The earth connections shall be properly made. 5. A complete copper mesh earthing grid needs to be installed for the server farm area, every rack need to be connected to this earthing grid. A separate earthing pit needs to be in place for this copper mesh. 6. Provide separate Earthing pits for Servers, & UPS as per the standards. 4.3.3.7. Junction Box, Poles and Cantilever 1. The MSI shall provide the Junction Boxes, poles and cantilever to mount the field sensors like the cameras, traffic sensors, traffic light aspects, active network components, controller and UPS at all field locations, as per the specifications given in the RFP. 2. The Junction Box needs to be appropriately sized in-order to accommodate the systems envisaged at the Junctions, and the MSI should design the Junction box for 1.5 times the actual size the MSI requires for utilization under the ATCS project. 3. The Additional 50% space in the Junction Box shall be utilized by GSCDL to accommodate any future requirements under other projects 4. The Junction Box for UPS with Battery bank needs to be considered separately 5. It should be noted that the MSI would have designed the Junction box keeping in mind the scalability requirements of ATCS project, and the additional 50%volume needs to considered over and above such requirement

6. The junction box should be designed in a way that, separate compartment will be available for separate system (i.e. ATCS Controller, Mini server, Active component, etc.). Each compartment shall have lock & key facility. There should be provision made to integrate the systems if required. 4.3.3.8. Cabling Infrastructure 1. The MSI shall provide standardized cabling for all devices and subsystems in the field, Viewing Centers and Interim ICCC/ICCC. 2. MSI shall ensure the installation of all necessary cables and connectors between the field sensors /devices assembly, outstation junction box, for pole mounted field sensors /devices the cables shall be routed down the inside of the pole and through underground duct to the outstation cabinet. 3. All cables shall be clearly labeled with indelible indications that can clearly be identified by maintenance personnel. The proposed cables shall meet the valid directives and standards. 4. Cabling must be carried out per relevant BIS standards. All cabling shall be documented in a cable plan by the MSI. 4.4. Design, Supply, Installation & Commissioning of the ATCS Field Equipment The Scope includes Supply, Installation, commissioning and Customization (as required) of various field systems which include Adaptive Traffic Control System (ATCS) at Traffic Junctions, ANPR Cameras, PA System, ECB System, Variable Message Signs, Red Light Violation Detection system, Speed Violation Detection System, Traffic Violation cameras, and other IT infrastructure required for successful operation of the ATCS modules. Based on the approved Survey report, the MSI will undertake the system configuration and customization in line with the changed, improved or specific requirements of Gandhinagar Police and GSCDL including: 1. The implementation methodology and approach must be based on the global best practices in-order to meet the defined Service Levels during the operation. 2. Best efforts have been made to define major functionalities for each subsystem of ATCS system. However, MSI should not limit its offerings to the functionalities proposed in this RFP and is suggested to propose any functionality over and above what has already been given in this tender. 3. The MSI shall design the field level equipment architecture to ensure maximum optimization of network equipment, poles, cantilever, mounting infrastructures, power supply equipment including, electric meters and junction box. 4. Finally approved/accepted solution for each component of ATCS systems shall be accompanied with “System Configuration” document and the same should be referenced

for installation of ATCS systems at Junctions that are identified within the scope of this project. 5. The MSI shall be required to submit a detailed installation report post installation of all the equipment at approved locations. The report shall be utilized during the acceptance testing period of the project to verify the actual quantity of the equipment supplied and commissioned under the project. 6. The MSI shall be responsible for obtaining all permits and approvals necessary to install the ATCS systems components as per the approved design. The sub-components included as part of the project for which field equipment needs to be deployed and integrated are given in the subsequent sections. 4.4.1.1. Adaptive Traffic Control System (ATCS) The broad scope of work to be covered under ATCS sub module will include the following, but is not limited to: 1. Preparation of Solution Architecture as per project blueprint to develop a final BOQ for installation traffic signaling systems. 2. Installation of vehicle detectors, controllers, Traffic light aspects, poles, cantilevers, Junction Box and other required accessories at 10 traffic junctions for successful operation of the ATCS for GSCDL and Gandhinagar Traffic Police 3. Integration of ATCS field infrastructures with the proposed ATCS software application 4. Configuration of traffic signal at each of the junction along with development of signal control plan for individual operations, coordinated signal plan for the junction in sync with the area wide signal plan for different operating conditions. The operating conditions may include different peak and off-peak conditions, special events, contingency plans etc. 5. The MSI may design and propose energy saving signaling system by using solar powered signals or other advanced technologies. 6. For more details on technical and functional specifications of ATCS, MSI should refer to Annexure I for Functional and Technical specifications. 4.4.1.2. ANPR Cameras The broad scope of work to be covered under this sub module will include the following, but is not limited to: 1. The MSI shall install the ANPR Cameras at 5 junctions/locations across the city. This system shall automatically capture the license number plate of the vehicle at these junctions. 2. The MSI shall design, supply, and install the ANPR camera system as defined in the RFPs, all camera accessories such as IR Illuminators, camera housing and mounting shall be

installed by the MSI. The MSI shall supply all of the necessary equipment for the camera and local processing system, including but not limited to: computers, local storage, and ancillary camera equipment, camera poles, warning signs and shall make the final connections to the camera. 3. The MSI shall be responsible for providing all the necessary IT infrastructure for detection, analysis, storage & retrieval of the number plate information at Interim ICCC/ICCC or any other location as specified in the RFP. 4. For more details on technical and functional specifications of ANPR Cameras, MSI should refer to Annexure I for Functional and Technical specifications.

4.4.1.3. Red Light Violation Detection (RLVD) System The broad scope of work to be covered under this sub module will include the following, but is not limited to: 1. The MSI shall install the RLVD Systems at 5 traffic junctions across the city. This system shall capture the infractions of Red light and stop line violations at these junctions. 2. The MSI shall design, supply, and install the RLVD system as defined in the RFPs, all wiring connections to the traffic signal controllers and to the camera platforms shall be installed by the MSI. The MSI shall supply all of the necessary equipment for the camera and detection system, including but not limited to: computers, ancillary camera equipment, camera housings, camera poles, warning signs and shall make the final connections to the camera. 3. The solution proposed by the MSI shall seamlessly integrate with the E-Challan system proposed under the scope of this project. GSCDL shall facilitate to get access to the Vaahan and Sarathi database. Bidder shall be required to access the same through use of appropriate APIs. 4. The MSI shall be responsible for providing all the necessary IT infrastructure for analysis, storage & retrieval of the infraction information at Interim ICCC/ICCC or any other location as specified in the RFP. 5. For more details on technical and functional specifications of Red Light Violation Detection (RLVD) system, MSI should refer to Annexure I for Functional and Technical specifications. 4.4.1.4. Speed Violation Detection System The broad scope of work to be covered under this sub module will include the following, but is not limited to: 1. The MSI shall install the Speed Violation Detection Systems at 5 locations across the city. This system shall capture the infractions of speed violations at these locations.

2. The MSI shall design, supply, and install the speed violation detection system as defined in the RFPs, all wiring connections for the system shall be installed by the MSI. The MSI shall supply all of the necessary equipment for the camera and detection system, including but not limited to: sensors, computers, ancillary camera equipment, camera housings, camera poles, warning signs and shall make the final connections to the camera. 3. The solution proposed by the MSI shall seamlessly integrate with the E-Challan system proposed under the scope of this project. 4. The MSI shall be responsible for providing all the necessary IT infrastructure for analysis, storage & retrieval of the infraction information at Interim ICCC/ICCC or any other location as specified in the RFP. 5. For more details on technical and functional specifications of Speed Violation Detection system, MSI should refer to Annexure I for Functional and Technical specifications. 4.4.1.5. Variable Message Sign (VMS) Boards The broad scope of work to be covered under this sub module will include the following, but is not limited to: 1. The MSI shall install IP based VMS boards on approximate 5 locations across city of Gandhinagar. These VMS boards shall have different characteristics depending upon the location and purpose of installation. VMS board displays are to be controlled by Gandhinagar Traffic Police personnel from the Interim ICCC/ICCC. The purpose of the VMS boards is to provide the commuters with information about traffic conditions and alternate routes in case of high traffic on roads. 2. The MSI, in consultation with Traffic Police can propose alternate locations apart from the locations mentioned in this RFP for installing the VMS boards where their effectiveness in communicating information about traffic conditions in Gandhinagar will be maximized. 3. Gandhinagar Traffic Police shall review and approve the proposed locations. The MSI shall install the VMS boards on the approved locations. 4. For more details on technical and functional specifications of VMS boards, the MSI should refer to Annexure I for functional requirements and technical specifications. 4.4.1.6. Public Address (PA) System & Emergency Call Box (ECB) System The broad scope of work to be covered under this sub module will include the following, but is not limited to: 1. The MSI shall install IP based Public Address System as part of the information dissemination system at 10 locations in the city. These systems shall be deployed at identified junction to make public interest announcements. The system deployed shall be IP based and have the capability to be managed and controlled from the Interim ICCC/ICCC

2. The MSI shall also install Emergency Call Box/Panic buttons at 10 locations in the city. These systems shall be deployed at identified junction for ease of access by citizens of Gandhinagar city. 3. The MSI, in consultation with Traffic Police can propose alternate locations apart from the locations mentioned in this RFP for installing the PA system & ECB system where their effectiveness in communicating information about traffic conditions in Gandhinagar will be maximized. 4. Gandhinagar Traffic Police shall review and approve the proposed locations. The MSI shall install the PA & ECB system on the approved locations. 5. For more details on technical and functional specifications of IP based PA system and ECB system, the MSI should refer to Annexure I for functional requirements and technical specifications. 4.4.1.7. E-Challan Devices The MSI is required to seamlessly integrate with the existing e-Challan system.

4.5. Design, Supply, Installation, Commissioning and Testing of Smart Pole The bidder shall be responsible to design, implement and maintain solution as mentioned in this RFP and to provide the services as specified. The following Smart components needed to be implemented as part of the RFP;  Intelligent Poles  Smart LEDs  Surveillance  Smart Billboards  Environmental Sensors  Wi-Fi  SOS panic button on pole The Concessionaire has to deploy approximately 18 intelligent poles in the project. The locations of such poles have been tentatively finalized along with GMC authority and are subjected to change based on site condition and actual circumstances . 4.5.1. LED based Smart Street Light Electric street lights are essential elements of a municipal environment and services. They affect resident sense of safety while influencing a city’s ability to create an inviting environment for business and tourism. Unfortunately, outdoor lights are also a major energy draw. Therefore following are desired in designing, implementation and O&M of LED based Smart Street Lighting:

 Reduce energy consumption, cost, and its maintenance  Enhance situational awareness, real-time collaboration, and decision making across city  Add intelligent IT innovations to civic utilities, public safety without adding significantly more physical infrastructure  Real-time data communications with low latency (or minimal delay), to improve operational efficiency  Creation of the foundation of Smart City Gandhinagar by implementing a smart city platform through ‘networked’ LED street light installation and an advanced Centralized LED Control & Monitoring application  Ensure efficient operation and maintenance of street lighting services using the smart city platform The existing streetlights to be retrofitted with particular wattage of LED luminaire in line with the specifications and as per national lighting code, as published by the bureau of Indian standard. Providing, erection and commissioning of new street light feeder panels with feedback facility using GSM/GPRS/ETHERNET technology or any other compatible technology and having compatibility to communicate with LED luminaire to achieve two step (up to 50%) dimming with an astronomical On/Off timer at pre-determined time & monitor parameters like load & consumption. OEMs having NABL accredited lab certification for Electrical, Optical & Electronics would be preferred. Two step dimming functionality shall only be provided for luminaires having power of more than 50W. Luminaires with power <90W shall be controlled (ON/OFF) and monitored in groups from their respective feeder panels upon instructions from centralized software. Bidder is expected to carry out necessary field surveys to verify the status of switching points, physical installations, geographic area covered and scope of the project defined so as to fully satisfy themselves on the existing field conditions and their scope. They will also be responsible for reviewing the baselines established pursuant to Energy Audits completed recently and satisfy themselves on the scope and feasibility of the project implementation for Feeder panel and Smart LED light fixtures. Scope of Work – Smart LED The Bidder needs to retrofit the aforementioned luminaires, other than LED, with LED luminaires and make the entire street lights smart. Each and every LED should be monitored and controlled from the Command and Control Center with the aid of a centralized software. The scope of work includes but is not limited to;  Supply, installation, testing and commissioning, O&M of all equipment system to meet the requirement as defined in specifications  Bidder shall be responsible for conducting GIS/GPS mapping of street lighting switching points and rationalize the coverage area under the switching points.

 The Bidder will ensure pole numbering with linkage to the respective switching points/feeder panels which caters to these poles. The Feeder panels and switching points from which the street lights on poles are connected and billed will also be numbered using suitable indelible method in consultation with GSCDL. Pole marking done by Energy Auditors in recent months may be made use of to the extent possible. The count of street light fixture on each pole numbered should be verified by GSCDL. Bidder will ensure that these numbers are not erased during the concession period. Similarly, any modifications done in the current system has to be appropriately fed to the GPS data and it should be updated on regular basis by Bidder  All the machineries and equipment required for implementation of the project is to be arranged by the Bidder, GSCDL has to provide only authorization and necessary clearance and permission if required  The quality of the luminaries/ Lux level will be maintained by Bidder during the project life. The Bidder has to follow all necessary safety guidelines/directions issued by Municipal Corporation from time to time  Design, supply, installation, commissioning of LED streetlight systems as per specifications with all fixtures, fittings compatible with existing poles and other related works  The Bidder will have full responsibility of warranty of LED’s/fixture for the entire concession period and warranty will start from the date of successful commissioning of the switching Points/ Gateway/ Controllers  Receipt, storage, preservation and conservation of equipment at the Site  Reliability tests and performance and guarantee tests on completion of commissioning  Labeling of information shall distinctly and indelibly marked on the housing like, Year of Manufacturing, Batch no., Serial no., Name of manufacturer, Rated wattage and Voltage(Input) & rated Lumen  Design, Installation, testing and O&M of Central Management Software for remotely monitoring and Controlling of LED luminaires from the Command and Control Center  Undertake measurement of the energy usage and lighting level of the street lighting segment after successful installation of the street lights  Implementation of National Lighting Code illumination parameters towards safety of motorists & pedestrians  The Bidder will be fully responsible for all kind of theft including electricity. The feeder panel should be equipped to raise an alarm and command center in case of electricity theft  Bidder will liaison with Torrent Power during pre and post implementation periods of the project for addressing all the electricity billing issues such as average billing, metering, replacement of defective meters, reduction or increase in contract demand as per the actual loads, power factor incentives etc. GSCDL will facilitate all such meetings; Bidder will obtain

all necessary approvals, sanctions, licenses in the name of Bidder for installation of proposed equipment pertaining to the project from the concerned competent authorities and maintain validity of the same at all times during the project duration. Bidder will bear the charges or pay deposits or any other amount for such approvals/licenses/sanctions as may be necessary. GSCDL will facilitate the requirement/clearances as and when required. Post satisfactory completion of installations, independent energy auditor will establish the savings on the feeder panel and submit a report to GSCDL. GSCDL shall issue “Commissioning Certificate” for switching point/meters only if the energy savings are found to be equal or more than the guaranteed savings proposed by the Bidder

 Any other permission apart from RoW will be taken by Concessioner, however GSCDL will facilitate the requirement/clearances as and when required

4.5.2. Technical Architecture of the Smart Street Light Following is an indicative technical architecture of the Smart Street Light for Concessionaire’s reference;

The luminaire node can communicate via a Low Power Radio Frequency (LPRF) through a gateway or directly through GPRS/GSM etc. with Centralized Command and Control software.

4.5.3. Recommended Levels of Illumination (as per BEE guidelines) # Type of Road Characteristics Average Level of Ratio of Minimum/ Road Illumination on Average Illumination

Road Surface in Lux 1 A-1 Important traffic routes carrying 30 0.4 fast traffic 2 A-2 Main roads carrying mixed traffic 15 0.4 like city main roads/streets, arterial roads, throughways 3 B-1 Secondary roads with 8 0.3 considerable traffic like local traffic routes, shopping streets 4 B-2 Secondary roads with light traffic 4 0.3  Operation & Maintenance Energy efficiency should be achieved by a comprehensive Operation & Maintenance. Following are the indicative activities the Bidder shall perform during O&M period;  Replacing defective lamps, accessories, and wires  Early rectification of cable faults  Regular maintenance of street light conductors and underground cables  Making sure that cables are joined properly  Regular maintenance of service cabinet/fuse box to avoid loose connections  Regular cleaning of the luminaire cover to keep it free of dust/dirt and increase light output  Regular maintenance of smart street light control system like LED controller, feeder panels etc.  Regular updates and upgrades of the centralized software at command and control center

 The Bidder shall monitor the electrical load on each phase & each circuit in the panel & also maintain load balance equally on all the phases. Bidder shall never allow any circuit to be overloaded. However, Concessioner need to highlight the areas with proper justification where load balancing is not possible 4.5.4. Public Wi-Fi Hot Spot Wi-Fi serves as the foundation for creating a connected city to access the wireless internet service with ease and convenience. For this purpose GSCDL has identified locations within the Municipal limits of Gandhinagar where these services has to be provided to citizens. For implementing the same the Bidder will carry out survey at these 18 locations and will deploy the access points as required for providing the Wi-Fi services. As a part of Wi-Fi solution the Bidder needs to provide Wi-Fi controller, DNS, Internet bandwidth from Internet Service Provider (ISP).

For installation of Access Points, if there is any requirement of additional poles, the same will be provided by Bidder at its own cost with prior approval from GSCDL The objective is to implement wireless networking technology that uses radio waves to provide wireless high-speed Internet and network connections. All wireless networking equipment must be based on the IEEE standards of 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac and 802.1p compatible. Scope of Work – Wi- Fi The Bidder shall be responsible for establishment of Wi-Fi network at the selected location in the Gandhinagar, these locations are normally tourist spots, public places or any other identified place by GSCDL. Bidder shall provide Operation & Maintenance throughout the concession period from the date of commissioning. The broad scope of work for the Bidder during the entire project period would be as under;  The Bidder Shall undertake a Site-survey of all the specified sites and submit a site wise survey report to GSCDL mentioning the location &number of Access Points (APs) required to be installed at each site.  Bidder proposal must provide all the necessary electronic components needed to provide wireless access to the public. This includes but is not limited to Wireless controllers, Access points, Power over Ethernet devices, L2 and L3 managed switches, Routers, UPS, passive components i.e UTP, OFC, Electric wires, racks etc.  The Bidder shall install the Access Points at approved locations (on directions by GSCDL after approval of Site-Survey report). The power points, connectivity and LAN points will be the responsibility of Bidder. GSCDL will facilitate the requirement/clearances as and when required  Bidder shall properly Wall Mount/ Pole Mount the Access Points at approved locations with external mounting kit as per OEM standard practice.  The Bidder shall install the AP Controller, NMS, NAS and required software at Command & Control Center  The Patch Cords, Power adapter, Power cables, connectors, mounting kit and other required accessories for successful commissioning of the Wi-Fi network shall be provided by the Bidder and shall be properly cased and tied such that it doesn’t get broken  All intended coverage areas must be covered with wireless AP/array for high rate data applications. For density concerns, there must be multiple radios per classroom/area. Each wireless AP/array must be 802.11 a/b/g/n/ac 3x3:3 MIMO WAVE2 capable and be able to scale without adding additional controllers or user licenses. At each site Bidder must consider at least one primary controller and secondary controller to avoid a single point of failure.  The controller should be configured with 1 + 1 in Active-Active Load Balancing mode.

 Hardware / Software based controller should be ready for supporting 100 AP’s and 10000 devices from day one to run in Active-Standby / Active-Active Load Balancing Mode, with scalability for 500 AP support in future.  Each wireless device (not system) must support per SSID traffic shaping and limiting at line- rate at the Access Point (not controller). This is to prevent additional data on the network  Each wireless device (AP) must employ a future-proof modular architecture for upgradability to future standards  Bidder must include PoE-injectors in the pricing and clearly define where PoE injectors are needed  System must include a centralized management system that provides a platform for central management of all devices across the network  Where ever applicable, Bidder shall have to integrate the existing wired LAN and internet links to the Wi-Fi solution  PVC case wiring should be done for the entire required passive cabling i.e. UTP and electrical wiring  Bidder will ensure a secure Wi-Fi connectivity and internet access through user Login ID and password to all the subscribers with central authentication mechanism  Bidder shall ensure that unique user ID and Password do not have provisions for simultaneous multiple logins  Policy on validity of the user ID and Password for internet access should be configurable as per the requirement.  Wi-Fi access points (APs) must be configured to use cryptographic keys or other methods to ensure that only authenticated users can use the Wi-Fi services  Internal / External AAA server should be deployed ensuring DOT guidelines for providing public Wifi access. The log trails for any specific user shall be made available online for at least last 3 months and the backup shall be kept for one year.  The system should be capable of managing automatically upgrade or degrade of end-user’s account after threshold usage (download/time limit) is reached  The Wi-Fi network should be secure and conform to the industry standard security requirement. Bidder shall suggest and help GSCDL team to deploy policies at various levels (i.e. on firewall, IDS, antivirus etc.) to prevent any attack/intrusion in the Wi-Fi network  The Bidder shall be responsible for integrating the Wi-Fi Network with the existing LAN/SWAN network  The Bidder shall be responsible for integrating the available payment gateway(s) at GSCDL for making online payments (if any) according to respective plans for internet usage

 The Bidder shall be responsible for integrating the available SMS gateway (HTTP) at GSCDL for automatically sending the required details/ information through SMS to the users as per the requirement e.g. during user registration, forgot password, password reset etc Operation & Maintenance

Following are the indicative activities the Bidder shall perform during O&M period;

 The Bidder need to ensure that adequate spares are retained at all times to meet onsite warranty/support and SLA requirements  The maintenance services involves comprehensive maintenance of all component covered under the contract, including repairing, replacement of parts, modules, sub-modules, assemblies, sub-assemblies, spares part, updating, security alerts and patch uploading etc. to make the system operational

 Bidder shall insure all the APs to ensure theft protection of all APs throughout the Bidder period 4.5.5. Surveillance City Safety and Security solution helps protect cities against crime, terrorism, and civil unrest, planning events, monitoring of infrastructure, encroachments etc. It helps law enforcement monitor public areas, analyze patterns, and track incidents and suspects enabling quicker response. Keeping the above perspective, GSCDL for this purpose is intending to implement the high definition IP based surveillance cameras across various locations within Gandhinagar. Installation of 18 nos. of CCTV cameras are required. The exact location will be finalized after detailed survey by the Concessioner, post award of the contract. The cameras should be housed on the intelligent/street poles. It shall also be possible to adjust the camera focus from a remote location. Following is an indicative scope of work;  Installation and commissioning work includes installation of all cameras, monitors, cables laid in PVC conduit etc, commissioning all the systems at the pre-defined locations in the project area  The Bidder shall prepare the final camera distribution plan at all the camera locations in discussion with GSCDL  Actual location for placement of pole & number of cameras at each location, type of cameras, fixation of height & angle for the cameras would be done carefully to ensure optimum coverage  Bidder should use the industry best practices while positioning and mounting the cameras. Some of the check-points which need to be adhered by the Bidder while installing / commissioning cameras are as follows: o Ensure Project objectives are met while positioning the cameras, creating the required field of view

o Ensure appropriate housing is provided to protect camera from the on field challenges o Carry out proper adjustments to have the best possible image o Ensure that the pole /tower/ mast implementation is vibration resistant o During implementation period, in case any camera is damaged by a vehicular accident (or due to any other reason outside the control of Bidder) and needs repair, then the Bidder will need to repair / have the new camera within 15 days of the incidence. Damages are to be borne by Bidder in such cases through proper insurance.  Bidder will have to identify and obtain necessary legal / statutory clearances for erecting the poles and installing cameras, for provisioning of the required power, etc; the same will be facilitated by GSCDL. It is important to mention that a timely communication and required follow-up will be required by the Bidder for the clearances  During implementation period, in case the pole is damaged by a vehicular accident (or due to any other reason outside the control of MSI) and needs repair, then the MSI will need to repair / have the new pole within 15 days of the incident. Damages are to be borne by MSIs in such cases through proper insurance  For the successful commissioning &operation of the edge devices and to provide the video feeds to Command Control Centers, the Bidder will be required to provide electricity to the edge devices through the aggregation points. Bidder has to plan the power backup based upon the power situation across the city  The Bidder will be responsible for the solution deployment / customization for implementing end-to-end Surveillance System including its integration with other components as required.  The Bidder will ensure that the best practices for software development and customization are used during the software development/customization and implementation exercise  If at any stage the CCTV online data is required to be connected to Police Control Room/Command Center, the Bidder will connect it to the same 4.5.6. Variable Messaging Boards As a part of the beautification of certain specific locations in the city of Gandhinagar, Bidder is required to implement 18 variable Messaging Boards housed on intelligent poles. GSCDL will have rights for usage of advertisement display boards for 100% time for displaying new/information. These sites could provide information about various schemes, policies of Government being implemented for the welfare of citizens of Gandhinagar. It shall be possible to change the advertisements /Messages in these Variable Messaging Boardss from a centralized location. 4.5.7. Environmental Sensor

Bidder shall require to integrate environmental sensor for providing air quality, temperature, and humidity. These Sensors should be integrated into the intelligent poles. It is expected that each ward will have one environment sensor Each environmental Sensor should be able to measure following parameters;  Temperature  Humidity  CO  CO2  NO2  SO2  PM2.5  PM 10 4.5.8. Integrated Command and Control Centre The Bidder has to integrate all the smart pole components at centralized command and control center with an integrated operations and dashboard application that will integrate various Smart City components implemented in this project and in future. The Integrated command and control center can monitor and control, via the centralized application, the smart components like Smart LED, Smart Surveillance, Access Points for the public Wi-Fi, Variable Messaging Boards and Environmental Sensors. All the hardware and software issues related to smart pole will be the responsibility of the Bidder.

4.6. Design, Supply, Installation and Commissioning of Solid Waste Management

4.6.1. Scope of Work The scope of work for the selected implementing agency will include supply, installation and implementation of Web based tracking and monitoring system with RFID, BLS based combined with integration with existing systems with GMC. Along with that, it will also include the post implementation support and maintenance of RFID, BLS Tracking and Monitoring solution The primary scope of work will include:

End-to-End Solution to implement and to provide Support Services & Maintenance.

1. Implementation of “Door to Door Collection Monitoring System” 1.1. Supply and installation RFID tags and readers.

1.2. Design and integrate Door to Door Tracking and Monitoring System

3. SI should provide Automatic Vehicle Locator solution to vehicles at primary and secondary collection points

4. SI should provide GPS based attendance management system to the staff

5. SI should install Surveillance cameras at bulk waste generation points.

6. SI Shall provide an MIS System which shall be capable of recording the details of daily waste receipt, waste processed and waste disposed in terms of tonnage. The solution provided shall be automated by having a computerized weigh bridge. The data shall be transmitted online to the ICCC

7. Integrating data feed from waste disposal site (data feed access would be provided by GSCDL/GMC) like feeds from CCTV camera and Data from Weigh Bridge

8. Sizing of Hardware, software and network devices required in the data Centers for using the Integrated SWM.

9. Design, Development, Supply, Deployment & Implementation of Web Based Application software integrated with GPS, RFID devices, VTMS and complaint management modules.

10. Maintenance of RFID devices and after warranty period including the replacement of devices in cases of damage, new vehicle or any other change.

11. Maintenance of web based application for Integrated SWM., during and after warranty period.

12. Provide resources for support, maintain and administering the system. 13. Integration of SWM with ICCC 14. Provide training to GSCDL resources for operating the tracking system.

Process Diagram for ISwM

4.6.2. Components of Proposed Architecture Details and role of the components of the expected solution architecture will be as follows:

RFID/BLS Only Bins and Households of GMC will be installed with an RFID tag or BLS to identify each object associated with the tag. Each tag will contain a unique identification code. This will help in the tracking of the bins individually. The RFID readers will be installed in each vehicle which will read the radio frequency signals of the tags installed on the bins from which the garbage is collected. The information pertaining to the collection of the garbage and the garbage bins being covered will be sent to the tracking device for creating the reports about the bins covered by the garbage collection vehicles giving the identification code of each bin being covered. Information transmission The information will be collected by the tracking device and this information will be sent to the tower using the GPRS signal for the transmission of the information. The GPRS tower will communicate with the data centre using the transfer protocol to transfer the information collected from the various vehicles. The GSCDL cloud data centre will be equipped to collect the data and to produce the reports. The central server will also have digital maps which will allow seeing GSCDL user about the location of the vehicles on that map. All the information will now be available over the internet and physical checking will be eliminated. The routing can now be given to the drivers using this system and tracking can be done automatically instead of having multiple check points.

Components of Proposed Architecture a. Garbage Collection points b. Bin locations

c. Departmental Offices d. Dumping grounds e. Transfer stations f. Motor loading points g. Department workshops h. Ward offices i. Others (as per GSCDL request) The accuracy of these locations should be 3 to 5 meters. The implementing agency shall use these locations over the maps and shall deliver the same to GSCDL in any standard GIS format. 4.7. Smart Elements- Kiosks and Wayfinders

4.7.1. The essential components of the Integrated Transport management system are:

1. Wayfinder Showing people how to find their way around a large facility or building complex is not an easy task. And no matter what type of company, organization or institution it is, the routes are always dynamic. There are adjustments due to renovations, maintenance or spaces that change ownership Additionally, new visitors to the facility need to know how to get to the right place, appointment or find the right office. Creating a digital wayfinding strategy enables to easily adjust routes and maps and lead your visitors to the right place easily and quickly. The system shall be connected to central control center via wireless communication system provided using GSM /GPRS / 3G system. There are following 2 types of wayfinders as per requirements of Gandhinagar i. Internal Wayfinder ii. External Wayfinder

2. Kiosks

Kiosks offer great interactive possibilities that offer people extra service and at the same time have a cost-reducing effect on the organization providing it. i. Reduces personnel costs through facilitation of self-service ii. Helps pay utility bills like water tax, property tax, electricity bills etc. iii. Accelerates processes through attractive and easy menus iv. Offers customized route descriptions with wayfinding kiosks, equipped with a real or virtual keyboard v. Trigger passersby with general information, enticing them to touch the screen and have a message delivered about anything vi. Register visitors automatically using a card swipe or scan and alleviate wait time by offering content that is informative, educating or entertaining

The MSI’s scope of work shall include but will not be limited to the following broad areas. Details of each of these broad areas have also been outlined in subsequent sections of this document: 1. Assessment and Site Survey: Conduct a detailed assessment of any existing wayfinder or Kiosks systems and develop a comprehensive project plan, including: a. Assess the existing external wayfinder systems used around Gandhinagar City and site survey. b. Site Survey and feasibility study for Kiosks and wayfinders. c. Finalization of detailed technical architecture, gap analysis and project plan d. Obtain site Clearance obligations & other relevant permissions 2. Design, Supply, Installation and Commissioning of Field Equipment which includes the following components:  External Wayfinders  Internal Wayfinders  Kiosks Some of the Internal wayfinders and kiosk features need to be integrated for important locations as will be suggested by Authority. So, its expected of MSI to be able to provide field equipment which is capable of providing integrated wayfinder and Kiosk functionalities. 3. Requirement analysis and design of Network Connectivity for Integrated Transport Management. a. MSI is required to carry out detailed network requirement analysis and design for supporting solution and live data streaming to Data Centre, ICCC. b. Last mile connectivity including customer premise equipment (CPE) will be responsibility of GSCDL/Service provider. c. Integration and migration onto the city fiber network backbone envisaged as future Smart Solution Projects under Gandhinagar Smart City initiatives. 4. Hosting of Hardware and Software Infrastructure which includes design, supply, installation and commissioning of IT Infrastructure for the solution at Data Centre, Interim ICCC and ICCC. This consist of: a. IT Infrastructure including server, storage, other required hardware, application portfolio, licenses b. Interim ICCC/ICCC infrastructure including video walls, operator workstations, IP phones, joystick controller etc.

c. Establishment of LAN and WAN connectivity Interim ICCC/ICCC and DC limited to scope of infrastructure procured for the project 5. Capacity Building for GSCDL and GMC which includes preparation of operational manuals, training documents and capacity building support, including: a. Training of the city authorities and Interim ICCC/ICCC operators on operationalization of the system b. Support during execution of acceptance testing c. Preparation and implementation of the information security policy, including policies on backup and redundancy plan d. Developing standard operating procedures for operations management and other technical services to be rendered by Interim ICCC/ICCC e. Preparation of system documents, user manuals, performance manuals, etc. Operations and Maintenance services for the software, hardware and other IT and Non-IT infrastructure installed as part of the project after Phase wise Go-Live and 5 years after implementation or phase wise Go-Live. Warranty period of the product supplied under project i.e hardware, software, IT/Non-IT etc., will be considered after phase wise Go-Live.

4.7.2. Geographical Scope of services The following is a summary of the geographical extent of the project. The counts are indicative and may vary as per actual site condition and circumstances. Some of the Internal wayfinders and kiosk features need to be integrated. So, its expected of MSI to be able to provide field equipment which is capable of proving integrated wayfinder and Kiosk functionalities. 1. External Wayfinder Includes but is not limited to- all Government and Semi Government buildings, Board Corporates, Public/Private Buildings around sector 10, 11, 17 etc, area surrounding Mahatma Mandir. Count as found appropriate during survey and assessment 2. Internal Wayfinder 27 (indicative locations can be found in annexure for List of locations towards the

end of document) 3. Kiosks 13 (indicative locations can be found in annexure for List of locations towards the end of document)

Indicative Software Requirements includes but not limited to:

1 Incident Management System 2 Solution with mapped location and other features which include but not limited to utility payments ability, tourism info, weather info, allow grievance logins etc. 3 MIS

4.8. Integrated Transport Management system Architecture and Scope The Integrated Transport Management 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 of the Integrated Transport management system are:

1. Integrated Automated Vehicle Location Monitoring System

The Automated Vehicle Locating System (AVLS) shall primarily use GPS devices mounted on the vehicle as primary source of data for tracking purposes. The AVLS shall also facilitate Central Control Centre (CCC) as a source of information for real time on field operations and equip them with the details log for drill down of the critical events. The AVLS shall essentially comprise of following components:

1. GPS devices for city buses 2. OBU (On Board Unit)/GPS/Bus Driver Console The AVLS system shall enable operations team to monitor vehicle movement in real-time and synthesize the AVL field data to deliver the same on the public information system devices installed on Bus Stops, Terminals, Buses, Customer portal and mobile information delivery system.

2. Passenger Information System in Bus and at bus stops and ETA Prediction System

The passenger information system is an important component of integrated ITS system and renders an important consumer facing services. Accurate and timely PIS delivery facilitates consumer trust

on public transport service and also aids modal shift in long term, as the reliability and availability 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 to commuters will also be delivered via other electronic means like web portal and mobile app. This multi-channel commuter interface enables quick access to transport system and ensure citizens see the city transit system as safe and reliable alternative for travel purposes.

 The system shall consist of following units to offer users access to real-time information regarding operations of bus transit service and extend ease of information access related to travel needs: o PIS Display Screen ( LCD based) at Bus Stations o PIS Screen (Front and Back Display only) o PIS display ( LCD based ) in bus o Transit web portal for Bus Schedule & ETA, SMS o Mobile App  The PIS display systems at bus stations/In bus shall display real-time information of the route and estimated time of arrival using communication system installed within the station (Wired / Wireless) with the central AVLS / PIS Application. The system will have capabilities to clearly indicate the route no of the bus on the display to assist passengers.  The Authority web portal shall enable passengers to get information about the bus schedules on various routes operated by Authority and shall also have facility to deliver ETA based on the real-time data from central PIS system. PIS shall also be made available to users via mobile apps.

3. Vehicle Scheduling & Dispatch System

Vehicle scheduling & dispatch system will help GMC effectively coordinate drivers, dispatchers and call centers to streamline operations and enhance customer service. The solution will facilitate assignment of new orders and manage exceptions with robust real-time planning tools that will utilize robust route optimization engine.

4. Smart Bus stops Smart bus stop will essentially comprise of three major components ( i) Surveillance (iii) LCD based PIS (iii) Solar Roof top. The idea behind smart bus stop is to make bus stops more passenger friendly and safe. 5. In bus and at the bus stop surveillance

The aim behind surveillance at bus stop and in bus is to make sure both passengers and drivers are safe while commuting on public transport system. The surveillance will also act as deterrents to

criminal activity and inappropriate behavior, these cameras will provide passengers and drivers with an added sense of security, and can also supply valuable evidence during criminal investigations

6. Business Intelligence System

The schematic diagram below shows the systems envisaged under Integrated Transport management system and the information flow across the systems to be integrated.

The MSI’s scope of work shall include but will not be limited to the following broad areas. Details of each of these broad areas have also been outlined in subsequent sections of this document: 6. Assessment and Site Survey: Conduct a detailed assessment of existing IT systems and Infrastructure of GMC and develop a comprehensive project plan, including: a. Assess the existing IT systems used by GSRTC buses and site survey of bus shelters/stops b. Site Survey and feasibility study for smart bus stops c. Finalization of detailed technical architecture, gap analysis and project plan d. Obtain site Clearance obligations & other relevant permissions 7. Design, Supply, Installation and Commissioning of Field Equipment which includes the following components:  Automatic vehicle locating system ( AVLS)  Passenger information system in buses and at bus stops  Surveillance in buses and at bus stops  Smart bus stops – LCD PIS, Charging Points, Surveillance at bus shelter/stops 8. Requirement analysis and design of Network Connectivity for Integrated Transport Management. a. MSI is required to carry out detailed network requirement analysis and design for supporting ITMS solution and live data streaming to Data Centre, ICCC. b. Design , supply, installation and commissioning of OBU to Wi-Fi connectivity provided at bus depots to feed video surveillance to ICCC c. Last mile connectivity including customer premise equipment (CPE) will be responsibility of GSCDL/Service provider. d. Integration and migration onto the city fiber network backbone envisaged as future Smart Solution Projects under Gandhinagar Smart City initiatives.

9. Hosting of Hardware and Software Infrastructure which includes design, supply, installation and commissioning of IT Infrastructure for the solution at Data Centre, Interim ICCC and ICCC. This consist of: a. IT Infrastructure including server, storage, other required hardware, application portfolio, licenses b. Interim ICCC/ICCC infrastructure including video walls, operator workstations, IP phones, joystick controller etc. c. Viewing Centre infrastructure including LED displays, operator workstations, IP phones etc. d. Establishment of LAN and WAN connectivity Interim ICCC/ICCC and DC limited to scope of infrastructure procured for the project 10. Capacity Building for GSCDL and GMC which includes preparation of operational manuals, training documents and capacity building support, including: a. Training of the city authorities and Interim ICCC/ICCC operators on operationalization of the system b. Support during execution of acceptance testing c. Preparation and implementation of the information security policy, including policies on backup and redundancy plan d. Developing standard operating procedures for operations management and other technical services to be rendered by Interim ICCC/ICCC e. Preparation of system documents, user manuals, performance manuals, etc. Operations and Maintenance services for the software, hardware and other IT and Non-IT infrastructure installed as part of the project after Phase wise Go-Live and 5 years after implementation or phase wise Go-Live. Warranty period of the product supplied under project i.e hardware, software, IT/Non-IT etc., will be considered after phase wise Go-Live.

4.8.1. Geographical Scope of services The following is a summary of the geographical extent of the project. 4. PIS and controller 30 at GSRTC Bus stop 75*2 in Bus 5. On Board Unit 75 Buses 6. CCTV Surveillance 75 in Bus and 30 in bus stops 7. Smart bus stops 30  Surveillance  PIS & Controller

Software Requirements

1 Incident Management System 2 Vehicle planning, schedule and dispatch system 3 Web Portal 4 Mobile Application 5 MIS 6 Financial Management System 7 Business Intelligence System

4.8.2. Assessment and Site Survey for finalization of detailed technical architecture and project plan After signing of contract, the Systems Integrator needs to deploy local team (based out of Gandhinagar) proposed for the project and ensure that a Project Inception Report is submitted to GSCDL which should cover following aspects: 1. Names of the Project Team members, their roles and responsibilities 2. Approach and methodology to be adopted to implement the Project (which should be in line with what has been proposed during bidding stage, but may have value additions / learning in the interest of the project). 3. Responsibility matrix for all stakeholders 4. Risks the MSI anticipates and the plans they have towards their mitigation 5. Detailed project plan specifying dependencies between various project activities / sub- activities and their timelines 6. Installation locations geo mapped preferably on google earth to visually identify the geographical area The MSI shall conduct a comprehensive As-Is study of the existing Transport network of Gandhinagar which includes understanding current operating model, existing infrastructure of GSRTC buses and bus stops. The output of the As-Is study should be identification of the key performance indicators (KPI) for the project. The KPIs of the study shall be included in the survey. The following minimum parameters should be captured during the comprehensive study 1. Current ridership of GSRTC 2. Peak hour identification 3. Coverage of current transportation network 4. Physical and visual characteristics of the bus stops and buses 5. Travel times, delays between different points of the transportation network 6. Additional dependencies with respect to the available infrastructure and geometry at the junctions

7. Feasibility study of solar roof top at bus stops 8. Any other relevant data which the MSI anticipates will assist in establishing the benchmarks for the project The report shall also include the expected measurable improvements against each KPI as detailed out in the above ‘As-Is’ study after implementation of Integrated Transport Management project. The benchmarking data should also be developed to track current situation and desired state. The MSI shall study the existing business processes, functionalities, existing transport management systems and applications including MIS reporting requirements. The MSI will be responsible to propose transition strategy for dismantling of existing bus stops, and setting up of new smart bus stops with field components. The proposed strategy should clearly provide approach and plan for implementing the new bus stop while ensuring minimum disturbance to the road traffic and shall use appropriate static signage designating the work in progress status. Additionally, the MSI should provide a detailed To-Be designs for integrated transport management specifying the following: 10. High Level Design (including but not limited to) Application architecture, Logical and physical database design, Data dictionary and data definitions, ER diagrams and other data modelling documents and Physical infrastructure design for devices on the field 11. Application component design including component deployment views, control flows, etc. 12. Low Level Design (including but not limited to) Application flows and logic including pseudo code, GUI design (screen design, navigation, etc.), Database architecture, including defining data structure, data dictionary as per standards laid-down by Government of India/ Government of Gujarat. 13. Location of all field systems and components proposed at the bus stops and in Bus, (KML /KMZ file plotted on GIS platform like google earth etc.) 14. Height and foundation of Cameras, OBUs, PIS in bus and bus stops or any other field equipment. 15. Location of Bus stops 16. Location of Network Provider’s Point of Presence (PoP) 17. Electrical power provisioning The MSI shall also identify the customizations/ workaround that would be required for successful implementation and operation of the project. The report should take into consideration following guiding principles: 8. Scalability - Important technical components of the architecture must support scalability to provide continuous growth to meet the growing demand of the Gandhinagar city. The system should also support vertical and horizontal scalability so that depending on

changing requirements from time to time, the system may be scaled upwards. There must not be any system imposed restrictions on the upward scalability in number of field devices. Main technological components requiring scalability are storage, bandwidth, computing performance (IT Infrastructure), and software / application performance. In quantitative terms, there may not be major change in number of Command Centers. However, command center should have to be shifted from Interim ICCC to ICCC, once ICCC gets operational. 9. Availability - Components of the architecture must provide redundancy and ensure that are no single point of failures in the key project components. Considering the high sensitivity of the system, design should be in such a way as to be resilient to technological sabotage. To take care of remote failure, the systems need to be configured to mask and recover with minimum outage. The MSI shall make the provision for high availability for all the services of the system. 10. Security - The architecture must adopt an end-to-end security model that protects data and the infrastructure from malicious attacks, theft, natural disasters etc. MSI must make provisions for security of field equipment as well as protection of the software system from hackers and other threats. Using Firewalls and Intrusion detection systems such attacks and theft should be controlled and well supported (and implemented) with the security policy. The virus and worms attacks should be well defended with gateway level Anti-virus system, along with workstation level anti-virus mechanism. Furthermore, all the system logs should be properly stored & archived for future analysis and forensics whenever desired. GSCDL may carry out the Security Audit of the entire system post acceptance / operationalization through a Third Party Auditor (TPA) if required. The following guidelines need to be observed for security: e. Build a complete audit trail of all activities and operations using log reports, so that errors in system – intentional or otherwise – can be traced and corrected. f. Access controls must be provided to ensure that the system is not tampered or modified by the system operators. g. Implement data security to allow for changes in technology and business needs. h. The security of the field devices must be ensured with system architecture designed in a way to secure the field devices in terms of physical damage & unauthorized access. 11. Manageability - Ease of configuration, ongoing health monitoring, and failure detection are vital to the goals of scalability, availability, and security and must be able to match the scalability of the system 12. Interoperability - The system should have capability to take inputs from other third party systems as per situational requirements 13. Open Standards - System should use open standards and protocols to the extent possible without compromising on the security

14. Convergence - GSCDL has already initiated many projects which have state of the art infrastructure at field locations deployed under them. The Integrated Transport Management Infrastructure should be made scalable for future convergence needs. Under the smart city program, GSCDL has envisaged to create a state of the art infrastructure and services for the citizens of Gandhinagar, hence it is imperative that all infrastructure created under the project shall be leveraged for maximum utilization. Hence the MSI is required to ensure that such infrastructure will allow for accommodation of equipment’s being procured under other smart city projects. The procedure for utilization of the infrastructure will be mutually agreed between the GSCDL and MSI. Sub-contracting / Outsourcing shall be allowed only for the work which is allowed as mentioned in the clause with prior written approval of GSCDL. However, even if the work is sub-contracted / outsourced, the sole responsibility of the work shall lie with the MSI. The MSI shall be held responsible for any delay/error/non-compliance etc. of its sub-contracted vendor. The details of the sub-contracting agreements (if any) between both the parties would be required to be submitted to GSCDL. Sub-contracting / outsourcing would be allowed only for work such as: 1. Passive Networking & Civil Work during implementation, 2. FMS staff for non- IT support during post-implementation 3. Services of professional architect for design of Interim ICCC/ICCC 4.8.3. Site Clearance obligations & other relevant permissions 4.8.3.1. Survey and Commencement of Works Prior to starting the site clearance, the MSI shall carry out survey of field locations as specified in Annexure VIII, for buildings, structures, fences, trees, existing installations, etc. The GSCDL shall be fully informed of the results of the survey and site clearance shall then be agreed with the GSCDL. 4.8.3.2. Existing Bus stops The infrastructure of existing bus stops will be leveraged under the scope of the ITMS project. 4.8.3.3. Electrical works and power supply The MSI shall directly interact with GSCDL for provision of mains power supply at all desired locations for Integrated Transport Management system. MSI is expected to clearly define the power availability and requirements as part of AS-IS report and same will be taken care by GSCDL. 4.8.3.4. Lightning-proof measures The MSI shall comply with lightning-protection and anti –interference measures for system structure, equipment type selection, equipment earthing, power, signal cables laying. The MSI shall describe the planned lightning-protection and anti –interference measures in the As-Is report. Corresponding lightning arrester shall be erected for the entrance cables of power line, video line, data transmission cables. All crates shall have firm, durable shell. Shell shall have dustproof, antifouling, waterproof function & should capable to bear certain mechanical external force. Signal

separation of low and high frequency; equipment’s protective field shall be connected with its own public equal power bodies; small size/equipment signal lightning arrester shall be erected before the earthling. The Internal Surge Protection Device for Data Line Protection shall be selected as per zone of protection described in IEC 62305, 61643-11/12/21, 60364-4/5. Data line protection shall be used for security system, server data path and other communication equipment. Data line protection shall be installed as per zone defined in IEC 62305.Type 1 device shall be installed between zone 0B and zone 1. Type 2 devices shall be installed before the equipment in zone 2 and 3. 4.8.3.5. Earthing System All electrical components are to be earthen by connecting two earth tapes from the frame of the component ring and will be connected via several earth electrodes. The cable arm will be earthen through the cable glands. The entire applicable IT infrastructure i.e signal junction or command centre shall have adequate earthing. Further, earthling should be done as per Local state national standard in relevance with IS standard. 1. Earthing should be done for the entire power system and provisioning should be there to earth UPS systems, Power distribution units, AC units, etc. so as to avoid a ground differential. GSCDL shall provide the necessary space required to prepare the earthing pits. 2. All metallic objects on the premises that are likely to be energized by electric currents should be effectively grounded. 3. There should be enough space between data and power cabling and there should not be any cross wiring of the two, in order to avoid any interference, or corruption of data. 4. The earth connections shall be properly made. 5. A complete copper mesh earthing grid needs to be installed for the server farm area, every rack need to be connected to this earthing grid. A separate earthing pit needs to be in place for this copper mesh. 6. Provide separate Earthing pits for Servers, & UPS as per the standards. 4.8.3.6. Cabling Infrastructure 1. The MSI shall provide standardized cabling for all devices and subsystems in the field, Viewing Centers and Interim ICCC/ICCC. 2. MSI shall ensure the installation of all necessary cables and connectors between the field devices. 3. All cables shall be clearly labeled with indelible indications that can clearly be identified by maintenance personnel. The proposed cables shall meet the valid directives and standards. 4. Cabling must be carried out per relevant BIS standards. All cabling shall be documented in a cable plan by the MSI.

4.8.4. Design, Supply, Installation & Commissioning of the Integrated Transport Management solution The Scope includes Supply, Installation, commissioning of AVLS, and smart bus stops and other IT infrastructure required for successful operation of the Integrated Transport modules. Based on the approved Survey report, the MSI will undertake the system configuration and customization in line with the changed, improved or specific requirements of GSCDL including: 1. The implementation methodology and approach must be based on the global best practices in-order to give public transportation in Gandhinagar the required facelift. 2. Best efforts have been made to define major functionalities for each subsystem of AVLS and Smart Bus stops. However, MSI should not limit its offerings to the functionalities proposed in this RFP and is suggested to propose any functionality over and above what has already been given in this tender. 3. The MSI shall design the field level equipment architecture to ensure maximum improvement in operational efficiency of Transportation system in city of Gandhinagar. 4. Finally approved/accepted solution for each component of Integrated Transport Management System shall be accompanied with “System Configuration” document and the same should be referenced for installation of the solution at bus stops that are identified within the scope of this project. 5. The MSI shall be required to submit a detailed installation report post installation of all the equipment at approved locations. The report shall be utilized during the acceptance testing period of the project to verify the actual quantity of the equipment supplied and commissioned under the project. The MSI shall be responsible for obtaining all permits and approvals necessary to install the Integrated Transport Management System components as per the approved design.

4.9. Design, Configuration, Installation and Commissioning of DC and DR on Cloud

GSCDL would like to host entire IT Infrastructures (Compute, Network, and Storage) and Aplication on the cloud and wishes to engage a Cloud Service Provider to provide Managed Cloud services (hereafter referred to as “Service Provider”, “Selected Agency”, “Vendor”, and “Bidder”) for a period of 5 years for this project. The Scope of work includes but not limited to, 1. MSI shall be respoinsible for detail designing and Solutions architecture of required Infrastructure, setup, applications of GSCDL 2. Understanding the existing Infrastructure, setup, software, applications of GSCDL and planning for Cloud DC-DR solution.

3. MSI must ensure that cloud virtual machine is into separate network tenant and virtual LAN. 4. MSI must ensure that cloud virtual machines are having private IP network assigned to cloud VM. 5. MSI must ensure that all the cloud VMs are in same network segment (VLAN) even if they are spread across multi datacenters of CSP. 6. In case of scalability like horizontal scalability, the MSI should ensure that additional require network is provisioned automatically of same network segment. 7. MSI must ensure that GSCDL gets ability to map private IP address of cloud VM to public IP address as require from portal of CSP. 8. MSI must ensure that public IP address of cloud VMs remains same even if cloud VM gets migrated to another datacenter due to any incident. 9. MSI must ensure that public IP address of cloud VMs remains same even if cloud VM network is being served from multiple CSP datacenters. 10. MSI must ensure that the public network provisioned for cloud VMs is redundant at every points. 11. MSI must ensure that cloud VMs are accessible from GSCDL private network if private links P2P/MPLS is used. 12. MSI must ensure that there is access to cloud VMs if there is a requirment to access it using IPSEC/SSL or any other type of VPN. 13. MSI should ensure that cloud VM network is IPV6 compatible. 14. MSI should have provision of dedicated virtual links for data replication between their multiple datacenter in order to provide secure data replication for DR services. 15. MSI should ensure use of appropriate load balancers for network request distribution across multiple cloud VMs.

4.9.1. DR Plan and Implementation

Disaster Recovery as a Service 1. MSI is responsible for Disaster Recovery Services so as to ensure continuity of operations in the event of failure of primary data center meet the RPO and RTO requirements. 2. RPO should be less than or equal to 15 minutes i.e. the replication cycle should run at maximum 15 minutes. 3. RTO shall be less than or equal to 2 hour.

4. During the change from Primary DC to DR or vice-versa (regular planned changes), there should not be any data loss. 5. The Primary DC-Cloud and the DR-Cloud should be in different seismic zones. 6. CSP should provision VM’s for both DC and DR. GSCDL shall pay the CSP Vendor as per ‘Pay as you use’ model on hourly basis for the resources used at the Cloud-DR site. 7. During normal operations, the Primary Cloud Data Centre will serve the requests. The Disaster Recovery Site will not be performing any work but will remain on standby. During this period, the compute environment for the application in DR shall be available on demand basis for a functional DR and minimum compute if required, as per the solution offered. The application environment shall be installed and ready for use. 8. DC Data shall be replicated (Active-Active) on an ongoing basis at Cloud-DR, as per designed RTO/RPO and replication strategy, data consistency and integrity should be maintained 9. Database should be in Active mode at DC and Passive mode at DR, data consistency and integrity should be maintained. 10. In the event of a site failover or switchover, DR site will take over the active role, and all the requests will be routed through that site. Application data and application states will be replicated between data centres so that when an outage occurs, failover to the surviving data centre can be accomplished within the specified RTO. This is the period during which the Compute environment for the application shall be equivalent to DC. The installed application instance and the database shall be usable and the same SLAs as DC shall be provided. The use of this Full Compute DR environment can be for specific periods during a year for the purposes of DC failure or DR Drills or DC maintenance. 11. The security shall be for full infrastructure i.e. Cloud-DC and Cloud-DR 12. Website and live application (both external and internal) should be routed seamlessly from Cloud-DC site to Cloud-DR site. 13. The MSI shall conduct DR drill one in every six months, of operation wherein the Primary DC has to be deactivated and complete operations shall be carried out from the DR Site. However, during the change from DC to DR-Cloud or vice-versa (or regular planned changes), there should not be any data loss. 14. The MSI shall clearly define the procedure for announcing DR based on the proposed DR solution. The MSI shall also clearly specify the situations in which disaster shall be announced along with the implications of disaster and the time frame required for migrating to DR. The MSI shall plan all the activities to be carried out during the Disaster Drill and issue a notice to the Department at least 15 working days before such drill. 15. RPO monitoring, Reporting and Events Analytics for the Disaster recovery solutions should be offered as part of the offering.

16. Any lag in data replication should be clearly visible in dashboard and alerts of same should be sent to respective authorities. 17. Training should be provided to the staff members and System Administrator on DR. 18. Services provider should provide the solution document of DR. 19. Selected bidder should have proper escalation procedure and emergency response in case of failure/disaster at DC. 20. Selected bidder shall provide support for all server maintenance activities. This would include periodic health check, on-demand troubleshooting, etc. from certified vendors. ITIL processes named problem, change, incident & configuration will be followed by selected bidder at DR site. 21. Selected bidder shall provide Disaster Recovery services during the event of Disaster. 22. The Selected bidder shall configure all the components and sub-components for end-to- end user access to all Windows applications/services. 23. The Selected bidder will have to demonstrate the DR site to run on thirty percent capacity for proving successful implementation of the DR site. 24. GSCDL reserves the right, on its own or via a third party auditor, to conduct overall testing at any point of time for the services delivered by the selected bidder. 25. The selected bidder shall make provisioning of requisite software licenses, Database licenses and other required monitoring software, tools for IT setup at DR site 26. The selected bidder shall undertake installation and configuration of operating systems, databases, storage solution and replication mechanism for all in-scope business application systems. 27. The selected bidder shall undertake installation and configuration of any other specialized applications/ software solution/Hardware solution required for the Disaster Recovery Setup. 28. The selected bidder would be solely responsible for implementation of all applications at DR site. All costs including licenses for application, OS, replication tools or databases if any shall be borne by the selected bidder 29. Automated switchover/ failover facilities (during DC failure & DR Drills) to be provided and ensured by selected bidder. The switchback mechanism shall also be automated. The selected bidder shall also provide a tool/ mechanism for GSCDL Cloud DC to trigger DR switchover (CSP to deliver Switch Over and Switch back) 30. Selected bidder shall provide support for the development of detailed activity plans for recovery for all systems. 31. Selected bidder shall provide support for the development of a detailed disaster recovery plan. This plan document will contain steps/procedures to switch over services to DR site

in the event of invocation of disaster at DC site. Selected bidder shall also document steps for restoring services from DR site to DC site. 32. Selected bidder shall provide support with the development of detailed operating manuals for the implemented replication solution from system administrator’s perspective.

4.9.2. Testing Following cloud resource deployment/provisioning, the testing of the same at CloudDC- DR site becomes very important. Therefore the service provider must perform following testing:  Infrastructure testing - The bidder should perform various testing procedures listed below on infrastructure (server, storage and network infrastructure) provided at Cloud site. Indicative list of test parameters are as follows a. VM testing b. Storage/Disk IO testing. c. Network throughput and latency testing d. CPU and RAM benchmarking testing e. Read/Write latency testing f. Data Replication Testing g. Firewall policy and configuration testing  Data Integrity Testing, Reverse Replication Testing and Switch over testing: The Cloud service provider will facilitate the FMS vendor and the application vendor of GSCDL to carry out these/ such testing, whenever required. 4.9.3. Post Implementation Maintenance & Support The service provider shall maintain and manage the system (cloud solution) for the entire period of the contract and shall be fully responsible for ensuring adequate CPU processing power, memory, storage, network, internet bandwidth and monitoring of the cloud services for optimum performance of the entire Cloud solution conforming to SLAs as per the Contract. The successful bidder has to provide post implementation support to maintain SLAs. During the O&M period (defined as period of 5 years), if the successful bidder is unable to comply with the support terms as mention in later section, the bidder will have to a pay a Penalty as specified under the SLA of this project. Post implementation support would also include support during scheduled DR drills (once every 6 months, which shall be performed by cloud provider of GSCDL), during regular operations while only replication is taking place, in disaster scenario when DR is active and operational, and during switchover and switchback.

4.9.4. Security Audit

The service provider shall conduct vulnerability and penetration test (to be conducted by a third party testing agency which should be CERT-IN empanelled and which is approved by GSCDL) on the proposed Cloud solution in every one year and reports should be submitted to GSCDL. Corrective action should be taken by the service provider within 3 months from the date of submission of the report. Compliance review should be done within 4 months from the date of submission of the report. Any non-compliance in the reports may lead to penalty clauses. The service provider needs to update the system in response to any adverse findings in the report, without any additional cost to GSCDL. GSCDL may also depute auditors to conduct security check/ vulnerability test/penetration test.

4.9.5. Cloud Management Portal

The MSI should provide Cloud Management Portal / Self provisioning portal including but not limited to,

 User Roles & Rights : GSCDL should be able to create users based on roles & rights.  Monitoring Reports  SLA Reports  Backup Reports  VM Status report  Provisioning /De-provisioning of VM’s  Creating templates for VM’s  Able to make changes in configurations

4.10. Design, Supply, Installation and Commissioning of IT Infrastructure at Viewing Center, Interim ICCC, main ICCC 1. The ICCC has been envisaged to be established in an approximate area of 10000 Square Feet for main ICCC at the new GMC building at Fire Station location. Till the time ICCC is operational, MSI is expected to establish Interim ICCC in the existing Municipal Corporation Office, Gandhinagar in an approximate area of 2000 Square Feet. Once the main ICCC is operational, then the MSI shall migrate the Interim ICCC to the ICCC.

Indicative list of Equipment’s for Interim ICCC

S. No. Description Unit of Measurement Indicative Quantity Video Wall Cubes- 70/72" 1. Number 10 LED in 5 X 2 matrix Video wall controller with 2. wall management Number 1 software Audio Mixer and speaker 3. Number 1 system

Multi-Function Laser 4. Printer (City Operations Number 2 Room) Operator Workstations (City Operations Room, Manager, Help Desk, 5. Number 18 technical support, contact centre, security room and war room )

6. IP Phones Number 20

7. Digital Set top boxes Number 1 65"/70" LED display to 8. present critical Number 1 information Display

9. IP Push to Talk Radio Number 1

10. Microphone Number 4

11. IP PABX System Number 1

12. PRI Modem pair Number 2

13. SMS Gateway modem Number 1

14. DG Set (For IT Load Only) Number 2 Air Conditioning for City 15. Number 3 Operations Room

16. Comfort Air Conditioning Number 4 UPS with Battery backup 17. Number 3 of 1 hour

18. Access Control System Lump sum 1

Electrical and power 19. Lump sum 1 cabling Electrical Cabling & 20. Necessary Illumination Lump sum 1 Devices 21. LAN and CAT-6 cabling Lump sum 1 Fire & Smoke Detection 22. Lump sum 1 System

23. Fixed Dome Cameras Number 6

Furniture for City 24. Operations Room Number 9 Operator Desks Furniture for City 25. Operations Room Number 1 Manager's Desk

Furniture for 'Technical 26. Number 8 Support Team Desks

Furniture for Security 27. Number 2 Room/Reception Desks Furniture for Meeting 28. Room meeting table and Number 1 chairs

Services for DTH 29. Number 1 Subscription

30. Services for SMS Gateway Number 1

31. Services for PRI Lines Number 1 Civil Work (Raised Floor, False Ceiling, Ducting, 32. Lump sum 1 Access Doors, Painting, Partitioning etc.)

33 Networking/IT Racks Number 2

4.11. Responsibility Matrix # Key Successf GM GSCD Netwo Electric Other Othe PM Exisit Activities ul C L rk ity Utiliti r C ng ICT Bidder Vendo Provide es Dep Vendo rs rs art rs at men GSCDL ts Project Inception Phase 1 Project R/A C C I I I I C I Kick Off 2 Deploymen R/A C C I I I I C I t of manpower Requirement Phase 3 Assess the R/A C C C C C C C C requireme nt of IT Infrastruct ure and Non IT Infrastruct ure 4 Assessmen R/A C C I I I C C I t of Business processes

5 Assessmen R/A C C I I I C C I t of requireme nt of Software requireme nts 6 Assess the R/A C C C C I C C C Integration requireme nt 7 Assess the R/A C C C I I C C I connectivit y requireme nt all locations (including Building) 8 Assessmen C C C R/A I I C C I t the Network laying requireme nt 9 Assessmen R/A C C I I I C C I t of training requireme nt Assessmen R/A C C I I I C C I t of ERP infrastruct ure requireme nt Assessmen R/A C C I I I C C I t of GIS infrastruct ure requireme nt Design Phase

10 Formulatio R/A C C C I I C C I n of Solution Architectur e 11 Creation of R/A C C C I I C C I Detail Drawing 12 Detailed R/A C C C I I C C I Design of Smart City Solutions 13 Developme R/A C C C I I C C I nt of test cases (Unit, System Integration and User Acceptance ) 14 Preparatio R/A C C C C I C C I n of final bill of quantity and material 15 SoP R/A C C C C C C C I preparatio n Development Phase 16 Helpdesk R/A C C I I I I C I setup 17 Physical R/A C C I I I I C I Infrastruct ure setup 18 Procureme R/A C C I I I I C I nt of Equipment , edge devices, COTS software (if

any), Licenses

19 IT and Non R/A C C I I I I C I IT Infrastruct ure Installation 20 Developme R/A C C I I I I C I nt, Testing and Production environme nt setup 21 Software R/A C C I I I I C I Application customizati on (if any) 22 Developme R/A C C I I I I C I nt of Bespoke Solution (if any) 23 Data R/A C C I I I I C I Migration 24 Integration R/A C C I I I I C I with Third party services/ap plication (if any) 25 Unit and R/A C C I I I I C I User Acceptance Testing 26 Implement R/A C C I I I I C I ation of Solutions 27 Preparatio R/A C C I I I I C I n of User Manuals , training

curriculum and training materials 28 Role based R/A C C I I I I C I training(s) on the Smart City Solutions Integration Phase 29 SoP R/A C C C C C C C I implement ation 30 Integration R/A C C C C C C C I with GIS 31 Integration R/A C C C C C C C I of solutions with Command and Control Centre Integration R/A C C C C C C C I with ERP and e- governance systems Go –Live 32 Go Live R/A C C I I I I C I Operation and Maintenance 33 Operation R/A C C I I I I C I and Maintenanc e of IT, Non IT infrastruct ure and Application s 34 SLA and R/A C C I I I I C I Performan ce Monitoring

35 Logging, R/A C C I I I I C I tracking and resolution of issues. 36 Application R/A C C I I I I C I enhanceme nt 37 Patch & R/A C C I I I I C I Version Updates 38 Helpdesk R/A C C I I I I C I services

Note: All decisions will be taken by GSCDL which will be abided by all the stakeholders in the above matrix. R/A = Responsible/Accountable C = Consulted I = Informed RACI Matrix for Cloud services The roles of the stakeholders shall change over a period of time as the project will evolve from design to implementation and enter the operations phase. With this background, is given below The RACI matrix for various activities in the design & implementation phase and operational phase of the project is as given below

Sr No Activity Phase MSI/ Application GSCDL/ Cloud Management GMC Service Vendor(s) Provider 1. Infrastructure Analysis Analysis R/A I I 2. Design of Cloud Solution Design & R/A I I /C (DC and DR) Installation 3. Configuration of Cloud Design & R/A I C Solution Portal Installation 4. Installation/End Point Design & R/A I C Protection of VM’s Patch Installation , & Release management at Operation & Infrastructure and Maintenance Operating System Level

5. Installation of Websites Operations I R/A C code/ Application code & Maintenance 6. MPLS Connectivity Design & C I R/A between GSCDL – Installation CloudDC and GSCDL- Cloud DR site Operation & Maintenance 7. Availability of Operations R/A I I Infrastructure & Maintenance 8. Management of Operations C R/A R/A Application/Database, & Patch & Release Maintenance management at Application Level 9. ILL Connectivity for Cloud Design & R/A I I DC and Cloud DR Installation

Operation & Maintenance 10. Infrastructure testing Testing R/A I I

11. Application Testing Testing C R/A C/I

12. Data Integrity Testing Testing R/A R/A I

13. Cloud Solution Functional Testing R/A I R/A Testing 14. Replication Testing Testing R/A R/A I between Cloud DC – Cloud DR 15. Reverse Replication Testing R/A R/A I Testing between Cloud DR – Cloud DC 16. DR Readiness (Failover & Testing R/A A A Failback) 17. DR Drill –Switchover & Operation & R/A R/A A Failback Maintenance 18. DNS Management Operation & R/A I A/C Maintenance 19. Cloud Solution (DC and Operations R/A I I DR) Maintenance & Maintenance 20. Cloud Service Operations R/A I I Provisioning & Maintenance

21. Training to GSCDL Users Operation & R/A I I as per the training Maintenance requirements mentioned in the RFP 22. 24x7x365 Support, Cloud Operations R/A I C service Provisioning, de- & provisioning, etc. Maintenance 23. Maintaining the helpdesk Operations R/A I I for Cloud components & Maintenance 24. Security Audit VA & PT Operations R/A/C R/C C/I /Load Test of Network & & Applications Maintenance 25. Audit of Infrastructure Operations R/A I I & Maintenance 26. Backup Monitoring, Operations R/A I C/I Scheduling, Retention & & Restoration Maintenance

4.12. Project Deliverables # Key Activities Deliverables

1 Project Kick Off 1. Project Plan 2 Deployment of manpower 2. Risk Management and Mitigation Plan 3 Assess the requirement of IT Infrastructure 1. Functional Requirement Specification and Non IT Infrastructure document 2. System Requirement Specification 4 Assessment of Business processes document 5 Assessment of requirement of Software 3. Requirements Traceability Matrix requirements 4. Site Survey Report 6 Assess the Integration requirement

7 Assess the connectivity requirement all locations (including Building)

8 Assessment of network laying requirement

9 Assessment of training requirement

10 Formulation of Solution Architecture 1. Final Bill of Quantity 2. HLD documents 11 Creation of Detail Drawing

12 Detailed Design of Smart City Solutions 3. LLD documents 4. Application architecture documents. 13 Development of test cases (Unit, System 5. Technical Architecture documents. Integration and User Acceptance) 6. Network Architecture documents. 14 Preparation of final bill of quantity and 7. ER diagrams and other data modeling documents. material 8. Logical and physical database design. 15 SoP preparation 9. Data dictionary and data definitions. 10. GUI design (screen design, navigation, etc.). 11. Test Plans 12. SoPs 13. Change management Plan 16 Helpdesk setup 1. IT and Non IT Infrastructure Installation 17 Physical Infrastructure setup Report 18 Procurement of Equipment , edge devices, 2. Completion of UAT and closure of COTS software (if any), Licenses observations report 3. Training Completion report 19 IT and Non IT Infrastructure Installation 4. Application deployment and configuration report 20 Development, Testing and Production environment setup 21 Software Application customization (if any)

22 Development of Bespoke Solution (if any)

23 Data Migration 24 Integration with Third party services/application (if any) 25 Unit and User Acceptance Testing

26 Implementation of Solutions 27 Preparation of User Manuals , training curriculum and training materials

28 Role based training(s) on the Smart City Solutions 29 SoP implementation 1. Integration Testing Report 30 Integration with Smart Components 31 Integration of solutions with Command and Control Centre 32 Go Live 1. Go-Live Report

33 Operation and Maintenance of IT, Non IT 1. Detailed plan for monitoring of SLAs and infrastructure and Applications performance of the overall system 2. Fortnightly Progress Report 34 SLA and Performance Monitoring 3. Monthly SLA Monitoring Report and 35 Logging, tracking and resolution of issues. Exception Report 4. Quarterly security Report 36 Application enhancement 5. Issues logging and resolution report 37 Patch & Version Updates 38 Helpdesk services 4.13. Project Timelines

Services Approximate Tentative Scope/ Approximate Tentative Lead Time Time for Sizing (Months) Issuance of Request Order Request One week post 1. Command and Control Center 9 months post Order for issue of LOI/ (ICCC) IT hardware issuance of request Phase 1 completion of Site 2. Command and Control Center order (for Survey activity (ICCC) non-IT equipment GSCDL) 3. Command and Control Center (ICCC) – software 4. Command and Control Center Viewing for (ICCC) IT hardware 5. Smart DC on cloud – Hardware 6. Smart DC on cloud – Software 7. Smart Disaster Recovery (DR) on cloud 8. Integration of City Surveillance System 9. Implementation and Integration of Smart Traffic Control System (SVD & RLVD) 10. ITMS (City Bus- Sub- System) 11. Implementation and imtegration of SWM 12. Implementation and Integration of Smart Pole and other smart elements 13. Integration of existing City wide network 14. Integration with existing Environmental Sensor (Sub- System and Sensors) 15. Integration with Smart Street Lighting (Sub- System)

Request Post completion of 1. Integration with GIS (Sub- 3 months post Order 2 site survey activity System) issuance of request and Integration of 2. Integration with Smart order Phase II Healthcare (Sub- System) 3. Integration with e- Learning (Sub- System) 4. Integration with ERP, e- Governance, City app portal and Mobile App Request Post completion of 3 months post Order 3 site survey activity 1. Integration with Sewage issuance of request and Integration of SCADA (Sub- System) order Phase III 2. Integration with Water SCADA (Sub- System) 3. Integration with Knowledge Centre 4. Integration with Smart Parking (Sub System and Sensors Only)

5. Annexure I- Functional Requirements & Technical Specifications 5.1. Adaptive Traffic Control System (ATCS)

5.1.1. Functional Requirement - Adaptive Traffic Control System # Building Blocks Bidder Compliance(Yes/No) 1 Traffic Signal Controller 2 Vehicle Detectors 3 Communication Network 4 Software Application

5.1.1.1. Functional Requirement -Traffic Signal Controller # Description Bidder Product Compliance( Documentation Yes/No) Reference 1 Make 2 Model 3 The Traffic Signal Controller equipment is a 32 bit or 64 bit microcontroller with solid state traffic signal lamp switching module with the ability to program any combination of traffic signal stages, phases and junction groups. The controller will ideally have a conflict monitoring facility to ensure that conflicting, dangerous are pre-flagged at the programming stage and these are disallowed even during manual override phase. 4 The Traffic Signal Controller will be adaptive so that it can be controlled through the central traffic control center as an individual junction or as part of group of traffic junctions along a corridor or a region. The signal controller design must be flexible for the junction could be easily configured to be part of any corridor or group definition and could be changed through central command controller easily 5 Site specific configuration data shall be stored in a non-volatile memory device (FLASH memory) easily programmable at the site through keypad or laptop. A minimum of 512KB flash memory and 128KB RAM shall be provided. Volatile memory shall not be used for storing the junction specific plans or signal timings.

Volume II – Scope of Work and Functional & Technical Specification 80

6 All timings generated within a traffic signal controller shall be digitally derived from a crystal clock which shall be accurate to plus or minus 100 milliseconds. 7 The controller shall provide a real time clock (RTC) with battery backup that set and update the time, date and day of the week from the GPS. The RTC shall have minimum of 10 years battery backup with maximum time tolerance of +/- 2 sec per day. 8 The controller shall have the facility to update the RTC time from ATCS server, GPS and through manual entry. 9 The traffic signal system including controller shall have provision for audio output tones and should be disabled friendly. 10 The controller shall be capable of communicating with the ATCS server through Ethernet on a managed leased line network or any other appropriate stable communication network.

A) Police Panel

The controller shall provide the following facilities in a separate panel with provision for lock and key arrangements for use by the Traffic Police. # Description Bidder Product Compliance( Documentation Yes/No) Reference 1 Four Hurry Call switches: The Hurry Call mode will provide the means to force the controller to a defined stage, without violating safety clearances. A preemption input may be used to demand the Hurry Call mode to give right of way to emergency vehicles. It should be possible to configure the Hurry Call switches to any stage as per site requirements. 2 One Forced Flash Switch: Activation of this switch should force the signal to Flashing Amber / Flashing Red. 3 One Auto / Manual Switch: Activation of this switch should enable manual operation of the controller. Deactivation of the manual switch shall continue from the current stage without interruption. 4 One Manual Advance Pushbutton Switch: In manual operation mode, the stages appear in the sequence specified in the signal plan timetable. Activating the pushbutton switch shall terminate

Volume II – Scope of Work and Functional & Technical Specification 81

the currently running stage and start the next, without violating safety clearances. 5 One Junction OFF Switch: Activating this switch should put OFF all signal lamps. On deactivation of the switch the traffic signal controller shall resume its normal operation without violating any safety clearances.

B) Modes of Operation

The traffic signal controller shall have the following modes of operation: # Description Bidder Product Compliance( Documentation Yes/No) Reference 1 Fixed Time: In fixed time (pre-timed) mode the traffic signal controller shall execute stage timings according to the site specific timetable maintained in the traffic signal controller FLASH memory. Inputs from vehicle detectors shall be ignored in this mode and no preemption shall be made on any stage. Cycle time remains constant in every cycle execution for a given time period. 2 Vehicle Actuation with All Stages Preemption: In the vehicle actuation with all stages preemption mode, the traffic signal controller shall execute stage timings as per demand from vehicle detectors within the constraints of Minimum Green, Maximum Green running period for the stage and Cycle time stored in the traffic signal controller FLASH memory. Preemption shall be possible for all demand actuated stages. Cycle time may vary in every cycle execution. 3 Semi-Actuation: In the semi-actuation mode, the traffic signal controller shall execute stage timings in the vehicle actuated stages as per demand from vehicle detectors within the constraints of Minimum Green, Maximum Green running period for the stage and Cycle time stored in the traffic signal controller FLASH memory. All other stages shall execute the Maximum green time configured for the stage. Preemption shall be possible for all demand actuated stages. Cycle time may vary in every cycle execution. 4 Stage Skipping: The traffic signal controller shall not execute the stage enabled for skipping when there is no vehicle demand registered for the

Volume II – Scope of Work and Functional & Technical Specification 82

stage till clearance amber time of the previous stage. 5 Transit Signal Priority (TSP) for BRT buses: The traffic signal controller shall provide transit signal priority for buses in dedicated lane to ensure minimum stop delay at the intersection, without violating safety clearances. 6 Vehicle Actuation with Fixed Cycle length: In vehicle actuation with fixed cycle length mode, the traffic signal controller shall execute stage timings as per demand from vehicle detectors within the constraints of Minimum Green, Maximum Green running period for the stage and Cycle time shall be maintained constant during a given timeslot. Preemption for all demand actuated stages except for Priority Stage shall be possible. 7 Full ATCS (FATCS): In FATCS mode, the traffic signal controller shall execute stage timings as per demand within the constraints of Minimum Green, Maximum Green running period for the stage and Cycle time specified by the Central Computer during every cycle switching. Preemption for all demand actuated stages except Priority Stage shall be possible in this mode. The traffic signal controller shall identify a communication failure with the central computer within a specified time period. In such an event the signal plan timings shall be executed from the local timetable stored in the traffic signal controller FLASH memory. Fallback mode of the traffic signal controller shall be vehicle actuated. On restoration of the communication with central computer the traffic signal controller shall automatically resort to FATCS mode. The traffic signal controller shall accept commands for remote selection / de-selection of the following from the Central Computer at Interim ICCC/ICCC. Hurry Call Flashing Amber / Flashing Red Junction Off If not reverted to the normal operation within the time period listed below, the traffic signal controllers shall timeout the commands and operate normally Hurry Call – 5 Minutes

Volume II – Scope of Work and Functional & Technical Specification 83

Flashing Amber / Flashing Red – 30 Minutes Junction Off – 30 Minutes The traffic signal controller shall report the following to the Central Computer through the communication network every cycle or on an event as appropriate. Green time actually exercised for each approach (stage preemption timing) against the Green running period set for the approach by the Central Computer Mode of Operation Lamp failure, if any Output short circuit, if any Detector failure, if any

C) Traffic Signal Controller Operating Parameters Phases - The controller shall have facility to configure 32 Phases either for vehicular movement, filter green, indicative green, pedestrian movement or a combination thereof. # Description Bidder Product Compliance( Documentation Yes/No) Reference 1 It shall be possible to operate the filter green (turning right signal) along with a vehicular phase. The filter green signal shall flash for a time period equal to the clearance amber period at timeout when operated with a vehicular phase. 2 The pedestrian phase signal shall be configured for flashing red or flashing green aspect during pedestrian clearance. 3 It shall be possible to configure any phase to the given lamp numbers at the site. 4 Stages – The controller shall have facility to configure 32 Stages 5 Cycle Plans – The controller shall have facility to configure 24 Cycle Plans and the Amber Flashing / Red Flashing plan. It shall be possible to define different stage switching sequences in different cycle plans. The controller shall have the capability for a minimum of 32 cycle-switching per day in fixed mode of operation. 6 Day Plans – The controller shall have facility to configure each day of the week with different day

Volume II – Scope of Work and Functional & Technical Specification 84

plans. It shall also be possible to set any of the day plans to any day of the week. The controller shall have the capability to configure 20 day plans. 7 Special Day Plans – The controller shall have facility to configure a minimum of 20 days as

special days in a calendar year.

8 Starting Amber – During power up the controller shall initially execute the Flashing Amber / Flashing Red plan for a time period of 3 Seconds to 10 Seconds. The default value of this Starting Amber is 5 Seconds. Facility shall be available to configure the time period of Starting Amber within the given limits at the site. 9 Inter-green – Normally the inter-green period formed by the clearance Amber and Red extension period will be common for all stages. However, the controller shall have a facility to program individual inter-green period from 3 Seconds to 10 Seconds. 10 Minimum Green – The controller shall allow programming the Minimum Green period from 5 Seconds to 10 Seconds without violating the safety clearances. It should not be possible to preempt the Minimum Green once the stage start commencing execution. 11 All Red – Immediately after the Starting Amber all the approaches should be given red signal for a few seconds before allowing any right of way, as a safety measure. The controller shall have programmability of 3 Seconds to 10 Seconds for All Red signal. 12 Signal lamps monitoring – The controller shall have inbuilt circuitry to monitor the lamp status 13 Green – Green Conflict Monitoring – The controller shall have a facility to list all conflicting phases at

an intersection. The controller should not allow programming of these conflicting phases in a Stage. A hardware failure leading to a conflict

condition (due to faulty devices or short circuit in the output) shall force the signal into Flashing Amber / Flashing Red. 14 Cable less Synchronization – It shall be possible to synchronize the traffic signal controllers installed in a corridor in the following modes of operation, without physically linking them and without

Volume II – Scope of Work and Functional & Technical Specification 85

communication network. GPS enabled RTC shall be the reference for the cable less synchronization. 15 Fixed Time mode with fixed offsets 16 Vehicle Actuated mode with fixed offsets

Volume II – Scope of Work and Functional & Technical Specification 86

D) Input and Output facilities # Description Bidder Product Compliance( Documentation Yes/No) Reference 1 Lamp Switching: The controller shall have maximum 64 individual output for signal lamp switching, configurable from 16 to 32 lamps. The signal lamps shall be operating on appropriate DC/AC voltage of applicable rating

2 Detector Interface: A minimum of 16 vehicle detector inputs shall be available in the controller. All detector inputs shall be optically isolated and provided with LED indication for detection of vehicle. 3 Communication Interface: The traffic signal controller shall support Ethernet interface to communicate with the ATCS server 4 Power Saving: The traffic signal controller shall have a facility to regulate the intensity of signal lamps during different ambient light conditions thereby saving energy. 5 Real-time Clock (RTC): The GPS receiver for updating time, date and day of the week information of the traffic signal controller should be an integral part of the traffic signal controller. 6 The traffic signal controller shall update the date, time and day of the week automatically from GPS during power ON and at scheduled intervals. 7 Manual entry for date, time and day of week shall be provisioned for setting the traffic signal controller RTC (Real Time Clock). 8 It shall be possible to set the RTC from the Central Server when networked 9 Keypad (optional): The traffic signal controller shall have a custom made keypad or should have provision for plan upload and download using PC/laptop/Central Server 10 Operator Display (optional): The traffic signal controller shall optionally have a LED backlit Liquid Crystal Display (LCD) as the operator interface.

Volume II – Scope of Work and Functional & Technical Specification 87

5.1.1.2. Functional Requirement -Camera based Vehicle Detector

The detector equipment is a separate logic unit, which may be integrated into the controller, or alternatively mounted in its own housing. The outputs of the detectors indicate the presence of vehicles and are used to influence the operation of the traffic signal controller and shall generate counts, demands and extensions for right-of-way. Means shall be provided so that a detector may be connected to demand and / or extend a phase movement as specified. # Description Bidder Product Compliance( Documentation Yes/No) Reference 1 Make 2 Model 3 The contractor shall clearly specify the placement of the detector (upstream, downstream, stop-line, exit etc.) for independent straight and right turn signals. 4 The detector shall be able to count vehicles in non-lane based mixed traffic flow conditions. The accuracy of counts shall be bigger than 90% over all light and weather conditions. The contractor shall clearly specify how this is accomplished. 5 The contractor shall give an estimate of the total number of vehicle presence detection zones and vehicle detectors required and the type of detection system recommended. 6 A detector that does not change its status at least once during a stage execution shall be notified to the Central Computer (in ATCS mode) at the termination of the associated stage.

5.1.1.3. Functional Requirement -Countdown Timer Countdown Timer shall be installed at each traffic junction under ATCS System Project.

# Description Bidder Product Compliance( Documentation Yes/No) Reference 1 Make 2 Model 3 Count Down Timer to be configured in Vehicular Mode. 4 The Vehicular countdown timer should be dual color,  Red for Stop or STP  Green color for Go

Volume II – Scope of Work and Functional & Technical Specification 88

5 There should be alternate Red and Balance phase time for STOP or STP in Flashing 6 Alternate Green and Balance Phase Time for Go in Flashing

5.1.1.4. Functional Requirement -Communication Network Function of the Communication network is for remote monitoring of the intersection and its management. Real time data (like RTC time, stage timing, mode, events, etc.) from the traffic signal controller is required to be sent to the Central Computer in Interim ICCC/ICCC. Central Computer running the ATCS application shall calculate and send optimum signal timings to all intersections in the corridor. The contractor shall clearly specify the bandwidth requirements and the type of network recommended for the ATCS. The contractor shall specify the networking hardware requirements at the Interim ICCC/ICCC and remote intersections for establishing the communication network.

5.1.1.5. Functional Requirement -ATCS Software Application Objective of the ATCS is to minimize the stops and delays in a road network to decrease the travel time with the help of state-of-the-art technology. The adaptive traffic control system shall operate in real time with the capacity to calculate the optimal cycle times, effective green time ratios, and change intervals for all system traffic signal controllers connected to it. These calculations will be based up on assessments carried out by the ATCS application software running on a Central Computer based on the data and information gathered by vehicle detectors at strategic locations at the intersections controlled by the system.

The ATCS application software shall do the following: # Description Bidder Product Compliance Documentation Reference (Yes/No) 1. Make 2. Model 3. Identify the critical junction of a corridor or a region based on maximum traffic demand and saturation. 4. The critical junction cycle time shall be used as the group cycle time i.e. cycle time common to all intersection in that corridor or region. 5. Stage optimization to the best level of service shall be carried out based on the traffic demand. 6. Cycle optimization shall be carried out by increasing or decreasing the common corridor cycle time based on the traffic demand within the constraints of Minimum and Maximum designed value of cycle time.

Volume II – Scope of Work and Functional & Technical Specification 89

7. Offset correction shall be carried out to minimize number of stops and delays along the corridor for the priority route. Offset deviation measured using distance and speed between successive intersections shall be corrected within 5 cycles at a tolerance of +/- 5 seconds maximum. 8. The system shall have provision to configure priority for upstream signals as default. The ATCS software shall continuously check the traffic demand for upstream and downstream traffic and automatically assign the priority route to the higher demand direction. 9. Develop appropriate stage timing plans for each approach of every intersection under the ATCS, based on real time demand 10. Propose timing plans to every intersection under the ATCS in every Cycle 11. Verify the effectiveness of the proposed timing plans in every cycle 12. Identify Priority routes 13. Synchronize traffic in the Priority routes 14. Manage and maintain communication with traffic signal controllers under ATCS 15. Maintain database for time plan execution and system performance 16. Maintain error logs and system logs 17. Generate Reports on request 18. Graphically present signal plan execution and traffic flow at the intersection on desktop 19. Graphically present time-space diagram for selected corridors on desktop 20. Graphically present network status on desktop 21. Make available the network status and report viewing on Web 22. The ATCS shall generate standard and custom reports for planning and analysis 23. It shall be possible to interface the ATCS with a popular microscopic traffic flow simulation software for pre and post implementation analysis and study of the proposed ATCS control strategy

Volume II – Scope of Work and Functional & Technical Specification 90

24. Shall have the ability to predict, forecast and smartly manage the traffic pattern across the signals over the next few minutes, hours or 3- 5 days and just in the current real time. 25. Shall provide a decision support tool for assessing strategies to minimize congestion, delays and emergency response time to events via simulation and planning tools liked with real time traffic data fusion and control of traffic signaling infrastructure on ground. 26. Shall collect continuously information about current observed traffic conditions from a variety of data sources and of different kind (traffic states, signal states, vehicle trajectories, incidents, road works, …) 27. Shall infer a coherent and comprehensive observed traffic state (speeds, vehicular densities, and presence of queues) on all network elements, from abovementioned observations, including vehicle trajectories, through a number of map matching, data validation, harmonization and fusion processes 28. Shall extend the measurements made on only a number of elements both on the rest of the unmonitored network, and over time, thus obtaining an estimation of the traffic state of the complete network and the evolution of this traffic state in the future 29. Shall forecast the traffic state with respect to current incidents and traffic management strategies (e.g. traffic signal control or variable message signs), improving the decision making capabilities of the operators even before problems occur 30. Shall calculate customisable Key Performance Indicators (KPI) to quickly assess the results 31. Shall provide calculated traffic flows estimation and forecast, queues and delays to Urban Control and Adaptive Signal Control Systems, allowing for proactive Traffic Management and Control 32. Shall generate alerts to the operator that trigger on customizable conditions in the network (starting with simple drops in flow, up to total queue lengths along emission

Volume II – Scope of Work and Functional & Technical Specification 91

sensitive roads surpassing a definable threshold) 33. Shall distribute both collected and calculated traffic information via a variety of communication protocols and channels, ensuring high interoperability degree and thus acting as a “traffic data and information hub” 34. Shall create a traffic data warehouse for all historic traffic information gathered from the hardware installed on the road network. 35. Shall operate in real time that is continuously updating the estimates on the state of the network and the travel times on the basis of data collected continuously over time. 36. Shall operate the traffic lights with the adaptive traffic controls, based on the current and forecasted traffic demand and the current incidents, thus optimizing the green waves continuously throughout the network 37. Enable a smart public transport priority respecting the delays for all road users at once with the adaptive signal controller

A) Reports System shall generate Corridor based and Intersection based reports. The application software shall generate the following reports, but not limited to the below. All the reports shall be possible for selected dates.

# Description Bidder Product Compliance Documentation Reference (Yes/No) 1. Intersection based reports 2. Stage Timing report – The report shall give details of time at which every stage change has taken place. The report shall show the stage sequence, stage timings and stage saturation of all stages of all cycles for a day. The saturation is defined as the ratio between the available stage timings to the actual stage timing executed by the traffic signal controller for the stage (stage preemption time). 3. Cycle Timing report – The report shall give details of time at which every cycle has taken place. The report shall show the cycle

Volume II – Scope of Work and Functional & Technical Specification 92

sequence and cycle timings for all the cycles in a day. 4. Stage switching report – The report shall give details of time at which a stage switching has taken place. The report shall show the stage sequence, stage timings and stage saturation for a day. 5. Cycle Time switching report – The report shall give details of time at which a cycle switching has taken place. The report shall show the cycle sequence and cycle timings for the cycle in a day. 6. Mode switching report – The report shall give details of the mode switching taken place on a day. 7. Event Report - The report shall show events generated by the controller with date and time of event. 8. Power on & down: The report shall show time when the master is switched on, and last working time of the master controller. 9. Intensity Change – The report shall show the brightness of the signal lamp is changed according to the light intensity either manually through keypad or automatically by LDR with time stamp. 10. Plan Change – The report shall show the time of change of plan either through keypad or remotely through a PC or Server. 11. RTC Failure – The report shall show the time when RTC battery level goes below the threshold value. 12. Time Update – The report shall show the time when the Master controller updated its time either manually through keypad, automatically by GPS or through remote server. 13. Mode Change – The report shall show the time when Master controller’s operating mode is changed either manually through keypad or a remote server. The typical modes are FIXED, FULL VA SPLIT, FULL VA CYCLE, FLASH, LAMP OFF and HURRY CALL. 14. Lamp Status Report – The report shall show lamp failure report with date and time of

Volume II – Scope of Work and Functional & Technical Specification 93

failure, colour of the lamp and associated phase 15. Loop Failure Report – The report shall show the date and time of detector failure with detector number and associated phase. 16. Conflict – The report shall show the conflict between lamps (RED, AMBER, GREEN) in the same phase or conflict between lamps with other phase. 17. Corridor Performance Report – The report shall show the saturation of all the intersections in a corridor for every cycle executed for the corridor and the average corridor saturation for a day 18. Corridor Cycle Time Report – The report shall show the Corridor cycle time, Intersection cycle time, Mode of operation and degree of saturation of all the intersections in a corridor for every cycle for a day

B) Graphical User Interface The application software shall have the following Graphical User Interface (GUI) for user friendliness.

# Description Bidder Product Compliance Documentation Reference (Yes/No) 1. User login – Operator authentication shall be verified at this screen with login name and password 2. Network Status Display – This online display shall indicate with appropriate colour coding on site map whether an intersection under the ATCS is online or off. On double clicking the intersection a link shall be activated for the traffic flow display for the intersection. 3. Traffic Flow Display – This online display shall indicate the current traffic flow with animated arrows, mode of operation, stage number being executed and elapsed stage time. 4. Saturation Snapshot – This display shall show the current saturation levels of all intersections in a corridor.

Volume II – Scope of Work and Functional & Technical Specification 94

5. Reports Printing / Viewing – This link shall allow selection, viewing and printing of different reports available under ATCS 6. Time-Space Diagram – The time-space diagram shall display the current stages being executed at every intersection in a corridor with immediate previous history. 7. Junctions shall be plotted proportional to their distance on Y-axis and time elapsed for the stage in seconds on X-axis. 8. Junction names shall be identified with each plot. 9. Facility shall be available to plot the time- space diagram from history. 10. Currently running stage and completed stages shall be identified with different colours. 11. Stages identified for synchronization shall be shown in a different colour. 12. Speed lines shall be plotter for stages identified for synchronization to the nearest intersection in both directions. 13. It should be possible to freeze and resume online plotting of Time-Space diagram. 14. The system shall have other graphical interfaces for configuring the ATCS, as appropriate.

5.1.2. Technical Specifications - Adaptive Traffic Control System

5.1.2.1. Adaptive Traffic Control- Traffic Sensor

Appropriate camera based traffic sensors may be chosen to provide the operational levels and accuracy as required for successful function of the ATCS system as per the SLAs defined.

5.1.2.2. Adaptive Traffic Control- Traffic Controller

Appropriate controller technology may be chosen to provide the operational levels and accuracy as required for successful function of the ATCS system as per the SLAs defined. The proposed traffic controller shall be disabled friendly and shall also provide audio tones output.

5.1.2.3. Adaptive Traffic Control- Traffic Light Aspects Description Bidder Product Compliance(Yes/No) Documentation Reference

Volume II – Scope of Work and Functional & Technical Specification 95

1. Make 2. Model 3. Key Features: a. lowest power consumption for all colors, maximum 8 watts for each color b. Meets or exceeds intensity, colour and uniformity specifications c. Temperature compensated power supplies for longer LED life d. Uniform appearance light diffusing e. Should be Intertek/ETL/EN compliant f. All units operate at voltage of - 12 / 24 volts DC g. LED shall be single source narrow beam type with clear lens & Luminance uniformity of 1:15 h. Pedestrian traffic lights should be provided with clearly audible signals for the benefit of pedestrians with visual impairments i. Phantom Class 5 or equivalent. IP Rating: IP65 4. LED aspects: a. Red, Amber, Green-Full (300 mm diameter) : Hi Flux b. Green-arrow (300 mm diameter): Hi flux c. Animated Pedestrian-Red and Green Animated c/w countdown (300 mm) Hi Brite with diffusions 5. LED Retrofit Specifications: a. Power supply:230 Vac +/- 10% and frequency 50+/-5Hz b. Standards: EN 12368 compliant c. Convex Tinted Lens: Available d. Fuse and Transients: Available e. Operating Temperature Range: 0 degree Celsius to 55 degree CelciusTurn Off/Turn On Time: 75 milli seconds max f. Total Harmonic Distortion: <20% g. Electromagnetic interference: Meets FCC Title 47,Subpart B, Section 15 Regulation or equivalent EN/IRC standard h. Blowing Rain/Dust Spec: MIL 810F or Equivalent EN/IRC standard complaint i. Minimum Luminous Intensity (measured at intensity point)(cd): Red 400 j. Amber 400

Volume II – Scope of Work and Functional & Technical Specification 96

k. Green 400 l. Dominant Wavelength (nm): Red 630 Amber 590 m. Green 490 n. Lamp conflict compatibility system: Compatible with lamp failure and conflict detection

5.1.2.4. Countdown Timer # Parameters Minimum Bidder Compliance Product Specifications or better (Yes/No) Documentation Reference 1. Make 2. Model 3. CPU Micro Controller 4. Mechanical Specifications A Structural Polycarbonate Material strengthened against UV rays B Body Color Light Grey/Black C Dimensions 360mm x 370mm x 220mm 5. Display Specification

A Lamp Diameter 300mm B Digit Height 150 -165mm C Display Type Dual Coloured (Red & Green) D No. of Digit 3

6. LED Specifications

A LED Diameter 5mm LED B Viewing Angle 30°

C LED Wave 630-640nm (Red), 505nm Length - 520nm (Blue-Green) D LED Dice AIInGap (Red), InGaN Material (Blue-Green) E LED Warranty 5 years period 7. Technical Features

Volume II – Scope of Work and Functional & Technical Specification 97

A Power 20 - 30 Watt Per Lamp Consumption B Input Power 85-260V AC, 50Hz C Operating -20 to + 60 °C Temperature D Humidity 0% to 95% Relative Humidity E Water & Dust IP 65 Ingress F Standard En12966 Compliant

5.1.2.5. Poles for Traffic Signals Sr. No Component Bidder Product Compliance Documentation (Yes/No) Reference 1. Make 2. Model 3. Material GI Class ‘B’ pipe 4. Paint Pole painted with two coats of zinc chromate primer and two coats of golden yellow Asian apostolate paint or otherwise as required by architect and in addition bituminous painting for the bottom 1.5 m portion of pole.

5.1.2.6. Cables for Traffic Signals Sr. No Component Bidder Product Compliance Documentation (Yes/No) Reference 1. Make 2. Model 3. No’s of core 7 and 14 core 1.5 sq. mm. 3 Core 2.5 sq. mm. 4. Materials PVC insulated and PVC sheathed armored cable

with copper conductor of suitable size as specified in BOQ.

Volume II – Scope of Work and Functional & Technical Specification 98

5. Certification ISI Marked 6. Standards Indian Electricity Act and Rules A. IS:1554 PVC insulated electric cables (heavy duty) 5.2. Traffic Enforcement System

5.2.1. Functional Requirements of the Red Light Violation Detection System # Description Bidder Product Compliance Documentation (Yes/No) Reference 1 Make

2 Model

3 General

a. The following Traffic violations to be automatically detected by the system by using appropriate Non- Intrusive sensors technology: The system should have both provisions to detect red light status by taking the signal feed from the traffic signal controller as well as by video analytics method using another camera (Evidence Camera) focused at the red light. The Evidence camera should also be used for evidence snap generation.

a) Red Light Violation b) Stop Line Violation b. The system should be capable of capturing multiple infracting vehicles simultaneously in Different lanes on each arm at any point of time with relevant infraction data like:

a) Type of Violation b) Date, time, Site Name and Location of the Infraction c) Registration Number of the vehicle through ANPR Camera system for each vehicle identified for infraction.

Volume II – Scope of Work and Functional & Technical Specification 99

c. The system should be equipped with a camera system to record a digitized image and video of the violation, covering the violating vehicle with its surrounding and current state of signal (Red/Green/Amber) by which the system should clearly show nature of violation and proof thereof :- a) When it violates the stop line. b) When it violates the red signal. c) Besides, a closer view indicating readable registration number plate patch of the violating vehicle for court evidence for each violation.

The system must have in-built tool to facilitate the user to compose detail evidence by stitching video clips from any IP camera in the junction (including but not limited to the red light violation detection camera, evidence camera), and any other surveillance cameras in the vicinity of the spot of incidence. The entire evidence should be watermarked and encrypted to stand the court of law. d. The system shall be able to detect all vehicles infracting simultaneously in each lane/ arm at the junction as per locations provided. It should also be able to detect the vehicles infracting serially one after another in the same lane. The vehicles should be clearly identifiable and demarcated in the image produced by the camera system. e. The Evidence image produced by the system should be wide enough to give the exact position of the infracting vehicles with respect to the stop line and clearly indicate colour of the Traffic light at the instant of Infraction even if any other means is being used to report the colour of the light. f. The system should interface with the traffic controller to validate the colour of the traffic signal reported at the time of Infraction so as to give correct inputs of the signal cycle. g. The Evidence and ANPR camera should continuously record all footage in its field of view to be stored at the local base station. This should be extractable onto a portable device as and when required.The option of live viewing of evidence cameras from the locations shall be available at the TMC. The network should have the capability to provide the real time feed of the evidence camera to the TMC at the best resolution possible on the available network.

Volume II – Scope of Work and Functional & Technical Specification 100

h. The system shall be equipped with IR Illuminator to ensure clear images including illumination of the Number Plate and capture the violation image under low light conditions and night time. 4 Recording & display information archive medium a. The recording and display of information should be detailed on the snapshot of the infracting vehicle as follows: b. Computer generated unique ID of each violation c. Date (DD/MM/YYYY) d. Time (HH:MM:SS) e. Equipment ID f. Location ID g. Carriageway or direction of violating vehicle h. Type of Violation (Signal/Stop Line) i. Lane Number of violating vehicle j. Time into Red/Green/Amber k. Registration Number of violating vehicle 5 On site-out station processing unit communication & Electrical Interface a. The system should automatically reset in the event of a program hang up and restart on a button press. However the system should start automatically after power failure. b. The system should have secure access mechanism for validation of authorised personnel. c. Deletion or addition and transfer of data should only be permitted to authorised users. d. A log of all user activities should be maintained in the system. e. Roles and Rights of users should be defined in the system as per the requirements of the client f. All formats of the stored data with respect to the infractions should be Non Proprietary. g. The communication between the on-site outstation processing unit housed in the junction box and the detection systems mounted on the cantilever shall be through appropriate secured technology. h. The system should have the capability to transfer the data to Interim ICCC/ICCC through proper encryption in real time and batch mode for verification of the infraction and processing of challan. Call forwarding architecture shall be followed to avoid any data loss during transfer. i. In the event that the connectivity to the Interim ICCC/ICCC is not established due to

Volume II – Scope of Work and Functional & Technical Specification 101

network/connectivity failures, then all data pertaining to the infraction shall be stored on site and will be transferred once the connectivity is re- established automatically. There shall also be a facility of physical transfer of data on portable device whenever required. There should be a provision to store minimum one week of data at each site on a 24x7 basis. 6 Mounting structure

a. Should be cantilever mounted and shall have minimum 6 Mtrs. height with appropriate vertical clearance under the system from the Road surface to ensure no obstruction to vehicular traffic. b. It should be capable to withstand high wind speeds and for structural safety, the successful bidder has to provide structural safety certificate from qualified structural engineers approved/ certified by Govt. Agency. c. It shall be painted with one coat of primer and two coats of PU paint. The equipment including poles, mountings should have an aesthetic feel keeping in mind the standards road Infrastructure (e.g Poles, Navigation boards etc) currently installed at these locations. The equipment should look “one” with the surroundings of the location and not look out of place. d. Rugged locking mechanism should be provided for the onsite enclosures and cabinets. 7 RLVD Application

a. It should be capable of importing violation data for storage in database server which should also be available to the Operator for viewing and retrieving the violation images and data for further processing. The programme should allow for viewing, sorting, transfer & printing of violation data. b. It should generate the photograph of violations captured by the outstation system which include a wider view covering the violating vehicle with its surrounding and a closer view indicating readable registration number plate patch of the violating vehicle or its web link on notices for court evidence. c. All outstation units should be configurable using the software at the Central Location. d. Violation retrieval could be sorted by date, time, location and vehicle registration number and the data structure should be compatible with

Volume II – Scope of Work and Functional & Technical Specification 102

Gandhinagar Police database structure. It should also be possible to carry out recursive search and wild card search. e. The operator at the back office should be able to get an alarm of all fault(s) occurring at the camera site (e.g. sensor failure, camera failure, failure of linkage with traffic signal, connectivity failure, Camera tampering, sensor tampering). f. The automatic number plate recognition Software will be part of the supplied system, Success rate of ANPR will be taken as 80% or better during the day time and 60% or better during the night time with a standard number plate. g. The application software should be integrated with the E Challan software for tracing the ownership details of the violating vehicle and issuing/printing notices. Any updates of the software (OS, Application Software including any proprietary software), shall be updated free of cost during the contract period by the MSI. h. Image zoom function for number plate and images should be provided. In case the number plate of the infracting vehicle is readable only through the magnifier then in such cases the printing should be possible along with the magnified image. i. Various users should be able to access the system using single sign on and should be role based. Different roles which could be defined (to be finalized at the stage of SRS) could be Administrator, Supervisor, Officer, Operator, etc. j. Apart from role based access, the system should also be able to define access based on location. k. Rights to different modules / Sub-Modules / Functionalities should be role based and proper log report should be maintained by the system for such access. l. Components of the architecture must provide redundancy and ensure that there are no single points of failure in the key project components. Considering the high sensitivity of the system, design shall be in such a way as to be resilient to technological sabotage. To take care of remote failure, the systems need to be configured to mask and recover with minimum outage.

Volume II – Scope of Work and Functional & Technical Specification 103

m. The architecture must adopt an end-to-end security model that protects data and the infrastructure from malicious attacks, theft etc. Provisions for security of field equipment as well as protection of the software system from hackers and other threats shall be a part of the proposed system. Using Firewalls and Intrusion detection systems such attacks and theft shall be controlled and well supported (and implemented) with the security policy. The virus and worms attacks shall be well defended with Gateway level Anti-virus system, along with workstation level Anti-virus mechanism. There shall also be an endeavour to make use of the SSL/VPN technologies to have secured communication between Applications and its end users. Furthermore, all the system logs shall be properly stored & archived for future analysis and forensics whenever desired. n. The evidence of Infraction should be encrypted and protected so that any tampering can be detected. o. Ease of configuration, ongoing health monitoring, and failure detection are vital to the goals of scalability, availability, and security and must be able to match the growth of the environment. p. System shall use open standards and protocols to the extent possible and declare the proprietary software wherever used. q. The user interface should be user friendly and provide facility to user for viewing, sorting and printing violations. The software should also be capable of generating query based statistical reports on the violation data. r. The data provided for authentication of violations should be in an easy to use format as per the requirements of user. s. User should be provided with means of listing the invalid violations along with the reason(s) of invalidation without deleting the record(s). t. Basic image manipulation tools (zoom etc.) should be provided for the displayed image but the actual recorded image should never change. u. Log of user actions be maintained in read only mode. User should be provided with the password and ID to access the system along with user type (admin, user).

Volume II – Scope of Work and Functional & Technical Specification 104

v. Image should have a header/footer depicting the information about the site IP and violation details like date, time, equipment ID, location ID, Unique ID of each violation, lane number, Regn. Number of violating vehicle and actual violation of violating vehicle etc. so that the complete lane wise junction behaviour is recorded including (Red Light violation and Stop Line Violation) w. Number plate should be readable automatically by the software/interface. There should be user interface for simultaneous manual authentication / correction and saving as well. x. Interface for taking prints of the violations (including image and above details).

5.2.2. Functional Requirements of the Speed Violation Detection System # Description Bidder Compliance Product (Yes/No) Documentation Reference 1 Make

2 Model

3 General

a. The Speed Violations should be automatically detected by the system by using appropriate sensors technology. b. The system should be capable of capturing multiple infracting vehicles simultaneously in defined lanes at any point of time simultaneously with relevant infraction data like: a) Type of Violation b) Speed of violating vehicle c) Notified speed limit d) Date, time, Site Name and Location of the Infraction e) Registration Number of the vehicle through ANPR Camera system for each vehicle identified for infraction c. The system should be equipped with a camera system to record a digitized image or video frames of the violation, covering the violating vehicle with its surrounding d. The system shall provide the No. of vehicles infracting simultaneously in each lane. The

Volume II – Scope of Work and Functional & Technical Specification 105

vehicles will be clearly identifiable and demarcated in the image produced by the camera system e. The system shall be equipped with IR Illuminator to ensure clear images including illumination of the Number Plate and capture the violation image under low light conditions and night time.

4 Speed a. Speed measurement may be made by using non-intrusive technology such as Radar/sensor/camera/virtual based or any other appropriate certified technology. CE and homologation certificate from Ministry of Traffic or equivalent department from respective country of origin, document authenticated by Indian Embassy (to authenticate that systems are legalized and tested for infractions to avoid legal issues) or Certificate from internationally accredited metrology laboratories (approved for speed calibration) is acceptable 5 On site-out station processing unit communication & Electrical Interface a. The system should automatically reset in the event of a program hang up and restart after power failure. b. The system should have secure access mechanism for validation of authorised personnel c. Deletion or addition and transfer of data should only be permitted to authorised users. d. A log of all user activities should be maintained in the system e. Roles and Rights of users should be defined in the system f. The data shall be transferred to the Interim ICCC/ICCC in real time for verification of the infraction and processing of challan. g. In the event that the connectivity to the Interim ICCC/ICCC is not established then all data pertaining to the infraction shall be stored on site and will be transferred once the connectivity is re-established automatically.

Volume II – Scope of Work and Functional & Technical Specification 106

6 Mounting structure

a. It should be capable of importing violation data for the Operator for viewing and retrieving the violation images and data for further processing. The programme should provide for sort, transfer & print command. b. It should generate the photograph of violations captured by the outstation system which include a wider view covering the violating vehicle with its surrounding and a closer view indicating readable registration number plate patch of the violating vehicle or its web link on notices for court evidence. c. All outstation units should be configurable using the software at the Central Location d. Violation retrieval could be sorted by date, time, location and vehicle registration number and data structure should be compatible with Gandhinagar Traffic Police database and Gandhinagar Transport department database structure. e. The operator at the back office should be able to get an alarm of any possible fault(s) at the camera site (outstand) (e.g. sensor failure, camera failure, failure of linkage with traffic signal, connectivity failure, Camera tampering , sensor tampering) f. The automatic number plate recognition Software may be part of the supplied system, or can be provided separately as

Volume II – Scope of Work and Functional & Technical Specification 107

add on module to be integrated with violation detection. a.) Success rate of ANPR will be taken as 80% or better during the day time and 60% or better during the night time on standard number plates. g. Image zoom function for number plate and images should be provided. Any updates of the software available, shall be updated free of cost during the contract period by the vendor and will integrate the same with existing application and database of Gandhinagar Traffic Police and Gandhinagar Transport department. h. The application software should be integrated with the notice branch software for tracing the ownership details of the violating vehicle and issuing/printing notices. i. Various users should be access the system using single sign on and should be role based. Different roles which could be defined (to be finalized at the stage if SRS) could be Administrator, Supervisor, Officer, Operator, etc. j. Apart from role based access, the system should also be able to define access based on location. k. Rights to different modules / Sub-Modules / Functionalities should be role based and proper log report should be maintained by the system for such access l. Important technical components of the architecture must support scalability to provide continuous growth to meet the growing demand of Gandhinagar Police. The system shall support vertical scalability so that depending on changing requirements from time to time, the system may be scaled upwards. There must not be any system imposed restrictions on the upward scalability. Main technological components requiring scalability are Storage, Bandwidth, Computing Performance (IT Infrastructure), Software / Application performance and advancement in proposed system features. m. The system shall also support horizontal scalability so that depending on changing

Volume II – Scope of Work and Functional & Technical Specification 108

requirements from time to time, the system may be scaled horizontally. n. Components of the architecture must provide redundancy and ensure that are no single point of failures in the key project components. Considering the high sensitivity of the system, design shall be in such a way as to be resilient to technological sabotage. To take care of remote failure, the systems need to be configured to mask and recover with minimum outage. o. The architecture must adopt an end-to-end security model that protects data and the infrastructure from malicious attacks, theft, natural disasters etc. provisions for security of field equipment as well as protection of the software system from hackers and other threats shall be a part of the proposed system. Using Firewalls and Intrusion detection systems such attacks and theft shall be controlled and well supported (and implemented) with the security policy. The virus and worms attacks shall be well defended with Gateway level Anti-virus system, along with workstation level Anti- virus mechanism. There shall also be an endeavour to make use of the SSL/VPN technologies to have secured communication between Applications and its end users. Furthermore, all the system logs shall be properly stored & archived for future analysis and forensics whenever desired. p. Ease of configuration, ongoing health monitoring, and failure detection are vital to the goals of scalability, availability, and security and must be able to match the growth of the environment. q. System shall use open standards and protocols to the extent possible r. The user interface should be user friendly and provide facility to user for viewing, sorting and printing violations. The software should also be capable of generating query based statistical reports on the violation data.

Volume II – Scope of Work and Functional & Technical Specification 109

s. The data provided for authentication of violations should be in an easy to use format as per the requirements of user unit. t. User should be provided with means of listing the invalid violations along with the reason(s) of invalidation without deleting the record(s). u. Basic image manipulation tools (zoom etc.) should be provided for the displayed image but the actual recorded image should never change. v. Log of user actions be maintained in read only mode. User should be provided with the password and ID to access the system along with user type (admin, user). w. Image should have a header and footer depicting the information about the site IP and violation details like viz. date, time, equipment ID, location ID, Unique ID of each violation, lane number, Regn. Number of violating vehicle and actual violation of violating vehicle etc. so that the complete lane wise junction behaviour is recorded viz. (Speed of violating vehicle, notified speed limit, Speed Violation with Registration Number Plate Recognition facility. Number plate of cars, buses/HTVs should be readable automatically by the software/interface. There should be user interface for simultaneous manual authentication / correction and saving as well x. Number plate of cars, buses/HTVs should be readable automatically by the software/interface. There should be user interface for simultaneous manual authentication / correction and saving as well. y. Interface for taking prints of the violations (including image and above details).

5.2.3. Technical Specifications: Red Light Violation Detection Systems # Parameter Minimum Specifications Bidder Product or better Compliance Documentation (Yes/No) Reference (Yes/No) 1. Make

Volume II – Scope of Work and Functional & Technical Specification 110

2. Model 3. General The system should be capable of generating a video & minimum 3 snapshot in any of the standard industry formats (MJPEG, JPG, avi, mp4, mov, etc) with at least 10 frames per second. The video shall be from t-5 to t+5 sec of the violation and should also be recorded (being the instant at which the infraction occurred). 4. Digital Network Camera a. Video H.264 Compression b. Video Resolution 1920 X 1080 c. Frame rate Min. 30 fps d. Image Sensor 1/3” Progressive Scan CCD / CMOS e. Lens Type Varifocal, C/CS Mount, IR Correction full HD lens f. Lens# Auto IRIS 5~50mm /8 – 40 mm, F1.4 g. Minimum Colour: 0.5 lux, B/W: 0.1 Illumination lux (at 30 IRE) h. IR Cut Filter Automatically Removable IR-cut filter i. Day/Night Mode Colour, Mono, Auto j. S/N Ratio ≥ 50 Db k. Auto adjustment Colour, brightness, + Remote Control sharpness, contrast, white of Image settings balance, exposure control, backlight compensation, Gain Control, Ture Wide Dynamic Range l. Local storage Minimum 64 GB Memory card in a Memory card slot. In the event of failure of connectivity to the central server the camera shall record video locally on the SD card automatically. After the connectivity is restored these recordings shall be automatically merged with the server recording such that no manual intervention is required to transfer the SD card based recordings to server. m. Protocol IPV4, IPV6, HTTP, HTTPS, FTP/SMTP, RTSP, RTP, TCP, UDP, RTCP, DHCP, UPnP, NTP, QoS, ONVIF Profile S

Volume II – Scope of Work and Functional & Technical Specification 111

n. Security Password Protection, IP Address filtering, User Access Log, HTTPS encryption o. Operating 0 to 50°C (temperature), conditions 50 to 90% (humidity) p. Casing NEMA 4X / IP-66, IK10 rated q. Intelligent Video Motion Detection & Tampering alert r. Alarm I/O Minimum 2 Input & 1 Output contact for 3rd part interface

s. Certification UL/EN, CE,FCC 5. On site-out station processing unit communication & Electrical Interface (Junction Box)

a. Data Storage on The system should be site equipped with appropriate storage capacity for 7 days 24X7 recording, with overwriting capability. The images should be stored in tamper proof format only.

b. Network Wired/GPRS based Connectivity wireless technology with 3G upgradable to 4G capability.

c. Minimum 2(two) USB Port to support the latest external mass storage devices and Ethernet (10/100) Port for possible networking. However all logs of data transfer through the ports shall be maintained by the system.

d. The system should be capable of working in ambient temperature range of 0oC to 60oC.

e. Lightening arrester shall be installed for safety of system (As per BIS standard IS 2309 of 1989).

f. The housing(s) should be capable of withstanding vandalism and harsh weather conditions and should meet IP66, IK10 standards (certified).

6. Violation Transmission and Security

Volume II – Scope of Work and Functional & Technical Specification 112

a. Encrypted data, images and video pertaining to Violations at the Onsite processing station should be transmitted to the Interim ICCC/ICCC electronically through GPRS based wireless technology with 3G upgradable to 4G, or wired connectivity if available in Jpeg format

b. Advanced Encryption Standard (AES) shall be followed for data encryption on site and Interim ICCC/ICCC, and its access will protected by a password.

c. The vendor shall ensure that the data from the onsite processing unit shall be transferred to Interim ICCC/ICCC within one day.

7. Video Recording

a. The system should be capable of continuous video recording in base station for 7 days. The system shall automatically overwrite the data after 7 days. It should be noted that at any point of time the local storage at the base station should have the data of previous 7 days.

b. Direct extraction through any physical device like USB flash drive , Portable Hard disk etc. shall be possible

5.2.4. Technical Specifications: Speed Violation Detection System # Description Bidder Product Compliance Documentation (Yes/No) Reference 1. Make Modela. Theb. system should be capable of generating a video & minimum 3 snapshot in any of the standard industry formats (MJPEG, JPG, avi, mp4, mov, etc) with at least 10 frames per second. The video shall be from t-5 to t+5 sec of the violation and should also be recorded (being the instant at which the infraction occurred). 2. Speed

a. Unit of Speed Kmph Measurement

b. Speed detection 200Kmph ± 5% system to Capture speed

c. Speed Threshold (Vendor should provide

Volume II – Scope of Work and Functional & Technical Specification 113

manufacturer certificate/third party test report in support of their claim)

d. Speed Enforcement Radar/Laser/Others Technology

3. Digital Network Camera 1. Video H.264 Compression 2. Video Resolution 1920 X 1080

3. Frame rate Min. 60 fps 4. Image Sensor 1/3” Progressive Scan CCD / CMOS 5. Lens Type Varifocal, C/CS Mount, IR Correction full HD lens 6. Lens# Auto IRIS 5~50mm /8 – 40 mm, F1.4 7. Minimum Colour: 0.5 lux, B/W: 0.1 Illumination lux (at 30 IRE) 8. IR Cut Filter Automatically Removable IR-cut filter 9. Day/Night Mode Colour, Mono, Auto

10. S/N Ratio ≥ 50 Db 11. Auto adjustment Colour, brightness, + Remote Control sharpness, contrast, white of Image settings balance, exposure control, backlight compensation, Gain Control, Ture Wide Dynamic Range 12. Audio Audio Capture Capability, G.711, G.726 13. Local storage Minimum 64 GB Memory card in a Memory card slot. In the event of failure of connectivity to the central server the camera shall record video locally on the SD card automatically. After the connectivity is restored these recordings shall be automatically merged with the server recording such that no manual intervention is required to

Volume II – Scope of Work and Functional & Technical Specification 114

transfer the SD card based recordings to server. 14. Protocol IPV4, IPV6, HTTP, HTTPS, FTP/SMTP, RTSP, RTP, TCP, UDP, RTCP, DHCP, UPnP, NTP, QoS, ONVIF Profile S 15. Security Password Protection, IP Address filtering, User Access Log, HTTPS encryption 16. Operating 0 to 50°C (temperature), conditions 50 to 90% (humidity) 17. Casing NEMA 4X / IP-66, IK10 rated 18. Intelligent Video Motion Detection & Tampering alert 19. Alarm I/O Minimum 1 Input & 1 Output contact for 3rd part interface 20. Certification UL/EN, CE,FCC 1. Recording & display information archive medium

a. The system should be capable of recording the following details of the infracting vehicles

b.  Computer generated unique ID of each violation  Date (DD/MM/YYYY)  Time (HH:MM:SS)  Equipment ID  Location ID  Carriageway or direction of violating vehicle  In cases when multiple infracting vehicles are detected in one instant the system should be capable to provide the following data for all Infracting vehicles detected o Type of Violation o Notified speed limit (in Kmph) o Speed of violating vehicle (in Kmph) o Lane Number of violating vehicle o Registration Number of violating vehicle

Volume II – Scope of Work and Functional & Technical Specification 115

1. On site-out station processing unit communication & Electrical Interface

a. Data Storage on site The system should be equipped with appropriate storage capacity for 7 days 24X7 recording, with overwriting capability. The images should be stored in tamper proof format only.

b. Network Connectivity Wired/GPRS based wireless technology with 3G upgradable to 4G capability.

d. The system should be capable of working in ambient temperature range of 0 degreeC to 60 degree C

e. Atleast one hour UPS power back up to keep the system functional in case of power failure without any break in recording the violation.

f. Lightening arrester shall be installed for safety of system (As per BIS standard IS 2309 of 1989)

g. The housing(s) should be capable of withstanding vandalism and harsh weather conditions and should meet IP66, IK10 standards (certified).

2. Violation Transmission and Security

Volume II – Scope of Work and Functional & Technical Specification 116

b. Advanced Encryption Standard (AES) shall be followed for data encryption on site and Interim ICCC/ICCC, and its access will protected by a password.

c. The vendor shall ensure that the data from the onsite processing unit shall be transferred to Interim ICCC/ICCC within one day.

5. Video Recording

b. Direct extraction through any physical device like USB, Hard disk shall be possible

5.3. Surveillance System

5.3.1. Functional Requirement - Surveillance System Functional Requirement of the overall Surveillance System can be categorised into following components: 1. Information to be Captured by Edge Devises

2. Information to be analysed at Interim ICCC/ICCC 3. Role Based Access to the Entire System 4. Storage / Recording Requirements 5. Other General Requirements

5.3.1.1. Information to be captured by Edge Devices Surveillance Cameras being one of the core sub modules of ITMS, it is important that their selection and placement is carefully done to ensure the full coverage of the traffic junction along with all associated junction arms, accuracy of the information captured on the field and they are rugged, durable & compact. These cameras need to work on 24 X 7 basis and transmit quality video feeds to the Interim ICCC/ICCC and would capture the video feeds at 15 FPS during entire duration of day. However, Gandhinagar Police may take the regular review of the requirements for video resolution,

Volume II – Scope of Work and Functional & Technical Specification 117

FPS and may change these numbers to suit certain specific requirements (for example, there could be a situation when certain cameras are required to be viewed at higher FPS for specific period. It is estimated that not more than 5% of the cameras would be required to be viewed at higher FPS at a given point of time). Video feeds will be stored at 15 FPS for a minimum of 30 days at the Data Centre.

5.3.1.2. Information to be analyzed at Interim ICCC/ICCC The proposed Video Management System should provide a complete end-to-end solution for security surveillance application. The control centre shall allow an operator to view live / recorded video from any surveillance camera on the IP network. The combination of control centre and the IP network would create a virtual matrix, which would allow switching of video streams around the system. It has been envisaged that all surveillance cameras would not be simultaneously viewed at Interim ICCC/ICCC. The viewing shall vary from time to time which will help to manage traffic at the junctions and coordinate with the field police officers.

5.3.1.3. Role Based Access to the Entire System Various users should have access to the system using single sign on and should be role based. Different roles which could be defined (to be finalized at the stage of implementation) could be Administrator, Supervisor, Officer, Operator, etc. Apart from role based access, the system should also be able to define access based on location. Other minimum features required in the role based authentication systems are as follows: a. The management module should be able to capture basic details (including mobile number & email id) of the Police Personnel & other personnel requiring Viewing / Administration rights to the system. There should be interface to change these details, after proper authentication. b. Rights to different modules / sub-modules / functionalities should be role based and proper log report should be maintained by the system for such access. c. The system should be with login name & password enabled to ensure that only the concerned personnel are able to login into the system d. There should be provision to specify hierarchy of operators / officers for control of the cameras from various locations. e. The number of users shall increase as per phase wise implementation. MSI is expected to estimate and provision the same based on the phase wise requirements. f. Windows Active Directory/LDAP or any such system can be used to design role based access.

5.3.1.4. Storage/Recording Requirements It is proposed that the storage solution shall be modular enough to ensure compliance to the changes in storage / recording policy, to be evolved upon initial deployment of the system. The following storage requirements shall be fulfilled by the MSI as scope for the project:

a. The Data Centre (DC) will be hosted at State Data Center (SDC), Government of Gujarat. b. 30 days storage of all the surveillance camera feeds to be stored at Data Centre and Flagged data (critical incidents) will be stored for approximately 90 days, permanent storage envisaged on secondary/backup storage c. 90 days storage for all traffic enforcement systems including RLVD, Speed Violation Detection, Traffic violation cameras and ANPR camera at Data Centre.

Volume II – Scope of Work and Functional & Technical Specification 118

d. 365 days storage of traffic junction data for ATCS at Data Centre and Flagged data will be stored for approximately 4 years. e. Above systems except ATCS are required to be stored on Primary storage for 7 days & on Secondary Storage for remaining days respectively at Data Centre. f. For ATCS, Primary storage will be for 90 days and Secondary Storage for 275 days. Back up storage for 4 Years approximately. g. Data on storage would be over-written automatically by newer data after the stipulated time period. If some data is flagged by police personnel (or by designated personnel) as important data / evidence data due to some reporting of crime or accident in the area or due to court order or due to suspicious activity, it would need to be stored for longer duration, as per requirements. Gandhinagar Police would analyse such flagged data every 3months to take such decisions for preservation of the flagged data beyond 90 days. h. Full audit trail of reports to be maintained for 90 days. i. Bidder is expected to carry out the storage requirement estimation and supply as per the solution proposed. j. Archival/Backup to be done on NAS / Scale-out NAS / SAN / Unified or equivalent storage solution k. Retrieval time for any data stored on secondary storage should be max. 4 hours for critical data & 8 hours for other data. l. The recording servers / system, once configured, shall run independently of the Video Management system and continue to operate in the event that the Management system is off- line. m. The system shall support the use of separate networks, VLANs or switches for connecting the cameras to the recording servers to provide physical network separation from the clients and facilitate the use of static IP addresses for the devices. n. The system shall support H.264 or better, MPEG-4 and MJPEG compression formats for all analog cameras connected to encoders and all IP cameras connected to the system. o. The system shall record the native frame rate and resolution supplied by the camera or as configured by the operator from the system administration server. p. The system should not limit amount of storage to be allocated for each connected device. q. The on-line archiving capability shall be transparent and allow Gandhinagar Police to browse and archive recordings without the need to restore the archive video to a local hard drive for access. r. The system shall allow for the frame rate, bit rate and resolution of each camera to be configured independently for recording. The system shall allow the user to configure groups of cameras with the same frame rate, bit rate and resolution for efficient set-up of multiple cameras simultaneously. s. The system shall support archiving or the automatic transfer of recordings from a camera’s default database to another location on a time-programmable basis without the need for user action or initiation of the archiving process. Archiving shall allow the duration of the camera’s recordings to exceed the camera’s default database capacity. Archives shall be located on either the recording server or on a connected network drive. If the storage area on a network drive becomes unavailable for recording the system should have the ability to trigger actions such as the automatic sending of email alerts and sound alerts to necessary personnel. t. Bandwidth optimisation

Volume II – Scope of Work and Functional & Technical Specification 119

o The Recording Server / System shall offer different codec (H.264, MJPEG, MPEG-4, etc.) and frame rate (CIF, 4CIF, QCIF) options for managing the bandwidth utilisation for live viewing on the Client systems. (through use of multiple systems such as transcoding server) o From the Gandhinagar Police, the user shall have the option of having video images continually streamed or only updated on motion to conserve bandwidth between the Client systems and the Recording Server. u. The Recording Server / System shall support camera (analogue and IP cameras) devices from various manufacturers. v. The Recording Server / System shall support the PTZ protocols of the supported devices listed by the camera OEMs. w. The system shall support full two-way audio between Client systems and remote devices. (Audio from certain set of cameras can be recorded in future). x. Failover Support o The system shall support automatic failover for recording servers. This functionality shall be accomplished by failover server as a standby unit that shall take over in the event that one of a group of designated recording servers fails. Recordings shall be synchronized back to the original recording server once it is back online. o The system shall support multiple failover servers for a group of recording servers. y. SNMP Support o The system shall support Simple Network Management Protocol (SNMP) in order for third-party software systems to monitor and configure the system. o The system shall act as an SNMP agent which can generate an SNMP trap as a result of rule activation in addition to other existing rule actions.

5.3.1.5. Other General Requirements 1. Management/Integration functionality

a. The Surveillance System shall offer centralised management of all devices, servers and users. b. The Surveillance System should not have any limit on the number of cameras to be connected for Surveillance, Monitoring and recording. Any increase in the no. of cameras should be possible by augmentation of Hardware components. c. The Surveillance System should have ability to knit the video streams from multiple cameras, based on the date/time stamp. Every video stream shall have date, time, source camera location, FPS etc. water-marked. These attributes shall be finalised at the System Design time. There shall be a centralised NTP server, from which all devices shall synchronise the date and time. d. The Surveillance System shall support distributed viewing of any camera in the system using Video walls or big screen displays. e. The Surveillance System shall support alarm management. The alarm management shall allow for the continuous monitoring of the operational status and event-triggered alarms from system servers, cameras and other external devices. f. It should be possible to integrate the Surveillance System with 3rd-party software, to enable the users to develop customized applications for enhancing the use of video surveillance solution. For e.g., integrating alarm management to initiate SMS, E-Mail, VoIP call etc.

Volume II – Scope of Work and Functional & Technical Specification 120

g. It should be possible to integrate social media platforms to Surveillance System to enable Gandhinagar Police to track and monitor certain trending incident or crime. h. The Management system shall store the overall network elements configuration in central database, either on the management server computer or on a separate DB Server on the network. i. System should be able to be integrated with Event Management / Incident Management System, if implemented by Gandhinagar Police in future.

2. System Administration functionality

a. The System Administration Server shall provide a feature-rich administration client for system configuration and day-to-day administration of the system b. The System Administration Server shall support different logs related to the Management Server o The System Log o The Audit Log o The Alert Log o The Event Log 3. Rules The system shall support the use of rules to determine when specific actions occur. Rules shall define what actions shall be carried out under specific conditions. The system shall support rule initiated actions such as: o Start and stop recording o Set non-default live frame rate o Set non-default recording rate o Start and stop PTZ patrolling o Send notifications via email o Pop-up video on designated Client Monitor recipients

4. Client System

a. The Client system shall provide remote users with rich functionality and features as described below. b. Viewing live video from cameras on the surveillance system c. Browsing recordings from storage systems d. Creating and switching between multiple of views. e. Viewing video from selected cameras in greater magnification and/or higher quality in a designated hotspot. f. Controlling PTZ cameras. g. Using digital zoom on live as well as recorded video. h. Using sound notifications for attracting attention to detected motion or events. i. Getting quick overview of sequences with detected motion. j. Getting quick overviews of detected alerts or events. k. Quickly searching selected areas of video recording for motion (also known as Smart Search).

Volume II – Scope of Work and Functional & Technical Specification 121

5. Remote Web Client The web-based remote client shall offer live view of up to 16 cameras, including PTZ control and event / output activation. The Playback function shall give the user concurrent playback of multiple recorded videos with date, alert sequence or time searching. a. User Authentication – The Remote Client shall support logon using the user name and password credentials

6. Matrix Monitor

a. Matrix Monitor – The Matrix Monitor feature shall allow distributed viewing of multiple camera on the system on any monitor b. The Matrix Monitor feature shall access the H.264/MJPEG/MPEG4 stream from the connected camera directly and not sourced through the recording server

7. Alarm Management Module a. The alarm management module shall allow for continuous monitoring of the operational status and event-triggered alarms from various system servers, cameras and other devices. The alarm management module shall provide a real-time overview of alarm status or technical problems while allowing for immediate visual verification and troubleshooting. b. The alarm management module shall provide interface and navigational tools through the client including; o Graphical overview of the operational status and alarms from servers, network cameras and external devices including motion detectors and access control systems. o Intuitive navigation using a map-based, hierarchical structure with hyperlinks to other maps, servers and devices or through a tree-view format. c. The module shall include flexible access rights and allow each user to be assigned several roles where each shall define access rights to cameras. d. Basic VMS should be capable to accept third party generated events / triggers e. Based on alarms/alerts, customised/standard alert messages should be published on VMB/PA, after authorisation by a supervisor/operator.

8. Other Miscellaneous Requirements

a. System should have a facility to create CDs or other storage media for submission to Judiciary, which can be treated evidence for legal matters. Such storage media creation should be tamper proof and MSI to provide appropriate technology so that integrity and quality of evidence is maintained as per requirements of the judiciary. Bidder is required to specify any additional hardware / software required for this purpose & the same can be listed in miscellaneous section of the commercial bid. MSI will also prepare the guideline document to be followed by the Police Personnel for the retrieval of Video / images from the CCTV System so as to maintain integrity of the evidence. Such a guideline document should include methods of retrieval of data, check-list to be followed and flowchart of the entire process to be followed. b. All the systems proposed and operationalisation of Video Management System should comply with requirements of IT Acts.

Volume II – Scope of Work and Functional & Technical Specification 122

c. Any hardware or software required to achieve the functional requirement and technical solution of the overall Project (may not be not specified in the schedule) is to be proposed in the Bid and borne by the MSI. d. Bidder shall be required to provide a standardized Mobile Application to integrate smart phones and tablets for 2-way communication with the Surveillance System in a secure manner. Gandhinagar Police may provide such tablets / smart phones to the designated Police Personnel. It will be responsibility of MSI to configure such tablets / Smartphone, for the Surveillance System being implemented a part of this project, and ensure that all the necessary access is given to these mobile users. Functionalities to be provided through mobile application: Viewing of any video steam from Central VMS, uploading of video / pictures central VMS, Location based GIS Map access, tagging of mobile device/location information for all relevant functionalities. Gandhinagar Police reserves the right to appoint any Independent Evaluation Agency at any time during the phases of the project.

5.3.2. Technical Specifications - Surveillance System

5.3.2.1. PTZ Cameras # Parameters Minimum Bidder Compliance Product Specifications or better (Yes/No) Documentation Reference 1. Make 2. Model 3. Video H.264 Compression 4. Video 1920 X 1080 Resolution 5. Frame rate Min. 25 fps 6. Image Sensor 1/3” OR ¼” Progressive Scan CCD / CMOS 7. Lens Auto-focus, 4.3 - 129 mm (corresponding to 30x) 8. Minimum Colour: 0.5 lux, B/W: 0.1 Illumination lux (at 30 IRE) 9. Day/Night Mode Colour, Mono, Auto 10. S/N Ratio ≥ 50Db 11. PTZ Pan: 360° endless/continuous, 0.2 to 300°/s (auto), 0.2 to 100°/s (Manual) Tilt: 90°, 0.2 to 100°/s (Auto), 0.2 to 40°/s (Manual)

Volume II – Scope of Work and Functional & Technical Specification 123

30x optical zoom and 10x digital zoom 64 preset positions Auto-Tracking Pre-set tour 12. Auto adjustment Colour, brightness, + Remote sharpness, contrast, Control of Image white balance, exposure settings control, backlight compensation, Gain Control, Wide Dynamic Range 13. Protocol HTTP, HTTPS, FTP, RTSP, RTP, TCP, UDP, RTCP, DHCP, UPnP, QoS, IPV4, IPV6, ONVIF Profile S 14. Security Password Protection, IP Address filtering, User Access Log, HTTPS encryption 15. Operating 0 to 50°C (temperature), conditions 50-90% humidity 16. Casing NEMA 4X / IP-66 rated 17. Certification UL/EN,CE,FCC 18. Local storage Minimum 64 GB Memory card in a Memory card slot. In the event of failure of connectivity to the central server the camera shall record video locally on the SD card automatically. After the connectivity is restored these recordings shall be automatically merged with the server recording such that no manual intervention is required to transfer the SD card based recordings to server. 19. IR Internal/External. IR range should be 100 mtr or better

5.3.2.2. Fixed Box Cameras

Volume II – Scope of Work and Functional & Technical Specification 124

# Parameter Minimum Specifications Bidder Product or better Compliance Documentation (Yes/No) Reference 1. Make 2. Model 3. Video H.264 Compression 4. Video Resolution 1920 X 1080 5. Frame rate Min. 30 fps 6. Image Sensor 1/3” Progressive Scan CCD / CMOS 7. Lens Type Varifocal, C/CS Mount, IR Corrected Full HD 8. Lens# Auto IRIS 5~50mm/ 8 – 40 mm, F1.4 9. Minimum Colour: 0.5 lux, B/W: 0.1 Illumination lux (at 30 IRE) 10. IR Cut Filter Automatically Removable IR-cut filter 11. Day/Night Mode Colour, Mono, Auto 12. S/N Ratio ≥ 50 Db 13. Auto adjustment Colour, brightness, + Remote sharpness, contrast, white Control of Image balance, exposure control, settings backlight compensation, Gain Control, Wide Dynamic Range 14. 15. Local storage Minimum 64 GB Memory card in a Memory card slot. In the event of failure of connectivity to the central server the camera shall record video locally on the SD card automatically. After the connectivity is restored these recordings shall be automatically merged with the server recording such that no manual intervention is required to transfer the SD card based recordings to server. 16. Protocol IPV4, IPV6, HTTP, HTTPS, FTP/SMTP, NTP, RTSP, RTP, TCP, UDP, RTCP, DHCP, UPnP, QoS, ONVIF Profile S 17. Security Password Protection, IP Address filtering, User Access Log, HTTPS encryption 18. Operating 0 to 50°C (temperature), 50 conditions to 90% (humidity)

Volume II – Scope of Work and Functional & Technical Specification 125

19. Intelligent Video Motion Detection & Tampering alert 20. Alarm I/O Minimum 1 Input & 1 Output contact for 3rd part interface 21. Casing NEMA 4X / IP-66 rated, IK10 22. Certification UL/EN, CE,FCC

About 12 of the camera feeds would be used for detecting wrong way movement traffic violations and should be provided ANPR capability. About 54 would be used for ANPR (Automatic Number Plate Recognition). Please note that the exact numbers may change depending upon the survey carried out by the successful bidder along with Police Dept. Bidders are required to provide necessary provisions in these cameras to support Analytics.

5.3.2.3. IR Illuminators

The infrared illuminators are to be used in conjunction with the Fix Box / PTZ cameras specified above to enhance the night vision. # Parameter Minimum Specifications Bidder Product or better Compliance Documentation (Yes/No) Reference 1. Make 2. Model 3. Range Min. 100 meters, with adjustable angle to cover the complete field of view at specified locations 4. Minimum High sensitivity at Zero Lux Illumination 5. Power Automatic on/off operation 6. Casing NEMA 4X / IP-66 rated 7. Operating -0° to 50°C conditions 8. Certification UL/EN/CE/FCC

5.3.2.4. Fixed Bullet IR Cameras # Parameters Minimum Specifications Bidder Product or better Compliance Documentation (Yes/No) Reference 1. Make 2. Model 3. Video H.264 Compression

Volume II – Scope of Work and Functional & Technical Specification 126

4. Video Resolution 1920 X 1080 5. Frame rate Min. 25 fps 6. Image Sensor 1/3” OR ¼” Progressive Scan CCD / CMOS 7. Lens Fixed 3.6mm or better 8. Minimum Colour: 0.5 lux, B/W: 0 lux Illumination with IR On 9. IR Range 20 Mtrs or better 10. Day/Night Mode Colour, Mono, Auto 11. S/N Ratio ≥ 50Db 12. Auto adjustment + Colour, brightness, Remote Control of sharpness, contrast, white Image settings balance, exposure control, backlight compensation, Gain Control, Wide Dynamic Range 13. Protocol HTTP, HTTPS, FTP, RTSP, RTP, TCP, UDP, RTCP, DHCP, UPnP, QoS, IPV4, IPV6, ONVIF Profile S 14. Security Password Protection, IP Address filtering, User Access Log, HTTPS encryption 15. Operating 0 to 50°C (temperature), conditions 50-90% humidity 16. Casing NEMA 4X / IP-66 rated and IK10 rated 17. Certification UL/EN,CE,FCC

18. Local storage Minimum 64 GB Memory card in a Memory card slot. In the event of failure of connectivity to the central server the camera shall record video locally on the SD card automatically. After the connectivity is restored these recordings shall be automatically merged with the server recording such that no manual intervention is required to transfer the SD card based recordings to server. 19. Power Source PoE, 12V

5.3.2.5. Network Video Recorder

Volume II – Scope of Work and Functional & Technical Specification 127

# Parameter Minimum Specifications Bidder Product or better Compliance Documentation (Yes/No) Reference 1. Make 2. Model 3. Input 8 channel IP camera inputs 4. Output 1 VGA, 1 HDMI 5. Support for Two- 1 channel Input, 1 channel way Talk Output 6. OSD Camera title, Time, Video loss, Camera lock, Motion detection, Recording 7. Video/Audio H.264 / MJPEG / PCM Compression 8. Resolution 1080P (1920×1080) / 720P(1280×720) / D1 (704×576 / 704×480) 9. Record Rate 25 FPS@1080P for each channel 10. Bit Rate 48~8192Kb/s 11. Record Mode Manual, Schedule(Regular(Contin uous), MD, Alarm), Stop 12. Record Interval 1~120 min (default: 60 min), Pre-record: 1~30 sec, Post-record: 10~300 sec 13. Search Mode Time/Date, Alarm, MD & Exact search (accurate to second), Smart search 14. Playback Play, Pause, Stop, Rewind, Functions Fast play, Slow play, Next file, Previous file, Next camera, Previous camera, Full screen, Repeat, Shuffle, Backup selection, Digital zoom 15. Ethernet RJ-45 port (10/100/1000M) 16. Network Functions TCP/IP, UDP, DHCP, DNS, IP Filter, PPPOE, DDNS, FTP, Email, Alarm Server 17. Internal HDD Minimum 2 HDD slots with each capacity of 4TB with RAID 0 (mirroring) support.. Should be provided with appropriate storage to meet the functional requirements.

Volume II – Scope of Work and Functional & Technical Specification 128

18. USB Minimum 2 port 19. Working 0°C to 50°C / 0% to 90% RH Environment 20. Certification UL/EN, CE, FCC 21. Protocol ONVIF

5.3.2.6. Public Address (PA) System # Parameter Minimum Specifications Bidder Product or better Compliance Documentation (Yes/No) Reference

1. Make 2. Model 3. PAS system Should have the capability to control individual PAS i.e. to make an announcement at select location (1:1) and all locations (1: many) simultaneously. The PAS should also support both, Live and Recorded inputs 4. Speaker Minimum 2 speakers, To be used for Public Address System 5. Connectivity IP Based 6. Access Control Access control mechanism would be also required to establish so that the usage is regulated.

7. Integration With VMS and Command and Control Center 8. Construction Cast Iron Foundation and M.S. Pole, Sturdy Body for equipment 9. Battery Internal Battery with different charging options (Solar/Mains) 10. Power Automatic on/off operation 11. Casing IP-55 rated for housing 12. Operating conditions 0° to 50°C

Volume II – Scope of Work and Functional & Technical Specification 129

5.3.2.7. Emergency Call Box (ECB) System

1. A high quality digital transceiver, to be placed at certain traffic junctions determined by the Police Department (mostly at junction boxes / camera poles to avoid any additional investments)

2. Key is to make it easily accessible by public

3. The unit shall preferably have a Double button which when pressed, shall connect to the Interim ICCC/ICCC/Police Command Center/other locations over the existing network infrastructure setup for ATCS project.

Sr. No Parameter Minimum Specifications Bidder Product or better Compliance Documentation (Yes/No) Reference

1. Make

2. Model

3. Construction Cast Iron/Steel Foundation, Sturdy Body for equipment 4. Call Button Watertight Push Button, Visual Feedback for button press 5. Speaker To be used for Public Address System 6. Connectivity GSM/PSTN/Ethernet as per solution offered 7. Sensors For tempering/Vandalism

8. Battery Internal Battery with different charging options (Solar/Mains) 9. Power Automatic on/off operation 10. Casing IP-55 rated for housing

11. Operating conditions 0° to 50°C

5.3.2.8. Field Junction Box # Parameter Minimum Specifications Bidder Product Compliance Documentation (Yes/No) Reference

1. Make

Volume II – Scope of Work and Functional & Technical Specification 130

2. Model

3. Size Suitable size as per site requirements to house the field equipment

4. Cabinet Material GI with powder coated

5. Material Thickness Min 1.2mm

6. Number of Locks Two

7. Protection IP 55, Junction Box design should ensure to keep the temperature within suitable operating range for equipment's and should also avoid intentional water splash and dust intake

8. Mounting On Camera Pole / Ground mounted on concrete base

9. Form Factor Rack Mount/DIN Rail

10. Other Features Rain Canopy, Cable entry with glands, proper earthing and Fans/any other accessories as required for operation of equipment’s within junction box.

5.3.2.9. Poles for Camera # Parameter Minimum Specifications Bidder Product Compliance Documentation (Yes/No) Reference

1. Make

2. Model

3. Pole type Hot Dip Galvanized after Fabrication with Silver coating of 86 micron as per IS:2629; Fabrication in accordance with IS-2713 (1980)

4. Height 5-10 Meters (or higher), as-per-requirements for

Volume II – Scope of Work and Functional & Technical Specification 131

different types of cameras & Site conditions

5. Pole Diameter Min. 10 cm diameter pole (bidder to choose larger diameter for higher height)

6. Cantilevers Based on the location requirement suitable size cantilevers to be considered with the pole

7. Bottom base plate Minimum base plate of size 30x30x1.5 cm

8. Mounting facilities To mount RLVD Cameras, ANPR, Speed detection sensors, CCTV cameras, Traffic Signals, Pedestrian Signals, Switch, etc.

9. Pipes, Tubes All wiring must be hidden, through tubes/pipes. No wires shall be visible from outside.

10. Foundation Casting of Civil Foundation with foundation bolts, to ensure vibration free erection (basic aim is to ensure that video feed quality is not impacted due to winds in different climatic conditions). Expected foundation depth of min. 100cms.

Please refer to earthing standards mentioned elsewhere in the document.

11. Protection Lightning arrester shall be provided, to protect all field equipment mounted on pole.

5.3.2.10. Edge Level Switch (at Traffic Junctions) (Edge Level Switch(at Field Locations)

Volume II – Scope of Work and Functional & Technical Specification 132

# Parameter Specifications Bidder Product Compliance Documentation (Yes/No) Reference 1. Port Density The switch should be rugged & outdoor DIN rail mountable 8 ports Redundancy 10/100/1000TX PoE+( min. 4 Port IEEE802.3at Or 8 Port 802.3af) and with 2 100/1000x SFP ports

May require higher port density at some locations, depending upon site conditions

2. PoE Standard IEEE 802.3af/ IEEE 802.3at or better on all ports simultaneously 3. Quality of Support for Egress rate limiting, Service Eight egress queues per port, Voice VLAN, DSCP for IP-based QoS, Differentiated services architecture, IEEE 802.1p Class of Service with strict and weighted round Robin scheduling. 4. Multicast IGMP Snooping V1, V2, V3 support 5. Management SNMP V1,V2,V3, Web GUI, CLI, USB or equivalent memory card, IP v6 management feature on open standards, IEEE802.1ag, TDM or equivalent standards

6. Security Should support Access Control Lists (ACLs), DHCP snooping, IEEE802.1x based port authentication, RADIUS, TACACS, SSL, SSH, port mirroring, NTP 7. Resiliency IEEE802.1q, IEEE802.1d, IEEE802.1s, IEEE802.1w, ring resilience/ring protection 8. PoE Power per Sufficient to operate the CCTV port cameras/edge devices connected 9. Enclosure Rating IP 30 or equivalent Industrial Grade Rating(to be housed in Junction box) 10. Operating 0 -60 C or better Industrial Grade Rating Temperature 11. Safety UL/EN/IEC or equivalent, RoHS Certifications standards, NEMA –TS2

Volume II – Scope of Work and Functional & Technical Specification 133

5.3.2.11. Online UPS for field locations

Sr No Parameter Minimum Bidder Compliance Product Specifications (Yes/No) Documentation Reference 1. Make

2. Model

3. Capacity Adequate capacity to cover all above IT Components at respective field locations 4. Technology IGBT based PWM Technology, True Online UPS 5. Input 45 to 55 Hz Frequency Range 6. Output 45 to 55 Hz Frequency Range 7. Output Voltage 220VAC - 230VAC

8. Voltage +/-2% (or Regulation better) and with built- in Over Voltage Cut off facility in the Device 9. Frequency 50 Hz +/- 0.1% (free Run Mode) 10. Harmonic < 3% (linear load) Distortion (THD) 11. Output Pure Sine wave Waveform 12. Output Power 0.8 or more Factor 13. Battery Backup Adequate and required battery backup to achieve required uptime of field device as well as SLA of the overall solution.. 14. Battery Type Lead acid, Sealed Maintenance Free (SMF)

Volume II – Scope of Work and Functional & Technical Specification 134

15. General 0 to 50 Degree Operating Celsius Temperature 16. Alarms & All necessary Indications alarms & indications essential for performance monitoring of UPS like mains fail, low battery & fault detection 17. Bypass Automatic, Manual Bypass Switch 18. Certifications For Safety & EMC as per internation al standard 19. Overall IP 55, Protection Junction Box design should ensure to keep the temperatu re within suitable operating range for equipment 's and should also avoid intentional water splash and dust intake

5.3.2.12. ANPR System The ANPR System shall enable monitoring of vehicle flow at strategic locations. The system shall support real-time detection of vehicles at the deployed locations, recording each vehicle, reading its number plate, database lookup from central server and triggering of alarms/alerts based on the vehicle status and category as specified by the database. The system usage shall be privilege driven using password authentication.

# Description Bidder Compliance Product (Yes/No) Documentation Reference

Volume II – Scope of Work and Functional & Technical Specification 135

1. Make

2. Model

3. Vehicle Detection by Color  The system shall detect the color of all vehicles in the camera view during daytime and label them as per the predefined list of configured system colors. The system will store the color information of each vehicle along with the license plate information for each transaction in the database.  The system shall have options to search historical records for post event analysis by the vehicle color or the vehicle color with license plate and date time combinations

4. Alert Generation  The system should have option to input certain license plates according to the hot listed categories like “Wanted”, “Suspicious”, “Stolen”, etc by authorized personnel.  The system should be able to generate automatic alarms to alert the control room personnel for further action, in the event of detection of any vehicle falling in the hot listed categories. 5. Vehicle Status Alarm Module  On successful recognition of the number plate, system should be able generate automatic alarm to alert the control room for vehicles which have been marked as "Wanted", "Suspicious", "Stolen", "Expired". (System should have provision/expansion option to add more categories for future need).  The Instantaneous and automatic generation of alarms. In case of identity of vehicle in any category which is define by user. 6. Vehicle Log Module  The system shall enable easy and quick retrieval of snapshots, video

Volume II – Scope of Work and Functional & Technical Specification 136

and other data for post incident analysis and investigations.  The system should be able to generate suitable MIS reports that will provide meaningful data to concerned authorities and facilitate optimum utilization of resources. These reports shall include. o Report of vehicle flow at each of the installed locations for Last Day, Last Week and Last Month. o Report of vehicles in the detected categories at each of the installed locations for Last Day, Last Week and Last Month. o Report of Vehicle Status change in different Vehicle Categories.  The system shall have Search option to tune the reports based on license plate number, date and time, site location as per the need of the authorities.  The system shall have option to save custom reports for subsequent use. The system shall have option to export report being viewed to common format for use outside of the ANPRS or exporting into other systems.  The system should provide advanced and smart searching facility of License plates from the database. There should be an option of searching number plates almost matching with the specific number entered (up to 1 and 2 character distance) 7. Vehicle Category Editor  The system should have option to input certain license plates according to category like "Wanted", "Suspicious", "Stolen", “Expired" etc. by Authorized personnel.  The system should have an option to add new category by authorized personnel.  The system should have option to update vehicle status in specific

Volume II – Scope of Work and Functional & Technical Specification 137

category by authorized personnel. e.g. on retrieval of stolen vehicle, system entry should be changed from "Stolen" to "Retrieved".  System should have option to specify maximum time to retain vehicle records in specific categories. 8. Central Management Module  The Central Management Module shall run on the ANPRS Central Server in control booth. It should be possible to view records and edit hotlists from the Central Server.

ANPR Specification  Base Specification of Fixed Box Cameras (Section 5.2.2.2 of Annexure I) must be part of the ANPR specifications.

Camera Housing  IP66 standard with sunshield vandal proof Housing 9. Systems requirement  Local Server at Intersection: The system must run on a Commercial Off the Shelf Server (COTS). Outdoor IP 66 Quad core processor based server should be able to cover at least 8 lanes. Temperature rating of the server should be at least 60 degree.  Operating system: The system must be based on open platform and should run on Linux or windows Operating system.  Workstation: Workstation must run on latest available OS.

5.4. Variable Message Signage System

5.4.1. Functional Requirements of the Variable Message Signage System # Description Bidder Compliance Product (Yes/No) Documentation Reference

Volume II – Scope of Work and Functional & Technical Specification 138

1 Make 2 Model 3 System Requirements a. The system should be capable to display warnings, traffic advice, route guidance and emergency messages to motorists from the Interim ICCC/ICCC in real time. b. The system should also be capable to display warnings, traffic advice, route guidance and emergency messages to motorist by using local PC/Laptops. c. The VMS should display text and graphic messages using Light Emitting Diode (LED) arrays. d. The System should able to display failure status of any LED at Interim ICCC/ICCC. e. The System should support Display characters in true type fonts and adjustable based on the Operating system requirement. f. The VMS workstation at the Interim ICCC/ICCC should communicate with the VMS controller through the network. It should send out command data to the variable message sign controller and to confirm normal operation of the signboard. In return, the VMS workstation should receive status data from the VMS controller. g. VMS controllers should continuously monitor the operation of the VMS via the provided communication network. h. Operating status of the variable message sign should be checked periodically from the Interim ICCC/ICCC. i. It shall be capable of setting an individual VMS or group of VMS’s to display either one of the pre-set messages or symbols entered into the computer via the control computer keyboard or by another means. j. It shall be capable of being programmed to display an individual message to a VMS or a group of VMS’s at a pre-set date and time. k. A sequence of a minimum of 10 messages/pictures/ pre-decided sign or group of signs shall be possible to assign for individual VMS or group of VMS’s.

Volume II – Scope of Work and Functional & Technical Specification 139

l. It shall also store information about the time log of message displayed on each VMS. The information stored shall contain the identification number of the VMS, content of the message, date and time at which displayed message/picture starts and ends. m. The central control computer shall perform regular tests (pre-set basis) for each individual VMS. Data communication shall be provided with sufficient security check to avoid unauthorized access. 4 Variable Message Sign board application a.Central Control Software allows controlling multiple VMS from one console. b. Capable of programming to display all types of Message/ advertisement having alphanumeric character in English, Hindi, Gujarati and combination of text with pictograms signs. The system should have feature to manage video / still content for VMS display. The system should have capability to divide VMS screen into multi-parts to display diverse form of information like video, text, still images, advertisements, weather info, city info etc. The system should also provide airtime management and billing system for paid content management c. Capable of controlling and displaying messages on VMS boards as individual/ group. d.Capable of controlling and displaying multiple font types with flexible size and picture sizes suitable as per the size of the VMS. e.Capable of controlling brightness & contrast through software. f.Capable to continuously monitor the operation of the Variable Message sign board, implemented control commands and communicate information to the Interim ICCC/ICCC via communication network. g.Real time log facility – log file documenting the actual sequence of display to be available at central control system. h.Multilevel event log with time & date stamp.

Volume II – Scope of Work and Functional & Technical Specification 140

i.Access to system only after the authentication and acceptance of authentication based on hardware dongle with its log. j. Location of each VMS will be plotted on GIS Map with their functioning status which can be automatically updated. k. Report generation facility for individual/group/all VMSs with date and time which includes summary of messages, dynamic changes, fault/repair report and system accessed logs, link breakage logs, down time reports or any other customized report. l.Conf igurable scheduler on date/day of week basis for transmitting pre-programmed message to any VMS unit. m.Various users should access the system using single sign on and should be role based. Different roles which could be defined (to be finalized at the stage of SRS) could be Administrator, Supervisor, Officer, Operator, etc. n.Apart from role based access, the system should also be able to define access based on location. o.Rights to different modules / Sub-Modules / Functionalities should be role based and proper log report should be maintained by the system for such access p.Components of the architecture must provide redundancy and ensure that there are no single points of failure in the key project components. To take care of remote failure, the systems need to be configured to mask and recover with minimum outage. q.The architecture must adopt an end-to-end security model that protects data and the infrastructure from malicious attacks, theft, natural disasters etc. provisions for security of field equipment as well as protection of the software system from hackers and other threats shall be a part of the proposed system. Using Firewalls and Intrusion detection systems such attacks and theft shall be controlled and well supported (and implemented) with the security policy. The virus and worms attacks shall be well

Volume II – Scope of Work and Functional & Technical Specification 141

defended with Gateway level Anti-virus system, along with workstation level Anti- virus mechanism. There shall also be an endeavour to make use of the SSL/VPN technologies to have secured communication between Applications and its end users. Furthermore, all the system logs shall be properly stored & archived for future analysis and forensics whenever desired. r.Ease of configuration, ongoing health monitoring, and failure detection are vital to the goals of scalability, availability, and security and must be able to match the growth of the environment. s.System shall use open standards and protocols to the extent possible t.Facility to export reports to excel and PDF formats. 3. Remote Monitoring a. All VMS shall be connected/configured to Interim ICCC/ICCC for remote monitoring through network for two way communication between VMS and control Room to check system failure, power failure & link breakage. b. Remote Diagnostics to allow identifying failure up to the level of failed individual LED. 5.4.2. Technical Specifications: Variable Message Signage System # Parameter Description Bidder Product Compliance Documentation (Yes/No) Reference

1. Make

2. Model

3. Dimensions

A Minimum 3.0m length X 1.5m height X 0.2m depth. (3000mm x 1500mm X 200mm approx)

4. Colour LED Full Colour, class designation C2 as per IRC/EN 12966 standard

5. Luminance L3 as per IRC/EN 12966 Class/Ratio standards.

6. Luminance Control & auto Diming

Volume II – Scope of Work and Functional & Technical Specification 142

a. Should be automatically provide different luminance levels but shall also be controllable from the traffic centre using software.

b. Auto dimming capability to adjust to ambient light level (sensor based automatic control)

c. Photoelectric sensor shall be positioned at the sign front and sign rear to measure ambient light. Capable of being continually exposed to direct sunlight without impairment of performance.

7. Contrast Ratio R3 as per IRC/EN 12966 standard

8. Beam Width B6+ as per IRC/EN12966 standards.

9. Pixel Pitch 12mm or better

10. Picture Display

d. At least 300mm as per IRC /EN 12966 standards

e. Full Matrix: Number of lines & characters adjustable, active area: 2.88mX1.2m atleast

f. Synchronized Dot to Dot display.

a. Capable of displaying real time message generated by Interim ICCC/ICCC.

b. Special frontal design to avoid reflection.

c. Display shall be UV resistant

11. Viewing Angle B6+ as per IRC/EN12966 standard- Viewing angle shall ensure message readability for motorists in all lanes of the approach road

12. Viewing Distance Suitable for readability from 150 Mtrs. or more at the character size of 240mm, from moving vehicles.

13. Self-Test

a. VMS shall have self-test diagnostic feature to test for correct operation.

Volume II – Scope of Work and Functional & Technical Specification 143

b. Display driver boards shall test the status of all display cells in the sign even when diodes are not illuminated.

c. All periodic self-test results shall be relayed to the Interim ICCC/ICCC in real time to update the status of the VMS

14. Alarms

a. Door Open sensor to Inform Control room during unauthorized access

b. LED Pixel failure detection alarm

15. Flicker Refresh Frequency should not be less 90 Hz. No visible flicker to naked

eye.

16. Multiple Data RJ45 Ethernet, RS232, RS Communication 485, FC port and any other interface/Port suitable

17. Communication Wired & GPRS based (connectivity) wireless technology with 3G upgradable to 4G capability.

18. Ambient Operating The system should be Temperature capable of working in ambient temperature range of 0oC to 55oC.

19. Humidity (RH) Operating ambient humidity: 10% - 95% Rh or better.

20. Protection against Complete VMS should be Pollution/dust/wat of IP 65 protection level er from front and IP54 from side and rear. As per

Volume II – Scope of Work and Functional & Technical Specification 144

EN60529 or equivalent Standard.

21. Power a. 170-250V AC (more than 90% power factor) or DC as per equipment requirement. b. Protection for overvoltage/ fluctuation/drop of the nominal voltage (50%) shall be incorporated. c. The enclosure shall contain at least two 15 Amp VAC (industrial grade) outlet socket for maintenance purpose.

22. Power Back-up & its UPS for one hour power enclosure back-up with auto switching facility. The enclosure of UPS and battery should be pole mountable with IP 65 protected housing and lockable.

23. Material for VMS at least 2mm aluminum or frame Non-corrosive, water resistant or better. Frame of the VMS should be black & Powder coated. 24. Mounting, Installation and finishes

a. Mounting structure shall use minimum 6Mtrs. High Cylindrical GI Pole (Class B) or suitable structure with 5.5 mtr. Minimum vertical clearance under the VMS sign from the Road surface. b. The mounting shall be capable of withstanding road side vibrations at site of installation.

c. It shall be provided with suitable walkway for maintenance access.

d. The sides interior and rear of enclosures shall be provided in maintenance free natural aluminium finish. All enclosure shall be flat and wipe clean.

e. Rugged locking mechanism should be provided for the onsite enclosures and cabinets.

f . For Structural safety, the successful bidder has to provide structural safety certificate from qualified

Volume II – Scope of Work and Functional & Technical Specification 145

structural engineers approved/ certified by Govt. Agency.

25. Wind Load WL9 as per EN12966 to withstand high wind speeds and its own load.

26. Cabling, connections and Labelling.

a. All cable conductors shall be of ISI marked for quality and safety. It shall be of copper insulated, securely fastened, grouped, wherever possible, using tie warps approximately every 10-20 Cms or cable trays.

b. All connections shall be vibration-proof quick release connections except for power cables terminating in terminal blocks, which shall be screwed down.

c. All terminal block shall be made from self- extinguishing materials. Terminations shall be logically grouped by function and terminals carrying power shall be segregated from control signal terminals.

d. All cables shall be clearly labelled with indelible indication that can clearly be identified by maintenance personnel using “As built : drawings”.

e. Lightening arrester shall be installed for safety on each VMS.

f. The successful bidder has to provide safety certificate from qualified Electrical engineers approved/certified by Govt. Agency.

27. Local Storage in Embedded VMS controller VMS should be capable to store atleast 100 messages and symbols/pictograms to allow display to run in isolated mode on a predefined structures/timings, in case of connectivity failure.

5.5. Integrated Transport Management System

Volume II – Scope of Work and Functional & Technical Specification 146

5.5.1. Functional Requirement of Automatic Vehicle Locator System Sr. No. Requirement Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc. 1 Web based software with high resolution GIS Map and Google Map for showing real time information of vehicles should be provided. 2 System should be capable to give comparative connectivity analysis between any two preferred geographical areas in graphical and tabular manner 3 System should be capable to configure user accessibility, organization and operational structure based on client’s existing structure. 4 AVLS system should have capability to define and track trips using user defined templates. 5 AVLS system should be capable to automatically identify and notify major and minor route violations as per authority’s definition. 6 AVLS system should be smart to automatically force close the trips either in the cases where in GPS Device is in coverage area showing abnormalities in terms of schedules time and distances or in case GPS Device is outside coverage area. Such alerts/events/reports shall be provided. 7 The software shall provide customized GIS Maps along with vector Maps and line map for better decision support facility. 8 The system should be capable to map and plot all fleet performance relevant incidents live on map. 9 Vehicle transit history / Replay should also highlight distance travelled with over speed, low speed, all stoppages, deviated path, other vehicles of same route and their current location, GPS data loss zones etc.

Volume II – Scope of Work and Functional & Technical Specification 147

Sr. No. Requirement Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc. 10 System shall have dedicated dashboard where user shall be able to analyses every scheduled trip, its adherence and other performance relevant information and regularity in single window. 11 The software shall provide map based tracking and transit route line based tracking of vehicles for control centre operators. 12 The software shall have enterprise capabilities which enables multiple user type to carry out various functions like Alarm Management, Vehicle Schedule Tracking, Speed Management, Stoppage management, Route replays, bus tracking dashboard etc. as a standard functionality. 13 The software shall enable Authority to drill and analyses information and online data in a multi-dimensional manner. 14 Comprehensive analysis and reporting capabilities are expected to be part of the application delivery which matches the world standard capabilities of AVLS systems. 15 The system should store the running time whenever a vehicle transits between two waypoints, system should have the ability to accumulate and constantly refines a database of travel times that have occurred to accurately predict the ETA. 16 Ability to measure vehicle’s actual movements against these predicted values to determine how late or early a vehicle is running against the historical averages. These predictions that should be disseminated to PIS and other stakeholders. 17 The system should interface with data sources such as the schedule and planning tool to obtain operational route and timetable data. The system should also support a standard web-service interface for

Volume II – Scope of Work and Functional & Technical Specification 148

Sr. No. Requirement Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc. third party consumers of real-time public transport information.

18 Solution should have On-vehicle hardware and software that provides AVL tracking and integration with on-vehicle equipment including next stop displays, audio systems. 19 The system should have track routes being running, where the stops are located, the timetables for these routes at these stops, all must be current and accurate. 20 System should have functionality to load each vehicle with the complete schedule for a shift when the operator dispatches the vehicle. 21 The system should store the running time whenever a vehicle transits between two waypoints, system should have the ability to accumulate and constantly refines a database of travel times that have occurred to accurately predict the ETA. 22 The system should obtain crew and vehicle allocations through the schedule and planning system. 23 The software should have capability to have a multi-screen based tracking system, so as to enable tracking staff to quickly analyses activities and have a better insight into operational data of all activities within the system. 24 Proposed AVL solution should have capability System should have Tracking buses in real time and predicting ETA at stops and disseminate this information to PIS and on board PIS systems. 25 Ability to define geo-fencing for different locations like parking, depots, stations,

Volume II – Scope of Work and Functional & Technical Specification 149

Sr. No. Requirement Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc. authorized stoppage points, etc with Entry & Exit both being of different radius. 26 System should notify the operator of the communication error in case vehicle is untracked. 27 System should have facility to reproduce the path taken by vehicle with different colour according to vehicle status. 28 Solution should have functionality to change the speed of reproduced path while displaying it on GIS map for better analysis. 29 System should able to display overall fleet status with colour legend in graphical manner. 30 Overall performance analysis based upon operational regularity should be displayed. 31 System should be capable of showing adherence to defined schedule on line diagram of all previous and present trips. 32 System should have ability to show fleet and trip status overview in graphical manner. 33 System should have facility to monitor live station details with self-regulating in-time and out-time of vehicle. 34 System should have functionality to check unassigned vehicle and crew assignment details at any time. 35 Solution should be able to configure incidents with its severity, level as well as authority responsible for handling those incidents. 36 System should be capable of defining route boundary over GIS map and displaying it in software. 37 Solution should be capable of showing all stoppage locations with its details given any stoppage time.

Volume II – Scope of Work and Functional & Technical Specification 150

Sr. No. Requirement Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc. 38 All unauthorized stoppage should be measured and monitored through the system. 39 System should have multi selection functionality for tracking multiple trips information at a same time. 40 Solution should have event management module for configuring special occasions. 41 Solution should be able to depict tabular and graphical representation of trips and fleets statistics. 42 System should be easily configurable based upon user rights and user roles for different modules. 43 Solution should cover all aspects for routes, schedules and vehicles based on user role such as, All stop details (name, location, number, type with functionality to add/edit/delete) All route details (boundary, order, stops with functionality to add/edit/delete) All passenger information details (final & mid-point destination name numbering with functionality of add/edit/delete) All vehicle details (with add/edit/delete) All crew details (with functionality of add/edit/delete) All schedule details (with add/edit/delete) 44 System GUI should provide the ability to perform assignments of crews and vehicles 45 System should have ability to automatically import Routes and timetables and validate against existing route and timetable data within the system and are tested for any timing or route changes.

Volume II – Scope of Work and Functional & Technical Specification 151

Sr. No. Requirement Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc. 46 System should automatically detect the route deviated by vehicle from its predefined one. 47 Software should be able to track vehicle service based on different operational state parameters. 48 Solution should be able to show trip with different color legend based upon its operational status. 49 Solution should be deprived of showing live vehicles, stops and lines on map. 50 Solution should have functionality to display stops, vehicles, lines on straight line diagram. 51 System should be able to generate reports such as, Performance report Exception report Monitoring report Validating report Summary report 52 Solution should able to display information of vehicle, crew and trip on mouse over. 53 System should show detailed control information of vehicle with detailed stop control. 54 Solution should have multi-map view and ability of zone creation. 55 System should have panic button message management and management of detours.

5.5.2. Technical Specification of OBU (On Board Unit)/GPS/Bus Driver Console

Volume II – Scope of Work and Functional & Technical Specification 152

Sr. OBU and BDC architecture Compliance Documentary No. (Yes/No) Reference

1 Usability/Functionality/Capability

A Integrate and interface all features of i Passenger information system (PIS) ii Automatic vehicle location system (AVL) iii Security camera network system (SCN) iv Vehicle health monitoring and diagnostics (VHMD)

B Provide the driver/user interface/display on BDC as specified elsewhere in this document

C Display camera images on BDC as specified elsewhere in this document

D Control PIS functionality as specified elsewhere in the document

E Provide two-way voice and data link with control centre to communicate data and information as specified elsewhere in this document. The link will be based on open public communications network services 3G (GSM) with downward compatibility with 2G

F Provide wireless LAN (Wi-Fi) interface for wireless communications between the vehicle and depot network as specified elsewhere in this document. This interface will not be available to passengers

G Provide capability to upload firmware/ software and configuration of parameters on ‘SCU’ via the wireless LAN

H Provide audio interface to the driver’s microphone and earpiece or speaker using wired link to SCU (Telephone dial up is not envisaged)

I BDC, on a selectable ‘menu’ will have ‘panic’ options’ for communicating pre-configured messages to control centre

J Capability to store 'diagnostic trouble coded' (DTC)’,'parameters identifiers (PID)

K To comply with test standards under Annex 2

Volume II – Scope of Work and Functional & Technical Specification 153

Sr. OBU and BDC architecture Compliance Documentary No. (Yes/No) Reference

N In the event of a loss of on-board vehicle power, the stored data inside the OBU shall not be lost; even if the loss of on-board vehicle power is indefinite.

P OBU shall have map of Surrounding areas on Driver Console. Using that crew shall be able to see the vehicle location.

Q The map shall provide incident location and route choices to incident with travel time on the map for emergency vehicle OBU.

2 Technical specifications: SCU

A Processor: 32/ 64 bit

B Operating system: embedded Windows/Linux with programming software (Windows 7 or latest at the time of calling the tenders)

C Memory: flash: 2 GB minimum, RAM 512 MB minimum (RAM memory includes SCU and BDC)

D Interface: CAN 2.0, RS 485, RS 232, fast Ethernet, USB, digital outputs, digital/Analog inputs, WLAN, audio input output, amplified audio output

E Interface protocols: as specified elsewhere in this document

F In built GPS and 3G(GSM) modules

G WLAN

H Combi antenna using RG174 cable. The connectors on Combi antenna will be preferably SMA(M) ST plug type for GPS and FME(F) jack type 1/4"-36UNS-2B for 3G

I In built /external two channel amplifier minimum 10 Watts rms each suitable for 4 ~8 Ohm impedance with input for external microphone

J In-built MP3 files storage/playback function.

K Power to SCU & BDC will be supplied through bus multiplexing wiring system

3 Technical Specifications: BDC

Volume II – Scope of Work and Functional & Technical Specification 154

Sr. OBU and BDC architecture Compliance Documentary No. (Yes/No) Reference

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) 60°/75° (right/left)/ (vertical) 60°/75° (up and down) iv Adjustable back lighting

B Key board :4 keys minimum

4 Technical specifications: GPS modules

A Rating:22 tracking/66 acquisition minimum

B Tracking sensitivity: -165 dBm typ

C Navigation sensitivity; -148 dBm typ

D Update rate I Hz (configurable to 10 Hz)

E Time to first fix cold acquisition 35 seconds typ

F Hot acquisition 1 second typ.

G Navigation accuracy 3M horizontal

5 Technical specifications: 3G(GSM) modules

A GSM/GPRS SMT quad band and UMTS (3G)

B Temperature range -40°C to +85°C

6 Technical specifications: ‘Combi’ Antenna

A AMPS 850MHz, GSM900MHz, ISM868MHz, DCS1800MHz, PCS1900MHz, 3G UMTS 2.1GHz, Wi-Fi /Blue Tooth (2.4 GHz), GPS (1575.42MHz). Separate WLAN antenna may be provided if necessary.

B GPRS

i Impedance 50 Ohm

ii Radiation pattern Omni-directional

iii Polarization linear (vertical)

C GPS i Impedance 50 Ohms

Volume II – Scope of Work and Functional & Technical Specification 155

Sr. OBU and BDC architecture Compliance Documentary No. (Yes/No) Reference ii VSWR <1.5:1 iii Polarization RHCP

D Waterproof IP-66

E Temperature range -40°C to +85°C

F RG174 cable

7 Fitment on bus

A All ‘OBITS’ equipment including wiring harness, antennas to be original factory fitment.

B Front 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

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 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 SCU, recorder, amplifier: secured and ventilated compartment right above the driver vii BDC: ergonomically placed for driver ease viii Camera: as specified else where ix Ticketing machines - pole Mounted: as specified elsewhere x Combi antenna: suitable place to define inside the bus (preferably) with direct line of view for 'affixing' the unit.

8 Communication amongst sub systems

A Signs' to 'SCU' - RS 485

B Multiplexing nodes' to 'SCU' - CAN 2B (J1939)

Volume II – Scope of Work and Functional & Technical Specification 156

Sr. OBU and BDC architecture Compliance Documentary No. (Yes/No) Reference

C Camera' to 'Recorder’ - AVI or Ethernet (for ‘IP’ camera option)

D SCU to 'BDC' - Ethernet/DVI/VGA/HDMI/RS232/RS485 as required.

E Add -on 'Ethernet switch' and CAN ports are permitted

9 Communication between SCU and depot/central control centre (CCC)

A AVL to CCC:

Raw GPS data in NMEA 0183 protocol (GPVTG, GPGGA, GPRMC, GPGSV and GPGSA) and route number via open public communications network services 3G and download compatibility

B VHMD real time warning to CCC

Open public communications network services 3G and download compatibility

C VHMD end of the day to depot

IEEE 802.11 Wireless LAN (WiFi) via 'Back haul' at depot

D SCN 48 hour recording to depot

IEEE 802.11 Wireless LAN (WiFi) via 'Back haul' at depot plus SD card physical transfer/USB physical transfer

E Firmware download from Depot

IEEE 802.11 Wireless LAN (WiFi) via 'Back haul' at depot

F PIS Two-way communication to depot need based, API to be pre-agreed

G Any protocol provided by ITS supplier will be under a 'NDA' amongst the parties

5.5.3. Technical Specification of PIS

Volume II – Scope of Work and Functional & Technical Specification 157

# Particular Specification Compliance Documentary (Yes/No) Reference 1. Size of 768 x 384 mm (W x H) displaying area 2. Size of body of 900 x 460 mm (W x H) display 3. Pitch 6mm (H) 6mm (V) 4. Resolution 128 x 64 (W x H) 5. Colour RGB 7 color day light readable 6. LED SMD 7. Angle of minimum 160°V, 110°H viewing 8. Min. & Max. 2-30 meters Viewing distance 9. High of display 94mm character 10. Number of 128, but on the display, characters per will display characters route dipped on font style. If it be over displaying area the route will scroll. 11. Intensity of 2500 candelas or more Light sq/m 12. Line vertically 4-line English/Gujarati//Hindi 13. Line height 16 pixel (approx. 96 mm) 14. Communication GPRS/HTTP protocol 15. Controller and inbuilt in display antenna 16. Minimum life 50000 Hrs 17. Powers supply 190V to 250V AC 50Hz 18. update real time (configurable information interval from 1s to 256s) 19. Length of the  a) Route No.: The message for a vehicle Route particular Identity b) route; Vehicle No.: The information Vehicle Identity that needs to of the bus c) be displayed in Time: Estimated English & Time of Arrival of Gujarati the bus at the

Volume II – Scope of Work and Functional & Technical Specification 158

# Particular Specification Compliance Documentary (Yes/No) Reference given bus Stop d) Service Class: Type of service like Limited stop Service etc e) Destination: End point of the Trip f) Via – en-route information Gujarati)  Font style and size. 20. Thnx environmental (a) temperature 0 to 21. 22 spec. +55°C (b) thermal cycling 5°C/mt (c) humidity: 5% to 95% RH (d) sealing IP65

5.5.4. Controller

Bidder Minimum Specifications or Product Documentation # Parameters Compliance better Reference (Yes/No)

Broadcom BCM2387 chipset. 1.2GHz Quad-Core ARM 1 Processor Cortex-A53 802.11 b/g/n Wireless LAN and Bluetooth 4.1 (Bluetooth Classic and LE) ES 2.0, hardware-accelerated Open VG, and 1080p30 H.264 high-profile 2 CPU decode. Capable of 1Gpixel/s, 1.5Gtexel/s or 24GFLOPs with texture filtering and DMA infrastructure 3 Memory 1GB LPDDR2

Boots from Micro SD card, Operating running a version of the 4 System Linux operating system or Windows 10 IoT

Volume II – Scope of Work and Functional & Technical Specification 159

Bidder Minimum Specifications or Product Documentation # Parameters Compliance better Reference (Yes/No)

5 Dimensions 85 x 56 x 17mm

6 Power Micro USB socket 5V1, 2.5A

7 Connectors:

10/100 BaseT Ethernet 8 Ethernet socket

HDMI (rev 1.3 & 1.4 Video 9 Output Composite RCA (PAL and NTSC) Audio Output 3.5mm jack, Audio 10 HDMI Output USB 4 x USB 2.0 Connector

40-pin 2.54 mm (100 mil) expansion header: 2x20 strip GPIO 11 Connector

Providing 27 GPIO pins as well as +3.3 V, +5 V and GND supply lines

Camera 15-pin MIPI Camera Serial 12 Connector Interface (CSI-2)

Display Serial Interface (DSI) Display 15-way flat flex cable 13 Connector connector with two data lanes and a clock lane

Memory 14 Push/pull Micro SDIO Card Slot

Volume II – Scope of Work and Functional & Technical Specification 160

5.5.5. Fixed Box Cameras # Parameter Minimum Specifications Bidder Product or better Compliance Documentation (Yes/No) Reference 23. Make 24. Model 25. Video H.264 Compression 26. Video Resolution 1920 X 1080 27. Frame rate Min. 30 fps 28. Image Sensor 1/3” Progressive Scan CCD / CMOS 29. Lens Type Varifocal, C/CS Mount, IR Corrected Full HD 30. Lens# Auto IRIS 5~50mm/ 8 – 40 mm, F1.4 31. Minimum Colour: 0.5 lux, B/W: 0.1 Illumination lux (at 30 IRE) 32. IR Cut Filter Automatically Removable IR-cut filter 33. Day/Night Mode Colour, Mono, Auto 34. S/N Ratio ≥ 50 Db 35. Auto adjustment Colour, brightness, + Remote sharpness, contrast, white Control of Image balance, exposure control, settings backlight compensation, Gain Control, Wide Dynamic Range 36. 37. Local storage Minimum 64 GB Memory card in a Memory card slot. In the event of failure of connectivity to the central server the camera shall record video locally on the SD card automatically. After the connectivity is restored these recordings shall be automatically merged with the server recording such that no manual intervention is required to transfer the SD card based recordings to server. 38. Protocol IPV4, IPV6, HTTP, HTTPS, FTP/SMTP, NTP, RTSP, RTP, TCP, UDP, RTCP, DHCP, UPnP, QoS, ONVIF Profile S 39. Security Password Protection, IP Address filtering, User Access Log, HTTPS encryption

Volume II – Scope of Work and Functional & Technical Specification 161

40. Operating 0 to 50°C (temperature), 50 conditions to 90% (humidity) 41. Intelligent Video Motion Detection & Tampering alert 42. Alarm I/O Minimum 1 Input & 1 Output contact for 3rd part interface 43. Casing NEMA 4X / IP-66 rated, IK10 44. Certification UL/EN, CE,FCC

5.5.6. Functional requirements Vehicle planning, schedule and dispatch system Sr. No. Requirement Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

General Requirements

The Bidder shall conduct a detailed study of the existing IT infrastructure and data of city 1. during the planning stage of the project and propose a migration plan into the new VPSD.

The VPSD system should be scalable in terms of performance 2. for future increase of users, fleet, crew, depots, etc.

The Bidder shall provide required number of VPSD licenses for all 3. necessary users and the entire fleet for the entire duration of the Project.

VPSD application shall consist of: •Planning & Scheduling o Vehicle Scheduling and timetable o Crew Scheduling and Roster 4. •Dispatch and Daily Management o Dispatch of Vehicles & Crew o Daily Management of Vehicles and Crew

VPSD to be integrated with AVLS as 5. per the requirements.

Volume II – Scope of Work and Functional & Technical Specification 162

Sr. No. Requirement Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

VPSD related data shall be available 6. for a minimum period of 3 years.

Data nomenclature shall follow existing structure as per authority’s requirements such as by division, 7. depot, operation, route, schedule, bus type, employee type, employee, bus, etc.

All terminology in the VPSD application shall be consistent with 8. the current operational terminology used by the authority.

Application shall have ability to 9. have a separate database instances for testing purposes.

All its major features shall be available through toolbar icons and 10. all features shall be accessible with dialog boxes.

All data shall only need to be 11. entered once with no retyping of data necessary.

Application shall have role based 12. access with read and write level access.

Flexibility in access of individual screens of the application shall be 13. provided so that each user shall have different (no access/read/write) privileges.

All components of VPSD shall be integrated with other ITS 14. subsystems so that data entry shall be done only once between the subsystems.

The system shall be modular so 15. that improvements in one sub system/component do not make

Volume II – Scope of Work and Functional & Technical Specification 163

Sr. No. Requirement Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

other subsystems/components to fail.

The Bidder shall identify steps to ensure migration to the Bidder’s 16. VPSD from the current system with least operational challenges for the authority.

Ability to produces printouts of 17. crew schedules, duty rosters, route timetables, bus stop timetables etc.

The system shall provide necessary 18. reports, operations monitoring dashboards and MIS environment.

Network and Route modelling

The objective of network modelling is to digitalize and maintain the GIS information (stops, depots, routes, 19. distances, etc…) and produce a statistical speed analysis to be applied during vehicle scheduling.

The bidder shall collect the existing 20. network databases from authority and propose a migration plan.

The solution shall have map-based interface with the option to use 21. Google Map as a background and being compatible with Google Transit.

All GIS objects shall be editable in the map-based interface (stops, 22. stations, depots, distances, paths, etc…).

The solution shall allow the user to 23. change the path automatically based on road network (with the option to use google map) or

Volume II – Scope of Work and Functional & Technical Specification 164

Sr. No. Requirement Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

manually and enter distances manually.

The solution shall provide specific features for managing and 24. optimizing the dead run (non- commercial trip) on the map.

The solution shall have a schematic 25. view of the routes / network.

The solution shall provide statistical module for analysing GPS 26. data from AVLS in order to build a speed / travel model for the entire network.

The speed / travel time model shall be based on type of days and hours of the day for each path / section (including dead run) of the 27. network. The model shall be further used to produce the timetables and schedules in order to integrate the traffic conditions into the planning process.

Vehicle scheduling and timetables

The objective of vehicle scheduling is to define the schedules / trips of the vehicles based on targeted 28. frequencies depending on routes, types of day and hours of the day and traffic conditions and available resources.

The bidder shall collect the existing 29. timetable databases from authority and propose a migration plan.

The proposed system to allow frequency or number of vehicle 30. approach for producing the vehicle scheduling plan.

Volume II – Scope of Work and Functional & Technical Specification 165

Sr. No. Requirement Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

For frequency approach, the user shall be able to give as a parameter the targeted frequency depending 31. on the hour of the day for a type of day. The system will calculate the necessary number of vehicles.

For number of vehicle approach, the user shall be able to give the maximum number of vehicles 32. (depending on the hour of the day), the system will calculate the optimum frequency at peak hours.

The proposed application shall display vehicle scheduling using graphical representation for the 33. selected period (time-vehicle graph), with different color for each vehicle (stops for Y-scale and time for X-scale).

Ability to define types of day (week days, weekends, holidays, festivals, 34. etc.). Each type of day can have different vehicle scheduling and timetables.

System should have ability/edit 35. specify inbound and/or outbound timetable for a specified day type.

Ability to add, edit and 36. copy/duplicate timetables

Ability to link/add trips to the 37. selected timetable.

Ability to produce and compare what-if scenarios in order to minimize/maximize kilometres 38. (commercial and non-commercial), number of vehicles, crew shifts and hours, extra hours, etc…

Volume II – Scope of Work and Functional & Technical Specification 166

Sr. No. Requirement Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

Crew Scheduling and roster

The objective of crew scheduling is to optimize the crew allocation to the vehicle services. Key indicators are number of crew, hours (driving and non-driving), extra hours, etc… The crew scheduling also helps in providing crew schedules 39. according to personal preferences and social constraints. The proposed solution shall have automatic and manual features for building a roster grid of crew scheduling to be applied to the different types of day.

The system shall support existing crew rules and regulations of the authority and in-turn authority shall be open to the process 40. improvements suggested by the implementation of VPSD system and tailor their processes for the optimal solution.

System shall have ability to create crew schedules considering 41. different shifts parameters such as shift spreads, meal time etc.

System shall have ability to define 42. shift start and end points, break times, etc…

System shall have ability to support minimizing/maximizing crew 43. hours (driving, breaks…), extra hours, total weekly / monthly respecting the rules & regulations.

System should be capable of creating crew schedules for Bus 44. schedules which operate from specific depot / division and transfer crew.

Volume II – Scope of Work and Functional & Technical Specification 167

Sr. No. Requirement Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

System shall support following reports but not limited to: a) Detailed Crew report for each duty / crew day(s) of the week clearly indicating sign On, Sign Off , Trip details that are to be performed, meal break location, etc.. b) Consolidated Crew report for all duties in a depot for day(s) of the 45. week clearly indicating Sign On, Sign Off , On Vehicle, OFF Vehicle, Steering time and hours of duty for driver and conductors c) Statistics reports of crew and depot. d) Horizontal Blocks to provide duty wise details of each crew along with the Route number on which they will perform duty

The Bidder shall provide a Crew 46. Rostering Software with choice based duty.

Crew Rostering module shall be 47. able to create group of users based on set of defined parameters.

System shall have provisions to 48. easily make changes to the planned roster

System shall have provision to create rosters for user definable 49. day types such as Public Holidays, weekends etc.

System should have provision to 50. include non-driving work in the roster

System should have provision to 51. utilise drivers from other Depots

Volume II – Scope of Work and Functional & Technical Specification 168

Sr. No. Requirement Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

Schedule master shall have minimum start place, end place, starting and end time of each trip, 52. rest time in between the trips, distance between the start and end place, distance between stops, overnight stay, etc.

The crew scheduling module shall provide following MIS reports, but are not limited to: • Crew Reports 53. • Driving and non-driving hours • Depot / division reports • Crew Allocation alerts and reports

Dispatch and Daily Management

The objective of the daily dispatch module is to allocate on a daily basis the vehicles and crew to the planned services, depending on maintenance planning for the vehicles and crew holidays or trainings, etc… For each 54. operational day, a type of day shall be applied and physical resources to be allocated. The solution shall have interfaces at the depot for recording the crew operations and store the attendance information (worked and driving hours, absence, etc...).

The proposed solution shall have a vehicle and crew master database 55. with their attributes (type of vehicle, identification, names, etc…).

The proposed solution shall have 56. specific features for preparing the allocation plan for the next days /

Volume II – Scope of Work and Functional & Technical Specification 169

Sr. No. Requirement Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

weeks / months depending on the rules and regulations for the crew.

The proposed solution shall allow change of allocation (vehicle / 57. crew) during the operations at the depot level.

The proposed solution shall record the crew operations of each day (to 58. be further used by other systems for salary calculation or statistics…).

The dispatch module shall provide following MIS reports, but are not limited to: • Vehicle and crew allocation plan for specific periods (weeks, months, year...) 59. • Statistics based on vehicle (KMs, maintenance...) and crew (driving and non-driving hours, extra hours...) • Depot / division reports • Attendance reports

5.5.7. Functional Requirement Incident management system

Sr. Requirement Compliance Reference of No. (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

Incident Handling Module

Volume II – Scope of Work and Functional & Technical Specification 170

Sr. Requirement Compliance Reference of No. (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

System should be able to facilitate user to define Incident Definition during System configuration. And allow user to redefine it as 1. per the need at any later stage. All incident reports should reflect such user driven Incident definition from the immediate effect.

System should have dedicated Incident 2. handling dashboard to View, Analyse and Handle incidents easily.

System should analytical graphical dashboard to evaluate live and historical incidents (such 3. as Route performance analysis, transporter performance analysis) for pattern analysis and better decision making

System should be able to automatically identify Incident severity and exact location of incident 4. along with all previous incidents of same route or trip

Incident handling mechanism should enable control centre staff member to manage 5. incidents based on Priority & severity or escalate it if needed based on user authorization assigned.

System should be able to auto prepare driver 6. score card based on incident reported

System should be capable enough to auto close 7. incidents based on predefined system configuration

System should be able to prompt all incident 8. alerts.

System should be able to support at least 9. following incidents;

Volume II – Scope of Work and Functional & Technical Specification 171

Sr. Requirement Compliance Reference of No. (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

•Fleet Performance

 Vehicle running with Over Speed  Vehicle Running with Minimum Speed  Vehicle attempting Route Deviation  Vehicle having Unidentified Stoppage  Vehicle having Missed Stoppage  Vehicle having Miss out Trip 10.  Vehicle having Early Trip Start  Vehicle having Delayed Trip Start  Vehicles in state of Bunching / Bundling / Headway  Passenger Overload  Organizational Level/Depot/Terminal wise Operational Regularity  Vehicle in Breakdown  Vehicle in Accident / Panic Situation  Equipment Performance  GPS/BDC Device not connected 11.  Low Battery  Shelter PIS Out of order  Onboard PIS Out of order  Incidents Recorded by External Entities Damaged Lane  Riots Blocked Road due to Road Side Accident

12. Blocked Road due to Road Side Working Progress Excess Passenger Flow due to Event/Festival

5.5.8. Functional Requirement Web Portal Sr. No. Requirement Compliance (Yes/No) Reference of documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

Volume II – Scope of Work and Functional & Technical Specification 172

Service provider / bidder shall have to develop web pages which shall allow user to view 1. and download route information, route schedule and real-time ETA.

Web Portal shall allow user to plan their journey based on 2. source and destination preferred.

The portal will act as a single source of information with regards to transportation system in Authority city and hence shall have all possible 3. interfaces like logging complaints, viewing transport information, real-time updates, organizational structure, citizen blogs etc.

5.5.9. Functional Requirements Mobile application # Mobile App Features Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc. Ease of Finding Bus stop / Bus / route / schedule etc. 1 System should show Current Location of user with nearby Bus stop on Map along with the distance & time to travel. 2 User should able to search for nearby station, where the user can get the bus for the route selected by him/her or the Source & destination pair. 3 Show routes and the details of bus reaching in next 15/30 min for the selected bus station. 4 Should able to search the all routes connecting the source and destination provided by them, along with upcoming bus details in those routes. 5 Should able to view all the schedule time for a selected route and between the selected bus stations. 6 Should able to Provide details of Bus location, last stop crossed, Last stop time along with ETA of the particular bus.

Volume II – Scope of Work and Functional & Technical Specification 173

# Mobile App Features Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc. 7 Should able to see the real time expected travel time between his selected source and destination or at the station. Ease Of travelling 8 Should able to mark favourite for a route or for a particular bus stop. Favorites should be displayed in the front for easy access to know upcoming Busses in the favourite route and their ETA/ETD etc. 9 User should able to set an alarm/ notification as per his requirement against a particular schedule time of a particular bus stop in a particular route. The notification should come to User or Alarm should buzz when the ETA of the Bus scheduled to arrive at that station matches with the Predefined time given by User. In case of cancellation of Bus, the User should be notified for the same. Ease of Ticket Booking 10 Should able see the fare between two stations with relevant details like distance, routes connecting two stops etc. 11 Should able to book tickets for travel. The e- ticket/ SMS etc. should able to be verified by ticket collector inside the Bus though the Hand held Machine. 13 Should have a provision to pay for ticket directly through mobile application. Ease of Management 14 Should able to give feedback to authority with photograph of problem/ suggestion. Others 15 Should be available in Android and iOS Only. 18 Should have an Emergency panic button which can be used by user to send exact location of Bus to all relevant persons during emergency.

5.5.10. Functional Requirement MIS Sr. No. Requirement Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/

Volume II – Scope of Work and Functional & Technical Specification 174

MIS/Report/ Brochure etc.

Ability to capture Operational 1. Performance KPI events as they occur

Ability to analyses Trips v/s KMs v/s 2. Passengers v/s Expenditure

Ability to analyses Route 3. Performance

Ability to analyses 4. Exceptions/Events/Incidents

Ability to capture Fleet & Crew 5. performance and prepare Driver performance scorecard

6. Ability to capture depot performance Ability to capture incidents and 7. trigger the training requirements for the crew

Ability to define level of detail from 8. minor to complex as per company or regulatory requirements

MIS Reporting is used to perform day to day monitoring of the ticketing 9. operations and be responsible for generation of MIS reports.

The Back office generates reports automatically at end of day. The Back office collate, format and enable end of day and ad-hoc reports to be 10. printed from the data transmitted by the AFC Devices. Data will be stored in a relational data base structure to permit ad-hoc and detailed log reporting.

MIS reporting should be capable of 11. extracting reports from the day of operations

Details of the parameters of report 12. will be finalized during the design phase.

Below are the minimum number of reports required and all the reports 13. will be finalized during the design phase.

Volume II – Scope of Work and Functional & Technical Specification 175

5.5.11. Functional Requirement Financial Management System # Particular Compliance (Yes/No) Reference of documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc. 1 The Financial Management system shall be standard corporate financial management system including P/L and Balance sheet management. 2 The financial management system shall comprise of enterprise reporting management which shall take care of all accounting functions including fare accounting, disbursal to operations, profit and loss calculations, asset management etc. 3 The financial management system should also manage fare or any other financial transactions with companies offering services. It is envisaged to offer single ticket to passengers to travel across all urban transport systems and hence the financial management system should have capability to account for all such activities and suitably have function to enable payment receivables and deliverables to respective entities – Central Clearing House System.

The reporting for the automated fare collection (AFC) component of the system and the accounting package shall be separate.

The AFC system shall provide reporting on transactions and other financial data in its own right and shall be separate from a third party corporate accounting system.

Volume II – Scope of Work and Functional & Technical Specification 176

# Particular Compliance (Yes/No) Reference of documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc. 4 a) Central Accounting System The central Accounting system shall consist of following sub-systems/ modules but not limited to; • Payments Accounting Module/Sub- system (Treasury section) • Receipts Accounting Module/Sub- System (Treasury section) • Daily Receipts and payments • Cross Verification (Daily Sheets) (Accounting Section). • Bank Reconciliation. • Investment Module. • Gross Cost Contract (GCC) Module 5 b) Receipts Accounting Module (RAM) The receipt of funds shall be a centralized/de-centralized activity and shall be managed by central financial management system. The receipts from the transportation and allied activities shall be managed in the central accounting system. The RAM shall cover the following major activities: • Receipt of Funds (Treasury Section) • Posting in Daily Sheets • Consolidation into Classified Registers • Cross Check with Collection Centres and Treasury Section • Trial Balance (monthly & annually) 6 c) Payment Accounting Module (PAM)

Payment accounting module shall allow both centralized and de- centralized activity and hence payments shall be made from the Central Accounts Department as well from the other operational centres.

The payees shall be able to put up their requests by means of credit bill or Performa invoice to the department, which has placed an order for supplies or for the work or service provided. After due

Volume II – Scope of Work and Functional & Technical Specification 177

# Particular Compliance (Yes/No) Reference of documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc. verification of the supplies received or the work done, the concerned department shall prepare ‘payment memo’, debits it to the appropriate budget-head and then the head of that department or the person who has budget-drawing powers shall signs it. This payment-memo is then sent to the Central Accounts Department. The PAM shall cover the following major activities: - • Payment Memo Approval • Payment • Daily-sheet preparation/posting • Posting in Bills/Budget Ledgers • Consolidation into Classified Register • Trial Balance Preparation 7 d) Daily Receipts and Payments Cross-tally 8 Central accounting system shall provide facility for Item-wise receipts and payment statements (Daily- Sheets) under RAM and PAM every day. These shall be prepared on the basis of paid vouchers and receipt challans, while bank- book (Journal) and cash-book (Journal) shall be written as and when challans are received along with cash or cheques or voucher is paid in cash or by cheque. 9 In order to ensure correctness of daily accounts (receipts and payments) the cash and bankbooks (or main journal) shall be cross-tallied with the sum of the budget item-wise daily statement. If the gross receipts & payments of the day (as per journals) tallies with the sum of the daily sheet, the accounts are presumed to be correct. 10 Depot Management shall automate Depot Operations by providing Vehicle Management, Services Management, Integrated depot management and stores and inventory management 11 This module enables to manage and update depot Operations. It should be enabling maintaining Vehicle Details,

Volume II – Scope of Work and Functional & Technical Specification 178

# Particular Compliance (Yes/No) Reference of documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc. manufacture details, depot and roles of users, staff management etc.

12 Shall provide managing and adding the Crew/staff details such as employee code, role, current address, contact number, personal information.

5.5.12. Functional Requirement Business Intelligence System Sr. Requirement Compliance Reference of documentary No. (Yes/No) proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

1. The purpose of Pervasive Business Intelligence Layer is to augment the native BI capabilities of applications hosted on the data centre. Almost every business application hosted on data centre will have set of reports to be used by the business users. It is expected that the level of maturity of reporting and analytics would vary across applications. Data centre will provide a pervasive business intelligence layer, which can get linked to disparate repositories and can extend the analytics capabilities of hosted applications. This will ensure a single view of business performance matrix (e.g. Cost view, revenue view, project status view etc.) is given to the business users to help them make better decisions.

2. The BI platform must be a comprehensive and integrated suite of Analytical Solutions designed to bring greater business insight to broadest audience of users allowing them to have web based self-service access to relevant and actionable intelligence from relevant data

Volume II – Scope of Work and Functional & Technical Specification 179

Sr. Requirement Compliance Reference of documentary No. (Yes/No) proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

sources (of which they have access to). The BI platform should definitely consist of Managed Reporting, OLAP Analysis, Ad-hoc querying, Dash boarding, Score carding, Business Activity Monitoring, MS Office Integration as well as Mobile / Handheld delivery capabilities. All these need to be provided from a single BI platform and should be available as a web application.

3. The application catering to the areas of Managed Reporting, OLAP Analysis, Ad- hoc querying, Dash boarding, Score carding and Business Activity Monitoring needs to be a zero-foot print application. Zero-foot print also means no applets.

4. Ad Hoc Query Capability: BI Platform must provide an analytical Solution enabling a web based ad-hoc analysis Solution where end user can interact with logical view of information creating charts, pivot tables, reports, gauges, dashboards etc

5. It should have facility to save the queries and edit the same in future to derive newer queries

6. It should have facility to create ad hoc queries through use of simple business terms for querying the data sources

7. for the purpose of comparison or analysis like Arithmetic (sum, difference, round up or down, etc.), Percentage (% difference, % total, etc.), Analytic (Max, Min, average etc.)

8. It should have facility to create ad hoc queries through use of simple business terms for querying the data sources

9. It should have the ability for the business users to create their own charts and graphs based on their requirement. It should have the ability to convert a

Volume II – Scope of Work and Functional & Technical Specification 180

Sr. Requirement Compliance Reference of documentary No. (Yes/No) proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

tabular report into a chart by passing the relevant parameters.

10.Business users should have the ability to define their own measures and calculative fields on the fly and be able to save the new columns that are created as a self-service feature and should not depend on IT to do it. The system should allow the user to save these measures and re-use them in future.

11.Business users should have the ability to understand the data lineage, i.e., the source of the information that they are currently looking at in the BI environment. This could either be a technical view in terms of table name, etc. or a business view.

12.Business users should be able to add comments, remarks on a report and other users should be able to view this comment history so that they know the justification / history.

13.Save and Share Capability: After end user spends time and creates, adds, deletes, changes the pivot table views, he/she should be able to save these changes and share the updated view with group of users.

14.Ability to export the data or report to spread sheets including graphics and to flat file.

15.There should be a facility for an end user to select a few of the reports and mark them as “favorites”

16.Ability to export the reports into CSV, pdf & xls html formats

17.Ability to directly send the report for printing on a LAN printer / personal printer

18.Dashboard Capability: End users should interact with BI platform using rich,

Volume II – Scope of Work and Functional & Technical Specification 181

Sr. Requirement Compliance Reference of documentary No. (Yes/No) proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

interactive, role based, easy to understand web based dashboard providing access to live reports, prompts, charts, tickers, pivot tables and graphics.

19.Should integrate with an existing enterprise portal mechanism

20.Should allow end users to create their own dash boards via a simple drag and drop mechanism

21.Should allow the entire dashboard to be printed as a report

22.Should integrate with a mapping Solution / have one of its own to show geographic activity in terms of a map. Alignment with the Indian Postal Codes map is desired.

23.Should provide dashboard facility with visual features like Metric Dials, Graphs, etc for display and track of metrics

24.Solution shall automatically detect and suggest hierarchical structures in data sets

25.Map physical data structures to business terms in an easy-to-use interface

26.Define consistent business views of the data for relational tables and OLAP cubes

27.Single meta data layer should be used by all the various BI features

28.The same modelling Solution should model the business metadata layer from both a warehouse that is in a star-schema as well as the transactional system relational tables that are not in a star- schema.

29.Multiple metadata views should be able to be developed and published to users. For example, a single metadata model/file should create multiple ‘views’ of the metadata for end user consumption

Volume II – Scope of Work and Functional & Technical Specification 182

Sr. Requirement Compliance Reference of documentary No. (Yes/No) proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

30.The drill path should be based on business hierarchies that are not necessarily organized in the same manner as in the physical representation in the database. By default, when users drill down, the system must automatically drill to the next dimension/level in the business hierarchy. However, users may also select a different drill path to other hierarchies during analysis.

31.Alternate drill down paths should be supported. These should be created at the metadata modelling Solution.

32.Microsoft Office Integration Capability: Given that most users would use office documents like word, excel and power point documents in day to day operations, the BI platform must provide an ability to embed up-to-minute application data in MS office documents while preserving security policy to access data.

33.Allow query and refresh of embed data within native MS applications

34.OLAP Analysis Capability: Ability to do ROLAP, MOLAP and HOLAP analysis, depending on the requirement, needs to be catered to by the Solution.

35.Maintain and monitor status of data cubes being built by users

36.Drill -across dimensions for selected records 1.51 Slice and Dice of data sets

37.Sorting

38.Filtering

39.Should allow different levels of nesting to integrate several rows and columns of data. e.g. build analysis by geography and allow to nest analysis by entity and time within a geography

Volume II – Scope of Work and Functional & Technical Specification 183

Sr. Requirement Compliance Reference of documentary No. (Yes/No) proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

40.Asymmetric analysis and multi-grain analysis of multi-dimensional data should be supported

41.Facility to perform query and analysis on the user defined cubes but not restricting query and analysis to the data cubes created by application 1.48 Trends across dimensions over time evident in the fact records 1.49 Drill-down across hierarchy of levels within a target dimension

42.Drill -across dimensions for selected records 1.51 Slice and Dice of data sets

43.Score carding capability: the application needs to have the ability to build and display scorecards

44.Application shall provide facility to create and maintain organization hierarchy with various organization roles defined

45.Provide metrics and scorecard facility at a team, function and enterprise level

46.Provide dashboard facility with visual features like Metric Dials, Graphs, etc for display and track of metrics

47.The Solution should allow you to view and edit the cause and effect relationships for each metric

48.The Solution should have integration with the reporting section. A report should be easily added or linked to / from a metric.

49.All Analytical Solutions provided in this layer (described as capabilities above) must share a common service oriented architecture, common data access services, common

50.analytical and calculation infrastructure, common metadata management service, common symantec business model, common security model and common administration Solutions

Volume II – Scope of Work and Functional & Technical Specification 184

Sr. Requirement Compliance Reference of documentary No. (Yes/No) proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

51.The BI platform must enable the data centre to single, consistent logical view of information across different department specific operational systems, warehouses and multi-dimensional sources. This will ensure that business user has unified view of all accessible information

52.The logical view of information defined above must be simple, understandable, semantically unified logical business model. This means that BI platform must provide an ability to map complex physical data structures including database tables, derived measures, OLAP cubes etc. into simple business terms.

53.The end user should be able to intuitively interact with BI layer using multiple delivery channels. This means end users can access relevant analysis channels like web based and mobile access.

54.The BI platform should provide ability to do analysis on both operational data (OLTP systems) and historical data (Data Warehouse systems). Specifically, for enabling advanced analysis on operational systems hosted on datacentre, BI platform must provide support for capabilities such as trickle feed ETL, Business Activity Monitoring, Federated data access directly from OLTP systems

55.The BI platform must be hot pluggable in any hosted data source. This means that BI layer should be able to work seamlessly with any popular data source, business application and security infrastructure

56.The presentation layer of BI platform must be based on pure web based architecture based on HTML, DHTML and JavaScript. There should be NO client downloads, no plugin’s, No ActiveX controls, No Applets.

Volume II – Scope of Work and Functional & Technical Specification 185

Sr. Requirement Compliance Reference of documentary No. (Yes/No) proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

57.Solution should be installed in minimum Redhat Linux, Windows 2000, Windows 2003 server, Windows XP, IBM and HP flavors of Unix

58.The Solution needs to have ability to authenticate as well as authorize within the application. Based on the available infrastructure, the administrator should be able to make a choice between the two for the whole deployment.

59.Internal temporary files created on the server side should also be encrypted and secure

60.Reports can be scheduled on the basis of occurrence of a business event / business threshold being breached.

61.Mobile support should be enabled. Should cater to leading technologies such as Blackberry, Symbian as well as Windows Mobile.

5.5.13. Functional Requirement Smart Bus stops

Volume II – Scope of Work and Functional & Technical Specification 186

Sr. No. Requirement Compliance Reference of (Yes/No) documentary proof/evidence supported by system screenshot/ MIS/Report/ Brochure etc.

1 The smart bus stop should have below components

1. Surveillance 2. Smart Lighting 3. LCD Passenger Information System 4. Solar roof top 5. Mobile Charging station 6. Seating place for 5-15 people ( depending on location and feasibility) 7. Standing place for 5-10 people ( depending on location and feasibility)

2 The bus stop should have provision to display static content such as city public transport map, route information etc.

3 The bus stop structure frame and seats shall be made of stainless steel, The structure should be smoothly finished (Grade SS304 satin finish) surface with chamfered edges / corners without any protruding parts.

4 The Side panels should be mounted 3 inches off the ground

5 Easy to use dustbins

6 Smart Bus stop should be inclusive in design - differently-abled, women, children and the elderly requirements should be taken care of.

7 ICT components such as camera, lighting, PIS should have protective casing to reduce vandalism

8 Power requirement of the bus stop should be taken care by rooftop solar

Volume II – Scope of Work and Functional & Technical Specification 187

5.6. Smart Elements

5.6.1. Functional Specification of the Internal Wayfinder & Kiosks 1. Provides simple UI based content Authoring tool. 2. Provides web based powerful Content Manager and a playback engine 3. Built-in template engine 4. Drag-and-Drop media items, easy creation and editing of playlist 5. Crawling text Supports Multiframe and Multi layering Content 6. Supports layering of Video with other content types 7. Images, Videos, Flash, HTML and RSS feeds, IPTV, Live Streaming support 8. Tickers and Crawling Graphics support 9. Manage content by categories and conditional playback rules for media items in playlists and sub-playlists 10. Assign roles and permissions to allow multiple content creators, managers and approvers. Creating associations between content, playlists and groups of users using workgroups 11. Delivery to multiple screen groups/screen attributes 12. Content expiration by date 13. Bring in live feeds such as news, weather, traffic, financial data and social media 14. Integration with Demographics and Data Analytics. 15. Integration with POS data, Hardware like RFID, Touch, gesture, live camera feeds, barcode, QR code etc.. 16. Based on Criteria content playlists are auto populated using Metadata 17. Emergency Messages display by overriding all the running content 18. Content Scheduling and playback based on event and time triggers 19. Make your own design, choose from the many templates and customize them to your style or use marketing materials that are made with your favorite tools 20. Inventory download status can be checked and details of player inventory can be monitored remotely from CM 21. Set non peak timings to download the inventory 22. Stable and Reliable performance 24 hours a day and 7 days a week 23. Superior playback technology delivers smooth sub-pixel motion without distracting choppy, stutters

Volume II – Scope of Work and Functional & Technical Specification 188

24. Player will only download changes, not the entire content 25. Connects with virtually any data and content source 26. With Content Manager schedule and control your messages on one or even thousands of screens 27. Reports of content playback by media items and by players 28. Remote view of player status and player problems 29. Synchronized content playback 30. Remote management of hardware(Eg : Switch OFF/ON Screens) 31. Network bandwidth Throttling 32. Secure and Encrypted communication 33. Generates playback audit report by players, player groups, media Items or any predefined criteria 34. Content Manager supports multiple foreign languages and is capable of rendering content in regional and foreign languages 35. Supports 2D transitions and many 3D transitions 36. Self-Healing Mechanism: Recovers from any software level fault

5.6.2. Technical Specifications of the Media Player

CPU Intel® Atom™ Processor E3845 SoC (22nm); Quad-Core @ 1.91GHz

Chipset Integrated

Memory 4GB DDR3L-1333 SO-DIMMs, Dual Channel, Max. 8GB (Non-ECC)

Graphics Intel® HD Graphics, (Gen 7-LP) 4EU

Display 2x HDMI

H/W EDID -

Ethernet 1x Realtek RTL8111G-CG

1 x mPCIe Expansion Slots 1 x SIM card slot

1x FHD Video Capability 2x HD

Specify Firmware iSmart 2.0

Fanless Yes

iAMT/DASH -

Certification CE/FCC, VCCI class B, cULus & CCC

Storage 64GB SSD

Volume II – Scope of Work and Functional & Technical Specification 189

2x USB 2.0 USB 1x USB 3.0

Dimensions 190mm(W) x 130mm(D) x 19.5mm(H)

Weight 0.8Kg (1.76lbs)

Operating Temperature -30°C~ 60°C (-22°F~140°F)

Power Supply 60W power adaptor

Operating system Win10 IoT Ent LTSB 2016 MultiLang OEI (ESD)

Warranty 3 years

5.7. Smart Poles 5.7.1. Intelligent Pole – Specifications

#. Specifications 1. Intelligent pole should able to meet city aesthetic requirement and it should visual appealing. It should easily blend-in into city street pole master plan. 2. Pole Height requirement is 12 meters. 10 % of the total no. of poles can be of 25 meters. TRAI and DOT guidelines to be followed as the pole will be used as a telecom site. Any local regulations will be taken care by the Concessionaire 3. It should be able to support telecom technologies like GSM, WCDMA, LTE and Wi-Fi. It should also be possible to support future technologies such as 5G

4. It should be possible to support LED luminaries from reputed OEMs

5. Intelligent pole should able to support city as well telecom standards for India such as wind speed, climate, aesthetic etc 6. It should be possible to support connectivity for Intelligent pole

7. The allowed diameter will be as per the BIS regulations and wind speed requirement

8. All cabling, cooling/heating etc should either be via/inside the pole or should be camouflaged (aesthetically concealed) so that it is not visible from outside. 9. The camouflaging material (to cover RF equipment’s) should have RF transparency with attenuation within the permissible limits 10. It should meet EMC requirement of telecom sites as per Indian regulations

11. The minimum power backup requirement is minimum 2 hrs for telecom equipment

12. It should be possible to provide multiple color options as asked by municipality/user as per city light pole colors 13. It should be possible to house radio units with integrated antenna, MW /optical transmission unit, SMPS (AC to DC convertor), batteries, controllers, power distribution etc. either inside the smart pole or should be camouflaged (aesthetically concealed) so that it is not visible from outside 14. It should be possible to house telecom equipment’s from all reputed OEMs.

Volume II – Scope of Work and Functional & Technical Specification 190

15. It should be possible to provide light connection in daisy chain with separate MCB for lighting and telecom part 16. There should be provision to have separate connection for light as well for telecom equipment for maintenance purpose. 17. The paint material (to cover the RF section ) should complied to RF/Telecom requirements

18. It should be possible to color the complete body (including RF equipment camouflaging) by any paint color 19. The cooling/heating equipment’s to cool /heat telecom equipment is integral part of intelligent pole and should be in permissible limits, efforts should be made to reduce the power consumption as much as possible

20. The cabinet where telecom equipment is store should be IP65 compliance or better

21. There should be suitable mounting options for Radio /Antenna unit mounting

22. The ambient temperature requirement is 0-50 deg

23. The overall power budget for intelligent pole should not exceed 2KW (telecom + lights)

24. It should support minimum one light arm per smart pole. However, the same may vary depending on location to be surveyed and finalized by the selected bidder. 25. The minimum life requirement of above intelligent pole structure is 15 years

26. The Concessionaire should not use any banned /restricted material as per Indian regulations

5.7.2. LED based Smart Street light National Lighting Code by Bureau of Indian Standards (IS)- SP 72, 2010, IS 1944, IS 1977 and IEC Standards shall be complied for design and development of street lighting calculations, selection of lighting fixtures, lighting technologies, pole structure & erection, cable selection and sizing, insulation requirements, conductor specifications etc. 5.7.3. LED Specifications The scope includes design, development, manufacturing, testing and supply of energy efficient luminaire complete with all accessories, LED lamps with suitable current control driver circuit including mounting bracket for street light and High mast light. The luminaire shall be suitable for rugged service under the operational and environmental conditions encountered during service. 5.7.4. Smart Street Light Solution # Specifications 1. The smart street lighting solution should be able to operate in any weather conditions 2. The smart street lighting solution should be able to communicate to the centralized software installed at Command and Control Center 3. The solution should be able to operate the luminaires on/off, increase/decrease luminosity (Dimming) as per the command received from the centralized software. This control of smart street lights should also be available through a mobile App ( compatible with iOS, Android) 4. The software should have the capability to apply policies to the smart lighting system.

Volume II – Scope of Work and Functional & Technical Specification 191

5. The city administration should be able to see the real time status of the LED luminaires (like state, power consumption etc) on a city map view of the centralized software 6. The city administration should be able to operate the Smart Lighting System manually too. 7. The smart lighting solution should be able to communicate the system issue or failure to the centralized software. 8. Should enable Over the Air (OTA) firmware update 5.7.5. LED Luminaire # Minimum Specifications

1. High bright white power LEDs shall be used in the Luminaries and the wattage of these LEDs shall be>1W and <3W. 2. Life span of LEDs used in the Luminaire shall be more than 50,000 hours at 70% light output.( Manufacture shall submit the proof- L70& TM 21 test report) 3. Color rendering index (CRI) of the LEDs used in the luminaire shall be greater than 70. 4. Color temperature of the proposed white color LED shall be 5000K-6500K 5. Junction Temperature; Should be less than value at which LM80 (IS16105) data published. Should be >105 Degree C 6. The distribution of luminaire illumination ( control of distribution) shall be based on type of roads as per BIS standard IS 1944 7. Power Factor:0.9

8. Chip Efficacy: Shall be 135 lumen/watt, system lumen output at 25 degree C, supported by LM80 report shall be submitted. 9. CRI of Luminaries: >=70 ( supported by LM80) 10. Light Uniformity ratio ( Emin/ Eavg) shall be as IS 1944 based on category of road

11. The luminaire light output (lumen) shall be constant. The voltage variations/ fluctuations in the specified voltage range shall not impinge upon the lumen it produce maximum +/- 2% is allowed throughout in the input operating voltage range 12. Operating voltage: 120 V to 270 V universal electronic driver with surge protection of 6 KV (Application IS 15885, Driver safety 16104-1/2) 13. Total Harmonic Distortion: <15% THD Test method IEC:610003-2 14. LEDs shall be operated at a current less than 90% of its rated current 15. LED driver efficiency: >=350ma<=1000mA 16. LED driver efficiency Driver (High Voltage, Low current): >85% 17. Luminaire body temperature should not exceed 30 deg C from ambient (45 deg C) without tolerance of 10 deg. C after 24 Hrs. 18. Heat dissipation/heat sink: Well-designed thermal management system with defined heat sink 19. Input Current< 1000mA 20. Should have Open Circuit protection

Volume II – Scope of Work and Functional & Technical Specification 192

21. The Luminaire shall be equipped with distortion free, clear, heat resistant, toughened, UV stabilized glass cover in the front fixed to the die cast. Aluminum frame which shall be fixed to the housing by means of stainless steel screw. 22. The Luminaire shall be built in such a way it can withstand wind speed of 80Kmps 23. Cover/glass without lens or with lens: Fixture cover-UV stabilized Polycarbonate/heat resistance toughened glass or equivalent will be accepted for the Luminaire without lens. For the Luminaire with lens, toughened glass be required with proper IP66 provision is preferred 24. Frequency: 50 Hz+/-3% 25. Operating temperature: Range -10C to +50 C 26. Protections: IP66 for all wattage, Surge protection 6 KV, IEC61000-4-5 27. Working humidity: 10% to 90% RH 28. Conformation standards of Luminaire: The Luminaire should conform to IEC 60598/IS:10322. The Luminaire should be tested as per IEC 60598-2-3:2002/IS:10322 Part 5 sec-3 standards and following test reports should be submitted. Heat resistance test, thermal test, Ingress protection test, drop test electrical/insulation resistance test, endurance test, humidity test, photometry test (LM80 report) vibrant test. 29. Finish: Aesthetically designed housing with corrosion resistant polyester powder coating 30. Luminaire configuration/technical requirement: Side entry type. Shall consist of separate optical and color gear compartments. It should be easy replacement in the field condition 31. Compliance: RoHS/CE/ERTL/ERDI 32. Surge protection: External surge protection of 10 KV to be separately installed with the each fixture 33. Lamp starting time: Max 10 sec 34. Overall system efficacy: >85% 5.7.6. Feeder Panels The Concessionaire shall replace the feeder panel in non-working conditions as per the below mentioned specifications (refer scope of work). Concessionaire shall upgrade the feeder panels in working conditions (like remote transfer of data) with the below mentioned functionality. The design and operation of feeder panels shall comply with SP 72 Part 8 of National Lighting Code 2010. # Specifications 1. Principle equipment should be designed on the basis of `Lossless Series Reactance with Secondary Compensation’ technology (Auto-transformer) 2. The efficiency of such principle equipment should not be less than 99.4% between 50%- 110% of loading 3. Other than basic switching components, no other moving parts are allowed to be installed in the feeder panel 4. 240 VAC 50 Hz Single Phase Two Wire / 415 VAC 50 Hz Three Phase Four Wire Input

Volume II – Scope of Work and Functional & Technical Specification 193

5. Three Taps of Single / Three Phase Four Wire Outputs 6. Standard Output Taps in each Phase at 200/205/210 VAC @ 240 VAC Nominal Input 7. Feeder panels should have GPRS/GSM based remote streetlight monitoring system with capacity for self-protection from short-circuit, over voltage and anti-theft alert 8. The rating of the Streetlight controller should be at least 1.3 times the lighting load as measured during the initial studies 9. Energy Meters to be installed in separately sealable and open able compartment within the Feeder Panels as per the following specifications:  Energy Meters should have Accuracy class of Class 1 or better;  Meters could be either three phase whole current or CT operated for LT as may be required based on the load connected to the feeder panel. The space to be created in the feeder panel for housing the meters should consider the same.  Energy Meters should be capable of logging parameters for each 15 minute time block with stamping of date and time. Such data logs should be retained in the energy meters for a period of 60 days or more.  Such Energy Meters should record the following minimum parameters  Phase to neutral voltages o Phase-wise current o Phase-wise power factor and frequency o Total active power o Total reactive power o Total active energy o Total reactive energy o Total KVAH energy  Meters should have requisite port (Serial port communication – RS232 orRS485) for enabling remote reading and for connection of Modem for the same o Energy Meter specifications should meet the minimum specifications specified by DISCOM and a sign-off on the same shall be obtained from DISCOM prior to finalizing the specifications; o Energy Meters shall be tested, installed and sealed in accordance with procedures specified by DISCOM; o A signoff from DISCOM on the design and specifications of the compartment in the Feeder Panel where the meters are to be housed is also recommended; The Bidder needed to coordinate with Power Discoms for aforementioned energy meters 10. Bidder has to install appropriate power conditioning devices to protect the new EE technologies and components of feeder panels from damage. Poor power quality is not allowed as an excuse for non-functioning of the new technologies installed under the project 11. Fixed capacitor with appropriate capacity shall be introduced in each feeder panel to always maintain a power factor above 0.90 12. In case of Single phase controller unit, 1 pole contactor or multiple parallel pole contactors should be used and in case of 3 phases, appropriate duty 3 pole contactor should be used. The number of contactors used should be suitable for ON/OFF/Dimmed and for changeover between full voltages to various voltage taps and interchanging between taps. The panels should be equipped with a microprocessor based Dual Channel Almanac Timer controller which should be user programmable to enable setting of ON/OFF/Dimmed times and also switching over to savings mode/bypass mode when required 13. All the principle equipment’s along with input output switchgears, metering, switches(bye pass and tap changers), contactors, fuses, auto transformer coils etc. should be of reputed manufacturers and should meet best engineering practices and norms as applicable in relevant standards;  Auto transformer coil should have full current operating efficiency of better than99%

Volume II – Scope of Work and Functional & Technical Specification 194

 The total heat dissipation from single coil should not exceed 6 watts-sec/kVA under fully loaded condition  The rated current of the auto transformer should be for continuous 120% that of input rated current  The switched fuse units should be of 32 Amp continuous AC current capacities.  Fuses used should be of 20 Amp. Rating of high rupturing capacity (S/c current at least 50 kA) 14. The bidders should always ensure that the System is capable to capture live data and record it at variable time-intervals. Following parameters should be recorded for every60- 120 minutes time interval:  Voltages  Current  Power Factor  Active Power (kW)  Apparent Power (kVA)  Metering kWh cumulative  Metering kVAh cumulative  Number of hours the lamps were glowing  Special emergency on/off facility with wireless control.  Benchmarking capacity so as to generate alert SMS for: o Phase-wise currents on crossing threshold values o Phase-wise voltages on crossing threshold values o JSCLB trips o Theft alerts o Group failure of lights o Contactor failure o No output supply  Alert SMS shall be forwarded to five (5) phone numbers. 15. Enclosure Box of feeder panels shall be IP-56 compliant and should be fabricated out of MS sheet SWG 16 / 14 duly powder coated for corrosion resistance and long life.  It should have Single Phase power socket for connecting utility tools like drill machine etc. (capacity 1phase 240Vac / 5Amp socket)  Utility Service Lamp inside Panel for use during maintenance work  Gland Plates for Cable Entry at Incomer and Outgoing Auto Bypass / Tap Changing in lieu of Manual. The tap changing should be automatic between the full voltage and lower voltage for minimum two numbers selected taps.

16. The bidder shall have to get the control panels fabricated from the vendor having type test certificate from CPRI for 31 MVA short-circuit rating up to 400 amp for cubical panels. The copy of the type test certificate shall also have to be produced failing which feeder panels shall not be accepted 17. Design life of the control panel should be mentioned in form of MTBF (mean time between failures) and it should be minimum 15 years 5.7.7. Centralized Management Software # Specifications 1. Web Base Software replaces visual inspections of individual street lighting with sitting at pc with Internet connectivity. Also by fault alarm and monitoring of data user can judge the fault status and severity of fault 2. Remote switching through Web Base Software to override local controller 3. User can demand any time live status of feeder pillar for current electrical and real time parameters 4. Emergency Stop / Manual ON / Manual OFF / Test Mode of feeder pillar 5. User can monitoring and change all settable parameter setting and clock time setting

Volume II – Scope of Work and Functional & Technical Specification 195

6. Control at any level of individually Street lights. Generate electrical profile of any individual feeder pillar 7. Unit can be Direct mapping on Google Map 8. The software shall receive the self-generated data message from individual Feeder Pillar like, ON time, Off time, Dim time, Power Down time, Auto mode / Manual Mode, Volt Fault, Over Current Fault, Short Circuit Fault, Neutral Fault, RTC Fault, ADC Fault, Memory Fault, Low Ampere Fault, Door Open, Relay Fault, Calibration Data and acknowledgement of massage demand by WEB of Parameter writing, E Stop, Test Mode, E Profile, All this massage contain All electrical parameter with real-time clock date and time 9. The software shall generates report of any date or any date range for fault and message of individual unit or all the units. The software shall also generate Range Report for fault, Message, Voltage graph, Current Graph, Streetlight On time, VA Consumption, etc 10. All the data collected by the software can be export to worksheet format for further analysis as per requirement. User can generate graph and report as per requirements 11. System is easily expanded and maintained. New configurations can be made remotely 12. Web Interface gives instant status of the street lights on the dynamic Google map

5.7.8. Recommended Levels of Illumination (as per BEE guidelines) # Type of Road Road Characteristics Average Level of Ratio of Illumination on Minimum/ Road Surface in Average Lux Illumination 1 A-1 Important traffic routes 30 0.4 carrying fast traffic 2 A-2 Main roads carrying 15 0.4 mixed traffic like city main roads/streets, arterial roads, throughways 3 B-1 Secondary roads with 8 0.3 considerable traffic like local traffic routes, shopping streets 4 B-2 Secondary roads with 4 0.3 light traffic 5.7.9. Minimum desired illumination levels during peak hours  Variation in illumination level shall be ± 2% is allowed in input voltage range from 180VAC to 250VAC.  The illumination shall not have infra-red and ultra-violet emission. The test certificate from the NABL approved laboratory shall be submitted.  Electronic efficiency shall be more than 85% 5.7.10. Conformance Standards Product Certification should be obtained from UL or CPRI or any other NABL certified lab. The following test reports should be provided:

LM-79 Luminaire efficacy (Photometry data) LM-80 LED chip data IP 66 Luminaire Ingress Protection Luminaire Endurance Test Practical testing of luminaire through 20,000 cycles

Volume II – Scope of Work and Functional & Technical Specification 196

EN 60929 Performance IEC 60598-1 General requirement and tests IEC 61000-3-2 Limits for Harmonic current emission - THD < 10% IEC61000-4-5 Lightning and industrial surges 5.7.11. Public Wi-Fi - Specification 5.7.11.1. WLAN Controller # Parameter Specifications 1. Hardware Redundancy Features: Controller Must support Active: Active and Active: Standby. Same license should be shared by both the controller. 2. General Feature Ability to map SSID to VLAN. 3. Requirements Should support automatic channel selection – interference avoidance (Co-channel management, Adjacent Channel Management, Channel reuse management). Internal / External Captive Portal. 4. Auto Deployment of APs at Access points can discover controllers on the same L2 domain different locations without requiring any configuration on the access point. 5. Access points can discover controllers across Layer-3 network through DHCP or DNS option 6. System Architecture Centralized MAC addresses filtering 7. Should support onboard/ external DHCP server 8. Controller should support Onboard / External AAA server 9. The proposed architecture should be based on controller based Architecture with thin AP deployment. While Encryption / decryption of 802.11 packets should be performed at the AP. 10. Support roaming between access points deployed on same subnet and different subnets 11. QoS features Per user bandwidth Rate Limiting 12. Self-healing (on detection of RF interference or loss of RF coverage) 13. Should support per user, per device, and per application/TCP- port prioritization 14. Dynamic load balancing to automatically distribute clients to the least loaded 802.11 channel and AP; load balancing must not require any client specific configurations or software 15. Adaptive RF management that provides the capability to pause channel scanning / adjust RF scanning intervals based on application and load presence. 16. Capability to provide preferred access for ―fast clients over ― slow clients (11n vs. 11g) in order to improve overall network performance. 17. Support advanced multicast features with multicast rate optimization, multi-channel use and IGMP snooping 18. RF Management Should be able to load balance clients across channels and access points 19. Should be able to load balance clients based on client count 20. Should be able to load balance clients based on effective throughput on AP 21. Should be able to use client and throughput as a measure to load balance between bands 22. Inline Security Features Should allow authenticated client devices to roam securely from one access point to another, within or across subnets, without any perceptible delay Security during re association. 23. Controller should support AES-128 and AES-256 encryption,

Volume II – Scope of Work and Functional & Technical Specification 197

with site-to-site and client-to-site VPN capabilities; should have provision to supports IPSEC/GRE tunnels 5.7.11.2. Access Point # Parameter Specifications 1. Features The wireless solution should be based on dual radio. 2. 802.11 a/b/g/n/ac / 3x3:3 MIMO, dual radio , access Point 3. The Access Point should have single 10/100/1000 Ethernet interfaces 4. The overall functionality to handle security, mesh, , RF Management, QOS , roaming, local forwarding should be provided by a virtual / software /hardware based WLAN controller so as to increase performance of the WLAN network 5. 802.11 a/b/g/n/ac Access Point should be able to power up using standards 802.3 af/at POE input. 6. Radio 1: 2.4GHz: Chan 1-13 (2412-2472 MHz), 7. Radio 2: 2.4GHz: Chan 1-13 (2412-2472 MHz) 5GHz: All channels from 5200 MHz to 5825 MHz Actual operating frequencies depend on national regulatory limits 8. Two spatial streams for maximum performance in both 2.4 GHz and 5.0 GHz 9. Antenna configuration: 1x1, 2x2, 3x3 10. Antenna Characteristics Antenna Gain 11. 2.4 GHz-2.5 GHz : 4 dBi 12. 5.150 GHz- 5.875 GHz : 4dBi 13. Operating temperature -10 to +60°C or better 14. Storage Temperature -20 to 70°C or better 15. Regulatory FCC certified 16. CE Mark / WPC Compliance 17. Enclosure Should be IP67 rated or higher for outdoor application 18. AP Characteristics Able to be powered over 802.3af/at standard Power-over- Ethernet (PoE). Auto sensing, 10/100/1000 on the network port 19. 16 BSSIDs per AP 20. On Demand Channel Scan, Auto Channel Select 21. Capable of multi-function services including: data access, intrusion detection, intrusion prevention, location tracking, real-time non-disruptive packet capture, RF monitoring with no physical touch and no additional cost 22. AP will provide make before break handovers 23. The wireless meshing AP shall support minimum low hop latency under clear channel conditions and high SNR 24. MESH link should support AES encryption on the MESH link 25. MESH link should support extending corporate network with VLAN Tags and VLAN priority tags to the remote site 26. AP shall provide internal / external antenna options 27. Wi-Fi alliance 802.11ac certified APs 5.7.12. Variable Messaging Boards #. Specifications 1 The Billboards should be hanged at the height of at least 5 meters or above, however the uniformity should be maintained on all the poles 2 The Smart Billboard will be operated from Command & Control Center

Volume II – Scope of Work and Functional & Technical Specification 198

3 It should have ability to house power plant and battery

4 It should have provision for incoming power input cables and fiber connectivity

5 It should be Vandal Proof

6 It should have display of minimum 60 inch.

7 It should be Aesthetical & Camouflaged finish with respect to environment

5.7.13. L2+ 8 Ports Managed PoE Switch (Edge Level switch (For field Locations)) # Parameter Specifications Bidder Product Compliance Documentation (Yes/No) Reference 12. Port Density The switch should be rugged & outdoor DIN rail mountable 8 Redundancy ports 10/100/1000TX PoE+( min. 4 Port IEEE802.3at Or 8 Port 802.3af) and with 2 100/1000x SFP ports

May require higher port density at some locations, depending upon site conditions

13. PoE Standard IEEE 802.3af/ IEEE 802.3at or better on all ports simultaneously 14. Quality of Support for Egress rate limiting, Service Eight egress queues per port, Voice VLAN, DSCP for IP-based QoS, Differentiated services architecture, IEEE 802.1p Class of Service with strict and weighted round Robin scheduling. 15. Multicast IGMP Snooping V1, V2, V3 support 16. Management SNMP V1,V2,V3, Web GUI, CLI, USB or equivalent memory card, IP v6 management feature on open standards, IEEE802.1ag, TDM or equivalent standards

17. Security Should support Access Control Lists (ACLs), DHCP snooping, IEEE802.1x based port authentication, RADIUS, TACACS, SSL, SSH, port mirroring, NTP

Volume II – Scope of Work and Functional & Technical Specification 199

18. Resiliency IEEE802.3ac, IEEE802.3az, IEEE802.1v, IEEE802.1q, IEEE802.1d, IEEE802.1s, IEEE802.1w, ring resilience/ring protection 19. PoE Power per Sufficient to operate the CCTV port cameras/edge devices connected

20. Enclosure IP 30 or equivalent Industrial Rating Grade Rating(to be housed in Junction box) 21. Operating 0 -60 C or better Industrial Grade Temperature Rating 22. Safety UL/EN/IEC or equivalent, RoHS Certifications standards, NEMA –TS2

5.7.14. Environmental Sensors 1. Smart environment sensors will gather data about pollution, ambient conditions (light, noise, temperature, humidity and barometric pressure), weather conditions (wind, rain, fog), levels of gases in the city (pollution) and any other events on an hourly and subsequently daily basis. It is for information of citizens and administration to further take appropriate actions during the daily course/cause of any event. 2. The environment sensors should have the following capabilities: 3. They should be ruggedized enough to be deployed in open air areas, on streets, roads, coastal areas, parks etc. 4. They should be able to read and report at least the following parameters: Air-Quality, Sun Light, Noise, Weather conditions etc. 5. Smart environment sensors will notify and allow citizens and administrators to keep a check on their activities which impact the environment and enable the city to take remedial action if required. 6. These environmental sensors can be connected via 3G wireless network or Wi- Fi/LORA networks based on connection availability. 7. the data should be integratable in third party CCC (Command and Control Centre) Software. Various environment sensors shall sense the environment conditions and send the data to the integrated control system where real time data resides and the same shall be made available to various other departments and applications for decision making. The platform must include intelligent analytical engines that make information meaningful to all stakeholders and helps ease decision making. 8. The environmental data should be submitted in a print ready PDF report format on daily, weekly and monthly basis to at least 5 designated email of the authorities of various departments. 9. In a situation where environmental deterioration crosses a threshold limit set by the concerned authorities in the software system, the system should be able to notify the concerned authorities of various departments by means of SMS and E-mails. 10. Successful bidder can also make use of the Nearby Variable Messaging Displays wherever possible (need to be finalized post detailed survey of locations).

Volume II – Scope of Work and Functional & Technical Specification 200

11. The sensor management platform should allow the configuration of the sensor to the network and also location details etc. 12. The sensors should be able to be managed remotely. This includes sensors being updated with calibration parameters and software upgrades. 13. Apart from information provision, the sensors must ensure data is transmitted securely and have security measures from sensors to the software platform. It must also ensure tamper alerts are provided in cases of vandalism, security breaches, etc.

Sr. No. Parameter Specification

1 Measurement parameters PM 2.5: 0 to 600 micrograms / m3 and range (must measure required ranges) PM 10: 0 to 900 micrograms / m3 NO2: 0 - 10 ppm (minimum detection 10 ppb) NO: 0 - 10 ppm (minimum detection 10 ppb) SO2: 0 - 10 ppm (minimum detection 10 ppb) H2S: 0 - 10 ppm (minimum detection 10 ppb) O3: 0 - 5 ppm (minimum detection 10 ppb) CO: 0 - 500 ppm (minimum detection 100 ppb) CO2: 0 - 2000 ppm NH3: 0 - 50 ppm (minimum detection 300 ppb) CH4: 0 - 1000 ppm (minimum detection 50 ppm) Light: up to 50,000 Lux UV Radiation: up to 50,000 uW/cm2 IR: upto 40,000 Lux Noise: up to 135 dB (A) Rain : in mm/inch of rain Flood-water Level : in cm of water level

2 Temperature, Humidity Real-time Temperature Range: outdoor -10ºC ~ 70ºC and Atmospheric Pressure Sensors Real-time in Air Humidity Level 0-100% RH Real-Time Atmospheric Pressure (in Bars or millibars)

3 Connectivity (Minimum) GPRS (2G) / GSM (3G) / Wi-Fi / LORA Sensors must have provision to interchange between GSM and LORA. Sensors must have Ethernet connectivity for wired data

Volume II – Scope of Work and Functional & Technical Specification 201

communication and USB connectivity for external display connection.

4 Power The sensor should be consuming power as low as 3 Watt and fully operated using Solar Power with minimum of 24 Hours of Battery Backup.

5 Sensor Installation The sensors should be installed between 12 to 15 feet height from ground level on city-pole or wall.

6 Data Frequency Each environmental sensor should be sending data every 120 to 600 seconds. The data frequency should be changeable from sensor management platform.

7 Measurement Principle The sensors should be measuring air-quality and noise parameters from downward (ground) direction to capture vehicular pollution and noise. The sensors should be measuring light parameters from top direction to capture maximum sunlight. The sensors should be measuring particulates from the sideward direction to avoid the effect of gravity on the measurement.

8 Measurement Flow-rate The system should have minimum a suction based air measurement system. For Particulate monitoring should be having minimum 1 Liter / Min as the minimum required flow rate. Where for Gas monitoring should be having minimum 200 ml/min as the minimum required flow rate.

9 System backup The system should have an internal memory for the data backup for minimum 7 days in case of network failure or system maintenance cycles

10 Sensor Configuration and Smart environmental sensors should be centrally Geo-tagging configurable and updated from Command and Control Center Software. Geo location tagging of each environmental sensor should be done from Command and Control Center Software.

11 Weather Protection The mechanical enclosure should be weather resistant with IP65 grade protection.

12 Mechanical Enclosure Smart Environment Sensor should be compact and should be inside a single enclosure (keeping only necessary parts outside for measurement constraints) without exceeding exterior dimensions 400mm X

Volume II – Scope of Work and Functional & Technical Specification 202

300mm X 150mm for better aesthetic value. Mechanical Enclosure should be made of tamper proof material preferably engineering metal.

13 Make in India The Hardware solution should be made in India.

14 Quality Certification The Hardware manufacturer should be having Quality standards with ISO-9001-2015 and Environmental Standards with ISO-14001-2015.

5.8. Cloud Functional and Technical Specification 5.8.1. Cloud Network Requirement 1. CSP must ensure that cloud virtual machine is into separate network tenant and virtual LAN. 2. CSP must ensure that cloud virtual machines are having private IP network assigned to cloud VM. 3. CSP must ensure that all the cloud VMs are in same network segment (VLAN) even if they are spread across multi datacenters of CSP. 4. In case of scalability like horizontal scalability, the CSP should ensure that additional require network is provisioned automatically of same network segment. 5. CSP must ensure that GSCDL gets ability to map private IP address of cloud VM to public IP address as require by SMART CITY from portal of CSP. 6. CSP must ensure that public IP address of cloud VMs remains same even if cloud VM gets migrated to another datacenter due to any incident. 7. CSP must ensure that public IP address of cloud VMs remains same even if cloud VM network is being served from multiple CSP datacenters. 8. CSP must ensure that the public network provisioned for cloud VMs is redundant at every points. 9. CSP must ensure that cloud VMs are accessible from GSCDL private network if private links P2P/MPLS is used by SMART CITY. 10. CSP must ensure that there is access to cloud VMs if SMART CITY require to access it using IPSEC/SSL or any other type of VPN. 11. CSP should ensure that cloud VM network is IPV6 compatible. 12. CSP should have provision of dedicated virtual links for data replication between their multiple datacenter in order to provide secure data replication for DR services. 13. CSP should ensure use of appropriate load balancers for network request distribution across multiple cloud VMs.

5.8.2. Cloud Datacenter Specification 1. The datacenter of CSP must be within India only. 2. All the physical servers, storage and other IT hardware from where cloud resources are provisioned for SMART CITY must be within Indian datacenters only. 3. The datacenters of CSP should be spread across different geolocation in different seismic zones. 4. The CSP datacenters should have adequate physical security in place. 5. The CSP datacenters should comply/certified Tier III datacenter norms.

Volume II – Scope of Work and Functional & Technical Specification 203

6. The Data Center should conform to at least Tier III standard (preferably certified under TIA 942 or Uptime Institute certifications by a 3rd party) and implement tool-based processes based on ITIL standards.

5.8.3. Cloud Storage Service Requirement 1. MSI should provide scalable, dynamic and redundant storage. 2. MSI should offer provision from self-provisioning portal to add more storage as and when require by SMART CITY. 3. MSI should clearly differentiate its storage offering based on IOPS. There should be standards IOPS offering per GB and high performance disk offering for OLTP kind of workload. CSP should delivery minimum 8000 IOPS per TB for OLTP load. The IOPS for NON OLTP load should be minimum 3000 per TB. 4. CSP should have block disk offering as well as file/object disk offering to address different kind of SMART CITY needs. 5. CSP should allow minimum block of 5 GB to be provisioned by SMART CITY from self- service provisioning portal. 6. CSP must give provision to attached new disk block to any cloud VM SMART CITY needs from self-service portal.

5.8.4. Cloud Security Requirement 1. CSP should ensure there is multi-tenant environment and cloud virtual resources of SMART CITY are logically separated from others. 2. CSP should ensure that any OS provisioned as part of cloud virtual machine should be patched with latest security patch. 3. In case, the CSP provides some of the System Software as a Service for the project, CSP is responsible for securing, monitoring, and maintaining the System and any supporting software. 4. CSP should implement industry standard storage strategies and controls for securing data in the Storage Area Network so that clients are restricted to their allocated storage 5. CSP should deploy public facing services in a zone (DMZ) different from the application services. The Database nodes (RDBMS) should be in a separate zone with higher security layer. 6. CSP should give ability to create non-production environments and segregate (in a different VLAN) non-production environments from the production environment such that the users of the environments are in separate networks. 7. CSP should have built-in user-level controls and administrator logs for transparency and audit control. 8. CSP cloud platform should be protected by fully-managed Intrusion detection system using signature, protocol, and anomaly based inspection thus providing network intrusion detection monitoring.

5.9. Solid Waste management

5.9.1. Automatic Vehicle Locator Management System # Description Bidder Compliance Product (Yes/No) Documentation Reference System Requirements

Volume II – Scope of Work and Functional & Technical Specification 204

a. GPS tracking of the waste pick up vehicle for real time tracking b. System should help in co-ordination between primary and secondary collection vehicles for transferring dump c. Route Optimization will help in reduction of trip time, fuel saving and serving more locations d. System should ensure that complete coverage of door to door and community collections served by vehicles e. Record history of vehicle routes, attended sites and other details f. Monitoring & Reporting Application - reports of vehicles, garbage collection status etc.

g. Ensure complete coverage of door to door and community collections served by vehicles h. Alert / Alarm management

a. Real time management of missed garbage transfer

b. Daily report of Door-Door Collection efficiency combined with complaints raised by Public i. Monitoring & Reporting Application - reports of vehicles, garbage collection status, bin status etc. j. Solution should be integrated into the GIS map provided by GSCDL

5.9.2. Mobile GPS based Staff Attendance Management System

GPS based device with RFID receiver shall enable Authority’s field staff to register their attendance/presence throughout the day. The system shall periodically track the location (with time stamping) of the staff through their GPS based mobile device and shall map it in the system with

Volume II – Scope of Work and Functional & Technical Specification 205

the pre-defined area coordinates. The device shall feed the data through GPRS/GSM network to the city operation centre central application for reporting generation and alerts.

1. Provided to Staff who are doing activities such as door-door collection via street sweeping etc.

2. Provide ability for the staff to update job completion reports along with pictures. 3. Pictures should be stored on historical mode in the GIS Map for a period of 1 week. 4. Solution should be integrated into the GIS map provided by GSCDL 5. Solution should be able to mark route attended by the staff along with the allocated route 5.9.3. Mobile application for customer

SI should develop a mobile application to be provided to the Public which will help them raise complaint for following:

a. Garbage Pile on the roads b. Missed Garbage Collection at home / Industrial Area c. Crowd sourcing application for compliant registration and grievances d. Request for Garbage Collection 5.9.4. Unified Dashboard View for Solid Waste Management

A unified View should can show the primary and secondary collection. a. Included all vehicles tracked via AVL or Mobile based. b. Collection Percentage achieved daily – co-relating with the final dumping processes c. Co-relation with the complaints raised / Area, along with photographic evidence 2. System should be capable of providing missed collection 3. System should be capable of marking areas where waste is generated or high to low basis 4. System should be capable of showing only a single selected process for a particular area 5. System should be capable of showing complaints raised by citizen tagged to a particular location.

6. System should be capable of showing CCTV footages from bulk waste generation points and inside the waste treatment plant on the GIS map

7. System should be capable of showing real time data from the load cell placed in the Waste Treatment Facility

8. Unified view should be capable of being integrated with other departments 9. Unified View goal will be to improve waste collection efficiency using the field infrastructure deployed

a. Any other reports aiding to perform the same shall be in scope of SI.

5.9.5. Infrastructure Solutions

Volume II – Scope of Work and Functional & Technical Specification 206

The MSI shall be responsible for the supply, installation & commissioning of the following field equipment’s as per the technical specifications mentioned in the RFP document:

a. GPS Tracking System with all fittings & fixtures in all the vehicles b. GPS based mobile attendance management. c. CCTV Cameras at Waste Processing Site and at bulk waste generation points d. RFID tags at households e. RF tags on collection vehicles f. Automated Weigh bridge

Type of vehicle

Auto Tipper (Primary Collection) GPS Tracking System

Push Carts + Tricycle (Primary Collection) Tracking via GPS Based Attendance System

Twin Dumpers (Secondary Collection) GPS Tracking System

Tipper (Secondary Collection) GPS Tracking System

Tractor (Secondary Collection) GPS Tracking System

Staff Sweeping Roads Tracking via GPS Based Attendance System

The solution that will be proved by the selected SI will have the below mentioned indicative functional requirements. However detailed functional requirement will have to be prepared by the selected SIs after the award of the project by carrying out a details requirement gathering activity with GSCDL and other line departments:

5.9.6. Functional Requirement – SWM Functionality Integration required with Common Functional Requirements

Dash board Dashboard Module should give a quick and easy view to know overall fleet status on real time basis. It should display status information of all vehicles i.e. Running, Idle or Standby. The Dashboard view should provide the following information: Each department separate authentication based vehicle tracking module. 1. Within department section, there shall be a an aggregated view of all the department specific vehicles, its location, movement and other real time details shall be available.

Volume II – Scope of Work and Functional & Technical Specification 207

2. There should be a facility to club the area specific and category specific vehicles in groups. 3. Zone name, Ward Name, Vehicle No, Vehicle Type, Current Location & Last Updated Date & Time of each vehicle. 4. It should give alert message if GPS device gets disconnected from a vehicle. 5. Dashboard should have search parameter where different searches i.e. Vehicle Number wise, Zone & Ward wise, running / idle / standby vehicle wise and “No communication” wise searches can be done. 6. It should also give an indication regarding the running speed of the vehicle i.e. Normal speed, Alarming speed and above Alarming speed. 7. There should be provision to see a particular vehicle on map. A] Map Based Analysis 8. Creating buffers along the emergency site, working site. . GIS 9. Creating & sending alerts in case SUB’s reached at particular level . Integration with for vehicle movement, which can be shown on the map Vehicle Tracking System Functional Requirements - SWM A] Area Details 10. Area information (Zone / Ward / Colony / Society) 11. Population details 12. Volume of the Solid waste which includes Wet & Dry waste (Recycled & Non Recycled) 13. Resources required 14. Collection procedure ( i.e. Primary : House to House & Secondary : Community Bin to Garbage transport centre or mix) B] Garbage Collection Scheduling 15. Assign SWM Vehicles to pick-up the Garbage. Category wise . GIS assignment like A: Highly in demand, B: Medium, C: Low Demand. 16. Assignment of dynamic routes using the vehicle initial route and bins attended. 17. Location-wise assignment of Sanitation Staff 18. Scheduling of garbage collection and cleaning activities with the objective of maximizing citizen friendliness on the one hand and optimum use of resources on the other. C] Primary Garbage Collection & Disposal 19. Record the volume of garbage collected and disposed on a daily . Integration with basis. Weigh Bridge 20. Linkage with Garbage Bins / Land Fill Sites, in case of Citizen . Integration with Grievance Vehicle Tracking 21. Keeping certain Checks as per environmental regulations, like System minimum frequency of lifting garbage etc.

B] MIS

Volume II – Scope of Work and Functional & Technical Specification 208

22. Monitor the deployment of pickup trucks and personnel based on the schedule originally drawn. 23. Info on the use of Transfer Stations 24. How much garbage received? 25. Door to door collection, ward wise 26. Dashboard for all activities 27. Reports of Ward Wise Weight Reports. 28. Energy production report 29. Any other custom report as per department

5.9.7. Technical Requirement – SWM 5.9.7.1. GPS/GSM Tracker # Parameter Minimum Specifications or better

1. Weight Should Be Lightweight.

2. Housing Aluminium Or Fibre Case

3. Operational Temperature -25~70

4. Storage Temperature -40~80

5. Power Consumption <1 W (60ma~100ma)

6. Backup Power 24 Hrs Minimum.(In Ideal Mode)

7. Input Voltage 10~30v

8. Frequency L1,1575.42 MHz

9. Protocol Nmea 0183 V2.2

10. Channels 20

11. Flash 4mbit

12. Sensitivity Tracking: -159dbm

13. Cold Start 42seconds, Average

14. Warm Start 38seconds, Average

15. Hot Start 1 Seconds, Average

16. Reacquisition 0.1 Seconds, Average

17. Accuracy Position: 10meters, 2d Rms,5meters, 2d Rms,Waas Enabled Velocity: 0.1 M/S 18. Frequency Bands Sim 340 Quad-Band: Gsm 850,Egsm 900,Dcs 1800,Pcs 1900. The Band Can Be Set By At Command, And 19. Temperature Range DefaultTime:Normal 1us BandOperation: Synchronized Is Egsm -20 900 To To +55And Gps Dcs Time 1800 ,Compliant To Gsm Phase 2/2+ 20. Data GPRS RestrictedGPRS Data Operation: Downlink - Transfer:25 To -20 AndMax. +55 85.6 To Kbps +70 Storage Temperature -40 To +80 GPRS Data Uplink Transfer: Max. 42.8 Kbps Volume II – Scope of Work and Functional & Technical Specification 209 Coding Scheme: Cs-1, Cs-2, Cs-3 And Cs-4 Sim340

Supports Protocols PAP (Password Authentication Protocol)

Mt, Mo, Cb, Text And Pdu Mode Sms Storage: Sim Card 21. Sms Support Transmission Of Sms Alternatively Over Csd Or Gprs. User Can Choose Preferred Mode.

22. Sim Interface Supported Sim Card: 1.8v ,3v

23. Two Serial Interfaces Serial Port 1 Seven Lines On Serial Port Interface

24. Sim Application Toolkit Supports Sat Class 3, Gsm 11.14 Release 98

25. Real Time Clock Implemented

26. Timer Function Programmable Via At Command

27. Firmware Upgrade Firmware Upgradeable Over Serial Interface

28. Internal Battery Cum Charger Li-Ion Battery With Minimum 08 Hrs Backup When Idle And 04 Hrs When Continuously Used. With 29. Certification AppropriateMinimum IP65 Charger & ARAI To Certification Be Charged From Vehicle Battery 5.9.7.2. Technical Specification- Pan Tilt and Zoom – based Cameras CC TV

# Parameter Minimum Specifications or better

1 Video Compression H.264 or better

2 Video Resolution 1920 X 1080

3 Frame rate Min. 25 fps

4 Image Sensor 1/3” OR 1/4” Progressive Scan CCD / CMOS

5 Lens Auto-focus, 4.7 – 84.6 mm (corresponding to 18x)

6 Minimum Illumination Colour: 0.5 lux, B/W: 0.1 lux (at 30 IRE)

7 Day/Night Mode Colour, Mono, Auto

8 S/N Ratio ≥ 50dB

Pan: 360° endless/continuous, 0.2 to 300°/s (auto), 0.2 to 100°/s (Manual)

Tilt: 90°, 0.2 to 100°/s (Auto), 0.2 to 40°/s (Manual) 9 PTZ 18x optical zoom and 10x digital zoom

16 preset positions Auto-Tracking Pre-set tour Auto adjustment + Remote Colour, brightness, sharpness, contrast, white 10 Control of Image settings balance, exposure control, backlight compensation, Gain Control, Wide Dynamic Range

Volume II – Scope of Work and Functional & Technical Specification 210

11 Protocol HTTP, HTTPS, FTP, RTSP, RTP, TCP, UDP, RTCP, DHCP,SNMP

12 Security Password Protection, IP Address filtering, User Access Log, HTTPS encryption

Volume II – Scope of Work and Functional & Technical Specification 211

# Parameter Minimum Specifications or better

13 Operating conditions 0 to 50°C

14 Casing NEMA 4X / IP-66 rated

15 Certification UL / CE / FCC / EN

The camera should be automatically discovered and 16 Auto Detection & Configuration configured when connected to VMS or Network Switch, to set the right network parameters for the video stream on the network

Camera should support User- definable alerts with 17 Activity detection configurable sensitivities and thresholds, email alert, and HTTP notifications. Camera should also support for IEEE 802.1X authentication

5.9.7.3. Technical Specification- RFID Tag and Reader UHF Passive RFID Tag Specifications

Parameter Specification

Type ABS, High Quality Engineering Plastic

Supported ISO18000-6C EPC Class 1 GEN2 Transponders Frequency Range ISM865~928MHz

Operation Mode Fixed Frequency or FHSS Software Programmable

The tag should support ISO18000-6C protocol standard 2K Bits storage capacity, Memory capacity 1728 Bits (216bytes) writable user area; MR6730B metal supports EPC C1 GEN2 (ISO18000-6C), with 96Bits writable EPC Code area, 512Bits writable user area, and 32Bits password area, EPC 128 bit user 512 bit TID 96 bits. Reading Rate Software Programmable, Average Reading per 64Bits <10ms

212

Reading Range Should be able to be calibrated. (to be kept as 2-4m max) based on the site visit.

Operation Temp -35°C to 85°C

IP Classification IP 68

Weather Heat, dust proof, UV resistant & sea water resistant.

No physical or performance changes in Chemical 168 hour Motor oil exposure Resistance 168 hour Salt water exposure (salinity 10%) 5 hrs Sulfric acid (10 %Ph 2)

1 h Naoh (10 % Ph 14 ) exposure 5.9.7.4. Technical Specification- RFID Reader Specifications Parameter Specification

ISO18000-6C EPC GEN2

Protocol Configurable for mixed or single tag-type operation. Air interface software on IV7 is downloadable to add Gen 2 and Class 1 air interfaces and to “future-proof” the product as standards evolve and new features become available.

Frequency Range Standard ISM 902 928MHz or 915 MHz (US FCC), 865 MHz (ETSI 302-208), and 869 MHz (ETSI 300-220) Operation Mode FHSS

RF Power 0~30dBm, software adjustable

Reading Speed Software Programmable Average Reading per 64Bits <6ms

Reading Mode Timing or Touch, Software Programmable (reading should be such that the reader does reads two tags at a time)

Communication Mode TCP/IP and GPRS or higher with central server Data Input Port Trigger input one time

Reading Range Max 12 m(able to calibrate)

Communication Interface RS232

213

Environmental Rating IP65

Humidity 10% - 90%g1g

Shock and Vibration Withstands standard material handling vehicle environments. Meets or Protection exceeds MIL STD 810F Storage Temperature: -30°C to 75°C (-22°F to 167°F)

Humidity 10% to 90%

Power Supply Vehicle DC power 12 to 60V, 4.5 A maximum

Operating Temperature: -25°C to 55°C (-13°F to 131°F)

5.10. Data Centre

5.10.1. Core Router . # Item Minimum Bidder Compliance Product Specifications (Yes/No) Documentation Reference 1. Make

2. Model 3. Multi-Services Should deliver multiple IP services over a flexible combination of interfaces 4. Ports As per overall network architecture proposed by the bidder, the router should be populated with required number of LAN/WAN ports/modules, with 214

7. Protocol Support Must have support for TCP/IP, PPP Must support IPSEC VPN Must have support for integration of data and voice services Routing protocols of RIP, OSPF, and BGP. Support IPV4 & IPV6

8. Manageability Must be SNMP manageable

9. Scalable  The router should be scalable. For each slot multiple modules should be available.  The chassis offered must have free slots to meet the scalability requirement of expansion of the project in the future.

215

10. Traffic control Traffic Control and Filtering features for flexible user control policies

11. Remote Access Remote access features

12. Redundancy  Redundancy in terms of Power supply(s). Power supply should be able to support fully loaded chassis  All interface modules, power supplies should be hot- swappable 13. QOS Features  RSVP  Priority Queuing  Policy based routing  Traffic shaping  Time-based QoS Policy  Bandwidth Reservation / Committed Information Rate

5.10.2. Internet Router # Item Minimum Bidder Compliance Product Specifications (Yes/No) Documentation Reference 1. Make

2. Model 3. Multi-Services Should deliver multiple IP services over a flexible combination of interfaces

216

4. Ports As per overall network architecture proposed by the bidder, the router should be populated with required number of LAN/WAN ports/modules, with cable for connectivity to other network elements.

5. Speed As per requirement, to cater to entire bandwidth requirement of the project. 6. Interface modules Must support minimum 2* 10G Port with necessary SFP+ Modules. Must have capability to interface with variety interfaces.

7. Protocol Support Must have support for TCP/IP, PPP Must support IPSEC VPN Must have support for integration of data and voice services Routing protocols of RIP, OSPF, and BGP. Support IPV4 & IPV6 8. Manageability Must be SNMP manageable

9. Scalable  The router should be scalable. For each slot multiple modules should be available. 217

11. Remote Access Remote access features

12. e Redundancy  Redundancy in terms of Power supply(s). Power supply should be able to support fully loaded chassis  All interface modules, power supplies should be hot- swappable 13. QOS Features  RSVP  Priority Queuing  Policy based routing  Traffic shaping  Time-based QoS Policy  Bandwidth Reservation / Committed Information Rate

5.10.3. Firewall

218

8. Other  802.1Q, NAT, PAT, IP Multicast support, Remote support Access VPN, Time based Access control lists, URL Filtering, support VLAN, Radius/ TACACS, Support multilayer firewall protection, Traffic shaping, Bandwidth monitoring 9. QoS  QoS features like traffic prioritisation, differentiated services, committed access rate. Should support for QoS features for defining the QoS policies. 10. Management  Console, SSHv2, Browser based configuration  SNMPv1, SNMPv2, SNMPv3 11. Additional  Should have inbuilt HDD of minimum 64 GB Features  Should support DDoS protection 12. Certifications ICSA/NDPP/EAL4

5.10.4. Data Center Switch (Manageable)

219

# Parameter Minimum Bidder Product Specifications Compliance Documentation (Yes/No) Reference

1. Make

2. Model

3. Ports  24 or 48 (as per requirements) 10/100/1000 Base-TX Ethernet ports and extra 2 nos of Base- SX/LX ports  All ports can auto-negotiate between 10Mbps/ 100Mbps/ 1000Mbps, half- duplex or full duplex and flow control for half- duplex ports. 4. Switch type Layer 3

5. MAC Support 8K MAC address.

6. Backplane 56 Gbps or more Switching fabric capacity (as per network configuration to meet performance requirements)

7. Forwarding rate Packet Forwarding Rate should be 70.0 Mbps or better

8. Port Features Must support Port Mirroring, Port Trunking and

220

9. Flow Control Support IEEE 802.3x flow control for full-duplex mode ports.

10. Protocols  Support 802.1D, 802.1S, 802.1w, Rate limiting  Support 802.1Q VLAN encapsulation, IGMP v1, v2 and v3 snooping  802.1p Priority Queues, port mirroring, DiffServ  Support based on 802.1p priority bits with at least 8 queues  DHCP support & DHCP snooping/relay/o ptional 82/ server support  Shaped Round Robin (SRR) or WRR scheduling support.  Support for Strict priority queuing & Sflow  Support for IPV6 ready features with dual stack  Support up-to 255 VLANs and up-to 4K VLAN IDs 221

11. Access Control  Support port security  Support 802.1x (Port based network access control).  Support for MAC filtering.  Should support TACACS+ and RADIUS authentication 12. VLAN  Support 802.1Q Tagged VLAN and port based VLANs and Private VLAN  The switch must support dynamic VLAN Registration or equivalent  Dynamic Trunking protocol or equivalent 13. Protocol and  Network Time Traffic Protocol or equivalent Simple Network Time Protocol support  Switch should support traffic segmentation  Traffic classification should be based on user-definable application types: TOS, DSCP, Port based, TCP/UDP port number

222

14. Management  Switch needs to have RS-232 console port for management via a console terminal or PC  Must have support SNMP v1,v2 and v3  Should support 4 groups of RMON  Should have accessibility using Telnet, SSH, Console access, easier software upgrade through network using TFTP etc. Configuration management through CLI, GUI based software utility and using web interface

5.10.5. Data Center Switch (To be used as Top of the Rack (TOR) switch if required)

# Parameter Minimum Bidder Compliance Product Specifications (Yes/No) Documentation Reference 1. Make 2. Model 3. Ports  24 or 48 (as per density required) 1G/ 10G Ethernet ports (as per internal connection requirements) and extra 2 numbers of

223

224

225

5.10.6. Fire proof enclosure The overall design of the safe should be suitable for safe storage of computer diskettes, tapes, smart cards and similar devices and other magnetic media, paper documents, etc. the safe should have adequate fire protection.

226

5.10.7. KVM Module

# Item Minimum Specifications Bidder Compliance Product (Yes/No) Documentation Reference

1. Make

2. Model

3. KVM Requirement Keyboard, Video Display Unit and Mouse Unit (KVM) for the IT Infrastructure Management at Data Center

4. Form Factor 19” rack mountable

5. Ports minimum 8 ports

6. Server Connections USB or KVM over IP.

7. Auto-Scan It should be capable to auto scan servers

8. Rack Access It should support local user port for rack access

9. SNMP The KVM switch should be SNMP enabled. It should be operable from remote locations

227

10. OS Support It should support multiple operating system

11. Power Supply It should have dual power with failover and built-in surge protection

12. Multi-User support It should support multi- user access and collaboration

5.10.8. Server/Networking rack specifications

# Parameter Minimum Bidder Compliance Product Specifications (Yes/No) Documentation Reference 1. Make 2. Model 3. Type  19” 42U racks mounted on the floor  Floor Standing Server Rack - 42U with Heavy Duty Extruded Aluminum Frame for rigidity. Top cover with FHU provision. Top & Bottom cover with cable entry gland plates. Heavy Duty Top and Bottom frame of MS. Two pairs of 19" mounting angles with 'U' marking. Depth support channels - 3 pairs with an overall weight carrying Capacity of 500Kgs.  All racks should have mounting hardware 228

5.10.9. Enterprise Management Systems (EMS) for Cloud based Services

230

231

# Description Bidder Product Documentation Compliance Reference (Yes/No) 1 Make 2 Model 3 The proposed tool should integrate with network performance management system and support operating system monitoring for various platforms supplied as part of this Project. 4 The proposed tool must provide information about availability and performance for target server nodes. 5 The proposed tool should be able to monitor various operating system parameters such as processors, memory, files, processes, file systems, etc. where applicable. 6 If the offered server/computing 232

Centralized Helpdesk System # Description Bidder Compliance Product Documentation (Yes/No) Reference 1 Make 2 Model 3 Helpdesk system should provide incident management, problem management templates along with helpdesk SLA system for tracking SLA’s pertaining to incident resolution time for priority / non-priority incidents. 4 System should also automatically create tickets based on alarm type 5 The proposed helpdesk solution must provide flexibility of logging, viewing, updating and closing incident via web interface for issues related to the project. 6 IT Asset database should be built and managed by the bidder, in order to carry out the scope of work items.

5.10.10. Centralised Anti-virus Solution The following features are required for centralized anti-virus solution, to protect all computing resources (servers, desktops, other edge level devices, etc.) : 1) Ability to scan through all file types and various compression formats. Ability to scan for HTML, VBScript Viruses, malicious applets and ActiveX controls. 2) Must update itself over internet for virus definitions, program updates etc. (periodically as well as in push-updates in case of outbreaks) 233

5.10.11. Database Licenses  Bidder needs to provide Licensed RDBMS, enterprise/full version as required for the proposed Surveillance System and following all standard industry norms for performance, data security, authentication and database shall be exportable in to XML.

5.10.12. Backup Software 1. The software shall be primarily used to back up the necessary and relevant video feeds from storage that are marked or flagged by the Police. The other data that would require backing up would include the various databases that shall be created for the surveillance system. Details of data that would be created are available in the table at section ‘Data Requirements’ 2. Scheduled unattended backup using policy-based management for all Server and OS platforms 3. The software should support on-line backup and restore of various applications and Databases 4. The backup software should be capable of having multiple back-up sessions simultaneously 5. The backup software should support different types of backup such as Full back up, Incremental back up, Differential back up, Selective back up, Point in Time back up and Progressive Incremental back up and snapshots 234

5.10.13. Directory services 1. Should be compliant with LDAP v3 2. Support for integrated LDAP compliant directory services to record information for users and system resources 3. Should provide authentication mechanism across different client devices / PCs 4. Should provide support for Group policies and software restriction policies 5. Should support security features, such as Kerberos, Smart Cards, Public Key Infrastructure (PKI), etc. 6. Should provide support for X.500 naming standards 7. Should support that password reset capabilities for a given group or groups of users can be delegated to any nominated user 8. Should support that user account creation/deletion rights within a group or groups can be delegated to any nominated user 9. Should support directory services integrated DNS zones for ease of management and administration/replication.

5.10.14. Structured Cabling Components # Parameter Minimum Specifications Bidder Compliance (Yes/No) 1. Standards ANSI TIA 568 C for all structured cabling components 2. OEM OEM Certification and Warranty of Warranty 15-20 years as per OEM standards 3. Certification UL Listed and Verified

5.10.15. Electrical cabling component # Parameter Minimum Specifications Bidder Compliance (Yes/No) 1. Standards All electrical components shall be design manufactured and tested in accordance with relevant Indian standards IEC’s 5.11. Integrated Command and Control Center & Viewing Centers

5.11.1. Integrated Command and Control Center Application

235

10. The platform should be able to normalize the data coming from different devices of same type (i.e. Different lighting sensor from different OEMs, different energy meters from different OEMs etc.) and provide secure access to that data using data API(s) to application developers 11. Convergen System need to have provision that integrates various services and be ce of able to monitor them and operate them. The solution should provide Multiple option to integrate existing deployed solution by City and also need to feeds / provide scalability option to implement new use cases. services System should support DDE and OLE for integration with Process control systems and sensors System should have capability to source data from various systems implemented in Gandhinagar City to create actionable intelligence 12. Industry The solution should adhere to the Industry standards for Standards interoperability, data representation & exchange, aggregation, for the virtualization and flexibility

236

 System Platform – The platform should provide a common data integration layer which can collect and contextualize information from disparate data sources regardless of protocol. The platform should support templatization to allow “build once-deploy everywhere” functionality.  Workflow and Incidents Lifecycle engine – This function should allow users to define and modify new worflows. The workflow could cut across multiple systems via the interfacing modules. Workflow for operational alerts and escalations should be triggered automatically without human intervention. Workflow approvals should have facility to approve from any device with e-signature. This function should provide facility to trigger a corrective action workflow and define the stakeholders for the same. Should manage the life cycle of incidents and related entities via pre-define workflows. The workflow could cut across multiple systems via the interfacing modules. Workflow for operational alerts and escalations should be triggered automatically without human intervention.  Incidents Planning – should manage the planning preparations of an incident including resource allocation, tasks management etc. 237

26. The system must identify and track status of critical infrastructure / resources and provide a status overview of facilities and systems 27. Should provide detailed reports and summary views to multiple users based on their roles. 28. A Reference Section in the tool must be provided for posting, updating and disseminating plans, procedures, checklists and other related information.

29. Provide User-defined forms as well as Standard Incident Command Forms for incident management.

238

33. Should provide historical reports, event data & activity log. The reports can be exported to pdf or html formats. 34. Should provide dashboard filtering capabilities that enable end-users to dynamically filter the data in their dashboard based upon criteria, such as region, dates, product, brands, etc. and capability to drill down to the details

35. Integration Should provide integration of the Incident Management application with Social with the social media. Should Provide analytics based on the social Media & media feed collected from the open source intelligence and collate with Open the surveillance inputs to alert the responders for immediate action on Source the ground. 36. Intelligence Should extract messages and display it in an operational dashboard. 37. Should be able to correlate the extracted message from the social media with existing other events and then should be able to initiate an SOP.

38. Should be able to identify the critical information and should be able to link it to an existing SOP or a new SOP should be started. 39. Should provide notifications to multiple agencies and departments (on mobile) that a new intelligence has been gathered through open source/social media.

40. Device Should provide icon based user interface on the GIS map to report non- Status, functional device. 41. Obstructio Should also provide a single tabular view to list all devices along with n Detection their availability status in real time. and 42. Availability Should provide User Interface to publish messages to multiple devices Notificatio at the same time. n

239

44. Standard Command & Control Center should provide for authoring and invoking Operations un-limited number of configurable and customizable standard Procedures operating procedures through graphical, easy to use tooling interface. (SOP)

45. Standard Operating Procedures should be established, approved sets of actions considered to be the best practices for responding to a situation or carrying out an operation.

46. The users should be able to edit the SOP, including adding, editing, or deleting the activities. 47. The users should be able to also add comments to or stop the SOP (prior to completion). 48. There should be provision for automatically logging the actions, changes, and commentary for the SOP and its activities, so that an electronic record is available for after-action review.

49. The SOP Tool should have capability to define the following activity types: 50. Manual Activity - An activity that is done manually by the owner and provide details in the description field. 51. Automation Activity - An activity that initiates and tracks a particular work order and select a predefined work order from the list. 52. If-Then-Else Activity - A conditional activity that allows branching based on specific criteria. Either enter or select values for Then and Else.

53. Notification Activity - An activity that displays a notification window that contains an email template for the activity owner to complete, and then sends an email notification.

54. SOP Activity - An activity that launches another standard operating procedure. 55. Key Command & Control Center should be able to facilitate measurement Performan or criteria to assay the condition or performance of departmental ce processes & policies. Indicator 56. Green indicates that the status is acceptable, based on the parameters for that KPI, no action is required. 57. Yellow indicates that caution or monitoring is required, action may be required.

240

60. The solution should generate Customized reports based on the area, sensor type or periodic or any other customer reports as per choice of the administrators

61. Collaborati Should provide tools for users to collaborate & communicate in real- on Tools time using instant messaging features. 62. Communic The solution should adhere to the below mentioned communication ation requirements. 63. Requireme Provide the ability to search/locate resources based on name, nts department, role, geography, skill etc. for rapidly assembling a team, across department, divisions and agency boundaries, during emergency

64. Provide the capability to Invite - Using information provided during the location of those individuals or roles, invite them to collaborate and to share valuable information.

65. Provide a single web based dashboard to send notifications to target audiences using multiple communication methods including voice- based notification on PSTN/Cellular, SMS, Voice mail, E- mail and Social Media 66. The solution should provide Dispatch Console integrates with various communication channels. It should provide rich media support for incidents, giving dispatchers the power to consolidate information relating to an incident and instantly share that information among responder teams. It should assess the common operating picture, identify & dispatch mobile resources available nearby the incident location. Augment resources from multiple agencies for coordinated response. 67. Authenticat Use authentication information to authenticate individuals and/or ion assign roles. 68. Instant Provide ability to converse virtually through the exchange of text, messaging audio, and/or video based information in real time with one or more individuals within the emergency management community.

69. Events and Should provide the capability for the events that are produced from a Directives subsystem and are forwarded to the Command & Control Center. control Events could be a single system occurrence or complex events that are correlated from multiple systems. Events could be ad hoc, real-time, or predicted and could range in severity from informational to critical. At the Command & Control Center, the event should be displayed on an operations dashboard and analysed to determine a proper directive.

241

71. What -if The solution should provide the capability to manage the emergencies Analysis and in-turn reducing risks, salvaging resources to minimize damages Tool and recovering the assets that can speed up recovery.

72. To take proactive decisions that help minimize risks and damages, the solution should provide Analytical and Simulation systems as part of the Decision Support System. The solution should help simulate what if scenarios. It should help visualize assets/resources at risk due to the pending/ongoing incident, should render impacted region on a GIS/3D map. The solution should help build the list of assets, their properties, location and their interdependence through an easy to use Graphical User Interface. When in What if Analysis mode the solution should highlight not only the primary asset impacted but also highlight the linked assets which will be impacted. The user should be able to run the What-if Analysis mode for multiple types of emergency events such as Bomb Blast, Weather events, Accidents etc. 73. Resource & The system should provide the software component for the message Route broadcast and notification solution that allows authorized personal Optimizati and/or business processes to send large number of messages to target on audience (select-call or global or activation of pre-programmed list) using multiple communication methods including SMS, Voice (PSTN/Cellular), Email and Social Media.

74. Alert & Provide a single web based dashboard to send notifications to target Mass audiences using multiple communication methods including voice- Notificatio based notification on PSTN/Cellular, SMS, Pager, Voice mail, E-mail and n Social Media Requireme nts

75. Provide function for creating the alert content and disseminating to end users. Provision of alerting external broadcasting organizations like Radio, TV, Cellular, etc., as web-service.

76. Provide Role based security model with Single-Sign-On to allow only authorized users to access and administer the alert and notification system.

242

78. Internet Comprehensive policy-based security administration to provide all Security users specific access based on user's responsibilities. Maintenance of authorization policy in a central repository for administration purposes. 79. Authorizati Should support to enable assignment of permissions to groups, and on administration of access control across multiple applications and resources. Secure, web-based administration tools to manage users, groups, permissions and policies remotely

80. User group Provide policies using separate dimensions of authorization criteria like Traditional static Access Control Lists that describe the principals (users and groups) access to resource and the permissions each of these principals possess.

81. Provide SSO to Web-based applications that can span multiple sites or domains multi- with a range of SSO options. dimensiona l access control 82. Flexible Support LDAP authentication mechanism single sign- on (SSO) 83. Authenticat Should have ability to respond to real-time data with intelligent & ion automated decisions 84. Rule Should provide an environment for designing, developing, and Engine & deploying business rule applications and event applications. 85. Optimizati The ability to deal with change in operational systems is directly on related to the decisions that operators are able to make 86. Should have at-least two complementary decision management strategies: business rules and event rules. 87. Situational  The CCA should be able to combine data from various sources Awareness and present it as different views tailored to different operator’s COP needs. (Common  The CCA should automatically update the information based on Operationa alarms and incidents that are presented to it via the business l Picture) rules engine. The polling and CCA database refresh cycle shall be configurable to match the status of the situation (whether there is an emergency or crisis or just monitoring only).  Common Operational Picture should comprise of a comprehensive view of the incident or a group of related incidents as on a specific date and time which should include but not be limited to the following: o Tasks assignment and their status

243

 The above attributes shall be colour coded.  The system shall allow the tasks to be filtered on the real-time dashboard by agency then by task status. This filtering should allow an operator to filter for all tasks of a particular state or a combination of state; and by the time remaining until (or time elapsed since) the target completion time.  The system should allow multiple individual workstations to select specific agencies of interest on each workstation simultaneously.  The system should allow the GSCDL to display all agencies’ tasks simultaneously as well.  The tasks should be displayed on a real-time timeline. The criticality of tasks should be dynamically changed depending on the performance of the incident response. 89. Timeline  The system should provide a facility to see incidents and and actions (tasks) added to the CCA in a tabular list form as Charting well as GANTT chart format filtered by day, week, month, year or any specific date range. 244

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City o Perimeter ranges o Resource tracks Allow user to zoom in/out on different regions of map graphic 91. Video  Shall view live or recorded video from resizable and movable Display windows  Should have an ability to perform video controls for video systems from workstation  Shall play, fast-forward, rewind, pause, and specify time to play recorded video  Shall take a video still image (snapshot) from live or recorded video  Shall export video for user specified time and duration  Shall have the capability to move PTZ cameras  Shall view Video in Video Matrix  Shall display in 1x1, 2x2, 3x3 and 4x4 window formats  Shall enable operator to specify video windows to be displayed in matrix  Shall enable matrix settings to be saved per user  Shall view either live or recorded video can be displayed in the video matrix window.  Shall enable video snapshot to be taken and saved from any window pane in the matrix view  Shall rotate video in “virtual” video guard tour  Shall rotate through multiple video views based on predefined video camera sequence and duration.  Shall enable the user to pause the rotation of video and resume the video rotation again  Shall enable times between new video to be adjusted  Shall enable both live video and recorded video to be played through the video guard tour.  Shall enable alarms to be generated from any video pane  Shall enable user to only view and control video for which they have been assigned permissions by the administrator  Shall manually create an alarm from the live or recorded video with specified severity and description 92. Alarm  Should have an ability to display alarm condition through Display visual display and audible tone  Should have an ability to simultaneously handle multiple alarms from multiple workstations  Should have an ability to automatically prioritize and display multiple alarms and status conditions according to pre-defined parameters such as alarm type, location, sensor, severity, etc.  Should display the highest priority alarm and associated data / video in the queue as default, regardless of the arrival sequence

246

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City 93. Historical  Should have an ability to view historical alarms details even Alarm after the alarm has been acknowledged or closed. Handling  Should have an ability to sort alarms according to date/time, severity, type, and sensor ID or location. 94. Alarm  Should have an ability to generate a full incident report of the Reporting alarm being generated.  Should have an ability to display report on monitor and print report  Should have details of alarm including  severity, time/date, description and location  Captured video image snapshots  Relevant sensor data such as SCADA sensors  Response instructions  Alarm activities (audit trail)  Should have an ability to export alarm report in various formats including pdf, jpeg, html, txt, and mht formats  Should have an ability to generate an alarm incident package including the full incident report and exported sensor data from the incident in a specific folder location. 95. Alarm  The CCA solution should have the following ability to handle Policies the workflow alarms through graphical user interface. and  Should have an ability to match keywords or text from the Business alarming subsystem’s incident description to raise an alarm using Logic criteria including exact match, exact NOT match, contains match, Administra wildcard match and regularly expression match (such as forced tion door alarm, denied access, door open too long, etc.)  Should have an ability to optionally match alarming subsystem’s incident status, incident severity, and sensor type  Should have an ability to apply any alarm policy to one or more monitoring area(s) or zone(s) without having to reapplying the policy multiple times.  Should have an ability to apply any alarm policy to one or more sensors without having to reapply the policy multiple times.  Should have an ability to assign specific actions for each alarm  Should have an ability to activate or deactivate alarms as required  Should have an ability to create exceptions  Should Create batch-wise rules and process them  Should Check and rectify logical errors and contradictory rules  Should have an ability to schedule execution of rules • Should Suspend or Terminate the application of rule Should archive unused or deactivated rules

5.11.2. Contact Centre:

247

4 Automatic call distribution 5 Automatic identification of incoming number based on landline and mobile number mapping

6 Call recording mapped to incident tickets

7 Customizable agent and supervisor desktop layout 8 Inbound and outbound capability

9 Call control 10 Multisession web chat 11 Email 12 Live data reporting gadgets 13 Phonebook 14 Multiline support 15 Speed dial in IP phones

5.11.3. IP Push to Talk (interpretability Communication Channel)

# Minimum Requirements Bidder Product Compliance(Ye Documentation s/No) Reference 1 Make 2 Model 3 IP Push to Talk Radio: Instant communication to critical first responders via push to talk over IP. This will enable All communication across various business sites.

4 The radio over IP solution must integrate any analog or digital radio system, any to any Push To Talk (PTTT) communications.

248

12 The system shall provide Loop Prevention: As multiple dispatchers patch channels together, there is always the possibility of creating a channel loop that causes audio feedback into the communication path. The system should automatically identify potential audio loops and resolve them before they become an issue

13 The System Server shall provide an audit trail for analysis, critique, and operations management. Detailed activity logging shall allow administrators to determine which user actions were performed and when they were performed

5.11.4. Video Wall Screen 249

# Parameter Minimum Specifications Bidder Product Compliance Documentation (Yes/No) Reference 1. Make

2. Model

3. Seamless Video wall of DLP Cubes. Each cube size to be 70” or more (70”/72” Inches diagonally) with complete configuration of (5 cubes x 2 cubes) with covered base. All cubes have to be of the exactly Configuration same size, configuration and model wise mandatorily. The wall to be installed in curved fashion with all required support system like Controller / stand for DLP Cubes / Interfaces / Connecting cables.

4. 24 X 7 : The Video Walls & Controllers and all support systems should be capable of Operation working in 24 x 7 mode without any deterioration in the performance

5. 1-chip 0.95" Digital Micro Mirror Chip Type Device

6. 1920 x 1200 native ( WUXGA Resolution Display )

7. Light Source LED light source with separate Type LED array for each colour ( RGB) 8. Brightness Minimum 700 Lumens ANSI 9. Brightness ≥ 90 % Uniformity 10. Dynamic 1400000:1 or more Contrast

11. Redundant Cube should be equipped with a Dual Power built in dual redundant power Supply supply

250

12. Hot Swappable The inbuilt power supply should Power Suply be hot swappable 13. Control IP based control to be provided

14. IR remote control should also be Remote provided for quick access 15. Screen to ≤ 0.3 mm Screen Gap 16. Screen should have an anti Screen Support reflective glass backing to prevent bulging

17. Cooling Inside By Means of a heat pipe. No Cube liquid cooling. 18. Cube Depth 740mm or less

19. Maintenance Rear Access

20. Inputs in the DVI-2, HDMI-1, HDbaseT-1, Cube Display port-1 21. Output in Cube DVI - 1

22. Video wall should have cube control & monitoring system which can provide video wall status including source, light source, temperature, fan & Cube control & power information. The system Monitoring should be based on web-browser architecture. Should be able to provide an error message in three sections: a) Problem area b) Error Module Location c) Error Module Image

5.11.5. Video Wall Controller

# Parameter Minimum Specifications Bidder Product Compliance Documentation (Yes/No) Reference 1. Make

2. Model

251

3. Controller to control Video Walls in a matrix of 5 x 2 with 16 DVI Display outputs (for future expansion) , 4 controller Universal inputs & DUAL LAN INPUTS along with necessary software’s 4. Single Quad Core Intel® Processor Xeon/i7 64-bit 2.0 GHz CPU or better 5. RAM 8GB

6. 500 GB Hard Disk

HDD Hard disk Capacity should be upgradable

7. * RAID 0 configured with usable RAID space of 500 GB in each controller

8. * Dual-port Gigabit Ethernet Controller inbuilt

* Support for Add on Network Networking adapters

* Support for Optical Fiber interface Adapters 9. DVD-R,DVD+RW,, Keyboard, Accessories mouse 10. * Supports 64-bit Operating OS Systems Windows 7 11. (1 + 1) Redundant AC-DC high- efficiency power supply w/ PFC Power Supply * AC Voltage 100 - 240V, 50- 60Hz

12. * 19” industrial Rack mount movable Chassis Front Panel should have lockable Door to Protect Drives

13. * Operating Temperature range : 10° to 35°C (50° to 95°F) System Reliability * Non-operating Temperature range : -40° to 70°C (-40° to 158°F)

252

* Operating Relative Humidity rnge : 8% to 90% (non- condensing) * Humidity: 10 – 90% non- condensing * Non-operating Relative Humidity: 5 to 95% (non- condensing) 14. Wall 16 DVI-D Outputs configuration 15. 1920x1200 per output minimum Resolution ( WUXGA ) 16. 8 Universal Inputs ( Should be Universal able to accept at least 4 kinds of Inputs signals i.e. DVI/RGB/Component Video ) along with USB 3.0 17. System Should have the redundancy support for Redundancy Controller HDD, power supply & Support LAN ( Gigabit Ethernet RJ-45 connection ) 18. Connectivity between the controller & Video wall should Connectivity be on Optical Fiber cables only. 19. Video Wall, Controller, Cube & Wall management software should be from same OEM for ensuring smooth operations and Video Wall, seamless integration and feature Controller, enablement and enhancement. Cube & wall All licenses of the software management supplied with Controller and Video Wall should be with perpetual license and cost of the same should be included in the quoted cost. 20. Two controllers should be provided which can act as Controller backup to each other i.e. a single configuration controller should be able to drive all the cubes of both the video walls. 21. Video Wall should be mounted Video Wall on stand with minimum height of stand 750 mm ( two and half feet ) with flexibility of 50 mm height 22. Comprehensive onsite warranty Warranty on the DLP video wall and Controller for 5 years

253

# Parameter Minimum Bidder Product Specifications Compliance Documentation (Yes/No) Reference 1 Make 2 Model 3 Display & Display multiple Scaling sources anywhere on display up to any size 4 Input All input sources can Management be displayed on the video wall in freely resizable and movable windows 5 Scenarios Save and Load management desktop layouts from Local or remote machines 6 Layout Support all Manage Layout from ment Input Sources, Internet Explorer, Desktop and Remote Desktop Application 7 Multi Multiple view View of portions or Option regions of Desktop, Multiple Application Can view from single desktop 8 Other SMTP support 9 features Remote Control over LAN

254

5.11.7. Monitoring Workstations

# Parameter Minimum Bidder Compliance Product Specifications (Yes/No) Documentation Reference 1. Make 2. Model 3. Processor Latest generation 64bit X86 Quad core processor(3Ghz) or better 4. Chipset Latest series 64bit Chipset 5. Motherboard OEM Motherboard 6. RAM Minimum 8 GB DDR3 ECC Memory @ 1600 Mhz. Slots should be free for future upgrade. Minimum 4 DIMM slots, supporting up to 32GB ECC

255

7. Graphics card Minimum Graphics card with 2 GB video memory (non- shared) 8. HDD 1 TB SATA-3 Hard drive @7200 rpm with Flash Cache of 64GB SSD 9. Media Drive NO CD / DVD Drive 10. Network interface 10/100/1000 Mbps autosensing on board integrated RJ-45 Ethernet port. 11. Audio Line/Mic IN, Line- out/Spr Out (3.5 mm) 12. Ports Minimum 6 USB ports (out of that 2 in front) 13. Keyboard 104 keys minimum OEM keyboard 14. Mouse 2 button optical scroll mouse (USB) 15. PTZ joystick  PTZ speed dome controller control for IP (with 2 of the cameras workstations in  Minimum 10 SCOC) programmable buttons  Multi-camera operations  Compatible with all the camera models offered in the solution  Compatible with VMS /Monitoring software offered 16. Monitor Three Monitors of 22” TFT LED monitor, Minimum 1920 x

256

5.11.8. LED Display 257

# Parameter Minimum Bidder Compliance Product Specifications (Yes/No) Documentation Reference 1. Make 2. Model 3. Technology HD LED Display , Direct LED Backlight 4. Screen Size 55 inch diagonal or better for viewing centers 5. Resolution Full high definition (Min 1920 x 1080) 16:9 Widescreen 6. Contrast ratio 5000:1 7. Brightness 350 nit 8. Viewing angle 178 degree/178 degree (H/V) 9. Response time 8ms 10. Control - RS232 control - On Screen Display (OSD) - IR remote control 11. Operations 24x7 12. Additional Should be at least UL / Specifications FCC, BIS, BEE/Energy Star certified

5.11.9. IP Phones

# Parameter Minimum Bidder Compliance Product Specifications (Yes/No) Documentation Reference 1 Make 2 Model 3 Display 2 line or more, Monochrome display for viewing features like messages, directory 258

8 POE IEEE 802.3af or better and AC Power Adpater (Option) 9 Supported SNMP, DHCP, DNS Protocols 10 Codecs G.711, G.722, G.729 including handset and speakerphone 11 Speaker Full duplex speaker Phone phone with echo cancellation Speaker on/off button, microphone mute 12 Volume Easy decibel level control adjustment for speaker phone, handset and ringer 13 Phonebook/ Minimum 100 Address book contacts 14 Call Logs Access to missed, received, and placed calls. (Minimum 20 overall) 15 Clock Time and Date on display 16 Ringer Selectable Ringer tone

17 Directory LDAP standard Access directory

259

5.11.10. Network Color Laser printer

# Parameter Minimum Bidder Compliance Product Specifications (Yes/No) Documentation Reference 1. Make 2. Model 3. Print Speed Black : 16 ppm or above on A3, 24 ppm or above on A4 Color : 8 ppm or above on A3, 12 ppm or above on A4 4. Resolution 600 X 600 DPI 5. Memory 8 MB or more 6. Paper Size A3, A4, Legal, Letter, Executive, custom sizes 7. Paper Capacity 250 sheets or above on standard input tray, 100 Sheet or above on Output Tray 8. Duty Cycle 25,000 sheets or better per month 9. OS Support Linux, Windows 2000, Vista, 7, 8, 8.1 10. Interface Ethernet Interface

5.11.11. IP PBX (Call Control System)

260

13. The protection of signaling connections over IP by means of authentication, Integrity and encryption should be carried out using TLS 14. System should support MLPP feature

261

5.11.12. Contact Centre Specifications Automatic Call Distribution (ACD): 1) Should be highly available with hot standby and seamless failover in case of main server failure. There should not be any downtime of Contact Center in case of single server failure. 2) Should support skill based routing and it should be possible to put all the agents in to a single skill group and different skill groups 3) ACD support routing of incoming calls based upon caller input to menus, real-time queue statistics, time of day, day of week, ANI, dialed number etc. 4) ACD should support call routing based on longest available agent, circular agent selection algorithms. 5) ACD should support the playing of customizable queuing announcements based upon the skill group that the call is being queued to, including announcements related to position in queue and expected delay. 6) Agents should be able to chat with other Agents or supervisor from the Agent desktop software 7) Supervisor should be able to see the real-time status of agents, supervisors should be able to make agent ready or logout from the supervisor desktop 8) Should support Queuing of calls and playing different prompts depending on the type of call and time in the queue. 9) In future if required, the ACD should support active and standby server mode, where the server can be put in DC and DR. In case of Main server in the Data center fail the standby server in DR should take over seamlessly. ACD solution should support placing of Main and Stand by server in DC and DR respectively.

262

1) IVR should play welcome messages to callers Prompts to press and collect DTMF digits 2) IVR should be able to integrate with backend database for self-service, as and when required. 3) GUI based tool to be provided for designing the IVR and ACD call flow. 4) IVR should support VoiceXML for ASR, TTS, and DTMF call flows 5) IVR should be able to Read data from HTTP and XML Pages 6) IVR should be able to run outbound campaigns.

Reporting: 1) System to provide report of IVR Application Performance Analysis, Call by Call details for all the calls, Traffic analysis reports etc 2) Reporting platform to support Agent level reports, Agent login, logout report, report on agent state changes 3) Queue reports, Abandon call reports all the reports should be summary, tabular and detailed report format to be available for the agents. 4) Reporting platform to support custom reports using a combination of the Crystal Reports Developer's Toolkit and SQL stored procedures. 5) Users of the Historical Reports should be able to perform the following functions View, print, and save reports. Sort and filter reports, Send scheduled reports to a file or to a printer. Export reports in a variety of formats, including PDF, RTF, XML, and CSV.

E-mail: 6) Administrator should be able to assign one or more email addresses to a single Queue. 7) Email routing support integration with Microsoft Exchange 2003 or Microsoft Exchange 2007 or 2010. 8) Agents should be able to automatically resume of e-mail processing on voice disconnect. 9) Agent should be able to save email draft response and resume at a later time. 10) Agent should be able to re-queue email. 11) Supervisor should be able to access real-time reporting for Agent E-Mail mail volume by Queue

5.11.13. Video Conferencing Unit 1) Video Standards: H.263, H.264 2) Should support 30 fps & 60fps (frames per second) with 1080p resolution from day one

263

5.11.14. Multiparty Conference Unit (Video and Audio Conferencing Bridge with Secure VC over Internet) 1) The Bridging should be running on the standard Intel servers on standard Virtualized platforms. The hardware, software and virtualization software should be supplied and supported by a single bidder. 2) From day one the bridge must provide 6 full HD video ports @1080p 30 fps and 30 audio conference ports. 3) All necessary hardware to support the above capacity needs to be supplied from day one. Bridge must have a redundant power supply.

264

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City 4) All the 10 ports must be able to connect different sites at different bandwidths and protocols. H.264 AVC standard must be supported at the minimum to connect all the 10 sites. 5) The bridge should support room based video end points, users joining from browsers’ supporting WebRTC and HTML5 and its own clients. In case additional components are required for this functionality, all additional components required to have this functionality has to be included in the solution 6) The bridge should have the capability to host meetings with internal and external participants in a secure way such that it should co-exist with the enterprise security policies 7) The bridge should have components such as the Web Server for Web RTC, Scheduler as part of the offering from day one. 8) Should support H.263, H.263+, H.263++, H.264, WebRTC video algorithms 9) Should support video resolution from SD to Full HD to join into a conference 10) Along with the Support for basic algorithms like G.711 and G.722.1 the bridge should also support wideband Audio protocols like MPEG 4 AAC - LC / MPEG 4 AAC – LD 11) Must support the ability to allow Video conferencing devices, Clients on Mobile phones, Smart phones and Laptops to join into conference. These clients can be inside the WAN network or even on the Internet without a VPN. 12) The bridge should support transcoding of different Audio/video Protocols. 13) The bridge should have H.239/BFCP protocol for sending and receiving dual video streams (Presenter + Presentation). 14) The bridge must also support advanced continuous presence such that the site that is "on- air" to be seen on a larger window and the other sites are seen in smaller quadrants 15) The bridge must be a secure Non-PC Hardware with a strong operating system. The Hardware and software must be from the same OEM. 16) The bridge should support 128 Bit strong AES encryption for calls and H.235/SHA1 for authentication 17) It should be possible for outside agencies (for state government, central government, police department, etc.) to join the bridge for multi-party video conference call securely over internet. 18) They should be able to join the bridge using standards based VC endpoints using internet (as long as these endpoints are exposed to internet) securely. 19) It should be possible to connect 5 such external endpoints / locations concurrently at any given point of time. 20) It should use secure firewall traversal technology.

265

5.11.15. Online UPS

# Parameter Minimum Bidder Compliance Product Specifications (Yes/No) Documentation Reference 1. Make 2. Model 3. Capacity Adequate capacity to cover all above IT Components at respective location 4. Output Wave Form Pure Sine wave 5. Input Power Factor >0.90 at Full Load 6. Input Three Phase 3 Wire for over 5 KVA 7. Input Voltage Range 305-475VAC at Full Load 8. Input Frequency 50Hz +/- 3 Hz 9. Output Voltage 400V AC, Three Phase for over 5 KVA UPS 10. Output Frequency 50Hz+/- 0.5% (Free running); +/- 3% (Sync. Mode) 11. Inverter efficiency >90% 12. Over All AC-AC >85% Efficiency 13. UPS shutdown UPS should shutdown with an alarm and 266

267

# Parameter Minimum Bidder Compliance Product Specifications or (Yes/No) Documentation better Reference 1. Make 2. Model 3. Video Compression H.264 4. Video Resolution 1920 X 1080 5. Frame rate Min. 25 fps 6. Image Sensor 1/3” Progressive Scan CCD / CMOS 7. Lens Type Varifocal, IR Correction Full HD lens compatible to camera imager 8. Lens# Auto IRIS 2.8-10mm 9. Multiple Streams Dual streaming with 2nd stream at minimum 720P at 30fps at H.264 individually configurable 10. Minimum Colour: 0.1 lux, Illumination B/W: 0.01 lux (at 30 IRE) 11. IR Cut Filter Automatically Removable IR-cut filter 12. Day/Night Mode Colour, Mono, Auto 13. S/N Ratio ≥ 50 dB 14. Auto adjustment + Colour, brightness, Remote Control of sharpness, Image settings contrast, white balance, exposure control, backlight

268

269

5.12. Non-IT Requirements & Specifications The selected bidder should adhere to the specifications given below for Non-IT components. It is essential that Fire Proof material be used as far as possible and Certification from Fire Department be taken for Command Centres before Go-Live. 5.12.1. Civil and Architectural Work # Description Bidder Compliance (Yes/No)

A. False Ceiling (at Command Centers)

1 Providing and fixing metal false ceiling with powder coated 0.5mm thick hot dipped galvanised steel tiles 595 x 595 mm with regular edge (10mm) suitable for 25mm grid supported on suitable powder coated galvanised steel grid as per manufacturer specification. The same shall be inclusive of cut outs for lighting, AC grills, Fire detectors, nozzles, etc.

2 Providing and fixing 12 mm thick fire line Gypsum false ceiling and lighting troughs 300 mm as per design including 100 mm high cornices as lighting pelmets on G.I. frame work, in G.I. vertical supports at every 450mm c/c and horizontal runners at every 900mm c/c self-taping metal screws to proper line and level. The same shall be inclusive of making holes and required

270

B. Furniture and Fixture

1 Workstation size of min. 18” depth made with 1.5mm thick laminate of standard make over 18mm thick commercial board complete with wooden beading including cutting holes & fixing of cable manager etc. complete with French polish. Edges shall be factory post-formed. The desk shall have the necessary drawers, keyboard trays, cabinets etc. along with sliding / opening as per approved design with quality drawer slides, hinges, locks etc.

2 Providing & making of storage unit with 18 mm thick MDF board along with 1.5 mm approved laminate colour outside and 2 coat of enamel paint inside the storage of size 1'6"x1'6"x2'4". The same should be provided with all the required accessories including the handle, lock, sliding channel and necessary hardware, etc. complete with French polish

3 Cabin table of min. depth 2’ made with 1.5mm thick laminate of standard make over 19mm thick commercial board complete with wooden beading including cutting holes & fixing of cable manager etc. complete with French polish.

4 Providing, making & fixing 6" high laminated strip using 1.5mm thick laminate over 10mm thick commercial board on all vertical surface in the entire server & ancillary areas including low height partition, brick wall, partition wall, cladding etc. complete with French polish in all respect.

5 Providing, making & fixing an enclosure for gas cylinder of Shutters and Partitions along with wooden support and 18 mm thick MDF board along with 1.5 mm approved laminate colour outside and 2 coat of enamel paint inside the shutter. The same should be provided with all the required accessories including the handle, lock, loaded hinges, tower bolt and necessary hardware etc. complete with French polish.

C. Partitions (wherever required as per approved drawing)

1 Providing and fixing in position full height partition wall of 125 mm thick fire line gyp-board partition using 12.5 mm thick double fire line gyp-board on both sides with GI steel metal vertical stud frame of size 75 mm fixed in the floor and ceiling channels of 75 mm wide to provide a strong partition. Glass 271

2 With glazing including the framework of 4" x 2" powder coated aluminium section complete (in areas like partition between server room & other auxiliary areas).

3 Providing & fixing Fire Rated Wire Glass minimum 6 mm thick for all glazing in the partition wall complete. (External windows not included in this).

4 All doors should be minimum 1200 mm (4 ft.) wide.

D. Flooring (wherever required as per approved drawing)

1 The MSI shall procure and install a raised floor to match the floor height and room aesthetic in accordance with the approved final layout and design. The MSI shall consider standard parameters for developing the final height, width, point of load, and uniform distribution load of the raised floor for the rooms based on type of furniture and overall load.

2 The MSI shall ensure the following features and parameters are considered while designing and commissioning the raised floor:

1. Point of Load (PoL) shall be considered 20% more than the actual load 2. Uniform Distribution Load shall be calculated according to the final Point of Load 3. Noise-proof 4. Fireproof 5. Maintenance window for easy access to under the raised floor 6. Separate electrical and data cable tray under the raised floor 7. Face of floor tiles shall conform to the aesthetic part of the approved design 3 The MSI shall perform load test and noise test of the constructed raised floor.

272

1. Floor shall be designed for standard load conforming to BIS 875-1987. 2. Panels shall be made up of 18-gauge steel of 600 mm × 600 mm size treated for corrosion and coated with epoxy conductive paint (minimum thickness 50 Micron). 3. Raised flooring covering shall be antistatic, high- pressure laminate, two (2) mm thick in approved shade and color with PVC trim edge. It shall not make any noise while walking on it or moving equipment. Load and stress tests on floor panels shall be performed as part of acceptance testing. E. Painting

1 Providing and applying Fire retardant paint of pre-approved make and shade to give an even shade over a primer coat as per manufacturers’ recommendations after applying painting putty to level and plumb and finishing with 2 coats of fire retardant paint. Base coating shall be as per manufacturer’s recommendation for coverage of paint.

2 For all vertical Plain surface.

3 For fire line gyp-board ceiling.

4 Providing and laying POP punning over cement plaster in perfect line and level with thickness of 10 - 12 mm including making good chases, grooves, edge banding, scaffolding pockets etc.

5 Applying approved fire retardant coating on all vertical surfaces, furniture etc. as per manufacturer's specification.

5.12.2. PVC Conduit # Description Bidder Compliance (Yes/No)

1. The conduits for all systems shall be high impact rigid PVC heavy-duty type and shall comply with I.E.E regulations for non- metallic conduit 1.6 mm thick as per IS 9537/1983.

2. All sections of conduit and relevant boxes shall be properly cleaned and glued using appropriate epoxy resin glue and the proper connecting pieces, like conduit fittings such as Mild Steel

273

3. No conduit less than 20mm external diameter shall be used. Conduit runs shall be so arranged that the cables connected to separate main circuits shall be enclosed in separate conduits, and that all lead and return wire of each circuit shall be run to the same circuit.

4. All conduits shall be smooth in bore, true in size and all ends where conduits are cut shall be carefully made true and all

sharp edges trimmed. All joints between lengths of conduit or between conduit and fittings boxes shall be pushed firmly together and glued properly.

5. Cables shall not be drawn into conduits until the conduit system is erected, firmly fixed and cleaned out. Not more than two right angle bends or the equivalent shall be permitted between draw and junction boxes. Bending radius shall comply with I.E.E regulations for PVC pipes.

6. Conduit concealed in the ceiling slab shall run parallel to walls and beams and conduit concealed in the walls shall run vertical or horizontal.

7. The chase in the wall required in the recessed conduit system shall be neatly made and shall be of angle dimensions to permit the conduit to be fixed in the manner desired. Conduit in chase shall be hold by steel hooks of approved design of 60cm center the chases shall be filled up neatly after erection of conduit and brought to the original finish of the wall with cement concrete mixture 1:3:6 using 6mm thick stone aggregate and course sand.

5.12.3. Wiring # Description Bidder Compliance (Yes/No) 1. PVC insulated copper conductor cable shall be used for sub circuit runs from the distribution boards to the points and shall be pulled into conduits. They shall be stranded copper conductors with thermoplastic insulation of 650 / 1100 volts grade. Colour code for wiring shall be followed.

274

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City 2. Looping system of wring shall be used, wires shall not be jointed. No reduction of strands is permitted at terminations. 3. Wherever wiring is run through trunking or raceways, the wires emerging from individual distributions shall be bunched together with cable straps at required regular intervals. Identification ferrules indication the circuit and D.B. number shall be used for sub main, sub circuit wiring the ferrules shall be provided at both end of each sub main and sub-circuit. 4. Where, single phase circuits are supplied from a three phase and a neutral distribution board, no conduit shall contain wiring fed from more than one phase in any one room in the premises, where all or part of the electrical load consists of lights, fans and/or other single phase current consuming devices, all shall be connected to the same phase of the supply. 5. Circuits fed from distinct sources of supply or from different distribution boards or M.C.B.s shall not be bunched in one conduit. In large areas and other situations where the load is divided between two or three phases, no two single-phase switches connected to difference phase shall be mounted within two meters of each other. 6. All splicing shall be done by means of terminal blocks or connectors and no twisting connection between conductors shall be allowed. 7. Metal clad sockets shall be of die cast non-corroding zinc alloy and deeply recessed contact tubes. Visible scraping type earth terminal shall be provided. Socket shall have push on protective cap. 8. All power sockets shall be piano type with associate’s switch of same capacity. Switch and socket shall be enclosed in a M. S. sheet steel enclosure with the operating knob projecting. Entire assembly shall be suitable for wall mounting with Bakelite be connected on the live wire and neutrals of each circuit shall be continuous everywhere having no fuse or switch installed in the line excepting at the main panels and boards. Each power plug shall be connected to each separate and individual circuit unless specified otherwise. The power wiring shall be kept separate and distinct from lighting and fan wiring. Switch and socket for light and power shall be separate units and not combined one. 9. Balancing of circuits in three phases installed shall be arranged before installation is taken up. Unless otherwise specified not more than ten light points shall be grouped on one circuit and the load per circuit shall not exceed 1000 watts. 275

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City 5.12.4. Cable Work # Description Bidder Compliance (Yes/No) 1. Cable ducts should be of such dimension that the cables laid in it do not touch one another. If found necessary the cable shall be fixed with clamps on the walls of the duct. Cables shall be laid on the walls/on the trays as required using suitable clamping/ fixing arrangement as required. Cables shall be neatly arranged on the trays in such manner that a criss- crossing is avoided and final take off to switch gear is easily facilitated. Cable shall be laid as per the IS standard 2. All cables will be identified close to their termination point by cable number as per circuit schedule. Cable numbers will be punched on 2mm thick aluminium strips and securely fastened to the. In case of control cables all covers shall be identified by their wire numbers by means of PVC ferrules. For trip circuit identification additional red ferrules are to be used only in the switch gear / control panels, cables shall be supported so as to prevent appreciable sagging. In general distance between supports shall not be greater than 600mm for horizontal run and 750mm for vertical run. 3. Each section of the rising mains shall be provided with suitable wall straps so that same the can be mounted on the wall. 4. Whenever the rising mains pass through the floor they shall be provided with a built-in fire proof barrier so that this barrier restricts the spread of fire through the rising mains from one section to the other adjacent section. Neoprene rubber gaskets shall be provided between the covers and channel to satisfy the operating conditions imposed by temperature weathering, durability etc. 5. Necessary earthling arrangement shall be made alongside the rising mains enclosure by Mean of a GI strip of adequate size bolted to each section and shall be earthed at both ends. The rising mains enclosure shall be bolted type. 6. The space between data and power cabling should be as per standards and there should not be any criss-cross wiring of the two, in order to avoid any interference, or corruption of data. 5.12.5. Earthing All electrical components are to be earthen by connecting two earth tapes from the frame of the component ring and will be connected via several earth electrodes. The cable arm will be earthen through the cable glands. Earthling shall be in conformity with provision of rules 32, 61, 62, 67 & 68 of Indian Electricity rules 1956 and as per IS-3043. The entire applicable IT infrastructure in the Control Rooms shall be earthed. 276

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City # Description Bidder Compliance (Yes/No) 1. Earthing should be done for the entire power system and provisioning should be there to earth UPS systems, Power distribution units, and AC units etc. so as to avoid a ground differential. State shall provide the necessary space required to prepare the earthing pits. 2. All metallic objects on the premises that are likely to be energized by electric currents should be effectively grounded. 3. The connection to the earth or the electrode system should have sufficient low resistance in the range of 0 to 25 ohm to ensure prompt operation of respective protective devices in event of a ground fault, to provide the required safety from an electric shock to personnel & protect the equipment from voltage gradients which are likely to damage the equipment. 4. Recommended levels for equipment grounding conductors should have very low impedance level less than 0.25 ohm. 5. In case of a UPS and Transformer equipment, the Earth resistance shall be automatically measured on an online basis at a pre-configured interval and corrective action should be initiated based on the observation. The automatic Earthing measurements should be available on the UPS panel itself 6. There should be enough space between data and power cabling and there should not be any cross wiring of the two, in order to avoid any interference, or corruption of data. 7. The earth connections shall be properly made. 8. A complete copper mesh earthing grid needs to be installed for the server farm area, every rack need to be connected to this earthing grid. A separate earthing pit needs to be in place for this copper mesh. 9. Provide separate earthing pits for servers, UPS & generators as per the standards. 5.12.6. Fire Detection and Control Mechanism Fire can have disastrous consequences and affect operations of a Control Room. It is required that there is early-detection of fire for effective functioning of the Control Room. # Description Bidder Compliance (Yes/No) A. System Description 1 The Fire alarm system shall be an automatic 1 ton (e.g. 8) zone single loop addressable fire detection and alarm system, utilizing conventional detection and alarm sounders.

277

278

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City 4 Devices shall be compatible with the CIE conforming to the requirements of EN54 Part 5 and be LPCB approved. 5 The detectors shall have a single LED to indicate the device has operated and shall fit a common addressable base. E. Addressable detector bases 1 All bases shall be compatible with the type of detector heads fitted and the control system component used. Each base shall comprise all necessary electronics including a short circuit isolator. 2 The device shall be automatically addressed by the CIE on power up of the loop without the need of the insertion of a pre- programmed EPROM or setting of DIL switches. 3 Detector bases shall fit onto an industry standard conduit box. F. Audible Alarms 1 Electronic sounders shall be coloured red with adjustable sound outputs and at least 3 sound signals. The sounders should be suitable for operation with a 24V DC supply providing a sound output of at least 100dBA at 1 meter and 75 dBA min, for a bed head or sounder base type device. The sounder frequency shall be in the range of 500Hz to 1000Hz. G. Commissioning 1 The fire detection and alarm system will be programmable and configurable via an alpha numeric keypad on the control panel. 5.12.7. Access Control System The Access Control System shall be deployed with the objective of allowing entry and exit to and from the premises to authorized personnel only. The system deployed shall be based on Biometric Technology. An access control system consisting of a central PC, intelligent controllers, power supplies and all associated accessories is required to make a fully operational on line access control system. Access control shall be provided for doors. These doors shall be provided with electric locks, and shall operate on fail-safe principle. The lock shall remain unlocked in the event of a fire alarm or in the event of a power failure. The fire alarm supplier shall make potential free contacts available for releasing the locks in a fire condition especially for staircase and main doors. Entry to the restricted area shall be by showing a proximity card near the reader and exit shall be using a push button installed in the secure area. The system shall monitor the status of the doors through magnetic reed contacts. The system should be designed and implemented to provide following functionality: # Description Bidder Compliance (Yes/No) 1 Controlled Entries to defined access points 2 Controlled exits from defined access points 3 Controlled entries and exits for visitors 4 Configurable system for user defined access policy for each access point 279

280

6.1.3. Design Phase The MSI shall build the solution as per the Design Considerations detailed in Annexure – IV. The solution proposed by MSI should comply with the design considerations requirements as mentioned therein.

6.1.4. Development Phase The MSI shall carefully consider the scope of work and provide a solution that best meets the project’s requirements. Considering the scope set in this RFP, the MSI shall carefully consider the solutions it proposes and explicitly mention the same in the technical proposal. The 282

1) Smart LED Street a) The ICCC should aggregate various data feeds from light Lights sensors and systems further process information out of these data feeds to provide interface /dashboards for generating alert and notifications in real time. b) Provide single dashboard of various brand of lighting solution. c) ICCC should support lighting control like diming, switch on/off, group control etc. d) ICCC should provide reports of various brand of lighting solution. e) Integration with GIS map

284

285

4) GIS Based Property a) The Property Tax module should be integrated into ICCC Tax b) ICCC uses an ESB or IoT API Adapter for consuming the web services from Property Tax application c) ICCC Integration Engine stores auth and other historic data for generating reports d) ICCC initially makes call to get the authentication tokens for calling web services e) ICCC makes calls to get the required data from Urban Local Bodies (ULB) viz., City Corporation, City Municipal Council, Town Municipal etc., f) ICCC expects the following services viz., Property Details per Location, g) ICCC displays the analytical information of property tax collections across the in a GIS map I. All the below services can be integrated into ICCC II. Create New Property III. Get Property details IV. Get Property Bill V. Make Payment VI. Get Receipt h) Following reports can be displayed on ICCC, if required I. Demand / Collection Register II. Assessment Register III. Ward-wise / Zone-wise Recovery reports IV. Top Defaulters Report V. Occupancy wise / Flat wise report' VI. Tax-wise Recovery Details VII. Tax-wise Demand Details VIII. Advance Payment Reports IX. Objection / Hearing Details i) Integration with GIS map

286

7) Environmental a) Monitor key inputs from city environmental sensors like Monitoring (sensor Temperature, Humidity, CO, CO2, NO2, SO2, PM10, PM2.5, based) b) Create awareness within the city based on dynamic inputs received from sensors and display output to various interfaces including city application, multi-services c) Integration with GIS map

287

9) Smart a) Integrate the portal for displaying birth and death data via Governance(ERP) APIs Birth & Death b) Integrate with master data and other modules for Module, Assets information validity Managemen, Vanue c) MIS Reports on Birth/Death information per Booking etc.. location/age/gender etc. viz., - Online Birth Certificates printed today - Online Death Certificates printed today - Total Birth Certificates printed - Total Death Certificates printed - Birth Registrations – Today - Birth Registrations – Total - Death Registrations – Today - Death Registrations – Total - Re-print requests per day/month - Verification requests per day/month - Pending Certificates issuance - Location/Hospital wise birth/death registrations - Age group wise death registrations - Gender wise birth/death registrations d) Analytics on Population vs Birth/Death e) KPI’s on birth and death certificate issuance by location per location f) Integration with GIS map

288

2 HRMS a) The HRMS should be integrated into ICCC 8 b) ICCC uses an ESB or IoT API Adapter for consuming the ) webservices from HRML application c) ICCC Integration Engine stores auth and other historic data for generating reports d) ICCC initially makes call to get the authentication tokens for calling web services e) ICCC should integrate the MIS details of Payroll, Employee Wise Pay Summary, Department/Section wise, PF/CPF

# Function Use Case Stakeholder for Use Case 1. Traffic View ambient condition at a given ATCS traffic signal. Police The view would include: Overall 360 degree view, edge view of 180 degree and specific lane views. 2. Traffic View ambient condition at a ATCS corridor. The view Police would include: specific arm of carriage way across multiple signals in a corridor. 3. Traffic View cycle times for signals (where adaptive traffic GSCDL / GMC control has been implemented) across all junctions in the city with a facility to drill down. 4. Traffic View ambient volume count across all ATCS junctions in GSCDL / GMC the city with a facility to drill down volume count on each arm. 289

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City 5. Traffic Track movement of a flagged vehicle (with number Police tagged as Wanted”, “Suspicious”, “Stolen” ) across the city on map with relevant video feeds 6. Traffic View the eChallans generated across a region, with a Police facility to drill down. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 7. Traffic View the list of repeat violators. The view should allow Police the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 8. Traffic View the vehicle volumes across ATCS traffic signals. Police The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 9. Traffic View traffic violation count super imposed on the map. Police The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 10. Traffic View traffic volume count super imposed on the map. GSCDL / GMC The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 11. Safety View camera feeds across the city with cameras on a Police sample basis appearing across the video wall. The view should have provision to auto select new set of cameras after pre configured time. 12. Safety View all camera feeds in vicinity of selected camera Police based on geographical selection of the area. The geographical selection can be in terms of a polygon or could be linear. 13. Safety View and playback recording from past (based on Police availability in storage) of a specific camera or cameras defined in a geography. 14. Safety Identify unattended objects, baggage, vehicle in a given Police camera feed with help of analytics 15. Safety View network of cameras on the map, including Police incidents detected and resolved. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 16. Safety Auto identify a specific camera and show the feed based Police on data / threshold from traffic/ display/ sensor subsystems. 17. Connectivity View consumption patterns of data across Wi-Fi access GSCDL / GMC points 18. Connectivity View list of URLs accessed from a public IP based on a GSCDL / GMC given time frame and IP address

290

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City 19. Connectivity View the coverage and usage patterns superimposed on GSCDL / GMC the city map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 20. Connectivity View connectivity status of all field devices/sensors GSCDL / GMC superimposed on the city map. 21. Connectivity View the bandwidth utilization of all field devices GSCDL / GMC superimposed on the city map. 22. Display View the messages displayed at the Variable Messaging GSCDL / GMC Sign Board (display boards) in a specific area of the city. The geographical selection can be in terms of a polygon or could be linear. 23. Display View all the messages displayed on a given Variable GSCDL / GMC Messaging Sign Board (display boards). The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 24. Display Change the message to be displayed on a specific GSCDL / GMC display board, display board in an area or across the city. 25. Display View the advertisements displayed at the display board GSCDL / GMC (Bill Board) on iPoles in a specific area of the city. The geographical selection can be in terms of a polygon or could be linear. 26. Display View all the advertisements displayed on a given iPole GSCDL / GMC Display board (Bill board). The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 27. Sensor View NOX levels across the city, view threshold GSCDL / GMC breaches, and view data superimposed on a map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 28. Sensor View SO2 levels across the city, view threshold GSCDL / GMC breaches, and view data superimposed on a map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 29. Sensor View CO2 levels across the city, view threshold GSCDL / GMC breaches, and view data superimposed on a map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 30. Sensor View O2 levels across the city, view threshold breaches, GSCDL / GMC and view data superimposed on a map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available.

291

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City 31. Sensor View noise levels across the city, view threshold GSCDL / GMC breaches, and view data superimposed on a map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 32. Sensor View ambient light levels across the city, view threshold GSCDL / GMC breaches, and view data superimposed on a map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 33. Sensor View humidity light levels across the city, view GSCDL / GMC threshold breaches, and view data superimposed on a map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 34. Sensor View UV light levels across the city, view threshold GSCDL / GMC breaches, and view data superimposed on a map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 35. Transit View the feeds received from GPS Devices from Public GSCDL / GMC Transport buses) on the city map. 36. Civic View the aggregate transactions performed at a given GSCDL / GMC Center/Ward civic center on the city map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 37. Civic Center/ View the rating of civic centers based on collections, GSCDL / GMC Ward services offered and staff availability on the city map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 38. Civic Center / View the feeds received from ERP system on the city GSCDL / GMC Ward map. 39. Property Tax View the tax collected on the city map. The view should GSCDL / GMC allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 40. Property Tax View the tax to be collected and shortfall (from tax GSCDL / GMC value) on the city map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 41. Property Tax View turnaround times for collection of property tax on GSCDL / GMC the city map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 42. Property Tax View the feeds received from ERP system on the city GSCDL / GMC map.

292

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City 43. Birth View normal births registered on the city map. The GSCDL / GMC Registration view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 44. Birth View abnormal births on the city map. The view should GSCDL / GMC Registration allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 45. Birth View turnaround times for issuance of certificate on the GSCDL / GMC Registration city map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 46. Birth View the feeds received from ERP system on the city GSCDL / GMC Registration map. 47. Death View deaths registered on the city map. The view GSCDL / GMC Registration should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 48. Death View turnaround times for issuance of certificate on the GSCDL / GMC Registration city map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 49. Death View the feeds received from ERP system on the city GSCDL / GMC Registration map. 50. License View the licenses (unique view for each license type) GSCDL / GMC expired (not renewed) on the city map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 51. License View the licenses (unique view for each license type) GSCDL / GMC issued on the city map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 52. License View the license turnaround times (unique view for GSCDL / GMC each license type) issued licenses on the city map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 53. License View the feeds received from ERP system on the city GSCDL / GMC map. 54. Building View the building permissions (unique view for each GSCDL / GMC Permission license type) issued on the city map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available.

293

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City 55. Building View the building permission turnaround times (unique GSCDL / GMC Permission view for each license type) issued licenses on the city map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 56. Building View the demand required (water, waste, sewerage, GSCDL / GMC Permission etc.) as a result of building permissions given in the city on the city map. 57. Building View the feeds received from ERP system on the city GSCDL / GMC Permission map. 58. Water View water related grievances on the city map. The GSCDL / GMC view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 59. Water View the distribution network status on the city map. GSCDL / GMC 60. Water View the distribution volumes on the city map. GSCDL / GMC 61. Water View the feeds received from SCADA system on the city GSCDL / GMC map. 62. Water View the underground utility network on the map. GSCDL / GMC 63. Accounts View the spending pattern across the budget heads GSCDL / GMC with a facility to drill down. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 64. Accounts View area wise budget spent across the city on a city GSCDL / GMC map. 65. Accounts View the feeds received from ERP system on the city GSCDL / GMC map. 66. Solid Waste View waste related grievances on the city map. The GSCDL / GMC view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 67. Solid Waste View movement of Garbage pick up vehicles on the city GSCDL / GMC map. 68. Solid Waste View the feeds received from ERP system on the city GSCDL / GMC map. 69. Solid Waste View the feeds received from Solid Waste Management GSCDL / GMC system on the city map. 70. Welfare View the benefits issued (unique view for each benefit) GSCDL / GMC Schemes issued on the city map. The view should allow the facility to change the time scale from 1 hr. to 1 year, with daily, weekly, monthly, quarterly and yearly views available. 71. Welfare View the feeds received from ERP system on the city GSCDL / GMC Schemes map. 72. Project Systems View the project status (physical completion and GSCDL / GMC financial completion) for each ongoing project in the city. 294

6.1.6. Go-Live Preparedness and Go-Live a. MSI shall prepare and agree with GSCDL, the detailed plan for Go-Live (in-line with GSCDL’s implementation plan as mentioned in RFP). b. The MSI shall define and agree with GSCDL, the criteria for Go-Live. c. The MSI shall ensure that all the data migration is done from existing systems. d. MSI shall submit signed-off UAT report (issue closure report) ensuring all issues raised during UAT are being resolved prior to Go-Live. e. MSI shall ensure that Go –Live criteria as mentioned in User acceptance testing of Project is met and MSI needs to take approval from GSCDL team on the same. f. Go-live of the application shall be done as per the finalized and agreed upon Go-Live plan.

6.1.7. Operations and Maintenance Success of the Project would lie on how professionally and methodically the entire Project is managed once the implementation is completed. From the MSI perspective too this is a critical phase since the quarterly payments are linked to the SLA’s in the post implementation phases. MSI thus is required to

295

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City depute a dedicated team of professionals to manage the Project and ensure adherence to the required SLAs. MSI shall provide operations and maintenance services for the software, hardware and other IT and Non-IT infrastructure installed as part of the project after Phase wise Go-Live and for the 5 years after implementation or phase wise Go-Live Warranty period of the product supplied under project i.e hardware, software, IT/Non-IT etc., will be considered after phase wise Go-Live. The scope of work for the Operations & Maintenance Phase can be categorized under 8 service categories. 6.1.7.1. Project Management & Facilities Management Services The MSI will be required to provide facilities management services to support the GSCDL and Police Department officials in performing their day-to-day functions related to this system. MSI is required to depute a dedicated, centralised project management and technical team for the overall project management and interaction with GSCDL and Police Department. 6.1.7.2. Provision of the Operational Manpower to view the feeds at Command Center The MSI is required to provide suitable manpower to monitor the data feeds at command center and support GSCDL, Traffic Police Department and any other smart solutions in operationalisation of the project. The exact role of these personnel and their responsibilities would be defined and monitored by GSCDL and respective departmental personnel. MSI shall be required to provide such manpower meeting following requirements: 1. All such manpower shall be minimum graduate pass 2. All such manpower shall be without any criminal background / record. 3. GSCDL reserves the right to carry out background check of the personnel proposed on the Project for verification of criminal record, at the beginning of deployment or during deployment. 4. MSI shall have to replace any person, if not found suitable for the job. 5. All the manpower shall have to undergo training from the MSI for at least 15 working days on the working of project. Training should also cover dos & don’ts and will have few sessions from GSCDL and Traffic Police Department officers on right approaches for monitoring the feeds & providing feedback to GSCDL, Traffic Police Personnel and other associated government agencies. 6. Each person shall have to undergo compulsory 1 day training every month 7. Operational Manpower shall work in 3 shifts, with no person being made to see the feeds for more than 8 hours at a stretch. Detail operational guideline document shall be prepared during implementation which shall specify detail responsibilities of these resources and their do’s & don’ts. The Current estimation of the man-power required from the MSI for viewing of the data feeds is as follows:

# Description Quantity

296

The supervisors required for operationalization of the project will be provided by GSCDL, as per requirements. 6.1.7.3. Basic Infrastructure Services Following services shall be provided by the MSI under the basic infrastructure services: 1. Ensure availability of the infrastructure (both physical and IT) including but not limited to Power, Cooling, Racks, Storage and other peripheral equipment installed at the time of Project commissioning as per the SLAs. 2. Ensure scalability in terms of availability of racks and supporting infrastructure. 3. Proactive and reactive maintenance, repair and replacement of defective components (physical and other peripheral IT infrastructure) installed for the Project through this RFP. The cost for repair and replacement shall be borne by the MSI. 4. Any component (Physical & IT installed at the time of Project commissioning) that is reported to be faulty / non-functional on a given date should be either fully repaired or replaced by temporary substitute (of equivalent configuration) within the time frame agreed upon in the Service Level Agreement (SLA). 5. Proactive monitoring of the entire basic infrastructure installed. 6. MSI shall maintain records of the maintenance of the basic infrastructure and shall maintain a logbook on-site that may be inspected by the GSCDL and Traffic Police at any time. 6.1.7.4. Network Monitoring Services The activities shall include: 1. MSI shall provide services for management of Gandhinagar Project to maintain performance at optimum levels on a 24 x 7 basis. 2. MSI shall monitor and administer the network. 3. MSI shall create and modify VLAN, assignment of ports to appropriate applications and segmentation of traffic. 4. MSI shall carry out break fix maintenance of the LAN cabling or maintenance work requiring civil work. 6.1.7.5. Integration Testing This shall be a black-box testing role primarily to ensure that the application to be deployed does not disrupt the Gandhinagar operations and affect other Gandhinagar infrastructure in terms of performance and security. The technical tasks to be carried out shall be as follows:

297

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City 1. Functional Testing: Ensuring that the application functionality as described by the GSCDL and Traffic Police works adequately. The functional testing of application will necessarily be minimal as this is a core responsibility of the Supplier. 2. Performance Testing: Ensuring that the application meets expressed performance requirements on the Gandhinagar servers by using performance test tools and performance monitoring tools. 3. Security Testing: Testing for exploitable application security weaknesses that undermine the application security or the security of the infrastructure. 6.1.7.6. Vendor Management Services The activities shall include: 1. Coordination with all the project stakeholders to ensure that all Gandhinagar activities are carried out in a timely manner. 2. MSI shall coordinate and follow-up with all the relevant vendors to ensure that the issues are resolved in accordance with the SLAs agreed upon with them. 3. MSI shall also ensure that unresolved issues are escalated to respective departments. 4. MSI shall maintain database of the various vendors with details like contact person, telephone nos., escalation matrix, response time and resolution time commitments etc. 5. MSI shall draw a consolidated quarterly SLA performance report across vendors for consideration of the GSCDL and Traffic Police. 6.1.7.7. Network Management The objective of this service is to ensure continuous operation and upkeep of the Network infrastructure of the project including all active and passive components. The selected MSI shall be responsible to coordinate with Network Service Provider for network related issues between ICCC, DC, DR and other sub systems. The services to be provided for Network Management include: 1. Ensuring that the network is available 24x7x365 as per the prescribed SLAs for the initial 5 year of operations 2. Attending to and resolving network failures and snags. 3. Support and maintain the overall network infrastructure including but not limited to LAN passive components, routers, switches etc. 4. Configuration and backup of network devices including documentation of all configurations. 5. 24x7x365 monitoring of the network to spot the problems immediately. 6. Provide information on performance of Ethernet segments, including capacity utilization and error statistics for the segment and the top-contributing hosts, WAN links and routers.

298

6.1.8. Exit Management a. This sets out the provisions, which will apply on expiry or termination of the Master Service Agreement, the Project Implementation, Operation and Management SLA. b. In the case of termination of the Project Implementation and/or Operation and Management, the Parties shall agree at that time whether, and if so during what period, the provisions of this Schedule shall apply. c. The Parties shall ensure that their respective associated entities carry out their respective obligations set out in this Exit Management Schedule.

6.1.8.1. Cooperation and Provision of Information During the exit management period: a. The MSI will allow the GSCDL or its nominated agency access to information reasonably required to define the then current mode of operation associated with the provision of the services to enable the GSCDL to assess the existing services being delivered; 299

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City b. Promptly on reasonable request by the GSCDL, the MSI shall provide access to and copies of all information held or controlled by them which they have prepared or maintained in accordance with this agreement relating to any material aspect of the services (whether provided by the MSI or sub-contractors appointed by the MSI). The GSCDL shall be entitled to copy of all such information. Such information shall include details pertaining to the services rendered and other performance data. The MSI shall permit the GSCDL or its nominated agencies to have reasonable access to its employees and facilities, to understand the methods of delivery of the services employed by the MSI and to assist appropriate knowledge transfer. 6.1.8.2. Confidential Information, Security and Data a. The MSI will promptly on the commencement of the exit management period supply to the GSCDL or its nominated agency the following:  information relating to the current services rendered and customer and performance data relating to the performance of sub-contractors in relation to the services;  documentation relating to Intellectual Property Rights;  documentation relating to sub-contractors;  all current and updated data as is reasonably required for purposes of GSCDL or its nominated agencies transitioning the services to its Replacement MSI in a readily available format nominated by the GSCDL, its nominated agency;  all other information (including but not limited to documents, records and agreements) relating to the services reasonably necessary to enable GSCDL or its nominated agencies, or its Replacement MSI to carry out due diligence in order to transition the provision of the Services to GSCDL or its nominated agencies, or its Replacement MSI (as the case may be). b. Before the expiry of the exit management period, the MSI shall deliver to the GSCDL or its nominated agency all new or up-dated materials from the categories set out in Schedule above and shall not retain any copies thereof, except that the MSI shall be permitted to retain one copy of such materials for archival purposes only. 6.1.8.3. Transfer of Certain Agreements On request by the GSCDL or its nominated agency the MSI shall effect such assignments, transfers, licences and sub-licences GSCDL, or its Replacement MSI in relation to any equipment lease, maintenance or service provision agreement between MSI and third party lessors, vendors, and which are related to the services and reasonably necessary for the carrying out of replacement services by the GSCDL or its nominated agency or its Replacement MSI. 6.1.8.4. General Obligations of the MSI a. The MSI shall provide all such information as may reasonably be necessary to effect as seamless a handover as practicable in the circumstances to the GSCDL or its nominated

300

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City agency or its Replacement MSI and which the MSI has in its possession or control at any time during the exit management period. b. For the purposes of this Schedule, anything in the possession or control of any MSI, associated entity, or sub-contractor is deemed to be in the possession or control of the MSI. c. The MSI shall commit adequate resources to comply with its obligations under this Exit Management Schedule. 6.1.8.5. Exit Management Plan a. The MSI shall provide the GSCDL or its nominated agency with a recommended exit management plan ("Exit Management Plan") which shall deal with at least the following aspects of exit management in relation to the MSA as a whole and in relation to the Project Implementation, and the Operation and Management SLA.  A detailed program of the transfer process that could be used in conjunction with a Replacement MSI including details of the means to be used to ensure continuing provision of the services throughout the transfer process or until the cessation of the services and of the management structure to be used during the transfer;  plans for the communication with such of the MSI's sub-contractors, staff, suppliers, customers and any related third party as are necessary to avoid any material detrimental impact on the GSCDL’s operations as a result of undertaking the transfer;  (if applicable) proposed arrangements for the segregation of the MSI's networks from the networks employed by GSCDL and identification of specific security tasks necessary at termination;  Plans for provision of contingent support to GSCDL, and Replacement MSI for a reasonable period after transfer. b. The MSI shall re-draft the Exit Management Plan annually thereafter to ensure that it is kept relevant and up to date. c. Each Exit Management Plan shall be presented by the MSI to and approved by the GSCDL or its nominated agencies. d. The terms of payment as stated in the Terms of Payment Schedule include the costs of the MSI complying with its obligations under this Schedule. e. In the event of termination or expiry of MSA, and Project Implementation, each Party shall comply with the Exit Management Plan. f. During the exit management period, the MSI shall use its best efforts to deliver the services. g. Payments during the Exit Management period shall be made in accordance with the Terms of Payment Schedule. h. This Exit Management plan shall be furnished in writing to the GSCDL or its nominated agencies within 90 days from the Effective Date of this Agreement.

301

Sl. Component/Application/System Prescribed Standard No. 1. Information Security ISO 27001

2. IT Infrastructure Management ITIL specifications

3. Service Management ISO 20000 specifications

4. Project Documentation IEEE/ISO/CMMi (where applicable) specifications for documentation Cloud Data Centre TIA 942/ Uptime Institute certifications

c. Apart from the above the MSI need to ensure compliance of the project with Government of India IT security guidelines including provisions of:  The Information Technology Act, 2000” and amendments thereof and  Guidelines and advisories for information security published by Cert-In/DeitY (Government of India) issued till the date of publishing of tender notice. Periodic changes in these guidelines during project duration need to be complied with. d. While writing the source code for application modules the MSI should ensure high-quality documentation standards to improve the readability of the software module. An illustrative list of comments that each module contained within the source file should be preceded by is outlined below:  The name of the module  The date when module was created  A description of what the module does  A list of the calling arguments, their types, and brief explanations of what they do  A list of required files and/or database tables needed by the module  Error codes/Exceptions  Operating System (OS) specific assumptions

302

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City ix. Any other issues that either party wishes to add to the agenda. During the development and implementation phase, there may be a need for more frequent meetings and the agenda would also include: i. Module development status ii. Testing results iii. IT infrastructure procurement and deployment status iv. Status of setting up/procuring of the Helpdesk, DC hosting v. Any other issues that either party wishes to add to the agenda. Bidder shall recommend PMO structure for the project implementation phase and operations and maintenance phase. 6.1.10.2. Helpdesk and Facilities Management Services The MSI shall be required to establish the helpdesk and provide facilities management services to support the GSCDL and stakeholder department officials in performing their day- to-day functions related to this system. The MSI shall setup a central helpdesk dedicated (i.e. on premise) for the Project, which shall be supported by individual smart city command centres, implemented and proposed to be setup under Bhopal Smart City Programme. This helpdesk would be operational upon implementation of the Project. Providing helpdesk/support services from a shared facility of any other party/provider is not permitted. Functional requirements of the helpdesk management system, fully integrated with the enterprise monitoring and network management system. The system will be accessed by the stakeholder department officials for raising their incidents and logging calls for support. The detailed service levels and response time, which the MSI is required to maintain for provisioning of the FMS services are described in the Service Level Agreement of this Tender. MSI shall deploy Manpower during implementation and O&M phases. The deployed resource shall report to GSCDL’s Project In-charge for Smart City Project and work closely with Program Management Office of the project. Following are the minimum resources required to be deployed in the Project, however MSI may deploy additional resources based on the need of the Project and to meet the defined SLAs in this RFP: # Type of Resource Minimum Minimum Deployment during Operation and Quantity Maintenance phase 1. Project Manager 1 100% (8*5) 2. Solution Architect 1 Onsite Support to Project team on need basis 3. Software 1 100% (24*7) Application Expert 4. Network & 1 100% (24*7) Security –

304

10. Command Center 10 100% (24*7 –2 in each shift) Operators

Note: Numbers provided for staff providing 24*7 support is excluding relievers.

6.1.10.3. Steering Committee The Steering Committee will consist of senior stakeholders from GSCDL, its nominated agencies and MSI. MSI will nominate its Smart City vertical head to be a part of the Project Steering Committee The MSI shall participate in monthly Steering Committee meetings and update Steering Committee on Project progress, Risk parameters (if any), Resource deployment and plan, immediate tasks, and any obstacles in project. The Steering committee meeting will be a forum for seeking and getting approval for project decisions on major changes etc. All relevant records of proceedings of Steering Committee should be maintained, updated, tracked and shared with the Steering Committee and Project Management Office by MSI. During the development and implementation phase of the project, it is expected that there will be at least fortnightly Steering Committee meetings. During the O&M phase, the meetings will be held at least once a quarter. Other than the planned meetings, in exceptional cases, GSCDL may call for a Steering Committee meeting with prior notice to the MSI. 6.1.10.4. Project Monitoring and Reporting The MSI shall circulate written progress reports at agreed intervals to GSCDL and other stakeholders. Project status report shall include Progress against the Project Management Plan, status of all risks and issues, exceptions and issues along with recommended resolution etc. Other than the planned meetings, in exceptional cases, project status meeting may be called with prior notice to the Bidder. GSCDL reserves the right to ask the bidder for the project review reports other than the standard weekly review reports. 6.1.10.5. Risk and Issue management 305

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City The MSI shall develop a Risk Management Plan and shall identify, analyse and evaluate the project risks, and shall develop cost effective strategies and action plans to mitigate those risks. The MSI shall carry out a Risk Assessment and document the Risk profile of GSCDL based on the risk appetite and shall prepare and share the GSCDL Enterprise Risk Register. The MSI shall develop an issues management procedure to identify, track, and resolve all issues confronting the project. The risk management plan and issue management procedure shall be done in consultation with GSCDL. The MSI shall monitor, report, and update the project risk profile. The risks should be discussed with GSCDL and a mitigation plan be identified during the project review/status meetings. The Risk and Issue management should form an agenda for the Project Steering Committee meetings as and when required. 6.1.10.6. Governance procedures MSI shall document the agreed structures in a procedures manual. 6.1.10.7. Planning and Scheduling The MSI will prepare a detailed schedule and plan for the entire project covering all tasks and sub tasks required for successful execution of the project. The MSI has to get the plan approved from GSCDL at the start of the project and it should be updated every week to ensure tracking of the progress of the project. The project plan should include the following: 1. The project break up into logical phases and sub-phases; 2. Activities making up the sub-phases and phases; 3. Components in each phase with milestones; 4. The milestone dates are decided by GSCDL in this RFP. MSI cannot change any of the milestone completion dates. MSI can only propose the internal task deadlines while keeping the overall end dates the same. MSI may suggest improvement in project dates without changing the end dates of each activity. 5. Key milestones and deliverables along with their dates including those related to delivery and installation of hardware and software; 6. Start date and end date for each activity; 7. The dependencies among activities; 8. Resources to be assigned to each activity; 9. Dependency on GSCDL 6.1.10.8. License Metering / Management

306

6.1.11. Change Management & Control 6.1.11.1. Change Orders / Alterations / Variations a. The MSI agrees that the requirements given in the Bidding Documents are minimum requirements and are only indicative. The vendor would need to etch out the details at the time of preparing the design document prior to actual implementation. It shall be the responsibility of the MSI to meet all the requirements of technical specifications contained in the RFP and any upward revisions and/or additions of quantities, specifications sizes given in the Bidding Documents required to be made during execution of the works, shall not constitute a change order and shall be carried out without a change order and shall be carried out without any time and cost effect to Purchaser. b. Further upward revisions and or additions required to make MSI’s selected equipment and installation procedures to meet Bidding Documents requirements expressed and to make entire facilities safe, operable and as per specified codes and standards shall not constitute a change order and shall be carried out without any time and cost effect to Purchaser. c. Any upward revision and/or additions consequent to errors, omissions, ambiguities, discrepancies in the Bidding Documents which the MSI had not brought out to the Purchaser’s notice in his bid shall not constitute a change order and such upward revisions and/or addition shall be carried out by MSI without any time and cost effect to Purchaser.

6.1.11.2. Change Order a. The Change Order will be initiated only in case (i) the Purchaser directs in writing the MSI to include any addition to the scope of work covered under this Contract or delete any part of the scope of the work under the Contract, (ii) MSI requests to delete any part of the work which will not adversely affect the operational capabilities of the facilities and if the deletions proposed are agreed to by the Purchaser and for which cost and time benefits shall be passed on to the Purchaser, (iii) the Purchaser directs in writing the MSI to incorporate changes or additions to the technical specifications already covered in the Contract. b. Any changes required by the Purchaser over and above the minimum requirements given in the specifications and drawings etc. included in the Bidding Documents before giving its approval to detailed design or Engineering requirements for complying with technical specifications and changes required to ensure systems compatibility and reliability for safe operation (As per codes, standards and recommended practices referred in the

307

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City Bidding Documents) and trouble free operation shall not be construed to be change in the Scope of work under the Contract. c. Any change order as stated in Clause 2 a. comprising an alteration which involves change in the cost of the works (which sort of alteration is hereinafter called a “Variation”) shall be the Subject of an amendment to the Contract by way of an increase or decrease in the schedule of Contract Prices and adjustment of the implementation schedule if any. d. If parties agree that the Contract does not contain applicable rates or that the said rates are inappropriate or the said rates are not precisely applicable to the variation in question, then the parties shall negotiate a revision of the Contract Price which shall represent the change in cost of the works caused by the Variations. Any change order shall be duly approved by the Purchaser in writing. e. Within ten (10) working days of receiving the comments from the Purchaser or the drawings, specification, purchase requisitions and other documents submitted by the MSI for approval, the MSI shall respond in writing, which item(s) of the Comments is/are potential changes(s) in the Scope of work of the RFP document covered in the Contract and shall advise a date by which change order (if applicable) will be submitted to the Purchaser. 6.1.12. Testing and Acceptance Criteria a. MSI shall demonstrate the following mentioned acceptance criteria prior to acceptance of the solution as well as during project operations phase, in respect of scalability and performance etc. The MSI may propose further detailed Acceptance criteria which the GSCDL will review. Once GSCDL provides its approval, the Acceptance criteria can be finalized. In case required, parameters might be revised by GSCDL in mutual agreement with bidder and the revised parameters shall be considered for acceptance criteria. A comprehensive system should be set up that would have the capability to log & track the testing results, upload & maintain the test cases and log & track issues/bugs identified. b. The following table depicts the details for the various kinds of testing envisaged for the project: Type of Testing Responsibility Scope of Work System Testing MSI 1. MSI to perform System testing 2. MSI to prepare test plan and test cases and maintain it. GSCDL may request the MSI to share the test cases and results 3. Should be performed through manual as well as automated methods 4. Automation testing tools to be provided by MSI. GSCDL doesn’t intend to own these tools Integration MSI 1. MSI to perform Integration testing Testing 2. MSI to prepare and share with GSCDL the Integration test plans and test cases

308

309

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City 6. Testing tools if required, to be provided by MSI. GSCDL doesn’t intend to own these tools 7. During O&M phase, penetration testing to be conducted on yearly basis and vulnerability assessment to be conducted on half-yearly basis. GSCDL will also involve third party auditors to perform the audit/review/monitor the security testing carried out by MSI. Cost for such auditors to be paid by GSCDL. User Acceptance  GSCDL or 1. GSCDL / GSCDL appointed third party auditor to Testing of Project GSCDL perform User Acceptance Testing appointed 2. MSI to prepare User Acceptance Testing test cases third party 3. UAT to be carried out in the exact same auditor environment/architecture that would be set up for production 4. MSI should fix bugs and issues raised during UAT and get approval on the fixes from GSCDL / third party auditor before production deployment 5. Changes in the application as an outcome of UAT shall not be considered as Change Request. MSI has to rectify the observations. Note: a. Bidder needs to provide the details of the testing strategy and approach including details of intended tools/environment to be used by MSI for testing in its technical proposal. GSCDL does not intend to own the tools. b. The MSI shall work in a manner to satisfy all the testing requirements and adhere to the testing strategy outlined. The MSI must ensure deployment of necessary resources and tools during the testing phases. The MSI shall perform the testing of the solution based on the approved test plan, document the results and shall fix the bugs found during the testing. It is the responsibility of MSI to ensure that the end product delivered by the MSI meets all the requirements specified in the RFP. The MSI shall take remedial action based on outcome of the tests. c. The MSI shall arrange for environments and tools for testing and for training as envisaged. Post Go-Live; the production environment should not be used for testing and training purpose. If any production data is used for testing, it should be masked and it should be protected. Detailed process in this regard including security requirement should be provided by the MSI in its technical proposal. The process will be finalized with the selected bidder. d. All the Third Party Auditors (TPA) as mentioned above will be appointed and paid by GSCDL directly. All tools/environment required for testing shall be provided by the MSI.

310

6.1.12.1. Factory Testing Success MSI shall have to submit Factory Test Certificate for the below mentioned materials before the actual supply of the items. 1. Cable 2. Pole 3. Signal Aspects Authorized representative from GSCDL will visit the manufacturing plant of the product subject to present in India. Authorized representative will check the testing process. 6.1.12.2. Final Acceptance Testing The final acceptance shall cover 100% of the Gandhinagar Project, after successful testing by the GSCDL and Traffic Police or its PMU; a Final Acceptance Test Certificate (FAT) shall be issued by the GSCDL and Traffic Police to the MSI. Prerequisite for Carrying out FAT activity: 1. Detailed test plan shall be developed by the MSI and approved by GSCDL. This shall be submitted by MSI before FAT activity to be carried out. 2. All documentation related to Gandhinagar Project and relevant acceptance test document (including IT Components, Non IT Components etc.) should be completed & submitted before the final acceptance test to the GSCDL and Traffic Police. 3. The training requirements as mentioned should be completed before the final acceptance test. 4. Successful hosting of Application, NMS and MIS Software. 5. For both IT & Non-IT equipment’s / software manuals / brochures / Data Sheets / CD / DVD / media for all the Gandhinagar Project supplied components. The FAT shall include the following: 1. All hardware and software items must be installed at respective sites as per the specification. 2. Availability of all the defined services shall be verified.

311

312

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City 7. Annexure III: Payment Schedule and Milestones The payment schedule and milestones are divided into three phases: i. Implementation Phase ii. Integration Phase iii. Operations and Maintenance Phase GSCDL shall issue a “Request Order” in writing, indicating the number of units of Hardware and Software to be supplied along with the location (Project Site). The GSCDL shall continue to issue such request until the full quantities of Hardware and Software specified in volume 2 within the variation limits of RFP is exhausted. Upon getting the Request Order, the MSI shall promptly and as soon as possible within the lead time specified in the request order, supply, install and implement specified numbers of hardware and software at stated project site and commissioned the same. GSCDL shall specify the Lead Time in Request Order. The Lead Time of Request Order shall be decided in discussion with the Service Provider before the Request Order is placed. GSCDL’s decision in this regard shall be final but reasonable time shall be provided to the MSI. Delay or non-performance will form the basis for application of Liquidated Damages. Tentative Number of Request Orders and Lead Time as envisaged at this point of time is specified below. Services Approximate Tentative Scope/ Approximate Tentative Lead Time Time for Sizing (Months) Issuance of Request Order Request One week post 16. Command and Control Center 9 months post Order for issue of LOI/ (ICCC) IT hardware issuance of request Phase 1 completion of Site 17. Command and Control Center order (for Survey activity (ICCC) non-IT equipment GSCDL) 18. Command and Control Center (ICCC) – software 19. Command and Control Center Viewing for (ICCC) IT hardware 20. Smart DC on cloud – Hardware 21. Smart DC on cloud – Software 22. Smart Disaster Recovery (DR) on cloud 23. Integration of City Surveillance System 24. Implementation and Integration of Smart Traffic Control System (SVD & RLVD) 25. ITMS (City Bus- Sub- System) 26. Implementation and imtegration of SWM 27. Implementation and Integration of Smart Pole and other smart elements

313

Request Post completion of 5. Integration with GIS (Sub- 3 months post Order 2 site survey activity System) issuance of request and Integration of 6. Integration with Smart order Phase II Healthcare (Sub- System) 7. Integration with e- Learning (Sub- System) 8. Integration with ERP, e- Governance, City app portal and Mobile App Request Post completion of 3 months post Order 3 site survey activity 5. Integration with Sewage issuance of request and Integration of SCADA (Sub- System) order Phase III 6. Integration with Water SCADA (Sub- System) 7. Integration with Knowledge Centre 8. Integration with Smart Parking (Sub System and Sensors Only)

314

315

Milestones Payment Payment Schedule Time Deliverable Milestones for the Schedule

Implementation % Payment of Time Schedule Phase

M1 Project Kickoff Value commensurate to the D NA discovered quote for site survey activity as per commercial format

M2 Request Order 1

M2.1 Request Order 1 – 10% of Request Order 1 Value D + 1 1. Inception Report Site Survey (Capex Cost)post issuance of Month 2. Project Plan work order 3. Risk Management and Mitigation Plan 4. Site Survey report

316

Specification document 3. Requirements Traceability Matrix

4. Final BoQ

M2.3 Request Order 1 – 10% of Request Order 1 Value D+ 4 2. HLD documents (Capex Cost) Months 3. LLD documents Design Phase 4. Application Completion architecture documents.

5. Technical Architecture documents. 6. Network Architecture documents. 7. Logical and physical database design. 8. Data dictionary and data definitions. 9. GUI design (screen design, navigation, etc.). 10. Test Plans 11. Change management Plan

M2.4 Request Order 1- 30% of Request Order 1 D + 7 1. IT and Non IT Value (Capex Cost) Months Infrastructure Power-up (for Installation Report hardware), 2. Completion of UAT Installation, and closure of configuration and observations report Application 3. Training Completion deployment and Go report Live 4. Application deployment and configuration report

M2.3 Request Order 1 – 10% of Request Order 1 Value D + 9 1. Integration Testing Completion of (Capex Cost) Months Report Integration of Smart 2. Go-Live Report Features and Go- Live of Phase I

317

M 2.6 Request Order 1 – 10% of Request Order 1 Value D+12 Three months of (Capex Cost) Months 1. SLA Report successful operation and Maintenance after Project

Acceptance

M3 Request Order 2

M3.1 Request Order 2 – 10% of Request Order 2 Value D + 10 1. Functional Assessment of (Capex Cost) post issuance of Month Requirement Requirement request order 2 Specification document for request order 2

M3.2 Request Order 2 – 70% of Request Order 2 Value D + 13 1Updated System Completion of (Capex Cost) post issuance of Months Requirement Integration Smart request order 2 Specification document Features and Go- 2.Updated Requirements Live (Project Traceability Matrix Acceptance) 3. Test Plan

4. UAT and Integration Testing Report

4. Go-Live Report

M3.3 Request Order 2 – 10% of Request Order 2 Value D +14 1. SOPs Submission of SoP’s (Capex Cost) post issuance of Months request order 2

M3.4 Request Order 2 – 10% of Request Order 2 D + 16 1. SLA Report Three months of Value (Capex Cost) post Months successful issuance of request order 2 operation and Maintenance after Project

Acceptance

M4 Request Order 3

M4.1 Request Order 2 – 10% of Request Order 2 D + 14 1. Functional Assessment of Value (Capex Cost) post Month Requirement Requirement issuance of request order 2 Specification document for request order 2

318

4. UAT and Integration Testing Report

4. Go-Live Report

M4,3 Request Order 2 – 10% of Request Order 2 D+18 1. SOPs Submission of SoP’s Value (Capex Cost) post Months issuance of request order 2

M4.4 Request Order 2 – 10% of Request Order 2 D + 20 order 2 Three months of Value (Capex Cost) post Months successful issuance of request order 2 operation and Maintenance after Project

Acceptance

Note: • All payments to the Systems Integrator shall be made upon submission of invoices along with necessary approval certificates from concerned Authority like GSCDL, GSCDL. • The above payments are subject to meeting of SLA’s failing which the appropriate deductions as mentioned in the SLA document of this RFP. • Payment for Integration with Individual sub system can be released after 3 months of given timeline of each phase in case of the any of the sub systems of that phase is not ready

319

Payment of Operations and maintenance phase will be made on quarterly basis (at completion of each quarter) based on the adherence to SLA, for the amount quoted for each respective year.

320

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City 8. Annexure IV : Smart City-Design Consideration 8.1. Key Design Considerations Key design considerations taken into account are as follows –  Designed for 24x7 online availability of application.  Scalable solution on open protocols  No propriety devices/ applications  API based architecture for Integration with other web applications and Mobile applications The key guiding principles considered for building the integrated solution are the following:  Continuous adoption of rapidly evolving Technology - Technology evolves too fast and Government projects similar to Smart City with its long procurement cycles do not align naturally to adapt to this trend. Also, any changes to existing implementations require contract changes, new RFP (Request for Proposal), etc. Hence the entire system would be built to be open (standards, open API, plug-n-play capabilities), components coupled loosely to allow changes in sub-system level without affecting other parts, architected to work completely within a heterogeneous compute, storage, and multi-vendor environment.  Selection of best solution at best rate as and when required - Large integrated systems of Smart City operations should be designed to get best cost and performance advantages of natural technology curve (constant increase of speed and decrease of cost) and still aligned to open procurement practices of the Government. For this to happen, architecture should be open and vendor neutral, use commodity hardware, and designed for horizontal scale. This allows buying of commodity compute, storage, etc. only when needed at best price.  Distributed Access and Multi-channel service delivery -With high penetration of mobile devices and very large percentage of internet usage using mobile devices, it is imperative that the Smart City applications provide multiple channels of service delivery to its stakeholders. An important consideration is that the access devices and their screen capabilities (including browser variations) are numerous and constantly evolve. Hence, it is imperative to design the system such that the ecosystem of Smart City-integrated mobile apps also evolves.  Security and privacy of data - Security and privacy of data within the integrated Project will be foundational keeping in view of the sensitivity of data and critical nature of the infrastructure envisioned to be built for Smart City operations. Security and privacy of data should be fundamental in design of the system without sacrificing utility of the system. When creating a system of this scale, it is imperative that handling of the sensitivity and criticality of data are not afterthoughts, but designed into the strategy of the system from day one.  Provision of a Sustainable, Scalable Solution- The motive of the technological enhancements to provide a system that would be sustainable for the next few years. The expectation is that the system should sustain at least 5 years from GO-Live. The solution would be done keeping in mind the scalability of the system. The simplified procurement 321

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City processes and ease of compliance is expected to lead to huge growth in contract’s base. Every component of GSCDL system needs to scale horizontally to very large volume of data. The Application Software will have the capability to scale up to tomorrow's requirements like given below:  Managing the entire Property Life Cycle (Data Collaboration between various govt. departmental systems)  Maintaining Information on Citizen Life Cycle (Right from Birth to Marriage, Health, Education, Driving License, Interactions with GSCDL)  API Approach- GSCDL has decided to adopt Open API as the guiding paradigm to achieve the above goals. Though GSCDL system would develop a portal but that would not be the only way for interacting with the GSCDL system as the stakeholders via his choice of third party applications, which will provide all user interfaces and convenience via desktop, mobile, other interfaces, will be able to interact with the GSCDL system. These applications will connect with the GSCDL system via secure GSCDL system APIs. This architectural approach has been taken as the UI based integration through a ubiquitous web portal requires manual interaction and does not fit most consumption scenarios. The following benefits are envisaged from API based integration, o Consumption across technologies and platforms(mobile, tablets, desktops, etc.) based on the individual requirements o Automated upload and download of data o Ability to adapt to changing taxation and other business rules and end user usage models o Integration with customer software (GIS, Accounting systems).  Business Rule Driven Approach-All configurations including policy decisions, business parameters, rules, etc. shall be captured in a central place within the system. The system shall provide facility to the decision makers to add new or edit/delete existing policies or make changes with appropriate permission control and audit trace. Managing these in a central repository ensures only once source of truth is used across many application servers and reduces issues of inconsistent application behaviour. Decoupling of the business parameters/rules/master data from the rest of the solution architecture and making them configurable allows for a great deal of flexibility.  Data Distribution Service-As a future roadmap it is envisaged that the functionalities provided by the GSCDL Project should be available as services that could be offered to other stakeholders on request. Keeping this in mind the system shall be able to provide data on subscription-publication basis. The organization of the information exchange between modules is fundamental to publish-subscribe (PS) systems. The PS model connects anonymous information producers (publishers) with information consumers (subscribers). The overall distributed application (the PS system) is composed of processes. The goal of the DDS architecture is to facilitate efficient distribution of data in a distributed system. 322

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City Participant using DDS can ‘read’ or ‘write’ data efficiently and naturally with a typed interface. Underneath, the DDS middleware will distribute the data so that each reading participant can access the ‘most current’ values. 8.1.1. Guiding Architecture Principle The IT architecture principles defined in this section are the underlying general rules and guidelines that will drive the subsequent development, use and maintenance of architectural standards, frameworks and future state target architecture. GSCDL system will be built on the following core principles: 8.1.1.1. Platform Approach It is critical that a platform based approach is taken for any large scale application development, to ensure adequate focus and resources on issues related to scalability, security and data management. Building an application platform with reusable components or frameworks across the application suite provides a mechanism to abstract all necessary common features into a single layer. Hence the GSCDL system is envisaged as a faceless system with 100% API driven architecture at the core of it. GSCDL portal will be one such application on top of these APIs, rather than being fused into the platform as a monolithic system. Open APIs designed to be used form the core design mechanism to ensure openness, multi-user ecosystem, specific vendor/system independence, and most importantly providing tax payers and other ecosystem players with choice of using innovative applications on various devices (mobile, tablet, etc.) that are built on top of these APIs. 8.1.1.2. Openness Adoption of open API, open standards and wherever prudent open source products are of paramount importance for the system. This will ensure the system to be lightweight, scalable and secure. Openness comes from use of open standards and creating vendor neutral APIs and interfaces for all components. All the APIs will be stateless. Data access must be always through APIs, no application will access data directly from the storage layer or data access layer. For every internal data access also (access between various modules) there will be APIs and no direct access will be there. 8.1.1.3. Data as an enterprise asset Information is a high value asset to be leveraged across the organization to improve performance and decision making. Accurate information would ensure effective decision making and improved performance Effective and careful data management is of high importance and top priority should be placed on ensuring where data resides, that its accuracy can be relied upon, and it can obtained when and where needed. 8.1.1.4. Performance A best of breed solution using the leading technologies of the domain should be proposed in the solution ensuring the highest levels of performance. It will also ensure that the performance of

323

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City various modules should be independent of each other to enhance the overall performance and also in case of disaster, performance of one module should not impact the performance other modules. The solution should be designed in a manner that the following can be achieved:  Modular design to distribute the appropriate system functions on web and app server  Increase in-memory Operations (use static operations)  Reduce number of I/O operations and N/w calls using selective caching  Dedicated schemas for each function making them independent and avoiding delays due to other function accessing the same schema.  Solution should provide measurable and acceptable performance requirements for users, for different connectivity bandwidths.  The solution should provide optimal and high performance Portal Solution satisfying response time for slow Internet connections and different browsers. 8.1.1.5. Scalability The component in the architecture will be capable of being scaled up to more user requests or handling more no. of input resources in various modules. Even inclusion of additional application functionalities can be catered to by upgrading the software editions with minimal effort. The design of the system to consider future proofing the systems for volume handling requirements  The application functions to be divided logically and developed as Modular solution.  The system should be able to scale horizontally & vertically.  Data Volume- Ability to support at least 20 % projected volume growth (year on year ) in content post system implementation & content migration.  Functionality – Ability to extend functionality of the solution without significant impact to the existing functional components and infrastructure.  Loose coupling through layered modular design and messaging - The architecture would promote modular design and layered approach with clear division of responsibility and separation of concerns at the data storage, service and integration layer in order to achieve desired interoperability without any affinity to platforms, programming languages and network technologies. The architecture has to be scalable, maintainable and flexible for modular expansion as more citizen and business services are provided through the Project. Each of the logical layers would be loosely coupled with its adjacent layers  Data partitioning and parallel processing - Project functionality naturally lends itself for massive parallel and distributed system. For linear scaling, it is essential that entire system is architected to work in parallel within and across machines with appropriate data and system partitioning. Choice of appropriate data sources such as RDBMS, Hadoop, NoSQL data stores, distributed file systems; etc. must be made to ensure there is absolutely no “single

324

8.1.1.6. No Vendor lock-in and Replace-ability Specific OEM products may only be used when necessary to achieve scale, performance and reliability. Every such OEM component/service/product/framework/SI pre-existing product or work must be wrapped in a vendor neutral API so that at any time the OEM product can be replaced without affecting rest of the system. In addition, there must be at least 2 independent OEM products available using same standard before it can be used to ensure system is not locked in to single vendor implementation. 8.1.1.7. Security The security services will cover the user profile management, authentication and authorization aspects of security control. This service run across all the layers since service components from different layers will interact with the security components. All public contents should be made available to all users without authentication. The service will authenticate users and allows access to other features of the envisaged application for which the user is entitled to. The system should be designed to provide the appropriate security levels commiserate with the domain of operation. Also the system will ensure data confidentiality and data integrity. The application system should have the following  A secure solution should be provided at the hardware infrastructure level, software level, and access level.  Authentication, Authorization & Access Control: 3 factors (User ID & Password, Biometric, and Digital Signature) security mechanisms should be implemented to enable secure login and authorized access to portal information and services.  Encryption Confidentiality of sensitive information and data of users and portal information should be ensured.  Appropriate mechanisms, protocols, and algorithms necessary to protect sensitive and confirmation data and information both during communication and storage should be implemented.  Data security policies and standards to be developed and adopted across the Smart City departments and systems

325

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City  In order to adequately provide access to secured information, security needs must be identified and developed at the data level. Database design must consider and incorporate data integrity requirements.  Role based access for all the stake holders envisaged to access and use the system  Appropriate authentication mechanism adhering to industry good practice of Password Policies etc.  Ability to adopt other authentication mechanism such as Electronic Signature Certificates  Authorization validity to be ensured for the users providing the Data to the system. Data should be accepted only from the entity authorized  Data should be visible only to the authorized entity  Audit trails and Audit logging mechanism to be built in the system to ensure that user action can be established and can investigated if any can be aided(e.g. Logging of IP Address etc.)  Data alterations etc. through unauthorized channel should be prevented.  Industry good practice for coding of application so as to ensure sustenance to the Application Vulnerability Assessment System must implement various measures to achieve this including mechanisms to ensure security of procurement data, spanning from strong end-to-end encryption of sensitive data, use of strong PKI national standards encryption, use of HSM (Hardware Security Module) appliances, physical security, access control, network security, stringent audit mechanism, 24x7 monitoring, and measures such as data partitioning and data encryption. Activities such as anti-spoofing (no one should be able to masquerade for inappropriate access), anti- sniffing (no one should be able get data and interpret it), anti-tampering (no one should be able to put/change data which was not meant to be put/changed) should be taken care for data in transit, as well as data at rest, from internal and external threats. 8.1.1.8. User Interface The architecture and application solutions to be designed should promote simplicity and ease of use to the end users while still meeting business requirements. It should provide a simpler and more cost- effective solution. Reduces development time and makes the solution easier to maintain when changes in requirements occur. This will be accomplished by the implementation of rich User Interfaces along with its integration with the DMS, Relational Data Store, Messaging and other external applications.  Efficient and layout design are the key considerations that enhance usability which should be factored in while designing the application. Standard and consistent usability criteria must be defined. An intuitive, user friendly, well-articulated navigation method for the applications greatly enhances the usability of the application.  Effective information dissemination

326

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City  Enhanced functionalities including personalized delivery of content, collaboration and enriching GUI features  The load time for all web page user interfaces must satisfy both the following response time targets on 1 mbps connection: o 3 sec for welcome page o 5 sec for static pages o 10 sec for dynamic pages  Ability to perform a simple search within 10 seconds on 1 mbps connectivity and a complex search (combining four terms) within 15 seconds regardless of the storage capacity or number of files and records on the system.  Mobile Application Platform o Applications and services including all appropriate channels such as SMS/USSD/IVRS and development of corresponding mobile applications to the applications and services leveraging the Mobile Service Delivery Gateway (MSDG) and Mobile App Store. o Application platform should support the following smart phone mobile OS (Android 4.0 and above, iOS 4, 5 and above, Windows Phone OS 8.0 and above, Mobile Web App) o Support the target packaging components like (Mobile Website, Hybrid App, Native App, Web App and Application Development, Eclipse tooling platforms) o Support the ability to write code once and deploy on multiple mobile operating systems o Support integration with native device API o Support utilization of all native device features o Support development of applications in a common programing language o Support integration with mobile vendor SDKs for app development and testing o Support HTML5, CSS3, JS features for smartphone devices o Support common protocol adapters for connection to back office systems (i.e. HTTP, HTTPS, SOAP, XML for format) o Support JSON to XML or provide XHTML message transformations o Support multi-lingual and language internalization o Support encrypted messaging between server and client components 8.1.1.9. Reliability This is a very crucial system and data are of high sensitivity, the data transfer and data management should be reliable to keep the confidence of the stakeholders. The system should have appropriate measures to ensure processing reliability for the data received or accessed through the application. It may be necessary to mainly ensure the following

327

328

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City 8.1.1.11. Availability The solution design and deployment architecture will ensure that the application can be deployed in a centralized environment offering system High Availability and failover. The solution should meet the following availability requirements  Load Balanced across two or more Web Server avoiding single point of failure  Deployment of multiple application instances should be possible  Distributed or load balanced implementation of application to ensure that availability of services is not compromised at any failure instance.  Network, DC, DR should be available 99.99 % time. 8.1.1.12. SLA driven solution Data from connected smart devices to be readily available (real-time), aggregated, classified and stored, so as not to delay the business processes of monitoring and decision making, and will enable appropriate timely sharing across the Smart City organization. Readily available and consumed device data will facilitate timely access of analytics reports at every level and department of the Smart City and provide timely analysis of data as well as monitoring of KPIs through SLAs resulting in effective service delivery and improved decision making. 8.1.1.13. Reconstruction of truth System should not allow database/system administrators to make any changes to data. It should ensure that the data and file (data at rest) that is kept in the systems has tamper resistance capacity and source of truth (original data of invoices and final returns) could be used to reconstruct derived data such as ledgers and system generated returns. System should be able to detect any data tampering through matching of hash value and should be able to reconstruct the truth.  Services/solutions should be flexible and extensible to respond to, accommodate and adapt to changing business needs and unanticipated requirements easily. Consolidate and simplify technology applications wherever possible to minimize complexity. Ongoing application, database and server consolidation may be required.  Software should use meta-data to configure itself (using declarations rather than coding).  Avoid proprietary solutions and technologies if possible. Consider adhering to latest industry best practices and technical standards.  The infrastructure should support an environment that allows applications to start small, grow quickly, and operate inexpensively. An adaptable infrastructure provides the capability to add to the current infrastructure with minimum inconvenience to the user.  The IT architecture should be designed to support the overall SLA requirements around scalability, availability and performance.

329

8.1.1.14. Integration Architecture This section recommends the proposed integration architecture aligning with the overarching architectural principles.

The following are the integration specifications for the various integration scenarios -

Real-time integration All the Smart City applications will be deployed in the Data Centre while any external application of the Smart City ecosystem will reside in outside premises. The need for an OPC Unified Architecture (OPC- UA) is felt that will facilitate GSCDL in defining an enterprise integration platform. An OPC platform will help in data exchange across applications in real-time mode (both synchronous and asynchronous), promote loose coupling with ease of maintenance and change, facilitate rapid composition of complex services, achieve scalability through modularity, and improved business visibility. The OPC UA architecture is a service-oriented architecture (SOA) and is based on different logical levels. It is an architectural style that allows the integration of heterogeneous applications & users into flexible service delivery architecture. Discrete business functions contained in enterprise applications could be organized as layers of interoperable, standards-based shared "services" that can be combined, reused, discovered and leveraged by other applications and processes. The following are the various integration modes and techniques that could be leveraged –

 OPC Base Services are abstract method descriptions, which are protocol independent and provide the basis for OPC UA functionality. The transport layer puts these methods into a protocol, which means it serializes/deserializes the data and transmits it over the network. Two protocols are specified for this purpose. One is a binary TCP protocol, optimized for high performance and the second is Web service-oriented

330

 Message based interfacing technique will be leveraged for real-time asynchronous integration mode. The following integration points could be considered for message based interfacing - o Central LDAP with ERP to synchronize member and employee user registration data o Payment solution and ERP to exchange payment data for tracking of beneficiary’s payment transactions against different services (citizen, workers, transporter, vendor), master data (employee, vendor/supplier, location, facilities, price table) o Employee attendance data with ERP (HR Module) to capture data pertaining to employee location and attendance o Departmental applications with ERP (Asset Management module) to exchange data for procurement and maintenance of any assets or infrastructure items for each department. o Municipal operations application with ERP (Material Management module) to capture materials related transaction and inventory data for public works o Other government applications with Smart City application to exchange data for government procurement, public health schemes, welfare schemes, citizen health, etc.

 RESTful API service based interfacing technique will be leveraged for the following integration areas- o Access and use of various services provided by the different departments for citizens and business community will be done through a RESTful, stateless API layer.

331

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City o Access and use of various internal functions related to operations and administration of Smart City for departmental and GSCDL employees will be done through a RESTful, stateless API layer  Data integration in batch mode will be through ETL. The following integration points could be considered for ETL based data integration - o Initial data migration to cleanse, validate and load the data extracted from source systems into target tables o Data load from all the individual transactional systems like ERP, Grievance Redressal to central enterprise data warehouse solution for aggregation, mining, dashboard reporting and analytics. Process Integration layer of the GSCDL solution will automate complex business processes or provide unified access to information that is scattered across many systems. Process Integration will provide a clean separation between the definition of the process in the process model, the execution of the process in the process manager, and the implementation of the individual functions in the applications. This separation will allow the application functions to be reused in many different processes. An enterprise service bus (ESB) is a software architecture model used for designing and implementing the interaction and communication between mutually interacting software applications in Service Oriented Architecture. As software architecture model for distributed computing it is a variant of the more general client server software architecture model and promotes strictly asynchronous message oriented design for communication and interaction between applications. Its primary use is in Enterprise Application Integration of heterogeneous and complex landscapes. Following are the requirement for an ESB system:  The solution should support static/deterministic routing, content-based routing, rules-based routing, and policy-based routing, as applicable in various business cases.  The solution should have capabilities to receive input message in heterogeneous formats from various different systems, interpret those messages, process and transform those messages to generate output and feed them to various different clients as per formats applicable. o The solution should have features to communicate across different services, process them and expose as single aggregate service to facilitate business functionality o ESB should support SOA standards such as XML, XSLT, BPEL, web services standards and messaging standards. o ESB should support all industry standards interfaces for interoperability between different systems There are four integration gateways envisaged as part of the solution design. The key requirements with respect to each of these are mentioned below: SMS Gateway: SMS services are envisaged to be made available as part of the solution design. The service provider may integrate the solution with MSDG, and use the services available through it, or

332

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City deploy its own SMS Gateway services at no extra charge to GSCDL, but it is a mandatory requirement that all the SMS based services (alerts and notifications) should be available as part of the solution. Following are some of the key requirements for the SMS services through the solution:  Should contain required details/information and targeted to the applicant or designated officers of tax departments and other stakeholders and users as per prevailing TRAI norms  Facilitate access through access codes for different types of services  Support automated alerts that allows to set up triggers that will automatically send out reminders  Provide provision for International SMS  Provide provision to receive messages directly from users  Provide provision for personalized priority messages  Resend the SMS in case of failure of the message  Provide messaging templates Email Services: Email services are envisaged to be made available as part of the solution design to send alerts/intimations/automated messages to registered email ids, based on preferences set up/opted by individual users. An authenticated SMTP mail service (also known as a SMTP relay or smart host) is envisaged to be integrated with the solution for sending mail from the solution, and delivered to intended inbox. Support antispam features. Payment Gateway: The solution is envisaged to have integration with payment gateways, to enable authorized Users make financial transactions, as per rights and privileges provided to him/her. The service provider is required to make the provisions for integration with such third party gateways and provide payment services, as per requirement of the GSCDL. Some of the key features of payment gateway are mentioned below:  Should support secure integration with Payment Service Providers  Should support a unified interface to integrate with all Payment Service Providers  Should support integration with Payment Service Providers using web services and over HTTP/S protocol  Should manage messages exchange between UI and payment service providers  Should support beneficiary’s payment transactions tracking against various services  Should support bank accounts reconciliation  Should provide logs for all transactions performed through the Payment Gateway for future financial dispute resolution that might arise between entities and either beneficiaries or Payment Service Providers  Should maintain and keep transactions logs for time period required and specified by the financial regulations followed in country  Should support redundant Payment Discovery 333

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City  Should submit Periodic Reconciliation Report to government entities  Should support transaction reports to monitor and track payments  Should support real-time online credit card authorization for merchants  Should support compliance with emerging trends and multiple payment options such debit card, credit card, cash cards and other payment gateways  Should provide fraud screening features  Should support browser based remote administration  Should support multicurrency processing and settlement directly to merchant account  Should support processing of one-time or recurring transactions using tokenization  Should support real time integration with SMS and emails IVR Services: IVR services are envisaged as part of Call Centre facility, which will be integrated with the solution, to provide information and services to the people who would contact the Call Centre: Some of the key features of the IVR services are mentioned below:  Should provide multi-lingual content support  Should facilitate access through access codes for different types of services  Should support Web Service Integration  Should support Dual Tone Multi Frequency (DTMF) using telephone touchpad - in-band and out- of-band  Should support for Voice Extensible Markup Language (VoiceXML)  Should support speech recognition that interprets spoken words as texts (Advanced Speech Recognition).  Should support playing of pre-recorded sounds  Should support redirection to human assistance, as per defined rules  Should be able to generate Data Records – (CDRs) and have exporting capabilities to other systems  Should provide provision for voice mailbox and voice recognition There are multiple ways of integration of the solution with other systems is envisaged. These may be through Web Services, Message Queuing, File based or API based. The integration and data sharing mechanism may be either in Batch Mode or Needs basis (synchronous or asynchronous). Some of the key requirements of the interface/integration are mentioned below: o Interface Definition o Interface Owner o Interface Type

334

Note: Bidder is free to proposed their own design to be meet the scope and SLA requirement 8.2. Security Data exchange should abide by all laws on privacy and data protection Security Architecture This section recommends the proposed security architecture aligning with the overarching architectural principles. The basic tenets of Smart City security architecture are the design controls that protect confidentiality, integrity and availability of information and services for all the stakeholders. 8.2.1. User Security and Monitoring Authentication & Authorization A strong authentication mechanism should be considered to protect unauthorized access to the Smart City applications. Consider use of at least two of the following forms of authentication mechanism:  Something you know, such as a password, PIN etc  Something you have, such as a smart card, hardware security token etc

335

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City  Something you are, such as a fingerprint, a retinal scan, or other biometric methods Levels of Authentication Based on the security requirements the following levels of authentication should be evaluated.  For applications handling sensitive data it is recommended that in the least one factor authentication key in the form of a password is essential. Strong password complexity rules should be enforced to ensure confidentiality and integrity of the data  For applications handling highly sensitive data it is recommended that two factor authentication mechanisms should be considered. The first line of defence is the password conforming to the password complexity rules'. Along with the password next user has to provide a one-time password which varies for each session. One time passwords are valid for each session and it is not vulnerable to dictionary, phishing, interception and lots of other attacks. A counter synchronized One-Time Password (OTP) solution could be used for this purpose. Authorization Authorization of system users should be enforced by access controls. It is recommended to develop access control lists. Consider the following approach for developing access control list -  Establish groups of users based on similar functions and similar access privilege.  Identify the owner of each group  Establish the degree of access to be provided to each group 8.2.2. Data Security Traditional Structured Enterprise Data GSCDL should protect Integrated Project information against unauthorized access, denial of service, and both intentional and accidental modification. Data security, audit controls and integrity must be ensured across the data life cycle management from creation, accessed, viewed, updated and when deleted (or inactivated). This provides a proactive way to build defences against possible security vulnerabilities and threats, allowing errors to be corrected and system misuse to be minimized. The implications for adhering to an effective data security and integrity guideline related to the Project are the following –  Data security policies and standards to be developed and adopted across GSCDL Smart City applications and stakeholders  Data security controls to be put in place to restrict access to enterprise data based on roles and access privileges. Data audit logs should be maintained for audit trail purposes. Security controls will be able to be reviewed or audited through some qualitative or quantitative means for traceability and to ensure that risk is being maintained at acceptable levels.  In order to adequately provide access to secured information, security needs must be identified and developed at the data level, not the application level. Database design must consider and incorporate data integrity requirements.

336

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City  Procedures for data sharing need to be established. Data integrity during data synchronization needs to be ensured across the enterprise.  Audit Capabilities: The system provides for a system-wide audit control mechanism that works in conjunction with the RDBMS.  Maintaining Date/Time Stamp and User Id: Every transaction, with a date and time and User ID, is captured. The system allows generating various audit reports for verification.  Access Log: The GSCDL Project should have extensive inbuilt security and access control mechanisms. Based on this, the system keeps track of the various functions accessed by any users. Audit Trail & Audit Log Audit trails or audit logs should be maintained. Log information is critical in identifying and tracking threats and compromises to the environment. There are a number of devices and software that should be logged which include hardware & software based firewalls, web servers, authentication servers, central/domain controllers, database servers, mail servers, file servers, routers, DHCP servers etc. It is essential to decide what activities and events should be logged. The events which ideally should be captured include  Create, read, update and delete of confidential information;  User authentication and authorization activities in the system, granting, modification or revoking of user access rights;  Network or service configuration changes;  Application process start up, shutdown or restart, abort, failure or abnormal terminations, failure of network services;  Detection of suspicious activities such as from Intrusion Detection and Prevention system, anti- virus, anti-spyware systems etc. 8.2.3. Application Security  Project must comply with the Application Security Plan and security guidelines of Government of India as applicable  Secure coding guidelines should be followed. Secure coding guidelines should include controls against SQL injection, command injection, input validation, cross site scripting, directory traversal, buffer overflows, resource exhaustion attacks etc. OWASP Top 10 standard should be mapped in the secure coding guidelines to cover all major vulnerabilities.  Validation checks should be incorporated into the application to detect any corruption of information through processing errors or deliberate acts.  Data output from an application should be validated to ensure that the processing of stored information is correct and appropriate to the circumstances

337

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City  Should implement secure error handling practices in the application  Project should have Role based access, encryption of user credentials. Application level security should be provided through leading practices and standards including the following: o Prevent SQL Injection Vulnerabilities for attack on database o Prevent XSS Vulnerabilities to extract user name password (Escape All Untrusted Data in HTML Contexts and Use Positive Input Validation) o Secure Authentication and Session Management control functionality shall be provided through a Centralize Authentication and Session Management Controls and Protect Session IDs from XSS o Prevent Security Misconfiguration Vulnerabilities (Automated scanners shall be used for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc. maintain Audits for updates o Prevent Insecure Cryptographic Storage Vulnerabilities (by encrypt off-site backups, ensure proper key storage and management to protect keys and passwords, using a strong algorithm) o Prevent Failure to Restrict URL Access Vulnerabilities (By providing authentication and authorization for each sensitive page, use role-based authentication and authorization and make authentication and authorization policies configurable o Prevent Insufficient Transport Layer Protection Vulnerabilities (enable SSL for all sensitive pages, set the secure flag on all sensitive cookies and secure backend connections o Prevent Id Redirects and Forwards Vulnerabilities o For effective prevention of SQL injection vulnerabilities, MSI should have monitoring feature of database activity on the network and should have reporting mechanism to restrict or allow the traffic based on defined policies. 8.2.4. Infrastructure Security The following focused initiatives to discover and remedy security vulnerabilities of the IT systems of GSCDL Smart City should be considered to proactively prevent percolation of any threat vectors -  Deploy anti-virus software to all workstations and servers to reduce the likelihood of security threats;  Deploy perimeter security technologies e.g. enterprise firewalls to reduce the likelihood of any security threat;  Deploy web content filtering solutions to prevent threats from compromised websites to help identify and block potentially risky web pages;  Install enterprise-level e-mail anti-security software to reduce vulnerability to phishing and other e-mail security spams. This would check both incoming and outgoing messages to ensure that spam messages are not being transmitted if a system becomes compromised. 338

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City  Perform periodic scanning of the network to identify system level vulnerabilities  Establish processes for viewing logs and alerts which are critical to identify and track threats and compromises to the environment. The granularity and level of logging must be configured to meet the security management requirements.  Deploy technology to actively monitor and manage perimeter and internal information security.  Deploy network Intrusion Detection System (IDS) on the perimeter and key points of the network and host IDS to critical systems. Establish process to tune, update, and monitor IDS information.  In case of cloud deployment, cloud services can be disrupted by DDoS attacks or misconfiguration errors which have the potential to cascade across the cloud and disrupt the network, systems and storage hosting the cloud application.  Deploy security automation techniques like automatic provisioning of firewall policies, privileged accounts, DNS, application identity etc. Network Security for Smart Devices The core principles of security for any smart device network rest on the three most important data security concerns of confidentiality, integrity and authentication. Hence the security for smart device networks should primarily focus on the protection of the data itself and network connections between the nodes. From a network perspective, following are to be considered for designing the smart devices network -  Protection of fair access to communication channels (i.e. media access control)  Concealing of physical location of the nodes  Defence against malicious resource consumption, denial of service, node capturing and node injection  Provision for secure routing to guard the network from the effects of bad nodes  Protection of the mobile code Smart devices have a triple role in most networks - data collectors, processors and traffic forwarders for other devices in the network. The typical attacks for which countermeasures are to be defined and implemented are: Radio Jamming, Nodes Reporting Wrong Data, Data Aggregation Attacks and Battery Attacks. The following guidelines need to be considered for security enhancement of smart devices and their networks:  Use of IP-based network for smart devices  Use of Link Layer Security for password-based access control and encryption  Protection of smart devices nodes behind a firewall for carrying out SSL-based application data transfer and mechanism to avoid distributed DoS attacks

339

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City  Public-key-based authentication of individual devices to the network and provisioning them for secure communications  Conformance of the security solution to the standards of IETF, IEC and IEEE to ensure maximum security and interoperability, with support for the following commonly used protocols at a minimum - IPSec/IKE, SSH and SSL/TLS 8.3. Software Development Lifecycle Continuous Build The Gandhinagar Project should be highly modular and parallel development should be carried out for faster execution using industry’s best Software Development Lifecycle practices. All application modules within the same technology platform should follow a standardized build and deployment process. A dedicated ‘development / customization’ environment should be proposed and setup. The MSI must provision separate development and testing environment for application development and testing. Any change, modifications in any module must follow industry standard processes like change management, version control and release management in large and complex application development environment. Application source code could be maintained in source control and could be broken up into a number of projects. Source control projects are created to abstract related set of modules or feature that can be independently included in another application. It is a mandatory to create, update and maintain all relevant documentation throughout the contract duration. Also it should be ensured that a bug tracking toll is maintained for proper tracking of all bugs fixes as per various tests conducted on the application. 8.4. Quality Assurance A thorough quality check is proposed for the Gandhinagar Project and its modules, as per standard Software Development Life Cycle (SDLC). MSI is expected to lay down a robust Quality Assurance program for testing of the developed application for its functionality, performance and security before putting in production environment. The program must include an overall plan for testing and acceptance of system, in which specific methods and steps should be clearly indicated and approved by GSCDL. MSI is required to incorporate all suggestions / feedback provided after the elaborate testing of the system, within a pre-defined, mutually agreed timeline. MSI must undertake the following:  Outline the methodology that will be used for testing the system.  Define the various levels or types of testing that will be performed for system.  Provide necessary checklist/documentation that will be required for testing the system.  Describe any technique that will be used for testing the system.  Describe how the testing methodology will conform to the requirements of each of the functionalities and expected outcome.

340

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City  Indicate / demonstrate to GSCDL that all applications installed in the system have been tested. 8.4.1. Performance and Load Testing MSI is expected to implement performance and load testing with following features:  Testing workload profiles and test scenarios based on the various functional requirements should be defined. Application as well as system resource utilization parameters that need to be monitored and captured for each run also needs to be defined.  Should support application testing and API testing including HTTP(s), web services, mobile applications and different web 2.0 frameworks such as Ajax/Flex/HTML5.  MSI should perform the load testing of Gandhinagar Project for multiple workload profiles, multiple scenarios, and user loads to handle the envisaged users of the system.  Different activities before load testing i.e. identification of work load profiles, scenarios, information capturing report formats, creation of testing scripts, infrastructure detailing and workload profile should be prepared before the start of actual load testing exercise.  Solution parameters needs to be tuned based on the analysis of the load testing reports. The tuning process could be iterative until the issues are closed. Multiple load runs needs to be executed for users to simulate different scenarios, such as peak load (year end, quarter end, etc.), load generation within the LAN, Load generation across WAN or mobile network simulator while introducing configurable latency/jitter/packet loss etc.  Should eliminate manual data manipulation and enable ease of creating data-driven tests.  Should provide capability to emulate true concurrent transactions.  Should identify root cause of performance issues at application or code level. Include code performance analysis to quickly pinpoint component-level bottlenecks: Slowest classes and methods, most frequently called methods, most costly (aggregate time spent for each method), response time variance etc.  Should allow selection of different network bandwidth such as analog modems, ISDN, DSL, or custom bandwidth.  Should be able to monitor various system components e.g. Server (OS, Web, Application & Database) Monitoring, Network (between Client & Server) Delay Monitoring, Network Devices (Firewall, Switch & Router) Monitoring during the load test without having to install any data capturing agents on the monitored servers/components  Should correlate response times and system performance metrics to provide quick insights in to root cause of performance issues.  Reports on following parameters (but not limited to) such as transaction response time, transaction per second (Passed), user interface rendering time, transaction per second (Failed), web transaction breakdown graphs, hits per second, throughput, HTTP responses per Second, pages downloaded per second, system infrastructure performance metrics etc.

341

342

Request for Proposal (RFP) for Selection of Master System Integrator for Implementation of Intelligent Transport Management System (ITMS), Adaptive Traffic Management System, Solid waste Management, Smart Poles, other smart Elements and Integrated Command and Control Centre (ICCC) in Gandhinagar City 9. Annexure V- Common guidelines regarding compliance of systems/equipment 1. The specifications mentioned for various IT / Non-IT components are indicative requirements and should be treated for benchmarking purpose only. MSIs are required to undertake their own requirement analysis and may propose higher specifications that are better suited to the requirements. 2. In case of addition/update in number of license for the Integrated Command and Control Centre (ICCC) software and VMS licenses for Cameras, the MSI is required to meet of technical specifications contained in the RFP and for the upward revisions and/or additions of licenses is required be made as part of change order and cost would be commensurate to the itemized rate approved at the LOI issuance. 3. Any manufacturer and product name mentioned in the Tender should not be treated as a recommendation of the manufacturer / product. 4. None of the IT / Non-IT equipment’s proposed by the MSI should be End of Life product. It is essential that the technical proposal is accompanied by the OEM certificate in the format given in Volume I of this Tender, where-in the OEM will certify that the product is not end of life product & shall support for at least 6 years from the date of Bid Submission. 5. All IT Components should support IPv4 and IPv6 6. Technical Bid should be accompanied by OEM’s product brochure / datasheet. MSIs should provide complete make, model, part numbers and sub-part numbers for all equipment/software quoted, in the Technical Bid. 7. MSI should ensure that only one make and model is proposed for one component in Technical Bid for example all Traffic Surveillance cameras must belong to a single OEM and must be of the same model etc. 8. MSIs should ensure complete warranty and support for all equipment from OEMs. All the back-to-back service agreements should be submitted along with the Technical Bid. 9. All equipment, parts should be original and new. 10. The user interface of the system should be a user friendly Graphical User Interface (GUI). 11. Critical core components of the system should not have any requirements to have proprietary platforms and should conform to open standards. 12. For custom made modules, industry standards and norms should be adhered to for coding during application development to make debugging and maintenance easier. Object oriented programming methodology must be followed to facilitate sharing, componentizing and multiple-use of standard code. Before hosting the application, it shall be subjected to application security audit (by any of the CERTIN empanelled vendors) to ensure that the application is free from any vulnerability; and approved by the Police Department. 13. All the Clients Machines / Servers shall support static assigned IP addresses or shall obtain IP addresses from a DNS/DHCP server. 343

344

13 City OFC No Yes 14 Digital Signage Boards No Yes 15 Integrated Transport No Yes Management System 16 Smart Poles No Yes e-HealthCare No Yes e-Learning No Yes City App and web Portal No Yes ERP No Yes

345

1 GMC Actplease 2011 None

2 Property Tax 2016 Regular

3 Professional Tax 2016 Regular

4 Birth, Death and 2011 None Marriage Registration

5 Attendance 2015 None

346

12.1. List of Traffic Signals # Junction Name

1. GH0

2. CHO

3. Rakshashakti Circle

4. Sargasan Circle

5. Pathik Ashram

6. CH-3

7. CH-4

8. CH-5

9. GH-4

10. GH-5

12.2. List of locations ATCS S. No. Name of Location RLVD SVD Total Cameras

1. GH0 1 1 5

2. CHO 1 1 5

3. Rakshashakti Circle 1 1 5

4. Sargasan Circle 1 1 5

347

6. CH-3 - - -

7. CH-4 - - - 8. CH-5 - - - 9. GH-4 - - - 10. GH-5 - - - 11. Total 5 5 10

12.3. List of locations for proposed ATCS Systems # Junction Name Number of Arms

1. GH0 4 2. CHO 4 3. Rakshashakti Circle 4 4. Sargasan Circle 4 5. Pathik Ashram 4 6. CH-3 4 7. CH-4 4 8. CH-5 4 9. GH-4 4 10. GH-5 4

12.4. List of locations for RLVD System # Junction Name Total No of No of Arms to be No of Lanes to Arms covered be covered

1. GH0 4 4 8 2. CHO 4 4 8 3. Rakshashakti Circle 4 4 8 4. Sargasan Circle 4 4 8 5. Pathik Ashram 4 4 8

12.5. List of locations for Speed Violation Detection System # Junction Name

348

12.6. List of locations for proposed Variable Message Sign Boards # Junction Name

1. GH0 2. CHO 3. Rakshashakti Circle 4. Sargasan Circle 5. Pathik Ashram 6. CH-3 7. CH-4 8. CH-5 9. GH-4 10. GH-5

12.7. List of locations for proposed PA system # Junction Name

1. GH0 2. CHO 3. Rakshashakti Circle 4. Sargasan Circle 5. Pathik Ashram 6. CH-3 7. CH-4 8. CH-5 9. GH-4 10. GH-5

12.8. List of locations for proposed ECB system

349

1. GH0 2. CHO 3. Rakshashakti Circle 4. Sargasan Circle 5. Pathik Ashram 6. CH-3 7. CH-4 8. CH-5 9. GH-4 10. GH-5

12.9. List of locations for proposed Smart Poles # Junction Name

1. KH 1 2. KH 2 3. KH 3 4. KH 5 5. G 2 6. G 3 7. G 4 8. GH 0 9. GH 5 10. CH 3 11. CH 5 12. CH 6 13. CHH 5 14. CHH 6 15. Sector 30 Circle 16. GH 7 17. K 7 18. Infocity Circle

12.10. List of locations for proposed Kiosk system

350

1. Sector 21 Shopping Centre 2. Infocity 3. Railway Station 4. Mahatma Mandir 5. New Sachivalay 6. Pathikashram 7. Akshar Dham 8. Sctor 7 Shopping Centre 9. Indroda Park 10. Infocity Resort 11. GH 2 12. Sector 24 Shopping Centre 13. KH 0

12.11. List of locations for proposed Internal Wayfinder system # Junction Name Count(1 for each floor or block as applicable for the building)

1. Old Sachivalay 4 2. New Sachivalay 8 3. Vidhan Sabha 4 4. Karmayogi Bhavan 1 5. Mahatma Mandir 2 6. Udyog Bhavan 8

12.12. List of locations for proposed Smart Bus Stops The indicative count is 2 as most of the bus stops are on either side if the roads for indicated location.

# Junction Name Count

1. Unawa 2 2. Pethapur 2 3. Chiloda 2 4. PDPU 2 5. Indroda Bridge 2 6. Visat 2 7. Chandkheda 2 8. Vaishnodevi Circle 2 351

9. Adalaj Circle 2 10. Infocity 2 11. Sargasan 2 12. J 6 2 13. CH 5 2 14. GH 6 2 15. K 6 2 16. Pathikashram 2 Kolavada 2

352

353