COP-1 and the Link Component

COP-1 (CCSDS 232.1) sequences the telecommand frames of a link and retransmits the lost ones. In Stellar Control it runs in the transport of the link, such as ccsds-tc: the driver only encodes packets. Its state is exposed to operators and procedures as the measures of a standard component, link, and its directives as telecommands of that component.

The link component#

The compiler adds the link component to the catalogue of every target, with one instance per declared link (enum link_id): link[nominal], link[direct]. It is generated, so a catalogue cannot define a component link nor the enums link_id and fop_state (topology::reserved-name).

The transport publishes these measures whenever they change; the compute stage, the current value table, procedures and alarms handle them like the measures of the platform.

Using it in procedures and operations#

The measures of a link are addressed through the role of the target:

step "Uplink ready"
  uses sat: platform-v3
  check sat.link[nominal].lockout is false
  check sat.link[nominal].fop_state is active

The name of the link is checked when the run is resolved against its target: links belong to targets, not to platforms. For the same reason, the requires of a catalogue cannot read the link component.

Directives go through the executor like any telecommand:

stellar send flatsat-1 'link[nominal].unlock'
stellar watch flatsat-1 'link[nominal].fop_state' 'link[nominal].vs'

step "Unlock the link"
  uses sat: platform-v3
  send unlock to sat.link[nominal]

set_vr is hazardous: in a step, it follows an ask operator "…", confirmed by the roles of the environment. The driver of the link gives ACK 1 and hands a directive to the transport of the link it names, without encoding it; a link without transport refuses it (ENCODE_FAILED).

How the transport runs COP-1#

The ccsds-tc transport reads its COP-1 settings from the parameters of the link: spacecraft scid, virtual channel vcid, window K window (10), timer T1 t1 (5 s) and transmission_limit (3). The SDK runs one FOP-1 per link and builds the TC transfer frames (CCSDS 232.0).

• Numbering. The unit of a telecommand becomes the data field of an AD frame. The FOP numbers it as soon as the window allows. A telecommand still waiting for the window at its deadline fails (SEND_FAILED), never numbered.
• ACK 2. The first transmission of a frame carries its telecommand: the gateway publishes SENT. Retransmissions go without event.
• CLCW. The transport extracts the CLCW from the Operational Control Field of each TM frame and hands it to the FOPs of the target. A FOP starts in its initial state and initialises itself on the first clean CLCW received (V(S) = N(R)).
• Stop. A lockout, or no acknowledgement after the transmission limit, stops the FOP: the frames in flight are forgotten, the waiting telecommands fail, and new telecommands are refused (SEND_FAILED, the reason telling to unlock the link) until unlock or set_vr.
• Other units. A unit of no telecommand, such as a CFDP PDU, goes in a BD frame, outside the sequence.

Downlink, ccsds-tc extracts the space packets from TM frames of tm_length octets, reassembling packets across frames with the first header pointer.

Persistence#

The state of each FOP (V(S), frames in flight and waiting, counters, last CLCW) is written to the KV bucket stellar_cop1, key <target>.<link>, after every change and before any frame leaves: two frames never get the same number. After a restart of the transport:

• the sequence goes on from the stored state;
• a telecommand delivered again is recognised and not sent twice;
• the first retransmission of each restored frame carries its telecommand again, in case it never left.

The reconciler creates the bucket and grants each transport the keys of its targets, and the right to publish the measures of the link component.

Metrics#