07 - Statement of Objectives - Cooperative Perception- Solicitation.pdf

Office of Acquisitions and Grants Management

Broad Agency Announcement (BAA)

693JJ3-24-BAA-0004

Topic: Advancing Cooperative Perception in Transportation Applications Toward

Deployment

Table of Contents

I. GENERAL INFORMATION

1. Summary of Important Dates

2. Proposal Submission

3. Funding Note

II. STATEMENT OF OBJECTIVES (SOO)

1. Purpose

2. Program Mission

3. Period of Performance

4. Background

5. BAA Objectives

A. General Requirements

B. Technical Objectives

III. ADMINISTRATIVE INFORMATION

IV. EVALUATION CRITERIA

V. PROPOSAL FORMAT AND CONTENT

1. Detailed Proposal Instructions

2. Proposal Format

3. Cover Pages and Tables of Contents

4. Proposal Requirements for Volume 1: Technical

5. Proposal Requirements for Volume 2: Cost

VI. OTHER ADMINISTRATIVE INFORMATION

VII. AWARD SELECTION

I. GENERAL INFORMATION

This solicitation is being conducted via a Broad Agency Announcement (BAA) per FAR

35.016 Broad Agency Announcement.

Contracting Officer: James Mikell, FHWA, james.mikell@dot.gov

Contracting Specialist: Okpemitoritse (Torishay) Onuwaje, FHWA, o.onuwaje@dot.gov

Contract Types: The Offeror may propose a Firm Fixed Price, Cost Reimbursement, or a

Time and Materials contract.

1. Summary of Important Dates

The Federal Highway Administration anticipates that the proposal, evaluation, and award process for this Broad Agency Announcement will generally proceed per the following schedule:

Question Period Closes September 27, 2024

Proposals Due 1:00 pm EST October 24, 2024

Anticipated Award Dates: November 22, 2024

2. Proposal Submission

Electronic transmissions of the proposal must be sent to HCFA-23SRI@dot.gov and the

Contract Specialist (CS), o.onuwaje@dot.gov, no later than 1:00 p.m., EST, on October

24,2024. Submissions received after this date and time will not be considered.

The proposal transmission must be titled in the following format:

Topic – Advancing Cooperative Perception in Transportation Applications Toward

Deployment

3. Funding Note

Funding in the amount of $2.5 million for all awards under this Broad Agency Announcement is available. FHWA anticipates that one to three contracts may be awarded.

II. STATEMENT OF OBJECTIVES (SOO)

1. Purpose

The U.S. Department of Transportation (U.S. DOT) / Federal Highway Administration (FHWA) is issuing this Broad Agency Announcement (BAA) to procure cooperative perception (CP) models and technologies that will support the ability of Advanced Driver Assistance mailto:james.mikell@dot.gov mailto:o.onuwaje@dot.gov mailto:HCFA-23SRI@dot.gov mailto:o.onuwaje@dot.gov

Systems (ADAS)1 or Automated Driving Systems (ADS) to navigate safely and efficiently and accelerate deployment. In the context of surface transportation, CP can be loosely defined as the action of an agent (e.g., infrastructure or a vehicle) making sense of the environment around it by, at least in part, relying on wireless communication messages received from other agents (e.g., other infrastructure or other vehicles). By engaging in CP, the agent may improve its situational awareness compared to merely relying on its onboard sensors and, therefore, be better able to ensure its surrounding environment's safety and operational efficiency.2 Since 2020, research and investment in the field of CP has increased. However, many questions still need to be addressed before deployment. Therefore, this BAA will endeavor to bring the CP technology closer to deployment by:

1. Developing a prototype CP system that the Offeror will demonstrate on a closed test track(s) and answering several other relevant technical questions (see section II.5

“BAA Objectives” below) necessary for the prototype's reliable performance. The CP prototype will have both an infrastructure and a vehicle component.

2. Bringing together infrastructure owner-operator (IOO) / industry/technology experts to provide technological/architectural design and usability input, ensuring alignment with real-world deployment requirements. Additionally, engaging with stakeholders, including potential end-users, to gather insights into usability and practical application needs, enhancing the CP system's effectiveness and user acceptance.

3. Quantifying the impact of CP technology on the surface transportation network in terms of safety, mobility, and the economy to justify continued investment.

4. Ensuring the prototype CP system's interoperability with other CP systems in terms of being able to send, receive, and interpret relevant messages correctly.

5. Executing technology transfer activities before the completion of the project to ensure that IOOs and industries that could benefit from the research findings and tools from this project can do so.

