Todo List

Member CC_FSM::reset (void): the implementation of this method is not robust against any of the states having been loaded with an illegal nextState. It is not clear whether this kind of robustness should be built into the method since an illegal nextState would typically be the result of a configuration error and the framework classes are not requierd to be robust against configuration errors (but there should at least be an assertion-level protection).

Class CC_RootObject: change the name of isObjectConfigured to isConfigured
fix the policy for inline methods. Currently, all header files that define inline methods include the corresponding "_inl" file. This should make it unnecessary for the "_inl" file to be included by the body files. This must be checked on the ERC32 simulator. If confirmed, all inclusions of "_inl" files in body files should be removed.

Class CC_TelecommandManager: extend the test case for the telecommand manager to check the generation of an event in case the telecommand execution is not successful
the name of method setPendingTelecommandListSize is not consistent with the name of the equivalent method in class ManoeuvreManager (which is simply called setPendingListSize. The two names should perhaps be harmonized.

Class ConditionalPunctualAction: Add a getExecutionCheckCode to return a code describing the reason for the failure of the execution check.

Class DataPool: This class defines the setter and getter methods to be virtual. This is expensive in CPU time. Given that data pool implementations will often be generated automatically by XSL programs, and given that an application would normally only have one data pool component, it may be wiser to have the XSL program generate an implementation for class DataPool that is defined to have only non-virtual methods. The problem with this approach is that it is not possible to have multiple implementations of a data pool in a single delivery and that therefore it is not possible to have several data pool test cases in the same delivery (this could be alleviated by generating the test case for the data pool as well as the data pool implementation).

Class DC_AfsFsmState: Modify the generator meta-component generateRecoveryAction to generate the code that sets the class identifier and to treat the default attributes in the custom recovery action description.

Class DC_BasicPUSTcLoader: The implementation of method "activate" must be updated every time a new PUS telecommand class is added to the framework

Class DC_DataItem: Make the constructor parameterless for consistency with the rest of the framework and add a setter method for the variable encapsulated by the data item In order to keep this class distinct from DC_SettableDataItem, the setter method should raise an assertion exception if it is called more than once.

Class DC_DataPoolMonitor: change the specification and the implementation of the class to set the status of a data pool item whose monitoring check reports "no deviation from profile" to "valid". At present, the validity status can only go from "valid" to "not valid".

Class DC_FdirCheck: change the name of this class to: DC_FdirAction (remember to update the comments to reflect the change of class name)

Class DC_OCM_FsmState: Modify the generator meta-component generateRecoveryAction to generate the code that sets the class identifier and to treat the default attributes in the custom recovery action description.

Class DC_PUSClearDataReporting: This class can only take one telemetry mode manager as configuration parameters. If we assume that the same applications can have several telemetry managers (maybe to manage telemetry packets with different levels of RT priority), then it would be necessary to modify this class to accept several telemetry mode managers.

Member DC_PUSDataReportingPacket::setDefinitionBufferSize (unsigned int size): Clarify the reason for the 0xFF limit on the buffer size. This seems to be obsolete.

Class DC_PUSEventRepository: Verify whether the declaration and implementation of method create(CC_RootObject*,TD_EventId) is really needed (try omitting it on the gnu compiler). Its presence seems unnecessary and it is undesirable because it adds a level of indirection
Modify the processing of the events denoting "success" to include a check on the acknowledge flag of the telecommand that is being verified: a verification packet should only be sent in case of success if this is explicitly requested by the telecommand through its acknowledge flags (see pag. 44 of PUS standard). to most calls of the event creation service.

Class DC_PUSMemoryDumpAbsolute: construct a test case for this class.

Class DC_PUSMemoryDumpOffset: construct a test case for this class.

Class DC_PUSTcVerificationPacket: construct a test case for this class.

Class DC_SampleControlBlock_1: Modify the generator meta-component generateRecoveryAction to generate the code that sets the class identifier and to treat the default attributes in the custom recovery action description.

Class DC_SampleControlBlock_2: Modify the generator meta-component generateRecoveryAction to generate the code that sets the class identifier and to treat the default attributes in the custom recovery action description.

Class DC_SampleControlBlock_3: Modify the generator meta-component generateRecoveryAction to generate the code that sets the class identifier and to treat the default attributes in the custom recovery action description.

Class DC_SampleControlBlock_4: Modify the generator meta-component generateRecoveryAction to generate the code that sets the class identifier and to treat the default attributes in the custom recovery action description.

Class DC_SampleMonitoringProfile: Modify the generator meta-component generateMonitoringProfile to generate the code that sets the class identifier and to treat the default attributes in the custom monitoring profile description.

Class DC_SampleRecoveryAction: Modify the generator meta-component generateRecoveryAction to generate the code that sets the class identifier and to treat the default attributes in the custom recovery action description.

Class DC_SBY_PostSepFsmState: Modify the generator meta-component generateRecoveryAction to generate the code that sets the class identifier and to treat the default attributes in the custom recovery action description.

Class DC_SBY_PreSepFsmState: Modify the generator meta-component generateRecoveryAction to generate the code that sets the class identifier and to treat the default attributes in the custom recovery action description.

Class DC_SCM_FsmState: Modify the generator meta-component generateRecoveryAction to generate the code that sets the class identifier and to treat the default attributes in the custom recovery action description.

Class DC_SettableDataItem: create a test case for this class

Class DC_SM_PreSepFsmState: Modify the generator meta-component generateRecoveryAction to generate the code that sets the class identifier and to treat the default attributes in the custom recovery action description.

Class MonitoringProfile

Add an internal variable that to record the reason for the violation and that concrete monitoring profiles can set to indicate how the profile was violated (e.g. violation of upper boundary of a range interval). Clients can then inspect the value of this variable to know the exact reason of the profile violation.

Add a test case to cover the "next monitoring profile" functionality. This could be obtained by modifying the test case of DC_ProfileList.

Monitoring profiles use parameters that are implemented as internal variables. In practice, these parameters will often have to come from the parameter database. Two solutions are possible: generators are used to parameterize the concrete monitoring profiles classes with respect to the mode of implementation of the profile parameters. Or aspect programs are used modify the monitoring profile class as follows: code to set the link to the parameter database is inserted, and code to update the value of the internal parameter with the value read from the parameter database is added at the beginning of method doProfileCheck.

Class ObsClock: create a PUSObsClock class derived from this class to implement PUS-specific timing services
spilt the setTime method into two setter methods

Class ParameterDatabase: This class defines the setter and getter methods to be virtual. This is expensive in CPU time. Given that database implementations will often be generated automatically by XSL programs, and given that an application would normally only have one database component, it may be wiser to have the XSL program generate an implementation for class ParameterDatabase that is defined to have only non-virtual methods. The problem with this approach is that it is not possible to have multiple implementations of a database in a single delivery and that therefore it is not possible to have several database test cases in the same delivery (this could be alleviated by generating the test case for the database as well as the database implementation).

Class PunctualActionModeManager: Create a class DC_FSMPunctualActionModeManager where the mode is driven by an FSM. Same thing should be done for the TelemetryModeManager

Class PUSFunctionManagement: Can a generic way be found to handle the execution of some action as a function of the "function ID field" in the telecommand packet?

Class Telecommand: The possibility should be considered of making Telecommand a subclass of ConditionalPunctualAction. This would make sense because the Telecommand class contains a conditional execution check. However, this change would require delicate changes to the CC_TelecommandManager and CriticalTelecommand classes (at the least). For the time being, it seems wiser to leave things as they are. The advantage of the current solution is that it gives greater control to the telecommand manager over the execution of the telecommand and it makes it easier to implement "special" types of telecommands (such as, for instance, critical telecommands).
should new versions of method setRawData that take as argument unsigned short and unsigned int be added? This would speed up execution when a large number of data have to be loaded but it might make implementation of the methods in concrete subclasses more complex.

Class TestCase: reformulate comments to test cases in terms of "checks" rather than "verification".

Class TestCaseWithFactories: Use this class as base class for test cases that use items that could be provided by a dynamic factory