Blog personal de Aitor Iriarte.
Intento ayudar en lo que queda de una comunidad con personas que se respetan unas a otras. Si esto sigue adelante sólo es por comentarios positivos o alentadores. Si ves que este blog permanece congelado, el nulo feedback es el único motivo.
Antes de ejecutar los comandos en sistemas en producción, asegurate leyendo la ayuda o en sitios especializados, de que son adecuados para el fin que pretendes.
Siempre ocurre lo mismo. Este barco no se puede hundir (1912), "la montaña no se mueve" (presa Vajont, 1963), estas centrales son a prueba de terremotos (Fukushima 2011).
La simple negación de un peligro ya indica que entra de lo posible. Si no fuera así no habría ninguna necesidad de desmentirlo.
En el caso de las centrales resulta llamativo que cuando se crean se les pone una fecha de caducidad, que a medida que va llegando se amplía y se amplía negando que haya ningún peligro.
Ahora que ha ocurrido el desastre, mira, resulta que es bastante fácil explicar lo ocurrido, y los que lo tienen difícil son los super catedráticos que han salido estos días en los medios diciendo que era imposible un desastre nuclear (estoy pensando en el Catedrático de la UPV que hace unos días dijo "imposible" y se quedó tan tranquilo).
Pues sí, era posible, y además era un peligro previsto en la zona.
Esta guía Japonesa explica de qué forma estudiar la mejor ubicación para asentar una Central atendiendo la sismicidad. Lo firma la Organización para la Seguridad Nuclear de Japón.
El problema que le veo es que el documento es de 2009 y la Central caída se construyó en 1971, igual que Garoña a escasos 45 km de mi casa. ¿Se hicieron los mismos estudios en su día? ¿Se han tomado medidas según los peligros identificados en la guía? Obviamente no.
En la hoja 17.2 se habla del los factores externos que pueden afectar a la central, como por ejemplo grandes terremotos. En A3-83 podemos ver la forma de clasificar los terremotos que por supuesto incluye los más destructivos. En la hoja 14-8 se mencionan expresamente tsunamis, etc. etc.
Y por supuesto, también se contemplan peligros de las que no se libra casi ninguna Central: la caída de un avión.
Eso sí, el documento se ha elaborado 35 años después de la central.
Fotografía extraida del infome que menciono en el texto:
Hoy han echado una película que me ha impresionado bastante. Es Vajont de 2001.
Relata los hechos ocurridos durante las pruebas de llenado en el embalse de Vajont. Los ingenieros no valoraron correctamente el peligro del emplazamiento. Una periodista intenta alertar a la población y la compañía la denuncia por crear falsa alarma.
El 9 de octubre de 1963 la ladera de la montaña se vino abajo cubriendo totalmente el embalse a la velocidad de 80 km/h. La ola y el viento generado arrasó varios pueblos llegando a 2.000 muertos. La presa permanece todavía intacta.
En este informe que he encontrado se analizan las causas y errores del proyecto. Son 30 páginas con fotografías y gráficos técnicos que se lee fácilmente y explican perfectamente lo ocurrido. Recomendable para ser más críticos cuando en nombre de la ciencia nos dicen que algo es totalmente seguro.
Hoy espero aclarar las dudas que pueda haber sobre el tema de las excepciones.
En Visual Basic.NET tenemos unas cuantas funciones de conversión:
En el siguiente código visual basic se hace una conversión como la que pudo ocurrir en el momento previo de la explosión del cohete.
Tenemos una variable entera llamada i. Y una variable doble llamada z.
Dim i As Integer Dim z As Double z = 4.354354387594386E+25 i = CInt(z)
En Visual Basic, igual que en Ada (lenguaje utilizado en el Ariane-5) la variable z contiene un valor demasiado grande para que pueda convertirse al tipo entero. Lógicamente esto provocará un error.
Igual que en el caso del cohete Ariane, hemos introducido captura de excepciones, lo que ocurre es que no se capturan todas.
Try
Dim i As Integer Dim z As Double DimstreamEscritura As New System.IO.StreamWriter("c:\temp\dato.txt")
Catchioe As System.IO.IOException MsgBox("c:\temp no existe")
Catch se As System.Security.SecurityException MsgBox("Acceso denegado.")
EndTry
El programita después de la conversión imposible va a intentar escribir el resultado en un fichero de texto. Hemos capturado la excepción de "Error de Entrada/Salida" y la de "Seguridad". Veamos lo que ocurre:
Se ha producido un error "Overflow Exception" y la ejecución del programa se ha interrumpido. Esto es lo que ocurrió en el cohete.
La solución es evidente. Hay que capturar TODAS LAS EXCEPCIONES para que nunca se interrumpa de esa forma la captura de datos de los sensores. Si un valor es demasiado grande no debería ocurrir nada, se desecha el valor y el sensor ya nos enviará un nuevo dato.
En Visual Basic esto se hace con una captura de excepción genérica:
Catchex As System.Exception EndTry
Bueno, la lección es la siguiente: Hay que pensar que siempre puede haber excepciones no previstas. Pensar la mejor forma de salir del error e implementarla en el lugar adecuado.
También es importante recordar que las conversiones de tipos suelen ser especialmente problemáticas.
El Ariane-5 era algo más que la continuación de los anteriores. El diseño prácticamente era nuevo. La nueva lanzadera tiene dos secciones. La de abajo es la parte común para todas las misiones y la superior depende de la carga que se va a poner en órbita.
El 4 de junio de 1996, en su primer vuelo, la expectación fue enorme. Todo el mundo estaba observando. Despegó y a los 40 segundos, empieza a girar sobre si mismo hasta que explota.
A los pocos días se nombró una comisión de investigación formada por técnicos de diferentes países. Y esto fue lo que encontraron:
Datos de vuelo:
Hasta el segundo 42 tenían datos telemétricos remitidos a tierra, señales de radar e imágenes visuales.
1-Antes del despegue, todo normal. 2-Despegue, todo normal. 3-Hasta el segundo 36, todo normal. 4-Fallo del sistema de referencia inercial de reserva. 5-Fallo del sistema de referencia intercial activo. 6-La posición de las bocas de los propulsores y del motor van a la posición más extrema. 7-Autodestrucción de la lanzadera.
Con estos datos, ya vieron lo que falló: el sistema de referencia inercial.
Recogida de más datos:
La zona de despegue (Kourou, Guayana Francesa) estaba rodeada de árboles. La explosión fue sobre los 4.000 m. Los fragmentos se dispersaron a lo largo de 12 km cuadrados. Patearon toda la zona y encontraron los dos sistemas de referencia inerciales los cuales tenían datos valiosísimos que no se habían remitido a tierra. De esta forma se supo que primero falló el sistema de reserva y luego el principal.
El diseño
Lógicamente, lo primero que tenemos que saber es qué es eso del sistema de referencia inercial. Para decirlo con cuatro palabras. Parece un montón sensores (giroscopios láser y acelerómetros) conectados a un procesador. De esta forma se mide en todo momento el movimiento, orientación, velocidad, aceleración de la lanzadera.
Este sistema de referencia inercial provee de datos a la computadora de a bordo (sí, como los coches de ahora) a través de un bus de datos.
Esa computadora central tiene el programa de vuelo y va accionando las bocas de los propulsores, el motor, etc. por medio de elementos hidráulicos.
El hecho de que hubiera dos sistemas de referencia inerciales era para evitar el desastre en caso de que fallara el principal. El hardware y el software eran iguales. Como se suele decir ahora eran un activo pasivo y encargado de "switchear" es el computador de a bordo en caso de detectar algún fallo.
El computador de a bordo también estaba duplicado.
El fallo
La secuencia "marcha atrás" fue la siguiente:
A la velocidad que va el cohete y con una inclinación del 20 grados (y subiendo), los propulsores se separan. Eso hace que se active la autodestrucción.
Ese giro no planeado se produce porque las bocas de los propulsores y del motor se encuentran "a tope".
Estaban "a tope" porque así lo había ordenado la computadora de a bordo.
Los datos que cogió de referencia la computadora de a bordo eran los del sistema de referencia principal. No eran datos "buenos" pero los tomó como si lo fueran.
El sistema de referencia principal no enviaba datos "buenos" porque se había producido una excepción en el software.
Aunque había una excepción, el ordenador de a bordo no cambió al sistema de referencia secundario porque este había fallado antes que el principal. En el secundario se había producido la misma excepción.
La excepción se produjo en una conversión de datos de coma flotante (64 bits) a entero con signo (16 bits). Resulta que el número en coma flotante que se intentaba convertir no cabía en los 16 bits del entero. La excepción era un "Error de Operando". El código era Ada, y en esta parte del programa se habían tenido en cuenta otro tipo de errores de conversión, pero no el "Error de Operando".
Ya vemos el cariz que esta tomando esto, pero la realidad supera siempre a la ficción y lo que viene es flipante...
El módulo en el que ocurre el error es para una función de alineamiento que sólo es necesaria antes del despegue. Después del despegue ya no sirve para nada.
O sea, todo se fue al garete sin necesidad. Se trataba de un código que no debería estar ejecutándose.
La cosa es algo más complicada que eso. El Ariane-4 si que necesitaba esa función durante 50 segundos desde la activación del "modo de vuelo" de los sistemas de referencia inerciales. Esos 50 segundos se terminan sobre el segundo 40 desde el despegue. El Ariane-5 no necesitaba esa función en vuelo.
El Error de operando se produjo porque la función se encontró con un valor más alto de lo esperado. La variable está relacionada con la velocidad horizontal de la plataforma.
Era más alto que lo normal porque la trayectoria del Ariane-5 es diferente del Ariane-4 y lo que no era normal en el anterior sí era normal en el nuevo cohete.
00:30 a.m. Hora de dormir. Mañana continuo, porque en el informe se intenta justificar el motivo por el cual no se hicieron todas las comprobaciones necesarias. Decían que no se quería llegar al 80% de la capacidad de proceso del sistema de referencia inercial, pero algo huele mal si realmente estaban ejecutando código innecesario.
Es mucho más conocido lo ocurrido en 1986 con el Challenger. Por un lado, a diferencia del Ariane, éste era un vuelo tripulado. Además recuerdo que en aquel vuelo iba una civil (la primera civil en el espacio). Por si eso fuera poco, muchos vieron las imágenes en directo.
En la wikipedia hay un resumen y las posibles causas del accidente, así como detalles más o menos escabrosos como la posibilidad de que la causa de la muerte de los astronautas fuera el impacto con el océano. La falta de un sistema de eyección así como de paracaídas fue muy criticada y tuvo consecuencias para la NASA.
Hoy quiero hablar del Ariane ya que desde el principio se achacó el desastre a un "problema" informático.
En muchos sitios se habla del Ariane, al fin y al cabo es un cohete europeo con muchos años de vida, pero parece que se ha olvidado lo ocurrido en 1996. En la Wikipedia una simple oración lo recuerda, y en muchos sitios especializados ni mencionan aquel problema informático que originó una pérdida de millones de euros.
Ariane es una familia de cohetes europeos construidos por la Agencia Espacial Europea (ESA). Esta agencia está formada por varios países. Entre otras misiones los Arianes se encargan de poner en órbita satélites.
El primer Ariane se lanzó en 1979. Tenía 47 metros de longitud y podía poner en órbita un satélite de unos 2.500 kg. En 1980 se encarga la construcción a la empresa Arianespace cuyo accionista mayoritario es el estado francés. Las diferentes series se van mejorando y se utilizan según necesidades. La serie 4 podía poner en órbita 4.400 kg.
En estas estamos cuando se llega a la serie 5. La decisión de una lanzadera-cohete más competitiva, con menores costes y mayor fiabilidad, la tomaron en 1987 los ministros de los estados miembros. El Ariane 5 podía poner en órbita 2 satélites de 3.000 kg cada uno, o uno solo de 6.800 kg. Puede transportar incluso vehículos tripulados.
Para el año 1996 se preparan los primeros dos vuelos de prueba: el ariane-501 (en mayo) y el ariane-502 (en otoño). Al final el vuelo 501 se lanza en junio y ocurre el gran desastre.
Al tratarse de un proyecto compartido entre varios países había que iniciar una investigación y hacer públicos los errores. El resultado muy sorprendente. Uno de los mayores fallos software de la historia en un sistema diseñado para que nada falle.
Este post ha resultado demasiado largo. Son las 00:43. Mañana el informe.
El cohete europeo que explotó en el aire era un proyecto en el que colaboraban numerosos países y había que clarificar quien había metido la pata. Los resultados de la investigación eran públicos y al menos el año pasado estaba en Internet.
Imprimí lo que encontré del tema y lo guardé para cuando hiciera falta. Ahora no encuentro nada. Ni mis apuntes, ni el informe de lo ocurrido en la red.
En cuanto encuentre el material, lo analice y lo resuma lo publico en el blog.
Por el momento, sólo os diré que hubo un problema clásico que no se habría producido en caso de haber seguido las nociones más elementales de ingeniería del software.
Por otra parte se produjo un problema de redondeo que tiene relación con lo que hablábamos de las limitaciones en informática y por último, el sistema entero estaba duplicado pero el error de redondeo también se produjo en el sistema secundario con lo que no sirvió de nada.
La lección: por mucho dinero que metas en el proyecto, si te saltas a la torera la documentación de proyectos y das por hecho cosas que no son ciertas el fracaso te perseguirá. Además, luego todo el mundo te dirá a ver por qué no leíste la documentación, y por qué no hiciste las pruebas necesarias.
Aunque la matemática sea la supuesta "Reina de las Ciencias", algunos matemáticos no la consideran una ciencia natural. No, no es una ciencia natural. Se basa en conceptos abstractos que muchas veces no tienen reflejo en el resto de ciencias. Por ejemplo no hay ningún problema para representar un espacio vectorial con 1.384 millones de dimensiones. Dudo que el mundo físico en el que vivimos tenga justo justo esa cantidad de dimensiones.
Incluso cuando tratamos conceptos que se pueden extrapolar a la física, las matemáticas expresan cuestiones que sólo pueden existir en nuestra cabeza.
Por ejemplo un punto 0-dimensional.
¿Y algo que tenga que ver con la informática?
Pongamos un sencillo ejemplo. El siguiente programa en pseudocódigo calcula la circunferencia de un círculo con radio r.
Programa circunferencia contante pi = 3,141592 variable radio: real
Escribe("Introduce el radio") Leer(radio)
Devolver 2 x pi x radio
Observa el programa. Hemos puesto un pi con 6 decimales. Podíamos haber puesto un número pi todo lo preciso que queramos pero el programa nunca devolverá el valor exacto.
Esto sólo demuestra una cosa. Podemos acotar el error pero es imposible eliminarlo. Esto es lo que le pasó al cohete europeo Ariane Vpor un error de redondeo (un día de estos publicaré detalles técnicos recopilados desde hace tiempo).
Lo que hemos visto en el video anterior es el problema de la informática por basarse en la realidad física en lugar de en las matemáticas puras.
Pero hay más:
PI es un número irracional. Significa que no expresarse como una fracción p/q donde "p" y "q" sean enteros. Se caracterizan por tener infinitos decimales que no siguen un periodo definido. Efectos prácticos: Imaginemos que encontramos un circulo perfecto en el mundo. Nos inventamos una unidad de media nueva de forma que el radio del círculo sea la unidad.
Entonces el diámetro es 2 x pi x r, y como pi es irracional y r es la unidad... Tenemos que el diámetro es 2 x pi. Y si pi tiene infinitos decimales, pi x 2 también. Por lo tanto, no hay circulo perfecto en el mundo simplemente porque no podría haber una circunferencia con "longitud finita" que cumpliera la igualdad.
El circulo perfecto es una idea en nuestra cabeza nada más. Por eso decía que la informática se basa en la realidad física más que en las matemáticas.
Mañana os cuento lo que le ocurrió hace 2.500 años al matemático (entonces filósofo) que intentó que las matemáticas avanzaran admitiendo la existencia de esos números tan "irracionales" que no podían ser de este mundo.
