Modernizar las fuerzas armadas es un proceso lento, costoso, y con múltiples riesgos. Desde cierto punto de vista, no nos sorprende saber que Alemania aún utiliza discos floppy de ocho pulgadas, pero en algún momento hay que evaluar nuevas tecnologías, y eso fue exactamente lo que hizo el crucero USS Yorktown en septiembre de 1997. Al formar parte del programa Smart Ship de la Armada Estadounidense, el Yorktown funcionó como «banco de pruebas» para un nuevo sistema de control digital… que terminó dividiendo por cero, y quedó varado cerca de la costa de Virginia por casi tres horas.
El crucero USS Yorktown (CG-48) de la clase Ticonderoga entró en servicio el 4 de julio de 1984. La información disponible indica que fue especialmente diseñado para aprovechar al máximo el sistema de combate Aegis, que combina ordenadores y radares para la guía y el rastreo de armamento. El Yorktown tuvo algunas intervenciones de alto perfil, entre las que se destacan la intercepción del Achille Lauro (secuestrado por terroristas en octubre de 1985), y varias operaciones en Libia.
Con un equipo de 33 oficiales y más de 300 tripulantes, el Yorktown funcionó dentro de los parámetros esperados, y recibió múltiples condecoraciones. Sin embargo, en octubre de 1995, el NRAC (Naval Research Advisory Committee) publicó un estudio en el que recomendaba explorar diferentes estrategias para reducir tripulaciones, y por extensión, costos operativos. Dos meses más tarde se creó la Oficina del Programa Smart Ship, con el objetivo de incorporar nueva tecnología «y» reducir el número de tripulantes, sin sacrificar rendimiento o capacidad en combate. El crucero elegido… fue el USS Yorktown.
USS Yorktown, y un «divide-by-zero» de tres horas
Bishr Tabbaa nos explica en su blog que un año más tarde, en diciembre de 1996, el Yorktown recibió el primer prototipo funcional del sistema Smart Ship. Construido por Litton Industries, estaba formado por una red LAN de 27 terminales dual-Pentium Pro a 200 MHz conectadas vía fibra óptica a un servidor. Todas las máquinas de Smart Ship utilizaban Windows NT 4.0, un sistema operativo relativamente joven en aquella época (la versión Workstation había debutado en agosto, y la Server en septiembre).
Las proyecciones de ahorro eran de unos 2.8 millones de dólares anuales (considerando una reducción de 44 tripulantes, y múltiples operaciones manuales redundantes). El Yorktown completó con éxito una misión de cinco meses en el Caribe, y varios ejercicios junto al USS George Washington. Sin embargo, el 21 de septiembre se encontraba realizando ejercicios frente a la costa de Cape Charles (Virginia), cuando un tripulante detectó una discrepancia en una válvula de combustible.
La válvula se encontraba físicamente cerrada, pero el módulo SMCS (Standard Machinery Control System) del sistema Smart Ship decía que estaba abierta. La decisión del técnico fue iniciar una recalibración digital de la válvula, ingresando el valor 0 en una de sus propiedades con la ayuda del Remote Database Manager, o RDM. El problema fue que RDM trató de iniciar una operación de división sobre ese nuevo valor, efectivamente dividiendo por cero. El módulo RDM se colgó… al igual que el resto de los sistemas que dependían de él. El efecto dominó llegó a la propulsión, y el pobre Yorktown se quedó flotando, inerte.
En 2 horas y 45 minutos, la tripulación del Yorktown logró reiniciar todo el sistema, y regresar a su base en Norfolk. El blog de Tabbaa también explica incidentes posteriores, contradicciones, y otros detalles falsos como que el Yorktown necesitó ser remolcado. Esto fue desmentido por el propio capitán del crucero, Richard Rushton, y agregó que «no era la primera vez» que el RDM se colgaba debido a parámetros incorrectos. Otras fuentes apuntaron a Windows NT 4.0 como responsable por la falla, pero una vez más, el capitán Rusthon negó que el sistema operativo haya causado problemas.
El Yorktown continuó con sus pruebas, regresó a servicio activo en septiembre de 1999, y fue retirado en diciembre de 2004.
(N. del R.: Bishr Tabbaa publicó otras fallas similares en su libro «Bugs: A Short History of Computer System Failure»).
Accede al artículo completo: Haz clic aquí
