How Auterion tested
Summary of Auterion's test setup for Remote ID implemented in AuterionOS and AMC
Last updated
Summary of Auterion's test setup for Remote ID implemented in AuterionOS and AMC
Last updated
Known issue: AMC does not show a warning if the GCS position fix is lost during flight
The main reference used for our tests is the document "Standard Practice for Remote ID Means of Compliance to Federal Aviation Administration Regulation 14 CFR Part 89" published by the American Society for Testing and Materials (ASTM), which specifies the Means of Compliance (MOC) for Remote ID.
Section 8 of the MOC covers the suggested test methods. The following is not a complete reproduction of the contents of the MOC. Only the information relevant to Auterion for testing Remote ID has been summarised below, accompanied by Auterion's test results.
MOC 8.7 specifies that all but the message interval test are to be conducted outdoors and with the use of a mobile device that has a receiver app installed. In our tests we used the Android Application OpenDroneID OSM. Auterion cannot guarantee that the use of this app sufficiently validates the Remote ID.
MOC 8.6.1 - 8.6.2.4 outline a test procedure using network sniffing and inspection of the recorded network traffic to make sure, that the following criterion is fulfilled:
The maximum observed time interval between two messages of a specific type is below the threshold specified in Specification F3411.
This experiment was conducted on a bench test setup. We used Wireshark to analyze the received Wifi beacon frames with the Remote ID data.
The measurement results are based on the subsequent capture:
The pilot should see all required information of the Remote ID system and should be able to observe the data on the receiver app mentioned before.
The pilot should introduce a failure in Remote ID and verify that the vehicle rejects a takeoff command.
Step 1: The pilot should perform a take off, fly to an altitude of 10m above surface. Once airborne the Remote ID receiver application should receive and display the correct values for the required data fields, such as latitude and longitude of the operator's ground station for example.
Step 2: Fly to certain waypoints at a relative distance and altitude from the take off location. For Multirotors this is a cube spanning an altitude from 100ft (30.5m) to 200ft (61m). Fixed Wing aircraft are expected to loiter at 100ft altitude and 200ft altitude. with a loiter radius of 100ft. As in step 1 the information transmitted via Remote ID should be present and accurate during these flight maneouvers.
If the Autopilot implements emergency status', as is the case with APX4, this needs to be tested and the information received from Remote ID verified. The receiver app should show the type or name of the emergency if one is present. The test procedure should be done for all automatic and manual emergency states.
This test is specific to each vehicle and its hardware. As such Auterion did not conduct this test.
The accuracy of the vehicle's GPS is to be determined and compared to a maximum value outlined in the specifications. For this test the vehicle is to be placed on a known surveyed physical position, which is then used to compare the data from Remote ID against.
This test is specific to each vehicle and its hardware. As such Auterion did not conduct this test.
The broadcast module used for Remote ID should have an omnidirectional radiation. For this test the vehicle should be placed at a distance of 100m to the receiver device. Measurements are conducted while the vehicle is rotated at 9 degree intervals.
Induce a real or an artificial failure in one of the components that are critical for a nominal function of the vehicle. The pilot should observe the failure indication received by the Remote ID app. Critical components are defined in MOC 7.2.3 and include positioning sensors as well as transmitters for the radio link.