The investigation

Decisions regarding the scope of an investigation are based on many factors, including the level of safety benefit likely to be obtained from an investigation and the associated resources required. For this occurrence, a limited-scope investigation was conducted in order to produce a short investigation report, and allow for greater industry awareness of findings that affect safety and potential learning opportunities.

The occurrence

On 21 July 2023, a Piper Aircraft PA-31-350, registered VH-XMM and operated by AirLink, taxied at Essendon Fields Airport, Victoria for a departure to Bankstown, New South Wales. The pilot was the only person on board and was conducting a freight charter flight under the instrument flight rules.

At 0109 local time, VH-XMM taxied from the southern apron where they had been parked, with the airport lighting energised. The pilot contacted Melbourne Centre air traffic control (ATC) and relayed their taxi intentions, to which the controller responded asking if they could accept runway 26[1] for departure. The pilot accepted and over the next 10 minutes taxied the aircraft via taxiway Papa and November, crossing runway 17, (Figure 1). They completed their pre-departure checklists, engine run-up checks[2] and obtained an airways clearance during the taxi. After they arrived at the holding point of runway 26, the pilot reported ready for departure and received departure instructions from the controller.

Figure 1: Aircraft taxi route

Source: Airservices Australia, annotated by the ATSB

As they entered the runway, the pilot completed the departure flight logs, read back the departure instructions to ATC and conducted the line-up checklist. After they commenced the take-off run, they heard multiple loud noises and, in response, rejected the take-off at 77 kt by closing the throttles and applying the brakes. As the aircraft’s speed reduced, the pilot felt abnormal braking pressure on the right main landing gear. The aircraft subsequently veered to the left side of the runway and the pilot continued the aircraft‑induced left turn to complete a full 360° turn before exiting the runway at taxiway Hotel. The pilot contacted the controller at 0122 and advised that they were vacating the runway and cancelled their departure instructions. The aircraft was returned to the southern apron for further inspection.

On inspection of the aircraft, the pilot determined that the right main landing gear brake caliper was leaking fluid and a cut in the tyre was observed. The pilot sought the advice of a senior base pilot who was on site at the time however, it was not clear at this time exactly how the aircraft came to be damaged. The pilot entered a defect into the aircraft maintenance release and arranged another aircraft to complete the flight.

During a subsequent inspection of the runway, damage to multiple runway lights was detected and foreign object debris was found scattered across the runway.

Figure 2: Damaged runway lights

Source: Airport operator, annotated by the ATSB

Context

Pilot experience

The pilot attained their commercial pilot licence (aeroplane) in 2018 and completed a satisfactory instrument proficiency check on a multi engine aircraft in January 2023. Both a line check and proficiency check for Airlink were completed on 21 July 2022, where the pilot was assessed as competent for charter and regular public transport flights.

At the time of the incident, the pilot had 1,540 total flight hours and 532 hours on Piper PA-31-350 type aircraft, with approximately 400 hours accrued at night.

Fatigue

The Melbourne‑based pilot routinely flew the night sector between Essendon and Bankstown. They had conducted a similar flight on the previous night where they had encountered a mechanical issue on the aircraft they were flying. A replacement aircraft could not be found and therefore the duty period had ended in Bankstown. A rest period away from base was utilised where the pilot received 6 hours of sleep. The pilot awoke at 0630 the following day and repositioned via a commercial flight to Melbourne. Due to the pilot’s late-night roster, their normal wake-up time was around 1000.

After arriving in Melbourne, the pilot was provided with an off-duty period of 12 hours between 1130 and 2330 however, they were discussing weather conditions with the company for the upcoming flight and advised they received 1-hour of sleep during this period.

Initially the pilot advised they did not feel fatigued during the incident flight, however after the pilot reviewed their disrupted sleep pattern and the discussion held during their off-duty period they reported that they considered fatigue was a contributing factor.

Aircraft information

VH-XMM is a Piper Aircraft Corporation PA-31-350 type aircraft fitted with 2 Textron Lycoming TIO-540-J2BD piston engines, each driving a 3‑bladed Hartzell propellor. The aircraft was manufactured in the United States in 1979 and issued serial number 31-8052020. VH-XMM was first registered in Australia in 1986 and Airlink became the registered operator in July 2021.  

After the occurrence, the aircraft was inspected by engineers. Further damage was found to the main fuselage which was consistent with the aircraft striking the runway lights (Figure 3).

Figure 3: Damaged sustained by VH-XMM

Source:  Airport operator

Aerodrome information

The airport lighting was energised without interruption during the course of the aircraft’s taxi out, take-off run, aborted take-off and return taxi until after shut-down. The airport lighting de-energised at 0129.

The airport is equipped with green taxiway centreline lighting and runway 26 has a lit lead in taxi line with painted yellow markings. The runway edge lighting provided for runway 26 includes medium and high intensity lighting at 58 metre intervals along the runway edge (Figure 4).

Figure 4: Runway 26 lights and markings

Source: Google earth, annotated by ATSB

The aerodrome inspection carried out on the evening prior to the incident, did not note any defects or damage to the airport lighting system.

The airport operator provided the ATSB with ADS-B movement data which showed the position of the aircraft, and further ADS-B data was obtained from publicly‑available, third-party websites (Figure 5).

Figure 5: VH-XMM take-off path with damaged light positions

Source: Google earth, annotated by ATSB

Standard operating procedures

As the pilot was lining up, they were also completing the line-up checklist. The Airlink standard operating procedure was for pilots to complete the checklist from memory via a flow method and then confirm by referring to a checklist. The line-up checklist required the pilot’s attention to ensure the correct position of multiple items. Figure 6 shows the required checklist flow of an exemplar aircraft, which highlighted the pilot’s attention being drawn from outside the aircraft into the cockpit to identify and confirm specific switches. In addition to the checklist, the pilot also reported checking the extended runway 26 approach for traffic.

Figure 6: Exemplar aircraft showing the line-up checklist flow

Source: File:Piper PA-31-350 Navajo N828KT cockpit (29890802667).jpg - Wikimedia Commons, annotated by the ATSB

CCTV footage

CCTV footage showing the runway was obtained to confirm if the runway lights were energised during the take-off. From the footage, an aircraft could be seen conducting a take-off run from runway 26 at 0119 and during the take-off, one of the runway lights extinguished as the aircraft passed over it.

Figure 7: CCTV before and after take-off run

Source: Airport operator, annotated by the ATSB

Safety analysis

The pilot of VH-XMM was conducting a flight from Essendon to Bankstown and taxied to runway 26. Recorded position data from the aircraft confirmed that the aircraft was aligned with the runway edge lighting during the line-up.

CCTV footage confirmed that the aerodrome lights were energised and an aircraft was observed to conduct a take-off run along runway 26 at the time of VH‑XMM’s departure. As the aircraft moved along the northern runway edge lights were observed to extinguish. In addition, after the aircraft returned to the apron, the damage was detected, which was consistent with striking the runway lights.

During the interview, the pilot confirmed that while entering the runway, they checked the runway approach for traffic, filled out flight departure times and confirmed the line-up checklist was completed by using a physical checklist. These actions diverted the pilot’s attention from outside into the cockpit. In addition to the refocusing of attention, the pilot also advised that runway 26 was not a frequently used runway for operations. A combination of the high workload, unfamiliarity with the runway and night operations increased the risk of runway misalignment.

Due to the time of the occurrence and pilot’s belief that fatigue was a contributing factor, the ATSB conducted an analysis of the pilot’s fatigue level. This analysis showed that, based on the information known in relation to the pilot’s previous sleep and work roster, it is unlikely that the pilot was experiencing a level of fatigue known to have an effect on performance at the time of the incident.

Findings

From the evidence available, the following findings are made with respect to the misaligned take‑off involving Piper PA-31-350 VH-XMM at Essendon Fields Airport, Victoria on 21 July 2023.

Contributing factors

• The pilot had a high workload during runway line up and subsequently aligned the aircraft with the northern edge lighting, resulting in minor damage during the take‑off run.

Safety action

Airlink advised the ATSB of the following proactive safety action, involving reviews of the:

• fatigue management of aircrew conducting night operations, including setting mandatory ‘out of contact’ hours
• night proficiency checks for pilots and how regularly these occur
• airport familiarisation process for pilots conducting night operations, including developing a clear procedure on aspects to be considered when inducting aircrew at new ports
• current simulator set up to determine the potential for simulator training and checks to support practical assessment, including night checks
• fatigue management plan to identify areas of improvement for night flights and variances against Civil Aviation Safety Authority Civil Aviation Order 48.1 regulations.

Sources and submissions

Sources of information

The sources of information during the investigation included the:

• pilot and operator
• Airservices Australia.
• Essendon Field Airport operator.
• CCTV footage of the incident flight.
• recorded data from the aircraft.
• Airlink Standard Operating Procedures
• PA-31-350 pilot operating handbook

Submissions

Under section 26 of the Transport Safety Investigation Act 2003, the ATSB may provide a draft report, on a confidential basis, to any person whom the ATSB considers appropriate. That section allows a person receiving a draft report to make submissions to the ATSB about the draft report.

A draft of this report was provided to the following directly involved parties:

• pilot in command
• Airlink
• Civil Aviation Safety Authority

A submission was received from:

• pilot in command

The submission was reviewed and, where considered appropriate, the text of the report was amended accordingly.

Purpose of safety investigations The objective of a safety investigation is to enhance transport safety. This is done through: identifying safety issues and facilitating safety action to address those issues providing information about occurrences and their associated safety factors to facilitate learning within the transport industry. It is not a function of the ATSB to apportion blame or provide a means for determining liability. At the same time, an investigation report must include factual material of sufficient weight to support the analysis and findings. At all times the ATSB endeavours to balance the use of material that could imply adverse comment with the need to properly explain what happened, and why, in a fair and unbiased manner. The ATSB does not investigate for the purpose of taking administrative, regulatory or criminal action. Terminology An explanation of terminology used in ATSB investigation reports is available here. This includes terms such as occurrence, contributing factor, other factor that increased risk, and safety issue. Publishing information Released in accordance with section 25 of the Transport Safety Investigation Act 2003 Published by: Australian Transport Safety Bureau © Commonwealth of Australia 2023 Ownership of intellectual property rights in this publication Unless otherwise noted, copyright (and any other intellectual property rights, if any) in this report publication is owned by the Commonwealth of Australia. Creative Commons licence With the exception of the Coat of Arms, ATSB logo, and photos and graphics in which a third party holds copyright, this publication is licensed under a Creative Commons Attribution 3.0 Australia licence. Creative Commons Attribution 3.0 Australia Licence is a standard form licence agreement that allows you to copy, distribute, transmit and adapt this publication provided that you attribute the work. The ATSB’s preference is that you attribute this publication (and any material sourced from it) using the following wording: Source: Australian Transport Safety Bureau Copyright in material obtained from other agencies, private individuals or organisations, belongs to those agencies, individuals or organisations. Where you wish to use their material, you will need to contact them directly.

Investigation summary

What happened

On the evening of 14 July 2023 an aerial light display was scheduled to be conducted over the waters of Victoria Harbour, Docklands, Victoria using a swarm of 500 Damoda Newton V2.2 remotely piloted aircraft (RPA). 

At 1830 the Remote Pilot in Command (RPIC) launched the swarm. Shortly after, the RPIC identified both visually and from multiple errors on the ground control station (GCS) computer, that multiple aircraft were out of position. 

Despite this, the aircraft automatically commenced the transition from the launch location towards the show area. As the aircraft transitioned, further errors with increasing severity appeared on the GCS computer. Aircraft were observed to be out of position and colliding in the air, with multiple aircraft breaching the geofence.

As the errors cascaded, the RPIC commanded the aircraft in the swarm to loiter (hold position) and attempted to return those with the most significant errors to the launch site individually. Whilst multiple aircraft were in the loiter, the GCS computer lost connection to almost 400, with the majority descending into the harbour below.

427 of the 500 aircraft in the swarm were lost into the water, with divers subsequently recovering 236.

What the ATSB found

The ATSB determined that shortly after launch, the swarm encountered wind conditions that exceeded the aircraft’s published capability. That was not identified by the RPIC as they were unaware that the wind speed affecting the aircraft was displayed on the GCS computer. Additionally, while the GCS computer displayed the wind speed, it did not have the functionality to actively alert the pilot to exceedances.

Consequently, the RPIC allowed the flight to continue toward the show area, where wind speeds more than twice the published limit were encountered. In these conditions the aircraft were unable to maintain position, resulting in aircraft collisions, breaches of the operating area, and activation of failsafe modes that led to most of them descending to the water.

The RPIC did not make use of all processes available to them to collect relevant wind information prior to launching the swarm. There were also a number of factors on the day that caused the RPIC to have a higher than normal workload that affected their decision‑making capacity, and was likely to be under pressure to conduct the show. It was also found that the operator had no procedure in place to verify that pilots were familiar with all relevant functions of the GCS software. 

Finally, while not contributory to the accident, the investigation also identified that the flight crew did not comply with operational limitations set by the regulator and contained within their own documentation.

What has been done as a result

Operator

The operator advised that in response to this accident it undertook a detailed review of its operating procedures and made several changes, including:

• changes to the crewing requirements to have 2 Civil Aviation Safety Authority‑approved pilots operating every show
• introduction of wind speed test flights using individual aircraft prior to show launch to establish actual conditions in the show area
• establishment of multiple go/no-go points during the launch sequence allowing for more clearly defined stop points
• introduction of sterile cockpit procedures to limit outside interactions with the flight crew in critical phases in the lead‑up to show launch.

Additionally, the ATSB issued a safety recommendation that the operator develops a process to ensure that future software changes are communicated and understood by all pilots before commencing operations.

Manufacturer

The manufacturer advised that updating the ground control station software to include an active alert for wind speed exceedances was technically possible and that this feature was being considered for future software releases. The ATSB issued a safety recommendation to the manufacturer that such alerting be implemented.

Safety message

In Remotely Piloted Aircraft System (RPAS) swarm operations the flight crew are highly dependent on the ground control station software, its functionality and the data it provides for safe operation. It is therefore critical that the flight crew be familiar with all functionalities and understand the information being presented to them. Functionality that actively alerts crew to exceedances in flight‑critical parameters can assist crew awareness.

Operators should have systems in place to ensure that pilots are familiar with new functionality when introduced. To assist flight crews, operators should ensure that operational documentation, including checklists, carry the relevant prompts for flight crews to gather all necessary information to assist their decision‑making processes.

Additionally, the impact of human factors on RPAS operations should be actively considered and managed. While the risk profile may differ from that of crewed operations, factors such as workload and operational pressure can equally impact RPAS operations. 

As RPAS operations continue to rapidly develop and diversify, compliance with operational guidelines and limitations set or approved by the regulator are critically important to minimise risk to both the operation and the public. This is particularly important where RPAS are being operated in higher risk environments, such as public displays in built‑up areas.

Summary video

The occurrence

Test flight

