Surveillance and Broadcast Services

1. Surveillance and Broadcast Services Actual Radio Coverage

2. Brief Introduction • Actual Radio Coverage (ARC) • A coverage plot based on ADS-B updates in an airspace enclosing an ADS-B GBT. Using these updates, as well as updates from neighboring GBT, it is possible to determine the geographic probability of detection (GPD). • Geographic Probability of Detection (GPD) is a measure of how likely an update will be received from a transmitter by a GBT by using their geographic proximity as well as other well defined factors (Theoretical Radio Coverage Plots). Data from other sensors will help make this value more accurate.

3. Brief Introduction (Cont.) • Usefulness of the GPD • Holes in coverage might be discovered that are not defined in theoretical cover plots. • This could also show degradation in coverage due to inclement weather. • Determine if there is a lose of data. • Dropped messages or poor reception. • Flying in a GPS coverage hole. • Determine if there is NO data. • GPD would be displayed in a stale state indicating that this value is based on older update times and that no new updates have been received with which to update the GBT GPD value (GBT is Transmitting NO ADSB updates at all!).

4. Summary • Functions • GPD Tracker Service • This service will be responsible for generating information about each ADSB GBT in a configured service volume as well as information pertaining to targets received by each ADSB GBT and other sensors in a configured service volume. • GPD Fusion Service • This service will be responsible for fusing data from all GPD Tracker Services and combining in a manor that creates an overall picture from the information created about each GBT and target by each GPD Tracker Service. • Assumptions • This model assumes that: • At least one ADS-B update is received to start the process • All duplicate and best fit from all towers are being transmitted • Coverage areas will be viewable in both GBT centric and tower composite views

5. First & Second Level Requirements

6. System Context Diagram Sample

7. Topic Overview Example

8. GPD Tracker Service Outline • GPD Tracker Service • GBT GPD Calculation • SBS GPD Tracker Service will be responsible for handling and grouping ADSB target updates in a manor in which the GPD calculation algorithm can determine the probability that a GBT has received a target within its theoretical coverage plot. • Primitive Historicize • SBS GPD Tracker Service will be responsible for handling ADSB, TISB, and other future sensor updates in a manor such that this information can be used to increase the accuracy of the GPD value and generate separation densities of targets in a defined airspace.

9. GPD Service Design Overview

10. Derived Requirements

11. Derived Requirements (Cont.)

12. GPD Calculation

13. GPD Calculation (Cont.) • For each GBT in the generated list, verify that GBT exists in the list of updating GBTs • If it does, verify that in exists inside of that towers theoretical coverage region. Increase towers positive value if it does • If it does not • Verify that this update does not exist in a coverage hole based on the theoretical coverage • If not in a coverage hole, increase missed counter • If in a coverage hole, do nothing. List of Updating Towers 7-0001 7-0002 7-0004 7-0005 7-0006 7-0007 Generated List of Towers 7-0001 7-0003 7-0004

14. GPD Calculation (TRC Lookup Table) • Using a lookup table will quickly verify that an update exists inside a GBTs theoretical coverage • Read in all polygons for all altitudes for a tower. For each altitude, find the maximum and minimum latitude and longitude values in that altitude slice. Use a cube of side length s (configurable) to generate the primary table from these values. • For each polygon in this altitude slice, fill these polygons with cubes. For each point in these fills, toggle the coverage state of the primary table for that altitude slice (coverage or no coverage). • After generating the lookup tables, save them to an XML file in a local directory so that these tables will only have to be generated once or when a towers TRC map changes. • This will be able to handle Simple polygons (non self intersecting polygons) and complex polygons (self intersecting polygons)

15. GPD Calculation (TRC LT Cont.) • Using a lookup table also allows for • Generating a tower centric GPD • Using a lookup table will allow for a more accurate representation of the towers GPD by using the towers theoretical coverage. This will reduce the number of false negatives by forgiving holes in coverage generated by the theoretical coverage plots. • Generating an altitude based GPD • Summing the positive and negative values of each cube in the desired altitude bands and applying the GPD formula will produce a GPD for that range of altitudes • Generate a multi-tower GPD • Summing the positive and negative values for all cubes of all towers for an altitude band (can include all) would generate an overall GPD value for that set of towers • Generate a coverage area GPD (SA) • Generate a list of cubes from selected towers using geo-fencing. Summing the positive and negative values of this list of cubes will generate a GPD value for the desired area.

16. GPD Calculation (TRC LT Cont.) • Generating Common Coverage between GBTs • When generating coverage areas, a GBTs coverage will overlap with its neighbor. This can cause double counting and cubes overlaying cubes. In common coverage, a root mean square value for the common coverage area can be calculated and displayed as the common GPD value.

17. GPD Calculation (TRC LT Cont.) • TRC/ARC for 7-0125 at 17000ft • The indigo polygon represents the GBTs TRC. • Grey cubes represent cubed coverage inside the GBTs TRC. Black cubes represent cubed coverage outside the TRC • Blue circle represents the absolute maximum distances away from the GBT to accept targets. • Healthy : Green • Alert : Yellow • Alarm : Red • No Traffic : Grey • Outliers : Purple

