111Spec__2025___002_.pdf

Invitation No. 111-25

CV2X Connected Vehicle Equipment

REQUIREMENTS/SPECIFICATIONS

Section 1: Intent

The intent of this Invitation to Bid (ITB) is to establish for various parts, components, services and applications for Connected Vehicle

Environment/Ecosystem

Section 2: Contract Duration

The Contract shall be in effect for twelve (12) months from the date of award.

Section 3: Free on Board (F.O.B.) Place of Destination

Please be advised, the vendor must honor any bid price submitted in this Invitation to Bid for all of ODOT’s twelve (12) Districts and eighty-eight (88) counties in the State of Ohio. All deliveries shall be Free on Board (F.O.B.)

to any of ODOT’s twelve (12) Districts and eighty-eight (88) county destination locations in the State of Ohio, as per the enclosed map.

Purchase orders when issued, will detail specific destination points. The Department will not accept any additional charges for these deliveries.

District 1 – Lima District 7- Sidney

District 2 - Bowling Green District 8 - Lebanon

District 3 – Ashland District 9 - Chillicothe

District 4 – Akron District 10 - Marietta

District 5 - Jacksontown District 11 - New Philadelphia

District 6 - Delaware District 12 - Garfield Heights

Central Office - Columbus

Section 4: Delivery

Delivery shall be made within 60 calendar days upon written or verbal notification of a valid State of Ohio purchase order.

4.1 : Delivery Hours All deliveries shall be made between the hours of 8:00 a.m. and 3:00 p.m., Monday through Friday, excluding State holidays, unless special permission is granted by the Department to temporarily waive or adjust this requirement.

Section 5: F.O.B. Delivery Minimum Order: $250.00

a. Orders meeting or exceeding the minimum shall be shipped F.O.B.

Place of Destination at the unit price quoted.

b. Orders amounting to less than the minimum shall be shipped at the unit price quoted, prepaid with freight/shipping charges added to the invoice. Copies of freight/shipping charges are to be included with the invoice.

c. No minimum shall apply to an order picked up by the Department of Transportation at the vendor location, at the unit price quoted.

Section 6: Award

This is a Multiple Award Invitation to Bid. All bidders meeting specifications will be considered awarded.

Section 7: Descriptive Literature

All vendors will be required to submit descriptive literature either in their pricing cd or in the bid package.

Vendors must submit their Bid Responses electronically in OhioBuys before the published deadline date & time, Columbus, Ohio local time on the Proposal due date. Vendors will not be able to submit Bid Responses, or unsolicited Proposal amendments after the deadline.

Vendors must allow adequate time for uploading a Bid Response prior to the due date and time. ODOT recommends that vendors submit Bid Responses as early as possible. If a second round is issued for any reason, vendors must resubmit their bid if they had already submitted in a previous round, as the previously submitted Bid Responses do NOT carry over to the new round.

The Signature process takes place after the award now. The email will come from documents@esign.ohio.gov and will go to the signatory that was identified in the bid submission. The subject line will be the bid # Signature Request, (example: 101G-25 Signature Request).

No contract can be issued to your company until we receive your signature to complete the process. And you must have an OAKS Payor ID before a contract can be issued. To obtain that, you will need to go into https://ohiopays.ohio.gov

Section 8: Product Specifications

Vendors are required to provide the requested OEM or approved non- OEM repair parts as listed by part number or an approved equal that will be fully compatible to existing material. It will be the vendor’s responsibility to verify that Non-OEM parts meet or exceed the requirements of OEM parts. If no part number is listed, it can be assumed that various models of devices / equipment may be approved to be acceptable.

The purchasing contract is intended to provide various parts, components, mailto:documents@esign.ohio.gov https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fohiopays.ohio.gov%2F&data=05%7C02%7CTodd.VanKirk%40dot.ohio.gov%7C1ac0731aa3fa4f066d5408dc7b4d0c36%7C50f8fcc494d84f0784eb36ed57c7c8a2%7C0%7C0%7C638520818049379076%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=v8I%2Ba6H4M2smMVdNcvpoDrB2Dqsn4%2FJvMONLWyfwoxE%3D&reserved=0 services and applications for Dedicated Short Range Communications (DSRC) and Cellular-Vehicle-to-Everything (C-V2X) technologies and related services.

Cellular-Vehicle-to-Everything (C-V2X)

C-V2X devices use single carrier frequency division multiplexing (SC-FDMA) via cellular (3GPP release 14) signal to transmit safety messages. C-V2X devices will be allowed to transmit on the upper 30 MHZ portion of the 5.9 GHZ band per FCC Report and Order although Channel 183 (5905-5925 MHz) is typically used.

5G Mobile Edge Computing (5G MEC) Current Edge Computing offers cloud computing capabilities at the “edge” of the network. MEC gives an avenue for utilizing cellular networks to provide non time-critical applications out to the general public using cellular applications on mobile devices and even in the infotainment systems in vehicles.

SPaT Messages Output from Traffic Signal Controller.

