Detect and Avoid (DAA) System - Product Requirements Document

Andi Lamprecht ·2026-05-11· 19 min read· Draft

1. Purpose

This document defines the product requirements for DroneUp’s Detect and Avoid (DAA) system. The DAA system enables safe Beyond Visual Line of Sight (BVLOS) drone operations by detecting nearby manned aircraft, alerting operators, and commanding avoidance maneuvers when necessary.

The system operates as a dual-authority architecture: the cloud handles operator alerting, visualization, logging, and clearance decisions, while the onboard system independently detects conflicts and is the authority for executing avoidance maneuvers.

2. Background

DroneUp operates drone delivery and inspection missions across hundreds of operational sites nationwide. Current operations are limited to Visual Line of Sight (VLOS) or operations with visual observers (VOs). Scaling these operations requires BVLOS capability, which in turn requires an FAA-accepted DAA system.

The DAA system must:

• Ingest air traffic data from both ground-based and airborne ADS-B receivers, as well as non-cooperative surveillance sensors.
• Compute conflict volumes (OCDV, OCAV, Well Clear, NMAC) in real time for every active drone flight.
• Present air traffic and alert information to operators so they can maintain situational awareness.
• Autonomously trigger avoidance maneuvers (the “Crouch”) when intruders penetrate the OCAV boundary.
• Log all encounters for FAA compliance reporting.

3. Scope

The DAA system is delivered in six sequential phases, each building on the capabilities of the previous:

Phases 5 and 6 are independent of each other. Both depend on Phase 2.

Phase Dependency Graph

    graph LR
    P1["Phase 1\nDetect & Notify"]
    P2["Phase 2\nAutomated Avoid"]
    P3["Phase 3\nOnboard ADS-B"]
    P4["Phase 4\nDual-Authority DAA"]
    P5["Phase 5\nTerrain & Traffic\nCrouch Targeting"]
    P6["Phase 6\nUAS Performance\nCalibration"]

    P1 --> P2
    P1 --> P3
    P2 --> P4
    P3 --> P4
    P2 --> P5
    P1 -.->|historical data| P5
    P2 --> P6

    style P1 fill:#4A90D9,color:#fff
    style P2 fill:#E07030,color:#fff
    style P3 fill:#4A90D9,color:#fff
    style P4 fill:#B83032,color:#fff
    style P5 fill:#6B8E23,color:#fff
    style P6 fill:#6B8E23,color:#fff
  

4. Key Concepts

OCDV (Ownship Centric Detection Volume): The outermost detection cylinder. Entry triggers situational awareness alerting and begins intrusion tracking.

OCAV (Ownship Centric Alert Volume): The warning-level cylinder. Entry triggers the avoidance decision logic (Crouch maneuver).

Well Clear: A separation standard (610m horizontal, 76.2m vertical). Loss of Well Clear is an escalation beyond OCAV.

NMAC (Near Mid-Air Collision): The innermost volume (152.4m horizontal, 30.48m vertical). The most severe classification.

Crouch Maneuver: The standard avoidance response: pause horizontal flight, descend at a controlled rate, and hold until cleared.

Clear to Proceed / Clear to Resume: Two-stage clearance. “Clear to Proceed” means an individual intruder is diverging and outside Well Clear. “Clear to Resume” means all intruder pairs are resolved and the operator has confirmed.

Detection Volumes (Ownship-Centric)

Volume Hierarchy and Avoidance Flow

    stateDiagram-v2
    direction LR

    state "All Clear" as AC
    state "OCDV Intrusion\n(7,250 m horiz / 228.6 m vert)" as OCDV
    state "OCAV Intrusion\n(dynamic radius / 76.2 m vert)" as OCAV
    state "Loss of Well Clear\n(610 m horiz / 76.2 m vert)" as WC
    state "NMAC\n(152.4 m horiz / 30.48 m vert)" as NMAC
    state "Clear to Proceed" as CTP

    state "Avoidance Response" as AR {
        direction TB
        state "Crouch: Pause + Descend" as CROUCH
        state "Hold at Safe Altitude" as HOLD
        CROUCH --> HOLD : Reached safe alt\nor landed
    }

    [*] --> AC
    AC --> OCDV : Intruder enters OCDV
    OCDV --> AC : Intruder exits OCDV

    OCDV --> OCAV : Intruder enters OCAV
    OCAV --> AR : Trigger avoidance
    OCAV --> WC : Separation < 610 m
    WC --> AR : Immediate Crouch
    WC --> NMAC : Separation < 152.4 m
    NMAC --> AR : Continue descent

    AR --> CTP : Intruder diverging\n& outside Well Clear
    CTP --> OCDV : Intruder still in OCDV
    CTP --> AC : Intruder exits OCDV\n+ operator confirms\n(Clear to Resume)
  

DAA Geometric Constants

DAA Timing Parameters (Baseline)

Note on Twcl: For OCDV computation, 37s is constant. For OCAV computation, Twcl is computed in real time based on ownship altitude and descent rate. Timing values vary for non-ADS-B-based DAA (see DAA Timeline Selection).

Phase 1: Detect & Notify

Cloud-based conflict detection and operator situational awareness. No avoidance automation.

Outcome: Operators see real-time air traffic on the GCS map, receive audio/visual alerts on intrusions, and all encounters are logged for compliance. The system computes OCDV/OCAV/Well Clear/NMAC states but does not command any drone behavior.

System Architecture (Phase 1)

    graph TB
    subgraph "Ground Infrastructure"
        ADSB_RX["Ground ADS-B\nReceivers"]
        NON_COOP["Non-Cooperative\nSensors"]
    end

    subgraph "Cloud Services"
        INGEST["Data Ingestion\n& Deduplication"]
        GEO["Geo Filter\n(16 km radius)"]
        CDS["Conflict Detection\nService (Go)"]
        LOG["Encounter\nLogging"]
        REPORT["Compliance\nReporting"]
    end

    subgraph "GCS Frontend (React/Apollo)"
        MAP["Traffic Map\n& Volume Viz"]
        ALERTS["Alert Panel\n& Audio"]
        OPS["Operator\nControls"]
    end

    subgraph "Drone"
        TELEM["Telemetry\n(1-2 Hz)"]
    end

    ADSB_RX -->|"1-2 Hz / aircraft"| INGEST
    NON_COOP -->|"up to 5 Hz"| INGEST
    TELEM -->|"1-2 Hz"| INGEST
    INGEST --> GEO --> CDS
    CDS -->|"state transitions"| MAP
    CDS -->|"alert events"| ALERTS
    CDS -->|"1 Hz per intruder"| LOG
    LOG --> REPORT
    OPS -->|"site config"| GEO

    style CDS fill:#4A90D9,color:#fff
    style MAP fill:#2563EB,color:#fff
    style ALERTS fill:#B83032,color:#fff
  

Feature Areas

1.1 Conflict Detection Algorithm

Computes OCDV, OCAV, Well Clear, and NMAC states for every drone-intruder pair using geometric volume definitions and configurable timing constants. Classifies each pair into one of six states (All Clear, OCDV Intrusion, OCAV Intrusion, Loss of Well Clear, NMAC, Clear to Proceed) and emits transition events on boundary crossings.

Key behaviors: dynamic OCAV radius computation based on intruder speed and timeline parameters; worst-case assumptions for unknown altitude (co-altitude) and unknown airspeed (77.17 m/s); warning alerts use only current surveillance data (no predictions); Clear to Proceed requires diverging separation over 4 consecutive measurements.

Capacity: minimum 50 simultaneous drone flights (design capacity 100). Stale flights cleaned up within 60 minutes of scheduled end.

Jama: UERQ-FLD-546 | SLRs: UERQ-SYS-2187, 2188, 2191, 2332, 2280, 2281, 2201, 2282, 2283, 2192, 2193, 2195, 2196, 2202, 2203, 2286, 2322, 2197, 2198

1.2 Data Pipeline

Ingests ADS-B plots (1-2 Hz), drone telemetry (1-2 Hz), and non-cooperative surveillance (up to 5 Hz). Deduplicates by aircraft ID, keeping only the most recent position. Removes stale plots and telemetry after 5 seconds of silence. Identifies aircraft type from ADS-B emitter category where available.

