On AGI Framework Integration for SSA activities

As stated on Wikipedia, the Space Situational Awareness (SSA) Program is the European Space Agency's (ESA) initiative designed to support Europe's independent space access and utilization through the timely and accurate information delivery regarding the space environment, and particularly hazards to both in orbit and ground infrastructure. The SSA program is split into three main segments:

•  Space weather (SWE) segment: monitoring the Sun, the solar wind, and in Earth's magnetosphere, ionosphere and thermosphere, that can affect spaceborne and ground-based infrastructure or endanger human life or health;
• Near-Earth objects (NEO) segment: detecting natural objects, such as asteroids and comets, which can potentially impact Earth;
• Space surveillance and tracking (SST) segment: Tracking active and inactive satellites and space debris (collectively these items are referred to as Resident Space Objects -RSOs).

The SST segment's primary goal is the detection, storage and orbit prediction of objects orbiting the Earth. It is part of an effort to avoid collisions between orbiting satellites and debris, provide safe reentries, detect on-orbit explosions, assist missions at launch, deployment and end-of-life and overall reduce cost of space access.

AGI (now part of ANSYS, Inc.) provides a complete set of APIs (as part of the well-known STK Systems ToolKit and ODTK Orbit Determination ToolKit) to build an SST related end-to-end flight dynamics system and to use it during operation. This article aims to explain how AGI technology can be used to implement a fully automated SSA/SST system.

The figure below shows a typical SST workflow:

Catalog Processing

The process starts with the reception, from the available sensors, of satellite’s tracking data. The SST segment currently relies on existing European radar and optical systems. Some of its assets are existing radio and optical telescopes, with now serving a secondary role for tracking space debris.

Preliminary Processing

Tracking data could be referred to known objects (such as cooperative satellites) or unknown objects (such as debris). The unknow objects have to be correlated first (they need to be identified and related to a specific catalog ID); also, in case of active satellite tracking, a non-cooperative maneuver may occur in between tracking sessions. In this case it would be useful to estimate the maneuver epoch/magnitude to better assess the in-orbit activities of that specific object.

Evaluating which object may have been passed through the sensor’s field of view at specific epoch is a crucial step of the entire process. This can be accomplished directly inside STK by using the Deck Access Tool.

Orbit Determination

When all the objects have been correlated and all maneuvers have been estimated and/or implemented, the actual orbit determination process takes place. Even if ODTK does not provide an independent set of APUs like STK does, it is fully automatable by using external scripts. The main steps to follow during the orbit determination are highlighted here below:

ODTK provides different capabilities to estimate the satellite initial state, depending on the information available. The estimate is then used in conjunction with the appropriate models (of both tracking stations and satellite force model) to let the Least Squares and/or the Extended Kalman Filter estimate the satellite state over time (among other things, the filter is able to estimate any unknown variable in the system state space). The solution from the filter is then smoothed to refine the solution and to validate it with specific consistency tests. If any the consistency test fails, some of the given inputs have to be changed (this may involve the tracking station bias model, satellite force model or satellite initial state) and the process has to be repeated until all the tests are passed.

The main scope of the OD process is to provide satellite’s ephemeris with covariance (the level of uncertainty around the estimated solution). Having the consistency tests passed in ODTK will assure that the covariance provided is realistic. This is a crucial aspect for many of the possible applications in the SST framework, such as the close approach analysis. Ephemeris can either be provided for the provided tracking data time span (in order to perform a forensic analysis on the past states of the satellite) or as estimates for future states. The latter option is the one that allows the creation of flight dynamics products.

Flight Dynamics Products

The prediction of future state/covariance values is crucial for many aspects of the operational processes. We’ll shortly see which kind of products can be created/delivered.

Visibility Data

The simplest application is the calculation of future pass data (azimuth, elevation and range) over the ground station(s) for contact/tracking planning. When two or more satellite are passing over the same ground station at the same time, some deconflicting algorithm is required to optimize the contact times. A tool like STK Scheduler is normally required to perform this analysis. Scheduling tracking activities on the same satellite from two different ground stations helps in reducing the overall covariance, as demonstrated by the following figure (this concept is called sensor fusing):

