This section defines the functional requirements for real-time command support and stored command support.
201 The flight software shall accept real-time commands from the RF transponder via the uplink card and route them to their proper subsystems.
202 The flight software shall comply with the CCSDS command standard as specified in the WIRE Telemetry and Command Handbook.
206 The flight software shall accept real-time commands and command data from the RF transponder (via the uplink card) over virtual channel #0.
206.1 The flight software shall be capable of handling a command uplink rate of 2 kbps.
206.2 The flight software shall accept commands which are formatted to comply with CCSDS Telecommand Standards.
206.3 The flight software shall support variable length CCSDS command packets. The maximum command length shall be 256 bytes and all commands shall be an even number of bytes.
206.4 The flight software shall "unlock" the CCSDS Frame Acceptance and Reporting Mechanism (FARM) based on ground command.
206.5 The flight software shall reset the CCSDS frame sequence number to zero based on ground command.
206.6 The flight software shall execute a NOOP command that does nothing except increment the command sequence counter.
211 The flight software shall perform CCSDS command structure validation.
211.1 The flight software shall implement CCSDS Command Operations Procedure number 1 (COP-1) to validate that CCSDS transfer frames were received correctly and in order.
211.2 The flight software shall support a fixed size FARM sliding window of 127 and a fixed FARM negative edge of 63.
211.3 The flight software shall telemeter status and discard the real-time command packet if any of the following errors occur:
211.4 The flight software shall generate and maintain a Command Link Control Word (CLCW). Each time an update is made to the CLCW, a CLCW packet is formatted and routed for possible downlink.
212 All software tasks which receive command packets shall validate each command and maintain housekeeping data counts of both valid and invalid commands received.
212.1 The flight software tasks shall reset the housekeeping command counts by ground command.
216 The flight software shall route individual command packets to their destination based on packet application ID.
251 The flight software shall provide autonomous operation of the spacecraft through the processing of on-board stored commands.
Absolute Time-Tagged Commands
252 The flight software shall accept Absolute Time-tagged command loads from the ground.
252.1 The flight software shall maintain two buffers for absolute time commands -- one actively being processed by the flight software and one available for loads from the ground.
252.2 Absolute time commands shall be loaded from the ground as a table load with a particular absolute time command buffer designation. (see Table Load requirements)
252.3 An absolute time-tagged command load shall be able to be appended to a previously loaded absolute time command buffer.
252.4 The flight software shall be capable of executing absolute time-tagged command loads sorted in any time order.
252.5 The flight software shall be capable of managing up to 400 absolute time-tagged commands per command buffer. The total length of the stored command buffer shall not exceed 35000 bytes.
252.6 The flight software shall accept absolute time-tagged commands formatted as a command number, absolute time-tag, any legal spacecraft command in CCSDS command packet format, and a checksum.
252.7 Absolute Time-tagged commands shall have a one second time resolution.
253 The flight software shall autonomously process individual commands from the absolute time command buffer.
253.1 Absolute time-tagged commands shall be issued to their destination when the absolute time tag of a command stored in onboard memory matches the current spacecraft clock time.
253.2 Absolute time-tagged commands shall be issued no more than 100 ms after the time tag (assuming that no two commands have the same time tag).
253.3 For commands that have the same time tags, the flight software shall issue commands with the lowest command number first.
253.4 The flight software shall telemeter status and discard the absolute time-tagged command if any of the following errors occur:
253.5 An absolute time-tagged command shall be able to activate a Relative Time Command Sequence.
253.6 Absolute time command processing shall support the following command requests:
253.7 The flight software shall maintain the status of each absolute time command in a table which can be dumped to the ground. Status shall include for each stored command number:
253.8 The flight software shall maintain a pointer to the next command to be issued from the absolute time command buffer.
Relative Time-Tagged Sequences
256 The flight software shall accept Relative Time-Tagged Command Sequence loads from the ground.
256.1 Relative time command sequences shall be loaded from the ground as table loads. (see Table Load requirements)
256.2 The flight software shall support up to 64 relative time-tagged sequences.
256.3 Relative time command sequences shall provide for a variable number of commands.
256.4 Relative time command entries shall consist of a relative time tag, any legal spacecraft command in CCSDS command packet format and a checksum.
256.5 Each relative time command sequence shall be an even number of bytes not to exceed 300 bytes in length.
Note: If a sequence requires more than 300 bytes, the last command in each full buffer must activate a sequence in another command buffer.
256.6 Relative Time Command time tags shall specify delay from the previous relative time command and shall have a one second resolution.
257 The flight software shall autonomously process individual commands from the relative time-tagged command buffers.
257.1 The flight software shall permit the relative time command sequences to execute concurrently.
257.2 The flight software shall initiate a relative time command sequence based on:
257.3 The flight software shall support the following relative time command sequence control requests from a ground command, an ATS, or from within a RTS:
257.4 A sequence must be in an enabled state prior to being started.
257.5 If an active RTS is disabled, the sequence shall be processed completely. However, the sequence shall not be restarted without first being re-enabled.
257.6 An enabled relative time command sequence shall be able to be started more than once without re-enabling the sequence between executions.
257.7 An individual relative time-tagged command within a relative time command sequence shall be issued within 100 msec plus the delta time-tag from the previous command in the sequence. ( Assuming no higher priority stored command is pending)
257.8 A relative time tag of zero shall cause the command to be issued as soon as possible after, and in the same second, as the previous command.
257.9 The flight software shall generate an event and discard the relative time-tagged command if one of the following errors occurs:
257.10 The flight software shall routinely provide the status of each relative time-tagged command sequence in telemetry. Status shall include:
257.11 The default state of each stored command sequence for safing shall be the enable state with transition to the disable state only by specific ground commands.
257.12 If a request to start an RTS is received while that RTS is already running, the flight software shall reject the new request and allow the RTS to continue running.
ATS/RTS Command Priorities and Limits
261 The priority of stored command processing shall be as follows:
262 The number of commands issued by all ATSs and RTSs shall be limited to 10 per second.