Late in the evening of 13 July 2023, the Remote Pilot in Command (RPIC) and copilot of a Damoda Newton V2.2 Remotely Piloted Aircraft (RPA) swarm operated by the Australian Traffic Network Pty Limited (ATN) arrived at a pre-arranged launch site on North Wharf at Docklands, Melbourne, Victoria (Figure 1). They were to conduct a limited test of a swarm RPA display (drone show) which was to take place the following evening in support of a sporting event at the Docklands Stadium. 

Figure 1: Operational area and launch site

Source: Google Earth, annotated by the ATSB

The RPIC and copilot set out 10 aircraft [1] on the launch site and prepared the ground control station (GCS) to test the show program. The primary function of the flight was to test for potential interference from the launch site and the surrounding area. Shortly before the launch time, the RPIC identified that the wind conditions were well above the 15.6 kt limit that the aircraft could safely operate in and the test was downscaled to a hover test. The hover test involved 10 aircraft launching to a height of 10 m and hovering for a short time before landing. 

The hover test was successfully completed with the GCS system recording minimal interference from the launch site. However, the RPIC reported that as part of this process the launch location programmed for the show was identified to be incorrect and that this location needed to be updated before the show the following evening.

Flight preparation

At approximately 1400 local time on 14 July 2023 the RPIC and copilot returned to the launch site to prepare for the show that was scheduled for 1830. On surveying the intended operating area, the RPIC identified that the mast of a boat moored on the wharf directly adjacent to the launch area was an obstacle for the swarm as it transitioned from the launch area to the show area. The mast was measured at approximately 15 metres tall, requiring the height of the swarm’s transition between the launch and the show to be increased.

Shortly after arriving, the copilot and RPIC were met onsite by 4 members of the show support crew. A fifth member, who was to assist in setting up and conducting safety checks on the 500 aircraft, was late. Following launch, the support crew were to monitor the exclusion zone [2] surrounding the show area for intruders.

The RPIC briefed the crew on several topics, including the operational plan for the display, the requirements for the launch grid and setting up the aircraft. The support crew then commenced setting out the launch grid and aircraft as per the show plan. The RPIC recalled that setting out the aircraft took slightly longer than anticipated due to the wind interfering with the process of measuring out the grid. During the set‑up the RPIC took multiple ground level wind readings with a handheld anemometer. The pilot recalled that these readings were returning 8‍–‍10 kt of sustained wind, with frequent gusts up to 12 kt. 

Throughout the set‑up the RPIC was interrupted on multiple occasions by tasks normally assigned to the copilot. This included:

• additional briefings to support personnel
• multiple interactions with the client who wanted to confirm whether the show would be able to go ahead in the prevailing conditions
• interactions with other stakeholders and senior management of the operator’s company who were in attendance to view the show.

Setting up the grid took approximately 2 hours, after which the RPIC gave the support crew a 30‑minute break while they completed a walkthrough of the grid to ensure that the location and identification of each aircraft aligned with the set‑up plan. 

At 1740, the RPIC started screen recording on the ground control station (GCS) computer. This recorded all activity on the screen of the GCS computer and audio within range of the computer’s microphone (see the section titled Ground Control Station). 

Throughout the 50 minutes leading up to the show the recording captured interactions between the RPIC and copilot, and with support crew and stakeholders. It also recorded a range of operationally critical information. A detailed summary of events captured in the recording can be found in Appendix A, with key events summarised below.

At 1750 the first recorded wind speed reading was taken, giving 14 kt. At 1754 and 1817 further readings are taken at 12 kt and 14 kt respectively. At 1805 and following the 1816 reading the pilot and copilot discussed the prevailing wind conditions. The copilot stated that they believed that conditions were suitable to launch the swarm. In response, the RPIC identified that the readings they had were only at ground level and they had not tested for gusts at the intended height of the show. No further wind speed readings were taken and there was no further discussion of the wind speed recorded before the show.

At 1756 the RPIC was recorded dictating a voice to text message to the client’s representative with an update regarding the status of the show. They advised that the conditions were on trend with the forecast and they expected the show to go ahead at that point. At 1816 the RPIC identified that the representative had asked them for an update by 1815 as to whether the show would go ahead. At 1817 the RPIC was recorded dictating a further text message to the client that they were good to launch.

At 1759 the RPIC identified that to reprogram the show position to avoid the boat mast in front of the launch area required the assistance of another company pilot as they had not used that software functionality before. However, they were unable to contact the other company pilot for a further 8 minutes, despite prearranging for them to be available at 1800 to assist.

Between 1807 and 1817 the RPIC and the other company pilot went through the process of moving the show, performing the show virtual preview and interpreting the results of the preview. The RPIC applied the relevant correction to the show position, increasing the show height and moving the show to the left. The RPIC identified that the increased show height now exceeded the 120 m limit of the approval, but the other company pilot identified that the surrounding buildings provided some shielding. The RPIC elected to continue the show.

At 1817, following the completion of the show repositioning, the RPIC identified that they needed to work through the pre‑flight checklist prior to launch. The pilot and copilot worked through the items on the pre‑flight checklist. On multiple occasions they are interrupted by external communications from stakeholders and support crew.

At 1827 the RPIC instructed the copilot to make an airband broadcast in accordance with the pre‑flight checklist. The copilot questioned the need for the broadcast but was overruled by the RPIC and made the relevant transmission. The RPIC then completed the verification that the show program had been successfully uploaded to all 500 aircraft. At 1829 the copilot read out the last pre‑launch items on the checklist and the RPIC confirmed that they had been completed.

Flight

Launch

The aircraft were programmed to take off and ascend into a hover in a series of 10 layers of 50 aircraft (Figure 2). The aircraft would then move out over the water transitioning into the show area flying through a series of waypoints to make the relevant patterns of the show before returning and landing back on the grid. The whole show was planned to take about 10 minutes from take-off to return.

At 1830:15 the RPIC commanded the show to launch on the GCS. Following a 10 second countdown the aircraft powered up and the take‑off sequence commenced. The aircraft took off as programmed, with the 10 layers of aircraft stacked over the take‑off grid (Figure 2). However, 15 seconds after the first aircraft launched the GCS recorded 45 aircraft with errors, indicating that aircraft were out of position. Over the following 30 seconds the GCS recorded a further 78 aircraft showing as out of position. 

Transition to the show area 

At 1831:11 the swarm commenced its transition into the show area, but within 30 seconds more than half of the aircraft in the show were indicating errors, most for being out of position. At 1831:43 and 1831:48 the RPIC attempted to command the swarm to loiter, the first attempt was unsuccessful as they had not selected the aircraft to send the command to. The second attempt was successful with the loiter command reaching all the aircraft that were connected to the GCS computer. 

At approximately the same time as the second loiter command was issued, multiple aircraft presented with critical errors indicating an autopilot failure. This was shortly followed at 1831:55 by the RPIC identifying that there was a ‘fly‑away’. Further errors of varying severity levels continued to present on the GCS. After confirming that the copilot had the fly‑away aircraft under their control, the RPIC directed the copilot to disarm[3] that aircraft. 

By this time over 400 aircraft were presenting errors on the GCS. Between 1832:30 and 1832:50 the GCS rapidly lost connection to almost 400 of the aircraft in the swarm. When the connection was lost aircraft were in multiple different modes, with many showing loiter as per the RPIC’s command, some attempting to return to the launch area and others, predominantly those with critical errors, showing land in place.

Of the remaining aircraft connected to the GCS, 7 aircraft were attempting to continue with the show, which the RPIC then commanded to return home, while the remainder were indicating varying levels of errors. 

Nine minutes and 56 seconds after the show was commanded to launch, the last operational aircraft returned to the launch point.

Divers contracted by the operator attempted to recover the aircraft from the harbour over the following days. The divers recovered 236 of the 427 aircraft that entered the water, with 191 unrecovered.

Figure 2: CCTV footage of show

Source: City of Melbourne, cropped and annotated by the ATSB

Context

Aircraft information

Overview

The swarm consisted of 500 Newton V2.2 remotely piloted aircraft manufactured by Shenzhen Damoda Intelligent Control Technology Co., Ltd. (Damoda).

The Newton V2.2 is a quadcopter designed specifically for light show operations (Figure 3). It measured 360 mm square, sat 109 mm high, and weighed 725 grams. Mounted centrally on the bottom of the aircraft was a single colour‑changing LED light outputting a maximum of 16 watts. With a single battery the aircraft was designed for a show time of between 16 and 18 minutes and with a maximum hover endurance of approximately 26 minutes. The number of aircraft within the swarm could be varied depending on the individual show requirements, up to a maximum of 1,024.

Figure 3: Damoda Newton V2.2

Source: Operator, annotated by the ATSB

To conduct a show each aircraft was programmed with a series of timed waypoints and light colour changes. The aircraft operated independently through these waypoints with minimum separation distances of approximately 1.5 m during the show. Aircraft were not fitted with sensors to allow independent collision avoidance, relying on positional and time‑based accuracy to prevent collisions.

The aircraft were installed with a firmware package to enable operations. Due to the flight critical nature of the firmware, the operations manual required a flight test be conducted following a firmware update and that a record of this flight be made in the aircraft maintenance log.

Batteries

For the show each aircraft was fitted with a removeable Lithium Polymer (LiPo) battery that weighed 300 g and had a maximum energy capacity of 42.56Wh. Upon installation the aircraft had a red button that would protrude from the body of the aircraft to indicate that the battery was mounted correctly. For a swarm of 500 RPA these batteries equated to a total energy capacity of 21.28kWh. 

Aircraft limitations

The manufacturer’s wind speed limit for the Newton V2.2 was 8 m/s (equivalent to 15.6 kt or 29 km/h), this wind limit was common to all Damoda aircraft. In addition to the wind speed limit the aircraft also had an ingress protection or IP[4] rating of 63. This rating indicated that the aircraft were dust tight and could resist water spray but were not designed to operate in rain or be immersed in water and they would not float.

Aircraft positioning

Due to the close proximity of the swarm aircraft, uncorrected GNSS position information was not sufficiently accurate. To obtain high accuracy GNSS positions the aircraft were connected to a network containing a Real Time Kinematic (RTK) receiver. By using an independent stationary receiver in proximity to the aircraft the positional accuracy can be improved from several metres to centimetres as required for show operations. At 1822, 8 minutes before the show was due to launch, all aircraft were showing between 23 and 28 satellites connected and a high accuracy RTK position fix.

Prior to the show, the operator set up a spectrum analyser to identify potential interference in the GNSS signal that may cause the aircraft to malfunction or be out of position. The RPIC advised that prior to the show no abnormalities were identified in the signal that could have affected the aircrafts’ ability to accurately position themselves. 

GNSS spoofing

GNSS spoofing is the process of tricking a receiver into reporting an incorrect position. Spoofing a signal requires 2 steps, first the incoming signal to the receiver needs to be jammed and then the receiver must lock onto an independently generated false signal providing incorrect information. In the lead‑up to the display the GCS computer shows the position of each aircraft on the ground and in flight. These positions were shown over a base map and corresponded with locations recorded by CCTV footage (Figure 4). If the signal to the aircraft had been spoofed these locations would not have aligned.

Figure 4: Comparison of GCS and recorded aircraft positions

Note: The satellite basemap image as shown on the GCS is not an accurate representation of the actual structures around the launch site. This image was taken earlier in 2023 but the ATSB was unable to confirm the exact date. Source: City of Melbourne and operator annotated by the ATSB.

Aircraft modes

The Newton V2.2 could be operated in 6 different flight modes, G (guided), S (stabilised), L (loiter), R (return to launch), LD (land) and AH (altitude hold). A mode could be selected for an individual aircraft, it could be commanded for all aircraft in the swarm or it could be automatically changed by logic within the aircraft in the event that certain conditions were met. Manual mode changes could be commanded via the ground control station computer or a backup manual controller (see the section titled Ground control station).

In guided mode the aircraft was positioned based on the corrected GNSS position and transited through a series of pre‑programmed waypoints, before returning to the launch location.

In stabilised mode the GNSS positioning was disabled and the aircraft was manually flown using the hand controller. This mode was used if the aircraft had an error that rendered it unable to return to home automatically.

In loiter mode the aircraft held both lateral and vertical position until a further command was provided by the pilot, either via the GCS or using the hand controller.

In return to launch (RTL) mode the aircraft automatically tracked back to a position over the launch location. As the aircraft did not have obstacle avoidance sensors, this option was preferred only for individual or small groups of aircraft as commanding RTL for the whole swarm was likely to result in multiple aircraft collisions and loss of aircraft.

In land mode the aircraft landed directly below its current location.

Aircraft errors

The Newton V2.2 had 6 error modes that could be presented on the ground control station. These were: 

• EKF (autopilot failure)
• W (waypoint issue)
• B (battery voltage was low)
• F (aircraft had breached the geofence)
• T and S (Too far and Static) both indicated that the aircraft was not at the planned position. Too far indicated that the aircraft was more than 0.8 m from its target position. The distance from the target position required to activate a static error was not identified in the aircraft documentation.

These errors were broken into 3 categories depending on the required pilot response when they are presented.

• EKF or W errors required the pilot to return the aircraft to launch.
• B error - the aircraft should activate RTL automatically.
• F error - the aircraft would automatically activate RTL and re-enter the geofence. If it did not return within the geofence the motors would be automatically shut down.
• T and S errors were for information and monitoring. The pilot was only to intervene and manually activate RTL if the distance between the planned and actual locations continued to increase. 

The display of these errors on the GCS is discussed further in the section Flight control software - Warnings. The RPIC identified that there were up to 10 aircraft presenting with EKF errors, and that they had never experienced more than one EKF error simultaneously. 

Fleet

At the time of the occurrence the operator had a total Damoda V2.2 fleet of 1,136 aircraft registered with the Civil Aviation Safety Authority (CASA). The first 515 of these were registered with CASA at the end of October 2022. The remaining aircraft were registered in April of 2023, shortly after their purchase.

Along with these additional aircraft, the operator also purchased additional support equipment for a second complete GCS layout. This enabled the operator to either operate 2 independent fleets of 500 aircraft or to combine the 2 fleets for a single show of up to 1,024 aircraft. When the operator purchased the additional aircraft, it was supplied with the latest version of the aircraft firmware and the manufacturer’s latest GCS software (see the section titled Flight control software). 

Ground control station

The ground control station (GCS) consisted of 4 elements: 

• a laptop computer running Damoda’s flight control software
• a Wi-Fi network to which all the aircraft were connected, enabling communications and data transfer between the aircraft and flight control software before and during the show
• a differential ground station for real time correction of the GNSS signal
• a spectrum analyser used to identify abnormalities or issues in the frequency bands that the aircraft and the GNSS signal were operating. 

These elements were brought to the show location by the operator and were set up by the flight crew.

Flight control software

Operating on a laptop computer, the flight control software provided all command and control actions for the swarm through the local network. Common to all Damoda aircraft types, the software allowed flight crew to monitor the status of all aircraft before and throughout the show. It was used to upload, manipulate and test the proposed show, control the aircraft either through the software itself or by tethering them to the hand controller.

