Configuring Access Constraints

Access constraints do not appear in the Access tool itself. Rather, STK obtains the constraints from each object and combines them in an access pair (i.e. the set of enabled constraints owned by object A and the set of enabled constraints owned by object B). Every object that participates in access computations contributes a set of active constraints that STK considers when computing access for that object and every access computed using that object.

Active constraints are ones that you, or STK's object default settings, have enabled for an object in the scenario. The active constraints are usually just a small subset of all the possible constraints that are available for you to enable.

Every object supports a unique set of available constraints that are appropriate for it.

• The available constraints for child objects not only include constraints pertinent for the child object (Sensor, Transmitter, Radar, etc.) but also include all available constraints for their parent (and grandparent) as well.
  • Child objects do not inherit active constraints from a parent or grandparent. You must directly select a constraint for a child object for it to be active for that child object. See the example scenario.
• Most objects support many geometrical constraints, defined from the spatial relationship between the pair of objects. However, certain objects behave specially:
  • Stars are treated having a direction in space, not a location in space.
  • Area Targets only support constraints that STK can evaluate over the entire area within its boundaries.
  • Line Targets only support constraints that STK can evaluate over its entire length.
• Field of view (FOV) is only available for Sensors and children of Sensors.
• Communications constraints are only available for Transmitters and Receivers.
  • They are not available for ground locations (Facilities, Places, and Targets) or vehicles.
• Some Radar constraints are only available for Radar objects.
  • However, you can set certain Radar constraints on ground locations and vehicles when those objects are involved in an access with a Radar object, modeling their reflectance attributes.

Special cases

• Stars
  • Stars have a direction but not a location. Constraints that require a location (e.g., Range and Altitude) are not applicable when computing access to a Star.
• Area Targets and Line Targets
  • You can configure these objects to require that, at each time step, either (i) or (ii) applies:
    • (i) The whole object must satisfy all the constraints, applying to every point within an Area Target or every point on a Line Target.
    • (ii) Any part of the object must satisfy all the constraints.
  • When STK only requires a part of the object for access computations, then the following conditions apply:
    • STK can use different parts at different times.
    • For any given time, there must be at least one point that satisfies all the constraints for an access to occur. It is not sufficient for one point to satisfy some constraints while some other point satisfies the other constraints.
  • Given this convention, few constraints apply to these objects, other than LOS, FOV, and elevation angle.
  • If it is more important to understand the access behavior of the individual points belonging to these objects, then you should use STK's Coverage capability rather than the Access tool.
• Linked antennas
  • You can link Receiver and Transmitter objects to an Antenna. When you do this, the available constraints for the Receiver and Transmitter do not include any constraints from their parent/grandparent.
  • When you compute Access using the Receiver/Transmitter, STK includes any active constraints for the linked Antenna as an applicable constraint, as evaluated by the Antenna. The resulting access times for the Antenna further restrict the access involving the Receiver/Transmitter.