El fracaso de los Patriot y el número de 24 bits

El caso de los misiles Patriot está un poco olvidado porque pasaron unos cuantos años desde la Guerra del Golfo pero para refrescarles la memoria (o si son jóvenes y no tienen idea), luego de que Saddam Hussein invadiese Kuwait creyendo que nadie iba a reaccionar una gran coalición internacional se formó para liberar el país.

Durante los meses previos, y justo antes del avance aliado, Hussein lanzó numerosos cohetes Scud contra las posiciones de la ONU en Arabia Saudita y sobre Israel y, para contrarrestar esto, estaban los misiles Patriot... pero resultaron ser un fiasco enorme y todo por un error de diseño...

El 25 de Febrero de 1991 un misil Scud iraquí impactó contra las barracas de la base de Dhahran en Arabia Saudita matando a 28 solados de los EEUU ¿Cómo había llegado el misil sin ser interceptado?

Era un error muy estúpido pero una investigación encontró el problema: las marcas de tiempo en el software.

Resulta que la batería de misiles, como toda instalación, tiene una parte que compone el radar y mando de tiro y por otra parte el misil en sí. El sistema Patriot implica ambas partes.

El radar había estado operando más de cien horas, algo que uno esperaría normal, sin un rebooteo pero he aquí que el reloj interno se iba corriendo un tercio de segundo cada cien horas, que, en términos de velocidades de un misil, es como errarle por 600 metros.

El radar había detectado el misil entrante, predijo dónde iba a estar el Scud en la siguiente pasada del radar, pero como los tiempos estaban mal miró dodne no debía ver y allí no había nada. Esos 600 metros de desfasaje fueron suficientes para que el radar cancelara la detección asumiendo que se trataba de un error.

Lo que sucedía es que el tiempo se fijaba en una variable de 24 bits con el punto flotante fijo. Luego de 100 horas la precisión se iba perdiendo a tal punto de ser totalmente inútil el dato.

En el caso de Dhrahan ni siquiera la batería de misiles intentó disparar y contraatacar, asumió todo como un error y lo dejó pasar. El Scud impactó directamente en las barracas.

Según el informe del GAO

"La predicción de la ventana de rango de dónde aparecerá el Scud a continuación es una función de la velocidad conocida del Scud y el tiempo de la última detección de radar. La velocidad es un número real que se puede expresar como un número entero y un decimal (por ejemplo, 3750.2563 ... millas por hora). El tiempo se mantiene continuamente por el reloj interno del sistema en décimas de segundos pero se expresa como un número entero o entero (por ejemplo, 32, 33, 34 ...). Cuanto más tiempo haya estado funcionando el sistema, mayor será el número que representa el tiempo. Para predecir dónde aparecerá el Scud a continuación, tanto el tiempo como la velocidad deben expresarse como números reales. Debido a la forma en que la computadora Patriot realiza sus cálculos y el hecho de que sus registros tienen sólo 24 bits de longitud, la conversión de tiempo de un número entero a un número real no puede ser más precisa que 24 bits. Esta conversión da como resultado una pérdida de precisión causando un cálculo de tiempo menos preciso. El efecto de esta inexactitud en el cálculo de la ventana de rango es directamente proporcional a la velocidad del objetivo y la longitud del sistema que ha estado funcionando. En consecuencia, realizar la conversión después de que el Patriot haya estado funcionando continuamente durante períodos prolongados hace que la ventana de alcance se aleje del centro del objetivo, lo que hace menos probable que el objetivo, en este caso un Scud, sea interceptado con éxito."


Dos semanas antes de esto los israelíes habían detectado el problema e informado tanto al ejército de los EEUU como la oficina del proyecto Patriot y hasta al desarrolador del software. Inteligentemente los israelíes recomendaron rebootear regularmente el sistema para que el contador de tiempo arrancara siempre desde cero y no arrastrara el error hasta las cien horas.

La actualización del software llegó el día después del ataque a las barracas.

