El software es esa parte de los sistemas de cómputo que son intangibles. Vamos, que finalmente el código fuente de cualquier pieza de software, sistemas operativos, aplicaciones, herramientas, etcétera, son ceros y unos en chips que además, están distribuidos de maneras que ni siquiera imaginamos y que de alguna manera se ejecutan como programas que usamos cotidianamente. En general pensamos que el software que se escribe está bien hecho y que bueno, en ocasiones por alguna razón se “congela”, se traba, y nos obliga a rearrancar nuestra máquina para regresar a un estado conocido.
En lo que se refiere al cómputo casero lo peor que nos puede pasar -cuando el equipo decide no responder, cuando se traba- es que tengamos que rearrancarlo, pero ¿qué hay de los ingenieros de software que trabajan en sistemas de misión crítica, por ejemplo, en las aplicaciones y programas que usan las aeronaves modernas? Ahí es fundamental que los programas no se traben porque podrían poner en riesgo un vuelo y la vida de los pasajeros y la tripulación. De hecho, por eso hay incluso toda una disciplina que busca la manera de demostrar que el software es correcto y funcional.
En el Boeing 787 Dreamliner ha ocurrido un problema de software que parece ser obliga a resetear los equipos cadas 248 días. Si no se hace este procedimiento, el sistema entra en un modo contra errores y el avión podría perder toda su energía eléctrica. La razón de esto, de acuerdo a un funcionario de la FAA (Federal Aviation Administration), es: “Esta condición es causada por un contador interno en el software que se pasa de su límite (cae en overflow, pues) después de 248 días de uso contínuo. Esto podría convertirse en la pérdida de la energía eléctrica del avión, con lo cual se podría perder incluso el control de la aeronave”.
Así entonces, el problema es un clásico overflow. ¿Será fácil arreglarlo? ¿No sería suficiente agregar más bits para evitar este problema? ¿O tal vez usar precisión infinita (bigint) para evitar la dificultad? Quizás la solución más obvia es que cuando se llegue a este momento del overflow (o un poco antes), el sistema se rearranque solo.
Pero mientras hay un parche para este problema, todos los Dreamliners tendrán que rearrancarse antes de los 248 días. Cabe señalar que la FAA indica que el rearranque puede tardar una hora en total, por lo cual, el problema va más allá de apagar y prender los sistemas. Es interesante saber que el Airbus A380 es comparable en complejidad al Dreamliner, y el software que se usa tiene más de 100 millones de líneas de código.
Referencias: