Invalid license: Your evaluation license of Refined expired.
bannerd

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: activity formatting

...

Show If
spacePermissionedit
Panel
titleVisible to editors only
Expand

Content updates needed on this page: 

  1. Update tabs
as necessary
  • Update References as necessary
  • Update Lessons Learned
    1. as necessary
  • Update space code in macros and links as needed - 2 upd - 11/23
  • Set Data
    hiddentrue
    namereftab
    4
    Tabsetup
    01. Principle and Rational
    12. Examples
    23. Inputs
    34. Resources
    45. Lessons Learned
    Div
    idtabs-1

    1. Principle

    Floatbox

    Include Page
    Principles List
    Principles List

    Excerpt

    Design software to send a positive acknowledgement of command receipt.

    1.1 Rationale

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









    Div
    idtabs-2

    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

    Swerefn
    refnum668
    , Consultative Committee for Space Data Systems (CCSDS)
    Swerefn
    refnum667
    . 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  and 9.11 Invalid Data Handling Design Principles.

    2.1 Additional Guidance

    Links to Additional Guidance materials for this subject have been compiled in the Relevant Links table. Click here to see the

    Tablink2
    tab4
    linktextAdditional Guidance
     in the Resources tab.

    Div
    idtabs-3

    3. Inputs

    Show If
    groupconfluence-users
    Panel
    titleColorred
    titleVisible to editors only

    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.

    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.


    Div
    idtabs-4

    4. Resources

    4.1 References

    refstable-topic


    Show If
    groupconfluence-users
    Panel
    Visible to editors only
    titleColorred
    titleInstructions for Editors
    Expand

    Enter

    the

    necessary modifications to be made in the table below:

    SWEREFs to be addedSWEREFS to be deleted


    SWEREFs called out in

    the

    text: 439, 667, 668

    SWEREFs NOT called out in text but listed as germane: NONE

    Refstable staging

    Related Links Pages

    Children Display

    Refstable Topic


    Include Page
    REF RPT p04
    REF RPT p04

    4.2 Additional Guidance

    Additional guidance related to this requirement may be found in the following materials in this Handbook:

    Related Links

    Include Page
    9.04 - Related SWEs
    9.04 - Related SWEs

    Include Page
    9.04 - Related SM
    9.04 - Related SM

    4.3 Center Process Asset Libraries

    Excerpt Include
    SITE:SPAN
    SITE:SPAN
    nopaneltrue

    See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

    SPAN Links

    Include Page
    SITE:SPAN Design
    SITE:SPAN Design

    4.4 Associated Activities

    This topic is associated with the following Life Cycle Activities: 

    Div
    idtabs-5

    5. Lessons Learned

    No lessons learned

    Swerefn
    refnum439
    have currently been identified for this principle.