Jama: UERQ-FLD-547 | SLRs: UERQ-SYS-2205, 2206, 2290, 2207, 2208, 2209, 2210

1.3 Geo Filtering

Processes only ADS-B plots within 16,093 m of an active operational site. Sites loaded from persistent store with hot-reload (no restart). Supports 1,000+ sites across all regions.

Jama: UERQ-FLD-548 | SLRs: UERQ-SYS-2293, 2212, 2213

1.4 Visualization – Air Traffic

Real-time aircraft display on the GCS map with heading-oriented icons, altitude labels, intrusion-status color coding (blue/grey → yellow → red), and stale-data indicators. Operators can toggle tail number labels, click aircraft for detail panels, and view only traffic within OCDV radius of their active missions.

Jama: UERQ-FLD-554 | SLRs: UERQ-SYS-2214, 2215, 2216, 2217, 2218, 2219, 2220, 2294, 2295, 2296

1.5 Visualization – Alert Volumes

OCAV rendered as a red semi-transparent circle on active OCDV intrusion (largest radius when multiple intrusions). OCDV rendered as optional yellow circle. Circles track drone position in real time and disappear when the intruder exits the OCDV.

Jama: UERQ-FLD-555 | SLRs: UERQ-SYS-2223, 2326, 2224, 2225, 2226, 2227

1.6 Alerting

Escalating audio alerts on volume boundary crossings (attention → warning → urgent → critical) with severity-priority queuing. Visual alert list shows bearing, velocity, range, vertical separation, and trend indicators. Alerts sorted by severity then time-to-CPA. Map navigation on alert click. Suppressed on page load for pre-existing states. Operator must confirm audio test before each takeoff.

Jama: UERQ-FLD-550 | SLRs: UERQ-SYS-2228, 2229, 2338, 2339, 2230, 2231, 2232, 2233, 2297, 2235, 2236, 2340, 2237, 2238, 2239

1.7 Reporting

Logs every OCDV intrusion at 1 Hz minimum with full intruder and ownship fields, dual timestamps (system + source), and boundary state tagging. OCAV+ encounters retained permanently; OCDV-only encounters retained 30 days minimum. Compliance reports exportable by time range and authority. Access restricted to supervisor/admin roles.

Jama: UERQ-FLD-551 | SLRs: UERQ-SYS-2317, 2318, 2319, 2320, 2321, 2300, 2301, 2242, 2243, 2244, 2245

1.8 Performance

Jama: UERQ-FLD-552 | SLRs: UERQ-SYS-2246, 2302, 2303, 2247, 2304

1.9 Operations

Auto-reconnect on stream loss with operator-visible status. DAA constants updatable via configuration (no deploy). BVLOS missions gated on DAA availability. DAA service outage triggers operator alert (automated Crouch command added in Phase 2). 99.9% uptime SLA.

Jama: UERQ-FLD-553 | SLRs: UERQ-SYS-2252, 2253, 2254, 2305, 2306, 2307, 2309

Phase 2: Detect & Automated Avoid (Crouch)

Cloud detects conflicts and commands the drone to execute the Crouch avoidance maneuver. Drone executes but does not independently detect.

Outcome: When the cloud detects an OCAV intrusion, it commands the drone to Crouch. The drone pauses, descends, and holds. Operators confirm Clear to Resume. Safety edge cases (battery, telemetry loss, C2 loss with VOs) are handled.

Authority model (Phase 2): Cloud is sole detection authority. Cloud commands Crouch via C2. Drone executes. If C2 is lost, drone follows lost-link procedure (no onboard detection available yet).

Crouch Maneuver Sequence

    sequenceDiagram
    participant I as Intruder Aircraft
    participant CDS as Cloud Detection Service
    participant GCS as GCS Operator
    participant D as Drone

    I->>CDS: Enters OCAV
    CDS->>GCS: OCAV alert (audio + visual)
    CDS->>D: Crouch command

    Note over D: Pause horizontal flight
    Note over D: Descend at 1.219 m/s

    D->>CDS: Crouch confirmation (<1s)
    CDS->>GCS: Avoidance in progress

    Note over D: Hold at safe altitude

    I->>CDS: Diverging, exits Well Clear
    CDS->>GCS: Clear to Proceed
    GCS->>CDS: Operator confirms resume
    CDS->>D: Clear to Resume
    Note over D: Resume mission
  

