Attachment_C_Technical_Specifications_Requirements_Response_TR0-6357.xlsx
XLSX spreadsheet 32 KB Posted
- Solicitation number
- TR0-6357
- Issued by
- King County, Washington
About this file
The document is a technical specifications spreadsheet for the City of Seattle's USDOT/FHWA Traffic Management Equipment and Services contract, part of the University of Washington Multimodal Integrated Corridor Mobility for All (UW MICMA) and Strengthening Mobility and Revolutionizing Transportation (SMART) projects. The solicitation seeks comprehensive intelligent transportation system equipment, including edge devices, cameras, roadside units (RSUs), and onboard units (OBUs) for improving safety and efficiency at signalized intersections in the Rainier Valley. Proposals are due by 2:00 pm on Tuesday, October 1, 2024, and will be submitted through the city's procurement portal.
The technical specifications detail extensive requirements for multimodal traffic detection, connected vehicle applications, and safety analytics, with a focus on deploying advanced sensing infrastructure. The system must provide real-time detection of vehicles, pedestrians, and cyclists, generate detailed safety reports, support V2X communications, and integrate with existing traffic signal controllers. The project is funded by FHWA and USDOT grants, targeting improvements in community safety through technology investments. Key technical capabilities include AI-powered analytics, 90% detection accuracy, comprehensive reporting features, and robust security protocols for message authentication and data protection.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| USDOT_FHWA_Traffic_Management_Equipment_and_Services_(Addendum_#1_Revision).pdf | ||
| Requirements_for_Insurance.docx | DOCX document | |
| Attachment_E_Federal_Provisions_Supplement_for_TRO_RFP#6357.pdf | ||
| City_Technology_Terms_and_Conditions.pdf | ||
| SDOT_Concurrence_SMART_Grant_Agreement_Draft_Version_-_signed.pdf | ||
| Attachment_#1_-_FHWA_Cooperative_Agreement_No._693JJ31950002_and_T&C's.pdf | ||
| System_Support_Agreement.docx | DOCX document | |
| Terms-and-Conditions.docx | DOCX document | |
| fas-pc-purchasing-technology-contract-hardware-software.docx | DOCX document | |
| IT_Pricing_Table_Template.xlsx | XLSX spreadsheet | |
| Rebate_Template.xlsx | XLSX spreadsheet |
Show all 11
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Sheet1
| Deliverable Category | Sub-Category | Requirement No. | Requirement/Specification | Yes, Full Compliance | Partial Compliance | No, Does Not Comply | In this space provide additional information/explanation. Additional information/explanation is REQUIRED if Partial Compliance is checked. |
| 1. Edge Device | 1.1 Analytics Engine Requirements | 1.1.1 | The analytics engine shall make use of off-the-shelf hardware including but not limited to edge processors and cameras. | ||||
| 1. Edge Device | 1.1 Analytics Engine Requirements | 1.1.2 | The analytics engine shall be deployed locally at each intersection within an edge unit in the traffic signal control cabinet. | ||||
| 1. Edge Device | 1.1 Analytics Engine Requirements | 1.1.3 | The analytics engine shall provide all the functionality listed in these specifications with a maximum of two field-deployed cameras for a standard four-legged intersection, with a minimum system accuracy of at least 90%. | ||||
| 1. Edge Device | 1.1 Analytics Engine Requirements | 1.1.4 | The analytics engine shall use new or existing cameras. | ||||
| 1. Edge Device | 1.1 Analytics Engine Requirements | 1.1.5 | The analytics engine shall work with fixed view or PTZ; rectilinear, panoramic/fisheye images, all being network cameras. | ||||
| 1. Edge Device | 1.1 Analytics Engine Requirements | 1.1.6 | The analytics engine shall fuse video sensor data in real-time (performing multi-sensor, multiple camera tracking into a single unified representation, and to suppress duplicate road user detection data. | ||||
| 1. Edge Device | 1.1 Analytics Engine Requirements | 1.1.7 | The analytics engine shall perform multimodal detection (including vehicles, light rail, pedestrians and cyclists) in all lighting and environmental conditions with a minimum 90 percent accuracy, as substantiated by third-party agency or academic analyses. | ||||
| 1. Edge Device | 1.1 Analytics Engine Requirements | 1.1.8 | The analytics engine shall rely on Artificial Intelligence tools and approaches to enhance and process video to produce the required data elements. | ||||
| 1. Edge Device | 1.1 Analytics Engine Requirements | 1.1.9 | The analytics engine shall perform real-time road user localization (physical position / location of detected road user object). | ||||
| 1. Edge Device | 1.1 Analytics Engine Requirements | 1.1.10 | The analytics engine shall perform road user movement and intent prediction. | ||||
| 1. Edge Device | 1.1 Analytics Engine Requirements | 1.1.11 | The analytics engine shall support industry standard road safety data proxy messages including SAE J2735 & J2945/x. | ||||
| 1. Edge Device | 1.2 Compute Platform Requirements | 1.2.1 | The system shall run LOCALLY at the roadside edge (on sensor or on an edge processing device). | ||||
| 1. Edge Device | 1.2 Compute Platform Requirements | 1.2.2 | The unit shall be a ruggedized module embedding computing capable of processing in real-time at least eight high-definition camera feeds simultaneously. | ||||
| 1. Edge Device | 1.2 Compute Platform Requirements | 1.2.3 | The unit shall provide for Gigabit network communications with the capability for at least four devices (such as cameras, RSUs, etc.) to be powered using embedded Power-Over-Ethernet ports. | ||||
| 1. Edge Device | 1.2 Compute Platform Requirements | 1.2.4 | The unit shall allow for SDLC communications with the signal controller. | ||||
| 1. Edge Device | 1.2 Compute Platform Requirements | 1.2.5 | The unit shall be expandable to support additional SDLC and I/O communications. | ||||
| 1. Edge Device | 1.2 Compute Platform Requirements | 1.2.6 | The unit shall allow for cellular communications. | ||||
| 1. Edge Device | 1.2 Compute Platform Requirements | 1.2.7 | The unit shall operate primarily without a built-in fan. The unit shall allow for the addition of an external fan in certain conditions which can be removed at any point in time without affecting the system performance materially. | ||||
| 1. Edge Device | 1.2 Compute Platform Requirements | 1.2.8 | The unit shall meet NEMA TS-2 environmental specifications. | ||||
| 1. Edge Device | 1.3 Analytics System Integration, Configuration, Operation and Maintenance Requirements | 1.3.1 | The system shall provide access to Safety and Traffic data and insights along with recorded videos through a web-based dashboard for an unlimited number of users and must include user authentication using two factor authentications. | ||||
| 1. Edge Device | 1.3 Analytics System Integration, Configuration, Operation and Maintenance Requirements | 1.3.2 | The system shall provide high frequency health and status checks (incl. power failures, memory usage, processor usage, communications failure, etc.) and provide system monitoring reports. | ||||
| 1. Edge Device | 1.3 Analytics System Integration, Configuration, Operation and Maintenance Requirements | 1.3.3 | The system shall be able to push notifications and alerts on detected events and system health and status issues through email, SMS and customizable push/pull APIs to third-party systems. | ||||
| 1. Edge Device | 1.3 Analytics System Integration, Configuration, Operation and Maintenance Requirements | 1.3.4 | The system shall be able to push processed data and reports to third-party systems (ATMS, ICM) through customizable push/pull APIs. | ||||
| 1. Edge Device | 1.3 Analytics System Integration, Configuration, Operation and Maintenance Requirements | 1.3.5 | The system shall be able to ingest third-party data available through APIs such as count, traffic conditions, weather, or connected vehicle data. | ||||
| 1. Edge Device | 1.3 Analytics System Integration, Configuration, Operation and Maintenance Requirements | 1.3.6 | The system shall have an uptime of over 99%. | ||||
| 1. Edge Device | 1.3 Analytics System Integration, Configuration, Operation and Maintenance Requirements | 1.3.7 | The system shall provide remote as well as local configuration and maintenance capabilities. | ||||
| 1. Edge Device | 1.3 Analytics System Integration, Configuration, Operation and Maintenance Requirements | 1.3.8 | The system shall allow for maintenance and troubleshooting by trained third-party technicians. | ||||
| 1. Edge Device | 1.3 Analytics System Integration, Configuration, Operation and Maintenance Requirements | 1.3.9 | A web-based user interface shall be provided that supports an unlimited number of users. | ||||
| 1. Edge Device | 1.4 Analytics System and Edge Unit Training and Support | 1.4.1 | The system shall be warranted for a minimum of 2 years against failure of hardware or software. | ||||
| 1. Edge Device | 1.4 Analytics System and Edge Unit Training and Support | 1.4.2 | The system shall include a minimum of 2 years of software maintenance and updates. | ||||
| 1. Edge Device | 1.4 Analytics System and Edge Unit Training and Support | 1.4.3 | Training shall be included for a minimum of 16 hours. | ||||
| 1. Edge Device | 1.5 Multimodal Traffic Data Collection and Analytics | 1.5.1 | The system shall be able to be deployed at intersection, roundabouts, or other road segments such as mid-block locations. | ||||
| 1. Edge Device | 1.5 Multimodal Traffic Data Collection and Analytics | 1.5.2 | The system shall be able to detect, count and classify different vehicle classes and light rail in real-time. | ||||
| 1. Edge Device | 1.5 Multimodal Traffic Data Collection and Analytics | 1.5.3 | For intersections, roundabouts, and road segments, the system shall be able to detect, count and classify different classes of vulnerable road users in real-time (e.g. pedestrians and bicyclists). | ||||
| 1. Edge Device | 1.5 Multimodal Traffic Data Collection and Analytics | 1.5.4 | For intersections, roundabouts, or road segments, the system shall be able to detect and calculate average speed of each road user. | ||||
| 1. Edge Device | 1.5 Multimodal Traffic Data Collection and Analytics | 1.5.5 | For intersections, roundabouts, or road segments, the system shall be able to calculate occupancy and density values for the location. | ||||
| 1. Edge Device | 1.5 Multimodal Traffic Data Collection and Analytics | 1.5.6 | For intersections or roundabout, the system shall be able to calculate average vehicle delay. | ||||
| 1. Edge Device | 1.6 Multimodal Traffic Data Collection and Analytics Reporting | 1.6.1 | The system shall provide a Vehicle and VRU Counts Report | ||||
| 1. Edge Device | 1.6 Multimodal Traffic Data Collection and Analytics Reporting | 1.6.2 | The system shall provide a Vehicle Classification Report | ||||
| 1. Edge Device | 1.6 Multimodal Traffic Data Collection and Analytics Reporting | 1.6.3 | The system shall provide a Vehicle Occupancy Report | ||||
| 1. Edge Device | 1.6 Multimodal Traffic Data Collection and Analytics Reporting | 1.6.4 | The system shall provide a Vehicle Density Report | ||||
| 1. Edge Device | 1.6 Multimodal Traffic Data Collection and Analytics Reporting | 1.6.5 | The system shall provide a Turning Movement Counts Report | ||||
| 1. Edge Device | 1.6 Multimodal Traffic Data Collection and Analytics Reporting | 1.6.6 | The system shall provide a Peak hour count Report | ||||
| 1. Edge Device | 1.6 Multimodal Traffic Data Collection and Analytics Reporting | 1.6.7 | The system shall provide a Vehicle Delay Report | ||||
| 1. Edge Device | 1.6 Multimodal Traffic Data Collection and Analytics Reporting | 1.6.8 | The system shall provide an Over speed limit Vehicles Report | ||||
| 1. Edge Device | 1.6 Multimodal Traffic Data Collection and Analytics Reporting | 1.6.9 | The system shall generate the statistical reports for specific date ranges defined by the user. | ||||
| 1. Edge Device | 1.6 Multimodal Traffic Data Collection and Analytics Reporting | 1.6.10 | The system shall arrange the statistical reports to visualize data by day of the week, at 5, 15, 30, 60-minute intervals or at a user-defined time interval. | ||||
| 1. Edge Device | 1.6 Multimodal Traffic Data Collection and Analytics Reporting | 1.6.11 | The system shall arrange the statistical reports to visualize data for predefined or user-defined speed ranges. | ||||
| 1. Edge Device | 1.6 Multimodal Traffic Data Collection and Analytics Reporting | 1.6.12 | The system shall generate and filter the statistical reports by Class of vehicles or vulnerable road users. | ||||
| 1. Edge Device | 1.6 Multimodal Traffic Data Collection and Analytics Reporting | 1.6.13 | The system shall generate and filter the statistical reports by Lane or Movement. | ||||
| 1. Edge Device | 1.6 Multimodal Traffic Data Collection and Analytics Reporting | 1.6.14 | The system shall identify the peak hour and volume for the whole day, daytime and nighttime. | ||||
| 1. Edge Device | 1.6 Multimodal Traffic Data Collection and Analytics Reporting | 1.6.15 | The system’s reports shall allow the user to compare different timeframes for before and after studies | ||||
| 1. Edge Device | 1.6 Multimodal Traffic Data Collection and Analytics Reporting | 1.6.16 | The system shall provide for the export of raw data, and generated reports shall be exportable in common formats including at least CSV format. | ||||
| 1. Edge Device | 1.6 Multimodal Traffic Data Collection and Analytics Reporting | 1.6.17 | The data shall be stored in the US with flexible and configurable data retention policies. For example, the City requires all automatically collected video be retained no more than 10 days. | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.1 | The system shall identify all the following violation at a location in real-time using video data and SPaT data from the signal controller: Illegal Pedestrian Crossing Events | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.2 | The system shall identify all the following violation at a location in real-time using video data and SPaT data from the signal controller: Pedestrian Signal Violations (provided an integration with the controller is available) | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.3 | The system shall identify all the following violation at a location in real-time using video data and SPaT data from the signal controller: Red-Light Violations (provided an integration with the controller is available) | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.4 | The system shall identify all the following violation at a location in real-time using video data and SPaT data from the signal controller: Illegal Turning Movement Violations: Illegal U-Turn | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.5 | The system shall identify all the following violation at a location in real-time using video data and SPaT data from the signal controller: Illegal Turning Movement Violations: Illegal Right Turn | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.6 | The system shall identify all the following violation at a location in real-time using video data and SPaT data from the signal controller: Illegal Turning Movement Violations: Illegal Left Turn | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.7 | The system shall identify all the following violation at a location in real-time using video data and SPaT data from the signal controller: Illegal Turning Movement Violations: Illegal Through Movements | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.8 | The system shall identify all the following violation at a location in real-time using video data and SPaT data from the signal controller: Lane Compliance Violations | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.9 | The system shall identify all the following violation at a location in real-time using video data and SPaT data from the signal controller: Stopped Vehicle Violations | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.10 | The system shall identify all the following violation at a location in real-time using video data and SPaT data from the signal controller: Wrong Way Driving Violations | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.11 | The system shall identify all the following violation at a location in real-time using video data and SPaT data from the signal controller: Near Miss Events | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.12 | The system shall identify all the following violation at a location in real-time using video data and SPaT data from the signal controller: Crashes | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.13 | Near Miss events shall include events between vehicles and events between vehicles and vulnerable road users (VRU) at a location based on processed real-time video data. | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.14 | Near Miss events shall post at least the following information on detected Near-miss events: Date and Time of the event, vehicle speed, Post Encroachment Time (PET), Time to Collision (TTC), Gap Time, Classes of the road users Involved, Conflict Type, Road User Movement and Direction of Travel. | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.15 | For Near Miss Events, users shall be able to configure level of severity. | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.16 | Crash events shall include events between vehicles and events between vehicles and vulnerable road users (VRU) based on real-time video data. | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.17 | Crash events shall post at least the following information: Date and Time of the event, vehicle speed, Classes of the road users Involved, Crash Type, Road User Movement and Direction of Travel. | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.18 | For all types of violations, the system shall post at least the following information (when applicable): Date and Time of the event, Signal Phase at the time of the violation, Vehicle Speed and Direction of Travel. | ||||
| 1. Edge Device | 1.7 Multimodal Road Safety Analytics | 1.7.19 | The system shall link the relations between two separate events if applicable (i.e. Lane Compliance Violation led to a Near Miss Event). | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.1 | The system shall provide visualization of detected event reports with related video and data including: Date and Time | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.2 | The system shall provide visualization of detected event reports with related video and data including: Type of event with parameters | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.3 | The system shall provide visualization of detected event reports with related video and data including: Approach with direction of travel | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.4 | The system shall provide visualization of detected event reports with related video and data including: Video recordings of the detected events | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.5 | The system shall be able to generate event statistics reports which can be filtered for a user-defined date range. | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.6 | All event count data shall be capable of being arranged to be visible by day of the week, for 5, 15, 30, 60-minute time-intervals or at a user-defined time interval. | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.7 | The system shall represent all the data through multiple statistical and graphical reports based on user-defined parameters (including line charts, bar charts, tables,). | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.8 | The system shall provide the user a means of filtering across the meta data associated with each event. | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.9 | The system shall be able to export raw data and generated reports shall be exportable in common formats including at least CSV and PDF. | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.10 | The system shall be able to generate an aggregated report in the form of heat maps based upon event data such as near-miss. | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.11 | For Near Miss events, the system shall be able to generate an aggregated report By Severity | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.12 | For Near Miss events, the system shall be able to generate an aggregated report By Day of Week | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.13 | For Near Miss events, the system shall be able to generate an aggregated report By Time of Day | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.14 | For Near Miss events, the system shall be able to generate an aggregated report By Movement | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.15 | For Near Miss events, the system shall be able to generate an aggregated report By Direction | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.16 | The system shall be able to generate a safety score for each location based on safety and/or traffic data. | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.17 | The system shall allow the user to configure the safety score calculation based upon user defined preferences | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.18 | The corresponding safety score for each location shall be easily visualized and interpreted on the dashboard’s main map. | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.19 | The system shall prioritize the worst performing locations in a list across a network/corridor/project based upon safety score | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.20 | The data shall be stored in the US with flexible and configurable data retention policies. | ||||
| 1. Edge Device | 1.8 Edge Unit Multimodal Road Safety Analytics Reporting | 1.8.21 | The system shall provide real-time notifications of all events in the form of emails, text messages (SMS), and customizable APIs to third-party systems | ||||
| 1. Edge Device | 1.9 Multimodal Traffic Detection for Traffic Control | 1.9.1 | The system shall be able to detect, track, classify, and predict the intent of all road users within a sensor’s field of view. | ||||
| 1. Edge Device | 1.9 Multimodal Traffic Detection for Traffic Control | 1.9.2 | The system shall be able to detect pedestrian surges approaching intersection crosswalks | ||||
| 1. Edge Device | 1.9 Multimodal Traffic Detection for Traffic Control | 1.9.3 | The system shall be capable of emulating inductive traffic loop detectors. It shall allow the user to define detection zones and convert road user presence within the zone into a traffic signal controller input for zone or phase activation (pulse or presence mode). | ||||
| 1. Edge Device | 1.9 Multimodal Traffic Detection for Traffic Control | 1.9.4 | The system shall allow the user to configure, for each zone, a delay in controller inputs when a road user is detected within the zone. | ||||
| 1. Edge Device | 1.9 Multimodal Traffic Detection for Traffic Control | 1.9.5 | The system shall be able to predict potential red light running vehicles. | ||||
| 1. Edge Device | 1.9 Multimodal Traffic Detection for Traffic Control | 1.9.6 | The system shall be able to integrate with standard traffic signal controllers using Network (SNMP, HTTP), SDLC, I/O communication and shall support common controller protocols such as NTCIP 1202 and AB3418. | ||||
| 1. Edge Device | 1.9 Multimodal Traffic Detection for Traffic Control | 1.9.7 | The system shall also be able to use User-Logic Command Operation (IF-THEN-ELSE) to communicate information to traffic signal controllers. | ||||
| 1. Edge Device | 1.9 Multimodal Traffic Detection for Traffic Control | 1.9.8 | The system shall be able to integrate with dynamic signs, beacons, or light controllers through common protocols. | ||||
| 1. Edge Device | 1.9 Multimodal Traffic Detection for Traffic Control | 1.9.9 | The system shall revert to a failsafe operating mode in the event a system or sensor health issue is reported, where the system shall be able to go into one of three modes: | ||||
| 1. Edge Device | 1.9 Multimodal Traffic Detection for Traffic Control | 1.9.10 | maximum recall mode | ||||
| 1. Edge Device | 1.9 Multimodal Traffic Detection for Traffic Control | 1.9.11 | minimum recall mode | ||||
| 1. Edge Device | 1.9 Multimodal Traffic Detection for Traffic Control | 1.9.12 | user-configurable fixed recall mode. | ||||
| 1. Edge Device | 1.9 Multimodal Traffic Detection for Traffic Control | 1.9.13 | The system shall support adaptive pedestrian operations using commercial off the shelf (COTS) adaptive signal control system software. | ||||
| 1. Edge Device | 1.9 Multimodal Traffic Detection for Traffic Control | 1.9.14 | Pedestrian detection shall aggregate up to eight zones into one to four outputs for adaptive operations. | ||||
| 1. Edge Device | 1.10 Connected Vehicle Applications - Edge Unit | 1.10.1 | The connected vehicle application shall have full functionality to broadcast and display live Signal Phase and Timing (SpaT) on the provided OBU user interface. | ||||
| 1. Edge Device | 1.10 Connected Vehicle Applications - Edge Unit | 1.10.2 | The connected vehicle application shall have full functionality to broadcast Sensor Data Sharing Message (SDSM) messages for all road users via the proposed C-V2X. | ||||
| 1. Edge Device | 1.10 Connected Vehicle Applications - Edge Unit | 1.10.3 | The connected vehicle application shall have full functionality to broadcast, transmit, receive, filter and display BSM and PSM alerts on the supplied OBU units. | ||||
| 1. Edge Device | 1.10 Connected Vehicle Applications - Edge Unit | 1.10.4 | The system shall be able to provide road user real-time detection, tracking, and classification object lists used to generate vehicle to everything (V2X) messages in compliance with SAE J3224_2022208 (Sensor Sharing Services (SSS)), SAE J2735, J2945/x, NTCIP 1202 v03A, and NTCIP 1218 v1 standards, including: SPaT messages | ||||
| 1. Edge Device | 1.10 Connected Vehicle Applications - Edge Unit | 1.10.5 | The system shall be able to provide road user real-time detection, tracking, and classification object lists used to generate vehicle to everything (V2X) messages in compliance with SAE J3224_2022208 (Sensor Sharing Services (SSS)), SAE J2735, J2945/x, NTCIP 1202 v03A, and NTCIP 1218 v1 standards, including: MAP Messages | ||||
| 1. Edge Device | 1.10 Connected Vehicle Applications - Edge Unit | 1.10.6 | The system shall be able to provide road user real-time detection, tracking, and classification object lists used to generate vehicle to everything (V2X) messages in compliance with SAE J3224_2022208 (Sensor Sharing Services (SSS)), SAE J2735, J2945/x, NTCIP 1202 v03A, and NTCIP 1218 v1 standards, including: Infrastructure generated Basic Safety Messages (BSMs) including lane-level localization, speed, acceleration, heading, vehicle size, path history and prediction (10Hz) | ||||
| 1. Edge Device | 1.10 Connected Vehicle Applications - Edge Unit | 1.10.7 | The system shall be able to provide road user real-time detection, tracking, and classification object lists used to generate vehicle to everything (V2X) messages in compliance with SAE J3224_2022208 (Sensor Sharing Services (SSS)), SAE J2735, J2945/x, NTCIP 1202 v03A, and NTCIP 1218 v1 standards, including: Infrastructure generated Personal Safety Messages (PSMs) including lane-level localization, speed, acceleration, heading, classification, crossing status and intent, path history and prediction (1-10Hz) | ||||
| 1. Edge Device | 1.10 Connected Vehicle Applications - Edge Unit | 1.10.8 | The system shall be able to provide road user real-time detection, tracking, and classification object lists used to generate vehicle to everything (V2X) messages in compliance with SAE J3224_2022208 (Sensor Sharing Services (SSS)), SAE J2735, J2945/x, NTCIP 1202 v03A, and NTCIP 1218 v1 standards, including: Infrastructure generated intersection collision avoidance (ICA) messages for collision avoidance at intersections (10Hz) | ||||
| 1. Edge Device | 1.10 Connected Vehicle Applications - Edge Unit | 1.10.9 | The system shall be able to provide road user real-time detection, tracking, and classification object lists used to generate vehicle to everything (V2X) messages in compliance with SAE J3224_2022208 (Sensor Sharing Services (SSS)), SAE J2735, J2945/x, NTCIP 1202 v03A, and NTCIP 1218 v1 standards, including: Infrastructure generated Sensor Data Sharing Messages (SDSM) for collision avoidance at intersections (10Hz) | ||||
| 1. Edge Device | 1.10 Connected Vehicle Applications - Edge Unit | 1.10.10 | The system shall be able to provide road user real-time detection, tracking, and classification object lists used to generate vehicle to everything (V2X) messages in compliance with SAE J3224_2022208 (Sensor Sharing Services (SSS)), SAE J2735, J2945/x, NTCIP 1202 v03A, and NTCIP 1218 v1 standards, including: Signal priority / preemption V2X messages (SRM, SSM, EVA) | ||||
| 1. Edge Device | 1.10 Connected Vehicle Applications - Edge Unit | 1.10.12 | The system shall be able to properly format the following V2X message for broadcasting per the SAE standards: SPaT messages | ||||
| 1. Edge Device | 1.10 Connected Vehicle Applications - Edge Unit | 1.10.13 | The system shall be able to properly format the following V2X message for broadcasting per the SAE standards: MAP messages | ||||
| 1. Edge Device | 1.10 Connected Vehicle Applications - Edge Unit | 1.10.14 | The system shall be able to properly format the following V2X message for broadcasting per the SAE standards: Infrastructure generated BSMs including lane-level localization, speed, acceleration, heading, vehicle size, path history and prediction (10Hz) | ||||
| 1. Edge Device | 1.10 Connected Vehicle Applications - Edge Unit | 1.10.15 | The system shall be able to properly format the following V2X message for broadcasting per the SAE standards: Infrastructure generated PSMs including lane-level localization, speed, acceleration, heading, classification, crossing status and intent, path history and prediction (1-10Hz) | ||||
| 1. Edge Device | 1.10 Connected Vehicle Applications - Edge Unit | 1.10.16 | The system shall be able to properly format the following V2X message for broadcasting per the SAE standards: Infrastructure generated intersection collision avoidance (ICA) messages for collision avoidance at intersections (10Hz) | ||||
| 1. Edge Device | 1.10 Connected Vehicle Applications - Edge Unit | 1.10.17 | The system shall be able to properly format the following V2X message for broadcasting per the SAE standards: Infrastructure generated Sensor Data Sharing Messages (SDSM) for collision avoidance at intersections (10Hz) | ||||
| 1. Edge Device | 1.10 Connected Vehicle Applications - Edge Unit | 1.10.18 | The system shall be able to properly format the following V2X message for broadcasting per the SAE standards: Signal priority / preemption V2X messages (SRM, SSM, EVA) | ||||
| 1. Edge Device | 1.10 Connected Vehicle Applications - Edge Unit | 1.10.19 | The system shall be able to transmit and receive connected vehicle data over cellular devices using 5G/LTE communication and the C-V2X RSUs provided by the vendor. | ||||
| 2. Camera System | 2.1 General | 2.1.1 | The camera shall include a 12MP sensor (minimum), delivering a full 360° field of view with sustained high image quality. | ||||
| 2. Camera System | 2.1 General | 2.1.2 | The camera shall have built-in Infrared (IR) illumination. | ||||
| 2. Camera System | 2.1 General | 2.1.3 | The device shall support digital PTZ views and de‑warped perspectives, encompassing panorama, quad, corner, and corridor options. | ||||
| 2. Camera System | 2.1 General | 2.1.4 | The camera shall include Power over Ethernet (PoE) technology to enable the provision of power and data. | ||||
| 2. Camera System | 2.1 General | 2.1.5 | The camera shall meet IP-66 specifications. | ||||
| 2. Camera System | 2.1 General | 2.1.6 | The camera enclosure shall meet NEMA 4X specifications. | ||||
| 2. Camera System | 2.1 General | 2.1.7 | The network standards support shall include: IPv4, IPv6 USGv6, ICMPv4/ICMPv6, HTTP, HTTPSa, HTTP/2,TLSa, QoS Layer 3 DiffServ, FTP, SFTP, CIFS/SMB, SMTP, mDNS (Bonjour), UPnP®, SNMP v1/v2c/v3 (MIB-II), DNS/DNSv6, DDNS, NTP, NTS, RTSP, RTP, SRTP/RTSPS, TCP, UDP, IGMPv1/v2/v3, RTCP, DHCPv4/v6, SSH, LLDP, CDP, MQTT v3.1.1, Syslog, Link-Local address (ZeroConf), IEEE 802.1X (EAP-TLS), and IEEE 802.1AR | ||||
| 2. Camera System | 2.2 Lens | 2.2.1 | The lens focal length shall be 1.2mm minimum. | ||||
| 2. Camera System | 2.2 Lens | 2.2.2 | The lens horizontal field of view shall be at least 182 degrees. | ||||
| 2. Camera System | 2.2 Lens | 2.2.3 | The lens vertical field of view shall be at least 182 degrees. | ||||
| 2. Camera System | 2.3 Image Compression | 2.3.1 | The video compression engine shall be capable of reducing H.264 bandwidth and storage requirements by at least 15%. | ||||
| 2. Camera System | 2.3 Image Compression | 2.3.2 | H.264 shall be fully supported. | ||||
| 2. Camera System | 2.3 Image Compression | 2.3.3 | H.265 shall be fully supported. | ||||
| 2. Camera System | 2.3 Image Compression | 2.3.4 | Motion JPEG shall be fully supported. | ||||
| 2. Camera System | 2.4 Video Image | 2.4.1 | The image sensor shall be CMOS. | ||||
| 2. Camera System | 2.4 Video Image | 2.4.2 | The image sensor size shall be 1/2.3 | ||||
| 2. Camera System | 2.4 Video Image | 2.4.3 | The Wide Dynamic Range (WDR) shall be Forensic WDR with up to 120 dB, depending on scene. | ||||
| 2. Camera System | 2.4 Video Image | 2.4.4 | The minimum illumination/light sensitivity (color) shall be 0.19 lux or better. | ||||
| 2. Camera System | 2.4 Video Image | 2.4.5 | The minimum illumination/light sensitivity (B/W) shall be 0.04 lux or better. | ||||
| 2. Camera System | 2.4 Video Image | 2.4.6 | A day and night Automatic IR-cut filter shall be provided. | ||||
| 2. Camera System | 2.4 Video Image | 2.4.7 | The camera shall include on-board processing of images produced under extremely low lux conditions to provide full-color crisp images. | ||||
| 2. Camera System | 2.4 Video Image | 2.4.8 | The camera angle shall support digital roll of + 360 degrees. | ||||
| 2. Camera System | 2.4 Video Image | 2.4.9 | The shutter speed shall range from 1/8100 sec to 0.5 sec. | ||||
| 2. Camera System | 2.4 Video Image | 2.4.10 | Noise reduction shall be provided with a spatial filter (2D noise reduction) and a temporal filter (3D noise reduction). | ||||
| 2. Camera System | 2.4 Video Image | 2.4.11 | Image settings shall include: Saturation, contrast, brightness, sharpness, local contrast, tone mapping, white balance, day/night threshold, exposure mode, exposure zones, compression, mirroring, dynamic text and image overlay, and polygon privacy mask | ||||
| 3. Camera Mounting Hardware | 3.1 General | 3.1.1 | Vendor must furnish all camera mounting bracket and hardware capable of mounting to the luminaire arm, mast arm, or pole as specified by SDOT. | ||||
| 3. Camera Mounting Hardware | 3.1 General | 3.1.2 | The mounting must meet the recommendations of the camera manufacturer and be submitted for approval. | ||||
| 3. Camera Mounting Hardware | 3.1 General | 3.1.3 | Vendor must furnish all bolts required to mount the video detection cameras and mounting bracket. | ||||
| 3. Camera Mounting Hardware | 3.1 General | 3.1.4 | All parts must be made of corrosion resistant materials. | ||||
| 3. Camera Mounting Hardware | 3.1 General | 3.1.5 | All external screws, nuts and locking washers must be stainless steel or galvanized. No self-tapping screws to be used. | ||||
| 3. Camera Mounting Hardware | 3.1 General | 3.1.6 | All materials must be resistant to fungus growth and moisture deterioration. | ||||
| 3. Camera Mounting Hardware | 3.1 General | 3.1.7 | The camera must require no aiming or focusing of the camera assembly due to the mounting hardware. | ||||
| 4. Camera Cable | 4.1 General | 4.1.1 | Each camera shall be supplied with a heavy-duty UV resistant jacket and CMX rated shielded outdoor CAT 6/6A/or Cat 7 Ethernet Cable of the required length, meeting the following: | ||||
| 4. Camera Cable | 4.1 General | 4.1.2 | The cable shall support power-over-ethernet (POE) PoE/PoE+/PoE++ (IEEE 802.3af/at/bt) up to 75 Watts | ||||
| 4. Camera Cable | 4.1 General | 4.1.3 | The cable shall provide for SFTP transmission | ||||
| 4. Camera Cable | 4.1 General | 4.1.4 | The cable shall be compliant with ANSI/TIA/EIA-568-B. 2-10, 10BASE-T, 100BASE-TX (Fast Ethernet), 1000BASE-T/1000BASE-TX (Gigabit Ethernet) and 10GBASE-T(10-Gigabit Ethernet) at high speeds. | ||||
| 4. Camera Cable | 4.1 General | 4.1.5 | The cable shall be supplied with pre-installed shielded and outdoor rated RJ45 connectors on each end. | ||||
| 4. Camera Cable | 4.1 General | 4.1.6 | The specified POE ethernet cable shall be compatible with the supplied CCTV camera and POE ports found on the edge computing device or switching equipment. The specified cable shall be able to power the supplied camera and provide data transfer between the edge computing device and the camera. | ||||
| 5. Connected Vehicle Application | 5. General | 5.1.1 | The connected vehicle application shall comprise a complete end-to-end system as required to provide a fully functioning system that provides all required detection, message generation and broadcasting, and system configuration and management. | ||||
| 5. Connected Vehicle Application | 5. General | 5.1.2 | The complete end-to-end system shall include, but not be limited to the following: | ||||
| 5. Connected Vehicle Application | 5. General | 5.1.3 | All required hardware including but not limited to edge units, RSU, OBU, routers, cabling, mounting hardware, antennas, GNS/GPS, HMI displays, servers, SDLC controller interface for SPaT data and any other required hardware. | ||||
| 5. Connected Vehicle Application | 5. General | 5.1.4 | Software including HMI with Web UI for alert display via OBU, SDSM, MAP, TIM, BSM, PSM message generation, message broadcasting, message filtering, SCMS server application, RSU and OBU system management. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.1 | The RSU shall be protected from power surges, power spikes, and electrical noise. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.2 | The RSU shall be resistant to vibration and shock. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.3 | The RSI shall be resistant to out-of-band communications and out-of-channel interference to protect the V2X signal in the operating channel. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.4 | The RSU shall be resistant to electrostatic discharge (ESD). | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.5 | The RSU shall have limited electronic emissions that cause radio frequency interference (RFI) and electromagnetic interference (EMI). | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.6 | The RSU shall be capable of various mounting configurations including shelf, wall, rack or vertical or horizontal (including on a traffic signal pole mast arm) pole mounting. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.7 | The RSU shall support diagnostic testing, including the RSU as a whole and individual components. The diagnostic settings shall include one in which all messages can be forwarded without verifying a signature, and shall also support storage of messages sent and received. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.8 | The RSU shall be able to receive and install software and firmware updates both locally and remotely. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.9 | The RSU start up routine shall start up using a specific configuration including network and V2X interfaces, allowing the operator to configure the state and setup of the RSU when it is powered up. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.10 | The RSU shall have remote restart capability, restarting to the following options: Factory Settings, Default, and Last Saved – including network and V2X settings. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.11 | The RSU shall have local restart capability, with a requirement to recycle the power at the PoE source. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.12 | The RSU shall accurately maintain time. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.13 | The RSU shall synchronize to a common time reference used ty the surrounding transportation infrastructure, via an NTP server maintained by the City of Seattle for this purpose. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.14 | The RSU shall estimate its current location. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.15 | The RSU shall include a network interface to connect to the RSCE, TMS, and any back-office systems, and is configured using objects defined in NTCIP 1218v01. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.16 | The RSU shall include non-volatile log files that record events. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.17 | The RSU shall collect statistical data about V2X messages set and received, and V2X devices within range of the RSU. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.18 | The RSU shall coordinate with multiple RSUs within the same communication zone to improve performance. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.19 | The RSU shall forward messages received from local field devices, back-office systems, or TMS to the V2X interface. If the message received is not signed or encrypted, the RSU signs and may encrypt the message before transmitting it on to the V2X interface. For example, a traffic signal controller may generate a SPaT and/or Signal Status message; or information displayed on a DMS may be sent as an unsigned message by the DMS to the RSU. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.20 | The RSU shall immediately forward messages signed by the message source from local field devices, back-office systems, or TMS to the V2X interface. In the case the message received is already signed and optionally encrypted, the RSU will forward it to the V2X interface without additional security processing. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.21 | The RSU shall periodically transmit messages stored on the RSU to the V2X interface. If the stored messages are not signed or encrypted the RSU will sign and may encrypt the message before transmittal. If the stored messages are signed by the message source, no additional processing is needed at the RSU. | ||||
| 6. Roadside Units (RSUs) | 6.1 RSU General | 6.1.22 | The RSU shall forward messages received from local field devices, back-office systems, or TMS, depending on the application content. WAVE Short Messages are verified at the RSU that they are validly signed (and decrypted if encryption is used) before forwarding. The RSU will only verify the message if it is being forwarded. When using Diagnostic Mode, support for forwarding messages without verifying signature shall be provided. | ||||
| 6. Roadside Units (RSUs) | 6.2 Applications Contained on the RSU | 6.2.1 | The RSU shall broadcast SPaT information in real time from connected traffic signal controllers. The RSU shall communicate with the controllers to receive the SPaT information and covert it to SAE J2735_202007 format. The RSU shall support both the NTCIP 1202 v03A SPaT message and the Traffic Signal Controller Broadcast Message (TSCBM). The TSCBM is defined in the V2I Hub Interface Control Document. | ||||
| 6. Roadside Units (RSUs) | 6.2 Applications Contained on the RSU | 6.2.2 | The RSU shall pre-process Basic Safety Messages (BSMs) to provide statistics to the TMS or back-office system. | ||||
| 6. Roadside Units (RSUs) | 6.2 Applications Contained on the RSU | 6.2.3 | The RSU shall store MAP (intersection geometry) messages for periodic broadcast over the V2X interface. | ||||
| 6. Roadside Units (RSUs) | 6.3 RSU Configuration and Management | 6.3.1 | The RSU shall conform to NTCIP 1218 v01 enabling configuration and management of the RSU. | ||||
| 6. Roadside Units (RSUs) | 6.3 RSU Configuration and Management | 6.3.2 | The RSU shall not permit configurations that result in an inoperable state through on-board consistency and integrity checks. | ||||
| 6. Roadside Units (RSUs) | 6.3 RSU Configuration and Management | 6.3.3 | The RSU shall perform health and status monitoring functions per NTCIP 1218 v01, enabling monitoring of the RSU. | ||||
| 6. Roadside Units (RSUs) | 6.3 RSU Configuration and Management | 6.3.4 | The RSU shall provide visual status indications including operating status and power status discernable from the ground when mounted up to 30 feet above ground. | ||||
| 6. Roadside Units (RSUs) | 6.4 V2X and Back-office Interfaces and Communications | 6.4.1 | The RSU shall have an IP-based communication interface with a back-office or traffic management system, enabling RSU monitoring, configuration of all parameters, and for data exchange between these systems and the RSU. | ||||
| 6. Roadside Units (RSUs) | 6.4 V2X and Back-office Interfaces and Communications | 6.4.2 | The RSU interface shall include methods to ensure only authorized personnel and systems are provided with access. | ||||
| 6. Roadside Units (RSUs) | 6.4 V2X and Back-office Interfaces and Communications | 6.4.3 | The RSU shall implement 3GPP PC5 Mode 4, Release 14 or 15 for C-V2X communications. | ||||
| 6. Roadside Units (RSUs) | 6.4 V2X and Back-office Interfaces and Communications | 6.4.4 | The RSU shall support the networking and transport protocols defined in IEEE Std 1609.3 – 2020 for data exchange with OBUs and Mobile Units. | ||||
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.1 | The RSU shall apply authentication services to outgoing messages to the OBU or Mobile Unit. | ||||
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.2 | The RSU shall apply authentication checks to incoming messages from OBUs and Mobile Units. | ||||
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.3 | The RSU shall be able to apply authentication services on message in both directions that authenticate that the sender has permission to send the message being sent. | ||||
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.4 | The RSU shall have on-board capability to protect data integrity. |
Integrity is defined as protecting the data at rest and in transit and is not corrupted or used in any way not intended. The interface shall verify or assist in ensuring that the data an RSU transmits is the same as the data the RSU receives.
6. Roadside Units (RSUs) 6.5 Security 6.5.5 The RSU shall have on-board capability to protect data confidentiality.
Confidentiality is defined as the protection from unauthorized access.
6. Roadside Units (RSUs) 6.5 Security 6.5.6 The RSU shall be provided with a secure local/back office interface for connection to location field devices and the back office, providing confidentiality.
Confidentiality is defined as the protection from unauthorized access.
6. Roadside Units (RSUs) 6.5 Security 6.5.7 The RSU shall be provided with a secure local/back office interface for connection to location field devices and the back office, providing integrity.
Integrity is defined as protecting the data at rest and in transit and is not corrupted or used in any way not intended. The interface shall verify or assist in ensuring that the data an RSU transmits is the same as the data the RSU receives.
6. Roadside Units (RSUs) 6.5 Security 6.5.8 The RSU shall be provided with a secure local/back office interface for connection to location field devices and the back office, providing authenticity.
Authenticity is defined as assurance that at the time the RSU first connects to other devices, parties or entities on the network, it can be demonstrated to have connected to the intended entity.
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.9 | The RSU shall maintain data availability to authorized users and processes in accordance with NTCIP 1218 v01. |
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.10 | The RSU shall provide tamper-evidence mechanisms to identify whether the enclosure has been physically tampered with, enabling, from visual inspection alone, to assess if unauthorized access was attempted or completed. |
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.11 | The RSU shall provide physical protection from unauthorized access to sensitive information (i.e. private keys) stored on its security modules. Any tamper evident mechanisms on the security module shall include means for resetting the tamper status. |
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.12 | The RSU shall have assurance of connectivity to and access by the correct network. |
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.13 | The RSU shall be enrolled with a Secure Credential Management System (SCMS) provider. |
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.14 | The RSU shall have the ability to be configured for SCMS interaction, including configuration of which applications the RSU requests certificates for and when the RSU will request new certificates. |
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.15 | The RSU shall connect to an SCMS to request and download new application certificates. |
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.16 | The RSU shall securely store the enrollment certification, application certificates, and trust chain files protecting them from unauthorized modification and substitution. |
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.17 | The RSU shall securely store the private keys associated with enrollment and application certificates protecting them from unauthorized use. |
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.18 | The RSU shall download all relevant Certificate Revocation Lists (CRLs)from the SCMS to enable the RSU to authenticate signed messages from other devices. |
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.19 | The RSU shall download other files associated with the SCMS and certificate operations including the local certificate chain file (LCCF). |
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.20 | The RSU shall provide for an OBU or Mobile Unit to connect to an SCMS. |
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.21 | The RSU shall securely store all credentials. |
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.22 | The RSU shall support logging operations for security purposes. |
| 6. Roadside Units (RSUs) | 6.5 Security | 6.5.23 | The RSU shall provide updates to software/firmware in a secure manner. |
| 6. Roadside Units (RSUs) | 6.6 Minimum Technical Specifications | 6.6.1 | CPU: 800 MHz |
| 6. Roadside Units (RSUs) | 6.6 Minimum Technical Specifications | 6.6.2 | RAM: 2 GB DDR3 SDRAM |
| 6. Roadside Units (RSUs) | 6.6 Minimum Technical Specifications | 6.6.3 | Flash: 4 GB eMMc |
| 6. Roadside Units (RSUs) | 6.6 Minimum Technical Specifications | 6.6.4 | Ethernet: 10/100/1000 Mbps Ethernet PoE |
| 6. Roadside Units (RSUs) | 6.6 Minimum Technical Specifications | 6.6.5 | External I/OGPIO |
| 6. Roadside Units (RSUs) | 6.6 Minimum Technical Specifications | 6.6.6 | Power Supply: 802.3at (passive Poe) surge and reverse polarity protected |
| 6. Roadside Units (RSUs) | 6.6 Minimum Technical Specifications | 6.6.7 | Backup Power: 10 second Store and Shutdown |
| 6. Roadside Units (RSUs) | 6.6 Minimum Technical Specifications | 6.6.8 | Positioning: Advanced GNSS |
| 6. Roadside Units (RSUs) | 6.6 Minimum Technical Specifications | 6.6.9 | Cellular 5G/LTE |
| 6. Roadside Units (RSUs) | 6.6 Minimum Technical Specifications | 6.6.10 | V2X Radio: 3GPP r14/r15 PC5 |
| 6. Roadside Units (RSUs) | 6.6 Minimum Technical Specifications | 6.6.11 | Security technologies to ensure the safety and integrity of V2X communications and embedded systems shall include: |
| - | Hardware Security Module (e-HSM) | |||
| - | ECDSA verification and encryption | |||
| - | NIST and Brainpool verification, encryption | |||
| - | Secure boot, encrypted storage, tamper-proof system | |||
| - | EAL6+ certified and available with up to 1MB of secure SOLID FLASH | |||
| - | ARM TrustZone including the TZ architecture | |||
| 6. Roadside Units (RSUs) | 6.6 Minimum Technical Specifications | 6.6.12 | Operating temperature range: -40°C to +65°C | |
| 6. Roadside Units (RSUs) | 6.6 Minimum Technical Specifications | 6.6.13 | SPaT Processing Requirements: |
| - | The RSU shall encode (UPER), sign, and broadcast SPaT messages upon receiving SPaT information in NTCIP 102 v03A format from a traffic signal controller. | |||
| - | The RSU shall encode (UPER), sign, and broadcast SPaT messages upon receiving SPaT information in TSCBM format from a traffic signal controller. | |||
| 6. Roadside Units (RSUs) | 6.6 Minimum Technical Specifications | 6.6.14 | BSM Processing Requirements: |
| - | The RSU shall forward the first BSM received from each vehicle traveling into a specific zone. | |||
| - | Zones are defined geographically and based on heading, with a minimum of 4 zones per RSU. | |||
| - | BSMs are forwarded if the zone criteria are met, supporting a range of applications as well as RF coverage performance. | |||
| 7. Onboard Unit (OBU) | 7.1 Minimum Technical Specifications | 7.1.1 | CPU: 800 MHz | |
| 7. Onboard Unit (OBU) | 7.1 Minimum Technical Specifications | 7.1.2 | RAM: 2 GB DDR3 SDRAM | |
| 7. Onboard Unit (OBU) | 7.1 Minimum Technical Specifications | 7.1.3 | Flash: 4 GB eMMc | |
| 7. Onboard Unit (OBU) | 7.1 Minimum Technical Specifications | 7.1.4 | Ethernet: 10/100/1000 Mbps Ethernet PoE | |
| 7. Onboard Unit (OBU) | 7.1 Minimum Technical Specifications | 7.1.5 | External I/OGPIO |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .