Dispositivos móviles, electrodomésticos inteligentes, vehículos autónomos, sistemas de producción de energía… La tecnología avanza cada día y con ella aumenta la complejidad del software necesario para su funcionamiento y control.
Del correcto funcionamiento de los sistemas de software que controlan esas tecnologías dependen grandes infraestructuras e incluso vidas humanas. Por esta razón es fundamental asegurar un correcto funcionamiento para prevenir accidentes. Estos son los llamados sistemas críticos o safety-critical systems.
Aunque el desarrollo de estos sistemas está muy orientado a la calidad final del producto, esto no los blinda 100% ante fallos. En el caso de los sistemas críticos, un error puede tener consecuencias catastróficas, como queremos mostrar en este artículo.
Therac-25 y su exceso de radiación.
Este es uno de los casos de estudio más sonados. Therac-25 era una máquina de radioterapia para el tratamiento de cáncer usada en la década de los 80. Mediante una pequeña computadora incorporada, generaba y enviaba una radiación para la destrucción de los tumores.
La máquina tenía dos modos de operación: el primero y ya usado en modelos anteriores era un haz de electrones de baja potencia; el segundo y novedoso, un rayo x mucho más potente. La máquina también contaba con un sistema de difusión de energía usado a modo de pantalla antes de que la radiación llegara al paciente.
¿Qué ocurrió? En primer lugar y debido a una race condition, el sistema permitía que el rayo de alta potencia pudiera usarse sin el sistema de difusión, dejando al paciente totalmente expuesto al rayo de alta energía.
El segundo problema apareció en el sistema de control. El software utilizaba un contador de 8 bits para almacenar los parámetros del tratamiento, que continuamente se chequeaban con la prescripción del paciente. Cuando este contador pasaba del valor 255 al 0 se producía la catástrofe: el sistema permitía operar la máquina pero con unos parámetros erróneos para el paciente. Esto causó una sobre exposición a la radiación que terminó al menos con la vida de 3 personas.
¿Por qué ocurrió esto? Investigaciones posteriores demostraron que el proceso de desarrollo del software fue inadecuado, de forma que no se podía testar adecuadamente el software. Además, tampoco se realizó ninguna revisión independiente del software crítico.
Ariane 5 y sus sistemas de navegación.
Otro caso muy sonado es el de la lanzadera espacial Ariane 5 y su vuelo inaugural de 1996, el llamado Vuelo 501. El Ariane 5 se diseñó para sustituir al Ariane 4, teniendo más capacidad de carga. Hoy es el vehículo de lanzamiento estándar de la Agencia Espacial Europea contando con un total de 47 lanzamientos.
A pesar de su éxito, su lanzamiento inaugural fue una catástrofe. Solo 37 segundos tras el despegue sus dos sistemas de navegación fallaron. Dos sistemas gestionados por dos ordenadores diferentes pero ambos con el mismo software, de forma que el mismo defecto tumbó ambos sistemas. El resultado fue la pérdida tanto del vehículo como de su carga, con un coste de 370 millones de dólares.
La causa del error: suponer que el navegador de inercia de su predecesor, el Ariane 4, sería válido para el Ariane 5. El nuevo modelo tenía mucha más velocidad horizontal que su predecesor. Este valor se trackeaba en un punto flotante de 64 bit que después el software procesaba y almacenaba en un entero de 16 bit. Los mayores valores de velocidad hicieron que se produjera un overflow en el sistema al realizar esta conversión.
Además, el software que causó el error ni siquiera debería estar funcionando durante el lanzamiento.
Por lo tanto, se debe ser prudente a la hora de reusar software de proyectos previos. Siempre se debe comprobar que funcionará de forma adecuada en el nuevo entorno, cosa que no es siempre sencilla como se ha visto en los casos anteriores. Además, se debe valorar muy bien si existen razones para ejecutar software que sea innecesario ya que puede ser fuente de problemas.
Sistema de misiles Patriot y la desincronización de sus relojes.
Vamos a hablar del tercer y último caso de estudio en este post, el sistema de misiles Patriot. Es un sistema creado originalmente para derribar aviones enemigos. Posteriormente, en la Guerra del Golfo Pérsico, el sistema se adaptó para derribar misiles Scud. Todo parecía funcionar bien hasta que ocurrió una catástrofe.
En 1991 un misil llegó a las barracas de los soldados americanos en Arabia Saudí debido a un fallo del sistema. Como resultado 28 soldados perdieron la vida y al menos hubo otra centena de heridos.
El sistema falló debido a un error de desfase en el reloj del sistema, que se incrementaba cuanto más tiempo pasaba funcionando. De hecho, dos semanas antes del incidente ya se había reportado que cuánto más tiempo pasaba funcionando el sistema, menos preciso se volvía. La única solución que se dio fue reiniciar para resetear el tiempo de operación.
Una de las modificaciones realizadas en el sistema para aplicarlo a la defensa ante misiles Scud estaba orientada a controlar las medidas de tiempo de forma más precisa, pero esa modificación no se aplicó a todas las partes del software. Como resultado, las medidas de tiempo se realizaban de forma precisa por un lado pero se comparaban con otras medidas no tan precisas realizadas por la parte no actualizada del sistema, lo que producía una discrepancia.
El sistema de misiles Patriot incorporaba un reloj a 1/10 segundos, medida que se representaba mediante el decimal 0,1 en otros sistemas. El problema: no es posible representar este 0,1 en binario. Por lo tanto, la conversión de los enteros que representan el 1/10 del reloj a los valores decimales resultaba en un error de redondeo.
En el momento de este incidente el sistema llevaba funcionando unas 100 horas ininterrumpidas, de forma que el desfase acumulado (que ya era de 1/3 de segundo) se traducía en un error de tracking de unos 600 metros.
El sistema trabajaba con tipos de datos diferentes, lo cual puede ser problemático. Al monitorizar cualquier tipo de medida es importante ser consistente con las unidades y los tipos de datos para que no afecte a la precisión, redondeos, conversión de datos, etc.
Cierre
Incluso los sistemas críticos, desarrollados con los más altos estándares de calidad, no están exentos de errores, que, si no se detectan pueden tener graves consecuencias. Realizar pruebas de software es necesario para prevenir y corregir estos problemas antes de lanzar el producto. En Centum podemos ayudarte con todos estos procedimientos de calidad, mejorando el funcionamiento del software y la experiencia del usuario. Si quieres más información no dudes en contactar con nosotros.
