Technology Friend or Foe – Automation in Offshore Helicopter Operations
In London 3-4 July 2014 the Royal Aeronautical Society held a landmark conference on the introduction of automation to offshore helicopters titled: Technology: Friend or Foe? This RAeS conference was triggered by:
- a CFIT accident on approach to Sumburgh airport in August 2013 (AS332L2 G-WNSB),
- the issue, a few weeks later, of a Transportation Safety Board (TSB) report into a serious incident where S-92A C-GQCH where the helicopter descended to within 38ft of the sea,
- the realisation that automation issues were not addressed in detail in the UK Civil Aviation Authority (CAA) North Sea Review, which resulted in the CAP1145 report (the ‘Safety review of offshore public transport helicopter operations in support of the exploitation of oil and gas’).
The conference was notable for an impressive range of speakers and a carefully structured programme that set the context of offshore operations, examined key technology, discussed the modern cockpit, operational procedures and finally training & competency. The conference was an ideal opportunity to look back at how automation had been introduced and the critical lessons, including cultural lessons, that need to be learnt.
To underscore the importance of the topic, just days after the conference the UK Air Accidents Investigation Branch (AAIB) published their report into a serious incident with EC155 OY-HJJ that suffered a loss of control after departure from a helideck in the North Sea in November 2013.
Jim Lyons, who masterminded the conference programme, has produced a detailed summary of the conference. The RAeS Rotorcraft Group are expected to publish a position paper on the topic.
See also our article: Commanders: Flying or Monitoring? which follows up on one presentation that discussed an observation about past large UK helicopter accidents.
UPDATE 21 October 2015 – Further Resources:
A follow up RAeS conference is planned for 6-7 July 2016 (not April 2016 or late July as originally announced).
The European Helicopter Safety Team (EHEST) has published: Safety Leaflet HE9 Automation and Flight Path Management
At the EHEST Safety Worksop at Helitech in London in October 2015:
- The UK CAA gave this presentation: Training – Overview of Automation Issues
- Airbus Helicopters presented: Training – For Automation
UPDATE 9 January 2017: HeliOffshore have released a HeliOffshore Automation Guidance document and six videos to demonstrate the offshore helicopter industry’s recommended practice for the use of automation.
UPDATE 18 February 2018: Autopilot, Mind Wandering (MW), and the Out Of The Loop (OOTL) Performance Problem. According to researchers from ONERA and CNRS:
The OOTL phenomenon has been involved in many accidents in safety-critical industries, as demonstrated by papers and reports that we have reviewed. In the near future, the massive use of automation in everyday systems will reinforce this problem. MW may be closely related to OOTL—both involve removal from the task at hand, perception drop, and understanding problems. More importantly, their relation to vigilance decrement and working memory could be the heart of their interactions. Still, the exact causal link remains to be demonstrated. Far from being anecdotal, such a link would allow OOTL research to use theoretical and experimental understanding accumulated on MW. The large range of MW markers could be used to detect OOTL situations and help us to understand the underlying dynamics. On the other hand, designing systems capable of detecting and countering MW might highlight the reason why we all mind wander. Eventually, the expected outcome is a model of OOTL–MW interactions which could be integrated into autonomous systems.
UPDATE 18 September 2016: AAIB: Human Factors and the Identification of Flight Control Malfunctions
The designer’s view…may be that the operator is unreliable and inefficient… so should be eliminated from the system. There are two ironies of this attitude.
One is that designer errors can be a major source of operating problems…
The second irony is that the designer who tries to eliminate the operator still leaves the operator to do the tasks which the designer cannot think how to automate…it means that the operator can be left with an arbitrary collection of tasks, and little thought may have been given to providing support for them.
This is discussed further in this 2012 paper: The ironies of automation … still going strong at 30?