Page | 1

Table of Contents

Table of Contents

1. Executive Summary

2. Project Objectives & Success Criteria

2.1 Objectives

2.2 Success Criteria

3. Scope Boundaries

3.1 In-Scope

3.2 Out-of-Scope

3.3 Existing System Overview

4. Technical Proposal / Solution Overview

4.1 System Architecture

4.2 U.S. Market Presence

4.3 Roadside Subsystems

4.4 Back Office Platform

4.5 Integrated Garage & Parking + Tolling Experience

4.6 Integration Layer

4.7 Resilience and Monitoring

5. Functional Requirements

5.1 Transaction Lifecycle

5.2 Tag-less Revenue Capture

5.3 Special Handling Scenarios

5.4 Integrations

5.5 Security & Compliance

Page | 2

5.6 Data Management

6. Business Rules

6.1 Rate Models

6.2 Exemptions & Discounts

6.3 Dispute & Collections

7. Installation & Transition Plan

7.1 Permits & Safety

7.2 Gantry & Cabinet Installation

7.3 Existing Facilities and Equipment Mapping

7.4 Replacement and Upgrade Plan

7.5 Cutover & Data Migration

7.6 Operational Readiness

8. Roadway Support System Installation Design

8.1 Structural

8.2 Electrical

8.3 Network

8.4 Environmental

9. Disaster Recovery Plan

9.1 Disaster Recovery Objectives

9.2 Disaster Recovery Strategies

9.3 Disaster Recovery Procedures

9.4 Business Continuity

9.5 Testing & Drills

9.6 Documentation & Compliance

Page | 3

10. Reconciliation & Audit Manual

10.1 Daily Cycle

10.2 Exceptions

10.3 Periodic Audits

10.4 GL Reconciliation

11. Operations & Maintenance

11.1 Monitoring

11.2 ServiceNow ITSM

11.3 Long-Term Operational Expenditure

11.4 Field Maintenance

12. Service Level Agreements (SLA)

13. Glossary of Terms

13.1 Glossary of Terms & Acronyms

Appendix A: Technical Requirements

A.1 System Architecture

A.2 Roadside Subsystems

A.3 Back Office Platform

A.4 Integration Layer

A.5 Resilience and Monitoring

A.6 Functional Requirements (Expanded)

A.7 Roadside Systems & Subsystems

A.8 Interfaces and Data Requirements

Appendix B: Testing Documentation

B.1 Testing Strategy and Philosophy

Page | 4

B.2 Test Planning

B.3 Test Execution

B.4 Test Reporting and Issue Management

B.5 Test Templates and Artifacts

B.6 Roles and Responsibilities

B.7 Continuous Improvement

Appendix C: Compliance & Regulatory

C.1 Security & Data Protection

C.2 Audit & Traceability

C.3 Regulatory Reporting & Certifications

C.4 Data Sovereignty & Jurisdiction

C.5 Third-Party & Vendor Compliance

C.6 Compliance Monitoring & Continuous Improvement

Appendix D: Detailed Business Rules

D.1 Overview

D.2 Rate Models

D.3 Exemptions & Discounts

D.4 Collision & Credential Conflict Resolution

D.5 Dispute & Collections Workflows

D.6 Partner Onboarding & Management

D.7 Exception Handling & Manual Review

D.8 Reporting & Compliance

D.9 Change Management

Appendix E: Campus map

Page | 5

1. Executive Summary

DFW Airport (The Board) is committed to advancing its digital transformation agenda and reducing wait-times for every guest throughout the travel journey. As one of the nation’s most highly regarded international gateways, DFW is focused on delivering an experience that reflects the scale, pride, and innovation of

Texas.

To support projected growth to more than 100 million passengers by 2030 and beyond, the airport is expanding its infrastructure with a new terminal, enhanced roadways, consolidated transportation operations, and the removal of operational barriers where possible.

A major milestone in this transformation will occur in 2029, when the existing parking control plazas on

International Parkway are removed to establish a fully Open Road Environment (ORE).

An ORE leverages advanced digital identity, automated screening, and real‑time data to move customers more efficiently and confidently through each stage of their journey. This technology eliminates traditional bottlenecks, minimizes wait times, and delivers a smoother, more intuitive traffic flow. At the same time, an integrated technology ecosystem strengthens security, modernizes revenue operations, and enables a more seamless, high‑performing airport experience.

This Scope of Work (SOW) defines the comprehensive requirements, deliverables, and standards for the design, development, installation, testing, transition, and ongoing operations of the Parking Access and

Revenue Control System (PARCS) for DFW International Airport. The SOW integrates best practices and requirements from prior project baselines and the latest industry RFPs, ensuring a robust, resilient, and future-ready solution for access fee collection, revenue assurance, and operational excellence. The PARCS will enable accurate, efficient, and auditable transactional parking and access operations, minimize revenue leakage, and provide seamless integration with enterprise and partner systems. This document is intended for use by project stakeholders, procurement teams, technical reviewers, and implementation partners.

DFW is providing high level intent for each section of this document. While not all specifics are detailed, the information included is intended to give vendors sufficient context to propose their solutions and platforms effectively.

Page | 6

2. Project Objectives & Success Criteria

This section defines the measurable objectives, KPIs, and performance standards the solution must achieve to be considered successful. It outlines both operational expectations and compliance thresholds across credentialing, billing, integrations, security, and reliability. These criteria guide vendor responses, system design decisions, and acceptance testing throughout the project lifecycle.

2.1 Objectives

• Transaction Integrity: Achieve end-to-end transaction integrity, ensuring every vehicle event is captured, matched, billed, and reconciled with ≥99% accuracy.

