Catastrofe Filipinas

5 catástrofes provocadas por software (y estupidez)

Cuando alguien nos pregunta por qué GNU/Linux no es el sistema operativo más usado (por lo general, gente que cree que Windows y lo que pasa en su computadora es lo que pasa en todos lados) solemos contestar la gran cantidad de sitios en los que se utiliza como sistema operativo principal: bases misilísticas, nucleares, centrales de operaciones, satélites, bueno, cualquier sistema que necesite robustez, estabilidad y fiabilidad. Imaginate que de pronto EEUU libere todas sus bombas nucleares contra Belice porque se le clavó el Windows. Eso no puede pasar. Pero lo cierto es que producto de la enorme cantidad de situaciones para las que se emplea y confía en el software es mucho más importante que sólo usar GNU/Linux, eso es sólo una base. Lo importante viene después. Hoy algunos errores que produjo el software, no, ninguno es de elecciones con voto electrónico, esos no sólo abundan, además son archiconocidos.

Errores de software o hardware -o su combinación- han causado millones de pérdidas, dejado desprotegidos a los sectores más humildes de la sociedad, colocaron gobiernos antipopulares o asesinaron personas. Reformulemos la frase: usar software y confiar en su infalibilidad, ha producido todos estos problemas y muchos más.

Desde hace un tiempo el sistema Autopilot de Tesla (que incorpora una piloto automática en sus autos) está en reprueba luego de producir la muerte de quien iba en el Model S de Tesla al impactar contra un camión encontrándose Autopilot encendido.

Sleipner A

Se trata de una plataforma marina que pertenece a Statoil (una petrolera noruega). Esta edificación, de una extensión de 140 por 60 metros con capacidad para 160 personas -una construcción realmente impresionante- colapsó en 1991 luego de una falla catastrófica. El casco original se vino abajo durante la última fase de construcción, sus cámaras de flotabilidad implosionaron y la construcción golpeó el lecho del fiordo en el que se encontraba con la fuerza de un terremoto de tres puntos en la escala Richter. Nadie sufrió grandes heridas ni hubo muertas. Tiempo después, buscando las responsabilidades de tan terrible situación, se toparon con que NASTRAN, el programa de cálculos usado para la construcción de la plataforma, produjo un error de cálculo de tolerancias de ¡47%!

Holocausto nuclear

Allá por 1983, en plena guerra fría (que no era más que una demostración del poder de aniquilamiento total, inevitable y cruel que se hacían mutuamente los países hegemónicos), un caza soviético derribó por error un vuelo comercial que paradójicamente recibía el número 007, prestado por Korean Air Lines. Todas las pasajeras murieron. Ante esta situación de tensión internacional, un pestañeo fuerte o un estornudo podían disparar una escalada de asesinatos que incluso eliminarían a las propias atacantes, por lo que el hecho de que un avión militar derribe un vuelo comercial resultaba por lo menos complicado.

En aquel momento el sistema satelital de alerta de la URSS reportó, en dos ocasiones, el lanzamiento de misiles intercontinentales desde EEUU. Un ataque militar. Stanislav Yevgrafovich Petrov era quien tenía a su cargo la operación de este sistema y luego de pasar por el momento de estrés más importante que haya vivido una humana (activar la defensa, la respuesta y destruir el mundo desde un botón), decidió, con el riesgo de un juicio por traición que seguro vendría con condena a muerte, que se trataban de dos falsas alarmas. Todo indicaba que EEUU lanzaría cientos de misiles al mismo tiempo, pero los radares en tierra no confirmaban la situación, algo que Petrov sumó a las constantes sospechas de que el sistema fallaba.

Liberadas por un error de software

Allá por 2011, la corte suprema del país que más personas ha asesinado en la historia de la humanidad (EEUU), ordenó al estado de California mejorar las condiciones de sus prisiones (que son un negocio, lo mismo un supermercado que una cárcel) con el objetivo de disminuir el hacinamiento. Para esto esta gente no tuvo mejor idea que recurrir a un software desarrollado por el Departamento de Justicia, que tenía defectos que generaron una liberación incorrecta a 1.500 internas.

¿Cómo? Es tan estúpido que hasta da risa: utilizaron el software para determinar automáticamente qué prisioneras podrían liberar, las de causas más leves. El problema fue que el 50% de los registros -de 16.4 millones de detenciones- estaban incompletos, el programa no encontró información sobre sus causas, y los otorgó automáticamente una libertad condicional irrevocable. El dato simpático es que por tratarse de una libertad irrevocable, ninguna responsable del estado hizo el seguimiento y todas las liberadas mantuvieron su libertad.

El estado y el software

AizokYWCIAAHLYR

La Agencia británica de Bienestar Infantil fue otra que sufrió las mieles del software cuando la compañía EDS implemento, allá por 2004, un sistema para agilizar los pagos, mientras que el departamento para Pensiones y Trabajo de ese país imperialista y colonizador estaba en un proceso de restauración. Ambos softwares resultaron por completo incompatibles, lo que produjo el colapso total de la red de la agencia y trajo aparejado que casi dos millones de personas recibieran más dinero que lo que les correspondía, mientras que unas 700.000 recibieron menos o ningún dinero. A la postre, el colapso se extensión y llegó a dejar 7.000 millones de dólares sin repartir, demoró 239.000 casos y otros 36.000 quedaron inaccesibles en el sistema. ¿La solución? Un gasto extra de mil millones de dólares.

Therac-25: rostizar pacientes

La Therac-25 fue una máquina de radioterapia producida por la empresa AECL (Atomic Energy of Canada Limited) allá por 1982. La máquina se ganó la friolera de cinco muertes a lo largo de más de 6 accidentes entre 1985 y 1987. ¿Cómo lo hizo? Bombardeó a las pacientes con una dosis cien veces más alta de lo necesaria. Sí, confiar en el software y la automatización como forma de abaratar costos disminuyendo el trabajo humano (tomado como costo) hizo que quienes estaban haciéndose un estudio terminaran rostizadas.

Para este desarrollo la empresa había reutilizado código antiguo sin hacerle correcciones, sin pruebas previas de laboratorio y afines. Tras una sucesión de tires y aflojes, AECL, que se negaba a reconocer los fallos de la máquina, no tuvo más alternativa que retirar todas las unidades que produjo. Aquí más información al respecto.

Como para seguir confiando nuestra vida al software.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *