ASTRONÓMICA

Conferencia de la Astronómica de Sabadell. Marc Ribell, 29 de octubre de 2025.

Hoy hablaré sobre el análisis de riesgos de retorno en trayectorias interplanetarias. En concreto, sobre un proyecto en el que estamos trabajando ahora para la Agencia Espacial Europea, que se llama PlanetSSA. Primero haré una breve introducción a qué es SST, el departamento y el ámbito en el que trabajo. Después haré una breve introducción a PlanetSSA, el proyecto que presentaré hoy. A continuación, hablaremos un poco de los modelos matemáticos y del software que utilizamos. Posteriormente comentaré los módulos en los que hemos dividido esta herramienta que estamos desarrollando y, finalmente, comentaré cuáles son los pasos siguientes, porque este proyecto ahora mismo está en curso, no está acabado y, por tanto, faltan cosas por hacer.

Empezaremos con una breve introducción a SST. En primer lugar hemos de hablar de la basura espacial, aquellos objetos en desuso hechos por el ser humano, enviados al espacio y que ya no cumplen ninguna función útil. Estos objetos nos pueden molestar porque pueden chocar con satélites activos o pueden reentrar de manera descontrolada y causar daños. ¿Y por qué estos objetos no caen? Una manera en la que podemos pensarlo es que, a la vez que un objeto cae, se desplaza horizontalmente porque van muy rápidos y entonces no llegan a caer nunca. Veamos un resumen en números de la situación actual (Figura 1), a ver si nos tenemos que preocupar o no. Tenemos unos 26.000 objetos controlados desde la Tierra ahora mismo, en órbita terrestre. De estos 26.000 objetos, tenemos 2.040 fragmentos de cohetes, 2.800 satélites que ya no funcionan y unos 21.000 objetos que son escombros, es decir, partes de satélites que están por ahí.

Figura 1. Basura espacial.

Y después, en base a esto, también podemos estimar más o menos el resto de objetos más pequeños que no somos capaces de seguir desde la Tierra. Los círculos azules son los que podemos seguir desde la Tierra y los que están en rojo son los que no podemos seguir desde la Tierra, porque son pequeños, pero es lo que podemos estimar. Estimamos que hay unos 36.500 objetos más grandes de 10 centímetros, alrededor de un millón de objetos de entre 1 y 10 centímetros, y unos 130 millones de objetos entre un milímetro y un centímetro, que son pequeños pero van a velocidades muy elevadas y pueden causar daños muy grandes.

Figura 2. Evolución del número de objetos en órbita terrestre a lo largo de los años.

En la Figura 2 tenemos una evolución de los objetos en órbita terrestre a lo largo de los años. He marcado aquí tres picos, tres crecimientos súbitos. El primero es el ASAT Fengyun. Un ASAT es un test antisatélite que es un cohete enviado solo para chocar con un satélite, para reventarlo, básicamente. Son pruebas militares. Con este choque se producen muchos fragmentos de este satélite que, al final, son muchos más objetos que hemos de seguir, que hemos de controlar, etc. Después tenemos el Iridium-Kosmos, que fue un choque entre dos satélites, un Iridium y un Kosmos, que también hizo aumentar los escombros espaciales. Finalmente, también uno que es bastante reciente, del 2022, que fue un ASAT de un Kosmos.

Otra cosa bastante evidente es que en los últimos 10 o 15 años no solo han aumentado los objetos en órbita, sino que también ha aumentado la velocidad a la que enviamos objetos al espacio.

Ahora que sabemos más o menos la situación actual, podemos hablar de SST. Son las siglas de Space Surveillance and Tracking (Vigilancia y Seguimiento Espacial, en español). La parte de surveillance, que es “vigilancia”, es básicamente observar el cielo para detectar nuevos objetos. Y tracking, que significa “seguimiento”, es hacer el seguimiento de estos objetos para tenerlos controlados y conocer su órbita con más precisión. A veces, también se usan los términos SSA (Space Situational Awareness) –por eso el proyecto del que hablaremos se llama PlanetSSA– y SDA (Space Domain Awareness). Este último término se usa más en ámbitos militares.

Además de vigilar y seguir estos objetos, dentro del ámbito de SST, también se llevan a cabo diversas actividades. Las principales son los controles de evitación de colisiones, de reentradas y de fragmentaciones.

Hasta ahora, la mayoría de objetos que enviamos al espacio se quedan en órbitas terrestres por dos motivos principales. El primero es porque es más barato y el segundo es porque las funciones que queremos que hagan ya las pueden hacer lo suficientemente bien cerca de la Tierra. Pero hay muchas misiones que viajan más allá de la Tierra, y todos los objetos que enviamos más allá tienen una cierta prioridad de retorno. Cuando un objeto en estas trayectorias más allá de la Tierra retorna, lo hace con mucha más velocidad y, por tanto, con mucha más energía. Es decir, los daños que podría causar son bastante mayores.

Es por eso que, con la Agencia Espacial Europea, estamos desarrollando el proyecto PlanetSSA. Es un proyecto liderado por GMW, que es la empresa donde trabajo yo, en un consorcio con otras dos empresas, que son HTG y Maity Space. El objetivo principal del proyecto es desarrollar una herramienta que sea capaz de realizar un cálculo estadístico de ciertos riesgos que tienen estas misiones interplanetarias. Los principales objetivos de cálculo son la probabilidad de retorno de una emisión, la capacidad de determinación orbital –es decir, hasta qué punto somos capaces de realizar una determinación orbital de una de estas trayectorias de retorno–, la probabilidad de colisión con satélites a la hora de retornar, la probabilidad de reentrada y, finalmente, el riesgo de víctimas. Uno de los objetivos de esta herramienta es ser capaces de asesorar si se cumplen ciertas directrices que marca la Agencia Espacial Europea, que están divididas en dos documentos. El primero hace referencia a las reentradas y el segundo es sobre la mitigación de basura espacial.

Respecto a la reentrada, los puntos clave son los siguientes: la probabilidad de víctimas ha de ser inferior al 0,01%, los tanques presurizados y explosivos no han de liberar energía de manera violenta al impacto, los productos químicos y peligrosos bajo la regulación de la Unión Europea no han de llegar a la superficie de la Tierra, las sustancias radioactivas requieren la aprobación bajo política de fuentes de energía nuclear de la Agencia Espacial Europea, … Un punto clave muy importante es que el diseño ha de intentar que el mismo objeto se desintegre en la reentrada. Es decir, que llegue lo mínimo posible del objeto a tierra y, en caso de reentrada controlada, la zona de reentrada ha de evitar el suelo, las aguas territoriales y las zonas marítimas protegidas. Además, las zonas económicas exclusivas requieren de una notificación previa.

Hablemos ahora del segundo documento, que hace referencia a la mitigación de escombros espaciales. El primer punto es sobre la prevención de fragmentación. Está completamente prohibida una fragmentación voluntaria, y la probabilidad de causas internas como explosiones de tanques o fallos de baterías ha de ser inferior al 0,1%. En términos de evitación de colisión, si queremos enviar un satélite a una órbita geoestacionaria, hemos de asegurarnos de que este satélite tenga capacidad de hacer maniobras de evitación de colisión.

En cuanto a la aseguración de eliminación, el primer punto dice que si enviamos un satélite a una órbita terrestre baja, hemos de asegurar que este objeto reentre como máximo antes de 25 años después de haberlo puesto en su órbita final. En órbitas geoestacionarias, los objetos se habrán de enviar a una órbita de 235 km por encima del anillo geoestacionario. Es lo que llamamos órbita cementerio, y allí básicamente no molestan. Los dos últimos puntos de este apartado son los que nos interesan más en esta conferencia, porque son los que se aplican a objetos que van más allá de la Tierra. El primero nos dice que al final de la vida útil hemos de mover el objeto a una órbita que no moleste. Recomienda una órbita heliocéntrica –es decir, alrededor del Sol–, pero otras alternativas serían una órbita de impacto lunar, una reentrada a la Tierra –controlada siempre–, o una órbita cementerio lunar con un análisis de estabilidad de 100 años. Es decir, hemos de asegurar que con 100 años no haya peligro y garantizar también que no se vuelva a entrar en las regiones terrestres protegidas, que son las órbitas terrestres bajas (LEO, de Low Earth Orbit) y de las órbitas geoestacionarias (GEO).

¿Cómo se plantea esto? En la Figura 3 tenemos el diseño a alto nivel del proyecto. Después entraré más en cada uno de los módulos, pero de los que más hablaré son los que están encerrados con el círculo rojo, porque son los que estamos desarrollando en GMW y, por tanto, me los conozco mejor.

Figura 3. Diseño a alto nivel del proyecto PlanetSSA.

La idea es la siguiente, muy resumidamente. En el primer módulo tenemos la generación de trayectorias. Aquí se generan las trayectorias que consideraremos de referencia. Con estas trayectorias hacemos un cálculo de los eventos. Aquí lo que calculamos es cuándo seremos capaces nosotros de observar o de tomar medidas de estos objetos. Después pasamos estos intervalos de tiempo al módulo de simulación y observaciones, y allí simulamos observaciones de telescopio o de radar y, en estas observaciones, podemos realizar las determinaciones orbitales. Seguidamente, con la determinación orbital obtenemos la órbita del objeto calculada por nosotros, es decir, un poco más realista. Después lo pasamos por una interfaz de trayectorias, que no es más que un adaptador de información, y después lo pasamos al módulo de riesgo de colisiones, donde se evalúa el riesgo acumulado cuando este objeto cruza las regiones protegidas. Al mismo tiempo, también se pasa la información orbital al módulo de reentradas y fragmentaciones, y después estos fragmentos al módulo de riesgo de víctimas.

Antes de empezar nos teníamos que hacer un par de preguntas importantes. La primera es qué modelos matemáticos usamos y la segunda es qué herramientas de software utilizar.

Empecemos por la primera pregunta. ¿Cómo podemos hacer estos cálculos? ¿Cómo podemos propagar estas trayectorias? Depende de la precisión que queramos, podemos elegir un modelo u otro. Pero hemos de tener en cuenta que, cuanto más precisión nos dé el modelo, más coste computacional tendrá. Idealmente, deberíamos encontrar un modelo que sea un equilibrio entre precisión y coste computacional.

Hablemos ahora de propagación orbital, que trata básicamente de, sabiendo un estado, poder calcular dónde estará un objeto en el futuro. Cuando hablo de estados, hablo en nuestro caso de un vector estado de seis componentes. Como es un espacio tridimensional, tres componentes para la posición y tres componentes para la velocidad. Si yo sé estas componentes en un tiempo 1 (t1), con un modelo puedo saber dónde estarán en un tiempo 2 (t2) y viceversa. Esto es la propagación orbital. Entonces, cuando hablamos de modelos, el más sencillo que podemos encontrar es el modelo kepleriano, que básicamente asume dos cuerpos, uno de ellos sin masa y el otro simplificado en un punto de masa. La órbita del segundo objeto siempre es una sección cónica, ya sea un círculo, una elipse, una parábola o una hipérbola. Es el modelo más sencillo y el más barato de simular.

Lo que pasa es que no todo es tan bonito. Si queremos pasar del modelo a la realidad, vemos que, primero, la Tierra no es una esfera perfecta, tiene una atmósfera que frena los satélites, la radiación solar también tiene un efecto sobre estos y al mismo tiempo hay otros astros que también ejercen una fuerza gravitacional sobre nuestro objeto. Los más importantes son la Luna, el Sol y Júpiter. Lo que podemos hacer para tener en cuenta estas contribuciones, que es un poco barato computacionalmente hablando, es poder añadir precisión al modelo añadiendo perturbaciones. Las principales perturbaciones son la protuberancia ecuatorial –el hecho de que la Tierra está achatada por los polos–, el efecto de la presión solar y también el rozamiento.

Figura 4. Valor de las perturbaciones en función de la altitud.

Para hacernos una idea del orden de magnitud de las perturbaciones en base a cada altitud, el gráfico de la Figura 4 va muy bien. Aquí nos dice básicamente que cuando estamos en órbitas muy bajas, lo que nos afecta muchísimo es la protuberancia ecuatorial. Después encontramos otros componentes de la no esfericidad de la Tierra. A más altitud, nos molestan bastante la Luna y el Sol. Después, decreciendo de orden de magnitud, tenemos efectos de la presión de radiación solar y, finalmente, de correcciones debidas a la relatividad. El drag (rozamiento con la atmósfera) es un poco curioso, porque es cierto que no tiene un efecto muy grande. Nos importa más en órbitas bajas, pero el problema que tiene es que es muy difícil de modelar, porque hay muchísimos factores que le afectan.

Con el modelo del problema de los dos cuerpos, podemos enlazar varias trayectorias con lo que se llama patched conics, enlazando secciones cónicas. Es una simplificación y con esto podemos calcular también órbitas interplanetarias. Este modelo asume que siempre estamos solo bajo la influencia de un solo cuerpo. Si hacemos una trayectoria de la Tierra a Marte, al principio solo estamos bajo la influencia de la Tierra. Cuando escapamos de la gravedad de la Tierra, asumimos que solo estamos bajo la influencia del Sol. Finalmente, cuando entramos en la esfera de influencia de Marte asumimos que el único cuerpo que nos afecta es Marte.

Si nos alejamos un poco de la Tierra, encontramos el problema de los tres cuerpos restringido, que es bastante útil sobre todo en el espacio cislunar. En vez de tener dos cuerpos, uno con masa y uno sin, tenemos dos cuerpos con masa y otro sin. Es muy útil para objetos que están muy lejos de la Tierra o en órbitas lunares altas, o bien en medio. Es un modelo de especial interés porque allí encontramos los famosos puntos de Lagrange, que es donde se han enviado y se plantean enviar muchas misiones. Pero tiene un pequeño problema para nosotros, y es que es un régimen caótico. Después lo comentaremos con un poco más de detalle.

Si queremos aún más precisión, existe el modelo full ephemeris, que básicamente es un modelo en el que tenemos en cuenta tantos efectos gravitacionales como queramos. Si queremos hacer una aplicación de alta fidelidad, los efectos gravitatorios de otros planetas también se han de tener en cuenta. Estas pequeñas perturbaciones pueden dar lugar a un comportamiento inesperado y órbitas que aparentemente son estables pueden acabar en impactos planetarios. Y también, igual que el anterior, es un régimen caótico.

Después de mirar si nos podíamos escaquear, resulta que no: en el régimen interplanetario, si queremos una aplicación fiel, necesitamos un modelo preciso. Y este modelo no puede ser otro que el de full ephemeris. Es decir, hemos de tener en cuenta varios astros para nuestra propagación. Y, además, también hemos de modelar la presión de radiación solar y, cuando la trayectoria se acerca a la Tierra, también hemos de tener en cuenta el drag, es decir, la fricción con la atmósfera.

Hay otro concepto que es muy importante, que también nos condicionará bastante la herramienta, que es la incertidumbre. Porque hemos hablado de propagar y hemos hablado de calcular un estado, pero siempre que calculamos una posición o un estado tenemos una incertidumbre asociada. No tenemos medidas infinitamente precisas, ni tenemos modelos perfectos. Por tanto, siempre tenemos una incertidumbre asociada a un estado. Y esta incertidumbre, en nuestro caso, viene dada principalmente por la precisión de los sensores –es decir, de los telescopios, láseres o radares–. La parte positiva es que la podemos modelar bastante bien. La podemos representar con la matriz de covarianza, que es una matriz simétrica y básicamente es una distribución gaussiana multivariante. Los elementos de la diagonal son las varianzas y los componentes cruzados son las covarianzas –es decir, cómo afecta un error de una componente al error de otra componente–.

En órbitas terrestres esta incertidumbre la podemos propagar de manera analítica. Esto lo hacemos con la matriz de estado de transición, que es una aproximación que consiste en hacer una linealización del sistema. Es muy útil porque con un coste computacional muy bajo podemos conseguir propagar esta incertidumbre a lo largo del tiempo. Esta aproximación no nos sirve indefinidamente pero, por los marcos de tiempo con los que trabajamos en horizontes terrestres, nos sirve bastante bien. Y también podemos, en vez de propagarla de manera analítica, propagarla con un método de Monte Carlo.

Para los que no saben qué es el método Monte Carlo es bastante sencillo, es un método estadístico fácil de explicar. Imaginad que yo tengo un dado que tiene seis caras. Si lo tiro muchas veces, seguramente caerá siempre las mismas veces, el 1, el 2, el 3, el 4, el 5 y el 6. Pues, imaginad que nos dan un dado que está trucado, pero no sabemos cómo y lo hemos de averiguar. Pues yo lo que podría hacer es lanzar este dado muchísimas veces –cien, mil, diez mil, …– y podría mirar dónde ha caído más veces y así sabría cómo está trucado. Pues el método de Monte Carlo consiste en eso, es un análisis estadístico con muchísimas muestras.

El problema que tienen siempre los análisis de Monte Carlo es que computacionalmente son muy caros, porque hemos de simular lo mismo muchísimas veces. Por desgracia para nosotros, en regímenes caóticos no podemos propagar la matriz de covarianza de manera analítica porque la aproximación lineal no nos sirve. Entonces, la única herramienta fiable que nos queda es el método de Monte Carlo, que es computacionalmente bastante caro.

En regímenes caóticos, una perturbación muy pequeña en las condiciones iniciales nos condiciona muchísimo, dado que hace variar mucho las condiciones finales. Esto es un poco la explicación por la que no podemos propagar de manera analítica la matriz de covarianza. Entonces, sabiendo que estamos condenados sí o sí a usar el método de Monte Carlo, ahora podemos elegir el software que nos ayudará. Nos presentaron dos opciones –las dos de la Agencia Espacial Europea, porque barrieron para casa–.

Las dos opciones son GODOT y CUDAjectory. GODOT es una biblioteca de astrodinámica que es muy completa, está escrita en C++, se desarrolló en el ESOC, que es el centro de operaciones de la Agencia Espacial Europea, y es muy potente. La otra herramienta que nos presentaron se llama CUDAjectory, que no es una biblioteca sino un propagador de trayectorias y está basada en GPU –esto es muy importante porque nos permite paralelizar de manera masiva–. Se centra en lotes de propagación muy grandes (Monte Carlo, protección planetaria, etc.).

Resumidamente, GODOT es una biblioteca con funciones muy completas. Cuando propagamos una trayectoria nos permite obtener los estados intermedios pero tiene el problema de que es computacionalmente muy intensivo. Por otro lado, la ventaja principal de CUDAjectory es que es muy rápido y computacionalmente muy barato, siempre que tengas una GPU. Uno de los problemas que tiene es que, en principio, no permite obtener los estados intermedios y tiene muchísimas menos funcionalidades analíticas. Entonces, al final, después de meditar bastante y hacer varios estudios vimos que podíamos intentar combinar los dos e intentar coger lo mejor de cada mundo. GODOT está escrito con C++ y CUDAjectory está escrito con CUDA, pero los dos tienen interfaces con Python que podemos usar.

Ahora que sabemos más o menos qué vamos a usar, podemos comentar un poco los módulos que hemos desarrollado o que estamos desarrollando. Porque uno de los requisitos también es que la herramienta ha de ser modular, y cada módulo lo hemos de poder ejecutar individualmente o tantos como queramos. Es decir, no solo poder hacer una ejecución de principio a fin, sino que hemos de poder elegir qué módulos queremos ejecutar a voluntad. Por tanto, cada módulo ha de ser independiente.

El primer módulo que encontramos es el de generación de trayectorias. En este módulo se generan trayectorias que consideramos verdad fundamental, es decir, las trayectorias de referencia. ¿Cómo hacemos esto? Pues lo primero que hacemos es generar las condiciones iniciales. Lo que le llega a la herramienta es un estado y una incertidumbre. Puede ser con simplemente las varianzas o directamente con la matriz de covarianza. Y con esto, la herramienta genera muchas condiciones iniciales. Nosotros estamos trabajando ahora mismo con alrededor de 100.000 condiciones iniciales. Una vez las tenemos, las propagamos. Y aquí es donde entra en juego la combinación entre CUDAjectory y GODOT. Lo que hacemos, primero de todo, es propagar todas las trayectorias con CUDAjectory porque es muy rápido y muy eficiente. Recordemos que estas trayectorias las hemos de propagar durante 100 años, que es bastante tiempo. Una vez hemos propagado todas estas trayectorias, miramos cuáles han entrado dentro de una cierta región de interés que hemos de definir nosotros. Esta región de interés la definimos sobre todo en base a nuestros sensores, porque nos interesa saber cuándo podemos empezar a observar un objeto.

Figura 5. Esquema de la propagación de trayectorias.

Antes os he dicho que con CUDAjectory no podíamos obtener estados intermedios. Pero afortunadamente están desarrollando esta herramienta ahora mismo y estamos en contacto con el principal desarrollador. De hecho, somos los primeros que la estamos probando y es una relación bastante fructífera para los dos, porque nosotros podemos dar feedback a los desarrolladores y, además, podemos pedir funciones que nos hacen falta a nosotros y que pueden ser útiles. Entonces, una de las funciones que hemos pedido es un cálculo de eventos, de manera que con CUDAjectory podemos saber cuándo una trayectoria entra dentro de una cierta región de interés que hemos definido y cuándo sale. Entonces, resumidamente, lo que hacemos con CUDAjectory es propagar todas las trayectorias, que son las de color gris en la Figura 5, y cuando una trayectoria entra dentro de la región de interés nos guardamos estos estados, que son las estrellas negras, y después estos estados los ponemos en GODOT y los repropagamos, porque así lo tenemos en el sistema de datos de GODOT y podemos hacer análisis posteriores.

Una vez tenemos estas trayectorias podemos pasar al cálculo de eventos, donde buscamos cuándo somos capaces de ver estas trayectorias con nuestros sensores. Por tanto, una vez tengamos la trayectoria del objeto y una red de sensores –un listado de características de telescopios o radares– podemos saber cuándo podremos ver un objeto. Primero de todo, se cargan los errores de trayectoria y la configuración de red de sensores. Los sensores terrestres se describen en múltiples parámetros, pero uno de los más importantes son la posición del sensor o telescopio. Y en el caso de telescopios espaciales, lo que usamos es la órbita nominal del telescopio y la incertidumbre de esta órbita. Después, con estos arcos de trayectoria, calculamos las visibilidades.

Para calcularlas, se tienen en cuenta las siguientes cosas. Primero de todo, sobre todo para los telescopios, cuándo es de noche y cuándo es de día. Porque si es de día, no podemos ver gran cosa. Después los eclipses, porque si tenemos un objeto en medio entre nuestro sensor y nuestro objetivo, no podremos ver nada porque nos lo tapará. Después tenemos la elevación mínima, porque si está muy bajo no lo podremos ver. Después los ángulos de fase de la luna del Sol, también la velocidad angular máxima –si el objeto del cielo se mueve muy rápido puede ser que nuestro sensor no sea capaz de seguir este objeto–, el ángulo mínimo con la Tierra –parecido al ángulo de fase que tenemos con la Luna del Sol– y finalmente el campo de visión –sobre todo para los radares, porque a diferencia de los telescopios no suelen tener monturas móviles, sino un campo de visión fijado–.

Estas clases que hemos creado de eventos –clases a nivel de programación– están basadas todas en el módulo de GODOT de eventos. Por eso nos interesa también mucho usar GODOT, porque tiene muchas herramientas para aprovechar y podemos construir sobre estas herramientas.

Después, una vez sabemos cuándo podemos observar estos objetos, podemos simular las observaciones. En el módulo de simulación de observaciones, simulamos las medidas, que después pasaremos al módulo de determinación orbital. Entonces, básicamente, con estos intervalos de visibilidad, y con las trayectorias y con la red de sensores, podemos realizar estas simulaciones. Para los sensores ópticos, se recupera un vector de dirección que va desde nuestro objetivo, desde el satélite, hasta el sensor. Y como GODOT tiene muchas funcionalidades que podemos aprovechar, también podemos aplicar varias correcciones. Se tiene en cuenta el tiempo de viaje de la luz y se aplican correcciones como la de la aberración y la relativista. Una vez hacemos un cálculo aproximado de la magnitud, también descartamos aquellas medidas que no llegan a una magnitud mínima. Es decir, si el objeto no es lo suficientemente brillante para que el sensor lo vea, lo descartamos.

Para las medidas de radar es bastante similar. Un radar no solo recibe información sino que también primero la ha de enviar, después este señal rebota con el objeto que nos interesa y vuelve. Esto es muy simplificado, evidentemente, pero es un poco el concepto. Entonces, con el radar, aparte de obtener las medidas de los ángulos, tenemos el range y el range rate. El range viene a ser la distancia a la que tenemos este objeto –como sabemos cuándo se envía la señal y cuándo vuelve, y dado que sabemos la velocidad de la luz, podemos calcular a qué distancia está el objeto–. El range rate es la velocidad a la que varía este range. Y también, de manera similar a lo que hemos hecho con los sensores ópticos, los sensores de radar tienen también un mínimo: se descartan las medidas que tienen una sección de radar equivalente (RCS) inferior al límite del sensor.

Una vez tenemos estas observaciones, las agrupamos con lo que se llaman tracks, que son un conjunto de medidas que nos dicen en qué dirección está el objeto. Usamos el estándar CCSDS TDM. Por cada época tenemos tres entradas, ángulo 1, ángulo 2 y magnitud, y eso es lo que aprovechamos nosotros. Una vez hemos simulado las medidas, podemos pasar a la determinación orbital, donde actualizamos la órbita que ya tenemos. Una de las cosas que se necesita para determinación orbital es una estimación inicial, que es un estado, y para esta estimación inicial usamos nuestra trayectoria de referencia, que es lo que consideramos verdad fundamental.

