Hace unos días se suscitó un interesante debate a partir de una calculadora que al hacer la operación 700/30*3 producía el resultado 69,999999 en vez de 70. La primera reacción fue atribuir el desfase al redondeo, hasta que pudimos discutir que 30/3 (10/1) son 10 y el resultado de la división debía ser necesariamente 70,0.

Una vez la curiosidad sucedió al escepticismo, pudimos ir comprobando que la mayoría de las calculadoras debían tener componentes comunes y el error es bastante frecuente. Algunos dijeron que 0,000001 es un error residual, que al fin y al cabo funcionan electrónicamente no sólo nuestros bancos, los ascensores, los servofrenos del coche, el tráfico aéreo... un momento. El tráfico aéreo no funciona electrónicamente. Siendo uno de los sectores en que más rápida implantación tuvo la informática, las decisiones se siguen tomando de forma manual ¿Por qué?

Tal vez los ciudadanos medios disfrutemos de una ignorancia autocomplaciente pensando que sesudos expertos han analizado todos los posibles problemas y han diseñado programas a prueba de fallos... ¿cómo se detecta un fallo? Porque el ejemplo de la calculadora nos ha demostrado que la mayoría de nosotros no somos capaces de detectar cuando falla un sistema electrónico. Si nuestros ordenadores de buceo diesen decos absurdas, la mayoría de nosotros simplemente las cumpliríamos y si nuestras células nos muestran lecturas de ppO2 imposibles (por ejemplo una subida de ppO2 en ascenso), simplemente actuaríamos de forma automática (inyectando diluyente). ¿Podemos estar seguros de que nuestra calculadora no nos ha suministrador resultados incorrectos con anterioridad?

En los años 60, cuando los ingenieros eran capaces de poner al hombre en la luna son la única ayuda de reglas de cálculo, se desarrolló uno de los sistemas informáticos más revisados del mundo, de hecho el primer sistema embebido. Dio en llamarse Apollo Guiding Computer (AGC) y fue diseñado por el MIT. Tenía 2 Kb de RAM y 36 Kb de ROM y corría a poco más de 1 mHz. Aunque lo podemos considerar mucho más lento que un smartphone, no es que no existieran ordenadores más rápidos por entonces, sino que se trataba de un diseño a prueba de fallos, lento pero seguro.

El software Luminary era capaz de ejecutarse en modo multitarea, alternando la escritura y lectura de ocho tareas simultáneas. En caso de ser requeridas más de ocho tareas simultáneamente, el sistema simplemente accionaba una alarma. La confianza en el sistema era completa -o pensamos que lo era- pues el proyecto Apollo 11 se había calculado que tenía un 50% de posibilidades de fallar en el alunizaje y tan sólo un 10% de hacerlo en el regreso a casa. Aunque se trataba de un equipo unas 8 veces menos potente que un handset -o una controladora de vuelo de radio control- actuales.

A pesar de su aparente poca potencia, el AGC era respaldado en la Tierra por varios enormes mainframes de IBM, logarítmicamente más potentes, pero menos fiables a decir de los expertos.

El AGC estaba programado para posar el módulo del Apollo 11 en la luna, pero es conocido que poco antes de hacerlo produjo el código de error “1201” y más tarde “1202”. El comandante, Neil Armstrong consultó esta incidencia y el ingeniero Jack Garman lo tranquilizó diciendo que era resultado de la alarma multitarea y que ignorara los errores.

De modo que los astronautas simplemente se dejaron llevar hasta comprobar horrorizados que el AGC pretendía alunizar en un cráter lleno de rocas. Armstrong era una de esos astronautas de la vieja escuela, que había volado más de 200 modelos diferentes de planeadores, cazas, helicópteros... y simplemente ignoró las instrucciones de Tierra y pasó a modo manual, alunizando sin novedad a seis kilómetros de donde estaba programado.

Toda esta historia viene a colación de que aunque he realizado bastantes inmersiones en modo electrónico con rebreather, incluso las manuales han dependido en última instancia de las alarmas de sistemas electrónicos no mucho más potentes que el AGC, construidos las más de las veces en sistemas abiertos (tipo Arduino) por aficionados que no tienen ni los recursos ni la preparación que el pool de ingenieros del MIT que trabajaron para la NASA en la primera mitad de la década de 1960.

Llevo unos meses volando drones -o intentándolo- con la intención inicial de auxiliarme encontrando nuevas cuevas y a pesar de usar tecnología de vuelo que sobrepasa con creces al AGC, he de confesar que la mayoría de mis vuelos terminan accidentalmente a pesar de estar recurriendo al control automático. Es difícil explicar las razones de que esto suceda e incluso los equipos de documentalistas del National Geographic, volando equipos que cuestan más de 10 veces lo que el mío, terminan algunos vuelos estrellados o perdidos.

Cuando regreso a casa con los restos, no puedo dejar de pensar en los rebreathers y en la confianza en la gestión electrónica. En mi caso necesitaría cientos, miles quizá de horas para volar en manual con una mínima seguridad (no ya la que demostró Neil Armstrong alunizando) pero soy consciente de que cualquier usuario de un eCCR desde la primera inmersión -en que no tiene experiencia- hace depender su vida de la gestión electrónica.