Update and clean up flight_planning interface

[BenjaminPelletier]

This PR cleans up the flight_planning interface and makes a few small but substantive changes.

Cleanup

Included YAML file names

scd.yaml is renamed astm_f3548v21.yaml because it is now the only place where data structures that must (always) match ASTM F3548-21 are stored -- the old "astm_f3548_21.yaml" (now renamed geotemporal.yaml) mostly had data structures that only happened to align with F3548-21 but might evolve away from those types over time.

Description improved

The overall API description is improved by adding more detail on what is conceptually expected from USSs and clients for this API.

FlightPlanID used instead of UUIDv4Format

UUIDv4Format was a data type specific to F3548-21 and there is no need to align flight plan IDs to that format, so the flight plan ID format is moved into the main YAML and named accordingly.

Enum data types defined separately rather than inline

Previously, a few enum types were defined only in the object in which that data type was used for a field. This PR breaks those definitions out explicitly to more cleanly align OpenAPI and eventual rendered Python.

AdvisoryInclusion enum values changed

Previous values of True and False were expanded to 1) more precisely describe the situation and 2) enable cleaner Python code generation (True and False are reserved Python keywords).

Wording adjustments

In many places, wording is slightly adjusted to hopefully improve clarity.

Extraneous definitions removed

A few object definitions were not used anywhere, so this PR removes them for clarity.

Version incremented

Updated to v0.3.0 to distinguish from the previous version.

Substantive changes

Single area

Basic flight plan information now only contains a single area: the flight area the user has specified. Previously, this interface was essentially expecting to the user to provide both a nominal area and an off-nominal area separately, but this seems like an unreasonable requirement to impose on all USSs (not all USSs will require their users to keep track of their previously-coordinate volumes when declaring non-conformance -- in fact, probably none will). Instead, the user will definitely indicate the relevant flight area, but the USS is exclusively responsible for keeping track of previously-deconflicted nominal volumes to satisfy ASTM F3548-21 CMSA0035.

OffNominal and Closed added to PlanningResult

(but see below here and here for an update to this approach)

Based on discussions with users and potential users of automated testing under different circumstances, this PR adds these two new planning results as potential planning outcomes. One example situation is:

An operator is flying an active flight plan (a previous planning action resulted in a ReadyToFly flight plan). The operator then declares that they are changing their volumes while the flight is still active, but those new volumes create a conflict that isn't allowed by ASTM F3548-21. Previously, there was no good result to indicate in this case. Per ASTM F3548-21, a USS performing CMSA should transition the operational intent to Nonconforming (or possibly Contingent, depending on assumptions). Once this is done by the USS, the USS shouldn't respond with ReadyToFly because the operator can't fly there nominally because there is a disallowed conflict. But, the USS also shouldn't respond with Rejected because the appropriate UTM action was successfully taken and the state of the flight has been successfully updated. The new OffNominal option is intended to address this situation -- the USS would indicate OffNominal which means that the USS recognizes the operator is flying regardless of UTM and has successfully performed the appropriate UTM actions, but the operator is not in compliance with UTM rules for nominal operations. This option covers both F3548-21 Nonconforming and Contingent operational intent states -- these two states are not broken out separately because it is unclear how a USS would necessarily be required to differentiate these situations to its operator, and uss_qualifier can easily differentiate based on the operational intent content.

The Closed option is also added to support a wider range of situations. For instance, some jurisdiction may only require UTM participation in certain areas (such as controlled airspace), and a USS may want to only manage flight plans for operators when there is a requirement to do so. In that case, if an operator updated a flight from being within controlled airspace to being entirely outside controlled airspace, the USS may properly respond by closing the flight plan as its management is no longer needed.

As an added bonus, a USS can now respond more precisely to the outcome of a user attempting to close a flight plan, which may be something other than Closed or Failed. For instance, if a jurisdiction imposes some additional requirement (like obtaining positive confirmation from a control tower) in order to nominally close a flight plan, an operator that fails to provide the necessary information to the USS could have their attempt to close the flight plan Rejected.

