Issue with 'Current OVNs not provided for one or more OperationalIntent or Constraints'

[ron10023]

Describe the bug
When we have a few 'Contingent' Operational Intents that update each time the UAV changes position (coordinates or altitude), and we try to create a new 'Accepted / Activated' Operational Intent, we get an error message that says 'Current OVNs not provided for one or more OperationalIntent or Constraints'.

To Reproduce
Steps to reproduce the behavior:

1. Have an interval that updates 2 or more Contingent Operational Intents.
2. Create a few 'Accepted' Operational Intent and 'Activate' them.
3. Every once in a while you'll get the error message mentioned above since those flows (1 and 2) runs in parallel.

Expected behavior
The Accepted/Activated Operational Intent gets approved with the missing operational intents / constraints get returned which indicates that there is probably an airspace item that the USS is not familiar with.

Desktop (please complete the following information):

• Version 0.8.0-rc2

Additional context
In Israel we have the 'Israel National Drones Initiative' in which we use the DSS system to synchronize between 2 multiple USS systems that manage the same airspace.
Our database uses a replica set which means that there might be a synchronization when there are multiple UAVs that are flying around.
The relevant use case checks the operation of both pilot-based UAVs that are marked as 'Contingent' OperationIntent and automated delivery UAVs that fly a specific route that are marked as Accepted / Activated OperationIntent.
This synchronization issue causes the requested routes to get denied and interfere with the proper workflow.

Questions

1. Was there a reason for denying this cases?
2. Do you plan in your roadmap to handle these use cases?

Thanks

[BenjaminPelletier]

When we have a few 'Contingent' Operational Intents that update each time the UAV changes position

The general expectation is that off-nominal volumes should be added to encompass the anticipated area the aircraft will occupy -- if this area is changing on every UAV position update, it seems like that anticipation is not being performed very effectively. There is a telemetry endpoint for off-nominal operational intents that can provide information about the near-real-time position of the UAV when available, but updating the operational intent on every position update will make it difficult for other USSs to plan or react. ASTM F3548-21 does not address tactical conflicts between UAS, and updating an operational intent on every position change is essentially tactical.

we get an error message that says 'Current OVNs not provided for one or more OperationalIntent or Constraints'.

The two purposes of the DSS are Discovery and Synchronization -- that message occurs when ensuring the latter. The sequence probably looks something like this:

This error message would be delivered in message [15] because the DSS has resolved the race condition by accepting USS2's op intent 2b rather than USS1's op intent 1b, and then USS1 is responsible for getting the 2b details and evaluating conflicts against 2b (rather than 2a, which it had at the time of the race condition). This is very much as intended as the DSS is ensuring that all interactions are synchronized by ensuring that a USS trying to change the airspace knows about the current version of the airspace before they are allowed to do so. The expected resolution is simply for USS1 to obtain the updated airspace information before retrying the update of their operational intent.

Was there a reason for denying this cases?

Yes: The USS attempting to create or modify their operational intent did not indicate they were aware of the current state of the airspace which meant they might not have detected conflicts that currently exist when creating or modifying their operational intent. A "current OVN" is essentially proof of knowledge of the current version of a particular operational intent or constraint. If a current OVN is not provided for one or more operational intents or constraints, it means the USS was not aware of the current version of that operational intent or constraint when evaluating conflicts between the operational intent it wants to create or modify and other airspace features. The error message you received should also indicate exactly which operational intents and/or constraints were missing current OVNs and where the most current details can be obtained.

Expected behavior: The Accepted/Activated Operational Intent gets approved with the missing operational intents / constraints get returned which indicates that there is probably an airspace item that the USS is not familiar with.

The DSS does not approve per se, rather it synchronizes -- specifically, it disallows updates of unsynchronized changes. If an Accepted/Activated operational intent is missing operational intents/constraints, that means the operational intent is not synchronized -- the USS cannot possibly have considered all potential conflicts and therefore cannot have achieved various SCD0015-SCD0070 requirements which require a USS to verify that disallowed conflicts do not exist for transitioning or updating an operational intent.

Do you plan in your roadmap to handle these use cases?

The heart of ASTM F3548-21 is that a USS planning a coordinated operational intent must be aware of, and evaluate conflicts with, all current features in the airspace. Since requiring current OVNs is the mechanism by which the DSS achieves this and this behavior is prescribed in the standard (e.g., A2.2.13, A2.7.2(2)), InterUSS has no plans to change this behavior -- doing so would not meet the requirements of ASTM F3548-21.

[ron10023]

ASTM F3548-21 does not address tactical conflicts between UAS, and updating an operational intent on every position change is essentially tactical.

This race condition issue can occur not only with Contingent but with multiple requests for Accepted / Activated Operational Intents at the same time. It is not tactical issue but rather normal real world scenario.

[BenjaminPelletier]

Certainly I agree this race condition can occur with operational intents of many different states, and I agree it is a real world scenario. The term "tactical" I'm using here is from ASTM F3548-21:

3.2.38 Strategic Conflict Detection, n—a USS service that determines if an operational intent conflicts with other operational intents. The process of detecting conflicts by comparing operational intents. In contrast, tactical conflict detection generally relies on nonstrategic information such as current location, heading, and speed.

The opposite of "tactical" (in this usage) is "strategic". Strategy is pre-planned decision-making whereas tactical is real-time decision-making (e.g., aircraft approaching head-on should give way to the right). Strategic off-nominal volumes for a contingent operation should cover where the aircraft is expected to go:

4.3.16 Operational intents are supplemented with one or more off-nominal 4D volumes if the operational intent enters the Nonconforming or Contingent states. The intention is that these 4D volumes confidently encompass where a UAS is expected to or may travel during off-nominal situations with minimal consumption of airspace.

This is why I say if the off-nominal volumes are being updated with every position report from the UAS, those updates are essentially tactical rather than strategic where:

4.3.19 [...] the key requirement is that off-nominal 4D volumes encompass where the UAS may travel.

Separately, even if an operational intent is being updated very rapidly, the ASTM F3548-21 synchronization guarantee should still work properly. The error message you're seeing is ensuring that synchronization.

Expected behavior: The Accepted/Activated Operational Intent gets approved with the missing operational intents / constraints get returned which indicates that there is probably an airspace item that the USS is not familiar with.

If the Accepted/Activated operational intent gets approved when there is an airspace item that the USS is not familiar with, the USS is not compliant with, e.g., SCD0035 if both operational intents are of the same priority and the operational intent is attempting to be Accepted. The USS is not compliant with SCD0045 is the operational intent is attempting to transition to Activated and the other operational intent is of the same priority. See Fig 9 in ASTM F3548-21 for more cases and the specific requirements for those cases. The InterUSS DSS implementation is not intended to support USS actions that are not compliant with ASTM F3548-21.

[nasajoey]

For this question in the original post:

Do you plan in your roadmap to handle these use cases?

Just a plug that that conceptual discussions and the standard are discussed in ASTM. InterUSS works to implement things that meet and support the standards. So I wouldn't expect use cases that are not considered by the standard to be on the roadmap for InterUSS software.

Related to this:

we have a few 'Contingent' Operational Intents that update each time the UAV changes position

Also want to support Ben's overview... we've seen experiments and sims where the approach of rapidly updating strategic information in DSS causes many conceptual, interoperability, and stability problems. That is using the system in a way that it wasn't designed to be used.