attachment 01 scope of workattachment 01 scope of work toll collection system for the dulles toll...

ATTACHMENT01ScopeofWork

TollCollectionSystemfortheDullesTollRoad

March,2016

Attachment 01 Scope of Work – March 2016

Pg. ii

Table of Contents

GLOSSARY OF TERMS ...................................................................................................................................... VIII

1 PROJECT OVERVIEW .................................................................................................................................. 19

1.1 PROJECT GOALS .............................................................................................................................................. 19

1.2 EXISTING SYSTEM DESCRIPTION ......................................................................................................................... 20

1.2.1 Dulles Toll Road Description .................................................................................................................. 20

1.2.2 Current DTR Toll Collection System Description ..................................................................................... 21

2 NEW TOLL COLLECTION SYSTEM FUNCTIONAL REQUIREMENTS ................................................................. 28

2.1 GENERAL DESCRIPTION OF NEW TOLL COLLECTION SYSTEM .................................................................................... 28

2.2 GENERAL REQUIREMENTS FOR THE NEW TCS ....................................................................................................... 29

2.2.1 Electrical Equipment .............................................................................................................................. 29

2.2.2 Computer Equipment ............................................................................................................................. 29

2.2.3 Mechanical Equipment .......................................................................................................................... 30

2.2.4 Software ................................................................................................................................................. 30

2.2.5 Software Licenses ................................................................................................................................... 31

2.3 RE‐USE OF EXISTING EQUIPMENT ....................................................................................................................... 32

2.4 LANE LEVEL REQUIREMENTS .............................................................................................................................. 32

2.4.1 Lane Types and Modes of Operation ..................................................................................................... 32

2.4.2 Data Exchange Between the Lane Controller and Host ......................................................................... 38

2.4.3 E‐ZPass Transponder Database ............................................................................................................. 39

2.4.4 Violation Detection ................................................................................................................................ 40

2.4.5 Automatic Vehicle Identification (AVI) Subsystem ................................................................................. 40

2.4.6 Automatic Vehicle Classification (AVC) Subsystem ................................................................................ 42

2.4.7 Automatic Coin Machine Requirements ................................................................................................ 43

2.4.8 Automated Toll Payment Machine Requirements (Alternate Option) ................................................... 45

2.4.9 Violation Enforcement Subsystem (VES) ................................................................................................ 49

2.4.10 Lane Controller .................................................................................................................................. 52

2.4.11 Intercom ............................................................................................................................................ 61

2.4.12 Lane Status Sign ................................................................................................................................ 62

2.4.13 Patron Fare Indicator (PFI) ................................................................................................................ 64

2.4.14 Canopy Lights .................................................................................................................................... 65

2.4.15 Equipment Enclosures........................................................................................................................ 65

2.5 HOST REQUIREMENTS ...................................................................................................................................... 66

2.5.1 General Requirements ........................................................................................................................... 66

2.5.2 Toll Rate Structure ................................................................................................................................. 67

2.5.3 Future Toll Rate Programs ..................................................................................................................... 67

2.5.4 Fare Determination ................................................................................................................................ 68

2.5.5 Real Time Monitoring ............................................................................................................................ 68

2.5.6 Remote Lane Management ................................................................................................................... 69

2.5.7 Host Administration Application ............................................................................................................ 70

2.5.8 Workstations .......................................................................................................................................... 70

2.5.9 Printers ................................................................................................................................................... 70


Pg. iii

2.5.10 System Interfaces .............................................................................................................................. 71

2.5.11 Migration to All Electronic Tolling ..................................................................................................... 74

2.5.12 Time Stamping and Synchronization ................................................................................................. 75

2.5.13 Vault Switching .................................................................................................................................. 75

2.5.14 Bank Deposit Reconciliation .............................................................................................................. 76

2.5.15 Version Tracking Requirements ......................................................................................................... 76

2.5.16 Revenue Day Assignment and Verification ........................................................................................ 76

2.5.17 Data Summarization .......................................................................................................................... 76

2.5.18 Diagnostics ........................................................................................................................................ 77

2.5.19 Data Security ..................................................................................................................................... 77

2.5.20 Transaction Processing ...................................................................................................................... 77

2.5.21 User Setup and Maintenance ............................................................................................................ 77

2.5.22 Upload Verification of Transaction Records ...................................................................................... 78

2.5.23 Transponder Status File and Fare Table Downloads ......................................................................... 78

2.5.24 Audit and Reconciliation .................................................................................................................... 79

2.5.25 TCS Reports ........................................................................................................................................ 80

2.5.26 TCS Host System Requirements ......................................................................................................... 91

2.5.27 System Access .................................................................................................................................... 98

2.6 DIGITAL VIDEO AUDIT SYSTEM (DVAS) ............................................................................................................... 99

2.6.1 DVAS Architecture and Network Video Management Server ................................................................ 99

2.6.2 DVAS Cameras ....................................................................................................................................... 99

2.6.3 DVAS Application ................................................................................................................................. 100

2.7 STANDALONE CAPABILITIES ............................................................................................................................. 100

2.7.1 Lane ..................................................................................................................................................... 100

2.7.2 Host ...................................................................................................................................................... 101

2.8 POWER BACKUP (UPS) .................................................................................................................................. 101

2.9 MAINTENANCE ONLINE MANAGEMENT SYSTEM (MOMS) ................................................................................... 102

2.9.1 MOMS Administration ......................................................................................................................... 104

2.9.2 Failure/Malfunction Reporting ............................................................................................................ 104

2.9.3 Performance and Status Monitoring ‐ Real‐Time Display and User Interface ..................................... 105

2.9.4 Remote Access/Dial‐Up Networking .................................................................................................... 105

2.9.5 Inventory/Spare Parts Control ............................................................................................................. 105

2.10 COMMUNICATIONS REQUIREMENTS ................................................................................................................. 105

2.10.1 Communications Network ............................................................................................................... 106

2.10.2 Network Backbone Coordination ..................................................................................................... 107

2.10.3 Lane to Host Communications ......................................................................................................... 107

2.10.4 Ramp to Host Communications ....................................................................................................... 107

2.10.5 Network Communications Monitoring ............................................................................................ 107

2.10.6 Communications Equipment ............................................................................................................ 108

2.10.7 Maintenance / Service ..................................................................................................................... 112

2.11 PCI COMPLIANCE .......................................................................................................................................... 112

2.12 ENVIRONMENTAL REQUIREMENTS .................................................................................................................... 113

2.12.1 Weatherproofing ............................................................................................................................. 114

2.12.2 Enclosures, Racks and Cabinets ....................................................................................................... 114

2.12.3 Workmanship .................................................................................................................................. 115

2.13 SYSTEM SECURITY ......................................................................................................................................... 115


Pg. iv

2.13.1 Data Security and Integrity .............................................................................................................. 115

2.13.2 Data and Anti‐Virus Protection ........................................................................................................ 115

2.13.3 Computer Access Security ................................................................................................................ 116

2.13.4 Remote Access Personnel Authentication ....................................................................................... 116

2.13.5 Physical Security .............................................................................................................................. 117

2.14 ACCURACY REQUIREMENTS ............................................................................................................................. 117

2.15 AVAILABILITY ................................................................................................................................................ 121

2.16 CHARGEABLE AND NON‐CHARGEABLE FAILURES .................................................................................................. 122

2.16.1 Chargeable Failures ......................................................................................................................... 122

2.16.2 Non‐Chargeable Failures ................................................................................................................. 122

3 TCS INSTALLATION REQUIREMENTS ........................................................................................................ 124

3.1 INSTALLATION SCOPE OF WORK AND REQUIREMENTS ........................................................................................... 124

3.1.1 Installation and Construction Coordination and Meetings .................................................................. 124

3.1.2 System Installation Requirements ....................................................................................................... 125

3.1.3 Compliance to Standards ..................................................................................................................... 127

3.1.4 Electrical Work ..................................................................................................................................... 127

3.1.5 Work Standards and Requirements ..................................................................................................... 131

3.1.6 FCC Licensing ........................................................................................................................................ 132

4 TCS TESTING ........................................................................................................................................... 133

4.1 OVERVIEW ................................................................................................................................................... 133

4.2 MASTER TEST PLAN ....................................................................................................................................... 134

4.3 FACTORY ACCEPTANCE TEST (FAT) ................................................................................................................... 134

4.4 SYSTEM ACCEPTANCE TESTING......................................................................................................................... 135

4.4.1 On‐Site First Installation Test ............................................................................................................... 135

4.4.2 Statistical Performance Test ................................................................................................................ 137

4.4.3 Measurement of Errors ........................................................................................................................ 137

4.5 COMMISSIONING TEST ................................................................................................................................... 138

4.6 EXTENDED OPERATIONS TEST (EOT) ................................................................................................................ 139

4.7 ANNUAL PERFORMANCE TEST.......................................................................................................................... 139

4.7.1 Annual Performance Test Report ......................................................................................................... 140

4.8 ANNUAL DISASTER RECOVERY TEST .................................................................................................................. 140

4.9 ANNUAL SECURITY TEST ................................................................................................................................. 140

4.10 INDEPENDENT TEST REPRESENTATIVE ................................................................................................................ 141

4.11 QUALITY CONTROL TEST BENCH ENVIRONMENT .................................................................................................. 142

5 PROJECT MANAGEMENT AND EXECUTION .............................................................................................. 143

5.1 PROJECT REPORTING AND MEETINGS ................................................................................................................ 143

5.1.1 Monthly Report and Progress Meeting ................................................................................................ 143

5.1.2 Project Meetings .................................................................................................................................. 143

5.2 STAFFING..................................................................................................................................................... 144

5.2.1 Key Personnel ....................................................................................................................................... 144

5.2.2 Staffing Plan ......................................................................................................................................... 144

5.3 DOCUMENTATION ......................................................................................................................................... 144

5.3.1 Contractor Developed Documentation ................................................................................................ 145


Pg. v

5.3.2 Third Party Documentation .................................................................................................................. 155

5.3.3 Third Party Software Documentation .................................................................................................. 155

5.3.4 Third Party Hardware Documentation ................................................................................................. 156

5.4 SYSTEM DESIGN AND DEVELOPMENT ................................................................................................................ 156

5.4.1 General Requirements ......................................................................................................................... 156

5.4.2 Requirements and Business Rules Verification .................................................................................... 156

5.4.3 Requirements Traceability Matrix........................................................................................................ 157

5.4.4 Software Design ................................................................................................................................... 158

5.4.5 System Network Design ....................................................................................................................... 158

5.4.6 Preliminary Design Review ................................................................................................................... 158

5.4.7 Design and Configuration Workshops ................................................................................................. 159

5.5 QUALITY ASSURANCE AND QUALITY CONTROL .................................................................................................... 160

5.5.1 Configuration Management System .................................................................................................... 160

5.5.2 Change Control Process ....................................................................................................................... 160

5.5.3 Records ................................................................................................................................................ 160

5.5.4 Control of Purchase .............................................................................................................................. 161

5.5.5 Inspection and Verification .................................................................................................................. 161

5.5.6 Handling, Storage and Delivery ........................................................................................................... 161

5.5.7 Inspection at Subcontractor and Contractor Facilities ......................................................................... 161

5.5.8 Access to/Inspection of Contractor's Facilities ..................................................................................... 161

5.6 TRAINING .................................................................................................................................................... 161

6 PROJECT SCHEDULE, PHASES AND MILESTONES ...................................................................................... 163

6.1 PROJECT PHASES ........................................................................................................................................... 163

6.2 PROJECT SCHEDULE ....................................................................................................................................... 164

6.3 WORK PROGRESS .......................................................................................................................................... 165

6.4 PHASE I ....................................................................................................................................................... 165

6.4.1 Phase IA ............................................................................................................................................... 165

6.4.2 Phase IB ............................................................................................................................................... 166

6.4.3 Phase IC ................................................................................................................................................ 167

6.5 PHASE II ...................................................................................................................................................... 168

6.6 PROJECT DELIVERABLES .................................................................................................................................. 168

6.6.1 General ................................................................................................................................................ 168

6.6.2 Summary of Major Project Deliverables and Deadlines ....................................................................... 168

6.6.3 Document Delivery and Control ........................................................................................................... 171

7 PHASE II ‐ TCS MAINTENANCE ................................................................................................................. 172

7.1 TCS MAINTENANCE AND SOFTWARE CONTINUOUS SUPPORT SERVICES ................................................................... 172

7.1.1 Maintenance Summary Scope of Work ................................................................................................ 172

7.1.2 Maintenance and Software Support Services ...................................................................................... 172

7.2 WARRANTY PROGRAM ................................................................................................................................... 174

7.2.1 Hardware Warranty Program including Third Party Warranty ........................................................... 174

7.2.2 Software Warranty .............................................................................................................................. 175

7.2.3 TCS Defect & Malfunction Severity ...................................................................................................... 175

7.2.4 Hardware Warranty ............................................................................................................................. 175

7.3 MAINTENANCE PLAN ..................................................................................................................................... 176


Pg. vi

7.3.1 Maintenance Coverage and Response Times ...................................................................................... 176

7.3.2 Maintenance Online Management System (MOMS) ........................................................................... 177

7.3.3 Preventive Maintenance ...................................................................................................................... 178

7.3.4 Predictive Maintenance ....................................................................................................................... 178

7.3.5 Corrective Maintenance ....................................................................................................................... 178

7.3.6 Upgrades and Enhancements .............................................................................................................. 179

7.3.7 Notifications ......................................................................................................................................... 179

7.3.8 Recording of Maintenance Activities ................................................................................................... 179

7.4 SPARE PARTS ................................................................................................................................................ 180

7.4.1 Spare Part Inventory and Tracking ...................................................................................................... 181

7.4.2 Procurement and Control of Spare Parts ............................................................................................. 181

7.4.3 Inventory Management ....................................................................................................................... 181

7.5 COOPERATION WITH OTHER CONTRACTORS AND PROVIDERS ................................................................................. 181

7.6 EMERGENCY RESPONSE MANAGEMENT ............................................................................................................. 181

7.7 INCIDENT AND REVENUE LOSS REPORTING ......................................................................................................... 182

7.8 MAINTENANCE STAFFING, MATERIALS AND TRAINING .......................................................................................... 182

7.8.1 Maintenance Staffing Requirements ................................................................................................... 182

7.8.2 Tools and Materials ............................................................................................................................. 182

7.8.3 Personnel Training ............................................................................................................................... 182

7.8.4 Training Materials and On‐going Education ........................................................................................ 182

7.8.5 Training Program ................................................................................................................................. 183

7.8.6 Training Records .................................................................................................................................. 183

7.9 SAFETY ........................................................................................................................................................ 183

7.10 MAINTENANCE AND PROTECTION OF TRAFFIC ..................................................................................................... 183

7.11 REPORTING REQUIREMENTS ............................................................................................................................ 184

7.11.1 Field and Shop Maintenance Records .............................................................................................. 184

7.11.2 Maintenance Summary Reports ...................................................................................................... 184

7.11.3 Additional Maintenance Summary Reports ..................................................................................... 185

7.12 ON‐SITE DOCUMENTATION ............................................................................................................................. 185

7.13 MAINTENANCE PERFORMANCE REQUIREMENTS .................................................................................................. 186

7.13.1 Maintenance Coverage ................................................................................................................... 186

7.13.2 Required Performance and Liquidated Damages ............................................................................ 187

7.14 SECURITY ..................................................................................................................................................... 189

7.15 CONFIDENTIALITY .......................................................................................................................................... 189

8 LIQUIDATED DAMAGES FOR DISRUPTION OF SERVICE ............................................................................. 190

9 SOFTWARE ESCROW ............................................................................................................................... 191


Pg. vii

Table of Figures

Figure 1-1: Dulles Toll Road Map ................................................................................... 20

Figure 1-2: DTR Lane Configuration Diagram .............................................................. 22

Figure 1-3: Dulles Toll Road Existing Network Diagram ............................................. 26

Table of Tables

Table 1-1: Current Vehicle Classifications and Toll Rates ......................................... 27

Table 2-1: Lane Operating Modes ................................................................................ 33

Table 2-2: ITL Signals ....................................................................................................... 65

Table 2-3: Network Functional Requirements ........................................................... 108

Table 2-4: Functional Security Requirements............................................................ 110

Table 2-5: TCS Performance Requirements ............................................................... 117

Table 2-6: TCS Availability............................................................................................ 121

Table 6-1: Project Phases ............................................................................................. 164

Table 6-2: Deliverable Deadlines ............................................................................... 170

Table 7-1: Severity Levels ............................................................................................. 175

Table 7-2: Response & Repair Times ........................................................................... 177

Table 7-3: Maintenance Performance Requirements and Parameters ................ 187

Table 8-1: Liquidated Damages For Disruption in Service ...................................... 190


Pg. viii

GLOSSARYOFTERMS

Term Acronym Definition

All Electronic Tolling AET A toll collection system that uses electronic means to capture revenue with no option for manual cash collection.

Advanced Encryption Standard

AES A 128 bit or larger symmetric key cipher encryption scheme based on NIST FIPS PUB 197 Advanced Encryption Standard used for protection of information.

Airports Authority The Metropolitan Washington Airports Authority. Amendment A document that is issued to make written revisions to the

solicitation Statement of Work issued by the Airports Authority prior to the Contractor proposal due date.

Application Processing Interfaces

APIs The specific method prescribed by a computer’s operating system or by an application program by which a programmer writing an application program can make requests of the operating system or another application.

As-Built Updated or ‘red-lined” drawings, plans, deliverables and other work products that reflect changes made during the implementation process, recording differences between the planned and the delivered Systems and Services.

Authorized User Any person who has been given permission by the Owner to access some portion of the System, Product, Service, data, or documents using role-based security.

Automated Toll Payment Machines

ATPMs A machine that allows a customer to pay their toll in a lane without a toll collector by using cash credit card or other means of payment.

Automatic Vehicle Classification

AVC A System for automatic vehicle detection, separation and classification of vehicles used for the determination of tolls fares.

Automatic Vehicle Identification

AVI A System consisting of radio frequency antenna and reader equipment and a compatible Transponder mounted in a vehicle for automatic unique identification of the vehicle upon the electronic read of the Transponder as it passes the toll collection point of the lane.

Automatic Coin Machines

ACM A machine located in the toll lane at a plaza that collects coins to pay for the toll.

Business Days Monday through Friday, 8:00 a.m. to 5:00 p.m., Eastern Time Zone, except for holidays observed by the State of Virginia and the Owner.

Calendar Days A period of time from midnight to midnight; all days in the month, including weekends and holidays.

Canopy Lights Lights that are mounted overhead of each lane on the upstream gantry in front of the plaza canopy used to inform oncoming traffic of whether a lane is open or closed.


Pg. ix


Change Notice A signed notice issued to the Contractor by the Contracting Officer specifying a proposed change to the Contract requiring the contractor to commence specified work on a time and materials basis.

Change Order A written order for any change in work issued and authorized by the Contracting Officer which precedes the modification to the contract.

Configuration Management

The management of security features and assurances through control of changes made to Hardware, Software, firmware, documentation, tests, and test documentation throughout the life cycle of the System.

Contract The signed agreement between the Owner and the Contractor to legally bind the Contractor to perform the duties outlined in the Solicitation, including not limited to, all exhibits, the Proposal, appendices, addendums, attachments, licenses, and any other document incorporated by reference into the specification in accordance with the Contract Terms and Conditions.

Contracting Officer CO An individual who has been issued a Certification of Appointment with formally delegated written authorization to commit the Airports Authority by entering into contracts and other contractual instruments such as modifications, task orders, delivery orders, purchase orders, and blanket purchase orders.

Critical Path A schedule of activities from beginning to end of the Contract, and the earliest and latest that each activity can start and finish to ensure successful implementation of the Contract.

Customer Service Center

CSC The Owner’s toll collection customer account management system and services used by the customers to pay for their tolls.

Day Refers to a calendar day unless otherwise stated. Deliverables Refers to the Contractor’s Products and Services, including

plans, documents, designs, components, Milestones and a fully functioning system which are prepared for the Owner during the course of Contractor’s performance under the Contact.

Demarcation Point Demarc The point at which the Airports Authority or Public Utility’s installed infrastructure terminates and the Contractor’s Work begins.

DTR Fiscal Department

Dulles Toll Road department that monitors and collects the toll revenue from the plaza and lanes.

Effective Date The date on which the Contract Documents are executed by the Contractor and the Contracting Officer.

Electronic Toll Collection

ETC A means of collecting toll revenue electronically with the use of a system that employs roadway sensors, cameras, computing and communications equipment capable of identifying the vehicle by RFID tag and/or License Plate image capture.


Pg. x


Enhancements All updates, upgrades, additions, and changes to, future releases for, maintenance updates, error corrections to the Software, firmware and/or System in whole or in part. It shall also include updates that encompass improvements, extensions, deficiency corrections, or other changes that are logical improvement or extension of the System.

Escrow Agreement An agreement entered into by the Airports Authority, Contractor and the Escrow Agent, for the establishment of a repository for Escrow Material.

Escrow Material The Software source code, and System Design Documentation, including all relevant commentary, explanations and other documentation, as well as instructions to compile such source code. Escrow Material shall also include all source code for the enhancements and modifications to the Software provided to Airports Authority under the Warranty and Maintenance segment of Work

Extensible Markup Language

XML An open electronic data exchange standard of specific form and format used for describing and defining data and data elements on a web page or in a data file.

E-ZPass Group The E-ZPass Group is an association of 25 toll agencies in 15 states that operates the E-ZPass electronic toll collection program that allows members to exchange toll data files in order to collect toll payments from customers who have E-ZPass accounts with other agencies.

Factory Acceptance Test

FAT The testing performed by the Contractor to verify that functional elements of the System, Product or Service are in conformance with the Technical and Operational Requirements.

Federal Communications Commission

FCC The communications regulatory agency of the Federal government that grants radio station licenses to tolling sites that use RFID based systems.

Fiber Backbone A fiber optic communications network that supports interconnectivity with many locations at high bandwidth data rates.

Fiber to Ethernet A interface that allow conversion in data communications format between a fiber optic base medium and a copper wire Ethernet based network.

File Transfer Protocol FTP Internet protocol subset that allows peer to peer file transfer across the network.


Pg. xi


Final Acceptance Closeout procedure ensures that the contractor has complied with all the contract requirements and that, in turn, the Airports Authority has fulfilled its obligations. Contract Closeout is the culmination of a series of monitoring actions throughout the life of the contract. A written notice from the Airports Authority to the Contractor indicating that a Product, System and/or Services purchased by Airports Authority for the Project has (a)passed its Acceptance Testing in accordance with the Acceptance Testing Plan, or (b) where there is no Acceptance Test Plan, when it otherwise meets the applicable Specifications of the Contract.


Pg. xii


Force Majeure Any circumstances or acts: (a) Which are beyond the reasonable control of the party seeking delay; and (b) Which do not arise from a default by or collusion of the party seeking delay; and (c) Which consist of an act of God or public enemy, fire, storm, wind, flood, seismic sea wave, tsunami, earthquake, epidemic, explosion, volcanic eruption, lightning, continuous loss of power or other utilities for more than thirty (30) Calendar Days not caused by any other event of Force Majeure, nuclear radiation, radioactive contamination, ionizing radiation, geological or archaeological condition, earth slides, quarantine restriction, government expropriation of property or equipment, freight embargo, act of war (whether declared or undeclared), ship wreck or train wreck or (with respect to Vendor) unexcused failure of Owner to perform an obligation within the relevant time period established pursuant to the Contract, any unexpected acts of Owner, court order restraining or enjoining performance of an activity within the relevant time period established pursuant to the Contract, interference by civil or military authorities, riot or public discord, civil disturbance, act of terrorism, sabotage, criminal damage or threat of such acts, labor strike (but excluding strikes, lockouts or other labor disputes directed at or involving Vendor or any of its Subcontractors of any tier), secondary labor boycott (but excluding any secondary labor boycott directed at or involving Vendor or any of its Subcontractors of any tier), or suspension of the national or State banking system due to financial crises; and (d) Which the party seeking delay could not have reasonably anticipated and prevented; and (e) Which have, or may reasonably be expected to have, a materially adverse effect on a right or obligation of the party seeking delay hereunder including circumstances or acts which: (i) Cause physical damage or destruction to the System; or (ii) Delay the scheduled time of commencement or completion of design, installation, or maintenance of the System or functions or delay performance by the party seeking delay of an act by a date certain agreed to in the Contract; or (iii) Interrupt the full and regular operation of all or any portion of the System or functions.

Graphical User Interface

GUI A Software screen and menu representation that allows users to input, retrieve, add, and change data.


Pg. xiii


Hardware A collective term that shall include the physical components of the System, including but not limited to receivers, transmitters, antenna, coaxial hardline, routers, hubs, servers, computers, telecommunications, mounting equipment and other similar devices. Hardware is also used collectively to describe the physical aspects of telecommunications network infrastructure.

High Occupancy Vehicle

HOV A public agency bus or vanpool or a carpool vehicle with minimum occupancy requirements that may vary from two to four persons depending upon the posted roadway HOV signage.

Host The computer and or system that performs the central processing of transactions from the toll lanes for the TCS and then sends them to the CSC.

Image File A file of digital images of the front and rear of vehicles that have passed through the tolling point for processing by the Optical Character Recognition subsystem and by human review.

Interface Control Document

ICD The interface control document that defines the file formats and related business rules for processing data and / or Toll Transactions.

Key Project Staff Contractor staff identified in the Contract documents that are assigned to the Project.

Lane Controller A full-featured solution that manages and automates the real-time control of toll lane equipment and creates secure revenue toll payment Transactions.

Lane Status Signs LSS A lane status sign system made up of LED displays integrated and controlled by the TCS to display alphanumeric and graphic information indicating the status of the toll lane to vehicles.

Laws and Regulations

The Airports Authority is committed to maximizing the competitive procurement process and ensuring that its contracting actions are guided by and carried out in accordance with all applicable law, including the statutes establishing the Airports Authority, the lease with the United States, the bylaws of the Airports Authority, sound contracting methods, and the highest standards of integrity and ethical conduct.

License The rights granted by the Contractor to the Owner to use the Software that is supplied or developed by Contractor under this Contract.

Light Curtain A vertical light bar system of lights and sensors a that collects data of a vehicles profile as they pass through the toll lane in order to determine the vehicle class.

Live Traffic Actual traffic on the roadway in an uncontrolled, live environment.


Pg. xiv


Manual Lane Terminal

MLTs The data entry terminal used by a Toll Collector to process a customer’s toll payment in the lane.

Maintenance Online Management System

MOMS An automated, fully integrated System that monitors the status of operational TCS in real time, records system and process failures, notifies maintenance personnel, generates and tracks Work Orders, maintains preventative maintenance schedules, generates repair history, maintains parts inventory and asset management.

Method of Payment MOP The manner in which a toll fare is rendered by the patron. Milestone Completion of Work for which Owner Approval is needed in

order to receive payment and or proceed with the next project phase.

Modification Changes or additions to the specifications authorized under this Contract, which changes or adds to the Work required to be performed by Contractor. All Modifications must be mutually approved and executed by the Contracting Officer to be a binding Contract.

National Electric Code

NEC NEC or NFPA 70 is a regionally adoptable standard for use by designers, engineers and electrical workers that dictates the safe installation of electrical wiring and equipment in the United States.

National Electrical Manufacturers Association

NEMA Industry organization that publishes standards for manufacturers of Electrical products to ensure safety.

Notice of Award Written notice of award sent by the Contracting Officer to the unsuccessful offerors , abstracts with the names of unsuccessful offerors redacted and with total price offers (other than unit prices) shown on such Documents will be released.

Notice to Proceed NTP Written notice from the Contracting Officer to the Contractor to proceed with the Work specified in the Notice to Proceed. Contracting Officers shall ensure that contractors are aware that they must not commence contract performance until such time as they receive Notice-to-Proceed (NTP).

NTCIP NTCIP National Transportation Communications for Intelligent Transportation System Protocol (NTCIP) is a family of standards designed to achieve interoperability and interchangeability between computers and electronic traffic control equipment from different manufacturers. For a TCS, NTCIP is used to provide a common communications format between digital variable message signs.


Pg. xv


Optical Character Recognition

OCR A Software process that automatically recognizes license plate characters without requiring human intervention, then extracts and provides the license plate characters and state jurisdiction from the image of the license plate.

Owner Metropolitan Washington Airports Authority (“Airports Authority”) Patron Fare Indicators

PFIs A numerical display mounted in a toll plaza lane that conveys the toll fare to the driver of the vehicle.

Performance Measures

The metric to which the System and certain Services shall perform during Acceptance Tests and thereafter in full operation, as described in the Contract.

Payment Card Industry

PCI Credit Card industry organization that publishes standards for the protection of personal credit information.

Permits The documented approval required for Work within the Right-of-Way pursuant to the Airports Authority regulations or policies, and any additions, substitutions or modifications to those polices.

Post-Class The TCS provides post-class AVC subsystem as the vehicle departs the toll lane.

Pre-Class The pre-determination of fare class based on the pre-class AVC subsystem.

Presence Loop (Loop)

Traffic loop installed in the roadway of the toll lane to detect the presence of a vehicle.

Priority Level A status established in order of importance or urgency. Project Shall mean the products and services procured through the

Airports Authority Solicitation process to obtain a Toll Collection System including design, development, implementation, operation and maintenance of the Toll Collection System in accordance with the terms and conditions of the Contract.

Contractor’s Project Manager

Contractor’s duly designated representative for day-to-day management of the Work and communications with the Owner.

Proposal Contractor’s Proposal to perform the Work required in the Solicitation.

Punch List Refers to the list of Work which remains to be completed after Tolling Commencement has been achieved and before System Acceptance.

Quality Assurance QA The process of confirming the degree of excellence of a Product or Service, measured against its defined purpose.

Quality Control QC The Operational techniques and activities that are used to fulfill the requirements for quality.

Radio Frequency Identification

RFID Short range wireless technology in the form of a radio based reader and vehicle mounted transponder (tag) used to specifically identify a vehicle by reading the tag as it passes the antenna.


Pg. xvi


Ramp Subnets Logical Ethernet sub-networks that support the toll collection system at each exit/entry ramp location.

Redundant Array of Individual Drives

RAID A data storage virtualization technology that combines multiple disk drive components into a logical unit for the purposes of data redundancy or performance improvement.

Relational Database Management System

RDBMS A set of Software programs that controls the organization, storage, management and retrieval of data (or objects) in a database.

Router A network communications component that connects devices to the toll system network.

Requirements Traceability Matrix

RTM A spreadsheet form that contains all the requirements of the Project and indicate their location in the Solicitation, Amendments, Exhibits, Appendices etc.

Request for Proposal RFP A solicitation document used in negotiated procurements seeking proposals that conform with the solicitation from responsible offerors.

Right of Way ROW All real property to which the Owner holds fee title or other real property interest and which is devoted to State highway purposes, including but not limited to toll plazas, parking lots, ramp access, rest areas, scenic view areas, weigh stations, park and ride facilities, maintenance facilities, pit sites and the like.

Scalable The ability of the System to scale to support larger or smaller volumes of data and more or less users.

Scope of Work SOW Also referred to as Statement of Work. This is a description of the construction, goods, or services being procured.

Site The locations where the Work will be performed and all locations where the systems, services and equipment shall reside or be delivered.

Software Defined as computer instructions, including but not limited to, programs, routines, functions, libraries, and data bases, supplied, procured or developed by Vendor in connection with the performance of the Work, including but not limited to the Software; however, Software shall not include embedded code, firmware, internal code, micro code, and any other term referring to software residing in the equipment that is necessary for the proper operation of the equipment is not included in this definition of Software. Software includes all prior, current, and future versions of the Software and all Maintenance updates and error corrections which are provided to the Owner under the Contract.


Pg. xvii


Solicitation An Invitation by the Airports Authority for Bids, Request for Proposals (RFP), Request for Quotations (RFQ), or Request for Qualifications Information (RFQI).

Special Events Functionality of the toll system accommodate vehicle travel through the toll lane(s) during critical events such as evacuations, convoys or other events as deemed necessary by the Airports Authority.

Subcontractor A person, partnership, company, or other organization which is not in the employment of or owned by Contractor, that is performing all or part of Contractor’s responsibilities under the Contract, pursuant to a separate contract entered into by and between the Subcontractor and of the Contractor. The term “Subcontractor” means a Subcontractor of any tier.

System The fully functional TCS designed, developed, and installed by the Contractor under the Contract, including but not limited to all Products, Services and subsystems.

System Acceptance The Airports Authority written acceptance of the Project Milestone indicating that the Owner has approved and fully accepted the System.

System Acceptance Testing

SAT The testing of the Systems and Services provided under the Contract to ascertain that the systems and services meet the requirements of the Work and the Performance Measures after Tolling Commencement.

System Administrator A user responsible for managing and maintaining the configuration and operation of a subsystem, System, or Product.

T-1 Lines A specific type of copper or fiber optic communications line that has a data rate of 1.544 megabits.

Tape Backup

Computing peripheral that uses magnetic tape and connects to a toll system host computing environment to make a copy of the information stored on the system as a backup in case of failure or loss of data.

Terminal Server

A computing device that allows multiple users to access the toll system host environment.

Toll Collection System

TCS Reference to an electronic system that is installed on toll road to collect tolls and works in conjunction with the CSC and uses various communications and electronic technologies to facilitate the collection of tolls from customers.

Toll Zone TZ The area of the roadway where the TCS detects vehicles passing and performs tolling functions, such as RFID Transponder reads, image capture and Automatic Vehicle Classification and communicates this data to the Toll Zone Controller.


Pg. xviii


Tolling Commencement

A Project Milestone giving the Owner the ability to start revenue operations on the Toll Road or Bridge.

Transaction A record of activity of road sensors producing an event recorded by the System.

Transponder An identification device attached to a toll customer’s vehicle that in conjunction with the reader will automatically identify the toll customer’s vehicle as it passes through the toll lane.

Transponder Account

A customer Toll account created at the CSC that primarily uses a Transponder to identify and charge the customer in accordance with the CSC business rules.

Treadle An electro-mechanical or optical sensor mounted in the road bed of the toll lane used to count vehicle axles and determine direction of travel.

Unattended A toll lane that is not staffed with a toll collector and is fully equipped with an automatic toll collection system.

Uninterruptible Power Supply

UPS An electrical device or system that supplies power instantly for a limited amount of time to the TCS in the event that Utility power ceases.

Unplanned Disruption

Defined as a disruption in operation and service delivery to existing systems, circuits, and equipment that occurs outside of a time period planned and pre-approved by the Owner.

Unusual Occurrences

UO Not classified as a normal toll transaction

Violation Enforcement System

VES A system of cameras, sensors, logic and software that capture toll evaders and produce a means for generating a violation transaction to be sent to the VPC.

Violation Processing Center

VPC A system or provider which receives violation images and data from the TCS for subsequent processing of violation noticing.

Warranty and Maintenance Period

The period following System Acceptance to the end of the Contract term whereby the System is maintained by the Contractor.

Work All of the Contractor’s efforts necessary to complete all of its obligations under the Contract.

Work Order An automated (or manual) request for service generated by the Toll Collection System to the Contractors Maintenance Personnel.


Pg. 19

1 PROJECTOVERVIEW

1.1 ProjectGoals

The purpose of this project is to acquire a new Cash/E-ZPass Toll Collection System (“TCS” or “System”) and securing on-going TCS maintenance services for the Dulles Toll Road. To fulfill these intentions, the following project goals have been established:

Acquire a new Toll Collection System that is non-proprietary to the extent possible, is scalable and expandable, is based on an open and decoupled architecture and is adaptable to accommodate future migration to All Electronic Tolling (AET).

Maintain the use of Automatic Coin Machines (ACMs) until they are eventually phased out.

Preserve and or improve functionality including but not limited to a new Violation Enforcement System (VES), Maintenance Online Management System (MOMS), Digital Video Audit System (DVAS) and communications network.

Decommissioning, removal and disposal of existing infrastructure that will not be used in the new TCS in accordance with the Airports Authority’s rules.

Obtain on-going TCS maintenance services.

Establish standardized open application processing interfaces (APIs), such as the interfaces to the E-ZPass Customer Service Center (CSC), Violation Processing Center (VPC), bank and General Ledger, which are sustainable and adaptable to changes in business rules.

Utilize asynchronous queue messaging techniques to facilitate communications between all systems and applications.

Utilize NTCIP protocols where applicable when designing the system architecture, communications systems and interfaces.

Obtain a fully PCI compliant TCS that is capable of integrating real-time in-lane credit card readers and Automated Toll Payment Machines (ATPMs) at some point in the future.

The project will be administered in two (2) distinct phases. Phase I includes commencement of work upon issuance of a Notice to Proceed (“NTP”) and involve the


Pg. 20

design, development, testing and deployment of the new TCS. Phase II will begin with complete warranty and maintenance support of the new TCS.

1.2 ExistingSystemDescription

1.2.1 DullesTollRoadDescription

The Dulles Toll Road (DTR) was built in 1984 by the Virginia Department of Transportation (VDOT) to provide local access to interchanges between the Capital Beltway (I-495) and Washington Dulles International Airport. The toll road is located in the Dulles Corridor, which also carries the Dulles Airport Access Highway and is the location of the Dulles Corridor Metrorail Project. The DTR is a 14-mile portion of Virginia Route 267, with four primary travel lanes in each direction. The DTR is primarily a commuter based road. Figure 1-1 below provides a general overview map of the Dulles Toll Road.

Figure 1-1: Dulles Toll Road Map

In 2013 the DTR toll collection system processed over 88 million total toll transactions of which nearly 80 percent were made by vehicles paying with E-ZPass transponders. Currently all E-ZPass and violation transactions are processed, under agreement with the Virginia Department of Transportation (VDOT), through its E-ZPass Customer Service Center (CSC) and Violation Processing Center (VPC) currently operated by Faneuil with technical support from 3M. Additionally there is also a separate access road within the center median of the DTR known as the Dulles Airport Access Road which provides free travel between Dulles Airport and I-66. Access to/from the Dulles Airport Access Road is not tolled for revenue collection however certain ingress/egress points are controlled by the toll system to


Pg. 21

allow authorized vehicles (via E-ZPass) to use the access road. The following is a list of each ingress/egress point:

Westbound (inbound to airport) o I-495 – Entry Only, Not Controlled o Beulah Road – Entry Only, Not Controlled o Hunter Mill Road – Exit Only, TCS Controlled o Monroe Park & Ride – Entry Only, Not Controlled o Dulles Airport (WB Terminus) – Exit Only, Not Controlled

Eastbound travel (outbound from airport) o Dulles Airport - Exit Only, Not Controlled o Centerville Road – Exit Only, Not Controlled o Hunter Mill Road – Entry Only, TCS Controlled o Leesburg Pike – Exit Only, Not Controlled

Revenue collection on the DTR is currently carried out at nineteen (19) interchange locations and one (1) mainline plaza. Patrons may pay tolls via E-ZPass, exact change (unattended lanes) or cash (attended lanes). On November 1, 2008, VDOT transferred the operation of the DTR to the Metropolitan Washington Airports Authority (Airports Authority). Under this transfer the Airports Authority is the sole operator of the DTR. Recent and historical DTR traffic and revenue statistics are document in the Dulles Toll Road Comprehensive Traffic and Revenue Study, which is located at: http://www.metwashairports.com/file/CTR_Study2014.pdf. Other facts and figures about the DTR can be found at: http://www.metwashairports.com/tollroad/1135.htm

1.2.2 CurrentDTRTollCollectionSystemDescription

The existing DTR TCS is comprised of a barrier tolling system, totaling 59 lanes across the DTR and accommodating toll collection at 19 ramp locations and one (1) mainline plaza. Lane types include dedicated E-ZPass only lanes (both low speed conventional lanes and higher speed Express lanes), Unattended lanes (exact change) and Attended lanes. Figure 1-2 provides a detailed layout of the various DTR toll plaza locations, lane designations and lane configurations.


Pg. 22

Figure 1-2: DTR Lane Configuration Diagram

With the exception of the Express E-ZPass Lanes, each lane system is generally comprised of an Automatic Vehicle Identification (AVI) Subsystem, Automatic Vehicle Classification (AVC) Subsystems (both pre-class AVC and post-class AVC), a Violation Enforcement Subsystem (VES) Patron Fare Indicators (PFIs), Island Traffic Lights (ITLs),


Pg. 23

Lane Status Signs (LSSs) and Canopy Lights. Some lane systems also have Automatic Coin Machines (ACMs).

In an Unattended lane, tolls are collected by exact change from the patron deposited directly into the ACM or via E-ZPass.

In an Attended lane the toll collector may either make change for a patron and then deposit the fare directly into the ACM or the patron may deposit the exact change directly into the exterior ACM basket. The collectors do not collect any toll revenue; they simply make change for patrons. Additionally, Attended lanes also include manual fare collection equipment such as a Manual Lane Terminal (MLT), and Receipt Printer. Attended lane functionality allows for the collector to also classify vehicles and process additional transaction types such as Unusual Occurrences (UO) and Authorized Run-throughs.

Currently when ACM vaults are 50 percent full, 75 percent full and 100 percent full, the TCS sends an audible alert to the DTR control room. The DTR fiscal department staff then pulls the full vaults for subsequent count and reconciliation.

All DTR toll lanes are equipped with E-ZPass antennas and readers.

The DTR currently employs two (2) differing types of E-ZPass Only lanes – low speed conventional dedicated E-ZPass lanes and higher speed Express E-ZPass lanes. There is no pre-class AVC subsystem in Express E-ZPass lanes as there is in the conventional E-ZPass and cash lanes.

Maintenance of the current TCS is provided by TransCore.

The overall TCS is currently comprised of three (3) basic functional levels or tiers:

1. Lane System 2. Plaza/Host System 3. Communications System

The current lane system consists of the following hardware categories and items:

E-ZPass AVI readers, antennas and RF modules, cables, attenuators, mounting brackets and reader cabinets. Readers are Kapsch (formerly Mark IV) legacy RoadCheck models.

AVC subsystems (some lanes contain a mix of TransCore’s IVIS™) o Cash and conventional dedicated E-ZPass Lanes.

Pre-Class Presence Loops (2) Light Curtain (5 ft) Treadle (4 strip)

Post-Class


Pg. 24

Presence Loops (2) Light Curtain (5 ft) Treadle (4 strip)

o Express E-ZPass Lanes Only (single lane channelized) Post-Class (Mix of Idris Loops and IVIS™)

VES Subsystem – Front and Rear Cameras Lane Controllers ACM (coin sorters, coin paths, dual and quad vault systems) Manual Lane Terminals (touch screens and mounting arms) Receipt Printers Equipment Cabinets Canopy Lights Lane Status Signs (LSSs) Patron Fare Indicators (PFIs) Island Traffic Lights (ITLs) Uninterrupted Power Supplies (UPSs)

The general functionality of the lane system is to detect and classify vehicles according to the Airports Authority’s toll collection business rules, apply the appropriate toll rate, collect and account for toll revenue, capture pictures of vehicles license plates (front and rear), provide feedback to the driver and create a transaction (toll or violation) for each vehicle.

The E-ZPass AVI antennas, Lane Status Signs and Canopy Lights are all mounted on steel truss gantries located upstream just prior to the toll plaza canopy structure.

The Plaza/Host is located in an environmentally controlled computer room at the Airports Authority’s DTR administration building located next to the mainline plaza.

Ramp plazas do not have independent plaza servers and all ramp lanes communicate directly to the Plaza/Host System at the DTR administration building.

The current Plaza/Host System consists of the following hardware items installed at the mainline toll plaza only.

Plaza Terminals Printers Uninterrupted Power Supplies Dual DEC AlphaServer DEC Router Terminal Server Communication Routers and Switches Tape Backup


Pg. 25

The basic functionality of the Plaza/Host System is to process and store transactional data from the lanes, accommodate lane monitoring, facilitate remote ramp/lane operations, toll collection staff management, collector cash out functions and interface with the E-ZPass CSC and VPC.

The current Host System has reached its useful life capacity and is in need of immediate replacement to preserve the Airports Authority operation of the DTR. To address this immediate need the Airports Authority is currently in the process of upgrading the Host System. The physical infrastructure and supporting host hardware is being procured by the Airports Authority. The specifications for the upgraded Host System have been provided in Appendix A. Under separate contract with the current TCS provider TransCore, the TCS Host software system will be deployed on the new Host infrastructure. Recognizing the Airports Authority’s investment in this replacement Host the Contractor is encouraged to any extent possible, to utilize this hardware either through re-use or repurposing. In the event the Contractor chooses to utilize all or parts of the replacement Host they shall clearly indicate the details in the proposal technical response.

In addition to the DTR toll lanes, there are two stand-alone access ramps located at the Monroe Park and Ride Lot which provide AVI only access from the Dulles Airport Access Road (DAAR) to the DTR for buses with authorized transponders. The TCS interfaces with these stand-alone ramps to maintain and update the white list of authorized transponders. The current TCS Communications System consists of the following hardware items:

Fiber backbone (connects all ramps toll plazas and the mainline plaza) T-1 Line and wireless connection from the Monroe Street Park and Ride Access

Ramps to the mainline plaza Ramp subnets Ethernet lane to Plaza/Host (at mainline) or lane to Fiber converter (at ramps) Fiber to Ethernet Converters Routers and lightly managed hubs T-1 Lines

The Communications System provides the means for all data to be transmitted among the various Lane and Plaza/Host Systems and to/from the E-ZPass CSC and VPC.

The existing Dulles Toll Road network configuration is illustrated in Figure 1-3.


Pg. 26

Figure 1-3: Dulles Toll Road Existing Network Diagram

Currently DTR fares are calculated on an axle-based vehicle classification structure. The Airports Authority does not currently anticipate any changes to the vehicle classification structure. Since the DTR is configured as a barrier tolling system, patrons pay tolls as they pass each tolling point (ramps or mainline toll plaza) based on the approved toll rate.

Table 1-1: Current Vehicle Classifications and Toll Rates below shows the current vehicle classification and toll rate structure.


Pg. 27

Table 1-1: Current Vehicle Classifications and Toll Rates

Vehicle Type At the Main Toll Plaza At the On/Off Ramps

2 Axles $2.50 $1.00

3 Axles $5.00 $2.00

4 Axles $6.25 $2.50

5 Axles $7.50 $3.00

6 or More Axles (Maximum Toll)

$8.75 $3.50


Pg. 28

2 NEWTOLLCOLLECTIONSYSTEMFUNCTIONALREQUIREMENTS

2.1 GeneralDescriptionofNewTollCollectionSystem

This project shall involve the efforts needed to replace the current System with a new fully functional TCS. The new TCS shall have an expected life cycle of no less than 10 years and shall be both easy to maintain and cost effective to the Airports Authority.

The new TCS shall meet the following criteria:

a) The new TCS shall be developed from an existing and stable TCS product base. b) The new TCS shall be capable of integrating future functionality such as real-time

In-lane Credit Card Processing, Automated Toll Payment Machines (ATPMs), additional toll fare schedules, additional classification schedules, and time of day pricing.

c) In support of MAP21 mandates the new TCS shall be capable of supporting both current E-ZPass Group (PS111) and future national interoperable protocol(s) protocols through the use of multi-protocol AVI readers that are certified by the E-ZPass Group.

d) The new TCS shall be scalable, both vertically (by adding more computing power to existing equipment) and horizontally (by adding more equipment) to accommodate future growth.

e) The new TCS shall be scalable, expandable and adaptable to accept other toll lanes and ramps.

f) The Contractor shall replace the lane systems at the stand alone Monroe Park and Ride lot access ramps as well as the controlled ramps to/from the Dulles Airport Access Road. The TCS shall also ensure that the white list of authorized transponders is up-to-date at the access ramps to allow continued access to buses with authorized transponders.

Phase I shall commence with NTP. In Phase I the Contractor shall provide a seamless transition from the legacy System to the new TCS.

The Contractor is urged to propose any new system design modifications such as enhancements or additional functionality that may introduce efficiencies in operations and or positive impacts to both initial system costs as well as on-going maintenance during Phase II. The Contractor shall clearly identify any potential value-added enhancements or functionality to the Airports Authority.

The new DTR Host will continue to communicate directly with the E-ZPass CSC and VPC as per the approved Interface Specifications Documents attached as Appendix B.


Pg. 29

2.2 GeneralRequirementsfortheNewTCSThe Contractor shall comply with the following general requirements for the new TCS as specified by the Airports Authority.

2.2.1 ElectricalEquipment

Equipment operation shall not be affected by transient voltages, surges and sags normally experienced on commercial power lines. It is the Contractor’s responsibility to check the local power service to determine if any special design is needed for the equipment. The extra cost, if required, shall be the responsibility of the Contractor.

All equipment shall meet all the applicable objectives of the most recent National Electrical Manufacturers Association (NEMA) Standards. All wiring shall meet all the applicable objectives of the most recent National Electric Code and all local codes.

The System design shall include all necessary utility upgrades to properly operate the System being installed.

The Contractor shall be responsible for obtaining all necessary permits and approvals to perform all needed electrical work at each facility. This includes the responsibility for preparing and submitting applications for FCC site licenses.

The power requirements of the system shall comply with all applicable industry regulations, codes, and safety requirements and shall follow best industrial practices. The Contractor shall submit to the Airports Authority for approval a complete wiring diagram for the work to be done before installation of conduit or electrical equipment.

The Contractor shall provide supporting calculations and documentation that there is sufficient power available for all the equipment and that the storage capacity of the uninterrupted power supply meets the minimum time requirements of 30 minutes of backup power for the DTR mainline toll plaza and 60 minutes of backup power for all DTR ramp toll plazas.

The Contractor shall adhere to all applicable electrical requirements specified in the Airports Authority’s Design Manual, which can be found on the Airports Authority’s website at http://www.mwaa.com/business/airports-authority-design-manual .

2.2.2 ComputerEquipment

Any local computer server(s) utilizing disk drives shall provide for a Redundant Array of Individual Drives (“RAID”) configuration that includes a hot spare that will automatically be configured into the active drive array in the event that a drive failure is encountered without loss of data or interruption of computer system operation.

Any proposed tape backup systems shall utilize an LTO-5 or newer tape utilizing data encryption. The encryption scheme shall conform to the latest “NIST FIPS PUB 197


Pg. 30

Advanced Encryption Standard (“AES”)” and shall be kept current throughout the term of the Contract and any subsequent extensions. A minimum 128 bit or larger symmetric key cipher shall be used.

All computer server(s) including tape and disk units shall be rack mounted in 19” rack cabinets.

The Systems that will be located in the primary data center shall be replicated at a backup data center. The data shall be immediately replicated to the backup site and the systems configured for automatic failover.

All servers located in the primary data center and the backup site shall have dual redundant power supplies that are hot-swappable. The redundant power supplies shall be powered from separate circuits.

The System shall include the ability to remotely update any tables or other configuration information for the application both system wide and to the lane level without the need to reboot the affected system.

The Contractor shall adhere to all standards governing computer equipment specified in the Airports Authority’s Technology Standards. These standards will be provided at the time of the Pre-proposal meeting.

2.2.3 MechanicalEquipment

All cabinets, enclosures, equipment housing that are installed outdoors and are exposed to the elements shall be fabricated of 14 gauge Type 304 stainless steel or better, powder-coated and constructed to NEMA 4X standards and IP 66 standard specifications for equipment enclosures. They shall also be designed to be water proof and completely sealed to prevent any entry of moisture. Anchor bolts, nuts, couplings, studs and washers shall be stainless steel conforming to ASTM F593 / F594 and shall be fabricated in accordance with ASTM standards. If required by the Selected Contractor’s design, any required supplemental heating or cooling of the interior of these enclosures will be included at no cost to the Airports Authority.

The Contractor shall adhere to all applicable mechanical requirements specified in the Airports Authority’s Design Manual, which can be found on the Airports Authority’s website at http://www.mwaa.com/business/airports-authority-design-manual .

2.2.4 Software

The System shall employ redundancy as needed to meet the required availability and functionality requirements and to protect against data loss and data corruption. Data loss includes the loss of transaction data, any system configuration or operational information, or any other information that would negatively affect the DTR operations.


Pg. 31

Communication transmissions shall employ reliable means of confirming sent data is accurately received.

The System shall be designed to protect against data loss caused by equipment malfunction and failure, inadequate data storage capacity, communication loss, power outage, voltage drop or surges, extreme temperatures, deletion by unqualified and unauthorized users, or software attacks (i.e., rogue users/hackers, virus attacks, etc.).

The System shall employ an integrated and comprehensive anti-spam and anti-virus protection system.

Any modifications to data (records) shall be made as adjustment entries with all actions recorded to a retrievable chronological log that includes notations to support System audits. The System screens shall support this adjustment feature in both entry and review modes such that adjustments made to the data are readily available. The name and user ID of the person making the adjustment as well as the date, time, workstation, and specific notation that was made shall accompany each adjustment record. This component feature shall be assignable to user-access levels by the system administrator.

The Contractor shall specify in their proposal any operating system(s) and or platform(s) on which the lane controller, Host, or other subsystem(S) software application(s) will be utilizing.

2.2.5 SoftwareLicenses

The TCS software license shall grant the Airports Authority a perpetual, irrevocable, nonexclusive, non-transferable, license to use the TCS software, system and all associated documentation, subject to the terms of the Contract. The Airports Authority may allow its agent(s) and or other Contractors acting on its behalf to access and use the software.

The Contractor shall furnish and keep up to date all third-party software licenses required to operate the TCS during the Contract term and any subsequent contract term extension. Any late fees or penalties incurred due to the Contractor’s lack of control over the software licenses and support process shall be paid by the Contractor.

The Contractor shall transfer all software licenses to the Airports Authority at the completion or termination of the Contract Term and any extension to the Contract Term.


Pg. 32

2.3 Re‐UseofExistingEquipmentThe Airports Authority has determined that certain TCS components may be re-used as part of the new TCS and the TCS shall interface to the existing devices as specified in the Scope of Work. The following is a list of the equipment which may be re-used.

Canopy Lights Island Traffic Lights Fiber Backbone Gantries

The Contractor is encouraged to examine these existing items during the Pre-Proposal Meeting and Site Visit. The Contractor may, at its own discretion, propose the replacement of any of these items. However any such replacement must be clearly identified in the proposal by the Contractor. The Airports Authority recognizes that the current ACMs are aging. It is the intent of this Solicitation that the Contractor shall provide new ACMs while preserving ACM operations as are currently performed. At some point in the future, the Airports Authority intends to phase out the use of the ACMs and replace them with cash collection and/or credit card processing. The Airports Authority is also considering the use of Automated Toll Payment Machines (ATPMs) that will accept both cash (coin and bills) and credit cards (swipe and contactless) as well as other electronic methods of payment including cell phone payment. The new TCS shall be capable of integrating ATPMs for future use by the Airports Authority (see section 2.4.8, Automated Toll Payment Machine Requirements). The Contractor may reuse the existing lane controller cabinet housing and location in the tunnel. Alternative locations for lane controllers shall be clearly identified in the Contractor’s proposal.

2.4 LaneLevelRequirementsThe following sections are intended to describe the TCS requirements for each of the various lane types and lane operating modes. All lane functionality described in this section shall be reviewed and approved by the Airports Authority during the system design process.

2.4.1 LaneTypesandModesofOperation

The new TCS shall support the following lane operating modes indicated in the Table below:


Pg. 33

Table 2-1: Lane Operating Modes

LANE TYPE LANE OPERATING MODE PAYMENT METHOD

Attended

Manual/ACM/E-ZPass Cash, Exact Change or E-ZPass

ACM/E-ZPass Exact Change or E-ZPass Closed None Special Events None Maintenance None

Unattended

E-ZPass Only E-ZPass

ACM/ATPM Only/E-ZPass Exact Change, Cash, Credit Card* or E-ZPass

Closed None Special Events None Maintenance None

Express E-ZPass

E-ZPass Only E-ZPass Closed None Special Events None Maintenance None

* Indicates Future capability

Special Events Mode - The Special Events functionality shall accommodate vehicle travel through the toll lane(s) during critical events such as evacuations or other events as deemed necessary by the Airports Authority. Under this mode, tolls may not be collected (i.e. toll rates shall be set to $0.00) or a special events rate may be applied. In any case the TCS shall record the full transaction details, including the vehicle classifications, so that the Airports Authority could determine the potential toll revenue loss for reimbursement. The Canopy Light and Island Traffic Light shall remain a steady green. The PFI shall remain blank to avoid patron confusion. The AVC subsystem(s) shall continue to classify and record each vehicle and the lane shall assign a Method of Payment (MOP) as Exempt, with a reason code called Special Event. In Special Events Mode, the VES subsystem shall not create any violation transactions. The AVI subsystem shall remain active but no E-ZPass transactions shall be sent to the E-ZPass CSC and all transaction details shall be reported to the Host. The TCS shall be capable of placing any lane in Special Events mode. The TCS shall only allow specific authorized users to place a lane in Special Events mode from the DTR control room.

2.4.1.1 AttendedLaneThe TCS shall require the toll collector to login to the lane controller through the manual lane terminal (MLT) by manually entering a unique collector ID and a four digit PIN. The existing legacy TCS collector ID information shall be retained in the new TCS. The new TCS shall mask both the unique collector ID and PIN during entry into the MLT.


Pg. 34

In an Attended lane all vehicles shall be processed either manually by a toll collector via the ACM or automatically by the E-ZPass AVI subsystem. The toll collector makes change and deposits all fares directly into the ACM. The collector does not retain any toll fare revenue. For cash payments (ACM/E-ZPass attended lane mode) the toll collector shall process vehicles into the MLT as follows:

1. Determining and entering the vehicle classification (only when the collector determines that the vehicle needs to be reclassified).

2. Receiving payment from the motorist, making change if required and providing a receipt. Either the collector or the motorist deposits the toll payment in the form of exact change into the ACM. The TCS shall also have the ability to produce a print out from the receipt printer with up to 5 pre-defined messages such as directions, E-ZPass information.

3. Handling exceptions (e.g. Unusual Occurrences, authorized run-throughs). 4. The collector shall have the ability to modify the vehicle classification

(determined by the pre-class AVC subsystem) during a manual transaction, which shall result in coding the transaction as an unusual occurrence (UO) for “vehicle re-class”.

5. The TCS shall record and provide a complete audit trail or log of each collector action performed through the MLT.

6. The MLT shall prompt the collector to confirm that they wish to reclassify a vehicle.

7. The MLT screen shall include a “Back” button to allow the collector to go back one step in the transaction processing sequence if they wish to do so.

8. If the driver requires a cash receipt, the collector will push the Receipt button on the MLT and the Receipt Printer shall generate a receipt for the transaction.

9. The MLT shall allow the collector to modify the vehicle classification even if money has already been deposited into the ACM as long as the vehicle has not left the booth area and entered the post-class AVC area.

10. The collector shall have the ability to process convoys such as military, funeral or other multiple vehicle processions through a single lane. Convoy transactions shall be tolled; the first vehicle shall pay for the entire convoy and be issued a convoy receipt. If convoy operations are selected the following shall occur:

a. The Canopy Light shall be green while the Island Traffic Light remains green;

b. The TCS shall notify the toll supervisor by displaying a notification alert on the Supervisor monitor screen when the collector initiates convoy operations and the alert shall remain on while the convoy is being processed;

c. All transactions shall be recorded and a corresponding indicator shall appear in the transaction record for each vehicle passage as part of the convoy;


Pg. 35

d. Any vehicle that is part of the convoy procession and is equipped with a valid transponder shall not be assessed an electronic toll;

e. In the event a non-convoy vehicle enters the lane during the procession, the collector shall have the ability to pause or hold the convoy and process the non-convoy transaction normally. Upon completion of the non-convoy transaction the lane shall automatically return to convoy mode; and

f. The AVC classes (pre-class and post-class) and the AVI class (if available from the transponder) shall be included in the transaction.

11. The MLT shall have individual buttons for specific Unusual Occurrences such as “Authorized Run-Throughs” or “Authorized Non-Revenue” transactions. Pressing this button shall display a new screen where the type of authorized transaction can be selected (e.g. police, fire department, ambulance, etc.).

12. The receipt printer shall be capable of printing a non-revenue form if the collector presses the “Authorized Non-Revenue” button.

13. The MLT shall display the queue of transactions if multiple vehicles are present in the pre-class area by displaying the pre-class AVC axles and an indication that the vehicle has a valid transponder (where applicable). No collector action shall be required if the vehicle is equipped with a valid transponder. The MLT shall also identify the current transaction being processed.

14. If the driver of a vehicle does not deposit the correct toll amount in the ACM, there will be no expectation or activity from the collector. The transaction shall be treated as a violation.

15. The VES cameras shall capture and save license plate images of toll violators (i.e. underpayments or non-authorized run-throughs) when a lane is operating in Manual/ACM/E-ZPass mode.

16. Vehicle Classification shall be determined by configurable Airports Authority business rules:

a. Currently the TCS determines the cash fare class based on the pre-class AVC subsystem unless the collector re-classifies the vehicle. The post-class AVC subsystem is used for Airports Authority audit purposes.

b. Currently the TCS determines the E-ZPass fare class based on the AVI class from the transponder, unless the pre-class AVC indicates a different class. If there is a class mismatch discrepancy between the AVI and AVC classes, then the pre-class AVC classification shall be used.

17. The transaction record shall contain all classes recorded (pre-class AVC, collector, post-class AVC and AVI).

All MLT key strokes shall be captured as electronic data by the lane controller. This data shall be transferred to the Host and shall be easily retrievable and reviewable by the Airports Authority toll audit staff.


Pg. 36

The MLT shall visually alert the collector that a vehicle is equipped with an E-ZPass transponder.

The lane controller shall capture data from the ACM. This data shall be processed by the System where the vehicle class, expected payment and actual payment are tracked.

The TCS shall monitor all ACM vaults, both for vault capacity and for vault performance.

The TCS shall deliver audible alerts to the DTR Fiscal Department staff in the Control Room when vaults are 50 percent full, 75 percent full and 100 percent full.

The TCS shall notify both the DTR Fiscal Department and the TCS Maintenance Provider when there is an ACM or vault performance issue.

The current ACM’s utilize either dual or quad vault systems which are generally located in the tunnel beneath the lane (for the mainline plaza) or within the ACM cabinet at ramp locations. The Contractor shall indicate in their Proposal the vault system, including vault quantity and capacity details.

Only one vault shall be active at any one time. The active vault shall secure all coins until a new vault is selected. Vault selection may be triggered automatically based on predetermined thresholds (weight or cash amount), manually at the lane (via the ACM) or remotely by supervisor staff or other designated staff (via the TCS).

Via output from the AVC subsystem, the lane shall record the number of axles and corresponding classification of each vehicle. The AVI (if applicable) classification, pre-class AVC, post-class AVC and collector classifications shall be compared in the audit of collector performance.

At the end of their tour of duty (TOD), toll collectors shall, via interface with the MLT, complete an end of Tour. This shall indicate to the System that the specific collector has completed their TOD and shall be reported accordingly to the Host.

2.4.1.2 UnattendedLaneUnattended lanes are limited to exact change payment via the ACM or by E-ZPass. In an Unattended lane, the patron deposits the fare into a coin basket. The coin basket delivers the coins to the ACM which authenticates and counts the coins, then verifies against the toll rate and corresponding classification as indicated by the pre-class AVC subsystem. If the motorist deposits a correct fare, after verification, the Island Traffic Light turns from red to green and the vehicle is allowed to exit the lane. The exiting vehicle is detected and classified by the post-class AVC.

In similar fashion to Attended mode the fare class is determined based on Airports Authority configurable business rules. Currently the E-ZPass fare class is determined by


Pg. 37

the AVI class on the transponder, unless the pre-class AVC indicates a different classification; in that case the pre-class AVC shall determine the E-ZPass fare class. For cash transactions in an unattended lane, the fare class is determined by the pre-class AVC subsystem.

The lane controller shall capture data from the ACM. This data shall be processed in the Host audit system where the vehicle class, expected payment and actual payment are tracked.

The TCS shall monitor all ACM vaults, both for vault capacity and for vault performance.

The TCS shall deliver audible alerts to the DTR Fiscal Department staff in the Control Room when vaults are 50 percent full, 75 percent full and 100 percent full.

The TCS shall notify both the DTR Fiscal Department and the TCS Maintenance Provider when there is an ACM or vault performance issue.

The current ACM’s utilize either dual or quad vault systems which are generally located in the tunnel beneath the lane (for the mainline plaza) or within the ACM cabinet at ramp locations. The Contractor shall indicate in their Proposal the vault system, including vault quantity and capacity details.

Only one vault shall be active at any one time. The active vault shall secure all coins until a new vault is selected. Vault selection may be triggered automatically based on predetermined thresholds (weight or cash amount), manually at the lane (via the ACM) or remotely by supervisor staff or other designated staff (via the TCS).

The VES cameras shall capture front and rear license plate images of toll violators when an unattended lane is operating in ACM/E-ZPass mode.

The transaction record shall contain all classes recorded for each transaction (pre-class AVC, post-class AVC and AVI if applicable).

2.4.1.3 E‐ZPassOnlyLaneAll DTR toll lanes shall be capable of being opened and operated in E-ZPass Only mode. In E-ZPass only lanes, the lane will be assigned a virtual collector ID used for the Tour of Duty (TOD’s) generated in the lane. The lane controller shall automatically create TODs for configurable time periods (e.g. every 8 hours to correspond with a collector shift or every 24 hours). The virtual collector ID shall be based on the lane number and plaza identification.

VES cameras will capture all front and rear license plate images of toll violators.

The VES cameras shall capture license plate images of all toll violators when a lane is operating in E-ZPass Only mode.


Pg. 38

Transaction records from conventional dedicated E-ZPass lanes shall contain all classes recorded (pre-class AVC, post-class AVC and AVI).

Transaction records from Express E-ZPass lanes shall contain the post-class AVC and AVI classes.

In conventional dedicated E-ZPass lanes, the E-ZPass fare class shall be determined by the AVI class on the transponder, unless the pre-class AVC indicates a different classification; in that case the pre-class AVC shall determine the E-ZPass fare class.

In Express E-ZPass lanes, the E-ZPass fare class shall be determined by the AVI class on the transponder, unless the post-class AVC indicates a different classification; in that case the post-class AVC shall determine the E-ZPass fare class.

2.4.2 DataExchangeBetweentheLaneControllerandHost

The lane controller shall receive data files and information updates from the Host in near real-time per applicable administrative rules for items including, collector ID tables, E-ZPass transponder status files, time stamp, and toll rate schedules. The Contractor shall incorporate file validation and error check functionality to ensure that corrupt or incorrect files are not used. The lane shall send data and information updates to Host in near real-time for items including collector log on and log off, transaction files, in-lane events, peripheral device status changes including vault switch and vault pull, and in-lane equipment diagnostic messages. The lane shall be able to receive and act upon the commands that are sent remotely from the Host workstations. These commands include opening and closing a lane remotely, changing lane modes/types, and resetting an improperly functioning lane.

Messages and file transfers shall use a TCP optimized for accurate delivery rather than timely delivery. The Contractor shall use asynchronous queue messaging to facilitate communications between all systems and applications. The Contractor shall also identify the means by which proper message transmission between the lane controllers and the Host is guaranteed. Contractors shall propose appropriate protocols and data structures to accomplish the communications required in this section, which shall be compatible with their existing products wherever appropriate. These protocols must be fully detailed in the system design by the Contractor and approved by the Airports Authority before system implementation. The Contractor shall propose appropriate status and diagnostic messages for review and approval by the Airports Authority.

All messages generated by the lane controllers shall be transmitted to the Host in near real-time and shall be guaranteed. All messages shall be uniquely identified and validation shall be performed at the Host to ensure that there are no missing or duplicate messages. The System shall support exception handling in accordance with the Airports Authority Business Rules approved during the Design phase. An alarm shall be generated and reported to the MOMS for all exceptions/errors.


Pg. 39

The Contractor shall provide an automated means of synchronizing the lane and Host messages in the event the lane controllers are replaced, if communications are down, or if data on the lane controller is not retrievable due to a catastrophic failure.

Transaction records shall be received from lane controllers, verified, and stored in a database. After successful verification and testing, transaction records shall remain in local storage in the lane controller until overwritten and in compliance with the stand alone data retention requirements.

2.4.3 E‐ZPassTransponderDatabase

The E-ZPass transponder database file maintains up-to-date account status information for all E-ZPass transponders (or tags). The database shall contain information for all tags activated within the E-ZPass Group with expansion for no less than 100 million transponders. The E-ZPass transponder database file, typically referred to as the ‘tag status file’, is provided by the VDOT E-ZPass CSC via FTP server. This file contains the E-ZPass transponder numbers and account statuses of all E-ZPass Group agencies. The TCS shall retrieve the new tag status files in accordance with the VDOT CSC Interface Control Documents (attached as Appendix B) and push this file to all DTR lane controllers in near real time. The Host shall store the tag status file in the format specified in the AVI Tag Status File Description contained in the VDOT CSC Interface control Document (attached as Appendix B). However, the lane controller shall store the tag status file in a format determined by the Contractor.

The following information shall be held by the System in the database for each transponder:

1. The 11 digit transponder serial number; 2. The account status. This shall have one of the following values:

a. Subscriber's account balance is above a defined low-balance threshold, valid (1);

b. Subscriber's account balance has reached the defined low-balance threshold, low- balance (2);

c. Subscriber's account has zero or negative balance, invalid (3); d. Transponder has been identified as lost or stolen, (4); e. Account has been provided as a non-revenue; and f. Provision for two (2) additional statuses, to be defined if required in future

by the Airports Authority.

In addition to non-revenue transponders issued by the VDOT E-ZPass CSC (agency code “010”), the Airports Authority issues a separate set of non-revenue transponders for DTR employees only. These transponders are not included in the tag status file transmitted by the E-ZPass CSC to the TCS Host, instead they are loaded directly from the Host into each lane controller as a separate white list of non-revenue transponders for DTR


Pg. 40

employees only. The Contractor shall continue to manage this unique list of DTR non-revenue transponders through the Host. The System shall create non-revenue transactions for vehicles using these transponders that shall be reported at the Host. The System shall not send any non-revenue transactions created by these unique DTR non-revenue transponders to the E-ZPass CSC.

2.4.4 ViolationDetection

The System shall detect all violation events that occur in the toll lane. Violation events shall include, but are not limited to, run-through vehicles with no transponder, run-through vehicles with a transponder with status other than Valid or Low Balance, and cash vehicles that have made a partial payment (underpayment). Any violation event detected by the System shall be immediately reported on the real-time monitor screen with all pertinent data included (e.g. plaza, lane, lane status, transaction ID, transaction time, vehicle class,). The collector shall take no action upon receipt of a toll violation alert from the TCS.

2.4.5 AutomaticVehicleIdentification(AVI)Subsystem

The Contractor shall provide a new AVI subsystem that is certified to be compliant with the E-ZPass Group requirements, including certified manufacturer (Kapsch) tuning and commissioning of the AVI equipment. The AVI system shall be able to read all transponders with E-ZPass protocols as well as additional transponder protocols in the future through the use of multi-protocol readers, to the accuracy specified in Section 2.14. The Contractor shall provide the latest version of Kapsch Janus® readers that have been certified and accepted by the E-ZPass Group. If the E-ZPass Group has not approved the use of a Kapsch Janus® multi-protocol reader at the time of this procurement, the Contractor shall design the TCS to be able to seamlessly upgrade to a Kapsch Janus® multi-protocol reader upon E-ZPass Group certification and approval with minimal modification to the TCS.

The Contractor shall be responsible for the placement, installation, physical tuning of the AVI equipment, integrating the AVI subsystem into the TCS Design, and maintenance of the AVI subsystem. The Contractor shall be responsible for synchronizing the AVI readers as required by the AVI manufacturer (Kapsch) during the transition from the legacy TCS to the new TCS as well as after full implementation of the new TCS. The Contractor shall utilize the Kapsch reader’s Master/Slave configuration and functionality to provide a highly redundant AVI solution. The Contractor shall furnish and install other cabling and associated equipment mounting fixtures necessary to provide a fully functioning AVI subsystem that meets the requirements of this project.

The AVI subsystem shall be able to read and report Transponders on vehicles traveling through any area of the toll lanes with no degradation of performance or interference. If more than one Transponder is present in a vehicle, the AVI subsystem shall have the


Pg. 41

ability to accurately detect that there are multiple transponders in the vehicle and shall not assign any of those transponders to another vehicle. The AVI subsystem shall have the ability to process Transponders mounted on vehicles traveling in stop and go, bumper-to-bumper traffic in a fully congested roadway (up to a minimum spacing of three feet) and on vehicles traveling at speeds up to 50 mph in Unattended and Attended lanes and speeds up to 100 mph in the Express E-ZPass lanes.

The AVI subsystem shall be capable of continuously performing diagnostics and reporting its health to the toll lane controller. The Contractor shall utilize the Kapsch Janus® reader’s built-in web-based interface that provides diagnostic capabilities for the Janus® reader. The Contractor shall provide access to this reader web-based interface through the TCS. Loss of communication to any element of the AVI subsystem shall be immediately detected and transmitted to the MOMS.

To support remote access to the AVI subsystem, the Contractor shall provide an interface so that software lane tuning, diagnostics, and other remote support shall be available to authorized personnel. Setup and configuration of the AVI subsystem shall be achieved remotely and shall not require lane closure except for major lane tuning such as any modification or adjustment that requires calibration or recalibration of the AVI read zone.

The AVI subsystem shall support read-write functionality.

The AVI subsystem shall detect the E-ZPass Group vehicle classification programmed on the transponder as defined in the E-ZPass Inter-Customer Service Center Interface File and Reporting Specifications and map those E-ZPass Group vehicle classes to the Airports Authority vehicle classes.

The AVI subsystem shall be capable of reading E-ZPass Flex transponders including the designated declaration or ‘switch’ position.

The Airports Authority desires the future capability to migrate to All Electronic Tolling (AET), which may potentially employ a different toll lane configuration in which toll booths and any physical lane separators (such as those present in the existing Express E-ZPass lanes) are removed to create a multi-lane, free-flow AET zone. The Contractor shall describe in their proposal how the proposed AVI Subsystem can accommodate the transition and or reconfiguration of existing lanes to multi-lane free-flow lanes.

The AVI subsystem shall accommodate configurable transponder time out functionality as well as filters for specific vehicle movements (e.g. u-turns and illegal movements) to prevent transactions from being rejected at the VDOT E-ZPass CSC. These filters may be at either the lane controller level or at the Host level and the Contractor shall work with the Airports Authority to define any such filters.


Pg. 42

The AVI subsystem shall meet the accuracies specified in Table 2-5: TCS Performance Requirements.

The DTR does not have any extra wide lanes and the Airports Authority does not require any shoulder coverage in any of the existing conventional toll lanes or Express E-ZPass lanes. However, if the Airports Authority migrates to AET in the future, the Contractor shall provide AVI coverage of the shoulder lanes in the AET toll zones.

2.4.6 AutomaticVehicleClassification(AVC)Subsystem

The Contractor shall be responsible for developing, testing and installing a new AVC subsystem that shall accurately detect, separate, and classify vehicles traveling in stop and go (“bumper-to-bumper”) traffic in a fully congested roadway and vehicles traveling at speeds up to 50 mph (100 mph in the Express E-ZPass Lanes), and accurately separate vehicles spaced as closely as three (3) feet apart.

For the conventional toll lanes (non Express E-ZPass) the Contractor shall provide both a pre-class AVC subsystem and a post-class AVC subsystem. The pre-class AVC subsystem is primarily required to support unattended lane usage (ACM or E-ZPass) where the pre-class classification will allow the lane system to determine the expected fare due and provide this information to the patron via the PFI. For the Express E-ZPass lanes only, the Contractor shall provide only a post-class AVC subsystem.

In the conventional toll lanes, the post-class AVC subsystem will continue to be used to provide an additional layer of accuracy by allowing for identification of classification mismatches between the AVI class, collector class, pre-class and post-class.

The Contractor may propose different AVC subsystems for conventional toll lanes and Express E-ZPass lanes.

The Airports Authority desires the future capability to migrate to All Electronic Tolling (AET), which typically uses a different toll lane configuration in which toll booths and any physical lane separators (such as those present in the existing Express E-ZPass lanes) are removed to create a multi-lane, free-flow AET zone. The Contractor shall describe in their proposal how the proposed AVC Subsystem can accommodate the transition and or reconfiguration of existing lanes to multi-lane free-flow lanes.

The Airports Authority recognizes that the current lane geometry may not allow for a complete pre- classification of longer commercial vehicles due to limited space and approach area. In the event that vehicle pre-classification cannot be achieved in an Unattended lane due to this limitation, the lane system shall calculate the fare due based on the actual number of axles detected by pre-class AVC subsystem (which may be less than the total number of axles) and display this amount on the PFI. The post-class AVC subsystem shall correctly capture the full classification of the vehicle and append the transaction with this information. If the vehicle does not pay the


Pg. 43

correct toll fare due (based on the posted toll rate schedule), the transaction will be marked as an underpayment and the VES subsystem shall capture front and rear license plate images and identify the transaction as a violation. In an Attended lane, the collector shall be able to adjust the classification for correct fare determination in the event the pre-class AVC subsystem cannot detect the total number of axles of a longer vehicle due to geometric constraints.

The system shall also be able to recover from instances of vehicles backing up through the lanes and this activity shall not impact the classification and detection of other vehicles in the lanes. The AVC subsystem shall detect the speed of the vehicle and report that to the toll lane controller as part of the vehicle transaction data.

The AVC subsystem shall have the ability to detect trailer hitches and ensure that vehicles with a tow are reported as one unit and are classified according to current Airports Authority toll rates and classification structures. The Contractor shall analyze the site conditions and provide an AVC subsystem that satisfies the functional and performance requirements set forth in this document.

The AVC subsystem shall provide vehicle event messages and signals, and classification data to the lane controller and or VES trigger. The AVC subsystem shall be capable of reporting its health to the lane controller and shall provide real-time or near real-time status to the MOMS. Loss of communication to any element of the AVC subsystem shall be immediately detected and transmitted to the Host and or be reported to the MOMS. The AVC subsystem shall have adequate redundancy whereby failure of a single sensor or device does not degrade lane operations or the System’s capability to accurately capture and process images.

The AVC subsystem shall meet the accuracy specified in Table 2-5: TCS Performance Requirements.

2.4.7 AutomaticCoinMachineRequirements

The Contractor shall fully replace each of the existing ACMs. The Contractor is not required to precisely replicate the current dual and quad vault configurations deployed. However the Contractor shall detail in their proposal the proposed use of dual and or quad vaults if different that the current configuration. The Contractor shall take into account the DTR’s use of quad vaults at certain locations allows for extended operations and reduced vault swaps by operations staff.

The ACM shall be designed for ease of patron use with clear and visible instructions.

Each ACM cabinet shall have a coin hopper mounted on the front to allow patrons or collectors to deposit coins. The design shall ensure that coin bounce is minimized so that coins can quickly enter the coin processor. The ACM shall be capable of detecting all forms of US coins including pennies, 50 cent pieces and dollar coins. All


Pg. 44

slugs, invalid coins, tokens, foreign coins, non-coin materials and other objects shall be rejected. The Contractor shall provide shop fabrication drawings showing the location of the rejected bin.

The TCS shall check to ensure that there is an active vault before a lane can be opened and prevent the lane from being opened if an active vault is not available. Each ACM shall be equipped with a vault housing keypad to allow authorized users to access the ACM. Before a vault can be removed, the authorized user must enter their ID and PIN that shall be validated against a table stored on the lane controller. Each vault shall be uniquely encoded that shall allow the lane controller to identify a vault and detect and record which vault is being removed or replaced. The status of the vault shall be recorded and displayed in real-time at the Host as information from the ACM is received (e.g. vault removed, vault active, vault inserted, etc.). Each vault shall have a status indicator with LEDs to indicate the status of each vault via different light colors (e.g. Green = In Use, Yellow = Available, Red = Full, Off = No Vault).

The ACM shall switch to a new vault when a calculated and or configurable weight threshold of the active vault reaches a preconfigured amount. The ACM shall also be instructed to switch vaults via a remote command from the Host. When all vaults are full, the ACM shall be disabled from collecting revenue and shall notify the DTR control room via an audible alert as well as the MOMS and the status be displayed on the real-time monitor. The PFI shall display the toll amount due based on the number of axles detected by the pre-class AVC subsystem. As coins are inserted into the ACM, the PFI shall show the decremented balance until the balance reaches zero.

The ACM shall include logic to associate the full payment with a vehicle in the event that the vehicle leaves the lane before all the coins are counted by the ACM.

The ACM cabinet shall be self-supporting and designed to withstand the usage and environmental conditions of a toll facility located in Virginia. The Contractor shall seek Airports Authority’s approval on all graphics, instructions and symbols that would be painted or placed on the ACM cabinets prior to preparing the cabinet. The Airports Authority shall also approve the paint colors before the ACM cabinets are painted.

The Contractor shall integrate each ACM to the specific lane controller and the ACM shall be controlled from both the ACM itself and the supervisor’s Host workstation in the DTR control room. The ACM shall report all operational activity including any malfunctions to the Lane Controller and to the MOMS.

The ACMs shall be capable of being serviced from the booth without closing the adjacent lane and shall provide for easy maintenance and access. The ACM cabinet shall be mounted securely and shall be removable without any demolition. The ACM cabinet shall be non-corrosive and tamperproof. The ACM shall meet the current toll industry standards for reliability, durability, availability and accuracy.


Pg. 45

2.4.8 AutomatedTollPaymentMachineRequirements(AlternateOption)

The Airports Authority is considering the future implementation of Automatic Toll Payment Machines (ATPMs) at selected locations on the DTR. The Airports Authority is not committing to the implementation of ATPM’s at this time however may execute this alternate option at a later date and time during the contract term.

As part of the base proposal the Contractor shall provide details and demonstrate the capability of providing an ATPM. In the even the Airports Authority does implement an ATPM solution the ATPM shall meet the functional requirements as stated below.

The ATPM shall be capable of being installed into the existing toll booth, toll lane and canopy structure with minimal structural modifications. The Contractor shall be responsible for any civil, electrical and structural related work related to the installation of ATPMs.

Vehicles using an ATPM lane shall be classified by the pre-class AVC subsystem, similar to the ACM lane. The TCS shall treat all underpayments as a toll violation and capture both front and rear license plates of a vehicle that makes a partial payment.

The ATPM shall include logic to associate the full payment with a vehicle in the event that the vehicle leaves the lane before all the coins are counted by the ATPM.

Vehicles with valid E-ZPass transponders that pass through an ATPM-equipped lane shall be processed by the AVI subsystem as an E-ZPass transaction.

At a minimum the ATPM shall meet the following requirements.

2.4.8.1 FunctionalRequirementsThe ATPM shall be designed to accommodate all types of automobiles, motorcycles and commercial vehicles with tractor trailer cabs of varying operator heights above the road.

The Contractor shall provide a design that supports a bill acceptor that is reachable by both high and low vehicles.

Bill acceptors shall permit four-way insertion (face side up or down from either direction)

Bill acceptors shall be configured to reject foreign and counterfeit bills.

Bill collection bins/stackers shall accept a minimum of one thousand (1,000) bills.

Bill acceptors shall report status (capacity levels), errors, and system faults and provide diagnostic capabilities.

Coin acceptor shall be installed at a level where it is reachable by patrons in either a high or a low vehicle. The Contractor shall offer as an option dual coin acceptors at


Pg. 46

both levels, upper and lower.

Credit card readers shall be installed where it is reachable by both high and low vehicles.

Credit cards shall be validated in near real-time with the Airports Authority’s Credit Card Processer.

Credit card transactions shall be completed in a reasonable amount of time to prevent long queues and facilitate vehicle throughput.

The Contractor shall be responsible for interfacing the System to the existing Airports Authority’s credit card payment processer.

Bill dispensers (if applicable) shall be installed at a level where it is reachable by both high and low vehicles. After a predetermined period of time, bill dispensers shall recover any bills that are not taken by the patron. Recovered bills shall be deposited into a separate bin/stacker.

Bill dispensers shall report alarms, system status, diagnostics and other pertinent information.

Coin dispenser shall be installed at a level where it is reachable by patrons in either a high or a low vehicle.

Receipt printers shall be installed at a level where it is reachable by patrons in either a high or a low vehicle.

The ATPM shall have the ability to switch vaults when they are full and send a status message indicating the switch to a notification table of personnel.

ATPM’s shall have a centrally-located graphics display for user instructions.

The ATPM shall have an intercom that facilitates two-way communication between the ATPM and the DTR Control Room whereby patrons that are experiencing issues using the ATPM can speak to the DTR toll operations staff.

All patron-accessible components shall be arranged in a logical, sequential order so as to simplify the operation of the ATPM for the patron (i.e. ticket acceptors, bill and coin acceptors, credit card acceptors, receipt printer and intercom).

In the event a bill dispenser is depleted, the ATPM shall attempt to provide change using the other available denominations.

In the event that the ATPM bill dispensers run low a system alert is sent to the TCS requesting service.


Pg. 47

The Contractor shall integrate each ATPM to the specific lane controller and the ATPM shall be controlled from both the ATPM itself and the supervisor’s Host workstation in the DTR control room. The ATPM shall report all operational activity including any malfunctions to the Lane Controller and to the MOMS. The MOMS shall monitor the general health, functionality and performance of the ATPM. All ATPM failures shall be reported through the MOMS and also to the DTR Control Room via audible alarms.

2.4.8.2 MechanicalRequirementsExterior of enclosure shall be vandal resistant and non-corrosive. The Contractor shall seek Airports Authority’s approval on all graphics, instructions and symbols that would be painted or placed on the ATPMs. The Airports Authority shall also approve the paint colors before the ATPMs are painted. The ATPM shall meet both the NEMA 4X and IP 66 standard specifications for equipment enclosures.

The ATPM shall be self-supporting and designed to withstand the usage and environmental conditions of a toll facility located in Virginia. Enclosure shall be weather-resistant; all openings shall be sealed and protected from water intrusion. All exterior indicator lights, buttons, phone speaker, etc. shall be vandal resistant.

All exterior graphics shall be fabricated from high-performance self-adhesive vinyl subject to Airports Authority approval.

Enclosure access door hinges shall be continuous stainless steel piano-type hinges. Door lock shall be barrel-type with removable core. Enclosure shall be installed with a “door open” switch.

Interior of ATPM shall be environmentally controlled. All air intakes shall be protected with replaceable air filters.

All internal components and wiring shall be installed so as to provide easy access for maintenance/repairs; cable management shall be provided.

All internal wiring, wiring blocks, connections shall be labeled.

Enclosure shall be installed with a 110 VAC service light.

The ATPMs shall be capable of being serviced from the booth without closing the adjacent lane and shall provide for easy maintenance and access. The ATPMs shall be mounted securely and shall be removable without any demolition.

The ATPM shall meet the current toll industry standards for reliability, durability, availability and accuracy.

2.4.8.3 ATPMFormsofPaymentThe ATPM shall accept all major credit cards via manual card swipe, chip (EMV -


Pg. 48

Europay, MasterCard and Visa) and near field communications (NFC) detection. EMV processing shall also accommodate the use of PIN entry by the patron.

The Contractor shall take measures to protect the credit card readers from potential skimming of credit card data. The Contractor shall describe these potential measures in their proposal.

The ATPM shall comply with all applicable credit card functionality standards such as the Payment Card Industry Data Security Standard (PCI DSS), the Payment Application Data Security Standard (PA-DSS) and EMV standards throughout the life of the contract.

The Contractor shall check the credit card readers on a routine basis to ensure that they continue to protect the Personal Identifiable Information (PII) of patrons using the ATPM. A plan for checking the card readers shall be included as part of the Maintenance Plan.

The ATPM shall accept the following US paper currency.

One dollar ($1) bills;

Five dollar ($5) bills;

Ten dollar ($10) bills;

Twenty dollar ($20) bills;

Fifty dollar ($50) bills; and

One hundred dollar ($100) bills.

The ATPM shall accept the following US coin currency:

Five cent (5¢) coins;

Ten cent (10¢) coins;

Twenty-five cent (25¢) coins;

Fifty cent (50¢) coins; and

One dollar ($1) coins.

The ATPM bill dispensers shall be capable of dispensing the following US currency:

Five dollar ($5) bills

One dollar ($1) coins;

Twenty-five cent (25¢) coins;

Ten cent (10¢) coins; and

Five cent (5¢) coins.

Credit cards shall be processed in accordance with the PCI requirements.


Pg. 49

All ATPM applications, inclusive of maintenance and diagnostics applications, shall seamlessly integrate with the new TCS and lane controller and Host.

All ATPM’s shall be capable of downloading or receiving configurable files or updates from the TCS interface.

2.4.8.4 RemoteOperation&MonitoringThe ATPM shall have the ability to be remotely operated via a TCS interface from the DTR control room.

ATPM status shall be monitored real-time via the TCS real-time overview.

The ATPM shall allow personnel with the appropriate Supervisor level to have remote access to assist the patron in completing a toll payment transaction.

2.4.8.5 ATPMServiceModeThe TCS shall have the ability to place the ATPM in “Service” mode at any time. Service mode may be used to accomplish such tasks as loading bill dispensers, vault changes/swaps, receipt paper replacement, etc. The ATPM shall have the ability to empty one denomination at a time so that the Supervisor could “bag” each denomination as it was dispensed to simplify counting the money.

2.4.8.6 MaintenanceModeThe ATPM shall provide a mechanism to securely recognize a valid technician (e.g. card swipe, proximity card reader, key pad, etc.) and change the ATPM mode to Maintenance. The ATPM will indicate Maintenance mode on the LCD display. The ATPM shall provide multiple diagnostic screens for troubleshooting the internal components individually. A menu display shall be available to display the status of the various components in a color-coded coded manner to indicate where a problem may lie. The ATPM shall be capable of printing out error codes and status on the receipt printer.

2.4.9 ViolationEnforcementSubsystem(VES)

The Contractor shall furnish and install all necessary VES hardware and software at the lane and Host levels required to support the violations processing requirements set forth in this document. The Contractor shall provide new VES equipment and software to support proper front and rear license plate image capture in all operating and weather conditions. Front and rear vehicle license plate images shall be captured, processed, stored and transferred in accordance with the DTR Business Rules to be developed during the Design phase and in accordance with all applicable laws, including Commonwealth of Virginia laws and legislation, the interface specification requirements of the E-ZPass CSC and VPC, and the business rules of the Airports Authority. The Contractor shall propose a license plate image capture camera type that they can properly integrate into the VES subsystem and TCS to meet the


Pg. 50

performance requirements specified in Table 2-5: TCS Performance Requirements.

The Contractor shall design the VES to be scalable, adaptable and capable of processing a higher volume of license plate images in the event the Airports Authority transitions to All Electronic Tolling (AET) at some point in the future.

The VES shall capture and process vehicles traveling through the toll lanes as follows:

Stop and go traffic “Bumper-to-bumper” traffic For all vehicle classes Vehicles traveling at speeds up to 50 mph (100 mph in the Express E-ZPass lanes) Vehicles with separation as close as three (3) feet apart Vehicles positioned at the extreme edges of the lane

The VES shall be capable of buffering images (retaining an image until its disposition is known) such that no image is lost in order to support multiple vehicles in the lane and Airports Authority Business Rules.

The Contractor shall furnish, and install all cameras, lighting, VES triggers, and necessary functionality to automatically adjust and accommodate varying light and weather conditions to maintain adequate brightness and contrast settings, with or without traffic, to ensure optimum license plate information capture under all conditions and time of day. Lights furnished and installed in support of VES cameras shall not distract motorists traveling in either direction in the lanes nor pose a nuisance to the surrounding communities.

The Contractor shall identify their VES power loads and data transmission needs in their proposal.

The Contractor may propose high resolution color cameras or high resolution black and white cameras; near-infrared cameras may not be used.

The VES shall be capable of capturing, processing, storing and transferring full (uncompressed) images, the Region of Interest (ROI) or both as determined during the Design phase and in accordance with all applicable Commonwealth of Virginia legislation and the business rules of the Airports Authority. VES images shall not contain any portion of vehicle occupants.

The Contractor shall provide the necessary controllers/servers to support the in-lane VES equipment and functionality. The processor speed and memory shall be sufficient to process vehicles/images in real-time to meet the speed and traffic volumes as specified in this document. The VES subsystem shall support standalone operations and the storage media shall be sized to hold a minimum of thirty (30) days of images and associated transaction data per lane at each of the tolling locations under normal


Pg. 51

operating conditions.

The VES subsystem shall be capable of maintaining performance levels with no degradation under conditions where every vehicle transaction may be processed as a violation (i.e. 100% violations). Under these conditions the VES subsystem shall be capable of storing images for a minimum of seven (7) consecutive days per lane. The System shall be configurable to be set for processing of 100% violations. The VES controllers/servers shall have sufficient redundancy such that failure of a processor, board, power supply, disk or other critical unit does not result in loss of violation images and/or data. Each violation transaction shall be associated with the correct violation image captured by the in-lane VES cameras and then transmitted onto a VES Server at the Host and finally to the Violations Processing Center (VPC). The VES software shall use a naming scheme that identifies whether the image is a front or a rear image as well as a unique identifier to correlate each violation transaction to the appropriate front and rear image.

In the event communications to the VES controller/server is lost or the VES controller/server becomes non-operational, the Contractor design shall ensure that no images are lost. The VES shall be capable of continuously performing diagnostics and reporting its health to the MOMS. Loss of communication to any element of the VES shall be immediately detected and reported to the MOMS.

The VES subsystem shall meet the accuracy specified in Table 2-5: TCS Performance Requirements.

2.4.9.1 OpticalCharacterRecognitionThe Contractor shall include Optical Character Recognition (OCR) functionality as part of the new TCS. OCR functionality shall be performed for all violation transaction images captured from the lane and return the following values:

license plate character information; OCR determined Confidence level; OCR determined U.S. plate jurisdiction; OCR determined jurisdiction plate type;

It is anticipated that the OCR engine shall be trained for the following states:

Virginia* Maryland* District of Columbia* Delaware New Jersey New York Pennsylvania


Pg. 52

West Virginia North Carolina South Carolina Georgia Florida Connecticut Massachusetts New Hampshire Maine

*Subject to the accuracy specified in Table 2-5: TCS Performance Requirements.

The OCR subsystem shall process all vehicle images through one (1) or multiple OCR engines.

The OCR engine shall produce a plate number, plate type, and plate jurisdiction of issue for each license plate image when an OCR value is returned.

The OCR subsystem can be located at either the lane level or the Host level.

The Host shall include VES audit functionality to enable Airports Authority staff to view the results of the OCR process. Additionally the Contractor shall include in their monthly reporting to the Airports Authority statistics on the overall performance of the OCR subsystem identifying areas of degradation, improvement or other concerns.

The OCR subsystem shall initially meet the accuracy specified in Table 2-5: TCS Performance Requirements for the indicated states above. The OCR subsystem shall also be capable of increasing, or adding additional states to also meet the Performance Requirements. The Contract shall identify in their proposal the process and capability of the OCR subsystem to accommodate this change.

2.4.10 LaneController

The lane controller shall process all of the data obtained from the various lane subsystems to generate a transaction record for each vehicle that passes through the toll lane. The lane controller shall:

1. Maintain the transponder status list used to validate the status of a transponder received from the AVI subsystem.

2. Obtain the toll rate and schedule data from the Host and determine the toll rate to be charged to each transaction. Determination of the toll fare shall be performed at the lane controller.

3. Use the data obtained from the AVI subsystem and AVC subsystem(s) to assign the transponder read and classification to the correct vehicle.


Pg. 53

4. Notify the VES to save and process vehicle images if the vehicle is flagged as a violation (unauthorized run-throughs and underpayments).

5. Indicate the transmission status of the transaction recorded. 6. Transmit the transaction record with vehicle detection data, classification data,

transponder data, collector input data, ACM data, ATPM data and all other pertinent information regarding the vehicle to the Host.

7. Transmit the violation images and data to the VES server for further processing. 8. Transmit to the MOMS all alarm messages relating to the health of each

subsystem, including the health of the lane controller. 9. Accept buffered reads from the AVI subsystem.

The lane controller software shall be configurable and able to support the Airports Authority’s operational needs without requiring changes to software. All configurable parameters shall be presented via a graphical table for easy viewing and updating by the system administrator through the appropriate application software module. The configurable parameters shall be further defined during the design process.

The Contractor shall propose appropriate protocols and data structures to accomplish the communications required between various components and peripherals. The Contractor shall utilize web services, industry standard IT architecture and NTCIP protocols, where applicable, in the system architecture, communications systems and interfaces. These protocols and data structures shall be fully detailed by the Contractor during the design process and approved by the Airports Authority prior to System Implementation. All files and messages between the lane controller, VES, AVI, AVC subsystems and Host shall utilize a guaranteed transmission protocol.

The lane controller shall meet the accuracy specified in Table 2-5: TCS Performance Requirements.

The lane controller application software shall support all lane functions required to meet the Airports Authority’s operational requirements. These functions are further detailed in the following sections:

2.4.10.1 LaneControllerStart‐UpUpon start-up or initialization, the lane controller shall perform a self-diagnostics test to ensure full system operations. Alarm messages shall be reported for all failure conditions and a notification of the diagnostic check completion shall be displayed on the MOMS monitoring screen. The lanes shall not be prevented from start-up and opening as long as all critical subsystems as defined by the Airports Authority are operational. The failure of a critical subsystem shall result in the toll lane operating under degraded operations in accordance with the Business Rules developed during the design phase.

Upon boot-up, the lane controller shall verify with the Host that it has the latest configuration files, application software, transponder status file, employee/user file, toll


Pg. 54

rates and schedules, and any other files required to support the lane operations. If the latest files are not present on the lane controller, it shall request the latest data from the Host. The lane controller upon start-up shall also synchronize its time with the Host.

2.4.10.2 TransactionProcessingThe lane controller shall detect, classify, frame, correlate transponder reads and VES images for the correct vehicle. The detailed transaction processing rules and the transaction message details shall be defined during the design phase by the Contractor and the Airports Authority and approved by the Airports Authority; however, the following basic rules apply:

1. Each vehicle that passes through the toll lane shall be processed and reported as a transaction.

2. The System shall have the ability to process multiple transponders in a vehicle and report each transponder.

3. All transponder reads shall be recorded and included in the transaction record. 4. One transaction shall be created for each vehicle that travels through the tolling

location and the lane controller shall ensure that the transaction is complete prior to transmitting it.

5. The lane controller shall ensure that duplicate AVI transactions (same Transponder ID) are not reported from the same lane within a configurable period of time.

6. Buffered Transponder Reads that are transmitted to the lane controller shall not be assigned to a vehicle by the lane controller but shall be flagged and reported to Host for further processing and vehicle assignment.

7. The lane controller shall automatically synchronize with the various subsystems to ensure the events in the lane correspond to the transaction generated.

8. Each transaction shall contain and be reported with various event times including ‘pre-class AVC vehicle entry’ time, ‘post-class AVC vehicle exit’ time and ‘Transponder read’ time that shall allow Transponder reads, VES images and DVAS video to be associated correctly with the vehicle.

9. The lane system shall also be designed to prevent the creation of a violation transaction due to delayed coin processing by the ACM. (the vehicle exits the lane before all coins are counted and a violation occurs)

2.4.10.3 FareClassThe TCS shall provide the necessary information to assign a fare class (as structured under the current system) to each transaction. The following rules shall be considered as part of the overall Business Rules during the TCS design:

1. Cash/Exact Change/E-ZPass Transactions


Pg. 55

a. For Attended Lanes, the class and expected fare shall be determined by the pre-class AVC or by the collector reclassification in the lane. The post-class AVC classification shall also be included in the transaction.

b. For Unattended lanes, the class and expected fare shall be determined by the pre-class AVC for cash transactions. For E-ZPass transactions, the class and expected fare shall be determined by the AVI transponder class, unless the transponder class differs from the pre-class AVC. In that case the pre-class AVC classification shall be used instead. The post-class AVC classification shall also be included in the transaction. If the pre-class AVC system is not operational and no AVI (Transponder) class is identified, the default class for the transaction will be Class 2 per the plaza or ramp fare (configurable).

c. For Unattended lanes, transactions with 0 or 1 axle shall default to Class 2 per the plaza/ramp fare (configurable). The TCS shall flag the transaction and all data shall be retained.

2. Express E-ZPass Lane Transactions a. If the AVC subsystem is not operational and no AVI (Transponder) class is

identified, the default class for the transaction will be Class 2 per the plaza or ramp fare (configurable).

b. Transactions with 0 or 1 axle shall default to Class 2 per the plaza/ramp fare (configurable) if no AVI (Transponder) class is detected. The TCS shall flag the transaction and all data shall be retained.

3. Violations (non-payments in the lane) a. If the AVC subsystem is not operational, the default class for the

transaction will be Class 2 per the plaza/ramp fare (configurable). b. Transactions with 0 or 1 axle shall default to Class 2 per the plaza fare

(configurable). The TCS shall flag the transaction and all data shall be retained.

2.4.10.4 SavingofImagesVES images shall be saved at both the lane and Host levels. VES images shall be retained in accordance with the data retention requirements as set forth in Section 2.5.26.6.

The TCS shall also have the ability of assigning a violation type or category when saving images such as ACM underpayment, unauthorized run-throughs, etc. The System shall be capable of being configured by Airports Authority staff to filter specific violation types at the Host level and prevent them from being transmitted to the VPC. During the design process the Contractor shall work with the Airports Authority in defining the violation types/categories.


Pg. 56

2.4.10.5 ConfigurationFilesAll parameters and settings required to run the lane controller application shall be maintained in configuration files. Access to configuration files required to support the lane controller shall be limited to authorized personnel.

The configuration files may be maintained on the Host server or downloaded along with the lane controller application file; however, authorized personnel shall be able to make changes to the configuration files in the field as approved by the Airports Authority. The TCS shall record a log of the authorized personnel that access each lane controller to make modifications as well as record the configuration files that are modified. All lane controllers shall have default configuration files that shall allow the lane to start-up automatically. Authorized personnel shall be able to make changes to parameters and settings that are defined as configurable as identified in this document and in the approved Detail Design Documents.

A method shall be developed such that the presence of outdated configuration files and software versions is detected and reported to the MOMS.

2.4.10.6 InterfacetoAVISubsystemThe lane controller shall interface with the AVI subsystem and accept all data received from the AVI subsystem. The lane controller shall report all tag reads; the details of the data format shall be confirmed during the design phase by the Contractor and the Airports Authority and approved by the Airports Authority. The Contractor shall be responsible for ensuring that all data elements required by the E-ZPass CSC to meet Airports Authority operational requirements and E-ZPass Group interoperability requirements are provided in the transaction.

2.4.10.7 InterfacetoAVCSubsystemsThe lane controller shall interface with the AVC subsystems to obtain vehicle events that shall permit accurate detection, classification, tracking and processing of vehicles.

2.4.10.8 InterfacetoVESSubsystemThe lane controller shall interface with the VES subsystem to capture and process images of vehicles identified as violators in accordance with the Business Rules to be reviewed and confirmed during the Design phase by the Contractor and the Airports Authority. Vehicle data and images obtained from the VES subsystem and transmitted to the VPC shall support the Airports Authority’s violation processing and VPC data format requirements.

2.4.10.9 InterfacetoMOMSAll alarm and equipment/process health messages generated by the lane controllers shall be transmitted to the MOMS in real-time and shall be guaranteed. All messages shall be uniquely identified and validation shall be performed to ensure that there are no missing or duplicate messages. The MOMS shall automatically detect the failure of


Pg. 57

any equipment including but not limited to such items as lane controller, AVC subsystems and components, AVI subsystem and components, DVAS subsystem and components, Plaza and Host, workstations, UPS, etc.).

2.4.10.10 InterfacetoACMsandATPMsThe lane controller shall capture data from the ACM and the ATPM. This data shall be processed in the Host audit system where the vehicle class, expected payment and actual payment are tracked.

2.4.10.11 InterfacetoPatronFeedbackDevicesThe lane controller shall provide input to the patron feedback devices such as the patron fare display and the island status signal.

2.4.10.12 InterfacetoCommunicationsDevicesThe lane controller shall interface with the various network communications devices to transmit and receive data between the lane controller, the Host and all external devices and subsystems.

2.4.10.13 ReceivingDataThe lane controllers shall receive files and tables from the Host. Receipt of all files and data shall be verified and acknowledged and any failures in the transmission shall be reported to the MOMS.

Transponder (Tag) Status File: The lane controller shall support the E-ZPass Tag Status File. The lane controller shall accept comprehensive (complete list once a day) and incremental (changes updated on a configurable interval, but not less than every 15 minutes) tag status files and shall activate the files upon receipt after validation of the files. The Contractor shall use an effective design to transmit the files (compress, encode, and transmit), store the files and use the files such that the new file is available at the lane controllers within 10 minutes of the applicable Host obtaining the new list. Transponder validation shall occur in no greater than 50 milliseconds. Any exceptions to this requirement shall be clearly explained and detailed in the Contractor’s proposal. The format of the file shall be defined during the design phase by the Contractor and the Airports Authority and approved by the Airports Authority.

DTR Employee Non-Revenue Transponder (Tag) Status File: The lane controller shall support the DTR Employee Non-Revenue Tag Status File. The lane controller shall accept comprehensive (once per day) and incremental DTR employee non-revenue tag status files (changes updated in near real-time) and shall activate the files upon receipt after validation of the files. The Contractor shall use an effective design to transmit the files (compress, encode, and transmit), store the files and use the files such that the new file is available at the lane


Pg. 58

controllers in near real-time of the applicable Host providing the new list. Transponder validation shall occur in no greater than 50 milliseconds. All exceptions to this requirement shall be clearly explained and detailed in the Contractor’s proposal and identified on an Exceptions and Clarifications form. The format of the file shall be defined during the design phase by the Contractor and the Airports Authority and approved by the Airports Authority.

Toll Rates and Schedules: The toll rates are based on vehicle class and tolling location. The toll rates schedules and the effective time shall be downloaded automatically to the lane controller (if applicable) when the toll rate structure changes. The System shall permit the Airports Authority to schedule toll rate and schedules changes in advance of the new rates becoming effective. The System shall also be capable of implementing value-based pricing that varies by time of day, day of the week, and holiday.

Employee File: The lane controller shall accept employee status files from the Host. Employee files shall be pushed to the lanes upon any update or change to the file.

Configuration Files: All configuration files and tables needed to support the lane operations shall be downloaded to the lane controllers from the Host upon confirmed change or at scheduled intervals and activated as required. Versions of the configurable files on each lane controller shall be maintained, tracked, and recorded.

Software Download: All lane controller software shall be downloaded to the lane controllers from the Host and versions on each lane controller shall be maintained, tracked, and recorded.

2.4.10.14 TransmittingDataThe lane controller shall transmit the toll collection data to the Host including but not limited to those identified below.

1. All transaction messages generated in the lanes. 2. All alarm and status messages generated in the lanes. 3. All lane operational messages, communication status messages and self-health

messages (e.g. collector log on, collector log off, vault switch, vault pull, lane open, lane close).

4. All events generated in the lanes that are displayed on the real-time monitor or are required at the Host.

All messages shall be confirmed as received by the Host before they are flagged for archiving. In the event of communication failures the messages shall be stored on the


Pg. 59

lane controller until successful transmission is complete and verified. The exception handling process shall be instituted in accordance with the Business Rules approved during the Design phase and all failed transactions shall be identified and reported. Any exceptions or failure shall result in the creation of an alarm that is reported to the MOMS.

2.4.10.15 MonitorAllLaneEquipmentforDeviceStatusAll lane controllers shall be monitored by the MOMS. In addition, each lane controller shall monitor itself, associated in-lane equipment and subsystems for status. All subsystems including AVI, AVC, VES, LSS, DVAS and shall be continually polled (once per minute or frequency to be recommended by the Contractor and approved by the Airports Authority) for status. The health of digital devices may be inferred from events. If a device recovers after reporting a failure, then a recovery message shall be generated and the device operational status restored. The MOMS shall determine if it has lost communication with the lane controller, and generate an alarm message if communication is unavailable. All alarm, health and recovery messages shall be transmitted to the applicable servers and reported to the MOMS and the real-time monitor screen. Any lane out-of-synch conditions shall be detected, reported to MOMS and displayed on the real-time monitor screen.

2.4.10.16 DiagnosticsandEquipmentMalfunctionThe lane controller software shall execute periodic diagnostic checks on in-lane equipment. Intelligent peripheral devices shall be interrogated for device status on a regular basis. A device's failure to respond to a status inquiry, after a configurable number of retries shall be regarded by the lane controller software as an equipment failure. In the event of this failure a message shall be sent to the MOMS. Such tests shall take place in all modes of lane operation, and the results shall be placed in each lane controller's event log.

Degraded modes of operation shall be supported based on Business Rules developed during the design process. The Contractor shall ensure the TCS continues to operate without loss of revenue or visible impact to the patron in accordance with the degraded mode operations agreed to during the design phase by the Contractor and the Airports Authority in the event that certain designated components of the TCS fail.

2.4.10.17 TimeSynchronizationAll lane controllers shall be synchronized either to the Host as a primary source or to a common time synchronization source described in Section 2.5.12. There shall be a second source for time synchronization if communication to the primary source is down. The software used for time synchronization shall support monotonic changes to time. The lane controller shall synchronize or transmit time synchronization messages with every device in the lane capable of maintaining time. The TCS shall provide alarms to


Pg. 60

the DTR Control Room and the MOMS if there are time synchronization or time lag issues among the various TCS subsystems and components.

2.4.10.18 TollCollectorTerminalandRelatedEquipment

2.4.10.18.1 ManualLaneTerminalAs is currently functioning, the Manual Lane Terminal (MLT) interface shall facilitate and support all toll collection operations and functions in the attended lanes. The Contractor shall provide new MLTs for each attended lane. Toll collectors shall use the touch-screen feature on the MLT to navigate through the various menus and screens. The user interface shall provide a clear feedback to the user to acknowledge user input.

MLTs shall be of the touch screen type. Touch screens shall be designed to operate in the harsh environmental climate existing at the mainline plaza and ramps, meeting at least NEMA 4/12 (IP64) standard to be water/oil and dust proof. Touch screens shall be of a type such that toll collectors either wearing gloves or not wearing gloves shall be able to activate the screen.

The MLT shall be designed to fit on the toll booth counter. It shall be designed in a manner to allow the collector to adjust the height, tilt and pivot based on individual user preferences.

All displays shall be specially treated to eliminate glare. The color and brightness of the display shall be adjustable and permit viewing under high and low ambient light conditions. If necessary, the Contractor shall provide a shade for the top of the touch screen.

The interface shall be user-friendly and shall be designed to minimize Repetitive Motion Injuries (RMI) that could result from repeated use of the terminals. The buttons on layered screens shall be positioned in such a way so as to avoid accidental inputs.

The Contractor shall propose appropriate layout and design for the MLT menus and screens for review and approval by the Airports Authority during the design process.

2.4.10.18.2 ReceiptPrinterThe Contractor shall provide new receipt printers for each toll collector terminal. Each toll collector terminal shall be equipped with an industrial-quality, thermal receipt printer, which shall be a separate unit from the toll collector terminal.

The printer shall print a receipt only at the request of the toll collector after any valid cash transaction. Only one receipt shall be provided for each successfully completed transaction. Receipts shall not be provided, even upon request of the toll collector, for E-ZPass transactions. Convoy receipts shall be produced for the first vehicle in the convoy.


Pg. 61

Basic transaction data will be included on the receipt, such as the facility name, location, lane number, date, time, vehicle class, collector ID, and amount of toll due and the toll was paid.

The TCS shall also have the ability to produce a print out from the receipt printer with up to 5 pre-defined messages such as directions, E-ZPass information, etc. These messages shall be configurable by DTR staff.

The freestanding receipt printer unit shall be located on the counter of the tollbooth, next to the toll collector terminal, and designed to fit such space. It shall be designed in such a manner as to allow nontechnical personnel to physically exchange the entire unit in case of failure.

The receipt printer shall also be designed to allow the toll collectors to easily replace receipt printer paper without affecting normal operation in the toll lane, and without the use of tools.

The receipt printer shall detect jams and low paper conditions and report all such statuses to the lane controller and the MOMS.

Receipt design shall be submitted by the Contractor during the design period for the review and approval by the Airports Authority. The receipt paper shall be of standard COTS and easily obtainable.

Connection point(s) to receipt printer shall be clearly labeled by permanent printing or etching. Connection point(s) to the receipt printer shall be unique and shall be keyed to avoid misalignment of printer cable(s).

2.4.10.18.3 CanopyOverrideSwitchThere is an existing canopy override switch in each lane. The purpose of this switch is to allow authorized staff to manually override that canopy lane status. The override switch is not currently integrated with the TCS and the Contractor shall not be required to do so. It however shall be maintained throughout the course of the contract and subsequent maintenance term(s).

2.4.11 Intercom

A new intercom system shall be provided as part of the TCS to accommodate both patron and collection staff communication between the toll lanes and the DTR control room.

All calls shall be directed back to the DTR control room for plaza operations staff to address.

The communication intercom system shall utilize voice over IP protocols.


Pg. 62

For any lanes capable of operating in Unattended mode (ACM/E-ZPass) remote intercom call stations shall be furnished for patron use. Intercoms shall be located so that they can be easily accessed from an open window of standard passenger vehicle. Intercoms shall include “Press for Assistance” or similar placards and visual verification that assistance has been requested, and that assistance has been dispatched.

Additionally for Attended lanes intercom call stations shall also be provided for collection staff to communicate directly with the mainline plaza operations office.

Intercom system shall comply with current Americans with Disabilities Act requirements.

The entire intercom system shall operate without malfunction due to climate conditions stated herein.

2.4.12 LaneStatusSign

2.4.12.1 LSSFunctionalRequirementsThe Contractor shall furnish a new NTCIP compliant lane status sign (LSS) system that will be integrated and controlled by the TCS. The LSS signs shall be sized to be mounted above each of the 57 toll lanes of the mainline and ramp toll plazas. The LSS will be capable of displaying alphanumeric characters and graphics in multiple colors stored as pre-programmed messages. The LSS shall provide information messages to the motorists to indicate the status of the toll lane. The LSS shall support messages to indicate all toll lane types which include E-ZPass Only, Unattended (exact change) and Attended.

The Contractor shall inspect all tolling locations and obtain detailed information in order to determine how to mount signs to existing sign structures and toll canopies. The Contractor shall engage the services of a structural engineer licensed in the Commonwealth of Virginia to perform structural calculations to determine if the support structures will adequately support the LSSs and meet a related requirements and codes.

2.4.12.2 LSSTechnicalRequirements

2.4.12.2.1 SignMountingHardwareThe Contractor shall be responsible for designing, procuring, fabricating, installing, testing and maintaining all hardware necessary to ensure the sign is securely mounted, including the sign mounting beams, vertical and horizontal brackets.

The Contractor shall be responsible for the LSS housing, structural framing, face covering, mounting members, and any other component necessary to ensure that the TRS is designed to withstand a wind velocity of 100 mph with a thirty (30) percent gust factor and shall otherwise comply with the latest requirements of AASHTO’s Standard Specifications for Structural Supports for Highway Signs, Luminaires and Traffic Signals.


Pg. 63

The Contractor shall identify the power loads required to operate the LSS and the communications needs required to integrate the LSS with the System in their proposal.

The Contractor shall comply with all applicable Airports Authority’s design and installation requirements set forth in the Airport Authority’s Design Manual, which can be found on the Airports Authority’s website at http://www.mwaa.com/business/airports-authority-design-manual .

2.4.12.2.2 LaneStatusSignDisplayThe sign display shall be a high-contrast full-matrix configuration of pixels supporting a 70-degree viewing cone with a minimum character height of 6-inches. Each LSS display matrix shall be full-color. The pixel matrix shall display alphanumeric character fonts measuring a minimum of six (6) inches high to a maximum of the display matrix height.

The LSS shall be able to display messages composed of any combination of alphanumeric text, punctuation symbols, and graphic images across multiple frames. The LSS shall display a minimum of 3 lines of 8 character text assuming a minimum character height of 6-inches.

LSS messages shall be legible within a distance range of seventy-five (75) feet to 1000 feet from the LSS display face under the following conditions:

1. Whenever the LSS is displaying alphanumeric text that is at least six (6) inches high.

2. Twenty-four (24) hours per day and in most normally encountered weather conditions in the Metro Washington DC-Baltimore Area.

3. During dawn and dusk hours when sunlight is shining directly on the display face or when the sun is directly behind (silhouetting) the LSS.

4. The LSS shall return to a default message displayed upon restoration of power (following a power outage). The message shall be fully displayed and operational a maximum of thirty (30) seconds from the time power has been restored.

2.4.12.2.3 LaneStatusSignControlSystemThe LSS control system shall include all conduit, wiring, and hardware associated with providing power and communication between the local control cabinet and each sign. The Contractor shall include software or hardware to ensure the LSS is fully compatible with the TCS and completely capable of being operated by DTR toll operations staff.

The LSS sign controller shall be able to receive instructions from and provide information to a computer or device containing LSS control software using the following communication modes:


Pg. 64

1. Locally-Via Ethernet TCP/IP communications as part of the TCS network 2. Remotely-Via Ethernet TCP/IP communications 3. Locally-Via a direct connection using CAT6 communication cable from each LSS

to the controller interface. Communications between the LSS controller and all control software throughout the LSS System shall meet all applicable NTCIP requirements. The Contractor shall provide all of the software, firmware, and services necessary to operate a LSS System that fully complies with the NTCIP requirements.

2.4.12.2.4 DiagnosticandStatusInformationThe LSS system shall provide LSS operational status, as well as the functional status of major LSS components and LSS sign controller communications. Status information shall be reportable to the TCS via the LSS control software. This shall minimally include the following information:

1. Sign Name/Location 2. Sign Controller Communications- As “Normal” or “Failed.” 3. Message Display Status - As {name of message being displayed} or “Blank

Message.” 4. LED Intensity Level - The percentage of the maximum brightness at which the LED

display is currently operating, whether the intensity control is in automatic or manual mode.

5. LED Intensity Level Control Method – As “Automatic” or “Manual.”

2.4.13 PatronFareIndicator(PFI)

The Contractor shall provide new Patron Fare Indicators (PFIs). The PFI provides feedback to patrons as they are processed in the lane related to fare paid, balance due, etc.

The PFI shall be provided and installed in the conventional toll lanes, replacing the existing PFI. The existing PFI is located above the ACM basket mounted to the booth in Attended lanes. In Unattended lanes (ACM only) the PFI is located above the coin basket on the ACM cabinet. There is no PFI in the E-ZPass only lanes.

The PFI shall display a minimum of at least 1 line, 6 alphanumeric characters at 4 inches high.

The PFI shall display messages such as E-ZPass Paid, Call E-ZPass, Credit Card Paid, Cash Paid and Thank You. The Contractor shall work with the Airports Authority to define the various messages that will be displayed on the PFI.

2.4.13.1 IslandTrafficLight


Pg. 65

The Contractor may reuse the existing Island Traffic Lights (ITLs) continue to be utilized. The current ITL is comprised of a three (3) lens (Red, Yellow and Green) typical traffic light. The ITL is pedestal mounted at the downstream end of the island. The lane controller shall control the appropriate lens illumination based on the following basic business rules in Table 2-2: ITL Signals.

Table 2-2: ITL Signals

LANE MODE EVENT ITL SIGNAL

Open

No vehicle or awaiting payment Blank

Fare Paid (Cash, Credit Card or E-ZPass) Green

No payment, underpayment, invalid E-ZPass

Red

Low Balance E-ZPass Yellow Closed Blank

Special Events Green Maintenance Blank

During the design process the Contractor shall work with the Airports Authority to refine, if necessary, the business rules regarding light indication for each of the lane mode types.

2.4.14 CanopyLights

The Contractor may reuse the existing Canopy Lights. The Canopy Lights are mounted overhead of each lane on the upstream gantry in front of the plaza canopy.

The purpose of the Canopy Light is to inform oncoming traffic of whether a lane is open or closed. The Contractor shall integrate the new TCS with the existing Canopy Lights so that they are primarily controlled by the lane controller based on lane status. Additionally the Canopy Lights shall have a physical override switch which allows the Canopy Light to be switched to red in the event of an emergency.

2.4.15 EquipmentEnclosures

All new proposed enclosures shall be subject to the approval of the Airports Authority and compliant with all UL and NEMA standards.

Existing equipment enclosures may be reused at the discretion of the Contractor. During the Pre-proposal and site visit the Contractor shall inspect the existing equipment enclosures and validate the potential for re-use. The re-use of any existing enclosure shall not waive the Contractor of meeting the requirements of this project.


Pg. 66

Any heating and cooling of the equipment cabinets and enclosures required to meet the TCS operational and performance requirements shall be the responsibility of the Contractor.

The Contractor shall provide locks for the equipment enclosures and shall coordinate with the DTR Operations Staff.

The Airports Authority does not require any video based access detection systems when an enclosure is opened.

The Contractor shall coordinate with the Airports Authority on the placement of AVI cabinets.

The Contractor shall ensure that all equipment necessary for the proper collection of toll revenue shall be on UPS power.

2.5 HostRequirements

2.5.1 GeneralRequirements

The TCS shall be administered and controlled by a new Host System that performs the following functions at a minimum:

Management of User Access Privileges Toll Rate/Schedule Management Transactional Audit and Reconciliation Financial Audit and Reconciliation Report Generation Real-Time Monitoring Violation Enforcement System (VES) interface (if separate) Maintenance Online Management (MOMS) interface (if separate) Digital Video Audit System (DVAS) interface (if separate) Data backup, Restoration and Archival Tag Status File Management Interface to E-ZPass CSC Interface to VPC Interface to Toll Lane Controllers Collector Functions and Audit ACM Vault Functionality DTR Employee Non-Revenue Transponder White List Special Events Management Interface to General Ledger

The Contractor shall provide the software and hardware needed to support Host System requirements specified herein. All transactions, images and messages


Pg. 67

transferred between all subsystems shall have the required data validation protocols to confirm the accuracy and validity of data transfer.

The interaction and common architecture between applications should be flexible, agile, scalable and robust. The interaction between applications and system components shall be based on an open architecture that is decoupled, flexible, agile, scalable and robust. It is preferred that the System software uses non-proprietary open-standards Application Programming Interfaces (APIs) that are maintained by the software vendor and enables use of or includes an industry standard Enterprise Service Bus (ESB).

All System applications shall be internet browser-based.

2.5.2 TollRateStructure

The System shall support differential toll rate structures for E-ZPass and cash. The System shall also support configurable rate programs including but not limited to commuter programs and discount programs, allowing different rates to be in effect based on the terms of the applicable program. Some of these configurable rate programs may need to be implemented in coordination with the E-ZPass CSC. In addition, the System shall support establishing toll schedules for special events that are activated during Special Events mode of operation.

A Default Rate Table shall also be defined at the global, tolling location and lane level, which shall be used automatically when no specific rate table is defined for a specific time period.

2.5.3 FutureTollRatePrograms

The Airports Authority may choose to implement one or more alternative toll rate structures and pricing schemes in the future. These new alternatives may be implemented to support such aspects as congestion pricing, point-to-point or distance based tolling. Although it is understood that the exact details and rate structures have yet to be determined the System shall be configured to meet the following minimum requirements:


Pg. 68

Distance Based Pricing – The System shall be designed to allow for the deployment of a point-to-point tolling structure where toll rates are based on specific entry and exit points (i.e. distance). At a minimum the System shall allow for the future assignment or re-designation of tolling locations as either an entry or exit location. The System shall allow for the assignment of toll rates based these ‘distances’ travelled.

Congestion/Value Based Pricing - The System shall also have the capability to support Value-Based Pricing including separate rate tables for various periods of congestion based upon time of the day, day of the week and or holidays.

Dynamic Pricing – The System shall be designed at a minimum to accept real time input of dynamic toll rates where by toll rates are adjusted in near real time based upon traffic data (i.e. volume, speed, occupancy) along the DTR corridor.

In support of both Value-Based Pricing and Dynamic Pricing the System shall also be capable of communicating in real time effective toll rates to variable message signs. The Contractor shall develop an interface (ICD) as part of the system design which shall support the future interfacing with variable rate message signs.

2.5.4 FareDetermination

The System shall determine the toll fare for all transactions using the toll rates and schedules established for each of the DTR tolling locations. The toll determination shall be performed at the lane controller where every transaction shall have the correct toll fare associated with the transaction based on the fare class as defined in this section. Toll Rate Schedules shall be user configurable through a configuration menu at the Host with the ability for global, plaza (ramp), and/or lane selection based on effective date/time of the change.

2.5.5 RealTimeMonitoring

The system shall provide the ability to simultaneously display real-time status and activity of all lanes including the ability to monitor the status of all lanes, subsystems and Host devices. This functionality shall be available from any workstation that connects to the TCS network. Approved users shall have access to the detailed data directly from the pictorial and dashboard view. Users shall be able to easily maneuver through screens and view data, and different colors and pictures shall be used to bring critical events to the user’s attention.

Lane statuses, including open, closed, special events and degraded (i.e., no communications with the lane controller or degraded subsystem), shall be graphically indicated by such as different colors. The system shall display all toll transaction activities in all lanes for a given ramp, plaza or individual lane. The overall design and layout of the real-time monitor (RTM) screen shall be designed with ease of use and simplicity in mind. Extra or erroneous information is not desired.


Pg. 69

Summary data by payment type for the entire roadway and by toll plaza shall be displayed and users shall have the ability to drill down to the details. Users shall be able to easily identify problems (traffic or equipment) on the toll lanes.

In addition, the real-time monitoring shall provide detailed information about the performance of the AVI, AVC, VES, DVAS subsystem, LSSs, ACMs and communications systems to assist in diagnosing and investigating problems. Data pertinent to traffic monitoring and maintenance shall be displayed in real-time.

In addition to the varying levels of monitoring, the RTM shall allow for the real-time overview of lane activity based on plaza selection from the user. At a minimum, the real-time overview function should provide the following on-screen information.

Lane ID; Collector ID (when applicable); Lane Mode; Lane status (open/closed/ degraded); Previous Vehicle Classification; Previous Vehicle Fare; Current Vehicle Classification; and Current Vehicle Fare.

2.5.5.1 AlarmMonitoringThe system shall generate alarms for all equipment failures and unusual conditions at the lane and host levels and notify the appropriate personnel about such malfunctions and unusual occurrences. The system shall clearly identify the date and time of the alarm, a description of the alarm/equipment failure and location of the alarm/equipment failure. The Contractor shall clearly define all the system generated alarms for review and approval by the Airports Authority during the design process.

As these malfunctions and unusual occurrences are detected, they shall be reported to the MOMS which will evaluate the message and determines if it is a major alarm.

If a message is a major alarm, it will be sent to the real-time monitor and an indicator will pop-up with an icon that will flash continuously until it is acknowledged by toll operations personnel. The alarm may be acknowledged by dismissing the incident if it is resolved so that it will not appear again, or it may be “silenced” temporarily for an adjustable interval of time. The alarm will resume flashing after the interval is passed, until it is dismissed, or until it is silenced again.

Based on the severity of the event and the number of times it has been detected, the system shall generate an alert message that will notify one or more individuals based on the affected system component and its location.

2.5.6 RemoteLaneManagement


Pg. 70

Toll operations supervisors and managers shall have the ability to remotely open a lane, close a lane, change lane mode, and switch vaults if necessary from the DTR control room.

2.5.7 HostAdministrationApplication

Each TCS workstation shall be able to access the TCS Administration application. The TCS Administration application shall require a secure login and provide access to different levels and features based on the user’s access level. Functions shall be selected from the main menu for the following functional areas:

Collector End of Shift/Cash-out Financial Menu Audit Menu Real-time Monitors Remote Commands Administration Menu System Functions Menu Reports Menu Maintenance Menu

All administrator functions may be performed by the Airports Authority’s Office of Technology and the Contractor in keeping with the Airports Authority’s security policies and IT best practices.

2.5.8 Workstations

The Contractor shall provide 15 new workstations (desktop PC’s) to the Airports Authority to access and support daily operations of the new TCS.

Workstations shall be equipped with the peripheral equipment needed for operations and shall be installed in designated offices to provide the required access.

All workstations connected to the DTR TCS network shall be able to access the application software and, based on access privileges, appropriate menus and screens shall be made available to the user.

These workstations shall also be maintained as part of the new TCS.

2.5.9 Printers

The Contractor shall provide, configure and maintain 4 new printers as part of the new TCS and any subsequent warranty and maintenance term. The following types of printers shall be provided:

1. 1 heavy duty, high speed, color laser printer, capable of printing both 8.5” x 11” and 11”x17” paper, single or double sided.


Pg. 71

2. 1 heavy duty, high speed, black & white laser printer capable of printing both 8.5” x 11” and 11”x17” paper, single or double sided.

3. 2 standard desktop black & white desktop laser printers.

2.5.10 SystemInterfaces

2.5.10.1 InterfacewiththeE‐ZPassCustomerServiceCenter(CSC)The Host shall interface to the E-ZPass CSC to transfer E-ZPass transactions on a real-time basis, and obtain E-ZPass Tag Status files and Tag Status Update files on a periodic basis. The Contractor shall develop the TCS to E-ZPass CSC interface using the approved VDOT E-ZPass CSC Interface Specifications. This document describes the transmission formats between the DTR and VDOT for E-ZPass transactions and E-ZPass Tag Status and Tag Status Update files. The E-ZPass CSC shall transmit Tag Status files and Tag Status update files to the TCS via a secure FTP drop box. The TCS shall transmit E-ZPass transaction files individually as XML messages via Restful Web Services calls. The Contractor shall furnish the relevant reports to allow for reconciliation of all data sent to and received from the E-ZPass CSC. The Contractor shall only be responsible for data integrity up to the interface point between the TCS and the E-ZPass CSC.

2.5.10.2 InterfacewiththeViolationsProcessingCenter(VPC)The TCS also interfaces with the Violation Processing Center (VPC) to transmit violation information. The violation information is currently transferred from the VES server to the VPC via Windows copy in compressed, zipped files known as an “evidential package” on a periodic basis. Each evidential package consists of a violation transaction file associated license plate images file sets (raw binary data received from the camera). Currently the VPC is operated by the same vendor as the VDOT E-ZPass CSC however the Airports Authority may consider implementing its own VPC at some later date through a separate procurement. If the Airports Authority does not change its VPC provider, the Contractor shall use the VDOT VPC Interface Specifications provided under Appendix B, to develop the interface between the TCS and the VDOT VPC. Otherwise the Contractor shall work with the new Airports Authority VPC vendor to develop a new interface, utilizing the E-ZPass Inter-CSC Interface File and Reporting Specifications as best as possible. The Contractor shall also furnish the relevant reports to allow for reconciliation of all violation data and files sent and received from the TCS to VPC interface. The Contractor shall only be responsible for data integrity up to the interface point between the TCS and the VPC. The Contractor shall support the Airports Authority in accommodating any changes to the VPC throughout the life of this Contract.

2.5.10.3 CSCandVPCCommunicationsInterfacesThe TCS shall include communication interfaces to the E-ZPass CSC and VPC. It is anticipated that all E-ZPass transactions generated from the TCS will be transmitted to the E-ZPass CSC individually on a real-time basis using web services.


Pg. 72

The Communications Interfaces and associated protocols shall support the periodic transfer of violation evidential packages (violation transactions, VES image data and OCR information) on a periodic basis from the TCS to the VPC.

The Contractor shall be responsible for providing and maintaining the internal networking and connections from the Host to points of interface with the E-ZPass CSC and VPC. The E-ZPass CSC and VPC provider(s) will be responsible for providing, and maintaining the connections to these interfaces via communication links from the E-ZPass CSC and VPC.

2.5.10.3.1 DataTransfersfromHosttoE‐ZPassCSCandVPCThe interface specifications for the data files passed between the Host and the E-ZPass CSC and VPC shall follow the approved TCS to E-ZPass CSC and VPC Interface Specifications Documents. This includes the use of acknowledgement and/or check files required for E-ZPass transactions, violation evidential packages, tag status files and tag status update files.

The TCS shall determine and providing alert, reporting or similar alarm messaging when acknowledgement and/or check files are not received from the E-ZPass CSC and VPC or an indicated discrepancy.

The Contractor shall be responsible for parsing the E-ZPass Tag Status Files and Tag Status Update Files received from the E-ZPass CSC into whatever format is suitable to facilitate the operation and formation of E-ZPass toll transactions as part of their system design.

No data transmitted from the E-ZPass CSC and VPC to the Host shall modify any of the expected toll revenues generated by the Host. Any adjustments to revenue due to non-revenue transactions, rejected E-ZPass transactions or other toll rate corrections will be processed and accounted for at the E-ZPass CSC and VPC level.

The TCS shall receive revenue reconciliation data in an electronic format from the E-ZPass CSC and VPC and shall populate this data in E-ZPass and Violation Collected Revenue fields at the Host. The TCS shall also calculate any discrepancies between indicated revenue (from the lane) and collected revenue (from the E-ZPass CSC and VPC).

2.5.10.3.2 E‐ZPassandViolationDataTransmissionThere are two types of data that shall be sent daily from the Host to the E-ZPass CSC and VPC via the Host to E-ZPass CSC and VPC Interface; they are:

1. E-ZPass transactions for all normal (non-violating) E-ZPass transactions that will be sent from the Host to the VDOT E-ZPass CSC individually on a real-time basis using web services.


Pg. 73

2. Violation evidential packages for all toll violations made by vehicles without a transponder, E-ZPass transactions by transponders with an “invalid” or “lost/stolen” status, run-through transactions in attended, exact change or unattended lanes). These evidential packages shall consist of a violation transaction file, associated front and rear license plate images and OCR information and shall be transmitted from the VES Server to the VPC on a periodic basis.

All data sent from the TCS to the E-ZPass CSC and VPC will be retained for a minimum period of 90 days on the TCS for use in data reconciliation. All E-ZPass transaction and violation evidence packages transmitted from the TCS to the E-ZPass CSC and VPC will be stored in a non-compressed format and be available for review by the Airports Authority. These files may be stored on a removable media in a compressed format. The Host will include the tools and system documentation for retrieval of the retained data.

2.5.10.3.3 E‐ZPassTransponderStatusFilesThe E-ZPass CSC will generate a Transponder Status File or “Tag Status File” and a Tag Status Update File on a periodic basis. The Tag Status File will follow the E-ZPass Inter-Customer Service Center Interface File Specification for tag status files, commonly referred to as the “ITAG” file. As per the specification, all fields will be filled. The Tag Status File and Tag Status Update File will contain the statuses of all transponders issued by the E-ZPass CSC as well as all the tags received by the E-ZPass CSC from away agency E-ZPass CSCs. The Tag Status File and Tag Status Update File may be transmitted in a compressed format mutually agreed to by the Contractor and the E-ZPass CSC provider.

The Contractor shall be responsible for parsing the Tag Status File and Tag Status Update file into whatever format is suitable for the operation and collection of E-ZPass toll transactions as part of their system design. The Contractor shall provide a Tag Status validation protocol that will daily validate and reconcile the Tag Status and Tag Status Update Files at the lane level with the files transmitted from the E-ZPass CSC.

All Tag Status and Tag Status Update Files received by the Host will be retained for a period of 90 days for use in transaction reconciliation. These files may be stored on a removable media in a compressed format.

The Host System will include the tools and system documentation for the retrieval of the retained data.

2.5.10.4 InterfacewithBank


Pg. 74

Currently the Airports Authority does not have an interface with their bank (Bank of America) for reconciliation. The new TCS shall allow the Airports Authority staff to manually enter the bank count deposit information into the TCS.

The Host System shall reconcile the bank counts to the vault counts inputted into the Host system by the Airports Authority fiscal department personnel. This reconciliation shall be performed once per day on the total DTR deposit.

2.5.10.5 InterfacewithGeneralLedgerCurrently the Airports Authority does not have direct interface between the TCS and the Airports Authority’s ERP solution / General Ledger. As part of the new TCS, the Contractor shall work with the Airports Authority to develop and configure an interface between the TCS financial reporting subsystem and the Airports Authority’s General Ledger (Oracle E-Business Suite R12).

The TCS shall transfer collected revenue data (AVI, cash and violation revenue) that has been reconciled in the TCS financial management subsystem to the ERP solution / General Ledger on a regular basis.

2.5.11 MigrationtoAllElectronicTolling

The Contractor shall be aware that the Airports Authority is currently in the planning stages for the potential future migration and transitioning to All Electronic Tolling (AET). The Airports Authority considers AET to be the collection of tolls through electronic means including the use of Automated Toll Collection Machines and E-ZPass. The Contractor shall design the TCS, specifically the Host and associated subsystems, to easily accommodate a future transition to AET. As part of the DDD and the design process the Contractor shall represent at a minimum the following:

1. The TCS’ ability to be modified and or configured to accept new lanes or AET zones;

2. The TCS’ ability to modify and or introduce new vehicle classification schemes and corresponding toll rates;

3. The TCS’ ability to support pay-by-plate transactions.

4. Document in detail the internal TCS violation and AVI transaction formats to be utilized as a future Interface Control Documents to define data transmission formats of the new AET zones;

5. Ability to define and create new reports related to AET;

6. Ability to redefine, add or delete business rules (i.e. violations transactions transitioning to video tolling and invoicing); and


Pg. 75

7. TCS’s ability to operate under both conventional tolling and AET during any transitioning period.

The Contractor shall clearly represent the TCS’s overall capability of transitioning to support AET. There shall be no limitations or design restrictions preventing such transition or need for substantial re-design of the TCS Host and supporting subsystems. The Contractor shall work with the Airports Authority to define all pay-by-plate and video tolling business rules in the event the DTR transitions to AET.

2.5.12 TimeStampingandSynchronization

The Contractor shall incorporate time stamping in all facets of the new TCS. In all transaction records, the time stamp shall, at a minimum, be to the nearest hundredth (0.01) of a second.

The Host shall be synchronized to a certified time source that is approved by the Airports Authority using standard network time protocol (NTP) at configurable intervals but at a minimum every five (5) minutes. The TCS shall provide accurate time synchronization among all lane, and Host components (including video DVAS equipment) to the hundredth (0.01) of a second at a minimum. If needed, synchronization messages shall be sent to devices that do not support off-the-shelf time synchronization software. The time synchronization technique shall ensure that there are no transactions or files with incorrect time stamps.

The Host will be provided with a real-time clock and calendar. The performance requirements for the clock are:

1. Clock Resolution of 1/60 second

2. Automatic date correction to compensate for 28, 29, 30 and 31 day months.

3. Correctly handling the time change and placing traffic data in the right file automatically.

4. Clock Accuracy of ± 5 seconds per month.

5. A rechargeable battery that will last at least one month will back-up the clock.

The host computer system will operate normally, without any failure or loss of data, when the system clock is reset.

2.5.13 VaultSwitching

The TCS shall allow toll operations personnel to modify the vault switch weight (calculated by the number of coins), which triggers the lane system to switch to the next vault when the active vault reaches the pre-determined threshold. The data field for the vault switch weight shall include an entry for the revenue date in which the


Pg. 76

system will start applying the new weight definition. The new weight definition shall become effective at midnight for the date it is set to be active.

The system shall show historical weight definitions to allow authorized users to check that previously entered weight definitions have been correctly entered to the system.

2.5.14 BankDepositReconciliation

The TCS shall allow for the manual entry of bank deposit information that has been received from the bank. A daily physical count is taken after all the vaults have been emptied and been run through the coin counting machines by the Airports Authority fiscal staff. The TCS shall allow the Airports Authority staff to manually enter the coin count information into the TCS. If there is a difference between the physical count that is manually entered into the TCS and the bank count, an adjustment shall be granted by the Airports Authority audit staff. This bank deposit data shall not affect revenue reports.

The system shall allow for the toll audit staff to assign the above deposit adjustment to an ACM, vault, lane or plaza/ramp location.

2.5.15 VersionTrackingRequirements

The TCS shall maintain records of all versions of the Transponder Status files; toll rates and schedules; lane configuration files, Employee files, and lane executables that it received and/or created and that were successfully downloaded to the lanes over the past six months on a rolling schedule or as determined in design and approved by the Airports Authority. Receipt of files from and transfer of files to the E-ZPass CSC and VPC, their version, time of receipt and processing status shall also be tracked. Reports and a GUI shall be made available to verify the versions and the download status. Failure in the transmission of any data to a lane or the back office system (E-ZPass CSC or VPC) shall result in a failure message being logged and reported to the MOMS.

2.5.16 RevenueDayAssignmentandVerification

It is critical that all messages from the lane controllers are transmitted to the Host System and a verification of this data transmission shall be performed. The Contractor shall provide this validation which, if successful, closes the Revenue Day. If the validation process fails for any reason, failure messages shall be created and reports shall be made available to authorized personnel. If the Revenue Day process determines that transactions are missing, the missing transaction sequence numbers shall be identified and reported. The System shall allow for the manual closure of a Revenue Day and all such manual closures shall be flagged and reported. Reconciliation of transactions and revenue is performed on a Revenue Day basis.

The current revenue day shall be from 12:00:00.00 AM to 11:59:59.99 PM.

2.5.17 DataSummarization


Pg. 77

In order to support the Airports Authority reporting requirements and control the size of the database, all pertinent financial and transactional data shall be summarized. The availability of detailed data and the summarization of data shall be in accordance with the data backup and retention requirements, herein.

2.5.18 Diagnostics

The TCS shall provide self-diagnosis functions to detect and report on the status and functioning condition of the System hardware devices; communications; processes; tasks, and software applications, as defined in the Airports Authority-approved Detailed Design Document. All failures detected shall be reported to the MOMS.

2.5.19 DataSecurity

The Contractor shall ensure that master data records, once entered into the TCS, cannot be deleted or changed. These records shall include MOMS timestamps such as a maintenance technician’s acknowledgement time. Master data records and files shall only be appended to and not edited or deleted. If manual intervention is required only authorized users with proper security access shall be permitted to ‘flag’ a file to ensure the integrity and provide a complete audit trail. All TCS system access/entry, logins, and modifications (i.e. flagging actions) shall be recorded. Encryption shall be used for all confidential data.

2.5.20 TransactionProcessing

The Host System shall ensure that all transactions transmitted to the E-ZPass CSC and the VPC are transactions that comply with the approved TCS to E-ZPass CSC and TCS to VPC Interface specifications and can be correctly posted to an E-ZPass account or pursued as a violation. If duplicate transactions are not filtered at the lane controller, then the Host System shall perform such filtering. In cases where a transponder is read and a violation is created for a vehicle (e.g. due to buffered transponder reads or lane logic issues), the Host System shall perform the filtering based upon configurable parameters approved during the system design phase. In case of buffered read transactions, the transponder read time shall be used as the transaction time. Alarm messages shall be created and reported to the MOMS in the event such exceptions exceed a configurable threshold. The Host shall provide additional configurable filters for violation transactions to allow the Airports Authority to manage the violation transactions that are sent to the VPC. These configurable violation filters shall be specified and approved by the Airports Authority during the system design phase.

Upon contract award and NTP the Airports Authority will provide details on the existing Host business rules for filtering violation filters to the selected Contractor.

2.5.21 UserSetupandMaintenance


Pg. 78

User setup and maintenance is a critical task since the employee access levels/roles created through the System shall determine what privileges and access rights each employee and or role is granted. Access to Host System and the MOMS application shall be controlled through this interface. Authorized personnel shall have the ability to create new users through the System. Through a user setup and maintenance menu, the users shall be designated various access levels/roles based on their responsibilities (job description). In the Design phase access levels/roles shall be created and the System shall allow the input and editing of generic job access levels/roles. The access rights of each role and the ability to add roles and users shall be defined by the Airports Authority during the Design phase.

The user setup and maintenance menu shall be also used to activate and inactivate employees from the System. The same menu shall also be used to assign User ID and PIN/password for access to TCS applications. As soon as the information is saved, an access control list shall be transmitted in near real-time to the various Systems for immediate user access. Although the specific design of the System and various TCS applications are dependent on the Contractor’s solution the Airports Authority prefers the use of Active Directly where possible.

2.5.22 UploadVerificationofTransactionRecords

The Host shall have the capability of receiving transaction records from all lane controllers and verifying the completeness of transaction record data. Any “gaps” in transaction records or missing transaction data shall be identified, searched for (or polled) and replaced by the Host with transaction data stored in the lane controllers. A listing of any missing sequences in transaction numbers or loss of required transaction record data shall be maintained in the MOMS and in an Audit Reconciliation file.

All lane transaction records shall be stored in a manner where it shall be available at the Host for local processing and report generation and transmission to the E-ZPass CSC and VPC. The Host shall coordinate and log all communications to/from the lane controllers and to/from the E-ZPass CSC and VPC.

The Host computer system shall have the capability to store at least 90 days of transaction records from all lanes in the event of a communication outage between the Host and the E-ZPass CSC and VPC. The transaction records shall also be removable and transportable. Provision shall be made to transport the transactions from Host to the E-ZPass CSC and VPC on a portable computer or removable storage media in the event of a communication interruption.

2.5.23 TransponderStatusFileandFareTableDownloads


Pg. 79

The Host shall receive periodic file updates of E-ZPass transponder account status from the E-ZPass CSC. The Host shall store the most recent version of this file and maintaining a log of the time and date of the file receipt. The Host shall thereupon update/replace the transponder status file stored in each lane controller. Lane controllers shall immediately begin using the new tag status file.

Fare Table updates shall include the date and time the update is to take effect and the new fares for each class. The fare table shall be stored so that authorized Airports Authority personnel can easily modify changes to the existing schedule. The system will maintain a log of fare table changes.

The system shall accept any adjustments or increases to the current schedule and support a maximum of fifteen (15) additional rates per vehicle class. The toll rate schedule(s) shall also take into consideration and be established in accordance with the current Airports Authority vehicle classification structure.

2.5.24 AuditandReconciliation

Reconciliation is a calculation that shows how one balance or figure is systematically derived from another. The purpose of reconciliation is to explain the difference between two items. The principal data comparison and reconciliation activity is performed via the toll collector shift reconciliation analysis.

Vehicle reconciliation for an attended lane uses the toll collector classifications to determine the total number of vehicles by class classified during a shift. This number of calculated vehicles by class is compared to both the pre-class AVC and post-class AVC vehicle counts by class (recorded during the shift). If there are no unusual occurrences, the three totals should match and the vehicle counts would be reconciled.

Next, collections shall be reconciled. The system shall count the number of vehicles of each class during the toll collector's shift, excluding those that have paid by E-ZPass. Vehicle counts for each class when multiplied by their respective toll class and added together constitute the system measurement of the cash that was collected.

As part of the audit process, the toll auditor counts and enters the funds collected during the shift through the automatic coin machines. The comparison between the ACM vault count in the cash room, and the funds indicated by the toll collector’s classifications are reviewed and evaluated by toll audit.

In a mixed mode lane, E-ZPass or cash transaction records shall be separately accounted for in order to determine the vault amount to be expected from an ACM.

E-ZPass transaction reconciliation compares vehicle reads (valid and invalid) and “no-reads” not processed by a toll collector with independent lane sensors.


Pg. 80

Daily lane reconciliation shall account for the toll period and be tabulated by vehicle counts, vehicle classifications and axle counts by cash payment types and exceptions/violations. Shift or period totals will also be provided.

2.5.25 TCSReports

This section describes the existing TCS reports that the DTR staff use to audit and reconcile the legacy TCS and its operation. The new TCS shall furnish these existing TCS reports as well additional System reports related to traffic and toll revenue, audit, toll operations, system performance as well as MOMS reporting.

The Contractor shall describe their process for modifying reports and which reports may need to change, in the event the Airports Authority chooses to migrate to AET and/or pay-by-plate functionality.

2.5.25.1 ScreensandReportAccessThe TCS software shall provide the capability to assign privileges and access rights, as determined by the Airports Authority, to the Host System application. Based on the access levels/role a user shall be assigned to the appropriate menus, screens, tabs, reports and all other required user information shall be displayed. For some screens, certain access levels/roles may only be allowed to view the contents and not allowed to enter any data. Access privileges shall be set up to allow Airports Authority authorized personnel to make changes to the access privileges at any time, and shall be based upon access level/role and not at an individual employee basis.

2.5.25.2 GeneralReportingRequirementsAll data entered or generated in the System shall be retrievable through reports and browsing screens. Reports and screens shall be made available through the System and on an ad-hoc basis, shall have various selection, filtering and sort criteria, and shall be easily configurable.

The location selection criteria shall include plaza, lane, and direction of travel. The date selection criteria shall include but are not limited to the ability to generate the same report by minute, hour; day; date range; weekly; monthly; yearly, and year-to-date. Users shall have the ability to sort the data by any field type and apply filters to select specific field types to display.

Data shall be presented as an accumulation or individually for the selected criteria. This capability shall be configurable and applicable to individual tolling location and different transaction types whereby the user can choose the data to be presented as an accumulation of tolling locations and/or payment types or as individual tolling locations and/or payment types.

The Contractor shall provide the Airports Authority with the capability to manipulate the report data to perform comparative analysis and statistical calculations. As such, the


Pg. 81

Contractor shall provide the Airports Authority with a complete data dictionary and database access to support data mining activities by Airports Authority staff and or its representative(s). The Contractor shall also provide the Airports Authority with ad-hoc reporting tools. These ad-hoc reporting tools shall accommodate the need for specialized system analytics and business intelligence processes to further support the on-going operations and planning for the DTR. The use of such tools to generate ad-hoc reports shall be documented. Ad-hoc report templates created by authorized users shall be made available to all authorized users.

In addition to the reports listed below, the Contractor shall provide up to fifteen (15) additional ad-hoc reports to be determined during the contract. All reports shall show the status of the Revenue Day, as defined by the Airports Authority and other relevant statuses that indicate items including but not limited to whether all data has been obtained from the lanes; the transactions have been transmitted to the E-ZPass CSC and VPC; the report is complete, and if audit can begin. Additionally, the time of the last transaction processed shall be included in all applicable reports. All reports shall include individual totals, sub-totals, and grand-totals as appropriate. Reports shall be configurable based upon “processed date,” “transaction date,” or both, as designated by the Airports Authority. Transactions generated during Special Events mode shall not be included in revenue and traffic reports. Separate reports shall be made available to report Special Events mode transactions.

The Contractor shall provide a commercially available reports package, such as Crystal Reports, that will allow all reports and screens to have the capability of being printed and saved in industry standard Adobe .pdf format; html format; xml format; rtf format; Microsoft Access® and Microsoft Excel® .csv and .xls formats (latest version of Microsoft Office® utilized by the Airports Authority), and other formats to be approved by the Airports Authority during the Design phase. Selected reports shall be automatically generated and made available to authorized personnel at the start of the Revenue Day or at other appropriate time as designated or requested by the Airports Authority. A report generation feature shall be available for configuration and shall permit an individual with permission to request selected reports for auto delivery by email or to a designated drive folder according to a routine or custom-specific interval. The System shall have the ability to drill down all high-level reports to the next level of detail and to details as required. Additionally, the user shall have the ability to display and review the violation images and event details associated with the selected transaction from the drilled down details.

Authorized personnel shall also have the ability to view the contents of files that are received by and/or transmitted by the Host System in a readable format. If files are compressed or encrypted, the necessary software tools shall be provided to view their contents.


Pg. 82

Where applicable, data shall also be presented in a graph forms and chart types and the user shall be able to select presentation form from a variety of graphic styles. Report designs shall be presented during the Design phase by the Contractor and the Airports Authority and approved by the Airports Authority. Data shall be organized and summarized in manner to allow for report generation within no more than two (2) seconds for daily reports, and no more than twenty (20) seconds for monthly and annual reports, of a report generation request. Additionally, after implementation of the System, the need may arise to create additional reports and modify implemented reports and the Contractor shall support any such additions and/or modifications at a reasonable cost to the Airports Authority.

2.5.25.3 AdministrationReportsThis section provides a list of administrative reports that the Airports Authority staff currently uses. In addition to providing these legacy administration reports, the Contractor is encouraged to provide additional administration reports to facilitate enhanced administrative functionality.

2.5.25.3.1 AlarmHistoryReportThe Alarm History Report presents a full history of all system alarm activities for a selected period of time by location. An alarm can be a system error or equipment malfunction that requires acknowledgement. The report shall display the start/end dates and times of the reporting period, plaza, lane, alarm type, date, time, and description of the alarm event as well as the Staff ID that acknowledged the alarm and the date/time stamp when the alarm was acknowledged. The system shall not permit a user to modify the timestamp of the alarm nor the timestamp that the alarm was acknowledged.

2.5.25.3.2 LaneOperationsHistoryReportThe Lane Operations History Report presents a history of lane information specific to the opening and closing of one or more lanes. The report shall include the start/end dates and times of the reporting period, plaza, lane, mode of operation, lane open date/time, lane closed date/time, Staff ID, staff name and vault number (if applicable).

2.5.25.3.3 LaneEventsReportThe Lane Events Report shall provide a chronological list of lane operational events and messages, by lane or by collector, within the selected lane/plaza for selected date and time range.

2.5.25.3.4 SpecialEventsReportThe Special Events Report presents a summary of transactions for each Special Event that occurred during a specific reporting period. The report shall include the start/end dates and times of the reporting period, the plaza, lane, vehicle count and total number of axles processed by the lane for the Special Event.

2.5.25.3.5 StaffRegistryReport


Pg. 83

The Staff Registry Report presents the staff registry listing and associated details sorted by chosen sort criteria (e.g. name, badge, user level). The report shall include the Staff ID, staff name, User ID, user level, Badge Number, registration date and termination date.

2.5.25.3.6 VaultInventoryReportThe Vault Inventory Report presents the current status and history for one or more selected ACM vaults. The report shall include the Vault ID, plaza, lane, current status, check (indicates if a vault status needs further investigation), date/time, Staff ID, total active vaults, total inactive vaults, total vaults removed, total vaults lost, total vaults sent to maintenance, total vaults in storage, and total vault inventory.

2.5.25.3.7 FileTransmissionReconciliationReportsThe File Transmission Reconciliation Reports are daily, weekly, monthly and yearly reports that show AVI and violation transaction transmission reconciliation for all of the tolling locations. These reports shall validate that all of the AVI and Violation transactions received from the lanes were transmitted from the Host System to the E-ZPass CSC and VPC. Reports shall be available by revenue day and transmit day and transmit day reports shall show the files transmitted and acknowledged by the receiving system.

2.5.25.3.8 TransponderFileTransmissionReportThe Transponder File Transmission reports shall show the status of the Transponder Status File transmissions to the Host System and to all of the tolling locations/lanes. Time of receipt from the E-ZPass CSC, time of transmission to the tolling locations/lanes, and the status of the transmission shall be displayed.

2.5.25.4 AuditReportsThis section provides a list of audit reports that the Airports Authority staff currently uses. In addition to providing these legacy audit reports, the Contractor is encouraged to provide additional audit reports to facilitate enhanced audit functionality.

2.5.25.4.1 TransactionAdjustmentReportThe Transaction Adjustment Report presents details of transactions that were adjusted by toll audit staff for the requested reporting period and for specified sorting criteria. The report shall include the start/end dates and times of the reporting period, the Sort By criteria, transaction date/ time, plaza, lane, class, transaction type, number of transactions, revenue adjustment, axle adjustment, Staff ID (making the adjustment), adjustment date/time, Collector ID (for whom the adjustment was made) and a comment (as entered by the staff making the adjustment).

2.5.25.4.2 DetailedAuditReportThe Detailed Audit Report shall list every transaction that occurred during the specified report time range. The Detailed Audit report provides insight into the performance of the lane and collector actions in the lane. The report shall include the start/end dates


Pg. 84

and times of the reporting period, the plaza, lane, Staff ID and staff name as well as the full details for every transaction including, but not limited to, transaction date/time, transaction type, collector classification, indicated axles (identified by the collector or by the transponder classification), revenue expected, revenue collected, equipment states, alarms, transponder ID, pre-class forward axles, pre-class reverse axles, net pre-class axles, post-class forward axles, post-class reverse axles, net post-class axles, indicated axles (identified by the collector or by the transponder classification), difference between pre-class and indicated axles, difference between post-class and indicated axles and details of Unusual Occurrences including the status of various lane equipment sensors.

2.5.25.4.3 SystemAuditReportsWeekly and monthly reports shall be made available that show the user access data and modifications made and ability shall be provided to obtain the details of the modifications.

2.5.25.4.4 UnusualOccurrenceReportThe Unusual Occurrence (UO) Report shall present a summary of all unusual occurrences within a specified time frame. Each Unusual Occurrence Report shall include the start/end dates and times of the reporting period, plaza, lane, collector ID, collector name, UO type, date/time of occurrence, Sort By criteria, collector classification, UO description, expected revenue, revenue collected, alarms and total unusual occurrences.

Examples of UO transactions include: run-through vehicles, ACM under/over classification, authorized run-throughs, AVI class mismatches, AVI axle mismatches, pre-class/post-class axle mismatches, collector reclassification, invalid/lost stolen transponders.

2.5.25.4.5 TourDetailReportThe Tour Detail Report shall summarize all the transaction details associated with a collector’s tour of duty (i.e. the period of time between the collector login and logout). The report shall include the start/end dates and times of the reporting period, plaza, lane, Collector ID, lane open/close date and time, ACM vault number, summary of transaction type by vehicle class (ACM, AVI, Authorized Run-Throughs, Non-Revenue Cash and Non-Rev AVI, Violations, Unusual Occurrences, Total), ACM revenue collected by vehicle class, ACM revenue expected by vehicle class, totals, axle summary by vehicle class (indicated axles, pre-class axles, post-class axles, total), indicated/pre-class axle differences by class, indicated/post-class axle differences by class, AVI expected revenue, totals, alarms, dates/times alarms were reported, alarm descriptions, Staff IDs that acknowledged the alarms and the alarms acknowledgement dates/times.


Pg. 85

2.5.25.4.6 E‐ZPassReconciliationSummaryReportThe E-ZPass Reconciliation Summary Report shall provide a reconciliation summary of the E-ZPass transactions sent to the E-ZPass CSC. The report shall include the start/ end dates and times of the reporting period, plaza, lane, sort sequence, transaction date/time, transponder number, fare class charged, fare amount charged, transaction total and fare charged total.

2.5.25.4.7 DailyVaultTrialBalanceReportThe Daily Vault Trial Balance Report shall summarize the deposit status of selected vaults within the specified reporting parameters on a daily basis. This report does not show AVI transaction data. The report shall include the start/end dates of the reporting period, plaza, lane, Vault ID, Staff ID (that removed the vault), expected revenue, collected revenue, deposited revenue, expected/collected revenue variance, collected/deposited revenue variance, ACM under payments, ACM over payments, resets (transactions purged due to a lane reset), violations, overclass transactions, underclass transactions, authorized run-throughs, total transactions, indicated axles (collector or AVI), pre-class axles, post-class axles, adjustments and comments (entered by staff).

2.5.25.4.8 DailyCollectorTrialBalanceReportThe Daily Collector Trial Balance Report shall summarize all collector tours within the specified reporting parameters on a daily basis. This report does not show AVI transaction data. The report shall include the start/ end dates of the reporting period, plaza, lane, Vault ID, expected revenue, collected revenue, expected/collected revenue variance, ACM unusual occurrences, insufficient fund transactions, violations, overclass transactions, underclass transactions, authorized run-throughs, non-revenue cash transactions, total transactions, sub-total of collector shifts, adjustments, adjustment comments, and the total (subtotal plus sum of adjustments for each transaction and revenue field).

2.5.25.4.9 DailyAVITrialBalanceReportThe Daily AVI Trial Balance Report shall summarize all AVI transaction data within the specified reporting parameters on a daily basis. The report shall include the start/ end dates of the reporting period, plaza, lane, expected revenue, AVI transactions by class, AVI transaction totals, non-revenue AVI transactions, AVI class mismatches, no funds transactions, invalid transponder transactions, lost/stolen transponder transactions, adjustment comments, subtotal of each traffic and revenue field, total of each traffic and revenue field.

2.5.25.4.10 AxleReconciliationReportThe Axle Reconciliation Report shall present a reconciliation summary of the indicated axles, pre-class axles and post-class axles for the specified location and reporting period. The report shall include the start/end dates and times of the reporting period,


Pg. 86

plaza, lane, indicated axles (identified by the collector or by the transponder classification), pre-class axles (identified by pre-class AVC), the pre-class vs. indicated axle actual and percentage difference, post class axles (identified by the post-class AVC), the post-class vs. indicated axle actual and percentage difference.

2.5.25.5 FinancialReportsThis section provides a list of financial reports that the Airports Authority staff currently uses. In addition to providing these legacy financial reports, the Contractor is encouraged to provide additional financial reports to facilitate enhanced financial management functionality.

2.5.25.5.1 CollectorDailyReportThe Collector Daily Report shall summarize all transaction data that occurred during a collector’s shift which could include multiple tours within the specified reporting parameters on a daily basis. The report shall default to sort multiple tours by time order. The report shall include the start/end dates of the reporting period, Collector ID, collector name, Staff ID and staff name that performed the Collector End-of-Shift operation, date/time when the End-of-Shift operation was performed, date/time opened (start of specific tour of duty), date/time closed (end of specific tour of duty), plaza, lane, Vault ID, a full breakdown of transactions by payment type (ACM and AVI) and by class which shall consist of: normal transactions (excludes UOs), authorized run-throughs, non-revenue manual transactions, violations, total manual transactions, unusual occurrences (over-class, underclass, run-throughs, re-class, revenue collected, revenue expected, expected/collected revenue variance, indicated axles (by collector), pre-class axles, post-class axles, total transactions, alarm details (date/time, description, Staff ID that acknowledged alarm and acknowledgement date/time).

2.5.25.5.2 PlazaRevenueSummaryReportThe Plaza Revenue Summary Report shall present a summary of the revenue collected between a given start date and a given end date and shall display summary data by date, day, plaza, lane, ACM revenue expected by class, total ACM deposit (from bank), adjusted revenue, AVI revenue expected by class and by transponder issuing agency.

2.5.25.5.3 AnnualRevenueSummaryReportThe Annual Revenue Summary Report shall present a summary of the year to date monthly revenue count by payment method (ACM, AVI, Total, Deposit Amount), lane, plaza, with sub-totals for mainline, ramps and overall total.

2.5.25.5.4 CollectorTourswithoutEnd‐of‐ShiftReportThe Collector Tours without End-of-Shift Report shall present the list of all collector tours for which no collector End-of-Shift exists within the specified reporting parameters. The report shall include the start/end dates, Collector ID, date/time opened (start of tour of


Pg. 87

duty segment), date/time closed (end of tour of duty segment), plaza, lane, vehicles per hour (total vehicles divided by the total time of the tour of duty).

2.5.25.5.5 Non‐RevenueTransactionReportThe Non-Revenue Transaction Report shall present the transaction details of all non-revenue transactions that occurred within the specified reporting parameters. The report shall include the start/end dates and times, plaza, lane, starting Staff ID and name, ending Staff ID and name, transaction date and time, transponder number, non-revenue type (AVI or manual), Sort By criteria (plaza, lane), and indicated axles.

2.5.25.5.6 VaultRevenueDetailReportThe Vault Revenue Detail Report shall summarize the vault revenues for selected vaults during the specified reporting parameters. The report shall include the start/end dates, plaza, lane, Vault ID, vault status, vault housing, deposit date, vault installation date, Staff ID that inserted vault, vault activation date, vault removal date, Staff ID that removed vault, vault counted date, Staff ID that counted the vault, start/end tour of duty date/times, Collector ID and name of collector performing each tour, ACM vehicle count, ACM overpaid transactions, ACM underpaid transactions ACM violations, Other Unusual Occurrences, Total UO transactions, indicated vault weight, number of times ACM door was opened while vault was active, ACM revenue count by coin denomination, money room revenue count by coin denomination, bank revenue count by coin denomination, TCS expected revenue, vault expected revenue, money room counted revenue, bank counted revenue, expected/vault revenue variance, vault/money room revenue variance, money room/bank revenue variance, alarm details (date/time, alarm descriptions, date/time of alarm acknowledgement, Staff ID that acknowledged alarm), Staff ID of maintenance technician that worked on the ACM while the vault was active.

2.5.25.5.7 VaultSummaryReportThe Vault Summary Report shall summarize the history of one or more selected vaults the specified reporting parameters. The report shall include the start/end dates, plaza, lane, Vault ID, vault status, vault installation date, Staff ID that inserted vault, vault activation date, vault inactivation date, vault removal date, Staff ID that removed vault, Staff ID of maintenance technician that worked on the ACM while the vault was active.

2.5.25.5.8 DetailedCreditCardReportShall provide a sum total and chorological listing of each credit card transaction by credit card company, by equipment location for a selected time period. Report shall include credit card payments made to all machines and other active programs within the System. This report shall be used to reconcile credit card transactions between the credit card transaction, clearinghouse and bank deposit.


Pg. 88

2.5.25.6 TrafficReportsThis section provides a list of traffic reports that the Airports Authority staff currently uses. In addition to providing these legacy traffic reports, the Contractor is encouraged to provide additional traffic reports to facilitate enhanced traffic monitoring functionality.

2.5.25.6.1 PeakViolationsReportThe Peak Violations Report presents a daily summary of the lane violations counts for each plaza and lane for the requested reporting period. The report shall include the start/end dates of the reporting period, plaza, lane, violation records, links to the violation images, hourly violation count by lane and the total violation count by plaza.

2.5.25.6.2 PlazaTransactionSummaryReportThe Plaza Transaction Summary Report shall present the transaction count summary by plaza and lane for the requested reporting period. The report shall include the start/end dates and times of the reporting period, plaza, lane, ACM transactions, AVI transactions, authorized run-throughs, non-revenue manual transactions, non-revenue AVI transactions, violations, total transactions, indicated axles, post-class axles, indicated/post-class axle difference and totals of all columns. The user shall have the ability to request this report by date range, time range, plaza, lane, axles and transponder issuing agency.

2.5.25.6.3 TrafficActivitybyClassReportThe Traffic Activity by Class Report shall present the hourly transaction count by vehicle class on an hourly basis and lane for the requested reporting period. The TCS shall auto -generate this report each morning for the previous day and distribute it to a configurable set of recipients. The report shall include the start/end dates of the reporting period, plaza, lane, ACM transactions, AVI transactions, authorized run-throughs, non-revenue manual transactions, non-revenue AVI transactions, violations, and the total transaction counts for each vehicle class and each hour. If multiple days are selected, the report shall show each day on a separate page.

2.5.25.6.4 TrafficActivitybyLaneReportThe Traffic Activity by Lane Report shall present the daily traffic count by lane for one or more selected plazas for the requested reporting period. The TCS shall auto -generate this report each morning for the previous day and distribute it to a configurable set of recipients. The report shall include the start/end dates of the reporting period, plaza, ACM transactions, AVI transactions, authorized run-throughs, non-revenue manual transactions, non-revenue AVI transactions, violations, and the total transaction counts for each lane at the selected plaza. If multiple plazas are selected, the report shall show each plaza on a separate page.

2.5.25.6.5 HourlyTrafficReport


Pg. 89

The Hourly Traffic Report shall present the hourly transaction summary by lane by for one or more selected plazas for the requested reporting period. The TCS shall auto-generate this report each morning for the previous day and distribute it to a configurable set of recipients. The report shall include the start/end dates of the reporting period, plaza, lane, ACM transactions, AVI transactions, authorized run-throughs, non-revenue manual transactions, non-revenue AVI transactions, violations, and the total transaction counts for each lane at the selected plaza. If multiple plazas are selected, the report shall show each plaza on a separate page.

2.5.25.6.6 DailyTrafficOverviewReportThe Daily Traffic Overview Report shall present a summary of all transactions for the requested date/time range reporting period and shall display the lane/Plaza, Auto ACM, Auto AVI, Auto Non-Rev, Auto Vio, Total Auto, % AVI Auto, Truck ACM, Truck AVI, Truck Non-Rev, Truck Vio, Total Truck, % AVI Truck, Total Traffic.

2.5.25.6.7 DetailedTrafficReportThe Detailed Traffic Report shall provide a chronological list of every transaction that occurred during the specified report time range. The report shall include the start/end dates and times of the reporting period, the plaza, lane, Staff ID and staff name as well as the full details for every transaction including, but not limited to, transaction date/time, transaction type, collector classification, indicated axles (identified by the collector or by the transponder classification), revenue expected, revenue collected, transponder ID, transponder read time, pre-class forward/reverse axles, post-class forward/reverse axles, indicated axles (identified by the collector or by the transponder classification), class/axle mismatches, Unusual Occurrences, lane state (normal or degraded), degrade reason, etc.

2.5.25.6.8 MonthlyTrafficSummaryReportThe Monthly Traffic Summary Report shall present a summary of the Monthly to Date daily traffic count by transaction type (ACM, AVI, Authorized Run-Through, MLT Non-Revenue, AVI Non Revenue, Violations, Total), lane, plaza, pre-class axles, post-class axles, pre-class vs. post-class axle difference, with sub-totals for mainline, ramps and overall DTR total.

2.5.25.6.9 AnnualTrafficSummaryReportThe Annual Traffic Summary Report shall present a summary comparison of transactions between previous month/year and current month/year. It shall display the Year to Date monthly traffic count by transaction type (ACM, AVI, Authorized Run-Through, MLT Non-Revenue, AVI Non Revenue, Violations, Total), lane, plaza, pre-class axles, post-class axles, pre-class vs. post-class axle difference, with sub-totals for mainline, ramps and overall DTR total.

2.5.25.6.10 TrafficandRevenueComparisonReport


Pg. 90

The Traffic and Revenue Comparison Report shall present the comparison of Year to Date monthly traffic and revenue count by class by transaction/payment type (ACM, AVI, Violation, Non Revenue, Total) by plaza for current year vs previous year, monthly Year/Year actual and percent difference, Year to Date Year/Year actual and percent difference.

2.5.25.6.11 AVIViolationsReportThe AVI Violations Report shall present the list of all AVI violation transactions by plaza for the requested reporting period and for specified sorting criteria. The TCS shall auto -generate this report each morning for the previous day (sorted by date/time then by plaza/lane and by transponder number) and distribute it to a configurable set of recipients. The report shall include the start/end dates of the reporting period, plaza, lane, sort by criteria, transponder number, and the AVI transaction total.

2.5.25.6.12 AVITrafficandRevenueSummaryReportThe AVI Traffic and Revenue Summary Report shall present the AVI transaction and expected revenue summary, both for the home E-ZPass agency (010) and all away E-ZPass agencies (total), by vehicle class for one or more selected plazas for the requested reporting period. The TCS shall auto-generate this report each morning for the previous day and distribute it to a configurable set of recipients. The report shall also be capable of being run for time periods less than an hour such as 15 minute or half-hour increments. The report shall include the start/end dates and times of the reporting period, plaza, AVI transactions and expected revenue by class for E-ZPass agency 010, AVI transactions and expected revenue by class for all away E-ZPass agencies, total AVI transactions and total expected AVI revenue. If multiple days are selected, the report shall show a sub-total for each day of the reporting period and a total for the entire reporting period.

2.5.25.6.13 AVISummarybyAgencyReportThe AVI Summary by Agency Report shall present the AVI transaction and expected revenue summary by transponder issuing agency, by vehicle class for one or more selected plazas for the requested reporting period. The TCS shall auto-generate this report each morning for the previous day and distribute it to a configurable set of recipients. If multiple days are selected, the report shall show each day’s summary on a separate line and a sub-total of the summary data for each agency. The report shall include the start/end dates and times of the reporting period, plaza, AVI transactions and expected revenue by class for each E-ZPass agency.

2.5.25.6.14 AVIUsageReport(SingleTransponder)The AVI Usage Report shall present the total transaction usage for a specific transponder and shall display the transponder number, plaza, lane, transaction date/time, transaction transponder status, expected AVI revenue.


Pg. 91

2.5.25.6.15 AVIPenetrationReportThe AVI Penetration Report shall present the AVI penetration by start/end date, start/end time, lane, plaza, AVI traffic count, total traffic count, total penetration by plaza, overall DTR penetration.

2.5.26 TCSHostSystemRequirements

2.5.26.1 TCSHostSystemGeneralRequirementsThe Contractor shall provide a TCS Host which is comprised of both a Primary and Secondary system/servers. The primary TCS Host shall be located at the DTR’s Administration building server room. The secondary TCS Host shall serve as a redundant system to support the restoration and recovery of the TCS in the event of a catastrophic failure of the primary TCS Host. For both the primary and secondary TCS Hosts the Contractor shall provide, at a minimum the following:

1. Contractor shall maintain a secure TCS Host environment providing all necessary hardware, software, and communication bandwidth to manage the TCS Host System application and support multiple users with permission based logins.

2. Access for Airports Authority users shall be browser based via Internet Explorer. 3. At the Airport’s Authority request, designated and authorized third parties shall

be given limited access by the Contractor to certain levels of the TCS Host System through VPN or other secure separate network connection that meets the Contractor’s specifications.

4. The TCS Hosts must both be physically secured – restrict access to the site(s) to personnel/users with controls such as biometric, badge, or others security solutions. Policies for granting access must be in place and followed. Access shall only be granted to those with a need to perform tasks on the TCS Host.

5. Contractor must monitor the TCS Host System application and all related servers. 6. Contractor shall manage the databases and services on all related servers

located at the Data Center. 7. Updates, patches or fixes for vulnerabilities rated critical by NIST (US-CERT) shall

be tested and installed within 48 hours of release from the vendor or third party provider. All other updates shall be installed and tested with 30 days of release. Where applicable the Contractor shall also employ patching in accordance with the Airports Authority’s patching standards as well.

8. Contractor shall monitor System, security, and application logs. 9. Contractor shall manage the sharing of data resources. 10. Contractor shall manage daily backups, off-site data storage, and restore

operations. 11. The Contractor shall monitor physical hardware. 12. The Contractor shall immediately report any breach in security to the Airports

Authority.


Pg. 92

The Contractor shall provide a TCS Host System and data storage strategy which prevents impairment to the operation of the System and does not require that the System be shut down to repair.

The Contractor shall ensure the TCS Host System and supporting resources are sized appropriately and scalable to meet a minimum 100% (2X) increase in operational and traffic growth projections (see the traffic growth projections contained in the Dulles Toll Road Comprehensive Traffic and Revenue Study, located at: http://www.metwashairports.com/file/CTR_Study2014.pdf).

The Contractor shall use effective data storage techniques for the management of data. These data storage techniques shall be defined in the detail design documents.

2.5.26.2 TCSHostHardwareandInfrastructureRequirementsThe Contractor shall furnish and install a complete TCS Host server and supporting infrastructure including data storage, data back-up, network communications and other hardware as needed to support the requirements of this project.

The TCS Host configuration shall include all cabinets and ancillary equipment to provide a complete, secure and acceptable system that meets the Contract requirements. The server configurations shall have redundancy to support the TCS’s availability requirements. Servers shall be specified, designed and configured to support disaster recovery procedures and ensure data security.

All servers, including all major hardware elements, shall be of the latest design and shall incorporate standard commercial products currently in production. The Contractor shall use proven server configurations that support future upgrades to processors, memory, storage, operating system, database, etc. Server virtualization shall be leveraged to achieve fault tolerance, redundancy and fast recovery during failures.

2.5.26.2.1 TCSPrimaryHostPhysicalRequirementsThe Contractor shall furnish and install the primary TCS Host System at the DTR Administration Building’s dedicated server room. During the pre-bid meeting and site inspection the Contractor shall inspect the current server room to determine available infrastructure and or any needed modifications. Any identified modifications shall be clearly represented in the proposal and as well any required inputs or resources of the Airports Authority shall be identified. The primary TCS Host shall meet the following minimum physical infrastructure requirements:

Secure access to the server room by authorized personnel only Secure access to rack systems and other related enclosures Video surveillance (i.e. NetBotz) Fire detection and suppression system Adequate heating, cooling and ventilation


Pg. 93

Redundant power supply (servers) Adequate power service Back up power – The DTR mainline does currently have a generator. UPS power

(see section 2.8)

2.5.26.2.2 TCSHostReportsServerThe Contractor shall provide a separate reports server. This server shall not access the production database but a near real-time replication of the production database. The report server shall provide the ability for users to run ad-hoc reports as well as predefined reports. The reports shall be available in both an industry standard Adobe .pdf format and an industry standard Microsoft Excel .csv format.

2.5.26.3 TCSHostSecurityRequirementsThe Contractor shall adhere to the following minimum security requirements related to both the Primary and Secondary TCS Hosts:

1. The Contractor shall employ security measures ensure that all application(s) and data are protected.

2. If Airport’s Authority data is hosted on multiple servers, data exchanges between and among servers must be encrypted.

3. All servers and devices must have currently-supported and hardened operating systems, the latest anti-viral, anti-hacker, anti-spam, anti-spyware, and anti-malware utilities. The environment, as a whole, shall have aggressive intrusion-detection and firewall protection.

4. All components of the infrastructure shall be reviewed and tested to ensure they protect the Airport’s Authority hardware, software, and its related data assets. Tests shall focus on the technical, administrative and physical security controls that have been designed into the System architecture to provide confidentiality, integrity and availability.

5. The Contractor shall notify the Airport’s Authority designee of any security breaches immediately following such occurrence.

6. The Contractor shall be solely liable for costs associated with any breach of Airport’s Authority data housed at their location(s) including but not limited to notification and any damages assessed by the courts.

7. The Contractor shall authorize the Airports Authority to perform scheduled and random security audits, including vulnerability assessments, of the TCS Hosts upon request.

2.5.26.4 TCSHostOperatingSystemThe operating system(s) for the TCS System shall consist of a multi-user, multi-tasking operating system. The operating system shall support all peripherals defined in these requirements. The operating system shall also support the proposed communications


Pg. 94

architecture, redundant configuration, database software, and Contractor’s application software.

The Contractor shall obtain all licenses required in the name of the Airports Authority. All licenses shall be provided to the Airports Authority for all off-the-shelf operating system software, in addition to original software installation titles and media. The Contractor shall retain authorized copies (backups) for all software media to use for periodic System Maintenance, upgrades, or restore, as required. Any operating system(s) shall have a future upgrade path and must be supported for a minimum of five (5) years from the date of Final Acceptance under any warranty and maintenance period. The proposed operating system(s) shall be covered under warranty during the Warranty Period.

The operating system shall be a proven system, used widely throughout the United States for intensive database operations, and should be compatible with the database and other web-based tools.

2.5.26.5 TCSHostSystemDatabaseThe TCS Host System is a critical system that is directly linked to financial viability of the DTR and its operations. The Airports Authority requires a high level of reliability and security from the database used for the storage of transaction data, toll collection management data, violation data, and all other data, as applicable, for the TCS. The Contractor shall use an industry standard, robust, highly available relational database management system (RDBMS) that is field-proven to operate in a transaction intensive environment. The Host system database shall provide the common functionality, elements and capabilities encountered in commercially available relational databases. Appropriate licenses shall be provided to the Airports Authority for all off-the-shelf database software. The proposed database software shall be supported during any warranty and maintenance period. The chosen RDBMS should have an upgrade path and should support upgrades to operating system, application, memory, disk drives, and processors.

2.5.26.6 DataBackupandDataRetentionThe TCS Host System shall be backed up on a minimum daily basis without manual intervention.

The Contractor shall describe in their proposal the proposed data backup strategy including data recovery and or retrieval processes. At a minimum the Contractor shall comply with the following backup and data retention requirements:

1. Contractor shall adhere to a defined and documented back-up schedule and procedure.


Pg. 95

2. Back-up copies of data are made for the purpose of facilitating a restoration and recovery of the data in the event of data loss or System failure.

3. Scheduled backups of all data must be completed regularly. At a minimum, data shall be backed up nightly, with one daily, one weekly, and one monthly data backup stored in a secure location to assure data recovery in the event of disaster.

4. The minimum frequency of backups shall be: o Daily differential backup o Weekly full backup

5. Any physical back-up media must be securely transferred from one physical location to another to avoid complete data loss with the loss of a facility.

6. Where data is personally identifiable (PII) or contains credit data, data must be encrypted in the operation environment and on any backup tapes or other secondary location.

Notification on the status of the backup process shall be sent to the MOMS. Tools shall be provided to view the backup data in a user friendly and readable form. If there is a catastrophic failure that results in the loss of data, the Contractor shall provide a means to retrieve the data without disruption to the Host operations. The Contractor shall provide a process that, at minimum stores a weekly full data backup at an offsite location.

The following rules for data retention shall be followed by Contractor:

1. Detailed transaction data shall be retained online for a minimum of two (2) fiscal years plus the existing fiscal year on the Host System (i.e. 3 years total) and then archived to permanent long-term storage disk.

2. Summarized transaction data shall be retained online on the Host System for at least ten (10) fiscal years plus the existing fiscal year.

3. System logs shall be retained online on the System for 120 days after which they are archived.

4. All other data shall be retained on the server for a minimum of two (2) fiscal years plus the existing fiscal year (i.e. 3 years total) after which they are archived.

5. Violation Images shall be retained for a minimum of ninety (90) days.

When the data storage utilization reaches a configurable capacity (to be set initially at 80%), a message shall be transmitted to the MOMS. Data shall be deleted only after it is confirmed to be successfully archived. Any deletion of data shall be automatic, without user intervention, and shall generate a message to be transmitted to the MOMS.

The TCS Host System shall be sized to accommodate the restoration of the archived data, if needed but such data shall not impact online data or reports. Users shall be


Pg. 96

able to generate queries from the restored or archived data. Detailed data storage sizing calculations shall be provided by the Contractor during the Design phase. The Contractor shall describe their data purging process/mechanism in sufficient detail in their proposal. The Contractor shall purge all data in accordance with the Code of Virginia § 46.2-819.1.B requirements governing the purging of information collected by toll collection systems.

2.5.26.7 DisasterRecoveryandBusinessContinuityAs indicated the Contractor shall provide a secondary TCS Host which supports expedited disaster recovery from a catastrophic failure of the Primary TCS Host and preserves to the greatest extent possible full business continuity. The Secondary TCS Host shall be physically located separately from the Primary TCS Host. The Contractor shall propose a site/location for the Secondary TCS Host which at a minimum ensures that any catastrophic failure to the Primary would not impact the Secondary TCS Host. The Contractor may propose to house the Secondary TCS Host at its own facility or other location. In either case the security and access requirements as stated shall apply the Secondary TCS Host site location. Additionally the Contractor may make use of the Airports Authority’s off-site data center in Ashburn, VA. Use of this facility will be at no additional cost to the Contractor. Details of this facility can be found at http://www.verizonenterprise.com/resources/factsheets/fs_sterling-dc-ashburn-va_en_xg.pdf. The Contractor shall provide and maintain full network communications between the Primary and Secondary TCS Hosts throughout the entire term of the Contract as well as any subsequent extensions. The Contractor shall design and implement a disaster recovery and business continuity solution which ensures that both the Primary and Secondary TCS System(s) are hardware, software and information redundant. The disaster recovery solution shall be designed, maintained and implemented such that full TCS System functionality is restored within three (3) calendar days in the event of a catastrophic failure such as complete physical or functional loss of the Primary TCS Host. The Contractor shall provide Disaster Recovery procedures for the TCS Host System that shall be implemented to ensure data security during a disaster. The TCS Host System shall be capable of performing all functions described in these specifications.


Pg. 97

The Contractor shall also demonstrate the capability of full disaster recovery during the System Acceptance Test and annually each year thereafter during the Annual Disaster Recovery Test.

The Contractor shall separately price the secondary failover solution in their cost proposal. The details of the proposed disaster recovery and failover solution shall be clearly defined in the proposal.

2.5.26.8 TCSHost‐DataCenter/SharedHosting(AlternateOption)With the understanding that there may be hosting solutions which leverage shared or third part data centers the Contractor may also propose an optional alternate TCS Hosting solution which utilizes shared or third party solutions. It should be noted that this is only optional. The Contractor is not required to provide a proposed shared TCS Host solution. Any proposed optional alternate TCS Host solution will not be considered or evaluated as part of the technical or price scoring.

In the event the Contractor wishes to propose an optional shared or third party hosted TCS Host solution they shall continue to meet the requirements of the TCS Host System as specified and in addition the following requirements as they may relate to shared or third party data centers:

1. The Contractor’s System support and maintenance shall commence upon the Effective Date and extend through the end of the Contract term.

2. Maintain the hardware and Software in accordance with the Specifications, terms, and requirements of the Contract, including providing upgrades and fixes as required.

3. The TCS Host System shall be supported at a minimum by a secure Class A Data Center, with a minimum Tier 3 availability.

4. Repair or replace the hardware or Software, or any portion thereof, so that the System operates in accordance with the Specifications, terms, and requirements of the Contract.

5. The Data Center must be physically secured – restrict access to the site to personnel with controls such as biometric, badge, and others security solutions. Policies for granting access must be in place and followed. Access shall only be granted to those with a need to perform tasks in the Data Center.

6. The Contractor shall immediately report any breach in security to the Airports Authority.


Pg. 98

7. The Airports Authority shall have unlimited access, via phone or Email, to the hosting facility technical support staff between the hours of 8:00am to 5:00pm- Monday thru Friday EST.

8. The TCS Host System for the Airports Authority shall be available twenty-four (24) hours a day, 7 days a week, except during scheduled and prior approved maintenance.

9. A regularly scheduled maintenance window shall be identified (such as weekly, monthly, or quarterly) at which time all relevant server patches and application upgrades shall be applied.

10. The Contractor shall use a change management policy for notification and tracking of change requests as well as critical outages.

11. A critical outage will be designated when a business function cannot be met by a nonperforming application and there is no work around to the problem.

12. Updates, patches or fixes for vulnerabilities rated critical by NIST (US-CERT) shall be tested and installed within 48 hours of release from the vendor or third party provider. All other updates shall be installed and tested with 30 days of release.

13. The Contractor shall maintain a record of the activities related to repair or maintenance activities performed and shall report quarterly on the following: Server up-time; All change requests implemented, including operating system patches; All critical outages reported including actual issue and resolution; Number of deficiencies reported with initial response time as well as time to close.

In consideration of any alternately proposed shared data center solution(s) the Contractor may make use of the Airports Authority’s off-site data center in Ashburn, VA. Use of this facility will be at no additional cost to the Contractor. Details of this facility can be found at http://www.verizonenterprise.com/resources/factsheets/fs_sterling-dc-ashburn-va_en_xg.pdf.

2.5.27 SystemAccess

Access to the TCS System shall be via a Graphical User Interface (GUI) application. Any new access shall be browser-based and only workstations connected to the TCS network shall be able to access to the System application via standard internet browsers such as Microsoft® Internet Explorer, Google Chrome and Mozilla Firefox. Based on the user’s access privileges the appropriate menus shall be made available. The Airports Authority shall have any required licenses to use such applications and the TCS shall accommodate the ability to allow any and all TCS workstations to access the application.


Pg. 99

2.6 DigitalVideoAuditSystem(DVAS)The Contractor shall provide a new Digital Video Audit System (DVAS) solution as part of the new TCS.

The DVAS shall perform video surveillance on both the pre-class and post-class sides of each toll plaza, providing full coverage of each DTR lane. The DVAS shall capture live video images, archive and recall video image records that will correlate with the toll transactions as they occur in the lanes. The DVAS is intended to provide Airports Authority’s audit staff with the capability to review video in time synchronization with toll transactions. The DVAS shall be designed to operate on a continuous availability basis, 24 hours per day, 7 days per week 365 days per year and as such must be maintained with the same rigor as the TCS.

The DVAS should not be confused with the VES or vehicle recognition systems that utilize optical character or image recognition to determine vehicle license plate or vehicle profile data.

The Contractor is encouraged to furnish integrated video solutions incorporating VES that may achieve economies in system design and maintenance.

2.6.1 DVASArchitectureandNetworkVideoManagementServer

The DVAS shall be integrated with the TCS and have access to the Host transaction database. The DVAS Network Video Management System shall provide video image storage and recall (via Hard Drive Array) that will support near real-time retrieval for a minimum of ninety (90) days and archiving of video greater than 90 days for up to one year. The DVAS shall provide a viewer capable of viewing a vehicle for at least one second along with its associated transaction data. The DVAS shall capture video in a manner to assure one or more usable images of the vehicle are obtained for vehicles traveling from 5 mph up to and including 100 mph. The DVAS shall capture, stream, and store video at 15 or greater images per second. The DVAS images shall be time synchronized with the toll collection data for the appropriate toll lane location and time stamped with the TCS clock to track each transaction. All transaction data will be matched up with each video image. All data with unusual occurrences shall be stored with each video image. The DVAS software shall provide password-protected access to this video data, which will be restricted to certain users. The software shall allow authorized users to search the video by day, time, plaza, lane or transaction ID. The DVAS shall make archived data instantly available when the transaction occurs. The DVAS application shall provide a GUI where the user would be able to advance through multiple images that correspond to the transaction information displayed on the same screen.

2.6.2 DVASCameras


Pg. 100

Each DVAS camera shall produce a digital image with an adjustable field of view (FOV) that is wide enough to visually observe no more than three (3) lanes of traffic with sufficient image quality that will enable the user to identify the visual characteristic of the vehicle, including the number of vehicle axles at night. The DVAS camera connectivity shall be IP based having an Ethernet type connection capable of supporting fiber optic data transmission. The design and quality of the DVAS camera is critical and shall provide images of sufficient resolution and clarity in all weather and lighting conditions. The DVAS camera shall be capable of rendering images in both color and black and white. DVAS camera housing shall be weather tight meeting specification IP66.

2.6.3 DVASApplication

Toll audit operations shall be supported by the DVAS Application where video images can be viewed in near real-time as they are recorded or later in time from anywhere within the TCS communications network. The DVAS interface shall be browser-based and have an integrated display that combines playable video images of actual traffic (from DVAS) with data from corresponding toll transactions or lane events. The DVAS Application will make it possible for the user to zoom in on an image to determine the type of vehicle or transaction that occurred. Users may access the corresponding video image by inquiry using a transaction number, or transaction date and time, or any unusual occurrence event associated with a toll transaction.

The Contractor shall provide user training on the DVAS Application.

2.7 StandaloneCapabilities

2.7.1 Lane

The lane controller shall operate in a stand-alone mode for a minimum of thirty (30) days if communications to the Host is down. When operating in this mode, the last known good files downloaded from the Host shall be used while processing vehicles. Upon re-establishing communications with the Host all back-logged data shall be transmitted without affecting the real-time operations or degrading the lane operations. If any lane downloads were initiated from the Host while the communications were down, then these files shall be re-transmitted to the lane controller to bring it up to-date.

The lane controller shall allow for the manual transfer, via portable media, of transaction data, image files, software, transponder status files, employee files, toll rates (if applicable) or other pertinent data required for continued operation until communications with the Host is re-established.


Pg. 101

In the event that in-lane credit card processing is implemented, the manual transfer of credit card data shall be in accordance with Payment Card Industry (PCI) standards (See Section 2.11).

Upon re-establishing communications with the Host all back-logged messages shall be transmitted to the Host without affecting the real-time operations or degrading the lane operations. Manually transferred transactions shall also be transmitted and the Host shall ensure all transactions are synchronized. If any downloads were initiated while the communications were down, then these files shall be re-transmitted to the lane controller to bring it up to-date; however, in the case of dynamic toll rate and travel times, only real-time data shall be transmitted (if applicable). Upon re-establishment of communications and successful transmission of all messages, a recovery message shall be transmitted to the MOMS.

2.7.2 Host

The new Host shall be capable of standalone operation in the event that communications with any of the TCS subsystems or communications to the E-ZPass CSC and/or VPC is degraded or lost. Transaction files and violation images to be sent to the E-ZPass CSC and VPC by the Host shall be stored for a period of ninety (90) days. Upon restoration of communications, the Host shall send the transaction and image data to the E-ZPass CSC and VPC and generate a report to track/audit what was sent.

2.8 PowerBackup(UPS)The Contractor shall provide a new UPS solution and shall replace the existing UPS hardware at the DTR mainline plaza and each ramp location.

The proposed UPS solution shall provide battery backup power to the entire mainline plaza (for all TCS operations) in the event of loss or failure of normal utility power for a minimum up-time of no less than thirty (30) minutes. A back-up generator exists at the mainline and it is the intention that the UPS solution shall cover the time period between any failure and restoration or use of the generator. The generator shall be configured to take up load within five minutes of a power loss.

The ramp locations shall provide UPS up-time of no less than one (1) hour. There are no generators at the ramp locations however the DTR maintenance staff (roadway maintenance) has the ability to use portable generators. The UPS solution at the ramp locations is intended to provide adequate coverage until such portable generators are located on-site.

The UPS design shall ensure continuous operation for TCS and support equipment and systems ensuring performance standards are met for revenue collection.


Pg. 102

Each UPS shall filter power to eliminate power spikes and under-voltages to the TCS equipment and shall report power problems and malfunctions to the Maintenance On-Line Management System (MOMS).

The rated output of the UPS shall meet the required AC power input of the connected equipment load plus 10 percent even after de-rating for high and low temperatures and elevations that may be present at the installed locations. All equipment and components in the racks, enclosures and cabinets shall operate normally when the UPS is under fully loaded conditions.

The UPS system shall perform the following functions:

1. Filter the power coming into the cabinet 2. Provide backup in case of service outages 3. Provide remote monitoring, including Web-based interfaces 4. Include rechargeable batteries that are capable of being charged by an

external source (such as a portable generator) and can reach a power level of 80 percent after two hours of charging.

The UPS system shall be installed for full on line configuration (line interactive type), providing automatic voltage regulation and power conditioning when under normal utility power. The transfer from utility power to battery power and vice versa shall not interfere with the normal operation of the connected TCS load or any devices within the System. Each UPS storage battery shall be of the sealed, maintenance-free type.

All electrical equipment as part of the UPS emergency backup power and electrical systems shall be UL 924 listed. The operating life of the UPS shall be a minimum of 10 years and operating life of the UPS batteries shall be a minimum of 5 years.

The batteries shall be of the type that does not release explosive or corrosive vapors to the atmosphere.

As part of the Detailed Design Document, the Contractor shall provide, site power schematics, equipment power schedules, UPS load calculations indicating UPS sizing for each corresponding UPS DTR site. The Airports Authority shall review and approve the UPS design and calculations as part of the DDD.

2.9 MaintenanceOnlineManagementSystem(MOMS)The Contractor shall provide an automated Maintenance Online Management System (MOMS). MOMS shall be a fully integrated with the TCS to monitor the status of all operational equipment in real-time. The MOMS may be part of the TCS Host System application software, or implemented as a separate application and or subsystem.


Pg. 103

The MOMS shall record equipment and process failures, for reporting and tracking alarm messages, notify maintenance personnel, log acknowledgements, generate and track service orders, maintain Preventative Maintenance schedules, generate repair history, and maintain parts inventory and asset management.

The Airports Authority shall have the ability to configure the priority level of each alarm and assign and change the escalation attributes. Addition of alarms shall not require any changes to the MOMS and the Airports Authority shall have the ability to indicate if an alarm should result in the generation of a work order and if an alarm should be considered in performance reporting.

The MOMS shall meet the requirements needed to support the maintenance operations as specified in this document. The MOMS shall support real-time paging of maintenance staff and shall be configurable to meet the Airports Authority operations requirements.

The MOMS shall have the ability to create manual work orders in events where one was not automatically created. The MOMS shall have the ability to determine response times, repair times, and lane down time from the data entered by the maintenance technician.

The MOMS may reside on the Host System or a separate server can be provided. If the separate server is provided, it shall meet the general hardware requirements set forth in this document. Authorized personnel shall have the ability to generate various operational, management and performance reports from the MOMS, including:

1. Summarized and Detailed Alarm History; 2. Maintenance Paging and Response History; 3. Work Order Status; 4. Equipment Inventory; 5. Equipment Changes in Availability and Status; 6. Total System Availability; 7. Preventive Maintenance; 8. Corrective Maintenance; 9. Response and Repair Times; 10. Tolling Location Operational Status; 11. Equipment Use History; 12. Equipment Repair History; 13. Equipment versions, software versions, firmware versions and serial numbers for all

equipment installed for the TCS or related Enhancements to the existing toll system;

14. Component failure trend analysis; and 15. Incident Logs and Lost Revenue Estimates.


Pg. 104

The Contractor shall work with the Airports Authority in configuring the MOMS to meet the Airports Authority maintenance needs as further detailed in this document.

2.9.1 MOMSAdministration

Scheduling of all preventive and predictive maintenance activities shall be performed through the MOMS and automatic work orders shall be generated at the scheduled times.

2.9.2 Failure/MalfunctionReporting

The MOMS shall be capable of reporting and tracking alarm messages and maintaining status, location, health, and attributes for all hardware, networks, and software procured, developed, furnished, and installed. All failures and alarms shall result in the creation of work orders and depending on the work order priority, the MOMS shall notify Maintenance staff electronically in real-time. The Airports Authority shall have the ability to configure the priority level of each alarm and assign and change the escalation attributes. Addition of alarms shall not require any changes to the MOMS and the Airports Authority shall have the ability to indicate if an alarm should result in the generation of a work order and if an alarm should be considered in performance reporting.

Maintenance staff shall have the ability to create work orders manually, enter data regarding the Maintenance status and close work orders.

The MOMS shall allow for the possibility of generating, at a minimum, five (5) different types of work orders. The MOMS shall also provide for the capability to build ad-hoc work orders for unusual occurrences of maintenance activities. Work order formats and specifications shall be determined during the design process and approved in writing by the Airports Authority prior to implementation. In addition, a work order shall include, but not be limited to, the following information regardless of its format:

1. Date/Time of Work Order Generation;

2. Date/Time/Location of repair or maintenance call;

3. Work Order Number (sequential); and

4. Failure or Malfunction description.

The MOMS shall allow for the automatic or manually activated paging of technicians once a work order has been generated. The notification method utilized shall be described in the proposal by the Contractor and shall be at the cost of the Contractor. The Contractor shall also provide details in the Maintenance Plan related to the escalation process of un-responded to events.

Maintenance staff shall be equipped with portable devices that allow them to access the MOMS, enter data remotely and completely manage work orders. The MOMS shall


Pg. 105

have the ability to determine and calculate initial acknowledgement times, response times (both remote access and on-site), repair times and lane and system down time from the data entered by the Maintenance technician. Equipment recovery messages shall also be reported through the MOMS. The MOMS shall not allow any user to modify the time stamp of an event, including the initial acknowledgement time, response time and repair time entered by a maintenance technician.

2.9.3 PerformanceandStatusMonitoring‐Real‐TimeDisplayandUserInterface

As part of the MOMS, a performance monitoring application shall be provided which will, on a real-time basis, provide information regarding the status of all levels of toll system equipment and performance. The performance monitoring shall be accessible from any TCS workstation provided the proper clearance level has been entered. The performance monitoring function shall be developed in such a way as to allow the user to select and observe the status and/or performance of several predefined levels of the toll collection system. The following is a breakdown of the various levels, and, at a minimum, the degree of information required to be displayed for each level:

1. Lane Level Components; 2. All equipment status;

a. Status of all lane applications; b. Lane ID/Type; c. Lane Location (Plaza, Lane No.); d. Current mode of operation (If applicable); e. Lane Operation Status – Open, Closed, Degraded;

3. Plaza/Host Level; a. Status of Lane/Plaza/Ramp Communications Link; b. Status of Plaza/Host Communications Link; and c. Status of Plaza/Host applications.

2.9.4 RemoteAccess/Dial‐UpNetworking

The MOMS shall be capable of providing remote access for maintenance and Airports Authority personnel through the LAN. Maintenance staff shall be equipped with portable field devices (laptops, PDA’s, tablets, etc) that allow them to access the MOMS with full functionality and ability to manage all work orders.

2.9.5 Inventory/SparePartsControl

A spare parts inventory of equipment shall be maintained and tracked by the MOMS. When spare parts inventory reach a configurable threshold, automatic replenish alerts shall be generated. The MOMS will be capable of generating purchase requests and track delivery of all toll related equipment. Further the MOMS shall be capable of tracking and identifying such variables as part warranty status, install date, manufacture date, order amount, etc.

2.10 CommunicationsRequirements


Pg. 106

The Contractor shall design an independent network, comprised of appropriate computing and networking devices, components and interfaces, which is robust, able to meet the TCS performance requirements and capable of interfacing with the SONET fiber backbone provided by Others. The Contractor shall submit the network design as part of the Detailed Design Document. The network design shall support TCS redundancy and availability utilizing the SONET Ring so that no single failure of a device will cause an operational failure.

The Contractor is responsible for furnishing and installing all communications infrastructure required to support the TCS operations. For areas of which no communications infrastructure exists, it must be provided by the Contractor at their cost. For areas where there is existing infrastructure, existing SONET connectivity, and such infrastructure must be surveyed and evaluated and deemed acceptable for use by the TCS.

The network design shall be based on open architecture standards that support future upgrades, while building on the existing DTR infrastructure and minimizing network down time. The network design must be able to accommodate reasonable future growth in traffic, electronic transactions and license plate images.

2.10.1 CommunicationsNetwork

Over the length of the DTR an ATM SONET communications backbone (provided by others) provides single mode fiber optic connectivity between the Mainline toll plaza and the ramp locations.

The new network topology shall support the entire DTR TCS. The network shall support all toll lane types which include E-ZPass only, Unattended (exact change) and Attended.

The Contractor shall provide a Detailed Design Document must include a network design topology showing the implementation of all types of lane data, including video switching for the DVAS, workstations, and field Hardware devices. The Detailed Design Document must also include the details for all servers, switches, connectors, patch cords, terminations and all other devices (including racks or other mounting infrastructure) necessary to accomplish the required connectivity to and throughout the Host. To the extent possible this connectivity shall be accomplished using the existing SONET communications infrastructure and in a manner that minimizes impact on the current toll operations and customer service during system deployment.

Communications cabling between devices on the network must be in accordance with the cabling standards and as appropriate for the particular cabling runs. The Contractor must provide patch cords to connect all supplied equipment to the communications infrastructure. All network communication cabling shall be CAT-6 or


Pg. 107

fiber optic. The Contractor must include a complete and detailed description of the physical cabling topology in the Detailed Design Document.

2.10.2 NetworkBackboneCoordination

The network backbone is an ATM SONET based shared network resource. The Contractor shall coordinate all network design with the Airports Authority and their designated contact for SONET network services in order to allow for integration.

2.10.3 LanetoHostCommunications

The Contractor shall design and furnish the communications network connectivity between the toll lanes (ramps and mainline) and the Host to support the TCS functionality. Any anticipated modifications to the mainline or ramp plazas shall be clearly identified in the proposal by the Contractor.

2.10.4 RamptoHostCommunications

Currently each ramp location to Host communications is via SONET backbone, except the Monroe Street Park and Ride ramp which utilizes a T1 line. The Contractor shall continue to utilize this resource for the new TCS. Any anticipated departure from this network topology shall be clearly identified in the proposal by the Contractor.

2.10.5 NetworkCommunicationsMonitoring

The Contractor shall provide a Commercial-off-the-Shelf (COTS) network monitoring and management software that can actively manage the performance and availability of the TCS servers, switches, applications, connections and websites. The network management environment shall:

1. Manage and monitor physical hardware as well as virtual servers such as VMware hosts of the TCS

2. Monitor all custom and “off-the-shelf” TCS applications including Active Directory and ODBC database (if applicable)

3. Contain tools to assist in resolving problems - start/stop services, kill processes, and restart servers

4. Work seamlessly over the network with minimal burden to network capacity and throughput

5. Utilize SNMP (Simple Network Management Protocol) V3 and contain the SNMP strings needed for management.

6. Out of Band (OOB) management connection that will not invade the transaction network.

The Contractor shall provide for the remote management of network devices by the Airports Authority or other designated network services personnel.


Pg. 108

The Contractor shall integrate the network communications monitoring software with the MOMS.

2.10.6 CommunicationsEquipment

As part of the TCS design and implementation, the Contractor shall furnish and install communications equipment to support the underlying Ethernet network. Ethernet network equipment, specifically layer-2 switches and layer-3 switches (high-speed routers) that are located either in the core layer of the network, at the Host or the main distribution frame (MDF) [also referred to as the distribution layer of the network]) in a mainline toll building or internal wiring closets (called intermediate distribution frames or IDFs [also referred to as the access layer of the network]).

Network equipment shall support the following network speeds:

10 Mbps Ethernet 100 Mbps Fast Ethernet 1000 Mbps (Gigabit) Ethernet 10 Gbps Ethernet (when available) 802.11 a/b/g/n wireless Ethernet

Modular chassis switches with redundant power supplies and hot-swappable modules are superior to stackable switches because they are more reliable and more easily expanded in terms of port capacity. Modular chassis switches have backplanes that interconnect all of the modules (or blades). These backplanes must have enough bandwidth capacity to allow all of the switch ports to operate at “line speed”. If there is insufficient backplane capacity, some reduction in the ports' maximum speeds will occur. The rule of thumb for backplane capacity is to sum up the bandwidth capacity of each port on the switch and divide that result by two. If stackable switches are used in an IDF, it is best to use ones with the highest capacity to meet the port requirements rather than cascading switches with smaller port capacities (assuming that the higher density switches have the backplane capacity to support the aggregate port capacity).

2.10.6.1 FunctionalNetworkRequirementsThe following Table 2-3: Network Functional Requirements constitutes a list of functional network requirements for each of the layers (C=core, D=distribution, A=access) and where noted, whether a layer-three (L3) switch is indicated:

Table 2-3: Network Functional Requirements

Functional Requirement Description Layers Required

IPv4 (RFC 1812 & RFC 2644) C, D(L3)


Pg. 109

IPv6 C, D(L3)

OSPFv2 (RFC 2328) C, D(L3)

OSPF NSSA (RFC 1587) C, D(L3)

IPX C, D(L3)

IPX RIP C, D(L3)

AppleTalk C, D(L3)

RTMP C, D(L3)

Differentiated Services (RFC 2475) C, D(L3)

Classification and marking of layer 4 traffic for timing-sensitive applications C, D, A

VRRP per redundant, L2-connected building (RFC 3768) C

Fully-redundant and fault-tolerant switch components C

Sufficient backplane capacity for non-blocking frame forwarding C, D, A

Wire-speed frame forwarding on all ports C, D, A

MAC Bridging (IEEE 802.1D) C, D, A

VLAN Tagging/Prioritization (IEEE 802.1p) C, D, A

Virtual LANs (IEEE 802.1Q) C, D, A

Multi-Link Trunking (IEEE 802.3ad) C, D, A

100BaseTX/FX Ethernet (IEEE 802.3u) C, D, A

Flow Control (IEEE 802.3x) C, D, A

1000BaseSX/LX/ZX Ethernet (IEEE 802.3z) C, D, A

Gigabit over Category 5 Wiring (IEEE 802.ab) D, A

AAA (RFC 2989) C, D, A

BGP4 (RFC 1771, RFC 1745, RFC 1965, RFC 1997, RFC 2385, RFC 2439, RFC 2798, RFC 2842)

C

BOOTP (RFC 951, RFC 1542) C, D, A

BOOTP/DHCP Relay (RFC 2131) C, D(L3)

DVMRP V3 (RFC 1075) C, D(L3)

IEEE 802.1x Authentication D, A


Pg. 110

IGMP (RFC 1812) C, D, A

IGMP V2 (RFC 2236) C, D, A

IP Forward Table MIB (RFC 1354) C, D(L3)

NTP (RFC 1305) C, D(L3)

PIM-Dense Mode (RFC 2362) C, D(L3)

PIM-Sparse Mode (RFC 2117) C, D(L3)

Radius (RFC 2865) C, D(L3)

RIP V1 (RFC 1058) C, D(L3)

RIP V2 (RFC 2453) C, D(L3)

RSVP (RFC 2205, RFC 2206, RFC 2207, RFC 2208, RFC 2209, RFC 2210) C, D(L3)

RMONv1 (RFC 1757 - Groups 1,2,3,9) C, D, A

SNMPv3 (RFC ) C, D, A

SNMP MIB II (RFC 1907) C, D, A

SSH Version 2 C, D, A

Syslog Support C, D, A

TFTP (RFC 783) C, D, A

Gigabit port mirroring C, D, A

Secondary IP addressing on routed interfaces C

VLANs based on non-standard subnet masks C, D, A

2.10.6.2 FunctionalSecurityRequirementsThe following table constitutes a list of functional security requirements for each of the layers (C=core, D=distribution, A=access) and where noted, whether a layer-three (L3) switch is indicated:

Table 2-4: Functional Security Requirements



Pg. 111


Support central security policy enforcement capability, e.g., check security baseline of any device connecting to the network and allow access only after baseline has been verified (or place the device in a quarantine zone, as needed, containing remediation software that can be installed on it). This shall include:

Anti-virus (AV) software version Endpoint security software version OS patch level Registered MAC address Appropriate IP address Inappropriate or unauthorized services

The System shall be up to date on all OS security patches and anti-virus software.

C, D, A

Work with Airports Authority's AV provider to verify AV policy compliance

D, A

Provide a solution to allow for planned firmware update management in communications devices

C, D, A

Support anomaly-based network intrusion protection system (IPS) sensors by simultaneously mirroring all ports on switch to IPS sensor port

C

Trigger security ACL changes based on IPS detection C, D, A

Identify network attacks: DDOS & DOS Violations of RFCs and stop unknown/unauthorized traffic

C, D, A

Event and audit logging to Security Information Management System (SIMS):

Communications device configuration modifications Failed communications device authentication attempts OSPF update tampering (only for OSPF participating devices) Unauthorized access (ports & services)

C, D, A

Security Assertion Markup Language (SAML) information exchange between communications devices and SIMS:

Network thresholds SNMP traps

C, D, A


Pg. 112


Device overflows Host configuration (services, password policy) RFC violations

Per port flow data C, D, A

2.10.7 Maintenance/Service

The Contractor shall be responsible for the maintaining the operational performance of the TCS communication network infrastructure under the warranty and any subsequent maintenance term(s).

At points where the network relies upon the SONET communication backbone provided by others, the Contractor shall coordinate with the Airports Authority’s designated contact for issues and problems related to SONET backbone.

2.11 PCIComplianceAs credit card processing is anticipated to be future component of the TCS, the Contractor shall design and deploy a TCS and underlying communications network that is fully PCI compliant upon deployment based on requirements set forth by the PCI Security Standards Council. The Contractor is responsible for all systems, subsystem and or devices that reside or operate within the chain of PCI data gathering, generation, transmission and storage shall be maintained at a level of 100% PCI compliant at all times. The system shall automatically mask any credit card information and shall not store any PII related information.

As part of the Detailed Design Document the Contractor shall provide a specific section describing how the design meets PCI compliance. At a minimum this section shall include, but not be limited to:

1. Network diagram with full credit card data flows; 2. Firewall and router configuration standards that address all PA-DSS and PCI-DSS

requirements; 3. Log locations are documented.

The Contractor shall ensure that the credit card payment functionality is both PCI-DSS compliant and PA-DSS compliant. Within 30 days of implementation, the credit card functionality shall be audited by the Airports Authority’s PCI and PA-DSS Qualified Security Assessor. The Contractor shall be responsible for the rectification of any non-compliance findings as a result of the QSA’s audit.


Pg. 113

For the Contractor that is performing on-going annual maintenance, the following should be done:

1. Vulnerability scans must be conducted on a quarterly basis and all vulnerabilities with a CVSS score of 4 or higher must be addressed and a re-scan issued until all vulnerabilities with a CVSS score of 4 or higher have been remediated. A report needs to be provided quarterly to the Airports Authority.

2. Internal and external penetration tests (Pentest) must be conducted at least once a year or after any major infrastructure change. A report needs to be provided to the Airports Authority annually.

3. Annual Incident Response Plan exercise. A report and post-action "lessons learned" need to be provided to the Airports Authority annually.

The Contractor’s PCI solution should include all necessary components such that:

1. File Integrity Monitoring Software or Change Detection Software must be deployed on a systems and devices that process, store or transmit cardholder data. The final monitoring and change detection software solution needs to be agreed-upon with the Airports Authority in advance of deployment;

2. Logs are active by default; 3. Logs are available for review; and 4. PCI compliant security protocols deployed on servers and related Infrastructure.

The Contractor shall be responsible for coordinating the performance of quarterly and annual PCI audits of the TCS during the initial Warranty Period and any additional maintenance term (if elected by the Airports Authority). The PCI audits shall be conducted by the Airports Authority’s Qualified Security Assessor (QSA). The Airports Authority reserves the right to assess damages resulting from fines or loss revenue, against the Contractor if the TCS is found to not be in compliance with PCI standards. Moreover, the Contractor shall adhere to both the PCI standards required of the Contractor’s software systems and the PCI standards required of the installation. The Contractor shall also provide the necessary support to the Airports Authority in any annual PCI Report on Compliance (ROC) and quarterly network scans.

The most current PCI standards and documentation information can be found at the following link: www.pcisecuritystandards.org

2.12 EnvironmentalRequirementsThe Contractor shall conduct all work necessary to deliver the Project while protecting and enhancing the environment. Elements of the work shall include, but are not limited to, the following:

1. The Contractor shall become familiar with all Federal, State, and local environmental regulations and issues.


Pg. 114

2. Avoid impacts to the community and to environmental, historic, archaeological, and cultural resources beyond those already approved by the regulatory agencies. If impacts are unavoidable, the Contractor shall make every effort to minimize and mitigate the impacts.

3. Foster good relationships with Federal, State, and local agencies; and local stakeholders by ensuring that the commitments the Airports Authority has made are reflected in the Project’s final design and are fulfilled during construction. The Contractor shall accomplish this by meeting or exceeding all Environmental Requirements and commitments listed in the Contract, Permits, environmental documents, regulatory agency permits, and regulatory agency Concurrence Letters.

4. Comply with all Federal, State, and local laws, regulations, and ordinances and not receive any permit violations, penalties or warnings.

5. Maintain clean and safe work zones, promptly removing all refuse, extra materials and temporary structures from the site on a weekly basis.

6. Work activities that produce airborne debris or dust must be contained as not to cause an impact to nearby traffic, personnel or landscape areas.

2.12.1 Weatherproofing

Contractor furnished outdoor enclosures, cabinets, junction boxes and housings shall meet the environmental requirements above and have a rating of NEMA4X.

Camera and Luminaries shall have weatherproof corrosion resistant housings or enclosures with an IEC rating of IP65 or better.

Wire and cables that will be exposed to outdoor conditions shall be rated for outdoor use having a UV resistant jacket.

Outdoor connections and connectors shall be weatherproof; rated for outdoor use and resistant to UV exposure. Outdoor antenna connections shall be properly sealed using manufacturer recommended methods and materials.

2.12.2 Enclosures,RacksandCabinets

All new enclosures, racks and cabinets shall be vented to the atmosphere allowing for either convection cooling, internal fans, or under floor (computer room) cooling. Enclosures shall be provided with appropriate access doors, closure panels, face panels, stabilizer kits, ventilation, mounting and installation hardware as may be necessary to provide a complete and operational installation of the TCS hardware.

Each enclosure front shall be enclosed with a tempered glass door and key lock to shield the electronics and systems from dust. The enclosure designs shall consider the allowable space at the mainline toll plaza data room where the servers are to be installed. The enclosures, enclosure panels, and hardware described in this section and


Pg. 115

the proposed equipment layout shall be submitted to the Airports Authority for Approval during the design process prior to purchase and installation.

All enclosures shall have, at a minimum 20% of the capacity reserved for future expansion.

2.12.3 Workmanship

All interconnection, data and power cabling shall be provided as necessary and shall be installed to provide a neat professional appearance utilizing cable management systems when necessary.

2.13 SystemSecurity

2.13.1 DataSecurityandIntegrity

The Contractor shall endeavor to protect all data. The Contractor shall submit an IT Security Plan, demonstrating the Contractor’s ability to preserve data integrity. The IT Security Plan shall be submitted to and approved by the Airports Authority as part of the Detailed Design Document.

The Contractor shall ensure that master data records, original transactions, once entered into the TCS cannot be deleted or changed. Master data records and files shall only be appended to and not edited or deleted. If manual intervention is required only authorized users with proper security access shall be permitted to ‘flag’ a file to ensure the integrity and provide a complete audit trail. All TCS access/entry, logins, and modifications (i.e. flagging actions) shall be recorded. Encryption shall be used for all confidential data including user passwords.

The Contractor shall follow industry best practices for data and system security. The use of wireless data access is discouraged; however in the event it cannot be avoided, all remote access to the TCS shall have two-factor authentication and any wireless data transmission shall be encrypted to WPA2 or higher in accordance with current industry best practices.

2.13.2 DataandAnti‐VirusProtection

The Contractor shall coordinate with the Airports Authority to provide appropriate Data and Anti-virus Protection throughout the TCS. The Airports Authority shall review and approve Anti-Virus software for the following environments:

Lane; Host; Workstations; External system interfaces; Remote access locations; and Internet.


Pg. 116

Data and Anti-Virus protection shall include, but not be limited to:

Password data security at workstation login; Data backup subsystems; Boot record and memory virus scanning; Disk and tape virus scanning; Communication link and data packet scanning virus scanning; and Import and export file virus scanning prior to standard file opening and/or

transfer. The Contractor shall, at a minimum, provide the following:

1. The method for maintaining and accessing updates from the current system, subject to the Airports Authority approval;

2. The latest version of Anti-Virus software, subject to the Airports Authority approval;

3. Update service for the virus dictionary and/or virus scanning software throughout the initial warranty, maintenance and any optional maintenance periods; and

4. Anti-Virus Operational procedures for daily updates to the servers, work stations and lane controllers.

All anti-virus software provided shall be regularly updated for new signatures and all security patches shall be promptly applied.

2.13.3 ComputerAccessSecurity

Access to all information on the TCS and computer network shall be approved by the Airports Authority and limited to authorized Airports Authority and Contractor personnel only and shall be password controlled. User access security including sign-on facilities, permission control, and different levels of access shall be provided for the files, directories, and application software. The Airports Authority and the Contractor shall develop the matrix of access levels during system design. The system should allow for changes to the access levels and additions of personnel in a secure manner. The system administrator shall be able to view and update access levels via a graphical user interface with the TCS software. The Contractor shall not circumvent the system security as designed and as Approved by the Airports Authority.

The Contractor shall conduct an initial Network Penetration Test during the Extended Operations Test, and annually during the Annual Security Test to verify that the TCS cannot be penetrated from internal or external attempts. At the Contractor’s discretion this may completed in conjunction with the PCI audit requirements as described in Section 2.11.

All flash drives and CD/DVD drives on the TCS workstations shall be disabled.

2.13.4 RemoteAccessPersonnelAuthentication


Pg. 117

Remote user access must be based upon unique, individual, TCS specific user accounts. All remote user access must be logged. The Contractor shall address during the Preliminary Design Review its intended approach to accommodating secured remote access. Final design of any remote access shall be approved by the Airports Authority. Remote access to the TCS shall require two-factor authentication.

2.13.5 PhysicalSecurity

2.13.5.1 TCSEnclosureAccessAccess to all TCS and associated network cabinets, enclosures, racks and vaults shall be key/lock controlled. Access monitoring to the enclosures is preferred but is not mandatory.

2.14 AccuracyRequirementsThe new TCS shall meet the accuracy requirements described in Table 2-5: TCS Performance Requirements provided below. The minimum number of transactions shown in the table is representative of the statistically significant sample size necessary to demonstrate the required accuracies at a 90% confidence level.

Table 2-5: TCS Performance Requirements

ID Performance Requirement Description Accuracy

Required

Minimum no. of

Transactions

Transaction Creation Accuracy

The Lane Controller shall correctly correlate all lane event data into a single transaction for each vehicle that passes through the toll lane.

Total transactions created Total vehicles in data set

≥ 99.95% 4,604

Transponder Detection Accuracy

The AVI subsystem shall correctly detect all correctly installed and mounted E-ZPass tags in vehicles passing through the toll lane.

Total detected transponders Total vehicles with transponders in data set

≥ 99.95% 4,604

Transponder Association

The AVI subsystem shall correctly associate all E-ZPass tags installed in vehicles passing through the toll

≥ 99.95% 4,604


Pg. 118


Required

Minimum no. of

Transactions

Accuracy lane to the correct vehicle.

Total correctly associated transponders Total vehicles with transponders in data set

E-ZPass Transaction Transmission Accuracy

The AVI subsystem shall transmit 100% of E-ZPass transactions captured in the toll lanes to the E-ZPass CSC under all operating conditions.

Number of E-ZPass transactions sent to the E-ZPass CSC Number of E-ZPass Transactions reported from the lanes.

100% 4,604

Vehicle Detection Accuracy

The AVC subsystem shall correctly detect all vehicles that pass through the toll lane.

Total detected vehicles Total vehicles in data set.

≥ 99.9% 2,301

False Tag Read Accuracy

Reading an E-ZPass tag in a vehicle traveling in an adjacent lane.

Total transponder reads from adjacent lane Total vehicles traveling in adjacent lane

≤ 0.2% 1,150

Vehicle Classification Accuracy

The AVC subsystem shall correctly classify all vehicles that pass through the toll lane.

Total correctly classified vehicles Total vehicles in data set

≥ 99.8% 1,150


Pg. 119


Required

Minimum no. of

Transactions

Image Capture and Reporting Accuracy

The VES subsystem shall capture at least one front and one rear human readable license plate image for each violating vehicle that passes through the toll lane regardless of weather, lighting or vehicle position or speed.

Total violations with at least one front and one rear human readable images captured Total violations in data set

≥99% 219

OCR Accuracy

The OCR subsystem shall return correct OCR results returned for 80% of all human readable plates including plate number, type and jurisdiction.

Total images with correct OCR values Total human readable images in data set

≥80% 4,604

Incorrect Violation Image Capture Accuracy

Capturing violation images for vehicles with properly mounted transponders and good E-ZPass accounts.

Number of violation images captured for E-ZPass vehicles with transponders in good standing Total E-ZPass transactions in data set

≤0.2% 1,150

Image Transmission Accuracy

The VES subsystem shall transmit 100% of violation images captured in the toll lanes to the VPC under all operating conditions.

Number of violation images sent to

100% 160


Pg. 120


Required

Minimum no. of

Transactions

the VPC Number of violation images reported from the lanes.

Cash Toll Collection Accuracy

The TCS shall correctly process, record and report transactions for all vehicles paying cash in the toll lanes.

Number of correct cash transactions Total vehicles paying cash

≥ 99.8% 1,150

Automatic Coin Machine Accuracy

The ACM shall accurately collect the correct toll in the lane for each vehicle

≥ 99.8% 1,150

Lane Controller Data Storage

The lane controller shall be capable of storing a minimum of 30 calendar days of all lane events and transaction data including violation images.

Calculated by running a lane stand alone for 1 day. Extend calculation to represent 30 days. Verify disk space used against total disk size/availability.

≥ 30 Days

The Contractor shall validate that the new TCS performs to the accuracy specified for each performance requirement by using transaction datasets that meet or exceed the minimum statistically significant sample size using both controlled traffic with “scripted scenarios” and live traffic for each test as described further in this document. All times-of-day and traffic conditions shall be proportionally represented within the datasets. Transactions that fail to meet the performance requirements shall be reviewed and audited and the anomalies will be investigated.


Pg. 121

2.15 AvailabilityThe Contractor shall meet availability requirements listed below in Table 2-6:

Table 2-6: TCS Availability

Availability Requirements (Monthly)

TCS Component Availability Requirement (%)

Monthly Downtime Allowed (mins)

Conventional Lanes 99.5 216

Express Lanes, OCR, DVAS, MOMS, LSSs, Communications Network

99.9 43

TCS Host 99.95 22

An available lane is defined as a lane with all of its associated subsystems (AVI, AVC and VES) and hardware (ACM, MLT, PFI, ITL and LSS) properly functioning and available to collect revenue and send required transactions, violation images and messages to the TCS Host. If any of the lane subsystem or lane hardware ceases to function, the lane shall be considered unavailable.

An available TCS Host is defined as a Host that is properly functioning and available to receive data transmitted from the lanes and properly process and transmit the data to the E-ZPass CSC and VPC. A failure of a lane shall not be included in the Host availability calculation.

TCS Component Availability will be calculated on a monthly basis using the following formula (Lanes to be calculated on a per lane basis):

Total Days within the Month x 24 hours per day x 60 (Minutes) – Downtime (Minutes) Total Days within the Month x 24 hours per day x 60 (Minutes)

Downtime shall be defined as:


Pg. 122

(elapsed time between notification and response) + (Repair time beyond two hour repair window)

2.16 ChargeableandNon‐ChargeableFailuresFor purposes of calculating Availability performance requirements for testing and for Maintenance performance, chargeable and non-chargeable failures are defined as follows:

2.16.1 ChargeableFailures

Chargeable failures include any failures that are not specifically identified as non-chargeable including, but not limited to, the following:

1. A malfunction which prevents the TCS component (hardware or software) from performing its designated function, when used and operated under its intended operational and environmental conditions as detailed in this document.

2. A malfunction that poses a threat to the safety of the toll collection system components, toll collection system patrons, employees or others.

3. An occurrence where data is not successfully transmitted between the lanes and the Host to the E-ZPass CSC/VPC unless such failure is already accounted for as a separate performance failure (e.g., if the lane is not functioning and does not transmit data to the Host, the lane would be charged for the failure but the System would not).

4. A failure of equipment or software that allows revenue loss to occur on the TCS that is not already accounted for as a separate performance failure.

5. Software anomalies and bugs that affect the performance and operation of the TCS.

6. Shutdown or unavailability of the TCS unless specifically directed by the Airports Authority.

7. Failure to properly register or report a transaction. 8. Failure to properly reconcile the toll collection system. 9. Failure to electronically send or receive transaction and payment information. 10. Failure to send required E-ZPass or violation transactions to the E-ZPass CSC and

VPC. 11. Failure to generate the reports required to reconcile and audit the System. 12. Failure to publish tag files to the lane controller and or lane subsystem.

2.16.2 Non‐ChargeableFailures

Non chargeable failures shall include:

1. Force majeure, as defined in the applicable Contract Documents.


Pg. 123

2. Vandalism. 3. Failure of a test facility or test instrumentation. 4. System component failures caused by externally applied stress conditions outside

of the requirements of this document. 5. System component failures caused by environmental or operating conditions

outside of the requirements of this document. 6. Normal operating adjustments as allowed in the Test Procedure or Maintenance

Plan, as applicable. 7. Failures or accidents that are patron or user induced.


Pg. 124

3 TCSINSTALLATIONREQUIREMENTS

3.1 InstallationScopeofWorkandRequirementsThe Contractor shall procure, install, terminate and test all equipment required as part of the new TCS as set forth in this document. The Contractor shall also procure, furnish, and install any new enclosures, conduits and or cable runs required to operate the new TCS. Any required maintenance of traffic (MOT) and lane closures and shall be the responsibility of the Contractor and coordinated with the Airports Authority. The Contractor shall follow the work zone safety policies and guidelines set forth in the most current and approved version of the Virginia Work Area Protection Manual.

3.1.1 InstallationandConstructionCoordinationandMeetings

3.1.1.1 Bi‐WeeklyInstallationMeetingsThe Contractor shall schedule and conduct bi-weekly installation meetings during the active installation phases (Phase IB) of the project. The Contractor and any Subcontractors shall ensure that the appropriate personnel are present at these meetings, who can represent the Contractor’s interest and provide the information necessary in a meaningful manner. The Contractor shall prepare and distribute a meeting agenda at least 24 hours prior to the scheduled meeting. The meeting agenda shall consist of those items pertaining to the installation and schedule for the previous and current week’s installation efforts, as well as a two week forecasted schedule of activities. All issues that arose during the installation activity for the week shall be discussed and acted upon. At this meeting, the Contractor should also be prepared to address any issues or questions by the Airports Authority. The Contractor shall document the meeting discussions and distribute the meeting documentation to the team. The Contractor shall also record and maintain an action items list that tracks all installation related issues. The Contractor shall also create and maintain a risk register to identify on-going risks and activities for mitigating such risks.

3.1.1.2 ConstructionCoordinationAs the primary efforts on this project are not expected to require any significant civil work, the Contractor shall be prepared to coordinate if necessary with other Airports Authority Contractors. In the event of such need the Contractor shall coordinate closely with the Airports Authority, and any other Airports Authority Contractors in all aspects of the Project. The Contractor shall:

1. For any TCS equipment provided by the Contractor, provide all required Design and installation drawings, operating requirements and installation instructions to the Airports Authority and its third party Contractors;

2. Review any third party Contractor provided drawings with respect to the TCS and approve all aspects of such drawings related to the toll system, and

3. Ensure the Contractor’s needs necessary to meet the requirements set forth in this document are met with regard to such design. This includes responsibility for


Pg. 125

ensuring that the locations, positions, installation, connections and other elements of the Contractor inputs identified on the design and installation drawings provided by the Contractor for all Contractors and the Airports Authority provided equipment, whether in-roadway, canopy mounted, or otherwise located, shall meet such requirements.

3.1.2 SystemInstallationRequirements

The Contractor shall supply all personnel, tools, vehicles, materials and equipment required to perform the complete installation of the new TCS, including but not limited to all equipment and vehicles required for overhead canopy installation work; specialty equipment for preparation and saw-cutting of loops as required, and provide necessary test vehicles, cameras and equipment to adequately test the installed System in accordance with the Approved test plan.

Where the Contractor is providing subsystem components manufactured by a third party vendor, the Contractor shall ensure that all such components are installed in accordance with manufacturer’s installation guidelines. In addition, Contractor shall provide such subsystem manufacturer on-site and remote support as is necessary to ensure the proper installation and operation of its equipment at no additional cost to the Airports Authority.

The Installation scope of work includes but is not limited to:

1. Verify clean power to all toll collection equipment. 2. Where necessary furnish and install all connecting conduit from wire ways

provided and installed by others and/or stub conduits to the equipment. 3. Verify, and install if necessary separate grounding for the TCS, surge protection

devices (SPD), junction boxes, pull boxes, conduits, and other such items as required by the installation standards and requirements.

4. Where necessary furnish and install all wiring for all in-lane equipment and connections to the enclosures. This includes the proper termination of all power, communication, and RF cables and/or wiring (copper or fiber optic) required to connect the individual components into a fully operational TCS.

5. Furnish and install all equipment racks and enclosures required for the in-lane electronics, including environmental control devices and UPSs, as required.

6. Furnish and install all equipment brackets to support structures. 7. Furnish and install all electronics and other devices in their respective equipment

racks and enclosures as required to provide a fully operational TCS. 8. Where necessary furnish and install the AVC system equipment, including in-

pavement sensors or overhead mounted equipment as specified. Includes all Airports Authority approved materials, equipment and supplies required for saw-cutting, wiring and sealing of wires in the roadway.


Pg. 126

9. Install the AVI system equipment, including antennas, readers, related equipment, cables, and any support brackets required. All AVI mounting hardware, junction boxes, and cables shall be procured and supplied by the Contractor.

10. Furnish and install the VES equipment, including cameras, VES illumination, and any video controller equipment, sensors, software, controllers/servers, or specialty equipment associated with the VES.

11. Furnish and install the VSS equipment, including cameras, mounting poles and brackets, and any video controller equipment, sensors, software, controllers/servers, or specialty equipment associated with the VSS.

12. Furnish and install the DVAS equipment, including cameras, mounting poles and brackets, and any video controller equipment, sensors, software, controllers/servers, or specialty equipment associated with the DVAS.

13. Furnish and install the LSS’s, including cables, brackets, controllers and any other required equipment.

14. Validate all cable and wire terminations via a test process to ensure that the cable is connected to the correct location on each end and that the cable/wire is properly terminated.

15. Power up and provide a field check out/installation Acceptance Test of all Systems, to be witnessed and approved by the Airports Authority or its designated representative. Provide the completed installation checklist.

16. Where necessary tuning and testing of the AVI system, as described in, and in full accordance with, manufacturer’s guidelines.

17. Calibration and testing of VES in full accordance with manufacturer’s guidelines. 18. Where necessary, calibration and testing of AVC system in full accordance with

manufacturer’s guidelines. 19. All other items, materials, and equipment to complete installation in accordance

with this specification. 20. All other items, materials, and equipment to complete testing in accordance

with this specification. 21. Decommission, removal and disposal of any obsolete System components in

accordance with the Airports Authority’s rules and regulations.

3.1.2.1 InstallationChecklistAs part of the Installation Plan, the Contractor shall develop an installation checklist that tracks the progress and completion of all installation activities. The checklist shall be the document detailing those items required for the installation crew to complete the installation process for all equipment and components, including terminations and connections. A copy of the checklist signed and approved by the Contractor, attesting to the completeness of the installation, shall be provided to the Airports Authority after the completion of the installation activities for each lane at each tolling location. The


Pg. 127

Contractor shall conduct a final inspection of all installations and certify the installation work.

3.1.3 CompliancetoStandards

The Contractor shall adhere to all installation standards, applicable laws, ordinances and codes as required, including but not limited to NEC, Airports Authority, FHWA, IEEE and OSHA, for areas including but not limited to electrical codes, traffic control, seismic considerations, or environmental. All installations shall meet such requirements. The Contractor shall be responsible for all costs associated with any permits, plan reviews, and inspections. It shall also be the Contractor’s responsibility to procure all documentation required to install and adhere to the proper installation standard, law, ordinance, or codes.

Prior to beginning any construction work, the Contractor shall apply for, and obtain a Construction Permit from the Airports Authority, per the Airports Authority’s Building Codes Manual, which can be found on the Airports Authority’s website at http://www.mwaa.com/business/airports-authority-design-manual .

3.1.4 ElectricalWork

Electrical work to be performed shall include, but not be limited to the following general items of work:

1. Provide and install surge protection devices as required to protect the TCS equipment and electronics.

2. Install junction boxes and terminate new cable and conduit attachment devices, where applicable.

3. For any new work, bond all conduits, manhole frames, metallic junction boxes, and other conductive items to the grounding system in conformance the NEC.

All electrical work shall be performed in accordance with the applicable regulations. Appropriate NEC compliance shall be adhered to with all electrical articles for installation pertaining to wiring, enclosures, and other electrical equipment in hazardous locations. UL labels shall be provided for all electrical components.

All electrical equipment must be inspected prior to installation for defects that could damage the equipment or harm personnel. Any equipment found to have defects shall not be installed but shall instead be replaced with a fully functioning replacement.

All electrical equipment shall be properly grounded for safety. Refer to the following Section 3.1.4.1.7 Bonding, Grounding.

3.1.4.1 ElectricalRequirements


Pg. 128

All electrical material, equipment, wire, cable and components furnished by the Contractor shall meet all the applicable standards of ASTM, NEC, NEMA, IEEE, OSHA, FHWA and ASTM; shall be new, of the latest design and within twelve (12) months manufacture, in an operable condition at the time of installation. Equipment operation shall not be affected by transient voltages, surges and sags normally experienced on commercial power lines.

The power requirements of the New TCS shall comply with all applicable industry regulations, codes, and safety requirements and shall follow best industrial practices. The Contractor shall submit to the Airports Authority for approval a complete wiring diagram or drawing of the work to be done before installation of conduit or electrical equipment.

The Contractor shall ensure that the operation of all new TCS equipment shall not be affected by transient voltages, surges and sags normally experienced on commercial power lines. The Contractor is responsible for surveying the local power service to determine if any special design or power conditioning equipment is needed for the TCS. In the event that additional power design and equipment is required to support the TCS, the extra cost shall be identified separately in the Pricing Proposal.

The TCS design shall include all necessary utility upgrades to properly operate the system being installed.

The power requirements of the system shall comply with all applicable industry regulations, codes, and safety requirements and shall follow best industrial practices.

The Contractor’s electrical design shall include supporting calculations and documentation that there is sufficient power available for all the TCS equipment at all toll facilities.

3.1.4.1.1 InstallationRequirementsThe Contractor shall install the New TCS equipment and associated wiring in accordance with all industry standards, NEC, National and local building codes. All services by the Contractor shall be performed in a workmanlike and professional manner by qualified and licensed personnel. The Contractor shall be responsible for obtaining all necessary permits and approvals to perform all needed civil and electrical work at each facility. The Contractor shall not make final connections of the newly installed components to the existing system until receiving approval from the Airports Authority.

In the course of its work the Contractor notices or identifies any existing work or elements that may potentially be out of compliance they shall immediately notify the Airports Authority. The Airports Authority will work with the Contractor to determine what, if any, action may be required.

3.1.4.1.2 MountingofEquipment,ConduitAttachmentandComponents


Pg. 129

The Contractor shall provide surface mounting of equipment, conduit attachment and components according to the manufacturer’s standard specifications. Mounting and fastening hardware components for stainless steel channel supports shall be stainless steel. Mounting and fastening hardware components for powder coated enclosures shall be stainless steel.

The Contractor shall use stainless steel mounting hardware such as bolts, nuts, washers, and external hinges on vaults, cabinets, shelters, junction boxes, and other devices. Surface mounting to concrete shall use stainless steel fasteners of sufficient size and penetration depth to support the load. The Contractor shall use only components designed for ten (10) or more years of industrial use.

3.1.4.1.3 InspectionThe Airports Authority and or its representative(s) reserve the right to perform any necessary inspection of work for verification of any code or standard compliance. The Contractor shall be responsible for notifying the relevant Building Code Inspector(s) to inspect all construction work related to the installation of the new TCS as required by the Airports Authority’s Building Codes Manual (which can be found on the Airports Authority’s website at http://www.mwaa.com/business/airports-authority-design-manual .

3.1.4.1.4 Conduit

In the event new conduit is required the Contractor shall provide conduit according to the following specifications:

Installation of conduit shall conform to appropriate articles of NEC and this section. In new conduits, electrical or low voltage signal conductors shall occupy a maximum of twenty-six (26) percent of the cross-section of the conduit. In existing conduits, conductor fill shall meet NEC requirements for conduit with three or more conductors, and shall occupy a maximum of forty (40) percent of the conduit’s cross-sectional area. New conduit shall be supplied as a system matching existing conduit in place; all required fittings, terminations, and other installation accessories; all in accordance with this section.

Where larger size conduit is used, reducing couplings will not be permitted so conduit shall be same size for the entire length of the run.

The internal ends of all conduits, metallic and non-metallic shall be reamed to remove burrs and rough edges. Field cuts shall be made square and true. Slip joints or running threads will not be permitted for coupling metallic conduit; however, running threads will be permitted in traffic signal head spiders and rigid galvanized steel (RGS) outer-duct. When installing RGS conduit standard coupling cannot be used, an approved 3-piece coupling shall be used. Threads on all conduit shall be rust-free, clean. All couplings shall be tightened so that a good electrical connection will be made


Pg. 130

throughout the entire length of the conduit run. All conduit including spare conduits shall be installed with bushings. All conduit including spare conduits shall be installed with plugs, which shall not be removed until installation of conductors or pull string. Upon installation of wiring at other locations, conduit shall be sealed with proper sealant. Upon installation of the pull string, spare conduit shall be plugged.

Where PVC conduit is installed, conduit shall be schedule 40, with the exception that roadway crossings and service lateral runs which shall be schedule 80. Metallic and nonmetallic conduit installation shall include equipment grounding conductor and shall conform to requirements noted in the Standard Plans.

Fittings and support spacing shall be installed in accordance with the NEC and local codes. Where surface mounting of conduit is required, supports shall consist of stainless steel channel with stainless steel or galvanized 2-hole clamps sized for the conduit. Channel supports shall be installed with stops, to prevent clamps from sliding out of the ends. Channel installations shall provide for future conduit installation. Channel shall be at least one (1) foot longer than required.

Where conduit is surface-mounted, approved expansion, deflection, and/or combination expansion/deflection fittings shall be installed at all expansion joints. Expansion fittings shall be installed for up to four (4) inches of horizontal movement. Deflection fittings shall be installed for up to ¾-inch movement in all directions.

3.1.4.1.5 ElectricalSystemsandElectronicCableThe Contractor shall not splice electric or electronic cables without the Airports Authority’s approval. The Contractor shall use 1-piece cables between termination points for power, communications control, and RF antenna cables.

When using crimp-on connectors, the Contractor shall install the insulation of electrical cables deep enough into the lug so that the insulation acts as a strain relief. The Contractor shall maintain the electrical continuity of the cable shields. The Contractor shall comply with all manufacturers’ requirements for cable and connector terminations.

3.1.4.1.6 WiringThe Contractor shall provide wiring system according to the following:

1. At each junction box, power supply and communication wires and cable shall be labeled with a PVC marking sleeve

2. Power supply circuits the sleeve shall bear the circuit number

3.1.4.1.7 Bonding,GroundingThe Contractor shall verify a proper ground exists at each facility and bond to the existing grounding system. All electrical equipment shall be properly grounded for


Pg. 131

safety. Most equipment shall be furnished with grounding pads or lugs. All ground connections shall be cleaned immediately prior to connection. The Contractor shall provide all grounding material required but not furnished with the equipment. No grounding conductor shall be smaller in size than 12 AWG unless it is a part of an acceptable cable assembly. Ground connections made to metallic cold water piping system at such locations shall be readily available for inspection. Where cold water piping is not available, use other available or made electrodes as described in NEC Sections 250-81 or 250-83. The Contractor shall ensure that protection devices are suitable for the specific installation and equipment being supplied, in accordance with NEC, NEMA, ASTM and UL. The Contractor shall ground and bond equipment according to NEC, NEMA, ASTM and UL.

3.1.4.1.8 SurgeProtection

The Contractor shall provide surge protection incorporated into all electrical paths in order to safely divert energy spikes to an acceptable ground for any new electrical work or system component installation. The surge suppression shall be utilized in conjunction with the grounding system and lightning arrestors to protect equipment.

3.1.5 WorkStandardsandRequirements

To the extent possible TCS installation shall be scheduled so as not to disrupt or delay traffic during the installation process. The Contractor shall make every effort to schedule work around peak traffic movement times. In the event that extended lane closures are required, closures may have to be accomplished during night hours. Final testing and installation/testing of the cash lanes are more likely to apply to these requirements.

All TCS installation shall be performed according to the Airports Authority Approved set of installation plans. The Contractor shall provide project management and oversight of all work performed. At all times when installation work is taking place, the Contractor shall have an individual designated Installation Manager on-site to supervise the installation.

The Contractor shall provide a safe environment for the installation process in accordance with all applicable local, State and federal requirements, as well as any Airports Authority policies. Examples would include but not limited to the following examples:

1. Safety harnesses shall be included and employed on all lifts, and the personnel trained on their use.

2. Hard hats and safety vest shall be worn in all construction areas. 3. Safety toe shoes shall be worn in construction areas and around active

roadways while performing installation processes. 4. Regular safety meetings shall be scheduled to review safety procedures.


Pg. 132

3.1.6 FCCLicensing

The Contractor shall assist the Airports Authority staff in securing all required FCC licenses required by providing information required for the FCC application such as frequencies, location information, and other related information. The Contractor shall be responsible for assisting the Airports Authority in updating their existing FCC license as necessary in accordance with FCC procedures.

The Airports Authority shall own the FCC license for all tolling equipment required to have one.


Pg. 133

4 TCSTESTING

4.1 OverviewThe requirements described in this section detail the labor, materials, facility, and support services necessary to test the TCS. The testing shall be conducted in various phases and stages as detailed below, to validate the TCS integrity, reliability, functionality and compliance to the requirements set forth in this document including the following technical requirements.

Throughout the project TCS testing shall be completed in the following sequential steps:

1. Factory Acceptance Test (FAT) 2. System Acceptance Test (SAT)

a. Onsite First Installation Test (OFIT) b. Statistical Performance Test

3. Installation Commissioning Tests 4. Extended Operations Test (EOT) 5. Annual Performance Test 6. Annual Disaster Recovery Test 7. Annual Security Test

Each test indicated above shall be supported by an approved test procedure/script by the Airports Authority and/or its Representative. Test procedures shall be submitted no later than 30 days prior to performance of each test. This is intended to allow the Airports Authority and/or its Representatives adequate time to review each test procedure and comment prior to test execution. Each test procedure shall specifically describe such items as testing logistics, resource needs, schedule(s) of events, coordination, etc. Any and all costs associated with performance of the tests shall be borne by the Contractor including any transaction processing costs.

At the completion of each test indicated above the Contractor shall provide a detailed test report which describes the test performance, results including all anomalies, failures, etc. The test report shall be reviewed and approved by the Airports Authority and/or its Representatives. Approval of the test report shall be the mechanism used to indicate approval to move the next test phase or project milestone.

If there are any failures or anomalies in conducting any test step, the Contractor shall take the necessary corrective action and the test shall be repeated. In the case that corrective action is undertaken by the Contractor, it shall perform all necessary regression testing to ensure that such corrective action has not adversely affected the system’s ability to pass any previously conducted test steps. If necessary this process shall continue until success is achieved and approved by the Airports Authority.


Pg. 134

The objective of TCS testing is to ensure that the TCS is systematically and thoroughly tested for compliance with this document and operates reliably in accordance with Airports Authority Business Rules and Policies. Testing shall be completed using actual equipment and vehicles. Simulation of messages, events or components will not be permitted. Furthermore, the Contractor shall represent in their proposal, the ability to conduct Factory Testing at a test track type facility where replicas of at least one DTR conventional MLT/ACM/E-ZPass lane and one Express E-ZPass lane are constructed and operational.

The TCS provided by the Contractor shall be tested and certified to be interoperable with all E-ZPass agencies, and the entire TCS shall be tested and commissioned prior to opening for revenue collection. The Contractor shall be responsible for all test logistics (coordinating lane closures with the Airports Authority, test vehicles, transponders, drivers, etc.) and coordination activities. The Contractor shall provide the test facility that meets the requirements of the testing program. The Airports Authority and/or its Representatives shall only witness and approve the testing and the Contractor shall be responsible for all aspects of the testing. Approval of any aspect of testing shall not relieve the Contractor of the responsibility to meet the full requirements of the Contract.

4.2 MasterTestPlanThe Contractor shall be required to provide a Master Test Plan covering all aspects of testing within the time specified in

Table 6-2: Deliverable Deadlines, for the work described in this document.

4.3 FactoryAcceptanceTest(FAT)The Factory Acceptance Test (FAT) shall be conducted by the Contractor to verify that all functional elements of the TCS and components provided by the Contractor are in conformance with the Airports Authority technical and operational requirements and the final System Design as approved by the Airports Authority. Additionally during FAT the Contractor shall demonstrate the TCS’s ability to operate under periods of heavy processing loads. The FAT test procedures shall include provisions for stress and load testing of the TCS. The Contractor may use simulated processes to perform stress and load testing.

During FAT the Contractor shall demonstrate the TCS ability to prevent unauthorized access and represent communications and networking safeguards to prevent any unauthorized access or use within any of the TCS subsystem or modules.

The FAT shall be conducted at the Contractor’s test track facility in accordance with the Approved Master Test Plan and test procedures. The test procedures shall document the test configuration and all exceptions shall be noted.


Pg. 135

The Airports Authority and/or its Representatives shall witness the FAT and the results of such testing shall be subject to Airports Authority Approval. FAT shall provide sufficient evidence to the Airports Authority and/or its Representatives that the new TCS meets the operational requirements of this document and any subsequent design document and is ready to be installed on-site.

Upon completion of the FAT, the Contractor shall submit a test report to the Airports Authority for Approval that details the results of the test. Upon the completion of any re-tests and Approval of the FAT by the Airports Authority, the Contractor shall be given the authorization to move forward to the On-site First Installation Test.

4.4 SystemAcceptanceTestingFollowing successful completion of the FAT the Contractor shall be permitted to begin System Acceptance Testing (SAT). SAT shall be completed in two distinct phases:

1. On-Site First Installation Test (OFIT); and 2. Statistical Performance Test.

The SAT will be conducted at a DTR Toll Plaza that has the new TCS fully installed and is an intended to be an “end-to-end” test that will be used to test the functionalities and accuracies all the TCS subsystems through the Host and onto the E-ZPass CSC and VPC.

All costs associated with the SAT testing efforts, including E-ZPass CSC and VPC transaction processing costs, shall be paid for by the Contractor.

4.4.1 On‐SiteFirstInstallationTest

The objective of the On-site First Installation Test (OFIT) is to verify the full functionality of the TCS and its compliance with the requirements of this document and any subsequent design document in a controlled, on-site environment. OFIT shall include a representation of each lane type/mode. The Contractor shall conduct the OFIT in a single toll lane, to be determined by the Airports Authority, where all the new TCS components and functionality can be installed and tested. After successful completion of the OFIT, the lane in which the OFIT was conducted will be allowed to go live for revenue collection but shall continue to report transactions to the legacy Host until the new TCS is fully accepted by the Airports Authority. All equipment provided for the TCS or related enhancements to the existing TCS by the Contractor shall be part of this test including the communications network. The Host System shall be installed in its final locations and all interfaces to other entities shall be tested and ready prior to the start of the OFIT. The Contractor shall detail in the Master Test Plan the logistics of the testing.

As part of the OFIT the Contractor shall also test ability of the UPS at the mainline plaza.

The UPS testing procedure shall provide for operational testing of the following:


Pg. 136

1. UPS Power Module 2. Surge Suppressor 3. Automatic Transfer Switch 4. Generator Power Transfer Switch 5. Maintenance Bypass Switch

The UPS field test shall demonstrate the loss of utility power and the switch over to battery power without interference with the normal operation of the TCS or any devices supporting the toll system.

The Contractor and the Airports Authority shall agree on a test site(s) and the Contractor shall work with the Airports Authority in setting up the lane and installing all equipment in the lane. All equipment and software that is required for the new TCS shall be in place, and prior to the start of the test. The Contractor shall formally notify the Airports Authority that the TCS is “ready” for testing. The test shall be conducted by the Contractor and witnessed and approved by the Airports Authority and/or its Representatives. The test shall be conducted in accordance to approved test procedures and test schedule, all in accordance with the requirements in this document. Once successful completion of the OFIT has been achieved the Contractor shall complete installation of new equipment in the remaining lanes at the plaza.

As part of this test, the Contractor shall update the Requirements Traceability Matrix that was reviewed and approved by the Airports Authority identifying each requirement and the tests conducted that prove compliance to the Contract requirements. It shall be the Contractor’s responsibility to ensure that each requirement is certified and/or tested for compliance.

Any and all anomalies shall be documented and categorized in the OFIT Test Report and corrected, subject to the Airports Authority approval.

Upon the successful completion and approval of the OFIT, any further changes to the software shall be fully documented and made only with the approval of the Airports Authority and/or its Representatives. Depending on the changes made to the TCS, the Airports Authority reserves the right to request a re-test of the entire or part of the OFIT. The objective of this is to ensure that changes to one part of the TCS do not have a negative effect on the rest of the System.

4.4.1.1 InterfaceTestingAs part of the OFIT testing, TCS to E-ZPass CSC and TCS to VPC interface tests shall be conducted to verify that the interface developed meets the requirements of this document, requirements identified through coordination with the Airports Authority TCS Contractor and E-ZPass CSC and VPC Contractors during the design process (if applicable). The Contractor shall work with the E-ZPass CSC and VPC Contractors to develop the detailed test procedures that describe all aspects of the interface testing


Pg. 137

and validation of each test requirement. The interface test shall be coordinated with the E-ZPass CSC and VPC Contractors and testing shall be conducted in accordance with the Approved test procedures. The Contractor shall coordinate this testing with the Airports Authority and the E-ZPass CSC and VPC Contractors where applicable.

4.4.1.2 DisasterRecoveryTestAs part of the On-site First Installation Test, the Contractor shall also demonstrate the Disaster Recovery process in accordance with the Disaster Recovery procedures approved by the Airports Authority.

4.4.2 StatisticalPerformanceTest

The Statistical Performance Test shall provide a statistically significant sample size of toll transactions to evaluate the accuracies of the new TCS. This test shall be completed utilizing controlled test vehicles (i.e. no live uncontrolled traffic) and “scripted scenarios” with expected results published before the test is conducted. The same plaza that is used for the OFIT shall also be used to conduct the Statistical Performance Test and at least two adjacent lanes shall be used to conduct this Statistical Performance Test. The test will encompass all subsystems and performance accuracies as defined in Table 2-5: TCS Performance Requirements.

The dependability of each portion of the TCS, as specified herein shall be evaluated using the data collected during the SAT.

In conducting the Statistical Performance Test, the Contractor shall design their test scripts to achieve the minimum sample size of usable transactions as indicated in Table 2-5: TCS Performance Requirements, in order to validate the performance requirements at a confidence level targeted at 80%.

4.4.3 MeasurementofErrors

Automatic Vehicle Classification System – An AVC error occurs when the AVC system (either pre-class AVC or post-class AVC) incorrectly or fails to classify any vehicle. It can be either an over-class (AVC higher class than actual class) or an under-class (AVC lower class than actual class). Another type of error occurs when a TCS report incorrectly counts transactions by classification.

Violation Enforcement System Images – A VES error occurs when the System fails to transmit images for a toll violation; the front and/or rear image does not have the vehicle plate visible in the image; the front and/or rear image for the violating vehicle is not the correct vehicle; an image is generated for a non toll violation. Another type of error occurs when a TCS report incorrectly counts violation transactions.

E-ZPass System Errors – An E-ZPass System error occurs when a transaction is not recorded; transaction data in file does not match what was expected from the lane (an AVC error would not be an E-ZPass System error); an E-ZPass transaction is recorded


Pg. 138

for the wrong vehicle. Another type of error occurs when a TCS report incorrectly records and reports E-ZPass transactions.

Attended/Unattended/E-ZPass Lane Cash Toll Collection Errors – This error occurs when a toll collector is unable to record a cash transaction on the MLT; the MLT transaction detail does not match with the detail for that transaction on the plaza monitor. Another type of error occurs when a TCS report incorrectly records and reports the cash transactions. This shall also apply to lanes where the lane fails to recognize or process fares deposited into the ACM.

Only failures encountered during the Statistical Performance Test deemed, by the Airports Authority and/or its Representatives, as beyond the control of the System, will be excluded as part of a reliability measure. Such failures may include an improperly located tag, an obstructed tag, or a damaged tag as defined herein. Unsuccessful transactions resulting from equipment or software failures shall be included in all measurements. Other specific tests during the Statistical Performance Test shall include:

1. File Transfers to demonstrate data file transfer between the lane, the Host and the E-ZPass CSC and VPC. Partial and full file transfers shall be tested.

2. Archiving of old files to demonstrate the archive and deletion of files functions. 3. Demonstrate the non-interruption of in lane operations during the E-ZPass CSC to

Host to lane file transfers. 4. The ability of the lanes to operate in stand-alone mode when the Host is not

available. 5. The ability of the lanes to operate in degraded modes. The correctness of

Diagnostics/Status messages that flag improper, degraded, or inoperable performance shall be determined, should any occur.

4.5 CommissioningTestUpon the successful completion and approval of the results of the SAT and subsequent test report, the Contractor shall be given the authorization to begin the complete installation of the TCS. As each lane is installed it shall undergo a Commissioning Test to validate the functionality and operational status of the lanes. Every piece of in-lane equipment and its interface to the Host shall be verified to be fully operational. During this test the lane interface to the Host and the E-ZPass CSC and VPC interfaces shall be validated to ensure that the communication system is in place and the Airports Authority TCS to ready for revenue collection.

The entire communications network shall be exercised to ensure that bandwidth is appropriately sized and the network is configured to handle the expected traffic conditions. The installation of all equipment and software, and their operations shall be verified end-to-end.


Pg. 139

Upon the successful completion of the Commissioning Test and approval of the test report, the Contractor shall begin the ninety (90) day Extended Operational Test for the TCS.

Specific to Commissioning at each of the ramp locations, the Contractor shall also field test the UPS system to assure that all components are operational within manufacturer’s tolerances.

4.6 ExtendedOperationsTest(EOT)A ninety (90) day Extended Operations Test (EOT) shall be conducted by the Contractor upon successful completion of installation and commissioning. The System shall be observed in live operations by the Contractor and the Airports Authority and/or its Representatives for a minimum of one (1) continuous calendar month to cover a full monthly audit cycle. During this period System accuracy, performance, reliability, and audit-ability shall be verified. The Contractor shall demonstrate in the Master Test Plan the proposed mechanism for verification of performance.

In order to verify system accuracies and performance compliance, the Contractor shall include the use of video capture for validation purposes. The details of how the video will be setup and utilized shall be described in the EOT Plan.

Over the course of the EOT period, a minimum of 10,000 usable transactions (under live conditions) shall be collected for verification.

As a component of the EOT the MOMS alarms, reporting and supporting use of the DVAS shall be analyzed. Anomalies identified shall be categorized by criticality and resolution of all anomalies shall be made by the Contractor, subject to Airports Authority Approval. These tests shall be repeated until the Airports Authority and/or its Representatives is satisfied that the TCS meets the requirements as set forth in the Approved design documents and the System requirements.

An integral part of the EOT will include verification of the E-ZPass CSC and VPS interfaces, reconciliation of transactions transmitted from the TCS to the E-ZPass CSC and VPS, collector audit and reconciliation, ACM vault audits and bank deposit audits.

4.7 AnnualPerformanceTestDuring and throughout each maintenance term, the Contractor shall perform an Annual Performance Test of the TCS. The Annual Performance Test is intended to verify that the system performance accuracies and availability has been maintained and has not degraded. The Annual Performance Test shall be conducted within 30 days of the anniversary of the commencement of the first year maintenance coverage. Performance accuracies and availability shall be tested and verified to be in compliance with the requirements as identified in Table 2-5: TCS Performance Requirements.


Pg. 140

The Contractor shall identify in the Master Test Plan and subsequent test procedures, the methodology, approach, and process for representing the results of the Annual Performance Test. The Annual Performance Test may be a combination of both review of historical data, collection of live data and or use of controlled tests. The Annual Performance Test plan and procedures shall be subject to the review and approval of the Airports Authority. Further the Airports Authority reserves the right to perform any ad-hoc or additional tests it deems necessary to validate system compliance.

4.7.1 AnnualPerformanceTestReport

Within 15 days after the Annual Performance Test has been completed the Contractor shall submit a report of the results. The Annual Performance Test Report shall include but shall not be limited to the following:

1. A summary of the overall test results highlighting the general conclusions of the testing and any problems found and corrected; and

2. An appendix containing the test results and data used in evaluating the system’s operational performance.

4.8 AnnualDisasterRecoveryTestThe Contractor shall perform an Annual Disaster Recovery Test of the TCS to verify that the Host can be failed over seamlessly from the primary system to the secondary system and then restored back to the primary system.

The Contractor shall identify in the Master Test Plan and subsequent test procedures, the methodology, approach, and process for representing the results of the Annual Disaster Recovery Test. The Annual Disaster Recovery Test plan and procedures shall be subject to the review and approval of the Airports Authority. Further the Airports Authority reserves the right to perform any ad-hoc or additional tests it deems necessary to validate system compliance.

Within 15 days after the Annual Disaster Recovery Test has been completed the Contractor shall submit a report of the results. The Annual Disaster Recovery Test Report shall a summary of the overall test results highlighting the general conclusions of the testing and any problems found and corrected.

4.9 AnnualSecurityTestThe Contractor shall be responsible for performing an annual Security Test to verify that the TCS cannot be penetrated from internal or external network penetration attempts. The Annual Network Penetration Test shall be performed by an Airports Authority approved third party security auditor. At the Contractor’s discretion this may completed in conjunction with the PCI audit requirements as described in Section 2.11 PCI Compliance


Pg. 141

Within 15 days after the Annual Security Test has been completed, the Contractor shall submit a report of the results. The report shall a summary of the overall test results highlighting the general conclusions of the testing and any problems found and corrected. The Annual Security Test Report shall also include an annual summary of the PCI audit tests for the previous year.

4.10 IndependentTestRepresentativeThe Contractor shall provide a separate Independent Testing Representative (ITR) throughout each testing phase. The ITR shall provide independent testing oversight and validation of all testing efforts. It will be the role of the ITR to work directly with the Contractor in development of test plans/procedures, execution of testing and observation of test results and analysis. The ITR shall also report directly to the Airports Authority on the status of all testing efforts and provide guidance to the Airports Authority on success or failure of the various test phases.

The Contractor shall consider and include the ITR as an extension of its staff for input and observation during any testing related activities including draft test document preparation as well as test performances, data analysis and reporting.

The Contractor shall provide the ITR access to all pertinent test information and data at the direction of the Airports Authority for each test phase including (but not limited to):

1. Any test plans, scripts developed by the Contractor. These will be reviewed and approved by the ITR prior to execution of any test.

2. Problem tracking records, punch-lists, ticket reports, etc.

3. Any data generated by the conduct of testing (both informal and formal).

The ITR shall be present for all formal testing and sign off on any and all formal test documents/reports prior to submittal to the Airports Authority.

In the event that additional testing is required due to failed or rescheduled test cases and or test efforts beyond what is agreed to in the baseline schedule the Contractor shall be responsible to retain the services of the ITR until successful completion of all testing milestones.


Pg. 142

4.11 QualityControlTestBenchEnvironmentAs part of the initial system design and develop phases the Contractor shall establish a dedicated test bench environment. The test bench environment shall be setup, configured and kept current with all System enhancements, updates, etc. to mimic the production system. The Contractor shall use this test bench to perform any and all necessary testing and or regressions testing of new features, enhancements, bug fixes, etc. prior to deployment on the production system.


Pg. 143

5 PROJECTMANAGEMENTANDEXECUTION

5.1 ProjectReportingandMeetings

5.1.1 MonthlyReportandProgressMeeting

Monthly progress meetings (in addition to the bi-weekly installation meetings during the active installation periods) shall be conducted on-site at the offices the Airports Authority at a reoccurring date/time to be jointly agreed by the Contractor and the Airports Authority. The purpose of these meetings shall be to monitor progress, discuss design issues and plan for system installation, test and start-up of operations. The Contractor shall attend the monthly progress meetings in person. Three working days prior to the meeting, the Contractor shall submit a monthly progress report of the previous month to the Airports Authority. The form of the Monthly Report shall be agreed to as one of the initial project tasks upon NTP and shall be incorporated into the Project Management Plan. The reports shall include the following components:

1. A summary outlining progress and status, and the labor, materials and the percentage of work performed for each task in the Project Schedule. Comments shall be included where appropriate. The summary shall also identify key deliverables met and missed in the period.

2. The report shall include an analysis of all critical path tasks, potential risks associated with the tasks and proposed contingency/work around plans to circumvent delays to the Project.

3. A discussion of Schedule compliance and an updated Project Schedule showing proposed changes from the baseline Approved Project Schedule, if any, and showing progress from the previous month for discussion purposes. If no Project Schedule change has occurred, the Contractor shall so state.

4. An updated action items list that tracks the status of all outstanding Deliverables, activities and issues that need decision/resolution.

5. A progress payment request, if applicable. Progress payment requests will only be considered as a part of the Monthly Report package.

6. A list of change order requests and their status shall be submitted with the Monthly Progress Report.

7. A summary of the time devoted to the Project by each Key Staff for the immediately preceding month.

8. The previous monthly meeting minutes for Approval. 9. A six (6) week look-ahead schedule. 10. A Risk Register and Mitigation Report.

5.1.2 ProjectMeetings

In addition to the monthly progress meeting, weekly project status meetings, and other regularly scheduled or ad-hoc Project meetings may be required during the course of the Project to deal with specific issues as they arise. It is anticipated that in addition to


Pg. 144

regular overall project status meetings, project specific technical meetings, and interface development meetings shall also take place, as needed.

The Contractor shall perform the following tasks related to all meetings including but not limited to:

1. Distribute notices of Project meetings in accordance with document control requirements;

2. Prepare the agenda in coordination with the Airports Authority; 3. Attend the meeting with all required staff in attendance; and 4. Prepare draft minutes of the meeting and forward them to the Airports Authority

within five (5) working days after the day of the meeting.

5.2 StaffingIt shall be the Contractor's responsibility to maintain and assign a sufficient number of competent and qualified professionals and other technical personnel to meet the project schedule and requirements.

5.2.1 KeyPersonnel

As a part of their proposal as well as the Project Management Plan, the Contractor shall provide the Airports Authority with an Organization Chart that identifies the Contractor’s employees dedicated to this Project (the “Key Staff”). The chart shall identify Key Staff responsibilities and the resources to be used in fulfilling the requirements of this document.

Replacement of Key Staff personnel shall be submitted to the Airports Authority for review and Approval prior to replacement of individual.

5.2.2 StaffingPlan

The Contractor shall identify in the Project Management Plan staffing requirements at a level immediately below the Key Staff required to meet project requirements. The Staffing Plan shall, in addition to identifying personnel immediately below Key Staff, provide a time line reference for anticipated resource requirements for the duration of the project

5.3 DocumentationThe Contractor is required to provide various hardware; software; requirements; design; testing; installation; and maintenance documentation that include Contractor-developed documentation and thirty-party documentation. Documentation on the various TCS subsystems, components and equipment shall be provided as part of the Detailed Design Document (DDD) and shall include manufacturer's operational manuals, programming manuals, installation and shop drawings, schematics, performance specifications, circuit descriptions, and catalog cut sheets.


Pg. 145

All documentation provided under the Contract shall meet the requirements described below. All Contractor-developed documentation for the new TCS may be provided in the form of updated existing documentation or new documentation as appropriate.

Airports Authority shall retain all rights to reproduce any contractor provided documents.

5.3.1 ContractorDevelopedDocumentation

Detailed and accurate documentation is required to ensure sustainability of the TCS and that the Airports Authority can operate and maintain the TCS. Detailed documentation shall enable the Airports Authority to understand the TCS, thus resulting in better performance of audit and reconciliations. It also shall assist the Airports Authority in making better, informed decisions on any required System changes or revisions to Business Rules.

Draft copies of all documentation shall be submitted to the Airports Authority for review, and comment and the Airports Authority shall have the right to require additional interim drafts at no additional cost should draft documentation submitted not be of adequate quality, or does not incorporate the Airports Authority review comments, or have missing or incorrect information.

The Contractor shall submit two (2) hard copies and two (2) electronic versions of all Contractor developed documentation for the Airports Authority review and Approval unless otherwise stated. Acceptable softcopy formats are Microsoft Office®, Microsoft Project® and AutoCad for Contractor prepared documentation as listed below. Additionally the Airports Authority may also request documentation to be submitted in PDF for ease of distribution and review by staff.

5.3.1.1 ProjectManagementPlanThe Contractor shall submit a Project Management Plan (PMP) to the Airports Authority for review and Approval. The PMP shall describe how the Contractor plans to implement and manage the project including staffing, scheduling, communication procedures for controlling all correspondence, submittals, and other communications between the Contractor and the Airports Authority.

The PMP shall at a minimum include the following elements:

1. A description of the management and organization of the program, an organization chart, identification of Key Staff and their responsibilities and identification of the resources to be used in fulfilling the requirements of the Contract.

2. A description of the planning and reporting methods to be utilized, both for use within the Contractor’s staff and externally to the Airports Authority.

3. The Contractor’s Quality Assurance and Quality Control Plan.


Pg. 146

4. How day-to-day operations, general issues, and problems are communicated to the Airports Authority.

5. How the Project Schedule and performance are reported and tracked for development activities and transition activities.

6. Risk Register – As part of the PMP develop an initial Risk Register of potential risk items. The Risk Register shall be updated throughout the project in collaboration with the Airports Authority and submitted with Monthly Progress reports. The Risk Register shall also contain information such as risk description, potential impact, severity, mitigation actions, responsible party, etc.

7. Document the change order request submittal and approval process.

8. Document the invoice submission, verification, and approval process.

9. A section on communications that addresses: a. Correspondence – Correspondence shall be identified as to originator and

designated receiver. b. Document Control – The Contractor shall manage the Project

correspondence through Document Control software to which the Airports Authority shall be a user and have access.

c. Submittals - All submittals shall be submitted as an enclosure to the Contractor's submittal letter. Each submittal letter shall be limited to a single subject or item. The Contractor's letter shall identify the letter itself, Contract Number, Contract Name, and Subject of the submittal.

d. Contract Number and Name - All items of correspondence, submittals, and documentation shall contain the Contract Number and the designated project name.

e. Information - No party shall be entitled to rely on any information unless it is in writing and received from the other party’s Designated Representative.

f. Change Orders - Any change orders from the Airports Authority shall be in writing and shall be executed by one of the Airports Authority’s Designated Representatives and one of the Contractor Designated Representatives. The form of change order will be directed and Approved by the Airports Authority.

g. Access to Contractor Key Staff – The Airports Authority or the Airports Authority’s Designated Representative who is knowledgeable in the field of work, shall have unlimited access to the Key Staff during the Contractor’s performance of the Contract.

10. A section on transition with the current TCS maintenance provider. 11. A section on coordination with the E-ZPass CSC/VPC.

5.3.1.2 Schedule


Pg. 147

The Contractor shall develop a detailed Project Schedule that lists all tasks related to the design, development, testing, installation and deployment of the TCS in Microsoft Project® format. Coordination with the third party civil Contractor shall be identified and all interfacing tasks clearly documented. The Project Schedule shall identify all critical dates and events starting with the Notice to Proceed through the end of the warranty period.

The Project Schedule shall include all draft submissions and review cycles. The Project Schedule shall form the basis for all subsequent schedules and updates throughout the duration of the Project. The Project Schedule shall be baselined upon Approval and the Contractor is required to update the Project Schedule on a monthly basis showing percent complete. Critical path tasks shall be clearly identified. All changes to the baseline Approved Schedule must be approved by the Airports Authority.

5.3.1.3 TCSDesignDocumentation

5.3.1.3.1 DetailDesignDocumentA Detailed Design Document (DDD) will be required as part of this Contract. All deliverables shall be made in accordance with

Table 6-2: Deliverable Deadlines.

The Contractor shall verify interface compatibility among items of equipment to be utilized. The Contractor shall assess risk in all areas of development and provide detailed information on how they will be addressed.

The Contractor shall provide functional narrative text, system and subsystem block diagrams, data flow diagrams, data structure diagrams, schematics and any other graphic illustrations, detailed engineering drawings, shop or fabrication drawings and engineering specifications to demonstrate all elements of the proposed system design.

The DDD submittal shall address and show compliance for system hardware and software with quality assurance, reliability, maintainability, software development, and other requirements of these specifications.

Approval of the DDD does not release the Contractor of the overall responsibility of ensuring that all design requirements, as specified, have been achieved in the final system design.

The Contractor shall submit a DDD that describes the design specifications of all hardware and software provided as part of the TCS to meet the Approved requirements of the Contract. Hardware Design shall describe all hardware specifications, third-party software, configuration, and testing. Software Design and configuration shall be described to the process and module level for all of the functions detailed in the Scope of Work and approved requirements. The DDD shall be submitted


Pg. 148

in draft form, after which the design reviews shall take place. Upon completion of the design reviews, the DDD shall be revised and submitted to the Airports Authority for review and approval.

The DDD shall include, but not be limited to:

High Level Overview; The specification sheets for all equipment; In-lane equipment, equipment enclosure layout and interconnections; Listing of all functions, the source of the baseline code (project used

on), version and date; The requirements for all peripheral device interfaces and control; Listing of all software languages used and for what; Standards, and conventions used; All user interfaces; Lane and Host layouts, and logic and timing details; Degraded mode of operations and impacts of failure on System

operations; Module level descriptions and interaction among various modules; All operational and Business Rules (to be used as a standalone

document); Interface Control Documents for all interfaces (standalone

document(s)); System data dictionaries; Report and screen format (Including table references and data

sources); Database design and configuration; Data flow diagrams and table configurations; Security access system layout and interconnections; UPS sizing; Computer/Server sizing and design details; Updated RTM; and IP Scheme/Network Architecture diagrams (including subnets).

The DDD shall demonstrate that the Contractor understands the functional and operational requirements of the TCS and has the processes and policies in place to provide a high quality and reliable product that meets the requirements of the Contract.

5.3.1.3.2 ShopDrawingsThe Contractor shall submit shop drawings detailing the installation design that shall be used on-site for lane, plaza, ramp and Host for installation work. Detailed drawings shall be provided for each lane configuration and if measurements differ from site to site, these variations shall be noted. All documentation regarding the TCS equipment shall be maintained by the Contractor and made accessible to the Airports Authority for


Pg. 149

review. All documents should have updated and visible version and revision numbers, titles and other information. Examples of documentation to be provided include but are not limited to:

Detailed installation drawing for each piece of equipment Detailed electrical schematics Detailed roadside enclosure layout and interconnections drawings Detailed equipment rack layout and interconnections drawings Detailed communications layout Sketches, both hand drawn and computer generated Memos denoting changes or modification requirements All red line drawings

At the completion of the installation, when all changes and modifications have been incorporated and Approved, this documentation shall be supplied to the Airports Authority as part of the as-built package.

5.3.1.4 MasterTestPlanThe Contractor shall submit to the Airports Authority, within the time specified in

Table 6-2: Deliverable Deadlines, a detailed plan for testing all components of the TCS. This plan shall include component testing, functional tests and all other tests culminating in the performance of the Factory Acceptance Test, System Acceptance Test, and Extended Operations Test.

The Contractor’s test plan shall be subject to approval by the Airports Authority and/or its Representatives. The Airports Authority and/or its Representatives shall be permitted to participate in or otherwise observe any and all of these tests. The Airports Authority shall be notified of the time and place the tests are to be conducted by the Contractor in writing at least ten business days in advance.

The Contractor shall develop detailed test procedures, including pass/fail criteria, for each of the types of testing to be conducted and shall submit these test procedures to the Airports Authority for review and approval at least twenty (20) business days prior to the scheduled start of the testing. Only preapproved test procedures shall be used for the testing.

5.3.1.5 InstallationandTransitionPlan

5.3.1.5.1 GeneralRequirementsThe Contractor shall develop a detailed Installation and Transition Plan. The Installation and Transition Plan shall be a comprehensive document that addresses all elements of the project beginning with system design and configuration, and following through to testing, installation, and the seamless transition from the existing TCS to the new TCS including full maintenance and support during the warranty and any subsequent


Pg. 150

maintenance period. The Installation and Transition Plan shall include and define, at a minimum, the following items:

1. The installation and transition schedule, detailing phases and/or installation and transition segments. Once the baseline schedule is approved by the Airports Authority updates during the installation periods identifying all schedule changes and work progress in the form of percentage completions shall be submitted to the Airports Authority.

2. Details on the transition approach from the legacy system to the new TCS including any potential parallel operation of the new Host, to decommissioning of lane and systems, installation, test and commissioning of toll lanes and plazas.

3. The minimum resource allocation (personnel and equipment) requirement for any installation and transition task.

4. Installation and transition checklist. 5. How the Contractor manages delivery, staging and installation of lane

equipment and Host to be installed. 6. The order in which equipment items are to be installed with estimated durations. 7. Any required prerequisite activities to be accomplished by other Contractors. 8. The coordination between third party Contractors, including, where applicable

any civil Contractor(s), the existing TCS maintenance provider and the E-ZPass CSC and VPC Contractor(s).

9. Any special or unique installation requirements. 10. How the Contractor shall manage system redundancy and applicable disaster

recovery facility. 11. A detailed component list and how each item version number and serial number

shall be recorded and accurately input to the MOMS for each installation 12. Organization Chart defining key personnel, roles and responsibilities and contact

information. 13. Training requirements. 14. A Go-Live Plan

As part of their proposal, the Contractor shall provide an initial transition plan that describes how they plan convert the legacy system to the new TCS. The Contractor shall address the sequencing of lane conversions, potential parallel operation of the legacy Host and the new Host, and how the interface to the CSC/VPC may or may not be impacted. The transition plan shall be developed with the goal of minimizing impacts to the customers, the Airports Authority, and the CSC/VPC.

5.3.1.5.2 ActivityPlanning

The Contractor shall provide detailed transition planning including the following: 1. Action List – Summary of the materials, training, agreements, and methods

required for transition. 2. Criteria for Successful Transition – Successful transition will differ for each area.

Examples could include receiving documentation or establishing a sub-contract. The final criteria for each shall be defined.

3. Identification of Required Resources – This may include third parties (e.g., the E-ZPass CSC Contractor) as well as Contractor staff.


Pg. 151

4. Responsibility of Airports Authority and Current Contractors – The Contractor will require Airports Authority assistance and coordination for many of the referenced areas. The expected level of participation of the Airports Authority and the current contractors shall be defined. All interaction with the current TCS Contractor shall be coordinated with the Airports Authority.

5. Weekly Transition Status Report – This report shall indicate the status of transition for each of the above areas and any other areas identified by the Contractor and the Airports Authority. The report shall identify any problems and shall include a sign-off sheet for each of the areas, including a final checklist for each area successfully transitioned.

5.3.1.5.3 CoordinationwiththeAirportsAuthorityandCurrentContractorsThe Contractor shall conduct meetings with all involved parties, including the Airports Authority, the current contractors, and other designated parties to review and coordinate with the succession plans of the current contractors.

During this period, the action lists, transition criteria, and identification of required resources shall be approved by the Airports Authority.

Any deviations among the succession plans of the current contractors, other Airports Authority requirements, and the Implementation and transition Plan as proposed shall be identified and resolved; any required modifications to the transition plan shall be performed and the Final Implementation Plan shall be submitted for Airports Authority approval in accordance with the schedule.

5.3.1.5.4 TrainingThe Installation and Transition Plan shall include a Training Plan subsection. The Training Plan shall provide information on the time frames and level of training to be provided to each Airports Authority staff member; an outline of subjects; and materials and resources to be utilized. The Contractor shall determine which staff members will require training in each functional area and shall include this information in the plan. All training shall be completed a minimum of two weeks prior to Go Live of the new TCS.

5.3.1.5.5 Go‐LivePlanNo later than 120 days prior to Go-Live, the Contractor shall submit the final Go-Live Plan to the Airports Authority for review and approval.

The Go-Live Plan shall include but not be limited to the following topics:

1. All activities required for Transition and Go-Live. 2. A Go-Live task list covering activities before, during, and after Go-Live. 3. The necessary Airports Authority approvals for Go-Live. 4. Roll back criteria and procedures.

The Go-Live Plan shall integrate with the Implementation and Transition Plan and may be a subset of the Implementation and Transition Plan.


Pg. 152

5.3.1.6 MaintenancePlanThe Contractor shall submit a Maintenance Plan that describes how the Contractor plans to perform the Maintenance of the new TCS. It shall include a description of the management and organization of the program; an organization chart; identification of key personnel and their responsibilities; identification of staffing; and identification of the resources, equipment and facilities to be used in fulfilling the Maintenance and Software Support Services. It shall also include staffing; coverage; training; scheduling; communications; spare parts inventory management; notification; escalation; and reporting procedures to be utilized by the Contractor while performing maintenance services.

The Maintenance Plan must be approved by the Airports Authority prior to Final Acceptance of the system.

5.3.1.7 Manuals

5.3.1.7.1 TollCollectorManualA Toll Collector Manual shall be provided. This document shall include a complete and simple description of all operational toll collection procedures and a nontechnical description of the MLT. This manual shall not include any information that will jeopardize the security of the TCS. The manual shall contain illustrations and diagrams as required to demonstrate the step-by-step operations required for processing all normal and irregular toll transactions, opening and closing the lane, and all other toll collector procedures. Final copies of this manual are to be delivered not less than thirty (30) days prior to commencement of the toll collector-training program. Draft copies shall be delivered sufficiently in advance to allow a thirty-day (30) review period, including revisions and eventual approval.

5.3.1.7.2 Shift/VaultSupervisorManualSupervisor Manual shall be provided under this Contract. This document shall provide a complete description of the Shift and Vault Supervisor's workstation functions, input menu options, and screen format descriptions. Diagrams and simplified instructions are encouraged. This manual shall include text to define the Supervisor's duties in order to efficiently monitor toll collector activities.

Additionally, the Supervisor Manual shall become the online help manual. Final copies and draft copies shall be delivered according to the same schedule identified above for Toll Collector Manuals.

5.3.1.7.3 FacilitiesDirectorandAuditUser'sManualA Facilities Director and Audit User's Manual shall be provided. This manual shall be provided for assisting in daily audit and operations of the TCS. It shall provide details explaining how administration such as TCS configuration changes, employee updates,


Pg. 153

toll fare table management, reports are derived, etc are processed. Complete diagrams, illustrations, and instructions shall be provided for ease of understanding the TCS operation. All operator commands, error messages and responses shall also be explained in detail.

For components not manufactured by the Contractor, the Manufacturer's standard equipment specifications and operator's manuals shall also be provided. All diagrams, illustrations, instructions and procedures shall be appropriately dated. Draft copies of this manual shall be delivered in accordance with the schedule in


Additionally, the Facilities Director & Audit User’s Manual shall become the online help manual. Final copies of this manual shall be delivered at least thirty (30) days prior to training.

5.3.1.7.4 MaintenanceandServiceManualMaintenance and Service Manual shall be provided. This document shall be comprehensive and shall provide complete detailed technical descriptions of maintenance operations, including but not limited to the following:

1. Preventive Maintenance Schedule; 2. Corrective Measures (both temporary and permanent); 3. Troubleshooting Techniques; 4. Alarms and Severities; 5. Maintenance Techniques (routine, preventive, and remedial); 6. Location and availability of support services for all major components; 7. Point-to-point component wiring schematics and logic signal flows; and 8. Assembly and disassembly drawings, including exploded view drawings.

This manual shall be prepared for technical personnel assigned to the maintenance of the TCS. This manual shall include a general description, theory of operation, operator instructions, detailed electrical/electronic logic circuit analysis, mechanical functions, installation, test and trouble-shooting procedures, preventive and corrective maintenance procedures.

The Maintenance Manual shall also contain diagrams, schematics, layouts, troubleshooting charts and parts lists required to service each component and circuit board utilized in the TCS.

The maintenance and service manual shall become the online help manual. The detailed service manuals and proprietary information shall be strictly used to ensure proper maintenance.


Pg. 154

Standard service manuals for unmodified commercial products used in the TCS shall be acceptable if they contain details and accurate information in order to properly service the specific toll collection equipment supplied under this Contract. Large size diagrams and mechanical assembly diagrams do not have to be reduced or incorporated into the manuals if these drawings are provided with the manuals.

Maintenance Manuals shall be delivered in preliminary form to the Airports Authority prior to the commencement of TCS installation. The Maintenance Manual shall be delivered according to the schedule in


Final Acceptance shall be contingent upon submittal and approval of the Maintenance Manuals.

5.3.1.8 PartsListsandCataloguesAn electronic copy and three (3) printed copies of a comprehensive and detailed parts list for each and every component included in the TCS shall be supplied. Parts shall be numerically encoded, with all spare parts permanently encoded with the parts lists number for inventory purposes. Parts lists shall be categorized and related to particular system components (major subassemblies) and toll equipment.

Parts lists with component part numbers without descriptive information shall not be accepted. The parts lists shall contain the source vendor's name, identification numbers and codes or other means to identify the manufacturer of each component. Second sources shall be stated for all standard commercial components.

All parts lists and catalogues shall be provided prior to the issuance of a Final System Acceptance.

5.3.1.9 As‐BuiltDrawingsThe Contractor shall provide two (2) complete sets of reproducible As-Built drawings for the TCS. The As-Built drawings shall be provided in electronically in both CAD and PDF format as well as in hard copy. The set shall include, but not be limited to, all schematics, logic diagrams, layouts, wiring diagrams, assembly drawings, parts detail drawings for mechanical parts design or modified under this Contract, including installation details so as to provide a complete record of the As-Built status of the TCS.

The Contractor shall incorporate into the As-Built drawings all design modifications, change orders and field installation changes. At the time of submittal, the Contractor shall certify in writing that the above has been accomplished.

Drawings contained in standard catalogues and manuals for unmodified commercial products do not have to be reproduced as part of the As-Built drawing set. All revisions


Pg. 155

to standard commercial assemblies or components of the toll system shall be included in the As-Built drawings.

The set of As-Built drawings shall consist of a title sheet, an index sheet and the various As-Built drawings. The index sheets shall include a listing of all drawings with headings for Drawing Number, Drawing Title, and the type of drawing, such as assembly, schematic, material list, wiring diagram, wire list, or similar categories.

The Airports Authority will review the As-Built drawings for content and will accept the drawings only when the Contractor has complied with requirements set forth herein.

The Contractor shall deliver all required As-Built drawings prior to Final System Acceptance.

5.3.2 ThirdPartyDocumentation

The Contractor shall provide standard, commercially available documentation for all third-party provided hardware, software, maintenance materials, and support documentation provided under the Contract.

The Contractor shall furnish, install and maintain, in current updated condition, all third party documentation. This material shall be provided in its commercially available form or in a comparable form and placed in racks or shelves to be retained at the Airports Authority Offices or another Airports Authority designated location for the duration of the Contract. Additionally, a softcopy of these documents with updates, if available shall be provided to the Airports Authority. All updated documents shall show the revisions and also include a version of the clean document.

The Contractor shall provide two (2) hard copies and one (1) electronic version of all hardware/software and user manuals for all third party sources. Electronic copies shall be reproducible by the Airports Authority.

5.3.3 ThirdPartySoftwareDocumentation

The Third Party Software Documentation shall include, but not be limited to all user’s manuals; programmer’s reference manuals; Warranty documentation; installation manuals; and Maintenance manuals, and shall contain all required information on items including the operating system; utilities; programming languages; application software; and communications software. The package shall also include all required electronic media to install, operate, and maintain the System being supplied. The Third Party Software Documentation shall be provided by the Contractor in a standard and organized format, with appropriate labels, tabs, and cross references to allow the Airports Authority to easily access and reference information on each software component on the System. Third party documentation if available for the security access system is acceptable to the Airports Authority.


Pg. 156

The Contractor shall be responsible for ensuring that all software patches and updates are current for software provided by both the Contractor and third parties during the warranty and maintenance period. All patches and updates made to the System software (third party and Contractor) shall also be provided to the Airports Authority in electronic media. A description of what patches and updates are considered part of the established maintenance fee and what is considered extra work shall be identified by the Contractor in their proposal. The Airports Authority shall apply penalties for failure to update software and security patches in a timely manner.

5.3.4 ThirdPartyHardwareDocumentation

The Third Party Hardware Documentation shall include, but not be limited to all technical manuals; operator's guides; installation guides; warranty documentation; hardware reference manuals; available options and versions; catalogs; components; and illustrated parts lists. The third party hardware manual shall be provided by the Contractor in a standard and organized format, with appropriate labels, tabs and cross references to allow the Airports Authority to easily access and reference hardware information on each equipment component. Additionally, with each third party hardware manual, the Contractor shall include sufficient documentation to describe the configuration of the hardware as it was set by the Contractor for the TCS. Any such configuration changes shall be provided to the Airports Authority in the form of a bulletin and a change to the relevant documentation.

5.4 SystemDesignandDevelopmentThe Contractor shall design and develop the new TCS in accordance with this Solicitation.

5.4.1 GeneralRequirements

The Airports Authority desires a collaborative approach to the System Design and Development of all components of the new TCS. The focus of the System Design and Development effort shall include the following activities:

1. Ensure that the Airports Authority’s Business Rules and Solicitation Requirements are completely attained by the new TCS.

2. Develop interfaces to other systems as required in this Solicitation. 3. Integrate the new TCS components and interfaces to create a seamless

functionality.

The System Design and Development effort shall focus on developing a comprehensive new TCS solution to best implement the Business Rules and Requirements.

The Contractor shall execute all activities required to design and develop the products, services, and systems specified in the Solicitation. Any activities required to meet the Solicitation Requirements are within the scope of the overall contract.


Pg. 157

5.4.2 RequirementsandBusinessRulesVerification

The Contractor shall conduct a series of interactive workshops with the Airports Authority and their representative(s) to verify and confirm the Requirements, Business Rules, and the Scope of Services detailed in this Solicitation. The Contractor shall be responsible for the scheduling and facilitation of these workshops. The results of these workshops shall provide as a key input into the development of the Preliminary Design Review (see Section 5.4.6 Preliminary Design Review)

During these workshops, the Contractor shall seek clarification and finite definition of the Requirements and Business Rules to achieve a mutual understanding between the Contractor and the Airports Authority.

The Contractor shall discuss how their proposed TCS solution meets the Scope of Services and what areas of the solution will or may require configuration, enhancement, modification, or development.

Through working groups, the Contractor and the Airports Authority will address each of the various areas that require configuration, clarification, and development. It is anticipated that these working groups will be required for Business Rule configuration, network communications, system interfaces, financial and accounting requirements, work flow process, and reporting.

As a result of the workshops, the Contractor shall prepare updated Business Rules for review and approval by the Airports Authority.

5.4.3 RequirementsTraceabilityMatrix

After the completion of the Requirements and Business Rules verification workshops, the Contractor shall submit a Requirements Trace Document for review and approval by the Airports Authority within sixty (60) Calendar Days of Notice to Proceed.

The Requirements Trace Document shall capture all of the Requirements for the new TCS.

The Contractor shall trace all Requirements to specific aspects of the new TCS provided by the Contractor to demonstrate that all requirements have been satisfied.

The Requirements Trace Document shall include an identification of the source of the requirement.

During implementation of the System, it is also expected that this document be updated to reflect any changes to the requirements that have been accepted by the Airports Authority.

The Requirements Trace Document shall also be used during system testing to verify compliance to the project requirements.


Pg. 158

5.4.4 SoftwareDesign

As identified in the Requirements and Business Rules verification workshops, the Contractor shall design any software enhancements or develop new software as required to meet the Scope of Services.

It is anticipated that design efforts may be necessary for new features and functions required to meet the program requirements, systems to system interfaces, and reporting.

The Contractor shall organize and coordinate concurrent design working sessions with the Airports Authority, its partners, suppliers, and contractors, as needed, to identify and develop any needed software modifications to meet the Solicitation Requirements.

The Contractor shall prepare Preliminary Design Documents for the individual development efforts and submit them to the Airports Authority for review and comment.

The Contractor shall then conduct a Preliminary Design Review of the proposed System. This first review shall be performed after the Contractor has made changes to the system design to accommodate the Requirements of the Airports Authority.

Based on the results of the Preliminary Design Review, the Contractor shall update the Design Documents and conduct a Detailed Design Review.

The Contractor shall then update the Design Documents based on the results of the second review.

The final System Design Document shall be submitted to the Airports Authority for final review and approval.

5.4.5 SystemNetworkDesign

The Contractor shall review and catalog the necessary system communication links, components and applied technologies, and assess the capability and adequacy of the proposed network based on current and future loads. This shall be done for estimated volumes of daily system data (such as transaction and communications data) and real-time data requirements.

This design shall consider the potential for system expansion and life-cycle analysis of major elements.

The Contractor shall submit a draft system network design to the Airports Authority for review and approval as part of the Preliminary Design Documents.

5.4.6 PreliminaryDesignReview


Pg. 159

The Contractor must conduct a Preliminary Design Review (PDR) of the proposed TCS. The PDR must be a formal presentation to be conducted in the form of a workshop over a one (1) to two (2) day period on-site with Airports Authority staff. A formal submittal of a PDR document is not required; however, the PDR should be supported by a presentation package such as Microsoft® PowerPoint. An advance copy must be provided ten (10) business days prior to the formal presentation for review.

Sections and or topics for the PDR must include, but must not necessarily be limited to, the following:

TCS Concept and Methodology; Project Schedule; Overall System Architecture; Requirements Traceability Matrix (RTM) covering each System, sub-system or TCS

component cross referencing each requirement the DDD, other applicable documentation and various test phases;

Integration of existing TCS equipment; Installation Overview, including but not limited to;

o Contractor identified modifications to existing physical infrastructure; o Data communications and power requirements ; o Computer and networking requirements and coordination with Airports

Authority’s staff; o Relevant product cut-sheets not provided with the Contractor’s Proposal; o Temporary power and back-up generator requirements and

arrangements; o MOT notification plans and programs;

Assess design issues and associated risk; and Risk Mitigation.

In addition, the Contractor must address and show compliance with quality assurance, reliability, and maintainability requirements, software configuration and other System requirements.

Hardware concept drawings and preliminary level engineering specifications must be submitted during this review.

The Contractor must summarize its input along with any related Airports Authority comments and provide a written document memorializing the meeting.

5.4.7 DesignandConfigurationWorkshops

The Contractor shall organize concurrent design and configuration workshops to finalize the actualization of the Business Rules, Requirements, work flow processes, and other user configurable parameters.


Pg. 160

As appropriate, use cases or other techniques shall be used to demonstrate how the System will meet the Requirements of this Solicitation.

5.5 QualityAssuranceandQualityControlThe Contractor shall establish and maintain an effective Quality Assurance (QA) Program to ensure compliance with the Contract. The QA Program shall ensure adequate quality throughout all areas of performance, including, design, development, fabrication, processing, assembly, inspection, test, Maintenance, packaging, shipping, storage, site preparation and installation. This QA Program shall be documented in a QA Plan to be submitted as a section of the PMP. The QA Program shall detail the process and procedures instituted by the Contractor to ensure the QA program is in place.

All supplies and services for the TCS, whether manufactured or performed within the Contractor's plant or at any other source, shall be controlled at all points necessary to ensure conformance to the specifications of these technical requirements. The QA Program shall provide for the prevention and ready detection of discrepancies and for timely and positive corrective action. The Contractor shall make objective evidence of quality conformance readily available to the Airports Authority.

The QA Program shall include effective quality control of purchased materials and subcontracted work. Manufacturing, fabrication, and assembly work conducted within the Contractor’s plant shall be controlled completely by the Contractor.

5.5.1 ConfigurationManagementSystem

The Contractor shall describe the Configuration Management System that is utilized for the Project. Configuration management process shall detail TCS defect tracking, change control, software changes and testing including regression testing, release notes and approval, deployment of software changes in production and verification.

5.5.2 ChangeControlProcess

The QA Plan shall detail the Contractor’s Change Control Process that is instituted for the DTR TCS project.

5.5.3 Records

The Contractor shall maintain records or data essential to providing objective evidence of quality until the expiration of the guarantee/warranty period and they shall be made available to the Airports Authority upon request. Examples of quality-related data include: inspection and test results, records of sub-Contractor QA/QC Programs, cost records pertinent to acceptance of nonconforming material, change odder backup, design reviews and walkthroughs, and the results of internal and vendor audits. Records shall be maintained in a manner that shall allow for easy access and analysis of the status of the overall QA/QC Program.


Pg. 161

5.5.4 ControlofPurchase

The Contractor shall ensure that all supplies, components, developmental tools, assemblies, subassemblies, and services procured from Subcontractors and vendors conform to the specifications of these technical requirements. The Contractor’s responsibility includes the establishment of procedures for the selection of qualified suppliers. In selecting qualified suppliers, the Contractor shall ensure that the Subcontractors and vendors control the quality of the supplies and services provided. Purchase orders for equipment furnished and supplied under this document shall be submitted to the Airports Authority and the Airports Authority shall have the option to approve every purchase order as required. Approval of a purchase order shall not constitute Approval of the equipment or the design.

5.5.5 InspectionandVerification

The Contractor’s QA Program shall include requirements for inspection and verification for in-process, final assembly, unit tests and System testing of the Contractor supplied Systems.

5.5.6 Handling,StorageandDelivery

The Contractor’s QA Program shall provide for adequate, documented handling, storage, preservation, packaging, and shipping instructions to protect the quality of products required by these technical requirements. Any unique or special requirements applicable to procured items shall be delineated in the procurement documents. All procurement documents shall be made available to the Airports Authority upon request.

5.5.7 InspectionatSubcontractorandContractorFacilities

The Airports Authority reserves the right to inspect, at the source, supplies or services not manufactured or performed within the Contractor’s facility. The Airports Authority inspection shall not constitute Approval, nor shall it in any way replace the Contractor’s inspection activity or relieve the Contractor of the responsibility to furnish an acceptable end product.

5.5.8 Accessto/InspectionofContractor'sFacilities

Upon request, the Airports Authority shall have access to the Contractor’s facilities and personnel. This access may be restricted to those portions of the facilities and personnel involved with or otherwise performing work for the TCS. Such access shall be for the purpose of inspecting the facilities, verifying progress, inspecting materials, work-in-progress and finished goods, or verifying test performance and results.

5.6 TrainingContractor shall provide all necessary training for toll collectors, toll supervisors, administration staff, and maintenance personnel. The Contractor will train the Airports


Pg. 162

Authority’s toll collection staff in all aspects and functions of the toll collection system. Training shall include both “classroom” training as well be available for hands-on or in-the-field training.

A separate training course shall be provided, at a location designated by the Airports Authority, for each of the following categories of personnel:

Toll Collectors; o Five (5) sessions of courses required with a class size of up to ten (10)

people and a minimum of two (2) hours per training class. Toll Supervisors (Shift Supervisor and Vault Supervisor);

o Two (2) sessions of courses required with a class size of up to ten (10) people and a minimum of three (3) hours per training class.

Auditor Personnel (Fiscal Technicians, Senior Accountant and Internal Auditor; o Two (2) sessions of courses required with a class size of up to five (5)

people and a minimum of four (4) hour sessions per training class. Toll Facilities Operator;

o One session of course required with a class size of up to five (5) people and a minimum of four (4) hours.

Maintenance training shall include both "classroom" training and extensive field training. These requirements shall be satisfied during the Warranty Period, commencing at a time designated by the Airports Authority.

The Contractor shall work with the Airports Authority to define and develop complete set of training manuals for all personnel to be trained.


Pg. 163

6 PROJECTSCHEDULE,PHASESANDMILESTONES

This section shall provide an overall summary of project phasing, scheduling, and milestone achievements.

6.1 ProjectPhasesThis project shall be divided into two (2) overall phases, generally delineated by successful completion of major milestones. These phases include:

Phase I - TCS Deployment - Phase shall involve the various efforts and task required to design, develop, install and commission the new TCS for revenue collection. Phase II shall be accomplished under the following sub phases;

Phase IA – Design, Development and Factory Test – Under this sub phase the Contractor shall complete the new TCS design and develop culminating in Factory Acceptance Test (FAT).

Phase IB – System Acceptance Test, Installation and Commissioning – This will include the necessary efforts to perform System Acceptance Testing (SAT), and all necessary installation and upgrade efforts including system commissioning testing.

Phase IC – Extended Operations Test (EOT) – This test will be a 90 day evaluation of the new TCS under live operating conditions to prove out conformance with the specified requirements culminating in the issuance of Final System Acceptance. This phase also includes full system warranty support and maintenance by the Contractor.

Phase II - TCS Maintenance and Warranty – This phase includes both the provisions of full maintenance and system support during a nine (9) month Warranty Period, following issuance of Final System Acceptance, and throughout any executed maintenance term as defined in Section 7.1.1 Maintenance Summary Scope of Work.

The following table represents the completion deadlines required for each major Phase of the Project:


Pg. 164

Table 6-1: Project Phases

PROJECT PHASE MILESTONE COMPLETION DATE*

Phase I – New TCS Deployment

Phase IA – Design, Development and Factory Test

270 Days** from NTP

Phase IB – System Acceptance Test, Installation and Commissioning Test

360 Days from NTP

Phase IC – Extended Operations Test (Final System Acceptance)

90 Days from Phase IB Completion

Phase II –9 Month TCS Warranty and Maintenance Term

9 Months From Final System Acceptance

*The actual milestone completion date shall be subject to the approved baseline schedule.

** All durations shall be in calendar days unless otherwise noted.

6.2 ProjectScheduleThe Contractor shall begin work on the date specified in the Notice to Proceed (NTP). Any work performed or executed prior to issuance of NTP shall be at the sole risk and responsibility of the Contractor.

Within the time specified in

Table 6-2: Deliverable Deadlines the Contractor shall prepare and submit a detailed Project Schedule outlining the order in which they propose that work shall be performed. The Project Schedule shall be developed in Critical Path Format (CPM).The specific installation deadlines set forth in this document shall be identified in this Project Schedule. The schedule shall be used as a basis for progress tracking throughout the course of the project. The Airports Authority shall review and approve the Project Schedule. Once approved the Contractor shall set the approved schedule as the Baseline schedule and this baseline shall be represented on each subsequent updated submittal.

Schedules shall be submitted in both printed and digital format using Microsoft Project® 2010 or later.

If a delay in the work schedule arises due to circumstances beyond the Contractor’s control, the Contractor shall submit a revised project schedule within ten (10) days after it is requested by the Airports Authority. Any failure or delinquency in submission of the schedule shall be treated as default on the part of the Contractor, who will then


Pg. 165

become liable for all possible actions which can be taken, including withholding of any payments due on the Contract.

6.3 WorkProgressThe Contractor shall use all practical means to make the progress of the work conform fully to the Project Schedule. If the Contractor fails to meet the Project Schedule, the Airports Authority may require them to take any or all of the following actions at no additional cost to the Airports Authority:

Perform overtime work; Increase the number of personnel assigned to the project; and Increase plant or machine capacity.

The Contractor shall prepare and submit to the Airports Authority monthly progress reports on the status of all major items and activities. The monthly progress report shall include an updated Project Schedule.

6.4 PhaseIPhase I will be accomplished over three (3) sub-phases whereby the Contractor shall design, develop, test, install and commission for use the new TCS.

6.4.1 PhaseIA

Efforts during this phase shall include all system design, software development, hardware procurement and fabrication, shop testing, software testing, software documentation culminating in a full Factory Acceptance Test (FAT).

Periodically throughout this Phase, the Airports Authority and its representatives reserves the right to visit the Contractor’s facility/facilities in order to inspect work in progress and may, from time-to-time, request reasonable demonstrations of toll collection equipment and subsystems. The Airports Authority will give reasonable advance notice prior to factory visits. At such time as the Contractor has completed all development and fabrication of the TCS, including detailed internal testing, the Contractor shall provide written notice to the Airports Authority requesting the scheduling of a full FAT.

The Contractor shall provide written results and evidence their own testing prior to FAT. If the proposed test scripts have been approved and, if after reviewing the evidence of the Contractor’s internal testing of the toll system the Airports Authority agrees that the Contractor has sufficiently tested at the factory level, a FAT can be performed.

FAT shall involve testing of all subsystems to be installed as part of the Toll Collection System (with the exception of the full communications system). All components shall be fully fabricated and integrated, ready for installation at the time of the Factory Acceptance Test. At least one complete subsystem of each category shall be installed at the Contractor’s site for the purpose of this Factory Acceptance Test, including:


Pg. 166

1. One Express E-ZPass Lane, including AVI subsystem, VES subsystem, AVC subsystem and any other lane system components;

2. One Dedicated E-ZPass Lane, including AVI subsystem, VES subsystem, AVC subsystems (pre-class and post-class) and any other lane system components;

3. One Attended Lane, including AVI subsystem, ACM, VES subsystem, AVC subsystems (pre-class and post class), MLT, PFI, ITL, receipt printer, LSS, canopy light and any other lane system components;

4. One Unattended lane, including AVI subsystem, ACM, VES subsystem, AVC subsystem, PFI, ITL, lane LSS, canopy light and any other lane system components;

5. The Host System with fully configured including all software, printers and peripherals, the Host Level functionality, and administration/audit subsystem including the Supervisor Workstation, and Cash Count Workstation;

6. VES System supporting VES image subsystem from the lane and integration with the TCS including OCR validation (OCR functionality only); and

7. DVAS subsystem.

Any toll system functions defined in this Contract as well as any Contract modifications shall be subject to detailed testing and verification by the Airports Authority during the FAT. If, in the judgment of the Airports Authority and/or its Representatives, the FAT indicates that the toll collection equipment and software appear to be functioning satisfactorily in accordance with a predefined test plan and all functional and technical requirements of the Contract, the Airports Authority shall issue written approval of the FAT and immediately authorize shipment of equipment to the site for field installation.

This Approval of the FAT shall in no way reduce or eliminate the Contractor’s full responsibility to resolve any problems and make the TCS work in full conformance with the requirements of this Contract. Nor shall it limit the rights of the Airports Authority to bring toll system problems to the attention of the Contractor at a later time.

6.4.2 PhaseIB

Upon successful completion of FAT and approval by the Airports Authority, the Contractor may be authorized to commence with Phase IB efforts including SAT, Installation and Commissioning.

No actual equipment installation activity shall take place on-site until FAT approval has been obtained. However, if any preliminary installation or other minor physical modifications are required, these may be performed prior to approval of the FAT. Any pre-FAT approval installation activity shall be approved, in writing, by the Airports Authority.


Pg. 167

Any necessary plans for civil works shall be submitted to the Airports Authority for review and approval. Actual installation will be inspected by, and subject to the approval of the Airports Authority. All required traffic control or maintenance of traffic (MOT) shall be provided by the Contractor subject to the approval of the Airports Authority.

Installation of any new toll collection equipment shall be performed by the Contractor with trained personnel who are familiar with all aspects of the toll equipment.

Under the supervision of the Airports Authority the Contractor shall begin installation and preparation to perform the On-Site First Installation Test (OFIT). This testing shall include individual lane equipment, communication networks and any other reasonable test that may be required to verify proper functioning of the TCS as described in Section 4.4.1.

Once OFIT has been successfully completed the Contractor shall then begin Statistical Performance Test which shall involve transaction and data gathering and analysis of the new TCS to verify full end-to-end system functionality and conformance with the performance accuracies as defined in Table 2-5: TCS Performance Requirements. Successful completion of Statistical Performance Test shall indicate that the new TCS is ready for full system wide installation and Commissioning.

Once the Statistical Performance Test is completed, reported and approved by the Airports Authority the Contractor may then begin to complete installation and Commissioning throughout the remainder of the system, plazas and lanes. As each lane is completed the Contractor shall then perform Commissioning tests to validate lane functionality and preparedness for live traffic and revenue collection operations.

During the installation phase of the project, the Contractor shall provide a full time on-site Installation Manager conveniently located and accessible to the Airports Authority. During phases other than the installation phases, the Contractor’s Project Manager shall be readily accessible via telephone and/or pager. In addition, the Contractor’s Project Manager shall report to the site within 24 hour notification from the Airports Authority.

During any and all installation efforts the Installation Manager shall coordinate closely with the Airports Authority’s toll operations staff.

In the event that any structure is damaged due to the Contractor’s activities, such damage shall be repaired immediately at the Contractor’s expense and to the satisfaction of the Airports Authority.

6.4.3 PhaseIC

Phase IC will commence once the entire system is installed and successfully commissioned. During this Phase of this Contract, a ninety (90) day Extended Operations Test (EOT) of the new TCS shall take place under live traffic conditions. The


Pg. 168

Contractor shall be required to fully support and maintain the TCS, in accordance with provisions set forth in Section 7, Phase II - TCS Maintenance. Any problems detected during the monitoring of the toll system during Phase IC shall be immediately brought to the attention of the Contractor and the Airports Authority for resolution. At the conclusion of this evaluation period, if the system is considered to be operating fully in compliance with Contract requirements, the Airports Authority shall provide the Contractor with written notice of Final System Acceptance.

Throughout the period of the EOT the Contractor shall provide a full time manager on-site to advise and assist the Airports Authority in start-up and initial operation of the TCS.

6.5 PhaseIIThe final phase of this Contract, Phase II, shall include continued toll system maintenance through the 9-month Warranty Period. Phase II commences when the Contractor is given Final System Acceptance by the Airports Authority.

All provisions, as set forth in 7


Pg. 169

Phase II - TCS Maintenance shall be in effect throughout the Warranty Period. During this Period the Contractor shall supply adequate maintenance personnel, spare parts and factory support to ensure the system shall remain fully operational in full accordance with system performance requirements and problems are corrected within the repair/replacement as specified in this document.

6.6 ProjectDeliverables

6.6.1 General

Unless specifically agreed to by the Airports Authority, all major document deliverables shall require an outline, a first draft, a final draft, and a final submission with time allocated for the Airports Authority review and approval of each deliverable.

The Airports Authority and/or its representatives will review and approve all deliverables required under the Contract.

As part of the review process, the Airports Authority will provide the Contractor with a consolidated set of comments on the deliverable submitted for review.

The Contractor shall respond in writing to all Airports Authority provided comments. A comment resolution meeting may be conducted to clarify and resolve any remaining questions and issues concerning the comments and/or responses provided.

Based on Airports Authority comments and the results of the comment resolution meeting, the Contractor shall prepare a final version of the deliverable for Airports Authority approval.

6.6.2 SummaryofMajorProjectDeliverablesandDeadlines

To assist the Contractor a number of the interim deliverables are presented in

Table 6-2: Deliverable Deadlines. This summary is provided for convenience only and does not necessarily represent a complete or definitive listing of all document deliverables. The Contractor shall independently determine all deliverables required during the Project. In case of differences between the text in this document

Table 6-2: Deliverable Deadlines shall govern. The Airports Authority approval of deliverables is required for payment or progression to the next stage or phase.


Pg. 170

Table 6-2: Deliverable Deadlines

Deliverable Delivery Schedule*

Project Management Plan 15 Days from NTP

Baseline Project Schedule 15 Days from NTP

Requirements Traceability Matrix 60 Days from NTP

Preliminary Design Review Meeting 60 Days from NTP

Master Test Plan 75 Days from NTP

Approved Draft Business Rule Document 60 Days from NTP

Approved Draft Interface Control Documents

90 Days from NTP

Approved Draft Detailed Design Document 120 Days from NTP

Approved Final Business Rule Document 180 Days from NTP

Approved Final Interface Control Documents

180 Days from NTP

Approved Final Detailed Design Document 210 Days from NTP

Factory Acceptance Test (FAT) Plan and Procedures

30 Days before the scheduled test

Training Plan 60 Days Prior to Commissioning

Installation and Transition Plan 60 Days Prior to Commissioning

Training Completed 10 Days Prior to Commissioning

System Acceptance Test (SAT) Plan and Procedures

30 Days before the scheduled test

Commissioning Test Plan and Procedures 30 Days before the scheduled test

Toll Collector Manual 30 Days Prior to Training

Toll Supervisor Manual 30 Days Prior to Training

Administrator/Audit User Manual 30 Days Prior to Training

Final Shop Drawings 30 Days Prior to Commissioning

Maintenance Plan 30 Days prior to Commissioning

Maintenance and Service Manual 30 Days prior to Commissioning

Parts List and BOM 30 Days after Final System Acceptance

As-Built Drawings 30 Days after Final System Acceptance

Final Manuals 30 Days after Final System Acceptance

*Unless otherwise stated all days are calendar days.


Pg. 171

Unless stated or otherwise agreed to between the Airports Authority and the Contractor, the standard review time for the Airports Authority shall be fifteen (15) business days.

6.6.3 DocumentDeliveryandControl

The Contractor shall keep track of all documentation submitted to the Airports Authority or its representatives including the document identification, name, and description of the document, version number, release date, distribution list, approval date, and document’s electronic file name.

The Contractor shall record any revisions made to the original documents and retain copies of said documents with additional written comments as original records.

The Contractor shall use a standard file naming convention to keep track of all electronic files.

The Contractor shall be responsible for ensuring that the documents are distributed electronically and can be accessible through an electronic document storage facility. This shall include all reports required under the reporting requirements.

All information (documents and communications) related to the project shall be kept on a secure, dedicated FTP or Microsoft SharePoint® site held by the Contractor.

The Contractor shall be responsible for administering the FTP or Microsoft SharePoint® site and providing access to parties approved by the Airports Authority.


Pg. 172

7 PHASEII‐TCSMAINTENANCE

7.1 TCSMaintenanceandSoftwareContinuousSupportServicesThe Contractor shall provide maintenance and software support to the TCS and support systems on a 24 hour, 365 day per year basis. The level of service shall be adequate to meet or exceed all systems availability, response and repair times as defined in the Contract. The Contractor shall provide the required access, all tools, vehicles, training, and any other materials required to maintain the TCS and related systems at required levels of operation.

7.1.1 MaintenanceSummaryScopeofWork

The Contractor shall provide maintenance of the TCS for a six (6) year term. The Contractor shall provide pricing for the six (6) year maintenance term as part of their base bid amount.

Full TCS Warranty and Maintenance Services shall begin upon the issuance of Final System Acceptance. Maintenance services shall also be provided throughout the installation and commissioning period as lanes are transitioned from the legacy system to the new system.

No later than Sixty (60) days prior to the end of any maintenance term, the Airports Authority shall notify the Contractor its intent to continue, or discontinue, the Maintenance Contract by the election of an additional Maintenance Term as defined in Section 7.1.1 Maintenance Summary Scope of Work.

The Maintenance Services Scope of Work shall include monitoring, preventive, predictive, corrective, and emergency Maintenance services to be performed on all elements of the TCS.

7.1.2 MaintenanceandSoftwareSupportServices

The Contractor shall fully maintain and support the hardware, software, firmware, subsystems and all related supporting infrastructure subsystems of the new TCS. Support services will include all levels of repair and troubleshooting necessary to preserve and or restore the TCS to revenue collection operating levels defined in this document.

The Maintenance and Software Support Services Scope of Work shall include but not limited to the following:

1. In-lane TCS System and subsystems (Hardware & Software); 2. UPS Equipment; 3. Enclosures and Racks; 4. Equipment Mounting Brackets, Hardware and Structures; 5. Cables, Wiring, and Terminations; 6. Network Equipment, Communications Components, and Enclosures;


Pg. 173

a. TCS LAN; b. Routers, switches, and other signal directing equipment; c. Ethernet, fiber optic, and other connecting wires and cables; d. Data wire and cable terminations and splices; and e. AC/DC power cables and connectors for LAN equipment

7. Host(Hardware & Software); 8. All Hosting Environments or Solutions; 9. All Third Party Software; 10. MOMS; 11. DVAS; 12. LSSs; 13. ACM’s; 14. System Administration; and

a. Daily, weekly, or periodic Maintenance necessary to maintain the TCS at required performance levels (for example: purging old files, adding new tables or directories, etc.);

b. Retrieval of data manually, if required; c. Performing disaster recovery procedures as needed; d. Maintaining System Availability requirements; e. Re-establishment or re-installation of System files, programs and

parameters, as required, following a failure or damage to the TCS; f. Investigation and analysis of anomalies to include trend analysis; g. Monitoring, notifications, and initiating corrective actions on application

programs to meet requirements; h. Performance of ad hoc queries based on the Airports Authority requests

and provide reports on all requests; i. Provide user support to the Airports Authority personnel that require

access to the TCS; j. Monitoring of error and System logs; k. Third party software or firmware upgrades, as required; l. Providing changes to configurable parameters as requested by the

Authority; m. Performance of software updates resulting from corrective action,

business rule changes, and configuration changes; n. Verify processes and scheduled job are successful; o. Verification on a daily basis that transactions are being generated in the

lanes and these transactions are being sent appropriately to the Host and then on to the E-ZPass CSC and VPC, and report the status;

p. Maintenance of software versions (TCS and third party); q. Support of System back-ups and archiving (all TCS software and

transaction data);


Pg. 174

r. Performing security software upgrades and patches, data base upgrades and patches and operating system upgrades and patches;

s. Installation of new software and confirmation of successful installation; t. Verification that the MOMS is receiving and processing TCS events and

reporting the correct status; u. Performance of regular virus protection updates in accordance with

recommended Maintenance schedule; and v. Verification of time synchronization is occurring as configured and System

clocks are not drifting beyond acceptable threshold. 15. Software Changes within scope of this document. Record and release notes of

software downloads shall also be submitted to the Airports Authority in summary format each time a software change is made.

16. Annual Performance Testing as described in Section 4.7 Annual Performance Test.

17. Annual Disaster Recovery Test as described in Section 4.8 Annual Disaster Recovery Test

18. Annual Security Test as described in Section 4.9 Annual Security Test.

7.2 WarrantyProgramThe Contractor shall provide a nine (9) month Warranty to start on the date that Final System Acceptance has been granted to the Contractor. The Warranty shall be all-inclusive where the Contractor shall provide on-site response to any service affecting the TCS operations; this includes Preventive Maintenance.

Maintenance service shall be provided on a twenty-four (24) hour, seven (7) day per week basis during the warranty period.

During the warranty period, any defects and/or malfunctions identified shall be brought to the attention of Contractor in writing prior to the expiration of the Warranty Period. Written communication of any defects shall be submitted to the Contractor in a standardized form. The format and content of the form shall be developed by the Contractor and subject to the approval of the Airports Authority during the Maintenance Plan review. The Contractor shall make repairs under the terms of the Warranty.

The Warranty Program shall not limit the responsibility of the Contractor for designing, fabricating and installing equipment in a good and workmanlike manner and in accordance with good industry standards.

7.2.1 HardwareWarrantyProgramincludingThirdPartyWarranty

In addition, the Contractor shall require that in agreements with Subcontractors and Suppliers (Third Parties), such parties shall assign and furnish warranties and representations to the Airports Authority.


Pg. 175

7.2.2 SoftwareWarranty

All software and firmware furnished under the Contract shall be warranted by both the Contractor and manufacturer(s) to be free of defects in workmanship. All software and firmware shall remain in good working order in the sole judgment of the Airports Authority; and, shall meet or exceed the requirements specified in this document.

7.2.2.1 Software/HardwareProblemDefinitionsSystem problems manifest themselves in several ways, the results of which are termed either as errors, bugs, defects or malfunctions. These problems shall be defined as follows.

Error/Bug - A problem found in the development environment prior to product and being placed into service.

Defect - Any function, equipment, or system problem identified that does not conform to the specifications and or approved SDD. An Error or Bug may cause a defect to occur.

Malfunction - A malfunction is produced by a program defect or bug that causes a program to work poorly, produce incorrect results, or failure.

7.2.3 TCSDefect&MalfunctionSeverity

System problems shall be classified by severity level and it associated impact to the System and operations. Table 7-1 provides brief descriptions of the severity levels:

Table 7-1: Severity Levels

Severity Level Description

Severity 1: Critical Defined as any malfunction or fault that will result in the immediate loss of revenue, loss of operations, closure of a lane, loss of data, or hazard to personnel or Patrons.

Severity 2: High Defined as any malfunction or fault degrading the TCS performance, but not the operational ability of the TCS.

Severity 3: Medium Defined as any event that has the potential of resulting in a malfunction or degrading of the TCS performance.

Severity 4: Low Defined as any event or malfunction that is cosmetic and presents no risk in affecting TCS performance.

7.2.4 HardwareWarranty


Pg. 176

The Warranty Program shall cover all TCS hardware components as being free of defects in equipment, software and workmanship for a period nine (9) months from Final System Acceptance. This warranty however shall exclude the following components or hardware:

Island Traffic Lights Canopy Lights Fiber optic network

7.3 MaintenancePlanThe Contractor shall provide a detailed Maintenance Plan deliverable no later than the time specified in

Table 6-2: Deliverable Deadlines. The Maintenance Plan shall detail the maintenance procedures of how the Contractor will meet the requirements of this document and perform the Work. In addition the Maintenance Plan will include the following:

1. Maintenance Management & Personnel a. Maintenance Roster/Organization Chart

2. Maintenance Methodology and Procedures a. Preventive (PrM), Predictive Emergency & Corrective Maintenance (CrM)

Procedures b. Repair and Replacement Procedures c. Lane Closings/Maintenance of Traffic

3. Service Call/Work Order Procedures (Technicians)(24/7 X 365) a. Technician Responsibility- Notification & Acknowledgement b. Call Escalation c. Work Order Closure d. Reporting of Work Orders or incidents with Actual or Potential Loss of Data

4. Safety Procedures 5. Spare Parts and Inventory Control 6. Maintenance Reporting and Control

7.3.1 MaintenanceCoverageandResponseTimes

The Maintenance Coverage and Response Times requirements for the new TCS are as follows:


Pg. 177

Table 7-2: Response & Repair Times

Severity Level Time* to Respond Time* to Repair

1 - Critical 1 Hours 2 Hours

2 - High Priority 4 Hours 24 Hours

3 - Medium Priority 8 Hours 2 Business Days

4 - Low Priority 1 Business Day 5 Business Days

* Failure to meet Repair times due to Airports Authority imposed physical restrictions shall not be held against the Contractor. In the event a repair time is affected by such restriction it shall be recorded on the Work Order including the length of the delay.

Response and Repair times shall be calculated on a per event basis.

Response Times shall be determined based on when the Contractor receives notification of an event, and the time the Contractor acknowledges said event.

Repair Times shall be determined based on when the event is acknowledged and when it has been fully resolved.

7.3.2 MaintenanceOnlineManagementSystem(MOMS)

The Contractor shall provide a Maintenance Online Management System to monitor and facilitate the maintenance of the TCS. The MOMS shall have the capability of a comprehensive tool used for monitoring and reporting System status. The server application and database shall reside on a dedicated MOMS server or integrated with the Host System as determined by the Contractor and the Airports Authority during the Design phase. The Contractor shall ensure that the furnished MOMS shall have the following capabilities:

a. Receive and monitor status messages from all devices, processes, and Systems. b. Capable of local manual entry or email entry by authorized Airports Authority or

Contractor personnel. Entry shall be recorded and automatically tracked to closure.

c. Data is stored in a relational data base to permit data recovery and flexibility in reporting the raw data.

d. Automatically generate and print or email daily and monthly performance reports as determined by the Airports Authority during the Design process.

e. Track device failures, process failures and service requests. f. Assign priorities and actions to events. g. Automatic notification to the Maintenance technicians via reports, email, and/or

text.


Pg. 178

h. Record time of acknowledgement, time to respond (both remotely and on-site) and time of repair by Contractor’s maintenance personnel assigned to problem.

i. Record completion of service calls as well as the ability to filter the records based on priority levels of calls.

j. Maintain list of vendors from where products are procured from to include 2nd source.

k. All Warranty information on all equipment and third party software maintained in System.

l. Maintain and track PM, PrM, CrM and all other activity. m. Asset management and spare parts inventory. n. Schedule preventive and predictive Maintenance activities. o. Manage the TCS equipment inventory with purchase order generation for parts

replacement. p. User level security. q. Automatic alert for spare parts levels, work order not closed out in specified time. r. Provide various System performance, device performance, staff performance,

and management reports.

The presence of a MOMS notification via electronic notification shall constitute the start time of the response time period for purposes of measuring the Contractor’s response time. Notwithstanding the foregoing, failure of the MOMs system to generate an alert shall not be deemed a waiver of the response time requirement. In this case, notification shall be considered to commence upon the time of the actual event or failure.

7.3.3 PreventiveMaintenance

Preventive Maintenance (PM) – Involves scheduled maintenance activity of the TCS ensuring that the equipment is operating properly and within specified parameters. The Contractor shall identify system components that will undergo PM and utilize MOMS to create a PM schedule the will automatically issue work orders to the field technicians.

7.3.4 PredictiveMaintenance

The Contractor shall use Predictive Maintenance (PrM) methods to maintain the TCS. PrM uses MOMS historical data to predict what components or parts are likely to fail in a given time period. Through the evaluation of mean time to repair (MTTR) and mean time between failures (MTBF) data, it is possible to schedule a component or part to be replaced near the end of its normal expected life prior to the occurrence of a failure.

7.3.5 CorrectiveMaintenance

The Contractor shall utilize a Corrective Maintenance (CrM) process to maintain the TCS – CrM involves diagnosing and correcting TCS problems, which may be related but not limited to system performance, function, or availability in order to meet the normal


Pg. 179

operating requirements of the TCS. For repeated failure of TCS components, the Contractor shall undertake an investigation and if the problem is determined by the Airports Authority to be a pervasive defect, the Contractor shall correct the problem at no additional charge.

7.3.6 UpgradesandEnhancements

Software modifications that are required to maintain and support the System as a part of the normal course of business such as version changes, configuration or parameter changes or minor changes to software or code; or, changes that improve the Contractor’s ability to maintain and support the System, shall not be considered upgrades or Enhancements subject to reimbursement by the Airports Authority.

Upgrades and Enhancements required for reasons such as to meet major changes to standards, statutes or interoperability requirements or the addition of new functionality as requested by the Airports Authority with a demonstrable benefit in performance, costs or productivity, shall be proposed by the Contractor and coordinated through the Airports Authority.

As part of the initial maintenance term and or any subsequent extension the Contractor shall include any and all required system patches, hot fixes and or version update releases.

7.3.7 Notifications

The Contractor shall follow the required response and coverage times as specified in Table 7-2: Response & Repair Times. The Contractor shall utilize MOMS to the fullest extent possible to automate the process of handling alerts, notifications and communications for work orders and calls for service.

The Contractor shall designate Maintenance Technicians and Staff to be “On-Duty” for specific time periods based upon a resource schedule. Scheduling of maintenance staff shall be at the discretion of the Contractor but must be established in consideration of the response and repair times as specified in Table 7-2: Response & Repair Times. The Maintenance Plan shall detail the initial schedule of maintenance staff and shall be subject to approval of the Airports Authority.

The maintenance personnel On-Duty shall receive all MOMS automated notifications or e-mails and/or text messages containing alerts of notification of problems or events. The person On-Duty shall then perform all required processes and responses to affect the analysis of the event, trouble shooting and remediation of the problem and/or repair of the system to make the TCS fully functional for revenue collection.

7.3.8 RecordingofMaintenanceActivities


Pg. 180

In all cases, it shall be the Contractor’s responsibility to log all reported maintenance activities. The Contractor shall also document all information and issues related to a fault condition. The Contractor shall develop a report on the MOMS that can be identified by its unique tracking number and acquired through any variable associated with the report. For example, the report should be able to be queried via specific aspects such as location, component, or corrective action. This document shall be the mechanism by which an individual problem is tracked to completion. The document shall be identified as a Trouble Failure Report (TFR). The TFR shall contain as much information as possible in order for any person to reasonably determine the fault, when it was worked on, the corrective action, and any other information pertaining to the individual Maintenance event. Items to be contained on the TFR include:

1. Applicable Date / Time blocks (received, response, repair, closed out); 2. Location of fault (tolling location, lane, subsystem, etc); 3. Failure component; 4. All codes and alerts associated with the failure; 5. Detailed description of corrective action; 6. Technician (s) who worked on the fault condition; 7. Serial number of failed component and any replacement components; 8. Notification date/time, arrival on-site date/time, and repair complete

date/time; and 9. Any other blocks or fields deemed necessary to adequately track and

describe the Maintenance action.

Standard definitions and terminology shall be established to encourage consistency and limit discrepancies between reports. Specifically, if pull-down menus or similar selections are made available to the technician for input of items such as corrective action, each option should be clearly defined and its intended use must be defined in the technician training materials. The goal of this standard shall be to establish a consistent and traceable reporting of activities.

It is the Contractor’s responsibility to ensure that their maintenance staff has real-time access to the MOMS and all the required connections are established and on-going to ensure that the Maintenance staff maintains access, including required remote units.

7.4 SparePartsThe Contractor shall be responsible for the complete supply chain of spare parts inventory to maintain the new TCS. The scope of spare parts shall include all re-used equipment/parts as well as any new spare parts to be purchased for supporting the New TCS. The Airports Authority shall bear the cost and ownership of all spare parts (outside of warranty). The Contractor shall submit a budgetary line item for new TCS spare parts supported by a detailed list of the parts and the subsystem to which they belong.


Pg. 181

7.4.1 SparePartInventoryandTracking

Faulty components or parts will be returned to the manufacturer for repair or replacement as soon as possible after a failure occurs. Components that are under warranty will be expedited for repair before the warranty period expires. Parts and components that have been repaired by either the manufacturer or third party shall be checked for quality when received, entered into MOMS and placed back in inventory.

7.4.2 ProcurementandControlofSpareParts

The Contractor shall utilize the functionality of MOMS to maintain, control, track and purchase all inventory related to spare parts for the TCS and all toll related equipment. The Contractor shall store and control all spares and asset inventory in a safe and secure manner.

7.4.3 InventoryManagement

All spare parts and asset inventory of equipment shall be performed through MOMS. When spare parts inventory reach a configurable threshold, automatic replenish alerts shall be generated. The Contractor shall work with the Airports Authority to determine the asset levels for inventory.

7.5 CooperationwithOtherContractorsandProvidersThe Contractor may be required from time to time to work with or other vendors or providers in order to support the TCS. The Contractor shall cooperate to the fullest extent with other Contractors or representatives of the Airports Authority in order to ensure that the TCS and other functional elements do not conflict or cause any deterrent in capability, operation or service to the Airports Authority and the traveling public.

At the conclusion of the initial maintenance term or any subsequent maintenance term extension the Contractor shall provide transition support to the any new successor contractor and or maintenance contractor. The transition support shall provide the necessary resources to accommodate the following at a minimum:

1. Operational transition of staff and field technicians; 2. Transfer of information such as all Manuals, System Documentation, and

Maintenance records. 3. Training of system interfaces such as MOMS, reporting functions, etc.

7.6 EmergencyResponseManagementThe Contractor shall immediately respond to any emergency situation such as weather, vehicle accident, third party (power outage), or vandalism that may arise that has already or could potentially damage the TCS. The Contractor shall be prepared to put forth all necessary resources to divert or correct an emergency condition. Such


Pg. 182

emergency conditions shall be handled in accordance with policies and procedures established and Approved by the Airports Authority.

7.7 IncidentandRevenueLossReportingThe Contractor shall immediately notify the Airports Authority of any incident whereby loss of revenue has occurred or could potentially occur. The Contractor shall take immediate action to rectify the condition and return the TCS to normal functioning. An Incident Report shall be provided to the Airports Authority. If the condition is determined to be due to the fault of the Contractor, damages and costs shall be the responsibility of the Contractor as set forth in this Contract.

7.8 MaintenanceStaffing,MaterialsandTrainingThe Contractor shall at its own expense provide all personnel necessary to perform the Maintenance Services specified in this document. Staffing shall include all human resources necessary to manage and administrate the field maintenance force. The Contractor shall provide all materials necessary for maintenance personnel including but not limited to: Vehicles, tools and equipment, uniforms, computing and communications devices and facilities for central repair depot or maintenance office.

7.8.1 MaintenanceStaffingRequirements

All personnel engaged in the maintenance, repair and troubleshooting shall be qualified, properly licensed, OSHA safety trained and authorized under all applicable laws and regulations both local and national.

The Airports Authority may conduct reference and background checks on all Maintenance Staff at any time while under any maintenance term. Further the Airports Authority may conduct background checks during the Phase I period of the project for any contractor staff assigned to or working on this project. The Airports Authority reserves the right to reject any of the Contractor’s assigned staff as a result of such reference and background checks

7.8.2 ToolsandMaterials

The Contractor shall provide all tools, vehicles, training, and any other materials required to maintain the TCS to the operating levels specified in this document.

7.8.3 PersonnelTraining

The Contractor shall train personnel up to their level of their responsibility. Training shall be comprehensive so that personnel have full comprehension of the overall TCS operation including all lane types, DVAS, LSS, VSS, Host functionality, and E-ZPass Group functions and supporting infrastructure.

7.8.4 TrainingMaterialsandOn‐goingEducation


Pg. 183

The Contractor shall provide professional quality training materials including manuals; videos, computer based training and “hands-on” demonstrations. The Contractor shall provide refresher and remedial training, continuing education, as necessary and required.

7.8.5 TrainingProgram

Training programs shall be developed “in-house” by the Contractor or by an accredited or certified third party educational company, community college or vocational technical school.

7.8.6 TrainingRecords

The Contractor shall maintain training records in employee personnel files and make the information available as part of the yearly reporting to the Airports Authority.

7.9 SafetyThe Contractor shall adhere to all applicable safety standards and guidelines for working on or around construction zones, energized equipment, active roadways, and a Maintenance environment, including but not limited to the following:

1. Airports Authority safety procedures and guidelines 2. OSHA 3. NEMA 4. NEC 5. FHWA 6. Any other local, state, or Federal ordinance, procedure, or guideline that

provides for a safe operation and working environment.

7.10 MaintenanceandProtectionofTrafficThe Contractor shall provide any and all required maintenance of traffic (MOT) related to toll lane closures for the maintenance of the TCS. Coordination of proposed toll lane or other lane closures as part of the Maintenance Plan shall detail procedures for notifying the Airports Authority for any such requested closures. The Contractor shall coordinate with the Airports Authority for the performance of all MOT in accordance with Lane Closure Policies provided under Attachment 05 of the RFP. Advanced planning shall be required to determine detailed procedures for the request for and coordination of MOT. The Contractor shall work with the Airports Authority to develop as a part of the Maintenance Plan described above a maintenance and protection of traffic coordination procedure for approval by the Airports Authority.

Contractor shall adhere to the Approved MOT Plan when setting up, working under MOT and restoring lanes to live traffic operations. The Contractor shall work with the Airports Authority to coordinate MOT work and to adhere to Airports Authority advance notice requirements for work in the lanes, both on a scheduled and emergency basis.


Pg. 184

As a basis for determining toll lane procedures the following are the current guidelines for toll lane closures:

The lane canopy light shall be turned to red. Cones shall be tapered into a “V” format in front of the toll lane. A minimum 4’ by 4’ lane closed sign shall be placed at the beginning of the lane

closure. These provisions shall also be adhered to during initial installation activities as well as during any additional work as may be directed by the Airports Authority.

7.11 ReportingRequirementsThe Airports Authority and/or its representative shall have access to all Maintenance and service records at all times for review and audit.

7.11.1 FieldandShopMaintenanceRecords

The Contractor’s Maintenance Manager shall maintain current, complete, and accurate records for all field and shop maintenance activities. All preventative and predictive Maintenance activities shall be reported in the same manner as corrective or emergency Maintenance activities. The information shall be contained on the MOMS database.

The MOMS shall generate a summary report related to all maintenance activities over a specified time period. This report shall include, but not limited to:

1. Type of notification 2. System failure (Lane, Host, Network) 3. Location ID 4. Lane #, if applicable 5. Equipment failure and description 6. Work or service performed 7. Technician(s) or personnel assigned 8. Parts replaced, including serial numbers and other descriptions 9. Dates and times the action started and completed

This summary report shall be generated monthly and distributed to the Airports Authority.

7.11.2 MaintenanceSummaryReports


Pg. 185

The Contractor shall provide the following summary reports to the Airports Authority on a monthly basis and be readily available in detail or summary format over the network to the Airports Authority personnel on a daily, weekly or any time period determined by the Airports Authority:

1. Average time to respond and time to repair for the preceding weeks Maintenance activities

2. Time to respond exceeding the allowed maximum. Each item shall be detailed with a description as to why the maximum times were not adhered with and any corrective actions to ensure these do not continue.

3. Time to respond and repair exceeding the allowed maximum. Each item shall be detailed with a description as to why the maximum times were not adhered with and any corrective actions to ensure these do not continue.

4. Total down time of any lane or equipment for the preceding week 5. Lane availability, weekly 6. System availability, weekly 7. Equipment availability, weekly 8. Detailed list of parts replaced as a result of Maintenance actions 9. Status of removed parts and equipment (System generate part numbers,

being repaired in Maintenance shop, purchase replacement part, etc). 10. Trend analysis of repetitive failures 11. Status of spare parts inventory 12. Personnel staffing and issue

7.11.3 AdditionalMaintenanceSummaryReports

The Contractor shall provide the Airports Authority with up to fifteen (15) additional maintenance reports beyond those defined in this document that the Airports Authority may require in order to determine that the System is operationally sound, functionally efficient, and being maintained to the expected level. The Contractor shall provide all available resources in order to collect data and prepare the required reports.

7.12 On‐SiteDocumentationThe Contractor shall maintain one (1) full set of all TCS documentation including, but not limited to, As-Built documentation (including final DDD), toll equipment service manuals, computer manuals, financial audit and control manual, parts inventory lists and other data as may be required for record purposes. In addition, one (1) set of complete documentation shall be maintained at the Contractor’s home office and one (1) set of complete documentation shall be maintained at the Airports Authority’s administration office at the mainline plaza.

The Contractor shall furnish all maintenance personnel with appropriate System documentation as may be required to perform their respective duties. All System documentation shall be serially numbered and the assignment of all documentation to maintenance personnel shall be recorded at the existing onsite location of the


Pg. 186

Contractor’s local maintenance support. The Contractor shall provide to the Airports Authority a list of documentation assigned to Contractor personnel which shall be updated quarterly.

The documentation provided and/or assembled for the TCS or enhancements to the existing system to support the TCS shall be considered highly confidential. The Contractor’s employees shall not reproduce the documentation or discuss the contents of the documentation with Airports Authority toll collectors or other unauthorized personnel.

The Airports Authority will make available to the Contractor any relevant documentation that it maintains and that will assist in the maintenance of the TCS. However, the Airports Authority will not guarantee the sufficiency, accuracy, or adequacy of any documentation provided.

The Contractor shall keep all documentation current and usable for maintenance of the TCS.

7.13 MaintenancePerformanceRequirements

7.13.1 MaintenanceCoverage

Maintenance Services shall be provided on a 24/7/365 basis. The 24/7/365 coverage shall be a combination of direct on-site work hours and on call availability. The Contractor shall provide on-site personnel to the extent required to meet the maintenance response times and any required preventative, predictive and corrective maintenance procedures. During those hours that a maintenance technician is not physically on-site, coverage shall be performed via an on call basis.

The Contractor shall make every attempt to schedule potential lane closure requirements outside of the peak traffic periods. The Contractor shall coordinate directly with the Supervisor and or toll operations staff in performance of maintenance activities.

In the event extended lane closures will be required to complete certain installation or Maintenance actions, such actions may have to be accomplished during night time hours. All lane closures are subject to the approval of the Airports Authority.

The Contractor shall post a weekly schedule identifying personnel and times of who will be available on-site for Maintenance activities. The schedule will also identify the personnel and times of who will be assigned on call for Maintenance activities. The Contractor shall provide to the Airports Authority on a regular basis the updated schedule, active personnel list, and contact information.

Response and repair times for every maintenance event shall be recorded and reported by the MOMS. The MOMS shall be utilized that provide comprehensive


Pg. 187

reporting package that validates the Contractor performance is in conformance with this document. The Contractor shall be accountable for meeting the response and repair times specified in this Contract, and corresponding Liquidated Damages as specified in Table 7-3: Maintenance Performance Requirements and Parameters.

7.13.2 RequiredPerformanceandLiquidatedDamages

Contractor shall be required to meet Maintenance performance requirements that are detailed in this section. In addition to Airports Authority’s other rights and remedies, the Airports Authority may assess liquidated damages for failure to perform these Maintenance services, including, but not limited to, system performance, availability and mean time between failures, as further described in the in Table 7-3: Maintenance Performance Requirements and Parameters and detailed further below.

Table 7-3: Maintenance Performance Requirements and Parameters

Performance Parameter

Failure Event* Performance Standard

Liquidated Damages

Time to Respond

Severity Level 1

Critical

Acknowledge receipt of failure or priority event within one (1) hour

$250 per occurrence

Time to Respond

Severity Level 2

High

Acknowledge receipt of failure or priority event within four (4) hours

$250 per occurrence

Time to Respond

Severity Levels 3 & 4 Medium & Low

Acknowledge receipt of priority event within eight (8) hours

$250 per occurrence

Individual Event Repair Time

Severity Level 1 Repair or restoration within two (2) hours

$250 per hour beyond repair time


Pg. 188

Performance Parameter

Failure Event* Performance Standard

Liquidated Damages


Severity Level 2 Repair or restoration within twenty four (24) hours

$500 per day (24 hr period) beyond repair time


Severity Levels 3 & 4

Repair or restoration within required time

$250 per business day beyond repair time

*Failure and or other performance availability events are subject to the definitions of Chargeable and Non-Chargeable Failures as identified in Section 2.16.

In the event liquidated damages are assessed the Airports Authority will deduct these from the monthly maintenance invoice.

In addition to Airports Authority’s other rights and remedies, the Contractor shall also be liable for damages associated with the loss of data and/or revenue for the failure of the Airports Authority’s System. Such damages would include and are not limited to resources expended by the Airports Authority resulting from failure of the Airports Authority’s TCS as well as the value of any such lost data or revenue. Because this amount cannot be readily determined liquidated damages shall be assessed for such failure. For every day in which the System fails to operate and revenue and/or data is lost due to the actions or inactions of Contractor, an amount equal to one thirtieth (1/30) of the monthly Maintenance fee and all lost revenue associated with the failure shall be assessed as liquidated damages against the Contractor. Revenue loss will be determined by the Airports Authority, using data for comparable time periods where such loss cannot otherwise be directly determined.

Reports shall be developed by the Contractor to measure whether the performance standards have been met. Where reports are used to measure performance, reports shall be generated by Contractor and provided to the Airports Authority on a monthly basis, unless otherwise specified in the Contract. The reports shall be in a format approved by the Airports Authority. The Airports Authority shall have the right to audit Contractor and system records, date and reports to verify the accuracy of information provided, and if a discrepancy is found the Contractor shall pay the audit expenses.

If the Contractor fails to remedy any failure, defect, or damage within 14 calendar days after receipt of notice, unless permitted otherwise by the Contracting Officer, the Authority shall have the right to replace, repair, or otherwise remedy the failure, defect, or damage at the Contractor's expense.


Pg. 189

7.14 SecurityAll Contractor personnel shall be subject to appropriate security and background checks to the satisfaction of the Airports Authority. The Contractor shall obtain Approval from the Airports Authority for all service personnel. Contractor’s personnel shall be issued identification badges, and shall wear such identification badges at all times when on Airports Authority property. Use of such identification badges for purposes other than work associated with the Contract will result in termination of the employee from the Contract, and possible other legal or disciplinary action.

The services and work performed under the Contract are considered highly confidential. All employees of the Contractor shall not discuss their work with the Airports Authority toll collectors, with other unauthorized personnel, or any individuals not directly associated with the Airports Authority. Contact with Toll Collectors shall be limited to problem data gathering only and not solution audit information.

The Airports Authority will identify and designate primary points of contact for the Contractor communications. Under most circumstances, the Contractor shall limit communication with the Airports Authority to Airports Authority’s designated points of contact.

Discussion of any services or work performed on the Airports Authority’s toll system with the media, in oral presentations, in written publications or in any other form must be approved in advance by the Airports Authority.

7.15 ConfidentialityThe Contractor shall keep all information regarding its activities pursuant to the TCS confidential and shall communicate such information only with authorized Airports Authority personnel or Airports Authority designated representatives.


Pg. 190

8 LIQUIDATEDDAMAGESFORDISRUPTIONOFSERVICE

In the event the Contractor causes any unscheduled disruption or adverse impact to the Legacy TCS affecting use, the Contractor shall be subject to the following Liquidated Damages shown in Table 8-1. An ‘unscheduled disruption’ shall mean any event which was not planned, scheduled or approved prior by the Airports Authority.

Table 8-1: Liquidated Damages For Disruption in Service

DISRUPTION EVENT PERFORMANCE MEASURE

LIQUIDATED DAMAGE AMOUNT

For each lane that is unavailable where another lane is STILL available.

Per one (1) hour of unavailability.

$250 per hour

For each lane that is unavailable where another lane is NOT available.

Per one (1) hour of unavailability.

$1000 per hour

Loss of plaza operations or functionality (including communication failure with any lane or subsystem)

Per one (1) hour of unavailability

$1000 per hour


Pg. 191

9 SOFTWAREESCROW

For all software deliverables, the Contractor and/or Supplier(s) shall provide for source code escrow, identifying the proposed escrow agent, stating whether the Airports Authority would become a beneficiary to an existing escrow agreement or enter a new one with the Contractor or Supplier(s), and describing the deposit materials, the release conditions, and the terms of the post-escrow license.

1. The deposit materials will include all deliverables and all updates and modifications to such deliverables, specifically including all software deliverables in source code format, and all other materials and information necessary for the Airports Authority to operate, maintain and modify such software;

2. The release conditions shall include any event of insolvency on the part of the Selected Contractor or its Supplier(s), as well as the inability or refusal of the Contractor or its Supplier(s) to perform required maintenance, support, or development for any reason; and

3. The Airports Authority shall have a perpetual and fully paid-up license to use the deliverables, including all software, in a manner no more restricted than that set out in the Selected Contractor’s Proposal, or in any Supplemental Agreement, and to modify and maintain the software deliverable as necessary to enjoy all such rights.