CSSM Meeting Summary

1. CSSM Meeting Summary CCSDS CSSM Technical Meetings Noordwijkherhout, The Netherlands 31 March – 03 April 2014

2. Agenda (As adjusted during the meetings) Monday, 31 March 0830: CCSDS Plenary 0930: CSS Opening Plenary 1100: Introduction, recap of San Antonio meetings, subsequent progress, agenda adjustments (Barkley/Haddow) 1130: Introductory survey of information entities and general extensibility considerations (Barkley) 1230: Lunch 1330: Service Request/Service Package formal extensibility points (Pietras, Barkley) 1515: Break 1530: Review of Schedule of Services prototype test report (Tuttle, Gnat) 1730: Adjourn Tuesday, 01 April 0845: Timelines Overview – as a basis for planning information in general (Haddow) 0930: Event Sequence extensibility dimensions 1000: Toward accountability (Barkley) – inter specification meta-data engineering 1030: Break 1045: Planning information – toward 1st issue of blue book 1 (work on elaboration of section 5.6 in green book) 1200: Schedule of Services Agency Review planning (Haddow, Barkley) 1230: Lunch 1330: Configuration Profile/Service Agreement vs IOAG Catalog 1 1430: Joint Mtg w CSTS on SANA OID Registration tool 1530: Break 1545: Configuration Profile/Service Agreement vs IOAG Catalog 1 (cont’d) 1630: Planning Information Preview (Haddow) 1730: Adjourn Wednesday, 02 April 0845: Joint meeting, generic file transfer BOF (or maybe a splinter session) 1045: Break 1100: Blue book development planning (planning info, svc req/pkg, config profile/svc agreement, event sequence) 1230: Lunch 1330: Planning information engineering working session (Haddow) 1500: Break 1515: WG Planning, with emphasis for next 6 months (Barkley/Haddow), incl prototype development 1730: Adjourn Thursday, 03 April 0845: discuss SANA registration considerations 0930: TP Engineering discussion 1015: Blue-1 5 year confirmation? 1030: Action Items Review (Tuttle) 1100: AOB, meeting summary, wrap-up 1230: Lunch 1330: Reserved Planning Information working session (if needed) 1530: CSS Closing Plenary 1730: Adjourn

3. Brief Survey of Extensibility • Brief introductory working session • Capture/sketch shown below • Intention is to track extensibility mechanisms as the recommendations develop as tool to help keep the various information • Note that further information re Service Package is later in the summary

4. Service Package/Service Request Extensibilty • General goal is to develop an M2 model of service request and service package such that extensibility concerns are identified; first step is to abstract the components • See next two slides for current status re service request and service package respectively • Presentation for service package is available via http://cwe.ccsds.org/css/docs/CSSSM/Meeting%20Materials/2014/Spring/AbstractServicePkgResultModel-140326.ppt • Further work/study required for these efforts

5. Draft Svc Request Extensibility Component Model • Discussion Notes • The notion of a multiple Service (Contingency) Scenario Specification was challenged as not being in-line with current agency practices • Noted, with conclusion that restriction (per Svc Agreement) to only 1 scenario per request adds very minimal overhead and for time-being, SCSS remains in component model • The (Stored) Data Retrieval Service likely needs to be further abstracted for general pre-cached/off-line type data sources such that forward direction is also accommodated (e.g, forward file services and/or coupling with GFT for files of CLTUs to be radiated)

6. Draft Svc Request Extensibility Component Model • Discussion Notes • Still very much work in progress • Complete CSTS service instance that “span” service packages needs further discussion • Retrieval SP and Retrieval TD may in fact be grouped under a general off-line retrieval component/capabiltiy • Does this tie into generic file transfer?

7. Schedule of Services Prototype Test Report • 3 Test Cases presented • Manually building/exchanging of schedule of services (DLR   NASA in all cases) • Use of automated tools for building/exchanging of schedules of services • Building/exchange of unused/unallocated times • Test results by and large positive – key findings • Correction to XML schema • Clarification re semantics for beginningOfActivity (BOA), beginningOfTrack, endOfTrack, and endOfActivity for unused time publication in draft BB • BOA and EOA are set NULL (only BOT and EOT used in this case) • See presentation in CWE for more details • http://cwe.ccsds.org/css/docs/CSS-SM/Meeting%20Materials/2014/Spring/SSFS%20test%20report%20status.pptx

8. Timelines Discussion • Discussed in the context of planning information entities • Envisioned that these entitles will all be time-series data • Also noted that event sequences may be a candidate for timelines expression • Key point for considerations is to consider provenance or namespaces in constructing timelines • E.g, rather than a (with respect to prototypical communications geometry events) consider an abstract representation such as • T1: AOS • T2: ENTER OCCULTATION • T3: LOS • T4: EXIT OCCULTATION • T5: AOS (etc) • An alternate abstract representation may be • AOS: T1, T5 • ENTER OCCULTATION: T2 • EXIT OCCULTATION T4 • LOS: T3 • Noted that given timelines data exchange (TDE) current BOF of status that a recommendation is not likely for 1st draft of planning information book • Agreed to examine concept and consider adoption of conceptual approach

9. Event Sequencing Extensibility Considerations • Introductory presentation only • Extensibility model discussion differed until late July 2014 • See next slide for introduction to state model for event sequencing • Note: this may be (eventually) be represented by an activity timeline

