UNIVERSITY OF CALIFORNIA, SAN FRANCISCO REQUEST FOR PROPOSAL. Vehicle Tracking System

Transcription

1 UNIVERSITY OF CALIFORNIA, SAN FRANCISCO REQUEST FOR PROPOSAL Vehicle Tracking System UCSF Transportation Services 1625 Owens Street, Suite 202 San Francisco, CA REQUEST FOR PROPOSAL CONTENTS: Background Specification Scope of Work Technical Requirements General Information/Terms and Conditions

2 Deviations from Specifications: Any deviation from the specifications shall be identified and fully described. The right is reserved to accept or reject proposals on each item separately, or as a whole, and to waive any irregularities in the proposal; irregularities may, however, render the proposal nonresponsive. Public Disclosure: Responses to Become Public Records: All materials submitted in response to this solicitation become a matter of public record and shall be regarded as public record. Designation of Confidential Information: The Regents will recognize as confidential only those elements in each response, which are trade secrets as that term is defined in the law of California and which are clearly marked as TRADE SECRET, CONFIDENTIAL, or PROPRIETARY. Vague designations and blanket statements regarding entire pages or documents are insufficient and shall not bind The Regents to protect the designated matter from disclosure. The California Public Records Act limits The Regents ability to withhold prequalification and bid data to trade secrets or records, the disclosure of which is exempt or prohibited pursuant to federal or state law. If a submittal contains any trade secrets that a Contractor does not want disclosed to the public or used by The Regents for any purpose other than evaluation of the Contractor s eligibility, each sheet of such information must be marked with the designation Confidential. The Regents will notify the submitter of data so classified of any request to inspect such data so that the submitter will have an opportunity to establish that such information is exempt from inspection in any proceeding to compel inspection. The Regents Not Liable for Required Disclosure: The Regents shall not in any way be liable or responsible for the disclosure of any records if they are not plainly marked TRADE SECRET, CONFIDENTIAL, or PROPRIETARY, or if disclosure is required by law or by an order of the court. 2

3 Table of Contents 1. INTRODUCTION BIDDER PRE-QUALIFYING CRITERIA REFRENCES SCOPE OF WORK TECHNICAL SPECIFICATIONS COST PROPOSAL GENERAL TERMS AND CONDITIONS

4 INTRODUCTION The University of California, San Francisco s Transportation Services Department is soliciting proposals from qualified vendors for a Vehicle Tracking System or Global Positioning System ( GPS ) for its fleet of 50 shuttle buses. BACKGROUND The University of California, San Francisco (UCSF) is a leading university dedicated to promoting health worldwide through advanced biomedical research, graduate-level education in the life sciences and health professions, and excellence in patient care. It is the only UC campus in the 10-campus system dedicated exclusively to the health sciences. UCSF today boasts high-ranking schools of dentistry, medicine, nursing and pharmacy and a Graduate Division, plus one of the nation s top programs in patient care. All four professional schools, virtually all UCSF graduate programs, UCSF Medical Center and UCSF Benioff Children s Hospital rank among the best in the country in the latest surveys by US News & World Report and other agencies. A hallmark of UCSF excellence is a spirit of collaboration among all disciplines that carries through its wide spectrum of patient care, research and education programs, fostering an environment of innovation and discovery. The result is groundbreaking life sciences research and world-class health care that support UCSF s mission: advancing health worldwide. As one of the most prominent institutions in the San Francisco Bay Area, UCSF has a total paid workforce of 22,800 and is a major economic engine for the entire region. UCSF generates more that 39,000 jobs (including those at UCSF) and produces an estimated impact of $6.2 billion that includes operations, construction, salaries, and local purchases by employees, students and visitors, according to a 2010 economic impact report. UCSF Transportation Services manages all aspects of transit related services for the campus, including parking, shuttle, transit demand management and rideshare services. The shuttle operation includes 1 Operations Manager, 1 Fleet Manager, 4 Supervisors, 1 Administrative Assistant, 70 full-time drivers, and 6 part-time drivers, and 3 maintenance staff. The operation covers a geographic area of approximately five square miles via sixteen fixed-routes throughout the city of San Francisco. The shuttles provide intercampus service to 6 major campus locations with 17 major stops. On an annual basis, UCSF shuttles travel over 1.2 million miles and carries over 2.4 million passengers. The fleet consists of (5) - 33 Passenger Krystal International, (6) - 30 Passenger Chevrolet AeroElite and (39) - 22 Passenger Ford Aerotech shuttles. See for more information about the department and operation. Additional operational highlights: 2.3 million passengers per year, up from 1 million in 2003; anticipated ridership increase in with expansion at Mt. Zion and Mission Bay campuses. 98% on-time departure rate. Smith-Drive camera system deployed throughout fleet. SmithSafe Fleet monitoring service enabled on all fleet vehicles (with decals) Monthly Ridership Statistics per Route (5 major lines): o Grey riders o Gold riders o Blue riders o Black riders o Tan riders Service: Monday-Friday, 6am to 9pm, connecting all major UCSF campus locations in San Francisco, including: Parnassus, Mission Bay, Laurel Heights, SFGH, MCB and Mt. Zion (17 major stops across 6 major sites). Up to 600 trips per day, with scheduled serviced departing approximately every throughout the day. 4

