Portada
mis comunidades
otras secciones
#6:
De un foro aeronáutico:
http://pilotosdeiberia.foroactivo.com/t131p150-accidente-a400m-en-lezl#2509
“…/…Pero su confirmación implícita de que la avería tuvo su origen en el programa informático ECU, encargado de regular la potencia de los motores en función de las señales que le envía el piloto, apunta a un error humano, probablemente a que ese programa no se cargó adecuadamente en el A400M que se estrelló…/…”.
ABSOLUTAMENTE FALSO !!!!
1º porque el software es alemán, viene de Alemania, junto con los motores. Todas ellos han sido controladas y verificadas posteriormente y vienen con su correspondiente "for one"
2º porque todo el material en rango de seguridad 1 (los motores y sus sistemas electrónicos de gestión lo son) se monta "POKE YOKE" es decir solo se pueden hacer DE UNA SOLA Y ÚNICA FORMA. Es decir que el ensamblaje SE MONTA CON SU "FOR ONE" ANTERIOR (es decir controlado y verificado por el anterior para el siguiente que corresponda. Además todas las operaciones de ensamblaje están controladas por video cámaras.
3º porque el diseño prevé 4 ordenadores independientes de gestión de los motores con su correspondiente software aplicado desde Alemania, concretamente BREMEN y con su correspondiente "FOR ONE". El responsable de ello es el SAC (Servicio de Aseguramiento de Calidad) de los motores y el software de Bremen.
Ahora que ya es de casi vox pública, a mi conocimiento, que es de primerísima mano, puedo decir que el origen está en la programación del software, entre otras consecuencias del mismo, han sido unas sondas que regulan la potencia de los motores que entre otras cosas disminuyen la potencia aplicada a los 15.000 pies y resulta que debido a una actualización anterior, en Alemania no aquí, ni en el ensamblaje porque no es posible (poke yoke), a alguien se le perdió un “cero” y el sistema cortó potencia a 1.500 pies…! La cuestión está en la validación del software por parte del SAC correspondiente. En absoluto la planta de ensamblaje de Sevilla.
Finalmente respecto al tema del ensamblaje, a continuación para conocimiento, ilustro brevemente el proceso general con que se lleva a cabo todo ensamblaje.
Por ejemplo, el hangar correspondiente a la pieza considerada parece más bien un quirófano, ambiente controlado de temperatura y humedad, un panel vertical contiene cada una de las piezas a ensamblar, de manera que al terminar el panel debe estar vacio, en el caso de tener que poner remaches, un puntero laser señala el punto exacto donde efectuar el primer taladro (verificado por el operario en cuestión), en todo momento (arriba y/o abajo) existen “a mano” aparatos de medida, numerados y verificados periódicamente para su uso eventual. Luego, es el robot, una vez situado vía laser el primero de los remaches, por ejemplo, realiza el resto de los remaches necesarios, siempre verificados por el operario e incluso controlados vía cámara focal que comprueba a su vez la exactitud de la operación. Luego todo es verificado por un controlador de calidad y posteriormente por el responsable del SAC correspondiente. Sólo después se sella el informe y queda validado, "For One".
En la construcción aeronáutica, la descentralización de tareas conlleva, que el anterior asegure al siguiente la validación de su parte, de manera que la FAL sólo haga eso el ensamblaje de las partes. Cargar sobre la FAL una validación errónea más arriba del proceso es inadmisible
Nada se monta en un avión si no hay una prueba funcional realizada con un equipo calibrado y realizado por una persona capacitada que evidencie formación en un centro homologado con profesores titulados.
Respecto a las pruebas funcionales en tierra de los motores, que siguen un procedimiento concreto, al parecer al simular el corte a los 15000 pies los motores se comportaron normalmente…. Ya que estaban “cortados por software desde 1500pies” ! y nadie pudo sospechar que el software estuviera incorrecto, puesto que eso debía ya estar controlado, verificado y validado anteriormente… y no en Sevilla.
Lo que pasa es que los alemanes acarrean siempre mucho retraso en la entrega de los fuselajes y motores, góndolas etc. y desde hace mucho tiempo hay una pugna entre los que quieren trasladar a Sevilla parte del programa para disminuir los retrasos y otros que se quieren llevar la FAL (final Assembly Line) fuera de Sevilla. De hecho la Dirección va a trasladar parte de ello a Sevilla para disminuir los retrasos y otros no quieren… de ahí la disparidad de declaraciones.
Una cosa puedo asegurar, en el accidente, el ensamblaje y el correspondiente Control de Calidad de Sevilla no puede estar en entredicho porque es imposible.
Lo que pasa es que como el Pisuerga pasa por Valladolid… pues… ascua a mi sardina… demasiadas injerencias político militares en el programa… como el dinero no les cuesta…
Saludos
P.D. hasta ahora he querido guardar prudencia pero visto que ya se quiere envenenar la cosa (no se miente pero se tergiversa la realidad) y es pública que la causa fue el sistema informático de gestión electrónica de los motores. También tengo las conversaciones entre el 400 y el ATC... muy ilustrativas... pero eso no puedo divulgarlo, es delito.
http://pilotosdeiberia.foroactivo.com/t131p150-accidente-a400m-en-lezl#2509
“…/…Pero su confirmación implícita de que la avería tuvo su origen en el programa informático ECU, encargado de regular la potencia de los motores en función de las señales que le envía el piloto, apunta a un error humano, probablemente a que ese programa no se cargó adecuadamente en el A400M que se estrelló…/…”.
ABSOLUTAMENTE FALSO !!!!
1º porque el software es alemán, viene de Alemania, junto con los motores. Todas ellos han sido controladas y verificadas posteriormente y vienen con su correspondiente "for one"
2º porque todo el material en rango de seguridad 1 (los motores y sus sistemas electrónicos de gestión lo son) se monta "POKE YOKE" es decir solo se pueden hacer DE UNA SOLA Y ÚNICA FORMA. Es decir que el ensamblaje SE MONTA CON SU "FOR ONE" ANTERIOR (es decir controlado y verificado por el anterior para el siguiente que corresponda. Además todas las operaciones de ensamblaje están controladas por video cámaras.
3º porque el diseño prevé 4 ordenadores independientes de gestión de los motores con su correspondiente software aplicado desde Alemania, concretamente BREMEN y con su correspondiente "FOR ONE". El responsable de ello es el SAC (Servicio de Aseguramiento de Calidad) de los motores y el software de Bremen.
Ahora que ya es de casi vox pública, a mi conocimiento, que es de primerísima mano, puedo decir que el origen está en la programación del software, entre otras consecuencias del mismo, han sido unas sondas que regulan la potencia de los motores que entre otras cosas disminuyen la potencia aplicada a los 15.000 pies y resulta que debido a una actualización anterior, en Alemania no aquí, ni en el ensamblaje porque no es posible (poke yoke), a alguien se le perdió un “cero” y el sistema cortó potencia a 1.500 pies…! La cuestión está en la validación del software por parte del SAC correspondiente. En absoluto la planta de ensamblaje de Sevilla.
Finalmente respecto al tema del ensamblaje, a continuación para conocimiento, ilustro brevemente el proceso general con que se lleva a cabo todo ensamblaje.
Por ejemplo, el hangar correspondiente a la pieza considerada parece más bien un quirófano, ambiente controlado de temperatura y humedad, un panel vertical contiene cada una de las piezas a ensamblar, de manera que al terminar el panel debe estar vacio, en el caso de tener que poner remaches, un puntero laser señala el punto exacto donde efectuar el primer taladro (verificado por el operario en cuestión), en todo momento (arriba y/o abajo) existen “a mano” aparatos de medida, numerados y verificados periódicamente para su uso eventual. Luego, es el robot, una vez situado vía laser el primero de los remaches, por ejemplo, realiza el resto de los remaches necesarios, siempre verificados por el operario e incluso controlados vía cámara focal que comprueba a su vez la exactitud de la operación. Luego todo es verificado por un controlador de calidad y posteriormente por el responsable del SAC correspondiente. Sólo después se sella el informe y queda validado, "For One".
En la construcción aeronáutica, la descentralización de tareas conlleva, que el anterior asegure al siguiente la validación de su parte, de manera que la FAL sólo haga eso el ensamblaje de las partes. Cargar sobre la FAL una validación errónea más arriba del proceso es inadmisible
Nada se monta en un avión si no hay una prueba funcional realizada con un equipo calibrado y realizado por una persona capacitada que evidencie formación en un centro homologado con profesores titulados.
Respecto a las pruebas funcionales en tierra de los motores, que siguen un procedimiento concreto, al parecer al simular el corte a los 15000 pies los motores se comportaron normalmente…. Ya que estaban “cortados por software desde 1500pies” ! y nadie pudo sospechar que el software estuviera incorrecto, puesto que eso debía ya estar controlado, verificado y validado anteriormente… y no en Sevilla.
Lo que pasa es que los alemanes acarrean siempre mucho retraso en la entrega de los fuselajes y motores, góndolas etc. y desde hace mucho tiempo hay una pugna entre los que quieren trasladar a Sevilla parte del programa para disminuir los retrasos y otros que se quieren llevar la FAL (final Assembly Line) fuera de Sevilla. De hecho la Dirección va a trasladar parte de ello a Sevilla para disminuir los retrasos y otros no quieren… de ahí la disparidad de declaraciones.
Una cosa puedo asegurar, en el accidente, el ensamblaje y el correspondiente Control de Calidad de Sevilla no puede estar en entredicho porque es imposible.
Lo que pasa es que como el Pisuerga pasa por Valladolid… pues… ascua a mi sardina… demasiadas injerencias político militares en el programa… como el dinero no les cuesta…
Saludos
P.D. hasta ahora he querido guardar prudencia pero visto que ya se quiere envenenar la cosa (no se miente pero se tergiversa la realidad) y es pública que la causa fue el sistema informático de gestión electrónica de los motores. También tengo las conversaciones entre el 400 y el ATC... muy ilustrativas... pero eso no puedo divulgarlo, es delito.
#9:
#7 Es más cuando se programa una aplicación debes saber de que va dicha aplicación
Discrepo, es imposible que tengas un conocimiento profundo sobre todos los sectores para los cuales desarrollas software. Si eso fuese así, yo a parte de Ingeniero Informático tendría que tener la carrera de Farmacia, la de Medicina e incluso la de Químico.
Cuando yo desarrollo algo para sector médico, me ciño a las formulas y datos que me facilitan, yo no se si 200mg de un medicamento concreto es un mucho o poco, o si tener X cantidad de glóbulos blancos es bueno o malo, eso lo sabe el medico o el farmacéutico, no el desarrollador.
Discrepo, es imposible que tengas un conocimiento profundo sobre todos los sectores para los cuales desarrollas software. Si eso fuese así, yo a parte de Ingeniero Informático tendría que tener la carrera de Farmacia, la de Medicina e incluso la de Químico.
Cuando yo desarrollo algo para sector médico, me ciño a las formulas y datos que me facilitan, yo no se si 200mg de un medicamento concreto es un mucho o poco, o si tener X cantidad de glóbulos blancos es bueno o malo, eso lo sabe el medico o el farmacéutico, no el desarrollador.
#35:
#34 "Y lo de "prueba funcional realizada con un equipo calibrado y realizado por una persona capacitada que evidencie formación en un centro homologado con profesores titulados."
suena a chiste."
Como todo el mundo sabe, las pruebas se hacen con aparatos descalibrados y los utiliza cualquier persona sin estudios, que no sabe ni para qué sirve cada botón del aparato. Y la mínima preparación se hace en la parroquia, después de la catequesis.
Tu comentario sí que es de chiste.
suena a chiste."
Como todo el mundo sabe, las pruebas se hacen con aparatos descalibrados y los utiliza cualquier persona sin estudios, que no sabe ni para qué sirve cada botón del aparato. Y la mínima preparación se hace en la parroquia, después de la catequesis.
Tu comentario sí que es de chiste.
#19:
Yo llevo toda la vida haciendo programas, de los que pierden dinero y no vidas cuando fallan, y a pesar de mi desconocimiento de este tipo de entorno de sofware se me hace muy raro diseñar un sistema que no permita al piloto un override completo.
Si yo tuviese que hacer un programa de esos y mi programa decidiese que los motores no deben subir de potencia pero el piloto le da al override, pues mi programa pitaría, encendería leds y se cagaría en su madre pero le daría el control al piloto. Si piensas que tu programa siempre va a ser más listo que el usuario y no se va a equivocar, vas de culo.
Si yo tuviese que hacer un programa de esos y mi programa decidiese que los motores no deben subir de potencia pero el piloto le da al override, pues mi programa pitaría, encendería leds y se cagaría en su madre pero le daría el control al piloto. Si piensas que tu programa siempre va a ser más listo que el usuario y no se va a equivocar, vas de culo.
Comentarios
De un foro aeronáutico:
http://pilotosdeiberia.foroactivo.com/t131p150-accidente-a400m-en-lezl#2509
“…/…Pero su confirmación implícita de que la avería tuvo su origen en el programa informático ECU, encargado de regular la potencia de los motores en función de las señales que le envía el piloto, apunta a un error humano, probablemente a que ese programa no se cargó adecuadamente en el A400M que se estrelló…/…”.
ABSOLUTAMENTE FALSO !!!!
1º porque el software es alemán, viene de Alemania, junto con los motores. Todas ellos han sido controladas y verificadas posteriormente y vienen con su correspondiente "for one"
2º porque todo el material en rango de seguridad 1 (los motores y sus sistemas electrónicos de gestión lo son) se monta "POKE YOKE" es decir solo se pueden hacer DE UNA SOLA Y ÚNICA FORMA. Es decir que el ensamblaje SE MONTA CON SU "FOR ONE" ANTERIOR (es decir controlado y verificado por el anterior para el siguiente que corresponda. Además todas las operaciones de ensamblaje están controladas por video cámaras.
3º porque el diseño prevé 4 ordenadores independientes de gestión de los motores con su correspondiente software aplicado desde Alemania, concretamente BREMEN y con su correspondiente "FOR ONE". El responsable de ello es el SAC (Servicio de Aseguramiento de Calidad) de los motores y el software de Bremen.
Ahora que ya es de casi vox pública, a mi conocimiento, que es de primerísima mano, puedo decir que el origen está en la programación del software, entre otras consecuencias del mismo, han sido unas sondas que regulan la potencia de los motores que entre otras cosas disminuyen la potencia aplicada a los 15.000 pies y resulta que debido a una actualización anterior, en Alemania no aquí, ni en el ensamblaje porque no es posible (poke yoke), a alguien se le perdió un “cero” y el sistema cortó potencia a 1.500 pies…! La cuestión está en la validación del software por parte del SAC correspondiente. En absoluto la planta de ensamblaje de Sevilla.
Finalmente respecto al tema del ensamblaje, a continuación para conocimiento, ilustro brevemente el proceso general con que se lleva a cabo todo ensamblaje.
Por ejemplo, el hangar correspondiente a la pieza considerada parece más bien un quirófano, ambiente controlado de temperatura y humedad, un panel vertical contiene cada una de las piezas a ensamblar, de manera que al terminar el panel debe estar vacio, en el caso de tener que poner remaches, un puntero laser señala el punto exacto donde efectuar el primer taladro (verificado por el operario en cuestión), en todo momento (arriba y/o abajo) existen “a mano” aparatos de medida, numerados y verificados periódicamente para su uso eventual. Luego, es el robot, una vez situado vía laser el primero de los remaches, por ejemplo, realiza el resto de los remaches necesarios, siempre verificados por el operario e incluso controlados vía cámara focal que comprueba a su vez la exactitud de la operación. Luego todo es verificado por un controlador de calidad y posteriormente por el responsable del SAC correspondiente. Sólo después se sella el informe y queda validado, "For One".
En la construcción aeronáutica, la descentralización de tareas conlleva, que el anterior asegure al siguiente la validación de su parte, de manera que la FAL sólo haga eso el ensamblaje de las partes. Cargar sobre la FAL una validación errónea más arriba del proceso es inadmisible
Nada se monta en un avión si no hay una prueba funcional realizada con un equipo calibrado y realizado por una persona capacitada que evidencie formación en un centro homologado con profesores titulados.
Respecto a las pruebas funcionales en tierra de los motores, que siguen un procedimiento concreto, al parecer al simular el corte a los 15000 pies los motores se comportaron normalmente…. Ya que estaban “cortados por software desde 1500pies” ! y nadie pudo sospechar que el software estuviera incorrecto, puesto que eso debía ya estar controlado, verificado y validado anteriormente… y no en Sevilla.
Lo que pasa es que los alemanes acarrean siempre mucho retraso en la entrega de los fuselajes y motores, góndolas etc. y desde hace mucho tiempo hay una pugna entre los que quieren trasladar a Sevilla parte del programa para disminuir los retrasos y otros que se quieren llevar la FAL (final Assembly Line) fuera de Sevilla. De hecho la Dirección va a trasladar parte de ello a Sevilla para disminuir los retrasos y otros no quieren… de ahí la disparidad de declaraciones.
Una cosa puedo asegurar, en el accidente, el ensamblaje y el correspondiente Control de Calidad de Sevilla no puede estar en entredicho porque es imposible.
Lo que pasa es que como el Pisuerga pasa por Valladolid… pues… ascua a mi sardina… demasiadas injerencias político militares en el programa… como el dinero no les cuesta…
Saludos
P.D. hasta ahora he querido guardar prudencia pero visto que ya se quiere envenenar la cosa (no se miente pero se tergiversa la realidad) y es pública que la causa fue el sistema informático de gestión electrónica de los motores. También tengo las conversaciones entre el 400 y el ATC... muy ilustrativas... pero eso no puedo divulgarlo, es delito.
#6 ingenuo. Mira que pensar que alguien en meneame va a reconocer que un error critico se puede dar en un pais serio en lugar de en españa...
#8 Pues lo siento porque, según mi experiencia, los alemanes también se equivocan... y los finlandeses, y los canadienses y los de burkina-faso. Cualquier proceso está expuesto a errores, véase la Ley de Murphy.
#10 Y los holandeses, los peores... aún no saben que hay que cumplir las leyes de la termodinámica los del departamento de termodinámica...
En serio, no somos los peores ni de lejos. Hay mucha basura en europa. Nos van a comer por los pies, China, Corea, Rusia, India, etc.
Pero bueno es lo que hay con los sistemas educativos elitistas y los mini salarios para ingenieros y científicos.
De momento parece ser que lo único que preocupa son los pitidos al himno (chinta, chinta...) y poco más.
#6 resumen los alemanes cometieron el fallo, y para cubrirse la responsabilidad le echaron la culpa a los ensambladores españoles, por algo es uno de los estados pigs...
#11 Si, saben que nos han labado el cerebro y pensamos que somos una mierda de país y ellos son super guais y nos tragamos todo lo que nos digan.
#11 Lo mismo hicieron con los pepinos españoles.
#6 Te he votado negativo por error... lo he compensado en tu siguiente comentario. Disculpa.
#6 Francamente, no lo entiendo. Tratándose de un Software de esa criticidad (entiendo que DAL A o, a lo sumo, DAL B) los requisitos de verificación y validación son de lo más exigentes. Tendría que haber pruebas unitarias de todas las líneas de código, pruebas de integración, etc, y esto se aplica a todas las actualizaciones del SW. ¿Cómo se les pudo pasar por alto algo así?
#6 👏 👏 👏 👏 👏 👏 👏 👏 👏
#6 Lo que comentas de " han sido unas sondas que regulan la potencia de los motores que entre otras cosas disminuyen la potencia aplicada a los 15.000 pies y resulta que debido a una actualización anterior, .... al parecer al simular el corte a los 15000 pies los motores se comportaron normalmente…. Ya que estaban “cortados por software desde 1500pies" no me encaja.
¿Por qué iba a cortar a 15.000 pies? Eso no tiene ningún sentido por mucho que lo hayas adornado. Ummmmmm.....
Y lo de "prueba funcional realizada con un equipo calibrado y realizado por una persona capacitada que evidencie formación en un centro homologado con profesores titulados."
suena a chiste.
Yo de todas formas independientemente de quién sea la culpa habría cancelado el programa hace siglos. Es un gasto innecesario y un capricho como el AVE o las radiales y tantos otros disparates que están haciendo las empresas de ingeniería con amigos en la capital. El futuro de la aviación militar pertenece a los mucho más baratos y eficaces drones. Pero bueno, como las empresas implicadas vivís del cuento y tenéis barra libre para gastar pues nada... a gastar se ha dicho.
No te preocupes que una buena juerga finiquitada en un puticlub de la Castellana curan todas las heridas. Luego los alumnos de primaria se quedarán sin becas de comedor escolar pero los cientos de millones tirados a la basura en avioncitos de guerra están asegurados.
#34 "Y lo de "prueba funcional realizada con un equipo calibrado y realizado por una persona capacitada que evidencie formación en un centro homologado con profesores titulados."
suena a chiste."
Como todo el mundo sabe, las pruebas se hacen con aparatos descalibrados y los utiliza cualquier persona sin estudios, que no sabe ni para qué sirve cada botón del aparato. Y la mínima preparación se hace en la parroquia, después de la catequesis.
Tu comentario sí que es de chiste.
#35 Todos los meneantes conocen España y todos los meneantes conocen el significado de "centro homologado con profesores titulados".
#34 No sabes nada del tema y acabas yéndote por los cerros de Úbeda... por mucho que lo hayas adornado.
#40 Poco, poco sé, he de admitirlo. Lo poco que sé es que los 10.000 millones pasaron a ser 30.000 millones y no se sabe muy bien para qué porque la ventaja estratégica en el campo de batalla de este cacharro es más bien ninguna. Y más teniendo en cuenta que hoy en día un misil inteligente o un dron acabaría con el en menos que canta un gallo. Si al menos fuera indetectable al radar pues aun tendría sentido este despilfarro de decenas de miles de millones pero basta ver el conflicto de Ucrania para ver como incluso un caza bombardero mucho más ágil y rápido es pan comido para un misil moderno.
Y también sé que por mucho menos podríamos tener sistemas electrónicos de detección de rostro en aeropuertos y aduanas ante el peligro real e inminente de atentados yihaidistas, escáneres para detectar armas ocultas, mejorar la inteligencia militar española o reforzar los sistemas de encriptación contra espionaje electrónico.
Pero bueno, si te llena el estómago perder el tiempo con estas tonterías, el problema ya no lo tienes tú, lo tenemos los demás.
#45 Teniendo en cuenta el nivel de los argumentos que tú has expuesto, y la base con que los expones (poco, poco sé, he de admitirlo #44), bastante tienes que se ha tomado la molestia de explicartelo todo cuidadosamente.
#34 El futuro de la aviación militar pertenece a los mucho más baratos y eficaces drones.
El A400M es un avión de transporte que sirve para llevar material y personal de un sitio a otro, cosa que un dron no puede hacer.
Salvo que tu idea sea que con un dron matas a todos los malos y así no hay que llevar nada a ningún sitio
#41 "cosa que un dron no puede hacer."
Así, con argumentos sólidos, porque yo lo valgo.
#45 ¿Existe algún dron que sea capaz de transportar tropas y material?.
#6 sinceramente intentar vender que todo el problema es que un programador se olvidó de un cero no cuela... me da igual que sea alemán o español y me da igual que seo cierto o falso. En todos los sistemas de software complejos hay fallos comos estos a decenas y no deberían explicar que un avión se caiga en un vuelo de pruebas, vuelo donde precisamente se comprueba que los fallos que aún no están corregidos permiten un funcionamiento normal y si el funcionamiento es anormal ahí está el piloto para tomar el control y evitar que el avión caiga.
Que un fallo de software aparentemente tan evidente no sea detectado hasta llegar a un vuelo de pruebas más o menos rutinario antes de entregar un avión no lo entiendo, que un piloto no pueda tomar el control manual de un aparato que demuestra un funcionamiento anómalo en un vuelo de pruebas tampoco lo entiendo, y así podríamos seguir con una lista más bien larga, que supongo se irá esclareciendo
#51 Pues posiblemente ése sea el fallo de fondo de Airbus, el exceso de automatización y la pérdida del control manual.
¿Entoces ha fallado el software Aleman y no los operarios Españoles?
Que alguien con conocimientos lo aclare.
#1 Fue un fallo en cadena, se saltaron muchos protocolos por las prisas:
El accidente del A400M, un fallo en cadena “desde Alemania a Sevilla”
El accidente del A400M, un fallo en cadena “desde ...
elconfidencial.comEl problema con los motores se podría haber detectado.
#3 "El problema con los motores se podría haber detectado", o no. Me quedo con esto “Lo que realmente hay es una guerra interna de Alemana y Francia con España” y deduzco que el fallo fue de software, o no.
#4 "Si el avión hubiera realizado el rodaje de los motores a alta velocidad en tierra previo al primer vuelo los motores se habrían paralizado antes de que volara". Lo dice un senior manager de Airbus de Sevilla.
#5 Lo que se conoce como una "prueba de motor" entiendo.
#3 Entonces el fallo está en saltarse los protocolos y el responsable es quien tomó esa decisión.
#1 Seguro que nadie apretó el lock?
Yo llevo toda la vida haciendo programas, de los que pierden dinero y no vidas cuando fallan, y a pesar de mi desconocimiento de este tipo de entorno de sofware se me hace muy raro diseñar un sistema que no permita al piloto un override completo.
Si yo tuviese que hacer un programa de esos y mi programa decidiese que los motores no deben subir de potencia pero el piloto le da al override, pues mi programa pitaría, encendería leds y se cagaría en su madre pero le daría el control al piloto. Si piensas que tu programa siempre va a ser más listo que el usuario y no se va a equivocar, vas de culo.
Sin ser ingeniero, aventuro la siguiente hipótesis.. la triple "P"... prisas, plazos y plaf...
Se monta el avión con prisas, esto implica saltarse protocolos base de comprobación. Luego, el software (como apunta #19); se carga el mismo que en los simuladores (total es el que funciona o es el que tienen, da igual. Pero amigo, este software lleva un subprograma secundario que en caso de problemas que detecte apaga el motor para evitar "daños
económicos" y, por supuesto, nadie cae en ello). El piloto hace sus comprobaciones "según manual", y todo ok.. va y despega el avión - a partir de aquí, puesss.... fallo en un motor, este se para, el resto ven fallo de estabilidad, sobrecalentamiento - lo que sea... y se van apagando uno tras otro. Y todo por un tema meramente de plazos.Desde aquí, mi reconocimiento al piloto y a la tripulación que con su sacrificio - salvaron vidas.
#19 Por lo que he oído en la radio este mediodía, Airbus ha tomado esa decisión a raíz de estas noticias: en lugar de decidir el software, le devuelven el control al piloto.
Vamos, que sí, que le habían dado las llaves al programa. Ufff
#23
#19 Lo que pasa es que los aviones modernos ya no tienen ni palanca de mandos. Antes el piloto gobernaba el avión, ahora el avión es quien gobierna al piloto.
Menos mal que fué en Sevilla la congelación.
Que me corrija un ingeniero si peco de demasiado osado, pero que te fallen 3 motores de 4 apunta a error de diseño, no fallo humano. Incluso si es un fallo humano, un buen diseño lo tienen en cuenta.
Hay mucho empresario que cuando gana dinero es por su mérito, y cuando lo pierde es culpa de los trabajadores.
Solo pido un poco de coherencia, que lo normal es que pongan al currito de turno de culpable mientras los enchufados en puestos de decisión se lavan las manos.
¿Os acordáis de las cajabancos? Pues ahí culpan a los comerciales de los impagos, quienes en su dia eran los niños mimados por sus éxitos de ventas. Como lo oyen, los directivos de Unicaja se lavan las manos y dicen que la culpa de la morosidad es de los directores y comerciales que cerraban operaciones.
#30 Me he dejado un en mi comentario, sorry.
En cuanto a lo del software, yo habría dejado uno de cada lado, desde luego.
#37 , no debería hacer falta, pero con la de trolls que hay por aquí, por no llamarles otra cosa, nunca se sabe si lo dicen en serio o no.
Y con respecto al software, yo también lo hubiera dejado uno a cada lado (de forma simétrica)
Es un poco raro que antes de poner el sistema en funcionamiento en un entorno real no hayan hecho simulaciones sobre el software para comprobar si está bien configurado todo.
A esto me refería con el tema de las responsabilidades en la noticia del otro día. Si es cierto que en vez de poner 15.000 pies alguien puso 1.500 cuando sabes que puede depender miles de vida de ti, la culpa es de quien no verificó que esos datos fuesen correctos. Es más cuando se programa una aplicación debes saber de que va dicha aplicación.
Salu2
#7 Es más cuando se programa una aplicación debes saber de que va dicha aplicación
Discrepo, es imposible que tengas un conocimiento profundo sobre todos los sectores para los cuales desarrollas software. Si eso fuese así, yo a parte de Ingeniero Informático tendría que tener la carrera de Farmacia, la de Medicina e incluso la de Químico.
Cuando yo desarrollo algo para sector médico, me ciño a las formulas y datos que me facilitan, yo no se si 200mg de un medicamento concreto es un mucho o poco, o si tener X cantidad de glóbulos blancos es bueno o malo, eso lo sabe el medico o el farmacéutico, no el desarrollador.
#9 Hace años tuve una amiga que escribía software militar. Los protocolos eran que a los desarrolladores nunca debían saber que estaban programando ni para qué. Las especificaciones eran de funciones y capas de abstracción.
Luego existía otro estrato técnico que juntaba las piezas y ese estrato si sabía de qué iba la cosa pero no conocía los entresijos de la programación.
Parece ser que son protocolos de seguridad de manera a evitar posibles hacking en los sistemas.
#9 Ponte a diseñar un invernadero de kiwis (como hice yo), y el software de control del susodicho, sin saber la temperatura, la humedad relativa, cada cuanto hay que regar los kiwis, el control de la luz, el viento,... y a ver que sale. Y obviamente lo peor que podría pasar es que se me perdiesen los kiwis.
No me refiero a tener un control absoluto de la rama o del campo, respecto a la aplicación diseñada pero por ejemplo saber lo que se hace.
#17 Eso vale de excusa, pero si llega a pasar algo por culpa del software, las culpas irían para ella lo más seguro.
Salu2
En este foro no parece que importe qué fallo, sino echarle la culpa al alemán.
Así nos va y así nos ven.
#49 ¿Entiendes la diferencia entre "diseñar" y "construir"?
#47 eres adivino?
#47 Sí la entiendo. ¿Y tú la diferencia entre antes y después?
O sea, que sólo han fallado los motores 1,2,3 (no se sabe por qué) pero todo lo demás no, pues menos mal, es todo un alivio.
Ya puestos, también para aliviar, decir que, por suerte, el aparato sólo se puede destrozar por accidente una vez.
#20 Según la radio, el 4 tenía una versión antigua del programa. Y ya puestos, si no pusieran las torres de alta tensión en medio, el piloto habría conseguido aterrizar.
#26 Y porque estas compañias lo externalizan todo y no quieren gastarse un euro en actualizar sus herramientas de desarrollo. Si, vosotros reiros, cuando pregunteis con qué compilador estaba hecho el software y os digan que gcc 4.4.1. editado con vim
#27 Sólo por curiosidad, ¿de qué compañía hablas cuando estás diciendo "estas compañías"?
#26 Me parece que las torres de alta tensión estaban ahí desde hace mucho, tal vez no deberían haber hecho las pruebas tan cerca de unas torres de alta tensión.
Y, por otra parte, ¿a qué iluminado se le ocurrió la brillante idea de dejar un único motor con un software distinto al del resto? ¿A nadie se le ocurrió que si a ese motor le da por reaccionar de forma distinta al resto se pueden encontrar con un problema? Probablemente hubiera sido más seguro montar los motores 2 a 2 (2 con el software más moderno y 2 con el antiguo)
Primero te dicen que "ES METAFÍSICAMENTE IMPOSIBLE QUE EL MOTOR DE UN AVIÓN FALLE", con lo cual dejan enmudecida esa vocecita interior que desde lo más hondo de tí te dice que el avión es peligroso porque si sus motores fallan en el aire te vas al carajo.
Cuando el motor falla, y antes de que tu vocecita interior de la sensatez diga nada, todo son explicaciones y razonamientos llenos de terminología y acrónimos, que vuelven a distraer tu vocecita interior, y por los que nadie tuvo la culpa de que el motor fallara, excepto los pasajeros que se han matado.
Yo, por mi parte, seguiré haciendo caso a mi vocecita interior, que hasta ahora nunca me ha fallado.
#52 Hay aproximadamente 100.000 vuelos cada día que no se caen. Los accidentes salen en las noticias precisamente por que son tan rematadamente raros. De hecho la probabilidad de que un avión tenga un accidente es aproximadamente 1 entre 5 millones, lo que significa que si lo cogieras cada día tendrías un accidente al cabo de 7000 años.
Como quieras. Mejor no pienses en riesgos reales (pero menos espectaculares) como caerse por las escaleras o tener un infarto.
#53 Accidente de Spanair, accidente de Germanwings, y todos los accidentes de avión que han ocurrido hasta la fecha desde que se inventaron los aviones... no han ocurrido en intervalos de 7000 años entre uno y otro.
Como experto que soy en aeronáutica con varios años de experiencia en el diseño de aviones militares, creo que lo que pasó es todo culpa de la guerra ilegal en la que nos metió Aznar.
#12 Espera, voy a por palomitas y me sigues contando.