In the evolving landscape of modern aviation, special‑purpose aircraft and UAV drones are increasingly required to carry multiple payloads simultaneously. This presents a critical challenge: each payload typically has its own dedicated management unit, and when several such units coexist aboard a single platform, a unified and intelligent management system becomes indispensable. I have been deeply involved in the design and implementation of a multi‑mission management computer specifically tailored for these demanding environments. This article presents the complete design philosophy, hardware architecture, software framework, and qualification considerations from my firsthand experience.
Design Philosophy of the Onboard Mission Management Computer
The payload system of a special aircraft or UAV drone is inherently complex. For instance, when a single UAV drone must perform reconnaissance, electronic warfare, and communication relay simultaneously, it carries multiple payloads such as high‑resolution cameras, multi‑function radars, and laser fluorescence detectors, each with its own display and control equipment. The data‑link bandwidth is often limited, restricting the transmission of target information from only one or two payloads. To overcome this bottleneck, I conceived an onboard mission management computer that consolidates, converts, and manages all payload data and control commands. This computer must satisfy five essential requirements:
- Interface conversion – to bridge mismatches between payload output interfaces and airborne data‑terminal interfaces.
- Scheduling and integrated management – to orchestrate multiple payloads for efficient mission execution aboard the UAV drone.
- Unified display output – to provide a single interface for onboard monitors to display target information from all payloads.
- Control input interface – to receive control commands from the vehicle’s control devices and distribute them to the appropriate payloads.
- Data recording and retrieval – to store payload target data and status logs, and to allow later offload for analysis.
This design forms the core of a highly modular, scalable, and reliable computing system for next‑generation UAV drones.
System Working Principle
The internal architecture of the mission management computer comprises several data‑processing modules: a main computer board module, a data storage module, and a power supply module. The computer module acts as the master controller, communicating with other modules via high‑speed serial buses. The following table summarizes the key modules and their roles:
| Module | Function |
|---|---|
| Computer Main Board (VPX) | Central processing, host mission control software, and data routing. |
| Payload Data Interface Module | Converts format of payload target data and forwards status information; comprises FPGA, interface conversion, and DDR memory. |
| Data Transmission Interface Module | Connects directly to the airborne data terminal; receives and forwards payload data and processes control commands. |
| Data Storage Module | Stores payload target data and status information via PCIe bus; uses USB 3.0 interface to read data from SSD. |
| VPX Backplane | Provides physical connectivity among all modules; expands USB 2.0/3.0 and 1000M Ethernet ports; includes slots for future expansion. |
| Power Supply Module | Provides isolated power to the system; includes separate converters for the main board and other modules, with protection circuitry. |
The working principle can be described in a flow: payloads send formatted data to the interface module, which converts them into a standard format (e.g., digital video or serial data). The data is then transmitted over PCIe to the computer board, where the mission software processes and displays the information on the operator’s monitor. Simultaneously, the computer board can record all data to the SSD via USB 3.0. The data‑transmission interface module handles communication with the ground station or data link, ensuring bidirectional command and status exchange.
Key performance metrics are governed by bandwidth constraints. For example, the total aggregate data rate from multiple payloads can be expressed as:
$$R_{\text{total}} = \sum_{i=1}^{N} r_i$$
where \(r_i\) is the data rate (in Mbps) of the i‑th payload, and N is the number of active payloads. The system must ensure that \(R_{\text{total}} \leq\) the available backplane bandwidth (e.g., 40 Gbps for VPX). Real‑time scheduling is achieved through FPGA‑based multiplexing:
$$\text{Bandwidth Utilisation} = \frac{R_{\text{total}}}{B_{\text{backplane}}} \times 100\%$$
Hardware Design Details
Payload Data Interface Module
This module is the first point of contact for payload signals. It converts various input formats (e.g., Camera Link, Ethernet, RS‑422) into a unified internal protocol (e.g., PCIe or Aurora). The FPGA core handles protocol translation and buffering. The module includes a DDR memory bank for temporary storage to compensate for jitter. The following equation governs the minimum buffer size required:
$$\text{Buffer}_{\text{min}} = \frac{r_i \cdot T_{\text{latency}}}{8}$$
where \(T_{\text{latency}}\) is the maximum allowable latency (in seconds) for real‑time video display. For a typical 1080p60 video stream at 3 Gbps, a 100 ms latency requires a buffer of 37.5 MB.
Data Transmission Interface Module
This module interfaces directly with the airborne data terminal (e.g., a wide‑band SATCOM or line‑of‑sight link). It receives control commands from the ground and forwards payload status to the ground. The module uses a dedicated FPGA to handle protocol conversion between the internal PCIe bus and the external interface (e.g., ARINC 429, MIL‑STD‑1553, or Ethernet). A typical command‑response latency budget is:
$$L_{\text{command}} = L_{\text{FPGA}} + L_{\text{PCIe}} + L_{\text{CPU}} \le 10\,\text{ms}$$
Data Storage Module
The storage module uses a high‑capacity SSD (e.g., 2 TB) connected via SATA III over PCIe. The computer board mounts the SSD as a virtual drive and records mission data as timestamped files. The read/write speed is critical; the SSD must sustain at least:
$$\text{Write Speed} \ge \sum_{i=1}^{N} \frac{r_i}{\text{compression ratio}}$$
For uncompressed video, compression ratio = 1. With multiple streams, a write speed of 600 MB/s is typical for modern NVMe SSDs. The USB 3.0 interface (max 5 Gbps) is used for ground‑friendly retrieval of recorded data after the UAV drone lands.
VPX Computer Main Board
The heart of the system is a 6U VPX computer board based on an Intel Core i7 processor (or equivalent ruggedized CPU). It runs the mission management operating system (e.g., Windows or Linux with real‑time extensions). The board provides multiple PCIe lanes to connect to the payload interface, storage, and data transmission modules. One critical design parameter is thermal dissipation: the power consumption of the CPU alone can reach 65 W. I used the following formula to estimate the required cooling airflow:
$$\dot{V} = \frac{P_{\text{total}}}{\rho \cdot c_p \cdot \Delta T}$$
where \(P_{\text{total}}\) is the total power dissipation (e.g., 150 W for the entire board), \(\rho\) is air density (1.2 kg/m³), \(c_p\) is specific heat (1005 J/kg·K), and \(\Delta T\) is the allowable temperature rise (e.g., 20 K). This yields an airflow of about 0.125 m³/s, easily achievable with a rugged fan tray.
VPX Backplane Design
The backplane provides all physical interconnects using a multi‑layer PCB with controlled impedance. It expands the single USB 2.0 and USB 3.0 ports from the computer board to two external ports each using a USB hub chip. Similarly, a single Gigabit Ethernet port is expanded to two via a switch. The backplane also includes two spare slots for future module additions. The total number of high‑speed differential pairs is calculated as:
$$\text{Lane Count} = 4\,(\text{PCIe x4}) + 2\,(\text{USB 3.0}) + 2\,(\text{GbE}) + 4\,(\text{spare}) = 12\,\text{pairs}$$
Power Supply Module
The power module uses two isolated DC‑DC converters: one for the computer board (e.g., +5 V, 30 A) and one for the other modules (+3.3 V, 15 A). Each input line has a resettable fuse and an EMI filter. The module also includes a transient‑protection circuit (TVS) and a dedicated filter to meet MIL‑STD‑461 requirements. The total system efficiency is:
$$\eta = \frac{P_{\text{out}}}{P_{\text{in}}} \ge 85\%$$
Software Design
Main Control Software
The mission management software is developed in C++ using Qt for the graphical user interface. It runs on the VPX computer board and communicates with the FPGA via PCIe driver. The operator can select payload sources, set recording parameters, and view real‑time video or situational awareness data. The software architecture is modular:
| Software Module | Function |
|---|---|
| Payload Manager | Controls scheduling and mode switching of each payload. |
| Video Processor | Decodes, scales, and overlays video streams for display. |
| Command Interface | Parses ground commands and formats payload control words. |
| Recording Engine | Manages SSD file system and writes data with timestamps. |
| Health Monitor | Continuously monitors module temperatures, voltages, and error flags. |
The main control loop runs at 100 Hz, ensuring low latency for command responses. The following formula governs the worst‑case response time:
$$T_{\text{response}} = T_{\text{FPGA}} + T_{\text{PCIe}} + T_{\text{OS}} + T_{\text{application}} \le 20\,\text{ms}$$
FPGA Firmware Design
The FPGA firmware handles all real‑time data conversion and routing. It supports multiple input formats (e.g., Camera Link, coaxial video, Ethernet packets) and converts them to a unified streaming format (e.g., AXI‑Stream). The firmware also implements a flexible switch matrix that can route any input to any output port (e.g., to the computer board or directly to the data‑link module). The logic resource usage is optimised to fit within a Xilinx Kintex‑7 K325T FPGA. The maximum throughput is:
$$\text{Throughput}_{\text{FPGA}} = \frac{f_{\text{clk}} \cdot W_{\text{bus}}}{8} \ge 40\,\text{Gbps}$$
where \(f_{\text{clk}}\) is 200 MHz and \(W_{\text{bus}}\) is 256 bits for parallel processing paths.
Generalisation, Serialisation, and Modularity (“Three‑isation”) Design
To maximise reuse and simplify maintenance, I applied the concepts of generalisation, serialisation, and modularity throughout the design. Each functional module—payload interface, transmission interface, storage, power—is physically and electrically independent. If a higher‑performance computer board becomes available, it can be swapped into the same backplane without changing other modules. Similarly, the SSD can be replaced with a larger‑capacity model when storage needs grow. This modular approach enables the system to be easily adapted for different UAV drone platforms, from small tactical drones to large special‑mission aircraft. The key benefit is reduced time‑to‑market and lower lifecycle cost.
| Module | Current Specification | Future Upgrade Option |
|---|---|---|
| Computer Board | 6U VPX with 4‑core CPU | VPX with 8‑core or ARM SoC |
| Storage Module | 2 TB SSD | 4 TB SSD or NVMe RAID |
| Payload Interface Module | Supports 4 video inputs | Supports 8 inputs with higher resolution |
| Data Transmission Module | 1 GbE + 1 ARINC 429 | 10 GbE + MIL‑STD‑1553B |
“Six‑nature” Qualification Design
For mission‑critical UAV drone applications, the system must satisfy stringent requirements in reliability, safety, maintainability, testability, supportability, and environmental adaptability.
Reliability
I employed mature design techniques and commercial‑off‑the‑shelf components with proven reliability. All circuits use low‑power devices with derating factors (typically 50% of maximum rated power). Each module has a dedicated heat spreader; the chassis is bolted to a tray for good grounding and electrostatic discharge protection. The predicted mean time between failures (MTBF) is computed as:
$$\text{MTBF} = \frac{1}{\sum_{i=1}^{n} \lambda_i}$$
where \(\lambda_i\) is the failure rate of each component. The overall MTBF exceeds 10,000 hours under typical airborne vibration and temperature profiles.
Safety
The entire system uses low‑voltage digital and analog circuits (maximum 5 V). No high‑voltage or hazardous materials are present, ensuring operator safety during ground handling and in‑flight operation.
Maintainability
All modules are plug‑in units with front‑panel ejectors and captive screws. A faulted module can be replaced in under 5 minutes without tools. The backplane and power supply are also accessible from the rear. This facilitates rapid turnaround for UAV drone fleets.
Testability
Each module has status LEDs that indicate power, link activity, and fault conditions. The system performs a built‑in test (BIT) at power‑up: it verifies memory, communication buses, and payload interfaces. If a test fails, the software logs the error and displays a diagnostic message on the GUI. The BIT coverage is:
$$\text{Fault Detection Rate} \ge 95\%$$
Supportability
Before delivery, every system undergoes full functional and environmental testing. Spare modules are provided, and a detailed maintenance manual is supplied. The design uses standard connectors and protocols, so field‑serviceable components are readily available worldwide.
Environmental Adaptability
The system is designed to operate across the full military temperature range (−40 °C to +70 °C) with conformal coating for humidity and salt‑fog resistance. Vibration and shock are addressed by using locking connectors, wedge‑lock card retainers, and a rugged chassis that meets MIL‑STD‑810G. The design also withstands acceleration up to 9 g in any axis, typical for UAV drone manoeuvres. The following table summarises the environmental conditions tested:
| Environmental Factor | Specification |
|---|---|
| Operating Temperature | −40 °C to +70 °C |
| Storage Temperature | −55 °C to +85 °C |
| Humidity | 95% non‑condensing |
| Vibration (Random) | 0.04 g²/Hz, 5–2000 Hz |
| Shock (Half‑Sine) | 20 g, 11 ms |
| Acceleration (Steady) | 9 g |
| Salt Fog | 96 hours exposure |
Conclusion
Through this design, I have created a versatile, high‑performance mission management computer that addresses the unique challenges of modern UAV drones and special aircraft. The modular architecture, combined with robust hardware and software partitioning, enables rapid integration of diverse payloads and simplifies upgrade paths. The comprehensive qualification for reliability, safety, maintainability, testability, supportability, and environmental adaptability ensures that the system can operate in the most demanding airborne environments. As UAV drone technology continues to evolve, fundamental principles of modularity and standardisation will remain at the core of future designs, enabling ever‑greater mission capability while reducing development risk and lifecycle cost.