Página 3 de 3 PrimerPrimer 123
Resultados 21 al 28 de 28
  1. #21
    Que mal llevan algunos que les tiren por tierra sus argumentos, que por otra parte no sabia que eres moderador para decirme cuando y que puedo escribir...

    Como me dijo un buen amigo... cuanta paciencia...

  2. #22
    De flaiyin machin
    Registro
    30 ago, 10
    Ubicación
    LEBL
    Mensajes
    3,295
    Me sigue encantando este foro después de tantos años por gente como tú, gracias por la explicación MDKeeper, de verdad gracias.

    Saludos.

    Enviado desde mi Redmi Note 6 Pro mediante Tapatalk
    P3D v4.5 & Star Citizen Alpha 3.5.1 with Aurora LN Running in: Intel Core i7 6700K 4'5GHz - Cooler Master Hyper EVO 212 - Asus Z170 Pro Gaming - GeForce GTX 970 4.0 GB Strix OC - 16 GB RAM DDR4 G.Skill Ripjaws V 2133MHz - Alimentación Corsair HX750i - Kingston SSD M.2 240 GB - WD Black SATA3 1 TB 7200 rpm - Samsung LED FX2490HD 24" - Nox Hummer TX - X52Pro & Rudder Pedals& Saitek Pro Flight

    Dadme un turbofan y apartaros!

  3. #23
    Usuario Foroaviones
    Registro
    23 ago, 11
    Mensajes
    220
    Vale vamos a ir por partes:

    Estas añadiendo informacion que yo no he dicho bien porque no me has entendido bien porque no has leido al detalle o por la razon que sea.

    Por ejemplo el accidente de Air France. Yo dije que las pitot se congelaron por hielo, el Alpha Protection estaba activado por las AoA sensor, metio full thrust e intento sacar el avion de la perdida explicando un poco a la gente que no sabia. Entonces tu vas y me dices esto:

    ``Los pitots del A330 no se congelaron por fallo de antihielo´´ Yo se que se congelaron simplemente, no se la razon, nunca dije que fuera antihielo o no, o que la razon fuera un drain hole. Eso lo has añadido tu (porque se ve que conoces del caso) pero no viene a cuento porque estas rebatiendome algo que no dije. Porque no has leido bien mi respuesta.


    -------------------------------------------------------------------------------------------------------------------------------------------

    ``Además...los inerciales del Airbus NO miden AOA´´ Nunca en ningun mensaje mio dije que los inerciales midieran AoA Lo deje claramente usando dos palabras diferentes: ``Ademas, el morro arriba del AoA se puede corroborar/relacional con un alto pitch up (morro arriba) medido por los inerciales´´ Se perfectamente que pitch angle y AOA angle no es lo mismo. Me estas rebatiendo una cosa que no he dicho. Por no haber leido bien mi respuesta.



    ------------------------------------------------------------------------------------------------------------------------------------------


    A la información que dan los AOAs accedemos por medio del menú ADR que está relacionado con los ADIRUs (Air Data and Inertial Reference Unit) en Airbus, porque es quien recibe la señal de pitots/statics/TATs y AOAs, pero un ADIRU NO MIDE AOAs!!!


    De nuevo me rebates algo que yo no he dicho y he dejado claro. Mira esta frase que escribi: Y por diseño y funcionamiento, los inerciales no pueden sufrir congelamiento estan dentro del avion no toman ningun dato de fuera. Lo que me estas diciendo lo deje tambien claro. Pero no has leido mi respuesta.


    ---------------------------------------------------------------------------------------------------------------------------------------

    No es cierta la descripción que das del FBW de Airbus y no es cierta la descripción que das de mandos de vuelo del B737.
    El FBW de Airbus no es ningún transmisor de tus órdenes en el sidestick. El FBW recibe, calcula, compara, calcula de nuevo y envía la información si lo estima oportuno. Tú eres quien sugieres al avión y él decidirá qué hace.


    El FBW de Airbus es el mero transmisor de las ordenes que a mi me salen de los cojones para volar el avion, asi de simple. Seria la ostia que no lo fuera. Y te lo deje claro unos cuantos mensajes antes. Pero de nuevo has vuelto a no leerme. Te escribo de nuevo lo que puse:

    Si tu giras derecha el joystick, este pasara por varios ordenadores y estos deciden (dadas condiciones de velocidad, densidad, etc...) de si mover el aleron exterior, el interior, o solo los spoilers por ejemplo para realizar el giro a la derecha (Le saca el maximo partido a la aerodinamica haciendolo mas eficiente via software). Pero en este caso el piloto gira derecha y el avion gira derecha. Los ordenadores y el software son meros transmisores y optimizadores de informacion (la de tu mano) para traducir esos movimientos en una accion dada. Eso se llama Inner Loop.

    El unico momento en el que tu vas a girar el joystick a la derecha y el avion no te responda es cuando te pases de las protecciones y del flight envelope que tiene. Si a cierta velocidad el maximo angulo de bank es 20 grados y yo quiero meterle 30 grados el avion no me va a dejar. Eso se llama Iner Loop. Pero en el momento en que recibe la informacion de un tercero (sensor) se llama Outer Loop y ahi es cuando el avion ``cobra vida´´ y hace lo que quiere y la unica manera de frenarlo es desactivandolo. Confundes Iner Loop con Outer Loop.



    ---------------------------------------------------------------------------------------------------------------------------------------




    Sabes de lo que hablas, pero no lees nada de nada macho te centras en rebatir. Ademas lo de los sensores no te has enterado de nada de lo que te intento decir. Si tu tienes 3 sensores el avion al ser una maquina no sabe cual es el correcto (cosa que dije yo primero dos mensajes antes y has vuelto a repetir en fin). Por esa razon, se queda con la informacion de uno de ellos. Si fuera uno el incorrecto se queda con los otros dos y si fueran los tres incorrectos o que no concuerdan se quedaria con uno (normalmente el del capitan).

    PERO

    En el momento que fallan o no concuerdan los sensores (pitot, AOA, inerciales, etc...), amigo mio se revierte o se degrada a una ley inferior. He aqui la clave de lo que no estas entendiendo. ¿Como va a funcionar el Alpha protection si fallan los sensores? Muy simple, no funciona, se queda desactivado debido a que volvemos a una ley inferior llamada Alternate Law que te he escrito:

    If Multiple Failures of Redundant Systems occur, the flight controls revert to Alternate Law.

    Encima me dices, que tu no puedes saber si el Alpha Floor funciona o no funciona. No perdona, si se puede saber:

    The ECAM displays the message: ALTN LAW: PROT LOST Tu como piloto debes saber que ese mensaje singifica que no hay protecciones y por tanto alpha floor no funciona. Ademas, los punteros de la velocidad cambian y el pitch en la pantalla son dos cruces ahora.


    Sabes mucho si, pero lee lo que los demas escribimos, asi no llegamos a ningun lado. Dejando de lado todo esto, lo que yo te quiero transmitir y mi mensaje mas importante que me he dejado para el final es el siguiente:

    Si fallan los sensores del Airbus por la razon que sea, el avion no hace una cosa rara y se estampa contra el suelo porque el Alpha Protection no funciona, esta en Alternate Law. El avion no sabe que sensor funciona, pero lo que si sabe el avion es que tiene que desactivar el Alpha Protection porque ya no sirve para nada y para evitar una tragedia.

    Si fallan el sensor del 737 MAX se estampa contra el suelo por dos motivos. El primero la falta de redundancia al usar un solo sensor (capitan) y la imposibilidad de desactivarlo. El sistema no fue diseñado para que en caso de fallo, desactive el MCAS. Mas que nada porque directamente al usar un solo sensor no sabe lo que es fallo o no, asi de simple.


    ¿Cual es la mejor prueba de que lo que yo digo es cierto? Justo el accidente que tu mencionas. El vuelo XL de Germany:

    El agua entonces se congeló en vuelo, haciendo que los sensores se inutilizarán y eliminando así la protección que proporcionan desde el sistema de gestión de vuelo de la aeronave. Cuando la tripulación intentó una prueba improvisada del sistema de alerta AOA (que no estaba funcionando) perdieron el control del avión. La tripulación no estaba al tanto de que los sensores AOA estaban bloqueados, pero tampoco tuvo en cuenta los límites de velocidad apropiados para las pruebas que estaban realizando, lo que resulta en una pérdida


    1-Los AOA se congelan y fallan

    2-Las proteciones de la perdida (Alpha Protection) quedan desactivadas debido a que el avion recibe lecturas incorrectas.

    3-Los pilotos suben el morro del avion intentando a ver si funciona el avisador de perdida y el Alpha Protection.

    4-El avisados de perdida va primero y el Alpha Protection despues. El avisador de perdida no suena (debio de haber sonado pero no lo hizo por otro fallo ajeno) y siguen tirando pero el Alpha Protection tampoco funciona (y no lo saben), no empuja morro abajo (cosa que ellos esperaban) y el avion entra en perdida y se estrella.

    Aqui esta la prueba de lo que te digo es cierto. En el momento en el que los AOA no funcionan el Alpha Protection esta desactivado. Tu me has presentado un caso donde esto ocurre y los pilotos en vuelo suben el morro del avion a ver si funciona y como esto no es asi, lo meten en perdida y se estrellan (Por eso me lo he dejado para el final, para que veas que si, te sonaran muchos casos, pero no vale con que te suenen tienes que leerlos a fondo).


    Y espero que Stalker aprenda a escuchar y entender un poquito mas antes de precipitarse...
    Última edición por vladut.grecu; 01/05/2019 a las 18:50

  4. #24
    Usuario Foroaviones
    Registro
    04 ago, 07
    Ubicación
    Ni cerca ni lejos, ni todo lo contrario
    Mensajes
    4,338
    Desgraciadamente el que mezcla e intenta hacer ver que su mezcla es la verdad no soy yo.

    Alpha Floor NO es comparable al MCAS porque Alpha Floor protection es una protección única y exclusivamente del Autothust. No tiene absolutamente nada que actuar en Flight Controls!!

    Vuelvo a repetir que el AF no se estrelló por engelamiento, y mucho menos los AOAs se congelaron.
    El Alpha Floor se activó por velocidad (pitots) y no por AOAs, que estaban indicando bien. El problema es de comparación de señales y software (“solucionado” a medias con el BUSS).

    El FBW de Airbus no actúa como dices. Por muchas veces que lo repitas seguirá siendo de otra forma.
    El FBW recibe, interpreta, calcula, actúa, vuelve a recibir y vuelve a calcular y actuar. Tú muestras tus intenciones y el avión decide si ejecuta o no.

    Que el MAX habrá que modificarlo es evidente, pero que estás mezclando mil cosas y acusando a los demás de no leer o entender, también...

    Después de 14 años de A320, siendo mi primer avión en licencia, y habiendo trabajado mucho en él en diferentes versiones (Classic, enhanced...) y habiendo vivido incidentes, accidentes, ADs, sufrido sus problemas (arreglados y sin arreglar) ... no es mi intención decir si es mejor o peor que el B737 (que también está en mi licencia), pero lo que dices no es cierto.

    Y ahora vuelve a contestar que no leo, pero si leo...si. Lo que hay que dejar es de interpretar las cosas como nos viene bien!!
    Última edición por MDKeeper; 01/05/2019 a las 17:39

  5. #25
    Usuario Foroaviones
    Registro
    23 ago, 11
    Mensajes
    220
    Cita Iniciado por MDKeeper Ver Mensaje
    Desgraciadamente el que mezcla e intenta hacer ver que su mezcla es la verdad no soy yo.

    Alpha Floor NO es comparable al MCAS porque Alpha Floor protection es una protección única y exclusivamente del Autothust. No tiene absolutamente nada que actuar en Flight Controls!!

    Vuelvo a repetir que el AF no se estrelló por engelamiento, y mucho menos los AOAs se congelaron.
    El Alpha Floor se activó por velocidad (pitots) y no por AOAs, que estaban indicando bien. El problema es de comparación de señales y software (“solucionado” a medias con el BUSS).

    El FBW de Airbus no actúa como dices. Por muchas veces que lo repitas seguirá siendo de otra forma.
    El FBW recibe, interpreta, calcula, actúa, vuelve a recibir y vuelve a calcular y actuar. Tú muestras tus intenciones y el avión decide si ejecuta o no.

    Que el MAX habrá que modificarlo es evidente, pero que estás mezclando mil cosas y acusando a los demás de no leer o entender, también...

    Después de 14 años de A320, siendo mi primer avión en licencia, y habiendo trabajado mucho en él en diferentes versiones (Classic, enhanced...) y habiendo vivido incidentes, accidentes, ADs, sufrido sus problemas (arreglados y sin arreglar) ... no es mi intención decir si es mejor o peor que el B737 (que también está en mi licencia), pero lo que dices no es cierto.

    Y ahora vuelve a contestar que no leo, pero si leo...si. Lo que hay que dejar es de interpretar las cosas como nos viene bien!!
    Claro eso tambien hay que recalcarlo y es cierto. Alpha Floor no empuja ni pica morro abajo. Eso lo unico que hace es meter TOGA a los motores basandose en las pitot porque a full thrust la velocidad de perdida es menor y por lo tanto previene en cierto modo la perdida. Pero cuidado, Alpha Protection que seria considerado un subapartado del Flight Envelope Protection si que pica morro abajo el avion y si que toma informacion del AoA sensor. De ahi que durante todo este tiempo hablemos de que es un sistema similar al MCAS porque lo es como bien pregunto alguien ahi mas arriba. Y si que actua en los flight controls....

    High Angle of Attack Protection (alpha):

    When alpha exceeds alpha prot, elevator control switches to alpha protection mode in which angle of attack is proportional to sidestick deflection.
    Alpha max will not be exceeded even if the pilot applies full aft deflection


    Y fijate que tanto en el caso que yo he descrito del accidente como el funcionamiento de los sensores esta escrito Alpha Protection, refiriendome al Flight Envelope.

  6. #26
    Usuario Foroaviones
    Registro
    04 ago, 07
    Ubicación
    Ni cerca ni lejos, ni todo lo contrario
    Mensajes
    4,338
    No tenía tiempo antes de buscarlo, pero aquí lo tienes...

    Airbus entra en Alternate Law y desactiva el Alpha Protection cuando tiene fallo de 2 AOAs porque como están colocados en zonas diferentes no es posible que los dos fallen igual... ¿verdad?

    Lufthansa de Bilbao a Munich:

    "
    The BFU reported Spain's CIAIAC delegated the investigation to the BFU on Nov 11th 2014.

    The BFU reported that according to flight data and cockpit voice recorder the first officer (35, ATPL, 6,473 hours total, 5,179 hours on type) was pilot flying, the captain (52, ATPL, 16,384 hours total, 12,414 hours on type) pilot monitoring. After the aircraft climbed clear of top of clouds at about FL200 the flight data recorder recorded a fixed value of +4.2 degrees for the left hand AoA sensor, less than a minute later the FDR began to record a fixed value of +4.6 degrees for the right hand AoA sensor. The aircraft subsequently turned to fly direct to LATEK waypoint, during this turn the captain noticed the Alpha Protection Band had unusually and significantly increased. The first officer therefore reduced the climb rate from 800 to 500 feet per minute to enable the aircraft to accelerate. A short time later the first officer disengaged the autopilot and gave a brief nose down input.

    The aircraft however continued to pitch down, inputs to counter the pitch down remained without effect. About 45 seconds after the nose down began the first officer alerted the captain who took control of the aircraft, that at this time had reached a rate of descent of 4000 feet per minute and a pitch of -3.5 degrees. The captain provided a maximum nose up input which caused the aircraft to pitch up again and the rate of descent decreased and the aircraft entered level flight.

    The captain was able to maintain altitude by providing a continuous nose up input deflecting the side stick about 50% of its travel. The autopilot could not be engaged again, and a manual nose up trim was not possible.

    The crew checked for related checklists but did not find any. The crew reset the Flight Augmentation Computers 1 and 2 in sequence with no effect.

    8 minutes after the aircraft began its descent the Aircraft Communications Addressing and Reporting System (ACARS) issued an automated information to dispatch showing the three AoA sensor values amongst other data.

    21 minutes after the aircraft began its descent the crew sent a message to maintenance checking whether a simultaneous reset of all FACs would be possible. Maintenance replied in the positive stating that the aircraft would revert to alternate law as result. Another 7 minutes later the crew reported they needed to constantly pull on the sidestick, trim was inoperative and autopilot could not be engaged and the Alpha Prot Band came up extremely quick. In addition the crew received a message "PH6 AOA3" on the centralized fault display system (CFDS). Upon suggestion by maintenance the crew switched off the air data reference unit (ADR3), however, without effect. ADR3 was reengaged. Another 12 minutes later maintenance wrote a message to the cockpit along the lines "after review of the data we found the values for AoA 1 and AoA2 appear to be frozen and report too high an angle of attack. If the problem persists, disengage ADR1 and ADR2 which will cause the aircraft to revert to Alternate Law however." then followed up "perhaps it is sufficient to just disengage ADR2".

    The crew disengaged ADR2 which immediately prompted the aircraft to revert to Alternate Law and it was no longer necessary to pull the nose up.

    The crew decided to use the remaining hour of flight time to verify the system status and to prepare for landing and landed safely at the destination.

    The BFU reported that the aircraft features three Angle of Attack sensors consisting of a heated movable vane, the movement of the vanes is converted into electrical signals and the actual angle of attack computed by the related air data reference unit.

    If the measured/computer Angle of Attack exceeds the value of Alpha Prot by one degrees, the autopilot is automatically being disengaged. In manual flight if the Alpha Prot Angles is exceeded, the Alpha Protection activates, the position of trim is stored and used as maximum nose up trim, the function of the side stick changes to command a specific pitch angle with the most nose up angle being Alpha Max which can be reached by full nose up deflection of the side stick.

    The BFU reported that all three AoA sensors were examined by the manufacturer, no damage, malfunction or anomaly was identified with either of the sensors.

    Airbus analysed the data and stated: "all three sensors worked normally until about 8 minutes into the flight, when the aircraft climbed through FL195. At that point, at an ambient temperature of -35 degrees C, AoA sensors 1 and 2 froze up at a position of approximately 4.5 degrees nose up and remained in this position until the aircraft descended towards the destination airport. At the time, when the autopilot disengaged the aircraft was flying at 0.675 mach, the Alpha Prot angle was 4.2 degrees, the Alpha Max 5.8 degrees. Within 15 seconds the first officer made increasing nose up input until reaching 75% of the maximum travel of the side stick, the attitude however changed from 4.5 degrees to -3.5 degrees against this input. The system disregarded/turned off the AoA 3 sensor because it disagreed more than the permitted value with the other 2 sensors.

    When later ADR2 was disengaged, the system immediately reverted to Alternate Law because ADR3 had already been disengaged by the system and now two ADRs were offline.

    The BFU reported that they are working to establish how reliable AoA sensors are but annotated: "The algorithms and boundary conditions differ from each other and are not entirely known to the BFU. The investigation is aiming to establish the probability of a repeat of this occurrence."




    Uncommanded nose dive. A330 de Qantas (entre otros):



    "
    Contributing safety factors

    - There was a limitation in the algorithm used by the A330/A340 flight control primary computers for processing angle of attack (AOA) data. This limitation meant that, in a very specific situation, multiple AOA spikes from only one of the three air data inertial reference units could result in a nose-down elevator command. [Significant safety issue]

    - When developing the A330/A340 flight control primary computer software in the early 1990s, the aircraft manufacturer’s system safety assessment and other development processes did not fully consider the potential effects of frequent spikes in the data from an air data inertial reference unit. [Minor safety issue]

    - One of the aircraft’s three air data inertial reference units (ADIRU 1) exhibited a data-spike failure mode, during which it transmitted a significant amount of incorrect data on air data parameters to other aircraft systems, without flagging that this data was invalid. The invalid data included frequent spikes in angle of attack data. Including the 7 October 2008 occurrence, there have been three occurrences of the same failure mode on LTN-101 ADIRUs, all on A330 aircraft. [Minor safety issue]

    - The LTN-101 air data inertial reference unit involved in the occurrence (serial number 4167) also had a previous instance of the data-spike failure mode, indicating that it probably contained a marginal weakness in its hardware, which reduced the resilience of the unit to some form of triggering event.

    - For the data-spike failure mode, the built-in test equipment of the LTN-101 air data inertial reference unit was not effective, for air data parameters, in detecting the problem, communicating appropriate fault information, and flagging affected data as invalid. [Minor safety issue]

    - The air data inertial reference unit manufacturer’s failure mode effects analysis and other development processes for the LTN-101 ADIRU did not identify the data-spike failure mode.

    - Although passengers are routinely reminded to keep their seat belts fastened during flight whenever they are seated, a significant number of passengers have not followed this advice. At the time of the first in-flight upset, more than 60 of the 303 passengers were seated without their seat belts fastened. [Minor safety issue]

    Other safety factors

    - In recent years there have been developments in guidance materials for system development processes and research into new approaches for system safety assessments. However, there has been limited research that has systematically evaluated how design engineers and safety analysts conduct their evaluations of systems, and how the design of their tasks, tools, training and guidance material can be improved so that the likelihood of design errors is minimised. [Minor safety issue]

    - The large number of spurious warnings and caution messages that resulted from the anomalous air data inertial reference unit behaviour created a significant amount of workload and distraction for the flight crew.

    - Single event effects (SEE) have the potential to adversely affect avionics systems that have not been specifically designed to be resilient to this hazard. There were no specific certification requirements for SEE, and until recently there was no formal guidance material available for addressing SEE during the design process. [Minor safety issue]

    - The LTN-101 air data inertial reference unit (ADIRU) model had a demonstrated susceptibility to single event effects (SEE). The consideration of SEE during the design process was consistent with industry practice at the time the unit was developed, and the overall fault rates of the ADIRU were within the relevant design objectives. [Minor safety issue]

    - Industry practices for tracking faults or performance problems with line-replaceable units were limited, unless the units are removed for examination. Consequently, the manufacturers of aircraft equipment have incomplete information for identifying patterns or trends that can be used to improve the safety, availability or reliability of the units. [Minor safety issue]

    - There has been very little research conducted into the factors influencing passengers’ use of seat belts when the seat-belt sign is not illuminated, and the effectiveness of different techniques to increase the use of seat belts. [Minor safety issue]

    - Although passengers are routinely advised after takeoff to wear their seat belts when seated, this advice typically does not reinforce how the seat belts should be worn. [Minor safety issue]

    Other key findings

    - As of the end of 2009, A330/A340 aircraft had accumulated over 28 million flight hours. The occurrence on 7 October 2008 was the only occasion when incorrect data from an air data inertial reference unit had resulted in inadvertent elevator commands. This in-service performance was consistent with the relevant certification requirements.

    - As of April 2010, the LTN-101 air data inertial reference unit (ADIRU) had accumulated over 128 million hours of operation. The data-spike failure mode had only been observed on three occasions. The ADIRU’s in-service performance met the aircraft manufacturer’s safety and reliability objectives.

    - Air data inertial reference unit (ADIRU) 2 and ADIRU 3 operated normally throughout the flight.

    - Although air data inertial reference unit 1 transmitted a significant amount of incorrect data on inertial reference parameters to other aircraft systems, almost all of this data was flagged as invalid.

    - It is very likely that the air data inertial reference unit (ADIRU) data-spike failure mode involved a problem with the data packaging and queuing within the ADIRU’s central processing unit module. This fault resulted in numerous data anomalies, including air data reference parameters being intermittently transmitted with the data or label of another parameter. Despite extensive testing and analysis, the exact origins of the failure mode could not be determined.

    - Tests and analyses showed that the air data inertial reference unit data-spike failure mode was probably not triggered by a software bug, software corruption, hardware fault, physical environment factors (such as temperature of vibration), or from electromagnetic interference.

    - The three known occurrences of the air data inertial reference unit data-spike failure mode occurred on two A330 aircraft operated by the same operator; however, no factors related to the operator’s aircraft configuration, operating practices, or maintenance practices were identified that were associated with the failure mode.

    - The flight crew’s responses to the warnings and cautions, the pitch-down events, and the consequences of the pitch-down events, demonstrated sound judgement and a professional approach.

    - Wearing a seat belt during all phases of a flight, and having the seat belt fastened low and firm, will significantly minimise the risk of injury in the unlikely event of an in-flight upset.

    The ATSB reported in addition to the information released so far, that there had been a good opportunity to catch the failure mode before the events of 2008, when VH-QPA (which got involved involved in the Learmonth accident 2 years later) had another encounter with the same ADIRU. Although the flight data of that flight were no longer available, testimony of the crew reporting a number of warnings received permitted the investigation to conclude that "the occurrence involved similar ADIRU data output anomalies as that which occurred on the 7 October 2008 flight." The crew switched ADIRU#1 off and the anomalies ceased, maintenance realigned the ADIRU, which subsequently passed tests.

    The ATSB stated therefore: "In theory, the 12 September 2006 occurrence provided an opportunity for the ADIRU data-spike failure mode and the design limitation of the A330/A340 flight control system to be identified before the 7 October 2008 occurrence. In reality, based on the available information, there were good reasons for not conducting any further investigation at the time."

    The ATSB analysed that the upset was caused by elevator pitch down movements, that were not initiated by turbulence, pilot input, autopilot input, problems with the aircraft mass and balance, technical faults with the elevator controls or other relevant faults of the electronic flight control system. The investigation showed that the elevator movement was in fact prompted by the eletronic flight control system's primary flight control computer, which were programmed to provide a pitch down command if too high of an angle of attack (AoA) was detected. This was part of the AoA protection and anti pitch-up compensation. In the particular flight a very specific and unintended scenario occurred, in which erroneous AoA data from one of the three ADIRUs could trigger a pitch down command. The scenario needed two spikes with the second arriving 1.2 seconds after the first. About two minutes prior to the upset the ADIRU#1 started to provide erroneous AoA data containing a number of spikes. Simulation of those spikes done by the aircraft manufacturer confirmed the sequence of spikes as present in the accident flight would trigger the elevator movements as occurred on the accident flight."


    Estás mezclando y obviando cosas para dar veracidad a tu opinión. Alpha Protection NO actúa bajando el morro del avión en el 320. Por mucho que lo repitas, no es cierto.



    Última edición por MDKeeper; 01/05/2019 a las 23:41

  7. #27
    Usuario Foroaviones
    Registro
    23 ago, 11
    Mensajes
    220
    Cita Iniciado por MDKeeper Ver Mensaje
    No tenÃ*a tiempo antes de buscarlo, pero aquÃ* lo tienes...

    Airbus entra en Alternate Law y desactiva el Alpha Protection cuando tiene fallo de 2 AOAs porque como están colocados en zonas diferentes no es posible que los dos fallen igual... ¿verdad?

    Lufthansa de Bilbao a Munich:

    "
    The BFU reported Spain's CIAIAC delegated the investigation to the BFU on Nov 11th 2014.

    The BFU reported that according to flight data and cockpit voice recorder the first officer (35, ATPL, 6,473 hours total, 5,179 hours on type) was pilot flying, the captain (52, ATPL, 16,384 hours total, 12,414 hours on type) pilot monitoring. After the aircraft climbed clear of top of clouds at about FL200 the flight data recorder recorded a fixed value of +4.2 degrees for the left hand AoA sensor, less than a minute later the FDR began to record a fixed value of +4.6 degrees for the right hand AoA sensor. The aircraft subsequently turned to fly direct to LATEK waypoint, during this turn the captain noticed the Alpha Protection Band had unusually and significantly increased. The first officer therefore reduced the climb rate from 800 to 500 feet per minute to enable the aircraft to accelerate. A short time later the first officer disengaged the autopilot and gave a brief nose down input.

    The aircraft however continued to pitch down, inputs to counter the pitch down remained without effect. About 45 seconds after the nose down began the first officer alerted the captain who took control of the aircraft, that at this time had reached a rate of descent of 4000 feet per minute and a pitch of -3.5 degrees. The captain provided a maximum nose up input which caused the aircraft to pitch up again and the rate of descent decreased and the aircraft entered level flight.

    The captain was able to maintain altitude by providing a continuous nose up input deflecting the side stick about 50% of its travel. The autopilot could not be engaged again, and a manual nose up trim was not possible.

    The crew checked for related checklists but did not find any. The crew reset the Flight Augmentation Computers 1 and 2 in sequence with no effect.

    8 minutes after the aircraft began its descent the Aircraft Communications Addressing and Reporting System (ACARS) issued an automated information to dispatch showing the three AoA sensor values amongst other data.

    21 minutes after the aircraft began its descent the crew sent a message to maintenance checking whether a simultaneous reset of all FACs would be possible. Maintenance replied in the positive stating that the aircraft would revert to alternate law as result. Another 7 minutes later the crew reported they needed to constantly pull on the sidestick, trim was inoperative and autopilot could not be engaged and the Alpha Prot Band came up extremely quick. In addition the crew received a message "PH6 AOA3" on the centralized fault display system (CFDS). Upon suggestion by maintenance the crew switched off the air data reference unit (ADR3), however, without effect. ADR3 was reengaged. Another 12 minutes later maintenance wrote a message to the cockpit along the lines "after review of the data we found the values for AoA 1 and AoA2 appear to be frozen and report too high an angle of attack. If the problem persists, disengage ADR1 and ADR2 which will cause the aircraft to revert to Alternate Law however." then followed up "perhaps it is sufficient to just disengage ADR2".

    The crew disengaged ADR2 which immediately prompted the aircraft to revert to Alternate Law and it was no longer necessary to pull the nose up.

    The crew decided to use the remaining hour of flight time to verify the system status and to prepare for landing and landed safely at the destination.

    The BFU reported that the aircraft features three Angle of Attack sensors consisting of a heated movable vane, the movement of the vanes is converted into electrical signals and the actual angle of attack computed by the related air data reference unit.

    If the measured/computer Angle of Attack exceeds the value of Alpha Prot by one degrees, the autopilot is automatically being disengaged. In manual flight if the Alpha Prot Angles is exceeded, the Alpha Protection activates, the position of trim is stored and used as maximum nose up trim, the function of the side stick changes to command a specific pitch angle with the most nose up angle being Alpha Max which can be reached by full nose up deflection of the side stick.

    The BFU reported that all three AoA sensors were examined by the manufacturer, no damage, malfunction or anomaly was identified with either of the sensors.

    Airbus analysed the data and stated: "all three sensors worked normally until about 8 minutes into the flight, when the aircraft climbed through FL195. At that point, at an ambient temperature of -35 degrees C, AoA sensors 1 and 2 froze up at a position of approximately 4.5 degrees nose up and remained in this position until the aircraft descended towards the destination airport. At the time, when the autopilot disengaged the aircraft was flying at 0.675 mach, the Alpha Prot angle was 4.2 degrees, the Alpha Max 5.8 degrees. Within 15 seconds the first officer made increasing nose up input until reaching 75% of the maximum travel of the side stick, the attitude however changed from 4.5 degrees to -3.5 degrees against this input. The system disregarded/turned off the AoA 3 sensor because it disagreed more than the permitted value with the other 2 sensors.

    When later ADR2 was disengaged, the system immediately reverted to Alternate Law because ADR3 had already been disengaged by the system and now two ADRs were offline.

    The BFU reported that they are working to establish how reliable AoA sensors are but annotated: "The algorithms and boundary conditions differ from each other and are not entirely known to the BFU. The investigation is aiming to establish the probability of a repeat of this occurrence."




    Uncommanded nose dive. A330 de Qantas (entre otros):



    "
    Contributing safety factors

    - There was a limitation in the algorithm used by the A330/A340 flight control primary computers for processing angle of attack (AOA) data. This limitation meant that, in a very specific situation, multiple AOA spikes from only one of the three air data inertial reference units could result in a nose-down elevator command. [Significant safety issue]

    - When developing the A330/A340 flight control primary computer software in the early 1990s, the aircraft manufacturerÂ’s system safety assessment and other development processes did not fully consider the potential effects of frequent spikes in the data from an air data inertial reference unit. [Minor safety issue]

    - One of the aircraftÂ’s three air data inertial reference units (ADIRU 1) exhibited a data-spike failure mode, during which it transmitted a significant amount of incorrect data on air data parameters to other aircraft systems, without flagging that this data was invalid. The invalid data included frequent spikes in angle of attack data. Including the 7 October 2008 occurrence, there have been three occurrences of the same failure mode on LTN-101 ADIRUs, all on A330 aircraft. [Minor safety issue]

    - The LTN-101 air data inertial reference unit involved in the occurrence (serial number 4167) also had a previous instance of the data-spike failure mode, indicating that it probably contained a marginal weakness in its hardware, which reduced the resilience of the unit to some form of triggering event.

    - For the data-spike failure mode, the built-in test equipment of the LTN-101 air data inertial reference unit was not effective, for air data parameters, in detecting the problem, communicating appropriate fault information, and flagging affected data as invalid. [Minor safety issue]

    - The air data inertial reference unit manufacturerÂ’s failure mode effects analysis and other development processes for the LTN-101 ADIRU did not identify the data-spike failure mode.

    - Although passengers are routinely reminded to keep their seat belts fastened during flight whenever they are seated, a significant number of passengers have not followed this advice. At the time of the first in-flight upset, more than 60 of the 303 passengers were seated without their seat belts fastened. [Minor safety issue]

    Other safety factors

    - In recent years there have been developments in guidance materials for system development processes and research into new approaches for system safety assessments. However, there has been limited research that has systematically evaluated how design engineers and safety analysts conduct their evaluations of systems, and how the design of their tasks, tools, training and guidance material can be improved so that the likelihood of design errors is minimised. [Minor safety issue]

    - The large number of spurious warnings and caution messages that resulted from the anomalous air data inertial reference unit behaviour created a significant amount of workload and distraction for the flight crew.

    - Single event effects (SEE) have the potential to adversely affect avionics systems that have not been specifically designed to be resilient to this hazard. There were no specific certification requirements for SEE, and until recently there was no formal guidance material available for addressing SEE during the design process. [Minor safety issue]

    - The LTN-101 air data inertial reference unit (ADIRU) model had a demonstrated susceptibility to single event effects (SEE). The consideration of SEE during the design process was consistent with industry practice at the time the unit was developed, and the overall fault rates of the ADIRU were within the relevant design objectives. [Minor safety issue]

    - Industry practices for tracking faults or performance problems with line-replaceable units were limited, unless the units are removed for examination. Consequently, the manufacturers of aircraft equipment have incomplete information for identifying patterns or trends that can be used to improve the safety, availability or reliability of the units. [Minor safety issue]

    - There has been very little research conducted into the factors influencing passengersÂ’ use of seat belts when the seat-belt sign is not illuminated, and the effectiveness of different techniques to increase the use of seat belts. [Minor safety issue]

    - Although passengers are routinely advised after takeoff to wear their seat belts when seated, this advice typically does not reinforce how the seat belts should be worn. [Minor safety issue]

    Other key findings

    - As of the end of 2009, A330/A340 aircraft had accumulated over 28 million flight hours. The occurrence on 7 October 2008 was the only occasion when incorrect data from an air data inertial reference unit had resulted in inadvertent elevator commands. This in-service performance was consistent with the relevant certification requirements.

    - As of April 2010, the LTN-101 air data inertial reference unit (ADIRU) had accumulated over 128 million hours of operation. The data-spike failure mode had only been observed on three occasions. The ADIRUÂ’s in-service performance met the aircraft manufacturerÂ’s safety and reliability objectives.

    - Air data inertial reference unit (ADIRU) 2 and ADIRU 3 operated normally throughout the flight.

    - Although air data inertial reference unit 1 transmitted a significant amount of incorrect data on inertial reference parameters to other aircraft systems, almost all of this data was flagged as invalid.

    - It is very likely that the air data inertial reference unit (ADIRU) data-spike failure mode involved a problem with the data packaging and queuing within the ADIRUÂ’s central processing unit module. This fault resulted in numerous data anomalies, including air data reference parameters being intermittently transmitted with the data or label of another parameter. Despite extensive testing and analysis, the exact origins of the failure mode could not be determined.

    - Tests and analyses showed that the air data inertial reference unit data-spike failure mode was probably not triggered by a software bug, software corruption, hardware fault, physical environment factors (such as temperature of vibration), or from electromagnetic interference.

    - The three known occurrences of the air data inertial reference unit data-spike failure mode occurred on two A330 aircraft operated by the same operator; however, no factors related to the operatorÂ’s aircraft configuration, operating practices, or maintenance practices were identified that were associated with the failure mode.

    - The flight crewÂ’s responses to the warnings and cautions, the pitch-down events, and the consequences of the pitch-down events, demonstrated sound judgement and a professional approach.

    - Wearing a seat belt during all phases of a flight, and having the seat belt fastened low and firm, will significantly minimise the risk of injury in the unlikely event of an in-flight upset.

    The ATSB reported in addition to the information released so far, that there had been a good opportunity to catch the failure mode before the events of 2008, when VH-QPA (which got involved involved in the Learmonth accident 2 years later) had another encounter with the same ADIRU. Although the flight data of that flight were no longer available, testimony of the crew reporting a number of warnings received permitted the investigation to conclude that "the occurrence involved similar ADIRU data output anomalies as that which occurred on the 7 October 2008 flight." The crew switched ADIRU#1 off and the anomalies ceased, maintenance realigned the ADIRU, which subsequently passed tests.

    The ATSB stated therefore: "In theory, the 12 September 2006 occurrence provided an opportunity for the ADIRU data-spike failure mode and the design limitation of the A330/A340 flight control system to be identified before the 7 October 2008 occurrence. In reality, based on the available information, there were good reasons for not conducting any further investigation at the time."

    The ATSB analysed that the upset was caused by elevator pitch down movements, that were not initiated by turbulence, pilot input, autopilot input, problems with the aircraft mass and balance, technical faults with the elevator controls or other relevant faults of the electronic flight control system. The investigation showed that the elevator movement was in fact prompted by the eletronic flight control system's primary flight control computer, which were programmed to provide a pitch down command if too high of an angle of attack (AoA) was detected. This was part of the AoA protection and anti pitch-up compensation. In the particular flight a very specific and unintended scenario occurred, in which erroneous AoA data from one of the three ADIRUs could trigger a pitch down command. The scenario needed two spikes with the second arriving 1.2 seconds after the first. About two minutes prior to the upset the ADIRU#1 started to provide erroneous AoA data containing a number of spikes. Simulation of those spikes done by the aircraft manufacturer confirmed the sequence of spikes as present in the accident flight would trigger the elevator movements as occurred on the accident flight."


    Estás mezclando y obviando cosas para dar veracidad a tu opinión. Alpha Protection NO actúa bajando el morro del avión en el 320. Por mucho que lo repitas, no es cierto.




    Alpha Protection evita meter el avion en perdida no dejandote tirarle a los controles mas de lo necesario, es decir omitiendo ciertas ordenes de tu mano. PERO si el avion entiende que esta en perdida, Alpha Protection si que te empuja morro abajo, tu mismo en el caso que me has expuesto te contradices:


    A short time later the first officer disengaged the autopilot and gave a brief nose down input.

    The aircraft however continued to pitch down, inputs to counter the pitch down remained without effect. About 45 seconds after the nose down began the first officer alerted the captain who took control of the aircraft, that at this time had reached a rate of descent of 4000 feet per minute and a pitch of -3.5 degrees. The captain provided a maximum nose up input which caused the aircraft to pitch up again and the rate of descent decreased and the aircraft entered level flight.


    El piloto al ver que el avion esta cercano a la perdida (no lo estaba pero la maquina le hacia intuir eso), le empuja un poco de morro abajo para ver si resuelve la situacion. En cambio, el avion sigue creyendo que esta en perdida y sigue empujando morro abajo hasta -3.5 grados alcanzado 4000 pies de vario. En otras palabras, si que el piloto mueva los mandos el avion pica morro abajo. ¿Eso que nombre tiene? ¿Segun tu no decias que no era posible eso que no funcionaba asi?.... Para sacar el avion de esa situacion y mantenerlo nivelado, el capitan tira al maximo del sidestick morro arriba y consiguen nivelarlo. Y luego tu vienes y me dices que el Alpha Protection no pica morro abajo.....


    Debido a que los sensores estan situados en diferentes partes del fuselaje y el aire les golpea de una manera ligeramente diferente (aun estando calibrados para indicar lo mismo) es virtualmente imposible que dos de ellos fallen e indiquen lo mismo (las dos condiciones). Si eso falla, entonces el avion pica morro abajo y se estrella. Es JUSTO el caso que me estas planteando. Este caso no hace mas que corroborar lo que estoy diciendo. Fijate en lo que te escribir mensajes anteriores:


    El unico caso para que el avion pique morro abajo y se estrelle es que se de una cosa muy rara en el caso numero 1. Tu tienes que saber que el avion no es como el humano, el no sabe decidir lo bueno y lo malo, el solo sabe que le estan llegando 3 valores. Dicho esto:

    El avion vuela por dentro de una nube y se le congelan dos de los sensores indicando mal mientras que uno de ellos queda libre e indica bien. Debido a que los dos que se congelan indican mal PERO indican lo mismo, le haria caso a esos sensores y descartaria el tercer sensor (el correcto), que no tiene hielo y que funciona correctamente y activaria el Alpha Protection picando morro abajo y estrellandolo.


    Esto amigo mio, esto que ves aqui y que escribi al principio del post sin que tu intervinieras previamente y sin que me dijeras nada de engelamiento ni me presentaras ningun caso de incidente en primer lugar no me lo saque de la chistera y en segundo lugar coincide con el caso que tu me has expuesto. Dos sensores de AOA que se quedan bloqueados indicando lo mismo (uno 4.2 grados y otros 4.6 grados) el avion hace caso a los erroneos descartando el tercero bueno (elige por mayoria) y por lo tanto el avion pica morro abajo y comienza a descender.

    the flight data recorder recorded a fixed value of +4.2 degrees for the left hand AoA sensor, less than a minute later the FDR began to record a fixed value of +4.6 degrees for the right hand AoA sensor.

    Ademas me estas diciendo que el Alpha Protection no puede picar morro abajo...¿Entonces si no puede picarme el avion morro abajo porque vienes y me presentas dos incidentes que se llaman ``Uncommanded nose dive A330´´? Vamos que si se puede entonces no?



    Ademas lo que mas me gusta de lo que has expuesto es como resuelven el problema los pilotos, que de nuevo confirma el funcionamiento de los sensores de AOA que segun tu me estaba inventando....

    Hay 3 sensores. AOA1 y AOA2 fallan y estan congelados estando en perdida, AOA3 funciona bien.

    1-Los pilotos intentan resetar los ordenadores, de nada sirve, no es un problema de ordenadores es uno de sensores.

    2-Intentan desactivar el AD3. Lo hacen pero sin ningun efecto, el avion sigue teniendo problemas (normal, porque al que falla no es el sensor AOA3). Vuelven a conectarlo.

    3-Mantenimiento se da cuenta de que los sensores AOA1 y AOA2 funcionan mal. Les dicen que los desconecten (quitando ADRs) y resolveran el problema pero que tengan en cuenta que estaran a partir de entonces en Alternate Law. Tambien les dicen que intenten solo quitar el AOA2 que posiblemente solo con desactivar ese funcione.

    Bien pues ellos desactivan solamente el AOA2 quitando el ADR2 y voilá, el avion esta en Alternate Law y se soluciona el problema. Asi que ya esta, ahi lo tienes: en el momento en el que hay 2 sensores indicando algo y uno indicando algo diferente ocurren dos casos:

    1-Los dos sensores indican bien y se elimina el tercero, el avion vuela sin problema.

    2-Los dos sensores indican mal y el avion descarta el tercero por mayoria (no sabe cual es el bueno). Por lo tanto tenemos un problema. Ese problema se resuelve desactivando uno de los sensores erroneos. Desactivandolo tenemos ahora 1 sensor que indica bien y 1 sensor que indica mal. El Airbus no sabe cual es el correcto, por lo que los ignora, se degrada a Alternate Law y el Alpha Protection queda desactivado.


    Y no voy a leer mas ni hablar mas lo siento mucho pero es que me cuesta mucho escribir tanto parrafo paso por paso para explicar dos cosas que dije al principio. Espero que haya quedado claro al menos como funciona esto.
    Última edición por vladut.grecu; 02/05/2019 a las 12:24

  8. #28
    Usuario Foroaviones
    Registro
    20 ago, 08
    Mensajes
    6,067
    https://www.seattletimes.com/busines...-is-uncertain/

    Aplazada sin fecha fija la vuelta al servicio de los 737MAX.

    https://www.larazon.es/economia/los-...ido-LN23482845

    El regulador americano no aprueba su vuelta tras reunirse con la compañía para estudiar las mejoras introducidas. Sólo autorizará sus vuelos cuando los considere completamente seguros

    Las aspiraciones de Boeing de que la crisis de su modelo 737 MAX se superase con rapidez sufrieron esta madrugada un severo contratiempo. La Agencia Federal de Aviación (FAA) de Estados Unidos ha dejado sin fecha la homologación del modelo tras la reunión mantenida este jueves con nueve reguladores aéreos del mundo, entre los que estaban también el chino y el europeo.

    Hace un par de semanas, Boeing anunció que había actualizado el software de su sistema de estabilidad de vuelo (MCAS), que parece estar detrás de los accidentes de Indonesia y Etiopía que causaron 346 muertos y llevaron a las autoridades aéreas mundiales a prohibir los vuelos del 737 MAX en marzo. Sin embargo, al término del encentro mantenido en Forth Worth (Texas), el jefe interino de la FAA, Daniel Elwell, ha informado de que a pesar de que la reunión fue "extremadamente positiva" y "constructiva", no hay fecha para la vuelta del 737 MAX.

    Elwell ha reiterado que la autoridad aérea estadounidense no aprobará el regreso del modelo 737 MAX "hasta que haya completado un análisis de seguridad" y "sin un calendario establecido para el entrenamiento de pilotos" en el MCAS, según informa Reuters.
    Por cada "ciudadanos y ciudadanas", chupito.

 

 
Página 3 de 3 PrimerPrimer 123

Temas Similares

  1. Respuestas: 15
    Último Mensaje: 24/01/2017, 09:03
  2. Respuestas: 2
    Último Mensaje: 14/12/2015, 18:14
  3. Respuestas: 48
    Último Mensaje: 07/03/2011, 12:11
  4. Respuestas: 19
    Último Mensaje: 27/09/2010, 08:13
  5. Respuestas: 12
    Último Mensaje: 28/11/2008, 02:51

Permisos de Publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •