1. Tracking Data CSTS v0.7 31 March - 3 April 2014 Noordwijkerhout, Netherlands John Pietras Global Science and Technology, Inc, Greenbelt, MD, USA

2. www.ccsds.org Changes Since Spring 2013 Version  Aligned with March 2014 version of CSTS SFW  Added the Range & Doppler Extraction Functional Resource type to the TD- CSTS production  Added Information Query procedure to report to the user the current status of the service instance  Production status (1)  Procedure configuration parameters of the Association Control procedure (5)  Procedure configuration parameters of the Buffered Tracking Data Message Delivery procedure (3 (or 4?))  Should IQ be mandatory or optional?  Does the service need to support multiple named label lists for so few (10) parameters?  Added Notification procedure to report to the user the events as they occur (bypasses TDM Recording Buffer)  Production status events (5)  Procedure events of the Buffered Tracking Data Message Delivery procedure (3)  Should Notification be mandatory or optional?  Does the service need to support multiple named label lists for so few (8) events? 2

3. www.ccsds.org Things Still To Do  Write (P)ICS Proforma annex  Decouple specification from SCCS Service Management Issue 1 Blue Book 3

4. www.ccsds.org Production Status Questions/Issues  What is the source of production status for a BDD procedure in complete mode?  For the events stored in the Recording Buffer, the production before the recording buffer is appropriate  When a separate Info Query/Cyclic Report/Notification procedure is included to provide a real-time bypass of the recording buffer, the production before the recording buffer is (again) appropriate if the service is operating concurrently with the space link session  Is production status meaningful for complete mode when in pure playback (no concurrent SLS)?  If so, it would need to be the status of the Recording Buffer  When in real-time mode, if a separate Notification procedure is included, the same notifications can be sent twice in real time, once through BDD and once through Notification  Ironically, if the link is congested, the Notification procedure could cause the BDD to discard buffers containing the same notifications 4

5. www.ccsds.org Issue: No Labels for Procedure Parameters/Events  I wanted to have the TD-CSTS define the default parameter label list and event label list to contain the labels for the generic service parameters and events (production status related) and the procedure-specific parameters and events (e.g., return-buffer-size and ‘end of data’)  Issue – “Label” definition is limited to parameters and events of FR types: labels aren’t defined for procedure parameters and events  As of now, the only way to include procedure events in list-of-events is to list the full procedure event names  Includes procedure role  Recommendation: explore allowing Labels for procedure events (and parameters), e.g., [{Buffered Data Delivery}:’end of data’] 5

6. www.ccsds.org Simple Adoption of CSTS SFW Procedures (1 of 2)  Contents of list-of-parameters and list-of-events in CSTS SFW procedures are now defined as valid terms of parameters [events] of Functional Resource instances that are “associated with the service instance that executes the …procedure”  This eliminates the possibility of a procedure accessing multiple instance of an FR unless explicitly modified as in the MD-CSTS case  Intended to allow almost all “normal” CSTSes to simple adopt these procedures without further derivation  However, the wording still allows as valid all parameters/events of such an associated FR instance  If we want to restrict the valid values to a subset, the behavior has to be refined 6

7. www.ccsds.org Simple Adoption of CSTS SFW Procedures (2 of 2)  3 possible approaches (maybe more)  Leave it as currently stated in CSTS SFW Can still be simply adopted for those services that allow access to all parameters of the instances Must be refined for any subsetting  Limit nominal validity statements to cover only generic service and procedure configuration parameters/events Can be simple adopted for any service that doesn’t need to report anything about it’s production’s parameters/events except production status Must be refined to add any production-related parameters/events  Rephrase validity statements to be along the lines of “the parameters [events] that are defined by the service specification that are associated with the instances of the FR types that are associated with the service instance that executes the … procedure” Requires all service procedures to be at least refined However, the refinement can be concentrated into a simple, single list of support parameter/event labels* 7 * See previous issue about procedure configuration parameter/event labels

8. www.ccsds.org Other Issues  Assume return buffer size the configured value, not the instantaneous value  Change in return buffer size would trigger too many notifications  There should be separate names for the configuration parameter vs. instantaneous value  For the BDD procedure, the latency-limit used to be listed as a configuration parameter but it is not currently listed in Table 4-16  Recording buffer size is listed in CSTS SFW as a configuration parameter of the BDD procedure. It is really a parameter of the Recording Buffer production, and only reportable through its association with the BDD 8