Execution style

The client now explicitly differentiates the user's desired style of execution between "I am doing this" (InReality), "I would like to do this if allowed" (IfAllowed), and "Would I be allowed to do this?" (Hypothetical).

Future note

Currently, the API only has the ability to perform actual user actions -- e.g., the user is actually going to use this new airspace in flight, so rejecting that planning action is not an option with UTM schemes like ASTM F3548-21 CMSA (instead, the operational intent should be represented as Nonconforming or possibly Contingent in that case). Another obvious user action not currently supported by this API is for the user to ask whether a particular planning action would be ok -- e.g., the user wants to know if they could nominally use this new airspace in flight. That capability is not currently included in the API because I do not believe it is necessary to verify compliance to any of the sets of requirements we are currently working on testing, but it is certainly a candidate for addition later.

[punamverma]

Referring to the comment in the description under section OffNominal and Closed added to PlanningResult-

“But, the USS also shouldn't respond with Rejected because the appropriate UTM action was successfully taken and the state of the flight has been successfully updated. “

If the new volumes create a conflict, the USS should respond with Rejected, as the intended flight was not allowed due to conflict. Then the operator can decide not to proceed with those new volumes, and can change to another area with no conflict. But, if user can't change the intended volumes, and has to fly there, then it should resubmit its intended BasicInformation with that area and uas_state: OffNominal. Thats when the USS should respond with PlanningResult OffNominal.

[BenjaminPelletier]

As mentioned in the "Future note" PR description, the behavior you describe certainly makes sense when an operator merely requests to do something rather than asserting they are doing something. However, I don't think it makes sense when the operator is representing what they are actually doing (rather than what they would potentially like to do if allowed).

If the new volumes create a conflict, the USS should respond with Rejected, as the intended flight was not allowed due to conflict. Then the operator can decide not to proceed with those new volumes, and can change to another area with no conflict. But, if user can't change the intended volumes, and has to fly there, then it should resubmit its intended BasicInformation with that area and uas_state: OffNominal. Thats when the USS should respond with PlanningResult OffNominal.

The rule to decide whether a planning action should be Rejected or not is certainly not whether new volumes create a conflict as many types of conflict are allowed by ASTM F3548-21. Conflicts between equal priority operational intents are allowed when permitted by regulation, conflicts between high priority operational intents and lower ones are allowed, and conflicts between off-nominal (Nonconforming and Contingent) operational intents and others are allowed. One important function a USS performing CMSA is expected to perform is to automatically transition an operational intent to Nonconforming and add off-nominal volumes when the USS detects that the aircraft has exited or is about to exit coordinated volumes (when the USS cannot or will not strategically coordinate nominally). The operator does not make an explicit request for this transition, but rather the USS performs the transition automatically for them as a core function of the USS (CMSA0115, CMSA0300, CMSA0305). The USS is also required to perform other transitions and updates automatically (CMSA0310, CMSA0315, CMSA0320).

It also doesn't make sense to require an operator to explicitly transition their own operational intent to an off-nominal state in all cases as there will be many situations where the operator is already spending all their effort dealing with the off-nominal state and therefore can't increase their workload by also explicitly transitioning their operational intent in the UTM system. There will be other situations where the root problem is that the operator does not understand or is unable to properly actuate nominal transitions in the UTM system. If we required that flights only transition to off-nominal states when explicitly requested by the operator, not only would we be non-conformant with the standard (above paragraph), but also the common off-nominal states described in this paragraph would never be communicated to other USSs (and therefore other operators).

[nasajoey]

the behavior you describe certainly makes sense when an operator merely requests to do something rather than asserting they are doing something

^^^ I think this is the key distinction. Sometimes it is difficult to express this context in a discussion and folks will have a particular idea what an operator "request" to the USS really is. "Request" I think is a holdover term from the API perspective... the operator is sending data to the USS about its operation. It's not always a "may I do this" kind of request.