5 Inventory of 50 shuttles that travel 103K miles per month. Fleet Specifications: o (5) - 33 Passenger Krystal International o (6) - 30 Passenger Chevrolet AeroElite o (39) - 22 Passenger Ford Aerotech o Fleet services in South San Francisco with local vendor Mode Split: 2012 Transportation Survey Data- 38% of all faculty, staff and students indicated they regularly used the UCSF shuttle system to commute to work and school. 5

6 BIDDER PRE-QUALIFYING CRITERIA BIDDER eligibility to respond to this RFP is based on BIDDER S ability to meet the qualification requirements listed below. The UNIVERSITY, in its sole discretion, reserves the right to determine whether any BIDDER meets the minimum eligibility standards, to determine whether a proposal is responsive, and to select a proposal which best serves its financial and program objectives. The UNIVERSITY reserves the right to reject all proposals. If BIDDER cannot meet all qualification requirements as stated herein, BIDDER S proposal shall be rejected without further consideration. To have a proposal considered BIDDER S must be well qualified in the following categories: 1. Successful installation of an equal or greater project of similar size, type, and complexity. 2. Ability to develop a fully operational system as jointly defined, portions of which can be installed and functioning within the agreed upon time frames. 3. Ability to commit to a multi-phase project with implications for long-term support. 4. Demonstrated track record of acceptable performance on similar projects, to be evaluated from comments of BIDDER references. 5. Ability to provide timely on site resources and support to UCSF. 6. Ability to demonstrate end-to-end compliance with PCI DSS for the proposed system. 6

7 REFERENCES Please list references of at least 3 customers that are currently using this solution in production under similar circumstances as UCSF proposes. Upon successful BIDDER qualification, the UNIVERSITY may contact some or all of these references to better understand your services and performance levels. References should be of comparable size and complexity to the UNIVERSITY installation. For each reference BIDDER must state contact names and telephone numbers and a brief description of the nature and outcome of each project. Reference information shall be considered in determining BIDDER pre-qualification and may also be considered within the evaluation process in determining BIDDER S compliance with applicable criteria. The UNIVERSITY may contact references furnished by the BIDDER, in addition to other individuals not furnished by BIDDER. The UNIVERSITY is not limited to specific contacts at any reference company. The UNIVERSITY reserves the right to obtain and use, in its evaluation, information from sources not necessarily identified by BIDDER. Furnishing incorrect and/or incomplete reference information may lead to BIDDER S elimination from consideration for award. All references must include the following information: 1. Customer Account 2. Contact Information a. Name b. Telephone c. 3. Organization s Name and Address 4. Context (list work performed and project scope) 7

