El software que lleva a una persona al espacio tiene fama de ser una cosa aparte: lenguajes raros, procesadores endurecidos contra la radiación que cuestan una fortuna, sistemas operativos de tiempo real diseñados para aviones y décadas de certificación. Durante mucho tiempo fue exactamente así, y en buena parte de la industria lo sigue siendo.
SpaceX lo hace de otra manera, y lo ha contado. No hay código abierto ni documentación oficial, pero su equipo de software se ha sentado tres veces a responder preguntas en abierto —en 2013, en 2015 y sobre todo en junio de 2020, unos días después del primer vuelo tripulado de la Crew Dragon—, y de ahí sale casi todo lo que se sabe. Esto es lo que dijeron, y lo que conviene no dar por cierto.
Claves
- Sistema operativo: Linux. No un sistema de tiempo real clásico, sino un Linux poco modificado con los parches
PREEMPT_RT, con núcleo y cadena de herramientas propios. - Lenguajes: C++ para el software de vuelo, Python para las pruebas y HTML, CSS y JavaScript para las pantallas de la Crew Dragon.
- Sí, un navegador: esas pantallas las dibuja Chromium, el mismo motor que hay debajo de Chrome. Solo dibuja; no pilota.
- Nada de silicio especial: componentes comerciales corrientes en vez de procesadores endurecidos, y la radiación se compensa con el diseño del sistema.
- Triple redundancia: cada decisión se calcula tres veces y se vota antes de emitirla.
- Un equipo pequeño: unas 35 personas en 2013 y en torno a 50 hacia 2019 para todo el software de vuelo de todos los vehículos.
Cómo se toma una decisión a bordo
Esta es la parte interesante, y la que explica por qué se pueden usar procesadores de los que lleva cualquier portátil. En vez de comprar un chip carísimo que aguante la radiación, SpaceX asume que un chip corriente va a equivocarse de vez en cuando y monta el sistema para que una equivocación no llegue a ninguna parte.
El mecanismo se conoce como actor-juez. Hay tres «hilos de vuelo» independientes, cada uno con dos núcleos que ejecutan lo mismo. Un hilo solo emite una orden si sus dos núcleos coinciden; si discrepan, calla. Después, el controlador que recibe las órdenes compara los tres hilos: si los tres dicen lo mismo, adelante; si uno se sale, se hace caso al que venía acertando y se ignora al discrepante.
Los motores Merlin del Falcon 9 llevan su propia versión del mismo reparto: tres ordenadores que votan, cada uno con dos procesadores que se vigilan entre ellos.
Qué corre dónde
La capa de arriba es la que dio que hablar. Cuando los astronautas de la Demo-2 pilotaron la cápsula con pantallas táctiles, resultó que lo que veían era HTML y JavaScript dibujados por el mismo núcleo que hay debajo del navegador Chrome. SpaceX usa Chromium únicamente como motor de dibujo, con una biblioteca reactiva propia encima, y lo mantiene aislado del resto: según el equipo, una pestaña colgada no se lleva por delante la cápsula. Y hay botones físicos de respaldo para lo esencial.
Debajo, lo que de verdad vuela la nave es C++ sobre Linux, y ahí Chromium no entra.
Starlink juega con otras reglas
Lo más revelador de la sesión de 2020 fue la comparación entre las dos mitades de la casa, porque enseña que no hay «una» manera de hacer software en SpaceX, sino dos muy distintas según lo que pase si algo falla.
| Crew Dragon | Starlink | |
|---|---|---|
| Qué pasa si falla uno | Es una pérdida de misión | Perder un satélite no es una pérdida de misión |
| Ritmo de cambios | El código se congela meses antes del vuelo | Actualizaciones aproximadamente semanales |
| Forma de trabajar | Verificación exhaustiva antes de volar | Iteración rápida, «como armarios de servidores en un centro de datos» |
De esa diferencia sale un detalle que resume bien la escala: los satélites Starlink recién lanzados suelen llegar a órbita con el código ya atrasado respecto al resto de la constelación, porque entre que se cargó y que llegaron arriba el software ha seguido avanzando. En 2020 el equipo hablaba de más de treinta mil nodos Linux en órbita y más de seis mil microcontroladores.
Esa misma constelación es la que Starship empezó a desplegar en su primer vuelo orbital, y es también la razón de que la cifra no pare de crecer.
Lo que circula y no está claro
Buena parte de lo que se lee sobre este asunto son relatos de segunda mano de aquellas sesiones, y por el camino se han colado cosas que conviene marcar.
| Se dice que… | Qué pasa con eso |
|---|---|
| Los procesadores son x86 | Es lo que repiten la mayoría de fuentes, pero el relato de una charla en la GDC habla de tres procesadores ARM de doble núcleo en placas propias. No hay una declaración oficial que lo zanje |
| Usan VxWorks | Choca de frente con lo que el propio equipo dijo en 2020 sobre Linux y PREEMPT_RT. Aparece en algún resumen y no en las fuentes directas |
| Certifican según la norma DO-178B | No he encontrado ninguna fuente primaria. Es una norma del mundo aeronáutico, no del lanzamiento espacial comercial |
| El simulador de atraque de su web lleva el código real | El equipo lo desmintió expresamente: no es el mismo código que vuela en la Crew Dragon |
Por qué importa
Importa porque desmonta una idea muy extendida: que el software crítico exige herramientas exóticas. Aquí hay un vehículo tripulado volando con el mismo núcleo que corre en cualquier servidor y con el mismo lenguaje que se usa para escribir videojuegos. La diferencia no está en las piezas, está en cómo se combinan: la fiabilidad la aporta la arquitectura —tres cálculos y una votación—, no la etiqueta del componente.
Importa también porque enseña que el nivel de rigor se elige según lo que cuesta un fallo, y no de manera uniforme. El mismo equipo congela el código de una cápsula durante meses y despliega en la constelación cada semana. Esa es una decisión de ingeniería deliberada, no una incoherencia, y es trasladable a cualquier proyecto en el que convivan partes que no pueden fallar con partes que pueden reintentarse.
Y conviene cerrar con la advertencia que atraviesa todo lo anterior: esto no es documentación, son declaraciones. Son respuestas en un foro, sin referencias, algunas ya con años encima y sin forma de contrastarlas. Lo mejor que se puede decir de ellas es que vienen del propio equipo; lo peor, que es lo único que hay.
Sobre la imagen de portada. Es una fotografía de archivo del interior de una Crew Dragon, con Robert Behnken y Douglas Hurley antes de la misión Demo-2, tomada en marzo de 2020. No tiene relación directa con el software del que habla el artículo, más allá de ser la nave cuyas pantallas se mencionan. Fotografía de SpaceX, bajo dominio público (CC0), vía Wikimedia Commons.
Fuentes: las sesiones de preguntas del equipo de software de SpaceX en Reddit (2013, 2015 y junio de 2020, recogida por Hackaday), InfoQ sobre el uso de JavaScript en la Dragon, la ficha del Falcon 9 v1.0 en Wikipedia para la aviónica y el hilo de Hacker News sobre el ordenador de vuelo.