[punamverma]

I agree if conflicts are allowed then it should not be Rejected. But, the said statement in description is written in context of disallowed conflict.

Once this is done by the USS, the USS shouldn't respond with ReadyToFly because the operator can't fly there nominally because there is a disallowed conflict. But, the USS also shouldn't respond with Rejected because the appropriate UTM action was successfully taken and the state of the flight has been successfully updated.

I think in that case it should be Rejected. As the spec mentions -

Rejected: The data provided in the flight plan was invalid and/or could not be used to successfully authorize the flight. The reason for rejection may include a disallowed conflict with another flight.

I agree the USS should change the state of operations to NonConforming as per the standard, whether position-based or operator-reported.

The operator does not make an explicit request for this transition, but rather the USS performs the transition automatically for them as a core function of the USS (CMSA0115, CMSA0300, CMSA0305).

In some situations, user can report to the USS about flight being OffNominal through uas_state in the spec, which USS will use to change its state to NonConforming. So, if an operator is in a situation that he has to use the Rejected intent while flying, then it can resubmit its plan with uas_state set to OffNominal. And USS will then change the state to NonConforming.

Currently, there is a "Rejected" result option provided by the API.

rejecting that planning action is not an option

Is there a plan to remove REJECTED result from the Flight Planning spec?

[BenjaminPelletier]

the behavior you describe certainly makes sense when an operator merely requests to do something rather than asserting they are doing something

^^^ I think this is the key distinction. Sometimes it is difficult to express this context in a discussion and folks will have a particular idea what an operator "request" to the USS really is. "Request" I think is a holdover term from the API perspective... the operator is sending data to the USS about its operation. It's not always a "may I do this" kind of request.

Agreed; the difference between a technical client request to a server and an operator "request" to potentially do something (as opposed to an announcement that a thing is happening) is very important -- I'll see if I can add wording to make this more explicit.

rejecting that planning action is not an option

Is there a plan to remove REJECTED result from the Flight Planning spec?

No; creating a flight plan can be Rejected, but announcing the state of reality (e.g., "my aircraft is flying here") cannot be Rejected.

It seems like perhaps two output/result states would be useful: whether the UTM action was performed successfully, and the new state of the flight plan. If an operator announced they were flying in a way that created a conflict, the UTM action would be performed successfully and the new state of the flight plan would be non-coordinated/off-nominal/etc. Attempting to plan a flight with a disallowed conflict would certainly indicate that the flight plan was not planned/created/approved, and we'd have to think about whether the UTM action was performed successfully. I'll see what I can draft.

[BenjaminPelletier]

@punamverma and @nasajoey I've updated the changes in this PR to have two results in the response. I considered what I would generally expect to happen under ASTM F3548-21 rules, and I think it would look something like the table below (illustrative, not exhaustive). Please let me know if this makes sense and addresses your concerns.

Row	Initial plan state	User intent		Situation	USS result under F3548-21
		UAS state	Usage state		Planning activity result	Final plan state
