CCSDS SM&C WG Core and Common Service Prototyping
description
Transcript of CCSDS SM&C WG Core and Common Service Prototyping
CCSDS SM&C WGCore and Common Service Prototyping
Amalaye OyakeJet Propulsion LaboratoryMember of Technical StaffApril 13th, 2005
• IntroductionNASA JPL reengineering effortsCCSDS Common Services Red BookCCSDS SLE Reference Model
• SLE as "a" Common ServiceElaborating Interoperable Adapters
• CCSDS Core Service Red BookJPL Deep Space Mission System (DSMS) Information BusSCOS 2000
• Harmonization of Work
Topics
• 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).
Introduction
* Discussed later on in the presentation
CCDSDS Core and Common Service Red Books<<BIG PICTURE>>
ADAPTER
PROTOCOL
CCSDS SLE Reference Model
Diagram form Larry Munzy, CSOC
• 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.
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.
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.
SLE as a Common Service
MISSION
OPERATION
CENTER
SLE
INTEROPERABLE
ADAPTER
GROUND STATION
DEVICE
C&DH
ANTENNA
SCOS 2000, JPL I-Bus etc
DSN, NCTRS etc
S/K/X Transponderor
UHF Transceiver
SMCP Messages over AMS
SLE as a Common Service
INTEROPERABLE
ADAPTER
SLE Service Access Point
Application Service Access
Point
SLE as a Common Service
USERAPPLICATION
SM&C SERVICES
SIS (SOAP/CORBA/AMS)
INTEROPERABLEADAPTER
SLE
SLE SERVICE MANAGMENT
GROUND STATION
ONBOARDAPPLICATIONS
SM&C SERVICES
CCSDS SOIS C&DA SERVICE
CCSDS TM/TCSOURCE PACKETS
TRANCEIVER
APPLICATION MESSAGES (SMCP via AMS/CORBA)
CCSDS XFER FRAMERF LINK RF LINK
SLE as a Common Service
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.
• 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.
Mission Operations
Harmonization of Work
In discussions with Mario Merri et al, there is great potential for prototyping work. The following should be done as well:
1.The CCSDS Common Services Red Book should specify the role of SLE.
2.The CCSDS SM&C WG should understand SLE Service Management*.
3. Elaborate the specification of the interoperable adapters.
4. There is ongoing work by the JPL DSMS group which should be shared with the CCSDS SM&C WG.
5. 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.