jueves, marzo 27, 2008

Hilbert y su gran conferencia

http://www.historiasdelaciencia.com/?p=36


Hilbert, además, tenía salidas geniales. Un día le invitaron a dar una conferencia sobre el tema que él quisiera. La conferencia creó una gran expectación ya que el tema elegido fue : “La prueba del último teorema de Fermat”. Llegó el día y dio la conferencia. La exposición fue muy brillante pero no tuvo nada que ver con el último teorema de Fermat. Cuando le preguntaron el porqué del título contestó: “Oh, el título era solamente para el caso de que el avión se estrellara”.

Inversión en ejecución concurrente Microsoft e Intel

Atención a la noticia...

http://www.infoq.com/news/2008/03/ParallelComputing


microsoft e intel invertirán 20millones de dólares para pensar como
hacer cosas que funcionen bien con muchos micropocesadores


1.- Ya hay una cosa fantástica y no han invertido tanto dinero Erlang

2.- Esto explica como escalan sus sistemas operativos (ver entrada anterior), de algún sitio
tienen que sacar el dinero

3.- Hablan de que el objetivo es chips con 1000 núcleos. Como
escarpias tengo los pelos de pensar lo que cuesta una licencia de
windows para ese chip tal y como escalan (nuevamente, ver entrada anterior)


Hace un par de días, el interesado era Java.
Vamos, que está de moda hablar de esto. Erlang lleva hablando del tema
muchos años.


curioso


pos ala, a comprar windows para 4 y 8 procesadores que necesitan
dinerito para invertir (en algo que ya existe, es libre y open source)

Informática paralela

Ayer pude constatar algo que era más que probable, aunque no me guste
nada reconocerlo



No sé si te comenté algo de que la ley de Moore está agotada o cambiada.
Los procesadores ya no son más rápidos, ahora incorporan más núcleos
Hay documentación y gráficas por todos lados

¿Están los sistemas operativos, los programas y los lenguajes de
programación preparados para aprovechar sistemas con muchos
procesadores?


Hace poco Java se apuntó a esa corriente. Erlang es la mejor situada.
Haskell también está muy bien, etc...



Resulta que lo que mejor escala en el paralelismo NO ES ERLANG, ni
haskell, ni ada, ni la próxima versión de Java, ni Scala...



ES... microsoft



Cuando hay que reconocerlo se reconoce y punto

Para algo tenía que servir tantos cerebros concretrados en una empresa

La labor de ingeniería paralela realizada por los técnicos de
microsoft es aplastante y muy fácil de demostrar. Voy a ello...



Recordatorio...

Ahora que los procesadores no suben velocidad y suben en núcleos, que
ya no se pueden comprar mononúcleos y dentro de poco ni con dos
núcleos, es el momento y los sistemas operativos de microsoft están
ahí


Demostración...

Te compras una máquina con uno o dos procesadores, y le puedes poner
un XP Home o equivalente Vista. Precio... 120€

Pero si te la compras con tres o cuatro procesadores... Server básico.
Precio 1000€

Y si te hacen la faena de ponerte un par de procesadores multinúcleo y
el sistema operativo suma más de cuatro y menos de nueve... 3000€







Conclusión



Queda demostrado que en la informática paraLELAs y paraLELOs, lo que
mejor escala son lo sistemas operativos de mocosoft



Quiero pensar que mocosoft cambiará su estrategia a la VISTA de la
moda multicores, pero seguro que ellos también se beneficiarán del
cambio a costa de los paraLELOs y paraLELAs que no quieren poner linux
en casa



¿y GNU/LiNUX, que opina de todo esto?

Que yo sepan no escala bien, no creo que te cueste diferente para 2
que para 8 o 16 procesadores

miércoles, marzo 26, 2008

Trabajando con sistemas críticos

Antes de empezar una aclaración.


NO PRETENDO DEMOSTRAR NADA EN ESTE CORREO.


Es frecuente que mucha gente utilice símiles para demostrar, pero eso es un error lógico total.


Los símiles sólo sirven para explicar.



Dicho esto...



Recordarás que el challenger explotó con 7 tripulantes a bordo.

Es más, había una importante expectación porque era la primera vez que había un tripulante civil (una profesora de colegio)

El tripulante civil, era claralmente una operación de marketing.

En un momento delicado, se pretendía demostrar que el transbordador era un gran invento.

Un camión de carga espacial, seguro y reutilizable.

El coste del trasbordador y los lanzamientos, eran bestiales
¿Estaba cumpliendo el carísimo transbordador la misión para la que fue desarrollado a un elevadísimo coste?

