National Aeronautics and Space Administration

Strategic Deconfliction:
System Requirements

Final Report

Joseph Rios
joseph.rios@nasa.gov
31 July 2018
UAS Traffic Management (UTM) Project
Overview
This file is a combination presentation and document.
Not all “slides” are optimized for on-screen presentation.

These slides represent a revision of potential requirements for an implementation supporting

Strategic Conflict Management within UTM. The full set of requirements presented here lay the
groundwork for strategic deconfliction of UTM Operations from each other.

These slides DO NOT endeavor to provide generalized insight into UTM and are not intended to
do so. It is assumed the audience for these slides is familiar with UTM concepts. For good
introduction to UTM research, please see the initial NASA ConOps and the more recent FAA
ConOps on UTM.

These are system-level requirements presented at a high level. Detailed requirements will be
developed from this requirement set. Those more detailed requirements will be placed upon
specific systems within UTM, such as the USS or FIMS. Architectural decisions may also be
made based on this requirement set.

These slides are an important step in the formalization of UTM requirements including their
validation through collaborative review.

Since we are early in this process, some of the concept of operations and the requirements are
conflated, but this document should provide a clear picture of both aspects of the system
description.
Approach
The requirements as listed on Slide 13 of this document were
presented to the NASA UTM Project collaborators. Then a survey was
developed to solicit specific responses to each requirement from the
collaborators. Those responses are the driver for the final set of
requirements listed in Slide 33.

Each collaborator and organization they represent brings various

levels of interest and insight with regard to the UTM concept. These
collaborators span a wide breadth of stakeholders within UTM:
manufacturers, service providers, operators, policy specialists,
researchers, etc.
Strategic conflict management
From ICAO Doc 9854, “Global Air Traffic Management Operational Concept.”

2.7.10 Strategic conflict management is the first layer of conflict management and is
achieved through the airspace organization and management, demand and capacity
balancing and traffic synchronization components.

2.7.11 The term “strategic” is used here to mean “in advance of tactical”. This recognizes
that a continuum exists from the earliest planning of the user activity through to the
latest avoidance of the hazard. Strategic actions will normally occur prior to departure;
however, they are not limited to pre-departure, particularly in the case of longer duration
flights. Changes to the trajectory (whether at the request of the user or by the service
provider) will result in the selection of the best means of conflict management, which may
be strategic.

2.7.12 Strategic conflict management measures aim to reduce the need to apply the
second layer — separation provision — to an appropriate level as determined by the ATM
system design and operation. Important Note:
While ICAO allows for the possibility of strategic actions while airborne, this concept
simplifies to assume strategic is predeparture and everything after is tactical. This aids
the overall breakdown of services within UTM
Role of the Strategic Layer
Strategic conflict management (SCM) ICAO Conflict Management Layers
measures reduce the need to apply
separation provision and ultimately collision Strategic Conflict
avoidance. Management
Chance of
transition to next
“Strategic Deconfliction” is a proposed layer needs to be
reduced to some
mechanism to achieve this in UTM and is the target level (TBD)

primary topic of these slides. Separation

Provision
There are other aspects of SCM within UTM
that are out of scope of this document.

This helps specifically with keeping

cooperative UTM operations strategically
separated. Collision
Avoidance
SCM will never be the sole layer of conflict
Sense+Avoid WG
management and any safety case for an Comm+Nav WG
operation or a concept will need to address Data WG
all three layers. NASA-FAA Working Group Responsibility (notional) Concepts WG
UTM Strategic Separation Tactical Separation
Conflict
Management
Collision
Model Strategic Conflict Management Separation Provision
Avoidance

Airspace Organization and

Management Service
Conformance Monitoring Service
USS
Flight Awareness Service
Function Airspace Hazards

Airborne Hazards
Strategic Deconfliction Service Dynamic Rerouting Service
Ground Hazards

Flight Planning Service Conflict Advisory and Alerting Service

UTM

SDSP
or USS
Function
Flight Notification Service Surveillance Service

Visibility and Audibility