1a	N/A	Nominal	Planned	Disallowed conflict	Rejected	NotPlanned
1b		Nominal	Planned	Aspect of valid plan is unsupported by USS	NotSupported	NotPlanned
1c		Nominal	Planned	UTM system error (e.g., DSS error)	Failed	NotPlanned
1d		OffNominal	Planned	Any	Rejected	NotPlanned
1e		Contingent	Planned	Any	Rejected	NotPlanned
1f		Nominal	Planned	No disallowed conflicts	Completed	Planned
1g		Nominal	InUse	No disallowed conflicts	Completed or NotSupported	ReadyToFly
1h		Nominal	InUse	Disallowed conflict	Completed	OffNominal
1i		OffNominal	InUse	Any	Completed	OffNominal
1j		Contingent	InUse	Any	Completed	OffNominal
1k		OffNominal or Contingent	InUse	USS does not perform CMSA	NotSupported	NotPlanned
2a	Planned	Nominal	Planned	No disallowed conflicts	Completed	Planned
2b		Nominal	Planned	Disallowed conflict	Rejected	Planned or NotPlanned
2c		Nominal	InUse	No disallowed conflicts	Completed	ReadyToFly
3a	ReadyToFly	OffNominal	InUse	Any	Completed	OffNominal
3b		Contingent	InUse	Any	Completed	OffNominal
3c		Delete flight plan		Any	Completed	Closed
4a	OffNominal	Nominal	InUse	No disallowed conflicts	Completed	ReadyToFly
4b		Nominal	InUse	Disallowed conflict	Rejected	OffNominal
4c		Delete flight plan		Any	Completed	Closed
4d		Contingent	InUse	Any	Completed	OffNominal
5a	OffNominal	Nominal	InUse	Op intent is contingent	Rejected	OffNominal
5b		OffNominal	InUse		Rejected	OffNominal
5c		Contingent	InUse		Completed	OffNominal
5d		Delete flight plan			Completed	Closed

[barroco]

Few details inline. The table looks good to me.
Waiting for the discussion to converge before a final review.

[barroco]

No further comment from my side at this point. Thanks.

[BenjaminPelletier]

@punamverma or @nasajoey any other things to address before merging?

[nasajoey]

@punamverma or @nasajoey any other things to address before merging?

I honestly don't understand the qualifier interface and the interim states (Planned, ReadyToFly, etc.) required well enough to comment further. Generally I still have concerns about the allowed state machine from the standard (e.g. being able to start an operation with an initial state of non-conforming) and I haven't been able to spend time to see the implications based on the table you provided.

I won't hold this up, but I would like @punamverma to provide her take.

Thanks for checking with us!

[BenjaminPelletier]

Generally I still have concerns about the allowed state machine from the standard (e.g. being able to start an operation with an initial state of non-conforming)

I think that should be mostly orthogonal to this interface -- this interface is what allows the test director (uss_qualifier) to "actuate" a USS under test by saying something like "create a flight in the blue area described in test step 2" to the USS representative, and for the USS representative to respond appropriately (e.g., "I couldn't create that flight because the app said it was rejected"). If the state machine transition question is resolved such that transitions not prohibited by requirements are allowed, then a USS would presumably respond to the test director saying "start flying in the green area now" when there wasn't a pre-existing Accepted operational intent for the green-area flight by creating an operational intent in the Activated state, then saying {Completed, ReadyToFly} to the test director. If the state machine transition question is resolved such that transitions not shown on the diagram are prohibited, then a USS would presumably respond to the test director saying "start flying in the green area now" when there wasn't a pre-existing Accepted operational intent for the green-area flight by creating an operational in the Accepted state and then immediately transitioning to the Activated state, then saying {Completed, ReadyToFly} to the test director. The actions the USS takes to fulfill a user intent should be mostly irrelevant to the way the test director commands those user intents and the way the USS representative indicates the outcome of attempting to fulfill those user intents (and this interface is the way the test director interacts with the USS representative).

[nasajoey]

I think that should be mostly orthogonal to this interface

Agreed... that's the main reason I'm not arguing to hold this PR up. I am under the assumption that pending a standard update or clarification from ASTM folks or requirements from particular regulators, it will mostly affect the test cases and that we can probably make those work with the approach in the PR. I think that is kind of what you are saying above.

[mickmis]

Reviewing a bit late, but those changes look like good improvements, notably in terms of clarifying that the flight planning interface is meant to represent user actions.

Single area change: we are currently relying for some specific tests on being able to bring operational intents in an off-nominal state in order to test for specific situations. This means that we may loose a bit of coverage for some specific tests. I assume that even in that case it still makes sense to do this change, but it's good to keep in mind.

The split between the flight plan status and planning result makes a lot of sense as the exact meaning of the previous planning result was sometimes a bit confusing to interpret.

[mickmis]