Feature Areas

2.1 Crouch Maneuver

The avoidance maneuver: (a) immediate pause of horizontal flight, (b) controlled descent at descent_rate to safe hold altitude or landing, (c) hold until operator clears. Initiation within 500 ms of decision. Confirmation back to cloud within 1 second. If no confirmation received within 3 seconds, backend escalates (TBD: escalation behavior).

Jama: UERQ-FLD-557 | SLRs: UERQ-SYS-2260, 2267, 2268, 2269, 2334

2.2 Cloud-Commanded Avoidance

Two decision paths in Phase 2 (cloud as sole authority):

• Notify-Then-Act: Time to Loss of Well Clear exceeds 15s threshold → cloud commands, drone waits for command or threshold expiry before executing.
• Act-and-Notify: Time to Loss of Well Clear at or below threshold → cloud commands immediate Crouch.
• Loss of Well Clear / NMAC: Immediate Crouch regardless of threshold.

SLRs: UERQ-SYS-2261, 2262, 2264, 2265, 2266

2.3 Mission Recovery

Clear to Resume requires (a) Clear to Proceed for every intruder pair, and (b) explicit operator confirmation. New intrusions during active Crouch are logged separately without restarting the maneuver. OCAV intrusion during lost-link RTH interrupts RTH for avoidance, then resumes RTH from current position.

Jama: UERQ-FLD-558 | SLRs: UERQ-SYS-2270, 2272, 2273

2.4 Safety – Cloud-Commanded Avoidance

Covers: telemetry staleness during active avoidance (blocks Clear to Proceed), cloud traffic provider failure (Crouch all BVLOS drones), C2 loss with VOs (continue detection on last known telemetry, notify VO system), dual failsafe Crouch + low battery (land at nearest safe point when intruder clears), prioritized multi-drone alerting (active > supervised > monitored, grouped when >10).

Jama: UERQ-FLD-561 | SLRs: UERQ-SYS-2292, 2328, 2329, 2335, 2337

Phase 3: Onboard ADS-B Sensor Integration

The drone relays ADS-B contacts detected by its onboard receiver to the cloud. No onboard detection logic yet – the drone is a sensor, not a decision-maker.

Outcome: Ground-based ADS-B coverage gaps are filled by airborne ADS-B. The cloud fuses both sources into a single consolidated traffic picture. Operators see source attribution (ground/airborne/fused).

ADS-B Source Fusion Architecture

    graph TB
    subgraph "Ground"
        GRX["Ground ADS-B\nReceivers"]
    end

    subgraph "Airborne"
        ARX["Onboard ADS-B\nReceiver"]
        MAV["MAVLink ADSB\nMessages"]
        OBC["Onboard Client\n(parse + validate + buffer)"]
    end

    subgraph "Cloud"
        INGEST["Ingestion Service"]
        FUSION["Source Fusion\n(dedup by ICAO)"]
        CDS2["Conflict Detection\nService"]
    end

    ARX --> MAV --> OBC
    OBC -->|"1 Hz / contact\n(buffered if C2 lost)"| INGEST
    GRX -->|"1-2 Hz"| INGEST
    INGEST --> FUSION
    FUSION -->|"GROUND_ONLY\nAIRBORNE_ONLY\nFUSED"| CDS2

    style FUSION fill:#4A90D9,color:#fff
    style OBC fill:#E07030,color:#fff
  

Feature Areas

3.1 Onboard ADS-B Relay

Configures ADS-B receiver parameters from cloud vehicle config at boot. Parses MAVLink ADSB messages (valid position flags only). Validates: lat/lon range, speed 0-340 m/s, altitude -1,000 to 60,000 ft, valid 24-bit ICAO, timestamp not >5s future. Transmits to cloud at configurable rate (default 1 Hz/contact) with batching. Buffers in circular buffer (60s minimum) when C2 is lost; replays chronologically on reconnect.

Jama: UERQ-FLD-560 (SLRs drafted) | SLRs: UERQ-SYS-2311, 2312, 2313, 2314, 2333

3.2 Cloud ADS-B Source Fusion

