Interagency Operations Advisory Group Mission Operations Systems Strategy

Interagency Operations Advisory Group Mission Operations Systems Strategy Group Recommendations on a Strategy for Mission Operations Systems Interoperability August 5, 2016 FINAL REPORT IOAG-MOSSG Final Report, August 5, 2016

CONTENTS 1. Introduction 2. Interoperability Considerations and Trends 3. The Service Catalog Approach 4. Findings and Recommendations 5. Service Evaluation Factors 6. Summary and Future Plans Appendix A: Summary of Findings and Recommendations IOAG-MOSSG Final Report, August 5, 2016 2

Acronyms AMS CCSDS CFDP CNES COTS CSA CSS CSTS DLR DTN ESA ESTEC GSFC HOSC ICD IDD IOAG IP ISECG ISO ISS IT Asynchronous Message Service Consultative Committee on Space Data Standards CCSDS File Delivery Protocol Centre National d'Études Spatiales Commercial Off-the-shelf Canadian Space Agency Cross Support Service Cross Support Transfer Services Deutsches Zentrum für Luft- und Raumfahrt Delay Tolerant Networking European Space Agency European Space Research and Technology Centre Goddard Space Flight Center Huntsville Operations Support Center Interface Control Document Interface Definition Document Interagency Operations Advisory Group Internet Protocol International Space Exploration Coordination Group International Organization for Standardization International Space Station Information Technology IOAG-MOSSG Final Report, August 5, 2016 JAXA MO MOC MOIMS MOSCG MOSSG MSFC NASA OSTM Qo. S RF RT SANA SISG SLE SM SM&C SOA SW TC TM TOGAF USLP WG WWW Japan Aerospace Exploration Agency Mission Operations Center Mission Operations and Information Management Services Mission Operations Systems Coordination Group Mission Operations Systems Strategy Group Marshall Space Flight Center National Aeronautics and Space Administration Ocean Surface Topography Mission Quality of Service Radio Frequency Real Time or Real-time Space Assigned Numbers Authority Space Internetworking Strategy Group Space Link Extension Service Management Spacecraft Monitoring & Control Service-oriented Architecture Software Telecommand Telemetry The Open Group Architecture Framework Unified Space Data Link Protocol Working Group Worldwide Web 3

1 Introduction IOAG-MOSSG Final Report, August 5, 2016 4

IOAG MOSSG Membership Co-chairmen: Francois Allard Dan Smith European Space Agency (ESA) European Space Research and Technology Centre (ESTEC) National Aeronautics and Space Administration (NASA), Goddard Space Flight Center (GSFC) Members: Centre National d'Études Spatiales (CNES) • Marc Duhaze Canadian Space Agency (CSA) • • Kenneth Lord David Shaffer Deutsches Zentrum für Luft- und Raumfahrt (DLR) • Marcin Gnat IOAG-MOSSG Final Report, August 5, 2016 Japan Aerospace Exploration Agency (JAXA) • Yoshikazu Miyano National Aeronautics and Space Administration (NASA) • • Lena Braatz (Technical Editor, Booz Allen Hamilton/NASA Headquarters) Marilyn Newhouse (HOSC Services Contract/NASA Marshall Space Flight Center (MSFC) Kelvin Nichols (NASA MSFC) Lindolfo Martinez (Lockheed Martin Corp. /NASA Johnson Space Center) 5

Purpose This report is intended to provide overall strategic findings and recommendations of the IOAG’s Mission Operations Systems Strategy Group (MOSSG) related to the use of mission operations services in support of cross-agency (Control Center to Control Center) interoperability for space mission operations. NOTES: 1. This report is presented in Power. Point presentation format to allow for release much earlier than would be possible if a full report document were to be completed per the original MOSSG plans. 2. The MOSSG deliverables, per IOAG direction, consist of this report and “Service Catalog #3” for review describing recommended mission operations services and priorities. A third deliverable, a system-level interoperability prototype, was always considered optional based on funding availability and has not been developed. IOAG-MOSSG Final Report, August 5, 2016 6

MOSSG Objective The objective of the MOSSG is to make recommendations to foster a greater ability to achieve cooperation and interoperability among our space agencies, specifically leading to. . . Greater integration among mission operations functions across multiple agencies Greater capabilities for future multi-agency spaceflight missions, both large and small Greater efficiency as these capabilities are reused from program to program and from generation to generation Greater adherence to standards and beneficial recommendations for new standards from groups including CCSDS Recommendations to IOAG member agencies on how to better support each other and work together in the Mission Operations domain The practical perspective within an agency: Improve the ability of single- and multi-mission control centers to serve the interoperability needs of future programs. IOAG-MOSSG Final Report, August 5, 2016 7

