Interagency Operations Advisory Group IOAG Mission Operations System

Interagency Operations Advisory Group (IOAG) Mission Operations System Strategy Group (MOSSG) Catalog #3 Interoperability Demonstration Marc Duhaze, CNES Costin Radulescu, NASA Mehran Sarkarati, ESA 2020 CCSDS Spring Technical Meetings May 6, 2020 1

Demonstration objective refresher 1. Demonstrate inter-agency interoperability for a typical multi-agency project’s use case. 2. Identify the benefits, challenges and mitigation approaches associated with reusable inter-agency interoperability approaches for mission operations. • From the IOAG Service Catalog #3 specification…: “Service-based development is one valid approach for implementing interoperability functions. Many missions, however, have utilized a message-format approach to exchange information and use a variety of message delivery alternatives. The use of formats-based approaches may provide a simpler development process and could therefore speed adoption across Agencies. ” 3. This effort attempts to demonstrate the IOAG interoperability solutions above by using: • A representative subset of Catalog #3 services to show both IOAG interoperability approaches (i. e. service-based, formatbased) and Identify the benefits, challenges and mitigation approaches associated with each approach. • Three Agencies to demonstrate interoperability • Each Agency’s representative mission operations systems and infrastructure • Exercise each agency's security interfaces for authentication and authorization May 6, 2020 2

Participating Agencies • Centre National d'Etudes Spatiales (CNES) • Marc Duhaze (Marc. Duhaze@cnes. fr) • European Space Agency (ESA) • Mario Merri (Mario. Merri@esa. int) • Mehran Sarkarati (Mehran. Sarkarati@esa. int ) • National Aeronautics and Space Administration (NASA) • Costin Radulescu (Costin. Radulescu@jpl. nasa. gov) • Funding for each agency’s activities is internally provided by each Agency. • Group meets bi-monthly. May 6, 2020 3

Some Interoperability Guidelines considered for this demonstration 1. 2. 3. 4. 5. 6. 7. 8. Support is needed for both formats and services • Allow development of transformations between the two. Use mnemonics (names) to reference parameters instead of locally generation IDs. • Mnemonics are unique across the set of systems. Provide descriptive log/event/memo messages when sending across external interfaces • May include an ID number, flag(s), etc. Minimize storage of one’s configuration information on other users’ systems • Keeping everything in sync becomes a problem with a big overhead • May need invasive access to each system (e. g. . Directory update/delete/etc. ) Assume each agency has its own security approach and may not be as simple as a unique plug-in. Minimize need for cross agency remote DB queries and registries (e. g. each partner has an XTCE file). • Agencies involved in a mission know they are involved in that mission and have planned for it with their partners! Identify the subset of functions applicable across agencies for the primary purpose of interoperability. This may be a small list. MO may have other benefits for reuse, ease of ops, on-board, etc. Separate local system design from the actual use of information (exchange) May 6, 2020 4

Concept (at task kickoff in April 2019) Interoperability Demonstration System New or Legacy System CAT #3 Services/ Interfaces Local Interfaces Gateway Simulators Agency A Testbed Communications Infrastructure – network (internet or private) and transport protocol Logon and Security provisions as required Catalog #3 services between gateways CAT #3 Services/ Interfaces Local Interfaces Gateway Simulators Agency B Testbed CAT #3 Services/ Interfaces Pass-through Interfaces Gateway Agency C Testbed May 6, 2020 New or Legacy System “CAT #3 Aware” New or Legacy System Simulators Note: • Gateway provides interface mapping when dealing with heterogeneous deployments. • Pass-through gateway assumes homogeneous deployments. 5

Service selection for demonstration • For this demonstration we chose to exercise two scenarios for which we selected two services from Catalog #3, respectively: 1. Scenario 1 (serviced-based approach): • Real-time telemetry data exchange (Real-time Parameter Service) 2. Scenario 2 (format-based approach): • Navigation data exchange May 6, 2020 6

