Complete Q A_ISS Prototyping.xlsx
XLSX spreadsheet 29 KB Posted
- Attached to
- Intersection Safety Systems (ISS) Prototyping Federal contract opportunity
- Solicitation number
- 693JJ3-26-BAA-0004
About this file
This file is a Questions and Answers document for the Intersection Safety Systems (ISS) Prototyping solicitation (693JJ3-26-BAA-0004). The document addresses inquiries from potential offerors regarding the requirements, evaluation criteria, and administrative aspects of the solicitation issued by the Department of Transportation Federal Highway Administration. As a Q&A document, it provides clarifications on the solicitation requirements rather than specifying new products or services, and serves to ensure all prospective contractors have consistent understanding of the opportunity details before proposal submission.
The Q&A document would typically contain responses to common questions about proposal format and content requirements, technical approach expectations, cost and pricing guidance, contractor eligibility requirements, and other administrative details. To provide specific details about response dates, award information, pricing terms, or other salient contract details, the actual content of the Q&A spreadsheet would need to be reviewed, as this summary is based on the file name and associated solicitation metadata alone.
View the file
Other files for this federal contract opportunity
| File | Type | Posted |
|---|---|---|
| Attachment 3 - Milestone Payment Schedule Template.xlsx | XLSX spreadsheet | |
| 693JJ3-26-BAA-0004_ISS Prototyping.pdf | ||
| Attachment 1 - Draft Performance Work Statement.docx | DOCX document | |
| Attachment 2 - Small Business Subcontracting Plan Template.doc | DOC document | |
| Attachment 4 - Q A Template.xlsx | XLSX spreadsheet |
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Complete Q&A
| Solicitation Number: 693JJ3-26-BAA-0004 | These columns are not distributed to contractors. Hide these columns prior to making .pdf and distributing. |
| Project Name: Intersection Safety Systems (ISS) Prototyping |
| # | Reference: Paragraph/Sentence | Question | Answer | Firm | Email Address |
| 1 | IP & Code Sharing: Our core sensor-fusion and conflict-detection engines are privately funded Background IP and must remain protected. To support the USDOT's open-access goals, may we structure our proposal with an isolated, in-kind costshare for these proprietary modules, while committing to open-source delivery strictly for the newly developed integration layers (such as the signal extension communication code)? | The Government seeks to share the software development, enhancements, alterations, or adaptations of this effort that are developed using Federal funding with the research community. Existing applications brought to the deployment need not be made open source. As noted in the PWS, prospective Contractors are encouraged to describe what elements, if any, of the ISS prototype will be made open source. Additionally per section 2.8 of the solicitation, the Offeror must describe how the Government can accomplish the stated objectives with the limitations described or proposed by the Offeror. | |||
| 2 | Phase I Test Site: Does the FHWA have preferences for which closed-circuit testbeds are selected? | Please refer to evaluation criterion 1b, Overall Technical Approach, regarding the role of the testbed in supporting proposed ISS prototyping activity in meeting Phase 1 and Phase 2 objectives | |||
| 3 | Must the prime team member be the lead ISS developer? As far as I know, few public agencies develop or prototype systems in-house. Rather, they evaluate, procure, and manage systems. To respond to this BAA, is it possible for a public agency to lead a proposal team without taking the role of lead ISS developer? Or can the ISS developer role be assigned to researchers from one of its state universities through inter-agency contracts or research projects? | Please refer to Section 2.4, Teaming Requirements. Proposed teams must include the three identified roles. A single organization or entity of any type, including a public sector agency, may play one or more of these roles including that of lead developer/prime, provided they can demonstrate their qualifications and experience to do so. Public agencies may also choose to partner with universities or other entities as a part of a teaming strategy. | |||
| 4 | Background §1.2 / Factor 1a-1b (BAA pp.3,13) | The BAA background and Draft PWS emphasize low-cost, infrastructure-based sensor systems. Will the Government consider ISS prototype concepts that do NOT employ roadside/infrastructure-mounted sensors - for example, approaches relying primarily on connected-vehicle (V2X) data or other non-infrastructure sensing - provided they demonstrably predict and mitigate conflicts and improve intersection safety? Would such concepts be fully eligible and competitive under Evaluation Factor 1? | The Government is open to all innovative approaches addressing low-cost and scalable methods to improve intersection safety. However, please note that as indicated in Evaluation Factor 1a, any proposed solution must both demonstrate integration potential with existing intersection infrastructure and have a clear path to implementation at scale. | ||
| 5 | PWS ConOps use cases / Exhibit A scenarios | The high-level use cases in the Draft PWS describe conflicts among ground road users (vehicles and pedestrians). Is the Government interested in ISS prototypes that predict and/or mitigate conflicts between ground vehicles and AERIAL vehicles - e.g., uncrewed aircraft systems (UAS/drones) or advanced air mobility (eVTOL) operations - at or near intersections, or is the intended scope limited to ground-based road users? | ISS prototypes must address high-value real-world intersection safety issues identified by a public sector partner. | ||
| 6 | §2.4 Teaming / PWS Task 1-3 & roles | The PWS references an 'accredited configurable closed testbed.' Could the Government define what qualifies as access-controlled and 'accredited' - for example, are university proving grounds or facilities acceptable - and are there minimum instrumentation, configurability, or accreditation requirements the testbed provider must meet? | Formal safety accreditation is not required. However, the proposed test bed must, at a minimum, be both access controlled and have a safety management protocol governing all experimentation conducted in the testbed. | ||
| 7 | §2.4 Phasing / PWS Phase 2 | For Phase 2, what is the Government's expected process and timeline for the documented concurrence among the lead developer, public-sector partner, and COR required to authorize real-time mitigation in live intersections? Is there a standard approval pathway offerors should assume for scheduling purposes? | Concurrence on the Real-Time Mitigation Working memorandum, from the Government's perspective, requires only e-mail concurrence with the memorandum on the part of the lead developer, public sector partner, and the COR. Note that the Contractor may propose alternative processes, as needed, tailored to the needs of the other signing parties. | ||
| 8 | §2.7 & §2.11 / PWS Task 1-7 (Code/Data Plan) | Can the Government clarify how the boundary will be drawn between (a) existing/background applications and privately developed components that remain proprietary, and (b) enhancements, alterations, or adaptations developed with Federal funding that are subject to open-source posting on ITS CodeHub? Specifically, will federally funded enhancements built on top of an offeror's pre-existing proprietary platform be required to be open-sourced, and how is that scope finalized in the Code/Data Plan and pre-award negotiations? | The Government seeks to share the software development, enhancements, alterations, or adaptations of this effort, that are developed using Federal funding, with the research community. Existing applications brought to the deployment need not be made open source. As noted in the PWS, prospective Contractors are encouraged to describe what elements, if any, of the ISS prototype will be made open source. Subsequent refinements of these elements will be conducted both pre-award and in the finalization of the Code/Data Plan. | ||
| 9 | §2.4 Teaming / Factor 1d / Appendix C | May a single proposal include more than one public-sector partner / jurisdiction (e.g., multiple agencies providing intersections for Phase 2 deployment)? If so, is a separate Letter of Support required for each public-sector partner? | Multiple public sector partners may be included. A separate Letter of Support is required for each public sector partner. Note that any Letter of Support must be specific to active participation in both Phase 1 and Phase 2 of the effort, rather than expression of general interest in the proposed ISS prototype system. | ||
| 10 | Section 2.4 Program Requirements and Project Funding Limits. | Defining "Convincing Evidence" and "Acceptable Risk": The BAA states that real-time mitigation in Phase 2 can only be introduced if there is "convincing evidence" that it can be done with "acceptable risk". What specific performance metrics, key performance indicators (KPIs), or safety thresholds will the US DOT and the Contracting Officer’s Representative (COR) use to define "convincing evidence" and "acceptable risk"? Are there specific quantitative milestones the observe-only phase must hit before active mitigation is approved? | USDOT will not provide or establish metrics and thresholds. Specific metrics and performance thresholds establishing consensus among the relevant parties in Task 2-5 are informed by the nature of the proposed ISS prototype and ISS prototype development activity in Phase 1 and Phase 2. The Contractor documents all relevant metrics and thresholds, among other considerations regarding real-time mitigation, in the Field Deployment and Demonstration Plan. Concurrence between the ISS developer and the public sector partner is codified for specific operational conditions in the Real-Time Working Memorandum. After COR acceptance, real-time mitigation may be implemented. Note that if concurrence cannot be reached among the relevant parties to implement real-time mitigation, then no real-time mitigation may be implemented. | ||
| 11 | Section 4.2 Evaluation Factors. | Standards for Auditory and Visual Warnings: The BAA expects prototypes to mitigate individual conflicts by taking immediate action, such as "issuing an auditory or visual warning". For systems that intend to deliver auditory or visual warnings directly to drivers or pedestrians, does the US DOT require or prefer alignment with specific communication standards (such as specific C-V2X protocols) or existing infrastructure platforms, or is the technical approach entirely up to the Offeror? | No specific communication method is mandated for the issuance of auditory or visual warnings. | ||
| 12 | Section 4.2 Evaluation Factors. | Scope of "Practical Mitigation" in the Phase 1 Closed Testbed: Phase 1 requires testing in an "access-controlled testbed". During Phase 1 testing in the closed testbed, is the Offeror required to physically execute intersection control modifications (e.g., physically altering the traffic signal lights in the testbed), or is it acceptable to demonstrate the system's ability to trigger these mitigations virtually/via simulation while the sensors operate physically? | The Offeror technical approach must provide a compelling and realistic test environment designed to demonstrate the potential of the proposed ISS system. The test environment must include a physical aspect. However, the Offeror may propose virtual elements that augment or enhance planned physical testing. | ||
| 13 | Section 2.4 Program Requirements and Project Funding Limits. | Liability for Approved Phase 2 Mitigations: If real-time mitigation is introduced in Phase 2, it requires explicit documentation and concurrence from the lead ISS developer, the public sector partner, and the COR. Once the US DOT (via the COR) and the public sector partner explicitly approve and document the deployment of real-world mitigation actions (such as altering signal phases), how will liability be handled among the public sector partner, the lead developer, and the federal Government if an automated mitigation action results in an unintended traffic incident? | Determining liability depends on many facts that are unknown at this time, including the details of an incident, prototype design, and deployment location. The BAA states real-time mitigation may be introduced “[i]f convincing evidence is identified that some or all potential real-time mitigating actions can be introduced in an operational state … with acceptable risk…” Offerors should consider liability when conceptualizing “acceptable risk.” |
Liability considerations will be addressed during negotiations after an awardee is selected. See BAA Section 4.3. As noted in the BAA, “specific terms, conditions, and contract clauses, including FAR, USDOT, and FHWA terms and conditions, can only be determined based on the specifics of a proposed project, appropriate contract, and entity type.”
| 14 | Section 4.2 Evaluation Factors. | Clarification on the Predictive Window: The BAA states that prototypes will be evaluated on their potential in "predicting and mitigating individual conflicts in real-time" and defines these conflicts as situations with a high risk of an "imminent collision". Is the 3-second predictive window from the previous stage of the Challenge still the required benchmark for defining an "imminent collision," or are Offerors now permitted to define, propose, and justify their own real-time predictive time horizons as part of their technical approach? | Offerors are permitted to define predictive time horizons tailored to their prototype ISS concepts. |
| 15 | Section 2.7 Code Sharing. | Boundaries Between Open-Source and Proprietary Code: The BAA states that software development funded by this effort must be shared as open-source, while existing applications can remain proprietary. If an Offeror utilizes pre-existing proprietary AI/ML models or sensor fusion algorithms, but uses project funding to train or adapt these models specifically for the ISS prototype, does the USDOT consider the underlying algorithm to be subject to the open-source requirement, or only the newly developed interface/adaptation layers? | The Government seeks to share the software development, enhancements, alterations, or adaptations of this effort, that are developed using Federal funding with the research community. Existing applications brought to the deployment need not be made open source. As noted in the PWS, prospective Contractors are encouraged to describe what elements, if any, of the ISS prototype will be made open source. |
| 16 | Section 2.4 Program Requirements and Project Funding Limits. | Specific Metrics for Phase 2 Down-Select: The Government notes it may exercise the Phase 2 option for "all, some, or none" of the Phase 1 awardee teams. Regarding the transition from Phase 1 to Phase 2, what specific, objective performance metrics or operational readiness criteria will the Government use at the conclusion of Phase 1 to determine whether a team's Phase 2 option will be exercised? | The Government may exercise the option for all, some or none of the awardee teams for Phase 2 based on the availability of funds, the successful completion of all Phase 1 deliverables, and the demonstrated potential of proposed ISS systems. Note that the decision to exercise the option is determined on an individual team basis, i.e., there is no direct comparison of performance metrics among teams as a part of the Governments' decision -- as the conditions under which the ISS systems are evaluated are expected to be significantly different. |
| 17 | Section 2.4 Program Requirements and Project Funding Limits. | Structural Requirements for the Closed Testbed: Phase 1 requires testing in an access-controlled testbed "situated apart from public roadways and closed to the general public". Does the USDOT have minimum geometric or infrastructure requirements for the Phase 1 access-controlled testbed (e.g., minimum number of lanes, presence of functional traffic cabinets, specific crosswalk layouts), or is the Offeror free to propose any closed environment that safely accommodates vehicle and pedestrian conflict testing? | There are no required functional or geometric requirements for the closed testbed. However, the testbed must provide a suitable environment for the testing and development of the proposed ISS prototype concept and must be able to support the required Use Case, Scenario, and Operational Condition Combinations identified in Table 1 of PWS Attachment 1. |
| 18 | 3.2 Volume II: Business, Cost, and Pricing Data | Cash Flow and Other Direct Costs (ODCs): The BAA states that Other Direct Costs (ODCs) such as materials and travel will be reimbursed at cost separately, but also mandates that payments will not be made for partially completed deliverables. To facilitate timely reimbursement of these separate costs, are Offerors permitted to define the incurring of ODCs—particularly major upfront capital expenditures like prototype equipment/hardware procurement, but also routine travel costs—as standalone, billable milestones in the Milestone Payment Schedule? | Materials and travel costs are not considered project deliverables. |
Offeror's must provide estimates for these ODC's in their cost/price proposal with as much accuracy as possible; however, they do not need to be included in the milestone payment schedule as separate deliverables, instead they will be invoiced after those costs are incurred with receipts attached, and will be reimbursed at cost.
| 19 | 2.4 Phasing Requirements (Phase 2) | For Phase 2 deployment in "multiple real-world intersections," what is the minimum number of intersections the Government considers acceptable (e.g., is 2 enough)? And within the firm-fixed price, are installation costs—power, communications backhaul, permitting, and pole/cabinet/civil work—to be carried by the Offeror, or provided in-kind by the public sector partner and documented in the Appendix C letter of support? | Phase 2 deployments must feature a minimum of two intersections. The number of deployed intersections must be sufficient to demonstrate the versatility and scalability of the proposed ISS concept (see evaluation factor 1a). Installation and maintenance costs may be included as components of the proposed fixed price milestones or provided in-kind by a public sector partner. Note, however, that there is no requirement for a public sector match in this solicitation. |
| 20 | 2.4 Teaming Requirements | Can one commercial firm serve as both the lead ISS developer and the access-controlled testbed provider (with a separate public agency as the public sector partner)? If so, is a lease or use-agreement for the testbed sufficient (versus ownership), and will a two-role proposal be scored differently under Factor 1d than a three-organization team? | Please refer to Section 2.4, Teaming Requirements. Proposed teams must include the three identified roles. A single organization or entity may play one or more of these roles, including that of testbed operator. Testbed access may be obtained via lease/rental or through outright ownership. |
| 21 | Phase 1 (Base Period): Prototype Development and Testing will focus on the development and testing of ISS prototypes in an access-controlled roadway intersection testbed, referred to as a closed testbed. | Can the testbed consist of a mobile setup including portable traffic lights as long as the intersection is controlled, away from public roadway access, configurable and has logging capabilities? | Formal safety accreditation is not required. However, the proposed test bed must, at a minimum, be both access controlled and have a safety management protocol governing all experimentation conducted in the testbed. |
| 22 | an entity providing access to an accredited configurable closed testbed | Can you clarify what accreditation is needed or provide a list of testbed providers that meet the accreditation? | Formal safety accreditation is not required. However, the proposed test bed must, at a minimum, be both access controlled and have a safety management protocol governing all experimentation conducted in the testbed. |
| 23 | an entity providing access to an accredited configurable closed testbed | Will a test intersection that is closed, configurable and has logging capabilities overseen by a public sector partner, but does not have a specific accreditation, be considered? | Formal safety accreditation is not required. However, the proposed test bed must, at a minimum, be both access controlled and have a safety management protocol governing all experimentation conducted in the testbed. |
| 24 | BAA Section 2.1 Schedule / correspondence; proposal submission requirements | Please confirm the required proposal submission method for Volume I and Volume II. Should proposals be submitted through SAM.gov, by email to the Contract Specialist, through another online portal, or by physical delivery? | All proposals should be emailed directly to the contract specialist identified in section 2.1 of the solicitation. |
| 25 | BAA Section 2.3 Offeror Eligibility; Section 2.4 Teaming Requirements | For the required teaming structure, may the lead ISS developer include affiliated entities, subcontractors, universities, research institutions, public agencies, and technical partners as part of the proposal team, provided the lead offeror remains responsible for contract performance? | Please refer to Section 2.4, Teaming Requirements. Proposed teams must include the three identified roles. A single organization or entity may play one or more of these roles. |
| 26 | PWS Phase 1 public-sector partner letter of support requirement | Please clarify the minimum required content for the public-sector partner letter of support. Must the letter identify exact Phase 2 intersection locations at proposal submission, or is it acceptable to identify representative intersection types and commit to final site selection during the project? | Representative intersection types and confirmation that intersections meeting this description can be found under the public sector partner's jurisdiction are sufficient for the Letter of Support. Specific locations are intended to be identified at the start of Phase 2. |
| 27 | BAA Section 2.4 Teaming Requirements; PWS Phase 1 closed testbed requirement | Please clarify what qualifies as an “access-controlled roadway intersection testbed” or “accredited configurable closed testbed.” Is formal accreditation required, or may a university, research facility, proving ground, or controlled roadway environment qualify if it can safely replicate intersection use cases and collect required performance data? | Formal safety accreditation is not required. However, the proposed test bed must, at a minimum, be both access controlled and have a safety management protocol governing all experimentation conducted in the testbed. |
| 28 | PWS Phase 1 Key Research Questions - Mitigating Strategies | For Phase 1 prototype testing, would real-time visual, auditory, roadside, connected, or in-vehicle warnings satisfy the mitigation requirement if technically justified, or is direct traffic signal control expected to be demonstrated? | The Government is open to all innovative approaches addressing low-cost and scalable methods to improve intersection safety. However, please note that as indicated in Evaluation Factor 1a, any proposed solution must both demonstrate integration potential with existing intersection infrastructure and have a clear path to implementation at scale. |
| 29 | BAA Section 2.4 Phasing Requirements; PWS Phase 1 and Phase 2 deployment descriptions | Does USDOT expect a minimum number of physical ISS prototype units, roadside nodes, or devices to be deployed in Phase 1 closed-testbed testing or Phase 2 field deployment, or should offerors propose the quantity required to satisfy their test plan, use cases, and deployment objectives? | There are no required quantities of ISS prototype units, devices, or sensors in Phase 1. However, the ISS prototype concept and must address the required Use Case, Scenario, and Operational Condition Combinations identified in Table 1 of PWS Attachment 1. |
Phase 2 deployments must feature a minimum of two intersections. The number of deployed intersections should be sufficient to demonstrate the versatility and scalability of the proposed ISS concept (see evaluation factor 1a).
| 30 | PWS Phase 2 Site Engagement and Deployment; real-world intersection deployment planning | Will the Government or public-sector partner provide information on available power sources at proposed Phase 2 deployment locations, or should offerors propose power configurations based on site conditions? | Phase 2 deployment locations should utilize available power sources or, if required, augment power supply as a part of the deployed prototype ISS. |
| 31 | PWS Task 1-7 Code/Data Sharing; data privacy and sharing requirements | For privacy-sensitive sensor data, may offerors satisfy data-sharing requirements through anonymized, de-identified, metadata-based, synthetic, or derived datasets instead of raw video or imagery, provided the submitted data supports evaluation and research objectives? | Proposers are encouraged to propose data sharing strategies that will provide value to the research community, including strategies utilizing anonymized, aggregated, or otherwise altered data (both visual and digital) while protecting both PII and proprietary data. |
| 32 | BAA / PWS code sharing and intellectual property requirements | Please confirm that pre-existing proprietary software, firmware, AI models, device-management systems, and commercial platforms brought to the project may remain proprietary if clearly identified in the proposal, while only federally funded software development, enhancements, or adaptations identified for sharing would be subject to CodeHub/open-source expectations. | The Government seeks to share the software development, enhancements, alterations, or adaptations of this effort that are developed using Federal funding with the research community. Existing applications brought to the deployment need not be made open source. As noted in the PWS, prospective Contractors are encouraged to describe what elements, if any, of the ISS prototype will be made open source. |
| 33 | PWS human-use approval / IRB requirements for experiments involving human participants | Is Human Use Approval / IRB approval required at the time of proposal submission, or is it sufficient to include the proposed IRB approach, responsible party, and schedule for obtaining approval after award and before any human-subject testing begins? | A proposed path/process to obtaining Human Use Approval / IRB approval is expected at proposal submission. IRB approval post-award must be obtained before any human-subject testing begins. |
| 34 | TECHNICAL EXHIBIT 2, section 1.2.6.2 Use Cases/Scenarios/Operational Conditions and Closed Testbed Setup. "At least four additional combinations must be relevant to demonstrating ISS prototype capabilities" | Can these four combinations be for scenarios such as non-signalized intersection (e.g., intersections with stop signs), or red-light running vehicles risk T-bone crash etc.? | Non-signalized intersections, including roundabouts, are valid intersections for prototype ISS development and testing. In these cases, adaptations of the required Use Cases may be proposed as well as other use cases designed to demonstrate the value of the proposed ISS concept. |
| 35 | 2. CONTRACT GUIDELINES, section 2.1 | What is the expected project start time and funding availability status? | The Government anticipates the project to start in October 2026. Refer to section 2.4 for project funding information. |
| 36 | 2. CONTRACT GUIDELINES 2.4 Program Requirements and Project Funding Limits, "Note that the lead ISS developer, the public sector partner, and the Contracting Officer’s Representative (COR) must all concur and document the operational conditions, mitigation types, and deployment locations under which real-time mitigations may occur." | For mitigation types, would non-MUTCD warning signs/LED message board allowed for intersection deployment and testing? | For the Phase 2 locations where the ISS prototype is deployed, MUTCD complaint signage is required; however, a waiver may be requested. Note that the final form of the ISS prototype may change during Phase 1 development activity and Phase 2 refinement effort, so in the proposal stage the Offeror is not required to commit to a definitive warning sign design. |
| 37 | Section 2.4 Paragraph 3: Access Controlled Roadway Intersection Test Bed | Is access to a specific test bed provided as part of the testing portion of Phase I? If not, is an LOC/LOS required or can this relationship be finalized during the execution phase? | Access to a specific testbed in both Phase 1 and Phase 2 is not provided by the Government. As a part of their proposal, Offerors should identify a specific testbed expected to be utilized for ISS development and testing. |
File details come from the government source that posted it. Updated .