As a result of this BAA, fueled and inspired by #3 in the list above (which will provide the business case for the technology), IOOs and industry will be able to use the prototype and add their private modifications, as necessary (while making sure they maintain interoperability), and begin testing with other potential deployers. This would first happen on closed test tracks, and when the technology is ready, IOOs and industry will move to public roads. In addition, lessons learned and data collected will be shared with relevant stakeholders, including Standard

Development Organizations (SDOs), to aid in refining and improving standards to support deployment.

Note to Offerors that may be involved with the USDOT-sponsored Intersection Safety Challenge

(ISC): This BAA is in no way meant to infringe on the work of the ISC and vice versa. In contrast to the ISC, this approach focuses solely on enabling cooperative perception (as opposed

1 Although an L0 system can have ADAS functionalities (e.g., automatic emergency braking [AEB]), this BAA will focus on L1+ systems.

2 Although a CP agent is generally either a vehicle or an infrastructure component, it is also possible that a human driver can be included in the scope of the vehicle agent where a vehicle would receive a message and process it to give the human driver a notification about a potential upcoming conflict. However, this will not be the focus of this

BAA.

to other methods that could be used to make the surface transportation system safer), desires to consider scenarios with and without vulnerable road users (VRUs), and requires a minimum of

L1 automation. In addition, while the ISC focuses on intersections, Offerors may propose scenarios on any part of the surface transportation system. The Offerors are permitted to use any data or knowledge publicly available through the ISC for this work, although it is not obligatory.

2. Program Mission

The FHWA Cooperative Driving Automation (CDA) Program seeks to lead research, development, and standardization to demonstrate CDA technologies' benefits and accelerate industry deployment. The work performed under this BAA will contribute to this mission by (1) developing a CP prototype with other related technologies, (2) engaging IOOs and industry to ensure that the approach and the technologies being developed are conducive to deployment, and handing them off to IOOs and industry by the end of the project via technology transfer, and

(3) conducting analysis to predict the system impacts of the developed technologies. These three contributions to the program are further described in section II.5 “BAA Objectives” below.

3. Period of Performance

Depending on the scope of the proposed effort, FHWA anticipates a performance period of no more than 36 months. The period of performance must include time for the final project report to be published by the FHWA which typically takes about 6 months from the time the final project report is submitted.

4. Background

The FHWA CDA Program desires to enable a cooperative, safe, efficient, and sustainable surface transportation system for all users. It develops proof-of-concept (POC) technologies, allowing CDA use cases. Then, it endeavors to pass these use cases on to IOOs and the industry via technology transfer activities to support deployment efforts. To that end, the program has completed over a dozen POC use cases through partnerships with the ITSJPO, FMCSA, FTA, and MARAD.

One particular use case that has drawn considerable attention is CP. CP has the potential to drastically improve both individual and system safety by enabling vehicles with communication capabilities to enhance their situational awareness. This technology can also improve mobility, as cars can plan their trajectories more efficiently by knowing what is beyond their sensors' direct line of sight.

Thus far, most of the program efforts in CP have been conducted in simulation. At the same time, many other institutions have also increased their research and investment in CP technology.

Therefore, this BAA endeavors to select one to three Offerors to develop “an IOO and industry-approved” prototype of the CP technology that will be tested and demonstrated on closed test tracks.

Note that “IOO and industry approved” means that IOO and industry stakeholders have been engaged throughout the project to ensure the approach is conducive to deployment.

5. BAA Objectives

This section notes the general requirements and the technical objectives.

A. General Requirements

1. The Offeror must provide personnel with the demonstrable skill and experience necessary to successfully complete all the selected technical objectives.

2. The Offeror must provide/procure all necessary software, hardware (including vehicles and sensors), test equipment, access to test facilities, automatic data processing equipment/software, documentation, and all other tools and supplies necessary to complete all the selected technical objectives.

3. The Offeror must assemble a team of multiple organizations (if necessary) to assist in performing the BAA as subcontractors.

4. The Offeror must assemble a Steering Committee or an Advisory Board consisting of at least one vehicle OEM expert, one IOO expert, and one ITS expert. Multiple experts from each of the three categories (especially from the first category) are encouraged, as they will advise the team whether their approaches are conducive to real-world deployment. Other experts from adjacent domains are also encouraged. Note that the

Steering Committee / Advisory Board members do not need to be official team members

(but they may be) as long as they can attend regular Committee/Board meetings (e.g., monthly) to provide their input.

5. The Offeror must execute technology transfer activities to ensure that relevant stakeholders can benefit from the research findings and tools developed in this project to support deployment. This is a crucial step and one of the key outcomes of this BAA, as the FHWA envisions that IOOs and the industry will use the results to host future pilots that involve CP. The Offer must propose specific technology transfer activities that will be performed, such as standard development organization (SDO) engagement, peer exchanges, webinars, and demonstrations.