Scenario 1 (service-based approach) • Real-time telemetry data exchange: • MO* Parameter Service • All Agencies would use the existing CCSDS Standards and refrain from inventing new ad-hoc interfaces • It is fine for an Agency not to deploy MO Service software as long as it complies with the existing data standards exchanged “on the wire” (e. g. messages and behavior as specified by MO Parameter Service, MAL** over HTTP and XML binding). • In this case the agency uses a “gateway” to serve as an interface between MO Services and the Agency’s internal mission operations system to deal with things such as mnemonics, security (authentication & authorization), etc. • Things such as from/to domain information will be documented in an ICD May 6, 2020 *CCSDS Mission Operations Services 7 **CCSDS Message Abstraction Layer

Current demonstration concept CNES IOAG GATEWAY Functions ISIS Science CCC IOAG GATEWAY tp ht ESOC p XML Msg SWOT Simulator http SCOS Note: • XML Msg http Bepi. Colombo Simulator IOAG GATEWAY The IOAG Gateway is a generic interface implemented by each Agency to map from "canonical IOAG protocol" to "local system interface”. May 6, 2020 NASA http IOAG GATEWAY AMMOS • Map mnemonic to parameter_id in the XML message on the wire • Map MO Login service to agency specific security services to acquire authentication & authorization credentials and update the XML message header on the wire Generic S/C Sim 8

Scenario 2 (format-based approach) • Navigation Data Exchange: • Team had a lot of discussions trying to articulate exactly what is format-based interoperability • The current approach is to use CCSDS navigation data format (applies to other comparable CCSDS data formats). • The “format” is the actual CCSDS Navigation data format being exchanged on the wire (need to specify exactly which one will be used) • There are implicit operations that need to be executed in order to authenticate, authorize, initiate, execute, handle events, terminate the exchange of navigation data formats. • An example may be an instantiation of a file transfer protocol • Provider/consumer interfaces will be documented in an ICD and housed in the gateway to be shared across Agencies. May 6, 2020 9

Points of contention • Catalog #3 needs to provide more specificity with respect to what it considers to be service-based versus format-based interoperability • The team spent a lot of time arguing about what is considered “format-based interoperability”. • The team is converging on a path forward format-based interoperability in Scenario #2 of the demonstration, but identifies that there is still a “service”-like framework associated with it. • Use of mnemonics per Catalog #3 guidelines • The team acknowledges the value of using mnemonics, but unless they are part of the information/data/message exchanged on the “wire” it will require a query service to match mnemonics against internal parameter identifiers. • Security • Each Agency has its own security interface and security token generation authority. • The team is still discussing whether the MO Login service can meet the security needs for Scenarios #1 & #2. May 6, 2020 10

Preliminary findings • Interoperability seems to have a “service”-like framework associated with it. • The question is what are the boundaries of defining such “service”? • Is it a “service” framework/architecture or an actual implementation/instantiation of such a framework? • Both Scenarios #1 and #2 require some level of interface documentation (e. g. ICD) • Initial assumption is that Scenario #1 requires a simpler straight-forward ICD versus Scenario #2. • Each Agency will use their own Gateway implementation • The team plans to provide findings and recommendations for what it thinks is needed to do inter-agency interoperability in the future. May 6, 2020 11

Current demonstration status • CNES • Uses ISIS Science Command Control Center with simulated SWOT data • ISIS has a MOIM SM&C compliant front-end and may use the conversion gateway in both modes (pass-through and conversion) • Work on the gateway has not started. Start date is TBD. • ESA • Stood up 2 VMs using SCOS with Bepi Colombo simulated data • SCOS has a MOIM SM&C compliant front-end and may use the conversion gateway in both modes (pass-through and conversion) • NASA • Stood up 2 VMs using AMMOS and finalizing security access (perimeter access control) • AMMOS does not have a MOIM SM&C front end and will use a conversion gateway. • Work on the gateway configuration for Scenario 1 will begin end-of-May 2020. • Setting up infrastructure and getting all communication ports and security credentials in place took longer than anticipated. • Initial interoperability demonstration should be completed by end-2020 allowing expanded demonstration or implementations to be conducted in 2021 onwards. • Team will work on generating the list of deliverables at the end of CY 2020. May 6, 2020 12

Backup Material May 6, 2020 13