This site has quite a few topics regarding the APU, such as: Taking Another Look at Details of the A350 Fuselage Trying out a Boeing 777 Cold and Dark Startup Boeing 787 APU Inlet Door Opened During Flight Comparison of APU Inlet Doors Airline Pilot Exploration 2.3: Push Back from the Gate and Engine Start and so on; perhaps I’m just a bit sensitive to this topic.

Today, while looking at the Japan Aviation Safety Reporting System ASRS Report 201603, I found a case where the APU was turned off during engine start, so I will briefly introduce it here.

After receiving pushback clearance, they began executing the engine start (ENG START) procedure. When the No. 2 engine (ENG 2 START) had started, the Captain set the Parking Brake after contacting Ground. During this time, the First Officer turned off the APU before receiving the Captain’s “Normal Start” command.

Neither the Captain nor the First Officer noticed the APU status and began starting ENG 1. Because the APU Bleed Air was turned off (APU BLEED OFF), the N2 rise was very slow, and the EGT rise rate was extremely fast, so they immediately aborted the start.

Afterwards, they checked the checklist again and contacted ground personnel and Ground Control, finally discovering that the APU was in the OFF state. Following this, they restarted the APU, then started the No. 1 engine, and everything proceeded normally.

Analyzing this operational error after the fact, the wind was very strong that day, and a “Straight Push Back” was used during pushback. Because they assumed there was a Tail Wind and that engine start would be slower, it took a relatively long time to discover the APU OFF status.

So, why did the First Officer mistakenly turn off the APU? According to recollections, the weather was severe that day with high winds, and a runway change happened just during the pushback. This chain of events caused the First Officer’s attention to be scattered, and after hearing the Captain’s “Normal Start” command, they reflexively turned off the APU…

Additionally, since that airline had previously experienced an error where the APU was forgotten and left on, they established a procedure requiring an “APU OFF” callout when shutting down the APU. However, during this combination of situations, this step was still forgotten.

This issue of the ASRS report introduces 160 reports of various errors from the airline operational front, covering various phases of the flight. Although reading it can be a bit dry, it is very helpful for understanding real-world aviation operations. For example, you learn that high-ranking pilots still make these basic mistakes! (One example: an aircraft entered the Runway, the Captain pressed TOGA for takeoff, but the engines had no response. They quickly exited the Runway, and after struggling for a while, discovered that the engine auto-start mode hadn’t been engaged…) Humans are not machines and will always make various errors, but through the ASRS, I believe it serves a role in mutual communication and improvement.

Most things in this world possess vulnerabilities. For example, voice-based ATC communications in the aviation industry contain vulnerabilities such as electronic interference, accents, speech rate, language, ambiguous phrasing, and commands prone to misunderstandings; another example is information security in one’s own work, which always deals with vulnerabilities, such as bugs and security vulnerabilities in OS/system software/application software, insufficient system capacity planning during design, insufficient user requirement analysis, insufficient interface design performance between systems, and insufficient test cases. Humans may be the biggest cause of vulnerability; we make mistakes when busy, nervous, or fatigued, and we are more prone to error when everything is going smoothly and there is no pressure.

Only by recognizing that vulnerabilities are universally present can we adopt the correct attitude at work, avoid taking chances, and steadily take every step well.

End