I joined the aerospace community in 1999 as a developer of operational display software for air traffic control. Until then I didn't really have a notion of this discipline of aviation, other than having seen the movie and read the book Airport. Being the prototypical nerd, and having played thousands of hours of video games by then, it struck me as odd at that time, that cutting-edge air traffic control displays looked very much like Pong, the popular 70's video game: A few lines, a few boxes, and some fake afterglow effects. Of course, I learned then, that what looks good in a video game, doesn't really work well in a control room, and that even the fake afterglow effects had a purpose.
Career-wise, I moved from display software to networking software, and finally to algorithms. In the early noughties, I happened on the subject of conflict detection. The job I was hired to do at that time had actually nothing to do with algorithms. It involved some straightforward porting work, taking implementation from platform A and modify for platform B. I think it was from DEC/Alpha to GNU/Linux; something like that. But after having ported the software, and having seen it running, it turned out that the performance of the algorithm sucked. How come, in the age of Lara Croft, that an air traffic control conflict detection software, a mission-critical piece of software - if any, couldn't handle a few hundred, let alone a few thousand, aircraft at the same time? That piqued my interest. And I started digging into conflict detection and resolution algorithms.
At very high altitudes, aircraft move primarily horizontal, straight, and at a steady speed, with the occasional climb or descent; not very interesting from the computing perspective. Air traffic in lower controlled airspace is primarily vertical. Most aircraft are either climbing to attain their cruising altitude, or descending to approach their destination airport. Air traffic controllers clear the climb or descent, and have to make sure that the aircraft can transition between altitudes without conflicts. This is no small cognitive feat. Homo sapiens tends to think in two dimensions.
Spock: He [Khan Noonien Singh] is intelligent, but not experienced. His pattern indicates two dimensional thinking.
Star Trek: The Wrath of Khan
When aircraft change altitude, this is no straightforward linear movement. Going up, the air becomes thinner. For a climbing aircraft, drag decreases. As the aircraft climbs, it effectively accelerates. Charting the distance covered with time, as seen from the ground, the aircraft trajectory looks like the upper slope of a parabola that opens to the right. It is not a true parabola, of course. The mathematical expression is slightly more complicated. But the parabola serves as an approximation. Again, this is something difficult to do in your head. Let's imagine a baseball scenario: Pitcher serves ball straight at the batter. Batter bats it. Simple enough. Now, assume the ball is accelerating as it approaches the batter. At some point in time, the batter will start to swing to hit the ball, but the ball will still be accelerating. By the time, the bat swings round, the ball has travelled farther than anticipated. A similar scenario when aircraft descend. As drag on the airframe increases, the aircraft decelerates, and becomes slower. In baseball terms, as the ball approaches it becomes slower and slower. After the batter has started to swing, the ball will still be breaking in midair, and the swing will probably miss it.
At an altitude of 11 km the atmospheric properties change and things become nice again. From here on up until about 20 km, when the aircraft climbs or descends, it doesn't change groundspeed. Travel's at a nice and steady pace while climbing or descending.
With both of these conditions applying to aircraft as they transition between altitudes, accelerating below 11 km, steady above, or first one then the other when crossing the 11 km, guaranteeing conflict-free transitions is a cognitive challenge.
Aircraft positions, distances, headings, movements, trajectories essentially are all just geometry. A branch of mathematics that has been literally around for ages. The discipline of computing dealing with geometry is called computational geometry. It is mainly employed in computer graphics to render images on screen for design, computer games, or visual effects in movies; and in geographical information systems to query about proximity (Where's the next restaurant?) and location (What is here?). By the end of the noughties, I had assembled and modified a bunch of algorithms into a software that could process air situations of a few hundred aircraft, and detect conflicts between them in a few milliseconds - on a single processor of a commercial-off-the-shelf computer. That should be good enough for air traffic management.
In 2011, the R&D division of DFS Deutsche Flugsicherung, the German air navigation service provider, contracted me to develop the conflict detection and resolution software components of their CATO Controller Assistance Tools research prototype. The tools assist controllers in two ways: They alert air traffic controllers to existing conflicts in the current situation, and they continuously run extensive clearance simulations.
The first function acts as another pair of eyes for the air traffic controllers. The cognitive workload on controllers in dense traffic situations can be quite demanding. The software makes sure, that no conflict escapes the attention of the controllers. Like a dog occasionally barking to make sure that no movement goes unnoticed.
The second function is a bit less obvious: A clearance simulation is to speculate "What would the situation probably look like, if this aircraft were cleared to this altitude? Would that situation be free of conflicts?" The software conducts these simulations extensively: For every aircraft on frequency, for every clearable flight level, for every clearable climb rate, for every clearable heading, for every clearable waypoint, what would the situation be if this were the clearance given to this aircraft? Would the situation be free of conflicts? Like a chess computer, the software determines the consequences of possible next steps to take. Information thus gained is presented to controllers on occasion and when useful.
On the operational display of the air traffic control system, whenever a menu is opened to clear a flight, all available options will be colour-coded. For every option there will be an indication whether such a clearance would be free of conflicts, or whether it would entail some conflict, or whether it would need additional constraints to remain free of conflicts. Presenting this information in a proper fashion, imparts additional situational awareness on controllers. Usually, they look onto a flat screen, and perceive air traffic from the bird's eye perspective. Presenting available flight levels in a ladder-like fashion, or available headings in a pie-chart fashion - all colour-coded to indicate conflicts or additional constraints - conveys a first-person perspective i.e. lets the controller perceive the situation from the perspective of the aircraft to be cleared.
The software has been validated and proven feasible for significantly higher amounts of air traffic than today while maintaining or improving safety levels.
The software can scale up to large amounts of traffic by parallelisation and appropriate hardware. The validation results in the context of conventional air traffic management suggest as much. But wouldn't it be interesting to see how the software would fare if the hardware platform were actually shrunk?
La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer.
Perfection is attained not when there is nothing more to add, but when there is nothing more to remove.
Antoine de Saint-Exupéry
I have implemented the conflict detection algorithms on a Raspberry Pi. To my liking, it did alright. The conflict detection wasn't as fast as on a dedicated set of air traffic control computers, of course. But a Raspberry Pi would be able to handle moderate levels of today's air traffic in watchdog mode. For extensive clearance simulations, it lacks the resources. But I have my eyes set on Jetson, one of NVidia's embedded GPUs to see how it performs with embedded accelerators.
Surveillance components have already scaled down to smaller form factors. With efficient traffic analysis algorithms running on small devices like the Raspberry Pi, the Jetson, and their kind, I believe we can have IoT traffic management devices for everyday use; and not just air but any kind of traffic.
In this spirit,