Coverage

Here is a short list of some of the functionality available for use with coverage:

• Analysis of Assets (get) covering a single time dynamic object.

• Analysis of Assets (get) covering a grid on a central body.

• Analysis of Assets (get) covering an arbitrarily shaped grid defined in a reference frame.

• Gridding algorithms to define the boundary and density of the grid.

• The ability to configure grid points with custom services for use with access calculations.

• Represent Assets (get) using Access Queries, allowing complex relationships between assets and their targets.

• Highly parallel coverage calculations over a grid can be done in multiple threads.

• Various figures of merit allow for meaningful analysis of large amounts of data.

Of course, since coverage is essentially a complex access problem, you can use all the functionality of access constraints and Access Queries. So, the above list is really only the means for facilitating a broad spectrum of uses. The coverage components are intended to be versatile enough to be applied to any application involving a large number of repetitive access calculations.

Below is an example of the result of a coverage calculation over the continental United States with a 0.5 degree resolution on the grid. The colors indicate the number of assets providing coverage at the time of the snapshot. Black indicates 0 assets, Deep Blue is 1, Navy Blue is 2, and Light Blue is 3 assets. The red dots represent the positions of the assets at the time of the snapshot.

There are two standard coverage definitions, ParameterizedSpatiallyPartitionedCoverageDefinition and MaterializedSpatiallyPartitionedCoverageDefinition. Both standard coverage definitions are derived from ContinuousCoverageDefinition which treats time as a continuous variable. Each of these contain a way to specify a gridding algorithm, specify a set of complex access calculations for each asset, define arbitrary functionality present at each grid point, and then produce results over space and time. There are two ways to specify the properties at a given grid point, a delegate or an IServiceProvider . The method used for specifying the definition of grid points dictates which of the two coverage definitions you use. The recommended definition for most use cases is ParameterizedSpatiallyPartitionedCoverageDefinition. In this coverage definition a template object is used to specify the grid point's properties. Only use MaterializedSpatiallyPartitionedCoverageDefinition in special cases where unique properties for each grid point, that last the duration of the calculation, are desired.

To further clarify the operation of these coverage definitions; when a template is used to define the properties at a given grid point, the template platform or object, is applied to each grid point as the analysis is computed. When a delegate is used to set each point's properties, the defined GridPointCreationCallback (get / set) is called for each point generated by the gridding algorithm to create an access problem for that point. In both cases the properties of the grid point may include, position, orientation, sensor field of view, and any other extensions or functionality. In these coverage definition types multi-threaded computation over the grid is accomplished by sending appropriately sized groups of grid points to available calculation threads to be analyzed over the interval of time requested.

Coverage definitions derived from DiscreteCoverageDefinition offer an alternative to the previously described ContinuousCoverageDefinition based classes. As described in the preceding section, the coverage definitions derived from ContinuousCoverageDefinition divide up their analysis work into groups of grid points, analyzed over the entire requested time interval. This works reasonably well in cases where there are complex calculations at each grid point that are largely independent of any of the other grid points. Terrain analysis is a good example, since terrain obscuration is unique at each grid point. However, there are other use-cases where there are a significant number of redundant calculations shared among the grid points, such as performing analysis with a large number of propagated satellites requiring transformations between inertial and fixed frames, or performing communication network analysis with uplink and downlink relay chains. In these latter cases, it can be beneficial to cache calculations at each evaluation time, rather than having to repropagate all the satellites for each grid point.

Coverage definitions based on the discrete (in time) approach evaluate the entire grid in lock-step while caching redundant calculations. These definitions then use multiple threads to loop over a set of time intervals. This allows you to gain runtime performance, at the expense of the ability to detect and represent small access intervals. By using a larger time step, the overall calculation will take less time, but the coverage calculation may miss intervals that are shorter than the time step (intervals where there is either a short satisfaction or loss of satisfaction). In many coverage use cases, there is a significant amount of error in precision inherent in the modeling itself. So, short intervals of access may be extraneous and not represent accesses for the real system. In other cases, real world systems (such as cameras or human operators) can't respond fast enough inside very short access intervals. In both cases, it may be preferable to miss these short intervals and accept the imprecision in order to improve performance. However, in other instances where small visibility windows are important, such as a LEO spacecraft passing quickly overhead, it might be necessary to ensure that the time step is small enough to resolve the short access times. So, depending on the use-case and error tolerance, this discrete coverage offers different tradeoffs which give you a wider range of options for tuning coverage performance.

In addition to coverage over grids, there is also coverage to a single time-dynamic object. Some examples where this functionality is useful include: an aircraft which is being tracked by a navigation constellation or a lunar exploration craft which needs to be tracked by multiple communication and relay spacecraft as well as satisfying certain constraints involving the 'asset' of the Moon. CoverageDefinitionOnSingleObject works with an IServiceProvider to define the target directly, just like a simple access calculation.