CCSDS SM&C WG Core and Common Service Prototyping

1. CCSDS SM&C WG Core and Common Service Prototyping Amalaye Oyake Jet Propulsion Laboratory Member of Technical Staff April 13th, 2005

2. Topics • Introduction • NASA JPL reengineering efforts • CCSDS Common Services Red Book • CCSDS SLE Reference Model • SLE as "a" Common Service • Elaborating Interoperable Adapters • CCSDS Core Service Red Book • JPL Deep Space Mission System (DSMS) Information Bus • SCOS 2000 • Harmonization of Work

3. Introduction • NASA/JPL - NASA/JPL's infrastructure is built around the Deep Space Network (DSN), which employs many applications many of which are proprietary. • The DSN is a network of radio antennas that supports interplanetary spacecraft missions as well as Earth-orbiting missions. It has 26, 34 and 70 meter antennas in Barstow, Madrid, and Canberra (Australia). • There are several ongoing efforts within JPL to reengineer various segments. Particularly using Service Oriented Architecture (SOA), Web-Services and XML (Erik Barkley, JPL-DSMS*). • The CCSDS M&C WG should; • 1. Review some of this parallel/complimentary NASA/JPL work. • 2. Review the CCSDS SLE Reference Model particularly the core service and the service management aspects. • 2. Harmonize/Align it the with CCSDS Core and Common Services Red Books - Especially in the area of exposed Service Access Points provided by future services to Ground Systems. • 3. Coordinate future activities (marketing, prototyping, etc). * Discussed later on in the presentation

4. CCDSDS Core and Common Service Red Books <<BIG PICTURE>> PROTOCOL ADAPTER

5. CCSDS SLE Reference Model Diagram form Larry Munzy, CSOC

6. SLE as a Common Service • The SM&C Common Services (as defined in the Red Book) builds upon the layering concept outlined in the Mission Operations Services Concept White Book. • The SM&C Common Services specifies multiple high-level services over a smaller set of common services, which make it easier to bind these to different underlying technologies to facilitate communication over the layers of the protocol stack. • What is required is an “adapter” layer between the common service and the underlying protocol to enable all high-level services to communicate over that technology.

7. SLE as a Common Service • These adapters described in the Red Book should expose an interface using a standard Service Access Point (SAP). • In the deployment of ground data system applications, each agency (NASA, ESA, JAXA) implements its own specific architecture. Adapters would help bridge the underlying agency infrastructure. • For example if JPL wanted to inter-operate with an ESA mission, an adapter could be used to bridge ground station resources. • The CCSDS Space Link Extension is a standard SAP for forwarding frames and returning telemetry data.

8. SLE as a Common Service • One of the goals of the CCSDS is that recommendations will enable commercial-off-the-shelf (COTS) product development and resource sharing between space systems and ground stations. • To enable ground station resource sharing, CCSDS created the Space Link Extension (SLE), which extends the space link standards to the ground link. • The CCSDS Common Services Red Book makes no mention of SLE. • CCSDS Common Services Red Book should specify SLE as an interoperable layer, and specify adapters to the SLE service.

9. SLE as a Common Service MISSION OPERATION CENTER DEVICE SCOS 2000, JPL I-Bus etc SMCP Messages over AMS C&DH INTEROPERABLE ADAPTER SLE GROUND STATION ANTENNA S/K/X Transponder or UHF Transceiver DSN, NCTRS etc

10. INTEROPERABLE ADAPTER SLE as a Common Service Application Service Access Point SLE Service Access Point

11. SM&C SERVICES APPLICATION MESSAGES (SMCP via AMS/CORBA) SIS (SOAP/CORBA/AMS) SM&C SERVICES INTEROPERABLE ADAPTER CCSDS SOIS C&DA SERVICE SLE CCSDS TM/TC SOURCE PACKETS SLE SERVICE MANAGMENT TRANCEIVER GROUND STATION SLE as a Common Service USER APPLICATION ONBOARD APPLICATIONS RF LINK RF LINK CCSDS XFER FRAME

12. Mission Operations • The CCSDS Core Services Red Book identifies Mission Operations Functions. • The SM&C Core service builds upon the layering concept outlined in the Mission Operations Services Concept. • These ideas are very similar to a NASA/JPL project called the DSMS Information Bus. • The DSMS Information Bus End-to-End will support End to End data accountability, commanding, sequencing, catalog service, service preparation, network monitor and control (NMC) and more. This aligns with the Capability Sets listed in the Core Services Red Book.

13. Mission Operations • ESA's Space Operations Center (ESOC) already uses a modern M&C core infrastructure called SCOS-2000. SCOS-2000 is a generic spacecraft mission monitoring and control infrastructure developed by ESA. It is a consistent end-to-end application for use by ESA members. • It provides all essential functions to monitor and control a satellite both in orbit and during testing. It is based on the state of the art software engineering technology and has been conceived to be platform/vendor independent. • It should be noted that SCOS-2000 provides the following functionality - Telemetry reception and processing, Telecommand editing and releasing in manual and automatic mode, Data archiving and retrieval mechanism, Live and retrieval data display, On-board software images archive and maintenance. • The SCOS-2000 framework also looks very similar to the JPL DSMS Information Bus concept.

14. Harmonization of Work • In discussions with Mario Merri et al, there is great potential for prototyping work. The following should be done as well: • The CCSDS Common Services Red Book should specify the role of SLE. • The CCSDS SM&C WG should understand SLE Service Management*. • Elaborate the specification of the interoperable adapters. • There is ongoing work by the JPL DSMS group which should be shared with the CCSDS SM&C WG. • Marti Demore of DSMS has already submitted comments on the Core and Common Service Redbooks and is interested in participating in the SM&C WG. * Note: SLE Service Management is the formal contract that is negotiated before initiating an SLE Session. Many parameters must be (such as trajectory, space link characteristics, service request specifications) specified by the SLE Service Management before a session can be initiated.