Appendix 4_Toll Technical Requirements.pdf

APPENDIX 4: Toll Technical Requirements

Request for Proposals

RFP-2026-0911

Washington State

Roadway Toll Systems

Modernization Programs

Offered by

Washington State Department of

Transportation

Roadway Toll Systems Project Appendix 4. Toll Technical Requirements

4-i State of Washington Contract No. ___ Department of Transportation

Table of Contents

APPENDIX 4. TOLL TECHNICAL REQUIREMENTS ....................................................................... 4-1

4.1 Introduction ............................................................................................................................. 4-1

4.1.1 DOCUMENT OVERVIEW ................................................................................................................... 4-1

4.1.2 DOCUMENT SCOPE .......................................................................................................................... 4-1

4.1.3 ABBREVIATIONS AND DEFINITIONS ............................................................................................... 4-1

4.1.4 NAMING CONVENTIONS ................................................................................................................... 4-1

4.2 System Overview .................................................................................................................... 4-1

4.3 RTS Technical Requirements ................................................................................................ 4-2

4.3.1 GENERAL ........................................................................................................................................... 4-2

4.3.2 SYSTEM ARCHITECTURE ................................................................................................................. 4-2

4.3.3 ROADWAY TOLL SYSTEM ................................................................................................................ 4-2

4.3.4 ROADSIDE MANAGEMENT HOST .................................................................................................... 4-6

4.3.5 COMMUNICATION ........................................................................................................................... 4-22

4.3.6 SECURITY REQUIREMENTS .......................................................................................................... 4-25

4.3.7 PERFORMANCE REQUIREMENTS ................................................................................................. 4-27

4-1 State of Washington Contract No. ___ Department of Transportation

APPENDIX 4. TOLL TECHNICAL REQUIREMENTS

4.1 Introduction

4.1.1 DOCUMENT OVERVIEW

This Appendix is divided into three major sections. Section 4.1 herein explains the scope of the Appendix as a whole. Section 4.2 herein provides an overview of the Roadway Toll Systems (RTS) and the

Roadside Management Host (RMH). Section 4.3 herein describes the technical requirements in detail for the RTS, RMH, and Side-Fire Tolling (SFT) Proof of Concept.

4.1.2 DOCUMENT SCOPE

The requirements set forth herein describe the RTS and RMH that WSDOT intends to procure for the

RTS Contract. These toll technical requirements will be used as a baseline from which the Vendor will develop a more detailed System Design Document and System Requirements Compliance Matrix.

In addition to compliance with all technical requirements for the RTS Contract, specific requirements for the SFT Contract are presented to extend the solution baseline and the Vendor’s System Design

Document and System Requirements Compliance Matrix.

4.1.3 ABBREVIATIONS AND DEFINITIONS

All capitalized terms and abbreviations used in this Appendix, but not expressly defined herein, shall have the meanings set forth in Appendix 1, Definitions, attached to the Request for Proposals.

Appendix 6 lists mandatory manuals and/or publications that the Vendor shall use for the design and installation of the Work. These Mandatory Standards are a list of publications that shall be used for all design and installation. If the Vendor becomes aware of any ambiguities or conflicts relating in any way to the Mandatory Standards and the Contract requirements, the Vendor shall notify WSDOT immediately in writing so WSDOT may review and provide direction to resolve them.

The Vendor shall use the mandatory manuals and/or publications that are current as of the latest effective date of the applicable facility change order.

Updates to the mandatory manuals and/or publications during the time of the Contract that will affect the design criteria or installation requirements shall be handled per the Contract. The provided list of standards is not exhaustive; the Vendor is responsible for identifying and complying with all applicable standards, Laws, and Regulations necessary to perform the Work.

4.1.4 NAMING CONVENTIONS

Toll technical requirements are individually labeled with a unique requirement number. For example, the label “4.1” refers to the first toll technical requirement for the RTS in Section 4 (i.e., this Appendix).

4.2 System Overview

The RTS described herein provides a means for WSDOT to collect tolls in various configurations via radio frequency identification (RFID) and image capture technologies at the roadside. The RTS will include all

4-2 State of Washington Contract No. ___ Department of Transportation

Toll Point Hardware and Software necessary to satisfy the functional and performance requirements for roadside tolling. The RMH will include a host platform and Software to support operations, administration, and maintenance of the tolling facilities. The RMH will not include customer service, customer account maintenance, or similar functionality. The System collectively describes all RTS and RMH Hardware and

Software.

The overall RTS concept for this Project shall consist of several key elements, including the Roadway Toll

Equipment and integration with the RMH supporting external interfaces to the WSDOT Traffic

Management Center (TMC) and WSDOT Back Office System (BOS).

4.3 RTS Technical Requirements

In general, all technical requirements included herein are applicable to both RTS and SFT. Technical requirements that may not be applicable to some SFT proposed configurations are noted in RTS subsystem items below.

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

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

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.

https://watech.wa.gov/policies

4-3 State of Washington Contract No. ___ Department of Transportation

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-4 State of Washington Contract No. ___ Department of Transportation

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

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

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

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.

4-5 State of Washington Contract No. ___ Department of Transportation

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.

http://apps.leg.wa.gov/rcw/default.aspx?cite=46.63.160

4-6 State of Washington Contract No. ___ Department of Transportation

RTS_4.49 Supplemental lighting shall result in minimal additional light reaching the surrounding environment.

4.3.3.7 Enforcement Beacon (for Express Toll Lanes 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

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.

4-7 State of Washington Contract No. ___ Department of Transportation

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

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 RMH 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.

4-8 State of Washington Contract No. ___ Department of Transportation

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.

4-9 State of Washington Contract No. ___ Department of Transportation

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.

4-10 State of Washington Contract No. ___ Department of Transportation

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

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.

4-11 State of Washington Contract No. ___ Department of Transportation

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

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

4-12 State of Washington Contract No. ___ Department of Transportation

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.

4-13 State of Washington Contract No. ___ Department of Transportation

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

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.

4-14 State of Washington Contract No. ___ Department of Transportation

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.

4-15 State of Washington Contract No. ___ Department of Transportation

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 DATA 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.

4-16 State of Washington Contract No. ___ Department of Transportation

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

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.

4-17 State of Washington Contract No. ___ Department of Transportation

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.

4-18 State of Washington Contract No. ___ Department of Transportation

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

4-19 State of Washington Contract No. ___ Department of Transportation

• 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_4.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.

4-20 State of Washington Contract No. ___ Department of Transportation

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.237is 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.

4-21 State of Washington Contract No. ___ Department of Transportation

RT…