Con el proceso de determinación orbital podemos también obtener una covarianza, que nos interesa mucho. ¿Cómo hacemos esto? Básicamente cogemos el estado inicial, que se establece como el estado actual para la estimación. Con este se propaga hacia adelante o hacia atrás, dependiendo de cómo tengamos el estado. La idea es propagar para cubrir el track entero y cubrir todas las medidas que tenemos. Después se generan medidas sintéticas. Es decir, repetimos un poco lo que hemos hecho en el módulo anterior porque hemos de simular medidas otra vez y posteriormente calculamos los residuos de estas medidas y las comparamos con las medidas reales. A continuación se introducen estos residuales en nuestro solucionador, que resuelve el problema de estimación con un filtro de información de raíz cuadrada y nos devuelve una nueva trayectoria, un nuevo estado. Entonces este es el algoritmo, y repetimos estos pasos hasta que converja, es decir, hasta que nuestros residuales estén por debajo de un umbral que establecemos, o hasta que veamos que ya no mejora, o hasta que lleguemos a un número máximo de iteraciones. Es decir, al final lo que queremos encontrar es una trayectoria que se acerque más a nuestras medidas.

Una vez tenemos la determinación orbital, pasamos al módulo de interfaz de trayectorias, que es muy sencillo, ya que lo único que hace es adaptar la información que ya tenemos a los siguientes módulos. Esto es porque del módulo de determinación orbital lo que tenemos es un data frame –básicamente los estados con una organización de datos– y los dos módulos siguientes necesitan dos tipos diferentes de información. El módulo de riesgo de colisiones necesita los vectores estado de cuando el objeto cruza las regiones protegidas y el módulo de reentradas y fragmentaciones necesita un vector estado en coordenadas geodésicas a 120 km.

Una vez hemos hecho esto, podemos pasar al módulo de riesgo de colisiones. Aquí, como ya he comentado, pasaré por encima porque no lo domino tanto. Lo que sí os puedo comentar es que nuestros compañeros están usando un módulo de la Agencia Espacial Europea llamado MASTER, que es capaz de generar una población de satélites porque, como os podéis imaginar, si hemos de hacer análisis de 100 años, no podemos saber dónde estarán los objetos de aquí a 100 años con mucha precisión. MASTER nos ayuda a crear una población de objetos con un modelo estadístico. Lo que hacen en este módulo es primero discretizar el espacio, creando celdas de espacio como si fueran fronteras, y después con MASTER generan los objetos secundarios, es decir los posibles objetos con los que podrían chocar. A continuación, miran por qué celdas pasa nuestro objeto –nuestra trayectoria– y calculan las probabilidades de colisión con los objetos que se han generado. El resultado final es la probabilidad de colisión acumulada.

Hablemos ahora del módulo de reentradas y fragmentaciones. Este módulo, como ya he comentado, recibe un estado geodésico, un estado de un objeto a una altura de 120 kilómetros, que es lo que establecemos como reentrada. Usan también un software de la ESA llamado DRAMA (Debris Risk Assessment and Mitigation Analysis), que tiene varios componentes. Con este módulo y otros parámetros simulan la reentrada de este objeto. Durante esta, puede ser que el objeto se fragmente y en este caso se pasan los fragmentos al siguiente módulo, que también necesitará un modelado del objeto en 3D y se habrán de introducir parámetros de características de los materiales, etc.

Una vez lo tienen se pasa al siguiente módulo, que es el módulo de riesgo de víctimas. Y en este módulo se evalúa la probabilidad de que alguno de estos fragmentos caiga o llegue a una zona habitada. Se mira la densidad de población y con esto, más o menos, pueden obtener el riesgo de víctimas. Se obtiene un riesgo total para cada trayectoria, se analiza el riesgo asociado con cada fragmento y después la distribución del riesgo total se calcula y se producen unos outputs que pueden ser archivos de texto o directamente gráficos. Esto nos da la probabilidad total de riesgo de víctimas con las condiciones iniciales que hemos introducido al principio de la herramienta.