The flight control software also displayed errors and warnings affecting the aircraft or the software. The flight control software was not used for the development of the show flight paths or ‘drama’. This was completed in a different software package and a drama file containing the show flight paths for each aircraft was imported into the flight control software for uploading to the individual aircraft.

When the operator received the first 500 aircraft in October 2022 these were provided with version 2 of the manufacturer’s flight control software. Prior to the acquisition of the operator’s second 500 aircraft in April 2023, the manufacturer introduced an updated version of the flight control software (version 3), and this was provided to the operator, along with an updated version of the aircraft firmware.

Wind speed monitoring

A wind monitoring function was introduced with version 3 of the flight control software. This function displayed the maximum wind speed and direction encountered by aircraft in the swarm, in the upper right corner of the screen (Figure 5). To provide a reading, at least one aircraft had to be active and connected to the GCS software.

The wind monitoring function remained visible and its position constant on the screen throughout the operation of the GCS. Other functionality could be selected or deselected depending on the pilot’s information preference. Wind speed and direction were calculated and displayed in real time through the interpretation of aircraft bank angle and motor speed, combined with the planned and actual positions of the aircraft. 

When the wind speed limit was exceeded, there was no audible, visual or tactile alert presented to the pilot. As such, the flight crew needed to actively monitor the parameter to be aware of an exceedance of the wind speed limit. Figure 6 shows the wind speed indicator at 3 moments during the show with the wind speed below, just above and significantly exceeding the 8 m/s published wind speed limit of the aircraft. 

Figure 5: GCS software display with wind speed readout highlighted

Source: Operator, annotated by the ATSB

Figure 6: Wind speed display below, just above and significantly exceeding the wind speed limit

Source: Operator, cropped and annotated by the ATSB

The flight crew advised that at the time of the show they were not aware that this functionality was available to them. The RPIC reported that they only became aware of it when they were reviewing the incident with another one of the operator’s pilots who identified the indicator to them. The RPIC stated that if they had identified this information at the time of the show then they would have likely terminated the show when the wind speed limit was reached.

Warnings

The GCS software could present 2 different types of warnings depending on whether an individual or multiple aircraft were affected. 

Errors related to individual aircraft presented on the GCS computer in an individual box as shown in Figure 7. These boxes showed the aircraft identifier, the error or errors and the mode the aircraft was operating in. They were then grouped by colour coded category depending on the required pilot response. Errors requiring immediate action were coded red, those that resulted in an automatic RTL were coded orange and those that only required monitoring were coded blue.

Where an aircraft showed errors from multiple different categories the aircraft was placed in the highest category of urgency encountered. Figure 8 shows all 3 of the categories appearing on the GCS for this occurrence, shortly after the aircraft transitioned towards the show area.

Figure 7: GCS screenshot showing individual aircraft errors

Source: Operator, annotated by the ATSB

Figure 8: GCS recording showing the 3 error categories as they appeared on the night of the show

Source: Operator annotated by the ATSB

Errors that affected multiple aircraft were presented as a pop‑up over other windows on the GCS screen (Figure 9) and required acknowledgement before any other action could be taken. These warnings were presented in instances such as a failure of data to successfully upload to aircraft or failure of a command to reach the aircraft. 

Figure 9: GCS screenshot showing a multi-aircraft warning pop‑up

Source: Operator, annotated by the ATSB

Both types of warnings relied on data processed by the GCS to display the relevant information to the pilot. The errors were then presented in such a way that the pilot could rapidly interpret the meaning and respond appropriately. 

Adjusting the show 

The GCS software had the capability to adjust the position, height and orientation of the drama file to ensure that the flight paths could be executed safely. The flight crew had multiple options for making the adjustment, which could be used independently or simultaneously. They could change the height or position of the whole drama file or they could adjust the launch and landing profiles, which changed the position and altitude that the aircraft moved to before they transitioned into the show area.

Due to the boat mast hazard the RPIC, in consultation with one of company’s other pilots, elected to adjust the position of the transition into the show area by increasing the height by 11 m and moving all aircraft 2 m to the left (Figure 10). To accommodate for these changes the total height of the show was also adjusted up by 8 m taking the maximum show height to 126 m. 

Figure 10: Drama adjustment functionality as set by the RPIC

Source: Operator, annotated by the ATSB

Setting the geofence and exclusion zone

The geofence is a polygon made of a series of GNSS locations surrounding the show area (Figure 11). It was manually created in the flight control software and then uploaded to the aircraft. Once in flight, if an aircraft passed through the geofence it automatically activated the RTL mode to bring it back inside the geofenced area and return to land. If the aircraft remained outside the geofence then the motors were shut down and the aircraft fell to the ground or water uncontrolled. 

Figure 11: Development and placement of Geofence

Source: Operator, annotated by the ATSB

The flight control software had a measurement feature that allowed the operator to identify and measure approximate distances over the base map. This allowed the determination of the size of both the geofence and the subsequent size of the exclusion zone (see the section titled Exclusion zone).

Hand controller

Swarm operations are conducted autonomously with the aircraft moving through a series of pre‑programmed waypoints or in the relevant failsafe modes. In the event of a system issue or error that prevented the automated system from effectively controlling the swarm, manual control could be taken using a hand controller. The controller allowed the operator to fly the swarm, command mode changes and activate relevant failsafe modes on the aircraft. For the hand controller to be used it must be tethered to the relevant aircraft in the swarm. It could be tethered to all aircraft in the swarm or to certain aircraft independently.

The manual controller employed by the operator was a VANTAC Taranis hand‑held controller, manufactured by FrSky. The VANTAC (Figure 12) was a programmable, 24 channel, 2.4 GHz transmitter that could be used to control a range of remote devices, including RPA. The controller had 8 programable control switches, (6 3‑position and 2 2‑position) that the user could assign to modes or operational settings. In support of the Damoda swarm operations the switches were assigned as per Figure 12. The mode switch allowed the operator to change the mode between land, loiter and stabilised modes. As part of the operator’s pre-flight checklist the throttle (vertical movement on the left control stick) on the controller was to be set to 50% so that if the controller was required the aircraft would have sufficient power to hover.

The emergency kill switch was a 2‑position switch. When activated it immediately shut down the motors, causing the aircraft to fall to the ground. This was the command that the copilot implemented once the RPIC instructed them to disarm the fly‑away aircraft.

Figure 12: FrSky VANTAC Taranis controller

Source: Operator

Crew information

The operator’s manuals listed the crew for a light show operation in 3 distinct groups, all under the oversight of the RPIC, as follows: 

• flight crew, responsible for the safe setup and operation of the fleet of drones
• ground/support crew, assisted in the set-up of the fleet and operational area and monitoring the ground and airspace around the show for potential intruders
• additional security or other personnel involved in securing the operational area, such as water police for a show over water. 

Flight crew

For light show operations involving up to 500 aircraft the company operations manual required a flight crew of 2 – a mission commander (RPIC) and a copilot. The CASA permission for the operation (see the section titled Operational approval) listed specific pilots who were approved to operate more than one RPA at a time. The CASA permission did not specifically require a second pilot, however the operator’s manuals contained a requirement for a 2 or 3 pilot operation depending upon the swarm size. 

Remote pilot in command 

The RPIC was authorised and qualified to act as the mission commander for the operation that was being undertaken. They held a Remote Pilot License (RePL) for multi‑copter operations up to 25 kg. Upon joining the operator in October 2022, they had completed the Damoda training program and subsequently been endorsed by CASA to operate more than one RPA at a time.

At the time of the operation the RPIC had approximately 6 hours on type consisting of 32 training or operational shows varying in size from 10 to 1,050 aircraft conducted at a range of locations, including over water, and in both day and night conditions. The RPIC’s most recent show flight was the rehearsal for the Docklands operation, which was carried out 4 days prior to the show.

The RPIC held ultimate responsibility for the safe operation of the show in accordance with the relevant permissions and operator’s manuals. The operations manual outlined the specific responsibilities of the RPIC to include but were not limited to:

• Conducting an operational safety briefing on items relevant to the RPA operation.

• RPA crew co-ordination.

• Ensuring the RPA is in CASA approved airspace.

• Ensuring operations are conducted in accordance with company operating procedures including the JSA [job safety assessment] and Flight Authorisation.

• Maintaining communication with the RPA crew throughout the entire operation using Local Comms Handheld Radios.

• Confirming responsibilities of all flight crew members

• Reviewing the show design and verify operational area, exclusion area, and minimum drone separation distance (1.0 m) prior to flight.

• Confirming proper set-up of base station.

• Operation of the RPA.

• Post-flight data recording.

• Confirm all crew fitness for duty.

• Reporting incidents to the Chief Pilot.

Copilot

The copilot for this operation was authorised and qualified to operate in the role of copilot. They held a RePL for multi‑copter operations up to 25 kg and had completed the operator’s Damoda training program following the introduction of the aircraft type in October 2022.

The copilot had previously completed 17 lightshow training flights operating in either the RPIC or copilot role, the most recent of which was as a copilot 3 days prior to the occurrence flight at Sydney Olympic Park. The operator’s flight logs identified that prior to that operation they had not completed a show in more than 6 months. The copilot had not been endorsed by CASA as qualified to operate as mission commander (RPIC) in one‑to‑many operations, however under the operator’s manuals this was not required to operate in the role of copilot. 

The copilot’s role as outlined in the operator’s manuals was to assist the RPIC in the conduct of the show. The manual delegated specific responsibilities to the copilot. While not specifically stated in the manual, one of the aims of this was to reduce the RPIC’s workload. The responsibilities of the copilot included: 

• conducting an operational safety briefing on airspace items

• management of stakeholders

• management of show support crew

• monitoring operating area Airband VHF frequencies throughout the entire operation

• broadcasting on VHF frequency when needed

• immediately advising Mission Commander of any relevant airspace traffic

• show timing

• co-ordinating incident response

• assist the Remote Pilot in Command and be co-located during the show unless attending to an emergency

• activate emergency procedures in event of RPIC incapacitation

• Hold direct communication with the all crew throughout the entire operation using Local Comms Handheld Radios (or co-location).

• Visual observation of swarm

• Alert of drone flyaway

• Control of drone flyaway Drones IDs 1-500

The copilot was also the operator’s chief remote pilot (CRP). As such, they had overall responsibility for the RPAS operation, including the approval of operations planned by the other pilots. The copilot had completed training on the V2.2 aircraft and GCS software when it was introduced, however they stated that they normally left the planning and operation of the shows to the other pilots who were more proficient in swarm operations. This allowed them to focus on other areas of their role in the organisation. 

Due to staffing changes at the operator (see the section titled Staffing changes) the chief remote pilot had been brought into this operation as a copilot. As they were not endorsed by CASA, they could not assume the role of RPIC. 

Ground crew

In support of the flight crew the operator’s manual required that one ground crew member be present for every 100 aircraft within the display. Under the operations manual these crew members were responsible for a range of tasks. These included: 

• ground handling of the RPAs
• pre- and post-flight checks of the RPAs
• battery management
• monitoring of the ground and airspace around the show area for potential breaches
• maintaining direct communications with the flight crew throughout the entire operation.

The operator sourced ground crew members from a labour hire company. Ground crew members were briefed by the RPIC and required to complete a consent and compliance declaration acknowledging that they understood their role. Once briefed by the RPIC the management of the show support crew was the responsibility of the copilot.

Additional personnel

As this show was to be conducted over water, the operator was required to ensure that water traffic was maintained clear of the show area exclusion zone. To enforce this zone the operator had engaged vessels from Parks Victoria, Victorian water police and a private contractor to monitor the show area perimeter. Communications between these vessels and the flight crew was maintained by UHF radio.

Multi-crew operations

Cockpit gradient

A cockpit or authority gradient refers to how balanced power and decision‑making authority is within a team. Authority is not necessarily defined by experience or competence in a role but may be through the role that a person holds (SKYbrary, 2025). Where a cockpit gradient is too steep, team members may not be willing to challenge or express concerns over a leader’s decisions, and where too shallow it can slow decision‑making processes.

A negative gradient is where a team member in a subordinate role has more power or authority than the team leader. This can undermine the team leader’s authority and lead to the leader deferring to, or placing additional weight on, that team member’s opinions or ideas.

In crewed operations, to be endorsed to fly multi‑crew, pilots must undertake multi‑crew coordination (MCC) training. Part of this training required the candidate to demonstrate effective management of flight deck gradient for tasks that were being performed. Neither the CASA approval nor the operator’s documentation required this or equivalent training for swarm operations.   

Operator information

Operations manual

The operator maintained an operations manual and operations library in accordance with the requirements of Part 101 of the Civil Aviation Safety Regulations 1998 (CASR); both had been approved by CASA. The operations manual contained the operator’s overarching processes and procedures and outlined various regulatory compliance requirements. The operational library contained more specific aircraft information and operational processes.

For example, the operator’s manual contained information about the conduct of RPAS display operations, however the specific process for carrying out the pre‑show checklist was contained in the operational library. Similarly, the basic and overarching emergency procedures were contained within the operations manual but specific responses and processes for different emergencies were in the operational library. 

The operations manual outlined that the chief remote pilot was responsible for all operational matters and remote pilot training affecting safety. This included:

• ensuring that operations were conducted in compliance with relevant regulations
• responsibility for applications, permissions and approvals to facilitate operations
• maintaining a reference library of operational documents
• developing checklist and procedures relating to flight operations. 

Checklists

To support show operations using Damoda aircraft the operator maintained and utilised several checklists contained within the operations library. The show day and flight checklists were the primary documents used by the crew in preparations for a show. There were different versions of these checklists depending on whether more or less than 500 drones were being used in the show. 

For a show of up to 500 drones, the show day checklist consisted of 10 items, taking the crew through the set‑up of the GCS and the laying out of all drones in preparation for the show. It also included guidance on the set‑up of the network and RTK equipment and environmental monitoring including electromagnetic and wind conditions.

The final item on this checklist (Figure 13) was for a weather inspection. This item required the pilot to check the current weather forecast and measure the wind speed at 5‑minute intervals for the 30 minutes before the show start ‘if the pilot has capacity’. The checklist did not identify a specific location where these wind readings are to be taken. The checklist was dated 7 March 2023, which was before the introduction of the wind management plan and weather drone (see the section titled Wind management plan). 

Figure 13: Item 10 on the operator’s show day checklist

Source: Operator

At interview both the RPIC and copilot identified that this checklist was available to assist them in the lead‑up to the show. The RPIC stated that they and other pilots were familiar with the content and they did not always refer to the checklist during preparations for the show.

For a show of up to 500 drones the flight checklist consisted of 20 items taking the flight crew through the set‑up of the aircraft and GCS equipment, a review of the emergency procedures and final checks. Item 17 was the final item before launch and it required the RPIC to consider their confidence in the fleet and assess the overall risk factors before deciding whether to launch the show. The RPIC stated that the flight checklist was mandatory and was always used in the lead‑up to the show.

Emergency procedures

The operator’s manuals outlined the procedures in the event of an emergency during the swarm display. It defined procedures for a range of non‑swarm related emergencies including fire on the ground, crew medical event and non‑cooperative traffic (aircraft or bird) interacting with the swarm.

