When highly automated helicopters are hand-flown into the ground by pressing the wrong buttons, it is time to review some fundamental aspects of aircraft handling through automation. As per ICAO Doc 10011, such Loss of Control in Flight (LOC-I) accidents are usually catastrophic and characterised by very few, if any, survivors.
Before we proceed, a silent tribute to the crew who perished in the accidents described below. No accident is ever the result of a single event. We obviously have the benefit of hindsight that came too late for these crew. I write with the hope that someone somewhere learns a lesson and lives to fly another day.
Case 1: ‘Dhruv’ Advanced Light Helicopter (ALH)
On 19th Oct 2011, a ‘Dhruv’ ALH, VT-BSH operated by Pawan Hans Helicopters Limited (PHHL, now PHL), took off from Ranchi in poor visibility during daylight hours. During the climbout, activation of ‘TGB Hot’ caption forced a return to Ranchi. The Dhruv has a sophisticated Automatic Flight Control System (AFCS) and autopilot with flight director ‘upper modes’. Yet the pilot flying (PF) decided to takeover manual control as they continued visual flight into Instrument Meteorological Conditions (IMC). The short flight of about 6 minutes saw extreme bank & pitch attitudes, speed excursions breaching VNE, high & low rotor RPM & overtorque – all consistent with LOC-I. All three onboard received fatal injuries and helicopter was destroyed in the crash and post-impact fire. Among other probable causes and contributory factors, the accident report carries a grim pointer to the crew’s resort to manual control of the helicopter under IMC.
Case 2: Leonardo AW139
On 13th Mar 2014, a privately-owned AW139 helicopter G-LBAL took off from a ground level helipad with poor cultural lighting and 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 ‘all weather’. A 40-min delay imposed by his late arrival pushed the flight into deteriorating weather. No special procedures, briefings, Ops Manual or standard calls were in use. The Captain briefed for a vertical liftoff from the field without any clarity on the subsequent procedure to be followed, including the most vital aspect for that takeoff – use of automation.
“Right all i’m going to do, take it over to the centre 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”
—CVR transcript from the UK AAIB report
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º below horizon while descending through 100 feet agl. ‘The trim release switches were held-in throughout the flight’. Again, tell-tale marks of an LOC-I event – extreme attitude, speed, descent rates & 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 400m away. All four occupants perished in the crash.
Page 45 of the AAIB report notes that ‘No flight director modes were selected during the flight‘. 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: Dauphin N (G-BLUN): On 27th Dec 2006, an AS365N Dauphin G-BLUN of CHC Scotia Ltd crashed into the Irish Sea while attempting to land at night on the North Morecambe Gas Platform. As per the accident report, “the approach profile flown by the co-pilot suggests a problem in assessing the correct approach descent angle because of the limited visual cues available to him”. The approach was not stabilised as he was disoriented. The helicopter crashed into the sea with seven fatalities (2+5). 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: Dauphin N3 VT-PWF
As opposed to the examples above, PHL Dauphin N3 VT-PWF went into the night sea rather gracefully on 4th Nov 2015 during a training flight. Here is a paragraph from the accident report:
‘The helicopter took off from WIS helipad at 1910 hrs. The helicopter was planned to land first at Ron Tappmeyer Rig attached to EE platform in South Field and then to floating platform Sewak. 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. Simultaneously it descended and few seconds later the helicopter crashed into the sea and was destroyed. Both the flight crew members received fatal injuries.’
Instead, use of the ‘Go Around’ mode of AFCS may have seen the Captain retire safely after over 35 yrs in cockpit (he was into his last month of service) and the trainee achieve successful night offshore captaincy.
Loss of Situational, Spatial or System Awareness?
Investigation report into all three accidents brings out the common trap 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 type. The instructor pilot of Dauphin VT-PWF 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 cheese to align and, alas, we have an accident.
Low Awareness of Automation Kills as Much as Over-reliance on Automation
Much has been written about automation and its ills in recent years. ‘Children of Magenta‘ is almost a household name in aviation circles. While we continue to lament the atrophy of flying skills that automation has brought about, I am putting forth a hypothesis that informed and appropriate use of automation may have saved these 16 lives from four accidents.
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.
Automation is There For A Reason
All of us at some stage must 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, Stability Augmentation Systems (SAS) for short-term rate damping, artificial-feel mechanisms, Force Trim (FT) etc. were added. Then came ‘Attitude’ mode for long-term attitude retention and Flight Director with ‘upper modes’ such as airspeed, vertical speed & altitude hold, lateral and vertical navigation, etc. Slowly the ‘hand of automation’ offloaded our gloved hands. All that stood between you and the aircraft were a few buttons on the cyclic, collective and AFCS panel.
They are there for a reason. Under normal circumstances, long-term, repetitive tasks that require high accuracy are best left to autopilots (aka ‘George’). That leaves spare capacity to ‘monitor’, manage systems, lookout for birds, obstacles, etc. and also alleviates crew fatigue. Flying over featureless terrain at night or in poor visibility is best left to ‘George’ since he doesn’t get disoriented. For airliners, extended cruise in RVSM airspace is not allowed without automatic altitude maintaining systems (besides other equipment).
SAS, ATT & ‘Fly-Through’ Modes
In simple terms, SAS mode is meant for ‘hands-on’ flying (Force Trim may be ON or OFF), ATT mode is meant for long-term attitude retention or ‘hands-off’ flying (FT has to be ON). Designers also give you ‘fly-through’ or ‘against spring load’ modes where you could make small changes without disturbing the reference attitudes or rates.
Cruising at 140 knots on flight director, when you suddenly see that flock of birds right ahead, you could move the cyclic ‘against spring load’ in the desired direction without pressing any buttons, evade the birds and then restore the cyclic back to original place. If in ATT mode & situation permits, you could ‘beep’ the cyclic or use the heading mode to circumvent the birds. If aggressive manoeuvring is required, you may have to use the FT Release (FTR) switch on the cyclic grip. Each choice comes with different connotations.
Use of AFCS in Different Modes
Pressing FTR allows the pilot to make coarse (or large) changes in attitude while the system stands-by in a modified SAS 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’.
Helicopters that have ‘Attitude’ mode provide a ‘beep trim’ (also called ‘Chinese hat’) function that allows small/fine changes in reference setting. If you want to make frequent changes to attitude or fly ‘hands-on’ (e.g, hover or traffic patterns), SAS is the recommended choice in most Rotorcraft Flight Manuals (RFM). If in IMC conditions or flying IFR, ATT mode is mandatory.
Shooting ILS or RNP approaches ‘hands-on’ or with ‘FT off’ under IFR is best left to the simulators, if not already prohibited in RFM. Because when you turn off the FT, you lose ‘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 barnstorming days. YOU are now the ‘autotrim’.
Design usually caters for quick & easy decoupling of flight director modes or the AFCS itself. This is to ensure manual takeover of aircraft should any system degrade, misbehave or ‘feed’ energy into unwanted oscillations. Intelligent design should preclude inadvertent operation of the ‘Emerg AFCS OFF’ or ‘SAS Release’ switch since some helicopters can quickly go into divergent oscillations without AFCS unless handled with care.
On the AW139, for instance, the ‘SAS REL’ 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 ‘Emerg AFCS OFF’.
Under duress, natural human tendency is to tighten the grip on controls. Whether VT-BSH Dhruv crew operated the ‘Stab OFF’ trigger during the tense moments of that flight we will never know since there were gaps in the FDR data. I would hazard that they did, having foreseen this possibility during my early days as a test pilot on ALH.
Getting Hands-On Experience At What Cost?
The Force Trim switch of Bell 412 is hidden under a red guard in the ON position. For the SAS mode, FT can be ON or OFF. During type-rating and initial days on the 412, flying with FT off is passed on to transitioning crew like a rite of passage. Noble intent, but the consequences for a 5.4-ton helicopter must be understood; and then again, only under VMC.
There is also an old school that believes the first 1000 hours on Bell 412 should be flown with Force Trim OFF. I reserve my comments. There are too many body bags stacked against this narrative. Perhaps, teaching intelligent use of AFCS modes is a better investment, especially for crew who have been hand-flying all their lives.
ATT mode with coupled upper modes provides engine operating safeguards and height protection that cannot be discounted (in both VT-BSH and G-LBAL, both engines were taken well beyond AEO torque limits leading to loss of rotor RPM). Similarly, negative transfer of training through the tendency to assume ‘hands-on in emergency situations under low visibility must be guarded against. Trainers must analyse the pros & cons of these approaches in the 21st Century when even light-singles are tending towards greater automation.
The AAIB report on VT-BSH brings out that salient aspects of handling automation on Dhruv was taught to the deceased pilots during conversion training. Both pilots were from ‘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 were never introduced to it in the first place. Since the VT-BSH 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 called ‘Evidence-based Training‘. The BSF Dhruv accident is an abject antithesis of EBT, if ever there was one.
Upset Prevention & Recovery Training (UPRT)
With automation levels increasing by the day, UPRT must also be tailored to handling 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 takeover manual control may not be the best option for all seasons. Type-rating and recurrent training must recognise such tendencies and correct it before that rainy day.
Company SOPs 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 focussing on handling emergencies or abnormal procedures.
But Takeover When You Got To!
Lastly, a word of caution to not shy away from taking over manual control when the situation so demands (apart from RFM procedures that specify ‘Fly Manually’).
On 14th March 2017, Rescue 116, a S-92 helicopter 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 preliminary report issued by the Irish AAIB, a low-altitude autopilot mode that reduces warning boundaries and look-ahead distances was in use at the time of accident. This ‘VFR-only’ mode was used by night in patchy mist and fog, cloud base of 300-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-FMS coupled mode. Intervention time was critical.
Initiating immediate recovery action by stepping down to a lower mode of automation or manually taking over controls would probably have saved the day. Instead, a heading change was initiated using the ‘Heading’ mode even as a rear crew member interjected with increasing urgency “Come right now, come right, COME RIGHT”. The helicopter with a host of new generation devices like EGPWS, FMS, Multi Missions Management Systems, Automatic Flight Control System (AFCS), Electro Optic / Infrared Camera System, dual radio altimeters, weather radar, etc. impacted the rocky outcrop and crashed into sea with loss of all 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 left for you to glean from the examples above, RFMs, Flight Crew Operating Manuals, and then discuss with your instructors during type-rating / recurrent training.
Grabbing controls and pressing all the wrong buttons is not an option of choice.
Happy landings, folks.
(A lightly edited version of this story was originally featured in Vertical Magazine’s Oct/Nov 2019 print & digital edition. You can access the magazine here, scroll to Pg 96 for this story).
©KP Sanjeev Kumar, 2019. All rights reserved. I can be reached at firstname.lastname@example.org or on my Twitter handle @realkaypius.Views are personal.
Disclaimer: If you are a flight crew, please consult national regulations, the Rotorcraft Flight Manual or Aircraft Flight Manual and your company’s Operations Manual as applicable to the type you fly.
7 thoughts on “Automation on Helicopters: Lessons From Fatal Accidents”
Very well articulated KPS. Yes technology and automation are the need of the hour, however, the right balance of human intervention is equally important.
Automation, like fire, is a great slave but a bad master.
Making the right choice is experience, training and luck.
Such robust culture of investigations in aviation has helped processes, manufacturing, and automation to improve and keep fatalities very very low. The medical field needs to learn to learn similarly.
Excellent reading these thoughts from a versatile pilot, another push in the right direction.
More automation is inevitable.
Very nicely broken got out. In complete agreement with the author.
So many accidents have taken place when flying manually in IFR environment. Very nicely articulated article. Well written.
I enjoyed your article, it was excellent.
Although automation is certainly an issue, have you also considered (in a few of your examples) that aircraft are being operated in what is intended to be a visual phase of flight (i.e. takeoff and landing), without adequate visual reference and in many cases below the minimum speeds that the aircraft demonstrated the stability required to fly utilizing the flight instruments during certification (Vmini), with or without automation.
I have completed hundreds, if not thousands of night onshore and offshore takeoffs and landings from unimproved areas, both utilizing night vision goggles, and without, and I still find it incredible that in this day and age that night vision isn’t even mentioned by most companies and regulators as a barrier against some of these accidents. Or for that matter that night takeoffs and landings from non-airport environments without night vision is even still a thing in this day and age.
I recently put together a safety analysis regarding worldwide offshore CFIT accidents over the period 2007-2018 for my current employer (who fortunately for me utilize night vision for all night operations). The data was quite shocking, even though only a tiny percentage of the overall offshore flights are conducted at night, night flights accounted for 83% of the total CFIT accidents, and 90% of the fatalities. The old “we’ve been doing this for years safely, and we can train for it” mantra is actually complete nonsense if you look at the data. I know that night vision would have prevented a lot of these accidents, and even a few in your article, but for some strange reason it never seems to get mentioned, even in the accident reports.
Anyway, just food for thought.
Thank you for your valuable feedback. Here in India, NVGs are solely a ‘luxury’ enjoyed by few in the military. The civil aviation operations are wholly unaided – both in terms of NVGs and also unaided by the wisdom espoused in your comment. Hope that’ll change with you and me hammering home these points, however unpalatable and stained in blood they may be.
With regards, KPS
Great article Kaypius,
One thing I have long felt has been oddly missing in aviation is a focus on making systems intuitive to the pilot. This has improved slightly in recent years but I still feel that the industry is lagging woefully behind on placing importance on this despite the staggering amount of easily preventable accidents that have been caused at least in part by problems with the human-machine interface. This is further exacerbated by non-standardization.
How many aviation accidents (including major airline accidents) have occurred because pilots did not realize that the autopilot had been switched off?? A personal friend of mine and highly competent pilot died due to this. And yet including, for instance, a simple sound or voice alert that the system has been disactivated is still incredibly rare.
I am dumbfounded by some of the design failures in aviation.. just an example, but one would be how some AS350’s have a digital RPM gauge that indicates increasing RPM by moving downwards and decreasing RPM by moving upwards. Sure the numbers and colors (green, yellow, red) still correctly indicate which way your RPM is moving but one can imagine that that a pilot suddenly finding themself with a failed engine and in a critical emergency situation, startled with fear and nervousness rushing to their brain.. who’s ability to process information has suddenly substantially deteriorated (and who is likely accustomed to the vast majority of RPM indicators who’s indication moves downwards as RPM reduces and upwards as it increases) might read that gauge incorrectly. Sure we’re supposed to be knowledgeable professionals who know the ins and outs of their machine but why would you EVER place even the smallest unnecessary obstacle in the way of a pilot who has mere seconds (if that) to correctly react to a life or death situation?! Again just one example of many many design failures in aviation that fail to incorporate basic human psychology.