Ground Surveillance
Enhancements
UAS
Operator / Collision
Flight Planning Position Broadcast Detect and Avoid
UAS Avoidance
Function
Obstacle
Geographic Flight Containment
Avoidance
UTM Strategic Separation Tactical Separation
Conflict
Management
Collision
Model Strategic Conflict Management Separation Provision
Avoidance

Airspace Organization and

Management Service
Conformance Monitoring Service
USS
Flight Awareness Service
Function Airspace Hazards

Airborne Hazards
Strategic Deconfliction Service Dynamic Rerouting Service
Ground Hazards

Flight Planning Service Conflict Advisory and Alerting Service

UTM

SDSP
or USS
Function
Flight Notification Service Surveillance Service

This document focuses on requirements for a single service

Visibility and Audibility
within the UTM System. ThisGround service relies on several other
Surveillance
Enhancements
UAS services and requirements to create a safe, efficient, fair
Operator / Collision
system. Position Broadcast
Further documentation
Flight Planning on the approach Detectto
and Avoid
conflict
UAS Avoidance
Function
management and other individual services will be forthcoming. Obstacle
Geographic Flight Containment
Avoidance
 UTM five core operating principles

ba

ba
4444-8888-FEEDDEADBEEF

UAS don’t hit each other UAS don’t hit manned traffic Actors are identifiable Common situational awareness Public safety ops have priority

ca

ap
?
 ● A UTM Operation should be free of 4-D
intersection with all other known UTM
Operations prior to departure and this
ba
should be known as “Strategic Deconfliction”
within UTM.

ba

● There must be a prioritization scheme for

operations within UTM.

UAS avoid Operators Access for

each other have common priority ops
● A UTM Operator must have a facility to
awareness
negotiate deconfliction of operations with
other UTM Operators when that Operator
has a lower priority operation.
This requirement set directly
supports three of the five core
● There needs to be a capability to allow for operating principles as stated in the
intersecting operations.
UTM Concept of Operations.
 Strategic Conflict Management
(may include other elements in the future)
Requirements Terms
We rely on the IETF definitions for requirement terms within this document.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here.

Key definitions used in this document:

MUST
This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute
requirement of the specification.

SHOULD
This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in
particular circumstances to ignore a particular item, but the full implications must be
understood and carefully weighed before choosing a different course.
Note on “Strategic”
There were many comments (on individual requirements and in summary) that related to
the limitation of these requirements to pre-departure operations only. The distinction of
“strategic” to imply pre-departure operations is aligned with other organizations and aids
in decomposing the services within UTM with clear boundaries.

We understand the perspective that the requirements and concepts discussed in the
Strategic Deconfliction slides seemed equally applicable to en route traffic. To be more
specific, we see the applicability of these requirements to Dynamic Rerouting, which is a
Separation Provision service within UTM. This relationship will be manifest in the form of
lower level requirements for both Strategic Deconfliction and Dynamic Rerouting that
trace up to the requirements in these slides.

To better reflect this fact, these requirements are renamed to UTM-CM-xx with “CM”
implying “Conflict Management” of which SD and DR are a part.
 UTM Strategic Deconfliction Concept of Operations & Requirements
Requirements as presented in the survey. Update based on the survey presented on Slide 33.
● A UTM Operation should be free of 4-D intersection with all other known UTM Operations prior to departure and this should
be known as “Strategic Deconfliction” within UTM. The Strategic Deconfliction scheme:
○ [UTM-SD.05] MUST have the 4-D non-intersection of operation plans as its primary objective.
○ [UTM-SD.10] MUST be transparent to operators.
○ [UTM-SD.15] MUST be supported by all USSs
○ [UTM-SD.20] MUST be mandated by the airspace regulator.

● Strategic Deconfliction needs a prioritization scheme for operations within UTM. The Prioritization scheme:
○ [UTM-SD.25] MUST allow for preemption of operations with lower priority by those with higher priority
○ [UTM-SD.30] MUST be deterministic.
○ [UTM-SD.35] MUST be efficiently calculable by USSs.
○ [UTM-SD.37] MUST be unilaterally calculable by USSs.
○ [UTM-SD.40] SHOULD be a function of operator, operation, airspace, and vehicle parameters.