Conjunction Assessment

Space is becoming very crowded. JSpOC (Joint Space Operations Center) is currently tracking more than 23000 objects in space, but looking at the latest estimates by the European Space Agency report a dramatically increasing numbers:

• 29000 - for sizes larger than 10 cm
• 670000 - for sizes larger than 1 cm
• More than 170 million - for sizes larger than 1 mm

The currently ongoing development of very large constellations (Starlink, OneWeb etc.) is furtherly increasing the probability of collision (especially in LEO regime) and an accurate (and fast) evaluation of close approaches is required. STK provides (in a specific toolset called CAT – Conjunction Analysis Tool) all the analytical capabilities to evaluate the PoC (Probability of Collision) occurring between any pair of objects whose minimum separation distance goes below a specific threshold. This evaluation requires the knowledge of different parameters (basically the physical dimensions of the objects, the minimum estimated distance and covariance value at TCA - Time of Close Approach).

By using CAT and some custom code the users would be able to generate and/or interpret CDM (Conjunction Data Messages), the standard format for sharing conjunction-related information. In the image below an example of custom implementation is provided. It has been build using the STK Engine approach (see below for additional info), and incorporates specific routines to evaluate the PoC under different assumptions about the expected covariance at TCA.

The user only needs to load a CDM file and optionally add custom input data. The relevant STK scenario will be built at runtime, providing an enhanced situational awareness about the geometry of the close approach and a quick estimation of all the other parameters related with it.

Reentry Analysis

We normally discriminate a reentry between de-orbit or decay:

• De-Orbit is a forced re-entry to remove a satellite from Earth orbit using a maneuver or external force to allow the vehicle to re-enter over a certain region (i.e. Pacific Ocean). These events can be planned inside of Astrogator and can use the target sequences to attempt re-entry over a specific region;
• Decay is a natural Re-Entry that removes a satellite from Earth Orbit. This re-entry is uncontrolled and it is unclear where exactly the vehicle will touchdown.

STK provides a fully numerical propagator called HPOP (High Precision Orbit Propagator). HPOP allows the definition of every detail regarding both the force model and the numerical integrator, in such a way we can configure it accordingly with the problem to solve. For reentry analysis low-altitude density models have to be used, together with a precise estimate of the solar flux and satellite physical data. That information can be embedded into a template, that can then be used in the simulation.

Once again, the analytical capabilities of STK can be wrapped into a custom application being able to automate analysis and report back to the user a wide set of information. The figure below shows the results of a Montecarlo analysis made on top of a TLE relevant to a decaying object. Accordingly with the estimated uncertainty around its initial state, multiple initial states are guessed and a complete propagation (until the satellite reaches the Earth surface) is performed. The results are then used to generate a likelihood map for the impact location. A similar estimate can be done for the reentry epoch.

Threat Assessment

Space is a harsh environment, where each active satellite could potentially be used as a weapon simply using its kinetic energy against other objects. A collision in space not only leads to the loss of the assets under consideration, but would be extremely dangerous due to the debris cloud generated by the impact. Threat assessment allows to evaluate if, among the tracked satellites, a potential hostile maneuver occurred (this means that, after the maneuver, the new orbit will be in a collision course with a specific satellite).

Threat assessment can realistically occur only after we have an updated and accurate orbit estimates for the catalog, especially after non-cooperative maneuvers. But how we can determine if a maneuver was normal or abnormal? Normal maneuvers are assessed from the space object’s pattern-of-life. For example, most of the station keeping maneuvers for GEO satellites are executed on weekly basics.

We define abnormal maneuvers the ones that do not fit the historical pattern-of-life. Abnormal maneuvers are further characterized as potentially hostile or non-hostile. Non-hostile (but still abnormal) maneuvers can be due to spacecraft anomalies, end-of-life disposal, station-change, change of normal station-keeping patterns, seasonal changes, etc. Potentially hostile maneuvers need to be analyzed to examine potential targets and threat type (i.e. kinetic kill, hostile proximity operations, etc.)

The Space Object Threat Analysis (SOTA) tool was designed to assess vulnerability of any space object due to the action of another space object.

