mmecina / CCS

The UVIE Space Central Checkout System (CCS) and Test Specification Tool (TST)
Mozilla Public License 2.0
1 stars 0 forks source link

Handling of CCF_NPARS Field by CCS #1

Closed pasetti closed 5 months ago

pasetti commented 5 months ago

It seems that, as part of the processing of telecommands, the CCS uses the CCF_NPARS field. This field is optional in the SCOS2000 Reference but, if it is defined, it should hold the number of parameters in a telecommand. As far as we can judge, the value of this field is used in module ccs_function_lib.py where an incorrect setting triggers the exception at the end of the following code excerpt:

def encode_pus(params, *values, params_as_fmt_string=False):
    """

    :param params:
    :param values:
    :param params_as_fmt_string:
    :return:
    """
    if params_as_fmt_string or isinstance(params, str):
        return struct.pack(params, *values)

    if not isinstance(values, list):
        values = list(values)

    ed_pars = [param for param in params if param[5] not in ['A', 'F']]
    if len(ed_pars) != len(values):
        raise ValueError('Wrong number of parameters: Expected {}, but got {}.\n{}'.format(len(ed_pars), len(values), ', '.join(x[10] for x in ed_pars)))

We would like to have the following clarifications:

(1) Is our interpretation of how CCF_NVARS is used correct? (2) For telecommands which have a variable number of parameters, how should CCF_NVARS be set?

For question (2), comparison with what was done on Cheops suggests that the CCS expects CCF_NPARS to be equal to the number of parameters in the TC definition. Thus, for instance, for TC(3,5), the expected value of NPARS would be 2 (because the TC data are defined by two parameters: NUM and REP_id).

mmecina commented 5 months ago

(1) Is our interpretation of how CCF_NVARS is used correct?

In the context of building a TC, CCS uses the CCF_NPARS field only to distinguish between commands that carry parameters and commands that do not (e.g., a TC17,1 "Connection test" typically has no parameters, CCF_NPARS=0). It is not used to verify the correct number of parameters for each respective TC.

The ValueError is raised if the number of parameter values handed over to the encode_pus function, e.g. from the Tcsend_DB or Tcbuild commands, does not match the number of editable parameters defined for the respective PUS TC, i.e. parameters that have CDF_ELTYPE = E. This means that values for both spare and fixed-value parameters (CDF_ELTYPE is 'A' or 'F') are queried from the MIB and must not be supplied by the user as function arguments. A typical example of fixed-value parameters are discriminants to sub-divide a PUS subservice further into several commands.

For question (2), comparison with what was done on Cheops suggests that the CCS expects CCF_NPARS to be equal to the number of parameters in the TC definition. Thus, for instance, for TC(3,5), the expected value of NPARS would be 2 (because the TC data are defined by two parameters: NUM and REP_id).

Correct, this is also how we handle it, as there doesn't seem to be a strict definition in the SCOS-2000 ICD. Note that the CCF_NPARS value counts 'A' and 'F' type parameters as well.

pasetti commented 5 months ago

Many thanks for the explanation. Everything is clear now.