The development and validation of coordinated flight strategies for multi-drone systems, or drone formations, present significant challenges in real-world testing due to high costs, safety risks, and logistical complexity. High-fidelity simulation has thus become an indispensable tool. In our research, we designed and implemented a distributed simulation framework specifically for multi-drone formation flying. The core objective was to create a reusable, interoperable, and scalable platform that enables the testing of formation algorithms, collision avoidance protocols, and mission coordination in a virtual environment before physical deployment.
To achieve robust distributed interaction, we adopted the High-Level Architecture (HLA) as the overarching technical framework. HLA provides a standardized approach for coupling disparate simulation entities, known as federates, into a unified simulation execution, called a federation. The communication backbone of any HLA-based system is the Run-Time Infrastructure (RTI), which manages all data exchange, synchronization, and lifecycle services among federates. Our framework leverages RTI to decouple the individual drone simulation models, the visualization system, and the command/control interface, allowing each component to be developed and updated independently. This design is paramount for simulating complex drone formation behaviors where each drone is an autonomous entity that must react to both environmental factors and the states of its neighbors in real-time.
The evolution of distributed simulation technology, from early networks like SIMNET to the current HLA standard, has progressively focused on interoperability and reuse. Our framework builds upon this heritage, utilizing HLA/RTI to specifically address the dual needs of the drone formation simulation domain: managing the complexity of multiple interacting agents and dramatically reducing the cost and risk associated with physical flight tests.
Architectural Design of the HLA-Based Simulation Framework
The design of our multi-drone formation flight simulation system follows the structured Federation Development and Execution Process (FEDEP) model. This process ensures a systematic approach from conceptualization to execution. The system’s primary physical components include dedicated simulation computers for running federate logic and a high-performance computer for 3D visual rendering. The logical architecture is a federation consisting of several key federates interacting via the RTI.
The system’s functional architecture can be decomposed into three primary layers: the Simulation Layer (federates), the Communication Layer (RTI), and the Support Layer (databases, models). The core federates in our drone formation simulation are:
- Drone Federate(s): Multiple instances exist, each simulating the dynamics, sensors, and control algorithms of a single UAV within the formation. A drone federate publishes its state (position, velocity, attitude) and subscribes to commands and the states of other drones to enable coordinated behavior.
- Manager/Script Federate: This federate acts as the mission commander. It is responsible for initializing the drone formation, defining the flight path or waypoints for the entire group or individual units, and sending high-level commands (e.g., change formation shape, execute maneuver).
- Data Collector/Monitor Federate: This component subscribes to all relevant data published by the drone federates. It performs real-time monitoring (e.g., checking for minimum safe separation distances) and logs all simulation data to a persistent database (Microsoft SQL Server) for post-mission analysis, performance evaluation, and regression testing.
- Visualization Federate: A dedicated federate or a linked application receives state data via the RTI or a direct UDP link from the Data Collector. Using the Multigen Creator and Vega Prime toolchain, this module renders a real-time, 3D visual scene of the entire drone formation operating in a geo-typical or geo-specific virtual environment.
The interaction between these federates is governed by the Federation Object Model (FOM), a critical HLA artifact that defines the “contract” for data exchange. Our FOM defines object classes (like `Drone`) with attributes (position, speed) and interaction classes (like `FormationCommand`) with parameters (new formation type, target waypoint). The publication and subscription relationships for a drone entity are summarized in the table below:
| Object/Interaction Class | Federate Action | Attributes/Parameters |
|---|---|---|
| Drone (Object Class) | Publishes & Updates | ID, Position (Lat, Lon, Alt), Attitude (Pitch, Roll, Yaw), Velocity, Speed |
| FormationCommand (Interaction) | Subscribes & Reflects | CommandType, TargetWaypoint, FormationParameters |
| ProximityWarning (Interaction) | Subscribes & Reflects | WarningLevel, IntruderID, Bearing, Distance |
A snippet of the Federation Execution Details (FED) file, which codifies the FOM for the RTI, is shown below. This XML-like structure defines the `Plane` interaction class used to share state updates reliably.
(class Plane best_effort receive (parameter time) (parameter status_longitude) (parameter status_latitude) (parameter altitude) (parameter status_pitchingAngle) (parameter status_rollAngle) (parameter status_speed) )
Implementation of Federates and the RTI Layer
The implementation of each federate follows a common lifecycle pattern dictated by the HLA interface specification. We used RTI 1.3-NG as our specific RTI implementation and developed federates in C++ using Microsoft Visual Studio. The RTI 1.3-NG software itself consists of several key processes: the global `RtiExec` process that manages federation executions, the `FedExec` process that manages a specific federation, and the `libRTI` library linked into each federate to provide the HLA service APIs.
Every drone federate follows a standard operational workflow. First, it joins the federation execution via the RTI. Then, it declares its intent to publish and subscribe to specific object classes and interaction classes as defined in the FOM and the federate’s own Simulation Object Model (SOM). After this initialization, the federate enters the main simulation loop. In this loop, it performs the following tasks cyclically:
- Advance Time: Requests a time advance from the RTI to synchronize with other federates in the simulation.
- Compute Dynamics: Calculates its next state based on its internal dynamics model, current control inputs, and the reflected state of other drones in the formation.
- Send/Receive Updates: Sends attribute updates for its own drone object and any relevant interactions (e.g., firing a virtual sensor). Concurrently, it processes incoming updates from other federates via RTI callbacks.
- Check for Commands: Processes any incoming interaction from the Manager federate, such as a command to switch from a “V” formation to a “line abreast” formation.
The logical flow for a federate is captured in the following sequence:
- Create Federation Execution / Join Federation
- Declare Publish/Subscribe Interests
- Register Object Instances (e.g., Drone_01, Drone_02)
- Enter Main Simulation Loop:
- Request Time Advance (Time-Stepped or Event-Driven)
- Run Local Simulation Model (Update Drone State)
- Update Attribute Values & Send Interactions
- Process Incoming RTI Callbacks (Reflect Attributes, Receive Interactions)
- Delete Objects, Resign from Federation, Destroy Federation Execution.
The critical coordination for maintaining a stable drone formation is achieved through algorithms running within each drone federate. These algorithms use the state information of neighboring drones (received via RTI) to calculate necessary control adjustments. A fundamental aspect is formation-keeping, often modeled using potential field or consensus-based control laws. For example, a simple potential field function to maintain a desired separation $d_{des}$ from a neighbor can be expressed as part of a control input calculation:
$$
\vec{F}_{rep} = \begin{cases}
k_{rep} \left( \frac{1}{||\vec{r}||} – \frac{1}{d_{des}} \right) \frac{\vec{r}}{||\vec{r}||^3} & \text{if } ||\vec{r}|| < d_{des} \\
0 & \text{if } ||\vec{r}|| \geq d_{des}
\end{cases}
$$
where $\vec{r}$ is the vector from the current drone to its neighbor, and $k_{rep}$ is a repulsive gain constant. The total control input $\vec{u}_i$ for drone $i$ in a formation might combine attractive forces to a waypoint, repulsive forces from neighbors, and velocity-matching terms:
$$
\vec{u}_i = \vec{u}_{i}^{goal} + \sum_{j \in \mathcal{N}_i} \vec{F}_{rep}(i,j) + k_v (\vec{v}_j – \vec{v}_i)
$$
where $\mathcal{N}_i$ is the set of neighbors for drone $i$, and $\vec{v}$ denotes velocity. The table below summarizes key services provided by the RTI that are extensively used in our drone formation simulation.
| RTI Service Category | Service Name | Role in Drone Formation |
|---|---|---|
| Federation Management | Create/Join/Destroy Federation Execution | Initializes and terminates the multi-drone simulation session. |
| Declaration Management | Publish/Subscribe Object & Interaction Classes | Defines which drone data (state, commands) each federate shares and listens for. |
| Object Management | Register/Discover/Update/Reflect Object Instances | Manages the lifecycle and state updates of each individual drone in the federation. |
| Ownership Management | Attribute Ownership Transfer | Could allow dynamic handover of drone control between different controller federates. |
| Time Management | Time Advance Request (TAR/GALT) | Synchronizes the logical time of all drone federates, ensuring causal correctness. |
System Integration and Visualization
The integration of the 3D visualization component is crucial for providing intuitive feedback on the drone formation performance. We developed this module as a semi-tightly coupled system. While it could be a full HLA federate, for performance and flexibility, we implemented it as a standalone application that receives a consolidated stream of all drone states via User Datagram Protocol (UDP) from the Data Collector federate. This design choice offloads the demanding graphical rendering from the RTI’s time management cycle.
The visual database for the terrain, airspace, and detailed drone models was created using Multigen Creator. The runtime scene graph and visual effects are driven by Vega Prime, configured through application code written in C++. The Visualization federate subscribes to the essential position and orientation data for every entity in the drone formation. It then maps this data onto the corresponding 3D models within the scene, rendering the coordinated motion of the formation in real-time. This allows observers to visually verify formation integrity, identify near-miss events, and assess the overall efficacy of the control algorithms governing the multi-drone system.
The data pipeline for analysis is equally important. The Data Collector federate logs timestamped states of all drones, all issued commands, and any triggered warnings (e.g., proximity violations) into a SQL database. This repository serves multiple purposes: post-simulation analysis to quantify formation-keeping error or fuel efficiency, mission debriefing, and regression testing. By comparing logs from different simulation runs, developers can iteratively refine the autonomous behaviors governing the drone formation, enhancing robustness and performance.
Conclusion and Future Enhancements
We have successfully designed and proposed a functional framework for a multi-drone formation flight simulation system based on the HLA/RTI standard. This framework effectively addresses the core requirements of interoperability, reusability, and scalability for complex distributed simulations. By decomposing the system into modular federates—simulating individual drones, management, monitoring, and visualization—we have created a platform where algorithms for formation control, collision avoidance, and mission planning can be developed, tested, and analyzed in a high-fidelity virtual environment. The use of a standardized RTI ensures reliable and synchronized communication between these modules, which is critical for the coherent behavior of the entire drone formation.
The framework’s adherence to HLA means that individual components can be readily replaced or upgraded. For instance, a more advanced aerodynamic model for a specific drone type can be integrated into its federate without affecting the rest of the system. Similarly, new federates for simulating weather effects or ground control stations can be added to the federation. Future work will focus on implementing more sophisticated, bio-inspired formation algorithms, enhancing the fault-tolerance models within the simulation (e.g., simulating the loss of a drone in the formation), and integrating hardware-in-the-loop (HIL) components where actual drone flight controllers are tested against simulated vehicles and environments. This framework establishes a foundational testbed that is vital for advancing the safety and reliability of autonomous multi-drone operations, from dazzling light shows to complex collaborative missions.