MOSSG Vision All member space agencies foster and develop the ability for operators of ground and space assets to cooperate in an efficient manner by sharing and utilizing as appropriate the current and future data formats, protocols, systems, and infrastructure, thereby reducing costs and the time needed to implement and conduct multi-national space missions. The implementation of interoperability functionality is prudent for all space programs and is a clear requirement for multi-agency programs. Programs should always consider the potential need for interoperability with other agencies’ resources at some time in their mission life and therefore the adoption of appropriate interoperability standards should be considered when developing requirements for all missions. The Service Catalog #3 effort focuses on short- and medium-term software-based efforts to promote interagency interoperability between control centers. Very longterm visions of seamless joint operations for complex missions espoused by CCSDS or the International Space Exploration Coordination Group (ISECG) are not precluded and can be addressed as technology, common practices, and the available standards evolve. It should be noted that software-based efforts have a much shorter technology/development cycle time than standard device and protocol efforts, which normally require the development of space assets or ground infrastructure. IOAG-MOSSG Final Report, August 5, 2016 8

Activities of the MOSSG The IOAG Mission Operations Systems Strategy Group (MOSSG) was formed in Fall of 2013 The team conducted business through bi-weekly team telecons and met together twice a year in the week preceding the semi-annual CCSDS technical meetings. In considering interoperability the MOSSG reviewed: Material from the IOAG and MOSCG Current operational programs including; ö ISS Columbus Operations ö ISS Robotic Operations ö OSTM/Jason 2 Robotic Operations Potential programs defined by the ISECG in their Global Exploration Roadmap The work of the CCSDS Working Groups IOAG-MOSSG Final Report, August 5, 2016 9

2 Interoperability Considerations and Trends Cross-agency joint missions, by definition, require some level of system interoperability. Agencies must consider much more than just the definition of standard interfaces and standards to connect their systems. This section presents key concepts and considerations for full system interoperability. IOAG-MOSSG Final Report, August 5, 2016 10

Infrastructure Future multi-agency programs should agree on the infrastructure architecture before developing or adapting their mission operations systems ö May include voice and video systems, timing, networks, security, shared data storage systems Network considerations ö Private networks v. the Internet ö Growth capacity required – demands for data will increase ö Qo. S requirements and delay tolerance Security ö Network, cloud, and applications access rules often differ by agency – it is critical to define and incorporate common approaches early ö Different data elements may require different security rules Future interagency infrastructures need to be scalable in order to manage the exponential growth for bandwidth, the increase in the number of users/systems, and the need for operations and science activities. IOAG-MOSSG Final Report, August 5, 2016 11

System Architecture – Choices for Interaction The following technology options should be considered as multi-mission architectures are developed: Application Sharing (run copies of the same software components) ö Widely used on ISS ö Better suited within programs Client/Server ö Allows for data sharing ö Users have flexibility on how to use/display the data ö Requirements placed on user infrastructure Service Oriented Architecture ö Common buses link Agencies who advertise mission operations services ö Common bus capitalizes on IP Protocols and services ö Any bus user could subscribe to access the service Remote Access ö ö Applications support remote log-on, remote access, collaborative work Now the new model for ISS; many COTS systems support this approach Fast and easy to establish Processing concentrated in unique centers Cloud ö Emerging approach for use of common/remote applications and data storage IOAG-MOSSG Final Report, August 5, 2016 12

Development Considerations Service quality should be built in at development time and is not part of the service standard. Examples include: Reliability, redundancy, auto-recovery Performance, availability, and maintainability Optional user interfaces, error checking Ease of integration, ease of maintenance Interoperability should account for use of legacy systems Cannot expect agencies to “start from scratch” to develop interoperable systems Legacy system “adapters” can be used to match individual components to new format or service standards A gateway (front-end processor, edge connector) can serve as a primary portal between dissimilar systems, supporting interoperable interfaces on one side and legacy interfaces on the other. IOAG-MOSSG Final Report, August 5, 2016 13