No.


Pero si se lanzaba con un civil, todo como si fuera una rutina y sin incidentes, podría parecer que casi.

Pero había algunos problemas.

Los ingenieros detectaron que había unas juntas tóricas (con forma de rosquilla) que tenían problemas.

Es más, sabían que tenían problemas gravísimos en condiciones de baja temperatura. No funcionaban como estaba previsto y las cosecuencias podían ser muy graves. (Para algo estarían estas juntas)

Un par de días antes del lanzamiento, un ingeniero jefe dijo que no de podría realizar.

La razón, es que tendrían una temperatura de un par de grados, y con ese frío, las juntas tóricas de los cohetes de combustible sólido...

Eso suponía para los gestores un revés importante.

Los gestores tenían la enorme responsabilidad de dar un empujon a la credibilidad y viabilidad de transbordador.

Pero los gestores no entendían nada de los argumentos de los ingenieros.

Así que cogieron al ingeniero jefe y lo presionaron para que firmara la aprobación para el lanzamiento.

Los gestores razonaron como sigue...

1.- Es importante realizar el lanzamiento según lo previsto

2.- Las juntas tóricas han tenido problemas en el pasado y todo fue bien. Lo que demuestra, que el sistema puede funcionar con este defecto en las juntas tóricas

3.- Los ingenieros son cobardes y excesivamente precavidos sin considerar en ningún momento otras cuestiones relevantes

El ingeniero firmó, por las presiones y considerando los argumentos de los gestores, por creer que quizá exageraba. El transbordador explotó matando a 7 personas



ERRORES EN RAZONAMIENTO DE LOS GESTORES

2.- Es un error lógico garrafal, deducir que algo no es importante porque no ha provocado un fallo en el pasado.
Eso no es científico, es un fallo muy grave que debe evitarse
Por dios, que nadie olvide que un defecto generá un fallo más tarde o temprano si le das las oportunidades suficientes. Es obvio

3.- Si no confías en la opinión de los ingenieros, no montes el sistema.
No olvidemos nunca que no sólo es importante la probablidad del fallo. Hay que valorar la unión de la probabilidad del fallo con el perjuicio del mismo


Otro símil clásico... Una pistola con 1 bala en un tambor de 6... tienes una probabilidad de pegarte un tiro en la ruleta rusa de 1/6. Es pequeña, ¿pero alguien en su sano juicio asumiría el riesgo?

No, porque no sólo es importante la probabilidad de que ocurra

Y ya sólo como curiosidad

En la comisión de investigación, detectaron más fallos importantes, empezando por dificultades burocráticas que incomunicaban ingenieros y mecánicos con gestores.

Fue difícil descubrir la causa, aunque había ingenieros muy afectados por lo ocurrido (ellos lo sabían)

Sólo se pudo indicar esta causa porque uno de los que formaban la comisión, era cabezota e intocable. Richard Feynman, premio de física en el 65 y uno de los mejores profesores de la historia

Dijo que si no se incluían sus observaciones, aunque fuera en un anexo, no firmaría y lo denunciaría en los medios de comunicación



CONCLUSIÓN...

¿APRENDIERON LA LECCIÓN?


SÍIIII
Ya sabes que hace poco, explotó en la reentrada otro transbordador

Este era un transbordador "reciclado".

Ya había terminado su vida útil según los ingenieros, pero eso es lo de menos.

Lo importante, es que explotó porque en el lanzamiento, el desprendimiento de un aislante blando y ligero del tanque central, provocó una avería en la nave.


TODOS SABÍAN QUE ERA FRECUENTE DESPRENDIMIENTOS DE ESTOS MATERIALES DURANTE EL LANZAMIENTO.

Y algunos pensaron... El que suceda desde el principio y con frecuencia, demuestra que no es peligroso. Nunca pasa nada.

¿Esto demuestra que yo no soy paranoico y pefeccionista?


NOOOOO

Pero espero que se entienda mejor mi punto de vista

Me considero no pefeccionista y podría detallar cientos de razones que lo avalan (de forma concreta en nuestro sistema).

Te sorprendería la cantidad de tornillos que están flojos en el sistema

El que se haya diseñado un sistema resistente a fallos, con ajuste continuo, no significa que pueda resistir cualquier cosa en todas condiciones.

El que defectos y fallos no provoquen incidentes graves, no demuestra que no sean importantes

¿De que sirve un sistema predictivo y dinámico si ignoramos sus advertencias y no realizamos los ajustes?

Antes de acusar de perfeccionismo hagamos un ejercicio...

¿Qué riesgos estáis dispuestos a asumir?

Valorad el coste de la reducción de esos riesgos con dichas situaciones

¿Cómo podéis acusarme por un lado de perfeccionista y por otro protestar (en muchas ocasiones) de que el sistema ha fallado por principio?

No es raro recibir llamadas que nos dicen... "el sistema ha funcionado mal Y ME HE PILLADO".

Luego cuesta horas, muchas horas, analizar lo sucedido y lo mismo para explicarlo. En el 99% de los casos, se demuestra que no ha sido un fallo del sistema.

No entiendo como en ocasiones culpamos al sistema por principio, para empezar, y por otro lado decimos que se trata de ser perfeccionista.

Es contradictorio



Pedazo reflexión (por el tamaño)

Si quieres más información del tema del challenger, hay un libro llamado "que le importa lo que digan los demás" que tiene el informe de Richard Feynman
(Yo aprendí muchas cosas de este informe)



saludos

Ejecución paralela en Java 7



Para Java 7, que está previsto que venga en el 2009


Comentarios...

Ya no son sólo los de la programación declarativa, especialmente Erlang los que dicen que hay que prestar atención a la ejecución paralela

Dan los mismos argumentos. La ley de Moore ha cambiado. Ahora los procesadores no son más rápidos, ahora incluyen más núcleos

Hablan de dividir los problemas recursivamente

De forma que los problemas más pequeños se puedan ejecutar en paralelo FORK

Y posteriormente combinar los resultados JOIN

Esta técnica la llaman FORK/JOIN

Para evitar la carga de la creación, destrucción y conmutación de threads, utilizan una piscina de threads donde distribuyen los trabajos.

El número de threads disponibles se ajustará al número de núcleos (más o menos)

Opinión subjetiva sin tener suficientes datos...

La idea parece chula y sencilla de utilizar, pero no confío que sea sencillo

Yo creo que este sistema, permitirá que algunos problemas se resuelvan de forma fácil y elegante.

Pero la mayoría de problemas, no serán triviales.

Es una mejora importante, quizá imprescindible, pero creo que utilizarla será un poco compleja y dificultará el diseño

Comprando con otros...

Erlang, está pensado desde el inicio para tabajar no sólo de forma concurrente, también de forma distribuida.

En erlang es natural tener muchos procesos (baratos) y además es muy fácil distribuir el programa. No es necesario pensar de otra forma


Scala

Probablemente Scala pueda aprovecharse mucho mejor de esta técnica que Java.

Si en Scala reduces la programación imperativa al mínimo y utilizas el modelo de actores (coordinación del paralelismo con paso de mensajes), el punto de partida es mucho mejor


Haskell

Como lenguaje declarativo, parte con una ventaja clara respecto a Java


pos eso

miércoles, marzo 19, 2008

El primer vuelo del Ariane-5

http://www.historiasdelaciencia.com/?p=249

Publicado el 9 de Febrero de 2007 en Historias de la ciencia por omalaled
Tiempo aproximado de lectura: 3 minutos y 12 segundos
Este artículo se ha visitado: 626 veces

El artículo de hoy está inspirado en uno que ya publicó Dan en su blog centpeus (blog en catalán) y del que ya os he hablado alguna vez, así que el mérito es enteramente de él. Yo, tan sólo, he retocado y añadido detalles.

La primera nave del Programa Mariner que llegó a Venus, el Mariner II, fue lanzada el 27 de agosto de 1962. Y si os preguntáis qué sucedió con el Mariner I os diré que cayó al mar inmediatamente después de despegar porque a alguien se le olvidó introducir un signo menos en el ordenador (dicen que fue un error al leerlo de la fórmula hecha a mano).

La NASA ha tenido bastantes fiascos posteriores debidos a fallos que podríamos calificar de “fácilmente evitables”. Uno de los mayores ridículos fue el perder una sonda que impactó contra la superficie de Marte porque se hicieron un lío entre una estación que expresaba las distancias en kilómetros y otra que lo hacía en millas.

Pero la ESA, la Agencia Espacial Europea, tampoco ha podido evitar unirse al espectáculo y el mayor y más sonado fue en el vuelo inicial del cohete Ariane-5, que estalló 39 segundos después del lanzamiento. Fue un golpe duro porque era el primer lanzamiento de la nueva generación de cohetes europeos, más grandes, más potentes y con más capacidad que los predecesores Ariane-4. El motivo del desastre fue ridículo: una de las unidades de 64 bits que controlaba la trayectoria hizo unos cálculos y emitió un número que envió a una unidad de 16 bits. Esta no pudo procesar el resultado porque el número era demasiado grande y simplemente ¡no cabía en 16 bits! Por lo tanto, hizo lo que hacen los ordenadores: dio un mensaje de error y se desconectó.

