AccessComputation Class

Though AccessComputation has its use cases we recommend using constraints directly as AccessQueries rather than attaching them to AccessComputations. AccessQueries have much more flexibility in the sorts of networks that they can represent. Most notably AccessComputations are limited to calculating Access for a single pair of Platforms.

When talking about whether one object can "access" another object, we are typically talking about inter-visibility. When can my satellite see my facility? Determining when a satellite can see a facility might involve checking any number of requirements, depending on the specific problem being solved. For starters, you would likely want to require that the surface of the Earth not lie between the satellite and the facility. This might involve the use of an idealized, spheroidal model of the Earth. Or it might involve checking for actual terrain obstructing the line of sight. Next, you may want to model a specific sensor on the satellite in order to further restrict what it is able to see. All of these things are AccessConstraints.

An AccessComputation without any constraints will report that Access is always available. Each constraint that is added to the computation further restricts Access availability. Conceptually, the overall intervals when Access is available are the intersection of the intervals when each constraint is satisfied. In actuality, AccessComputation attempts to work faster by not evaluating intervals for a constraint if those intervals have already been eliminated by a previous constraint. AccessComputation will also evaluate the least computationally expensive constraints first in the hope that significant chunks of time will be eliminated from consideration before the more expensive constraints must be evaluated.

The Transmitter and Receiver are the two objects involved in the Access computation. The names "Transmitter" and "Receiver" serve only to distinguish the two objects. AccessComputation itself does not treat the two objects any differently. Specific AccessConstraints, however, may impart additional meaning to one or both of these roles. When this is the case, the documentation for the AccessConstraint should make it clear.

The only requirement of the two objects is that they implement IServiceProvider. Constraints will require additional capabilities from the object and they will obtain the additional capabilities through the IServiceProvider interface. The documentation for each constraint will describe the service interfaces that are required by the constraint. Consider using Platform to represent your objects involved in Access computations.

Internally, AccessComputation uses TimeIntervalFinder and JulianDateFunctionExplorer to evaluate the constraints.

Note that AccessComputation will create links based on the light time delay settings, but will not add any extensions to the links themselves. So, if a constraint (e.g. CommunicationLinkConstraint) requires additional information on the link, AccessComputation will not work. For these cases, use the constraints as AccessQuery objects and specify the links explicitly. For more information, see the documentation overview on using AccessQuery.

Reference