This post was intended as the start of a series on how to make a Twitter constellation visualization bot. However, recent updates to the Twitter API have meant that the repetitive nature of the posts have blocked the bot so I will be stopping this effort. I tried to modify my code to work with the new API but it has proved too time-consuming. Instead, I will be posting these GIFs to my personal website on a dedicated page.

Introduction

Inspired by the pioneering work of Jonathan McDowell’s Jonathan’s Space Report and T.S. Kelso’s CelesTrak, I embarked on a journey to create a unique project of my own. Over the Easter holidays, I developed a Twitter bot that provides daily updates on the current state of satellite mega-constellations. While my bot may not match the scale of Kelso and McDowell’s contributions, it’s my modest attempt to make satellite data more accessible and engaging for a broader audience.

Now that I have a working “version 1.0” of this Twitter bot, I’d like to share an overview of its creation process. Whether you’re interested in replicating it, contributing to the code, or simply curious about its inner workings, I hope you find this post informative. If you are curious to see it in action you can check out the Twitter bot here: ConstellationBot

About the Bot

The bot serves as a reliable resource, delivering daily status updates on the largest satellite mega-constellations - at present, it’s tracking the top 7. It’s designed in Python, utilizing the Tweepy library for interacting with the Twitter API. The bot functions autonomously through GitHub Actions and is activated by a cron job that triggers the Python script once daily. Future plans encompass augmenting its competencies with added features and visualizations.

This bot’s mission is to furnish a concise overview of the current state of major players in the arena, expediting the process of staying abreast with the newest advancements. Moreover, it visually illustrates constellation geometry, contributing critical insights into constellation operations such as orbit raising, deorbiting, anomalies, and shifts in geographical coverage. I’m in the process of enhancing a statistics module to accompany each visualization with relevant stats.

The code I share in this post serves only to shed light on the logic that fuels these scripts- I will be sharing the entire code repository in an upcoming post. For now, I hope this will inspire you to dive deeper, and perhaps use this method as a scaffold for you to create your own unique applications.

Method Overview

I will outline a broad overview and share some key functions that I used below.

1. Selection of Constellations: I chose to track the seven largest operational constellations: Iridium, Starlink, OneWeb, Planet, Spire, and Swarm.

2. Fetching Latest TLEs: Fetch the latest TLEs from Space-Track.org. I use the Python package spacetrack to do this. You will have to make a Space-Track account to use the API to fetch the latest TLEs for the selected constellations. Then you will manually have to do some digging around to find the constellation IDs for each constellation. For the ones I selected this ended up being:

   constellation_cat_names = {"starlink": "STARLINK", "oneweb": "ONEWEB", "planet": "FLOCK", "swarm": "SpaceBEE", "spire": "LEMUR", "iridium": "IRIDIUM"} 
   

3. Propagating TLEs: Use the Python package sgp4 to propagate the TLEs if required. Two of my visualizations (the constellation geometry and ground tracks), require the state to be propagated forward. I do this for one orbital revolution (or 2pi radians of argument of latitude). The SGP4 propagator will return Earth-Centred Inertial Coordinates in the TEME (True Equator, Mean Equinox) reference frame.

    import logging
    from typing import List, Union
    from sgp4.api import Satrec
   
    def sgp4_prop_TLE(TLE: str, jd_start: float, jd_end: float, dt: float) -> List[List[Union[float, tuple]]]:
        """
        Given a TLE, a start time, end time, and time step, propagate the TLE and return the time-series of Cartesian coordinates, 
        and accompanying time-stamps (Modified Julian Day). This is a wrapper for the SGP4 routine in the sgp4.api package (Brandon Rhodes).
   
        Args:
            TLE (str): TLE to be propagated.
            jd_start (float): Start time of propagation in Julian Date format.
            jd_end (float): End time of propagation in Julian Date format.
            dt (float): Time step of propagation in seconds.
   
        Returns:
            list: A list of lists containing the time-series of Cartesian coordinates, and accompanying time-stamps (MJD).
           
        Raises:
            ValueError: If jd_start is greater than jd_end.
        """
        if jd_start > jd_end:
            raise ValueError('jd_start must be less than jd_end')
   
        ephemeris = []
        dt_jd = dt/86400
        split_tle = TLE.split('\n')
        s = split_tle[0]
        r = split_tle[1]
        fr = 0.0
        satellite = Satrec.twoline2rv(s, r)
   
        time = jd_start
        while time < jd_end:
            error, position, velocity = satellite.sgp4(time, fr)
            if error != 0:
                logging.error('Satellite position could not be computed for the given date')
                break
            else:
                ephemeris.append([time,position, velocity])
            time += dt_jd
   
        return ephemeris
   