Había un sistema de emergencia que se puso en funcionamiento inmediatamente pero el software era idéntico al que había fallado, de forma que el error se repitió exactamente igual. La unidad también se desconectó, el cohete quedó sin control y adiós.

El problema con estas unidades fue que, en realidad aprovechaban el sistema operativo de los cohetes Ariane-4. Después de todo, aquel sistema había funcionado muy bien. Y si algo funciona correctamente lo mejor es no tocarlo (bien, esto es cierto a no ser que seas una multinacional de la informática que, por mantener el negocio, necesites vender cada 4 años un nuevo sistema operativo).

Pero, aun cuando el sistema iba muy bien por el Ariane-4, algunas cosas no servían para el Ariane-5 y esta era una de ellas.

La unidad que falló calculaba los desplazamientos horizontales del cohete y los técnicos no se debían preocupar por si daba un valor demasiado alto pues el Ariane-4 nunca se desplazaba tan deprisa. El problema era que el Ariane-5 era mucho más rápido y potente y sí que lo hacía. De forma que cuando el sistema detectó aquel desplazamiento lateral, no pudo calcularlo porque la realidad iba más allá de lo que en el diseño habían previsto (correctamente) que podía hacer un Ariane-4. En fin, que hizo que el ordenador central perdiera los datos de trayectoria del cohete y el desastre fue inevitable. La trayectoria no se pudo corregir de ninguna forma y al final empezó a ir demasiado “de lado”. Debido a esa inclinación (más de 20º), los propulsores se separaron de la etapa principal por efecto de las fuerzas aerodinámicas y se disparó el mecanismo de autodestrucción.

Y lo más irónico es que aquel sistema ya no hacía falta. La unidad que falló estaba diseñada por calcular los desplazamientos horizontales en los primeros segundos del lanzamiento, antes de que se estableciera el “modo de vuelo”, como si dijéramos cuando el cohete ya ha arrancado del todo.

Esto requería 40 segundos por los Ariane-4, pero sólo 3 segundos para el Ariane-5. De forma que el desastre pasó porque falló un procesador que, en realidad, ¡ya no servía para nada! Un curioso camino que empezó en un error al asumir que no hacía falta modificar el diseño de un programa informático y acabó en un fracaso de 7 mil millones de Euros.

Ya sabemos que no hay ningún sistema está 100% libre de errores pero, a veces, se pone de manifiesto de maneras bien espectaculares.

Moraleja: el “si funciona, no lo toques” no siempre es aplicable.

Fuentes:
“Astronomía”, Patrick Moore
http://centpeus.blogspot.com/2006/10/un-nmero-massa-gran.html
http://www.mononeurona.org/index.php?idnew=323
http://www.upv.es/satelite/trabajos/pract_9/kike/paginas/accid.htm

El Accidente del Columbia

http://es.geocities.com/fjcasadop/


El 1 de febrero de 2003, el telediario del mediodía nos sorprendía a muchos de nosotros con las imágenes, grabadas por un videoaficionado, del Columbia desintegrándose sobre el cielo de Texas, durante la maniobra de reentrada de la misión STS-107 del transbordador espacial norteamericano. El Columbia, el más veterano de la flota de transbordadores, contabilizaba con ésta un total de 28 misiones al espacio.



Casi de inmediato empezaron a surgir las primeras hipótesis sobre las causas del accidente, mostrándose unas imágenes tomadas durante el despegue de esta misión, en las que se observaba cómo un trozo del aislante que recubre gran el depósito central de propulsante se desprendía del mismo impactando sobre el ala izquierda del Columbia. Se planteaba que éste podía haber sido el origen del fallo, aunque al mismo tiempo se argumentaba que acontecimientos similares habían ocurrido en otros despegues sin que hubieran tenido el más mínimo efecto en la integridad del transbordador. De hecho, los técnicos de tierra habían observado el impacto y, tras varios días de debate, la conclusión oficial de la NASA era que no existía riesgo alguno, habiéndose proseguido la misión con normalidad.



Luego, como suele ocurrir, el accidente dejó de ser noticia, y la investigación sobre sus causas cayó en el olvido para el público en general.



