Announcement

Collapse
No announcement yet.

What is it doing now?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • What is it doing now?

    Evan dismissed this accident too quickly in the other thread.

    As he said, it is quite complex and I am still struggling to understand the facts.

    But in summary, it seems that due to a number of issues and conflicting information FOUR FLIGHT CONTROL COMPUTERS gave up on the elevator, leaving it frozen at zero, not providing even direct law control for which as far as I know said computers don't need any information or input other than the sidestick input, which was not compromised.

    And, as a side note, here we have an Airbus pilot facing a very confusing situation and improvising a procedure where there was none (for loss of pitch control in take-off or landing) and resorting to manually turn the trim wheel to have some degree of pitch control, in an airplane where you NEVER make trim inputs (neither with switches or manual mechanisms) except in the sim or in a very bad day.
    At the same time, the same pilot did NOT improvise and strictly followed the procedure to reset the ELAC to fix the ELAC PITCH FAULT message that was triggered.... 4 times. Maybe some more improvising and saying "ok, 2 is enough, let's land this thing now" would have been in order.

    http://avherald.com/h?article=4b57c3dd/0000&opt=4096

    --- Judge what is said by the merits of what is said, not by the credentials of who said it. ---
    --- Defend what you say with arguments, not by imposing your credentials ---

  • #2
    Well clearly the answer is that they need FIVE flight control computers! https://www.youtube.com/watch?v=xJxwvZ5SE_c
    Be alert! America needs more lerts.

    Eric Law

    Comment


    • #3
      Originally posted by Gabriel View Post
      Evan dismissed this accident too quickly in the other thread.

      As he said, it is quite complex and I am still struggling to understand the facts.

      But in summary, it seems that due to a number of issues and conflicting information FOUR FLIGHT CONTROL COMPUTERS gave up on the elevator, leaving it frozen at zero, not providing even direct law control for which as far as I know said computers don't need any information or input other than the sidestick input, which was not compromised.

      And, as a side note, here we have an Airbus pilot facing a very confusing situation and improvising a procedure where there was none (for loss of pitch control in take-off or landing) and resorting to manually turn the trim wheel to have some degree of pitch control, in an airplane where you NEVER make trim inputs (neither with switches or manual mechanisms) except in the sim or in a very bad day.
      At the same time, the same pilot did NOT improvise and strictly followed the procedure to reset the ELAC to fix the ELAC PITCH FAULT message that was triggered.... 4 times. Maybe some more improvising and saying "ok, 2 is enough, let's land this thing now" would have been in order.

      http://avherald.com/h?article=4b57c3dd/0000&opt=4096
      The manuals have apparently been updated to point out the very obvious limit on resetting FCC's, and hopefully pointing out that the procedure is NOT intended to keep the a/c in service indefinitely. Also, the incident would not have happened if the ground maintenance hadn't used whatever random bunker oil they had lying about on a precision component of a passenger airliner. I doubt there will ever be an aircraft that can stand up to improvisation like that. So, fouled component, multiple fair warnings ignored and an ELAC left faulted between cycles, this is one rotten stack of swiss cheese that hopefully future crew will smell before it ever goes this far.

      I have to dig up the MMEL and see what the conditions are for single ELAC dispatch.

      Comment


      • #4
        Originally posted by Evan View Post
        I have to dig up the MMEL and see what the conditions are for single ELAC dispatch.
        Well, to begin with, there is this requirement:

        Elevators and roll spoilers control through the SECs is verified operative before each flight.
        Kinda doubt that was done...

        Comment


        • #5
          Originally posted by Evan View Post
          Well, to begin with, there is this requirement:



          Kinda doubt that was done...
          Why? I mean, I don't know if it was done, but apparently the SECs were controlling the elevators correctly when the ELACs stopped doing so... until the point where the SECs also stopped doing so.

          What I don't understand (or rather the most important thing I don;t understand, because there is a lot I don't understand in this accident) is why the elevator wasn't available even in direct mode, where the trim is manual anyway. Having an issue with the HTS and confusion about whether the plane is on the ground or in the air doesn't seem like enough to make direct law elevator impossible.

          --- Judge what is said by the merits of what is said, not by the credentials of who said it. ---
          --- Defend what you say with arguments, not by imposing your credentials ---

          Comment


          • #6
            Originally posted by Gabriel View Post
            Why? I mean, I don't know if it was done...
            Obviously, MEL was not considered between these touch-and-go flights. Nor was there any instruction to do so:

            Originally posted by Final Report
            There is no reference in the Airbus FCTP or FCTM (in the versions published before the event) to consider MEL for training continuation on “touch and go” or “stop and go” training.
            Originally posted by Gabriel
            ...apparently the SECs were controlling the elevators correctly when the ELACs stopped doing so... until the point where the SECs also stopped doing so. What I don't understand (or rather the most important thing I don;t understand, because there is a lot I don't understand in this accident) is why the elevator wasn't available even in direct mode, where the trim is manual anyway. Having an issue with the HTS and confusion about whether the plane is on the ground or in the air doesn't seem like enough to make direct law elevator impossible.
            Warning: This is a VERY complex scenario and will be Gabriellian in length. It may contain acronyms.

            As simple as I can state it: ELAC 1, which normally takes over on the ground, was not reset from a fault on a previous cycle, thus ELAC 2, (which is normally in control in the air) remained in control on the ground. When the pilot manually stopped the trim wheel, with the OVM unit malfunctioning (explanation to come), the system detected a discrepancy between the computer-commanded position of the THS (COM) and the actual position (MON) and faulted ELAC 2. At this point SEC2 took over pitch control. However, due to a VERY complex relationship between the SEC trim runaway detection logic and the LGCIU's, which are receiving data from the compression sensors on the MLG, and the bounced landing due to the failure to arm ground-spoilers (as directed in the Airbus FTCM but not in the Smartlynx procedure), one SEC lane was operating in ground mode and one was in air mode and the disagree caused both SECs to fault as well (both receive the same LGCIU data, so both experienced the same fault). This resulted in a MASTER WARNING and F/CTL L+R ELEV FAULT on ECAM, yet the crew, now well above V1, decided to continue. (I'm not sure that was the right decision, but that assumes they had situational awareness. CAS was 170 kt, and the aircraft was 1600 m from the end of the runway).

            This one requires a deep dive into systems, one that few pilots will ever make. The problem initiated with the corruption of the OVM (THS override mechanism that enables the pilot to manually override the ELAC and SEC signal to the THS) by improvised and improper maintenance. The OVM is critical here because, upon touching down during touch-and-go's, the instructor pilot was manually stopping the trim wheel in order to prevent ELAC 1 from automatically resetting the THS in ground mode to 0 deg. When the pilot does this, the OVM normally operates micro-switches (The mechanical linkage forces the OVM piston to act on the micro-switches located at the OVM) to ensure that the FCC's (ELACS and SEC's) remain synchonized to the manually-selected position. Unless the microswitches are triggered by the OVM, the F/CTL computers will continue to monitor both the commanded and actual postion of the THS, and, if there is a threshold discrepancy, trigger ELAC and SEC faults. In this case, due to a fouled OVM unit, the F/CTL failed to detect the manual imputs, continued to think it was driving the THS and then detected the discrepancy of the actual (manually commanded) position, and thus the ELAC(s) were faulted each time thie trim wheel was manually arrested.

            Originally posted by Final Report
            If the OVM does not work properly and for instance does not trigger the microswitches (or the microswitches do not trigger the signal) when the pilot is taking over the Trim Wheel (while the F/CTL computer in command is active on the THS), no signal is sent to the F/CTL computer and therefore the electrical motors keep driving the THS without any effect as they are mechanically disconnected. However, the F/CTL will keep monitoring the THS position and as the pilot is ordering some inputs on the Trim wheel, the actual THS position is no longer consistent with the THS position commanded by the F/CTL computer. When this discrepancy exceeds a certain threshold F/CTL computers will detect a movement of the THS MON transducer that is not consistent with the electrical command (COM transducer position), the THS servo-loop monitoring is triggered resulting in the loss of electrical control of the THS by the F/CTL computer in command and the triggering of ECAM alerts and associated failure messages:
            - If an ELAC is in control, the ECAM message “F/CTL ELAC 1(2) PITCH FAULT” will be displayed (THS ACTR POS ERROR 9CE of ELAC 1 (2) if ELAC is in command)
            - If a SEC is in control, the ECAM message “F/CTL STABILIZER JAM” will be finally displayed when both SECs will have lost the THS control.
            So, as you can see, it is important that the OVM is working properly if you are intending to manually intervene on the trim wheel. This may be seen as a design flaw, since it is a single point of failure without redundancy, but it is a condition that requires both a highly unusual use of the trim wheel (for touch and go's) AND a rather unforgivable dose of stoogery during maintenance:

            During certification, this single-failure condition wasn't considered a threat because:

            Originally posted by Final Report
            Permanent electrical mode signal from 3 micro switches“ is considered to have no effect as a single failure as it requires a human action on the trim wheel to have an effect on the systems. Airbus specified that in normal operations such a human action is never requested by any procedure when the auto-trim is active, however the Airbus FCTM described pilot action "monitor/adjust the trim movement towards the green band" during touch and go.
            During the investigation, it was checked that even considering this human action, the probability of the failure condition “Loss of control of both elevators, both locked neutral” still meets the safety objective.
            The lack of friction, in this case due to a low viscosity oil (as revealed by the oil analysis) was not taken into account in the certification process. There is no maintenance task that is required by Airbus to detect this type of OVM failure as this failure is combined with additional failures leading to having effect on the system. FC diagram only considers failures or events and does not consider human actions and thus this failure needs an additional and independent failure (like for instance jamming of the mechanical linkage between the Trim Wheel and the THSA) in order to loss the pitch control by both ELAC’s through an OVM failure.
            The improper lubricant altered the OVM friction curve, resulting in the actuator pistons not engaging the microswitches:

            Originally posted by Final Report
            Therefore, the oil that was used in the gearbox was non-compliant to the CMM and can in itself explain the change in the friction curve and the intermittent misbehaviour of the OVM that led to the ELAC PITCH FAULT conditions during the event.
            In addition to the lubrication error, the unit teardown revealed the following:

            Originally posted by Final Report
            Disassembly revealed that there were several issues referring to the opening of the THSA gearbox - wire locking of different components was not compliant with the CMM, tab-washers were re-used, the shimming of the OVM had not been done accordingly to CMM.
            The ECAM fault messages are inhibited below 1500ft, so on each climb out after the initial touch and go, the crew received warnings upon exceeding this altitude of ELAC PITCH FAULT and reset the ELAC's using the procedure. In the first instance, both ELAC's were in pitch fault and thus the law temporarily reverted to Alternate. IMHO, this should have terminated the exercise until maintenance could determine the cause.

            However, importantly, during one of the subsequent cycles at 13:47, F/CTL ELAC 1 PITCH FAULT was triggered and was never reset. ELAC 1 is normally in command during ground mode. For the remainder of the flights, only ELAC 2 was available. When an ELAC 2 fault was triggered by the manual pitch trim upon the final touchdown before the event, SEC2 briefly took over. Subsequently:

            Originally posted by Final Report
            The associated TSD indicated that before the failure (i.e. F/CTL L+R ELEV FAULT), SEC2 was active on both elevators and THS and both elevators were available in SEC1. Nevertheless, after the failure, SEC1 and SEC2 were no longer engaged on both sides’ elevators.
            Therefore, before the event, the F/CTL system nominally reconfigured several times for elevator control:
            • on ELAC2 when ELAC1 was faulty,
            • on SEC2 when ELAC1 and ELAC2 were faulty (similarly like at 14:55),
            but during the event, although the reconfiguration to back-up computers (SEC1 and SEC2) took place, both computers were unable to control Left and Right elevator and THS.
            As for design shortcomings:

            Originally posted by Final Report
            The discrepancy of the SEC`s COM and MON lanes can be determined as the root cause for the loss of elevator control by both SECs. This system behaviour, which cannot be seen as a failure, as it is part of the SEC design (hence not covered by SSA), should be considered as a weakness of the design that was revealed during this accident.
            As for operator issues:
            • There was careless, nonstandard, improvised maintenance involved. This created the failure condition.
            • There were multiple, serial failures of ELAC pitch control (5 resets to ELAC1 and 4 resets to ELAC2) that were not taken seriously enough due to a weakened safety culture, including the failure of both ELAC's and the loss of normal law.
            • The crew neglected to reset ELAC 1 at a fateful point in the sequence of events.
            • The operator procedure for touch-and-go's omitted the need to arm ground spoilers.
            • The PIC commanded gear retraction before positive climb.
            • There was no consideration of MEL between flight cycles.


            Ultimately, this is your classic swiss-cheese scenario, where multiple failures and errors and instances of neglect had to align in just the right way.

            Comment


            • #7
              Originally posted by Gabriel
              ...apparently the SECs were controlling the elevators correctly when the ELACs stopped doing so... until the point where the SECs also stopped doing so. What I don't understand (or rather the most important thing I don;t understand, because there is a lot I don't understand in this accident) is why the elevator wasn't available even in direct mode, where the trim is manual anyway. Having an issue with the HTS and confusion about whether the plane is on the ground or in the air doesn't seem like enough to make direct law elevator impossible.
              A shorter answer is that, in the FBW loop, in any control law, it must be able to verify that the commanded position results in the expected position. The chain-of-events described above resulted in the COM and MON lanes of the SEC's diverging beyond a safe threshold, signaling an apparent fault and causing the system to lock the elevators at neutral and hand over pitch to the mechanical backup (THS).

              Comment


              • #8
                Originally posted by Evan View Post
                A shorter answer is that, in the FBW loop, in any control law, it must be able to verify that the commanded position results in the expected position. The chain-of-events described above resulted in the COM and MON lanes of the SEC's diverging beyond a safe threshold, signaling an apparent fault and causing the system to lock the elevators at neutral and hand over pitch to the mechanical backup (THS).
                Not satisfactory. If I am understanding correctly (and I very well may not), the discrepancy was in the THS and not in the elevator. The elevator was working perfectly ok all the time until it did not work at all.

                Who cares if the aircraft is in the ground or air to control the elevator in direct law? Even further, if the law had degraded to direct the THS would have been in manual anyway and you would not have the ELACs commanding any THS motion and hence would not have had the disagreement between COM and MON.
                But the most important part is that you had 4 computers receiving correct inputs from the side stick and feedback from the elevator encoder but due to a discrepancy somewhere else "decide" to shut down entirely (oh, but they did command elevator to neutral even when all 4 of them were receiving correct and agreeing sidestick inputs and elevator encoder feedback).

                Again, leaving the elevator without authority should be a last resource that is done if there is no other alternative or the alternative is even more dangerous (like risk of having uncommanded elevator inputs). Regardless of how the Airbus design was executed, it seems that this was not a requirement or input into the design to begin with.

                And finally, here you have a case where more redundancy (or should I say apparent redundancy) is worse than less redundancy. Similar to a plane that has 2 engines but cannot sustain flight or cannot be controlled with 1 engine out. The additional engine is not a real redundancy but a liability. You've just doubled the chances of an accident due to an engine failure buy doubling the number of engines. In this case, a single SEC would not have detected a discrepancy between whether the plane was on the ground or on the air. It might have been wrong, but it would have kept elevator control in any case. By having 2 SECs now they disagree and both go offline (even when one was right and the other one, even being wrong, could have provided elevator control), thus leaving no elevator control.

                It feels to me that Airbus computers give up too easily.

                --- Judge what is said by the merits of what is said, not by the credentials of who said it. ---
                --- Defend what you say with arguments, not by imposing your credentials ---

                Comment


                • #9
                  Originally posted by Gabriel View Post
                  Not satisfactory. If I am understanding correctly (and I very well may not), the discrepancy was in the THS and not in the elevator. The elevator was working perfectly ok all the time until it did not work at all.

                  Who cares if the aircraft is in the ground or air to control the elevator in direct law? Even further, if the law had degraded to direct the THS would have been in manual anyway and you would not have the ELACs commanding any THS motion and hence would not have had the disagreement between COM and MON.
                  But the most important part is that you had 4 computers receiving correct inputs from the side stick and feedback from the elevator encoder but due to a discrepancy somewhere else "decide" to shut down entirely (oh, but they did command elevator to neutral even when all 4 of them were receiving correct and agreeing sidestick inputs and elevator encoder feedback).

                  Again, leaving the elevator without authority should be a last resource that is done if there is no other alternative or the alternative is even more dangerous (like risk of having uncommanded elevator inputs). Regardless of how the Airbus design was executed, it seems that this was not a requirement or input into the design to begin with.

                  And finally, here you have a case where more redundancy (or should I say apparent redundancy) is worse than less redundancy. Similar to a plane that has 2 engines but cannot sustain flight or cannot be controlled with 1 engine out. The additional engine is not a real redundancy but a liability. You've just doubled the chances of an accident due to an engine failure buy doubling the number of engines. In this case, a single SEC would not have detected a discrepancy between whether the plane was on the ground or on the air. It might have been wrong, but it would have kept elevator control in any case. By having 2 SECs now they disagree and both go offline (even when one was right and the other one, even being wrong, could have provided elevator control), thus leaving no elevator control.

                  It feels to me that Airbus computers give up too easily.
                  Does it? Do you think this waaaaaaaaay out there scenario is too easy? Do you realize that this incident required not only a component botched by maintenance but also a touch and go sequence with uneven gear contact and a manually arrested trim wheel (why would you ever do that on a revenue flight?) and a single ELAC operation? So, in terms of revenue service, we are talking about what... a MEL'd ELAC, a very late go-around with bounced runway contact on one MLG followed by manual pitch trim input and a sabotaged OVM unit. Do you really think that's giving up too easily?

                  The very cautious minds that went into designing this didn't miss much although it sometimes seems that way to avforum parlour talkers. I think they could explain their reasoning, but on the face of it, it seems that the philosophy is to remove flight control from a component that has detected a flight control fault. WIth four levels of redundancy, that's not a problem. So much went wrong here that it broke the airplane. I think, when an airline manages to defeat four levels of redundancy, you're as good as dead flying with them. I don't think it is unreasonable to have missed this as a possible scenario during certification, nor do I think it will ever happen again.

                  However, Airbus has acknowledged certain design weaknesses in the software and they are removing those weaknesses:

                  Originally posted by Final Report
                  Airbus has initiated an ELAC software modification development for monitoring the THS during the THS Ground Setting phase (i.e. From 5 s after ground condition and THS back to 0o position). The aim of the modification is to mitigate the consequences of a non-detection of a manual takeover of the THS (the failure that caused the triggering of the ELAC PITCH FAULT).

                  The certification of the ELAC software improvement with a worldwide retrofit is planned for mid-2020.

                  5. Airbus has initiated a SEC software modification development to improve SEC COM/MON consolidation logics. The aim of the modification is to improve SEC robustness against landing gear bounce around logic triggering threshold (1 s) at touchdown.
                  (keeping in mind that pitch control is very, very, very, very rarely handled by the SEC's in the first place).

                  Comment


                  • #10
                    I am not talking so much about this specific accident as the design philosophy.

                    Why would you leave the airplane without any elevator control when there is no real reason to do so?

                    And is this real quadruple redundancy? Only if you are willing to call 3 pitots triple redundancy... (and when you 1 single cause making 2 of them fail you are left with zero airspeed indications).
                    The 2 ELACs were put off line by the same cause, and the 2 SECs put each other off-line.
                    Again, all 4 computers were receiving correct, valid and agreeing values of sidestick input and elevator position feedback. That's all you need for direct law (actually you only need 2 of the 4 agreeing). So why would you provide direct law control in any scenario that you don't even need to define specifically but that has the characteristic of of having at least 2 agreeing sidestick and elevator position data regardless of whatever clusterf*ck is happening around to complete the scenario.

                    --- Judge what is said by the merits of what is said, not by the credentials of who said it. ---
                    --- Defend what you say with arguments, not by imposing your credentials ---

                    Comment


                    • #11
                      Originally posted by Gabriel View Post
                      I am not talking so much about this specific accident as the design philosophy.

                      Why would you leave the airplane without any elevator control when there is no real reason to do so?

                      And is this real quadruple redundancy? Only if you are willing to call 3 pitots triple redundancy... (and when you 1 single cause making 2 of them fail you are left with zero airspeed indications).
                      The 2 ELACs were put off line by the same cause, and the 2 SECs put each other off-line.
                      Again, all 4 computers were receiving correct, valid and agreeing values of sidestick input and elevator position feedback. That's all you need for direct law (actually you only need 2 of the 4 agreeing). So why would you provide direct law control in any scenario that you don't even need to define specifically but that has the characteristic of of having at least 2 agreeing sidestick and elevator position data regardless of whatever clusterf*ck is happening around to complete the scenario.
                      I warned you this was complicated. The SEC's 'gave up' on elevators because the aircraft experienced a L+R ELEVATOR FAULT. That results in pitch reversion to mechanical back-up (for obvious reasons). It went into this fault mode because the system assumed there had been a 'spool valve runaway':

                      SEC Spool Valve Runaway Monitoring
                      The objective of the SEC spool valve runaway monitoring is to prevent an actuator from runaway when there is a failure in the spool valve control system (current, spool valve, sensors, wiring or COM/MON order discrepancy). The SEC spool valve monitoring compares the current calculated in the MON channel to the equivalent current measured on the spool valve position sensor, computed and commanded by the COM lane [see the first attachment].
                      For SEC spool valve monitoring, a trend monitoring principle is used (rather than position monitoring), which can detect erroneous control surface movement (e.g. surface movement in the opposite direction of the given order). If a spool valve runaway signal is detected, a centering command is launched, and the control is released to the next computer.
                      Both the ELAC's and the SEC's have three servo loops in pitch: L elevator, R elevator and THS. If any of those three loops becomes invalid, the ELAC's go into pitch fault mode. However the SEC's can remain engaged in pitch with only one of those servo loops valid, so, if a THS loop becomes invalid, the elevators loops can still be valid and the elevators will remain in direct law. However, in this rare scenario, both SEC's detected an invalid condition with the ELEVATORS, not just an invalid THS position. The system reached this assumption because the opposing air/ground signals from the LGCIU's resulted in the COM and MON lanes for the ELEVATOR position on both SEC's being in disagreement. This is because the COM lanes get their air/ground data from LGCIU 1, while the MON lanes get it from LGCIU 2. It is important to note, when launching a flight or ground law, the initial orders sent to servos are opposite on different laws [see the second attachment]. In this event, one LGCIU was in air mode and the other was in ground mode (due to the asymmetrical bounce resulting from the absence of ground spoilers). Therefore the elevator MON data diverged from the COM data on both SEC's, and thus they 'gave up'.

                      Now... context: this was a phenomenal event. The investigators had to do lab work to understand why the SEC's had failed. Weaknesses (very, very rare weaknesses) in the software design were revealed by the investigation. As a result, Airbus is upgrading the software to remove those weaknesses. As far as I can determine, the upgrades alter the way the SEC's receive and/or process data from the LGCIU's, probably so the COM and MON channels can share data from both LGCIU's, or perhaps it alters how the SEC's handle the initial MON data, or both. The other software alt seems to address the ELAC's to prevent a manual trim input from leading to fault detection in the event of a OVM malfunction.

                      With those mods in place, I don't see ANY possibility for such an event to recur. Even without the mods, I don't see any revenue service scenario where such an event could occur.

                      Does that answer your question?
                      Attached Files

                      Comment


                      • #12
                        Was there a split elevator at any point?

                        --- Judge what is said by the merits of what is said, not by the credentials of who said it. ---
                        --- Defend what you say with arguments, not by imposing your credentials ---

                        Comment


                        • #13
                          Originally posted by Gabriel View Post
                          Was there a split elevator at any point?
                          The COM signals on both elevators would have been the same. The issue is the discrepency between the COM and MON lanes on each SEC, not between the left and right elevator commands. So I don't see anything that would create a split elevator condition.

                          Tha attachment shows this more clearly. See the COM and MON lanes at the bottom.
                          Attached Files

                          Comment


                          • #14
                            Evan,

                            Now... context: this was a phenomenal event. The investigators had to do lab work to understand why the SEC's had failed. Weaknesses (very, very rare weaknesses) in the software design were revealed by the investigation. As a result, Airbus is upgrading the software to remove those weaknesses. As far as I can determine, the upgrades alter the way the SEC's receive and/or process data from the LGCIU's, probably so the COM and MON channels can share data from both LGCIU's, or perhaps it alters how the SEC's handle the initial MON data, or both. The other software alt seems to address the ELAC's to prevent a manual trim input from leading to fault detection in the event of a OVM malfunction.

                            With those mods in place, I don't see ANY possibility for such an event to recur. Even without the mods, I don't see any revenue service scenario where such an event could occur.
                            I disagree about it being phenomenal. This is a classic software/logic timing problem. I see this problem in software all the time. This complexity arose because a computer has to translate multiple concurrent data streams into a single decision, and due to the limitations of computers -- things like sample rates, and ordering -- the logic can be quite complex and error prone. Testing of all combinations is also impossible -- usually because there is an infinite number of conditions. These failure scenarios are often quite rare -- which is why well designed systems don't fail all the time -- but under heavy use (like millions of flight hours and conditions) they tend to happen eventually. Just like this one did.

                            There is a big trade-off between increasing redundancy automation vs simplicity. When biasing toward the former, the problem relies on the designers and developers being able to accurate predict potential conditions that might happen and the assume certain actions will result in the right outcome. It is not dissimilar from hardware design except in software, the conditions are far more complex.

                            The complexity of scenarios often increases exponentially as you add redundancy which is why your definitive confidence in the risk assessment of possible problems is completely unfounded and not based on the reality of complex systems design.




                            Comment


                            • #15
                              These pilots were very very lucky. A lot of things went well enough for them to survive especially given that the engines lasted just long enough to support their quick turn back to the runway.

                              They also lucked out from the timing, it appears the only reason they were able to climb out initially was because the landing gear was in transit and the front gear pushed the nose up as the engines spooled up. This is why they were able to gain altitude and figure out how to get the plane back to the runway.

                              As the aircraft landing gear was in transition when the aircraft hit the ground, the initial pitch up movement (from -1,7o to +8,8o) can be explained by the front landing gear hitting the runway and changing the aircraft pitch, leading to pitch increase up to +20o with the contribution of the THS being in position 1,5o UP and both thrust levers in 42o (TOGA) position (CAS approximately 200kt).

                              Comment

                              Working...
                              X