The file's text, extracted by GovTribe without its formatting.
NOTICE OF SOLICITATION
SERIAL # 260013-C
INVITATION FOR BIDS FOR ROADSIDE UNIT AND ONBOARD UNIT DEVICES (CVAZ)
Notice is hereby given that Maricopa County is conducting this Invitation for Bids electronically through an outside e-procurement platform, BidNet Direct, until 2:00 p.m. Mountain Standard Time (MST) on October 14, 2025, for SERIAL# 260013-C INVITATION FOR BIDS FOR ROADSIDE UNIT AND ONBOARD UNIT DEVICES (CVAZ) for Maricopa County.
ONLY RESPONSES THAT ARE SUBMITTED THROUGH THE E-PROCUREMENT PLATFORM, BIDNET DIRECT (www.bidnetdirect.com), WILL BE CONSIDERED.
For submission instructions, see Exhibit 1.
For assistance with the e-procurement platform, contact BidNet Direct Vendor Support during regular business hours: Phone: 1-800-835-4603 or Email: support@bidnet.com. The BidNet Direct Support Department is available Monday - Friday from 8:00 a.m. to 8:00 p.m. EST.
All responses shall be submitted electronically through the e-procurement platform prior to the bid closing. The bid will be listed under “260013-C ROADSIDE UNIT AND ONBOARD UNIT DEVICES (CVAZ).”
The Maricopa County Procurement Code (Code) governs this procurement and is incorporated by reference. Any protest concerning this Invitation for Bids must be filed with the procurement officer in accordance with Section MC1-905 of the Code.
All standard terms and conditions concerning this Invitation for Bids can be located at https://www.maricopa.gov/DocumentCenter/View/6453.
Any addenda to this Invitation for Bids will be posted on the Maricopa County Office of Procurement Services website under the solicitation serial number. This information will also be posted online at www.bidnetdirect.com.
FAILURE TO REVIEW ANY ADDENDA DOES NOT NEGATE YOUR INITIAL OFFER AND HOLDS THE RESPONDENT RESPONSIBLE FOR ANY CHANGES PRIOR TO BID CLOSING.
INQUIRIES: SUBMIT ALL INQUIRIES ABOUT THIS INVITATION FOR BIDS BY THE QUESTION DATE/TIME DEADLINE POSTED IN BIDNET DIRECT USING THE LINK IN THE “Q&A” TAB FOR THIS SOLICITATION.
Administrative inquiries may be directed to:
ryan bennett, PROCUREMENT OFFICER
TELEPHONE: (602) 506-1460
preferred method Ryan.bennett@maricopa.gov
THERE WILL BE NO PRE-BID CONFERENCE FOR THIS SOLICITATION.
NOTE: Maricopa County publishes its solicitations online and they are available for viewing and/or downloading at https://www.maricopa.gov/2190/Solicitations.
AZ UTRACS Registration – Prime contractors and all subcontractors including DBEs must be registered in the AZ UTRACS web portal https://utracs.azdot.gov/.
All bidders must complete an on-line bidders list at www.azutracs.com, and submit the corresponding Bidders List email confirmation notice to the Office of Procurement Services by 4:00 p.m. MST on the fifth calendar day after bids are opened. Bidders who do not submit the Bidders List Email Confirmation are deemed non-responsive.
TABLE OF CONTENTS
NOTICE OF SOLICITATION
TABLE OF CONTENTS
ACCRONYMS
SECTIONS
1.0 INTENT
2.0 SPECIFICATIONS
3.0 PURCHASING REQUIREMENTS
4.0 CONTRACTUAL TERMS & CONDITIONS
5.0 INSTRUCTIONS TO RESPONDENTS (Note that this section does not become part of any resultant contract.)
ATTACHMENTS
| ATTACHMENT A: | VENDOR INFORMATION |
| ATTACHMENT B: | AGREEMENT PAGE |
| ATTACHMENT C: | REFERENCES |
| ATTACHMENT D: | PRICING SHEET |
| ATTACHMENT E: | TRAINING PLAN |
EXHIBITS
| EXHIBIT 1: | BIDNET DIRECT ELECTRONIC SUBMISSION INSTRUCTIONS |
| EXHIBIT 2: | SAMPLE INSURANCE CERTIFICATE |
| EXHIBIT 3: | OFFICE OF PROCUREMENT SERVICES CONTRACTOR TRAVEL AND PER DIEM POLICY |
| EXHIBIT 4: | SOLE-PROPRIETOR WAIVER |
| EXHIBIT 5 | DEPLOMENT AREA |
| EXHIBIT 6 | SYSTEM ARCHITECTURE DIAGRAM |
| EXHIBIT 7 | RSU SUBJECT OF PROCUREMENT |
| EXHIBIT 8 | RSP SUBJECT OF PROCUREMENT |
| EXHIBIT 9 | OBU SUBJECT OF PROCUREMENT |
| EXHIBIT 10 | MARICOPA COUNTY DEPARTMENT OF TRANSPORTATION SUPPLEMENTAL TERMS AND CONDITIONS |
| EXHIBIT 11 | 2025 TITLE VI ASSURANCES |
| EXHIBIT 12 | SMALL BUSINESS ENTERPRISE (SBE) PROGRAM PARTICIPATION REPORTING FORM |
| EXHIBIT 13 | LOCAL PUBLIC AGENCY (LPA) PROMPT PAY AND PAYMENT REPORTING PROVISIONS |
| EXHIBIT 14 | LPA EPRISE NO GOAL CONSTRUCTION |
| EXHIBIT 15 | BUILD AMERICA, BUY AMERICA STORED SPECIFICATIONS |
| EXHIBIT 16 | DAVIS-BACON WAGE DETERMINATION AND RELATED ACTS |
| EXHIBIT 17 | FEDERAL IMMIGRATION AND NATIONALITY ACT |
| EXHIBIT 18 | EXECUTIVE ORDER 2009-09.9.2025 |
| EXHIBIT 19 | EQUAL EMPLOYMENT OPPORTUNITY COMPLIANCE REPORTS |
| EXHIBIT 20 | NOTICE REQ FOR AFFIRMATIVE ACTION - EXECUTIVE ORDER 11246 |
| EXHIBIT 21 | EQUAL OPPORTUNITY CLAUSE AND THE FILING OF REQUIRED REPORTS |
| EXHIBIT 22 | AFFIDAVIT OF COMPLIANCE |
| EXHIBIT 23 | NON-COLLUSION AFFIDAVIT |
ACRONYMS
| AVL: | | Automatic Vehicle Location System |
| BABA: | | Buy America/Build America |
| BSM: | | Basic Safety Message |
| CAV: | | Connected and Automated Vehicles |
| CORS: | | Continuously Operating Reference Station |
| CRL: | | Certificate Revocation List |
| CTI: | | California Test Interval/Connected Transportation Interoperability Standard |
| CVAZ: | | Connected Vehicle Acceleration Zone |
| EVP: | | Emergency Vehicle Preemption |
| FSP: | | Freight Signal Priority |
| GNSS: | | Global Navigation Satellite System |
| GPS: | | Global Positioning System |
| HMI: | | Human-Machine Interface |
| IEEE: | | Institute of Electrical and Electronics |
| IP: | | Internet Protocol |
| IPv4: | | Internet Protocol version 4 |
| IPv6: | | Internet Protocol version 6 |
| LTS: | | Long-Term Support |
| MAG: | | Maricopa Association of Government |
| MAP: | | Map Data |
| MCDOT: | Maricopa County Department of Transportation | |
| MEP: | | Mobile Edge Processor |
| NIST: | | National Institute of Standards and Technology |
| NTCIP: | | National Transportation Communications for Intelligent Transportation System Protocol |
| OBU: | | On-Board Unit |
| PoE: | | Power over Ethernet |
| PSID: | | Provider Service Identifier |
| RJ-45: | | Ethernet RJ-45 |
| RSP: | | Roadside Processor |
| RSU: | | Roadside Unit |
| RTCM: | | Radio Technical Commission for Maritime |
| SAE: | | Society of Automotive Engineers |
| SCMS: | | Security Credential Management System |
| SDSM: | | Sensor Data Sharing Messages |
| SNMPv3: | Simple Network Management Protocol version 3 | |
| SPaT: | | Signal Phase and Timing |
| SRM: | | Signal Request Message |
| SSH: | | Secure Shell |
| SSM: | | Signal Status Message |
| TSC: | | Traffic Signal Controller |
| TSCBM: | Traffic Signal Controller Broadcast Message | |
| TSP: | | Transit Signal Priority |
| V2X: | | Vehicle-to-Everything |
| VRU: | | Vulnerable Road User |
| WAP: | | Warranty Administration Plan |
| WAVE: | | Wireless Access in Vehicular Environments |
| WRA: | | WAVE Routing Advertisement |
| WSA: | | WAVE Service Advertisements |
| 5GAA: | | 5G Automotive Association |
SERIAL # 260013-C
INVITATION FOR BIDS FOR ROADSIDE UNIT AND ONBOARD UNIT DEVICES (CVAZ)
1.0 INTENT
1.1 The intent of this Invitation for Bids (IFB) is to establish sources for the procurement, configuration, and delivery of Connected Vehicle (CV) equipment to support Maricopa County Department of Transportation's (MCDOT) Connected Vehicle Acceleration Zone (CVAZ) initiative. This solicitation will include procuring Roadside Units (RSU), Roadside Processors (RSP), and On-Board Units (OBU).
1.2 Other governmental entities under agreement with Maricopa County (County) may have access to services provided hereunder (see also Sections 3.21 and 3.22 below).
1.3 The County reserves the right to add additional contractors, at the County’s sole discretion, in cases where the currently listed contractors are of an insufficient number or skill set to satisfy the County’s needs or to ensure adequate competition on any project or task order work.
1.4 The County reserves the right to award this contract to multiple vendors. The County reserves the right to award in whole or in part, by item or group of items, by section or geographic area, or make multiple awards, where such action serves the County’s best interest.
2.0 SPECIFICATIONS
2.1 BACKGROUND INFORMAITON
2.1.1 Location of Work: MCDOT CVAZ is focused on the central core of the Phoenix metropolitan region, targeting the jurisdictions of Phoenix, Tolleson, Avondale, parts of unincorporated Maricopa County, as well as along Grand Avenue/US60. Emergency Vehicle Preemption (EVP), Transit Signal Priority (TSP), Vulnerable Road User (VRU) Safety, and Freight Signal Priority (FSP) Vehicle-to-Everything (V2X) applications will be supported. EVP intersections are located along major thoroughfares, which are generally spaced at one-mile increments within the regional street network. TSP routes include those with a high level of intersection delay and highest ridership routes (greater than 2,000 daily riders) where there are visual gaps at signalized intersections. Additional TSP locations are along Grand Avenue, an important express bus route along US60. VRU intersections are based on the Maricopa Association of Government’s (MAG) list of top 100 intersections in the Phoenix metropolitan area for crash risk.
2.1.2 FSP intersections are those along local and regionally significant freight corridors, as identified by the MAG 2017 regional freight study.
2.2 GENERAL REQUIREMENTS
2.2.1 The contractor may submit for one or more of the following items in technical specifications (RSU, RSP Hardware, RSP Software, or OBU).
2.2.2 All contractors that submit a bid by agrees that all parts, components and equipment, supplied will comply to Buy America/Build America (BABA) requirements. If the County purchases any equipment that is later determined not to meet BABA requirements, the contractor shall fully reimburse the County for the cost of the equipment.
2.2.3 Warranty Requirements
2.2.3.1 The contractor shall submit a Warranty Administration Plan (WAP) for each product at the time of bid submission. The WAP must address warranty management for each applicable component (RSU, RSP Hardware, RSP Software, and/or OBU).
2.2.3.2 All items furnished under this contract shall conform to the requirements of this solicitation and be free from defects in design, materials, and workmanship.
2.2.3.3 The warranty period shall be a minimum of five years and shall commence upon written acceptance by the County following successful delivery, installation, and testing.
2.2.3.4 The contractor shall indicate on the pricing sheet the duration of the warranty and any applicable limitations or conditions.
2.2.3.5 The contractor agrees, at its own expense, to provide all labor and parts required to remove, repair, and replace any defective workmanship or materials identified during the warranty period.
2.2.3.6 The contractor shall guarantee that all equipment supplied complies with all applicable regulations.
2.2.4 Training
2.2.4.1 When required, training shall be provided by the contractor in multiple sessions.
2.2.4.2 Contractor shall submit a training plan with their proposal.
2.2.4.3 The first training session shall be for maintenance and troubleshooting. This session shall be a minimum of eight hours in length for each type of field device installed, including communications. This session shall be oriented for the County maintenance staff.
2.2.4.4 The second training session shall be for operations. This session shall be a minimum of eight hours in length for each type of field device installed. This session shall be oriented for the County Traffic Management staff.
2.2.5 Payment
2.2.5.1 The unit price for each item shall be inclusive of all costs associated with delivery, testing, warranty, documentation, training, mounting hardware, and configuration support. No additional charges will be allowed unless expressly authorized by the County in writing.
2.2.5.2 All equipment delivered shall be subject to County inspection and preliminary acceptance prior to installation and testing.
2.2.5.3 Payment for configuration support and testing labor shall be made only upon successful demonstration that the delivered equipment is fully operational and functions in accordance with the specifications.
2.2.5.4 Final payment for each item shall be made only after the item has been successfully installed, properly configured, and has passed County testing with verification of full functionality
2.3 TECHNICAL SPECIFICATIONS
2.3.1 Roadside Units (RSUs):
2.3.1.1 RSUs shall come equipped with antennas, Power-over-Ethernet adaptors\injectors, mounting brackets and hardware, and any other ancillary components required for complete installation and operation.
2.3.1.2 After the RSUs are installed, the RSU supplier shall assist MCDOT and the project team with configuring.
2.3.1.3 RSUs shall be configured to sign, and broadcast Signal Phase and Timing (SPaT) and Map Data (MAP), based in J4501.
2.3.1.4 RSUs shall be configured to sign and broadcast Society of Automotive Engineers (SAE) J2735 Signal Status Message (SSMs).
2.3.1.5 RSUs shall be configured to sign and broadcast SAE J3224 Sensor Data Sharing Messages (SDSM).
2.3.1.6 RSUs shall be configured to sign and broadcast Institute of Electrical and Electronics (IEEE) WAVE Service Advertisements (WSAs) as defined in the RSU.
2.3.1.7 RSUs shall be configured to verify and forward SAE J2735 Basic Safety Message (BSMs) and Signal Request Message (SRMs) to the roadside processor.
2.3.1.8 All RSUs components, configuration, and installation shall meet or exceed the requirements contained in the RSU Requirements Table.
RSU REQUIREMENTS
| Requirement ID |
| Description |
Roadside Unit Functional Requirements
| RSU-FR-001-v1.0 |
| An RSU shall have California Test Interval (CTI) 4001 "immediate forward" capability. |
| RSU-FR-002-v1.0 |
| An RSU shall have CTI 4001 "store and repeat" capability. |
| RSU-FR-003-v1.0 |
| An RSU shall have CTI 4001 "message forwarding" capability. |
| RSU-FR-004-v1.0 |
| An RSU shall be configurable. |
| RSU-FR-005-v1.0 |
| The RSU shall allow the user to configure parameters to generate the WSA. |
| RSU-FR-006-v1.0 |
| An RSU should forward the IEEE 1609.3 WSA to the CVAZ Message Exchange Platform. |
| RSU-FR-007-v1.0 |
| An RSU shall provide the RSU status to the V2X management system. |
| RSU-FR-008-v1.0 |
| An RSU shall operate on the upper 30-megahertz (MHz) of the 5.9 gigahertz (GHz) (5.895-5.925 GHz) safety band. |
| RSU-FR-009-v1.0 |
| An RSU shall be capable of supporting both 10 and 20 MHz channel. |
| RSU-FR-010-v1.0 |
| An RSU shall support National Transportation Communications for Intelligent Transportation System Protocol (NTCIP) 1218v1.038 for diagnostic and health monitoring functions. |
| RSU-FR-011-v1.0 |
| An RSU shall support remote login such that an authorized device administrator can modify configuration settings (through Secure Shell (SSH) and V2X Management System). |
| RSU-FR-012-v1.0 |
| An RSU shall support remote firmware updates (through SSH and V2X Management System). |
| RSU-FR-013-v1.0 |
| An RSU shall be compliant with mandatory requirements in CTI 4001. |
| RSU-FR-014-v1.0 |
| An RSU shall be compliant with IEEE 1609.2.1. |
| RSU-FR-015-v1.0 |
| An RSU shall be compliant with IEEE 1609.3. |
| RSU-FR-016-v1.0 |
| An RSU shall be compliant with SAE J3161/0 and Third Generation Partnership Project (3GPP) 36.521-1. |
| RSU-FR-017-v1.0 |
| An RSU shall be powered by an IEEE 802.3 AT Power over Ethernet (PoE) injector. |
| RSU-FR-018-v1.0 |
| An RSU shall be compliant with applicable sections of Title 47 of the Code of Federal Regulations Part 15, Subpart C. |
Roadside Unit Interface Requirements
| RSU-IR-001-v1.0 |
| An RSU shall have at least one Ethernet Registered Jack – 45 (RJ-45) port for network connection. |
| RSU-IR-002-v1.0 |
| An RSU shall support both Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6) network protocols over ethernet. |
| RSU-IR-003-v1.0 |
| An RSU shall support all management through the RJ-45 port. |
| RSU-IR-004-v1.0 |
| An RSU shall communicate with the V2X management system, data system, and other systems and hardware using Simple Network Management Protocol version 3 (SNMPv3). |
| RSU-IR-005-v1.0 |
| An RSU shall utilize Global Positioning System (GPS) for time synchronization. |
| RSU-IR-006-v1.0 |
| An RSU shall communicate with the Security Credential Management System (SCMS) over an IPv4 network connection. |
| RSU-IR-008-v1.0 |
| An RSU should support IPv6 tunneling over IPv4. |
| RSU-IR-009-v1.0 |
| An RSU should act as an IPv6 Gateway to enable OBUs to request and download IEEE 1609.2 Certificates from MCDOTs SCMS. |
| RSU-IR-010-v1.0 |
| An RSU shall broadcast SAE J2735 Radio Technical Commission for Maritime (RTCM) received from the Roadside Processor (RSP) using the Immediate Forwarding functionality. |
| RSU-IR-011-v1.0 |
| An RSU shall broadcast SAE J2735 SPaT received from the RSP using the Immediate Forwarding functionality. |
| RSU-IR-012-v1.0 |
| An RSU shall broadcast SAE J2735 MAP received from the RSP using the Immediate Forwarding functionality. |
| RSU-IR-013-v1.0 |
| An RSU shall broadcast J3224 SDSM received from the RSP using the Immediate Forwarding functionality. |
| RSU-IR-014-v1.0 |
| An RSU shall broadcast J2735 SSM received from the RSP using the Immediate Forwarding functionality. |
| RSU-IR-015-v1.0 |
| An RSU shall generate and broadcast IEEE 1609.3 Wireless Access in Vehicular Environment (WAVE) Service Advertisements (WSA). |
| RSU-IR-016-v1.0 |
| An RSU shall forward J2735 SRM to the RSP. |
| RSU-IR-017-v1.0 |
| An RSU shall forward SAE J2735 messages, including but not limited to SPaT, MAP, SSM, Traveler Information Message (TIM), RTCM, and SDSM that it broadcasts to multiple external network hosts (e.g. V2X management system, Data System.) |
| RSU-IR-018-v1.0 |
| An RSU shall forward SAE J2735 messages received from nearby RSUs, including but not limited to SPaT, MAP, SSM, TIM, RTCM, and SDSM to multiple external network hosts (e.g. RSP, V2X management system, Data System.) |
| RSU-IR-019-v1.0 |
| An RSU shall forward SAE J2735 messages received from nearby OBUs, including but not limited to BSM and SRM, to multiple external network hosts (e.g. RSP, V2X management system, Data System.) |
| RSU-IR-020-v1.0 |
| An RSU shall be delivered with a National Electrical Manufacturers Association (NEMA) Technical Standard 2 (TS2) PoE, IEEE 802.3 AT, PoE injector. |
| RSU-IR-021-v1.0 |
| An RSU shall receive location and time data from Global Navigation Satellite System (GNSS). |
Roadside Unit Performance Requirements
| RSU-PR-001-v1.0 |
| The IEEE 1609.3 WSA shall reflect the current service configuration. |
| RSU-PR-002-v1.0 |
| The RSU shall broadcast the WSA once per second. |
| RSU-PR-003-v1.0 |
| An RSU shall broadcast between 9-11 J2735 MAP messages in a 10-second interval. |
| RSU-PR-004-v1.0 |
| An RSU shall broadcast 90-110 J2735 SPaT messages in a 10-second interval. |
| RSU-PR-005-v1.0 |
| An RSU shall broadcast between 90-110 J2735 SSM messages in a 10-second interval when conditions to broadcast SSM have been met. |
| RSU-PR-006-v1.0 |
| An RSU shall broadcast between 90-110 J3224 SDSM messages in a 10-second interval when conditions to broadcast SDSM have been met. |
| RSU-PR-007-v1.0 |
| The system clock of an RSU shall be accurate to within 10 milliseconds of the Universal Time Coordinated (UTC) reference. |
| RSU-PR-008-v1.0 |
| The RSU V2X message broadcast range shall be sufficient to support application requirements. |
| RSU-PR-009-v1.0 |
| An RSU shall have an overall uptime greater than 99 percent. |
| RSU-PR-010-v1.0 |
| An RSU shall have a minimum of 64 Megabyte (MB) Static Dynamic Radom Access Memory (SDRAM). |
| RSU-PR-011-v1.0 |
| An RSU shall have a minimum of a 500MHz Central Processing Unit (CPU) speed. |
| RSU-PR-012-v1.0 |
| An RSU shall be OmniAir certified for Cellular Vehicle-to-Everything (C-V2X) Release 1 or provide a letter from OmniAir stating the RSU (make and model) is actively in the OmniAir certification process. |
| RSU-PR-013-v1.0 |
| An RSU shall have associated documentation that indicate it has been tested at events such as OmniAir Plugfests, 5G Automotive Association (5GAA) PlugFests, etc. |
| RSU-PR-014-v1.0 |
| An RSU shall be time synchronized with other system devices. |
Roadside Unit Data Requirements
| RSU-DR-001-v1.0 |
| The IEEE 1609.3 WSA shall broadcast as Provider Service Identifier (PSID) 0p80-07. |
| RSU-DR-002-v1.0 |
| The IEEE 1609.3 WSA shall contain the SSM PSID, 0pE0-00-00-15, to advertise the Signal Priority service. |
| RSU-DR-003-v1.0 |
| An IEEE 1609.3 WSA should contain the IPv6 Services PSID, 0pEF-FF-FF-FE, to advertise the Internet Protocol (IP) Service. |
| RSU-DR-004-v1.0 |
| An RSU should broadcast WSAs containing WAVE Routing Advertisements (WRA) comprised of IPv6 network information to be utilized by OBUs. |
| RSU-DR-005-v1.0 |
| An RSU should support over-the-air IPv6 communications with OBUs. |
Roadside Unit Security Requirements
| RSU-SR-001-v1.0 |
| All RSUs shall comply with IEEE 1609.2. |
| RSU-SR-01a-v1.0 |
| An RSU shall be compliant with IEEE 1609.2.1. |
| RSU-SR-002-v1.0 |
| All RSUs shall be provisioned with valid IEEE 1609.2 enrollment certificates (by the supplier) prior to deployment. |
| RSU-SR-003-v1.0 |
| An RSU shall sign all outgoing messages for broadcast with a valid IEEE 1609.2 application certificate. |
| RSU-SR-004-v1.0 |
| An RSU shall cease transmission of messages if no valid IEEE 1609.2 application certificates are available. |
| RSU-SR-005-v1.0 |
| RSUs shall be capable of performing certificate verification on received messages, according to IEEE 1609.2. |
| RSU-SR-006-v1.0 |
| An RSU shall reject V2X messages that fail signature verification or are signed with expired or revoked certificates. |
| RSU-SR-007-v1.0 |
| RSUs should download and utilize the latest Certificate Revocation List (CRL) from the SCMS. |
| RSU-SR-008-v1.0 |
| RSUs should reject all messages received from any source listed on the current CRL. |
| RSU-SR-009-v1.0 |
| An RSU shall have no more than two weeks of IEEE 1609.2 application certificates loaded at a time. |
| RSU-SR-010-v1.0 |
| An RSU shall request to receive additional IEEE 1609.2 application certificates at least once per week from the SCMS. |
| RSU-SR-011-v1.0 |
| An RSU shall implement IEEE 1609.2 certificate download and renewal processes over secure, encrypted, end-to-end connections. |
| RSU-SR-012-v1.0 |
| Access to an RSU shall be controlled using role-based access control, ensuring users can access only the functions necessary for their role. |
| RSU-SR-013-v1.0 |
| RSU user accounts shall be authenticated using a unique username and a strong password meeting National Institute of Standards and Technology (NIST) SP 800-63B guidelines (minimum length, complexity, and password history requirements). |
| RSU-SR-014-v1.0 |
| All RSUs shall be protected by network firewalls that restrict inbound and outbound traffic to only approved IP addresses and ports necessary for system operations. |
2.3.2 Roadside Processors (RSPs) Hardware
2.3.2.1 RSPs shall come equipped with all necessary 120v power cables, mounting brackets, and any other ancillary components required for complete installation and operation.
2.3.2.2 RSPs for the CVAZ deployment shall meet or exceed the hardware requirements in RSP Hardware Requirements table.
RSP HARDWARE REQUIREMENTS
| Requirement ID |
| Description |
Roadside Processor Hardware Requirements
| RSP-HW-001-v1.0 |
| RSP shall support an operating temperature of -29°F to 165°F (-34°C to 74°C). |
| RSP-HW-002-v1.0 |
| RSP shall support operating Humidity up to 95 percent Relative Humidity (RH). |
| RSP-HW-003-v1.0 |
| RSP shall have a Web Interface for control and configuration |
| RSP-HW-004-v1.0 |
| RSP at a minimum shall have Power, Single Board Computer (SBC), Hard Disk Drive (HDD), and Heartbeat light-emitting diode (LEDs). |
| RSP-HW-005-v1.0 |
| RSP shall support 10V-36V, 6W of power. |
| RSP-HW-006-v1.0 |
| RSP shall have a minimum of two Ethernet, two USB, two RS-232, four RS-485, two Digital out, two Analog input, one HDMI, Audio in, and Audio out connectors. |
| RSP-HW-007-v1.0 |
| RSP shall have a GPS receiver with external antenna port. |
| RSP-HW-008-v1.0 |
| RSP shall have a minimum of an Intel Core i3 Dual Core 1.7 GHz processor. |
| RSP-HW-009-v1.0 |
| RSP shall have a minimum of 4GB of random-access memory (RAM). |
| RSP-HW-0010-v1.0 |
| RSP shall have a minimum hard drive size of 16GB SSD. |
| RSP-HW-0011-v1.0 |
| RSP shall have an Operating System equivalent to Ubuntu 16.04 Long-Term Support (LTS). |
2.3.3 Roadside Processor (RSP) Software
2.3.3.1 Contractors shall furnish all required software to generate SPaT messages, based on SAE J4501, SAE J2735 Signal Status Messages (SSM), SAE J3224 SDMS, and SAE J2735 RTCM messages. The RSP shall store SAE J2735 MAP messages. The RSP software shall send SPaT, MAP, SDSM, and RTCM messages to the local RSU and Mobile Edge Processor (MEP), as applicable, for broadcast. RSP software shall send signal priority\preemption calls to the local traffic signal controller. RSP software shall send SPaT, MAP, SSM, RTCM, SRM, BSMs, and other V2X messages to the V2X Management System. RSP software for the CVAZ deployment shall meet or exceed the requirements contained In RSP requirement software table.
2.3.3.2 After installation, the responder shall assist MCDOT and the project team with configuring RSP in deployment.
2.3.3.3 RSPs shall be configured to generate and send SPaT messages to the local RSU and MEP.
2.3.3.4 RSPs shall be configured to store and send MAP messages to the local RSU and MEP.
2.3.3.5 RSPs shall be configured to generate and send SSMs to the local RSU and MEP.
2.3.3.6 RSPs shall be configured to generate and send SDSMs to the local RSU and MEP.
2.3.3.7 RSPs shall be configured to send signal priority\preemption calls to the local traffic signal controller.
2.3.3.8 RSPs shall be configured to forward SPaT, MAP, SSM, RTCM, SRM, BSMs, and other V2X messages to the V2X Management System.
2.3.3.9 RSP software for the CVAZ deployment shall meet or exceed the requirements contained in the Table below.
RSP SOFTWARE REQUIREMENTS
| Requirement ID |
| Description |
Roadside Processor Functional Requirements
| RSP-FR-001-v1.0 |
| An RSP shall generate J2735 RTCM using position correction information, along with any other user-configured parameters for RTCM generation. |
| RSP-FR-020-v1.0 |
| An RSP shall generate J2735 SPaT using Traffic Signal Controller Broadcast Message (TSCBM), along with any other user-configured parameters for SPaT generation. |
| RSP-FR-003-v1.0 |
| An RSP shall store J2735 MAP messages. |
| RSP-FR-004-v1.0 |
| An RSP shall use detection data to determine if a detected VRU is in a configured conflict zone. |
| RSP-FR-005-v1.0 |
| An RSP shall generate J3224 SDSM using detection data, along with any other user-configured parameters for SDSM generation. |
| RSP-FR-006-v1.0 |
| A RSP shall determine which vehicle type is making a priority\preemption request (freight, emergency, transit) based on SRMs. |
| RSP-FR-007-v1.0 |
| An RSP shall allow a user to configure a list of vehicles “authorized” to receive signal priority or preemption. |
| RSP-FR-008-v1.0 |
| An RSP shall store a list of vehicle IDs “authorized” to receive signal priority or preemption. |
| RSP-FR-009-v1.0 |
| An RSP shall compare the vehicle ID (and/or other data) in J2735 SRM against the authorized vehicle list to determine eligibility for emergency preemption requests. |
| RSP-FR-010-v1.0 |
| An RSP shall compare the vehicle ID (and/or other data) in J2735 SRM against the authorized vehicle list to determine eligibility for transit priority requests. |
| RSP-FR-011-v1.0 |
| An RSP shall use the vehicle ID (and/or other data) in J2735 SRM in a query to the V2X Auth/Payment System to determine eligibility for freight priority requests. |
| RSP-FR-012-v1.0 |
| A RSP shall address conflicts when multiple J2735 SRMs are received simultaneously based on configurable prioritization rules. |
| RSP-FR-013-v1.0 |
| An RSP shall store a list of priority and preemption call types. |
| RSP-FR-014-v1.0 |
| An RSP shall compare the data elements from the J2735 SRM against the list of priority/preemption call types to determine which priority or preemption plan to call on the controller. |
| RSP-FR-015-v1.0 |
| An RSP shall generate J2735 SSM using Traffic Signal Controller (TSC) signal status data, along with any other user-configured parameters for SSM generation (for authorized requests). |
| RSP-FR-016-v1.0 |
| An RSP shall generate J2735 SSMs with a "denied" status if the requesting vehicle ID is not on the "authorized" vehicle list. |
| RSP-FR-017-v1.0 |
| An RSP shall generate J2735 SSM if a priority or preemption plan is not defined for the request with a status of "denied". |
| RSP-FR-018-v1.0 |
| An RSP shall support remote user authenticated access. |
| RSP-FR-020-v1.0 |
| RSP shall send status and monitoring data to the V2X management system. |
Roadside Processor Interface Requirements
| RSP-IR-001-v1.0 |
| An RSP shall receive position corrections data from a Continuously Operating Reference Station (CORS). |
| RSP-IR-002-v1.0 |
| An RSP shall send J2735 RTCM to an RSU. |
| RSP-IR-003-v1.0 |
| An RSP should send J2735 RTCM to the MEP. |
| RSP-IR-004-v1.0 |
| An RSP shall receive TSCBM from a TSC. |
| RSP-IR-005-v1.0 |
| When TSCBM is not available, An RSP should receive J2735 SPaT from the TSC. |
| RSP-IR-006-v1.0 |
| An RSP shall send J2735 SPaT to an RSU. |
| RSP-IR-007-v1.0 |
| An RSP shall send J2735 SPaT to the MEP. |
| RSP-IR-008-v1.0 |
| An RSP shall receive J2735 MAP from the V2X Management System. |
| RSP-IR-009-v1.0 |
| An RSP shall send J2735 MAP to the RSU. |
| RSP-IR-010-v1.0 |
| An RSP shall send J2735 MAP to the MEP. |
| RSP-IR-011-v1.0 |
| An RSP shall receive detection data from Vulnerable Road User Detection Equipment. |
| RSP-IR-012-v1.0 |
| An RSP shall allow a user to input a configurable detection zone geometry for determining if an SDSM should be broadcast. |
| RSP-IR-013-v1.0 |
| An RSP shall send J3224 SDSM to an RSU if a VRU is detected in a configured conflict zone. |
| RSP-IR-014-v1.0 |
| An RSP shall not send J3224 SDSM to an RSU if a VRU is not detected or the VRU is not in configured conflict zone. |
| RSP-IR-015-v1.0 |
| An RSP shall send J3224 SDSM to the MEP if a VRU is detected in a configured conflict zone. |
| RSP-IR-016-v1.0 |
| An RSP shall not send J3224 SDSM to the MEP if a VRU is not detected or the VRU not in a configured conflict zone. |
| RSP-IR-017-v1.0 |
| An RSP shall receive J2735 SRM from an RSU. |
| RSP-IR-018-v1.0 |
| An RSP shall receive J2735 SRM from the MEP. |
| RSP-IR-019-v1.0 |
| An RSP shall allow a user to input a list of priority and preemption call types. This configuration shall map SRM data elements (e.g., Request Type, Vehicle Class, Request ID) to corresponding TSC priority and preemption plan identifiers. |
| RSP-IR-020-v1.0 |
| The RSP shall allow a user to input a configurable value for the amount of time a signal status entry (for a given priority or preemption request with an unchanging status) is included in the SSM. |
| RSP-IR-021-v1.0 |
| An RSP shall send an account status request to the V2X Auth/Payment system (using a unique vehicle identifier - from the J2735 SRM) to determine if a freight vehicle is authorized to receive signal priority. |
| RSP-IR-022-v1.0 |
| An RSP shall receive account status validation results from the V2X Auth/Payment system. |
| RSP-IR-023-v1.0 |
| An RSP shall send an NTCIP 1202 priority or preemption request to the TSC (for authorized requests, and when a priority or preemption plan is defined for the request). |
| RSP-IR-024-v1.0 |
| An RSP shall not send a priority or preemption request to the TSC for unauthorized requests. |
| RSP-IR-025-v1.0 |
| An RSP shall not send a priority or preemption request to the TSC when a priority or preemption plan is not defined for the request. |
| RSP-IR-026-v1.0 |
| An RSP shall send J2735 SSM to an RSU. |
| RSP-IR-027-v1.0 |
| An RSP shall send J2735 SSM to the MEP. |
| RSP-IR-028-v1.0 |
| An RSP shall send J2735 SSM (or other data that indicates the final status of the request) to the V2X Authorization and Payment System for freight requests. |
| RSP-IR-029-v1.0 |
| An RSP shall not send J2735 SSM to an RSU if there are no entries in the signal status list. |
| RSP-IR-030-v1.0 |
| An RSP shall not send J2735 SSM to the MEP if there are no entries in the signal status list. |
| RSP-IR-031-v1.0 |
| An RSP shall communicate with the V2X management system, data system, and other systems and hardware using SNMPv3. |
| RSP-IR-032-v1.0 |
| An RSP shall forward all V2X messages sent to an RSU or MEP (J2735 SPaT, MAP, RTCM, SSM, and J3224 SDSM), to the data system and the V2X Management System. |
| RSP-IR-033-v1.0 |
| An RSP shall send all V2X messages received from the MEP (J2735 SRM and J2735 BSM) to the data system and the V2X Management System. |
Roadside Processor Performance Requirements
| RSP-PR-001-v1.0 |
| Any timestamp data elements included in messages should be accurate to within 10 milliseconds. |
| RSP-PR-019-v1.0 |
| The MsgCount data field of all applicable V2X messages shall increment by 1 when data in the message has changed (other than timestamp data, excluding elements in the SPaT Time Change Details data frame). |
| RSP-PR-004-v1.0 |
| The J2735 SPaT should be CTI 4501 compliant. |
| RSP-PR-005-v1.0 |
| The J2735 SPaT shall contain all required data elements per CTI 4501, except for startTime and nextTime. |
| RSP-PR-006-v1.0 |
| J2735 SPaT and MAP broadcast from the same intersection should have matching intersection and road authority identifiers (Road Authority ID). |
| RSP-PR-007-v1.0 |
| The list of unique signal group ID between J2735 SPaT and MAP broadcast for the same intersection, shall match. |
| RSP-PR-008-v1.0 |
| The revision (message count) should increment by one only when any data elements in the SPaT message change, except for the timestamp in the intersection data frame. Otherwise, the revision (message count) should remain the same. |
| RSP-PR-009-v1.0 |
| The J2735 SPaT enabled lanes list shall only include lanes identified as revocable in the MAP message. |
| RSP-PR-009a-v1.0 |
| The J2735 SPaT enabled lanes list shall accurately reflect the lanes and operations in use at the time the message is broadcast. |
| RSP-PR-010-v1.0 |
| The J2735 SPaT shall contain all movement events for the current movement state. |
| RSP-PR-011-v1.0 |
| The J2735 SPaT should contain movement events for a subsequent movement state, only for movement events in the current movement state with a green or yellow event state (protected-Movement-Allowed, permissive-Movement-Allowed, protected-Clearance, permissive-Clearance). |
| RSP-PR-012-v1.0 |
| The J2735 SPaT Movement events shall be updated at the computation frequency of the traffic signal controller. |
| RSP-PR-013-v1.0 |
| The J2735 SPaT eventState data element should always accurately reflect actual signal indications for all movement events for the current movement state (when linked to a MAP message using the signal group). This includes movements that are controlled by more than one phase, such as protected-permissive turns). |
| RSP-PR-014-v1.0 |
| The J2735 SPaT minEndTime should never decrease. |
| RSP-PR-015-v1.0 |
| The J2735 SPaT maxEndTime should never increase. |
| RSP-PR-016-v1.0 |
| The J2735 SPaT minEndTime shall equal the maxEndTime when the event state is Protected-Clearance or Permissive-Clearance. |
| RSP-PR-017-v1.0 |
| The actual transition from one event state to the next for a given signal group shall occur between the minEndTime and maxEndTime values specified in the last message for that signal group before the transition occurs. |
| RSP-PR-018-v1.0 |
| The J2735 SSM shall contain one signal status entry for each active priority or preemption request |
| RSP-PR-019-v1.0 |
| The J2735 SSM shall only include a signal status entry (for a given priority or preemption request with an unchanging status) for the configured amount of time. |
| RSP-PR-020-v1.0 |
| All required J2735 SSM data elements shall be accurately populated. |
| RSP-PR-021-v1.0 |
| J3224 SDSM locations shall be accurate to within 0.5 meters. |
| RSP-PR-022-v1.0 |
| V2X message latency from generate to RSU broadcast shall be less than 300 milliseconds. |
| RSP-PR-023-v1.0 |
| The latency between change in signal head and the corresponding change in the SPaT message shall be less than 300 milliseconds. |
| RSP-PR-024-v1.0 |
| An RSP shall have an overall uptime greater than 99 percent. |
| RSP-PR-025-v1.0 |
| An RSP shall be time synchronized with other system devices. |
Roadside Processor Data Requirements
| RSP-DR-001-v1.0 |
| The J2735 RTCM shall include the msgCnt field to support sequencing (J2735 Section 7.113). |
| RSP-DR-002-v1.0 |
| The J2735 RTCM shall include the rev (message revision number) (J2735 Section 7.178). |
| RSP-DR-003-v1.0 |
| The J2735 RTCM may include the RTCM Header field if metadata tagging is used (J2735 Section 6.122). |
| RSP-DR-004-v1.0 |
| The J2735 SPaT shall contain the MsgCount data element (J2735 Section 7.113). |
| RSP-DR-005-v1.0 |
| The J2735 SPaT shall contain the time stamp data element (J2735 Section 7.109). |
| RSP-DR-006-v1.0 |
| The J2735 SPaT shall contain the Intersections data frame (J2735 Section 6.64). |
| RSP-DR-007-v1.0 |
| The J2735 SPaT shall contain the IntersectionState data frame (J2735 Section 6.45). |
| RSP-DR-008-v1.0 |
| The J2735 SPaT shall contain the IntersectionReferenceID data frame (J2735 Section 6.44). |
| RSP-DR-009-v1.0 |
| The J2735 SPaT shall contain the intersection status data element (J2735 Section 7.65). |
| RSP-DR-010-v1.0 |
| The J2735 SPaT shall contain the MOY (minute of the year) data element (J2735 Section 7.109). |
| RSP-DR-011-v1.0 |
| The J2735 SPaT shall contain the MovementState data frame (J2735 Section 6.61). |
| RSP-DR-012-v1.0 |
| The J2735 SPaT shall contain the MovementEvent data frame (J2735 Section 6.59). |
| RSP-DR-013-v1.0 |
| The J2735 SPaT shall contain the MovementPhaseState data element (J2735 Section 7.112). |
| RSP-DR-014-v1.0 |
| The J2735 SPaT shall contain the SignalGroupID data element (J2735 Section 7.187). |
| RSP-DR-015-v1.0 |
| The J2735 SPaT shall contain the TimeChangeDetails data frame (J2735 Section 6.148). |
| RSP-DR-016-v1.0 |
| The J2735 SPaT shall contain the minEndTime data element (J2735 Section 7.213). |
| RSP-DR-017-v1.0 |
| The J2735 SPaT shall contain the maxEndTime data element (J2735 Section 7.213). |
| RSP-DR-018-v1.0 |
| The J2735 MAP shall contain all mandatory data elements (J2735 Section 5.8). |
| RSP-DR-019-v1.0 |
| The J2735 MAP may contain Preempt Priority List (J2735 Section 6.99). |
| RSP-DR-020-v1.0 |
| The J2735 MAP shall contain MinuteOfTheYear (J2735 Section 7.109). |
| RSP-DR-021-v1.0 |
| The J2735 MAP shall contain the MsgCount data element (J2735 Section 7.113). |
| RSP-DR-022-v1.0 |
| The J2735 MAP shall contain the IntersectionGeometryList data frame (J2735 Section 6.43). |
| RSP-DR-023-v1.0 |
| The J2735 MAP shall contain the IntersectionGeometry data frame (J2735 Section 6.42). |
| RSP-DR-024-v1.0 |
| The J2735 MAP shall contain the IntersectionReferenceID data frame (J2735 Section 6.44). |
| RSP-DR-025-v1.0 |
| The J2735 MAP shall contain the IntersectionID data element (J2735 Section 7.64) |
| RSP-DR-026-v1.0 |
| The J2735 MAP shall contain the Position3D (refPoint) data frame (J2735 Section 6.96). |
| RSP-DR-027-v1.0 |
| The J2735 MAP shall contain the Latitude data element (J2735 Section 7.99). |
| RSP-DR-028-v1.0 |
| The J2735 MAP shall contain the Longitude data element (J2735 Section 7.103). |
| RSP-DR-029-v1.0 |
| The J2735 MAP shall contain the LaneWidth data element (J2735 Section 7.98). |
| RSP-DR-030-v1.0 |
| The J2735 MAP shall contain the LaneList data frame (J2735 Section 6.55). |
| RSP-DR-031-v1.0 |
| The J2735 MAP shall contain the GenericLane data frame (J2735 Section 6.34). |
| RSP-DR-032-v1.0 |
| The J2735 MAP shall contain the LaneID data element (J2735 Section 7.96). |
| RSP-DR-033-v1.0 |
| The J2735 MAP shall contain the AllowedManeuvers data element (J2735 Section 7.5). |
| RSP-DR-034-v1.0 |
| The J2735 MAP shall contain the NodeListXY data frame (J2735 Section 6.80). |
| RSP-DR-035-v1.0 |
| The J2735 MAP shall contain the NodeSetXY data frame (J2735 Section 6.85). |
| RSP-DR-036-v1.0 |
| The J2735 MAP shall contain the NodeXY data frame (J2735 Section 6.86). |
| RSP-DR-037-v1.0 |
| The J2735 MAP shall contain the NodeOffsetPointXY data element (J2735 Sections 6.69-6.74). |
| RSP-DR-038-v1.0 |
| The J2735 MAP shall contain the Connection data frame (J2735 Section 6.17). |
| RSP-DR-039-v1.0 |
| The J2735 MAP shall contain the ConnectingLane data frame (J2735 Section 6.16). |
| RSP-DR-040-v1.0 |
| The J2735 MAP shall contain the SignalGroupID data element (J2735 Section 7.187). |
| RSP-DR-041-v1.0 |
| The J3224 SDSM message shall include the msgCnt field (J3224). |
| RSP-DR-042-v1.0 |
| The J3224 SDSM message shall include the required fields in DetectedObjectCommonData (J3224). |
| RSP-DR-043-v1.0 |
| The J2735 SSM shall contain the MsgCount data element (J2735 Section 7.113). |
| RSP-DR-044-v1.0 |
| The J2735 SSM shall contain the timeStamp data element (J2735 Section 7.109). |
| RSP-DR-045-v1.0 |
| The J2735 SSM shall contain the SignalStatusList data frame (J2735 Section 6.134). |
| RSP-DR-046-v1.0 |
| The J2735 SSM shall contain the id (IntersectionReferenceID) data frame (J2735 Section 6.44). |
| RSP-DR-047-v1.0 |
| The J2735 SSM shall contain the intersection status data element (J2735 Section 7.65). |
| RSP-DR-048-v1.0 |
| The J2735 SSM shall contain the RequestID data element (J2735 Section 7.166). |
| RSP-DR-049-v1.0 |
| The J2735 SSM shall contain the vehicleID (TemporaryID) of the requesting vehicle (J2735 Section 7.167). |
| RSP-DR-050-v1.0 |
| The J2735 SSM shall contain the SignalStatusPackage data frame (J2735 Section 6.136). |
| RSP-DR-051-v1.0 |
| The J2735 SSM shall contain the PrioritizationResponseStatus data element indicating granted, denied, or pending status (J2735 Section 7.152). |
Roadside Processor Security Requirements
| RSP-SR-001-v1.0 |
| Access to an RSP shall be controlled using role-based access control, ensuring users can access only the functions necessary for their role. |
| RSP-SR-002-v1.0 |
| RSP user accounts shall be authenticated using a unique username and a strong password meeting NIST SP 800-63B guidelines (minimum length, complexity, and password history requirements). |
| RSP-SR-003-v1.0 |
| All RSPs shall be protected by network firewalls that restrict inbound and outbound traffic to only approved IP addresses and ports necessary for system operations. |
2.3.4 On-Board Units (OBUs)
2.3.4.1 V2X OBUs will generate and broadcast J2735 SRM to request signal priority\preemption through RSUs within the deployment area.
2.3.4.2 OBUs will generate and broadcast SAE J3161/1 BSM.
2.3.4.3 OBUs will sign all messages with IEEE 1609.2 certificates from the MCDOT SCMS.
2.3.4.4 OBU Antennas – Roof-mounted, or other as appropriate and approved by the department of transportation,
2.3.4.5 RSUs will broadcast SPaT and MAP messages, based on SAE J4501, SAE J2735 SSM, SAE J3224 SDSM, as well as IEEE 1609.3 Wireless Access in Vehicular Environment (WAVE) Service Advertisements (WSA) to advertise signal priority. RSUs will sign all messages with IEEE 1609.2 certificates from the MCDOT SCMS.
2.3.4.6 OBUs will be installed in local transit vehicles, first responder vehicles, agency owned fleet vehicles, as well as private commercial freight vehicles. OBUs will typically be installed under the driver’s seat, behind the driver’s seat, in a concealed compartment or cabinet, or any other location such that the OBU does not interfere with vehicle operation and is not subjected to a harsh environment. OBUs will be connected to a constant vehicle power source as well as a power source that turns on and off with the vehicle ignition. The associated OBU antenna will be mounted on the vehicle roof (the highest surface on the vehicle) to maximize communication range.
2.3.4.7 The OBU supplier shall configure each OBU for either EVP, TSP, VRU Safety, or FSP based on a list of vehicles provided by MCDOT with the Purchase Order.
2.3.4.8 OBUs shall be configured to sign and broadcast SAE J3161/1 BSMs and SAE J2735 SRMs as defined in the OBU requirements table.
2.3.4.9 OBUs shall be configured to verify SPaT, MAP, SDSM, SSM, and WSAs as defined in the OBU requirements table.
2.3.4.10 The OBU Supplier shall provide general installation instructions and support OBU installers, as needed during installation.
2.3.4.11 OBU Hardware shall be delivered including power cables, antennas, mounting brackets and hardware, and any other ancillary components required for complete installation and operation.
2.3.4.12 OBU Configuration support shall paid a lump sum covering all labor and associated costs required to support the demonstration of full OBU operations in the identified vehicles.
2.3.4.13 All OBU purchase must meet all the requirements in the OBU requirements table.
OBU REQUIREMENTS
| Requirement ID |
| Description |
Onboard Unit Functional Requirements
| OBU-FR-001-v1.0 |
| Emergency vehicle OBUs shall use WSAs containing PSID 0pE0-00-15 as an indication that the intersection supports signal priority\preemption. |
| OBU-FR-002-v1.0 |
| Emergency vehicle OBUs shall use the J2735 MAP message received from the intersection along with the vehicles' position information to determine the intersection identifier, road regulator identifier, and if the vehicle is located within a lane geometry. |
| OBU-FR-003-v1.0 |
| Emergency vehicle OBUs shall determine identifiers for the approach and lane the vehicle is in from the received SPaT and MAP messages |
| OBU-FR-004-v1.0 |
| Emergency vehicle OBUs shall generate SRMs using the vehicles current position, vehicle identifier, intersectionID, and lane and approach information, from received SPaT and MAP messages, along with any other user-configured parameters required for authorized requests. |
| OBU-FR-005-v1.0 |
| Transit vehicle OBUs shall use WSAs containing PSID 0pE0-00-15 as an indication that the intersection supports signal priority\preemption. |
| OBU-FR-006-v1.0 |
| Transit vehicle OBUs shall use the J2735 MAP message received from the intersection along with the vehicles' position information to determine the intersection identifier, road regulator identifier, and if the vehicle is located within a lane geometry. |
| OBU-FR-007-v1.0 |
| Transit vehicle OBUs shall determine identifiers for the approach and lane the vehicle is in from the received SPaT and MAP messages. |
| OBU-FR-008-v1.0 |
| Transit vehicle OBUs shall generate SRMs using the vehicles current position, vehicle identifier, intersectionID, and lane and approach information, from received SPaT and MAP messages, along with any other user-configured parameters required for authorized requests. |
| OBU-FR-009-v1.0 |
| VRU Safety OBUs shall use J3224 SDSM along with the vehicles position and motion information to determine if the vehicle is on a potential collision course with a VRU. |
| OBU-FR-010-v1.0 |
| OBUs shall generate J2735 BSMs using the vehicles position, speed, heading, etc. using data from GNSS and onboard sensors, along with any other user-configured parameters for BSM generation. |
| OBU-FR-011-v1.0 |
| All OBUs should use RTCM to correct positioning, if available. |
Onboard Unit Interface Requirements
| OBU-IR-001-v1.0 |
| Emergency vehicle OBUs shall receive all over-the-air messages from direct V2X RSUs. |
| OBU-IR-002-v1.0 |
| An emergency vehicle OBU shall receive the status of lights/siren systems from the emergency vehicle on board system. |
| OBU-IR-003-v1.0 |
| Emergency vehicle OBUs shall broadcast SRMs, if the intersection WSA contains PSID 0pE0-00-15, the vehicle is within lane geometry defined in the intersection MAP message, and the vehicle lights and sirens are active. |
| OBU-IR-004-v1.0 |
| Emergency vehicle OBUs shall not broadcast an SRM if the intersection WSA does not contain PSID 0pE0-00-15 or the intersection is not broadcasting a WSA. |
| OBU-IR-005-v1.0 |
| Emergency vehicle OBUs shall not broadcast SRMs if lights and sirens are not active. |
| OBU-IR-006-v1.0 |
| An emergency vehicle OBU should not broadcast an SRM (if not located within a lane geometry). |
| OBU-IR-007-v1.0 |
| Emergency vehicle OBUs may broadcast SRMs if the vehicle is not located within lane geometry defined in the intersection MAP Message. |
| OBU-IR-008-v1.0 |
| Transit vehicle OBUs shall receive all over-the-air messages from direct V2X RSUs. |
| OBU-IR-009-v1.0 |
| Transit vehicle OBUs should receive "on-time status" data from the vehicles on-board Automatic Vehicle Location System (AVL) system. |
| OBU-IR-010-v1.0 |
| Transit vehicle OBUs shall broadcast SRMs if the intersection WSA contains PSID 0pE0-00-15, the vehicle is within lane geometry defined in the intersection MAP message, and the vehicle is behind schedule by more than a user-configurable amount of time. |
| OBU-IR-011-v1.0 |
| Transit vehicle OBUs shall not broadcast an SRM if the intersection WSA does not contain PSID 0pE0-00-15 or the intersection is not broadcasting a WSA. |
| OBU-IR-012-v1.0 |
| Transit vehicle OBUs shall not broadcast SRMs if the vehicle is not behind schedule more than a user-configurable amount of time or data is available to make a determination. |
| OBU-IR-013-v1.0 |
| Transit vehicle OBUs shall not broadcast SRMs if the vehicle is not located within a lane defined in the intersection MAP message. |
| OBU-IR-014-v1.0 |
| VRU Safety OBUs shall receive all over-the-air messages from direct V2X RSUs. |
| OBU-IR-015-v1.0 |
| VRU Safety OBUs shall deliver visual and/or audible warnings to the vehicle operator via an OBU Human-Machine Interface (HMI) if the vehicle is on a potential collision course with a vulnerable road user. |
| OBU-IR-016-v1.0 |
| VRU Safety OBUs shall not deliver visual and/or audible warnings to the vehicle operator if the vehicle is not on a potential collision course with a vulnerable road user. |
| OBU-IR-017-v1.0 |
| OBUs shall broadcast SAE J3161/1 BSMs. |
| OBU-IR-018-v1.0 |
| All OBUs shall receive location and time data from GNSS. |
Onboard Unit Performance Requirements
| OBU-PR-001-v1.0 |
| An OBU shall broadcast between 9-11 J2735 SRM messages in a 10-second interval when conditions to broadcast SRM have been met. |
| OBU-PR-002-v1.0 |
| All required SRM data elements shall be accurately populated. |
| OBU-PR-003-v1.0 |
| OBUs shall broadcast 90-110 SAE J3161/1 BSM messages in a 10-second interval. |
| OBU-PR-004-v1.0 |
| All required SAE J3161/1 BSM data elements shall be accurately populated. |
| OBU-PR-006-v1.0 |
| An OBU shall have associated documentation that indicate it has been tested at events such as OmniAir Plugfests, 5GAA Plugfests, etc. |
Onboard Unit Data Requirements
| OBU-DR-001-v1.0 |
| The J2735 SRM shall contain the MsgCount data element (J2735 Section 7.113). |
| OBU-DR-002-v1.0 |
| The J2735 SRM shall contain the timeStamp data element (J2735 Section 7.192). |
| OBU-DR-003-v1.0 |
| The J2735 SRM shall contain the requestor data frame (RequestorDescription) (J2735 Section 6.98). |
| OBU-DR-004-v1.0 |
| The J2735 SRM shall contain the VehicleID field within requestor (J2735 Section 6.147). |
| OBU-DR-005-v1.0 |
| The J2735 SRM shall contain the TemporaryID field under VehicleID (J2735 Section 7.187). |
| OBU-DR-006-v1.0 |
| The J2735 SRM shall contain the RequestID data element (J2735 Section 7.153). |
| OBU-DR-007-v1.0 |
| The J2735 SRM shall contain the SignalRequestList data frame (J2735 Section 6.118). |
| OBU-DR-008-v1.0 |
| The J2735 SRM shall contain the SignalRequest data frame within the list (J2735 Section 6.120). |
| OBU-DR-009-v1.0 |
| The J2735 SRM shall contain the IntersectionReferenceID data frame (J2735 Section 6.36). |
| OBU-DR-010-v1.0 |
| The J2735 SRM shall contain the inBoundLane data frame (IntersectionAccessPoint) (J2735 Section 6.33). |
| OBU-DR-011-v1.0 |
| The J2735 SRM shall contain the PriorityRequestType field to distinguish request intent (J2735 Section 7.142). |
| OBU-DR-012-v1.0 |
| The J2735 SRM shall contain expected arrival time and duration if used (J2735 Section 6.120). |
| OBU-DR-013-v1.0 |
| The J2735 SRM shall contain current speed, heading, and position of the vehicle (J2735 Section 6.98). |
| OBU-DR-014-v1.0 |
| BSMs shall include all data elements contained in the BSMcoreData data frame (J2735 Section 6.10). |
| OBU-DR-015-v1.0 |
| BSMs may include any of the Part II extensions (VehicleSafetyExtensions J2735 Section 6.168, Special Vehicle Extensions J2735 Section 6.142, SupplementalVehicleExtensions J2735 Section 6.147), only if there are data elements within those frames that can be accurately populated. |
Onboard Unit Security Requirements
| OBU-SR-001-v1.0 |
| All OBUs shall comply with IEEE 1609.2. |
| OBU-SR-001a-v1.0 |
| OBUs shall comply with IEEE 1609.2.1. |
This is the start of the file's text. The full file is on GovTribe.