18. GPD Calculation (TRC LT Cont.) Common Coverage of all GBTs in Service Volume 160 • Healthy : Green • Alert : Yellow • Alarm : Red • No Traffic : Grey

19. GPD Calculation (TRC LT Cont.) Density Plot of all Overlapping GBT Coverage in Service Volume 160 • 1-2 : Blue • 3-4 : Yellow • 5-6 : Red • 7 or more : Violet

20. Geographic Dilution of Precision (TRC LT Cont.) • Two GDOP Values can be generated • GDOP from WAAS data. This will show a measure of how good the geometry is between the satellites and the received, giving a measure of the accuracy of the GPS value. • GDOP from the GBT data. This will show a measure of how good the geometry is between the GBT and the transmitter, giving a measure of the accuracy of MLAT values (If generated). • Using MLAT on updates from GBTs will generate another measured distance which can be used to verify the position of the transmitter.

21. Derived Requirements

22. Primitive Historicize • Apply Kalman Filter to updates to generate a model for that track (ADSB Only). This will allow for: • Confidently associating other sensor data updates with an ADSB update. This association will provide more data points which may be used to determine whether an update was received by a GBT in areas of common coverage between sensors. • Verify the accuracy of the reported position of an update. • Determine the density of traffic of an airspace as well as separation densities of traffic of an airspace.

23. Primitive Historicize (Kalman Filter)

24. Primitive Historicize (KF Cont.)

25. Primitive Historicize (KF Cont.)

26. Primitive Historicize (KF Cont.) Time Update (Prediction) Measurement Update (Correction) Initial states based on measured values

27. Separation Densities (KF Cont.) • Having knowledge about the state of the model allows for the ability to time align (assure that all target updates exist is the same time frame through either updates are predicted states) position information to measure the distances between targets as well as verify the position of updates. < 5NM >= 3NM < 3NM >= 5NM

28. Separation Densities (KF Cont.) • Having states defined for a model allows for separation densities to be generated by sampling the model every (threshold) timespan. • Every (threshold) timespan, grab all the positions from either the GPS update or state (depending on which value we believe more) and determine the distances from each. • Having states gives us another value for the dynamics of the transmitter. • Are the errors in the GPS measurements to great to confidently determine a position to base a distance measurement off of? • Are all of the updates current? Are all of the values measured for the same instance in time?

29. Derived Requirements

30. Derived Requirements (Cont.)

31. GPD Service Design Overview

32. GPD Fusion Service Outline • GPD Fusion Service • Merge GBT TRC lookup tables • Merge lookup tables that cross SDAT boundaries to allow for a more complete GPD value and plots to be generated • Assign tables to service areas that span SDAT boundaries • Compile information to be shipped off to portal • Allow GPD Tracker Services to share track information • Allow NESAT 2D and 3D to request information about GBTs, Service Volumes, and Service Areas to be displayed. • Allow each GPD Tracker Service to query the others about track information for new tracks that have entered its airspace • Only do this for tracks in Terminal and En Route airspaces. • Don’t want to reset our state objects for established targets.

33. Merge GPD Lookup Tables • Merge GBT TRC lookup tables • Merge lookup tables that cross SDAT boundaries to allow for a more complete GPD value and plots to be generated • Assign tables to service areas that span SDAT boundaries • Count the number of unique overlapping coverage areas • Compile information to be shipped off to portal

34. Share Shareable Track Information • Allow GPD Tracker Services to share track information • Allow each GPD Tracker Service to query the others about track information for new tracks that have entered its airspace • Only do this for tracks in Terminal and En Route airspaces. • Don’t want to reset our state objects for established targets. • Will give information about the number of unique ADSB targets seen per day

35. Display Interface • Allow NESAT 2D and 3D to request information about GBTs, Service Volumes, and Service Areas to be displayed. • NESAT 2D and 3D will request information from this service to insure that all information is fused properly • Fuse GBT coverage that spills into adjoining SDATs • Fuse Service Area data that is not contained in a single SDAT

36. Derived Requirements

37. GPD Alarms

38. Database Schema • GPD Values • Tower Centric • Use tower DSID as primary key • Save the count of positive, negative, and outlier values. • Service Volume Centric • Use Service Volume ID as primary key • Save the count of positive, negative, and outliers for cubes that are contained inside the service volumes boundaries only. • “Ruled Airspace” Centric • Use Service Volume ID as the primary key and class of airspace as the secondary key • Save the count of positive, negative, and outliers for cubes that satisfy the ruled airspace boundaries as well as the service volume boundaries.

39. Database Schema (Cont.) • ARC Tower Coverage Cubes • Use Tower DSID as a primary key • Use each altitude as a secondary key • Assign each cube a unique number to be used as a secondary key. Save the center point of each cube along with the positive, negative, and outlier counts associated with that cube. • Separation Probabilities • Use Service Volume ID as primary key • Save the maximum, minimum, and average separations. • Save counts of the number of targets that satisfy • Less than one mile separation • Between five mile and one mile separation • Greater than five mile separation

40. Database Schema (Cont.) • ARC Alarms • Use DSID as primary key and event time as secondary key • Use Boolean flags to indicate the alarm state.