The general response to any of these emergencies was to respond to the immediate threat (if required) and then place the swarm on the ground as quickly and safely as possible either using an RTL or land command sent to all aircraft or manually controlling aircraft to the ground. 

The operator maintained specific emergency procedures for aircraft producing EKF (autopilot failure) and W (waypoint issue) errors. These errors required an immediate response from the pilot to select RTL and if the RTL command failed the aircraft were to be flown back manually using the hand controller.

Item 2 of the operator’s flight checklist required that the RPIC and copilot reviewed the emergency procedures prior to flight. The GCS recorded that the RPIC stated that the response to these errors would be to RTL, take control of the aircraft manually and if neither of these were successful, land the aircraft in the water.

In response to this occurrence, the RPIC activated the emergency procedure for EKF errors and fly away aircraft. While initially the RPIC activated a loiter command, at that time neither the fly away nor the first EKF error had occurred. When these occurred the RPIC instructed the copilot to control and then deactivate the aircraft and attempted to RTL each aircraft showing an EKF error on the GCS.

Training and checking

With the introduction of the Damoda aircraft all the operator’s pilots, including the copilot (CRP) undertook initial training with the manufacturer’s Australian agent. The CRP identified that there were some gaps in the training so the operator’s pilots undertook further in‑house familiarisation and testing with the show software to understand the relevant capabilities and features.

When version 3 of the GCS software was introduced, no formalised training was undertaken with the manufacturer or its Australia agent. The operator and RPIC reported that the manufacturer had provided a document with installation guidance and some differences between the old and new versions of the software. They further identified that prior to starting operations with the new software the pilots undertook familiarisation with it, identifying updates to existing features and some of the new features.   

There was no documented process for ensuring that all pilots had the same level of competence or were aware of all the relevant features of the software.

Prior to commencing show operations, the RPIC was required to complete the operator’s internal training program and be checked by CASA for approval to operate multiple aircraft simultaneously. The training syllabus for operations using the Damoda aircraft involved 8 sessions. The first required the pilot to demonstrate correct set‑up and operation of all the show hardware, including the GCS and aircraft.

The following sessions involved incremental increases in the number of aircraft from a single aircraft through to a 1,050 aircraft flight. Each session required the pilot to identify the relevant configuration, set‑up and crewing changes for the number of aircraft being operated. The CASA check for approval to the operational instrument was built into this training syllabus and was completed as part of session 7. Session 8 was a final demonstration flight with 1,050 RPA.

The operator’s manual required show‑qualified RPICs, copilots and ground crew members to undertake proficiency checks to ensure that they were operationally capable. Proficiency checks covered a range of items applicable to each of these roles. They were required every 12 months unless the candidate had carried out a minimum of 4 relevant light show operations in the last 12 months, whereby the time between the proficiency checks could be extended to 24 months.

The RPIC had joined the operator less than 12 months previously and had completed more than the required 4 light show operations as RPIC meaning that a proficiency check was not required until October 2024.

Proficiency checks were required for each aircraft type and additional proficiency checks were not required in the event of significant changes to the software.

Wind management plan

In response to a specific request from an earlier client the operator had developed a wind management plan. Introduced on 21 May 2023, the plan was ‘…to ensure the safe and successful execution of a drone light show event in windy conditions’. While initially developed for that specific client the plan made no specific reference to that client or event, generally identifying the set‑up and operational wind limits and specifying how weather could be monitored. The set‑up limit was 18 kt (9.2 m/s) measured 3 hours before the flight and the operational limit was 14 kt (7.2 m/s) measured 5 minutes before the flight. The wind management plan also contained higher level statements about how the use of certain aircraft, training of pilots, engagement with stakeholders, an emergency response plan and post‑event evaluation was used to achieve the purpose of the plan. 

Despite containing operationally relevant information related to wind management and responses to adverse conditions the plan was only included in the event plan for the show and was not integrated into the organisation’s operational processes and procedures.

Version 1.1 of the wind management plan was dated 6 June 2023, approximately 5 weeks before the accident flight. The updated version increased the operational wind limit from 14 to 15.3 kt (7.2 to 7.9 m/sec) and introduced, at the RPIC’s discretion, the use of a weather drone to test the conditions in the show area before the show was launched. The plan did not detail how the weather drone could be used, but the CRP identified that it could be conducted with a separate aircraft or an aircraft from the swarm could be tethered to the controller and flown manually for the weather check. As with the earlier version, the updated version of the plan was only included in the event operational plan and not integrated into show processes and procedures. 

The wind management plan did not refer to the wind speed readout on the GCS display.

The RPIC advised that they were aware of the wind management plan and that, to their knowledge at the time of the occurrence, it did not contain the option for the launch of a weather drone. They further stated that this was only introduced post this accident. 

Staffing changes

In the weeks leading up to the show there were several staffing changes that impacted how the show was planned and carried out. Firstly, the operator’s chief executive officer (CEO) had left and this show was the first opportunity for the new CEO to see the company’s drone swarm operation in practise. Secondly, the operations manager, who had been the main point of interaction between the client and flight crew during show preparations had left the company and had not been replaced. 

As a result of the departure of the operations manager, the RPIC had taken on this role and subsequently was involved in preparation of multiple shows, including the Docklands show. This included liaising directly with the client and other stakeholders. The RPIC stated that having the pilot operating the show involved in client interaction during operational planning was normally avoided. This was to ensure that the RPIC on the night could focus on operating the show and not have to worry about engaging with the client.

Normally, once a show had been planned, contact with the client would be handed over to the copilot for them to manage on the night of the show. For this show that did not occur due to the already established relationship between the RPIC and client. 

The reduction in team size brought about by the operations manager’s departure reduced the personnel available for this show. Subsequently the CRP who was copilot‑qualified, but stated that they weren’t ‘recent’ in the operation, stepped into the role of copilot. The RPIC commented that this resulted in a different dynamic between the RPIC and copilot than if the copilot had been more experienced.

Operator’s review

Following the accident the operator conducted a review into the occurrence and identified the following:

• The flight crew did not consider the conditions in the show area at altitude.
• RPIC was under unrealistic pressure to complete the show in the allotted time.
• The copilot’s limited experience increased pressure on the RPIC.
• Requirement to move the show reduced time available for show preparations.
• The RPIC had significant confidence in the reliability and functionality of the operational fleet.

Operational information

Operational approval

In Australia RPAS operations are governed by Part 101 of the CASR. Under regulation 101.300 a person may not operate more than one RPA without a specific approval from CASA. On 12 May 2023 CASA issued a 12‑month approval for the operator and specified pilots to operate more than one RPA at a time and at night, subject to a series of conditions. Some of the conditions listed on this approval were that the:

• operator must have an active notice to airmen (NOTAM) advising when and where the operation was taking place

• operator must operate in accordance with their operations manual

• operator may only operate Damoda multirotor aircraft up to 750 g

• RPA must have appropriate failsafe functionality in the event the data link to it was lost.

• operator must maintain an appropriate exclusion distance to non-essential personnel as outlined in the specific revision of their operations library.

Provided that these conditions could be met, the operator was permitted to plan shows at any location in Australia. 

Show planning

Once a potential show location had been identified, an operational self‑assessment was to be carried out on the site using the process outlined in the operations library. The assessment was to include hazards within the operational area, including the show airspace, the launch and recovery area and the traversal airspace between these 2 areas. The assessment also determined the exclusion zone requirements. 

The self-assessment required consideration of the access to both the ground and airspace in these areas, clearance and obstacles, the potential for RF interference, ground topography and other potential users. The manual specifically identified that waterways were a preferred operational area as the water provided a natural barrier to public access. Waterways without vessel access were preferred, however where vessel access was possible then an exclusion zone needed to be set up and enforced by the relevant authorities.

Docklands

The show planning for the Docklands operation was carried out by the RPIC and one of the operator’s other pilots. Part of the planning process was engagement with the harbour authority to organise a harbour closure and enforcement of the exclusion zone around the show. In the days leading up to the show, the operator requested that the 15‑minute closure window for the show be moved later due to forecast wind conditions. The operator advised that the harbour authority had stated that this was not possible.

Event operational plan

The event operational plan contained all the relevant information that the crew required to conduct the show, such as timings, location, relevant stakeholder contact details and plans for traffic and crowd control. Listed as attachments to the operational plan were 5 appendices (labelled A through E). Appendix A was the wind management plan. The event operational plan did not specify which version was attached, however at the time v1.1 was current. Appendix D contained the operator’s risk assessment. This document identified the loss of aircraft into the water as a hazard that required treatment. Most of the treatments were related to management of batteries and inspection of aircraft, the final treatment was the availability of divers onsite to recover any RPAS that were lost into the water.

The event operational plan and its appendices were available to the flight crew on the day of the accident. However, the RPIC reported that in the lead‑up to the show the crew would normally refer to the checklists rather than the event operational plan for relevant processes. In the 50 minutes leading up to the show the only reference that was recorded to the event operational plan was associated with obtaining the frequency for the nearby Essendon air traffic control tower.

Operational area

Victoria Harbour is located approximately 1 km south‑west of the Melbourne CBD. The area surrounding the harbour is a mixed residential and commercial precinct with the Docklands Stadium on the northern end and several high‑rise buildings adjacent to the harbour, with the tallest being approximately 140 m.

South of the harbour the Bolte Bridge crosses the Yarra River with two 140 m tall support towers. The selected launch site had previously been used by another operator to launch a swarm display. That display had encountered issues with magnetic interference close to the ground, which was believed to be due to the large volume of steel reinforcing of the concrete at the launch site associated with its previous use as an operational dock.

The operator had identified this as a potential hazard and expected that there may be some magnetic interference with the aircraft, however there were minimal impacts identified in the GCS recording or reported by the flight crew prior to or during the initial launch of the swarm.

As shown in Figure 1 there were multiple jetties where pleasure craft were moored extending up to 90 m into the harbour. As the operator did not have access controls in place for these jetties, to ensure safety for anyone on them at the time of the show, they needed to be outside of the exclusion zone around the show area. 

Exclusion zone

An exclusion zone ensures that, in the event of an aircraft operational issue, it will be contained and not pose a risk to non‑essential personnel. The zone is calculated from the geofence, based on the aircraft’s maximum operational speed and its wind speed limit. Therefore, an aircraft operating at maximum operational speed with a tail wind at the aircraft’s wind speed limit will still be contained. The exclusion zone was calculated at 50 ft operating height increments between 100 ft and 400 ft (maximum allowable show height).

Table 1, reproduced from the operations library, shows the calculated minimum exclusion zones for Damoda V2 aircraft between 100 ft and 400 ft.

Table 1: Damoda V2 minimum exclusion zones by aircraft height

Prior to setting the geofence, the pilot measured the distance between the edge of the show area and a publicly-accessible jetty on the opposite side of the harbour to be 62 m. The RPIC then set the geofence around the show area manually using a buffer of 8‍–‍15 m, resulting in an effective exclusion zone between 47‍–‍54 m (Figure 14). 

Figure 14: Exclusion zone positioning

Source: Operator, modified and annotated by the ATSB

Based on the operator’s exclusion zone calculation process, the ATSB assessed the size of zone required to contain aircraft operating at maximum show speed and subject to a tailwind of twice the approved limit of the aircraft (16 m/s) at a height of 126 m (the maximum planned height of the show). In that scenario, an exclusion zone of more than 100 m would have been required. 

Meteorological information

Operator accessed information

The flight crew advised that, throughout the afternoon and in the lead‑up to the show, they had accessed meteorological information from several sources. This included the Bureau of Meteorology (BoM), Windy and Willy Weather applications and aviation meteorological forecasts, including the relevant graphical area forecast and terminal area forecast for Essendon Airport (6 nautical miles to the north-west of Docklands). In discussing the wind conditions the flight crew noted that they were above the limit of the aircraft, but expected them to ease leading up to the show time.

Ground‑based monitoring

The flight crew were monitoring the wind speed on the ground using a handheld anemometer[6]. The flight crew reported that during the set‑up for the show the wind had been recorded in excess of the aircrafts’ limit. 

Table 2 shows the recorded wind readings that were taken in the 40 minutes leading up to the show, ending at 1817.

Table 2: Wind speed measurements taken at launch site recorded by GCS

Bureau of Meteorology aviation forecasts and observations

The graphical area forecast issued by the BoM, valid at the time of the show for the Docklands area, identified surface visibility exceeding 10 km and severe turbulence below 6,000 ft for most of south‑eastern Victoria.

At 0927 on the day of the show the BoM issued a terminal area forecast (TAF) for Essendon Airport (YMEN)[7]. The TAF was valid between 1000 and 2200 local time on the day of the show. It forecast winds from the north at 18 kt gusting to 28 kt, strengthening to 20 kt gusting 32 kt from 1100, with severe turbulence below 5,000 ft from 1000.

At 1507 the BoM issued an amended TAF valid from 1600 till 0400 the day after the show. From 1600 it forecast winds from the north at 18 kt gusting 28 kt and severe turbulence below 5000 ft. From 2200 winds were forecast from the north at 14 kt with the turbulence reducing to moderate. 

Corresponding observations

METAR and SPECI information for YMEN for the period from the start of the amended TAF at 1600 until 1830 (the show launch time) was consistent with the forecast conditions. The wind direction was consistently from the north and wind speeds varied around the aircrafts’ limit, with gusts between 25–30 kt (Figure 15).

Figure 15: YMEN wind speed observations

Source: ATSB using BOM data

Aircraft

While airborne and connected to the GCS the aircraft reported wind speed and direction information, which was displayed on the wind monitor. The wind speed was manually extracted from the GCS recording and plotted at 5 second intervals showing the changes in wind speed throughout the occurrence (Figure 16).

Within 10 seconds of the first data being recorded, the aircraft were operating in excess of the wind speed limit. As the aircraft climbed during the transition to the show area the wind speed increased rapidly progressing to more than double the 8 m/s limit of the aircraft.

Over the following 35 seconds the wind speed decreased and remained at or close to the limit until 1833:30, approximately 2 minutes after the show was launched. At the time the wind speed decreased most of the aircraft had activated their failsafe mode and were attempting to land in the water. Notwithstanding the potential effect of wind gusts, at these lower heights the wind speeds were likely closer to the speeds recorded on the ground before launch.

Figure 16: Wind speeds displayed on the GCS

Source: ATSB based on operator data

Recorded data

Aircraft

Following the occurrence the operator downloaded the flight logs from the aircraft that were not submerged and provided these, along with the screen recording and logs from the GCS software to the manufacturer for further analysis.

The manufacturer identified that up to 397 aircraft simultaneously reported ‘T’ errors. Further analysis of the available logs indicated that aircraft throttled to 100% and that the recorded pitch angle of the aircraft (max 53°) exceeded the normal flight angle (Figure 17).

The manufacturer concluded that the aircraft had encountered wind conditions exceeding their capability.

Figure 17: Aircraft pitch, roll and throttle parameters

Source: Manufacturer, annotated by the ATSB

