Avoiding human error, Take off calculations

[Capt Groper]

Does anybody have references to information regarding Data Input and Human Error, how best to aviod, trap.

[Three Wire]

Try Human Error by James Reason
and look at your own post post for an example of a human error in data input.

[TyroPicard]

Just out of interest, I did not spot the error until warned about it, when I read the post again more carefully....

[PPRuNe Towers]

Same for me TP,

So much for my proff reaading skills. A chastening experience regarding input errors and crosschecking.

Rob

[Ancient Observer]

I once met a Dr lady from the Belgrano who seemed to have a handle on this. Dr. Sue someone. Try the Human Factors team at the belgrano - (if they still have such a team).

[SNS3Guppy]

We use a system known as Onboard Performance System, or simply OPS. It's a software program which provides for inputs of all the takeoff and landing data, and provides takeoff information, cruise data, and a landing card. In our case, the flight engineer does the calculations. It's also done by flight schedulers/dispatchers prior to generating the flight plan. When the data is entered and printed, it's handed to the captain and first officer, who review it, and one of the checklist items on takeoff (for example) is "Takeoff Data...VALID" (and requires a response from all three cockpit crewmembers.

The response, VALID, verifies that no only are the performance numbers correct, but that the level-off numbers for the engine failure profile are correct, the weight and temperature are right, and other data matches what we know to be reasonable.

I've been handed a card before and said "that doesn't look right." Not very scientific, but after reviewing cards at certain weights and temperatures, one will come to recognize numbers that don't match. Same for enroute altitudes. Most of us apply certain rules of thumb for knowing what altitude we'll need, what fuel we'll need, etc...and we can compare the numbers that the computer spits out to the rules of thumb for a "reasonableness check."

Checking for reasonablness is a check of generalities, however, and doesn't presume to spot small errors.

The OPS data is usually very accurate. However, I've seen it also be inaccurate from time to time, and you could say this may be the fault of whomever entered the data into the program itself, thus creating errors in the program. One of those errors which has been discovered in the past has been the altitude which the program gives us to level-off and accelerate following an engine failure on takeoff.

We're given certain airfields around the world with a Jeppesen "pink page" engine failure procedure. The OPS system should spit out an altitude at which we level off while following the lateral guidance in the procedure. This level-off is a time when we begin to clean up the airplane and address the problem,and accelerate to a better speed. A few instances have popped up in which the level-off altitude isn't right. This isn't an error by the crew, of course; it's an error by whomever put that data into the program itself. We get regular updates to the program, and when errors are discovered, there's a process for making sure it's put right, notifying all crewmembers, etc.

The OPS program itself prevents certain errors. If information is entered which exceeds a parameter, for example, the OPS won't let us go further. Of course, it also opens the possibility of operator error in which the wrong information is entered...which leads us back to your question. We have experienced situations in which the operator entered the wrong fuel load, for example, and the computer program though the airplane weighed substantially less than it did. The performance numbers, takeoff distance, speeds, etc, were all therefore printed out much better than the real world performance data would be.

In such a case, the protection against using those numbers comes from three sets of eyes (in our case) in the cockpit verifying the weights against the flight plan as part of our preflight and our response to the challenge "Takeoff Data...VALID."

Personally, I use a sticky note which is attached to the panel in front of me, which includes all the data from the TOLD card, balanced against the planned data or expected numbers. I have them written side by side, and if they don't match, then it raises a question that must be answered before departing.

We are given some leeway,too. For example, our actual takeoff weight doesn't have to exactly match the planned takeoff weight on the flight release and flight plan that's sent to us. We can be within 10,000 lbs and still use the fuel load and planning that's been for us. If it's more than that, we need to hold the flight and call for a new flight release to be issued, as well as obviously recalculate everything. That's our own policy. Others may vary. That sounds like a major discrepancy, but in the grand scheme of things, considering the overall weight of the airplane (833,000 lbs), it's not that much.

The OPS program has safegaurds built into it to catch errors, and the crew has experience and preplanned numbers in mind, and everyone reviews the data for validity. The same calculations have been through several hands in the flight planning and dispatching department, using the same processes. After that, it's all about what the airplane can really do.

[autoflight]

Always check that each load sheet entry is correct or reasonable and re-check your own or provided calculations whenever possible.
Choice of fuel quantity usually requires consideration of planned take-off and landing weight. So if your fuel / pax / baggage / freight load is as expected, your own pre-planned weights should be about right. If the paperwork does not agree, you have questions to ask of yourself or loading staff. With a bit of experience on your type, typical take-off speeds vs weight should be known. If you are direct Melbourne to Dubai there is no excuse for use of training weight speeds. If the rough estimate agrees, you're not going to scrape the tail off the departure end of the runway.
Worked for me.