nit: any reason why including Unknown and not just leaving the field empty in this case?

[BenjaminPelletier]

It's in an effort to be as accommodating to different tooling as possible. For instance, the problem-child of RPC tooling is Google's Protocol Buffers (protobuf) which is great when designing APIs using protobufs, but is not accommodating for many non-protobuf API design patterns. One specific proto3 "characteristic" (shortcoming? oversight? questionable design choice?) is that it is difficult to differentiate between default values and "missing", and it's difficult to actuate "omit" versus "default value". So, to maximize compatibility, a good API design practice is to specify an explicit default value that has the same effect as omitting the field. That way, tooling that prefers omitting values can do so, and tooling that prefers explicit values for all "primitive" (non-object) types can do so.

[mickmis]

Makes sense, thanks for the clarification 👍

[punamverma]

@BenjaminPelletier Thanks for adding the new fields, it clarifies the results. And, thanks for the table as well.

Sorry for my delayed response. But, I am currently not able to state that I agree with all the cases in the table, as I am looking for clarity if we have to follow the state diagram in the ASTM standard, as discussed earlier. I have requested @nasajoey, if we can get a direction from the regulators on this issue for writing our tests. So, once we get that direction, there might be changes in the results of some of the rows in the table.

Though, I wanted to check if the Final plan states correspond to the UTM states as follows -
Planned - Accepted
ReadyToFly - Activated
OffNominal - NonConforming/ Contingent
Closed - Ended

[punamverma]

Also, I am not clear how area field will be used by users. Will it be complete area of the intent that they are going to fly? Or will it be additional area that they intend to fly in next? How is that distinction going to be made?

[BenjaminPelletier]

I am currently not able to state that I agree with all the cases in the table, as I am looking for clarity if we have to follow the state diagram in the ASTM standard, as discussed earlier.

That's fine; that question is not relevant to this PR and the table is just a thought exercise for what might be expected when testing ASTM F3548-21 requirements with this interface (which is only one of many uses for this interface) -- it is merely illustrative of how the two result fields might be used (to make sure they make sense as fields) and not a prescription on how they must be used by specific tests (e.g., for ASTM F3548-21).

Though, I wanted to check if the Final plan states correspond to the UTM states as follows - Planned - Accepted ReadyToFly - Activated OffNominal - NonConforming/ Contingent Closed - Ended

For a USS implementing only ASTM F3548-21, that is the correspondence I would expect based on the descriptions of the FlightPlanStatuses in this PR and the definitions of states in ASTM F3548-21.

Also, I am not clear how area field will be used by users.

When a client of this interface (probably just uss_qualifier) wants to emulate a user performing a flight planning activity, the client will specify that the "User intends to or may fly anywhere in this entire area." This is equivalent to the user somehow indicating their relevant flight area via the USS's standard user interface.

Will it be complete area of the intent that they are going to fly? Or will it be additional area that they intend to fly in next? How is that distinction going to be made?

