HUMS: Safety Alert

HUMS: Safety Alert

3-Feb-2017 Source: Allan Blake for

The recent “near miss” that occurred on a rig landing by S92A G-WNSR on December 28th 2016 is the latest in a series of major incidents that appear to have been caused by the accelerated deterioration of critical components, this time in the tail rotor bearing assembly (Air Accident Investigations Branch “AAIB” Special Bulletin S1/2017, 11th January 2017).

The rate of deterioration is such that the normal detection and preventive safety barrier created by helicopter Health and Usage Monitoring Systems (“HUMS”) systems do not create a sufficiently timely alert for operators to ground and inspect the aircraft. The other incidents include:

Helicopter safety entered into a new dimension with the development of HUMS. Put simply, HUMS comprises electronic systems that monitor vibrations and metal chips in vital components such as engines, transmissions, gearboxes and rotor systems.  The objective is to discover, through electronic downloads of data collected around these components, potential faults or the ‘health’ of the component before they get to the stage when they could fail and cause an incident. A Helicopter Airworthiness Review Panel convened in 1984 by the CAA recommended the development of such an early warning system and Bristow’s design office led by Alistair Gordon and supported by Allan Brown and Mike Cogan started to develop the first systems which came into general operation in the early 1990s. HUMS systems are now in place in most types of helicopters to varying degrees and in June 1999, the system was mandated on UK registered helicopters with a Certificate of Airworthiness in the Transport Category (Passenger) and maximum approved passenger seating configuration of more than nine, extended to all offshore helicopters from January 2019. Bristow and Shell even contracted for the first system to be installed into the Mi-8, the aircraft that Shell were operating on Sakhalin Island through the Sakhalin Energy consortium with Gazprom. I remember well a visit to the Russian engineers of the Mi-8 in Moscow, who were delighted to take on the challenge to introduce HUMS to their helicopter and were very knowledgeable about the development of HUMS and the safety benefits that would be derived. As an Accountable Manager, the presence of HUMS systems in the helicopters that I was responsible for was an essential tool for delivering a safe flying environment, and it remains so today.

The purpose of the various HUMS systems is to monitor the “health” of the components through measuring small changes over time, a cycle that could be 100 hours ahead of any failure of the component.  Before any such failure the HUMS alert should have led to engineering action to monitor and remedy the fault in advance of any failure of the component.   This sequence of preventative engineering action prompted and guided by HUMS output is taking place thousands of times every day around the world.  An admittedly small Federal Aviation Authority (“FAA”) funded research project estimated that HUMS systems had reduced incidents by 47%. It is understandable that when this prior alert system appears not to have raised a timely alert of component failure, amid the often catastrophic consequences, questions should be asked about the scope, development and application of HUMS to cope with fast rates of component deterioration.

