Poor software design led to second £1m Army spy drone crash

Thales Watchkeeper WK006 dived itself into Boscombe Down's runway

A British Army Watchkeeper drone lands at Parc Aberporth. Crown copyright
Thales Watchkeeper drone WK005, sister drone of the crashed aircraft. Crown copyright

An Army Watchkeeper drone flown by the Royal Artillery crashed on landing after its crew selected the self-flying craft’s “master override” function, according to the official report into the accident.

Thales Watchkeeper drone WK006 flopped into the runway at Boscombe Down airfield in November 2015 when its two-man crew, operating it from a ground station at the airfield, engaged the override after the craft twice attempted and failed to make a safe landing.

The £1m unmanned aircraft had to be written off thanks to the damage it sustained after its onboard systems smashed it into the runway at a 35˚ nose-down angle.

A similar Watchkeeper, tail number WK031, crashed in very similar circumstances in 2014 after its crew engaged the override in an attempt to guarantee that the drone would land before a storm overtook it.

Whee, flop, oh bugger

After a successful takeoff WK006 was uneventfully flown over Salisbury Plain Training Area before its crew tried to land it back at Boscombe Down. The drone’s ground crew, who prepared the site for landing, noticed that the Automatic Take-off and Landing System (ATOLS) was unserviceable.

ATOLS consists of three components, two of which are ground-located beacon and radar units. With those out of use, the drone would instead use its onboard GPS/INS-based landing system.

On its first approach the crew selected the “altitude deviation” override, in accordance with the drone’s flight reference cards, because cloud cover had closed in to 100ft above ground level. While flying in low cloud the aircraft’s systems would falsely give ground proximity reports unless this override was engaged. Despite this, the drone automatically aborted its first landing attempt.

The second landing attempt resulted in another automatic landing abort. At this point the crew agreed, after discussion with the flight’s authorising officer, to engage the master override. This would prevent the drone from automatically aborting another landing.

On the third attempt the drone made its approach to the runway, descended to a height of 22 feet above it, and then nosed over until it struck the ground at a 35.29 degree nose down angle.

WK006 was being operated by a crew of three – a captain, a pilot and a payload operator – from 43 Battery, 47 Regiment Royal Artillery (RA). They were on an accelerated programme to train them as instructors for other crew learning to operate the drones. The captain was an experienced drone officer with several hundred hours’ experience on type who was one of the first to use Watchkeeper on its initial operational deployment to Afghanistan.

If you program it to do something silly, it’ll do it

The military-convened accident investigation panel from the Defence Safety Authority reviewed the Watchkeeper’s logs, including what decisions the drone’s onboard logic was making.

As WK006 made its final approach to the runway it opened its “ground touch” window, sensed that it had touched down and then recorded that it had bounced back into the air. Under normal circumstances, if this happened the drone would default from its “approach” state to “air jump” and, after a few seconds without any further ground contact, close the “ground touch” window, abort the landing, go around and try again.

As “master override” was engaged on the final landing attempt, however, the drone remained in its “approach” state. Its vertical acceleration reduced enough for the onboard logic to decide that it was now straight and level and therefore on the ground – despite being 325 feet above it – and commanded a nose down manoeuvre to put weight onto the steerable nosewheel.

The panel concluded, in its analysis, that WK006 incorrectly sensed its altitude because the two onboard laser altimeters both recorded altitudes of less than 1m above ground level thanks to reflections from the low cloud it was flying through.

It further stated, while pondering how the onboard logic could have decided it had touched down at 325ft AGL:

... it can be seen that Air Jump should end when dACCz [a function of acceleration] has a value of greater than 1 ms-2 for more than 0.1 seconds. Analysis of the VMSC [Vehicle Management System Computer] data showed that on the final approach Air Jump ended when these parameters were met, with a corresponding change in the WOW1 [Weight on Wheels] state to On-ground. Figure 5 shows that vertical acceleration (labelled as ACC Z) was greater than -9ms-2 at the first Ground Touch and that the ATOL State changed to Air Jump, only returning to Approach when dACCz reached a value of 1 ms-2 , at which point WOW1 latched to On-ground.

The Watchkeeper had initially pitched down, causing Ground Touch to be declared, because it was above the three degree approach glidescope for Boscombe’s runway.

In its determination of factors that caused the crash, the panel said:

The VMSC software had, therefore, declared the UA was on the ground and ultimately commanded post-landing actions whilst the UA was still airborne. The Panel concluded that flawed VMSC software logic was a Causal Factor.

The panel later noted that the VMSC “did not compare the laser altimeter readings when it first started using them at the CP with either barometric or GPS height information,” which contributed to the crash.

Weight on wheels? Yeah, software will sort that

No physical weight-on-wheels switch used for landing is fitted to Watchkeeper, which Thales explained to the panel was because of the military requirement that the drone be able to operate from unprepared landing strips: the company said landings on rough surfaces would be likely to break the switch, a problem it had noticed on its other drones. Instead a software algorithm determines, from altitude and acceleration data, whether the Watchkeeper has touched down or not. A switch is fitted to the nosewheel but only to prevent the high-powered laser and radar observation equipment from transmitting while on the ground.

Air Marshal Dick Garwood, head of the Defence Safety Authority, noted at the end of the report: “The Service Inquiry (SI) Panel believes the operation of WK with the flawed VMSC logic still carries an undefined safety risk, unless it can be shown that there are no other conditions that could lead to a false Ground Touch being sensed.”

The air marshal added that the user document set provided by Thales UK “states that WK [Watchkeeper] is an all-weather aircraft which is not true and has likely led to operators having expectations beyond its true capabilities... Although unrelated to the issues described surrounding the landing logic, Thales UK had limitations in place at West Wales Airport regarding cloud at the CP [landing commencement point] since 2013, although, surprisingly, this had not been communicated to the MOD Type Airworthiness Authority or the Army operators at Bascombe Down. This was a missed opportunity.”

“Clearly the VMSC software needs to be fixed before WK is able to provide a reliable and credible capability in a range of weather conditions. I have no doubt that this can be done and the technical issues will be fixed,” concluded Air Marshal Garwood. ®


Biting the hand that feeds IT © 1998–2017