RFP_Exhibit_2_Compliance_Matrix.xlsx
XLSX spreadsheet 61 KB Posted
- Solicitation number
- RFP 2026-0911
- Issued by
- Adams County, Asotin County, Benton County, Chelan County, Clallam County, Clark County, Columbia County, Cowlitz County, Douglas County, Ferry County, Franklin County, Garfield County, Grant County, Grays Harbor County, Island County, Jefferson County, King County, Kitsap County, Kittitas County, Klickitat County, Lewis County, Lincoln County, Mason County, Okanogan County, Pacific County, Pend Oreille County, Pierce County, San Juan County, Skagit County, Skamania County, Snohomish County, Spokane County, Stevens County, Thurston County, Wahkiakum County, Walla Walla County, Whatcom County, Whitman County, Yakima County, Asotin City, Clarkston City, Clarkston Heights-Vineland CDP, West Clarkston-Highland CDP, Benton City, Chelan City, Chelan Falls CDP, Clallam Bay CDP, Lewisville CDP, Rock Island City, Pacific Beach CDP, Whidbey Island Station CDP, Mercer Island City, Pacific City, Bainbridge Island City, Kingston CDP, Kitsap Lake CDP, Kittitas City, Klickitat CDP, Okanogan City, Anderson Island CDP, Fort Lewis CDP, Fox Island CDP, Herron Island CDP, Ketron Island CDP, North Fort Lewis CDP, Raft Island CDP, Stevenson City, Hat Island CDP, Lake Stevens City, Snohomish City, Spokane City, Spokane Valley City, Puget Island CDP, Garfield Town, Yakima City, Washington
About this file
This is a Compliance Matrix document prepared by WSDOT (Washington State Department of Transportation) that outlines the technical and operational requirements for the Roadway Toll Systems Modernization Programs. The matrix establishes compliance criteria for two independent contracts to be awarded through a single RFP: an Open Road Tolling (ORT) RTS contract and a Side-Fire RTS contract. Each contract will be evaluated separately, with WSDOT retaining the flexibility to award future toll facilities to either or both contractors based on project scope and state needs. The document serves as a structured evaluation tool to ensure bidder proposals meet specified technical standards, operational capabilities, and system performance requirements across multiple functional areas including toll collection technology, interoperability, customer service platforms, and back-office operations.
The compliance matrix functions as a reference document for bidders to understand mandatory and desired system capabilities, allowing proposers to demonstrate alignment with WSDOT's technical specifications and operational expectations. Rather than establishing pricing terms or financial requirements, the matrix focuses on technical compliance metrics, performance standards, and system functionality benchmarks that bidders must address in their proposals. This tool enables standardized evaluation across all submissions and ensures that both the ORT and Side-Fire RTS contracts will operate with consistent quality standards and technical compatibility requirements, while maintaining the independence of each contract award decision.
View the file
Other files
Show all 26
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
Directions
| EXHIBIT 2: COMPLIANCE MATRIX |
| Request for Proposals |
| RFP-2026-0911 |
| Washington State |
| Roadway Toll Systems Modernization Programs |
| Offered by Washington State Department of Transportation |
| Compliance Matrix |
| All capitalized terms used in this Exhibit 2, but not expressly defined herein, have the respective meanings set forth in Appendix 1 of the RFP. |
| A compliance matrix table is attached and explained below. As part of the submitted proposal, the Bidder shall complete sections 5, 6 and 7 of this table to indicate: |
| (1) whether the proposed solution complies with the Toll Technical Requirements of Appendix 4 of this Request for Proposals (RFP), and |
| (2) whether the proposed solution’s functionality either (a) requires some degree of additional development to meet the requirements of the RFP or (b) does NOT require any additional development to meet the requirements of the RFP. |
| Do not make changes to sections 1 through 4. |
| (1) Section Number |
| This section contains the section and subsection number reference. Do not change anything in this section. |
| (2) Section Title |
| This section contains the section titles for each section and subsection. Do not change anything in this section. |
| (3) Requirement Number |
| This section contains the Requirement Number for each requirement. Do not change anything in this section. |
| (4) Requirement |
| This section contains the Requirement details. Do not change anything in this section. |
| (5) Compliance |
| In the Compliance section (5), the Bidder shall mark an “X” in the “Yes” column for each line item if the Bidder’s proposed solution meets every element of the requirements of that section/subsection as written in its entirety without any modifications, limitations, or exclusions. In the same section, the Bidder shall mark an “X” in the “No” column for each line item if the Bidder’s proposed solution does not meet every element of the requirements of that section as written in its entirety without any modifications, limitations, or exclusions. |
| If the Bidder places an “X” in the “No” column in the Compliance section (5), the Bidder shall identify in section (7) “Bidder Comment” the specific requirements in that section/subsection which the Bidder does not fully meet and how they propose to specifically mitigate for not meeting a requirement of this RFP. |
| (6) Development |
| In the Development section (6), the Bidder shall mark an “X” in the “Development Required” column if the Bidder’s proposed solution requires development or additional configuration to meet every element of the requirements of that section as written in its entirety. In the same section, the Bidder shall mark an “X” in the “No Development Required” column if the Bidder’s proposed solution does NOT require development to meet every element of the requirements of that section as written in its entirety. For these purposes, development shall mean the addition of functionality to an already operating Toll System solution to meet the requirements of this RFP. |
| For any requirement marked with a “Development Required”, the Bidder shall provide an explanation and expected duration of development Work, in months, in section (7) “Bidder Comment” or as a separate attachment if additional space is needed. |
| (7) Bidder Comment |
| Bidder shall provide comments in this section as instructed herein. |
| Bidder responses to this compliance matrix shall in no way obligate WSDOT to accept any changes or conditions to the requirements presented in this RFP. |
Page &P of &N RFP-2026-0911 Exhibit 2– Compliance Matrix
4.3 RTS Technical Requirements
| 4.3 | RTS Technical Requirements | |||||||
| (1) | (2) | (3) | (4) | (5) | (6) | (7) | ||
| Section Number | Section Title | Requirement Number | Requirement | Compliance | Development | Bidder Comment | ||
| Yes | No | Development Required | No Development Required | |||||
| 4.3.1 | General | |||||||
| 4.3.1 | General | RTS_4.1 | The design of the Work shall be completed and documented in English units of measure. | |||||
| RTS_4.2 | User interfaces and reports shall display time in local Pacific Standard Time with standard AM/PM format, and be automatically adjusted for Daylight Saving Time, unless otherwise directed by WSDOT. | |||||||
| RTS_4.3 | The RTS and all peripheral systems shall receive time synchronization from the RMH or from GPS/GNSS devices installed at the toll sites. Local GPS/GNSS devices shall demonstrate time synchronization with the RMH time source. | |||||||
| 4.3.2 | System Architecture | |||||||
| 4.3.2 | System Architecture | RTS_4.4 | The RTS shall operate where no single equipment failure will result in complete loss of revenue collection. For any locations where adequate power is not available for complete redundancy, the Vendor shall coordinate with WSDOT to identify and prioritize redundant equipment. | |||||
| RTS_4.5 | The System architecture shall meet or exceed the current security policies and standards. For more information, see Section 4.3.6 herein and also refer to security policies and standards found in WaTech Policies Chapter 4 and Appendix 9 Information and Security. | |||||||
| RTS_4.6 | WSDOT’s preference is that the RTS shall use no more than one overhead gantry per toll collection point (single gantry solution). | |||||||
| 4.3.3 | Roadway Toll System | |||||||
| 4.3.3.1 | Description | |||||||
| 4.3.3.1 | Description | RTS_4.7 | The RTS design shall be modular, allowing for expedited removal and replacement during maintenance. | |||||
| RTS_4.8 | All components that perform the same function shall be interchangeable. | |||||||
| RTS_4.9 | All software and firmware that performs the same function shall be the same version within each RTS facility. | |||||||
| RTS_4.10 | Any changes to Software and firmware in one or many components shall be implemented in all similar Hardware within 90 Calendar Days. | |||||||
| RTS_4.11 | The RTS shall detect, classify, and identify vehicles and capture images in environmental and lighting conditions within each Project area. | |||||||
| RTS_4.12 | To discourage birds from nesting, installed components of the RTS shall include a commercially available bird-exclusion solution, when applicable, that does not interfere with the RTS or the traveling public. | |||||||
| RTS_4.13 | Enclosures installed by the Vendor shall have at least 25 percent expansion capacity to accommodate added boards, components, equipment, and software for future expansion. | |||||||
| 4.3.3.2 | Zone Controller | |||||||
| 4.3.3.2.1 | General | RTS_4.14 | The Zone Controller and its peripheral systems shall be capable of full toll operations locally without connection to the RMH. | |||||
| RTS_4.15 | Under normal conditions, the Zone Controller and its peripheral systems shall be fully automated and perform all toll operations activities without manual intervention. | |||||||
| RTS_4.16 | Design redundancies of the Zone Controller and its peripheral systems shall be fully automated to failover without manual intervention. | |||||||
| RTS_4.17 | The Zone Controller shall verify with the RMH upon startup that it has the latest configuration files, application Software, and any other files required to support lane operations. | |||||||
| RTS_4.18 | The Zone Controller shall record to a log file the verification result of data referenced in RTS_4.17. | |||||||
| RTS_4.19 | The Zone Controller shall detect failure/problems with itself and its peripheral systems and report alarms and recovery messages to the Maintenance Online Management System (MOMS). | |||||||
| 4.3.3.2.2 | Data Storage | RTS_4.20 | The Zone Controller shall record and retain all data transmitted from its peripheral systems, including all transactional data, images, and maintenance data, for a period of at least 30 Calendar Days. Refer to each facility Statement of Work (SOW) for traffic volume details. | |||||
| RTS_4.21 | The Zone Controller shall provide the ability to electronically transfer Toll Transaction and maintenance data to portable electronic media for delivery to the RMH in the event of a communication loss. | |||||||
| 4.3.3.2.3 | Communications | RTS_4.22 | Upon reestablishment of communications between the RMH and Zone Controller, the Zone Controller shall transmit all buffered data to the RMH in the order it was received. | |||||
| RTS_4.23 | The RTS shall utilize an error-checking protocol to ensure accurate data transmission between the Zone Controller and the RMH. | |||||||
| RTS_4.24 | The RTS shall be able to manage communications from each roadway individually, providing control to prioritize data transmissions in the event of an issue at a toll point, or multiple toll points. | |||||||
| 4.3.3.3 | Vehicle Detection | |||||||
| 4.3.3.3 | Vehicle Detection | RTS_4.25 | The Vehicle Detection subsystem shall measure the speed of all vehicles traveling from 5 miles per hour (mph) up to and including 100 mph to within ±5 mph. | |||||
| RTS_4.26 | The Vehicle Detection subsystem shall be capable of creating a distinct separation between vehicles spaced as close as 2 feet apart, from head to tail. | |||||||
| RTS_4.27 | The Vehicle Detection subsystem shall correctly discriminate in which lane a vehicle is traveling. | |||||||
| RTS_4.28 | The Vehicle Detection subsystem shall correctly correlate the vehicle and Toll Transaction data to the toll lane in which the vehicle is traveling. | |||||||
| 4.3.3.4 | Vehicle Classification | |||||||
| 4.3.3.4 | Vehicle Classification | RTS_4.29 | The Automatic Vehicle Classification (AVC) subsystem shall count the number of axles on each vehicle and perform axle-based classification. | |||||
| RTS_4.30 | The AVC subsystem shall correctly distinguish between individual vehicles and vehicles towing one or more trailers. | |||||||
| RTS_4.31 | The AVC subsystem shall accommodate vehicle classes as defined in Section 4.1 of the latest approved version of the WSDOT Lane Side Business Rules. | |||||||
| 4.3.3.5 | Vehicle Identification | |||||||
| 4.3.3.5 | Vehicle Identification | RTS_4.32 | The Automatic Vehicle Identification (AVI) subsystem shall have the ability to read Super eGo® (SeGo), E-ZPass TDM, and ISO 18000 6C Transponder protocols. It shall read SeGo and 6C concurrently. | |||||
| RTS_4.33 | The AVI subsystem shall assign priority for Transponders when multiple Transponders are read in a single transaction in accordance with the order shown in Section 7.10.1.5 of the WSDOT Lane Side Business Rules. | |||||||
| RTS_4.34 | The AVI subsystem shall detect and read properly installed Transponders on vehicles in the travel lanes and shoulders, and on vehicles straddling two lanes or a lane and adjacent shoulder. | |||||||
| RTS_4.35 | The AVI subsystem shall detect and read properly installed Transponders on closely following and side-by-side vehicles. | |||||||
| RTS_4.36 | The AVI subsystem shall authenticate all 6C Transponders programmed according to Version 2.0 or later of the 6C Coalition AVI Standard. | |||||||
| RTS_4.37 | Authentication will be completed according to the Unique Item Identifier (UII) authentication (Hash Value) section of the standard. | |||||||
| RTS_4.38 | For Transponders programmed with Version 4.0 or later, the UII Validation (cyclic redundancy check (CRC)) will also be performed and reported. | |||||||
| RTS_4.39 | All fields necessary for these calculations (UII, Track Item Data [TID], Hash/CRC expected values, Hash/CRC calculated values, etc.) shall be stored in the RMH and made available through dedicated reports. | |||||||
| RTS_4.40 | The RTS shall prevent Transponder reads from being assigned incorrectly to leading or trailing vehicles (tailgating). | |||||||
| RTS_4.41 | The RTS shall prevent an AVI reader in a lane from assigning to that lane the Transponder of a vehicle traveling in an adjacent lane. | |||||||
| 4.3.3.6 | License Plate Image Capture | |||||||
| 4.3.3.6.1 | General | RTS_4.42 | The License Plate Image Capture (LPIC) subsystem shall comply with Revised Code of Washington 46.63.160 7(a), which limits photo enforced images to the vehicle and vehicle license plate only (for more information refer to http://apps.leg.wa.gov/rcw/default.aspx?cite=46.63.160). | |||||
| RTS_4.43 | The LPIC subsystem shall capture front and rear images of the vehicle region of interest for all vehicles that pass through the Toll Zone, regardless of whether they are in one lane, straddling two lanes, straddling the buffer (if any), or driving on the shoulder. WSDOT prefers color images although black and white images may be used. | |||||||
| RTS_4.44 | The LPIC subsystem shall capture human-readable license plate images. A license plate image shall be human readable if a human can manually review the license plate image and clearly identify features such as license plate characteristics (e.g., plate numbers, plate type, and plate jurisdiction) and vehicle characteristics. A license plate image of a bent or obstructed license plate shall be human readable if a human can manually review the image and clearly identify that the plate is bent or obstructed. | |||||||
| RTS_4.45 | All images that contain any portion of the license plate shall be stored in accordance with Section 4.3.4.8.4 herein for retrieval if necessary. | |||||||
| RTS_4.46 | The Image File naming convention for Image Files included as part of Trip information sent to the BOS shall meet the latest approved Roadside Interface Control Document (ICD) guidelines and requirements. | |||||||
| RTS_4.47 | Image storage and transmission shall meet the latest approved Roadside ICD guidelines and requirements. | |||||||
| 4.3.3.6.2 | Supplemental Lighting | RTS_4.48 | Supplemental lighting for vehicle LPIC, or any other device, shall not distract, startle, or otherwise impair or interfere with motorists driving in either direction of traffic. | |||||
| RTS_4.49 | Supplemental lighting shall result in minimal additional light reaching the surrounding environment. | |||||||
| 4.3.3.7 | Enforcement Beacon (for Express Toll Lane Facilities Only) | |||||||
| 4.3.3.7 | Enforcement Beacon (for Express Toll Lane Facilities Only) | RTS_4.50 | The Zone Controller shall activate the enforcement beacon based on user-configurable parameters including Transponder type and status to be determined during System design. | |||||
| RTS_4.51 | Successive activations of the enforcement beacon for closely spaced successive vehicles traveling at the posted speed limit shall be visibly discernible to the naked eye. | |||||||
| RTS_4.52 | The enforcement beacon shall become inactive during any period when tolls are not required to be collected. | |||||||
| RTS_4.53 | The enforcement beacon shall include a viewing angle of 10 to 25 degrees as measured from the beacon, with a minimum viewing distance to the end of the nearest downstream enforcement area. | |||||||
| RTS_4.54 | The location of the enforcement beacon shall be on Express Toll Lanes (ETLs) only and will be determined by WSDOT during the Preliminary Design Phase of the Work. | |||||||
| RTS_4.55 | The single color of the enforcement beacon will be determined by WSDOT during the Detailed Design Phase of the Work. | |||||||
| RTS_4.56 | A single enforcement beacon shall be installed for each associated travel lane. | |||||||
| 4.3.4 | Roadside Management Host | |||||||
| 4.3.4.1 | General | |||||||
| 4.3.4.1 | General | RTS_4.57 | The RMH shall receive all Toll Transaction data, images, and other associated data from each Zone Controller on all systems. | |||||
| RTS_4.58 | The RMH shall transmit all Trips, Toll Transaction data, images, and other associated data to the WSDOT BOS as defined within the latest approved Roadside ICD. | |||||||
| RTS_4.59 | The RMH shall immediately receive the full Transponder Validation List (TVL) data file when it is available from the WSDOT BOS as defined in the latest approved Roadside ICD, which will occur at least once a day. | |||||||
| RTS_4.60 | The RMH shall immediately receive incremental updates to the TVL data file when it is available from the WSDOT BOS as defined in the latest approved Roadside ICD, which will occur at 15-minute intervals. | |||||||
| RTS_4.61 | The RMH shall process the TVL data file from the BOS within 15 minutes of receipt at the RMH for use by the RTS. | |||||||
| RTS_4.62 | If the RMH fails to process a full or incremental TVL data file, the RMH shall generate a MOMS ticket and continue using the most recently processed TVL data file. | |||||||
| RTS_4.63 | The RMH shall store data to non-volatile memory upon receipt or generation to minimize the loss of data in the event of a power failure or other RMH failure. | |||||||
| RTS_4.64 | In the event of data loss at the RMH due to Product failure, the RMH shall have the ability to retrieve the lost data from the Zone Controller. | |||||||
| RTS_4.65 | The RMH shall be monitored by separate Software or Hardware (e.g., a watchdog) that will notify maintenance staff when the RMH or supporting services lock up, reboot, fail, or lose network connectivity. | |||||||
| RTS_4.66 | The RMH data storage and processing capacity shall be evaluated during the design phases and shall be increased as required to accommodate additional facility transactional volumes as provided by WSDOT in the respective facility SOW. | |||||||
| 4.3.4.2 | Time Synchronization | |||||||
| 4.3.4.2 | Time Synchronization | RTS_4.67 | The RMH shall automatically adjust the date and time to conform to local Daylight Saving Time. | |||||
| RTS_4.68 | The RMH shall synchronize the date and time by US Naval Time, or another WSDOT-approved time source, at least once every 30 minutes. | |||||||
| 4.3.4.3 | User Interfaces | |||||||
| 4.3.4.3.1 | General | RTS_4.69 | The Graphical User Interface (GUI) shall be a hierarchical, menu-driven system. | |||||
| RTS_4.70 | Access to functions and features shall be limited to Authorized Users based on user accounts, roles, and permissions developed by WSDOT and the Vendor during the System design phase. | |||||||
| RTS_4.71 | All interfaces shall display time in local Pacific Standard Time with standard AM/PM format, and be automatically adjusted for Daylight Saving Time. | |||||||
| RTS_4.72 | Any user interface in the Software shall not require elevated System privileges on the user’s workstation. | |||||||
| RTS_4.73 | User interfaces shall be web-based, graphical in nature, and compatible with WSDOT-deployed operating system and internet browser utilized at the time of submission of the draft System Design Document. | |||||||
| 4.3.4.3.2 | RHM Functionality | RTS_4.74 | The RMH shall provide an interface facilitating the update and download of modified, updated, or new vehicle classification and toll rate tables. | |||||
| RTS_4.75 | The RMH shall provide a web-based interface for Authorized WSDOT Users remotely accessing the RMH. | |||||||
| RTS_4.76 | The RMH shall provide a user display and interface for the monitoring of each roadway facility and the lane activities and Products installed at each Toll Zone. | |||||||
| RTS_4.77 | The RMH shall present data and information in a graphical manner. | |||||||
| RTS_4.78 | The RMH shall display the status of all lane Products and related communications. | |||||||
| RTS_4.79 | The RMH shall display the last image captured for each camera. | |||||||
| RTS_4.80 | The RMH shall display the status of all computer Hardware and related communications using a WSDOT-approved color scheme. | |||||||
| RTS_4.81 | The RMH shall display the AVI usage rate for all reader locations as they occur and over user-defined time intervals. | |||||||
| RTS_4.82 | The RMH GUI shall allow Authorized Users to view, modify, add, and remove a wide range of database settings, configurations, and parameters. | |||||||
| RTS_4.83 | At a minimum, the GUI shall provide the following: |
| • | Users and user groups – Create and modify users and user information and assign users to a user group; define a user group and its access level to program functions and reports. |
| • | System functions – Define the make-up of the RTS nodes (e.g., Zone Controllers) and computers (workstations). |
| • | Toll classification table – Defines the different vehicle declaration states and classifications, and is user configurable. |
| • | Toll rate table – Defines the toll rates for times, days, declaration states, and classification types and is user configurable. Also includes the GUI for viewing the current posted toll rate, the upcoming (if available) toll rate, historical toll rates, override functionality, and the base copy of toll rate information for updates. |
| • | Toll rate schedule – Defines the enforcement schedule for the toll rate tables with option for variable time of the day configuration to schedule peak/off-peak times and fixed static time of the day schedule, and is user configurable. |
| • | Global configuration – Defines global parameters of the System. |
| RTS_4.84 | The Trip Research/Reporting Tool shall provide a web-based interface for Authorized Users to access time, location, Toll Transaction, and image data associated with each Toll Zone within a Trip. | ||
| RTS_4.85 | The Trip Research/Reporting Tool shall be available 99 percent of the month. | ||
| 4.3.4.3.3 | System Administration | RTS_4.86 | The RMH shall control and manage the RTS administration for all aspects of the RTS. |
| RTS_4.87 | The RMH shall support vehicle classification and toll rate table changes via an effective date that specifies the date and time after which the old tables are no longer used and the new tables go into effect. | ||
| RTS_4.88 | Application restarts shall not cause a loss of Toll Transaction information or loss of log file data. | ||
| 4.3.4.3.4 | System Monitoring | RTS_4.89 | The RMH near real-time status display shall consist of graphics, symbols, text, and/or numerals defined during the design phase. |
| RTS_4.90 | The RMH shall automatically refresh the screen or display to show the latest status, captured image, and Toll Transaction data collected. | ||
| RTS_4.91 | An Authorized User shall have the ability to view near real-time transaction data from any Toll Zone. | ||
| RTS_4.92 | An Authorized User shall have the ability to view near real-time images captured by the LPIC subsystem. | ||
| RTS_4.93 | Each device and subsystem status shall be indicated with color in the GUI (e.g., green – “healthy”; yellow – “degraded” or “ailing”; red – “failed”). | ||
| RTS_4.94 | The display shall indicate communication link status with each device (e.g., graying of the device upon communication loss). | ||
| RTS_4.95 | The RMH shall transmit Trips to the BOS in accordance with business rules defined for the Trip-building process. | ||
| RTS_4.96 | The RMH shall store Photo Toll images in a Secure File Transfer Protocol (SFTP) server that shall be transmitted upon request by the WSDOT BOS according to the Roadside ICD. | ||
| RTS_4.97 | The RMH shall log all anomalies in data transmission via the log files. | ||
| 4.3.4.4 | Transaction Management | ||
| 4.3.4.4.1 | General | RTS_4.98 | The RMH shall include a filter to account for duplicate Toll Transaction and Trip data. |
| 4.3.4.4.2 | Transaction Creation | RTS_4.99 | The System shall create a unique Transaction ID for each and every vehicle passing through the Toll Zone. |
| RTS_4.100 | The System shall assign a unique and sequential Transaction ID to each transaction. | ||
| RTS_4.101 | Transactions shall include all associated data related to each vehicle passing through the Toll Zone. | ||
| RTS_4.102 | The System shall create Trips of type AVI, HOV, or IMG in accordance with the latest approved Business Rules. | ||
| RTS_4.103 | All Toll Transaction data, whether complete or incomplete and regardless of characteristics, shall be recorded and stored for retrieval and/or transmittal to the RMH or other RTS subsystems. | ||
| 4.3.4.4.3 | Trip Building | RTS_4.104 | Based on individual Toll Transactions created at each Toll Zone, the System shall complete the Trip Assembly Process by compiling AVI, image, toll rate, and other Toll Transaction information for each vehicle passing through a Toll Facility. |
| RTS_4.105 | The System shall assign a unique and sequential Trip ID to each Trip. | ||
| RTS_4.106 | Each assembled Trip shall include all associated Toll Transaction data related to each vehicle’s passage through a Toll Facility. | ||
| RTS_4.107 | The Trip Assembly Process shall take into account single Toll Zone transactions constituting a single Trip and multiple Toll Zone transactions constituting a single Trip. | ||
| RTS_4.108 | The System shall have the capability to identify when there is a missing Toll Zone transaction between sequential transactions and to determine whether or not there should be a single Trip assembled or multiple Trips. | ||
| RTS_4.109 | A Trip shall be compiled from all Toll Transactions based on Transponder and/or license plate number whether or not both data points are available for every transaction. | ||
| RTS_4.110 | The System shall contain logic with configurable parameters for discerning Trips including single or multiple transactions. | ||
| 4.3.4.5 | Toll Rate Management | ||
| 4.3.4.5 | Toll Rate Management | RTS_4.111 | The RMH shall record and retain all toll rates and other messages obtained from the TMC in accordance with the Toll Sign Display File ICD for a minimum of 6 months. |
| RTS_4.112 | The RMH shall obtain the Toll Sign Display File from the TMC as an event-driven process, such that all files are validated and processed in near real-time. | ||
| RTS_4.113 | The RMH shall validate contiguous versioning of Toll Sign Display Files and attempt to locate and process missing files. | ||
| RTS_4.114 | The RMH shall not process invalid or incomplete Toll Sign Display Files. | ||
| RTS_4.115 | The RMH shall make repeated attempts to obtain the Toll Sign Display File. If the file is not available within 24 hours, the Trip-building process shall stop and WSDOT shall be contacted for resolution. | ||
| RTS_4.116 | If the RMH fails to process a Toll Sign Display File, the RMH shall generate a MOMS ticket. | ||
| RTS_4.117 | The RMH shall archive all valid Toll Sign Display Files older than 6 months. | ||
| RTS_4.118 | The RMH shall log all communication events between the RMH and TMC and maintain this log for at least the past 30 days. | ||
| RTS_4.119 | The RMH shall generate and transmit an alert when there are communication, validation, and non-contiguous Toll Sign Display Files. | ||
| RTS_4.120 | For ETLs, the System shall assign to each Trip the toll rate or message that was observed by the driver at the time the vehicle passed under the adjacent upstream toll rate sign. This assignment shall be based on both logic within the System and on a user-configurable toll rate assignment time delay. | ||
| RTS_4.121 | For ETL facilities, the System shall assign a $0.00 toll to each Trip for vehicles with the declarable Transponder in HOV mode. | ||
| 4.3.4.6 | System Interfaces | ||
| 4.3.4.6.1 | BOS | RTS_4.122 | The RMH shall interface with the BOS according to the latest approved Roadside ICD. |
| RTS_4.123 | The Vendor shall provide a file server with SFTP access for use in file storage and transfer to the BOS. | ||
| RTS_4.124 | The Vendor shall send a reconciliation report on a periodic basis to the BOS as per the latest approved Roadside ICD. | ||
| RTS_4.125 | The RMH shall meet the compression standards in the latest approved Roadside ICD. | ||
| RTS_4.126 | The RMH shall be able to control the release of trips to the BOS by roadways individually. | ||
| 4.3.4.6.2 | TMC | RTS_4.127 | The RMH shall interface with the TMC according to the Toll Sign Display File ICD. |
| 4.3.4.7 | Reporting | ||
| 4.3.4.7 | Reporting | RTS_4.128 | The System shall provide the capability for users to generate and produce reports based on predefined and ad hoc report criteria. |
| RTS_4.129 | No blackout period shall exist for running reports. | ||
| RTS_4.130 | The System shall allow the user to edit and view the report selection parameters. | ||
| RTS_4.131 | The System shall generate scheduled and ad hoc reports automatically and email and/or save them to a location as defined by the user. | ||
| RTS_4.132 | The ability to support inquiries and the generation of reports shall be available 24 hours per day, seven days per week. | ||
| RTS_4.133 | Reporting shall include daily, weekly, monthly, yearly, day of week, day of year, week of month, and week of year recurrence criteria. The report dataset shall reconcile among reports when rolled up (e.g., daily report shall reconcile with weekly report for the day). | ||
| RTS_4.134 | Reporting shall be output, saved, or printed in the following formats, including but not limited to on-screen, PDF, and comma-separated values (text). | ||
| RTS_4.135 | The System shall have the capability to retrieve data for: |
| • | Any given date/time Toll Transaction | |||
| • | Any given date/time Trip | |||
| • | Any given lane or Toll Zone | |||
| • | Groups of Toll Zones by Roadway/by Roadway direction | |||
| • | Entry/exit location | |||
| • | Any given classification | |||
| • | Trip type | |||
| • | Toll rate sign information | |||
| RTS_4.136 | The System reports shall provide relevant overall information such as column and row totals, percentage splits, and basic statistics (such as minimum, maximum, and average). | |||
| RTS_4.137 | The System shall have the capability to report on power information such as power fluctuations, on/off state changes, UPS battery runtime, generator operation and health, and other anomalies defined during Design. | |||
| RTS_4.138 | The System shall have the capability to report on available network information such as on/off states and bandwidth utilization. | |||
| 4.3.4.7.1 | Defined Reports | RTS_4.139 | The RMH shall generate a range of reports for user-configurable periods of time (at least monthly), of which the content and form shall be submitted to WSDOT during the design phase. The reports shall include but not be limited to: |
| • | Users and user groups | |||
| • | Toll fare schedule and toll rate sign display history | |||
| • | Non-associated and extra Transponder reads | |||
| • | Toll Transactions detail including but not limited to transaction type | |||
| • | Trip assembly detail | |||
| • | Daily reconciliation report | |||
| • | UII Hash Authentication Report | |||
| • | UII Validation (CRC Calculation) Report | |||
| RTS_4.140 | The file transmission report shall show the status of any file sent to the RMH server, to the BOS, and to all of the tolling locations/lanes. Time sent, time of receipt, time of transmission, and the status of the transmission shall be displayed. | |||
| RTS_4.141 | The Optical Character Recognition (OCR) performance report shall display OCR performance statistics, including quantity of images taken, OCR results, and confidence levels. | |||
| RTS_4.142 | Weekly and monthly reports shall be available that show the user access data and modifications made, and the ability shall be provided to obtain the details of the modifications. | |||
| 4.3.4.7.2 | AD HOC Reports | RTS_4.143 | The RMH shall allow users to format and generate ad hoc reports. | |
| RTS_4.144 | The design of ad hoc reporting capability shall protect the RMH from being adversely affected by processing load caused by reporting functions. | |||
| RTS_4.145 | The design of ad hoc reporting capability shall protect the online database from corruption caused by reporting functions. | |||
| RTS_4.146 | Table views shall be provided to simplify ad hoc queries. | |||
| RTS_4.147 | Ad hoc reports shall include the capability for various selection and sort criteria (to be determined during System design phase). | |||
| RTS_4.148 | Ad hoc queries shall be able to be saved by query name for later recall by the RMH. | |||
| RTS_4.149 | Reports generated from ad hoc queries shall save and export in a format that can be opened by Microsoft Excel. | |||
| 4.3.4.8 | System Technology and Application Requirements | |||
| 4.3.4.8 | System Technology and Application Requirements | RTS_4.150 | Data exported from the RMH shall be compatible with the current WSDOT-approved version of Microsoft SQL Reporting Services at the time of submission of the System Design Document. | |
| RTS_4.151 | The RMH shall be a cloud-based, scalable, multizone architectural system and multi-region deployment with geographic redundancy to support the current and future toll traffic volumes (refer to each facility SOW for traffic volume details). | |||
| RTS_4.152 | The RMH system response times shall meet defined service-level agreements for transaction processing and shall provide load balancing across multiple instances to ensure optimal resource utilization and prevent bottlenecks. | |||
| RTS_4.153 | A Relational Database Management System (RDBMS) shall be utilized to store data collected throughout the RMH system. Data tables, such as AVI Transactions, image-based Transactions, RTS events, maintenance events, etc., shall be maintained within the database. | |||
| RTS_4.154 | The RDBMS shall provide the common functionality, elements, and capabilities encountered in commercially available RDBMSs. The latest available version of the proposed RDBMS shall be used. | |||
| RTS_4.155 | The RMH system architecture shall minimize latency between database and application servers and shall support required bandwidth capacity to handle the Transaction workload. | |||
| RTS_4.156 | The RMH system shall support redundant component architecture to eliminate single point of failure. | |||
| RTS_4.157 | The RMH system shall use a distributed, segmented, and secure network design to support cloud-based architecture. The system shall provide end-to-end encryption for data in transit, using industry-standard protocols. | |||
| RTS_4.158 | The RMH system shall provide comprehensive logging, monitoring, and alerting capabilities to enable proactive issue detection and resolution. Real-time dashboards shall be provided to track transaction volumes, error rates, and system health metrics. | |||
| RTS_4.159 | The RMH application shall be GUI based and provide access to data by Authorized Users based on their user privileges. | |||
| RTS_4.160 | The RMH shall provide access to Toll Zone transaction and audit data to Authorized Users. | |||
| RTS_4.161 | RMH data access shall not adversely affect the processing and/or any other function of the RTS. | |||
| RTS_4.162 | The online database(s) shall be protected from corruption due to any user access to the data. | |||
| RTS_4.163 | Any Vendor-provided Ethernet Product to be used in connection with the System network, unless requested for exclusion and approved by WSDOT, shall utilize connectors and cable, rated and capable of connecting at speeds up to 1 Gigabit per second (Gbps). | |||
| 4.3.4.8.1 | Data Protection | RTS_4.164 | The Vendor shall protect all data in accordance with the security policies and standards found in WaTech Policies Chapter 4 and in Appendix 9. | |
| RTS_4.165 | The Vendor shall consider all RTS data classified as Category 3 (see the security policies and standards found in WaTech Policies Chapter 4 and in Appendix 9). The classification category dictates the security level requirements. | |||
| RTS_4.166 | The Vendor shall provide data and anti-malware protection throughout the System, including but not limited to the following environments: |
| • | RTS | ||
| • | RMH | ||
| • | Workstations | ||
| • | External system interfaces | ||
| • | Remote access locations (Vendor controlled) | ||
| • | Internet | ||
| RTS_4.167 | Data and anti-malware protection shall include but not be limited to: |
| • | Password data security at workstation login | ||
| • | Data backup subsystems | ||
| • | Boot record and memory virus scanning | ||
| • | Communication link and data packet virus scanning | ||
| • | Import and export file virus scanning prior to standard file opening and/or transfer | ||
| RTS_4.168 | The Vendor shall, at a minimum, provide the following: |
| • | The latest version of anti-malware protection at the time of System Acceptance | ||||
| • | Update service within 15 Calendar Days of update issuance for the malware dictionary and/or malware scanning Software throughout the warranty, maintenance period, and any optional maintenance periods | ||||
| • | Anti-malware operational procedures | ||||
| 4.3.4.8.2 | Data Transfer | RTS_4.169 | The configuration files, classification tables, etc., shall be transmitted to the applicable system immediately upon update. | ||
| RTS_4.170 | The electronic transfer of data between the RMH and the TMC and BOS shall include a mechanism for ensuring that the data transfer has successfully transmitted the correct data and provide a daily reconciliation report on the information transferred. | ||||
| RTS_4.171 | The RMH shall provide the ability to electronically copy Toll Transactions to a portable electronic media for delivery to the BOS in the event of a communication loss. | ||||
| RTS_4.172 | The RMH shall transfer the required data to the BOS for Toll Transactions and Trips as per the latest approved Roadside ICD. | ||||
| 4.3.4.8.3 | Back-up and Recovery | RTS_4.173 | The RMH shall automatically back up data and support continuous backup with point-in-time recovery capabilities. | ||
| RTS_4.174 | The RMH shall support geographically distributed backup systems with automated testing capabilities, including database restore, verification, and integrity checks. | ||||
| RTS_4.175 | All backup data shall be encrypted as per the industry standard. | ||||
| RTS_4.176 | Based on the WSDOT retention policies, the RMH data shall be archived using tiered, cost-optimized storage across multiple cloud regions. | ||||
| RTS_4.177 | The RMH shall include automated failover mechanisms with configurable recovery time objectives and recovery point objectives. | ||||
| RTS_4.178 | The Vendor shall provide a cloud-based Disaster Recovery system with a warm standby configuration to support the operations. | ||||
| RTS_4.179 | The Vendor shall provide Disaster Recovery procedures with documented recovery point objectives and recovery time objectives based on the proposed Disaster Recovery architecture. | ||||
| RTS_4.180 | The Vendor shall provide a Disaster Recovery Plan and perform regular yearly Disaster Recovery testing to support RMH operations. The Disaster Recovery Plan must be reviewed and updated yearly as part of the continuous improvement cycle. | ||||
| RTS_4.181 | The Vendor shall provide backup, archive, and restore procedures for the proposed RMH system. The procedures shall be reviewed and updated yearly as part of the continuous improvement cycle of the Disaster Recovery Plan. Refer to Appendix 3, Design, Installation, and Testing. | ||||
| 4.3.4.8.4 | Data Retention | RTS_4.182 | Image Files shall be retained on the file server for at least 90 Calendar Days as per the latest approved Roadside ICD. | ||
| RTS_4.183 | The RMH shall retain all Toll Transaction data online for a period of 365 Calendar Days. | ||||
| RTS_4.184 | The Digital Video Audit System (DVAS) shall retain data for 90 Calendar Days. | ||||
| RTS_4.185 | The System shall retain raw event data in accordance with the latest WSDOT-approved version of the data retention and destruction policy. | ||||
| RTS_4.186 | The RMH shall retain offline Toll Transaction data and images for a period of 365 Calendar Days. | ||||
| RTS_4.187 | The RMH shall retain offline summarized daily traffic data for a period of five years. | ||||
| RTS_4.188 | The RMH shall provide confirmation of successful data archival before deletion. | ||||
| 4.3.4.9 | Optical Character Recognition | ||||
| 4.3.4.9 | Optical Character Recognition | RTS_4.189 | The OCR subsystem shall process all vehicle images through one or multiple OCR engines. | ||
| RTS_4.190 | Regardless of how many license plate images are captured of a vehicle, the OCR subsystem shall determine the plate jurisdiction of issue, plate type, and plate characters for each license plate image. | ||||
| RTS_4.191 | The OCR subsystem may create a composite OCR value based on multiple images and vehicle and plate analysis. | ||||
| RTS_4.192 | The OCR subsystem shall assign a confidence rating to each OCR result for each of the following three elements: plate characters, plate type, and plate jurisdiction. | ||||
| RTS_4.193 | The RMH shall include an OCR plate filter and allow modification of the plate filter list. Plates on the filter list shall be assigned a low OCR confidence to be directed to Manual Image Review. | ||||
| RTS_4.194 | A composite OCR value shall include a confidence rating and meet all other applicable OCR requirements. | ||||
| RTS_4.195 | The OCR subsystem shall append the determined OCR value for the plate with the highest confidence to the Toll Transaction when the OCR values for the front and rear plate of a 2-axle vehicle do not match. | ||||
| RTS_4.196 | The OCR subsystem shall append the determined OCR value for the front plate to the Toll Transaction when the OCR values for the front and rear plate of a 3-axle vehicle or larger do not match. | ||||
| 4.3.4.10 | Maintenance Online Management System | ||||
| 4.3.4.10.1 | General | RTS_4.197 | During the Vendor-provided Operations and Maintenance period, the MOMS shall be the primary application for all System maintenance activities, including preventive maintenance, emergency maintenance, real-time monitoring, repair calls, and report generation. | ||
| RTS_4.198 | In the event a third-party MOMS is provided, reports required to support maintenance reporting shall be consolidated by the Vendor. | ||||
| RTS_4.199 | The MOMS shall utilize a GUI that allows Authorized Users to perform view, update, and query functions. | ||||
| RTS_4.200 | The MOMS shall monitor and control Product failures within the System in near real-time. | ||||
| RTS_4.201 | The Vendor shall provide a list of all monitored components of the System and last known status. | ||||
| RTS_4.202 | The Vendor shall provide a list of all monitored processes and services of the System. | ||||
| RTS_4.203 | The Vendor shall define and develop ticket escalation parameters during the design phase of the Project. | ||||
| RTS_4.204 | At a minimum, the MOMS shall provide the following information to its users: |
| • | Current System status (level defined by user) | |||
| • | Current Toll Zone operation status (System health for each Toll Zone) | |||
| • | Current toll component status | |||
| • | Failure and/or malfunction location/time | |||
| • | Failure and/or malfunction description (including both initial Priority Level and current Priority Level, if applicable) | |||
| • | Failure and/or malfunction duration (running time or overall if resolved) | |||
| • | Spare parts inventory identification information and current status | |||
| • | Part/Product description (including part/serial number), if applicable | |||
| • | Record of last maintenance activity for a Product entered by maintenance staff | |||
| • | Record of last preventive maintenance activity for a Product as entered by maintenance staff | |||
| • | Historical System information/report generation | |||
| • | Technician schedule | |||
| RTS_4.205 | The MOMS shall be monitored by separate Products (e.g., a watchdog) that will notify maintenance staff when MOMS or supporting services lock up, reboot, fail, or lose network connectivity. | |||
| 4.3.4.10.2 | Remote Operations | RTS_4.206 | Access to the MOMS shall not impact the flow of data between the Zone Controller and the RMH. | |
| RTS_4.207 | The MOMS shall prevent unauthorized users from gaining access to the MOMS. | |||
| RTS_4.208 | Each user shall be assigned a personal username and password for logging into MOMS. | |||
| 4.3.4.10.3 | System Monitoring | RTS_4.209 | The MOMS shall determine the operational status of each device at user configurable intervals, down to a minimum threshold of every 30 seconds. | |
| RTS_4.210 | The MOMS shall monitor each device to detect and record that the device has failed, changed state, is intermittent, is in recovery, or is degrading in its performance level. | |||
| RTS_4.211 | The System shall flag each Toll Transaction that occurs when the AVI, AVC, Vehicle Detection, and/or LPIC subsystems are less than fully functional, as described in RTS_4.210. | |||
| RTS_4.212 | The System shall continuously monitor the quantity of images taken, quantity of OCR results, and confidence levels. | |||
| RTS_4.213 | The MOMS shall include a filter to locate and flag duplicate MOMS data. | |||
| RTS_4.214 | The MOMS shall have the ability to generate Work Orders with no human intervention. | |||
| RTS_4.215 | The MOMS shall have the ability to generate, at a minimum, two different types of manual Work Orders: |
| • | Ad hoc | ||
| • | Preventive maintenance | ||
| RTS_4.216 | The Work Order shall record the source of the Work Order, either as automatically triggered by MOMS monitoring, or the person reporting the failure (Vendor maintenance technician, WSDOT staff member, or both). | ||
| RTS_4.217 | The MOMS shall support the generation of ad hoc Work Orders for unusual occurrences of maintenance activities as requested by WSDOT. | ||
| RTS_4.218 | A Work Order shall include but not be limited to the following required information: |
| • | Date/time of Work Order generation | ||
| • | Date/time of Work Order closure | ||
| • | Date/time/location of repair or maintenance call | ||
| • | Work Order number (sequential) | ||
| • | Work Order priority | ||
| • | Work Order status | ||
| • | Work Order assignment details | ||
| • | Failure or malfunction description | ||
| • | Repair/diagnosis details | ||
| • | Usage of spare parts | ||
| RTS_4.219 | All Work Orders shall create a unique, sequential number. | ||
| RTS_4.220 | The MOMS shall provide a search feature that allows users to search for Work Orders either through the use of or in combination with text entry, pull-down menus, and data range entry by: |
| • | Date/time of Work Order generation | |||
| • | Date/time/location of repair or maintenance call | |||
| • | Date/time of Work Order completion | |||
| • | Work Order number (including Wildcard operators) | |||
| • | Work Order priority | |||
| • | Work Order status | |||
| • | Work Order assignment details | |||
| • | Repair/diagnosis details | |||
| • | Usage of spare parts | |||
| • | Failure or malfunction description | |||
| RTS_4.221 | The MOMS shall provide a drill-down feature, where it begins with a listing of Work Orders by category, to be agreed upon by WSDOT in the system development phase, and the ability to drill down to the detail level for individual Work Orders. | |||
| RTS_4.222 | The MOMS shall monitor the TMC interface for successful receipt and acknowledgement of the Toll Sign Display File. | |||
| RTS_4.223 | The MOMS shall track and provide reporting for functional availability, Mean Time To Respond (MTTRespond), and Mean Time To Repair (MTTRepair). | |||
| 4.3.4.10.4 | Notification | RTS_4.224 | The MOMS shall provide an automatic ticket generator for automated notification of maintenance issues. | |
| RTS_4.225 | The MOMS shall allow for automatic notification of technicians once a Work Order has been generated. | |||
| RTS_4.226 | The MOMS shall allow users to set parameters for all error notifications, status changes, and escalation rules. | |||
| RTS_4.227 | The MOMS shall allow for user-configured thresholds that automatically notify technicians of changes in the quantity of images taken, quantity of OCR results, and confidence levels of the OCR. | |||
| RTS_4.228 | The MOMS shall provide the capability to notify technicians, at a minimum, through use of SMS text and email. | |||
| RTS_4.229 | Email-based notifications shall include a unique and descriptive subject line related to the failure or malfunction and location (e.g., Zone Controller A failed in Zone #1, Lane #1). | |||
| RTS_4.230 | The System shall notify maintenance technicians when summary data as monitored and defined in requirement RTS_211 deviates from historical rolling previous three-month averages during the same 30-minute time period according to user-configurable parameters. | |||
| RTS_4.231 | The preventive maintenance schedule shall be integrated with the MOMS to generate automatic Work Orders at scheduled times. | |||
| RTS_4.232 | The MOMS shall create a ticket when a full TVL file is not received within a user-configurable period. | |||
| 4.3.4.10.5 | Spare Parts Management | RTS_4.233 | The MOMS shall provide an integrated spare unit and spare parts inventory control function. | |
| RTS_4.234 | The MOMS shall integrate inventory control with the Work Order generation function, which shall automatically update and maintain the spare parts inventory based on Work Orders and technicians recording of parts used during Work Order close-out. | |||
| RTS_4.235 | The MOMS shall create automatic notifications when new parts are required due to changes in inventory, established by user-configurable thresholds. | |||
| RTS_4.236 | Spare parts required information includes any parts entered into inventory and shall include details such as but not limited to: |
| • | Original Equipment Manufacturer (OEM) serial number | |||
| • | WSDOT-specific serial number, if any | |||
| • | Purchase date | |||
| • | Expiration date (if applicable) | |||
| • | Time and date part entered into inventory | |||
| • | Warranty information | |||
| • | Current status | |||
| • | Current location of the spare part | |||
| • | Time and date part was removed from inventory | |||
| • | Any relevant tracking/shipping information | |||
| • | Asset tag number | |||
| • | Assigned facility | |||
| • | Replenish threshold quantity | |||
| 4.3.4.10.6 | Availability Tracking | RTS_4.237 | Availability calculations shall consider the following subsystems: |
| • | LPIC | |||
| • | Vehicle Classification | |||
| • | Vehicle Detection | |||
| • | AVI | |||
| • | OCR | |||
| RTS_4.238 | A subsystem shall be considered available when (a) that subsystem is collecting, processing, and recording data, and (b) when the Software or Hardware solution referenced in requirement RTS_ 4.237 notifies the System at a configurable frequency that the associated services are running. | |||
| RTS_4.239 | If one of the five subsystems listed in requirement RTS_ 4.237 is unavailable, the entire RTS shall be considered unavailable. | |||
| RTS_4.240 | Every unavailable incident (outage) during each month shall be tracked by the MOMS and reported. | |||
| RTS_4.241 | The MOMS availability calculations shall be performed automatically whenever the availability report is run as defined in Contract A Exhibit J and Contract B Exhibit E. | |||
| 4.3.4.10.7 | Mean Time to Respond and Mean Time to Repair | RTS_4.242 | The MTTRespond and MTTRepair calculations shall be performed automatically whenever the MTTRespond/Repair report is run. | |
| RTS_4.243 | The MOMS shall denote all deductions to MTTRespond and MTTRepair individually. | |||
| 4.3.4.10.8 | Reporting | RTS_4.244 | The MOMS shall generate operational, management, and performance reports, of which the content and form shall be submitted to WSDOT for approval, including but not limited to: |
| • | Summarized and detailed component failure history | |||
| • | Maintenance paging and response history | |||
| • | Work Order status and tracking | |||
| • | Availability and/or device status monitoring for devices, subsystems, and systems | |||
| • | Preventive maintenance | |||
| • | Emergency maintenance | |||
| • | Response and repair times | |||
| • | Product inventory and tracking | |||
| • | Product use history | |||
| • | Product repair history | |||
| • | Product versions, Software versions, firmware versions, and serial numbers for all Product installed under the Contract | |||
| RTS_4.245 | The availability report shall take into account the number of installed Toll Zone lanes on a Toll Facility and the length of outages affecting the particular Toll Zone lane function. | |||
| RTS_4.246 | The availability report shall be provided for user-configurable periods of time. | |||
| 4.3.4.11 | Digital Video Audit System | |||
| 4.3.4.11.1 | General | RTS_4.247 | The Vendor shall provide one or more cameras mounted at each Tolling Point to provide a continuous video feed of the traffic passing through the Toll Zone. | |
| RTS_4.248 | The Toll Transaction details taking place in the Toll Zone shall be viewable in synchronization with the video image so as to enable the viewer to associate vehicles with Toll Transaction data and judge the overall apparent health of the RTS. | |||
| RTS_4.249 | The viewable data shall include all Toll Transaction data captured for each vehicle passing through the Toll Zone. |
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 .