Protocols

Protocols implement the idea of Rules of the Road, by defining which operator is initially proposed to take responsibility in a conjunction event.

Protocols therefore allow for automating the initial case assignment suggestion, skipping the need for a case-by-case negotiation. (Note that this initial assignment suggestion can still always be negotiated, in case the circumstances require it.)

In the following, we show which different kinds of protocols are available, which ones you can use out-of-the box, and how you can define your own protocols.

Protocol hierarchy

Protocols come in three different flavors.

Baseline protocols are predefined based on recommendations by authorities and the community, such as the Space Safety Coalition. They are designed such that they are in principle applicable to all conjunctions, and are available for all registered operators to subscribe to. The available baseline protocols are described below.
Bilateral protocols are created by direct agreement between two operators. They only apply to conjunctions between those operators and can thus include very spacecraft- and orbit-specific rules.
Global protocols are an extension of bilateral protocols: They are created by one operator and are available for all other operators to adhere to in conjunctions with the creator organization. They make sense, for instance, for operators with larger constellations, who want to agree on a coordination strategy with the operators they have frequent conjunctions with.

Protocols are evaluated from most specific to most general. That is, for any conjunction, OKAPI:Astrolabe first checks whether the operators agreed on bilateral protocols. If so, they are used. If not, OKAPI:Astrolabe checks whether is a global protocol in place that applies. If so, this is used. If not, OKAPI:Astrolabe checks whether both operators are subscribed to baseline protocols, and if so, uses them.

If no protocols apply, or the applicable protocols either yield no or conflicting decisions, then both operators get a case assignment action and have to negotiate who takes responsibility.

Available baseline protocols

Based on the best practices put forward by the Space Safety Coalition, the first baseline protocols defined and available in OKAPI:Astrolabe are the following ones.

Assignment based on maneuvering capabilities: The spacecraft with the higher maneuvering capabilities maneuvers, according to the following hierarchy.
- Crewed: A crewed spacecraft is assumed to be able to alter their orbit to avoid collision. It always takes precedence.
- Automated collision avoidance maneuvering capability: The decision to conduct an avoidance maneuver is made without human confirmation or intervention.
- Manually maneuverable: Able to easily change orbit at relatively short notice.
- Minimal maneuvering capabilities: Only able to change the orbit to a very small degree, for example using low duty cycle low-thrust maneuvers or differential drag perturbations.
Assignment based on mission phase: If both spacecrafts have the same maneuverability, and one is in nominal mission phase while the other is not, then the spacecraft that is not in nominal mission phase maneuvers.

They are recommended to be used together. You can subscribe to any of them (independent of other operators) in the Baseline tab of the Protocols page.

Note: These protocols use satellite properties, so they will only be able to reach a decision if you provide the relevant information for your satellites. You can do this via dedicated API endpoints.

Subscribing only some satellites to a protocol

Coming soon.

Defining and negotiating own protocols

The Protocols page has a Bilateral tab, where you can define your own protocols.

The tab provides an overview of all bilateral protocols either created by you or created by other operators who invited you to use them.

As soon as you have one of your own protocols activated, you can invite another operator, with whom you want to use the protocol as bilateral agreement. They can then accept or reject. Analogously, if another operator invited you to use one of their protocols in shared conjunctions, you can accept or reject to do so.

When you click on “Create new protocol”, a protocol editor will guide you through setting up conditions and assignment rules following the definitions below.

Protocol definition language

Protocols consist of two main components: conditions and assignment rules.

Conditions determine whether a protocol applies in a given situation. They specify properties of the conjunction, the involved spacecrafts, and possibly the operators and their coordination history. Examples are:

TCA is more than 36 hours in the future.
Both spacecrafts are in their nominal mission phase.
One spacecraft has a lower dry mass than the other.
None of the spacecrafts is crewed or has automated collision avoidance.

Assignment rules specify which spacecraft is supposed to maneuver if the protocol applies. Examples are:

