Originally Posted by faheel
You are correct in saying one way to fix the problem of putting the zfw into the gw field in the fmc is simply to block any data entry whilst on the ground, but why is it an expensive option?
I don't know Boeing's current FMC software pricelist, but I do know that this software fix has been offered by Boeing for quite some years already as a operator-selectable option. I.e, implementing this fix cost money. Not surprisingly, the beancutters in my company initially didn't see the importance of this option, and consequently we flew for years accepting a totally avoidable risk of gross crew input errors during the pre-flight performance calculations.
My company did just that shortly after a tailscrape incident a few years back, anyway the cost of having that mod done to the fmc software has got to be a hell of a lot cheaper then repairing an a/c or worse still losing one.
I agree, and luckily my company nowadays thinks likewise. But similarly to your company, it took at least one "interesting" incident before the risk was fully acknowledged. This problem could have been fixed years ago. In my opinion, allowing a grossweight input on the ground (not in some obscure maintenance page, but in the PERF INIT page) is a serious ergonomic design error, and the fix should be mandated by Boeing, rather than offered as a payable option. (Perhaps this is also applicable to the Airbus FMS, but I don't know that equipment. But the problem certainly exists/existed in the Boeing and MD-11 FMSs.)
Of course, it remains to be seen if this scenario happened here. On first sight there seem to be similarities with other performance-related takeoff incidents and accidents, but it could very well be something totally different that caused this crash.