DozyWannabee
The complexity is mitigated by redundancy, as you state - and the components themselves (derived from the 80186) were obsolete in computing terms in the late '80s, but highly predictable and easy to understand at a circuit level. To compare that to the incredibly dense multi-pipelined designs used in consumer level computers even 10 years ago is like comparing a trusty old pick-up truck engine (powerful enough to do the job, but reliable over long periods of time) to that of a Formula 1 racer (Immensely powerful, but prone to frequent failure).
The demands placed on avionics computers have increased a lot since the
early days, and current systems do in fact use much more powerfull
processors, some of which are pipelined, have extensive cache memories,
as do current desktop computers. Without appearing complacent, I
don't see any real problem with this as avionic systems have arguably
the most rigorous development processes applied to them than any other
development activity. It's very unlikely that any fundamentally serious
bugs would ever be found in the software. By bugs, I mean noncompliance
with original spec. Of course, all this becomes toast if there were
holes in the original spec that failed to recognise and cater for corner
cases, or assumed that they would never occur.
To demonstrate one aspect of how rigorous the whole process is, take the
example of redundant systems. Very often, where a system is say, dual or
triple redundant, both the the hardware and software will be designed
and built to the specification by separate development teams who are
forbidden to collaborate or talk to each other. Often, different
programming languages and hardware processor architectures will be
chosen as well. For example, team A may use Ada on PowerPc, team B, C on
68K/Coldfire, team C, Jovial on Intel x86 etc. The whole point of this
is to enforce separate thinking, different algorithmic processes and a
unique approach to development. Once the development and testing to spec
is complete, the different finalised systems are again rigorously tested
against each other, ie: compared to ensure that they all agree.
Afaik,
no other industry, with the exception of nuclear uses these extreme and
very costly development processes and there is much more to it than the
above brief description.
I worked on avionics in Basingstoke in the mid 80's and even in those
days, the process was quite rigorous. Much of the less critical software
was still being written in assembler, with fadec software catered for by
custom in house control languages. Most of the modules were quite short,
not more than a page or so of assembler and it was designed to be clear
from inspection what the code was doing. For testing, every module was
tested on a simulator running on a Vax or HP mini, with module input
data set up to ensure that every path through the code was executed and
that expected or sane output values appeared for good and bad input
data. Once this was complete, the modules were linked to final code
image and tested to the original product spec, again with normal and bad
input data and with a variety of hardware failures injected for good
measure.
While I have almost complete faith in the avionic systems design, i'm
not so sure about items like pitot probes, which may have been certified
20 years ago and are now perhaps working well outside their original design
limits at least some of the time...