• Revenue Assurance: Minimize revenue leakage to ≤0.5% of captured transactions, with robust exception handling and audit trails.

• Integration: Deliver seamless, real-time integrations with enterprise and partner systems, including DFW App, NTTA, General Ledger (GL), ServiceNow, Parking Guidance System (PGS), App Orchid and others.

• Resilience: Ensure system resilience, including offline capture, local buffering, and rapid recovery from outages or disasters.

• Compliance: Meet or exceed all Key Performance Indicators (KPIs) and regulatory requirements, including PCI DSS, SOC 2, and ISO 27001.

2.2 Success Criteria

• ≥99% transaction integrity for in-scope matched transactions.

• ≤0.5% revenue leakage (due to system performance).

• 100% of scoped integrations “green” in demo; ≥95% of messages within SLA (≤2 minutes).

• ≥99% auto-resolution of multi-tag/collision events.

• ≥99% accurate exemption handling for special plates.

• Successful completion of all acceptance tests (FAT, SAT, OAT).

• Full documentation, training, and operational readiness at go-live.

Page | 7

3. Scope Boundaries

This section establishes the full scope of the solution, including all business functions, technical domains, and operational areas included in–or excluded from—the project. It clarifies what the solution must cover across parking, roadways, access control, trip‑building, integrations, and back‑office operations, as well as which responsibilities remain outside vendor scope. This section ensures alignment between DFW, vendors, and implementation teams.

3.1 In-Scope

The solution shall provide campus‑wide vehicle credential capture, spanning all entry, exit, routing, and circulation points across International Parkway, terminal garages (A–E), Express and Remote lots, hotel/valet areas, employee lots, and all other designated access locations. Credential capture must not be limited to roadside tolling gantries but must encompass all DFW access control environments.

In scope activities include:

• Campuswide Capture: Deployment of Automatic License Plate Recognition (ALPR) cameras, side‑fired devices, RFID/AVI transponder readers, BLE beacons, lane controllers, vehicle sensors, and/or edge processors across all access points. (See appendix E for a campus map).

• Credential Resolution & Business Rules: Implementation of business logic for rate calculation, exemptions, collision handling, and exception management.

• Billing, Collections, Audit, Reconciliation: Automated and auditable processes for billing, collections, financial reconciliation, and reporting.