Cuando el presidente de EEUU de ese entonces hablaba públicamente del "éxito" de los Patriot contra los Scud mencionaba un 97% de efectividad, sólo uno había pasado de largo. Pero esto no era cierto: estaba por debajo del 10%.

Para evitar no interceptar nada se lanzaban varios misiles al mismo tiempo (un enorme desperdicio pero mejor que nada).

Por ejemplo , si un misil tiene un 50% de probabilidades de acertar dos elevan ese número al 75% y tres al 87.5%, básicamente interceptaron por fuerza bruta. Si lanzaban 20 seguro acertaban con un 0.1% de margen de error.

Otra razón por la que no hubo muchas víctimas de los Scud es que el ejército Iraquí le había hecho muchas modificaciones para aumentar su autonomía y varios de éstos realizaban su reentrada ya destruidos por las fuerzas G (sí, los misiles balísticos van hasta el espacio y vuelven).

El problema para los Patriot es que era imposible detectar cual de todos los pedazos cayendo era la ojiva explosiva y cual el resto del cohete desarmado.

restos de un Scud en el desierto

La única ventaja en Arabia era que la mayoría de las bases estaban en el desierto, el problema para Israel era que siempre le disparaban hacia las ciudades. "Algo" terminaba cayendo y lastimando gente. Adicionalmente a esto Israel no es una dictadura que censura las malas noticias, Arabia Saudita sí, así que se supo más del daño producido donde menos restricciones al flujo de información había.

En Israel estaban tan disconformes con la performance del Patriot que empezaron a planear su propio ataque contra Irak pero, por suerte para todos, la guerra llegó a su fin ante de esto.

Luego el sistema fue debidamente corregido por Raytheon y estos problemas dejados en el pasado pero es interesante que una cosa tan tonta como manejar un decimal fijo en un registro podía generar tantos problemas. Faltó testing ahí.

Si te gustó esta nota podés...
Invitame un café en cafecito.app


Otros posts que podrían llegar a gustarte...

