Captain Crunch,
thank you for your gracious reply.
Originally Posted by Captain-Crunch
I suspect I could comprehend some of the FADEC architecture if I had access to it; but I'm sure it's proprietary. (not the physical code, but flowcharts would be interesting.) It would be interesting to know how the sw handles all fuel temp probes iced up. .....
You are right about design and code being proprietary. Your suggestion (flow charts, which no one uses any more as far as I know) concerns design. Then there is the coding. General industry knowledge (not of RR in particular; I have no specific knowledge of the quality of their SW and do not wish to suggest that I have) suggests that in delivered safety-critical SW one can expect about 1 error in about 1000 lines of executable code (LOC). State of the art for the last few years appears to be about 1 error in 25,000 LOC; that has been achieved in well-documented products derived according to a very strict and well-proven analytical regimen during development. So in, say, 150,000 LOC one would not be surprised to find between 6 and 150 errors.
Originally Posted by Captain-Crunch
If you ask me, adding more and more complexity to this automation monster we have created and keeping everything in extreme secrecy is what really does the industry a disservice imho.
A distinguished colleague of mine proposes that all safety-critical software in any domain should be published, by law, so that anyone is enabled to check and comment on the quality of the product. ( And of course to enable the usual army of computer-obsessives to find faults in it faster than the developer
) I think that proposal has a lot to recommend it. First, quality of product will be on public display, so the public will be able to make up its collective mind on a matter of public interest, namely safety of flight. Second, quality will likely improve.
Presumed-quality of SW has been for far too long judged by the process used to develop it, and not by objective properties of the resulting SW product. No correlation has been demonstrated in the scientific and engineering literature between the "usual" features of quality-of-process and the quality of the resulting product, except for those processes which explicitly involve determining objective properties of the product (such as the exclusion of possibilities of run-time failure). The goal of my standardisation work is to bring more focus upon evaluating properties of the SW product.
Originally Posted by Captain-Crunch
And I think it's best to realize that this is after all, a pilot's rumour network, not a tabloid for the public to read. Right?
It seems to be both of those, at least. And who am I to judge its purpose?
PBL