What is so depressing about this whole protracted administrative disaster is that almost everyone assumes that the fault is with the aircraft engineering when it could equally be that the engineering is perfectly adequate for the role in the context of the whole range of risks that are involved, but the standards being used to judge that adequacy are excessive and inappropriate.
This is a twin engine MILITARY helicopter, with two piloting positions and fully duplicated systems right the way through from power supplies and sensors to display instruments.
The engine management systems and the navigation and flight instrument systems were not supposed to be interconnected, so the risks ref FADEC and instrumentation are independent.
Then there are the reversionary modes where displays on the left can be fed from the displays on the right, and vice versa, if there is good reason to feel one of the systems is misbehaving. THEN there are the electromechanical back-up instruments - as far as I remember there is an electromechanical AI on each side, and there was supposed to be a Meggitt combined backup electromechanical HSI & altimeter too. Looked at from an overall systems point of view, it's hard to see that the software in the digital flight and navigation instruments really is flight critical.
Then there is the extensive operating history on all the instruments used, in other aircraft types - I believe they all had FAA certification.
The fact is that too many people have had their fingers burnt with the Chinook FADEC software analysis and certification issues, the crash, and all the subsequent enquiries. No-one has dared make the pragmatic decisions for HC Mk3 that have been taken on other MOD aircraft types such as Apache and C17 that have flight instrument, engine, and a lot of other, software that was "off the shelf" from the USA rather than built from scratch in the way favoured by particular teams of experts at UK MOD / Boscombe Down. The truth is that unless the software is designed from the outset in accordance with the UK Def Stan preferred methodology, it's virtually impossible to get the tick in the box from Boscombe Down that says "Yes, we can assure you this is absolutely safe and a software glitch will never give you a problem".
The experts have not been proved that the systems and aircraft are DANGEROUS; rather, they have been unable to prove independently that they are absolutely fault-free. That is a very different thing.
This little extract from the 2004 Public Accounts Committee report should have received far more attention as a possible route out of the morass:
"The Department acknowledged, however, that, as with the Apache Attack Helicopter, it was not always necessary to have access to source codes to achieve adequate safety assurances. The Department currently operates the C17 aircraft within United States' safety parameters without having independently validated the avionics software codes."
i.e. don't blame the aircraft, or the contract it was purchased under, blame lack of systems-wide failure-modes-&-effects analysis, and gold-plated MOD UK software assessment standards that very few people understand enough to challenge.
We will probably never know what actually happened in-between all the documentation leaving the MOD PE offices citing Def Stan 55, and a contract actually being placed on Boeing by the embassy offices in Washington. It IS clear that there were fundamental conflicts between the overall policies to maximise use of Commercial Off-the-Shelf software and Boscombe Down's preferred software engineering and analysis methods. Within the limited budget available the Boeing engineers, and everyone else with a brain involved at the time, must have put creating a system that would do the job, using certificated components that were already proven in other aircraft, in a highly redundant system, as a higher priority than designing a complete new set of instruments from scratch for just eight aircraft at far higher cost much more slowly and with more timescale risk.
Also from the Public Accounts Committee report of 2004: "there needed to be a better understanding of the underlying safety issues, particularly where there was a unique British requirement for the independent validation of source software codes. The need to validate independently the software codes for the Chinook Mk3 had been a British requirement. Other countries, including the United States, were happy to fly the aircraft. "
N.B. This is saying "make sure you challenge the requirement" just as much as it is saying "carry the requirement right the way through the contract to the testing and the release to service".
Indeed Boeing has always asserted that the aircraft is safe and fit for purpose - including extremely low level night-time operations in bad weather - which Boeing was perfectly well aware were the intended missions for this aircraft type. Their test pilots had passed the aircraft as fit to fly.
So the wasted costs being discussed may really be the costs of a policy, not the costs of an aircraft that according to some daft newspaper reporters "can't fly in the rain".
One other cause of the problems that seems not to have received much comment is that if most of the people on a project change part way through, through retirement or whatever, key aspects of their approach may get lost too.
Any comments or corrections from people more closely associated with this programme recently?