Program Considerations (1 of 2) Joint operations concepts and agreements are required Agencies must agree on overall concepts, data exchanges, processing responsibilities, and access needs Goal to reduce dependency on extensive ICDs ö SOA with service directory allows for common usage and interface definition ö Standards-based formats and services reduce need for additional documentation ö Interface definition documents (IDDs) used to specify interface plans Governance processes must be established Agreements are critical, given the complexities of data distribution and ownership, the sharing of software and interfaces, and the longevity of many missions "Centers of Excellence" supporting multiple multilateral programs will require management and governance. Key topics include: ö Limited liability ö Ownership of data; restrictions on use and distribution of data, etc. ö Handling of software/system problem reports, upgrades when balancing competing priorities of different agencies ö Need for configuration board IOAG-MOSSG Final Report, August 5, 2016 14

Program Considerations (2 of 2) Technical support and commitment should be documented Distributed capabilities and services require special attention Service level agreements should be established Training and help-desk support should be provided for service users Must be assured that service support will remain for duration of mission Rules must be established for how service, interface, or support changes are announced, implemented, transitioned Support needs will vary depending on the criticality of the function or data There must be an awareness of competing priorities across agencies Agencies must have a long-term view to reap the benefits from standards-based Interagency Operations Ideally, agencies will meet interoperability needs for an individual mission through the use of capabilities also common to other missions within the same agency or across multiple agencies. But this approach may be in conflict with desires or priorities to be consistent with agency internal common approaches or between an agency and other government or commercial organizations. Agency pressures to reduce operating costs may influence interoperability decisions Agency desires to continue innovating in system design and operations approaches will put pressure on all participants in shared mission operations – it is important to reduce cross-agency interdependence while encouraging cross-agency interaction through common interfaces and standards. IOAG-MOSSG Final Report, August 5, 2016 15

Trends affecting mission operations systems Increase use of IP over WWW and national or private internets Increased security challenges; networks of networks, advanced secure gateways/portals Cloud computing and data storage Rapid deployment; operations from anywhere Open source software – including full telemetry and command systems Automated spacecraft and ground operations Increased use of commercial commodity communications and services Observations These trends have the potential to significantly change how missions are operated in the future and how their mission support systems are developed and deployed. The CCSDS format and service standards are compatible with all of these future trends. IOAG-MOSSG Final Report, August 5, 2016 16

3 The Service Catalog Approach IOAG-MOSSG Final Report, August 5, 2016 17

MOSSG Service Catalog #3 Context Mission Needs and Requirements Inter. Operability Plenary Technology Drivers Agency Plans and Future Mission Policy Drivers Needs for Standardization St ra t gu egy ida le nc vel e Space Internetworking Standards SISG MOSSG Mission Ops Standards IOAG-MOSSG Final Report, August 5, 2016 ISECG Service Catalog #1 Link Layer Service Catalog #2 Netwk Layer Int’l Mission Programs and Projects Capabilities for Int’l Mission Interoperability Service Catalog #3 App Layer 18

Service Catalog #3 (1 of 2) Interoperability Definition (From CCSDS SANA Glossary) The technical capability of two or more systems or components to exchange information and to use the information that has been exchanged. Multiple degrees of interoperability are possible, ranging from basic physical layer (e. g. , frequency, modulation and coding) compatibility up to full application layer information exchange. Framework and Functional Services The IOAG effort focuses on the functional services needed to support mission- specific interoperability. With a full service-based approach, these mission support functional services rely on an integrating services framework. The framework may include registries, security and logon provisions, time capabilities, and transport services. CCSDS has developed standards for much of this type of framework as part of their mission operations services set of specifications. IOAG-MOSSG Final Report, August 5, 2016 19

Service Catalog #3 (2 of 2) Standard Formats and Standard Services Interoperability requires system interactions covering both data exchange and system behavior/processing. Formats-only standards are easy to develop to and provide flexibility for use in different architectures. Behaviors may be implied, specified in an interface document, or managed by configuration files or user inputs. Service standards support the exchange of data, but the emphasis is on the interaction activity and the types of data exchanged – not necessarily the exact format of the data elements. The services approach will take longer to develop, but has advantages of including the interaction and utility tool support not possible with a simple format definition. The IOAG-MOSSG recommends that functional interoperability areas be addressed both by service specification standards and by format specification standards. IOAG-MOSSG Final Report, August 5, 2016 20

