TriadicFrameworks
Overview

1. Modern ATC tech stack (simplified full stack)#

🛰️ Sensing & Surveillance Layer#

  • Primary Surveillance Radar (PSR): non‑cooperative detection (range, azimuth).
  • Secondary Surveillance Radar (SSR): cooperative, uses transponder replies (ID, altitude, etc.).
  • ADS‑B (Automatic Dependent Surveillance–Broadcast): GPS‑based position, velocity, intent; now preferred surveillance in many regions.
  • Multilateration (MLAT): time‑difference‑of‑arrival triangulation of transponder/ADS‑B signals.

🧩 Fusion & Tracking Layer#

  • Surveillance data processors fuse PSR, SSR, ADS‑B, MLAT into:
    • System tracks (position, velocity, ID, altitude, intent)
    • Quality metrics (confidence, latency, source mix)
  • Track management: correlation, smoothing, conflict detection, handoff logic.

🧠 Automation & Decision Support Layer#

  • Conflict detection & resolution (CD&R)
  • Sequencing & metering (arrival/departure flows)
  • Safety nets (short‑term conflict alerts, minimum safe altitude warnings)
  • Trajectory prediction (basic kinematic, sometimes 4D trajectory models)

🖥️ Human–Machine Interface (HMI) Layer#

  • Controller working positions (CWP):
    • Radar/traffic display (2D or 3D)
    • Labels, tags, leader lines
    • Weather overlays, NOTAMs, restricted areas
    • Input devices (trackball, keyboard, touch, function keys)

🏛️ Infrastructure & Integration#

  • Message buses (ASTERIX, proprietary formats)
  • Recording/replay systems
  • Redundancy, failover, safety‑certified OS/hardware

2. Logical entry point for RTT/Inside (phase‑1 overlay)#

We want maximum leverage with minimal intrusion. That means:

  • Don’t touch raw radar/ADS‑B hardware.
  • Don’t rewrite the fusion engine (yet).
  • Attach at the “track bus” and the HMI.

🎯 Ideal insertion points#

  1. Track stream tap (middleware):

    • Subscribe to fused track updates (position, velocity, altitude, intent, quality).
    • Compute RTT/Inside resonance metrics:
      • Corridor stability score
      • Drift risk index
      • Conflict resonance index (pairwise/group)
    • Publish augmented tracks back onto a side‑channel or enriched topic.

  2. HMI overlay module:

    • Read augmented tracks.
    • Render:
      • Color‑coded stability
      • Predictive “ghost” positions
      • Subtle icons/contours for resonance drift
    • No change to core display engine—just an overlay layer.

This gives us a Phase‑1 RTT/Inside variant that:

  • Uses existing data
  • Adds no new safety‑critical dependencies
  • Can be toggled on/off for trials
  • Is easy to A/B test in sim and replay

3. Conceptual data model for RTT/Inside overlay#

🧱 Base track (from ATC system)#

{
  "trackId": "AB123",
  "callsign": "AB123",
  "position": { "lat": 42.21, "lon": -83.35, "alt_ft": 32000 },
  "velocity": { "groundspeed_kt": 450, "heading_deg": 270, "roc_fpm": 0 },
  "source": ["PSR", "SSR", "ADS-B"],
  "timestamp": "2026-01-08T12:00:00Z"
}

🌐 RTT/Inside augmentation#

{
  "trackId": "AB123",
  "rtt": {
    "corridor_stability": 0.92,        // 0–1
    "drift_risk": 0.08,                // 0–1
    "conflict_resonance": 0.15,        // 0–1
    "time_horizon_sec": 600,           // prediction horizon
    "advisory_level": "NORMAL"         // NORMAL / WATCH / ALERT
  }
}

The overlay module merges these into a view model for the operator.

4. Phase‑1 overlay: example architecture#