The traffic signal controller located roadside at the signalized intersection will generate the current signal phase and timing parameters used to control the signal heads and pedestrian crossing signs. SPaT messages are traditionally generated by one of three methods. Those methods are the use of NTCIP 1202v3, J2735, or Traffic Signal Controller Broadcast message (TSCBM). Various traffic signal controller manufacturers use these methods to deliver signal phase and timing information to the RSU for transformation and/or broadcast.

Applications

The applications listed in Table 1 are shown to provide context to the various application categories and functions that are or are expected to be on the market in the future, as connected vehicle technology is adopted broadly.

Table 1: Typical CV Applications

For the purposes of the requirements of this contract, all responding vendors for V2X Roadside Units and On-Board Units shall work towards a collaborative effort with DriveOhio and its identified CV stakeholders to develop common functional operation standards for the below applications and implement the application functionality into their hardware. In coordination with OmniAir, DriveOhio will provide these common operational standards for incorporation into the OmniAir Application Test Documents for consideration of inclusion into the OmniAir Application Certification Program.

The following applications are organized into Base-Level Applications that are required to be supported out-of-the-box and Supplemental Applications that will likely be implemented in the future.

Base-Level Applications

Supplemental Applications

Vehicle-to-Infrastructure (V2I)

• Red-Light Violation Warning

• Reduced Speed Zone

• Lane Closure Warning

• Traffic Signal Preemption / Priority

• Curve Speed Warning

Vehicle-to-Vehicle (V2V)

• Intersection Movement Assist (IMA)

• Blind Spot Warning (BSW)

• Emergency Electronic Brake Light (EEBL)

• Forward Collision Warning (FCW)

Vehicle-to-Infrastructure (V2I)

• Wrong Way Driver Alert

• Pedestrian in Crosswalk Warning

• Pedestrian Conflict Warning

• Spot Weather Warning

Vehicle-to-Vehicle (V2V)

• Left Turn Assist (LTA)

• Do Not Pass Warning (DNPW)

• Eco-Approach & Departure

Common acronyms:

• CV – Connected Vehicle, vehicles that have on-board technology that provides a wireless connection between other vehicles and the infrastructure in real time.

• ATS –Automated Transfer Switch

• CVRIA – Connected Vehicle Reference Implementation Architecture, defines functionality and information exchanges needed to provide connected vehicle applications.

• HMI – Human Machine Interface, software application that presents information to an operator or user about the state of a process, and to accept and implement the operator control instruction Information is typically display on a graphics display within the vehicle for CV applications.

• MAP – Map data, the geocoded data, sent by the RSE, used to describe the intersection geometry to approaching vehicles and other road users. The map data includes lane configuration and usage, the edge of the roadway, the location of stop bars, and other information necessary for connected vehicles to understand the layout of the intersection they are approaching.

• OBE – On-Board Equipment, the equipment package, including the DSRC radio with its antenna, and other peripheral equipment, located in the vehicle, which enable communications with other connected vehicles and RSEs.

• OBU – On-Board Unit, the DSRC radio located in the vehicle that is responsible for sending and receiving connected vehicle information

• PoE – Power over Ethernet, an IEEE network standard for powering devices over the same cable used for the network connection. RSUs are required to use PoE cabling, for connection to the RSE, which helps to simplify RSU installation.

RSE - Roadside Equipment, traffic management equipment installed along the roadside to convey traffic or traveler information to passing vehicles or to connect roadside equipment to a traffic management center or other back office services or applications.

• RSU – Roadside Unit, the DSRC radio located on the side of the roadway or at an intersection that enables wireless communications between the Roadside Equipment (RSE) and equipped vehicles or non-vehicle road users

SDK - Software Development Kit

• TMC – Traffic Management Center, a commonly used term in ITS to represent a facility, either physical or virtual, that houses network switches/routers, servers, software, storage, operators and workstations, etc.

WAVE - IEEE 1609.3 Wireless Access in Vehicular Environment

VAD - Vehicle Awareness Device

• BSM – Basic Safety Message, the message defined by the SAE J2735 standard for vehicles to communicate their identification, location, heading, speed and other information to other vehicles and to nearby RSEs.

RWA - Road Weather Advisories, this application provides the capability of collecting road weather data from Commission Fleets and using that data to develop short term warnings or advisories that can be provided to individual vehicles.

• CSW - Curve Speed Warnings, this application provides information about curve “advisory speed limit” as drivers approach a deceleration ramp.

• RTCM – Radio Technical Commission for Maritime Services, the Federal Communications Commission use RTCM standards to specify radar systems, Emergency Position Indicating Radio Beacons, Differential GPS systems and the basic version of Digital Selective Calling radios.

• SPaT – Signal Phase and Timing, the message set defined by the SAE J2735 standard for traffic signal controllers (and included in NTCIP 1202 version 3) to communicate the identification, location, status of intersection indications, timing before the next change and other information to vehicles or other road users approaching the intersection.

• TMC – Traffic Management Center, a commonly used term in ITS to represent a facility, either physical or virtual, that houses network switches/routers, servers, software, storage, operators and workstations, etc.

• V2I – Vehicle to Infrastructure, refers to connected vehicle communications between vehicles and Roadside Equipment (RSE).

V2V- Vehicle to Vehicle, refers to connected vehicle communications between two or more vehicles.

