cFE TIME unit tests break when different configuration options are used

[skliper]

When using the unmodified sample version of the {{{cfe_platform_cfg.h}}} file, the test cases defined in {{{time_UT.c}}} all pass.

But if the user makes any time-related modifications to the platform config file, many of the unit test cases break. In particular, configuring a time server vs. time client or setting SRC_MET == TRUE, etc.

The test cases in "time_UT.c" need to include/accommodate other valid configuration options.

[skliper]

Imported from trac issue 78. Created by jphickey on 2015-07-09T16:30:14, last modified: 2019-07-03T12:48:08

[skliper]

Trac comment by jphickey on 2017-10-20 11:58:34:

This ticket points to a deeper issue and first requires a clean up of the TIME subsystem in general. Many of the configuration options trigger calls into functions that do not exist and are not defined in the respective API at all. Functions like:

OS_SelectTone()
OS_GetLocalMET()

Since these options have been broken in previous versions and this isn't a //new// issue in 6.6, I recommend deferring this to cfe-next.

[skliper]

Trac comment by jphickey on 2017-10-20 11:59:48:

NOTE: for example ticket #123 is one that should be a dependency of this one.

[skliper]

Trac comment by jhageman on 2019-04-01 09:41:02:

CCB 3/27/2019 - discussed removing unimplemented configuration options. Assigning to Alan for review.

Edit - fixed CCB date typo

[skliper]

Trac comment by acudmore on 2019-04-03 11:29:42:

As part of tickets 47, 78, and 92, I would like to do a survey of missions for TIME subsystem options.

Depending on the results of the survey, we should:

1. Implement stub PSP functions to implement any necessary functions (PSP equivalents of OS_Get/SetLocalMET , OS_SelectTone) and update unit tests etc.
2. Deprecate the un-needed options/features and prepare to remove them in a more comprehensive time subsystem simplification.

[skliper]

Trac comment by jphickey on 2019-04-03 11:40:01:

For what its worth, the "TimeBase" feature that was added and implemented in the "ng" OSAL versions may make these functions and special features in CFE_TIME unnecessary.

For the most part, CFE TIME just needs a properly synchronized 1Hz PPS signal from the PSP. Although I've never seen an actual implementation of e.g. OS_SelectTone my guess is that this would ultimately select the synchronization source for the 1Hz signal. The "MET" is probably analogous to the free run timer in the TimeBase object, which is already implemented (a monotonically incrementing tick counter that is reset when the system boots).

With the TimeBase layer the PSP can implement all this logic on its own and it is totally abstract to applications. CFE_TIME just gets a 1Hz callback based on the timebase, and the PSP can decide what to actually synchronize that to.

The main question to evaluate is whether any of the CFE_TIME ground commands or telemetry would change or report this status, and if so, we might need some form of PSP call to get the status in an abstract fashion.

[skliper]

Trac comment by jhageman on 2019-07-03 12:48:08:

Moved unfinished 6.6.1 issues to next minor release