Sin embargo, la investigación del accidente ha avanzado sin pausa en este tiempo, publicándose sus conclusiones el pasado mes de septiembre. El estudio ha sido exhaustivo: se han analizado uno a uno con gran detenimiento todos los datos (y son muchos) registrados por todos los sistemas de la nave a lo largo de la misión; se han observado una y otra vez los videos del despegue y las imágenes radar obtenidas durante la parte orbital de la misión; se han estudiado en detalle los restos minuciosamente recolectados a lo largo de varios estados; se han realizado múltiples ensayos de diferente tipo para intentar reproducir y validar las distintas hipótesis vertidas por el equipo de investigación sobre el desarrollo de los acontecimientos... Y como resultado de todo ello, la conclusión es que el desprendimiento y posterior impacto contra la parte inferior delantera del ala izquierda del transbordador de un trozo de espuma aislante desprendida del depósito ventral, fue el origen del daño que conduciría a la destrucción del vehículo durante la reentrada.



El trozo de aislante desprendido tenía una forma más o menos ovalada, con un tamaño de 500 a 700 mm de largo por 300 a 500 de ancho, y al menos 5 cm de espesor. Su peso estaba en torno a los 600 ó 800 gramos, y la velocidad de impacto fue del orden de los 260 m/s (más de 900 km/h) Aunque se trata de una ligerísima espuma rígida, los ensayos realizados durante la investigación han demostrado que, al contrario de lo que se pensó en su momento, un fragmento de estas características pudo llegar a ocasionar un gran agujero en el borde de ataque del ala izquierda del Columbia.



Se han estudiado otras posibilidades, como el impacto de un micrometeorito o de un fragmento de basura espacial durante la parte orbital de la misión, pero tras el detallado análisis de los sensores de la nave y las imágenes radar, no se ha encontrado nada que apoye esta hipótesis. No obstante, durante el segundo día en órbita se registró la separación de un pequeño objeto que se alejaba a baja velocidad de la nave. Tras extensos análisis, se ha descartado que pudiera proceder de algún equipo experimental de la bodega o que fuera algún deshecho del propio transbordador; se comparó la imagen radar obtenida de este objeto con la que dejarían distintos elementos de la nave, obteniéndose que sería aproximadamente idéntica a la que dejaría una loseta cerámica aislante del borde de ataque del ala, o una junta rígida de carbono del mismo borde de ataque. Aunque no puede probarse, parece probable que, tras el impacto, fragmentos del recubrimiento del borde de ataque cayeran hacia el interior del mismo, liberándose al exterior en ausencia de gravedad al efectuar una pequeña maniobra de giro del transbordador.



La secuencia del accidente se ha intentado reproducir y se conoce con bastante exactitud cómo se desarrollaron los acontecimientos. En un determinado momento de la maniobra de reentrada, con el Columbia ingresando en la atmósfera con el elevado ángulo de ataque requerido para presentar el escudo térmico en su posición más efectiva, comenzó a penetrar aire extremadamente caliente hacia el interior del ala a través de una fisura o, más probablemente, un agujero producido en el borde de ataque. Este flujo de gases a enorme temperatura fue erosionando y fundiendo los materiales, agrandando el agujero y avanzando por el interior del ala izquierda en dirección a la bahía del tren de aterrizaje. Los daños en el ala fueron aumentando, comenzando a afectar al elevón izquierdo y a la maniobrabilidad del transbordador, que empezó a desviarse de su actitud nominal en alabeo y guiñada. Los sistemas de control de la nave intentaron compensar la desviación, pero los daños fueron aumentando sin que pudiera restablecerse el control. Llegado un determinado momento, la posición del Columbia se alejó tanto de la nominal que el vehículo resultó destruido por las fuerzas aerodinámicas.



Fue, por tanto, el desprendimiento del aislante lo que provocó el accidente, pero ¿por qué se desprendió? ¿Fue una mala decisión del MRB, que aceptó con “use as is” un defecto en la aplicación del aislante que se había detectado en la inspección de calidad? ¿Se trató de un fallo aleatorio debido a la naturaleza misma del aislante y del procedimiento de aplicación? Probablemente nunca se sepa, pero las recomendaciones del comité investigador incluyen modificaciones en el esquema aislante del depósito central del transbordador espacial para evitar que hechos así se repitan en el futuro. Desprendimientos de aislante se han repetido en numerosos vuelos del transbordador espacial, pero nunca habían ocasionado ningún daño, y precisamente por ello no se le dio mayor importancia, aunque nunca hasta ahora el desprendimiento detectado había sido de esta magnitud.



De hecho, el informe del comité investigador es extremadamente crítico con la NASA, con su gestión y cultura interna, tanto en materia de seguridad como de organización en general. Es más, el comienzo y conclusiones del informe señala que si bien la causa física del accidente fue el desprendimiento del aislante, tan responsable o más que el propio trozo de aislante fue la gestión de la agencia en la valoración del incidente que dio lugar al trágico accidente con la pérdida de siete vidas.