Specifically, while most of the aircraft were showing the commanded loiter mode, the manufacturer identified that:

Due to the influence of the wind speed, the power of the motors was no longer able to provide the required lift for the drones, so they moved up and down and slowly landed.

Without the capacity to provide the required lift the aircraft could not maintain position in the loiter as the RPIC had commanded and subsequently descended. This resulted in most of the aircraft ditching into the harbour. The GCS recording did not show evidence of a mode change, with most aircraft still showing the ‘L’ indicating they were in loiter mode on the GCS when connection was lost.

The manufacturer’s report also stated that the pilot was responsible for testing the wind speed and should be aware that the winds at height may be greater than that on the ground.

Ground control station

In accordance with the operator’s show day checklist the RPIC started screen recording on the GCS laptop computer at 1740, 50 minutes before the show was launched. The recording captured all activity that was displayed on the screen, including command inputs and selections, errors and function displays through until 1920, 50 minutes after launch.

The recording only captures what was displayed on the screen and not the information that the software used to generate the visual display. For example, during the show an aircraft status window was open over the location map so the location of the aircraft during and after transition into the show area was not visible. 

The software used to record the screen also recorded the input from the computer’s microphone, capturing the interactions and communications between various crew members that were within range. Appendix A summarises the recording leading up to the show.

Closed circuit television

A series of 6 closed circuit television (CCTV) cameras around Victoria Harbour (Figure 18) captured the show’s launch, transition to the show area and some of the show. The footage captured the uncommanded movement of multiple aircraft, aircraft collisions, the aircraft landing in the water and the fly away aircraft (Figure 2).

Camera 1 captured the location of the boat mast that the RPIC had identified as presenting an obstacle to the swarm (Figure 2). Camera 4 captured multiple flags showing full extension at the time that the show was launching in the background. Noting that wind conditions varied with height, this camera was used to gain a general understanding of the conditions around the show site in the lead‑up to, and at the time of, the show.

Figure 18: CCTV cameras around Docklands

Source: Google Earth, annotated by the ATSB

Safety analysis

Introduction

At 1830 on 14 July 2023, the remote pilot in command (RPIC) of a swarm of 500 Damoda Newton V2.2 aircraft commanded the aircraft to launch to conduct a light show. Shortly after launch, and before the aircraft transitioned to the show area, the RPIC was presented with an increasing number of errors. The swarm continued towards the show area where further errors presented with multiple aircraft entering failsafe modes and landing or falling into the water. A total of 427 aircraft were submerged, with only 236 recovered.

The following analysis will consider the conduct of the show from the launch to the aircraft ditching into the water, including the factors that impacted the decision to launch. It will also review several safety issues that increased the risk to the operation. 

Launch decision

Available information

Prior to the show the flight crew monitored wind conditions by referencing various weather sources and taking wind speed measurements at ground level. The conditions on the ground were below the limit of the aircraft with gusts exceeding the limit. The flight crew expected that, based on their interpretation of the available forecasts, wind conditions would ease in the lead‑up to the show time.

However, at 1817, 13 minutes before the show launch, a wind speed of 7 m/s was recorded on the ground, only 1 m/s below the allowable wind limit. At this time there was a conversation between the RPIC and the copilot about the wind conditions. The RPIC identified that the conditions on the ground were near the limit of the aircraft and that the wind speed in the show area was likely to be higher than that at ground level. The copilot responds that it’s only gusting and that they just have to get off the ground. In the following 13 minutes prior to the launch the RPIC was occupied with other tasks and no further wind speed assessment was undertaken. 

Wind management plan

The version of the operator’s wind management plan current at the time of the accident provided guidance for the collection of wind information within the show area using a weather drone. The RPIC was aware of the wind management plan but not that it contained the option to use a weather drone. That understanding was consistent with the content of the previous version of the plan that did not contain that option. 

As the wind management plan was attached to the event operational plan, which was prepared by the RPIC and approved by the copilot in their role as CRP, both flight crew should have been aware of the plan’s availability to them on the night of the show and its contents. However, in response to the draft report, both advised that they were unaware of its attachment to the event operational plan. Further, as the wind management plan had not been included in any operational process or procedure there was no prompt for the flight crew to review or access the plan prior to the show for guidance in the windy conditions. Subsequently, neither the plan nor the weather drone option it contained were used.

If a weather drone had been launched it is highly likely that it would have encountered conditions like those experienced by the swarm. That would then have provided the flight crew with confirmation that conditions were unsuitable for the light show to proceed.

Control issues and ditching

Show launch

Ten seconds after the RPIC commanded the swarm to launch, the wind speed displayed on the ground control station (GCS) was equal to the aircrafts’ limit of 8 m/s. A further 10 seconds later the readout was showing a wind speed of 9.9 m/s. At this time 85 aircraft were displaying errors on the GCS. Of these, the 20 where the error type was visible were all showing ‘T’ errors indicating that they were out of position. The manufacturer’s analysis of the flight data identified that these ‘T’ errors were presented due to the aircraft motors being unable to hold position against the prevailing wind.

Having ruled out interference with or spoofing of the GNSS signal the ATSB also considered the possibility of a malicious actor attempting to take control of the swarm. However, the GCS computer showed no unexpected changes to aircraft mode or any commands received by the aircraft that were not commanded either by the RPIC or automatically through aircraft logic. Additionally, if the aircraft had been interfered with and tasked to alternate positions then they would likely not have recorded out of position errors.

Ground control station wind speed display

There was no indication from the discussion, comments or actions recorded on the GCS computer that the flight crew identified a wind limit exceedance. They did not equate the 85 aircraft indicating ‘T’ errors to a limit exceedance or identify the wind speed readout. The RPIC and copilot were both unaware of the GCS wind speed display functionality so were not monitoring it for limit exceedances. They stated that if they had identified that the wind was in exceedance of limit that they would have taken actions to terminate the show.

Once the show had launched the copilot’s responsibilities as outlined in the operations manual were to monitor the airspace for relevant traffic, visually observe the swarm and to monitor it for fly aways. These 3 tasks required the copilot’s attention to be on the swarm and the surrounding airspace rather than detail displayed on the GCS computer. While the copilot visually identified aircraft out of position, they did not associate it with a wind speed limit exceedance.

Movement into the show area

As the aircraft moved into the show area along the pre‑programmed flight paths, the wind speed increases noticeably from 8.3 m/s to 18.5 m/s 40 seconds later. CCTV footage showed multiple aircraft in the upper layers of the show drop into the lower layers and collide with one another. The GCS displayed an increasing number of errors across all 3 categories. Not all errors were shown on the screen simultaneously so it was not possible to determine the exact number of aircraft presenting each error. However, the manufacturer’s analysis showed a maximum of 397 aircraft simultaneously recorded T errors indicating that they were out of position and the GCS recorded at least 11 aircraft presented with F errors indicating that they had breached the geofence. 

The RPIC’s last command to the swarm was to loiter, the manufacturer’s analysis confirmed that this command was received by aircraft in the swarm. The manufacturer’s analysis further identified that, due to the wind conditions the motors were unable to provide the required lift to remain airborne while attempting to maintain their position. The manufacturer reported that they subsequently descended into the water below their location. 

Human Factors

Pilot workload

All tasks require a level of cognitive load to process the information and undertake the activity. Workload is a measure of the amount of mental effort that is needed or expended to process this information. Humans have a limited capacity to process information, where the information processing required is close to, or exceeds, the human capability this is referred to as overload and can have multiple negative effects on performance. These effects can include, task shedding, attentional focusing, reduction in situational awareness, increased fatigue and the increased chance of errors. (United Kingdom Civil Aviation Authority, 2016)

The level of workload that an individual task requires varies depending on a range of factors. These include the difficulty of the task, familiarity and recency with the task, the number of other tasks that are being conducted concurrently and the time available to complete the task. (United Kingdom Civil Aviation Authority, 2016)

The completion of an RPAS light show requires flight crew to be familiar and interact with multiple systems including:

• the aircraft
• the various hardware and software elements of the GCS
• condition monitoring equipment
• operational processes and procedures.

The flight crew also need to interact with and manage support crew and stakeholders. The operator had procedures to mitigate this through the implementation of the multi‑crew operation requiring at least 2 flight crew members for shows of more than 10 aircraft. 

Workload review

A review of the operational environment in the lead‑up to and at the time the show was launched identified 2 factors that increased the RPIC’s workload above the normal level for show operations. These were the

• copilot’s limited experience in show operations
• RPIC’s lack of familiarity with adjusting the show position. 

Copilot experience

For this operation the operator’s chief remote pilot (CRP) was performing the role of copilot. At the time of the show the RPIC had completed almost twice as many shows as the copilot, and the copilot had only conducted a single show in the previous 6 months, which was on the Wednesday night before this show. While not required to be, the copilot was also not approved by CASA to operate in the RPIC role.

At interview both flight crew identified that the copilot had less experience in show operations compared to the RPIC and the copilot themselves identified that, while current, they were ‘rusty’ when it came to show processes and procedures. As a result, some tasks that were normally assigned to the copilot were carried out by the RPIC. The GCS recording captured the RPIC:

• actively managing various stakeholders and the show support crew
• ensuring that the show timings were met
• alerting the copilot of an aircraft fly away.

All these tasks were the responsibility of the copilot in the operator’s procedures. The RPIC reported that if they had been operating with a more current pilot the division of tasks would have been more equal, which would have reduced their mental load. 

The increased tasks that the RPIC carried out meant that they had to move from task to task rapidly, and work on multiple tasks concurrently. Both of which are known to increase workload. (United Kingdom Civil Aviation Authority, 2016)

RPIC lack of familiarity

On the night of the show the presence of the boat mast hazard meant that the RPIC had to reposition the show. Being unfamiliar with the required process, the RPIC elected to consult, by phone, with another pilot who was familiar with the system. 

The conversation between the RPIC and the other pilot had been prearranged for 1800, 30 minutes before the show launch time. However, the other pilot did not call back until 8 minutes later, leaving only 22 minutes before launch to effect the change. 

Subsequently the RPIC was preoccupied with tasks of moving the show for 18 of the 30 minutes leading up to the show. Based on the required actions it was assessed that, for someone familiar with the process and site, the move of the show could have been completed in about 5 minutes.

In summary, the combination of task unfamiliarity, time pressure and extra tasks due to the copilot’s limited show experience significantly increased the RPIC’s workload in the lead‑up to launch. That reduced the effectiveness of the wind speed assessment vital for the safety of the launch decision. 

Operational pressure

Pressure refers to a feeling of internal or external stress, which may not necessarily be based on actual urgency or necessity. This pressure can stem from various sources, such as tight schedules, stakeholder expectations or personal standards of performance. It can lead to rushed decisions, cutting corners or taking of unnecessary risks that can impact the safety of operations. (Ramdeen, 2024)

Multiple ATSB investigations and other publications have discussed the impact that personal, social or organisational pressures (perceived or actual) can have on pilot weather‑related decision‑making. In their safety leaflet about visual flight rules into instrument meteorological conditions (VFR into IMC) occurrences, (UK CAA, 2024) the United Kingdom Civil Aviation Authority (CAA) identified that as a pilot:

‘You may feel pressure to commence or continue a flight due to factors such as time constraints, passenger expectations, disruption to your personal life or the continuation bias of wanting to execute the intended plan. The effect of these pressures is sometimes referred to as ‘get-there-itis’ and can lead to a disregard for weather conditions or an overly optimistic interpretation of the situation, increasing the likelihood of a VFR into IMC scenario’

As a large public event an RPAS light show will likely place a level of pressure on the flight crew, and particularly the RPIC, for the show to go ahead. The operator’s procedures went some way to mitigating this hazard by assigning the copilot the task of stakeholder engagement to isolate the RPIC from the potential pressures. On this occasion however, the RPIC conducted this task. 

Factors known to increase pressure

A review of the operational environment on the night of the show identified a number of the factors that the CAA identified as likely to increase pressure. These, together with 2 other factors, are discussed in the following sections. 

Time constraints

To conduct the show, the harbour needed to be closed to keep vessel traffic out of the exclusion area. To minimise disruption the port authority provided a 15‑minute time window, starting at 1830, for the 10‑minute show. In the days leading up to the show the operator identified that the forecast conditions at the show time were going to be marginal and had requested that the show time be moved later. The operator advised that the port authority would not allow them to move the show later due to the impact on the harbour’s operations. This meant that the RPIC had to launch at 1830, or the show could not go ahead. 

Stakeholder expectation

RPAS light show operations do not involve passengers however there are other stakeholders who will have the same desire for a flight to go ahead and limited understanding of the operational requirements. In this case the client had expended significant capital and expected that the show would proceed. 

The RPIC advised that they had been in contact with the client’s representative on multiple occasions in the lead‑up to the show giving updates on conditions and what that meant for the likelihood of the show going ahead. The RPIC stated that they were aware that the client had other people waiting on the decision as to whether the show would proceed. 

Secondly, the recently appointed CEO and COO had limited experience with the light show operation and had travelled specifically to see this show and observe the operation in person. The RPIC advised that the CEO and COO had spoken with them in the lead‑up to the show and expressed a desire to see the show operate effectively.

Continuation bias

Continuation bias is ‘an unconscious cognitive bias to continue with the original plan in spite of changing conditions.’ (Transportation Safety Board of Canada, 2019) In a crewed operation continuation bias might appear as a pilot departing into questionable conditions on a route they have completed successfully a number of times before. It could also appear as a flight crew conducting multiple attempts to land at the destination airport rather than divert to a location where the conditions are more suitable. (Federal Aviation Administration, 2022)

The RPIC reported that the operator had never had to cancel a show due to wind conditions. Further, the RPIC’s records indicated that they had conducted more than 30 shows without incident. Therefore, continuing with the show launch was a familiar process and based on previous experience a negative outcome from this decision was not expected.

Additional factors 

The light show was being conducted in a populated area, had been advertised by the client and was supporting a national sporting team’s fixture, which was expected to draw a large crowd. The show therefore had a higher than normal profile that provided significant publicity and an opportunity to demonstrate the operator’s capability. 

On the night of the accident the copilot, as the operator’s CRP, held greater organisational authority than the RPIC. Despite the RPIC holding overall responsibility for the safe conduct of the flight, that pairing created a negative cockpit gradient. On multiple occasions during the lead‑up to the launch the copilot stated to the RPIC that they believed that the conditions are suitable for launch. While the RPIC identified that they were the ultimate authority onsite, the statements from the copilot potentially influenced their decision‑making.

Summary

The review of the operational environment identified that the RPIC was likely experiencing time pressure, expectations from the client and senior staff that the show would go ahead, an expectation bias as they had conducted many shows without a similar issue with these aircraft. As identified by the CAA these pressures can lead to a disregard or overly optimistic interpretation of the situation. Further increasing pressure the show had a higher than normal profile and there was a negative cockpit gradient between the RPIC and copilot. 

The operator’s report into the accident identified that the RPIC had been placed under additional pressure by external factors including: 

