ASTM NetRID nominal behavior expects incorrect data in Service Provider Polling

[wing-utm-sharing-airspace]

Observed behavior
When running the ASTM NetRID nominal behavior scenario, our USS is failing because our service provider is populating AricraftType and UAS ID with data where the test suite expects those fields to be empty.

Example test run: 5997b1a5-ce5d-4302-9f96-4163b8cbd6bd.zip

Test check
Scenario: ASTM NetRID nominal behavior - Service Provider Polling - steps 38 and 67

Difference from expected behavior
AircraftType, UAS ID (Registration ID), UAS ID (Serial Number) appear to be populated in the injected test flight

I would expect only UAS ID (UTM ID) to fail in this test scenario when all four fields are currently marked as failures.

[the-glu]

Hello,

The test suite is using the response of the injection API to make comparison with values. If we look at the response in our case, those field are not populated:

However, on the mock_uss who pass the same test suite, those are returned as injected:

Since injection API response specify that the response is the actual data injected, I would say that wing_uss should probably be updated to return those fields with data that will be returned in flight queries.

[BenjaminPelletier]

If I understand correctly, it seems like the root issue is with the RID injection API. Specifically, it has two fields for serial number (here, here) and two fields for registration number (here, here). The problem seems to be:

1. The injection request populates data for both these fields in both places in the API
2. Wing's as-injected response only populates one sets of fields
3. uss_qualifier uses the other set of fields as the canonical set, and therefore assumes those fields were omitted from the as-injected flights
4. Wing uses the injected values in its polling response
5. uss_qualifier indicates a failed check because it believes these fields should be empty, but instead it observes them populated

There is a fix in progress for the RID injection API, but InterUSS should support the current version at least until it is officially updated. @the-glu, I think this means we should either raise an error during injection if we receive a response with inconsistent values (since we can't necessarily determine which value should be used for, e.g., serial number: EXPL3123 or [empty]), or we should make our best guess as to what value to use (I think it's very reasonable to assume that failing to populate the other redundant field fairly clearly communicates an intent to use the value of the field that was populated).

[the-glu]

Yes, that true that we tried to fix the field duplication by populating both data, but since we didn't do it on the received injected data (I was not aware that this one was used) it's not really fixed.

I propose that we do apply the same 'rules' and try to determine the best value to use on what we received in return of the injection call.

However, I think this doesn't apply to the AircraftType issue, so this one should be fixed on the wing_uss side, correct?

[the-glu]

#1006 should be fixing the UAS ID part

[BenjaminPelletier]

I propose that we do apply the same 'rules' and try to determine the best value to use on what we received in return of the injection call.

That sounds good to me -- as helpful as we can be for our users is usually best unless doing so creates undefined, unpredictable, or surprising behavior, and I think we can safely assume [specified] + [empty] almost certainly indicates the intent to provide [specified].

However, I think this doesn't apply to the AircraftType issue, so this one should be fixed on the wing_uss side, correct?

Agreed. @wing-utm-sharing-airspace, if you look at s15e2 (scenario 15 "ASTM NetRID nominal behavior", event 2), the request (from uss_qualifier) indeed specifies aircraft_type as HybridLift, but the response (from system under test) omits this field indicating that the flight effectively does not have an aircraft type as injected. The aircraft_type field should be specified in the injection response to indicate that the as-injected flight indeed has an aircraft type of HybridLift. This issue is separate from the serial & registration numbers issue, which is mainly an InterUSS issue.

[wing-utm-sharing-airspace]

Thanks for the detailed response and proposed fixes! Will make the aircraft_type update on the Wing side.