Routing File Format

Use a routing file to specify the rules for links in a chain associated with objects in a constellation or entries in a satellite collection subset. It is an ASCII text file with a *.routing extension that STK reads every time it computes a chain with the constellation or subset.

The file can have one or more of the following types of file sections :

• Outgoing rules - These rules govern which objects in the constellation or entries in the subset can be the source of the outgoing signal to another chain object, which can be inside or outside the constellation or subset.
• Incoming rules - These rules govern which objects in the constellation or entries in the subset can be the destination of an incoming signal from another chain object, which can be inside or outside the constellation or subset.
• Multihop rules - These rules govern the links between two or more objects within the constellation or between two or more entries within a subset. MultihopRules do not apply to objects outside of the constellation or subset.

See the Specific rules format section of this topic for more information on creating rules for each of these cases.

Routing file general format

The general format for a section is as follows:

Begin { OutgoingRules | MultihopRules | IncomingRules }
 DefaultRule { Always | Never | Access }

 Begin Rules
  List of rules for link pairs
 End Rules
End { OutgoingRules | MultihopRules | IncomingRules }

First, STK applies the “DefaultRule” to all possible links between from/to objects related to the constellation or subset. Then the Begin Rules/End Rules part specifies the exceptions to that default rule.

For constellations, the link rules for pairs (Begin Rules/End Rules part) requires that you identify the specific object in the constellation for each rule.

For satellite collections, the link rules for pairs (Begin Rules/End Rules part) requires that for each rule you identify both the specific subset of the satellite collection and the specific entity within that subset. This is because the routing file applies to the entire satellite collection, not to a specific subset within the collection. For an example of satellite collection formatting, see the satellite collection multihop example section of this topic.

There is an example of a complete routing file — all three types of rules together — later in this topic.

Specific rules format

The general form of the Begin Rules/End Rules part enables you to identify link pairs to specifically call out how STK should determine their visibility. The format is as follows:

    RuleType truncatedPath1 truncatedPath2

You can specify as many rules for links as are necessary. If there are two or more conflicting rules, the latest rule in the list of rules overrides earlier rules.

You can use wildcards in the truncated path names. Suppose you have a chain with a constellation of satellites followed by a constellation of places. The constellation of satellites is then considered the "outgoing" source. You could then create the following specific outgoing rules for the constellation of satellites:

Begin Rules
    Always Satellite/Satellite1 Satellite/Satellite2
    Access Satellite/Satellite1 Place/Place*
End Rules

The first rule says that Satellite1 can always see Satellite2. The second rule says that Satellite1 can see all Places during times of access.

The Incoming/Outgoing and Multihop sections do have slightly different options when specifying the link. In the Incoming/Outgoing sections, you can choose to specify only one path. In this case, STK assumes the other side of the link is a wildcard, so any other object will satisfy the link.

For example:

Begin OutgoingRules
	DefaultRule Never
    
	Begin Rules
	  Access Satellite/Satellite1
	End Rules
End OutgoingRules
				

In this case, when the constellation of satellites is in the "from" (outgoing) position, Satellite1 is the only satellite that can "see" other objects and uses access to compute visibility times to whatever objects are in the "to" (incoming) position.

The multihop section must specify both sides of the link: the from (outgoing) and to (incoming) sides. For a multihop section, you can use the word “reciprocal” to mean that the link rule is applied in both directions when multihopping.

For example:

Begin MultihopRules
 DefaultRule Never
    
 Begin Rules
   Always Satellite/Satellite1 Satellite/Satellite2
   Always Satellite/Satellite2 Satellite/Satellite3 Reciprocal
 End Rules
End MultihopRules
				

For the case above, when multihopping within the constellation of satellites, Satellite1 can always communicate to Satellite2, but Satellite2 cannot communicate to Satellite1. In contrast, Satellite2 can communicate to Satellite3 and Satellite3 can communicate to Satellite2; the direction doesn’t matter.

If an entire section (outgoing, incoming, multihop) is not defined in the routing file, then the chain assumes that all objects in a constellation and all entities in a satellite collection subset are available when computing visibility between links in the chain based on the constellation and subset positions in the link.

Full routing file example

Here is an example of a complete routing file for a constellation of satellites:

Begin OutgoingRules
 DefaultRule Never
    
 Begin Rules
  Access Satellite/Satellite1
 End Rules
End OutgoingRules

Begin MultihopRules
 DefaultRule Never
    
 Begin Rules
   Always Satellite/Satellite1 Satellite/Satellite2
   Always Satellite/Satellite2 Satellite/Satellite3
 End Rules
End MultihopRules

Begin IncomingRules
	DefaultRule Never
    
	Begin Rules
		Access Satellite/Satellite3
	End Rules
End IncomingRules
				

Satellite collection multihop example

Here is an example of a routing file with just a multihop section for a satellite collection. It contains one default rule and one specific exception rule.

Begin MultihopRules
 DefaultRule Never
    
 Begin Rules
   Access "CollectionSubsetEntry SatelliteCollection/SatelliteCollection1/Subset/AllSatellites Shell_1_P*_S*" "CollectionSubsetEntry SatelliteCollection/SatelliteCollection1/Subset/AllSatellites Shell_2_P*_S*" reciprocal
 End Rules
End MultihopRules
			

If subset "AllSatellites" from SatelliteCollection1 is part of a chain, this rule says that no entries will be able to talk to other entries in the subset (DefaultRule = Never) except for the Shell_1 entries using access to talk to the Shell_2 entries and vice versa (reciprocal).