8 SCOPE OF WORK To improve the quality of transit service, UCSF is seeking a Vehicle Tracking System utilizing GPS technology in conjunction with vehicle location and mapping software to track vehicle locations en route and real-time. UCSF maintains a diversified inventory of vehicle types that provide transit service, ranging from modern CNG buses to diesel and to conventional 22 passenger gasoline buses. This system must provide route and vehicle information in real- time via a web interface to passengers, the dispatcher, and managerial personnel. The primary purpose of the system is to facilitate daily UCSF fixed-route service, and must be equipped with reporting capabilities to accurately data stream operational service information (e.g., route timing, passenger wait time, trip counts, operator performance, vehicle speed and movement). This is essential for the completion of performance metrics, the analysis of daily operations, and long term program planning and analysis. The Vehicle Tracking System must include the functionality for hardware/software components to be installed on 50 vehicles. Following are the functional requirements for the desired VTS application. Proposals must provide a response to each of the requirements with a detailed explanation of the capability of the proposed products or services to provide the desired functionality. The University will consider an Application Service Provider (ASP) hosted solution as well as other alternatives. The Core Requirements represent the minimum functionality the University expects to acquire. 1. Vehicle Tracking Software CORE REQUIREMENTS The Vehicle Tracking Software must utilize GPS in conjunction with vehicle location and mapping software to accurately track bus locations en route in real-time and provide visual mapping displays. The GPS readings of the bus location must occur in real-time with vehicle location information posted on a GUI map display available on a public website and viewable through various devices (SmartPhone, Kiosk, Bus Stop, PC, tablets (I-Pad), etc.). The system should be equipped with a notification service, whereupon users can subscribe and be able to select one route or multiple routes and be notified when the next bus is coming. Real time tracking means that a vehicle's location is reported via an AVL device installed on each vehicle and transmitted to an internet server with a delay of not more than 60 seconds. This is done through the use of GPS for pinpointing the location and a wireless communication system (i.e., cellular GPRS or twoway radio) for transmitting the information to an internet server. Vendor should indicate their recommended rate of transmission for a system such as this. 2. Vehicle Location Data The Vehicle Tracking software must provide a GUI real-time automatic vehicle location data display. Vehicle icon on the map display shall clearly indicate Vehicle ID, Route, Direction, and Location. Further layered information on the vehicle should include Run, Trip, Date/Time, and Speed. Vendors should provide detailed explanations of existing maps and software mapping components and how they work with other components of the system. Screen shots of display windows utilized by dispatch and/or the passenger should be provided describing key features, attributes, and the information available within the mapping component. The Vendor should describe in detail all traveler supported components that it provides, to include the features within each component as well as software and hardware required for implementation. 3. Maps The Vehicle Tracking software must include one integrated map with detailed maps of the UCSF campus streets and buildings, local and regional areas, and major landmarks. The map views should include standard map display features (zoom in/out, panning, etc.). The maps should have an automatic refresh 8

