#1 Y muy directo, han jugado a la ruleta rusa con los pasajeros y las tripulaciones de los 737 MAX por un beneficio económico y no esta claro que pretendan dejar de hacerlo, incluso sabiendo lo que había y con casi cuatrocientos muertos presionaron para que los aviones siguieran volando, los directivos deberían terminar delante de un juez y no resolviendo su responsabilidad con una actualización del software
#1 si no dominas el inglés puede ser arduo, pero me ha parecido realmente muy interesante.
Muchas veces falta experiencia real en la gente que diseña los sistemas.
En mi trabajo (un departamento de estudios) nos lo encontramos muy habitualmente , los técnicos son teóricos y no han estado en campo en su vida. Por eso los mejores técnicos son los que llevan las dos vertientes.
Si en una película hubiera visto al piloto protagonista luchando contra la máquina haciendo fuerza con el timón mientras la máquina tiraba en la dirección opuesta me habría levantado una sonrisa y hubiera pensado que era infantil y poco creíble representar la lucha entre el hombre y la máquina de esa forma.
No creo que a los pilotos que se encontraron en esa situación real les levantase sonrisa alguna.
#3 Yo acuñé hace años la expresión “programador de salón” para estos que tienen muchos conocimientos teóricos pero nunca se ponen en la piel de los usuarios o en la realidad operativa en el mundo real.
Esto es lo más completo, informado, comprensible y bien documentado que he leído sobre el tema del 737 Max. Escrito por alguien que conoce el tema a fondo. Es un artículo sensacional.
Meneo de libro. Maravilloso artículo. Me permito destacar la conclusión por si alguno no tiene tiempo para leerlo entero:
So Boeing produced a dynamically unstable airframe, the 737 Max. That is big strike No. 1. Boeing then tried to mask the 737’s dynamic instability with a software system. Big strike No. 2. Finally, the software relied on systems known for their propensity to fail (angle-of-attack indicators) and did not appear to include even rudimentary provisions to cross-check the outputs of the angle-of-attack sensor against other sensors, or even the other angle-of-attack sensor. Big strike No. 3.
None of the above should have passed muster. None of the above should have passed the “OK” pencil of the most junior engineering staff, much less a DER.
That’s not a big strike. That’s a political, social, economic, and technical sin.
#11 en mi campo también decimos que los mejores controladores aéreos son los que además son pilotos. Saben qué pueden pedir y qué no a un avión y siempre tratan de poner las cosas fáciles en momentos difíciles.
Un apunte acerca de la estabilidad dinámica (a mis alumnos les costaba cogerlo a veces). Un avión dinámicamente estable es como una canica en un cuenco. Da igual dónde la coloques dentro del cuenco, se moverá, oscilará, pero siempre terminará en el mismo sitio. El fondo.
Esto era fácil de ver en las clases prácticas. Si dejas una Cessna 172 virando con el morro hacia arriba, o en pérdida (Stall), o con morro abajo exagerado, o incluso en barrena y después sueltas los mandos, siempre terminará igual, volando recto y nivelado. Perderá más o menos altura, quizá entre en sobre velocidad, pero es un diseño estable y la teoría y la práctica dicen que si sueltas los mandos terminarás volando recto y nivelado.
Los aviones comerciales deberían hacer lo mismo, pero a ver quién se atreve a probar...
El fondo de la cuestión está en qué la agencia americana de seguridad aérea ha dejado en manos de una compañía privada un control de seguridad para tener menos costes y sea más rápido y ágil todos los textos guay esto demuestra que cuando dejas todo en manos del mercado y no hay regulación solo puede ir a peor
El ejemplo del piloto con el perro en cabina
es magistral.Segun los "expertos"el software controlará todo,el piloto animará a pasajeros dando seguridad presencial y el perro impedirá a este que toque ningún mando.
Luego llegan los problemas y se acaba el cuento del piloto,perro y pasajeros.
En todos los relatos que he leído, se omite una parte que creo que es bastante importante en el caso de Ethiopian, y es que se estrellaron entre 470 y 550 nudos (knots) IAS.
No dudo de que el motor eléctrico pudiera ajustar el estabilizador, pero no hay persona humana que pueda moverlo a esas velocidades. Un grave error en ese accidente es que hacía ya rato que havían superado la velocidad máxima permitida y esto hacía que la fuerza sobre los estabilizadores fuera superior a la tarada en diseño. Vamos, que en esa situación, los pilotos se olvidaron de ajustar el throttle (si estás bajando, no vayas a máxima potencia, coñe) dentro de los límites, eso los hubiese hecho bajar más lento, dar más tiempo y muy posiblemente permitir un leve ajuste manual, que aún les daría un poco más de tiempo, como sus dos intentos previos.
Tampoco los pilotos, en su último intento, en dónde dieron corriente al motor del estabilizador, fueron capaces de pensar que cada vez que mandaban subir el morro con el estabilizador, el MCAS se deshabilitaba durante unos segundos, y que si ellos insistían, el avión se estaba dejando subir. Os recuerdo que hay una indicación para la posición del trim en la cabina y se puede saber y ver si con los selectores, está subiendo o bajando, y que existen tanto el pilot flying como el pilot monitoring, que es ese su cometido. Quisieron usar los motores pues no podían con la mano, pero sentenciaron su suerte al no insistirle periódicamente al avión.
Si fuera por mí, no homologaría ningún vehículo o aeronave sin que el código fuente no se hubiese puesto a disposición de la FAA e ICAO con anterioridad. Me vendes una caja negra que dices que funciona (y el DER lo confirma) y te la metes dónde te quepa, o código, o plános, o esquemas o la puerta. Estaría muy bien que una situación como ésta del MCAS sentenciara al software life-critical a dejar de ser oscuro/cerrado, por lo menos ante las autoridades, que serían las responsables de jugársela de verdad en cuándo lo autorizaran/homologaran.
#14 la FAA no debería haber dejado a su antojo la certificación a Boeing, Big strike no.4
Boeing tenía que haber explicado correctamente cómo desactivar el sistema en training y cursos de reciclaje, Big strike no.5
Boeing y FAA tenían que haberse asegurado que la directiva de aeronavegabilidad tras el primer accidente explicaba la casuística y tenía en cuenta toda la envolvente de vuelo (a alta velocidad es casi imposible mover el trim manual, que fue lo que pasó en el 2° accidente), Big strike no.6
#26 nunca se mete un A320 en barrena, o en deep Stall, o en un upset recovery. Son conceptos teóricos. Los pilotos de pruebas sí meten en pérdida, paran motores, etc. Con lo que tienen todo mi respeto.
#31 cierto los americanos la cagaronco. La idea siempre de desregularización todo y ahorro de costes ... Lo que.me da más rabia es que en este caso dólar invertido son vidas .... Que no fallecen. Pero desde que lo dejas todo en manos privadas ocurre esto... Por eso me chirría cuando oigo que sea el mercado quien se autogestione sin control gubernamental
![Análisis del 737 MAX por un programador (y piloto) [ENG]](https://peta.meneame.net/backend/media?type=link&id=3115403&version=0&ts=1555660266&image.jpeg)
Muchas veces falta experiencia real en la gente que diseña los sistemas.
En mi trabajo (un departamento de estudios) nos lo encontramos muy habitualmente , los técnicos son teóricos y no han estado en campo en su vida. Por eso los mejores técnicos son los que llevan las dos vertientes.
Si en una película hubiera visto al piloto protagonista luchando contra la máquina haciendo fuerza con el timón mientras la máquina tiraba en la dirección opuesta me habría levantado una sonrisa y hubiera pensado que era infantil y poco creíble representar la lucha entre el hombre y la máquina de esa forma.
No creo que a los pilotos que se encontraron en esa situación real les levantase sonrisa alguna.
#0 Gracias por subirlo.
So Boeing produced a dynamically unstable airframe, the 737 Max. That is big strike No. 1. Boeing then tried to mask the 737’s dynamic instability with a software system. Big strike No. 2. Finally, the software relied on systems known for their propensity to fail (angle-of-attack indicators) and did not appear to include even rudimentary provisions to cross-check the outputs of the angle-of-attack sensor against other sensors, or even the other angle-of-attack sensor. Big strike No. 3.
None of the above should have passed muster. None of the above should have passed the “OK” pencil of the most junior engineering staff, much less a DER.
That’s not a big strike. That’s a political, social, economic, and technical sin.
Moraleja... a lo mejor el volante no debe de desaparecer en los coches?
Supongo que habrá algún que otro fallo, así que para los talibanes del correctismo iros de semana santa.
Esto era fácil de ver en las clases prácticas. Si dejas una Cessna 172 virando con el morro hacia arriba, o en pérdida (Stall), o con morro abajo exagerado, o incluso en barrena y después sueltas los mandos, siempre terminará igual, volando recto y nivelado. Perderá más o menos altura, quizá entre en sobre velocidad, pero es un diseño estable y la teoría y la práctica dicen que si sueltas los mandos terminarás volando recto y nivelado.
Los aviones comerciales deberían hacer lo mismo, pero a ver quién se atreve a probar...
es magistral.Segun los "expertos"el software controlará todo,el piloto animará a pasajeros dando seguridad presencial y el perro impedirá a este que toque ningún mando.
Luego llegan los problemas y se acaba el cuento del piloto,perro y pasajeros.
No dudo de que el motor eléctrico pudiera ajustar el estabilizador, pero no hay persona humana que pueda moverlo a esas velocidades. Un grave error en ese accidente es que hacía ya rato que havían superado la velocidad máxima permitida y esto hacía que la fuerza sobre los estabilizadores fuera superior a la tarada en diseño. Vamos, que en esa situación, los pilotos se olvidaron de ajustar el throttle (si estás bajando, no vayas a máxima potencia, coñe) dentro de los límites, eso los hubiese hecho bajar más lento, dar más tiempo y muy posiblemente permitir un leve ajuste manual, que aún les daría un poco más de tiempo, como sus dos intentos previos.
Tampoco los pilotos, en su último intento, en dónde dieron corriente al motor del estabilizador, fueron capaces de pensar que cada vez que mandaban subir el morro con el estabilizador, el MCAS se deshabilitaba durante unos segundos, y que si ellos insistían, el avión se estaba dejando subir. Os recuerdo que hay una indicación para la posición del trim en la cabina y se puede saber y ver si con los selectores, está subiendo o bajando, y que existen tanto el pilot flying como el pilot monitoring, que es ese su cometido. Quisieron usar los motores pues no podían con la mano, pero sentenciaron su suerte al no insistirle periódicamente al avión.
Si fuera por mí, no homologaría ningún vehículo o aeronave sin que el código fuente no se hubiese puesto a disposición de la FAA e ICAO con anterioridad. Me vendes una caja negra que dices que funciona (y el DER lo confirma) y te la metes dónde te quepa, o código, o plános, o esquemas o la puerta. Estaría muy bien que una situación como ésta del MCAS sentenciara al software life-critical a dejar de ser oscuro/cerrado, por lo menos ante las autoridades, que serían las responsables de jugársela de verdad en cuándo lo autorizaran/homologaran.
/rant
Boeing tenía que haber explicado correctamente cómo desactivar el sistema en training y cursos de reciclaje, Big strike no.5
Boeing y FAA tenían que haberse asegurado que la directiva de aeronavegabilidad tras el primer accidente explicaba la casuística y tenía en cuenta toda la envolvente de vuelo (a alta velocidad es casi imposible mover el trim manual, que fue lo que pasó en el 2° accidente), Big strike no.6