Design software to send a positive acknowledgement of command receipt.
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.
Excerpts from two documents are included below but no information on the documents that the excerpts were taken from is available. These two documents should be properly referenced.
188.8.131.52 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
184.108.40.206 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.
220.127.116.11.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.
18.104.22.168 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.
REF RPT p04
REF RPT p04
Visible to editors only
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.