A few years ago, after meeting a group at UC Berkeley who built an auction-based UAV swarm manager, I decided to build a simple aircraft fleet simulator of my own, just for fun, using Excel and Google Earth. In my simulator, aircraft would first take off from designated airports, and loiter in a special loiter area until a mission was posted. The nearest unassigned aircraft having the right capabilities would accept the mission and fly it, then return to their loiter area if no new missions were available. Missions had priorities, and an aircraft could abandon a lower-priority mission for a higher one.
There are only two basic missions: a tracking mission flies a specified geometric pattern (eg: an octagon) around a point for either a specified number of iterations or until assigned a new mission. A path mission flies along a multi-segment path. Multiple path missions are chained together to form an area mission, in which one or more aircraft fly over a rectangular area. Takeoffs and landings are simply path missions, with takeoff and landing paths predefined for each airport. Loitering is simply a tracking mission in a specially designated area.
It became apparent that, the greater the number of aircraft and the smaller the space, the greater the need for some forms of traffic management. For traffic control within a loitering area, each aircraft is assigned a unique positional slot to avoid collisions. Wide-area traffic management was later added by building a grid of pathways connected at specified waypoints. When an aircraft accepts a mission, it gets to the operational area of the mission by flying along these travel pathways. The travel pathway is not precomputed; the optimal available pathway is selected as the aircraft arrives at each waypoint. In this way, pathways can be activated and deactivated as the need arises in order to, for example, make room for a new operational area.
The simulator can run in either Real Time mode or Best Effort mode. Best effort will run as fast as possible, while real time will not overrun the clock. In addition, a special mode enabled the expensive position computations to be run less frequently, without missing waypoints. In real time and best effort modes, about 20 aircraft could be simulated at one time. In the delayed update mode, more than 200 aircraft could be simulated at one time; although they would accurately hit all waypoints and complete missions, the tradeoff was that their positions were not precisely plotted most of the time. Other optimizations included a way to allow the system to catch up when running in real time mode.
At one point, I had two spreadsheets operating at once; the first ran the Simulator and the second served as the mission manager. I discovered that I could establish an OLE connection between the two and it was possible to add new missions to the mission manager spreadsheet and have those pushed over to the simulator while the simulator was running. It isn’t possible to update a spreadsheet while a VB script is running so with just one spreadsheet, all of the missions had to be plotted in advance.
For fun, aircraft had a limited fuel supply, plus a reserve and would abandon a mission and attempt to return to their home airport when their main supply was exhausted. Failure to reach the airport in time would result in a crash. Progress could be easily monitored by watching the Mission worksheet. In addition, position information was output in KML format and viewable in Google Earth.
I did not implement more sophisticated algorithms for assigning missions, although numerous obvious improvements were possible. These included better mission abandonment cost functions, and latest time of value considerations.