[uss_qualifier/rid] NET0470 OperatorID, UAS ID, Operator Location, Operator Altitude, Operational Status, Current Position, Height, Timestamp, Track, Speed checks

[barroco]

Following previous PRs related to NET0260,Table1,* which were checking the service provider responses, this one adds support to the mock_uss riddp for the following requirements and implements the checks of the observation harness response:

• astm.f3411.v22a.NET0470,Table1,1
• astm.f3411.v22a.NET0470,Table1,1a
• astm.f3411.v22a.NET0470,Table1,5
• astm.f3411.v22a.NET0470,Table1,7
• astm.f3411.v22a.NET0470,Table1,9
• astm.f3411.v22a.NET0470,Table1,10
• astm.f3411.v22a.NET0470,Table1,11
• astm.f3411.v22a.NET0470,Table1,14
• astm.f3411.v22a.NET0470,Table1,15
• astm.f3411.v22a.NET0470,Table1,19
• astm.f3411.v22a.NET0470,Table1,20
• astm.f3411.v22a.NET0470,Table1,23
• astm.f3411.v22a.NET0470,Table1,24
• astm.f3411.v22a.NET0470,Table1,25
• astm.f3411.v22a.NET0470,Table1,26

Note that UAS Height and Height Type are currently not injected. It will be addressed separately. Since they are optional fields fulfilling optional capacity requirements. However, the checks have already been added:

• astm.f3411.v22a.NET0470,Table1,14
• astm.f3411.v22a.NET0470,Table1,15

In addition, this PR fixes some arguments which were wrongly provided in common_dictionary_evaluator_test.py. and some improvement to the RID version handling has been made to better use the features of the monitorlib library.
Finally, monitoring.monitorlib.rid_automated_testing.observation_api has been removed and replaced by the definitions of uas_standards.

[barroco]

Needs interuss/uas_standards#12 to be released to be properly built by the CI.

[mickmis]

Here is a partial review which are mostly comments to myself as I will take over this PR from @barroco :)
Note: file monitoring/uss_qualifier/scenarios/astm/netrid/common_dictionary_evaluator.py not reviewed

[mickmis]

Note to @barroco @BenjaminPelletier : I've removed the minimum resolution checks, as if my understanding is correct, those are minimums and not exact resolution requirements. E.g. a speed of 23.63 m/s is valid, it has a resolution higher than the minimum mandated of 0.25 m/s. As such we cannot detect if a minimum resolution is not respected. Did I get this right?

[BenjaminPelletier]

Note to @barroco @BenjaminPelletier : I've removed the minimum resolution checks, as if my understanding is correct, those are minimums and not exact resolution requirements. E.g. a speed of 23.63 m/s is valid, it has a resolution higher than the minimum mandated of 0.25 m/s. As such we cannot detect if a minimum resolution is not respected. Did I get this right?

Yes, that description is correct (haven't checked code yet, but will shortly). The whole "minimum resolution" thing is weird for Network because we have plenty of data space to communicate resolution far beyond the specified minimums and systems would usually simply do this by default. It's also weird for Broadcast because the prescribed broadcast messages define exactly the resolution they carry so the standard appears to be imposing requirements on the standard in that case. We could conceivably detect someone getting this wrong by injecting 54.3 m/s and checking for the value being between 53.8-54.05 or 54.55-54.8, but seems like a very esoteric problem to have. One valuable thing is knowing that if we inject 54.3 m/s, we are sure the USS is wrong if it reports less than 54.05 or more than 54.55, but we should probably tolerate 54.2999999999999999998 m/s.