524-24_Bid_Document__1_.pdf
PDF 197 KB Posted
- Attached to
- Competitive Selection OH|DOT52424-1
- Contract number
- DOT52424-1
- Issued by
- Ohio
About this file
This document is a Request for Proposal (RFP) issued by the Ohio Department of Transportation (ODOT) for a USDOT SMART Grant project. The key stakeholders include ODOT, DriveOhio, ODOT's Office of Traffic Management, and American Honda Motor Company. The project is part of Phase 1 of a grant to develop two proof of concept solutions within ODOT's Event Streaming Platform (ESP), focusing on improving roadway safety through advanced data integration and analytics.
The primary objectives are to develop two technological solutions: 1) an incident detection and response system that automatically provides crash location and severity information to emergency responders using vehicle airbag deployment alerts, and 2) a crash prediction system that uses real-time and static roadway data to identify high-risk scenarios and provide proactive mitigation recommendations. The project will run from September 1, 2023, to January 31, 2025, with bi-weekly meetings and an agile development approach. Vendors will be evaluated on technical capabilities, including experience with artificial intelligence, machine learning, data analytics, and federal grant project management. The contract will be awarded based on a technical scoring system, with a minimum score of 710 points required, and the vendor offering the lowest cost per quality point will be recommended for contract award.
View the file
Other files
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
SECTION I. Development of Crash Detection and Prediction Proof of Concept Solutions
1.1 Overview
Background
The Ohio Department of Transportation has been developing the foundational elements for the Event Streaming Platform (ESP), with a goal of utilizing the newly available streaming data in combination with currently present static data, to create efficiencies throughout the department.
These efforts have led to the identification of several use cases throughout the department. In 2022, ODOT was awarded a Phase 1 USDOT SMART Grant to build two proof of concept solutions focused on two of those use cases, aimed at improving roadway safety. The two proof of concept solutions to be developed with SMART Grant funds shall provide the following:
1. Incident detection and response initiation: ODOT will receive air bag deployment alerts directly from vehicle manufacturers and automatically provide crash location and severity information to emergency responders. The automatic dissemination of this information seeks to hasten emergency response, particularly in rural areas with less camera coverage.
2. Crash prediction and proactive mitigation: Real-time and static roadway data, including speed, traffic volumes, weather, pavement conditions, workzones, average daily traffic volumes, transportation systems management and operations studies, etc., will be compared to historical data to identify scenarios that pose a higher probability of crashes occurring. The system will then provide mitigation recommendations to our Traffic Management Center operators to reduce the risk of crashes. For example, recommendations could include utilizing intelligent transportation systems (i.e., digital messages, ramp metering, lowering the speed limit) or pre-positioning law enforcement at identified high-risk locations.
ODOT’s ESP processes high volumes of real-time data streams from various sources in order to provide quick insights that can aid decision-making. The ESP was built with infrastructure as code (IaC) in mind. A functioning ESP environment can be built using Docker, Github, an AWS subscription, and a handful of commands. Developers can get to work immediately with all the required components installed in the docker container.
Applications in the ESP are built like any normal application with inputs, processing, and outputs. With no code, inputs can come from configurable connectors, IoT/Edge devices, and configurable REST APIs. Processing or data aggregation can be performed with KSQL for low code efforts, Kafka Streams using Java, or custom coding using any language. Outputs can be handled with no code using configurable connectors or REST APIs.
A key concept of the ESP is that there will be a marketplace or “shopping mall” of data sources. The ESP marketplace is where producers can publish/advertise their data sources and consumers can browse, discover, and subscribe to data sources or services with confidence that the protocols and technologies of those connectors and APIs are already supported in their ESP environment.
The Phase 1 SMART Grant intends to prototype concepts, build internal buy-in and partnerships with stakeholders, and report on results, to inform how these concepts may be scaled up. Phase 2 of the SMART Grant is yet to be awarded, however, it is intended to be the “Implementation Phase” of the grant, where the proof of concept solutions will be refined and developed for the production environment and utilized in ODOT operations.
Purpose
The purpose of this Request for Proposal is to solicit proposals from vendors, or teams of vendors, experienced in the following areas:
• Data integration within multiple environments.
• Kafka within the AWS cloud environment
• AWS cloud-based programming and design.
• Developing code-based data models to solve specific use cases.
The selected development team will work with the program management team to deliver functional proof of concept solutions for the two identified use cases within the ODOT Event Streaming Platform Environment. The development team will be expected to the program management team by providing relative technical content for the feasibility analysis and all reporting required by
ODOT/USDOT.
Objectives
Project objectives include but are not limited to:
• Design and develop the two pilot use cases. This includes review of the data flows, processing logic, and interfaces for each use case.
• Develop prototypes of the two pilot use cases. This includes implementing the design in a working system that can be tested and evaluated. The prototype should be designed with the concept to be easily integrated into the Event Streaming Platform (ESP) architecture in potential future phases. The ESP Architecture document is provided for review in Exhibit A.
• Test the prototypes of the two pilot use cases. This includes testing the functionality, performance, and scalability of the prototypes.
• Evaluate the prototypes of the two pilot use cases. This includes gathering feedback from stakeholders and making necessary improvements.
• Develop a plan for deploying the two pilot use cases to production. This includes identifying the necessary infrastructure and resources and developing a deployment schedule.
SECTION II. SCOPE OF WORK & SPECIFICATIONS OF DELIVERABLES
2.1 Scope of Work
Awardee will be responsible for the following phases of the grant project:
Creating a working prototype in addition to working with program management team to develop/deploy proof of concept solutions in accordance with ESP architecture and Project Implementation and Performance Metrics Plans.
Deliverables shall include:
1. Draft & Final Project Workplan: This document should outline the steps and timeline for completing the Proof of Concepts in coordination with the Program Management Team to allow delivery of the project reports in the required timeframe. It should also include a risk assessment.
2. Proof of Concept Delivery: All code and associated documentation shall be stored in a project specific Git-Hub account and the account admin access shall be granted to the Ohio Department of Transportation. Upon completion of the project the account shall be made public to the USDOT SMART Grant Office.
3. Proof of Concept Implementation and Testing: Selected Proposer shall assist ODOT ESP team in successfully implementing and testing the proof of concept solution and generate an output in the desired format determined during project proof of concept development.
4. Draft & Final Concept of Operations
Assist the Program Management Team by identifying any needed modifications/updates to the Project ConOps, including lessons learned during the proof of concept development and testing.
a. Detailed design specifications for the two pilot use cases.
b. Data requirements:
c. Performance Measures:
d. Testing plan:
e. A plan for monitoring and maintaining the pilot use cases.
5. Draft & Final Implementation Reports
Assist the Program Management Team in the development of the Project Implementation Report by providing lessons learned throughout proof of concept development and implementation within the ESP environment. Additionally assist the Program Management Team by providing information related to feasibility of deploying the technology selected in the development of the proof of concept solution.
6. Project Management:
At a minimum, bi-weekly meetings shall be held to ensure the project stays on task. It is expected that the delivery of project milestones be programmed using the agile method and the bi-weekly sprints be presented during those meetings.
7. Timeframe
The SMART Grant award commences on September 1, 2023. All deliverables must be completed, and the final report draft is due January 31, 2025.
8. Stakeholders:
a. ODOT Divisions of IT,
b. DriveOhio,
c. ODOT Office of Traffic Management, and
d. American Honda Motor Company.
SECTION III. VENDOR QUALIFICATIONS AND EXPERIENCE
3.1 Organizational Experience and Capabilities – vendors will be evaluated based on the following:
• Experience in conducting at least similar types of projects/programs within the past 5 years that demonstrate expertise in data integration.
• Name and contact information for leaders of those projects/programs (max 1 page resume per)
• Name(s) of any subcontractor(s) that will be involved in working with the vendor, and their experience/qualifications.
• Experience in projects involving data analytics and modeling.
• Experience in app development technologies
• Experience in leading projects involving development using Artificial Intelligence and/or
Machine Learning Technologies
3.23 Staff Experience and Capabilities – proposals should demonstrate significant expertise by assigning staff to key leadership roles. Proposals must include, at minimum:
• Identified staff, by name and position, who are considered key to the project/program’s success. Key staff includes, at Minimum, Project Manager, Business Analyst, Tech lead/Lead developer, GIS SME, DBA, etc.
• Resumes/curriculum vitae of those key staff that describe appropriate education, experience and expertise needed for the project/program – 1 Page Max per
Sensitive Personal Information: It is the sole responsibility of the vendor submitting a proposal to remove all personal confidential information (such as home addresses and social security numbers) of vendor staff and/or of any subcontractor and subcontractor staff from resumes or any other part of the proposal package.
Following submission to ODOT, all proposals submitted may become part of the public record. ODOT reserves the right to disqualify any vendor whose proposal is found to contain such prohibited personal information.
Technical Proposal Score Sheet
Scoring of Technical Proposal
Technical Proposals will be collectively scored by a Proposal Review Team (PRT) appointed by ODOT. For each of the evaluation criteria given in the score sheet, reviewers will collectively judge whether the technical proposal does not meet, partially meets, meets or exceeds each criterion, and assign the appropriate point value. The scoring is by consensus and one official score sheet will be completed for each technical proposal that is scored.
Criteria for Considering the Cost Proposal
The cost proposal will be reviewed by the PRT. The grand total of the vendor’s cost proposal will be divided by that vendor’s final technical proposal score. This compares the cost with the quality of the technical proposal, which will provide an average cost-per-quality point earned on the technical proposal.
ODOT may, at its sole discretion, negotiate with all technically qualifying vendors for a revised cost proposal. Vendors may then: 1) Submit one last and best offer; 2) request that ODOT view its original cost proposal as its last and best offer; or 3) May formally withdraw from further consideration. The vendor shall formally indicate its choice according to directions provided by ODOT at that time. Upon receipt of all last and best offers, ODOT will then consider those vendors’ revised cost proposals.
PHASE I: Criteria for Scoring of Technical Proposal
Qualifying technical proposals will be collectively scored by a Proposal Review Team (PRT) appointed by ODOT. For each of the evaluation criteria given in the following score sheet, reviewers will collectively judge whether the technical proposal exceeds, meets, partially meets or does not meet the requirements expressed in the RFP, and assign the appropriate point value, as follows:
0 6 8 10 Does Not Meet Requirement
Partially Meets Requirement
Meets Requirement
Exceeds Requirement
Technical Performance Scoring Definitions:
“Does Not Meet Requirement”- A particular RFP requirement was not addressed in the vendor’s proposal, Score: 0
“Partially Meets Requirement”-Vendor proposal demonstrates some attempt at meeting a particular RFP requirement, but that attempt falls below acceptable level, Score: 6
“Meets Requirement”-Vendor proposal fulfills a particular RFP requirement in all material respects, potentially with only minor, non-substantial deviation, Score: 8
“Exceeds Requirement”-Vendor proposal fulfills a particular RFP requirement in all material respects, and offers some additional level of quality in excess of ODOT expectations, Score: 10
A technical proposal’s total PHASE II score will be the sum of the point value for all the evaluation criteria.
The review team will collectively score each individual qualifying proposal. Technical proposals which do not meet or exceed a total score of at least 710 points (a score which represents that the selected vendor has the capability to successfully perform the project/program services) out of a maximum of 1000 points, will be disqualified from further consideration, and its cost proposal will neither be opened nor considered.
Only those vendors whose Technical Proposals meet or exceed the minimum required technical points will advance to PHASE III of the technical proposal score sheet.
ITEM
EVALUATION CRITERIA Weighting Doesn’t Meet
Partially Meets
Meets
Exceeds
WORK REQUIREMENTS
1 Technical approach and schedule 20
2 Project manager, team and availability 20
Respondents experience with using Artificial Intelligence and/or Machine Learning
Respondents experience with State DOT or other interagency data / development integrations
Respondents experience working on, managing, and reporting on Federal Grant Projects
Respondents experience using data analytics to address real-world challenges
Column Subtotal of "Partially Meets" points Column Subtotal of "Meets" points Column Subtotal of "Exceeds" points
GRAND TOTAL SCORE:
Based upon the Grand Total Technical Score earned, does the vendor’s proposal meet or exceed the minimum Technical score of 710 points?
Yes__________ No_____________ (If “No” vendor’s Cost Proposal will NOT be opened)
Cost Per Quality Point
Vendors Total Submitted Cost: ________________ / Grand Total Technical Score: ______________
Cost per Quality Point: _______________
The Technical Proposal with the lowest Cost per Quality point will be recommended for contingent award of the contract.
If ODOT finds that one or more Proposals should be given further consideration, ODOT may select one or more of the highest-ranking Proposals to be short-listed and will move on to an interview phase. ODOT may alternatively choose to bypass any or all subsequent phases and make an award based solely on the Proposal evaluation phase.
File details come from the government source that posted it. Updated .