Perseverance aterriza en Marte: el stack tech detrás del rover (y qué inspira a tu empresa)
El 18 de febrero, después de siete meses de viaje y los famosos "siete minutos de terror" durante el descenso, el rover Perseverance de la NASA aterrizó con éxito en el cráter Jezero de Marte. A bordo lleva a Ingenuity, un helicóptero de menos de dos kilos que en las próximas semanas intentará volar en una atmósfera con menos del uno por ciento de la densidad de la terrestre. Será el primer vuelo motorizado en otro planeta.
Más allá de la épica espacial, hay una historia técnica que vale la pena contar. Las empresas que escriben software crítico operan en mundos muy distintos al de NASA, pero algunas decisiones de ingeniería del Jet Propulsion Laboratory son sorprendentemente aplicables a equipos pequeños y medianos. En ALCA, donde trabajamos con varios equipos de ingeniería de empresas mexicanas, estuvimos revisando con detalle el stack que llevó Perseverance a Marte. Queremos compartir lo que encontramos.
El cerebro del rover: hardware modesto, software extremo
El procesador principal del Perseverance es un BAE RAD750, una versión radiación-resistente del IBM PowerPC 750 que se vendía comercialmente a finales de los noventa. Corre a aproximadamente 200 MHz, tiene 256 MB de RAM y 2 GB de almacenamiento flash. Es decir, un teléfono inteligente de hace siete años tiene más poder de cómputo bruto que el rover.
Esta aparente paradoja tiene explicación clara: en Marte no hay reinicio remoto. Cada componente debe sobrevivir radiación cósmica, ciclos térmicos extremos y vibraciones de lanzamiento. La tecnología más nueva no necesariamente es la más confiable; lo es la más probada. NASA elige hardware donde cada falla potencial está documentada, simulada y mitigada.
Lección uno para empresas: la versión más reciente de cada componente no siempre es la mejor decisión. Para sistemas críticos, madurez vence a novedad.
Sistema operativo y framework de software
El rover corre VxWorks, un sistema operativo en tiempo real desarrollado por Wind River, usado en sistemas embebidos críticos durante décadas. No es Linux. Pero el equipo de tierra que opera el rover, los sistemas de simulación, el ground control y muchas herramientas internas de JPL sí corren Linux y software libre extensamente.
Más interesante aún: el código de aplicación del rover usa F Prime, un framework de vuelo desarrollado por JPL y publicado como código abierto en GitHub. Eso significa que cualquier ingeniero del mundo puede leer, estudiar e incluso usar el mismo framework que hace funcionar a un rover en Marte. Esa decisión de abrir tecnología de misión crítica refleja una filosofía importante: el software libre no es solo para herramientas chicas, puede sostener sistemas extremos.
Ingenuity, el helicóptero, va aún más allá. Corre Linux con un procesador Snapdragon 801 (el mismo de algunos teléfonos Android de hace seis años), usa componentes comerciales y JPL liberó documentación detallada de su arquitectura. Es la primera vez que Linux vuela en otro planeta.
Lección dos: el software libre y los componentes comerciales pueden ser parte legítima de sistemas serios cuando se aplican con la disciplina correcta.
Cómo se prueba código que no se puede actualizar fácil
Aquí está, para nosotros, lo más interesante. Cualquier corrección de software del rover requiere subir un parche por radio a través de millones de kilómetros, con ventanas de comunicación limitadas, latencia de varios minutos y riesgo no nulo de dejar el rover inoperativo. Eso obliga a una práctica de ingeniería que las empresas comerciales rara vez se toman en serio.
Cada cambio pasa por revisión por pares múltiple, análisis estático exhaustivo, pruebas unitarias con cobertura cercana al 100% en componentes críticos, simulaciones en hardware idéntico al del rover y, finalmente, ejecución en un rover gemelo en tierra antes de subirlo al rover real. El ciclo entre escribir código y desplegarlo en producción puede tomar semanas o meses.
Para una startup acostumbrada al despliegue continuo varias veces al día, esto suena absurdo. Y para muchos casos lo es. Pero hay sistemas donde algo similar tendría sentido: software que controla cobros financieros, sistemas de salud, plantas industriales, infraestructura crítica. La pregunta útil para CTOs no es "¿cómo escribiría código si fuera para Marte?" sino "¿qué partes de mi sistema merecen un nivel de cuidado intermedio entre 'CI básico' y 'NASA'?".
Lección tres: no todo el código merece el mismo nivel de rigor. Identificar las partes críticas y aplicarles disciplina extra es ingeniería madura.
La cultura de simulación y digital twins
El JPL mantiene réplicas físicas y digitales del rover durante toda la misión. Cuando los operadores planean una secuencia de movimientos en Marte, primero la ejecutan en el gemelo de tierra. Eso permite detectar problemas (cables atorados, terreno mal interpretado, secuencias mal calculadas) antes de mandar comandos al planeta vecino.
En el mundo empresarial, este concepto se llama digital twin y se ha vuelto popular en manufactura industrial. Pero la idea es transferible a software: tener entornos de pre-producción que reproducen lo más fielmente posible el comportamiento del entorno real. Muchos equipos de empresas mexicanas que conocemos tienen "stage" como una versión recortada y poco realista de producción. Acercar staging a producción es trabajo aburrido pero paga dividendos enormes en confiabilidad.
Lección cuatro: invertir en simulación realista de producción es una de las mejores apuestas de productividad de un equipo de ingeniería.
Qué inspira y qué no aplica
No queremos sugerir que toda empresa debe operar como NASA. Sería absurdo, ineficiente y caro. La velocidad de iteración rápida que permite Internet es una ventaja real para la mayoría de productos comerciales. El equilibrio entre velocidad y rigor es siempre contextual.
Lo que sí inspira y sí aplica es la actitud. La ingeniería de software de misión crítica trata cada decisión con respeto, documenta cada componente, asume que el costo de un error es real, busca confiabilidad como atributo de primera clase. Esa actitud, llevada a las partes correctas de cualquier producto comercial, eleva la calidad de manera que se nota.
Para los líderes de ingeniería en empresas mexicanas medianas: vale la pena, este trimestre, identificar los tres o cinco componentes de tu sistema donde una falla genera daño serio. Y para esos, aplicar un nivel de rigor más cercano a JPL que a startup en sprint de viernes. No para frenar el resto, sino para proteger lo que importa.
Perseverance va a estar explorando Marte por años. Cada movimiento que hace lleva detrás miles de horas de ingeniería que casi nadie verá. Esa invisibilidad del trabajo bien hecho es una constante de la buena ingeniería, dentro y fuera del sistema solar.
¿Quieres elevar prácticas de ingeniería en tu equipo? Conversemos. En ALCA acompañamos a equipos técnicos a definir prácticas de ingeniería diferenciadas según criticidad, sin caer en burocracia inútil. Agenda una sesión sin costo.