MOSSG Interoperability Model Interoperability Levels 4 3 2 1 0 Extensive: Data exchange approaches are routine, incorporated into policy and tools. Assumed for each mission. MOSSG primary focus is on level 2 Progression from level 1 to levels 2, 3, and 4 can be viewed as a simplified longterm roadmap for increasing interoperability across the Agencies. Governance Policy High: Common services and applications; COTS product support. Developed to multi-agency requirements/standards. Agencies acquire common systems (executable SW, not just interfaces); Team members have common tools and common training on those tools. Service level (MO Services) Agencies develop or adapt systems to Moderate: Standardized Interfaces, satisfy standard interfaces formats, services. Multi-program; Multi-Agency, standards developed collaboratively, software may be developed independently. . Data Format Level Minimal: Single Agency Interfaces applied to multiple agencies Program-unique; often not designed for reuse; not developed collaboratively. ISS Case (in general): Lead agency specifies exchange data formats Essentially None: Reliance on public infrastructure such as voice calls IOAG-MOSSG Final Report, August 5, 2016 21

Interoperability—It’s not just MO Services Mission Operations Interoperability IOAG SERVICE GROUPS Ground Station Control and Data Acquisition Ch. 4. 7: Interoperability Framework • SERVICE CAT 1 • Network, Transport • SERVICE CAT 2 • Language Bindings • Login Service • Directory Service • Configuration Service • Interaction Service Ch. 4. 1: Telemetry Services KEY: (SC#3 Ref) MO Service Group Ground-Ground Ch. 4. 3: Data Access Services Ch 4. 2: Command Services • Real-time Processed • Real-time Parameter Service Command Service • Telemetry Packet • Deferred-time Distribution Service Command Service • Bitstream Distribution • Command History Service Distribution Service Headin g Applications Services • Mission Parameters Distribution Service • Archive Retrieval Service • Telemetry Replay Service • Product Distribution Service Space-Ground Ch. 4. 4: Planning and Scheduling Services • Scheduling Service • Activity Request Service Supporting Capabilities Mission-Specific Ch. 4. 5: Navigation Services • Navigation Data Service • • Remote Access Shared Data Portal Voice Loops Video channels Ch. 4. 6: Support Services • Alert and Broadcast Message Service • Data Definitions Provision Service • Time Provision Service Out of Scope for this Effort IOAG-MOSSG Final Report, August 5, 2016 22

4 Findings and Recommendations IOAG-MOSSG Final Report, August 5, 2016 23

Introduction to Findings The MOSSG concluded that the ongoing CCSDS mission operations services standardization effort represents a very ambitious effort, which appears to be addressing a mixed and ad hoc set of goals from the many working group members and standards developers. It is hoped that by providing suggestions for a clear set of objectives, service approaches, and priorities, the MO Services can reach an initial baseline usability level in a timely fashion and establish a foundation for future strategic direction and growth. Only ground-to-ground interactions are considered here since the MOSSG concluded that, in the short- to mid-term, the primary use of MO Services is for MOC-MOC interfaces. Although onboard use of MO services may provide significant value to missions, it may also introduce particular additional challenges. These are not addressed here. Eight key findings have been identified: F 1. Scope F 2. Standards Development Roadmap F 3. Range of Interoperability Needs F 4. Long-Term Innovation IOAG-MOSSG Final Report, August 5, 2016 F 5. Cohesive Approach Across all of CCSDS F 6. Promoting Infusion and Use F 7. Code Sharing F 8. Need for Guiding Principles 24

Finding 1: Scope Finding: F 1. Scope: The size and scope of the CCSDS MO Services standards framework is too large to expect that the effort will be completed in a “reasonable” time period, commensurate with other industry standards development efforts. Risks: Given such a long lead time to standards development, a new disruptive paradigm could very well emerge that would supplant the generalized service approach, causing the whole effort to become obsolete prior to its completion and establishment. End-users may view the perceived lack of an initial baseline set of services as an indication of “a work in progress” and will delay consideration of the use of the standards. Recommendations: R 1. 1: Focus on completing a limited set of MO Services for two to three functional areas only (of high priority from CCSDS participating agencies) and push within the agencies for their operational use. R 1. 2: Limit future technology bindings to most prevalent technologies per inputs from the member agencies. R 1. 3: Do not focus on onboard capabilities. Agencies are always encouraged to develop innovative uses for the standards and the MO services may well be able to run anywhere, but specific work for onboard capabilities should be managed by, and coordinated with, those other standards teams already working on onboard system and service standards. IOAG-MOSSG Final Report, August 5, 2016 25

Finding 2: Standards Development Roadmap Finding: F 2. Standards Development Roadmap: A complete roadmap showing the full suite of existing and planned mission operations services, their key development milestones, and the organization (standards working group) assigned to the standards development is essential to gaining confidence across the agencies and their missions. Risk: As with the scope issue (Finding #1), the many potential users of MO services are reluctant to invest in capabilities for which the growth path and completion plans are not clear. This is true of agencies, missions, and COTS vendors. Recommendation: R 2. 1: The MO services team should place a high priority on developing the full roadmap of standards and bindings to be developed, utilizing the IOAG MOSSG Service Catalog #3 material as one set of inputs. The effort to create the roadmap may have the additional benefit of ensuring that all members of the standards development organizations and their agencies agree on a consolidated plan of action. IOAG-MOSSG Final Report, August 5, 2016 26

Finding 3: Range of Interoperability Needs Finding: F 3. Range of Interoperability Needs: It was clear to the MOSSG team, which studied a range of missions, that the extent to which interoperability capabilities will be required varies greatly. It is important that the MO services team explicitly address the spectrum of interoperability degrees (illustrated in the table on next page). Risk: MO services not sufficiently flexible to support the wide range of anticipated or potential mission interoperability complexities. Recommendations: R 3. 1: Throughout the MO Service specification and prototype efforts, utilize an explicit range of mission types with different degrees of interoperability when matching new standards to mission needs. For new services, include documentation on how they could be utilized across different mission classes. Mission type examples: a. Agency X needs limited telemetry or data products from Agency Y b. Payload X on Satellite Y or multiple payloads from different agencies c. Multiple missions with coordinated activities/goals (Mars, lunar, Earth observation) d. Jointly operated missions (ISS) IOAG-MOSSG Final Report, August 5, 2016 27

Finding 3: Range of Interoperability Needs, continued R 3. 2: The MO services team should clearly document its decision approach for determining the core set of functional capabilities for a service and how both subsets and supersets of the functional list can be handled. a. SUGGESTED APPROACH: The standard should cover the minimally accepted capability set to enable basic interoperability. Individual service providers may incorporate any additional capabilities as they see fit, but are encouraged to meet the minimum set of capabilities of the standard. Ideas for additional capabilities (typically gathered from many end-users based on their experiences with their mission sets) can be provided as an informational list. The service suite should not attempt to specify every good idea received from the working group members. b. OPTIONS: The service specification could support both the minimal set and an optional set of additional capabilities. Developers could then claim to meet either Level 1 or Level 2 (for example) service support. The specification could also include, for example, a block of op-codes reserved for mission-specific use. IOAG-MOSSG Final Report, August 5, 2016 28

Key Functions for Center-to-Center Interoperability Degree of Interoperability High Low IOAG-MOSSG Final Report, August 5, 2016 29

Finding 4: Long-term Innovation Finding: F 4. Long-term Innovation: The rate of functional innovation for software-based systems and services is much higher than the rate of change for many other standards, including RF link protocols, packet formats, etc. It is important that the MO services recognize and support the need for agencies, missions, or COTS product providers to additional services or to add capabilities to existing services without requiring modifications to the documented standards. Risks: Missions will develop their own independent solutions to incorporate their expanded capability needs or key innovations and the use of the formal MO services may be reduced. COTS vendors may find that they have a choice of getting out of the business or competing against the entire MO services approach so they can rapidly make product advances and offer creative solutions to their customers. Missions will limit themselves to the MO services without the enhanced capabilities Recommendations: R 4. 1: Must clearly document how innovations may be added to the standard services and what the implications are to the formal standards. For example, could establish reserved OP Codes within services for local use. R 4. 2: Need a functional review/refresh plan that addresses the potential for upgrades to major parts of the MO effort. IOAG-MOSSG Final Report, August 5, 2016 30

Finding 5: Cohesive Approach Across All of CCSDS Finding: F 5. Cohesive Approach Across All of CCSDS: CCSDS has multiple efforts working on services, service management, and service frameworks. It was not clear to the MOSSG team that these efforts are coordinated with each other. There may be significant overlap or inconsistency among the efforts. Risk: The lack of a common framework for services within CCSDS will result in confusion and inefficient use of limited CCSDS and agency development resources. Recommendations: R 5. 1: Clarify the boundaries between MO Services Working Groups and other CCSDS Areas and working groups. R 5. 2: Define a common CCSDS service framework for use across all ground elements. IOAG-MOSSG Final Report, August 5, 2016 31

Finding 6: Promoting Infusion and Use Finding: F 6. Promoting Infusion and Use: There is an inherent difficulty in adopting any new suite of standards or approaches. Approval to incorporate a service-oriented approach may be particularly difficult since the paradigm is better known in software development circles than in management circles. This raises the importance of agencies working together to collectively promote the infusion of the MO services approach. Risk: The MO services approach will stay restricted to individual development efforts and only a small team of experts. Recommendations: R 6. 1: Define a “minimal MO Services Suite” which could be adopted as a lower-cost-of-entry approach for selected missions. R 6. 2: Ensure that there are both format-based and service-based standards developed for each key function. The format approach will allow for quicker adoption and allows users to exchange data for interoperability without having to build a fully compliant software framework. R 6. 3: Consider the development of a cross-agency interoperability demonstration to highlight the many benefits and capabilities of the suite of standards. This demo would showcase the overall MO vision, and not just a single standard as is currently done with CCSDS prototypes. R 6. 4: Encourage agencies to share their lessons learned as MO services are developed and utilized. IOAG-MOSSG Final Report, August 5, 2016 32

Finding 7: Code Sharing Finding: F 7. Code Sharing: Code sharing through CCSDS has been proposed as a means of MO services standards infusion across space agencies and is listed as a key benefit of the services approach. Risk: Puts CCSDS in the software release, maintenance, and sustainment business; not to mention the complexities associated with software licensing. Recommendations: R 7. 1: Standards organizations should focus on providing interagency and intra-agency MO services interoperability specifications only, not implementation R 7. 2: Limit any CCSDS-coordinated code sharing to purely technology proof-of-concept demonstrations R 7. 3: IOAG suggests that CCSDS encourage agencies to develop and share software, possibly as open source; but it should be the responsibility of the agencies to promote and share any software they wish to make available. IOAG-MOSSG Final Report, August 5, 2016 33

Finding 8: Need for Guiding Principles Finding: F 8. Need for Guiding Principles: No set of guiding (or architecture) principles appears to exist for the depth and scope for the definition of MO services. Risk: MO services may not conform to consistent levels of granularity, quality and usability. Considerable effort may be expended on individual MO services which, if completed as planned, do not meet established criteria for a high-quality, widely useable, international service standard. Recommendation: R 8. 1: Develop a small set (~6 to 10) of guiding/architecture principles or criteria that the MO services development team shall use to guide the evolution of the standards. Recall that principles are “general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission. ” (Source: The Open Group Architecture Framework [TOGAF], Version 9. 1). The MOSSG has developed a sample set of Service Evaluation Factors which could form the basis for the guiding principles (see Section 5). IOAG-MOSSG Final Report, August 5, 2016 34

5 Service Evaluation Factors IOAG-MOSSG Final Report, August 5, 2016 35

Considerations for Suitability for Interoperability Development of new standards should only be undertaken after careful evaluation of plans against established criteria. The MOSSG has identified a wide variety of candidate factors against which plans for future services can be evaluated. Mission operations service developers should consider evaluating their systems against a similar list (and modifying as necessary) as they plan future activities. The MOSSG has organized the service evaluation factors into the following categories: Meeting interoperability objectives Ease of adoption of the MO services standards Service quality IOAG-MOSSG Final Report, August 5, 2016 36

Service Evaluation Factors: Meeting Interoperability Objectives Common Need. Does the service respond to multi-agency and multiple-mission needs? A formal international standard is typically not needed if the primary purpose is for a single mission – regardless of its size. The standard should have general applicability across a wide range of mission types Coverage of interoperability services: Is development of the service supportive of the vision identified in Service Catalog #3? Use of Services. Is the development and use of a new standard service the most appropriate method to meet the specific interoperability objective for missions today and those envisioned for the future? For example, a common user interface or display standard could be developed, but it may be better for missions to simply utilize display-sharing software now commonly available. Contribute to the Larger Plan: Does the service complement the mission operations services already developed, and does it fit in with the overall MO services vision? Compatibility with program integration requirements: Programs have different degrees of integration and levels of interoperability. Will the service to be developed support the range of mission types and needs? Can the service be used to meet a need regardless of the mission size or complexity? Multiple services with similar functionality should not be required as a way to meet the needs of different mission sets. IOAG-MOSSG Final Report, August 5, 2016 37

Service Evaluation Factors: Ease of Adoption of the MO Services Standards Ease of adoption: Will existing or future programs adopt the proposed SM&C standards easily ? What could be show-stoppers and difficulties? Compatibility with legacy systems: Will the proposed MO service standard support the use of legacy capabilities? And how? Can simple adapters be developed to interface between MO services and legacy systems? Reuse of software capabilities across programs: Will the proposed SM&C and MOIMs standards support re-use across programs? How? Handling specific mission needs: What policy is in place or planned for handling subsets or supersets of an international service specification standard as needed to meet a mission’s specific requirements? IOAG-MOSSG Final Report, August 5, 2016 38

Service Evaluation Factors: Service Quality Correct service orientation: Services need to have characteristics like scalability, being easy to combine to support larger functions, self-contained. Do MO services standards promote these concepts? Standard support structure: It is hoped that MO services will be widely adopted and compatible with many products and systems across many agencies. How well is the proposed standard supported? What would be needed to make that support effective? Are prototype reports or software available? Any there any user experiences or lessons learned? Any COTS vendor interest? Compatibility with lower level standards: Will SM&C and other MOIMs standards be compatible with other CCSDS standards established at different ISO layers (e. g. CSS SM, SLE & CSTS, DTN, USLP, AMS, CFDP, etc. )? Resilience to IT technology evolution: It is clear that IT technology will continue to evolve. Any adopted standard must thus offer some resilience to such evolutions or must accommodate changes. Can the MO service standard be compatible with likely evolutions of IT technology or requests for functional changes or additions? IOAG-MOSSG Final Report, August 5, 2016 39

6 Summary and Future Plans IOAG-MOSSG Final Report, August 5, 2016 40

Summary Statements from the MOSSG 1. The CCSDS mission operations service specifications (existing and planned) are fairly complete, with the MOSSG noting only a few omissions or suggested changes. 2. The CCSDS mission operations working groups already promote a mix of service and format specifications. More work is needed to add format specifications matched to the MO services for end users who may not implement the full service-oriented infrastructure. 3. Careful consideration is required for determining that an international standard should be developed for a particular functional area as a way to promote interoperability needs across missions and agencies. 4. For service specifications, a minimal capability set should be identified as a subset of the more extensive specification. 5. The MOSSG developed 8 key findings, each with associated recommendations for action. It is recognized that some of the recommendations are already being worked on by the CCSDS organization and that progress has been made during the period of the MOSSG study effort. IOAG-MOSSG Final Report, August 5, 2016 41

Thoughts for the Future The MOSSG effort is scheduled to end following the acceptance of the Catalog #3 with this report and the presentation of findings to the IOAG. It may be desirable to have the MOSSG continue to support the IOAG on operations-related issues The MOSSG could participate in IOAG Cislunar or Mars working groups to represent mission operations concerns and to promote the existing and planned mission operations standards. IOAG-MOSSG Final Report, August 5, 2016 42

Appendix A Summary of Findings and Recommendations IOAG-MOSSG Final Report, August 5, 2016 43

Summary of Findings and Recommendations (1 of 5) FINDINGS F 1. Scope: The size and scope of the CCSDS MO Services standards framework is too large to expect that the effort will be completed in a “reasonable” time period, commensurate with other industry standards development efforts. RECOMMENDATIONS R 1. 1: Focus on completing a limited set of MO Services for two to three functional areas only (of high priority from CCSDS participating agencies) and push within the agencies for their operational use. R 1. 2: Limit future technology bindings to most prevalent technologies per inputs from the member agencies. R 1. 3: Do not focus on onboard capabilities. Agencies are always encouraged to develop innovative uses for the standards and the MO services may well be able to run anywhere, but specific work for onboard capabilities should be managed by, and coordinated with, those other standards teams already working on onboard system and service standards. F 2. Standards Development Roadmap: A complete roadmap showing the full suite of existing and planned mission operations services, their key development milestones, and the organization (standards working group) assigned to the standards development is essential to gaining confidence across the agencies and their missions. IOAG-MOSSG Final Report, August 5, 2016 R 2. 1: The MO services team should place a high priority on developing the full roadmap of standards and bindings to be developed, utilizing the IOAG MOSSG Service Catalog #3 material as one set of inputs. The effort to create the roadmap may have the additional benefit of ensuring that all members of the standards development organizations and their agencies agree on a consolidated plan of action. 44

Summary of Findings and Recommendations (2 of 5) FINDINGS F 3: Range of Interoperability Needs: It was clear to the MOSSG team, which studied a range of missions, that the extent to which interoperability capabilities will be required varies greatly. It is important that the MO services team explicitly address the spectrum of interoperability degrees (illustrated in the table on next page). RECOMMENDATIONS R 3. 1: Throughout the MO Service specification and prototype efforts, utilize an explicit range of mission types with different degrees of interoperability when matching new standards to mission needs. For new services, include documentation on how they could be utilized across different mission classes. Mission type examples: a. Agency X needs limited telemetry or data products from Agency Y b. Payload X on Satellite Y or multiple payloads from different agencies c. Multiple missions with coordinated activities/goals (Mars, lunar, Earth observation) d. Jointly operated missions (ISS) R 3. 2: The MO services team should clearly document its decision approach for determining the core set of functional capabilities for a service and how both subsets and supersets of the functional list can be handled. a. SUGGESTED APPROACH: The standard should cover the minimally accepted capability set to enable basic interoperability. Individual service providers may incorporate any additional capabilities as they see fit, but are encouraged to meet the minimum set of capabilities of the standard. Ideas for additional capabilities (typically gathered from many end-users based on their experiences with their mission sets) can be provided as an informational list. The service suite should not attempt to specify every good idea received from the working group members. b. OPTIONS: The service specification could support both the minimal set and an optional set of additional capabilities. Developers could then claim to meet either Level 1 or Level 2 (for example) service support. The specification could also include, for example, a block of op-codes reserved for mission-specific use. IOAG-MOSSG Final Report, August 5, 2016 45

Summary of Findings and Recommendations (3 of 5) FINDINGS RECOMMENDATIONS F 4: Long-term Innovation: The rate of functional R 4. 1: Must clearly document how innovations may be added to the innovation for software-based systems and services is standard services and what the implications are to the formal much higher than the rate of change for many other standards. For example, could establish reserved OP Codes within standards, including RF link protocols, packet formats, etc. services for local use. It is important that the MO services recognize and support R 4. 2: Need a functional review/refresh plan that addresses the need for agencies, missions, or COTS product potential for upgrades to major parts of the MO effort. providers to additional services or to add capabilities to existing services without requiring modifications to the documented standards. F 5. Cohesive Approach Across All of CCSDS: CCSDS has multiple efforts working on services, service management, and service frameworks. It was not clear to the MOSSG team that these efforts are coordinated with each other. There may be significant overlap or inconsistency among the efforts. IOAG-MOSSG Final Report, August 5, 2016 R 5. 1: Clarify the boundaries between MO Services Working Groups and other CCSDS Areas and working groups. R 5. 2: Define a common CCSDS service framework for use across all ground elements. 46

Summary of Findings and Recommendations (4 of 5) FINDINGS F 6. Promoting Infusion and Use: There is an inherent difficulty in adopting any new suite of standards or approaches. Approval to incorporate a service-oriented approach may be particularly difficult since the paradigm is better known in software development circles than in management circles. This raises the importance of agencies working together to collectively promote the infusion of the MO services approach. RECOMMENDATIONS R 6. 1: Define a “minimal MO Services Suite” which could be adopted as a lower-cost-of-entry approach for selected missions. R 6. 2: Ensure that there are both format-based and service-based standards developed for each key function. The format approach will allow for quicker adoption and allows users to exchange data for interoperability without having to build a fully compliant software framework. R 6. 3: Consider the development of a cross-agency interoperability demonstration to highlight the many benefits and capabilities of the suite of standards. This demo would showcase the overall MO vision, and not just a single standard as is currently done with CCSDS prototypes. R 6. 4: Encourage agencies to share their lessons learned as MO services are developed and utilized. IOAG-MOSSG Final Report, August 5, 2016 47

Summary of Findings and Recommendations (5 of 5) FINDINGS F 7. Code Sharing: Code sharing through CCSDS has been proposed as a means of MO services standards infusion across space agencies and is listed as a key benefit of the services approach. RECOMMENDATIONS R 7. 1: Standards organizations should focus on providing interagency and intra-agency MO services interoperability specifications only, not implementation R 7. 2: Limit any CCSDS-coordinated code sharing to purely technology proof-of-concept demonstrations R 7. 3: IOAG suggests that CCSDS encourage agencies to develop and share software, possibly as open source; but it should be the responsibility of the agencies to promote and share any software they wish to make available. F 8. Need for Guiding Principles: No set of guiding (or architecture) principles appears to exist for the depth and scope for the definition of MO services. IOAG-MOSSG Final Report, August 5, 2016 R 8. 1: Develop a small set (~6 to 10) of guiding/architecture principles or criteria that the MO services development team shall use to guide the evolution of the standards. Recall that principles are “general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission. ” (Source: The Open Group Architecture Framework [TOGAF], Version 9. 1). The MOSSG has developed a sample set of Service Evaluation Factors which could form the basis for the guiding principles (see Section 5). 48