● Strategic Deconfliction needs an allowance for negotiating deconfliction of UTM operations. The Negotiation scheme:
○ [UTM-SD.45] SHOULD minimize or eliminate direct human interaction.
○ [UTM-SD.50] MUST be facilitated via USSs.
○ [UTM-SD.55] MUST be a finite process.

● Strategic Deconfliction needs an allowance for intersecting UTM operations. Intersecting operators, via their USSs,:
○ [UTM-SD.60] MUST have preceded the decision to intersect with a negotiation process.
○ [UTM-SD.65] MUST each provide explicit acknowledgement to each other of the planned intersection of operation
volumes when intersection is mutually decided.
○ [UTM-SD.70] MUST each provide details to each other on the approach to a separation provision while in
intersection operation volumes when intersection is mutually decided.
○ [UTM-SD.75] MUST provide acknowledgement of responsibility and risk related to operation volume intersection
whenever intersection is unilaterally decided by that operator.

Note: Requirement labels likely to change during harmonization with other documentation. Labels to be only considered for consistency within this document.
Survey Results Overview
This document will be considered the final report for the survey results. The data and analysis should be
considered preliminary and is only provided to give insight to the process as early as possible. The
requirements themselves will be cataloged with other UTM System requirements and presented by NASA
to the FAA as part of our RTT process some time in the future.

Some caveats for the graphs:

● Did not exclude any respondents in these results.

● There are three orgs represented with two respondents
● There is one org with three respondents
● One of the orgs with two respondents is NASA, though they are from non-UTM Project personnel

We provide a single breakout of a key group: USS Implementers. Each of the six USS implementers were
represented by a single respondent. NASA did not verify that the respondent was authorized to speak
on behalf of their organization, but NASA was familiar with each respondent and felt their responses
were indicative of their organization.

NASA feels that on the issues related to the strategic time horizon as well as other aspects of the future
UTM System, that those that have built USSs have key insights. In addition, all of these USS
Implementers have had operations flown against their systems in NASA flight tests. The breakout is
provided as a pie graph superimposed on the bar graph. The green area captures the “positive”
responses with a value of 4 or greater.
Results slide example
The next slide is an example of how the results are presented on a
per-requirement basis in the slides that follow.
[ORIGINAL REQUIREMENT LABEL] As-presented requirement Text.

Discussion about the results and how they

affect the requirement outcome.
Bar graph of all respondents. Pie graph of USS
implementers.

[FINAL REQUIREMENT LABEL] Final requirement text.

[UTM-SD.05] The Strategic Deconfliction scheme MUST have the 4-D non-intersection
of operation plans as its primary objective.

The focus on “strategic” was complicated for

respondents. The requirements seem to apply
just as well to active operations. The main
response to this is that there will be parallel
requirements for Dynamic Rerouting to address
this concern. We keep them separate to allow
more flexibility in application, but the
requirements will look very similar. Also
concerns about prioritization here (public
safety priority, efficient planning priority, etc.).
We feel these should be captured in the
prioritization requirements and will be more
concrete at lower requirement levels. Efficient
planning will be a separate set of requirements
developed in conjunction with the C+N working
group. Reword to remove “plans” from
requirement language.

[UTM-CM.05] The Strategic Deconfliction scheme MUST have the 4-D non-intersection
of operations as its primary objective.
[UTM-SD.10] The Strategic Deconfliction scheme MUST be transparent to operators.

The lack of a definition for “transparent” was

apparent. The original intent was to ensure that
operators were aware that SD existed in the
UTM System and was executed on their behalf
by the USS. The operator, as a result of this
requirement, would have access to how the
process works and potentially the reason for a
given SD decision provided to them by a USS.
This was the idea of “transparency” in this
requirement. Based on the comments, we think
this addresses some concerns. Given the
determinism other requirements, the goal would
be confidence of the operator that the system
is performing “fairly” on their behalf.

[UTM-CM.10] The Strategic Deconfliction scheme MUST be well-documented for the

understanding of operators.

[UTM-CM.12] The Strategic Deconfliction scheme MUST allow for inspection of