10. Event Sequencing Overview (telemetry example) Start space link Start data transport  L o n g t i m e  End spacelink End of Spacelink Stop data transport Symbol rate change Start of Spacelink Trajectory Start data transport Data availability at higher symbol rate Data availability at lower symbol rate Spacelink availability t1 t2 t3 t4 t5 t6 t7 t8 Data Transport State Data Transport State Space Link Available State Space Link Available State (In fact, spacecraft may continue to make return space link available so this may in fact be space link available state definition – more later)

11. Planning Data Format – 1st Release Discussion • Part 1 of the Discussion focused on overall meta data, especially in relation to communications geometry • Following are the pieces of meta data identified and notes where appropriate • Time • Absolute (yes) • Relative (no; does not appear to be a general agency practice) • Duration (? – to be determined) • Spacecraft Id • Events • AOS, LOS etc (see next slide) • Event Id • Orbit number (optional parameter) • Timeline Id (maybe)

12. Planning Data Format – 1st Release Discussion • Part 2 of the Discussion focused on event definitions • Following are the preliminary set of events identified with notes as appropriate • Planning Information Events discussion • AOS/LOS • Elevation (relative to ground station) • physical terrain mask • uplink lo + hi power masks • down link mask • fixed elevation (an elevation of interested to the mission) • Rise/Set • Occultations • O|RTLT (One-way or Round Trip Light Time) • Max Elevation (relative to the ground station) • Keyhole • Sun Alignment Angle • Cable Wrap • Range {? – technically O|RTLT cover this } • Noted that 1st items are closely related – some classification work likely needed JP Chamoun (GSFC) to provide relay satellite inputs once initial event list determined

13. Configuration Profile/Service Agreement vs. IOAG Catalog 1 (1/2) • Reviewed analysis of functional group combinations needed for configuring data delivery and radiometric services as identified in IOAG Service Catalog 1 • Main conclusion there are 14 FG combinations that in total address configuration for all of the IOAG C1 services • “infinite” extensibility is not required • We can likley delivery the CP/SA book with “shrink-wrapped” FG combinations and treat extensibility as maintenance updates (similar to that already for RF modulation related books) • See next slide for summary of IOAG C1 service vs. FGs

14. Configuration Profile/Service Agreement vs. IOAG Catalog 1 (2/2) Summary of FGs Needed to Support IOAG C1 Services; Full presentation at http://cwe.ccsds.org/css/docs/CSS-SM/Meeting%20Materials/2014/Spring/StandardServiceConfigurations-140319.ppt

15. Joint Mtg w CSTS re Object Identifiers, SANA • MD-CSTS will register OIDs with SANA – based on functional resource definitions • “Root” defn is: 3/112/4/4/2 • ISO numbers are: identified-organization (3) standards-producing organization(112) ccsds(4) css (4) crossSupportResources (2) • Specific functional resources subsequently identified from here on down • CSTS scheme is that the version number will be the last digit of the OID • The CSSM configuration profile and service agreement information entities will reference selected OID numbers that represent the function group • These will be carried in the XML Schema for the CP and SA • As we have inter-specification dependency, this implies that SANA registration policy for functional resource/group OIDs is necessarily coordinated at the area level

16. Toward Service Accounting • Preliminary/Initial discussion • Main goals/concerns identified • Consistent coherent inter-recommendation meta-data • Usage foreseen for • forensic analysis • Specific contact/tracking pass summarization • Longer term trending re service level/quality commitments • E.g, Over a period of a Week, a Month, a Year • Noted that • Standard defintion of metrics, on a service basis will be useful • E.g, telemetry frame gaps and runs • Functional groups may be a good intial basis against which to provide some of the key service metrics • Agency reps to begin gathering input on reporting metrics for fall meetings

17. Trajectory Prediction • Concluded that as a pure data format project not really needed • Existing ODM Book (502.0-B-2) already addresses this • Green Book to be updated • Project to be removed from CWE Framework

18. SANA Registry Discussion • (See also notes on CSTS OIDs/joint CSTS mtg) • Need to consider namespaces for schemas • Likely to have common schema – inter recommendation • Common schema defn probably only possible once "payload" schemas developed • Policy needs to fit with overall area-level approach • SSoS- White book -- relies on spacecraft Ids; "creates" station/antenna Id registry • Agreed to confer with CESG to see if there are any concerns re “ownership” of stations/antenna identifiers registry by CSS Area

19. Blue-1 Reconfirmation • August 2014 will mark 5 years since B-1 published • Should recommendation be re-confirmed? • DLR: Yes • NASA: Yes • UKSA: Yes • No opinions to the contrary • Minor updates are needed (e.g, proper inclusion of trajectory prediction) • Anticipate project initiation for minor revisions in Spring 2015

20. Long Range Book/Recommendation Planning Discussion • Conclusions • Need to develop an inter-recommendation tracking tool (e.g, spreadsheet or other similar mechanism) to include items such as • Common terms • Dependencies • This may also have a bearing on XML Schema structuring

21. Plan for next 6 months • RID resolutions for SoS by Aug 2014 (assuming agency review completes) • Any updates needed done by Nov 2014 • SoS Prototype Test Report: June 2014 • Complete draft of planning re communications geometry: Nov 2014 • Preliminary write-up configuration profile/service agreement: Nov 2014 • Service Request/Package component write-ups: September 2014 • Preliminary draft of Event Sequencing: Nov 2014 • TeleconSchedule • T1: 28 April • T2: 14 May • T3: 03 Jun • T4: 17 Jun • T5: 15 Jul • T6: 05 Aug • T7: 26 Aug • T8: 16 Sep • T9: 07 Oct • T10: 04 Nov

22. Thank you • Thank you to • Participants for traveling to and contributing to productive meetings • ESA for excellent hosting