OK, I guess here's where I come in...
The general gist of the previous replies is correct. To answer the question thoroughly would require an essay-length reply or longer, so I'll try to stay brief for now and for a more in-depth look, direct you at this PDF, which covers things in greater detail:
http://www.cs.ucc.ie/~herbert/CS4504...2000627364.pdf
A few ground rules worth understanding include the following:
- We're talking purely of flight control computers here -or the FBW aspect. FMS/automatics are a completely separate concept.
- As the A320 was not just the first iteration of Airbus's civil FBW technology, but a world first - the tendency was to overengineer things slightly. As an example, the functions handled by the FACs in the A320 were folded into the PRIMs and SECs on the A330/340 (and hence the change in designation).
- There are several layers of redundancy at work. Not just duplicating the systems themselves, but function-sharing in terms of physical connections and a dissimilar codebase for each.
- The hardware used was already obsolete by the mid-'80s. This meant that the hardware was fully understood and predictable in terms of operation.
- This in turn necessitated a very simple codebase - which was and is standard practice in realtime systems development.
- Megabytes and gigabytes of storage have little bearing on this kind of technology, because it is designed to be lightweight in terms of complexity (and as such reduce risk of error).
As far as the dissimilar codebase goes, the ELACs, SECs and FACs each have the same basic hardware implementation per type (the ELACs based around the Motorola 68010 and the SECs around the Intel 80186), but the code developed for ELAC1 was different to that of ELAC2, and the same went for the SECs and FACs.
To give an example of function-sharing and redundancy in the physical sense, I'll quote from the article linked above:
The computers and actuators are also redundant. This is illustrated by the A320 pitch control (left imd right elevator, plus Trimable Horizontal Stabilizer - 'THS). Four control and monitoring computers are used, orie is sufficient to control the aircraft. In normal operation, one of the computers (ELAC2) controls the pitch, with one servocontrol pressurised by the Green hydraulic for the left elevator, one pressurised by the Yellow hydraullic on the right elevator, and by electric motor NO2 for the THS. The other computers control the other contra11 surfaces. If ELAC2 or one of the actuators that it controls fails, ELAC1 takes over (with the servocontrols pressurized by the Blue hydraulic on elevators, and with THS motor NO1). Following same failure method, ELACl can hand over control to SEC2. Likewise, pitch control can be passed from one SEC to the other depenlding on the number of control surfaces that one of these computers can handle.
At the risk of repeating myself, I'm going to reiterate the point about the hardware used being obsolete even by mid-'80s standards because it is crucial to understand, given the scuttlebutt aimed at the system over the years. Your home PC with its modern processor is the equivalent of a Formula 1 engine - designed to run complex software at tremendous speed, with the caveat that it will crash from time to time. Realtime systems use obsolete hardware and very simple code and would be the equivalent of an old pick-up truck or VW engine - not amazingly fast, but designed to run problem-free and reliably for an unbelievable amount of time. For this reason, specialist firms are still knocking out hardened packages based on processor designs that are over three decades old, because for most realtime work you don't need anything much more complex!
The software too is based on completely different principles to what most people are used to. In engineering terms this design principle is known as a Finite State Machine and you tend to encounter them in things like washing machines and microwave ovens. Put simply, there is only a finite number of states (e.g. Fill, Wash, Rinse, Spin, Drain) that the machine can be in, and usually only one of those states applies at any given time. The Airbus flight control software is essentially an interconnected set of these FSMs which can trigger changes in behaviour amongst themselves. This means that a system which appears complex to the outside observer is actually made up of a group of very simple systems which were tested exhaustively in isolation and later in combination with each other.
I realise I've exceeded the bounds of the original question slightly, but I hope this info is useful!