FMDS vs PERTI: Functional Comparison & Adaptation Analysis

1. Executive Summary

What is FMDS?

The Flow Management Data and Services (FMDS) program is the FAA's effort to replace the legacy Traffic Flow Management System (TFMS), a suite of automation tools developed since the late 1980s that supports traffic flow management across the National Airspace System (NAS). TFMS manages over 45,000 flights daily and is used at 114+ facilities (21 ARTCCs, 35 TRACONs, 17 ATCTs, the ATCSCC, and others).

FMDS was announced as a Challenge-Based Acquisition (ChBA) in September 2025, with Initial Operating Capability (IOC) targeted for Q1 FY2029 (December 2028). The program defines six core functional areas: Manage Data (F.1), Assess NAS State (F.2), Conduct Traffic Flow Management (F.3), Conduct Post-Event Analysis (F.4), Manage Display (F.5), and Maintain Operations (F.6). Key documents include the final Program Requirements Document (fPRD, 160 pages), Concept of Operations (ConOps, 91 pages), Functional Analysis Document (FAD, 186 pages), and Human Interface Guidelines (HIG, 49 pages).

What is PERTI?

PERTI (Plan, Execute, Review, Train, Improve) is the VATSIM virtual ATC network's flow management platform, operated by vATCSCC (Virtual Air Traffic Control System Command Center). Built on PHP 8.2, Azure SQL, PostgreSQL/PostGIS, and MySQL, PERTI provides real-time flight data management, TMI modeling and implementation, demand/capacity analysis, spatial boundary processing, compliance monitoring, and multi-facility coordination -- all adapted for the VATSIM virtual ATC environment.

Why This Comparison Matters

PERTI was designed independently to solve many of the same problems the FAA faces: balancing demand with capacity, coordinating TMIs across facilities, and providing integrated situational awareness. This document systematically maps FMDS's functional requirements against PERTI's existing capabilities to:

1. Identify where PERTI already provides equivalent functionality
2. Highlight gaps where FMDS capabilities could be adapted
3. Document areas where PERTI exceeds the FMDS baseline
4. Establish a roadmap for bringing FMDS concepts into PERTI

2. Methodology

This comparison was conducted through:

1. Document-by-document review of all 14 FMDS acquisition documents (fPRD, ConOps, FAD, HIG, SOO, Master Site List, Method of Evaluation, and supporting attachments)
2. Codebase audit of the PERTI repository, examining PHP API endpoints, Python analysis scripts, JavaScript frontend modules, SQL schemas, and daemon processes
3. Functional mapping against the FMDS hierarchy (F.0 through F.6 and all sub-functions) using FMDS requirement IDs (FMDS_fPRD_XXXX) as reference points
4. Coverage classification using the following scale:

3. Functional Area Comparison

F.1 -- Manage Data

Ingests and processes external data sources including flight, weather, aeronautical, CDM, and space data to create a common model of NAS operations.

F.1.1 -- Ingest Data

F.1.2 -- Process Data

F.1.3 -- Derive Data

F.1.4 -- Provide Data

F.2 -- Assess NAS State

Evaluates the current and projected state of the NAS and enables Traffic Managers to identify near- and long-term problems.

F.2.1 -- Specify Resource Capacity

F.2.2 -- Predict Resource Demand

F.2.3 -- Compare Demand and Capacity

F.2.4 -- Predict Route Availability (RAPT)

F.2.5 -- Conduct NAS State Analysis

F.2.6 -- Manage Notifications

F.3 -- Conduct Traffic Flow Management

Provides tools to maintain the flow of air traffic by defining FxAs, conducting TMIs, and logging NAS events.

F.3.1 -- Define FxAs (Flow Evaluation/Constraint Areas)

F.3.2 -- Conduct TMIs

F.3.3 -- Manage NAS Event Log

F.4 -- Conduct Post-Event Analysis

Employs historical data to improve algorithms, enable replay, and generate reports of past data.

F.5 -- Manage Display

Manages the user interface display and configuration settings.

F.6 -- Maintain Operations

Records and archives operational data, maintains adaptation, monitors the system, manages access, and supports testing/training.

4. Coverage Summary

Overall functional coverage: ~64% (Full + 50% of Partial = ~82% weighted)