Fuses airborne and ground-based ADS-B reports by ICAO address, keeping the most recent timestamp when both sources report the same aircraft. Tags each plot: GROUND_ONLY, AIRBORNE_ONLY, or FUSED.

Jama: UERQ-FLD-560 (SLRs drafted) | SLRs: UERQ-SYS-2315, 2316

Phase 4: Onboard + Cloud DAA Orchestration

The drone runs independent conflict detection and becomes the authority for avoidance maneuvers. Cloud remains authority for operator alerting, visualization, logging, and clearance.

Outcome: Full dual-authority architecture. The drone can detect and avoid autonomously (including when C2 is lost). Cloud and onboard run in parallel with disagreement detection and logging.

Dual-Authority Model

    graph TB
    subgraph "Onboard (Authority: Avoidance)"
        OD["Onboard Detection\n(1 Hz cycle, <200ms latency)"]
        DEC["Decision Logic\n(Notify-Then-Act / Act-and-Notify / Autonomous)"]
        CROUCH["Crouch Execution"]
        BUF["Encounter Buffer\n(30 min @ 10 intruders)"]
    end

    subgraph "Cloud (Authority: Alerting, Logging, Clearance)"
        CD["Cloud Detection"]
        VIZ["Visualization & Alerts"]
        LOGGING["Encounter Logging"]
        CTP["Clear to Proceed /\nClear to Resume"]
    end

    OD -->|"state classification"| DEC
    DEC -->|"OCAV+"| CROUCH
    OD -->|"1 Hz state reports"| CD
    CD --> VIZ
    CD --> LOGGING
    CD --> CTP

    OD -.->|"C2 lost"| BUF
    BUF -.->|"C2 restored"| CD

    CD ---|"disagreement\n>2s = logged"| OD

    style OD fill:#B83032,color:#fff
    style CD fill:#4A90D9,color:#fff
    style DEC fill:#E07030,color:#fff
  

Feature Areas

4.1 Onboard Conflict Detection

Independent intrusion state classification using same geometric volumes and constants as cloud. Detection cycle at minimum 1 Hz. Constants loaded from cloud at pre-flight initialization (fixed for flight duration). State transition latency < 200 ms. Algorithm consistency verified against shared reference test vectors.

Jama: UERQ-FLD-556 (SLRs drafted) | SLRs: UERQ-SYS-2255, 2256, 2257, 2258, 2259

4.2 Avoidance Decision Paths (Full Dual-Authority)

Upgrades Phase 2 decision paths – onboard is now the detection and avoidance authority:

• Notify-Then-Act: Onboard detects OCAV, time to LoWC > threshold → transmit to cloud, wait for ack or threshold expiry, then Crouch.
• Act-and-Notify: Onboard detects OCAV, time to LoWC <= threshold → Crouch immediately, notify cloud concurrently.
• Autonomous (C2 Lost): Onboard detects OCAV with no C2 → Crouch immediately, buffer encounter log, replay on C2 restore.
• Autonomous Recovery: C2 lost + all intruders clear OCDV for 60s → execute lost-link procedure.

SLRs: UERQ-SYS-2261, 2262, 2263, 2271

4.3 Drone-Cloud Coordination

Cloud and onboard operate in parallel. Onboard transmits state at 1 Hz per active intrusion. Disagreements logged when classifications differ for > 2 consecutive seconds. Encounter events buffered onboard when C2 unavailable (30 min capacity at 1 Hz for up to 10 intruders), replayed chronologically on restore.

Jama: UERQ-FLD-559 (SLRs drafted) | SLRs: UERQ-SYS-2274, 2275, 2276, 2278, 2279

4.4 Safety – Dual-Authority Edge Cases

Open requirements that become meaningful with onboard detection:

Jama: UERQ-FLD-561

Phase 5: Terrain & Traffic-Aware Crouch Targeting

Crouch target altitude adapts to local terrain and historical air traffic patterns, replacing the fixed “descend until safe altitude” behavior.

Outcome: Each operational site has a computed optimal crouch altitude that (a) avoids terrain, (b) maximizes vertical separation from the altitudes where manned aircraft historically operate in that area.

