1. Principle

1.1 Rationale

Implementation of this rule gives assurance that the physical and virtual links between the sender and receiver are working properly.

2. Examples and Discussion

The basis of this principle is the need to have some positive confirmation that a command was received by the target. Historically, this rule has been captured in a software requirement and is sometimes paired with a related requirement to acknowledge that the resulting action has been initiated. An example where this principle is useful is when a command is sent to open a valve but that valve does not open. The problem could be in the command link, or the valve failure itself, or the valve driver, or somewhere else in the system. Positive acknowledgement of command receipt by the target computer facilitates troubleshooting of the problem. Implementations that provide a reason code with a negative acknowledgement further support troubleshooting and autonomous fault protection at little additional cost. Implementation of this principle would also help identify a dropped command in a sequence of commands that might otherwise go undetected. Note that the acknowledgement discussed in this principle is in addition to command acknowledgement implemented by the transmission protocol (e.g., MIL-STD 1553B , Consultative Committee for Space Data Systems (CCSDS) . The additional acknowledgement will help detect command errors at the application software level.

In some cases, like the transfer of data from a non-critical component, the designer may make the determination that a command acknowledgement is not necessary (unless there is an approved requirement to do so). But these decisions need to be carefully considered with respect to required troubleshooting capabilities.

The Ames Research Center (ARC) document excerpted in the Inputs section below does not specifically address commands generated internal to the flight software. The notes in the Marshall Space flight Center (MSFC) document (excerpted below) do indicate that the design principle applies to commands generated internally in the flight software. However, the wording in the MSFC document allows the designer some latitude, since it seems excessive to place an item in telemetry for every internally generated command that is placed on every bus for every cycle. The designer may interpret the command acknowledgement to be an acknowledgement to the sender, even if the sender is an on-board computer. 

The reference documents do address responding to invalid commands (e.g., nack response) and the discussion is included in the 9.07 Fault Detection and Response and 9.11 Invalid Data Handling Design Principles.

3. Inputs

3.1 ARC

• 3.6.2.2 Command Logging
  
  The flight software generated data products available for downlink shall include a log of all received, executed and rejected commands that indicates:
        time of receipt
        time of execution
• 3.6.2.3 Critical Command Locking
  
  Critical commands that may adversely affect system operation or safety shall be controlled so that they cannot be inadvertently executed without operator acknowledgement.

• 3.7.2.4.1 Command Validation and Acknowledgement
  
        a) Flight software shall be designed to verify uplinked commands, data, or loads.
        b) Flight software shall ignore, and log incorrectly formatted commands, data, or loads and provide notification that they were incorrectly formatted.
        c) Flight software shall be designed to send acknowledgement of command receipt to the source with indication of acceptance or rejection of command. For rejected commands, the acknowledgement message shall include a reason for rejection in the transmitted message.
  
  Note: For example, flight computer designs have included Error Detection And Correction (EDAC) logic on EEPROMs, and the load process has been designed to detect and respond to failure if the EDAC detects an uncorrectable bit error. Software designs have included check sum logic and periodic verification of memory to detect command, data, or load, and memory faults.
  
  Note: For example, a command handler should check whether a received command is appropriate for the current system mode, and a software module should check whether a command is appropriate for its local state.
  
  Note: For example, flight computer designs have included Error Detection And Correction (EDAC) logic on EEPROMs, and the load process has been designed to detect and respond to failure if the EDAC detects an uncorrectable bit error. Software designs have included check sum logic and periodic verification of memory to detect command, data, or load, and memory faults. For example, a command handler should check whether a received command is appropriate for the current system mode, and a software module should check whether a command is appropriate for its local state.

3.2 GSFC

None

3.3 JPL

None

3.4 MSFC

• 4.12.1.8 Software shall be designed to send acknowledgement of command receipt.
  
  Note: Critical command information needs to be captured in both the downlink in real-time and on any kind of onboard recording device, including internally generated commands.
  
  Rationale: To verify successful command transmission and to evaluate command disposition.

4. Resources

4.1 References

Enter the necessary modifications to be made in the table below: SWEREFs to be added SWEREFS to be deleted SWEREFs called out in the text: 439, 667, 668 SWEREFs NOT called out in text but listed as germane: NONE

5. Lessons Learned

No lessons learned have currently been identified for this principle.