|
|
|
Here are some ideas I had about the history replay problem. These ideas are basically derived from Howard's ideas (and from an idea on the subject that Sandy had a couple of months ago.)
Display Replay Telemetry
Process <-----> Process <-----> History
Manager
The Telemetry History Manager would function as suggested in Howard's rough draft for the ADD. Clients would request intervals of data to be extracted from the archive; the THM would locate the data in the archive and play back the requested interval (which could be as small as a single major or minor frame) to the client. Unlike TPOCC's replay mechanism, XSAR's on-demand replay scheme would avoid the need to keep a thousand and one processes coordinated.
The Replay Process would respond to commands from the Display Process (generated by button clicks, etc.) to access a particular telemetry frame, step forward, step backward, jump forward, jump backward, etc. These commands would be translated into requests for the THM. When data is received, the Replay Process would decommutate it and send the desired data items to the Display Process. (The data being sent to the Display Process could be routed through the Data Server in order to fit into the existing TPOCC data services interface.)
The Replay Process would decommutate data using a decommutation library, basically a "callable" Telemetry Decom. (This library could be shared, as Howard suggested, although I don't think its size would be critical.) The decommutation library would include the following functions:
initialize()- prepares for decommutation. This would require loading the telemetry database; I don't know that the system variable database needs to be loaded.
register()- registers a "callback" for a mnemonic. These callbacks are routines that will be called when a mnemonic is decommutated. In our case, for instance, a callback might play the mnemonic's current value out to the Display Process. (Callbacks could also be registered at major and minor frame boundaries.)
mnf_decom()- decommutates a minor frame of data.
mjf_decom()- decommutates a major frame of data. (The XSAR Replay Process should probably perform decommutation in units of major frames.)
The TPOCC Telemetry Decom program is daunting on first glance, but encapsulating the basic decommutation functions in a library would not be difficult, nor would the library be very large. Unlike TLM Decom, the library would not have to respond to state manager commands or data server requests. It would not be responsible for playing data out to the data server; this function would be handled by callbacks. For XSAR purposes, the library only needs to implement decommutation of the XSAR telemetry data types (although it would be to CSC's advantage to write this library in a mission- and operating-system-independent fashion).