Go Back  PPRuNe Forums > Flight Deck Forums > Rumours & News
Reload this Page >

MAX’s Return Delayed by FAA Reevaluation of 737 Safety Procedures

Rumours & News Reporting Points that may affect our jobs or lives as professional pilots. Also, items that may be of interest to professional pilots.

MAX’s Return Delayed by FAA Reevaluation of 737 Safety Procedures

Old 4th Aug 2019, 21:23
  #1761 (permalink)  
 
Join Date: Dec 2006
Location: uk
Posts: 752
Received 19 Likes on 6 Posts
It is virtually impossible to reproduce startle effect in a simulator.
olster is online now  
Old 4th Aug 2019, 23:29
  #1762 (permalink)  
 
Join Date: May 2011
Location: NEW YORK
Posts: 1,352
Likes: 0
Received 1 Like on 1 Post
Perhaps a general consensus is emerging among the regulators as to what the needed enhancements are that will restore the MAX to airline service.
If so, it is extremely well hidden from the travelling public.That suggests considerable further delay, because there will need to be general agreement that the aircraft is safe to fly.
For instance, China is one of the major MAX customers, but in the current near trade conflict environment, Boeing will not get much leeway there.

So the question to the experts here is whether a plausible scenario for a return to flight before 2020 is even possible, much less likely, given the technical and political obstacles.
etudiant is offline  
Old 5th Aug 2019, 01:49
  #1763 (permalink)  
 
