scenarios.astm.utm.FlightIntentValidation tries to plan flight in the past as valid flight

[AlexanderZellober]

Observed behavior
During the scenario scenarios.astm.utm.FlightIntentValidation the Qualifier tries to plan a valid flight that happens to start in the past.

report.zip
sequence.zip

Test check
"First failed_check"

Difference from expected behavior
The planned flight should start in the future, not in the past.

[BenjaminPelletier]

Asking for a flight that starts in the past is not an inherently invalid operation, so strictly speaking this is probably an issue in the test configuration if the intent of the test designer is to never ask participants to plan flights starting in the past. (E.g., there could potentially be an expectation that participants would truncate requested start time to now)

However, InterUSS's CI test configurations are often used as examples/templates for users to create their own test configurations, so we should make them as broadly-applicable as practical. In this case, that means we shouldn't ask for flights that start in the past. So, InterUSS should adjust the "standard flight intents" it defines accordingly.

[BenjaminPelletier]

@AlexanderZellober how would you envision tests working ideally? A test designer could ensure that a Planned flight is planned for a time in the future, but then when uss_qualifier goes to activate that flight, it would either have to change the time bounds when activating (a feature that some USSs do not support), or else wait until the start time arrived to activate (introducing additional testing delay). Would it be unreasonable to ask and expect a USS to respond to a request to plan a flight starting in the past by planning as requested, except truncating all start times to now?

[AlexanderZellober]

About this Bug:

In this particular case the StartTime during Planning being in the past happend because of a Problem with Windows OS.
I am using the WSL to run the Qualifier-Tests and Windows has a Problem where espacially if the PC goes to sleep the Clock of the Linux-Distro in the WSL and the Host System can get out of sync.
Here the WSL lagged behind by about 15 seconds which resulted in the Qualifier tyring to plan a flight starting some time in the past.

To your Question:
Activating a flight that has a startTime in the past should not be a problem for a USSP, since in the real world there can always be some delays that impact the actual start of the flight.
If the flight cannot be activated because an operator missed the start window by a few seconds, it would be problematic.
The planning however should always have a startTime that happens in the future.

[BenjaminPelletier]

Here's the challenge:

If a USS:

1. Refuses to plan a flight with a start time in the past, and
2. Will not truncate the requested in-the-past start time to the current time, and
3. Cannot activate a flight prior to the flight's start time

...then we have a dilemma. At t0, we must pick t_start (the start time of Flight 1) such that it is later than tmin (the time at which the USS receives the planning request), yet earlier than tmax (the time at which the USS receives the activation request). If t_start is too small, then the USS will complain about the start time of the planned flight being in the past (our current problem). But, if t_start is too big, then the USS will complain about the start time of the activated flight being in the future, or else uss_qualifier will have to stop and wait for t_start to arrive before continuing with the test. The problem is that we don't know how long after t0 tmin will be since we can't control the transit time of the API message, and we can't control the USS's processing time for the message.

It seems like the best solution to this problem would be to enable uss_qualifier to say "plan a flight that starts basically right now, or as soon in the future as you will allow me to plan". The ability to make such a request would resolve the problem of not knowing how to synchronize "nows" between uss_qualifier and the USS. Would you support the expectation that the USS test bridge support such a capability, perhaps expressed by omitting the start time for one or more volumes? If so, would it be reasonable to also expect the USS test bridge to exercise that capability whenever a planned flight had a start time earlier than now? In that case, I would expect the USS to indicate success, but truncate the start time(s) of the volume(s) to the time at which the request was processed, and this would be reflected in (e.g.,) the flight volumes of the operational intent uss_qualifier queries just after the planning request completes.

[ereiswich]

"It seems like the best solution to this problem would be to enable uss_qualifier to say "plan a flight that starts basically right now, or as soon in the future as you will allow me to plan".

That sounds like a good suggestion. In our system, there are various rules governing how we handle flight requests in terms of time. E.g. we do not allow flights in the past to prevent people from obtaining retroactive authorizations. We also have a buffer of approximately 5 seconds to prevent flights from ending up in the past during processing. So it would be helpful if the qualifier were left to us to decide how to inject flights into our system so that they are timed correctly.