Coverage Analysis to be performed on the LEO Earth Observation Constellation
Introduction
In part one of this satellite design series, we explored the modelling of a physics accurate RF Comms link between ground facility and LEO satellite. However, rarely do modern LEO satellites work in isolation. Instead, they work as part of a larger constellation, continuously exchanging data to fulfil their intended mission.
Part two of this series explores the design of a larger LEO constellation and how Ansys STK allows for the qualitative and quantitative analysis of user-specified regions of interest to discern how effective a given constellation will be.
Designing LEO Constellation
STK Provides a number of methods to design new satellite constellations or import existing real-world constellations. In this instance we have used a “Satellite Collection” object as it facilitates rapid modifications to both the satellite configuration and EO payloads once setup. Below are the settings for one such constellation, featuring six evenly spaced planes, with two satellites per plane.
Constellation definition for LEO satellites.
Additionally, a reference object is defined for the satellite constellation. This allows the quick application of a universal EO payload across all satellites. At this stage it should come as no surprise that should the user add, remove or otherwise modify this constellation, the EO payload will automatically apply across these changes. Vice versa, changing the EO payload aboard the reference satellite will propagate this update across all constellation satellites.
In this instance, the EO Payload is modelled as a simple rectangular FOV Sensor. However, be sure to check out our full DME Blog to see applications of dedicated EOIR sensors for bushfire observation, hypersonics detection and more!
Visualisation of initial constellation.
Defining Coverage Grid
In part one of this series, we looked at RF Comms Access between one satellite and ground facility. In the following section we will expand on this, evaluating the effective coverage of the constellation we just created above. The aim here is to assess the effectiveness of various constellations in covering a user-defined region of interest.
STK provides several avenues to define these coverage definitions. These generally take the form of coverage definition grids. In its most basic form these may be a global or region based uniform grid, as seen below.
Basic Global coverage definition grid.
Basic coverage definition grid constrained to Australia, note finer resolution of the grid compared to previous example.
However, we can create more sophisticated coverage grids for specific mission requirements. Suppose our constellation was tasked with observing all protected land areas in Australia. We can constrain the coverage grid to these specific point locations to create a bespoke coverage definition for such a requirement. Similarly, we could attain a map protected marine areas and define a coverage grid constrained to these specific areas. Both examples have been created within STK using point and shapefile information available from the Australian Government Department of Climate Change, Energy the Environment and Water.
Coverage Grid constrained to Protected Land Areas across Australia.
Coverage Grid constrained to Protected Marine Areas.
Ultimately, these coverage grids can be used to evaluate the performance of constellation sensors by assigning them as “assets” to these coverage definitions. As standard in STK, these coverage definitions and their associated analysis remains dynamic, so any change to the underlying grid does not require the user to start the analysis setup from scratch. Instead, results are recomputed automatically, allowing for rapid exploration of various design points and requirements.
Evaluating Effective Coverage
Analysis for constellations and their effective coverage will often start with an Accumulated Coverage report. Pictured below, this shows that over the simulation analysis period, the constellation is in fact able to cover 100% of the coverage grid within approx. four hours. Suppose our initial constellation had only shown 50% accumulated coverage over 24 hours. This may be an early indicator that the constellation required reworking in order to achieve higher total coverage values. Possible solution might include raising the orbits, widening the sensor Field of View (FOV) or increasing the number of LEO satellite planes. Keeping in mind, we cannot invalidate other design requirements in the process.
Current (red) and Accumulated (Blue) coverage provided by LEO constellation and provided sensor field of view.
To further investigate a constellation, the user can assess coverage definitions via several “figures of merit.” These encompass common data metrics including “age of data,” and “number of assets,” as well as any custom metric the user may wish to explore. Moreover, each metric can be visualised as either instantaneous or time-averaged values. Below is a snapshot of a handful of the metrics and their visualisation
Instantaneous coverage of LEO Satellite as it passes over Western Australia. Green points currently have access whilst red do not.
Instantaneous Age of Data Contour – useful for visualising areas that fail mission requirements around age of data. In this example, any red areas have not had a satellite sweep within the last 60 minutes, failing a hypothetical design requirement. Areas in green have had a sweep within the last 15 minutes.
Average Age of Data – this provides an interesting point of comparison to the previous contour. Here the averaged time data shows the bulk of Australia does pass the hypothetical 60 min time requirement, when averaged across the entire analysis period. Whether instantaneous or time-averaged results are more imperative will depend on specific mission requirements, such as whether the constellation needs to be capable of capturing a short real-world event that could occur at any time.
Ultimately, we can utilise these coverage definition to refine our satellite constellation and ensure it is capable of completing the required mission, even if certain satellites become unavailable or any other contingency plans need to be put into action.
What Next?
Albeit beyond the scope of this short blog, the constellation and coverage definition assembled here could now be used to drive a parametric design sweep or optimisation study within STK. Utilising STK’s Analyzer feature, the user can evaluate various sensor FOV values, satellite orbits, etc against specified performance metrics, all whilst optimising for a user-defined cost function. For more information on this, feel free to reach out to us at Leap Australia for more information.
In the meantime, join us in part three of this Satellite Design Series as we explore a vital factor of our satellite’s longevity – Conjunction Analysis in a crowded low Earth orbit.
Conjunction Analysis to be performed in Part 3 of this series.
References
Shape File and Point File location used for Protected Land and Marine areas coverage definitions attained from the Australian Department of Climate Change, Energy and Environment and Water: https://fed.dcceew.gov.au/datasets/. License: https://creativecommons.org/licenses/by/4.0/