The strongest areas are TMI implementation (GDP, GS, restrictions), data management, demand prediction, and notification/coordination. The weakest areas are advanced display features, route availability prediction, probabilistic demand, and training/testing infrastructure.

5. Where PERTI Exceeds FMDS

PERTI provides several capabilities that FMDS does not describe or that go beyond FMDS's scope:

5.1 Discord-Based Multi-Facility Coordination

FMDS describes automated coordination methods (fPRD_0906-0914) but within its internal automation system. PERTI's Discord-based coordination system (load/discord/MultiDiscordAPI.php, discord-bot/bot.js) provides:

• Multi-organization support -- Coordination across independent virtual ATC organizations (VATUSA, VATCAN, etc.)
• Reaction-based approval -- Facility representatives approve/deny TMI proposals via Discord reactions, tracked in tmi_proposal_reactions
• Public transparency -- TMI advisories and coordination visible to the entire virtual ATC community
• Rich media -- Advisory messages with formatted embeds, compliance charts, and visual aids

5.2 TMI Compliance Analysis Engine

While FMDS requires TMI monitoring (F.3.2.6), PERTI's compliance analysis goes deeper:

• Python backend (scripts/tmi_compliance/core/analyzer.py): Haversine-based spacing calculations, traffic sector computation, flow cone analysis with bearing clustering
• JavaScript frontend (assets/js/tmi_compliance.js, ~280KB): Approach bearing → 45-degree clustering → per-stream distance-bin centerline → Gaussian smoothing → monotonic convergence → buffer polygon visualization
• Multi-type analysis: MIT, MINIT, GS compliance with real-time and historical data

5.3 PostGIS Spatial Processing

FMDS references geographic boundaries and airspace, but PERTI implements sophisticated spatial processing:

• Real-time boundary detection (adl/php/boundary_gis_daemon.php): Every 15 seconds, determines which ARTCC/TRACON/sector each flight occupies using PostGIS ST_Contains
• Crossing prediction (adl/php/crossing_gis_daemon.php): Predicts when flights will enter/exit boundaries with time estimates
• Route parsing with geometry (adl/php/parse_queue_gis_daemon.php): Converts route strings to PostGIS geography with waypoint resolution
• Pre-computed grid lookup (adl_boundary_grid): Fast lat/lon → boundary mapping without full polygon intersection

5.4 Airport Taxi Reference System

PERTI's airport taxi reference (airport_taxi_reference, 3,628 airports) uses a methodology inspired by the FAA ASPM program:

• 90-day rolling window with P5-P15 average (excluding outliers)
• Minimum 50 samples before trusting observed data
• Blended default-to-observed transition as sample size grows
• Per-airport unimpeded taxi time for GS delay analysis

5.5 SWIM API with WebSocket

PERTI's SWIM API (api/swim/v1/) provides FIXM-aligned data access that goes beyond FMDS's data provision requirements:

• REST API with API key authentication and tiered access
• WebSocket server (api/swim/v1/ws/WebSocketServer.php) for real-time event streaming
• Topic-based subscriptions via SubscriptionManager.php
• Flight data in FIXM-compatible format via swim_flights denormalized view

5.6 Virtual Airline and Pilot Client Integration

FMDS serves institutional users (FAA facilities, CDM airlines). PERTI extends to individual participants:

• Flight simulator plugins (MSFS, X-Plane, P3D) for direct data exchange
• Pilot client plugins (vPilot, xPilot) for SimBrief import and position reporting
• Virtual airline modules (phpVMS, smartCARS, VAM) for organizational participation
• vATIS integration for automated runway and weather correlation

5.7 Normalized Flight Data Architecture

PERTI's 8-table normalized flight architecture (adl_flight_core, adl_flight_plan, adl_flight_position, adl_flight_times, adl_flight_tmi, adl_flight_aircraft, adl_flight_trajectory, adl_flight_waypoints) is more modern than TFMS's legacy monolithic design. This architecture enables:

• Independent update cycles for position, timing, and TMI data
• Efficient querying of specific data domains
• Change tracking via adl_flight_changelog with field-level granularity

6. VATSIM-Specific Considerations