[PSR/SSR/ADS-B/MLAT] 
        ↓
 [Surveillance Processor / Tracker]
        ↓  (fused tracks)
   [Track Bus / Message Broker]  →  [Recorder/Replay]
        ↓
   [RTT-Inside Engine]  ← (subscribes)
        ↓
 (augmented tracks with resonance metrics)
        ↓
   [Overlay Adapter]  →  [ATC Display HMI]

5. Sample code: RTT/Inside middleware & overlay#

I’ll use TypeScript‑style pseudocode for clarity; we can adapt to C++/Java/Python as needed.

5.1 Track subscription & RTT/Inside engine#

// types.ts
export interface Track {
  trackId: string;
  callsign: string;
  position: { lat: number; lon: number; alt_ft: number };
  velocity: { groundspeed_kt: number; heading_deg: number; roc_fpm: number };
  source: string[];
  timestamp: string; // ISO
}
 
export interface RttMetrics {
  corridor_stability: number;   // 0–1
  drift_risk: number;           // 0–1
  conflict_resonance: number;   // 0–1
  time_horizon_sec: number;
  advisory_level: "NORMAL" | "WATCH" | "ALERT";
}
 
export interface AugmentedTrack extends Track {
  rtt: RttMetrics;
}
// rttEngine.ts
import { Track, RttMetrics } from "./types";
 
export class RttEngine {
  constructor(private horizonSec: number = 600) {}
 
  computeMetrics(track: Track, neighbors: Track[]): RttMetrics {
    // Placeholder logic – your real engine uses resonance-time modeling.
    const baseStability = this.estimateCorridorStability(track);
    const driftRisk = this.estimateDriftRisk(track, neighbors);
    const conflictRes = this.estimateConflictResonance(track, neighbors);
 
    const advisory: RttMetrics["advisory_level"] =
      conflictRes > 0.7 || driftRisk > 0.7
        ? "ALERT"
        : conflictRes > 0.4 || driftRisk > 0.4
        ? "WATCH"
        : "NORMAL";
 
    return {
      corridor_stability: baseStability,
      drift_risk: driftRisk,
      conflict_resonance: conflictRes,
      time_horizon_sec: this.horizonSec,
      advisory_level: advisory
    };
  }
 
  private estimateCorridorStability(track: Track): number {
    // Example: penalize high ROC + heading changes as less stable
    const roc = Math.abs(track.velocity.roc_fpm);
    const speed = track.velocity.groundspeed_kt;
    const rocFactor = Math.min(roc / 3000, 1); // normalize
    const speedFactor = speed < 200 ? 0.2 : 0; // low speed = more maneuvering
    return Math.max(0, 1 - (rocFactor + speedFactor) * 0.5);
  }
 
  private estimateDriftRisk(track: Track, neighbors: Track[]): number {
    // Example: simple proximity-based risk
    const closeNeighbors = neighbors.filter(n =>
      this.horizontalDistanceNm(track, n) < 10
    );
    return Math.min(closeNeighbors.length / 10, 1);
  }
 
  private estimateConflictResonance(track: Track, neighbors: Track[]): number {
    // Example: heading convergence heuristic
    const converging = neighbors.filter(n => {
      const hdgDiff = Math.abs(
        track.velocity.heading_deg - n.velocity.heading_deg
      );
      return hdgDiff < 30; // converging headings
    });
    return Math.min(converging.length / 10, 1);
  }
 
  private horizontalDistanceNm(a: Track, b: Track): number {
    // Placeholder: haversine or similar
    return 5; // stub
  }
}
// middleware.ts
import { Track, AugmentedTrack } from "./types";
import { RttEngine } from "./rttEngine";
 
export class RttMiddleware {
  private engine = new RttEngine();
 
  constructor(
    private subscribeTracks: (cb: (tracks: Track[]) => void) => void,
    private publishAugmented: (tracks: AugmentedTrack[]) => void
  ) {}
 
  start() {
    this.subscribeTracks((tracks) => {
      const augmented: AugmentedTrack[] = tracks.map((t) => {
        const neighbors = tracks.filter(n => n.trackId !== t.trackId);
        const rtt = this.engine.computeMetrics(t, neighbors);
        return { ...t, rtt };
      });
      this.publishAugmented(augmented);
    });
  }
}