6. The Offeror should solicit feedback from potential end-users (e.g., travelers or IOOs) to ensure that real-world pain points are being addressed as necessary. This is particularly important for travelers if the Offeror chooses to work with an L1/L2 system. Still, it may also be required if the Offeror decides to work with an L3+ system (see Technical

Objective #1 for more information on the levels of automation requirement).

7. The Offeror must ensure that the FHWA Public Affairs team approves all applicable deliverables (e.g., reports, peer reviewed journal publications, promotional materials, etc.) for public dissemination.

8. The Offeror must execute standard project management practices to ensure (1) the project stays on schedule and budget, (2) the artifacts produced are high quality, and (3) the

FHWA management is up to date on the project progress. Examples of these practices include the list below:

a. Creating a Project Management Plan (PMP) that includes a Work Breakdown

Structure (WBS) and a project schedule to be submitted within 30 days of the beginning of the period of performance. Any changes to deliverable due dates after the initial project schedule baseline must be approved by the Government.

b. Submitting a monthly progress report no later than 15 calendar days after the end of the month being reported on in the format specified by the Contracting

Officer’s Representative (COR). The progress report must describe work completed during the period, anticipated work for the following period, problems/risks encountered or anticipated and their contingency plans, and the updated schedule and budget, if applicable.

c. Conducting biweekly meetings with the COR to update on project progress.

d. Managing a Risk Management Register.

e. Ensuring a submittal of a final project report (to be published by the FHWA or

ITS JPO) and a final project briefing.

9. The Offeror must coordinate with the selected European Commission project(s) (likely two) that will address “AI for advanced and collective perception and decision making for CCAM applications.”3 The Offeror shall conduct two webinars per year to exchange information about their US-based project and learn about results from the

European-based project(s). The Offeror shall visit Europe, once per year, to engage in an in-person meeting with the selected European project(s).

B. Technical Objectives

In addition to the general requirements, a number of technical objectives related to the current

CP methodologies need to be addressed to realize progress towards deployment. Thus, the list below provides CP-related technical objectives that should be addressed by Offerors for this

BAA.

All Offerors must propose on technical objectives 1 through 3. Technical objectives 4 through 8 are optional.

These objectives are written to develop a reliable prototype that can be passed on to IOOs and the industry for eventual pilots and deployment. For each selected objective, the Offeror must, at minimum, (1) propose an approach, (2) justify why the approach would be technically successful and why it would be conducive to deployment, (3) the criteria by which success of the approach will be measured, (4) the budget and schedule of the proposed approach, (5) any risks associated with the proposed approach and (6) contingency plans of those risks.

1. Develop a prototype CP system (i.e., tested on actual infrastructure and actual vehicles)

A prototype system of CP, including a minimum of one L1+ vehicle and one connected/cooperative infrastructure component participating in CP (e.g., a LiDAR installed at an intersection), must be developed. Higher levels of automation, a greater number of vehicles, and a greater numbers of infrastructure components participating in CP are encouraged.

3 See pages 491 through 494 here: wp-8-climate-energy-and-mobility_horizon-2023-2024_en.pdf (europa.eu) https://ec.europa.eu/info/funding-tenders/opportunities/docs/2021-2027/horizon/wp-call/2023-2024/wp-8-climate-energy-and-mobility_horizon-2023-2024_en.pdf

To the extent possible (regarding time, budget, and feasibility), functional safety analysis should be completed based on the principles of ISO 26262 and the Safety of the Intended

Functionality (SOTIF) ISO/PAS 21448. The resultant functional safety concept and SOTIF mitigations should be implemented in the prototype. The functional safety analysis, including the functional safety concept and SOTIF mitigations, will be shared with IOOs and the industry.

At least one of the scenarios on which the CP technology will be tested must involve one or more VRUs. Also, at least one other scenario must not involve VRUs. More scenarios in terms of count and variability are also encouraged.4. For example:

1. Using CP to respond to potential red-light violators proactively.

2. Using CP to navigate difficult geometric conditions that may affect line-of-sight.

3. Using CP to inform vehicles about VRUs at mid-block crossings or intersections, VRUs jaywalking, VRUs occluded by large vehicles (e.g., buses), and VRUs sharing the right-of-way with cars.

4. Using CP to inform vehicles about wrong-way driving.

5. Using CP to inform vehicles about a foreign object in the roadway.

6. Using CP to inform vehicles about a sudden braking event downstream by a non-connected agent.

7. Using CP to assist with passing maneuvers (e.g., safely and legally moving past a vehicle in front when there is only one lane in each direction) or merging maneuvers.

8. Using CP to assist in adverse weather limiting line-of-sight.

9. Using CP to assist vehicles in navigating work zones.

10. Using CP to ensure safety during emergency events, including providing the safety of first responders.

Note that the list above is just examples and by no means requires the Offeror to address each of scenario or prevents the Offeror from proposing other potential scenarios, as long as at least one scenario involves VRUs and at least one other scenario does not involve VRUs.

Also note that for scenarios involving human pedestrians, it is assumed that testing will be completed with pedestrian dummies instead of human pedestrians.

Comprehensive testing is critical to demonstrating the prototype's performance. To truly understand the performance of the developed systems, they may undergo thorough software-in-the-loop simulation testing followed by live testing (i.e., closed test tracks). The simulation and live testing should include functional safety testing to the extent possible.

As mentioned above, tests can be performed on any L1 through L5 vehicle. At least one vehicle in each test must modify one or more planned maneuvers based on the received CP message. In the case of cars with lower levels of automation, response to CP messages may be done, for example, simply by safely slowing down (in the case of longitudinal control only). In the case of higher levels of automation, a lane change (if necessary) and a

4 While this BAA may "encourage" specific project activities or approaches, Offerors should carefully consider the opportunity costs of choosing these options over others. For example, in this case, the Offeror should consider whether there would be greater value in doing just two scenarios in greater depth or doing more scenarios in less depth.

slowdown may be appropriate. Note that more advanced maneuvers in response to the CP messages are covered in Technical Objective #6. The testing should cover the functional safety mechanisms and safe states through fault injection to the extent possible.

The prototype system must use SAE J3224 SDSMs or another standard message type recommended broadly by the industry and the Steering Committee / Advisory Board.

At a minimum, vehicles will use cooperative perception messages received from infrastructure (I2V, one-directional, being sent out by infrastructure and received by vehicles). In addition, assuming concurrence from IOOs and the industry regarding feasibility, the cooperative perception prototype must also include vehicle-to-infrastructure

(V2I) and vehicle-to-vehicle (V2V) communication. If the Steering Committee / Advisory

Board advises that V2I or V2V is not conducive to deployment, then the prototype must be

I2V only.

The prototype development process must engage IOOs and industry throughout the project, especially early on (primarily through the Steering Committee / Advisory Board, but other engagement is encouraged when necessary). This is crucial to ensure that the technology being developed is on the shortest path to safe and effective deployment. The development process may also engage other stakeholders (e.g., end-users) to gather insights into usability and practical application needs.

The Offeror must plan to demonstrate the developed prototype in at least one scenario at the

Turner-Fairbank Highway Research Center in McLean, VA. The prototype may also be demonstrated in other closed test track locations.

The developed prototype may use proprietary products produced outside of this BAA. Still, the Government prefers that all products and documentation (including systems engineering documentation, source code, and code documentation) developed within the BAA be government-owned, open-source, and published on a commonly used software development platform5. In cases where it is not possible to make everything developed within the BAA open-source, the Offeror must clearly communicate what will/will not be open-source in the proposal. In addition, any datasets generated from this project must be uploaded to a public-facing repository (e.g., ITSDataHub). This applies to this technical objective and all subsequent technical objectives.

2. Quantify the transportation system impacts of a CP system.

The transportation system impacts of CP in terms of safety must be quantified (as opposed to the base case of no CP); this will help to justify a continued investment into this technology and a continued push for deployment.

5 The purpose of this is to (1) encourage and support further research by entities not involved in the BAA and to (2) provide a prototype system on top of which IOOs and industry can make their own proprietary modifications, as necessary, to reach eventual deployment.

This analysis must also consider the safety impact on individual vehicles (e.g., a car equipped with cooperative perception is X times less likely to be in a crash than an identical vehicle without cooperative perception, all other things being equal); the safety impact on individual vehicles will help justify investment into the technology from vehicle OEMs.

The quantification of system impacts in terms of mobility, and the economy is also encouraged but not required.

The analysis should account for various market penetration rates, various communication network demands (assuming C-V2X or another viable communication solution broadly accepted by the industry), and various traffic demand levels. The Offeror must consider the spectrum requirements in this analysis and note what those requirements are. In the proposal, the Offeror must clearly state what types of performance metrics must be studied; the Offeror may consider traditional safety measures, surrogate safety measures, or a combination of the two.

Suppose the Offeror proposes working on any optional objectives from below (i.e., Technical

Objectives #4 through 8). In that case, the analysis conducted for this objective should consider how/whether the work under each objective may further impact the system.

3. Demonstrate interoperability of the prototype CP system with others in the CP field

Regarding the prototype CP system developed under Technical Objective #1, interoperability with other entities engaging in CP-related work must be demonstrated in simulation or natural systems (or both). Of primary importance will be showing that the CP safety critical messages (e.g., SAE J3224 SDSMs) being sent out by one team can be received, processed, and appropriately acted upon by another team, and vice versa.

The Offeror is encouraged to consider multiple external teams with whom to partner for interoperability testing, but at least one is required. In the proposal, it is not a requirement that the Offeror already identify these external team(s).

The Offeror may use VOICES to demonstrate interoperability or propose a different approach.

To accelerate deployment, lessons learned throughout the development process (e.g., during interoperability-related activities) must be shared with SDOs or similar.

4. Ensure spatial and temporal synchronization of the prototype CP system (optional)

The prototype CP system developed in Technical Objective #1 must ensure spatial and temporal synchronization among the different agents involved in CP (to ensure accuracy and continuity). Problems can be caused by factors such as windy conditions swaying the infrastructure on which sensors assisting in cooperative perception are installed (e.g., traffic https://www.transportation.gov/hasscoe/voices signal pole) and a lack of temporal synchronization between the various CP agents, which may include varying output frequencies.

Infrastructure CP agents may need embedded algorithms to enable automatic self-calibration depending on current external factors (e.g., swaying due to wind) to address this need. In addition, all agents (i.e., both infrastructure and vehicles) may need embedded adaptive algorithms that can efficiently fuse data from other agents with varying computational capabilities and data transmission and receiving capabilities (this may involve fusing somewhat “stale” data).

5. Communicate only necessary information (optional)

The prototype CP system developed in Technical Objective #1 must include the capability to automatically determine which agents should communicate at any one time (and which should not) and what information they should be communicating. What can be done to avoid unnecessary duplication of the objects reported to the communication network (note that some redundancy may be desirable, based on feedback from IOOs and industry)?

This contrasts with most current approaches to CP, which may involve all agents within the communication range broadcasting all detected objects. This mechanism can lead to the waste of computational resources and the congestion of the communication network.

Therefore, under this objective, algorithms should be embedded in each agent responsible for determining when and what to communicate (e.g., a decision tree to help prioritize the information that would be broadcast).

Note that the approach used in this objective must be conducive to deployment based on feedback from IOOs and the industry. Therefore, the approach should most likely be broadcast-based, as opposed to point-to-point communication.

6. Improve the ADAS or ADS decision-making and motion-planning processes based on input from CP (optional)

CP can have significant implications at a vehicle's strategic and tactical levels, influencing decision-making and motion-planning processes. Therefore, in Technical Objective #1, improvements will be made to the downstream modules of the ADS and ADAS vehicles that are a part of the CP system (i.e., modules onboard the ADS and ADAS vehicles that would take as input the output of the CP module). However, in Technical Objective #1, the expectation is that these downstream modules would lead to simple maneuvers such as decelerations and lane changes. In this objective, the expectation is for the Offeror to demonstrate innovation by increasing the complexity of the resulting maneuvers (e.g., two or more vehicles are involved where they have to coordinate their response to the CP event to ensure that they neither collide with the object reported through the CP system nor with each other).

It is imperative to note that the vision for CP is not for infrastructure or any other foreign agent to directly control the vehicle (i.e., the infrastructure or any other foreign agent does not have direct control over the response of individual agents). Instead, the vision for CP is merely to provide additional information to connected agents in the surface transportation system, to increase situational awareness, and to allow them to determine the best response.

Connected agents may choose to coordinate with each other to decide on the best response willingly. Still, they will never cede control to other agents; ultimately, their response will always be their responsibility.

As part of the proposal, the Offeror must explain the improvements to be made, note the high-level scenarios in which these improvements may be demonstrated, and explain how the improvements will be measured compared to the base case, which would not have these improvements.

7. Improve the prototype CP system through the use of multiple sensor types

(optional)

Most current approaches to CP rely on LiDAR as they may offer high-resolution measurements, even potentially for distant objects. However, LiDAR-based solutions have limitations, especially in adverse weather conditions. Cameras provide rich visual data but are sensitive to lighting changes, and radars excel in poor visibility conditions but have limited ability to provide detailed object recognition and classification.

In this objective, the prototype CP system developed in Technical Objective #1 must include a comprehensive solution that integrates LiDAR(s), camera(s), and radar(s), thereby combining their strengths to compensate for individual limitations and ensuring consistent and accurate CP in all weather and lighting scenarios.

The Offeror must, as part of the proposal, clearly explain (1) whether this improved solution will be hosted on just infrastructure or both infrastructure and vehicles and (2) whether each of the sensors that will be integrated will work in isolation or whether they will be fused for object detection and tracking, thereby producing even more accurate results.

8. Predict the future trajectories of non-connected agents and incorporate them into the messages within the prototype CP system (optional)

The prototype CP system developed in Technical Objective #1 must communicate the current status of detected objects and be enhanced to predict and communicate the future trajectories of the entities not sharing their own planned trajectories. For example, this might imply sending an array of [x, y, z, t] coordinates for each non-connected agent where each coordinate [x, y, z] is a prediction of where the non-connected agent will be at time t over the next few seconds based on the non-connected agent’s historical (i.e., past) trajectory. The predicted trajectories would also likely come with confidence intervals. This will assist in identifying potential conflicts and planning one’s own trajectories that are more efficient in mobility and energy use.

Any required changes to standard message sets would have to be clearly documented;

interoperability may not be lost with agents who would not use these potentially updated message sets.

If the Offeror pursues Technical Objective #5, the Offeror may consider developing protocols to determine whether all agents participating in CP must communicate this information or only a subset (e.g., infrastructure only).

III. ADMINISTRATIVE INFORMATION

Offerors are required to follow the guidance contained herein. The following sections provide information on the evaluation criteria, the proposal format and required content, and other general information. Proposals not meeting the format described in this BAA will not be reviewed.

All administrative correspondence or questions on this BAA should be directed to the CS at the following email address: o.onuwaje@dot.gov and HCFA-23SRI@dot.gov.

The CS is this acquisition's exclusive point of contact. Address any questions or concerns you may have to the CS. Written requests for clarification shall be submitted using the Questions

Template (Attachment 1) and sent to the CS. Questions or requests for clarification must be submitted on or before September 27, 2024. The BAA must take precedence in the conflict between the answer to questions and the BAA. Please be advised that the Government will be posting the questions and responses to all the questions received. Questions must contain the

BAA number and Topic. Please e-mail all questions to o.onuwaje@dot.gov and HCFA-

23SRI@dot.gov.

IV. EVALUATION CRITERIA

The FHWA may select approximately one to three proposals for award. Offerors that propose on optional tasks may be rated higher.

The primary basis for selecting proposals will be Technical Merit and the availability of funds.

Cost reasonableness, realism, and value to the Government shall also be considered to the extent appropriate. Individual proposal evaluations will be based on acceptability or non-acceptability without regard to other proposals submitted under the announcement. Note that not all technically meritorious proposals may be funded due to budgetary constraints.

Technical Merit will be evaluated based on the following criteria, listed in descending order of relative importance:

1. Technical Approach:

A. The proposed technical approach for the CP prototype is conducive to successful real-world deployment and aligns with the BAA requirements and objectives mailto:o.onuwaje@dot.gov mailto:HCFA-23SRI@dot.gov mailto:o.onuwaje@dot.gov listed in sections II.5.A and II.5.B and supports the CDA program mission described in section II.2.

B. The proposal demonstrates a reliable plan for soliciting feedback from relevant stakeholders, including IOOs and industry experts, to enhance the technical approach.

C. The proposed technical solutions are realistic and feasible within time and budget constraints, supported by evidence and expertise.

D. The proposal offers effective metrics to evaluate each technical objective's success.

E. The proposal demonstrates innovative and creative approaches to addressing project challenges and achieving objectives.

2. Ability of the Performing Team: The proposing team demonstrates the qualifications, experience, and capacity to complete all technical work within the proposed timeframe and budget.

3. Risk Management: The proposal demonstrates that the proposing team understands the technical, financial, and organizational risks likely to be encountered and knows how to manage and mitigate them.

In addition to the Technical Merit, the Cost and the Small Business Subcontracting Plan will also be evaluated:

1. Cost: Fund availability will be considered in the ultimate award decision. Cost reasonableness, realism, and value to the Government will only be considered on the highest rated technical proposals. Cost will be considered in the ultimate award decision, as the Government may elect not to award to a proposal if the Contracting Officer is unable to determine that the costs are realistic and reasonable or if it is determined that there is not enough value to the Government.

2. Small Business Subcontracting Plan: The Small Business Subcontracting Plan will be evaluated for those that are selected for award. Proposals submitted from other than small businesses that exceed $750,000 in total value must include a Small Business

Subcontracting Plan in accordance with the Federal Acquisition Regulation Part 19.7.

Each prime Offeror who is other than a small business must include within its proposal a complete copy of the prime Offeror’s Small Business Subcontracting Plan, satisfactorily addressing all the administrative requirements set forth in FAR section 52.219-9. The

Offeror must also submit a subcontracting plan in accordance with the instructions/format in Appendix C - Small Business Subcontracting Plan (Attachment 2) to this BAA. In the event that the Offeror has no such plan, the form must be submitted with “no plan identified” indicated on the form as applicable and the Offeror must submit a statement of circumstances supporting that determination. The Small Business Subcontracting Plan will be rated on a pass/fail basis.

V. PROPOSAL FORMAT AND CONTENT

The Offeror must submit the proposal separated into the following volumes:

1. Volume 1: Technical

2. Volume 2: Cost

1. Detailed Proposal Instructions

The Offeror’s complete proposal (consisting of the Technical and Cost Volumes) will be evaluated per the evaluation criteria of this solicitation.

The following detailed proposal instructions ensure a consistent and precise description of the

Offeror’s approach and the associated price. The Offeror must include the volumes noted above.

2. Proposal Format

There is a 25 page limit on Volume 1: Technical and no limit on the number of pages for

Volume 2: Cost. Any pages over the page limit specified will not be evaluated. All documentation submitted must be in any font, point size 12, single-spaced, 8.5x11 inch paper.

The cover page, the table of contents, the proposed statement of work, and resumes are excluded from the page limitations of Volume 1: Technical. However, resumes must be at most two pages each.

Proposals must set forth full, accurate, and complete information as required by this solicitation.

The penalty for making false statements is prescribed in 18 USC 1001.

3. Cover Pages and Tables of Contents

The Offeror must provide a Cover Page in each Volume. The Cover Page will include the following information:

A. Working title of the proposed project

B. BAA Research Topic Title and reference call number

C. Whether it is Volume 1: Technical or Volume 2: Cost

D. Company name

E. Name and title of the point of contact (POC) authorized to negotiate on behalf of the Offeror’s organization.

F. Telephone number, email address, and mailing address of the POC.

G. Names, titles, email addresses, and telephone numbers of other POCs that the

Government may contact if clarification of responses is needed.

The Offeror must provide a Table of Contents in each Volume; these pages will not be counted against the page limit.

4. Proposal Requirements for Volume 1: Technical

In addition to providing sufficient information to allow for the evaluation of the three Technical

Merit criteria listen in section IV (i.e., Technical Approach, Ability of the Performing Team, and

Risk Management), the Offerors must provide the following:

A. Titles and duties of all key personnel

B. A Level of Effort Table (table displaying labor categories and the number of hours per task).

C. A separate section containing the proposed statement of work. The statement of work must include separate tasks for each required objective and each optional objective selected by the Offerors (if any).

D. Any other information that the Offeror wishes to bring to the Government's attention.

5. Proposal Requirements for Volume 2: Cost

General Requirements

The Offeror may propose a Firm Fixed Price, Cost Reimbursement, or a Time and Materials proposal. Please note that for cost type contracts, the Offeror must have an acceptable accounting system for cost type Government contracts. An Offeror without an approved accounting system should consider submitting a Firm Fixed Price or Time and Material price proposal. The Offeror shall provide Volume II of its formal Proposal organized by the following sections:

A. Cover Page

B. Cost/Price Information

C. Other Financial/Organizational Information

D. Small Business Subcontracting Plan (required for proposals of $750,000 or more)

E. Recommended Pricing Arrangement

F. Patent and Data Rights

Cover Page

The cover page for the cost and pricing Proposal must include:

A. Working title of the proposed project

B. BAA Research Topic title and reference call number

C. “Cost/Price Proposal” written below the project title

D. Names, phone numbers, mailing address, and e-mail addresses for the principal technical and contractual points of contact (person or persons authorized to negotiate on behalf of the Offeror and who can contractually obligate the

Offeror’s organization)

Cost/Price Information

Offerors shall provide detailed cost/price information. Offerors shall present cost/price information using the Firm Fixed Price, Cost Reimbursement or Time-and- Materials workbooks in Appendix B – Cost/Price Proposal Models. Offerors’ cost/price information shall include the total costs for the proposed period of performance. The detailed cost and price information in the

Contract cost/price proposal must also include a separate breakdown of costs by major SOW task areas. Offerors shall use the same task or subtask numbers as described in the SOW submitted in its technical proposal. If necessary, the Government will request additional back-up information, as appropriate.

NOTE: See Section I.3 for the Project Funding Limits.

If the Offeror elects to submit a cost reimbursable proposal, the Offeror shall provide a detailed cost break-down showing all its proposed costs by each major cost category, including (as applicable) direct labor, overhead and/or fringe rates, subcontract costs, general & administrative costs, profit or fee, other direct costs (travel, equipment, etc.), and indirect costs for the proposed effort. For each major cost category, the Offeror’s price proposal shall include:

Direct Labor:

A. Personnel by name or labor category.

B. Number of hours proposed (commercial organizations) or percent of effort

(organizations subject to OMB Circulars);

C. Hourly unburdened labor rate (commercial organizations) or salary rate and basis

(9- or 12-month basis) (organizations subject to OMB Circulars);

D. Overhead and/or Fringe Benefits Rates applied; and

E. Profit/Fee percentage and amount

Other Direct Costs. Other Direct Costs shall be supported by explanation of estimating factors and other relevant supporting details. For example, travel costs shall be supported by detail on the estimated trips, number of travelers, and associated costs for airfare, per diem, other transportation, etc. A similar level of detail shall be provided for any meeting costs, equipment, duplication/printing charges, and other direct costs.

Indirect Costs. Discuss your proposed rates for all years. Identify the various specific indirect rates and what they are based on (e.g., labor overhead based on direct labor dollars) and how they are applied/calculated. State any differing rate applications (for example if there is a different proposed rate when applied to travel or material purchases than when applied to subcontractor costs). Offerors must provide dollar values as well as percentages.

Subcontractor costs should be fully detailed, and the information used by the proposer to analyze the price of the subcontract shall be provided. An SF1411 is not required for this submission of your proposal.

Details of any cost sharing to be undertaken by the Offeror shall also be included in the cost section. Describe the type of funds (cash, in-kind, etc.) and its contribution and relationship in enhancing the proposed effort. Include:

A. Adequate detail to support the total price for each task and the grand total price.

B. Sufficient detail or cross-references to establish the relationship between the work to be performed and the offered price. All information should be supported by explanations to permit the Government to evaluate the proposal.

C. If proposing FFP, include a milestone payments, if any. For proposed milestone payments to be acceptable, they must follow the following guidelines:

1. Associated with only final deliverables.

2. Payments may not be made for draft deliverables, progress reports/meetings, or kickoff meetings.

3. Payments must be commensurate with the value of the deliverable being submitted.

D. Small Business Subcontracting Plan as noted in section IV.

VI. OTHER ADMINISTRATIVE INFORMATION

It is the policy of the FHWA to treat all proposals as competitive information and to disclose the contents only for evaluation. The Government may use selected support contractor personnel as unique resources to assist in administering the evaluation of the proposals. These persons are restricted by their contracts from disclosing the proposal information or using it for other than performing administrative tasks. Contractor personnel are required to sign non-disclosure statements. By submission of your proposal, you agree that your proposal information may be disclosed to those selected contractors for the limited purpose stated above.

The Government reserves the right to select for award any, all, part, or none of the proposals received in response to this announcement. The Government may select some of the optional tasks (marked as “Government Options”) in the submitted statement of work which means the

Government may or may not choose to exercise them.

This BAA is an expression of interest only and does not commit the Government to pay any proposal preparation costs. All responsible sources that satisfy the Government’s needs may submit proposals, which will be evaluated.

VII. AWARD SELECTION

Once proposal evaluations have been completed, the Contracting Officer will notify all Offerors whether they have been selected for an award. After an awardee is selected for an award, the

USDOT may choose to enter into negotiations with the awardee regarding any aspect of the contract award. Offerors whose proposals were accepted for funding will be contacted before the award to obtain additional information required for the award. The Government reserves the right to remove an awardee from award consideration should the parties fail to agree on contract terms, conditions, and cost/price within a reasonable time or if the offeror fails to provide any additional information requested promptly.

Awards received through this announcement are not controlled by general procedures of FAR

Part 15, “Contracting by Negotiation.” Instead, they are awarded under the authority and procedures described in FAR Part 35, “Research and Development Contracting.” Accordingly, given the inherent nature of a broad agency announcement, specific terms, conditions, and contract clauses, including FAR, USDOT, and FHWA terms and conditions, can only be determined by specifics of a proposed project and will be determined based on the appropriate contract and entity type. Accordingly, contract clauses will be identified and defined during negotiations before the award.

The Government reserves the right to request additional information necessary to determine the offeror’s qualifications for the contract award or clarify any proposal aspects. Such information must be furnished promptly upon the Government’s request. Copies of the successful submission will be retained only as needed for contract administration and monitoring.

VIII. List of Attachments:

TITLE OF ATTACHMENTS ATTACHMENTS NUMBERS

Questions Template 1

Appendix C - Small Business Subcontracting

Plan