2.0 Analysis 2.1 Introduction Neither aircraft airworthiness nor environmental conditions contributed to the cause of the occurrence. Therefore, the analysis will concentrate on the company computer application in use that affected aircraft operational data, and flight crew handling of the aircraft during the take-off roll. 2.2 ALPAC Computer Application The ALPAC computer application had been used by company load agents for several years without any reported errors in calculations used for aircraft operational data. Load agents were confident with the application and accepted aircraft operational data computed by the application without question. Since the ALPAC-computed CofG for the occurrence flight fell within the operational limits of the aircraft, the agent accepted it and dispatched the flight. He passed the weight and balance information to the flight crew and they accepted the calculations, routinely, as they had in the past. In this instance, an experienced load agent, thoroughly familiar with the loading of aircraft, accepted a computer-generated CofG calculation that located the aircraft CofG near the centre of the flight envelope when the bulk of the freight, 63.3% of the total weight of the freight on board, was loaded in the very aft section of the aircraft. The actual CofG was beyond the aft limit of the flight envelope. The unquestioning acceptance by the load agent of computer-generated data demonstrates a degree of overconfidence that trained and experienced personnel have gained through the use of computers. The ALPAC application in its entirety was not tested after the modification was completed, nor was it monitored after it was put in operation by the airline. In this instance, as with several previous flights, the ALPAC application correctly computed the weight of the aircraft but did not correctly compute the weight moment for the Q-designated pallets loaded on the main deck cargo area. The application is designed to display a computer screen warning to the load agent when aircraft operational limits are exceeded. In this instance, although the CofG was, in fact, aft of the rear limit, the computer data indicated that the CofG was positioned well within the limits; therefore, no warning was displayed. As well, there was no computer indication that the weight moment change was not being correctly computed when the load agent entered Q-pallet information. 2.3 Take-off Roll Since the control column does not move without someone actually moving it, it was concluded that all control column movements, as recorded on the FDR, were inputs by the first officer. As the aircraft accelerated, the nose began to pitch up, gradually increasing with the control column in a near neutral position. The uncommanded nose pitch-up resulted from a combination of the aft CofG, the incorrect stabilizer trim setting (in that the stabilizer was trimmed for a nose-heavy aircraft although the aircraft was tail heavy), and the lack of control input by the first officer to keep the aircraft nosewheel firmly on the runway until rotation speed was attained. The aft control column movement that started at 132 KIAS was considered to be the initiation of rotation by the first officer. The aircraft nosewheel was likely off the ground at this point, without any control input from the first officer. The uncommanded initiation of rotation likely influenced the first officer to continue rotation, even though the airspeed was about 11 knots below VR. The aircraft lifted off below VR with the nose pitched up 13degrees, which caused the underside of the tail to strike the runway. The captain, who was monitoring the first officer's take-off, did not take action to prevent the gradual, uncommanded increase in aircraft pitch attitude during the take-off roll, or to prevent early rotation of the aircraft. Once airborne, the captain told the first officer that the airspeed was low. 2.4 Silent Cockpit Company policy for Boeing aircraft did not require the PNF to call out airspeeds on take-off, and none were called on this occurrence. Both pilots were accustomed to the silent cockpit take-off procedure. The first officer was not experienced on the B747-400 and may not have been accustomed to its characteristic lack of weight exerted on the nosewheel. The light weight on the nosewheel requires the pilot to make a conscious effort to keep the nosewheel firmly on the runway by applying forward control column movement (down elevator) until just before the aircraft reaches VR. The company's rationale for not calling out airspeeds is that it sees no requirement to call out normal information which is displayed to both flight crew. Any call made in this environment will therefore be addressing some abnormality. There are, however, some crew co-ordination and workload consequences arising from this procedure. The PF must direct more of his attention to the airspeed indicator as V1 and VR are approached; he knows that the PNF will not be calling the speeds. This re-focusing of attention could be at the expense of time spent looking outside the cockpit or at other control and performance instruments. As for co-ordination, a verbal call of VR could help ensure that rotation takes place at VR, and not before or after. The V1 speed is less important in a normal take-off situation, but is critical for determining pilot reactions to an engine failure. The absence of a verbal V1 call could create some confusion between the pilots should a power loss occur at an airspeed close to V1. 3.0 Conclusions 3.1 Findings The flight crew was certified, trained, and qualified for the flight in accordance with existing regulations. The occurrence flight was the first officer's second at-the-controls take-off since completing his pilot conversion training on the B747-400. The first officer did not apply sufficient down elevator input to keep the aircraft nosewheel firmly on the runway during the take-off roll. There was an uncommanded nose pitch-up during the take-off roll. Airspeeds were not called out by the PNF during the take-off roll, nor were they required to be by the company. The first officer rotated the aircraft too steeply and at an aircraft speed below the calculated rotation speed, and, as a result, the underside of the tail struck the runway. The captain, who was monitoring the first officer's take-off, did not take action to ensure that the aircraft nosewheel remained firmly on the ground until rotation speed was attained, or to prevent early rotation of the aircraft. The aircraft stabilizer trim setting was incorrectly set because of an incorrectly computed aircraft take-off CofG. The first officer's recent simulator training did not include an aircraft out-of-trim or out-of-balance take-off. A recently modified computer application, ALPAC, used by load agents to plan loads and compute aircraft weight and balance, incorrectly computed the aircraft take-off CofG. The ALPAC-computed aircraft take-off CofG was near the centre of the aircraft flight envelope, while the actual CofG was beyond the aft limit. The ALPAC application produced a large error in the aircraft CofG calculation; however, there was no defence in place to detect such a critical error in the application itself, at the aircraft loading stage, or in the flight crew confirmations of load and trim setting. The modified computer application was not adequately tested before it was released for operational use. The modified computer application was not monitored effectively for accuracy after it was placed in operational use. 3.2 Causes The underside of the tail struck the runway on take-off because the first officer rotated the aircraft too steeply and at an aircraft speed below the calculated rotation speed; the early rotation was facilitated by the far aft CofG and the incorrect stabilizer trim setting. Contributing to the incident were an error in a recently modified aircraft loading computer application, incomplete validation of the modifications to the computer application, and the inability of the aircraft loading system to detect a gross calculation error. 4.0 Safety Action 4.1 Action Taken 4.1.1 Operator Action - Calling of Speeds on Take-off On 15 July 1996, the operator amended its Boeing 747-400 aircraft operations manual to introduce verbal calls at speeds of 100 knots, V1, and VR during the take-off roll. The change in procedures will be applicable to all Air Canada aircraft and will standardize the company fleet operation with the procedures previously accepted for the operation of Airbus aircraft in the company fleet. 4.1.2 Operator Action - Weight and Balance Since the occurrence, Air Canada has taken action to enhance the quality assurance procedures for its load control software. Weight and Balance introduced a position of Operational Control Manager and Technical/Training/Development, effective 01June 1996. More direct control will be taken for software changes, software change specifications will be clearly defined, a full impact assessment will be made to identify all components affected by the change, test databases have been updated, follow-on testing will be done in livemode, and positive confirmation of testing will be achieved. Although its focus is currently on load control software, Air Canada indicated that it is taking a more comprehensive look at the testing environment and procedures for all critical systems. Training lesson plans are being rewritten to strengthen load agents' understanding of the relationship between the manual and ALPAC methods of determination of weight and balance.