Join Date: Jul 2019
Location: Mass
Posts: 23
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Tomaski
As far as the test you refer to, it was a different malfunction than the one presented to the accident crews, particularly as it presented a runaway trim with the A/P engaged so no one was getting direct feedback through the controls. Even though the FAA reports that this malfunction has never been seen in actual operation, it deserves to be fixed because you never know when the stars will line up against you.
The malfunction also involved flipping a bit to fool the FCC computer into thinking MCAS was active, which disabled the control column cut-out switches from stopping the runaway trim. One or more of the other bit flips must also have prevented the FCC computer from recognizing that MET was being used because use of MET should have reset the MCAS bit to "off," which should have re-enabled the control column cut-out switches (unless the pilots were told to recover without MET). As I wrote before, and tried to explain again (my comment wasn't posted), the likelihood of a five-bit error flipping the five specific bits needed to create the simulator scenario is beyond astronomically small. If the chance of the stars (or in this case neutrons) lining up, over the lifetime of the type, is less than one in a trillion, would you still say that it deserves to be fixed (even though the chances of messing up the fix is probably a lot greater than that)?

Originally Posted by Tomaski
The current FCC architecture relies very heavily on the pilots detecting a malfuntion, and if the airlines aren't going to properly train for this role then the architecture needs to be fixed.
The pilots of both accident aircraft detected a malfunction. Detecting the malfunction with enough time to take corrective action wasn't the problem in either flight. The Lion Air crew successfully countered with nose-up trim for about 6 minutes. Nobody knows why they stopped or why they didn't turn electric trim off (or why they apparently advanced the throttles in the final dive). The Ethiopian Airlines crew detected the malfunction but failed to follow the AD (I also believe ET302 was overweight, further complicating the crew's situation).
Notanatp is offline  
Old 5th Aug 2019, 05:24
  #1764 (permalink)  
fdr
 
Join Date: Jun 2001
Location: 3rd Rock, #29B
Posts: 2,951
Received 856 Likes on 256 Posts
Originally Posted by Mad (Flt) Scientist
I

Having been part of a significant software redesign of a flight control system for a part 25 aircraft, which addressed a multitude of failure cases (including some we found in the course of the redesign and the associated design reviews...
M(f) S; was that OEB117 or LSAS?
fdr is offline  
Old 5th Aug 2019, 05:48
  #1765 (permalink)  
nyt
 
Join Date: Apr 2004
Location: France
Posts: 32
Likes: 0
Received 1 Like on 1 Post
Originally Posted by olster
It is virtually impossible to reproduce startle effect in a simulator.
you would need to pose a meaningful threat to the pilot, which cannot be physical harm for obvious reasons. What else? Suspending the licence for a year if one fails?
nyt is offline  
Old 5th Aug 2019, 06:11
  #1766 (permalink)  
 
Join Date: Apr 2019
Location: EDSP
Posts: 334
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Notanatp
The malfunction also involved flipping a bit to fool the FCC computer into thinking MCAS was active, which disabled the control column cut-out switches from stopping the runaway trim. One or more of the other bit flips must also have prevented the FCC computer from recognizing that MET was being used because use of MET should have reset the MCAS bit to "off," which should have re-enabled the control column cut-out switches (unless the pilots were told to recover without MET). As I wrote before, and tried to explain again (my comment wasn't posted), the likelihood of a five-bit error flipping the five specific bits needed to create the simulator scenario is beyond astronomically small. If the chance of the stars (or in this case neutrons) lining up, over the lifetime of the type, is less than one in a trillion, would you still say that it deserves to be fixed (even though the chances of messing up the fix is probably a lot greater than that)?



The pilots of both accident aircraft detected a malfunction. Detecting the malfunction with enough time to take corrective action wasn't the problem in either flight. The Lion Air crew successfully countered with nose-up trim for about 6 minutes. Nobody knows why they stopped or why they didn't turn electric trim off (or why they apparently advanced the throttles in the final dive). The Ethiopian Airlines crew detected the malfunction but failed to follow the AD (I also believe ET302 was overweight, further complicating the crew's situation).
1. As I wrote before, I am not sure that the five flips coinciding was transmitted correctly through the com. channel main stream media.
2. Even if it was, the astronomically small probability is irrelevant because it uncovered a massive shortcoming of the FCC to handle an exception that may occure through other failure modes as well. They can only be mitigated by choosing an appropriate architecture.
3. Time argument isn't sound. Time was enough to put the aircraft in an energy state and attitude preventing recovery. No, the ethipoian crew did not push the throttles forward during dive.
4. It has been proven by argument and experiment that pilots are unsuitable for pushing the occurance probability for a rare but catastrophic event from the 1e-6 range to the 1e-9 range. This is due to their human nature and not their training state.

Last edited by BDAttitude; 5th Aug 2019 at 06:42.
BDAttitude is offline  
Old 5th Aug 2019, 10:33
  #1767 (permalink)  
 
Join Date: Aug 2015
Location: UK
Posts: 0
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Notanatp
Interestingly, none of the reporting has said just how likely the test scenario was to occur in flight, other than to say it was "esoteric," or "theoretical," or "extremely improbable."

The test simulated the effect of 5 bits being simultaneously flipped in the FCC's memory due to cosmic rays or some other unnamed cause. The 5 bits were independent. One bit was flipped to tell the FCC that MCAS was active when it wasn't (this disabled the yoke cut-off switches). Another bit told the FCC to incorrectly issue a nose-down trim command. The other 3 bits weren't described but apparently were necessary to create the runaway trim scenario.

Assuming a 5-bit event, the odds of these 5 specific bits being flipped depends on the size of the memory. If the FCC has 1-megabyte of RAM, then the odds of those particular 5 bits being flipped in a 5-bit event should be on the order 10**-32. I don't know how frequently the FAA estimates a 5-bit event will occur on an aircraft with a 1-meg memory, but even if it approaches 1 (i.e., it can be expected to happen each flight), the likelihood of this particular 5-bit event occurring on any single flight is on the order 10**-32. You could fly all the 737 Max's that will ever be made 3 times a day for a billion years, and you'd still be looking at probabilities on the order of 10**-16.

As for the rest of the reporting, I cannot find it now but I've read one account of the test that said all three test pilots recovered the airplane if it was assumed they recognized the problem within 3 seconds (the time to respond to an autopilot runaway pitch trim). The FAA wasn't satisfied with that so it ran additional tests were it allowed the failure to go longer before being recognized, and one of the three pilots either couldn't recover or didn't recovery fast enough. My understanding is that it was on the basis of this addition test where it was assumed that only an exceptional pilot would have recovered, therefore, the catastrophic classification. Has anyone else seen this account, and if it is correct, then doesn't it sound like this is rigged against Boeing?
There's a significant assumption here that bit flip events are what are referred to by statisticians as IID (independent and identically distributed), but if they are bits within a single word of data in memory or a single register within the processor they could be physically extremely close together. The 286 is based on 1.5um technology so those bits may be only tens of um apart. For memory devices they could be closer. I don't know enough about cosmic ray events to know whether a single event could affect multiple bits within a small area like that.
david340r is offline  
Old 5th Aug 2019, 10:50
  #1768 (permalink)  
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 62
Posts: 424
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by david340r
There's a significant assumption here that bit flip events are what are referred to by statisticians as IID (independent and identically distributed), but if they are bits within a single word of data in memory or a single register within the processor they could be physically extremely close together. The 286 is based on 1.5um technology so those bits may be only tens of um apart. For memory devices they could be closer. I don't know enough about cosmic ray events to know whether a single event could affect multiple bits within a small area like that.
The Seattle Times article (quoted earlier) specifically states that the FAA regarded the 5 bits flipping as a "single event", however improbable this may seem. AFAIK this is equivalent to a "single point of failure", and since there are no redundant software checks, it cannot be permitted in an automated flight control.

Edit: Cosmic rays are not the only way to trigger bit-flips, merely one of the more colourful possibilities that a lay audience can understand. Electrical spikes, and various hardware factors, may also play a role. Some computers are fitted with parity checks, to detect specific kinds of bit-errors, but these are not foolproof.

P.S. I previously pointed out that the probabilities suggested by Notanatp are misleading.

Last edited by GordonR_Cape; 5th Aug 2019 at 11:11.
GordonR_Cape is offline  
Old 5th Aug 2019, 11:48
  #1769 (permalink)  
 
Join Date: Mar 2006
Location: Vance, Belgium
Age: 61
Posts: 270
Likes: 0
Received 5 Likes on 3 Posts
Originally Posted by david340r
I don't know enough about cosmic ray events to know whether a single event could affect multiple bits within a small area like that.
Yes, cosmic rays can produce multiple soft errors.
These are more prevalent with secondary cosmic rays that are neutrons and with higher altitude.
Theoretically, they could also be produced by a direct hit from high energy gamma rays, but the probability that such a particle traverse the high atmosphere unscathed and hit the semiconductor is very remote.

More information in this document, searching with the keyword "multiple".
https://pdfs.semanticscholar.org/511...d29980c6fa.pdf
Luc Lion is offline  
Old 5th Aug 2019, 12:59
  #1770 (permalink)  
 
Join Date: Aug 2019
Location: Argentina
Posts: 10
Likes: 0
Received 0 Likes on 0 Posts
My humble two cents for evaluation:

It seems again that FAA and The Boeing Co. are trying to find 'someone' or 'something' guilty of activating MCAS. They did not succeeded with the pilots, now they are going for the 'cosmic rays'. They are imagining scenarios so far out and crazy that gives me the chills. Because they are saying the general public that a computer can fail and flip the result of calculation or a memory position (twice in a couple of months) due to cosmic rays?? come on... the scenario is so bizarre, that I seriously doubt about all this. Seems the 'proper way' to introduce a reformulation of the automated flight control systems on the 737 after a major f*@ked up piece of software.

Boeing is 'ready' to deliver the redesign to use both flight computers? In a month's time?? looks like a child trying to hide the broken pieces of the TV's remote after mom and dad told not to touch it.

Those ill fated aircraft had control issues for sure, the indication of the AoA was wrong even before taking off (major fault not detected by the computer), if the main gear is contacting ground, and in T/O configuration @ 80 kts I simply cannot be 75 deg nose up... or... the hell of a sloped runway.
The MCAS activating 'only' after flaps 0... so... if the flaps are 1 notch down, well OK, lets die everybody as men... MCAS will not act... as soon as the pilots selects 0... hang on for the ride everybody!!! seems now that an aircraft cannot be in a sharp turn stalling with flaps 1.
MCAS is an 'automated' system kicking in unannounced while on 'manual' flight to 'help?' those monkey rider pilots who are stalling the craft... seems an insult to a pilot

and now everybody is talking about cosmic rays and bit flip on microprocessors. It's classic 'corporate' story deviations... well you know... maybe it was a memory flip...

I work with realtime automation systems... the main point of all this is to analyze the inputs and the memory every single scan of the program (the computer is reading every cycle the status of the inputs and analyzing the program to produce the actions or outputs), even if 5 bits where flipped, the program must evaluate again in the next cycle and find that MCAS is really not activated, flipping back the result of that operation to the normal status. If not, they 'really' have to check their routines, specially with a system that is modifying the flying surface with the highest authority on the aircraft.

This has 'cover up the main issue' written all over the place... B and FAA know they f*@ked up big time... and they are trying to divert attention.

Well, you know... now, everybody is thinking, well this same computer is on all the NGs... so, they could flip bits... if I am the owner of one of those crafts, or a lessor, I should immediately request a fix for my poor troubled computer...

Rewriting a MAJOR change that is a computer controlling another is a really huge task, not something to be done in a month's time. And at the end... if the computers disagree? which one is right? are both wrong? you need a third to control the other 2 with a voting system... is not that simple.
Maybe the big B is going to teach the pilots with an hour class on an iPad at the end, and business as usual...

I'm not saying that is not possible that such event may ever happen... but in here the possibility that 2 events of this class have kicked in, sustained in time enough to bring down 2 planes, is well... that's impossible. Also, Ethiopian aircraft presented the issue on a previous flight... well, it was a BIIIIG cosmic ray that foul the computer... and also probably foul the technicians on the ground when they checked system integrity,,, hummm... maybe Flash Gordon fired the ray and pointed very well to the microprocessor ... come on guys of B and FAA, get real!

They are looking for an excuse that let them modify the software without having to take the load for the previous error...

again, this is my humble opinion... everybody is free to take their own conclusions, have a nice day using your brain.
halfwinged is offline  
Old 5th Aug 2019, 16:03
  #1771 (permalink)  
 
Join Date: Aug 2006
Location: UK
Posts: 181
Received 16 Likes on 7 Posts
Originally Posted by Loose rivets
I know I'm repeating myself, but it's SO not rocket science that I'm still very uneasy about those trim inputs functioning as expected. Is it conceivable that the PF handed over to his First Officer because the feel didn't alter as expected? Do we know for sure he was concentrating on the check-list as the reason for needing his hands free?

Is there any evidence computer overload ever happened prior to the recent modifications? i.e. was that shock finding the result of fixes?
I'm puzzled by:
At 05:40:27, the Captain advised the First-Officer to trim up with him.
At this stage, they were still using the manual electric trim system, i.e. not trying to turn the trim wheels by hand. I assume the trim wheels are firmly linked and can therefore be used by both pilots together, in theory. But how could using the trim switches on both sides simultaneously make any difference, on the MAX or any previous 737?

Whatever his reasoning, it seems the Captain thought this would help; presumably with an electric trim problem he thought existed.

I'm hoping that a detailed analysis of the CVR recording will add clarity, in this area and generally.
John Marsh is online now  
Old 5th Aug 2019, 17:23
  #1772 (permalink)  
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 62
Posts: 424
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by halfwinged
My humble two cents for evaluation:

It seems again that FAA and The Boeing Co. are trying to find 'someone' or 'something' guilty of activating MCAS. They did not succeeded with the pilots, now they are going for the 'cosmic rays'. They are imagining scenarios so far out and crazy that gives me the chills. Because they are saying the general public that a computer can fail and flip the result of calculation or a memory position (twice in a couple of months) due to cosmic rays?? come on... the scenario is so bizarre, that I seriously doubt about all this. Seems the 'proper way' to introduce a reformulation of the automated flight control systems on the 737 after a major f*@ked up piece of software.

[snip]
I think you have seriously got the wrong end of the stick. This is a new error, and has nothing to do with MCAS, though it does affect the horizontal stabiliser. Fixing MCAS is necessary, and (almost) everyone agrees on that. See: https://www.seattletimes.com/busines...ight-controls/
GordonR_Cape is offline  
Old 5th Aug 2019, 18:05
  #1773 (permalink)  
 
Join Date: Sep 2002
Location: La Belle Province
Posts: 2,179
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by John Marsh
I'm puzzled by:

At this stage, they were still using the manual electric trim system, i.e. not trying to turn the trim wheels by hand. I assume the trim wheels are firmly linked and can therefore be used by both pilots together, in theory. But how could using the trim switches on both sides simultaneously make any difference, on the MAX or any previous 737?

Whatever his reasoning, it seems the Captain thought this would help; presumably with an electric trim problem he thought existed.

I'm hoping that a detailed analysis of the CVR recording will add clarity, in this area and generally.
Not saying this WAS the logic, but one possibility.

Trim switches usually have multiple contacts, to try to prevent single failures causing runaways. There may be logic (even just basic wiring type) that requires both sets of sensors to be in agreement before a trim switch is taken as a valid command.

Suppose your trim switch seems to be working - but whenever you let go the trim moves "on it's own". One possible thought that could flash through your head is an intermittent fault on the copilot side (usually pilot side has priority, but as soon as the pilot lets go, the copilot switch can work)

You MIGHT think that if the copilot puts a command in as well, it may either reinforce your command OR cause his switch to vote itself out if there is any residual fault. In someways its a bot like pressing harder on a switch in the hope that works - and sometimes it does under specific mechanical circumstances.

Total random theory, i admit.
Mad (Flt) Scientist is offline  
Old 5th Aug 2019, 18:27
  #1774 (permalink)  
 
Join Date: Aug 2007
Location: Alabama
Age: 58
Posts: 366
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Mad (Flt) Scientist
Not saying this WAS the logic, but one possibility.

Trim switches usually have multiple contacts, to try to prevent single failures causing runaways. There may be logic (even just basic wiring type) that requires both sets of sensors to be in agreement before a trim switch is taken as a valid command.

Suppose your trim switch seems to be working - but whenever you let go the trim moves "on it's own". One possible thought that could flash through your head is an intermittent fault on the copilot side (usually pilot side has priority, but as soon as the pilot lets go, the copilot switch can work)

You MIGHT think that if the copilot puts a command in as well, it may either reinforce your command OR cause his switch to vote itself out if there is any residual fault. In someways its a bot like pressing harder on a switch in the hope that works - and sometimes it does under specific mechanical circumstances.

Total random theory, i admit.
Looking at the wiring diagrams posted on this thread there is no interlocking of the trim switches, i.e. both sides have the same authority at all times. Is not clear if the drawings posted have all the details, and there is indeed a wiring voting system.
FrequentSLF is offline  
Old 5th Aug 2019, 18:32
  #1775 (permalink)  
 
Join Date: Apr 2019
Location: EDSP
Posts: 334
Likes: 0
Received 0 Likes on 0 Posts
Maybe halfwinged is not so wrong ...

... they could have been looking for a trigger to come forward with this measure. I have argued before that this problem should have been fixable without using the second FCC.
They can now claim we did tests of the utterly most improbable scenarions, never done before, came up with new findings, but we will fix it as safety is pri...bla bla.
Sounds better than we have failed at design, hazard and risk analysis and certification, and have to heave the trim control from DAL C to DAL A, doesn't it?
If it helps them to do the things needed to be done, so be it.

Last edited by BDAttitude; 5th Aug 2019 at 18:43.
BDAttitude is offline  
Old 5th Aug 2019, 18:58
  #1776 (permalink)  
 
Join Date: Jul 2019
Location: Mass
Posts: 23
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by BDAttitude
1. As I wrote before, I am not sure that the five flips coinciding was transmitted correctly through the com. channel main stream media.
2. Even if it was, the astronomically small probability is irrelevant because it uncovered a massive shortcoming of the FCC to handle an exception that may occure through other failure modes as well. They can only be mitigated by choosing an appropriate architecture.
3. Time argument isn't sound. Time was enough to put the aircraft in an energy state and attitude preventing recovery. No, the ethipoian crew did not push the throttles forward during dive.
4. It has been proven by argument and experiment that pilots are unsuitable for pushing the occurance probability for a rare but catastrophic event from the 1e-6 range to the 1e-9 range. This is due to their human nature and not their training state.
1. I'm discussing the information about the simulator scenario described in the Gates Seattle Times article. If that information is wrong, then my comments about the scenario are irrelevant.

2. You can assert that the simulator scenario can occur through other failure modes, but the onus is on you to explain what they are and how likely they are to occur. Just asserting that an "electrical spike" could do this isn't good enough, unless you are prepared to explain how an "electrical spike" could flip 5 specific bits but not do enough damage to bring down the entire processor. Vague reference to "various hardware factors" adds nothing.

3. I assume you are talking about the simulator runs; however, there is nothing in the reporting that said either the 3 second or longer delay in responding to the runaway trim put the aircraft in an "energy state and attitude preventing recovery." All three pilots recovered the airplane when recognizing the runaway trim within 3 seconds. Two of the three pilots successfully recovered the airplane when taking a longer time to initiate recovery under the scenario as modified by the FAA (it would have been nice iff the Gates article said how long the FAA made the pilots wait).

3. I didn't say the ET302 crew advanced the throttles during the dive--I said the Lion Air crew appeared to have done so (look at the DFDR graphs in the Preliminary Report). I said I thought the ET302 plane was overweight.

4. We're not talking about events with probabilities in the 10**-6 to 10**-9 range. You say you previously pointed out that my analysis of probabilities is "misleading" but I beg to differ. There is no a priori basis for assuming that the 5 bit flips are not statistically independent. There is no architectural reason why they would be likely to be located in a single memory word (or byte) and I'm not sure there is even a scientific basis for assuming that a single neutron could flip multiple closely-located bits (as opposed to multiple neutrons flipping multiple bits independently). The Gates article quoted Dwight Schaeffer, a former senior manager at Boeing Commercial Electronics, as saying “Five independent bit flips is really an extremely improbable event." So someone with knowledge believes these are statistically independent. I see no reason to start with the assumption that a former employee would throw out a red herring. Assuming statistical independence, a 1-megabyte RAM, and a 5 bit error occurring on every flight, the simulator scenario is testing something with a probability in the area of 10**-22 (not 10**-6).
Notanatp is offline  
Old 5th Aug 2019, 19:57
  #1777 (permalink)  
 
Join Date: May 2008
Location: denmark
Posts: 8
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by halfwinged
I work with realtime automation systems...
... the program must evaluate again in the next cycle and find that MCAS is really not activated, flipping back the result of that operation to the normal status. If not, they 'really' have to check their routines, specially with a system that is modifying the flying surface with the highest authority on the aircraft.
There are many cases where a bit flip might not be overwritten with the correct value the next control scan. E.g. if a filter or timer value is flipped to an out of range value, it can take hours to return to a normal value. Another example are state derived from ‘history’ e.g. incremental encoders or manual toggle buttons.
The only protection against this is a controller with lock-stepping (bit-flip protection), in automation systems this is seen in SIL rated safety systems.

Originally Posted by halfwinged
Rewriting a MAJOR change that is a computer controlling another is a really huge task, not something to be done in a month's time. And at the end... if the computers disagree? which one is right? are both wrong? you need a third to control the other 2 with a voting system... is not that simple.
You need two fail silent computers (Typ. 4 CPU’s).. A fail-silent system is a type of system that either provides the correct service, or provides no service at all. This ensure that an incorrect calculation is newer propagated out of the box.
A fail-silent system can be implemented by having two CPU’s in the same box, usually named COM and MON, COM is commanding, and MON is monitoring.
Inputs are connected to both CPU’s, and MON has inputs check the outputs generated by COM, if they disagree, they fail silent.
https://www.irit.fr/torrents/seminar...8.pdf#page=120

So both Flight Controller A and B, each need a COM and MON CPU. (Or at least a lockstep CPU like TMS570)
Each Flight Controller might have their own AoA sensor, that may differ in values, this in itself might not be a problem.
What is important is when the two Flight Controllers share their AoA values, they agree on what to do with them, or in rare cases one controller fails-silent. Otherwise we have a Byzantine fault.
Adding a 3’rd Flight Controller might improve dispatch reliability, by being able to MEL a Flight Controller.
HighWind is offline  
Old 5th Aug 2019, 20:18
  #1778 (permalink)  
 
Join Date: Apr 2019
Location: EDSP
Posts: 334
Likes: 0
Received 0 Likes on 0 Posts
Somebody back again?
http://www.cs.toronto.edu/~bianca/pa...gmetrics09.pdf
For those interested in memory corruption.
BDAttitude is offline  
Old 5th Aug 2019, 20:34
  #1779 (permalink)  
 
Join Date: Aug 2007
Location: Buenos Aires, Argentina
Age: 78
Posts: 12
Likes: 0
Received 0 Likes on 0 Posts
Halfwinged wrote:
" And at the end... if the computers disagree? which one is right? are both wrong? you need a third to control the other 2 with a voting system... is not that simple. "

Two computers running two programs written by TWO DIFFERENT PROGRAMMERS is the way some Railways use for controlling the yards. An order is executed if and only if both computers agree.
A third computer, perhaps a carbon-based one, should make the final decision if they don't.
Jorge_Vilarrubi is offline  
Old 5th Aug 2019, 21:23
  #1780 (permalink)  
 
Join Date: Jan 2008
Location: Medically Grounded
Posts: 136
Received 2 Likes on 1 Post
Back in ancient times I designed memory systems to be resistant to bit flipping involving cosmic rays. It was in conjunction with a computer that used a 286 processor, the same one in use in the suspect flight systems. Our solution was to use error detecting and correcting memory. This architecture used extra memory bits that would allow any single bit error in a memory word to be corrected on the fly. The technology was mature at the time the flight control computers were developed. Does anyone know if memory correction technology was used on the Boeing flight control computers? If so it would rule out random bit flips as an error condition.
Piper_Driver is offline  

Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service

Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.