4. Plotting Positions: You will need to store the (/time series of) positions for each satellite after each TLE is propagated. Then you can use this data to plot the satellite positions in 3D. I use matplotlib to plot the satellite positions in 3D and I use the cartopy module for the map under the ground tracks. If you want to plot the ground tracks, you will have to convert the Earth Centred Inertial(ECI) coordinates into Earth Centred Earth Fixed (ECEF)coordinates. Then you will have to convert these to latitude and longitude to project them onto a map of the Earth. The astropy.coordinates provides methods to do both of these conversions accurately and painlessly.
   1. ECI to ECEF: Use the CartesianRepresentation() class and make sure you convert from GCRS to ITRS.
   2. ECEF to Lat/Long: Use the Transformer() class to convert from EPSG:4978 to EPSG:4326.

5. Animating Plots: To animate these plots I rotate the plots by 5 degrees about the z-axis and then save each new plot as a numbered frame (.png format ). I then use the PIL module to convert the pngs into a gif. For the large constellations this becomes pretty computationally intensive so I have included some use of the multiprocessing module to speed things up. This parallelizes the plotting of each frame- however for Starlink this still takes around 30 minutes (and fails in Github Actions)…

    import logging
    import multiprocessing as mp
    import os
    from PIL import Image
    import time
    from typing import Any
   
    def generate_geom_gif(const: str) -> None:
        """
        Generate a gif of the geometry of a constellation.
   
        Args:
            const (str): The name of the constellation.
   
        Raises:
            FileNotFoundError: If an image file does not exist.
            PermissionError: If the program does not have permission to delete an image file.
        """
        const_ephemerides, constellation_img_paths = process_geom_data(const)
   
        max_workers = 4 # Max number of processes that can run in GitHub Actions is 5. 
   
        gif_folder = os.path.join('images/constellation_anim/gifs/', const)
        images_folder = os.path.join('images/constellation_anim/current_geometry/', const)
        os.makedirs(gif_folder, exist_ok=True)
   
        with mp.Pool(processes=max_workers) as pool:
            pool.map(create_frame, [(az, const, const_ephemerides, constellation_img_paths) for az in range(0, 365, 5)])
   
        logging.info(f"Combining frames into gif for {const}...")
   
        images = sorted([img for img in os.listdir(images_folder) if img.endswith(".png")], key=lambda x: int(x.split('_')[-1].split('.')[0]))
        with Image.open(os.path.join(images_folder, images[0])) as first_image:
            image_list = [Image.open(os.path.join(images_folder, img)) for img in images[1:]]
            first_image.save(os.path.join(gif_folder, f'geom_{const}_{time.strftime("%y_%m_%d")}.gif'), save_all=True, append_images=image_list, duration=110, loop=0)
   
        logging.info(f"Finished creating .gif file for {const}")
   
        logging.info(f"Deleting frames for {const}...")
        for img in images:
            try:
                os.remove(os.path.join(images_folder, img))
            except FileNotFoundError:
                logging.error(f"File {img} not found.")
            except PermissionError:
                logging.error(f"Permission denied to delete file {img}.")
   

6. Computing Statistics: At this stage, I also compute statistics for the constellation. For the time being this is somewhat rudimentary but it works as follows: I have created a JSON file that contains the number of satellites in each constellation, the number of satellites in each altitude band (from 0-2000 in 100km bands), and the number of satellites in each inclination band (from 0-180 in 10 degree bands), and a timestamp to go with this data. Every time I pull data pertaining to a constellation this JSON file gets populated.

7. Selecting Statistics: Then I use the json module to read the last two entries for a given constellation. I calculate the differences between all the bands and select the largest difference. I then manually generate a tweet that says something like “Starlink has added 10 satellites in the 1000-1100km altitude band since yesterday”.