The spacecraft operated by Planet Express maneuvers.
The spacecraft with the greatest thrust value maneuvers.
The spacecraft with the lowest dry mass maneuvers.

Protocol definitions use standard YAML syntax with a specific structure and specific fields and properties. The general structure is a list of conditions together with a list of assignment rules:

when:  
  - <condition>  
  - ...  
then:  
  - <assignment rule>  
  - ...

The when list of conditions determines whether the protocol applies in a given situation, where all conditions are implicitly connected conjunctively, i.e. the protocol applies if and only if all conditions are satisfied. If the protocol applies, the then list of assignment rules determines which satellite is assigned to maneuver in case it becomes necessary. The assignment rule list is ordered such that the first rule that yields a decision decides, all subsequent ones are skipped.

Conditions

Two kinds of protocol conditions are defined: conjunction conditions and spacecraft conditions.

Conjunction conditions have the following form:

type: conjunction_has  
property: <conjunction property>  
operator: <operator>  
value: <value> 
unit: <string> 
epsilon: <number>

They specify a predicate on a property of the conjunction, taken from the available CDMs and subsequent updates.

The unit and epsilon attributes are optional. The unit specifies the unit of the provided value (e.g. m and km for miss distance), and epsilon determines the difference margin within which numeric values count as equal (for example, 0.4 equals 0.5 if epsilon is 0.1, but not if epsilon is 0.01).

Here is an example using one of the conjunction-related properties and available operators, expressing that a protocol applies if miss distance of the most recent CDM is less than 370 m (plus/minus 0.1 m):

type: conjunction_has  
property: miss_distance  
operator: less_than
value: 370
unit: m
epsilon: 0.1

For properties based on timestamps, the value can either be

an ISO timestamp, such as 2024-05-01T16:10:07.000Z,
an expression of the form now + <temporal shift>, like now + 1 day or now + 20 hours 10 minutes,
an expression of the form now - <temporal shift>, such as now - 2 days 1 hour 45 minutes.

For example, in order for a protocol to apply if TCA is still more than 36 hours in the future, you can define a condition like this:

type: conjunction_has  
property: tca
operator: greater_than
value: now + 36 hours

Spacecraft conditions have a very similar form, with the only addition that they include a quantification in their type:

type: one_spacecraft_has | all_spacecraft_have | no_spacecraft_has  
property: <spacecraft property>  
operator: <operator>  
value: <value> 
unit: <string> 
epsilon: <number>

Spacecraft-related properties include identification properties (e.g., NORAD and COSPAR ID), physical properties (like mass, hard-body radius and cross section), mission-related properties and orbital parameters.

In addition, you can define a disjunction of conditions:

type: or 
conditions:  
  - <condition> 
  - ...

Note: If you have agreements in mind that cannot be expressed with the conditions and properties described here, please feel free to get in touch. We are curious to learn what rules are most useful in actual operations, and are open to extending the protocol language.

Assignment rules

Assignment rules decide which spacecraft is supposed to maneuver in case it’s necessary. Therefore they differ from conditions mainly in that they do not evaluate to a Boolean value but instead to one (or several or none) of the spacecrafts involved in the conjunction.

The following kinds of assignment rules are defined.

Negotiate: Both operators are asked to accept responsibility, equivalent to the case where no protocol is applicable.

type: negotiate

Alternate: The operators want to alternate maneuvering. So each time the protocol is applicable among the same two operators, the operator who did not maneuver last time is assigned. The first time the protocol is applied, one of the operator is chosen randomly.

type: alternate

Field-based assignment: The assignment is decided based on the value of one of the spacecraft-related properties. This can take different forms. The first one simply assigns the spacecraft which satisfies a certain condition:

type: assign_spacecraft_with  
property: <spacecraft property>  
operator: <operator>  
value: <value> 
unit: <string>  
epsilon: <number>