decisions by operators upon request from operators to their supporting USS.
[UTM-SD.15] The Strategic Deconfliction scheme MUST be supported by all USSs.

This requirement had wide acceptance. Some

comments hinted at the need for more
specificity in the requirement. We think this will
be provided in the lower level requirements that
trace up to this one.

[UTM-CM.15] The Strategic Deconfliction scheme MUST be supported by all USSs.

[UTM-SD.20] The Strategic Deconfliction scheme MUST be mandated by the airspace
regulator.

There was some common comments related to

WHICH SD approach would be mandated. We
believe this is nailed down through the lower
level requirements. We agree that the “right” SD
approach is what is to be mandated under this
requirement. Another common comment
thread involved whether the airspace regulator
is the right entity, but we think this sentiment
may be more driven by not having the regulator
be in complete control of the SD approach. We
agree that stakeholders and industry will be key
in helping choose, prove out, and maintain the
SD approach. That sentiment does not seem to
detract from the requirement itself.

[UTM-CM.20] The Strategic Deconfliction scheme MUST be mandated by the airspace

regulator.
[UTM-SD.25] The Prioritization scheme MUST allow for preemption of operations with
lower priority by those with higher priority.

The general sense of the comments revolved

around wondering about the correct
prioritization scheme. We agree this is
important and will be better addressed by lower
level requirements. This requirement points
directly to the core principle that there is
allowance in the system for priority operations.
Other key comments pointed to the need to
bound and monitor priority announcements
such that they do not become abused resulting
in denying access to airspace to nominal
operations. We agree and think this can and
will be handled by lower level requirements.

[UTM-CM.25] The Prioritization scheme MUST allow for preemption of operations with
lower priority by those with higher priority.
[UTM-SD.30] The Prioritization scheme MUST be deterministic.

Determinism was agreeable to respondents.

Comments suggested additional requirements
would harden this requirement. We add that
given the same inputs, the results are the
deterministic. We add a requirement that the
results are the same for all USSs given the same
inputs. This should preemptively close
requirement loopholes. Some comments
suggest that there are “corner cases” that may
not fit this requirement. We argue that a well
designed prioritization (as defined in lower level
requirements) will form a strict total ordering,
though this may require certain data elements
in each operation plan.

[UTM-CM.30] The Prioritization scheme MUST be deterministically calculable by each

USS given the same operation data.

[UTM-CM.32] The Prioritization scheme MUST be equivalently calculable by each USS

given the same operation data.
[UTM-SD.35] The Prioritization scheme MUST be efficiently calculable by USSs.

This was generally well-accepted. Some

comments on how we would measure or define
“efficiently” in this requirement. This is valid to
ask. We would defer such metrics for lower level
requirements. These will likely take the form of
being proven calculable within some time on
some specific hardware as a benchmark. Then
implementations would have to prove results
for a test set of data that beat this benchmark.
Note that these results would not take into
consideration network latency. Service level
agreements on elements such as that would be
in a separate set of requirements unrelated
directly to SD. We add some text to the
requirement to align with new .30 and .32
requirement wording.

[UTM-CM.35] The Prioritization scheme MUST be efficiently calculable by each USS

given the same operation data.
[UTM-SD.37] The Prioritization scheme MUST be unilaterally calculable by USSs.

This requirement had the lowest number of “7’s”

recorded. Based on the comments, this may
have been due to some ambiguity in the
wording. We tried to address this by swapping
in “independently” for “unilaterally” and added
the same “given…” statement as in .30, .32, and
.35 above. We think this will address a good
number of the supplied comments.

[UTM-CM.37] The Prioritization scheme MUST be independently calculable by USSs

given the same operation data.
[UTM-SD.40] The Prioritization scheme SHOULD be a function of operator, operation,
airspace, and vehicle parameters.

3 of 15 respondents who left comments wanted

this to be a MUST statement. Some respondents
were concerned that there would be more
parameters in the future, another felt it should
ONLY be based on the operation and no other
parameters. As lower level requirements get
developed, this recommendation will become
more clear. This might evolve into a MUST
statement if the lower level requirements are
written clearly enough. The concern making this a
MUST statement is that it might imply that all
prioritization would require consideration of all
elements, when only one matters. Leaving this one
as-is for now with the understanding/hope that
concerns are addressed by lower level
requirements.

