5-05. VENDOR RESPONSE SHEET.V2X Mgt System.final.docx
DOCX document 51 KB Posted
- Solicitation number
- UDOT250259MP-1
- Issued by
- Utah
About this file
This is a Vendor Response Sheet for a Vehicle-to-Everything (V2X) Maintenance and Management System Request for Proposal (RFP) issued by the Utah Department of Transportation (UDOT). The solicitation seeks to develop, implement, and maintain a V2X system to support UDOT's Connected Vehicle Ecosystem. The contract is anticipated to be a single award with a 5-year initial term and an option for 5 additional years. Vendors must submit a comprehensive technical proposal addressing mandatory requirements and scored technical categories, including system architecture, data processing, hardware asset management, traffic event monitoring, and traveler information message creation. The evaluation process will assess vendor responses across five main categories: technical requirements (49%), system hosting and support (17%), additional scope and features (3%), system demonstration (13%), and cost (17%), with a total of 860 possible points.
The vendor selection will be based on a detailed scoring rubric, with points awarded from 0-5 for each technical requirement, weighted by a factor to determine total points. Vendors must achieve at least 360 points (60%) in the technical scoring areas to be invited to a virtual system demonstration. Mandatory qualifications include experience developing cloud-based V2X management systems, contractual relationships with public agencies, and expertise in data displays, dashboards, and data sharing platforms. The RFP encourages vendors to provide innovative ideas and optional features beyond the specified requirements, with the opportunity to propose additional scope that UDOT may select at its discretion.
View the file
Other files
Show all 12
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
VENDOR RESPONSE SHEET
UTAH DEPARTMENT OF TRANSPORTATION (UDOT)
VEHICLE-TO-EVERYTHING (V2X) MAINTENANCE AND MANAGEMENT SYSTEM
Instructions Mandatory Requirements The selected vendor and their system must meet the requirements listed as “Mandatory” in the Stage 1 table below. Compliance documentation or narrative must be offered in the cell beneath each requirement. If a vendor cannot meet the mandatory requirement to UDOT’s satisfaction based on the responses provided, they will be deemed non-responsive and ineligible for further consideration.
Technical Proposal Requirements and Evaluation The vendor must indicate their capabilities to meet each technical requirement listed in Stage 2: Technical Response Categories A, B, and C tables, below. An indication of the vendor’s ability to satisfy these requirements must be inserted in the “Explanation” cell beneath each requirement. Brief explanations about how the system will do so may also be offered. Scoring of each item will be based on these explanations. If a vendor needs additional development effort to meet specific requirements, they must indicate the time needed beyond a Notice to Proceed (NTP)to meet that requirement in the “Explanation” cell.
Technical Proposals will be scored based on the vendor responses to each of the sections in the “Vendor Response Sheet”, as described herein. Total possible scores for each of the Categories indicated are shown in the table below along with their proportion of the total number of points possible.
Vendors who achieve at least a 60% score (360 points) in the technical scoring areas (Categories A, B, and C in the table below) will be invited to demonstrate their system in a virtual meeting.
Category
| Percent of Total Points |
| Points Possible |
| A |
| Ability to meet project requirements (Sections 2 through 7 on the Vendor Response Sheet) |
| 49% |
| 425 |
| B |
| System Hosting, Installation, and Support (Section 8 on the Vendor Response Sheet) |
| 17% |
| 150 |
| C |
| Additional Scope and Features (Section 9 on the Vendor Response Sheet) |
| 3% |
| 25 |
| System Demonstration |
| 13% |
| 110 |
| Cost |
| 17% |
| 150 |
| TOTAL POINTS POSSIBLE |
| 100% |
| 860 |
Each technical requirement will be given a score, by the evaluators, between 0 and 5, based on the following rubric:
(a) Five (5) points (Excellent): The proposal addresses and exceeds the requirements or criteria for that feature;
(b) Four (4) points (Good): The proposal addresses the requirements or criteria for that feature and, in some respects, exceeds them;
(c) Three (3) points (Satisfactory): The proposal addresses the requirements or criteria for that feature in a minimum satisfactory manner;
(d) Two (2) points (Unsatisfactory): The proposal addresses the requirements or criteria for that feature in a partial or less than complete way;
(e) One (1) point (Poor): The proposal inadequately addresses the requirements or criteria for that feature or provides incomplete information; or
(f) Zero (0) points (Fail): The proposal fails to address the requirements or criteria for that feature or indicates it will not provide the feature.
(g) One (1) point will be deducted from the score assigned in the above rubric for any feature that will be provided more than 90 days after NTP, with zero (0) being the lowest score possible.
A weighting factor is shown next to each evaluation item in the “Weighting Factor” column. The total score given to each item will be multiplied by this weighting factor to result in the total awarded points for that item.
The vendor may offer additional scope or features beyond what is defined herein in the section labelled “Additional Scope and Features”.
General system descriptions that provide useful background may be attached in the section labelled “General System Information”, with a five-page limit. An additional, optional, document may be added containing graphics and diagrams (no text except captions) to support the responses and explanations provided for the Category A, B, and C requirements, below. It is limited to 15 pages.
Vendor Name
Stage 1: Mandatory Vendor Qualifications (Pass/Fail)
| Item |
| Type |
| Requirement Description |
| Evaluation |
| 1.1 |
| Mandatory |
| Experience developing and deploying a cloud-based V2X Management System supporting deployments of over 50 RSUs. |
| Pass/Fail |
Compliance Documentation:
| 1.2 |
| Mandatory |
| Contractual relationship with at least one public agency with the vendor’s V2X Management System in use for at least one year. Provide a reference in the “Compliance Documentation” section, below. |
Pass/Fail
Compliance Documentation:
| 1.3 |
| Mandatory |
| Experience developing data displays and dashboards for various V2X data elements and hardware assets. |
| Pass/Fail |
Compliance Documentation:
| 1.4 |
| Mandatory |
| Experience operating V2X data sharing platforms or systems, including APIs with other systems. |
| Pass/Fail |
Compliance Documentation:
Stage 2: Technical Response:
Category A: Ability to meet project requirements System and Network Architecture (95 Points Possible)
| Item |
| Type |
| Requirement Description |
| Weighting Factor |
| 2.1 |
| Scored |
| Ability for the cloud-based system to provide scalable, secure, and redundant infrastructure to support V2X data processing and analytics. |
| 2 |
Explanation:
| 2.2 |
| Scored |
| Ability for System to be available 24/7 with uptime of 99.9% or higher. Vendor must supply evidence of this level of availability in currently deployed systems. |
| 2 |
Explanation:
| 2.3 |
| Scored |
| Ability for System to provide an interactive, user-friendly, dashboard with a refresh rate less than 15 minutes that displays the information, facilitates the analysis, and provides the functionality described in the requirements below. |
| 3 |
Explanation:
| 2.4 |
| Scored |
| Ability for System to provide network connectivity through a private, direct point-to-point circuit for security, speed, and scalability. |
| 1 |
Explanation:
| 2.5 |
| Scored |
| Ability for System to provide network redundancy and automatic failover in case of network degradation or outage. |
| 0.5 |
Explanation:
| 2.6 |
| Scored |
| Ability for System design to support hardware interoperability and cross-vendor compatibility. |
| 1 |
Explanation:
| 2.7 |
| Scored |
| Ability for System to support standardized V2X protocols to ensure interoperability and standards compliance. |
| 1.5 |
Explanation:
| 2.8 |
| Scored |
| Ability for System to Support external APIs for integration or data exchange with other systems, especially the UDOT ARCH ATMS system |
| 2 |
Explanation:
| 2.9 |
| Scored |
| Ability for System to Support integration with external data feeds such as RWIS, Work Zone Data Exchange, and transit agency GTFS feeds. |
| 1 |
Explanation:
| 2.10 |
| Scored |
| Ability for System to Push TIM messages created by this system to the Situational Data Exchange (SDX) REST API in the format required by that system. |
| 1 |
Explanation:
| 2.11 |
| Scored |
| Ability for System to Push roadway event data created by this system or obtained from the UDOT ARCH ATMS system to the Situational Data Exchange (SDX) API in the format required by that system. |
| 1 |
Explanation:
| 2.12 |
| Scored |
| Ability for System to allow role-based access to different levels of system management, hardware management, data, and analysis (e.g. administrator, standard, read-only users) |
| 2 |
Explanation:
| 2.13 |
| Scored |
| Ability for System to allow jurisdiction-based access to different levels of management, data, and analysis, such as only to the devices and data owned by that agency. |
| 1 |
Explanation:
Data storage, processing, manipulation, analysis and sharing (100 Points Possible)
| Item |
| Type |
| Requirement Description |
| Weighting Factor |
| 3.1 |
| Scored |
| Ability for System to ingest and store J2735-2020 or newer SPaT, MAP, BSM, SRM, and SSM messages in a centrally accessed database |
| 2 |
Explanation:
| 3.2 |
| Scored |
| Ability for System to ingest and store J3224 SDSM messages in a centrally accessed database. |
| 0.5 |
Explanation:
| 3.3 |
| Scored |
| Ability for System to ingest and store over one billion V2X messages each day |
| 1 |
Explanation:
| 3.4 |
| Scored |
| Ability for System to store messages for at least six months after ingestion and use that data to populate dashboards and displays to report trends, warnings, and analytics |
| 1 |
Explanation:
| 3.5 |
| Scored |
| Ability for System to provide a ‘cold storage’ solution for storage of messages older than six months. Describe the ability and mechanism for user access and downloading of this data, including conversion of the data into CSV or another commonly used format. |
| 1 |
Explanation:
| 3.6 |
| Scored |
| Ability for System to deduplicate repetitive BSM, MAP, and SRM messages before processing events to reduce the total data processing and storage needs |
| 2 |
Explanation:
| 3.7 |
| Scored |
| Ability for System to create system-generated summaries using logged messages so that end users do not need to aggregate and sort data manually |
| 1 |
Explanation:
| 3.8 |
| Scored |
| Ability for System to display the number of messages ingested by location, by message type, and by day, in tabular form and in graphical form |
| 1 |
Explanation:
| 3.9 |
| Scored |
| Ability for System to display specific BSM data elements ingested by day, in tabular form and in graphical form |
| 1 |
Explanation:
| 3.10 |
| Scored |
| Ability for System to filter and report data by date and time, intersection ID, and type of vehicle requesting priority or preemption. |
| 1 |
Explanation:
| 3.11 |
| Scored |
| Ability for System to display SRM data received at a selected intersection filtered or sorted by the vehicle identifier (SRM data is not anonymous) to support the analysis of TSP effectiveness. |
| 1 |
| 3.12 |
| Scored |
| Ability for System to display information from the SDSM messages, including number of messages ingested by day, number of vehicles detected, ratio of vehicles detected vs. vehicles classified, average distance to vehicle classified, number of Vulnerable Road Users (VRUs) detected (pedestrians, bicyclists, etc.), number of zone-based warnings generated, and number of near-misses identified. (SDSM messages will be created by the RSU from data generated by the LiDAR system.) |
| 0.5 |
Explanation:
| 3.13 |
| Scored |
| Ability for System to provide a user interface for managing MAP data, allowing users to create, edit, and refine intersection MAPs and the association of lanes with SPaT signal groups. |
| 0.5 |
Explanation:
Explanation:
| 3.14 |
| Scored |
| Ability for System to retain historical MAP data for sites designated as intersections, including timestamps and user IDs for MAP modifications for change logging, ensuring MAPs can be restored if needed. |
| 0.5 |
Explanation:
| 3.15 |
| Scored |
| Ability for System to store MAP data in a structured format, per the J2735 standard, to allow MAPs to be viewed, and to view MAP message information superimposed on an aerial image of the intersection. |
| 1 |
Explanation:
| 3.16 |
| Scored |
| Ability for System to view the lane numbering scheme used in the MAP message as a feature that can be toggled on or off over the graphic MAP message. |
| 0.5 |
Explanation:
Explanation:
Explanation:
| 3.17 |
| Scored |
| Ability for System to facilitate user-run queries on raw data using scripts or other tools |
| 1.5 |
Explanation:
| 3.18 |
| Scored |
| Ability for System to allow users to download blocks of data for analysis |
| 2 |
Explanation:
| 3.19 |
| Scored |
| Ability for System to allow an outside entity, with an appropriate password-protected account, to manipulate, analyze, and download data |
| 1 |
Explanation:
Manage V2X roadside and vehicle hardware assets (60 Points Possible)
| Item |
| Type |
| Requirement Description |
| Weighting Factor |
| 4.1 |
| Scored |
| Ability for System to ‘enroll’ roadside hardware assets into the system, manually or imported from an offline list, including RSUs, signal controllers, fiber switches, SCMs, and LiDAR units. Ability to store at least the following attributes for each asset: location (intersecting streets, and/or mile marker), site ID, location type (intersection, non-intersection roadside), jurisdiction owner (the agency that owns the device), device type, make, model, serial number, firmware / OS version, installation date, and network information (including IP addresses and other relevant details). |
| 2 |
Explanation:
| 4.2 |
| Scored |
| Ability for System to create custom fields for monitored devices. Describe the process whereby a custom field would be created. It is not necessary that the custom field be created dynamically by individual users; it could be created by an administrator or the Vendor. |
| 0.5 |
Explanation:
| 4.3 |
| Scored |
| Ability for System to query devices to obtain serial number information, where supported by the device. |
| 0.5 |
| 4.4 |
| Scored |
| Ability for System to display the hardware asset information in list format, sortable by location, site ID, device type, make, model, installation date, and jurisdiction owner. |
| 2 |
Explanation:
| 4.5 |
| Scored |
| Ability for System to display hardware locations on a geographic map overlay. |
| 2 |
Explanation:
| 4.6 |
| Scored |
| Ability for System to allow selection of a location from the deployment map to see a list of devices deployed at that location, including location information, jurisdiction, device attributes, and device status |
| 1 |
Explanation:
| 4.7 |
| Scored |
| Ability for System to ‘enroll’ vehicle-based V2X hardware asset information into the system, manually or imported from an offline list, including OBUs and OBPs and display that information. Ability to store at least the following attributes of each asset: OBU serial number, OBP serial number, installation date, and information about the vehicle the device is installed in, including vehicle Fleet ID, owner information, VIN, make, model, year, plate, vehicle ID, and whether the vehicle is allowed to request signal priority or preemption. |
| 1.5 |
Explanation:
| 4.8 |
| Scored |
| Ability for System to download the list of hardware assets (roadside and vehicle-based), including sortable subsets of that list, in multiple formats (CSV, JSON, XML). |
| 1.5 |
Explanation:
Explanation:
| 4.11 |
| Scored |
| Ability for System to allow appropriate users to configure which devices are permitted to operate within the system through role-based access. |
| 1 |
Explanation:
Monitor health and performance of roadside hardware assets and system operations (85 Points Possible)
| Item |
| Type |
| Requirement Description |
| Weighting Factor |
| 5.1 |
| Scored |
| Ability for System to support Simple Network Management Protocol (SNMP) versions 1, 2c, and 3 monitoring protocols for devices |
| 1 |
Explanation:
| 5.2 |
| Scored |
| Ability for System to support Internet Control Message Protocol (ICMP) monitoring protocol for devices, including PING, SNMP, and SSH. |
| 0.5 |
Explanation:
| 5.3 |
| Scored |
| Ability for System to query OIDs listed in standard, non-enterprise SNMP MIBs |
| 0.5 |
Explanation:
| 5.4 |
| Scored |
| Ability for System to query OIDs for USDOT 4.1 MIBs if an RSU does not support NTCIP 1218 |
| 1 |
Explanation:
| 5.5 |
| Scored |
| Ability for System to provide network ping response check (reachable, response time) for all ‘pingable’ network devices |
| 1 |
Explanation:
| 5.6 |
| Scored |
| Ability for System to query history logs of ping failures, degraded messages, and other failure alerts for each device and location and produce periodic summaries (daily, weekly, monthly) for each alert type. |
| 0.5 |
| 5.7 |
| Scored |
| Ability for System to provide Secure Shell (SSH) device check (confirm authenticate, run commands) and support SSH as a terminal-level monitoring and interaction protocol for devices. |
| 1 |
Explanation:
| 5.8 |
| Scored |
| Ability for System to report status of individual hardware assets and record instances of degraded performance (when a device is not performing as designed or a message is malformed or incomplete), including no response, SNMP failure, MAP not available, SPaT not available, MAP data degraded (missing key data), SPaT data degraded, and certificate missing. |
| 1 |
Explanation:
| 5.9 |
| Scored |
| Ability for System to report the initial time and duration of each degraded performance issue. |
| 1 |
Explanation:
| 5.10 |
| Scored |
| Ability for System to provide in-browser reports of degraded performance in both tabular and graphic formats and selectable from a map of locations. |
| 1 |
Explanation:
| 5.11 |
| Scored |
| Ability for System to report the number of each type of degraded performance on a given date. |
| 1 |
Explanation:
| 5.12 |
| Scored |
| Ability for System to monitor and report CPU utilization levels, memory utilization percentages, and availability of local storage space on applicable devices. |
| 0.5 |
Explanation:
| 5.13 |
| Scored |
| Ability for System to monitor the broadcast of SDSM messages (at locations where LiDAR is operating) and report on the health of those systems, such as when SDSM broadcasts cease. |
| 0.5 |
Explanation:
| 5.14 |
| Scored |
| Ability for System to query and report device uptime. |
| 0.5 |
| 5.15 |
| Scored |
| Ability for System to support automated reboot of monitored devices, specifically Cisco and Fortinet PoE switches, using an applicable protocol or device |
| 2 |
Explanation:
| 5.16 |
| Scored |
| Ability for System to query logs of start and stop times of specific store-and-repeat J2735 messages, like TIMs, and report when message broadcast is started and stopped |
| 0.5 |
Explanation:
| 5.17 |
| Scored |
| Ability for System to monitor self-reported transmission rates for J2735 messages (specifically SPaT and MAP) broadcast by the RSU and generate alerts if transmission rates fall outside of thresholds over a 10-second period. |
| 0.5 |
Explanation:
| 5.18 |
| Scored |
| Ability for System to produce alerts (by email or text) to report when degraded performance exceeds a defined threshold. Describe which of these thresholds can be determined or changed by the system user. |
| 0.5 |
Explanation:
| 5.19 |
| Scored |
| Ability for System to support schedulable reports for specific metrics for specified time periods. |
| 0.5 |
Explanation:
| 5.20 |
| Scored |
| Ability for System to monitor SPaT and MAP messages to verify that all required data elements specified by J2735 and CTI 4501 are included; generate alerts when required fields are missing. |
| 0.5 |
Explanation:
| 5.21 |
| Scored |
| Ability for System to obtain security certificate status through an API with the SCMS system and report security certificate status in this dashboard, including last update and time-to-expiration. |
| 0.5 |
Explanation:
| 5.22 |
| Scored |
| Ability for System to process SPaT and MAP messages to detect conflicting signal states between signal groups reported in those messages and generate alerts if conflicts are identified. |
| 0.5 |
| 5.23 |
| Scored |
| Ability for System to track minimum and maximum phase end times in SPaT messages and generate an alert when invalid time changes occur. Comment on the data processing implications of this requirement and the potential use of user-defined alerting thresholds to minimize the number of alerts. |
| 0.5 |
Explanation:
View Traffic Events (45 Points Possible)
| Item |
| Type |
| Requirement Description |
| Weighting Factor |
| 6.1 |
| Scored |
| Ability for System to collect raw BSM data, process in real time, and report road events, including hard braking, hazard light activation, air bag deployment, and temperature |
| 2 |
Explanation:
| 6.2 |
| Scored |
| Ability for System to display events retrieved from BSM data in tabular, graphical, and map formats. |
| 2 |
Explanation:
| 6.3 |
| Scored |
| Ability for System to collect and report information from UDOT Road Weather Information Stations (RWIS), including temperature, precipitation, icy road, and wind speed and display information in tabular, graphical and map formats. |
| 0.5 |
Explanation:
Explanation:
| 6.5 |
| Scored |
| Ability for System to continuously evaluate irregular vehicle movements at intersections in near-real time by comparing BSM data to allowed movements reported by SPaT and MAP messages to identify possible errors in SPaT and MAP messages. (This function is documented in the Connected Intersection Message Monitoring System (CIMMS) developed by the Connected Vehicle Pooled Fund Study; open-source code is available.) |
| 1.5 |
Explanation:
| 6.6 |
| Scored |
| Ability for System to report irregular vehicle movements, and to send alerts, by location, date and time, and movement type (vehicle in wrong direction lane, vehicle crosses stop bar on red, vehicle comes to a complete stop when traversal of the intersection was allowed, and vehicle enters improper egress lane) (These functions are documented in CIMMS) |
| 1 |
Explanation:
| 6.7 |
| Scored |
| Ability for System to report irregularities between SPaT and MAP messages, including conflicting signal states and improper minEndTime and maxEndTime behavior. |
| 1 |
Explanation:
| 6.8 |
| Scored |
| Ability for System to playback activities at an intersection for a selected time and date, including showing signal phase changes, associated lane linkages, vehicle movements, and signal priority and preemption traversals. Animation should be superimposed over the MAP message imagery. The playback can be limited to a short time period, e.g., 5 or 10 minutes. |
| 1 |
Explanation:
Create Traveler Information Messages (TIMs) (40 Points Possible)
| Item |
| Type |
| Requirement Description |
| Weighting Factor |
| 7.1 |
| Scored |
| Ability for System to create Curve Speed Warning TIM message based on user input (through the user-interface) about curve location and recommended speed. Conform to the protocol for this message developed in the Connecting the West Program. |
| 2 |
Explanation:
| 7.2 |
| Scored |
| Ability for System to automatically generate Spot Weather Impact Warning TIM messages for high wind, rain, snow, and icy road conditions based on data retrieved from vehicle BSM and UDOT RWIS stations. Conform to the protocol for these messages developed in the Connecting the West Program. |
| 1 |
Explanation:
| 7.3 |
| Scored |
| Ability for System to automatically generate Variable Speed Limit (VSL) TIM message based on data retrieved from UDOT’s VSL system. Conform to the protocol for this message developed in the Connecting the West Program. |
| 1 |
Explanation:
| 7.4 |
| Scored |
| Ability for System to create Disabled Vehicle Warning TIM message based on hazard light activation data retrieved from vehicle BSMs. |
| 0.5 |
Explanation:
| 7.5 |
| Scored |
| Ability for System to create Stationary Emergency Vehicle Ahead Warning TIM message based on detected emergency vehicles with emergency lights activated data retrieved from vehicle BSMs or other sources. |
| 0.5 |
Explanation:
| 7.6 |
| Scored |
| Ability for System to create Work Zone Warning TIM message based on data retrieved from UDOT’s Work Zone Data Exchange feed or the Situational Data Exchange (SDX), some of which will be generated in Wyoming and Colorado. Conform to the protocol for this message developed in the Connecting the West Program. Describe the role of the user in creating or approving these messages. |
| 1 |
Explanation:
| 7.7 |
| Scored |
| Ability for System to create TIM messages for Road Closed, Road Closed – Local Traffic Only, Lane Blocked Ahead, Lane Closed Ahead, Shoulder Closed Ahead, and Road Construction Ahead based on event data retrieved from the UDOT ATMS system or the SDX. Conform to the protocol for these messages developed in the Connecting the West Program. Describe the role of the user in creating or approving these messages. |
| 1.5 |
Explanation:
| 7.8 |
| Scored |
| Ability for System to generate TIM messages warning motorists of chain law requirements on specific corridors due to inclement weather based on data from the UDOT ATMS system. Describe the role of the user in creating or approving this message. |
| 0.5 |
Explanation:
Category B: System Hosting, Installation, and Support (150 Points Possible)
| Item |
| Type |
| Requirement Description |
| Weighting Factor |
| 8.1 |
| Scored |
| Vendor shall describe the proposed scheme for hosting the system and data: where the system will be hosted (Vendor cloud or UDOT’s GCP instance), whether there will be other secondary cloud, on-premises, or edge systems, how those systems will work together, how the data will be managed to minimize cloud costs, how the growth of data will be managed, etc. |
Note that no costs shall be presented here; those are to be shown only in the Vendor Pricing Sheet.
Explanation:
| 8.2 |
| Scored |
| Vendor shall describe the process used, and constraints of, the installation and integration of the system, including a projected timeframe to have the system functioning |
| 3 |
Explanation:
| 8.3 |
| Scored |
| Vendor shall list the staff that will be dedicated to installing and supporting their proposed system, along with a brief summary of the staff’s qualifications. Subcontractor staff shall be included and indicated as such. |
| 3 |
Explanation:
| 8.4 |
| Scored |
| Vendor shall describe the documentation that will be provided to UDOT to support system use. |
| 2 |
Explanation:
Category C: Additional Scope and Features (25 Points Possible)
| Item |
| Type |
| Requirement Description |
| Weighting Factor |
| 9.1 |
| Scored |
| Vendor shall describe additional scope and features which can be provided that are not listed above. UDOT will have the option to select any of these features at its discretion. |
| 5 |
Explanation:
General System Information (Informational, Not Scored) Vendor may attach general system descriptions and information, that may provide background for UDOT’s review of the proposed system, with a five-page limit.
Vendor Response Sheet Page 2 of 2
File details come from the government source that posted it. Updated .