If there is no unique decision, i.e. none or all of the spacecrafts satisfy the condition, evaluation proceeds to the next assignment rule in the list.

The second kind of rule assigns the spacecraft with the highest or lowest value for a given property:

type: assign_spacecraft_with_min | assign_spacecraft_with_max  
property: <spacecraft property> 
epsilon: <number>  
epsilon_unit: <string>

Finally, there is a possibility to concisely assign a spacecraft based on where its value of a property is within a hierarchy, compared to the other spacecraft’s value:

type: assign_spacecraft_highest_in_hierarchy 
property: <spacecraft property> 
order: 
    - <value> 
    - ...  
unknown_at: top | bottom

The unknown_at attribute specifies where in the hierarchy an unknown value would be placed (i.e. a value not contained in the order list).

Operators

Available operators are the following:

equals, not_equals for equality and inequality between values of the same type
less_than, less_than_or_equals, greater_than, greater_than_or_equals for comparison of numeric values and timestamps
in, not_in for list inclusion and exclusion
matches, not_matches for matching strings against a regular expression

Conjunction properties

Currently, the following conjunction-related properties can be used.

tca (timestamp) corresponding to the time of closest approach
collision_probability (number) at TCA, as given in the most recent CDM
miss_distance (number, default unit: m) at TCA, as given in the most recent CDM
radial_miss_distance (number, default unit: m) at TCA, as given in the most recent CDM

Spacecraft properties

Currently, all satellite properties can be used in protocols. If the values are not known for the spacecrafts involved in a conjunction, it usually leads to the protocol not being applied or not reaching a decision.

In addition, you can use the following dynamically determined property:

age specifies the time passed since launch in days. It is computed dynamically from the launch_date, where only the date is taken into account and not the specific launch time.

Examples

In this section we provide a few examples.

In case you want a protocol to apply to all conjunctions, you can leave the condition set empty. For example, the following protocol specifies that the operators always want to alternate maneuvering.

when:
then:
  - type: alternate

Or they want always the satellite with the smaller total mass to maneuver:

when:
then:
  - type: assign_spacecraft_with_min
    property: mass

In bilateral agreements, you can also formulate very satellite-specific rules, for example agreeing that in conjunctions between two defined satellites always one of them maneuvers:

when:
  - type: one_spacecraft_has
    property: norad_id
    operator: equals
    value: 90001
  - type: one_spacecraft_has
    property: norad_id
    operator: equals
    value: 10009
then:
  - type: assign_spacecraft_with
    property: norad_id
    operator: equals
    value: 90001

You could also make the assignment dependent on the type of orbit or specific conjunction properties. For example, let’s assume the case of two operators using different risk thresholds (for example, because one operates a large constellation, while the other has only one satellite), who want to agree that for collision probabilities between 1e-6 to 1e-5, the more risk-averse operator maneuvers, and for smaller probabilities, the other one maneuvers. This would require two rule protocols:

when:
  - type: conjunction_has  
    property: collision_probability
    operator: greater_than
    value: 1e-6
  - type: conjunction_has  
    property: collision_probability
    operator: less_than_or_equals
    value: 1e-5
then:
  - type: assign_spacecraft_with  
    property: operator
    operator: equals
    value: Mega Constellation

And:

when:
  - type: conjunction_has  
    property: collision_probability
    operator: less_than
    value: 1e-4
then:
  - type: assign_spacecraft_with  
    property: operator
    operator: equals
    value: Single Sat

Defining a list of assignment rules provides a way to specify what happens if some rule doesn’t yield a decision. For example, let’s define that the smaller satellite maneuvers, and if they have the same size category, then the operators negotiate. In order to make it fair, we want the protocol to only apply if the size of both satellites is known.

when:
  - type: no_satellite_has
    property: size
    operator: equals
    value: unknown
then:
  - type: assign_spacecraft_highest_in_hierarchy 
    property: size 
    order:
      - small
      - medium
      - large
  - type: negotiate

Notifications Supported data formats