8. Generating Tweet Text: I pass the statistics and the string with the largest difference along with the name of the constellation to the openai module’s Completion class to generate the text. If there is no change in the statistics then I have a different prompt to generate a generic tweet about this constellation.

    import logging
    import openai
    from typing import List, str
   
    def generate_tweet(constellation_name: str, viz_type: str, openai_api_key: str) -> str:
        """
        Generates a tweet for the given constellation using OpenAI's GPT-3 API.
   
        Args:
            constellation_name (str): The name of the constellation.
            viz_type (str): The type of visualization.
            openai_api_key (str): The API key for OpenAI.
   
        Returns:
            str: The generated tweet.
   
        Raises:
            ValueError: If viz_type is not valid.
        """
        possible_viz_types = ["latest_state", "current_geometry", "ground_tracks"]
        if viz_type not in possible_viz_types:
            raise ValueError(f"Invalid viz_type {viz_type}. Must be one of {possible_viz_types}")
           
        prompt = create_gpt3_prompt(constellation_name, viz_type)
   
        openai.api_key = openai_api_key
        response = openai.Completion.create(
        engine="text-davinci-002",
        prompt=prompt,
        temperature=0.72,
        max_tokens=200,
        top_p=1,
        frequency_penalty=0,
        presence_penalty=0
        ) # the parameters here took some trial and error
   
        tweet_text = response.choices[0].text.strip()
        tweet_text = "Constellation-bot: " + tweet_text
        logging.info(f"gpt tweet: {tweet_text}")
   
        # If the generated tweet is too short or contains invalid characters, generate a default tweet
        if len(tweet_text) < 10 or not tweet_text.isascii():
            tweet_text = f"Check out the latest state of the {constellation_name} constellation! #spacex #megaconstellations #satellites"
        if len(tweet_text) > 280:
            tweet_text = f"Check out the latest state of the {constellation_name} constellation! #spacex #megaconstellations #satellites"
        return tweet_text
   

9. Posting Tweets: Finally, I use the tweepy module to post the text and the tweet. You will have to set up a Twitter developer account to generate the necessary API keys and tokens to post the tweets. In order to run this script automatically and not have my tokens exposed on Github I have also set up a Github Secret to store these keys and tokens in my repository environment variables. tweepy does not yet have a build in method to post GIFs so I had to repurpose the code used for posting PNG images. I will make this class available in my repo in the near future.

10. Automating the process : Finally I set up a Github Actions workflow cron job to run the script once a day with a different constellation and visualization type. If the script fails/succeeds I get a notification through the Github app on my phone.

name: Cron twice-daily tweet

on:
  schedule:
    - cron: '0 17 * * *'
  workflow_dispatch:

jobs:
  cron:
    runs-on: ubuntu-latest
    timeout-minutes: 60
    steps:
      - uses: actions/checkout@v3
      - name: Set up Python
        uses: actions/setup-python@v3
        with:
          python-version: '3.8'

      - name: Upgrade pip
        run: pip install --upgrade pip

      - name: Install system dependencies
        run: |
          sudo apt-get update
          sudo apt-get install -y libproj-dev proj-data proj-bin
          sudo apt-get install -y libgeos-dev

      - name: Install dependencies
        run: pip install -r requirements.txt

      - name: Run cron_tweet.py
        run: python source/twitterbot/cron_tweet.py
        env:
          PYTHONPATH: $
          TWIT_CONSUMER_KEY: $
          TWIT_CONSUMER_SECRET: $
          TWIT_ACCESS_TOKEN: $
          TWIT_ACCESS_TOKEN_SECRET: $
          OPENAI_API_KEY: $
          SLTRACK_PWD: $
          SLTRACK_USR: $ 

As ever if you have any questions or comments please feel free to message me. I hope you enjoyed this post and I hope you enjoy the bot!

Navigating the Challenges of Space Traffic Management

The growing importance of space traffic management is underscored by the limitations of the Two-Line Element (TLE) format and the need for increased transparency in the measurement and generation process of TLEs. Accurate positioning of uncooperative assets is vital for the safety and sustainability of the space environment. As highlighted by Oltrogge et al. (2018), Space Situational Awareness (SSA) data must not only meet but significantly surpass operators’ probability of collision thresholds. Positional error thresholds for Low Earth Orbit (LEO) objects, assuming a probability of collision threshold of 0.01%, typically range from 100-200 meters (Alfano, 2021; Oltrogge, 2018).

