The initial trail plan is no more nor less liable to planning error than AARWIN - and a lot more accurate.
In flight the receiver fuel states are updated 15 min before the next bracket. Any significant change to the initial plan is down to mathematical calculation in the same way as it would be if an electronic calculator had been used. This includes amended APs, of course.
5 min after the RB, receiver fuel is again checked (that allows time for any receiver transfer issues, gauging settling etc) and the plan updated for the next RB. Exactly as it would be if it was an AARC sitting there with a laptop, but with the added bonus of continuous aircraft data being provided automatically.
Anyway, the level of assurance satisfied the Airbus engineering and airworthiness people - who have very demanding standards. They agree that it is not flight critical, merely mission critical.
If a double failure should ever cause the entire MCS to throw in the towel, the last known plan update (which should have been printed out) can be used if neither MCS processor can be rebooted. Any subsequent receiver issue would of course be rather more difficult to resolve, but the users are happy that the likelihood of both MCS processors failing is so remote that, should that happen and a receiver then has a subsequent fuel problem, a diversion to the abort aerodrome would be the preferred option.
A lot of time and thought went into the system and if used correctly, it is very effective. If users encounter problems, then there is a fault reporting system specifically set up for resolving such issues. But if they don't bother, then how can the issue ever be properly addressed? Was it caused by operator error, software bugs, aircraft interface (e.g bent connector pins, pinched cabling) or what?
Last edited by BEagle; 1st Sep 2014 at 11:36.