• the client engagement
• the time pressure from the time window available for the show to be carried out
• confidence in the fleet due to the number of successful shows that had been completed. 

Further, the RPIC identified directly that they had felt that there was pressure to have the show happen and for it to be successful.

Leading up to the show the RPIC had information that the weather conditions on the ground were near, but below, the limit of the aircraft but the conditions within the show area were unknown. An optimistic interpretation of conditions in the show area would be that the conditions were better or at least equivalent to those at ground level. Under this interpretation of the conditions they would have been acceptable for the show to go ahead. 

In crewed operations a poor weather‑related decision can put the aircraft, crew and passengers at risk of a fatal outcome. In uncrewed operations the primary risks relate to financial and reputational damage in the event of an incident or accident. While present, the risk to personal safety of the crew was low, which may have altered the flight crew’s risk perception or tolerance.

Operational requirements

To mitigate against the boat mast obstacle the RPIC elected to lift the entire show by 8 m above the originally planned maximum height of 118 m to a height of 126 m. The operator’s CASA permission required the RPIC to comply with their approved operations manual and subsequently operations library. The operations library stated that shows were not to be conducted at night above 120 m (400 ft) unless a specific approval had been approved by CASA, no such permission had been issued for this operation. 

At the time that they changed the show height the RPIC identified that they were in exceedance of the 400 ft limit. The phone discussion with the other pilot who was assisting in the show move identified that this was a minor breach of the limit, and it was mitigated by the presence of buildings that exceeded the maximum show height.

The CASA permission also required that the operations be conducted within an exclusion zone, which was detailed in the operations library. The role of the exclusion zone was to ensure that in the event of an aircraft loss of control, bystanders were maintained at a safe distance. For a maximum show height of 400 ft a minimum exclusion zone of 70 m was required. The exclusion zone set by the RPIC was not able to be precisely determined but was estimated to be between 47 and 54 m, from a publicly accessible jetty. 

The exclusion zone is calculated based on aircraft height and wind conditions. The RPIC’s decision to lift the show to avoid the boat mast meant that the planned exclusion zone of 70 m was no longer applicable. The zone should have been recalculated based on the new show height. For an 8 m (26 ft) increase in show height the exclusion zone should have been increased by about 4 m. Further, the wind speeds that the aircraft encountered, being more than twice the wind limit, increased the required exclusion zone to more than 100 m.

The available data did not identify the maximum height that aircraft reached or whether any aircraft exceeded the exclusion zone. However, as the flight was automated, if it had continued as planned it would have been in breach of both the maximum height and exclusion zone restrictions approved by the regulator. By not complying with these limitations safety defences built into the documentation and approval process were removed. While this did not contribute to the accident, it increased the risk of an adverse outcome.

Ground control station capability

Version 3 of the Damoda flight control software introduced a wind speed read out, showing wind speed and direction, in the top right corner of the display. Following launch, if the wind speed limit was exceeded, no active alert was shown on the GCS computer display. In its report, the manufacturer expressed a view that the flight crew should be actively monitoring the wind speed readout. 

An alert, visual, audible or tactile, improves the chance that the operator will be made aware of this information, especially when under high workload. In crewed aviation there are multiple alerts that are provided to pilots despite information already being presented independently to them. For example, aircraft are required to have an airspeed indicator but active stall warnings are commonly used.

The software displayed multiple types of alerts, which varied from individual aircraft showing single or multiple errors, through to pop‑up boxes advising that a command had failed to reach one or more aircraft. All were clearly identifiable on the screen and were easily interpreted by someone who was familiar with the system. 

For light show operations wind speed and direction are critical to the safety of flight. The small tolerances between aircraft and their relatively light weight means that changes in wind speed can significantly impact the aircraft position and lead to an increased risk of collisions.  

The implementation of an active alert to the wind speed monitoring function would improve the pilot’s ability to both identify and respond to wind speed exceedances. 

The RPIC stated that they were not aware of the wind speed readout at the time of the occurrence. Therefore, for an alert to have been effective in this instance it would have had to both identify the wind speed readout and the exceedance to the flight crew. As the alerting function did not exist, it was not possible to determine if it could have effectively done both these things. As such, the lack of an alert was not considered contributory to the accident. 

Pilot training

Following the introduction of version 3 of the GCS software, the operator’s pilots undertook familiarisation flights with the new software, and the manufacturer was consulted about issues when they were encountered. However, there was no formalised training, as there had been for an earlier version of the software, and there was no system of assessment in place to ensure that all pilots had an equivalent understanding of the software before they started using it operationally.

The operator had both initial training and proficiency requirements for pilots to ensure that they were competent in the systems that they would be expected to use. The ongoing proficiency checks were only required on the introduction of new aircraft types or annually or biennially, depending on how recently a pilot had completed operational flights. As such, if a pilot had recently been checked and a new software version was then introduced it could be up to 2 years of operational flying before their proficiency on the new software and understanding of all its features would be assessed.

The flight crew for this show were not aware of the wind speed indication function or confident in the process of moving the show. However, at least one other pilot was aware of these systems and how to effectively use them.

Without a timely verification process in place there was no way for the operator to know whether their familiarisation process had been effective and if the pilots understood how to use the relevant features in an operational environment. Had such a system been in place, it is more likely that the flight crew would have identified the wind speed limit exceedance and that moving the show would have been done more efficiently.

Operational document changes

The option of using weather drones to assess airborne conditions was introduced with version 1.1 of the wind management plan, dated 6 June 2023. This represented a significant change in the information gathering process for the wind speed information in the lead‑up to the show. The wind management plan, along with the event risk assessment, the emergency management plan and the maritime safety management plan, were available to the flight crew as attachments to the event operational plan. While the event plan was available, it was not a primary reference during preparations for the show. The show day and pre‑flight checklists were the primary references. 

As neither of these documents contained reference to either the weather drone or the wind management plan, subsequently the flight crew were less likely to use a weather drone to collect relevant information from the show area. That increased the risk of launching into unsafe flight conditions. 

It could not be determined whether inclusion of the information in the operator’s procedures would have altered the outcome of the accident as it was not known how or where this information would have been included in the operational procedures/documents. Additionally, as not all the procedures such as the show day checklist were routinely used, the inclusion of the weather drone option may not have been identified by the members of the flight crew, particularly given the high workload and time‑restricted environment in the lead‑up to show launch. 

Findings

From the evidence available, the following findings are made with respect to control issues and ditching involving RPA swarm of 500 Damoda Newton 2.2 RPA, Victoria Harbour, Docklands, Victoria on 14 July 2023. 

Contributing factors

• The remote pilot in command launched the show with the wind speed close to the limit of the aircraft and aware that conditions in the show area were likely to be worse than those on the ground.
• In the lead‑up to the show, the flight crew did not use a weather drone to conduct a wind check at show altitude as outlined in the operator's wind management plan. As a result, the remote pilot in command did not have accurate information about the conditions within the show area at the time they launched the swarm.
• Shortly after launch, before transitioning to the show area, the swarm encountered wind conditions that exceeded the aircrafts’ operational manoeuvring capability. This resulted in multiple aircraft being out of position and errors presenting on the ground control station computer.
• The flight crew were both unaware that the ground control station had a wind speed monitoring function. The remote pilot in command did not use it to monitor the wind conditions after take-off. As a result, they did not identify that the wind exceeded the aircrafts’ limits and continued with the transition to the show area.
• Shortly after starting the transition into the show area, the swarm encountered wind conditions that were more than double the published capability of the aircraft. This led to multiple aircraft being unable to hold position, with at least 11 aircraft breaching the geofence, multiple aircraft collisions and most aircraft descending into the water.
• The remote pilot in command's workload was significantly increased due to their unfamiliarity with the process to make the necessary show position adjustment and the copilot’s limited knowledge and experience in show operations. This reduced the effectiveness of the wind speed assessment vital for the safety of the launch decision.
• It is likely that the remote pilot in command perceived a higher than normal level of pressure for the show to go ahead. This combined with a higher than normal workload, contributed to their decision to launch the show into unknown wind conditions.

Other factors that increased risk

• The remote pilot in command programmed and launched the show with a maximum height which exceeded the 120 m limit and with an insufficient exclusion zone, both of which were limitations in accordance with the operator's CASA‑issued permission to conduct the shows. This increased the risk of injury to bystanders in the event of an aircraft malfunction.
• Version 3 of the Damoda ground control station software included a wind speed readout, but did not actively alert the pilot if the wind speed limit was exceeded. This increased the risk that a pilot would fail to identify a limit exceedance and continue a show into unsafe conditions. (Safety issue)
• The operator did not provide formal training on version 3 of the ground control station software to its pilots. Instead, relying on familiarisation flights and ad hoc advice from the manufacturer. This increased the risk that show-qualified pilots would fail to identify exceedances in flight critical parameters and experience increased workload. (Safety issue)
• Following the introduction of a weather drone option to the wind management plan in June of 2023, the operator had not updated its operational procedures to include this option. As a result, flight crew were not prompted to use this method for gathering information on wind conditions in the show area prior to launch. (Safety issue)

Safety issues and actions

No trigger in key operational documents to use weather drone

Safety issue number: AO-2023-033-SI-01

Safety issue description: Following the introduction of a weather drone option to the wind management plan in June of 2023, the operator had not updated its operational procedures to include this option. As a result, flight crew were not prompted to use this method for gathering information on wind conditions in the show area prior to launch. 

Ground Control Station pilot assurance

Safety issue number: AO-2023-033-SI-02

Safety issue description: The operator did not provide formal training on version 3 of the ground control station software to its pilots. Instead, relying on familiarisation flights and ad hoc advice from the manufacturer. This increased the risk that show-qualified pilots would fail to identify exceedances in flight critical parameters and experience increased workload. 

Safety recommendation to The Australian Traffic Network Pty Limited

Safety recommendation number: AO-2023-033-SR-02

Safety recommendation description: The Australian Transport Safety Bureau recommends that The Australian Traffic Network Pty Limited develops a process to ensure that future software changes are communicated and understood by all pilots before commencing operations.

Aircraft control software

Safety issue number: AO-2023-033-SI-03

Safety issue description: Version 3 of the Damoda ground control station software included a wind speed readout, but did not actively alert the pilot if the wind speed limit was exceeded. This increased the risk that a pilot would fail to identify a limit exceedance and continue a show into unsafe conditions.

Safety recommendation to Damoda Intelligent Control Technology Co., Ltd

Safety recommendation number: AO-2023-033-SR-01

Safety recommendation description: The Australian Transport Safety Bureau recommends that Damoda Intelligent Control Technology Co., Ltd implements active wind speed exceedance alerting in the ground control station software.

Safety action not associated with an identified safety issue

Additional safety action by The Australian Traffic Network Pty Limited

The Australian Traffic Network Pty Limited advised the ATSB that following this incident it implemented several changes to its show planning and conduct processes. These included:

• changes to the crewing requirements to have 2 CASA-approved pilots operating every show
• establishment of multiple go/no-go points during the launch sequence allowing for more clearly defined stop points
• introduction of sterile cockpit procedures to limit outside interactions with the flight crew in critical phases in the lead‑up to show launch.

Glossary

Sources and submissions

Sources of information

The sources of information during the investigation included:

• the remote pilot in command and copilot
• The Australian Traffic Network Pty Limited
• the aircraft and ground control station software manufacturer
• Civil Aviation Safety Authority
• another Australian operator of the type
• ground control station software screen recording
• Bureau of Meteorology
• video footage of the accident flight and other photographs and videos taken on the day of the accident

References

Federal Aviation Administration. (2022). CFIT and Plan Continuation Bias. Washington DC: United States Department of Transportation.

Ramdeen, A. (2024, 04). Performing Under Percieved Pressure in Aviation Maintenance. Naval Safety Command Aviation Safety Blog.

SKYbrary. (2025, May). Authority Gradients. Retrieved from SKYbrary: https://skybrary.aero/articles/authority-gradients

Transportation Safety Board of Canada. (2019). AIR TRANSPORTATION SAFETY INVESTIGATION REPORT A18P0031 Loss of control and collision with terrain Island Express Air Inc. Beechcraft King Air B100, C-GIAE Abbottsford Airport, British Columbia 23 February 2018. Quebec: Transportation Safety Board of Canada.

UK CAA. (2024). VFR Flight Into IMC - CAP 2562. London: UK CAA.

United Kingdom Civil Aviation Authority. (2016). Flight crew human factors handbook. West Sussex: United Kingdom Civil Aviation Authority.

Submissions

Under section 26 of the Transport Safety Investigation Act 2003, the ATSB may provide a draft report, on a confidential basis, to any person whom the ATSB considers appropriate. That section allows a person receiving a draft report to make submissions to the ATSB about the draft report. 

A draft of this report was provided to the following directly involved parties:

• remote pilot in command
• Australian Traffic Network Pty Ltd chief remote pilot
• Aircraft and GCS software manufacturer
• Civil Aviation Safety Authority

Submissions were received from:

• remote pilot in command
• Australian Traffic Network Pty Ltd chief remote pilot

The submissions were reviewed and, where considered appropriate, the text of the report was amended accordingly.

Appendices

Appendix A – Ground control station recording summary

Purpose of safety investigations The objective of a safety investigation is to enhance transport safety. This is done through:  identifying safety issues and facilitating safety action to address those issues providing information about occurrences and their associated safety factors to facilitate learning within the transport industry. It is not a function of the ATSB to apportion blame or provide a means for determining liability. At the same time, an investigation report must include factual material of sufficient weight to support the analysis and findings. At all times the ATSB endeavours to balance the use of material that could imply adverse comment with the need to properly explain what happened, and why, in a fair and unbiased manner. The ATSB does not investigate for the purpose of taking administrative, regulatory or criminal action. Terminology An explanation of terminology used in ATSB investigation reports is available here. This includes terms such as occurrence, contributing factor, other factor that increased risk, and safety issue. Publishing information Released in accordance with section 25 of the Transport Safety Investigation Act 2003 Published by: Australian Transport Safety Bureau © Commonwealth of Australia 2025 Ownership of intellectual property rights in this publication Unless otherwise noted, copyright (and any other intellectual property rights, if any) in this report publication is owned by the Commonwealth of Australia. Creative Commons licence With the exception of the Commonwealth Coat of Arms, ATSB logo, and photos and graphics in which a third party holds copyright, this report is licensed under a Creative Commons Attribution 4.0 International licence. The CC BY 4.0 licence enables you to distribute, remix, adapt, and build upon our material in any medium or format, so long as attribution is given to the Australian Transport Safety Bureau.  Copyright in material obtained from other agencies, private individuals or organisations, belongs to those agencies, individuals or organisations. Where you wish to use their material, you will need to contact them directly.

Section 21 (2) of the Transport Safety Investigation Act 2003 (TSI Act) empowers the ATSB to discontinue an investigation into a transport safety matter at any time. Section 21 (3) of the TSI Act requires the ATSB to publish a statement setting out the reasons for discontinuing an investigation. The statement is published as a report in accordance with section 25 of the TSI Act, capturing information from the investigation up to the time of discontinuance.

Overview of the investigation