9 feature with the option of refreshing the map views 'upon-demand' by the dispatcher. The geo-spatial object management portion of the system should provide capabilities to trace routes (i.e. bread-crumbs ), place stops and landmarks on the map for dispatchers and the general public to see. The mapping component shall also include a navigational request. 4. Route Management The Vehicle Tracking System must include a Route Management module that can be utilized by the dispatcher to effectively manage the route and determine the location of any vehicle in service. The system must provide the dispatcher the necessary real-time information to manage vehicle fleets whether they are on fixed shuttle routes, charters, in the yard, or on special on-demand events. The system should display the time each bus arrives at each stop per route and the "wait times" (e.g., how long the bus is at the stop). The software should include a GUI real-time dispatch display that clearly indicates status (i.e., color-coding), with emphasis on off-route or off-schedule vehicles. The software should include a predictive estimate of bus arrival times at designated stops based on the average speed of the bus and traffic impacts. The vehicle icon on the dispatch display should clearly indicate Vehicle ID, shuttle code ID (see explanation in next paragraph), Route, Directional Status, Arrival Time, Departure Time, and Date & Time of last GPS update. Like most operations, UCSF chains individual bus trips into vehicle routes. In UCSF terminology, an individual trip on a specific route is referred to as a run. A route defines what one or multiple vehicles will do over the course of the day, and will typically consist of 7 to 50 individual runs, usually rotating among 1-4 different buses throughout the day. The routes are designated by a primary color-coded system, i.e. Yellow, Green, Blue, Red, Lime, etc. The buses are recognized by designating an alpha letter to the bus and color, i.e. A, B, C, or D; and issued a 2 or 3 digit bus identification number to display on the front/rear of vehicle. Therefore, dispatchers and management refer to the shuttles, such as Blue A #98, Grey B #104 or Lime C #57. On occasion, we may interline a specific bus to cover or augment (add on service) to compensate for peak demand or special events that may impact a specific route. For example, the Grey route may consist of scheduled service starting at 6:30AM and departing every 20 minutes throughout the course of the day. A Bronze shuttle may be interlined to augment the Grey s 5:30PM departure from Parnassus to satisfy peak period demand and is therefore referred by dispatch as the back-up 5:30PM Grey. In the UCSF operation, the color and scheduled departure time is the primary reference for the Dispatcher and the entire internal operation. In addition, it may become necessary to place a back-up or reserve shuttle bus into operation to cover a run or route, in response to traffic delays, high passenger loads, driver no-show, mechanical break-downs or routine maintenance, etc. It is essential that the tracking system be able to incorporate the back-up vehicles into the tracking system. The operation typically has a minimum of 6 shuttles in the back-up mode at any time. These shuttles are identified as back-up shuttle and 2-3 digit identification number, i.e. Back-up #55. Vendors should provide detailed explanations of route management components and how they work with other components of the system. Screen shots of applicable windows should be provided describing key features, attributes, and the information available within the management component, and the information available on the dispatch display. 5. Customer Interfaces The Vehicle Tracking System must include a public interface that provides customers with bus location information. At a minimum, the bus locations are to be displayed on a map available on via the internet. Desired functionality includes details available for each bus (showing route, time at last stop or last time point, minutes late/early, etc.) and at each stop (showing next scheduled time and predicted time of next arrival). Vendor should also describe other information distribution interfaces that are available with their product such as stop-based electronic displays, text/sms messaging, PDA applications, etc. UCSF may not choose to implement these additional interfaces if their ongoing cost is too high, but the availability of multiple interfaces will be an important benefit. 9

10 6. Access to Location Data Access to all real-time and archived vehicle location data must also be available to third party applications for external development purposes. Vendor should indicate which method would be used (XML, RSS, JSON, SQL, etc.). 7. Automatic Passenger Counter Requirements Note: The inclusion of the APC module is required, however, the solution must allow the University to expand the use of APC s on individual buses as needed. As an example, the initial deployment of APC hardware may be limited to major routes, consisting of 5 or more buses, however, the module and software must be able to accommodate the entire fleet. The quote should include a cost for 5 buses plus a marginal cost for each additional bus. The Vehicle Tracking System include a compatible Automatic Passenger Counting (APC) module with full logic to count all boarding and departing passengers at each stop and calculate the number of riders onboard after each stop. Passenger counting should only be performed when the door is open. It is preferred that the APC component be integrated with the vehicle location data that is collected and transferred via the wireless communications network to the dispatch center after each stop. Specific features of the APC component should include/provide for: a. Capture and storage of passenger count data. b. Reports from passenger count information, including: i. Clearly identified peak service periods (PSP) based upon passenger counts (loading and unloading) for each specific bus stop by each specific route, and peak service periods within incremental hourly ranges. For example, 300 passengers loaded from 7:00 AM to 8:00 AM at Stops 2, 4, 5 and 6 and 275 passengers were unloaded from 7:00 AM to 8:00 AM at Stops 2, 4, 5 and 6 on Grey A bus. ii. Passengers on and off at specified stops, times, or stated time periods. iii. Ridership counts by route, trip, or stated time periods. c. A means to verify proper operation of count sensors and to diagnose problems. d. The passenger count sensors should be configured, positioned, and adjusted to reliably detect the presence and direction of each passenger's movement, whether boarding or alighting from the bus. e. The sensors must be discrete components that transmit passenger count information to the dispatch center in real-time. f. The sensors should be electro-optical devices (i.e., infra-red) and should not require physical contact with the passengers being counted. g. The sensors should be capable of operating within a transit environment and proper alignment should not be susceptible to normal vibrations found on a bus. The Vendor should clearly describe how the passenger count data is obtained and stored as well as the equipment and hardware required for storage and transmission to central dispatch. Additionally, Vendors should describe the reports available from the passenger count data, and provide sample reports in the proposal. 8. LED and LCD Signage (OPTIONAL) It is preferred that the Vehicle Tracking system include web-based integrated text-only LED or LCD signs be fully integrated with the Vehicle Tracking system and placed either outdoors or indoors at bus stops, kiosks, or in major campus buildings. Signs placed outdoors must be weatherproofed and sunlight readable. 10