Assessing Validation Using Geodetic Spheres

Some SSA systems claim to produce ephemerides with covariances of a few hundred meters for both cooperative (Abraham, 2018) and uncooperative (Nicolls, 2017; Conkey, 2022) tracked assets. However, caution must be exercised when interpreting these claims. For instance, Nicolls (2017) found an orbit determination error of a few hundred meters when validating against International Laser Ranging Service truth ephemeris for the Stella Geodetic Reference Sphere. The use of geodetic reference spheres for validating orbit determination (OD) solutions is not without its drawbacks. These spheres, by their very nature, perform unusually well in simplistic force models like SGP4, which assume the spacecraft to be a sphere when calculating many non-conservative forces (e.g., solar radiation pressure and aerodynamic drag). Consequently, errors resulting from mismodeling geometry and attitude are “hidden.” Furthermore, geodetic spheres have small area-to-mass ratios, which reduce errors associated with calculating non-conservative forces.

It’s important to note that mismodeling spacecraft geometry and attitude are some of the largest sources of error in computing non-conservative forces (Vallado, 2014). As a result, the accuracy and precision achieved using geodetic spheres as calibration tools should be considered a lower-bound or best-case scenario in orbit validation. Spacecraft with different geometries, attitudes, and orbital geometries will likely perform worse. Nevertheless, geodetic spheres offer valuable insight into the potential for uncooperative tracking.

Understanding the Impact of Positional Error

Defining “good” accuracy depends on the requirements we set for ourselves. To better grasp the consequences of positional error, consider this example:

Suppose a spacecraft operator believes their spacecraft is at an altitude of 1200 km (typical of OneWeb constellation satellites). Ignoring all other orbital perturbations except for the monopole gravity term, they calculate the acceleration onto their spacecraft using the formula:

${g_h} = g_0(\frac{R_e}{R_e + h})^2$

Where ${h}$ is the altitude, ${g_h}$ is gravitational acceleration at altitude ${h}$, ${g_0}$ is the standard gravitational acceleration (9.80665 m/s$^2$), and ${R_e}$ is the mean radius of the Earth (6731 km).

Using this formula, the gravitational acceleration at 1200 km is calculated as:

${g_{1200{Km}}} = 9.80665(\frac{6371}{6371 + 1200})^2 = 6.9443147 m/s^2$

Now, imagine the spacecraft is actually one meter higher than the operator thought. This would give the spacecraft a gravitational acceleration of:

${g_{1200+1m}} = 9.80665(\frac{6371}{6371 + 1200.001})^2 = 6.9443129 m/s^2$

The difference in acceleration between both states is:

$\Delta a = 6.9443129 - 6.9443147 = 1.8\times10^{-6}$

Calculating the overall distance between both states over a 24-hour period (86400 seconds), we find:

$\frac{1}{2}at^2 = \frac{1}{2}\times 1.8\times10^{-6}\times86400^2 = 6718.464m$

This difference greatly exceeds the 100-200 meter positional error threshold we are shooting for in LEO. This example demonstrates how small errors in initial conditions can lead to disproportionate errors in position over time. Furthermore, this effect is accentuated in LEO due to the increasingly strong impact of monopole gravity with decreasing altitude. Gravity is roughly 1000 times greater than any other acceleration in LEO (Montenbruck, 2000), making not only the calculation of gravitational force of paramount importance, but also highlighting the importance that the inputs to the equations of motion be precise and accurate.

Tackling Positional Degradation in Space Situational Awareness Data

The decline of positional accuracy of orbits over time poses a significant challenge for SSA systems. In this section, we discuss three primary solutions for mitigating positional degradation in SSA data:

• Increasing Measurement Frequency: By increasing the frequency of spacecraft position measurements, the growth of positional error can be constrained. For instance, if the spacecraft’s position is re-measured with a 1-meter error every 24 hours, the observer will theoretically never be off by more than approximately 6700 meters. However, if the period is reduced to 12 hours, the error will never exceed roughly 1700 meters.

• Improving Initial Conditions Accuracy: Enhancing the accuracy and precision of a spacecraft’s initial position measurement can also reduce positional error. For example, in the previous section, if the initial error is reduced from 1 meter to 0.5 meters, the error after 24 hours will be around 3300 meters. Beyond hardware improvements, this can also be achieved through data fusion techniques that combine measurements from different sensors.

