QF842 Data entry error and tailstrike
Join Date: Jun 2006
Location: Australia
Posts: 73
Likes: 0
Received 0 Likes
on
0 Posts
Takeoff data entry into the FMS is one of the most critical stages of flight which requires the upmost diligence as the consequences can be catastrophic. The routine of turn arounds, time pressures and complacency are major threats to this duty, and mistakes and wrong data entry can be easy to do.
But as mentioned earlier, cross checking the load sheet T/O weight with the FMGS calculated takeoff weight after ZFW insertion should be a fail safe, unless of course the is an error with the load sheet.
But as mentioned earlier, cross checking the load sheet T/O weight with the FMGS calculated takeoff weight after ZFW insertion should be a fail safe, unless of course the is an error with the load sheet.
Join Date: Dec 2002
Location: Australia
Age: 64
Posts: 22
Likes: 0
Received 0 Likes
on
0 Posts
This problem has been around for years. Incorrect data entry is a problem that won't go away no matter what crew actions are put in place. The reason I say that is simple. The last threat barrier in the threat sequence is a crew procedure. There any number of reasons why these procedures fail to trap the threat, the point is that they will continue to occur.
The only way to prevent this from happening again is to place a technological barrier as the last defence. A good example of this is and where it works is with the threat of mid-air collisions. ACAS is the last line of defence, when all the other barriers have failed. With this tailstrike incident placing a technology solution as the last line of defence will stop the threat. Some example that are readily available are wheel weight sensors that would feed the aircrafts know weight straight to the FMC (This has been available to the trucking industry for years). Another is aircraft acceleration software. If the aircraft does not accelerate at a predetermined rate down the runway, then the pilots are alerted.
The pilots still have an important part to play in the process but threat illimination in this human machine interface should have a technological solution, not human.
The only way to prevent this from happening again is to place a technological barrier as the last defence. A good example of this is and where it works is with the threat of mid-air collisions. ACAS is the last line of defence, when all the other barriers have failed. With this tailstrike incident placing a technology solution as the last line of defence will stop the threat. Some example that are readily available are wheel weight sensors that would feed the aircrafts know weight straight to the FMC (This has been available to the trucking industry for years). Another is aircraft acceleration software. If the aircraft does not accelerate at a predetermined rate down the runway, then the pilots are alerted.
The pilots still have an important part to play in the process but threat illimination in this human machine interface should have a technological solution, not human.
start a clock at TOGA initiation. It normally takes between 32-40 seconds to Vr. From the beginning of the runway, you will pass "80 Knots" call passing the 1500' markers. Try it for the NG as a gross error check.
Nunc est bibendum
....you will pass "80 Knots" call passing the 1500' markers.
Was always great fun. I've got some go pro footage of me in the 767 and almost without exception, every take off has me with a goofy grin on my face when the thrust kicks in. 
But yes, as a gross error check it's a good one.
Suspected tail strike and they did not return to Sydney.
Doesn't make sense to me.
Doesn't make sense to me.
Suspecting a tailstrike, the flight crew conducted the tailstrike checklist and contacted the operator’s maintenance support. With no indication of a tailstrike, they continued to Darwin and landed normally.