11 Vendor to describe the communications infrastructure requirements (e.g. wired Ethernet connections, wireless cellular data communications) and other related infrastructure hardware or software required to implement and deploy the LED or LCD signage. Vendor must also describe the sizes of the signs, power requirements, pre-set timing options, and display options. Vendor should provide sample views of LED and LCD signs. 11

12 TECHNICAL REQUIREMENTS A. Data & Infrastructure Vendors should recommend a data network that will provide real time vehicle location data for a minimum of 50 vehicles in total of which up to 40 will be operating at the same time. UCSF employs approximately 76 employees, so the system must be capable of accommodating this number of employees (each with a unique four-digit employee number) and a reasonable number of employees due to expansion. The data network must utilize in real-time with a built-in resolution for 'dead-zones'. The Vendor should define the specifications for the data communications protocols and the time delays that will occur between capture of GPS coordinates and data transmission to the map views. The Vendor should state the maximum number of vehicles that can be supported by the data communications being proposed. Additionally, vendors should describe in detail the means for monitoring the status of communications between each vehicle and the central dispatch center. Vendor should clearly identify all equipment necessary to transmit data between vehicles and the dispatch center. Vendors must identify how proposed data network will resolve for potential interference restrictions (i.e., dead-zones). Vendor must describe in detail all hardware, software, wiring, and interconnections necessary, to include pricing, for automatically transferring data between vehicles and central dispatch and posting data to graphical user interface (GUI) map views. B. Hosted versus Non-Hosted If vendor hosted implementation is an option, please respond to the requirements below for both a vendor hosted and UCSF hosted scenario: 1. Minimum recommended hardware requirements for servers, workstations, and software necessary to operate the system(s) must be specified. The University reserves the option to acquire all non-proprietary hardware and software meeting the supplied requirements. 2. Application should support Active Directory, IIS, and Windows 2003 or higher in a multi-server clustered and load-balanced configuration. Also, a virtual server implementation should be supported. 3. Any network configuration and security requirements necessary to operate the system(s) must be specified. Network and interface diagrams showing the relationship between servers, workstations, other devices, and the internet should be provided. 4. System should utilize a robust database engine. Oracle (version 10G, rev 2 or higher) or MS SQL 2005 are currently supported by UCSF and are the preferred platforms. All data collected should be backed up so that no data is lost. 5. The end user and administrative software should have a graphical user interface run on standard Windows XP, Windows Vista and Apple OS workstations on a multi-user local area network or via the internet. The system shall be Web based and accessible from any desktop within the UCSF system. A non-java dependent interface is preferred. A description of any desktop installation 12