Crouch Altitude Determination

    graph TB
    subgraph "Inputs"
        TERRAIN["Terrain Elevation\nData (30m / 3m)"]
        HIST["Historical ADS-B\nAltitude Profiles\n(30-day rolling)"]
        MARGIN["Terrain Clearance\nMargin (default 15m)"]
    end

    subgraph "Computation"
        FLOOR["Terrain Floor\n= elevation + margin"]
        BAND["Traffic Band\n= altitude where >=90%\nof manned traffic operates"]
        OPT["Optimal Crouch Alt\n= max separation from\ntraffic band, above floor"]
    end

    subgraph "Delivery"
        CONFIG["Per-Site Config\n(recomputed weekly)"]
        PREFLIGHT["Pre-Flight\nInitialization"]
        GCS3["GCS Display\n(target altitude)"]
    end

    TERRAIN --> FLOOR
    MARGIN --> FLOOR
    HIST --> BAND
    FLOOR --> OPT
    BAND --> OPT
    OPT --> CONFIG --> PREFLIGHT
    CONFIG --> GCS3

    style OPT fill:#6B8E23,color:#fff
    style BAND fill:#E3C039,color:#000
  

Feature Areas

5.1 Terrain-Aware Crouch Floor

Terrain elevation data maintained for all active sites (30m horizontal / 3m vertical resolution). Crouch target never descends below terrain + configurable clearance margin (default 15m / 50ft). Terrain data refreshed every 90 days; conservative default used when unavailable or expired.

SLRs (TBD): UERQ-SYS-TBD-501, TBD-502, TBD-503

5.2 Historical Air Traffic Pattern Analysis

Aggregates Phase 1 ADS-B data into per-site altitude density profiles (OCDV radius). Profiles recomputed weekly on a 30-day rolling window. Computes optimal crouch altitude to maximize vertical separation from the altitude band where >= 90% of manned traffic operates. Delivered to drone at pre-flight initialization (fixed for flight). Displayed in GCS alongside current altitude during Crouch.

SLRs (TBD): UERQ-SYS-TBD-504, TBD-505, TBD-506, TBD-507, TBD-508

5.3 Safety Constraints

Operator can override computed crouch altitude per-mission before takeoff (logged with reason). Sites with < 7 days of historical data fall back to terrain floor + margin and are flagged as “insufficient traffic data.”

SLRs (TBD): UERQ-SYS-TBD-509, TBD-510

Phase 6: UAS Performance Calibration & Latency Chain Tuning

DAA timing parameters are derived from measured UAS performance data rather than conservative baselines. Automated flight testing quantifies actual sink rate, velocity, deceleration, and latency chain per UA model.

Outcome: Each UA model has a validated performance profile that feeds into the OCAV radius computation. Tighter (less conservative) volumes for high-performing aircraft reduce unnecessary Crouch triggers without compromising safety.

Calibration Pipeline

    graph LR
    subgraph "Flight Test"
        FT["Automated\nTest Flights"]
        ENV["Envelope Conditions\n(temp, payload, battery)"]
    end

    subgraph "Profile Store"
        PERF["Performance Profile\nper UA model + FW version\n(valid 180 days)"]
        LAT["Latency Profile\nper C2 link type\n(P95 values)"]
    end

    subgraph "DAA Engine"
        OCAV["OCAV Radius\nComputation"]
        BASE["Baseline Params\n(fallback)"]
        SAFE["Safety Margin\n(10s, not reducible)"]
    end

    FT --> PERF
    ENV --> FT
    FT --> LAT
    PERF -->|"descent_rate\nTtransition\nTdecel"| OCAV
    LAT -->|"Tsl (gcs_latency)"| OCAV
    BASE -.->|"no valid profile"| OCAV
    SAFE --> OCAV

    style OCAV fill:#6B8E23,color:#fff
    style PERF fill:#4A90D9,color:#fff
    style LAT fill:#4A90D9,color:#fff
  

Feature Areas

6.1 UA Performance Profiling

Automated flight test sequences measuring: max sustained descent rate, max horizontal deceleration (cruise → hover), command-to-maneuver latency (Ttransition), and maneuver-to-stable-hover time. Profiles stored per UA model + firmware version with measurement conditions (temperature, altitude, payload weight). Valid for 180 days or until firmware update. Tests run across envelope conditions (min/max temp, min/max payload, min battery SOC); worst-case used.

