Attachment_F_-_Requirements_Compliance_Matrix.xlsx
XLSX spreadsheet 34 KB Posted
- Attached to
- Passenger Flow Management Solution and Services State and local contract opportunity
- Solicitation number
- RFP 26-0285
- Issued by
- Maricopa County, Phoenix City, Arizona
About this file
This is a Requirements Compliance Matrix for a Passenger Flow Management Solution and Services contract issued by the City of Phoenix for Phoenix Sky Harbor International Airport. The solicitation seeks a turn-key passenger flow management system designed to monitor, analyze, and optimize passenger movement and queue management across multiple airport operational areas for a seven-year contract term beginning January 1, 2027. The system must dynamically detect and monitor queues at TSA security checkpoints, capture and process passenger data at rates of 250 milliseconds or less, deliver position data with maximum latency of two seconds and precision of 50 centimeters or better, and provide real-time queue length, wait time, and passenger activity information. The solution must be capable of scaling across additional operational areas including ticket counters, concessions, baggage dropoff, airline lounges, terminal curbsides, airport roadways, gate hold areas, restrooms, and aprons without requiring system architecture changes.
Vendors are required to complete the compliance matrix by indicating whether each requirement can be met through out-of-the-box functionality (OOB), software configuration changes (SCON), additional hardware (AHAR), custom development (CUST), or is not supported (NS). The system must integrate with Microsoft Active Directory and Azure Active Directory/ADFS for authentication, operate on VMware virtual machines within Aviation's infrastructure, run the latest supported versions of Windows and SQL Server, support high-volume data collection and processing, and provide comprehensive reporting and visualization capabilities including heat maps, density plots, trend lines, and customizable dashboards. The system must generate hourly automatic fault reports, provide real-time equipment health telemetry and monitoring, and send alerts via dashboard, email, and text notifications when preset thresholds for wait times and queue lengths are exceeded. Additionally, the solution must provide a fully functional API for data retrieval and integration with airport systems and enterprise data warehouses while maintaining security compliance with City of Phoenix Identity Management and Password Management standards.
View the file
Other files for this state and local contract opportunity
Show all 18
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Instructions
| Instructions | |
| 1. | In each section, complete column 'D' of the table. Use one of the following abbreviations to indicate how much effort is needed to meet the requirement: |
| OOB – Out of the Box, no software or code changes are required to meet requirement. The cost for out of the box functionality is included in the Vendor’s proposed software cost. | |
| SCON – Software configuration changes (no custom development) are required to meet requirement. Vendor must specify if cost for configuration is not included in the Vendor’s proposed software cost. | |
| AHAR – Additional Hardware is required to meet the requirement. Vendor must specify what hardware is included in base quote and must provide pricing for any additional hardware required to meet requirement. | |
| CUST – Custom development is required to meet requirement. Vendor must include pricing for custom development to be completed in the Vendor’s proposed timeline. If costs are included in Vendor’s base proposal, Vendor is to state that no additional costs are included. | |
| NS – Not supported, cannot meet requirement. | |
| 2. | After each section, please enter any additional comments or feedback, including alternative approaches you may recommend if you cannot meet the requirement in column 'E'. |
SYSTEM REQUIREMENTS
| Requirements | Response Code | Description | Response Dropdown List |
| System Functional Requirements | OOB | ||
| Recommended equipment must capture data at a rate of 250ms or less. | SCON | ||
| Recommended equipment must deliver the position data with a maximum latency of 2 seconds. | AHAR | ||
| Recommended equipment must deliver the position data with a precision of 50 cm or less. | CUST | ||
| Dynamically detect and monitor queues that form and dissipate as part of daily operations and provide information including but not limited to – queue length (i.e. number of people in the TSA checkpoint queue), actual queue wait time (i.e. how long it takes for the queue to get from point A to point B), estimated queue wait time, and similar data. | NS | ||
| The Pax Flow System must adapt to changes in passenger flow due to unforeseen circumstances, such as delays, cancellations, emergencies and queue configuration changes and allow for dynamic adjustments based on real-time conditions. | |||
| Provide information based on various segments of the same queue. For example, how long it takes to move in the queue from start of queue to the TSA Travel Document Checker (TDC) podium, from the document check to the X-ray screening station and from the screening station to the recomposure area. Additionally, the System must dynamically include additional passenger wait time in the overflow area in its calculations. | |||
| Dynamically detect and provide information on different queues that form concurrently in the same physical area but pertain to different operational processes. For example, be able to differentiate queues for General Boarding Lane, Special Needs/Priority, TSA Pre-Check Lane, CLEAR, PHX Reserve, etc. at a TSA security checkpoint. The System shall dynamically detect open/closed and lane switching (e.g. TSA PreCheck vs General Boarding or blended lanes). | |||
| Be able to provide an accurate count of people physically present in the TSA checkpoint queue and number of people boarding and offboarding airport trains at each PHX Sky Train station. | |||
| Have capability to discern between airport representatives, TSA uniformed workforce, passengers and other populations to strengthen the accuracy of anonymized data. | |||
| Be able to use historical information, real-time queue and passenger flow information, and other sources of data, such as flight information, to predict queue lengths, wait times, and passenger activity levels in specific parts of PHX. For example, providing an estimated wait time at the TSA Security Checkpoint based on historical wait times, current wait times, projected passenger volumes, number of individuals in line, their speed, projected flight activity, and TSA staffing models and checkpoint processing rates. | |||
| Upon reaching preset thresholds for wait times and queue length, take appropriate action by notifying stakeholders via a dashboard, email, and text alerts to enhance Aviation’s ability to allocate its resources based on real-time needs. The Pax Flow System must have the capability to provide customizable alert notifications. The System shall detect abnormal activity (e.g. sudden crowd surges) and alert airport personnel. | |||
| The Pax Flow System must be capable of scaling additional operational areas across PHX, including, but not limited to, ticket counters, concessions, baggage drop‑off, airline lounges, terminal curbsides, airport roadways, gate hold areas, restrooms, and aprons without requiring any system architecture changes. The System must also support expansion into other passenger and operational areas, such as pedestrian walkways, employee access points, commercial and retail queuing areas, and perimeter fence monitoring to enhance both passenger experience and security. | |||
| The Pax Flow System must be designed for modular scalability, enabling capacity expansion without proportional cost increases. | |||
| Contractor must propose architectures that optimize resource utilization and minimize incremental costs as demand grows. | |||
| The Pax Flow System must be flexible and easily adapt as queue configurations are changed, for example, as TSA checkpoint lane layouts change. | |||
| Must provide a fully functional API that enables retrieval of operational data. This API must support seamless integration with other airport systems and third-party platforms through standardized protocols or an integration platform. Additionally, the Pax Flow System must allow ingestion of data into an enterprise data warehouse to support analytics and reporting. | |||
| Be highly configurable and flexible so Aviation and its stakeholders can understand, visualize, and manage passenger flow and queueing in multiple ways. The Pax Flow System must support a variety of operational perspectives; for example, terminal operations staff may need to review passenger flow data to determine queue lengths, wait times, and train passenger counts during peak periods such as holidays or special events. The System shall provide an operator toolkit to define, visualize, and adjust queue entry and exit boundaries. | |||
| Be able to collect, transmit and store high volumes of passenger data traffic. Use either on-premises, cloud, or hybrid infrastructure for storage, processing, and delivery of passenger flow analytics. | |||
| Handle large volumes of passengers, especially during peak times, such as holidays or special events. | |||
| Integrate with airport business intelligence platforms, data warehouses or other data stores, if needed, to share data analytics and insights. | |||
| Ad hoc reporting: The Pax Flow System must provide robust ad hoc reporting tools that allow authorized users to query, filter, and analyze the full range of collected data points without Contractor intervention. This includes historical, real‑time, and predictive datasets to support operational decision-making. | |||
| Secure, role‑based access: Reports, dashboards, and administrative interfaces must be securely accessible from desktop environments, with access controlled through Aviation-defined user groups and permission structures. The Pax Flow System must align with Aviation security and infrastructure standards outlined in the SOW. | |||
| Mobile access and cloud support: Where feasible, the Pax Flow System must provide mobile‑friendly dashboards optimized for responsive viewing on tablets and smartphones. Preference will be given to cloud‑based or hybrid architectures that inherently support modern mobile reporting capabilities. On-premises deployments may offer limited mobile functionality and must clearly describe any constraints associated with such environments. | |||
| Advanced data visualization: Dashboards must include a suite of visualization tools, including, but not limited to, heat maps, density plots, trend lines, queue length charts, dwell time visualizations, and passenger‑movement flow diagrams to support an intuitive understanding of operational conditions. Visualizations must be configurable and exportable to meet stakeholder reporting needs. | |||
| Provide custom reports/dashboards and enable multiple user accounts that include, but are not limited to: |
i. Passenger wait times per TSA checkpoint, per queue lane with passenger counts Hourly with 15-minute average per queue
| Weekly, with an hour-by-hour average per queue |
| Monthly, with a weekly average |
| Yearly, with a monthly average |
ii. Provide passenger on/off counts, time stamps for each door, and Sky Train
iii. Station by name
| Daily, with an hour-by-hour average by berth (Sky Train door) |
| Weekly, with an hour-by-hour average by berth (Sky Train door) |
| Monthly, with a weekly average by berth (Sky Train door) |
| Yearly, with a monthly average by berth (Sky Train door) |
| The Pax Flow System must be modular, allowing for seamless upgrades and expansions as technology advances, new technologies emerge, or airport requirements evolve. It must also be adaptable to emerging challenges, including changes in security protocols, shifts in passenger behavior, and evolving airline industry trends. |
| The Pax Flow System must provide a mechanism (e.g., RESTful API, database-level connectivity) to access all source data necessary for operational reporting, analytic modeling, historical analysis, and integration with Aviations’s Enterprise Data Warehouse (EDW) and Business Intelligence platforms. |
| Account Management Requirements |
| Contractor must demonstrate conformance with the City’s Identity Management Standard (INF200.201, Attachment N) and Password Management Standard (ISS300015, Attachment O), including all roles, processes, and technical controls defined therein. |
| The solution must integrate with Microsoft Active Directory (on-premises) and Azure Active Directory/ADFS (cloud) as authoritative sources for authentication. |
| System Infrastructure Requirements |
| The on-premises server environment must be built as virtual machines running within Aviation’s VMware clusters and be VMware High Availability (HA) and Distributed Resource Scheduler (DRS) process-tolerant. |
| Computer resource allocation must be based on virtual machine requirements as opposed to bare metal and will be provisioned with an emphasis on efficient allocation rather than over-engineering. |
| Aviation standardizes on Microsoft stack, meaning Windows/SQL Server, etc. Contractor application must run the latest supported version of the operating system and database platform, no greater than (n-1). |
| Contractor’s application must be tolerant of Microsoft Volume Shadow Copy service as part of snapshots and backup operations. |
| All edge and cloud components shall maintain cryptographically authenticated time synchronization using secure protocols (e.g., authenticated NTP or secure PTP). |
| Time synchronization shall ensure consistent timestamps across all system components. |
| Availability and Monitoring Requirements |
| Pax Flow System must provide equipment health telemetry, including monitoring uptime, performance, and component status. This information must be presented on a GUI dashboard for Aviation staff to monitor. |
| Pax Flow System shall detect, log, and report errors in real time, including malfunctions, data anomalies, and communication failures, and send alerts via text and email immediately to Aviation stakeholders of System outages or failures. |
| Pax Flow System must generate an hourly automatic fault report in real time as the System monitors and automatically tests itself. |
Data Validation
| Compliance Response |
| Out of the Box |
| Configuration Change |
| Programming Change - On Roadmap |
| Programming Change - Custom Development |
| Not Supported |
File details come from the government source that posted it. Updated .