Comentarios

  • Christian     01/02/2021 - 11:25:34

    Hola.
    Una consulta.
    ¿Se podría explicar en algún post el por qué la NASA no desarrolló una tecnología similar a la de Blue Origin o SpaceX con respecto a los cohetes reutilizables, desde la finalización del proyecto Space Shuttle?
    Muchas gracias.

    • Fabio Baccaglioni     01/02/2021 - 14:51:14

      hice algunos videos al respecto en mi canal porque... ejem... el congreso

      Lo explico simple. El SLS se construye con las mismas piezas del Shuttle, fabricadas en muchos estados y, por ende, dan trabajo en dichos estados. Los representantes quieren eso, que sus estados tengan trabajo gracias a "su gestión", y por más que cueste diez veces más y sea un desarrollo anticuado, siguen apoyando eso.

      Todo esto llevó a la NASA a no tener un lanzador propio hasta que llegó SpaceX.

      ¿El SLS? Sigue atrasándose y es diez veces más caro que cualquier opción privada.

      • Christian     02/02/2021 - 11:40:56

        Si.
        Vi que ya hay retraso en Artemis. Se ve que ahora ya no los apura Trump.
        Gracias.

  • Javier     01/02/2021 - 11:30:48

    Increible como hicieron para descubrir este bug. A veces uno puede ingresar a los logs en un servidor y asi y todo es dificil. Aca tenes un SW que corre desatendido en el medio de la nada, sabes que fallo pero anda a ver un log de ejecucion... tenes las pruebas que hiciste en tu laboratorio y nada mas...Aplausos a los ingenieros que tienen que diganosticar esto remotamente (antes de hoy en dia que en general acceso remoto hay a casi cualquier cosa)

  • cesar     01/02/2021 - 18:43:32

    Me pasó en un proyecto algo parecido. La solución era reescribir todo de nuevo (inviable por razón de tiempo y dinero), la otra que se reinicie regularmente. Lo mas difícil fue explicar el problema que se generaba porque un contador se iba atrasando cada vez que el procesador estaba en uso por el antivirus. En el caso de los misiles supongo que actualizar el software debería haber sido muy costoso.

    • Fabio Baccaglioni     01/02/2021 - 22:10:57

      Pero al final lo hicieron, en realidad no era imposible de arreglar y para el final de la Guerra del Golfo ya lo tenían parcheado. El problema era, justamente, darse cuenta del error!

  • Danbat     02/02/2021 - 02:28:06

    Apa, pasaron ya 30 años de la Guerra del Golfo .

    Recuerdo que las primeras Pentium tuvieron un callback porque presentaban errores de cálculo de punto flotante a partir del decimal 12 (creo recordar) y en ese momento pensaba "¿por qué necesitarías tantos decimales en una PC común?". Tres años después estaba haciendo unos cálculos cartográficos y de pronto me di cuenta que estaba usando coordenadas con 15 decimales. Se necesitaban no más de cinco para tener una precisión de 1 metro, pero como los errores se acumulan, usaba los 15 decimales que me daba el programa. Ahí fue que aprendí que no se redondea hasta el número final.

  • GAK     02/02/2021 - 13:39:19

    ¿Habrá sido para ahorrarse unos pesos?. Para aquel entonces ya existían procesadores tipo DSP de 32bit y coma flotante (y ayudaban en invierno con la calefacción).

    • Fabio Baccaglioni     02/02/2021 - 13:51:39

      Teniendo en cuenta que lo que se pone en un arma suele ser bastante más primitivo/probado y que tiene que soportar radiación y varios malos tratos, es normal que los procesadores en un misil sean re crudos. Pero aquí no era el misil el problema... era el radar! La cagaron por pijoteros? Puede ser, no me extrañaría.

  • nan     13/05/2021 - 21:58:05

    Muy lindo artículo che.

    Si te sigo bien y recuerdo correctamente algo de métodos numéricos, el problema es que los valores representables del punto flotante están cada vez más espaciados entre sí a medida que te alejás del cero.

    Aclaro que en el contexto adecuado esto tiene su razón de ser: te permite representar números muchísimo más grandes a través del uso del fragmento de potencia que lleva la dupla que lo compone), por ej. El número de punto flotante se compone de una dupla, una parte que es una potencia y otra que es un sumador.

    Entonces... a medida que el contador del clock avanza, vas perdiendo precisión (cada vez que aumenta la potencia en la dupla, se te vuelven más espaciados los números)

    A esto se le compone otro problema complejo (agrego por si aporta algo): los cálculos matemáticos que se hacen luego, en lugar de hacerse con los valores reales (matemáticamente hablando: los números reales), se hacen con el aproximado en punto flotante, y cada cálculo que hacés, dependiendo cómo se haga amplifica o reduce ese error). Hay formas de estudiar el comportamiento de las fórmulas, estudiando qué sucede con los errores, algo que se llama velocidad de convergencia o divergencia,.

    ---- aca viene la anecdota personal que no le importa huevo a nadie jajaj---

    Me acuerdo que me topé con la superficie de este problema cuando tenía creo unos doce años, estaba tratando de programar un video y necesitaba calcular el rebote de una pelota, y había un cálculo muy simple y no funcionaba, en determinado momento, y las cuentas estaban bien, y los números que daba la calculadora y la computadora decían cosas distintas, en una tangente.. lo hablé con un amigo más sabio de la escuela y ahí estaba: cerca de cero, las tangentes se iban al cuerno, era el punto flotante, o sea... según el valor que tenía que representar convenía usar una u otra fórmula trigonométrica para que el cálculo diera el resultado correcto, a pesar de que matemáticamente eran igual. No te podés imaginar lo que puteé.
    -- fin de la anécdota --

Deje su comentario:

Tranquilo, su email nunca será revelado.
La gente de bien tiene URL, no se olvide del http/https

Negrita Cursiva Imagen Enlace


Comentarios ofensivos o que no hagan al enriquecimiento del post serán borrados/editados por el administrador. Los comentarios son filtrados por ReCaptcha V3.