The acceptance check for an incoming command is implemented in the InLoader. Inside the InLoader. the acceptance check is split into four sub-checks:
The type/sub-type/discriminant of the incoming command or report is valid (i.e. it is defined in CrFwInFactoryUserPar.h and is therefore known to the application);
The InFactory has sufficient resources to provide an InCommand or InReport component to hold the command or report encapsulated in the packet;
The InCommand or InReport is successfully configured (i.e. it enters state CONFIGURED);
The InCommand or InReport is successfully loaded in the InManager.
Sub-checks 1, 2 and 4 are fully implemented at CORDET framework level. In the CORDET Framework, sub-check 3 is application-specific. It is called the Validity Check because it verifies the validity of the parameters of the incoming report or command and is implemented by a user-provided function which must conform to the prototype of function pointers CrFwInRepValidityCheck_t for incoming reports or CrFwInCmdValidityCheck_t for incoming commands. The functions implementing the validity checks are defined in CrFwInFactoryUserPar.h. In the PUS Extension of the CORDET Framework, the Validity Check is implemented to verify the checksum and length of the command (the PUS extension closes adaptation point P-ICM-3).
In the CORDET Framework, function InLoaderLoadCmdRep in the InLoader is responsible for checking whether the sub-checks are passed. For incoming commands, failure to pass a sub-check is handled as follows:
Failure of sub-checks 1 and 2 is handled by calling function CrFwRepInCmdOutcomeCreFail with outcome crCmdAckCreFail.
Failure of sub-check 3 is handled by calling function CrFwRepInCmdOutcome with outcome crCmdAckAccFail.
Failure of sub-check 4 is handled by calling function CrFwRepInCmdOutcome with outcome crCmdAckLdFail.
In the PUS Extension, I need to define verification failure codes covering these three cases and I need to close the corresponding adaptation points. I propose to use the following failure codes: VER_CRE_FAIL, VER_ACC_FAIL and VER_LD_FAIL.
The rejection code VER_CRE_FAIL is defined and is associated to the crCmdAckCreFail outcome.
If there is a failure of the validity check which results in the crCmdAckAccFail error condition, then the failure code is set equal to the command outcome. It is therefore up to the command implementing the validity check to define a rejection code and to load it in the outcome field
The rejection code VER_CMD_LD_FD has been created for the crCmdAckLdFail case
The acceptance check for an incoming command is implemented in the InLoader. Inside the InLoader. the acceptance check is split into four sub-checks:
Sub-checks 1, 2 and 4 are fully implemented at CORDET framework level. In the CORDET Framework, sub-check 3 is application-specific. It is called the Validity Check because it verifies the validity of the parameters of the incoming report or command and is implemented by a user-provided function which must conform to the prototype of function pointers CrFwInRepValidityCheck_t for incoming reports or CrFwInCmdValidityCheck_t for incoming commands. The functions implementing the validity checks are defined in CrFwInFactoryUserPar.h. In the PUS Extension of the CORDET Framework, the Validity Check is implemented to verify the checksum and length of the command (the PUS extension closes adaptation point P-ICM-3).
In the CORDET Framework, function InLoaderLoadCmdRep in the InLoader is responsible for checking whether the sub-checks are passed. For incoming commands, failure to pass a sub-check is handled as follows:
In the PUS Extension, I need to define verification failure codes covering these three cases and I need to close the corresponding adaptation points. I propose to use the following failure codes: VER_CRE_FAIL, VER_ACC_FAIL and VER_LD_FAIL.