[UTM-CM.40] The Prioritization scheme SHOULD be a function of operator, operation,

airspace, and vehicle parameters.
[UTM-SD.45] The Negotiation scheme SHOULD minimize or eliminate direct human
interaction.

There were a number of strong opinions in the

comments. We think there was some individual
interpretation of this recommendation as written.
There is not an intention or ability for UTM to be
fully automated in all aspect upon initial
implementation of capabilities. We agree there will
be special cases were humans need to be involved
and this need may persist long into UTMs
existence. The goal still needs to be minimization
of human interaction for these operations to scale
and be efficient. We are altering the language to
make it a MUST statement and removing the
“eliminate” clause. The goal is the minimize…
eventually that may mean eliminating (for the
most part) human interaction in negotiations.

[UTM-CM.45] The Negotiation scheme MUST minimize direct human interaction.

[UTM-SD.50] The Negotiation scheme MUST be facilitated via USSs.

This was fairly well-accepted and is remaining

as-is for now. There were some comments (at least
3) as to allowing negotiation by other means. This
is not disallowed due to this requirement. This
requirement pertains to THE Negotiation scheme
as defined and required for USSs to implement.
Operators may still negotiate in traditional or
other means, there just will not be a requirement
to do so within UTM.

[UTM-CM.50] The Negotiation scheme MUST be facilitated via USSs.

[UTM-SD.55] The Negotiation scheme MUST be a finite process.

The goal of this requirement is to ensure that

negotiations between two USSs on behalf of their
operators do not continue indefinitely and that a
clear “end” is guaranteed by the automated
negotiation process.

The comments made it clear that an additional

requirement should be written that helps scope
what the negotiation scheme is intended to
accomplish. This additional requirement will be in
the final report.

This requirement remains as-is with the

assumption of a future supporting requirement
scoping negotiation more clearly.

[UTM-CM.55] The Negotiation scheme MUST be a finite process.

[UTM-SD.60] Intersecting operators, via their USSs, MUST have preceded the decision
to intersect with a negotiation process.

There was some concern as to why we want a

provision for intersecting operations at all. This is
a reasonable question. Through discussions with
stakeholders, there may be scenarios where
intersections are reasonable, assuming that
operators are aware of and assume the risks. This
avenue for potential intersecting operation
volumes also may help avoid the impression that
all of the airspace can be “reserved” or otherwise
denied for access by operators. The primary
objective, as stated in .05 is always the 4D
deconfliction of operations. As a backup, we
create the potential for intersections under the
appropriate conditions and assumption of risk. It
may be that efficiency of planning and vehicle
capabilities eventually make intersections moot.

[UTM-CM.60] Intersecting operators, via their USSs, MUST have preceded the decision
to intersect with a negotiation process.
[UTM-SD.65] Intersecting operators, via their USSs, MUST each provide explicit acknowledgement to
each other of the planned intersection of operation volumes when intersection is mutually decided.

This had broad acceptance and is left as-is. It was

noted in the comments that this requirement
really needs .60 to ensure that operators are
completely aware of other operations and have
gone through the other steps to try to eliminate
this intersection before agreeing to intersect.

[UTM-CM.65] Intersecting operators, via their USSs, MUST each provide explicit acknowledgement to
each other of the planned intersection of operation volumes when intersection is mutually decided.
[UTM-SD.70] Intersecting operators, via their USSs, MUST each provide details to each other on the
approach to a separation provision while in intersection operation volumes when intersection is
mutually decided.

Several comments on this requirement mention

Detect and Avoid (DAA) and efficient operation
planning and rules of the road as being
requirements. We agree. DAA would likely be a
component of the separation provision. Efficient
planning will be enforced in multiple ways in the
operational UTM. For example a simple forcing
function is to minimize your chances of intersecting
with anyone and to reward efficient plans in “breaking
ties” for operations that are intersecting. Rules of the
road for sUAS are potentially overly simple or overly
complex, but they will likely be part of the future
system. These (DAA, planning, rules of road) are
separate and potentially lower-level requirements
that are envisioned for the UTM System. Just a
grammar change (intersection -> intersecting).