Several factors make the VATSIM environment materially different from real-world NAS operations, affecting how FMDS concepts can be adapted:

6.1 Traffic Volume and Predictability

Impact: Probabilistic demand prediction (IDP) may be less effective due to lower traffic volumes and less predictable scheduling. Event-based demand forecasting may be more appropriate.

6.2 Infrastructure Differences

Impact: PERTI doesn't need FMDS's disaster recovery, multi-site failover, or 99.99% availability. However, architectural improvements (API modularization, better caching) would benefit scaling.

6.3 Operational Scope

Impact: PERTI's TMI compliance is inherently advisory. Features like EDCT enforcement, formal slot substitutions, and CDM member data quality tracking have reduced importance.

6.4 Weather

VATSIM does not simulate weather effects on aircraft performance. Weather on VATSIM is informational only -- it affects runway selection and ATIS but not aircraft trajectories or separation requirements. This means:

• RAPT/route blockage has limited value (no convective avoidance necessary)
• Weather-based capacity reduction is a training/realism exercise rather than operational necessity
• Wind-adjusted trajectory modeling has value for ETA prediction but not safety

7. Recommended Adaptation Roadmap

Based on the gap analysis and VATSIM-specific considerations, the following adaptations are prioritized by impact and feasibility:

Tier 1: High Impact, High Feasibility (0-6 months)

Tier 2: High Impact, Medium Feasibility (6-12 months)

Tier 3: Medium Impact, Higher Effort (12-24 months)

Tier 4: Lower Priority / VATSIM-Specific Adaptation (Ongoing)

Appendix A: FMDS Document Index

Appendix B: PERTI File Reference Index

TMI System

• api/tmi/gdp_preview.php -- GDP impact preview with arrival-time filtering
• api/tmi/gdp_apply.php -- Apply GDP from sandbox to live ADL
• api/tmi/gdp_simulate.php -- GDP simulation
• api/tmi/gs/ -- Full GS lifecycle (create, model, activate, extend, purge, flights, demand, list, get)
• api/tmi/gs/common.php -- Shared GS utilities (DB helpers, auth, input parsing)
• api/tmi/gs_preview.php -- Ground Stop preview with departure filtering
• api/tmi/advisories.php -- TMI advisory management
• api/tmi/entries.php -- TMI restriction entries (MIT, MINIT, STOP, APREQ, etc.)
• api/mgt/tmi/coordinate.php -- Multi-facility coordination workflow
• api/mgt/tmi/promote.php -- TMI promotion (staging to active)
• scripts/tmi_compliance/core/analyzer.py -- Python TMI compliance engine

Flight Data Management

• scripts/vatsim_adl_daemon.php -- 15-second flight data ingestion
• adl/php/parse_queue_gis_daemon.php -- Route parsing with PostGIS
• adl/php/boundary_gis_daemon.php -- Spatial boundary detection
• adl/php/crossing_gis_daemon.php -- Boundary crossing prediction
• adl/php/waypoint_eta_daemon.php -- Waypoint ETA calculation

Demand & Capacity

• api/adl/demand/fix.php -- Fix-based demand
• api/adl/demand/segment.php -- Route segment demand
• api/adl/demand/airway.php -- Airway demand
• api/demand/airport.php -- Airport demand
• api/demand/rates.php -- AAR/ADR rates
• api/demand/override.php -- Manual rate overrides
• assets/js/demand.js -- Demand chart visualization

Display & Visualization

• assets/js/route-maplibre.js -- MapLibre route visualization
• assets/js/tmi-active-display.js -- Active TMI display
• assets/js/tmi_compliance.js -- TMI compliance visualization (~280KB)
• assets/js/weather_radar.js -- Weather radar overlay
• assets/js/gdt.js -- Ground Delay Table
• assets/js/splits.js -- Sector split management

External APIs

• api/swim/v1/ -- SWIM API (FIXM-aligned)
• api/swim/v1/ws/WebSocketServer.php -- Real-time WebSocket

Infrastructure

• load/discord/MultiDiscordAPI.php -- Multi-org Discord posting
• discord-bot/bot.js -- Discord Gateway bot for coordination
• scripts/startup.sh -- Daemon orchestration
• scripts/archival_daemon.php -- Trajectory tiering and archival