The ATSB commenced an investigation into a collision between freight train Y375 and an unoccupied excavator that occurred at Fairfield station, Queensland, on 15 July 2023. The serious incident occurred during completion of a major construction project at Fairfield station that included the demolition of the existing railway station and timber pedestrian overpass, construction of a new railway station, pedestrian overpass bridge and supporting non‑rail and rail infrastructure, dual gauge line lowering, equipment removal and replacement, signalling works, and rail shutdown periods.

Workers had earlier departed the Fairfield work site leaving it unoccupied at the time of the collision. There were no injuries to the train crew and freight train Y375 sustained minor damage.

The occurrence

Construction at Fairfield station

Work preparations commenced around 0200 local time for the inner‑city scheduled corridor access system (SCAS)[1] shutdown between Dutton Park and Rocklea stations on the Queensland Rail (QR) network. This shutdown was separated into zones, with Fairfield station specifically falling under local possession authority permit E on the up and down suburban lines, and track authority number 2 (TA2) on the dual gauge rail line.[2] All of the possessions for the shutdown were managed by a possession protection officer based at the QR Yeerongpilly depot.

A workgroup supervisor, employed by UNITY Alliance (UNITY), arrived at Fairfield station at 0530 to prepare for planned work between 0600‍–‍1800. Following a pre‑work brief with about 50 participants, activities outside of the danger zone began.

At 0837, worksite permit E became active, covering both the up and down suburban lines at Fairfield station, under which multiple workgroups operated. Between 0910 and 1122, 9 workgroups formally signed onto the multiple workgroup register at Yeerongpilly depot for tasks on the suburban lines. The Fairfield station workgroup supervisor signed on at 1030.

Concurrently, at 0858, TA2 was issued by the network control officer (NCO) for the dual gauge line passing through Fairfield station, with 7 workgroups signing on to its register between 0900 and 1343 at Yeerongpilly depot. The Fairfield station workgroup supervisor signed on at 1343, and following staff locking onto local lockboxes,[3] planned work proceeded on both the suburban and dual gauge lines.

At approximately 1647, a decision was made to leave machinery, including an excavator, on the dual gauge line and danger zone, due in combination to access challenges and in preparation for work the following day.

From about 1730, construction at Fairfield station began to close down for the day with workers locking off from the local lock box and departing the site. At about 1745, the work group was clear of both the suburban and dual gauge lines with the local lock boxes free of padlocks. The workgroup supervisor remained at Fairfield station to finalise the day. At about 1815, the workgroup supervisor left Fairfield station and drove to the Yeerongpilly depot, and at 1826 they signed out from permit E on the up and down suburban line leaving the checkbox (declaring the track was clear) unticked, see Figure 1.

Figure 1: Sign in and out permit E from the suburban line

Source: Queensland Rail, annotated by the ATSB

Immediately following, the workgroup supervisor signed out from TA2 (Figure 2) at 1828 and ticked the checkbox denoting:

When signing out, I acknowledge that all members of the workgroup are accounted for, in a safe place and that the track within the area they were working is clear of any obstructions and fit for service.

The possession protection officer recalled that they had confirmed twice with the workgroup supervisor that the track was clear. The workgroup supervisor then left the depot and completed their shift.

Figure 2: Sign in and out of track authority number 2 from the dual gauge

Note: The planned finish date of 17-7-23 was incorrectly shown on the multiple work group register, instead, it should have shown 15‑7‑23. Source: Queensland Rail, annotated by the ATSB

Freight operations

Concurrent to ceasing the daily work at Fairfield, at about 1750, rail traffic crew (one driver) signed on for duty at Fisherman Island to operate Aurizon freight train Y375 from Fisherman Island to Maryborough, Queensland. The train departed Fisherman Island at about 1806. When performing a radio check, the QR NCO informed the rail traffic crew that their train would be held at signal CH7, located at Cannon Hill, until the dual gauge line was opened. The train arrived at signal CH7 at about 1829 and waited for the signal to show a proceed indication.

At about 1936, the stop boards protecting the dual gauge line were removed. At 1939, TA2 protection was removed by network control and at 1941 the dual gauge line opened for rail traffic.

Train Y375 received a green proceed indication from signal CH7 and departed at 1945. It then travelled south towards Fairfield station on the dual gauge line. Train Y375 gradually increased speed to a maximum speed of 51 km/h, then the speed gradually decreased approaching Fairfield station.

Train Y375 approached the station at about 23 km/h, below the posted limit of 60 km/h, with main headlights off (as is usual practice in suburban areas), ditch lights on and the throttle controller set to notch 3.

Just prior to Fairfield platform, the driver noticed a dark shadow on the track ahead. At 2001:53, the driver switched on the main headlight, applied the brakes, throttle controller to idle, and sounded the train horn. The train was travelling at about 20 km/h when at 2002:00 it collided with an excavator (DCC006) on the dual gauge line (Figure 3). The train had initially impacted the excavator blade, with the boom arm facing the other direction.

The impacted excavator was pushed into adjacent machinery that was parked on an adjacent vehicle access pad located between the dual gauge line and corridor boundary fence. The excavator impacted a Hydrema dump truck and another excavator (DCC05), then was pushed alongside the track by the passage of the train, before coming to rest between a retaining wall and the leading locomotive. The train stopped at 2002:16, about 55 m from the initial collision point (Figure 4 and Figure 5). No workers were on the machinery or track at the time of the collision, and the driver was uninjured.

At 2002:21, the driver of train Y375 transmitted ‘emergency emergency emergency’ over the train radio. The NCO responded to the driver and confirmed details of the collision, occupancy of the excavator, and location. In a following communication with the NCO, at 2005:38, the driver advised that another item (elevated work platform) was on the track ahead of the train (Figure 3).

Figure 3: Fairfield station closed circuit television footage at 2001:56 showing train Y375 just prior to it impacting the construction equipment

Source: Queensland Rail, annotated by the ATSB

Figure 4: Collision site at Fairfield station

Source: Google Earth, annotated by the ATSB

After the incident, the damaged machinery was cleared and about 0730 the following day, train Y375 departed the site following minor repairs. The dual gauge line was again closed at about 1110 through a track authority for continuation of the construction work at Fairfield station.

Site information

Fairfield station has platforms for the up and down suburban line and a platform for the dual gauge line. The 5 t excavator (DCC06) that was parked on the dual gauge line was pushed about 15 m by the leading locomotive, in the process colliding with a 10 t articulated rear dump truck that was parked on the vehicle access pad. Alongside the dump truck on the pad, was a Hitachi 5 t excavator (DCC05), which was also impacted.

Excavator DCC06 came to rest on the ballast shoulder between the locomotive and a retaining wall, spun around 180° from the original position. Train Y375 stopped about 5 m further from excavator DCC06 (Figure 5), but short of another item of machinery, a mobile elevated work platform Skyjack SJ60AJ+, parked on the track at the end of the station platform. The locomotive front cowling contacted the excavator blade in the first instance.

Figure 5: Train Y375 following the impact at Fairfield station 

Source: Queensland Rail, annotated by the ATSB

The work at Fairfield station

The construction work at Fairfield station was part of the Cross River Rail project. The Cross River Rail project was being delivered through 3 major works packages:

• The Rail, Integration and Systems (RIS) package – delivered by UNITY.
• The Tunnel, Stations and Development package – delivered by PULSE.
• The European Train Control System package – delivered by Sequence Alliance.

The work at Fairfield station was being delivered through the RIS package. The client for that package was the Cross River Rail Delivery Authority. The RIS package alliance consisted of non‑owner construction participants operating as the UNITY comprising 4 non‑owner participants:

• CPB Contractors
• UGL Engineering
• AECOM Australia
• Jacobs Group (Australia).

The participants had entered into a project agreement with QR and the Cross River Rail Delivery Authority (acting as owners on behalf of the State of Queensland). UNITY was contracted to deliver the RIS package, which is depicted in Figure 6.

Figure 6: Major rail and associated infrastructure projects

Source: Queensland Audit Office, Audit Brief 20 January 2025, Major Projects 2024, Report 9: 2024-25, Figure 4B Major rail and associated infrastructure projects (estimated expenditure as of 30 June 2024), page 24

Proactive safety actions

CPB Contractors

Following a post‑incident investigation, CPB Contractors made the following recommendations:

• UNITY to develop an agreed track clearance process that requires secondary evidence to confirm that a site walk has occurred as required, and that this has been verified by a second UNITY worker or QR personnel. As part of this process, an inspection checklist and associated guidance document will be developed and implemented. Checklist to be completed by the worksite supervisors prior to any track being handed back to the QR protection officer.
• UNITY should impose a clear requirement that UNITY construction supervisors clear track of all plant and equipment at the conclusion of the shift and this should be recorded by UNITY with photographic evidence that the track is clear.
• Senior management provision of guidelines on the priorities of attending the T-1 meetings[4] and familiarity with the content of the UNITY possession summary document prior to SCAS occurring and additional guidance on the use of the track protection and access board. The provision of resources as needed to achieve those goals.
• UNITY to develop a process for accountability for personnel attendance requirements in T-1 meetings and providing required information to those who do not attend.
• Pending agreement by QR to a new safety supervisor process, as an interim measure UNITY’s construction supervisor to be accompanied by either the UNITY superintendent or QR supervisor during physical inspection of track before confirming to protection officer that all workers have been accounted for, are clear of the worksite and the line is clear and fit for use.
• QR subject matter expert to provide UNITY supervisors with additional training beyond mandatory training that clarifies the roles and responsibilities of the possession protection officer, protection officer and worksite supervisors when working in the danger zone under the worksite protection, as a means of increasing competency and understanding of those supervisors particularly while performing roles under MD‑14‑166.[5]

Queensland Rail

Following the collision, QR initiated several safety actions, including:

• QR and UNITY stopped work on sites until all works could be confirmed safe.
• A meeting was held between the group executive, Major Projects Integration, the program director of UNITY and head of south‑east Queensland to confirm an action plan to ensure track access safety.
• Reviewing the UNITY investigation report and proposed corrective actions to determine suitability against QR’s requirements as the rail infrastructure manager.
• Schedule and complete a 2nd line compliance and assurance activity to review the implementation of identified UNITY corrective actions.
• QR and UNITY to facilitate appropriate change management regarding any changes to established ways of working to ensure QR is satisfied with the proposed changes.
• Reviewing the existing network pre‑start briefing (documented in MD‑15‑43) requirements throughout the safety and environment management system to implement consistent requirements for the application and acknowledgment of the network pre‑start briefing.
• Reviewing existing requirements regarding rail safety responsibilities of workgroup supervisor/worksite supervisors/person in charge of the workgroup and consider the development of role specific training/qualification requirements.
• Developing rail safety/safeworking assurance program/tools in consultation with relevant business areas to monitor and report compliance with QR’s safety management system requirements.
• Reviewing the multiple workgroup register form increasing the prominence of the sign off declaration.
• Reinforcing the CPB Contractors track clearance process.

Reasons for the discontinuation

The ATSB strives to use its limited resources for maximum safety benefit, and considers that in this case, based on a review of the available evidence, it was unlikely that further investigation would identify any systemic safety issues or important safety lessons. Consequently, the ATSB has discontinued this investigation. The subsequent proactive safety actions undertaken by the involved parties have been published for the interests of transport safety. 

The evidence collected during this investigation remains available to be used in future investigations or safety studies. The ATSB will also monitor for any similar occurrences that may indicate a need to undertake a further safety investigation.

The investigation

Decisions regarding the scope of an investigation are based on many factors, including the level of safety benefit likely to be obtained from an investigation and the associated resources required. For this occurrence, a limited-scope investigation was conducted in order to produce a short investigation report, and allow for greater industry awareness of findings that affect safety and potential learning opportunities.

The occurrence

On 6 July 2023, the pilot of a Piper Aircraft Inc. PA-28-181 (PA-28), registered VH-SFA and operated by Schofields Flying Club Limited, was conducting a return solo navigation training flight from Bankstown Airport, New South Wales. The planned flight involved a touch-and-go landing at Shellharbour with a full stop landing at Goulburn, New South Wales before returning to Bankstown.

The PA-28 departed Bankstown at 0931 local time, arriving in the Shellharbour common traffic advisory frequency (CTAF) broadcast area (see the section titled Shellharbour Airport) at 1000. The pilot recalled that the Shellharbour airspace was very busy, and that they conducted a go‑around during their first approach due to traffic congestion. After conducting a circuit, the pilot elected to conduct a full stop landing in order to make use of the facilities and at around 1010, parked the PA-28 on the regular public transport (RPT) apron (Figure 1).

During this time, a Saab 340B (Saab), registered VH-VED and operated by Link Airways as flight FC251, was enroute to Shellharbour from Brisbane, Queensland. At 1041, while on descent, the flight crew broadcast on the CTAF that the aircraft was at 30 NM inbound to the airport. The Saab ground crew observed the PA-28 in the parking bay that had been allocated to the Saab and advised the pilot, over the radio, that an aircraft was inbound for that bay.

Figure 1: Shellharbour Airport layout

Source: En Route Supplement Australia, annotated by the ATSB

There were multiple VFR[1] aircraft in the Shellharbour CTAF area and the pilot monitoring (PM)[2] in the Saab made a series of broadcasts to other aircraft to organise separation and sequencing for their arrival. At 1051, after flying a circuit, the Saab turned onto a 3-mile final for runway 34.[3] At 1052, the pilot of the PA-28 made a radio broadcast advising they were taxiing for runway 34. Neither of the Saab flight crew recalled hearing this transmission. At 1053, the Saab flight crew made a radio broadcast, advising that they would be backtracking on the runway and subsequently landed on runway 34.

The PA-28 pilot taxied to, and held, at holding point Hotel (Figure 1) where they observed the Saab land and commence a turn to the right. Being unaware of the intended backtrack, they incorrectly assumed that the Saab would exit the runway on taxiway Alpha and taxi to the RPT apron. They then diverted their attention to other traffic in the circuit.

At 1054, after identifying a gap in the traffic, the PA-28 pilot broadcast that they were entering the runway using the non-standard phraseology ‘turning on runway 34’. The PM in the Saab, in the turn to backtrack the runway, immediately replied, advising that they would be backtracking runway 34, however the PA-28 pilot did not hear this transmission. The PA‑28 pilot reported that, with the large number of aircraft in the circuit they felt pressured to commence the take-off as soon as possible and forgot to make a rolling call prior to commencing their take-off run. They further stated that as the aircraft accelerated past 50 kt, and towards the rotation speed, they saw the Saab appear to re-enter the runway at taxiway Alpha.

The pilot flying (PF) in the Saab advised that they ensured the landing lights were left on to aid in detection while on the runway. They also stated that, as right circuits were required when using runway 34, they made the reversal turn to the right on the runway to enable them to view the traffic in the circuit. As they realigned with the runway centreline to commence the backtrack, the PF noticed the PA-28 appeared to be rolling on the runway towards them. The PM attempted to contact the pilot of the PA-28, however, other aircraft in the circuit made broadcasts about this time, possibly over transmitting the call by the PM, and the transmission from the Saab was not heard by the pilot of the PA-28. In order to minimise the risk of collision with the approaching aircraft, the PF taxied the Saab to the western side of the sealed runway surface (Figure 2).