De todo lo que he explicado no todo está hecho, estamos trabajando en ello, pero esta sería una primera parte. Ahora brevemente comentaré los pasos siguientes que hemos de hacer. El primero es crear una interfaz de línea de órdenes (CLI), que no deja de ser una capa de alto nivel de software para poder gestionar todos los archivos y las ejecuciones. Como he dicho antes, uno de los requisitos es que hemos de poder ejecutar esta herramienta no desde el primer módulo sino desde donde queramos. De esto se encargará esta capa de alto nivel, que se dedicará a orquestar la ejecución y la gestión de archivos.

Después hemos de crear un producto integrado, que es muy sencillo. Se trata de, una vez tengamos todos los módulos hechos, encajarlos con la ayuda de esta CLI y asegurarnos de que todo funciona de manera encadenada.

Y después, finalmente, para asegurarnos de que funciona como queremos que funcione, hemos pensado en unos casos de prueba para poder probar la herramienta. Hemos pensado en varios casos que pueden ser interesantes. El primero es la última etapa de JUICE, que se lanzó con intención de reencontrarse con la Tierra, después de un par de maniobras, y como se ha de reencontrar con la Tierra, sabemos que esta trayectoria acabará retornando. Es un caso interesante.

Después tenemos la órbita nominal de la sonda Gaia, que estaba en una órbita en el sistema Sol-Tierra en el punto de Lagrange 2, en una órbita Lissajous. Los puntos de Lagrange son puntos de equilibrio pero son muy inestables: unas pequeñas perturbaciones pueden causar trayectorias inesperadas y desviaciones que hagan que finalmente acaben en la Tierra. Entonces también es un territorio de interés.

También tenemos la órbita de final de misión de Gaia, que es la órbita a la que han puesto Gaia cuando hace poco acabó su vida útil, para que no moleste. En teoría esta órbita se aleja lentamente de la Tierra, pero en algún momento se calcula que volverá a la proximidad de nuestro planeta.

Finalmente, la que ahora está última pero que al principio del proyecto era la primera prueba de caso de uso, es la Lunar Gateway, que es interesante por varios motivos, pero uno de ellos es porque tiene bastante interés mediático. Pero como sabéis en Donald Trump parece que está a punto de cancelarla y el proyecto quizás no se lleve a cabo, pero queremos aprovechar la trayectoria como caso de prueba. Al igual que la órbita Lissajous, está en un punto de equilibrio pero muy poco estable. Entonces, propagada a largo plazo, puede ser que esta órbita acabe en una trayectoria de impacto hacia la Luna o hacia la Tierra.

COLOQUIO

Esto es lo que hace la Agencia Espacial Europea. Las agencias espaciales de otras administraciones, como la NASA, Roscosmos, etcétera, ¿cada una hace una cosa similar? Sí y no. Cada agencia tiene su propio programa, por ejemplo, este proyecto es para la Agencia Espacial Europea, en concreto para el Space Debris Office, que es la parte de la ESA que se encarga de estos temas de basura espacial. También en Europa hay otra comisión independiente de la ESA.

Cada agencia sí que tiene sus propios proyectos de SST. Y hay algunos que, incluso, son conjuntos entre varios países o agencias. Pero aquí también entran temas de políticas entre países, de los cuales yo no domino mucho, la verdad.

Respecto al tema del coste computacional, ¿tenéis que usar superordenadores como el Barcelona Supercomputing Centre o no os hacen falta? No, no, porque en nuestro caso estamos desarrollando una herramienta que se ha de poder ejecutar en empresas normales. Uno de los requisitos precisamente es que el coste computacional no sea demasiado excesivo. Ha de ser una herramienta más portable, digamos.

¿Entonces está pensado para calcular trayectorias de muchos objetos o la gente que use la herramienta se preocupará del suyo, por entendernos? Las dos cosas un poco. El objetivo de PlanetSSA es que la Agencia Espacial Europea tenga una herramienta que pueda proporcionar a empresas europeas para que cada una pueda asesorar los riesgos que su misión puede llegar a tener y que, en consecuencia, pueda cumplir las directrices que marca la misma Agencia Espacial Europea.

Respecto al tema de la fragmentación, ¿esto es controlable? Porque da la sensación de que se deben tener unos márgenes de error bastante importantes. Sí. De hecho, respecto a las reentradas, últimamente hemos vivido unas cuantas que seguro que habéis visto por la televisión. Y si os fijáis, una cosa que hasta el último momento no se sabe es dónde caerá. Porque es muy difícil de prever sobre todo por lo que he comentado al principio, que el modelo atmosférico es muy difícil de modelar correctamente.