SLRs (TBD): UERQ-SYS-TBD-601, TBD-602, TBD-603, TBD-604

6.2 Latency Chain Measurement

Automated end-to-end latency measurement: ADS-B broadcast → ground receiver → cloud ingestion → conflict detection → command transmission → C2 delivery → onboard execution. Each segment measured independently. Stored per C2 link type (LTE, dedicated radio); gcs_latency set to P95 measured value. Continuous production monitoring with flag when measured latency exceeds profile by > 50%.

SLRs (TBD): UERQ-SYS-TBD-605, TBD-606, TBD-607

6.3 Calibrated OCAV Computation

When a valid performance profile exists, uses profiled values for descent_rate, time_to_initiate_maneuver, deceleration_buffer, and gcs_latency in OCAV radius computation. Falls back to baseline parameters when no valid profile exists (with warning log). Safety margin (Tmargin = 10s) is never reduced regardless of profile results – reserved for regulatory margin.

SLRs (TBD): UERQ-SYS-TBD-608, TBD-609, TBD-610

Authority Model Progression

The authority model evolves across phases:

Open Items and TBDs

Estimation Input

prd_sizing_input:
  feature: "DAA System"
  scope_clarity: "A"
  phases:
    - name: "Phase 1 - Detect & Notify"
      scope_clarity: "A"
      key_terms:
        - "conflict detection"
        - "OCDV"
        - "OCAV"
        - "ADS-B ingestion"
        - "air traffic visualization"
        - "intrusion alerting"
      risk_flags:
        - "real-time-processing"
        - "aviation-regulatory"
      domains:
        - "backend-go"
        - "frontend-react"
      regulatory: true
      discovery_needed: false

    - name: "Phase 2 - Detect & Automated Avoid"
      scope_clarity: "A"
      key_terms:
        - "crouch maneuver"
        - "avoidance command"
        - "mission recovery"
        - "clear to resume"
      risk_flags:
        - "safety-critical"
        - "onboard-firmware"
        - "aviation-regulatory"
      domains:
        - "backend-go"
        - "firmware-cpp"
        - "frontend-react"
      regulatory: true
      discovery_needed: false

    - name: "Phase 3 - Onboard ADS-B Integration"
      scope_clarity: "A"
      key_terms:
        - "ADS-B relay"
        - "MAVLink ADSB"
        - "source fusion"
        - "airborne ADS-B"
      risk_flags:
        - "onboard-firmware"
        - "hardware-dependency"
      domains:
        - "firmware-cpp"
        - "backend-go"
      regulatory: true
      discovery_needed: false

    - name: "Phase 4 - Onboard + Cloud Orchestration"
      scope_clarity: "A"
      key_terms:
        - "onboard detection"
        - "dual authority"
        - "disagreement logging"
        - "parallel detection"
      risk_flags:
        - "safety-critical"
        - "onboard-firmware"
        - "distributed-system-coordination"
      domains:
        - "firmware-cpp"
        - "backend-go"
        - "frontend-react"
      regulatory: true
      discovery_needed: false

    - name: "Phase 5 - Terrain & Traffic-Aware Crouch"
      scope_clarity: "B"
      key_terms:
        - "terrain elevation"
        - "traffic altitude profile"
        - "crouch altitude"
        - "historical ADS-B"
      risk_flags:
        - "new-data-pipeline"
        - "aviation-regulatory"
        - "terrain-data-dependency"
      domains:
        - "backend-go"
        - "data-pipeline"
        - "frontend-react"
      regulatory: true
      discovery_needed: true

    - name: "Phase 6 - UAS Performance Calibration"
      scope_clarity: "B"
      key_terms:
        - "flight test"
        - "descent rate"
        - "latency chain"
        - "performance profile"
        - "OCAV tuning"
      risk_flags:
        - "flight-test-infrastructure"
        - "safety-critical"
        - "per-UA-model-variation"
      domains:
        - "backend-go"
        - "firmware-cpp"
        - "test-infrastructure"
      regulatory: true
      discovery_needed: true

  affected_repos:
    - "TBD - pending gh search code discovery"
  regulatory: true