vincent duchamp density-adapting layers towards pbn for utm€¦ · faa@uberelevate summit: -...
TRANSCRIPT
Density-Adapting Layers towards PBN for UTM
Vincent Duchamp - Ecole Nationale de l’Aviation Civile Toulouse, France
Leonid Sedov and Valentin Polishchuk - Linköping University
Norrköping, SwedenSupport: Gouvernement de la République française. Vetenskapsrådet and Trafikverket via Swedish ANSP (LFV)
Airpsaces are like ogres
AltAlt Rule
Levels in ATM prevail
Metropolis
Thorough investigation of several air traffic structuring concepts
● Full Mix● Layers● Zones● Tubes
Metropolis@ICRAT'18 →
Metropolis
same (# of) layers over whole ROI
Findings
Layers performed best… The Layers concept, being the most promising, definitely deserves more attention in future research
Assumption
Uniform traffic distribution (a/c equally likely anywhere in ROI)
UTM: non-uniform vehicle distribution
Expected traffic densityhow likely it is to see a drone
Population density
Likely UTM (LiU) map [S,P,Bulusu DASC'17]
This paper # of layers adapting to conflict severity
Algorithms ⇒ frequent change eg hourly updates or faster (ATM-like AIRAC cycles for AIP
too slow for dynamic UTM)
↓
Software-Defined Airspace!?
VLL airspace: thin band for drones
MetropolisNASA UTM
Better now (proactively, from scratch)
than ever (retrofitting is painful, cf. ATM)
PBN4UTM: much needed - high diversity of users
need to quantify their RNP- need diverse airspaces
ConOps'es work towards these
Layers (scarce VLL resource) → performance requirements
+ less noisyimproved vertical
precision
Performance requirements
Asked for multiple times:
● Ectl RPAS ConOps○ need to define classification of drones capabilities
● CARS solution from Ectl+EASA: ○ "still requires research and validation campaigns to specify the
performance requirements of each of the airspace users and sub-systems."
● …
Some answers, e.g. [Ren, Castillo-Effen, Yu, Johnson, Yoon, Takuma, Ippolito DASC'17]
Categorization of drone PBN capabilitiesincluding the vertical performance
Our adaptive airspace design
Suggests performance needs + Relies on PBN to separate traffic classes based on their performance
PBN4UTM: long promoted [PK DASC'16 plenary, @Google, pers comm]
● encourage to adopt different regulations in different airspaces ○ incl. restrictions for drones with weaker capabilities from flying
through congested urban spaces● establish restrictions only when and where necessary
○ cruising, lanes, corridors, altitude separation ● match the geography to the required performance to operate in
the airspace
Reflected many times...
Our am
bitions
Great minds think alike
● NASA ConOps Mantras- flexibility where possible, structure only where necessary- risk-based approach where geographical needs and use cases determine the airspace performance requirements
● SESAR U-space Blueprint Key principle- follow risk-based, performance-driven approach when setting up appropriate requirements...
● FAA@UberElevate summit: - importance of performance-based regulatory regime, risk-based analysis for urban airspaces
● AirMap requirement for U-space: - to be performance-based to encourage innovation
● All 3 airspace issues identified at CORUS Exploratory Workshop:- related to height; overall view on question of airspace division into bands was that many layers should be an exception, for drone-busy areas, rather than the rule
Our solutions: ConOps → action!?
Concrete examples of possible use
areas in the city center: Amber airspaces [CORUS]? →
← segment the airspace "into cells of similar requirements"
[DLR Concept for Urban Airspace Integration] (which develops concepts to "form a basis forfurther research in the area of separationand performance-based operations for UAS")
What our methods are based on
Push off UTM probabilistic capacity thresholds [UC Berkeley + Linköping U '17]
Inspired by perfect graphs [chromatic number = max clique]
Definitions (graph, chrom #, max clique, threshold...),
technical details follow…
Model
● UAV = radius-r disk
● conflict = disks overlap
Conflict graph
● vertices = UAVs
● edge = conflicting pair
Layer assignment = Graph coloring
any edge: endpoints have different colors
colors = layers (any 2 conflicting UAVs → different layers)
chrom# of a graph =
min # of colors to color the graph
Clique = set of pairwise-connected vertices
maximal clique = can't add a vertex
Useful fact: chrom# ≥ clique size
Finding chrom# and cliques
Computationally hard (∄ fast alg to find opt); heuristics ∃
● Clique enumeration [Bron–Kerbosch]
○ complicated○ guarantees to list all cliques○ slow (exponentially many cliques)
lucky if fast● Greedy coloring [DSATUR]
○ simple and efficient○ no opt guarantee (in theory)
lucky if good result
[Michail, Kinable, Naveh, Sichi A Java library for graph data
structures and algorithms]
On drone conflict graphs: got lucky with both!
Experiments
On drone conflict graphs:
● Cliques were listed fast ● Greedy coloring: |max clique|
or |max clique| +1 colors○ proof of (near) opt!
In what follows:layers = drone cliques
Why lucky (ruminations)intuition (curiosity only)
Conflict graphs: (almost always)perfect (chrom# = |max clique|)
= no chordless odd cycle• "unlikely"
Perfect graphs: chrom#, clique are easy (efficient algs) - possible reason greedy works well
Key to demand--capacity balancing
How to match demand to capacity of resources?
● Resource = airspace (layers)● Conflict graph: a representation of demand
Know where to look in the demand (bottleneck): drone cliques in the conflict graph
How to use it to decide layers over the city?Study "geography of conflicts"
(spatial distribution of clique size)
Q1: How many layers in the city center (largest clique)?Q0: Why is it <∞ ( < N = total # of UAVs )?
UTM
● Unpredictable behaviour● Kindergarten is enough● Can takeoff from anywhere● Jammy urban GPS signal
Stochastic nature of UTMATM
● Scheduled, precalculated flights● Trained cabin crew● Can takeoff only from airport● Accurate geopositioning
Randomness is good:
● Malicious (deterministic) users could create large conflicts● Random flights "smear" conflicts (lower their prob)
○ under a "reasonable" randomness model
Cal model
● Bulusu, Sengupta, Liu (UC Berkeley "Cal") @ ICRAT'16] ● [PK (NASA Ames, CA) @ Google: "every home will have
a drone and every home will serve as an aerodrome"]
Endpoints: ~ population density
@ ∀ pt:Poisson process
intensity ~ pop density [Bulusu, Sengupta, Liu ICRAT'16]: Figure 3
VTOL, direct flights, same speed, r
Prob{conflict}?
Depends on
● r conflict radius● N expected # of flights
(traffic intensity)
P{conflict}(N,r)
● ~0 for "small" N, r hard to bump into a drone
● ~1 for "large" N, r hard to avoid a drone
What is the exact dependence?
r = 100m
Joint with UC Berkeley, IEEE SysCon'17
Prob{conflict}(N)
r = 50m
Joint with UC Berkeley, IEEE SysCon'17
Prob{conflict}(N)
r = 5...300m
Joint with UC Berkeley, IEEE SysCon'17
Prob{conflict}(r)
Joint with UC Berkeley, IEEE SysCon'17
Safe
Unsafe
MasterPlan's "drone density thresholds"?
Prob{conflict}(N,r) -- sharp 0/1 thresholds
Conflict graph: rnd geometric graph (RGG)- vertices are rnd distributed- edges defined by proximity
Deep result from RGG theory [Goel, Rai, Krishnamachari'05]:
Monotone properties have (sharp) thresholdsVery general (applies to any property)Theory: for uniformly distributed vertices
Experimental confirmation (simulation, sampling)for (highly non-uniform) drone conflict graphs
[UC Berkeley + Linköping U '17]
"Having a conflict" -- monotone property+edge → conflict "even more"
"Having a large conflict (clique)" -- monotone property
Graph propertiesMonotone: holds on+edge ("even more")
● Connectedness● Being a tree● Having edges
○ component of size >1
● Component of size >2● Component of size >3● Component of size 2● >2 comps of size 2● >2 comps of size >2● 2 comps of size 2● 2 comps of size >2● …
Prob{|clique|≥2}(N,r) -- sharp 0/1 threshold
Prob{|clique|≥3}(N,r) -- sharp 0/1 threshold
Prob{|clique|≥4}(N,r) -- sharp 0/1 threshold
Prob{|clique|≥5}(N,r) -- sharp 0/1 threshold
Prob{|clique|≥6}(N,r) -- sharp 0/1 threshold
Prob{|clique|≥7}(N,r) -- sharp 0/1 threshold
Prob{|clique|≥8}(N,r) -- sharp 0/1 threshold
Prob{|clique|≥9}(N,r) -- sharp 0/1 threshold
Prob{|clique|≥10}(N,r) -- sharp 0/1 threshold
Prob{|clique|≥11}(N,r) -- sharp 0/1 threshold
Thresholds (for cliques) → max # of layers
For given N,r Different N, r → different (# of) layers
(Software-Defined Airspace)
Just know your thresholds (for all drone trips)
● computed once ● for the full range of● N, r, clique size
Prob{|clique|≥11}(N,r) -- sharp 0/1 threshold
Prob{|clique|≥10}(N,r) -- sharp 0/1 threshold
Prob{|clique|≥9}(N,r) -- sharp 0/1 threshold
Prob{|clique|≥8}(N,r) -- sharp 0/1 threshold
Prob{|clique|≥7}(N,r) -- sharp 0/1 threshold
Prob{|clique|≥6}(N,r) -- sharp 0/1 threshold
Prob{|clique|≥5}(N,r) -- sharp 0/1 threshold
Prob{|clique|≥4}(N,r) -- sharp 0/1 threshold
Prob{|clique|≥3}(N,r) -- sharp 0/1 threshold
Prob{|clique|≥2}(N,r) -- sharp 0/1 threshold
Thresholds: max clique = 4 for given N,r
4-clique somewhere in the city [earlier thresholds work]
4 layers over the whole city? [SP ICRAT'18]
defeat our purpose
Spatial distribution of 4-cliques- take many traffic samples- find locations of 4-cliques- 4-layer area = CH(4-cliques)
Recursively - 3-layer area = CH(3-cliques)- 2-layer area = CH(2-cliques)
(larger has negligible prob)
Results
Results
Results
r = 200 r = 300
N = 60000
N=100000
More pix: https://tiny.cc/atm_sem_pics
Extensions of CH
CH(S) = complement of all empty halfplanesTo curve out CH(S), roll a halfplane around S
S = choc chips in universe of icecreamCH(S) = what's left after choc allergic eats all icecream with knife
Extension 1/3: k-hull
k-hull(S) = complement of all halfplanes with ≤ k pts of STo curve out k-hull(S), roll a halfplane with k pts of S around S
S = choc chips in universe of icecreamk-hull(S) = what's left after choc allergic eats all icecream with cheese knife (k holes)
a.k.a. k-depth contour in statisticspts "deeper" inside S ("k-deep")statistically meaningful (sans outliers)
generalization of CHCH = 0-hull
k-hulls for k = 0, 10, 30
Extension 2/3: ɑ-hull
ɑ-hull(S) = complement of all empty ɑ-disks To curve out ɑ-hull(S), roll an ɑ-disk around S
S = choc chips in universe of icecreamɑ-hull(S) = what's left after choc allergic eats all icecream with scoop (radius ɑ)
ɑ-shape(S): straightline version of ɑ-hull(S)better conforms to "shape" of S may have >1 cluster
generalization of CHCH = ∞-hull = ∞-shape
ɑ-shape
CH
+ Avoiding restrictions
- Non-convex (re-entry possible)
Extension 1+2 / 3: k-order ɑ-hull
k-o ɑ-hull(S) = complement of all ɑ-disks with ≤ k pts of STo curve out k-o ɑ-hull(S), roll an ɑ-disk with k pts of S around S
S = choc chips in universe of icecreamk-o ɑ-hull(S) = what's left after choc allergic eats all icecream with colander (k holes, radius ɑ)
k-o ɑ-shape(S): straightline version of k-o ɑ-hull(S)combines features of k-hull and ɑ-shape(generalizes both, hence generalizes CH)
k-order ɑ-shape
+ ignores some outer pts (outliers?)
as k-hull
+ saves space (permits less equipped drones to operate in unrestricted area)
as ɑ-shape
k-order ɑ-shapes →more parsimonious than CHs
CHs↓
SummaryLayered structure
adapting to conflict severity
Algorithms ⇒ changes eg due to events
Follow ConOpses towards PBN4UTM in Software-Defined Airspace
Open questions
● name for the different-layers places
○ sectors (ATM), areas, zones
● distributing among layers optimally
○ eg min jumps between layersfor "through" flights
● managing insufficient layers (DCB)
○ eg with economic incentives? [Saez, Josefsson, D, P, Wiren DASC'19]
● study possible impact of geovectiring [Hoekstra, Ellerbroek, Sunil, Maas ICRAT'18]
○ no-fly zones, for starters