13 requirements including drivers, java, components, etc., must be provided. 6. Database must be thoroughly documented to facilitate data import/exports and ad hoc query and reporting. Documentation should include a detailed data dictionary, Entity Relationship diagrams, and Data Flow diagrams. Application should support Active Directory, IIS, and Windows 2003 or higher in a multi-server clustered and load-balanced configuration. Also, a virtual server implementation must be supported. 7. Must be compatible with third party reporting tools such as Crystal Reports. Indicate with which 3rd party reporting tools the database is compatible. 8. The system must have the capacity to both import and export data on a regular and automated basis either through vendor API or defined database access protocol. 9. A description of the security features of the application should be provided. This includes antiintrusion measures at the client, business object and database levels, auditing and logging features, and user management controls. In addition, it is desirable for user logon and access rights to be integrated with Active Directory. C. SOFTWARE AND HARDWARE REQUIREMENTS UCSF prefers an ASP solution, whereby the ASP will manage and distribute information from a central data center. Vendor to respond to the requirements below for purchased hosted software applications: 1. Vendor to assume responsibility for complete delivery, setup, configuration, and installation of software and hardware. Vendor must work directly with hardware vendor to provide a smooth and seamless data transmission between communications devices and software applications. 2. A system solution that uses proven open technology, with minimal operational impacts to passengers, vehicle operators, and dispatchers, and a system that requires minimal system customization. Any new or customized software requiring further development shall be indicated in the proposal. UCSF must approve the design and functionality of any new or customized software prior to development. 3. All equipment must be current production/state-of-the-art, commercially rated and manufactured by well-established and reputable manufacturers. Equipment must be readily available for the expected life span of the system as needed for repair, replacement or expansion/upgrades. 4. The Vendor must certify that the proposed equipment is designed for and suitable for the University s intended purpose of demand-response and fixed route services, which require long-life and high reliability under adverse conditions. 5. All electronic equipment should be solid-state design, and all equipment housings should be waterproof and dust-proof. 13

14 6. All Vendor-provided on-board equipment should operate properly under the environmental conditions encountered on board the vehicles including conditions pertaining to temperature, humidity, dust/dirt, power variations, shock, and vibration. 7. The Vendor's proposal must include all vehicle wiring and connectors required for the equipment. The wiring and connectors should be appropriate to the transportation environment where the equipment is to be installed. Shielded cables should be provided where necessary to avoid interference problems. D. WARRANTY AND MAINTENANCE All components of the Vehicle Tracking System should include a standard/limited warranty that begins once the system is accepted for purchase by UCSF. The Vendor should provide a copy of the warranty and maintenance terms in the proposal. The Vendor should specify the following: 1. Hardware, software, and vehicle equipment maintenance agreement terms, including the level of support provided. 2. The services provided (what are the turnaround times for hardware repairs, etc.). 3. Toll free technical support number provided during the hours of 8:00 a.m. to 5:00 p.m. PDT Monday through Friday. Include information on evening and weekend support hours and services. If the vendor is hosting the system, notification should be provided prior to any scheduled downtime and as soon as possible regarding any unscheduled downtime, with a detailed explanation, including length of service interruption. Up-time should be 99.9%. UCSF retains the right to negotiate purchase/warranty terms where appropriate. UCSF also has the option of accepting or rejecting an extended warranty/maintenance agreement. The Vendor should state in the proposal any extended warranty/maintenance agreements that are available for the proposed equipment. Vendors should include their annual software and hardware maintenance escalation percentages. Additionally, vendors should include descriptions of how new versions/upgrades of the software are released and what options customers have to migrate to these new versions. Specify if the new versions/upgrades are included in the purchase price. E. DATA STORAGE AND SYSTEM REPORTING The Vehicle Tracking System shall collect vehicle location data and store it for reporting as required. The reporting component should provide monthly, annual, year-to-date, and ad-hoc operational reports on vehicles, drivers, locations, etc. Typical reports would include: 1. On-time performance, including count of early and late stop departures and wait times. 2. Vehicle usage (demand-response and fixed-route usage, etc.). 3. Route statistics (schedule adherence, historical routes driven, defined routes, off-route vehicles, etc.) The Vendor should describe in detail the reports available, including sample reports. If one or more of the reports is not currently available, the vendor should include the cost for developing such reports as a separate line item. UCSF would prefer that the database supporting the reporting component be compatible with and allow accessibility to third-party reporting tools, such as Crystal Reports. 14