• Enterprise System Integrations (Examples Only: The system shall integrate with DFW enterprise platforms, including but not limited to:

– Financial systems (E.g. AR, GL)

– Salesforce

– Workday

• – Snowflake

NOTE: This list is illustrative and not exhaustive; additional enterprise systems may be added without requiring SOW modification.

• Disaster Recovery, Training, O&M: Comprehensive DR planning, staff training, and ongoing operations and maintenance.

• Trip‑Building & Orphan Transactions Prevention: The system must include automated trip‑building logic capable of identifying and resolving unmatched entry or exit events to prevent

Page | 8 orphan transactions. This includes the ability to detect incomplete trip records, apply configured matching rules, close out lingering entries, and generate audit‑ready reconciliation outputs. The logic must operate in real time and during replay of buffered transactions, ensuring complete transaction integrity across all lanes and facilities.

• Charging Customers with and Without Toll Tags: System must fully support tag‑based and tag‑less workflows, including ALPR‑only identification, credential resolution, owner lookup, fee calculation, and billing workflows for vehicles lacking toll tags.

• Parking Privilege / Employee Access Integration: Integration with DFW’s employee Parking

Privilege Application (PPA) or successor system. Credential updates must propagate to access control in real time, enabling unified ingress/egress across all parking and roadway assets.

• Reservations, PGS, and Parking System Integrations:

Integration with:

– Parking Guidance System (PGS)

– Parking reservation platforms

– Employee access/contract parker systems (See appendix E for a campus map)

• Exhibits and Maps

An exhibit shall provide a public GIS‑based infrastructure map showing core roadway, garage, surface lot, and access‑point capture infrastructure.

3.2 Out-of-Scope

• Civil works not directly related to toll system installation (e.g., major roadway construction, unrelated utility work).

• Legacy system decommissioning outside the scope of the transition plan.

3.3 Existing System Overview

The current parking infrastructure at DFW Airport consists of multiple control plazas (North, South, 5E), terminal garages, infield and Express lots, Remote lots, hotel and valet areas, and associated lane equipment. The existing system includes a mix of ticket issuing devices, AVI readers/antennas, barrier gates, CCTV, cashier terminals, lane lights, intercoms, and LPR cameras. (See appendix E for a campus map)

In-Scope for Replacement:

All legacy parking control equipment at these facilities will be replaced with new PARCS-compliant

Page | 9 equipment. The new system will provide end-to-end transaction integrity, enhanced credential capture, and modernized business rule enforcement.

4. Technical Proposal / Solution Overview

This section outlines the expected technical architecture and capabilities of the proposed system. It defines the core technology components required to support a unified platform for credential capture, data processing, integrations, resilience, and monitoring. Vendors will use this section as a baseline to propose compliant system architectures, deployment models, and technology stacks.

4.1 System Architecture

• Modular Microservices: The PARCS shall be based on a modular, microservices based architecture, supporting scalability, maintainability, and rapid deployment of new features.

• Data Integration: All integrations shall be managed through a secure API gateway or other modern data integration approaches (not file based), supporting REST/GraphQL, event streaming (Kafka or equivalent), and webhooks.

• Configuration by end users: The platform/solution must have the ease of configuring both the functionality and configuration using an easy-to-use interface (preferably web interface). We expect this functionality to cover key areas like a rules engine (among others) to manage business logic for rate calculation, exemptions, and exception handling.

• Hybrid Deployment Requirement: The platform must support a hybrid on‑premises + cloud architecture with no functional delta between deployments. Vendors must not limit features or capabilities to cloud‑only environments. All core functions (transaction processing, credentialing, reconciliation, analytics feeds) must operate fully on‑prem when required.

• Edge AI Support: System should support edge‑based processing for image recognition, ALPR optimization, and metadata extraction where beneficial for latency reduction; however, cloud‑offloading must also be supported.

• Event Bus: Real-time and batch data flows between roadside equipment, back office, and third-party systems.

• Secure Data Stores: All data at rest and in transit must be encrypted (AES-256 or better), with

PCI DSS compliance and regular vulnerability assessments.

• High Availability & DR: Active-active or active-standby configurations, automated failover, and quarterly DR drills.

Page | 10

4.2 U.S. Market Presence

Vendors must demonstrate substantial experience delivering parking and tolling combination solution within the United States market, including deployments with state DOTs, toll authorities, airport authorities, or major metropolitan agencies. Vendors must provide:

• References for U.S. deployments of comparable scale

• Evidence of meeting U.S. regulatory, privacy, and security standards

• Demonstration of interoperability with U.S. transponder protocols and ALPR standards

• Documented performance benchmarks (read rates, match rates, leakage, latency)

4.3 Roadside Subsystems

The system must fully support a modern free‑flow, barrier‑less revenue environment in which vehicles pass through roadside capture points without stopping, slowing, or interacting with physical equipment. All revenue capture, credential capture, and transaction classification must occur automatically via ALPR, AVI, BLE, and sensor inputs. The vendor must demonstrate proven experience delivering free‑flow revenue collection systems with:

• High‑speed vehicle capture (minimum of 100mph)

• Near‑real‑time transaction creation

• Automated exception handling

• Resilience under mixed traffic conditions (garage exits, plazas, slip‑ramps)

The system must maintain throughput without lane impedance and provide real‑time monitoring of capture quality, latency, and failure rates.

• Toll Gantries Equipment: Equipped with ALPR cameras (day/night/IR), RFID AVI/transponder readers, BLE beacons, lane sensors, and controllers. All equipment must be housed in

NEMA/IEC-rated cabinets with resilient power (UPS) and lightning protection.

• Credential Capture: Capture vehicle credentials (tag, plate, vehicle attributes), timestamp, and lane metadata for every transaction, including:

o RFID/AVI Toll Tag Data

Including tag ID, protocol type (e.g., ISO 1800063 “6C”, SeGo, EZPass), read confidence, and antenna source.

Page | 11 o License Plate and ALPR Data

Including plate number, state, jurisdiction, image set (overview + plate crops), and confidence scoring.

o Vehicle Attributes

Including body class, axle count (when applicable), and any classification outputs defined by business rules.

o Event Metadata

Including timestamp, lane ID, approach direction, gantry/location ID, and sensor derived metadata (speed, direction, queueing).

o Metallized Windshield

System a must be capable of reliably capturing RFID/AVI toll tags mounted on vehicles equipped with metallized (metal‑oxide coated) windshields, which are known to reduce or block passive transponder readability under standard installations.

4.3.1 Video Feed Capture & Analytics Enablement

The roadside subsystem shall include high‑quality video capture capabilities that complement ALPR, AVI/Tag reads, and sensor data. Video must be treated as an integral part of the credential capture, transaction validation, and security workflow. The system must meet the following functional and technical requirements:

A. Video Capture Requirements

Each roadside capture point (gantry, lane controller, garage ingress/egress, express/remotes, circulation roads) must support:

• High‑resolution video suitable for transaction validation, vehicle movement analysis, operator identification, and security/audit review.

• Day/Night/IR capability for full‑time operation in all weather conditions

• Synchronized timestamping aligned with ALPR, AVI, and sensor events

• Continuous loop recording with configurable retention policies

• Automatic clipping of video segments associated with each transaction event

Video clips must be tied to the transaction’s unique identifier and stored as part of the full event evidence package.

Page | 12

B. Smart Camera / Edge AI Processing

To reduce bandwidth and accelerate insight generation, the system must support smart cameras or edge‑compute modules capable of performing local inference, including but not limited to:

• Motion / object detection

• Vehicle path tracking

• Vehicle classification assistance (body style, lane position, movement behavior, etc.)

• Threshold‑based alerts (queue buildup, stalled vehicle, reverse movement, sudden stops, etc.)

• Environmental triggers (visibility, occlusions, camera obstruction notifications, etc.)

The system must allow DFW to configure the rules engine that governs when video‑based triggers occur.

C. Video Metadata Capture

Each video event must generate metadata that can be consumed by DFW Enterprise Systems. Metadata may include:

• Camera ID and GPS/gantry location

• Lane ID

• Trigger type (ALPR hit, AVI tag read, threshold breach, rule event, etc.)

• Motion vectors or movement classification (optional)

• Confidence scoring (object/vehicle classification)

• Environmental context (lighting, weather impact where available)

This metadata must align with the broader enterprise analytics strategy, including future Digital Twin ingestion at DFW.

D. Evidence Bundling & Retrieval

Video associated with a transaction must be bundled into the transaction’s evidence package, enabling:

• Dispute resolution

• Dunning / collections evidence

• Security / law enforcement investigative workflows

• Operational quality checks

Page | 13

The system must:

• Generate short, bounded clips (e.g., 3–10 seconds before/after the event)

• Support export of raw video or compressed formats

• Allow DFW staff to retrieve video through API or Back Office UI

• Prevent tampering by enforcing chain‑of‑custody controls and audit logs

E. Integration with High‑Volume Data Platforms

Given the volume of video and metadata:

• The system must support Kafka‑based or equivalent event streaming for transporting video metadata to enterprise platforms

• Support integration with analytics platforms (e.g., Video Analytics or others)

• Provide configurable throttling, batching, and compression

This reflects the team's point that video will represent high‑volume, high‑speed data and should be compatible with the integration layer.

F. Performance & Network Considerations

• Edge processing should minimize video load on the network where possible

• When transmitting videos, the system must:

o Apply optimal compression o Use adaptive bitrate were supported o Allow configuration of frame rate and resolution per site

• API access must support multiple subscribers without performance degradation

G. Security Requirements

Video streams and clips must be protected in accordance with DFW security policy:

• AES‑256 encryption at rest

• TLS 1.2+ in transit

• Strict role‑based access controls

• Audit logs for all viewing, export, deletion, and modification events

Page | 14

H. Future Analytics Enablement

The system must not restrict future use of video for any attributes like

• Queue length estimation

• Occupancy estimation (garage/lot)

• Behavioral detection (wrong-way movement, speeding, loitering)

• Predictive analytics using historical video metadata

• Integration with DFW’s long‑term Digital Twin initiatives

4.3.2 Local Buffering Requirements

• Roadside controllers must support offline operation, buffering all transactions and images for at least 30 days in the event of network outage, with automatic replay upon reconnection.

• DFW has a robust private cellular network, and vendors can leverage this network as a fallback to keep operations running.

• The results of information processed (e.g., transaction data, images, metadata, logs) across all the roadside devices including ALPR cameras, AVI readers, controllers, edge processors, lane sensors, and BLE beacons, must be buffered for a minimum of 30 days at peak throughput.

4.3.2 Automatic Replay Upon Connectivity Restoration

• When network connectivity is restored, the system must:

o Automatically detect restoration of primary or backup network paths.

o Automatically re-transmit buffered transactions and evidence.

o Reconcile replayed data with the back-office to avoid duplication.

o Flag late-arriving transactions for appropriate processing and reporting.

4.3.3 Remote Retrieval of Buffered Data During Extended Outages

To eliminate the historic need for on-site manual data collection (e.g., using USB drives), the system must support at least one of the following:

A. Automatic Remote Retrieval via Cellular Backup Network (Preferred)

• Each roadside controller must support an integrated or addon 4G/5G modem or private

LTE/CBRS module.

Page | 15

• If primary fiber/ethernet connectivity is down:

o The controller should automatically switch to cellular backhaul.

o Buffered data must trickle-sync over cellular bandwidth intelligently to avoid network congestion.

• System must implement:

o Adaptive sync, prioritizing critical metadata first.

o Compression of image/video data prior to upload.

o Encrypted transmission (TLS 1.2+) for all cellular data.

B. Remote Retrieval via Portable Mesh/UAV Relay Units

(Optional, advanced support)

• In extreme outage conditions (storms, fiber cuts), the vendor may optionally provide:

o Portable mesh network repeaters.

o UAV (drone) relay modules capable of securing data handoff from roadside equipment.

4.3.4 Remote Administrative Access and Monitoring

• During network outages (primary or secondary), the system must still allow:

o Remote health monitoring (CPU/temperature, storage, sensor connectivity).

o Remote access for diagnostics, where permitted by the security model.

o Remote reboot, service restarts, and mode switching.

• If remote access fails, the system must produce:

o Alerts via ServiceNow or similar ITSM integrations.

o Offline operational logs saved to local storage for later analysis.

4.3.5 Security Requirements for Remote Data Retrieval

All remote retrieval methods must adhere to the following:

• Zero-trust authentication (device certificates, API tokens, or hardware keys).

• AES-256 encryption at rest and TLS 1.2+ in transit.

• Audit logs tracking:

o Who retrieved data.

o When retrieval occurred.

o Volume and type of retrieved data.

Page | 16

• Automatic quarantine of any re-uploaded data that fails integrity checks.

4.3.6 Prohibited Methods

To protect operational integrity and eliminate historical inefficiencies:

• The vendor must not require physical removal of media (e.g., SD card swapping).

• The vendor must not require USB thumb drives or laptops for normal data retrieval operations.

• The system must not depend on manual data extraction methods for outage recovery except in catastrophic failure scenarios.

4.3.7 Vendor Documentation and Validation Requirements

Among other key documents, vendors must include:

• A description of the high-level architecture and data flow diagrams

• A network flow diagram

• Documentation that can demonstrate during FAT/SAT:

o Simulated fiber outages.

o Automatic failover to cellular.

o Remote retrieval validation.

o Successful reconciliation in back-office.

4.4 Back Office Platform

The Vendor shall provide a mature, production-proven Back Office Platform that supports enterprise‑grade transaction processing, financial reconciliation, credential management, dispute resolution, customer case management, reporting, call center operations, and integration functions required for DFW’s operational, financial, and customer‑service environments.

In addition to the traditional back‑office capabilities listed below, the Vendor must provide a domestic, U.S.–based customer contact center function that delivers high‑quality customer support, case resolution, and multi‑channel communication aligned with DFW’s service level expectations.

The Back Office Platform shall include, at minimum, the following functional domains:

Page | 17

4.4.1 Customer Contact Center & Case Management

The Vendor must provide a domestic U.S‑based call center operation, staffed and equipped to manage customer inquiries, payment issues, disputes, refunds, violations, and account updates associated with

DFW’s Parking and Access Fee systems. This capability is not optional.

The system and Vendor operational model must support:

Contact Center Operations

• A U.S based staffed call center during Airport defined operating hours

• Call routing, queueing, and IVR logic for customer triage (integration with DFW IVR Genesys or its replacement)

• Call recording, supervisor monitoring, and real‑time “listen‑in” capability for QA

• Dedicated queues for DFW Parking/Access Control Center, separate from other vendor customer operations

• Ability for airport customers to get customer support via phone and digital means

Customer Case Management

• A unified customer record consolidating calls, vehicles, payments, notices, disputes, refunds, and interactions

• Creation, editing, closing, and reopening of customer cases

• Association of each customer case to:

1. Vehicles

2. Transactions

3. Invoices

4. Refund requests

5. Payment attempts

6. Case Management

• Ingestion of customer activity from calls, emails, web forms, online disputes, and payment channels

Dispute Handling & Workflow Support

• Full lifecycle management of disputes including overcharge scenarios, Toll Tag issues, camera mismatches, veterans’ plates, and lost‑card cases

• SLA tracking of dispute resolution timelines, backlog visibility, and exception queues

• Ability to generate refund packages or evidence bundles required by Airport Finance team

• Case status notifications via email/SMS or portal

Page | 18

Collections Call Process Integration

• Automated collections workflows from case creation → notices → payment reminders → status updates

• Contact management logic ensuring notices are only sent to customers with active unpaid balances

• Bidirectional status updates between customer’s financial balance and collections case management

4.4.2 Transaction Management

End‑to‑end support for ingesting, validating, rating, posting, and storing all transactional events, including:

• Vehicle credential data (plate, tag, BLE)

• Trip‑building

• Rate assignment

• Fee calculation

• Evidence package linkage (images, video, timestamps)

4.4.3 Billing, Invoicing & Collections

Automated and auditable workflows for:

• Recurring billing cycles

• Invoice generation for plate‑based, partner, and corporate accounts

• Payment processing, adjustments, reversals, settlements, and chargebacks

• Automated collections workflows, aging buckets, dunning cycles

• Reporting on revenue assurance and integration with Airport financial systems

4.4.4 Financial Reconciliation & Auditability

The Back Office Platform must provide:

• Daily and periodic reconciliation workflows

• Exception queues for mismatched or orphan transactions

• Audit trails meeting or exceeding DFW’s compliance standards

• Integration with Oracle Fusion for GL posting

• Role‑based approval workflows for adjustments, refunds, and write‑offs

Page | 19

4.4.5 Credential & Account Management

Support for managing:

• Customer accounts

• Partner accounts (airlines, hotels, ground-transportation operators)

• License plates, tags, badges

• Exemptions and entitlements

• Credential validity periods, audit history, and usage visibility

4.4.6 Dispute Resolution & Exception Handling

Configurable workflows for investigating and resolving:

• Overcharges

• Credential conflicts/multi-tag events

• Unmatched entry/exit trips

• Image/metadata mismatches

• Orphan transactions

• Customer refund requests and chargeback cases

4.4.7 Reporting & Dashboarding

The Back Office Platform must provide:

• Operational dashboards

• Collections and aging dashboards

• Call center performance dashboards (volume, wait time, agent productivity, SLA compliance

• Trend analysis

• Reconciliation reporting

• Full support for ad‑hoc queries and data export for Airport leadership and auditors

• Support for enterprise tools such as Snowflake and Tableau

4.4.8 Rate & Business Rules Engine

A configurable, version‑controlled rules engine to support:

• Complex rate structures

• Dynamic pricing

• Time‑band or event pricing

• Exemptions and discounts

• Special programs

• Configuration without vendor intervention where appropriate

Page | 20

• Integration with Airport pricing systems

4.4.3 Operational Specification: Domestic Call Center Core Requirements

A. Technology

• Cloud CCaaS: Central cloud phone platform with 99.99% uptime.

• Smart Routing: IVR menus and ACD to send callers to the right agent.

• CRM & Ticketing: Unified software to track customer history and issues.

• Knowledge Base: Central digital library for quick agent troubleshooting.

B. People & Structure

• Agents: Native-language agents split into Tier 1 (general) and Tier 2 (technical).

• Supervisors: Floor managers maintaining a 1:15 ratio with agents.

• Support Staff: Dedicated QA analysts and WFM traffic schedulers.

4.5 Integrated Garage & Parking + Revenue Collection

Experience

The system must provide unified customer experience across parking operations, garages, express lots, and roadside revenue collection, ensuring that vehicle credentials, entitlements, and billing workflows function seamlessly across all DFW access points. Requirements include:

• Consistent credential recognition (plate, tag, BLE, barcode) across parking and roadside revenue environments

• Shared business rules for rate assignment, exemptions, and entitlements

• Unified billing for garage, parking, and roadside revenue transactions where applicable

• Integrated customer journey through the MyDFW App, reservation systems, and partner platforms

• Cross‑system reporting and analytics for operational visibility

4.6 Integration Layer

• Integration Complexity & Capability: The vendor must support complex, multi‑system integrations consistent with DFW’s enterprise architecture, including real‑time, batch, and event‑driven interfaces. The integration framework must:

o Support REST, GraphQL, event streaming, and webhook‑based interactions

Page | 21 o Provide pre‑built connectors or accelerators for common airport/tolling partners (e.g., NTTA, DMV lookup, GL, Salesforce, ServiceNow, reservation platforms, etc.)

o Manage API throttling, retries, error isolation, schema validation, and secure token handling o Provide monitoring dashboards for integration health, message failures, and latency o Offer partner onboarding tools for third‑party integrators

• Partner Onboarding: Self-service portal for third-party partners (e.g., airlines, hotels) to manage credentials, API keys, and integration testing.

The vendor must demonstrate experience handling complex, multi‑system integration ecosystems of comparable scale.

4.7 Resilience and Monitoring

Vendor solution must adhere to the standard resilience and monitoring standards expected of a tier 1 platform. Vendor shall share all the relevant documents that show these capabilities in action. Some of the activities that DFW will be looking for are:

• Ability to operate independently in Offline/Standalone Mode: Roadside systems must continue to operate and buffer data during network or cloud outages, with automated replay and reconciliation.

• Degree of Monitoring & Alerting: Integrated with ServiceNow and enterprise monitoring tools for real-time health checks, incident management, and automated alerts for outages, exceptions, and SLA breaches.

5. Functional Requirements

This section describes the functional capabilities the system must deliver across the full transaction lifecycle. It details expectations for credential capture, trip‑building, matching, pricing, billing, exception handling, integrations, and security. These requirements define how the system must operate day‑to‑day to support DFW’s business processes, customers, and operational teams.

5.1 Transaction Lifecycle

• Capture: Vehicle credentials (tag, plate, vehicle attributes), timestamp, and lane metadata must be captured for every vehicle event. Must use ALPR and computer‑vision techniques capable of

Page | 22 reliably distinguishing legitimate license plates from bumper stickers, novelty plates, decorative art, and other non‑regulatory plate‑like imagery to prevent false credential capture and misclassification.

• Match: Entry and exit events must be correlated using configurable matching logic, supporting slip ramp and multi-lane scenarios.

• Bucket: Rate engines must assign transactions to the correct rate category, applying discounts, exemptions, and dynamic pricing as configured.

• Bill: Automated invoice generation for individual, fleet, and corporate accounts; support for multiple payment channels.

• Reconcile: Daily and periodic reconciliation of transactions, revenue, and financial records;

exception handling for unmatched, miscategorized, or misclassified events.

• Trip‑Building: System must identify, correlate, and construct vehicle journeys across all access points, including terminal garages, IP Parkway, surface lots, and circulation roads. Trip‑building must resolve unmatched events and prevent orphan transactions.

• Fee Calculation: The system must calculate all applicable fees for every transaction, including:

– International Parkway usage rates

– Parking rates

– Dynamic pricing

– County‑specific tax rules (North vs South exit)

– Discounts, exemptions, partner programs

• Tag‑less & Tag‑based Processing: Transaction creation must work for:

– AVI/RFID tag holders

– ALPR‑only customers

– BLE‑based vendor app users

– Partner/contract parkers

– Contract parkers (PPA‑managed)

5.2 Tag-less Revenue Capture

The system must support full revenue capture for customers without toll tags through ALPR‑based identification and an integrated intelligent app that utilizes pay-per-use capability. This ensures frictionless tolling for all customers, regardless of whether they possess an active toll tag.

DFW prefers to leverage an integrated intelligent app that end customers can use to pay-per-use. This app must have the ability to be integrated into the MyDFW app of the airport.

Page | 23

5.3 Special Handling Scenarios

• Multi-Tag Handling: Rule-based resolver for vehicles with multiple tags or conflicting credentials;

operator queue with reason codes for manual resolution.

o Tag/Plate Precedence: Configurable logic for resolving multiple credentials.

o Confidence Thresholds: Adjustable thresholds for ALPR and tag reads.

• Disabled/Veteran Plates: Automated detection using ALPR and state lists (e.g., TxDOT); audit trail for exemption decisions.

• Ground Transportation: Support for special rate categories (e.g., hotel, valet, employee, promotional programs, etc.).

• Hot Plate List: must provide Hot Plate / Watchlist detection functionality that supports

Department of Public Safety (DPS) and the Board security needs, including the ability to ingest, update, and process law‑enforcement‑provided watchlists (hot plates), triggering real‑time alerts and security notifications when a matching vehicle is detected.

• Whitelist/Blacklist Logic: Automated and manual management of credential lists.

5.4 Integrations

This list is illustrative and not exhaustive; additional enterprise systems may be added without requiring

SOW modification.

• MyDFW App: Account linkage, receipts, customer notifications.

• Parking Guidance System (PGS): Occupancy and wayfinding integration.

• Reservations: Entitlement validation and advance purchases. (Aero parker)

• NTTA: Tag validation, hotlist/whitelist feeds.

• GL/Financials: Posting, journals, reconciliation. (Oracle Fusion)

• ServiceNow: Incident, problem, change, maintenance.

• Salesforce: customer profiles

• Milestone VMS

• Snowflake

• 3rd party systems that support demand-based pricing, Video Stitching/Analytics

Page | 24

5.5 Security & Compliance

• PCI DSS Compliance: All payment and credential data must be handled in accordance with PCI

DSS standards.

• RBAC & MFA: Role-based access control and multi-factor authentication for all system users.

• Encryption: All data at rest and in transit must be encrypted.

• Vulnerability Management: Regular scans, patching, and remediation.

• Firmware updates: must ensure that all security controls extend to firmware running on every system component, including field devices, controllers, sensors, ALPR units, AVI readers, and

VCATS modules, and must support secure, authenticated, and auditable firmware upgrade processes to maintain compliance with the Board cyber and operational standards.

5.6 Data Management

All data processing activities, including background jobs, analytics workloads, replay operations, synchronizations, data exports, retention/purge routines, and any vendor‑managed automated tasks, must be designed and executed in a manner that does not degrade the performance, availability, latency, throughput, or stability of the Production environment; the system must dynamically manage resource allocation to ensure operational efficiency, predictable response times, and reliable transaction processing under all load conditions.

It must support configurable data retention and deletion processes that comply with the Board Records

Retention Policy, including required purging, archival, and masking of data (PII and non‑PII) according to the Board defined schedules; all data stored, processed, transmitted, or generated by the system, including transaction data, images, logs, audit records, and metadata; shall be the sole property of the Board, and the Vendor shall have no ownership rights or independent usage rights to this data under any circumstances.

See Appendix A for full technical requirements.

6. Business Rules

This section defines the configurable business logic that governs all pricing, exemptions, conflicts, disputes, and collections processes. It captures how the system should determine rates, apply discounts, Page | 25 resolve credential conflicts, enforce tax rules, and manage financial adjustments. The goal is to ensure consistent, transparent, and auditable application of DFW’s policies.

6.1 Rate Models

• Vehicle Classes: Public, ground transportation, hotel, valet, employee, off-airport, promotional, and custom rate cards.

• Flat Rates & Time Bands: Support for fixed pricing windows and time-based rules.

• Dynamic Pricing: vendor must have ability to apply demand-based pricing

• Tax Jurisdiction Handling: The system must automatically apply the correct tax rate for any transaction fee based on the guest’s exit location. Because DFW Airport spans two counties, the system must determine whether the vehicle exited on the North or South end of the airport and apply the corresponding county tax rate accordingly. The tax logic must be fully configurable, auditable, and traceable in the rules engine, and must support future changes in tax policy without requiring code modifications.

6.2 Exemptions & Discounts

• Special Plates: Automated eligibility validation for Disabled Veterans (DV), government, and authorized exemptions.

• Partner Entitlements: Integration with hotel, airline, parking privilege and corporate partner programs.

6.3 Dispute & Collections

• Evidence Retention: Images, timestamps, and transaction history for dispute resolution.

• Adjustment/Rebill: Workflow for correcting and rebilling transactions.

• Dunning & Escalations: Automated reminders, escalation processes, and collections integration.

See Appendix D for detailed business rules.

Page | 26

7. Installation & Transition Plan

Need introductory paragraph for request: DFW to state transition expectations, Phase 1 then into Phase 2

OR we can include in the overall vision under 1. Executive Summary

7.1 Permits & Safety

• Regulatory Compliance: All work must comply with TxDOT, OSHA, and local regulations.

• Traffic Control: Lane closures, detours, and safety barriers as required.

• Safety Plans: Lift plans, hazard assessments, PPE requirements.

7.2 Gantry & Cabinet Installation

• Foundations: Structural engineering, stamped drawings, inspections.

• Erection: Gantry assembly, equipment mounting, cable routing.

• Commissioning: Power-up, network integration, initial testing.

7.3 Existing Facilities and Equipment Mapping

A comprehensive inventory of all current parking and tolling facilities, equipment, and control points is provided in the specifications

1. This includes:

• Control Plazas: North, South, and 5E, each with multiple entry/exit lanes equipped with ticket issuing devices, AVI readers, barrier gates, CCTV, cashier terminals, lane lights, and intercoms.

• Terminal Garages and Surface Lots: Each terminal (A–E) has garages and infield/express lots with varying equipment configurations.

• Remote Lots, Hotel, and Valet Areas: Specialized equipment for remote and hotel parking, including integration with hotel guest validation and valet operations.

7.4 Replacement and Upgrade Plan

• Replacement: All existing parking control equipment at the listed facilities will be replaced with new PARCS-compliant equipment.

Page | 27

• Decommissioning: Legacy equipment identified for replacement will be removed and disposed of per Board policy. Salvaged items will be delivered to the Board Salvage Yard.

• Transition Sequencing: New equipment will be installed in parallel with legacy systems to ensure uninterrupted operations. Cutover will occur only after successful testing and Board acceptance.

• Integration Points: Any equipment or systems not being replaced (E.g., certain hotel or valet systems) will be integrated as required, or interfaces will be provided for manual processes during transition.

7.5 Cutover & Data Migration

Vendor shall provide a detailed cutover plan in alignment with DFW’s planned phasing of this implementation. DFW will be looking for high level details of expertise from your other implementations showcasing these activities. Some of the key details we will be looking for include:

• Parallel Run: Operate new and legacy systems in parallel during transition.

• Staged Lanes: Phased activation of lanes and equipment.

• Rollback Plan: Procedures for reverting to legacy system if needed.

• Data Migration: Import partner entitlements, DV plate lists, NTTA lists, rate tables.

• Partnering with Planning and construction

7.6 Operational Readiness

Vendor should partner with DFW to create a detailed Operational Readiness plan covering all facets of this implementation. Some of the key areas that we are looking for are:

• Playbooks: Step-by-step guides for go-live and incident response.

• On-Call Rotations: Defined escalation paths for support.

• Escalations: Procedures for critical incidents.

8. Roadway Support System Installation Design

Vendors must provide detailed specifications for all required infrastructure (gantries, cabinets, power, network, etc.), but construction and installation may be performed under a separate contract.

Vendors must provide a transition plan and timeline for moving from the current system to the new solution.

Page | 28

8.1 Structural

• Load Calculations: Wind, seismic, fatigue analysis.

• Stamped Drawings: Licensed engineer approval.

• Foundations: Concrete, anchor bolts, corrosion protection.

8.2 Electrical

• Power Distribution: Sizing, redundancy, UPS, surge protection.

• Grounding: Lightning protection, bonding.

• One-Line Diagrams: Detailed electrical schematics.

8.3 Network

• Topology: DMZ, segmentation, VLANs.

• Bandwidth: Sizing for peak transaction and image loads.

• Redundancy: Dual paths, failover, port lists, TLS encryption.

8.4 Environmental

• Ingress Protection: IP65+ for all outdoor equipment.

• Thermal Management: HVAC, condensation control.

See Appendix A for technical details.

9. Disaster Recovery Plan

This section defines the disaster recovery (DR) and business continuity (BC) requirements, procedures, and responsibilities for the Parking Control System (PARCS). The goal is to ensure that the PARCS can withstand, recover from, and continue operations during and after disruptive events, including hardware/software failures, cyber incidents, natural disasters, and other emergencies.

Page | 29

9.1 Disaster Recovery Objectives

9.1.1 Recovery Time Objective (RTO)

• Definition: The maximum acceptable time to restore a system or service after a disruption.

• Requirement: RTO for all critical PARCS services (transaction capture, credential resolution, billing, reconciliation, reporting) shall not exceed 4 hours.

9.1.2 Recovery Point Objective (RPO)

• Definition: The maximum acceptable amount of data loss measured in time

• Requirement: RPO for all critical PARCS data (transactions, images, audit logs) shall not exceed

15 minutes.

9.1.3 Prioritized Services

• Tier 1: Transaction capture, credential resolution, and image storage

• Tier 2: Billing, reconciliation, and reporting

• Tier 3: Analytics, dashboards, and non-critical integrations

9.2 Disaster Recovery Strategies

9.2.1 System Redundancy

• Active-Active/Standby: All critical PARCS components (roadside, back office, networking) must be deployed in redundant configurations, either active-active or active-standby.

• Automated Failover: The system must detect failures and automatically failover to standby systems with no manual intervention required for Tier 1 services.

9.2.2 Local Buffering & Replay

• Roadside Buffering: Roadside controllers must buffer all transactions and images for at least 30 days in the event of network or back-office outage.

• Automated Replay: Upon restoration of connectivity, buffered data must be automatically replayed and reconciled with the back office.

Page | 30

9.2.3 Data Backup & Restore

• Backup Frequency: Full backups of all critical data must be performed nightly; incremental backups every 15 minutes.

• Backup Storage: Backups must be stored in at least two physically and geographically separate locations.

• Restore Testing: Quarterly restore tests must be performed and documented.

9.2.4 Cloud & On-Premises DR

• Cloud Deployments: Must leverage multi-region, multi-availability zone redundancy.

• On-Premises Deployments: Must have a secondary DR site at least 100 miles from the primary site, with full data replication.

9.3 Disaster Recovery Procedures

9.3.1 DR Plan Activation

• Trigger Events: DR plan is activated in response to major outages, data corruption, cyber incidents, or physical disasters.

• Authority: The DR Coordinator or designated executive has authority to activate the DR plan.

• Notification: All stakeholders (operations, IT, partners, authorities) must be notified within 30 minutes of DR activation.

9.3.2 Incident Response

• Initial Assessment: Determine scope and impact of the incident.

• Containment: Isolate affected systems to prevent further damage.

• Eradication: Remove threats (e.g., malware, compromised accounts).

• Recovery: Restore systems and data from backups or failover sites.

• Validation: Test restored systems for integrity and functionality before resuming operations.

9.3.3 Communication Plan

• Internal: Regular updates to all PARCS staff and management.

Page | 31

• External: Notification to partners, customers, and regulatory authorities as required.

• Templates: Pre-approved communication templates for incidents and recovery status.

9.3.4 Roles & Responsibilities

Role Responsibilities

DR Coordinator Maintains plan, leads drills, activates DR, coordinates recovery

IT Operations Executes technical recovery, backup/restore, failover, and validation

Business Leads Ensures continuity of critical business functions, manual workarounds

Communications Lead Manages internal/external communications during incidents

Vendors/Partners Support recovery of their components, participate in drills, maintain compliance

9.3.5 Contact Lists

• Essential Personnel: Names, roles, phone numbers, email addresses

• Vendors & Partners: Support contacts, escalation paths

• Authorities: Regulatory and emergency contacts

9.4 Business Continuity

9.4.1 Continuity of Operations

• Critical Functions: Identify and prioritize all critical business functions (transaction processing, billing, customer support).

• Manual Workarounds: Document manual procedures for toll collection, billing, and reconciliation if automated systems are unavailable.

• Alternate Work Locations: Identify backup locations for operations and support staff.

9.4.2 Resource Management

• Staffing: Maintain a list of essential personnel and alternates for all critical roles.

• Supplies: Ensure availability of spare parts, consumables, and backup equipment.

• Vendor Coordination: Ensure vendors and partners have their own DR/BC plans and are contractually obligated to support recovery.

Page | 32

9.5 Testing & Drills

9.5.1 DR Drills

• Frequency: Conduct full DR drills at least quarterly.

• Scope: Include failover, backup/restore, manual workarounds, and communication protocols.

• Documentation: Record outcomes, lessons learned, and corrective actions.

9.5.2 Continuous Improvement

• Post-Incident Reviews: After any real incident or drill, conduct a review to identify gaps and update the DR/BC plan.

• Plan Updates: Review and update the DR/BC plan annually or after major system changes.

9.6 Documentation & Compliance

• DR/BC Plan Storage: Maintain up-to-date copies of the DR/BC plan in both digital and hardcopy formats at primary and secondary locations.

• Audit Readiness: All DR/BC activities, tests, and incidents must be logged and available for audit.

• Regulatory Compliance: Ensure DR/BC plan meets all applicable regulatory requirements (PCI

DSS, SOC 2, ISO 27001, state/federal laws).

10. Reconciliation & Audit Manual

This section documents the financial reconciliation processes required to ensure revenue integrity across all transactions.