There are some excellent summaries of HUMS.   The Rotorcraft Maintenance Plan Industry Group produced an excellent and comprehensive review of HUMS in various helicopter types in October 2016: “Towards HUMS for Credit”. HeliOffshore produced “Best Practice” guidance for operators in “The Health & Usage Monitoring Systems Best Practice Guidance Version 1.0” (published in 2014 on the HeliOffshore website at www.  HeliOffshore encouraged its members to adopt the best practice recommendations across the offshore helicopter sector in a common approach.

2016: S92A G-WNSR

The AAIB investigation into S92A G-WNSR is ongoing, but the Special Bulletin provides the necessary detail:

“The flight was the second sector of a four-sector rotation from Aberdeen to the Elgin-Franklin Offshore Field in the North Sea…As the helicopter… lifted from the Elgin PUQ helideck it yawed unexpectedly to the right through 45°. The commander applied full left yaw pedal, checked the rotation and landed back onto the deck. The flight crew discussed the likely cause, which they thought to have been the result of local turbulence or wind effects created by the platform structures… They decided to continue…all control responses appeared normal… The helicopter made a normal approach and deceleration to the West Franklin and crossed over the helideck. During the descent to land, at approximately 4 ft above the helideck, it yawed rapidly to the right, reaching a maximum rate of 30 degrees per second. At the same time it rolled 20° to the left, at which point the left main landing gear contacted the helideck. It continued to yaw to the right on its left mainwheels and nosewheels before the right mainwheels contacted the surface. The helicopter came to rest… having rotated through 187°.”

The initial technical investigation identified that the tail rotor servo piston was damaged and that the tail rotor pitch change shaft double row angular contact bearing was in a severely distressed condition, leading to a total loss of control of the tail rotor. This was a very “near miss”. The investigation found that:

“… the failure of this specific bearing was rapid; a period of 4.5 flight hours had elapsed from the first exceedance of the relevant bearing condition indicator recorded on the operator’s Health and Usage Monitoring System to the point of failure.”

The initial investigation also found that:

“A routine download of the HUMS was performed on the evening of 27 December 2016 and the helicopter was released to service. A detailed analysis of the data, conducted after the accident, showed that the Tail Gearbox Bearing Energy Analysis limit had been exceeded on 27 December 2016.”

The specific bearing was not monitored by the original S92A HUMS and a different stand alone tool to do so was added in 2007. I understand that an automatic alert HUMS software tool is being ‘tested’ but was not installed in this case, so visual analysis of the data was required to identify exceedances.  Engineering sources inform me that the specific data in question is not very easy to identify. The manufacturer has now recommended that operators use the software tool “as often as reasonably possible” and subsequent fleet checks including inspections have led to other S92A helicopters reporting anomalies.

This incident raises the following issues which can also be observed in the other accidents to be reviewed:

  • Timely availability of reliable data for key decision making; and
  • The level of expertise required and available to access and interpret the data accurately.

In particular how quickly can the HUMS data impact:

  • the engineer’s return to service of the helicopter; or
  • a pilot fly/ no fly/ land decision whilst airborne, on a rig or away from a main base.

In this case 4.5 flight hours had elapsed since HUMS recorded the exceedance. It could easily have been the case that the daily flight time prior to return to a base with a Ground Control Station capable of analysing the data would have exceeded this.  Placing limits on the maximum flight time prior to the download of HUMS data and analysis is a precaution but is not practical where there are long sectors. Also, other incidents have a period of HUMS identification of component deterioration of less than than 4.5 hours prior to failure.

The analysis of HUMS data is a significant task growing in its complexity and demanding considerable levels of engineering expertise and experience, including referrals from the operator to the manufacturer’s experts.  The number of individuals with this level of expertise and experience across different types is limited in any single operator requiring considerable planning and thought as to how such data analysis can be undertaken so as to guide the fly/ no fly decision.

2009: G-REDL, AS332L2


This accident on the 1st April 2009 led to 16 fatalities and occurred whilst the helicopter was operating a flight from the Miller Platform in the North Sea to Aberdeen. Some 50 minutes into the flight, there was a catastrophic failure of the MGB. The main rotor and part of the epicyclic module of the MGB separated from the fuselage and the helicopter struck the sea at high speed.

The accident investigation found that:

“The failure of the Main Gear Box started in one of the eight second stage planet gears in the epicyclic module as a result of a fatigue crack.”

A metallic particle had been discovered on the epicyclic chip detector during maintenance on 25 March 2009, 36 flying hours prior to the accident. This was the only indication of the impending failure of the second stage planet gear and the investigation found that

“…the existing detection methods did not provide any further indication of the degradation of the second stage planet gear”.

The engines and the MGB sump chip detectors were the only alerts connected to warning indicators that displayed in the cockpit of the AS332L.  The investigation did comment that the epicyclic module magnetic chip detector fitted to the H225 does provide a cockpit warning as well as being recorded on HUMS.  G-REDL was fitted with seven magnetic chip detectors, six of which were electrically connected to the HUMS. These included one on each engine and one on the MGB sump, epicyclic module, intermediate gearbox and tail-rotor gearbox.

The investigation report commented on the time gap between HUMS exceedances being recorded on the HUMS systems in flight and the availability of that information to those who could interpret the data and act upon it:

“The HUMS thresholds are set in the ground station so if an exceedance occurred in-flight, it would be only highlighted once the HUMS data was downloaded to the ground station… There was no direct data link between the helicopter manufacturer and the operator’s ground station. HUMS support by the manufacturer relied on emailed screenshots and periodic copies of the ground station database to facilitate technical support”

There were other contributory factors in this accident.  The magnetic particle discovered on the epicyclic module chip detector on 25 March 2009 was not recognised as an indication of degradation of the second stage planet gear which subsequently failed. The ring of magnets installed on the AS332 L2 and H225 main rotor gearboxes reduced the probability of detecting released debris from the epicyclic module. HUMS did record a chip warning on the flight but it was only three minutes and three seconds before the cockpit MGB oil low pressure warning and master warning.

The manufacturer’s HUMS experts analysed all the data available prior to the accident and:

“…confirmed that, in their opinion, there was no evidence in the G-REDL HUMS data that suggested a component failure was imminent.”

This finding led the AAIB to consider the question of what components are effectively monitored by HUMS:

“The lack of additional debris collected by MGB chip detectors on G-REDL after 25 March 2009, and the inability of the HUMS system to identify epicyclic bearing degradation shows that the current methods for identifying gearbox deterioration are unlikely to detect the rapid deterioration of a component in the epicyclic module…the effectiveness of the vibration analysis for each component depends on the distance of the accelerometer from the component, the transmission path of the vibration and the quality of the electronic signal acquired by HUMS. If any one of these conditions is affected then the HUMS ability to detect component degradation diminishes.”

Therefore, G-REDL adds a further third category of concern:

  • Gaps in data monitoring.

2012: G-REDW & G-CHCN, H225s


These accidents took place on 10 May 2012 east of Aberdeen (G-REDW) and 22nd October 2012 southwest of Sumburgh (G-CHCN).  Both helicopters lost oil pressure caused by a failure of the bevel gear vertical shaft in the main rotor gearbox which drives the oil pumps.   They made controlled ditchings; the crew and passengers evacuated safely into liferafts and were rescued. There were no serious injuries.

Given the similarities of the accidents, the AAIB investigations were merged and found that:

“The shafts had failed as result of a circumferential fatigue crack in the area where the two parts of the shaft are welded together…On G-REDW the crack initiated from a small corrosion pit on the countersink of the 4 mm manufacturing hole in the weld…On G-CHCN, the crack initiated from a small corrosion pit located on a feature on the shaft described as the inner radius. Debris that contained iron oxide and moisture had become trapped on the inner radius, which led to the formation of corrosion pits.”

There were two relevant HUMS indicators called MOD-45 and MOD-70.  The MOD-45 amber threshold on G-REDW was exceeded 4.62 flight hours before the loss of MGB oil pressure and, on G-CHCN, 4.75 flight hours. G-CHCN also had a red threshold on this indicator which was exceeded 3.63 flight hours before loss of MGB oil pressure. The MOD-70 amber threshold on G-REDW was exceeded 2.95 hours before the loss of MGB oil pressure, and on G-CHCN the last recorded value was 1.71 hours prior to loss of oil pressure exceeding both amber and red thresholds. The epicyclic chip indicator only activated 3 minutes after the MGB emergency lubrication system was activated.

As the fatigue crack grew prior to failure the HUMS indicators were picking up rising vibration trends some 6 and 4.5 flying hours before the accidents on the two aircraft.  The investigation found from testing that the MOD-45 indicator would give readings beyond the red threshold when the crack was between 97-100mm in length. However,

“The guidance to operators given in CAP 753 states that the period between the successful download and assessment of any primary [Vibration Health Monitoring] indicator, used for monitoring the engine and rotor drive system components, should not exceed 25 hours. This interval is reduced to 10 hours for components or indicators that require ‘close monitoring’ where, for example, an indicator value has exceeded a ‘maintenance action’ threshold or shows signs which warrant increased attention.”

HUMS was designed to detect wear and degradation of rotating systems with a low propagation rate, not the accelerated failure rates seen in these two accidents. It was not designed to provide warning of the type of failure that occurred to the shafts on G-REDW and G-CHCN. The MOD-45 indicator did pick up the imminent failure and provided an early warning on both helicopters. The MOD-70 indicator also provided warning of the failure on G-REDW, but both these alerts remained within the HUMS data on the aircraft and unknown to either the crew or engineers on the ground.

The G-CHCN accident led to the grounding of the H225 for 10 months. In order to bring the helicopter back into service prior to redesign of the MGB the manufacturer introduced several alerts using the MOD-45 indicator to warn of the possible presence of a crack on the bevel gear vertical shaft. Of particular relevance to the issue of timely availability of reliable data for decision making, was the decision to introduce further real time monitoring into the cockpit, introducing a MOD-45 alert. The H225’s MFDAU (Miscellaneous Flight Data Acquisition Unit) software was updated to:

  • Calculate the MOD-45 indicator in real time;
  • Increase the acquisition rate;
  • Display the MOD-45 indicator status on the HUMS Control Panel in the aircraft; and
  • Introduce a ‘HUMS’ light on the instrument panel to indicate if the MOD-45 threshold has been exceeded, or if there has been an invalid or no MOD-45 acquisition for 30 minutes or no data received from HUMS (ASB No EC225-45A010 ‘Central Maintenance System – HUMS – M’ARMS MOD45 on-board monitoring system’ 8th July 2013).

When the new H225 MGB was introduced these real time HUMS indications were removed including the cockpit alert. The problem is that in-flight indication risks are likely to increase the ditching rate through false alerts.  Although the H225 MOD-45 cockpit indicator was certified and calibrated by the two in-flight failures, even that had a high false alarm rate.

The two accidents illustrate that, even where HUMS data is available, if the rate of deterioration of the component is fast then there may well be no opportunity within the current HUMS framework to assess the data and make a timely judgment on the health of the aircraft. In both of these cases the data was available, even though it came from a source that was not intended to be monitoring for such a fault.

2016: LN-OJF, H225

In some instances the particular area affected within a component isn’t monitored by HUMS. On 29th April 2016 a Norwegian H225 suffered a catastrophic failure of the MGB resulting in 13 fatalities. This accident is still under investigation, but the Preliminary Report by the AIBN stated that:

“… the accident most likely was the result of a fatigue fracture in one of the second stage planet gears. What initiated the fatigue fracture has not yet been determined.”

The AIBN made specific comment concerning the lack of warning mechanisms in this part of a major component, stating that:

“The observed failure mode in this investigation seems to differ from what was expected or foreseen during certification. AIBN believes that a sub-surface crack has propagated without creating a significant amount of magnetic debris from spalling. Also, the HUMS appears unable to identify symptoms of such degradation in the epicyclic module.  It appears that the fracture of the failed second stage planet gear on LN-OJF has propagated in a manner which is unlikely to become detected by existing mandatory or supplementary systems for warning of an imminent failure.

The epicyclic causes real issues for measuring vibrations as it is difficult to place sensors on the gears which move in a complex geometry. However, some system of monitoring is needed given the incidents in this area of the MGB.  I have commented elsewhere that:

“Finding and remedying the cause of the crash will also need to be accompanied by some method of identifying future symptoms of degradation before the H225 ever flies again as well as gaining certification for the process; this will take some time.” Future of H225 compounded by HUMS investigation remark (6th July, 2016) HeliHub,

The European Aviation Safety Agency and FAA response to this incident, allowing the H225 to return to service, are both surprising and precipitate.  The cause of the accident may be known, but there is still no proposal for effective monitoring of this critical area: the H225 should not be brought back into service until there is (see Helitech 2016: Return of the H225 Part 2, 12th October 2016 Helihub,  If there is a return to service Accountable Managers will need to assess carefully whether the proposed monitoring is sufficient.

This need for enhanced monitoring seems to be accepted by Airbus CEO Guillame Faury, understandably eager to return the H225 to service.   In a media conference call on January 27th he pledged to review processes to raise safety across the offshore industry with more effective monitoring and sensors playing a key role in this review:

“We believe there is a much broader use of HUMS to be made, maybe no longer HUMS as we see them today…better use of data, more sensors on board, data being transferred, digital products and services”.

In each of the five accidents looked at the deterioration of the component that has caused the accident has happened relatively quickly putting pressure on a HUMS monitoring process which it was not designed for but is increasingly being called upon to respond to, both for the enhancement of safety and confidence in flight.  The three key areas highlighted are:

  • Timely availability of reliable data for key decision making;
  • The level of expertise required and available to interpret the data accurately; and
  • Gaps in data monitoring.

The HUMS system was originally designed to monitor trending of parts over a time frame of 50-100 hours; it was not designed to cope with a rate of component deterioration that is much faster, such as 4-10 hours.  However, given the recent accidents, the development of HUMS needs to progress so that the data is available and can be used to alert operators when the rate of deterioration is accelerated. Such an alert was quickly placed into the cockpit of the H225 following the incident involving G-CHCN to enable its return to service prior to a change out of all main gearboxes, but this would require extremely accurate alerts to be designed to avert unwarranted ditchings. The notification mechanism was adapted to get the H225 flying again following the grounding as in cases of fast component deterioration you cannot rely on a safe return to wherever a HUMS Ground Station Computer is based to download and interpret the data. There are other possible solutions to this problem that don’t place the decision point in the cockpit, reducing the risk of unwarranted ditchings:

  • The real time transmission of HUMS data to a central point staffed with appropriate expert personnel may ultimately be the way forward for tackling the concern of timely access to, and accurate interpretation of, HUMS data;
  • Downloading data whilst on the rig during turn round would cut alert times in half. Of course, oil companies would have enhanced safety but also the risk of a helicopter stranded for recovery and a possible shut down of their operations if there is no parking area; and
  • I have also been informed by experts in this field that enhanced oil debris monitoring may be a better detection solution for some problems but has had very little attention.

Given the sequence of accidents detailed above where the immediacy of fault identification and expert response was critical, a combination of these and other approaches will be necessary to prevent future similar incidents.

Following the tragic accidents that have occurred recently in offshore helicopter transportation there is a real need to develop greater confidence in flight for passengers. This requires a step change in thinking and leadership to generate a speedy response as the underlying safety issues affect all helicopter types and all operators. Regulators and operators need to work with manufacturers to enhance the HUMS or other monitoring and alert capability in the three areas I have identified.

It is noticeable that it was an operator, Bristow, that led the HUMS initiative back in 1984 spurred on and supported by a regulator, the UK Civil Aviation Authority. This issue is now too important to be left to one manufacturer or operator. One option is for HeliOffshore, well placed given their wide membership and remit, to provide the necessary leadership and oversight of this safety initiative. I put this to Gretchen Haskins, CEO of HeliOffshore as a role that her organization could champion and she told me that,

“Demonstrating an industry-wide commitment to enhancing safety, HUMS experts from HeliOffshore member organisations are collaborating to identify and share best practice in the use of HUMS. Their work led to the development of global HUMS best practice guidance, which was published. Experts continue to collaborate, including work to identify potential alternate methods of detection that could be used to enhance the reliability and resilience of the offshore helicopter fleet.”

HUMS has developed since the 1990s as a very significant safety tool, expanding to cope with events that it was not originally designed for and at the same time placing increased pressure on the engineers analysing and interpreting the data. With focused development and rigorous oversight it can prevent even more helicopter accidents.


Copyright and full responsibility for the content of this article remains with Allan Blake, is an independent Aviation Consultant & Journalist. He is the author of “Dynamic Directors: Aligning Board Structure for Business Success” (Macmillan).


, , , ,

Copyright © 2023 HeliHub

Website by Design Inc

Helihub logo