15 F. DOCUMENTATION All aspects of the Vehicle Tracking system and individual components should be clearly and thoroughly documented for both technical and non-technical support staff and for end-user understanding. Documentation should encompass detailed product descriptions as well as step-by-step instructions on how to utilize the equipment. Documentation should be geared towards varying audiences to include vehicle operators, dispatchers, network support staff, area managers, transit operators, and maintenance technicians. Documentation materials should be broken into the following areas and/or functions: 1. Computer hardware, systems software, and equipment specifications. 2. End-user focused materials on "How To" operate the equipment within each of the Vehicle Tracking System components. For example, detailed step-by-step instructions should be included for: a. Traveler Information Features (Web Interface, etc.). b. Map Creation and Views (Zooming, Multiple Views, Ad-Hoc Maps, Map Maintenance, etc.) c. Wireless Data Communications (Usage of wireless equipment and data transmission procedures). d. Route Management and Performance (Dispatcher). e. Data Storage and Reporting (Report Generation, Ad-Hoc Report Creation, etc.). f. Data Access including API for use in developing 3 rd party applications. g. Automatic Passenger Counters - If proposed (Equipment and Maintenance). 3. On-going support with various options (on-line, phone, etc.). 4. Toll free support number provided during the hours of 8:00 a.m. to 5:00 p.m. PDT Monday through Friday. Include information on evening and weekend support hours and services. The Vendor should provide a sample of the documentation in the proposal. Upon installation, the successful bidder will provide complete documentation and training materials. G. TRAINING The Vendor should provide Training Support to address all aspects of the Vehicle Tracking System and individual component parts. The Vendor should provide on-site consultation and training throughout the implementation process. Training should be provided for both technical, non-technical support staff, and end-user administrators and staff. Training should encompass demonstrations of the overall product and individual component parts. Step-by- step instructions should be demonstrated on how to install and/or use the equipment for varying audiences to include vehicle operators, dispatchers, network support staff, area managers, transit operators, and maintenance technicians. Detailed documentation materials (as described above) should be include in training sessions to provide the level of depth required to effectively administer and operate the Vehicle Tracking System and its component parts. The Vendor should state the training support and service they will provide to include the following: 15

16 1. Toll free support number provided during the hours of 8:00 a.m. to 5:00 p.m. PDT Monday through Friday. Include information on evening and weekend support hours and services. 2. On-site system implementation consultation and support. Vendor to state the number of hours provided. 3. Hardware/equipment and vehicle installation training. Vendor to state the number of hours provided. 4. Field training for dispatchers, field supervisors, and field operators. Vendor to state the number of hours provided. 5. Administrator training for administrators and support staff. Vendor to state the number of hours provided. 6. Training for the 'trainers'. Vendor to state the number of training hours provided. 7. On-going training support and various training options (on-line, CBTs, etc.). The Vendor should describe in detail the training support and service, and suggested training plan, with proposed timelines, for varying stages before after and during the project. 16

17 PRICE PROPOSAL CORE FEATURES Core Product # Product Description # Of Units Unit Price Dis- Count % Net Unit Price Ext. Price Wireless Data Communications Infrastructure 1 Wireless communications fees Equipment 1 Hardware 2 Cables 3 GPS Receiver & Antenna 4 Limited/Standard Warranty 5 Extended Warranty Labor On-Site Installation Support (labor 21 On-Site Hardware Installation (in Other 1 Other Charges (please describe) Subtotal Wireless Data Communications PRICE Software Application Software 1 Web Based Maps Labor 2 Ad-Hoc Maps & Routine Updates 3 Navigational Map Tool 4 Route Management Module 5 Vehicle Location Module 6 Internet Information Display 7 Data Storage & Reporting On-Site Installation Support (labor 1 2 Other Services Other 1 Other Charges (please describe) Subtotal Software Application PRICE Training & support Training 1 On-Site System Implementation & Consultation 2 Training Manuals 2 Dispatcher, Operator, and Ad i i t t T i i 3 Field Training 4 Train-the-Trainer Training 5 Hardware/Equipment Vehicle I t ll ti T i i 6 On-going Training Support TOTAL Training & Support PRICE GRAND TOTAL CORE FEATURES 17

