Analyzing Airspace Data with RACE

{Peter.C.Mehlitz, Dimitra.Giannakopoulou, Nastaran.Shafiei}@nasa.gov
NASA Ames Research Center

Slides

started as a distributed LVC simulation framework in 2015
evolved into a general event driven application framework:
- can import/export from/to external systems - connectivity
- can process high event rate and data volume - scalability
- supports distributed and massively concurrent operation
- has batteries included (except Java runtime, SBT build system)

runs on JVM, programmed in Scala using Akka actor library
basic building blocks are actors - objects that only communicate through messages (processed sequentially)
RACE messages are sent through channels
RACE actors/channels runtime configured (JSON), not hardwired

automatic detection of

mapped to dedicated actors

only ~140 app specific lines of code (mostly HTML formatting)
original goal was only XML schema validation - time series analysis added after visualization showed anomalies
import layer convenient to switch between input sources
first application to use HTML server for reporting (was running headless in private network)

goal: automatically detect parallel approaches that are angled-in exceeding 30° heading differences within given distance (causing loss of sight)

~180 lines of code (approach analyzer)
quadratic problem: pairwise trajectory comparison of un-synchronized irregular time series
approach: filter candidates, detect parallel approach point, interpolate and compare traces backwards
filtering crucial (brute force parallel was limiting extensibility)
uses generic trajectory infrastructure (traces, extrapolation/interpolation) - more needed

how do positions for same flight differ between different input sources (ASDE-X, TAIS, SFDPS, direct ADS-B)?
are differences random or systematic?

~180 lines of code (trajectory comparer)
again motivated by visualization (noticing discrepancies)
import layer convenient to switch between different input sources
again pairwise trajectory analysis (selection by same flight id)
comparison more expensive (interpolation, mean diff, variance for distance + angle)

left shows TCAS display of simulator flight FDZ001 - live flight XY333 shown as alert
right shows RACE viewer with LoS event between simulated (FDZ001) and live (XY333) flight

uses generic native interface layer (memory layout, native library for external simulator)
highly parallel problem (trajectory extrapolation, sorted proximity calculation)
larger number of flights would require parallel computation

actors are a good programming model for presented applications
implementation platform (JVM, Scala, Akka) is suitable basis but favors throughput over latency (soft realtime)
trajectory analysis requires more domain specific support for interpolation, extrapolation
visualization is important for property identification but currently a challenge (general: native APIs, specific: WorldWind)
applications often highly parallel but HW based solution (GPU,SIMD) difficult in JVM without sacrificing extensibility
native code/memory support becomes more important (hybrid systems interfacing, graphics APIs, heterogeneous computing)
yet RACE already scales up to whole NAS (>4000 simultaneous flights, >1000 msg/sec) and more optimizations in the queue