[UTM-CM.70] Intersecting operators, via their USSs, MUST each provide details to each other on the
approach to a separation provision while in intersecting operation volumes when intersection is
mutually decided.
[UTM-SD.75] Intersecting operators, via their USSs, MUST provide acknowledgement of responsibility
and risk related to operation volume intersection whenever intersection is unilaterally decided by
that operator.

There were strong opinions in opposition to this

requirement, despite a majority of “7’s”. This response
had the highest number of responses less than 5 (13
total, while the average number of responses less than
5 was just 6.8). It also had the highest number of “1’s” in
the survey at 5.

Many on NASA UTM would also not want unilateral

decisions to intersect, given the opportunity to
encourage efficient planning and negotiation.

For now, we remove this requirement pending further

developments or discussions. This eliminates the
possibility of active, unilateral decisions for one UTM
operation to intersect with another known/ announced
UTM operation. In the future, this requirement will
likely need re-visitation.

[UTM-CM.75] Intersecting operators, via their USSs, MUST provide acknowledgement of

responsibility and risk related to operation volume intersection whenever intersection is unilaterally
decided by that operator.
 UTM Strategic Deconfliction Concept of Operations & Requirements

● A UTM Operation should be free of 4-D intersection with all other known UTM Operations prior to departure and this should be
known as “Strategic Deconfliction” within UTM. The Strategic Deconfliction scheme:
○ [UTM-CM.05] MUST have the 4-D non-intersection of operations as its primary objective.
○ [UTM-CM.10] MUST be well-documented for the understanding of operators.
○ [UTM-CM.12] MUST allow for inspection of decisions by operators upon request from operators to their supporting USS.
○ [UTM-CM.15] MUST be supported by all USSs
○ [UTM-CM.20] MUST be mandated by the airspace regulator.

● Strategic Deconfliction needs a prioritization scheme for operations within UTM. The Prioritization scheme:
○ [UTM-CM.25] MUST allow for preemption of operations with lower priority by those with higher priority.
○ [UTM-CM.30] MUST be equivalently calculable by each USS given the same operation data.
○ [UTM-CM.35] MUST be efficiently calculable by each USS given the same operation data.
○ [UTM-CM.37] MUST be independently calculable by USSs given the same operation data.
○ [UTM-CM.40] SHOULD be a function of operator, operation, airspace, and vehicle parameters.

● Strategic Deconfliction needs an allowance for negotiating deconfliction of UTM operations. The Negotiation scheme:
○ [UTM-CM.45] MUST minimize direct human interaction.
○ [UTM-CM.50] MUST be facilitated via USSs.
○ [UTM-CM.55] MUST be a finite process.

● Strategic Deconfliction needs an allowance for intersecting UTM operations. Intersecting operators, via their USSs,:
○ [UTM-CM.60] MUST have preceded the decision to intersect with a negotiation process.
○ [UTM-CM.65] MUST each provide explicit acknowledgement to each other of the planned intersection of operation
volumes when intersection is mutually decided.
○ [UTM-CM.70] MUST each provide details to each other on the approach to a separation provision while in intersecting
operation volumes when intersection is mutually decided.

Note: Requirement labels likely to change during harmonization with other documentation. Labels to be only considered for consistency within this document.
Summary
This document provides an overview of requirements developed
through a survey-based approach with stakeholders. These potential
requirements for a future operational system help define a Strategic
Deconfliction Service for UTM. From the NASA UTM Project
perspective, Strategic Deconfliction is a key layer in the conflict
management model for UTM and a core service that will be provided
by all USSs in the future UTM System.

The requirements presented have undergone an initial validation

step through survey with stakeholders working with NASA on UTM
development.

These requirements will aid in the design of Strategic Deconfliction

and will be part of a larger set of requirements that define the UTM
System, as proposed by the NASA UTM Project.
joseph.rios@nasa.gov