cTBL6000.1 requirement failure - no partial table load field in header

[dmknutsen]

Current requirement verbiage: If the Command specified file's header indicates that the file contains only a portion of the Table, the cFE shall first load an Inactive Table Image with the contents of the Active Table Image and then load the contents of the Command specified File.

There is no field in the header that specifies if a table is a partial load. The software detects the partial load and handles it appropriately.

Describe the solution you'd like
We should update the verbiage or consider combining with cFE-304 (cTBL6000.4).

Requester Info
Dan Knutsen
NASA/Goddard

[jphickey]

IMO we should re-evaluate the basis for the whole "partial load" requirement in TBL. It is responsible for a whole lot of complexity in TBL, and I doubt it really handles the corner cases.

If the goal is to upload a partial table update from the ground to save bandwidth - then I'd propose a more generic "patch" API in FS, that can then produce a complete file that TBL can load.

This would separate the issue, greatly simplify TBL load procedures, while also improving the feature by making partial file transfers available to any app, not just TBL services.

[dmknutsen]

Having never used cFE on a flight project...I'm not really sure of the use case of partial loads. I think it might be possible that the partial load functionality is intended to uplink large tables that can't fit in a single transfer frame (ie uplinked via multiple CADUs). Does cFE provide some kind of 'table buffering' capability in this case or would the ground need to send the table as 'partial' table loads?

[astrogeco]

From my limited flight project experience, partial loads are super useful. Especially for huge apps like Attitude Control which have multiple matrix parameters etc.

[jphickey]

My point is not about "partial loads" in general. I concur completely that the ability to transfer data in potions is critically important. My question was whether this belongs in TBL specifically.

CFE already provides a highly useful, generic "buffering" capability - in the form of filesystem/ramdisk.

Wouldn't more a general-purpose "partial file" be more useful than a "partial table", while still covering all the use cases that a partial table loading gives you?

Wouldn't it be better to assemble a complete table file from (perhaps several) partial files first, then load in TBL services? Why does such complexity need to be baked into CFE_TBL_Load() rather than doing this beforehand/externally? Furthermore, if done properly, if the fragments didn't reassemble correctly into a valid table, one can revert back to the original table. Although I've never tried it, I'm doubtful that something like this is possible with the partial load feature in TBL currently.

This generic "patch file"-based approach would seem to address the large-file problem for TBL services while greatly reducing the complexity of TBL, while also having the benefit of being usable by any entity that works with files, not just TBL.