It will be the complete area that they intend to fly in or may fly in, as of the flight planning activity they are conducting (I don't see any mention of "additional area").

[punamverma]

Sounds good about the table being illustrative currently.

The additional area is w.r.t previously submitted area; I mentioned it to cover the cases of modifying the intent area, or providing the off_nominal_volumes in addition to the nominal volumes, in case of OffNominal as needed for UTM system. So, when a user is reporting OffNominal, it needs to tell the area it will be OffNominal in. It would want to tell the area its going to use while OffNominal, and would want to get back to Nominal area that it reported earlier, once its working nominally.
So, then user has two options. That it provides just the OffNominal area that USSes use to populate off_nominal_volumes. Or it could provide complete area that includes both nominal and OffNominal area, and then USS calculates, what part of this area is nominal volumes and what part is off_nominal_volumes. Which one is the user supposed to provide in different states is not clear from the description. If it's complete area, I think that should be mentioned in the description.
If the intention is to keep area open-ended at the moment, I think that needs to be mentioned in the description to avoid confusion about how the operator volumes need to be interpreted by the USSes. And, then the tests can take care of it.

[seungman0816]

For a USS implementing only ASTM F3548-21, that is the correspondence I would expect based on the descriptions of the FlightPlanStatuses in this PR and the definitions of states in ASTM F3548-21.

Based on the descriptions of the FlightPlanStatuses in this PR, the 'ReadyToFly' is defined as "The flight plan is ready for the operator to nominally fly within the bounds (including time) of the flight plan." It sounds like the flight plan has NOT been activated yet. If you intended to use the flight plan status 'ReadyToFly' more generally, not only for ASTM F3548-21, what's the main difference between 'Planned' and 'ReadyToFly'? What's going to be the flight plan status if the UA/UAS is already in flight? Is that still 'ReadyToFly'? It seems like the status name 'ReadyToFly' causes confusion. I would suggest changing the term to 'Inflight' or 'Activated' or something else to avoid confusion.

[BenjaminPelletier]

Which one is the user supposed to provide in different states is not clear from the description. If it's complete area, I think that should be mentioned in the description.

This API previously said that "User intends to or may fly anywhere in this entire area". I have updated to this be more specific: "The complete area in which the user intends to fly, or may fly, as known by the user. The user intends to fly, or may fly, anywhere in this entire area." If the client specified one square inch of area, I suppose it would not have been clearly technically wrong under the previous definition (the user does intend to fly there; they just also intend to fly elsewhere as well) -- the clarified definition explicitly prohibits that since it must be the complete area.

[BenjaminPelletier]

Based on the descriptions of the FlightPlanStatuses in this PR, the 'ReadyToFly' is defined as "The flight plan is ready for the operator to nominally fly within the bounds (including time) of the flight plan." It sounds like the flight plan has NOT been activated yet.

I'm not clear on why the description of "ReadyToFly" would not essentially match the ASTM definition of Activated; could you elaborate? Perhaps the confusion is coming from "Ready"? I've changed the state to "OkToFly".

If you intended to use the flight plan status 'ReadyToFly' more generally, not only for ASTM F3548-21, what's the main difference between 'Planned' and 'ReadyToFly'?

Could you elaborate on the confusion? The Planned FlightPlanStatus is documented that "the user may not yet start flying" while the ReadyToFly was "ready for the user to nominally fly". So, the difference is whether the user is allowed to cause their aircraft to enter the air (fly).

It seems like the status name 'ReadyToFly' causes confusion. I would suggest changing the term to 'Inflight' or 'Activated' or something else to avoid confusion.

Inflight seems like a good description of the state of a UAS, but FlightPlanStatus describes the status of a flight plan rather than a UAS and flight plans don't fly. Also, we expect to enter this state before the aircraft is in flight, so it can't be referring to the state of the UAS associated with the plan either. Activated isn't wrong, but we would need to provide a definition that doesn't beg the question of what "activation" means -- I'm open to this change if we can create such a definition, but since this API is intended to be UTM-procedures-agnostic, deconflicting from the specific definition of the Activated operational intent state in ASTM F3548-21 seems useful to avoid confusion. The previous definition was "The flight plan is ready for the user to nominally fly within the bounds (including time) of the flight plan." (emphasis addded) which seems to summarize nicely to ReadyToFly.

[seungmanlee-nasa]

Could you elaborate on the confusion? The Planned FlightPlanStatus is documented that "the user may not yet start flying" while the ReadyToFly was "ready for the user to nominally fly". So, the difference is whether the user is allowed to cause their aircraft to enter the air (fly).

Now, I know where I was confused. I thought the Planned status meant that "the user MAY ALSO start flying" in the Planned status, which means you're also ready to fly. But it seems like you're NOT PERMITTED/ALLOWED to start flying in the 'Planned' status unless the flight plan is in the 'ReadyToFly' or 'OkToFly'. Is that correct? Thanks!

[BenjaminPelletier]

it seems like you're NOT PERMITTED/ALLOWED to start flying in the 'Planned' status unless the flight plan is in the 'ReadyToFly' or 'OkToFly'. Is that correct? Thanks!

Yes, exactly -- the user may not yet start flying when the FlightPlanStatus is Planned, but they may start flying (in the time bounds of the plan) when the FlightPlanStatus is OkToFly.

[seungmanlee-nasa]

Yes, exactly -- the user may not yet start flying when the FlightPlanStatus is Planned, but they may start flying (in the time bounds of the plan) when the FlightPlanStatus is OkToFly.

Then that means the user should NOT request for 'Nominal' UAS state and 'InUse' Usage state when the FlightPlanStatus is 'Planned' (2c in the above table) until you get the 'OkToFly' flight plan status change notification from the USS. Is that right? So, what should the USS do if the user starts flying even when the FlightPlanStatus is Planned? I think the USS cannot just change the flight plan status to 'OkToFly' in that case. Am I still missing something?

[BenjaminPelletier]

Yes, exactly -- the user may not yet start flying when the FlightPlanStatus is Planned, but they may start flying (in the time bounds of the plan) when the FlightPlanStatus is OkToFly.

Then that means the user should NOT request for 'Nominal' UAS state and 'InUse' Usage state when the FlightPlanStatus is 'Planned' (2c in the above table) until you get the 'OkToFly' flight plan status change notification from the USS. Is that right? So, what should the USS do if the user starts flying even when the FlightPlanStatus is Planned?

If the FlightPlanStatus is currently Planned and the user communicates to the managing USS their intent to commence flight operations within the coordinated operational intent (indicates Nominal UAS state + InUse usage state), I would expect the USS to indicate Completed for that planning action with a resulting FlightPlanStatus of OkToFly (row 2c in the above table) when there are no conflicts.

I think the USS cannot just change the flight plan status to 'OkToFly' in that case. Am I still missing something?

The USS cannot just change the flight plan status to OkToFly when complying with ASTM F3548-21; instead, they would transition the operational intent state to Activated and then indicate that the flight plan status is now OkToFly.

But, I think this raises an important issue. Per "Future note" of the description, the current API is merely targeting "I am doing this" and not (yet) "Would I be allowed to do this?", nor "I would like to do this if allowed". I was previously thinking we could hit most test points with just "I am doing this" without needing "Would I be allowed to do this?", and I hadn't really considered "I would like to do this if allowed". For instance, with no conflicts, "I am now flying here" with a pre-existing Planned flight plan would simply transition that flight plan to OkToFly after transitioning the F3548 operational intent to Activated. But, this paradigm actually doesn't work as intended in the presence of conflicts. If there is a Planned flight plan and a new conflict has been created in the meantime (e.g., higher-priority operational intent), "I am now flying here" would force a CMSA USS to transition the F3548 operational intent to Nonconforming since the USS would be unable to establish a coordinated operational intent covering the user's flight area. That's not usually what operators would want -- they would want to essentially obtain clearance to take off, or "I would like to do this if allowed". So, I'm pretty sure I was wrong that we could perform necessary F3548 tests with just "I am doing this".

I've added 7eb6389 as a draft of distinguishing between "I am doing this" (InReality), "I would like to do this if allowed" (IfAllowed), and "Would I be allowed to do this?" (Hypothetical) under the name "execution style". Please take a look and let me know if you have any suggestions as this is the first draft of a new concept as of just now (terminology, wording, and substance suggestions welcome). @punamverma @mickmis and @barroco also. I don't think we strictly need Hypothetical, but it seems reasonable to include it if only to make it clear what the other two options aren't.

Thanks for the review -- I don't think this PR would have had a good outcome without addressing this issue in some way.

[BenjaminPelletier]

Note: merging this PR does not promote the API version to 1.x.x -- it is still in 0.x.x. So, while I think the immediate comments in this PR have been addressed, we should be able to fairly easily create another PR in the future to address anything that is outstanding.