CSSM Meeting Summary Fall 2012 Meetings 15 – 18 October E. Barkley Chair (NASA/JPL) C. Haddow Co-Chair (ESA/ESOC) Cleveland, Ohio, USA

eb- 2 Contents 1. Joint Session – CSSM/CSA WGs 2. Draft Concept Review 3. Framework Outline and ‘Client’ Recommendations 4. Framework Extensibility Mechanism 5. Roadmap 6. Information Entities 7. Concept Book Project Definition 8. Schedule of Services Project Definition 9. Schedule of Services Project Definition 10. Framework Project Definition 11. Joint Session – CSSM/CSTS WGs 12. Current Agency Blue-1 Implementations 13. Timelines Discussion 14. JAXA Prototype Test Report 15. Planning for next 6 months

Joint Session CSSM/CSA WGs Agreed to harmonize Enterprise models Agreed that CSA WG will take lead in producing SysML model CSSM will subsequently work toward fitting into/revising CSA SysML model

eb- 4 Draft Concept Review Key Updates Agreed Upon Enterprise model to start in section 2 May need more elaboration of enterprise model in section 3 prior to lifecycle Service agreement needs to allow for multiple spacecraft definitions Rework summary section (framework definition, diagrams) May 2011 Berlin, Germany

“Client” Book Outline Given Framework Book (Exploration of End-State) No significant changes suggested Question was raised: is extensibility re modulation schemes is captured in managed services books? Is the modulation scheme in the managed service books or the framework? (…segue to extensibility mechanism..)

Framework Extensibility Mechanism Main question is to what level extensibility is needed – ie., is it relatively coarse grain or fine grain Related to functional resources vs service access points - E,g. Will CCSDS ever offer a standardized intermediate frequency out type of service? (vs., telemetry frames) - Does it makes sense to “pre-cook” sub-service level (mostly related to space link) configurations and offer those as the significant extension points - E.g, CCSDS 401 style space link vs CCSDS 415 style space link vs DVB-S2 style space link Other significant questions include Do we essentially assume a component model, given the functional resources? Is the functional model OID tree part of this component model’s meta-data?

Roadmap No significant issues were noted with general flow of roadmap Further write-up to be provided in the Concept Book - Editorial Note (not discussed): Schedule of Services is ahead of 1 st version of framework effort per project definitions -- WG Chair comment: technical risk, deemed acceptable

Information Entities (Scheduling Focus) Review of schedule format information suggests following items as a first cut: Service Times - Start of Activity - Beginning of Track (Pass) - End of Track (Pass) - End of Activity Mission Identifier Station Identifier Antenna Identifier Service Package Identifier Some discussion points: Some networks have the same value for station identifier and antenna identifier (i.e., the station is the antenna) NASA SN does not appear to be well represented by this yet – it seems to be a reasonable starting point for other networks Agreed that specification/information needs to be kept relatively small - Engage agency reviewers sooner rather than later

Concept Book Project Definition

Schedule Format Project

Framework Project Definition

Joint Session CSSM + CSTS Main focus was review and discussion of functional resources; especially so from the point of view of being applicable to the CSS Area in general Conclusions The OID (Object ID) tree needs further development; CCSDS portion beginning directly with CSTS is an understandable artifact of CSTSWG origin but needs revision for broader scope SANA registry policy for functional resources (FRs) is an Area Level concern, as FRs have a bearing on both CSTS and CSSM recommendations Question about instance identifiers for monitoring reporting for a service package execution with multiple antennas involved and/or multiple scenarios (is there a hierarchy of instance identifiers) ? - Consensus is to associate instance identifiers at per production chain/station/antenna level – should imply a “flat” instance identifier scheme

Current Agency Blue-1 Implementation Activities NASA: SGSS (for Space Network) - Currently in development - utilizing Blue-1 as basis for machine-to-machine interfaces; - Significant extensions to Blue-1 with a concentration in service package management service - E.g., Wait-listing of service packages, (conditional) “chaining” of alternate sets of service packages - See “SGSS_extension_of_SCCS-SM ” presentation for further information NASA Space Communication and Navigation office is considering a NASA wide portal development using CCSDS B-1 XML Schema as a starting point

Timelines Discussion Reviewed introductory material See dated 15 October 2012 from C. Haddow, subject “Timeline standardization telecon follow-up” Agreed that schedule data is very likely a good candidate for a “payload” for a general timelines data format and/or timelines management system Unclear as to whether a schedule will ultimately be GLTL (Ground Linear Time Line) or ATL (Activity Time Line) Approach is start with assumption of GLTL

JAXA Test Report Updated JAXA Blue-1 prototype test report reviewed and approved To be included in yellow book report thereby recording all prototype activities

Planning  Spring 2013 (1/3)

Planning  Spring 2013 (2/3)

Planning  Spring 2013 (3/3)

Thank You Thank you to all attendees for a very successful CSSM WG inaugural meeting.