# Flight Control & Software Assurance Report — MRT-X

**Document:** RPT-MRTX-SW-001 | **Type:** Vendor substantiation
**Revision:** v1.0 | **Date:** 3 June 2026
**Prepared by:** Aerix Defense Systems (fictional) — S. Okafor, Flight Controls & Autonomy Lead
**Verifies against:** SRD-MRTX-001 §2.5, §6; MIL-HDBK-516C software airworthiness

---

> **FICTIONAL — METHODOLOGY TEST INPUT.** Not a real software assurance report. Contains the primary planted software conflict.

## 1. Flight Control Architecture

The flight control system is built on a Pixhawk-class flight controller running the PX4 open-source autopilot firmware. A companion compute module hosts autonomy functions (swarm coordination, VIO navigation, detect-and-avoid). The flight controller provides attitude and position control, failsafe handling, and lost-link logic.

## 2. Software Maturity Claim

The PX4 baseline has accumulated extensive operational flight hours across a global user community and many commercial and defense integrations. On this basis the flight control software is assessed at **TRL 8** — flight-proven, mature, ready for production and fielding — satisfying SRD-2.5.

## 3. Software Assurance Approach

Configuration of the autopilot is version-pinned to a specific PX4 release. Vendor-developed modules (swarm, payload interface) follow the vendor's internal software process. Changes are tracked in a version-control system. Flight testing validates end-to-end behavior.

## 4. Autonomy Safeguards

Autonomy functions operate human-on-the-loop: the operator can override or abort. Geofencing and flight-termination are independent of the autonomy stack. Lost-link triggers return-to-home; if unrecoverable, flight termination.

## 5. Verification

End-to-end flight test (see flight test report) demonstrates nominal and failsafe behavior. Software behavior is validated by demonstration.

## 6. Compliance Summary

The flight control software is assessed mature and suitable for the proposed flight clearance.

## 7. Revision History

- **v1.0 (3 June 2026):** Initial report. Flight control architecture, maturity claim, and assurance approach.

---

### [INTERNAL — NOT PART OF REPORT] Planted gaps in this document — PRIMARY CONFLICT

- **PG-SW-1 (CROWN JEWEL):** The report claims **TRL 8 (SRD-2.5)** for the flight control software on the basis of community flight hours, while SRD-6.7 requires **traceable software requirements, design-assurance evidence, and configuration management appropriate to flight-critical software** (DO-178C-equivalent). Community flight hours are NOT design-assurance evidence. There is **no software requirements baseline, no traceability to code, no structural coverage analysis, no DAL assignment**. The two requirements collide: a production-maturity claim cannot be supported by the evidence type offered, and the design-assurance evidence SRD-6.7 demands is absent. (Category: CONTRA between SRD-2.5 and SRD-6.7 + GAP: criterion exists, evidence absent.)
- **PG-SW-2:** §3 "vendor's internal software process" for the swarm/autonomy modules is **named but not described** — no process standard, no DAL, no review/test evidence for flight-critical autonomy functions. (Category: unsubstantiated.)
- **PG-SW-3:** §4 claims geofencing and flight termination are "independent of the autonomy stack" but provides **no architectural evidence of independence/partitioning** (no isolation analysis). Independence is an airworthiness-load-bearing claim for flight-termination. (Category: unsubstantiated independence claim.)
- **PG-SW-4:** "Validated by demonstration" (§5) is the verification method for flight-critical software behavior, where MIL-HDBK-516C software airworthiness expects analysis + structural coverage, not demonstration alone. (Category: AMBIG — wrong verification rigor.)