Sin entrar en más detalle por la falta de espacio, simplemente señalar que los análisis advirtieron que existía la posibilidad de que el aislante hubiera podido penetrar en la estructura... aunque no era demostrable (el modelo no estaba preparado para impactos de esta magnitud). Para asegurarse, los técnicos pidieron que se tomasen imágenes del transbordador en órbita por parte de los sistemas ópticos del Dpto. de Defensa (telescopios espías de altísima resolución), pero la petición fue denegada por los gestores de la NASA, al considerar que no había motivos para la misma. El criterio general era que los habituales desprendimientos de espuma del depósito central no eran un asunto de seguridad de vuelo... aunque nunca se había probado lo contrario. La repetitividad de la anormalidad la había convertido en normalidad, sin ningún estudio que asegurase su inocuidad. De nuevo, como sucedió con el Challenger, el exceso de confianza y la priorización de los objetivos y plazos de la misión sobre la seguridad, tuvieron mucho que ver en este nuevo accidente de la aventura espacial.

Cuando los ingenieros se ponen en la piel de los gestores

http://www.historiasdelaciencia.com/?p=327

Publicado el 3 de Marzo de 2008 en Opinión por omalaled
Tiempo aproximado de lectura: 8 minutos y 43 segundos
Este artículo se ha visitado: 4,232 veces

Sé que la historia de hoy la conocéis todos, pero no está de más desempolvar recuerdos para no olvidar errores de antaño. Uno de esos errores fue el desastre (que no accidente) del Challenger. Y sobre dicho desastre hablaremos en nuestra historia de hoy.

El 28 de enero de 1986, el excesivamente administrado programa espacial estadounidense alcanzó su nadir. Bajo la presión de tener que probar que el transbordador servía para lanzamientos sucesivos, funcionando como un camión, las administraciones de la NASA y de sus contratistas prefirieron ignorar las advertencias de los ingenieros.

El transbordador despegaba rumbo al espacio utilizando una combinación de cohetes; los motores de oxígeno e hidrógeno líquidos en la cola del orbitador y los dos cohetes aceleradores de combustible sólido, adosados a ambos lados del enorme depósito exterior que contenía el combustible líquido.

Challenger

Los dos cohetes aceleradores de combustible sólido utilizados hasta 1986 eran una pila de segmentos reutilizables. Os pongo el detalle de uno de esos cohetes aceleradores.

Cohetes propelente solido

Después de cada vuelo, estas pilas se desmontaban, recargaban y volvían a montar. Las conexiones entre los segmentos se sellaban con dos juntas de goma, una principal y otra de apoyo, llamadas juntas tóricas (literalmente del ingés anillos-O).

Imagen anillos O

Para que dichas juntas funcionaran correctamente tenían que ser dúctiles y flexibles, capaces de cubrir bien la separación cuando el combustible comenzara a arder y la presión del gas lo empujara contra las conexiones entre los segmentos.

En siete de las nueve misiones que efectuaron los transbordadores en 1985 los ingenieros de Morthon Thiokol, la empresa fabricante de los cohetes aceleradores de combustible sólido, detectaron una erosión significativa y daños en las juntas tóricas primarias. En otro vuelo, realizado en abril de 1985, detectaron que una sección de una junta tórica primaria había quedado completamente calcinada. Estas pruebas sugerían que, en condiciones de bajas temperaturas, las juntas tóricas no funcionaban como se esperaba de su diseño. A pesar de la preocupación creciente entre los ingenieros, los transbordadores seguían volando. Tal y como Roger Boisjoly, ingeniero de Morthon Thiokol, escribió en un memorando fechado en julio de 1985: Siento el verdadero y sincero temor que si no actuamos inmediatamente y dedicamos un equipo a resolver el problema … entonces corremos el peligro de perder una misión junto con todas las instalaciones de lanzamiento.

En la mañana del 28 de enero de 1986, el pronóstico para cabo Cañaveral era de una temperatura de 2,2 ºC, próxima al punto de congelación. El transbordador Challenger se disponía a iniciar su décimo vuelo y la vigésimo quinta misión de los transbordadores. Transportaba a siete astronautas, entre ellos, la maestra de escuela Christa McAuliffe, que era el primer ciudadano estadounidense seleccionado para volar al espacio sin que formara parte del programa de astronautas de la NASA.

