Time not using Critical Data Store

[dmknutsen]

Describe the bug
The following requirements specify that TIME should be using CDS:

cTIME2502
Upon a Processor Reset the cFE shall verify the Critical Data Store used to store time values.

cTIME2501
Upon a Processor Reset the cFE shall acquire the following time elements from the <MISSION_DEFINED> Critical Data Store:

• Time Status Data
• STCF
• Leap Seconds

cTIME2700
During normal operation, the cFE shall preserve the following time elements in the <MISSION_DEFINED> Critical Data Store:

• Time Status Data
• STCF
• Leap Seconds
• MET

cTIME2502.1
If the critical data store is not valid, all of the time elements shall be initialized in the same fashion as following a power-on reset.

There is no CDS for time – the respective variables are preserved through the Reset Area.

Expected behavior
The requirements or FSW should be updated to reflect intended implementation.

Reporter Info
Dan Knutsen
NASA/Goddard

[jphickey]

I'm going to guess that this evolved this way because the "Reset Area" is always memory-mapped (i.e. accessible via pointer) whereas the CDS only has an indirect read/write API via the PSP.

But in reality the CDS and reset area are effectively the same thing on the three platforms in the framework - they are allocated together and use the same underlying storage mechanisms for both.

That being said - this use of the "Reset area" by TIME (and I think EVS too) is one of the few remaining things that require a sort of "backdoor" or private/non-public interface between CFE core apps - as ES technically "owns" this data structure.

There are a couple approaches that could work:

1. Use table services with a "critical" table to store these time variables. This should in turn be backed by a CDS, with the advantage that all of the regular TBL management stuff will apply too (e.g. dumps, etc). But will have to review the code to make sure it won't add overhead - it is important that these TIME variables can be accessed quickly with low overhead, and they change frequently with every time at tone message. The "page flipping" of the reference data implemented in TIME is somewhat similar to a double buffered table already.

2. Just formalize what is already there, and divide the current ES "reset area" into a separate area for each of the core apps.

I think option 1 is better long term but it is more work and involves more risk of regressions. Because these extra internal-only interfaces (like the reset area) are a maintenance issue and increase the complexity of the code and the difficulty of porting to new platforms. Making everything work through TBL services and the existing CDS simplifies things.

[skliper]

Marked as enhancement to reflect that the spirit of the requirement is met (persistent time data) it's just not in what the implementation calls the "critical data store". Should address this along with the planned major TIME refactor work #302 and others.