AF 447 Search to resume (part2)
Join Date: May 2011
Location: At Sea
Age: 67
Posts: 3
Likes: 0
Received 0 Likes
on
0 Posts
Search Area Refinement
Additional to 'noske's post 1915
Anyone interested in the detailed analysis used to refine the search area should see:
http://wwz.ifremer.fr/lpo/layout/set...A9mentaire.pdf
BEA posted this summary of the sea search operations on Monday already, but I haven't seen it mentioned here before:
http://www.bea.aero/fr/enquetes/vol....16.05.2011.pdf
Most interesting in my opinion are fig.5 and fig. 6. One is a diagram of nine marker buoys and their drift paths, from an experiment made in June 2010. Look at those crazy loops! I guess that is what persuaded them to abandon any predictions about the crash site based on the location of floating debris.
The other is a map used for planning phase 4 of the search, indicating the most likely places to find the wreck. It is based on the assumption that most (but not all) areas already covered by sidescan sonar need not be searched again, and (in contrast to phase 3) that the pingers were probably just not working.
http://www.bea.aero/fr/enquetes/vol....16.05.2011.pdf
Most interesting in my opinion are fig.5 and fig. 6. One is a diagram of nine marker buoys and their drift paths, from an experiment made in June 2010. Look at those crazy loops! I guess that is what persuaded them to abandon any predictions about the crash site based on the location of floating debris.
The other is a map used for planning phase 4 of the search, indicating the most likely places to find the wreck. It is based on the assumption that most (but not all) areas already covered by sidescan sonar need not be searched again, and (in contrast to phase 3) that the pingers were probably just not working.
http://wwz.ifremer.fr/lpo/layout/set...A9mentaire.pdf
Guest
Posts: n/a
OK465
Thick skin also, but the brain has some catching up to do. I know the pilots of A330 here are top notch, and most of this is well above my head, but I get the definite feeling that if not completely conversant with the Law, a guy could get real behind, real quick, and perhaps not even be aware of how far behind until the thinker goes to overwhelm. I'm sure it's just me, and my archaic skills.
I am so waiting to hear from the pros here when the data hits the fan instead of the s. Perhaps at that point we can truly appreciate their (your) presence here. TurbineD, PJ2, Hazelnuts39, takata, Chris Scott, gums, Machinbird, Smilin Ed, Tubby Linton, mm43, y'all know who yar.
Thick skin also, but the brain has some catching up to do. I know the pilots of A330 here are top notch, and most of this is well above my head, but I get the definite feeling that if not completely conversant with the Law, a guy could get real behind, real quick, and perhaps not even be aware of how far behind until the thinker goes to overwhelm. I'm sure it's just me, and my archaic skills.
I am so waiting to hear from the pros here when the data hits the fan instead of the s. Perhaps at that point we can truly appreciate their (your) presence here. TurbineD, PJ2, Hazelnuts39, takata, Chris Scott, gums, Machinbird, Smilin Ed, Tubby Linton, mm43, y'all know who yar.
Join Date: Aug 2007
Location: London, New York, Paris, Moscow.
Posts: 3,632
Likes: 0
Received 0 Likes
on
0 Posts
a guy could get real behind, real quick, and perhaps not even be aware of how far behind until the thinker goes to overwhelm. I'm sure it's just me, and my archaic skills.
My Wild Speculation
Basically everything working well: the radar and crew spot a wet cb and avoid it, perhaps even begin to think they have gotten through the ITCZ.
The radar and crew do not see a humongous dry/ice crystal updraft and fly into it. The temperature is so much warmer than standard that the a/c stalls somewhere in the updraft. Pitots may or may not be clogging while this is happening.
I am waiting for the BEA to learn how this or a different situation was handled by the crew.
Once both engines stall because because of high alpha, pulling one back to idle will not induce a roll.
The radar and crew do not see a humongous dry/ice crystal updraft and fly into it. The temperature is so much warmer than standard that the a/c stalls somewhere in the updraft. Pitots may or may not be clogging while this is happening.
I am waiting for the BEA to learn how this or a different situation was handled by the crew.
Once both engines stall because because of high alpha, pulling one back to idle will not induce a roll.
Join Date: Jun 2010
Location: USA
Posts: 245
Likes: 0
Received 0 Likes
on
0 Posts
Didn't work too well in QF72's case, where one dud ADIRU brought the whole show to it's knees and completely out of the control of the pilots for some time..
AFAIK this is untrue. The last report I have seen they have not be able to duplicate the anomalies. They do not know if the ADIRU was a dud, if there was some outside interference, or what.
how could the capt. enter through the secured cockpit door unless the situation took minutes to unfold.
Originally Posted by Mountainbear
Didn't work too well in QF72's case, where one dud ADIRU brought the whole show to it's knees and completely out of the control of the pilots for some time..
Last edited by Capn Bloggs; 23rd May 2011 at 02:17.
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Likes: 0
Received 0 Likes
on
0 Posts
Lightning
Hi,
EDLB
For components test, not an entire a/c. Do you have example(s)?
I prefer destroy It during testing than in real operation. And you can increase the pulses adaptively observing the test results. I suspect the a/c manufacturers just check compliance to rules, etc. I don´t like this.
donaldt
Impressive information; In one mission of STS they studied the phenomena with impressive findings. Very long bolts, etc. Frightening.
Some interesting info. on lightning in a/c:
triple whyskey dot niar.wichita.edu/agate/Documents/Lightning/WP3.1-031027-043.pdf
Posting just to close the issue unless something related is reported by BEA.
EDLB
Sure they are
but might be a bit destructive on the airframe
donaldt
Impressive information; In one mission of STS they studied the phenomena with impressive findings. Very long bolts, etc. Frightening.
Some interesting info. on lightning in a/c:
triple whyskey dot niar.wichita.edu/agate/Documents/Lightning/WP3.1-031027-043.pdf
Posting just to close the issue unless something related is reported by BEA.
Join Date: Jun 2010
Location: USA
Posts: 245
Likes: 0
Received 0 Likes
on
0 Posts
It is true. Read the reports. Why ADIRU 1 put out spurious signals is irrelevant: the system didn't isolate it and the pilots could not control the aeroplane... twice.
As for whether the ADIRU was a dud the 2nd Interm report clearly states it was not.
As outlined in the first Interim Factual Report, the ADIRU (serial number 4167) and an exemplar unit were subjected to a range of tests and examinations, and no faults were found that provided any information relevant to furthering the understanding of the accident.
http://www.atsb.gov.au/media/1363394...8070_ifr_2.pdf
Join Date: Jun 2009
Location: In one of the two main circles
Age: 65
Posts: 116
Likes: 0
Received 0 Likes
on
0 Posts
NWR
Thanks for posting the link to the Ifremer report.
Quite technical but pretty interesting.
That's another evidence to which length the BEA was ready to go to find the wreckage (sorry for our beloved conspiracy theorists who are sure that the BEA / AF /AI do not want the wreckage to be found
).
Quite technical but pretty interesting.
That's another evidence to which length the BEA was ready to go to find the wreckage (sorry for our beloved conspiracy theorists who are sure that the BEA / AF /AI do not want the wreckage to be found
).
bearfoil
Presume you are referring to the DC10 at Chicago.
If my grey cells are still functioning correctly...
The DC 10 had no protection on the slats for hydraulic failure.
When the engine disappeared over the wing it took out the hydraulic lines which allowed the slats to retract.
The crew had no knowledge of this and rotated the aircraft to obtain V2+10 which was below the stall speed of the wing on the side where the slats had blown back into the retracted position.
Not very dissimilar to the Trident captain who didn't notice that the droop had been retracted and after stick push recovery went back to try and fly V2+10.
Another question. In the 80s there was talk of fitting A of A indicators to civil aircraft - did it ever happen?
Presume you are referring to the DC10 at Chicago.
If my grey cells are still functioning correctly...
The DC 10 had no protection on the slats for hydraulic failure.
When the engine disappeared over the wing it took out the hydraulic lines which allowed the slats to retract.
The crew had no knowledge of this and rotated the aircraft to obtain V2+10 which was below the stall speed of the wing on the side where the slats had blown back into the retracted position.
Not very dissimilar to the Trident captain who didn't notice that the droop had been retracted and after stick push recovery went back to try and fly V2+10.
Another question. In the 80s there was talk of fitting A of A indicators to civil aircraft - did it ever happen?
Join Date: Mar 2002
Location: Wybacrik
Posts: 1,190
Likes: 0
Received 0 Likes
on
0 Posts
Phew!...after reading a lot of rubbish on prune over many years this thread of 100 plus pages is the biggest load of nonsense I've ever read on prune... this has to take the cake!
A complete waste of space from technical nerds who haven't got a clue what the hell they are talking about!
A load of nonsense from ancient aviators who flew F14s, Vipers or other military types that have NO RELEVANCE WHATSOEVER to this prang!
Chris Scott, an A320 driver, is one of very few current pilots on this thread who knows what caused this prang... as most current professional pilots do!
Wannabe pilots who never made the grade, and want to tell pro's who did cut the mustard how to do it, should listen to what Chris and his fellow professional airline pilots have to say!
A complete waste of space from technical nerds who haven't got a clue what the hell they are talking about!
A load of nonsense from ancient aviators who flew F14s, Vipers or other military types that have NO RELEVANCE WHATSOEVER to this prang!
Chris Scott, an A320 driver, is one of very few current pilots on this thread who knows what caused this prang... as most current professional pilots do!
Wannabe pilots who never made the grade, and want to tell pro's who did cut the mustard how to do it, should listen to what Chris and his fellow professional airline pilots have to say!
Join Date: Jun 2009
Location: Earth
Posts: 79
Likes: 0
Received 0 Likes
on
0 Posts
Wiring fault
RR-NDB wrote and quoted one of my posts :
Svarin,
What kind of cause can create such wiring fault.
The importance to me is not related to what this "wiring fault" could make to a redundant architecture.
I would like to understand what can create a "wiring fault". Other than a Kapton issue.
RR-NDB, there are two very different considerations related to this wiring fault. The first is why did it happen ? Your question. The second is what are its consequences ? My question.
As to your question, lightning was suggested quite early after the accident in June 2009 by Mr Feldzer. I do not believe it. Coincidence is too great. However, a software versioning compatibility issue would perhaps fit the bill.
As to my question, takata, in an uncharacteristically broadly sweeping answer, made a reference to BUS 2 and BUS 1. Takata, would you care to enlighten us on this BUS structure, please ? Just how many BUSes are there on them 'Buses ? And more importantly, how do they connect all relevant computers (ADRs, FCPCs) together ?
Takata, PJ2, Lemurian, mm43, and other knowledgeable individuals, please tell us, could multiple FCPCs retain their own personal flight law, differing with their "clones" ? What would a trio of clones become after a highly suspicious wiring fault affected only one of them ? What do you make of an airspeed probes fault appearing near simultaneously with a wiring fault ? What becomes of redundancy in this cr@ppy situation ? Why is there no "ADR 1(2)(3) FAULT" message in the sequence ? Why is there a PRIM1 FAULT and no PRIM2 FAULT ?
Best regards
PS : to all who take the time to read my modest posts, thank you for your patience. Please understand that my attitude here is about working with available first-hand evidence only. And so far, ACARS sequence is one very good source for such. Primarily, a maintenance sytem will not tell about crew deficiencies, only aircraft deficiencies. Thus, the reason why I appear strictly one-sided at this time.
Svarin,
02:11:55 EFCS1 X2,EFCS2X,,,,,,,FCPC2 (2CE2) / WRG:ADIRU1 BUS ADR1-2 TO FCPC2, HARD
This is definitely a wiring fault, where FCPC2 and ADR1 lose their connection.
This is definitely a wiring fault, where FCPC2 and ADR1 lose their connection.
The importance to me is not related to what this "wiring fault" could make to a redundant architecture.
I would like to understand what can create a "wiring fault". Other than a Kapton issue.
As to your question, lightning was suggested quite early after the accident in June 2009 by Mr Feldzer. I do not believe it. Coincidence is too great. However, a software versioning compatibility issue would perhaps fit the bill.
As to my question, takata, in an uncharacteristically broadly sweeping answer, made a reference to BUS 2 and BUS 1. Takata, would you care to enlighten us on this BUS structure, please ? Just how many BUSes are there on them 'Buses ? And more importantly, how do they connect all relevant computers (ADRs, FCPCs) together ?
Takata, PJ2, Lemurian, mm43, and other knowledgeable individuals, please tell us, could multiple FCPCs retain their own personal flight law, differing with their "clones" ? What would a trio of clones become after a highly suspicious wiring fault affected only one of them ? What do you make of an airspeed probes fault appearing near simultaneously with a wiring fault ? What becomes of redundancy in this cr@ppy situation ? Why is there no "ADR 1(2)(3) FAULT" message in the sequence ? Why is there a PRIM1 FAULT and no PRIM2 FAULT ?
Best regards
PS : to all who take the time to read my modest posts, thank you for your patience. Please understand that my attitude here is about working with available first-hand evidence only. And so far, ACARS sequence is one very good source for such. Primarily, a maintenance sytem will not tell about crew deficiencies, only aircraft deficiencies. Thus, the reason why I appear strictly one-sided at this time.
Join Date: Jun 2009
Location: I am where I am and that's all where I am.
Posts: 660
Likes: 0
Received 0 Likes
on
0 Posts
Mr Optimistic, I'd not be at all surprised if the BEA and other organizations have at their disposal a tool that "plays back" the FDR recordings into a video animation of the plane and the cockpit.
If they don't somebody should write such a tool.
If they don't somebody should write such a tool.
Join Date: Mar 2010
Location: Sweden
Age: 87
Posts: 67
Likes: 0
Received 0 Likes
on
0 Posts
QF72 interrim report 2
Cited from the report:
"As outlined in the first Interim Factual Report, two significant safety factors have been identified with the aircraft’s systems:
• an air data inertial reference unit (ADIRU) provided erroneous data that was not detected by the ADIRU itself
• the flight control computers did not filter spikes in angle of attack data in a specific situation.
The investigation is examining the context and origin of both of these factors."
It looks to me that the ADIRU is still suspect although the problem remains undetected..
However, more interesting, and perhaps relevant to AH447, is the fact that a program update brought an earlier unidentified bug into operation. There is a remote possibility that the software running on the computers on AF447 was a unique combinations of updated and un-updated programs leading to a unique system behaviour in comparison with other flights having speed-measurement problems.
"As outlined in the first Interim Factual Report, two significant safety factors have been identified with the aircraft’s systems:
• an air data inertial reference unit (ADIRU) provided erroneous data that was not detected by the ADIRU itself
• the flight control computers did not filter spikes in angle of attack data in a specific situation.
The investigation is examining the context and origin of both of these factors."
It looks to me that the ADIRU is still suspect although the problem remains undetected..
However, more interesting, and perhaps relevant to AH447, is the fact that a program update brought an earlier unidentified bug into operation. There is a remote possibility that the software running on the computers on AF447 was a unique combinations of updated and un-updated programs leading to a unique system behaviour in comparison with other flights having speed-measurement problems.
Join Date: Jun 2009
Location: I am where I am and that's all where I am.
Posts: 660
Likes: 0
Received 0 Likes
on
0 Posts
Safety Concerns, your post brought me back to one of my hobbyhorses, the plane being out of communications.
Suppose the storm looked too large for them to go around without contacting DAKAR. That could lead to their trying to thread a hopeless needle and eventually going down.
Revealing such an assumption most likely will lead to an international incident. So it needs to be nailed down tighter than a drum before they release it in particularly delicate language.
This could be getting quite interesting to watch. DAKAR would no doubt point to Brazil's failing. Yet, DAKAR had the final responsibility here.
(I believe planes have dual HF radios. One should have been on Brazil with SelCal on. The other should have been on DAKAR with SelCal on after an alert to DAKAR they were coming but not in DAKAR's region of concern, yet. I tend to believe in "communicate early and often.")
Suppose the storm looked too large for them to go around without contacting DAKAR. That could lead to their trying to thread a hopeless needle and eventually going down.
Revealing such an assumption most likely will lead to an international incident. So it needs to be nailed down tighter than a drum before they release it in particularly delicate language.
This could be getting quite interesting to watch. DAKAR would no doubt point to Brazil's failing. Yet, DAKAR had the final responsibility here.
(I believe planes have dual HF radios. One should have been on Brazil with SelCal on. The other should have been on DAKAR with SelCal on after an alert to DAKAR they were coming but not in DAKAR's region of concern, yet. I tend to believe in "communicate early and often.")
Moderator
Ref this post my limited knowledge of cutting code suggested that the sentiments were a bit optimistic. A specialist colleague provided the following commentary as an observation and invited me to post it for information.
"The contributor who goes by the name of syseng68k has a rosy, and, I fear, misleading idea of the quality of software and software development. It is not error-free, even in critical systems. There is probably no substantial system (of the order of tens of thousands of lines of code or larger, the size of all flight control systems in commercial aircraft nowadays) which has ever been built that was or is error-free. For the state of the art, see the last paragraph.
I have worked in the reliability and safety of software-based systems for a quarter century, am a member of my country's standardisation committe on functional safety of computer-based systems, have an international reputation in the field, and indeed shall be giving a keynote talk at a major international conference on the subject later in the year.
A famous study by Robin Lutz of Iowa State University twenty years ago on the source of about 200 mission-critical software failures for NASA showed that over 98% were due to the requirements not covering adequately the actual situation the system encountered. (syseng68k prefers not to call these "bugs" but most people working in ultrareliable software do.) A more recent study by Lutz and Mikulski from 2004, published in one of the premier journals for software engineering, may be found at http://www.cs.iastate.edu/%7Erlutz/publications/tse04.pdf
There is an enormous variety of problems with computer-based systems in aerospace contexts, the number of incidents is clearly increasing, and I fear will continue to do so. A check of Peter Neumann's "illustrative risks" Section 1.6, Commercial Aviation, gives some sense:
http://www.csl.sri.com/users/neumann/illustrative.html#9 The Risks Digest archive is also available on-line at http://catless.ncl.ac.uk/risks
Kevin Driscoll of Honeywell, along with Brendan Hall, Hakan Sivencrona (of Chalmers Institute of Technology) and Phil Zumsteg, published a paper recounting a so-called "Byzantine anomaly" with the FBW control system of a major airliner, that almost caused the airworthiness certificate to be withdrawn:
http://www.cs.indiana.edu/classes/b649-sjoh/reading/Driscoll-Hall-Sivencrona-Xumsteg-03.pdf
Driscoll gave a recent keynote talk at SAFECOMP 2010, "Murphy was an Optimist" on such kinds of failures, which are ongoing.
Estimates by colleagues who know put the general coding error rate in safety-critical software at about one error per 1,000 LOC (lines of executable source code). Obviously, this is a very general statement. How often behavioral anomalies are triggered by coding errors depends of course on the operational profile of the software. For example, the bug in the configuration control software on the Boeing 777 aircraft was present throughout the lifetime of the aircraft but only manifested after a decade of line service http://www.atsb.gov.au/publications/investigation_reports/2005/aair/aair200503722.aspx and recent anomalies, also triggered by issues with ADIRUs affecting the primary flight control, in Airbus A330 took a similar length of time to manifest : http://www.atsb.gov.au/media/1363394/ao2008070_ifr_2.pdf
There are some companies, such as Altran Praxis (formerly Praxis High Integrity Systems), who have instrumented their error rates and demonstrably achieve much lower rates, of the order of one error per 25,000 LOC. Altran Praxis have recently engaged on the Tokeneer project funded by the NSA, whose object was to develop error-free software http://www.adacore.com/home/products/sparkpro/tokeneer/
Despite apparent initial success, five errors were eventually found:
http://www-users.cs.york.ac.uk/~jim/woodcock-hoare-75th-final.pdf (note, this is a paper for a celebration of the 75th birthday of a UK pioneer in reliable software technology, Turing Award winner Sir Tony Hoare, co-inventor 40 years ago of the original method for mathematically proving that sequential programs do what they are supposed to do).
Summary: Five errors is as good as it gets in software with many tens of thousands of LOC. This is the order of the first civil aircraft flight control systems a quarter-century ago (Airbus A320, 1988, about 60,000 LOC). However, since then the size of the systems has increased by two orders of magnitude, and of course they are also very highly distributed, which brings many subtle additional sources of potential error into play (e.g., Byzantine failures)."
"The contributor who goes by the name of syseng68k has a rosy, and, I fear, misleading idea of the quality of software and software development. It is not error-free, even in critical systems. There is probably no substantial system (of the order of tens of thousands of lines of code or larger, the size of all flight control systems in commercial aircraft nowadays) which has ever been built that was or is error-free. For the state of the art, see the last paragraph.
I have worked in the reliability and safety of software-based systems for a quarter century, am a member of my country's standardisation committe on functional safety of computer-based systems, have an international reputation in the field, and indeed shall be giving a keynote talk at a major international conference on the subject later in the year.
A famous study by Robin Lutz of Iowa State University twenty years ago on the source of about 200 mission-critical software failures for NASA showed that over 98% were due to the requirements not covering adequately the actual situation the system encountered. (syseng68k prefers not to call these "bugs" but most people working in ultrareliable software do.) A more recent study by Lutz and Mikulski from 2004, published in one of the premier journals for software engineering, may be found at http://www.cs.iastate.edu/%7Erlutz/publications/tse04.pdf
There is an enormous variety of problems with computer-based systems in aerospace contexts, the number of incidents is clearly increasing, and I fear will continue to do so. A check of Peter Neumann's "illustrative risks" Section 1.6, Commercial Aviation, gives some sense:
http://www.csl.sri.com/users/neumann/illustrative.html#9 The Risks Digest archive is also available on-line at http://catless.ncl.ac.uk/risks
Kevin Driscoll of Honeywell, along with Brendan Hall, Hakan Sivencrona (of Chalmers Institute of Technology) and Phil Zumsteg, published a paper recounting a so-called "Byzantine anomaly" with the FBW control system of a major airliner, that almost caused the airworthiness certificate to be withdrawn:
http://www.cs.indiana.edu/classes/b649-sjoh/reading/Driscoll-Hall-Sivencrona-Xumsteg-03.pdf
Driscoll gave a recent keynote talk at SAFECOMP 2010, "Murphy was an Optimist" on such kinds of failures, which are ongoing.
Estimates by colleagues who know put the general coding error rate in safety-critical software at about one error per 1,000 LOC (lines of executable source code). Obviously, this is a very general statement. How often behavioral anomalies are triggered by coding errors depends of course on the operational profile of the software. For example, the bug in the configuration control software on the Boeing 777 aircraft was present throughout the lifetime of the aircraft but only manifested after a decade of line service http://www.atsb.gov.au/publications/investigation_reports/2005/aair/aair200503722.aspx and recent anomalies, also triggered by issues with ADIRUs affecting the primary flight control, in Airbus A330 took a similar length of time to manifest : http://www.atsb.gov.au/media/1363394/ao2008070_ifr_2.pdf
There are some companies, such as Altran Praxis (formerly Praxis High Integrity Systems), who have instrumented their error rates and demonstrably achieve much lower rates, of the order of one error per 25,000 LOC. Altran Praxis have recently engaged on the Tokeneer project funded by the NSA, whose object was to develop error-free software http://www.adacore.com/home/products/sparkpro/tokeneer/
Despite apparent initial success, five errors were eventually found:
http://www-users.cs.york.ac.uk/~jim/woodcock-hoare-75th-final.pdf (note, this is a paper for a celebration of the 75th birthday of a UK pioneer in reliable software technology, Turing Award winner Sir Tony Hoare, co-inventor 40 years ago of the original method for mathematically proving that sequential programs do what they are supposed to do).
Summary: Five errors is as good as it gets in software with many tens of thousands of LOC. This is the order of the first civil aircraft flight control systems a quarter-century ago (Airbus A320, 1988, about 60,000 LOC). However, since then the size of the systems has increased by two orders of magnitude, and of course they are also very highly distributed, which brings many subtle additional sources of potential error into play (e.g., Byzantine failures)."
Join Date: Jun 2009
Location: somewhere
Posts: 451
Likes: 0
Received 0 Likes
on
0 Posts
"Wiring Fault" ?
Svarin:
From BEA Interim ACARS report:
ATA: 279334
Source: *EFCS1
Identifiers: *EFCS2
Class 2, HARD
This message indicates that FCPC 2 no longer considers as valid the information that is
delivered to it by ADR 1 (via bus 2). The ATA code beginning with 27 indicates that the fault was not detected by any other FCPC during the three seconds that followed (otherwise this message would have been classified ATA 34). This message has not been fully explained at this stage of the investigation.
In my knowledge the slash "/" is used when an ambiguous fault occurs.
Up to 3 possible failures may be indicated with the most probable possibility on the left. (FCPC 2 FIN 2CE2)
A "+" sign is used when there are multiple faulty components involved.
No!, only 1 FCPC or FCSC is in control, this will be the FCPC(FCSC) which has the highest level of law (The Master), Normal order FCPC 1,2,3 FCSC 1,2.
The Master transmits it's deflection orders to the other computers, which executes these to their own sets of servo's.
A FCPC is able to engage Normal law(all protections), Alternate Law(reduced protections) and Direct law(No protections), FCSC can only compute Yaw alternate law and Direct Law.
After Loss of normal laws the reconfiguration of control laws is different for the pitch axis and for the lateral axis.
02:11:55 EFCS1 X2,EFCS2X,,,,,,,FCPC2 (2CE2) / WRG:ADIRU1 BUS ADR1-2 TO FCPC2, HARD
ATA: 279334
Source: *EFCS1
Identifiers: *EFCS2
Class 2, HARD
This message indicates that FCPC 2 no longer considers as valid the information that is
delivered to it by ADR 1 (via bus 2). The ATA code beginning with 27 indicates that the fault was not detected by any other FCPC during the three seconds that followed (otherwise this message would have been classified ATA 34). This message has not been fully explained at this stage of the investigation.
In my knowledge the slash "/" is used when an ambiguous fault occurs.
Up to 3 possible failures may be indicated with the most probable possibility on the left. (FCPC 2 FIN 2CE2)
A "+" sign is used when there are multiple faulty components involved.
could multiple FCPCs retain their own personal flight law, differing with their "clones"
The Master transmits it's deflection orders to the other computers, which executes these to their own sets of servo's.
A FCPC is able to engage Normal law(all protections), Alternate Law(reduced protections) and Direct law(No protections), FCSC can only compute Yaw alternate law and Direct Law.
After Loss of normal laws the reconfiguration of control laws is different for the pitch axis and for the lateral axis.
Last edited by A33Zab; 23rd May 2011 at 11:41.