https://en.wikipedia.org/wiki/Federal_Communications_Commission https://en.wikipedia.org/wiki/Federal_Communications_Commission https://en.wikipedia.org/wiki/Federal_Communications_Commission https://en.wikipedia.org/wiki/Emergency_Position_Indicating_Radio_Beacon https://en.wikipedia.org/wiki/Emergency_Position_Indicating_Radio_Beacon https://en.wikipedia.org/wiki/Emergency_Position_Indicating_Radio_Beacon https://en.wikipedia.org/wiki/Differential_GPS https://en.wikipedia.org/wiki/Digital_Selective_Calling

• V2I Hub – Vehicle to Infrastructure Hub, is a software program that supports the collection, integration and dissemination of data between the infrastructure and vehicles for a wide variety of applications such as signal phase and timing, mapping (intersections and road segments), other roadside equipment (e.g., dynamic message signs, detectors), positioning corrections, communications, and road condition and weather data. This software may run on the controller (as an example through use of the Econolite Connected Vehicle Co-Processor (CVCP) or on an external device.

8.1

GROUP 1

Roadside Unit (RSU)

The RSU shall have the following requirements:

1. RSU’s shall be fully compliant with IEEE 1609.2-1609.4, IEEE 802.11p.

2. RSU’s shall be fully compliant with SAE J3161/0 and 3GPP 36.521-1

3. Vendors shall also be OmniAir certified for C-V2X Release 1 or show that they are actively working toward certification to become OmniAir certified for C-V2X Release 1 (LTE-V2X). Vendors must complete certification prior to any procurement activities being initiated. Proof of certification or working toward certification letter shall be submitted with bid documents.

4. RSU’s shall be compliant with all mandatory requirements of CTI 4001.

5. Vendors shall submit documentation showing that they are actively developing and testing at events such as OmniAir Plugfests, 5GAA Plugtests, etc.

6. RSU supports latest published version of SAE J2735 2024 compliant message sets, including but not limited to: basic safety message (BSM), Personal Safety Message

(PSM), Signal Phase and Timing (SPaT), MAP, Signal Request Message (SRM), Signal Status Message (SSM), Radio Technical Commission for Maritime Services

(RTCM) and Traveler Information Message (TIM). This includes ability to support the full range of Provider Service Identifiers (PSID) as specified in the DriveOhio

Security Documentation located at 23-Standards+for+Comms.pdf (ohio.gov).

7. The RSU’s shall be compatible with the following controllers: Econolite Cobalt, Econolite ATC 2070C, Intelight 2070LDX, Intelight NEMA XN-1, Intelight NEMA XN-

2, and YUNEX (Siemens) M60 / YUNEX (Siemens) Blade.

8. The vendor shall provide a NEMA TS2 PoE power supply for powering the RSU.

https://drive.ohio.gov/wps/wcm/connect/gov/d778f137-d314-4d0f-9152-80ac2bd6c747/23-Standards+for+Comms.pdf?MOD=AJPERES&CONVERT_TO=url&CACHEID=ROOTWORKSPACE.Z18_K9I401S01H7F40QBNJU3SO1F56-d778f137-d314-4d0f-9152-80ac2bd6c747-nFyTrAd

9. RSU shall be compliant with applicable sections of Title 47 of the Code of Federal

Regulations Part 15, Subpart C.

10. RSU shall operate on the upper 30 MHz of the 5.9 GHz radio frequency band.

11. RSU shall be capable of supporting both 10 and 20 megahertz (MHz) channel widths.

12. RSU shall have at least one Ethernet RJ-45 port for network connection and supports

IPv4 and IPv6 address configuration dual stacked. Ensure all management of the RSU may be performed through via the RJ-45 port.

13. RSU shall support NTCIP 1218v0138 for diagnostic and health monitoring functions.

14. The RSU’s shall support a minimum 64 Megabyte (MB) Static Dynamic Radom Access Memory (SDRAM).

15. The RSU’s shall support a minimum 500MHz Central Processing Unit (CPU) speed.

16. Performance Requirements for SPaT, MAP and RTCM to support applications include the following: SPaT broadcast at 10 Hz; MAP broadcast at 1 Hz. RTCM version 3.3.

17. The RSU shall be in the process of supporting the full implementation of the NTCIP

1218v0138 MIB. The RSU shall be compliant with IEEE 1609.2.1 for security certificate enrollment.

18. The RSU’s shall be able to update to newer technologies with little overhead (5G-NR chip incorporation into device, etc.)

19. The RSU’s shall conform to all mandatory requirements found in DriveOhio’s ‘US-33

Smart Mobility Corridor Device Transition Plan’. US-33+Transition+Plan+V1.0+-

+Final.pdf (ohio.gov)

Item Details:

Unit only shall include just the RSU unit.

A Complete Kit shall include PoE Power Supply, Cabinet Surge Protection, Omni Antenna, Mounting Hardware, Wiring (100 ft) and all the necessary cables, connectors, and any other hardware necessary to provide a fully functional unit to be deployed in the field.

Wiring Kit (multiples of 50 ft lengths) shall be paid for in feet. Orders will be placed in multiples of 50 ft. (I.e., 50,100,150,200 ft…). Kit shall include all necessary end connectors.

Mounting Hardware shall be provided for installation on either an ODOT Standard Drawing TC-81.10 Strain Pole, TC-81.21 Mast Arm, HL-10.11 or equivalent round pole.

Equipment (Other) covers any items that are necessary and not listed in order to have a fully functional field deployed unit.

Manufacturer Warranty shall include repair or replacement by the vendor without costs to the purchasing agency for any defect in design, materials, or workmanship that may occur during proper and normal use through final system acceptance during a two-year period following delivery of the unit. This warranty shall include the RSU, provided antennas, and the PoE injector.

https://drive.ohio.gov/wps/wcm/connect/gov/26bcb793-12cb-4eae-a20b-aee4c713a5c9/US-33+Transition+Plan+V1.0+-+Final.pdf?MOD=AJPERES&CONVERT_TO=url&CACHEID=ROOTWORKSPACE.Z18_M1HGGIK0N0JO00QO9DDDDM3000-26bcb793-12cb-4eae-a20b-aee4c713a5c9-ojjCgH4 https://drive.ohio.gov/wps/wcm/connect/gov/26bcb793-12cb-4eae-a20b-aee4c713a5c9/US-33+Transition+Plan+V1.0+-+Final.pdf?MOD=AJPERES&CONVERT_TO=url&CACHEID=ROOTWORKSPACE.Z18_M1HGGIK0N0JO00QO9DDDDM3000-26bcb793-12cb-4eae-a20b-aee4c713a5c9-ojjCgH4

GROUP 2

8.2 On-Board Unit (OBU)

The OBU shall have the following requirements:

1. The OBU shall adhere to the following Standards: SAE J3161/1, 3GPP 36.521-1, IEEE 802.11p, and IEEE 1609.1-1609.4 as applies for the technology bid (DSRC, C-V2X, Dual-Mode).

2. The OBU shall have received certification from OmniAir or show that they are actively working toward OmniAir certification.

3. The vendor shall provide documentation showing continued efforts to be certified in the Base-Level Applications documented on page 4.

4. The OBU shall support integration of vehicle CAN bus data for those elements required to comply with any OmniAir application certification in support of the base or supplemental applications.

5. The OBU shall support updates to the Local Certificate Chain File (LCCF) to facilitate the distribution of certificates among SCMS components, as well as updates to the SCMS roots.

6. OBU supports latest published version of SAE J2735 and J3161/1 compliant message set, including but not limited to: basic safety message (BSM), Signal Phase and Timing (SPaT), MAP, RTCM, Signal Request Message (SRM), Signal Status

Message (SSM), and Traveler Information Message (TIM). This includes ability to support the full range of PSIDs as specified in the DriveOhio Security Documentation located at 23-Standards+for+Comms.pdf (ohio.gov).

7. The OBU shall include a GPS antenna (integrated or externally mounted and environmentally hardened). If OBU design includes an integrated antenna, the OBU shall support the addition of an external antenna for improved performance.

8. The OBU shall operate on 12 Volts Direct Current (VDC).

9. OBU shall implement a method for secure physical attachment to the host vehicle.

10. OBU system shall store a log of all alerts provided to the vehicle operator for 12 hours of operating time.

11. The OBU shall log the date, time, and location of each alert provided to the vehicle operator.

12. The OBU shall have the ability to provide audible and visual alerts to the Vehicle Driver.

13. The OBU shall support audible and visual alerts to a Heads-Up Display (HUD) via HDMI and a tablet via wireless communication.

14. OBU shall log the unique vehicle ID for each alert provided to the vehicle operator.

15. The OBU shall keep BSM logs with all mandatory requirements found in SAE

J2945/1 and J3161/1.

16. OBU shall store all messages received for 12 hours of operating time.

17. OBU shall have a radio range of a minimum of 300 meters line of sight from vehicle to roadside equipment.

18. OBU should be approximately 2 inches tall (with respect to the mounting surface) by 8 inches x 4 inches.

19. OBU shall be compliant with the electromagnetic compatibility requirements of SAE

J1113, including procedures -2, -4, -11, -13, -21, -22, -26, -27, 41, 42j.

20. OBU shall operate at automotive temperatures consistent with SAE J1211 Interior-

Instrument Panel-Other (-40 C to 85 C).

21. OBU shall be resistant to permanent damage from shock and vibrations normally https://drive.ohio.gov/wps/wcm/connect/gov/d778f137-d314-4d0f-9152-80ac2bd6c747/23-Standards+for+Comms.pdf?MOD=AJPERES&CONVERT_TO=url&CACHEID=ROOTWORKSPACE.Z18_K9I401S01H7F40QBNJU3SO1F56-d778f137-d314-4d0f-9152-80ac2bd6c747-nFyTrAd associated with automotive electrical components and consistent with SAE J1211.

22. OBU should be protected from contaminant intrusion consistent with international standard EN 60529 IP 64 or greater.

23. OBU shall implement an interface to extract data files on-demand from the unit locally via wire and wirelessly via a secure wifi connection. The data shall be capable of being automatically transmitted via wifi, once in range of the wifi access point. The HMI shall indicate data transfer occurring and shall indicate when data transfer is complete.

24. OBU shall prevent overheating to occur such that damage to host vehicle is caused.

25. OBU vendor shall submit documentation to clearly show how they plan to implement the incorporation of the simultaneous use of identity (lights/sirens on) and pseudonym (lights/sirens off) certificates for public fleet vehicles. The use of the Emergency Vehicle Alert (EVA) message as defined in SAE J2735 may satisfy the requirement of having separate identity certificates.

26. The OBU’s shall incorporate a Hardware Security Module and shall allow enrolled security compliant with IEEE 1609.2.1.

27. The OBU shall conform to all mandatory requirements found in DriveOhio’s ‘Smart Mobility Corridor Device Transition Plan’.

28. OBU shall prevent electrical discharge from occurring to eliminate risk of damaging the host vehicle.

29. The C-V2X OBU shall support SCMS Certificate top-off OTA connection to encountered supporting RSUs.

Item Details:

Unit only shall include just the OBU unit.

OEM V2X module is a high-powered V2X module that is integrated into a vehicle’s on-board computer and allows V2V and V2I communication.

A Complete Kit shall include the OBU, the Power Supply, Surge Protection, Omni Antenna, WIFI module, mounting Hardware, Wiring and all the necessary cables, connectors, and any other hardware necessary to provide a fully functional unit to be deployed in a vehicle.

Human Machine Interface (OBU Display) shall display real-time traffic data to the driver that is received by an OBU. The display can be a tablet running an app connected to the OBU that is updated to show information from an OBU. Maximum display size shall be 8 inches and it should include universal mounting hardware to mount on a vehicle’s dashboard.

Rear View Mirror Display should provide drivers with a more visually appealing, easy to view OBU display with an OEM look. Should fit all standard windshield wedge-mount designs with an edge-to-edge glass design maximizing rear vision.

Heads-Up Display should provide drivers with a display that appears to be integrated into the windshield. This is done by projecting the display image onto the windshield just below the driver’s typical field of view of the roadway.

OBU wiring kit, mounting hardware, antenna and connectors shall be provided for the necessary vehicle identified in the purchase order. Appendix A will list all the potential ODOT vehicles, but not limited to, for installation. Hardware shall be compatible with Honda, Chevrolet, GMC, Ford, Dodge and International.

ATS interface box is to decode the controller head and send information to the OBU.

The ATS box should have an Ethernet port.

Equipment (Other) covers any items that are necessary and not listed in order to have a fully functional field deployed unit.

Manufacturer Warranty shall include repair or replacement by the vendor without costs to the purchasing agency for any defect in design, materials, or workmanship that may occur during proper and normal use through final system acceptance during a two (2) year period following delivery of the unit. This warranty shall include the OBU and provided antennas and HMI (HUD and/or tablet). Items that require repair shall be returned to DriveOhio within 14 calendar days. if repairs exceed such timeframe, a substitute item shall be provided.

8.2.1 OBU Lite / Ultralite (Aftermarket V2X Device)

This item shall consist of a small form factor On-Board Unit that is meant for use to support Vulnerable Road User applications. The device shall be capable of being powered by a external portable power source and shall include a compatible power source as part of the OBU kit. The OBU lite / ultralite kit shall include all necessary mounting and wiring to be installed and function as intended.

The unit shall be compliant with all respective requirements per SAE J3161/1. Vendors shall have 6 months to conform to SAE J5001 after publication and once a scope of work has been received from procuring agency. Vendor shall coordinate any work or orders related to this item with DriveOhio.

GROUP 3

Lidar – Items 3-31 through 3-39

All lidar units shall meet the following requirements:

Vertical Resolution

Lidar units shall be provided as selected from the pricing sheet and shall be organized based on the number of channels (32, 64, or 128) in vertical resolution.

Enclosure

The unit’s enclosure shall be IP67 rated as a minimum.

Range

The minimum range for operation shall be 50 meters.

Vertical Field of View

The unit shall have a minimum vertical field of view of 40 degrees.

Precision

The unit shall have a precision between 1.5 – 5 cm.

Horizontal Field of View

The unit shall have a horizontal field of view of 360 degrees.

Rotation Rate

If LiDAR is not solid state, the unit shall operate with a rotation rate of between 5 – 20 Hz.

Network Connectivity

The unit shall be both configurable and its firmware shall be updateable via an IP web interface.

Calibration

The unit shall auto-calibrate and shall not need any manual calibration during its lifetime.

Mounting Hardware

The unit shall be provided with the necessary mounting hardware for banding / bolting to a wood or galvanized steel pole, respectively.

Data Format

The vendor shall provide the format of the LiDAR unit data stream with the proposal / bid.

Configuration

If applicable, the lidar shall be provided in a selected configuration, to be provided by ODOT at the time of procurement, that is one of the following:

Uniform Beam – Equal angle above and below horizon.

Gradient Beam – High density of beam along central horizon with less density of beam above and below horizon.

Below Horizon – All beam is directed below horizon parallel.

Applications

The Lidar unit shall support the following transportation related applications:

• Pedestrian Safety

• Intersection Data Collection

• Traffic counts, classification, speed

• V2X

GROUP 4

8.3 Installation, Configuration, Application, Integration, Testing, Maintenance & Training

Item 4-1 Connected Vehicle RSU Field Survey

This section covers system integration, installation, configuration, application integration, testing maintenance and training.

Perform a site analysis to address a variety of issues, such as physical requirements, environmental conditions, application needs, component location, and range, and coverage.

Perform a field survey of proposed Connected Vehicle RSU location. Based on a 20’- 25’ mounting height, provide the Department with a drawing, Keyhole Markup Language (KML) or Keyhole Markup Language Zipped (KMZ) showing:

Maximum coverage area: 800 meter radius Null area: 300 meter radius Limited coverage area: 33 foot radius Shaded line-of-sight coverage area

Item 4-2 Connected Vehicle FCC Licensing & Site Registration

All license applicants seeking to operate Connected Vehicle RSUs, whether road operators, road users, or private service providers, must be in the process of meeting certain requirements to obtain and maintain a license from the FCC. Connected Vehicle licenses authorize the applicant to operate in a specified, non-exclusive geographical area and from identified RSU sites within that geographic area. A license applicant must also ensure that equipment at sites is certified to conform to the FCC rules.

All licensing and registration shall follow the documented guidance listed below.

https://docs.fcc.gov/public/attachments/DA-21-962A1.pdf

Provider shall provide necessary Licensing and registration under ODOT’s FCC Registration Number (FRN) 0002994622.

Item 4-3 Map File Generation

Item covers the generation of intersection MAP data following the CV PFS Map Guidance Document located at MAP Guidance Document - Revision 2_06232023.pdf (virginia.edu)In order for vehicles approaching an intersection to interpret the SPaT messages being broadcast, the vehicle systems must have a reference to determine the approach (or signal phase) they are following, and therefore understand the current display on the signal head. This is accomplished by the SPaT broadcast including a MAP message broadcast. The MAP message is not created in real-time, but rather is a static description of the geometries of the intersection and vectors describing approaches. The vehicle systems will compare GPS location readings on the vehicle against the MAP message and determine the vehicle’s approach.

https://engineering.virginia.edu/sites/default/files/common/Centers/CTS/CVPFS/projects/MAP/MAP%20Guidance%20Document%20-%20Revision%202_06232023.pdf https://engineering.virginia.edu/sites/default/files/common/Centers/CTS/CVPFS/projects/MAP/MAP%20Guidance%20Document%20-%20Revision%202_06232023.pdf

Item 4-4 GPS Correction/Real-Time

Item covers the generation of GPS Correction data. In order for the vehicle to accurately identify the approach/phase using the MAP message, it is critical that the location of the vehicle (determined by the on-board GPS) is accurate. This can be accomplished by a broadcast of GPS correction information as standardized by the Radio Technical Commission for Maritime Services (RTCM) v3.X as a method for minimizing the effects of GPS error caused by atmospheric conditions or reduced satellite access. The general concept of RTCM is that a base station with a known location (the location may be known by either by surveying in the station location or operating a GPS receiver for a long continuous period of time) continuously receives satellite signals and determines a current latitude/longitude position given the current atmospheric conditions. The base station then compares the position determined with the current atmospheric conditions to the known location and computes a correction factor that corrects the current calculated position to the known position. This correction factor is the RTCM message that can be sent out to vehicles. Depending upon the vehicle and the GPS system On-Board, the vehicle may or may not be able to apply the correction factor. Creation of the RTCM message may either be done by operating a base station at the intersection, or by retrieving the RTCM from an on-line source, or by a central calculation at the TMC.

Item 4-5 Connected Vehicle RSU Installation Support and Configuration

This item includes on-site support for the installation, configuration, and the complete intersection setup (if required) of an RSU to make it fully functional & operational per its intended application. It does not include any mounting, pulling wire or need for a bucket truck, such equipment and installation will be provided by others. Payment shall be per each location, complete in place, field tested and accepted.

Item 4-6 Connected Vehicle RSU Installation

This item includes all RSU mounting, pulling wire and bucket truck needs. Payment shall be per each location, complete in place, field tested and accepted.

Item 4-7 Connected Vehicle Application

This item includes the turnkey implementation of a connected vehicle out-of-the-box application at a single RSU location. Any OBU provided is expected to work with all Base-Level and Supplemental RSU applications and shall display information regarding the Basic Safety Message (BSM) and Traveler Information Message (TIM) / Roadside Safety Message (RSM). The application shall leverage real-time data to provide the vehicle driver with traffic information. The application shall utilize multiple avenues of communication that may include: RSU to OBU (I2V) connection, OBU to RSU connection (V2I), Vehicle-to-Network (V2N), or Network-to-vehicle (N2V). The application shall include all the necessary software, development kits, evaluation kits, application kits, platforms, hubs etc. for a complete setup on and between the OBU & RSU’s.

Potential Items:

V2X Development Kit V2X Evaluation Kit RSU Application Development Kit OBU Application Development Kit Development Board On Board Development Platform V2I Hub Windows V2I Hub Linux Common Computer Platform D2X Hub Version 1.0 2/2017 or most current.

https://itsforge.net/index.php/component/ars/repository/traveler-information/D2X%20Hub%20v1

Item 4-8 Connected Vehicle Application Development

This item includes development, testing, and implementation of a connected vehicle application that does not currently exist. This may include modifying an existing out-of-the-box application. ODOT - DRIVEOHIO will specify and clearly state the expectations of the application. The application must be developed to align with other national efforts. ODOT - DRIVEOHIO will work with the provider to figure out the viability of the application as well as create a work schedule for the development process. Payment shall be for each application developed. This application shall include any necessary work to complete the scope of work in the area of V2X PC5, V2X Network Cellular, and / or V2X NTN communications.

Item 4-9 Connected / Automated Vehicle Application Engineering Services

This item includes all elements needed to satisfy the scope of work for services related to development of connected / automated vehicle applications.

Item 4-10 Onsite Support, Vendor

This item covers on-site support for preventative maintenance, diagnosis of problems, repairs, and inspections of V2X RSE sites, including but not limited to the V2X Radios, antennas and associated equipment and V2X OBE vehicles, including but not limited to the V2X radio, antennas and sensors. Vendor must be trained and certified by the manufacturer of the equipment. Item shall be paid by the hour. All travel expenses (i.e., mileage) should be incidental to the cost per hour.

All equipment and materials necessary for onsite support of minor materials including, but not limited to, fuses, fasteners, jumper cables, and cable connectors shall be included in this work.

https://itsforge.net/index.php/component/ars/repository/traveler-information/D2X%20Hub%20v1 https://itsforge.net/index.php/component/ars/repository/traveler-information/D2X%20Hub%20v1

Item 4-11 Onsite Support, Manufacturer

This item covers on-site support provided by a specialist from the equipment manufacturer for onsite assistance with but not limited to troubleshooting, programming, and testing of the RSUs & OBUs. Item shall be paid by the day. Any travel, lodging, meals and transportation should be incidental to the cost per day.

All equipment and materials necessary for onsite support of minor materials including, but not limited to, fuses, fasteners, jumper cables, and cable connectors shall be included in this work.

Item 4-12 Connected Vehicle System Integration Assistance

Includes support and assistance from a qualified professional for OBU/RSU data transfer, storage, network integration, cloud support etc. to meet the requirements of the specific scope of work.

Item 4-13 Connected Vehicle Application Testing

This item covers on-site testing to validate the functionality of the connected vehicle applications. This includes the ability to transmit messages from vehicle-to-infrastructure and vehicle-to-vehicle. The testing shall be performed over the existing ODOT network to ensure expected connectivity and system operations are validated.

Item 4-14 Connected Vehicle OBU Installation

This item includes the installation only of an OBU into a vehicle. It should include all mounting, wiring, power connections etc. to make a functional unit. This includes ensuring the OBU is compatible with existing vehicle equipment such as fuel master, GPS/AVL equipment, a DMI etc. All Necessary materials will be supplied. Software and configuration will be separate from this item.

Item 4-15 Connected Vehicle OBU Vehicle Integration

This item includes the integration of an OBU into the CAN Bus of a vehicle for one vehicle data set, as directed.

Can BUS vehicle data sets shall include, but not be limited to the following:

Lights / sirens

Speedometer

Hard Braking

Left and Right turn signals

Transmission State

Brake Status (Pressure applied)

Antilock brakes status

Item 4-16 Rear View Mirror Display Installation

This item includes the installation only of a V2X HMI rear view display into a vehicle and connecting to an OBU. It should include all mounting, wiring, power connections etc. to make a functional unit. All Necessary materials will be supplied via the via the bid item in this contract.

Item 4-17 Heads-Up Display Installation

This item includes the installation only of a Heads-up display into a vehicle, so that the on-board unit display is projected on to the windshield in a location that does not obstruct the driver’s view of the roadway but is within their field of view while driving. It should include all mounting, wiring, power connections etc. to make a functional unit and connect to an OBU. All Necessary materials will be supplied via the via the bid item in this contract.

Item 4-18 Connected Vehicle OBU Installation Support and Configuration

This item includes on-site support for the configuration and setup of an OBU to make it fully functional & operational per its intended application inside a vehicle. Installation will be by others. This item is primarily for software configuration and setup to make a unit fully functional for its intended application. Payment shall be per each vehicle, complete in place, field tested and accepted.

Item 4-19 Training

Furnish eight hours of training in the operation, setup, and maintenance of a connected vehicle system. Furnish all handouts, manuals, and product information. Train on the same models of equipment furnished for the project. The training shall take place at ODOT Central Office, W. Broad Street Columbus, Ohio 43223. Furnish all media, literature and test equipment needed to present the training. Training instructor(s) shall be directly from the manufacturer, experienced in the skill of training others, and have conducted a minimum of three one day trainings on the connected vehicle technology.

ODOT - DRIVEOHIO shall coordinate the training a minimum of 30 days in advance of proposed date of training. Training shall be for up to 25 people. Any travel, lodging, meals, and transportation should be incidental to the training cost.

Need to add requirements for Device Management Platform

Item 4-25 Security Credential Management System Services - Dashboard Platform

4.25.1 Platform

This item shall consist of a web-user interface to monitor the status of SCMS certificates as they pertain to RSUs and OBUs deployed throughout the state and organized on a per deploying agency basis.

4.25.2 Certificate Association

Devices enrolled for SCMS certificate provision shall be associated with specific agencies within the State of Ohio. All certificates enrolled by DriveOhio shall be entered into the ODOT account and shall be available in the ODOT specified dashboard.

Vendors procuring certificates for use within the State of Ohio profile should be associating the specific devices with respective agencies as they are enrolled. This will allow RSU and OBU certificates to be tracked on an agency basis.

4.25.3 Dashboard

4.25.3.1 Access

The platform shall be configured in a way that allows for a tiered structure. The dashboard shall provide for DriveOhio to be the overarching administrative entity for the dashboard and this will allow DriveOhio to access the individual dashboards for all Ohio enrolled agencies. Each enrolled agency shall be provided a separate dashboard for use in tracking the certificate status of their individual devices. This access will be controlled by the SCMS provider and DriveOhio admin accounts through the configuration of individual user accounts and the association of those user accounts with specific agencies. The base cost of the platform shall include licenses for 10 user accounts. Additional user licenses will be purchased separately on an as needed basis.

DriveOhio

Columbus Dublin Marysville Ohio DOT Others. . .

Platform ADMIN View SCMS Operations Statewide

Create Users Assign Users to DriveOhio or lower level system views

Local System Users View Local Level system views

Specific System View Only

4.25.3.2 Dashboard Creation

SCMS Dashboards shall be created for each enrolled agency. As new agencies come online with V2X projects and SCMS-enrolled equipment is deployed, new dashboards shall be created for those entities. The cost of the additional dashboard shall be included in the bid price of the Dashboard platform.

4.25.3.3 Dashboard Content

SCMS Dashboards shall consist of a multi-level view structure as follows:

a. High Level View – shows total number of devices enrolled and by type.

Shows high-level status of devices by type. Status shall be presented as one of the following:

• Up-to-date

• Behind

• No Active Certs

• Deactivated

• Expired

b. Medium Level View – shows graphical representation of certificate downloads in time window. Differentiates number of devices that have more than half of their certificates vs. number of devices that have less than half of their certificate life-cycle.

c. Detailed Level View – This view allows the user to dig deeper into specific device level information. This shows when the last activity was and any relevant diagnostic information / error messages that are generated based on the certificate update activity. This view also allows the user to enter/view useful device level information so that devices can be related to specific locations / vehicles for easy management and maintenance. It is important to note that no specific vehicle information will be entered here for privately owned vehicles.

4.25.3.4 User Notifications

The platform shall allow each user to maintain their respective user information to allow the system to generate notifications to activated users based on user preference. The notifications shall initially be based on devices that have one of the following characteristics:

1. Device has not been loaded with the next weeks certificates, or

2. Device has no active certificates.

Item 4-26 SCMS Dashboard User License

This item shall be for an increase in user licenses on a per license basis, in addition to the base number of licenses included in the dashboard platform.

Item 4-29 Connected Vehicle Device Management System Platform

This item shall be for a turn-key off-the-shelf connected vehicle device management system platform that supports the State of Ohio and its local municipal jurisdictions. The system shall be cloud hosted include user licenses for 40 users, any needed VPN licenses for system security and shall provide the following functionality.

1. Device Interoperability

a. The platform shall support all current models of RSU equipment from all major vendors, including Yunex, Cohda, Kapsch, Commsignia, Danlaw, Harman, etc.

b. The platform shall support device management MIB 4.1 and shall also support the NTCIP 1218 MIB within 3 months of procurement. The platform shall allow the selection of device management MIB on a per RSU basis.

2. Connected Intersection Functionality

a. The platform shall support creation and sending of the J2735 required elements of the MAP message including all ingress lanes and all associated egress lanes within an intersection.

b. The platform shall visually show the MAP msg configuration of each intersection during the monitoring of each intersection.

c. Shall support all required elements within CTI4001 for a management platform.

d. Shall support transmitting RTCM v3.2 or later to RSU for broadcast.

3. Data Collection and Storage

a. The platform shall store all associated V2X messages sent and received by RSUs connected / managed by the platform. (ie. BSMs, TIMs, SPaT, MAP, RSM, etc.)

b. The data shall be viewable in a dashboard format and shall be downloadable in a CSV format.

c. The platform shall also support APIs for connections to other data platforms.

4. Dashboard

a. The dashboard shall show a mapped status icon for each RSU and OBU detected within the system and shall update the mapped icon if the device location changes. The location of the device shall be determined via the GPS coordinates of the device.

b. The ability to monitor the message types and sources being broadcast by each RSU shall be available.

c. SCMS Enrollment and certificate top off information shall be viewable within the dashboard view for each RSU.

d. The system logs for each RSU shall be available to be viewed.

5. Message Handling

a. The platform shall accept messages configured from other sources and if configured, shall relay those messages to the proper RSUs to be broadcast via immediate forward.

b. The platform shall have the capability to generate TIM/RSM both within the functionality of the software and accept those types of messages from external sources for distribution to RSUs for broadcast via Immediate Forward and/or Store and Repeat methodology.

6. State of Ohio OIT Provisions

a. The vendor shall complete Supplement A and Supplement S documents showing how they meet the included requirements of the State of Ohio Office of Information Technology.