18 APC and LED (Sign) Features Core Product # Product Description # Of Units Unit Price Dis- Count % Net Unit Price Ext. Price Automatic Passenger Counting (Optional) Counters 1 Sensors 2 Control Unit 3 Cables 4 Other Equipment 5 Limited/Standard Warranty 6 Extended Warranty Labor 1 On-Site Support (labor rate per day) 2 Other Services Other 1 Other Charges (please describe) Subtotal APC PRICE Driver Scheduling Software (Optional) Software 1 Driver Scheduling Module 2 Dispatcher Module 3 Reporting Other 1 Other Charges (please describe) Subtotal Driver Scheduling Software PRICE LED or LCD Signage (Optional) Signs 1 Software 2 Control Unit 3 Cables 4 Other Equipment Other 1 Other Charges (please describe) Subtotal LED or LCD Signage PRICE NO PAYMENTS WILL BE MADE IN ADVANCE OF PRODUCT DELIVERY OR WORK PERFORMED. 18

19 GENERAL INFORMATION: TERMS AND CONDITIONS This RFP is issued by the UNIVERSITY of California, San Francisco, Purchasing Department. PURPOSE This RFP provides prospective BIDDERS with sufficient information to enable them to prepare and submit a proposal. In this RFP, the term "UNIVERSITY" or "UCSF" shall be understood to mean "UNIVERSITY of California, San Francisco". The term "BIDDER", Vendor and/or Contractor, as used herein, shall be understood to mean the individual, company, corporation or firm whose product is selected for purchase after successfully bidding in response to this RFP. Until a purchase is recommended and approved, the term shall be understood to mean the individual, company, corporation or firm formally submitting a response to this RFP. The term "response," as used herein, shall be understood to mean a written offer to provide goods and/or services in accordance with the general conditions, instructions and specifications stated herein with exceptions clearly stated. SCOPE This RFP contains the instructions governing the proposals to be submitted and the material to be included therein. Mandatory requirements within must be met to be eligible for consideration. PROJECTED SCHEDULE OF ACTIVITIES BIDDERS conference, Mandatory: October 4, 2012, 2:00 PM 4:00 PM, UCSF Mission Bay Conference Center, Room 168, 1625 Owens Street, San Francsico, Ca., QUESTIONS*: Last day to submit questions: October 8, 2012, Noon. *Questions must be submitted in writing via BidSync. Answers will be posted on BidSync. Bidders are not to contact UCSF directly. RFP response submission deadline: October 18, 2012, Noon. INVITATION TO BID/RESPOND AND RESPONSIBILITIES OF BIDDERS The UNIVERSITY is hereby contacting prospective BIDDERS who have an interest or are known to do business relevant to this RFP. All interested individuals/firms who were not contacted are invited to submit a proposal in accordance with the policies, procedures and dates as set forth herein. In the event of "no bid," please sign bid, indicating, "no bid" and return. BIDDERS CONFERENCE A BIDDERS Conference will be held at the University on the date specified above. The conference is for the benefit of the potential BIDDERS to understand the magnitude of the project and to address questions and clarifications concerning the specifications/requirements under this project. If you have immediate questions or concerns regarding this RFP, please hold those until the conference. ATTENDANCE IS MANDATORY. Please Erick Villalobos, Associate Director, UCSF Transportation Services, at Erick.villalobos@ucsf.edu to confirm your attendance and obtain directions to the meeting site. 19