Los ingenieros de Morthon Thiokol volvieron a advertir a sus jefes y a los responsables de la NASA del Centro de Vuelo Espacial Marshall, quienes gestionaban las relaciones con el contratista, que las frías temperaturas de la Florida podían tener un efecto negativo sobre las juntas tóricas. Los gerentes, tanto en el centro Marshall como en Morthon Thiokol, se mostraban escépticos. Creían que los datos no eran concluyentes. Más importante aún: sentían la presión ineludible pero tácita de mantener el programa de vuelo previsto.

Siempre que la NASA había retrasado el lanzamiento de un transbordador, la agencia había tenido que enfrentarse al ridículo y a las acusaciones de sus adversarios en los medios de comunicación y el Congreso relativas a que el transbordador no estaba a la altura de la promesa de lanzamientos frecuentes y baratos. Esta presión pública la situaba en una posición incómoda: si se decantaba por la prudencia y cancelaba los lanzamientos bajo sospecha sería acusada de fracaso e incompetencia y daría municiones a aquellos adversarios que pretendían bajar el presupuesto de la agencia. Antes que brindarles a sus enemigos pruebas que el programa del transbordador era un fracaso, los administradores intentaban cada vez más a menudo aguantar el tipo, con la esperanza de demostrar que incluso en condiciones difíciles el transbordador podía funcionar como un avión de carga comercial.

La misma historia se repetía una y otra vez. Del mismo modo que las motivaciones políticas habían llevado a la NASA a comprometer tanto que el diseño del transbordador como el de la estación espacial, haciendo que ambos vehículos resultaran inadecuados para cumplir la tarea para la que habían sido originalmente concebidos, los gestores de Morthon Thiokol y de la NASA cambiaron una vez más de opinión en un intento inútil por complacer a los políticos, la prensa y el público; quienes o bien no comprendían el programa espacial o bien se oponían a él abiertamente.

En un momento de la noche anterior al lanzamiento, cuando los ingenieros de Morthon Thiokol intentaban desesperadamente convencer a sus jefes de que un lanzamiento al día siguiente podía ser muy arriesgado, un ejecutivo de la misma empresa, Jerald Mason, miró a Bob Lund, gerente del departamento de ingeniería y le dijo: “Bob, tienes que ponerte en la piel de un gestor y no en la de un ingeniero”.

La presión desde arriba, las dudas sobre los datos y la insistencia en que pensara “como un gestor y no como un ingeniero” fueron suficientes para que Lund cambiara de parecer. Se sumó a los otros gestores de Morthon Thiokol y, pasando por alto la opinión de sus ingenieros, certificó la seguridad de los cohetes aceleradores para el lanzamiento.

El Challenger despegó a las 11:38 de la mañana del 28 de enero de 1986. Sin embargo, tal y como temían Boisjoly y los demás ingenieros, al menos uno de las juntas tóricas del cohete acelerador de la derecha se había vuelto rígido y había perdido su flexibilidad a causa del frío. Con la junta incapaz de conservar el sellado hermético, un humo negro comenzó a filtrarse por la junta casi inmediatamente después de la ignición.

Humo que sale del SRB

A los 58 segundos, cuando el transbordador había alcanzado una altura superior a los 6 km y se movía a una velocidad superior a la del sonido, las llamas producidas por la filtración comenzaron a extenderse al gigantesco depósito exterior. Antes del lanzamiento, este depósito contenía caso 630.000 L de oxígeno líquido y 1.700.000 L de hidrógeno líquido, la mayor parte de ellos todavía sin quemar en ese momento del vuelo. A los 74 segundos, se incendió el combustible del depósito y el transbordador, el depósito y los cohetes estallaron.

Explosion

Los dos cohetes aceleradores salieron disparados como si fueran globos pinchados, obligando a los controladores de tierra a apretar sus botones de autodestrucción. El Challenger estalló en pedazos que se precipitaron al Atlántico. Su cabina de tripulantes, diseñada para resistir fuerzas como aquellas, resistió a la explosión y algunos de los tripulantes aún permanecían con vida en su interior.

Cabina

Sin embargo, las fuerzas resultaron ser mortales; y el impacto contra el océano destruyó la cabina.

¿Hemos evolucionado desde entonces? Años después, en 1997, un astronauta estadounidense llamado Jerry Linenger estuvo un total de 132 días en la MIR. Fue el primer estadounidense en efectuar un paseo espacial vistiendo un traje ruso. Durante esa época tuvieron uno de sus momentos más críticos vividos en la MIR.

