RID automated testing interfaces: handling of duplicate flight IDs across SPs

[mickmis]

@BenjaminPelletier Here is a potential issue we encountered and discussed with @barroco

As we are implementing the Remote ID automated testing interfaces, we are having issue managing potential duplicate flight IDs across service providers.

More specifically, the observation harness returns through its endpoint GET /display_data/{id} the details of a specific flight (identified by {id}).
To retrieve those details, the observation harness queries the DP under test for the details of the flight.
However, because

1. the DP needs to know which SP to query for the flight details, and
2. we cannot map the flight IDs to its corresponding SP because there is no guarantee of ID uniqueness across SPs;
   we seem to encounter an issue.

Are we missing something? Was this scenario covered in the conception of the RID automated testing interfaces?

It looks like it would make sense that the observation harness through its endpoint GET /display_data returns which service area or SP the flight belongs to so that it can then be fed to the endpoint GET /display_data/{id}. At least that would make our life much easier!

Thanks a lot.

[BenjaminPelletier]

I think this brings up an important issue for RID automated testing.

We expect multiple Service Providers (SPs) and multiple Display Providers (DPs) to be tested at the same time. To do this, we will sometimes inject a flight into each SP, and then observe from each DP. This means that a we need to always be able to connect a flight observed in any particular DP with the flight injected into a particular SP.

The way we currently do this is to assume that everyone agrees on the ID for a flight -- the ID returned by the SP when the flight is injected is the same ID that every DP will report when it observes the system. I think we make this assumption even though the documentation is explicit that this is not a good assumption. In the case you mention, there is nothing that prevents two different SPs labeling their respective flights with the same ID. Moreover, it would probably make sense for a DP to provide custom IDs for flights that encode or refer to the URL from which the details for that flight can be obtained, so we doubly shouldn't expect the ID the SP assigns to a flight to be the same ID the DP reports for that flight.

I think the solution is probably to write inference logic in RID automated testing that determines which (if any) flight reported by the DP maps to which flight injected into each SP. This will probably be a little messy, but I think we have to do it to avoid imposing artificial requirements on implementing USSs.

Specifically to your point number 1 above, the DP has to keep track of information it has for flights, including the appropriate details endpoint -- it would have to do this for a Display Application also. The SP the DP should query for details about a particular flight is whichever SP the DP originally queried to discover that flight.

[mickmis]

Thank you for your answer!

I think the solution is probably to write inference logic in RID automated testing that determines which (if any) flight reported by the DP maps to which flight injected into each SP. This will probably be a little messy, but I think we have to do it to avoid imposing artificial requirements on implementing USSs.

To clarify: where would this inference logic be implemented exactly? In the test harness of the system (observation+injection)? Or in the automated test driver?

We went ahead with the following solution for the moment:

• the interface that our DP exposes for use by potential display applications + observation harness returns both the flight ID (as reported by the SP) and the service area ID in response to a list flights request
• doing so, when the DP receives a request for flight details (for which the parameters include both the flight ID and service area ID), the DP can easily find which SP has the flight given that the service area ID are guaranteed to be unique across SPs
• then from the perspective of the observation harness, given that the flight ID that is exposed does not need to be the same as the one exposed by the SP as per the openapi files, it actually exposes what we call internally an "observation flight ID" that is constructed as such: <service area ID>:<SP flight ID>
• this "observation flight ID" can then be used by the test driver to retrieve flight details through the observation harness
• the injection harness, after is has injected flights in the system, returns to the test driver this "observation flight ID", which the test driver then uses to correlate injected flights with the observed ones

This solution seems to work well in our case modulo a change in the test driver (for which we planed to do a PR soon): the test driver currently does not use the flight ID that is returned by the injection harness to correlate the injected flights with the observed ones. I made locally a fix for this so that the test driver uses the flight ID returned by the injection harness. [edit: PR interuss/dss#811 seems to be doing exactly that]

However this solution might not work well in the scenario where a flight is injected into e.g. our injection harness / SP, and then returned through another unrelated observation harness / DP: the IDs won't necessarily match.

I have the feeling that the underlying issue is the non-uniqueness of the flight IDs across the RID board, since the SPs have authority for their flight IDs. However we do have the guarantee of uniqueness for the service area IDs, thanks to the DSS. Using both the service area ID and flight ID allows to uniquely identified a flight across all systems (given that thanks to the DSS we can link back a service area to a SP). Maybe this could be taken into account in the injection and observation interfaces?

The SP the DP should query for details about a particular flight is whichever SP the DP originally queried to discover that flight.

In this scenario, because the only parameter that the DP gets is the flight ID when being queried for flight details, how is it possible for the DP to be sure which SP the flight belongs to? Sure, the probability for ID collision is low, but it exists. And what about flight details request for a flight not previously discovered by the DP? I did not see anything that make this scenario illegal. Here, if as I describe just above we have the service area ID as a parameter, we can be 100% sure.

Thank you for your help and sorry for the wall of text.