• Improving Orbit Propagation: Even with perfect initial conditions and frequent measurements, a propagated orbit will still degrade due to force model and numerical integrator errors. Utilizing a higher-fidelity orbit propagator, which models the spacecraft’s interaction with the physical environment more accurately, will result in fewer errors.

Real-time positioning in Low Earth Orbits (LEO) has reached centimeter-level accuracy (Li, 2019). However this level of accuracy necessitates a “cooperative” approach to space traffic management, where two-way communication occurs between the ground station and the satellite in question.

In contrast, the United States Space Surveillance Network (USSSN) aims to disseminate information about a wide range of Resident Space Objects (RSOs) to various operators (Wilson, 2019). Most RSOs, however, either lack Global Navigation Satellite Systems (GNSS) receivers or are unable or unwilling to share information with the USSSN. This “uncooperative” approach presents significant challenges, as there is no telemetry to aid the tracking process for most RSOs. Consequently, the USSSN must make cost-benefit trade-offs concerning measurement frequency, initial conditions accuracy, and force model complexity. For instance, high-fidelity atmospheric density models like the TIE-GCM (Qian, 2013) are readily available but are not widely used in orbit propagators due to their high computational cost (Licata, 2021).

In summary, mitigating positional degradation in SSA catalogs requires a combination of increasing measurement frequency, improving initial conditions accuracy, and using high-fidelity orbit propagators. However, the uncooperative nature of tracking RSOs poses significant challenges for SSA systems and necessitates cost-benefit trade-offs in terms of resource allocation and computational complexity.

As the number of satellites and space debris in orbit continues to grow, ensuring the safety and sustainability of the space environment becomes increasingly crucial. The limitations of the TLE format and the lack of transparency in the measurement and generation process of TLEs are critical factors to consider in space traffic management. The quest for precise positioning of uncooperative assets is a key component in addressing these challenges.

Moving forward, it is essential to invest in research and development that seeks to improve SSA systems and develop new tracking technologies. This may include advancements in sensor technology, data fusion techniques, and high-fidelity orbit propagators. Additionally, fostering international collaboration and data sharing among different countries and organizations can help address the challenges associated with uncooperative tracking and enable more accurate and reliable space traffic management.

In conclusion, the future of space traffic management hinges on our ability to enhance the accuracy and reliability of positional information for satellites and other space objects. By tackling the challenges associated with uncooperative tracking and positional degradation, we can help ensure the long-term sustainability of the space environment and enable safe and efficient space operations for all stakeholders involved.

References

• Oltrogge, D. et al. (2018). “The “we” approach to space traffic management.” 15th International Conference on Space Operations.

• Alfano et al. (2021). “SSA positional and dimensional accuracy requirements for Space Traffic Coordination and Management.” 2021 Advanced Maui Optical Space Surveillance Technologies Conference.

• Nicolls, M. (2017). “Conjunction Assessment for Commercial Satellite Constellations Using Commercial Radar Data Sources.” 2017 Advanced Maui Optical Space Surveillance Technologies Conference.

• Vallado, D. (2014). “A critical assessment of satellite drag and atmospheric density modeling.” Acta Astronautica, 95, 141–165.

• Montebruck, O. & Eberhard, G. (2000). “Satellite Orbits Models, Methods and Applications.” Springer-Verlag Berlin.

• Li et al. (2019). “LEO enhanced Global Navigation Satellite System (LeGNSS) for real-time precise positioning services.” Advances in Space Research, 63(1), 73-93.

• Qian, L. (2013). “The NCAR TIE-GCM: A community model of the coupled thermosphere/ionosphere system.” Geophysical Monograph Series, 201, 73-83.

• Wilson, T. (2019). “18th Space Control Squadron - Small Satellite Support Presentation.” Sept.2019.

• Licata, M. (2021). “Impact of Space Weather Driver Forecast Uncertainty on Drag and Orbit Prediction.” Advances in the Astronautical Sciences, 175, 1941-1959.

Keeping track of objects in space is no easy task. The first real concerted effort to systematically track earth orbiting satellites started back in 1957, with the launch of Sputnik 1. The US government quickly realized they needed a way to keep track of all the objects in space and thus, Project Space Track was born. In the early days, tracking was done through a combination of radar, telescopes, radio, and even citizen observations. These observations were then manually reduced, and corrections were determined in order to generate orbital elements that could be used for predictions.

