Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
78 A P P E N D I X D Sample RFPs This appendix contains four RFPs issued by Michigan, Ohio, and Arizona DOTs for acquiring speed and OD data. They are provided as references and to demonstrate current RFP practices at state DOTs for different types of data acquisitions. The RFPs have specific data quality requirements, use and sharing policy specifications, criteria and their weights on vendor/product solicitation, cost proposal requirements, as well as payment penalties contingent on the data quality.
Sample RFPs 79 APPENDIX D1 MICHIGAN DOT SPEED DATA RFP Michigan Department of Transportation SCOPE OF SERVICE FOR SPECIALTY SERVICES Real-time Traffic Data & Performance Analytics Best Value CONTROL SECTION: 84900 JOB NUMBER: 116389 PROJECT LOCATION: Various locations throughout the state of Michigan, including MDOT Bay, Grand, Metro, North, Southwest, Superior and University Regions. PROJECT DESCRIPTION: The two tasks to be accomplished by this project are: Provide real-time traffic data for freeway routes in the State of Michigan for use by the Michigan Department of Transportation (MDOT) and its partners. Provide a web-based Transportation Performance Measure Reporting and Analysis System (TPMRAS) PRIMARY PREQUALIFICATION CLASSIFICATION(S): N/A SECONDARY PREQUALIFICATION CLASSIFICATION(S): N/A ANTICIPATED SERVICE START DATE:July 1, 2017 ANTICIPATED SERVICE COMPLETION DATE: June 30, 2020 PREFERRED QUALIFICATIONS AND CRITERIA: The Contractor shall have a minimum of five related projects working with state government, local municipalities, or international equivalent over the past five years providing real - time traffic data for freeway routes. The Contractor shall display extensive software experience, including working knowledge of data feeds including but not limited to; extensible mark-up language (XML) average speed, traffic, incident, construction, weather data and other traffic information. The selected Contractor must also display a highly developed ability to work with multiple teams on complex projects. The selected Contractor will have performed planning, installation, and support services for
80 Practices on Acquiring Proprietary Data for Transportation Applications similar software and installations for other DOTs, including procurement, installation, configuration, and operation of the software. Including minimum five years of previous experience with supplying state government, local municipalities, or international equivalents with similar software. MDOT PROJECT MANAGER: Elise Feldpausch, P.E. Michigan Department of Transportation 8885 Ricks Rd. P.O. Box 30049 Lansing, MI, 48917 517-636-0036 feldpausche1@michigan.gov REQUIRED MDOT GUIDELINES AND STANDARDS: Work shall conform to current MDOT, FHWA, and AASHTO practices, guidelines, policies, and standards. GENERAL INFORMATION: The Contractor shall furnish all services and labor necessary to conduct and complete the services described herein. The Contractor shall also furnish all materials, equipment, supplies, and incidentals necessary to perform the Services (other than those designated in writing to be furnished by the Department) and check and/or test the materials, equipment, supplies and incidentals as necessary in carrying out this work. The Services shall be performed to the satisfaction of the Department consistent with applicable professional standards. The Contractor shall comply with all applicable Federal and State laws, rules, and regulations. The Contractorâs staff shall conduct themselves with professionalism in carrying out their duties. The Contractor shall notify the Project Manager, in writing, prior to any personnel changes from those specified in the Contractorâs original approved proposal. Any personnel substitutions are subject to review and approval by the MDOT Project Manager. At the request of the Department, the Contractor, during the progress of the Services, shall furnish information or data relating to the Services described herein. These may be required by the Department to enable it to carry out or to proceed with related phases of the Project not described herein, or which may be necessary to enable the Department to furnish information to the Contractor upon which to proceed with further Services. For purposes of clarity and clarification this RFP will be broken down into two components; 1) the acquisition of Real-time Traffic Data for the State of Michigan and 2) the acquisition of a TPMRAS. 1) REAL-TIME TRAFFIC DATA MDOT's ITS program has historically focused on the State's urban centers of Detroit and Grand Rapids where two of the four existing transportation operations centers (TOCs) and the vast
Sample RFPs 81 majority of ITS assets are located. Beyond these two urban centers, however, MDOT has been expanding its ITS footprint throughout the entire State, recognizing that safe and efficient recreational and inter-city travel is critical to the state's economy. Advanced Traveler Information System (ATIS) is being deployed throughout the state to provide better traveler information to assist drivers with making more informed route choices. In order for the system to function properly the necessary data must be collected to make accurate and timely traffic management decisions. These decisions are made possible through the use of innovative nonintrusive traffic data collection techniques. There are two primary objectives of this portion of the procurement: The first objective of the project is for the acquisition of a subscription-based real-time, travel time service for all available segments. The data being supplied should be accurate, real-time, and reliable and must reflect actual traffic conditions. This data will enhance MDOT operations and provide for a more informed and reliable driving experience through the dissemination of information. The accuracy and timeliness of the data will play a major role in the public perception of the system. Therefore, in order for the system to be effective the data reported must reflect the actual conditions. The provided traffic data will be displayed in real-time on a publicly available web-based traveler information system such as the Mi Drive website (www.michigan.gov/drive). The traffic data will also be used to calculate travel times for MDOT routes on Dynamic Message Signs (DMS) in real time using MDOTâs Advanced Traffic Management System (ATMS) software. The second objective is for access to a historical archive of traffic data for operational planning and research purposes. This data will be used to analyze MDOTâs highway performance to determine if the department is meeting its performance measurement goals utilizing the acquired TPMRAS as defined in this RFP. Independent Validation The Contractor shall agree to cooperate with data validation either by MDOT or an independent contractor of MDOTâs choosing. The independent validation tests may use any combination of floating car runs, vehicle detection technology, Bluetooth and/or Wi-Fi re-identification technology to verify Contractor data. MDOT will enforce the data quality requirements and the quality targets included in this contract. MDOT will impose data quality requirements short of contract termination for the first infraction. If validation tests indicate that the Contractor has not met the data requirements for a particular time frame, a percentage of or the entire payment for that period shall be retained by MDOT. If the Contractor does not meet the data validation requirements the following period, MDOT shall have the right to withhold further payment, renegotiate or terminate the contract. Included in Appendix A is a detailed metric as to how validation is to be accomplished and the associated payment penalties. The Contractor shall disclose any changes that may improve or reduce data quality including, but not limited to gaining or losing a key fleet of vehicles or a cellular carrier contract. In the event that a key data source becomes unavailable, data quality requirements will still remain in place.
82 Practices on Acquiring Proprietary Data for Transportation Applications Data Usage All data provided by the Contractor shall be available for full use by MDOT, its partners and consultants for any traveler information purposes including DMS, potential future 511 services, potential future Connected Vehicle (CV) applications, websites including, but not limited to, MI Drive, highway performance measurement tools including the acquired TPMRAS, for archiving to be used in future MDOT planning, evaluation and research, system performance measures required by MAP-21 and the FAST act, and for future unforeseen uses. MDOT cannot resell any data provided by the Contractor. The Contractor retains the right to use the collected data for any use including traveler information and reselling and archiving. In the event the Contractor resells or makes public data that employs MDOT-owned detectors, credit or recognition shall be given identifying MDOT in connection with the data. Data may be made available to a consultant or systems integrator on the basis that the data is to be used strictly for planning and or engineering purposes to benefit MDOT. Non-MDOT agencies wishing to use the data may be subject to a non-disclosure clause. However, MDOT will not be held liable nor responsible to develop or enforce a non-disclosure clause. All data shall be available for viewing in real-time. At the end of each quarter-year, while the contract is active, the Contractor shall provide MDOT with a CD(s), DVD(s), USB flash drive(s) or external hard drive containing all of the collected data within that year for continued use. Valid Sources of Data This traffic data may come from a variety of sources and bidders are encouraged to propose innovative approaches to traffic data collection that fulfill the requirements of MDOT as detailed in this Request for Proposals (RFP). It is intended that this data will support the provision of inter-city traveler information, system performance measures and support MDOTâs ability to manage traffic in the coverage area. The successful bidder will enter into an agreement with MDOT for the provision of real-time traffic data for three years on routes specified in this RFP, with the potential contract terms. The Contractor shall clearly explain the proposed sources of data where they will apply, and how one or more will be used to derive a single estimate for each segment in each reporting period. MDOT will allow any combination of the following data sources: ⢠Real-time probe based data; ⢠Historical data; ⢠Forecasting or modeling; and ⢠MDOT owned real-time infrastructure-based data (access to live MDOT microwave vehicle detection system (MVDS) data). The Contractor is required to integrate the real-time data from MDOT MVDS in existing formats or schemas into the Contractorâs real-time data feed. Documentation on real-time detector locations and data access will be supplied to the Contractor upon request. Any processing or formatting required additional to the supplied data will be the responsibility of the Contractor. The Contractor shall ultimately be held responsible for meeting all data requirements. MDOT is not liable for failed or inaccurate data from its detectors. In the event that the Contractor obtains new sources of data, these may be incorporated into the system at no additional cost to MDOT. Additionally, MDOT may make available to the Contractor new data sources where feasible.
Sample RFPs 83 2) Transportation Performance Measure Reporting and Analysis System The Contractor will provide a web-based Transportation Performance Measure Reporting and Analysis System (TPMRAS) that will integrate the real-time traffic data provided in this contract and other associated MDOT provided transportation data. This will allow MDOT to manage, visualize, interpret, report and make actionable use of its transportation data by allowing MDOT to evaluate the traffic impacts of incidents, construction, special events, etc. This system will enable MDOT to establish baseline performance metrics and be able to better identify and efficiently respond to re-occurring and abnormal conditions. The MDOT provided transportation data includes but is not limited to the following: construction, incident, and crash data, Road Weather Information System (RWIS) data, Microwave Vehicle Detection Systems (MVDS) data, Permanent Traffic Recorder (PTR) data, Closed-Circuit Television (CCTV) video feeds and Dynamic Message Signs (DMS) messages. TPMRAS shall also include the National Performance Management Research Data Set (NPMRDS) or approved FHWA equivalent to be able to create system performance measures and targets based on the MAP-21 and FAST Act requirements. CONTRACTOR RESPONSIBILITIES: 1) REAL-TIME TRAFFIC DATA The Contractor must adhere to all applicable OSHA and MIOSHA safety standards, including the appropriate traffic signs for the activities and conditions for this job and adherence to the Personal Protective Equipment (PPE) standards. The Contractor shall meet with the MDOT Project Manager to review project, location of data sources and contact persons, and review relevant MDOT operations. The Contractor shall review and clarify project issues, data needs and availability, and the sequence of events and team meetings that are essential to complete the design by the project plan completion date. Attention shall be given to critical target dates that may require a large lead time. Scope of Contractor Duties The Contractor shall provide a Project Work Plan within ten business days of notice to proceed. The project work plan will include: ⢠A project schedule that outlines all necessary steps required to provide the real-time traffic data in this RFP. This includes the identification of interim deliverables and reviews required of MDOT. The schedule will include key milestones and the commencement date for the delivery of real-time traffic data feed will be part of the schedule. ⢠A quality assurance/quality control (QA/QC) plan that describes the Contractorâs plan for monitoring and maintaining data quality and coordination with MDOT and any potential independent validation Contractor. The Contractor shall submit monthly progress reports by the fifth business day of the next month.
84 Practices on Acquiring Proprietary Data for Transportation Applications Monthly progress reports will include, at a minimum, all key information affecting the quality, availability or reliability of the data feed in the previous month. For any issues that arise, the Contractor shall present a plan for how they will be resolved. Any formal request made to the Contractor to investigate inconsistent or questionable data must be responded to within seven calendar days. The monthly progress reports must also include any changes made to the real- time traffic data such as mapped segments and reference speeds. The project will begin with a formal in person kick-off meeting, to review the project work plan and provide an opportunity for MDOT and the Contractor to share expectations for the project. I. Real-Time Traffic Data Requirements A. Data Format. 1. The real-time data shall be provided in Extensible Markup Language (XML) format, using an MDOT approved schema. 2. The real-time data shall be provided in Comma Separated Values (CSV) format. 3. The real-time data files shall be delivered via Hypertext Transfer Protocol (HTTP) or another standard protocol. B. Data Elements. 1. Raw segment speed in miles per hour to the nearest integer shall be a reported data element. This shall be ârawâ data, without processing for smoothing. 2. Smoothed segment speed in miles per hour to the nearest integer shall be a reported data element. At a minimum, the smoothing process shall cap speeds at the speed limit. 3. Raw segment travel time to the nearest whole second shall be a reported data element. This shall be ârawâ data, without processing for smoothing. 4. Smoothed travel time to the nearest whole second shall be a reported data element. At a minimum, the smoothing process shall truncate travel times to not imply greater than speed limit travel 5. A confidence interval shall be a reported data element. The confidence interval shall indicate the reliability of each segment speed and travel time. A definition of the confidence interval must also be supplied. C. Definition of Segments. 1. Segment definition shall be based on logical breaks in facilities where one would expect the potential for differing traffic conditions such as an interchange, intersection, a lane drop or a major at grade intersection.
Sample RFPs 85 2. Segment definitions shall at a minimum contain beginning and ending latitude, longitude, heading, common name or route number, and a unique identifier (such as a Traffic Message Channel (TMC) code). 3. When individual probe speeds within a segment vary, speed data should be supplied for shorter, sub-segments that are approximately 1 mile in length. This ability must be provided for at least 80% of all segments statewide. 4. A segment definition file shall be provided and updated as changes are made (i.e. when ramps are added and geometry changes). 5. Segment definitions shall conform to applicable standards or comparable open and published data standards. 6. Segmentation shall be translatable to the Michigan Geographic Framework (see http://www.michigan.gov/cgi). 7. The segment definition file shall be in XML format in an MDOT approved schema. 8. The segment definition file shall be in CSV format. 9. Route Coverage. The Contractor shall provide traffic data for all segments statewide. 10. Update Interval. The data shall be updated once every 2 minutes. D. Accuracy. 1. Absolute average speed error shall be evaluated individually in separate speed buckets of 0-30 MPH, 31-50 MPH and 51+ MPH. 2. The average speed error shall be within +/- 10 MPH for each speed bucket E. Completeness. 1. The Contractor shall provide data quality indicators on completeness for each speed bucket. 2. Completeness shall be reported as the percent of segments with data per update interval. 3. Traffic data shall be provided for at least 95% of all segments at all required time reporting intervals. F. Data Availability. 1. The Contractor shall provide traffic data 24 hours a day 7 days a week, with allowances made for up to 40 hours of scheduled system maintenance per year during off hours. The Contractor shall not perform scheduled maintenance without prior approval from MDOT 24 hours before the scheduled maintenance.
86 Practices on Acquiring Proprietary Data for Transportation Applications 2. Apart from scheduled downtime, the Contractor shall maintain an overall data availability of at least 99.5 percent in each calendar month of the contract. G. Latency. 1. The Contractor shall maintain a maximum data latency of 10 minutes or less (minimum). 2. The Contractor shall maintain a maximum data latency of 5 minutes or less (desired). II. Historical Traffic Data Requirements A. At the end of each quarter-year, while the contract is active, the Contractor shall provide MDOT with a CD(s), DVD(s), USB flash drive(s) or external hard drive containing all of the collected data within that year for continued use. 2) TRANSPORTATION PERFORMANCE MEASURE REPORTING AND ANALYSIS SYSTEM Provide a web based performance measures program for unlimited users by state and contract employees. Allow other Michigan governmental entities access, and enable ability for MDOT to set up different access restrictions. Transportation Performance Measure Reporting and Analysis System TPMRAS must include the following requirements upon execution of the contract. I. Data Requirements A. Compatible with a standard XML feed for probe average speed data supplied to MDOT and incorporate all available segments and meet requirements identified in this RFP. B. Supply capacity to store a minimum of 10 years of all collected data and import existing data starting from January 1, 2012 to the present date. C. Incorporate National Performance Management Research Data Set or FHWA equivalent. D. Incorporate Annual Average Daily Traffic (AADT) and Commercial Average Daily Traffic (CADT) if available, as provided by MDOT and updated annually. E. Incorporate incidents and construction data as provided by MDOT and overlap them on applicable tools. F. Overlay incident, construction and weather radar on speed data. G. Incorporate data including but not limited to RWIS, MVDS, DMS and CCTV video feeds provided by MDOT.
Sample RFPs 87 II. Functionality Requirements All tools for performance measures have the ability for the user to: A. Select various time frames by day, week, month, and year with a granularity down to 5 minutes unless specified otherwise. B. Pull performance measures by route, route segment, region, by custom road mile marker and Physical Road (PR) mile points. C. Manipulate segment sets into groups to make it easy to perform segment specific reports or to help with repeated data pulls. These sets should have the ability for other users to use and the ability to sort. 1. Ability to have a reserved set of users who retain administrative rights including the ability to delete segment sets. D. Save the performance measures as a picture file, xml file and video file if applicable, and the ability to share links with other users. E. Access help pages at a minimum that explain how the performance measures are calculated and what data is being used. F. View all state routes, their current speeds, speed as a percentage of the historic average speed for that time of day and day of week, weather, incidents and construction in a map view. 1. Includes ability to see these measures in a previous point in time. G. Access tools to implement MAP-21/FAST Act system performance measure requirements that utilize the NPMRDS or equivalent. H. Alert MDOT of abnormal speed conditions compared to reoccurring congested conditions via email or text messages. Include the ability to send alerts to multiple people. Ability to select speed, location and time thresholds for when alerts should be sent. I. Compare all measures with previous selected data, i.e. comparing different years to each other. III. Map Requirements A. Generate a heat map which shows speeds/speed as a percentage of historic average/speed as a percentage of posted speed limit and reliability measures. 1. Tool must have the ability to change colors based on speed or other selectable data type.
88 Practices on Acquiring Proprietary Data for Transportation Applications 2. Must have the ability to select multiple roadways and show one or both directions at the same time. B. Generate animated maps showing changes in speed over a specific day/week/month/year. 1. Tool must have the ability to change colors based on speed or other selectable data type. 2. Have the ability to select multiple roadways. IV. Reporting Requirements A. Ability to calculate user delay costs based on the user selected speed thresholds and the ability to select what speed to calculate against at a minimum the posted speed limit and historical average. 1. The user delay costs is based on an hourly rate, AADT (each updated annually) provided by MDOT. Contractor will be responsible for updating calculations when new hourly rate is provided. 2. User delay costs must be reported out by the hour at a maximum but the calculations must use average speed increments of 10 minutes or less to reduce washing out the data. B. Generate reports on speed data; length and duration below a certain speed. C. Generate reliability measures summaries including buffer time, buffer index, planning time, planning time index, speed, travel time and travel time index. D. At a minimum be aggregated by hour but not limited to on the hour (ie 7:15-8:15) and the ability to group by day of week, weekday, weekends and by direction of traffic. E. Generate a bottleneck ranking report. 1. Ability to list and rank bottlenecks, how often they occur, average duration, maximum queue, volume and sort by each criteria. F. Generate reports on travel time, number of delays over various time thresholds, and user delay costs by time of day and position on route. G. Generate line graphs of speed and reliability measures. 1. This should include at a minimum 95th and 80th percentiles and average speeds with the ability to separate by traffic direction or time period. 2. Granularity at a 2 minute minimum.
Sample RFPs 89 3. Should have the ability to select multiple roadways. H. Historic average speeds to be calculated on a yearly basis. The previous 3 years of data should be shown when comparing data. I. Create exportable charts and interactive maps of speed data by time of day and by position on route. Include data quality metric as provided to the state by the probe data average speed data vendor. This includes the ability to eliminate historical data when confidence of the probe average speed data is low. V. Export Requirements A. Ability to export raw probe data as a CSV file including the ability to select various time periods, ability to average the probe data at various increments between 2-60 minutes. B. Must be able to export data in excel form and export maps/graphs. VI. Additional Requirements: Any of the following additional requirements identified below that are not available upon time of submittal must be integrated within 2 months of the contract start date. The Contractor must provide an integration plan and timeline for each of these requirements. A. Incorporate real-time MVDS data and have the ability to adjust AADT to calculate User Delay Costs. Ability to select specific MVDS sites and see real time readings. B. Develop a map based segment selection process. C. Ability to automatically generate daily, weekly and monthly reports for various performance measures. The ability to report on specific segments over a specific time frame and save query per user. D. Create annual Congestion & Mobility report and poster with performance measures/charts/maps, using metrics as specified by MDOT. See website below for previous reports. http://www.michigan.gov/mdot/0,4616,7-151- 9622_11045_25024_75677---,00.html E. Develop a tool to calculate congestion which is calculated as multiplying the number of hours congested (No/Low, Moderate, Severe) by the segment length. Example, greater than 55 mph is No/Low, 35 mph to 55 mph is moderate and less than 35 mph is severe. 3) TRAINING Contractor may be requested provide training for any other software necessary to meet the requirements of this Proposal. All training will meet or exceed the requirements listed below.
90 Practices on Acquiring Proprietary Data for Transportation Applications A. Course materials shall be approved by MDOT at least 10 calendar days prior to the training. B. Training shall be conducted by classroom style or webinar, as agreed upon by MDOT. C. Training shall be provided to both MDOT staff and other agencies as deemed appropriate by MDOT. D. Training shall cover the use of all computer software and web-based applications. MDOT RESPONSIBILITIES: 1. Schedule and/or conduct the following: a. Project related meetings b. Stakeholder engagement meetings 2. Make decisions or provide input for the following items: a. Resolve issues related to funding b. Review and approve all budget and schedule aspects TRAFFIC CONTROL AND MDOT PERMITS N/A PROJECT MANAGEMENT: 1. This project will require close interaction and good communication between the Contractor and multiple MDOT staff. 2. If there are any major deviations from the original scope of this assignment, these changes must be documented and jointly approved by the Contractor and MDOT. 3. The selected Contractor shall provide all necessary project management services, including monthly and quarterly progress reports, and providing invoices in a timely manner. 4. Contractors should provide a description of their management team for this project and list all key personnel responsible for the deliveries of this RFP. STATUS REPORTS/ MEETINGS: 1. There shall be periodic, regular meetings between MDOT representatives and the selected Contractor to review work product and to communicate progress, issues, ideas, and expectations. 2. The Contractor will be responsible for scheduling, agenda creation, meeting minutes etc. 3. The Contractor shall provide copies of all project reports, correspondence, meeting announcements, and meeting minutes from all meeting attended, which shall be delivered by email to the MDOT Manager. These shall be distributed by email to the MDOT Project Manager. PROJECT DOCUMENTATION: All documentation and reports shall be delivered in the current version of Microsoft Excel, Microsoft Word or Adobe Acrobat (whichever applies) being used by MDOT. All documentation
Sample RFPs 91 delivered shall be clear, concise, complete, and in compliance with standards required by the MDOT Project Manager. CONTRACTOR PAYMENT â Unit Price: Compensation for this project shall be on a unit price basis. This basis of payment typically includes a maximum quantity of units and a maximum reimbursable cost per unit. All billings for services must be directed to the Department and follow the current guidelines. Payment may be delayed or decreased if the instructions are not followed. Payment to the Contractor for services rendered shall not exceed the maximum amount unless an increase is approved in accordance with the contract with the Contractor. Typically, billings must be submitted within 60 days after the completion of services for the current billing. The final billing must be received within 60 days of the completion of services. Refer to your contract for your specific contract terms. SCORING POINT ASSIGNMENT: Total Points = 130 Points Proposed Selection Criteria and Total Possible Points: Understanding of Service â 30 Points Describe your understanding of the service to be provided. Qualifications of Team â 40 Points Describe your team and the roles of key personnel. Provide resumes for key personnel. Past Performance â 20 Points Provide references and examples of similar work performed for other agencies. Location â 5 Points Indicate the percentage of work that will be performed in Michigan. Presentation â 20 Points Price â40 Points Formula: Low Bid/Bid * points assigned Completed bid sheet required.
92 Practices on Acquiring Proprietary Data for Transportation Applications BID SHEET Specialty Services for MDOT Real-time Traffic Data & Performance Analytics MDOT STATEWIDE PAYMENT ITEMS (All entries made on this page shall be handwritten in ink) Contract Year 1 ITEMS OF WORK UNIT QUANTITY PRICE/UNIT TOTAL PRICE 1 Real-time Traffic Data Month 12 2 Operate and Maintain TPMRAS Month 12 3 Enhancements* Dollar $50,000 Contract Year 2 ITEMS OF WORK UNIT QUANTITY PRICE/UNIT TOTAL PRICE 1 Real-time Traffic Data Month 12 2 Operate and Maintain TPMRAS Month 12 3 Enhancements* Dollar $50,000 Contract Year 3 ITEMS OF WORK UNIT QUANTITY PRICE/UNIT TOTAL PRICE 1 Real-time Traffic Data Month 12 2 Operate and Maintain TPMRAS Month 12 3 Enhancements* Dollar $50,000 CHECK UNIT PRICE COLUMN FOR OMISSIONS BEFORE ENTERING BID TOTAL *Not to exceed amounts. Payment to be made based on actual cost Bid Price for the above listed items and quantities: $___________________________ CONTRACTORâS NAME: ________________________________________________ CONTRACTOR'S SIGNATURE: __________________________________________ DATE: ___________________________
Sample RFPs 93 VALIDATION PROCESS AND PAYMENT PENALTIES In accordance with section 6.1 of the RFP, data validation is required and subsequently if the data requirements are not met then penalties will be assessed. The following section details how these penalties are accessed and the necessary actions that MDOT may take to provide the best possible traffic data for the State. Data validation shall be tested based on several components, each with their respective percentage. If the subscription data does not fall within the allotted limits of the ground truth validation data a percentage of the maximum award fee shall be withheld up to 100 percent of the maximum award fee for that component. Validation will be performed on the raw (non-smoothed) data provided by the Contractor. Award Fee Component: Max Reduction Actual Reduction 1. Data Availability < 99.5% 40 % % 2. Data Accuracy +/- 10 MPH 40 % % 3. Data Latency > 5 Minutes* 20 % % Total Reduction % Max Payment $ (from cost proposal) Actual Payment $ (max payment X total reduction) * A latency of 5 minutes or less is desired, however if the selected offer is only able to propose a maximum latency of 10 min, this payment structure shall be modified to not penalize a latency under 10 minutes. Data Availability: The Contractor is required to maintain overall data availability on a per monthly basis of 99.5 percent, which does not include any scheduled maintenance. If MDOT should receive 99.5 percent of all the data reports for a particular month the vendor shall be award the maximum allotted amount reserved for the data availability component. Should the Contractor report less than 99.5 percent of the total reports for that particular month the maximum monthly payment shall be reduced based on the following table. Percent Available Reduction 99.5 or greater 0 % 99.49 or less 40 % Data Accuracy: System accuracy shall be evaluated based on the average absolute speed error. Section 2.1 of the RFP requirements states that the average speed error shall be +/- 10 MPH within each of the three ranges of speeds. The calculation method for the average absolute error is as follows: Let: Aij = Speed data for link i at time j from the data service. Bij = Corresponding speed from the validation data Average Absolute Speed Error = mean(|Aij â Bij|)
94 Practices on Acquiring Proprietary Data for Transportation Applications Ground truth speed data shall be collected at various times on MDOT selected segments which shall coincide with the Contractorâs segment definitions. These segments will then be compared with the Contractors reported data to verify its accuracy. For all evaluation data the speeds shall be rounded to the nearest whole integer. The following table is provided as a guide for the evaluation process. Sample No. Date Day Time Length (mi) Route No. Limits Data Comparison (MPH) From To Contractor Data Validation Data Error 1 MM/DD/YY Mon 00:00 0 # A B 0 0 0 2 MM/DD/YY Mon 00:00 0 # B C 0 0 0 3 MM/DD/YY Mon 00:00 0 # C D 0 0 0 4 MM/DD/YY Mon 00:00 0 # D F 0 0 0 5 MM/DD/YY Mon 00:00 0 # F G 0 0 0 6 MM/DD/YY Mon 00:00 0 # G H 0 0 0 Average of the absolute values of the errors: Avg. Average Difference Reduction +/- 10 or less MPH 0 % +/- 10 or greater MPH 40 % In addition to ensuring the average reported data is with an acceptable range, anomalies may occur in the reported data. These will be defined as instances when errors exceed 20 MPH. These anomalies may not raise the average enough to be greater than +/- 10 MPH. However, when reporting travel times to the public it is imperative that these anomalies not be reported at all. Therefore if data anomalies of 20 MPH or greater are reported then a percent reduction off the maximum attainable amount is incurred. The penalty shall be assessed on a percent basis which the following table identifies. % Of Data Records with Absolute Error > 20 MPH Percent Reduction 0-5 % 5 % 5-10 % 10 % 10-20 % 20 % Greater than 20 % 40 % Data Latency: System latency shall be validated using the three speed buckets outlined in the requirements table. These speed buckets are as follows: of 0-30 MPH, 31-50 MPH and 51+ MPH. The determiner of latency will be the time it takes for the subscription data to recognize a change from one bucket to the next, as compared to ground truth data. The following table outlines the percent reduction off the maximum available payment for this component based on latency. Time Difference Percent Reduction 5 Minutes or less 0 % 5+ Minutes 20 % * - A latency of 5 minutes or less is desired, however if the selected offer is only able to propose a maximum latency of 10 min, this payment structure shall be modified to not penalize a latency under 10 minutes.
Sample RFPs 95 APPENDIX D2 OHIO DOT SPEED DATA RFP
96 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 97
98 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 99
100 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 101
102 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 103
104 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 105
106 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 107
108 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 109
110 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 111
112 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 113
114 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 115
116 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 117
118 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 119
120 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 121
122 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 123
124 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 125
126 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 127
128 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 129
130 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 131
132 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 133
134 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 135 APPENDIX D3 OHIO DOT OD DATA RFP
136 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 137
138 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 139
140 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 141
142 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 143
144 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 145
146 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 147
148 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 149
150 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 151
152 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 153
154 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 155
156 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 157
158 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 159
160 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 161
162 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 163
164 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 165
166 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 167
168 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 169 APPENDIX D4 ARIZONA DOT TRAFFIC DATA RFP
170 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 171
172 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 173
174 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 175
176 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 177
178 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 179
180 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 181
182 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 183
184 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 185
186 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 187
188 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 189
190 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 191
192 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 193
194 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 195
196 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 197
198 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 199
200 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 201
202 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 203
204 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 205
206 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 207
208 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 209
210 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 211
212 Practices on Acquiring Proprietary Data for Transportation Applications
Sample RFPs 213
