Standardization of Command Responses

[dmknutsen]

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I reviewed the README file to see if the feature is in the major future work.
• I performed a cursory search to see if the feature request is relevant, not redundant, nor in conflict with other tickets.

Is your feature request related to a problem? Please describe.
cFS should have standardized command responses for commands that set a state/mode like enable/disable, on/off, true/false, start/stop/pause/resume, etc.

For those commands, the app should respond as describe below:

If the current setting is not in that commanded state,
    If the commanded state can be set successfully,
    a. Increment the command counter
    b. Send an INFO event that says command successfully executed
    otherwise,
    a. Increment the command error counter
    b. Send an ERROR event that says failed to execute the command

If the current setting is already in that commanded state,
    Increment the command counter, not command error counter
    Send an INFO event that says already in that state

The following command response does not align with the standard:

Successful events are debug type:

CS_ONESHOT_STARTED_DBG_EID
CS_RECOMPUTE_CFECORE_STARTED_DBG_EID
CS_RECOMPUTE_OS_STARTED_DBG_EID
CS_RECOMPUTE_EEPROM_STARTED_DBG_EID

Debug events are issued when a command addresses an empty table state 

CS_ENABLE_EEPROM_DEF_EMPTY_DBG_EID
CS_ENABLE_MEMORY_DEF_EMPTY_DBG_EID
CS_DISABLE_MEMORY_DEF_EMPTY_DBG_EID
CS_ENABLE_TABLE_DEF_NOT_FOUND_DBG_EID
CS_DISABLE_TABLE_DEF_NOT_FOUND_DBG_EID
CS_ENABLE_APP_DEF_NOT_FOUND_DBG_EID
CS_DISABLE_APP_DEF_NOT_FOUND_DBG_EID

Describe the solution you'd like
Update logic to align with the standard.

Requester Info
Dan Knutsen
NASA Goddard

[thnkslprpt]

The second list (CS_ENABLE_EEPROM_DEF_EMPTY_DBG_EID etc.) seems fine as-is no?

There is a success (INFO) event issued (and command counter increment), e.g. CS_ENABLE_EEPROM_ENTRY_INF_EID, and then a DEBUG event is issued to inform the user of pertinent information, but that does not rise to the level of an error.

Or is the problem more that the commands, as currently implemented, cannot be considered either completely successful or otherwise a failure (ERROR)? (i.e. the commands can be partially successful, where they update the results table, but only then realise that the definitions table entry is empty).

[dmknutsen]

Good observation/point. I reached back to the project that originally requested standardizing the command responses to get further clarification on this.

In this case - we increment the command counter and issue an event because the commands are valid. However, the spirit of the command fails when the memory definition table entry is empty (the tables are not updated). User's should be made aware of the failure - such that we should issue error message(s) as opposed to a debug message(s) for those events (ie the second list should be error as opposed to debug messages).

[thnkslprpt]

@dmknutsen cool no worries.

Re. 1st list - some issue a DEBUG event when the command is received and initial validity checks pass, and the command counter is incremented at this stage. However, there is a separate INFO event issued later when the processing of the command completes successfully.

Note, cFE has a similar pattern in a few cases (e.g. CFE_ES_STOP_DBG_EID, CFE_ES_RESTART_APP_DBG_EID & CFE_ES_RELOAD_APP_DBG_EID).

Options are to:

1. leave as-is (issue DEBUG event, increment command counter, finish processing, issue INFO event)
2. move command counter increment to only occur after successful processing
3. change both to INFO events (but then a successful command would issue 2 INFO events)

Option 2 seems like the worst as it could be quite hard or impossible to increment the command/command-error counters correctly further down the call-chain. Also increases complexity/coupling and lowers cohesion.

[dmknutsen]

Option 3 is best. The information conveyed in the messages is useful to the end user. If projects have bandwidth limitations and/or wish to reduce the message flow, they can certainly switch back to DEBUG message types on a case by case basis to best fit their project. The more important thing from in my view is that the default behavior is consistent. Same would apply to cFE.