>here’s your fully automated flight experience bro
>>2016953>After detailed forensic analysis of the FDR, the FCPC software, and the ADIRU, the CPU of the ADIRU was found to have corrupted the AOA data. The exact nature of the corruption was that the ADIRU CPU erroneously relabelled the altitude data word so that the binary data that represented 37,012 (the altitude at the time of the incident) would represent an angle of attack of 50.625°. The FCPC then processed the erroneously high AOA data, triggering the high-AOA protection mode, which sent a command to the electrical flight control system to pitch the nose down>The ATSB's final report, issued on 19 December 2011, concluded that the incident "occurred due to the combination of a design limitation in the FCPC software of the Airbus A330/A340, and a failure mode affecting one of the aircraft’s three ADIRUs. The design limitation meant that in a very rare and specific situation, multiple spikes in AOA data from one of the ADIRUs could result in the FCPCs commanding the aircraft to pitch down."[15So basically, they don't know what caused it, they still don't know what caused it, they will never know what caused it, but it is a proven possibility. How nice.
>>2016961It’s bizarre that a recurring software glitch can occur and it’s impossible to induce or replicate the failure in an isolated test.
>>2016969the wonders of jeet coding
>this glitch only happens in the summertime off the coast of Western Australia
>>2017026Space Jews posing as Abos and the base is inside Uluru or whatever the fuck that rock is called.
>>2016969>>2017026The most convincing theory i've heard is that it happened because of an extremely low frequency radio installation in australia (the nwc, situated in 21°46'48.0"S 114°09'00.0"E). Between 2005 and 2008 it just happened to be running an experiment to measure the effects on the ionosphere of a full power broadcast in a year of low solar activity:https://vlfstanford.ku.edu.tr/research_topic_inlin/introduction-vlf/https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2020JA028383https://link.springer.com/article/10.1007/s44195-023-00046-2
can't you design a plane with two redundant instruments and autopilot systems that are required to be in accordance with each other within a certain tolerance to execute actions
>>2017079OK. You are designing the autopilot. The two sensors are giving different readings outside the safe tolerance. What action should the autopilot take now?
>>2017113crash the plane with no survivors
>>2017053the going narrative, a single event upset, is convincing
>>2017079because you still dont know which system is correct and should control the single plane
>>2016961What flight was this?
>>2017079Why bother with just 2 when you could have 4? Not that it would have made any difference anyways if there's a problem in 3 of them...https://www.youtube.com/watch?v=7Q7OW4RZAiMPersonally I don't call having multiple copies of something working in parallel redundancy, because if they all work the same way they are all vulnerable to the same issues. The only real redundancy is having completely different mechanisms that can do the same result.
>>2017184My recollection of this is pretty shit, but I vaguely recall that a certain military aircraft flight control system used 4 sub-systems, but each system implemented different-but-redundant "rules." So system A handles rules 1 & 2, B handles rules 2 & 3, C handles 3 & 4, and D handles 4 & 1.So if one of the rules was producing dysfunctional behavior, there would only be 2 systems impacted, and the other 2 systems have completely independent copies of the three remaining (presumably non-dysfunctional) rules.
>>2016961That doesn't make any sense. There would have to be spikes in at least two ADIRUs at the exact same time.
>>2017113>two sensorsngmi
>>2017113Compare the readings to the third sensor and sound an alarm to bring the pilots' attention to the discrepancies.
>>2016953If it's Boeing I ain't goeing
