I've gone over the A330 FCTM and a cursory look at its overhead panel and for the life of me I can't find a flight computer disconnect switch -- which the article seems to confirm [1].
This is crazy! Boeing provides for the situation where your flight computer is going haywire, for example in the 777 [2].
[1] "As much as they can, the pilots try to assert control over the A330 while the computer system operates. It cannot be fully disengaged."
Final report (2011) https://www.atsb.gov.au/media/3532398/ao2008070.pdf conclusion: Although the [flight control primary computer] FCPC algorithm for processing [angle of attack] AOA data was generally very effective, it could not manage a scenario where there were multiple spikes in AOA from one air data inertial reference unit [ADIRU, of which there are three] that were 1.2 seconds apart. The occurrence was the only known example where this design limitation led to a pitch-down command in over 28 million flight hours on A330/A340 aircraft, and the aircraft manufacturer subsequently redesigned the AOA algorithm to prevent the same type of accident from occurring again [...] Each of the intermittent data spikes was probably generated when the
LTN-101 ADIRU's central processor unit (CPU) module combined the data value from one parameter with the label for another parameter. [...] they noticed a NAV IR 1 FAULT
6 caution message on the [electronic centralized aircraft monitor] ECAM [...] the flight crew were unable to enter an
RNAV (GNSS) approach into the flight management computer due to fault messages associated with the Global Positioning
System (GPS) units.
(ie. probable source = software in Northrop Grumman designed ADIRU unit, real apparent cause = low level language off by one / bounds checking error in control software within Northrop Grumman designed ADIRU unit, fault interactions = significant and undocumented/untrained, handling = issue apparently detected early but not responded to with a process that adequately constrained the impact, potential impact = mass casualty.)
Potential fixes:
(1) Ban the use of low level languages with manual memory management for safety critical systems, even those supplied by third parties.
(2) Enforce more draconian levels of testing on safety critical systems.
(3) Review the flight control system's algorithms and have it ignore by default one spurious input from the set of 3x live ADIRU units, if 2xADIRU concur and 1xADIRU is providing disparate data.
(4) Review the available responses / handling processes for obscure errors presented to pilots which may result in undocumented/untested/rare flight control system states.
(5) Critically review the interaction between ADIRU and GPS sources of positioning data within the flight control system in the event of module failure or abnormal data output.
The ADIRU in question is a product of Northrop Grumman, not Airbus, and is pictured on page 33 of the report. This fact probably influenced the testing regime designed and executed against the component and its assumed failure modes. Later in the report it is revealed that only some Airbus A330s use the Northrop Grumman ADIRUs: Airbus advised that
at the end of 2008, there were about 900 A330/A340 aircraft in operation, and 397 had Northrop Grumman LTN101 ADIRUs.
Relevant quote from https://github.com/globalcitizen/taoup is Wiener's Eighth and Final Law: You can never be too careful about what you put into a digital flight-guidance system. - Earl Wiener, Professor of Engineering, University of Miami (1980)
This is crazy! Boeing provides for the situation where your flight computer is going haywire, for example in the 777 [2].
[1] "As much as they can, the pilots try to assert control over the A330 while the computer system operates. It cannot be fully disengaged."
[2] https://imgur.com/a/6MCb0