The file's text, extracted by GovTribe without its formatting.
VENDOR MANDATORY AND TECHNICAL RESPONSE SHEET
UDOT C-V2X Equipment Instructions
Technical Compliance Matrix There are six (6) Technical Compliance Matrices, one for each device type category. For each device type category being bid, the Offeror must complete and submit the Technical Compliance Matrix in its entirety.
A. In the MMR portion of the matrix, a “Mandatory Minimum Requirements” column defines the specifications that must be met. The Y/N column is to be completed by the Offeror indicating whether the offered product meets the listed criteria. Any response that does not contain a “Y” for YES in all rows of the MMR will eliminate this bid from further consideration.
B. In the MRC Technical portion of the matrix, a “Mandatory Response Comments” section identifies features that are important to the Department. The “Required Responses” column defines the criteria being evaluated. Although it is not a requirement for the proposed device to meet all of these items, each item will still receive a technical score based on the Offeror’s response in the “Comment” column”. Offerors are encouraged to provide a brief discussion in the Comment section of the MRC table to succinctly address each of the criteria listed. It is not the intent for these comment responses to be lengthy or complex, but they should be of sufficient detail as to demonstrate compliance of the product being offered with the stated requirement. If a product does not comply with the requirement, a statement to that effect should be entered or a comment on intended future compliance. A blank response will result in a zero score. Likewise, an overly complex response or reference to an attached product document that makes it difficult for the evaluator to interpret the compliance of the product may similarly result in a low score. The “Maximum Points” space indicates the number of points that may be assigned to each requirement.
A minimum total score of 60 percent of the total possible points in the MRC section for a given device type is required for the offered product to be considered further. Technical responses that fail to meet the required 60 percent of total points will be disqualified from further consideration.
Device Type Categories
Offerors may choose to submit on any or all device types as defined below, but a unique and stand-alone response must be submitted for each Device Type proposed.
| 4 |
| Roadside Processor (RSP) |
| 5 |
| Human Machine Interface (HMI) |
| 6 |
| On-board Processor (OBP) |
Mandatory Response Comments (MRC) Technical Evaluation Criteria
The Department’s Review Committee will evaluate the comments entered in the MRC Technical matrix and score each criterion based on how well the product complies with the specification. Points will be awarded for each requirement as follows:
0 = Fail, the proposal fails to address the requirements or criteria described in the RFP or cannot be assessed due to missing information 1 = Poor, the proposal inadequately addresses the requirements or criteria described in the RFP or cannot be assessed due to incomplete information 2 = Unsatisfactory, the proposal addresses the requirements or criteria described in the RFP in an unsatisfactory manner 3 = Satisfactory, the proposal addresses all requirements or criteria described in the RFP in a minimum satisfactory manner 4 = Good, the proposal addresses all requirements or criteria described in the RFP and in some respects exceeds them 5 = Excellent, the proposal addresses and exceeds all of the requirements or criteria described in the RFP Evaluation committee members will individually score the Technical Evaluation Criteria on a 0-5 basis. The Evaluation Committee will then tally the final scores for the Technical Criteria to arrive at a Consensus Score by an average of the individual scores. The Consensus Score will then be multiplied by the Weighting Factor assigned to a criteria to arrive at the points earned for that criterion.
TECHNICAL REQUIREMENTS
TYPE 1 – C-V2X RSU
Vendor Name
Device Name
TYPE 1 – C-V2X RSU – MMR Matrix
| ITEM |
| MANDATORY MINIMUM REQUIREMENTS (MMR) (Pass/Fail) |
| Y / N |
| 1.1.1 |
| RSU shall be new production level devices (not beta or R&D versions) available for purchase. |
| 1.1.2 |
| RSU manufacturer shall have produced C-V2X RSUs that have been purchased and installed by customers. |
| 1.1.3 |
| RSU enclosure shall be a complete integrated unit and provide Ingress Protection of IP67 or greater and shall be pole mountable without an additional enclosure. |
| 1.1.4 |
| RSU shall have an ethernet connection and be powered with POE. |
| 1.1.5 |
| RSU shall be capable of transmitting and receiving messages within the 5.895 GHz to 5.925 GHz band of spectrum in accordance with current FCC rules. |
| 1.1.6 |
| RSU shall be capable of transmitting and receiving signed/secured messages and forwarding to a separate host. |
| 1.1.7 |
| RSU shall have an integrated hardware security module installed, with associated software libraries for managing certificate materials and signing and verifying messages. |
| 1.1.8 |
| RSU shall be furnished with a complete product user manual, quick start guide, software development manual, description of APIs, and proprietary commands. |
| 1.1.9 |
| RSU vendor shall provide engineering-level support to UDOT or its representative at no cost during the warranty period. |
| 1.1.10 |
| RSU shall have at least a 2-Year Warranty from date of purchase. |
TYPE 1 – C-V2X RSU – MRC Matrix
MANDATORY RESPONSE COMMENTS (MRC) (Scored)
Maximum Points = 100
| ITEM |
| Required Responses |
| Comment |
| Weighting Factor |
| 1.2.1 |
| Describe the company's experience in producing and delivering C-V2X RSU equipment and solutions. |
| 1.2.2 |
| What is the lead time to deliver 40 units? |
| 1.2.3 |
| Provide 3 references, including contact information (Name, Entity, Phone and Email), of three different deployments of the equipment being offered. |
| 1.2.4 |
| Describe whether the devices have received OmniAir certification or will be subjected to that process in the near future. |
0.5
| 1.2.5 |
| Does the RSU operate in the temperature range -34 C to 60 C? If not, provide the operating temperature range of the device. |
0.5
| 1.2.6 |
| Indicate if the device is compliant with PoE standards 802.3af or 802.3at. If not, describe the power requirements for the PoE device. |
0.5
| 1.2.7 |
| Describe all of the items that are delivered with the RSU, including all subsystem components (i.e., antennas, surge suppressors, power supplies, etc.) |
0.5
| 1.2.8 |
| Does the RSU have a GNSS Receiver with an accuracy of at least 3.0 meters? Does the GNSS receiver support multi-band (L1/L2 or L1/L5) and RTK (Real-Time Kinematic)? |
0.5
| 1.2.9 |
| Describe the RSU's support for J2735 messages. |
| 1.2.10 |
| Describe the RSU's support for J2945 messages. |
| 1.2.11 |
| Does the RSU support SNMP for commanding functions and device parameters? Describe what functions are supported and the MIB used. |
| 1.2.12 |
| Describe the ability and process by which applications can be developed and deployed natively to the RSU. |
0.5
| 1.2.13 |
| Describe allowable access level to the RSU applications and operating system that will be provided to UDOT and their representatives. |
| 1.2.14 |
| Does the RSU support the following Provider Service Identifiers (PSIDs)? |
· BSM – 32, (0x20)
· MAP – 2113687 (0x20-40-97)
· SPaT – 130 (0x82)
· SRM – 2113686 (0x204096)
· SSM – 2113685 (0x204095)
· TIM – 131 (0x83)
· RTCM – 128,129 (0x80, 0x81)
· SDSM – 2113690 (0x20409A)
| 1.2.15 |
| Describe how your RSU can be implemented as a drop-in replacement for existing UDOT RSU equipment based on RSU support of the following: |
· Receiving and immediately forwarding MAP messages from a separate host and broadcast on the C-V2X interface at 1Hz intervals
· Storing and forwarding MAP messages from a separate host and broadcast on the C-V2X at 1Hz intervals
· Receiving and immediately forwarding SPaT messages from a separate host and broadcast on the C-V2X interface at 10Hz intervals
· Receiving and immediately forwarding SSM messages from a separate host and broadcast on the C-V2X interface
· Receiving BSM messages on the C-V2X interface and forwarding to a separate host
· Receiving SRM messages on the C-V2X interface and forwarding to a separate host
| 1.2.16 |
| Does the RSU host 3rd party applications? |
0.5
| 1.2.17 |
| Does the RSU support development of 3rd party applications using a Software Development Kit (SDK) and/or API in a Linux environment? Describe the development environment, SDK, API and Logging capabilities of the RSU. |
0.5
| 1.2.18 |
| Describe the RSU's security capabilities and features, specifically the device’s Hardware Security Module, integration with certificate authority, and support of production level certificates. |
| 1.2.19 |
| Describe the company's commitment to providing engineering-level support (support directly from a member of the RSU manufacturer’s engineering team on hardware and software issues) and how quickly support will be provided. |
| 1.2.20 |
| Describe the device’s level of compliance with Buy America provisions. |
0.5
| 1.2.21 |
| Describe the device’s level of CTI 4501 compliance. |
| 1.2.22 |
| Describe the device’s level of CTI 4001 compliance. |
| 1.2.23 |
| Do you have experience using multiple vendors for security certificates with this device? If so, please describe this. |
0.5
| 1.2.24 |
| Describe other features of the RSU that you feel are worth noting that have not been identified. If these features are optional or require additional hardware, fees, or licensing, they must be listed in the Optional Features cost table. |
0.5
| 1.2.25 |
| Verify RSU support for unsecured/unsigned messages. If supported, indicate if this feature is configurable and describe the implementation. |
0.5
TECHNICAL REQUIREMENTS
TYPE 2 – C-V2X OBU
Vendor Name
Device Name
TYPE 2 – C-V2X OBU – MMR Matrix
| ITEM |
| MANDATORY MINIMUM REQUIREMENTS (MMR) (Pass/Fail) |
| Y / N |
| 2.1.1 |
| OBU shall be new production level devices (not beta or R&D versions) available for purchase. |
| 2.1.2 |
| OBU manufacturer shall have produced C-V2X OBUs that have been purchased and installed by customers. |
| 2.1.3 |
| OBU shall be capable of transmitting and receiving messages within the 5.895 GHz to 5.925 GHz band of spectrum in accordance with current FCC rules. |
| 2.1.4 |
| OBU antenna output terminal shall measure a minimum power of no less than +20dBm when set to maximum. |
| 2.1.5 |
| OBU shall be capable of receiving MAP at 1 Hz interval from multiple RSUs. |
| 2.1.6 |
| OBU shall be capable of receiving SPaT at 10 Hz interval from multiple RSUs. |
| 2.1.7 |
| OBU shall be capable of broadcasting BSM. |
| 2.1.8 |
| OBU shall be capable of broadcasting SRM, including an SRM generated by an independent on-board device, and receiving SSM. |
| 2.1.9 |
| OBU shall be capable of receiving, interpreting and communicating a TIM to an HMI. |
| 2.1.10 |
| OBU shall have an integrated hardware security module installed, with associated software libraries for managing certificate materials, to enable transmitting and receiving signed/secured messages. |
| 2.1.11 |
| OBU shall be furnished with a complete product user manual, quick start guide, software development manual, description of APIs, and proprietary commands. |
| 2.1.12 |
| OBU vendor shall provide engineering-level support (as defined in 4.2.19) to UDOT or its representative at no cost during the warranty period. |
| 2.1.13 |
| OBU shall have at least a 2-Year Warranty from date of purchase. |
TYPE 2 – C-V2X OBU – MRC Matrix
MANDATORY RESPONSE COMMENTS (MRC) (Scored)
Maximum Points = 105
| ITEM |
| Required Responses |
| Comment |
| Weighting Factor |
| 2.2.1 |
| Describe the company's experience in producing and delivering C-V2X OBU equipment and solutions. |
| 2.2.2 |
| What is the lead time to deliver 40 units? |
| 2.2.3 |
| Provide 3 references, including contact information (Name, Entity, Phone and Email), of three different deployments of the equipment being offered. |
| 2.2.4 |
| Describe whether the device has received OmniAir certification or will be subjected to that process in the near future. |
0.5
| 2.2.5 |
| Is the OBU rated for vehicular environments with an operating temperature range of -34 C to 74 C, operating voltage of 9 to 32 VDC, and color coded fakra connectors for antenna interfaces? |
0.5
| 2.2.6 |
| The OBU should be capable of operating in vehicular environments as follows: |
· Sense if the vehicle is on/off through an ignition sense output
· Interface via a CAN connection
· Provide user connections through an Ethernet connection (natively or with an adapter)
· Over-the-air updates, via LTE or WiFi, of all software and firmware modules.
Describe the level of compliance for each of these capabilities.
| 2.2.7 |
| The OBU should be capable of booting and obtaining GPS in less than 60 seconds, and also have a GNSS Receiver with an accuracy of at least 3.0 meters. Describe the level of compliance with these capabilities, or any differences. |
0.5
| 2.2.8 |
| Does the OBU have GPIOs for interfacing with equipment on the vehicle? |
0.5
| 2.2.9 |
| Describe all of the items that are delivered with the OBU, including all subsystem components (i.e., antennas, surge suppressors, power supplies, etc.) |
0.5
| 2.2.10 |
| Describe how the OBU communicates with the HMI. Specify supported HMI API protocols. |
| 2.2.11 |
| Describe the input and output ports the OBU has. |
| 2.2.12 |
| Describe the OBU's support for J2735 messages including Part I and Part II of the BSM Message. |
| 2.2.13 |
| Describe the OBU's support for J2945 messages. |
0.5
| 2.2.14 |
| Does the OBU support the following Provider Service Identifiers (PSIDs)? |
· BSM – 32, (0x20)
· MAP – 2113687 (0x204097)
· SPaT – 130 (0x82)
· SRM – 2113686 (0x204096)
· SSM – 2113685 (0x204095)
· TIM – 131 (0x83)
· RTCM – 128,129 (0x80, 0x81)
· SDSM – 2113690 (0x20409A)
| 2.2.15 |
| Describe the ability and process by which applications can be written to and run on the OBU. |
| 2.2.16 |
| How is the OBU configured (via a network API such as SNMP, RESTful, etc.)? |
0.5
| 2.2.17 |
| Describe allowable access level to the OBU applications and operating system that will be provided to UDOT and their representatives. |
| 2.2.18 |
| Verify OBU support for unsecured/unsigned messages. If supported, indicate if this feature is configurable and describe the implementation. |
0.5
| 2.2.19 |
| Describe how the proposed On-Board Unit (OBU) functions as a drop-in replacement for current UDOT equipment, specifically regarding its ability to interface with a separate host, such as the OBP or HMI for the following: |
· Provide live GNSS feed off of the OBU to a separate host.
· Independently broadcasting basic BSM messages on the C-V2X interface at 10Hz intervals.
· Receiving MAP messages on the C-V2X interface from multiple RSUs and forward to a separate host.
· Receiving SPaT messages on the C-V2X interface from multiple RSUs and forward to a separate host.
· Receiving and immediately forwarding SRM messages on the C-V2X interface from a separate host.
· Receiving SSM messages on the C-V2X interface and forward to a separate host.
· Support the passage and forwarding of both secured (signed) and unsecured (unsigned) messages to the OBP.
| 2.2.20 |
| Does the OBU host 3rd party applications? |
0.5
| 2.2.21 |
| Does the OBU support development of 3rd party applications using a Software Development Kit (SDK) and/or API in a Linux environment? Describe the development environment, SDK, API and Logging capabilities of the OBU. |
0.5
| 2.2.22 |
| Does the OBU have an API to provide injection of data elements of the J2735 BSM and does it provide access to the GNSS service and CAN interface? |
0.5
| 2.2.23 |
| Describe the OBU's security capabilities and features, specifically the device’s Hardware Security Module, integration with certificate authority, and support of production level certificates. |
| 2.2.24 |
| Describe the company's commitment to providing engineering-level support (support directly from a member of the OBU manufacturer’s engineering team on hardware and software issues) and how quickly support will be provided. |
| 2.2.25 |
| Describe the device’s level of compliance with Buy America provisions. |
0.5
| 2.2.26 |
| Do you have experience using multiple vendors for security certificates with this device? If so, please describe this. |
0.5
| 2.2.27 |
| Describe other features of the OBU that you feel are worth noting that have not been identified. If these features are optional or require additional hardware, fees, or licensing, they must be listed in the Optional Features cost table. |
0.5
TYPE 3 – C-V2X OBU (Compact) Vendor Name
Device Name
TYPE 3 – C-V2X OBU (Compact) – MMR Matrix
| ITEM |
| MANDATORY MINIMUM REQUIREMENTS (MMR) (Pass/Fail) |
| Y / N |
| 3.1.1 |
| OBU shall be new production level devices (not beta or R&D versions) available for purchase. |
| 3.1.2 |
| OBU manufacturer shall have produced C-V2X OBUs that have been purchased and installed by customers. |
| 3.1.3 |
| OBU shall be capable of transmitting and receiving messages within the 5.895 GHz to 5.925 GHz band of spectrum in accordance with current FCC rules. |
| 3.1.4 |
| OBU antenna output terminal shall measure a minimum power of no less than +20dBm when set to maximum. |
| 3.1.5 |
| OBU shall be capable of receiving MAP at 1 Hz interval from multiple RSUs. |
| 3.1.6 |
| OBU shall be capable of receiving SPaT at 10 Hz interval from multiple RSUs. |
| 3.1.7 |
| OBU shall be capable of broadcasting BSM. |
| 3.1.8 |
| OBU shall be capable of receiving, interpreting and communicating a TIM to an HMI. |
| 3.1.9 |
| OBU shall have an integrated hardware security module installed, with associated software libraries for managing certificate materials, to enable transmitting and receiving signed/secured messages. |
| 3.1.10 |
| OBU shall be furnished with a complete product user manual, quick start guide, software development manual, description of APIs, and proprietary commands. |
| 3.1.11 |
| OBU vendor shall provide engineering-level support to UDOT or its representative at no cost during the warranty period. |
| 3.1.12 |
| OBU shall have at least a 2-Year Warranty from date of purchase. |
| 3.1.13 |
| OBU shall have an internal antenna. |
TYPE 3 – C-V2X OBU (Compact) – MRC Matrix
MANDATORY RESPONSE COMMENTS (MRC) (Scored)
Maximum Points Possible = 105
| ITEM |
| Required Responses |
| Comment |
| Weighting Factor |
| 3.2.1 |
| Describe the company's experience in producing and delivering C-V2X OBU equipment and solutions. |
| 3.2.2 |
| What is the lead time to deliver 40 units? |
| 3.2.3 |
| Provide 3 references, including contact information (Name, Entity, Phone and Email), of three different deployments of the equipment being offered. |
| 3.2.4 |
| Describe whether the device has received OmniAir certification or will be subjected to that process in the near future. |
0.5
| 3.2.5 |
| Is the OBU rated for vehicular environments with an operating temperature range of -34 C to 74 C, operating voltage of 9 to 18 VDC, and fully integrated internal antennas for V2X and GNSS? |
0.5
| 3.2.6 |
| The OBU should be capable of operating in vehicular environments as follows: |
· Support automated power-state management (e.g., ignition sense or voltage-based wake/sleep).
· Interface via a CAN connection
· Provide user connections through an Ethernet connection (natively or with an adapter) or wireless connection.
· Over-the-air updates, via LTE or WiFi, of all software and firmware modules.
Describe the level of compliance for each of these capabilities.
| 3.2.7 |
| The OBU should be capable of booting and obtaining GPS in less than 60 seconds, and also have a GNSS Receiver with an accuracy of at least 3.0 meters. Describe the level of compliance with these capabilities, or any differences. |
0.5
| 3.2.8 |
| Does the OBU support the ingestion of vehicle state data (e.g., emergency lights, plow status) via CAN-Bus/OBD-II or Wireless Peripheral interfaces? If physical GPIOs are required for these inputs, please describe how the writing harness maintains a ‘compact’ and ‘non-intrusive’ cabin footprint. |
0.5
| 3.2.9 |
| Describe all of the items that are delivered with the OBU, including all subsystem components (i.e., antennas, surge suppressors, power supplies, etc.) |
0.5
| 3.2.10 |
| Describe the OBU's support for J2735 messages including Part I and Part II of the BSM Message. |
| 3.2.11 |
| Describe the OBU's support for J2945 messages. |
| 3.2.12 |
| Does the OBU support the following Provider Service Identifiers (PSIDs)? |
· BSM – 32, (0x20)
· MAP – 2113687 (0x204097)
· SPaT – 130 (0x82)
· SRM – 2113686 (0x204096)
· SSM – 2113685 (0x204095)
· TIM – 131 (0x83)
· RTCM – 128,129 (0x80, 0x81)
· SDSM – 2113690 (0x20409A)
| 3.2.13 |
| Describe the ability and process by which applications can be written to and run on the OBU. |
| 3.2.14 |
| How is the OBU configured (via a network API such as SNMP, RESTful, etc.)? |
0.5
| 3.2.15 |
| Describe allowable access level to the OBU applications and operating system that will be provided to UDOT and their representatives. |
0.5
| 3.2.16 |
| Describe how the proposed On-Board Unit (OBU) functions as a drop-in replacement for current UDOT equipment, specifically regarding its ability to interface with a separate host, such as the OBP or HMI for the following: |
· Provide live GNSS feed off of the OBU to a separate host.
· Independently broadcasting basic BSM messages on the C-V2X interface at 10Hz intervals.
· Receiving MAP messages on the C-V2X interface from multiple RSUs and forward to a separate host.
· Receiving SPaT messages on the C-V2X interface from multiple RSUs and forward to a separate host
· Receiving and immediately forwarding SRM messages on the C-V2X interface from a separate host.
· Receiving SSM messages on the C-V2X interface and forward to a separate host.
· Support the passage and forwarding of both secured (signed) and unsecured (unsigned) messages to the OBP.
| 3.2.17 |
| Does the OBU host 3rd party applications? |
0.5
| 3.2.18 |
| Does the OBU support development of 3rd party applications using a Software Development Kit (SDK) and/or API in a Linux environment? Describe the development environment, SDK, API and Logging capabilities of the OBU. |
0.5
| 3.2.19 |
| Does the OBU have an API to provide injection of data elements of the J2735 BSM and does it provide access to the GNSS service and CAN interface? |
0.5
| 3.2.20 |
| Describe the OBU's security capabilities and features, specifically the device’s Hardware Security Module, integration with certificate authority, and support of production level certificates. |
| 3.2.21 |
| Describe the company's commitment to providing engineering-level support (support directly from a member of the OBU manufacturer’s engineering team on hardware and software issues) and how quickly support will be provided. |
| 3.2.22 |
| Describe the device’s level of compliance with Buy America provisions. |
0.5
| 3.2.23 |
| Do you have experience using multiple vendors for security certificates with this device? If so, please describe this. |
0.5
| 3.2.24 |
| Describe the installation and transferability of the compact OBU. Specifically, address the time required for a non-technical user to install or move the unit between vehicles, and whether the unit supports non-permanent mounting (e.g., suction mount, friction pad). |
| 3.2.25 |
| Describe the material composition and ruggedization of the OBU housing. Response should address items such as UV resistance, impact resistance, thermal venting, mounting integrity, IP rating, etc.) |
0.5
| 3.2.26 |
| Describe the ability to power the device via common in-vehicle options (cigarette lighter, USB port, etc.) to allow for ‘plug and play’ installation. |
| 3.2.27 |
| Describe other features of the OBU that you feel are worth noting that have not been identified. If these features are optional or require additional hardware, fees, or licensing, they must be listed in the Optional Features cost table. |
0.5
TYPE 4 – Roadside Processor (RSP) Vendor Name
Device Name
TYPE 4 – Roadside Processor (RSP) – MMR Matrix
| ITEM |
| MANDATORY MINIMUM REQUIREMENTS (MMR) (Pass/Fail) |
| Y / N |
| 4.1.1 |
| RSP shall be new production level devices (not beta or R&D versions) available for purchase. |
| 4.1.2 |
| RSP manufacturer shall have produced C-V2X RSPs that have been purchased and installed by customers. |
| 4.1.4 |
| The RSP software shall comply with SAE J2735, SAE J3224, and CTI 4501 standards for V2X message handling. The unit must be capable of: |
· Generating and Processing: SPaT (via TSCBM), SSM, SRM, and RTCM messages.
· Processing Only: MAP and SDSM messages."
| 4.1.5 |
| RSP shall store SAE J2735 MAP messages. |
| 4.1.6 |
| RSP software shall send SPaT, MAP, SDSM, and RTCM messages to the local RSU for broadcast. |
| 4.1.7 |
| RSP software shall send signal priority/preemption calls to the local traffic signal controller based on an SRM it receives. |
| 4.1.8 |
| RSP software shall be capable of forwarding SPaT, MAP, SSM, RTCM, SRM, BSMs, and other V2X messages to multiple devices (via IP address) on the UDOT ITS network.. |
| 4.1.9 |
| RSP vendor shall provide engineering-level support to UDOT or its representative at no cost during the warranty period. |
| 4.1.10 |
| RSP shall have at least a 2-Year Warranty from date of purchase. |
| 4.1.11 |
| RSP shall be protected by network firewalls that restrict inbound and outbound traffic to only approved IP addresses and ports necessary for system operations. |
| 4.1.12 |
| RSP overall uptime shall be greater than 99%. |
TYPE 4 – Roadside Processor (RSP) – MRC Matrix
MANDATORY RESPONSE COMMENTS (MRC) (Scored)
Maximum Points Possible = 75
| ITEM |
| Required Responses |
| Comment |
| Weighting Factor |
| 4.2.1 |
| Describe the company’s experience in producing and delivering RSP equipment and solutions. |
| 4.2.2 |
| What is the lead time to deliver 40 units? |
| 4.2.3 |
| Provide 3 references, including contact information (Name, Entity, Phone and Email), of three projects with deployments of the equipment being offered. |
| 4.2.4 |
| Describe the RSP’s support for the following V2X SAE standardized messages: |
· SPaT
· MAP
· SSM
· RTCM
· SRM
· BSM
· SDSM
Highlight the J2735 data elements that are contained in each of these messages.
| 4.2.5 |
| Does the RSP support acting as an NTRIP server or client? Describe the process for configuring a fixed WGS84 location for RTCM 3.2 message generation. |
0.5
| 4.2.6 |
| Are the timestamp data elements included in messages accurate to within 10 milliseconds? |
| 4.2.7 |
| Is the generated SPaT message compliant with SAE J2735 and CTI 4501? Does it contain all required data elements? |
| 4.2.8 |
| What is the V2X message latency from generate to RSU broadcast? |
| 4.2.9 |
| Describe the ability and process by which applications can be written to and run on the RSP. |
| 4.2.10 |
| How is the RSP configured (via a network API such as SNMP, RESTful, etc.)? |
0.5
| 4.2.11 |
| Does the RSP support IFM (Immediate Forwarding) tables for routing MAP, SPaT, and SSM messages to the RSU? Describe the supported file formats for MAP data (e.g. JSON, NMAP). |
| 4.2.12 |
| Describe the RSP’s visual diagnostic indicators. Does the device provide real-time LED feedback for CV message reception and contact closure status? |
0.5
| 4.2.13 |
| Describe the company’s commitment to providing engineering-level support (support directly from a member of the RSP manufacturer’s engineering team on hardware and software issues) and how quickly support will be provided. |
| 4.2.14 |
| Describe the way the RSP is installed in the traffic signal cabinet, i.e. installed in the detector rack slots or in its own enclosure? Describe how it communicates with the traffic signal controller. |
1.5
| 4.2.15 |
| Describe the device’s level of compliance with Buy America provisions. |
0.5
| 4.2.16 |
| Describe other features of the RSP that you feel are worth noting that have not been identified. If these features are optional or require additional hardware, fees, or licensing, they must be listed in the Optional Features cost table. |
0.5
TYPE 5 – Human Machine Interface (HMI) Vendor Name
Device Name
TYPE 5 – Human Machine Interface – MMR Matrix
| ITEM |
| MANDATORY MINIMUM REQUIREMENTS (MMR) (Pass/Fail) |
| Y / N |
| 5.1.1 |
| HMI shall be new production level devices (not beta or R&D versions) available for purchase. |
| 5.1.2 |
| HMI manufacturer shall have produced C-V2X HMIs that have been purchased and installed by customers. |
| 5.1.3 |
| HMI shall be compatible with C-V2X OBU. (HMI shall support a dedicated data interface with the OBU) |
| 5.1.4 |
| HMI shall be capable of providing alerts/warnings. |
| 5.1.5 |
| HMI shall support automated power-state management (e.g., automatically booting upon vehicle ignition and entering a low-power sleep mode upon vehicle shut-off). |
| 5.1.6 |
| HMI shall be capable of translating ITIS codes and J2735 message elements into a driver-recognizable alert (e.g., visual icon, voice announcement, or specific auditory tone/alert) appropriate for the device’s form factor. |
| 5.1.7 |
| HMI vendor shall provide engineering-level support to UDOT or its representative at no cost during the warranty period. |
| 5.1.8 |
| HMI shall have at least a 2-Year Warranty from date of purchase. |
TYPE 5 – Human Machine Interface – MRC Matrix
MANDATORY RESPONSE COMMENTS (MRC) (Scored)
Maximum Points Possible = 55
| ITEM |
| Required Responses |
| Comment |
| Weighting Factor |
| 5.2.1 |
| Describe the company’s experience in producing and delivering C-V2X HMI equipment and solutions. |
| 5.2.2 |
| What is the lead time to deliver 40 units? |
| 5.2.3 |
| Provide 3 references, including contact information (Name, Entity, Phone, and Email), of three different deployments of the equipment being offered. |
| 5.2.4 |
| Describe how the HMI interfaces with the OBU to create messages, warnings, and alerts. |
| 5.2.5 |
| Describe the end-to-end latency from the moment the OBU receives a V2X message to the moment the HMI renders the alert. Specifically, address application processing time and display refresh latency. |
| 5.2.6 |
| Describe the level of safety regarding driver distraction (e.g., HMI compliance with NHTSA Driver Distraction Guidelines or SAE J2364). |
0.5
| 5.2.7 |
| Describe the device’s multimodal alerting function(s). Does it use auditory alerts? Is it displayed on a screen? Haptic feedback (compatibility with steering wheel vibration or seat shaking)? Spatial Audio (capability to provide directional audio)? |
| 5.2.8 |
| Describe the HMI’s ‘alert hierarchy’. How does the device prioritize multiple simultaneous messages? If the device is non-graphical, describe how complex ITIS codes are simplified for the driver. |
0.5
| 5.2.9 |
| Describe how the HMI is mounted in the vehicle. |
0.5
| 5.2.10 |
| Describe the company’s commitment to providing engineering-level support (support directly from a member of the HMI manufacturer’s engineering team on hardware and software issues) and how quickly support will be provided. |
| 5.2.11 |
| Describe other features of the HMI that you feel are worth noting that have not been identified. If these features are optional or require additional hardware, fees, or licensing, they must be listed in the Optional Features cost table. |
0.5
TYPE 6 – On-Board Processor (OBP) Vendor Name
Device Name
TYPE 5 – On-Board Processor – MMR Matrix
| ITEM |
| MANDATORY MINIMUM REQUIREMENTS (MMR) (Pass/Fail) |
| Y / N |
| 6.1.1 |
| OBP shall be new production level devices (not beta or R&D versions) available for purchase. |
| 6.1.2 |
| OBP manufacturer shall have produced C-V2X OBPs that have been purchased and installed by customers. |
| 6.1.3 |
| OBP shall support an operating voltage range of at least 9V to 24v dc to ensure compatibility with light and heavy-duty vehicle electrical systems. |
| 6.1.4 |
| OBP shall be able to interface with the vehicle through J1939 CAN communication port. |
| 6.1.5 |
| OBP shall be capable of processing SAE J2735 message sets. |
| 6.1.6 |
| OBP shall support RTCM for high-precision GNSS positioning. |
| 6.1.7 |
| OBP vendor shall provide engineering-level support to UDOT or its representative at no cost during the warranty period. |
| 6.1.8 |
| OBP shall have at least a 2-Year Warranty from date of purchase. |
TYPE 6 – On-board Processor (OBP) – MRC Matrix
MANDATORY RESPONSE COMMENTS (MRC) (Scored)
Maximum Points Possible = 55
| ITEM |
| Required Responses |
| Comment |
| Weighting Factor |
| 6.2.1 |
| Describe the company’s experience in producing and delivering C-V2X OBP equipment and solutions. |
| 6.2.2 |
| What is the lead time to deliver 40 units? |
| 6.2.3 |
| Provide 3 references, including contact information (Name, Entity, Phone, and Email), of three different V2X deployments of the equipment being offered. |
| 6.2.4 |
| Describe the OBP’s physical interface and connection points. Specifically, address the use of pigtails for power, CAN, and relay I/O. |
0.5
| 6.2.5 |
| Describe the OBP’s vehicle role configuration capabilities. Does the device support specific, customizable logic for ambulance, fire, DOT fleet vehicles, and transit roles? |
1.5
| 6.2.6 |
| Describe the transit signal priority (TSP) algorithms supported by the device. |
| 6.2.7 |
| Describe the OBP’s ability to track and log SRM details. |
| 6.2.8 |
| Describe the device’s diagnostic capabilities. Does it provide faceplate LEDs for real-time status of inputs and outputs? |
0.5
| 6.2.9 |
| Describe the web interface used for device configuration and logic updates. Is it accessible via ethernet port? |
| 6.2.10 |
| Describe the company’s commitment to providing engineering-level support (support directly from a member of the OBP manufacturer’s engineering team on hardware and software issues) and how quickly support will be provided. |
| 6.2.11 |
| Describe other features of the OBP that you feel are worth noting that have not been identified. If these features are optional or require additional hardware, fees, or licensing, they must be listed in the Optional Features cost table. |
0.5
Response Instructions Page 2 of 2