Operations that continue flying past end_time cannot be updated to Non-Conforming

[sjurcak]

Describe the bug
If an otherwise-conforming operation continues to fly past its end_time, the USS will submit a request to update the state to Non-Conforming. The request will contain the entire operation data, including an end_time in the past, which will illicit a 400 "OperationalIntents may not end in the past" response from DSS. Thus, vehicles that keep flying after the scheduled end of their operations will remain permanently conforming until they close.

To Reproduce
Steps to reproduce the behavior:

1. Submit and Activate an operation. Keep the operation in the conforming state.
2. Allow the operation's end_time to pass. Do not close the operation.
3. The USS will submit an UpdateOperationParameters to change the state to Non-Conforming.
4. See the 400 response from DSS due to invalid end_time, with a message containing "OperationalIntents may not end in the past".

Expected behavior
I would expect under these circumstances that the operation would be marked as Non-Conforming and that the offending USS would be expected to issue alerts as required and remedy the situation.

Desktop (please complete the following information):

• OS: iOS

Additional context
I think that the DSS is adhering correctly to the spec, but that the spec itself does not account for this off-nominal scenario.

[BenjaminPelletier]

The request will contain the entire operation data, including an end_time in the past, which will illicit a 400 "OperationalIntents may not end in the past" response from DSS.

The USS issuing this request does not appear to be compliant with ASTM F3548-21 CMSA0300 which requires the USS to "add one or more off-nominal 4D volumes to the operational intent to encompass the area and time of anticipated nonconformance". Since the USS is aware the operation is still active at the current time and the volumes of the operational intent do not encompass the current time, this requirement has not been met. The InterUSS implementation of the DSS defined in ASTM F3548-21 generally does not support USS actions that are not compliant with ASTM F3548-21.

See also 5.6.1.8, 4.4.4.3, and 4.3.16-4.3.18.

[nasajoey]

Just so I'm tracking, I want to read that back... it sounds like in Step 3 above, if there are appropriate off-nominal volumes included in that update (encompassing the non-conforming behavior of flying around after the end time of the strategically coordinated intent), the expectation is that DSS will provide an appropriate 20X response. Do I have it straight, @BenjaminPelletier ?

Follow-on point: since this is a CMSA requirement, a USS looking to provide SCD would not even need to implement this behavior at all. An operator flying without a CMSA provider could be flying around longer than intended and the SCD USS is not required to notify anyone because it isn't assumed that the USS knows anything about the state of the operation if not told by the operator. Does that sound correct as well? Assuming this is a correct reading, I'm guessing there are several other such non-conforming examples.

A couple of notes that I'll try to capture later for ASTM discussion: Many CMSA requirements (like CMSA0300) are compound, with several "and" statements. I think we will need to revisit those and ensure there are independently testable, singular requirements in the spec. Like breaking down CMSA0300 into 0301, 0302, 0303, etc.

[nasajoey]

Just catching back up with the standard. Based on:

5.4.2.20 A managing USS shall (SCD0100) only transition an operational intent to the Nonconforming and Contingent states if it is also serving the role of CMSA.

If there is no CMSA, then there seems to be no way to ever get to NC or Contingent.

[BenjaminPelletier]

it sounds like in Step 3 above, if there are appropriate off-nominal volumes included in that update (encompassing the non-conforming behavior of flying around after the end time of the strategically coordinated intent), the expectation is that DSS will provide an appropriate 20X response.

Yes.

since this is a CMSA requirement, a USS looking to provide SCD would not even need to implement this behavior at all.

Correct.

An operator flying without a CMSA provider could be flying around longer than intended and the SCD USS is not required to notify anyone because it isn't assumed that the USS knows anything about the state of the operation if not told by the operator.

Mostly correct, though a USS performing the strategic coordination role (SCD + aggregate operational intent conformance monitoring) will track that past-end-of-intent non-conformance in the long run, just perhaps not in real-time. For instance, the flight logs might be downloaded from the aircraft after landing and then used in AOICM. AOICM has requirements regarding verification of non-conformance rate and notifications when conformance requirements aren't met.

Many CMSA requirements (like CMSA0300) are compound, with several "and" statements. I think we will need to revisit those and ensure there are independently testable, singular requirements in the spec. Like breaking down CMSA0300 into 0301, 0302, 0303, etc.

Agreed; we often break down requirements into testable subcomponents -- see our list of F3411-22a requirements for some examples (commas are used for separators because periods have a reserved purpose).

If there is no CMSA, then there seems to be no way to ever get to NC or Contingent.

Correct, in terms of communication to other USSs. There is a way to detect systematically-nonconformant flight planning through AOICM (requirements ACMxxxx).

[nasajoey]

So, @sjurcak , if this doesn't sound like a bug anymore, probably OK to close this out? Or is there an open question still?