Estimated reading time 13 minutes, 5 seconds.
The high profile crashes of the Lion Air and Ethiopian Airlines Boeing 737 Max airliners have brought the issue of automation in aviation to the public attention like never before. How much automation we are comfortable with, and to what degree we should be reliant on it, are, of course, topics we have been discussing within aviation circles for as long as we have had the technology. And with the ever-increasing capability of rotary-wing automatic flight control systems (AFCS), these questions remain hugely relevant to our industry and future.
When highly automated helicopters are hand-flown into the ground through the wrong buttons being pressed, perhaps it is time to review some fundamental aspects of aircraft handling through automation. To do so, we’re going to take a look at some rotary-wing accidents and what can be learnt from them in terms of automation.
Before we proceed, it’s worth noting that no accident is ever the result of a single event, and we obviously have the benefit of hindsight that came too late for these crews. I write with the hope that someone somewhere learns a lesson that helps them live to fly another day.
Case 1: HAL ‘Dhruv’ Advanced Light Helicopter (VT-BSH)
On Oct. 19, 2011, a Dhruv Advanced Light Helicopter operated by Pawan Hans Helicopters Limited (PHL) took off from Ranchi airfield in poor visibility during daylight hours. During the climbout, the “TGB Hot” warning was activated, forcing a return to Ranchi.
The Dhruv has a sophisticated AFCS and autopilot with flight director “upper modes.” Yet the pilot flying decided to take over manual control as the aircraft continued visual flight into instrument meteorological conditions (IMC). The short flight of about six minutes saw extreme bank and pitch attitudes, speed excursions breaching never exceed speed (VNE), high and low rotor rpm and overtorque — all consistent with a loss of control in-flight (LOC-I) — culminating in a crash into hilly terrain. All three onboard were killed, and the helicopter was destroyed in the crash and post-impact fire.
Among other probable causes and contributory factors, the accident report includes a grim pointer to the crew’s resort to manual control of the helicopter under IMC.
Case 2: Leonardo AW139 (G-LBAL)
On March 13, 2014, a privately-owned AW139 took off from a ground-level helipad with little ambient lighting in dense fog conditions. The crew were under pressure to fly the owner, who had clearly invested in a modern machine and instrument-rated pilots so he could fly in “all weather.” A 40-minute delay imposed by his late arrival pushed the flight into deteriorating weather. No special procedures, briefings, operations manuals or standard calls were in use. The captain briefed for a vertical lift-off from the field without much clarity on the subsequent procedure to be followed, including the most vital aspect for that takeoff — the use of automation.
According to the CVR transcript in the report from the Air Accidents Investigation Branch (AAIB), the pilot in command (commander) said: “Right, all I’m going to do [is] take it over to the center of the field, and then just pull the power. We’ll go vertically up, I’ll go for the strobe — and just make sure the heading bug is central for us, if you can.”
The report states that “the cyclic and collective controls were manipulated by the commander throughout the accident flight; the automatic flight modes, which could have maintained pitch and roll, were not active.”
During takeoff, the helicopter continued to nose down after the initial vertical climb, reaching 35 degrees below horizon while descending through 100 feet above ground level. The trim release switches were also found to have been held in throughout the flight. Again, tell-tale marks of an LOC-I event — extreme attitude, speed, descent rates and overtorque — were evident in the short flight. The parabolic flight path of the helicopter lasted less than a minute when it impacted the ground about 400 meters away. All four on board perished in the crash.
“No flight director modes were selected during the flight,” the crash investigators noted in the report. Also in use was a “procedure not laid down in the flight manual or recognised as being compliant with the need to achieve Vmini [instrument flight minimum speed] before transition to instrument flight.” Once again, limited use of the AFCS was noted as a contributory factor.
Case 3: Airbus AS365 N Dauphin (G-BLUN)
On Dec. 27, 2006, an AS365 N Dauphin of CHC Scotia Ltd crashed into the Irish Sea while attempting to land at night on the North Morecambe gas platform in poor weather conditions. As per the accident report, “the approach profile flown by the co-pilot suggests a problem in assessing the correct approach descent angle, probably . . . because of the limited visual cues available to him.”
The approach was not stabilized as the co-pilot was disoriented. The helicopter crashed into the sea with seven fatalities (two pilots and five passengers). Large oscillations in pitch, roll and yaw consistent with use of force trim release (FTR) rather than the beeper trim or “Chinese hat” were evident in last few seconds of the flight. Use of FTR under IMC is a potentially risky choice unless closely monitored through instrument indications.
Case 4: Airbus AS365 N3 Dauphin (VT-PWF)
On Nov. 4, 2015, a PHL N3 Dauphin went into the sea during a night training flight. The aircraft took off from a helipad at an offshore platform and planned to land at the nearby Ron Tappmeyer Rig.
“The helicopter made an approach to land on Ron Tappmeyer, but as the helicopter was high on approach, it made a go around and banked to the left,” the accident report stated. “Simultaneously it descended and few seconds later the helicopter crashed into the sea and was destroyed.”
The two flight crew members on board were both killed in the accident.
Loss of Situational, Spatial or System Awareness?
The investigation reports into these accidents brings out the common deathtrap of spatial disorientation that accompanies planned or inadvertent entry into IMC. While the Dhruv crew were marked out for low awareness and unfamiliarity with a new type, the crew of G-LBAL were experienced on the type. The instructor pilot of Dauphin VT-PWF, who was the non-flying pilot during the ill-fated flight, was one of the most experienced pilots flying in India at that time.
Evidently, experience cuts both ways. Wrong habits can sometimes get fortified with experience. It just takes the holes in the metaphorical cheese to align and, alas, we have an accident.
Much has been written about automation and its ills in recent years. While we continue to lament the atrophy of flying skills that automation has brought about, I contend that intelligent and appropriate use of automation may, in fact, have saved the 16 lives lost in these four accidents. And there are countless other examples that abound in literature. For every accident attributed to excessive reliance on automation, you may well find a contrasting example where automation appropriate to that phase of flight was not used even though it was at hand.
To me, that’s a bigger irony than having no automation at all; much like carrying a treasure chest of smart boxes that were rendered deadweight. To understand this predicament, we need to go back to basic flight school.
All pilots must, at some stage, have hand-flown basic aircraft or helicopters without exotic AFCS. Your hands continuously held the stick and controlled the flight path, with or without servos to offload the control forces. In due course, technology such as stability augmentation systems (SAS) for rate damping, spring-feel mechanisms, and force trim were added. Then came “attitude” mode for long-term attitude retention, and upper modes such as airspeed, vertical speed and altitude hold, lateral and vertical navigation, and so on. Slowly, the hand of automation took an increasing amount of work off your gloved hands. All that stood between you and the aircraft were a few buttons on the cyclic, collective and AFCS panel.
This technology is there for a reason. Under normal circumstances, mundane, repetitive tasks that require high accuracy are best left to autopilots (also known as “George”). That leaves spare capacity to do things such as monitor and manage systems, and look out for birds or obstacles. It also alleviates crew fatigue to a large extent. Flying over featureless terrain at night or in poor visibility is best left to George, since he doesn’t get disoriented.
But even with all the automation, designers still give you “fly-through” modes where you can make short-term changes without disturbing the reference attitudes or rates. If you are cruising at 140 knots and suddenly see a flock of birds half a mile away, you can move the cyclic in the desired direction to avoid them without pressing any buttons, and then restore the cyclic back to its original place. The aircraft continues to chug along on automation. Such a beautiful system, isn’t it?
Well, all that changes when you press the force trim release (FTR) button. Pressing FTR allows the pilot to make large changes in attitude while the system stands by in SAS/ATT mode — a potentially disorientating move in marginal visibility or night conditions. A momentary distraction can set up unusual attitudes or leave you predisposed to “overcontrol.” Turn off the force trim and you lose the attitude mode. Turn off the AFCS or “stab” and all bets are off. It’s just you and the unstable machine — back to the good old days.
Aircraft design and teaching
The design of autopilots usually caters for quick and easy decoupling of flight director modes or the AFCS itself. This is to ensure manual takeover of aircraft should the system misbehave or “feed” energy into unwanted oscillations. Intelligent design should preclude inadvertent operation of the “Stab OFF” or “SAS Release” switch, since some helicopters can quickly go into divergent oscillations without the AFCS. On the AW139, for instance, this switch is placed inside a circular recess on the cyclic and operated by the ring finger.
On the Dhruv, a small trigger-detent sitting under the little finger operates the “Stab OFF.” Under duress, our natural tendency is to tighten our grip on controls. We will never know whether the Dhruv crew operated the “Stab OFF” trigger during the tense moments of that flight thanks to gaps in the flight data recording.
The force trim switch on the Bell 412 is hidden under a red guard. Yet, experienced pilots don’t think twice before putting it off and moving the controls. While the intent may be noble, it’s still potentially risky to do this in a 5.4-ton helicopter unless closely monitored; and then again, only under visual meteorological conditions. There is also an old school of thinking that holds that the first 1,000 hours on the Bell 412 should be flown with force trim off. I reserve comment, but there are too many body bags stacked against this narrative. It is best left to the doyens of training to analyze the pros and cons of this approach in the 21st century.
The report on VT-BSH brings out that the salient aspects of handling automation on the Dhruv were taught to the deceased pilots during their type rating. Both pilots were from a single-engine background — an epithet used to bracket pilots with hardly any exposure to automation. These are pilots who traditionally baulk at automation; mostly because they weren’t introduced to it early in their careers. Since the pilots are no longer around to defend themselves, we must take the accident investigation board remarks with a pinch of salt. There is such a thing as evidence-based training (EBT). The Dhruv accident is an abject antithesis of EBT, if ever there was one.
With automation levels increasing by the day, upset prevention and recovery training must also be tailored to handle emergencies with the appropriate level of automation. I see a big void here, especially in the Indian context. The tendency to grab controls, push the FTR and take over manual control may not be the best option for all seasons. Type rating and recurrent training must recognize such tendencies and correct it before that rainy day.
Company standard operating procedures and operation manuals may specify what level of automation to use for each phase of flight. But these can only be generic guidelines. Task saturation can be avoided by delegating mundane tasks to automation, while focusing on handling emergencies or abnormal procedures.
Take over when you’ve got to!
Lastly, a word of caution: you should not shy away from taking over manual control when the situation so demands (apart from rotorcraft flight manual procedures that specify “Fly Manually”).
On March 14, 2017, Rescue 116, a Sikorsky S-92 operating for the Irish Coast Guard, flew into an outcrop called Black Rock Island that was uncharted on the aircraft’s enhanced ground proximity warning system (EGPWS). As per the preliminary report issued by the Irish Air Accident Investigation Unit, a low altitude autopilot mode that reduces warning boundaries and look-ahead distances was in use at the time of accident. This visual flight rules-only mode was used by night in patchy mist and fog, with a cloud base of 300 to 400 feet, occasional light rain/drizzle and gale force winds. The crew reportedly received an “Altitude, Altitude” aural alert 26 seconds before the crash while flying at 200 feet/75 knots on an autopilot-flight management system (FMS) coupled mode.
If the crew had initiated immediate recovery action by stepping down to a lower mode of automation, or manually taking over controls, it probably would have saved the day. Instead, a heading change was initiated using the “Heading” mode even as a rear crewmember interjected with increasing urgency: “Come right now, come right, COME RIGHT.”
The helicopter, equipped with a host of new generation devices like EGPWS, FMS, multimission management systems, AFCS, electrooptic/infrared camera system, dual radio altimeters, and weather radar hit the ground and crashed into the sea with loss of four lives.
Automation, like fire, is a great slave, but a bad master. There is no magic pill for all situations. The abiding mantra remains “aviate, navigate, communicate.” If you are flying with George, understand his modes and moods. What level of automation is appropriate for a particular situation is best left for you to glean from the examples above, rotorcraft flight manuals and discussion with your peers and instructors. Grabbing the controls and pressing all the wrong buttons is not an option.
A great article.
Some discussion on recognizing when George is malfunctioning might be an add on. Often we revert to hand flying because we haven’t practiced with automation recently; and, we’re uncomfortable with the unfamiliar.
Straying from expected aircraft attitudes, associated with configurations of flight, may be the first symptom that George is misbehaving.
I’m a sim instructor; I’ve seen even the most seasoned pilot decide to hand fly after misinterpreting what George was doing well. Knowing the aircraft attitude appropriate for the configuration of flight would have been beneficial.
Leave a comment