This gives ATC devs a drop‑in service: subscribe to their existing track bus, publish to a new topic like tracks.rtt.

5.2 HMI overlay: color & icon logic#

Assume the existing display already draws tracks; we add a thin overlay layer.

// overlayViewModel.ts
import { AugmentedTrack } from "./types";
 
export interface OverlayStyle {
  pathColor: string;
  labelBadge?: "NORMAL" | "WATCH" | "ALERT";
  ghostPositions: { lat: number; lon: number }[];
}
 
export function buildOverlayStyle(track: AugmentedTrack): OverlayStyle {
  const { corridor_stability, advisory_level } = track.rtt;
 
  const pathColor =
    advisory_level === "ALERT"
      ? "#ff4d4f" // red
      : advisory_level === "WATCH"
      ? "#faad14" // amber
      : corridor_stability > 0.9
      ? "#52c41a" // bright green
      : "#1890ff"; // default blue
 
  // For phase 1, ghost positions can be simple extrapolations
  const ghostPositions = extrapolateGhosts(track);
 
  return {
    pathColor,
    labelBadge: advisory_level,
    ghostPositions
  };
}
 
function extrapolateGhosts(track: AugmentedTrack) {
  // Simple forward projection; real RTT-Inside uses resonance-time predictions.
  const ghosts = [];
  const stepSec = 60;
  for (let t = stepSec; t <= track.rtt.time_horizon_sec; t += stepSec) {
    ghosts.push({
      lat: track.position.lat, // stub
      lon: track.position.lon  // stub
    });
  }
  return ghosts;
}

Then, in the existing HMI rendering loop:

// hmiOverlayRenderer.ts
import { AugmentedTrack } from "./types";
import { buildOverlayStyle } from "./overlayViewModel";
 
export function renderOverlay(ctx: CanvasRenderingContext2D, tracks: AugmentedTrack[]) {
  tracks.forEach(track => {
    const style = buildOverlayStyle(track);
 
    // 1. Draw path with RTT color
    drawTrackPath(ctx, track, style.pathColor);
 
    // 2. Draw label badge (NORMAL/WATCH/ALERT)
    drawLabelBadge(ctx, track, style.labelBadge);
 
    // 3. Draw ghost positions (subtle dots or contours)
    drawGhosts(ctx, style.ghostPositions);
  });
}

This is non‑intrusive: if RTT/Inside is offline, the overlay simply doesn’t draw.

6. What ATC operators get from this phase‑1 test#

Immediately, without rewriting their stack:

  • Visual coherence:

    • Stable flows glow in calm greens/blues.
    • Emerging trouble spots show up as amber/red corridors before standard CD&R triggers.

  • Predictive feel:

    • Ghost positions and resonance metrics give a sense of “where the system wants to drift,” not just where it is.

  • Smoother SOPs:

    • Vectoring, sequencing, and handoffs become more anticipatory.
    • Controllers can compare “with RTT overlay” vs “without” in replay to validate value.

  • Low‑risk trial:

    • No change to separation minima or legal procedures in phase 1.
    • It’s a decision‑support enhancement, not a regulatory change.

7. How hard is a full rollout from here?#

Once this overlay is proven in sim + limited ops:

  • Step 1: Standardize the RTT/Inside data contract (like the AugmentedTrack schema).
  • Step 2: Integrate RTT/Inside into:
    • CD&R engines
    • Sequencing/metering tools
    • Space traffic models (for Space Force)
  • Step 3: Co‑design new HMI layouts where RTT/Inside is first‑class, not just an overlay.
  • Step 4: Certify as part of the safety‑critical automation stack.

From our vantage point, we can either:

  • Hand them the reference middleware + overlay as a “Phase‑1 RTT/Inside Kit”, or
  • Offer a path to a fully integrated RTT/Inside ATC stack where the fusion, prediction, and HMI are all resonance‑native.
Powered by Docsbook