The goal was to develop a method that would provide a fast-updating situational report of objects in space using the computing power that was available at the time for “large-scale space applications and simulations” (Hujsak, 1979). In pursuit of a concise data format for efficient data processing, Two-Line Elements (TLEs) were created to describe the orbits of objects in space. This ultimately led to the creation of SpaceTrack Report 2 (Lane and Hoots, 1979) and the adoption of the TLE format by the North American Aerospace Defense Command (NORAD). The model used to generate this data, Simplified General Perturbations 4 (SGP4), is an analytical model that eventually became the go-to model for commercial and scientific spacecraft operators.

What are TLEs? How are they made today?

But what exactly are TLEs? A single TLE is a two-line, 69-character description of a satellite’s identity, orbital geometry (using Keplerian elements), the orbit epoch for which this information was generated, and a term related to the ballistic coefficient (B-star). The TLE format is described in more detail in Vallado (2006). However, it’s important to note that the B-star term is widely understood to be somewhat problematic as the simplified force modelling and the way in which the data is processed means that this term ends up serving as a catch-all term for model errors (Vallado, 2006).

Today, TLEs are generated from a variety of data sources, such as radars, optical sensors, and in-orbit sensors. All these sources fall under the United States Space Surveillance Network (USSSN), as seen in the image below.

Since March 1998, T.S. Kelso has been pioneering the dissemination of TLEs through his website Celestrak.org. TLEs are now generated by the 18th Space Control Squadron (18th SpCS) and shared through their website (space-track.org). Spacetrack serves as the de-facto source of data for a multitude of SSA products the community relies on. These include but are not limited to conjunction (collision) data messages, decay and re-entry predictions.

More recently, Celestrak has also started sharing Operator TLEs for certain spacecraft. Operator TLEs (also referred to as Supplemental TLEs or SupTLEs) are TLEs that are “derived directly from owner/operator-supplied orbital data” instead of 18th SPCS measurements. This type of TLE is valuable as the operator-supplied orbital data used to generate them is typically derived from on-board GNSS receivers (Murley, 1982a), or operator ephemerides (Johnson, 2022), both of which are usually orders of magnitude more accurate than TLE data. When fit to high-accuracy ephemerides (e.g.GPS SEM Almanac orbits), these TLEs can be orders of magnitude more accurate than a run-of-the-mill NORAD TLE (Supplemental TLE Link). In practice, this means going from multi-kilometre error (~5-10 Km) to sub-kilometre error (~0.85 Km)

The graph below illustrates the performance of NORAD TLEs against supplemental TLEs on GPS spacecraft (work by T.S.Kelso. See https://celestrak.org for more information).

Limitations of TLEs

Whilst TLEs are the current bedrock of many SSA products, one should be aware of their (many) limitations. For example, TLEs are generated by fitting tracking data to the SGP4 force model (using batch-least squares), which while widely used, remains relatively inaccurate compared to state-of-the-art propagators. This saves on computational cost but also on accuracy.

TLEs are provided without any information pertaining to their accuracy (covariance matrices). This is done purposefully by the 18th Space Control Squadron to limit the ability of external parties to infer information about the sensors the USSSN disposes of. Furthermore, utilizing TLEs fitted to SGP4 with other force models will result in degraded performance. This means that, unfortunately any TLE is “stuck” with the SGP4 force model. Additionally, the accuracy of TLEs is known to degrade rapidly over time. They must be updated frequently with new tracking data to keep providing a representative picture of reality.

Despite these limitations, TLEs remain a valuable tool to provide a quick and efficient way to track and predict the orbits of objects in space and are widely used by spacecraft operators and other organizations involved in space activities. The recent addition of Operator TLEs, which are derived from more accurate operator-supplied data, adds an extra level of precision to TLE predictions.

TLEs have played a crucial role in the development of space monitoring and traffic management since the launch of Sputnik 1. The TLE format, while not without its limitations, provides a concise and efficient way to track and predict the orbits of objects in space. As space traffic continues to increase, it’s essential that the valid use cases of TLE continue to be monitored and that the space traffic management community continues to build tools that meet their ever-evolving needs. The recent addition of a public facing repository of Operator TLEs is an example of a tool that helps to improve the safety of space operations.