DUAS xx23 - Software Coding?

Initial Report

Note: this originated from AAIB report no 29959

Type of report: Accident

Aircraft Type and Registration: UAS Malloy Aeronautics T005

No & Type of Engines: 4 Electric T-Motor Engines

Year of Manufacture: 2024 (Serial no: 31)

Date & Time (UTC): 2 April 2024 at 1530 hrs

Location: White Waltham Airfield, Berkshire

Type of Flight: Experimental test flight

Persons on Board: Crew – None. Passengers – None

Injuries: Crew – N/A. Passengers – N/A

Nature of Damage: UA damaged beyond economic repair

Commander’s Licence: General line of sight certificate (GVC)

Commander’s Age: 33 years

Commander’s Flying Experience: 177 hours (of which 2 were on type). Last 90 days – 3 hours. Last 28 days – 1 hour

Information Source: Aircraft Accident Report Form submitted by the pilot and further enquiries by the AAIB

Synopsis: During a test flight to validate a flight control software update, the UA climbed and veered left. It then descended and struck two unoccupied General Aviation (GA) aircraft, coming to rest underneath the second. The UA was destroyed. The operator’s investigation identified that the UA lost control due to the software commanding more thrust than needed for level flight. Several technical, process and human performance factors contributed to the accident. The operator has taken thirteen safety actions to prevent reoccurrence.

History of the flight: A test flight was being conducted to validate a software update, which implemented visual tracking and following capability when flown in auto mode. The Remote Pilot (RP) was assisted by Command Unit Operator (CUO) and a Competent Observer (CO). The flight was being operated under the Open A3 Category. The flight was planned to take place at White Waltham Airfield, within the area (shown in white in Figure 1) designated for use as a UA site by the airfield and at least 150 m away from any buildings. After the airfield granted the operator permission for the flight, the operator’s flight team prepared the UA and conducted a team briefing and a set of pre-flight checks.

After being powered on, the UA was unable to acquire a GNSS signal, preventing a geofence, which mirrored the white area shown in Figure 1, from being applied. The RP decided to proceed with the flight on the basis that several means to activate the Flight Termination System (FTS) were available in case of an emergency. The team launched the UA and completed a short flight which validated the stabilised, alt hold and loiter flight modes. The UA was then repositioned. The RP launched the UA and, when he selected the auto mode, the UA climbed and veered left.

The RP was reported to have shouted “kill, kill, kill” and attempted to activate the FTS from his controller, which was not successful. The RP then used the backup controller to activate the FTS, which was successful. The RP and CUO then lost sight of the UA as it descended to the ground, with the CUO and CO both hearing ‘an impact with what they assumed to be one of the unoccupied GA aircraft parked outside a nearby hangar’.

Conclusion: The accident occurred because, when auto mode was activated, excessive throttle was commanded by the flight control software which caused the UA to veer to the left. The operator identified that the software commanded excess throttle because the flight model and feedback loops were inappropriately tuned. The flight team were unable to activate the FTS in a timely manner, in part because the pre-flight briefing did not sufficiently prepare them for enacting the emergency procedures, and because the software was designed to ignore FTS commands from the RP’s primary controller when in auto mode. However, the FTS did successfully activate when invoked from the backup controller. Although the RP initially refused to operate the flight when the geofence could not be applied, his decision was swayed by the fact that the geofencing is not required for Open Category flight, and because a previous T005 flight had taken place where a geofence was not used.

Safety actions: The operator has taken the following technical-related safety action:

• Replaced the throttle controller used in auto mode with a dynamic controller, to automatically adjust throttle based on measured response to throttle inputs.
• Adjusted the maximum bank, pitch and roll limits in auto mode to 30° for initial testing, which will be stepped up in 10° or 15° steps as the test programme matures.
• Modified the T005 UA control software, so that FTS messages from the primary controller are no longer ignored when in auto mode.
• Relocated the GNSS receiver to the flank of the UA, where there is less interference to GNSS signals from other equipment onboard the UA.
• Updated the pre-flight checklist to include a step requiring the RP to review the Quick Reference Handbook and emergency procedures. This includes procedures applicable to activating the FTS, specific to the UA type to be flown.
• Started to manage simulators using the MMF (Modification Management Form) change process, to ensure that the simulators and test systems appropriately represent the final product.
• Reviewed and strengthened its Emergency Response Plan.
• Retrained its flight test team regarding requirements for operation in the Open Category, with focuses including the application of geofencing and the process to obtain an exemption from the Chief Test Pilot.
• Taken steps to minimise exposure of RPs and CUOs to commercial pressures to operate a flight, including empowering RPs to conduct a risk assessment to support their decision not to fly if they feel it is not safe to do so.
• Updated the MMF to include dedicated sections for: identifying and describing the modification, assessing the change scope and operational safety impacts, and capturing the relevant stakeholder reviews and authorisation.
• Updated the MMF to clarify roles and responsibilities of stakeholders involved in the change process.
• Updated their Change Management training syllabus to capture how roles interact with the MMF, steps to be followed within the change management process, and when the MMF and CR process must be followed.
• Appointed an Aviation Lead to provide oversight of aviation operations, flight safety, risk management, operational authorisation and regulatory compliance within the company.

CHIRP Comment

The CHIRP Advisory Board had several points they thought relevant:

• Whilst we fully appreciate that this was a test flight, the Board felt that the first thing they might have done would have been to immediately switch the auto mode back off, the moment the aircraft started to unexpectedly turn left. We will never know if it would have solved the problem, but in general if you switch something on and something unexpected happens, switch it off again.
• Deciding to continue with the test in an environment where there was no GNSS signal was probably the initial human error, because it then led to a sequence of further errors. The lack of a GNSS signal and the way the crew had then determined the solution was to use the FTS, seem to have prepared the flight crew to use the FTS as a first solution to whatever problem might arise. This may be why they didn’t think of switching the auto mode back off. If a ‘Return to Home’ option had existed, it should have been the first option triggered, albeit to have been effective, the RTH would have needed to have been capable of working without the benefit of a GNSS signal.
• It looks as if as a minimum switching the auto mode back off would have enabled the FTS to work when first activated.
• Having successfully tested the Alt Hold and Loiter modes, it is possible the crew were anticipating a successful Auto Mode test and were caught a little more by surprise than they would have been for the first test.
• We note that good old commercial pressure has sneaked in as a possible contributor to this incident. In this moment of fast development funded largely by private equity who are managing return on investment timelines, commercial pressure is always going to occur. A Board of Directors that understands how to prioritise Safety and the reasons why it is so important is a necessity.
• There was a lack of technical understanding of the UAS behaviour and limitations, which should have been addressed prior to the flight taking place and been included in the OSC as it was being written.
• With only 2 hours on type, additional time behind the sticks would have been an advantage in determining the correct instant reaction when the flight started to go wrong. It is also not entirely clear that there was a test programme specific set of protocols that had been trained to.
• The flight and intended geofence areas approved by the airfield are not greater than 150m from buildings. If they had been greater than 150m from buildings, the aircraft may not have ended up damaging other parked aircraft, when the TFS was finally triggered.

Software Design issues. As a general remark regarding building software to digitise a sequence of actions, the Board observed that whilst there are many very capable coders out there, rare indeed is a coder that can write something from a user’s perspective. This just means that robust testing of “what if” scenarios on the ground needs to be undertaken before it is tested in flight. This includes good practice after a software update has been downloaded – see Safety Notice SN-2025/004. This Safety Notice recommends UAS operators and remote pilots flight test an unmanned aircraft after any [software] update or modification.