Figure 2: Aircraft avoiding action

The dashed lines show the approximate paths over the ground of each aircraft. The track of VED is based on recorded ADS-B data. The track of SFA is based on pilots’ statements.

Source: Google Earth, annotated by the ATSB

The PA-28 pilot, seeing the Saab on the runway ahead of them, initially hesitated. They advised they had never conducted a rejected take-off during their training and reported being unsure of the expected braking performance and the handling behaviour when using rudder steering.

During the period of hesitation, the aircraft continued to accelerate towards the rotation speed of 60 kt. The pilot then assessed that the distance between the 2 aircraft was sufficient to continue the take-off. Additionally, they perceived that any attempt to stop the aircraft on the runway remaining was not assured and may have resulted in a ground collision. Based on the avoiding action taken by the Saab crew, they continued the take-off and rotated prior to the runway intersection, before slowly veering to the eastern side of the runway (Figure 2) and passing approximately 150 ft over the left wing of the Saab (Figure 3).

Figure 3: CCTV footage

Source: Shellharbour Airport CCTV. Annotated by the ATSB

Context

VH-SFA pilot training

The pilot commenced flight training with the flying school in January 2023 after obtaining their recreational pilot licence (RPL) with another training school. English was not their first language, but they had demonstrated the required fluency and competency on the radio to obtain this licence. The pilot had accrued approximately 110 hours total time, 22 hours of which was as pilot in command. A review of their training records indicated that they had flown with 6 different instructors for the 14 flights since commencing with the flying school. They had recently been approved to commence solo navigation training to obtain their private pilot licence (PPL). The occurrence flight was the third solo navigation flight completed by the pilot.

Various comments had been made in the training records regarding inconsistencies in their procedural rigour, times of reduced situational awareness and the use of non-standard radio calls and phraseology.

The flying school confirmed that aborted take-off practice was delivered as part of the RPL syllabus of training, and as such had not been covered in the pilot’s training with them. However, a review of the pilot’s training file from their previous training provider indicated that the pilot had been assessed as achieving the required competency during the emergency circuit lessons in the RPL syllabus in November 2021, where rejected take-offs were conducted from simulated engine failures during the take-off run.

Planned navigation exercise

The exercise was originally planned via Bathurst, however the weather forecast along this route included low cloud over the Blue Mountains. The supervising instructor, responsible for signing out solo students that day, recognised this and changed the planned route to avoid the low cloud. The forecast weather along the revised navigation route was favourable for flight under the visual flight rules, with good conditions at Shellharbour for the aircraft’s scheduled time of arrival.

This was the student’s fourth visit to Shellharbour during their training; however, they had never stopped there before. All previous visits had involved touch-and-go landings or circuit training with an instructor. As the flight plan only included a touch-and-go landing, the taxiways were not briefed prior to the flight.

Shellharbour Airport

Shellharbour Airport (Figure 1) has two intersecting sealed runways 16/34 and 08/26. Runway 34 was in use at the time of the occurrence and had a 0.1% down slope to the north. The view of the entire runway from the threshold marker was clear of obstructions with good visibility (Figure 4).

Figure 4: View from the runway 34 threshold

Source: Shellharbour aerodrome operator.

The Enroute Supplement Australia (ERSA) facilities page detailed local procedures and restrictions. A note under ‘Local traffic regulations’ detailed a maximum weight restriction of 5,700 kg for taxiways Alpha and Bravo which run parallel to runway 34. As a result of this weight limitation, heavier aircraft such as the Saab 340 were required to backtrack along the runway to the intersection of the runways where they could then vacate via taxiway Delta for the RPT apron (Figure 1). The flying school’s internal investigation of this occurrence identified that the student was unaware of this limitation and was briefed by an instructor on their return to Bankstown.

The Shellharbour CTAF operates on a discreet frequency of 127.3. This frequency is the primary means of communication between aircraft operating in the vicinity of the aerodrome with the aerodrome receiving a mix of general aviation and regular public transport aircraft. Both the PA-28 pilot and the Saab flight crew described the airspace as typically being very busy when the weather was good. This was probably due to the number of flying school aircraft that use Shellharbour for circuit training and as an intermediate waypoint on navigation exercises.

Communication

Operations in the vicinity of non‑controlled aerodromes require flight crew to be aware of other aircraft that may be operating in the area by maintaining a listening watch on the radio and, if necessary, making radio broadcast to organise collision avoidance and sequencing. Communication is key to developing awareness, and guidance has been produced to standardise radio transmissions and phraseology to assist with effective and efficient radio communication.

Civil Aviation Safety Regulations 1998 Part 91 – Manual of Standards Chapter 21 listed the broadcast and reporting requirements for non-controlled CTAF airspace (Table 1).

Table 1: CTAF – prescribed broadcasts

Situation	Frequency	Requirement
When the pilot in command considers it reasonably necessary to broadcast to avoid the risk of a collision with another aircraft.	CTAF	Broadcast

In addition to this prescribed broadcast requirement, guidance in Civil Aviation Advisory Publication 166-01 v4.2 Operations in the vicinity of non-controlled aerodromes; and the Visual Flight Rules Guide produced by the Civil Aviation Safety Authority provided a list of recommended radio broadcasts to mitigate the risk of a collision in the CTAF (Table 2).

Table 2: Recommended positional broadcasts in the vicinity of a non-controlled aerodrome

A recording of the CTAF frequency at the time of the occurrence was obtained and provided a record of what broadcasts were made by the Saab flight crew and the PA-28 pilot. A summary of the key communication events appears in Table 3.

Table 3: Shellharbour CTAF radio broadcasts

During the time the Saab commenced their approach and the PA-28 departed, a number of radio transmissions were unreadable, probably due to different aircraft making simultaneous radio broadcasts. Significantly, one of these transmissions coincided with the report of the PM in the Saab trying to alert the pilot of the PA-28 to the conflict on the runway. Additionally, the crew of both aircraft reported missing radio transmissions from the other aircraft involved in the occurrence and having limited opportunity to make broadcasts due to the number of aircraft in the circuit.

A review of the radio broadcasts made around the time of the occurrence confirmed that in addition to the 2 occurrence aircraft on the runway, there was 1 aircraft departing from mid‑downwind overhead the field, and 3 other aircraft in the circuit.

Aircraft performance calculations

The estimated braking performance for a Piper PA-28 Archer II was used to determine the approximate distance to reject a take-off in the prevailing conditions. Calculations were based upon actual weather observations recorded by the Bureau of Meteorology at Shellharbour, pilot interviews, and the take-off and landing performance charts in the PA-28 Archer II pilot operating handbook (POH). To this calculation, the applicable landing safety factor recommended in CASA guidance material[4] was applied. The calculations are presented in Figure 5 and show the distance to accelerate to 50 kt and reject the take-off.

The point where the aircraft reached 50 kt and the PA-28 pilot first sighted the Saab was based on the interview with the pilot of the PA-28. Calculations were based on the aircraft commencing take-off from the threshold of runway 34 and not from runway entry at holding point Hotel. The pilot’s reported hesitation was not accounted for in this calculation.

Figure 5: Calculated braking performance in the event of a rejected take-off by VH-SFA

Source: Google Earth annotated by the ATSB.

Safety analysis

A review of the radio broadcasts that were made on the CTAF frequency supported the pilots’ assessment that the Shellharbour CTAF was busy on the day of the occurrence, increasing their workload and hampering effective radio communication. In this environment, both crew missed radio transmissions from the other aircraft involved in the occurrence. The use of non-standard phraseology from the PA-28 pilot as they entered the runway was unclear in its intentions and open to interpretation. Despite this, the Saab crew appear to have understood the intent as they immediately restated that they were backtracking the runway. Significantly, this transmission was missed by the PA-28 pilot who commenced the take-off without making a rolling call or confirming with the Saab crew that they were clear of the runway. It was determined that in the context of a busy radio frequency there was little opportunity for the Saab crew to make an additional broadcast due to transmissions made by other aircraft around this time.

Despite the impact on communication, there were multiple opportunities for the pilot of the PA-28 to identify that the Saab had not vacated the runway. They recalled observing the Saab commence a right turn on the runway, indicating they had an unobstructed view of the aircraft from the holding point and threshold of runway 34. However, they did not continue to monitor the Saab and diverted their attention to the traffic in the circuit. The decision to expedite the take‑off was influenced by self-imposed time pressure due to the traffic density. The pilot was aware that they should not have taken off from an occupied runway, indicating that they would not have done so if they had detected the conflict.

Once the pilot of the PA-28 detected the Saab on the runway, their response further added to the potential for a collision. Based on the descriptions provided by the crew of where each aircraft was located on the runway at the time the conflict was detected by the pilot of the PA-28, braking performance calculations showed that there was most likely enough room to stop in the distance available.

Although the pilot advised they had never conducted a rejected take-off during their training, training records indicated the required competencies had been demonstrated, however this was 19 months prior to the occurrence. These sessions involved the student rejecting a take-off in response to a simulated engine failure during the take-off roll. While the student had been assessed as competent, it could not be determined if the training scenario provided an accurate assessment of the pilot’s threat identification and decision-making skills. There was no record of an additional rejected take-off training assessment. In practice, the manipulation of controls to reject a take-off is similar to those required to stop an aircraft following normal and maximum performance landings. It is therefore unlikely that the pilot would have encountered control characteristics that they were not familiar with.

Student records indicated the PA‑28 pilot was familiar with Shellharbour circuit procedures, having previously flown there with instructors and on a solo navigation exercise. However, as these previous flights did not include full-stop landings, it is reasonable that taxiways not intended to be used as part of this exercise were not discussed during the pre-flight briefing. However it also meant that the pilot was unaware that larger aircraft, such as the Saab, could only access the apron by backtracking along the runway.

While detail of the taxiway restrictions are provided in the local regulations section of the Enroute Supplement Australia facilities page, a specific warning entry (such as already published for another airport hazard) that alerts inexperienced pilots to the possibility that taxiway restrictions require larger aircraft to backtrack along the runway could:

• prompt pilots to check that aircraft are actually clear of the runway prior to commencing their own take-off
• reduce the likelihood of misidentifying the turn to backtrack as the aircraft vacating the runway.

Findings

ATSB investigation report findings focus on safety factors (that is, events and conditions that increase risk). Safety factors include ‘contributing factors’ and ‘other factors that increased risk’ (that is, factors that did not meet the definition of a contributing factor for this occurrence but were still considered important to include in the report for the purpose of increasing awareness and enhancing safety). In addition ‘other findings’ may be included to provide important information about topics other than safety factors.  These findings should not be read as apportioning blame or liability to any particular organisation or individual.

From the evidence available, the following findings are made with respect to the runway incursion involving a Piper PA-28, VH-SFA, and Saab 340, VH-VED, at Shellharbour Airport, New South Wales on 6 July 2023.

Contributing factors

• The PA-28 pilot did not hear the backtracking broadcast from the Saab, reducing their awareness of the conflict on the runway.
• Although the PA-28 pilot observed the Saab commence a turn at the end of its landing roll on the runway, the pilot incorrectly assessed the aircraft had vacated the runway prior to commencing their take-off.
• The PA-28 pilot continued the take-off from an occupied runway and departed overhead the Saab that was backtracking the runway.

Other factors that increased risk

• The busy traffic environment at the time of the occurrence impacted the effectiveness of radio communication and increased both flight crews’ workload.

Safety actions

Safety action by Schofields Flying Club

Schofields reviewed their procedures for onboarding students trained by other organisations. All students are now required to commence training from the beginning of the relevant syllabus, or, after a formal assessment by the Head of Operations, they may be considered to enter the syllabus at a higher level. Additional safety action was taken to reduce the number of students allocated to each instructor, improving oversight, and the introduction of competency standards discussions during fortnightly flight instructor meetings.

Safety action by Link Airways

Following an internal review of the occurrence, Link Airways revised company guidance for operations into Shellharbour. Due to the workload and identified potential for conflict with VFR aircraft in the circuit, the requirement to conduct an instrument approach for all arrivals or a 10 NM final approach leg has been removed. Flight crew are reminded to make all required radio calls to maintain situational awareness and to review the CASA publication BE HEARD, BE SEEN, BE SAFE – Radio procedures in non-controlled airspace.

Sources and submissions

Sources of information

The sources of information during the investigation included:

• the occurrence pilots
• Schofields Flying Club
• Link Airways
• Bureau of Meteorology
• Civil Aviation Safety Authority
• the aircraft manufacturer
• Shellharbour Airport
• video footage of the flight
• aircraft ADS-B data.

References

Piper Aircraft Corporation (1975). Piper Cherokee Archer II Pilot’s Operating Handbook.

Submissions

Under section 26 of the Transport Safety Investigation Act 2003, the ATSB may provide a draft report, on a confidential basis, to any person whom the ATSB considers appropriate. That section allows a person receiving a draft report to make submissions to the ATSB about the draft report.

A draft of this report was provided to the following directly involved parties:

• the occurrence pilots
• Schofields Flying Club
• Link Airways
• Civil Aviation Safety Authority

Submissions were received from:

• Link Airways
• Schofields Flying Club

The submissions were reviewed and, where considered appropriate, the text of the report was amended accordingly.

Purpose of safety investigations The objective of a safety investigation is to enhance transport safety. This is done through: identifying safety issues and facilitating safety action to address those issues providing information about occurrences and their associated safety factors to facilitate learning within the transport industry. It is not a function of the ATSB to apportion blame or provide a means for determining liability. At the same time, an investigation report must include factual material of sufficient weight to support the analysis and findings. At all times the ATSB endeavours to balance the use of material that could imply adverse comment with the need to properly explain what happened, and why, in a fair and unbiased manner. The ATSB does not investigate for the purpose of taking administrative, regulatory or criminal action. Terminology An explanation of terminology used in ATSB investigation reports is available here. This includes terms such as occurrence, contributing factor, other factor that increased risk, and safety issue. Publishing information Released in accordance with section 25 of the Transport Safety Investigation Act 2003 Published by: Australian Transport Safety Bureau © Commonwealth of Australia 2023 Ownership of intellectual property rights in this publication Unless otherwise noted, copyright (and any other intellectual property rights, if any) in this report publication is owned by the Commonwealth of Australia. Creative Commons licence With the exception of the Coat of Arms, ATSB logo, and photos and graphics in which a third party holds copyright, this publication is licensed under a Creative Commons Attribution 3.0 Australia licence. Creative Commons Attribution 3.0 Australia Licence is a standard form licence agreement that allows you to copy, distribute, transmit and adapt this publication provided that you attribute the work. The ATSB’s preference is that you attribute this publication (and any material sourced from it) using the following wording: Source: Australian Transport Safety Bureau Copyright in material obtained from other agencies, private individuals or organisations, belongs to those agencies, individuals or organisations. Where you wish to use their material, you will need to contact them directly.