Al volver a la Tierra, cuestionó la seguridad de la estación y los gestores de la NASA se mostraron más proclives a calificarlo como “quejica” que a prestar atención a sus preocupaciones. Cuando Jim van Laak, el número dos del proyecto Shuttle-Mir escuchó el informe de Linenger, en vez de preocuparse, se enfureció. En lugar de dedicarse a investigar las quejas de Linenger, comenzó a controlar las entrevistas del astronauta con la prensa, al mismo tiempo que intentaba desacreditarle ante los periodistas. “En mi opinión Jerry Linenger no tiene razón”, comentó a los periodistas. También prohibió la circulación de transcripciones o notas de cualquier sesión informativa de dicho astronauta.

Nadie se levantó para afrontar los problemas comunicados por Linenger y decir: “Es difícil y hay cosas que han salido mal. Hemos cometido errores, pero todavía queremos hacerlo”. En vez de ello, todos se pusieron su gorra de gestor e hicieron como si los problemas no existiesen.

La situación no es muy esperanzadora. No hace falta que os diga que mintiendo no llegaremos muy lejos.

Volvamos con el Challenger. Tras el desastre, se formó la comisión Rogers. Uno de los componentes de dicha comisión fue Richard Feynman. Fue quien más duramente atacó la política de seguridad de la NASA. Les amenazó con retirar su firma del informe si no aparecían sus consideraciones personales, cuya última parte es famosa: para una gestión exitosa la realidad debe estar por delante de las relaciones públicas porque a la naturaleza no se la puede engañar. Bravo, Feynman.

Como ingeniero, me vais a permitir unas reflexiones. Estoy seguro que Bob Lund, el ingeniero al que presionaron “para que se pusiera en la piel de un gestor”, se sintió terriblemente responsable por ceder ante la presión. Sin embargo, sospecho que Mason, aquel ejecutivo que le presionó, se lavó las manos de cualquier responsabilidad, ya que él nunca tuvo que estampar su firma para garantizar la seguridad de los cohetes aceleradores y no era responsable de la seguridad de los mismos. Puede que su trabajo sólo consistiera en hacer presión o, simplemente, en transmitir la que le venía desde esferas más altas o una presión inventada por él mismo. Fuera su trabajo el que fuera, ¿cuál era exactamente su responsabilidad en el lanzamiento?

Pues bien, debo recordar a este ejecutivo y gentes que actúan de forma similar, que es muy fácil presionar a los ingenieros y a los técnicos: somos personas, y como tales, aguantaremos lo que haga falta. Llevadnos al límite de nuestro aguante, amenazadnos con despidos y ponednos en situaciones desesperadas. Lo conseguiréis: firmaremos, incluso, que un puente se mantiene con cuatro palillos. Ahora bien, debéis saber que los ingenieros no podemos presionar a la Naturaleza. No se deja. La Naturaleza no entiende de presiones políticas, económicas, personales, del público ni de la imagen. Es muy suya y tal y como Feynman lo sabía, lo sabemos también los ingenieros.

Es mucho más fácil presionar y responsabilizar a un técnico presionado de un error, que aguantar la presión y actuar con criterios de seguridad y de sentido común o, en caso de desastre, aceptar la responsabilidad de haber presionado. Es lo que se conoce coloquialmente como “endosar el marrón”: hazlo tú, hazlo para ayer y “mójate”; si sale bien, qué gran trabajo hemos hecho (algunos, incluso, dicen “gracias a mi gestión”); y si sale mal, el responsable eres tú.

Bien, amigo Jerald Mason. Ya has visto qué sucede cuando los ingenieros se ponen en la piel de los gestores. Ojalá llegue el día en que los gestores os pongáis en la piel de los ingenieros.

Conste que esta reflexión no la hubiera hecho si el Challenger hubiera explotado sin otras consecuencias más que las económicas o de imagen, al igual que sucedió con el Ariane-5. La reflexión es, sobre todo, porque hubo siete personas que pagaron con sus vidas toda esta lección de cómo no deben hacerse las cosas; personas que confiaron en el buen hacer de gestores y de ingenieros. Ojalá la lección haya sido asimilada, aunque me temo mucho que nunca aprenderemos.

Va por vosotros, muchachos.

Astronautas Challenger

Actualización: recomiendo leer el comentario de Javier Casado.

Fuentes:
“Adiós a la Tierra”, Robert Zimmerman
http://www.xtec.net/~cgarci38/ceta/tecnologia1/challenger.htm

Si queréis saber más sobre la catástrofe del Challenger y la comisión Rogers os recomiendo el libro Qué te importa lo que piensen los demás de Richard Feynman.

Tenéis montones de vídeos en youtube, por ejemplo, la explosión, el detalle de la cabina, etc.