SOTA can perform assessment in various modes: one-on-one, one-on-all, all-on-one, all-on-all. It can look at any detected maneuver and perform assessment of who is (are) the likely target(s) in a rank ordered list of vulnerable targets using specific metrics that lead to the determination of level of risk – the so called the Vanguard number.

Maneuver Planning

As discussed in the previous section, most of the active satellites have to be maneuvered on regular basis to overcome the disturbing forces acting on it. Also, in case of close approaches whose probability of collision is higher than a specific threshold, a collision avoidance maneuver has to be executed. Finally, operational missions sometime require Rendezvous and Proximity Operations – a well defined set of maneuvers to let two (or more) spacecraft have a specific relative motion.

All of those cases need a specific set of time tagged actions – namely a procedure. STK has a really powerful flight dynamic engine called Astrogator through which the operator can design, test and validate any possible procedure involving maneuvers and orbit changes.

Astrogator is a specialized analysis module for interactive orbit maneuver and spacecraft trajectory design. It acts as one of the propagators available for a satellite object and is able to calculate the satellite's ephemeris by executing a Mission Control Sequence, or MCS, that you define according to the requirements of your mission. MCS is a visual programming language that incorporates all the elements (conditional loops, logical operators, subroutines…) necessary to accomplish a non-linear workflow. An example of MCS is reported below:

The MCS is composed by a list of elements called segments whose order of execution is controlled either from the GUI or using a programming language. The architecture is open and interoperable, with comprehensive API for scripting and integration.

Astrogator can solve any type of complex problem by using a specific segment called Target Sequence, that allows the definition of independent variables (e.g. the delta-V) to get a specific result (e.g. altitude of apoapsis). It also allows the complete configuration of the elements used to perform the calculation (called components). For example, the user can create a specific numerical propagator for each phase of the mission. The figure below shows the pattern of a controlled geostationary satellite within its station keeping control box. Astrogator is able to automatically execute a station keeping procedure any time an intended threshold (e.g. max inclination) is reached.

The capability of being incorporated into an execution flow makes Astrogator the ideal tool for flight operation management and planning. The way in which it can be done is explained in the next section.

Framework Integration

We finally arrived to the last step: an organic integration of the previously mentioned tools and applications into a complete flight dynamics suite. We’ll consider STK and ODTK the two pillars of the system; all the other tools can be thought as the implementation of specific workflows of the native capabilities of both tools.

The levels of integration span from no integration at all (operators have to manually configure the software and run the analysis) to a fully automated process, where all workflows are automated and the operators can spend most of their time analyzing results. This is of course the most ambitious goal, but is somewhat forced when the operations involve a large number of satellites. The ways in which the integration/automation can be realized are summarized in the figure below:

• With Desktop Extensibility we mean the ability to create additional components (namely plugins) that can help in executing a specific process. Specifically, the UI Plugins bring into STK custom user interfaces;
• With Automation we mean the ability to run STK/ODTK in co-simulation with other tools, allowing real-time data exchange between them;
• With STK Engine we mean the ability to embed the analytical and graphical engines of STK/ODTK inside custom apps. An example of STK engine app is shown in the Conjunction Assessment section.

The figure below shows the possible architectures to run STK/ODTK in co-simulation mode:

• Component Object Model COM) is a binary-interface standard for software components introduced by Microsoft in 1993. It is used to enable inter-process communication and dynamic object creation in a large range of programming languages.
• TCP/IP is an Internet protocol suite that provides end-to-end data communication. Using TCP/IP, STK can be automated with Connect commands, an ASCII based command syntax that doesn’t require any coding skill.

This architecture is so versatile to allow a wide variety of different approaches. Just as example, in the figure below is shown a co-simulation between STK and Simulink for the design of attitude change procedures. The rotational mechanics equations and the controller are implemented in Simulink, while STK provides attitude information and a compelling visualization of the satellite attitude over time:

Conclusions

We’ve seen as AGI provides the state of the art in terms of analytical instruments to execute end to end satellite operations: STK and ODTK can work together to fully accomplish any given task. Using automation & integration will enhance these capabilities, allowing more flexibility and simplicity and in, turns, allowing operators to take under full control any aspect of their SSA related activities.